Systemd, ten years later: a historical and technical retrospective • Hacker News Board

Re: Systemd, ten years later: a historical and technical retrospective

#361

Post by cycloptic » Mon, May 04, 2020, 2:53 PM UTC

lmm wrote: post #348

cycloptic wrote: post #331

Earlier quoted context omitted.

>Since they all follow common standards, any program works with any environment.... If the systemd people want to make a shiny new init with cool features, great. It's when they break compatibility with alternatives that I have a problem with it. That is not relevant because the "common standard" in this case is the logind D-Bus API. There are no other active and viable alternatives to login management. It has two im…

> That is not relevant because the "common standard" in this case is the logind D-Bus API. There are no other active and viable alternatives to login management. It has two implementations, systemd-logind and elogind. You can choose either one, and only the first one requires systemd. Is there any commitment to treating those as stable interfaces, with a decent deprecation cycle around any incompatible changes? If so…

It appears they have marked the Logind API as being stable because it is intended to be used by the display server and by the DEs. I don't have any secret information here, I just saw this chart on their website. https://systemd.io/PORTABILITY_AND_STABILITY/

About BSD and non-systemd systems: I actually think it is possible for there to be better compatibility here eventually if someone builds more shims. BSD using Mesa for example is a really good thing for everyone. However FreeBSD and Linux have both refused to budge for quite a long time on various things and cgroups seems to have been the final nail in the coffin for any kind of expectation of modern cross-platform tooling. Everything now is container this, container that. The only non-systemd init that hasn't dragged their feet on this has been OpenRC, and even they still would not make any effort to be systemd-compatible because of objections over other things. So what is the solution here? Do you see how hard it even is to get people to run something like elogind on top of another init with another cgroup implementation? I don't blame the systemd developers for not bothering with that. It is not feasible to expect them to maintain everyone else's init as well as their own.

I checked the systemd contribution graph and it seems they have a large number of smaller contributions from outside developers, so the data does not really support your assertion about it not being worth it. https://github.com/systemd/systemd/graphs/contributors

Also, just going by the data, the repos for KDE (collectively) and FreeBSD (a monorepo, like systemd) are much, much bigger, just as tightly-coupled if not moreso, and get a lot more activity than the repo for systemd. It seems strange that you would pick those projects to contribute to.

Re: Systemd, ten years later: a historical and technical retrospective

#362

Post by tux1968 » Mon, May 04, 2020, 3:04 PM UTC

aganame wrote: post #123

dman wrote: post #101

Earlier quoted context omitted.

As a person who does not work as a system administrator professionally but does use self administered linux machines as workstations systemd has not brought any new productivity gains but it sure has increased the learning curve.

As a person for whom Linux and BSDs have been a hobby since 1996, I have no idea what you're talking about.

One small example that i've struggled with is logging. It used to be I could reuse my editor knowledge to search and read log files. Now every time I want to look at a log I have to re-read the man pages to figure out the proper incantation.

Re: Systemd, ten years later: a historical and technical retrospective

#363

Post by SQLite » Mon, May 04, 2020, 3:08 PM UTC

growse wrote: post #359

realusername wrote: post #357

Earlier quoted context omitted.

I don't agree with that argument, sqlite is totally the right tool for the job, it provides consistency, reliability, an api you can query anything upon, transactions, indexing, tools... And fits into files. You currently can't trust systemd log storage at all, even on my own laptop it manages to have some corruption... Querying is very poor and inefficient, indexing is unreliable... And that's exactly what I expect,…

SQLite doesn't work reliably on NFS, which rules it out for any PXE-booted system with an NFS root.

The issue with NFS and SQLite is that posix advisory locks do not work, or do not work well, on many NFS installations. As long as advisory locks work over NFS, or as long as there is only one client trying to access the database at a time, so that locks are not really needed, SQLite works fine over NFS. NFS is a lot slower, but that's just the nature of NFS and SQLite can't do anything about that.

You can ask SQLite to use dot-file locking instead of posix advisory locking. Or you can ask it to simply ignore locking all together. In both cases, SQLite will work on even a broken NFS system, though with the corresponding concurrency limitations.

Re: Systemd, ten years later: a historical and technical retrospective

#364

Post by cycloptic » Mon, May 04, 2020, 3:09 PM UTC

vezzy-fnord wrote: post #353

