From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HTML_FONT_LOW_CONTRAST,HTML_MESSAGE,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 4874 invoked from network); 5 Sep 2023 14:16:14 -0000 Received: from minnie.tuhs.org (2600:3c01:e000:146::1) by inbox.vuxu.org with ESMTPUTF8; 5 Sep 2023 14:16:14 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id B816540BB6; Wed, 6 Sep 2023 00:16:03 +1000 (AEST) Received: from mail-ua1-x92e.google.com (mail-ua1-x92e.google.com [IPv6:2607:f8b0:4864:20::92e]) by minnie.tuhs.org (Postfix) with ESMTPS id 0DCD5402EF for ; Wed, 6 Sep 2023 00:15:55 +1000 (AEST) Received: by mail-ua1-x92e.google.com with SMTP id a1e0cc1a2514c-7a505727e7eso916125241.0 for ; Tue, 05 Sep 2023 07:15:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ccc.com; s=google; t=1693923354; x=1694528154; darn=tuhs.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=6DfQ4YViQpvPGTtpzSBzorcGLhARWFJUwA6ejeg/FFA=; b=N6OoDWIKvM4ctL92Wyy5YTguUefUqO6S3IBjduxY9nWqCyhnN923Xv4NfrBqEI1fni CXLghHuqXCfjPNFMEIrStgp4XvB22/lnK/WtSeHSvIpbrZxt+O+IwuL3xar24sC8crtQ rbPFvesUG2Bv04AMVJZ7NYWrAwFQsZ6lhk7ZM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693923354; x=1694528154; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=6DfQ4YViQpvPGTtpzSBzorcGLhARWFJUwA6ejeg/FFA=; b=Uv5BSIWtg9GbGY7mNVGmd5wJwEKQYo0Wa9H6jeWg0RyJsjKUkZTMbdPwUCr2qX92ym zs+hTNSUam40TL+SlQONrL+q05Ogs/Q+w6hGS7h+chZEhEhrKk3JVAlMa0JaOK9gGGPH H1q+/wCmJckaFkhxVbfainZwcCtIQfWIqaFVKeA09EcBy6dj2ra5MI+TiKs6cKBIk5t+ Kpshi8uTyu7vgozMuaie4yR5J0qgXj5chNIZuekUyUqf1B3fVXvEGxIO5nV6+qACjdR0 8gKbrIU9yA51an1EaN92iD1PQjt+gPXyEjtSmgQATpst6G39GSE8cuNwnuCp3bw8ovsN cMKg== X-Gm-Message-State: AOJu0YwCR15bTHami2F3dXC1cQrq6eCwZVkAAjQWK09SgisqlDZNfBMW S69E/N7kVE724PINyfgH/9vJKjcRJ1A7gOaY6H9aH74+ile9ntOOVxFCJQ== X-Google-Smtp-Source: AGHT+IFPD8sJ8wFLuEUL+nM4E79borE3nPjzLhglSURpDzUKP241eT7y3tPpnTq65RIIXUU5GYP1rzklRpBmM6FnP24= X-Received: by 2002:a1f:c843:0:b0:48d:5de:3053 with SMTP id y64-20020a1fc843000000b0048d05de3053mr10173823vkf.14.1693923353617; Tue, 05 Sep 2023 07:15:53 -0700 (PDT) MIME-Version: 1.0 References: <8D99EBF7-CB1D-48EF-B6AD-914B45D48A5F@planet.nl> In-Reply-To: <8D99EBF7-CB1D-48EF-B6AD-914B45D48A5F@planet.nl> From: Clem Cole Date: Tue, 5 Sep 2023 10:15:17 -0400 Message-ID: To: Paul Ruizendaal Content-Type: multipart/alternative; boundary="000000000000c4fcb406049d43b7" Message-ID-Hash: NPG5HB65YST26GOK5ZBGLSVDNDWOZBX5 X-Message-ID-Hash: NPG5HB65YST26GOK5ZBGLSVDNDWOZBX5 X-MailFrom: clemc@ccc.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: "tuhs@tuhs.org" X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: Unix install & "standalone" package List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --000000000000c4fcb406049d43b7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable below.. On Tue, Sep 5, 2023 at 7:16=E2=80=AFAM Paul Ruizendaal via TUHS wrote: > One pitfall I would like to avoid in my own thinking is conflating > =E2=80=9Cinstalling=E2=80=9D and =E2=80=9Cbooting=E2=80=9D, > 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 =E2=80=9Crescue partitions=E2=80=9D). > 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 =E2=80=94 it was expensive with respect to what was availab= le 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. Ther= e > seems to be much potential for a =E2=80=9Cwheel of reincarnation=E2=80=9D= here where as an > installer grows large, a pre-installer is created to load the installer a= nd > 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=E2=80=99= 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 =E1=90=A7 --000000000000c4fcb406049d43b7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
below..=

