Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Systemd, ten years later: a historical and technical retrospective

blog.darknedgy.net

Post reply on HN
Print view View original

251–260 of 458 posts

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

#251

Post by crazy_hombre »

ArchD wrote: post #40
throw0101a wrote: post #28

Earlier quoted context omitted.

> An init system is harder than it might seem at first […] systemd-as-init-system is not the problem. systemd-as-kitchen-sink is the problem. It's the tight coupling that annoys many people. Does udevd really need to be in the same repo? While there may be some nice things about journald, does it really have to be in the same source package? (And why can't it support remote logging with the industry standard syslog p…

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.

systemd isn't just an init system. It's a suite of tools that provides a system and service manager. It's not handling everything in one monolithic process. This has been said thousands of times before. I don't know why people don't get this.

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

#252

Post by JChase2 »

lawnchair_larry wrote: post #197
JChase2 wrote: post #105

Earlier quoted context omitted.

Slackware doesn't use it, and Patrick Volkerding recently got a Patreon account set up so Slackware 15.0 or 14.3 will hopefully be out soonish with updated packages. I'm writing this on 14.2 and have been running it since it came out with basically no issues. Also have it on a backup server, runs great.

But it’s 2020, and we need package management.

Use Alpine or something then. I use Alpine as well on a server, OpenBSD on a server, slackware on a server, slackware on my laptop... There's some options. We even use Devuan to host OP's essay, although we'll eventually move to openbsd probably for other reasons.

In terms of package management... why do you need it? I have no problem maintaining everything with slackpkg and sbopkg along with slackbuilds.org. Sometimes it takes a while to find all the requirements for an application and add them to a queue, but once it's set up it's just sbopkg, click on update, upgrade, and you're good. It's pretty much rock solid once I get everything installed and I haven't missed package management much at all. My main gripe is the old packages in 14.2 but -current has a lot newer stuff. I don't mind waiting though.

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

#253

Post by sjwright »

nine_k wrote: post #86

My beef with systemd is not its reinventing things. That part may actually be good. One problem is that a number of reinventions were poorly made. E.g. the log format. Yes, unstructured logs have a ton of drawbacks. Can we take some ridiculously well-tested, reliable embedded database or serialization format (like sqlite) and use it as log storage? Alas. Another problem is the "I know better" attitude. Are user proce…

> Another problem is the "I know better" attitude.

All good software is based on this attitude. Wait, I hear you interject. You have examples to disprove this. Well whatever it is you might think isn't the "I know better" attitude is probably just the same "I know better" attitude with one layer of abstraction.

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

#254

Post by phatfish »

xfs wrote: post #174
cycloptic wrote: post #141

Earlier quoted context omitted.

Sysvinit is still around, you can always go back to it if you really want. The package is even still in debian.

This is the kind of false argument being thrown around often in OSS discourse that ignores the structural power differential. Don't like it? Write your own/Leave. The fact is you can't go back to it as an individual, because the system has changed and as an individual you're powerless to change the situation at all, especially against an army of developers paid full-time. The latest news from Debian is sysvinit suppo…

Lennart and the systemd team did exactly that 10 years ago. Why can't you?

The code is there for someone with enough skill to show how bad systemd is right?

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

#255

Post by vidarh »

jcynix wrote: post #189
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

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; unlike /etc/procmailrc, the files in /etc/procmail-rcs/ will take on the user id of the user the file is named for, like $HOME/.procmailrc).

User crontabs on my system at least (Ubuntu) are in /var/spool/cron/crontabs/[username], not in $HOME anyway. I can't remember the last system I had with user crontabs in $HOME.

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.

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

#256

Post by erik_seaberg »

yawaramin wrote: post #33
ttctciyf wrote: post #9

As a somewhat dilettante and casual home sysadmin (currently) I was messing around with screen on a box downstairs and ran into this: https://www.reddit.com/r/programming/comments/4ldewx/systemd... Namely that systemd doesn't allow persistent processes started from the shell by default, preferring to terminate them when the user logs out. This would include processes like "screen" whose entire raison d'etre is to per…

