I can’t remember how SunOs 4 startup worked, but it’s certain that I was first exposed to the “System V” system with SunOS 5, marketed as “Solaris” from its release in 1991.
Right from the beginning, I thought it was absurd. I was OK with the concept of “run levels”, representing “single user”, “multiple users”, “graphical interface”, and so on, but each run level was implemented by a set of scripts accessed by symbolic links, the name of which defined its activation and order of execution.
As an example, if I look at this current Linux laptop wot I’m typing on, /etc/rc3.d/S13networking does whatever is needed to get the machine’s network working. But that isn’t a real file, it’s a link to /etc/init.d/network but the init system needs to know to start it before /etc/rc3.d/S15nfs-common (a link to /etc/init.d/nfs-common) because network files can’t work before the network is up.
The same real file /etc/init.d/network is also linked to /etc/rc1.d/S13networking and /etc/rc5.d/S13networking in order to start the network in these different run levels. That means you need to remember that changing the real file to fix something affects all run levels, or changing the prefix because something else needs to run first will have to be done separately for all run levels.
It’s a rats nest, and many people don’t like it, so there have been many ideas for different schemes. But the fact that my Linux machine in 2015 still uses the same system is evidence that none of the replacements was significantly successful.
Until now. An init system called “systemd” is beginning to be implemented in most major varieties of Linux.
And it’s an abomination, worse in many ways than the ancient System V init. All software has bugs, but some software is designed wrong, and systemd is one of those, because the thinking behind it is wrongheaded. A key strength of Unix-style operating systems has always been the loose coupling of functions, encapsulated in the idea that programs should “do one thing, and do it well”.
Systemd tries to do many, many things. From a developer’s perspective, that inevitably makes it big and complex and difficult to maintain. And some of the things it wants to do are actually operating system functions. It’s clear that what the originators of systemd have in mind is an operating system on top of an operating system. Systemd will control users. Systemd will control devices. Systemd will control security.
So why has systemd been widely adopted if it’s obviously not fit for purpose? Well, it’s actually one of its worst flaws which has propelled it to success. The monolithic nature and lack of separation mean that you can’t have just a bit of systemd, you have to eat the whole elephant.
The Gnome project, for example, has adopted the “logind” part of systemd to manage the different users logged in, thus making systemd what developers call a “dependency”: you can’t easily have a recent version of the Gnome desktop unless you have systemd installed. (“Wait a minute,” you may say, “Different users logged in? I have a laptop with one user: me.” Well, exactly. The dependency on systemd is to handle a situation that doesn’t apply to the majority of users, but you still have to have it, or else the whole thing won’t work.)
Another project with a dependency on systemd is udev, the Linux process which looks for hardware changes and makes the device available to other software. For example, plugging in a USB hard drive will allow the folders in it to be accessed. Part of that process is handled by udev.
It’s udev which is bending my brain at the moment. I was lying when I talked about the whole elephant; or, rather, being foresighted. The current version of udev only needs one software library from systemd, but the project development has been merged with systemd, and it looks certain that the whole elephant will return, angrier than ever.
My current Linux systems use udev, and thus are contaminated by systemd, even though I don’t use it as the init system, and never will. The basic graphical interface, xorg, depends on udev to tell it about mice and keyboards (which means you can plug in, say, a second mouse and have it work immediately. But how often do you do that?) but I’ve discovered how to configure xorg to use separate drivers, and that’s working fine.
The other essential thing that isn’t working yet without udev is network devices, ethernet and wifi, which will take more work. And not absolutely essential, but nice, would be the USB drive thing. It would be easy to set it up as a fixed device, but having it appear and disappear will require some programming.
If you found this blog by desperate internet search, wanting to get your Linux system working properly and efficiently, well, I’m only a seeker too. I have no definite answers, but what I do may well incorporate the “mdev” element of busybox, or maybe “eudev” from the Gentoo project. Go search.