Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
No date in "uname -a" anymore
39 views
Skip to first unread message
Markus Schönhaber
May 19, 2013, 8:30:02 AM5/19/13
to
Hi all,
if I do this
~# uname -a
Linux squeeze 2.6.32-5-xen-amd64 #1 SMP Mon Feb 25 02:51:39 UTC 2013
x86_64 GNU/Linux
~# ls -l /boot/vm*
-rw-r--r-- 1 root root 2482528 May 10 15:32 /boot/vmlinuz-2.6.32-5-xen-amd64
~#
on a machine running squeeze, it is trivially easy to see that it
doesn't run the installed kernel, just by comparing the dates. The
machine hasn't been rebooted since the last update of the kernel package.
On wheezy this is a different matter:
~# uname -a
Linux wheezy 3.2.0-4-amd64 #1 SMP Debian 3.2.41-2 x86_64 GNU/Linux
~# ls -l /boot/vm*
-rw-r--r-- 1 root root 2833376 May 15 23:58 /boot/vmlinuz-3.2.0-4-amd64
~#
There is no date in the uname output anymore, which I could compare to
the kernel image file's timestamp.
Can someone please explain what exactly the "improvement" is in removing
information from uname's output?
<rant>
If I'd like to have taken away from me stuff of which others have
decided that I don't need it, I'd still use GNOME.
</rant>
And yes, I've seen
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=694565#10
but
| The package version identifies what source was used and is thus a lot
| more useful than the build date.
doesn't sound convincing to me. As an administrator, I couldn't care
less what source was used to build the kernel package installed.
Oh, and what is nowadays the recommended method to determine whether or
not the machine is running the kernel from the latest package update?
--
Regards
mks
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/5198C146...@list-post.mks-mail.de
if I do this
~# uname -a
Linux squeeze 2.6.32-5-xen-amd64 #1 SMP Mon Feb 25 02:51:39 UTC 2013
x86_64 GNU/Linux
~# ls -l /boot/vm*
-rw-r--r-- 1 root root 2482528 May 10 15:32 /boot/vmlinuz-2.6.32-5-xen-amd64
~#
on a machine running squeeze, it is trivially easy to see that it
doesn't run the installed kernel, just by comparing the dates. The
machine hasn't been rebooted since the last update of the kernel package.
On wheezy this is a different matter:
~# uname -a
Linux wheezy 3.2.0-4-amd64 #1 SMP Debian 3.2.41-2 x86_64 GNU/Linux
~# ls -l /boot/vm*
-rw-r--r-- 1 root root 2833376 May 15 23:58 /boot/vmlinuz-3.2.0-4-amd64
~#
There is no date in the uname output anymore, which I could compare to
the kernel image file's timestamp.
Can someone please explain what exactly the "improvement" is in removing
information from uname's output?
<rant>
If I'd like to have taken away from me stuff of which others have
decided that I don't need it, I'd still use GNOME.
</rant>
And yes, I've seen
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=694565#10
but
| The package version identifies what source was used and is thus a lot
| more useful than the build date.
doesn't sound convincing to me. As an administrator, I couldn't care
less what source was used to build the kernel package installed.
Oh, and what is nowadays the recommended method to determine whether or
not the machine is running the kernel from the latest package update?
--
Regards
mks
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/5198C146...@list-post.mks-mail.de
Claudius Hubig
May 19, 2013, 9:00:03 AM5/19/13
to
Dear Markus,
Markus Schönhaber wrote:
> ~# uname -a
> Linux wheezy 3.2.0-4-amd64 #1 SMP Debian 3.2.41-2 x86_64 GNU/Linux
> ~# ls -l /boot/vm*
> -rw-r--r-- 1 root root 2833376 May 15 23:58 /boot/vmlinuz-3.2.0-4-amd64
> ~#
>
> There is no date in the uname output anymore, which I could compare to
> the kernel image file's timestamp.
You are now supposed to compare the Debian package version reported
by uname (3.2.41-2 in the example above) against the one currently
installed (e.g. using dpkg -l). /proc/version still reports the build
time for me, though.
> doesn't sound convincing to me. As an administrator, I couldn't care
> less what source was used to build the kernel package installed.
As the source package used to build the kernel uniquely identifies the
kernel, you should only care about the source package version?
Best,
Claudius
--
Please don’t CC me.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20130519134...@ares.home.chubig.net
Markus Schönhaber wrote:
> ~# uname -a
> Linux wheezy 3.2.0-4-amd64 #1 SMP Debian 3.2.41-2 x86_64 GNU/Linux
> ~# ls -l /boot/vm*
> -rw-r--r-- 1 root root 2833376 May 15 23:58 /boot/vmlinuz-3.2.0-4-amd64
> ~#
>
> There is no date in the uname output anymore, which I could compare to
> the kernel image file's timestamp.
by uname (3.2.41-2 in the example above) against the one currently
installed (e.g. using dpkg -l). /proc/version still reports the build
time for me, though.
> doesn't sound convincing to me. As an administrator, I couldn't care
> less what source was used to build the kernel package installed.
kernel, you should only care about the source package version?
Best,
Claudius
--
Please don’t CC me.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Markus Schönhaber
May 19, 2013, 10:20:02 AM5/19/13
to
Thanks for your answer, Claudius!
19.05.2013 14:41, Claudius Hubig:
> Markus Schönhaber wrote:
>> ~# uname -a
>> Linux wheezy 3.2.0-4-amd64 #1 SMP Debian 3.2.41-2 x86_64 GNU/Linux
>> ~# ls -l /boot/vm*
>> -rw-r--r-- 1 root root 2833376 May 15 23:58 /boot/vmlinuz-3.2.0-4-amd64
>> ~#
>>
>> There is no date in the uname output anymore, which I could compare to
>> the kernel image file's timestamp.
>
> You are now supposed to compare the Debian package version reported
> by uname (3.2.41-2 in the example above) against the one currently
> installed (e.g. using dpkg -l).
OK, that is a way. To me, this seems to be a very awkward way, though.
> /proc/version still reports the build
> time for me, though.
Alas, for me it doesn't.
>> doesn't sound convincing to me. As an administrator, I couldn't care
>> less what source was used to build the kernel package installed.
>
> As the source package used to build the kernel uniquely identifies the
> kernel, you should only care about the source package version?
Someone seems to think I should care. They think I should care on wheezy
- but not on squid or any other Linux distribution I have to cope with.
Well, I'll continue to not care (mostly, at least)...
Anyway, it is still way beyond me how this change can be thought of as
an improvement.
I could well live with it if the oh-so-important source package version
was *added* to uname's output instead of being put in the place of the
info I really *do* care for. But as it is, someone has made a change
that gains me nothing but makes my life a tiny bit harder.
--
Regards
mks
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/5198DD3A...@list-post.mks-mail.de
19.05.2013 14:41, Claudius Hubig:
> Markus Schönhaber wrote:
>> ~# uname -a
>> Linux wheezy 3.2.0-4-amd64 #1 SMP Debian 3.2.41-2 x86_64 GNU/Linux
>> ~# ls -l /boot/vm*
>> -rw-r--r-- 1 root root 2833376 May 15 23:58 /boot/vmlinuz-3.2.0-4-amd64
>> ~#
>>
>> There is no date in the uname output anymore, which I could compare to
>> the kernel image file's timestamp.
>
> You are now supposed to compare the Debian package version reported
> by uname (3.2.41-2 in the example above) against the one currently
> installed (e.g. using dpkg -l).
> /proc/version still reports the build
> time for me, though.
>> doesn't sound convincing to me. As an administrator, I couldn't care
>> less what source was used to build the kernel package installed.
>
> As the source package used to build the kernel uniquely identifies the
> kernel, you should only care about the source package version?
- but not on squid or any other Linux distribution I have to cope with.
Well, I'll continue to not care (mostly, at least)...
Anyway, it is still way beyond me how this change can be thought of as
an improvement.
I could well live with it if the oh-so-important source package version
was *added* to uname's output instead of being put in the place of the
info I really *do* care for. But as it is, someone has made a change
that gains me nothing but makes my life a tiny bit harder.
--
Regards
mks
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Claudius Hubig
May 19, 2013, 11:30:02 AM5/19/13
to
Dear Markus,
Markus Schönhaber wrote:
Markus Schönhaber wrote:
> Thanks for your answer, Claudius!
Welcome :)
> 19.05.2013 14:41, Claudius Hubig:
> > You are now supposed to compare the Debian package version reported
> > by uname (3.2.41-2 in the example above) against the one currently
> > installed (e.g. using dpkg -l).
>
> OK, that is a way. To me, this seems to be a very awkward way, though.
It doesn’t break if you move files around, and at least to me
> > by uname (3.2.41-2 in the example above) against the one currently
> > installed (e.g. using dpkg -l).
>
> OK, that is a way. To me, this seems to be a very awkward way, though.
comparing version numbers is per se more reasonable than comparing
build dates, but YMMV, of course.
> > /proc/version still reports the build
> > time for me, though.
>
> Alas, for me it doesn't.
$ cat /proc/version
Linux version 3.7.1.a2017.3 (root@ares) (gcc version 4.7.2 (Debian 4.7.2-4) ) #3 SMP Sun Jan 13 16:24:52 GMT 2013
Maybe there is an option somewhere in the kernel compile-time
configuration?
> I could well live with it if the oh-so-important source package version
> was *added* to uname's output instead of being put in the place of the
> info I really *do* care for. But as it is, someone has made a change
> that gains me nothing but makes my life a tiny bit harder.
string (for whatever reason), so merely adding it was not an option.
Best,
Claudius
--
Please don’t CC me.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20130519160...@ares.home.chubig.net
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
0 new messages