Template talk:Unix/Archive 1

Archive 1

Grouping is a Bad Idea.

When you start lumping the BSDs together, the next logical thing is to start lumping the SysV types together, the minixlike ones (linux, minix) together... and then you run into Mac OS X - which has the dual heritage of both Mach and the BSDs. It's far better just to have a list of OSes than to try and group them at all. — Preceding unsigned comment added by Dogcow (talk • contribs) 22:13, 23 November 2005‎ (UTC)

I couldn't have said it better myself. Plus I think the extra punctuation clutters up the thing. NicM 22:48, 23 November 2005 (UTC).

Old, often dead Unixes?

What about Dynix, Unixware, System V, Venix, A/UX, etc? Include or ignore? NicM 08:43, 15 November 2005 (UTC).

IMO ignore unless they have big historical significance like Xenix. The template must be a small and usable nav utility, not an extensive list; otherwise it will eventually turn into a Szablon:Systemy GUI-style moster. --tyomitch 09:39, 15 November 2005 (UTC)

Okay, I think this is wise. Leave 'em out unless they are vaguely recent or important. NicM 09:54, 15 November 2005 (UTC).

NEXTSTEP was removed because it's "not a current system." IMHO, it's at least as important historically as Xenix, because of its leading up to OS X. I'd like to put it back in. Qwertyus 16:30, 30 November 2005 (UTC)

Large Cluster of Garbage

Can we avoid making this template into one? I've seen some of the disgustingly large lists of operating systems on other wikipedia sites - avoiding it would be nice. There is no need for something so oudated and irrelevant as NextStep to be on this list, Mac OS X is already there and it is a direct descendant of the codebase - the only descendant of the codebase. There is also no need for BSD to be listed when it's so long deserted - we've listed the surviving children. 69.199.202.17 14:59, 4 December 2005 (UTC)

BSD has a great historical importance in the development of Unix, just like System V. IMO, we should remove OpenServer again, as it's quite a minor OS in terms of user base and it'll probably die out in time, leaving no significant stamp on the history of computing.

I think we need to decide on what we want to list: current Unices or important Unices. I opt for the latter, as this is an encyclopedia, not a software catalog. Qwertyus 22:23, 4 December 2005 (UTC)

I would vote to include most current or recently dead (within 10 years or so?), plus a selection of important historical Unix-likes, ie, pretty much what we have: BSD, System V, NEXTSTEP, Xenix.

If necessary, I'd agree to let all of DragonFly, LynxOS, and SCO go, all are fairly low userbase and not really significant at this time - although I think it's already hard enough to agree what "important" means with the historical ones, it's going to be even harder if we take out well-known Unix-likes that are still alive.

I don't really think the current number of entries is excessive and there aren't that many more that anyone could persuasively argue to include. It certainly doesn't seem to be getting out of hand so it probably isn't necessary to decide at this moment. NicM 23:10, 4 December 2005 (UTC).

Despite my general loathing associated with SCO (I had to admin a few systems for a while), and there isn't anything interesting about the OS, per se - it was a pretty braindead, minimal flavor of Unix - it was the largest installed base of Unix OSes at one point. (I think that perhaps Xenix and SCO should be merged, but that's grist for another discussion.) --moof 05:45, 5 December 2005 (UTC)

SCO is either Xenix or System V, so, in a way, we've listed it implicitly :)

Shouldn't we list Unix, btw? Qwertyus 13:10, 5 December 2005 (UTC)

Unix-like links to Unix in the first sentence, so I don't think it's necessary. NicM 13:18, 5 December 2005 (UTC).

Possible additions

Contrary to NicM's belief, I note that neither A/UX, RISC iX or any of their close relatives have been discussed here.

A/UX was Apple's original attempt to marry UNIX and the Mac OS, which unfortunately didn't survive into the PowerPC era. Some of its features, although not strongly emphasised in the current A/UX article, remain unique. In particular commando - better explained in the real article than I could manage here - is something unique for the user experience. Unlike the current OS X which can run an X server on top of its custom GUI, it runs the Mac Finder and apps on top of X, and can even be run with no trace of the Mac toolkit or application support whatsoever.

It is therefore notable for including the only implementation of X that can natively run Classic OS applications and the first platform that allowed the Mac toolkit to be used with a preemptive multitasking POSIX base.

RISC iX was Acorn's only UNIX and besides anything else possibly the only commercial UNIX developed in the United Kingdom (even if only as a branch from its BSD 4.3 base) and definitely the first UNIX for the ARM processor. It also has a few unique user interface features, but nothing major - just things like the retention of the two cursor terminal mode of Acorn's own earlier machines and the Amstrad CPC. It was bundled with machines for a while, so was definitely in practical use even if not widespread.

Even if RISC iX is a bit tenuous, I definitely think A/UX is worthy of a place on the template.

ThomasHarte 23:53, 8 January 2006 (UTC)

I didn't say I believed they specifically had been discussed. In any case, I think RISC iX was definitely not notable enough to be worth including. I'm neutral on A/UX, as far as I am concerned it can go in if nobody else objects. NicM 00:15, 9 January 2006 (UTC).

Re: "I didn't say I believed they specifically had been discussed" - I was far too combative in my use of language and I apologise. With the "or any of their close relatives" clause I was attempting to apply what I distilled as the test implied by the discussions here rather than looking for a specific discussion, but I did go somewhat too much on the attack. Apologies.

Any idea what a good grace period for objections would be? I guess a week since that tallies with several of the formal wikipedia processes for things like article deletion. So that would mean inducting A/UX no earlier than the 15th, subject to objections. Is that reasonable? ThomasHarte 02:14, 10 January 2006 (UTC)

No problem. For time periods, I don't know if there are any official rules (AFDs and FACs are 5 days), I tend to just leave it until I get bored waiting: usually a few days unless a discussion starts up, or longer if there are a lot of people likely to take issue with it. Personally, since there hasn't exactly been a deluge of comments, I'd add it now and if anyone has any reasons to remove it again, they can bring it up here. I just think additions should be discussed to avoid too many steps on the road to cluster-of-garbagehood. NicM 18:18, 10 January 2006 (UTC).

A/UX should be added I think since it was quite notable but, while Risc iX is interesting, the current article is sorely lacking content which makes it hard to determine if it's notable enough to be on the list. - Dnewhall

Name change?

Given the general consensus illustrated here, wouldn't it be better if this template was headed somethig like "Notable Unix-like operating systems" or perhaps "Significant Unix-like operating systems" (although I prefer the former)? A Category can be created for bread & butter "Unix-like operating systems" so that the obscure and run of the mill are still flagged up as UNIX-like. ThomasHarte 21:46, 15 January 2006 (UTC)

The current title does not imply it is exhaustive: they are still Unix-like operating systems, even if they happen to also be notable or significant. I think it is fine as it is, any inappropriate additions can be dealt with easily enough or discussed here. A category to incldue everything is a good idea though, then link the template to it per Template:Linux-distro NicM 22:53, 15 January 2006 (UTC).

GNU OS

GNU is a Unix-like operating system. Hurd is it's kernel, but because unix-like operating systems are component-based, other kernels built for Unix-like operating systems can be used with GNU. Some people use a variant of GNU which uses Linux as it's kernel, but that's not what GNU is, that's something else. GNU is the GNU operating system. Sorry for the verbosity, maybe this is redundant but someone has remove GNU from the list of Unix-like operating systems, so I thought I should note here before re-adding it. Gronky 20:20, 31 January 2006 (UTC)

Most Unix-likes aren't really that component based. Linux is, but the bulk of most Unix-likes are developed as a unit—the BSDs, Solaris, and to my knowledge most of the other commercial ones. In any case, I thought they were calling their OS GNU/Hurd but I see that they're just calling GNU+Hurd plain old GNU, so I guess I don't really object to it staying—I reckon it's well known enough, if only for the 20-odd-year unfinished kernel saga. NicM 21:19, 31 January 2006 (UTC).

hide?

Is there really a reason to make a template that sits at the bottom of the article hidable? It's like three lines tall, hardly a big thing to scroll past. 65.95.124.5 02:11, 4 April 2006 (UTC)

Category:Unix

Currently, this template causes pages that include it to fall into Category:Unix. However, some pages are already in subcats of Unix, such as BSD. IMHO, this causes clutter in cat:Unix. Qwertyus 18:45, 13 April 2006 (UTC)

Plan 9 from Bell Labs and Inferno

Both are considered by Ken Thompson and Dennis Ritchie to be offical successors to UNIX. Where should they mentioned? eeemess 14:19, 27 April 2006 (UTC)

But are they Unix? I don't know where the line is drawn, is it only things which partially comply with POSIX? At that point we'll end up with Windows listed. Janizary 21:17, 28 April 2006 (UTC)

According to Ken Thompson etc. its Unix for a different type of computing or done over again for more modern computing. In terms of trademarks it isn't Unix - its consider to be its successors. I suggest you read [1]. eeemess 13:13, 29 April 2006 (UTC)

That's bullshit, plain and simple. It's either Unix or it's not, and if it's not it doesn't belong here. I could call Windows XP the successor to Unix and I'd at least be right, it is the thing that has succeeded Unix as the dominant operating system. Someone's opinion on if it is the successor or not is irrelevant, has Plan 9 succeeded anything anywhere outside of Bell Labs? Is anything about Plan 9 important to the evolution of Unix? Marketspeak does not a successor make. Janizary 22:38, 30 April 2006 (UTC)

What market speak? The co-inventers of UNIX call Plan 9 the Unix for distributed computing. Much of Plan 9 has impacted current Unixes. Much of the evolution of UNIX is thanks to Plan 9. I think you should do some research and get a clue before calling bullshit. ems (not to be confused with the nonexistant pre-dating account by the same name) 14:28, 1 May 2006 (UTC)

Blindly calling Plan 9 Unix's successor is bullshit, and it's marketing speak. There is nothing quantitative about successor, was it simply the successor within Bell Lab's research division? Well, that hardly makes it noteworthy. Was it the successor to SysV as the basis for all Unixen? No? Well, that would have made it the successor. UTF-8 came from Plan 9, that's really about all that has propagated to any other operating systems, much less Unixen. I don't see where anything else has been integrated into Unix. Even the compiler, which is noted to be very good, isn't being used in other systems. Where's the impact? What has it done? Janizary 17:15, 1 May 2006 (UTC)

Stop trying to twist what I said. I said according to Ken and Dennis. Please drop the zealosness. ems (not to be confused with the nonexistant pre-dating account by the same name) 05:40, 3 May 2006 (UTC)

I am not trying to twist the words, you're just using weak ones. What a man says does not become fact just because the man is influential - results; tangible, visible, calculable, verifiable results are what matter, that is how something is counted as being valid. Successor doesn't happen just because the guys who made it and what it is supposedly succeeding said so, it happens after it replaces what it is supposed to succeed. The Atari Jaguar was definately not the successor to the Atari 7800, the Nintendo Entertainment System was, it took the market, it replaced, and thus succeeded, the Atari system. So if anything, Microsoft's Windows NT series is Unix's successor. Is the Enterprise Audit Shell the successor to sudosh? Infact, there was a discussion about this when the man who made eash made an article about it, the result? Not until it succeeds it. Janizary 15:33, 4 May 2006 (UTC)

That is why I very simplely used one line and said according to who. Now do you want to answer the question? Where should they be mentioned? ems (not to be confused with the nonexistant pre-dating account by the same name) 15:43, 4 May 2006 (UTC)

