Talk:Comparison of operating systems

Which of these should be added?

• Airline Control Program (ACP)
• Advanced Interactive eXecutive/370 (AIX/370)
• AIX/ESA V1 & V2
• CP-40
• CP-67
• DOS/360 through z/VSE
• Distributed Processing Programming Executive/370 (DPPX/370)
• Interactive eXecutive (IX/370)
• AIX for PS/2
• Michigan Terminal System (MTS)
• McGill University System for Interactive Computing (MUSIC)
• Multi-User System for Interactive Computing/System Product (MUSIC/SP)
• OS/360 through z/OS
• Transaction Processing Facility (TPF)
• Time Sharing System/360 (TSS/360) and TSS/370
• VM/370 through z/VM
• z/TPF

Should each version be listed? --Shmuel (Seymour J.) Metz Username:Chatul (talk) 12:07, 13 October 2021 (UTC)

Well it would be nice for comparison reasons. I would also suggest:

• RT-11

AXONOV (talk) ⚑ 16:36, 17 December 2022 (UTC)

IBM offered systems called Advanced Interactive Executive (AIX) for several systems not listed in the article not listed in the article:

1. RT PC
2. RS/6000
3. PS/2
4. S/370
5. S/370-ESA

In addition, the table shows AIX as being bundled with the hardware. All versions that I am familiar with are separately priced.

Should each flavor of AIX be listed separately? Should AIX/ESA Version 1 and AIX/ESA Version 2 be listed separately? --Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:35, 27 October 2021 (UTC)

@Chatul: The version of this page, as of 20:38, 23 October 2021, and the version of this page, as of 10:37, 29 October 2021, both list the AIX for that runs on RS/6000, System p, etc., so it's listed, even if it doesn't explicitly mention the RS/6000 or successor systems. You've subsequently added entries for IX/370, AIX/370, and AIX/ESA. The RT PC and PS/2 version might be worth listing as well.

As for "separately priced", that may be the case for IBM Power Systems, as they can run one or more of IBM i, AIX, and Linux, and may have been the case after the arrival of Linux, but does that date all the way back to the original RS/6000? Guy Harris (talk) 22:48, 13 November 2023 (UTC)

I suspect that AIX was separately priced on the RT PC, prior to the RS/6000. I'll check whether https://ibm.com/common/ssi still works and try to find RT PC and RS/6000 announcement letters. The announcement letters that I've seen have been my source for pricing models.

Some relevant program numbers for searches are

5669-061

RT/PC AIX

RT Personal Computer Advanced Interactive eXecutive (AIX)

5713-AEQ

AIX PS/2 V1

5713-AFL

AIX/370 V1

756-030

AIX for RS/6000 V3'

AIX for RISC System/6000 Version 3

5756-112

AIX/ESA V2

AIX/ESA Version 2

5765-030

AIX for RS/6000 V3

AIX for RISC System/6000 Version 3

5765-393

AIX for RS/6000 V4.1

AIX for RISC System/6000 Version 4.1

5765-655

AIX for RS/6000 V4.2

AIX for RISC System/6000 Version 4.2

5765-C34

AIX for RS/6000 V4

AIX for RISC System/6000 Version 4

I'm still looking things up, but for both RT PC and RS/6000 there was a one time charge (OTC) for AIX. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 12:24, 14 November 2023 (UTC) -- revised 14:11, 14 November 2023 (UTC)

Some of the terms used in the tables are ambiguous, unclear or unfamiliar to some readers. I propose adding a nomenclature section and have some incomplete text that may be a useful starting point:

The nomenclature for operating systems varies among providers and sometimes within providers. For purposes of this article the terms used are:

kernel

In some operating systems, the OS is split into a low level region called the kernel and hifher level code that relies on the kernel. Typically the kernel impliments processes but its code does not run as part of a process.

hybrid kernel

...

monolithic kernel

...

Nucleus

In some operating systems there is OS code permanently present in a contiguous region of memory addressable by unprivileged code; in IBM systems this is typically referred to as the nucleus. The nucleus typically contains both code that requires special privileges and code that can run in an unprivileged state. Typically some code in the nucleus runs in the context of a dispatching unit, e.g., address space, process, task, thread, while other code runs independent of any dispatching unit. In contemporary operating systems unprivileged applications cannot alter the nucleus.

License and pricing policies also vary among different systems. The tables below use the following terms:

BSD

BSD licenses are a family of permissive free software licenses, imposing minimal restrictions on the use and distribution of covered software.

bundled

The fee is included in the price of the hardware

bundled initially

The fee is included in the price of the hardware but upgrades require an additional fee.

GPL2

...

GPL3

...

