Post B5km5ZImukNtPZ6QpU by drakulix@dreampi.es
(DIR) More posts by drakulix@dreampi.es
(DIR) Post #B5kZJjATjMwSezdZvE by q66@gts.q66.moe
1 likes, 1 repeats
hot take: dbus is mostly just kinda okay and not some kind of terrible evil thing that must be eliminatedsure it's a bit janky and the reference libdbus library to work with it is kinda ass (better ones exist now) but given when it was created it's not unusual and also it's not some kind of massive blocker that would warrant total replacementi'm fairly convinced that 95% of dbus hate mostly stems from the session bus formerly being launched with desktop, noone really understanding what dbus-launch and dbus-run-session really do, and the subsequent confusion about "why don't my bus-using apps work from another tty and/or from a clean terminal with fresh env vars" because abstract sockets are such a niche functionality and there used to be no real session tracking
(DIR) Post #B5kZyprTkVJbIDLthI by q66@gts.q66.moe
2 likes, 0 repeats
the worst thing now is how the old harmful conventions kinda just live on, partially because of old stuff partially because of most non-systemd distroslike when people arbitrarily put dbus-run-session in their session scripts without understanding why and nerfing their desktop in the process by making everything within lose access to the proper session bus that is already running, because some rando on some website said it was a good idea 10 years ago, or because they always used to do that
(DIR) Post #B5kipqVmrULGI3ziBU by navi@social.vlhl.dev
1 likes, 0 repeats
@q66 my major problem is autostart, dbus autostart is not configurable, error prone, and on non-systemd, starts unsupervised daemons arbitrarilyand specially with portals, having the thing autostart the kde portal when not in a kde session has caused a lot of confusion for wifey that took a while to debugdbus and pipewire were the major reasons i made openrc user-services after all
(DIR) Post #B5kipqyr7PatkDavUe by mia@shrimptest.0x0.st
1 likes, 0 repeats
@navi @q66 a lot of that stuff is reminiscent of windows directshow filter graphsand the implementation of portals is so fucking broken and weird
(DIR) Post #B5kiprByKe5OOtjOwC by navi@social.vlhl.dev
1 likes, 0 repeats
@mia @q66 imo autostart on an arbitrary api call shouldn't be a thing, instead it should just fail with a clear errorDEs already bundle daemons on startup, WM people already start e.g. pipewire on their own, use those mechanisms for dbus end points too
(DIR) Post #B5kiprRvNKqXCNC8no by lanodan@queer.hacktivis.me
0 likes, 0 repeats
@navi @q66 @mia I wish it would be just the autostart thing, which would probably be a simple patch.But dbus being used for all kinds of IPC including sensitive and security-critical stuff (like polkit belongs in hell) is what made me throw it all away, like launch dbus-monitor and see all the stuff going through it.Another one that's probably still there is if dbus crashes/get-killed, everything connected to it also crashes and so far all the desktop environments I've tried this in fails to recover.
(DIR) Post #B5km5ZImukNtPZ6QpU by drakulix@dreampi.es
0 likes, 0 repeats
@q66 100% agree and to extend upon that, I feel like this applies to a lot of the modern linux stack.Much of the frustration comes from power-users on single user systems, that are annoyed, that they "can't simply" do something *anymore*, while ignoring the complexities of modern computing, multi-user systems and security aspects.E.g. why can I not execute a graphical application as root under wayland, ignoring why that is a bad idea to begin with. Why is wayland not abstractable over network, ignoring the niceties of gpu-accelerated desktops and the existence of waypipe.Or take systemd. Dependency management is inherently complex and while it would surely be nice to be able to *simply* edit ones system initialization through a bunch of shell scripts, that completely ignores how difficult that is to maintain.Are any of these perfect solutions? Surely not and it is healthy that alternatives exist for the overall ecosystem. But "hate" for any of these is such a waste of time.
(DIR) Post #B5km5ZZ5w7QcE8jSFM by q66@gts.q66.moe
1 likes, 0 repeats
@drakulix for most part yeah? i still think systemd is kinda bad and unpleasant to use software for reasons mostly unrelated to the above, but that's a separate topic and any discussion about it kinda inevitably tends to get poisoned
(DIR) Post #B5kmBG8j4X59ia6see by pauldoo@mastodon.scot
0 likes, 0 repeats
@drakulix @q66 100% applies to the “power user” take of immutable or atomic linux systems, imho. “Oh but I can’t ‘sudo yum install’ anymore!”No, and that’s good! The clearer separation of the OS from software repositories is good! It’s also good to abandon the idea of mutating a live system in-place. That’s was never great. Push left!
(DIR) Post #B5kmBGKQN2RKIraDtA by q66@gts.q66.moe
1 likes, 0 repeats
@pauldoo @drakulix the idea with atomic systems may be alright but the way it's typically implemented on the legacy base is no good at allthe way i want it is making sure the underlying system seamlessly gives you the option without needing a bunch of crusty stuff on topstart with a package manager and packaging that acts atomically and doesn't run random scripts in the middle of a transaction, limiting them to the end and making them idempotentmake any dynamic configuration data (/etc /var) statelessmake the system fully workable with a read-only rootlittle and not-so-little things that make fundamental building blocks
(DIR) Post #B5kmID7Yh7F0NlsXAm by SRAZKVT@tech.lgbt
0 likes, 0 repeats
@drakulix @q66 but the problem of systemd isn't that it handles dependencies, openrc and s6 do as well, and as far as i know, so does dinitthe problem of systemd is it is a single monolith that tries to do everything, from system services, hostname resolution, user database, handling of xdg directories, superserver, etc. that is a very monopolistic behaviour, and those should be avoided
(DIR) Post #B5kmIDIu0wJawxBar2 by drakulix@dreampi.es
0 likes, 0 repeats
@SRAZKVT Not really a discussion I want to have. But you do realize, that systemd-hostnamed, systemd-timedated, systemd-userdbd, etc are all separate components, that aren't necessary to run or bundle in any systemd based system?You *can* simply use it as a service-manager and it still has a lot of merit over openrc, s6 and dinit. And I believe there is a reason people aren't doing that, which isn't simply "monopolistic behaviour". (Another reason is probably also polarizing people, given that pulseaudio also experienced a bunch of backlash, when it was new.)
(DIR) Post #B5kmSOCKMiz7dHxki8 by SRAZKVT@tech.lgbt
0 likes, 0 repeats
@drakulix all components depend either on others, or in the libsystemd shaped hole where nearly everything goes, so ypu'd need to reimplement at least partially some parts (which might in some way behave unexpectedly without identical behaviour), or patching systemdbut sure, it's all completely separate components
(DIR) Post #B5kmSOQVW0KMLGb4oS by navi@social.vlhl.dev
1 likes, 0 repeats
@SRAZKVT @drakulix if systemd truly were made of completely separate components, we wouldn't need the gardenhouse reimpls (of userdb, hostnamed, and misc tools), and elogind wouldn't be necessary, nor the broken mess it issystemd is compartmentalized, but not modular, and that's the issue
(DIR) Post #B5kmUZbUvgKjaRmGBc by fiore@brain.worm.pink
0 likes, 0 repeats
@navi @drakulix @SRAZKVT rose mentioned :cirno_love:
(DIR) Post #B5kmd7fOAWMXXzfqpk by fiore@brain.worm.pink
0 likes, 0 repeats
@lanodan @q66 @mia @navi why does polkit belong in hell in your opinion ? /genq
(DIR) Post #B5kpzp0M1EGCBvznOa by lanodan@queer.hacktivis.me
1 likes, 0 repeats
@fiore @q66 @mia @navi Polkit just screams dirty hack to me.Like even just surface-level, you get a JS runtime, XML libraries, and heavy usage of glib (the gnome lib).And then a bunch of CVEs related to lack of environment sanitisation / isolation, most well known there being PwnKit.Plus https://www.cve.org/CVERecord/SearchResults?query=polkit is full of various kinds of bypass, including https://www.cve.org/CVERecord?id=CVE-2021-3560 where credentials check can be just bypassed.
(DIR) Post #B5kr7yZUQxSu8IslSC by lanodan@queer.hacktivis.me
1 likes, 0 repeats
@fiore @mia @navi @q66 Also would have to check to be sure, but I sure hope polkit isn't using dbus as a safe channel like you could have with a socket at a root-controlled location.Otherwise it means that by design you get credentials sniffing / MITM / …
(DIR) Post #B5kt6IytmO4OlJ68yu by fiore@brain.worm.pink
0 likes, 0 repeats
@lanodan @q66 @mia @navi yeowch ….
(DIR) Post #B5kt7qP50ASYi14tTk by fiore@brain.worm.pink
0 likes, 0 repeats
@lanodan @q66 @mia @navi i sure hope too >~<
(DIR) Post #B5ku3kGhyAsWTeltqa by phnt@fluffytail.org
1 likes, 0 repeats
@lanodan @mia @navi >Another one that's probably still there is if dbus crashes/get-killed, everything connected to it also crashes and so far all the desktop environments I've tried this in fails to recover.There's a fun RHEL bug that is also probably in other distros due to how dbus works. When the system dbus-broker is restarted on update, something fails to recover and everything that wants to talk to dbus will wait doing nothing until it times out on every request. Of course su and sudo are affected, so if this happens and you don't know what happened, have fun waiting a minute for every invocation of sudo or su to complete.
(DIR) Post #B5kuMrD8Nl7rVjDHIO by lanodan@queer.hacktivis.me
0 likes, 0 repeats
@phnt @mia @navi su and sudo on RHEL are affected by dbus stuff?? o_OPAM shenanigans?
(DIR) Post #B5kuzQTnha9DtoOqjA by phnt@fluffytail.org
1 likes, 0 repeats
@lanodan @mia @navi systemd integration probably.EDIT: Which also means OpenSSH might be affected by this too.
(DIR) Post #B5kuzQguuodiYUXKAi by lanodan@queer.hacktivis.me
1 likes, 0 repeats
@phnt @mia @navi OpenSSH at least allows to disable PAM and I would highly encourage doing so as it can end up allowing password-auth even with PasswordAuthentication no
(DIR) Post #B5kvNNDVU6TWjJCJ04 by mia@shrimptest.0x0.st
1 likes, 0 repeats
@lanodan @navi @phnt openssh only uses PAM for account and session checks with PasswordAuthentication no and UsePAM yes. it won’t allow password auth with that
(DIR) Post #B5kvqhr3peL38RgZ3Q by lanodan@queer.hacktivis.me
0 likes, 0 repeats
@mia @navi @phnt Well hopefully it's OpenBSD having hardened OpenSSH since and that's the result, but would still encourage people to check password auth is actually disabled.
(DIR) Post #B5kw9OJogvP62y2se8 by phnt@fluffytail.org
0 likes, 0 repeats
@lanodan @mia @navi Debian allows UsePAM no I think, but RHEL will complain about it. https://git.almalinux.org/rpms/openssh/src/branch/c8/SOURCES/openssh-7.8p1-UsePAM-warning.patch
(DIR) Post #B5kw9OfnNCz798KQu8 by lanodan@queer.hacktivis.me
0 likes, 0 repeats
@phnt @mia @navi And of course just "and may cause several problems" instead of proper explaination.