Hacker News

points by gjvr 2 days ago | 0 comments

I really like this idea of 300 lines (asm) vs ~1M lines (C) which was possible by really understanding what you are doing and limiting to the core feature you need. In this case you had 'the luxury' of this being low level code. What I fear for is all (application) the code that runs on top of frameworks/run-times/interpreters (in reference to the recent PHP drama). We can harden our application code as much as we like, but if the underlying code is not safe we have an issue - this combined with you remark on attackers being in the advantage versus defenders. At this time the only way that I see to protect this is by using some kind of (virtual) private network. What are your ideas on this?

[–] b112 2 days ago

This is one of my biggest gripes with systemd. Millions of lines of code. Immense complexity. Constant churn. Endless config changes(leading to outdated and potentially dangerous configs).

Sysvinit, it's a 1000 lines of code, maybe a bit more. It's a rock compared to systemd.

So many devs have zero issue with large codebases. Some substitute "small" with "perceived small because I pull in 10M lines of node and composer packages".

And of course the new goal is to bring "trusted computing", eg Microsoft style EEE to Linux with Lennart's now corporate gig.

But it is a different world. So, what can you do?

[–] kragen 1 day ago

Even daemontools (0.76-8.1 Debian) is 3771 lines of C, much more than 1000. Sysvinit is much more code than daemontools; sysvinit 3.06 is 8407 lines of C and 3595 lines of sh, according to David A. Wheeler's 'SLOCCount'. systemd 252.39 is 549427 lines of C, 26257 lines of Python, 18735 lines of sh, etc., not even counting its dozen or so dependencies.

So you're correct that sysvinit is more than an order of magnitude smaller and simpler than systemd, and having all that code in your TCB is an express ticket to the bug-of-the-month club. But you're still underestimating sysvinit by an order of magnitude.

Bringing Treacherous Computing to Linux is, of course, generally a bad thing, and it's not a good idea to have the lead maintainer of the central component of your operating system employed by a notoriously unethical company whose main product is a competing operating system.

[–] gf000 1 day ago

Sysvinit is not 1000 lines if you add all the scripts you have to write to get feature parity with systemd. And now you have written that in the worst programming language ever created, bash, that is basically impossible to not be chock full of errors.

Frankly the amount of crying I have seen about systemd... and it's basically the most stable part of my Linux installs. Even though I really have seen everything else "catch on fire".

[–] crote 2 days ago

But that's not quite the the right comparison, is it?

Systemd doesn't just replace 1000 lines of Sysvinit. Those "millions of lines" also replace the thousands of hundred-line poorly-vetted Bash scripts you need, plus your syslog daemon, plus dozens of "fork, setuid, chroot" variants, plus your cron daemon. And that's before we get into things not directly related to service management, like logind, hostnamed, networkd, resolved, timesyncd, tmpfiles, udevd, and so on.

Systemd is an umbrella project. Look at each individual component in isolation, and the vast majority of the time the thing it replaces is significantly more complex and fragile. Systemd was adopted by most of the Linux ecosystem because it was a significant improvement over the status quo, there is no need to invent conspiracy theories here.

[–] dv_dt 2 days ago

But is the actual architecture of systemd giving simple, securable, reviewable boundaries? This is a codebase that runs in stages of inherent privelege and very low levels in many linux systems.

[–] preg_match 1 day ago

Yes, systemd is not one piece of software, it’s a collection of software, like GNU. The components aren’t just modules or something, they’re actually different programs altogether.

When people say systemd they really mean systemd-init, which is one piece of software. Not systemd-resolved, which is another.

[–] cowlevel 1 day ago

The number of binaries installed on the system has little to do with how the software is developed - how many pieces of software is LibreOffice?

[–] preg_match 1 day ago

What matters is if they’re separate programs or not. They’re separate programs. Systemd is, like, 25 different pieces of software. It’s not 25 objects that are dynamically loaded or something. No, it’s 25 different pieces of software.

Most distributions only use some of them, and the “some” set is different from distro to distro. Many distros swap parts out. And some distros only use systemd-resolved.

Systemd is, legitimately, well divided. Most of the complaints against systemd are from people who know basically nothing about systemd.

[–] cowlevel 1 day ago

Why does it matter that it's 25 binaries on disk? Surely the logical structure matters way more than the filesystem structure. Is Windows 3000 pieces of software because there are 3000 executables in system32?

[–] gf000 22 hours ago

Well, does the way spreadsheet cells are handled has any relevance to presentations? If not, then they don't increase each other's complexity budget.

systemd-init has nothing to do with network resolution.

[–] cowlevel 21 hours ago

Except it does, because it signals systemd-resolved whenever a network interface service comes up or goes down. And where do those come from? They're created automatically by systemd-init's tight coupling with the network subsystem, which it shouldn't have.

systemd-journald is a nicer example though.

[–] gf000 1 day ago

Well, my only gripe with it is that it's C. Otherwise it's very modular.

[–] radiator 1 day ago

> So, what can you do?

A new service manager for Linux distributions. The last piece of a full alternative to systemd. https://skarnet.com/projects/service-manager.html. This is a proof of concept, it does not yet have its final form.

[–] cowlevel 1 day ago

Sysvinit systems don't actually use sysvinit though, they just use sysvinit to kick off a complicated set of shell scripts on boot. The real boot code is in the shell scripts and the shell.

Usually your inittab only includes gettys, shutdown/reboot, and launching rc. That's the only things sysvinit does and it's not even the best way to do them.

[–] IshKebab 2 days ago

> It's a rock compared to systemd.

Complete opposite of my experience. I've never had a single problem with SystemD - it's one of the most surprisingly reliable parts of Linux IMO.

In contrast SysVInit worked ok on servers and sort of on desktops, but on laptops forget it.

[–] adrian_b 1 day ago

I do not believe that it is possible for SysVInit itself to have any problems on laptops, because it does nothing that is hardware specific.

Since 2005, for more than 2 decades, I have used on all my laptops only Linux with Gentoo and SysVInit and I have never encountered any problem.

Perhaps you mean that your particular Linux distribution had some startup shell scripts (which are not a part of SysVinit, they are only launched by SysVInit when the run level is changed) that were buggy on laptops. Buggy initialization shell scripts are not unusual, but such scripts are normally small and any bugs are relatively easy to find and fix, unlike with the bugs of SystemD.

While you did not had any single problem with SystemD, when I first tried SystemD (with Arch Linux; that was many years ago and that specific bug must have been fixed some time later, but nonetheless it convinced me that the developers of SystemD are incompetent), SystemD exhibited the most stupid bug that I have ever seen in a computer, i.e. the shutdown of the computer was very slow in comparison with SysVInit and moreover it sometimes failed, which is a thing that I have never seen in a computer elsewhere.

The reason for failure was that SystemD, instead of just sending signals to all processes like SysVInit, it used some inter-process messaging through DBus. At that time, at least on my computer, there was some kind of race condition between the concurrent processes that were terminated and some times DBus died before some other process that tried to communicate through it and then the SystemD shutdown sequence remained stuck and it never completed.

I consider such a bug much worse than a bug caused by carelessness, like a buffer overflow, because it demonstrated an erroneous design of the architecture of the system.

[–] IshKebab 1 day ago

> Buggy initialization shell scripts are not unusual

You can't really separate the buggy SysVinit shell scripts from SysVinit itself. That's classic "guns don't kill people, people kill people".

I prefer to not get shot.

[–] edoceo 1 day ago

On Gentoo aren't you using OpenRC?