Live data from Hacker News

Systemd, 10 years later (2020)

blog.darknedgy.net

191–200 of 332 posts

Re: Systemd, 10 years later (2020)

#191

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.

" For me and most users, the transition was fully imperceptible." So far. I hope for your sake it continues to be so.

'I am altering the deal, pray I do not alter it further.' --Darth Lennart

I actually appreciate, now, what systemd is trying to do, but I am not certain why it has to take over home directories and everything else to do it. And I am really uncertain why it has to have such bad taste. I can get why it uses C, even though IMHO that is a mistake. But .ini files? D-Bus? XML‽‽‽

Oh well, at least it's not YAML.

Re: Systemd, 10 years later (2020)

#192
post #115
post #112

Earlier quoted context omitted.

just like pentalobe screws! i'm not going to argue it's a bad thing, i actually really like macs and think they hide a lot of details making time and space for other pursuits, although since you cede user serviceability it's important to purchase a service plan and that you don't try anything that wasn't provided for in the design. maybe simple composable parts are past their prime. i always loved the simplicity of i…

> i always loved the simplicity of inetd. it was both self describing and inclusive. you could write an internet service without any knowledge at all of sockets and learn about the system by simply looking at it. You could achieve the same thing with systemd socket activation :)

> Which one would you trust to take you into space?

neither. last i checked, linux, even with rt_preempt, was unsuitable for realtime control applications.

even hollywood gets that, didn't you see the end of "don't look up"?

Re: Systemd, 10 years later (2020)

#193
post #113
post #46

The hatred for Systemd seems to come from those who see the unix philosophy of small, single use programs being thrown away in favour of a monolith. Back when I had linux as a desktop (around the day of slackware 10) there were plenty of problems with simple stuff like mounting usbs, connecting to wifi etc--possible but a pain. I've hardly looked at systemd or linux in such a way for a long time, however.

I don’t care about philosophy; I don’t like being forced and I don’t like opaque systems where they aren’t required. SystemD is essentially forced (for better or worse, not gonna argue) because it is a hard dependency for certain software and tightly integrated with other tools in the systemd ecosystem It is opaque because I cannot read, modify or understand what it’s doing without breaking out gdb, heaven forbid I w…

> It is opaque because I cannot read, modify or understand what it’s doing without breaking out gdb, heaven forbid I want to alter its behavior in a less than approved way.

In this respect I think that systemd is really a victim of the Unix kernel/shell style, where 'kernel' is read expansively to mean 'everything in C' and 'shell' is read to mean '/bin/sh'. The problem is that where shell is easily examinable and understandable for most technical folks, compiled C simply isn't (yeah, yeah, we all know someone who can debug in assembler; that guy ain't me).

It would have been nice to have had one system, with a typesafe compiled language. Scrutable, fast and safe. We have an example with emacs: one can always just M-. to a function's definition (even in the C core …).

It's a real pity that systemd hadn't been written in Common Lisp or some similar language.

Re: Systemd, 10 years later (2020)

#194

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.

> the transition was fully imperceptible

A normal user will never really link the features they see or do not see back to the init system. I'll draw a parallel with the worst subsystem being cut out of modern Linux - X Windows.

As far as I can tell Linux is missing good macro systems that can record actions taken by a user, then replay them. For loops for non programmers, basically. This isn't because the idea is radical, but because implementing the vision historically needed a programmer to understand X - which is too hard. There is a hidden link between the subsystem being awful and programs not existing.

Similarly, the monoculture created by systemd is influencing how the future of Linux evolves by making some things easier and others harder. End users won't be able to detect those influences though, and unlike X's problems systemd is likely a net positive. Systemd easily improves on the old init scripts.

Re: Systemd, 10 years later (2020)

#195
post #46

The hatred for Systemd seems to come from those who see the unix philosophy of small, single use programs being thrown away in favour of a monolith. Back when I had linux as a desktop (around the day of slackware 10) there were plenty of problems with simple stuff like mounting usbs, connecting to wifi etc--possible but a pain. I've hardly looked at systemd or linux in such a way for a long time, however.

Linux users tend to come up with whatever "philosophy" suits their agenda of complaining about all change. The unix philosophy gets thrown out the window as soon as it comes to Wayland which took a huge, bloated, and buggy Xorg and broke it down to something more sane and manageable.