btw, I answered your question "are they unix." ems (not to be confused with the nonexistant pre-dating account by the same name) 15:45, 4 May 2006 (UTC)

No, you said the men who made Unix called Plan 9 the replacement to Unix, that is different from being Unix. If you can get some sort of a consensus you could list whichever or both as mob rule dictates. Probably only Plan 9, if that, will get any support. Janizary 14:35, 13 May 2006 (UTC)

Removal of "historic unices and unices with a userbase in the hundreds"

I'm not sure if it is correct to say that "historic unices and unices with a userbase in the hundreds don't belong here" (see edit history). I don't see why only Unix-like operating systems that currently are very popular should be listed in this navigational template. Unix/Unix-like OS have a long history and I think that historic and influencial ones are just as important as current ones. An OS does not need to have a very huge user base to be influencial and historically important. We should not hide all the old/minor ones behind the 'more' link. Instead, we need to find some better criteria for which OS to add and which to remove. Any suggestions? Ghettoblaster (talk) 16:02, 14 July 2008 (UTC)

This is designed as a quick navigational tool, not as a family tree or an article in itself. Links which people probably won't be needing to access don't belong here. Chris Cunningham (not at work) - talk 13:13, 15 July 2008 (UTC)

Then tell me one thing. Why do you think anyone would only like to navigate to current Unix-like operating systems? I'm not saying we should extend this navbox into a family tree or an article. I seriously doubt that "people probably won't be needing to access" links to historically important Unix-like operating systems. Ghettoblaster (talk) 15:38, 15 July 2008 (UTC)

I too, think that the original list was way too messy. Moving all the old unix versions to the "more" article is the right thing to do. Raysonho (talk) 15:52, 15 July 2008 (UTC)

Even if it was messy, I don't think messy warrants removing all but the most recent ones. There are for instance navbox groups which are designed just for this purpose (which btw. are extensively used in other navigation templates). So why not include some of the more important historic unices into a 'defunct' or 'historic' group (or sth. like that) and the important newer ones into a 'current' group? We should not drop the historically important ones from this navbox because you can't expect the reader to only navigate between current unices. Ghettoblaster (talk) 17:45, 15 July 2008 (UTC)

I agree there should be some historical aspect to this navbox, unless it's subject is explicitly "Current Unix-like OSs". Surely OSs such as Coherent (an early PC Unix), NeXTSTEP (notable in several ways), Ultrix (ran on three different DEC architectures), UNICOS (first supercomputer Unix?) and Xenix (Microsoft connection) are historically significant enough to be listed? Also, I'm a bit dubious about including POSIX-compliant RTOSs like LynxOS and VxWorks - would they be better categorized as RTOSs? Letdorf (talk) 12:12, 4 December 2008 (UTC).

If an OS is both, a notable RTOS and a notable Unix-like OS, it should probably be in both navboxes. Ghettoblaster (talk) 15:53, 4 December 2008 (UTC)

That's a good argument for {{historical Unices}} or the like. Chris Cunningham (not at work) - talk 12:46, 4 December 2008 (UTC)

I still agree that we should split the content into two groups or navboxes to avoid "messiness" while showing a broad selection at the same time. However, I think it is also important that the template names make it very clear what should be included and what not. If we create a navbox containing only notable "Historical Unices" then we need to rename this template "Current Unices" or the like to void that an OS gets included in both navboxes. But when I think about it, most of the time we would probably end up including both templates anyway, so we could also just split them into two groups within one template. Ghettoblaster (talk) 15:53, 4 December 2008 (UTC)

I don't think we would use both that often - even right now, I don't think the overlap between users wanting to check out articles on Mac OS X / DragonflyBSD / Linux and Plan 9 is that great. And yes, a split would require a renaming to "Modern Unix-like systems" or the like. Chris Cunningham (not at work) - talk 10:31, 5 December 2008 (UTC)

3RR for DragonFly

OK, I've seen DragonFly BSD added and removed more than three times now. Can we please discuss and try to get some consensus as to whether it should be there or not? If we were actually voting, I'd say it'd be a very weak delete - it simply hasn't been around long enough, nor with enough of a userbase, to be notable. (Its users certainly seem to be gung-ho about it, however.) --moof 06:57, 11 March 2006 (UTC)

Well, DragonFly exists, which is more than can be said for GNU. 65.95.241.86 23:53, 18 March 2006 (UTC)

A/UX, BSD, NEXTSTEP and Xenix don't exist (anymore) either, but they are historically significant. DragonFly still has to prove itself. Qwertyus 01:25, 19 March 2006 (UTC)

Despite Gronky's opinion, GNU has never existed, at least Xenix really did get used once. NextStep had an actual userbase, which makes it significantly more important historically than GNU. As far as I'm concerned GNU shouldn't be listed and neither should Linux, neither are Unix-like operating systems, GNU/Linux can and should be listed. DragonFlyBSD actually exists, it's really there, it even has people running it, that makes it more proven than GNU at the very least. 65.95.241.86 17:39, 19 March 2006 (UTC)

GNU is historically very important in the development of Linux (which you call GNU/Linux), even though largely vaporware. Many other systems have a small userbase, like DFBSD; that alone is not enough to put them here. Qwertyus 18:55, 19 March 2006 (UTC)

But GNU is not an operating system, it's never made a functional system, it's a userland. Linux isn't an operating system, there isn't enough of it to make one, it's a kernel. The two as one make an operating system and therefore make sense to list, but neither on their own work. Historically neither work on their own, together they've played an important roll in Unix-like operating systems, but neither are one. 65.95.241.86 20:36, 19 March 2006 (UTC)

Linux is the name used for the entire OS on Wikipedia (as it is in the real world). I'm not going to have this discussion again. Qwertyus 00:06, 20 March 2006 (UTC)

But isn't this supposed to be an Encyclopedia, aren't they supposed to do things right around here, not how they're popular elsewhere? 65.95.241.86 00:53, 20 March 2006 (UTC)

