From owner-freebsd-questions@FreeBSD.ORG Thu Apr 25 03:43:04 2013 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D8F454A4 for ; Thu, 25 Apr 2013 03:43:04 +0000 (UTC) (envelope-from freebsd-questions@herveybayaustralia.com.au) Received: from mail.unitedinsong.com.au (mail.unitedinsong.com.au [150.101.178.33]) by mx1.freebsd.org (Postfix) with ESMTP id 8F1751D65 for ; Thu, 25 Apr 2013 03:43:04 +0000 (UTC) Received: from laptop2.herveybayaustralia.com.au (unknown [192.168.0.170]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.unitedinsong.com.au (Postfix) with ESMTPSA id 5E9C05C22 for ; Thu, 25 Apr 2013 13:59:24 +1000 (EST) Message-ID: <5178A647.4030302@herveybayaustralia.com.au> Date: Thu, 25 Apr 2013 13:43:03 +1000 From: Da Rock User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130205 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-questions@freebsd.org Subject: Re: FreeBSD-update? References: <201304242307.r3ON7AEg039368@chilled.skew.org> <201304242232170093.02EE4C98@sentry.24cl.com> <20130425044744.3ebda15f.freebsd@edvax.de> <201304242332000938.0324FC0A@sentry.24cl.com> In-Reply-To: <201304242332000938.0324FC0A@sentry.24cl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 03:43:04 -0000 On 04/25/13 13:32, Mike. wrote: > On 4/25/2013 at 4:47 AM Polytropon wrote: > > |On Wed, 24 Apr 2013 22:32:17 -0400, Mike. wrote: > |> If uname -r [-a] does not give the proper version of the OS, then it > is > |> either a bug, or the documentation for uname should be changed. > |> Currently, the man page for uname gives the following option: > |> > |> -r Write the current release level of the operating system to > |> stan- > |> dard output. > | > |Also the manpage of uname(3) would require a change to make clear > |that the version of the _kernel_ is provided, which _may_ stay the > |same during patchlevels of a given version. From that point of > |view, if we consider the patchlevel _not_ being part of the OS > |_version_, the statement (as it currently reads) makes sense. > |The understanding is: Version 9.1 is the OS version, and if > |a patch has been added, it's still 9.1 (even though the more > |precise information is 9.1-p5 for example). Similarly consider > |followint -STABLE: in this case, 9-STABLE or 9.1-STABLE is being > |reported, because no "precise" version numbers exist on that > |branch (at least not in the terms of patchlevels, instead a > |repository revision number or the date of the checkout could > |be considered for precision). > | > |The uname program relies on the uname system call to get the > |system identification, which queries the information stored in a > |(struct utsname *) data structure: > | > | The uname() function stores NUL-terminated strings of information > |identi- > | fying the current system into the structure referenced by name. > | > | > | The utsname structure is defined in the header > file, > |and > | contains the following members: > | > | release Release level of the operating system. > | > | version Version level of the operating system. > | > |This part of documentation would, given the case, also require > |adjustment, refering to the kernel instead of the OS. > ============= > > > On the other hand, maybe instead of changing the documentation of uname > to accommodate a problem with freebsd update, maybe freebsd update > should be changed to accommodate the historical and expected > performance of uname. > > In other words, once I found out this problem with freebsd update > (i.e., not properly refreshing the OS version), I stopped using it, as > I was not able to ascertain the current state of my OS installation > anymore. Interesting. My only observation was that sysctl is supposed to be the 'system' database where all queries relate to. It is supposed to display everything about the system; therefore any of these data bits should be fixed here first. Anything else would be a 'feature' :)