LWN: Comments on "Debian squeezes out Chromium"

Debian squeezes Chromium back in

zack — Mon, 04 Oct 2010 13:18:11 +0000

As of today, chromium is back in Debian Squeeze (which is not released yet, but still in freeze) http://packages.qa.debian.org/c/chromium-browser/news/201...

The lesson to learn here is that, as long as Squeeze (or any other Debian suite, FWIW) is not released, there is still a margin of variability in the software it contains. If that margin weren't there, then the suite would have been released in the first place. The point of a freeze, in Debian, is to stop package acceptance in the suite *by default* and undergo a thorough scrutiny of what goes in and what gets out.

On stability

robbe — Thu, 16 Sep 2010 14:57:17 +0000

The kernel community (Greg KH, with much help from others) do release updates to certain kernels, essentially creating upstream-supported stable branches.

I cannot see Firefox or Chromium upstream doing that. They seem to jettison support for older version once the new one is out.

Another difference is that the big distros seem to fund quite a bit of manpower working on the kernel. How many people have their Firefox/Chromium work paid for by a Linux distro?

Debian squeezes out Chromium

Lennie — Thu, 16 Sep 2010 13:49:01 +0000

It all sounds a bit like http://www.debian.org/volatile/ as well

On stability

Trelane — Mon, 13 Sep 2010 18:03:24 +0000

They also added support for Cairo 1.10 in trunk last week. This brings a lot of improvements in the longer-term, but is trouble in the short (my build system now needs retweaking).

On stability

gerv — Mon, 13 Sep 2010 16:19:04 +0000

The evolution of the web platform. In the past fifteen months, Firefox has added at least the following major features:

* Web fonts
* Vast improvements in SVG support
* Major speed improvements for JavaScript (JITs and other magic)
* Out of process plugins, to stop Flash crashing your browser all the time (which required a major internal rearchitecture)
* Profile sync
* Large chunks of HTML5 and CSS3
* Rendering system changes to support mobile and GPU-accelerated graphics

You can't do this with small patches on top of a stable base.

Gerv

On stability

giraffedata — Fri, 10 Sep 2010 23:43:31 +0000

A new release may add features, but the web being what it is, it's rare for browsers to break compatibility with existing sites or web applications.
Actually Opera 10.60 sometimes crashes on gmail, so I went back to 10.10. Bug report was sent.

I assume accidental incompatibility, which this surely is, isn't what the OP had in mind when complaining of compatibility-busting updates.

One thing I thought of when I read that is compatibility with user procedures. If the user knows how to use Opera 59, will he be able to use Opera 60 the same way? In the eight years or so I've been using Opera, both on Linux and Windows, I've upgraded two or three times and each time features I used disappeared. Sometimes they disappeared for good; other times they went into hiding, bound to a different key or something. Consequently, my policy now is not to upgrade. If I were using a system where updates were essentially mandatory, I'd be pretty bothered.

On stability

nevyn — Fri, 10 Sep 2010 21:03:48 +0000

2.2 now, I guess. I bought it in Feb. and hit the update button whenever it told me to (which, as I said, is like 4 times).

The apps. on it are even worse, it was a significant timesaver when the last OS update now allowed me to turn automatic updates on for them.

Well, yeah.

njs — Fri, 10 Sep 2010 20:57:00 +0000

Sure, but one result of those millions of lines of javascript is that developers are running into limitations of the web platform; the platform has to change if it wants to be competitive with Flash/Silverlight/etc.

On stability

bronson — Fri, 10 Sep 2010 18:31:06 +0000

> Release engineering and stability is something old people talk about.

True! I nominate this for a quote of the week.

On stability

jspaleta — Fri, 10 Sep 2010 16:57:43 +0000

Which version of Android are you running? 2.1 as originally shipped or did you upgrade to 2.2?

On stability

nevyn — Fri, 10 Sep 2010 15:24:06 +0000

> Do you really think that ChromeOS is going to have a browser with this
> sort of rate of churn?

Yes. Look at the Nexus One, that has had ~4 download and reboot OS upgrades in the 6 months I've had it.

Release engineering and stability is something old people talk about.

Automatic upgrade of backports

wookey — Fri, 10 Sep 2010 12:06:47 +0000

Maybe we should just stick chromium and iceweasel into volatile and have done with it.

Well, yeah.

ras — Fri, 10 Sep 2010 02:23:04 +0000

