Software and hardware annotations 2010 April

This document contains only my personal opinions and calls of judgement, and where any comment is made as to the quality of anybody's work, the comment is an opinion, in my judgement.

[file this blog page at: digg del.icio.us Technorati]

100429 Thu Laptop battery capacity halved
So I have been using using my laptop a bit too much standalone, so the battery has been discharged fully a few times, and then recharged, and the result is that it has lost another chunk of capacity in a few days:
  Battery #1     : present
    Remaining capacity : 3765 mAh, 92.62%, 02:59:17
    Design capacity    : 7800 mAh
    Last full capacity : 4065 mAh, 52.12% of design capacity
    Capacity loss      : 47.88%
    Present rate       : 1260 mA
    Charging state     : discharging
    Battery type       : rechargeable, LION
    Model number       : NS3P3SZNJSWR
    Serial number      : 12632
100424 Sat Battery at 60%
  Battery #1     : present
    Remaining capacity : 4606 mAh, 99.48%, 00:00:01
    Design capacity    : 7800 mAh
    Last full capacity : 4630 mAh, 59.36% of design capacity
    Capacity loss      : 40.64%
    Present rate       : 65231 mA
    Charging state     : charging
    Battery type       : rechargeable, LION
    Model number       : NS3P3SZNJSWR
    Serial number      : 12632
100403 Sat Very many changes to RHEL5 kernel

Somewat surprising evolution of the Red Hat Enterprise Linux 5 kernel, where since the release of the first RHEL5 2.6.18 kernel in 2007 its sources have nearly doubled in size as Red Hat have been backporting drivers and features to it from more recent kernels:

lftp> pwd
ftp://FTP.RedHat.com/pub/redhat/linux/enterprise/5Server/en/os/SRPMS
lftp> dir -tr | grep kernel
-rw-r--r--    2 ftp      ftp      48137499 Jan 27  2007 kernel-2.6.18-8.el5.src.rpm
-rw-rw-r--    2 ftp      ftp      48143032 Mar 09  2007 kernel-2.6.18-8.1.1.el5.src.rpm
-rw-rw-r--    2 ftp      ftp      48151578 Apr 16  2007 kernel-2.6.18-8.1.3.el5.src.rpm
-rw-rw-r--    2 ftp      ftp      48167315 May 14  2007 kernel-2.6.18-8.1.4.el5.src.rpm
-rw-rw-r--    2 ftp      ftp      48176455 Jun 13  2007 kernel-2.6.18-8.1.6.el5.src.rpm
-rw-rw-r--    2 ftp      ftp      48176889 Jul 06  2007 kernel-2.6.18-8.1.8.el5.src.rpm
-rw-rw-r--    2 ftp      ftp      48193718 Sep 12  2007 kernel-2.6.18-8.1.10.el5.src.rpm
-rw-r--r--    2 ftp      ftp      48194956 Sep 27  2007 kernel-2.6.18-8.1.14.el5.src.rpm
-rw-rw-r--    2 ftp      ftp      54386174 Oct 11  2007 kernel-2.6.18-53.el5.src.rpm
-rw-rw-r--    2 ftp      ftp      48213186 Oct 19  2007 kernel-2.6.18-8.1.15.el5.src.rpm
-rw-rw-r--    2 ftp      ftp      54421174 Nov 28  2007 kernel-2.6.18-53.1.4.el5.src.rpm
-rw-rw-r--    2 ftp      ftp      54461630 Jan 18  2008 kernel-2.6.18-53.1.6.el5.src.rpm
-rw-rw-r--    2 ftp      ftp      54464006 Feb 12  2008 kernel-2.6.18-53.1.13.el5.src.rpm
-rw-rw-r--    2 ftp      ftp      54492476 Mar 03  2008 kernel-2.6.18-53.1.14.el5.src.rpm
-rw-rw-r--    2 ftp      ftp      61784494 Apr 30  2008 kernel-2.6.18-92.el5.src.rpm
-rw-rw-r--    2 ftp      ftp      54521781 May 04  2008 kernel-2.6.18-53.1.19.el5.src.rpm
-rw-rw-r--    2 ftp      ftp      54540423 May 19  2008 kernel-2.6.18-53.1.21.el5.src.rpm
-rw-rw-r--    2 ftp      ftp      61794049 Jun 03  2008 kernel-2.6.18-92.1.1.el5.src.rpm
-rw-rw-r--    2 ftp      ftp      61800298 Jun 25  2008 kernel-2.6.18-92.1.6.el5.src.rpm
-rw-rw-r--    2 ftp      ftp      61830597 Aug 04  2008 kernel-2.6.18-92.1.10.el5.src.rpm
-rw-rw-r--    2 ftp      ftp      61870519 Sep 23  2008 kernel-2.6.18-92.1.13.el5.src.rpm
-rw-rw-r--    2 ftp      ftp      61917389 Nov 04  2008 kernel-2.6.18-92.1.17.el5.src.rpm
-rw-rw-r--    2 ftp      ftp      61921516 Nov 11  2008 kernel-2.6.18-92.1.18.el5.src.rpm
-rw-rw-r--    2 ftp      ftp      61939669 Dec 16  2008 kernel-2.6.18-92.1.22.el5.src.rpm
-rw-rw-r--    2 ftp      ftp      68237571 Dec 17  2008 kernel-2.6.18-128.el5.src.rpm
-rw-rw-r--    2 ftp      ftp      68254154 Feb 09  2009 kernel-2.6.18-128.1.1.el5.src.rpm
-rw-rw-r--    1 ftp      ftp      61957273 Feb 24  2009 kernel-2.6.18-92.1.24.el5.src.rpm
-rw-rw-r--    2 ftp      ftp      68293923 Mar 31  2009 kernel-2.6.18-128.1.6.el5.src.rpm
-rw-rw-r--    2 ftp      ftp      68324316 May 06  2009 kernel-2.6.18-128.1.10.el5.src.rpm
-rw-rw-r--    1 ftp      ftp      61961375 May 19  2009 kernel-2.6.18-92.1.26.el5.src.rpm
-rw-rw-r--    2 ftp      ftp      68370549 Jun 15  2009 kernel-2.6.18-128.1.14.el5.src.rpm
-rw-rw-r--    2 ftp      ftp      68373085 Jun 29  2009 kernel-2.6.18-128.1.16.el5.src.rpm
-rw-rw-r--    1 ftp      ftp      61960372 Jun 30  2009 kernel-2.6.18-92.1.27.el5.src.rpm
-rw-rw-r--    2 ftp      ftp      68370655 Jul 14  2009 kernel-2.6.18-128.2.1.el5.src.rpm
-rw-rw-r--    2 ftp      ftp      68402235 Aug 03  2009 kernel-2.6.18-128.4.1.el5.src.rpm
-rw-rw-r--    2 ftp      ftp      75420211 Aug 19  2009 kernel-2.6.18-164.el5.src.rpm
-rw-rw-r--    2 ftp      ftp      68404811 Aug 21  2009 kernel-2.6.18-128.7.1.el5.src.rpm
-rw-rw-r--    2 ftp      ftp      75483865 Sep 28  2009 kernel-2.6.18-164.2.1.el5.src.rpm
-rw-rw-r--    2 ftp      ftp      75513971 Nov 03 09:56 kernel-2.6.18-164.6.1.el5.src.rpm
-rw-rw-r--    2 ftp      ftp      75608874 Dec 09 19:16 kernel-2.6.18-164.9.1.el5.src.rpm
-rw-rw-r--    2 ftp      ftp      75613765 Jan 06 15:34 kernel-2.6.18-164.10.1.el5.src.rpm
-rw-rw-r--    2 ftp      ftp      75660747 Jan 06 22:09 kernel-2.6.18-164.11.1.el5.src.rpm
-rw-rw-r--    2 ftp      ftp      75700222 Mar 02 21:17 kernel-2.6.18-164.15.1.el5.src.rpm
-rw-rw-r--    2 ftp      ftp      83074284 Mar 17 19:38 kernel-2.6.18-194.el5.src.rpm

