"A week of mondays ago Albert D. Cahalan wrote:"
> > If cruft is kept, purely for the sake of backwards compatibility, when
>
> That "purely for the sake of backwards compatibility" hints at an
> attitude problem. Is backwards compatibility unimportant to you?
> You sound like a glibc developer...
>
> > better alternatives exist, then it leads to maintenance nightmares.
>
> That does not compute.
>
> 1. feature X exists for backwards compatibility
> 2. better alternatives exist
> 3. therefore, feature X is a maintenance nightmare
>
> Are you saying it was always a maintenance nightmare, or that it
> suddenly becomes one when you have something better?
:-). I can see what this month's discussion will fill up with.
There are distinct points of view here, and it's a power struggle.
Developers want to change the code in ways that are interesting to them
and not be hindered by old baggage. Everybody else wants them to change
NOTHING unless it fixes a problem they actually have.
Heck, I still have 1.2.13 kernels as backups everywhere, and they work
fine in most senses of the word. They don't support ATM and newish
ethernet cards, but that's about it. If I were connected by a modem,
I'd be fairly happy with 1.2.13.
Yes, any _single_ incompatible change that a developer works into the
fabric _doubles_ the work for everybody else. We all have to learn
about the change and its rationale and its consequences and how to "fix"
it. We all have to _do_ something.
For most, the blow is softened by use of the standard distributions, but
that only works so long as we're talking about users that are even savvy
enough to use those and their update mechanisms. The vast majority of
the several million people using linux out there are not savvy enough
for even that, and they'll just stop using linux if they have to _learn_
something in order to use it.
That's either good or bad, but it's a fact. So, if your heart's set on
evangelizing (and mine isn't - I'd be happy to lose a few million lusers
in the short term), make sure that you have backwards compatibility in
your mind at every single moment when you are coding.
> > /proc/pci is a mistake because it requires a kernel change everytime a
> > new piece of PCI hardware is released.
?? I've been adding hardware for years with only occasional efforts to
update the manufactuers names in the lists. Proc/pci is working fine
here.
> isn't something that requires serious hacking effort, and it isn't
> a tragedy when something new isn't listed.
Amen.
> > The new /proc/bus scheme places
> > the name/number database into user space where it belongs and where it
> > can be updated more frequently, or even accessed directly by apps that
> > have a better database than the free pciutils one.
>
> Fine, we can have both.
Amen. Lord penguin be blessed. Linus will judge whether the changeover to the
new scheme has advantages that will outweigh (or force) the code changes
required in user space.
#***#
Personally, I begin to see the need for a "compatibility module" that
will simply collect the old interfaces into a loadable module that can
be loaded by those utilitities that still need them. Maybe Alan would
like to manage it. He's been doing great things in 2.0.* maintenance.
No praise is high enough.
#***#
> As if it mattered, the kernel is much easier to update than userspace.
> Linus is normally quite good about backwards compatibility, so I don't
Indeed he is, as any good engineer would be in these circumstances.
When he breaks something it is in order to force development onto a new
track, and he selects the targets pretty carefully.
> need to worry much about things breaking. 2.1.xxx only messed up some of
> the system-specific network software for me. Userspace is another matter.
> Userspace has a complex web of library dependencies.
And no kidding.
> Let's ask David Parsons. He runs libc 4 BTW.
Good. Elf is obviously easier to deal with without having to incant
mysterious things at gcc/ld (and is portable) but aout has the big
advantage of being small and simple. Horses for courses.
Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/