Ironically, in the post-desktop era, UNIX started out the leader, with Linux fairly quickly taking a commanding percentage of deployments. It is now Microsoft who is so far behind that the odds seem insurmountable.

Sold!

You can't design a system to use an infinite amount of steam, and the Fukushima distaster, you couldn't contain the steam because of damage to the facilities (which, of course, got much worse after the meltdown). The design of the reactor was old, and has been superceded by more fail-safe designs, but that is not the root cause of the disaster. The root cause is the failings fo Tepco install and manage the reactors in a safe manner (high enough from the sea, not have its backup generators in the basement, lack of continual safety enhancements with new technology, etc.) was the root cause. While initiated by a tsunami, the plant was specifically installed with the knowledge that it would get hit by large earthquakes and tsunamis. The Onagawa nuclear plant, located closer to the epicenter of the earthquake, remained wholly operational. The difference? the company in charge of management's safety culture was different, and has been different for decades.

Mimmiths indeed.

I've had enough, first the click farmers, and now Planters© peanuts!

Wait...maybe I'm just hungry.

Or, more realistically, you're an idiot.

What they're trying to say, albeit poorly, is that from the waiter available for irrigation, drinking water, pools, lawn care, etc., a large amount is being used for irrigation. Because there is a shortage for everything else, they're saying about is being used for irrigating various crops, which in turn adds up to how much is being used for meat production.

Just because they say how much is being "used" doesn't mean they are implying it is gone forever. There is a finite supply (at current climatalogical conditions) of fresh water to use at one time. If you drain a lake to irrigate crops, the lake is still dry even if the water is still in the local environment.

Feel free to send an e-mail there as well. It will end up in the blackhole that is my junk address.

If it is the Satoshi Nakamoto, there is a pattern: a complete lack of the understanding of how personal privacy works on the internet.

1. He uses his own name, or at least a variation on it, when he created bitcoin.
2. He outs himself assuming he'd still maintain privacy because he's no longer "involved."

The fact that he's fairly old adds to the evidence. If he were in his mid 20s he'd never have used his real name or outted himself because he'd understand how privacy works (or rather, doesn't work) with respect to the internet.

Morning Glorys don't contain LSD, they contain LSA, which, while being a precursor to LSD, is very different.

This sidesteps the issue. Yes, adoption is an option for some, but not all. The cost and legal requirements can be quite high, whereas this is medical procedure to fix a disease (really prevent), potentially covered by insurance or a universal healthcare system. You're advocating the idea that those less affluent can only have genetically disease free kids if they themselves are free of genetic disease.

1

The unit is SE, for Standard Electron

In truth, like System V, it's a set it and forget it sort of thing for most users (or more realistic, never realize it's even there sort of thing). For me, I have about 40 servers, physical and virtual, and about 150 thin clients to manage using various shades of Fedora, CentOS and RHEL. The thin clients boot over pxe to and then connect via xdmcp to a Fedora 19 box for their desktop environment. As Fedora 19 isn't exactly the best, and users do strange things, one will end up getting rebooted every week or so. The thin clients end up getting rebooted all the time (people think they should turn off their computer at night, so they do). Being able to use journalctl to see exactly what process took how much time was instrumental in getting a fast bootup time, which makes users happier. Happy users = happy admin. Happy admin = the building doesn't get burned down in a quest to get back the stapler. Every time I have to mess with anything other than systemd (on the CentOS and RHEL servers) I die a little inside. It's like using ipchains instead of iptables. Yes it worked, but the world moved on (and yes, I know, iptables is archaic at this point in time).

Yes, you can do parallel startup with System V. You also can make a systemd init process that doesn't do anything in parallel.

Yes, systemd is smarter with dependencies in the sense that it has dependencies and not a numered list. Yes, you can have a System V script that manages it's own dependencies, but because you can do an infinite number of things with System V scripts many people have tried. I've ran across dozens of System V scripts that are hundreds of lines long even without couting the standard ". /etc/init.d/functions" size, which, on my system, is almost 600 lines long. Systemd simplies this by having a much larger library of functions and uses the presumption that you'll never call a script without using systemd to manage it. No longer does every script have to define a start, stop, restart, condrestart, status function; it's handled by systemd. No longer do you have to do checks for your PID file; it's handled by systemd. No longer do you have to make sure your script will always run after another script even if that script's chkconfig number changed; it's handled by systemd.

In the end, yes, it's another config language you'll have to learn, but it's worth it.

System V has a scrict sense of a run level. For example, if you want a full desktop, run level 5 is often used, for a headless server, run level 3. What if you have a box that is headless most of the time, but you want to be able to run a full desktop sometimes? With System V you would change from run level 3 to run level 5 which would, depending on implimentation, stop and start services that are needed by both. Systemd instead has the concept of targets. Your full desktop target would have the headless server target as a dependency, and starting the full desktop would only run what isn't already running. You typically also have individual sevices that have dependencies. For example, you'd want your dhcp server to wait to start until the network has come online. In System V you have to define network as a number and make sure everything that depends on it has a bigger number and everything it depends on to have a smaller number. systemd's dependency model is also smart enough to start processes in parallel.

All of that is just the most exposed part of systemd (to me at least). It also supplants other processes such as xinetd and udev. Instead of having three different ways to start processes based on system events (startup, port connection, hardware event) you have a single system to manage all three. It can get complicated (wasn't udev already complicated?) but the consistency is worth it.

To keep all the consitency systemd provides a series of functions and magic variables. By magic variables I mean you set a list dependencies, which IMHO is less magic than the chkconfig comment lines in a typical System V init script. Both the magic variables and functions mean your typical service initaliation script is 10 lines instead of 100. While they may not be as obvious what's going on (a System V script is self-contained and can be ran on it's own) it is once you've become familiar with them.

At a point when even the cheapest SoC has more processing power, memory, and storage space than your current desktop the cost of learning and using a custom system like Busybox will outweigh the benefit for many. For devices that need instant-on capabilities I don't think it's realistic to expect anything other than a custom init, but for the rest I expect programmers to programmers; that is, lazy.