I don’t know shit about fuck, but you explanation seems correct.

I do remember hearing that precisely because of the limitations of vinyl compared to CD, music is mastered differently for each medium. So the CD master of a certain song might be more compressed (dynamic compression, not digital compression) to make it sound “louder”, while the vinyl release has a wider dynamic range. So some people might prefer the vinyl version because it actually does sound different to the CD version.

Keep in mind tho, I might be spreading misinformation here.

Digital music can be taken as easily as it can be given.

Digital does not always mean DRM. You can pry my bandcamp FLACs from my cold dead hands. Physical media nowadays is more about the experience than functionality. Maybe there are snobs who claim that vinyls are somehow functionally superior, but generally the people who use vinyls or CDs or tapes instead of digital are really just looking for that physical experience in a highly digitalized world.

They have sound quality as good as digital

CD quality is actually superior to streaming services like spotify (I personally can’t tell the difference tho).

deleted by creator

“If buying it isn’t owning it, that means pirating it isn’t stealing it”

What comes after thrice? Quadrice? Tetrice?

How I sleep knowing that I have never having watched any Widevine content ever in my life: 😴😴😴

“Hey there nice post. Unfortunately, here is some bullshit I dug up from your comment history which clearly demonstrates that you are unworthy of expressing your opinion”

Not defending that guy, just really wish this type of behavior would just die along with the rest of r*ddit already. Something something ad hominem falacy

By “start with dbus” do you mean with the dbus-launch utility? I think it’s needed because it sets some environment variables that thunar uses to actually find and connect to the bus. If you run just the daemon “on the side”, thunar won’t know how to connect to it. Kind of how you need $DISPLAY to be set correctly for X11 applications to work.

Great point about policies! Setting permissions on sockets only gets you so far… I guess if you really wanted to, you could create an individual socket for every method of every resource, and have granular permissions that way. But that would be quite messy

There’s nothing about dbus that makes decoupling easier, you can do it just as well with sockets. Pipewire and pulse both speak the same protocol, and they both rely on sockets, not dbus. The vast majority of the apps on my system don’t know or care that they’re speaking with pipewire instead of pulse. Read my comment here https://lemmy.world/comment/6284859

I posted this in another comment, but to me it just sounds like this autostart mechanism in dbus is just a poor re-implementation of an init system

In either case you still need to read the documentation of whatever daemon you’re trying to interface with to understand how it actually works. Dbus just adds the extra overhead of also needing to understand how dbus itself works. Meanwhile sockets can be explained in sixteen words: “It’s like a TCP server, but listening on a path instead of an ip and port”.

modular daemons

A message bus won’t magically remove the need for developers to sit down together and agree on how some API would work. And not having a message bus also doesn’t magically prevent you from allowing for alternative implementations. Pipewire is an alternative implementation of pulseaudio, and neither of those rely on dbus (pulse can optionally use dbus, but not for its core features). When using dbus, developers have to agree on which path the service owns and which methods it exposes. When using unix sockets, they have to agree where the socket lives and what data format it uses. It’s all the same.

It can even start the receiving daemon if it is not yet running.

We have a tool for that, it’s called an init system. Init systems offer a large degree of control over daemons (centralized logging? making sure things are started in the correct order? letting the user disable and enable different daemons?). Dbus’ autostart mechanism is a poor substitute. Want to run daemons per-user instead of as root? Many init systems let you do that too (I know systemd and runit do).

Wouldn’t this also be possible with plain sockets tho? To continue with your example of music players, the current standard is MPRIS, which uses dbus. But in an alternate universe, the people behind MPRIS could just have decided that music players shall create sockets at /run/user/1000/mpris/[player name] that all speak the same standardized protocol. If a player wanted to add functionality beyond MPRIS, it could accept nonstandard requests on its socket, or create a new socket altogether for extended control.

I just don’t see how this would require any more coordination between developers than the current solution. And I don’t see how dbus can save you from having to “understanding every single […] app out there”. If anything, it adds the overhead of learning how dbus itself works, on top of how a specific app’s dbus interface works.