Indeed, GNU is not an operating system. Linux by itself is not. However, Linux combined with GNU is not an operating system either, as the actual academic definition of an operating system is software that controls and manages processes, resources, and hardware. Nothing in GNU for Linux does any of those things. The Linux kernel does, but it's only part of it. Anything that runs in kernel space that manages processes, resources, and hardware is actually part of the operating system. That means the kernel, drivers, and kernel modules. Nothing else. GNU makes a small, yet an arguably important, part of an operating environment (GNU is far from actually comprising the majority of an operating environment as it includes all libraries, daemons, and software NOT normally invoked by the user. GNU is far from even a large percentage of this, in fact.) GNU does have some bits in the shell layer and above, but it's all dependent almost entirely on non-GNU stuff in your typical linux installation: GNOME runs on X, and last I checked, there has yet to be an actual GNU implementation of X. I like to divide a computer system into 8 layers: Hardware, Operating System, Operating Environment, Shell, Application, Interface, Peripheral, User. Most of what GNU is lies in the Operating Environment. I divide those 8 layers into two systems, the Control System (Operating Environment and below.) and the User System (Shell and above, and entirely optional to the succeful operation of a computer system.). The Control System would result in a combination of Linux Operating System components and GNU Operating Environment components. But to get a full distribution (Both Control and User systems present and used.) it takes a lot more. This is part of the reason I believe RMS is misguided in thinking people should call Linux GNU/Linux, as GNU is neither critical nor needed for a Linux-based control system (One can indeed replace every last bit of the GNU toolchain with non-GNU tools.) or distribution (Very little in Shell and up is actually GNU! BASH and GNOME is pretty much the only thing GNU has in the User System. And those are readily replaced by things such as KDE, ZSH, XFCE, or CSH, for example. Linux does not actually need GNU. Torvalds used GNU purely out of convenience, not out of politics, despite Stallman's attempts at revisionism.). —Preceding unsigned comment added by 69.92.97.210 (talk) 18:03, 11 March 2009 (UTC)

I agree, lose DFLY for now. NicM 19:57, 19 March 2006 (UTC).

AmigaOS ?

Why is AmigaOS included in this? I'm not intimately familliar with it but I never heard it's a UNIX system and the AmigaOS wikipedia page doesn't mention anything like that either. Jtsiomb (talk) 03:39, 2 December 2011 (UTC)

Ditto. I removed it. If User:Michaelm wants to put it back, he should provide some justification for doing so here. Guy Harris (talk) 18:20, 27 May 2012 (UTC)

What system are "like Unix" (or not)?

Uniwersalista: "Yes, these systems are Unix-like, because they are like UNIX, have similar system utilities and so on. And iOS is Unix-like, because is based on OS X, which is UNIX". While I believe all of theis to be wrong, I will not revert this until fixed in target pages. See their talk pages and Talk:Unix-like#What constitutes Unix-like?. Please discuss general issue there and specific on the others. Not familiar with Blackberry, just assume same applies there. What "system utilities" are similar? I would say they would have to be the "same" that is be Unix programs, same source code. And in general it would not matter because Unix is not defined by running a few programs already installed but by running programs together including other Unix programs. Based on (some of) OS X, yes which is UNIX, but if you take enough out it not UNIX anymore. You can't even add those things back (without jailbreaking) and nobody has done that to my knowledge. comp.arch (talk) 12:58, 31 March 2014 (UTC)

Unix-like is a very vague concept that means different things in different contexts. It's meant to be broader than the Unix branding by The Open Group, so Linux is included too. This template has always been a battleground for this reason. QVVERTYVS (hm?) 14:33, 31 March 2014 (UTC)

I understand. Agree it's more than certified UNIX and includes Linux as in Linux distribution (most of the time). However doesn't include everything with Linux kernel (or XNU). Kernels only don't not make Operating systems. Can't boot into one and do anything with the Linux kernel only. If something that is added to a Linux kernel to make it a whole Unix-like OS, is then taken away it could, not be Unix-like anymore. Android might be an example, Firefox OS must be. comp.arch (talk) 15:05, 31 March 2014 (UTC)

I think the intention is indeed to include full operating systems only. Compiling a list of Unix-like kernels is even harder (are Mach kernels included? what if they're used to emulate Unix kernels, like in Digital UNIX or OS X?). QVVERTYVS (hm?) 15:37, 31 March 2014 (UTC)

"Unix-like kernels" are very different inside, so the internal structure of the kernel doesn't govern whether it's Unix-like. Perhaps the system calls the kernel offers might indicate whether it's Unix-like, but I could see an OS where the only "core OS" API offered to developers is a Unix API but that's all implemented as routines atop a different system call API (Windows NT's system call API is the Native API; Microsoft didn't describe it at all until recently, and it's subject to incompatible changes from version to version. The Win32 API is implemented atop it, with some Win32 calls being thin wrappers and others being more complicated, perhaps using multiple system calls and perhaps sending messages to other processes that actually do most of the work.) Guy Harris (talk) 19:06, 31 March 2014 (UTC)

As for "And in general it would not matter because Unix is not defined by running a few programs already installed but by running programs together including other Unix programs.", I consider, for example, the NT-based flavors of Windows Embedded to be Windows NT, even if, for example, the company buying Windows-based cash registers or ATMs only get to customize bits of the UI by asking the vendor to use different logos/colors/fonts/etc. Guy Harris (talk) 19:06, 31 March 2014 (UTC)

Yes, but then Windows and Unix are quite different systems in terms of their history. Windows is defined by being Microsoft's proprietary product + the Win32 API; perhaps ReactOS would be Windows-like, but OS/2 would not. By contrast, the distinguishing feature of Unix is its philosophy of "tools and glue" more than the system call interface. In this sense, Plan 9 is a Unix-like, it has a Unix-style shell, most of the commands, pipes, resources-as-files, etc., even though it is not even (in its native mode) remotely compatible with POSIX APIs. QVVERTYVS (hm?) 19:23, 31 March 2014 (UTC)

Distinguishing to whom? Users, script developers, or application/library developers? From my standpoint as a Wireshark developer, the APIs are at least as relevant than the command-line philosophy.

The underlying problem here is that Unix-like, in its first two paragraphs:

A Unix-like (sometimes referred to as UN*X or *nix) operating system is one that behaves in a manner similar to a Unix system, while not necessarily conforming to or being certified to any version of the Single UNIX Specification.

There is no standard for defining the term, and some difference of opinion is possible as to the degree to which a given operating system is "Unix-like".

opens itself to original research - absent a predominance of reliable sources all using the term in the same way, the best you can do is support all the senses in which a significant number of reliable sources use it. Guy Harris (talk) 20:08, 31 March 2014 (UTC)

You're right. Maybe we should restructure the template as follows:

• one list of "genetic" Unices, i.e. operating systems by AT&T source code licensees
• one list of trademark Unices, so SFU and IBM's offering
• a "see also" listing Coherent, Linux, Minix, Plan 9, QNX.

We'll probably end up discussing where *BSD fit in, but at least we're no longer explicitly claiming something is Unix-like. QVVERTYVS (hm?) 21:56, 31 March 2014 (UTC)

See, Wikipedia_talk:Articles_for_creation/Template:Unix_internals. Could be used in iOS, Android, Blackberry (and Firefox OS?), after approval. I've created articles (and redirects) before but not templates. Seems not to be different really, just that there is an approval process now. Could be used as is after that as is, but even better would be to refactor out Template:Unix and reference that. Trying to figure out how. comp.arch (talk) 09:19, 3 April 2014 (UTC)

I think "Unix-like internals" suffers from the same problem. What are Unix-like internals? What is a Unix-like process model? Why is Plan 9 listed, when it changes just about every bit of Unix, except for the basic command line? QVVERTYVS (hm?) 09:22, 3 April 2014 (UTC)

Note changes to that template to eg. "Unix APIs". I mean for it to include all what some people consider "Unix-like". Plan 9 is already in the other template. At least it has a shell so I do not object. Do not know enough about it, maybe it should be skipped from at least the "Unix-like" template. It has POSIX subsystem, but not by default? What OSes can we reasonably exclude from "Unix-like", to be put into another section or template? comp.arch (talk) 12:06, 4 April 2014 (UTC)

Edit war about Unix-like

Ok, Oknazevad: regarding this revert I object to. It seems I'm going to fast. I thought the discussion was over. See section above. It's clear as day to me that all these "mobile OSes" are similar and not very "Unix-like". They all had "Unix-like" in Infobox only, unsourced. But none have it anymore as I removed that as is ok, since it was unsourced (and untrue). The template should follow what the articles say. Please disagree there if need be. Android seems less clear-cut than iOS to me, but I'm just assuming BlackBerry doesn't have a shell and thus is not "Unix-like". Any best place to discuss this? The general issue if there is one? All these OSes are dissimilar (eg. the kernel), but seem similar in being "non-Unix-like", no shell (nor X Windows). Please revert when convinced. comp.arch (talk) 14:36, 4 April 2014 (UTC)

(Note: having the X Window System is not necessary to be Unix-like or even trademarked Unix, and OpenVMS used X as its window system as well.) Guy Harris (talk) 18:23, 4 April 2014 (UTC)

(edit conflict):Well, when you make the change less than 24 hours after the previous reverted just made a comment on the talk page , but before that person has responded to your reversion, it's too fast. No harm in waiting a few days. Requested moves and deletion discussions last a week. Don't need to wait that long, necessarily, but when there's multiple people having reverted you, there's need for more discussion to arrive at consensus. + −

As for the actual edit, again, you seem focused on user interface or POSIX compliance, mentioning shells and X Windows. And again, there's multiple editors who think that's too one dimensional. As Guy noted, X Windows is not a requirement by any means; OS X does not use X by default, and yet it is UNIX certified out if the box. iOS still uses the entirety of Darwin, which is universally called Unix-like, so I cannot agree with removing it. oknazevad (talk) 18:42, 4 April 2014 (UTC)

I shouldn't have mentioned X Windows, it's not a requirement, unlike the shell/command line processing, just one of the thing many would also associat with Unix bu now.. Sorry for confusing the issue. The point of operating systems is to run programs, so what type of compatible programs and how (the UI) is the key issue. iOS and Android are at least now os families. Either or both might be also Unix in a very restricted sense, restricted enough to be less than half-truth IMHO. comp.arch (talk) 19:07, 4 April 2014 (UTC)

[Repeating myself from other talkpages.] Regarding: "iOS still uses the entirety of Darwin, which is universally called Unix-like", Darwin seems to be crippled: "if your script takes 20 seconds to run, that's too long, and iOS will kill the app." [2]. iOS may include all of Darwins binaries, but if crippled in this way no longer follows POSIX.2. If locked down is ok and judging by what's inside ("internal structures"), I can add Tivo to Unix-like? If functioning shell (and/or compatibility in general) is not clear dividing line for inclusion, what is? Some fuzzy line at least would be helpful. If throwing iOS out is WP:NPOV, then so is including. More so I would say. comp.arch (talk) 19:34, 4 April 2014 (UTC)

Note my latest edit to the template. I didn't remove anything. Possibly should have used: "With Command-line interface" or "With Command-line interface"? Rename template? To Unix-something? Unix-like should redirect to it, but not be used on iOS and Android. comp.arch (talk) 20:49, 4 April 2014 (UTC)

Instead of running around in circles, may I suggest that we take to heart the usual Wikipedia rule of WP:42 for this template?

Articles generally require significant coverage

in reliable sources

that are independent of the subject.

s/Articles/Templates/g. Liberally interpreting this rule, I'd say that whenever a source can be found that credibly asserts Unix functionality and/or Unix heritage for an operating system or OS component, it may be listed, modulo notability and space considerations. Following WP:INHERIT's rule for notability, I suggest that sharing code with a Unix system does not itself imply Unix-likeness. QVVERTYVS (hm?) 21:07, 4 April 2014 (UTC)

Is this an argument against (or for) including eg. Android? I've already included lots of sources establising Android as it's own "OS family" in that page (Infobox and text). [See also recent edits for iOS.] Lots of sources say Android is not "Linux". Looking for sources that say Android is Unix, can't find any credible and none saying that ever in Android's page. Unsourced material (that is "Unix-like") can be removed (not that it can't be both (a hybrid, sources indicate at least it's more "Android" than "Unix" and now a family with "clones"). Please provide any source in these article saying they are Unix (not true) or "Unix-like". Looking forward to it. Until then I would really want them deleted but trying to come up with a comprimize that was [[3] reverted]. comp.arch (talk) 21:58, 4 April 2014 (UTC)

I'm not speaking pro or against any particular OS for inclusion, but we should set up a separate reference list for this template. I'm not sure how to do that though, maybe a subpage Template:Unix/References? Or can we make references hidden?QVVERTYVS (hm?) 11:20, 5 April 2014 (UTC)

Proposal: Change title to reflect inclusion of iOS and Android? (But not Tivo)

Unix-like now says:

Functional UNIX

Broadly, any Unix-like system that behaves in a manner roughly consistent with the UNIX specification, including having a "program which manages your login and command line sessions" (unlike e.g. iOS)

Unix has from its start included a command line interpreter (CLI) for "command line sessions" (can it even be added to iOS"?). Reflecting my sourced CLI addition above and that the CLI is gone from iOS (and Android), the title would rightly say "Unix, Unix-like and Unix-unlike operating systems", making it completely meaningless (then should include eg. Windows). Is there a better alternative?

Unix, Unix-like and Unix-based operating systems (no good, Unix-like-based not either)

Unix, Unix-like and POSIX-based operating systems (POSIX.2 is in POSIX, making this not ideal)

Unix, Unix-like and Unix API-based operating systems

Any other good alternative?

And possibly, use my latest reverted change to template with "Without CLI"? comp.arch (talk) 14:31, 5 April 2014 (UTC)

User interfaces

Another round of artificial distinction. Nearly all modern Unix-like systems offer touch user interfaces, which may or may not be primary UI. Fedora by default boots into touch UI – GNOME. There are so many ways to classify Unix-like systems, that using any of them will constitute landing unduewight on one aspect. In the end, this template is not about breaking systems in particular groups.

And again, Android offers command line interface in the very same manner any other Linux-based system does. Every Android system is equiped with mksh. The fact that no terminal emulator is installed by default means nothing, as the same effect may be achieved with any other system based on Linux kernel. — Dmitrij D. Czarkoff (talk•track) 20:17, 20 July 2014 (UTC)

I believe this revert is wrong as clearly all operating systems in group2 - the Mobile OS "Unix" variants are all incompatible with each other in practice and mostly incompatible in practice with the other traditional group 1 (that are mostly (source) code compatible within). While I know traditional Unix can be run on a laptop and is in that sense "mobile", the Mobile OS category doesn't cover that and they are clearly distinct in many ways from traditional Unix. One of them is that they do not have a command line user interface (primarily or as standard; nor do they have remote login/multi-user). comp.arch (talk) 20:29, 20 July 2014 (UTC)

Reiterating won't make this statement true. Fedora with custom kernel (CONFIG_VT=NO) and no gnome-terminal installed remains the same OS while qualifying for your definition of mobile OS, so you should better revise your criteria. And again, this template is not here to classify Unix-like systems, but to navigate between them. Division by "certified" criterion would be much more appropriate if any division would be need; albeit it is not the case. — Dmitrij D. Czarkoff (talk•track) 21:46, 20 July 2014 (UTC)

Between this version and this one, Czarkoff's version is probably better with a good explanation to the contrary. Just last night I was installing Arch Linux on a laptop and installed the gnome-shell package and configured it to load on startup, but forgot to install any sory of terminal emulator. (Impressively) my touchscreen was already perfectly configured just by installing and loading xorg, so it didn't have a command line user interface and had a touchscreen UI; was this a mobile device? In contrast, there are Android laptops that are not mobile devices. I know that Android is typically referred to as a mobile device, but the point is that it's not always true so why should the template make that distinction? I don't see it helping nagivation and the explanations on the left of the template needesly complicate and distract from the actual purpose of the template. I'm not saying it's a situation where I could say "this version is clearly right and this other one is clearly wrong" or anything, but between the two the clean and simple version does seem better in my opinion. - Aoidh (talk) 22:55, 20 July 2014 (UTC)

Arch Linux is not in the template so no immediate problem. Some Unixes can be configured into the "mobile" category, or vice versa, Android be "promoted" to a "desktop" version or hybrid (by forking/hacking). The interesting case is Firefox OS (and webOS?), I assume it has a shell behind the scenes (has init; see: Talk:Firefox OS). I'm very much against calling it Unix-like (completely incompatible at practical Unix-API level by design and traditional Unix philosophy/POSIX.2). At a minimum it would have to be qualified in the template if included and it seems to have all of the qualities that Android have for "Unix-like".. I would want to leave the mobile OSes out, qualified (in some way) is the only acceptable alternative. How do you like the revised version? comp.arch (talk)

@Comp.arch: To me every non-flat revision is equally bad for the same two reasons:

1. No separation is needed for this template. It is not about classification of Unix-like systems, – it is there to enumerate them, and flat list does this job best.
2. There are many ways to divide Unix-like systems, and every single one would land undue weight on one of aspects.

I would also remind you, that we are at "discuss" stage of WP:BRD, so, please, self-revert. It is you who introduce the change, and it was already challenged, so, please, make sure to establish consensus before next attempt at grouping. — Dmitrij D. Czarkoff (talk•track) 11:57, 21 July 2014 (UTC)

"It is not about classification of Unix-like systems". I'll look into the rules about that. If you have any pointers let me know (I reverted for now) (do you also have a problem with other classifications Template:Mobile operating systems? That is at least a precedent). The problem is Unix has a long history, had about 6 syscalls to begin with (and a shell). A lot has been added (and sometimes removed). Broadly, history is CLI/remote-login/multi-user based only, migrated into "workstation" territory with desktop environments (DE) still CLI compatible, DEs became primary user-interfaces (still with CLI) with X Windows becoming the standard (NEWS and Display PostScript (NeXTSTEP) died); X Windows (compatible) with CLI the current traditional "desktop Unix". Mobile OSes are the next evolution, but really a revolution as they broke compatibility in a practical way - now pretty unrecognizable as "Unix". Branded or not branded Unix is no longer any issue to anyone (and broadly compatible anyway and reflected in title of template). If practical application and user interface compatibility is not an issue and worthy of clarification in the template I propose migrating Windows OS(es), VAX, Multics into it.. comp.arch (talk) 12:26, 21 July 2014 (UTC)

(do you also have a problem with other classifications Template:Mobile operating systems? That is at least a precedent).

Frankly, that template is a mess; I have enough problems with it to keep myself out of its talk page. Anyway, there is natural division of mobile operating systems by parent OS (nearly all mobile OSes are derived from general-purpose or embedded OSes these days).

Broadly, history is CLI/remote-login/multi-user based only

Also true for OS/2, NT and many historical systems.

DEs became primary user-interfaces (still with CLI) with X Windows becoming the standard (NEWS and Display PostScript (NeXTSTEP) died); X Windows (compatible) with CLI the current traditional "desktop Unix".

Display PostScript morphed into Display PDF and still lives. X11 is on its way out, giving road to Wayland.

If practical application and user interface compatibility is not an issue and worthy of clarification in the template I propose migrating Windows OS(es), VAX, Multics into it..

In practical application and user interface Android is barely distinguishable from Desktop Linux on modern hardware. You don't argue that Windows Phone does not belong to the same family as Windows proper because it does not include long-standing Windows utilities, do you? Again, from practical standpoint, Android is no more different from GNU/Linux then Solaris, let aside the stupid decision to ship no terminal emulator by default. — Dmitrij D. Czarkoff (talk•track) 14:35, 21 July 2014 (UTC)

"Also true for OS/2, NT and many historical systems." Yes, and they haven't dropped CLI compatibility (nor have they standards demanding it), but my point was that in Unix, the CLI was the only user interface to begin with and one of the core parts. While X Windows applications are the norm now in "desktop Unix" it wouldn't be Unix without the CLI also. Let's say we could agree to that Unix has evolved into a GUI only standard (or in addition) then that one would be X Windows application compatibility standard and without it you would end up with NO application compatibility. What point is there then group the new OS (mobile OSes) with the incompatible forerunners? That is the reason mobile OSes in general and Android need to be qualified/explained. From the horses mouth(s) (first reference in Unix):

Ritchie, D.M.; Thompson, K. (July 1978). "The UNIX Time-Sharing System" first page:

(iv) System command language selectable on a per-user basis

(vi) High degree of portability

then "For most users, communication with the system is carried on with the aid of a program called the shell. The shell is a command-line interpreter: it read lines typed by the user and interprets them as a request to execute other programs." If you want to claim an operating system is like Unix - contradicting Ritchie and Thompson (my bolded parts) you have to give very good reliable sources saying the mobiles OSes are (a natural evolution of) Unix. Or qualify. The Unix-like doesn't and Functional UNIX part subsection contradicts Android. The Trademark or branded UNIX section applies to Mac OS X - NOT iOS - for a reason? comp.arch (talk)

Android is fully compliant with this definition – operating system allows that. The lack of pre-installed terminal emulator in reference implementation does not change the nature of OS. iOS is not compliant by default, although Jailbreaking makes it compliant as well; before you state that jailbroken iOS is not iOS any more, let me remind that most server Linux installations limit end-users in even more severe ways, which does not stop server Linux installations being Unix-like. — Dmitrij D. Czarkoff (talk•track) 21:14, 21 July 2014 (UTC)

Note, the proposal for split template/qualifications (open to suggestions of revised text) is consistent with your view and mine on this (for the Android, iOS and BlackBerry). The "mobile OS" category (lots of sources call them that, you and I both disagree on "mobile"/"desktop" OS designation as a perfect term for an OS..). I would like your view on adding "web OSes" (Chrome, webOS, Firefox OS?) and maybe smartTV/watch/"embedded" (Android Wear) to the second category and generalizing it:

Other/Mobile operating systems/

command-line user interface not included/promoted

Do you justify leaving them out of the template and not iOS/Android? "let aside the stupid decision to ship no terminal emulator by default" - that is a very understandable design decision for the form factor of the primary market of all the mobile OSes - but let's not argue to much about until we have mobile/web/speech/car/TV-based one promoting a CLI. Like it or not the screen sizes are getting smaller and continue to be keyboard-less (Android Wear/Auto). And people (most of them) absolutely do not want remote login/time sharing any more for security reasons in personal devices/cars. Time-sharing/CLI has been dying for a long time, since the workstation/PC era started. I use the CLI every day and it's not like I'm pro/against on this, it's just a fact that the market for "Unix" has evolved. "does not change the nature of OS" - why are these new OSes then all incompatible (and mutually so - I know about BlackBerry though "merging" with Android/Dalvik)? I know "(vi) High degree of portability" probably means of the OS, that includes the userland, but maybe also the applications? comp.arch (talk) 09:15, 22 July 2014 (UTC)

You exagorate their mutual incompatibility. The underlying Unix of Android, BlackBerry and iOS provides everything for running classic Unix utilities (which are actually included with each of these systems). Multiple Unix software (eg. vi) builds and runs there. Their degree of portability is comparable to every other Unix.

Compare that to Linux and OS X: nearly full compatibility for CLI software with nearly complete incompatibility for graphical software, which is dealt with by installing X11 on OSX, specific portability addressing code in Qt, GNUstep on Linux, etc. Actually, the whole Unix scene right now is indistinguishably similar to that of the days when X11 was not most prominent Unix UI yet. — Dmitrij D. Czarkoff (talk•track) 09:30, 22 July 2014 (UTC)

Yes and no. There is one problem with that view. As I explained above there are three broadly (overlapping) phases in the evolution of Unix. When X11/GUI (and alternatives that "died") era stared appearing in Unix, CLI was preserved. Yes, GUIs were incompatible, but the OSes were not incompatible for old applications (CLI). X11 in now part of traditional, and I was careful in my group one to not stress X11 too, saying GUI (linked X11..) much because of the past and future (Wayland, that seems to be not problem or it would fall under WP:CRYSTAL?)

What I have a problem with is when the CLI started "disappearing", technical users or programmers will know all this anyway, that you can add it, but for the was majority of users of the new OSes, they will look and feel different and be programmed for differently, Android apps, iOS apps (in the past BlackBerry apps), and hardly any (new) CLI programs will be added or used by ordinary users - the readers of Wikipedia. For the technical people like you and me, the grouping will also be useful or at least not wrong in any major way. comp.arch (talk) 09:53, 22 July 2014 (UTC)

"iOS provides everything for running classic Unix utilities (which are actually included with each of these systems)" - I think that is a distorted or wrong view, and will get more wrong over time. Maybe technically right (after adding terminal that most will not do) for Android, just barely. Firefox OS be design - also actively wants to prevent not just running the classic CLI utilities but also GUI apps unless through incompatible (with previous Unix GUI standards) web APIs. I would like your view on that/Unix-like? (in the template?) and then as we are both repeating ourselves, take a break and see if others have a view on this discussion? comp.arch (talk) 10:04, 22 July 2014 (UTC)

"The lack of pre-installed terminal emulator in reference implementation does not change the nature of OS" - disregarding user interfaces as a core components of operating systems lead to a bizzare conclusion. Your argument (defining something by what can be added not by what is there) essentially is, DOS is Windows as if you only add Windows 3.11 to DOS then you have Windows, ergo DOS is Windows. Now a few generation later DOS was dropped as a base (or turned around, in a VM) and you could still run DOS apps in Windows. Now they do not run DOS apps anymore(?) - the transition is complete, the same is happening in Unix. At some point Unix is no longer Unix or we have to put a dividing line and qualify. Another argument is Windows is Unix as coLinux can be added and then you run both concurrently (not ordinary host and VM or dual boot) as one (hybrid) OS. Then Windows is Unix as it can be added (or vice versa). Merge Windows and Unix-like templates? :) comp.arch (talk) 10:56, 22 July 2014 (UTC)

You either don't see or ignore my point: yes, UIs of Android, BB10 and iOS are strongest defining points of these operating systems. Saying that any of them is just another Unix (or Unix in disguise) is plain wrong. Still, these UIs, frameworks and VMs sit on top of classic Unix. This element is not of very much practical importance for most end users (thus no shell access by default), but it allows to unambiguously charecterize these systems as Unix-like.

This is the same story as with MacOS and OS X. The defining factor of Apple's computers always was their environment. When OS X was released, many (most?) users did not even notice that their new Macs were actually running proper Unix – all they cared about is another step in improvement of environment their Macs offered.

I would argue that NEXTSTEP was first to make CLI interface of Unix optional. That OS, although it was BSD flavor, included environment that did not rely on shell for users' workflow. It was even marketed as more GUI-driven then MacOS. Although it included terminal emulator and had no explicit policy against its usage, the whole user environment was based on the idea that users will work in a different way. In other words, NEXTSTEP was just as "ununixy" as Android or BB10. (Admittedly not as much as default iOS.)

This is your line. It does not separate true Unixes from new generation of OSes. It separates Unix internals of operating system from higher level of its userland.

P.S.: I am an ordinary user of ordinary Android phone. I use shell on my phone. Not as much as I use it on my PC, but still I use it.

— Dmitrij D. Czarkoff (talk•track) 22:07, 22 July 2014 (UTC) (updated 22:25, 22 July 2014 (UTC))

(Presumably you meant "NEXTSTEP was first to make CLI interface of Unix not compulsory" - other UN*Xes required some use of the CLI.) Guy Harris (talk) 22:11, 22 July 2014 (UTC)

Yes. Thank you. — Dmitrij D. Czarkoff (talk•track) 22:22, 22 July 2014 (UTC)

"NEXTSTEP was first to make CLI interface of Unix optional", not "true" - Terminal (OS X): "Terminal originated in NeXTSTEP and OPENSTEP, the predecessor operating systems of OS X. As a terminal emulator, the application provides text-based access to the operating system". Assuming this is true. I tried googling "terminal in NEXTSTEP" - not fun. I suppose it got installed by default (OS was pre-installed right?). Of course it's optional to use it, but having it makes the OS Unix not "ununixy". Android doesn't and even fewer (I guess) use a terminal there (relativity, Android is more popular by a large margin :) as it is not there - and not required therefore for anything (might be in NEXTSTEP). Not sure if NEXTSTEP was branded Unix, or at least promoted POSIX compliant. I think not only having a GUI was some selling point. comp.arch (talk) 15:01, 23 July 2014 (UTC)

I was offered a job at an NEXTSTEP startup app company but declined so my recollection is only for what I read at the time, never having used one. If it was actually absolutely not compulsory, was it in to maintain full Unix compatibility of CLI applications (to use GCC that was included. vi? emacs? included? none of these in Android). Or just for "fun"? To connect to other machines? I just wander why have it then? It's obvious to me why it's "missing" in the newer generation. comp.arch (talk) 15:09, 23 July 2014 (UTC)

Dmitrij didn't say "NEXTSTEP didn't provide a CLI", he said "NEXTSTEP didn't require the CLI", and the latter claim isn't disproven by the existence of Terminal.

I don't know why they provided it, but it was presumably there for the benefit of people who had UN*X CLI applications to run or who wanted to work at the command line.

I don't think NEXTSTEP was fully POSIX-compliant by default, as per, for example, the existence of a libposix library, with which programs weren't linked by default; I don't know what the differences between the UN*X API they offered by default (if Cocoa is a descendant of the NEXTSTEP code, the file I/O, at least, is ultimately done atop the UN*X file I/O calls, so they're there by default) and POSIX were. Guy Harris (talk) 17:25, 23 July 2014 (UTC)

The difference between NEXTSTEP and Android, regarding CLI, is that, NEXTSTEP clearly emphazised the GUI (incompatible one with others, ok), but it's claim to Unix compatibility is it still had the CLI as standard. Of course users might not have used it often (maybe programs did - GUI built on separate shell process process - the Unix way (applied to the GUI world), if you will, of one programs working together and being "minimal"). Android went the extra step of completely get rid of the shell - as a user interface. In the "mobile OSes" it actually doesn't make much sense and it seems it will not be getting back in this new world. I think that all of the mobile OSes not having a CLI is a notable pattern and only a tiny minority will add one. Until we have a real problem/confusing to readers with the template it should divide the two categories. If we have a problem in which group to put an OS we cross that bridge when we get there. NEXTSTEP (and Mac OS X, but not iOS or older Mac OS) fits the description for traditional "User interfaces: command-line and usually a desktop environment" comp.arch (talk) 13:57, 23 July 2014 (UTC)

Why is Mac OS X and not (older) Mac OS Unix? As you point out the GUI part is not the reason (they are incompatible, but mostly the same). The reason is the CLI and "Unix" in general. Grouping Mac OS X and older Mac OS, would make sense in a product template for Apple, but not in a template on Unix, iOS is the equivalent of older Mac OS in that sense, there the focus is the core original parts of Unix that are common - the CLI. comp.arch (talk) 14:02, 23 July 2014 (UTC)

"Saying that any of them is just another Unix (or Unix in disguise) is plain wrong." - you seem to be agreeing with my point. I see your points and I think you do mine. I think we've reach a common understanding (that is, you educating me on some points in the past..). "these UIs, frameworks and VMs sit on top of classic Unix" - take Android and iOS (no VM, not familiar enough with Blackberry but seems to apply there also, and for Chrome OS and certainly Firefox OS). For this to be true what you mean is "classic Unix"=Linux kernel (for Android, equiv. kernel for iOS, QNX for Blackberry), and its interfaces. But the kernels are not operating systems (and Unix was an OS not just a kernel, right?), they are part of one. A large part of what sits on top is also the OS. comp.arch (talk) 14:24, 23 July 2014 (UTC)

I think we're getting away from the main issue here, and also dangerously close to WP:OR. It's not about what I, or anyone else, think qualifies as a Unix variant or Unix-like. It's about what reliable sources say. Android (operating system) appears to cite proponents of both viewpoints. iOS only makes an unreferenced assertion in the lede. Is it possible to find reliable sources for either side of this disagreement? hbent (talk) 14:16, 23 July 2014 (UTC)

You seem to think that I'm pushing Android and similar out of the template, they are still in under the heading "Unix and Unix-like". Try however to find any sources for "Unix-like" (and Android, I've tried..). Maybe I have to educate myself on the rules on templates, but have not seen anything about forbidding splitting (or allowing/requiring and how) templates. I just know the split is based in verifiable facts, not OR. comp.arch (talk) 14:30, 23 July 2014 (UTC)

This template should reflect how the articles describe themselves, not the other way around. Right now both Android and iOS describe themselves as Unix-like in their respective infoboxes. It seems that if there are issues with those classifications, they should be addressed at the talk pages for the operating systems, not here. hbent (talk) 14:34, 23 July 2014 (UTC)

Like I said, the current proposal for this template doesn't dispute that. Those pages also say "mobile OS", not sure what you mean by - "iOS only makes an unreferenced assertion in the lede", if you mean right at the beginning that it is a "mobile OS", then I googled that and found this[4], and at least all the top results are consistent with that view. However this came up third[5] and I thought "Mac OS X" - strange, but "The new look of OS X with Yosemite borrows a bit from iOS 7′s flat, bold look, but it doesn’t break with tradition quite so dramatically. It does, however, borrow the penchant for transparency and translucency that Apple introduced to its mobile OS", meaning OS X is not a mobile OS, and iOS is. It is (un?)common knowledge that the mobile OS have not CLI (and the shell very hidden). Want sources for non-existing things, the lack of CLI (not meaning the actual shell executable - note "(iv) System command language selectable on a per-user basis" except maybe by rooting?) in them? comp.arch (talk) 14:44, 23 July 2014 (UTC)

Again, Android, BB10 and rooted iOS allow selecting shell on per-user basis. There is even a bundle of zsh and some useful utils on Android Market. — Dmitrij D. Czarkoff (talk•track) 16:35, 23 July 2014 (UTC)

Please see last paragraph of Android (operating system)#Linux kernel. Sources stating that Android is Linux distribution imply that it is Unix-like. See WP:FRINGE for the reason why no sources directly stating that Android is Unix-like are needed. — Dmitrij D. Czarkoff (talk•track) 16:22, 23 July 2014 (UTC)

Do you Guy Harris (and Hbent) agree with the refined change and know if the OSes in group1 in the template fit the description in the small font? (And group2). Hbent, wanted sources, do the above do? Relevant pages might have to be updated, but does anyone think this is not a relevant division of the "Unix-market"? I'm not pushing for group2 OSes out of the template. That could maybe be argued if I find the sources instead of merging. A simpler description would be ok with me, with/without CLI as standard, any thought on that? I do not want to push for a vote. Thought discussion had gone for long enough and BRD was respected but got reverted maybe because of the misunderstanding just added above by said reverter. comp.arch (talk) 16:27, 23 July 2014 (UTC)

"Sources stating that Android is Linux distribution imply that it is Unix-like", I'm not sure if this is the reason for the revert or answering because neither makes sense. I fully agree that Android is a Linux distribution as it has a Linux kernel and all other required things to make an OS as that is what it means. Unix is an OS right? And then Unix-like doesn't make much sense unless to describe an OS also, not just the Linux kernel on its own. And the Android addition makes it in many ways very Unix-unlike, because it subtracts essential stuff stuff that would have made the original Unix (and all versions for many years after) a doorstop. That justifies clarification in the template IMHO. Android in unrecognizable to ordinary people as Unix.. comp.arch (talk) 16:47, 23 July 2014 (UTC)

Presumably you're referring to the subset of ordinary people who know what Unix is (other than people who have had their testicles removed). :-) Guy Harris (talk) 17:54, 23 July 2014 (UTC)

"Linux" in "Linux distribution" means Linux, not Linux kernel. It is obvious from sources that they speak of Linux, saying that Android builds upon Unix-like operating system, not only Linux kernel. — Dmitrij D. Czarkoff (talk•track) 18:18, 23 July 2014 (UTC)

Linux kernel plus the Bionic C library, for starters. Guy Harris (talk) 20:33, 23 July 2014 (UTC)

We are in agreement on this then. Parens on my part my have thrown you of (I edited them out). You seemed (to me) be taking the view that the Linux kernel only, as in Android was an enough claim to Unix-like. I think it's fair to include (some) C library in Unix definition (see however for non-C/assembly unreleased? Unix example - the absolute first one on 18-bit PDP-7 and possible incompatibilities). The C library is part of userland, as is the plumbing for user interfaces (at least in part). User interfaces are a core part of OSes. NEXTSTEP being "dead" (but alive in Mac OS X) the first OS where the CLI started "dying" and new info from Harris above leads to a possibly more regular division. I'll implement just in case to get an opinion. Not offended if reverted but consider leaving it for a while at least. comp.arch (talk) 21:40, 23 July 2014 (UTC)

I believe that availability of Unix shell and possibility to use it is also defining factor of Unix. I just hold some more relaxed view on availability – I accept NeXTSTEP's "shell is not necessary" and Android's "shell is hidden by default" as long as shell is native, provides Unix symatics and may be accessed.

P.S.: proper place for drafting templates is their sandbox. This template's sandbox can be found here. — Dmitrij D. Czarkoff (talk•track) 23:54, 23 July 2014 (UTC)

I don't consider the presence of an X11-based GUI relevant to UNIX. There has never been a single standard GUI API for UNIX, and that's still true today. Lumping the "non-X11" OSes together makes no sense; OS X is just as much a "regular UNIX" as is, say, Fedora or Ubuntu, and there may come a point where the low-level window systems for both Fedora and Ubuntu aren't X11. The toolkit is what programmers write to, not the window system, and at least one toolkit, Qt, supports multiple underlying window systems (including the Windows window system), and there's also wxWidgets, which wraps various toolkits, including GTK+, the Windows widget set, and Cocoa. (And if you're going to going talk about non-X11-based GUIs for SunOS, you might as well include SunView. :-)).

And, yes, you should be using a sandbox for the experiments. Guy Harris (talk) 01:06, 24 July 2014 (UTC)

"OS X is just as much a "regular UNIX"", just in the CLI sense. OS X GUI apps, the was majority that Mac users care about are proprietary and non-portable to eg. Fedora. Right? Justifies clarification in a separate group in the new proposal. Looking at Unix from a GUI perspective - the real application portability there is clarified in the new proposal. Just because you can make portable apps even to Windows doesn't justify merging the template with a Windows one (I guess binaries will not be portable - are there fat binaries for both (even possible?)). Merging the groups in my proposal are however optional but not preferred. See Template:Pink Floyd (and discussion there) for example of non-flat template. Grouping singles vs. LP seems not arbitrary, but alphabetical, chronological or other are a possibility. I assume most logical and WP:consensus decides. comp.arch (talk) 11:59, 24 July 2014 (UTC)

Thanks for pointing out the template, see for proposal, with group1 split in two. Group2 clarifies app incompatibility. System V is in both group0 and group1, maybe splitting group1 was not a good idea or I did it wrong. It's a start at least to my ability. The groups are roughly in chronological order, but maybe reverse order - is in order  :) Thanks for the much needed Dilbert humor above.. Does this or similar have a WP:SNOWball in hell of getting accepted? comp.arch (talk) 11:04, 24 July 2014 (UTC)

Ugh. Firstly, way too much unlinked text, which violates the navbox style guidelines. Navboxes are for quick navigation; they should not have excess text or over-complicated structures. They don't do subtle explanation well, because that's what the articles are for. Some broad, logical groupings are useful at times, but if the grouping text takes that much to explain why a link is in a given group, then it's an unneeded, artificial distinction. Which is what is happening here. Trying to force an artificial distinction is resulting in a terrible navbox that goes against the guidelines.

Clearly, the repeated rejections by multiple editors, shows there is no consensus for such a change. And the countervailing evidence presented shows that the distinction being made is factually incorrect, which is why the resultant proposal looks so terrible. The marking if some systems as historical is a good idea, but otherwise it's time to let this drop. oknazevad (talk) 12:14, 24 July 2014 (UTC)

What about now after taking complication into account (was trying to satisfy Harris.. this is a better way)? comp.arch (talk) 12:42, 24 July 2014 (UTC)

Nothing that considers the use of X as the window system a fundamental characteristic will ever satisfy me.

As I've noted, programmers rarely write to the X11 API (both the Xlib API and the XCB API are too low-level), they normally write to an API for a toolkit such as Motif, GTK+, or Qt. The latter two of those toolkits are also in the process of providing support for Wayland as a window system, so that software written for them, and linked with versions of those toolkits with Wayland support will work without X.

Once we start talking about toolkits, however, Qt, at least, also supports Cocoa and the underlying graphics layer as a back end (GTK+ also has some support for it). It may not be a primary API for GUI programming on OS X (there used to be two GUI APIs - Cocoa and Carbon - but Carbon is now deprecated, leaving Cocoa as the primary API), but it's still an API that can be used (and is used by a number of applications, including Google Earth).

If you want to split based on the APIs that ship with the OS and that are supported (to some extent) by the supplier, you might be able to split OS X, NEXTSTEP, and non-X-based SunOS (and possibly other pre-X-based GUIs from other workstation vendors) into a category of its own, but how would you define the APIs not in that category? "Capable of running on top of X11", even if they don't happen to be running on top of X11 in Fedora 21?

Another problem with the template is that it lumps together "regular PC/workstation UN*X not using X11-capable toolkits", "mobile device", and "web-based OS"; the three don't have much in common. OS X, SunOS with NeWS or SunView, and NEXTSTEP are a lot more like, for example, Fedora or Ubuntu or current Solaris than they're like iOS or Chrome OS, and the biggest thing Chrome OS and Android have in common is that they both come from Google. :-)

And what about server and embedded use? (I'm defining "embedded" here as "embedded in a system with no third-party applications, so a smartphone OS isn't an embedded OS; this is more along the lines of a Tivo box or an ATM or a network switch or a Wi-Fi access point or....) I would consider the OS running on an ATM to be a version of OS/2 or Windows NT or Linux or whatever even if the only UI is "deposit, withdrawal, or balance?" and if nobody other than the OS vendor, the ATM vendor, and maybe the bank get to write software for it.

This is perhaps getting sufficiently complicated that just leaving things as they are may be the best strategy. Guy Harris (talk) 21:29, 24 July 2014 (UTC)

I used "desktop environment" (really meaning less known WIMP, note M for mouse and use that now and link to WIMP) then changed to "X Windows compatible usually installed" (but can go either way on terms and most natural split when found) as that is really the current "traditional" (unless you apply the traditional term to Android and iOS, and would you not say they are all mutually incompatible GUIs?).

Are you fundamentally opposed with a/the three/two way split, or can it be clarified with simple wording changes? And possibly moving/copying between categories as I've now done?

"X Windows compatible usually installed" didn't preclude OS X because of "usually". Installing something even more different, even full Android or Dalvik (has anyone? Why doesn't anyone? Ubuntu? Because it would be Android and kill Ubuntu as an ecosystem as happened with OS/2? Ubuntu for Android seems to have been put on hold for Ubuntu Touch).

