Notably including Alan Turing, who was chemically castrated with synthetic estrogen, and eventually committed suicide. I am glad to read that he was formally (royally) pardoned at the end of last year. I cannot imagine who thought castration was an appropriate response, especially given the long traditions of "rum, sodomy, and the lash" in the British Navy, but I suppose one must make allowances for the past, even if it is within living memory.

No, I mean what I said. Whether or not doorknobs should be painted purple is also not a scientific issue, and I take no position on it. I have an opinion about the rhetoric being used in this debate, or should I say the style of demagoguery.

On the one hand, I have no problems describing Monsanto as an evil, duplicitous corporation. If you read the link I provided, their only issue with PCB toxicity was getting all the money they could out of it before the public caught on. On the other hand, there has been and continues to be considerable scientific scrutiny of the dangers of GMO products, which was not the case with PCBs for at least several decades.

With regards to labeling, if it's not an immediate health hazard, I don't really care: it's not going to affect my purchasing habits whether or not it's there. I would support the idea of data being made available to the public on the Internet, and wouldn't you know, there are already several sites where said information can be obtained. Similarly, no one has been able to demonstrate any harm (to humans) from rBST milk; it's not something I am going to loose sleep over. It's not a health issue, it's not a scientific issue, it's just a marketing ploy. I'm not very amenable to marketing, still less so to frenzied, largely factless ranting about hypothetical dangers.

If you want to make this a personal crusade, then I am happy for you. I have enough real problems in my life that I don't have to go looking for more. If you have room in your life to be worried about the genetics of the food on your plate, that puts you ahead of about 90% of humanity. Some day I will have to return to the first world so that I can have those kind of problems too.

As an aside, I don't think "exerts" was the word you were looking for. You maybe meant to use "exhibits"? I could perhaps "push" or "peddle" an opinion, "exhibits" is a little passive.

systemd doesn't restart crashed daemon unless configured to do. It is also really smart about restarting daemons with rate limiting and timers and what not. systemd can distinguish between manually stopped daemons, and those who have been SIGHUP'ed or those with a unclean exit code.

Look here under the "Restart=" option for more details:
http://www.freedesktop.org/sof...

Yes, systemd stops and goes into emergency mode if some hard disk in fstab doesn't show up. This is the right behavior. You can really mess up a system if you allow it to boot with missing mount points. SysVinit and similar init systems may allow booting of a broken system without any notification, but that is simply buggy behavior.

systemd does complain loudly about missing entries in fstab, a quick "journalctl -b -p err" would show that.

Mounting devices with "nofail" in fstab will allow systemd to continue to boot even if the devices are missing, since that implies the admin knows the system will be all right despite missing discs.

systemd's journal is an open standard with a stable API and many language bindings. There already exist independent journal readers; they are easy to make.

Personally I don't care if there was forty trillions programs that could read legacy style text logs. If they don't provide the same power and ease of use as systemctl, I won't bother using any of them.

And the sad fact is, that old style text logging and parsing has several fundamental problems. They have a chaotic and messy structure where the actual wording of the error messages have become an API, so if a program changes the wording of its logging strings, it will break all kind of watch scripts.

Legacy style text logs don't have any rich meta data like monotonic time stamps etc. And if you try to extend the content of the log files they become more and more unreadable for humans, and it will break watch scripts.

There are many problems with text logs and as time goes by, and systems dump more and more info in the log files, the more these problems will be exposed.

I am fully aware that the systemd-hating techno-Luddites will deny that there are any problems with text logs, just like they will deny there are any problems with SysVinit. Everything is perfect and can't be improved according to them.

So sure, go ahead and use an unmodified SysVinit for the next 30 years too together with syslog text files. But don't complain that somebody else are tackling these problems like systemd does.

Ah, so it was a made up story about systemd simply because you don't have the technical insight or knowledge about systemd to give are real example.

Like what?
You do know that backwards compatibility was a primary design goal for systemd, so that it worked as a drop in replacement for SysVinit/Upstart. You don't have to modify your programs to work on a systemd distro, it will read SysVinit scripts just fine, and understand syslog style logging too.