MULC

MEASURED USAGE LICENSE CHARGES

MSU

The fee depends on the resources consumed by the user

PSLC

PARALLEL SYSPLEX SOFTWARE PRICING

Per user

The fee depends on the maximum number of users concurrently logged on.

I've arbitrarily listed the terms in alphabetical order; that might change with more wordsmithing. — Preceding unsigned comment added by Chatul (talk • contribs) 07:22, 28 November 2021 (UTC)

Is the concept of a "kernel" dependent here on the processor having some form of hardware-enforced privilege limitation, such as kernel/supervisor/monitor/... mode and user mode, with the kernel code running with more privileges than the higher-level (user mode) code?

What does "region" mean in "the OS is split into a low level region called the kernel and higher level code that relies on the kernel"? Does it refer to regions of physical memory, or is it (assuming the answer to the previous paragraph's question is "yes") just a distinction between code running with more privileges and code running with fewer privileges? If it's the former, does the "kernel" include all code running with more privileges? If so, note that, for example, code that supports loadable kernel modules does *not* necessarily have all the code running with more privileges in a single contiguous region of physical memory - or even a single contiguous region of virtual address space.

What does "[the kernel's] code does not run as part of a process" mean here?

"Monolithic kernel" should probably be put before "hybrid kernel", given that 1) I think most kernels fit in the former category and 2) I'm not entirely sure what distinguishes a "hybrid kernel" from a "monolithic kernel" (and I developed kernel-mode code for both).

What is the difference between a "kernel" and a "nucleus"?

A third possibility for a BSD-licensed OS's pricing is "free as in beer", possibly with a charge for the media if you buy a physical medium (CD-ROM, DVD-ROM) containing the OS release. Guy Harris (talk) 08:12, 28 November 2021 (UTC)

Did you mean for your text to not be indented? Shouldn't it have leading single colons?

I believe that the original concept of kernels implied some sort of architected privileged mode, but I'll dig out the original paper and check.

I would distinguish between the kernel itself and loadable kernel modules, but what does the literature say?

I can't comment on monolithic versus hybrid because I wasn't the one that used hybrid in some of the table rows. My concern is just that it be spelled out and then used consistently.

By region I simply mean a block of contiguous memory.

By "code does not run as part of a process" I mean that it is not using the stacks or translation tables of any specific process, but is either running with no translation or with global translation tables.

Would it be better to create a working document in the draft namespace of to just edit the proposed text with appropriate <s>...</s> and <i>...</i> markup? --Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:45, 28 November 2021 (UTC)

Yes, I meant for it not to be indented; as most of your original text was indented, indenting it with single leading colons made it difficult to distinguish the comment from your text. Therefore, I removed the leading colons; an alternative would have been to use two leading colons, or to add an outdent arrow. Adding your note after the indented text fixes that problem, so I'll re-indent my text.

"By region I simply mean a block of contiguous memory." That would, at minimum, require that we distinguish between the kernel and loadable kernel modules, and thus distinguishing between different pieces of code running with the same elevated privileges.

"By "code does not run as part of a process" I mean that it is not using the stacks or translation tables of any specific process, but is either running with no translation or with global translation tables." "The stacks of any specific process" would have to mean "the user-mode stacks of any specific process; at least some OSes assign separate kernel-mode stacks to separate processes or separate threads. In addition, whilst the kernel code and data may reside within a global portion of the address space, it may access user-mode data - and sometimes, even read user-mode code - via the current process's translation tables. In addition, kernel-mode CPU time might be counted per process (as it is on UN*Xes) and, with preempt able kernels, even time-sliced on a per-process basis. Guy Harris (talk) 20:21, 28 November 2021 (UTC)

Worse than that, some systems have more than two privilege levels.

As an example of the difference between systems for which the literature uses the term kernel and other systems, in MVS an authorized program can enter Supervisor Mode and can change its protection key. This is quite different for the layered design normally assumed when discussing kernels.

Similarly, some code in the MVS nucleus can run in either problem state or supervisor state.

IBM has several types of usage based licensing. Should the table mention them individually, or just show them all as usage based? --Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:03, 30 November 2021 (UTC)

That section still needs clarification on what "does not run as part of a process" means. As noted above and in the edit summary for a {{disputed inline}} I added to the article, "[the kernel's] code does not run as part of a process" depends on what "as part of a process" means; the code may be shared code rather than per-process code (although that may also apply to shared libraries) and use shared data rather than per-process data (but that may also apply to userland code), and may not use the same stack as the process's userland code, but it often runs in the process's thread of control, with per-process kernel stacks. Guy Harris (talk) 21:50, 13 November 2023 (UTC)