@p @vic
> It's like a DE. I don't want a DE. People ask how you can have a widget tray without a DE. I don't want a widget tray.
Same here, I have machines that do not have dbus, but I have no problem running it on the ones where I can benefit from it — seriously, among these things it's the only one I have zero problems with. Overengineered — sure, but it's nowhere near as buggy as systemd and it's fully modular: you can easily replace it with another thing and you can even not have it at all.
@p @vic
> It has that to support the stupid web GUI, and the web GUI
I don't think it's only used by luci — it's also used to notify daemons when the state of interfaces changes. Can you get away not using it? You certainly can, you can use sockets to notify every daemon individually, but at some point you would still want something to broadcast such messages, ubus fills the role just fine. Again, you can easily replace it with another implementation or not use it at all, nothing like systemd.
> Can you get away not using it?
I don't know, but it's a router, not a system where I run programs and write code, and ubus is not dbus: what I know of ubus makes it seem like less of a problem.
> but at some point you would still want something to broadcast such messages,
What you are trying to explain is that if I remove a part from a system that is architected a certain way, then that part needs another part that fits in. I have said I don't want to deal with a horse and you're asking me how I'm going to pull my carriage and asking what's wrong with horses. The carriage is designed around the presence of a horse.
If I want to know what state an interface is in, I can just ask the kernel. If there are a bunch of daemons that would rather call a library that makes a system call to talk to a bus versus making a system call to talk to the kernel, that's the design of that system.
> Again, you can easily replace it with another implementation or not use it at all,
I don't like dbus; this is not to say I dislike all buses. Once there is a bus, everything starts to look like a nail.
> I have no problem running it
Like you have a choice. I'd be delighted if I could remove it from this system but there are programs that I need to execute and they are tied to gtk.
> on the ones where I can benefit from it
That is exactly my point: I don't know what benefits you mean but I do not think they exist and if they do, they probably apply to things that I don't want anyway. We could enumerate the benefits and I could explain why I don't want them.
> it's nowhere near as buggy as systemd
If I kill dbus, a bunch of shit crashes. That is a bug, and it is a bug that they will never fix. Even with a named socket, usually you'll write code to reconnect if it goes missing instead of fucking segfaulting.
@p @vic
> If I kill dbus, a bunch of shit crashes.
I suppose it depends on the distro, how deeply it integrates it and how modular it assumes it to be.
I have just restarted dbus in my Void system (where I even have elogind) — literally nothing started falling apart, no user-facing software crashed or got terminated, bluetoothd got restarted — that's it 🤷
@teratology @p @vic
Yeah, I'm a huge fan — the only distro that suits me perfectly. Despite not having outdated software any problems with updates are quite rare and despite being flexible — I run it on about six machines of mine having vastly different roles and configurations, unlike with Gentoo, I do not spend countless hours servicing them after every update.
@teratology @p @vic
And even if I don't like the binaries they ship, xbps-src allows me to hack on things easily, for example I despise WebP and I build most software without support for it, even if it's not optional already, I can easily modify the template file to make it such, if it gets updated, I can always apply my changes on top of it and rebuild because void-packages is just a git repo.
Pretty much what I want from Gentoo — but without all the daunting fuckery, Void's amazing!
> I suppose it depends on the distro, how deeply it integrates it and how modular it assumes it to be.
No, it's how dbus works. You kill dbus and Firefox crashes, and this is every distro I have tried it on. This is intentional behavior, because dbus is designed for DE users and if the Windows taskbar crashes, Windows will restart it. The idea is that if dbus crashes, your session is broken and your xdm or whatever should restart your DE.
> I have just restarted dbus in my Void system (where I even have elogind) — literally nothing started falling apart,
If you are talking about the system dbus, it's the same program that is used to run a user-level dbus. I am not running the system-level dbus.
@p @vic
I just tried stopping it (instead of restarting) and killing all instances of dbus-daemon running as user — again, nothing special happened, except for… yeah, Firefox — it didn't segfault though, terminated gracefully with something like "channel closed".
Ironically, I can start Firefox again without dbus running, dbus doesn't get spawned and FF works fine.
Well, what can I say… It's odd, it's lame, but so is its developers design decision.
@p @vic
Does it have to do specifically with dbus? Of course not, FF does a plethora of questionable things, like audio input not working in FF without PulseAudio, so I have to use apulse — luckily the output works with alsa.
I agree with you — it should be optional, but IMO it doesn't make dbus itself bad.
I probably wouldn't even have a problem with systemd — were it modular (and less bug-infested😏), BTW this would fit nicely with your approach: don't need the horse — throw it the fuck out!
@dcc @p @vic
No — I checked, the only thing with dbus in its process name is dbus-run-session — because that is how I run dwm from slim, if I kill that, the session obviously terminates just because it's the parent process. But no dbus-daemon or friends running.
And bluetoothd starts complaining that it can't connect to dbus and keeps restarting — so no, not the case.
> FF does a plethora of questionable things,
I was listing questionable things from Linux, dbus was one. Firefox behaves badly around dbus. I have not been under the impression that Firefox was good since the pre-3.6 days.
> I probably wouldn't even have a problem with systemd — were it modular
The size of the surface and the privileged mode of operation means that you can't have it talking to the network, and Lennart made it talk to the network, then he made it speak a dozen protocols and then he put an XML parser and a JSON parser in it. Webservers give up root as soon as they have the port open because you open the door if you don't, and that's one protocol (HTTP) and it's generally just the server side. But he's got it speaking client and server for HTTP and DNS and a pile of other protocols and it isn't just root, it's init, and it links against so many libraries that a meaningful audit of the code for security can never be undertaken. There is no safe mode of operation for it, there's no securing it, it's broken by design. There's not anything to salvage.
> BTW this would fit nicely with your approach: don't need the horse — throw it the fuck out!
Or, like...if you don't want horses, but you let horses in, people will build around the horses and then you'll end up stuck with the horses until you switch to an OS that didn't shove horses in.
@p @vic
I don't know — I didn't write it myself, I'm using whatever Void's xbps-src is giving me🤷
The only thing that might be different in Firefox on this machine from the standard issue Void binaries, as I still had to rebuild it because I patch the about:config preference to disable WebP support, that Mozilla has removed, back in, is that it's built without PulseAudio support — I do not enforce it for every software I run, but the flag to disable it is set globally and it gets picked up.
> I don't know — I didn't write it myself, I'm using whatever Void's xbps-src is giving me🤷
I mean, it should be possible to find out, right?
> the about:config preference to disable WebP support, that Mozilla has removed,
Holy fucking shit. The only mitigation against the stupid webp exploit was to turn webp off.
@p @vic
> I mean, it should be possible to find out, right
Of course it is! On my build machine I would just check out the commit that was used for building it, start the rebuild process and snatch the config, but I'm not — and I'm a lazy ass looking for other options😅
> The only mitigation against the stupid webp exploit was to turn webp off.
Can you imagine it? They have removed that option in like a week or two after that vulnerability got discovered!
@p @vic
I can't even come up with a good explaination on why that was done — this preference looks zero maintenance cost to me, it's like four lines of code that require minimal to no testing; other than receiving a call from their Google HQ with something like: "No one likes our image format that is actually video compression cosplaying image compression — do something about it!"
> What's wrong with dbus though?
FSE's text limit is 16,384 characters. I don't think I need a daemon for a browser to run, I sure as hell don't know why the browser should crash if the daemon is killed.
> Something has to fill the role of IPC
Processes have to communicate, sure. dbus is not the only answer, or the best answer. Sun had an answer and people hate the rpcbind shit.
> to pass messages between daemons and other software
Sit on dbus-monitor a while and look at exactly what passes through.
> that isn't… you know, a named socket — something higher level
No, you do not. For most of these terrible pieces of software, people say this sort of thing, and sometimes the best alternative to a terrible thing is "nothing". I can ask you why you need that and you can say "Because otherwise we couldn't have $x" and I tell you that I don't have $x (or maybe I have $x but I don't want it but shit refuses to build without it). It is an overengineered piece of shit, it is a freedesktop.org bureaucratic nightmare, it provides literally nothing that I want and compels a lot of things that I do not want.
If we take it as a given that a real problem is being solved, even then "dbus is a solution to a problem" doesn't necessarily mean that it is the only solution. There are a lot of ways to achieve interprocess communication. A named socket is fine for Linux, terrible programs spew way too much information down dbus and it's another piece of shit tool in Lennart's open attempt to create a standard that no one needs in order to ensure that RedHat controls the ecosystem.
It's like a DE. I don't want a DE. People ask how you can have a widget tray without a DE. I don't want a widget tray. Increasingly, I don't want Linux, because all of the dumb shit that is present in Windows or OSX is getting added, as if the HCI problem were solved and there's only one way to do any of this. (Joke's on anyone that made that argument, because OSX is turning into iOS and Windows is turning into a shitty Flash website from 2002. Evidently the final word in user interfaces has not been spoken, or there wouldn't be any changes.)
> Even OpenWRT — which doesn't have all the luxuries of a full-blown system, has ubus.
It has that to support the stupid web GUI, and the web GUI breaks if you uninstall dnsmasq, which you might do because the stupid web GUI completely ignores you if you tell it that you already have a DHCP server and you want it to just route packets, and then you tell it to just not start dnsmasq and it ignores you anyway so you have to actually remove dnsmasq. So if you remove dnsmasq then the stupid web GUI actually crashes on startup.