Re: wlan interface (was: first play with new XO 1.5 machines)

2009-10-30 Thread Albert Cahalan
On Fri, Oct 30, 2009 at 8:45 PM, John Gilmore g...@toad.com wrote:

 I talked with one of the 802.11 experts I know. He's quite sure
 that there should be no problem on Atheros hardware at least.
 He has no problem transmitting arbitrary packets at arbitrary
 times and no problem receiving packets either.

Now I've talked to 5 experts, including one who was involved in
the standardization efforts.

They all agree that it should be possible, but all expect driver
problems. Firmware can ruin things. The recommended setup
is an Atheros chipset with the madwifi drivers. You generally
need to get the firmware into promiscuous (sniffer) mode, which
is not always documented. You'd be essentially doing VAP
(virtual access point) stuff; so VAP is the capability to look for.

Marvell generally doesn't support promiscuous mode, but the XO
firmware did get that feature added at one point. I don't know if
it's still there in the thinmac firmware and the XO 1.5 firmware, but
at least the classic XO setup could do it.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: wlan interface (was: first play with new XO 1.5 machines)

2009-10-29 Thread Albert Cahalan
On Thu, Oct 29, 2009 at 12:17 PM, Daniel Drake d...@laptop.org wrote:
 2009/10/26 Albert Cahalan acaha...@gmail.com:

 The issue is that A and B are both hosting their own networks, they
 are both beacon masters, spewing beacons based off their own clocks.

 How is this any different than the mesh situation?

 Exactly how the XO-1 mesh functions on this level is frustratingly
 unknown, but when I did a couple of simple observations once before,
 the clocks appear to synchronize with the neighbours.

 Which clock? Do you mean one for the individual bits, or one
 for packet-level time division?

 I mean the clock in the 802.11 MAC sublayer. This defines the basis of
 the timing synchronization function (TSF) which is a core part of
 802.11. Without synchronized clocks, nodes cannot communicate.

I talked with one of the 802.11 experts I know. He's quite sure
that there should be no problem on Atheros hardware at least.
He has no problem transmitting arbitrary packets at arbitrary
times and no problem receiving packets either. The only limit
is that you get just one channel at a time.

I'll check with a couple of the other experts I know.

The TSF stuff  looks like an optimization that you don't really need,
except perhaps when sending to a receiver that stops listening
at certain times. Lame hardware misses out, no surprise.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: wlan interface (was: first play with new XO 1.5 machines)

2009-10-25 Thread Albert Cahalan
On Fri, Oct 23, 2009 at 7:09 AM, Daniel Drake d...@laptop.org wrote:
 2009/10/23 Albert Cahalan acaha...@gmail.com:

 Thus, properly done, the XO labled C might have either of:

 a. wlan0 to reach A, and wlan1 to reach B (same hardware)
 b. wlan0, from which wlan0_0 and wlan0_1 are instantiated

 It can't do this, unless it has 2 independent clocks in the wifi
 hardware. I do not know of any hardware that does this.

 The issue is that A and B are both hosting their own networks, they
 are both beacon masters, spewing beacons based off their own clocks.

How is this any different than the mesh situation?

 C can either talk with A, by finding the beacons, adjusting its own
 clock to match. (at this point, any frames coming from B will be heard
 as noise)
 or it can adjust to B's clock, in order to speak to it (and everyone
 else who's synchronized to B). At this point, frames coming from A are
 just noise.

Which clock? Do you mean one for the individual bits, or one
for packet-level time division?

AFAIK, a clock for individual bits is not something you'd keep.
The preamble should take care of that. A packet-level clock
shouldn't cause the heard as noise issue.

If you can't deal with multiple beacon masters spewing beacons
based off their own clocks, then mesh should be impossible.

BTW, this goes beyond ad-hoc and mesh. I might want to serve
as 3 access points and be a client to 7 others. That should work,
subject only to channel and interference troubles. (hardware X can
do 1 channel in each band, hardware Y only does 1 channel total,
and hardware Z can do 2 degraded channels in 1 band)
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


wlan interface (was: first play with new XO 1.5 machines)

2009-10-23 Thread Albert Cahalan
Daniel Drake writes:

 Another laptop C comes along
 A  C -- B
 This laptop can see both of these independent laptops (each having
 its independent network). It can join one or the other. It cannot
 join both. Hence this XO can only communicate with A or B, but not
 both (even though the range is OK), and presenting this choice in
 the UI would be nasty.

This is the result of Linux kernel stupidity. It is thus fixable,
at least with soft-mac firmware.

We're treating wireless network hardware like wired network hardware,
but it's really not the same thing. Ignoring VLAN issues and such,
a wired network goes to one other place. A wireless network can go
many places at once.

Right now, you get one device named something like wlan0. You modify
parameters to move this one device about. The proper model is that
you instantiate a new instance of the device. A single wlan0 device
for the hardware is no good. The wlan0 device could...

a. exist only as an icky compatibility hack
b. not exist
c. be one of many instantiations of the hardware
d. be only used for raw 802.11-layer packet injection and sniffing
e. be only used for instantiating wireless lan devices

Thus, properly done, the XO labled C might have either of:

a. wlan0 to reach A, and wlan1 to reach B (same hardware)
b. wlan0, from which wlan0_0 and wlan0_1 are instantiated
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Disk layout for XO-1.5

2009-08-05 Thread Albert Cahalan
On Tue, Aug 4, 2009 at 2:32 PM, Martin
Langhoffmartin.langh...@gmail.com wrote:
 On Tue, Aug 4, 2009 at 4:42 AM, Albert Cahalanacaha...@gmail.com wrote:
 First partition: FAT16 with 4 KB clusters
 Second partition: LVM with ext4

 Gentlemen, before LVM can be considered, we need

  - fs resize that is fail-safe in the face of powerloss, for the fs
 types we plan to use.

  - lvm resize that is fail-safe in the face of powerloss

Unless you have a bug number, this is FUD. Where is
the bug number?

BTW, note that the flash disk itself is not certain to be
fail-safe in the face of powerloss. Neither the firmware
nor the hardware is supplied with proof of correctness.
Problems in similar hardware are not uncommon.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Disk layout for XO-1.5

2009-08-04 Thread Albert Cahalan
First partition: FAT16 with 4 KB clusters
Second partition: LVM with ext4

In the LVM, filesystems should be 50% to 80% full. This leaves some
extra space unused. As filesystems fill up, the filesystems can be
expanded to use the extra space.

Don't shrink filesystems unless they drop down to 15% to 30% full.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: is anyone actually doing Windows on XO work here?

2009-07-22 Thread Albert Cahalan
On Tue, Jul 21, 2009 at 2:46 PM, Sameer Vermasve...@sfsu.edu wrote:

 This is largely because you aren't doing normal Linux development.

 Normal. Now there's a term that's relative. Is GNOME normal? Or is it KDE?
 Or XFCE, LXDE? Enlightenment, maybe?

For this purpose: all of the above plus FVWM and probably
even Ratpoison, the mouse-free window manager. They are
quite compatible; I can run nearly all GNOME apps on KDE
and nearly all KDE apps on GNOME.

The development effort blamed on Linux is actually caused
by abandoning all the typical Linux compatibility.

 My daughter, who is almost 4 takes to Sugar quite easily, but will not
 bother with GNOME on my desktop at home. I was amazed at how easily
 she took to playing Implode on the XO in under 5 minutes. I realize that
 its a statistic of 1

Not that I was intending to suggest anything at all about the user
experience (my comment was strictly developer oriented) but...

I've seen the exact opposite. Kids seem to tolerate GNOME.
They lose things in Sugar, and they hate the slowness.
These are kids without much computer experience, and most
of that being on a computer with roughly XO-class hardware.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: is anyone actually doing Windows on XO work here?

2009-07-21 Thread Albert Cahalan
Ed McNierney writes:

 We've tried many times to make the very simple story about Windows
 support on the XO clear.  The conspiracy theorists don't really care.
 If you don't live in a fact-based universe, facts are irrelevant.
 Mitch is quite right, but we've said just about all of that before to
 little effect.  OLPCNews and Slashdot thrive on controversy, not
 accurate reporting.  I don't have much hope that we're going to say
 something now that makes the OLPC has switched to Windows crowd
 suddenly realize they're wrong.

You're not being fair to them. Your message has big problems.

Some of us know our Microsoft history. Anything you say is now
tainted by that. There is a **long** history of evil tricks.

Really there is only one way to fix the message, and I don't expect it
to ever happen. NN himself needs to personally and publicly apologize
for the XP adventure, admitting that it was harmful to the mission.
Nobody else can usefully apologize on his behalf. He probably also needs
to push a normal Linux desktop to be believable, because currently XP is
the desktop solution for the XO.

Finally, conspiracy theories are going to thrive whenever there is
a communication failure. OLPC decisionmaking is opaque, and decisions
have always been surprises. NN is simply not available to discuss
anything. Maybe you could get him on #olpc-devel twice a week or get
him to participate in two devel mailing list discussions per week.
People should feel that they know him like a Linus or Theo.

 Of course, Linux development is *far* more expensive for OLPC than
 Windows development is (and always has been), so if there were a way
 to convert all those Slashdot/OLPCNews typing fingers into volunteer
 coders it would be a nice improvement!

This is largely because you aren't doing normal Linux development.
Everything is custom. Porting from desktop Linux to MacOS is easier
than porting to the Sugar environment. For many apps, even a Windows
port is easier. Plain old Linux development is not unusually expensive.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


user-space XO hardware detection

2009-07-10 Thread Albert Cahalan
It's getting more and more important to be able to detect XO hardware
from userspace. One can no longer assume that Sugar implies XO because
Sugar runs elsewhere and because non-Sugar is getting common on the XO.
Considering the 1.5 hardware, assuming that Geode implies XO is not
going to be reasonable either.

I suppose the real needs are:

1. detect that the screen has XO-like blur
2. detect that the keyboard has XO-style keys
2a. detect that there is a multiply/divide key

If possible I'd like to do this as a regular user, without X server
help, in both Sugar and non-Sugar situations, despite any Bitfrost.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: user-space XO hardware detection

2009-07-10 Thread Albert Cahalan
On Fri, Jul 10, 2009 at 4:10 PM, Walter Benderwalter.ben...@gmail.com wrote:
 On Fri, Jul 10, 2009 at 11:20 AM, Albert Cahalanacaha...@gmail.com wrote:

 I suppose the real needs are:

 1. detect that the screen has XO-like blur
 2. detect that the keyboard has XO-style keys
 2a. detect that there is a multiply/divide key

 Many of the XO-1 machines do not have a multiply/divide key. It is the
 language key on non-Latin alphabets.

This is why I specifically mention it.

Right now I'm facing a hack: if the screen is 1200x900, then
we assume it's an XO. (both screen and keyboard) A hardcoded
locale list is then consulted to determine if multiply/divide exists.
Ew. Save me from this.

BTW, last I looked it was painful to deal with D-BUS. I'd like
to do things with as few libraries as possible, in plain C.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Browse.xo performance resolution - Hulahop 200dpi vs Browse 134dpi

2009-05-16 Thread Albert Cahalan
Martin Langhoff writes:

 The short version of it is that canvas (and image rendering in
 general) is hurting lots due to the dpi being hardcoded to 134
 which forces Gecko into image scaling games. Just setting
 layout.css.dpi to 96 makes Browse much snappier in general,
 and incredibly faster in canvas painting.

This was discovered when scaling was first enabled.

One could write a special-case scaler for that DPI,
avoiding the more generic scaling code.

The XO also suffers from 5:6:5 pixel layout, which requires
lots of bit shifting.

 It also makes pages unreadably small though.

It's not just the size. The XO screen purposely smears the pixels
to reduce color fringing.

 Questions:

 - I am intrigued, hulahop sources say it's hardcoded to 200dpi
 (and that jives with our screen) - why does it end up being 134?
 Should it be 200dpi?

134 puts 860x645 web pixels on the screen. We do this partly because
it is enough pixels for most modern web pages, and partly because of
a persistant myth that the XO screen resolution is equal to 800x600.
In other words, it's an arbitrary number with feeble justification.

There are at least two reasonable ways to deal with this problem.

The first way is to use the hardware scaling. This involves telling
the X server to change screen resolution. Sugar would need to manage
this on a per-activity basis, with adjustments to the frame as needed.
Besides elimination of scaling, the browser would move fewer pixels
and need less memory. It'd be amazing for performance. A downside is
that text would be less sharp, both from the scaler operation and more
directly from having fewer pixels.

The second way is to choose a scaling factor that is easy to optimize,
and then do so. Easy would be 128 (3:4 ratio, 900x645 web pixels) or
144 (2:3 ratio, 800x600 web pixels). You could optimize both, along
with 192 (1:2 ratio, 600x450 web pixels), and let users get a choice.
Unscaled can be an option too.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: [Server-devel] Questions

2009-05-09 Thread Albert Cahalan
Martin Langhoff writes:
 2009/5/9 david david at leeming-consulting.com:

 They have better luck (maybe my fingers are sweaty more than most)
 and I have noticed students often wrapping cloth around their
 finger to use the touch pad. It remains a real problem, but people
 do get by.

 The devel@ list archive has similar reports from the Nepal team.
 IIRC, many kids there had a small piece of cloth to sweep the pad
 of moisture and dust. Those reports were an important factor in the
 switch to a new touchpad, so as Daniel suggests, do request a sample
 one at least.

The old laptops can perform better than the new ones if you do this:

1. make the resistive/pressure mode be relative instead of absolute
2. make the resistive/pressure mode be the only mode

Maybe this needs to be a config option in Sugar.

The new touchpads might be less awful in bad conditions, but nothing
is ever going to make a capacitative touch pad work really well in
bad conditions. The technology is simply not suited to mud, snot,
cheese sauce, sweat, and so on. It's designed for adults in cool dry
office environments.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: I2C bus assignments

2009-05-01 Thread Albert Cahalan
I have a bad feeling about swiping the CRT I2C. It kind of leaves
a needless landmine for video driver authors who would prefer to
unify their code (XO and non-XO hardware) as much as possible.
Suppose a video driver attempts E-DDC. Is it going to confuse
some non-compliant I2C device or actually hit the address in use?

Bit banging the DCON sounds OK. Your comment about the DCON bug
makes this appealing, but is also worrisome. Is this not fixed
in current chips? (if not fixed, and you do decide to fix it,
please also make the two image quality fixes I requested)

You didn't mention bit banging the camera. If you're bit banging
anyway, the fact that the camera isn't correct I2C is no issue.
(please tell me I2C is for control only, not streaming video)

You didn't mention bit banging the clock generator. Impossible?
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: 3D engine uses in a no-nonsense GUI (was: XO Gen 1.5)

2009-04-25 Thread Albert Cahalan
Hal Murray writes:

 I've always thought of slide into view as annoying.  I have to
 wait around for the thing I want to look at to finish dancing.

Me too, which is why I specified fast and rapid. Animations
commonly suffer from various problems:

a. You really do have to wait, because the software is terribly
   slow, and the animation was put there to distract you.

b. The animation itself has bad performance. This is where the 3D
   engine can make a huge difference.

c. The animation is purposely slow because the UI designer fell in
   love with it and he wants you to love it too. You're supposed to
   sit there and marvel at what a wonderful animation it is.

Sometimes multiple reasons apply. Sugar activities take way too long
to start if they are written in Python, so we got a throbbing icon
for activity startup. This itself is so slow that non-Python activities
became much slower. (including Tux Paint, which is NOT lightweight)

A decent rule of thumb: if you have time to really focus on the
animation, then it is too slow. You should barely even see it as
it runs. It should only be there to direct your vision a bit,
giving you a feel for where things went or came from.

Without a 3D engine, it's not reasonable to expect such performance.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: CL1B power distribution

2009-04-24 Thread Albert Cahalan
John Watlington writes:

 - The SD slot and USB ports may be powered in suspend
  This is just in case some SD cards or USB devices don't handle
 being suspended
  aggressively.   We will support laptop wakeup on interrupt from any
  of these ports (SD or USB).   Under software control they may
 also be powered
  down during suspend.

There is value in making this per-port for the USB.

 - The audio codec remains partially powered in suspend
  This is in order to support wakeup on jack insertion.  The codec
  may be placed in a very low power state during suspend.

I would have expected power to be optional. The software doesn't
always need to use this component during the run state.

 Additional changes from Gen 1 include the ability to both measure
 DC input current and VIN voltage, as well as EC control over the
 current drawn from the DC input. The intent was to better support
 charging directly from solar panels.

I hope that this will be available to activities like Measure.

Ideally updates could be frequent enough to pick up a waveform
from an unrectified power supply. (spare audio channel?)
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


3D engine uses in a no-nonsense GUI (was: XO Gen 1.5)

2009-04-21 Thread Albert Cahalan
Christoph Derndorfer writes:

 I honestly can't think of a use-case for including any sort
 of 3D acceleration into the basic Sugar and activities. There's
 about a million significantly more important things that people
 should be working on before even thinking about 3D (IMHO).

One can use a 3D accelerator to greatly improve human factors in
the GUI. Smooth transitions in the GUI are vital to reducing the
user's sense of disorientation and confusion. This isn't just an
issue for less-clueful users; you might not realize it but poor
transitions are forcing needless mental effort that eats up a tiny
bit of time here, a tiny bit of time there... and it all adds up.
You may feel it in frustration even if you don't spot the cause.

Without the 3D engine, animations are a painful compromise. They
are slow, jerky, and CPU consuming. Imagine if the frame could
slide into view with fast perfectly smooth motion and almost no
CPU use. Think how much more usable Sugar would be.

Imagine if view switching and activity switching looked like a
rapid zoom out to showing a grid of all views and activities,
then a rapid pan to the right grid spot, and finally a rapid zoom
in to the newly selected view or activity. Better yet, make it
all in one smooth motion so that the user feels as though they
are jumping with a ballistic trajectory. The confusion goes away
and the transition might even be attractive. You can't make this
be acceptably fast or smooth without a 3D engine, even if you
cheat by using static screenshot images for the activities.

