The thing is that systemd is not just an init system, given it wants to cover a lot of areas and “seeps” into the userspace. There is understandably a big concern about this and not just one of political nature. Many have seen the problems the pulseaudio-monoculture has brought, which is a comparable case. This goes without saying that ALSA has its problems, but pulseaudio is very bloated and other programs do a much better job (sndio, pipewire (!)) that now have a lot of problems to gain more traction (and even outright have to camouflage as libpulse.so).
Runit, sinit, etc. have shown that you can rethink an init system without turning it into a monoculture.
In theory, having all (or at least most) Linux distros on a single audio subsystem seems like a good idea. Bugs should get fixed faster, compatibility should be better, it should be easier for developers to target the platform. But I also see a lot of negativity toward PulseAudio and people seem to feel “stuck” with it now.
So where’s the line between undesirable monoculture and undesirable fragmentation?
The Linux ecosystem is happy with some monocultures, the most obvious one is the Linux kernel. Debian has dropped support for other kernels entirely, most other distros never tried. Similarly, with a few exceptions such as Alpine, most are happy with the GNU libc and coreutils. The important thing is quality and long-term maintenance.
PulseAudio was worse than some of the alternatives but was pushed on the ecosystem because Poettering’s employer wanted to control more of the stack. It’s now finally being replaced by PipeWire, which seems to be a much better design and implementation. Systemd followed the same path: an overengineered design, a poor implementation (seriously, who in the 2010s, thought that writing a huge pile of new C code to run in the TCB for your system was a good idea?) and, again, pushed because Poettering’s employer wanted to control more of the ecosystem. The fact that the problems it identifies with existing service management systems are real does not mean that it is a good solution, yet all technical criticism is overridden and discounted as coming from ‘haters’.
seriously, who in the 2010s, thought that writing a huge pile of new C code to run in the TCB for your system was a good idea?
I really want to agree with you here, but looking back at 2010 what other choice did he realistically have? Now its easy, everyone will just shout rust, but according to Wikipedia, rust didn’t have its first release till June while systemd had its first release in March.
There were obviously other languages that were much safer than C/C++ around then but I can’t think of any
that people would have been okay with. If he had picked D, for example, people would have flipped over the garbage collection. Using a language like python probably wasn’t a realistic option either. C was, and still is, ubiquitous just like he wanted systemd to be.
I really want to agree with you here, but looking back at 2010 what other choice did he realistically have?
C++11 was a year away (though was mostly supported by clang and gcc in 2010), but honestly my choice for something like this would be 90% Lua, 10% modern C++. Use C++ to provide some useful abstractions over OS functionality (process creation, monitoring) and write everything else in Lua. Nothing in something like systemd is even remotely performance critical and so there’s no reason that it can’t be written in a fully garbage collected language. Lua coroutines are a great abstraction for writing a service monitor.
Rust wouldn’t even be on my radar for something like this. It’s a mixture of things that can’t be written in safe Rust (so C++ is a better option because the static analysis tools are better than they are for the unsafe dialect of Rust) and all of the bits that can could be written more easily in a GC’d language (and don’t need the performance of a systems language). I might have been tempted to use DukTape’s JavaScript interpreter instead of Lua but I’d have picked an interpreted, easily embedded, GC’d language (quickjs might be a better option than DukTape now but it wasn’t around back then).
C was, and still is, ubiquitous just like he wanted systemd to be.
Something tied aggressively to a single kernel and libc implementation (the maintainers won’t even accept patches for musl on Linux, let alone other operating systems) is a long way away from being ubiquitous.
In what optics are Pipewire any kind of improvement on the situation? It’s >gstreamer< being re-written by, checking notes, the same gstreamer developers - with the sole improvements over the previous design being the use of dma-buf as a primitive, with the same problems we have with dma-buf being worse than (at least) its IOS and Android counterparts. Poettering’s employers are the same as Wim Taymans. It is still vastly inferior to what DirectShow had with GraphEdit.
I’ve been using Linux sound since the bad old days of selecting IRQs with dipswitches. Anyone who says things are worse under PulseAudio is hilariously wrong. Sound today is so much better on Linux. It was a bumpy transition, but that was more than a decade ago. Let it go.
Yep! Pulseaudio routinely forgot my sound card existed and made arbitrary un-requested changes to my volume. Uninstalling it was the single best choice I’ve made with the software on my laptop in the last half decade.
Was Poettering not largely responsible for the virulent spread of those technologies? If so, I think he qualifies as a vector. I stand by my original wording.
It’s definitely an interesting word choice. To quote Merriam-Webster: vector (noun), \ˈvek-tər,
[…]
an organism (such as an insect) that transmits a pathogen from one organism or source to another
[…]
an agent (such as a plasmid or virus) that contains or carries modified genetic material (such as recombinant DNA) and can be used to introduce exogenous genes into the genome of an organism
To be frank, I mostly see RedHat’s power hunger at fault here. Mr. Poettering was merely an employee whose projects, who without doubt follow a certain ideology, fit into this monopolistic endeavour. No one is to blame for promoting their own projects, though, and many distributions quickly followed suit in adopting the RedHat technologies which we are now more or less stuck with.
Maybe we can settle on RedHat being the vector for this, because without their publicitly no one would’ve probably picked up any of Poettering’s projects in the large scale. To give just one argument for this, consider the fact that PulseAudio’s addition to Fedora (which is heavily funded by RedHat) at the end of 2007 coincides with Poettering’s latest-assumed start of employment at RedHat in 2008 (probably earlier), while Pulseaudio wasn’t given much attention beforehand.
Let’s not attack the person but discuss the idea though. We don’t need a strawman to deconstruct systemd/pulseaudio/avahi/etc., because they already offer way more than enough attack surface themselves. :)
Let’s not attack the person but discuss the idea though. We don’t need a strawman to deconstruct systemd/pulseaudio/avahi/etc., because they already offer way more than enough attack surface themselves. :)
This is why this topic shouldn’t be discussed on this site.
I don’t have an opinion on this specific systemd-related controversy but this blog post reads like projection to me. Politics is, among other things, a mechanism to convince others to share your values. The reason systemd triggers so many of these controversies is because it brings a different set of values to the organization of the system than existed in the past. Among these are speed over visibility, reactivity over predictability, and flexibility over experimentation. The decoupling that systemd tries to provide spreads the footprint of experimentation in a way that requires the experimenter to understand a broader swath of the integrated system versus what was usually just a specific point of invocation for the experimenter’s point of focus. So after a decade long campaign of systemd supporters convincing system integrators to share their values it is a bit ironic to say it is uncouth for others to attempt to do the same.
That’s an interesting analysis, and it confirms my own biases: I want visibility more than speed, predictability more than reactions to other events. I think what you are calling flexibility, though, is actually feature-coverage: systemd attempts to answer all possible questions with a systemd-specific way to do things.
By flexibility I was referring to the loose coupling between units via their dependency targets. In theory it lets you sub in different software to provide specific services. I think it accomplishes that fairly well. The downside though is that the configuration is usually dispersed throughout a set of units that don’t have an inherent organization and almost require you to know how those units are wiring services together in order to have a good idea what to grep for.
That’s the reference. DJB tends to put together a pipeline of executables that each have one set of related functions to perform. Rearranging or replacing them is a relatively easy process because they are all well-documented. As a result, people do – e.g. Bruce Guenter’s mailfilter front-ends and filters that feed into qmail.
Stop using your politics against systemd’s politics makes for a weak rant. I don’t have a strong technical opinion on systemd but the TINA (There is no alternative) “politics” of systemd has been annoying for… ever, hence the push against it and the work to keep a systemd-free alternative alive and viable.
Politics is, in a way, really about resource allocation. Maintainers of an open source project do have the right to make decisions about how their resources are allocated. If their reasoning is bad, you retain the right to fork, but throwing the dirty word “politics” on it is trying to use semantics as a cudgel to force other people to do things they don’t want to do with their limited resources.
I was on the fence, but decided to flag this as off-topic. I don’t think this passes the basic rules of thumb to be posted here.
All that said, the discussion on the merge request was offensive to me and so are some of the comments in here. I agree completely with this blog post that this was handled as poorly as possible if you want to inspire people into your community. People get way too worked up about this topic and it verges on conspiracy theory level at times.
I don’t feel this is on-topic for this site. Taking the discussion here is effectively leveraging Lobste.rs-as-Twitter, which ideally, it shouldn’t be.
Then you get it all to a point where you want to submit it upstream so
you can get help experimenting with this tool.
So you submit it to upstream in the experimental branch, expecting very
little pushback so you can get help tinkering with things.
If you read the whole thread, it is stated that the testing repo is not
a playground. Likewise, if you read the whole thread, the submitter
mentions that they did indeed expect serious pushback. This wasn’t a
case of “someone innocently did a little thing and ruffled a lot of
feathers”. They weren’t the least bit surprised by the response.
Is systemd playing politics when they’ve repeatedly rejected musl
patches?
The reactions in that thread are both disappointing and somewhat to be
expected. I don’t know why people have such a negative reaction to
systemd. It’s just an init system, not a religion.
Mission creep. I’m not a systemd fan myself, nor a staunch detractor.
I can appreciate it for what it is, and I don’t mind working with it
when I must.
For the record, I think a musl-based systemd distro is a very fine
idea. Maybe it could even start with Alpine as a base. I wish them
luck, because they’re probably going to end up maintaining a patchset to
make systemd run on musl.
If it is really that bad then the mantle
of responsibility is on you for coming up with a better option.
Many have. I myself use dinit
these days. Don’t lecture me about my mantle of responsibility to solve
a problem I have absolutely no reason to solve.
Comments like this have no place in open source contributions:
I agree one hundred percent, and so do others in that thread.
But over all I found your framing of the whole situation somewhat
disingenuous.
This is one of the most civil political debates that I have ever read.
In the entire thread, I saw only three comments that could be called offtopic or emotionally charged, and they were told to knock it off.
If this is problematic to you, you need to broaden your perspective. With an eye on the rest of the internet, that PR thread is a font of civility. If one day I have a popular software project, I should be eternally grateful if all its pull requests were debated in this manner!
If this discourages a newcomer, a word of advice to forestall disaster: echo 0.0.0.0 twitter.com | sudo tee -a /etc/hosts.
If this is problematic to you, you need to broaden your perspective. With an eye on the rest of the internet, that PR thread is a [front] of civility.
You may be misunderstanding. From what I can tell, the article is being marked as part of a flamewar. Whether it’s civil by Internet standards is secondary to Lobsters’s own guidelines.
This is one of the most civil political debates that I have ever read.
That’s great to hear, and I’m glad you’ve enjoyed your time reading the article. Nevertheless, I firmly hold that Lobsters should not serve as a site to link to or discuss such debates. Like the guidelines say, there are other sites for that.
I think the systemd team’s position is more defensible if you look at it top-down. Will spending resources on musl support do anything for the customers of the commercial distro vendors, or the end-users of those distros? Could it be justified to a non-technical manager or executive? Resources are always limited, and time spent on libc portability is time that can’t be spent on something else that might be more beneficial. I learned to take this view while I was on the Windows accessibility team at Microsoft. At the peak of our headcount, I naively thought we should be able to do everything we wanted to. But, like I said, resources are always limited, and tradeoffs have to be made.
I mean, a common criticism is that SystemD is a project driven by business concerns that does not play well with the existing ecosystem. And it sounds to me like you are saying “Yes, systemd does not play well with the existing ecosystem because the people working on it have to make decisions on the basis of business concerns.”
A primary reason that Linux is so open to experimentation is that the people working on it, at least in theory, are driven by the love of the craft and some level of principled thoughts about system design. The point of the UNIX philosophy (and yes I know Linux does not hew very closely to the UNIX philosophy, but there’s degrees–) is that a system assembled from independent components speaking an accessible interop language encourages, experimentation through composeability, readability and extensibility.
If Linux was designed the way that SystemD is designed, there would be a list of supported hardware and a paid certification program. Heck, it might even have more users that way! But I dare claim it would have fewer developers; at least, fewer unpaid developers. Its ecosystem would be vastly different, biased towards business rather than amateurs. It would be less welcoming to developers, even though it may be more welcoming to users. And I know that even now, most people working on Linux are paid to do so, but the ethos is amateur, and that’s a large part of what I like about it.
Also, yes systemd is developed primarily by people who work for a business. So what? That’s the best-case scenario of FLOSS–run a business while developing it. Or do you prefer it was developed by hackers part-time outside of work, school, and other jobs?
systemd does not play well with the existing ecosystem
systemd plays fine with the existing ecosystem. It even understands traditional config formats like crontab and fstab. It’s a reliable way to run a Linux box for users, developers, and sysadmins. That’s really all we need to know to see why it’s successful. No conspiracy theories needed.
That’s the best-case scenario of FLOSS–run a business while developing it. Or do you prefer it was developed by hackers part-time outside of work, school, and other jobs?
A non-profit org doesn’t guarantee anything in particular other than, the interests of its biggest funders will come first. If a powerful funder wants to control how a project is developed, they can just ‘acqui-hire’ its core developers. Look at Rust.
Note that Rust is not a 501(c)(3) non profit organization. It is a 501(c)(6) business league and does not pay its core team members.
Agree with you that non profits are vulnerable to high donation percentage from individual funders. However, non profit organizations have a crucial guarantee that for-profit entities do not: the flow of income must legally be pointed at the org’s mission statement, with none skimmed off the top. The org exists for the users, not for the financial stakeholders. Furthermore they are governed by a board, so when the founder retires, the org passes on to other board members rather than being sold and dying a painful corporate death at the expense of the users.
Nothing about this guarantees that the mission statement will remain unchanged, or that the software delivered will be fit for purpose, or that the rest of the board will be capable of maintaining it if the founder goes away. A for-profit business has one weird trick that really helps with all this: it’s in the business of selling that software, and if it’s no good, they go out of business i.e. lose their income source.
A primary reason that Linux is so open to experimentation
Given this thread, it doesn’t seem like this is true. Someone wants to experiment with this, and the entire community rejects it, even as an experiment.
…first of all, it’s not like musl is some shabby hobby project written by some hippie with way too much free time on their hands due to their questionable personal hygiene routine – it’s a pretty solid project, with a good maintenance history. Accepting patches that add support for an alternative piece of supporting infrastructure is not something that you’ll ever going to be able to justify to non-technical managers, especially when some of them are quite heavily invested in the other piece of infrastructure, the one that systemd already supports ;). That’s the road to technical stagnation, not pragmatic choices. At this rate, something better than glibc will have zero chance of ever showing up on Linux – and ten years down the line we’ll all be wondering why them young kids don’t even care about this crap anymore.
Also, more generally, copycating large corporate practices when developing software isn’t really conducive to quality software unless you have large corporate money to throw at it. If you try to write system software with Microsoft’s attitude but a small fraction of Microsoft’s money, all you get is a cheap clone of something Microsoft might make. (Edit: to clarify – this always has to be said when Linux is involved, for some reason… – I don’t mean “something Microsoft might make” in a derogatory manner. A lot of Microsoft’s NT software is frickin’ amazing, and light years ahead of anything comparable we have in FOSS land).
Second, this kind of “corporate gatekeeping” is one of the things that put a big nail in many Unix coffins back in the day. The idea that you can’t implement something that your users want because you’re unable to explain it to the people in charge is one of the things that made a lot of people move to systems that could do what they want – like Linux.
It’s also kind of undermining the whole point of using an open source program in the first place. If I wanted my choice of hardware and systems software to depend on the goodwill of some executives, I’d much rather bet on Microsoft’s.
Comparisons of systemd with illnesses and other rude comments aside, I think the maintainers of a project do have a right to reject the addition of the systemd package due to the potential far-reaching consequences, especially as most packages in Alpine’s repositories were built with the assumption that systemd will not be added:
there are quite a few packages in aports that use build flags like –disable-systemd-integration, –no-systemd, –without-systemd, -Dsystemd=disabled, and so on.
What happens when this is merged and folks want to enable systemd support in those packages?
Will there be foo (what exists today in aports) and foo-systemd (with the build flag removed) variants of each one?
I don’t have strong opinions about systemd, but Alpine was (in a way) designed with its exclusion in mind.
That said… yes, the juvenile anti-systemd comparisons are getting tiresome.
Just my two cents.
No, OpenRC is not that option. It can be PART OF an option, but it is not a competitor by
itself.
I recall that one of the Alpine maintainers was beginning work on a full-fledged alternative to systemd, both as a process supervisor and an init system. I can’t find it now, though. Ty Foxboron!
No, OpenRC is not that option. It can be PART OF an option, but it is not a competitor by itself.
That part was particularly illuminating because it shows the insistence on vendor density coming from the systemd community. They insist that all competitors have an intended scope on par with systemd’s, rather than relying on distros to provide value via integration of independently-developed components. They insist that systemd is a collection of independently-adoptable components and then when you want to swap out part of it for a competitor they point out that the competitor doesn’t have an analogous component for every other systemd component.
I recall that one of the Alpine maintainers was beginning work on a full-fledged alternative to systemd, both as a process supervisor and an init system.
You are talking about the s6 work done by Laurent Bercot, which was part of the discussion.
Figured I’d explain why I flagged as “troll” of all things. It’s not a statement on the author @cadey, nor even on systemd itself. I think discussing systemd is fine, but I don’t want flamewars started elsewhere to be adjudicated here on Lobsters.
On the nature of “flamewars”: Obviously there are well-intentioned parties involved, there’s no questioning that. Indeed, few flamewars are started for “no good reason”. But that’s just the problem. Once people start using charged language, it becomes hard to distinguish the healthy and unhealthy parts of the conversation. You need look no further than this thread to see Lobsters using the language of epidemiology to discuss other people and projects.
Again, I’m not trying to smear the author or the participants in general, or even the topic. But in my view, we should strive to have healthier discussions here on Lobsters.
I don’t think it’s useful for Lobsters to turn into the FOSS-drama-gossip site. There’s several Mastodons/Matrix rooms/IRC channels where folks can discuss these flamewars if they so choose.
for reasons that are not entirely clear
I don’t know why people have such a negative reaction to systemd. It’s just an init system, not a religion.
The issues people have had with SystemD during its adoption are exhaustively documented, as are the rebuttals to those issues. Implying that those reasons don’t exist or aren’t coherent comes from either a place of dishonesty or ignorance, and given the author’s expertise I doubt it’s the latter.
(To be clear: I’ve had nothing but reasonable experiences with systemd, and I think it totally is key to some cool tech trees like NixOS. I am happy to use it at work and at home projects, where it makes sense.
I also completely accept and empathize with folks that are concerned with its spread into things beyond init, and I especially empathize with folks who have a strong dislike for the politicking that contributed to that spread.)
Trying to shut down experimentation is how you get people to leave the community or give up participating in open source altogether.
For some cases this is a feature and not a bug, whether or not we agree with it. There’s a balance every project picks between embracing new developers and delivering reliable products, and if a group decides that maybe turning off people is an acceptable tradeoff in pursuit of that balance that’s fine.
It wouldn’t have become a good choice for so much of the Linux ecosystem without it having solid technical merits.
Linux (and tech in general) is chock full of projects that failed to succeed in spite of technical merits, as well as projects that succeeded in spite of real technical issues–PulseAudio being a great example (by some of the same folks that brought us systemd!). It is performative naiveté to suggest “oh gee well there’s no way it could’ve succeeded unless it was really that good”.
I am just some random person on a blog that got frustrated at the reactions to this contribution.
It is unbecoming, especially when doing things that look a bit like summoning an internet mob, to downplay one’s audience and reach.
~
C’mon @cadey, I expect better of somebody with your writing and talent.
EDIT: I agree very much with the part of your message I parse as “Folks, stop discouraging experimentation”, but I can’t abide the part that seems to dismiss people who have valid reasons or experiences that lead them to doing so.
The code will exist well after the people are dead; graveyards are full of valued contributors and beloved maintainers.
Less grimly: can you imagine the absurdity that would ensue were every project compelled to accept every contribution? What would be the impacts downstream, do you imagine?
It feels like going a bit against the grain here, but I agree with the article. It took until the very end of the thread to even get to some technical reasons for the package not being merged, everything in the lead up felt entirely like emotional reactions.
The thing about ends and means is that the means end up influencing the ends greatly. If you don’t want this MR to go ahead then the approach used might seem like a success, but there were many other approaches, a lot which would have been friendlier and led to a better outcome in terms of community and mutual respect between contributors and maintainers.
All the polemics aside, the actual thing that surprised me was this last comment. What the actual, proper, hell? Since when anyone gets to dictate how open source software is used?
I can understand “we won’t try to make systemd work with musl because there will be no support from upstream” but “we won’t try to make systemd work with musl because **upstream doesn’t want us to”? That’s just wild.
I’m not even a free software purist, I actually think that stuff like the kind of license Redis is doing to try to prevent AWS from eating their lunch is pretty valid, and when that whole discussion happened about maybe including clauses in open source licenses to prevent “evil” usages, I thought that was an interesting idea to at least discuss. But this is not that. There’s no economical or even ethical reasoning. It’s just “I think your tech is ugly and I don’t want you playing with my toys”.
Either don’t put your toys online, then, or shut up.
It’s not dictating. It’s giving a recommendation or uttering a preference.
This is quite common between us distro maintainers. If upstream tells us something is a bad idea we generally listen. This is what being a community is all about. This goes both ways as well, upstream listen to downstream maintainers around packaging and proper release management when they do weird stuff.
Maybe the person from the comment I linked is misrepresenting what systemd upstream said, but “this is not a good idea” is VERY different from “I don’t want you to do this”.
I don’t think that’s the most charitable interpretation of what the quoted bit means. Later in the paragraph you quoted, the author says:
Accusing a contributor of ignorance is inexcusable. Comments like this have no place in open source contributions:
SysTemD is the STD of operating systems. There is no “one little poke”, you can’t be a little bit pregnant.
That said, the repo’s owner already told the person who made the STD comment that they were out of line, and a lot of the other reactions were politely negative.
More broadly, I agree with several other people here that it’s not necessarily politics or unfair for developers to reject something someone wants.
Honestly, politics aside, this just seems like wasted effort. I don’t see it being feasible to maintain so many patches to get systemd to play nicely with musl, only for it to never really see the light of day since it can’t fit in with how existing packages in main and community are built (the “no systemd” flags) — simply put, it will never graduate out of testing.
You seem to be missing that the “contribution” mentioned in the article is the addition of a package to the ports tree, which the contributor would then be maintaining, not the Alpine developers.
The thing is that systemd is not just an init system, given it wants to cover a lot of areas and “seeps” into the userspace. There is understandably a big concern about this and not just one of political nature. Many have seen the problems the pulseaudio-monoculture has brought, which is a comparable case. This goes without saying that ALSA has its problems, but pulseaudio is very bloated and other programs do a much better job (sndio, pipewire (!)) that now have a lot of problems to gain more traction (and even outright have to camouflage as libpulse.so).
Runit, sinit, etc. have shown that you can rethink an init system without turning it into a monoculture.
In theory, having all (or at least most) Linux distros on a single audio subsystem seems like a good idea. Bugs should get fixed faster, compatibility should be better, it should be easier for developers to target the platform. But I also see a lot of negativity toward PulseAudio and people seem to feel “stuck” with it now.
So where’s the line between undesirable monoculture and undesirable fragmentation?
The Linux ecosystem is happy with some monocultures, the most obvious one is the Linux kernel. Debian has dropped support for other kernels entirely, most other distros never tried. Similarly, with a few exceptions such as Alpine, most are happy with the GNU libc and coreutils. The important thing is quality and long-term maintenance. PulseAudio was worse than some of the alternatives but was pushed on the ecosystem because Poettering’s employer wanted to control more of the stack. It’s now finally being replaced by PipeWire, which seems to be a much better design and implementation. Systemd followed the same path: an overengineered design, a poor implementation (seriously, who in the 2010s, thought that writing a huge pile of new C code to run in the TCB for your system was a good idea?) and, again, pushed because Poettering’s employer wanted to control more of the ecosystem. The fact that the problems it identifies with existing service management systems are real does not mean that it is a good solution, yet all technical criticism is overridden and discounted as coming from ‘haters’.
I really want to agree with you here, but looking back at 2010 what other choice did he realistically have? Now its easy, everyone will just shout rust, but according to Wikipedia, rust didn’t have its first release till June while systemd had its first release in March.
There were obviously other languages that were much safer than C/C++ around then but I can’t think of any that people would have been okay with. If he had picked D, for example, people would have flipped over the garbage collection. Using a language like python probably wasn’t a realistic option either. C was, and still is, ubiquitous just like he wanted systemd to be.
C++11 was a year away (though was mostly supported by clang and gcc in 2010), but honestly my choice for something like this would be 90% Lua, 10% modern C++. Use C++ to provide some useful abstractions over OS functionality (process creation, monitoring) and write everything else in Lua. Nothing in something like systemd is even remotely performance critical and so there’s no reason that it can’t be written in a fully garbage collected language. Lua coroutines are a great abstraction for writing a service monitor.
Rust wouldn’t even be on my radar for something like this. It’s a mixture of things that can’t be written in safe Rust (so C++ is a better option because the static analysis tools are better than they are for the unsafe dialect of Rust) and all of the bits that can could be written more easily in a GC’d language (and don’t need the performance of a systems language). I might have been tempted to use DukTape’s JavaScript interpreter instead of Lua but I’d have picked an interpreted, easily embedded, GC’d language (quickjs might be a better option than DukTape now but it wasn’t around back then).
Something tied aggressively to a single kernel and libc implementation (the maintainers won’t even accept patches for musl on Linux, let alone other operating systems) is a long way away from being ubiquitous.
In what optics are Pipewire any kind of improvement on the situation? It’s >gstreamer< being re-written by, checking notes, the same gstreamer developers - with the sole improvements over the previous design being the use of dma-buf as a primitive, with the same problems we have with dma-buf being worse than (at least) its IOS and Android counterparts. Poettering’s employers are the same as Wim Taymans. It is still vastly inferior to what DirectShow had with GraphEdit.
I’ve been using Linux sound since the bad old days of selecting IRQs with dipswitches. Anyone who says things are worse under PulseAudio is hilariously wrong. Sound today is so much better on Linux. It was a bumpy transition, but that was more than a decade ago. Let it go.
Mostly because of improvements to ALSA despite pulseaudio, not because of it.
Yep! Pulseaudio routinely forgot my sound card existed and made arbitrary un-requested changes to my volume. Uninstalling it was the single best choice I’ve made with the software on my laptop in the last half decade.
It’s no accident that PulseAudio and SystemD have the same vector, Poettering.
The word you’re looking for is “developer”, or “creator”. More friendlysock experiment, less name-calling, please :)
Was Poettering not largely responsible for the virulent spread of those technologies? If so, I think he qualifies as a vector. I stand by my original wording.
It’s definitely an interesting word choice. To quote Merriam-Webster: vector (noun), \ˈvek-tər,
To be frank, I mostly see RedHat’s power hunger at fault here. Mr. Poettering was merely an employee whose projects, who without doubt follow a certain ideology, fit into this monopolistic endeavour. No one is to blame for promoting their own projects, though, and many distributions quickly followed suit in adopting the RedHat technologies which we are now more or less stuck with.
Maybe we can settle on RedHat being the vector for this, because without their publicitly no one would’ve probably picked up any of Poettering’s projects in the large scale. To give just one argument for this, consider the fact that PulseAudio’s addition to Fedora (which is heavily funded by RedHat) at the end of 2007 coincides with Poettering’s latest-assumed start of employment at RedHat in 2008 (probably earlier), while Pulseaudio wasn’t given much attention beforehand.
Let’s not attack the person but discuss the idea though. We don’t need a strawman to deconstruct systemd/pulseaudio/avahi/etc., because they already offer way more than enough attack surface themselves. :)
This is why this topic shouldn’t be discussed on this site.
I don’t have an opinion on this specific systemd-related controversy but this blog post reads like projection to me. Politics is, among other things, a mechanism to convince others to share your values. The reason systemd triggers so many of these controversies is because it brings a different set of values to the organization of the system than existed in the past. Among these are speed over visibility, reactivity over predictability, and flexibility over experimentation. The decoupling that systemd tries to provide spreads the footprint of experimentation in a way that requires the experimenter to understand a broader swath of the integrated system versus what was usually just a specific point of invocation for the experimenter’s point of focus. So after a decade long campaign of systemd supporters convincing system integrators to share their values it is a bit ironic to say it is uncouth for others to attempt to do the same.
I don’t use systemd for speed, I use it because it’s more predictable.
That’s an interesting analysis, and it confirms my own biases: I want visibility more than speed, predictability more than reactions to other events. I think what you are calling flexibility, though, is actually feature-coverage: systemd attempts to answer all possible questions with a systemd-specific way to do things.
By flexibility I was referring to the loose coupling between units via their dependency targets. In theory it lets you sub in different software to provide specific services. I think it accomplishes that fairly well. The downside though is that the configuration is usually dispersed throughout a set of units that don’t have an inherent organization and almost require you to know how those units are wiring services together in order to have a good idea what to grep for.
Ah, the anti-DJB coupling method. I agree there, too.
Anti—Daniel J. Bernstein? Not sure I’m following you here.
I think they meant daemontools.
That’s the reference. DJB tends to put together a pipeline of executables that each have one set of related functions to perform. Rearranging or replacing them is a relatively easy process because they are all well-documented. As a result, people do – e.g. Bruce Guenter’s mailfilter front-ends and filters that feed into qmail.
Stop using your politics against systemd’s politics makes for a weak rant. I don’t have a strong technical opinion on systemd but the TINA (There is no alternative) “politics” of systemd has been annoying for… ever, hence the push against it and the work to keep a systemd-free alternative alive and viable.
Politics is, in a way, really about resource allocation. Maintainers of an open source project do have the right to make decisions about how their resources are allocated. If their reasoning is bad, you retain the right to fork, but throwing the dirty word “politics” on it is trying to use semantics as a cudgel to force other people to do things they don’t want to do with their limited resources.
I was on the fence, but decided to flag this as off-topic. I don’t think this passes the basic rules of thumb to be posted here.
All that said, the discussion on the merge request was offensive to me and so are some of the comments in here. I agree completely with this blog post that this was handled as poorly as possible if you want to inspire people into your community. People get way too worked up about this topic and it verges on conspiracy theory level at times.
I don’t feel this is on-topic for this site. Taking the discussion here is effectively leveraging Lobste.rs-as-Twitter, which ideally, it shouldn’t be.
If you read the whole thread, it is stated that the testing repo is not a playground. Likewise, if you read the whole thread, the submitter mentions that they did indeed expect serious pushback. This wasn’t a case of “someone innocently did a little thing and ruffled a lot of feathers”. They weren’t the least bit surprised by the response.
Is systemd playing politics when they’ve repeatedly rejected musl patches?
Mission creep. I’m not a systemd fan myself, nor a staunch detractor. I can appreciate it for what it is, and I don’t mind working with it when I must. For the record, I think a musl-based systemd distro is a very fine idea. Maybe it could even start with Alpine as a base. I wish them luck, because they’re probably going to end up maintaining a patchset to make systemd run on musl.
Many have. I myself use dinit these days. Don’t lecture me about my mantle of responsibility to solve a problem I have absolutely no reason to solve.
I agree one hundred percent, and so do others in that thread.
But over all I found your framing of the whole situation somewhat disingenuous.
This is one of the most civil political debates that I have ever read.
In the entire thread, I saw only three comments that could be called offtopic or emotionally charged, and they were told to knock it off.
If this is problematic to you, you need to broaden your perspective. With an eye on the rest of the internet, that PR thread is a font of civility. If one day I have a popular software project, I should be eternally grateful if all its pull requests were debated in this manner!
If this discourages a newcomer, a word of advice to forestall disaster:
echo 0.0.0.0 twitter.com | sudo tee -a /etc/hosts.You may be misunderstanding. From what I can tell, the article is being marked as part of a flamewar. Whether it’s civil by Internet standards is secondary to Lobsters’s own guidelines.
That’s great to hear, and I’m glad you’ve enjoyed your time reading the article. Nevertheless, I firmly hold that Lobsters should not serve as a site to link to or discuss such debates. Like the guidelines say, there are other sites for that.
TIL that systemd upstream refuses to make their software compatible with musl libc. Damn that’s shitty.
I think the systemd team’s position is more defensible if you look at it top-down. Will spending resources on musl support do anything for the customers of the commercial distro vendors, or the end-users of those distros? Could it be justified to a non-technical manager or executive? Resources are always limited, and time spent on libc portability is time that can’t be spent on something else that might be more beneficial. I learned to take this view while I was on the Windows accessibility team at Microsoft. At the peak of our headcount, I naively thought we should be able to do everything we wanted to. But, like I said, resources are always limited, and tradeoffs have to be made.
This is a defense of systemd that exactly matches its criticisms.
Sure, my logic also applies to distros that choose not to use systemd, like Alpine, and I have no problem with that. Or did you mean something else?
I mean, a common criticism is that SystemD is a project driven by business concerns that does not play well with the existing ecosystem. And it sounds to me like you are saying “Yes, systemd does not play well with the existing ecosystem because the people working on it have to make decisions on the basis of business concerns.”
A primary reason that Linux is so open to experimentation is that the people working on it, at least in theory, are driven by the love of the craft and some level of principled thoughts about system design. The point of the UNIX philosophy (and yes I know Linux does not hew very closely to the UNIX philosophy, but there’s degrees–) is that a system assembled from independent components speaking an accessible interop language encourages, experimentation through composeability, readability and extensibility.
If Linux was designed the way that SystemD is designed, there would be a list of supported hardware and a paid certification program. Heck, it might even have more users that way! But I dare claim it would have fewer developers; at least, fewer unpaid developers. Its ecosystem would be vastly different, biased towards business rather than amateurs. It would be less welcoming to developers, even though it may be more welcoming to users. And I know that even now, most people working on Linux are paid to do so, but the ethos is amateur, and that’s a large part of what I like about it.
IIt’s systemd, not SystemD.
Also, yes systemd is developed primarily by people who work for a business. So what? That’s the best-case scenario of FLOSS–run a business while developing it. Or do you prefer it was developed by hackers part-time outside of work, school, and other jobs?
systemd plays fine with the existing ecosystem. It even understands traditional config formats like crontab and fstab. It’s a reliable way to run a Linux box for users, developers, and sysadmins. That’s really all we need to know to see why it’s successful. No conspiracy theories needed.
Strong disagree. The best-case scenario for users is a non-profit organization such as Python Software Foundation or Zig Software Foundation.
A non-profit org doesn’t guarantee anything in particular other than, the interests of its biggest funders will come first. If a powerful funder wants to control how a project is developed, they can just ‘acqui-hire’ its core developers. Look at Rust.
Note that Rust is not a 501(c)(3) non profit organization. It is a 501(c)(6) business league and does not pay its core team members.
Agree with you that non profits are vulnerable to high donation percentage from individual funders. However, non profit organizations have a crucial guarantee that for-profit entities do not: the flow of income must legally be pointed at the org’s mission statement, with none skimmed off the top. The org exists for the users, not for the financial stakeholders. Furthermore they are governed by a board, so when the founder retires, the org passes on to other board members rather than being sold and dying a painful corporate death at the expense of the users.
Nothing about this guarantees that the mission statement will remain unchanged, or that the software delivered will be fit for purpose, or that the rest of the board will be capable of maintaining it if the founder goes away. A for-profit business has one weird trick that really helps with all this: it’s in the business of selling that software, and if it’s no good, they go out of business i.e. lose their income source.
Given this thread, it doesn’t seem like this is true. Someone wants to experiment with this, and the entire community rejects it, even as an experiment.
Not every experiment should be merged to the official project repos.
I get what you’re saying but…
…first of all, it’s not like musl is some shabby hobby project written by some hippie with way too much free time on their hands due to their questionable personal hygiene routine – it’s a pretty solid project, with a good maintenance history. Accepting patches that add support for an alternative piece of supporting infrastructure is not something that you’ll ever going to be able to justify to non-technical managers, especially when some of them are quite heavily invested in the other piece of infrastructure, the one that systemd already supports ;). That’s the road to technical stagnation, not pragmatic choices. At this rate, something better than glibc will have zero chance of ever showing up on Linux – and ten years down the line we’ll all be wondering why them young kids don’t even care about this crap anymore.
Also, more generally, copycating large corporate practices when developing software isn’t really conducive to quality software unless you have large corporate money to throw at it. If you try to write system software with Microsoft’s attitude but a small fraction of Microsoft’s money, all you get is a cheap clone of something Microsoft might make. (Edit: to clarify – this always has to be said when Linux is involved, for some reason… – I don’t mean “something Microsoft might make” in a derogatory manner. A lot of Microsoft’s NT software is frickin’ amazing, and light years ahead of anything comparable we have in FOSS land).
Second, this kind of “corporate gatekeeping” is one of the things that put a big nail in many Unix coffins back in the day. The idea that you can’t implement something that your users want because you’re unable to explain it to the people in charge is one of the things that made a lot of people move to systems that could do what they want – like Linux.
It’s also kind of undermining the whole point of using an open source program in the first place. If I wanted my choice of hardware and systems software to depend on the goodwill of some executives, I’d much rather bet on Microsoft’s.
Comparisons of systemd with illnesses and other rude comments aside, I think the maintainers of a project do have a right to reject the addition of the systemd package due to the potential far-reaching consequences, especially as most packages in Alpine’s repositories were built with the assumption that systemd will not be added:
I don’t have strong opinions about systemd, but Alpine was (in a way) designed with its exclusion in mind.
That said… yes, the juvenile anti-systemd comparisons are getting tiresome.
Just my two cents.
I recall that one of the Alpine maintainers was beginning work on a full-fledged alternative to systemd, both as a process supervisor and an init system.
I can’t find it now, though.Ty Foxboron!That part was particularly illuminating because it shows the insistence on vendor density coming from the systemd community. They insist that all competitors have an intended scope on par with systemd’s, rather than relying on distros to provide value via integration of independently-developed components. They insist that systemd is a collection of independently-adoptable components and then when you want to swap out part of it for a competitor they point out that the competitor doesn’t have an analogous component for every other systemd component.
You are talking about the s6 work done by Laurent Bercot, which was part of the discussion.
https://skarnet.com/projects/service-manager.html
Figured I’d explain why I flagged as “troll” of all things. It’s not a statement on the author @cadey, nor even on
systemditself. I think discussingsystemdis fine, but I don’t want flamewars started elsewhere to be adjudicated here on Lobsters.On the nature of “flamewars”: Obviously there are well-intentioned parties involved, there’s no questioning that. Indeed, few flamewars are started for “no good reason”. But that’s just the problem. Once people start using charged language, it becomes hard to distinguish the healthy and unhealthy parts of the conversation. You need look no further than this thread to see Lobsters using the language of epidemiology to discuss other people and projects.
Again, I’m not trying to smear the author or the participants in general, or even the topic. But in my view, we should strive to have healthier discussions here on Lobsters.
+1 (though I called it off-topic.)
I don’t think it’s useful for Lobsters to turn into the FOSS-drama-gossip site. There’s several Mastodons/Matrix rooms/IRC channels where folks can discuss these flamewars if they so choose.
The issues people have had with SystemD during its adoption are exhaustively documented, as are the rebuttals to those issues. Implying that those reasons don’t exist or aren’t coherent comes from either a place of dishonesty or ignorance, and given the author’s expertise I doubt it’s the latter.
(To be clear: I’ve had nothing but reasonable experiences with systemd, and I think it totally is key to some cool tech trees like NixOS. I am happy to use it at work and at home projects, where it makes sense.
I also completely accept and empathize with folks that are concerned with its spread into things beyond init, and I especially empathize with folks who have a strong dislike for the politicking that contributed to that spread.)
For some cases this is a feature and not a bug, whether or not we agree with it. There’s a balance every project picks between embracing new developers and delivering reliable products, and if a group decides that maybe turning off people is an acceptable tradeoff in pursuit of that balance that’s fine.
Linux (and tech in general) is chock full of projects that failed to succeed in spite of technical merits, as well as projects that succeeded in spite of real technical issues–PulseAudio being a great example (by some of the same folks that brought us systemd!). It is performative naiveté to suggest “oh gee well there’s no way it could’ve succeeded unless it was really that good”.
It is unbecoming, especially when doing things that look a bit like summoning an internet mob, to downplay one’s audience and reach.
~
C’mon @cadey, I expect better of somebody with your writing and talent.
EDIT: I agree very much with the part of your message I parse as “Folks, stop discouraging experimentation”, but I can’t abide the part that seems to dismiss people who have valid reasons or experiences that lead them to doing so.
I’m not sure it ever is. It seems to me that how we treat people is more important than defending technical purity.
The code will exist well after the people are dead; graveyards are full of valued contributors and beloved maintainers.
Less grimly: can you imagine the absurdity that would ensue were every project compelled to accept every contribution? What would be the impacts downstream, do you imagine?
It feels like going a bit against the grain here, but I agree with the article. It took until the very end of the thread to even get to some technical reasons for the package not being merged, everything in the lead up felt entirely like emotional reactions.
The thing about ends and means is that the means end up influencing the ends greatly. If you don’t want this MR to go ahead then the approach used might seem like a success, but there were many other approaches, a lot which would have been friendlier and led to a better outcome in terms of community and mutual respect between contributors and maintainers.
All the polemics aside, the actual thing that surprised me was this last comment. What the actual, proper, hell? Since when anyone gets to dictate how open source software is used?
I can understand “we won’t try to make systemd work with musl because there will be no support from upstream” but “we won’t try to make systemd work with musl because **upstream doesn’t want us to”? That’s just wild.
I’m not even a free software purist, I actually think that stuff like the kind of license Redis is doing to try to prevent AWS from eating their lunch is pretty valid, and when that whole discussion happened about maybe including clauses in open source licenses to prevent “evil” usages, I thought that was an interesting idea to at least discuss. But this is not that. There’s no economical or even ethical reasoning. It’s just “I think your tech is ugly and I don’t want you playing with my toys”.
Either don’t put your toys online, then, or shut up.
It’s not dictating. It’s giving a recommendation or uttering a preference.
This is quite common between us distro maintainers. If upstream tells us something is a bad idea we generally listen. This is what being a community is all about. This goes both ways as well, upstream listen to downstream maintainers around packaging and proper release management when they do weird stuff.
Maybe the person from the comment I linked is misrepresenting what systemd upstream said, but “this is not a good idea” is VERY different from “I don’t want you to do this”.
What is? That alpine contributors disagree with you?
I don’t think that’s the most charitable interpretation of what the quoted bit means. Later in the paragraph you quoted, the author says:
That said, the repo’s owner already told the person who made the STD comment that they were out of line, and a lot of the other reactions were politely negative.
More broadly, I agree with several other people here that it’s not necessarily politics or unfair for developers to reject something someone wants.
Honestly, politics aside, this just seems like wasted effort. I don’t see it being feasible to maintain so many patches to get systemd to play nicely with musl, only for it to never really see the light of day since it can’t fit in with how existing packages in
mainandcommunityare built (the “no systemd” flags) — simply put, it will never graduate out oftesting.If I would be a mainter, I would just say that I don’t have time to maintain this, please fork away… but then there will be no drama =)
You seem to be missing that the “contribution” mentioned in the article is the addition of a package to the ports tree, which the contributor would then be maintaining, not the Alpine developers.