On 9/10/2014 2:56 PM, Peter Ross wrote:
From: "Russell Coker" <russell@coker.com.au>
Technical analysis of the features and relative merits of different software has some value.
For a FreeBSD user it is annoying if a well-known Unix/Linux desktop environment gets "Linuxalized" via systemd etc. It is obviously harder to port it to other than Linux if you think of systemd during development in the first place.
;-)
It is a learning curve from shell scripts to something different. But that is okay as long as it is worthwhile.
Agreed. Trouble is, systemd doesn't look like it is worth it. Perhaps that will change, but right now it doesn't look that way to me.
The init scripts are grown in nearly half a century and are well-thought through.
Absolutely correct.
In substance, a daemon start/stop script looks the same under all kinds of Unix. A postfix start/stop scripts runs under any kind of Unix/Linux so - minimizing the work to integrate it in any kind of distribution.
Yes, I even heard one systemd advocator say that he couldn't understand how sysvinit works ... it is far simpler and much more easily maintained than an almost black box like, do anything and everything systemd via a monolithic single binary that is bloated to heck, together with binary log files and not enough documentation to satisfy many users. All in all, it is far too much risk for security and code auditing and is a significant backwards step away from the tried, true and proven sysvinit.
Complexity risks to overlook problems.
I remember putting a LDAP dependency in /etc/nsswitch.conf in Linux as done under FreeBSD before, and then udev starts.. waiting for a 30 seconds timeout per device created. It found it reported and closed in the Red Hat bugs database. It is not a nsswitch problem, it is not an udev problem.. nobody wanted to "own" it. It was somewhere fallen through the cracks. Best advice: "Don't do it."
It will be a whole lot worse with systemd too.
E.g. FreeBSD is using the old fashioned /etc/rc and this uses "rcorder" to prioritize /etc/rc.d scripts. After that they start in order - and it is possible to do things in parallel. The main reason _not_ to do so are (IMHO) a conservative approach to satisfy different environments (e.g. diskless clients etc.)
You only have to modify the /etc/rc "starter" and rcorder to have parallelisation in place.
For a physical server I wait for the hardware when booting, the OS initialisation only take seconds.
It certainly is much easier and far more maintainable.
A jail is running more or less immediately. The gain will be in millisecond range.
Yep, even if it saved seconds per server, it really doesn't amount to much and as you say, it is perfectly possible to do things in parallel with sysvinit. The time and effort being put in to systemd could be much better spent fixing the configuration issues of sysvinit setups where they are being blamed as a reason to justify the complete change to systemd.
Yes on a desktop it takes a bit of time. But start a system on a SSD and it isn't that much anymore. With hibernation you do not boot that way at all.
So true.
It is a huge development .. and it isn't clear how many people will actually benefit from it significantly.
It certainly looks like systemd is dividing many more people, it most certainly is not worth the trouble it is causing even at this stage.
In general, I have the feeling Linux developers are "overcomplicating" things;-)
Yes, the days of a boot floppy and a root floppy are long gone [my /boot partition on wheezy is 21M and there isn't anything special there]; hardware compatibility is a good reason for kernel bloat (somewhat), but the ever growing Linux kernel itself is enough of a concern without systemd growing into another monster. cheers A.