|
|
Log in / Subscribe / Register

A backdoor in xz

A backdoor in xz

Posted Mar 31, 2024 1:58 UTC (Sun) by himi (subscriber, #340)
In reply to: A backdoor in xz by mchehab
Parent article: A backdoor in xz

If SysV init systems are actually more robust than systemd ones, it's because they're much simpler - your description captures that simplicity really neatly, in fact.

Though I don't actually believe that claim - I've had plenty of SysV init based systems that were massive pains in the neck to deal with, while the majority of the systemd based systems I've managed have been fairly benign and well behaved, despite doing a whole lot more. Also, the issues I have to deal with generally have nothing to do with systemd, and when they /are/ issues with the unit configuration they've been much easier to resolve than similar issues with init scripts ever were.

Oh, and writing a service targeting a SysV init environment is /far/ more of a pain than writing the same thing targeting a systemd environment - in fact, it's ridiculous how easy it is to target systemd with a basic service. No daemonising, no futzing around with logging targets, no pid files, even the kind of basic intra-service coordination you're pooh-poohing is ridiculously simple. And no mess of spaghetti shell code init script! Most of the time the unit file for a basic service is five or ten lines, and they're simple and declarative with no complex logic - infinitely easier to write and debug. Even when you need to set up complex interdependencies it's generally simple to configure and relatively easy to debug - it can be fiddly, but that's mostly inherent to the problem, rather than an artefact of systemd's implementation.

SysV init worked okay in its day, though it was always a bit of a pain. But it's long /long/ past the time when people should have recognised how much of an improvement systemd is, in pretty much every way. Eulogising the past is all well and good, but actual current performance matters a whole lot more in the real world than sepia-tinted memories of past glories.


to post comments

Here too

Posted Mar 31, 2024 2:05 UTC (Sun) by corbet (editor, #1) [Link]

Fighting the old systemd wars yet again is not going to help us address this kind of attack. Please, let's not do that.

A backdoor in xz

Posted Mar 31, 2024 3:13 UTC (Sun) by DimeCadmium (subscriber, #157243) [Link] (2 responses)

Indeed, simpler is better. Simpler is easier to secure, simpler is easier to develop, simpler is easier to maintain (i.e. run a system with it), simpler is easier to modify, simpler is easier to troubleshoot, simpler is easier to understand.

A backdoor in xz

Posted Mar 31, 2024 13:00 UTC (Sun) by pizza (subscriber, #46) [Link]

> Indeed, simpler is better.

You can have your remberberries, but the rest of us have to deal with the real world.

...The real world isn't simple, hasn't ever been, and has only trended towards higher complexity.

A backdoor in xz

Posted Apr 1, 2024 14:08 UTC (Mon) by farnz (subscriber, #17727) [Link]

FWIW, by porting a system from SysV init to systemd, I was able to close several hard-to-reproduce bugs, since systemd's extra complexity allowed me to remove a ton of complexity from the various scripts that started components of the system, and at least some of that complexity turned out to have race conditions in it that systemd did not have.

There is a huge advantage to one implementation of something done well replacing (in my case) 5 different implementations, all with different bugs.


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds