Talk:Unix

external links

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

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

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

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

hi!

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

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

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

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

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

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

unix ported to interdata in 77 not 78

https://wiki.riteme.site/wiki/Interdata_7/32_and_8/32 2001:558:6033:16B:59D:F7F5:D1B4:651 (talk) 17:28, 27 June 2023 (UTC)

Fixed in this edit. Guy Harris (talk) 20:00, 27 June 2023 (UTC)

Android interface claimed to be a unix interface

As far as I know Android is not a UNIX and its interface doesn't run on anything other than Android. The idea that any Android specific interface can be a UNIX interface seems not well thought out. 89.239.195.102 (talk) 12:36, 25 August 2023 (UTC)

If you're referring to the "Default user interface" item in the infobox, that item mentions the command-line interface (which doesn't greatly differ between UN*Xes) and the low-level bases of graphical user interfaces (which do differ). It lists both GUI bases ("window systems') that run on several different UN*Xes (X11, Wayland) and those that don't (SurfaceFlinger, Quartz}, indicating which particular platforms use one of those GUI bases. That claim amounts to a claim that SurfaceFlinger, Quartz, and whatever the GUI bases of iOS/iPadOS/etc. is called are (the bases of) the user interfaces for particular UN*Xes; I don't think it's intended to be a claim that those GUI bases can be used on arbitrary UN*Xes.

As for whether Android is a UNIX, I have the impression the low-level core API (Linux system calls plus UN*X routines in Bionic) is close enough that it could be considered a UN*X. Guy Harris (talk) 22:13, 25 August 2023 (UTC)

Well, Android is Linux ... well it uses the Linux kernel ... well its kernel codebase is derived from the Linux kernel codebase both historically and to some extent, maybe, takes contemporary updates from the Linux kernel codebase. ... The Linux kernel is based on Unix, but is very specifically _not_ Unix, at least in a legal/licensing sense ... Does Linux share any codebase with Unix? IDK. If it did historically, they forked long ago. Linux is intended to replace Unix since it provides similar functionality with a similar design. In conclusion, Android is a Unix ... and Android is definitely not a Unix. :) Stevebroshar (talk) 10:04, 30 May 2024 (UTC)

The Linux kernel is based on Unix The Linux kernel implements an API that's based on the parts of the "Unix API" (as common to many Unix systems) that are typically provided by the kernel (as opposed to the APIs, such as getpwnam(), getpwuid(), getaddrinfo() and getnameinfo()>, etc., that are typically provided by user-mode code running atop the kernel). It's not based on any Unix or Unix-like kernel implementations in existence at the time of its creation.

but is very specifically _not_ Unix, at least in a legal/licensing sense Currently, there's the "licensing sense" of licensing the UNIX trademark and the "licensing sense" of licensing the source code that, at various times, was copyright by Bell Labs, AT&T, SCO, Novell, etc..

In the first of those senses, the requirement for licensing the trademark is having a system that passes the Single UNIX Specification (SUS) validation suite; the Linux kernel, as noted, implements too few APIs to pass that suite. However, when combined with libraries such as the GNU C library, the resulting system might be able to pass that suite, and, at various points, both Inspur K-UX and EulerOS, both based on the Linux kernel, GNU C library, and other libraries, did pass that site and were licensed UNIXes.

In the second of those senses, as the Linux kernel, and the libraries and command-line tools typically used with it, are not based on the "AT&T Unix" source, Linux distributions aren't subject to any such source-code licensing restrictions.

Does Linux share any codebase with Unix? The kernel? None that I know of. Userland? Very little. For example, maybe some distributions provide, for example, a Kornshell implementation based on one of the AT&T distributions, but that's about it.

Linux is intended to replace Unix The GNU operating system was, but, when it was originally announced, Linus Torvalds appears not to have had had any such grand ambitions for it ("just a hobby, won't be big and professional like gnu"). It eventually evolved to be the kernel for many Unix-like systems, some of which even passed the SUS validation suite and were UNIX(R) systems.

(That also raises the question of "what is the 'Unix' that it presumably would replace?" "Unix", in that context, appears largely to refer to the traditional commercial Unixes, of which the main remaining ones are Solaris, AIX, and HP-UX, although HP-UX is probably on the way out, as it only runs on Itanium processors, and they're not being made any more and no effort is being made to port it to, for example, x86. The Unix with the greatest "desktop" market share is macOS, and Linux doesn't seem to be gaining much "desktop" market share from macOS.)

In conclusion, Android is a Unix ... and Android is definitely not a Unix. It's not based on AT&T code, but it might look, at the "Bionic/Linux" layer, Unix-like enough that it's not "definitely not a Unix". Guy Harris (talk) 08:05, 1 September 2024 (UTC)

Market share

What is the market share of the various proprietary and open source distributions, for e.g. the server, desktop, and other (high-end computing?) markets? -- Beland (talk) 15:44, 6 March 2009 (UTC)

This info is still missing from the article, other than saying Unixes overall had 90% share for supercomputers. It would also be interesting to know how this changed over time. -- Beland (talk) 01:38, 1 November 2024 (UTC)