Joe (uh@no.way) on 5/6/07 wrote:
>
>Yeah, which is why Apple had a 64bit version of OSX ready
>to go as soon as they were shipping x64-capable Macs.
>
>Oh, wait.

Yeah. Great example.

There's a big difference between

"In theory you can take advantage of being single-
platform and controlling the whole stack"

and

"In practice, that just means that you don't get the
flexibility and capabilities of a wider range of hw
and usage"

and I have yet ever to see an environment where
specialization actually generated a better system.

Yes, Linux is portable, and yes, that effectively means
that core functionality does not necessarily support some
hardware-specific feature in a very integral manner. And
in theory, an operating system that can afford to integrate
the random feature of today very deeply into it could make
it more "natural".

But in practice, we've never had any real trouble with
allowing hardware capabilities to be exposed, even if they
may not be exposed as core functionality. Are you
on an x86 with magic support for virtualization? We can use
the hardware, even if not every other platform (or even
most x86 chips) actually supports that feature.

In fact, portability has in general meant that Linux has
been able to take advantage of new hardware features much
better than nonportable operating systems, exactly
because Linux doesn't make deep assumptions about
the architecture in core code. That really cuts both ways:
it very much means that new features that perhaps break
old assumptions are easier to integrate, because those old
assumptions weren't deeply encoded in some very core data
structure etc.

The 64-bit thing is an excellent example of this. Linux
was already very aware of the fact that data structures can
have different endianness and size, and so it was much
easier to move over.

But it goes deeper than that. Look at something like Cell:
where the cores are fundamentally different, but since the
"core" OS doesn't make tons of assumptions, and already has
abstracted out a lot of CPU details, we already had a lot
of the infrastructure in place for abstracting all of the
CPU details, and as a result it's not at all impossible in
theory to use the same scheduler with per-CPU queues to
schedule totally different kinds of CPU's using the same
core code!

IOW, portability is actually really hard but it also
actually does end forcing you to write better code! It's
taken us a long time to get there, but we've also had a lot
more resources than some piddling little company like Apple
(or even microsoft) can afford to put on something like a
core kernel!

Linus