An empty machine beckons ...

So here's an empty laptop once again. Every time I've begun a port, I've always faced a completely empty machine and sought to fill it.

With 386BSD, it started on a "lunch pail" 16 Mhz 32-bit first generation 386 with 2MB of memory and a 40MB 5.25" hard disk with 1.2MB floppy - where 386BSD got its name. This time the empty machine is a bit bigger - claiming 3,500 Mhz of 64-bit 8th generation with 512MB of memory and a 250,000MB 2.5" hard disk with a 4,700MB optical drive.

I'd like to say that since 386BSD that OS+distribution has gotten 200x better. That gets to the first question I'm seeking to answer - what is necessary for an OS+distribution to improve beyond current limits?

How we answered this before was to supply a PC user base with a derivative of VAX/BSD that was scalable to PC developers (e.g. we knew hardware would rapidly develop but knew software would lag hardware). The part that was "old" BSD was to us just a starting point. The part that mattered most was where one could go with it. Modular extensibility to compartmentalize software development and adaptive administration to lessen the burden of a more complex personal OS environment turned out to be what we found as the then limits we were exploring.

To begin, one needs to understand the state of the art to understand where the limits are. So, putting other 64 bit OS's onto the same hardware, we get a understanding of the limits of usability that a user gets when they attempt to use them. In this way we can compare many and get an idea of where they go awry in joint - the bigger picture of what an OS needs to do to exceed the current limits.

And with this we start with the installation of a system adjacent to our OS in development, on the same hardware and under the same situation IDENTICALLY, down to erasing("zeroing") the drive before installing.

When we tested 386BSD installation, we had found how incredibly small things made installation fragile/breakable.
Back then, the context of definition of the "PC platform" was not very refined - you couldn't even depend on memory layout nor BIOS compatibilty. There were some hardware devices that would jam the bus on reference, and some issues where spontaneous resets occured for unknown reasons (later found to be chip bugs of certain steppings).

So in starting to install OS's, it wasn't surprising to find that it didn't work right the first (dozen) times. That it required finding "magic combination's" of hardware configuration to complete. In one case it required disabling certain BIOS and OS features involving power (ACPI and processor fan), as well as disabling network updates of software during installation. Even with these, other surprises were present.

Partitioning software embedded in the install process "core dumped", jamming the installer (later traced to the way the drive had been cleaned from another OS having been left with an partition table that provoked an error). During the analysis of this, it was found that there were unrecoverable situations with hard disk formatting that required wiping the disk to recover, and even with that certain ways of partitioning the drive would create peculiar errors. At one point, a partially wiped drive core dumped the installer as it mounted a filesystem that was severely damaged and attempted to use it! Another case was where an operation for formatting appeared to be rerun, apparently because a script was run that wasn't waited for properly, and due to media delays was postponed and thus thought to have failed thus was reissued on timeout.

Then as now, the semantics of the installation environment are the culprit of errors. Clearly one area of improvement that's obvious is that we need to save accross the network all installation attempts and the differences in environment of what is encountered and how the installation process coped with it. Perhaps a way of bettering things with this knowledge would be to refine a decision tree of scripts on a network accessible site to try on encountering novel issues automatically.

So it begins ...