I'm not sure. A typist generally won't hold down a button for several months as this person allegedly did.
A brainfuck programmer who needs to access a big chunk of memory, on the other hand...

No, phones already had the capability. A telephone without a microphone would not go over well.

Slashdot: Olds for nerds, stuff.

Note the words "up to". That does not mean "typical" or "guaranteed".

True, and the solution to that should be that nothing except emergency fixes goes into the stable branch until it's tested in unstable.

And I disagree with the AC you replied to that Torvalds has god complexes. Not so - he's quite capable of changing his mind as situations change, which his change to discard odd/even is just one example of. He has made mistakes in the past, and will probably be the first to tell you. However, he's a leader type in that he's willing to make hard decisions even when they could potentially be mistakes.

Indeed.
2.0 -> 2.2 -> 2.4 -> 2.6 all heralded major changes, while 2.6 -> 3.x did not.
I think there should have been one major lift (to 2.8?) in there with devicetree - that's a big change that introduces lots of potential incompatibilities and required changes to userland. But that one went in a minor number, which seems rather wtf to me.

My recommendation: Switch to 4.1 and go back to an odd/even system so 4.2 will be the next stable.
Also make a marker for whether a stable kernel is also designated long term stable, because right now you have to just know which ones are LTS, or you have to look it up at Cox' or Morton's sites.

Outside production, yes.
In production, no way. The amount of work required just to try was determined to be immense, and there were incompatibilities from the start that seem prohibitive - like systemd taking over cgroups, while we already use cgroups for our own purposes, and hal not working because of incompatibilities with the "improved" dbus, and we rely on user-triggered external hardware detection, not system-triggered.

I currently run a test system with EL7 that does not need cgroups and hal, and when it works, it is not much of a problem - but that can be said of any software, regardless of quality. It's when it doesn't work, and a boot crashes that systemd leaves you stranded. If you haven't provoked boot problems to see what happens, and how to recover, you have not truly tried EL7.

The problems with systemd is when it doesn't work. You risk a system that's inoperable - you can't boot to single user mode and you can't even check logs from a different system, because they're not humanly readable and not committed. And you can't single-step through the tasks one by one and see what happens.

Never mind that it's also MSDOS .ini file based, which is about the most automation-unfriendly system there is. What a key is for depends on which section it is in, and there's no inheritance whatsoever. It's a file format that should have expired in the 90s, and thankfully never caught on in the Unix world. Because of that truly WTF choice, modifying settings through scripts becomes an error-prone headache.
And at the first error - boom, you have a system that can't be brought up or troubleshot. Better keep a bare metal backup handy.

What this sysadmin cares about isn't how fast a system boots[*], but that it's stable, consistent, has as few dependencies as possible, is debuggable when the shit hits the fan, and that no one failing part can bring down the whole house.

[*]: When an IBM system spends ten minutes in pre-boot running self-checks and enumerating all the SCSI disks, I couldn't care less whether it cuts the boot that follows down from a minute to half a minute.

I could live with hal. It provided useful functionality. Although whoever created the command line interface to hal must have been a masochist who loved typing and had an aversion to allowing more than one qualifier per command.

for udi in $(hal-find-by-capability --capability storage); do
    if [ "$(hal-get-property --udi=$udi --key storage.removable.media_available)" = "true" ]; then
        hal-get-property --udi=$udi --key block.device
    fi
done

try (this.that->matter(opinion).is())

It also provides its own bug opportunities. Indeed, from looking at what Coverity finds, most defects wouldn't have existed without the fluff.

I'm not advocating that people migrate to assembly or perl, but whenever you cannot point at just where something happens, you have overused abstractions.

They still modify the content. Say I use wget to recursively fetch a web site I run on the outside somewhere, and burn it to a CD for someone to look at. Then they will see the content that Cox inserted. That's not cool at all.

Something is wrong if you have to rely on SSL to protect you from your own internet provider!

That won't necessarily solve the problem. The only high speed internet provider where I live has rewritten HTML on the fly to serve their own content. I would not hold my breath that they won't do the same for video.