tom callaway (spot) wrote,
tom callaway
spot

Chromium: Why it isn't in Fedora yet as a proper package



People keep asking me about chromium (the generic name for Google Chrome), specifically, when it will be part of Fedora proper. Why do they ask me this? Well, because I've been packaging built-from-source-against-Fedora RPM packages here: http://spot.fedorapeople.org/chromium/

Here are a list of the roadblocks to proper inclusion:

* Chromium isn't stable. That's not to say that the code doesn't work, or even that it is overly buggy. The fact that I'm able to package it implies a certain measure of stability. What I mean by this is that the Chromium code (on Linux) is not yet doing stable code releases. Currently, I pull v8 and chromium code from SVN (and strip out all sorts of disgusting nonsense that is utterly and wholly unnecessary), then package it up, remerge my patches, build on three Fedora targets (F10, F11, F12), two architectures (i386|i586|i686 & x86_64), do some basic smoke testing to make sure that browsing works, and rsync the new packages to my fedorapeople.org space (along with repodata). This process takes about two days from beginning to end (most of the time is in builds, although remerging my patches usually takes a fair amount of time too). However, the point here is that everytime I build, I'm having to guess as to whether the code is in a workable state. There have been a few times where I've gone through the work to regenerate my patchset, built a set of packages, only to discover that some key functionality is broken at the moment, requiring either a later checkout or a bugfix from upstream. An open source project with stable releases marks a point in time release as reasonably stable, gives it a release number, pushes out tarballs of that source tree, and does patchfixes on that release for some period of time to cover things like severe bugfixes and security issues. Example, Firefox 3.5. Google isn't doing this yet, and I'm not sure when they will. (Note: I have asked various folks @ Google who work on Chromium about this, and only get vague wishy-washy maybe-sortof-coming-soonish answers. Keeping in mind that as of this writing, they are not officially even in "Beta" yet (understanding that the term "Beta" is really meaningless from a Google perspective *cough*gmail*cough*), I'm willing to be patient here.) Google needs to have "stable" releases before I would even think about maintaining it in Fedora.

But wait, you might say, there is a "stable" drop, the 3.* series. Yeah, except there is no bugfix plan, and most of the key features are either unimplemented or under-implemented in that release. Not much of an option.

* Google doesn't really treat v8 as an independent project. This is a shame, as the v8 code is pretty darned nifty, and it would be great to see it getting wider adoption outside of the browser space (or even outside of the "browsers-that-start-with-chrom" space). This is the power of leveraging cool code as an accelerator, working with other open source community projects. and gaining developers and users exponentially. How could Google do this? Well, for starters, see the above item, and replace "Chromium" with "v8". Define an API, and stick with it, at least for a major release version. (Need to make big changes? That's why unstable branches are for.) Stop bundling the v8 source as part of chromium, and document that you need to have version X.Y.Z installed to build chromium. ("Unpossible!", I hear the v8 devs crying out, except that I've been doing exactly that, for months.) But, you may ask, what is the big worry about a "stable" v8? Isn't a "stable" chromium code drop enough? Well, no. The problem is that the v8 development is pseudo-independent of the chromium code development, and the current bugfixing method for v8 (just like for chromium) is to update from SVN. Now, I've got two projects like trains, chugging along on separate train-tracks, and I'm clinging between them to keep them together. If one moves too fast (or two slow), I get pulled apart (figuratively only, I hope). The upstream rebuttal seems to be "This won't happen. Don't worry.", but I've been doing this FOSS stuff long enough to know better.

* Google is forking existing FOSS code bits for Chromium like a rabbit makes babies: frequently, and usually, without much thought. Rather than leverage the existing APIs from upstream projects like icu, libjingle, and sqlite (just to name a few), they simply fork a point in time of that code and hack their API to shreds for chromium to use. This is akin to much of the Java methodology, which I can sum up as "I'd like to use this third-party code, but my application is too special to use it as is, so I covered it with Bedazzler Jewels and Neon Underlighting, then bury my blinged out copy in my application.". A fair amount of the upstream Chromium devs seem to have Java backgrounds, which may explain this behavior, but it does not excuse it. This behavior should be a last resort, not a first instinct. What should happen is this:

[google] hey, it sure would be nice if we could use sqlite in chromium for our local db needs.
[google] hmm, the sqlite API doesn't mesh 100% with how I'd like chromium to use it
[google] hey sqlite upstream, there are a few places where we'd like to see API improvements so chromium can leverage it for our use-case
[sqlite_upstream] hey google, so cool that you want to use our code.
* sqlite_upstream looks at google's proposed changes to sqlite *
[sqlite_upstream] interesting, you could try using the foo_bar function for your camel launching needs, but the rest of the changes seem okay
* sqlite_upstream commits changes to the source tree in commit rev 12345 *
[sqlite_upstream] Our next release will support that.
[google] yay! we'll tell people to either apply our patch or use commit rev 12345 or newer.

To be fair, when Google forks an upstream project in chromium, they do write a README.chromium which summarizes the changes that they made. This is technically, better than nothing, but much in the same way that swimming in a pool full of angry, underfed, electric eels is better than nothing when you're desperate for a quick swim.

The rebuttal from the Chromium upstream is roughly this (although, not always in this order):
** We move too fast to work with upstreams in this manner. (Answer: No, you don't, and if you did, and you could document that, it would make a forking action more rational.)
** Chromium is too unique for this to work. (Answer: No, it isn't. Re: Tyler Durden in Fight Club.)
** We have people maintaining all of these forks and we always well, so its fine. (Answer: Really? Really? For how long? For this month, for this year, for ever-vers? What if everyone did that? We'd have thousands of forks of openssl, and possibly millions of forks of glibc.)
** We need special hacks for Windows/MacOSX/Linux that upstream probably wouldn't take. (Answer: Gee, I bet that they would like to properly support those platforms too.)
** Our hack is ugly. (Answer: Well, clean it up. Heck, even submit it as is, it might not be as ugly as you think, or upstream might help you come up with something that is prettier.)
** We need this for our pre-built magic binaries of Google Chrome (tm). (Answer: That's great, but I don't care what goats need to be sacrificed on what altars to make your magic binaries. If having hacked up copies of mystery third-party code-meat embedded in your "official" binaries is what you want to do, knock yourself out. I can think its dumb, risky, and long-term unmanageable, but its your code. Put a sweater on it and take it to the prom if it makes you happy. Heck, the nature of Windows might make it a fact of life for that platform, but if you're going to be dependent on pre-built upstream bits, wouldn't you prefer that those bits be supportable by that upstream, instead of forcing you to carry that support burden forever? Hint: The answer to that last question is yes.)
** We need this specific version for Chromium to work. (Answer: Lots of FOSS apps depend on specific versions of third party bits to work. Thats why those apps check for the existence of their dependencies on the system during initial configuration (pre-build), along with the specific versions of those deps. Heck, the pkgconfig infrastructure was built specifically to take some of the pain out of that procedure.)
** Chromium doesn't have an initial configuration process. (Answer: Well, gee. I wonder if that would be useful.)
** You just don't understand. Don't worry, we know what we're doing. (Answer: Uh huh. Okay. Where I grew up, when someone said "Don't worry, we know what we're doing", when there was ample and obvious evidence to the contrary, that person was usually about to blow off an appendage with fireworks. Forgive me if I take several large steps away from you now.)

Part of (okay, most of) my patchset has been to do exactly this, strip out Google's local copies of third-party upstream bits from Chromium and use the Fedora system copies. I've gotten a significant amount out, including bzip2, zlib, minizip, v8, icu, libxml, libxslt, and some of the mozilla bits. Some bits, like WebKit, are theoretically removable, but because Chromium depends on such bleeding edge WebKit code, are not practically removable, even though it is one instance where they have most of their changes in the upstream WebKit source.

To get Chromium into Fedora, I'm going to have to ask FESCo for an override of the guidelines involving bundled copies of system libs (specifically, that such behavior is not acceptable). The fewer examples of this in the Chromium code, the more likely that FESCo will permit that exception. I'm realistic enough to know that this will probably take a long time to drop to zero (yet, somehow, Mozilla manages it with Firefox), but hopeful that it will someday just be "WebKit because it is too new, and when WebKit catches up, not even that."

** Ubuntu doesn't care. (Answer: They should, and I bet, if you ask them, they probably do. But again, if someone else wants to do something dumb/dangerous, that doesn't make it a good idea. Note: I'm not implying that Ubuntu is dumb or dangerous. Insert any other distribution name there if it makes you feel better, I'm not trolling for an attack of the Ubuntu-fan boys/girls.)

* I haven't sat down and worked out all the licensing compatibility concerns yet. When I started doing that with any seriousness, I found a brand new (to me) license on the first piece of third party code that I found, and I'm not even sure if it is Free (waiting on the opinion of Red Hat Legal). The spaghetti nature of the relationship of Chromium and its third party code-bits makes determining the license of the meatloaf end-result somewhat mysterious. I've been assured that everything is kosher, but this comes from Google, who sees nothing wrong in redistributing all of the code to ffmpeg as part of Chromium. I am going to do this, just haven't had the time to beat through it all yet.



So, with all that, why do you even bother packaging Chromium for Fedora? Well, the application is interesting, and I think the competition in the Web Browser space for Firefox is healthy. It runs fast, and reasonably well, and has feature functionality that I like.

I do think that with great power comes great responsibility, and Google could truly be a much better community participant than it currently is.
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 88 comments
Previous
← Ctrl ← Alt
Next
Ctrl → Alt →

Anonymous

November 30 2009, 22:42:35 UTC 7 years ago

Thanks for the update!

I "use" chromium builds from chromium.org but I always hoped chrome/chromium would make it into distributions sooner or later (when the linux version is out of beta).

Thanks for keeping track of the issues. I really hope Google will cooperate and we will get "official" chromium builds from Fedora at some point.
From what I've seen of the Ubuntu Mozilla Team, Mozilla isn't much different if you want blessed binaries and branding. This version of that library, etc. I quietly walked back to my safe, safe place and let them do their business.

And as far as I can tell Chromium isn't in Ubuntu either, for a many of the reasons you cite. One of the mozilla team participants publishes a "personal package archive" but nothing is official yet. It also splits chromium out into browser, v8 and ffmpeg packages, and I think builds a separate package for the duplicated libraries, and while I can't check the changelogs at the moment, I imagine there's some effort to migrate these away. So I'd say we do care, and if you want to do something dumb/dangerous like use a PPA, that's what they're for =)

One question about stability testing though: I thought Chromium came with a testing suite? Though I guess it's quite large and I'm not sure where you draw the line on number of failed tests. Perhaps a monotonically decreasing criteria?

They do have a large code testing suite, but given how fast the code changes, it doesn't really help me determine when the tree is stable. Blink and it isn't. Blink again, and it is.

sdelatpravilno

2 months ago

I think the shorter answer is: you demand a huge amount of work for minimal benefit for "upstream" (Chrome), so while various bits of the work are underway it's not going to happen quickly. Each of your bullet points is of the form "X ought to be Y" but none mention why that is useful (or if it is useful, why it merits the amount of work involved). *shrug*

As always, I wish you'd do something constructive rather than rant. I CC'd you on a bug where I tried to itemize your requests:
http://code.google.com/p/chromium/issues/detail?id=28287
but heard nothing back.
I had hoped the reasoning was obvious, but I'll try to explain:

It is the difference between being a consumer and a contributor. Or, to be blunt, the difference between being a parasite and a partner.

I've generated a slide deck that I presented at Atlanta Linux Fest a few months ago which covers why cultivating contributions is healthy for a community (and arguably, necessary for it to survive):
http://spot.fedorapeople.org/Cultivating_Contribution-Atlanta-Linux-Fest.odp

As for me doing "something constructive", I'll note that I regularly send in patches, many of which are wholly ignored (http://code.google.com/p/v8/issues/detail?id=453 is a notable example). I did forget about your metabug, it fell off my radar, but I've thrown a lot of bugs at it tonight.

Anonymous

5 years ago

spot

5 years ago

Wouldn't that sort of make it non-tenable for Fedora anyway? What does it use ffmpeg for?
They actually dlopen ffmpeg, so I'm able to strip it out (except for the headers, which aren't patent encumbered). The code tree includes the full source though.

Re: ffmpeg?

king_inuyasha

7 years ago

Re: ffmpeg?

spot

7 years ago

Re: ffmpeg?

king_inuyasha

7 years ago

Re: ffmpeg?

Anonymous

6 years ago

Re: ffmpeg?

king_inuyasha

6 years ago

Re: ffmpeg?

blasdelf

7 years ago

Re: ffmpeg?

spot

7 years ago

You make very valid points. I wish Google would commit more to upstream.

I recently found that you can install Google Chrome (not chromium) directly from Google's repositories. Its v 4.0.249.11.
http://www.google.com/linuxrepositories/

Add the repo to /etc/yum.repos.d/

And do a
yum install google-chrome

Its interesting that Chrome can be downloaded for Fedora, while Chromium cannot!
Btw, thanks for the chromium builds.
Well, all of the builds that Google does, it puts the "Chrome" trademark on it. They're the only ones with permission to use that trademark, which is why my builds are all branded "Chromium". Same code, except for the identifier strings.
Google Chrome is yet another software made by Google ... to have more control over the Internet!!!!
Google is everywhere, it's like a virus!!!!
Google Chrome gives nothing of new and useful to you!! Yes, it's a new browser, but it sucks a lot!!!!!! What does Chrome gives to you? Is it of any advantage for you?
Mozilla gets almost all 'donations' from Google; don't you see anything of strange? Will you wake up when it will be too late???!!
Google is another EVIL company, even if they say the opposite!!!!
It's a multinational company tracking everything you're doing online!!!!! You search with Google, and surf on websites using Google Analytics, then you've GMail and their calendar, and their advertising!!!!
Don't use Google's applications!!!!!!! Don't establish a dependence to Google, like you wouldn't do with Microsoft or Apple, Intel or IBM!!!!!!!!!!!!!! They're companies with different names, but their behaviour is all the same one!!!!!!!!
Boycott Google!!!! Multinational companies like that one are terrible!!! You'll the first one to take advantages from the 'lack' of their usage.
Google Chrome is useless, it's like a Trojan Horse (if you know what a Trojan is.... it isn't a condom; i'm talking about the Trojan Horse derived from the Trojan War story in Greek mythology).

Don't install Google Chrome and don't suggest to the others to install it!!! Suggest the opposite!!!!!!!!!!!!

bye!!!!!!!!!!!!!!!!!!!!!
Bee!!!!!!!!!!
http://honeybeenet.phpbb3now.com/
Well, I'm not sure I agree with you here, Bee. Red Hat is a multinational company, should you not use Fedora because of that?

I don't think Google is Evil, even if I do have some concerns about how the chromium code base is managed. The code is out there, available for anyone to look at and inspect. If you are afraid of bad things hiding inside the chromium code, you can look through it and decide for yourself if it is safe or not.

I don't think that the existence of Chromium creates a dependence on Google, if anything, I think it offers more choice in the FOSS browser space, which was previously just Firefox, and, umm, Firefox. (Yes, I know about Konqueror, but I'm not a fan.)