Imagine having every activity smoothly scaled to fit the screen.
An activity opens a 320x720 window. It becomes a 400x900 window
on the LCD, but the activity doesn't have to deal with that at all.
Getting stuff to work well on the XO is suddenly much much easier.

Users can spot objects on the screen faster if they have slightly
organic shapes. Rather than having **perfectly** sharp corners on
things, give them tiny anti-aliased curves. Use bump mapping and
other shader features in **subtle** ways to enhance object edges.
Make the edges look like they have been polished or sanded a tad,
instead of being infinitely sharp and thus ill-defined to the eye.

Today, pressing a GUI button normally causes the button face image
to shift a bit. That's the best we could do before 3D engines.
Imagine if the button face could pop from convex to concave, with
perfect realism. The highlights, the density of the shadow, etc.
The button metaphor would be more effectively represented to the user.

BTW, stay away from the pointless stuff. It's now common to use 3D
for random nonsense that hurts usability. Don't do that. Stick to the
stuff that helps the eye follow things: smooth motion, softened shapes,
realistic shading, quality scaling, etc.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Check this out

2009-04-20 Thread Albert Cahalan
Aaron Konstam writes:

 Unfortunately, currently it seems to be only able to
 translate whole pages not words or paragraphs.

The more you have, the better you can translate:

I offered several different types of foods. They liked
a banana more than onions, roast beef, garlic, or beets.
In general, fruit flies like a banana.

We tested numerous items in our trebuchet. A flower didn't
fly very far. A lead sinker went really far. A banana went
a medium distance. In general, fruit flies like a banana.

(and this is why text-to-speech is a very hard problem)

Look up run or set in a dictionary if you still have hope
of single-word translation.

Now add idioms and bad grammar:

I threw my mother from the train a kiss goodbye.

Ouch!
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: announce: alternate power management

2009-03-20 Thread Albert Cahalan
pgf writes:

 so:  i've packaged a new version of powerd.  the big change
 is that it now allows for the two modes of operation i mentioned
 last week on the list:
 dim
 sleep, screen on
 sleep, screen off
 shutdown
 or:
 dim
 screen off
 sleep, screen off
 shutdown

screen on and screen off aren't very well defined.
What exactly do you mean?

a. the Geode chipset: producing video or not?
b. the DCON: pass-through, freeze-frame, or off?
c. the backlight: on or off?
d. the LCD panel: on or off?
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: OLPC upgrades

2009-02-04 Thread Albert Cahalan
Bobby Powers writes:
 2009/2/2 Tiago Marques tiagomnm at gmail.com:

 Python is killing the XO, what's being done in that regard?
 The $100 laptop will always be hardware limited, how can
 python be a benefit and not a *huge* burden? I for one can't
 get my head around that.

 The idea is to give kids as much transparency into the software
 stack as possible, AND make it easy to hack on and easy to create
 new activities for.  Python is much more forgiving than C.

Python is less forgiving if you want performance on the XO. :-)

For teaching, remember that Knuth uses assembly. C is an awful
lot closer to that than Python, and isn't the XO about teaching?

 Its killing the XO?  A personal pygtk based project launches in a few
 seconds on my debXO install on an XO, but much much longer on 8.2.
 It is a completely loaded statement to say that Python is killing
 the XO, and didn't really deserve a response :)

I'm assuming that personal [...] project means small.

The fact that you consider a few seconds to be acceptable shows
just how much people have lost touch with the concept of performance.

IIRC, that's about how long it took my old Pentium 200 MMX with 64 MB
of RAM (a quarter of what the XO has) to launch Netscape.

Today on an XO, I can write code that pops up a window far faster than
it needs to. Xlib can do the job in what looks like a few tenths of a
second or better -- it's really too fast for me to tell.

Even with a feature-rich monster like Tux Paint, I can at least pop up
a window much much faster than a Python activity ever does. The stupid
generic splash screen causes a very noticeable slowdown for any activity
that wasn't horrifically slow by itself.

Current usage of Python can be mostly explained as follows:

http://en.wikipedia.org/wiki/Sunk_cost_fallacy
http://en.wikipedia.org/wiki/Sunk_cost
http://en.wikipedia.org/wiki/Irrational_escalation
http://en.wikipedia.org/wiki/Cognitive_bias
http://en.wikipedia.org/wiki/Point_of_no_return
http://en.wikipedia.org/wiki/Psychology_of_previous_investment
http://en.wikipedia.org/wiki/Foot_in_the_door

The remaining bit of the explanation is that the developer pool
is now full of Python people. Nearly all others have run away.
One can't expect to attract non-Python talent when Python gets
a non-negotiable privileged position.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


for those recently laid off...

2009-01-07 Thread Albert Cahalan
In case any low-level hackers are included in the layoffs, note
that my employer can hire a good number of them. (if US citizen)
In case you know somebody appropriate who no longer reads devel,
please let him know. People might unsubscribe when laid off, or
might have been subscribed via a now-dead laptop.org address.

Overtime is rare, and paid, so there could be plenty of time for
hacking on personal projects. The work is interesting and varied.
Some will find it to be feel-good work as well.

Since we need multiple people, you don't need to be an expert in
everything. We need versatile hackers with a wide range of skills.
Roughly, desired skills/experience goes something like this:

comfortable with a hex dump
debugger internals
emulator internals, including JIT
compiler internals
assembly for multiple platforms
reverse engineering
internals for multiple OSes
malware internals
network protocols (any and all)
embedded development in general
vulnerability discovery

It wouldn't hurt to be handy with numerous other things: soldering,
AI, WxWidgets, i18n issues, logic analyser, spectrum analyser, etc.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Why not use swfdec-mozilla?

2009-01-04 Thread Albert Cahalan
Peter Robinson writes:

 I've found it very cpu intensive on Fedora 9 and 10 with a penryn
 dual core processor. It basically pins one of the cores to 100% CPU

That could be good. 70% would be more worrisome,
because we'd have to assume the CPU was really
doing the rendering. At 100%, it becomes reasonable
to guess that the code does a busy-wait spin after
the rendering. Maybe it only needs 2% of your CPU,
and the rest is just being wasted because you have it.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: No surprise on memory

2008-12-20 Thread Albert Cahalan
[multiple people]

 I recently learned a few very important things about Linux memory
 management (I'm speaking about how its supposed to work, irrespective
 of any bugs).  Operating systems experts already know all of this,
 but I did not.

This is a good reminder for those of us who tend to assume that
anyone joining these discussions is an OS expert.

 Conclusion: no magic get-out-of-jail-free card.

There certainly isn't anything that can work with perfect
reliability, even if policy was to disable overcommit and
check malloc everywhere.

Pay particular attention to how every proposed solution meets
the real goals, remembering that nearly all activities save the
user's data via a non-atomic process that requires memory.
Simply put, it is never acceptable to force a well-bahaved
activity to die or live without the memory it demands.

 It may be interesting to adjust the OOM score of some applications.
 This way it should be possible to protect the core applications
 (sugar-shell, journal, X, ...) from being killed in an OOM situation.

 I'm with Benjamin here, if the OOM killer kicked in soon enough and
 activities were clearly marked as first candidates to be killed,
 stability would be much much better.

No way.

The core applications only exist for the desired activity. If that
desired activity must die, you might as well power off the laptop.
The only processes slightly worth saving are klogd and syslogd,
allowing developers to figure out what just happened.

 And if background activities were killed before the active one,
 we would avoid data loss.

Background activities can contain valuable unsaved state too.
Of course, this is somewhat theoretical because kids do not
intentionally have background activities. The ten activities running
in the background on a typical kid's XO are a big contributer to
these memory problems.

 Combine that with Mac OS (pre X) style estimated memory allocation
 metadata for each activity and the user experience could perhaps even
 work.

This is key. Until the UI absolutely refuses to let the user start
a set of 2+ activities that could run out of memory, memory problems
are a given. For activities with unbounded memory usage, this means
they get the machine exclusively.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: idea for running out of RAM

2008-11-02 Thread Albert Cahalan
On Sat, Nov 1, 2008 at 11:01 AM, Benjamin M. Schwartz
[EMAIL PROTECTED] wrote:
 Albert Cahalan wrote:

 Memory reservations are a different beast entirely. Running
 out of memory becomes approximately impossible because
 the user is blocked from starting too many activities.

 This seems like a silly statement to me.  Almost every activity on the XO
 is capable of exceeding the hardware memory limit all on its own.

If so, then most are broken. Tux Paint doesn't suffer from
this defect.

The only semi-respectible excuse is that the activity accepts
arbitrary input. The web browser is the obvious example.
It's only semi-respectible because the activity can often have
an internal limit (enforced in the easy code paths) for this,
and because partial document rendering can prevent activities
like Read from having this problem.

If the activity can not be modified to limit itself, then it can't
legitimately specify a reservation. Sugar can make these
badly behaved activities run by themselves.

 Per-activity memory reservations are also per-activity limits, and they
 are only safe if those limits are set higher than the maximum amount of
 memory required by that activity, and that maximum value is simply far too
 large.

The difference is that activities never get killed under a
reservation system unless one is malicious or horribly buggy.

Under a limit system, activities will die. It's unacceptable.

 I like the idea of memory reservations, and they were part of the
 original design, but if we set them high enough to be safe, we would have
 a single-tasking (and maybe zero-tasking!) operating system.

No, although there are massive usability advantages for the
elimination of being able to run multiple things at once.
When a kid runs multiple activities, 100% of the time it was
unintentional. The kid got confused, probably because the
damn frame popped up under his mouse and stole a click.

 I should also be clear that I don't think Activities should receive the
 low-mem signal.  I think Sugar should catch the low-mem signal, so that it
 can attempt to do something smarter than the OOM killer because it knows
 much more about the system.  For example, it can choose to kill the
 activity instance that is using the most memory, or the
 least-recently-used activity instance, or even the instance that has most
 recently saved its state.

Destroying the user's work by killing an activity: FAIL

 This works especially well if we also use the knobs on the OOM killer.
 For example, the low-mem signal, after pausing all other processes, could
 cause Sugar to (1) select an activity to kill, (2) set that activity's
 oomadj parameter to make sure that it will be the first one killed if we
 hit OOM (3) ask that instance to save its state to the datastore, (4)
 close the activity instance, and (5) pop up a notification to the user
 about what just happened.

In a fit of rage, the kid throws his XO out the window. It just ate
his work for the eleventy-seventh time today.

Lots of things are wrong with that.

You may kill an activity that could have survived; there is
no good way to tell when OOM will be hit until you hit it.

Setting oomadj doesn't prevent the laptop from getting so
slow that the user decides to hard reboot.

There is no reasonable way to ask an activity to save state.
People don't write perfectly modeless code with atomic
operations on a database.

Since we can often determine an upper bound for the RAM usage
of an activity, we can trivially determine if a given set of activities
is capable of causing OOM. If we determine that starting a new
activity would place the XO in danger of OOM, then there is no
excuse for allowing that activity to start.

 The cgroups stuff could also help here, since the OOM killer by default
 thinks in terms of processes, but each Activity can be multiple processes.

That would cause activities to die. Work is lost. FAIL
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: idea for running out of RAM

2008-11-01 Thread Albert Cahalan
On Fri, Oct 31, 2008 at 9:24 AM, Benjamin M. Schwartz
[EMAIL PROTECTED] wrote:
 Albert Cahalan wrote:
 On Thu, Oct 30, 2008 at 10:05 AM, Erik Garrison [EMAIL PROTECTED] wrote:

 Could the oom-killer have a hook to enable this functionality to be
 invoked instead of simply killing the application?

 OOM is OOM. At that point, something needs to die.
 There is no escape from the cold hard truth that, once
 things have gone bad, it is too late for a good experience.

 Saving state will tend to cause OOM. When software
 does most anything, it needs memory. OOM is a particularly
 bad time to be trying to save state. Don't go there.

 I agree... which is precisely why we need the kernel to pause the
 offending allocation, and trigger a userspace program, while there are
 still (e.g.) 5 MB free.  Call it a lowmem trigger.  If the process of
 servicing the lowmem trigger hits OOM, then we're back to the standard
 behavior, but with an appropriately chosen buffer we should have enough
 room to close the memory-hogging activity instance without losing user data.

This tends to fail horribly. Early detection of low memory is
unreliable. Also, you have no idea if 5 MB is too much or
too little unless you get some guidance from activities.

Even if you succeed, you have failed. At best you have
forced an activity to die, which is really not what the user
would like. Most likely, you also get data loss. (because
the system thrashes and the user cuts power, or because
the activity doesn't implement an emergency save feature
that can reliably operate from any program state, etc.)

It's quite unlikely that the majority of activities will have
a reliable and useful response to a low-memory signal.
This is asking a lot from developers, even if you ignore
all the less-sugary activities.

 Note that this notion is entirely compatible with per-activity memory
 limits.  In fact, they seem to work quite well together.

memory limits != memory reservations

Memory limits create needless failure. Random user software
can not be expected to have a useful response to memory
allocation failures. The most you can hope for, and this is a
great big **hope**, is that sudden death is non-corrupting.

We have a problem with hitting the hardware memory limit.
Adding an extra limit just increases the problem. Instead of
continuing until the user gives up, a non-hardware memory
limit causes an early failure. One might as well just ship
less RAM if earlier failure is the goal!

Memory reservations are a different beast entirely. Running
out of memory becomes approximately impossible because
the user is blocked from starting too many activities.

Memory reservations mean this: Don't start something
that you can't finish. or Don't bite off more than you
can chew. or Don't make promises you can't keep.

Memory reservations are fairly easy for everybody. You can
implement them entirely in the program launcher. Activity
authors don't need to write any code; they merely need to
place a number in an activity.info file if they wish to participate.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: idea for running out of RAM

2008-10-31 Thread Albert Cahalan
On Thu, Oct 30, 2008 at 10:05 AM, Erik Garrison [EMAIL PROTECTED] wrote:

 Did you continue down this path (auto-saving application state to NAND
 when we run out of memory)?  How tenable is the idea of saving
 application state to NAND on our system?

 Could the oom-killer have a hook to enable this functionality to be
 invoked instead of simply killing the application?

OOM is OOM. At that point, something needs to die.
There is no escape from the cold hard truth that, once
things have gone bad, it is too late for a good experience.

Saving state will tend to cause OOM. When software
does most anything, it needs memory. OOM is a particularly
bad time to be trying to save state. Don't go there.

The focus needs to be on prevention.

I welcome something better than RAM reservations, but
I'm not expecting anything better. IMHO, implementing
the best known option would be a good move.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Sugar unusable as an e-book reader

2008-10-27 Thread Albert Cahalan
S Page writes:

 HTML in Browse integrates cleanly with the library/home page,
 can use advanced CSS for attractive layout, takes you from a
 link to a document without the download-Journal-Read steps,
 avoids PDF's fundamental broken-ness rendering a paper page
 on a screen, has JavaScript to add interactivity and features
 like annotations, etc. etc. It's the future. But PDF is
 certainly an important legacy format.

You need an update on PDF. Here you go:

PDF supports hyperlinks. You can browse from document to document.

PDF fully supports non-paged documents. Document formats that
can't support both paged and non-paged documents are the ones
that have fundamental brokenness.

PDF has JavaScript to add interactivity and features like
annotations, etc. etc. (not that I agree that JavaScript
belongs in a document format, but PDF supports it)
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: The XO laptop gets a Windows makeover

2008-10-26 Thread Albert Cahalan
[EMAIL PROTECTED] writes:

 It was a very poor experiment and the article had a number of items
 of misinformation.  The author of the article did not take advantage
 of the fact that she had 2 XOs .  She did not boot both in Sugar to
 observe the collaboration capabilities of Sugar and Activities.  If
 she had then Sugar would have won hands down.

Sugar isn't helped when people shout down any criticism.
Living in denial about the competition just leads to failure.
I'm far from a fan of Windows, but it gets many things right.

If you think booting both into Sugar would have helped Sugar,
then you obviously haven't seen the collaboration capabilities
of Windows. Booting both into Windows would allow file sharing.
Compared to what Sugar does, file sharing is very reliable.
It works with **all** programs, without any developer effort.
It's compatible between different software versions, different
types of software, and even different OSes. It even eliminates
the need to maintain a continuous network connection, which is
great for kids without wired networks or reliable electricity.

 Windows is pointless as an educational platform.  I have never seen
 what I would call an educational application on Windows.  I have seen
 rote training applications on Windows.  About all Windows is good for
 is in a school training the next generation of low skilled, low wage
 support personal for Microsoft with out of date knowledge.

I haven't seen decent educational software for any platform.
That includes Sugar and Mac OS. Probably this means that the
concept itself is defective. Real tools are superior.

I have seen Microsoft Excel used for science, engineering, and
statistics. Sugar has nothing comparable, despite at least two
usable free spreadsheets being available for Linux.

 Remember education and training are 2 different concepts.  Education
 gives you the ability to reach beyond your base knowledge and to
 continue to learn, explore and synthesize ideas and concepts. Rote
 training freezes you in time and makes you inflexible.

You just keep telling yourself that Windows is only for rote training
(false) and that rote training is useless (also false) while the
world mysteriously ignores you for some reason.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: The XO laptop gets a Windows makeover

2008-10-26 Thread Albert Cahalan
On Sun, Oct 26, 2008 at 7:57 PM, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:

 File sharing is not an active real time collaboration tool by any means.

Right. Active real-time collaboration is nice, and I wish my
own editor had it, but I think you're overvaluing it greatly.

 In sugar multiple children can work on the same write document, paint
 document, etc. at the same time and a copy is saved locally.

Last I heard, this is not true regarding the paint program.
It's not true regarding most programs in fact. Peer-to-peer
collaborative software is far from trivial to do decently.

 Means of file sharing can be setup fairly easily in Sugar if you want to
 move raw files around. Currently file sharing is performed through activity
 sharing.

Right, it could be fixed. There has been recent effort,
but Windows is still way ahead in this critical area.

 Just because MS Excel is used by some for science, engineering and
 statistics does not mean it is the correct tool for the job.  There are too
  many serious problems with MS Excel that have never been fixed and have
 caused serious problems with a number of scientific projects, etc., that
 relied on MS Excel.  I too can use a screw driver to hammer a nail into a
 wall but does not mean it is the correct tool.

