On 11.07.2017 18:03, Adam Borowski wrote:

> Because so many upstreams of valuable software not only migrate to it but
> also make it mandatory.

Do you have an example, that currently hits us - then I'll have a look
at it.

> It's all of lennartware, not just systemD.

Well, the dbus pest indeed is a problem. Let's solve that step by step,
as needed.

> I have
> been lucky to not need anything that uses to be infested with Avahi (they
> say it's "needed" for printers), but PulseAudio puts its tentacles
> everywhere.

PA isn't so bad, since lennart left the project. Perhaps, we could find
or create an suitable (crossplatorm) client API for the majority of the
use cases, and then start killing all these intermediate layers in
dozens of applications. Which actual audio system then is used in the
back, shall be the decision of the individual operator / user.

> You do know the story with Firefox;

Firefox has always been a mess, anyways. And it's now even worse, as
they made new programming laguage, which is yet in alpha state,
mandatory. I'd guess we wont see recent FF usable within the next year.

> Seriously, an audio player which doesn't care at all whether sound actually
> works?!

The reason for that decision is understandable, because many people
actually want PA (I've got it running myself, and I'm fine w/ it),
so they'd need to support multiple audio APIs, thus maintain their own
private intermediate layer.

It comes down to the lack of an (really usable) crossplatform audio API,
which bridges to the actual platform API. Maybe a subset of the PA API
could become that, maybe something completely different. But we need
to resolve that problem at the root.

> Especially that there's NOT A SINGLE REASON to ever use PulseAudio
> instead of ALSA: it used to be that "cheap" sound cards could be opened only
> once; this applies to basically all modern cards: they consist of just a DAC
> these days -- but ALSA has a software mixer for more than a decade now.

What about other platforms ?

IMHO, we need something as simple as OSS (but as a C API, not kernel
devices, of course), w/ backends for the various platforms.
> * armhf laptop. Starting PA causes a kernel OOPS that also kills
most GUI.

Userland should never be able to cause OOPS. Kernel bug ?

>    This is a kernel bug but one I can't fix -- it's stuck on a 3.0 sourceless
>    vendor kernel.

Demand the kernel sources from the vendor ?

> Nasty but that's widespread in the ARM world.

I'm doing a lot in ARM world (embedded systems), I never use vendor
kernels, nor vendor BSPs. (OTOH, no PA on these boxes, either)


--mtx