Talk:Clunky laptop

Style and flow

I've fixed typos and added wiki links, all without disturbing the prose. I've tried some reflow to see if that makes it an easier read.

I'd really like to remove this bit: 'Linux, however cumbersome ' and add "as short as" to the Flash URL but I'm leaving it as is.

Adricnet 00:04, 11 January 2008 (EST)

Thanks for the edits. I'm not so "arrogant" as to not appreciate some good copy editing!! --Walter 02:19, 11 January 2008 (EST)

Rather than use pullout quotes, how about just indenting the response with a leading : ?--Walter 02:44, 11 January 2008 (EST)

Oh, wow that looks much better! I'm noting that trick down. 'arrogant' lol.

Adricnet 03:33, 11 January 2008 (EST)

The XO is clunky. Here's why.

It's dog-slow, and we know it. But it isn't the processor's fault. The software is doing 200x as much work as it needs to, and using far more memory than it needs to. The development team hasn't had time to catch its breath and figure out why in detail, but that will get solved as soon as we're not fighting forest fires (e.g. bugs that stop the system from booting; release builds that never work; hardware issues like mis-manufactured keyboards and battery holders). This prediction assumes that OLPC has competent software management, which is still an open question. It's always more fun to develop features than to tune for performance and fix bugs.

The Sugar implementation was done by people who (apparently) did not understand the history of X Windows applications, or of Unix and Linux in general. This resulted in needless incompatability with thousands of existing applications (e.g. Firefox, email readers, control panels, printing software, games, etc). As far as I know there are no plans to fix this (nobody with the relevant experience is being added to the Sugar team and tasked with making a thousand Linux applications just work when installed with "yum update"; instead the expectation is that each application will need to be manually "Sugarized" by a programmer.) I think the Sugar team has come around to the position that compatibility would be fine if somebody else did it, but it's just not their priority. This choice will cripple the platform.

The browser is a joke. It's about as capable as the average cellphone browser. This is insane when we have an industry-leading browser like Firefox just sitting around unused.

The set of applications was chosen merely by throwing in everything that happened to work.

The jury is still out on the Sugar GUI itself. Many kids seem to love it. Many adults seem to hate it. It has numerous rough edges everywhere. (The Frame obscures key GUI elements; the way you start activities will clearly not scale to more than a few dozen; it's really cumbersome to share an activity; it looks like it was designed in Soviet Russia in the 1950's; etc etc etc.) Personally I think that Sugar is one of the OLPC "miracles" that didn't work. Competent project management would replace it with an existing, working interface, rather than risk the whole OLPC project failing because of it. Make it an option, if you like -- the underlying Fedora OS allows selection of KDE or Gnome, and Sugar could be added to that list. Then see how many people actually use Sugar when they have a real choice.

