Re: XBOX Linux Parralel project

On Saturday 11 December 2004 14:44, Karim Liman-Tinguiri wrote:
> Putting on my negative hat, I can think of a few disadvantages.
>
> 1) You'll still need an illegal bios to run these xbes anyway.
>
> You could, as xbeboot, use the mechinstaller exploit for example. The
> LinXDK would take care of generating the appropriate mechInstaller savegame
> image itself.

But you cannot sign the xbeboot.xbe to work with the mechinstaller.  You don't 
have the key, and neither do I.  If you link kernel + initrd into the xbe, 
each 'generation' of it will require a different key.  And the people who 
sign these xbes will soon get tired of doing it each time for everyone.

There are other less restrictive exploits, however, that might avoid this.

> 2) You'll probably need an illegal DASH to launch these xbes. A media
> player that launches from CD that then will not let you eject said CDROM to
> put in a movie isn't so much use.
>
> Why noy code an alternative dash itself using LinXDK ?

How do you plan to load it?  You'd need an MS dash exploit in order to 
bootstrap your alternative dash for starters.  The other problem you missed 
is that your linux-xdk apps won't be like normal xbox apps.  Once one is 
loaded, you're in linux. You cannot exit from it, and return to the MS kernel 
without a reboot.  Because the MS kernel is gone, you cannot chainlaunch 
XBEs.  So, making a dash which truly can launch your own XBEs as well as MS 
games is going to be... well.. difficult (TM).  The solution to this is to 
write a dash that runs under the MS kernel using the openXDK. But, like 
Grolsch, the openXDK is not ready yet.

> 3) Nobody in the 'scene' outside xbox linux cares about whether things are
> illegal or not anyway. They have no trouble getting hold of xbes of
> whatever they want, evox, xbmc etc.
> 4) Your 'sdk' will provide a significantly different api to what most
> XDK-app developers have, if indeed you have a coherent API at all. They
> aren't generally Linux developers, so I doubt they will be attracted to
> something radically different with fewer capabilities, with the only plus
> being that it's legal.
>
> The LinXDK would also allow pretty easy porting of any Linux app to XBOX;
> there are myriads of apps out there for Linux that could be interesting to
> XBOX users.

Yep, and most people in this category will already have a modded box. If they 
aren't smart enough to do that, the exploits you would need are far beyond 
their capabilities anyway.  You wouldn't BELIEVE the number of people who 
cannot master the mechinstaller process.

Generally, you might as well just run these apps from an xbox linux live-cd, 
as we already do.    Note, as I said, the people who might like 
mplayer-as-xbe will be already using xbox media center, which does provide a 
better end-user experience, you must agree.

Note, lack of legal issues will not win the sceenies over. They don't care 
about these, so if you were to succeed, you'll need to provide a better 
process for developers, as well as a better experience for end users.  And 
frankly, I believe you'll struggle to compete against the XDK as it already 
stands.

If you really, truly want to produce legal apps for the xbox that do not run 
under the linuxes we now have, better to throw your lot in with the openXDK 
team and get it to the point where it's actually useful. 
>
> 5) No 3D acceleration - you already know this one, but hey.
>
> Note that many of the illegal XBEs out there do not use much 3d
> acceleration (XBMC, E**X etc.)
>
> 6) Slower boot time - you need to load Linux then your app, instead of the
> app running directly under the Xbox-OS itself.
>
> We could drop out X and implement SDL on framebuffer directly as Jérôme
> proposed it. Hacking the kernel would not only allow lower size but also
> enhanced loading time. Remember it's a micro-distro; most of the loading
> procedure that makes standard distros slow will be stripped out, only the
> strict minimum required for the app to run is loaded.
>
Most of the standard 'loading proceedure' happens after the kernel loaded, and 
the system is chugging through the init steps. You can simply skip most of 
that, rather than hack the kernel. Time it- the actual kernel loading time 
can be made very short without the need to hack the source.


> 7) A few other disadvantages relating to xbox-linux video drivers - such as
> overscan on 1.6 xboxes, and others.
>
> In your preceding email you mentionned RAM problems. Don't forget we can
> use the X, Y and Z partitons as swap-partitions; that's what they were
> build for.

Potentially. But you'll have to copy your initrd into the cache partition and 
pivot_root to it. But it'll have to run as a loopback file, unless you plan 
to native format your swap partitions temporarily. Nasty.

I don't mean to sound pessimistic, but generally, when people think of a brand 
new idea, it usually isn't, and there's a reason it hasn't been tried 
already.  This idea has been round a few times, and each times it dies a 
death.  It's quite possible this time will be different but.... good luck, 
nonetheless.

David

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS d- s-: a-- C++ UL++++ P L+++ E--- W++ N+ o+ K- w---
O M V- PS+ PE+ Y+ PGP t 5- X+ R- tv+ b+ DI++ D+
G+ e++ h--- r++ y++
------END GEEK CODE BLOCK------


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/