Sorry to raise the dead a little... but if the problem with sysvinit-style booting is too many processes, wouldn't it be simpler to modify the interpreter so it doesn't spawn new processes for each script launched? If the problem is interpreted code speed, what about just-in-time compilation?

What makes you think that distros/sysadmins won't have to manage the systemd unit files?

If I have both fetchmail and getmail installed, which one gets run? How about wicd?

I'll also mention that starting a bunch of subsystems in parallel can (not will) result in some very difficult to nail down timing related issues. Especially if one or more unit files failed to record a dependency; sometimes it works, sometimes it doesn't.

Software engineering is a big game of whack-a-mole; the annoying things that you fixed by implementing feature X tends to pop up new and different annoying things.

4 members found this post helpful.

If we are going to rewrite code, isn't it more efficient to do a full redesign of the process from scratch according to the modern needs? What you are suggesting will still have the same management flaw we have in the current system - having to maintain a lot of scripts which include a lot of duplicated code.

1. systemd unit files are easier do manage
2. Not true for desktop distributions - almost all daemons included in a standard desktop distribution are either started by D-Bus, or include systemd units already; server (or power-user) distributions can stick with sysvinit since fast boot is not required there

Well, it is difficult to track down race conditions, but we cannot stick with the same technology forever when we have better things available and we should not be demotivated by such difficulties.

Does systemd have a reliable configuration utility written in something other than gtk or pygtk? For example something that can be used in the linux console.

0 members found this post helpful.

Actually, the GTK interface is mostly there as an example - I'm not sure it's even usable! Most of the enabling/disabling is done via. the CLI interface.

I suspect that they will be easier to manage in some ways than sysvinit and harder to manage in others. I also suspect that individual distros will have to tweak the systemd units to get things to work; the idea of independent software units successfully inserting themselves into a dependency graph is an appealing one, but it will be easy to miss some links in the graph.

That doesn't make any sense to me. What is the difference between a "desktop" and a "server" distribution in terms of system initialization?

Wow. That's almost "Shut up and drink the Kool-Aid."

Look, "better" depends upon what criteria you weigh more than others. From a support perspective, being able to reproduce a problem so that you can fix it is pretty important. Shaving a small amount of time off the boot process doesn't weigh a lot in my view of the word. Your mileage may vary.

4 members found this post helpful.

Maybe. I would say for the most part, starting the daemons is really simple. Systemd takes care of managing it it all, so no need to handle the shutdown, restart, etc. stuff any longer. That makes these files /really/ simple. Check out dbus, for example

http://cgit.freedesktop.org/dbus/dbu...bus.service.in


