12 ms·

Google Chromium drops support for Linux 3.16 and earlier

139 points by xai3luGi 12y ago

tbrownaw 12y ago
It's much more interesting to see how useful the replies are. I assume they're because it's a dumb question, but still. This is an excellent example of an unwelcoming / hostile culture.
- axlprose 12y ago
  Indeed. The culture was part of the reason I made the switch from debian to opensuse a while ago.
jpgvm 12y ago
Replies so far for the lazy: On Sat, Mar 07, 2015 at 07:17:13PM +0200, Georgi Naplatanov wrote: > On 03/07/2015 06:38 PM, Ben Hutchings wrote: > > On Sat, 2015-03-07 at 16:09 +0100, D. F. wrote: > >> Hello, Julien Tinnes from google says that next releases of > >> chromium will drops support for kernels without TSYNC > >> ubuntu 14.10 already has been patched > >> Can I to expect that debian 8/jessie will have support for > >> TSYNC? > > Sounds like another good reason to not use Google spyware. > Google Chrome for Linux is the only possibility to use latest version > of Adobe flash player for Linux as far as I know. another good reason not to use it. -- maks I guess this is why Gentoo is still my distro of choice after all these years.
- redthrowaway 12y ago
  That seems like an exceedingly childish exchange.
  - krick 12y ago
    It's common way to see things now, although I guess it's pretty normal. I always viewed distro as something people do primarily for themselves, if you want something from particular distro — you join the community. If your wishes are drastically different from what this community accepts — you go to another community or build your own. I'm not saying people should be rude and talk nonsense, but it seems that too many people tend to forget: Debian mailing list (or lkml, or what else people complain about) is not Starbucks or McDonalds where people are paid to smile and do what's requested. That's been said, I find question about TSYNC completely appropriate, and its support to be expected, but answer about "Google spyware" was funny and enjoyable anyway. So, yeah, maybe childish, but not "exceedingly childish".
  - stingraycharles 12y ago
    I cannot believe these are the actual people responsible for Debian. Is this unprofessional attitude common in the Debian community?
    - eropple 12y ago
      No. More than it used to be, but it's not comon.
    - xai3luGi 12y ago
      Could you explain what you mean by "unprofessional" here? Personally Google's business model seems to be the unprofessional thing in this conversation.
      - jfoster 12y ago
        If Debian were a business and the original poster were one of their customers, how would the OP be feeling about that exchange? It's unprofessional by definition because it is so clear that the person responding does not consider this their profession.
        adrusi 12y ago
        But it's not a business and that person wasn't a customer. Debian is a community, bound partially by common technical ideas about packaging, stability and security, and partially by philosophical ideas about Free software. Their goal is not to satisfy everyone who comes to their mailing list, that would be insanity.
        jfoster 12y ago
        Sure, but most people would consider the original poster's request as quite reasonable. Instead of considering it in a balanced way and producing a polite & considered response, the response was idealistic rhetoric. For better or worse, I think that does qualify the attitude of response as "unprofessional", as stingraycharles pointed out.
  - honestthrowaway 12y ago
    To be fair Google's whole business model is based on spying on people to gather data for ad placement. If we're being entirely honest a browser which sends every url you visit to Google by default is spyware.
    - yuhong 12y ago
      It is very off topic too.
      - honestthrowaway 12y ago
        Not really. You have to see the supreme irony in a company which is ditching suppport for very recent kernels in the name of security when the app in question is designed primarily to spy on your browsing habits (and ensure that you favour their search and mail products, which exist purely to make money from ads based on their spying).
    - danieldk 12y ago
      The questioner is using Chrome and already made his mind up that it is an acceptable trade-off. He is asking for a simple yes or no, but instead gets useless Chrome bashing. Of course, no one can expect free support. But if you want to have/keep users as well, this is perhaps not the way to treat them ;). Even if you wanted to sneak in the Chrome bashing, it would be better to answer the question first.
    - plantain 12y ago
      >If we're being entirely honest a browser which sends every url you visit to Google by default is spyware. [citation needed] Blatantly false.
      - kuschku 12y ago
        Definition of the Ombibar: While typing, the omnibar directly searches on Google and in your web history for the text you typed, may it be a search term, an URL, or content of a page you had visited in the past.
  - yrro 12y ago
    maks has always been a complete tosser.
