Google Chromium drops support for Linux 3.16 and earlier

Post by foogoespop » Sun, Mar 08, 2015, 4:25 AM UTC

rdtsc wrote: post #4

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 usua…

Post by ryanprichard » Sun, Mar 08, 2015, 4:36 AM UTC

teraflop wrote: post #17

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 See comment #47: "Ok, while it sounds like this is technically a regression, I'm going to mark this as Wontfix…

Post by xai3luGi » Sun, Mar 08, 2015, 5:03 AM UTC

stingraycharles wrote: post #18

redthrowaway wrote: post #7

Earlier quoted context omitted.

That seems like an exceedingly childish exchange.

I cannot believe these are the actual people responsible for Debian. Is this unprofessional attitude common in the Debian community?

Post by jfoster » Sun, Mar 08, 2015, 5:33 AM UTC

username223 wrote: post #19

wtallis wrote: post #16

Earlier quoted context omitted.

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.

> 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 s…

Post by sebcat » Sun, Mar 08, 2015, 5:44 AM UTC

taeric wrote: post #26

comex wrote: post #20

Earlier quoted context omitted.

Chrome isn't your average application, though - it pioneered the modern use of tight process sandboxes in general (in client-side applications, anyway), and in particular was the biggest motivating client for (and Kees Cook on Chrome OS Security wrote some of the code for) seccomp-bpf, the ~3-year-old sandboxing mechanism that allows precise control of permitted syscalls and syscall arguments. The incompatibility her…

On the flip side, chrome is also one of the tools used to convince people that web should somehow be equivalent to native. Which, really, just doesn't make any bloody sense. If web pages were content to showing web sites, the vast majority of the motivation for heavy sandboxing, Chrome style, would be irrelevant.