Google Chrome Requires TSYNC Support Under Linux
An anonymous reader writes Google's Chrome/Chromium web browser does not support slightly older versions of the Linux kernel anymore. Linux 3.17 is now the minimum requirement. According to a thread on the Debian mailing list, a kernel feature called TSYNC is what makes the difference. When a backported patch for the Debian 8 kernel was requested, there were hostile replies about not wanting to support "Google spyware."
First comment.
Awwww y
Not that I was going to use a system that kowtows to RMS by calling itself GNU/Linux anyway, but the OS is there to support the software I use, and I use Chrome on Linux. If the OS won't support it, then I won't use it.
Disinfect the GNU General Public Virus!
It's really just the JUST IN TIMEBERLAKE function.
This is unfortunate. I was hoping to not upgrade my Ubuntu 12.04 systems for another year or two, until the systemd dust settles, and I know other people in the same boat.
Am I part of the core demographic for Swedish Fish?
This doesn't pass the sniff test. This 'bug' has apparently been around for months (October/November) and it's just now that people are noticing? And the fix is patching the kernel rather than regressing whatever change was in Chrome that added this?
Inflammatory comments on the mailing list? Time for detective Slashdot to get on the case.
Would have been nice if TFS had included an explanation of what the TSYNC feature is.
The entire conversation was more or less...
1.) Chrome is going to require kernel bits we don't have
2.) OMG GOOGLE IS ALL SPYS AND DEVILS
3.) SO IS ADOBIE
4.) ok guys stfu. Show me where the spyware is or get back on topic.
5.) some kernel guy going on a rant about not back-porting an official patch (probably with good reason) but not being friendly about it
Debian 8 was a lost cause long before this nonsense. It will be the first "stable" version of Debian to include systemd. Systemd was forced upon Debian users thanks to some dirty politics, and has generally been unwanted by most of the Debian community. It already caused numerous problems for those running the unstable and testing versions of Debian, including systems that would no longer boot. The fact that systemd is still under very heavily development additionally means that it has no place in a stable Linux distro release, especially a Debian stable release. Many Debian users, especially those running servers, have realized that they need to discard Debian in order to maintain the stability of their systems. We've seen lots of these people move to the BSDs, in fact. All of that aside, Debian 8 is shaping up to be one of the most disappointing Debian releases ever, if not the worst, and it's all thanks to the bad decision to include systemd.
Rather than adding new code to your kernel, why not simply remove new code (whatever breaks without this TSYNC) from your browser? If this code was recently added, it just can't be that difficult to remove.
You are compiling it yourself, aren't you? I certainly do — that's what source code is for. What's the problem?
In Soviet Washington the swamp drains you.
I don't know what the fuck TSYNC is, but I'm confident that the BSDs, OS X, and Windows probably don't offer it, especially if only recent Linux kernel versions support it.
So how the flying fuck can Chrome run on these other systems that don't offer this functionality? What in shit's name is preventing those workarounds from being used on these older Linux systems?
The general issue here is that running a fairly large, popular application now requires a kernel patch that was authored by the same organization that wrote the application. Moreover, the kernel version including this patch is well newer than what's shipped by most mainstream distributions, AND the application vendor is fairly hostile to running older versions of the application software (that wouldn't require this patch).
So,
1. Vendor isn't willing to think about distribution support timelines
2. Vendor doesn't seem to care about kernel/userspace boundaries and very happily writes code on both sides to an interface they've designed themselves, for themselves.
3. Profit?
Yes, doing it this way is notably easier for Google. This is generally considered one of the selling points of a closed ecosystem: you don't have to care about little things like public interfaces and what's already in the field (and going to be there for a decade): just "move fast and break stuff" because it all works in the environment that you're testing in, and you don't much care about anything else.
This is pretty typical for modern Debian. The whole Debian project has found itself floating in a cesspool of shit and urine since the way systemd was forced upon the Debian users. Anyone who's any good within the Debian community fled soon after that incident. We find them using Slackware or the BSDs these days, and contributing to those projects instead of to Debian. Without these good people using and contributing to Debian, it has rapidly started to fall apart as a project. It doesn't surprise me at all that the discussion has hit a new low.
You don't go and start upgrading kernels in a LTS release for a stupid web browser to be functional. If Google wants their browser to work in these LTS releases, then they should fix their bugs/dependencies.
LTS as a practice, is against Google's best interest - Google is attempting to leverage Chrome to turn all software into insecure, auto-update, phone home garbage - just like all other web applications. They don't want to use the workaround, they want you to update.
It's a detail of how sandboxing works on Linux. Other OSes have theirmown sandbox mechanisms. Microsoft cares about Windows having the necessary features because they use a sandbox in IE. The Linux sandbox mechanism that Chrome/Chromium uses appears to be an API at least partially developed by Google. TSYNC is a feature Google recently added to the sandboxing API in Linux because they intended to use it in Chrome.
This is really a non-issue. Chrome decided to use a recent feature in the kernel. This happens all the time. Most distributions that are using the older kernel have patched. If Debian doesn't want to patch, move to another distribution or switch to Firefox. Both Fedora 20 and 21 are on 3.17 - so it isn't an issue there. Debian is notorious for using old stuff, so it may be the kernel they are using requires a multitude of changes and because of their policies they don't want to move to a more recent version. You buy into that logic when you choose to use Debian - so expect this stuff to happen. This has nothing to do with RMS or Google; rather the mismatch of using a slow to update distribution with a browser that is on the fast track.
Something doesnt' feel right abotu this. Kernel 3.17 is very new. Most distribitions are running kernels 3.16 or older. Any long term support releases from Ubuntu, Mint, CentOS, Red Hat, etc will be running older kernels. So either those distros are backporting patches or they cannot run Chrome, if the original post is correct. It seems unlikely Google would cause Chrome and Chromium to stop working on virtually every Linux distro.
Well, that depends. New hardware support is added all the time. LTS means that changes can be made. It doesn't mean you are frozen to a specific set of hardware. Chrome development is on the fast track. If the distribution you are using thinks that you are using a "stupid web browser" perhaps it is time to switch to another distribution. Fedora and Ubuntu will work just fine; and I'm sure there are others.
Now what do I do? I have to give up Android because of Google, and I can't use an iPhone because.. shiny, so what do I do? Get Windows phone? How could that be the answer??
Just because a version of Chrome gets released doesn't mean that all distributions will and must begin using the code immediately. Distributions will simply not deliver newer versions of Chrome until the kernel is bumped up to the level required to support said newer version.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Debian dickishness in full effect.
No thanks, I'll sick to my stable OS, and stable browser.
Ubuntu already appears to have a seccomp-tsync backport to 3.16.x: https://lists.ubuntu.com/archi....
So Debian now thinks Chrome is not suitable to be included but they ARE incuding systemd which is far LESS trustworthy?
I don't love Chrome but I do find that I need it at times, just like I need the ability to run Firefox and IE, and I certainly won't be using a distribution that goes out of it's way to make my life difficult.
The guy that said "Sounds like another good reason to not use Google spyware" does not have a Debian email address.
Of course Chrome IS spyware. I mean - isn't it obvious that they didn't write Chorme out of the 'goodness-of-their-heart'?
no, the real LTS kernel does not get new hardwaresupport. you confuse it with the hardware enablement stack of ubuntu.
Sounds like Firefox may get a bump in NetStat numbers, however small, and Chrome will drop. I still don't get why anyone would use that phone home spyware, but over 40% of the market can't be wrong, can it? Think about the windows users!
The cesspool just got a check and balance.
Prepare to get pwned in 5, 4, 3, 2...
I'm on Debian 7 Wheezy, running Google Chrome 40.something
Is that supposed to not work?
I don't know what the fuck TSYNC is, but I'm confident that the BSDs, OS X, and Windows probably don't offer it, especially if only recent Linux kernel versions support it.
So how the flying fuck can Chrome run on these other systems that don't offer this functionality? What in shit's name is preventing those workarounds from being used on these older Linux systems?
Shorter AC: I have no fucking idea what this is all about, but it fucking enrages me! Raaaugh!
So that's why Chrome wouldn't run on my laptop. I guess I'm not going to be able to use it anymore, because my laptop run 2.6.32 and nothing else. I'm not going to spend $500 on a new laptop just to run Chrome.
That's not the chrome update philosophy. They should be able to push updates quickly, automatically, and without regression to mitigate security problems because the attack surface of the web browser is so huge. They expect to be able to do this and have lots of automated testing to support it on all the platforms, and they don't maintain forks besides stable, beta, and dev: you must be at the head of one of those branches to remain secure.
You're saying the distro should make an even older fork than stable, and then backport all security patches from Google's stable to their branch. While that's possible, it's probably harder than backporting a kernel feature once. In practice the distribution will just freeze you at an old, potentially-insecure version of Chrome, leaving you exposed if a fix needs to be rolled out quickly.
The real question should be why the kernel update cycles are so long. I thought ABI churn problems on Linux were mostly in the past, and modern kernels were BSD-like in that they were compatible with multi-year swaths of userland.
How is this supposed to work on Android? The kernels in the ecosystem influenced by Google themselves are generally much older than the ones shipped on various distribution branches, even "LTS" ones, and they're not updated even for security bugs, much less arcane features. Does Chrome-on-Android simply not use seccomp?
"Shorter AC: I have no fucking idea what this is all about, but it fucking enrages me! Raaaugh!" - now, here's someone pointing out the reality of a trolls mentality
slashdot needs peer review, or something.
I'm running Chrome 41 on CentOS 6 -- that has kernel 2.6.32. I followed the link and one of the complaints was that Chrome remote desktop could not be installed. So I installed it. Works fine. No problems here.
Linux 3.17 clearly is not the minimum requirement.
(yes, it takes a shim to get Chrome to work on CentOS. It is a pain. see chrome.richardlloyd.org.uk -- he figured out how to make it work, and it works well.)
there are 3 kinds of people:
* those who can count
* those who can't
and Chrome is the only way to get this content under Linux
looky here -
A little effort & Firefox uses Chrome's PepperFlash.. Quite well, I might add.
and before anyone slams me for using flash, some sites I _need_ to use (cough)godaddy(cough) require it. Simply set it to ask to be enabled. Problem solved - options are good.
is the reason why you should not let constructive users interact with ignorant technical guys.
What is so hard about actually believing to a user that if he repots something, it may be important to him (in this case chromium/flash), for reasosn which you or he may or not like, but thich are probably there.
If you dont like something, act non-constructive and get ideological.
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.
I read that as more snarky than hostile.
It must have been something you assimilated. . . .
Intel compilers install their documentation as local HTML (on that server), so you need a browser of some sort to read it. And firefox won't do that job on RH servers, because RH puts in that ancient and rude "use the Firefox on the client machine, not the one local to the server" hack to the firefox it supplies. So you need either konqueror, chrome, or opera on the server ;-(
"My opinions are my own, and I've got *lots* of them!"
I even try Konqueror before I resort to Chromium.
I do not fail; I succeed at finding out what does not work.
You've got a shitty laptop. That's your problem.
Seems like it's Google's problem. My 6 year old laptop runs plenty of software just fine, including the latest version of Firefox. I use the laptop for some pretty serious coding, so it's hardly a toy. The main advantages:
1. I already paid for it
2. 11.6" screen allows me to open it all the way up in an airline seat (coach class) even if the person in front of me is leaning back.
ps - flying coach because my company doesn't want to waste money on first class or new laptops. I guess not wasting money is how my company manages to stay on the NASDAQ-100.
what has always puzzled me about Chrome/Chromium, is that the latter do not come as easy to handle tar-balls.
If you want to compile it you have to download special tools, then aim those at their source repo to grab a tagged branch, and then compile from that the variant you want (said repo mix Chromium and ChromiumOS as best i can tell).
comment first, facts later. http://chem.tufts.edu/AnswersInScience/RelativityofWrong.htm
Presumably, you're running RHEL/CentOS 6. If so, that's cool if it works for you--the stability is probably greater than just about any other major distro--but I think the expectation is that most who run Linux for their notebooks/workstations will run something newer and more flexible, and run something like that in a VM. But there's always the reality that RHEL/CentOS 6 isn't going to run the latest software in many cases (unless you go with non-standard repos), and here's a case where a browser has become one of those cases.
It's probably also surprising that you run a six-year-old notebook in a corporate environment. Even the fiscally conservative companies tend to upgrade notebooks at least every four years, even if they are Fortune-100 companies.
You can never go home again... but I guess you can shop there.
So as a user of free, open source software you don't want to update, or patch either kernel or Chromium, or find a patch made by others? You are doing it wrong!
I guess not wasting money is how my company manages to stay on the NASDAQ-100.
NASDAQ-100 =/= Fortune-100 =/= NYSE-100
They are truly the new Micro$oft. I was quit already. I'm twice as quit now!
Does it actually phone home, though? I've seen lots of puffy-faced, breathless posts complaining about this, but not a Wireshark trace in sight...
OTOH they have PLENTY of reason to upgrade. Heartbleed, freak, shellshock, etc. Tons of bugs found in Linux/Windows/Apple/Android on a day-to-day basis.
You're assuming it is "up".
New bugs are not necessarily better than old ones.
Are the Debian developers responsible for writing code or for making moral judgments about which applications users run on the platform? Where do they get off telling users what are good vs. bad applications? Either make the changes to support TSYNC or else give reasons like not enough time, too much work for too few users, etc., without the judgments.
There's a number of ways it phones home, some of which at least can be mitigated: spell check, url suggestions, and default search from the address bar which is my personal pet peeve, what was so hard about hitting the TAB key to go to the search field from the address field so I can control what I search for?
However, ask yourself this, what reason did Google have for making a better independent browser than Firefox, which was at 30+% market share at the time and used Google as it's default search engine? It wasn't altruism, so there must have been a driving reason for it.
The cesspool just got a check and balance.
https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/4WBMtXU5mfo
Chromium does not require TSYNC.
https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/4WBMtXU5mfo
- If TSYNC support is detected, Chromium will use it.
- No version of Chromium (including the latest M42 version) currently requires TSYNC (chrome://sandbox "adequately sandboxed" report does not currently depend on TSYNC being there or not).
Well, there's that. But don't let it interfere with y'all's herp-derp-chrome-is-spyware circle jerk.
If we take the chrome browser out of this
most would agree that improving the ability
to sandbox a program is good.
https://wiki.mozilla.org/Secur...
https://en.wikipedia.org/wiki/... (out dated by a bit)
This secure computing mode might be too simple for
some but it seems like a necessary tool to write code
that needs some trust and or is the target of all the
hackers in the world.
Since malware and other browser vectored problems abound
this could be a good thing. I see a long list of multithreaded
tools that use this sandbox.... It seems necessary
to have TSYNC if Intel and others are serious about growing
the number of cores in future processors.
.
Truth is stranger than fiction, but it is because Fiction is obliged to stick to possibilities; Truth isn't. Mark Twain.
Or just use FireFox that's been Open Source for long time
Sounds like Firefox may get a bump in NetStat numbers, however small, and Chrome will drop. I still don't get why anyone would use that phone home spyware, but over 40% of the market can't be wrong, can it? Think about the windows users!
Hmmm this sandbox strategy is used by Firefox and many more tools.
As more and more tools move to threads this ability
to sync them will gain traction.
My guess is there is a window of risk that needs to be closed before it surfaces
as a bug or exploit. All in all this sandbox stuff is new but interesting as heck.
There are stronger models but this is an improvement especially when RAM is
limited -- (tablets and phones).
Truth is stranger than fiction, but it is because Fiction is obliged to stick to possibilities; Truth isn't. Mark Twain.
RHEL is one of the few platform the vendors software does run in. The other is Ubuntu 10.04 LTS (yea, a 5 year old OS. it's silly. but that Linux can't run its own binaries because they are "too old" is pretty silly too. I've got a ton of old linux software that I've written over the years that only runs if you recompile against the latest glibc, etc.)
Developer machines come out of the engineering budget not the IT budget. IT upgrades machines, but they only give us one machine, so we make them buy a big beefy workstation. The laptops are purchased by engineering when you are hired and about the only option I have is to lose it or break it and then explain to the director why I am making him sign a purchase order.
Bug was reported August 7th, 2014 -- Google developers just got active with it this week.
=/= ? noob.