- deleted 12y ago
  [deleted]
rdtsc 12y ago
Really, a browser is now dependent on a particular Linux kernel? For example RHEL/CentOS 7 which was released just last year with at least a 10 year support ahead of it is now obsolete according to them because it has a kernel version 3.10... Not that many people are on desktop versions of those OSes, and those that are will not use Chrome (for example, US govt loves them some Desktop RHEL systems, but Chrome is usually not allowed there anyway), but just highlighting how still seems a bit crazy.
- eeZi 12y ago
  The feature might very well be backported to 3.10.
- wtallis 12y ago
  When you commit to a 10-year support cycle, you'd better be prepared to backport quite a few things. Google's being aggressive about taking advantage of a kernel-level security feature that they developed to solve a real problem. This seems like a good thing overall.
  - username223 12y ago
    > When you commit to a 10-year support cycle, you'd better be prepared to backport quite a few things. OTOH, when you make a break-the-world release every six weeks, you can expect lots of breakage when dealing with the rest of the world. From what I can tell, Google pushed a feature they wanted into Linux, then didn't bother to think about backward compatibility. This would be fine if Chrome weren't force-updating software -- people on older kernels could just wait and update when they updated their kernels -- but alas that is not the case.
    - jfoster 12y ago
      Chrome doesn't force-update on Linux. You can just install it and not accept any updates.
      - KaiserPro 12y ago
ars 12y ago
Can someone say what TSYNC is? Googling it did not help me, lots of links, but none that said what it actually is.
- deleted 12y ago
  [deleted]
  - gst 12y ago
    That's another tsync.
- gst 12y ago
  https://lwn.net/Articles/603815/ https://lwn.net/Articles/603815/
- nandhp 12y ago
  It looks like a "thread-sync" feature for seccomp. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1379020 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1379020 http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/273472.html http://lists.infradead.org/pipermail/linux-arm-kernel/2014-J... seccomp ("secure computing") is an application sandboxing mechanism in the Linux kernel (since 2.6.12, 2005-03-08). seccomp allows a process to make a one-way transition into a "secure" state where it cannot make any system calls except exit(), sigreturn(), read() and write() to already-open file descriptors. http://en.wikipedia.org/wiki/Seccomp http://en.wikipedia.org/wiki/Seccomp Chrome uses seccomp to sandbox rendering subprocesses and the Adobe Flash Player.
  - justincormack 12y ago
    It is the seccomp type 2 mechanism, where you choose the system calls and arguments to allow, not the early seccomp type 1 that only allowed exit, read. That one would not really need to sync, as you cannot even create threads afterwards.
- zobzu 12y ago
  it synchronize all the process's threads to use the same seccomp filter (seccomp being a sandbox mechanism - a bit like a firewall for system calls). Threads on Linux are very close to an equivalent of "separate process" except they share memory. Up to until seccomp tsync, only the thread calling seccomp and it's children would get the seccomp filter. If you wanted to have seccomp in previously started threads you'd have to handle a broadcast in userspace and ensure all threads actually apply the same seccomp filter. I bet they ran into issues with that (it's easy to forget a thread or have a new thread someone elses coded that will fail to apply the filter). tsync is kernel side and explicitly fails/succeeds so its both simpler and safer.
anarcat 12y ago
so what's going to happen with chromium in debian?
eeZi 12y ago
The answer seems to be "yes", as Jessie has a 3.16 kernel. Lots of speculation though - there's no official announcement, as far as I'm aware, and the OP on the mailing list did not identify as a Google employee.
- scottlinux 12y ago
  I believe this seccomp-tsync feature was introduced in 3.17. I can't find the exact commit but I'm looking. Edit: https://lkml.org/lkml/2014/7/18/718 https://lkml.org/lkml/2014/7/18/718
