NetBSD 10 proves old tech can still kick apps and take names three decades later NetBSD 10 marks a new level of maturity for this venerable open source Unix system, which somehow manages to be both modern and retro at the same time. By our reckoning, including the minor point releases, NetBSD 10.0 is the 71st release of the NetBSD operating system. By the project's own measures, NetBSD 10 is the 18th major …
[Author here]
> SOC executables
Er. I feel ignorant, but what is one of those?
System on a Chip I know. Binaries identical to discrete-chip devices, so not that.
Security Operations Center? Trendy among security wonks although they rarely bother to define it, which annoys me, as SoC has precedence. But not an executable type.
Separation of Concerns? Service-oriented computing or Service-oriented communications? Selectable Output Control? Self-organized criticality? Second order concern?
Damn these TLAs!
I've not used it, but there's various binary compatibility options in the kernel - I always comment them out in the config file when building a custom kernel. But assuming you can get any required shared libraries if the program you want to run isn't statically linked then it would probably run on the default kernel as that has pretty much everything compiled in or available as modules.
>It supports a remarkable number of active "ports." One of the project's mottos is "Of course it runs NetBSD!" and that's fair – there's no other OS in the world that runs on so many different architectures and platforms.
Yet, no POWER (ppc64le), no RISC-V, no LoongArch, no IBM Z (s390/s390x), no Elbrus2000, no Itanium. All of which are or were at some point supported by Linux.
> All of which are or were at some point supported by Linux
Since as I am sure everyone is overwhelmingly aware by now, Linux being just a kernel rather than an OS delegates the task to distros.
Very few individual distros have access to (or have even heard of) such exotic hardware. So ultimately NetBSD does support more than amd64 and aarch64.
That said, Debian (and to a lesser extent Alpine) are one of the few distros that support a wide range of hardware. It is probably comparable, especially considering the old stuff that NetBSD used to support.
> NetBSD 10 proves old tech can still kick apps and take names three decades later
Since NetBSD was first released in 1993, it makes it more modern than Windows and Linux. It seems weird that people think of NetBSD being retro and not the others. The Windows NT kernel was even designed by one of the original VMS architects, giving it that retro feel.
In a sense I always felt NetBSD remains most true to the original heart and soul of the original Berkeley Software Distributions of Unix, and so in that sense it is also much older, too. But BSD has always been about what is new and possible, too. FreeBSD is initially somewhat friendlier to use as a desktop, especially with desktop focused variants like GhostBSD, but it is also more focused on chasing Linux distros and what Apple wants than simply being a BSD, and I do think this is okay, too. As for OpenBSD, well, the fish tribe is kinda "special" ;).
:-) Fair enough!
I want some new fresh exciting ones, actually, TBH.
I want a modernised 9front with the GUI of Inferno, with an built-in microVM so it can run Linux apps.
Actually, I want a modernised Inferno, with tooling that can accept stuff that targets WebASM and compiles it to Dis instead.
I want an updated 64-bit Minix 3 with working SMP and the whole NetBSD app catalogue.
I want a revived desktop-tweaked Symbian running on a Raspberry Pi 5.
I'd like to see someone, maybe the chap behind SerenityOS, revive Syllable.
I'd like some passing billionaire to pay the MorphOS team's bills, buy the Amiga rights and donate the whole shebang to AROS.
I'd like a modernised Parhelion HeliOS on a modern manycore CPU.
There's a lot of cool stuff that would be preferable to 50-year-old Unix code.
> I want a modernised 9front with the GUI of Inferno
The GUI of Inferno? Surely we should aim just a little higher? ;)
> Actually, I want a modernised Inferno, with tooling that can accept stuff that targets WebASM and compiles it to Dis instead.
True, to be fair I would be happy for a 64-bit Intel Inferno VM. I think it still isn't 64-bit clean! Maintaining Dis for different architectures is still quite a task (same with JVM and .NET)
> I'd like to see someone, maybe the chap behind SerenityOS, revive Syllable.
This guy does some cool stuff. I would love to see a port of the SerenityOS desktop environment to X11 (or even Wayland).
--- But good point, I guess there is still some modern stuff that is very interesting :)
I'm not sure why, but I'm convinced the time-slicing / pre-emptive multi-tasking on BSD is smoother and way more solid than Linux, especially when running out of memory and under load. Like when I whack the enter key, I see a new prompt straight away, I like that a lot. Maybe I will try put it on my iMac 2009 once I finish mixing my album... convert to Reaper from Logic.
[Author here]
> Yet, no POWER (ppc64le), no RISC-V, no LoongArch, no IBM Z (s390/s390x), no Elbrus2000, no Itanium
There are 5 different PowerPC ports:
ibmnws, macppc, prep, rs6000, ofppc
Risc-V is here:
http://wiki.netbsd.org/ports/riscv/
IA64 is here:
http://wiki.netbsd.org/ports/ia64/
Both are WIP.
Elbrus 2000? I have never laid eyes on one. Maybe the Russians don't care enough.
No S/390, true. Not terribly relevant to NetBSD's user base. I know of 2 people with IBM mainframes at home, but just those 2. (Guy Sotomayor and Connor Krukosky.) IO'm sure there are more. And there's Hercules. It's probably trivial using Linux code, though.
But as the presentation I specifically linked to says, on page 8:
«
A lot of the supported (Tier 2) architectures are kinda “retro”.
Dreamcast? Amiga? BeBox? SGI MIPS? VAX??
Real talk:
There is no modern hardware that runs NetBSD but not Linux.
»
https://docs.google.com/presentation/d/1ZzaW9eI4wmMRGOnJ1uo-kGk5b_UvIOuU9Zgur4au_8s/edit#slide=id.g6e14fde33a_0_7
Liam. To be fair, ppc64le is probably an architecture that they ought to support. All of the ones you quote are big-endian, but modern Power processors are bi-endian, and future OpenPower platforms will be little-endian by default, as the Industry has decided that they need to ape Intel processors for data compatibility without the XDR kludges that had to be built into NFS and other networked filesystems.
It does make sense to match the dominant architecture to keep a foot in the door for Power. Otherwise, it will be consigned to history, and IMHO the world needs more than just X86-64 and ARM.
NetBSD seems to count every single variation of a processor platform (e.g. Amiga PowerPC versus Mac PowerPC) as a separate “architecture”, whereas Linux counts them all as one.
So this idea that “there's no other OS in the world that runs on so many different architectures and platforms” seems a bit suspect to me: just name one platform where NetBSD runs, but Linux doesn’t.
[Author here]
> The oldest 32 bit only hardware I have in the cupboard is a Thinkpad T42, which is a powerhouse compared to i486.
I have an X41 sitting here. It led a complicated little life for a while after I compared it with my now-colleague Dan Robinson's one at a press conference about 20 or 25 years ago, but now it is mine again, but sadly minus its PSU brick.
I must buy a new one and get it working again. I think its RAM is maxed out but I could bung an SSD in it for £peanuts.
Your point stands, though.
Saying that, there are new x86-32 SoC embedded PCs on sale today. Things like these:
https://www.vortex86.com/
> Saying that, there are new x86-32 SoC embedded PCs on sale today.
The laugh is the these will be used in “simple” focused applications, so most of the processing power will be used by the application. I suspect if we were to measure the number of clock cycles devoted to a specific application per second (ie. Unit of time) it would not be dissimilar to what a current processor with all the overhead of current OS’s, background tasks annd concurrently running anpplicaions also devoted to the same application.
32 bit is my use-case for NetBSD at the moment, on a little ITX with a VIA C7 CPU.
I used to have a pair of those running pfSense, but 32-bit support went by the wayside there a while ago, and I never got rid of the hardware. Since then they've been mostly FreeBSD but now that 32-bit support is finally going away circa 15.0, and Debian is making similar noises, it was time to find something else.
So I revisited NetBSD. Previously I'd run it on SPARC, DEC, SGI, and even PPC Mac for a little while, but rarely on PC hardware. Imagine my pleasure (but not surprise) that most things still just worked as I remembered, and as this review illustrates, more things are even better. I returned to NetBSD with 9.3 and now 10.0 and look forward to continuing.
Hello NetBSD, it is very good to see you again.
I'd use it for the above, but wouldn't bother as a desktop - you're letting yourself in for a world of pain if you do.
I feel the talk under sold NetBSD - as a general purpose OS it is far below FreeBSD in usability (and FreeBSD itself needs to be better), but it's available on a lot of platforms, and should be able to be customised for an embedded system. It's all under a BSD license so you can use it without worrying about licensing concerns.
It's a very classic Unix with some modern parts and experimental bits, probably the easiest Unix OS to hack on, but there's far more bit rot than FreeBSD, or OpenBSD (who will ruthlessly prune functionality if they think it isn't being maintained). There's a number of gotchas - when I tried FreeBSD 9 with ZFS used for some of the non home partitions an extra config parameter was needed to allow it to work early in boot. Then, whilst ZFS may 'work' the underlying storage system and drivers might not support functions you'd want, such as hard drives not being present on boot, but redundancy still operating.
There's an awful lot of embedded devices out there, and I was going to try and shoe horn NetBSD on one for fun and as a cheap and easy serial to network server. I think I got it as far as a partial kernel load via TFTP, but without the compression that it should have supported, and then became distracted by other things. It's still on the list of things to complete, and creating an ultra customised boot environment that fits in a small amount of flash seems easier with NetBSD than trying other things.
This post has been deleted by its author
TLDR : If you want to run Windows apps under Not Windows with less hassle, use Linux.
Define 'work'. If you mean 'can you throw a modern game at NetBSD and expect it to work?', then no. You'll run into issues doing that on FreeBSD, and FreeBSD is in a much better state.
NetBSD has zero closed source display drivers, so you're stuck with Nouveau and AMD drivers, and they'll be behind those available on other OS.
There is WINE available, but it's an older version, and critically WINE under Linux is very different from other platforms. Although there is some commonality of APIs in Unix, there's still a lot of per platform customisation, meaning windows API coverage in anything other than Linux will be significantly worse.
Will Steam work? Almost certainly not. Some older games will probably run just fine.
:) You know, it actually might? I've never tried. It's from 2007 so it doesn't require Steam, sure I have it on CD. NetBSD's graphics support isn't amazingly up to date, but it definitely supports as late as the Vega 56, should be complete with 3D acceleration, so it can handle Crysis with one hand tied behind its back.
Which just leaves the question of whether sufficient APIs are emulated. An exercise for someone with a suitable system.
"We at NetBSD of course do not believe the OpenBSD tale about their security focus and consider NetBSD at least as secure (with less voodoo) – but that is hard to demonstrate or verify on a technical level."
I will caveat what I'm about to say here as someone who has tried to use OpenBSD, but such is life being what it is, I hit a roadblock and moved on to something else.
But in all the research I did about which *BSD to use, I often saw the OpenBSD security thing being thrown around with gay abandon but it never felt it was concrete. As in, how can OpenBSD be so much more secure than other *BSDs? Are the other ones woefully bad? It just felt like a lot of the time it was just trotted out because the author had heard it themselves without really delving in to it. So to read the above is refreshing because, really, that matches my own view of the situation.
OpenBSD has an excellent track record introducing new security technologies and focusing on that above pretty much everything else. That does not necessarily mean that for a given area it is the premier example.
When it was discovered data could be extracted from processes on a hyperthreaded 'core', the eventual response by Linux was a very complicated work around that had at least one failure along the process of fixing it properly that still permitted data to be extracted. OpenBSD's response? Disable hyperthreading by default. Game over.
OpenBSD has made real efforts in process separation, and also in memory management, enabling some extremely old bugs to be finally squashed. Not to mention The OpenBSD project doesn't just create OpenBSD, they're also responsible for OpenSSH, LibreSSL, OpenBGPD etc (see the OpenBSD Foundation page).
The *real* advantage of OpenBSD is that it's quite well documented, has a well thought out user land, consideration for embedded or remote systems, and a lean easy to use install. It did take it a bit too long to streamline the upgrade procedure beyond booting from an install ramdisk and upgrading, but sysupgrade has now been out for a number of years and it's usually as simple as running it, going for a cup of tea, and coming back to find a rebooted and upgraded system.
I wouldn't use it as a desktop. It's decent as a firewall and for other networking purposes, but it isn't designed as an end user system.
Some of it. It depends. They're all using the 'BSD license' but there are still subtle differences of opinion in pulling in certain third party code (one reason ZFS is in FreeBSD, but not OpenBSD).
If the OS architectures are compatible enough, the BSD projects will absolutely take work from another project where possible - all of them need more resource. There can still be significant differences in driver models, despite parts of the userland looking very similar.
The highest praise I can give for OpenBSD, is that it's possible to install it on a system such as a pcengines APU4[1] via serial console, & once installed use serial or SSH, and it's not at all uncomfortable. Serial console is easy to get working, installer is text based and very fast to use. Base system includes the tmux terminal multiplexer, userland commands are decent. Sure, some specific Linux distributions could do the same thing, but OpenBSD feels designed.
It's also the only BSD where I'd trust running CURRENT, it's rare that it breaks things, although obviously STABLE may be a little safer. FreeBSD's current isn't horrendous when I tried it but was a little irritating at times. NetBSD current was definitely more Here Be Dragons, but that was a number of years ago. I still haven't used DragonFly BSD.
[1] RIP PCEngines, such decent hardware.
There are maybe half a dozen current BSD variants still in some stage of active development, versus maybe 50× that number of Linux distros. Yet it is easier to move among Linux distros than it is to move among BSD variants.
Linux offers a greater degree of variety with less fragmentation, while the BSDs seem to be more about greater fragmentation and less actual variety.
> Yet it is easier to move among Linux distros than it is to move among BSD variants.
That's pretty subjective, and frankly lacking details / context.
My anecdotal take is it's about the same, but "it depends".
Eg. going from Debian to Ubuntu is easier in areas like installing packages, controlling services (since both are systemD), and potentially configuring the network (NetworkManager is there if you want it). MX and Devuan preserve the similarity of package management environment but need different things from service control (no systemD), and so on.
Migrating to a Red Hat family member from a Debian is a pretty different experience in package management -- yes, the concepts are similar across dpkg/apt-get/apt vs. rpm/yum/dnf, but syntax differences take some muscle-memory retraining, and some functions are found in different commands ("what pkg installed this file?" etc).
Plus the Red Hat family repos are sometimes disjoint, requiring non-default or 3rd-party repos (e.g. EPEL, ELrepo, etc.) to get some packages. I helped an Ubuntu person with a CentOS setup years ago, they were frustrated by the idea of needing extra repos, and befuddled by finding them in the first place. In that particular case I realized it wasn't so much the technical differences between the OSes or the tools, rather it was differences in the distributions' ecosystems, if you will.
SUSE has similarities with Red Hat but it's zypper doing the heavy lifting for rpm's, similar concepts as yum, but not exactly, so again it's different. SUSE/SLES came with Brtfs for the longest time (maybe still?) with it's own peculiarities separate from ext* or even XFS; shouldn't be a problem most of the time but it's another difference to be aware of. Slight diffs in grub commands and where things end up, stuff like that.
Arch, gentoo, slack et al from your "50x" claim are different yet again. Some are considerably so.
I'm just scratching the surface here. Most Linux installers are different, sometimes very; the distributions come with different kernel versions and configs, updates happen on different schedules, upgrades might be in-place, but maybe not, Beyond servers, the desktop environments and tools are many and varied, and so on.
I'm not claiming it's a seamless transition between FreeBSD / NetBSD / OpenBSD either; I could compose another entire post with their differences too -- e.g. similar refrains as package managers above, different firewalls, etc. At least rc.d and rc.conf are pretty similar among them, but they use different variables within, and sometimes different tools (vi/sed vs. sysrc etc.) for adjusting them.
Overall I tend to think you're glossing over many detail-devils among the "50x" Linuxes. They likely don't seem like significant differences to someone who is used to moving around across different Linux distributions or even distro families, but it can be jarring for a while e.g. if you're joining a Red Hat environment after using only Ubuntu.
There’s the simple fact that you can dual-boot multiple Linux distros, and have them share the same /home area. So you can easily “distro-hop” without having to keep copying all your user files from one installation to another.
There’s the fact that you can run the userland for one distro as a container with another as host.
And yes, Linux distros can be as different as chalk and cheese. Compare, say, Gentoo or Arch with Android, or something as completely off-the-wall as GoboLinux. Look at this idea of “immutable” distros. Look at “toolkit” distros like Kali or SystemRescue. The BSDs have nothing like that.
And what makes them all “Linux” is they share the same kernel.
This relates to something I noticed during the "Unix Wars" thirty years ago: there seemed to be a lot of effort devoted to compatibility for programmers but a lot of differentiation in the system administration tools. This surprised me because I thought that the system administrators would have more influence on purchasing decisions than programmers.
I still see the same thing today among Linux distros and BSD variants: the core application software is all very similar, compatible, portable, but configuration and system management are all very different.
> Proper old-school Unix
I'm re-reading Scientific American July 1985. On page 120 I find a thing a little like the Compaq flat/yellow-screen portable with paper coming out the top and a document, a space shuttle, and a calculator on screen.
Hewlett-Packard presents the first 32-bit UNIX™ system under $5,000.It's the one computer for both the technical and administrative sides of your job.
Introducing the Integral Personal Computer.
Don't let the small size fool you. This is definitely a full-fledged member of the HP 9000 family of engineering workstations.
With a 16/32-bit MC68000. A graphics co-processor. 800KB of standard memory expandable to 5.8MB.
And a multitasking operating system based on UNIX System III. It's a UNIX system that's easy to use. Its powerful but friendly user interface means even novices can now tap the power of this ideal operating system for technical tasks. There are no cryptic commands to learn. And there's an optional mouse.
It's a personal computer without the limitations. Like other PCs, it runs a variety of popular spreadsheet, graphics, database and word processing software. But unlike other PCs, it has the multitasking operating system, powerful microprocessor and programming flexibility for your specialized applications. Just what you'd expect from Hewlett-Packard.
Developing custom solutions on the Integral PC is easy, with optional programming tools such as HP Technical BASIC, HP-UX "C" and RealTime Extensions.
And the Integral PC goes where you need it. The complete system -including our built-in ThinkJet graphics printer- packs into a single 25 pound package that takes up less than a cubic foot.
So for the name of the dealer or HP sales office near you, call -----
The Integral Personal Computer. Perhaps the most capable personal computer you can buy. And it's only $4,995!
HEWLETT PACKARD © 1985
Note: Not even System V. Kernel in ROM. $5K was half the price of a 1985 Mustang GT. More factlets on Wikipedia.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
