So is pulseaudio finally dead??

pulseaudio died because they replaced it with pipewire

>Poettering creates a monolithic and bloated "init process"
>Poettering also creates an audio daemon that is known to have latency issues
>Any Forums hates both for being ass
>Actual decent RedHat engineer creates a replacement for pulseaudio that fixes all of the latency issues
>it even is backwards compatible with pulseaudio bullshit
>Any Forums likes it because it is a genuine improvement on pulseaudio
What's to get?

>hold my beer

Attached: maxresdefault.jpg (1280x720, 57.02K)

Perhaps there are some people on here who use some mysterious other metric to judge software.
I for one understand that software quality is an indelible trait of a certain group of developers and only use stuff that is by the Any Forums certified good devs.

>Poettering creates a monolithic and bloated "init process"
systemd isn't bloated, it just provides better(most of the times less bloated) alternatives to system applications like oom daemon, network manager, dns resolver, bootloader etc. all of these systemd provided system utilities are much less bloated than their non-systemd counterparts.
and by your logic you shouldn't use linux kernel because its monolithic.

>systemd isn't bloated
They may be faster than their counterparts, but bundling them all under one application seems like bloat to me.
Systemd also isn't modular at all, so you have to use all of it or none of it (or forks of it's parts like eudev).
>by your logic you shouldn't use linux kernel because its monolithic.
Would honestly use something else if there was a kernel that could rival the linux kernel in it's drivers and whatnot.
I will say that compared to systemd, the monolithic design of the kernel is somewhat mitigated with kernel modules.

>hurr sure I'm retarded
systemd is garbage, I say this as someone who has to deploy Linux on performance critical hardware for a living.
the Linux kernel is extremely modular and easy to extend. the program code being a monolithic kernel architecture has nothing to do with it's extensibility or flexibility, unlike systemd where extension is nigh impossible even though the programs run as a series of small daemons.

has systemd hindered any of your "performance critical" tasks, if yes then what else do you use?

yes. the journal is so God awfully slow we have to severely limit our process debug logs just so the computer can run a program at 10hz.
the logs regularly corrupt during power cycles.
service parameterization is extremely limited meaning I have to hand roll dozens 3+ files each for each service running a different instance of the same program.
the environment in systemd services is difficult to manage cleanly, especially if you have multiple services with consistent environment settings.

I haven't been able to switch away from systemd yet due to time constraints on my deliverable, but my product will be switching to supervisord or potentially whatever Ubuntu core uses with snapd in the next release cycle

ALSA just works.

this, fuck poetteringware.

barely

Pipewire nit only depends on dbus but also requires it to be constantly running in somm weird desktop session mode.
Utter garbage.

>barely
Elaborate, what can't ALSA do?