I wrote the original anonymous message you're replying to.
> As Linux is a relatively young OS, you have to expect a certain amount of
> incompatabilities from a 1.x version through a 2.0.x version up to a 2.2.x
> version. Yes, they should definately be minimized to the maximum extent,
> but "old" technologies should not be kept around just for the sake of
> backwards compatability (not speaking of any particular change, just
> generalities here). There is a certain point that you must say, as an
> administrator, "NO I won't support that 7 year old version of Linux (or any
> product) anymore. You HAVE to upgrade if you want official support."
This isn't the issue; when you perform a major upgrade, you're usually
prepared to handle issues such binary incompatabilities, although it's
hoped they won't arise. If there's a compelling reason to break backwards
compatability, then you do it. But it shouldn't happen because developers
are too lazy to find a compatable solution.
Monty was complaining about a binary compatability problem which was
INTRODUCED in the "stable" 2.0.x series, supposedly for PRODUCTION
use! Nobody allows such careless changes in production code. This
wasn't a 2.1.x developer's kernel. This was supposed to be a stable
release, a relatively minor upgrade to the previous release. The changes
should NOT have caused binary incompatabilities, but they DID. That's
why Monty was complaining about the carelessness here; it's the sort of
thing that can destroy all the confidence in Linux that has taken years to
build, and once the confidence is gone, it's GONE. This isn't a small or
inconsequential matter; it could affect mainstream Linux acceptance for
years to come, possibly FOREVER. If we want Linux to suceed, this sort
of thing cannot be taken lightly.
We got away with the previous incompatable changes because Linux was
still young and largely still a hacker community. That's been changing in
1998 and beyond; Linux is headed for the mainstream, and if we want it to
succeed, we MUST start acting more like professionals. End of story.
-
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/