This looks like one of those PC/Console comparison memes from the early days of pcmasterrace. I like it!
This looks like one of those PC/Console comparison memes from the early days of pcmasterrace. I like it!
TBH cable transfer on android can be pretty shit as well. Like, if you luck out with the MTP implementation on both your phone and your computer, then it Just Works ™. But in many cases (like mine) it’s a buggy mess. I used to have a script that would sync music from my laptop to my phone with rsync, and I would have to run it like three times to actually transfer everything, because each time like 10% of the files would just… not make it across the cable lol. Now I just do it over WIFI. I really wish we could go back to the old days when plugging in your phone would just expose the microsd card as a block storage device.
Hey, do you mind telling me where I can sign up for the apple shilling program? What are the rates like? Approximately how many shill posts do you make a day? Is it necessary to make lots of different alt accounts, or can I just shill from my main?
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
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
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.
Damn, you’re right, maybe I should do some reading on these “well known problems” that I haven’t once experienced in my three years of using android. Sounds pretty bad /s
^ Edgy sarcasm aside, everything you said really is news to me. Is there really that much difference between different android ROMs? I’m running /e/-os on my phone (lineageos fork), and I don’t think I’ve ever had issues with notifications or this “Doze” thing. I can’t say for lemmy app / youtube music tho, I don’t use those. Though I can relate a little bit to the third-party launcher thing – I have MLauncher, and a recent update just completely crippled the search functionality for no reason.