|
|
Log in / Subscribe / Register

Another daemon for managing control groups

Another daemon for managing control groups

Posted Dec 6, 2013 21:39 UTC (Fri) by sorpigal (subscriber, #36106)
In reply to: Another daemon for managing control groups by anselm
Parent article: Another daemon for managing control groups

> The big advantage of systemd is that it unifies a lot of previously disjointed but similar functionality under a single interface. This means, among other things, that the configuration of the init process (together with other purportedly »independent« bits like inetd, cron, …) is that much easier to understand, to manage, to learn, and to teach. This will be an advantage in the long run.
While you are not wrong the advent of systemd seems to presume that we now know how to do this and don't need to experiment any more. Any replacement for systemd once it is entrenched would have to have at least identical features--the lowest common denominator is now not as low.

Anecdote time: I recently added a ./var/ directory in a little app that I'm building for my $job, because I didn't need to explain to anyone else on the team what var meant or why logs and caches would be written there. In the long run perhaps everyone will know what .unit means, but not today. This is the secondary value of Unix, after simplicity; over time conventions gain power without regard to their intrinsic values. Repeating those conventions makes them more valuable each time. Violating those conventions raises hackles even if the violation has a lot of intrinsic value.


to post comments

Another daemon for managing control groups

Posted Dec 6, 2013 22:35 UTC (Fri) by anselm (subscriber, #2796) [Link] (2 responses)

While you are not wrong the advent of systemd seems to presume that we now know how to do this and don't need to experiment any more.

SysV init has been around for 30 years or so. It is reasonable to assume that any significant use cases that it and its friends don't cover in some (convoluted and suboptimal) way would have shown up by now.

The other point worth making is that systemd doesn't come to us out of thin air. There was considerable experimentation going on in init-like systems in the shape of things like daemontools, launchd, Upstart, and so on, all of which have influenced the design of systemd. Systemd builds on these other tools in various ways and takes many of their ideas even further.

Finally, in case some revolutionary way of starting a service comes up that systemd doesn't cover, surely – systemd being open-source – it would make sense to extend systemd to deal with it rather than replace systemd outright with something else?

Any replacement for systemd once it is entrenched would have to have at least identical features--the lowest common denominator is now not as low.

I don't see this as an argument in favour of SysV init. Surely we don't want to stick with SysV init for the indefinite future because it offers fewer features and is easier to replace with something else than systemd?

I recently added a ./var/ directory in a little app that I'm building for my $job, because I didn't need to explain to anyone else on the team what var meant or why logs and caches would be written there. In the long run perhaps everyone will know what .unit means, but not today.

The /var directory came along in the 1980s when Unix had already been around for almost 20 years. It is safe to assume that there must have been old Unix hands at the time who would fight this innovation tooth and nail because it violated the conventions they had been repeating for more than a decade. The same applies to many of the other innovations that happened in nearly 50 years of Unix history (including but not limited to SysV init, which people seem to like to pretend goes back at least to Noah's ark).

People point to the hallowed »Unix tradition« as if Unix had sprung from the Earth in 1969, fully formed, and then didn't change at all until Linux came along 20 years later. The truth is that Unix changed all the time, and many things that we now consider part of the original »traditional« feature set only appeared way later than people generally accept. For example, the Bourne shell was introduced in 1977 with Unix Version 7, and still we read in actual published books that »The Bourne shell was the original Unix shell«. Not. Even something as central to the »Unix philosophy« as pipes was only implemented after Unix had already been around for several years.

SysV init and friends, in 2013, are the equivalents of baling wire and twine. It is amazing that they can be made to work at all. We can consider ourselves fortunate that somebody of Lennart Poettering's calibre has decided to come up with an alternative that will hopefully be suitable for the next few decades. I'm frankly a bit sick of those people who, because they have no technical arguments to make, will come up with quaint ways of saying »This is not what I'm used to and therefore I don't like it«. They can stick with SysV init for the next century or so, but they don't get to dictate policy to everybody else. If systemd is really as bad as they say they can rest assured that they will have the last laugh.

Another daemon for managing control groups

Posted Dec 7, 2013 3:23 UTC (Sat) by neilbrown (subscriber, #359) [Link]

> The same applies to many of the other innovations that happened in nearly 50 years of Unix history (including but not limited to SysV init, which people seem to like to pretend goes back at least to Noah's ark).

"If it can't be done by adding a few lines to /etc/rc.local, then it isn't worth doing!" - Noah.

Another daemon for managing control groups

Posted Dec 7, 2013 12:35 UTC (Sat) by sorpigal (subscriber, #36106) [Link]

I think you misunderstand, I was attempting to explain the reaction against systemd and part of why it might exist. Clinging to tradition seems to me to be a major source of negative reaction against systemd and you don't have to be an unreasonable person to react that way. The punch line would have been that eventually systemd is likely to receive hallowed status itself and there is no down side unless it has design flaws that are not apparent now and not fixable without total replacement.

Traditions and conventions have nothing specifically to do with Unix or the Unix Way, except insofar as its longevity means it has time to develop them while other things may not. Making new conventions is socially hard no matter the merit. Try convincing everyone to stop saying "Hello, world" and use something else instead; even for an arbitrary string it would be a hard sell.

> For example, the Bourne shell was introduced in 1977 with Unix Version 7
Indeed, and Bourne apparently spent quite a lot of effort individually convincing each of his early users to switch to his shell even though it was "obviously" superior and largely a superset of functionality. It was years before one could presume a Bourne sh. Change is hard (and slow).


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds