The big problem I see with this is the fragmentation it would cause. Quite frankly, the US already has issues due to their major mobile phone networks using different frequencies. Having different frequencies for the same network, within the same country would just exacerbate that.

I would argue that where the frequency is used for a standardized protocol, they should be required to allow others to use it, providing they are compliant with the appropriate standard. Allowing other frequencies to be allocated for competing standards would only be permitted where there were clear benefits to doing so.

Why would he? Wine runs as an unprivileged user - the only reason he might have needed root access is to open one of the privileged ports.

I think this is only part of it. I grew up using Windows (and am consequently lost on Macs), but I found Linux easier to learn than Windows. This may be partly due to my technical inclinations, but I think that variations in usability and documentation can make a real difference to how easily you can learn to use a system.

Given that this is Debian we're talking about, the the right comparison is with an LTS kernel, not a stable one. 3.17 is already EOL, and it was only released in October. The most recent LTS kernel is 3.14.

That said, Jessie is currently running 3.16, so there's likely something I'm unaware of regarding Debian's kernel policy...

The change is an improvement to sandboxing (i.e. security). If the kernel patch was sufficiently minor (this appears to be the case), it makes far more sense to backport it (improving the security under older kernels) than to remove it (compromising security under newer kernels). This is especially true given Debian's focus on security.

Most of the comments in the thread seem to be from people who don't care, but are happy to use it as an opportunity to bash Chrome/Chromium. I suspect if someone had actually done the work of writing a patch, it would have been merged without much drama.

While I agree that it's questionable whether systemd is suitable for Debian stable, I would hardly describe it as resulting from "dirty politics".
The reason that systemd got adopted is very simple: it means less work for distro maintainers. Systemd .service files are much easier to maintain than initscripts, systemd comes with logind (consolekit is unmaintained, and no one is interested in picking it up), and perhaps most importantly, Red Hat is pushing it (which means that they would contribute significantly to porting programs to it. The only real alternative to it was OpenRC, which doesn't fix the consolekit issue.[1] The maintainers were the ones making the decision, so they put their interests first, as opposed to that of their users.

I agree that systemd has some architectural issues (just cause you choose a binary log format, doesn't mean you need modify the start of it on each update) and management issues (it should never have assimilated udev without continuing to support its use without the rest of systemd), but its adoption was entirely due to the opportunity cost of choosing anything else, as opposed to politics.

[1] For the record, I think that OpenRC would have been a fine alternative for Debian. While it doesn't have as much upstream development, it doesn't need to as it's a mature product.

I've been using Sabayon for a few years now - it's a nice combination of some fairly nice features (being able to mix entropy and portage, Gentoo-style config file management, fairly bleeding edge packages) and making other things just work (bumblebee, UEFI). I agree that the documentation is a bit weak (downside of a small community), but in practice the only difference from Gentoo is the package manager and default config. (The Arch wiki is also quite useful.)

SystemD works pretty well once you get the hang of it, and these days pretty much everything supports it. Most of the criticisms of are concerning its architecture and management, rather than functional problems. (I think the most significant bug I've seen with it in the last year or two is that systemd-journald needs to be manually restarted if your rootfs gets full, which is fairly minor as bugs go.)

I suggest making backups of your root file system (btrfs snapshots are perfect for this) before updates though - I've had a major regression about once a year, on average. (To be fair, one of them was due to me doing something very unsupported with glibc, and the other due to some somewhat uncommon hardware. Both were fixed within a week as well.)

Feel free to reply to this post with any questions you might have about it. It definitely doesn't get as much attention as it merits, IMO, so I'm always happy to help out people who are interested in it.

More importantly, slashdot.jp can handle it too. It's probably trivial to port the code across - I'm surprised no one has done it.

Their APU lines are pretty nice. Their FX line was great 3 years ago (much better performance/price ratio than Intel), but it hasn't gotten any significant upgrades since then.

The file command (which uses /etc/magic) works fine, but the mimetype command will defer to the file extension unless the --magic-only flag is passed. Most DEs use the mimetype command, since the output is easier to work with.

Perhaps, but I suspect Intel could more than balance it out by adding a few developers to the Lima project.

It's not an either-or. I use FB for keeping up with friends and family (i.e. people I know in real life), but G+ is a far better platform for following hobbyist groups (e.g. distro pages) and celebrities (e.g. Linus Torvalds), because it allows non-reciprocal connections. That is, I can follow Torvalds' public posts without him needing to follow me.

Which means that the most useful data points are the projects which went through the effort of migrating between libraries. e.g. Subsurface which moved from GTK+ to Qt, and written by Linus Torvalds (among others). The reasons for doing so are given here. This is particularly interesting given that both Linus and Dirk prefer C

In my experience, the Qt libraries and tools are just as easy to use as .NET Framework + Visual Studio, which I think is excellent (and particularly impressive, given that Qt definitely doesn't have the same resources as Microsoft). I haven't used GTK+, but looking at the Hello World tutorial for it, it doesn't seem particularly intuitive. (e.g. why is the button label set with a callback?) Admittedly, there is some bias due to familiarity here, but I think my point is valid.

Github provides (private) hosting for proprietary projects, for a price. My guess is they didn't realise the gist wasn't protected similarly.

Easy way to find out: Mega could file a tortious inteference suit, and subpoena Paypal for the details. If it was one of the major processors, it'll be revealed and they can avail themselves of damages. If it was an NSL, that will become apparent too.