Messages in this thread | | | From | "Fred Reimer" <> | Subject | RE: Binary compatability is about ADMINISTRATION! | Date | Mon, 15 Feb 1999 17:14:37 -0500 |
| |
I took out Linus' email as I figure he can read the mailing list when he want's and does not need comments from the likes of me flooding his mail box :-)
Anonymous,
Your points are well taken but you must consider the reality of the situation also. I can't speak for the administators at MIT, but I would not officially support any user (student or faculty) that was still using 0.98 or some other ancient version of Linux. If they wanted to use it then fine, but don't expect support for crusty software. Take some examples from other "network" type OS's. Novell, know anyone running 2.15 anymore? Does Novell even support that, let alone network administrators all over the world? What about Windows 2.0 (or even 3.11 for that matter)? Is that "officially" supported? Do you know anyone in their right mind that would "officially" support Windows 3.1, 3.11, 95, 98, NT3.51, AND NT4.0 concurently (assuming it's a Microsoft shop)? Even Sun has major compatability issues with SunOS 4.x/5.x (SunOS/Solaris).
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." I know this may seem harsh for some viewers, but it's not really. The story would read quite differently if we were talking about proprietary/commercial products "No, I won't support that old version anymore, you need to spend tons of MONEY to upgrade for official support." but we are talking about a "free" OS with mostly free applications (as a percentage of those available). Yes, it would cost those users "time" which is precious, but it would also be a useful learning experience for them so it would not be for naught.
I certainly don't condone a cavalier attitude towards kernel interfaces or anything so important to an OS. However, although I have not read every comment, I have followed the gist of this thread and I honestly can't believe that MIT is officially supporting a.out binaries! Even if Monty is not officially MIT staff, the impression that I got was that he was addressing "official" support issues. I do not mean this as flame-bait, but does anyone else think that this is unreasonable? I personally think it is O.K. to have minor changes every few years in order to ensure that old systems are updated. Not that the intention is to break stuff that is only two years old, but to give incentive to those who keep relatively up-to-date.
If MIT wants to continue supporting every "version" of Linux out there, then I think they have to face the fact that they may need to put in for a FTE just for that task (compiling new versions of software for new versions of kernel/OS). Actually, this is an integral task of any "network" (meaning file-services as opposed to network infrastructure) administrator. Don't "traditional" administrators go through a constant cycle of upgrading application software on file servers as new versions get released? Isn't that the skill that separates "good" administrators from "average" or "bad" administrators? Isn't new application software installation the task that is given to the more experienced admins while simple user creation (which could be documented and done by a monkey if need be) left for those just starting out in administration? The fact that a lot of Linux' applications can be considered part of the OS itself complicates things (because you tend to think about the upgrade as a >OS< upgrade instead of application program upgrade), but it is fundamentally the same as other network based (non-Unix)OS's.
Sorry for the rant, repeated concepts, and non-sensical arguments.
Fred Reimer Eclipsys Corporation
> -----Original Message----- > From: owner-linux-kernel@vger.rutgers.edu > [mailto:owner-linux-kernel@vger.rutgers.edu]On Behalf Of Anonymous > Sent: Monday, February 15, 1999 3:24 PM > To: torvalds@transmeta.com; linux-kernel@vger.rutgers.edu > Subject: Binary compatability is about ADMINISTRATION! > > > I think you've confused the issue regarding binary compatability. > > Take another look at the original message from Monty: > http://lwn.net/1999/0211/a/monty.html
If you read it again, you'll notice that he never mentions AFS. He's not asking for binary compatability for the convenience of proprietary products. (Your feelings about THAT are quite understandable.)
He's talking about the administrative overhead of maintaining multiple incompatible binaries for THOUSANDS of machines. They obviously have source code available; he's talking about how they have finished building the third incompatible set of binaries. They're supporting machines across a wide range of kernel and library versions; they obviously can't force their users to track the bleeding edge.
For Linux to actually achieve World Domination (and I think it can), one of the keys is to reduce Total Cost of Ownership (TCO) -- eliminating administrative nightmares such as gratuitous incompatabilities is a big part of that. So is code stability; sure, Linux is extremely stable, but binary incompatibilies can make stable programs APPEAR to be buggy if you forgot to recompile something. Recompiling everything is a major undertaking even for ONE machine; it should be a rare event with a compelling reason.
This is not about making it easy to use AFS without source code. This is about eliminating unnecessary administrative overhead on MILLIONS of computers (all Linux systems), at the expense of a bit more discipline on the developer's side of things. Please don't impose this administrative overhead simply to spite the AFS developers. We'd all rather see source for AFS, but there's much more at stake here.
A cavalier attitude towards this issue is ultimately quite costly to the entire Linux community, in both direct administrative costs and opportunity costs of possible development work that never takes place because of the administrative overhead.
- 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/
- 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/
| |