Narcis Garcia, on dim. 20 août 2017 18:27:18 +0200, wrote: > Samuel Thibault wrote: > > The problem lies in uname's interface itself: it doesn't allow a system > > to be composed of a microkernel and userland microkernel servers. The > > current behavior of uname is the best compromise that could be found. > > What application will mostly care of as a version is the version of the > > application-visible interface, and thus the microkernel servers, thus > > uname -r's result. Then if you really want the detail, there is uname -v > > The "GNU" word is written somewhere. If uname (and maybe other calls) > does not find main microkernel's name, it should be enough with > rewriting that word with the right one any program should find.
I'm not sure what you mean. For the record, $ uname -s GNU $ uname -r 0.9 $ uname -v GNU-Mach 1.8+git20170609-486-dbg/Hurd-0.9 So it's a GNU system, release 0.9, using Mach 1.8, and Hurd 0.9. What exactly do you see wrong here? > Anyway, no bug registered for coreutils about uname? The problem is not uname(1), but uname(2), which is POSIX. Good luck with making that move :) Samuel
