JdeBP

For comparison: NetBSD, as headlined, supports Berkeley LFS and WAPBL journalling on FFS.

MirOS BSD is still around, too.

As someone who has used old BSDs, I can say from direct experience that it does not.

For starters, on the old BSDs there was no Almquist shell, unless you went to Usenet, grabbed the shar, and built it. The TENEX C shell was the hot new thing, as were BIND and Sendmail. And we got genuine Joy+Horton vi.

Whereas modern NetBSD does not have Sendmail any more, has nvi2, and supports access control lists. And of course under the covers has lots of things that the old BSDs didn't have, like UFS for TiB disc volumes and kqueue.

I've heard tell that they're even thinking of finally doing away with BIND in base.

Did you read the JSON file?

If you're going to support the ADM-3A terminal up/down navigation characters k and j, also support the vi navigation characters Control+N and Control+P. And Control+S and Control+Q for pause/resume as well.

Forwarding proxy DNS servers leading to a (yes) single resolving proxy DNS server at the end.

* https://jdebp.uk/FGA/dns-server-roles.html

It's bad the other way, too. btop on a 50×232 terminal over an actual 57600 BPS serial line is unusable, even in 16-colour mode. It does not have even the most basic of full-screen TUI redraw optimizations, and outputs the entire screen again and again.

Well, unless one is using FreeBSD or OpenBSD, where the btop code is still using 32-bit integers to calculate 64-bit sizes, and falling prey to unsigned integer wraparound. htop's code calculates using size_t, which ends up as a 64-bit integer on 64-bit architectures.

* https://news.ycombinator.com/item?id=48778757 (https://crocidb.com/post/freebsd-ate-my-ram/)

* https://github.com/aristocratos/btop/pull/1728

