The only reason, AFAIK, is because it's of strategic advantage to the systemd project, and by extension, Red Hat. (If someone has evidence to the contrary, I'd love to hear it.)

I've used systemd since mid-2013, and since then I've acquired a fair few reasons to dislike it, but it's the management of the project that bothers me more than any technical aspect. The systemd modules all seem to depend on the process manager and journal. The process manager requires that systemd also acts as init,* and user instances require a root instance. None of these dependencies need to exist - even the journalling library could be replaced by a shim that just forwards everything to stderr. Traditionally they would have been separate projects and such dependencies wouldn't exist.

* Systemd is a much better process manager than SysVinit, but there was never any reason to prevent the user from choosing another init.

The problem is that they aren't under the same contract as another generation company; they're just given a flat rate. The generators are subject to dynamic pricing that varies by the hour, and those prices take power factors into account. In certain regions, at certain times, the price of electricity can even go negative if the mismatch between demand and supply gets too great (this is typically associated with large wind/solar installations, which are inherently unpredictable).

Of course, the reason they're given a flat rate in the first place is because dynamic pricing would be too complex and unpredictable for the average consumer, even though it would result in a more efficient system. Ultimately I suspect they'll just offer a mean price that compensates for this, with dynamic pricing as a possible alternative.

Generalized Bechdel test: how many movies have conversations between minor characters that are about something other than the main character?

When you flick a pencil in the absence of gravity, you impart both translational and rotational momentum to it, both of which are conserved. Flick it in the center, and it will fly forward, and you backward. Flick it at an extreme*, and while it spins forward, you will spin backward. Flick it anywhere in between, and you'll get some combination of those.

* I doubt you can flick it without imparting any translational momentum in practice, because your finger is not infinitely thin.

Rather than choosing specific resources, you might find it more helpful to look for comprehensive collections. e.g.

• Wikipedia - because if anything comes close to being the sum of human knowledge, this is probably it. [10 GB]
• A complete mirror of the packages available for your distribution of choice (I suggest Debian stable [60 GB], though Gentoo [160 GB] might be worth considering if you want more flexibility and don't mind the compile times.). This will allow you to experiment with a language/program/etc. even if you don't have it installed when you leave.
• Project Gutenburg [8 GB]

In addition to these, any of the standard comp sci books (e.g. the Art of Programming) will give you something to mull over. Learn a functional language if you haven't used one before (I suggest Haskell).

I'll second that. It seems to be purely a matter of corporate backing - Go and Rust have received a significant amount of funding from Google and Mozilla, but D hasn't gotten much more than a few conferences sponsored by Facebook.

If it's not supported on WINE, then it's completely random whether or not the WINE demographic will buy it, and MBA-types tend to prefer predictability.
Furthermore, if it does work well under WINE, that implies the effort needed to port it is minimal - simply bundling WINE (or a similar translation layer) with it would be sufficient. In my experience, there isn't much support available for games anyway, unless it's a game-breaking bug that affects a large number of people.

I think you've mis-characterised the demographic. I single boot Linux (because dual booting is a pain), but I still buy Windows games via Steam that work via WINE. If a game isn't playable under WINE (which is increasingly uncommon these days) and doesn't have a native Linux port, I simply don't buy it.

Valve knows exactly how many people are doing this, and my guess is its a small but non-trivial number.

That's actually a rather interesting question.
As with many things in law, it's the result of historical precedent (aka legacy code).

So basically, software is copyrightable because blueprints are copyrightable, and later legislation was passed to codify this (and legislation doesn't need to be well reasoned or justified, merely politically tenable).
This then leads to the question of why blueprints are copyrightable.

So basically, architecture is a combination of art and functional aspects, and only the artistic elements were ever intended to be covered. The problem is that because the judiciary (in most cases) don't understand programming, they are unable to distinguish between them adequately.

IMO, computer programs in general should never have been considered to have an artistic element (and I say that as someone who appreciates beautiful code). A building may be said to have artistic elements because it serves two purposes: a functional one (to provide shelter), and an artistic one (to look good). With the exception of examples in textbooks (which are copyrightable independently of this), code is almost never written to look good, merely to serve a functional purpose. While it may be beautiful, that it not it's primary purpose. They should have been regarded as purely mechanical, and covered by patent law instead.* At this point in time though, it is likely impossible to fix that flaw, given how disruptive it would be.

* I think that software patents should exist, but not in their current form. While computer programs are mathemathical in nature, so are many other patentable creations. For example, the negative feedback amplifier was well-deserving of a patent (given how revolutionary it was at the time), but each of the components in that circuit could be well-defined mathematically. If the requirements for a patent were enforced properly (i.e. novelty/obviousness and the limitation to an implementation, as opposed to a goal/idea), then they would actually be useful.

You have a fairly well-written (if lengthy) post, but it is based on the assumption that the law should be consistent. However, pretty much every law has exceptions added. e.g. murder has self-defence and (in some jurisdictions) euthanasia, copyright has fair use, etc.

I consider APIs to be the digital equivalent of forms. You submit a form to a department that accepts it, and you get another form back. The layout of the form (which sections are on which pages, whether you have boxes or grids of bubbles) affects the efficiency with which the form may be processed.
Forms are not copyrightable, for many of the same reasons that APIs should not be copyrightable.

From Wikipedia:

That says it all, really. A CS degree is not supposed to be preparation for a career as a software engineer - it's preparation for a career in CS. Degrees in software engineering already exist and serve that purpose, though it sounds like Stanford didn't have one in 2000.

Debian is probably the second most influential distro, after Red Hat. One example of this is how Canonical dropped support for upstart after Debian adopted systemd as the default. (And don't forget how many distros are derivatives of Ubuntu.)

If Debian imposes a requirement that packages do not depend on systemd, then that will have a significant effect. That said, some larger projects do have enough influence to block them from doing so. e.g. not being able to run Gnome would be a pretty big blow to them. Ultimately, distros and upstream projects have a symbiotic relationship, so the larger players on either side can influence the outcome.

This is Debian we're talking about, not Gentoo (and I say that as a Sabayon user). For most packages, you're limited to whatever configuration the maintainer decided on (which is usually the one with the most features), since the alternative would be to have a separate package for each version. e.g. vlc and vlc-nox.
If you really want that level of control, Debian is not the right distro to be using.

systemd is the default init system, etc. in Debian Jessie.
It is currently undecided if other init systems will be supported, and whether users upgrading to Jessie will be automatically switched to it.

If other init systems are not supported under Jessie, and you wish to avoid systemd, your only choices will be to continue using Wheezy (until it's no longer supported), or to switch to a different distro.

The decision to support other init systems will be posted here: https://www.debian.org/vote/20...

Keep in mind that Linux is just a kernel, even if most people use the term to refer to the entire OS. If you can run Linux and X (or Wayland) on it, that opens up a lot of options, such as KDE Plasma Active, Jolla, or even just Gnome 3.