On Fri, Jan 20, 2006 at 10:14:15AM -0700, Michael Loftis wrote:
> It's easier for an embedded system especially to pick a target, and then
> stay with it. Later when a new major version comes out the time can then
> be invested ONCE to redevelop what needs redeveloping, which is easier to
> do (yes I'm speaking from a business standpoint, sorry, but someone has to)
> and to sell to management than nickel-and-dime to death of trying to follow
> a development tree.
Please note that the current development strategy suits embedded folk.
With the old model, embedded folk could not wait two years for a (eg)
2.5 kernel to become a 2.6 kernel and then "stabilise". In two years,
the new SoC is already in full-use in multiple applications and folk
have been and long gone developing their products.
So what happens is a massive conflict of interest - do we put
$mass-of-new-features into 2.4 kernels at the risk of destabilising
the current users, or do we push it into 2.5 and wait two or more
years before folk start using that code.
Like it or not, the latter causes a _lot_ of difficulties for a _lot_
of people, so much so that it's an economic disaster unless you're a
large corporation. The former is also a non-starter because then you
end up with folk complaining that it should be in the development
branch. It's a no-win situation - you can't satisfy everyone.
So, our current model is a compromise - you get _told_ that things
will change well in advance, and if you choose to ignore those warnings
(or don't respond to them) that's entirely your own problem.
It's like a stick and carrot scenario - see
http://everything2.com/index.pl?node=stick%20and%20carrot
The carrot in this case is the notice about devfs removal. The
stick is the actual devfs removal. One's pleasant, the other isn't.
Which you take notice of is entirely your choice.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
