Talk:Comparison of operating systems

What decides whether an OS is worthy of being on this list?

There are plenty of major and very significant operating systems missing from this list, certainly from an historical perspective. I'm guessing that a lot of it was compiled by someone relatively young, which is fair enough. I think it's a worthy endeavor and would probably extend this list myself, but what goes on it?

For an OS to be distinct, it needs to be really distinct. For an example every should understand, take Microsoft Windows. There have been two versions; one was a GUI running on top of MS-DOS (up to and including Windows ME), and the other is Windows NT, which was a re-write (from 3.5 IIRC, up to the current 6.3 and 10) - Microsoft's commercial names aren't relevant.

To be noteworthy, you can't decide it based on peak installations or whether its current. For example OS/360 had a major impact on computing, but has been defunct for many years and as it only ran on mainframes (realistically) the installed based must have been in the thousands.

Of the top of my head, some major operating systems missing include CP/M, Multics, VMS, Wang VS, MVS, VM. Others would include AppleDOS, TRS-DOS, OS-65, OS/9, Mirage.

I'm only counting systems that are independent of the hardware and run on more than one manufacturer's kit. This is a pretty arbitrary distinction. I've also not added any major RTOS families (e.g. OSEK/VDX). And then there are problems like Digital Research's GEM. This GUI/Application environment ran on top of DOS in the same way as pre-WindowsNT Windows did, so how can you call one an OS and not the other? And where does X-Window fit in (the same sort of thing running on top of *NIX)? And Android is just a GUI running over Linux.

If I was to spend any time expanding this, a consensus on what counts as an OS is needed first!

86.191.110.175 (talk) 16:33, 14 April 2016 (UTC)

Question : Why is Ubuntu not part of this list ? It is part of the GNU/Linux family but it is incorrect to state that this OS has not been updated since 2018.... We are really missing important OS information about one of the most used Operating system from the Linux world... Why hiding this information. From my point of view, the current list is misleading (eg. Ubuntu 20.04 is not listed) --Svergeylen (talk) 11:23, 25 May 2020 (UTC)

Yes, it's because it's part of the {GNU/}Linux family; to quote the second paragraph of the article:

Because of the large number and variety of available Linux distributions, they are all grouped under a single entry; see comparison of Linux distributions for a detailed comparison.

The "Current stable version" column for GNU/Linux says "4.19 (kernel)", and the "Release date" column says "2018, October 22 (kernel)"; that clearly indicates that the GNU/Linux row tracks only the kernel, not the other GNU and non-GNU components of GNU/Linux distributions.

And, yes, it's incorrect to state that it hasn't been updated since 2018 - or that the "current stable version" of the Linux kernel is 4.19 - because, at least according to https://www.kernel.org, the current stable kernel is 5.16.4, which came out on "2020, May 20". The article states that because nobody's bothered updating it.

So 1) the GNU/Linux line being out of date has nothing to do with Ubuntu in particular, it has to do with this article not getting enough updates in general and 2) if you want Ubuntu-specific information, go to comparison of Linux distributions. Guy Harris (talk) 19:19, 25 May 2020 (UTC)

What is the "Predecessor" column supposed to mean?

The "Predecessor" column doesn't appear to be used in a consistent fashion.

We have:

• MVS, the predecessor to which is given as OS/360;
• OS/390, the predecessor to which is given as MVS;
• z/OS, the predecessor to which is given as OS/390;
• z/VSE, the predecessor to which is given as VSE/ESA;
• z/VM, the predecessor to which is given as VM.

MVS was a virtual-memory successor to OS/360, with an extended version of the OS/360 API and ABI, so I can see it as a successor. OS/390 was, I think, mostly a new marketing name, with support for whatever features System/390 added. z/OS's big change was support for z/Architecture, the 64-bit version of System/3x0. In all cases, they could be seen as a successor.