An OS with only Wayland for native applications - not having X Windows-compatibility - eg. XWayland will be suicide for the forseeable future (or forever?) and will not be done (an OS like that would belong in the third group? that used to, and could, include hybrids, let's not worry to much about the template until that happens) or is planned that I know of by anybody (even Ubuntu plans XMir).

"traditional" was meant to mean has X Windows or other OS that can run X apps or Wayland apps. When you say programmers write to toolkits, that is right, but do they really support native iOS? Didn't know, but still native iOS apps do not migrate out of iOS. Considering native preferred GUI interface seemed reasonable, you can always write portable code.. comp.arch (talk) 23:40, 24 July 2014 (UTC)

I don't see servers as a problem. First category were servers. They also fit in the middle one, and most are there. In mobile OSes you usually do not want them, but peer-to-peer is kind of a server, and servers as such also belong there. Do we have to say the OS is a "server OS"? Similar for embedded, doesn't naturally fit in last category as you (and I define it). No problem that I see. Tivo isn't in the template anyway, but could be added in the middle. Yes, it's stretching it but so is calling Tivo an operating system and we would have put it in the "flat" template anyway. Yes, it has an OS in a restricted sense. I see this as grouping microcontrollers in a CPU template. Technically true. Or calculators in OS templates or (general purpos)e computer. comp.arch (talk) 00:07, 25 July 2014 (UTC)

Is the time-sharing era ok in the template proposal? I'm less familiar with that. The first Unix "Ken's first system" seems to be the only non-time-sharing system and an interesting factoid of non-C based, but I could go with only saying "Historical" if "Time-sharing" trips people up on this technicality. Also note Linux is also in first era. comp.arch (talk) 10:05, 25 July 2014 (UTC)

Heres a simple fact; the sheer amount of debate here just proves that this is an utterly needlessly complicated mess for a navbox. Again, navboxes are just there to provide links between articles. The are not there to make fine distinctions. That the pre C Ancient Unixes didn't support one sharing is the exact sort of detail that belongs in an article, not a navbox! And this debate has gone straight into original research, which doesn't just belong in a navbox, it doesn't belong anywhere in Wikipedia. The proposal is completely wrong. Just drop the stick and stop beating this dead horse, no one is going to accept any version of it, and now your just clogging up the talk page with needless long-winded posts. oknazevad (talk) 12:14, 25 July 2014 (UTC)

"proves" no. "needlessly complicated" not any more - simplified. I just took advantage of the sandbox to experiment and provide justification (small font description could be dropped but take no space). "navboxes are just there to provide links between articles", not true, it seems to my reading of the rules categorization is allowed. And preferred in another (longer.. also "open source") example Template:Human evolution (I guess there have been disagreements on those categories.. outside WP) - a perfectly good non-flat, roughly (overlapping) chronological/by capability eras. "fine distinctions": mobile vs. others distinction is a major one, supported by sources. If you take the GUI out of Android, you do not have Android any more, you have a bootable to non-CLI mess (in standard ASOP or even if you had a terminal add-on), where you can run no programs - calling it an OS anymore is WP:POV.. I admit the first split I know less about, when could you add X Windows or other GUI? Certainly not with an ordinary terminal, but at what version of Unix? I just do not want to be accused of WP:RECENTISM but could go with combining first two groups, but not with the third (see new SHR-section). comp.arch (talk) 18:17, 26 July 2014 (UTC)

SHR

I don't think SHR belongs here – it is a Linux distribution for mobile devices, strict subtopic of GNU/Linux, just as Archlinux, Fedora, Gentoo or Ubuntu. FWIW there is no place for SHR in sandbox, because it provides CLI just as any other Linux distro (both framebuffer console and terminal emulator), but its mouse support is similar to that in Android – available out of the box, but not really supported well in UI. — Dmitrij D. Czarkoff (talk•track) 07:54, 26 July 2014 (UTC)

I agree, it's a Linux distro, it doesn't need to be covered here. That would get out of hand very quickly. That it is intended for mobile devices is irrelevant to that, there are a few other Linux distros for mobile devices, but they are still Linux distros and covered under "Linux". - Aoidh (talk) 08:36, 26 July 2014 (UTC)

Ok, fair enough about SHR not in current template. But your logic for SHR's non-inclusion applies then for Android. You may not realize when I'm helping you. It was you who reverted my change, of OS family to Android on it's page, back to Unix-like. Android is not or could be based on first versions of Unix - could not have run on Unix for about 20 years+. It's based on Linux kernel - is a "Linux distro" if you will. Really Android (the OS family) is Linux kernel-based that is "Unix-like". Unix is 41 years old and mobile OSes are pretty different from first versions (even the shell is incompatible with first it seems). I expect you reconsider the proposed template or drop Android from the current template (note I added "usually" back for the minority SHR OS - descriptions in small font could be dropped and leave everything about CLI or X11 implied). comp.arch (talk) 16:47, 26 July 2014 (UTC)

What is "Android (the OS family)"? Android itself is OS, it just comes in several distributions.

See, SHR is just another Linux distribution to degree that You won't see difference between SHR and Arch with same DE installed from AUR. Android is distinct. Yes, there is an argument whether Android is GNU/Linux or distinct Unix-like system only sharing kernel with GNU/Linux, but at any rate it is distinct enough to be worth inclusion. (Not to mention that it is at very least an order of magnitude more popular then all other systems using Linux kernel altogether.

Regarding sandbox:

1. I still see no necessity in groups.
2. UI is really bad criterion: most systems belong to every of your groups.
3. SunOS is definitely the same OS, be it with NeWS, SunView or X11.
4. SunOS is BSD, Darwin isn't.
5. Xenix run X11 implementation by SCO – Xsight. System V also run X11.
6. System V is in two groups.
7. xv6 is misplaced.
8. SunOS predates most of "Terminal (time sharing)/Command-line user interface only".
9. SHR and "Linux" can't be in different groups: SHR is strict subset of Linux.
10. Nokia X? Really?
11. Plan 9 is definitely misplaced.
12. BB10 is ordinary Unix, it must be in the same group as modern Unixes.
13. BB10 is built on top of QNX just as OSX is built on top of Darwin.

Actually, differences between all of these groups are non-existant. You basically split them by default setup, which does not make sense. Even BSD vs. SysV-like would be more reasonable. But, again, group split is just not needed. — Dmitrij D. Czarkoff (talk•track) 20:59, 26 July 2014 (UTC)

Android mouse support is I believe called "touch emulation". The fat finger problem has implications for touch-based GUIs and app design. WIMP in the older generation is also similar (AFAIK) between X11-based and others and touch usually has "gorilla arm"-problem. In a touch-based/mobile OS, P for pointer is also the exception. M for menus at least a little bit different (always drop-down menus in older era, not new mobile OS era? Are those "touch-based" OS considered WIMP?). But you do not want to consider GUI as part of the OS (what the general ignorant public considers all of the OS..). comp.arch (talk) 16:59, 26 July 2014 (UTC)

Yes, Android and iOS are considered WIMP. Mostly because there is no significant difference between mobile software and desktop software. — Dmitrij D. Czarkoff (talk•track) 20:59, 26 July 2014 (UTC)

There is absolutely no argument about whether Android is GNU/Linux, because Android contains little to no GNU code; it can't be GNU/Linux without GNU. Even GNU is quite clear on this; whether android is Linux is probably what you meant, but it is most certainly not GNU/Linux, and even the group that pushes the term is adamant that Android is not GNU/Linux. - Aoidh (talk) 22:55, 26 July 2014 (UTC)

I use "GNU/Linux" name in this discussion to avoid ambiguity with Linux kernel. I should have probably said just "Linux distribution". — Dmitrij D. Czarkoff (talk•track) 07:29, 27 July 2014 (UTC)

Grouping

I boldly grouped:

• 386BSD, DragonFly BSD, FreeBSD, NetBSD and OpenBSD under BSD (mostly for cosmetic reasons);
• Darwin, iOS and NeXTSTEP under OS X (closely related, standing out from the list);
• illumos, Nexenta, OpenIndiana and SunOS under Solaris (historical and current variants).

This grouping is largerly arbitrary, and I would like to hear from other editors whether you think it is an improvement or damage to this template. — Dmitrij D. Czarkoff (talk•track) 08:07, 29 June 2014 (UTC)

The only things I could see being controversial are the historical groupings. Putting Nextstep under OS X and SunOS under Solaris is kind of iffy but I suppose I have no strong feelings about the matter. Thanks for your cleanup work, I definitely think this version is an improvement. hbent (talk) 17:55, 29 June 2014 (UTC)

I do not have a big problem with the (shallow) tree structure that this really is - just noting that it's not really flat and contradicting "To me every non-flat revision is equally bad" (in another discussion). For Apple, chronological would be Mac OS X, iOS. NeXTSTEP bought? Then in front..? Then there is alphabetical/flat. I'm not arguing against your way (except in the newer talk section about iOS in another group). I'm agreeing that structure/non-flat is good :) comp.arch (talk) 10:30, 22 July 2014 (UTC)

It is really flat in sense that it does not have branches. It merely groups closely related systems. It does not follow chronological order, rather alphabetic with groups attached to common factor. — Dmitrij D. Czarkoff (talk•track) 07:48, 27 July 2014 (UTC)

Is calling z/OS UNIX System Services a "compatibility layer" accurate?

z/OS is a certified UNIX 95. It is the OS as a whole which is certified as UNIX 95, not just a component of it – the UNIX certification program is for whole operating systems not subsystems of them. Given the whole OS is a certified UNIX, shouldn't it belong in the UNIX section not the compatibility layer section? z/OS has two main APIs – the UNIX API, and the legacy MVS API; the UNIX certification program certifies the UNIX API, it does not care about whether or not the OS also exposes a non-UNIX API. (Quite similarly, the certified UNIX macOS exposes various non-UNIX APIs, such as the Mach API and the OpenStep-derived Objective C APIs, and the UNIX certification program doesn't care about the existence of those other non-UNIX APIs either.) And z/OS UNIX is more than just a compatibility layer, an increasing number of z/OS components and applications run on top of z/OS UNIX – among others, anything written in Java. Mr248 (talk) 08:39, 26 December 2020 (UTC)

