systemd: please stop trying to take over the world :)

[Denys Vlasenko]

On Tue, 2011-06-14 at 13:14 +0200, Lennart Poettering wrote:
> On Tue, 14.06.11 12:36, Denys Vlasenko (dvlasenk at redhat.com) wrote:
> 
> > 
> > On Tue, 2011-06-14 at 10:20 +0200, Lennart Poettering wrote:
> > > On Mon, 13.06.11 22:46, Denys Vlasenko (dvlasenk at redhat.com) wrote:
> > > > Slide 6:
> > > > "We can now boot a system shell-free"
> > > > 
> > > > IOW: shell is bad, my new shiny toy is good.
> > > 
> > > Oh god. If you had listened you'd have understood that my aim is to
> > > deemphasize shell in the boot process
> > 
> > You go quite farther than that.
> > 
> > "We can now boot a system shell-free". *Shell-free*.
> 
> Yupp, and this is one of the reasons why we boot so fast and can boot
> a reasonably comprehensive userspace in less than one second.

Wrong. Running shell scripts per se is not a significant slowdown.
daemontools does it all the time. It just *runs them in parallel*.

Performing system initialization *from* shell scripts *is* significant
slowdown, because writing parallelized init in shell, correctly, is not
easy.


> A shell-free boot doesn't mean there wasn't any /bin/sh anymore. I mean,
> I use bash all the time, it's a key way how I interface with my
> machine. I use it in build scripts and everything, and I have no plans
> at all to remove it from that and doing that would be crazy.

I never thought you want to do that. No argument here.


> But in the boot process? I don't think it is the best tool for the job, and
> unnecessary, and if we deemphasize or remove it from the boot process we
> have a lot to win.

I don't think this is the only your motivation. You want to acquire as
much "turf" as possible. Killing shell scripts everywhere in init
process and requiring everyone to use systemd's way to set ulimit and
whatnot etc will give you significant amounts of authority and "power".
Packaging people will be forced to come to you and ask for this and that
(anything they could do in shell scripts, but not they can't). This will
feel good, right? You will be such an important guy!

I don't see any other reason for the crusade to eliminate shell
scripting from boot process. You are too clever to actually believe that
shell script start time is the biggest problem in boot time.


> systemd will not take /bin/sh away from you. It will just give you the
> right tools so that you don't need it anymore for booting, thus saving
> resources, making things faster and more robust. We will continue to
> support SysV init scripts for a long time, for compatibility reasons,
> and you'll always be able to plug a shell script into the ExecStart=
> line of a systemd service file, if you want to.
> 
> > ulimit -d $((16*1024*1024))
> > exec my_favorite_program some_opts
> 
> Sure you can do that, systemd will not take that away from you. However,
> we offer you a nicer, more descriptive, more homogenous way to do that in
> the service file itself, simply by using LimitDATA= in the service
> file. Easier to use, more descriptive, faster and involves no shell.

Exactly as I suspected. Your new shiny way is better than our stupid old
way. Except that I was quite happy with the old stupid way of setting
data segment limit. I don't want to learn new way just to stroke your
oversized ego by being forced to do it your way.

daemontools has it right: it doesn't force me to abandon what worked so
well for 40 years. It allowed me to run a service by writing a small
shell script which can set, say, ulimit. Or cd to a directory. Or
chroot. Or export a variable. Or mkdir /var/run/FOO...


-- 
vda