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

[Lennart Poettering]

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.

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. 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.

> You are not saying "driving boot process by shell scripts is slow
> because ... ... ..." (an argument I would agree with), you are
> aiming at *eliminating* shell scripts from boot process.

Yes, I want to deemphasize the shell in the boot process, and ideally
remove it entirely from the boot process.

> > > Slide 14:
> > > "systemd is an Init System"
> > > "systemd is a Platform"
> > > 
> > > systemd is a platform? Really? What next? systemd is an Aircraft
> > > Carrier? 
> > 
> > That is not a technical argument, but just FUDing.
> 
> No, it is a technical argument. I am saying that this is not how things
> are supposed to be done in Unix. I am saying that you are trying to
> incorporate as much stuff as possible into systemd, and I think it's
> wrong. You don't like me saying this? Well, not a surprise.
> I also don't like when people tell me that I'm wrong.

Wow, you honestly believe that suggesting systemd would turn into an
aircraft carrier is a technical argument? Must be good stuff you are
smoking...

I think we'll just have to agree to disagree and leave it at that.

> > > Slide 50:
> > > "Shell is evil"
> > > "Move to systemd, daemons, kernel, udev, ..."
> > > 
> > > Again, shell, a tool which endured for 40+ years, is suddenly "evil".
> > > I don't think this being the consensus.
> > 
> > Yeah, it's not the right tool for the boot process. Doesn't mean it
> > wasn't useful for interactive use or for scripting. Just not the right
> > tool for the boot process. Since you seem to have trouble understanding
> > that, let me repeat it a couple of times: shell is not the best tool to
> > accomplish a quick and reliable bootup.
> 
> Can shell play a part in the boot process, or is it now completely
> banished? I don't know, is something like this acceptable in the new
> world of systemd?

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.

> > In fact those slides you refer to explain all that. If you don't listen
> > and don't want to read, then I cannot help you. One last try with
> > different words, nonetheless: simplicity, speed, robustness,
> > compactness, functionality.
> 
> Good that you don't include "modularity" any more. At least one of my
> arguments reached through, it seems.

Uh? systemd is modular. Absolutely, you can choose the parts you want
and the ones you don't, which is handy for embedded uses.

If you however ask why we integrate a lot of previously separate stuff
in systemd, then answering "to make it modular" would be kinda
bogus. systemd is absolutely modular, but modularity is not a reason for
integrating things the way we do.

Oh, and the list above why we do this is not complete anyway, there's a lot I
could still add as reasons why we integrate things like this. For
example we want to use systemd as gentle push for the distros using it
to unify, standardize and de-balkanize the basic set of components of
the OS.

> Let's take a look at each of them:
> 
> simplicity - I don't see it

What's so hard to understand, that with systemd you need 10 basic
packages to build a minimal system, and without systemd you need
50. systemd is hence much simpler to understand. (these are not exact numbers)

> speed - yes
> robustness - actually yes, your code seems to be good in that area
> compactness - no

Oh hell, absolutely. It's much more compact, since you need to build
only 10 instead of 50 packages to build your basic system...

> functionality - too much of it. I'd call it bloat

Well, I call a system bloated that is build from a myriad of separate
packages, with lots of glue kludges inbetween, and enourmous amounts of
duplication. However a systemd which simplifies, unifies, streamlines
the chaotic set of existing basic building blocks into a few, integrated
well-written ones, that's what I call the opposite of bloat, and that's
what systemd is.

> I would also add "monolithic and inflexible". Sorry.

Well, it's neither monolithic nor inflexbile, it's pretty much the
contrary. But I have enough of this nonsense. We have to agree to
disagree. I'll leave you to your opinions -- how wrong they might be.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.