teraflop 12y ago
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. https://code.google.com/p/chromium/issues/detail?id=401655 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."
- ryanprichard 12y ago
  At least there seems to be a supported method for updating the 14.04 kernel: https://wiki.ubuntu.com/TrustyTahr/ReleaseNotes#LTS_Hardware_Enablement_Stack https://wiki.ubuntu.com/TrustyTahr/ReleaseNotes#LTS_Hardware... 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.
  - skuhn 12y ago
    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. [1] https://wiki.ubuntu.com/Kernel/LTSEnablementStack#Kernel.2BAC8-Support.LTS_Kernel_Support_Schedule https://wiki.ubuntu.com/Kernel/LTSEnablementStack#Kernel.2BA...
    - deleted 12y ago
      [deleted]
    - oliwarner 12y ago
      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.
feld 12y ago
These long term support distros are toxic to everyone except proprietary software vendors.
- Nux 12y ago
  You are surely joking and you're not good at it.
  - feld 12y ago
    Do you trust package maintainers at Redhat/Debian/etc to properly backport security fixes to ancient branches? They don't exactly have a clean track record. Look at the terribly old / EOL software in RHEL4 that is on "extended support" until 2017: Java 1.4 SVN 1.1 Apache 2.0 Stunnel 4.0.5 Python 2.3 Glibc 2.3.4 Firefox 1.0 edit: I stumbled upon some ELSA advisories a few weeks ago where additional security updates needed to be released for Apache because the CVE for which they intended to backport a fix was not adequately patched. That is terrifying. There's a reason why upstream doesn't release fixes for those old releases.
zobzu 12y ago
Wow that's extreme. They could broadcast seccomp across thread for older kernels. One day it's going to be "use Google's fork of the kernel". Of course, Firefox and others work fine on "older" kernels.
- justincormack 12y ago
  It is a sandbox, you cant trust the threads to apply it I guess, if they have been hacked. I dont understand why you need to change the seccomp filter after creation though.
bcook 12y ago
Some browsers have different goals. Is that a problem?
- honestthrowaway 12y ago
  It's supremely arrogant to tell your users to change the kernel they are using because you couldn't be bothered to fix a regression in your code. The problem with that approach is self-evident.
  - mackal 12y ago
    I'm not sure I would say its supremely arrogant to tell them to upgrade their kernels. I'm sure if they realized that they were breaking sub 3.16 kernels they would of announced it before hand, but they fudged that. So instead of fixing it to not use a kernel feature they wanted to use, they just said "well this sucks"
  - justincormack 12y ago
    Well I guess their argument is they cannot provide secure sandboxing without this feature, and they do not want to ship it with weaker security.
  - guipsp 12y ago
    It is not a regression :)
pmontra 12y ago
Most people update the kernel when their distro does. Ubuntu 12.04 LTS is currently at a .5 version with kernel 3.13. There seem to be no plans for a 12.04.6 with a newer kernel but we'll see. Maybe TSYNC can be backported to 3.13 (I'm unsure about who has to do it) or Chromium can be compiled without TSYNC (distro's choice). If nothing happens this is going to cost Google some users but obviously it's their browser and their choice of how to implement it and where it can run.
- ali1234 12y ago
  Ubuntu already backported TSYNC months ago.
  - pmontra 12y ago
    Great. I didn't know (actually I didn't know about TSYNC until today). Thank you.
cnvogel 12y ago
So, is this a feature that will also appear in Chrome for Android? Is there even an overlap in codebase? [I honestly have no idea] Given that a lot of handsets run ridiculously old Kernels, I assume that this feature will not be usable for the next few generations of handsets (or will have to be backported, obviously).
teekert 12y ago
Perhaps it is a good things. Many kernel devs aparently don't like the method of back porting fixes for ages the way Debian does. They say the Arch way is fine and one should not be too afraid to upgrade in between. Perhaps Debian could start trying this? In other words, is the Debian stable method still needed in this day and age? Perhaps a good start for a discussion.
- icebraining 12y ago
  Debian has had the "Arch way" before Arch, it's called Unstable :) Personally, I like running that on my laptop and Stable on my server, since I like being able to fix security issues without suddenly having some component replaced or new functionality introduced that breaks the system and requires my intervention. Add unattended-upgrades, and I can essentially leave it running alone for months, if not years.
