All this about it not being a real game console and not having a chance in the market is true, but it misses the point. The things that make Linux a wonderful operating system for general computing make it a horrible OS for consoles. Look at Linux's strengths: Multitasking, you're not going to run Street Fighter and Final Fantasy concurrently, now are you? Even if you don't use it, you still have the overhead of the context switch. Multithreading, maybe for running the game, playing music, responding? Nope! You'd do better to fill up the sound-chip's buffer, when it empties, have it send an interrupt. Player pushes a button? Interrupt. Etc. Or stability, Linux's pride and joy, done partly with memory protection, and drivers to hide the hardware. Needed so concurrent processes don't kill eachother or the kernel. But for a gaming system, you want the entire system open, if it were x86 based (Why? x86's a crap architecture, only reason to use it for computers is compatibility with legacy PC software and commodity, both not needed with a console), you'd just want it stuck in virtual mode with a big, flat addres space, and all hardware access open. You might want an IP stack for multiplayer over the internet, but not a complex system. And you'll need some type of storage device, but the kind of filesystem you'd need would bear more resemblance to ROMFS or ISO9660 than to second extended, maybe with some support for a memory dump, to save games. For a pure gaming system an OS is a liability, you'd just want a set of libraries for switching graphics modes, reading the DVD drive and such, but ones that you could ignore completely, rather than be forced to go through, as with OS system calls.
Slashdot Mirror
All this about it not being a real game console
and not having a chance in the market is true,
but it misses the point. The things that make
Linux a wonderful operating system for general
computing make it a horrible OS for consoles.
Look at Linux's strengths: Multitasking, you're
not going to run Street Fighter and Final
Fantasy concurrently, now are you? Even if
you don't use it, you still have the overhead
of the context switch. Multithreading, maybe
for running the game, playing music, responding?
Nope! You'd do better to fill up the sound-chip's
buffer, when it empties, have it send an interrupt.
Player pushes a button? Interrupt. Etc. Or
stability, Linux's pride and joy, done partly with
memory protection, and drivers to hide the hardware.
Needed so concurrent processes don't kill eachother
or the kernel. But for a gaming system, you want
the entire system open, if it were x86 based
(Why? x86's a crap architecture, only reason
to use it for computers is compatibility with legacy PC software
and commodity, both not needed with a console),
you'd just want it stuck in virtual mode with a
big, flat addres space, and all hardware access
open. You might want an IP stack for multiplayer
over the internet, but not a complex system. And
you'll need some type of storage device, but the
kind of filesystem you'd need would bear more
resemblance to ROMFS or ISO9660 than to second
extended, maybe with some support for a memory
dump, to save games. For a pure gaming system
an OS is a liability, you'd just want a set
of libraries for switching graphics modes, reading
the DVD drive and such, but ones that you could
ignore completely, rather than be forced to go
through, as with OS system calls.