Earlier quoted context omitted.
> You will not have this without changing the kernel itself, /sbin/init needs to run as the root process of all other processes on the machine. By design, any implementation has to "take over the machine" in some sense. Not in the systemd sense of putting its fingers into everything. In fact, not at all. My init will be little more than Rich Felker's init; the difference is that you will be able to tell it to spawn a…
>Not in the systemd sense of putting its fingers into everything. It is unclear what this "putting its fingers" actually means besides "implementing features that other projects then want to use". Is openssl "putting its fingers" into everything because everyone uses it to implement TLS? >In other words, your claim that I cannot make an init that doesn't take over the machine is false. No I don't think so. I cannot r…
> It is unclear what this "putting its fingers" actually means...
Why does systemd need timers when cron exists? Why does systemd need to manage home directories? Why does systemd need to manage the network when daemons existed to do that?
You know what I mean. systemd does a lot of things that were originally outside the scope of an init/supervision system.
> How is this any different from using the supervision system as the init?...killing either one of them will take down the system.
Because the supervision system has a different purpose than the init. systemd is too big for what init should be. Init should be made so small that it cannot crash. Having a separate daemon, that could possibly be restarted if it crashes is a good idea.
In fact, if PID2 saves its state to a file every time it stops or starts something, then if it crashes and is restarted, it could just reload and carry on as normal. In fact, it could even have signal handlers for all signals and exec() itself in those signal handlers in order to ensure that it doesn't go down. And if you do a `kill -9 -1`, you deserve what happens. But even in that case, since Linux does not kill init, it could simply restart the supervision system which could then rebuild everything from scratch. Simple. And even if you do a `kill -9 2`, then the init, when it receives word that that happened, could do the same thing as a `kill -9 -1` (or use SIGTERM, whatever), then restart the supervision system, which would then restart everything.
This could work even if you're running a different supervision system under my init because it could just pretend that it had barely booted the computer after it kills/terminates everything and restarts the supervision system.
But should systemd trigger a bug that causes a crash, good luck. I hope it has ways to recover, like the signal handlers I laid out above.
With my design, killing one daemon or the other is not a way to take down the system. First, you can't kill init on Linux unless it crashes, and systemd is far more likely to crash. Second, if you kill the supervisor, the init can handle that. That's why you separate them.
> ...you can just implement backwards compatibility with systemd in your init, and then those daemons can run again. It is not like this is even hard to do this, you can see exactly what APIs it depends on....
The fact that those daemons are depending on an API is systemd subsuming them. Making systemd a dependency is subsuming them. Daemons shouldn't have dependencies on specific init/supervision systems. If they do, they are part of that system, not separate. It would be like programs that can only run as children of bash but not zsh. It is stupid, and it is systemd subsuming them.
> ...the libraries are not so useful to any other code.
So what if those libraries are not useful to other code? Make a library, have both link to it. It doesn't matter if they're the only users. They could also be the same binary, kind of like busybox, which would have the added benefit of the executable already being in memory when starting the supervisor.
> All this code must be able to run as root inside the service manager.
Which is why it should be as small as possible.
> ...They chose themselves to adopt it because it was good and it made their lives easier...
Poettering made systemd a good init for distros, not for users. He made it easy for distros to set up a distro. He spent less time making it easy for users to set up a system and administer it.
And then he used persuasion and advertising, as well as the power of the company behind him, to get distros to adopt it. You may not call that politics. Okay, whatever. He used persuasion on distros, which resulted in users being forced to use systemd or to switch distros. That force, called coercion, of distros on users is what they didn't like.
I used the word "politics" because "coercion" is stronger. But since you don't like the word "politics," I'll use "coercion" instead. Because that's what it was, even if Poettering wasn't applying the coercion himself.
> The reason users cannot make this choice is because the init system and service manager is primarily something that needs to get set up by the distro...
Again, distros can support multiple. See Gentoo.
Also, now you are admitting that users didn't have choice? Glad we agree on something. I just can't believe you think that was a good thing.
> The distro maintainer is actually the primary user of this type of software so what they say goes...
No, users are still the primary users, just like Microsoft is not the primary user of Windows. Microsoft can do things that are good for Microsoft and bad for users. Same thing happened with distros and systemd. I think that the revealing of the disdain distros had for their users was surprising and was part of the source of the anger.
And the fact that I have to convince distros to adopt my init is exactly why I'm not going to be pushing it. The Linux community does not need a repeat of the systemd debacle.
> ...Users that don't will do like you and leave for another distro, or create their own...
Because using computers for kicks and giggles is not why people use computers, in general. They use them to get stuff done. They don't like maintaining computers. They don't like taking time away from their actual tasks.
Well, switching distros takes time to reinstall, to debug hardware/driver issues, to learn how to install software, to install all of the required software, to learn how to use the distro, etc.
A lot of users were coerced into facing a choice: spend the time to learn systemd or spend the time to jump ship. Both choices were awful because they meant time spent away from the tasks they needed done.
Most decided that learning systemd would take less time, but that doesn't mean they were happy about it.
> You have even starting making your own init system! If what you say about "choice" was true, you would not even be able to do that.
This is only possible because I am a C programmer. Most Linux users are not. Claiming that I have choice because I have skills is a subtle way of discarding users who do not have that possibility. It's an elitist mindset, and it's a mindset I wish this industry didn't have.
I'm not concerned about systemd's restrictions on my choice; I always had the capacity to get around it. (Actually, I had to learn Gentoo, but it was worth it.) But most users do not have that capacity. They may not have the skills and the time to learn them.
Most users just want to get things done. systemd came in and made that harder, at least for a while, or maybe even permanently, and there is anger because of that.
> This is exactly what Lennart did...
Absolutely not. This is rewriting of history. He went to distros not end users. End users are who I care about, not distros.
> Systemd did actually solve a lot of problems the distros had.
Yes! You're absolutely right. It solved a lot of issues that distros had, but not users. I used the word "people," but I should have used "users" because, as I said, users are who matters.