jrockway 12y ago
I don't think Chromium has dropped support for kernels <= 3.16. ChromiumOS uses 3.4, 3.8, 3.10, and 3.14 depending on device. All of those are less than 3.16, but as far as I know, ChromiumOS is not going away. It appears a patch needs to be cherry-picked back; a pretty common task for people that maintain older kernels. It's very common to backport patches to drivers you care about (because new kernel versions always introduce bugs in your obscure hardware, you only backport stuff that doesn't already work). There is even a system for doing it in an automated manner: http://drvbp1.linux-foundation.org/~mcgrof/rel-html/backports/ http://drvbp1.linux-foundation.org/~mcgrof/rel-html/backport...
- scottlinux 12y ago
  Google has backported this to ChromiumOS https://code.google.com/p/chromium/issues/detail?id=430588 https://code.google.com/p/chromium/issues/detail?id=430588
  - jrockway 12y ago
    Yup. So it doesn't seem that unreasonable to do the same in Debian. (Though I already have 3.16 in Debian, so...)
deleted 12y ago
[deleted]
kasabali 12y ago
This is not the first time that Chromium team doesn't care about even slightly older distros. Apart from the infamous RHEL 6 case, there is also the recent wheezy case. Back in September, there was a plan for requiring at least GCC 4.9 for building Chromium, which made building new releases for Debian wheezy in a pure Debian wheezy environment impossible. [0] Debian lacks the manpower of RedHat for backporting and supporting new software (which is GCC 4.9 for this case), so Stable Release Team and Security Team are not the most liberal teams when it comes to approving new packages into a stable release, and as a result, Chromium is not supported in Wheezy as of last month. [1] [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=763278 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=763278 [1] https://lists.debian.org/debian-security-announce/2015/msg00031.html https://lists.debian.org/debian-security-announce/2015/msg00...
derpsss 12y ago
Google never gave a single fuck about older distros. It took a few days after Debian 7 going stable that they stopped supporting Debian 6 (by requiring newer libc).
pXMzR2A 12y ago
The FUCK does a browser want with the version of my kernel?
- q3k 12y ago
  A security (sandboxing) extension.
nickysielicki 12y ago
"Most" chromiumOS developers use 14.04 LTS [1]... Which is 3.13. [1]: http://www.chromium.org/chromium-os/developer-guide http://www.chromium.org/chromium-os/developer-guide Kinda surprising... but not really.

139 points by xai3luGi 12y ago

It's much more interesting to see how useful the replies are. I assume they're because it's a dumb question, but still. This is an excellent example of an unwelcoming / hostile culture.

axlprose 12y ago
Indeed. The culture was part of the reason I made the switch from debian to opensuse a while ago.

jpgvm 12y ago

Replies so far for the lazy: On Sat, Mar 07, 2015 at 07:17:13PM +0200, Georgi Naplatanov wrote: > On 03/07/2015 06:38 PM, Ben Hutchings wrote: > > On Sat, 2015-03-07 at 16:09 +0100, D. F. wrote: > >> Hello, Julien Tinnes from google says that next releases of > >> chromium will drops support for kernels without TSYNC > >> ubuntu 14.10 already has been patched > >> Can I to expect that debian 8/jessie will have support for > >> TSYNC? > > Sounds like another good reason to not use Google spyware. > Google Chrome for Linux is the only possibility to use latest version > of Adobe flash player for Linux as far as I know. another good reason not to use it. -- maks I guess this is why Gentoo is still my distro of choice after all these years.

redthrowaway 12y ago
That seems like an exceedingly childish exchange.
- krick 12y ago
  It's common way to see things now, although I guess it's pretty normal. I always viewed distro as something people do primarily for themselves, if you want something from particular distro — you join the community. If your wishes are drastically different from what this community accepts — you go to another community or build your own. I'm not saying people should be rude and talk nonsense, but it seems that too many people tend to forget: Debian mailing list (or lkml, or what else people complain about) is not Starbucks or McDonalds where people are paid to smile and do what's requested. That's been said, I find question about TSYNC completely appropriate, and its support to be expected, but answer about "Google spyware" was funny and enjoyable anyway. So, yeah, maybe childish, but not "exceedingly childish".
- stingraycharles 12y ago
  I cannot believe these are the actual people responsible for Debian. Is this unprofessional attitude common in the Debian community?
  - eropple 12y ago
    No. More than it used to be, but it's not comon.
  - xai3luGi 12y ago
    Could you explain what you mean by "unprofessional" here? Personally Google's business model seems to be the unprofessional thing in this conversation.
    - jfoster 12y ago
      If Debian were a business and the original poster were one of their customers, how would the OP be feeling about that exchange? It's unprofessional by definition because it is so clear that the person responding does not consider this their profession.
      - adrusi 12y ago
        But it's not a business and that person wasn't a customer. Debian is a community, bound partially by common technical ideas about packaging, stability and security, and partially by philosophical ideas about Free software. Their goal is not to satisfy everyone who comes to their mailing list, that would be insanity.
        jfoster 12y ago
        Sure, but most people would consider the original poster's request as quite reasonable. Instead of considering it in a balanced way and producing a polite & considered response, the response was idealistic rhetoric. For better or worse, I think that does qualify the attitude of response as "unprofessional", as stingraycharles pointed out.
- honestthrowaway 12y ago
  To be fair Google's whole business model is based on spying on people to gather data for ad placement. If we're being entirely honest a browser which sends every url you visit to Google by default is spyware.
  - yuhong 12y ago
    It is very off topic too.
    - honestthrowaway 12y ago
      Not really. You have to see the supreme irony in a company which is ditching suppport for very recent kernels in the name of security when the app in question is designed primarily to spy on your browsing habits (and ensure that you favour their search and mail products, which exist purely to make money from ads based on their spying).
  - danieldk 12y ago
    The questioner is using Chrome and already made his mind up that it is an acceptable trade-off. He is asking for a simple yes or no, but instead gets useless Chrome bashing. Of course, no one can expect free support. But if you want to have/keep users as well, this is perhaps not the way to treat them ;). Even if you wanted to sneak in the Chrome bashing, it would be better to answer the question first.
  - plantain 12y ago
    >If we're being entirely honest a browser which sends every url you visit to Google by default is spyware. [citation needed] Blatantly false.
    - kuschku 12y ago
      Definition of the Ombibar: While typing, the omnibar directly searches on Google and in your web history for the text you typed, may it be a search term, an URL, or content of a page you had visited in the past.
