That pipe wire can often meet or beat pro-audio JACK for latency is so elegant & nice. Defeating that compromise of PulseAudio seems like the crowning achievement to me; there's not a lot of other faults or defects I felt with PulseAudio, and I say this as someone who has had sound servers with half a dozen audio cards (mostly USB) I've run off a system, as someone who has streamed PulseAudio from one system to another.
The technical sophistication of PipeWire is almost purely made possible by Linux improving, by the availability of DMA-BUFs for shared memory inter-process work. This wasn't possible when PulseAudio (nee Polyp) was being created; the kernel couldn't do that then.
On top of this modern base, pipewire has done a fantastic job generalizing it's architecture. It's also designed to pipe video. It could conceivably be used to pipe input events, or other arbitrary streams too. This is a cool upgrade that I hope we see more leaning into over time; I hope PipeWire someday becomes so pervasively used for so many reasons that it is even more known, tapped, used, & loved that dbus, the current inter-process nexus of FreeDesktop.
> The technical sophistication of PipeWire is almost purely made possible by Linux improving
I'm not sure about that. I guess improvements in ALSA have contributed. But PipeWire was created by none other than the guy who rearchitected GStreamer's foundations after GStreamer had been brittle and prone to crashing for years. I don't think that there was a better person in the Linux ecosystem to do it. It's the second system effect without featuritis, like when some of the Unix people created Plan 9.
Personally, I was not happy with PulseAudio, and I'm very happy with PipeWire. Great, great stuff.
I say that as both a user and somebody who created a prototype for a sound system for an embedded platform on top of PulseAudio that was, AFAICT, abandoned because it just couldn't deliver some things. PipeWire was on the radar at the time but too much in its infancy to use back then. That stopped being the case years ago.
I love this paean, and I am delighted to assimilate this gleeful happy memetics into my own. But I think the hate sucks & can get lost. Maybe it's not hate, but I'm just so done, so fed up with intolerance and/or nattering against Lennart Poettering, and it all comes off as ridiculous to me. Whatever the qualms: Pulseaudio and systemd have been such vast giant leaps over where we were before. Most of the voices are just against. That is, they don't saying what else we ought have done, they dont speculate constructively. They're winges (thank you Ben Collins for re-introducing me to that word). It would be such a bleaker worse world without pulseaudio and without systemd. (I'm sorry to hear your product ran into such difficulty though!)
I absolutely am happy to hand a massive trophy to Wim Taymans for building a truly elegant API architecture. But I repeat again: the core of PipeWire would not have been possible without the better Linux we have today. PipeWire competes with JACK because of https://docs.pipewire.org/page_dma_buf.html . That's basically a fact.
Pipewire is a refinement of the idea, many of these lessons are hard won by pulseaudio itself, being used for years.
Linux audio before pulseaudio was just a lot worse, for many people pulseaudio meant not having to think about how audio worked any more.
Pulseaudio saved my bacon just the other day with virtualization - since the server runs on OSX I could pipe all the audio devices from an OSX host to a Linux guest.
I’ve had nothing but issues with PulseAudio, leading me to disable it and use plain ALSA (with dmix) on basically every Linux system I’ve used. I’m excited that it’s being replaced, but I no longer use desktop Linux very often.
I hope the pro audio side gets a bit more love. I've installed PW for the first time on my Ubuntu 22.04 (through https://pipewire-debian.github.io/pipewire-debian/) and so far have been experiencing high CPU usage on Bitwig Studio v5.0.11 when trying to send audio from and to my Native Instruments Komplete Audio 6, and I have no idea what the culprit might be.
I'm going to try a bunch of stuff and hopefully be able to take advantage of this wonderful technology (that has already come _so_ far!)
I should probably document my troubleshooting ventures. Does anyone know a nice hosted blog that supports Markdown / CommonMark and RSS syndication? Is Substack a good option?
I'm running Arch (not that it should matter) with the newest Bitwig without problems. I'm using a Behringer interface though. Additionally I have a Roland synth acting as another sound card. This also works with Pipewire/Bitwig at the same time as the main interface. I couldn't get it running with JACK before.
I'd start with checking all sinks/sources to make sure you're not resampling by accident. But even that shouldn't be causing high CPU by itself. There's pw-top/pw-profiler to help you.
Thanks for the pw-profiler recommendation, wasn't aware of that one.
I believe the Pro Audio profile [0] (which I'm using) doesn't resample by default.
Using pw-top, I noticed that something was causing xruns [1] (see ERR column) though I was unsure what that was. Since the Pro Audio profile uses the IRQ mechanism, I looked at interrupts [2] but couldn't spot anything unusual. There is however irq/16-mmc0 process which is at times causing significant (>50%) CPU usage, so I think I need to unload the sdcard module and see if that fixes anything.
First however I think I'll try a newer kernel (linux-lowlatency-hwe-22.04, which according to apt search is on 6.2.0.1017.17~22.04.14 as opposed to the current 5.15.0-89-lowlatency that ships with Ubuntu 22.04)
When reading posts like these, I sometimes I feel very lucky having a MacOS M1 setup that does what it's supposed to and which works almost seamlessly with external hardware. Best of luck to your venture.
I think that's skipping some context though. Don't know about the previous poster, but I'm using pipewire for things that MacOS just can't do, at latencies which MacOS can't pull off, with codecs that MacOS can't support. So although I spent an hour or so on the setup / resolving issues, that's still 100% better.
Yeah, the basic things just work on MacOS. But try to do fancy audio routing, low latency processing and other things and you're left with spending hundreds of dollars on apps that give you half a hacky solution.
I'm sure PipeWire is technically more advanced, but as someone that just wants to make music using a DAW by tracking external synthesizers, a _bit_ higher latency doesn't kill, especially if the DAW can compensate for said latencies.
It's nice to hear that PipeWire supports more codecs, but here WAV, FLAC and MP3 are more than sufficient for my needs (and the needs of 99% of producers out there)
At the end of the day when I'm inspired I simply want to make music instead of mucking around with config and troubleshooting. It might be that the Linux audio landscape will offer this at some point, but I don't see that happening any time soon.
> Yeah, the basic things just work on MacOS. But try to do fancy audio routing, low latency processing and other things and you're left with spending hundreds of dollars on apps that give you half a hacky solution.
This; and that also includes running macOS version a release, two or three behind, because the newer ones break your setup.
> This; and that also includes running macOS version a release, two or three behind, because the newer ones break your setup.
That's true, and it's a widely known wisdom, but in my case my Mac isn't even connected to the network: I'm using it just as an appliance solely dedicated for audio / video editing and production.
I also hope the "pro" audio side gets more love. I'm not an audio pro, but I do play music.
Long story short, I tried pipewire for a year, it was a wasted year. Realtime audio never worked, it was a mess of configurations that didn't fix anything. Went back to Jack, everything worked.
Was sad that I could have spent more time making music instead of messing with "the newest, greatest, and best" in the Linux world.
I ran into a bunch of issues with it on a headless userless system. Unfortunately, like pulse, it's deeply integrated with dbus/policykit/xdg stuff. Wireplumber was looking for XDG_HOME_DIR and breaking when it couldn't find one, dbus issues when doing things from root services, Jack clients couldn't connect, etc.
I'm prepared to like it better than pulse, and alsa has its warts, but I'm not 100% convinced yet.
I don’t have anything bad to say about PipeWire. It's really been a breath of fresh air. And, as much hate as it gets, so was PulseAudio when it came out. Good to see things moving forward.
I did have some Bluetooth issues that made my headset unusable if I was using a Bluetooth mouse at the same time, but that issue seems to have resolved itself a few weeks ago so now I don't have any complaints either.
I had issues with audio production, but not anymore. I think this "not anymore" is the key takeaway. It may or may not be ready for everyone right now but it keeps improving.
It "just works" in the default configuration on traditional hardware, where plugging the headphones in does not result in the need to move streams to a "different" sound card. I have slightly unusual hardware in the form of a Dell Inspiron 7415 laptop (with its internal microphone and the headset microphone presented as two separate SOF cards), and there are two trouble points:
* The external microphone level is not saved/restored across the reboot, making the other party complain that my voice is clipping
* The echo canceller configuration is static - once loaded, it does not react to the headset plug/unplug events and always uses the same microphone.
I was using JACK and tried switching to PW at various points and always encountered issues.
Last year I took another chance and made a fresh Arch install on my laptop and went with PW (on previous attempts I tried to switch on an already running system). I had no issues, and in fact it solved some issues I used to have on jack.
Then I did the same on my desktop. I had problems setting up my microphone, but I managed to solve it. Now I have two, very minor issues: sometimes bitwig takes a bit to start the audio engine, or I have to restart the program; and sometimes my audio stops working when I unplug my zoom h1n while the system is running. I rarely do the latter so it's barely an issue.
There are patchbays for PipeWire that allow for wiring like jack. qpwgraph seems to be the most functional. Can use pw-cli too.
Actually it allows wiring also jack applications to pipewire applications and pipewire to jack. I use e.g. "pw-jack ardour" to run ardour and launch pw-jack jconvolver and route inputs and outputs with qpwgraph.
I'm currently in the process of setting up pipewire in an audio engineering setting. Currently in the process of latency tuning, hovering around 9ms right now, would love to cut that in half.
I'm using ardour (after the creator recommended I try it in another HN thread) on Debian with a realtime kernel for a 16 in by 8 out interface for eventual use as a FOH mixing console.
After lots of tweaking, I haven't seen much improvement over the default pipewire-jack config, but I've only recently started tackling realtime priorities and modifying pipewire metadata for interfaces.
In my experience pipewire didn't work for me but Jack did.
> It had a steep learning curve and a lot of configuration
Yeah I experienced that with Jack too. I spent even more time trying to learn and configure Pipewire, much longer than I ever did with Jack, all to give up and go back to Jack.
Had my bacon saved using a pulseaudio server on OSX for VM guest running Linux, but if worried that won't be possible in future if pulseaudio goes away and PW remains Linux only.
Off-topic posts are fine when they're whimsical, but it's definitely not fine to jump ship to a classic-flamewar-topic. That's like getting sucked into the gravitational field of the nearest hell.
I don't know anything about that situation—I've never personally looked into it. All I know is that we need you to follow the site guidelines when commenting here, no matter how right you are (or feel you are) about the situation.
It's quite sad that one person can get this level of hate online just for releasing open source software.
If you don't like his software why are you using it? If it's because your distro uses it shouldn't you try to be convincing them to switch to your preferred alternative, instead of calling out the developer by name on public forums?
TBF Poettering was working for RedHat when doing pulseaudio and systemd. Without RedHat they probably wouldn't have been so widely adopted.
I didn't mind PulseAudio that much. Linux audio was a mess way before PA and PA at least works quite well for basic desktop sound. PipeWire works better and works also for DAW usage.
Systemd OTOH makes almost all possible sins against the unix philosophy and it being so fundamental piece, it leaks the anti-unix all over. RedHat pushed it so deeply e.g. in Gnome that everybody eventually had to adopt it.
> Systemd OTOH makes almost all possible sins against the unix philosophy
Is this supposed to be a bad thing? Because I don't find it obvious. In fact, I don't get why many people have this mystical reverence for the "unix philosophy", as if having a large number of small processes that communicate via plain text was some kind of divine commandment rather than just one of many ways to design software (and not necessarily that good for tasks other than slicing and dicing text). I'm guessing that you do your image editing in a program like GIMP or Photoshop rather than with a bash shell, pipes, and a hundred tiny programs that input and output text. The "unix philosophy" simply isn't a good fit there. Having used both sysvinit and systemd when doing server administration, I find systemd so much better that to me, it's evidence that maybe the "unix philosophy" isn't the best choice here either.
The core idea is "do one thing and do it well". Implicated here is that these tools should have interoperable interfaces. These are very basic principles for good design in any programming.
Unix implementation of this is cli programs, streams and files.
The systemd ideology, and in general declarative or pointy-clicky-ad-hoc like in Windoes and MacOS, dumb down computers into appliancies. I don't want my computer, especially the very core of the userspace, to be an appliance.
For most image editing I use bash and imagemagic. I guess you e.g. resize a batch of images by repeating the same clicky-click routine for each image?
Clicky-click has it's uses, but e.g. in Blender I much rather use nodes instead of having thousands of buttons for all connection permutations. Nodes are quite unixy in their UI philosophy.
Shells and sysvinit sure have their problems as the implementation. But at least they let me use my system as a general purpose computer. I'd love a modern and retought implementation of the unix philosophy.
The historical "unix philosophy" was specifically about small programs communicating over pipes via plain text. If you retroactively change it to "do one thing and do it well", then it becomes a meaningless truism. "One thing" is so vague that you could argue Photoshop does one thing too; every large piece of software uses some kind of modularity; and who would deliberately write a program to do its job badly? The devil is always in the details that such cliches don't help us decide: how broad should our definition of "one thing" be, what should be the unit of modularity (processes, classes, Python modules?), what is the communication interface between the modules.
In the case of systemd, it's an umbrella project maintaining a bunch of medium-size C programs that communicate mostly over D-Bus, in ways that are extensively documented on systemd's website. I find it to be a big improvement in interoperability. Before systemd, most distros used the "simple" sysvinit in theory, but in practice sysvinit was so lacking in features and such a pain in the ass to program for that each distro usually shipped a bunch of helpers glued together with shell and Perl. So you would have to write distro-specific stuff, based on documentation that was less abundant than systemd's. That wasn't very good for interoperability.
Can you elaborate on how systemd doesn't let you use your system as a general purpose computer? Because that sounds ridiculous on the surface. There are several ways in which systemd is more general and hackable than sysvinit, for example having targets instead of runlevels. And in practice, after the introduction of systemd I've only found it easier to look into things on my system and tinker with it. journalctl's log formatting and filtering is a very useful addition to grepping when you need to investigate a problem quickly, and systemd user services have made it trivial for me to run my short Python scripts as full-featured daemons that write to my system's log and can be monitored.
Figuring what is "the one thing" is the art. It's like factoring code in separate functions that work well together and with others. There are no strict rules, criteria or methods to attain it.
Small programs communicating over pipes via plain text was/is the implementation. The philosophy is more general [1]. This one is more or less how I think of it:
"Even though the UNIX system introduces a number of innovative programs and techniques, no single program or idea makes it work well. Instead, what makes it effective is the approach to programming, a philosophy of using the computer. Although that philosophy can't be written down in a single sentence, at its heart is the idea that the power of a system comes more from the relationships among programs than from the programs themselves. Many UNIX programs do quite trivial things in isolation, but, combined with other programs, become general and useful tools."
"Medium sized" (systemd alone is around a million lines) C-programs are extremely difficult to debug or modify if you're not intimately familiar with the codebase. The code in them can't typically be used for any other purposes. Sysvinit as a program is very small, but the point is the protocol that allows multiple different kinds of programs to co-operate. Being able to glue things together with shell and Perl is a feature, not a bug.
Journalctl is a good example of violating the UNIX philosophy. It contains its own binary format, its own grep, its own head and tail, etc. With /var/log files you don't have separate cat, grep or tail to examine files and directory listings. That is the UNIX point. And this is what I mean by general purpose.
sysvinit had/has plenty of problems and systemd typically works better at least nowadays. I'm not singing any praises of sysvinit. But e.g. OpenRC manages initing without a million lines of code and taking control of more or less the whole OS.
This is just motte-and-bailey. You're shifting the definition of the "unix philosophy" between the general idea of interoperability, and the UNIX design of small programs that communicate via text and are glued together with the shell and pipes. The argument doesn't work if you actually use a consistent definition: the former is an obviously good thing but also an area where systemd scores well, and the latter isn't necessarily a good idea when you're doing something other than ad-hoc text manipulation.
I honestly don't understand why people want to do all these rhetorical backflips in order to maintain some kind of bizarre religious reverence for the "unix philosophy". UNIX's design was quite mediocre, it only looks brilliant when compared to the DOS lineage.
How about you make an actual technical criticism of systemd instead of hiding behind vague generalities? In particular, why is it bad that all the functionality needed to manage and monitor daemons is in one program? How would you split it into several programs in a way that maintains systemd's robustness for administrators and convenience for developers? What would be the practical benefits of this split to the users and developers (no "philosophies" please)? Can you justify that this proposed split would reduce systemic complexity (the complexity of the whole system) instead of actually increasing it by just shifting responsibilities onto daemon developers?
> The systemd ideology, ... , dumb down computers into appliancies.
> Shells and sysvinit sure have their problems as the implementation. But at least they let me use my system as a general purpose computer.
Why are you sure, you're perceived limitations of systemd compared to sysvinit are based on systemd's shortcommings instead of yours? I don't want to attack you personally, but I've had this conversation lot's of times before. Most of the time, people just had no clue how systemd works. In my experience it simplified lots of use-cases. And I have yet to find a use-case that was possible with sysvinit, but is not with systemd.
I have some clue how systemd works and manage to configure it to run the services I need. But to be frank, I'm quite clueless as to what most of its million LoCs do. I'm quite sure there's not more than a handful of people who do. Sysvinit did so little that it's almost trivial to understand.
It has simplified lots of use cases but my criticism is that it focuses too much on these cases and makes other use cases more difficult. It makes the system quite opaque to the user, a bit like Windows or MacOS that become almost impossible to fix when they break.
> Sysvinit did so little that it's almost trivial to understand.
This is only an advantage if you take an extremely short-sighted view of complexity. Yes, sysvinit itself is very simple, but by that metric you may just as well replace the init with a single exec to a user or distro-provided program. That would be even simpler, right?
Well, not if you think about systemic complexity rather than just the complexity of that one program. A modern Linux system will include the monitoring of daemons, auto-restart, parallelized dependency-based boot, and so on. A lot of people also want features such as starting a daemon only when a connection arrives or a device is plugged in, or automatically redirecting a program's output to the system log. This stuff is inherently complex, and that complexity has to go somewhere. sysvinit just says "not my problem", so every distro needed to ship lots of scripts to do these things. Every program that wanted to act as a daemon had to do a whole dance of double fork, setsid, environment variable sanitization, umask, managing a pidfile, etc. You'd have this error-prone logic repeated dozens of times in your system, in different programs, often written by people who aren't Linux experts. That's not systemic simplicity. systemd takes all of this complexity onto itself, and centralizes it into one place that is written by Linux experts. This lets many other programs be simpler.
> Makes other use cases more difficult. It makes the system quite opaque to the user, a bit like Windows or MacOS that become almost impossible to fix when they break.
What use cases does it make difficult? How does it make things impossible to fix? Please give specifics, because my experience has been the opposite. When something breaks in a systemd system, I usually find good clues in the system journal and the fix can be a simple configuration change after googling the problem. It's a breath of fresh air compared to having to trace the workings of a hairball of distro-specific shell scripts.
cli programs are not interoperable. Binary streams are not an interface, it's the lack of one. I can't goddamn pipe the CPU temperature into my display manager's status bar without 3 different tools unmaintainable, easy-to-break invocations, that will break from something as innocuous as changing the locale. It's as much of an interface as randomly reading into the memory of another process.
That you can do it with 3 different tools means that they are interoperable. That you can do this without hacking into some huge codebase or waiting someone to implement this specific feature.
/sys/class/thermal/thermal_zone0/temp gives you the temperature in ASCII. It's about as simple and interoperable as an interface gets. I like that I can check it in terminal with cat /sys/class/thermal/thermal_zone0/temp when needed. I really like that I can check a remote computer's CPU temperature by doing ssh some.remote.host -C cat /sys/class/thermal/thermal_zone0/temp. If you have the commands to show that in your status bar, you can easily extend a local one to a remote one. You prefer to wait for remotehosttemperaturetostatusbarctl to appear in the AppStore? Or write and debug thousand lines of dbus juggling in C?
I do agree that cli programs should be more interoperable in general. E.g. have more structured inputs and outputs akin to JSON or something, conform better to e.g. the GNU command line parameter spec and read stdin and write stdout and log to stderr by default.
Lennart's behavior in that talk does seem obnoxious, but the speaker also seems to be on-board with the adversarial banter, as well as there being acknowledgement of it being somewhat of a discussion-oriented format. Was that the way talks were playing out in general in that room?
I'm afraid that comes off like "If the speaker let it happen it's okay," which just rewards pushiness.
As I understand it, conference talks deliver their message first, THEN have a Q&A at the end where details can get sussed out or corrections issued. Lennart's time to complain or correct was after the talk.
I've been to talks where the format is deliberately more conversational. Lennart's raising that point when questioned specifically made me wonder if the room was already such an environment that day.
Many (or even most) of the issues with pulseaudio were actually sound driver bugs only being resurfaces by pulseaudio, as it was using them in a more complicated matter. It is pretty unfair to blame Poettering over anything wrong in your life, as many of you do, for some reasonx
Pipewire fixed my longstanding trouble with getting Bluetooth headphones to connect, same kernel/drivers under which pulseaudio was hopeless. I spent an hour power cycling my headphones and turning bluetooth on and off, restarting pulseaudio, fucking around with bluetoothctl, with the headphones connecting to bluetooth but not getting listed in pulseaudio... The usual nonsense except this final time my frustration overcame the activation energy to try something completely new so I installed Pipewire. It immediately worked and hasn't broken since.
Basically what I'm saying is that pulseaudio has serious issues even with new "fixed" drivers and distros switching to Pipewire is making the situation much better for many users.
To be clear, these were bluetooth headphones which would sometimes work with pulseaudio but it was a coinflip whether they would work properly or jerk me around for an hour. On paper it all should have worked, but pulseaudio just isn't reliable.
These were only true of pulseaudio in the early days of it. They are solved for good, by “simply” fixing the most common drivers. But in general, it couldn’t have been solved any other way.
Unlike PulseAudio, dbus, and other userland components, it is perfectly possible to have a Linux system which works with most software without systemd. runit and OpenRC are two of the most popular init alternatives, which are just inits, and nothing else, unlike systemd. You might argue you have to use logind and udev, but that has been spun off into elogind and eudev. There is also seatd as an alternative to elogind, which is quite big itself.
Just use it? I am still confused why systemd is supposedly something that needs to be fixed. Like all major distributions "accidentally" switched to it.
These takes are just ridiculous. Debian, with a more democratic system than any country on Earth, voted twice over the issue, overwhelmingly supporting the support of only systemd. How is that commercial interest? Then arch decided for the same thing independently. I’m sure arch linux is the core interest of every commercial vendor, right?
Just accept it, package maintainers had enough of the absolute shitty state of init systems. Systemd solves this very complex problem elegantly, giving some standard userspace can depend on.
The decision in Debian didn't come that easily. The tech committee was locked in a filibuster over systemd for ages and the votes were 50-50. Then the chair cast his tie-breaker vote in favor of systemd and everyone on the other side flipped their shit.
That's quite true I'll give you that. But there are still issues with it. It keeps swallowing up bits like resolver and others. It should only do one thing well.
Systemd adherents cannot seem to get past this deficiency in the software's messaging.
Same with Wayland. "it's not a program it's a protocol"
Still sucks, still is a thorn in my side and gets in the way.
Systemd is an attempt to consolidate the OS/service layer into one thing. Compilation options don't mean shit when every component is tightly coupled to systemd, its journal, dbus, or some other quackery.
Systemd would have been better as an entire distro to itself.
But as usual, people cannot handle the idea of running anything other than what's shoved in their faces from corporate programmers.
If I wanted corporate software I'd buy Apple or Microsoft.
Your terms are impossible to meet. The moment I reach one goal, you'll invent another. Not worth it my dude.
I am doing something about it by researching ways to excise Red Hat from as much of the tech stack as possible. Can't do much about the kernel, but every layer above it is moldable.
I don't care to provide 'usefulness' to you; if you're not paying me why would I give up any value?
It was an arrogantly managed project using the guise of standardization to bypass people's social tendencies. People are stupid, so they fell for the 'only consider the code, not our social fuckery!' Hook, link, and sinker.
It really opened my eyes to how ignorant and passive a lot of techies actually are. They're happy to slurp up whatever's advertised to them as the better thing.
Systemd runs my current laptop and I hate having to dive under the hood for anything. In a sysvinit, runit, or OpenRC system, I can achieve things quickly and don't need a book's worth of corporate style documentation to operate my damn system.
Systemd still doesn't support a one-time script on boot. You have to hack together a unit for that. Most other systems just run an rc.local script in /etc!
Binary logs are only useful if systemd is running, and only that version of it too!
Good luck understanding journalctl output. It doesn't capture everything.
Long story short, systemd has not improved a single area of my computing life. I guess I can ogle at a boot time graph. But the main goal seems to be for systemd to take away knowledge of the lower levels of the stack.
Like it or not, open software ecosystems are resistant to standardization by default.
Systemd and dbus and friends would not have bothered me if they weren't coupled with weird ideology about One True Linux or other crap.
Systemd never solved problems for me. I'm sure it solves many business problems but none of them apply to me.
I think systemd was developed to make a libre replacement for SMF, that supported socket-based activation and deterministic boot. Those were two of the project's original goals, but the endgoal I think was to develop this capability for open source Red Hat, SuSE and friends, get it on every distro, then use their influence at lower levels of the stack -- only one higher than the kernel itself! -- to have effective control over the open source ecosystem at a low level.
Poettering worked for Red Hat during the development of both PulseAudio and systemd. If he was not writing code they wanted, he would have worked on another project. Ergo, one can conclude those projects to be Red Hat-oriented, or sponsored at minimum.
I firmly believe the profit motive in the software world is what leads to dark patterns, user-hostile design, and other maladies we face in the modern software world. Their obligation to seek profit over all other things leads to compromised values, leading to compromised software.
I like what Benno Rice said[1] concerning a third "system" layer other than kernel and userspace. Systemd tries to fill that space entirely by providing a suite of tools that integrate well with another. But you are not forced to use these all of these, you're not forced to use resolved over resolvconf.
> It should only do one thing well.
I know this is a popular principle that some believe to be part of the unix philosophy. But an OS should also be coherent. Some tools can do their own thing and be independent from the rest of the system. But I think this works best for simple userland tools, not tightly integrated system services.
I don't like its hard dependencies on glibc (specifically, with no support for other libc's) and dbus (I'd've preferred Poettering going full nih and developing his own RPC protocol).
Other than that, systemd provides a polished experience, so if you want to displace it you'll have to produce something equally polished and compatible with existing unit files, just as systemd was able to consume ye olde sysv startup scripts.
The only other contender that I'm aware of that isn't just one massive design flaw, is openrc, and it's somewhat inferior to systemd.
Just a side note, but it's hard to take you seriously when you resort to such childish name calling. I think your chance of convicting traders (me included) would be much higher if you used some technical arguments instead.