Screws have been around for about 3 millennia at this point. They have patently failed to obviate the use of nails. So by this analogy we can expect the 'Only GPUs do the work.' believers to be still promising this, any day now, about three thousand years hence. (-:

It's already C64 BASIC inside an SQL server. Don't give them ideas of emulating a cassette tape, with Datasette for PostgreSQL, too! (-:

Ports is on 1.4.7.

* https://freshports.org/sysutils/btop/

The fix is still pending being even made to the origin version.

* https://github.com/aristocratos/btop/pull/1728

It's the version where a committee put in em-dashes to replace Jefferson's semi-colons, if those pictures are accurate. This is not unexpected given the provenance; but a semi-colon version would have made for a more interesting discovery.

Actually, it's orthodox; and it's fetch that isn't. FreeBSD is actually the odd one out, for having an extra tool for doing the same thing. The ftp tool in all of the BSDs, including FreeBSD, speaks HTTP, and has done since Luke Mewburn did lukemftp (later to be named tnftp) and Theo de Raadt did likewise, both based on the original 4.2BSD ftp, back in the middle 1990s.

* https://cgit.freebsd.org/src/tree/contrib/tnftp/ChangeLog#n1...

* https://cvsweb.netbsd.org/bsdweb.cgi/src/usr.bin/ftp/main.c?...

* https://cvsweb.openbsd.org/log/src/usr.bin/ftp/main.c,v?sort...

That does not really present any argument that we should be teaching your way of working to VIM novices, instead of teaching them the obvious arrow keys first and the hjkl navigation later.

The arrow keys can be used as motions for operators in VIM. Try them. This is also true for nvi.

Yes, hjkl navigation is certainly one of the things that should learn about a vi clone. But are novices well served, in the 2020s, by that being the primary thing that they learn before anything else?

This is not a criticism of this WWW site specifically. The VIM doco has the same priorities, teaching hjkl navigation before arrow keys. (So do nvi2 and NeoVIM.) The problem is that the received wisdom, that arrow keys are some newfangled idea that might not have reached your terminal manufacturer yet, is massively out of date.

Even if one does not teach the arrow keys first, the BS SPC SO (Control+N) DLE (Control+P) set is surely worth teaching early on. One cannot make any reasonable argument that terminals might not have spacebars. (-:

Given what is discussed in the commentary to the post, I wonder whether the author would be amenable to some Doxygen.

Also: You boot from the 'system' volume, and the operating system is stored on the 'boot' volume. (-:

* https://jdebp.uk/FGA/boot-and-system-volumes.html

'Windows subsystem for' actually has a similar sort of logic behind it.

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

Although Microsoft then spoiled that explanation a couple of years later by switching to a virtual machine system instead of the NT kernel emulating the not-present Linux kernel.

I wonder how many people immediately thought about whether similar things had been snuck into xfishtank and xpenguins.

The naïveté of that position is that the users are not informed ahead of time that there's a random chance of a political protest popping up on their screen, so do not get to make an informed choice before it is perhaps too late. It's not mentioned in the doco. It's obfuscated in the source code as an 'extra tree' in an array of xpmtrees. The commit that added this had the commit message 'willem'.

It is interesting to read M. Allbery's comment side by side with the discussion here on Hacker News about a CLAUDE.EXE program with hidden behaviour that subtly changes the way that it outputs an information banner based upon timezones, hostnames, and domain names.

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

Further LWN commentary (as observed at https://news.ycombinator.com/item?id=48736518) is that the result would not be solely drama but potentially some fairly nasty real world consequences for some people.

I am sure that DARPA, BBN, USC Information Sciences Institute, and many others will be overjoyed to learn that they've been erased from history by the new narrative that Venture Capitalists Built Everything. (-:

I am wondering whether there will be any effect to petition e-7124. It seems unlikely, to me.

* https://noscommunes.ca/petitions/fr/Petition/Details?Petitio...

We probably should not read too much into the fact that the Daily Mail's guide to what's currently on television no longer lists a documentary from 2023. Except, perhaps, that the Daily Mail's search engine gaming is clearly quite effective.

That's a television guide for what's currently being broadcast, published by the Daily Mail, not the actual documentary from 2023.

It's wild to see people having this argument in the subjunctive in 2026. I've had a convert-systemd-units tool since 2014, and provided Debian packages for the toolset that it is part of for around that long.

* https://jdebp.uk/Softwares/nosh/guide/commands/convert-syste...

* https://jdebp.uk/Softwares/nosh/guide/converting-systemd-uni...

* https://jdebp.uk/Softwares/nosh/debian-binary-packages.html

The annoying thing, looking at that, is that libnsfb (the library that netsurf-fb uses to construct its UI) once had a driver, deleted back in 2018, that could work directly with a Linux framebuffer device. This could have been easily adapted into a similar driver for wscons/wsdisplay/wskbd on OpenBSD and NetBSD.

* https://github.com/netsurf-browser/libnsfb/commit/b2bb565402...

Instead, libnsfb is now layered on top of SDL in the non-X11 non-Wayland case, with all of the dependencies and extra stuff that that entails, which of course you'll have to build. SDL3 explicitly doesn't handle dumb framebuffers and full wscons, explicitly requiring foreign KMS systems from Linux on the BSDs.

* https://wiki.libsdl.org/SDL3/README-kmsbsd

libnsfb then proceeds to ignore almost all of SDL anyway and draw its own UI directly, with SDL being little more than a glorified framebuffer-as-bitmap system with a couple of basic blitting operations.

* https://github.com/netsurf-browser/libnsfb/blob/master/src/s...

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 all of the repetitive common stuff.

* https://unix.stackexchange.com/a/480897/5132

* https://manpages.debian.org/trixie/sysvinit-utils/init-d-scr...

One of Masayoshi Son's recent slideshows has been doing the rounds on the FediVerse this week. If you've seen people making odd comments about 'Goose was not valued.' or 'Goose value 71.' or 'eggs do not lay eggs' over the past few days then Son's 2026 presentation to shareholders is what they are going on about.

* https://discuss.systems/@dev/116807460725864716

This is the context that a lot of us didn't have. Son has been doing this since 2010, the goose laying golden eggs going back to at least 2014, and the 2020 earnings report having a run of 23 slides of geese and eggs. Other weird things over the years have included dog telepathy and a representation of COVID-19 as flying unicorns jumping out of a ditch. As the Bloomberg people pointed out, this significantly came to the attention of the world outwith Japan, which largely boggled at some of the slideshows sans context, in 2019 and 2020. Part of the world is discovering this afresh in 2026.

* https://vice.com/en/article/these-delusional-powerpoint-slid...

* https://trillium.substack.com/p/golden-geese-stirring-the-po...

* https://group.softbank/system/files/pdf/ir/presentations/202...

* https://group.softbank/media/Project/sbg/sbg/pdf/ir/presenta... (https://group.softbank/en/news/webcast/20100625_01_en)

Some of the criticism over the years has focussed not on the more oddball aspects of these slideshows, but on the stereotypical way in which the graphs with projections just suddenly make lines shoot upwards.

Stéphane Chazelas would agree,

* https://unix.stackexchange.com/a/496642/5132

because the problem here is educating people with slipshod ideas about 'sh' being 'the POSIX shell' or (worse) 'the Bourne shell'. Both M. Chazelas and M. Gaigalas are making the point that 'sh' is a language that one aims to write in, not one of the many programs that sort of, sometimes, if invoked in the right way, implement that language; and a subordinate point that people are generally very poor about doing that when yet they insist that they are writing 'POSIX shell script'.

Fun facts: Standardization led by existing practice is not a simple process.

* https://unix.stackexchange.com/a/493743/5132

POSIX/SUS standardization is not a static thing. The long discussed thorny issue of echo has now subtly changed from all of those explanations given about it over the years, because in 2024 the standard was changed.

* https://pubs.opengroup.org/onlinepubs/9799919799/utilities/e...

M. Chazelas's own quite famous 2013 StackExchange answer on the subject has not yet been updated with the change that now incorporates -e and -E into the rule. Amusingly, it was M. Chazelas that raised defect 1222 that caused this change.

* https://unix.stackexchange.com/a/65819/5132

* https://www.austingroupbugs.net/view.php?id=1222