NetBSD 9.3: A 2022 OS that can run on late-1980s hardware Version 9.3 of NetBSD is here, able to run on very low-end systems and with that authentic early-1990s experience. When The Reg FOSS desk took a quick look at the latest version of FreeBSD a few months ago, some NetBSD enthusiasts were quick to point out that NetBSD is (very, very slightly) older. Since then, it has been on …
At least 20 of us, myself included, are glad you couldn't resist.
Although I suspect the young'uns around here won't have a clue as to what you're riffing on!
If you want to get a feel of what installing Linux was like with the very earliest Linux distros, such as SLS, installing NetBSD is a very similar experience. I have occasionally done it for nostalgic reasons, but never used it for long before leaving it to the shelf (many of my machines have some NetBSD VirtualBox VM sitting around for this reason).
One problem with NetBSD (and an itch I should scratch some time) is installing non-English keyboards and UTF-8. You can ask for a Finnish keyboard in the installer, but affects only the bare console and has no effect in the X11 session. This needs a separate setting (I think it involved XDM setup files).
(Icon? There wasn't the nice BSD daemon in sneakers available, so I had to use that)
> In my day we had 7-bit ASCII and maybe EBCDIC
At least you had brackets and backslashes, you rich bastards!. When I started, most Finnish terminals used a hacked ASCII where [\]{|} was replaced by ÄÖÅäöå. Have fun writing C in it.
if (strcmp(line, "fooÖn") == 0) ä
arrÄiÅÄjÅ ö= 1;
å
Some ADM3A terminals in the Helsinki University of Technology had a little retrofitted switch that flipped between ASCIi and the Finnish character set ROMs. If you used it, the text on the screen would change instantly between brackets and letters.
My Kaypro 2X had character map in a ROM, I dumped the ROM, crafted the bitmaps for {}[]/|, then burned into a EPROM, soldered it piggy back over (a copy of (just in case)) the original character map ROM and fitted a toggle switch to CS line. Worked a treat (even without a fancy debounce on the switch).
Sounds like someone had the same approach for those ADM-3As.
-> We fear that there may be unhappy comments from outraged NetBSD enthusiasts, just as there were from FreeBSD fans when we said that in testing it failed to boot from ZFS and didn't handle multiple partitions well.
I was one of those who raised some objections in the comments about this. Your statement about ZFS "in a VirtualBox VM, trying to install onto ZFS failed" was flat out wrong. I have FreeBSD on ZFS (and UFS) in VirtualBox and there is no problem at all. I asked for some clarification about the multiple partitions as I didn't clearly understand what you were trying to do. Original article: https://forums.theregister.com/forum/all/2022/05/20/freebsd_131/.
NetBSD is indeed a good learning experience, and this is why it is useful. Alas, there are some Linux people around today who think that Linux "just works". Well it does usually, but when it doesn't those same people are usually stumped. I did my share of fsck and recovering files from lost+found. The puzzlement of seeing LI on a screen, and learning how to fix it. In my view Linux has become more complicated. And more complication means you need more knowledge when things go wrong. Anyone who says "it doesn't go wrong" means "it hasn't gone wrong for them [yet]".
I won't demean NetBSD in any way - they have their project goals and good luck to them. But for a desktop I would (and do) use FreeBSD instead.
I tried to use Linux in the year 1999, emphasis on "tried". Had more luck with a very early live CD but you couldn't do anything save use the text editor. A few years later I succeed in making MP3 files work and I was so darn happy on a Linux distribution I can't remember the name of. Even so I formated the HD and went back to WIN98SE because games.
By the year 2008 I tried a horrible Linux distro then nuked ir and tried Ubuntu and was happy with it until Gnome 3 and Unity desktop happened. Nowadays I use Mint.
If I want to suffer I think I will try to get online using Freedos instead.
Yes, I know you were, but you did not get at what I was saying then and you don't know.
I am not saying "this is impossible" or "this can't be done". Clearly it can by someone familiar with the OS and the filesystem.
What I am saying is "I tried it and it didn't work". And I absolutely 100% stand by that. I *did* try it and it *did* fail.
You do not get to say "Your statement was flat out wrong" because you were not standing on my balcony in Prague watching me do it. Indeed, you made a comment on a previous story saying that a Linux distro was defective because it geolocated me to Prague, which shows that you did not understand that piece, either, and you apparently did not read my byline.
I *am* in Prague. Geolocating me to Prague is correct. It is the right thing to do. However, if I pick English as my installation language, then the right thing to do is then use English for the locale as well, or at least ask.
I did the test. The test installation failed, in a VM and on bare metal as well.
I do not know why it failed. The purpose of my article is to convey what the experience of using the OS is like for a non-specialist who is not a BSD expert.
And the reason I do _that_ is because a lot of people don't like things like BSD, Snap, Flatpack, Wayland and other modern Linuxisms. A valid answer to them is: then don't use Linux. Try BSD instead.
I am not a BSD expert. I've been experimenting with BSD for a good 15 years or more, but I am not skilled with the OS, whereas I have over 25 years of experience with Linux and I was using xNix boxes 3 years before Torvalds announced Linux 0.01.
So what I look for is how the experience is if you aren't a BSD expert and try to apply Linux knowledge to BSD: including OpenBSD, FreeBSD and now NetBSD.
The answer is: it doesn't work very well, it's hard, it's complicated, stuff fails or doesn't work, and if you are not very skilled in xNix in general, NOT just Linux, then you will have a bad experience.
I think this needs to be said, and a primary reason why I think it needs to be said is because every time I say it, angry BSD people pop up and tell me I am wrong. What that tells me is not that I am wrong: it tells me that there are special steps and special measures and special things you must do, which require specialist BSD knowledge, to do this stuff. If you lack that knowledge, it won't work.
When I say that an installation failed, *that means it failed.* Either it failed to boot or it failed to install or it failed in some other way.
So kindly stop telling me that things that happened to me, which I recorded and published, didn't happen. Because when you do that, you are calling me a liar, and I strenuously object to that.
How huffy people inexperienced with BSD get when they think their Linux knowledge is *as good*.
Let me quote from your article. "In our testing, in a VirtualBox VM, trying to install onto ZFS failed".
For me that tells me that when it comes to *BSD your knowledge is limited, which you admit, because I do not have the same problem. Installing FreeBSD with ZFS in a VirtualBox VM, it installed first time without any problems. I have to ask "What is Liam Proven doing wrongly?"
That is not being one of the "angry BSD people". It is a very reasonable question.
> the NetBSD terminal doesn't directly understand modern luxuries like cursor keys and command-line editing
Of course NetBSD supports command line editing:
1. Use ksh shell
2. type: set -o vi (or add: export EDITOR=/usr/bin/vi to /etc/profile)
Command line editing with vi keys is supported in ksh.
<ESC>k shows previous command
<ESC>/ps searches for the last command containing the string "ps" , type "n" to show next commands containing "ps"
At my employer we use NetBSD quite frequently in security sensitive applications, it is perfect for use as an appliance.
That's a blast from the past. I remember nagging my manager 30-odd years ago to buy ksh for our System V boxes because it was such a pain in the arse making a typo on a long command line (my usual trick was and remains hitting ] at the same time as return...). Fortunately he required little convincing and while my typos remain as bad as ever they instantly became much less annoying.
Edit: weirdly, I still use emacs editing keys; weird because I never liked emacs in the first place. I preferred ed, and since entering the full-screen age in the mid '90s I've always used vi or one of its clones. I would say "old habits die hard" but I never used Esc-Meta-Alt-Control-Shift enough for it to become a habit. *shrug* etc.
I find the whole issue of problems with command line editing as being strange on a BSD derived OS.
Firstly, historically, the default shell on BSD systems was csh, which is where the whole concept of command line editing came from. You did have to use ed style substitutions, rather than traversing the command line with cursor editing keys (I won't say the arrow keys, because back in the day, not all terminals even had arrow keys, and some which did only worked in local mode - which is why vi used h, j, k and l). It worked, but it was different (as was the csh itself!)
Secondly, it seems that the default shell on NetBSD is now an updated version of sh, which is on it's way to becoming a full POSIX shell. I just did a bit of digging, and quickly came up with the man page for sh(1) from NetBSD 8, which includes the standard POSIX'y section on command line editing.
The abomination of the multi-character escape sequences that ANSI X3.64 terminals (which include almost all xterm and putty variants) send when specific-function keys are pressed (plus the change in strings when application-keypad mode is selected) is one of the reasons why the arrow keys didn't work in something like ksh86. The problem is that back in the day, it was not unusual for strings of characters that were generated by function keys to be split into two network packets (even when using 'directly connected' terminals, as things like DEC terminal servers and IBM remote terminal nodes that pretended that the terminals were not run over a network), which on slow networks meant that from the start of an escape sequence to the end, 4, 5 or even 6 characters later, could be 10's of milliseconds. As the recognition of function keys by libcurses includes an element of time, to try to differentiate sequences of keys that might just be typed, compared to sequences of characters generated by function keys, long string commands from ANSI function keys were unreliable.
ksh88 did allow you to set up key macros to recognize multi-character sequences as single key presses, and even integrated with terminfo to do this for you if you knew how to set it up, but it was still flaky. You could make it more reliable by setting $TIMEOUT to something like 1000 (1 second), but even this had side effects. Most users just stuck with the vi sequences, or sometimes gmacs or emacs sequences.
As I said on a post on the other article, talking about FreeBSD, often these things not working are often an indication of administrator or user error.
As a counterpoint, non-editable command lines were a feature of other contemporary systems and shells such as non-VAX DCL and MCR systems, CP/M and early MS-DOS systems etc.
(previous user of Bell Labs. Edition 6 and BSD 2.3 systems - long before Xenix!)
I am aware of the issues of terminal support. In my time, I have used a wide variety of dedicated hardware terminals, including various ages and series of DEC VTs on both VAXen and PDPs, Wyse terminals, Alpha Micro terminals, all manner of IBM terminals, and more besides.
I know it is not trivial or easy.
But this is the PC version of the OS, and PCs do not need terminals. PCs only normally need the built-in console, and come with a standard PC layout keyboard, or a smaller layout that emulates it.
In an OS that supports the PC, I expect the standard baseline hardware to work as expected, *by default*. If it does not, that is a failure IMHO, and I will write about it.
It is not "administrator or user error" if a default boot disk does not support the hardware it booted on in its standard default config.
If I booted it on one of my 1990s 680x0 Macintoshes with one of my 1990s Mac keyboards, I'd expect that to work correctly, too. BY DEFAULT. I have an 68030 Amiga as well. I have never tried NetBSD on it and I'm not inclined to, but if I did, I'd expect the keyboard to work correctly. My Amiga doesn't have Ins/Home/End/PgUp/PgDn keys, so I would not expect them to work. It doesn't have F11 or F12. That is fine. It is normal and standard.
I would not expect a PC keyboard to work on a Mac, or a Mac keyboard on a PC. That is not standard or default.
I expect the standard hardware to work, out of the box, straight off the disk, unmodified and without any further configuration.
I expect every key on the keyboard to do what it says on it. I also object if, to pick a not very hypothetical example, my editor's tutorial says "press the Meta key". I don't have a Meta key. No new keyboard made in the last 40 years has a Meta key.
I have Shift, Ctrl, Alt, AltGr, and CapsLock. I don't even have a Windows key, because I like old keyboards.
So I expect the help to reflect what the PC has by default, and I expect them all to work.
Failure to support cursor keys _is failure_. Requesting or instructing the user to press keys that are not present on any PC made since the first one in 1981 _is a failure_.
And this in general is, I think, why the BSD OSes haven't achieved a lot of traction in the market. The usage of the main 4 variants is probably well under 1% of Linux usage, and Linux (excluding ChromeOS and Android) is only a few per cent of Windows and macOS usage.
1% of 1% is poor. And one reason it's so poor is that because the BSDs have failed to properly embrace the PC platform and support it fully.
Examples are the keyboard not working correctly by default, and requiring strange specialist partitioning schemata, with disk slices and so on. PCs with a BIOS and an MBR have up to 4 primary partitions and one extended partition with logical drives in it. That's how DOS and Windows worked for over 25 years (Vista changed it somewhat, as did x86-64 machines with UEFI).
OS/2 works that way -- badly, but it does it. Linux works that way.
The BSDs do not, and require a primary partition with their own weird subpartitioning system inside it. Weird because it is not the PC way.
I feel that that was only borderling acceptable in 1988 or so when 386BSD appeared. It was completely unacceptable by the 1990s when 32-bit PCs became the standard.
And that was over 30 years ago.
Linux has always been pragmatic: it uses the partitioning system that DOS and Windows imposed. It uses the PC keyboard, a good choice because now all computers have PC keyboards, from the Raspberry Pi to an IBM z Series server with a console on the Support Element... which is really an IBM Thinkpad.
The PC won. Modern RISC boxes are PC clones with weird CPUs. Even Intel Macs are PCs in some ways can can run PC OSes.
It's over. The IBM Enhanced Layout won.
https://deskthority.net/wiki/IBM_Enhanced_Keyboard
It's everywhere.
Even if NetBSD's default shell is csh with code from the 1970s, I expect it to support the keyboard, fully and properly. There is no excuse. That has been the world's default keyboard layout for nearly 40 years now, since before NetBSD first existed. By the time the first NetBSD release, 0.8, was made on 19 April 1993, the IBM Enhanced layout -- with small variations -- had been the default keyboard for everything, from the Mac to the Atari ST to the Amiga, for nearly a decade.
It should have supported it correctly then, and it should now.
It doesn't.
It needs special config. That is unacceptable. In my book that is a failing, and that is why I pointed it out in the article.
Thing is, NetBSD dosn't have "ease of use" as one of its design goals. What it aims for is clean design, code clarity and portability between platforms.
It cannot be guaranteed that cursor keys exist on any given platform, therefor the default doesn't include them. Said keys are (technically) a non-standard, and they are not required to admin the system.
However, I actually agree with you, and argued the point in that world for many years ... Last time I asked, virtually all the devs use a Model M (or derivative) .. you'd think they'd see the utility. But no, 'we've always done it this way" rules the roost. Furrfu! Frankly, I've given up.
Note that in the later stages of BSD (pre NetBSD), many of us were still using Knight, Symbolics or SpaceCadet keyboards, which did not have cursor keys. Some experimented with early Sun2 keyboards (the Sun1 was an abomination), and a little later the Model M. By the time of the late '80s, certainly by the release of 4.3BSD-Tahoe, anyone with a central nervous system could see that the cursor keys were here to stay ... Why newcomers like NetBSD refuse to see this is beyond me.
Cats or programmers. Which is the reincarnation?
OK, this may be somewhat contentious…
My only computer is BSD derived and works well with a PC keyboard. It uses macOS (via Darwin). Remembering Command/WIndows and Option/Alt wouldn’t be difficult if I used a USB connected PC keyboard. Certainly when I used PC-BSD, the PC keyboard was well supported by the CLI, but the OS was discontinued in 2020 (TrueOS). Perhaps the reason for BSDs low take-up probably wasn’t just an easy PC keyboard and partition compatibility?
I started with BSD on DEC, then SunOS, etc., which may be why I still prefer it to the many varieties of Linux that I have used. I’m retired now, but if I needed to build a Server, I’d probably still look at OpenBSD…
I think you missed the point of my writeup, and also missed a later part of it.
I did not say this problem could not be fixed, or was insoluble, or that there was no way to configure it worked.
In fact, I said the opposite: once I had installed Xfce, things like keyboard editing suddenly started working. That is good.
What I said is that it didn't work out of the box, and I stand by that. It doesn't work out of the box. In the default config, on an x86 PC, left-cursor and right-cursor don't work. Neither does cursor-up or cursor-down.
I feel that they should work, and if they don't, that is a problem to be fixed _in the default config_.
Other keys may work, but I want and expect the arrow keys on my keyboard to do what they do in every other OS. They don't. I said so.
First off, thank you for covering NetBSD - I have a soft spot for it, since I've run it on a number of architectures ever since 1.3.3 back in the late 1990s. However, I would like to clear up a few things raised in your article.
Firstly, VirtualBox disabling SMP is a deficiency in VirtualBox. NetBSD has very good SMP support, and at one time was able to outperform Linux on the same hardware for things like PostgreSQL. Not sure whether that is still the case, but the clean code makes it an attractive platform for people who want to optimise specific workloads.
As for the installer, I find it very simple and straightforward. Perhaps not as "newbie friendly" as something like the graphical installers in the Linux world, but on a par with the text installer that I regularly use in Debian. Unless my memory is going, it defaults to selecting the C shell as the default shell, which is something I always change to the Bourne shell. NetBSD's Bourne shell supports the key niceties of Bash, such as command line history and editing via the cursor keys. I assume the C shell is left as the default for historical reasons.
Partitions can be set up in the installer, including the setting of mount points for any existing ones (such as Linux ones for example). As for wireless networking, while the driver support is far less comprehensive than in Linux, the most common chipsets are supported. I ran NetBSD as my primary OS for development on a Dell laptop for five or six years, and never encountered an issue with wireless networking.
The installer also offers the option to install the pkgsrc tree - this is the configuration files for building all third party packages. Alternatively, the already present pkg_add command can be used to install binary packages. I've never heard of "pkgin".
As for documentation, did you not read the comprehensive and excellent Guide that is linked under the Documentation section on the NetBSD homepage? I've always found it bang up to date and covers the essentials such as installation, first time configuration after an install as well as things like pkgsrc,
As for installing Xfce, if you read the NetBSD documentation and not some random stuff from another website, then you'd know it's as simple as a single pkg_add command or "make install" if you want to build it from source.
"It is the recommended tool in NetBSD's own documentation"
No, it is not. Let's look at that complete sentence, shall we? It says:
"Binary packages can be installed with the high-level tool pkgin (which can be installed with pkg_add) or pkg_add(1) (installed by default)."
In other words, pkgin isn't the default, but may be added. The actual recommended and default tool is pkg_add (at least for this particular piece of the puzzle). Poor wording? Absolutely! But you'll get that in projects where people from all over the world, for some of whom English is a second (third, fifth ...) language. Documentation always needs help. Anyone who would like to contribute to the FOSS world but can't code might do well into looking into this neglected aspect.
It also goes on to point out:
"The NetBSD packages collection is also designed to permit easy installation from source."
Quite. And by far the best option. Highly recommended.
I'm reading that as a recommendation to use pkgin for installing anything except for pkgin itself, which must be installed with pkg_add. I also infer that pkgin is a user-friendly replacement for pkg_add. If that isn't what it's saying then there seems to be no reason for pkgin to exist and be mentioned.
No, but it should be possible on a Sinclair PC200 :-)
(Obviously, it's post-Amstrad purchase of the Sinclair name. ISTR another one that was a PC but had a cartridge slot or a built in Spectrum emulator or something. Or I may be confusing memories of multiple systems that did two job in one box)
My first dabble into Linux was a Slackware LiveCD and a thick book.
Install Linux? Nope. The first page talked about getting going enough to compile a kernel for your own machine...
I gave up soon after, because the thing violently objected to whatever the graphics hardware in my PC was (some sort of S3 clone, I think).
But, yeah. Kids these days. When your book begins "First compile your kernel", you know you're into new territory.
Heh, as a long time NetBSD (now FreeBSD) user a lot of the comments just sound like the differences between different *nixs than anything else.
I find similar experiences on Linux when I occasionally use it. Sure I know uparrow won't produce ^[ but I still have never worked out how to paste in 'vi' without the auto formatting kicking in. (I know it's vim, but vim on the 'BSDs by default isn't configured to do it, and I can never work out what I need to change).
It's just unfamiliarity with a thing that looks simliar to the thing you're familier with. Like driving someone elses car for the first time.
Modern Linux is, well, a modern OS. By default, it supports things like cursor keys, wireless networks, and multiple disk partitions, some of which may be in use by other OSes. The top command uses fancy PC console features such as bold fonts.
Whilst I know what you mean with that comment, as NetBSD can feel very archaic to someone used to Linux, it's probably still worth pointing out that NetBSD is also a modern OS. It's quite happy running on multi core servers with plenty of RAM as well as an Amiga.
(I personally started using it as my home router OS on a Risc PC 24ish years ago, and a decendent of that install was still running until I switched to FreeBSD a few years ago. The hardware was a multi core AMD part by that point though, with a few gig more memory than the Risc PC).
I switched to FreeBSD to get ZFS and Plex support, however there are still aspects of NetBSD I miss. It's a lovely OS.
IME one person's "archaic" is another's "clean".
Every time I have to do something to work with (or around) systemD, NetworkManager, et al I appreciate the BSD's a little more.
Similar situation with the ... soap opera ... from Red Hat and RHEL vs. CentOS & Stream -- the corporate shenanigans just leaves a bad taste in the mouth, which you won't really run into with FreeBSD or NetBSD (or OpenBSD and DragonFly et al for that matter).
My daily laptop runs Debian today, CentOS in prior iterations (before Stream), but I've also run FreeBSD on previous laptops and I'd be hard-pressed to really differentiate their functionality beyond the noted differences between BSD vs. Linux command syntax.
Admittedly, I installed Bash for my shell in all cases, so yes: "up arrow" and the like worked the same. :-)
Thanks to the folks who took the time to describe their use-cases for NetBSD. I was genuinely curious about that, and was wondering why someone would choose such a "primitive" OS. Even though I harken back to command line DOS, and to a lesser degree command line Linux, I really am happier just running my Mint box for everything.
And dear god, reading the installation saga convinces me that I've made the right choice. Life is too short for such things to have novelty appeal for me.
Man pages. Dear god no.....
Life is too short for such things to have novelty appeal for me.
That's a good attitude to have, sometimes once the fun in the playing with stuff stops then just having stuff that works is what you need.
I used FreeBSD for my server for this reason, I grew up on NetBSD and could still install it and get an internet router for my home network setup very very quickly; whereas I'd be lost trying to do the same in Mint.
If friends ask for a non windows OS though, I point them at Mint.
Man pages. Dear god no.....
Man pages are one of the things that really (used to) set NetBSD apart from Linux for me.
All the documentation is there, I can read it on a terminal if I have to.
Using linux and finding that 'the documentation is available in POD format at <url>' used to be really unhelpful when I was ssh'd in without a browser handy.
GNU has improved in this area over the last few years too.
Not only is the BSD man page documentation right there, no browser needed, but the quality is generally really very good as well.
And beyond the usual tools and commands too -- you'll also find man pages for device drivers and more. I remember being surprised and very pleased the first time I tried something like 'man fxp' on a BSD and sure enough, the man page for a common Intel 10/100 NIC driver came up.
Granted, reading a man page maybe isn't as easy as a typical cut-paste walkthrough on somebody's blog, but if you want to start to _understand_ rather than just _do_, those well-crafted man pages can be a valuable resource. And reading them is a skill worth having.
Granted, reading a man page maybe isn't as easy as a typical cut-paste walkthrough on somebody's blog, but if you want to start to _understand_ rather than just _do_, those well-crafted man pages can be a valuable resource. And reading them is a skill worth having.
Learning to read is one of the great skills in IT, as in not just skimming for the answer, but making a brew, setting some time aside and reading the man page or documentation properly. (This often takes a few reads).
Once you've done that you'll understand whatever it is much better.
A trick I've learnt over the years is to stop every few paragraphs, and ask yourself if you actually understand what you're reading, if you don't go back and start again.
Most people lose the thread of the thing they're reading a few paragraphs before they realise, there'll be a term that you won't understand fully, and it won't register as you're reading it, but that'll be the start of the incomprehension.
"A notable improvement in NetBSD 9.3 is being able to run a graphical desktop on an Amiga."
This is not strictly true - you've long been able to run a graphical desktop in NetBSD on an Amiga. I know this for a stone-cold fact, because I was the maintainer of the NetBSD/Amiga FAQ around .. *counts on fingers* ... 28 years ago, and you could do it then.
28. Christ.
I know what you mean.
And I do think there is a real danger of a lot of stuff being forgotten and lost to history as we old-timers just age out and die off.
Then a whole bunch of weird old stuff will just be carried on because it's how it's always been done, and nobody knows why.
AFAICT, from the docs, the Amiga's console graphics were supported for a long time, and then it was broken and stopped working because some kind of update moved to a more general model of framebuffer support and the Amiga method was no longer supported.
Now it's back again.
Some of us were using both MS-DOS and UNIX.
Early DOS had no command-line editing except destructive backspacing over the current line.
Later, we had 4DOS (even later, NDOS, which worked in a couple places 4DOS didn't, & vice versa).
Later still, Microsoft included rudimentary command line editing, but we still used 4DOS.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
