Talk:uname

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Windows is not UNIX[edit]

Removed VER command AGAIN. Windows is NT based not UNIX based and thus the version command for Windows does not belong here. —Preceding unsigned comment added by Vchapman (talkcontribs) 19:10, 2 February 2010 (UTC)[reply]

Examples[edit]

Why is there nearly identical examples in the table? This doesn't illustrate anything. --Ysangkok 14:54, 23 February 2007 (UTC)[reply]

These examples show that uname behaves differently on different systems. --Abdull 10:49, 22 April 2007 (UTC)[reply]
I mean, why is Windows and Linux represented so many times. Why not just one for each OS? Example:
Cygwin (Windows XP), Pentium 4
CYGWIN_NT-5.1
Cygwin
i686
unknown
unknown
2006-01-20 13:28
1.5.19(0.150/4/2)

Cygwin (Windows 2000), AMD Athlon
CYGWIN_NT-5.0
Cygwin
i686
unknown
unknown
2006-01-20 13:28
1.5.19(0.150/4/2)
--Ysangkok 17:43, 24 April 2007 (UTC)[reply]

I for one would like to see an agreement on what constitutes a "valid" example for the table, particularly what's useful and what's deemed "useless crud" without any explanation by certain users as to what exactly is "useful" and what's "crud." If we go very strict, then only one example is necessary and the table of examples isn't needed at all.

So what then is useful? Examples of responses from different linux distros? Is it the CPU type that is relevant? If we go the "one for each OS" route, than where do we delineate what makes a different "OS" then? Kernel branch? Unix vs Unix-like? Should OS X/Darwin even be show as an example when BSD is already present? And since when was Cygwin itself an "OS?" -Scaredpoet, 22:35 08 December 2007 UTC

Since uname is useful for build processes to distinguish platform properties, any differences in the values of uname -s and uname -m are very significant, also differences of uname -p or uname -i may be interesting. So I think any examples that differ in any of these values are useful. Towopedia (talk) 14:18, 3 April 2014 (UTC)[reply]

More examples[edit]

This article really needs a better AIX example, possibly something for Tru64, and anything running on IA64 hardware. I don't have access to any of these systems - does anyone else? 208.66.212.43 (talk) 04:25, 26 November 2007 (UTC)[reply]

I updated the AIX example. --Unixguy (talk) 16:11, 27 November 2007 (UTC)[reply]
Added Tru64 and a number of others, checked on the polarhome server farm. Towopedia (talk) 14:18, 3 April 2014 (UTC)[reply]

Trimmed the list again[edit]

Per the discussion above, there's no need to make the example list comprehensive. most examples impart little information to the reader, and I'd argue that we really only need one or two, but we're not having eleven at any rate. Chris Cunningham (talk) 12:11, 10 January 2008 (UTC)[reply]

You had removed two interesting entries which I'm re-inserting (see my comment about interesting differences above); Cray (which is quite unique) and Red Hat (with unique uname -p). Towopedia (talk) 15:52, 3 April 2014 (UTC)[reply]

uname gives KERNEL info, not OS info[edit]