cycloptic wrote: post #349

Earlier quoted context omitted.

Sorry for the glibness I am just really bored with these complaints, it really feels like the same old bikeshedding. As far as I know there is no way to make a transactional state machine without having the concept of a single, reordable work unit. Daemontools did not solve this or present a different model that was more workable. For every developer that rewrote their daemon to get rid of forking, we got more new de…

> As far as I know there is no way to make a transactional state machine without having the concept of a single, reordable work unit. You're basically taking systemd's architecture as an axiomatic premise, so no surprise your conclusion is obvious. I reject the premise, and the fruits of it I go into detail in chapter 3. For the record I am mostly a Unix-hater, so your complaints about Unix are things I agree with. s…

No I am not commenting on systemd or Linux at all. The fact is that if you implement a dependency graph, you must track and resolve state. There is no way around this. Add in support for event listeners and one-shot syscalls out to hardware (because remember, udev or some equivalent is still a critical piece in all this and there is no HAL to handle this for us) and now you have to deal with transactions. Try to parallelize it and now you have work units. That's the way it goes. Even in microkernels you will find all these things scattered around and they aren't going to be less painful just because you wrote them in eBPF. I liked the third chapter but it left me a bit disappointed because it didn't mention anything other than a critique of the wrong way to do it.

Re: Systemd, ten years later: a historical and technical retrospective

#365

Post by esarbe » Mon, May 04, 2020, 3:18 PM UTC

rleigh wrote: post #159

dralley wrote: post #132

Earlier quoted context omitted.

One of the reasons distributions appreciate systemd because systemd unit files are easy to write and can easily be written and maintained upstream and used with very few if any modifications downstream. Your average HN user doesn't see or particularly care that it makes things easier for distro maintainers, so it's much easier to push the corporate conspiracy angle than to accept that a lot of the hand-wringing takes…

This is one thing which is often claimed, but to my mind is poorly justified. As a (Debian) package maintainer for over a decade, this used to be a non-issue. They were write and forget. The average package was just some simple boilerplate.

I love not having to maintain half a dozen init scripts for three distributions but just one unit file for a well defined service manager.

Re: Systemd, ten years later: a historical and technical retrospective

#366

Post by throw0101a » Mon, May 04, 2020, 3:24 PM UTC

kuschku wrote: post #249

blibble wrote: post #96

Earlier quoted context omitted.

> So, for the simple act of logging in, three mechanisms are required (systemd, /etc/shadow, /etc/passwd). This is inefficient, and Poettering has decided to make a drastic change. That change is homed. With homed, all information will be placed in a cryptographically signed JSON record for each user. 10 years ago this would have been considered satire

homed is a purely optional, independent tool, for use in situations where you’d use roaming home directories on windows, or similar technology. No one is forcing you to change your broken buggy 30-year old shell scripts, you can always continue using them.

> No one is forcing you to change your broken buggy 30-year old shell scripts, you can always continue using them.

How about usernames that start with a digit? Am I still allowed to use those?

* https://ma.ttias.be/giving-perspective-systemds-usernames-st...

Re: Systemd, ten years later: a historical and technical retrospective

#367

Post by throw0101a » Mon, May 04, 2020, 3:29 PM UTC

vidarh wrote: post #255

jcynix wrote: post #189

Earlier quoted context omitted.

This must be satire, not? Because soon my .forward won't work, my .procmailrc won't work, my crontab scripts won't (etc pp) unless my encrypted home directory (planned to be decrypted on login) is decrypted. Or all these are moved to other locations.

