Because an operating system is only as good as the people using it
consider it to be.
> I see why M$ and others want it will all their closed
> source applications but for Linux it is just a matter of recompilation
> and that is what people really want to do.
I don't think people want to do that. I know _I_ don't want to do that.
What I do, in just about 99% of all cases, is to just install readymade
binaries. I've grown to like the fact that rpm can upgrade my system over
ftp, adn that I don't have to worry about makefiles for programs that I
don't care about all that much.
And I suspect other people feel the same way. Everybody has his own
project that he's involved with (be it the kernel or the compiler or the
libraries or more user-friendly things like KDE, Gnome, whatever), and
people usually don't want to care.
I don't expect people to track my kernels, for example, unless they are
doing real kernel development. Some people still do, but most people
obviously don't want to.
> You say you care very
> little about kernel module binary compatibility, why do you suddenly
> care about compatibility of binary only user land applictions?
Ask anybody - it's not sudden.
Compatibility is of supreme importance. It's been the #1 priority for
Linux since pretty much day one - although early on it used to be more of
a source compatibility with Solaris, simply because binary compatibility
with Linux itself didn't mean much.
Why do you think I worked hard at making Linux/alpha be binary compatible
with Digital UNIX? There's a huge power in having binary compatibility,
especially in early days of porting: moving applications over _without_
having to worry about whether there are major bugs in the compiler of the
libraries, and knowing that if something broke, it is broken in the
kernel.
> I do not say we should use one byte order or the other, I just don't
> see x86 binaries as a big reason reason for choosing one over the
> other.
What does an OS do? Really. What is the _one_ thing an OS is supposed to
do for its users?
Nice colourful icons? No.
The main reason for having an OS in the first place is to act as a buffer
between user programs and the hardware. User programs don't want to care
whether they are talking to a SCSI controller or an IDE disk. User
programs do not want to know whether the system has a floating point unit
or not. User programs just want to run, and run as efficiently as possible
given some abstraction level high enough that they don't have to worry
about each small detail.
Anything that we can reasonably do to be better at that job is our primary
directive as kernel developers. Ours is not to ask _why_ people do things.
That's why you shouldn't have policy in a kernel: the only policies that
are acceptable tend to be security-related or related to some basic
implementation or design issue that just limits what you should allow your
users to do.
And that's also why we should work hard at giving users as much freedom
ass we can. On the UltraSparc, this means the ability to run old SunOS
32-bit binaries: because people still use them, and in many cases it
doesn't actually give them anything to upgrade. On the Merced, it means
running x86 binaries.
You obviously DO have to balance all of these kinds of decisions with
other issues:
- how clean it is to implement
- what is performance like
- what are the implications for the kernel in the long run
but at least for the Merced/x86, these are all pretty much non-issues, as
the whole machine has been designed to also run x86 binaries anyway.
So why are kernel modules so different? And why are "system programs"
different (I don't mind occasionally breaking programs like "ifconfig" and
"modprobe" etc, for example)?
Basically, with kernel modules and system programs, the upside of
maintaining compatibility is not nearly as big (they are counted in the
tens rather than in the tens of thousands), and the _downsides_ are huge.
When something interacts that closely with the kernel, the implications in
the long run of maintaining compatibility are just prohibitive.
Linus
-
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/