It often is the correct tool, especially when you consider
things like ease-of-use and versatility. Turning your data
into pretty graphs in a report is easy with Excel. There is
even a built-in programming language, just in case you
should feel the urge to use one.

You can do your science while becoming familiar with a
typical business app. That's an excellent deal.

 I agree with you that there has been a dearth of decent educational software
 on all platforms.  There is a chance to start a fresh with a new platform
 that is not encumbered with a legacy of poor offerings in that area.

Many have gone down that path, generally resulting in
a fresh new legacy of poor offerings.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: journal is hard + sugar and the digital age

2008-10-09 Thread Albert Cahalan
Edward Cherlin writes:
 On Thu, Oct 9, 2008 at 7:15 AM, Carlos Nazareno object404 at gmail.com 
 wrote:

 3) Basically - The journal is really hard for people/ kids to
 use over a longer period of time. Kids and teachers can't find
 things that they did unless it was done within the last 30 minutes.

 Could you please elaborate on the difficulties that people have
 when using the journal?

 I've experienced the same problem. Items tend to clutter up in the
 journal over time, it's like viewing your entire web browsing history.
 Its current implementation simply leads to information overload with
 the accumulating number of entries.

 How about the Gmail method, in which you archive messages when
 you are done with them, but you can tag messages, set filters,
 and search easily?

tags: useless
filters: useful only for automated deletion of incoming spam
search: useful only for plain text

Fortunately, the vast majority of my email is text.
The journal is expected to handle lots of non-text data.

The email comparison is a good one. Just like an inbox, there
is an unrelenting torrent of spam that must be dealt with.
The main difference is non-text data, which makes the search
and filters ideas unworkable.

What you're lacking can be summed up like this: I put my data HERE,
where I can expect to find it later. There is no HERE in the
journal. Imagine storing 100% of your household goods in a giant
concrete mixer that rotates whenever you look away. You'd never
be able to find anything.

Now imagine that your neighbors like to empty their trash into
your concrete mixer. (spam problem) If you hadn't given up on
finding your stuff already, you will now! It's easier to buy new
stuff (start a fresh document) whenever you need it, and you might
want to keep your most beloved possessions in your desk at work
(copy them to a USB key). When the concrete mixer gets too full,
you toss in a lit match (kids in Uruguay rf -rf the datastore)
to keep the neighbors from complaining that they have no place to
empty their trash.

None of the recent suggestions, even if perfectly implemented,
would fix these problems. That's not even considering the issue
of compatibility with non-Sugar systems and user expectations.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Filesystem path ordering overrated.

2008-10-01 Thread Albert Cahalan
C. Scott Ananian writes:

 The response usually is that additional context is sufficient to
 disambiguate tag sets, you don't actually need ordering.  That is,
 it's okay if a/b is indistinguishable from b/a -- in practice one
 will really be c/a/b and the other will be b/a/d or whatever, and
 you can use the extra tag 'c' or 'd' to disambiguate.

Two big problems with this:

1. usually means on rare occasions we overwrite your files

2. Getting excess files is a problem. Imagine trying to use this
   (perhaps with a FUSE filesystem) with a Makefile $(wildcard *)
   or shell *. Extra files show up and get processed in some way.
   Maybe it's rm -rf foo/bar/* even.

There is also the matter of assuming that tags are easier to handle
than directories. The fact that some people struggle with directories
does not automatically imply that any alternative will be easier.
I tend to find tags more difficult in fact; they are disordered by
nature and that's a disorganized mess.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: idea for running out of RAM

2008-09-29 Thread Albert Cahalan
On Mon, Sep 29, 2008 at 6:04 PM, Jim Gettys [EMAIL PROTECTED] wrote:

 Note that more current Linux kernels, such as that in 8.2, are much
 better at being able to account for what process is using what memory.
 It's probably worth a little experimentation after 8.2 ships to see if
 the original concept is now viable.

I think a memory usage pie graph is beyond excellent.
I'm not so sure it should show current usage though.

It probably should show maximum expected usage,
based on previous behavior and/or RAM reservations.

The point of a pie display is to show the user how much
of the machine is occupied. If an activity is using 12 MB
now but will likely need 34 MB, then that extra 22 MB is
definitely not available for running other stuff.

Things work out nicely this way. The user can see why
the OS is refusing to let him start more activities. The
minimum activity size (for the icon) is no problem; it is
simply the minimum RAM reservation.

If the pie graph is exclusively based on RAM reservation,
then there isn't even any need to mess with /proc data.

An interesting extension of the idea would be to mark
activity icons (or their hover menus) with pie fragments.
This would let the user know in advance if an activity
would be unstartable, and would let the user know how
much he needs to free up to resolve that.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: [IAEP] Coloring books on the XO?

2008-09-26 Thread Albert Cahalan
C. Scott Ananian writes:
 On Tue, Jul 15, 2008 at 9:48 AM, Samuel Klein sj at laptop.org wrote:

 Coloring something certainly helps remember it.  And changing the
 colors of shapes/objects in a drawing or scene or skin is one of
 the simple pleasures in life.  A simple implementation of coloring
 would let you pick the colors of your own sugar skin and icon.

 I dreamed the other day about those pattern-coloring books that introduce
 you to unusual but beautiful tilings; when I was a kid we used to make
 copies of them or trace them on onionskin and color separately, later
 comparing the results for elegant patterns.

 Colors! might be a nice base for this activity.

 In general, we should think hard about how to best distribute 'example
 content', which you can open and remix on your XO.  From a UI
 perspective, I've suggested previously that these be presented as
 'friends' in the UI, who have files you can share.  The Red Cross
 might be a friend who has some coloring books available you can open
 in Colors! (or your choice of Paint programs).

Tux Paint has this functionality. I was thinking of ripping it out
to save a bit of space. I guess it's more valuable than I thought?

Press the button the create a new image. You'll see a set of images
to start with. The ones at the top are solid color, but scroll down
and you'll find the starter images.

Starter images have both foreground and background. The foreground
is always shown on top, and thus obviously needs an alpha channel.
For a traditional coloring book page, the foreground is all black
and has line art in the alpha channel. The background would be all
white in that case. Full color is possible. You could have a forest,
with some of the trees in the foreground. Erasing restores background.
Starter image properties survive save/quit/restart/load.

The full set of tools is available, including stuff like flipping
and mirroring the image. The stamp and flood-fill tools are most
useful, though cheating I suppose. (BTW, flood-fill is fast)

We have:

jigsaw puzzles
grids
chess board
chicken
airplane
ocean reef
rocket
shipwreck
diploma-style frame
skyline
farmer
maps (US, Japan, each continent, world, canada)
castle
nagasaki
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


idea for running out of RAM

2008-09-23 Thread Albert Cahalan
For the zillionth time, my kids brought my XO to a halt. They started
up two copies of Tux Paint and two copies of Colors! (BTW, boy do I
hate names with built-in sentence-ending punctuation) The end result
is that the activities die (unacceptable), usually via power button.

There are a number of different problems here. It's a UI defect that
the kids lose track of what is running and feel a need to start things
that are already running. Kids don't think I **switched** back to the
home screen. Instead, they seem to think the activity suddenly died.
It's another UI defect that they are getting switched away from the
activity at all; I'm quite sure there is no intent to go to the home
screen. It just happens randomly, being not very kid-friendly.

Intentional or (more likely) not, the kids get too many things running.
In theory the kernel will kill things as a last resort, which is awful,
but it doesn't happen because the user won't wait (hours? days?) for it.

Fully solving the problem is impossible, but we can do a lot better.
First let's rule some things out:

* the slow hang we have, causing loss of work via power button
* OOM, causing loss of work via actively killing stuff
* rlimit, causing loss of work via allocation failure
* activity grabs RAM up front, leading to one of the above

The commonality here is that, once started, an activity must never
be bothered with a memory shortage.

We can cover nearly all cases with RAM reservations. Worrying about
the other cases is not productive. Activities can lie about how much
RAM they will use. The OS itself may unexpectedly consume RAM. Again,
a perfect 100% solution is impossible but we can do a decent job.

RAM reservations go in activity.info files. They let sugar know
when to stop letting the user start new activities.

Suppose we have 256 MB, the OS consumes 176 MB, and 80 MB is left.
Activity X declares a need for 60 MB, activity Y declares a need
for 20 MB, and activity Z declares a need for 30 MB. Activities
P and Q do not declare anything. The user may thus run any of:

X
X,Y
Y,Y,Y,Y
Y,Y,Y
Y,Y
Y
Z
Z,Z
Z,Z,Y
Z,Y,Y
Z,Y
P
Q
P,...,P,Q,...,Q (unlimited)   -- optional

If we allow that last option, then activities P and Q are unprotected
in every way. Any number of them can run at the same time. Crashing is
far more likely, which is bad, but existing behavior is preserved.

Note that activities which declare a RAM requirement will never run at
the same time as activities which do not. If this is allowed, then any
activity that fails to declare a RAM requirement will endanger data in
the well-behaved activities. It's an option, but a rather awful one.

To be clear: after starting 4 copies of activity Y, sugar must refuse
to start any more. It's simply not allowed, since doing so is likely
to lead to data loss.

Not every activity can declare a RAM requirement. I happen to know that
Tux Paint is fairly well behaved; it does not grow without bound.
I strongly doubt that Browse is well-behaved or ever could be.

Determining the RAM requirement for an activity goes something like
the following:

awk '/Dirty/{x+=$2} END{print x}'  /proc/12345/smaps

(after exercising all functionality)

We can refine that, remembering that it will never be perfect.
Adding a bit more (5 megabytes?) to avoid the slows is important.

If an activity has lied, there isn't much that can be done. Oh well.
If the lie is caught before the system gets horribly slow, the OS
can simply increase the reservation for that activity. (either just
for that session, or persistently) The OS can log the problem, allowing
the activity developer to be flamed. Killing the lying activity is not
a good option, but it could be done, especially if some other activity
is already running. Once the slows hit, it's back to the power button.

BTW, the alternative is far more harsh yet easier for kids to deal with.
We just ditch the whole idea of letting activities run concurrently. :-)
Seriously, consider it. We're really short on RAM, and activity switching
is not at all easy for kids.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: G1G1v2 Activities

2008-09-20 Thread Albert Cahalan
Here is a list, most important first:

Journal required
Browse  needed for tech support
XoIRC   needed for tech support
Terminalneeded for tech support
Record  kids love taking pictures
DOOMkids love shooting monsters
SimCity kids like destroying cities
Ruler   useful, simple, tiny
Clock   useful, simple
Calculate   useful, simple

VNC Launcher is probably good for tech support, but I haven't verified
that it works. Chat, Write, Read, and Help may all be nice to have.

I'd love to recommend Measure, xo-get (critical IMHO) and some TamTam suff,
but I can't. They just don't work well enough yet.

Though the xo-get activity appears to be broken, the command line xo-get
tool is the easiest way to install activities. Be sure to include it.

Distance (Acoustic Measure) and StarChart almost make the cut.
Distance requires a second XO though, and StarChart suffers from
being for a very specific purpose that isn't tech support.

(for those wondering: yes, I did mean to leave out Pippy, eToys,
and TurtleArt -- all of which are difficult to use and not needed
for tech support)
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: [sugar] Ideas for Journal: How epiphany browser manages bookmarks just with tags

2008-09-20 Thread Albert Cahalan
On Sat, Sep 20, 2008 at 10:01 AM, C. Scott Ananian [EMAIL PROTECTED] wrote:
 On Sat, Sep 20, 2008 at 1:41 AM, Albert Cahalan [EMAIL PROTECTED] wrote:

 The case of b/a being distinct from a/b is necessary. You may call
 it a necessary evil, but in any case is is necessary.

 Surprisingly, it's not:
 http://wiki.laptop.org/go/Experiments_with_unordered_paths

 I still think it's worth supporting as an edge case, but from my
 actual experiments, it seems that path ordering is almost never
 actually necessary (!).

Suppose I hand you a 16 GB USB stick or a USB DVD drive.
Suppose it has a million files in 54321 directories, with a
typical path depth of 5 or 6 and a max path depth of 11.
How are you expecting to handle that? (CPU, RAM, IO, etc.)

Suppose the journal grows the ability to deal with CIFS
or NFSv4, as it ultimately must. You encounter a server
with home directories for all students in the school district.
Your fellow students do likewise. You're using wireless.

 For the journal to be truly usable, it needs to support pretty much
 all that we ask of a filesystem. You'll know you're doing OK when
 you can build joyride out of the journal. (git works, gcc works, etc.)

 This is a good test case.  I'll confirm it, but I believe that this
 should actually work with unordered paths.  The trickiness comes wrt
 to security in a multiuser system; Michael has been thinking hard
 about that.  (I prefer just to punt it for the moment.)

I'll guess you'll use FUSE? Don't forget readdir().
That could be /bin/ls or $(wildcard *.h) or whatever.

 Give priority to tags (and anti-tags) which split the set of
 files most evenly. This greatly reduces search time; it is
 equivalent to balancing a binary tree.

 It turns out that only about 3 tags are needed to find any directory
 among the 900,000 files in my home directory (I'm working on getting
 better statistics, sorry).  So the opposite criterion might be more
 important: give priority to tags which 'most narrow' the search --
 that is, they match the *fewest* things!

No, because displaying tags is not free. They take up screen
space. That imposes a hard limit on the number when you run
out of space, and a squishy limit from mental burden.

If you show enough tags so that only about 3 will do the job,
you'll be showing a truly huge number of tags. I think it's far
more than dozens, possibly even thousands.

 Once you've entered two
 search terms, the exact thing you are looking for ought to be in that
 list; you don't want to be distracted by terms held in common by lots
 of files which don't appreciably narrow your search.

If you could see the narrow search term right in front of you,
actually being able to find it, that would work nicely. There
are just too many narrow search terms though. You'd need
a way to search your search... uh oh!

It could be reasonable to reserve some (half?) of the precious
screen space for recent/popular search terms though.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: [sugar] Ideas for Journal: How epiphany browser manages bookmarks just with tags

2008-09-19 Thread Albert Cahalan
Eben Eliason writes:
 On Fri, Sep 19, 2008 at 3:59 PM, Eduardo H. Silva hoboprimate at gmail.com 
 wrote:
 2008/9/19 C. Scott Ananian cscott at laptop.org:

 Eben, Eduardo, and I have been chatting about this some over IRC.
 What I find most interesting here is how *filesystem paths* (well,
 URL paths in this particular case) are integrated with tags.

It's more than interesting. Solving the path problem is critical.
Paths allow compatibility with the world, including the laptop itself.
They are also a decent way to organize things, far from perfect yet
Superior to the overflowing inbox.

BTW, I'm delighted to see some serious consideration of the issue.

 If you accept that tags can sometimes be ordered, so that a/b is
 different than b/a (although both will show up on searches for 'a'
 and 'b'), then this starts looking more and more like a way to view
 filesystems as well, for those old enough to want to do that.
...
 So I agree that some kind of containerization is needed, but not in
 the form of a/b being different than b/a, but by using virtual
 folders or saved searches which would effectively act as virtual
 folders, with specific tags, search terms, object types, even a
 period of time if you wished.

The case of b/a being distinct from a/b is necessary. You may call
it a necessary evil, but in any case is is necessary.

