Systemd Creator Lands at Microsoft
phoronix.comNever thought all those "systemd is turning Linux into Windows" jokes would age like wine, yet here we are.
> age like wine
No pun intended?
Oh, I hope that was intented! ;)
On that note, Wine, too, has aged like wine :)
As someone who thinks PulseAudio is conceptually flawed, I don't really get the way old linuxers hate on systemd. I mean ok, from a user perspective certain common things in systemd could have been friendlier, but I always got the things I needed to work and it is clearly a powerful system. While I don't really like the way Poettering handles projects, I think nobody who does open source software deserves that kind of hatered for a piece of software they have written.
Usually if you don't like a piece of software, you just don't use it. And this is the core of the problem: If I got the critics correctly the problem has more to do with the way this has been "forced" onto the community. Most criticism on the substance has been just bias colored by this aspect or people being like "I was used to the old system, now I need to learn something new".
The latter is of course a totally valid point. If you want people to change their habits, you need to give them a clear reason why and — more important — they need to want to change that habit themselves.
The same greybeard friend of mine who still complains on systemd happily adopted pipewire. Why? Because he saw a clear benefit in doing so and nobody forced this onto him.
Critica might argue Pöttering now going to Microsoft is proof that he always has been the devil, I'd argue it is proof that a certain kind of culture can drive people out of open source. I could imagine a different kind of universe in which the communications between the systemd devs and the rest of the community had been different and we would not only have gotten a better systemd, but maybe also a Pöttering who would not go to 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 issue not being forced only. It's how valid criticisms are just tossed out of the window and systemd is developed as is because "the lead developer and the team knew way better than the collection wisdom accumulated over the years".
Funny thing is they have bitten by the bugs they claimed they're immune to, so they had to apply these principles like they're first adopters of these.
I've voiced my criticisms over the years, yet I still use systemd. I don't like it, but I don't hate it either.
I want to share them, but, It'll be long, so I'll just leave links to my own comments:
1- https://news.ycombinator.com/item?id=27651567 - A general criticism comment.
2- https://news.ycombinator.com/item?id=25616356 - A general criticism thread.
3- https://news.ycombinator.com/item?id=29672248 - About bugs in systemd.
At the end of the day, if a critical component of an OS is being replaced, people at least want their concerns addressed. Want to have some conversation. Being yelled at literally and proverbially as forcing adoption of said software is bound to create some backlash.
*Edit:* Initial text contained in this reply misunderstood the parent. Corrected, clarified, softened and re-written. Sorry about that.
This is probably the same issue with Wayland.
There are some massive quality of life improvements, but then there a few rough edges and papercuts and rather than address them, the conversation gets shut down.
> The same greybeard friend of mine who still complains on systemd happily adopted pipewire. Why? Because he saw a clear benefit in doing so and nobody forced this onto him.
I still use OpenRC + ALSA (with apulse for those programs that shit on backwards compatibility) and I too am looking at PipeWire. Beyond the not being forced aspect and actually adding something that is useful (to me), PipeWire also seems to take much more care about working with existing programs/interfaces rather then wanting to get them on the shiny new API.
> 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 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.
> 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.
> 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.
> 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.
Fair enough.
>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.
Systemd went against the whole philosophy of linux. The philosophy is to be able to choose which software you use. Systemd may have improved a lot of things, but it was a huge step backwards in terms of freedom of choice. Its creator admires Windows and the way it is designed and has tried to turn Linux into a Windows. And not to mention the careless way systemd is developed. I do not trust.
Automatically translated.
>Systemd went against the whole philosophy of linux. The philosophy is to be able to choose which software you use.
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.
> You can still choose whatever you want, by removing systemd from your system and replacing it with something else.
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.
That is unrelated to the issue. Developing any OS is not easy and takes expert work and a lot of time. No one ever said it was going to be easy. There is no choice that frees you from doing that work. The "choice" is entirely about how you are going to approach that work, and who you have chosen to do the work.
Saying that choice still exists because it can be done is disingenuous when others are saying that choice doesn't exist for most people who can't do it.
> 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...
>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 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 is the second part of my comments.)
> 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.
(Split my comment in two because HN complained it was too long.)
> 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.
>The same greybeard friend of mine who still complains on systemd happily adopted pipewire.
Pipewire is not from Poettering. He did Pulseaudio, which is so terrible it inspired the folks to write Pipewire to replace it.
People keep talking about how terrible Pulse is for them, but my decades of experience using Linux desktop recalls that for whatever faults Pulse might have it was a huge improvement over the shitshow that was Linux audio before it.
I adopted Pulseaudio back when it was still called Polypaudio, so I am aware of the problems of Linux audio before it, but PA was just yet another sound server in a world that was already full of them and didn't really bring anything to the table. Linux audio world is exactly as much of a shitshow today as it was before PA. Lennart didn't even envision people writing the PA API directly, but rather going through gstreamer (then a fancy new thing) or the like.
Pulseaudio got popular and then became "irreplaceable" because it started playing a role that would have been played by HAL back in those days; i.e. setting up audio policy (routing, etc) whenever the kernel would fail at it. I was very critic of Pulseaudio, a sound server, incorporating this role, and argued that this complexity would make this project impossible to replace with a newer sound server when it inevitably came. I was proven wrong, albeit in my defense the replacement Pipewire did require a shitton of effort, and PA was becoming toxic in the meanwhile (see the Bluetooth codecs drama).
Pulseaudio's "big" technicaly improvement ("glitch-free" audio, aka interrupt-less, long buffers), and without a doubt its major cause of annoyances to users (since it exercised a lot of rarely used APIs), has not been adopted by Pipewire (which goes back to "low latency" + lots of interrupts) or any other sound server for the matter. (And Pipewire still manages to have better performance...)
>but PA was just yet another sound server in a world that was already full of them and didn't really bring anything to the table
I seem to remember that the main thing it did was bring "being maintained" to the table, because esound was unmaintained and stagnating. I still find this to be really ridiculous that people complain about supposed "hostile takeovers" in open source when, for a lot of categories of project, there are still somewhere between zero and one alternatives for any given thing. All you have to do to become the top dog is make something that does the bare minimum and doesn't crash, and has like, one person to triage bugs.
>PA was becoming toxic in the meanwhile (see the Bluetooth codecs drama).
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.
>has not been adopted by Pipewire
Actually it has, Pipewire implements the pulse protocol for backwards compatibility. The pipewire developers are also still encouraging developers to use it because it is a lot nicer to use than the pipewire API.
> 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.
>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.
Dmix was always a poor solution for desktop sound. It can do mixing but that's not the whole story. To have any kind of concept of audio streams and routing, it has to be done in a daemon. It can't be added with just alsa plugins. The correct way to use alsa currently is actually to use the pulse/pipewire pcm, so you can use the simplest parts of the ALSA API without any of the drawbacks.
>At least from my point of view, the problem with Linux sound has been one of APIs.
Well, that's just the problem isn't it? To make the "one API to rule them all" you have to make an API that encompasses all of them, and it becomes as complicated as all of them combined.
>That's not the full story.
I thank you for sparing the details, but my point was, I am sure you can summarize it without accusing someone of malice.
>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.
Yes, I have no complaints about pipewire.
>What I was referring to is the glitch-free feature from Pulseaudio which is what actually broke most people's audio.
Sorry, I thought you meant the API that allows you to queue buffers and allows applications to make use of that glitch-free feature. That part is implemented in pipewire-pulse. Because why wouldn't it? Pipewire is designed that way because it's easy to add buffering on top of the "traditional" approach than it is to do the reverse. That decision was made actually because it allowed Wim to implement both the pipewire and PA APIs effectively.
>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.
No, you're mixing this up. Applications should indeed probably use something like gstreamer, and then gstreamer targets the PA APIs. Gstreamer also does support this type of buffering and I would imagine this is one of the reasons why PA also supports it.
> To have any kind of concept of audio streams and routing, it has to be done in a daemon. It can't be added with just alsa plugins.
I really don't see why. Do note that dmix runs in user-space like any other sound server. Certainly it never had dynamic audio stream routing, but it is something that could have been added with a plugin...
I actually wrote a simple ALSA plugin for bluetooth audio back in the day (not the current one) and the biggest problem was that (as usual for the ALSA API) plugins just cannot emulate all the functions of the ALSA API (e.g. mmap), not to mention that some closed source programs even banged the kernel directly anyway. Since these programs wouldn't work with the ALSA pulseaudio module, I'm assuming this is no longer a problem today.
I'm not advocating ALSA (it's a mess), it's just to say that again, PA did not bring much to the table at the time.
> Sorry, I thought you meant the API that allows you to queue buffers and allows applications to make use of that glitch-free feature
No, I specifically mean the use of large buffers and rewind usage compared to smaller buffers. See https://lwn.net/Articles/847412/ (just grep for rewind). Pipewire explicitly does not do this, and while it can result in increased CPU utilization due to more interrupts when lower latency is required (and the default latency is quite low), performance of Pipewire turned out to be still competitive.
> No, you're mixing this up. Applications should indeed probably use something like gstreamer, and then gstreamer targets the PA APIs.
What is it that I'm mixing up? Lennart himself said that most programs should not target the PA API. See http://0pointer.de/blog/projects/guide-to-sound-apis (2008). Literally the only category where he recommends PA API is for a mixer program; for everything else he recommends ALSA or gstreamer.
The "proof" that I mention is that most programs ended up targeting the PA API _anyway_ , despite the recommendations of the author. Which forced Pipewire to implement the PA API in order to provide a smooth transition (otherwise it would break everyone's audio _again_). Likely people used PA API because it is the lesser evil if you compare it to ALSA, and because people generally are afraid of abstraction layers (same reason libao and friends get little love, perhaps with reason).
>Do note that dmix runs in user-space like any other sound server.
Dmix is explicitly not a sound server, it is a plugin implemented in the alsa library that does "cooperative" mixing of the sound in an shm region. Adding all those other features and turning it into a daemon is a rather roundabout way to re-implement pulseaudio.
>No, I specifically mean the use of large buffers and rewind usage compared to smaller buffers
Right, but an application can still submit a large buffer that then needs to get muxed down. Pipewire has to account for this possibly by emulating that rewind inside the daemon.
>Lennart himself said that most programs should not target the PA API
I think you have missed this emphasized part:
>For now, the PulseAudio API should be used only for applications that want to expose sound-server-specific functionality (such as mixers) or when a PCM output abstraction layer is already available in your application and it thus makes sense to add an additional backend to it for PulseAudio to keep the stack of audio layers minimal
So that would be why gstreamer targeted the PA API, anyway.
>The "proof" that I mention is that most programs ended up targeting the PA API _anyway_ , despite the recommendations of the author
That article was written in 2008, things changed since then. Wim is currently saying the same type of things about the pipewire API (because it is unstable and unwieldy) but I suspect eventually it will become stabilized, gain some convenience features and then become used by applications just like the PA API...
> Dmix is explicitly not a sound server, it is a plugin implemented in the alsa library that does "cooperative" mixing of the sound in an shm region. Adding all those other features and turning it into a daemon is a rather roundabout way to re-implement pulseaudio.
I don't understand the purpose of this semantics discussion. I was just trying to say that dmix was very alive and growing, and for a time it even was going to be the replacement of the mostly-useless DE-specific sound servers, which are the reason many were abandoned. Whether you want to call it a sound server or not is irrelevant since it fulfilled the same role and had the same features as other sound servers of the era.
> Right, but an application can still submit a large buffer that then needs to get muxed down. Pipewire has to account for this possibly by emulating that rewind inside the daemon.
The point was that Pipewire didn't follow this Pulseaudio-specific design which actually was one of the primary technical improvements in Pulseaudio and at the same time the major cause of incompatibilities.
> I think you have missed this emphasized part
No, I have not missed this emphasized part. The point was that Lennart himself said that most programs should not target the PA API. Unless you are going to claim that gstreamer itself is "most programs" , my point still stands: Lennart himself said that most programs should not target the PA API.
> That article was written in 2008, things changed since then.
Actually, not much has changed since then in either ALSA or PA APIs. Everyone (including Lennart) _still_ recommends you target the ALSA API directly.
But, anyway, the point was to show that even despite the recommendation of the author of one of the APIs not to use it at the time, everyone used it anyway, further complicating the mess, and resulting in PW having to implement the PA API for a smooth transition.
If only stuff like gst had used the PA API, PW could have just shipped a gst module and called it a day. There would have been absolutely no reason to implement the PA API at all. Well, other than the gnome mixer program.
>I don't understand the purpose of this semantics discussion
>Whether you want to call it a sound server or not is irrelevant since it fulfilled the same role and had the same features as other sound servers of the era.
This is not semantics from me, you are trying to say the phrase "sound server" doesn't mean anything, or it actually means "servers but also plugins". No, that's not true. It has specific meaning. You are limited as to what you can do in an alsa plugin. It is not the same as having a daemon running.
If you are saying from the perspective of the ALSA API, the interface is the same as dmix, that is true. Those sound servers have just provided their own pcm. If you want to use this to say "I don't care as an application developer if it's a plugin or a sound server" then that should also show you that the approach of dmix is not all that great or important.
>The point was that Pipewire didn't follow this Pulseaudio-specific design
And I will say again that what Wim actually did was intentionally choose a design that could easily be used to implement a Pulseaudio-specific design on top of it. That is why pipewire-pulse is able to work. You can ask him about this yourself, I would rather not go back and forth with this hearsay.
>Unless you are going to claim that gstreamer itself is "most programs"
You have missed the point of that part though. Transitively it may very well be "most programs" if you use a lot of media apps, because those apps will use gstreamer which then uses pulseaudio underneath. Anyway I think it is pointless for you and I to keep harping on this one person's opinion, because that's all it is. An opinion on a blog. This is really not worth getting worked up over.
>Everyone (including Lennart) _still_ recommends you target the ALSA API directly.
He can recommend that all he wants. As you have found out, in open source that doesn't stop people from using the API. They will use whatever they want, for better or worse, irrespective of whether it will complicate the mess or not. Actually I would say all of open source is just a big complicated mess that will never reduce as long as it keeps growing.
>If only stuff like gst had used the PA API, PW could have just shipped a gst module
They did do that, this is not enough to call it a day though because it would not ensure binary compatibility with old gstreamer builds that don't have the new module. Also that is only one library, it doesn't count all the other libraries that fall underneath this category that may not support modules. The suggestions you are making are either not realistic or are hypotheticals based on hindsight. Of course, had anyone known all these issues years ago, they might have made OSS the perfect API at exactly the right time and then there would be no fragmentation. But the ship has sailed on that.
Agent Poettering, welcome back. You've done tremendous work for us.
*I actually don't care strongly about systemd one way or the other but couldn't resist the joke
I don't know why the hate, both systemd and Pulseaudio are great, at least better than what was before them and improved Linux desktop quite a bit.
Maybe for you. For me pulseaudion brought only problems. And the additional daemons did not bring any improvement (i don't use gnome or kde).
Pulseaudio created a lot of pain when it first arrived, since it had a ton of teething problems. It doesn't have logical defaults even today.
However, Pipewire just worked without any problems and smoothly the day it landed.
Just, no. Pulseaudio legitimately screwed up Audio on Linux for years and is a major source of headaches, even still today, for anyone trying to do audio properly on Linux.
Thank FNORD for Pipewire, meanwhile.
Did you actually use Linux audio before pulse audio?
It sure was great only using sound from one application at once.
I did, and contrary to unfounded meme, this was actually possible before PulseAudio was introduced.
Used JACK extensively before Pulseaudio came along .. never had any issue with it that Pulseaudio would solve.
Of course having audio switch when you switch applications has its benefits as well...
double agent poettering. you are to remain quiet in your new position until you receive the call to activate.
Due to an unforseen DBUS on WSL bug, we never were able to activate our double agent.
On the contrary: DBUS queue was never cleared and the agent kept receiving activation signals over and over unil overflowed ))
now that's just great. now he is hyperactive and needs meds to calm down.
Hahaha, he's your problem now!!
Just kidding, I hope everything goes well for him and I've really enjoyed following his work and reading his blog throughout the years.
i am not surprised that he made this move quietly.
poettering's work attracted a disproportionate share of criticism, and moving to microsoft is not exactly a helpful move to quell that criticism. on the contrary, it will only get worse.
since he continues to work on systemd, critics will now start to decry systemd as being a microsoft product, or at least strongly influenced by microsoft. so this move is likely to strengthen the anti systemd camp. we'll see what comes from that.
As a person who doesn't like systemd a lot (yet doesn't hate it either), I find some of the criticisms well founded.
I've written them in the past, so I'll not re-iterate these walls of text, but all in all, systemd had to learn some things over and over just because it disregarded people's warnings about the problems some of these design patterns create.
Being a little agreeable and open to discourse is not a bad thing.
All in all, systemd makes different trade-offs w.r.t. design, and is not radically fast when compared to what's coming before that. Capability wise it made some things easier (not possible), and some things way more harder.
It's just another iteration. Hope he doesn't pulls another "De Icaza", and all goes well for him.
OTOH, I can't trust neither him, nor Microsoft, because I look actions rather than words.
Let's see.
What does "quietly" mean to you? It would be an exercise in conceit to broadcast such a move on social media with the assumption that people are interested, wouldn't it?
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.
It'd be nice if Microsoft finally incorporated systemd support into WSL in a first-class way. At the moment, if you want to run a distro with its normal init system and service manager, you have to run the whole thing inside a user namespace so that systemd can be PID 1.
Am I the only one who finds that weird that the author of this piece purportedly a journalist relies on twitter and rumours rather than you know email or call Pottering to ask him what he is doing? Is Phoronix supposed to be taken seriously?
Well the article does state:
>At first I thought they were jokes or just snarky remarks, but after a day of following up with folks, it actually turns out not to be a joke.
So who's to say he didn't? Twitter seems just to be where he first heard it
I mean why is he following up with folks? It’s not like it’s extremely hard to get in touch with Poettering.
His redhat email returns out of office err OOF
From my observations, Poettering is not a person who kindly answers his e-mails.
Your observation strongly differs from mine then. Poettering has always been fairly reachable and is easy to communicate with. That might have changed following the torrent of abuse a minority of the Linux community threw at him. I hope it’s not the case.
I really would love to be proven wrong to be honest.
Frankly no. I don't mean to denigrate, but Phoronix is generally not seen as all that great a source of good journalism. He did say he at least tried to confirm this news however.
Say what you want about Microsoft, but the thing is they look after their people. See Miguel de Icaza for a previous example.
Can you elaborate?
What he means is these people were always Microsoft employees with the purpose of sabotaging Linux and now they can enjoy a nice, well-funded retirement at their master's palace.
Hey, he'll feel right at home with Powershell and the absurdly long verbs it uses.
You know that they can be shortened right? Get-ChildItem = gci
I for one really like PowerShell, if it could consume bash completions I would switch to using it as my $SHELL. Right now I'm leaning to switch from ZSH to Xonsh (Python).
Reason for liking PowerShell: C# compability, OOP, semi-sane syntax.
You can do type definitions, serde multiple formats into native structures.
Anyone who criticizes pwsh’s verbosity has never actually used it. It comes with great aliases by default and fuzzy matches switches to shorten them.
I don’t use many tools outside cmdlets or pwsh built-ins, but have you turned on history completions and menu complete? I find that I don’t need completions for external commands since history complete will just remember what I did last time.
It really is very hard not to make jokes about this.
Looks like a tactical 'Embrace'.
On top of that, surveillance capitalism is winning over the free software / open source developers as companies like Microsoft are buying out / hiring the majority of them.
The free-software activists from the FSF and other free-software supporters have lost to the tech bros at these big tech companies that have hijacked 'open-source' and ran with it.
They have failed in their mission to stop all this closed-source software from spreading. It looks like it is here to stay; especially with the help of former free software developers.
I guess if you can’t beat them, join them.
They pay you $500k/yr and up. Your open source project pays $50 on a good month. You have a house to maintain and family to feed. Why would you turn down such an offer?
One thing I will caution those who do take the offer, the company will use you until you are no longer necessary and then throw you out (extinguish)
Got a source for that $500k/year salary?
It might also be worth mentioning that Poettering was an employee at Red Hat, working on these open source projects, so I'd assume he was being paid more than 50 dollars a month for his work.
Source: My paycheck
And I have actively watched OSS devs get shown the door when their work no longer matched the company's mission.
levels.fyi, for one. Someone as notable as him would be L66+ easily, I feel.
Maybe not 500k, but is 400k that far off?
I know the GP is talking about generally but Poeterring was working at Redhat, he wasn't a lone open source developer fighting in the wilderness.
If you are in FOSS for the money, you are not in FOSS.
Humanity could be sat around eating fruit and making art, instead we have mortgages and credit scores, because the venal systems corrupt and extortionate the progressive ones.
We have mortgages and credit scores because the aformentioned humanity more often than not lacks the responsibility to assess both the financial capabilities of those who borrow the money and the evaluation capabilities of those who lend.
This is a late stage cause. There are also many early stage causes.
"Shepherds, Merchants, and Credit: Some Observations on Lending Practices in Ur III Mesopotamia" https://www.jstor.org/stable/25165020
Late stage, huh?
How long do you think that humans have existed?
Depends on what humans we're talking about. 200k years, if we talk Homo Sapiens.
It is like the Wall Street getting ex-hippies during the early 80's.
Eventually food on the table is needed and there is a family to feed and mortgage to pay, and working for the man isn't that bad as one once thought.
Or the ex-hippies knew very well that Woodstock is just a stage (pun intended) and didn't take it that seriously.
I mean, almost all prominent tech companies had those people at one stage or another. Nothing forbade them from listening to the Beatles in their Buicks or counting fat stacks to the sounds of Yellow Submarine.
I think Stallman, and having been at his session done at CERN during 2003, I did actually got to talk with him, doesn't agree with the stage thing.
I meant the hippies that eventually became high ranks in finances/tech (in terms of pay and Buicks per garage ratio).
That may be.
That all is a lot of nonsense, this is an instance of Microsoft paying an open source developer to maintain open source. Yes, they actually do that sometimes.
> That all is a lot of nonsense
It is the cold, brutal truth that is happening right now in the free software / open source ecosystem. Totally accurate.
> this is an instance of Microsoft paying an open source developer to maintain open source.
You might as well put binary blobs in a GitHub repo and call it 'open-source' or / and have telemetry baked in stealing our usage data since the term 'open-source' not only misses the point, but it is quite frankly meaningless at this point.
But we all knew that the tech-bros have hijacked the point of open-source whilst the free software movement have failed to stop all of it.
The cold brutal truth is that open source developers need jobs too. That has always been the case.
>You might as well put binary blobs in a GitHub repo and call it 'open-source'
But this has not happened.
>and have telemetry baked in stealing our usage data
This is not related. I don't think there is any open source or free software that will ever stop that. They actually don't want to stop it. They would consider stopping that to be a violation of the OSD "no discrimination against fields of endeavor" criteria or the FSF "freedom zero".
"Surveillance capitalism is winning over the free software..." software that "just works" and offers the latest and the greatest features does, not "surveillance capitalism" or "open source developers".
"They have failed in their mission to stop all this closed-source software from spreading." except that was never the mission, the mission was to provide an alternative to complex licensing as well as simplify the improvement and development of things "everyone needs" both law-wise and code-wise.
The only mission that could be considered to be "failed" (depending on who you ask) is licensing.
On that front, thanks to anti-GPL folks, we are back into Shareware and Public Domain, although under different names.
I don't think that it's solely the fault of anti-GPL people. GPL proclaims freedom but then demands you to limit your freedom when it comes to anything of your own that just happens to include GPL licensed elements. At that point, proprietary solutions whose providers couldn't care less as long as you pay your fee don't seem that bad in comparison to, say, a competitor who's going to exploit the GPL freedoms to gain an advantage. I mean, considering that the topic is about Microsoft (in a way), don't forget about the existence of the "Source available" license, though IMO the best license is always going to be the one that fits the product rather than ideology (and GPL puts the product in the background).
Public Domain is a great way of releasing intellectual property for everyone to use.
Trying to use GPL software makes you a target with angry techies constantly accusing you of not publishing complete diffs of changes needed to ship features. GPL fanatics are the most to blame for putting negative pressure on GPL. That is why Macs have wget instead of curl. GPL does not necessarily mean poison, but that is what it has become.
"That is why Macs have wget instead of curl." I got curious and decided to look that up. Did you mean to say "curl instead of wget"? "GPL does not necessarily mean poison, but that is what it has become." don't remember where i heard it first, but "with each iteration, GPL becomes less and less about freedom".
At long last I can finally get the Office suite as a .service!
What a surprise
I am not surprised that much by this news. Red Hat paid him well, and there are not a lot of companies that would offer more for the kind of job he does. I am sure this feels like a step forward from his perspective. He will still be able to do what he wants, work on something interesting, and continue to trigger the Linux community.
If this is true, it's more than likely that Poettering would join Microsoft only if his work was focused on systemd, or something similarly interesting and low level. I for one, will be glad that a company is willing to pay for such work, even if it's them.
Oh god I can already see the edgy YouTube thumbnails for videos covering this
"...now confirmed from additional sources that Lennart Poettering did indeed quietly depart Red Hat earlier this year for another employment opportunity." Can't we just wait for any official info?
The snobby attitude about Microsoft on HN makes no sense to me
They’ve worked very very hard in the past to extinguish and annihilate a lot of the values HN stands for. Either you’re too young or didn’t follow tech back then but MS and Gates truly did evil moves to try and kill any and all competition, especially Linux and open source. Many of us remember.
That was the bad old days. Things got better under Nadella. Just like they got steadily more evil at Google. There are no big corporations you can trust in the long term, but at least MS is behaving reasonably well right now.
> Things got better under Nadella
- Windows is now a dumpster fire - Azure is a mess - surface computers suck + much more
I feel like our definitions of “better” are very different
Well, yes. I'm talking about corporate trash antics like getting one of your insiders to wreck a competitor so you can buy out the scraps (Elop and Nokia), or using a proxy lawsuit to try to strangle the open opposition (SCO vs IBM). I'm not judging what's best on a technical level. No amount of hypothetical technical goodness can make up for Ballmer.
Microsoft has not proven to be a good faith steward of their own open-source projects in the 'new days', though.
See https://isdotnetopen.com/ and especially the recent controversies with Omnisharp ( https://visualstudiomagazine.com/articles/2022/06/16/csharp-... ).
See also the first snobby, then underhanded, then petulant behavior of the Windows Terminal maintainers recently with respect to some performance improvements: https://news.ycombinator.com/item?id=31284419
It's very reasonable to be skeptical of Microsoft's relationship to open-source in 2022, even as we might also feel positively about some aspects of their new open-source strategy.
>See also the first snobby, then underhanded, then petulant behavior
This just corporate open source as a whole. I don't know what else he expected. You don't participate in open source with the big boys if you expect a quick response or you expect to get any kind of non-trivial credit for something. It is not you who is paying the bills. No reason to be skeptical about it, this is how the game is played.
> Things got better under Nadella
I will believe that once they will sell Office for linux packaged in flatpak and 1:1 feature parity with windows version.
once you discard the friendly appearing PR ("Microsoft <3 Linux") they're behaving exactly the same as they always have
If you think that, you don't know half the rotten, criminal shit Ballmer did.
Things look better under Nadella. But they really aren't that much better.
Some people here are a bit older than a typical %MODERN_FRONTEND_TECHNOLOGY% developer and thus they remember very well what Microsoft did to Linux and open source community a decade ago and back.
Educate yourself on the topic and it will. Maybe start here?[1][2]
[1] https://en.wikipedia.org/wiki/Halloween_documents
[2] https://www.gnu.org/software/fsfe/projects/ms-vs-eu/hallowee...
Lots of people hate MS because of their monopolistic practices in the past.
Myself, I always despised the company because of the complete shit quality of their software, starting with DOS. That was a pile of crap from day 1, and while much has changed since then, you can still see the complete disregard for quality in so much of what they do.
Software is going the way other industries go: no real competition, no quality.
It's not that they want to do bad software, it's just they don't have any short-term profit on doing so.
A relevant primer, a comment by me: https://news.ycombinator.com/item?id=31987377
The world needs a better way to monetize open source.
More than that, the world needs a basic income system, so that people who feel thus motivated can write open source code^ without having to worry about monetization.
^: or raise children, make art, tend to community organizations, and any number of other socially beneficial activities for which a profit motive would be irrelevant or detrimental
RedHat showed the way. GitLab showed the way. Source Hut is showing the way. There are other examples for sure.
Don't Red Hat and GitLab have really different models, since Red Hat only releases free software and GitLab is merely 'open core'?
Yes, they tread different paths. RedHat sells support (RedHat Enterprise Linux), develops enterprise ready software and gives unbranded, not supported versions to the community to play with and use it.
GitLab sells SaaS, provides a free self-installable community supported version, and accepts contributions from community.
They're pivoting to a more closed model, which I don't like, but it's still possible to get the community version, the code and play with it.
All in all I think many possible different ways to monetize an free and open source project. They work differently than we get used to over the last century, but it's possible.
As a NixOS user, I love systemd
I'm interested in NixOS but it only supports systemd.
Seriously, init systems like OpenRC do one thing and do it well. Where have I heard that before?
NixOS doesn't follow the UNIX philosophy in many ways, especially when it comes to systemd. If you want NixOS you will have to use systemd and embrace it. Otherwise you can go the Guix route and try to make the most out of the much inferior ecosystem.
NixOS does systemd right:
- systemd gives the use a unified API for working with services. The journal etc. - Nix gives the programmer a nice way to define systemd units.
If you hate systemd due to normal Linux..NixOS might change your mind.
Officially yes. Unofficially there're have been attempts to support other init systems, e.g. https://sr.ht/~guido/nixos-init-freedom/ (s6), https://github.com/svanderburg/nix-processmgmt (abstract; allows a few inits).
Yes! Even when not on NixOS I like systemd, one reasonable(not perfect) way to do things? Sign me up!
Rick Belluzzo part deux.
Great, can the Linux heads now finally excise all of systemd along with it's monstrous scope creep, .ini files, binary journals from Linux, or will they continue to find excuses for their tastelessness and corporate slavedom?