Please differentiate between kernel and Operating System in this article and explain that the uname command gives only kernel-level information. While it is supposed to be able to also give OS info, almost every system fails in this regard (including Linux, Mac, Cygwin, and Solaris). I was hoping to find a link to such a resource on this page ... it's very frustrating to have to tell my UNIX developers over and over that our Mac server isn't running the "darwin" operating system and that it is really a genuine Macintosh (its single-line default /etc/motd stating "Welcome to Darwin!" doesn't help). The correct command on Linux for OS info is lsb_release -a although this command isn't implemented by all systems (I find grep . /etc/*-release /etc/*version is more reliable). The correct command for Mac OS X is sw_vers, for AIX is oslevel, and for Windows (unless you call the OS itself "Cygwin") is ver. --Adam KatzΔtalk 19:01, 28 May 2008 (UTC)[reply]

Actually you are wrong. The uname gives the OS name as standard says. But most of users mistakes the operating system from software system. The Mac OS X is ran by Darwin operating system (actually a XNU). The Darwin is the operating system and top of that is build all other Mac OS X parts. And the LSB-release is just version info of that standard what the system is implented to follow. LSB-standard itself is designed for one Linux (kernel) operating system so when you are building a software system what you want to be used easily by closed source developers, you need to follow LSB-standard what says what you need to include to Linux OS (kernel and what version/release it must be), what versions of system libraries you need to have and what other applications too. So when you have basic system definition, you can run all closed source software on that what are done for specific LSB-standard version. What you can find from /etc/lsb-release. The LSB-standard does not tell anything about operating system, thats why the uname command is done. The one problem is that there is different kernels, not just one "mystical" kernel what is always just a kernel and operating system is that kernel + something. The kernel can be alone a operating system, but not always.
And this makes the dificult to speak in usual terms about operating systems because the OS structure can be different so not all OS parts are in the kernel while others are. And when talking OS's like Linux (kernel) you can have driver API's what is kernel API for driver to function correctly. But then you have System Call API, what is same as API for Operating System. It is very difficult to discuss exactly the same things when talking on monolith operating systems (Linux, FreeBSD, OpenBSD etc) and OS's what are microkernel-based, because their functionality is very different and they are located to two address-space instead one like monolith. You can find more information from [Herder.pdf] for first start. The other problems comes when talking about political propaganda (GNU/Linux) and marketing purposes. Then you ain't talking anymore only about OS, even that you are talking of it too. There is multiple Linux-distributions what follows the specific LSB-standard, but not all. So thats why you can not find the lsb_release command on these. But still they are using same OS but not same standard of base system. Golftheman (talk) 13:25, 7 March 2009 (UTC)[reply]
The option -o (operating-system) is indeed GNU-specific. But I wouldn't call it propaganda. GNU separates kernel from OS, because "GNU" (e.g. Debian) can run not only on top of Linux (GNU/Linux) but also on top of FreeBSD kernel, HURD kernel, Solaris kernel+libc,Minix (early stages at this point) and potentially others. You can't call those systems "Linux", but they share most of their userspace with it. Thus the name "GNU" is the most appropriate.
Anyway, I just wanted to ask: when was the option -o added to GNU's uname? Is it a reaction to Linux being used as the favorite kernel? Tzafrir (talk) 13:57, 22 August 2010 (UTC)[reply]
GNU uname first implemented -o support in sh-utils 2.0.12 [1] (released May 2002 [2]), which predates the first GNU Coreutils release (coreutils merged fileutils, textutils, and sh-utils together in coreutils-4.5.1 in September 2002 [3]) Adam KatzΔtalk 00:12, 6 October 2010 (UTC)[reply]
A software system, according to Wikipedia, is a vague term that can mean anything related to software that runs on a computer. Your definition of that term is better applied to operating system while your definition of operating system is indistinguishable from that of a kernel. You are right about Darwin being itself an operating system built atop the XNU kernel, but Mac OS X is merely a derivative operating system (much like the way Ubuntu is built atop Debian, especially if you were to assume that Debian lacks Xorg, GTK, and Gnome). The BSD-derived Darwin version of uname misleadingly returns "Darwin" in "uname -s" rather than "XNU," which was Apple's choice for whatever reason. The uname program in GNU Coreutils now explicitly states these things, the -s flag is for "kernel name" (e.g. "Linux") while the non-standard -o flag refers to "operating sytsem" (e.g. "GNU/Linux").

LSB stands for Linux Standard Base. Its purpose is to increase compatibility between Linux distributions so as to enable third-party packages (be they closed source or otherwise) can be more easily installed. (A "Linux distribution" is an operating system that runs on the Linux kernel.) The lsb_release command merely gathers a distribution's information (ID, description, release, codename, and LSB modules), making it the Linux equivalent to sw_vers and oslevel as noted above.

Regarding APIs, there can be an API at any level; there are kernel APIs (Linux, XNU), there are windowing system APIs (X11, Quartz), window manager APIs (Metacity, Aqua), widget toolkit APIs (Gtk+, Cocoa), desktop environment APIs (GNOME, ... arguably, Mac OS X is a desktop environment), and many more. As to the GNU/Linux naming debate, there is some heat there. The rarer term "GNU/Linux" refers to the operating system (Linux distribution) while "Linux" refers to either the OS or the kernel, a distinction that can usually be made from context. The "GNU Operating System" would be named GNU/Hurd using that naming scheme, though it is redundant because Hurd is a GNU project (neither the Linux kernel nor any Linux distribution is a GNU project). The Linux operating system uses all of the GNU operating system except the still-incomplete kernel (Hurd) and is thus sometimes referred to as GNU/Linux. As noted above, there are other GNU variants that complete the GNU operating system with other kernels, including (most notably) Debian GNU/kFreeBSD. Adam KatzΔtalk 00:12, 6 October 2010 (UTC)[reply]

Recent revert[edit]

I recently reverted the article body (keeping the new interwiki links) to a version from this time last year. The content added from that point consisted entirely of the following:

  1. Trivial additional examples. This happens because, as noted previously, people find it easy to tack things onto lists even if they're only meant to be representative and not comprehensive.
  2. Material copied verbatim from The Open Group Base Specifications Issue 7. This material is © The Open Group, and I can't see any licensing terms which would allow for the inclusion of verbatim chunks of said text to be used here.
  3. Original research of various forms, including ranting about the difference (or lack thereof) between operating systems and kernels, or about the almost entirely unrelated concept of Internet user agents.

None of this is worth keeping, and #2 in particular could very easily get us into trouble. Hence the revert. Chris Cunningham (not at work) - talk 19:02, 17 July 2009 (UTC)[reply]

Seems that you had reversed the wrong information to the article and lies from GNU propaganda about uname print. How does that help peole who are not GNU fans? I tried to check the information for what you have reverted and the info what there was to clean the false information, what is now again brought to visible. Please revert your edits back to explain how the GNU version is misleading facts about twisting the uname prints and adding unstandard -o option to GNU/Linux. Golftheman (talk) 12:41, 23 September 2009 (UTC)[reply]
As you've been told repeatedly, we cannot derive information in articles from our own interpretation of primary sources. For what it's worth, I actually agree with your premise, but not with the way in which this article was used as a soapbox to call the FSF out about it. If a reliable, secondary source can be included which does its own interpretation to reach this conclusion (that GNU uname deliberately provides nonstandard output for the sake of conflating the GNU userland with what uname has traditionally deemed to be the OS) then I'll be more than happy to include that information in a neutral fashion. Chris Cunningham (not at work) - talk 15:26, 23 September 2009 (UTC)[reply]
please tell what more you need than black and white about IEEE standards what are used everywhere else because it is a standard. And then black and white from GNU version of the uname application? If the standard uname does not even mention the -o option and does not refer OS as kernel, like GNU version. Why can not logical person notice the mistake? You can check the uname options from any other Unix system what has not using GNU uname and you notice they follow only the IEEE standard functions and the uname prints always the OS name. Not name of the kernel. But when you use the GNU version of uname, it has changed explanations and added -o function what is not part of the IEEE standard. We do not need some kind person writting on the blogs or academic text to tell the same thing what everyone can notice when comparing IEEE standard uname and GNU version of uname. It is simple as that. And to be a dictionary, it is need to be a informative that GNU is not following IEEE standard. Thats why there was left the GNU version and explanation how it differs and WHY it is different. If we just remove GNU from the whole article, it is not again the truth but half of it and it causes that some people again "repairs" it to GNU version. If we check the opengroup, what maintains the standard of uname http://www.opengroup.org/onlinepubs/009695399/utilities/uname.html or any other site what follows the IEEE standard http://www.squarebox.co.uk/cgi-squarebox/manServer/usr/share/man/man1p/uname.1p#3 and http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPages/man1/uname.1.html and then we compare the IEEE standard to GNU's own official uname version http://www.gnu.org/software/coreutils/manual/html_node/uname-invocation.html anyone can clearly see that how it has changed to support GNU's own GNU/Linux propaganda (and it is propaganda, not mistake or similar). And you can find more history about RMS own fame chase with history http://www.mail-archive.com/linux-users@it.canterbury.ac.nz/msg21956.html As everyone can see, the status quo of article supports the GNU own ideology, not the IEEE standard what everyone else supports. If we can not even use use the standards on the article but the twisted versions, the article has no truth at all and so on no meaning. Question is, is the IEEE version correct or is the GNU correct? I say we need to use IEEE version as base because it is the standard and truth. But include the GNU release (as I did) to tell the people how the GNU version of uname is different and what is it's goals with it. Golftheman (talk) 09:05, 8 October 2009 (UTC)[reply]
Both are correct. The GNU version is clearly not an implementation of the specification defined by the open group but a similar one (enhanced, I'd say) -- there is a clear explanation as to -why- the -o option is needed and why it is not in the open group specification: the open group assumes that the kernel and the operating system are impossible to separate in any meaningful way and that by knowing which kernel or operating system a system is running on you automatically can assume something about the other. For the GNU operating systems this is not true. For operating systems using Linux, this is not true. For operating systems using the BSD kernel this is not true. And so on. The reality is that the open group specification is ancient and has not kept up with how operating systems work. The only sane thing that the FSF can do in such a situation is to keep their implementation as close to the "correct" behaviour as is feasible while also making the needed changes. I believe that the GNU version of uname does just that. 80.162.60.16 (talk) 23:29, 26 January 2012 (UTC)[reply]

Proposed rewrite[edit]

I find that the discussion section has more useful information about the various uname implementations than the main article -- I also think that the table provided is mostly useless as it is little more than a table of example outputs on various hardware and software combinations:

I propose that a rewrite be done with focus on the uname implementaions; GNU has one implementation, Apple another, AIX a third and so on; make a tables which provides information about what information each implementation provides on a given hardware platform and one for software platforms (kernels, operating systems).

For example, a (minimal) table for the hardware side could be:

Processor GNU Apple
Intel Core 2 Duo (64 bit) x86_64 x86_64
PowerPC PowerPC PowerPC

(the precision of the above table is irrelevant). An equivelant for kernels:

Kernel GNU Apple
Linux Linux N/A
XNU Darwin Darwin

Again the precision is irrelevant; this is just for illustrative purposes. — Preceding unsigned comment added by 80.162.60.16 (talk) 10:30, 26 January 2012 (UTC)[reply]

Low quality of table values[edit]

As long as people post results that have been collected with third party software like GNU uname, the table is useless. Please use only the official software to post results. Schily (talk) 15:19, 29 January 2016 (UTC)[reply]

Please stop faking command outputs[edit]

For the invalid editing reason See MOS:LINUX. GNU/Linux is not a name that is used on Wikipedia of a recent edit.

Saying I have the following example from an operating system:

$ uname -a
Linux am335x 3.2.0 #568 Sat Jun 3 14:54:59 CST 2017 armv7l GNU/Linux
$ uname -m
armv7l
$ uname -o
GNU/Linux

Someone said "No! the name GNU/Linux shouldn't be used on Wikipedia", and going to alter the original program outout; wasn't this behavior sounds crazy?

Low power (talk) 05:13, 18 May 2021 (UTC)[reply]

I think GNU/ should not be prepended to the Android at least. It is explicitly not GNU/Linux and also appears to have been edited without actually checking.

Example from a Chrome OS Android instance follows, using the native uname:

chronos@localhost $ adb devices
List of devices attached
emulator-5554   device
chronos@localhost $ adb shell uname -o
Linux
chronos@localhost $ adb shell uname -a
Linux localhost 5.10.136-987432-g055a9052785d #1 SMP PREEMPT Wed Oct 26 21:14:53 PDT 2022 x86_64

Other unames (toybox, suckless sbase, Heirloom, BSD baseutils, etc.) also don't report GNU/ by design - they're not GNU. Most users will probably see coreutils or busybox uname so I'm fine with leaving GNU/ on most distros here, but it shouldn't be included in Android if we're going by "what does uname -o report?" metric. Rwoodsmall (talk) 17:15, 21 November 2022 (UTC)[reply]