4 ms·

You're right, I misunderstood the integration. It still seems like it's optimizing for the wrong thing for the vast majority of linux users. The # of linux se

by count 15y ago

You're right, I misunderstood the integration. 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. Most scary is the way he wants to handle socket based services - it's already the source of one remote DOS against a machine running systemd: https://bugzilla.redhat.com/show_bug.cgi?id=739538 https://bugzilla.redhat.com/show_bug.cgi?id=739538

ominous_prime 15y ago
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).
LeonidasXIV 15y ago
> 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.

by count 15y ago

ominous_prime 15y ago

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

LeonidasXIV 15y ago

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