I could appreciate a client certification that is optional, like a list of approved clients on their website or something along those lines.

It should not be enforced by killing the client. I like security, but I enjoy software freedom more.

Llvmpipe is enabled in mesa at compilation time and actually modifies the swrast_*.so the last time I checked. Not runtime configurable. Also, I know at one point it had issues running on 32 bit machines. Not sure if that's still the case.

Just add a new user

Not sure about the Eco tank line, but the smart tank line botched the IPP interface. Ink level reporting is always wrong and printer status is regularly wrong. Exposed settings are limited to push people to the app.

To be fair, C predates dependency hell. It was either there or it wasn't. C++ has less of an excuse, but it was just object oriented concepts taped to C so it's no surprise it was also missing dependency management.

Now with cmake, gnu-make, meson, gradel, and the world of metabuild systems that wrap those, nothing will change. It it does, it might as well kick start world war 3.

I'm currently use RiMusic, but I wish something would automatically sort through my ListenBrainz recommendations

We'll have a timeline for the plan to make the plan by next quarter

Was actually considering buying premium now that I use YouTube for music more than Spotify, but then the ad stuff happened and now this. Going to avoid it out of principle now.

Sounds like it would specifically be APRS if they were. Neat protocol. Unfortunately no encrypted traffic was allowed last time I looked into it.

https://github.com/MultiMC/Launcher/issues/4102

I agree limiting application scope is useful for multiple reasons, however Jellyfin started as a fork of Emby which already had music support. I have yet to find a standalone application that has enough features to sway me from just utilizing the existing media server functionality.