As I have been coming to understand, you have a good point. What I don't know is if these components have well-documented interfaces so that they can be swapped out.

Systemd is also modular in that it is comprised of multiple components that run in isolated processes, which avoids having one service crash due to bugs in another. It's also not as spaghetti as people say it is. As I said in another post, the high level differences between systemd and sysvinit are:
- sysvinit starts a whole bunch of services whether you need them or not sequentially at boot time, and the startup is controlled by shell scripts.
- systemd starts services entirely on demand, only when they are needed, automatically managing dependencies, and the startup is controlled by C code.
So basically, they're a lot a like, except that systemd maintains more components internally to the project, and it's smarter and faster.

Wow. The usual complaint is the myth that systemd is monolithic. It's not. But now you're complaining that it's broken up into too many services? And how is this any different from sysvinit, which also starts any number of different binaries?

All they've done in systemd is write C code to start up services that used to be started instead by shell scripts and added the ability to make dependency resolution automatic so that services are only started when they need to be. So basically, they made it smarter and faster. The complaint that it's got too many binaries is moronic and a complaint just as well against sysvinit.

Systemd is modularized into a number of different binaries, each of which handles a different service. Thus, different functions are isolated from each other. This enhances stability and improves startup performance when not all need to be running first thing at boot time.

Oh, and all of systemd's config files are written in ASCII, in the traditional UNIX way. One cool thing they've done is made a single parser implementation (in a shared object library) so that all of the config files have the same syntax. Also, when you debug a problem with parsing for one service, you automatically debug it for all others at the same time.

We're talking about low-level system services here, where it's not really necessary to have swap-out options. Ok, sure, we have nano and vim, less and more (which nowadays are just the same program), variations on cron, etc. But a any one time, we just need to pick ONE. Moreover, most of us don't care which cron was chosen, as long as it does the right things at the right time.

With systemd, there is CURRENTLY less choice in some cases, but probably for ones that don't matter. Most components are already optional, and sooner or later, there will be multiple choices for a given service. (The lack of that is due to the young age of the project.)

As for duplication, you're not getting it. In a good system, common functionality is bundled into shared object liibraries so that they can be dynamically linked into multiple programs that need the same capabilities. Those are mapped to the same physical memory pages, so it saves memory too. It's also good to avoid reinventing the wheel. How many different config file parsers do we really need?

This sounds like a bug. Systemd is new, so it will have bugs. This is not, however, a design flaw. It is merely something that needs to be fixed. It's only a major problem if the devs refuse to fix it on the grounds that they don't think it's a bug. However, I've mostly only encountered that attitude when reporting Chrome bugs to Google.

Systemd is modular:
    - It's broken up into multiple independent processes, each of which handles one major thing well.
    - It's broken up into libraries so that commonly used code (such as parsing config files) is implemented once and shared among the services, saving memory (because you know how shared object libraries work, right?) and ensuring that there's only one implementation of any one thing that needs to be tested and debugged.
    - Interdependence among services is minimized, although as with any real, complex system, there are chains of dependencies.
    - Dependencies on and among services are handled on-demand so that only the services you need are running (often started well after boot). As a side effect, boot time is shortened.
    - Process 1 (init) is very small, with minimal functionality, in order to minimize the chances that it will crash.

The above are all true, or at least they are consistent with claims made by the developers. Sure, I have negative things to say, which are also true, but I don't want to add to the noise of all the false negative claims floating around.

Holy crap, dude. It was a joke. Things like "magical" and "zero runtime overhead" and "including ones that haven't been written yet" didn't clue you in?

The OpenBSD developers are so awesome that they've found a magical way to make modules unnecessary: Magical code compression with zero runtime overhead. As a result of this new approach, every possible kernel module (including ones that haven't been written yet) is stored in less space than an otherwise completely stripped kernel from the prior revision.

I said what I said because I had believed some of the myths promulgated about systemd. In fact, it's highly modular, and the main init process is actually quite small and not as much of a risk for crashes as people say it is. The main difference between systemd and sysvinit is that systemd is not based on shell scripts. Other than that, it is a collection of system services that are started up on demand and in logical order of dependencies, which was already a feature of Gentoo's OpenRC. Systemd's main objective seems to standardize and optimize many things about Linux that were previously (unnecessarily) inconsistent between distributions. Other than that, the main UNIX philsophy of making lots of specialized tools is not changed. Moreover, it's improved on the basis of sharing more code (in shared object libraries, I presume) between tools, such as code to parse configuration files and communicate with other components (which is based on dbus). They've taken the best UNIX features from various independent tools and system services and put them together into a single coherent implementation.

You really should read the page dispelling myths here, as pointed out by someone who replied to my earlier post: http://0pointer.de/blog/projects/the-biggest-myths.html

