Yes, they were certainly less efficient than modern engines. However, ICE engines have always had trade-offs between power output per size, mechanical efficiency and reliability, and for this vehicle the last one was certainly of most importance.

output probably contains all the output that doesn't depend on input (which this program doesn't have).

Neither does any other of the hundreds of existing text encodings.

It's debatable how much of a magic number it's supposed to be anyway, considering that few people have insisted on having magic numbers in text files, and that you get the BOM at the beginning by simply naively converting a UCS-2/UTF-16 file codepoint by codepoint (and vice versa, enforce it to be there if you ever happen to do the conversion the other way around because of course you're conversion couldn't include that extra logic in it).

That's generally not true. At best you'd roughly match an average car when balancing your weight perfectly; but typically you can only expect worse results when comparing the two.

Or you could just move the mouse with your fingers. Other positives include requiring much less space and not looking silly flailing around. (My preference is maybe 1–2 cm corner-to-corner, with no wrist related issues a couple decades in; and obviously, mouse acceleration is a great idea.)

That has less to do with POSIX compliance, as opposed to working around quirks with less-compliant historical implementations. Also, I think you'd have to dig pretty deep to find a test that doesn't support zero-length arguments; you'd be safe as long as you quote your variables.

The actual problem of ambiguity arises from variables that are also syntax, like '(', or '!', when using compound expressions (which you should avoid anyway).

  # this is bad (also obsolete)
  [ "$var" != foo -a "$var" != bar ]
  # this is good (and fully POSIX compliant)
  [ "$var" != foo ] && [ "$var" != bar ]
  # you probably don't need to care for systems where this was necessary
  [ "X$var" != Xfoo ] && [ "X$var" != Xbar ]

IMO this thing is way overblown. What applications these days do not simply use primary and clipboard selections in a consistent way? (FTR I like them separate very much as I would hate to have my clipboard contents change by simply selecting some text.) Middle click is not a shortcut for Ctrl+V!

Ctrl-C is indeed used to send SIGINT to the foreground processes in terminals and thus terminal emulators, and the established alternative for terminal emulators is to replace Ctrl-C/V copy/paste with Ctrl+Shift+C/V (I think that's how even cmd.exe works these days). Copying and sending a SIGINT would hardly be a useful default.

This is not really a debatable matter. There's an international standard for what is, and what is not a part of the C language.

Errors as you seem to understand them are optional for everything else except for the #error preprocessor directive. For all the other invalid C programs, only a diagnostic (like the warning you got) is required, and a conforming implementation is free to complete translating the invalid translation unit. I don't see why that would be an issue, as it's very easy to switch those warnings into translation errors if wanted.

Broken or ancient compilers. That's as much C's fault as it's Intel's fault that Windows 10 doesn't run on Pentium MMX. Implicit functions are not part of C; they were gotten rid of back in 1999!

You definitely can, at least if you allow manually vectorized code.

On my system, with a 1.661GB file (256 times big.txt from the original Haskell post) GNU wc takes about 6.5s (real time), a stripped down version of Apple's implementation about 4.1s, and a single-threaded vectorized wc (written in C) only 0.27s. (These times are of course only with a hot cache. For reference, catting the same file to /dev/null takes about 0.18s.)

edit: corrected the time for the BSD-derived implementation

Speak for yourself. I certainly think blasphemy laws are certainly way past their due date, and more extreme restrictions (e.g. like in Germany, but notably not everywhere in Europe) definitely at least borderline on the dystopian side.

And as to what an average citizen might think: perhaps an average Chinese considers their “free speech” laws, or their closest equivalent, quite reasonable after having been taught so all their life. Europe could certainly do with freer speech.

edit: the whole system is more complicated than this, of course, but the point here is that this safety net is permanent – you can not lose it even if you are unemployed for a long time (recently, a tiny reduction of welfare payment was introduced for those who do not meet certain criteria for activity; however, you are in any case entitled to certain level of income, and government-paid rent, etc., in any case.)

However, as far as user experience goes, I don't share your experiences at all – the web player is almost unbelievably bad, with frequently malfunctioning (disabled) player keys, volume slider jumping all over the place and common problems when resuming playback after a while. (Also, the desktop application has more features, including the ability to select multiple tracks to perform an operation on, and naturally the support for media keys.)