Jonathan de Boyne Pollard

> classic 3.5 inch floppy disks 90 mm floppy disks. https://jdebp.uk/FGA/floppy-discs-are-90mm-not-3-and-a-half-inches.htm… Which I have taken to calling 1440 KiB – accurate and pretty recognizable at the same time.

This applies to every domain name though (at the second level too, not just the first). You'd have exactly the same problem if you were using a fake .com domain that someone then actually registered. The best practice has always been to use a real domain name that you own, and subdomains thereof. If you don't, your setup isn't working so much as it is not broken ... yet. See https://jdebp.eu/FGA/dns-use-domain-names-that-you-own.html for more explanation.

Off-topic: I can't help but be nosy and check the https version of your page. You seem to be serving a cert with CN=albertstreetantiquescentre.co.uk. Might want to get this looked at :) Edit: Interesting, https://jdebp.uk has the correct cert configured, whereas https://jdebp.uk. serves the cert as mentioned above.

Oh man, I love that "chocolate covered banana" example, I've never heard of it before, thanks! Will definitely source these, how come the original site is down? Edit: found one that's up: https://jdebp.eu/FGA/put-down-the-chocolate-covered-banana.html

Good find, thanks, just bookmarked it, it must be the new one, over the years the site moved already a couple of times, it was: http://homepages.tesco.net/J.deBoynePollard/ Before being: http://homepage.ntlworld.com./jonathan.deboynepollard/ all the FGA's are nice, (besides - the technical ones - extremely accurate) if you loved the chocolate covered banana one, you will surely appreciate the "legacy" correct definition: https://jdebp.eu/FGA/legacy-is-not-a-pejorative.html and don't miss the note about the secret 7: https://jdebp.eu/Humour/microsoft-monopoly.html

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…

I wouldn't take that as criticism; you are 100% correct. But that instability was a direct result of the issues I mentioned above: the ring transition protection/implementation was absolutely horrible; 3rd-party developers would discover a useful function in NTDLL and start using it in unintended ways, etc. Do you remember the CSRSS Backspace Bug? [0] A simple: printf("hung up\t\t\b\b\b\b\b\b"); from ring-3 would result in a BSOD. That was a pretty major embarrassment. After retiring, I started volunteering my time to mentor CS students at two local universities. I work with juniors and seniors who have no idea what "heap memory" is because, for the most part, they don't need to know. For many developers, the web browser is the "operating system". I absolutely love using Python because I don't have to worry about the details that were major issues back in the 90s. But, at the same time, when I run into an issue, I fully understand what the operating system is doing and can still debug it down to assembly if need be. [0]: https://jdebp.uk/FGA/csrss-backspace-bug.html

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…

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 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]

