This article is written in
American English, which has its own spelling conventions (color, defense, traveled) and some terms that are used in it may be different or absent from other
varieties of English. According to the
relevant style guide, this should not be changed without
broad consensus.
This is the
talk page for discussing improvements to the
Unix article. This is
not a forum for general discussion of the article's subject.
This article is within the scope of WikiProject Computer science, a collaborative effort to improve the coverage of
Computer science related articles on Wikipedia. If you would like to participate, please visit the project page, where you can join
the discussion and see a list of open tasks.Computer scienceWikipedia:WikiProject Computer scienceTemplate:WikiProject Computer scienceComputer science articles
This article is within the scope of WikiProject Technology, a collaborative effort to improve the coverage of
technology on Wikipedia. If you would like to participate, please visit the project page, where you can join
the discussion and see a list of open tasks.TechnologyWikipedia:WikiProject TechnologyTemplate:WikiProject TechnologyTechnology articles
This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of
computers,
computing, and
information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join
the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
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)reply
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)reply
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)reply
"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)reply
oh, ok, if that's the case, then I made a mistake. --
seth (
talk) 19:36, 10 May 2021 (UTC)reply
As far as I know Android is not a UNIX and its interface doesn't run on anything bother 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)reply
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)reply