On Tue, Sep 5, 2023 at 7:16=E2=80=AFAM Paul Ruizendaal via TUHS <<= a href=3D"mailto:tuhs@tuhs.org">tuhs@tuhs.org> wrote:
One pitfall I would like to av= oid in my own thinking is conflating =E2=80=9Cinstalling=E2=80=9D and =E2= =80=9Cbooting=E2=80=9D,
Tha= t is an excellent point.=C2=A0 I think that the real question comes back to= how 'cold' the 'system' is.=C2=A0

Booting is the= process of making the processor 'live' including the loading of th= e 'initial memory contents' (IBM used to call it IPL for Initial=C2= =A0Program Load), while 'installation' is setting up a 'system&= #39; which 'lives' in the peripherals=C2=A0as long-term storage.=C2= =A0 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 mi= ght not even have that as the OS was not lost when power was removed].=C2= =A0


The starting point seems to be a setup where a small set of standalone prog= rams is used to load or repair the bits, as was done for 16-bit unix.
You are solving the 'chicken= and egg' issue.=C2=A0 Truth is Ken's famous "Reflections on T= rusting=C2=A0Trust"=C2=A0=C2=A0comes to bear here.=C2=A0 =C2=A0The fact is you are 'se= tting up' (or restoring) a system for bits that were generated on anoth= er. The=C2=A0critical point is that you are setting the initial 'system= s' bits into the peripherals for that specific system.=C2=A0 =C2=A0You are relying=C2=A0on making copies of those bits from another s= ystem.=C2=A0 The question is how to get them into the new media.

All the standalone system is doing is offering you a=C2=A0m= inimum way of making a copy of that other system without having access to i= ts hardware directly.


A next conceptual step seems to be where first a very basic system is insta= lled that is then used for further installation or for repair. This step se= ems to have come early, if this 32V install page is reflective of how it wa= s done back in 1980: https://gunkies.org/wiki/Install= ing_32V_on_SIMH=C2=A0 The idea to use disk swap space for this also see= ms to have come early (and I suppose the concept lives on in =E2=80=9Crescu= e partitions=E2=80=9D).

Newer versions of the system setup scheme offer more and more feat= ures, as the options of how you set up might be different from the origin= =C2=A0system become greater and greater. Modern OS implementations of the U= nix technologies now run on a much more comprehensive range of devices, and= frankly, 'IPL' much less might be set up from so many different ty= pes of sources, it's not surprising that the IPL schemes and the system= setup scheme are a lot more sophisticated.=C2=A0=C2=A0
But remember, wh= en you examine the past scheme, you must also consider the constraints of t= he timeframe (particularly the economics of certain choices).=C2=A0 It'= s not that you could not have built something like some of today's sche= mes=C2=A0=E2=80=94=C2=A0it=C2=A0was expensive with re= spect to what was available and, frankly, not wholly necessary.

=C2=A0

Another conceptual step might be where early installer phases run a differe= nt, smaller kernel (or even OS) than the one being installed. There seems t= o be much potential for a =E2=80=9Cwheel of reincarnation=E2=80=9D here whe= re as an installer grows large, a pre-installer is created to load the inst= aller 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 s= cratch on a fully blank SBC (without prepping a removable disk on another c= omputer) also appears to have 4 or 5 revolutions. That is one revolution ev= ery 5 years for the 25 years from the late seventies to the early 2000=E2= =80=99s.

Th= e circle started long before=C2=A0that.=C2=A0 For instance, the = boot/IPL=C2=A0got more flexible (like Sam's autoconfiguration=C2= =A0work developed for VAX).=C2=A0 =C2=A0Why?=C2=A0 Because the HW configura= tions had begun to branch and get bushy.=C2=A0 Even with the PDP= -11's peripheral set in V7, it was getting more complex.=C2= =A0 =C2=A0But those=C2=A0kernel configurations=C2=A0were statica= lly linked.=C2=A0 Sun added dynamic linking, making both IPL, mu= ch less setup/installation more complex.=C2=A0 =C2=A0But frankly= , to do that on an earlier machine took=C2=A0a lot of work.=C2=A0 =C2=A0BSD= 2.9 did backport much of the VAX work but not all of it.=C2=A0 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.=C2=A0 For i= nstance, you can look at what Apple's done with its system install sche= me.=C2=A0 =C2=A0It hides the setup/tear down as of the=C2=A0root and then m= akes a read-only root system under the covers.=C2=A0 =C2=A0This is both a b= lessing and a curse.=C2=A0 Sure, it helps make things a lot more secure for= them and basic users, but that choice=C2=A0breaks traditional admin script= s [which drives me nuts think - /etc/periodic] because the new Apple system implemen= tors=C2=A0don't understand why the core system works the way it does and thus those of us that have scripts<= font color=3D"#0000ff" style=3D"font-family:arial,helvetica,sans-serif"> ha= ve worked since V7 in the late=C2=A01970s, now don't.

Clem
3D""=E1=90=A7
--000000000000c4fcb406049d43b7--