idk man ipv4 NAT sounds like the “complicated bloat” to me.

Thanks, will take a look when I have time

No, it’s an edit. I linked the original in the post text. If you can’t access it for some reason, here’s a transcript:

Government of the Netherlands

Home > Topics > Coronavirus COVID-19 > Travelling to the Netherlands from abroad

Checklist for travel to the Netherlands

Do not travel to the Netherlands.

Agreed. Though I wonder if ipv6 will ever displace ipv4 in things like virtual networks (docker, vpn, etc.) where there’s no need for a bigger address space

Typical conversation between a non-programmer and a programmer about AI:

Won’t AI put you out of your job?

It probably won’t

Well, can’t AI write code much faster and more efficiently than humans?

How would it know what code to write?

I guess you would need to provide it with a description of the app that you want it to make?

So you’re telling me that in the future, there will be machines that can generate computer code based entirely on a description of the required functionality?

I guess so?

Those machines are called “compilers”, and “a description of the required functionality” is called “a program”. You’re describing programming.

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: 😴😴😴

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.