That developers are starting to use systemd features, is simply because systemd help upstream projects solve real world problems. systemd is all about making things work better on Linux, for both the end users, distro makers, and developers. This is why it has gained such widespread popularity and adoption.

Why do you think you need to modify vi to edit systemd config files? All systemd config files are just text files.

The basic lack of knowledge about systemd among those who dislike it is simply embarrassing for the Linux community; it is like people have forgot what a "man" page is, that sometimes you actually have to read up on stuff in order to understand it.

Seriously, try reading up on systemd: It is cool new Linux tech with lots of exceptionally fine features:
http://www.freedesktop.org/wik...

That is just wrong. Please read up upon the systemd project before having strong opinions on its design. Don't rely on people foaming at their mouth with rage for information on how systemd actually works. In the future, all major Linux distros will use systemd, so it is prudent to actually read and understand it. This is a good starting point:
http://www.freedesktop.org/wik...

First, systemd is of course split up in multiple processes each running with their own PID.

Second, in those case where there is e.g. kernel feature integration, systemd follows the most logical way to design a system. The reason why you don't see a systemd re-implementation done in hundreds of little independent modules, is that is a bad design with a huge overhead, when a module needs to talk with 3 other modules, that again needs to talk to 3 other modules every time a daemon request whether it eg. have more cgroup slices available.

So systemd is designed the way it is because it is meant to solve real world problems better than anything else out there, not be a show case of some dogmatic design philosophy.

Interesting problem; if systemd had taken existing sNTP and DHCP clients, modified them so they fitted the systemd user case, the systemd developers would have been accused of "subsuming" other projects.

I think it is important to understand why systemd made a sNTPv4 and a DHCP client; in both cases it was user requests, and it was all about OS containers. Most sNTP and DHCP clients are made for stand alone systems, but the OS container density on a system is between 10 to 100 times that of a system running VM's.

That means a server, instead of booting 5 VM's will perhaps boot 250 OS containers. That is 250 instances of Fedora/CentOS/Debian that all wants a DHCP lease and syncing time at the same time.
Reducing the time for getting a DHCP lease means significant time savings. In this case systemd developers improved DHCP connections times by reducing the time spent in getting a lease by a factor of 1000. Very cool.

As it is now, you can now boot an entire Linux OS container from zero in 100ms, including getting a DHCP lease. That again means Linux OS containers on demand.

http://www.phoronix.com/scan.p...
https://plus.google.com/+TomGu...

As you can see the DHCP client and server is implemented as a library, meaning everybody can use their work for their own super fast DHCP implementation.

Of course, no one is forced to use systemd's versions of sNTP or DHCP. Their versions are made for speed, not for features.

Yeah, I used the term because you did, it seemed apt. I will more politely request that next time you might lead with data and not diatribe.

Labeling is not an issue I take a position on, actually, except to say that the subject is not itself scientific. We're not talking about data being made available to researchers. Whether the public has a right to know is an important issue, but more of a marketing and commercial interest than a scientific one.

If those studies are all we have to worry about, I will not worry too much. Thank you for providing the links. One question though: on the off chance that GMOs are the significant danger that Taleb thinks is possible, what will labeling help?

Oh, come now, you left out the best story: Monsanto secretly poisons Alabama town.

However, I do think you're completely trolling with this anti-GMO riff. Monsanto being a bunch of evil bastards does not mean that GMO is automatically harmful, and there is a distinct lack of factual evidence in your post to support that idea.

I am not interested in rhetoric. If you cannot show harm, then you are in exactly the same position as anti-vaxxers. If you want to argue that there should be rigorous testing of GMO organisms, sure -- vaccine manufacturers eliminated whatever minute quantities of mercury were used in the manufacturing process based on hypothetical dangers, and there's no reason not to be extra-careful when dealing with possible biological threats. If that's what you're after, maybe you should try mixing in some alternative content with your FUD.

