I recently tried to setup Linux on a few machines with nvidia and AMD GPUs, and, while AMD could improve, they're way ahead of nvidia on all fronts except machine learning.
Nvidia's drivers are still uniformly garbage (as they have been for the last 20 years) across the board, but they do work sometimes, and I guess they're better for machine learning. I have a pile of "supported" nvidia cards that can't run most opengl / glx software, even after installing dkms, recompiling the planet, etc, etc, etc.
Since AMD upstreamed their stuff into the kernel, everything just works out of the box, but you're stuck with rocm.
So, for all use cases except machine learning, AMD's software blows Nvidia's out of the water for me. This includes running Windows games, which works better under Linux than Windows (the last time I checked), thanks to Steam.
On my 780m, I installed current devuan (~= debian) stable, and had a few xscreensaver crashes and reboots. I checked dmesg, and it had clear errors about irq state machines being wrong for some of the radeon stuff. So, even when running future hardware, their error logs are great.
After enabling backports and upgrading the kernel, the dmesg errors went away, and it's a 100% uptime machine.
The remaining hardware problem is that pulseaudio is still terrible after all these years, so I have to repeatedly switch audio out to hdmi.
That doesn't read like taking a dependency on systemd. Rather, Pipewire doesn't have custom code to "daemonize" by itself.
Is there any reason why all individual tools should learn how to daemonize (in addition to or in replacement of running in the foreground)? There's external tools that can take care of that uniformly, and using the latest/greatest syscalls for it. That seems better than every application including this code. As highlighted in the thread, there are other programs that can launch+daemonise another a process (like the aptly named [daemon(1)](https://manpages.debian.org/unstable/daemon/daemon.1.en.html) tool). Seems more like the UNIX way, from the outset.
Maybe it's complicated, but perhaps it's trying to replicate daemon(3) without bugs, and for different processes. See the BUGS section in the daemon(3) man page.
> Given that it’s typed once (by the daemon author, and not the end user), it seems like a big win vs. daemon(1) to me.
This seems like a false comparison. It's not the case that the end user writes the code to daemonise in the non-included case. The user would just use daemon(1) or systemd(8) or something else that can daemonise. Or perhaps a service manager that doesn't need to daemonise, like runit(8) (https://smarden.org/runit/) and its ilk.
The more I read about this, the more I want to know why it's so important that pipewire is running "daemonized" (whether it does it itself or not). Can you explain the advantages and disadvantages?
Nvidia's drivers are still uniformly garbage (as they have been for the last 20 years) across the board, but they do work sometimes, and I guess they're better for machine learning. I have a pile of "supported" nvidia cards that can't run most opengl / glx software, even after installing dkms, recompiling the planet, etc, etc, etc.
Since AMD upstreamed their stuff into the kernel, everything just works out of the box, but you're stuck with rocm.
So, for all use cases except machine learning, AMD's software blows Nvidia's out of the water for me. This includes running Windows games, which works better under Linux than Windows (the last time I checked), thanks to Steam.
On my 780m, I installed current devuan (~= debian) stable, and had a few xscreensaver crashes and reboots. I checked dmesg, and it had clear errors about irq state machines being wrong for some of the radeon stuff. So, even when running future hardware, their error logs are great.
After enabling backports and upgrading the kernel, the dmesg errors went away, and it's a 100% uptime machine.
The remaining hardware problem is that pulseaudio is still terrible after all these years, so I have to repeatedly switch audio out to hdmi.