Chrome "unofficially" dropped support for pre-3.16 kernels, such as the kernel in Ubuntu 14.04 LTS, about half a year ago. More precisely, they introduced a bug that caused installing extensions to fail with that kernel, and then declined to fix it.
See comment #47: "Ok, while it sounds like this is technically a regression, I'm going to mark this as Wontfix because there is a reasonable workaround of updating your kernel."
Linux 3.16 is 7 months old. The attitude of the Chrome team is extremely obnoxious. Some distributions support versions 10 years and beyond and there are plenty of reasonable reasons to want to use them as such. Requiring a 7 month old kernel is absurd.
I keep getting the feeling that Chrome isn't the browser for me.
Without defending Chrome team here; when a distro provides long time support (say > 1 year) I don't think is upstream responsibility to support the packages for that period of time.
If the distro is upgrading the browser package I think that may break the API/ABI stability that a long time support distribution should provide, so I can't see why this is a Chrome problem.
Also it sounds wrong that a web browser depends on the kernel version; so I'm with you that there are other browsers supporting Linux.
I'm sorry, but we ARE talking about arguably the most important piece of software running on an end-user device not being supported on a less than ONE YEAR old distribution. Not 5 years, not 15 years. Less than a year.
The result of your argument is basically returning to dark ages of having to support old broken IE6 because the vendor couldn't be arsed to support an older platform. When did dropping support for a less than a year old product become something to be applauded?
My argument is that open source is what it is. Read the license and you'll find that there's nothing about free support; and if for some reason it breaks... you keep both pieces.
I know this puts distributions in a bad situation, but unless the users can force the upstream project to be more user friendly, I think the only option is to switch to a different software (hint: Firefox).
You seem to think I endorse Chrome team's behaviour on this, and I don't. That doesn't change reality though.
Open source is what it is, but not all open source is equal.
I often see versions of this argument more or less opposing complaints against open source products. It has some merit, depending on circumstances. Circumstances are important.
Chrome isn't some guy's spare time project, or something done by a team of corporate and personal volunteers. Chrome is a product. Looking for Google's valuation comes up with an analysis that it will likely be the first or second company to be valued at a trillion dollars. Chrome enjoys nearly a 50% browser market share. Google has one of the strongest hands in shaping technology today, and it seems they aren't always making the best decisions; not that one would expect such a large company to always make the best decisions (or that there would be a consensus on _what_ is the best decision).
I've never paid for anything made by Google, but I am a customer regardless; so are you. Money hasn't changed hands but they have certainly profited from the relationship, and so have I.
---
"If you don't like it, submit a pull request" -- that response always rubs me the wrong way. To be clear, some of the loudest complainers about open source projects are entirely too entitled, but those that aren't do have a point sometimes. I believe that whether you are a guy with a hobby making $0 or a company valued at $3.8 * 10^11, you owe it to yourself and your users to maintain a certain level of quality if you create a popular product. More of a personal philosophy than the expectation of a legal obligation of course, but I think just as valid.
I always have mixed feelings when Google has a project with two versions: the open source one and the binary only based on that one. Chrome and Chromium are not quite the same thing after all.
I don't know for sure, but for Google Chrome may be the product and Chromium just a convenient way to make it happen.
Well put. Although someone makes a LTS distribution, it really does not mean 3rd parties would be compelled or required to support that steadily aging platform.
When you combine the fact that not even Ubuntu developers really support the LTS (9/10 of the developers flock to the newest release, and the bug reports towards LTS get generally ignored - the LTS tagged bug queues are graveyards), I can not see the whole point of making LTS version available in the first place.
That being said, 7 months is a bit small window of support for a specific platform component. I would understand not supporting 1-2 years old kernel/glibc/whatever, but 7 months is really not enough.
Well it's tricky, MSFT actually ties certain vendors to support their OS as long as it's under support. For example if you want to participate in the WHQL program you have to have a version for each supported MSFT OS.
Chrome is still supported on Windows XP, so is FF, on Windows vendors not only do not seem to drop support but actually extend beyond MSFT's requirements.
While canonical is surely not MSFT but when you make an LTS program you either have to get 3rd party vendors on board, or manage and update the packages yourself to make sure they will be compatible with your own software, or to make updates to your LTS distro to keep it compatible with the newer packages.
While the OS is quite important, it's usually not the piece of software neither end users nor corporate users care about, for them it's just a platform to run the software they actually use. And if the platform loses support for a major piece of software after less than a year you can't blame anyone besides the maintainer of that platform.
The Linux community really needs to get their shit together, with every step forward these past few years they've seen to be taking 2 steps back.
With PAAS becoming more and more popular, it really should only take Apple to release a general server OS (no OSX Server doesn't count) to push it back completely into the realm of BBS hobbyists these days.
What about XP? It's old, unsupported and littered with security holes. It has 50% penetration in China because it's the last version of Windows with easily circumvented piracy countermeasures and because it runs better on 10-year-old hardware. I don't think it's any guide to how long long-term support should be.
Well, it's a bit more subtle than that. Because it were the Chromimum developers which created the feature in the first place.
seccomp was introduced in the Linux kernel because the Chromium developers wanted a good way to reduce the harm Chromium browser processes could do if they got compromised.
Chromium is pretty much the only user of seccomp right now.
(although for example Docker also has support for it, but I don't think it's widely used)
Now Kees Cook who implemented TSYNC for seccomp in the Linux kernel works for Google. The kernel commit even lists his @chromium.org email address.
No, user software should not dictate kernel versions, unless there is no alternative (e.g. security issues). Maybe I'm unique in this, but I don't have a single-purpose workstation. My computer does not exist to run Google Chrome; I have lots of applications I like to use.
Consider a workplace setting where someone may have other software which is much more conservative about using new features. A newer kernel may cause that software to stop working entirely; upgrading a kernel rarely introduces just the feature Google Chrome wants to use. You could tell those people to just use a different browser, but there are a lot of workplace users - is this new feature right now really worth losing those users?
For all the effort the Linux community has put into keeping Linux distributions secure and making them easier to use, now Google is saying Linux users have to either know how to update their kernel outside the provided package manager to use Chrome, or use whatever older version of Chrome still supports their kernel. This is going to frustrate or alienate most new Linux users as well as veteran users who like stability and package management. Is using this new feature right now really worth losing those users as well?
Chrome is arguably the most popular browser on the Internet. They ought to be more conservative about things like this; the right way to handle a new kernel feature is to either delay its use until supported by the majority of your users, or to detect it at runtime and use it if available. IMO, what they have done here is lazy and arrogant. A very poor decision.
Agreed, though I doubt this is going to be a popular opinion. I've been steadily divesting myself of pretty much all Google products because of these sort of arrogant and obnoxious decisions.
First it was the won't fix VPN + countless other Android bugs, then repeatedly breaking Canvas in Chrome (why do I care about this? well Chrome auto-updates for 99% of users, so when they break canvas they're breaking sites) and not least the numerous platforms and products they introduced and then dropped despite vibrant & loyal user bases.
First, I'll note that plenty of people use Chrome without extensions. This issue wasn't a showstopper for any of them.
Second, you cut out the rest of the comment:
"If that causes great hardship for anyone and you want to do the work to figure out what's going on submit patches to fix it, I can provide pointers for where to start looking and code reviews for the patch."
Since that comment has anyone done anything other than updating their kernel and/or complaining? If not, why would the Chromium team think this issue was important?
I don't think the other half of that comment affects my point: that the Chrome team is declining to fix bugs that only manifest on older kernels, and hence it's reasonable to call those kernels "unsupported".
I agree that it's the Chrome team's prerogative to decide that supporting those kernels is unimportant.
So you only care about problems if the user is a skilled developer, and then only if they're actively solving the bug (because skilled programmers are never involved in other projects eating their time...)?
This seems like a colossal mess waiting to happen. I'm glad that I read their plan, so that I can completely avoid it.
The allure of Ubuntu LTS releases (currently 12.04 and 14.04) is the extended support cycle -- practically speaking the kernel is the biggest component of this for a lot of people.
If you use the 3.16 kernel (from Ubuntu 14.10) on 14.04, you are now on a 6 month support cycle [1]. One which doesn't even have defined dates (they're all still TBD). Now you have to keep running on the kernel upgrade treadmill to maintain support, moving to backported kernels from progressively newer Ubuntu releases every 6 months.
> practically speaking the kernel is the biggest component of this for a lot of people.
Really? I mean, step back from your initial gut reaction and ask yourself how many software developers could even name which version of the kernel their code runs on without checking. Most developers never make a syscall directly and, increasingly, aren't even calling something like libc directly because they use higher-level libraries.
Sure, some people really care cause they recently hit an issue with specific drivers and a few people are using a really new feature, but that's a much smaller group than the number of people running code which doesn't even depend on Linux, much less a specific point release.
Looking at the release notes, I'd say there are a LOT more people affected by real bugs which are fixed in 14.04.2 than will be affected by hypothetical bugs nobody seems to have noticed yet:
Overreacting much? The shortened support is limited to the packages you upgrade. It's a 9 month cycle with a new version available every in 6 months. Most importantly, these are just packages, they can be uninstalled of they don't work and you fall back to LTS versions. And this is all the same for 12.04.
For some reason, Chrome seems to work fine with extensions on my Ubuntu 14.04, kernel 3.13.
I agree with those saying this is completely stupid. In corporate environments, there are a lot of Ubuntu LTS, RHEL, and CentOS desktops. They won't be upgraded to >= 3.16 for years.
https://code.google.com/p/chromium/issues/detail?id=401655
See comment #47: "Ok, while it sounds like this is technically a regression, I'm going to mark this as Wontfix because there is a reasonable workaround of updating your kernel."