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.
>I want to be able to compose individual daemons, not have the init subsume them.
I don't understand why anyone says this, they are individual daemons in systemd. If you are talking about just the init itself, there is no benefit to splitting that into individual daemons. The most complex part is the probably the code in between fork() and exec() that spawns services, this has to be done in all the same place, because this is the part that is actually going to be setting up the rest of the daemons. Also it is complex to write because it has to be async-signal-safe. Everything else is just configuration around that part.
>Poettering used politics to limit user choice.
This is a really nonsense statement. He didn't limit anything or use politics, you can just not use his programs. It's incredibly easy to do that in fact. The "user choice" you have is the same as it always was, it's exactly what allows you to develop your own init or use Gentoo. If you ask me, most of the drama (with both systemd and pulseaudio) was because of botched distro rollouts, not politics.
>I'm also not going to advertise and push Ur like systemd was. I'm going to advertise my build system, and Ur will be bundled with it, and I will help people use Ur, but I'm not going to push Ur because an init and supervision system is just too central to Linux machines to push it on people.
I don't know what it is about engineers that makes them reluctant to promote their own work. I see this so often. If you work is good, please advertise and promote it. Please encourage people to use it. This is a forum about start-ups, that's what you do here. Users deserve to have good solutions and they deserve to have those promoted far and wide if it can help a lot of people. Don't worry about the comments from the peanut gallery. If you are confident that your work is good and useful, you can ignore the haters. Your users will know that it's doing something good for them and that's all that matters. It does not matter that anything is "central to a Linux machine" or not, good products are good for whatever place they fit in.
Don't take this to mean you should promote bad and unproven work, your seed users should be able to tell you what's good and what isn't.
>But if your distro changes the init, you're in for a long period of relearning and retooling everything.
No, this isn't true. You could just make the init backwards compatible, which systemd actually is with sysvinit scripts. Actually, to prevent any amount of friction you can make yours backwards compatible with systemd.
Automatically translated.
No, this is wrong in two ways.
First, that is not the Linux philosophy. According to Mr. Torvalds, the Linux philosophy is "Do it yourself": https://groups.google.com/g/linux.dev.kernel/c/qeeP584Ny08/m...
Second, even if that was the Linux philosophy, systemd didn't go against that choice. You can still choose whatever you want, by removing systemd from your system and replacing it with something else. This can be as simple as changing the symlink of /sbin/init to something else, but it gets harder if you have more configuration you need to migrate over to a different format. Systemd has not made this any easier or harder. It is the same as it always is when migrating between two different choices.
And if you really do not like the way systemd is developed, and you do not like any of the available replacements, then according to Mr. Torvalds you should go and make a replacement yourself, just like the parent commenter has taken the initiative to do.
Oh, you can do it, but the experience of Devuan shows that it is not easy and takes expert work and a lot of time.
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 specific supervision system. (By default, of course, it will spawn mine.) So you could technically run my init and then run systemd as the supervision system under it. (Well, you could if systemd wouldn't complain about it, which I bet it would.) Or you could run s6 or daemontools or runit or whatever.
So your claim that any init has to "take over the machine" is not true; the real program running things is the supervision system, and with my init, people will be able to choose the one they want. If they choose mine, great. If not, whatever.
In other words, your claim that I cannot make an init that doesn't take over the machine is false.
> I don't understand why anyone says this, they are individual daemons in systemd.
They may be separate processes, but if something refuses to run without systemd as init, then it is part of systemd, and systemd has subsumed those daemons.
> If you are talking about just the init itself, there is no benefit to splitting that into individual daemons. The most complex part is the probably the code in between fork() and exec() that spawns services, this has to be done in all the same place, because this is the part that is actually going to be setting up the rest of the daemons. Also it is complex to write because it has to be async-signal-safe. Everything else is just configuration around that part.
Actually, you're wrong. As I implied above, init should be something close to Rich Felker's minimal init, and the supervision system should be separate.
That's not to say that they can't share code, but sharing code can be done through libraries, including the fork()/exec() dance.
Also, I've written an async-signal-safe fork()/exec() dance. It's not hard. It just requires reading the manpages.
> This is a really nonsense statement. He didn't limit anything or use politics, you can just not use his programs. It's incredibly easy to do that in fact. The "user choice" you have is the same as it always was, it's exactly what allows you to develop your own init or use Gentoo.
Yes, he did. He used politics to get distros, not users, to adopt systemd by fiat, the same way someone might use politics to get a state legislature to pass a law by fiat. Sure, you can move to a different state, and you can move to a different distro, which is what I had to do! That's not really a lot of choice. The more friction there is to change, the less "choice" there is because those for whom the friction is too much cannot have their choice.
What I am going to do instead is to present my init/supervision system and let users adopt it as they may. As users adopt it, distros might be willing to add it as an option.
> If you ask me, most of the drama (with both systemd and pulseaudio) was because of botched distro rollouts, not politics.
Botched distro rollouts happened because of politics. It's entirely possible for distros to support two init/supervision systems; look at Gentoo. systemd removed a lot of user choice by introducing high friction to switch away by having distros change by fiat rather than over time. I'm sure systemd would have won eventually (without competitors) if distros had adopted it in parallel with sysvinit. People could have switched as they wanted and on their own terms, and they would be happy.
> I don't know what it is about engineers that makes them reluctant to promote their own work. I see this so often. If you work is good, please advertise and promote it. Please encourage people to use it.
First, I am going to promote something: my build system. Like I said, an init/supervision system is different.
Also, just because something is good doesn't mean that it should be promoted. They should only be promoted insofar as they solve problems that people have. [1] If I see an opportunity to promote Ur, that doesn't necessarily mean that I should. Perhaps the person I would evangelize to has no problems that Ur would solve better than their current init/supervision system. If that is the case, I would create problems for that person by wasting their time.
> Users deserve to have good solutions and they deserve to have those promoted far and wide if it can help a lot of people.
Users deserve good solutions, yes, but it is a better thing to make a judgment about whether Ur is a good solution for each individual I come across than to evangelize it blindly.
> Don't worry about the comments from the peanut gallery.
This whole thread started because I said I wasn't worried about comments from users, who you so disdainfully call "the peanut gallery."
> If you are confident that your work is good and useful, you can ignore the haters.
You're the one giving me "hate" right now.
> No, this isn't true. You could just make the init backwards compatible, which systemd actually is with sysvinit scripts.
It absolutely is true. We have the history of systemd to look at. Yes, systemd can run sysvinit scripts, but that's because sysvinit scripts are not run by systemd, they are run by the sysvinit interpreter.
> Actually, to prevent any amount of friction you can make yours backwards compatible with systemd.
systemd's declarative format is completely broken and hobbled. Its various types of dependencies are confusing. Implementation concerns are exposed to the user in various places.
No, I want a clean break from systemd, and I'm willing to have few users of Ur to have it.
By the way, you know my real name; I use it as a way to stop myself from participating in flame wars. However, I do not know who you are, an account created 2-3 days ago, just as these stories about Poettering started coming out. This is slightly suspicious, so could you tell me who you are to lay that to rest?
[1]: https://gavinhoward.com/2021/09/comments-on-cosmopolitan-and...
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 really see what you are gaining from this. I have also made simple inits like this back when I was a student. Usually a project is successful because of its features, not because of its absence of them. How is this any different from using the supervision system as the init? It sounds like you are making a PID1 that spawns one other process as PID2 and then that process takes over the system. So really, from the point of view of a sysadmin running this system, both PID1 and PID2 are the same and they both assume control of the system, because killing either one of them will take down the system.
>They may be separate processes, but if something refuses to run without systemd as init, then it is part of systemd, and systemd has subsumed those daemons.
No it has not. As I said before 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. Those other daemons may not require much more than one or two API calls. You are confusing "subsuming" with "having a dependency", and of course looking at it that way makes it seem a lot less dramatic because nearly all open source packages have dependencies.
>Actually, you're wrong. As I implied above, init should be something close to Rich Felker's minimal init, and the supervision system should be separate.
No, I'm not wrong. As I suggested above, separating it provides no benefit.
>That's not to say that they can't share code, but sharing code can be done through libraries, including the fork()/exec() dance.
I don't see any benefit there either, the libraries are not so useful to any other code. All this code must be able to run as root inside the service manager. Usually you will not have any other code that runs at this privilege level. That's what I mean by "take over the machine", by necessity the service manager must have the highest privilege level and this is part of the design of the OS. You can't change it without changing the kernel.
>Also, I've written an async-signal-safe fork()/exec() dance. It's not hard. It just requires reading the manpages.
I'd say it's more like that it's tedious. The more things you want to set up in there, the more you have to be very careful about how you do it.
>Yes, he did. He used politics to get distros, not users, to adopt systemd by fiat, the same way someone might use politics to get a state legislature to pass a law by fiat.
No he did not, this is incredibly rude to those distros and it suggests that those distros did not have any agency to make this choice. They chose themselves to adopt it because it was good and it made their lives easier. There was no "politics" to push them into it. 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. The distro is the one who ships all the services and writes the service files, users are not expected to do that. The distro maintainer is actually the primary user of this type of software so what they say goes, it is pointless to ask the users for an opinion on this. Maybe looking at it from that point of view will help you with your own init.
>Sure, you can move to a different state, and you can move to a different distro, which is what I had to do! That's not really a lot of choice.
That is plenty of choice. The users don't decide anything anyway and they never did. That's why they choose the distro, because they trust the distro to make the correct decision for them. Users that don't will do like you and leave for another distro, or create their own, which has been done countless times in the history of Linux distros. If no one did this there would only one Linux distro, but there are currently hundreds for you to choose from and a lot of them don't use systemd. I don't know how much more "friction" you need here or why this is not adequate, everything that you need has been given to you but you're still saying it's not enough. 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.
>What I am going to do instead is to present my init/supervision system and let users adopt it as they may. As users adopt it, distros might be willing to add it as an option.
This is exactly what Lennart did, and also what Scott Remnant did when he created upstart, and what DJB did when he created daemon tools...
>They should only be promoted insofar as they solve problems that people have
Systemd did actually solve a lot of problems the distros had.
>but it is a better thing to make a judgment about whether Ur is a good solution for each individual I come across
This does not scale beyond a very small number of users. I hope you can see that it would be impossible to develop something like the Linux kernel this way.
>comments from users, who you so disdainfully call "the peanut gallery."
I don't mean all users. By "peanut gallery" I am actually referring to people who don't use your software and who decided they don't like it. They are not your target audience, don't worry about them. You will not win over every potential user and that's to be expected.
>You're the one giving me "hate" right now.
Actually no, I have been trying to give you tips on how to promote your work and succeed, based on my own experience. Sorry if it came across poorly, that's on me. Maybe my tips are useful and maybe they are not.
>Yes, systemd can run sysvinit scripts, but that's because sysvinit scripts are not run by systemd, they are run by the sysvinit interpreter.
In the same way, you can just make a systemd interpreter. I think some other service managers do actually have that.
>systemd's declarative format is completely broken and hobbled. Its various types of dependencies are confusing. Implementation concerns are exposed to the user in various places.
After learning how to use it, I cannot say I share the same opinion, but you do you.
>No, I want a clean break from systemd, and I'm willing to have few users of Ur to have it.
But this is the tradeoff you have made personally. You can decide to support systemd, it's more work but you get more users. You can decide not to do that, it's less work and gives you some flexibility but it's risky. That is a choice you have made yourself to not be compatible with systemd, based on your own intelligence, it is not systemd somehow manipulating "politics" to make you do that or not do that.
>However, I do not know who you are, an account created 2-3 days ago, just as these stories about Poettering started coming out. This is slightly suspicious, so could you tell me who you are to lay that to rest?
No, I am sorry. I don't use my real name on here because I have been harassed online before, and this account is new because I lost my old one. I am even more cautious when discussing systemd because I have seen a lot of hateful messages about it, and the systemd developers have actually received death threats before just because someone was mad at them for developing systemd. In case you're getting any ideas: I am not Lennart, I have never worked with Lennart, I am not a systemd developer, I am not a Red Hat employee or a Microsoft employee.
> This does not scale beyond a very small number of users...
We are not talking about the Linux kernel. We are talking about an init/supervision system. Why are you moving the goalposts?
I would rather interact with individual users and delight them than have a massive audience. This has many benefits: you get friends, you have fun, and you have less bug reports!
But it does lead to bigger things. More on that later.
> By "peanut gallery" I am actually referring to people who don't use your software and who decided they don't like it...
I know. That's why I want to delight a few users than have many. By not spreading the message wide, I also avoid creating a "peanut gallery" of people. You only get a "peanut gallery" when such people can't ignore your software, so I'm going to make sure such people can ignore my software with no effort on their part.
> I have been trying to give you tips on how to promote your work and succeed, based on my own experience.
Your tips seem less than useful, and I guess I should explain why.
You don't know who you are talking to, which isn't surprising; my name is barely on Wikipedia in a footnote.
Let me enlighten you: I have code in FreeBSD. FreeBSD adopted a piece of software I wrote and put it into the base system. I did this by interacting with individual users and delighting them. One of them happened to care about this piece of software enough to push for it to be put into the base system.
So basically, I do what doesn't scale, and I got a lot of users from it. Didn't Paul Graham suggest doing something like that before? [1]
I know what I am doing when it comes to getting users. Sure, Poettering has more users, but I have more delighted users, and that's a win for me in my book.
> In the same way, you can just make a systemd interpreter.
systemd's language is underspecified. As someone who has written a compiler or two, I would rather walk on glass than implement an interpreter for something like that.
> But this is the tradeoff you have made personally. You can decide to support systemd, it's more work but you get more users.
I would get more users faster if I did that, but there's no guarantee I won't get the same amount of users eventually, even if I didn't. And like I said, I like to do things that don't scale because it's more fun.
> You can decide not to do that, it's less work and gives you some flexibility but it's risky.
Why is it risky? Risky in that I'm risking that people won't use my work? That's not a risk; it's not going to harm me if that happens. In fact, getting users faster is more risky in my eyes. Users are demanding when they are not delighted, and there is a risk of creating a "peanut gallery."
(I should write a blog post about these principles.)
> That is a choice you have made yourself to not be compatible with systemd, based on your own intelligence, it is not systemd somehow manipulating "politics" to make you do that or not do that.
I never said it was. I never said systemd's politics affected my choice to support its language. I said that its design affected my choice.
> No, I am sorry. I don't use my real name on here because I have been harassed online before...
So let me get this straight: you tell me to ignore the "peanut gallery," yet you create a new account to avoid them? I'm afraid I can't take any of your advice seriously now.
By the way, I agree that systemd detractors do harass, and that's never okay. I try to downvote them when they are, even though I don't like systemd.
(I will note that, to your credit, I have not seen you be toxic.)
But I've been harassed with this account, using my real name. I deal with it because that's the reality of our toxic industry. Perhaps I am better at dealing with the "peanut gallery" than you are?
Part of the reason I'm not happy with Poettering is because I believe he contributed to the toxicity, directly (by dismissing users, treating them disdainfully, etc.) and indirectly (by generating anger through indirect coercion).
That's also part of why I want to delight users: delighted people are usually less toxic.
> ...the systemd developers have actually received death threats before just because someone was mad at them for developing systemd.
I know about this, and it is unacceptable. For the record, if such people start using Ur (as they might), and then start doing this, I will hang them out to dry. They can go jump in a lake.
> I am not Lennart, I have never worked with Lennart, I am not a systemd developer, I am not a Red Hat employee or a Microsoft employee.
I guess I have to take your word for this because I have no proof of this.
> 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.
