[IAEP] [sugar] OLPC's bizarre behaviors

[Albert Cahalan]

>> Note that we *cannot* share much of the information about the
>> possible alternatives we are examining for Gen-2 hardware
>> until decisions are final; it is the basis of serious negotiations
>> among competing parties, under non-disclosure agreements.
>
> Lest rumors of more OLPC secrets get started, let me clarify that
> much of this information is related to processor and chipset choices,
> battery and power specs, display technology, etc, etc.  These
> critically depend on vendors, prices, contracts, and protracted
> negotiation.  We'll let you know those details as soon as the
> contracts are signed.

All of this worries me. Numerous mistakes were made last time.

You ended up with no alternative vendor for the touchpad.
Even when it became obvious that ALPS could not deliver a
usable input device, you had to push on and ship anyway.

You ended up with no alternative vendor for the wireless.
Even when it became obvious that Marvell was giving you buggy
firmware and would never release the source code, you had to
push on and ship anyway. Nobody could help fix the bugs.

You ended up with closed-source EC firmware. Your one NDAed
EC developer has had quite a time dealing with the buggy junk
that was supplied. Nobody else could help.

The D-CON chip had bugs etched in silicon. You failed to let
volunteers review the design, and the result isn't excellent.

Minus the dollar figures of course, getting contracts out in
public would be very good for you. Groklaw would be a great
place to get things reviewed. You should interpret resistance
to this as an indication that somebody may be trying to put
something bad in a contract.

> The best way to show
> that a touch screen keyboard is workable, for example, is to try to
> build one.  Ditto for alternative input mechanisms, gestures and
> multitouch, etc, etc.  If you think we should do X, Y, or Z, show us
> why it's a good idea.

How can I show you that something is a bad idea?

I could build a demo, but then you might naturally (rightly or not)
say that the fault is in my implementation.

FWIW, 1920x1080 (HDTV resolution) at 254 DPI is exactly
192x108 mm. This would be an excellent choice. It avoids
round-off error in the measurements, it is perfect for video,
and fast 2x scaling is well-suited to low-res web pages.