JdeBP

There's a lot more that can be said about this:

1. If you've ever heard of TurboVision, this UI is similar to it. But actual TurboVision as it was later to be found in Borland programs, and as even can be found in clones today, did not have this look and feel, which would have seemed a little clunky for a TUI by the end of the 1980s.

1. Notice that F1 is already help, but the other function keys do not follow the CUA pattern that was only actually formalized that same year.

1. Notice the differently coloured letters for the shortcut keys for menu entries, something that has largely vanished nowadays.

1. Notice how wasteful of 80×25 area some of the windows are. It was not long before everyone had shrunk the application menu down to 1 row. Conversely, though, look how colour is used to demarcate function key names, rather than using square brackets.

1. Scroll Lock is actually a major part of the user interface. A number of MC/PC/DR-DOS programs at the time gave a use to Scroll Lock. In Turbo BASIC, it switched (as it says in the screen shot) into and out of a mode where the arrow keys moved/resized things.

It's somewhat of a forced trick nowadays, I think.

I actually thought from the title before I read the article that it was going to use _Generic, as in something like _Generic((item),__typeof__((list)->payload):...) .

I don't care all that much even today. (-:

I use pax -r -w most of the time.

Oh yes. They were definitely graphical. No two ways about that.

I'm talking more about the distinction between VB/DOS and VB/Windows. They both did the whole WIMP thing, with a visual editor to construct the forms for one's programs, but VB/DOS used a TUI rendering that drew everything with VGA character graphics and used the firmware low-level keyboard access for input; whereas of course VB/Windows used the Windows GUI.

A VB/DOS-alike that ran on EFI and did the whole form-based programming thing, would use the EFI text input and output protocols, which know Unicode, waiting for events, and standardized scan codes and modifiers.

There is no major call for it, as you say, when bootstrapping an entire operating system is so easy. But it would be interesting to see someone tackle it from the point of view of what VB/DOS would look like today if it ran directly on the firmware, spoke Unicode, and ran in protected mode

The interesting thing would be if someone made a lookalike for Visual BASIC for DOS (not Windows) that ran as a standalone EFI application.

That is the real 'what if it had not gone out of fashion' path. VB/DOS definitely went out of fashion. GUI BASICs became fashionable, instead. Everyone who does a 'visual' BASIC nowadays does a GUI one.

The headlined BASIC is nothing like a VB/DOS for EFI, though.

It was not the future of the language. It's starting, as the blurb says, from where GW-BASIC and the old Microsoft BASIC were in the early 1980s. We know what the actual future of BASIC was after those, because that future happened. It wasn't this at all.

Interestingly, the mailing list discussion being talked about happened roughly a week after this Hacker News thread highlighted afresh all of the Ubuntu LaunchPad bugs being left hanging; and highlighted a major problem with rm that, probably not coincidentally, suddenly saw fresh attention after being around for years, the same day as the Hacker News entry appeared.

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

Of course, on OpenBSD it is GNU Core Utilities themselves that already are the alternative suite of SUS utilities. So it's an argument for carrying alternatives to the alternatives.

Yes. The name that you should look up is Trusix.

When cp was invented, 'most filesystems' did not have the first clue about copy on write.

However, I should note that possibly the first company to invent what you describe was Microsoft.

Novell Netware 386 had an NCOPY command which invoked a Netware extension to the DOS API that told the server to perform the entire copy on the server.

But even earlier, OS/2 1.x had a proper DosCopy() system call. Since it could be passed down to the installable filesystem drivers for intra-volume copies, something like the Netware client for OS/2 could in theory turn it into the same protocol call that did server-side copies. There was a NET COPY command in LAN Manager (and LAN Server, if memory serves) that did the same optimization.

* https://www.edm2.com/index.php/DosCopy_(OS/2_1.x)

* https://www.edm2.com/index.php/FS_COPY

It's rather sad that none of the answers were that the cp command simply did not gain a recursive option until the 1980s, well into the 1980s if you were on one side of the Unix wars.

Yes, seriously. When you read about the supposed evils of cat -v from the Unix nostalgia people, remember that it was the same people who gave cat its -v option who also gave cp its -r option, in 4.2BSD.

It took over half a decade to percolate out of the BSD world, too. AT&T Unix System 5 did not have an -r option to cp. Here's Brandon S. Allbery explaining in 1987 how one copies directories on AT&T Unix System 5 Releases 2/3 by combining find and cpio -p:

* https://groups.google.com/g/comp.unix.questions/c/XiumTgkcYR...

