3 ms·

> it's now basically just an overcomplicated init script. That's probably the better way to express what I was trying to say. It seems really complex and rigid

> it's now basically just an overcomplicated init script. That's probably the better way to express what I was trying to say. It seems really complex and rigid (and probably brittle?) for a script that's used basically to start services, but I may be missing something since I don't use Linux much and only then usually on a spare laptop. And as Theo once said, the process of booting an operating system is non-trivial. (Or words to that effect.)

peterwwillis 8y ago
I've written init replacements and it's not trivial, but it's not hard either. The majority of the starting of an operating system can be put in a single shell script (and in fact that used to be standard). But if you want to get really complicated, you can turn every boot operation into a service. Services are a common feature of modern operating systems. You have a dependency graph, you start something based on it, you either watch the process or wait for one to die, you reap it, you figure out what to do next (which is usually "restart the things I need to keep that thing running" or "die and warn the admin"). All of that is useful for daemons, things that need to keep running. For 99% of the rest of system booting, it's one-shot loading of stuff. So, many people (myself included) like just having a shell script to keep all that in, as one a system is built, the boot-up rarely changes. By keeping booting and a service manager separate, you can change things out as you wish. You can do that easily if all pid 1 does is kick off the boot-time stuff, which itself kicks off the service manager. You can't do that if the service manager is the boot manager and both are pid 1. Or at least, now you need to kick off a second service manager from the first one and pretend the first one doesn't exist, which is non-trivial. The more responsibilities you take over, the more crap you need to support. So as a result, systemd is an entire kitchen sink, because it needs to be for you to get anything done, due to its design decisions. With a different design they could offer any functionality and you could pick and choose what to use, but from what I understand now it's more like you have no choice.
- JdeBP 8y ago
  > So, many people (myself included) like just having a shell script to keep all that in, as one a system is built, the boot-up rarely changes. That's actually few people, rather than many people, as the history of the past 40 years shows. The simple fact of the matter is that after a system is built system administrators find themselves installing and uninstalling third-party applications softwares. Editing /etc/rc became tedious and error-prone, especially when installation/deinstallation utilities tried to do it automatically. First there came /etc/rc.local in the late 1970s and early 1980s, where administrators could in theory cordon off the non-operating-system stuff for these applications, so accidents didn't wipe out half of /etc/rc any more. Problematically, value-added resellers thought that /etc/rc.local was their domain and put their stuff into it. One 1991 Usenix paper bemoaned the consequence of this that "there is no place to put 'real' local modifications and keep them distinct and separate from vendor supplied files". Then came the idea in the early 1980s of drop-in shell scripts that could belong to individual softwares without need for editing a single monolithic shell script at all, the rc system of AT&T Unix System 3/System 5. This idea was repeated several more times. Miquel van Smoorenburg copied it for Minix and then Linux with an /etc/init.d/ directory. FreeBSD had a similar system by 1995 with an /etc/rc.local.d/ directory. Luke Mewburn reinvented it slightly differently for NetBSD in 2000 with an /etc/rc.d/ directory. Roy Marples reinvented it as OpenRC in 2007 with an /etc/conf.d/ directory. All of this tells us that many people (not including you) in practice do not like the problems of just having a single shell script, and continually move away from it. Time and again over a period of 4 decades. * http://jdebp.eu./FGA/rc.local-is-history.html http://jdebp.eu./FGA/rc.local-is-history.html

peterwwillis 8y ago

I've written init replacements and it's not trivial, but it's not hard either. The majority of the starting of an operating system can be put in a single shell script (and in fact that used to be standard). But if you want to get really complicated, you can turn every boot operation into a service. Services are a common feature of modern operating systems. You have a dependency graph, you start something based on it, you either watch the process or wait for one to die, you reap it, you figure out what to do next (which is usually "restart the things I need to keep that thing running" or "die and warn the admin"). All of that is useful for daemons, things that need to keep running. For 99% of the rest of system booting, it's one-shot loading of stuff. So, many people (myself included) like just having a shell script to keep all that in, as one a system is built, the boot-up rarely changes. By keeping booting and a service manager separate, you can change things out as you wish. You can do that easily if all pid 1 does is kick off the boot-time stuff, which itself kicks off the service manager. You can't do that if the service manager is the boot manager and both are pid 1. Or at least, now you need to kick off a second service manager from the first one and pretend the first one doesn't exist, which is non-trivial. The more responsibilities you take over, the more crap you need to support. So as a result, systemd is an entire kitchen sink, because it needs to be for you to get anything done, due to its design decisions. With a different design they could offer any functionality and you could pick and choose what to use, but from what I understand now it's more like you have no choice.

JdeBP 8y ago
> So, many people (myself included) like just having a shell script to keep all that in, as one a system is built, the boot-up rarely changes. That's actually few people, rather than many people, as the history of the past 40 years shows. The simple fact of the matter is that after a system is built system administrators find themselves installing and uninstalling third-party applications softwares. Editing /etc/rc became tedious and error-prone, especially when installation/deinstallation utilities tried to do it automatically. First there came /etc/rc.local in the late 1970s and early 1980s, where administrators could in theory cordon off the non-operating-system stuff for these applications, so accidents didn't wipe out half of /etc/rc any more. Problematically, value-added resellers thought that /etc/rc.local was their domain and put their stuff into it. One 1991 Usenix paper bemoaned the consequence of this that "there is no place to put 'real' local modifications and keep them distinct and separate from vendor supplied files". Then came the idea in the early 1980s of drop-in shell scripts that could belong to individual softwares without need for editing a single monolithic shell script at all, the rc system of AT&T Unix System 3/System 5. This idea was repeated several more times. Miquel van Smoorenburg copied it for Minix and then Linux with an /etc/init.d/ directory. FreeBSD had a similar system by 1995 with an /etc/rc.local.d/ directory. Luke Mewburn reinvented it slightly differently for NetBSD in 2000 with an /etc/rc.d/ directory. Roy Marples reinvented it as OpenRC in 2007 with an /etc/conf.d/ directory. All of this tells us that many people (not including you) in practice do not like the problems of just having a single shell script, and continually move away from it. Time and again over a period of 4 decades. * http://jdebp.eu./FGA/rc.local-is-history.html http://jdebp.eu./FGA/rc.local-is-history.html