On Tue, Sep 5, 2023 at 7:16 AM Paul Ruizendaal via TUHS <
tuhs@tuhs.org> wrote:
One pitfall I would like to avoid in my own thinking is conflating “installing” and “booting”,
That is an excellent point. I think that the real question comes back to how 'cold' the 'system' is.
Booting is the process of making the processor 'live' including the loading of the 'initial memory contents' (IBM used to call it IPL for Initial Program Load), while 'installation' is setting up a 'system' which 'lives' in the peripherals as long-term storage. When you 'Power-On' a CPU, you often need to IPL a system even if the peripherals have been set up [back in the day of core memory, you might not even have that as the OS was not lost when power was removed].
The starting point seems to be a setup where a small set of standalone programs is used to load or repair the bits, as was done for 16-bit unix.
You are solving the 'chicken and egg' issue. Truth is Ken's famous "Reflections on Trusting Trust" comes to bear here. The fact is you are 'setting up' (or restoring) a system for bits that were generated on another. The critical point is that you are setting the initial 'systems' bits into the peripherals for that specific system. You are relying on making copies of those bits from another system. The question is how to get them into the new media.
All the standalone system is doing is offering you a minimum way of making a copy of that other system without having access to its hardware directly.
A next conceptual step seems to be where first a very basic system is installed that is then used for further installation or for repair. This step seems to have come early, if this 32V install page is reflective of how it was done back in 1980: https://gunkies.org/wiki/Installing_32V_on_SIMH The idea to use disk swap space for this also seems to have come early (and I suppose the concept lives on in “rescue partitions”).
Newer versions of the system setup scheme offer more and more features, as the options of how you set up might be different from the origin system become greater and greater. Modern OS implementations of the Unix technologies now run on a much more comprehensive range of devices, and frankly, 'IPL' much less might be set up from so many different types of sources, it's not surprising that the IPL schemes and the system setup scheme are a lot more sophisticated.
But remember, when you examine the past scheme, you must also consider the constraints of the timeframe (particularly the economics of certain choices). It's not that you could not have built something like some of today's schemes — it was expensive with respect to what was available and, frankly, not wholly necessary.
Another conceptual step might be where early installer phases run a different, smaller kernel (or even OS) than the one being installed. There seems to be much potential for a “wheel of reincarnation” here where as an installer grows large, a pre-installer is created to load the installer and then the pre-installer grows large, etc. For booting, this wheel seems to have turned about 5 times in current Linux. Installing that from scratch on a fully blank SBC (without prepping a removable disk on another computer) also appears to have 4 or 5 revolutions. That is one revolution every 5 years for the 25 years from the late seventies to the early 2000’s.
The circle started long before that. For instance, the boot/IPL got more flexible (like Sam's autoconfiguration work developed for VAX). Why? Because the HW configurations had begun to branch and get bushy. Even with the PDP-11's peripheral set in V7, it was getting more complex. But those kernel configurations were statically linked. Sun added dynamic linking, making both IPL, much less setup/installation more complex. But frankly, to do that on an earlier machine took a lot of work. BSD2.9 did backport much of the VAX work but not all of it. It was often too difficult, and the 'gain' for the effort was low.
So my modern UNIX implementations, be it macOS, *BSD, or the Linux family, the schemes have matured and been recreated over and over. For instance, you can look at what Apple's done with its system install scheme. It hides the setup/tear down as of the root and then makes a read-only root system under the covers. This is both a blessing and a curse. Sure, it helps make things a lot more secure for them and basic users, but that choice breaks traditional admin scripts [which drives me nuts think - /etc/periodic] because the new Apple system implementors don't understand why the core system works the way it does and thus those of us that have scripts have worked since V7 in the late 1970s, now don't.
Clem