> > >Heck, 95% compatibility could even be achieved using a 100% userspace app
> > >which serves the data over named pipes.
> >
> > Screw backwards compatibilty. Sometimes you have to cut your loses and
> > move on. We don't want to end up like Microsoft and the whole brain-fuck
> > that is their dll world. (Yes, they knew it was stupid. And yes, they
> > would love to abandon it, but it's far, far too late.) We switched to ELF,
> > abandoned libc4, etc. Add another to the pile.
>
> It will be very, very hard for distributors to create a distribution which
> runs one the native 2.6 /proc interface as soon as 2.6 comes out. I think
> we must assume rewriting things like procps, init scripts, etc. will only
> start as soon as 2.6 comes out. We should provide some transitional period
> for userspace to adapt, but make clear to everybody that compatibility
> isn't going to last forever.
You must have forgotten about 2.5 which should serve as a transitional
period just fine. By the time 2.6.0 is about to be released I'll be damned
if init scripts and the rest proc related hadn't made their transition.
What was said there about making a transition for the better and M$ dlls
aswell as ELF binary format and libc4, I'd say ditch it even if we planned
to jump from 2.4 directly to 2.6.
-
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/
This archive was generated by hypermail 2b29 : Wed Nov 07 2001 - 21:00:35 EST