PulseAudio and Systemd Creator, Lennart Poettering, Reportedly Leaves Red Hat

Forgot to mention the best part - as far as I could tell, the package maintainer basically was upstream at the time. (I think both might have been maintained by Poettering himself, but it was a long time ago.) So in order for patches not to make it upstream the same person had to decide that it was important enough to diverge from the upstream release but not important enough to fix for everyone else. Oh, and one of the times I ran into this involved a seemingly really easy to reproduce crash (at startup, if I recall correctly) in a released upstream version...

Gnome depends on it, so that would be challenging. These days I just use alpine for servers where I can.

>I can point to multiple specific instances where gnome developers were rude, unhelpful, arrogant, etc

I too can point to multiple specific instances where Linux developers were rude, or where gcc developers were rude, or where SDL developers were rude, or where a lot of other developers were rude. I bet someone could dig through your comment history and find instances where you were rude and unhelpful too, probably even more if you shared any comments from when you were a young teenager. I hope you can see that it is completely ridiculous (and somewhat creepy) for someone to do that to you. Open source programmers just disagree sometimes, and sometimes they have a bad day and aren't totally professional about it, and in larger projects it is a lot more visible than on smaller ones. All you can ask of them is for an apology and then move on. It is unreasonable to expect anything else or to keep harping on this years after the fact.

Also it is completely ridiculous that this thread is getting derailed again into complaints about missing features in GNOME. Lennart isn't a GNOME contributor, I don't think he has written any significant code for GNOME at all. The fact that nonsense conflation is being used should be a "snap back to reality" moment. Just don't do it. This always seems to happen and it's always from the same suspects trying to revive the same old >=10 year old forum threads. Please give it a rest and try to do something positive instead, don't let the lwn trolls get inside your head. You are generalizing an entire group of people based on some cherry picked interactions that both of us likely lack the context to fully understand, unless you were "behind the curtain" like the parent comment actually was. If you weren't, then it is just another tone policing comment from the peanut gallery, the kind you probably would find to be bad if they were made from random users on your projects.

>At some point I suppose I'll get around to documenting the times gnome developers were publicly assholes to other open source contributors, but honestly I'd rather let it go and just ignore the whole project as much as I'm able to.

Letting it go is probably the right choice. If you want to revisit it, I have a suggestion: why don't you go through and publicly document all the times they did something right or the times they were nice to people, and then praise them for that and encourage them to do more of that. Surely you understand that it is not useful to keep beating a horse that died long ago. Just focus on the positive, if the worst thing they did is send some slightly unprofessional email 5-10 years ago (as if most open source developers in the 1990s-2000s didn't do that at some point, I think I lost count of the number of flamewars I read from that period) then it really should not be hard to find some examples of good.

This is factually false in my case since ALSA alone has always been fine, no issues. And since I switched (with the same hardware) pipewire also works just fine. But pulseaudio (pa+alsa ofc) is just simply broken on my archlinux install.

EDIT: also when pulseaudio breaks you just do `pulseaudio --kill ; pulseaudio --start` Does this really reset the hardware/firmware? I doubt it; it's just configured poorly for my hardware why is that hard to believe?

Putting this in a separate comment thread to avoid filling up the other one. I have some extra time so I read your blog post and wrote some comments. There is very little in there that is any kind of actionable issue.

>Sure, you can pipe journalctl into grep, but what if you want to use inotify, or tail a log, or expose logs over a network share? Well you have to learn the systemd-specific solution, instead of just using the tools that work with every other file.

This is absolutely not different from any other tools to manage structured data, like any database. I don't see anyone complaining that postgresql doesn't follow the unix philosophy. Logs are actually structured data, any adherence to a philosophy cannot change that fact. Actually a lot of those "standard" unix tools specifically exist to parse unstructured data into structured data, so from that perspective, having the format already in a structured data format is only there to save you some typing.

>I could complain about service files being spread all over the file tree, instead of in one central obvious place, but as I understand it systemd has some reason why that's better for them and that's fine.

The reason is straightforward. /run/ is for temporary services. /lib/ is for immutable service files shipped by the OS or by programs. /etc/ is for service files defined by admin configuration. /home/ is for service files defined by user configuration. This is all standard filesystem stuff that systemd is following. Actually, it is the old-style inits that break convention by putting everything in /etc, causing bugs in the process. The package manager should not install files to this folder that are not intended to be modified, doing so is sure to cause things to break whenever you upgrade a package. What seems like a "simple" solution in this case is actually too simple to the point of being broken.

>Unfortunatly the built-in OS image was not running systemd, and the kernal was several revisions out of date. While I had no problem getting a debian chroot running, all of the services were designed to run under systemd, this made the whole project much more of a pain in the ass than it should have been.

Well I don't see what this has to do with systemd, this would happen if you want to use any program or driver that depends on a new kernel version. Systemd cannot really do anything to solve the fragmentation caused by embedded devices running ancient kernel versions, that is very much a Linux-as-a-whole problem.

>I took the boot media out for trouble shooting, but when I systemd-nspawned into the host to try to address the problem, I discovered that journalctl would segault. Thankfully /var/log still had all the entries I needed to fix the problem. This appeared to be a general issue with running journalctl using qemu-static and binfmt.

A segfault sounds like an actual unintended bug that should be reported.

>By default systemd will kill long-running processes when I log out. Processes like screen or tmux.

Nit pick: this is not systemd doing this, but logind.

>The intentional and willful breaking of screen and tmux was to fix a GNOME bug of GNOME not closing up as it should when the user logs out

No, this is extremely wrong. GNOME cannot actually do anything about this, if a random nohup processes decides it is going to try to keep itself open.

>There's now no way to, by default, keep a program running in the background without a live ssh session.

The default is a flag in the config file that distros get to decide. There is nothing else they can do to accommodate you here, besides do what they already have done.

>For some reason my mother's computer can no longer resolve DNS. Ripping out systemd-resolved seemes to have fixed it, but note before I lost a few more hours.

>I used to think the systemd hate was silly... until I tried to get a VPN running and realized that all my DNS requests were going through a mysterious local DNS server

Unclear what is going on here without additional info. Copying more random comments that say vague things like "it doesn't work" is not really useful or meaningful to anyone. You could fill an entire book of comments like that made about everything in Linux over the years. It might be humorous, or interesting for historical purposes, but it won't help get any outstanding issues fixed.