Systemd, 10 years later (2020) • Hacker News Board

Re: Systemd, 10 years later (2020)

#291

Post by awrmc » Sun, Jan 09, 2022, 6:47 PM UTC

Arch-TK wrote: post #233

junon wrote: post #227

The only bit about SystemD I'm not fully sold on is D-Bus. I love that everything is exposed via D-Bus, but the C API is incredibly difficult to reason about. I've tried writing some higher-level bindings for it and it's still pretty difficult to get right. Perhaps at some point they'll switch to something that's established instead of maintaining their own IPC protocol.

I've tried writing higher level bindings on top of libdbus. Once I realised that libdbus was not designed for writing reliable or sane software (there's an error? there's an error! what is it? who knows) I decided to try writing my own implementation of the dbus protocol (the intention was to write C code generators for automating away writing a lot of the boilerplate). Once I had read the specification once I gave u…

I disagree with this, in my experience D-Bus is very similar to other IDLs like DCOM, protobuf or ASN.1. If you're familiar with those, D-Bus should actually be easy in comparison.

Re: Systemd, 10 years later (2020)

#292

Post by the_why_of_y » Sun, Jan 09, 2022, 6:58 PM UTC

Blikkentrekker wrote: post #264

the_why_of_y wrote: post #258

Earlier quoted context omitted.

> Debian was the last major system to discard sysvinit This is partially incorrect and partially misleading. Incorrect in that openSUSE and Arch are major distros and migrated from sysvinit to systemd. https://news.opensuse.org/2011/12/22/systemd-e2-80-93-boot-f... https://www.reddit.com/r/archlinux/comments/4lzxs3/why_did_a... Misleading in that Ubuntu and Fedora did use Upstart but not in its native mode, they used…

> Incorrect in that openSUSE and Arch are major distros and migrated from sysvinit to systemd. OpenSUSE also had upstart in the meanwhile but continued to support sysvinit as an alternative. Arch Linux had sysvinit as it's pid1, but it's big sell initially was that, similar to Crux, it had a custom BSD-style init script setup and did not use sysvinit's booting and rc mechanism. OpenRC systems typically also continue…

> OpenSUSE also had upstart in the meanwhile but continued to support sysvinit as an alternative.

I wasn't aware of that ... it turns out that it was the other way around: openSUSE 11.3 has this item, implying it's not the default:

"Upstart is included as optional init system"

https://en.opensuse.org/Archive:Product_highlights_11.3

openSUSE 11.4 then mentions systemd, although "experimental".

https://en.opensuse.org/Archive:Product_highlights_11.4

openSUSE 12.1 defaults to systemd (see previous comment), with sysvinit as non-default option.

So Upstart was a short-lived non-default option.

> A big sell of Upstart and OpenRC was always that it was backwards compatible with old-style sysvinit-style scripts even though new ones were written in the new style.

You are right that there are no distinct modes as such, my memory is quite fuzzy as it's been some years, and I wouldn't rely on anything I say. And it looks like Ubuntu (unlike Fedora) did replace a lot of init.d scripts with native Upstart jobs.

https://launchpad.net/ubuntu/+spec/replacement-initscripts

I can't remember what the problem was with mixing init.d scripts and native Upstart jobs, or what impact it had, maybe it was not important in practice.

The Debian wiki has this item, but, well, it's a Wiki, so perhaps it's not the most reliable source.

Can't set proper dependencies until everything has converted from SysV init files to Upstart jobs.

https://wiki.debian.org/Debate/initsystem/sysvinit

Re: Systemd, 10 years later (2020)

#293

Post by morelisp » Sun, Jan 09, 2022, 6:59 PM UTC

Blikkentrekker wrote: post #286

morelisp wrote: post #279

Earlier quoted context omitted.

> They did write the code to fork elongind in such a way that it no longer required systemd; they did write the code so that GNOME could run without logind like every other system; they did write the code to fork of udev from systemd again so that it could run without glibc. It sounds to me like the bazaar system is working fine qua its own standards, then. Red Hat writes what they need to solve their problems, party…

> It sounds to me like the bazaar system is working fine qua its own standards, then. Red Hat writes what they need to solve their problems, party X writes what they need to solve their problems, the code is shared, everyone gets what they want. The difference is that Red Hat's problem is not making enough money, and everyone's problem is software not working because Red Hat breaks functionality to make more money. R…

Describing systemd as "product tying" is ridiculous. The product is the OS distribution. Even in the heady days of a dozen of diverging Unix vendors, nobody was pitching their user-pluggable init system. What's next, coreutils and busybox are illegal, because I don't want my `cp` and `mv` from the same vendor?

Re: Systemd, 10 years later (2020)

#294

Post by posix_me_less » Sun, Jan 09, 2022, 7:03 PM UTC

awrmc wrote: post #282

posix_me_less wrote: post #274

Earlier quoted context omitted.

