30 October

An empty machine beckons ...

Omni ignotum pro magnifico in the present like the past

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 ...

Posted by william at 14:55 | Comments (0) | Trackbacks (0)
31 May

Comment on "Porting UNIX to the 386: The Initial Root Filesystem"

A reader found another way

One of the series readers is a friend of many years, now in retirement. He reminded me of another clever way the initial root could have be formed.

Continue reading "Comment on "Porting UNIX to the 386: The Initial Root Filesystem""
Posted by william at 19:37 | Comments (0)
16 March

What was it like launching the "porting" series

Setting the stage for 386BSD in the early 1990's

At the time Jon Erickson and I agreed to do the series, DOS was the prime platform for the IBM PC/AT. Windows 3 wasn't very well regarded, and the most common alternative platform was probably a Macintosh 512K.

Less than 10% of those with a PC had a machine as advanced as a 20Mhz 386 with 4MB or more memory with a 100 megabyte hard drive. CDROM's were anticipated, but the primary storage medium was 5 1/4 inch floppies.

So the primary goal of the article series wasn't UNIX or BSD types, but PC DOS programmers. Which is why the focus was on a console only BSD system, knowing full well that "real" bitmap graphics was still years off from being commonplace. This shows up in the goals of the first article "DESIGNING THE SOFTWARE SPECIFICATION".

If we could just get a OS out there, PC developers would go crazy and build out whatever was necessary. The only problem would be holding them back from what should probably not be done ...

Posted by william at 21:41 | Comments (0) | Trackbacks (0)

Welcome to Jolix

Blogging the history of early open source OS

Greetings to Jolix, where to interact with the past and current items about 386BSD.

Its been 15 years since the article series and many questions and stories remain. We owe it to the wonderful readers of our series and users of 386BSD to reengange with them after such a long time. Especially as much that 386BSD tried to do still has not been done by the other open source OS's, or even by big, bad, old Microsoft itself.

Thanks to all of you, look forward to hearing from you.

Posted by william at 19:09 | Comments (0) | Trackbacks (0)