Linked by diegocg on Mon 23rd Aug 2010 14:10 UTC
Linux Lennart Poettering has posted a status update about systemd, an init/upstart alternative. systemd is able now to replace /etc/fstab and cron, and it seems it will be the default init system for Fedora 14. He has also written a post about systemd for administrators.
Thread beginning with comment 437938
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: I am not okay with this
by sorpigal on Tue 24th Aug 2010 11:01 UTC in reply to "RE: I am not okay with this"
Member since:

I did not misread it. Go back and read his original announcement for more details, but in the current one he brags about bringing down the number of processes used during boot ("PID now under 500"). When he says this he means "We didn't run shell scripts with lots of utilities" which means "we didn't run shell scripts" which he thinks is a good thing. In one place he says "We reimplemented almost all boot-up and shutdown scripts of the standard Fedora install in much smaller, simpler and faster C utilities, or in systemd itself" - this is part of his crusade against shell scripts as part of the init system.

Here's a fun quote from his "Rethinking PID 1" post:

Another thing we can learn from the MacOS boot-up logic is that shell scripts are evil.

You may not have a problem with it the way I do, but I am not imagining this, it is happening. I don't think Lennart's reasons are very sound, just like I don't think he was right to undermine jackd with PA when a great deal of their problem-set overlaps and could be combined.

It's good that someone is try to solve "whole problems" and not just tiny disconnected pieces (and I applaud that) but some of the choices being made are, in my opinion, just bad.

Reply Parent Score: 3

RE[3]: I am not okay with this
by Rahul on Tue 24th Aug 2010 13:12 in reply to "RE[2]: I am not okay with this"
Rahul Member since:

Avoiding shell scripts is something a lot of the new init systems do and makes good sense but systemd fully supports sysvinit scripts including several distro extensions for compatibility and will continue to do so. It merely won't be the default. Although offtopic, I would note that jackd developer definitely does not agree with your idea of what overlaps and does not.

Reply Parent Score: 1

sorpigal Member since:

systemd "fully supports" sysvinit scripts in that it will use them if it must, but it is still the goal of the systemd authors to eradicate such scripts from the boot process.

Support may remain in a technical sense from now until the sun explodes but it will be useless if it is not use d (read: not tested) and not in use (read: I can no longer audit and edit my boot process).

Fact: one goal of systemd is to boot the system without executing shell scripts.

Fact: it is a goal of systemd to eventually get all daemons to stop using init scripts when running on a system using systemd.

I am not okay with either of these things.

You say

Avoiding shell scripts is something a lot of the new init systems do and makes good sense

But I don't see what sense it makes. I see a lot of harm here and no benefit besides some nebulous "well it might be faster." I don't see the question of debugging boot problems addressed at all.

You say
but systemd fully supports sysvinit scripts

But systemd supporters think of this support as an "if you must, if you have something that hasn't been updated yet." What if I don't want to stop using shell scripts? I don't demand sysvinit scripts exactly, but I want non-binary human-readable and -editable.

Just because in 5 years I "can" write a shell script to init sshd, because after all such things are still supported, doesn't mean that any system will ship that way by default, which means that in a failure scenario I will be screwed by default. Unless, of course, I undertake to rewrite all of my system init scripts myself, by hand, and maintain them myself. This is prohibitive.

What is the inherent superiority of hiding boot logic in an impenetrable, unfixable binary? If you say "It's faster" I will laugh--a lot--because sacrificing a little speed for something easy to understand and debug is a no brainer, to me. If it were really worthwhile for speed reasons to do init via small C programs instead of shell scripts why don't we start by replacing all of the things in /etc/init.d/ with C implementations, keeping /sbin/init the same, and see how much people like it.

If it's not a good idea to have C init programs for sysvinit then it's not a good idea for systemd. If it is a good idea then I'd like to hear the justification for why. I know I can write a word or two on the virtue of putting the init logic in shell scripts .

Reply Parent Score: 3

sorpigal Member since:

Although offtopic, I would note that jackd developer definitely does not agree with your idea of what overlaps and does not.

Confining OT stuff to another reply.

I didn't say specifically what I thought overlapped (and I won't). People keep saying that the needs of end user and pro audio people are fundamentally different, but when they explain how I am left even more baffled by the disconnect.

It appears that the logic behind PA instead of jack was "Jack is for realtime work, jack is for when you want to process audio first and do everything else second." And therefore a new system was needed. But, then, I read that Lennart wants to 'eventually' add realtime support to PA, and at that point I have to back up and ask: To what extent are these systems solving the same problems? The answer is to a very large extent, even if they are not very similar at the moment they will eventually be quite similar.

If the goal of PA is to eventually do everything jack does, a thing I have heard said, then why didn't we start with jack and work at the goal from the other end? It's NIH, mostly, as far as I can tell. Lots of things that PA does might be useful to jack and the only difference is that for jack it's necessary to provide more tunables and be less conservative. It seems like, in the end, either PA is a special case of jack or jack is a special case of PA, no matter how you look at it this is inevitable.

I've read everything there is to read on this subject, apart from 100% of the codebases of the two projects, and all I see is people working at cross purposes. They're polite about it and will quibble about different goals but the inevitable future is that PA kills jack for all but a few niche scenarios where the PA devs refuse to implement the last 5% of features jack users need and pro audio people are left with a decaying, broken system lacking the man power to sustain itself. You end up with the kind of stupid, fragmented system found on Windows which serves no one especially well.

For the record: I use jack on my systems. I use it for desktop audio. It works very well. Most of the issues are from *inconvenience* due to setup not being automatic (it could be) and problems that PA has, too. (PA has actually made a lot of progress in this area that has helped jack, because due to PA there are fewer and fewer broken apps that don't play nice.) The only remaining issues are (1) Stability, which is a reason to resent PA since work done to stabilize it could be happening on jack, and (2) resource consumption (jack can use a lot.

Reply Parent Score: 2