Hacker News Reader

Comment by turminal | Hacker News Reader

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.

Why are we talking like this? We’ve been using systemd for over 5 years. It’s weird. Time loops.

It took 10 years before the “python2 will never die”-crowd finally accepted they where not going to win at that python3 was here to stay.

People spend a couple of years getting used to a stack in their early carrier and then spend decades arguing that it should never change.

But python programs are much more complex than init scripts systemd replace. It is more like people hate change and are lazy to learn a new thing.

Mamagement has 99 problems. Holding a status quo is about minimizing the backlog more than hating change as such.

Even when we can show am improvement in security and usability, and lower training cost because of consistency, it's still another mouth to feed.

If it provides sufficient benefits (which systemd does), it is a no brainer.

As a technical matter, sure.

As a business/ management matter, we frequently cannot do the technically obvious thing due to other constraints.

I would agree, but systemd has been around quite some time now. At this point it is technical debt not upgrading to it, unless you use something better.

> the "[python] will never die"-crowd finally accepted they where not going to win

Why are you talking in the past tense? We have done no such thing. Death to python 3; long live python.

Obviously I don’t mean you don’t exist any more, but the surveys show enough converted that your views on pythons future are no longer relevant in the bigger picture.

The problem with your analogy is that while a lot of people did move from python to python 3, a lot also stopped using python all together because the python2/3 split demonstrated that the python devs were willing to throw everyone's work out the window for fun. There was no technical reason why backwards comparability wasn't possible. Multiple good solutions were put forward. They were all rejected for silly reasons.

A lot of that "python2 will never die" crowd left python all together, and they are better off for it because they won't have to deal with the next time python decides to throw everyone's work out the window.

I don't have a horse in the systemd vs init.d, I'm a dumb groovy programmer after all.

But you are right, adoption is not enthusiastic, which to me is a massive indictment of the design and usability. We'll basically spin wheels until someone gets annoyed with it and does systemd better, or at least more modularized.

My complaint? sudo systemctl <verb> <service> means the verb cannot be autocompleted or introspected like sudo service <service> <verb> could be. May be minor, but it's generally my only interaction with systemd versus init.d, and to me they completely blew the only thing I use. Not a good impression.

I understand that init.d was a cobbled set of scripts, loose conventions, and even some hacks. But the resistance to system.d is so pervasive it cannot just be stubborn unix neckbeards.

The people who matter, who write init scripts, in other words the distro maintainers, were happy to switch.

Why else do you think so many distributions switched?

Yes, the resistance is noisy and stubborn Unix neckbeards. Not even Unix, since every other Unix had something similar to systemd already. LINUX neckbeards.

Agreed.

One point is that processes other than root cannot start services on ports < 1024. That was a sensible precaution computers where big and multiuser, like in a university setting.

However, with single-serving services (e.g. in vm/container/vps/cloud), there is no need for it.

BSD lets you configure it with a sysctl option. But Linux defends that option like it is still 1990.

On NixOS, I patch it like this:

   boot.kernelPatches = [ { name = "no-reserved-ports";  patch = path/to/no-reserved-ports.patch; } ];

With the patch just as big:
--- a/include/net/sock.h +++ b/include/net/sock.h @@ -1331,7 +1331,7 @@ #define SOCK_DESTROY_TIME (10*HZ) /* Sockets 0-1023 can't be bound to unless you ares uperuser */ -#define PROT_SOCK 1024 +#define PROT_SOCK 24 #define SHUTDOWN_MASK 3 #define RCV_SHUTDOWN 1

Does it really change anything running something on port 90 rather port 1090?

If you get unprpivileged access to a system, and somehow manage to crash sshd, or win a race to bind port 22 when sshd restarts, you can intercept other logins.

If you can bind port 80,you can gets ssl certs via let's encrypt (which could let you intercept not just web, but also smtp/imap etc).

So yes, it can make a difference. Of course - it's better if the user doesn't have access to begin with.

This might be more interesting for classical multi-user servers than "single use" servers that don't allow "regular" users to login via ssh.

Reply on news.ycombinator.com