Live data from Hacker News

Systemd, 10 years later (2020)

blog.darknedgy.net

91–100 of 332 posts

Re: Systemd, 10 years later (2020)

#91
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.

Network configuration (on say, Debian) is still a pain and has a lot of different ways of accomplishing similar tasks. Anything beyond the plain vanilla singular network device that is either dhcp/static is often painful. Systemd has some sauce, there is legacy /etc/network* stuff, there are daemons which can be configured graphically… it’s still a mess. In this arena, I think systemd has failed for the last decade.…

Yes, this. The problem with systemd isn't systemd. It's that it never really replaced the other "legacy" parts effectively. Networking is a fantastic example. I'd be OK if there was one-definitive-place to configure networking, but when I read an article or follow a stack-overflow post, I'm not sure if what I'm changing is the most correct change or if its deprecated in favor of something newer. Systemd, I thought, would help settle this problem, but instead has only contributed to it.

Re: Systemd, 10 years later (2020)

#92
".... and found that someone was about to release TCP/IP for Linux" (Fred van Kempen, linked interview 1992)

Wow. I had forgotten how ropey early Linux was. I mean, I rip on Windows folk about early versions of Windows prior to 98SE or NT4 (and can recall having to install Winsock on a home Win95 install and thinking why the hell????) but finding out 30 years later that my early struggles with Linux were not entirely down to my own incompetence is ... refreshing. I mean how do you Google (ok in those days Altavista!) a "how to" if the network stack is borked? How do you even download the drivers or updates if the interface fails to come up?

It sounds silly but I'm so glad to know it wasn't something I was doing wrong on my end. 30 years later and dayamn!

Re: Systemd, 10 years later (2020)

#93
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.

Part of it was political, but it was also just practical. Poettering's designs are some of the worst for usability I've ever seen. They technically work, but you need a million StackOverflow Q&As to figure out how to get anything done or solve the many common problems.

It's like somebody decided that the problem with Linux was it wasn't complicated enough. And then everbody just went with it.

Re: Systemd, 10 years later (2020)

#94
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.

Of course, but I would not like to have to patch it to modify something that on other systems can be modified with either a configuration option, or a shell script. To me, the most poisonous example that contrasts the traditional design with Freedesktop's design is acpid contrasting logind. In the former case, an acpi event is sent, and acpid simply executes a file such as `/etc/acpi/action/lid_down.sh`. That file ca…

Although I like the acpid approach, the logind way is probably safer to abstract behind a user friendly GUI. That's what most people will be using. :-/

Re: Systemd, 10 years later (2020)

#95

This was an amazing review, and love systemd or hate it, this article gives a fantastic history and exposition of what systemd actually is . My favorite quote (and when taken in context is much less tongue-in-cheek thank you might think): systemd is an event-driven object manager with dependency-like side effects which ‘boxes’ primitive kernel resources and userspace subsystems into a generic object type called Unit.…

...so, how does a systemd unit definition differ from a Makefile (other than using a different syntax, obviously)? What features would you need to add to UNIX make (and PID 1, for that matter) in order to be able to separate out this whole dependency management business from the other stuff PID 1 has to deal with already?

My devuan linux desktop says something like this on each boot:

INIT: version 2.88 booting

Using makefile-style concurrent boot in runlevel S.

Re: Systemd, 10 years later (2020)

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

The transition period of any new tech is usually horrid.

But now that things aren't buggy, being unable to modify them in place is a good thing. It sets a clear boundary that this is not how you do things on a modern system, so you can always expect systemd to be the same, consistent, non customized thing it always is.

Re: Systemd, 10 years later (2020)

#98

Earlier quoted context omitted.

It reads like an over-eager developer read Design Patterns and then was tasked with writing a new init system for Linux.

His name is Lennart Poettering, and apparently he was tasked with reinventing the entire operating system

Quite true, and he was coerced!

http://systemd-the-porno.com

Re: Systemd, 10 years later (2020)

#99

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…

Did you check the linked bug and its suggested workaround? It's nothing an update note would address. It's just random breakage. There are a lot of these issues scattered across their bugzilla.

Re: Systemd, 10 years later (2020)

#100

https://www.reddit.com/r/archlinux/comments/4lzxs3/why_did_a... quote: "What most systemd critics consider "bloat", I consider necessary complexity to solve a complex problem generically. " endquote

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…

> Download an older python version(not too old since that would break everything else) from the arch package archive.

Unless you explicitly disabled it, you should have old packages archived in `/var/cache/pacman/pkg`. So you can simply downgrade via `pacman -U /var/cache/pacman/pkg/python-x.y.z`; no need to go to an (possibly untrusted) archive.

Post reply on HN