4 ms·

> The saddest thing about the whole affair is that it has a stifeling effect on new devs. Who would dare to write another systemd after that? Certainly not me.

> The saddest thing about the whole affair is that it has a stifeling effect on new devs. Who would dare to write another systemd after that? Certainly not me. Me! I want systemd capabilities in a small package. I also want it to not take over my machine like systemd did. I want to be able to compose individual daemons, not have the init subsume them. I do like the idea of supervision systems, though, and I am glad systemd popularized (not invented) them. So since the alternatives are quite...user unfriendly (s6), I'm making my own. It's called Ur (universal runner, also after the ancient city of Ur), and I'm building the dependency management for it, which will also go into a build system. So why wasn't this affair stifling to me? It's because I see why people got angry: Poettering used politics to limit user choice. User choice has been a theme of Linux use for decades, and people were not happy about it. I'm not going to limit user choice, so I'm not worried about angering people in that way. 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. Actually, the dichotomy between build systems and init systems is a good example. If a distro choose a build system to base their package manager off of, and you are on that distro when they make the change, their choice does not affect your use of another build system, unless your build system does not come installed by default, in which case, you install it and then continue as normal. But if your distro changes the init, you're in for a long period of relearning and retooling everything. I think Poettering pushed systemd through politics because he wanted to have a popular piece of software, and that's only the real way to do it because distros adopt init systems, not users. I don't blame him for wanting a popular piece of software; I do too. That's why I have another piece of software to advertise, just so I don't have to advertise the init. So why make it? Because I want it, and I'm on Gentoo, so I have the skills to switch out the current init (OpenRC). It's for me alone, and maybe for people who like it.

Crysstalis 4y ago
>I also want it to not take over my machine like systemd did. 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.
- ghoward 4y ago
  > 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 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-culture/#culture https://gavinhoward.com/2021/09/comments-on-cosmopolitan-and...
forgotpwd16 4y ago
>I think Poettering pushed systemd through politics because he wanted to have a popular piece of software Poettering already had created PulseAudio and Avahi which were used in every major distro for years before even starting systemd. Even discounting that, politics had nothing to do with system's adoption. Rather systemd was adopted because it was technically superior to any contemporary alternative.
- gavinhoward 4y ago
  > Even discounting that, politics had nothing to do with system's adoption. They had a lot to do with systemd's adoption! As I said in a reply to a sibling comment, usual adoption means getting users to adopt your software. Poettering used politics to get distros to adopt his software. Completely different methods. > Rather systemd was adopted because it was technically superior to any contemporary alternative. Not really. For certain use cases, yes, but systemd is still laughably bad.
- kasabali 4y ago
  > politics had nothing to do with system's adoption So Poettering wasn't an employee of Red Hat when he was writing systemd, wasn't coworker of Fedora developers when they were adopting systemd and all its subprojects? He also wasn't working at the same company with Gnome developers when they were making logind a hard dependency? I bet he also didn't have anything to do with his coworker Kay Sievers taking over udev maintainance only to subsume it into systemd shortly after. Politics has nothing to do with systemd's adoption, really.
pxc 4y ago
> If a distro choose a build system to base their package manager off of, and you are on that distro when they make the change, their choice does not affect your use of another build system, unless your build system does not come installed by default, in which case, you install it and then continue as normal. > But if your distro changes the init, you're in for a long period of relearning and retooling everything. Depends on your distro's tooling and focus. At some point in the past, NixOS actually did switch away from OpenRC (IIRC) to systemd, supposedly without all that much fuss for end users. On the other hand, migrating away from using Nix for builds would be a huge, huge deal and a big controversy to NixOS users.
- gavinhoward 4y ago
  Fair enough.

Crysstalis 4y ago

>I also want it to not take over my machine like systemd did. 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.

ghoward 4y ago
> 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 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-culture/#culture https://gavinhoward.com/2021/09/comments-on-cosmopolitan-and...

forgotpwd16 4y ago

>I think Poettering pushed systemd through politics because he wanted to have a popular piece of software Poettering already had created PulseAudio and Avahi which were used in every major distro for years before even starting systemd. Even discounting that, politics had nothing to do with system's adoption. Rather systemd was adopted because it was technically superior to any contemporary alternative.

gavinhoward 4y ago
> Even discounting that, politics had nothing to do with system's adoption. They had a lot to do with systemd's adoption! As I said in a reply to a sibling comment, usual adoption means getting users to adopt your software. Poettering used politics to get distros to adopt his software. Completely different methods. > Rather systemd was adopted because it was technically superior to any contemporary alternative. Not really. For certain use cases, yes, but systemd is still laughably bad.
kasabali 4y ago
> politics had nothing to do with system's adoption So Poettering wasn't an employee of Red Hat when he was writing systemd, wasn't coworker of Fedora developers when they were adopting systemd and all its subprojects? He also wasn't working at the same company with Gnome developers when they were making logind a hard dependency? I bet he also didn't have anything to do with his coworker Kay Sievers taking over udev maintainance only to subsume it into systemd shortly after. Politics has nothing to do with systemd's adoption, really.

pxc 4y ago

> If a distro choose a build system to base their package manager off of, and you are on that distro when they make the change, their choice does not affect your use of another build system, unless your build system does not come installed by default, in which case, you install it and then continue as normal. > But if your distro changes the init, you're in for a long period of relearning and retooling everything. Depends on your distro's tooling and focus. At some point in the past, NixOS actually did switch away from OpenRC (IIRC) to systemd, supposedly without all that much fuss for end users. On the other hand, migrating away from using Nix for builds would be a huge, huge deal and a big controversy to NixOS users.

gavinhoward 4y ago
Fair enough.