Systemd Creator Lands at Microsoft

well, that's the question. how would such an announcement have been received?

i expect the response would not have been much different really, so the only difference is that the response happens several months after the move, which now makes it a fait accompli.

trying to put myself into poetterings shoes the difference to me would mean that, if questioned, i could talk more confidently about why i made the move, pointing at how it affected my work, instead of speculating about it. it would also give me time to acclimate myself to the new situation.

so keeping the move quiet simply makes it easier to deal with any negative responses.

> 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.

>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.

Then you may have also missed the various responses to those criticisms and things that were done to address them.

> I seem to remember that the main thing it did was bring "being maintained" to the table, because esound was unmaintained and stagnating.

Well, that's true in so far as the useless DE-specific sound servers, but ALSA's userspace/plugin one (dmix) was definitely not abandoned and not stagnating. It was actually growing, and the advice then was to target ALSA API directly, not a specific sound server. The same advice is still valid today.

At least from my point of view, the problem with Linux sound has been one of APIs. OSS API is simple but limiting. ALSA API is a complex mess that no one bothers to implement fully and/or correctly. The various sound server APIs are sound server specific and range from the simple but limiting again (e.g. esd), complicated and still limiting (e.g. arts, PA) or just too complicated (e.g. jack). Using gstreamer as just a sound output API is not taken seriously.

The only reasonable option is to use a libao-like wrapper.

> I also still find this to be really ridiculous when people call maintainers "toxic" for being slow or for rejecting patches. Every open source project does that.

That's not the full story. Anyway, "being slow for accepting patches" is another word for "unmaintained" which you literally complained above and argued it is a point for justifying a replacement.

> Actually it has

No, it hasn't. What I was referring to is the glitch-free feature from Pulseaudio which is what actually broke most people's audio. This entire approach with longer buffers, few/no hardware interrupts and copious usage of ALSA's rewind feature (a deadly combination which broke most ALSA drivers). Compare with Pipewire which goes back to a more "traditional" small buffers and low latency approach.

Pipewire implementing the PA protocol is just more proof of the disaster that are the Linux audio APIs. Even Lennart said most people should not target the PA API.