To me this looks rather unhealthy: if Red Hat are doing this it must be pretty important, as backporting is a rather expensive and often difficult activity, but then if backporting is really needed implies that customers want newer kernels.

Put another way, the RHEL release cycle is too slow, as the colossal amounts of backporting shows. But the same time it is too fast, as there are lots of RHEL4 and even RHEL3 systems arond that nobody wants to change, for example because there are applications binaries that are difficult to rebuild for newer versions.

The root of the problem is that applications binaries require stable ABIs (stable as to semantics too), and there is no good way to check, never mind ensure, that ABIs are stable, or more precisely backwards compatible. The reason for this is that both APIs and ABIs cannot be explicitly represented and thus compared (to check backwards compatibility) in the sources and binaries of most programming languages, in particular most of those used on POSIX (or WIN32 or .NET) platforms. For binaries debug symbol tables somewhat help, but that's not quite enough. For WIN32 applications things like COM seem to offer some help as interfaces are indeed named, but within the ABI they are assigned runtime unique identifiers, which make them incommensurable with each other, which does not help.

The correct approach would be to have interfaces not only explicitly but also with something like various forms of composition. But of course the reality is that such concerns are considered too intellectual and we are stuck with the bad choice of having stable platforms with backports, and the mixed Red Hat strategy of backports for server platform components but potentially disruptive upgrades for some desktop ones (such as browsers and word processing).

Actually I suspect that it would be better to have essentially static production platforms, with very coarse freezing of interfaces, and turn things like RHEL point releases into proper updates, with small breaks of backwards compatibility. People who want production typically want absolute stability, and people who want updates usually do not care that much about absolute backwards compatibility.

There is a problem though, and it is that production hardware gets updated, often incompatibly, and if an old server dies, it can be difficult to buy the same model, and a newer model may not be supported by an older stable software platform release. The correct solution to that is to do what serious production oriented organizations do, that is to stock spares of old hardware. But many less serious organizations want it all: to upgrade hardware opportunistically while keeping software platforms constant. Thus the RHEL backports consisting mostly of drivers.

But at least the one ABI that is quite carefully maintained and kept (fairly) rigorously backwards compatible for GNU, Linux and UNIX platforms is that for kernel system calls. Unfortunately there is no constant ABI for drivers, at least for Linux, and the kernel usually offers other interfaces, like virtual filesystems such as sysfs or procfs whose layout and content do change. But using a newer kernel on an older platform looks to me better than backporting and can be a better solution to the problem of hardware inconstance.

The other major ABI that is quite carefully maintained backwards compatible is the X network protocol (not the X11 library ABI), which means that the X server can be upgraded to accomdate new hardware, which it often has to (and Red Hat unfortunately do not upgrade the X server).

Or put another way there is some gap between the stable enterprise and server oriented distributions (mainly RHEL, Debian, Novell's SLES) with their very slow progress (and official or unofficial backports) and the other much more frequently updated distribution that as a rule do not make any ABI stability promises.

Ultimately it all does not matter that much in the marketplace, as the similar but yet much worse issues with MS-Windows products show, as backporting and system upgrades are accepted to cause extensive problems and have spawned an entire industry for rollout management.