Behind the purposefully provocative formulation, I have a real point: even in such an interesting project, I think there are unworded assumptions that are worth questioning. What is "the Internet"? What does holding it up mean?

Are "four billion phones" part of "The Internet"? What would happen if Android stopped working? What amount of work would be necessary to get back to a similar level of service, maybe with fewer bells and whistles, but also with much less corporate involvement and layering of bullshit?

There are few really essential pieces, that would require tremendous work to replace. I am even questioning OpenSSL because even though it is a building block used by a lot of software, it's not irreplaceable at all. Replacing it would be work, but, maybe not that much.

And it is a good thing. There are alternatives. Bricks can be changed for other bricks. That is, in a large part, what FOSS is about. That is what holds up the Internet: when something doesn't work, we can fix it or we can replace it.

The lowest level piece of software in the list that I cannot argue against is bash. Too many things depend on it, it is vital to keep it working. And I am actually lamenting that, because bash is not even a good piece of software, and it is a tragedy that so much depends on it. We would be in a better position if software depended on a shell rather than this specific implementation of a shell.

Call me a radical. I might very well be. But I think these things are worth saying.

RE: https://mastodon.social/@bagder/117403995474031993

chat, is it bad if I don't care if Android, corejs, sudo, sqlite, OpenSSL and libxml2 crash and burn? 🤔

RE: https://neuromatch.social/@jonny/117325637081258433

Think I could sell proper supervision to Meta folks? 🤔

(nah, nobody could pay me enough for this)

• using glib
• using strdup
• on an argv element, which will be available for the whole lifetime of the program
• you cannot see it here without the full context, but it loops around n while path is defined outside of the loop, so it needs to free on every iteration or it just overwrites path and leaks

path = g_strdup (argv[n]);

How many code smells can you detect in that one single line?

On a thread around here:

"Everything is crumbling around us, we should prepare to rely on nothing"

This is very true, let's look at the replies in the thread:

"Can AI help?"

"Let's throw C out and start with something else"

"Cargo is lovely"

For no particular reason I felt inspired to make this creative work of art, and release it as is in the public domain with no product attached to it; it is not an endorsement or advertising of anything. If you decide to use it, please make sure to comply with the license of the logos this picture is using.

Just advertising today for no particular reason at all:

s6 is a process supervision suite, written in C, that can easily be turned into a complete init system, and that works out of the box on every remotely POSIX-compliant system, no matter the kernel, and that can probably be made to work really easily on any new Unix-inspired OS that would be published.

s6 comes with its own service manager, s6-rc, and it can also work in conjunction with OpenRC.

The whole s6 ecosystem is made by humans, for humans (and for computers as well, but computers are meant to serve humans). It has never merged a line of LLM-produced or "LLM-assisted" code, and it will never merge a line of LLM-produced or LLM-assisted code.

It moves slow, but it fixes things, and if everything is crumbling around you, it will still be here, and it will help you rebuild. That is what a supervision system does.

RE: https://beige.party/@PhoenixSerenity/117073356592883074

There is a definite correlation between my absolute lack of patience and my absolute lack of a green thumb. Nature is cool, but some of us are way more equipped to tend to it than others.

Tries to have technical discussions about good practices in Unix-like systems and supervision suites and service managers: yawn

Makes one shitpost about going back to sleep: omg favorite favorite boost boost new followers you are my spirit animal you speak to my soul you understand me so well.

I clearly missed my career. Is it too late at 50 to reconvert to wellness guru?

LB: it begins. And that, believe it or not, is one of the things that always prevented me from being okay with copyright assignments. Organizations evolve, circumstances change, and nothing guarantees that an organization that has your best interests at heart and represents your views adequately now will keep doing so later.

Together, we can go further, that's for sure, but I don't mind not going far that much. I prefer making sure I'm going in the right direction.

Call to contributions

Hey CI/CD Free Software Fedi,

I plan to move the s6-overlay repository away from Github. Probably to Codeberg.

Problem is, the build uses Github Actions, which I'm not fluent in (it was written by @jprjr , thanks again!) - and Forgejo Actions use a different format.

Learning these languages would be way too much time investment from me, for a small benefit.

So I'm asking for help from knowledgeable people. Could someone please take a look at https://github.com/just-containers/s6-overlay/blob/master/.github/workflows/release.yml and convert it to a file that would work on Codeberg's Forgejo? It's a small file, but it uses a build matrix, targeting several architectures.

What would be even more awesome is if Forgejo could create symlinks to artifacts (in order to have the same artifact exposed under several names). That would allow me to work on long-requested features. If not, no big deal.

Thanks a lot!

(Edit: typo)

Today's gratuitous portability annoyance: MacOS's select() returns -1 EINVAL if you pass it a timeout value greater than 10^8 seconds.

It accepts .tv_sec = 100000000, but not .tv_sec = 100000001.

