Hacker News Reader

Comment by andrewstuart | Hacker News Reader

>> The single, overarching problem with systemd is that it attempts, in every possible way, to do more instead of less.

The more systemd does, the better I like the power, features, consistency and functionality my linux systems have.

systemd is a beautiful work of art.

Software developers owe it to themselves to full understand what systemd has to offer, because if you really understand it then you'll find you can architect your systems around systemd and often let it to the hard work for you.

If anything, the old gnu/linux name should be dropped and replaced with linux/systemd to illustrate that in fact systemd is really a major part of what Linux is.

View on HN

> systemd is a beautiful work of art.

This reminds me of teenagers of the last generations who preferred distorted mp3 sound to original because that's the sound they have grew up with. Teenagers of today prefer distorted wide-angle selfies instead of properly shot faces because again that's what they have grew up with.

Calling systemd a work of art gives me the same vibe.

I can't tell if it's sarcasm or genuine, but I 90% agree. There's a lot of things that it makes easier. But there are areas which are just weird and overengineered and overcomplicated - for example resolved interacting with old files and creating lots of possible ways it can run. If you look at forums / SO it's obvious people are confused about what it tries to achieve. Instead of creating a whole new system, they could've started by implementing and standardizing the multi-interface behaviour in established projects like dnsmasq. Instead of that they went with NIH where it really wasn't necessary.

For resolve.conf, I think it is fundamentally bad design that is hard to get right. Before systemd, I've spent plenty of time trying to get networkmanager and resolvconf to play together. And then there was those dhcp scripts which would edit the files directly.

Also, what do you mean my "standardizing dnsmasq behaviour?" From my recollection of using it (and from manpage[0]), it's pretty basic. You (1) manually edit /etc/resolve.conf to point to localhost dnsmasq instance (2) use app-specific ways to configure nameservers, in dnsmasq's case it's an ad-hoc list of secondary resolv.conf files specified on command line, with no defaults. I don't think this is worth standardizing, as this scheme cannot even represent network interface -> dns entry associations.

https://thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html

I didn't say standardizing dnsmasq behaviour. I said multi home/interface which was one of the big reasons to write resolved. They could've added the missing feature to the 2 most popular daemons and use one of them as a default, but instead went with a whole new system written from scratch.

> If you look at forums / SO it's obvious people are confused about what it tries to achieve.

Well, many people are confused about how DNS resolving works. Many of do not consider a problem, when they configure their resolv.conf to two different upstreams, each returning different answers (i.e. one responding for domains that the other doesn't) and then wondering, why stuff is broken.

Of course that's a bit of a troll comment at the end there. There are plenty of Linux distros still not using systemd. https://www.devuan.org/ as one example.

Is this a bit?

Reply on news.ycombinator.com