A critical look at NetBSD’s installer

That romanticizes a vision of Unix that hasn't existed for like four decades, aside from maybe Xenix bitty boxes from Radio Shack servicing two terminals in auto shops, video stores, and the like. People bought Unix workstation and server systems specifically to run large, complex applications. Applications that did many things and kept their configuration in binary blobs or XML files. Stability, security, comprehensiveness, and ease of administration are stronger selling points for these systems than simplicity.

As an example of how comprehensive beats simple in the real world, consider Microsoft Outlook. Not just email, but calendaring and contact management. Microsoft's engineers discovered that in the business world, these things go together and bundled them into one, well-integrated program. Outlook ate everybody's lunch, including Windows-based mail clients like Eudora. Integration with Exchange let these services be provided together on an organizational level, fully integrated with Active Directory, and Exchange came to dominate email server deployments over Unix-based solutions which were more piecemeal. Easier to administrate as well.

NetBSD is a fantastic tinkerer's operating system, one of the most hackable ones out there. But let's not kid ourselves here. The philosophy it supposedly embodies hasn't really served real needs in a long time, if ever. Customers want solutions, not hacks held together with shell and Perl scripts.

> a tangled mess of systemd units

Ironic you use that term when a number of systemd units is often the simplest way of cleanly, reliably orchestrating services and daemons, doubly so when theres any level of complexity or limitations you want to confine one too.

Its cute to romanticize a bunch of scripts to run and orchestrate things but its a nightmare I'd not wish upon my enemies. Less moving parts, yet conceptually more complex to properly manage beyond the basics with far more that can and likely will go wrong.

> Text-first, scriptable interfaces where tools do one thing well and can be composed

emacs

> Human-readable configuration in plain files, no XML or opaque binary blobs

emacs

> Predictable, minimal system design where you can understand what’s happening under the hood without chasing abstraction layers

Maybe emacs

> Manual pages that matter, and a userspace that favors understanding over wizard-driven opacity

Probably emacs. Do I care about man when there is info?

I agree with that. Modern Unix is a 6-of-one-half-dozen-of-another type situation. Yes, terminal emulators and the termcap database are improved. But now, the traditional Unix user might be surprised at how things are done. I have accepted that ... systemd ... manages my networking now (ok, it's networkd or something I guess?). But if you can't accept that, it's good to have some option that just uses ifconfig.

Really? Is that actually really true that they cannot get past the spec?

Because I followed the Wikipedia article to the article on The Register. Whoever wrote Wikipedia summarized El Reg's entire article as how gemini has been critized for excluding people. 1 sentence. But that's only what the headline says, for clickbait. The actual article body paints a very different picture, including the rather subtle (by Register standards) rebuttal of that criticism by pointing out that WWW browsers and the Internet are not in an everything-is-a-nail-and-I-have-this-hammer situation.

So I wonder how true it really is that there's this wave of criticism, and how much that is rather inferred from people reading headlines and nothing else beyond them. Like the Wikipedia author did.

That said, having discovered the existence of Gemini today, I am now wondering how much of a doddle it would be to add a gemini UCSPI-TCP server (which would obviously have to sit behind something like Hoffmann's sslserver) to Bernstein publicfile. The publicfile way would of course have a separate off-line tool to turn index.gopher into index.gemini, once at content generation time instead of over and over at runtime.

Hmmm.

Stop giving me distractions, people! I'm supposed to be getting the next djbwares running on NetBSD. (-:

P.S. I have had the GOPHER server that I added to publicfile running for some time. I use it to publish a not-very-secret list of packages and source archives. It gets some quite odd requests in its logs.

IIRC it can't even show images, which I see as a big issue. I'm usually a fan of alt protocols.

Nice, I have to figure out how to add that to my site.

Don't be too envious. Linux kernel virtual terminals have "vcsa" devices that one can read for this sort of thing. And it's right there in the manual page how one does this.

* https://man7.org/linux/man-pages/man4/vcsa.4.html

They suffer from being straight copies of CGA, which has historically had a lot of conflation of boldness and brightness, as well as a very limited colour gamut that will make you weep at what your 256-colour TUI programs are reduced to. The NetBSD ioctl supposedly has a bold attribute in a separate field of the structure to a bright colour. Which in the backwards-thinking world of terminals where some people still have the CGA Think that bold=bright, is almost heresy. Still. In 2025. (-:

If you are looking for this sort of thing in a GUI/TUI terminal emulator that is a user application program, rather than the terminal emulators that are built into the NetBSD kernel or into Linux, then that's a different kettle of fish entirely. I know of one that provides a direct vcsa workalike. I wrote it.

* http://jdebp.info./Softwares/nosh/guide/commands/user-vt.xml

GNU screen works by having a server maintaining a buffer, and a client that attaches to the server and then renders that buffer's contents onto the client's own terminal. So in theory one might be able to access the display of GNU screen in a similar manner by making something that pretends to be a client. But how much of this mechanism even operates when GNU screen is in serial terminal mode, I don't know off the top of my head.

The same goes for tmux, of course. And indeed mosh. Although the documentation of the actual protocol was a not-done to-do item, promised in the early publicity for mosh but never delivered, for years. I kept checking back for quite a while to see whether they'd documented it as promised.

There's at least one GUI terminal emulator that stores its scrollback area to file, but only the scrollback area. GUI terminal emulators generally do not expose this sort of thing, though. It's some complex private data structure in the emulator process's memory, usually.

All that said, wscons is a fairly good-looking API. Certainly better than the undocumented mess that is fbio.

I assume NetBSD supports some sort of multiplexing for the local console? In which case it will need to have some sort of text buffer for each virtual terminal to maintain state when it’s off screen, and I guess they’ve decided to expose it to the outside world?