| |||||||||||||
Poettering: systemd for Administrators, Part VIIIPoettering: systemd for Administrators, Part VIIIPosted Apr 22, 2011 0:32 UTC (Fri) by wahern (subscriber, #37304)In reply to: Poettering: systemd for Administrators, Part VIII by cmccabe Parent article: Poettering: systemd for Administrators, Part VIII
What other optimizations? Optimizations which mitigate the performance hit that people are complaining about. For example, exec costs like dynamic linking (static linking of /bin binaries never caught on). Also, you could add speculative loading of shell script commands. I'd want to add useability features like exposing file locking and PID management primitives in a way that makes them as convenient to use as in C. Basically, the idea is to solve all the little issues that make people stop using the shell for trivial system management functions which *should* be using the shell.
The shell's raison d'etre was process and file management. Don't you find it odd that all of sudden people are successfully arguing that the shell sucks at process and file management?
I agree we should be moving in the direction of more process isolation. But projects like systemd are moving in the *opposite* direction. init(1) shouldn't be a complex process, and now at least on Linux it's becoming a behemonth. At some point systemd will sprout a scripting language and history will repeat itself. So if we're going to go crazy, I want to join the party.
My idea wouldn't run all system scripts on a single process. There's no mixing of user privileges so security isn't as much of an issue. Concerns regarding bugs apply equally or more so to systemd. And the behavior of shell commands naturally fit a cooperative concurrency model for which coroutines would be a good fit. Plus, the type of shell I'm talking about could fix the issues with control over long pipelines that current shell designs don't or can't easily fix, such as access to exit status.
(Log in to post comments)
Poettering: systemd for Administrators, Part VIII Posted Apr 22, 2011 1:35 UTC (Fri) by cmccabe (guest, #60281) [Link]
> Optimizations which mitigate the performance hit that people are
> complaining about. For example, exec costs like dynamic linking (static > linking of /bin binaries never caught on).
I'm pretty sure stuff like preload(8) has this covered.
> I'd want to add useability features like exposing file locking and PID
Bash already exposes file locking. man flock(1).
PID file management is going to be integrated with systemd, rather than exposed in shell scripts like it is now.
> Plus, the type of shell I'm talking about could fix the issues with
Bash has $PIPESTATUS.
> I agree we should be moving in the direction of more process isolation.
No matter what you think about systemd, you can't deny that it runs daemons in a separate process. And that is a very Good Thing.
Personally, I think systemd will work out well in practice. But I haven't had a chance to try it out yet.
Poettering: systemd for Administrators, Part VIII Posted Apr 22, 2011 2:11 UTC (Fri) by wahern (subscriber, #37304) [Link]
systemd will work well in the short run. But give me an example where moving a hundred different tasks into a single, monolithic C application with a descriptive or declarative configuration format has worked out in the long run.
Everything that systemd replaces is the result of endless experimentation made possible by the flexibility that scripting languages--particularly and especially shell scripting--allows. Systemd will now destroy this process. Systemd won't stop the inevitable hacks that people will implement in the future; it's only cleaned up the past hacks. Future hacks are going to be uglier, more obscure, and more frustrating because they're going to include dreadful workarounds to the rigidity of systemd. That is, unless and until systemd reinvents the wheel regarding scripting support.
Come back to this thread in 10 years, tell me I was wrong, and I'll buy you a beer.
Poettering: systemd for Administrators, Part VIII Posted Apr 22, 2011 4:39 UTC (Fri) by josh (subscriber, #17465) [Link]
You can always patch systemd if you don't like its behavior. Or you can install a systemd file that invokes a shell script if you really want to.
Poettering: systemd for Administrators, Part VIII Posted Apr 22, 2011 10:13 UTC (Fri) by mpr22 (subscriber, #60784) [Link] Tell me one thing you would want to do which (a) would need to be managed by one of the things systemd replaces and (b) would be impossible or ugly with systemd. Here's the man pages.
Poettering: systemd for Administrators, Part VIII Posted Apr 22, 2011 12:45 UTC (Fri) by mezcalero (subscriber, #45103) [Link]
You are very confused.
The early boot stuff systemd covers is not done from a single process. It's all neatly separated in individual binaries. Nice, modular, simple and parallelizable. All those binaries are simple C programs with no deps but libc. So it's not monolithic at all.
Poettering: systemd for Administrators, Part VIII Posted Apr 22, 2011 17:25 UTC (Fri) by martinfick (subscriber, #4455) [Link]
Perhaps you should think of systemd as a "little language"? I do.
http://c2.com/cgi/wiki?LittleLanguage
And, from that perspective, systemd is something well overdo. Unix has many little languages to make simple things simple, and my impression of systemd is that it makes many more simple things simpler.
I love the power of shells, but I cannot endorse what standard linux startup scripts have become. They have always seemed to me to be a place ripe for the introduction of a little language, and I am shocked that it has taken so long! Now that someone has finally done so, and improved on system isolation and dependency management, without taking away the power of using a shell, I am delighted.
I feel that systemd embodies the unix philosophy way better than some tangled mess of shell scripts do (and way better than other startup systems on other OSes). I hope that Lennart continues to push solutions to fill the linux gaps that he sees, particularly the ones which the oldbeards can no longer see because they are so used to overlooking them. Thank you Lennart!
Poettering: systemd for Administrators, Part VIII Posted Apr 28, 2011 15:56 UTC (Thu) by stevem (subscriber, #1512) [Link]
Absolutely: loss of flexibility, loss of experimentation, loss of tweakability. Ick.
Poettering: systemd for Administrators, Part VIII Posted Apr 22, 2011 15:58 UTC (Fri) by vonbrand (subscriber, #4458) [Link] All the system calls, and a good load of "system" libary functions, are available (almost) directly in Perl (and I'd guess in other such languages)...
|
|||||||||||||