Or you opt to not encrypt your home separately. But how large a proportion of machines do you think have mail delivery rely on .forward or .procmailrc in $HOME these days? In any case, procmail can be executed directly rather than from .forward in most cases, and can be configured to take the rc file to be a file in /etc/procmail-rcs/ as an alternative to $HOME/.procmailrc (at least the version of procmail in Ubuntu;…

> But how large a proportion of machines do you think have mail delivery rely on .forward or .procmailrc in $HOME these days?

I help run a 500 node HPC cluster that leverages procmail. Do I count?

> User crontabs on my system at least (Ubuntu) are in /var/spool/cron/crontabs/[username], not in $HOME anyway.

The crontab(5) may be there, but where is the script that is actually executed? Probably in $HOME/scripts/ or some such.

> People have had systems where relying on accessing the home directory of a logged out user has been undesirable or impossible for a very long time.

I have daily experiences indicating otherwise. I would hazard to guess that many other syadins in academia & research would agree. Even assuming $HOME is in /home breaks a bunch of stuff:

* https://utcc.utoronto.ca/~cks/space/blog/linux/Ubuntu2004Sna...

Re: Systemd, ten years later: a historical and technical retrospective

#368

Post by throw0101a » Mon, May 04, 2020, 3:32 PM UTC

Spivak wrote: post #48

ArchD wrote: post #40

Earlier quoted context omitted.

Yeah, don't get me started on the fragile glass test tube called systemd-resolved that fails in mysterious ways when I use wicd on Ubuntu and the WiFi gets momentarily disconnected. I don't see the sense behind treating name resolution as something so special that it has to be part of an init system. I like the overall theoretical concept of systemd but it has ugly implementation details like this.

But systemd-resolved is such an odd complaint since it’s only connection to systemd is the name and that it’s in the same repo. It’s not connected to the init system at all.

> [...] and that it’s in the same repo. It’s not connected to the init system at all.

And that's exactly the problem.

For all the complaining I do about systemd, I'd be much less annoyed with it if all it did was PID 1. It's all the other stuff that gets tightly coupled for no discernibly-good reason that poisons the well for me.

Re: Systemd, ten years later: a historical and technical retrospective

#369

Post by tpoindex » Mon, May 04, 2020, 3:37 PM UTC

Karunamon wrote: post #99

cmeacham98 wrote: post #32

Earlier quoted context omitted.

This is such a classic example of the type of argument I see from most anti-systemd proponents that it made me laugh out loud when I clicked your link. For the lazy, here's the context of that cherry-picked sentence: > In order not to break screen we currently do not set kill-user=1 or kill-session=1. > Note that in some cases it might be a good thing to kill screen sessions when the user otherwise logs out (think un…

My argument is remarkably simple. 1. Systemd did not solve any problems I actually had. 2. Systemd introduced problems that I did not have previously. 3. Systemd did not provide me any net benefit, that is, the few benefits it did provide over Upstart/SysV/etc. (easier service configuration and ordering) did not overshadow the issues it caused. Its introduction into my home and professional computing life has been a…

This, exactly.

My first experience with SystemD (Ubuntu 16.04 IIRC) turned into a frustrating experience, mostly around trying to mount a NFS volume in /etc/fstab, defined with 'soft' and 'bg' mount options. SystemD would often fail to mount the volume, and as a result would never fully boot to login prompt. Additionally, on shutdown SystemD would hang again forever trying to unmount that volume. No amount of mount option flag tweaking seemed to make much of a difference, so I simply removed the NFS volume from fstab and manually mounted when I needed it.

Happily running MX Linux today and back to mounting NFS in /etc/fstab.

Re: Systemd, ten years later: a historical and technical retrospective

#370

Post by bkor » Mon, May 04, 2020, 3:46 PM UTC

lmm wrote: post #348

cycloptic wrote: post #331

Earlier quoted context omitted.

>Since they all follow common standards, any program works with any environment.... If the systemd people want to make a shiny new init with cool features, great. It's when they break compatibility with alternatives that I have a problem with it. That is not relevant because the "common standard" in this case is the logind D-Bus API. There are no other active and viable alternatives to login management. It has two im…

> That is not relevant because the "common standard" in this case is the logind D-Bus API. There are no other active and viable alternatives to login management. It has two implementations, systemd-logind and elogind. You can choose either one, and only the first one requires systemd. Is there any commitment to treating those as stable interfaces, with a decent deprecation cycle around any incompatible changes? If so…

> I saw patches submitted and rejected on the grounds that the project leadership had no interest in supporting non-systemd

What do you mean with project leadership. If someone submits a patch, the maintainer(s) of the git module can obviously reject it if they don't want to maintain it. Unless they're persuaded because it's better for the project as a whole.

However, you talk about "project leadership". That doesn't really exist. There's loads of maintainers. There's a GNOME foundation, which mostly handles admin stuff, sysadmin stuff, etc. There's a release team. They ensure the various maintainers make releases, plus verify stuff actually builds.

If you help out in GNOME you're just a person in a big group of people. There's not really any "leadership", just loads of people who often agree, sometimes disagree, etc.