--On January 20, 2006 5:41:13 PM +0100 Jan Engelhardt
<[email protected]> wrote:
Lots of things still out there depend on devfs. So now if I want to
develop my kmod on recent kernels I have to be in the business of
maintaining a lot more userland stuff, like mkinitrd, installers, etc.
that have come to rely on devfs.
Just like the OSS-ALSA/e100 debate: If there IS something that you
do not like [something that requires devfs], why has NO ONE objected?
(Quoting Greg: "and I have not heard a single peep out of anyone about
the email titled "Subject: devfs going away, last chance to complain"")
Not to forget there is ndevfs if you really need it.
Unfortunately I wasn't pushing on bleeding edge kernels when that thread
happened and I apologize for not speaking up then, but this is much larger
than just devfs. This is the need for development to get off the stable
kernel, and onto a development branch where it belongs so we can quit
breaking things for the stable kernel. Unless the intent is to just not
have a stable kernel anymore. If it is, then fine, lets see word from the
forces that be along those lines.
I'm just calling things as they are, right now, 2.6 is development, and
unstable. Yes it runs without crashing and is stable in that sense, but so
are a goodly lot/most of the 2.5 series (heck I ran a decent chunk of that
in production).
The problem here is I'm spending a lot of my time lately fixing things that
shouldn't need fixing. Things that are/were developed against what was
supposed to be a stable major version and has been turned into a
development version.
I realise that there are/have been policy changes, and I can see the need
and reason behind those, and I agree with them on the front, more
development is good. But it should be done in a development branch,
because otherwise it makes it damn near impossible to maintain when the
world is slowly changing under you.
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.
-
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]
