11–20 of 69 posts
>systemd's team is noticeably chauvinistic and anti-Unix ONE OF THESE THINGS IS NOT LIKE THE OTHER, ONE OF THESE THINGS IS a serious allegation against the values of systemd's maintainers that is not backed up by anything in the text. Unless the writer just doesn't understand what "chauvinism" is beyond being a malword. >systemd flies in the face of the Unix philosophy: "do one thing and do it well," representing a c…
Can anybody explain to me what dbus is for, and why I sometimes have to start applications using "dbus-launch" because otherwise they can't connect to dbus. Or why sometimes when I login on other systems using "ssh -CY" I cannot even start applications like eog (eye of gnome) because dbus is in the way, but somehow mysteriously they DO start when I run them with "strace -f"? Seems to me that Linux systems are startin…
Dbus doesn't have anything to do with systemd FYI. It's a communication bus for processes to talk to each other through structured RPC messages.
> udev and dbus are forced dependencies.
Can anybody explain to me what dbus is for, and why I sometimes have to start applications using "dbus-launch" because otherwise they can't connect to dbus. Or why sometimes when I login on other systems using "ssh -CY" I cannot even start applications like eog (eye of gnome) because dbus is in the way, but somehow mysteriously they DO start when I run them with "strace -f"? Seems to me that Linux systems are startin…
Generally I only start it if an application won't work without it. Biggest issues for me (personally) is it's linux-specific and (unless I'm missing something) limited to the current host); otherwise it's client-agnostic sockets FTW.
Earlier quoted context omitted.
Dbus doesn't have anything to do with systemd FYI. It's a communication bus for processes to talk to each other through structured RPC messages.
From the article: > udev and dbus are forced dependencies.
Related writeup: https://people.debian.org/~stapelberg/2013/06/09/systemd-blo... .
>systemd's team is noticeably chauvinistic and anti-Unix ONE OF THESE THINGS IS NOT LIKE THE OTHER, ONE OF THESE THINGS IS a serious allegation against the values of systemd's maintainers that is not backed up by anything in the text. Unless the writer just doesn't understand what "chauvinism" is beyond being a malword. >systemd flies in the face of the Unix philosophy: "do one thing and do it well," representing a c…
You may be thinking of “male chauvinism”, which of course has nothing to do with “systemd chauvinism” (or “SysV chauvinism” for that matter).
All of the functionality on that list has two things in common that make them good candidates for Systemd: they all require programs to be started and stopped in response to state changes, and they all will require different programs to be started at initialization based on the initial state of the system. I was annoyed too when udev became systemd-udev and broke a few pieces of functionality I was relying on 15 years ago but if you're building a system around the Linux kernel it's a really useful toolkit if you have the resources to use it, because it does a ton of stuff for you.
Before Systemd I was having to write ifup/ifdown scripts and monkey with shell scripts in init.d and updating udev rules to control initialization, which was more Unixy but also riddled with edge cases. For example, there's nothing stopping ifup/ifdown scripts from running out of order with certain udev rules when you plug in a USB-to-Ethernet adapter without inventing your own ad-hoc synchronization mechanism. Systemd builds that same thing in and essentially makes it the default.
It's had some irritating teething problems, and I would also prefer some more interchangeability and some reduction in the amount of binary code, but I have a better experience with it than without it in the systems that I work with.
From what I can see there's still a groundswell of anti-systemd sentiment, and there are distros that attempt to avoid it.
Edit I was mistaken about how active CRUX is, corrected.
Earlier quoted context omitted.
Dbus doesn't have anything to do with systemd FYI. It's a communication bus for processes to talk to each other through structured RPC messages.
From the article: > udev and dbus are forced dependencies.
Even udev is optional (upon upon a time, adding a new device involved knowing the right 'mknod' invocation in order to be able to connect to it - udev sort-of solves that).