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

Avoiding Complexity with Systemd

mgdm.net

Post reply on HN
Print view View original

31–40 of 357 posts

Re: Avoiding Complexity with Systemd

#31

Post by dagw »

jbverschoor wrote: post #23
dagw wrote: post #22

Earlier quoted context omitted.

Service and runlevel management wasn't any better in the sysv era, nor were any of the multitude of custom start and boot scripts. They might not have been better or more robust, but they where easier to understand and reason about. You could explain the entire thing to the most junior of sysadmins in a few minuets, tell them to read the boot scripts, and they would basically understand how everything worked.

Really? Have you ever written init scripts for a hand full of services for your typical saas application? It’s always been a mess, and I’m very happy systemd was copied from / inspired by Apple’s launchd.

I'm not saying it was necessarily easier to use, just easier to understand what was going on. Explaining step by step how a Unix systems started up used to be trivial and make sense. I don't hate systemd, I just don't understand it. But that could also be symptom of me being old.

Re: Avoiding Complexity with Systemd

#32

Post by kbumsik »

midasuni wrote: post #13
Dinux wrote: post #10

I'm glad to see more people sway to systemd. Systemd is 10 years in the making and it was met with skepticism right from the first day. Some of that is now slowly changing with systemd being accepted in more and more distributions. Service and runlevel management wasn't any better in the sysv era, nor were any of the multitude of custom start and boot scripts. I remember when it took multiple days testing the configu…

For people who had well working low maintenence environments, systemd came in and changed everything - breaking things, requiring changes to get things working again. Its not just breaking init.d scripts, it’s ntp, dns, syslog. Systems throughout the OS fail to things that were no longer short commands with muscle memeory, there were now ridiculous convoluted commands like systemd-resolve --status instead of 30 years…

I sometimes feel a bit weird when I see complaints like this. Because I have never experienced broken by systemd.

For logging, can't you write a systemd service in bash with -x flag?

Re: Avoiding Complexity with Systemd

#33

Post by _jal »

zozbot234 wrote: post #11
Dinux wrote: post #10

I'm glad to see more people sway to systemd. Systemd is 10 years in the making and it was met with skepticism right from the first day. Some of that is now slowly changing with systemd being accepted in more and more distributions. Service and runlevel management wasn't any better in the sysv era, nor were any of the multitude of custom start and boot scripts. I remember when it took multiple days testing the configu…

There's a lot of poorly-understood incidental complexity in the systemd codebase, and this can bite users even when doing basic service and runlevel management. The systemd approach is to try and make it 100% declarative based on simple .ini files, but the semantics of this seemingly "declarative" configuration was never properly specified. Even many systemd fans seem to be quite aware of this, and there seems to be…

> semantics of this seemingly "declarative" configuration was never properly specified

Yeah, and it is not only underspecified, but too weak to be useful, which just pushes all the init.d logic somewhere else. What you've accomplished is moving it somewhere nonstandard, great job.

Also, the command line ergonomics suck. Systemd is deeply unfriendly to humans.

It was a power play in support of a long-term RH strategy, supported by a lot of bad faith arguments. Fascinating to watch as sociology, less nice as a forced-user.

Re: Avoiding Complexity with Systemd

#34

Post by imiric »

Apologies, I was also triggered by the title. :)

> systemd provides ways to restrict the parts of the filesystem the service can see.

So like chroot and namespaces? Why do I have to depend on systemd when these are native features provided by Linux?

So systemd provides a friendlier abstraction of these concepts. Great, but so do Docker and Podman and many other tools that can actually be installed without taking over the rest of the system.

Having your application actually use systemd libraries further increases this dependency and makes it no longer usable but on a subset of Linux machines. This would be fine for some controlled production deployment, but is awful for usability and adoption.

Re: Avoiding Complexity with Systemd

#35

Post by kaba0 »

kbumsik wrote: post #25
zozbot234 wrote: post #11

Earlier quoted context omitted.

There's a lot of poorly-understood incidental complexity in the systemd codebase, and this can bite users even when doing basic service and runlevel management. The systemd approach is to try and make it 100% declarative based on simple .ini files, but the semantics of this seemingly "declarative" configuration was never properly specified. Even many systemd fans seem to be quite aware of this, and there seems to be…

The question is, was it better before systemd?

No way in hell

Re: Avoiding Complexity with Systemd

#36

Post by jbverschoor »

midasuni wrote: post #13
Dinux wrote: post #10

I'm glad to see more people sway to systemd. Systemd is 10 years in the making and it was met with skepticism right from the first day. Some of that is now slowly changing with systemd being accepted in more and more distributions. Service and runlevel management wasn't any better in the sysv era, nor were any of the multitude of custom start and boot scripts. I remember when it took multiple days testing the configu…

For people who had well working low maintenence environments, systemd came in and changed everything - breaking things, requiring changes to get things working again. Its not just breaking init.d scripts, it’s ntp, dns, syslog. Systems throughout the OS fail to things that were no longer short commands with muscle memeory, there were now ridiculous convoluted commands like systemd-resolve --status instead of 30 years…

You do know that resolving something involves other things than a simple udp query to port 53?

Re: Avoiding Complexity with Systemd

#37

Post by [deleted] »

midasuni wrote: post #13
Dinux wrote: post #10

I'm glad to see more people sway to systemd. Systemd is 10 years in the making and it was met with skepticism right from the first day. Some of that is now slowly changing with systemd being accepted in more and more distributions. Service and runlevel management wasn't any better in the sysv era, nor were any of the multitude of custom start and boot scripts. I remember when it took multiple days testing the configu…

For people who had well working low maintenence environments, systemd came in and changed everything - breaking things, requiring changes to get things working again. Its not just breaking init.d scripts, it’s ntp, dns, syslog. Systems throughout the OS fail to things that were no longer short commands with muscle memeory, there were now ridiculous convoluted commands like systemd-resolve --status instead of 30 years…

[deleted]

Re: Avoiding Complexity with Systemd

#38

Post by goodpoint »

atoav wrote: post #4
whateveracct wrote: post #2

Use NixOS and you'll love systemd. You'll be defining your own systemd units with ease. systemd to you will be journalctl and systemctl. So pretty good.

I use mostly Ubuntu and Debian and defining systemd units just means you have to spit the right text into a .service file placed at the right spot. How does NixOS make that easier?

It does not.

Re: Avoiding Complexity with Systemd

#39

Post by [deleted] »

smitty1e wrote: post #30
turminal wrote: post #14

The title is an oxymoron. Putting a huge complex piece of software between yourself and "complexity" doesn't make the system less complex.

Systemd seems to do a good job of moving the complexity of managing the privileged/unprivileged divide into a standardized service. I sympathize with the "transition sucks" sentiments elsewhere on this post. Having a bunch of working scripts turned into instant technical debt cannot be pleasant. But, as with python3, systemd seems to be the way things are headed.

[deleted]

Re: Avoiding Complexity with Systemd

#40

Post by kkirsche »

As someone who wants to learn systemd, even just to understand what I’m stuck with and why it was made, this is the best introduction I’ve found. Does anyone have other resources to help beginners learn how to use systemd efficiently and it’s relationship to Docker?
Post reply on HN