Re: Don't use Google!!

Anonymous

7 years ago

Re: Don't use Google!!

Anonymous

7 years ago

Re: Don't use Google!!

Anonymous

7 years ago

Re: Don't use Google!!

Anonymous

7 years ago

Re: Don't use Google!!

Anonymous

7 years ago

I just wanted to thank you for all your hard work on bringing us Fedora users the Chrome browser. It says a LOT about Open Source that individuals can take a product like Chromium and do so much with it that a company the size of Google is either unwilling or unable to do. I just wish they would be more responsible members of the Linux/OSS community. They seem like such a bipolar company when it comes to Linux (in particular).
Only poofters use it!

-Ibod Catooga
I developed a fair bit of code in Java and honestly I do not see that much of what you give some concrete examples?

Deleted comment

Re: Java methodology ?

Anonymous

7 years ago

Re: Java methodology ?

spot

7 years ago

Re: Java methodology ?

spot

7 years ago

Deleted comment

Re: Java methodology ?

Anonymous

7 years ago

V8

Anonymous

December 1 2009, 20:58:35 UTC 7 years ago

Interesting post!

I have a comment about this part:

>> Google doesn't really treat v8 as an independent project. This is a shame, as the v8 code is pretty darned nifty, and it would be great to see it getting wider adoption outside of the browser space

