Live data from Hacker News

Systemd, 10 years later (2020)

blog.darknedgy.net

231–240 of 332 posts

Re: Systemd, 10 years later (2020)

#231
post #172

Earlier quoted context omitted.

The situation is that such hackers and tweakers rarely use systemd, for these reasons. They are simply annoyed by A) it being pushed on them; B) people often acting that they are irrational for not liking it while it does not what they expect and need; and C) discussions with Freedesktop developers that, frankness be, reveal they live inside of a very strange bubble and have no idea of the use cases outside of it. Th…

I'm an open source hacker and I like systemd. Once I took the time to learn its APIs I found it does everything I expect. Your issues with XFCE and libinput don't seem to be related to systemd. I can't see how airing grievances against other unrelated projects would be a constructive place to take this discussion. Complaining about open source projects only supporting some use cases is also confusing to me. A lot of…

I have no issues with XFCE. I personally would never use i, but it also leaves me alone and it's developers don't exhibit this mentality.

I have a problem with Jon McCann's famous quote, who was at the time a lead developed of GTK+, who did not know what XFCE, one of the biggest consumers of the library, even was when he made a change that broke about anything outside of GNOME. — What his language suggested was that he lived in a bubble thinking that only KDE and GNOME existed, and that since KDE wasn't using GTK+ it was fine to do this.

Re: Systemd, 10 years later (2020)

#232

The systemd "culture war" is just a side-effect of the hegemony server Linux enjoys over desktop Linux. A very small percentage of sysadmins really care about what init system is running on their servers. If you look at who's forking distros and making systemd-free variants, and look at who the vocal anti-systemd users are, they're overwhelmingly desktop-focused users. But this is strange because desktop Linux barely…

Vehement systemd defence also overwhelmingly comes from hobbyists who have no real use for an init system anyway. In fact, this whole argument is crap, most hatred of sysvinit comes from people who have never used it, is that a reason to discard all criticism of it? Of course not.

I have had enormous issues with systemd, not when using it for desktop purposes, but precisely when using it for server applications.

As an example, systemd can't handle a service which depends on a specific network interface (or specific bind address) before being brought up and the systemd developers blame the software for not listening to rtnetlink events or not relying on linux specific socket options[0]. This is unacceptable, it makes it incredibly difficult to run systemd on hosts connected to multiple segregated networks without lots of dirty tricks involving firewalls.

[0]: https://www.freedesktop.org/wiki/Software/systemd/NetworkTar...

Re: Systemd, 10 years later (2020)

#233
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 up. dbus is the most hideous protocol and most hideous library, its ONLY advantage is its ubiquity.

Re: Systemd, 10 years later (2020)

#234
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…

Yep. Sounds like we went down pretty much exactly the same path. I came to the same conclusion after attempting the same thing.

Re: Systemd, 10 years later (2020)

#235
post #12

Systemd pissed off many people. For me and most users, the transition was fully imperceptible. With the difference that systemctl tools seem to work better for what it does than the many sparse different tools it replaced.

it's kind of like locked bootloaders and pentalobe screwdrivers for organizing a unix system where most users were used to easy to inspect and modify scripts and single purpose programs . yes, it's still open source, but modifications and inspection are far more complicated creating a much higher barrier to entry. in the earlier days when it was still buggy, even linus himself was screaming about not being able to ea…

System boot is a hard problem with dependency resolution, service management, etc. Scripts didn’t properly solve the problem — they were like the easy solution for small ns. But that approach simply could not scale at all.

Systemd may indeed be somewhat more complex, but I don’t think that it would employ many accidental complexity— it is complex due to the problem domain. But imo that is a worthwhile thing to spend complexity budget on.

Re: Systemd, 10 years later (2020)

#236
post #45

Earlier quoted context omitted.

It's not like systemd is written in deliberately obfuscated C or something inscrutable altogether like Brainfuck. A monorepo containing well-organized boring C, developed on github of all places, is the polar opposite of raising the barrier to contributing vs. what was replaced. Full-disclosure: I contribute to systemd.

There is a difference between the best C, and scripts that you can modify in-place. But, like some other comments have said, I was young enough to dodge the drama. I basically grew up with systemd and I don't feel like I'm missing anything. The biggest problem I have is that Ubuntu Server defaults (or used to default) to having the system wait on network interfaces, which is annoying when I want to build a desktop of…

You can configure systemd to kill lingering applications, it was defaulted to false because some old UNIX tools liked to linger in the background forever.

Re: Systemd, 10 years later (2020)

#238
post #12

Earlier quoted context omitted.

it's kind of like locked bootloaders and pentalobe screwdrivers for organizing a unix system where most users were used to easy to inspect and modify scripts and single purpose programs . yes, it's still open source, but modifications and inspection are far more complicated creating a much higher barrier to entry. in the earlier days when it was still buggy, even linus himself was screaming about not being able to ea…

Right. I have a simple rule: don’t use a GNU/Linux system that uses systemd. It doesn’t respect the Unix philosophy. It’s trying to turn it into Windows. I’m waiting for Microsoft to buy Red Hat. Failing that, IBM.

Linux the kernel doesn’t respect the Unix philosophy either by a huge margin. Also, Unix philosophy is not even the Saint script — it can be good for some problems but terrible for others. In certain cases a distributed between 34 small programs is just a worse approach that will be bug prone and hard to test.

Re: Systemd, 10 years later (2020)

#239

Systemd pissed off many people. For me and most users, the transition was fully imperceptible. With the difference that systemctl tools seem to work better for what it does than the many sparse different tools it replaced.

I like systemd, but I abhor the arrogance and manouvering with which is was pushed.

You mean the completely democratic vote done multiple times by Debian?

Re: Systemd, 10 years later (2020)

#240
post #26

I am old enough to remember that problems with systemd were less technical and more political. People didn't like the way systemd developers pushed the community to adopt systemd, specially when they asked for 3rd party developers to make systemd a hard dependency. Unfortunately,people don't remember this today, and think users resisted to systemd adoption only because they didn't like systemd.

> systemd developers pushed the community

[citation needed]

I remember spending days reading the arguments on the Debian mailing list. There was no push from systemd devs. (Endless threads about upstart, how tweaking upstart would solve everything and it's already in Ubuntu, and a lots of questions about guarantees. Are openrc/upstart/systemd maintainers willing to guarantee this or that? And as far as I remember, there were no guarantees, obviously.)

Before that when the hwdb and udev merged into systemd, people got the pitchforks out, it was the decision by Kay, but obviously "systemd devs" were somehow behind it.

When Greg KH supported kdbus, somehow it was again those meddling systemd devs.

Somehow OSS veterans just lost their agency overnight and became puppets? Nah.

Post reply on HN