Summary

  • The 8 November announcement listed five binary target groups available at that point; HP 9000/300 was pending, while DECstation, some Sun 3 and some VAX ports lacked complete binary distributions.
  • NetBSD’s formal 1.0 pages list six architectures and say the hp300 binary used 1.0 source with patches 01 and 02.

A source tree can look generous. A complete release has to do the awkward work.

The NetBSD Project dates version 1.0 to 26 October 1994. The clearest snapshot of what people could obtain comes from Chris G. Demetriou’s 8 November release announcement. The dated list separates release-ready binaries from work still underway. It says binary releases were then available for Amigas, i386-family PCs, some m68k-based Macintoshes, PC532, and SPARCstation (sun4c)-class machines. Five target groups, each named in public.

That list is useful because it draws a line around a real deliverable: a binary release. Its wording separates a finished binary distribution from source code that still needs work. The distinction mattered to anyone choosing an operating system for a particular machine. A port in the source tree and a complete binary release asked different things of the person on the other side of the download.

HP was not a quiet sixth item

The same announcement says a binary release for the HP9000/300 family is expected, but not yet ready. The formal NetBSD 1.0 information page lists six binary architectures, including HP 9000/300. Its hp300 release page supplies the engineering footnote: the binary was built from 1.0 source with patches 01 and 02 applied. The page says those patches fixed bugs that had been blocking the hp300 release.

That is a more revealing record than a compatibility list. The project’s page names Charles Hannum as maintainer and Jason Thorpe as builder. It also gives the machine’s edges: the release had been tested on systems with as little as 7.5M of RAM, and a minimal installation without X or source fit on a 120M disk. Here “HP support” stops being a line in a port table. It becomes a stated source base, two named fixes, people responsible for the port and a bounded installation target.

Source support had its own status

The November announcement also names DECstations, some Sun 3 models and some VAXen as targets present in the source tree. They were not far enough along for a complete binary distribution. The project’s port-history table dates its pmax, sun3 and vax entries to months before NetBSD 1.0. Work on a port had begun; the finished release package had not caught up.

That gap exposed release engineering in public. Source support let the project name a machine and keep work moving toward it. A binary distribution asked for the additional labor of making a complete, usable release for that target. NetBSD’s own record keeps those jobs separate instead of using “portable” as a magic word that makes the last step disappear.

The official pages leave the HP binary’s release date unstated, so its delay cannot be measured; they do document the 1.0 source base and two required patches. The important figure is the distance between five and six: a target could be in the source tree, yet still need its own fixes and a complete binary before the project could call the distribution ready.

That is how portability reached users: one target, one release artifact, one honest status at a time.