Working is not the problematic part. There are two interrelated problems: how much complexity is introduced, and how to proceed when something is not working, or is flaky.
You, me, and our fellow posters know very well that Lennart's solutions are complex - in fact, more complex than the problem domain. Accordingly, the ability to narrow down, fix, or work around problems suffers. Systemd and PulseAudio aren't UNIX applications [1]; they are entirely new, rather opaque, sub-systems unto themselves. Thus they require separate knowledge, separate intuition, and separate skills.
All so I can seamlessly play music on TWO bluetooth speakers while also browsing logs without learning regex.
>Lennart Poettering is a dev who has contributed MASSIVE AMOUNTS OF CODE
Massive amounts of code is a clear and present problem. Why is the solution more complex than the problem domain? Why is the success being measured by magnitude of effort, rather than by barriers removed, and standards adhered to?
--
[1] what makes an UNIX application? small POSIX applications tied together with shell scripts, communicating via pipes, exposing services as files, following the `Worse is better' and `Do one thing, and do it well' principles.
> 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.
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.
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.
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 :-)
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.
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.
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.
Working is not the problematic part. There are two interrelated problems: how much complexity is introduced, and how to proceed when something is not working, or is flaky.
You, me, and our fellow posters know very well that Lennart's solutions are complex - in fact, more complex than the problem domain. Accordingly, the ability to narrow down, fix, or work around problems suffers. Systemd and PulseAudio aren't UNIX applications [1]; they are entirely new, rather opaque, sub-systems unto themselves. Thus they require separate knowledge, separate intuition, and separate skills.
All so I can seamlessly play music on TWO bluetooth speakers while also browsing logs without learning regex.
>Lennart Poettering is a dev who has contributed MASSIVE AMOUNTS OF CODE
Massive amounts of code is a clear and present problem. Why is the solution more complex than the problem domain? Why is the success being measured by magnitude of effort, rather than by barriers removed, and standards adhered to?
--
[1] what makes an UNIX application? small POSIX applications tied together with shell scripts, communicating via pipes, exposing services as files, following the `Worse is better' and `Do one thing, and do it well' principles.