That thread also mentions the solution that will work: https://askubuntu.com/a/904125 I.e., systemd-run --scope --user screen

This is severe scope creep for an init replacement. I don't exactly know what "the service manager of the calling user" is meant to actually do (that's way the hell outside POSIX), but if a user wants one they should be able to choose, and it shouldn't matter to them how the sysadmin chose to create routing tables and mount filesystems.

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

#257

Post by [deleted] »

tannhaeuser wrote: post #183
AnthonyMouse wrote: post #149

Earlier quoted context omitted.

The problem is not that sysvinit doesn't exist, it's that other packages now have dependencies on systemd, so it doesn't just swap out.

Exactly, and to prevent this from happening is what Devuan is all about (as I'm sure you know): to keep all the maintenance work going into Debian, while remaining mostly bullshit-free. It's what I'm about to be installing after a decade on the Ubuntu desktop. The recent snap fiasco is just the final nail in the coffin. The trifecta of SystemD, Gnome3, and SnapD means that I can just use Windows with WSL if I wanted…

[deleted]

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

#258

Post by sjwright »

pmlnr wrote: post #204
realusername wrote: post #136

Earlier quoted context omitted.

Sqlite is battle-tested though, it has one of the most comprehensive test suite and is used on billions of devices already. What systemd is doing with this log storage system is reinventing sqlite, because systemd has a fairly new and not battle-tested database implementation, it has shortcomings. I would argue that either they use plain text logs like before or use sqlite but they should not reinvent a new db.

Systemd is the very manifestation of NIH and reinvention, they are incapable of using existing tech.

Go back to the horse and cart then. Our fancy horseless carriage is just a reinvention of existing tech.

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

#259

Post by andor »

lmm wrote: post #176
thristian wrote: post #91

Earlier quoted context omitted.

The trouble is that 'nohup' is not a particular state that specifically marks processes that want to survive logout. Instead, the rule is that processes running inside a particular terminal are killed when that terminal closes, and processes running outside any terminal run as they please. If you SSH to a server, or telnet, or login on the text console, or via a serial port, you get a terminal and everything you run…

> Since the kernel's idea of "a login session" is wrong (it only includes text-terminals), and it can't easily be changed for compatibility reasons This is a CADT attitude. Improving existing interfaces while maintaining compatibility is hard; it's also what makes the difference between a serious software professional and an incompetent vandal.

I agree it would be nice to fix this in the kernel instead, but as the article said, it might not be possible due to compatibility constraints.

The fact that the logind developers came to a different solution than you, after spending much more time thinking about it and actually implemented it, doesn't exactly imply logind developers are the ones with an attention deficit, or that logind is bad. ("CADT" apparently means "Cascade of Attention-Deficit Teenagers")

Also, never call out others as "incompetent vandals" if you think of yourself as a "serious software professional". This is the kind of toxic behavior that makes communities non-inclusive and leads to impostor syndrome.

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

#260

Post by sjwright »

AnthonyMouse wrote: post #142
sneak wrote: post #118

Earlier quoted context omitted.

It's astounding to me the issues people have with this. systemd's existence doesn't preclude anyone from using the old, pre-systemd ways of doing things. There are thousands of linux distributions, and afaik there are at least a dozen which are primarily defined as never-using-systemd. Face it: the linux userspace has always sucked. Linus punted on it way-back-when (to be fair, he was a solo dev working on a kernel,…

> Traditions are not always inherently valuable. Try new things. Discard the ones that don't work for you. But that's the trouble. The people who make systemd keep integrating it with everything else they make and vice versa, which makes it harder to try new things because instead of things coming in pieces you might replace, it comes as one big interdependent blob.

One big interdependent blob? Sounds like the Linux kernel to me.
Post reply on HN