drawbacks of backward compatibility in *NIX

kloss · 01-21-2006, 07:36 AM

Quote:

Originally Posted by Beginning Was The Command Line (article written in 1999)

The average computer user is a technological antiquarian who doesn't really like things to change. [...]
All of the fixing and patching that engineers must do in order to give us the benefits of new technology without forcing us to think about it, or to change our ways, produces a lot of code that, over time, turns into a giant clot of bubble gum, spackle, baling wire and duct tape surrounding every operating system. In the jargon of hackers, it is called "cruft." An operating system that has many, many layers of it is described as "crufty." Hackers hate to do things twice, but when they see something crufty, their first impulse is to rip it out, throw it away, and start anew. [...]
Speaking of which, Microsoft tackled the same problem in a considerably more orderly way by creating a new OS called Windows NT. [...] And indeed, NT is reputed to be a lot less crufty than what MacOS eventually turned into. [...] Windows 95 was, and Windows 98 is, crufty because they have to be backward-compatible with older Microsoft OSes. [...]
Linux deals with the cruft problem in the same way that Eskimos supposedly dealt with senior citizens: if you insist on using old versions of Linux software, you will sooner or later find yourself drifting through the Bering Straits on a dwindling ice floe. They can get away with this because most of the software is free, so it costs nothing to download up-to-date versions, and because most Linux users are Morlocks.

In the writer's opinion, Linux - and more generally, Linux software - actually escapes the drawbacks of backward compatibility. In which extent is it true? Sometimes I have the feeling that some things could be rewritten from scratch: dealing with locales, keymaps, fonts or file associations is IMHO painful, for example.
Say we don't care about backward compatibility; would Linux be faster, reliabler and simpler?

++ Kloss

NB: Full article here.

halvy · 01-22-2006, 04:12 PM

because of oss if enuff people want backward compatibility, then they will do it.. but since these are mostly people who still tinker with 386's and the such, i don't see why any advancements in the kernel, etc. should be held back for these classes of users.

let microsoft have the rest-- since they are good at fixing their os decades after release

SciYro · 01-22-2006, 07:20 PM

Linux is a kernel, and as that, it contains backwards compatibility for lots of things, old API's stay in the kernel for a year or so before its finally yanked out, and people are forced to change their programs if they havent already.

As a OS, backwards compatibility is not a big deal. Lots of popular projects solve the issue by making their "updated" project install along side their older one, with the result being backwards compatibility, without any upgrades.

If backwards compatibility was just dropped, there would be no OS. As projects would just upgrade and change their API's whenever they want, without consideration for who uses it. Image if the C library just wanked out "fopen (".....")", the OS would just not compile. Even if the OS still worked, it would take longer to make software, as each API change would require mass editing of other software before the OS could be released, slowing down development (this assumes the OS is developed like a whole, like BSD's ... Linux as a OS is developed one project at a time, each one separate-ish).