> Why is the solution more complex than the problem domain?

So, where's your solution? If it's so simple, where is your contribution?

The fact is, he did it. You haven't. I can't even begin to imagine how much crap Lennart gets everyday by people who think they know everything and yet never actually seem to write any code.

Have some respect for the guy even if you disagree with the way he works, because you know.. his code is being used.

openrc, runit, s6, upstart*

dmix, jack, pipewire

* now maintained at https://gitlab.com/chinstrap/startup

I mean, if anything your list proves my point. They're not used at all. Also, I was asking parent for his implementation - I'm assuming he hasn't written any actual code though.

> I was asking parent for his implementation

This is not a valid argument, invalidating discussion of merit of thing based on not having personally created incarnation of said thing would remove 99% of debate of FOSS to no ones benefit.

Jack is actually really useful for music production, far superior to pulse audio, so yeah, people do use those programs.

My only problem with Jack is that Firefox (and Chrome too, afaik) absolutely insists on using Pulse, so you have to make both play nice if you want to use Youtube while working on music (which is actually pretty common). This can be a bit of a pain (funny things happen after suspend/resume). Still it's so useful for music/sound production, I put up with it :-)

Yeah I can relate to that, I start jack with qjackctl and run this post startup script "a2jmidid -e & pacmd set-default-sink jack_out "

Fair point, I didn't know that.

Being popular doesn't make you right.

Jack does not overlap with PulseAudio. Pipewire does, but it came later and has the explicit purpose of unifying Jack and PulseAudio.

Upstart is decidedly inferior to systemd; the event-based architecture is much harder to understand and apply than the target/dependency architecture of systemd. And systemd is in use in distros ranging from embedded (LibreELEC) to enterprise server, it must be doing _something_ right...

Regarding the event driven architecture: it is far easier to understand than systemd's dependency system. But it is indeed more difficult to apply, particularly because it is a departure from how most systems work currently and in the sysvinit past.

I enjoy the architecture, and hope to continue developing Upstart/startup or at least work with a similar model.

And yet none of those init systems are really being used in any significant way. It doesn't detract from them, but then they don't detract from systemd.

> All so I can seamlessly play music on TWO bluetooth speakers while also browsing logs without learning regex.

Are you suggesting that the alternative is to choose to just not support these features at all? (Which isn't implausible as a suggestion; OpenBSD doesn't support Bluetooth at all, for example. But in an ecosystem where everyone is building software to scratch their own itch, and then adopting the software that gains traction...)

I do not know about the person you are responding to, but I particularly take issue with how PA abstracts the hardware and does not allow low latency applications or servers such as Ardour, JACK, or other professional audio recording software to access it in an efficient manner.

So you end up with this weird situation where pulseaudio reroutes itself when JACK appears and no longer takes control of the sound card.

Why do we need to support two sound servers to take care of all the necessary features? I really hope pipewire fixes this use case and allows pro audio applications to work directly on top of pipewire while still supporting consumer friendly use cases like bluetooth speakers.

Just how loudly do you think people would complain if PulseAudio decided to link in JACK and replace it, instead of getting out of the way (and becoming a JACK client itself, I believe).

If PA was actually capable of half of what JACK does, they would be fine with it. These people just needs to record music without latency. But PA does not do what they need, so they would indeed complain.

I think what zlynx is saying is that even if PulseAudio emulated JACK, and did 100% of what people use in JACK, exactly as well or better than JACK did it, people would find something to complain about. Maybe they'd complain that PulseAudio is "bloated", or that this is yet another Poettering monolith.

FWIW I've been able to get similar input latency with PulseAudio as with JACK, that's not so much the issue as synchronization. If PulseAudio introduced a timecode like JACK, that'd probably be close to enough.

If you were really just going for minimum latency, your recording application would use ALSA directly.

Another use case for me is that I can more easily route audio from sources and applications to other applications, using JACK (and Patchage as a GUI).

This is not too difficult in PulseAudio. Every output has a "monitor" which can be routed to any application that's recording. You can do this through a GUI called pavucontrol, though it's not as pretty or flexible-looking as patchage or many of the other JACK patchbays. PulseAudio is, of course, more geared toward consumer and basic professional scenarios in general. Synchronization becomes important once you're routing through a couple of different applications.

> [...] aren't UNIX applications

What kind of argument is that - so what?

All major Linux distributions are doing very well with systemd and it makes sense to have some kind of supervizor service (or collection of tools) on top of `init`. You can still tie together your applications with shell scripts and not run systemd. Since systemd it is simpler to admin different linux boxes - at least that is my personal experience - before that every distribution shipped their own shell scripts.

Systemd is fine and if it is so inferior to simple POSIX applications glued together, people should provide a better alternative. The grieve that people have against Lennart is overblown - we should thank him for his contributions.