1% is a bad number to use, especially out of context. 1 degree C is better, but the more exact answer is 3.7W/m^2. The Earth receives about 240W/m^2, which gives us a black-body temperature of 255 K, or -18 degrees C. The observed global average temperature is about 33 degrees higher than that, thanks to the atmosphere.

The effect of an increased partial pressure of CO2 is to extend the CO2-rich region further into space. Outgoing longwave radiation (OLR) has a low mean free path (which varies with altitude but is generally in the low tens of meters), so it doesn't make much difference near the surface. The lower atmosphere is already more or less opaque to IR, so the effect is for OLR to take slightly longer to leave the upper atmosphere. Overall this means that the system retains more heat energy, by a tiny amount.

The problem is that CO2 isn't the only gas in the atmosphere, and there happen to be huge reservoirs of a much more effective greenhouse gas covering some 70% of the Earth's surface. It would be nice if either we could figure out another way that heat is transferred to space, or if there were some agent in the upper atmosphere that would counteract the effect of CO2. The first one can be ruled out by the physics of radiation, and the second one has not been observed by satellites. So, that leaves us with a certainty of 3.7W/m^2 per doubling of CO2, plus water vapor feedbacks, which are likely to be strongly positive, because the amount of water vapor that can be held in the atmosphere goes up exponentially with temperature, and as stated, water vapor is a much more effective GHG than CO2.

Not the people, but business.

Doing things the green way is usually more expensive. Most companies would be happy to dump toxic shit in to rivers, and pollute the air if governments would let them. So if Europe says you have to do X to keep the environment clean, and X costs Y, some companies will pay Y amount and others will move so that they don't have to do X.

Nike could pay people a decent wage in the US to make their shoes. But sweat shops in the developing world are much cheaper. This is the same issue, but with the environment instead of wages.

This summery is appalling.

The bill in question Bill C-13 was introduced almost a month ago and passed two readings in parliament before the attack. Canada has been debating this bill in parliament and in the media for some time. I don't agree with this bill, but to label it a reaction to the shooting is completely wrong. Especially bad is the fact that a quick google search would have been enough to identify the mistake.

http://openparliament.ca/bills/41-2/C-13/

I would say that out-of-the-box cgroups and kernel capabilities are making extremely much sense on servers. Being able to put hard limits on a service's CPU/IO/networking can only be a good thing, same with having defense in depth, by eg. preventing a service process /or any of its children/ from ever getting any privilege escalation (NoNewPrivileges). Combine it it with PrivateTmp=, and white-listing of what dir's it can read or write and you get some real hardening of the system in a very easy way.

Same with reliable killing processes, having a total supervision chain, including PID1 itself, being able to restart crashed processes, not by simplistic means, but using rate limiting, and perhaps based on exit signals too (only restart on unclean exit signals etc).

Regarding simplicity, then I am the opinion that the old legacy script based init systems where more "crude" and "primitive" rather than simple, and their total lack of features isn't so much a virtue, than a real downside to their use; even basic features had to be hacked and bolted on top of SysVinit.

I do agree though, that systemd is a rather hefty piece of software to understand, doing things in new ways, and lots of documentation to read. It also sucks to discard knowledge about e.g. boot sequences, and relearning everything again. But looking back, there was a lot of new tech that seemed extremely complex to begin with, that these days seem trivial, so I guess some of the seeming complexity of systemd will disappear once people "get it".

Regarding modularity; people may argue all day long that systemd isn't "really modular". But the point is in many ways moot; there is no real substitute for systemd's udev or logind or journald (syslog doesn't do all what journald does and vice versa), so what did it matter if systemd increased its internal complexity by supporting other modules than these; there simply haven't materialized any alternative despite years of warning from upstream projects.

Another thing I like about systemd and its wide acceptance in all major distros, is that it is a long needed reduction in needless fragmentation, being able to share knowledge about doing certain things on so many different distros is a boon.

One supplier does not competition make. Also, Intel isn't necessarily interested in making the chips that the Gov't wants, or this article would probably not exist.