I wouldn't call the MVS API a "legacy" API.

There's already an OS that runs on IBM Z mainframes that is probably very close to UNIX 03 compatibility (a similar OS is UNIX 03-certified on x86-64), and to which porting applications from other UN*Xes is probably easier, given that, for example, said OS uses ASCII-based character encodings. I suspect most if not all users of z/OS's UNIX components also have applications that run on the MVS API. They may even continue to develop existing applications using that API, and may perhaps develop new applications using it.

macOS isn't an OS with a "native API" that's an alternative to its UNIX API - file system I/O and networking, for example, ultimately turn into UNIX system calls, not into Mach messages, and the OpenStep-derived APIs use UNIX calls for those purposes. It's best thought of as a UNIX that supports Mach messages as an IPC mechanism. Guy Harris (talk) 10:16, 26 December 2020 (UTC)

@Guy Harris: z/OS Unix is not a mere "compatibility layer" because a lot of z/OS functions depend on it. To give some random examples, Zowe and AT-TLS policy agent. Neither of those are things ported from elsewhere, they are both z/OS exclusive features which need z/OS Unix Systems Services (BPX) to run. Even classic stuff like CICS now uses z/OS Unix (because they added to CICS the ability to run Java code, and the IBM J9 JVM runs under z/OS Unix.) Mr248 (talk) 10:58, 29 December 2020 (UTC)

