Template talk:Unix

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)

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[1], and at least all the top results are consistent with that view. However this came up third[2] 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)

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)