Actually I think V8 *is* seeing adoption outside of the browser space. For example, I am using it in a 3D game engine (syntensity), and judging by the V8 mailing list, there are various other projects as well.

My experience with using V8 has been very good - the API is clear and things work well. Upgrading to new versions has been mostly hassle-free (even though internal APIs changed a lot, externally things are fairly stable). Also, Google actually makes an effort to help people use V8 separately, with docs about how to embed it, mailing list support, etc.

Now, it might be that V8 isn't truly independent of Chromium (what you said above) in other ways - I haven't worked with the Chromium codebase at all, so I can't know. But it is very much usable by itself.

- kripken
I think what spot is trying to say is that you can't really just install a libv8 in your system and have everyone share it, which essentially defeats the purpose of a shared library. You are probably shipping V8 inside your 3D game engine, which is not what should happen.

Re: V8

Anonymous

7 years ago

Re: V8

spot

7 years ago

Re: V8

Anonymous

7 years ago

I agree that Java developers have a predilection for including hacked-up version of third party code there is a semi-legitimate reason for it. Java APIs are almost universally awful, so getting any functionality out of a third party library pretty much requires horrible interface-breaking hacks.
Chromium doesn't just use a 'new webkit', it uses a very fundamentally forked WebKit, for their process separation magic to work. There is currently no WebKit shared library which would be fit for their needs. They just started contributing their 'port' to upstream WebKit, and maybe in the future you'll be able to build a separate libchromium-webkit from there, but tbh, separating that from Chromium will surely feel like separating Gecko from Firefox - anyone who had to deal with it knows it's not really a fun thing to handle.
your fictional sqlite-google exchange fails to account that chrome/chromium has very frequent updates, both for stability and for security. It is almost certain that it will contain forked libraries. Either that or deliver that critical update a month later.

