Comment by bayindirh
9 days ago
> But that's not my vision of how open source should work.
Exactly. I expect a modular fork of systemd when people get annoyed enough. I still don't understand why people treat systemd as the second coming of the Christ.
Disclosure: I'm managing large number of servers for the last 20 years. Don't tell me that init scripts were bad. I won't buy it. Don't tell me systemd is fast, again, I won't buy it.
> Exactly. I expect a modular fork of systemd when people get annoyed enough.
That's exactly the case with elogind, used by e.g. Alpine, Void, and Gentoo.
> I still don't understand why people treat systemd as the second coming of the Christ.
FWIW it managed to pull most distros in a single direction, decreasing ecosystem fragmentation. The outliers are well, outliers.
Just to be clear: it's not an endorsement from my side; there's enough criticism of systemd which I will not repeat. But the fragmentation aspect is what kills so much momentum, and it just runs too deep: Gnome was started because KDE's dependency on Qt wasn't kosher; Qt later got relicensed, but both projects kept pulling in different directions. It feels like any compatibility between anything is coincidental.
> Qt later got relicensed, but both projects kept pulling in different directions.
Both desktop environments pull in different directions in appearance only. Esp. KDE team works their heads off to be compatible with GNOME and to support/build standards which work equally well on both systems. For example, ".desktop" file specification. Another notable example is, every KDE release comes with identical GTK themes for flagship Qt theme, plus numerous others which I can't remember now.
So, the underlying standards of many Desktop Environments are the same, because there are standards which many don't see, know, care (and this is a good thing). Vaxry is a case study here, and I exclude his creations.
I know this, because, I took part in developing a Debian derivative distro for ~5 years or so.
> FWIW it managed to pull most distros in a single direction, decreasing ecosystem fragmentation. The outliers are well, outliers.
On the other hand, every distribution selects parts of systemd, patches part of the selected set and configures this set, hence integrates systemd differently in different levels. This creates behavioral differences in systems and their systemd installations.
IOW, systemd didn't reduce fragmentation to the level people wanted them to believe.
Moreover, pulling from that 20+ experience with Linux systems, their behavior was already this consistent since forever. RedHat had a wrapper called "service" on top of "/etc/init.d" system, but the scripts were portable. Some config files unrelated to systemd/init.d were in different places (and still are). e.g. apache/httpd, /etc/network/interfaces vs. /etc/sysconfig/network-scripts, etc.
So, the defragmentation by systemd is an illusion. Since forever, I had to either look for /etc/{redhat,debian}_version or type apt/yum/dnf and press enter to see which distro I'm on. The rest is basically the same, across hundreds of installations.
> Both desktop environments pull in different directions in appearance only.
Nope, no. KDE has a dozen toggles for every feature, half of which don't make sense. It has OK/Cancel/Apply, as if Windows 95 was peak UX. Konsole uses the same color theme regardless of whether you pick light/dark; I've tried to hack together a script, but the CLIs/APIs don't make sense: you have to detect the light/dark preference by parsing the current system theme name. Good luck if it's something like some variation of "PurPurDay"/"PurPurNight". I also couldn't find a way to get programmatically notified about the theme changing - but KDE still shoves useless notifications in my face, like "button X was removed from the panel", which you have to disable one by one. KDE can't tell "powerful" from "overwhelming".
Gnome has a top bar. It has three buttons, the rest is wasted space. The "dock" can't be moved to the left/right screen edge - more precious vertical space taken away. It has no desktop icons, even though there's a "Desktop" folder in Nautilus. It can't set up different screen dim/lock timeouts on battery vs AC. Meanwhile I was watching a PR[1] that would add iCloud integration to system accounts - it got rejected, because "users can just set up IMAP/SMTP". Gnome can't tell "simple" from "simplistic".
I could go on, but please use macOS for a week, and try to draw a fair comparison.
[1]: https://gitlab.gnome.org/GNOME/gnome-online-accounts/-/merge...
> KDE team works their heads off to be compatible with GNOME [...].
Here we go. In the other thread, I was arguing that "competition" in this space is just wasted effort.
> So, the underlying standards of many Desktop Environments are the same [...].
So if I want to write a native application, which toolkit should I target? On macOS, it's Cocoa. On Windows, it's "whatever Windows is doing in this release", but at least I can still run programs that weren't touched since 1997.
On Linux, I have a choice of plain Qt vs KDE, plain GTK (2/3/4) vs Adwaita, and so on. Apps written with one look and behave out of place when used with the other. Every time glibc breaks something, the app needs to be rebuilt. OK, so I want to provide users with a self-contained package. The choices are Flatpak, Snap, and AppImage, all of which are built differently. I could go on.
> Another notable example is, every KDE release comes with identical GTK themes for flagship Qt theme [...].
Design is not how it looks, it's how it works.
> Moreover, pulling from that 20+ experience with Linux systems [...].
Yeah, I've also used Linux on the desktop for 20 years. Then I tried macOS for a month. Then tried OS X 10.5 for a comparison. I remember considering a MacBook in 2007, I regret not getting one back then.
> Since forever, I had to either look for /etc/{redhat,debian}_version or type apt/yum/dnf and press enter to see which distro I'm on.
I've inherited and managed a heterogenous fleet of Debian, Ubuntu, Fedora, CentOS, OpenBSD, etc, (many on different releases), and had to write a lot of Ansible roles by hand, because few existing roles could handle all of these. The quirks and hacks only piled and piled. It's insane.
/rant