Subject: Re: starting with 2.7
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: John Richard Moser <nigelenki@comcast.net>
Cc: znmeb@cesmail.net,
       Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
In-Reply-To: <41E0A032.5050106@comcast.net>
References: <1697129508.20050102210332@dns.toxicfilms.tv>
	 <41DD9968.7070004@comcast.net>
	 <1105045853.17176.273.camel@localhost.localdomain>
	 <1105115671.12371.38.camel@DreamGate>  <41DEC5F1.9070205@comcast.net>
	 <1105237910.11255.92.camel@DreamGate>  <41E0A032.5050106@comcast.net>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1105278618.12054.37.camel@localhost.localdomain>
Mime-Version: 1.0
Date: Sun, 09 Jan 2005 23:02:23 +0000
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1142
Lines: 23

> I'm claiming that an IT infrastructure that has to support 2.6 as-is
> will be wildly more complex and more expensive than one supporting a
> truly stable one with the same efficiency.  It keeps changing.  New
> features must be added that aren't amply tested (and due to the 2.6
> development structure, ample testing before mainline integration is much
> more difficult).

Large IT businesses already deployed 2.6 (SuSE) and will do so more soon
(Red Hat). These vendors are guaranteeing long term stable maintenance
of those versions.

> Ask Linus to start making 3rd party binary module support a reality then.

Binary module support is pretty irrelevant. Good management of out of
tree source code recompiling is a much more useful and relevant topic. 
2.6 has caused an inadvertent problem there because with 2.4 it was
*much* easier to grab 2.4.x and drop in a 2.4.y version of a driver.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/