[TUHS] Unix install & "standalone" package

[Clem Cole]

below..

On Tue, Sep 5, 2023 at 7:16 AM Paul Ruizendaal via TUHS <tuhs at 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
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.tuhs.org/pipermail/tuhs/attachments/20230905/b9b82138/attachment.htm>