src VS coreutils

OpenBSD website

Interesting! Let's check the OpenBSD implementation of this algorithm, and here is the link to it. The first point of interest lies here:

The OpenBSD project released 7.6 of their OS on 8 Oct 2024 as their 57th release 💫

Funny enough filenames are just byte sequences. So almost anything goes.

There was just some patch that added '/' protection, because that's the only character that's not allowed in filenames.

https://github.com/openbsd/src/commit/46f7109a9e03df89b66ada...

OpenBSD gives us good documentation as a series of the project. (For example, the man pages are cared and kept maintained.) It's applied to principal service packages as well as the OS. So is as to PostgreSQL.

The OpenBSD project released 7.5 of their OS on 5 Apr 2024 as their 56th release 💫

> Only two remote holes in the default install, in a heck of a long time!

As someone who doesn't know this kind of stuff well, will this cause OpenBSD to have to update the statement above?

https://www.openbsd.org

I can't find an official list of supported targets, but

https://github.com/coreutils/coreutils/blob/master/README-in...

contains notes on compiling for IRIX, HPUX, AIX, and OSF/1. So no, I would bet that it very much does run anywhere Linux runs, and a lot of places it doesn't.

How about the history for "true": https://github.com/coreutils/coreutils/commits/master/src/tr...

Yeah, the thing is that `yes` isn't a stand alone project, it is usually part of a bigger project such as coreutils (https://github.com/coreutils/coreutils/).

For the comparison to be valid you would have to split up coreutils into roughly 100 individual repositories and replace many of the implementations with ones that are trivial, buggy, and/or unmaintained that pose a supply chain attack risk because it gets hard to keep track of what's maintained, by whom and how. Coreutils is close to 100kLOC and its programs aren't packaged individually. It is far, far from the random mess that are microlibraries in NPM.

less (17kLOC), awk (43kLOC) and grep (4kLOC) are separate projects, but some of those require a bit more insight than much application code these days, so it makes sense that they are individual projects.

>There is no such thing as a small legacy codebase

Very true. As a followup, I think it's worth pointing out that command line applications in particular can cram a lot of functionality into very few LOC.

Last night, I read through the source code for `cat` (yes, that `cat`) and it was only about 800 lines of fairly breezy C: https://github.com/coreutils/coreutils/blob/master/src/cat.c

And a tiny CLI tool I use every day, several times a day, for learning Finnish, is about 200 lines of Python: https://github.com/hiAndrewQuinn/finstem

AFAIK, the remote applications simply do an isatty() check on the stdout and that's it; a proper terminal is then apparently expected to correctly skip and quietly ignore any OSC sequence it does not understand. See the source of ls [0], for example.

[0] https://github.com/coreutils/coreutils/blob/2a72cf1e9959f40b...

https://github.com/coreutils/coreutils/commit/fcfba90d0d27a1...

A summary of other changes just released in GNU coreutils 9.5 are:

* mv accepts --exchange to swap files

> some are simple like yes(1)

Not that simple: https://github.com/coreutils/coreutils/blob/master/src/yes.c