Re: If Linux Is About Choice, Why Then ...
<tomas@tuxteam.de> writes:
>
> What systemd brings (mainly[1]) to the table is the decoupling of
> different "parts" of init: just imagine you have one service (let's
> say a web server) which depends on some other thing (say a file
> system being present via ummm... NFS, but it could be a RAID or a
> memory stick, you get the idea). With a SysV init you can't express
> that: you would have to script it explicitly. With systemd you
> can express that the web server is only to be started once that
> file system appears.
>
> So I'd rather say systemd is an adaptation to a much more volatile
> hardware landscape (which previously was only known in big iron)
> comming to the masses these days (just think USB). It corresponds
> to a more "dynamic" configuration.
>
> There are, of course alternative ways to skin the cat.
>
> Note that I'm a decided systemd opponent, and that might shine
> through the above. Feel free to correct any misrepresentation.
>
You've been perfectly fair. Would that all opponents did so.
As Nicolas said, systemd's main advantage is that it keeps better track
of what exactly it launches. Not only can it keep track of subprocesses
launched by the main process, it can also use that knowledge to manage
their resources, giving the sysadmin the power to constrain a service so
that it never eats up all system resources.
Or, by putting it in a separate scope, it can separate processes from
the user session that started them, making clear the difference between a
rogue process that should have died on logout, and a user service that
should persist across sessions.
The bad news on that last one is that it triggered another flamewar, as
the default chosen (kill all processes on user session end) was rather
unfriendly to programs like tmux and screen.
Mart
--
"We will need a longer wall when the revolution comes."
--- AJS, quoting an uncertain source.
Reply to: