Systemd, 10 years later (2020) • Hacker News Board

Re: Systemd, 10 years later (2020)

#111

Post by yonrg » Sat, Jan 08, 2022, 10:28 PM UTC

ReactiveJelly wrote: post #59

rjzzleep wrote: post #34

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…

Arch user here since 2013 on my mobile systems. I do -Suy nearly every day, which causes me nearly null troubles. My experiences with any supported enterprise distro are much worse.

Re: Systemd, 10 years later (2020)

#112

Post by a-dub » Sat, Jan 08, 2022, 10:30 PM UTC

eternityforest wrote: post #96

ReactiveJelly wrote: post #50

Earlier quoted context omitted.

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.

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 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. but i suppose that's given way to large monolithic daemons these days.

personally though, i always thought the simplicity and the composability of unix philosophy was what bred systems that outperformed their competition in terms of security and extensibility. so many commercial systems reflected apparent power grabs within the corporate structures that produced them... i suppose that when you see foss monoliths like this, it's the same game playing out on a different field.

Re: Systemd, 10 years later (2020)

#113

Post by dijit » Sat, Jan 08, 2022, 10:30 PM UTC

tarkin2 wrote: 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 want to alter its behavior in a less than approved way.

This leads to weird situations like the MySQL unit executing a bash script to run: because systemd has limited preflight checking compared to alternatives.

Before someone claims I want sysvinit back: No, I don’t want that. I would simply prefer systemd to be smaller so that we can replace it with something better or more tailored should the need arise.

We’re locking ourselves in to prototype level software (which we best into working semi decently) with obstinate leadership team who deny any faults.

Re: Systemd, 10 years later (2020)

#114

Post by topspin » Sat, Jan 08, 2022, 10:32 PM UTC

tracnar wrote: post #80

zodiakzz wrote: post #54

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…

Podman supports running systemd units inside containers: https://developers.redhat.com/blog/2019/04/24/how-to-run-sys... One process per container is indeed strange in a lot of use cases, you lose the self-contained advantage of a container...

Thank you for that link. That is eye opening.

Re: Systemd, 10 years later (2020)

#115

Post by shawnz » Sat, Jan 08, 2022, 10:37 PM UTC

a-dub wrote: post #112

eternityforest wrote: post #96

Earlier quoted context omitted.

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.

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 :)

Re: Systemd, 10 years later (2020)

#116

Post by arendtio » Sat, Jan 08, 2022, 10:38 PM UTC

rlonn wrote: post #57

ratorx wrote: post #42

Earlier quoted context omitted.

I’m a fan of this description. It might not be the easiest to understand or the first one you should read, but I wish more things had this kind of description somewhere (but not necessarily on the introductory materials or front page).

It’s buzzword bingo with the aim to inflate the writer’s ego and intimidate the reader. This stuff happens all the time when insecure people get to write things.

It uses many well defined technical terms like:

- event-driven

- object

- side effects

- kernel resources

- userspace

- subsystems

- unit

- scheduled

- state propagation

- dispatched

- singleton

- merging

- cyclic ordering

- consistency checks

- dependencies

- non-idempotent

- weak ordering guarantees

And while this list is good for BS Bingo, as these terms are being used in other contexts too, the overall description of what systemd does is pretty precise for just three sentences.

Re: Systemd, 10 years later (2020)

#117

Post by generalizations » Sat, Jan 08, 2022, 10:39 PM UTC

It would be interesting to see Systemd compared to other modern init systems, like runit and the FreeBSD init. Seems like 2021 Systemd is being mostly compared to 2000's Upstart and Sysvinit.

Re: Systemd, 10 years later (2020)

#118

Post by [deleted] » Sat, Jan 08, 2022, 10:39 PM UTC

ratorx wrote: post #74

rlonn wrote: post #57

Earlier quoted context omitted.

It’s buzzword bingo with the aim to inflate the writer’s ego and intimidate the reader. This stuff happens all the time when insecure people get to write things.

Which words do you think are buzzwords in the description? What I think of by buzzwords are things like “Blockchain”, “Machine Learning” etc. which are generic topics used to build hype whilst not really explaining anything. In this case however, the words are all fairly precise and accurate (at least from my basic understanding of systemd). They might not be words used in everyday conversation, but they don’t need t…

[deleted]

Re: Systemd, 10 years later (2020)

#119

Post by INTPenis » Sat, Jan 08, 2022, 10:40 PM UTC

marcodiego wrote: post #3

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.

This is the comment I came to upvote and agree with.

I am considered a Linux expert in my field but the truth is that I really don't know how systemd internals work well enough to read that review and fully understand it. The review did teach me some things about what Units really are, more than just services and timers, but other than that it was too deep for me.

And yet I work full time with Linux systems, building services on Linux systems for major clients and government contracts.

From my perspective as a user and operator of Linux, systemd has been nothing but good things.

Re: Systemd, 10 years later (2020)

#120

Post by hedora » Sat, Jan 08, 2022, 10:40 PM UTC

MuffinFlavored wrote: post #49

klysm wrote: post #8

Earlier quoted context omitted.

I’m young enough to have missed the transition and really like systemd, I rely on it for as much as I can

Like what if you don't mind me asking, and what did people used to use as an alternative?

Take a look at OpenBSD. They managed to sidestep all this drama, and still ship a sane, well-documented init.

If you spend an afternoon installing it and configuring a few network services, you’ll already know most of what there is to know about how init used to work.

It used to be extremely elegant and robust.

The main flaw in the design was that the “service” files were written in a Turing complete language, which meant that distribution maintainers could ship things that were arbitrarily terrible, and many chose to do so.

(Edit: Also, the organizations that somehow couldn’t figure out how to use and maintain traditional init systems were the ones that produced the current generation replacements and pushed them so hard.)