(Some old versions of OpenBSD had the same limitation, with the same cutoff point, but it's fixed now.)

Who are these people who believe that three years and a half is equivalent to infinity?

(edit: can't this !@#$%^&* markdown do superscript correctly?)

That was way faster than expected! Some person read my emergency ticket sent last night (from logged out), and I seem to have been convincing enough because they restarted the server for me, and now everything is working again. 🥳

Guess I won't have these 10 days of forced vacation. 😔

Now to take measures so that it doesn't happen again...

skarnet.org will be down until further notice - it may take up to 10 days (!)

I wanted to reboot the server on a newly tailored kernel to avoid CopyFail shenanigans. The shutdown failed right before rebooting (because of a small oversight in s6-linux-init that is easy to fix and will not impact anyone else). Normally that wouldn't be a problem: log in to the web interface to the VPS administration, press the reboot button, done.

Except, Gandi added 2FA since I last logged in, and did not notify their users. And they decided that by default, the verification code would be sent to the registered primary e-mail address.

My registered primary e-mail address is hosted on skarnet.org. Because it was never a possibility that it would be needed for the bootstrap chain. Except that now it is, and I can't access it.

This is the dumbest catch-22 in the history of catch-22s. And the recovery procedure, when you have to prove your identity when writing to the support outside of a logged in account, can take up to 10 days. And tomorrow is a holiday. Fuck me, I guess.

I should have paid more attention, but the consequences of my not paying enough attention should definitely not be so vast, and I have choice words for several of the decisions that were made.

So, systemd's NOTIFY_SOCKET readiness notification mechanism has a sort of authentication mechanism by pid: it doesn't like it when the notification is sent from another process than the main one, unless you add the NotifyAccess=all directive. Okay, fair.

Except that even with this directive, it still can fail for some reason:

if an auxiliary process of the unit sends an sd_notify() message and immediately exits, the service manager might not be able to properly attribute the message to the unit, and thus will ignore it, even if NotifyAccess=all is set for it.

Huh? Even if the supervisor wants to check that the MAINPID= given in the message is the relevant unit, it shouldn't need the notifier process to still be around, but, let's ignore that for now. So, it has a barrier mechanism to tell the notifier to stick around until the supervisor has acknowledged it. What is that barrier mechanism? The notifier passes an fd to the supervisor via SCM_RIGHTS in the notification message, and when the supervisor closes that fd, it means it has acked the notification, and the notifier can now exit.

That's right, folks: it's a notification that the notification has been received!

There are two mistakes here: 1. the supervisor doesn't need the notifier process to be alive when processing the notification, and 2. NOTIFY_SOCKET being a socket means that any process can connect to it so the supervisor needs to authenticate the relevant unit.

And that is how a bad design decision cascades into a maze of complexity and inefficiency, and a pain to implement. Unless you're willing to use libsystemd to get access to sd_pid_notify_barrier(), good luck getting this to work right.

(systemd people will say this is conspiratorial, but if they wanted to force users to link against libsystemd, they wouldn't behave differently. But I really don't care if it's intentional or not. If it's not intentional, it's just terrible engineering.)

What would be a simpler way to handle all this? Have the supervisor run the unit with a pipe from the daemon to the supervisor, not a socket anyone can connect to. Processes that can write to the pipe are the ones that can inherit it, which means they're necessarily part of the same unit. No need for authentication via pid. When the supervisor receives a certain token on the pipe (e.g. a newline), it means that the daemon is ready. In the daemon or any process notifying on its behalf, that spells: write(fd, "\n", 1); and that's it.

In other words: the s6 readiness notification protocol, which is exactly what is described in the above paragraph, is as efficient as systemd's synchronization protocol for its notification protocol.

The real tragedy is that when you go through systemd with a looking glass, every part of it is this way. It still works, and nobody notices the inefficiencies because modern machines are blazingly fast, but it is. so. bad.

(Edit: typos)

s6 will never add an age tracking field anywhere.

This is your regular reminder that doas suffers from the exact same conception flaws as sudo.

• It is a suid root binary.
• It parses, as root, a text file that contains global instructions for what user is allowed to run what command as what other user. There is quoting involved. The syntax is not absolutely trivial (though simpler than sudo's).

Is doas better code? Probably. I trust that it's cleaner than sudo; its configuration file syntax certainly is. Has it been audited more, is it more trustworthy than sudo? Definitely, it comes from OpenBSD, and if there's one thing OpenBSD does well, it's that.

But does it solve the fundamental problem that causes the issues with sudo?

No. It does not.

If you use doas, you are not "choosing the more secure tool", at least not by its conception. You are simply trusting doas to do a better job of not being buggy while performing the exact same tasks as sudo in the exact same dangerous environment.

It is not a bad choice. You are probably right to do that. But you should know what you are doing exactly.

If you choose to use sudo-rs instead, you are still running a suid root binary that performs complex parsing, without the advantages of the simpler doas syntax or the experience of OpenBSD in hardening. You get the benefit of memory safety, but other kinds of bugs are still possible in Rust. You are basically trusting the sudo-rs authors to write a non-buggy sudo - and even with Rust's help, it is probably more difficult than writing a non-buggy doas.

It's a pick your poison situation.

If you want real security instead, you should reconsider your approach to privilege gain, study your use cases, and implement tailored specific solutions. Yes, it is a lot more work, but privilege gain is the single most dangerous thing you can do on Unix, so hardening it takes work.

Another day, another attempt to rewrite the world a little bit less and use an existing standard tool, because that's what they were made for...

... and another failure. kill does not have a portable way of sending a numbered signal to a process. When you have a signal number, you can use the kill() system call to send that signal to a process, but not the kill command-line utility.

Yes, I understand that you are supposed to address signals by their name and not by their number, but since the system call uses numbers in the first place, would it have been so horrible to allow the command line to do the same? And so, I am now writing a s6-frontend-kill command line helper. :blobfoxfacepalm:

When will they shove AI into it?

https://www.phoronix.com/news/Debian-APT-Will-Require-Rust