> Such a thing doesn't happen if the thing offered isn't an improvement over what was before. It does happen sometimes. GNOME3 and GTK3 didn't offer much to Linux desktop users, yet they were adopted. And improvement is subjective. Maybe systemd made maintainers' lives better. But it also introduced big nasty software full of bugs that discourages hacking by users. Many users consider that a deterioration of the Linu…

>GNOME3 and GTK3 didn't offer much to Linux desktop users, yet they were adopted. Are we thinking of the same thing? GTK3 had a much better theming system, new widgets, support for high DPI displays, improved rendering, support for animations, and a lot of other things. GNOME 3 had a much more streamlined design too. You may not have liked them but there were plenty of new features to offer. >I'll take wrestling a bu…

That was mostly feature expansion. I meant improvement of existing workflows. Maybe high DPI would count. I didn't have high DPI monitor back then, but those who did maybe were pleased.

Fixing a bug in shell script, even if 30 times, is still much easier than downloading, understanding modifying and compiling and deploying 4000 files and 1.6 million lines of systemd C code. There is an obvious cost/benefit factor here.

If systemd fixed just init and basic service management in correct and minimalistic way, maybe fixing its C code here and there by power users would be rational. Not with the ever-expanding pile of prototype-level software we got. I'm not reading that code, not even for money.

Re: Systemd, 10 years later (2020)

#295

Post by morelisp » Sun, Jan 09, 2022, 7:05 PM UTC

Blikkentrekker wrote: post #285

morelisp wrote: post #246

Earlier quoted context omitted.

This is a peculiarity of the GTK developers, not anything to do with systemd or fd.o. I maintained a popular GTK-but-explicitly-not-GNOME application long before the days of systemd and they had the same attitude.

I believe it is common to pretty much all Red Hat and Freedesktop developers. Poettering has come with very similar claims that betray that he does not understand what people outside of his small circle want and need, the same can be said for Wayland developers, DBus, NetworkManager, PulseAudio and all such other infamous projects.

If your problem is with the Red Hat developers, and the fd.o developers, and the GTK developers, and the Debian and Arch and SuSE and Ubuntu developers, and the DBus developers - maybe your problem is not actually with any of these developers but a mistaken idea of how open-source development ever worked?

Or what, is everyone except you under thrall to Lennart Poettering, master wizard?

Re: Systemd, 10 years later (2020)

#296

Post by usrbinbash » Sun, Jan 09, 2022, 7:06 PM UTC

posix_me_less wrote: post #274

usrbinbash wrote: post #251

Earlier quoted context omitted.

> the monoculture created by systemd systemd became the de-facto default init sys because Distro Maintainers have chosen it. I posted this link here before, but I will happily post it again: https://www.reddit.com/r/archlinux/comments/4lzxs3/why_did_a... Such a thing doesn't happen if the thing offered isn't an improvement over what was before. As a matter of fact, this doesn't even happen if the thing offered is onl…

> Such a thing doesn't happen if the thing offered isn't an improvement over what was before. It does happen sometimes. GNOME3 and GTK3 didn't offer much to Linux desktop users, yet they were adopted. And improvement is subjective. Maybe systemd made maintainers' lives better. But it also introduced big nasty software full of bugs that discourages hacking by users. Many users consider that a deterioration of the Linu…

> But it also introduced big nasty software full of bugs

If a bug happens in this code, everything is affected, everyone screams at the same time, it is obvious there is a bug, and once its fixed, its fixed everywhere and for every service.

If there is a bug in one of the old init scripts, it may go unnoticed for several years, until suddenly someone needs service Bar depend on Service Foo, but Bar cannot figure out the state of Foo correctly, and good luck to whoever has to solve this: unless the combination of services is a popular one, whoever has this problem, is likely the first to encounter this, there is no general outcry because nothing else is affected by it. A fix may not be forthcoming because the behavior may not even be considered a bug (the maintainers of Foo and Bar may simply disagree how some service state is to be communicated), and usually someone has to trawl through a pile of sh scripts (because backward compatible all the way to the 90s it has to be!) and implements a fix, which then gets destroyed by an update when the guy who fixed it is on holiday.

As someone who has been that exact guy, I have to say sorry but no, I don't want to do this any more.

Re: Systemd, 10 years later (2020)

#297

Post by awrmc » Sun, Jan 09, 2022, 7:25 PM UTC

posix_me_less wrote: post #294

awrmc wrote: post #282

Earlier quoted context omitted.

>GNOME3 and GTK3 didn't offer much to Linux desktop users, yet they were adopted. Are we thinking of the same thing? GTK3 had a much better theming system, new widgets, support for high DPI displays, improved rendering, support for animations, and a lot of other things. GNOME 3 had a much more streamlined design too. You may not have liked them but there were plenty of new features to offer. >I'll take wrestling a bu…

That was mostly feature expansion. I meant improvement of existing workflows. Maybe high DPI would count. I didn't have high DPI monitor back then, but those who did maybe were pleased. Fixing a bug in shell script, even if 30 times, is still much easier than downloading, understanding modifying and compiling and deploying 4000 files and 1.6 million lines of systemd C code. There is an obvious cost/benefit factor her…

