Talk:Unix - Wikipedia

Largest implementation[edit]

As of 2014, the Unix version with the largest installed base is Apple's macOS.[citation needed]

macOS might not be a Unix, but if it is shouldn't that now read iOS rather than macOS? S C Cheese (talk) 22:55, 25 January 2020 (UTC)

According to The Open Group, macOS is most definitely a UNIX(R), just as Solaris, AIX, HP-UX, and EulerOS are - they all passed the Single UNIX Specification's validation suite.

iOS, however, isn't - Apple's never certified it. It's a Unix-like system (there are even terminal emulators for jailbroken systems, so you can go construct pipelines to your heart's content), but it's not a UNIX(R). Guy Harris (talk) 00:11, 26 January 2020 (UTC)

And the claim has been removed anyway, given the lack of a reference to support it. (Probably true, given that the only other licensed UNIXes are server UNIXes, but "probably true" doesn't suffice.) Guy Harris (talk) 01:25, 26 January 2020 (UTC)

BSDs (FreeBSD, NetBSD, OpenBSD, etc.), z/OS UNIX, Huawei[edit]

I think the "family tree" diagram is amazing, but I also think it has some issues even as a simplified summary:

1. The contemporary open source members of the BSD family tree (FreeBSD, NetBSD, OpenBSD, etc.) aren't actually Unix. They haven't been submitted to The Open Group for Single UNIX Specification certification, and they don't wear the UNIX registered trademark. Consequently they really ought to be kicked over to the "Unix-like" side of the diagram, which would likely require shifting the macOS branch over to the right. That's certainly not a criticism, but that's just how our strange Unix world works. And I think it's quite important to document that reality, that "Unix" isn't a permanent state of being in an evolutionary path. The definition of "Unix" evolved, and operating systems evolved.

2. There's also a simple, non-AT&T (Bell Labs) code heritage part of the family tree that's missing -- a "virgin birth" UNIX: z/OS. And that family line has two straightforward, sequential box entries: MVS OpenEdition (1993 to 2001) over on the Unix-like side of the diagram, and z/OS UNIX (2001 to the Present) over on the Unix side of the diagram. z/OS achieved UNIX certification in 2001 and maintains it.

3. Huawei EulerOS is also a UNIX operating system and missing from the family tree. I'm not sure what its heritage is. DNCP is another missing UNIX, although I know even less about that one.

Regarding #2 and #3, while it would be difficult or impossible to update the diagram to include all historical UNIX operating systems (Silicon Graphics, DEC, Sequent, Apollo, etc., etc.) it seems quite reasonable and appropriate to make sure that all the contemporary UNIX operating systems are represented. z/OS UNIX, EulerOS, and DNCP seem to be the missing ones. The z/OS "virgin birth" example is quite important at least for that reason (Bell Labs invented Unix, but another company managed to reimplement Unix independently and with Unix certification -- and a "Unix-like" operating system can/has cross(ed) over to "Unix"), and Huawei's entry strikes me as quite significant to document for techno-geopolitical and other reasons. — Preceding unsigned comment added by BBCWatcher (talk • contribs) 06:11, 16 April 2020 (UTC)

I'm all for it; indeed, the tree is inaccurate and needs fixing (macOS is UNIX certified whereas the modern-day BSDs are the antithesis: the certifications became officiated when separating UNIX from the NetBSD/FreeBSD branches!). Altanner1991 (talk) 06:26, 16 April 2020 (UTC)

EulerOS's lineage is "Linux". I don't know what changes they had to make to get it to pass the Single UNIX Specification validation suite; presumably most if not all are in open-source code, most of which is probably GPLed code and thus available to be incorporated into the standard Linux kernel/GNU libc/etc. code base. Guy Harris (talk) 07:01, 16 April 2020 (UTC)

Cemprus is part of Stratus Technologies. The OS is called FTX, not DNCP; FTX stands for "Fault-Tolerant UNIX". According to Mike Turner's Linkedin page, "The Lucent Technologies SINAP group was acquired by DNCP Solutions/Cemprus which was then acquired by Stratus. See above for rolled up experience." Guy Harris (talk) 07:08, 16 April 2020 (UTC)

Considering only a handful systems are UNIX they deserve to be on the list (Linux family or not shouldn't change that). Altanner1991 (talk) 07:33, 16 April 2020 (UTC)

At this point, given the way the UNIX(R) trademark is licensed, the code base is irrelevant, so there's no reason to think that something being Linux should, would, or could change whether something is "UNIX(R)" or not. Guy Harris (talk) 07:42, 16 April 2020 (UTC)

Actually Single UNIX Specification was established in 1994 so no BSD systems nor even the original Unix systems were ever UNIX-certified and regarding EulerOS the chart doesn't aim to show/mix established brands with those "just" currently certified. However FTX and z/OS have been UNIX certified since their releases in 1995 and 2001 respectively. Altanner1991 (talk) 07:10, 18 April 2020 (UTC)

So to summarize my response while FTX is hardly in any article and EulerOS is still relatively new (it was registered to The Open Brand on September 8th, 2016^[1]), z/OS has been UNIX® Certified for enough years that would be worth adding to the chart. Then the open-source operating systems are not certified and yet are not changed in their order, which can make things more messy for the chart and ignore its central purpose of "code heritage". Altanner1991 (talk) 12:58, 23 April 2020 (UTC)

User:Oknazevad at User talk: Oknazevad and User:Eugrus at [[1]] have both voiced their objection on including z/OS with the Unix article picture and template, on the grounds that z/OS is only Unix thanks to its compatibility layer; so without further debate z/OS will not be included.

On my side of the debate, I had claimed that (1) Linux and Minix also share no code with the original Unix from AT&T but they are included anyway, and (2) z/OS is "certified official UNIX" so it should be included with all of the others; finally (3) this talk page had correctly identified any possible missing inclusions and z/OS was indeed the one most due in my opinion. Altanner1991 (talk) 19:25, 23 May 2020 (UTC)

Linux started out pretty early as UNIX-compatible; it's not as if there's a "compatibility layer" offered in addition to a non-UNIX native API. z/OS started out as MVS; I'm not sure how much OS/360-descended code was still in MVS, but its primary API was a descendant of the OS/360 API, which wasn't UNIX-compatible (not least because UNIX didn't exist at the time OS/360 was created...). HP Multi-Programming Executive eventually got a POSIX compatibility layer, and OpenVMS also added a POSIX compatibility layer; the only thing different about z/OS is that IBM got its UNIX environment through the validation suite for UNIX 95, but neither HP nor DEC got their POSIX environments certified. Guy Harris (talk) 21:09, 23 May 2020 (UTC)

Ok so it really is just a "compatibility layer" AND certification doesn't change much. Thank you. Altanner1991 (talk) 01:55, 24 May 2020 (UTC)

From a trademark point of view, "can you compile and run programs written to the UNIX specification" suffices; that's the difference that certification makes. However, an OS that originally had only a non-UNIX API, for which a lot of software was written, and that adds a compatibility environment to allow UNIX programs (or the subset of them that use only APIs from the UNIX specification in ways described by that specification) to be compiled and run, is conceptually different from an OS that only had a UNIX API and for which the software is all written to that API. Linux distributions fall into the latter category, as do the *BSDs, macOS, Solaris, AIX, HP-UX, and so on.

So z/OS is a "UNIX" in the sense that a carefully-written UNIX program (meaning "avoid any assumptions not supported by the UNIX 95 standard" - which includes the assumption that the character set being used is ASCII or a superset thereof!) can be compiled and run in its compatibility environment, but not a "UNIX" in the sense that it has any code or philosophical derivation from AT&T UNIX (Linux distributions have very little code derivation - AT&T did open-source a few programs such as cpio, but even there that might be GNU-derived on Linux distributions - but they have a huge philosophical derivation, as the Linux API is a superset of the UNIX API, just as the APIs of certified UNIXes such as macOS and Solaris are supersets of the UNIX API; z/OS, at the bottom, is still a descendant of MVS, with an MVS-style API as its original, and probably still primary, API). Guy Harris (talk) 02:16, 24 May 2020 (UTC)

The as you termed it "philosophical derivation" is very important, certainly. This is the crux of it which shows that the certification layer is truly a more "minor" portion. You have elaborated the argument most stupendously 👍 :-D Your examples/details are spot-on. Altanner1991 (talk) 03:04, 24 May 2020 (UTC)

z/OS[edit]

I would like to maintain my opinion that z/OS as meeting the Single UNIX Specification is equally worthy as any other UNIX OS.

The competing argument is that the Unix philosophy determines the Unix family tree. — Preceding unsigned comment added by Altanner1991 (talk • contribs) 20:58, 25 June 2020 (UTC)

external links[edit]

hi!
in [2] i removed the dead link to livingcomputers.com and i replaced the unix tree with the unix history repo.
afterwards the unix tree link was recovered by user:Guy Harris.
i still think that the unix tree is less comfortable that the unix history repo, because at the repo there seems to be more information and more possibilities (e.g. comparison, file history)
so what is the benefit of the unix tree website for the reader? -- seth (talk) 07:51, 8 May 2021 (UTC)

If the reader wants to immediately see or fetch the raw files from a given release, rather than see a reconstructed "this is what UNIX commit history would have looked like if it'd been put into Git back in 1969" tree and poke around in the 175(!) branches.

And sometimes I just want to grep through a repository, pull up files in my text editor, etc., which I can do more conveniently if I just clone the repository and work in a local source tree, which is a possibility that is, at best, a pain in a repository Web site.

So what is the disadvantage of providing links to both sites for the reader? Guy Harris (talk) 08:06, 8 May 2021 (UTC)

hi!

you don't need to use the web interface of github, you can clone the whole repo and grep through it offline. (but maybe i misunderstood your middle paragraph.)

however, i guess there's just one general disadvantage: the more links are presented, the more difficult it gets for a reader to find the most relevant stuff. so normally, if there are two different websites and one includes all the information of the other one, i just use the link to the more comprehensive website to improve the readability of the list.

if the github repo is too complicated(?) for many readers in your opinion, then it might be reasonable to mention both links.

still there are more than ten external links now. if really all of them are found useful, then at least a grouping with seperate headings might improve the clarity. -- seth (talk) 08:06, 9 May 2021 (UTC)

"if there are two different websites and one includes all the information of the other one" That's not the case here. The repository doesn't have all the source trees from the Unix Tree page. Guy Harris (talk) 18:12, 9 May 2021 (UTC)

oh, ok, if that's the case, then I made a mistake. -- seth (talk) 19:36, 10 May 2021 (UTC)