Keep in mind that Google Inbox is really just a fancy email client, albeit one implemented in the browser. I don't really care if they experiment with it, because I've always used a regular IMAP client instead, and I don't see them removing that option any time soon.

Open source hardware isn't viable, though, at least not in its own right. You need to make profit somewhere, and it's usually one of software, hardware, or support. The SoC manufacturers sell hardware - if they just gave it away by open sourcing it, they'd lose their biggest source of revenue. Pretty much all the open source hardware in existence is either bought by a small segment of zealots (e.g. any of the attempts at a completely FOSS tablet), or is sold as a loss leader (e.g. Sparkfun open sources the designs for their breakout boards, because they also sells the parts for them).

$ sudo lshw > hardware_info

The premise of the article is just weird - an article about programming languages with single letter names makes about as much sense as an article about operating systems with blue logos. That D is compared to C instead of C++ further demonstrates the author's cluelessness. (Many D programmers regard D as an improved, non-backward compatible version of C++.)

While I agree with your point, it is worth noting that there have been several studies over the last half-century disproving the diet-heart hypothesis.

You're conflating aspect ratio and resolution. If the 16:9 monitor is 1600x900, then a 4:3 with equivalent vertical resolution would be 1600x1200.

I use 2x 1280x1024 on my desktop, and 1x 1920x1080 on my laptop. I agree that 16:9 is almost like having dual screens, but it's just not as good. If you're going to use dual screens anyway, then it makes more sense to go with 4:3 and have one window per screen.

A semi-related issue is that Linux HiDPI support isn't quite there yet (KDE5 and Wayland aren't mainstream yet), so there's little reason to upgrade until then.

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.