also using sqlite as an example is interesting since the project has very limited manpower.

The big picture here is to put users first and then OSS. Upstreaming patches eventually happen.
"The big picture here is to put users first and then OSS"

If you don't put OSS first, you are not putting your users first either. You are just screwing them up.

Anonymous

December 2 2009, 00:48:27 UTC 7 years ago

You may have picked a bad example. My experience with sqlite_upstream:

[me] Hey sqlite upstream, I found a place where your library doesn't do what your documentation says it should do, and that makes it impossible to reliably do this thing we need. Here's a test case, and here's a patch to fix the bug.
[sqlite_upstream] The test suite already checks for this. Everything is fine.
[me] Hmm. Let me look at your test suite.
[me] Your test driver invokes your library in a way that will never exercise this case.
[me] Have you tried the test case I sent?
[me] Hello?

or:

[me] Hey sqlite upstream, I found another bug. Here's a test case, and here's a patch.
[me] Hello?

And so on. And that is why my project carries its own copy of SQLite.
Perhaps, but at least in your scenario, you could include documentation with a link to the bug that you filed with the sqlite upstream explaining why you have forked (and noting that when the bug is resolved, you'll drop your code-local copy).

I'm not advocating that forking should never ever be done, just that it should be an act of last resort.

Anonymous

7 years ago

security

Anonymous

December 2 2009, 14:28:03 UTC 7 years ago

One thing you do not mention is security. The problem with having your own forked copies that diverge from the upstream is that you are opening yourself up to possible security problems. Either security problems are fixes quitely (unintentionaly) in upstream that you do not merge (yes, that does happen, for example if you fix a bug you didn't realize was exploitable), or if your spagetti code exposes a new hole that doesn't exist upstream. New changes on the upstream are not made with your spagetti in mind, thus you can get unintended consequences.

As in chess, you ought to "watch the whole board to make a move." The upstream will not see your spagetti that touches their internals when they make changes. So merging changes from upstream will become tricky.

Different teams should have a well defined API between them, they should not play with each other's code. Otherwise you are asking for trouble. And with a browser, you are asking for security problems.
The problem with having your own forked copies that diverge from the upstream is that you are opening yourself up to possible security problems

Yeah, most of the Linux world learned that the hard way when a security hole was found in zlib some years back... before then, almost every package included their own copy, and had to individually release patches. Nowadays, almost everything uses a single system version.

Deleted comment

I'm not a big fan of compiler caching. I've seen it do weird and unpredictable things enough times to be wary of it.

Also, I'm rarely building the same source on the same distro/arch target pair more than once, and the actual chromium bits (as opposed to the bundled third_party bits) change a LOT between my checkouts. I'm not sure if ccache would save me any significant time or not.

However, if you've got the spare cycles and would be willing to try rebuilding my SRPM with (and without) ccache to get some benchmark numbers, I'd be interested in the results.

Deleted comment

That line right there completely contradicts everything else you said. Fedora is very well known (for better or for worse) for being extremely bleeding edge, and implementing very unstable software. So obviously there is another reason they are not adding it. Most likely the real reason they are not adding Chromium is because it just does not work correctly, period. Without changing the Useragent, Chromium is absolutely useless as a browser. Webpages do not render correctly, and when they do, you have to click 3 inches above or below objects/links to actually click them. Stick with Firefox.
Well, had you read everything else I said, you'd realize that I didn't mean stable as in "crashes a lot".

Chromium works very well as a browser, and I know quite a few people who are using it for their day to day needs.

If you are aware of websites which render incorrectly in Chromium, the upstream has been very responsive in addressing those issues, and I would encourage you to be productive and file bugs, rather than simply complaining, anonymously, here.

There is no other reason that Fedora has not added chromium, aside from what I've noted above. I have not submitted it for review, because I know it would not be approved.
Please don't ask for exceptions for chrome, even if its an exceptional browser.

I am resolving similar issues in our projects code base, and getting things in to debian and fedora has been a great incentive for other members of the team to understand that some Java practices (Most of the code base is Java) are not right for C based projects.

Thanks for the hard work, and I understand your frustration, but I think a calmer presentation of your views might help the Google folk agree with you, especially when they want their packages in debian and fedora, which they might well.

Cool, didn't know you were doing all this work! You might want to post some repos. somewhere:


% cat /etc/yum.repos.d/spots-chromium.repo
[spots-chromium]
name = Spot's test Chromium repo. for Fedora
baseurl=http://spot.fedorapeople.org/chromium/F$releasever
gpgcheck = false
enabled = true

I posted about how to make a repo for it when I started making the builds:

http://spot.livejournal.com/308900.html
Hi,

Thanks for all your great work. The only thing I have is that Inspect Element seems to be completely broken your latest update. Any ideas about that?
Didn't realize packaging Chromium is that much work. Much appreciated; it's SO much faster than Firefox that I switched over the moment I found your builds.

While it'll probably take a while before you can get the packages to Fedora, would you mind keeping the last few builds around in your repository? The latest one, 20091119svn32498 has some problems dealing with sites like Google Analytics, apparently due to the way it sticks data on the page for the embedded Flash and other visualizations. I didn't have this problem with the previous build, so I'd like to revert back, but stupidly didn't keep the files around..

Having a way to revert would also make it possible to try more builds, though I realize in this case the work is probably indeed in the packaging, rather than testing..

Thanks!
The problem is that the packages take up a TON of space, I had to have my people.fedoraproject.org quota increased by quite a bit just to get one set of builds to fit.

I'll ask them to double my quota again so that I can keep the previous build around, but we'll see if they are willing. :/
You overlooked the main reasons that Chromium's dependencies are compile time and not runtime:

1) Performance
By statically linking with our dependencies, there is much less work for the loader to do at startup, and thus Chromium starts up faster. Moreover by statically linking, we can take advantage of whole program optimizations at build time.

2) Quality Assurance / Stability
The configuration of dependencies used by Chromium receives exhaustive testing. See the right hand side of http://www.google.com/googlebooks/chrome/small_08.html for an example.

