Slashdot Mirror
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."
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?
Would have been nice if TFS had included an explanation of what the TSYNC feature is.
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.
So, you tell us you are not going to use a system that you weren't going to use.
And we should give a fuck, why?
Watch this Heartland Institute video
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.
Because it's yet another reason not to use them.
Disinfect the GNU General Public Virus!
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.
To each his own.
However, for folks who want their OS to actually pay attention to their needs, it's yet another nail in Debian's coffin.
Disinfect the GNU General Public Virus!
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.
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
Google didn't run around to all the servers on the internet gathering all the source code for the versions of Chrome that need this patch. Distributions will simply use the version they have that works and refrain from bumping up the Chrome version until after the linux kernel is at the required revision.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Ubuntu already appears to have a seccomp-tsync backport to 3.16.x: https://lists.ubuntu.com/archi....
I haven't even looked to see why Chromium needs to make a kernel call that no other browser needs to make. But - I'm rather skeptical of TSYNC before I even look at it. TFS already suggests that it might be spyware. Glad I no longer run Chromium - SRWare Iron is the same as Chromium, but stripped of all the intrusive bullshit.
http://www.srware.net/en/softw...
"Windows is like the faint smell of piss in a subway: it's there, and there's nothing you can do about it." - Charlie Br
"1) they derive directly from Ubuntu, which pays better attention to users,"
Seriously? WTF was Unity? I dumped Ubuntu as soon as they started tooting Unity's horn, and the wife dumped Ubuntu when her version with Mate desktop lost support. Pays attention to it's users? What users are those, exactly? The users who migrated from Windows, and wish to continue along the same path that Microsoft is going?
Nope, you don't get away with that one. You may state that Ubuntu satisfies all your wants and needs in a desktop, and I'll just roll my eyes, and keep my mouth shut. You may NOT proclaim that Ubuntu pays attention to it's users. THAT is a lie!
"Windows is like the faint smell of piss in a subway: it's there, and there's nothing you can do about it." - Charlie Br
Chrome is by definition, spyware.
It does everything in its power to relay information about your activities back to Google, right down to what you click and when, if you allow it.
Most of these 'features' require you to opt-in, but some just happen right out of the box.
If you don't realize that the entire existence of Chrome and Chromium is to get information about you, you're an idiot with your head in the sand.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
Chrome is non-free proprietary software. They have never included it in Debian.
You know what? I'm not paranoid about Google. They don't care about me individually, and I opt out of their ad targeting. The rest I just don't care about.
You're can't be paranoid about google, paranoia is thinking that someone's watching you, with Google, they boldly state they're watching you and in your case you're aware of that. I personally do care what Google knows and have taken steps to limit that significantly, by using as little of their services as possible and making tracking me much more difficult. A random Jane or John at Google shouldn't be able to tell you you're on your period this week, for instance.
The cesspool just got a check and balance.
no, the real LTS kernel does not get new hardwaresupport. you confuse it with the hardware enablement stack of ubuntu.
Chrome is non-free so most distributions don't distribute it to begin with.
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.
The guy that said "Sounds like another good reason to not use Google spyware" does not have a Debian email address.
You mean that guy?
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!
How about us people who used to think Debian was the very best Linux server system in existence, and who evangelized its use and put it in businesses and donated to SPI. But now we shun it as garbage, and actively remove it from our company's servers? Do you think that makes the Debian project happy?
You say that as though it's a bad thing.
Disinfect the GNU General Public Virus!
Settings -> Advanced -> Privacy -> uncheck the box "Enable phishing and malware protection."
Better attention to its users than Debian is a low bar to clear. I'll agree that Ubuntu has its own problems in that area.
Disinfect the GNU General Public Virus!
"TSYNC is a new sandboxing flag for seccomp that was recently added to the Linux kernel." -- from the description of the change to Chromium
Sounds like more browsers should be using it.
Disinfect the GNU General Public Virus!
Your browser, right or wrong. Doesn't matter that the Chrome people are being ridiculously brain-damaged here, you've decided that the OS people are always wrong in any conflict.
For every problem, there is at least one solution that is simple, neat, and wrong.
The issue not google chrome, but SystemD bloatfest
Not referring to chrome issue, rather that giant greasy dump by Poettering into the open source pool known as SystemD
No, not at all. In this case, though, it's not going in because of the animosity of one developer to all things Google. He didn't even bother to see what the change was about before shooting it down in flames.
The OS people are quite often right. Not this time, though.
Disinfect the GNU General Public Virus!
No, you're still not making an accurate representation.
DEBIAN'S USERS are groups such as Ubuntu, Mint (which uses both Ubuntu and Debian on different distros) Sparky, I think CrunchBang - that is, subordinate distros use Debian.
At this point in time, Sparky is paying attention to what I want, and supplying what I want in a working environment, all powered by the latest Liquorix kernel. I've seldom installed and/or assembled a desktop directly from Debian. However, Mint's LMDE had my attention for quite some time after Ubuntu abandoned it's users.
Since then, the Enlightenment desktop has grown bigger and stronger, so I've wandered further afield into Arch-Linux land, but keep bouncing back into Debian land. (basically, I'm following the best support for Enlightenment - if Ubuntu would deign to work on E, I might even give them another try. Then again - maybe not.)
"Windows is like the faint smell of piss in a subway: it's there, and there's nothing you can do about it." - Charlie Br
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. . . .
> How about us people who used to think Debian was the very best Linux server system in existence, and who evangelized its use and put it in businesses and donated to SPI.
Fakedebianist pls, I don't think there are that many of you that don't know what a stable release is.
Jessie is about to be debian stable, which means that the packages have undergone "some" QA testing, which provides the quality that made debian what it is.
Somebody asking to backport stuff to jessie at this stage, after the problem was known months in advance or so TFS says, is either ignorant or malicious.
The correct way to handle this is to ship a tested version of chrome, which implies no kernel patching, and apply security patches as usual. Those itching to run the latest chrome can run a newer kernel, run a backported chrome + kernel patch (maybe package it in a module and use the dkms system which works for my 3d drivers very well), run chrome in a VM (which is what I'd do if I was concerned about what data flows between chrome and google).
The debian dev rejecting the request has been rude, but he ends up being right.
---- MISSING MISCELLANEOUS DATA SEGMENT --- [sigdash] trolololol
Automated regression tests on the development build of a web application is one reason. Web pages can and should be tested, just like the unit tests for the code that backs them.
That's still no reason to reject a kernel patch that would improve the overall security of the system by sandboxing a commonly used exploitation attack vector. There's kernel developers on the payroll of the NSA, or who work for companies that have contracts with the NSA (Red Hat, for one) that contribute to the kernel. Should Ben Hutchins reject their patches because they're ostensibly related to a massive spying organization?
Here is the kernel commit message:
seccomp: implement SECCOMP_FILTER_FLAG_TSYNC
Applying restrictive seccomp filter programs to large or diverse
codebases often requires handling threads which may be started early in
the process lifetime (e.g., by code that is linked in). While it is
possible to apply permissive programs prior to process start up, it is
difficult to further restrict the kernel ABI to those threads after that
point.
This change adds a new seccomp syscall flag to SECCOMP_SET_MODE_FILTER for
synchronizing thread group seccomp filters at filter installation time.
When calling seccomp(SECCOMP_SET_MODE_FILTER, SECCOMP_FILTER_FLAG_TSYNC, ...) has been set on the calling thread, no_new_privs will be set for
filter) an attempt will be made to synchronize all threads in current's
threadgroup to its new seccomp filter program. This is possible iff all
threads are using a filter that is an ancestor to the filter current is
attempting to synchronize to. NULL filters (where the task is running as
SECCOMP_MODE_NONE) are also treated as ancestors allowing threads to be
transitioned into SECCOMP_MODE_FILTER. If prctrl(PR_SET_NO_NEW_PRIVS,
all synchronized threads too. On success, 0 is returned. On failure,
the pid of one of the failing threads will be returned and no filters
will have been applied.
The race conditions against another thread are:
- requesting TSYNC (already handled by sighand lock)
- performing a clone (already handled by sighand lock)
- changing its filter (already handled by sighand lock)
- calling exec (handled by cred_guard_mutex)
The clone case is assisted by the fact that new threads will have their
seccomp state duplicated from their parent before appearing on the tasklist.
Holding cred_guard_mutex means that seccomp filters cannot be assigned
while in the middle of another thread's exec (potentially bypassing
no_new_privs or similar). The call to de_thread() may kill threads waiting
for the mutex.
Changes across threads to the filter pointer includes a barrier.
https://git.kernel.org/cgit/li...
New things are always on the horizon
It means it makes Chrome more secure.
This sort of thing is why Debian is so often seen as a realm of knee jerk lunatics. Debian isn't keeping up with features Chrome needs to be more resistant to browser exploits (which are used to install ACTUAL spyware) and the answer is "Chrome gathers statistics on how it's used so it's evil and we don't care if it breaks". WTF?
Depends what you mean by needs. If google is misusing tsync for 'spyware' as claimed, then debian is acting in your interest by not supporting user hostile software.
Chrome is non-free so most distributions don't distribute it to begin with.
How was the kipper?
As I understand it, this problem is not directly related to Adobe Flash Player, patented codecs, Google Update, or Google crash reporting. These are the only non-free parts of Chrome.
Chrome is by definition, spyware. (...) If you don't realize that the entire existence of Chrome and Chromium is to get information about you, you're an idiot with your head in the sand.
And? They produce a product/service you want in exchange for some information they want. I realize this comes as a shock to /.ers but most of the world don't have a problem with what Facebook and Google is doing, nor do they think it's a secret. If it's not secret, it's not spyware. If you want to claim half the Internet-browsing computers out there is running spyware by using Google you're just diluting the term until it becomes meaningless and you have the credibility of a loon.
Live today, because you never know what tomorrow brings
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.
Thats bassackwards!
"Accept this kernel patch because some web browser unwisely introduced a dependency on a kernel feature two years before it would be sane to do so"
"That's crazy, hell no"
I think you've misidentified the side that's in the wrong here. Software developers, when they see a new feature in some library they use or in a kernel or whatever, should be thinking "That'll be nice to use someday, I'll start playing with it in a bit, make it an option in a year if that's workable, and maybe make it a dependency in two years". Deciding "OMG yes NOW NOW NOW" is moronic.
For every problem, there is at least one solution that is simple, neat, and wrong.
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!"
Popularity sucks, I always hope less people will choose the same tech as me. If it is popular then the lowest common denominator is guaranteed to be average. I want software with a community that is higher on the curve than that.
So which distro am I using? I say, don't ask, don't tell.
I even try Konqueror before I resort to Chromium.
I do not fail; I succeed at finding out what does not work.
That's your prerogative, but keep in mind you're throwing a tantrum over a issue that does not affect the server market. No one in their right mind install a GUI on a Linux server, so again, not a issue for the server market.
Well, I can appreciate the reasons for this argument, but I also routinely do the opposite: I have many servers installed on my own "workstation" machines, which of course came with GUIs.
Of course, by "server" you were presumably referring to hardware, while for many of us software types, a "servers" is a piece of software that can run wherever we're able to compile it. So technically, we don't install GUIs on our servers; we install GUIs and other servers on our machines. They're really independent chunks of software, and they can easily cohabit on a single machine these days.
One basic reasoning behind all this, of course, is for testing purposes. After all, no one in their right mind installs untested web software on a client-facing server (machine). We install it on our workstations, where we have all the software (including browsers that require a GUI) to do thorough testing, and we test the hell out of it before inflicting it on unsuspecting Web visitors.
(Actually, who am I kidding? I install small edits on "live" web servers all the time. This is rarely a problem, it turns out. But YMMV. I did this numerous times in the past week, because the server admins - in their wisdom - were installing upgrades on the server without first testing them on hidden machines. You wouldn't believe all the web site's stuff that this broke. I found it better to actively watch the web stuff that I was responsible for, and when it broke, try some quick fixes - or apologetic top-of-page messages - for the duration. And I'm still on good terms with those admins, who appreciated my occasional emails about what was currently broken. ;-)
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
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
This needs some serious modding up. ... as a lead developer who was instrumental in moving us from debian (which until the last year or two, I had been evangelizing and supporting for almost a decade) to FreeBSD for over 10,000 servers (two entire clusters) and hundreds of workstations (test/dev machines of developers/scientists/etc).
We're starting to see similar things from our peers as well, debian/centos/rhel/ubuntu being dropped pretty rapidly within our circle of influence - they don't listen to users/customers (really bad RHEL wise, when you're paying them hundreds of thousands of dollars), they fail on security (something debian was once great at), and they're moving linux into a direction that's frankly - undesirable for serious servers, HPC, etc.
Debian is dead, stop giving it attention, we've all moved on - so should the conversations.
"Chrome gathers statistics on how it's used so it's evil and we don't care if it breaks". WTF?
That's not even remotely what the Debian devs said. The Google Devs choose to disable support for anyone who want to have a stable Linux experience, so Ubuntu LTS users won't have Chrome extensions until 2017.
Ah looks like Ubuntu fixed it, things change I guess :-)
Perhaps I read it after you did, but *one* maintainer said he wouldn't support it, and called it spyware. (I don't know whether it is or not.) Another said that if it turns out to be needed and someone submits a "quality patch" then he would submit it. (He also said that if Chromium needed it, he would revert the patch that made it a requirement, but that Chrome was a binary that he [and implicitly Debian] had no control over.)
I think we've pushed this "anyone can grow up to be president" thing too far.
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.
Moved on to....
I think we've pushed this "anyone can grow up to be president" thing too far.
A random Jane or John at Google shouldn't be able to tell you you're on your period this week, for instance.
Pretty sure everyone knows but you keep telling yourself its a secret.
Moved on to....
I wish I could mod you up. I was curious about the same thing. So many people saying they've moved on from Debian but never ever saying which distro they moved to.
I seriously question any one who would complain about this. They really must not understand how Debian releases work. Debian Jessie is frozen, which means there is a stringent process to go through in order to add changes, we have known it was going to be frozen for months and months. Their testing releases always go through a freeze period before it moves into stable. Stable means that typically the only changes are security fixes. Expecting Debian, a distro which really doesn't like non open source software anyway, to unfreeze for something like Chrome is just an odd request. If you need bleeding edge, you should move to a bleeding edge distro, I can recommend Arch as being fantastic for bleeding edge, there are plenty of others as well. Stable/LTS releases are not ever bleeding edge. In fact, stable/LTS releases are usually significantly behind. Or even better, they can go back to Windows. Wouldn't even notice if they left.
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!
That doesn't make sense. TSYNC is a security-enhancing feature.
Chrome uses seccomp-bpf for Sandboxing.... that is isolating certain threads from the system.
TSYNC facilitates software correctness with regards to the security. Without TSYNC, there is a greater likelihood of problems in the application leading to system compromise.
So I'm quite satisfied by Google's choice to refuse to run their browser on kernels that don't support current security features.
Firefox, Konqueror, Midori, Epihani, Opera, Arora, etc, should do the same.
Of course, they will have to implement multi-threaded Sandboxing functionality first.
Following the release; I anticipate good security reasons not to run old versions that require TSYNC, to reject the patch requiring it is a lot like rejecting a patch that fixes a buffer overflow or other typical RCE. The TSYNC feature impacts security, and the lack of the feature might eventually result in system compromise.
If they know so much about me, then why do I keep seeing ads that I have absolutely no interest in? I don't even own a fucking tv (never owned, never watched cable) and 3/4 of all my ads are of some new hbo programming of some stupid sounding shows.
If you don't own a TV then you're now a potential customer for one. Duh.
All they have to do is convince you it's something you need to have -- like with ads for hot new shows you're missing because you don't have one.
One distribution that has not gone systemd only is, of course, Debian.
Watch this Heartland Institute video
I'm instead amazed by Google's arrogance in stating that RHEL 6 is "too old" for Google Chrome. It's been that way since at least last summer, so my RHEL teaching cluster and workstations just don't have chrome installed.
Actually, that's not quite true - one user manged to get Chrome working, but it regularly consumes all system resources and crashes the PC. Result.
All in all, I'm happy to do without Chrome on RHEL 6. Will I try to get it working when I roll out RHEL 7 this summer? Possibly, but moves like this make me wonder if Google's a company whose products I want to install at all. Firefox ESR may have its faults, but it basically works, and I can trust it'll stay working.
Oh arse
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...
Does it, though? I've seen loads of claims of this behaviour, but usually it's just some muppet complaining about malware protection or getting confused about something.
Chrome's entire existence is to provide a good experience using Google's websites, some which people pay for (and so are not "the product", as the trite saying goes), and some which are ad supported.
You might want to slow down on the idiot-calling - you might end up being called one yourself.
The OS people are quite often right. Not this time, though.
We (OS people) are always right. Always. And if you don't like it, "patches welcome" or lump it.
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.
Reread the message. Google Chromium is called spyware. They don't want to add TSYNC to support this software bundle they consider spyware.
I'd expect the sandboxing improvements to land in Chromium at some point. Anyway, Chrome being non-free doesn't mean that Debian can't include the tsync backport and let people apt-get it like any other kernel update. Apparently it's a pretty straightforward port and is useful for other things (like LXC).
He meant that Chrome was spyware not tsync
This is a pretty good point. Now so many applications are being designed as server apps to make them more portable and universal and are on systems that typically would have a gui.
Some examples include sickbeard and sabnzb
The point is whether Google should even have this information. Some of us say no as the potential for abuse is large no matter what today's policy is . (you get my point, I hope, that the policy is merely words on paper with no binding value since there's a clause that says said policy may be updated unilaterally by Google with your only recourse being to not use the service(s) in question?)
The cesspool just got a check and balance.
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.
Not entirely true. Ubuntu releases a new hardware support package for the most recent LTS release at about the same time as they release a new version of the distro; that's a backport of the kernel used by the new version. In the case of 12.04 they basically FORCED people to install the new kernel after the release of 14.04; they are no longer doing security updates for the old one. There are also sometimes X server updates for LTS systems that have a GUI installed; there is one for 12.04 that uses the X server from 14.04 and is similarly mandatory.
So... you will be able to have new versions of Chrome and Chromium on 14.04... IF you install the hardware update. You won't be able to have them on 12.04 because the 14.04 hardware support is the last version that release will get. Nor can you have them on 10.04, which is near end of life and scheduled to go out of support next month.
GP answered that question: FreeBSD
Thank you.
Unfortunately I need something that will support ext3 for the transition cycle. (Or more accurately not being willing to disrupt my workflow while learning a new system means I need ext3 support.)
I think we've pushed this "anyone can grow up to be president" thing too far.
Reads to me like the browser will check if the flag is present, and if not keep on going anyways (perhaps with a nag to the user that things are less secure than they could be).
comment first, facts later. http://chem.tufts.edu/AnswersInScience/RelativityofWrong.htm
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.
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.
The Debian guys have always been anti-business. They don't like anything that's not open source. It's one of the reasons I abandoned Debian for Ububtu. Ububtu has made a lot of unpopular (wrong?) choices, but they understand the need for non-oss. In the end, an OS needs to support your work. There is no browser for Linux that is better for supporting web and heavy js. This is another case of Debian Philosophy interfering with its usefulness.
You don't quite seem to undertsand the concept of Open Source and "free".
Source code for Google Chrome is available free of charge under open source software license agreements at http://code.google.com/chromiu...
Yes, when others build it from source they call it Chromium. Claiming Chrome is nonfree is either an asinine attempt to flame or representative of a pretty poor understanding of the terms you are throwing around.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
RHEL teaching cluster and workstations just don't have chrome installed.
RHEL6 is 'too old' for a great many new things.... try Firefox or an older edition of Chrome I consider RHEL great for servers, but it's a horrible platform to base a Desktop build on, IMO.
Even if it's more bleeding edge--- I would stick with Fedora, or an Ubuntu or ElementaryOS based build. In the past I also used SuSE, for this.
LinuxMint is taking a "wait and see" approach to SystemD for the next couple years. The BSD sure aren't jumping on that ship.
RedHat is losing their "leadership" position, they do too many weird proprietary things and try to lock people into a weird "redhat way". Companies are ditching it last like week's garbage.
Industries "standards" are sometimes found to be stupid and they flop.