-
Section menu
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]
Section menu
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
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
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.