3) Security
The Chromium project is very quick to release security updates. Security issues may be sensitive to the version of dependencies used. Using a different configuration of dependencies seems unnecessarily risky.

Finally, Chromium developers do frequently send patches upstream to dependent modules. Notice that we carry no forks to WebKit, V8, or Skia. Those are all quite substantial opensource projects.

In some cases, as with sqlite, I think some of the patches were not accepted upstream, and more work would need to be done to get them into a state where they could be accepted. Given the low benefit to Chromium in these cases, it simply hasn't been a high priority.

I strongly encourage Linux distributions to stick with the tried-and-true Chromium build configuration. Breaking Chromium up into a multitude of independently versioned shared objects might satisfy some goals, but it really misses out on some significant advantages. It's asking for trouble and degrades the overall quality of Chromium.

Regards,
-Darin
Hi Darin.

1) I've heard the performance arguments before, but they simply aren't true. There may be a minor difference between startup times, but it is statistically insignificant. And really, startup time isn't a useful performance metric, what you really care about is page rendering, javascript benchmarks, that sort of thing. I did testing comparing a stock, static compile of chromium with the Fedora builds that are using shared libraries... and the Fedora builds consistently performed faster on the standardized benchmarks. I sent this data to the Chromium team, and to date, no one has been able (or willing) to refute those results.

