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/