The question then becomes: Is the alternate method good, and is it
good enough to implement despite any user confusion and performance
issues that may exist? Perhaps there should be a mode switch, with
regular filesystems (USB stick, SD card, /, $HOME, /tmp) being
visible only when in ordered mode.

 The real question (I didn't overlook this!) regarding the concept of
 virtual folders (or, more specifically, saved searches) is whether
 or not they are dynamic.  That is, does the saved search represent an
 expression or a value?  My above tag idea is only valid, of course,
 when they are represented in value form.  For more power (but more
 complexity) one would store the search terms, filters, etc. and
 re-apply them on the fly to a growing list.

 I'm not sure which of these is more desired.  They both have merits.

If both work, then a mode switch could be made available.

Note that work means scalability for both CPU time and RAM.
On the existing hardware, you need to handle 100 thousand files.
On something like a regular PC you'll need to handle a million.
That means O(log) scaling at worst, for both CPU time and RAM.

 If you have files in ~/Journal/Music/Bach/Disc1 and
 ~/Journal/Music/Beethoven/Disc1, you can search for 'Bach', 'Music
 Bach' as well as 'Bach/Disc1' or 'Music/Bach/Disc1' if you want to be
 specific.  When you insert a USB key with files in a directory called
 'Music/Mozart', they appear in the journal as if they were tagged
 'Music/Mozart' and you can search for 'Mozart' or 'Music' to find
 them.  When I copy them to my XO, the tags come with, and I have
 operations to retag groups of files that are the result of a search
 (which can look very much like groups of files which are in a
 specific directory).

 Yep, I think this is a good idea to move files from a hierarchical
 system to a non hierarchical system (the Journal) and still reuse the
 information contained in that first organizational system.

 Absolutely. This is a critical element which we need to make work when
 we flesh out support for external devices in the next release.  This
 idea is the only solace I have been able to give to the many many
 people frustrated with the previous behavior of the devices in the
 Journal.

Round trip ability (USB - XO - USB) is important. Losing all the
directory info is no good.

For the journal to be truly usable, it needs to support pretty much
all that we ask of a filesystem. You'll know you're doing OK when
you can build joyride out of the journal. (git works, gcc works, etc.)

 At the end of my pdf, I showed how epiphany creates a seemingly
 hierarchical bookmark menu. But it is only seemingly. Remember, there
 where 3 bookmarks tagged education and free software. Because
 these tags where so popular, they became top-level menus, and inside
 each of these menus, the same 3 bookmarks lived, in their own section
 because they shared an extra tag.

 This is a really powerful structure, and I think it's just the thing
 we need to make navigating the Journal more pleasurable (for those
 that really don't like the idea of searching).  Getting the thresholds
 right for the number of items required to use a tag before it becomes
 top level will be a challenge (it should probably be based on a ratio
 to total unique tags).

Give priority to tags (and anti-tags) which split the set of
files most evenly. This greatly reduces search time; it is
equivalent to balancing a binary tree.

 Thanks for sharing this.  I think the ideas we're talking about should
 definitely be added to the list of future goals so we can work them
 in.  It would be a big improvement.

That's 

Re: CIFS will be strategic in some settings, but not included in kernel

2008-08-25 Thread Albert Cahalan
Martin Langhoff writes:

 In that sense, it is very simple - as a programmer, if I am going to
 spend significant time working on a feature like this I want it to

 1 - work for the deployments - this is the most important thing!
 2 - work for G1G1 users too - they are the donors and enthusiasts!
 3 - work for the developers - otherwise it won't get attention and bugfixes
 4 - work in as many places as possible
 5 - not cause security trouble
 6 - enable sharing across the internet if possible

 CIFS is only good on #2, and fails at all the other ones. It is a good
 solution for a very narrow set of scenarios.

Nope. CIFS meets them all. WebDAV fails at #2, #3, #4, #5.
CIFS sure does feel yucky, but it works pretty well. CIFS is
even done in userspace (GNOME's nautilus seems to have it).

A more Linux-oriented alternative would be NFSv4.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: The tedium of erasing journal entries

2008-08-03 Thread Albert Cahalan
Aaron Konstam writes:

 Someone in a recent message suggested that people should learn to
 routinely erase Journal entries to prevent the NAND from filling up.

 Unless I have missed something that is a very tedious task to lay on
 someone using the current GUI interface for erasing journal entries.
 Journal entries are added at a steady rate but their removal is a
 tedious one at a time process. I can't imagine child taking the
 time to keep these entries erased routinely. Another erasure method
 is needed.

I gave up. My journal has 1150 entries, 99% spam.

I don't even want to look in the journal. Not ever! It's unusable.
It's worse than the worst email inbox nightmare. Nothing has a useful
name, the scroll bar doesn't move with my mouse, clicking to mark an
entry takes many seconds to work (leading me to click again), and
the purely iconic interface is totally incomprehensible. I'd even
prefer the dreadful interface of Macintosh System 1.

An improvement would be to delete the datastore at boot. No joke.
The user's files are effectively missing already, because they are
lost among the spam. Stuff saved to the journal is unrecoverable
in any practical way.

In other words: users CAN NOT SAVE THEIR WORK on the XO. Sure, it
may technically get saved, but there is no hope for finding it back.

Clearly, nobody is dogfooding.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: The tedium of erasing journal entries

2008-08-03 Thread Albert Cahalan
On Sun, Aug 3, 2008 at 7:55 PM, Gary C Martin [EMAIL PROTECTED] wrote:
 On 3 Aug 2008, at 23:03, Albert Cahalan wrote:

 This is rather unfair. I take it you've just filled up all available space
 and jffs2 is now thrashing (as would happen on almost any file system)?

df -m . reports 1024 blocks, 854 used, 171 available, 84% used.
du -ms . in the store directory reports 195 megabytes.

Even if it is understandable to be unbearably slow at this
level of use, which I doubt, something needs to be done.

 I find my way around my 900+ entries just fine. I do agree that a high
 percentage of my entries seem to be cruft, but there is a proposed UI
 feature that I believe will greatly reduce accidently creating new journal
 entries when what was really intended was a resumption of an earlier entry.
 The much needed extension of the new Home view to default to, and display,
 recent entries for said activity.

http://wiki.laptop.org/go/Image:Activity_management-07.jpeg

Who wants to resume? Can't a person just play with
an activity for a while, without saving every embarrasing
failure? Why am I forced to keep my junk?

 Clearly, nobody is dogfooding.

 I would like to see more dogfooding, perhaps once 8.2.0 is out the door; as
 mentioned before, some occasional sugarised only dev meet-ups would be a
 nice start (Chat, shared Write for group notes, Xo IRC as a fall back when
 it all blows up, and any thing else that's useful).

That'd be a great start.

I happen to think that Sugar's python files should be
kept in the journal. Create a journal-aware git tool.
Do **everything** in sugar. If even the developers can't
manage this, then something is severely wrong.

That goes for UI designers as well. Ditch the Adobe tools
unless Adobe ports them to Sugar. MacOS is cheating.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: [sugar] Proposal: Activity developers mailing list

2008-08-02 Thread Albert Cahalan
Morgan Collett writes:

 We didn't get to discuss this activity developers' mailing list
 at the Sugar meetings. However I've had no negative feedback.
 If anyone is opposed to this list, please speak up quickly and
 loudly. Otherwise I will get it created in the next week,
 publicize it and invite all known activity developers whose email
 addresses I can track down to subscribe.

Well I don't want to be all that negative because it isn't my
server and I'm not joining the list, so I have little reason to
care. If you're looking for reasons why the list isn't useful
though, sure:

This will eventually, if not immediately, be a dead list.

Few people want to work on all activities. Activities often
do not share much in common. For developer D1 who likes to
hack on activity A1, emails about activity A2 are noise.

Generally, the expertise will be elsewhere. If I need to discuss
programming the camera, where does it make sense for me to go?
Certainly an activity mailing list is not the place.

If the list were moderated, to be used ONLY for announcements
of things that break the API/ABI, then there could be some value.
In that case, you'd need to split up Python and non-Python.
Like this:

[EMAIL PROTECTED]
[EMAIL PROTECTED]

There could also be a list to announce new activities.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Terminals

2008-08-02 Thread Albert Cahalan
Look, there is no reason to care about hashes. What is the fear
here, that the jffs2 filesystem will fail? We have pathnames.

Permissions are granted by the user. The only exception is when
the OS is initially installed, or when the whole OS is upgraded.

Permissions are tied to an inode. Since the kernel enforces that
directories may not have hard links, one may also tie permissions
to a directory.

It'd be nice to have a way for activities to specify reasons to
grant various permissions. This isn't a requirement. It'd be nice
to to have a way for activities to specify permissions that are
of no use (and thus should not be offered in the UI). This is not
a requirement.

Signatures and hashes are complexity. Complexity tends to be the
enemy of security. The answer is really simple: every activity,
no matter where it comes from (claiming to be an upgrade or not),
gets sandboxed by default. Users grant permissions as desired.

Bitfrost sure is compatible with P_ROOT. Of course any such
permission would implicitly grant all others; such is life.
There certainly should be a way to specify that setuid is to
be respected, that su should be allowed, that UID should be 0,
that the user's real home directory should be used, or that
various capability bits should be enabled.

The more dangerous items might best be handled via commands
to be run at the Linux console, ensuring that nobody can hit
them with random mouse clicking.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: video bleeds through somewhat between sessions

2008-08-01 Thread Albert Cahalan
Jordan Crouse writes:

 Video is muxed to the visible screen through the use of a color key -
 given a rectangle of some size, the hardware compares all of the pixels
 in that rectangle against a set color - if they match, then a pixel of
 the video frame is shown, otherwise not.

That should have gone out of style with those ISA VGA cards that
had a ribbon connector on top to accept video from a tuner card.
The hack almost made sense with a palette.

If a 32-bit framebuffer were used, would the use of the top 8 bits
fix this problem? (valid colors are 0 to 0xff, so use 0x100)

 The color is specified by the video application - most applications
 use very saturated colors similar to those used in green or blue
 screens. My favorite is hot pink (0xFF00FF).  IIRC, mplayer uses an
 off-shade color of grey, so it is easier to run into the possibility
 that other applications will match the color key, especially with
 automatic shading such as anti-aliasing.

Better would be 0xff00fe or 0xfe00ff, appropriately adjusted to
deal with 16-bit color. (0xf81e or 0xf01f I think) Decrement either
the red value or blue value to avoid being perfect magenta.

 Nothing to worry about - just a fun little side effect of video
 acceleration.

Well, it does detract from the overall appearance.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Terminals

2008-07-31 Thread Albert Cahalan
Michael Stone writes:

 One of our present security difficulties is that the Terminal activity
 is not isolated. It is de-isolated so that it can serve the dual role of
 root terminal and 'general exploration' terminal. Perhaps reviving the
 Quake Terminal for the root-terminal role and isolating the Terminal
 activity proper would be a nice way to solve half of our security issue?

No.

First of all, that would force usage of the root account to get
to the olpc account. There is little reason to want a random
user, but plenty of reason to want both olpc and root.

Second of all, the ability to de-isolate an arbitrary activity
is important. Isolation needs to be under the user's control.
Except to prevent a user from locking himself out by isolating
the de-isolation tool, no activity should be specially known
to Bitfrost or Sugar. Isolation is righfully a user choice.
It's OK to make isolation easier though, to avoid accidents.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: TuxPaint woes

2008-07-29 Thread Albert Cahalan
Michael Stone writes:

 On the other hand, it would be rather trivial for activities which
 cared to check their dependencies in a adhoc fashion (by running
 rpm themselves if they wish) and by reporting errors if necessary
 dependencies are unsatisfied.

This is far from trivial. Sure, I could do it, assuming the RPM
database not made unavailable via security restrictions.

First I need a wrapper, or I need to load my libraries with dlopen.
Otherwise, my program simply won't start. Upon discovering the
failure, I need to report it. This seems to require graphics, but
it may well be the graphics library that is missing. I suppose it
is OK to assume Xlib is installed (so, no need to speak X11) and
of course the C library, but... ouch.

There is a better way. Every *.xo could have something in it to
say what it needed. For example, a *.spec file. This file could
be read by some other activity. Call it PackageManager. :-)
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: TuxPaint woes

2008-07-29 Thread Albert Cahalan
Mikus Grinbergs writes:

 There are people like me who like TuxPaint better than Oficina.
 However, to run TuxPaint, users of current Joyride need to
 re-install SDL_mixer and libmikmod.

I hope you've filed a bug to request that those libraries
be put back.

I could use libpaper as well; the alternatives are that I drop
printing support or dig my old printing code out of Tux Paint's
CVS history. You may guess which is more likely.

 seems to start slower than it did

Without any profiling data, I'm going to point the finger at all
the Python-specific hacks. In particular, keeping an interpreter
running to fork off children is an evil memory-sucking hack.

 I realize there is a serious shortage of resources.  But should it
 be up to the Activity developers (or in this case, those who first
 fitted the software to Sugar) to keep supporting their submission
 as the Sugar/operating_system platform keeps evolving ?

FYI, I'm one of the core Tux Paint developers. (top 5 at least)
Maybe one person knows Tux Paint better than me, and he's quite
busy too. (new baby, California-style commute, etc.) He just got
an OLPC, and he reports that Tux Paint runs without any problems.

Changing the platform breaks stuff. If that means that lots of kids
(directly, or via school choice) will refuse to upgrade, oh well.
You're not supposed to break stuff.

BTW, there really shouldn't even need to be a *.xo for Tux Paint
or any other program. There are some moderately standard ways to
handle the problem of installing a package on a Linux system and
creating menu entries. Had these not been gleefully abandoned,
all sorts of things would just work.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: TuxPaint woes

2008-07-29 Thread Albert Cahalan
Daniel Drake writes:

 I'll look into why SDL_mixer went away, and what it is used for...

It's for audio. Reasons for use include:

* Nicely compatible with other SDL stuff
* Cross-platform (BeOS, MacOS X, Win95, Vista...)
* Easy support for stereo positioning
* Handles *.ogg files
* Good enough real-time / async features

There is no reasonable alternative.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Tuxpaint activity is bloated

2008-07-23 Thread Albert Cahalan
FYI, the Tux Paint port is mine. I have CVS commit rights to
the main Tux Paint code base. Probably 5% to 10% of the code
is mine.

Mitch Bradley writes:

 The filesystem layout for the tuxpaint activity has a lot of
 boilerplate that contributes to it taking up a lot of space on NAND.
 In some NAND images from Uruguay that I analyzed today, over 5000
 directory entries - nearly 50% of the total number of dirents in /home -
 were from tuxpaint.

This is unsurprising. Aside from minor packaging troubles,
the issue is that Tux Paint is simply not a bare-bones paint
program. If people want bare-bones, they use Paint instead.

In terms of total space, a large and growing problem is i18n
of *.ogg files that provide descriptions of the clip art.
Tux Paint supports 4 or 5 dozen languages, of which a half
dozen have audio descriptions.

 For example, there are 200+ CVS subdirectories, each containing Root,
 Repository, and Entries files.  Many of the CVS directories are in
 localized subdirectories, which also contain many copies of dirents or
 localized versions of files likes COPYING.txt, AUTHORS.txt, etc.

I've been doing massive Makefile changes to deal with this properly.
The *.xo is far from the only thing affected; I have these files in
my /usr/share/tuxpaint directory. The only reason you don't see them
on a regular Linux distribution is that the package maintainers
delete them after the build.

 One subdirectory hierarchy is named org.tuxpaint.sugar-is-lame\.
 That is unprofessional.

Hey, more evidence! Tux Paint does not ship with any such directory,
and does not ask for such a directory to be created. Tux Paint has
no use for such a directory. Please get sugar to stop being lame.

The sugar-is-lame string comes from a value that activities are
required to provide, even when the value is of no use. Activity
authors are being forced to provide a random string that is of no
use to the activity, so of course I provided one. The fact that I
was **forced** to provide this string is of course evidence of the
fact that sugar is in fact lame.

Not that any more evidence should be needed of course, but I hear
that the - character has now been made invalid. The allowed set
of characters was undocumented, has recently changed (breaking an
existing activity) without notice, and is still undocumented AFAIK.
I think we can conclude that yes, sugar is indeed lame.

IMHO, unprofessional would be text that includes the appropriate
level of profanity. (which, in this case, goes to 11)

 The activity itself appears to somewhat popular, at least based on its
 presence on all of the Uruguay NAND images that I analyzed.  If it is
 indeed popular, perhaps it would be worthwhile to optimize it for XO to
 reduce the footprint.  In addition to removing boilerplate that the
 children won't look at, one possible optimization would be to collapse
 the many files in TuxPaint.activity/share/tuxpaint/stamps/ into a few
 archive files, thus reducing the filesystem overhead.

Archives sound like a bad idea. Fast random access to those images
is kind of important.

Just what kind of overhead are we talking about here? If jffs2 is
much worse than an archive, then clearly jffs2 fixes/replacements
should be a priority. After all, jffs2 affects all activities.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Parallel desktops

2008-06-27 Thread Albert Cahalan
Benjamin M. Schwartz writes:

 There have been periodic suggestions, including some by potential OLPC
 buyers, that they would be more interested if the project offered a GUI
 that more closely resembled the environments to which they are accustomed.
 ~ I strongly disagree with these people, feeling instead that Glucose is
 already a highly effective environment with a very bright future.

A middle ground could be less dreadful than either extreme.

Good: secure activity isolation, full-screen for most things,
usable window management for other things, curved corners, 3D look

Bad: icons on the desktop, bag-of-spam file management

 However, it seems that some deployments, seeing Glucose as unfamiliar,
 might instead choose Windows, which I hate to death [1].

Of course. It has long saddened me that Linux has been given a
severe disadvantage on the XO. Windows looks pretty good. :-(

Chris Ball writes:

 There's another use case, unmentioned, which is the G1G1 community.
 Some of these donors expect a laptop that follows their expectations
 about computers:  robust support for wireless access points, printing,
 office automation programs, and loading files from a filesystem without
 finding a clever way to inject them into our journal first.

Kids in Peru deserve that too.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: etoys now available in Debian's non-free repository

2008-06-27 Thread Albert Cahalan
On Thu, Jun 26, 2008 at 9:47 PM, Edward Cherlin [EMAIL PROTECTED] wrote:
 On Tue, Jun 24, 2008 at 11:04 AM, Albert Cahalan [EMAIL PROTECTED] wrote:

 The Smalltalk community is puzzled that anybody would
 prefer to work on Smalltalk in something other than Smalltalk.

Unless you want to rewrite emacs in Smalltalk... :-)

 No point. Anybody who wants to can extract the source code from an
 Etoys image and create the objects you desire. That is the point. You,
 and apparently some of the Debian people, are complaining about two
 things, as far as I can tell.

Great. Do that, and THROW AWAY the Etoys image.
I gather that you can't do this though, which is the problem.

 One is that the Etoys people haven't given you a directory tree of
 text files including appropriate makefiles that would recreate the
 entire Etoys image, bit-identical to what they ship. I'm happy to
 discuss that, since creating those files would apparently let Etoys go
 into the Free repository.

Yes.

 The other complaint is that all of the tools for working on
 Smalltalk source are written in Smalltalk, except for the
 bits to be compiled in C.

Nope.

You'd be all set if you had Smalltalk source code that you
could feed into any random Smalltalk system to create
your build tools.

While I happen to like C, and it's a very popular way to
achieve the required ability to bootstrap, it isn't needed.
You even get a certain amount of respect from writing
the whole thing in Smalltalk. Use GNU Smalltalk.

You might even scrape by with Squeak building itself.
(not involving copy the currently running image)
If you can create a new image from loose UTF-8 text
files and standard media files, without any data being
swiped from the currently running image, then you've
met the requirement.

 http://users.ipa.net/~dwighth/squeak/oopsla_squeak.html

That's in interesting read. It does admit to depending
on a system image from decades ago:

Alter the ST-80 SystemTracer to write an image in the new format.
no longer needing to port images forward from Apple Smalltalk

 What is the source management system for the Etoys and Squeak VMs? Is
 _everything_ done in Smalltalk and kept in the image file? Wait, I see
 it. http://www.squeakvm.org/cgi-bin/viewcvs.cgi/. Albert?

That appears to be the OS interface layer. No problem there.
Feel free to write that in Smalltalk instead though.

 As far as I am concerned, you should write any such tools in
 Smalltalk/Squeak, and offer that source code to anybody who demands a
 translation to another language. No, I'm wrong, not a problem. We can
 translate it to C ourselves. There you go.

I don't see any reason to demand a specific other language,
or even any other language at all. I can see a reason to want
portable code (example: runs on Squeak and GNU Smalltalk),
to eliminate paranoia about a malicious compiler, but this isn't
critical. The really important thing is an ability to generate
everything from source. That means you can create a new
image without grabbing bits from an existing image.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: etoys now available in Debian's non-free repository

2008-06-26 Thread Albert Cahalan
On Wed, Jun 25, 2008 at 11:13 PM, K. K. Subramaniam [EMAIL PROTECTED] wrote:
 On Wednesday 25 Jun 2008 12:08:44 am Albert Cahalan wrote:

  *All the source code* for *every* piece of byte code in the
  image is available, and not only that, we even *ship* it

 No. This is not true. You ship a binary blob. That doesn't
 count, even if so-called source code is viewable from
 within the blob.
 Albert,

 You are confusing binary as in secret encoding with binary as
 in encoding based on freely available specifications. A UTF-8 encoded file
 containing Mandarin or Hindi text would be unreadable on an ASCII text
 editor, but that doesn't make it a closed binary blob.

Sure, but I actually can get an independent implementation
of an editor for such data -- it doesn't depend on itself.

A good situation would be that you can build the image from
plain text just like GNU Smalltalk does. That could happen on
the laptop when the activity starts, or when the activity is created.

The next best thing would be to supply a custom editor
which is **external** to the image, along with any other
tools needed to edit and create the image. It should be
possible to start from some standard build tools, feeding
in a mix of source code and standard media files, to end
up with a set of tools. Note that you could write such
tools in Smalltalk if you used GNU Smalltalk, which is
able to be bootstrapped. This solution essentially
treats the image like a multimedia file instead of code.
(a dump tool is all you have AFAIK; there is no editor
that can reliably edit a VM image)

Best would be both. Currently, you have neither.

 Squeak image is not a blob in the first sense. One can write a program to
 decode any image file and recover any data stored in it. The problem with the
 blob is not that it is closed, but it is monolithic and limited in capacity.
 The limit is not that restrictive for personal computing purposes, but it
 will hurt when one has to deal with audio/video clips, 3-D simulations or
 large databases. There is no checksum to verify integrity. Objects are stored
 higgedly piggedly making even partial recovery difficult. However, these are
 programming limits, not that of policy.

It's also a problem for change tracking, shared development,
use of one's favorite editor, code sharing with GNU Smalltalk, etc.

This idea of applying patch collections is disturbing. It reminds
me of the terrible mess that Minix was back in 1991, when the
license permitted people to share patches but not code with
the patches applied. Here you have a technical limit instead
of a legal one, but I expect that the result is not much different.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: etoys now available in Debian's non-free repository

2008-06-26 Thread Albert Cahalan
On Thu, Jun 26, 2008 at 3:02 AM, Yoshiki Ohshima [EMAIL PROTECTED] wrote:

  Before drifting to a new topic, let me make sure one thing; did you
 get convinced that FSF's definition of software freedom doesn't
 contradict with a binary image file with right tools to fully
 explore/understand/modify it?

I don't subscribe to the notion that the FSF defines open source.
Heck, I don't care for them and they don't care for open source.

 A good situation would be that you can build the image from
 plain text just like GNU Smalltalk does. That could happen on
 the laptop when the activity starts, or when the activity is created.

 The next best thing would be to supply a custom editor
 which is **external** to the image, along with any other
 tools needed to edit and create the image. It should be
 possible to start from some standard build tools, feeding
 in a mix of source code and standard media files, to end
 up with a set of tools. Note that you could write such
 tools in Smalltalk if you used GNU Smalltalk, which is
 able to be bootstrapped.

  You never explained why these things are good.

Right. I'm also not explaining why software freedom is
good, why maintainability is good, why interoperability
is good, etc. Values are values.

 This idea of applying patch collections is disturbing. It reminds
 me of the terrible mess that Minix was back in 1991, when the
 license permitted people to share patches but not code with
 the patches applied. Here you have a technical limit instead
 of a legal one, but I expect that the result is not much different.

  No, no. You don't get it.  Applying patch happens when building a
 release image and the resulting image gets into a package to be
 distributed.  It is just the same as compiling an executable binary
 from source code and distribute the binary.

I got that. The fundamental problem is the patch collection.
There is a problem even if you can distribute the result.
Patches need to be applied. If you do that, and distribute
a blob, then we're back to the blob problem. If you don't do
that, then we have the Minix problem.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: SuperUser permission for the Driver??

2008-06-26 Thread Albert Cahalan
Benjamin M. Schwartz writes:

 There is a planned design to allow the user to grant extra privileges
 to different Activities, but those privileges will probably never
 extend to loading arbitrary kernel modules.

VMWare-1.xo

It's the only way to get usable performance on a system that
doesn't have hardware virtualization support.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: etoys now available in Debian's non-free repository

2008-06-26 Thread Albert Cahalan
On Thu, Jun 26, 2008 at 1:38 PM, Bert Freudenberg [EMAIL PROTECTED] wrote:
 Am 26.06.2008 um 10:53 schrieb Albert Cahalan:

 This idea of applying patch collections is disturbing. It reminds
 me of the terrible mess that Minix was back in 1991, when the
 license permitted people to share patches but not code with
 the patches applied. Here you have a technical limit instead
 of a legal one, but I expect that the result is not much different.

 I got that. The fundamental problem is the patch collection.
 There is a problem even if you can distribute the result.
 Patches need to be applied. If you do that, and distribute
 a blob, then we're back to the blob problem. If you don't do
 that, then we have the Minix problem.

 I don't actually disagree with that. Smalltalk is an excellent personal
 computing environment (well, you would expect that from the guys who largely
 invented personal computing). It does not fare nearly as well for
 distributed, collaborative development (although the Squeak community has
 developed work-arounds, like Monticello, a nice distributed SCM).

 But: Why should these shortcomings in development style be a reason to not
 include it in a Linux distribution? It's not like if every other app is
 well-coded or well-maintained.

The very foundation of the Linux development community
(which Squeak developers are asking to be accepted by)
includes an expectation that software can be handled in
certain ways. Any person can browse the source, with the
worst case being that one must download an archive file
or perform a check-out. (better: web git/cvs/svn access)
Any person can use external tools, which themselves are
likewise open, to view/edit/save/create/share the source.
(better: those tools are standard, like emacs/gimp/audacity)
We also expect a certain degree of openness (not a lot of
non-public communication) and a certain degree of modularity
(parts are interchangable across similar projects and versions,
allowing distributions to mix and match).
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Running regular X11 apps

2008-06-26 Thread Albert Cahalan
On Thu, Jun 26, 2008 at 8:28 PM, Sayamindu Dasgupta [EMAIL PROTECTED] wrote:

 From what I gathered from my experiments, I think it makes sense for
 us to go with Metacity + maximus. That would require no code changes
 in metacity and minor changes in sugar. If we want to support activity
 icons though, we would probably require some more code changes in
 sugar.

Maximus won't handle the gimp AFAIK.

Can't regular activities just ask to be maximized
and/or ask to be the same size as the screen?
The common Python libraries could do this.

The critical thing here is switching between multi-window
programs that have stuff like floating toolbars. I suspect
that a one-desktop-per-activity policy will get you that.

If metacity needs to change, then it changes. Changing it
might involve a new freedesktop.org specification, so that
the changes don't become some sugar-specific hack.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: etoys now available in Debian's non-free repository

2008-06-24 Thread Albert Cahalan
I'm glad that Debian didn't break the rules for etoys.
You're claiming to be open source, yet you've LOST the
source code decades ago. Hacking up binary images is
shockingly horrible software non-engineering.

You've no justification for taking shots at gcc, which
is entirely capable of being bootstrapped from any other
C89 (ANSI C) compiler. BTW, Ken Thompson's hack is not
viable without perfect AI because source code gets modified.

GNU Smalltalk is built in a relatively normal way. OLPC could
ship that instead, assuming that Smalltalk is desirable.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


fixing etoys

2008-06-24 Thread Albert Cahalan
Here are some ideas that might help you fix some of the problems
with start-up performance, shut-down performance, open source,
and software engineering practices.

You're trying to do a persistant system image on an OS that wasn't
really designed for it. If you were on an exotic system with a
persistant image (like EROS, KeyKOS, or OS/400), you might be able
to cut the power at any time without losing more than a few seconds
of work. The key here is that the persistant system image OSes
continuously write out changes to disk. They do this atomicly,
and in small chunks, rather than overwriting everything at once in
a dangerous non-atomic operation.

You're trying to do a persistant system image on an OS that wasn't
really designed for it. If you were on an exotic system with a
persistant image (like EROS or OS/400), you'd be able to cut the
power at any time without losing more than a few seconds of work.
The key here is that the persistant system image OSes continuously
write out changes to disk. They do this atomicly, and in small
chunks, rather than overwriting everything at once in a dangerous
non-atomic operation.

Start with that. Break each object out into a separate file.
Your database becomes a directory rather than a big blob file.
When an in-memory object changes, you write a copy to a fresh
new file on disk. You keep the old on-disk copy around until
the new one has been synched. (fsync or sync probably, but be
very careful to avoid doing this more than once every few
seconds) You may need subdirectories for better performance;
it is very unwise to rely on Reiserfs-like performance when
having large directories.

On-demand loading is required for start-up performance.

Inheritance from a read-only image will cut per-instance disk size.
On a Debian system, install the read-only image under /usr/share
and the per-instance changes somewhere under $HOME. On the XO,
the read-only image stays in the activity and the per-instance
part goes into the journal. For older XO system software which
does not support grouping multiple files into single Journal entries,
you'll have to do it yourself with a standard archive format.
There are three to choose from: tar, cpio, pax.

To make things maintainable outside of the walled garden, store the
objects in text form. Make them be like nicely formatted source code.
Be permissive in parsing them, and try to preserve any comments that
might be added by users with regular text editors. Try to maximize
compatibility with GNU Smalltalk.

If you have bulk data that would not reasonably be editable with
a text editor, such as PNG images, then leave that part in binary.

To cut down on dirty anonymous pages in memory, and thus greatly
improve the situation on low-memory swapless systems like the XO,
you could do mmap(...,PROT_WRITE|PROT_READ,MAP_PRIVATE,...) on the
binary blobs at startup. This should just be things like PNG images.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: etoys now available in Debian's non-free repository

2008-06-24 Thread Albert Cahalan
On Tue, Jun 24, 2008 at 2:18 PM, Bert Freudenberg [EMAIL PROTECTED] wrote:
 Am 24.06.2008 um 20:04 schrieb Albert Cahalan:

 I'm glad that Debian didn't break the rules for etoys.
 You're claiming to be open source, yet you've LOST the
 source code decades ago. Hacking up binary images is
 shockingly horrible software non-engineering.

 Sorry Albert, this just shows your shocking ignorance.

 *All the source code* for *every* piece of byte code in the
 image is available, and not only that, we even *ship* it

No. This is not true. You ship a binary blob. That doesn't
count, even if so-called source code is viewable from
within the blob.

It's not source code unless I can:

a. build a bit-for-bit identical image from it (aside from timestamps)
b. edit it with an editor of my choice
c. manage it with svn, git, or anything else
d. diff it with standard tools
e. patch it with standard tools

 GNU Smalltalk is built in a relatively normal way. OLPC could
 ship that instead, assuming that Smalltalk is desirable.

 It is not Smalltalk that is desirable, but Etoys. I'd be very interested to
 hear of equivalent software packages.

Unless you can separate Etoys from Smalltalk, you sure
do desire Smalltalk. If you had source code, you could just
use the GNU Smalltalk interpreter.

Fortunately, you do have the possibility of recreating your
long-lost source code. You can mostly regenerate it from
your binary blob, then rewrite the bits that didn't survive.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Bitfrost and dual-boot

2008-05-30 Thread Albert Cahalan
On Fri, May 30, 2008 at 1:15 AM, Edward Cherlin [EMAIL PROTECTED] wrote:
 On Thu, May 29, 2008 at 8:45 PM, Albert Cahalan [EMAIL PROTECTED] wrote:
 On Thu, May 29, 2008 at 5:07 PM, Edward Cherlin [EMAIL PROTECTED] wrote:
 On Thu, May 29, 2008 at 10:48 AM, Albert Cahalan [EMAIL PROTECTED] wrote:

 I do believe that, practically speaking, all of this is moot.
 Windows uses both SD card storage and the NAND flash storage.

 I haven't seen it and you haven't seen it. What's your source?

As I said in a previous email, my source is Mitch on IRC.
It also just makes sense; I've long doubted the idea that
the NAND (a valuable resource) would just be wasted by
a Windows install.

 Are you
 talking about the version in the Windows-only trials during the next
 month or two?

I'm talking about everything.

Use of NAND flash is a Windows feature that doesn't have
anything to do with the choice of firmware. Even if we get
to keep Open Firmware (a miracle), Windows can still use
the NAND flash.

 Why do you keep believing that dual-boot XOs will actually ship?

 Because Microsoft and OLPC announced dual-boot. Because Microsoft
 can't buy XOs for resale, and OLPC has no intention of shipping
 Windows-only XOs. Egypt wants dual-boot.

Many people have been burned by believing similar words.
None of that info is trustworthy, all of it can change at any
time, and at least one of the parties has a very long track
record of being ruthless.

 OK, so Microsoft could arrange to wipe out Linux after delivery. Then
 what? Do you think that the world will stand still for that kind of
 overt sabotage? I can't imagine OLPC signing a contract that would
 allow it. I gather that you can. You're on crack, Albert.

You're putting words in my mouth now.

Wiping out Linux after delivery is certainly possible.
It would take the form of a helpful suggestion that
the user format the D: volume to make more space.

I can't imagine that a contract would mention it.

Still, I don't expect this at all. It would allow children
to try Linux. Microsoft doesn't work that way.
The laptops will be Linux-free from the start.

Not that booting Linux would be easy anyway;
remember that it is very hard to remove the SD card.

 Windows XP is **using** the NAND storage.

 There is no support for partitioning it. Even if both Linux and
 OpenFirmware were to support such a thing, you'd have to get
 Microsoft to agree to something that makes no business sense
 at all.

 Sources, please.

Sure. See www.kernel.org if you want source, proving that
there is no support for partitioning. You can also get source
for Open Firmware somewhere; use Google if you need it.

In case you meant the other kind of source (kind of rude)
to prove that Windows is using the NAND, I'll just have to
say that Mitch said so on IRC. It's also just plain silly to
think that Windows wouldn't use the NAND, both because
it is a valuable resource and to block competition.

 Who says what the dual-boot architecture will be? If
 you won't be able to run Linux after the first time you run Windows,
 as you seem to allege,

I don't know where you got that idea. Plain old Linux
will boot from a USB stick, but it won't be shipping
with the laptop. Since the NAND is in use by Windows,
there won't be a Linux to begin with.

 in what sense is this dual-booting? Are Mitch
 and Scott such technical idiots that they wouldn't spot this?

Right, it's not dual-booting. Dual-booting won't ship,
at least in large deployments.

 Also, I think you completely misunderstand the market. The ability to
 use Open FirmWare instead of a proprietary BIOS will be of intense
 interest to all PC vendors. I expect OFW to sweep through most of the
 market in no more than two or three years.

 I can't imagine why. LinuxBIOS (now coreboot) didn't.
 Even EFI didn't. Your wishes are not their wishes.

 Albert, I'm not talking to you any more until you start making sense.
 Linux BIOS never booted any Windows other than 2000 (with ADLO), and
 EFI isn't Open Source.

You think the PC vendors care that EFI isn't Open Source?
You think the PC vendors care that BIOS isn't Open Source?
Really, they have NO desire for Open Source firmware.

That's your desire, not theirs. Do not assume they think like you.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Bitfrost and dual-boot

2008-05-29 Thread Albert Cahalan
On Thu, May 29, 2008 at 5:07 PM, Edward Cherlin [EMAIL PROTECTED] wrote:
 On Thu, May 29, 2008 at 10:48 AM, Albert Cahalan [EMAIL PROTECTED] wrote:

 I do believe that, practically speaking, all of this is moot.
 Windows uses both SD card storage and the NAND flash storage.

 (NAND storage being what you'd hoped to protect)

 The most you could protect would be the firmware itself, but
 it is silly to imagine that a laptop would have OpenFirmware
 when the NAND storage doesn't even have Linux.

 The question was, how to protect Linux from Windows, in particular
 from malware allowed in by Windows. (Or possibly from malware designed
 into Windows, a marketing practice not unknown in the past.)
 Protecting Windows-only machines is Microsoft's problem, not ours.

 We can be quite certain that script kiddies and others will attack
 Fedora and OFW on dual-boot XOs.

Why do you keep believing that dual-boot XOs will actually ship?

Windows XP is **using** the NAND storage.

There is no support for partitioning it. Even if both Linux and
OpenFirmware were to support such a thing, you'd have to get
Microsoft to agree to something that makes no business sense
at all.

Supposing you managed to get that miracle, you'd have to
convince countries to ship a system with two OSes that are
both about to run out of space. Microsoft will of course be
pushing for a better Windows experience, meaning all space
is allocated to Windows. (but this is theoretical, because you'd
need a miracle to get partitioned NAND support into Windows)

BTW, if NAND size were doubled, that would mean more NAND
available to Windows. If there were so much NAND available
that Windows had no use for it, Microsoft would find a way to
purposely waste the additional NAND.

 Also, I think you completely misunderstand the market. The ability to
 use Open FirmWare instead of a proprietary BIOS will be of intense
 interest to all PC vendors. I expect OFW to sweep through most of the
 market in no more than two or three years.

I can't imagine why. LinuxBIOS (now coreboot) didn't.
Even EFI didn't. Your wishes are not their wishes.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: [OLPC Security] Bitfrost and dual-boot

2008-05-29 Thread Albert Cahalan
On Thu, May 29, 2008 at 7:31 PM, Bobby Powers [EMAIL PROTECTED] wrote:
 On Fri, May 30, 2008 at 12:39 AM, C. Scott Ananian [EMAIL PROTECTED] wrote:

 * Windows runs from an SD card, but there is not much space left on
 that SD card to store user files.  User files are stored in NAND at
 the moment.  In the dual-boot scenario which OFW2 will enable, we will
 either partition the NAND (likely also expand amount on onboard NAND),
 or limit Windows to the storage on the SD card (probably necessitating
 an increase in the size of the SD card).  None of this has been
 decided yet.

 Did I miss something?  I was under the impression that the XO uses JFFS2 on
 the NAND.  If we're worried about Windows malware messing with files on the
 NAND, won't they have to be able to mount the volume first?  I only did a
 quick google search, but I didn't find any Windows JFFS2 implementation.

First of all, malware can contain filesystem drivers. It's been done.
In this case, probably an existing Open Firmware or Linux kernel
jffs2 driver would be made to run in userspace.

Second of all, there won't be any need to worry about this issue.
Windows is using the NAND for itself. There is nearly zero chance
that Microsoft will be willing to share the NAND. It's about the same
chance as Microsoft being leveled by a large meteorite.

We'd be very lucky to keep Open Firmware at all. I can well
imagine even worse than losing Open Firmware.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: XO-2

2008-05-23 Thread Albert Cahalan
John Watlington writes:

 The loss of a keyboard is mourned. But so much of the activities
 the young kids that OLPC is targetting do are more manual and direct.

Kids too young for a keyboard? That would be below school age.

 The desire to maximize display area (but clam-shell, not tablet, for
 protection while being transported) led to the proposed form factor.

Display area costs power. It is highly desirable to have color,
so you'll be needing a backlight.

I have to wonder about the quality of this device, both as a display
and as an input device. This touch-screen idea seems to have become
an obsession that ignores all logic.

As an input device, why should anybody believe it won't be as awful
as the touchpad? Will it need screen-cracking hinge-breaking pressure?
Will it be jumpy and uncontrollable? Is there an alternate design
for when the touch screen is found to be unworkable? There were clear
signs early on that the ALPS dual-mode device was defective, yet the
device wasn't abandoned. Same here maybe, with an unusable device
being put into production?

As a display, the design has obviously been compromised. You'll be
needing an extra layer, which will block light. Then... haven't you
seen the pictures of XO touchpads that were behaving badly because
they were **covered** in grime? Dirty screens don't function.
You can also expect lots of scratches unless sapphire screen coatings
are somehow cheap enough.

 I can think of a few ways to integrate a keyboard with this new design.
 But then we continue the huge production/logistical problem of
 generating keyboards (and spares keyboards) for each country.

For generating them, you could do something more like an ink-jet.
Then you don't have to retool the factory to change things.
Write a mirror image into the mold for durability.

A flex keyboard with hard keycaps would have been lovely to type on.
It can be done; you just need a hardness gradient like the squid:
http://science.slashdot.org/article.pl?sid=08/03/29/237206from=rss
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: [IAEP] [sugar] OLPC's bizarre behaviors

2008-05-23 Thread 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.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: [Its.an.education.project] Constructionism (was Re: XP on OLPC - a contrarian view)

2008-05-23 Thread Albert Cahalan
On Fri, May 23, 2008 at 8:10 PM, Alex Belits
[EMAIL PROTECTED] wrote:
 Eben Eliason wrote:

 For what it's worth, I would be careful to portray the low-achievers
 and the brightest as opposites.  As I note below, I frequently find
 that some of the brightest are also some of the low-achievers, due to
 certain aspects of the educational system.  This doesn't change your
 point, of course, which is noted.  It simply means that the way we go
 about raising the overall educational level might not be as
 straightforward as many think.

I know. I was being overly polite, to the point of being wrong.
I hate it when others do that, and ought not do that myself.
Here we go, the rude version: the dumb kids (future muggers)

 What is important, higher overall education level ALWAYS benefits society
 given other equal conditions, and lower overall educational level ALWAYS
 hurts it.

 Ex #1: The above mentioned Republicans (or to be more precise,
 Social Conservatives that in US are represented by Republican Party)
 who are mostly supported by either rich or ignorant.

I hadn't thought of myself as being rich, but OK. Thanks.

Do remember that No Child Left Behind is actually working.
Prior to that, it was very easy for a school to simply ignore
the education of uncooperative and dumb kids. The kids got
nothing more than bad babysitting. I hope you don't find it
wrong or unbelivable that the Republican Party actually helps
those who are doing badly.

 Why there ARE tests that are not a part of the teaching process
 in the first place? US turns everything into some kind of
 adversarial system where government acts as both public schools'
 owner and adversary that challenges schools with tests instead
 of co-operating with them, thus basically not trusting its own
 employees to do their job, and doing it through students for whom
 both government and teachers are supposed to be figures of authority.

It's a mess, mainly because of the teacher's union. You can't
fire or lay off the worst teachers; you can only fire or lay off
the ones with the least seniority. You can't offer more money to
specialist teachers that are in high demand; an English or gym
teacher gets the same as a chemistry or physics teacher. This is
much of the reason why dumping money on the problem is rarely
effective; it just goes to the same people.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Constructionism (was Re: XP on OLPC - a contrarian view)

2008-05-19 Thread Albert Cahalan
On Mon, May 19, 2008 at 3:47 AM, Edward Cherlin [EMAIL PROTECTED] wrote:
 On Sun, May 18, 2008 at 5:41 PM, Albert Cahalan [EMAIL PROTECTED] wrote:
 On Sun, May 18, 2008 at 5:38 PM, Edward Cherlin [EMAIL PROTECTED] wrote:

 Sorry, people can't learn Constructionism simply by reading.

 That is simply appalling. The words that come to my mind are:
 nonsense, unlearnable, faith-based, bullshit, and excuses

 I'm sorry, I have no idea from this farrago of insults what your
 actual objection is. If you don't understand what I said, you can ask
 for clarification. If you think you do understand but you disagree,
 you can state your case. But this is unacceptable.

I couldn't find a less offensive way to describe my opinion of
the idea that the concept is both valid and unlearnable by reading.
I wish I could have done better.

 It's not that. I think you need an overview of unschooling.
 http://en.wikipedia.org/wiki/Unschooling

 I think it would be helpful if you gave the link when first
 introducing a new term whose meaning is not obvious.

I wanted to see if you were really aware of the field of
education, including the terminology. I guess that would
be a c13m way to teach you how I feel about your use of
words that not everybody understands.

 Yes, I see. Indeed, Unschooling as Holt expounds it includes much from
 Constructivism. Good man, Holt. Since you know about him, and you
 yourself have suggested him as a model for Constructivism, why are you
 shouting at us? It isn't our fault that you haven't put 2 and 2
 together yet.

I don't claim to agree with unschooling. That is however the
usual name for this sort of education. Feel free to explain
any distinctions you may see.

 I believe I even have the children of suitable age. (all even ages
 from 0 to 8) I can teach how I please, as they are homeschooled.

 Out with it, then! How do you please? How are they doing?

 Those worthless c13m toys (manipulatives) gave me an 8 year old
 who was struggling with multi-digit addition and subtraction.

 That's funny. I don't recall any suggestion from any educator that
 Cuisenaire rods would be any good for anything outside the 0-100
 range. Where did you get that dippy notion from? You need the
 Montessori materials for that, and they are only good up to 10,000.
 Chisanbop might have helped.

 I cast that junk aside, and

 replaced it with...?

Explain the topic, work through examples, give the kid some problems
to do, insist on effort, repeat as needed until barely competent,
then move on to the next lesson before boredom sets in. It helps to
have word problems with humor, obvious real-life use, and topics
that interest the child. Timed tests are good for simple arithmetic.
The standard is barely competent to avoid boredom; full competency
comes via the fact that later lessons will depend on earlier ones.
It's done with pencil and paper, and sometimes a calculator.

 3 months later he's doing much better.
 He can handle most of the math needed for a college-level physics
 course targeted at engineering students. That even includes the
 bare essentials of integral calculus.

 Now contrast the picture above with the standard Instructionist
 picture of going to school, taking COBOL classes for a few years,
 never learning anything not assigned, and getting a job as a cog in a
 corporation. It isn't COBOL any more, but the specific language
 doesn't matter. This is a picture of learning only enough so that you
 never have to think for yourself again, and being taught to _like_ it
 that way.

 Thinkers may look down on non-thinkers,

 Are you a Republican, considering Liberals to be elitists for wanting
 everybody to be able to think? I don't know anybody else who spouts
 that hypocritical nonsense.

 but don't knock it too much.
 Being a cog in a corporation will put food on the table and a roof
 over the head. It sure beats what the drop-outs face.

 Albert, you will never convince me that you believe that yourself. You
 know what it is to educate yourself on new computer technologies.

I personally don't wish to live the 9-to-5 existance, but that
doesn't make it bad for everybody. Most people are not very curious,
yet public education must serve them too.

 We thus have
 things like No Child Left Behind, which has done wonders for both
 math and reading skills.

 Are you serious? Are you really a Republican? No Child's Behind Left
 is the worst disaster in education in decades, as John Holt would have
 been the first to point out if he had lived long enough. Who claims
 that NCLB is raising skills, as opposed to test scores? With what
 evidence? The real skills aren't on the standardized tests.

Accountability and measurement is critical. Without that, you have
an unreliable system that produces a few winners and many losers.
While I regret that NCLB doesn't do much for the brightest, it is
extremely important for society that we raise the educational level
of the low acheivers.

 Spoon-feeding facts into a kid

Re: XP on OLPC - a contrarian view

2008-05-18 Thread Albert Cahalan
On Sat, May 17, 2008 at 6:28 AM, Martin Langhoff
[EMAIL PROTECTED] wrote:
 On Sat, May 17, 2008 at 9:34 PM, Albert Cahalan [EMAIL PROTECTED] wrote:

 Reason: it's not at all related to laptop computers
 Fact: it's not universally valued by teachers

 This *is* a project pushing the envelope. Waiting for universal
 consensus is aiming for the lowest common denominator.

 Constructionism might be a great idea. I have doubts, particularly
 in a classroom with 40 students and a below-average teacher.
 (remember, about half of the teachers are below-average)

 Stop here, and please _read_ on constructionism. (Hint: most of the
 tricks have to do with what happens _without the teacher around_).

I've tried. I'm not going to go get a degree studying it.

From what I can tell, constructionism (c13m) is a buzzword that
vaguely refers to an age-old teaching practice: learning by doing.
The idea appears to be extremely old, though not the norm. Ditching
the buzzword would be appreciated; it only serves to obfuscate.

From what I can tell, c13m is an awful lot like unschooling.
Perhaps you can explain the difference.

FYI, what happens _without the teacher around_ is probably not
what the adults would like. Kids play games, fight, view porn,
vandalize things...

It's been 28 years since the Mindstorms book. If the idea still
hasn't caught on, there must be a reason. The teachers have decided.
Normal teachers will thwart any effort to change teaching.
Tying the success of a laptop program to massive changes in
teacher behavior is not right.

 In any case, you simply don't need laptop computers for this.
 It's a matter of teaching style; you need to teach teachers.

 Not focus on the teachers necesarily. Provide the kids with
 interesting, self paced puzzles of increasing complexity. Give them
 tools to explore collaboratively. Give them interesting reading
 materials.

 That's what the XO+Linux+Sugar bring.

Given a choice, most kids will play some far less useful game.
You seem to think kids will teach themselves. The very brightest
ones might do that, driven by their curiosity. Most will not.

 I'm sure. Researchers tend to get the results they desire.

 And you will brush off evidence you don't like? I have higher
 expectations than that for discussion on devel@

I probably can not verify that the researchers used teachers
who were disinterested or even actively opposed to any change.
I probably can not verify that lots of below-average students
were included in the mix. I probably can not verify that the
classroom sizes were large.

 Software freedom does however require some kind of hardware.

 Software freedom - also close to my heart - does become interesting
 if we can get kids into learning about the sw. Missing a super-hacker
 as a teacher, they'll have to explore, learn and share.  Social
 constructivism is the name we tend to give these days to that dynamic.

According to wikipedia, social constructivism is something else.
I think you mean constructionist learning. (not that either is
all that clearly defined)

 In other words: play to the kids natural curiosity and share/compete
 instincts and they'll learn on their own.

 Now, if your interest in education goes as far as flashcards, don't
 worry, focus on helping us with the sw, and let others thing about
 education.

I can imagine myself providing content for a math program.
I made a kid go from struggling with multi-digit addition and
subtraction to dealing with simple calculus in 3 months.
Doing math on paper is probably easier than with a keyboard
though, and there is the problem of needing a human to look
over the child's work.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Constructionism (was Re: XP on OLPC - a contrarian view)

2008-05-18 Thread Albert Cahalan
On Sun, May 18, 2008 at 5:38 PM, Edward Cherlin [EMAIL PROTECTED] wrote:
 On Sun, May 18, 2008 at 11:46 AM, Albert Cahalan [EMAIL PROTECTED] wrote:
 On Sat, May 17, 2008 at 6:28 AM, Martin Langhoff [EMAIL PROTECTED] wrote:

 Stop here, and please _read_ on constructionism. (Hint: most of the
 tricks have to do with what happens _without the teacher around_).

 Sorry, people can't learn Constructionism simply by reading.

That is simply appalling. The words that come to my mind are:
nonsense, unlearnable, faith-based, bullshit, and excuses

I'm also reminded that one doesn't really understand a concept
until they can teach it. If you can't teach me, then perhaps
your own understanding is weak.

 The idea appears to be extremely old, though not the norm. Ditching
 the buzzword would be appreciated; it only serves to obfuscate.

 The jargon of any field is a necessity to practitioners, but a barrier
 to entry. There are essential reasons, having to do with saving lives,
 for the use of precise medical terminology. There are essential
 reasons, having to do with shared understanding of fairly difficult
 concepts, for the terminologies of mathematics and programming. The
 same is true in psychology, if you can filter out those who practice
 bafflegab to prevent anybody from noticing that they are not, in fact,
 saying anything. Not a trivial practice, but one that some people can
 and will help you with.

I checked the wikipedia article for bafflegab, and found it spot-on.
http://en.wikipedia.org/wiki/Bafflegab

We can do without the words epistemology and ontology as well.

 The problem is that everybody is a psychologist. Nobody thinks that
 simply owning a car makes you a mechanic without actually working on
 cars, but everybody thinks that having a mind entitles them to an
 opinion about all of its workings. The fact is that we are massively
 ignorant about minds/brains, but we do know a few useful things, like
 Isaac Newton's picture of himself as a child on the beach picking up
 pretty shells, while the vast ocean of truth lay all undiscovered
 before him.

 From what I can tell, c13m is an awful lot like unschooling.

 Nope. Well, the Amish practice of calling farm labor schooling might
 qualify, from their point of view.

It's not that. I think you need an overview of unschooling.
http://en.wikipedia.org/wiki/Unschooling

 The way to learn about Constructivist and Constructionist methods (not
 the same thing: Constructionism is the one with the computers) is not
 to discuss putative definitions. It is to practice Constructivism: try
 them and see for yourself. The most direct way to do that is to go to
 an education supply store and buy a set of Cuisenaire rods, and try
 them out on yourself and on any children of suitable age that you can
 borrow the use of.

Cuisenaire rods are truly dreadful, along with the decimal blocks
and sandpaper letters. If that's c13m, then it's harmful to kids.
It doesn't get results.

I believe I even have the children of suitable age. (all even ages
from 0 to 8) I can teach how I please, as they are homeschooled.

Those worthless c13m toys (manipulatives) gave me an 8 year old
who was struggling with multi-digit addition and subtraction.
I cast that junk aside, and 3 months later he's doing much better.
He can handle most of the math needed for a college-level physics
course targeted at engineering students. That even includes the
bare essentials of integral calculus.

 Now contrast the picture above with the standard Instructionist
 picture of going to school, taking COBOL classes for a few years,
 never learning anything not assigned, and getting a job as a cog in a
 corporation. It isn't COBOL any more, but the specific language
 doesn't matter. This is a picture of learning only enough so that you
 never have to think for yourself again, and being taught to _like_ it
 that way.

Thinkers may look down on non-thinkers, but don't knock it too much.
Being a cog in a corporation will put food on the table and a roof
over the head. It sure beats what the drop-outs face. We thus have
things like No Child Left Behind, which has done wonders for both
math and reading skills. You can't expect every kid to spontaneously
generate the sum of human knowledge by playing with plastic blocks.
Spoon-feeding facts into a kid might not be stylish, but it works.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: XP on OLPC - a contrarian view

2008-05-17 Thread Albert Cahalan
On Sat, May 17, 2008 at 2:24 AM, Sameer Verma [EMAIL PROTECTED] wrote:
 Albert Cahalan wrote:

 Watch the video. XP boots fast,

 What does a fast boot up have to do with the overall usability and
 productivity of a system? You can always show a boot screen early in the
 process and say its boots fast. Its not so much the boot speed that
 bothers me, but the impression it creates that if it boots fast, it must
 be fast overall.

True, but the rest didn't look bad at all.

 handles video very nicely,
 runs Microsoft Office just fine (spreadsheet!), and in general
 looks to be highly usable.

 What bothered me most about the video is that it was all XP and no
 Sugar. Yes, we have yet another OS. Where's Sugar?

Ever wonder why Microsoft fought Java, Netscape, Borland, and ODF
so viciously? (purposely making their Java incompatible, attacking
Netscape's revenue stream by making IE and IIS free, hiring away
Borland's employees, buying the OOXML ratification)

Microsoft is all about controlling the platform. They want you to
depend on a Microsoft platform, and especially not a portable platform.

Sugar qualifies as a 3rd-party portable platform. Forget it.

 If we are comparing
 OS only, how does Xubuntu stack up against XP's performance on the XO?

That is an excellent question. I suspect that the Xubuntu stack
has far more potential than sugar.

http://wiki.eeeuser.com/ubuntu:eeexubuntu:home

Unfortunately, sugar got blessed.

 The other thing that was strange was that when he captures video, the
 camera light did not come on. Isn't the camera wired in series with the
 LED? If that's the case then the LED should be on...or the video was
 edited post production.

Probably it is old hardware.

 http://mediadl.microsoft.com/MediaDL/WWW/U/unlimitedpotential/WindowsXP_XOLaptop.wmv
 (works OK in mplayer)

 Don't bet for a moment that Linux will get to stay. That is
 simply not how Microsoft operates.

 Based on my impression from the video clip, its all talk about XP,
 Office, etc. and native XP apps, so at this point, I would be surprised
 if Sugar ships at all.

Of course. Remember: it's about controlling the platform

BTW, though sugar-free XP is a certainty for business reasons,
it's not as if giving up the XP experience would be desired by
any of the buyers. Sugar has that frame getting in the way,
a look that is some adult's wrong idea of what kids see best,
a spam-filled journal that is **planned** to lose your data,
and incompatibility with everything. XP can at least run lots
of free software like Thunderbird, Audacity, Pidgin, and gimp!
(even Open Office, but that counts as a platform)
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: XP on OLPC - a contrarian view

2008-05-17 Thread Albert Cahalan
On Sat, May 17, 2008 at 4:14 AM, Martin Langhoff
[EMAIL PROTECTED] wrote:
 On Sat, May 17, 2008 at 4:08 PM, Albert Cahalan [EMAIL PROTECTED] wrote:

 You don't need computers for constructionism. If pushing educational
 theories of questionable value is your thing,

 Can we stop beating constructionism for no reason, and without any facts?

Reason: it's not at all related to laptop computers
Fact: it's not universally valued by teachers

Constructionism might be a great idea. I have doubts, particularly
in a classroom with 40 students and a below-average teacher.
(remember, about half of the teachers are below-average)
Martin Dougiamas won't be teaching all the classes.

In any case, you simply don't need laptop computers for this.
It's a matter of teaching style; you need to teach teachers.

 Formal research is widespread into this, and seems to consistently
 show that it works, as can be seen in the work of Martin Dougiamas

I'm sure. Researchers tend to get the results they desire.

 I'd rather give the gift of software freedom. Unlike your theories,

 This project has people with different focus from yours Albert. We
 need them all. _You_ care mainly about the sw freedom, others care
 mainly about education. But the overall goal needs both as they are
 complementary.

Oh, I care about education. I even think the laptop is wonderful
for education. The laptop can show flash cards. :-) There is no
need to tie the laptop to constructionism. You can have a laptop
without constructionism, and constructionism without a laptop.

Software freedom does however require some kind of hardware.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: c preprocessor.

2008-05-16 Thread Albert Cahalan
This is good, not bad. Adding glibc-headers is the proper response.
The XO is really really close to having normal and standard tools
for software development.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: [sugar] Microsoft

2008-05-16 Thread Albert Cahalan
On Fri, May 16, 2008 at 5:28 AM, Edward Cherlin [EMAIL PROTECTED] wrote:
 On Thu, May 15, 2008 at 6:15 PM, Albert Cahalan [EMAIL PROTECTED] wrote:

 Just look at the deal. Dual-boot costs $7 extra. Governments will
 not pay the extra $7 to allow dual-boot.

 No, Windows costs about $7 extra for the flash card plus $3 for the
 license. Countries wouldn't save anything by removing Linux + Sugar,
 which is all free. Dual-boot and Windows-only would have the same
 cost.

According to the recent nytimes.com article:

NYT: Windows will add a bit to the price of the machines,
NYT: about $3, the licensing fee Microsoft charges to some
NYT: developing nations under a program called Unlimited Potential.
NYT: For those nations that want models that can run both Windows
NYT: and Linux, the extra hardware required will add another $7 or
NYT: so to the cost of the machines, Mr. Negroponte said.

I can parse that two different ways, neither of which agrees
with you:

Linux-only is $0 extra.
Windows-only is $3 extra.
Dual-boot is either $7 extra or $10 extra.

(depending on if another means adding the $7 to the price
of the laptop, or to the price after already adding $3)
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: XP on OLPC - a contrarian view

2008-05-16 Thread Albert Cahalan
Robert Myers writes:

 The folks that are buying them, Ministries of Education, governments,
 charities all have their own agendas. They do not necessarily line up
 with the agendas of our real customers - children and educators, or our
 own. If we have to give them some of what they want, so that we can get
 some of what we want to to the children, it's a fact of life.

 Selling constructionism is hard. The theory is attractive, but the data
 is _not_ compelling. The buyers are probably not convinced going in that
 it's something they want or need. OLPC would probably have an easier
 time selling $100 Apple ][ clones with drill and practice software than
 the XO as it stands. If the buyers demand a machine that can run
 Windows, tell them that the XO can run Windows.

You don't need computers for constructionism. If pushing educational
theories of questionable value is your thing, spending $0 on a laptop
is the obvious solution for you.

Seriously, forget the laptop. You don't need it.

I'd rather give the gift of software freedom. Unlike your theories,
software isn't much good without hardware. XP is of no help at all.
Because of network effects (economic theory, not computer networks),
shipping XP (rather than nothing) is a net loss.

 The buyer gets to tick Windows off his must have list. OLPC sells a
 machine with XP on a card, a crippled and storage limited XP that still
 doesn't run current first world productivity applications well. XOs get
 out, still loaded with Sugar. Children get them. OLPC gets revenue that
 can help its educational mission. What have we lost but some innocence?

Watch the video. XP boots fast, handles video very nicely,
runs Microsoft Office just fine (spreadsheet!), and in general
looks to be highly usable.

http://mediadl.microsoft.com/MediaDL/WWW/U/unlimitedpotential/WindowsXP_XOLaptop.wmv
(works OK in mplayer)

Don't bet for a moment that Linux will get to stay. That is
simply not how Microsoft operates.

Notice that most of the big successes have had alternates.
There were several batteries, several cameras, and several
memory chips. Competition is good. The problems, our ever
lovable Marvell 802.11 jammer and ALPS frame invoker, did not
have any competition. Sugar did not have competition; from the
start it was fully blessed and immune to all reconsideration.
The choice is wrongly between XP and Linux+Sugar; there
is no logical reason why Linux must be so greatly burdened.
There is another laptop, the One2OneMate, which ships with a
much more reasonable Linux install for kids. Unfortunately that
laptop is not really meant for child ownership and control.

Discussion of the software situation reminds me of this:
http://en.wikipedia.org/wiki/The_Emperor's_New_Clothes
(many people ignore the most obvious problems)
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Microsoft

2008-05-15 Thread Albert Cahalan
Seth Woodworth writes:

 So as a fair practice I think it's clear that no special actions can
 ethically be made to prevent Windows or any other OS from running on
 the machine.  So a Windows port for the XO isn't something that
 could have been preventative.

Wrong. It's called tit-for-tat, otherwise known as fair-is-fair.
It's perfectly ethical to defend oneself against an adversary
who has no qualms about anything.

Just look at the deal. Dual-boot costs $7 extra. Governments will
not pay the extra $7 to allow dual-boot.

I do believe in fairness. The XO should run Windows about as well
as the Xbox 360 runs Linux. Note that the Xbox 360 has numerous
hardware features which were purposely designed to impede Linux.
Fairness mandates that we have hardware to lock out Windows.

Hardware is costly of course. A slightly weaker solution would be
to have the firmware use SMM/SMI tricks to regularly get a bit of
CPU time to scan for Windows in memory. If the firmware finds that
Windows is running, then it silently corrupts RAM. The ideal would
be to make Windows survive about an hour before crashing.
(keep the feature secret of course, to make debugging painful)
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: [Its.an.education.project] Sugar on the EEE PC

2008-05-08 Thread Albert Cahalan
Bernie Innocenti writes:

 Wow, there are way more than I thought, already.
 And they missed this one:

  http://www.one2onemate.com/

This is optimized for teacher thinking. They win. :-(

There is a cart, for moving the laptops to and from classrooms.
It has shaped holes for the laptops. It supplies enough power
to charge 32 laptops from a 15 amp circuit.

There is software for the teacher (using Windows) to monitor
all the students.

There is no hinge to break. If the laptop hits the floor
face-down on top of an object, the screen is protected.

The GUI and apps are superior, at least from the viewpoint of
a school system. You get an Excel-compatible spreadsheet,
a Word-compatible word processor, Tux Paint, Flash player, and a
desktop that hasn't been inspired to the point of unusability.

There will be a cart or two for the whole school to share.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


CIPA done (was: OLPC Project suggestions.)

2008-05-07 Thread Albert Cahalan
 Child-safe web filtering on XO
   Regardless of its merits, CIPA requires it for XO deployments
   in US schools:

Here are the requirements: http://ifea.net/cipa.pdf

The easy way out is child ownership. The requirements only
apply to computers which are owned by schools and libraries.
Probably not every potential buyer is aware of this.

The other thing to note is that there is no required level of
performance, configurability, reliability, or anything else.
People keep assuming that perfection is necessary; it is not.

Not that schools should own the computers though; OLPC should
continue to push for child ownership. (of course the schools
may wish to filter upstream, and they will certainly wish to get
parental permission before distributing hardware)

Anyway, this isn't much of a project. Meeting the requirements
for school-owned and library-owned hardware is very simple.
My /etc/cipa.conf file and technology protection measure follow.
The suggested name is /usr/bin/technology protection measure.
I do not believe that this implementation of the requirements
will have any measurable memory or CPU consumption, which is a
key consideration for the XO.

128.177.31.7
216.163.137.3
64.56.205.61
64.89.23.139
69.16.137.252
69.50.129.146
74.84.194.59

#!/bin/bash
iptables -A INPUT -i eth0 -p tcp -j CIPA
iptables -N CIPA
while read i ; do iptables -A CIPA -s $i -j DROP ; done  /etc/cipa.conf
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: CIPA done (was: OLPC Project suggestions.)

2008-05-07 Thread Albert Cahalan
On Wed, May 7, 2008 at 10:04 AM, Joshua N Pritikin [EMAIL PROTECTED] wrote:

  That is totally half-assed. As a parent, I would be pissed off when I
  became aware of the quality of such an OLPC web filtering solution.

  How about if we place a DansGuardian transparent proxy on a public IP
  address (e.g. proxy.laptop.org). The laptop can use iptables to route
  everything through the proxy. Then we don't have to waste precious RAM
  filtering on the laptop.

Your solution doesn't meet the requirement of the law.
The filtering MUST be on the laptop.

(but again: this only applies to school-owned laptops)

Since the filtering MUST be on the laptop, and the laptop
is already suffering performance problems, a half-assed
solution ON THE LAPTOP is sensible. Schools can also
do something sensible with their network connection, but
that doesn't help with compliance.

BTW, another interesting point is that the law only applies
to images. Kids can read all the filthy stories they want.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Sugar\Windows won't ship

2008-04-26 Thread Albert Cahalan
Let's imagine this several ways, and see why it won't happen.
First consider what a faithful Sugar\Windows system would be like.

a. the familiar Start menu is gone
b. regular Windows programs like Word can't run
c. OS config GUI stuff is (must be) rewritten from scratch

I doubt anybody wants that. Stand up and shout if you do.
It is pointless, because Windows compatibility has been lost.

If Nicolas Nigroponte takes that to a potential buyer, the first
complaint will be that Sugar\Windows isn't real Windows.
The edutainment junk won't run, the kids wouldn't learn the
normal Windows interface used in business, and regular Windows
users won't be able unable to support the strange mess.

The next demand is obvious: eliminate Sugar.

Not that many wouldn't jump for joy, but the price isn't worth it.
(price: loss of localization, loss of trojan protection, loss of
educational value, loss of nearly all volunteer support and nearly
all volunteer development help, power management problems, etc.)

Given how the Sugar\Windows idea seems to just assume compatiblity
with regular Windows stuff, it is entirely unfair to Sugar/Linux.
Sugar/Linux could easily have compatibility with regular Linux stuff,
but this has been denied despite strong demand.

Somebody is getting a bait-and-switch. I'm not sure who, but I would
bet that it is the Sugar fans rathar than the Windows fans. One may
even note that Sugar\Windows is a political way to ditch Sugar.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: [sugar] Mini-Conference Proposal: Toolbars Tabs (or lack thereof)

2008-03-25 Thread Albert Cahalan
Eben Eliason writes:

 1. Toolbar buttons use icons instead of text as an identifier.  Beyond
 the icon, we depend on the content of the toolbar to help define the
 tab, with a textual name being superfluous.  This makes localization
 easier (well, free) and prevents text from being cut off in due to
 translation.

I hope you don't mean to suggest eliminating the text.
Reading should be encouraged, not banished.

Tux Paint, a program commonly used by kids who are many years
younger than school age, is full of text. It is all localized.
We deal with problems (text being cut off, etc.) as they happen.

Putting text labels on everything is an excellent way to encourage
reading. It is very sad that the hardware isn't covered in labels,
but at least the hardware has a bit of an excuse. (logistics)
Software has no such excuse; every icon needs text.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: UI responsiveness

2008-03-24 Thread Albert Cahalan
Mikus Grinbergs writes:

 ...  Performance, or for us, UI responsiveness, the most visible
 and painful issue being start up time of applications is paramount.

 I'm impressed by the start up time of the (giant) TuxPaint activity.

 From the time I click on its icon in the Frame, it takes about
 two seconds to draw the initial view.  Then a tune is played,
 and the screen is populated with tool icons (and the latest
 drawing).  In less than 15 seconds *everything* has been
 initialized - but the user has not perceived that wait, since
 things kept happening.

 This is on Joyride -- shows what can be done *today*.

Thanks. I was wondering if I ought to mention that one.
(since I'm behind the XO port and may be a wee bit biased)

Other than scanning for font files in a background process,
there isn't any magic going on here. We just wrote tolerable
code in the standard programming language.

BTW, the size of Tux Paint can be adjusted. The truly fearsome
source of bloat is localized audio descriptions of the stamps.
Starter images are another big source.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


free usb8388.bin

2008-02-14 Thread Albert Cahalan
We have free firmware now:
git clone git://dev.laptop.org/users/albert/usb8388

I admit that it has some... bugs. The mesh doesn't work. Power management
doesn't work. Heck, it won't send/receive packets and it knows nothing
of this USB thing. However, we have a blinkenlight. Ship it!

BTW, what is killing my blinkenlight? I realize that it wouldn't do
to hang the boot forever because of some missing firmware features,
but that doesn't give much time to debug. Please don't do that.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: free usb8388.bin

2008-02-14 Thread Albert Cahalan
On Thu, Feb 14, 2008 at 11:24 AM, C. Scott Ananian [EMAIL PROTECTED] wrote:
 On Thu, Feb 14, 2008 at 3:26 AM, Albert Cahalan [EMAIL PROTECTED] wrote:

BTW, what is killing my blinkenlight? I realize that it wouldn't do
to hang the boot forever because of some missing firmware features,
but that doesn't give much time to debug. Please don't do that.

  At what point is boot hanging?  I'm guessing it's during the udev
  probe?  I'm not a udev hacker, but turning udev off should get you to
  boot at least (if I'm guessing properly).

It doesn't hang forever, so I can still boot. I haven't timed
the hang, but it could be 30 to 200 seconds.

Then it seems that something shuts off the wireless chip.
Random guesses are that the driver and/or NetworkManager
asks the EC to cut the power.

That isn't much time to run a debugger. (gdb via OpenOCD)
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: How to create a new MIME type for a Sugar activity?

2008-02-09 Thread Albert Cahalan
James Simmons writes:

 I agree I have no business inventing my own MIME type.

Yes you do, and you should ignore the x- disaster.
Pick something sane, descriptive but not too generic,
and be done with it.

(If you use x-, then you **still** face any collision
problems and you're expected to register the type anyway.
Since there would be x- data out in the wild, everybody
would need to support that until the end of time as well.
As they say, it is easier to ask forgiveness than permission.)

 What I really want is a file suffix association like I can
 do with Windows or Midnight Commander on Linux.

This needs to be required for every MIME association.
(if you don't ask for a file extension, no MIME for you!)

Because no common filesystem uses MIME types, the MIME data
is unstable. This is a security hazard. Data shows up one way,
suffers MIME damage (normally) or extension damage, gets sent
along to some other software on the assumption that the original
type info will be used, gets interpreted according to mangled
or alternate type info, and BOOM! You're pwned.

The faster sugar can phase out MIME the better.

 The MIME type of application/zip works, but Etoys is
 using that one too.

Whatever you invent, Etoys will claim it in the next release.
It does not matter if Etoys has any ability to handle the data.

I'm half serious too, as is clear to anybody who has looked at
the list of MIME types claimed by Etoys and tried them.
Almost none make sense. It's like some kind of land grab.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: free firmware for 88W8388

2008-01-23 Thread Albert Cahalan
Dan Williams writes:

 No, you can't.  One team reverse engineers the hardware and
 creates a specifications document, the second team implements
 (from scratch or from unencumbered FOSS sources) the firmware

The only unencumbered FOSS sources are public domain.
Creating BSD code from GPL code is no different from creating
GPL code from a binary blob. Without the clean-room approach,
the GPL code authors would have an easier time proving that
the BSD code is contaminated. It's not certain that they
would succeed of course, just as it isn't certain that a
binary blob vendor would succeed against a GPL firmware that
was made without a clean-room approach. This is purely a matter
of having a more solid defense if it can be shown that there
was no access to the original.

Any Linux hackers want to sue *BSD hackers?  :-)

(as always, this is not be be considered legal advice)
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: free firmware for 88W8388

2008-01-23 Thread Albert Cahalan
On Jan 23, 2008 6:22 PM, Dan Williams [EMAIL PROTECTED] wrote:
 On Wed, 2008-01-23 at 21:03 +0100, Rózsás Gödény wrote:

  I hope you can make options to start with any of the 3
  firmwares.
  Perhaps I wish to try writing a boot1 or boot2.

 Um, Boot1 is burned into ROM on the 8388 and you probably can't change
 that without a lot of voodoo magic :)

 Only Boot2 and the post-boot firmware are loadable.

Yes, but a free emulator requires free boot1 code.
One can certainly load that code in an emulator.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


MIDI does support non-Western music (was: Why can't i access /dev/dsp or /dev/snd on my XO)

2008-01-22 Thread Albert Cahalan
imm ian writes:
On 22 Jan 2008, at 4:11, Albert Cahalan wrote:

 You don't need to abuse pitch bends. MIDI lets you
 redefine the pitches of the notes. You can redefine
 middle C to be 1234 Hz if you like.

 Mmm, well, yes, but...

No but. You can redefine at will, for individual notes.

If you need a player, try timidity. If you have obsolete
equipment that can only do pitch bends, you can use Scalia
to convert a MIDI file. Scalia can also convert back.

 It's not so much the pitches that are the issue, it's the
 intervals, and MIDI kind of constrains what you can do about
 that, so you do kind of end up abusing pitch bend...

Nope. (not that abusing pitch bend is a tragedy though)

Since 1996, the MIDI tuning specification has allowed you to
set the pitch to within 1/16384 of a semitone.

Since 1999, the MIDI tuning extensions have made this a bit
more efficient.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Why can't i access /dev/dsp or /dev/snd on my XO

2008-01-21 Thread Albert Cahalan
On Jan 21, 2008 12:27 PM, Walter Bender [EMAIL PROTECTED] wrote:
 (b) as has been pointed out repeatedly, CSound is an open standard
 (which incidentally predates the MIDI standard).

It may be open, but it isn't much of a standard.
I've only found one implementation, csound itself.
There are no hardware implementations.

Pushing this kind of thing is **wrong**.

 (c) Victor gave some very compelling reasons as to why CSound is a
 better choice, especially for a program that is reaching out to
 non-Western musical sensibilities.

MIDI does non-Western stuff, including unusual
tuning systems.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Why can't i access /dev/dsp or /dev/snd on my XO

2008-01-21 Thread Albert Cahalan
On Jan 21, 2008 1:31 PM, Antoine van Gelder [EMAIL PROTECTED] wrote:
 Albert Cahalan wrote:
  On Jan 21, 2008 12:27 PM, Walter Bender [EMAIL PROTECTED] wrote:
  (b) as has been pointed out repeatedly, CSound is an open standard
  (which incidentally predates the MIDI standard).
 
  It may be open, but it isn't much of a standard.
  I've only found one implementation, csound itself.
  There are no hardware implementations.

 http://www.epigon.in/pdf/studyRoom1.pdf

 Might help a little to address your issues above ?

I think that is an excellent example what I suggested.
They used csound code to implement 64-voice MIDI.
No mention is made of using the csound data formats.

 As a musician, I don't know of anything else that comes close - and that
 includes some pretty expensive proprietary systems with pretty
 blinged-out user interfaces!

 Please don't make me have to go back to midi :)

You must mean bad MIDI engines or similar, because
your csound example was in fact MIDI.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Why can't i access /dev/dsp or /dev/snd on my XO

2008-01-21 Thread Albert Cahalan
On Jan 21, 2008 10:43 PM, M. Edward (Ed) Borasky [EMAIL PROTECTED] wrote:

 1. MIDI is limited but more or less universally spoken. Serious
 algocompsynth *must* involve support of MIDI. CSound recognized this
 years ago.

I think that means file storage, input, output, etc.
The keyboard produces MIDI, which is fed into a
MIDI rendering engine (possibly csound) or saved
to a file.

 3. There are a number of specialized Linux distros for audio. The three
 that I know the most about are Studio64, Jack Audio Distribution (JAD)
 and dyne:bolic. Almost all of them have a patched low-latency kernel,
 and all of them use something called the Jack Audio Connection Kit. They
 may still have to support both OSS and ALSA, but as I noted in another
 post, ALSA had support years ago for sound cards that weren't supported
 by free-as-in-freedom OSS drivers. So, serious algocompsynth on Linux
 *must* have a low-latency patched kernel, ALSA, and the Jack Audio
 Connection Kit.

This is for live performance computer-in-the-middle effects
processing and similar, particularly when multiple audio programs
are in simultaneous use. It's not required for the production
or playback of anything.

 So the question in my mind is, Should the XO be a platform for serious
 algocompsynth, or should it be what the project says it is -- an
 educational project for children to explore and discover? Do children
 need MIDI, CSound, low-latency kernels, Jack, Lisp and Java? I don't
 really think so.

Good point. It's easy to forget that.

 By the way -- as far as microtonal and xentonal and world music scales
 are concerned, MIDI's pitch bends are an awkward hack. Serious
 *microtonal* algocompsynth practitioners either have to spend time
 working around MIDI or use something else.

You don't need to abuse pitch bends. MIDI lets you
redefine the pitches of the notes. You can redefine
middle C to be 1234 Hz if you like.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Why can't i access /dev/dsp or /dev/snd on my XO

2008-01-20 Thread Albert Cahalan
On Jan 20, 2008 3:27 AM, victor [EMAIL PROTECTED] wrote:

 What you say does not make any sense to me. The MIDI
 standard is *one* of many, and in fact the poorest of them
 all. Besides Csound is probably the most used computer music
 language with composers of Computer Music and its
 score an integral part of it.

I know every developer wants to believe that their own
file format is a standard (and a good one too!), but come
on now. I went looking for stuff that supports csound.
I found **one** program, about 5 wrappers (at least one
of which also supported MIDI), and **zero** hardware.
The situation with MIDI is radically different; there are
a tremendous number of MIDI programs and devices.

Perhaps it will be more obvious this way:

Notice that the XO ships with a paint program. Suppose
that the author invented a nifty new image format. Would
it be good to use this format?

Notice that the XO ships with a word processor. This
word processor could use RTF, OpenDocument, OOXML,
TeX, *roff, XHTML... or a custom format that the authors
just happen to have invented. What do you think, go with
the custom format?

Notice that the XO lets you record sound. The most
popular unpatented format was used. The authors could
have invented their own sound format and used that though.
See any problems with doing that?

 But it is not the only way that
 can be used to run it: MIDI, OSC, API event calls, etc.,
 are also possible.

Excellent. You're ready to drop the non-standard stuff.

 If anything we should promote better standards than limit
 ourselves to a very poor one.

MIDI looks damn good to me.

If you really think you have it beat though, go get an RFC and
an ISO standard. Get multiple major hardware manufacturers
to start building your new standard into their hardware. See if
you can get Microsoft and Apple to follow. Then maybe it will
be time to begin the process of slowly saying goodbye to MIDI.
Only then does the format belong on the XO.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Why can't i access /dev/dsp or /dev/snd on my XO

2008-01-19 Thread Albert Cahalan
On Jan 19, 2008 4:33 PM, victor [EMAIL PROTECTED] wrote:

 I can't speak for TamTam because I am not involved in their
 design details, but I can say this, Csound's standard score
 preceeds MIDI by at least a decade (or two if you consider where
 it came from). It is much more flexible to convey musical data
 than MIDI. There are MIDI to csound score converters, but
 that is beside the point, because Csound can play MIDI files
 directly, receive realtime MIDI data and even output it.
 There is no problem whatsoever, with the proper instruments,
 Csound will be a MIDI synthesizer like any other. The main
 thing is, that it is not limited to it (thank goodness...).

How about showing some support for standards by
dropping the non-standard stuff? You can #ifdef it.
Maybe you can even save a few bytes.

If you really must, you can embed the non-standard
stuff into a MIDI file. It's better to avoid non-standard
stuff entirely of course, and any extended MIDI file
had better play decently on a standard MIDI player.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Violent games on the OLPC Activities page

2008-01-18 Thread Albert Cahalan
On Jan 18, 2008 4:06 AM, Antoine van Gelder [EMAIL PROTECTED] wrote:
 Albert Cahalan wrote:
  Sorry to hear about your war.

 Attitudes such as this sir, is the reason that America is viewed by many
 nations as a belligerent and imperialistic monster.

I'm sure you misinterpreted me. Maybe you thought
I was being sarcastic; I was not.

I do however mean to suggest that a problem in one
part of the world should not be used to justify restricting
things elsewhere. I have sympathy for the pain, but I
don't agree that this should impact those outside of
the region in question.

I also don't believe that all people affected by war
will be unable to enjoy DOOM. In any case, they
certainly won't be forced to install and run it.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Why can't i access /dev/dsp or /dev/snd on my XO

2008-01-18 Thread Albert Cahalan
On Jan 18, 2008 11:27 PM, Bill Nottingham [EMAIL PROTECTED] wrote:
 Albert Cahalan ([EMAIL PROTECTED]) said:
  You can read Hannu's take on the matter in his blog. This
  entry is particularly informative, but note that the code
  has since been released under the GPL.
  http://4front-tech.com/hannublog/?p=5

 It must be informative and unbiased. After all, he refers to
 people who disagree with him as Borgs.

Pay no attention to form. His arguments are solid.

There really shouldn't be any doubt anymore that ALSA
was a very bad path to go down. It's been a horrible mess
since day one.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Violent games on the OLPC Activities page

2008-01-17 Thread Albert Cahalan
Bryan Berry writes:

 I feel very strongly that violent games should not be associated
 with OLPC. Albert Cahalan points out that games like Doom can
 teach geometry and other skills. There are ways to teach those
 skills w/out involving violence. I work in Nepal, a country
 recovering from an 11-year civil war. Exposure to more violence,
 real or virtual, is the last thing most Nepali communities want.

OLPC is not shipping DOOM. That really ought to put an end to
things right then and there. OLPC is **not** shipping DOOM.
You're referring to a simple list of all activities. Many of
the activities aren't even working; the list covers **all**.

Sorry to hear about your war.

Games like DOOM provide a powerful incentive to learn subjects
like geometry and physics; the teaching is done elsewhere.
I happen to have a brother who would not have bothered to study
these subjects except that he had an intense desire to learn
how to make video games like the ones he'd been playing. Games
like DOOM set him on a path to learn about coordinate transforms,
linear algebra, computing efficiency, and so on. I wouldn't want
to deny that to any child.

 We can debate forever whether violent games cause violence.
 The fact is many those people (esp. outside the US) whose
 support we need for OLPC, think that violent games are damaging
 to kids. We need to respect that sentiment.

On a mainly development-oriented wiki, we certainly don't.
I suggest that you start a wiki in Nepal, with mirrors of
the activities you like best.

I notice that people tend to object on behalf of other people.
Nobody ever tries to claim that they felt compelled to download
something that then messed up their life.

I find some of the non-activity content on the wiki to be
highly offensive. The wiki actually has a PDF of a book that
strongly encourages genuine violence and intolerance. DOOM
is nothing by comparison. Unlike that book, DOOM has not
caused millions of real humans to die and many more to be
horribly oppressed.

As for inappropriate activities, nothing beats Browse. Students
in Nigeria have been using it to study anatomy, which is often
considered an inappropriate subject.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: font size in console

2008-01-17 Thread Albert Cahalan
Michael Stone writes:

 I assume you're talking about the virtual terminal here; not the
 Terminal activity. As root, you my try a command like:

   setfont sun12x22

Many people report that that font is also too small.
You can try my 15x30 font, which many people love.
It's attached to this email.


15x30pc.psf.gz
Description: GNU Zip compressed data
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: font size in console

2008-01-17 Thread Albert Cahalan
On Jan 17, 2008 11:24 PM, Bernardo Innocenti [EMAIL PROTECTED] wrote:
 Albert Cahalan wrote:

  Many people report that that font is also too small.
  You can try my 15x30 font, which many people love.
  It's attached to this email.

 It's already the second time you attach your font.

It's only 4 K. People keep wanting a decent font.

 Have you seen my message where I ask you where the glyphs
 came from and under what license the font could be
 released?

Yes. It got buried in my inbox while I had to make up
some hours for work. Also, you asked for a copy of
the full thing, but I need to regenerate that and I might
as well throw in the new characters while I'm at it.

BTW, I was mistaken. It's about 1000 characters.

I'm fine with the wording that Wikipedia uses for
public domain. (disclaiming the weird nonsense
which hopefully wouldn't apply to me anyway)

 The first step to get it accepted on the OLPC would be
 to contribute it to the kbd project.  The current
 maintainer also happens to be the Fedora packager, and
 I'm in contact with him for our console keyboards.

Since you're in contact with him, feel free to let him
know that he is welcome to have it.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Marvell microkernel replacement

2008-01-13 Thread Albert Cahalan
On Jan 13, 2008 6:42 AM, David Woodhouse [EMAIL PROTECTED] wrote:
 On Sun, 2008-01-13 at 02:30 -0500, Albert Cahalan wrote:
  David Woodhouse writes:
 
   http://www.csr.com/products/unifirange.htm
 
  They claim that that is a 1-chip solution. Is it really?

 I have no reason to believe otherwise -- why do you ask?

There have been claims that Marvell's solution is especially
well-suited to the XO because it includes a processor.
I can still count the chips though, and Marvell is using 2.
That makes them no better than a 1-chip solution without
a processor, because one can just add a processor to a
softmac 1-chip solution.

I am glad that the Marvell stuff is on USB, where it can
not DMA right over the kernel. :-)

 Fewer chips is generally better. If we could put the _whole_ thing on
 one die -- the kind of thing IBM are really good at doing for their
 customers -- then that would be ideal. I don't think we're quite going
 to manage _that_ level of integration, but we could certainly do better
 than we have in the current XO design.

Being a tad less aggressive: CaFE, D-CON, and a PPC4xx
to turn a softmac wireless chip into fullmac.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: disabling root and olpc passwords

2008-01-13 Thread Albert Cahalan
Bernardo Innocenti writes:
 Albert Cahalan wrote:
 Bernardo Innocenti writes:

 What we're actually doing is just to disable them in the
 default installation so that malicious activities cannot
 login as root or olpc and basically own the system.

 This is NOT needed at all.

 I wrote and tested an /etc/pam.d/su modification that will
 prohibit all non-wheel users from getting su to work.

 What use is it if an application can login, su or sudo as
 user olpc with no password and _then_ su to root?

No use, but the application can't do that, so the point is moot.

That rule will block an su to/from any UID. Note that I
did not use pam_wheel, which fails to protect user olpc.
I used pam_succeed_if to require the wheel group.

This is even easier:

chown root:wheel /bin/su
chmod 4550 /bin/su
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: disabling root and olpc passwords

2008-01-12 Thread Albert Cahalan
Carl-Daniel Hailfinger writes:
 On 13.01.2008 01:45, M. Edward (Ed) Borasky wrote:

 Typical Linux practice is the following:

 1. One *never* allows remote shell login as root -- *ever* -- even
 behind a firewall. One allows only *one* user in the wheel group to
 log in to a shell account, and then *only* via ssh.

 Which is almost as unsafe as using root directly.

It's exactly as unsafe, unless you count the obscurity value
of the non-root account. Note that olpc will not be obscure.

 2. When root access is needed, sudo is used, with the least permissive
 mode possible.

 And once you start installing software globally via sudo, the account
 from which you called sudo to install software is (in almost all
 circumstances) effectively root. Same goes for bootloader configuration.

Thank you! The sudo people sure do market that tool very well.
I was starting to wonder if everybody had gone insane. No, there
is no magic bullet for security, and sudo doesn't even help.

(excepting rare cases involving remote logging and multiple
poorly trusted admins -- as may be the case with employees
being paid to babysit a server)

 Anything less than this level of security is a bad habit --
 a *very* bad habit. Please don't encourage such habits,
 or ask the open source community to cater to them.

 Actually, I would consider the belief that sudo makes things
 unconditionally safer to be mostly equivalent to the belief that
 a personal firewall (which is not a firewall) makes things
 unconditionally safer. IMO, use of sudo should be discouraged
 because it gives people a false sense of security.

I strongly agree. Also, sudo is 146K. Ditch sudo, save space,
and improve security all at the same time.

 Many people interpret complicated or work-intensive interfaces
 as damage and work around them. Often the workaround not only
 neutralizes the intent of the original interface, it actually
 makes things worse from the perspective of the person who tried
 to impose the interface on them in the first place.

Yep.

Firefox is starting to get me clicking OK to everything because
it throws up a pair of dialog boxes for most https sites. Lovely.
If there were actually a serious problem, I might not spot it.
Firefox is crying wolf, with predictable results.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: disabling root and olpc passwords

2008-01-12 Thread Albert Cahalan
Bernardo Innocenti writes:

 What we're actually doing is just to disable them in the
 default installation so that malicious activities cannot
 login as root or olpc and basically own the system.

This is NOT needed at all.

I wrote and tested an /etc/pam.d/su modification that will
prohibit all non-wheel users from getting su to work.

Somebody else pointed out the simple /bin/su permissions
that that would do the exact same thing.

Apply both if you wish, but either alone will do nicely.
There are other ways too, like SE Linux.

For the PAM solution, the top 3 lines of the file should be:

#%PAM-1.0
auth  sufficient  pam_rootok.so
auth  requiredpam_succeed_if.so use_uid user ingroup wheel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Marvell

2008-01-12 Thread Albert Cahalan
Alex Gibson writes:

 Need internetworking support (mixing of arm and thumb code).

Does gcc support that? I won't worry if not though.

With a good compiler and good hackers, plain ARM will
fit just fine.

Alternately, one can easily switch modes by hand.

 For toolchains there are a few options for opensource arm gcc builds.
 Can expect pretty much none of them will directly support marvells
 extended ARM946E-S (by extended I mean the extra registers).

What extra registers? Why should gcc even care?

 Note you want arm-elf-gcc not arm-elf-linux-gcc .

This does not matter. Linux itself is not a Linux program,
yet we compile it with a normal gcc just fine.

Both Debian-unstable and Fedora 8 appear to offer gcc for ARM.
I expect that both will work just fine.

 Next question is which micro kernal/rtos to use ?

 I don't see the need to rewrite one from scratch, there are a
 few opensource rtos available that have been previously ported
 to arm9, not arm946es.

Let's write from scratch. I think it will be easier.

 One other question is how much of the spectrum management is in software ?

By that you mean what?
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Marvell microkernel replacement

2008-01-12 Thread Albert Cahalan
David Woodhouse writes:

 http://www.csr.com/products/unifirange.htm

They claim that that is a 1-chip solution. Is it really?
Marvell uses a 2-chip solution.

If a 2-chip solution is OK, then one could start with a
1-chip softmac solution and add any arbitrary processor.
That CPU could be ARM, MIPS, sh3, sh4, sh5, CRIS,
ColdFire, Blackfin, 186, PDP-11, IA-64...

In any case:

At minimum one must get promises in writing, but it's far
better to have actual published documentation first.
Don't forget about the errata!

BTW, CSR also does GPS for under a dollar.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


  1   2   >