Originally we read directories as raw byte streams and liked it, you know. (-:

Bah! Thought NeXTSTEP. Typed NextBSD. Fixed. I've been typing lots of names ending in 'BSD' today. (-:

This is rather missing the point. The headlined article isn't really about how to achieve a goal, but about the weird history and evolution of a tool that leads us to the rather odd situation that we are in today. And it's far from being the only tool that has a weird history, that looks rather nutty if one looks at it from the point of view of a novice having to learn this stuff.

It's also not even completely covering the weird case of -r and -R for the cp command. On HP-UX, for example, the twain were different, but not in the way that they were in old GNU Core Utilities. That would be too easy. (-:

The AIX manual for cp explains its difference between -r and -R:

* https://ibm.com/docs/en/aix/7.1.0?topic=c-cp-command

Illumos also treats the two differently, but in a subtly different way:

* https://illumos.org/man/1/cp

macOS was based off NeXTSTEP, not FreeBSD.

And the received wisdom about long options in the BSDs is a quarter of a century out of date. When the BSDs gained a getopt_long() in their C libraries thanks to Klausner and Baron, long options quietly started appearing. This process has been gradually and quietly on-going for the whole of the 21st century.

It's Breakout and Super Breakout according to a list that gives the real titles in the comments section.

Not wholly apocryphal. The U.K.'s air traffic control ran, and possibly still is running, on an IBM 4381 substituting for an IBM 9020.

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

They've reportedly already tried, and failed, to replace it with a more modern system.

That AmigaDOS emulation will almost certainly never run another program. (-:

Far more concerning from a RISKS point of view is the spare parts being physically in the same place as the live machine.

You probably recall https://news.ycombinator.com/item?id=19848953 .

It's a decent chunk in most people's.

But we're talking about a system that is also older than most people.

It was first put into operation in 1967 in the U.S.A., and brought over to the U.K. in 1974. It's formally called 'NAS En Route Stage A', and is written in a 1950s language named JOVIAL. It originally ran on an IBM 9020. It runs on IBM 9020 compatible systems today.

For some reason, a couple of years ago someone added a lengthy unverifiable description of it to Wikipedia's IBM 9020 article, even though that very description said that NAS hadn't run on a 9020 for 34 years at the time of writing, but had been running on a 4381.

A lot of people have already made almost all of the same observations that I was going to make.

Except for: There is no bug that originates in a GNU version of an old networking program and magically makes its way into the NetBSD, FreeBSD, DragonFlyBSD, and OpenBSD (Yes; I checked.) versions of that program.

History simply didn't happen that way.

This bug goes as far back at least as far as the Jolitz-released 386BSD source for libexec/telnetd , where it can be found and which is credited in the GNU versions of the file. GNU just took the 386BSD code. But BSD had a telnetd before 386BSD. In BSD, telnetd itself goes back to 1983. Although its code to do line mode did not pre-date RFC 1116, which was published in August 1989.

The code to do line mode was written the month after that RFC, by Paul Borman, and the bug is in the very first version of that code:

* https://github.com/dspinellis/unix-history-repo/blob/dc8d504...

This bug is not 32 years old.

It's sad that this is probably going to become canon, now, Raymon Chen being as influential as xe is, when what actually happened was that in 1998 H. Peter Anvin saw UD2 in Intel's doco, and that there was a second opcode that was just described by Intel as merely undefined, so gave it the mnemonic UD1 in the 0.98p3-hpa version of NASM because 'calling it UD1 seemed to make sense'.

* https://groups.google.com/g/comp.lang.asm.x86/c/ErG5TJEDjiw/...

* https://github.com/netwide-assembler/nasm/blob/nasm-0.98.x/C...

The 'wierd syntax' has finally been getopt-ified. On the C GNU coreutils 'dd', and in a couple of the BSDs 'dd's.

* https://jdebp.uk/Softwares/dd-with-getopt.html

It only took 52 years. My prediction stands, by the way. (-:

That's is famously not what 'dd' was designed to do. Its description in the original Unix 6th Edition manual was 'convert and copy a file'. It's infamous for people mis-remembering it as a disc copier when it was actually a file transcoding utility that understood EBCDIC and could re-block things.

The Launchpad bug is https://bugs.launchpad.net/ubuntu/+source/rust-coreutils/+bu... .

The apparently related bug in the origin project is https://github.com/uutils/coreutils/issues/2949, filed back in 2022 and which sat unmoved for several years until, probably not coincidentally, almost the same time yesterday that this appeared on Hacker News.

One of the few good things to have come out of this repeated silliness, is that for 2 years I've witnessed people reading more about what is being altered by these executive orders and sourced by Google Maps et al. and learning why the U.S.A. GNIS is such a woefully bad data source.

And it's not because of the antics of Donald J. Trump. It's been a shit-show for 50 years: a tale of long-term multiple-phase projects losing funding and changing direction mid-phase, of technical debt never dealt with, of the consequences of data entry methodologies, and of cultural erasure because of magtapes encoded in EBCDIC.

(Yes, EBCDIC. There wasn't a systematic deliberate plan to eliminate diacritics from the U.S.A. in the 1970s, as one might guess from observation. There was EBCDIC. In fact, there was initially a plan to put the accents back on, with extra data fields to record the correct names from state-level sources, after moving away from EBCDIC. During the Reagan Era. You can see today how that turned out.)

One bizarre thing, almost as bizarre as the re-spelling of an entire country by EBCDIC, is that the name change from South Park to South America is tame in comparison to the sort of shenanighans that went on in the GNIS. Ghost towns that never existed got named after rural post offices in wide open unpopulated country, railway stations, steam train water stops, local stations serving farms, company executives, loads of springs in California, and in extreme cases things like a fish pond, survey marker trees, and a cage for a monkey. Or a lone building at a crossroads got the name of something else because a map font was difficult to distinguish, or a name printed by something else just happened to run over it.

And then some people handy with computer automation enshrined this rubbish, by mass-importing it into Wikipedia. Wikipedia is still cleaning this up by hand almost two decades later. Oh the wonders that we have collectively done with computers! (-:

The creators of South Park have a long way to go before they are anywhere near as mad as actual history is.

* https://wiki.openstreetmap.org/wiki/USGS_GNIS

* https://en.wikipedia.org/wiki/Wikipedia:Reliability_of_GNIS_...

* https://en.wikipedia.org/wiki/Geographic_Names_Information_S...

I read the article thinking that it was not going to mention Dymaxion. Articles like this rarely do. The BBC has an article on the U.N. resolution (https://www.bbc.co.uk/news/articles/cly5r60v4mro), and it does not.

And then right at the bottom it went and mentioned Dymaxion.

Dymaxion is one of the few projections that actually shows Antarctica with something resembling its actual shape. Interestingly, to counter the people who say that the best thing to learn from is an actual globe, a couple of children's globes of the world that I had as a child had large metal caps around the axle that obscured most of Antarctica.

Any decent atlas uses a variety of projections, of course. The tatty, second-hand, older-than-I-am atlas that I had at school was already on to Interrupted Mollweide's Homolographic by page 3. (-:

An interesting unintentional benchmark is to go to https://github.com/iczelia/bzip3/releases and see to what degree bzip3 compresses its own release archives; and go to https://github.com/iczelia/bzip3/blob/master/.github/workflo... to see what options have been chosen for the other compressors here.

There are several interesting things about this.

1. WordPerfect‽

I last personally encountered WordPerfect in the early 1990s, when a marketing bod assured me that WordPerfect users never wanted to see the desktops of their graphical operating systems, so there was no reason to integrate with them. For me, it was not unexpected that I never heard of it again, except in nostalgic discussions of the 1980s. Until today.

It turns out that the boycotting U.S.A. movement missed the spot when it was both Canadian-owned and Canadian-made by some years. I myself am just amazed that it still exists, and equally amazed to find under the #WordPerfect hash-tag on the FediVerse someone posting a picture of a shop selling WordPerfect off the shelf, in boxes, in 2026. (https://pixelfed.social/p/rl_dane/972538257736811779)

1. Social media

It's interesting that https://Mstdn.CA , owned by Canadians, moderated by Canadians, hosted in Canada, does not get a mention. GuardTheLeaf promotes Hey.Cafe as well, but it is not a federated site.

1. Maps

Today's news about Apple Maps (9 Hacker News submissions already) has already hit this list, it appears; with several things listed as alternatives to Apple Maps. So it's up to date at the time of launch. The question is whether the list as a whole will be kept up to date, or be added to, as events unfold. And as noted, there are prominent omissions.

This is a semantic quagmire, and the threads on what undefined behaviour is are interminable. But just note this time around that correctness is not the same as conformity.

The old fallacies of WWW site changes equals software changes, and unchanged code equals non-existence, and Wikipedia being gospel for computing topics, rear their ugly heads again.

I follow the FediVerse robot that announces MirBSD CVS updates, which is quite active. The last major change, apart from some doco, was a fix to rdate at the end of May 2026, just 2 months ago. And even if MirOS BSD were unchanged for longer than that, it would very much still be around.