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."
There's a feature of the kernel that Chromium wants to use. That's a perfectly good reason to upgrade.
User software should dictate kernel versions.
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.
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.
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.
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 agree that it's the Chrome team's prerogative to decide that supporting those kernels is unimportant.
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.
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.
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?
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.
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.
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.
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.
Apparently, Ubuntu 14.04.2 installs a 3.16 kernel by default, and previous 14.04 installs can be updated by installing a bunch of "*-utopic" packages.
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.
[1] https://wiki.ubuntu.com/Kernel/LTSEnablementStack#Kernel.2BA...
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:
https://wiki.ubuntu.com/TrustyTahr/ReleaseNotes/ChangeSummar...
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.
Edit: oh, wait, this starts in the next version.