- yrro 12y ago
  maks has always been a complete tosser.
deleted 12y ago
[deleted]

rdtsc 12y ago

Really, a browser is now dependent on a particular Linux kernel? For example RHEL/CentOS 7 which was released just last year with at least a 10 year support ahead of it is now obsolete according to them because it has a kernel version 3.10... Not that many people are on desktop versions of those OSes, and those that are will not use Chrome (for example, US govt loves them some Desktop RHEL systems, but Chrome is usually not allowed there anyway), but just highlighting how still seems a bit crazy.

eeZi 12y ago
The feature might very well be backported to 3.10.
wtallis 12y ago
When you commit to a 10-year support cycle, you'd better be prepared to backport quite a few things. Google's being aggressive about taking advantage of a kernel-level security feature that they developed to solve a real problem. This seems like a good thing overall.
- username223 12y ago
  > When you commit to a 10-year support cycle, you'd better be prepared to backport quite a few things. OTOH, when you make a break-the-world release every six weeks, you can expect lots of breakage when dealing with the rest of the world. From what I can tell, Google pushed a feature they wanted into Linux, then didn't bother to think about backward compatibility. This would be fine if Chrome weren't force-updating software -- people on older kernels could just wait and update when they updated their kernels -- but alas that is not the case.
  - jfoster 12y ago
    Chrome doesn't force-update on Linux. You can just install it and not accept any updates.
    - KaiserPro 12y ago

ars 12y ago

Can someone say what TSYNC is? Googling it did not help me, lots of links, but none that said what it actually is.

deleted 12y ago
[deleted]
- gst 12y ago
  That's another tsync.
