JdeBP

Don't jump to the conclusion that they all mis-read the name several hours ago, though.

* https://news.ycombinator.com/item?id=48310191

No inline images is not a restriction of the protocol. It's a restriction of the text/gemini MIME content type, and of the browser implementations. A server can still respond with text/html content over the GEMINI protocol, with embedded <image/> data. The GEMINI protocol specification does not restrict what RFC2045 types can be used.

* https://geminiprotocol.net/docs/protocol-specification.gmi

* https://iana.org/assignments/media-types/media-types.xhtml

It's worth mentioning at this point that one can still get (Open)Solaris descendent operating systems: OmniOS, SmartOS, and Tribblix. The latter still has SPARC in its installation guide.

* https://tribblix.org/install-sparc.html

It's also superficial and wrong, and as bad as dividing people up by hair colour into blondes, brunettes, and redheads.

The way that the BSDs differentiate cannot be reduced in this way, not least because there is a lot of what Justin C. Sherrill (of the DragonFly Digest) calls 'cross-pollination' amongst the BSDs.

A case in point:

Superficially, and erroneously, one might observe that OpenBSD, NetBSD, and FreeBSD have nvi, and only DragonFlyBSD has nvi2. In fact there was a three-way fork of actual Bostic nvi, all of them making revisions and leaving the original behind, and then things got really complex with nvi2 taking from OpenBSD's nvi, and FreeBSD's nvi taking from nvi2; not even getting into the existence of nvi-m17n along the way and how there are nvis in base and nvis in ports. (https://news.ycombinator.com/item?id=48132452) One cannot divide the BSDs up into those that have nvi2 versus those that have nvi.

The split is complex in other areas, too.

We don't have to guess. There are several mailing list discussions:

https://marc.info/?l=openbsd-ports&m=177625153728067

That's not specifically OpenBSD, though. The BSD world is not the monolith that it was back in the 1980s.

Looking back over the times that the page has been submitted to Hacker News, it's almost an even split between with 'index.php' and without.

It's an interesting question for CIS URLs whether a url-path with an empty final component, that duplicates a url-path with an actual 'index' component (of some kind), is to be taken as the primary or the secondary form. When a site has 'index.php', 'index.html', 'index.gopher', 'index.gemini', and others, the question is whether the container is the same as the index file.

That 'nearly' is important. I can think of one operating system that you cannot possibly have access to, because it was never published. (-:

Two thoughts amused me.

Firstly: There's a 2025 (sic!) erratum to RFC 1055 that isn't in the www.c here. The erratum (q.v.) makes a good case for how it changes the decoding algorithm, and it actually is Linux on the other end of the link in this case.

Secondly: Next stop RFC 1144, presumably.

One of the two was viless, although I did mention that on the FediVerse when I discussed getting around to this. I'll let you guess what the other one was.

MSVCRT, the Microsoft Visual C/C++ Runtime library, is also 'the runtime library'. It was the runtime library for Microsoft's C/C++ compiler. In the days when there were multiple C/C++ implementations for Win32 (which still exist, if one is willing to dig up Watcom C/C++ or some such) there would be different runtime library DLLs for the different C/C++ vendors, even for different versions of their products.

Runtime libraries for C/C++ provide two general sets of stuff: the stuff mandated for the Standard C and Standard C++ libraries, and the stuff that is needed by the basic mechanics of the language.

The former is everything from abort() to wscanf(). The latter is a bunch of internal functions, calls to which the compiler inserts in order to do stuff. This is basically the split nowadays between UCRT and VCRUNTIME.

In the days of programming targetting the 80486SX without an 80487 present, for instance, every piece of floating point arithmetic was not a machine instruction but a call to a runtime library routine that did the floating point operation longhand using non-FPU instructions. Other runtime functionality over the years has included doing 32-bit or 64-bit integer arithmetic on 16-bit and 32-bit architectures where this was not a native word size, functions to do stack checking in the function perilogue, and functions to do C++ run-type type checking and exception processing.

This pattern is followed by other (compiled) programming languages. Naturally, the programming languages do not necessarily have any relation to the Standard C or Standard C++ libraries, nor do they generate code that needs the same helper functions for stuff as C/C++ code does. (But the situation is complicated by the POSIX API and the old C language bindings for the MS-DOS system call API, some of which another programming language might also allow program code to use.)

Don't forget the days when multiple C/C++ implementations from multiple vendors all came with their own runtime library DLLs, too.

I wrote a C Standard library for MS/PC/DR-DOS. Your recollection is correct.

It may one day be, far in the future, although that's predicted to be so far off that Sol might have become a red giant by then, making the issue moot.

But only Luna is tidally locked at the moment. Terra is not, and its rotation still has a long way to slow down before it becomes so.

Then go to Midwinter, the home of The Lurker's Guide to Babylon 5, and prepare to be absorbed for days.

And also not entirely correct. The 16-bit 1.x API was definitely x86-specific. But the 32-bit 2.x API was not, as evidenced by OS/2 for PowerPC actually existing at one point.

Transputers. Lots and lots and lots of transputers. (-:

For the record: https://mastodonapp.uk/@JdeBP/115869933538346446

There are no contemporary sources for that because it is, as it was called here on Hacker News some years ago, an 'ahistoric retcon'.

* https://news.ycombinator.com/item?id=31338349

The 's' is for 'static' version of the explanation of the name of sbin is not actually supported by any 20th century Unix doco. The books on AT&T Unix System 5 (before which, things were in /etc) that actually give an explanation for sbin all say system binaries, or system administration commands; and none of them says anything about linkage.

The 'static link' story came from Linux people years afterwards. Here's Ian McCloghrie correcting this misconception in a Linux discussion back in 1993:

* https://groups.google.com/g/comp.os.linux.development/c/EKzL...

I pointed out the origins of sbin some years ago.

* https://lists.debian.org/debian-user/2019/02/msg00041.html

If you had been born in the 1960s, you might well have learned by dint of being alive at the time that the world underneath /usr was pretty complicated in the 1970s, 1980s, and 1990s; that /etc was where some of the things that were used to boot the system once went; and that the tale of sbin is complex and slightly sad.

The tale that things were simple until they went to pot in 2000 is wholly ahistoric.

The problems with what you say are that:

1. The history of /usr subdirectories is a lot more complex than that. There was a /usr/lbin once, for example.

1. /usr/local is not where third party softwares from packages/ports go on "the BSDs". On NetBSD, they go in /usr/pkg instead, again exemplifying that this is quite complex through history and across operating systems.

I really should write that "Yes, Virginia; executables once went in /etc." Frequently Given Answer.

Because it was /etc (and of course the root directory) where the files for system boot and system administration went in some of the Unices of yesteryear. In AT&T Unix System 5 Release 3, for example, /etc was the location of /etc/init, /etc/telinit, and /etc/login .

sbin is actually quite complex, historically, because there were a whole lot of other directories as well.

* https://jdebp.uk/FGA/unix-path-and-personalities.html

To add further evidence: People actually discussed this here on Hacker News three months ago.

* https://news.ycombinator.com/item?id=45444362

See https://news.ycombinator.com/item?id=45963780 .

See https://news.ycombinator.com/item?id=45963780 for why.

Already noted in lengthy discussion, in amongst many other ironies, at https://news.ycombinator.com/item?id=45963780 .

Already at https://news.ycombinator.com/item?id=45963780 .

See https://news.ycombinator.com/item?id=45963780 for why.

Sadly, I can report that this has brought down 2 of the major Mastodon nodes in the United Kingdom.

Happily, the small ones that I also use are still going without anyone apparently even noticing. At least, the subject has yet to reach their local timelines at the time that I write this.

2 of the other major U.K. nodes are still up, too.

Duplicates https://news.ycombinator.com/item?id=45963780 and https://news.ycombinator.com/item?id=45963949 .