Hacker News new | ask | show | jobs
by deelowe 4252 days ago
Linux/unix has a bit of an issue with it's init aging systems. One simple example is that they are serial, meaning that services start one by one with little to no concurrency. This causes several issues. Also, the most popular variant, system V is difficult to maintain having multiple directories for various run levels and other cumbersome features. I won't go into details here, just know that the popular init systems needed a refresh.

There are other options, but systemd seems to have caught on as the popular option for a replacement. The issue that most people take with systemd is that it does much more than replace init. It replaces cron, has a login management hooks, has it's own network daemon, replaces the system logging facilities and more. It's a serious complex system.

The issue some take with systemd has a few facets:

1) Some feel that systemd's approach to managing everything goes against Unix's core principles where services and applications are supposed to be small, self contained entities that work in unison to form a cohesive system.

2) It can be daunting task to switch over to systemd as you have to relearn many traditional unix tools that most take for granted (remote logging for example).

3) Security minded people are concerned that a single service is touching so many parts of the core system all at once. There have been many complaints levied that such a large change introduces too much risk into the ecosystem all at once.

4) Some have accused the dev team of having a "not invented here" problem. I've seen it asked many times why they really needed to replace cron or logging.

The pro-systemd stance is that they are simply cleaning up many of the antiquated systems. Cron, logging, and init definitely all needed an overhaul. Linux never had a good network daemon and there are good reasons for the other things they are doing. The systemd team sees systemd as not just an init system but basically the system manager. So, by that view, this all makes sense.

Ultimately, it's a fundamental difference of opinion about what services in general should or should not look like on a unix/linux system.

3 comments

I agree completely that cron, logging and init all could use a little (a lot of) modernization. I just think it's really bad judgment to tie all of those together into one all-encompassing project whose scope seems to grow and grow the more I read about it, and whose leaders seem to have such a low opinion of what anybody else wants.

To make a stupid car analogy, it feels like having someone redesign your car's ignition switch and suddenly finding out that he also had strong opinions on the stereo UI so he made the changes together (and dependent on one another), and you're an idiot if you don't like it.

A lot of people complain about systemd missing the "unix philosophy" and that gets derailed on specifics of what people think that philosophy means ("everything is a file" or "do one thing only and do it well" and "be modular") but one significant difference to me between unix systems and Windows or OSX is that unix is built of simple components whose scope is very limited. It's related to do-one-thing and modularity but it's not exactly the same thing. Systemd is not simple or limited in scope.

Could someone just fork systemd and make a version that relaces the init system and nothing else?
That's uselessd. Software however relies on the other bits, e.g. logind dbus interfaces. For that there is a systemd-shim, but was not there initially and used to lag behind systemd for a 6+ months. Apparently it was also quite buggy. Seems ok now though.
To clarify, uselessd (http://uselessd.darknedgy.net/) is "a project to reduce systemd to a base initd, process supervisor and transactional dependency system, while minimizing intrusiveness and isolationism", not just the parent making a joke in the phrasing.
Thanks!