There was an article on Slashdot about this, basically some dudes got linux to boot in under 200ms. Thinking at least some of this could be applied to the Empeg anyway.

From what the LinuxBIOS people have done in the past, I'd say it's not that much of an amazing achievement. Most of the speed increase seems to be due to them ripping out hardware detection and removing IDE support. Also it's 200ms to get the kernel loaded and running, it doesn't mean your application is actually running at this point.

Probing the IDE interface takes a few seconds and you have to wait for drives to spin up and initialise before they'll properly respond.
As it's an embedded platform they're targeting, then they can hardwire the configuration so they don't need to do any detection of available RAM, working out how fast the processor is etc...

Okay, you could do the last part on the empeg but you can't really take out the IDE interface code for obvious reasons

The IDE code on the empeg doesn't really slow it down more than a second or so, if that. Mostly because the empeg NEEDS the IDE drives up and spinning in order to load it's software! So it's gotta wait regardless.

But wait, you say, it doesn't need to wait for a second drive in a single-drive player, right? RIGHT! That's why there's a Hijack menu item specifically for that situation.

-ml

But wait, you say, it doesn't need to wait for a second drive in a single-drive player, right?

With a bit (a lot?) more trickery, it might not have to wait for the second drive in a two drive system, until it actually needs to load some music from it.