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. The init scripts are grown in nearly half a century and are well-thought through. 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. 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." The containers get less and less shared resources from the base system. E.g. networking: Whether it is Solaris Crossbow architecture or FreeBSD jails v2 or newer Linux containers, they all can have their own network stack. Does it make sense to have one journald on the "host system" and one network daemon? Isn't that better located in "normal userland" (so in containers when appropriate) and so separated by default? That are questions I had in mind when going through systemd. More in general, it is a question of effort and result. Why reinventing the wheel? 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. A jail is running more or less immediately. The gain will be in millisecond range. 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. Mobile devices with Android are using another approach all together. Not to mention Busybox. It is a huge development .. and it isn't clear how many people will actually benefit from it significantly. [This is opinion] The history of Linux daemons close to the hardware (udev, hald, policy-kit, dbus, kdbus) as well as filesystem layout (procfs,sysfs) does not convince me. It all feels half-baked (sometimes even a bit narrow-minded, "I need this for me here now", and there are huge egos involved it seems) and I am not confident about quality and security of the code which is redone every few years and with competition between different approaches (and with this, splits in attention and effort). In general, I have the feeling Linux developers are "overcomplicating" things;-) Regards Peter