OStatic

by an anonymous user on Jun. 07, 2010

Would this problem exist if there was only one package format for all the Distros? To be more specific if Red Hat and Debian were to just agree on only using rpms or deb for every single linux distro or create a whole new package format and declare that the linux package standard would this problem exist? If so why?

by an anonymous user on Jun. 24, 2010

Looks like Ubuntu's Chromium PPA is doing automatic nightly builds just fine with the Chromium project. Actually, using Git and building is quite simple, even for someone who doesn't do a lot of building at the command line. I certainly don't.

by Reilithion on Jul. 20, 2010

Jun. 07, the answer is yes. This problem would still exist regardless of the package format differences between distributions. Here's why:

Nearly every modern piece of software works as a team with other pieces of software, as opposed to standing completely alone on bare hardware. Some is system software, like the operating system itself. Some is application software, like OpenOffice and Google Chrome. A lot of software comes in the form of shared libraries. Shared, because they're expected to be useful to multiple other pieces of software. Take Webkit, for example.

Google Chrome is not the only web browser to make use of Webkit. Webkit is a shared library, and anyone who wants to make a browser can make use of Webkit and save themselves the trouble of writing all that code over again. Midori, for instance, makes use of Webkit, and I believe Safari does too. It also saves your computer the trouble of keeping multiple copies of code that does the same thing sitting around in memory. If for some reason you want to run Midori and Safari at the same time, your computer only needs one copy of Webkit in memory. Saves space. Saves hard drive space too, since you only need one copy of the shared library file (.so on *nix, .DLL on Windows).

But right now, if you try to run Midori and Google Chrome together, there will be two copies of Webkit in memory, and two copies of it on your hard drive. Why?

Because the developers at Google yanked a copy of Webkit into the source of Google Chrome and started hacking on it. Now, maybe they had their reasons for doing this -- I wouldn't know. But it is wasteful. They did this with several different libraries, and as a result, Google Chrome is... kinda huge. Both in memory and on disk. Some distributions, like Ubuntu and Gentoo, are just dealing with this. They figure, "If the user wants Google Chrome, they can be the ones to worry about how much space it's wasting," and they provide packages for it. And it's almost a non-issue on Windows, where this is basically the default behavior anyway. But I can certainly understand why some distro maintainers would be hesitant to include such a package. The last thing I want to do all day is answer questions about why Google Chrome's package is some 600 MB and eats up all the RAM.

by Toshio Kuratomi on Jul. 29, 2010

Nice comment, Reilithion!

I'd just add that the problems with bundling don't stop with space usage. They also extend to bugs and security issues. If a security issue comes up in WebKit, no system administrator wants to run around looking for all the packages that embed WebKit, making sure to update them, and forward porting any customizations that those applications have made to the particular WebKit that they were bundling. The ideal case, is that you update a single, webkit package from your distribution and then, because it's a shared library, every application that uses it will start using the fixed version the next time the program is started.

Even when the packages needed a recompile or even porting to a new API, not bundling has advantages. With non-bundled libraries, at the most you have to port application code to the new library. You can tell which applications those are because the package metadata will tell you which packages require the shared library. Contrast this to the bundled library case where you first hunt down random packages that are bundling the library, then figure out how to port the patches that were applied on top of the library, and finally can port the application to the new API.

Doing all of that, remember while under pressure to release a fix before crackers start to exploit apps that contain the vulnerable library.

by diablomarcus on Jul. 31, 2010

@anonymous: Yes, it is a problem with Google and other's references to shared libraries. They don't reference the packages per-say, but rather fork the libraries that they want so that they are no longer compatible with the standard libraries. They probably make minor changes to them to make their coding easier. This is an example of lazy coding that makes projects go up really quickly, but be more messy, bloated and lack compatibility.

The rpm v. deb debate doesn't have much to do with it.

by diablomarcus on Jul. 31, 2010

And I thought the comments were bottom up... Sorry, my post is pretty irrelevant and not nearly as good as Reilithion's or the others that follow theirs.

by Reilithion on Aug. 11, 2010

Thanks for the extra information, Toshio Kuratomi. Security concerns and library patchs didn't even occur to me. I guess it's pretty obvious that I'm not a distro maintainer. ;-) Well, now I know.

by an anonymous user on Sep. 11, 2010

Sorry, I do not understand it. Chromium by default builds a mostly static library that includes all of that code Google forked. That's very easy to handle for packagers.

by an anonymous user on Sep. 12, 2010

I believe one of the idea is to let chromium developers actually test any fixes/changes in the libraries used instead of just hoping it will still work after version change. It will also allow them to use newer libraries which haven't been integrated to the target distro.

by phillw on Sep. 13, 2011

Well, just as I was getting used to Fedora they have some one say this?!!!! I'm a Ubuntu user popping my toe into Fedora at the request of one the 'upstream' F/OSS teams I am admin for.

As John McCenroe of tennis fame said... "You cannot BE serious".

The introduction of Chromium into Ubutnu caused many such suggestions. Sadly, it is a case of a multiple of urban myths. It was a requirement that Chormium does NOT report back to Google. The stable Chromium releases are just that... stable. If you want cutting edge (and I do use the daily builds to help test), then you can do so. As for forking off stuff tested in the F/OSS area to Chrome? Why not?

I'm fortunate to have exchanged e-mails with the guy who looks after Chromium (Google employee) on Ubuntu, he can go from reported bug to fix released in a matter of hours. I'm stunned at Fedora's attitude..... Well, at least it now means I have to work out how to use yum :D

Regards,

Phill.

by Jimbo on Oct. 08, 2011

I use chrome on both windows and fedora (chromium) and whilst it works fine I have notitced it's becoming evermore greedy with resources and plugins become increasingly unresponcive. Chome is a great web browser the UI is well thought out and it's increasing marketshare is testiment to this.

I know fedora to be a responsiable brand and a very stable OS that is devoted to its community, if there are codes of practice that are required to be adhered to in order to be in a repo thats trusted by that community; then applications and developers should follow this. Many other developers do and I feel that chromium should be no exception.

Obviously it's in no ones interests to make good programs difficult to access but with the same token I like to know that standards are being upheld with a OS I use day in day out.

by David on Mar. 21, 2012

You should all try Windows. Just download and install Chrome, Firefox, Safari. Whatever you want. It's really cool.

by an anonymous user on May. 13, 2012

David, I installed Windows, then I tried installing Firefox, but there wasn't any package manager to do this, so I decided to remove Windows again... What did I do wrong? :)