Jonathan de Boyne Pollard

The OpenRC people in Debian only really noticed the discussion when it reached the technical committee. There was an effort to put OpenRC into contention, and all of the technical committee people who did evaluations included it in their evaluations. The problem was that OpenRC as it existed on Debian at the time was lacking. People argued that it could with a little work do the things that the technical committee people pointed out, but the counterargument was that the decision really had to be made at that point, given the argument that had built up. I do recommend reading the discussions by Russ Alberry and others about OpenRC on the technical committee mailing list back then.

Yes, everyone who has, in the succeeding 12 years, framed this as a choice between van Smoorenburg init+rc and systemd either didn't pay attention or is being woefully slapdash. Debian's choice was between Upstart, as established on Ubuntu at the time, and systemd, with OpenRC as a late entry.

* https://jdebp.uk/FGA/debian-systemd-packaging-hoo-hah.html

Interesting tidbit:

People also made the argument that van Smoorenburg init+rc could be fixed. And in fact they did address some of it, The same year (2014), the sprawling shell scripts so characteristic of van Smoorenburg init+rc were being replaced by a new system, modelled somewhat after Mewburn rc on NetBSD and FreeBSD, where the scripts were much shorter, largely declarative, and reliant upon a new init-d-script interpreter that did…

Tell us all, please, how the starting vector of this attack would affect statically compiled dropbear binary even with systemd's libsystemd pwnage? I am very cruious about your reasoning.

The fact, that the whole reason this library is even being pulled into the sshd daemon process, is some stupid stuff like readiness notification, which itself is utterly broken on systemd, by design (and thus is forever unfixable), and makes this even more tragic.

Don't put your head into the sand, just because of the controversial nature of the topic. Systemd was VERY accommodating in this whole fiasco.

Saddest part of all this is, that we know how to to do better. At least since Bernstein, OpenBSD and supervision community (runit/s6) guys solved it. Yet somehow we see same mistakes repeated again and again.

If you want to read about notification shenanigans and systemd's dubious (at best) decisions and implementation quality, read here: https://jdebp.uk/FGA/unix-daemon-readiness-protocol-problems.html

I believe this is how you do readiness notification properly: http://skarnet.org/software/s6/notifywhenup.html

I.e. you fork and run little helper to write, or directly write a single byte(!), to notify supervisor over supervisor provided fd. It allows you to even privseparate your notifier stuff or do all the cute SELinux magic you need.

But that would be too simple, I guess, so instead we link like 10 completely unrelated libraries into sshd, liblzma being one of them, one of the…

I'm sure that anyone who likes to hack their systems will surely appreciate runit. But I wonder if the larger crowd is familiar with the philosophy and ecosystem behind runit that makes it such a pleasure to work with. Runit is a member of a family of supervision suites known as the daemontools family. daemontools [1] is a process supervision suite that Daniel J Bernstein released in 1997, and is still in use today.

The daemontools family is the exact opposite of what we've come to expect from an init or process supervision system. It pioneered an approach that eschews large complex monolithic daemons in favor of the unix philosophy. They're made of numerous small and simple applications - a few dozen sometimes. Unlike the traditional init systems that most of us prudently stay away from (other than writing their service configurations), these applications are very easy to understand and tinker with independently. They have a coreutils feel - you can easily find other uses for them and mix and match them freely (because they're all very specialized). Sometimes it feels like they designed the utility suite first and then designed a supervision/init suite around it. It isn't just easy to setup a service hierarchy with it. The applications are so small and simple that implementing the suite yourself isn't a big stretch either.

The way they set up an init system or supervision tree is out of scope here. The blog post "Celebrating Daemontools" [2] by G.D. Ritter is the best…

I'm certainly concerned.

Just the other day I was revisiting the notion that using SRV records in DNS for web traffic would be absolutely ideal for small to medium sites. Unfortunately, the browsers (which have faults listed against them) refuse to implement them. Instead we have these CDNs giving us the ever-valued low latency, rather than giving the next layer down infrastructure (you and me using our VPSes) the ability to do it without needing BGP AS# agreements and fixed IPs and the like.

Now, the reasons the browsers don't implement them is because of the RFC which introduced SRV records suggested that existing tech shouldn't use SRV...

Now the most damning thing about this is the Chrome [1] won't do it because Firefox didn't do it[0]...(see comment 2 on chrome/webkit bug). Both are excellent reads, with lots of coherent thought... and yet are just...rejected.

And finally, there's this page: https://jdebp.eu/FGA/dns-srv-record-use-by-clients.html, which has a section:

> The SRV Lookup Laggards' Hall of Shame

For which Mozilla sits there as #1.

So, yes, I'm concerned. Yes there are alternate ways so that everyone doesn't need to use a CDN. Yes, it's the browsers themselves that have been stopping us....for 19 years.

[0] https://bugzilla.mozilla.org/show_bug.cgi?id=14328 [RESOLVED WONTFIX]

[1] https://bugs.chromium.org/p/chromium/issues/detail?id=22423 [RESOLVED INVALID]

The 'job model' is the wrong abstraction, as is the unit concept which tries to reduce things that have irreducible differences. I'm also rather amused how you're conceding that they're doing a "bad job," but still shrug it off as better than nothing. If you're offering a mediocre solution to an "impossibly large scope" of a task, then you ought to rethink things. Even then, a poorly implemented feature can be worse than none at all.

So far as prior art is concerned, see my old post: https://blog.darknedgy.net/technology/2015/09/05/0/

I would also point out OpenWrt's procd as an example of how to have hotplug-capable service management at a fraction of the complexity: https://openwrt.org/docs/techref/procd

Now, this rethinking did indeed come with HAL, when the idea of a master daemon and ad-hoc service manager reacting to hardware state changes was unanimously rejected by the Linux patriciate as wrong. Perhaps with systemd they will one day reach the same epiphany for system and user services. Either way, I'm not terribly personally invested in this anymore -- I just figured I'd wrap my thoughts up on an issue that occupied a good deal of my time years ago.

EDIT: As to B, the problem of process supervision and having an idiomatic way of daemonizing has been solved for a long time: https://jdebp.eu/FGA/unix-daemon-design-mistakes-to-avoid.html

> 90 mm floppy disks. https://jdebp.uk/FGA/floppy-discs-are-90mm-not-3-and-a-half-inches.html

That page is part right and part wrong.

It is right in claiming that "3.5-inch" floppies are actually 90 mm.

It is wrong in claiming that the earlier "5.25-inch" floppies weren't metric

"5.25-inch" floppies are actually 130 mm as standardised in ECMA-78 [0]

"8-inch" floppies are actually 200 mm as standardised in ECMA-69 [1]

Actually there's a few different ECMA standards for 130 and 200 mm floppies – the physical dimensions are the same, but using different recording mechanisms (FM vs MFM–those of a certain age may remember MFM as "double density", and those even older may remember FM as "single density"), and single-sided versus double-sided.

[0] ECMA-78: Data interchange on 130 mm flexible disk cartridges using MFM recording at 7 958 ftprad on 80 tracks on each side), June 1986: https://ecma-international.org/publications-and-standards/standards/ecma-78/

[1] ECMA-69: Data interchange on 200 mm flexible disk cartridges using MFM recording at 13 262 ftprad on both sides, January 1981: https://ecma-international.org/publications-and-standards/standards/ecma-69/