>That was mostly feature expansion. I meant improvement of existing workflows

For desktop app developers? There were a lot of API refinements and enhancements to the widgets too, I didn't mention them all because there's far too many.

>4000 files and 1.6 million lines of systemd C

Just FYI these figures are incorrect, you're likely including the tests, documentation and data files. Running cloc on the current systemd code base I get around 2100 .c and .h files and 520,000 lines of C. That also includes all the other components too, not just the service manager. The service manager is a small fraction of that, it's only around 150 files including the headers.

>There is an obvious cost/benefit factor here.

From the perspective of a distribution I think it's much more cost effective for them to fix this once in C. To you what looks like just 30 shell scripts can quickly multiply into the thousands when you have to consider this is across all users of that distribution who might all have the same buggy set of 30 shell scripts but with different ad-hoc fixes applied.

>If systemd fixed just init and basic service management in correct and minimalistic way, maybe fixing its C code here and there by power users would be rational.

I think if you actually look at it, you'll find this is already what it does. That's what I saw when I actually took a few hours to familiarize myself with the code.

Re: Systemd, 10 years later (2020)

#298

Post by Nasreddin_Hodja » Sun, Jan 09, 2022, 7:37 PM UTC

awrmc wrote: post #283

Nasreddin_Hodja wrote: post #278

Earlier quoted context omitted.

> systemd became the de-facto default init sys because Distro Maintainers have chosen it. Because they were forced to choose it due to vendorlock and many other projects became dependent on systemd. Unsystemding everything would be very expensive. Same problem will be with snap and flatpak.

There aren't actually any projects dependent on systemd in any significant capacity. I don't know where that myth comes from but it's not true. Snap and flatpak are essentially just package managers, I can't see why you would expect those to be worse than any other package manager.

I heard that Gnome is dependent on systemd now.

> Snap and flatpak are essentially just package managers, I can't see why you would expect those to be worse than any other package manager.

Those are even worse than tarball bundles. Main purpose of both overengineered projects is to tie users to vendor's services (snapcraft, flathub, e.t.c.). Centralized delivery is outmoded, future is decentralized distributed distribution. Both package managers deprive me of control over my system. I don't like the aggressiveness with which these projects are enforced. When Let's Encrypt switched to Spat as the only official distribution of their tool, I had to switch to alternative tool acme.sh instead of installing bloated snapd on my server.

Re: Systemd, 10 years later (2020)

#299

Post by awrmc » Sun, Jan 09, 2022, 7:55 PM UTC

Nasreddin_Hodja wrote: post #298

awrmc wrote: post #283

Earlier quoted context omitted.

There aren't actually any projects dependent on systemd in any significant capacity. I don't know where that myth comes from but it's not true. Snap and flatpak are essentially just package managers, I can't see why you would expect those to be worse than any other package manager.

I heard that Gnome is dependent on systemd now. > Snap and flatpak are essentially just package managers, I can't see why you would expect those to be worse than any other package manager. Those are even worse than tarball bundles. Main purpose of both overengineered projects is to tie users to vendor's services (snapcraft, flathub, e.t.c.). Centralized delivery is outmoded, future is decentralized distributed distri…

>I heard that Gnome is dependent on systemd now.

Under some circumstances (not all), GNOME has a dependency on logind. If you're in one of those circumstances, you can use elogind as a drop-in replacement. That's far from having a dependency on systemd.

>Main purpose of both overengineered projects is to tie users to vendor's services (snapcraft, flathub, e.t.c.). Both package managers deprive me of control over my system.

I don't think snap lets you deploy your own repository, but for Flatpak this is very very wrong. Check here: https://docs.flatpak.org/en/latest/hosting-a-repository.html

Re: Systemd, 10 years later (2020)

#300

Post by Blikkentrekker » Sun, Jan 09, 2022, 7:55 PM UTC

awrmc wrote: post #288

Blikkentrekker wrote: post #285

Earlier quoted context omitted.

I believe it is common to pretty much all Red Hat and Freedesktop developers. Poettering has come with very similar claims that betray that he does not understand what people outside of his small circle want and need, the same can be said for Wayland developers, DBus, NetworkManager, PulseAudio and all such other infamous projects.

It's difficult to understand what your complaint is, that describes every software project I've ever seen. You pick a target set of users and then develop for those users. Is there some other way to develop software?

I don't think it is common to find memorable quotes akin to “I have no idea what XFCE is or does, sorry.” outside of this circle. This is a vintage and often quoted Red Hat-ism that betrays their mentality.

QT developers will not tell you “I have no idea what LXQt is or does.”; they do not generally break things that compromise 90% of their consumer base and they do not remove theming because they fear it's existence will hurt the “brand identity” of KDE.

It's dishonest to say similar problems occur outside of the Red Hat circle and that circle alone is commonly criticized on these policies.