Plenty of us who appreciate Linux and Unix are very, very worried about Wayland, which breaks a lot of things we have relied on and used for literal decades, and also seems to have some dubious lacunæ and misfeatures.

I am actually optimistic that in another dozen years or so Wayland might be pretty nice, but I certainly wouldn't consider it an examplar today.

Re: Systemd, 10 years later (2020)

#196
post #20
post #2

It's not as bad as at first feared. Views here are along the usual lines; for many when there's an issue either it's something that's fixable inhouse (init scripts) or needs a support contract. Having said that, personally (old school) I lost 2 or 3 hours yesterday due to not realising systemd was changing things I changed for a reason.

>I lost 2 or 3 hours yesterday due to not realising systemd was changing things I changed for a reason. This is one of my go-to reasons when people ask me why systemd is bad. Once it overrode power settings I had configured in xfce-power-manager. Mainly I wanted the lid close to do nothing on AC power and to sleep on battery. It started sleeping for everything after an update once. I think in the end I couldn't figur…

For the shutdown, do you use systemctl poweroff? If so, and you are sure that there will be no dataloss, you could use the --force parameter.

https://man7.org/linux/man-pages/man1/systemctl.1.html

Re: Systemd, 10 years later (2020)

#197

Earlier quoted context omitted.

I use archlinux as a daily driver, but it breaks far more randomly than gentoo ever did for me. Archlinux's bugzilla is full of random breakages that happen at random system updates. Here's a random python bug that been happening, cost me a couple of hours to debug and for now I don't update python until they get around fixing it[1]. The fix? Download an older python version(not too old since that would break everyth…

The official Arch stance seems to be "You should have read the blog before updating", and I enforce that by updating maybe 3 times a year at most. I think I'm just used to the installer. I like doing everything by CLI. Ubuntu is always trying to push something odd like Snap, and I think Xubuntu is defunct. The Ubuntu installers are very opinionated on what kind of desktop they want you to have. One of these days I'll…

> I blow up the rootfs once a year for full system updates.

My experience with Debian system updates have been pretty good; I don't think I have ever blown up my system through them. (when running stable)

Re: Systemd, 10 years later (2020)

#198

I miss Systemd inside Docker containers so much. IMO, for an app, "one-process per container" is a huge pain and very messy. I have a massively popular software to back up that claim: https://github.com/discourse/discourse_docker I use phusion/baseimage-docker[1] right now, love every bit of it. Having the database, web server(nginx) and the java backend all in one place works beautifully. The only pain point is havi…

Have you tried nspawn? Its part of systemd and integrates beautifully with the rest of systemd (for things like journald, networking, etc.) and is basically meant for what you requested.

Re: Systemd, 10 years later (2020)

#199
post #89

It’s tolerated because it was forced upon people by distros. I don’t know anybody who likes it, and I would happily rip it out if it wasn’t so much work to do so.

I like it. It's consistent, well documented, and has matured to the point where the last time I remember it getting in my way was probably 8+ years ago.

Re: Systemd, 10 years later (2020)

#200
post #135

Earlier quoted context omitted.

Agree to disagree. Maybe because I've worked in embedded Linux for so long (including on inits of various forms), but that description clearly articulates exactly what systemd is and does and I appreciate the direct, crystal clear technical language rather than some long form essay written assuming a clueless reader with 0 technical background.

You’re pulling my leg, right? The description could be improved, for starters, by forcing the author to not use the word “object.” That overuse alone makes me wonder if the description is satire. I expect everyone here commenting is familiar with systemd. I doubt very much that anyone who was unfamiliar with systemd and read that description would then have any idea what it does or how it works.

I mean, I'll agree with you in so far as that the wording could be improved further. But I do really, honestly think it's a good summary.

> I expect everyone here commenting is familiar with systemd. I doubt very much that anyone who was unfamiliar with systemd and read that description would then have any idea what it does or how it works.

It depends on what knowledge you expect. If someone is familiar with general init management and some programming concepts, this short summary will get them up to speed (and that's what I/we were arguing). If you grab a layperson of the street and read them this, it's obviously not going to tell them anything - but that's not the target audience.

What I value is a short summary which brings a reader, who knows the concepts and the space a software is operating in, up to speed quickly. And that's what this summary does.

Post reply on HN