Talk:Clunky laptop

"...you are right: our biggest challenge is swaying “middle management”, to whom, in any bureaucracy, change is uncomfortable." - Excellent point, very well put. More of the same won't do it. OLPC will.

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;
  • Comment: This is totally wrong history on the Mac. The killer apps were an operating system that was intuitive and both a word processing and graphics program that were consistent and fun and worked together. A person with a term paper due the next day, and who had used a typewriter, would within 5 minutes know that this tool would make their lives better. There was not the type of criticism on the Mac when it came out that we are experiencing here. And Mac Paint did have undo work right out of the box. I knew the Mac when it first came out. There are things I like about the XO, but it is no Mac, at least not yet.' Ganderson 05:50, 15 January 2008 (EST)
• 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? :-)

Some performance problems can be fixed with profiling and a tiny bit of optimization work. ("premature optimization...") Do not make the mistake of assuming that all performance problems are like this. It's not at all a minor project to rip out the Python. (anything less is just rearranging the deck chairs on the Titanic) That said, a journey of a thousand miles begins with a single step. AlbertCahalan 04:48, 12 January 2008 (EST)

UI basics

Sugar's appearance completely ignores the simple fact that the human eye-brain system is designed to pick out physical objects. Physical objects have a 3-D look, texture, and rounded corners. MacOS got this right over a quarter century ago. Note that greyscale Macs were common for many years; the interface worked very well without color. AlbertCahalan 04:48, 12 January 2008 (EST)

That is a good point. The current Sugar icon scheme is more reminiscent of Apple's other experiment, the Newton OS. I that case, thick outlines targeted B/W and 4-bit grayscale LCD displays. More surprising to me is the lack of color and dark tones in the default Sugar UI. Where are the preference panels for adding a bit of fun and color to Sugar's appearance?

In fact, I'm not sure I've found a page on this wiki showing the OLPC's "due-diligence" of investigating the educational software systems of the past, such as Apple II, Classic Macintosh, and Windows platforms. --IanOsgood 19:25, 14 January 2008 (EST)

It's about expectations

The above list of defects doesn't even scratch the surface when it comes to the heart of the machine - its usability for education (repeat after me: it's not a laptop project...). Constructivism is great, but an educated society needs its teachers, even if it doesn't need them for precisely what it thinks it needs them for (as walking textbooks?). Negroponte shoots himself in the foot when he implies that third-world teachers are all drunks - and I say that as someone who founded a school in rural Guatemala, and had to fire an alcoholic teacher. And the list goes on.

But give it time, and all of this could be fixed. I worked at Palm when the first version of Pocket PC and the first Blackberry came out. There was nothing to worry about. These were clunky failures. But they kept going, version 2, version 3... and now PalmOS is an also-ran, not dead yet, but certainly not at the top of its market. There are more examples above.

So will the XO ever live up to its promise? There are several conditions:

1. Is there some crucial defect built into the hardware? Worse, is it built into the hardware philosophy? I'd say, no. Battery life is never going to live up to the idealized expectations - but it will be pretty good. Ditto ruggedness. But the hardware is great. Congratulations.

2. Is there some unmeetable engineering expectation software-wise? Other than deadlines (same as always), I'd say no.

3. Is the combination of marketing and fundraising good enough to keep things afloat until the software reaches that magic version 3.1 (sorry, I know we all hate Microsoft, but that's about how long it takes)? This is a definite maybe, and every contract counts. Certainly, it's not time to give up. (But remember - the competition has no such problems. Ever. Sigh. (I think it should be illegal not to pay dividends, to build up an infinite pile of cash like... but that's another issue.))

4. Are the resources available going in the right directions, and are there enough? I'd say a qualified yes, though I'd ask for a good dose less of not-invented-here-ism and constructivist evangelism.

5. Finally: Is the attitude towards criticism fostering progress and community growth? I'd say this is the weakest point, and it would be a horrible shame for this to bring down the project. Note that this is separate from the above issue. You can hear the criticism, and begin the slow process of doing the right thing - and still respond meanwhile in a way that makes the critic into an cynic. And since hope is the most precious resource for a project like this, cynics are, inadvertently, its greatest enemies.

Just some ideas.

Homunq 18:07, 11 January 2008 (EST)

Further thought: the biggest challenges are 4 and 5. Crucial to both is the relationship between OLPC and outside developers, and the ability to reach consensus on priorities. That runs both ways. Both sides need ways to listen better. I don't have the magic solution, but perhaps something like a buddy program?? Homunq 08:59, 12 January 2008 (EST)

Anonymous criticism originally posted in article

Not a bad obituary, but our work is not yet finished. We are still busy non-delivering laptops to our G1G1 donors and not answering our emails, phones, or mail. Refer to http://olpcnews.com/forum/index.php?board=70.0

As someone outside of OLPC, I have to say that I have found them very accessible. If you want a real-time response, use IRC as explained in the "contact us" page.