GeneralThis forum is for non-technical general discussion which can include both Linux and non-Linux topics. Have fun!
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
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?
Distribution: Anything NOT SystemD (ie. M$) related.
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
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).