I guess I see systemd providing alot of improvements, but not many cons yet. I would argue that the current init system is not flexible at all. I mean, to prevent cron from starting on my slackware box, I have to manually edit rc.M. To start non-included daemons, I have to edit rc.local (and hope that I don't need it sooner in the boot process).

Alot of people seem to be against it mostly out of the sake of change - or, do you have technical disadvantages to using a quicker, more intelligent init system?

Well, for instance, you've got more daemons starting on a server/power user distribution. While recently, distributions like Ubuntu cut down the daemons they have to initially start to a very small count - sometimes only udev, dbus, NetworkManager, gdm need to be started initially and then the other services/daemons would be started by dbus on the fly.

The sad part is that when systemd came, it received a big amount of attention, while nobody ever cared that much about initng. Initng (despite being unmaintained) is a great dep-based init daemon which uses simple configuration files. Also, another big strength of it is the fact that it comes with pre-made configuration files which automatically integrate for your distribution upon install. That makes maintenance of init scripts (in this case, configuration files) pretty unnecessary. The distribution I maintain is using initng and the time from the start of initng to gdm is never more than 4 seconds.

And the difference with all the previous attempts, including initng, is that you have to explicitly declare said dependencies in the configuration files, so there is a requirement to keep always them up-to-date as dependencies change. The really nice thing about systemd is that you generally don't with socket based activation.

This is entirely true. Systemd also has many advantages over initng. The thing is, some of the previous attempts, although being worse than systemd, were better than sysvinit.

Maybe this ought to be read before ignorantly bashing systemd :

http://0pointer.de/blog/projects/why.html


Additional advantages :

* Writing a shell boot script requires many redundant, error-prone lines of shell code. Making a systemd unit is 4-5 lines of configuration. So it's actually more KISS.

* One other (big) advantage is that most of the maintenance required would be done upstream. Freeing time to do something else instead of reinventing the wheel with custom error-prone shell scripts.

* It replaces/deprecates ConsoleKit which "works" in a hackish way on Slackware.

* It supports many of the newer linux kernel features.

* Someone already did the work to get systemd working on Slackware.

That said, it might be still a little too early yet to adopt it. But it's definitely something to consider very seriously.

I would not consider systemd for this reason only: it is being written specifically to work only on the Linux platform.
I am very much an advocate of cross-platform development, UNIX is bigger than Linux alone. Systemd is expected to be used by "userland" programs like KDE and Gnome. However these are also used on BSD, Solaris, HP UNIX etcetera. It is as if Poettering expects that the userland programmers (KDE/Gnome and other desktop environments) and distributors of UNIXes should deal with the incompatibilities and patch their code to make it work on non-Linux OS-es where systemd will be unavailable.
Code that shows this amount of contempt for anything that is not Linux, should be buried without ceremony.

Poettering also said his code is "more efficient" because he does not stick to POSIX compliant programming. The programming shortcuts he takes are non-portable.
I think "more efficient" and "cross-platform" should not be mutually exclusive. Taking shortcuts to make your program do fancy stuff is an immature coding style and better suited for the demo scene. You can optimize code and still keep it cross-platform, there is a lot of software that proves this - look at the multimedia applications that use platform-specific assembler code to squeeze all the available performance out of a computer. Still those applications compile cleanly and can be used on Linux, UNIX, and on several hardware platforms. It takes effort to make software portable and you have to be willing to spend that time - you do it for the users of your software.
Poettering defends his systemd with vigor, but his comments reflect his contempt for any other way of thinking. One of his typical statements is that all his critics are "amazingly badly informed". You can not go into a dialogue with the guy, he just won't listen to your arguments.

So, what are the advantages of systemd? Using "error-prone shell code" instead of systemd is bullshit - it's not as if we have to write new init scripts every week. Replaces consolekit? Poettering and Zeuthen are two Redhat employees who infest computers with half-assed software that they deprecate faster than distros can adopt it. Does it make your computer boot faster? Well wow... how many seconds of productive time do you gain per day?.

It is not worth the hassle.

Eric

14 members found this post helpful.

OS portability is highly overrated *yawn* It's been keeping Linux back for years waiting for others to catch up.

0 members found this post helpful.

You could have anticipated my reply, judging by your introductory message on LQ:
It's good that the Slackware developer created a distro that is easily customizable. You can add systemd yourself if you want.

Eric

2 members found this post helpful.

Developers always think they're right but they more than often see things only through the limited perspective of their own software. Not the big picture of a system as a coherent whole. And so the system ends up to be an inconsistent mess. Haven't the people who vaunt OS portability as the holy grail also mentioned anything about the concept of spaghetti code ? And that's a bloody shame because the Linux kernel is superior to everything else out there as far as kernels in the UNIX world and pretty much also beyond it. Lennart Poettering and RedHat are pushing for more coherence and simplicity. And that's good news except for people whose hobby is to do system administration.

It's customizable not because any effort was put into that. But because (contrarily to Debian and Fedora) it's one of the rare distros that does have a sane policy of not including everything and the kitchen sink. It makes choices instead of allowing every esoteric possibility. That's what makes it easily customizable. And it has to be this way. If not, one person wouldn't be enough to keep it updated. But the best would be a distro that would make choices, that doesn't include everything and the kitchen sink, but which would also strive to be consistent so as to put some order into the chaos of the bazaar. There's no reason why one can't have the best of both worlds.

1 members found this post helpful.