Chrome/Chromium To Require Newer Version Of Linux Kernel

[asdfblah]

@chrisb & @strcat : coudn't the chrome/chromium guys have made this an OPTIONAL (but enabled by default) feature?
Seriously, I think that there is NO way to defend this.
EDIT: A bit too late... I just read the other article.

[Azrael5]

What exactly Tsync is useful to?

[Alex Libman]

Hoping this won't affect *BSD portability...

[strcat]

Taking bets, which do you think will happen first? Chrome will be built in to systemd? Or systemd will be built into chrome? Lol



Has Red Hat issued a statement on this yet? All of our workstations and servers here are RHEL6 (2.6.32) and we won't be upgrading until at least 2018. We use Chrome today, because it seems to handle certain web sites better than FF, especially sites that are Flash heavy.

RHEL gets loads of features backported and this is a tiny one, so I'd expect them to do it. It might take them a while though.

[torsionbar28]

I won't be surprised if one morning people wake up to find that chrome/chromium replaced their linux kernel entirely, and that it is now in charge of booting their machine! and for laughs it will load linux kernel as a JS plugin. Ok they might consider NaCl.

I once looked at chromium code, it is an order of magnitude more complex then the kernel itself. Damit!

Taking bets, which do you think will happen first? Chrome will be built in to systemd? Or systemd will be built into chrome? Lol

Google already backported the patch to 3.14, 3.10, 3.8, and 3.4.

Has Red Hat issued a statement on this yet? All of our workstations and servers here are RHEL6 (2.6.32) and we won't be upgrading until at least 2018. We use Chrome today, because it seems to handle certain web sites better than FF, especially sites that are Flash heavy.

[hrkristian]

I won't be surprised if one morning people wake up to find that chrome/chromium replaced their linux kernel entirely, and that it is now in charge of booting their machine! and for laughs it will load linux kernel as a JS plugin. Ok they might consider NaCl.

I once looked at chromium code, it is an order of magnitude more complex then the kernel itself. Damit!

Providing a user access to the whole internet is arguably an order of magnitude more complex than providing a browser access to hardware, frankly.

[chrisb]

Kernel 3.14 is the most recent long-term support kernel from upstream (=kernel.org). I think it's a bad idea if Google doesn't support that. Many people depend on it.

Google already backported the patch to 3.14, 3.10, 3.8, and 3.4.

[chrisb]

I use Firefox on an older kernel and everything works fine.. oh wait.

Note that the developer who decided Chrome and Chromium will only work on newer kernels works for Google full time, so there is no "independent open source project" crap that'll fly. It's Google decision.

It's a combination of decisions.

• Chromium upstream decided not to support kernels without a certain patch.
• The Debian developer decided that he wouldn't support the patch because he doesn't like Chromium.
• Chromium maintainer can now decide to try and get patch in anyway despite hostility
• Or Chromium maintainer can decide to revert patch requirement and ship modified upstream

The Chromium maintainer expects that TSYNC is not really a hard requirement, but if it is, will accept a patch to remove it. So perhaps this isn't really the big deal that people are making it out to be.

[balouba]

I use Firefox on an older kernel and everything works fine.. oh wait.

Note that the developer who decided Chrome and Chromium will only work on newer kernels works for Google full time, so there is no "independent open source project" crap that'll fly. It's Google decision.

[strcat]

I don't blame the Debian for feeling this way. They are not alone in objecting to vendor lockin.

It has nothing to do with vendor lock-in. It's an open-source project (Chromium) deciding to depend on a recent feature in the Linux kernel. The feature is upstream and most of the popular distributions distributions (Ubuntu, OpenSUSE, etc.) have backported it already. It's quite similar to how systemd and udev require fresh versions of the Linux kernel. Developers are less and less willing to leave legacy compatibility cruft in general as it leads to bugs / vulnerabilities and makes it harder to introduce new features.