2) The amount of testing that Google is able to provide, while arguably significant, is not as large as being able to leverage the amount of testing done in the larger FOSS community. By not bundling, you could have both.

3) Again, the fact that Google is currently invested in tracking all third_party bundled bits for security vulnerabilities is good, but what about in a year? In two? Five? The Linux distributions are able to track vulnerabilities in the components that they ship, but "submarine" components embedded inside other components are the real concern. Basically, your argument boils down to "trust us", when if you were handling it in a non-bundled fashion, we wouldn't need to, aside from the Chromium code where you are legitimately considered the upstream.

As to forks, your WebKit|V8|Skia code is not technically a fork, but your code pulls a specific revision snapshot and bundles it in. This revision generally keeps up with the latest code, but in the case of V8, it has historically lagged behind, which causes the V8 in chromium to be effectively a point-in-time fork. The only reason that V8 and Skia are even remotely sustainable in this use case is because Google is the controlling upstream for those projects. With WebKit, it mostly works because the Chromium team (at least some members) have direct commit access to WebKit, so the end result is the same.

Finally, to your last point about "encouraging Linux distributions" to not "ask for trouble", given that your 3 main points aren't really valid, I think it is safe to interpret your summary as FUD.

There is no real loss to properly working with system components, and in fact, there are significant gains from both performance and maintenance perspectives.

