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

Systemd by Example (2021)

seb.jambor.dev

Post reply on HN
Print view View original

101–110 of 115 posts

Re: Systemd by Example (2021)

#101

Post by okanat »

generalizations wrote: post #61
sph wrote: post #21

Earlier quoted context omitted.

Not a lot of people, a very loud minority. They can go use Void Linux or other niche distros which replace it with the monstrosity that were SysV init scripts. It's the type of people that never had to write one of those scripts by hand, and maybe support two or three different distros. The UX of systemd tools (systemctl, journalctl) is a bit crap, to be honest, but systemd does what it needs to do well and it is an…

> monstrosity that were SysV init scripts I'm really tired of people pretending that systemd is the only modern init system around. If you're going to compare it to the status quo, at least don't strawman it. If SysV init scripts are your comparison, it just sounds like you're regurgitating outdated talking points.

Sorry but this argument really falls flat. All of the other init systems' service files are reminiscent of SysV say OpenRC or runit.

Moreover systemd achieves what it does because it provides a unified way of doing system administration. It is not only a service manager. It is the much needed dynamic system layer for Linux.

A modern Linux engineer or a sysadmin, no longer needs to make 5 to 10 different services work together by duct taping everything or writing abstraction layers per integration. Any system that has the correct level of abstraction will be at least as complex as systemd.

Re: Systemd by Example (2021)

#102

Post by okanat »

fsflover wrote: post #98
op00to wrote: post #92

Earlier quoted context omitted.

I don't care about a 50 year old technology philosophy. Times have changed. Cloud computing and the prevalence of highly distributed systems have completely changed how software is deployed, scaled, and managed. These environments often rely on complex orchestration which can stretch the boundaries of the UNIX philosophy towards systems that are more about interactions between distributed components than about simple…

I don't see how it's relevant. An orchestration tool can also follow the Unix way by not implementing too much functionality and relying on the small tools for subtasks.

And do you know what systemd is? A project that produces multiple orthogonal executables that share a syntax paradigm and communicate over standardized IPC mechanisms.

I think the only valid-ish argument these Unix philosophy discussions boil down to "why didn't they use purely text based interfaces". Well because they are inefficent and hard to debug and reason with. Making things text only doesn't make them more understandable but they make sure the programs waste energy and development time in meaningless parsing code that is full of security issues.

Re: Systemd by Example (2021)

#103

Post by okanat »

traverseda wrote: post #32

I am not having a good time with systemd on my embedded device. Somewhat complicated scenario, I need to change the mode of a wifi driver (which I do via modprobe), use iw to create a second interface for that wifi device, and finally use networkmanager to create a wifi hotspot based on the host name of the device. We set the hostname based on the mac address of wlan0. There are a lot of places this can go wrong, and…

I think you're trying to force the init and service manager systemd side to do network things. Well those are more complex than the purely service manager side to handle and that's ultimately why you struggle.

All the extra complexity is the reason that systemd ships with its own network daemon systemd-networkd to handle that complexity separately. It sounds like you need a .netdev file to create your virtual interface. Also .device files are also handled by networkd. I use them on our embedded devices pretty successfully. Take a look (especially wlan type): https://www.freedesktop.org/software/systemd/man/latest/syst...

Re: Systemd by Example (2021)

#104

Post by ecnahc515 »

michaelcampbell wrote: post #94
dingnuts wrote: post #80

Earlier quoted context omitted.

That's the thing though, you have to remember filenames. I don't have to remember anything, just journalctl, because it can be run without any arguments and get logs for -everything that's running- including units I totally forgot about! More than once I've forgotten the name of some unit I wrote -- the same as I easily forget filenames for random services I've installed, and where I might have installed them. I can…

> you have to remember filenames. You have to remember unit names. They're all just names.

Not really, there’s systemctl list-units.

Re: Systemd by Example (2021)

#105

Post by fsflover »

op00to wrote: post #100
fsflover wrote: post #98

Earlier quoted context omitted.

I don't see how it's relevant. An orchestration tool can also follow the Unix way by not implementing too much functionality and relying on the small tools for subtasks.

Why? For old time’s sake?

See the Wiki link above.

Re: Systemd by Example (2021)

#106

Post by fsflover »

okanat wrote: post #102
fsflover wrote: post #98

Earlier quoted context omitted.

I don't see how it's relevant. An orchestration tool can also follow the Unix way by not implementing too much functionality and relying on the small tools for subtasks.

And do you know what systemd is? A project that produces multiple orthogonal executables that share a syntax paradigm and communicate over standardized IPC mechanisms. I think the only valid-ish argument these Unix philosophy discussions boil down to "why didn't they use purely text based interfaces". Well because they are inefficent and hard to debug and reason with. Making things text only doesn't make them more un…

You have a point concerning the text files. (Although I would be really interested to see an example where efficiency of text files is insufficient on modern hardware.)

However "multiple orthogonal multiple orthogonal executables" is just a strawman: their interfaces are unstable and non-straightforward, aand communicate over standardized IPC mechanismsnd one can't reliably replace one of them with an alternative. It's technically true but in practice not. This effectively makes it a huge, inflexible, not-easily-verifiable blob with wide permissions and, potentially, many bugs.

> and communicate over standardized IPC mechanisms

I've never seen that anyone could replace one systemd component with an alternative implementation. Did you?

Re: Systemd by Example (2021)

#108

Post by michaelcampbell »

ecnahc515 wrote: post #104
michaelcampbell wrote: post #94

Earlier quoted context omitted.

> you have to remember filenames. You have to remember unit names. They're all just names.

Not really, there’s systemctl list-units.

Just like `ls`, or even `ls *.log`.

As I've been trying to allude to, 90% of this is familiarity, not some objective "better".

Re: Systemd by Example (2021)

#109

Post by klysm »

mksybr wrote: post #79
klysm wrote: post #48

Earlier quoted context omitted.

The issue would be blocking the network coming down.

I think something like: Wants=network-online.target After=network-online.target Before=shutdown.target DefaultDependencies=no

Yeah it’s definitely expressable but non-obvious

Re: Systemd by Example (2021)

#110

Post by sneak »

sph wrote: post #46
doix wrote: post #43

Ha, systemd is basically my git. I'm always surprised by how many developers don't grok git despite understanding significantly more complex things. I keep thinking if they would just take a day or two, they would get it and then wouldn't complain about having to copy paste commands and "rm -rf && git clone" to fix their workspaces. And yet I do the _exact_ same thing with systemd. I don't get it, I don't like it, an…

Sounds like a you problem. You have identified a hole in your knowledge, you should address it. Systemd is not rocket science, and I would say it's more intuitive that git is anyway.

It’s not rocket science, but it is baroque. TFA ends with 30 lines of config to make it boot and do nothing, including some to disable a bunch of spooky action at a distance invisible default dependencies, which still ends up with a system with a bunch of other units that aren’t explained.
Post reply on HN