winscape 2348

I don't know whether this is a good sign or a bad sign, but what you describe above sounds a lot like what I might have produced if asked to describe what happens "at boot time", based on what I remember about 1970s-era IBM mainframes and what I've been told about current machines (which is probably somewhat PC-centric, but I think not completely exclusive of other machines).

Ohhhh, the *human* .... I was interpreting "installer" to mean a program .... More below.

Okay ....

As I said in a reply to another post in this thread (by Scott Lurndal), I'm realizing now that although I remember the terms "cold start" and "warm start" from my years working with 1970s-era IBM mainframes, I'm not sure I was ever clear on the difference between them.

So. I took "installer" to mean a program that takes bits from "installation media" (which I was interpreting to mean o-s-vendor-supplied media, unmodified by any per-site configuration), combines them with per-site configuration information (provided either by direct input from a human using a keyboard or mouse, or in the form of configuration files), and writes the result (which I'll call here "the installed-configured o-s") onto some medium from which the system can be booted ("IPL"ed in IBMspeak). This seems to me to be a reasonable description of what in PCspeak is called "installing the operating system" and what in IBM-mainframe-speak was called "system generation (sysgen)".

(What I think I'm doing here is explaining how I understand things to work, with the goal of doing some sort of compare-and-constrast, rather than presuming to instruct anyone.)

The PC version of this "installer program" seems to require direct input from a human (keyboard or mouse), and to be intended to be run on the same hardware that will run the "installed-configured o-s". It therefore can probe the hardware to gather some information needed in the configuration process. Since it is started (booted) from a removable medium (e.g., CD), no buttumptions need to be made about whether there is already a usable operating system on the hardware where it's running. It writes its results onto the disk(s) of the hardware where it runs, in the form of an "installed-configured o-s" that can then be booted. It can also be copied (by doing a bit-for-bit copy of disk contents) to other similar-enough hardware.

The IBM-mainframe version of this "installer program", if I remember right, took input in the form of configuration files, which among other things described the hardware on which the "installed-configured o-s" was supposed to run. It ran on any hardware, and wrote its results onto some specified disk(s), normally not the ones containing the "installed-configured o-s" of the system on which it was being run. These disk(s) would then become the medium from which the "installed-configured o-s" would be booted, either on the hardware where it was produced, or on some other hardware.

The differences between these two processes seem to me to say something about a difference in mindsets, but I'm not sure I want to try to describe it.

Anyway.

Do either of these map in any reasonable or interesting way onto your "cold start versus warm start" terminology? My guess is that "cold start" maps approximately to the "installation" process I just described, while "warm start" maps approximately to what is called "rebooting" in current parlance. But I might be still misunderstanding, and possibly no exact translation is possible.

It seems to me that this applies only to the very first step(s) of what in PCspeak is called "booting" and what in IBM-mainframe-speak was called "IPL" -- the step in which some bits are read from the "boot device" into memory, and control is transferred to the code just read in. As soon as one does that, there is code running.

snip

Well .... The example I had in mind when I wrote the above was a somewhat protracted discussion, at a meeting of all faculty, of the exact wording of the official document describing academic regulations for students, specifically the part describing how many courses students could-should take per semester. Most students, most semesters, take 15 "credit hours" (usually five courses). The debate was about whether this should be described as the "normal" course load, the "expected" course load, or .... I forget the details, but it seemed to me that the argument was about distinctions among words that would not be significant to a lot of the potential readers of the document. I found it mildly entertaining that the few people who seemed to care cared so much, and were able to more or less hijack a meeting of people who mostly didn't care. No opinion, then or now, about who was right or wrong.

It's my understanding that this sort of thing still happens in the groups that develop, e.g., standards for programmming languages, and they regard it as important for just the reasons you give. I do too, FWIW.

"Inadequate feelings of superiority"? no, I can't seem to parse that one.

Oh well. I think it's just possible that my confusion about what you mean by this term is a result of your sometimes applying it in a way that consbreastutes at least hopping, if not outright leaping, to conclusions .... I think there are frequently "two people divided by a common language" problems.

Here's a previous attempt by me to define what I thought you meant.

Is that even close?

And then here's another exchange, from the part of the thread discussing ownership of files:

(me)

(you)

"Only one thing at a time" and "one user" seem consistent with what I thought you meant. I'm not so sure about "infinite resources", since I would have thought that was more likely to be buttumed by people using a multiuser system than by single-user-system users. Further, you've said often that people using a good time-sharing system perceive it as .... No, maybe I'd better not try here, but the description does seem to imply unbounded resources, to me anyway.

I'm going to reply to the rest in a separate post. This is long, and there's too much of a range of topics ....

snip

-- B. L. Mbuttingill ObDisclaimer: I don't speak for my employers; they return the favor.