The more I look into this, the more I see the anti-systemd people being like creationists. Their view of the world is out-dated and replaced by better science (creationism isn't science at all, while sysvinit is not stupid, merely out-dated). Nevertheless, they fight to protect their old religion. And they deal with the new science mostly on the basis of total lies about their opposition.

I really have nothing invested in this, though, so my opinion my change yet again. I'm sure there are some disadvantages to systemd, but so far, all of the disadvantages I've seen people talk about have been fabrications, and it makes the adherents to the old religion of sysvinit look like luddites who can't separate fact from fiction and are merely afraid that their way of life is going to be taken from them, even when the new ways are better than the old ways. Quite possibly, some of the systemd opponents are INTENTIONALLY fabricating these things, and when things get to that point, I feel that their cult needs to die purely on principle.

Let's start by saying that the death threats against Lennart Poettering are ridiculous and should not be tolerated.

That being said, the design of systemd confuses me. It seems ripe for all manner of stability and security problems. As I understand it, it bundles a large number of services into a single process, which takes place of the init daemon. That's guaranteed to cause all kinds of system crashes.

What I don't get is why it isn't split up into multiple processes. All the same functionality could be provided by having a simple core init daemon that loads a set (perhaps a small set) of child processes. It wouldn't take longer to load. The services and behavior would be identical. But it would be a lot more stable, because a child process could be restarted if it crashes, keeping init to a bare minimum.

What's even more surprising is that someone with some sense hasn't done exactly that: Make a wrapper for the systemd build that patches a few things and just compiles it differently, into a slightly larger number of binaries. This way, we can benefit from the unification of services, while maintaining stability, and Poettering would have to be intentionally self-destructive to try to keep breaking that wrapper every release.

Instead of writing off creationism as pseudo-scientific clap-trap, why don't we start referring to it as a sport? Kinda like how curling and checkers are sports. When I was a student at Ohio State, studying computer science, I stayed way away from the campus during every football event. The traffic was a nightmare, and you'd have to park miles away and walk to every game, probably getting a ticket because where you parked was vaguely marked, and Ohio cops will use any excuse to get more ticket revenue. Hell, parking for a football game at the Ohio stadium was in itself a sport on many levels!

Anyhow, so how interested we are in sports, as scientists, varies quite a lot. Some of us care. Some of us could take it or leave it. Either way, a sport is mostly an event of mindless brutes kicking balls around and running into each other. Either that or it's comically painful like curling. Or self destructive like base jumping. So if we start referring to creationism as a sport, we'll be able to be clear about just how we think about it: A generally pointless exercise that makes whoever runs the event an ungodly amount of money. The debate as to whether or not creationism is serious science is about the same as the debate over whether or not it's possible to have a sport that involves ice skating and sweeping at the same time without being reduced to uncontrollable laughter.

You're assuming that there was already substantial diversity in feet size among lizards prior to the invasion. I'm not sure that that was the case.

Admittedly, the R code was probably horrible, but I inherited some of it, so I can't take all the blame. On the other hand, I'm really good at squeezing good performance out of C++.

This reminds me of the big hullabaloo Paul Graham made about how superior Lisp is because he was able to make more quickly adapt web back-ends for some website he'd done. I think attribution of this success to the language is misplaced -- his implenentation was more adaptable simply because he was a superior programmer, and Lisp probably only helped a little bit.

R syntax is a lot better. In Matlab, the dimensions of a 3D array are Y,X,Z. That's just one of the many papercuts that makes Matlab difficult and unintuitive to use. R makes a hell of a lot more sense to me.

That being said, R is also very slow. For one project, I used R and ended up having to use a supercomputer (I only needed a few hundred Opertons out of the 4096 available) to get all the work done in time. For a followup project, I rewrote it in C++ and reran all the same stuff in the same period on a Core 2 Duo. R is really that slow.

But then, R is an interpreted language, so that's not a surprise. And I was able to rewrite my code in C++ because we didn't need any special libraries; if we had, I wouldn't have had the expertise to reimplement it. R is really convenient to use for many things, and it's also faster than Matlab for everything I've tried in both. Matlab is a dog, and the Mac version crashes at the drop of a hat too. I can't believe people pay money for that crap, except that it's pushed on universities, so people get used to it.

What kind of courses do you think are bullshit? While I as in grad school, an undergrad I knew complained about having to take poetry course. I told him his complaint was stupid. For sure, this guy needed to have his horizons broadened. When I took grad CS courses (at Ohio State, BTW), they were certainly challenging, but when I took courses in Psych, Linguistics, and Cog Sci, I had to think about things in entirely new ways, so I came away feeling like I had expanded my mind more fundamentally.