> there is a lot of change in the de facto standards.

I disagree. The de facto standards trail the real ones by a large margin.

That is because the de facto standards are to a large extent determined by the oldest browser in use. Until very recently IE 6, which was released in 2001, and it didn't comply with the existing standards in force back then. Google and Facebook only just stopped supporting it.

This "the browsers must change because the web is changing" thing is a complete furphy. Certainly the web is changing. But that is because people are writing millions of millions of lines of javascript as they figure out how to use this "new" platform. But just because the stuff we build on top of the underlying platform changing at a dizzying rate doesn't mean the platform itself must be changing. On the contrary, it hasn't, until now with HTML5. Inventing new ways to do web pages no more depends on HTML/javascript change than the advancement of the linux kernel depends on gcc changing.

Well, yeah.

iabervon — Fri, 10 Sep 2010 01:49:14 +0000

Actually, the practical effect of the standards being such a pain is that, despite there not being new blessed versions of the standards documents, there is a lot of change in the de facto standards. This includes things that have always been in the standard, but which nobody previously expected to work. It also includes things that were never specified, but where enough popular browsers did something sensible and the same that people came to rely on that being available. Just because nobody wrote up standards documents of what was expected for a while doesn't mean that the de facto standards didn't keep changing.

Well, yeah.

ras — Fri, 10 Sep 2010 00:38:20 +0000

I don't think it is the web. Yes, HTML 5 is pushing things along a bit now. But the last major revision was HTML 4, which was released in 1998. That is hardly a frantic rate of change. Ditto for the other major underlying standards - CSS, SVG, Javascript. WebM has nothing to do with it - it is just a codec, a plugin.

I can think of two reasons for pace browsers are developed at. The first is because it is a monumental task, and when you are undertaking a monumental task break it down in to small bits and release early, release often, otherwise you will be overwhelmed. This is because, as standards go, those published by W3 are real pricks. We have enormous teams of programmers implementing them. As I said they haven't changed much in 12 years, yet a seemingly simple thing like rendering ACID3 correctly is a huge challenge. This is what happens when you publish the standard before writing the code. The IETF's policy of producing working code then publishing the standard is how it should be done. The difficulty in implementing a fully compliant HTML, CSS, and SVG are great examples of why it should be done that way.

The second reason is to do with marketing. I used to use, and still occasionally use Firefox 1.0.1. It has UI bugs, it crashes, and it renders things badly. But it was fast, and if they had just fixed those bugs I would be happy running it today. (Although maybe not for much longer, given the advent of HTML 5.) Fixing those bugs didn't require millions of lines of code to change every few months. What does require a new release every few months is a mindshare competition. (Why do you think Ubuntu does it?) What triggers most of those millions of lines of changes is new eye candy - something like rearranging the tabs and title bar, or the introduction of an "awesome bar".

So it is a combination of those two things - the size of the task means implementing a web browser will take 100's if not 1000's of man years, and that means a steady stream of releases as you do it. This is not unlike we see with the kernel or any other large project release. We know Debian can handle that. But them you mix those necessary changes with avalanche of bubble and froth created by a mind share competition - ie change for no reason than it generates publicity, and you become incompatible with a distribution that values stability over most over things.

On stability

jspaleta — Thu, 09 Sep 2010 22:52:49 +0000

look at it this way. Google has a master plan for its Chrome browser that quite frankly does not include the needs of other linux distributions or their users. Chromium the project has a codebase which is the leading edge of that plan for Chrome the product.

Do you really think that ChromeOS is going to have a browser with this sort of rate of churn? The rapid rate of development for Chromium right now has a lot to do with Google's overall plan for its own product line. They have real consumer device targets in mind for Chrome and ChromeOS and what you are seeing is the development run-up towards very specific end-goals.

Lets face it, other linux distributions are not the target audience and are not driving the development curve. But the development curve does make sense if you look at stable ChromeOS deployments as the end goal for the rapid development push that is going on now with Chromium. We can get as mad as we want about the reality of that, and its not going to make any difference at all.

-jef

On stability

roelofs — Thu, 09 Sep 2010 21:54:08 +0000

As far as I had understood both "roelofs" and "ringerc" were complaining about release speed, the time a release is maintained, and new features bringing new bugs.

Yup.

AFAICT that has nothing to do with bundling of libraries.