gst 12y ago
https://lwn.net/Articles/603815/ https://lwn.net/Articles/603815/
nandhp 12y ago
It looks like a "thread-sync" feature for seccomp. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1379020 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1379020 http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/273472.html http://lists.infradead.org/pipermail/linux-arm-kernel/2014-J... seccomp ("secure computing") is an application sandboxing mechanism in the Linux kernel (since 2.6.12, 2005-03-08). seccomp allows a process to make a one-way transition into a "secure" state where it cannot make any system calls except exit(), sigreturn(), read() and write() to already-open file descriptors. http://en.wikipedia.org/wiki/Seccomp http://en.wikipedia.org/wiki/Seccomp Chrome uses seccomp to sandbox rendering subprocesses and the Adobe Flash Player.
- justincormack 12y ago
  It is the seccomp type 2 mechanism, where you choose the system calls and arguments to allow, not the early seccomp type 1 that only allowed exit, read. That one would not really need to sync, as you cannot even create threads afterwards.
zobzu 12y ago
it synchronize all the process's threads to use the same seccomp filter (seccomp being a sandbox mechanism - a bit like a firewall for system calls). Threads on Linux are very close to an equivalent of "separate process" except they share memory. Up to until seccomp tsync, only the thread calling seccomp and it's children would get the seccomp filter. If you wanted to have seccomp in previously started threads you'd have to handle a broadcast in userspace and ensure all threads actually apply the same seccomp filter. I bet they ran into issues with that (it's easy to forget a thread or have a new thread someone elses coded that will fail to apply the filter). tsync is kernel side and explicitly fails/succeeds so its both simpler and safer.

anarcat 12y ago

so what's going to happen with chromium in debian?

eeZi 12y ago

The answer seems to be "yes", as Jessie has a 3.16 kernel. Lots of speculation though - there's no official announcement, as far as I'm aware, and the OP on the mailing list did not identify as a Google employee.

scottlinux 12y ago
I believe this seccomp-tsync feature was introduced in 3.17. I can't find the exact commit but I'm looking. Edit: https://lkml.org/lkml/2014/7/18/718 https://lkml.org/lkml/2014/7/18/718

teraflop 12y ago

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. https://code.google.com/p/chromium/issues/detail?id=401655 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."

ryanprichard 12y ago
At least there seems to be a supported method for updating the 14.04 kernel: https://wiki.ubuntu.com/TrustyTahr/ReleaseNotes#LTS_Hardware_Enablement_Stack https://wiki.ubuntu.com/TrustyTahr/ReleaseNotes#LTS_Hardware... 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.
- skuhn 12y ago
  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. [1] https://wiki.ubuntu.com/Kernel/LTSEnablementStack#Kernel.2BAC8-Support.LTS_Kernel_Support_Schedule https://wiki.ubuntu.com/Kernel/LTSEnablementStack#Kernel.2BA...
  - deleted 12y ago
    [deleted]
  - oliwarner 12y ago
    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.

feld 12y ago

These long term support distros are toxic to everyone except proprietary software vendors.

Nux 12y ago
You are surely joking and you're not good at it.
- feld 12y ago
  Do you trust package maintainers at Redhat/Debian/etc to properly backport security fixes to ancient branches? They don't exactly have a clean track record. Look at the terribly old / EOL software in RHEL4 that is on "extended support" until 2017: Java 1.4 SVN 1.1 Apache 2.0 Stunnel 4.0.5 Python 2.3 Glibc 2.3.4 Firefox 1.0 edit: I stumbled upon some ELSA advisories a few weeks ago where additional security updates needed to be released for Apache because the CVE for which they intended to backport a fix was not adequately patched. That is terrifying. There's a reason why upstream doesn't release fixes for those old releases.

zobzu 12y ago

Wow that's extreme. They could broadcast seccomp across thread for older kernels. One day it's going to be "use Google's fork of the kernel". Of course, Firefox and others work fine on "older" kernels.

justincormack 12y ago
It is a sandbox, you cant trust the threads to apply it I guess, if they have been hacked. I dont understand why you need to change the seccomp filter after creation though.

bcook 12y ago

Some browsers have different goals. Is that a problem?

honestthrowaway 12y ago
It's supremely arrogant to tell your users to change the kernel they are using because you couldn't be bothered to fix a regression in your code. The problem with that approach is self-evident.
- mackal 12y ago
  I'm not sure I would say its supremely arrogant to tell them to upgrade their kernels. I'm sure if they realized that they were breaking sub 3.16 kernels they would of announced it before hand, but they fudged that. So instead of fixing it to not use a kernel feature they wanted to use, they just said "well this sucks"
