Le nonidi 19 germinal, an CCXXV, tomas@tuxteam.de a écrit : > So we always had multi-user: the trend is rather the other way: > since everyone has his/her own gadget, complex things like desktop > environments tend to do silly things spoiling the multi-user roots > of UNIX. We agree on that. > Note that I'm a decided systemd opponent, and that might shine > through the above. Feel free to correct any misrepresentation. I would not have guessed. But you forgot a very important information: what are you a PROponent of? A lot of people are only opponents, and very vocal ones, and discussing with them is usually useless; I have seen the symptoms on this very list. Being an opponent is easy, everything has flaws that can be attacked; being a proponent is harder. Now, back to the discussion at hand, namely a comparison between systemd and the SysV init system: > Personally I find SysV ugly, but in ways which could be made better. > > 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. This is true, and IMHO a balanced way of expressing things. But you forgot a very important side to the question, that IMHO makes SysV init unsalvageable: the init program, the one running as PID 1, itself. With the SysV init system, the init program is stupid: it starts the master script that spawns all the individual init scripts, it reaps its children dutifully, but it does not keep track of anything beyond a single 3-bits piece information called "runlevel". Well, that is not entirely true: the init program can keep track of a few specific children, defined in /etc/inittab with the "respawn" keyword. But this feature is so limited and fragile that I have only seen used to respawn gettys. So, imagine you have an init script that starts, say, Apache httpd: httpd double-forks and is adopted by PID 1. At some points later, the httpd process exits; PID 1 reaps it, and that is all. Did it crash? Was it stopped by the sysadmin? Is it completely stopped, or is there still a mad subprocess running and monopolizing port 80? Nobody knows. On the other hand, systemd keeps track. When httpd is started, systemd knows "this is the httpd main process". Even better, it keeps track of all the subprocesses started by it. If the main process exits, systemd detects the return code, detects whether it is a crash or an explicit shutdown, and logs it accordingly. This makes a huge difference. Of course, a lot of other init systems came along to try and address that particular issue: daemontools, upstart, runit, etc. I have not examined all of them very closely, but I am quite sure that any of them is hugely better than SysV init. But the arguments to compare them with systemd are not all the same. That is why knowing what you are a proponent of is so important. As far as I know, systemd is the one that makes the most use of the new mutant powers of the Linux kernel: cgroups, namespaces... That makes the whole thing more complicated, but that is what makes it possible to implement certain features. For example, I have mentioned keeping track of all the subprocess started by a daemon: I do not know if that would have been possible without cgroups. And of course, there are non-technical considerations. If there is a technically awesome program but nobody uses it, maybe it is more efficient to choose a slightly-less-awesome program for which integration is already done and help is easier to find. That may not be fully satisfactory, but not all battles are worth fighting. This consideration makes a significant malus for init systems maintained by a single developer with some help of her or his mailing-list friends. And a significant bonus for init systems backed by a big corporation, even if that gives it the awful taste of a corporate program. On the non-technical side, having a non-obnoxious person as project leader can definitely be counted as a plus. That is definitely not a plus in the systemd (nor daemontools) column; I do not know for the others. Regards, -- Nicolas George
Attachment:
signature.asc
Description: Digital signature