Hacker News new | ask | show | jobs
by xorcist 147 days ago
There were dozens of other init systems that, like systemd, wasn't a shell script.

What set systemd apart is the collection of tightly integrated utilities such as a dns resolver, sntp client, core dump handler, rpc-like api linking to complex libraries in the hot path and so on and so forth that has been a constant stream of security exploits for over a decade now.

This is a case where the critics were proven to be right. Complexity increases the cognitive burden.
3 comments
sam_lowry_ 147 days ago
What set systemd apart was RedHat, and now Pottering repeats the old trick with Microsoft behind his back.

I think he will succeed and we will be worse off, collectively.

link
jacquesm 147 days ago
As predicted. I thought pulseaudio should have been enough of a lesson. Besides that, any person that works on open source but that joins Microsoft is not in the camp that should have a say in the overall direction of Linux.
link
bulatb 146 days ago
"People don't learn lessons" is a lesson that people don't learn.
link
PunchyHamster 147 days ago
that on itself is not a problem. The problem is that those work worse.

For example, the part of systemd that fills DNS will put them in random order (like actual random, not "code happened to dump it in map order)

The previous, while very much NOT perfect, system, put the DNSes in order of one in latest interface, which had useful side-feature that if your VPN had different set of DNSes, it got added in front

The systemd one just randomizes it ( https://github.com/systemd/systemd/issues/27543 ) which means that using standard openvpn wrapper script for it will need to be reran sometimes few times to "roll" the right address, I pretty much have to run

     systemctl restart systemd-resolved ; sleep 1 ; cat /etc/resolv.conf
half of the time I connect to company's VPN

The OTHER problem is pervasive NIH in codebase.

Like, they decided to use binary log format. Okay, I can see advantages, it can be indexed or sharded for faster access to app's files...

oh wait it isn't, if you want to get last few lines of a service the worst case is "mmap every single journal file for hundreds of MBs of reads"

It can be optimized so some long but constant fields like bootid are not repeated...

oh wait it doesn't do that either, is massively verbose. I guess I can understand it, at least that would make it less crash-proof...

oh wait no, after crash it just spams logs that previous log file is corrupted and it won't be used.

So we have a log format that only systemd tools can read, takes few times as much space per line as text or even JSON version would, and it still craps out on unclean shutdown

They could've just integrated SQLite. Hell I literally made a lil prototype that took journalctl logs and wrote it to indexed SQLite file and it was not only faster but smaller (as there is no need to write bootid with each line, and log lines can be sharded or indexed so lookup is faster). But nah, Mr. Poettering always wanted to make a binary log format so he did.

link