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

21–30 of 357 posts

Re: Avoiding Complexity with Systemd

#21

Post by irl_ »

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 think you're missing a few things here:

* Services started with sysvinit would put logs where they want, which is fine if you know where they are but per-service you might be guessing. Having everything always in the same place is handy.

* sysvinit wasn't giving you any of these security benefits.

* If your system really was working fine before, why did you need to upgrade it to a newer distribution with systemd?

Re: Avoiding Complexity with Systemd

#22

Post by dagw »

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…

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.

Re: Avoiding Complexity with Systemd

#23

Post by jbverschoor »

dagw wrote: post #22
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…

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.

Re: Avoiding Complexity with Systemd

#24

Post by turminal »

irl_ wrote: post #21
midasuni wrote: post #13

Earlier quoted context omitted.

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 think you're missing a few things here: * Services started with sysvinit would put logs where they want, which is fine if you know where they are but per-service you might be guessing. Having everything always in the same place is handy. * sysvinit wasn't giving you any of these security benefits. * If your system really was working fine before, why did you need to upgrade it to a newer distribution with systemd?

> * If your system really was working fine before, why did you need to upgrade it to a newer distribution with systemd?

Because the only two alternatives are 1) running mainstream distros from before 2014 or 2) running obscure distros that still don't use systemd.

Re: Avoiding Complexity with Systemd

#25

Post by kbumsik »

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…

The question is, was it better before systemd?

Re: Avoiding Complexity with Systemd

#28

Post by jbverschoor »

turminal wrote: post #24
irl_ wrote: post #21

Earlier quoted context omitted.

I think you're missing a few things here: * Services started with sysvinit would put logs where they want, which is fine if you know where they are but per-service you might be guessing. Having everything always in the same place is handy. * sysvinit wasn't giving you any of these security benefits. * If your system really was working fine before, why did you need to upgrade it to a newer distribution with systemd?

> * If your system really was working fine before, why did you need to upgrade it to a newer distribution with systemd? Because the only two alternatives are 1) running mainstream distros from before 2014 or 2) running obscure distros that still don't use systemd.

Or you could've actually improved init.d and add all the features to is, and make easy to use/create.

Re: Avoiding Complexity with Systemd

#29

Post by tpush »

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…

> [...] but the semantics of this seemingly "declarative" configuration was never properly specified.

What's missing from docs like [0] that makes you say that?

[0] https://www.freedesktop.org/software/systemd/man/systemd.uni...

Re: Avoiding Complexity with Systemd

#30

Post by smitty1e »

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.

Post reply on HN