To the extent the bundled libraries are modified, it certainly does. And even where they're not modified, the mere fact that they're additional copies means extra pain when security issues affect (or may affect) them--particularly when the browser version is no longer maintained by upstream.

But that discussion is more relevant to an earlier article.

Greg

On stability

roelofs — Thu, 09 Sep 2010 21:41:16 +0000

What do you mean by 'compatibility-busting'?

I meant more or less what the article was talking about, at least in part--i.e., the bundling of custom, system-incompatible libraries/toolkits such as Chromium and Webkit. (Other articles have covered Firefox's bundling and occasional forking of system libraries, not to mention its API disaster called "xulrunner.") But beyond that, there's the issue of "self-compatibility," which is what's relevant to the backporting of security fixes. Granted, it's unusual to ding a project on the pace of changes to its internals, but then again, in today's desktop systems there's no greater attack surface than the web browser (and its dependencies). Firefox's never-ending stream of vulnerabilities makes 1990s sendmail look good.

I'm not a complete luddite; I get the need for apps that are as central to the user experience as browsers are to innovate, add features, etc. But with that great power comes great responsibility--i.e., to make the browser significantly more secure than the average desktop app--and I'm not seeing an acknowledgment of that responsibility. Indeed, the short support cycles and general level of code churn that limits the ability of others to provide such support are arguably an abdication of that responsibility. (And, for what it's worth, I really don't see a need for the feature cycles to be so rapid. What are the appalling omissions in, say, a 2007 browser--or even a 2009 one--that are blocking the deployment of critical new web stuff?)

Note that nothing I've said implies that distributions should not be able to package newer releases if that's what makes sense for them. My beef is with the other end, i.e., development practices that penalize those distros (or end users) that don't want to upgrade more than once every couple of years.

Greg

Debian squeezes out Chromium

mjthayer — Thu, 09 Sep 2010 19:34:48 +0000

> Who maintains the seucirty fixes in the bundled copy of webkit in chromium? Google?

In my picture yes. It is their choice to bundle a library and assume the responsibility for it rather than use the system version. And the distribution will do stability testing and supply upstream with fixes as now, as far as upstream plays responsibly, and at the same time they will provide their users with the information they need to judge how much of a security risk they are taking by installing Chromium. And Google will no longer have the distribution conveniently taking responsibility in front of the user for the security aspects of their (Google's) decisions.

Automatic upgrade of backports

ametlwn — Thu, 09 Sep 2010 17:55:28 +0000

Currently, packages that come from backports do not get automatically updated when doing an apt-get upgrade (or its GUI equivalent).

This is fixed easily by adding

Package: *
Pin: release a=lenny-backports
Pin-Priority: 200

to /etc/apt/preferences. It is the recommended setting for using Debian backports, see the official instructions.

Debian squeezes out Chromium

tzafrir — Thu, 09 Sep 2010 17:54:31 +0000

So no problem with Chromium bundling WebKit, which is on its way to become a "system library"?

Who maintains the seucirty fixes in the bundled copy of webkit in chromium? Google?

On stability

josh — Thu, 09 Sep 2010 17:05:27 +0000

That's what "unstable" versions of distributions are for; users of those distributions will happily do the testing for you, and report a pile of bugs either upstream or by way of the distribution. That still doesn't explain shipping the (modified) source code to umpteen libraries in the application source tree.

"Handling things correctly" doesn't mean "test with every obscure Linux distribution", or even "test with the top N distributions". It means "make sure it builds in whatever reasonably up-to-date distribution the developers run, handle shared library versioning sanely, document the list of build dependencies, let Linux distributions package it, and work with them when they report bugs to you".

On stability

foom — Thu, 09 Sep 2010 17:04:42 +0000

New firefox requires new xulrunner and rendering libraries, which are not always compatible, and may require recompiling all dependent applications. If it was only firefox and thunderbird, and nothing else used the rendering engine, then sure, you could simply upgrade to the latest version without thinking. But there's other *desktop* apps involved too...

Well, it's a race...

smoogen — Thu, 09 Sep 2010 15:53:33 +0000

History of things:

Microsoft Explorer was originally Spyglass Enhanced Mosaic. Spyglass was a company whose idea was that by making browsers companies could specialize then it could get into the corporate market versus the consumer market that Netscape was focused on. Problem is that consumer markets move very very quickly and corporate ones do not. So Spyglass ended up in a game of catchup with its 5 programmers against Netscapes 20. However, Spyglass thought it had an ace in the sleeve with a deal with Microsoft.. until they realized that Microsoft could hire hundreds of engineers to rework their source code.

IE1->IE4 were mostly Spyglass code with lots of additions from Microsoft. IE5 was mostly Microsoft with some stuff from the remains of Spyglass (who had gone away in 1998 or so because they had not asked for a per copy payment from Microsoft in exchange for the source code... ) I have been told that sometime after Microsoft reached 90%, they repurposed most of the engineers working on the browser to other projects thus the slow down of 'features' until Mozilla restarted the race.

On stability

ringerc — Thu, 09 Sep 2010 15:39:17 +0000

In truth I really like rapid releases - for desktop software on home machines, and in development tools/libraries. Bugs in software I use myself I can work around or fix, or I can roll back to an older version until the issue is fixed in a later release.

It's only when I have my sysadmin hat on and am responsible for the reliability of a network of machines used by other people that I start to want stability and time to fix things before the next update breaks everything all over again. Even then, I still really like rapid releases ... it's only when they're accompanied by the total abandonment of any support for any older releases that they bug me.

I do think FF and Chrome may be rushing into the future a little *too* fast - not in the sense of improving too rapidly, but in being unwilling to keep a release or two around for at least security fix purposes.

Debian squeezes out Chromium

patrick_g — Thu, 09 Sep 2010 15:19:37 +0000

According to the FAQ there is no security support.

Debian squeezes out Chromium

rhertzog — Thu, 09 Sep 2010 14:10:15 +0000

This article comes out one day after the removal of squeeze and assumes the decision is final. It would not be the first time that a package reenters testing once the situation is clarified and when the security team confirms that it is able to provide some security support for it.

Moritz Muehlenhoff of the security team just confirmed that they were planning security support for chromium much like they do for iceweasel:
http://article.gmane.org/gmane.linux.debian.devel.release...

And the chromium maintainer also accepted to backport security fixes once v6 is no longer the current stable version for upstream. I hope it will get back into squeeze before the release.

This is an internal communication failure from Debian and it becomes an external communication failure because the maintainer was frustrated (because Julien Cristau removed the package and gave no explanation to the maintainer) and blogged and you picked up the news very quickly (maybe too quickly).

On stability

nicooo — Thu, 09 Sep 2010 13:29:25 +0000

The excuse for bundling libraries was that it helps them release faster.

On stability

fb — Thu, 09 Sep 2010 12:14:22 +0000

>> When it's the Linux kernel release cycle, the words "release early, release often" come to everyone's mind, and the release speed is something of a lesson to be learned. An achievement of excellence with regards to software development.
> The kernel doesn't bundle 17 different libraries.

How is that related?

As far as I had understood both "roelofs" and "ringerc" were complaining about release speed, the time a release is maintained, and new features bringing new bugs. AFAICT that has nothing to do with bundling of libraries.

Debian squeezes out Chromium

Trou.fr — Thu, 09 Sep 2010 11:56:14 +0000

On a not-completely-related note, now that backports are "official", I couldn't find any word about security updates for them. Any idea ?

The problem is even visible with short distribution cycles

cdamian — Thu, 09 Sep 2010 11:05:59 +0000

With Fedora for example it happens that a new Firefox is released just after one of 6 month Fedora cycle releases. So users have to live with an "outdated" browser for half a year.

And on the web six months is a long time. There are repositories for Firefox and Chromium which always contain the newest version, but these are usually not as well tested as the distribution packages.

On stability

nicooo — Thu, 09 Sep 2010 10:37:18 +0000

> When it's the Linux kernel release cycle, the words "release early, release often" come to everyone's mind, and the release speed is something of a lesson to be learned. An achievement of excellence with regards to software development.

The kernel doesn't bundle 17 different libraries.

On stability

djm — Thu, 09 Sep 2010 10:36:04 +0000

Hear are two good reasons for FF and Chromium's rapid release cycle: 1) fixing security problems (these are large and complex application by necessity). 2) Adding new features, since the web platform is still evolving fast.

The alternative to this, as you correctly identify, is Internet Explorer. A browser that substantially lags FF and Chromium in standards compliance, features and in which very serious vulnerabilities are not fixed _for years_ because of the engineering difficulties in doing so.

On stability

NAR — Thu, 09 Sep 2010 09:29:20 +0000

A new release may add features, but the web being what it is, it's rare for browsers to break compatibility with existing sites or web applications.

Actually Opera 10.60 sometimes crashes on gmail, so I went back to 10.10. Bug report was sent.

On stability

fb — Thu, 09 Sep 2010 09:06:09 +0000

> or simply because they don't care about handling Linux correctly and the least common denominator requires shipping everything with the application.

There is also the fragmentation that makes handling things correctly harder. From the perspective of the software vendor "Desktop Linux" is a blip in the radar, and a very fragmented one. (How many Fedora, Ubuntu, Suse, Debian etc versions are there to test against?)

The software vendor can rationally decide that there will be less users hit by a bug if they put even more resources testing it on Windows and MAC/OS than trying to test things on this large matrix of different Linux distributions and all their versions in use.

Stability of Chrome on Ubuntu

MisterIO — Thu, 09 Sep 2010 08:51:21 +0000

Actually Chromium 6, which is in Debian Unstable, works better than Chromium 5.

On stability

fb — Thu, 09 Sep 2010 08:51:05 +0000

> what makes Firefox and Chromium so special that they have to pop out a major new, compatibility-busting release every few months? Internet Exploder certainly doesn't; Safari doesn't (AFAIK); and neither does Opera (also AFAIK). This seems like a classic case of cranio-rectal impaction on the part of upstream.

When it's the Linux kernel release cycle, the words "release early, release often" come to everyone's mind, and the release speed is something of a lesson to be learned. An achievement of excellence with regards to software development.

Isn't the same thing that Firefox and Chromium are doing? Releasing early, and releasing often?

[...]

Firefox and chromium development cycles are focused on desktop users.

The position of "stability" in the priorities of many Linux distributions are IMO based on a "server room mentality": stability cannot be at _any_ risk, and there is a sys-admin. If new features are needed, the admin will manually do something about it.

Desktop users, in general, live a different life: (i) there is no "professional full-time admin" for the box (it must "just work") (ii) the whole point of that computer is to browse the internet, print flight tickets, and use VoIP. They need the features, and _some_ stability risk is an acceptable trade off. It just so happens that most desktop Linux users are comfortable as sys-admins.

Off-topic: FWIW _all_ desktop Linux users I knew during my PhD who were not comfortable as sys-admins are now MAC users. Every time I asked for the reason to migrate (these were people who had Linux installed at home) the answer was (in essence) that MAC/OS didn't require them to play sys-admin in order to get things to work.

On stability

epa — Thu, 09 Sep 2010 08:46:51 +0000

What do you mean by 'compatibility-busting'? New Firefox releases (and, I assume, Chrome and Chromium) have pretty good compatibility with everything except old plugins. A new release may add features, but the web being what it is, it's rare for browsers to break compatibility with existing sites or web applications.

That is why most distributions, including the commercial ones with long support windows, are happy to package the latest browser versions as they come out. Keeping your users on the same four-year-old browser (with only security fixes backported) is not long-term support worthy of the name.

Debian squeezes out Chromium

mjthayer — Thu, 09 Sep 2010 08:18:18 +0000

I think that this is partly the result of a couple of inconsistencies in the FLOSS/Linux distribution model. Distributions can't decide whether they want to be packagers or downstream developers and end up distributing massively patched pieces of software. And they try to cater to users who want a stable distribution with long-term support, but who still want Chromium and Firefox (probably many even want the latest versions). Nothing wrong with that of course, no one is asking humans to be robotically consistent and logical, but you have to decide where to stop. And it sounds like Debian is moving that way too.

It would be lovely to see a more tiered distribution, with a base set of packages for which the upstream is known to be reliable at maintaining stable releases and quick to apply patches from downstream (that way distributions can patch upstream directly and adopt new bug-fix releases faster in the knowledge that upstream is not likely to put silly things into them) and other packages sorted according to how reliable upstream is known to be, but still adopting upstream's bug-fix releases reasonably fast (or new major releases for more difficult cases like Firefox and Chromium). Then the user can make their own informed choices as to what they install.

I think that my other dream would be for the packaging to be maintained upstream as well (though probably by distribution people), so that when a new version is to be pulled in, distributions can just examine changes and build.

Stability of Chrome on Ubuntu

Cato — Thu, 09 Sep 2010 08:10:09 +0000

Very topical, since the Google Chrome 6.0 that I got from the Google repositories segfaults on startup with Ubuntu 8.04. Not what I expect from a stable browser, and Google Chrome 5.0 works fine.