Even if stuff in the "OS/360 with each job step getting its own demand-paged address space" environment uses stuff from the "compatible with older UNIXes as long as you can handle EBCDIC" environment, it's still an OS with two environments, with software being developed for both environments, unlike macOS, which has only one environment, the "OpENStEP-TNG on top of UNIX" environment.

Also, how much of the stuff in the latter environment is built atop stuff in the former environment? Guy Harris (talk) 20:36, 29 December 2020 (UTC)

"it's still an OS with two environments" => I'd argue that's not really true. It's not something like Windows Subsystem for Linux. In WSL1, a process is either an NT process (which can call the NT API) or a WSL1 picoprocess (which can call the Linux syscall API). A single process can't do both. (WSL2 is even more distinct – it isn't just two different types of processes running under the same kernel, it is two different kernels.) By contrast, there is no strict division between "classic" and "Unix" processes on z/OS. Any MVS address space can become a Unix process by making a Unix system call (this process of becoming a Unix process is called "dubbing"), at any point in time. An MVS address space can sit there ignoring the Unix API for weeks on end, and then suddenly out of the blue call a Unix API and at that point it becomes a Unix process. Developers can freely mix classic MVS API calls and Unix API calls in the same process (indeed, a lot of z/OS software is a mixture of both). Or similarly, a Win32 app can't gain direct access to the WSL Linux filesystem; by contrast, any MVS application can access the Unix filesystem – z/OS can present any Unix file as a BSAM,QSAM,BPAM or VSAM ESDS dataset – if the application accesses the file via a JCL DD statement, you just code "DD PATH='/path/to/unix/file'" in JCL and it can access it. (If it allocates datasets dynamically instead of via JCL DD, SVC 99 DALPATH gives access to Unix files via the classic MVS API.) In Windows, cmd.exe can't access WSL files, by contrast TSO/E can access Unix files just as well as it can access classic MVS datasets.

"how much of the stuff in the latter environment is built atop stuff in the former environment" => some bits are shared, some bits are independent. But do these kinds of implementation details matter? Standardised Unix is an interface, if you are certified as implementing the standard interface correctly then you are Unix, why should what you are doing under the hood matter? Mr248 (talk) 21:39, 29 December 2020 (UTC)

From what I've been able to find, MPE/iX allowed mixing of MPE intrinsics and POSIX calls, and it looked as if "POSIX for OpenVMS" was moving in that direction. Both of them appear to put native and POSIX files in the same name space, with some name space tweaks. I don't know what happened for access to native "structured" files from POSIX - did the raw bytes of the file get exposed, so that the POSIX code would have to look at record lengths etc., or did structured text files get translated to line-oriented text files, or could both be done? I also don't know how POSIX files were shown to the native APIs - again, text files could probably be mapped, but some form of structure might have to be imposed on binary files. VMS's RMS, at least, eventually added a byte-stream text file format, in addition to the older formats.

But I would draw a distinction between all three of those "non-UNIX OS that had UNIX added to it" cases and OSes that started out as UNIX from Day One. The latter don't offer an alternative API with its own advantages and disadvantages, and its own base of software, and the former probably all have places where the POSIX abstraction leaks a bit (e.g., EBCDIC in MVS and z/OS, and the top two layers of the directory hierarchy in MPE/iX).

So perhaps "compatibility layer" wouldn't apply to those cases, but I'd still put them in a separate category from the "UNIX from Day One" systems. Guy Harris (talk) 03:11, 30 December 2020 (UTC)

the former probably all have places where the POSIX abstraction leaks a bit (e.g., EBCDIC in MVS and z/OS – POSIX doesn't formally speaking mandate ASCII, so using EBCDIC isn't strictly speaking a case of "the POSIX abstraction leaks". Now, it is true that the vast majority of POSIX implementations do use ASCII, and a non-ASCII POSIX is unusual, but this is a case of people assuming that if >90% of the implementations of a standard do X, then X must be part of the standard, even though that isn't actually true. (Now, you could argue that POSIX should mandate ASCII, or even UTF-8, and maybe someday the Austin Group might even agree to that, but I don't think we are there yet.)

But I would draw a distinction between all three of those "non-UNIX OS that had UNIX added to it" cases and OSes that started out as UNIX from Day One Why does it matter? Why do we need to make that distinction? What exactly is "UNIX"? The official answer per the current owners of the UNIX trademark, is it is a standardised API, and any system which is certified as implementing that API correctly (and which pays the certification fees) is UNIX, and how the API is implemented, or whatever other APIs may be implemented as well, or the history of the implementation, are all irrelevant. By that definition, z/OS is definitely a UNIX, whereas most Linux distributions are not. Now, we could extend the definition to include systems which implement that API sufficiently well but aren't formally certified as doing so; that would bring Linux in general under the definition, although for trademark reasons maybe that is better described as "Unix-like" than "UNIX". A third, historical definition, is a historic code base deriving from Bell Labs, which would exclude systems which don't historically derive from that code base (such as z/OS or Linux). You seem to be proposing a fourth definition, but I'm not sure why we should use that fourth definition instead of one of these three? Mr248 (talk) 22:56, 30 December 2020 (UTC)

"Now, it is true that the vast majority of POSIX implementations do use ASCII" ...where "vast majority" means "everybody but z/OS", at this point, as far as I know. IBM certainly makes note of this issue in the "ASCII-EBCDIC Issues" section of their z/OS UNIX System Services Porting Guide.

"this is a case of people assuming that if >90% of the implementations of a standard do X, then X must be part of the standard, even though that isn't actually true." Or of deciding that it's simply not worth caring about the one and only exception to the standard, either if they don't need to care about running on IBM Z or if they can just run on Linux.

(BTW, 100% of the POSIX implementations conforming to UNIX 03 or later use ASCII. IBM has several of them, including the only two that conform to the version after UNIX 03.)

"The official answer per the current owners of the UNIX trademark" ...is not the only answer of interest.

Are there any cases where somebody who was choosing a UN*X system, and who had no need for any of the capabilities of z/OS or OpenVMS or HP's MPE, and who didn't have an existing IBM Z/VAX/Alpha/Itanium/HP 3000 system on which they wanted to run a UN*X system, chose z/OS or OpenVMS-with-POSIX or MPE/iX rather than Linux/Tru64 UNIX/Solaris/AIX/HP-UX? If not, then there is a useful distinction to draw between "UN*X from Day One" and "Now with added POSIX!" systems. Somebody might well have a use for something that "looks more like UNIX" but doesn't have the trademark, as they don't want to have to deal with the non-UNIXy parts of a system that might have the trademark but has other stuff that pokes through, whether at the programmer's level, the user's level, or the administrator's level. Guy Harris (talk) 23:44, 30 December 2020 (UTC)

"Now, it is true that the vast majority of POSIX implementations do use ASCII" ...where "vast majority" means "everybody but z/OS", at this point, as far as I know Two other IBM mainframe operating systems, z/VM (formerly known as VM/CMS) and z/TPF, are EBCDIC-based systems that support a subset of the POSIX API, although in both cases the support is not as complete as z/OS, and neither is formally certified as UNIX or POSIX. (z/VM's POSIX layer is called OpenExtensions.) Fujitsu (formerly Siemens) BS2000/OSD is a non-IBM mainframe operating system with an EBCDIC POSIX environment. Unisys MCP is another non-IBM mainframe OS with EBCDIC POSIX. So there are at least 5 EBCDIC-based operating systems with some degree of POSIX, although z/OS is the only one formally certified as anything. (IBM i, formerly OS/400, is another EBCDIC-based OS with POSIX support, however although the OS as a whole uses EBCDIC, its POSIX subsystem is ASCII-based)

Or of deciding that it's simply not worth caring about the one and only exception to the standard It isn't the one and only exception, and it isn't strictly speaking an exception, since the formal standard is silent on the topic of character encodings. (It mandates certain characters must exist, but it doens't mandate any particular coding system for representing those characters.)

(BTW, 100% of the POSIX implementations conforming to UNIX 03 or later use ASCII. There is nothing stopping anyone from certifying an EBCDIC-based implementation as UNIX 03 or UNIX V7. It probably isn't going to ever happen, but that's due to reasons of lack of market-demand, not due to what the standards formally require. (If IBM wanted to, they could upgrade z/OS to UNIX 03 or UNIX V7; they probably won't invest in that – indeed, I've heard directly from IBM employees it is unlikely to happen – but the only thing stopping them is their own judgement that it isn't a worthwhile use of their time and money, not anything standards-based or purely technical.)

IBM has several of them, including the only two that conform to the version after UNIX 03. Only two? I thought there was only one UNIX V7 certified system. (There used to be another, Oracle Solaris, but its registration lapsed because Oracle didn't pay the renewal fees.)

"The official answer per the current owners of the UNIX trademark" ...is not the only answer of interest. Sure. But why prioritise some other answer over the official one? Shouldn't Wikipedia put the official answer first?

Are there any cases where somebody who was choosing a UN*X system Does anybody do this anymore? The idea of someone saying "I want a UNIX system but I'm trying to make up my mind of which system to choose". Back in the 1980s or 1990s, yeah people went through that thought process. But nowadays? So your argument that your distinction is useful – maybe it was once useful, it isn't really useful these days, so why should Wikipedia highlight this distinction in the Template, as opposed to highlighting the official distinction (between certified and non-certified systems), or just lumping everything together indiscriminately? Mr248 (talk) 07:42, 31 December 2020 (UTC)

"So there are at least 5 EBCDIC-based operating systems with some degree of POSIX..." So shall we scale the other four down by the percentage of POSIX that they implement? :-) And to what extent are those not-quite-full-POSIX subsystems used?

"It isn't the one and only exception..." But are the other non-ASCII systems going to be of enough interest for software developers to care enough about them to bother making sure their code will work there?

"and it isn't strictly speaking an exception, since the formal standard is silent on the topic of character encodings ..." OK, make that "exception to the default".

"There is nothing stopping anyone from certifying an EBCDIC-based implementation as UNIX 03 or UNIX V7." But it hasn't happened. Is there no market demand because the additional facilities aren't useful enough? (IPv6 is, according to this table of contents for UNIX 03, an optional component; that's probably pretty useful, but it's optional, so they might not have to go through the effort to make sure it conforms.) Is it because there are fewer customers who care about certification? Or is it some other reason?

"I thought there was only one UNIX V7 certified system." According to this register page, there are both "AIX version 7, at either 7.1 TL5 (or later) or 7.2 TL2 (or later) on systems using CHRP system architecture with POWER™ processors" and "AIX version 7, at 7.2 TL5 (or later) on systems using CHRP system architecture with POWER™ processors". So, whether it's 1 or 2 depends on whether it's "AIX version 7" or "the two releases of AIX version 7 we ran through the tests". A narrower count would also convert the 2 Apple entries to 1 and convert the 2 HP entries to 1 (same OS version, different ISA).

"Sure. But why prioritise some other answer over the official one? Shouldn't Wikipedia put the official answer first?" 1) The "official answer" has changed over time; it was originally "UNIX is a trademark of Bell Laboratories" (and, originally, all the UN*Xes were possibly-modified versions of Bell Labs or AT&T UNIX; later, AT&T imposed various restrictions on the trademark, originally requiring, as I remember, that the code be one of AT&T's official System V releases - later, they might have said "if it conforms to the SVID"), and now it's "you get to call it UNIX if it passes the Single UNIX Specification test suite". 2) The Unix article spends a number of paragraphs discussing Unix-like systems in Unix#Free Unix and Unix-like variants; most Linux distributions aren't UNIX(R), but are sufficiently compatible with various UNIX(R) systems to compete with them, so a lot of what people think of as "UNIX" isn't UNIX(R).

"Does anybody do this anymore?" Perhaps. Are you saying that, for example, Solaris sites, or AIX sites, or pick-your-Linux sites, will stick with what they're running as long as the OS is still available, and would never consider switching? Yes, there's a cost to switching (different administrative procedures, different performance monitoring facilities, code running on one might trip over capabilities not present on another, or present but with a different interface on the other), but are there no cases where those costs are outweighed by the benefits (or perceived benefits) of switching, so that Oracle and IBM and {pick your company or team of companies selling enterprise Linux boxes} are rarely if ever competitors any more?

"So your argument that your distinction is useful – maybe it was once useful, it isn't really useful these days," It isn't? Guy Harris (talk) 09:14, 31 December 2020 (UTC)

Are you saying that, for example, Solaris sites, or AIX sites, or pick-your-Linux sites, will stick with what they're running as long as the OS is still available, and would never consider switching? I think many Solaris and AIX sites are contemplating switching to Linux at some point in the future (especially Solaris given Oracle appears to show very little commitment to its future.) Switching between Linux variants happens relatively often; recently at my work we switched a lot of stuff from Ubuntu to Centos (the former didn't comply with some US government security policies required for US government customers, the later did); given Red Hat's decision to kill Centos in favour of Centos Stream, we may well switch again sooner or later. But, what's this got to do with the Wikipedia Template:Unix? These sorts of decisions are not guided by Wikipedia. And your distinction between "systems Unix-like from the beginning" and "systems to which Unix API was later added" isn't important; they may not consider any systems in the later bucket, but there are heaps of systems in the former bucket they won't consider either.

The Template needs to be based on reliable sources not original research. If we are going to split Unix(-like) systems into different subgroups, the subgroups need to be based on reliable sources not just personal opinions of editors. If we split them based on certified-vs-non-certified systems, that would be basing it on a reliable source (the Open Group UNIX Brand Register). If we just lump them all together, we don't have this problem of establishing the reliability of subgroups. The current "Operating Systems" vs "Compatibility Layers" split is not based on a reliable source. Your desire to split them based on "systems that have been Unix-like from the beginning" vs "systems which began as non-Unix-like OSes but later had Unix API support added" – what is the reliable source to justify that distinction? Mr248 (talk) 22:51, 31 December 2020 (UTC)

Any reason for excluding Cygwin in compatibility layers?

-- 73.140.2.82 (talk) 01:15, 11 March 2021 (UTC)

Different types of compatibility layers

Most of the items in the "compatibility layers" section are layers that run on top of non-UN*X systems that provide a UN*X-compatible programming or command layer.

The exceptions are:

• Darling - a layer that runs on top of one UN*X (Linux) that emulates another UN*X (macOS) and the vendor-specific layers atop it.
• UserLAnd - appears to be a layer that runs on top of one UN*X ("Bionic/Linux", a/k/a Android) that emulates another UN*X ("GNU/Linux").

Should they be in a separate section? Guy Harris (talk) 00:26, 3 June 2022 (UTC)

Format of "Operating systems" group

It's currently a bullet-list, with some entries having parenthetical sub-lists, sometimes up to four nested-parens deep. If the goal is to see relationships among the entries, that doesn't help, since it's too hard to figure out what group/subgroup any given entry is a part of. I propose re-formatting it as at least one level of subgroups in the navbox format itself (see Template:Navbox/doc#Subgroups example). Here is a quick attempt: Template talk:Unix/draft.

While looking at all this, I also see that some entries are italicized, with a footnote "Italics indicate discontinued branches." That's a nice feature! But some entries are bold. What does that mean? DMacks (talk) 08:55, 20 November 2022 (UTC)

The boldface is to indicate major codebase trunk. It needs to be indicated in the key. Also, the four deep stuff is nonsense. Whoever did that was trying to indicate that those Apple systems spun out of iOS when Apple decided to treat them separately. It's unneeded and silly. I'm going to fix that now. oknazevad (talk) 12:26, 20 November 2022 (UTC)

Thanks for the cleanups and explanation! Hoisting the (now I understand:) major branches into a second-level grouping would be more accessible than bold and easier to parse (BSD still has two levels of parens). Each major branch could have its own subgroup, and a subgroup of "other": Template talk:Unix/draft. DMacks (talk) 18:43, 20 November 2022 (UTC)

I kinda like it. My concern is that it doesn't make it clear that Linux isn't just the Android and ChromeOS (and in fact is a bunch of systems as Linux distributions vary widely in content and there's some debate regarding what's really needed to be considered "Unix-like"; there are those who would omit Android because although it does use the Linux kernel, it doesn't use much of the other elements of a desktop or server Linux install. Perhaps a link to the Linux distro article is a good addition.

Also I made a couple of other tweaks to the list, noting BlackBerry 10 is discontinued, and adding the historically notable OSF/1 (which wasn't really BSD or System V, intended as an alternate to both during the Unix wars of though the only commercial release of that code base, DEC's Digital Unix, later evolved into Tru64, which became a System V derivative, but that's not really needed here). And I wasn't a fan of the arrow at illumos; this navbox doesn't need to show that detail of derivation. oknazevad (talk) 05:06, 21 November 2022 (UTC)

So I went ahead and copied the draft as the live template. Still think a link to the Linux fosters article is a good idea, since there has never seemed to be an appetite for including a list of distorts in this template (which I can understand; there's far too many of them) oknazevad (talk) 04:53, 27 November 2022 (UTC)

Unix System V

SCO Xenix 2.1.3 to Xenix/386 are all system V. Should it be edited to have SCO Xenix distinct from Xenix, or would it go in both ? Or should I just edit the article on Xenix to reflect what is going on?

158.51.81.86 (talk) 22:55, 5 August 2024 (UTC) https://gunkies.org/wiki/User_talk:ForOldHack

My inclination would be to have Xenix System V as a defunct System V-based UN*X, distinct from Xenix as an "Other' (V7) UN*X. Were there versions of Xenix branded as "SCO Xenix" that weren't SV-based?

If you have improvements that should be made to Xenix, go ahead and make them as well. (It's not immediately obvious from the history section whether Microsoft or SCO or both of them together System V-ified Xenix, for example.) Guy Harris (talk) 02:11, 6 August 2024 (UTC)

There are two problems: Microsoft has the information, and made a lot of mistakes, who gave it all to SCO, who made even more mistakes, and they tried to cover it all up, and it all happened during the Unix wars.

The lead time between, the product announcement, the final build, and the Release to Manufacturing, and shipping, was as long as 4 months, 2 in the case of SCO, 4 in the case of Microsoft, and 6~10 in the case of IBM, and completely unknown in the case of HCR. SCO Xenix was at first System III, Then SCO Xenix was System V, and then it was integrated into the formal ATT Unix tree, and became UNIX. ( and the definitive Unix tree has a bunch of errors ). I have been researching it for 4 years, and just yesterday uncovered more information. 158.51.81.86 (talk) 18:58, 6 August 2024 (UTC)