Go Gobo! FHS is loco! ( https://gobolinux.org/at_a_glance.html ) https://jdebp.uk/FGA/slashpackage.html or some derivative would be OK, too.

Cheers, that's interesting. There are a few instances of ([]) which look like broken links in: https://jdebp.uk/FGA/bernstein-on-ttys/cttys.html Tbf, they are probably all dead now anyway.

I'm saying that it did work perfectly fine and reliably for the common case of types oneshot and simple services. To expect it to work for type Forking services would be absurd since no mechanism would exist to even try to keep track of them. It's just a point to illustrate that systemd is not as intimately and irretrievably integrated with Linux features as some imagine. Freezers were never used by systemd as part of its process tracking mechanism. And cgroup emptiness notification was unreliable under cgroups v1. So that's not wrong. It used some horrible mechanism where a binary is launched (!) when the cgroup becomes empty. And that can fail to happen under situations of low memory availability. Related read is Jonathan de Boyne Pollard on cgroups:https://jdebp.uk/FGA/linux-control-groups-are-not-jobs.html

There is also plenty of old documentation that strongly advises against doing that, see [0] for references (e.g. the aside with an excerpt from the 1995-era AIX docs). [0] https://jdebp.uk/FGA/unix-daemon-design-mistakes-to-avoid.html

In a similar vein, but already existing, nosh lets you use systemd unit files and commands via a shim layer: https://jdebp.uk/Softwares/nosh/

> Someone else tries to weasel a difference between "shall" and "should", I find this sentiment surprising coming from someone pedantic enough to have written: https://jdebp.uk/FGA/han-unification.html https://jdebp.uk/FGA/fga-not-faq.html https://jdebp.uk/FGA/questions-with-yes-or-no-answers.html

What happened to udev also. Looked at nosh? https://jdebp.uk/Softwares/nosh/

<http://example.com./> is a valid URL, see for example: https://jdebp.uk/FGA/web-fully-qualified-domain-name.html

No idea, but someone uses disc here: https://jdebp.eu/FGA/floppy-discs-are-90mm-not-3-and-a-half-inches.htm… (btw, diskette comes from disk)

My understanding was that the double fork dance was actively discouraged for any semi-modern system. The man page you link says as much in the "new-style" section, as well as https://jdebp.eu/FGA/unix-daemon-design-mistakes-to-avoid.html. Just write your server as a straightforward process and let the service manager handle this stuff for you. You'll just be confusing it if you don't.

The plural is virus is viruses, or "virus" if you insist on its Latin form. It's a Latin word, but it only occurs in Latin as a singular collective noun: https://jdebp.eu/FGA/plural-of-virus.html

What is also interesting is that the appenwar implementation has now support for serializing logs in parallel builds: https://apenwarr.ca./log/20181106 The linked documentation does a good job why redo is a very, very interesting (and for the complexity of the task, stunningly simple) approach to a build system. I find the approach to support parallel builds quite enlightening, and I also like a lot the property that it is language-agnostic, which is very helpful for larger projects, but also makes it easier to include special tools in C/C++ projects. There are also some shortcomings of the design and some implementations of redo which are discussed here: https://jdebp.eu/FGA/introduction-to-redo.html

http://jdebp.eu/FGA/introduction-to-redo.html hoping jdebp will chime in..

Unikernels are older than microkernels, in terms of design philosophy, and owe more to VM (the IBM project from the 1960s) than later OS design. Microkernels are about splitting a single OS into what are sometimes called 'servers', whereas unikernels are individual systems running on a hypervisor; ultimately, the biggest advantage is that, in a microkernel, if one 'server' goes down (the disk server, for example) the whole system is down, whereas a single unikernel can fail without impacting any other unikernel. https://jdebp.eu/FGA/microkernel-conceptual-problems.html https://utcc.utoronto.ca/~cks/space/blog/tech/HypervisorVsMicrokernel

https://jdebp.eu/FGA/dns-srv-record-use-by-clients.html Browsers don't use SRV records for HTTP. With them one wouldn't need www subdomain CNAME hacks.

What you are saying makes sense to me. Within the context of the question, the expected answer is looking for some kind of feasible money-making project. I know that we have a lot of biases about what constitutes work; the point here is to challenge that bias. That feels like a legitimate project to me, so I try to do it when I can. I found this via HN the other day and it feels relavent to your response: https://jdebp.eu/FGA/put-down-the-chocolate-covered-banana.html

Announcement: https://lists.debian.org/debian-user/2016/08/msg00116.html URL: https://jdebp.eu/Softwares/nosh/ > It has moved. There's an article on the new WWW site about what happened. Can't find the article though.

> 90 mm floppy disks. https://jdebp.uk/FGA/floppy-discs-are-90mm-not-3-and-a-half-inches.htm… 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/ec… [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/ec…

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

> Show me an alternative to systemd that matches its functionality and consistency. As for init system, I would argue nosh[1] is a better init system. It’s based on daemontools design (same as s6, runit, etc, where it’s just a process that monitors a service directory). nosh can even semi-automatically convert systemd unit files[2] to a run script (including socket activation and all). For everything else that is not part of the system initialization process (initialize/running/shutdown) I don’t think they need to be tie into PID 1. elogind aims to do this job of taking the logind part out of systemd into its own service, which I found to be a good way of living in systemd world without using systemd (e.g. GNOME works) but it requires a lot of commitment of patching everything to link against elogind instead of systemd (Void Linux/Artix Linux are doing a good job at this). [1]: https://jdebp.eu/Softwares/nosh/ [2]: https://jdebp.eu/Softwares/nosh/worked-example.html