OLPC research did not deliver the painless security system that wouldn't get in anybody's way; this is another "miracle" that broke. Also, the OLPC's "pretty boot" implementation was conflated with "secure boot" by time pressure, complexity reduction, and engineer exhaustion. Knowing this, OLPC didn't revise its plans to compensate, but bulled on ahead. The unfortunate result is that laptops had to be shipped "locked down" or they would boot ugly rather than pretty; but this caused manufacturing issues, numerous support issues, and has caused the demand for developer keys to be much higher than expected, stressing the infrastructure that generates them and the engineers and manufacturing techs who run it. Fundamentally the decision to ship lockdown laptops to G1G1 donors appears to have been called incorrectly. Donors, particularly those who suffered from other software or hardware problems (and couldn't diagnose them), were the victims. Freedom was also a victim; OLPC was the first vendor to ship volumes of laptops that would only run signed binaries. There's no point in praying that more malevolent vendors will neglect to pick up this feature and use it for truly gruesome DRM systems, to everyone's detriment. It remains to be seen whether the whole purpose of all this trouble, "anti-theft", is actually accomplished in any third world school situations. The instant issue can be fixed by revising the boot firmware so that it's pretty to look at, regardless of the security setting; and by releasing a signed update that automatically disables the security on laptops with G1G1 SKU's.

This leads to the final problem that has done the most to disappoint OLPC’s fans: the hubris, arrogance and occasional self-righteousness of OLPC workers. They treated all criticism as enemy fire to be deflected and quashed rather than considered and possibly taken on board. Overcoming this will be essential if the project is to succeed past its first release. Technology products improve based on user feedback. The OLPC staff will need to learn to listen to the candid criticism of outsiders for the second-generation of the laptop—or they do not deserve to build one. I couldn't have said it better myself. Just read the main article page Clunky_laptop for a perfect example. Walter, its main author, can't see the beam in his own eye. OLPC may be transparent about most things, but it does not change very well in response to external input. I have been making similar criticisms for most of a year; e.g.

#1053 OLPC needs a usable GUI (i.e. not Sugar)

#4908 Basic Sugar UI primitive is bizarre: hover, then move, then click

#4910 Sugar UI overlaps three top bars on every activity

#1310 Handheld mode: rotation, activity switching, and key-map

#1146 Must specify a service name

#961 No home for a stylus

#967 XO can't self-host an upgrade of its EC, boot firmware, or OS image

#2866 Network Manager GUI doesn't report success or failure

#4406 XO leaves trash on USB sticks

#5680 G1G1 laptops are shipping with "security" enabled

#959 Trackpad doesn't produce mouse clicks when tapped

#1311 Power button is too easy to hit inadvertently

#2684 No way to set the timezone or the time or the time format

#4912 pygtk does thousands of futex(,FUTEX_WAKE) calls unnecessarily

#4679 The sugar_datastore_service polls about 400 times a second.

#4915 SimCity gets Buddy Delete messages unnecessarily

Some of these things have been changed; others deferred indefinitely; others ignored.

I'm not saying that every suggestion I make should be implemented. Even The Economist makes dumb suggestions sometimes (like "I can't type my article on this computer because a minor jffs2 error message appeared while it was booting".) Critical small stuff I report is often fixed. Many suggestions are briefly considered. But it seems like the big questions -- like has Sugar succeeded? Has DRM/security suceeded? are never answered, because the answer is too troubling to the status quo. I was raised in startups, where you have to ask and answer these questions -- before the customers notice. Oops OLPC, they're noticing; even the press is noticing.

 Gnu 07:49, 11 January 2008 (EST)

In reply to Gnu

Performance

It is true that there's lots of low hanging optimization fruit we haven't bothered picking, yet. I thought everybody agreed that we're going to do substantial performance over Update.2.

Compatibility

It is also true that we have gratuitous incompatibilities with X applications because we chose to use DBus rather than existing (and simpler) mechanisms for startup notification and other window management tasks. As a result, sugarizing programs written with anything but Python requires more effort. But Marco knows that, and I think he had plans to redesign that part.

Usability

I think the base concept of Sugar as designed by Eben is great. The current implementation is what an 1.0 release usually looks like. Unfinished, unpolished...

I'm sure this is notg the first time you see an 1.0 user interface:

• the UNIX Bourne shell totally sucked until it got completion, history and ubiquitous "--help" for all commands;
• The first Mac "System" was just a nice sketch put on a computer screen. You couldn't actually use it for anything productive. The killer application was a paint program in black and white, with no undo;
• the AmigaOS 1.0 was not even released. 1.1 crashed every few minutes. 1.3 was still very clumsy. Until 2.0, it couldn't show its full potential.

But with all these, I could see a promise of a great idea, and I can see it in Sugar too.

Security

I think you're aggregating two very different concepts when you refer to the security system. The anti-theft system adds plenty of inconvenience for users and developers, and it's still not clear that we'll ever be able to lock down the system well enough even for automated exploits a script kiddie could use. Before pushing it further, I'd like to see statistics on how many laptops have actually gone stolen in our pilot deployments.

The activity isolation, aka rainbow, is instead something revolutionary, yet simple and neat. Do not pay attention to the original vservers design. Look at the actual implementation. What we're doing now is just an interesting twist of existing POSIX concepts, requiring just some uid/gid magic plus a few hardlinks. D. J. Bernstein would be proud of us!

User:Bernie 11:25, 11 January 2008 (EST)

PS: I think we should move this discussion to devel@ to let the others participate. We're all mature enough to talk constructively about this rather than degenerating into a stupid flamewar, are we? :-)