Anonymous

December 7 2009, 06:00:39 UTC 7 years ago

Just a fyi, the intensity engine uses v8 for it's scripting. So it's existing outside of the chrom- space, and browser space even.
Even more reason why Google should treat V8 as a proper, independent project, with stable code releases (major and minor) and API tracking.

Anonymous

December 9 2009, 06:01:41 UTC 7 years ago

I had thought the at the point of integrating the libs was to allow updates to the browser to be pushed and integrated even if/when the OS itself was not? If so, then I can see the point: Chromium remains is protected independently from the OS and therefore Google protects its reputation.
If I keep my system up2date with all the latest vendor-supplied fixes, then Google's integrated libraries do not help me at all in fixing security and other problems.

If I do not keep my system up2date with all the latest vendor-supplied fixes, then Google's integrated libraries do not help me at all in fixing security and other problems.

In either case, I will apply all the updates or none of them.

I run CentOS for my daily computing. I do not willingly install non-standard software to it. If I want PHP, the version of PHP I install is that shipped with the relevant release of CentOS. If your software uses some newer version of PHP, I am very unlikely to use it.

I do have a Fedora system, but I'm not keen on breaking that either. If Chromium doesn't work with standard Fedora libraries I don't want it on my Fedora, and if it does not work with the standard libraries of the version of CentOS I use, I don't want it their either.
http://neugierig.org/software/chromium/notes/ - more about licences but kind of details what the changes made to subprojects were and what attempts have been made at upstream merging...
Previous
← Ctrl ← Alt
Next
Ctrl → Alt →