WSJ

[Edward Cherlin]

On Nov 25, 2007 10:57 PM, Albert Cahalan <acahalan at gmail.com> wrote:
> Mike C. Fletcher writes:
>
> > If we are serious in our goal of educating children, we need to do a
> > few things, and some of this requires a readjustment and a
> > detachment from the question of which hardware goes where.  Does the
> > hardware matter?
>
> Yes.

Yes, the low power consumption, wireless mesh networking, camera and
microphone, and non-toxic construction matter. The known set of ports
matters. Knowing exactly how much memory is available matters for some
purposes.

But those are all nice-to-haves, compared with being able to run the
software at all. We can already run a nice subset of the laptop
software from a Live CD on almost any x86 computer, including Macs. It
would not take much effort to create a new ISO file with an up-to-date
image.

> Standardized hardware means I can count on having things, and I
> can optimize. There is a microphone. There is an input that can
> measure DC voltage levels. There is a camera that does 640x480.
> The side of the camera with the user's face is quite predictable.
> There are 3DNow! instructions. JPEG compression levels can be
> made appropriate to the display. Images can be in ideal sizes.
> The kernel and X server don't need to ship a zillion drivers.
> The control panel can be managable.
>
> > we should port to the other inexpensive laptops, if a country
> > decides to go with EEEs or Classmates, we should be in there
> > offering an EEE or Classmate-optimised Sugar + Activities +
> > Content that they can load onto those machines
>
> This is a mixed bag. It dilutes the message.

The message is already diluted, or perhaps polluted. Intel and
Microsoft have seen to that. It is vital that XO software run
unaltered but with fewer features on alternate computers that lack
some of its hardware. Then the fact that free software that runs on
their machines is actually better on our cheaper XO laptop is a major
market advantage.

> > we need to make use on multi-user machines easy, where Sugar
> > is just a desktop manager session that is run just as one
> > would run KDE or Gnome (so that computing lab situations can
> > let children use Sugar's safe, rich  without giving up the
> > ability to run KDE/Gnome)
>
> Activities which don't need special XO hardware features
> should just run, right from the GNOME menu, without anything
> extra. Activity authors should have an easy way to specify
> if this means full-screen or 1200x900 in a window.

We have Gnome on the Live CD now. What prevents us from installing it on XOs?

> The ultimate goal should be to have activity isolation be a
> normal part of the business desktop. Sugar can melt away as
> the ideas get put into regular software.
>
> > For the other countries, we need to address their concerns.  It
> > seems that at least some of the concern is because we have
> > introduced a huge barrier to entry for application porting.  That
> > means we have a pool of dozens of applications instead of hundreds
> > or thousands of activities/applications.  Even compared to other
> > Linux-based solutions, we have a tiny pool of available
> > applications, many of which are still in reasonably early stages of
> > development.  We are missing whole classes of application/activity.

It's much easier than Debian packaging of apps that come out first in
RPMs. We could organize a bunch of schoolchildren to do it for
hundreds or thousands of apps. We could probably automate most of the
process.

> I feel like such a conspiracy theorist here, but...
>
> The thought that has always come to my mind is "Python cabal".
> At times it feels like things are maliciously non-standard,
> as if intended to exclude normal Linux software.

We need to get that Sugarizing code for non-Python apps like Etoys
onto a Wiki page.

> A simple xterm should work, no matter if it is started from
> the console or if it is on a separate machine with $DISPLAY set.
> Switching to and from the xterm should work perfectly. The icon
> and title should be used for the donut display.

I'm sorry, what's wrong with the current standard console and
Developer's Console? All it takes is Ctl+Alt+F1 or Alt+0.

> Shipping full-screen programs does not mean that the window
> manager should be incapable of handling anything else. It may
> be good for the window manager to automatically attempt to
> size a window to fill the screen, but the window manager needs
> to handle the case when that doesn't work.
>
> > * we need some way for a regular, non-Sugar-fied application to
> >   be installed (easily) and run (with reasonable support) on a
> >   Sugar desktop.  We should at least have the application-depth
> >   of a *Linux* desktop available to our students.
> >       o Even if they don't integrate nicely and they have file
> >         dialogues instead of Journal dialogues (so you'll have
> >         to switch to the Journal and add the file manually)...
> >         practicality beats purity
>
> Hack every common toolkit. Shared libraries are great.
> If you change the toolkit library, you get journal support.
>
> _______________________________________________
> Devel mailing list
> Devel at lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>



-- 
Edward Cherlin
Earth Treasury: End Poverty at a Profit
http://wiki.laptop.org/go/Earth_Treasury
"The best way to predict the future is to invent it."
Alan Kay