The same applies to z/VSE, a 64-bit version of VSE/ESA (which went all the way back to DOS/360, but we're not showing VSE/ESA or its predecessors)and z/VM, a 64-bit version of VM/370 et al.

Windows (classic 9x family) lists MS-DOS and "Windows NT 3.5" as its predecessors. It's not a successor to NT 3.5; it's more of a successor to DOS and the classic Windows 3.x family, including Windows for Workgroups 3.11 (at least one book says that its internal architecture is based on that of WfWg 3.11). Its main connection with the Windows NT series is that it implements a subset of the Win32 API/ABI originally provided by NT 3.0.

Windows (NT family) lists OS/2, Windows 9x and MS-DOS as its predecessors. The NT project was originally going to be the basis of OS/2 3.0, and early versions have OS/2 compatibility, so it could be seen as a successor to OS/2. It's also a successor to Windows 9x in the sense that, eventually, Windows XP was offered as a "home computer" version of NT, in place of Windows 9x, although it's not a simple predecessor/successor relationship.

macOS lists NeXTSTEP and BSD as its predecessors; NeXTSTEP is certainly a technological predecessor, but the OS it replaced was largely the classic Mac OS - probably some NeXTSTEP users bought Macs and used them, but it was mostly Mac users who sent to Mac OS X, as it was called at the time.

FreeBSD and NetBSD list 386BSD as a predecessor; they were both forked from 386BSD, which I think was mostly defunct at that point, so they're successors in that sense. DragonFly BSD and OpenBSD list FreeBSD and NetBSD, respectively, as predecessors; that's just forking, neither turned into replacements.

Several commercial UNIXes list "UNIX System V" as a predecessor; those are more like forks, in that the vendor started with some flavor of System V and went from there. Solaris lists "SunOS" as a predecessor; Solaris (in the SunOS 5.x-based sense) is part of the System V Release 4 project, where SVR4's predecessors would be SunOS 4.x (not just BSD - the BSD parts of SVR4 came from SunOS 4.x, as did the non-BSD-style VM subsystem and VFS layer, for example) and System V Release 3.

OpenVMS lists RSX-11M as a predecessor. That relationship is "an RSX-11M-flavored OS for the 32-bit PDP-11-flavored VAX"; it wasn't a replacement in the "you can run it on the same machines as RSX-11M" sense or in the "fork" sense. At most, it's a 2-bit version of RSX-11M, although it has a lot more than just 32-bitness, and could only run RSX-11M programs due to early VAXes having a PDP-11 compatibility mode.

(An editor had marked "Linux" as a predecessor of Android; that fits none of those patterns - Android is a Linux distribution, as the GNU/Linux distributions are, combining the Linux kernel with a userland. In the case of Android, the C library is the BSD-derived Bionic library rather than the GNU C Library used in most other Linux distributions.)

So it's a mixture of "this OS is a replacement for its predecessor", "this OS is a fork of its predecessor", "this OS is the next version of its predecessor, with this version having a name change", and "this OS is technologically descended from its predecessor without being a direct fork or replacement".

Should there be either a note explaining that in general, or an indication, for each OS, what it means for that OS? Guy Harris (talk) 01:48, 23 January 2021 (UTC)

IMHO, the article should be consistent; always show the immediate predecessor/successor, always ultimat, or always the full chain.

FWIW, some genealogies are

• OS
  • OS/360
    • OS/VS1
      • OS/VS1 BPE
    • OS/VS2 R1 (SVS)
    • OS/VS2 R2-R3.8 (MVS)

• • • • • MVS/SE

• • • • MVS/SP V1
      • MVS/SP V2 (MVS/XA)
      • MVS/SP V3 (MVS/ESA)
      • MVS/ESA SP V4
      • MVS/ESA V5
      • OS/390 V1
      • OS/390 V2
      • z/OS V1
      • z/OS V2
• DOS
  • DOS/360
  • DOS/VS
  • DOS/VSE
  • VSE/AF
  • VSE/SP
  • z/VSE
• TSS
  • TSS/360
  • TSS/370 PRPQ

There are also some side chains, e.g., SSX.

FWIW, OS/390 started as a bundle including MVS/SP V5, DFSMS/MVS and dozens of other products, many optional and separately priced.

Should IX/370, AIX/370, AIX/370 V1, AIX/370 V2 and DPPX/370 also be shown? --Shmuel (Seymour J.) Metz Username:Chatul (talk) 04:19, 3 October 2021 (UTC)

References

Missing 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 AIX

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)

Proposed nomenclature section

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)

Issues with MVS

There are several issues with the way data are presented for MVS

• The term MVS applies to everything from OS/VS2 Release 2 through z/OS.
• No version of MVS is bundled with the hardware, although the rates vary depending on what it is licensed to run on.
• The license varies depending on the version.

The following exist:

OS/VS2 R2 through R3.8

Source code freely available

Service provided as object code and listings on microfiche

MVS/SE

Add on to OS/VS2 R3.7 (Release 1) and R3.8 (Release 2)

Licensed

Source code and microfiche restricted to licensees

MVS/SP Version 1

Add on to OS/VS2 R3.8

Licensed

Source code and microfiche restricted to licensees

MVS/XA

Add on to OS/VS2 R3.8

Licensed

Source code and microfiche restricted to licensees

MVS/ESA

Licensed

Source code and microfiche restricted to licensees

OS/390

Licensed

Source code and microfiche not available

z/OS

Licensed

Source code and microfiche not available

The above somewhat oversimplifies, as the transition to object code only (OCO) was more gradual.

Currently there are table entries for MVS, OS/390 and z/OS. I'm not sure whether to use separate table entries for the four flavors prior to OS/390 or to group them in some way. Thoughts? -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:09, 3 May 2023 (UTC)

