systemd doesn't appear to solve a problem, it seems to just add a layer of indirection and complication, as well as a single point of failure for ALL system startup services, rather than letting each service just handle it's own deal.
`init` already exists to kick things off properly - now init just runs systemd which then kicks things off, for no appreciable gain.
Seriously, do you even know what you're talking about? init does not start systemd at all. systemd replaces init, in a way that I can even select whether I want to use the traditional init or systemd, on boot time, with a kernel option.
And have you seen proper systemd integration? I installed Fedora lately, and man, that boots fast. Fedora solves so many things in a sane way that Ubuntu has been struggling since years. usplash, xsplash, splashy? Fedora has FDO's plymouth. Guess what, it works. SYS V init, the stupid Arch init, ubuntus upstart? Fedora has FDO's systemd, and it's faster than any of those.
It still seems like it's optimizing for the wrong thing for the vast majority of linux users. The # of linux servers, which don't care about boot time (or where software init is a very tiny part of boot time anyway) is way larger than the number of people using it as a desktop. Boot time isn't the thing that's keeping linux off the desktop.
Rewriting scripts and rolling them into a C daemon defeats the whole point of scripts in the first place - the administrator of the system can't make quick changes or easily troubleshoot things (or, optionally, selectively enable/disable small sections of initialization). It's also a large amount of new work for folks busy fixing actual broken or buggy parts of their software.
Lennart complains that the starting PID on his linux desktop is too high, because init scripts call 'grep', 'awk', etc. - and that developers should rewrite all of that into their own startup daemons. It seems like he's complaining about the 'UNIX way' of small, text-oriented tools each doing one job and piping the results between them for flexibility and power for the the system administrator. Moving all of that into a C-based daemon, hiding it entirely from the administrator (short of a unsupported-by-your-contract recompile and source mod) doesn't seem like a net win for me, especially for a few seconds saved two or three times a year.
This isn't about boot time, that is just a nice side effect for desktop users.
This is about servers, and better ways to manage the services on them. A service shouldn't need to daemonize itself, and monitor it's own process via shell scripts and PID files. Having infrastructure to run services (as apposed to just starting them), monitor them, and resolve dependencies between them is a huge step forward.
(I also don't agree with the handling of socket-based service in systemd, but it's an experiment, and maybe I'm wrong, so its worth a try).
> Rewriting scripts and rolling them into a C daemon defeats the whole point of scripts in the first place - the administrator of the system can't make quick changes or easily troubleshoot things (or, optionally, selectively enable/disable small sections of initialization). It's also a large amount of new work for folks busy fixing actual broken or buggy parts of their software.
Well, kinda. But I think this is somehow a weird point to take, considering that much other software is indeed written in C and noone complains about that (grep, awk). It is just that the bootscripts were scripts for a long time, but I think this does not mean that that it is an undefiable law. Plus, it is still open source, so if you want to change samething, just remcompile. As you would do with any other software.
And indeed, the "lower" level it gets, the lower level languages I'd accept there. Kernel in C, Bootscripts in Vala, and the desktop in JavaScript or Python, sounds quite reasonable to me.
And the socket based services are one interesting element. Whether it is a good solution time will tell, but I can't remember anyone trying this before and I applaud people to think in new ways. Yes, a DOS is not nice, I admit, but maybe we should give it a chance? Consider that systemd is still pretty new.
It saddens me sometimes that people dismiss ideas, just because they are different to what is now. One consideeable advantage that I see in systemd that it tries to be a solution for the majority of Linux distributions. I hate all the custom rolled init systems, I hate all that custom rolled network interface configuration, I will it all went away.
One single init adopted init system also means potentially more people fixing one single service file, so you don't have to. Instead of someone fixing just the Debian one, he also fixes it upstream so it can migrate to other systems.
> `init` already exists to kick things off properly - now init just runs systemd which then kicks things off, for no appreciable gain.
NO, systemd in an init replacement. Yes, init may get the job done, but it can be done so much better. Solaris dropped init years ago, but unfortunately licencing prevented their implementation from being ported to Linux distributions.
Upstart (by Canonical/Ubuntu) was the first major attempt in Linux, and has been running services in Ubuntu and Fedora for a few releases now. Lennart saw that upstart may not have gone far enough, and started his own implementation. Systemd may not be the panacea we want, but the it is on the right track for innovation, which we need.
`init` already exists to kick things off properly - now init just runs systemd which then kicks things off, for no appreciable gain.