On 2013-08-18 11:44, Daniel Campbell wrote: > Systemd has a monolithic design, is headed by an egotist with no respect > for other developers, and cannibalizes other projects. The projects it > can't cannibalize will be strongarmed into irrelevance. Couple this with > Red Hat employees working on both systemd and GNOME, with a very clear > agenda to vertically integrate them, and you have a recipe for a closed > and/or heavily limited operating system. This is becoming clear with the > way GTK+ 3.x is handled, too.
Seems to me everything Gnome related is becoming the proverbial metric ton gorilla (on steroids, in a china shop)... Systemd follows that pattern. And Lennarts "track record" with avahi and pulseaudio does not inspire confidence, imho... I'm sure, given time, systemd will pull in Gnome as a building dependency... I joke of course, but then again nothing really surprises me anymore when it comes to the above mentioned projects... The supposedly advantages that systemd[1] has over other init systems are, supposedly: 1. To allow parallel boot of system services 2. cgroup integration 3. Re-start of services In my opinion: 1. Most of the time spent when cold booting is spent in the BIOS/UEFI cycle (around 30 seconds), the time from grub display to login (I'm using "slim") is 5 seconds (max). Ergo, parallel boot will do nothing for me. The parallel boot and the starting of services is also the thing that "breaks" the separate /usr philosophy (without static binaries). 2. cgroup can be handled by OpenRC as well. Not that I see much improvement, if any, over pre-cgroup kernels... So no advantage there either, for me. 3. Re-start of services (a.k.a. daemons in the UNIX world). Why would anyone want an automatic re-start of a daemon is beyond me. If a daemon crashes/doesn't start properly then it will not work by automatic re-start; I would like to believe that starting a daemon is not a stochastic process... I, however, would like to be told that it doesn't start so I can fix it. OpenRC does the latter well. Systemd also replaces the following services[1]: sysvinit, initscripts, pm-utils, inetd, acpid, syslog, watchdog, cgrulesd, cron, atd ...which obviously makes the code more complex, which goes against the KISS rule[2]. On a personal note, I like this quote best (from [2]): "It seems that perfection is reached not when there is nothing left to add, but when there is nothing left to take away" For the record... size comparisons (from [3]): OpenRC (0.9.3): sysvinit + 300 files, ~30k lines, 3.3k posix sh, ~12k C (sysvinit: 560kB, 75 files, ~15k lines) systemd (v44+): dbus + glib + 900 files, 224k lines, 125k C (D-Bus: 11MB, ~500 files. 300k lines, 120k C) (glib: 72MB, ~2500 files, ~1.7M lines, ~430k C) Also, integrating the services into one tool (systemd) makes a more fragile system (again, imho)... > I don't approve of an init system (or any other software) becoming > everything-and-the-kitchen-sink. UNIX philosophy is being forgotten by > these developers, and they openly condemn it while benefiting from it at > the same time. While the job of init could be argued as complex or > multifaceted, an init system can still "do one thing, and do it well": > Bring the system to an initial state. At the core, it means populate > sysfs (or an equivalent), start the specified daemons, load the relevant > modules, and standby until an event signals it to shutdown or restart. > No splash screens needed, no need to swallow a device management system, > no need to replace logging mechanisms, and so on. >From [4]: "Those who don't understand Unix are condemned to reinvent it, poorly." :-) > Coupling systemd with udev was a political move, not a technical one. It > was a deliberate effort to force their software on the FOSS world, with > the false pretense of "standardization", which is a buzzword among > developers that's effective at garnering support. The sad part is people > bought it. They will regret this move. Standardization per se is not a bad thing, i.e. protocols, APIs etc. (like POSIX)... I agree that Lennart and Kay motives are political though. Also, Lennart says this ([5]): "So, get yourself a copy of The Linux Programming Interface, ignore everything it says about POSIX compatibility and hack away your amazing Linux software. It's quite relieving!" [1] https://en.wikipedia.org/wiki/Systemd [2] https://en.wikipedia.org/wiki/Keep_It_Simple_Stupid [3] http://wiki.gentoo.org/wiki/Talk:Comparison_of_init_systems [4] https://en.wikipedia.org/wiki/Unix_philosophy [5] https://archive.fosdem.org/2011/interview/lennart-poettering At the end of the day I want the compute power in my computers/devices not to spend *one* cycle unnecessarily and it is very hard for a "kitchen-and-sink" system to do that, imho. I would very much like to see a "LEGO" approach (i.e. small individual tools with well defined interfaces that can work together) which imo is the UNIX philosophy. Best regards Peter K
