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

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).

Python is so great (half-sarcasm) that a trailing comma on its own constitutes a tuple (immutable list):

mytuple = 4,
assert len(mytuple) == 1
assert mytuple[0] == 4

https://gpa.43z.one/

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).