Avoiding Complexity with Systemd

Or how about adding new buggy DNS code that doesn't work in common scenarios? Oh, sorry, here's another CVE because we didn't create enough test cases for the corner cases that are actually important.

Or oops, "nobody uses ntsysv", right? Or "We don't need to implement chkconfig even though we broke it".

systemd is a monolithic beast that is absorbing everything else in the system without considering that some of its decisions should be able to be disabled, and a lot of the design decisions are half baked. I don't believe in the philosophy of design its author has embraced. Progress is good, but please, stop breaking shit that has worked for decades. Anyone can write new code that partially implements a feature, but it takes real effort to responsibly migrate users from tools that worked to your new shiny half assed kitchen sink.

How long do you think it takes to start gpsd, or pcsd? Even my laptop has 12 CPU threads, all idle during this time. And including human reaction time (noticing that the login screen has appeared) this is, what, 10 seconds? 120 CPU-seconds is not enough? All desktops run on SSD now too, right?

In fact, how many services do you even think are installed by default?

And Linux, being a multitasking OS, doesn't even have just that window.

But you know, maybe it's a tight race. You could try it. How long does it take to trigger all those?

> a hallmark of good engineering.

In the abstract, as a "neat idea", yes. In actual implementation when actually looking at the requirements and second order effects, absolutely not.

You know you could go even further. You could simply not spin up the VM when the user asks to spin up a VM. Just allocate the IP address. And then when the first IP packet arrives destined for the VM, that's when you spin it up.

That's also a neat idea, and in fact it's the exact SAME idea, but it's absolutely clearly a very bad idea[1] here too.

So do you do this, with your VMs? It's cleary "started lazily, on-demand, one of the classic techniques for performance optimization and a hallmark of good engineering".

[1] Yes, very specific environments could use something like this, but as a default it's completely bananas.

An internal audit is enough to trigger it. "Port scan crashes machine" is not exactly "reliable software".

> You can also use some cgroup managing tool (like systemd) to restrict memory usage to the process and configure the OOM killer behavior, so that would also prevent DoS attacks.

But that means that the default is bad, and unsuitable for resource constrained machines. Which circles back to "neat, but no actual use case".

> Actually no, this is wrong, at least for me when I tried the version of netstat that ships with debian. It only shows if something has the port open -- that thing could be an fd holding service

So you agree that it's a bad idea?

> So you're right that this complicates the system but this isn't really systemd's fault

It is, because it's needless complication. At least inetd was a model to make things simpler. It's the cgi-bin of network services.

But you'll notice that people don't write inetd-based services anymore. In fact my Ubuntu default install doesn't even have inetd installed.

> The only way to know for sure is to use a different tool that prints information about the owning process

netstat has supported this for (maybe) decades on Linux. It's the -p option.

But aside from systemd's poor choices if you see port 22 open, then you can actually be very sure that there is an sshd running, that successfully started (not too broken config).

You could still be wrong. Someone could have started netcat there, or just a honeypot, or whatever, but you can't tell me it's not useful information.

> Well now you got me confused, this seems to be directly conflicting with when you said this: "It will show you if you have an SSH server running"

… unless systemd broke this functionality. I'm making the point why it's a bad idea to break this.

Clients connecting will also not get useful error messages. Port is closed means service not running. Timed out waiting for SSH banner means something else.

Pre systemd it was essentially never anything other than inetd that held ports for others. And for about the last 20 years even it would only do things like echo,chargen,time service that people would run. And having those open by default is from a more naive time, where people thought "sure, why not run tftpd and time service, would could possibly go wrong?".

Nowadays they're off by default, because we're more experienced that any attack surface is still an attack surface, no matter how small.

Probably it helped that OpenBSD kept bragging about how many remote holes in the default install. It's not actually because OpenBSD had better code, it was just that a default OpenBSD only had OpenSSH open to the world.