Firefox works on Wayland now. So, unless you have redefined Firefox as a non-major browser, "is far from certain whether any of the major browsers will ever run on Wayland" is flatly wrong. Also: https://github.com/01org/ozone-wayland
And the obvious point is that turning ChromeOS into a full linux distribution defeats the point of ChromeOS itself: to have very few "moving parts", and only those necessary to launch Chrome. Also, the bulk of the work "for wayland" is not wayland itself: it is KMS/Mesa/glamor/libinput, which are already used by ChromeOS (except for libinput, I think).
Can I run Firefox on Wayland without X, i.e., without XWayland or some other compatibility layer which includes most of X's source code files?
If so, do you know where I can download it?
>turning ChromeOS into a full linux distribution defeats the point of ChromeOS itself: to have very few "moving parts".
Just because that is why Google created ChromeOS does not mean that those of us uninterested in Google's vision cannot bend it or parts of it to other purposes. It is after all distributed under open-source licenses.
The FSF's interpretation is valid for GPLv2 and LGPLv2 as well, since the line "You may not impose any further restrictions on the recipients' exercise of the rights granted herein." is also in there (not everyone agrees with this interpreation, but that's beside the point). The anti-tivoization clauses are not considered to be the problem, generally, since app developers are not distributing tivoized hardware or tivoizing it with their software.
Also, the path for solving compliance problems for (L)GPLv3 is much more well defined, as opposed to the case of v2. That's a plus.
I don't think they'll change it anytime soon. I don't like it at all, and I agree that it is almost dangerous, even though I sort of understand the rationale seeing how non-technical users handle volumes.
It's also kinda of hard to expose in a GUI: a checkbox with "Flat Volumes" is not really self-explanatory. For now I've just added .config/pulse/daemon.conf the config files I drag from one installation to the next.
Non-technical people do a whole lot of strange things. But then i likely do so to in the eyes of someone formally trained in computer operations. Frankly i have learned to grin and bear with them, thanks to being tech support for my parents for over a decade.
On the other hand we should expect nothing but good things from esteemed GPL violators such as Allwinner and WMWare, right? /s
EDIT: I guess I should qualify the statement wrt WMWare as "supposed violator", since the case isn't over and I haven't looked at the source code.
Allwinner actually signed up as part of an attempt not to be a GPL violator anymore, along with releasing the source to a bunch of their stuff as GPL or LGPL. Thanks to their newly-found interest in compliance I think they may actually be the only company shipping hardware-accelerated MPEG and h.264 decoders that don't require any kind of closed-source code. (Unfortunately, the VP8 decoder is closed still because VP8 isn't copyleft and they can get away with it.)
It is a rebuttal to the implication that the possibility of the community electing some nefarious personality should be considered valid ground for denying said community any representation. By the same token a bunch of corporations should be denied one.
I didn't interpret the post as call for reformed governance, unless you consider
It's not that I think they'll be motivated by altruism, but they presumably have some commercial skin in the linux game. Enough to get them paying those large foundation membership fees at least.
That only hides the pid directories of others users, and indeed on my system remounting /proc with hidepid=2 I'm still able to see the same values for kallsyms. Maybe your kernel is compiled without the CONFIG_KEYS=y option? (I'm spitballing here).
No, the bug is in the kernel keyring facility, so if I'm not mistaken compiling with CONFIG_KEYS=n option should protect you (I haven't tested though). As for the /proc/kallsyms, I honestly don't know how come you only get zeroes.
EDIT: The obvious question I should have asked is which distro you are running. Also, as others have pointed out, hoping that the attacker can't read kallsyms from the machine he's attacking is not really a good defense plan.
I'm running Ubuntu 14.04 which should be affected. I just hoped it would be harder without having the correct kallsyms version. It seems I will have no options except to reboot my cluster :)
SMEP would stop this particular exploit because it returns into usermode but SMEP is trivial to bypass on linux if there is no KASLR or other mitigation (apparently there are compiler plugins that remove popular stack pivot gadgets).
According the lwn comments it should be sufficient (and the post by perception-point suggests that it would at least make things more difficult), but I haven't the hardware to test for myself.
While the fact that since last fall grsecurity only ships the stable branch of the patchset for sponsors (because of persistent trademarks violations) doesn't help integration in smaller distributions (also Debian, I would guess), I am always baffled as to why grsecurity/Pax were never chosen by a distro like Suse to differentiate itself from Red Hat.
As others said, using a kernel with the Grsecurity patchset would prevent the issue (I believe the configuration of SElinux on Android should be sufficient, but the default config in RHEL7/Fedora is insufficiently strict).
Both in the case of Office 365 and that of Azure they are selling you their cashcow (office and windows), only in a software as service fashion.
Moreover, neither is opensource, unlike cloud offering based on Xen or kvm, which are (at least to some extent).
I fail to see how Sun fares worse in this comparison, if this was your point.
And the obvious point is that turning ChromeOS into a full linux distribution defeats the point of ChromeOS itself: to have very few "moving parts", and only those necessary to launch Chrome. Also, the bulk of the work "for wayland" is not wayland itself: it is KMS/Mesa/glamor/libinput, which are already used by ChromeOS (except for libinput, I think).