> I noticed (when it made one of my test machines blow up and die) that
> 2.2 doesn't support the old-style F_EXLCK locking anymore. This little
> patch (against 2.2.10) puts that locking back, so that people using a.out
> gdbm programs won't have them blow up on them.
Uhhuh. I can quite understand not wanting to upgrade from libc4 / a.out
binaries, but I can't understand sticking with libc4 & a.out, and then chucking
the 2.2 / 2.3 kernel on it. That's just weird. Why not stick with 1.2.13 or
2.0.37? If there are outstanding bugs in those versions they can be maintained
by whoever is interested -- I assume you patch libc4, so how would this be
different?
The theory is that after a major version or two we can drop the really old
stuff. It's not doing harm /per se/, but it's nice to view the current kernel
source as a reference implementation (reasonably) unencumbered by cruft.
> Backwards compatability is good.
Backwards compatability is good in moderation.
If you have binaries for which you have no source, they *will* eventually
break. Binaries without source should IMHO be viewed as unsupportable[1].
S.
[1] And I include commercial products in that. My life has become a lot less
stressful since I stopped having to work with Win95/8, NT, SCO, VMS.. Though
I agree with you that the libc-of-the-month that gets shoved in distributions
is somewhat irritating. Where did I put that OpenBSD CD?
-- A neutron walks into a bar. "I'd like a beer" he says. The bartender promptly serves up a beer. "How much will that be?" asks the neutron. "For you?" replies the bartender, "no charge"- 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/