OS/390 seems to indicate that it was mainly a change to the way some (optional(?) components were packaged, combined with some marketing people deciding to change the name. The latter doesn't render it a Shiny New Operating System separate from MVS; do the other changes do so, or should there be "MVS, OS/390" entries covering both?

Does z/OS include changes other than "we now support 64-bit hardware and applications"? Many other OSes have addes support for 64-bit hardware and applications without being labeled Shiny New OSes, just "version N+1, now with 64-bit support". If not, I'd be inclined to lump it together with MVS and OS/390 - and, for the other variants, do the same as well, unless they have changes that render them Shiny New Operating Systems rather than "

Every change in product name, release and version has new code and new feature, with a huge amount being carried forward. The selection of what is bundled, what is optional and how the code is packaged has changed multiple times. The z/OS V2 documentation still uses the term for some of the manuals. In particular, z/OS V1R1 is not just OS/390 V2R10 with 64-bit addresses. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 01:15, 4 May 2023 (UTC)

Every change in product name, release and version has new code and new feature, with a huge amount being carried forward. That's true of most OSes, but most changes aren't considered to result in a new OS, just a new version; which changes, if any, would make the OS with those changes a Shiny New OS? Guy Harris (talk) 01:48, 4 May 2023 (UTC)

The question isn't whether each is a Shiny New OS, but rather how to present the cost and license in the table. They both change as you got from version to version, so if you consider them to all be the same OS then you need some way to split and label the relevant table cells; I don't believe that {{free}} and {{nonfree}} can coexist within the same cell. Secondary issues are why whatever justifies separate entries for OS/390 and z/OS does not apply to MVS/370, MVS/XA and MVS/ESA and what to do about products that are available both for a monthly fee and for a one time charge. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 10:57, 4 May 2023 (UTC)

I don't believe that {{free}} and {{nonfree}} can coexist within the same cell. They can't, but you can play tricks with rowspan to have separate rows for some columns.

whatever justifies separate entries for OS/390 and z/OS The "whatever" is probably to be "they don't have the string "MVS" in their names", which also answers "why ... does not apply to {list of OSes whose names being with "MVS"}". :-) (I.e., it's the magic of marketing names; there are probaby people there who think that "Mac OS X" and "macOS" are different OSes (I'm not sure what they think about "OS X"), or that somehow Apple deciding to switch from a numbering scheme intended to make people think "Mac OS X" continues after "Mac OS 9" to a numbering schme intended to make people think that "macOS" is in the same extended family as "iOS" and "iPadOS" and.... (Sun changing the numbering schme for Solaris, because they realized that the object-oriented microkernel buzzword buzzword buzzword buzzword buzzword Solaris 3 would probably never happen, didn't seem to provoke that sort of response.))

what to do about products that are available both for a monthly fee and for a one time charge Use {{nonfree|Monthly license US$5,000, one-time charge US$5,000,000}} or whatever. Guy Harris (talk) 11:51, 4 May 2023 (UTC)

So are you recommending splitting columns Cost, availability, Preferred license and Target system type into separate rows for free, chargeable MVS/370, XA and ESA? -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:42, 4 May 2023 (UTC)

If having a single row for all members of what might be considered the MVS family is better than having separate rows for everything in the family, yes, splitting columns could work. (Note that we have a single row for macOS, the two name changes nonwithstanding and a single row for the (desktop) Windows NT family, the variety of names used for desktop NT-based OSes nonwithstanding, so having a single row for the MVS family might make sense.) (And speaking of IBM mainframe OSes, there's a row for "z/VM", which lists "VM" - which has no row - as its predecessor. Would a row for the VM family make sense?) Guy Harris (talk) 19:31, 4 May 2023 (UTC)

I wound up splitting it into free and licensed. @Guy Harris: I believe that the best thing to do with VM would be to have an entry for each of

• CP-67
• Virtual Machine Facility/370 (VM/370)
• Licensed VM prior to z/VM
• z/VM

leaving out CP-40 and lumping all of VM/BSE, VM/SE, VM/SP, VM/SP HPO, VM/XA MF, VM/XA SF, VM/XA SP and VM/ESA together. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 02:36, 14 May 2023 (UTC) -- Revised 16:32, 14 May 2023 (UTC)

That seems similar in structure to the way OS/360 and successors are presented, so that'd work. (But were early version of z/OS also supported on S/390?) Guy Harris (talk) 11:54, 15 May 2023 (UTC)

The z/OS announcement lists supported S/390 processors:

z/OS Version 1 Release 1 runs only on servers that implement certain architectural enhancements. The following IBM servers have these enhancements:

• z900 or comparable server
• S/390 Parallel Enterprise Servers — Generation 5 and Generation 6 models or comparable server
• All models of the Multiprise 3000 Enterprise Server or comparable server

You could run z/OS through Version 1 Release 5 on ESA/390 hardware, with only 24 and 31-bit virtual addresses; everything after that requires z/Architecture. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 09:02, 16 May 2023 (UTC)

References