I think it's matter of presentation and the actual implementation

Posted Nov 25, 2011 9:25 UTC (Fri) by khim (subscriber, #9252)
In reply to: That newfangled Journal thing by anselm
Parent article: That newfangled Journal thing

I don't remember a similar sort of spite-fest around Upstart, which attempted exactly the same thing that systemd is trying to do, namely creatively revamp the init subsystem. Is that because it didn't go as far as systemd, or because some people hate Lennart Poettering with more of a vengeance than they do Scott James Remnant?

I think it's matter of presentation and scale.

Scott's message:
Here is new version if SysV init which does exactly the same thing as the old one, but it can do few new tricks as well if you'll use new "native services". You can switch to them at you leisure. Indeed: upstart was added to Edgy Eft (Ubuntu 6.10) but even the next LTS (Hardy Heron AKA Ubuntu 8.04) used it as "modern SysV replacement" - native Upstart bootup was only introduced in Karmic Koala (Ubuntu 9.10).

Lennart's message:
Here is replacement for SysV init and upstart. It introduces totally new world and it's design does not take in the consideration the existing practice at all. Sure, we understand that compatibility is important and we'll provide compatibility mode till everyone will switch to systemd. We want to see this switch sooner rather then later - so we will patch programs and make them systemd-aware ASAP.

The first mode leads to years to transition but generates few ill feelings (people feel that they are in charge and can "jump ship" at any time) while second mode introduces abrupt change which naturally leads to spite-fests. Especially when another critical piece of the infrastructure is introduced which is intrinsically tied to the "new and unproven" systemd.

to post comments

I think it's matter of presentation and the actual implementation

Posted Nov 25, 2011 10:24 UTC (Fri) by anselm (subscriber, #2796) [Link]

It introduces totally new world and it's design does not take in the consideration the existing practice at all.

I don't think that is actually entirely fair.

For one, what systemd does is only a »totally new world« if you disregard the experience gained with Apple's launchd, which pioneered many of the ideas that we now find in systemd and which, on the whole, do make sense from a technical point of view. To some people this seems to come across as an evil conspiracy to make Linux »more like MacOS«, but I believe this is more due to the fact that the hackers at Apple appear to be on to something good here.

Also, it is worth bearing in mind that many of the things systemd does are traditionally provided by different pieces of infrastructure (SysV init, inetd, cron, ), not because these were designed that way from the start but because they arose at various points in the history of Unix and were introduced by different groups of people. It does seem worthwhile to me to try and construct a general framework for these tasks in the interest of simplicity, better configurability, and standardisation.