| |||||||||||||
The road forward for systemdThe road forward for systemdPosted May 26, 2010 20:09 UTC (Wed) by nybble41 (subscriber, #55106)In reply to: The road forward for systemd by martin.langhoff Parent article: The road forward for systemd
What's wrong with including an embedded interpreter in systemd? After all, Lua is small enough that some programs use it just to parse their configuration files. It wouldn't add much overhead to handle both configuration and scripting with an embedded Lua instance.
(Log in to post comments)
The road forward for systemd Posted May 31, 2010 16:26 UTC (Mon) by mezcalero (subscriber, #45103) [Link]
Well, my point was that I claim that a full turing-complete programming language should not be necessary to start up most services. Instead we should just identify common code in the various init scripts and make them available directly in the init system via a simple option in the .service file or in the daemons themselves. I am quite sure that for a few services this will not work out we we will still need a shell script for them. But that's fine, it will then just spawn a shell script which as last step simply execs the real daemon. But again, there is really no need for a shell interpreter for the majority of services, and hence let's just get rid of it.
The road forward for systemd Posted May 31, 2010 18:21 UTC (Mon) by nix (subscriber, #2304) [Link]
Exactly. What would be worthy of disparagement was if you'd decided that we *could* no longer use shell script fragments to start services. But, really, the repetitive umpty-Kb-long shell scripts to start random daemons on current systems are just ridiculous. Most of that isn't needed to *start the daemon* at all (BSD-style boot scripts didn't need it), but to provide the other services (stop/restart, easy reconfiguration via stuff in /etc/default et al) that the distribution needs. And *that* doesn't really belong in *every single* startup script. Better to centralize it.
|
|||||||||||||