- justincormack 12y ago
  Well I guess their argument is they cannot provide secure sandboxing without this feature, and they do not want to ship it with weaker security.
- guipsp 12y ago
  It is not a regression :)

pmontra 12y ago

Most people update the kernel when their distro does. Ubuntu 12.04 LTS is currently at a .5 version with kernel 3.13. There seem to be no plans for a 12.04.6 with a newer kernel but we'll see. Maybe TSYNC can be backported to 3.13 (I'm unsure about who has to do it) or Chromium can be compiled without TSYNC (distro's choice). If nothing happens this is going to cost Google some users but obviously it's their browser and their choice of how to implement it and where it can run.

ali1234 12y ago
Ubuntu already backported TSYNC months ago.
- pmontra 12y ago
  Great. I didn't know (actually I didn't know about TSYNC until today). Thank you.

cnvogel 12y ago

So, is this a feature that will also appear in Chrome for Android? Is there even an overlap in codebase? [I honestly have no idea] Given that a lot of handsets run ridiculously old Kernels, I assume that this feature will not be usable for the next few generations of handsets (or will have to be backported, obviously).

teekert 12y ago

Perhaps it is a good things. Many kernel devs aparently don't like the method of back porting fixes for ages the way Debian does. They say the Arch way is fine and one should not be too afraid to upgrade in between. Perhaps Debian could start trying this? In other words, is the Debian stable method still needed in this day and age? Perhaps a good start for a discussion.

icebraining 12y ago
Debian has had the "Arch way" before Arch, it's called Unstable :) Personally, I like running that on my laptop and Stable on my server, since I like being able to fix security issues without suddenly having some component replaced or new functionality introduced that breaks the system and requires my intervention. Add unattended-upgrades, and I can essentially leave it running alone for months, if not years.

jrockway 12y ago

I don't think Chromium has dropped support for kernels <= 3.16. ChromiumOS uses 3.4, 3.8, 3.10, and 3.14 depending on device. All of those are less than 3.16, but as far as I know, ChromiumOS is not going away. It appears a patch needs to be cherry-picked back; a pretty common task for people that maintain older kernels. It's very common to backport patches to drivers you care about (because new kernel versions always introduce bugs in your obscure hardware, you only backport stuff that doesn't already work). There is even a system for doing it in an automated manner: http://drvbp1.linux-foundation.org/~mcgrof/rel-html/backports/ http://drvbp1.linux-foundation.org/~mcgrof/rel-html/backport...

scottlinux 12y ago
Google has backported this to ChromiumOS https://code.google.com/p/chromium/issues/detail?id=430588 https://code.google.com/p/chromium/issues/detail?id=430588
- jrockway 12y ago
  Yup. So it doesn't seem that unreasonable to do the same in Debian. (Though I already have 3.16 in Debian, so...)

deleted 12y ago

[deleted]

kasabali 12y ago

This is not the first time that Chromium team doesn't care about even slightly older distros. Apart from the infamous RHEL 6 case, there is also the recent wheezy case. Back in September, there was a plan for requiring at least GCC 4.9 for building Chromium, which made building new releases for Debian wheezy in a pure Debian wheezy environment impossible. [0] Debian lacks the manpower of RedHat for backporting and supporting new software (which is GCC 4.9 for this case), so Stable Release Team and Security Team are not the most liberal teams when it comes to approving new packages into a stable release, and as a result, Chromium is not supported in Wheezy as of last month. [1] [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=763278 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=763278 [1] https://lists.debian.org/debian-security-announce/2015/msg00031.html https://lists.debian.org/debian-security-announce/2015/msg00...

derpsss 12y ago

Google never gave a single fuck about older distros. It took a few days after Debian 7 going stable that they stopped supporting Debian 6 (by requiring newer libc).

pXMzR2A 12y ago

The FUCK does a browser want with the version of my kernel?

q3k 12y ago
A security (sandboxing) extension.

nickysielicki 12y ago

"Most" chromiumOS developers use 14.04 LTS [1]... Which is 3.13. [1]: http://www.chromium.org/chromium-os/developer-guide http://www.chromium.org/chromium-os/developer-guide Kinda surprising... but not really.