He also (correctly) warned about the entanglement of government and scientific research, in the same speach as the military-industrial complex warning. It's funny that people remember one warning, but not the other.

cgroups just enable systemd to collect all of the log entries from all of the processes belonging to a service without missing any*. When a sysvinit service daemonizes itself, the pid of the daemon isn't the same as the pid of the process that init actually created. This means that every service has to keep track of its own pid (in a pidfile), and that every service would have to report this information to syslog somehow.

Or you could add this capability to init, but then your new init is no longer doing just one thing and this is exactly the complaint most people have about systemd. Also, be careful not to change the existing interface with syslog, because then you're imposing your own views on everyone else, just like folks are saying about systemd.

Oh, and if your service logs to syslog, and it's being run under systemd, then systemd intercepts those and attaches all of the extra metadata before adding the log entry to the journal. You don't need to rewrite anything to be compatible with systemd. In fact, if you also have syslog installed then systemd will automatically send everything that gets logged to syslog as well; you get both at the same time and neither steps on the other.

I don't like systemd because it is systemd, I like it because it gives me a great way to query my logs and find out what my systems have been up to. If you give a sysvinit system the same capabilities then I will use those capabilities just as often.

* Well, cgroups also let systemd do a few other things not related to logging, such as setting resource limits on individual services, but I don't use them much myself.

If you think you can add this nice thing to syslog, then please do. Quite a lot of people will sing your praises, in fact.

If you have a service called 'foo', then 'systemctl status foo' not only shows you whether the service is running, it also shows you the last 10 log entries created by that service. This is great when the service failed; usually the error message will be right there.

How does it do this? Well, because all processes created by the service are in the same cgroup, all of the log messages (and even anything they print to stdout, which would have been lost otherwise) can easily be tagged with the service name (and a bunch of other metadata). You can use journalctl to query the journal for the logs from a specific service, and systemctl status does this for you.

What was the point of Firefox? IE was free and was a proven and already well-established browser. By your logic, we never should have built Firefox and the Web should have stalled with IE6 in 2002.

The world needs a truly open mobile OS as much as it needed a truly open browser a decade ago. Android is open in name only and Google is hurriedly moving its most lucrative components into closed proprietary services and apps that aren't a part of open source Android. iOS is as closed as everything Apple does. Windows is getting some nice HTML5 support for apps, but not nearly enough. There's clearly an opportunity for HTML5 apps to compete on mobile if someone can build a solid alternative platform to the monopolies and silos we're all stuck with today.

I don't think the so-called slashdot effect is in effect these days except for casual and amateur sites. Pretty much any serious site can handle a hard slashdot hit any more.

Christians throughout history have understood that the laws God prescribed for Israel in the Old Testament are not mandatory outside that context, and in particular are not to be applied wholesale to gentiles (i.e. almost everybody). This isn't some modern opportunistic innovation, it's explicit in the New Testament (e.g. Acts 10-11,15).

The Protestant reformers would have objected violently to your characterization. To them, rejecting the human authority of the Pope in favour of 'sola scriptura' was a move *away* from secularism. You're right that ironically it provided room for true secularism to grow.

But the grandparent post is right nevertheless. The Christianity of the New Testament is fundamentally compatible with secularism and pluralism because it grew up as a minority faith in the Roman Empire and took hold through mostly-peaceful implementation of the teachings of Jesus. There have been a lot of deviations from that course but those deviations can be corrected/stripped away without doing violence to the core, and in the modern era have been.

Malaysia and Indonesia aren't too bad.

The 9/11 hijackers were Saudis, mostly well-educated and from relatively wealthy families.

Meanwhile there's desperate poverty all over Africa and Asia and not a whole lot of terrorism (except where Islam is introducing it).

Unfortunately the area's an ethnic patchwork, not just of Sunni and Shia but other groups like Yazidi. So just "redrawing along religious lines" isn't practical unless you also carry out mass deportations. And good luck trying to keep the minority groups viable.

Yes, he is amazing. He gives half of those SICP lectures as well, trading off with Hal Abelson, another great engineer and lecturer.

A rocket is a mass driver, and all of the "scifi" types of propulsion break the laws of physics one way or another. Space elevators would be pretty nice, but we still haven't found a material strong enough. Carbon nanotubes are the current hope, but we can't make them long enough yet; they'd have to be very long indeed to make a strong enough elevator. Short nanotubes have to be glued together and then you're down to the strength of the glue.

I got distracted and broke my links. An Electrical Engineering View of a Mechanical Watch is at http://video.mit.edu/watch/an-..., and the SICP lectures are at http://ocw.mit.edu/courses/ele...

For the most part it's a difference in magnitude. The speeds the rockets achieve are much higher than any airplane, let alone car, ever manages. The thrust of the engines is stupendous, the liquid H2 and O2 fuels are cryogenic, the flame temperatures in the engine are extreme. In fact, they're so extreme that the engines use precise control over the flow fuel and oxidizer entering the engine to create a layer of cooler gasses around the inside of the engine nozzle, so that it doesn't melt or ablate entirely away. Everything has to work in vacuum and at ambient air pressure and at max Q during flight.

All of this and more adds up to a much harder design problem, much more stringent test requirements, much tighter manufacturing tolerances, etc. The principle is the same, however; any change to one component of a system may require changes to every other component.

The one thing that all forms of engineering from (whether software, civil, aerospace, or other) have in common is the management of complexity. The automotive engineer designs the engine mounts in your car to accept a wide range of engines, so that they can manufacture several variants of the same car with different engines without having to redesign every component. Similarly, SpaceX has greatly reduced their cost and risk by reducing the complexity of their rockets; one way they did this was to use the same engine for both the first and second stages of their rockets (the first stage simply uses more of them). Another way was to avoid cryogenic fuels; they have a lower specific impulse (fuel efficiency), but a much greater space efficiency (liquid H2 is very light; that orange tank is huge, and 80% of it is for the H2 tank) plus you avoid having to deal with cryogenic fuels, and the complicated materials engineering that goes into designing the tanks to hold them.

If you want to know more, MIT has some great lectures on the subject, even ones suitable for non-engineers. A good one is An Electrical Engineering View of a Mechanical Watch . The description of this lecture only touches on superficial matters; Sussman's real point is that the means of abstraction present in an engineered system can be applied to any other engineered system, and that it's only by designing the right abstractions that engineers make continual progress in designing newer and better systems. He states this directly in the first two minutes, which is quite handy. You might also check out the video lectures for the Structure and Interpretation of Computer Programs , the first lecture of which goes into much the same topics in the realm of software engineering.