The $100 laptop

[Joseph Sinclair]

Of course, any developers brainless enough to hard-code a modern application for battery runtime should be shot anyway...

The C64 level-platform was needed at the time because the industry hadn't figured out how to make the O/S tell applications about it's hardware environment, and the apps had to directly access hardware to run.
With a modern O/S, like Linux, these are no longer concerns for the application developer.  Consider that we now see a vast array of applications written for Linux that run just fine on systems ranging from an old 486, to a 64-bit AMD, to a hyper-threading, multi-core, multi-processor, NUMA system, and you realize just how irrelevant the level-platform concept has become.

Even for a really low-end system like the "$100 laptop", it's no longer important to have a static hardware platform.  It only needs to have a stable O/S, a reasonably static ABI, and very high reliability to succeed in it's targeted application.

The last time I wrote anything (other than system-level software, like device drivers) that made any assumptions about the hardware environment, was 1992, and that was only because it had to run on MS-DOS and still access the graphics system.  Everything else I've written in that time has often been O/S specific, but hasn't made any assumptions about hardware, except that the hardware could run the O/S without killing itself.
In cases where software needs access to specific hardware capabilities, all modern O/S environments provide the ability to query the O/S about capabilities, and often the O/S will still report the capability exists because it can emulate the requested hardware (OpenGL is often emulated in Linux on poorly supported graphics cards, for instance).

There's no real need for hardware modularity either, the system is intended for an environment of low technological sophistication and extremely limited resources, so the systems are expected to be kept in service at original spec for 8-10 years, forever to us, but a really short lifecycle compared to what the users are used to from their existing technologies.
If I read the available information correctly, the system is completely non-upgradeable, it's a completely sealed unit (except for the battery).

==Joseph++

FoulDragon at aol.com wrote:
> In a message dated 10/8/2005 12:49:00 PM US Mountain Standard Time, 
> unixprgrmr01 at netscape.net writes:
> 
> 
>>The solution is simple... "plug &play"?!?!? modular upgrade parts 
>>consistent with the same inexpensive pricing as the original. If well 
>>designed ( and it looks like it IS!) this will be a matter of course.
>>Lynn
> 
> 
> -Modularity costs extra.
> -It may add problems (connectors get damaged or dirty or corroded in the 
> wrong environment, the modules can be popped out and-or stolen leaving the 
> customer unable to fix it himself)
> -It still eliminates the "level platform".  Wether I'm spending $20 for the 
> upgrade or $100 for a full new machine, there's now two types of $100 lappie 
> out there, and that means you can't make nearly as many assumptions on software.
> 
> Even a nonperformance change can have impact.
> 
> Boost runtime on a charge from 30 minutes to 50, and apps hard-coded to 
> assume a 30 minute battery life and save at 25 minutes will be in the middle of a 
> save cycle when the new machine shuts off.
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss at lists.plug.phoenix.az.us
> To subscribe, unsubscribe, or to change  you mail settings:
> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
>