New faster build 1897

[Build Announcer v2]

http://xs-dev.laptop.org/~cscott/olpc/streams/faster/build1897

Changes in build 1897 from build: 1895

Size delta: 11.27M

+cdparanoia-libs alpha9.8-27.2
-gstreamer-plugins-base 0.10.15-1.olpc2
+gstreamer-plugins-base 0.10.15-3.olpc2
+libvisual 0.4.0-3.fc6
+perl 4:5.8.8-28.fc7
+perl-libs 4:5.8.8-28.fc7
-sugar-presence-service 0.79.2-1.olpc2
+sugar-presence-service 0.79.3-1.olpc2
-sugar-toolkit 0.79.5-1.olpc2
+sugar-toolkit 0.79.6-1.olpc2
-TurtleArt 7
+TurtleArt 9

--- Included cdparanoia-libs version alpha9.8-27.2 ---

--- Changes for gstreamer-plugins-base 0.10.15-3.olpc2 from 0.10.15-1.olpc2 ---
  + Add the correct patch for the Thinkpad problem, and keep the old
  + Add upstream patch to fix default track selection on Thinkpads

--- Included libvisual version 0.4.0-3.fc6 ---

--- Included perl version 4:5.8.8-28.fc7 ---

--- Included perl-libs version 4:5.8.8-28.fc7 ---

--- Changes for TurtleArt 9 from 7 ---
  + fixed some typos
  + fixed divide by zero bug
  + French blocks

--
This mail was automatically generated
See http://dev.laptop.org/~rwh/announcer/faster-pkgs.html for aggregate logs
See http://dev.laptop.org/~rwh/announcer/joyride_vs_update1.html for a 
comparison
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Maintaining visibility into Collabora's work for OLPC

[Dafydd Harries]

Ar 25/04/2008 am 22:50, ysgrifennodd Michael Stone:
> In the mean time, I'm quite happy with Daf working on Gadget and with
> Guillaume working on debugging Telepathy/presence-service issues. (Daf
> -- we should have a chat with Martin about how to coordinate the testing
> and deployment of Gadget support on both the XO and XS platforms.)

Let's.

> Summary of Desires to Date
> --
> 
> Here's a summary of the feedback that I've received from several
> indiduals about needs they have which Collabora might be able to
> satisfy:
> 
>   Michailis remains most interested in an architecture overview and a
>   dataflow for Clique.
>   
>   Wad prefers to know the dataflow for the school-server XMPP protocol.
>   A written version of your last conversation with me would be a good
>   start. 
>   
>   Scott said that he cares less about documentation and more about
>   constructing the best collaboration architecture we can. 
>   
>   I don't think anyone is quite sure how best to pursue John Gilmore's
>   interoperability suggestions. 
>   
>   I have not queried Polychronis recently enough to have an accurate
>   account of his needs.
>   
>   (I would like to see someone spend a few minutes integrating
>   Telepathy's automated test suite into Chris' Tinderbox or Titus'
>   buildbot.)

I think these are all worth pursuing; it's just a matter of prioritising. :)

> Profiles
> 
> 
> I suggested to Daf a few days ago that I think it might be appropriate
> for Collabora and the Collabora employees working on OLPC's concerns to
> maintain profile pages on 
> 
>   http://wiki.laptop.org/go/Profiles
> 
> so that the entire project has greater visibility into Collabora's
> relationship with OLPC. To this end, I threw up a stub at
> 
>   http://wiki.laptop.org/go/Profiles/collabora
> 
> You should examine it to see if it is to your liking.
> 
> (Also, I mirrored the Collabora logo on our servers at 
> 
>   http://wiki.laptop.org/go/Image:Collabora.gif
>   http://wiki.laptop.org/go/Image:CollaboraLogo.gif
> 
> Feel free to alter this arrangement if you prefer a different one.)

Seems like a pretty good summary to me.

Thanks for the update!

-- 
Dafydd
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Maintaining visibility into Collabora's work for OLPC

[Michael Stone]

Rob, Daf, & others,

This email is just to let you know that I haven't forgotten about you
and that I'm still working on collecting the actual feedback necessary
to authoritatively respond to your proposed work statement [1]. 

  [1]: http://teach.laptop.org/~mstone/collabora.txt  (temporarily
  published here)

In the mean time, I'm quite happy with Daf working on Gadget and with
Guillaume working on debugging Telepathy/presence-service issues. (Daf
-- we should have a chat with Martin about how to coordinate the testing
and deployment of Gadget support on both the XO and XS platforms.)


Summary of Desires to Date
--

Here's a summary of the feedback that I've received from several
indiduals about needs they have which Collabora might be able to
satisfy:

  Michailis remains most interested in an architecture overview and a
  dataflow for Clique.
  
  Wad prefers to know the dataflow for the school-server XMPP protocol.
  A written version of your last conversation with me would be a good
  start. 
  
  Scott said that he cares less about documentation and more about
  constructing the best collaboration architecture we can. 
  
  I don't think anyone is quite sure how best to pursue John Gilmore's
  interoperability suggestions. 
  
  I have not queried Polychronis recently enough to have an accurate
  account of his needs.
  
  (I would like to see someone spend a few minutes integrating
  Telepathy's automated test suite into Chris' Tinderbox or Titus'
  buildbot.)


Profiles


I suggested to Daf a few days ago that I think it might be appropriate
for Collabora and the Collabora employees working on OLPC's concerns to
maintain profile pages on 

  http://wiki.laptop.org/go/Profiles

so that the entire project has greater visibility into Collabora's
relationship with OLPC. To this end, I threw up a stub at

  http://wiki.laptop.org/go/Profiles/collabora

You should examine it to see if it is to your liking.

(Also, I mirrored the Collabora logo on our servers at 

  http://wiki.laptop.org/go/Image:Collabora.gif
  http://wiki.laptop.org/go/Image:CollaboraLogo.gif

Feel free to alter this arrangement if you prefer a different one.)


Regards,

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

New joyride build 1897

[Build Announcer v2]

http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build1897

Changes in build 1897 from build: 1896

Size delta: 11.41M

+cdparanoia-libs alpha9.8-27.2
-gstreamer-plugins-base 0.10.15-1.olpc2
+gstreamer-plugins-base 0.10.15-3.olpc2
+libvisual 0.4.0-3.fc6
+perl 4:5.8.8-28.fc7
+perl-libs 4:5.8.8-28.fc7
-sugar-toolkit 0.79.5-1.olpc2
+sugar-toolkit 0.79.6-1.olpc2
-TurtleArt 7
+TurtleArt 9

--- Included cdparanoia-libs version alpha9.8-27.2 ---

--- Changes for gstreamer-plugins-base 0.10.15-3.olpc2 from 0.10.15-1.olpc2 ---
  + Add the correct patch for the Thinkpad problem, and keep the old
  + Add upstream patch to fix default track selection on Thinkpads

--- Included libvisual version 0.4.0-3.fc6 ---

--- Included perl version 4:5.8.8-28.fc7 ---

--- Included perl-libs version 4:5.8.8-28.fc7 ---

--- Changes for TurtleArt 9 from 7 ---
  + fixed some typos
  + fixed divide by zero bug
  + French blocks

--
This mail was automatically generated
See http://dev.laptop.org/~rwh/announcer/joyride-pkgs.html for aggregate logs
See http://dev.laptop.org/~rwh/announcer/joyride_vs_update1.html for a 
comparison
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Project name : wine-activities is set up

[Henry Hardy]

The correct URL is git+ssh://
[EMAIL PROTECTED]/git/projects/wine-activities

--HH.

On Fri, Apr 25, 2008 at 5:32 PM, Henry Hardy <[EMAIL PROTECTED]> wrote:

> Fri, 25 Apr 2008 16:22:25 -0400,   "Benjamin M. Schwartz" <
> [EMAIL PROTECTED]> wrote:
>
> 1. Project name : wine-activities
>
> Done. Your tree is here:
> git+ssh://[EMAIL PROTECTED]/git/projects/wine-activities PROTECTED]/git/activities/imagetosound>
>
> Please follow instructions here for importing your project:
> http://wiki.laptop.org/go/Importing_your_project
>
> Let us know if you have any problems with your tree. Happy hacking.
>
> Cheers,
>
> --
> Henry Edward Hardy
> [EMAIL PROTECTED]
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: An olpcfs experience report

[Joshua N Pritikin]

On Fri, Apr 25, 2008 at 04:59:56PM -0400, C. Scott Ananian wrote:
> If you want a solid semantic solution to the problem, you're looking
> at something like:
> http://portal.acm.org/citation.cfm?id=1242520.1242521&coll=&dl=ACM
> but that requires extending the filesystem API to support
> transactions.  I love transactions, but I don't think they are
> strictly necessary for us at this time.

I agree. I doubt transactions are necessary.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: An olpcfs experience report

[Joshua N Pritikin]

My other question about OLPCFS is how the versioning interacts with
activities which work with projects composed of discrete elements (such as
TamTam). I'm not sure whether there is a problem here. I'm just thinking
out loud.

TamTam deals with sounds which are stored as independent self-contained
files. It also deals with compositions of sounds (i.e. music). When I save
my TamTam project, presumbably, it writes out the elements into
individuals files and then saves the project file which ties everything
together. All these files might get slightly different timestamps.
However, all the components are saved earlier than the project file.

Suppose I want to reuse a sound "Yodel" in a comic book. To facilitate
this kind of reuse, activities should try to save content as granularly as
possible. A granular file format will also facilitate differential
compression.

Suppose I refine sound yodel in TamTam and then go back to my comic book.
It might be useful if there was a way to select the newest version of
yodel or select a particular version from among my favorites from within
the activity. OLPCFS would make that kind of UI magic possible.
Version-aware activities with an Import menu may also need a rollover on
the imported object to change the embedded version.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: An olpcfs experience report

[Joshua N Pritikin]

On Fri, Apr 25, 2008 at 12:38:59PM -0400, C. Scott Ananian wrote:
> On Fri, Apr 25, 2008 at 12:30 PM, Joshua N Pritikin <[EMAIL PROTECTED]>
+wrote:
> >  > If you use BDB correctly, it seems to me to be pretty solid and mature
> >  > -- a conclusion which concurs with the long list of BDB users.
> >
> >  Sure, but BDB would be even more trustworthy if I could 'rm -rf' the
> >  database and regenerate it from scratch without losing data. If metadata
> >  was stored in POSIX xattrs then it would seem like your design permits
> >  this mode of operation.
> 
> Yes, it does, but I doubt we'd want to waste precious NAND space on
> storing this data redundantly.  Perhaps.

Fair enough. At least the option is there.

> >  I have seen enough instances of "foolproof" databases that I think we
> >  should minimize reliance on them.
> 
> Yes, certainly I refuse to use GMail because there's a database behind
> it.  Or Firefox for that matter.  Or Linux, since it maintains many
> internal databases, and they're not even standard well tested
> userspace ones!  And don't get me started on resierfs.  Or  ext2.  Or
> ext3!

I'm not trying to give you a hard time. All I'm saying is that it might be
worth the disk space cost of making the data redundent and self-contained
in order to avoid potential support issues in the future.

For example, if some kid in the middle of nowhere starts complaining that
the journal doesn't work, do you want to tell him that he has to recover
from backup or tell him to simply click a hypothetical control panel
button to rebuild the journal index?

Or are you willing to bet that the failure rate of OLPCFS will be much 
less frequent than the failure rate of the NAND? Somebody should try to 
qualify how much disk space is actually at stake. What is the disk cost 
of storing the metadata (but not the index of the metadata) twice? If it 
really takes a lot of disk then maybe just store some of the metadata 
twice.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Project name : wine-activities is set up

[Henry Hardy]

 Fri, 25 Apr 2008 16:22:25 -0400,   "Benjamin M. Schwartz" <
[EMAIL PROTECTED]> wrote:

1. Project name : wine-activities

Done. Your tree is here:
git+ssh://[EMAIL PROTECTED]/git/projects/wine-activities

Please follow instructions here for importing your project:
http://wiki.laptop.org/go/Importing_your_project

Let us know if you have any problems with your tree. Happy hacking.

Cheers,

--
Henry Edward Hardy
[EMAIL PROTECTED]
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: An olpcfs experience report

[C. Scott Ananian]

On Fri, Apr 25, 2008 at 2:47 PM, Joshua N Pritikin <[EMAIL PROTECTED]> wrote:
> My other question about OLPCFS is how the versioning interacts with
>  activities which work with projects composed of discrete elements (such as
>  TamTam). I'm not sure whether there is a problem here. I'm just thinking
>  out loud.

Interesting issues.  My experience using the system is that this isn't
much of a practical problem; the 'new version' is written out over a
tightly-clustered amount of time, and groups are easy to distinguish.
If you want a solid semantic solution to the problem, you're looking
at something like:
http://portal.acm.org/citation.cfm?id=1242520.1242521&coll=&dl=ACM
but that requires extending the filesystem API to support
transactions.  I love transactions, but I don't think they are
strictly necessary for us at this time.
 --scott

-- 
 ( http://cscott.net/ )
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Request for Project Hosting: wine-activities

[Benjamin M. Schwartz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

1. Project name :  wine-activities
2. Existing website, if any : http://dev.laptop.org/~bemasc/DOSConsole-3.xo
3. One-line description :  Turn your Windows application into a Sugar
Activity (if it runs in Wine).

4. Longer description   :  Provides a virtual windows machine, powered
by Wine,
~: into which one can stick a piece of Windows
software in
~: order to run it as an Activity on the XO.
All you need to do is drop it in,
~: draw an icon, and change the name.

5. URLs of similar projects :
http://wiki.laptop.org/go/Wine
http://dev.laptop.org/ticket/3213

6. Committer list
~   Please list the maintainer (lead developer) as the first entry. Only list
~   developers who need to be given accounts so that they can commit to your
~   project's code repository, or push their own. There is no need to list
~   non-committer developers.

~  Username   Full name SSH2 key URLE-mail
~     - --
~   #1 bemasc Benjamin Schwartz (I'm already in the system)


7. Preferred development model
~   [X] Central tree.

8. Set up a project mailing list:
~   [X] No

9. Commit notifications
~   [X] No commit notifications, please

10. Shell accounts
~  (N/A)

11. Translation
~   [X] Translation arrangements have already been made at
http://wiki.winehq.org/Translating
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIEj2BUJT6e6HFtqQRAon8AJ9ppXWDvA9TVM2YtVM1HKZiUIQTgQCdE4Kn
RdV7vRvM+4WdMa9pVFUHMr0=
=bkOx
-END PGP SIGNATURE-
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Working Wine Activity

[Benjamin M. Schwartz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Short:
You can try out the simplest possible Wine-based activity here.  It's
really working now.
http://dev.laptop.org/~bemasc/DOSConsole-3.xo

Long:
This Wine-based activity incorporates the latest fixes to Wine (0.9.60),
which make the Desktop window behave better with Matchbox.  It also uses
Albert Cahalan's Sugarize code to integrate with the launcher notification
system.  It runs in Wine's "Desktop Window" mode, which provides a single
X window containing all the Windows windows, as well as handling the
decorations.  The effect is much like the proposed X-in-X solutions for
legacy X applications.  However, Wine also provides the Windows clipboard
as a layer over the X clipboard, so copy-paste to/from applications in
Wine appears to work perfectly.

My goal, in part, is to be able to say "you don't need Windows to run that
application; you can trivially pack it up as an Activity and run it in
Sugar".  To that end, the .xo contains step-by-step instructions for
converting the DOSConsole activity into the
MyParticularEducationalWindowsApp activity.

Politically, I consider this goal somewhat controversial, because it
suggests that I believe there is demand for running Windows applications.
~ In fact, I do not know of any such demand, and this is rather a
_pre-emptive_ answer to people who may suggest that there is.  I hope it
will be useful, and I hope it will rarely be used.

This framework makes no attempt to integrate with the journal. In the
current implementation, "DOSConsole" will never appear in the Journal, as
far as I can tell.  Instead, all files and state are stored in the /data
directory for the activity.  This effectively makes each Windows-based
activity its own virtual Windows machine.  As the launch and datastore
API's change, this integration may become easier.  However, I do not think
it is critical, especially for the stateless game-style programs that are
very common in the world of Windows educational software.

The system appears to be production-ready, and I would welcome anyone who
has an actual Windows program that they would like to run as a Sugar
activity.  The only significant remaining bug I am aware of is that the
system is likely to get screwy if the user attempts to launch two
instances of the same Wine-based activity at the same time.

- --Ben Schwartz
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIEjfvUJT6e6HFtqQRAv4BAKCC02ihk4G8u7gR/BjMKziBCl71xACeOFrx
UqaASpJospRU46+5XJuEAM8=
=KzUR
-END PGP SIGNATURE-
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Ad-hoc Networking

[Holger Levsen]

Hi,

On Thursday 24 April 2008 01:27, John Gilmore wrote:
> In ad-hoc mode, there is no forwarding of packets.  It isn't a mesh.
> It's just point-to-point communication between two radios, without any
> intermediaries. 

While this is true, it's also incomplete :-) Adhoc mode is not limited to two 
devices and olsr and b.a.t.m.a.n. are two layer-4 mesh routing protocols 
which (usually/often) both use 802.11 in adhoc mode. 

But unlike 802.11s as provided by the marvell chip in the XO this needs cpu...

> This mode works in every 802.11 chip set. 

In theory. In practice, many bugs where found in almost all chipsets and 
drivers in adhoc mode, simple because adhoc mode is not as widely used and 
thus tested as managed mode.


regards,
Holger


pgptEyF3mljDe.pgp
Description: PGP signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: A technical assessment of porting "Sugar" to Windows.

[NoiseEHC]

Thanks for providing this summary!

What is not clear to me is whether we are talking about:
1. Windows on XO with Sugar
2. Sugar on Windows on any machine
3. Both
Also not clear what advantage could any variation provide to OLPC so 
probably NN could be a little more concrete about Sugar on Windows. I 
mean that supporting 1. would be good for marketing since OLPC could 
tell the potential buyer that the laptop can run M$ word even if it is 
not too practical or sane, but at least it would result in laptop sales. 
However porting all the "new" thing would make the Linux development 
became a pointless effort (not that it is possible, see later). Also 
supporting 2. could mean more Sugar developers and more kids getting 
learning software but would undermine XO sales...

> 2. Activities.
>
> The XO comes with a large number of child-oriented "activities"; see
> http://wiki.laptop.org/go/Activities.  One interpretation of "Sugar on
> Windows" is to merely port the activities to Windows, transforming
> OLPC into a pure "educational software" company.  This course is
> moderately difficult.  Python and GTK are "cross-platform", of course, but in
> practice many platform dependencies are inadvertently added to Python/GTK
> code; any developer can tell you that "cross-platform" code which has not
> actually been *tested* on another platform is unlikely to "just work"
> on it.  So some amount of work is necessary on *each* XO activity.
>
> Further, activities are written to a number of XO-specific APIs,
> including APIs for UI elements, collaboration support, and document
> storage.  The easiest course is to stub these out with
> roughly-equivalent Windows implementations of the APIs.  This would be
> sufficient to allow Windows developers to do a significant amount of
> "activity development" on a Windows machine, but the version tested on
> Windows would not actually have all of the functionality of the same
> code running on the existing Sugar/GNU/Linux stack.  OLPC's developer
> base would be expanded, but the resulting ports would be
> "developer-friendly" Windows versions of the activities, not necessarily
> a "kid-friendly" versions one would expect to deploy in schools.
>
> A more aggressive pursuit of "Activities on Windows" would result in
> completely- and fully-functioning versions of ported activities, which
> were as "kid friendly" as the versions running on Sugar/GNU/Linux.
> This would inevitably entail ports of some of the other features of
> the XO; we will discuss the difficulty of implementing these other
> features in turn below and leave the reader to sum these for
> themselves.
>   
That is what I have meant by porting Sugar to Windows. I think that 
creating a minimal version which can run most of the Python activities 
should took less than 1 man year (yes, I have read the MMM) so it is not 
too hard. Of course it would mean fixing some of them, for example the 
Sugar shell crashes on VirtualPC 2007 since it only implements 
SoundBlaster so the OLPC kernel does not recognize any sound card (and 
the Sugar shell assumes one). Also needs fixing activities to handle 
different resolutions from 1200x900 and alikes. If you ask me this is 
the path I advice taking.
> 3. Window manager: Mesh/Friend/Home view, frame, etc.
>
> This is a more difficult task than merely porting the standalone
> activities; this feature entails replacing the existing Windows file
> and application chooser mechanisms with ones which mimic that of
> Sugar/GNU/Linux.  There are two implementation possibilities: writing
> a new Windows application from scratch which mimics this interface, or
> porting the existing Python code from Sugar/GNU/Linux.
>
> Writing a new Windows application is cheap in coordination costs, but
> entails completely rewriting this part of Sugar from scratch.  This
> course would probably also make porting Activities (item #2) slightly
> more difficult, as the interfaces to wm elements (cut and paste,
> collaboration, activity startup feedback) would likely need to be
> altered to work well with a standalone "Activity chooser" Windows
> application.  It is possible that, with some cleverness, the required
> API changes could be kept small.
>
> The other alternative is porting the existing code, which implies
> running X windows, dbus, and much of the rest of the Gnome software
> stack on Windows.  Ports of most of these already exist, but they tend
> to differ from the versions we are currently using in Sugar/GNU/Linux:
> either the Windows versions lag behind the versions we are using, or
> some features don't exist/are broken, or the APIs have deliberately
> diverged to better support Windows uses.  A significant amount of
> integration work would be necessary, but the end result would be a
> system which (in theory) would require only minimal additional changes
> to activities.  It is not clear that the result will be "elegant": it
> may not be well integrated into Windows, it may be less stab

Re: (unknown)

[Walter Bender]

If you have a G1G1 machine, just use sugar-control-panel -s language
Spanish/Peru to get the laptop to use the Spanish strings but keep the
keyboard settings.

-walter

On Fri, Apr 25, 2008 at 12:43 PM, C. Scott Ananian <[EMAIL PROTECTED]> wrote:
> On Fri, Apr 25, 2008 at 12:45 PM, Chris Ball <[EMAIL PROTECTED]> wrote:
>  > Hi,
>  >
>  >> The question has come up from Peruvians who bought G1G1 machines:
>  >> how can we get Sugar to use Spanish, while keeping an English
>  >> keymap (because G1G1 machines have english keyboards) ?
>  >
>  >  I'd edit /home/olpc/.i18n, change it to "es_ES.UTF-8" and restart Sugar.
>  >  I think there is a more friendly way involving the control panel, too.
>
>  I think you need LANG="es.UTF-8" or LANG="es_PE.UTF-8" -- ie, you need
>  to prefix the setting with LANG= and Spain-spanish is almost certainly
>  the Wrong Thing to use.
>   --scott
>
>  --
>   ( http://cscott.net/ )
>
>
> ___
>  Devel mailing list
>  Devel@lists.laptop.org
>  http://lists.laptop.org/listinfo/devel
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

RE: A technical assessment of porting "Sugar" to Windows.

[Raymond F. Hayes Jr.]

I understand your concerns. This is my work at home though which is far
enough away from what I do during the day to not be in conflict so I hope I
can contribute something useful. The aim of the OLPC organization is getting
more important with each passing day.

Ray

-Original Message-
From: Jeffrey Kesselman [mailto:[EMAIL PROTECTED] 
Sent: Friday, April 25, 2008 9:29 AM
To: Raymond F. Hayes Jr.
Cc: OLPC Devel
Subject: Re: A technical assessment of porting "Sugar" to Windows.

>From my POV, Ray?

Anything you can do that is cross platform and open is a great service
to the open source community.

But, with no disrespect intended, some of us have been in the way of
Micrsoft's muscling before and seen how at least the corporate side of
your company is not shy to try to get total control over a market by
controlling the core APIs.  Or to then use that control to muscle out
anything tht doesn't serve Microsoft's financial interests.

I think its this that worries people about a "Windows based" OLPC.  If
Microsoft committed to supporting a completely free and open set of
APIs that were controlled by the community, and not by them.  And to
live within those community decisions, then I don't personally see
anything wrong with a Windows kernel option for the OLPC.

But I'm not sure I believe its within your employer's corporate
culture to do so.

JK

On Fri, Apr 25, 2008 at 12:21 PM, Raymond F. Hayes Jr.
<[EMAIL PROTECTED]> wrote:

>  Say though, I did manage to get something working on all three platforms
and
>  put it all back out into the open source community. How does that "limit
the
>  freedom" of anyone? It would seem to me that every bit of knowledge and
>  every bit of code contributed to the open source community increases the
>  freedom of everyone.
>
>  Ray
>
>  (to be completely transparent, I do work as a developer for MS though in
>  Group Policy not anything remotely connected to the OS or the kernel or
>  OLPC)
>
>
>  -Original Message-
>  From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of
>  [EMAIL PROTECTED]
>
>
> Sent: Friday, April 25, 2008 8:16 AM
>  To: Raymond F. Hayes Jr.
>  Cc: 'OLPC Devel'
>  Subject: RE: A technical assessment of porting "Sugar" to Windows.
>
>
>
>  On Fri, 25 Apr 2008, Raymond F. Hayes Jr. wrote:
>
>  > I've been reading "Cross-Platform Development" in C++ by Syd Logan.
It's a
>  > fun read if you like coding for fun. I've got all the source; just want
>  all
>  > the information before I start playing.
>
>  Seems like most everyone involved currently considers this at best a bad
>  idea, but if limiting the freedom of a large chunk of a generation is
your
>  idea of fun, go ahead and knock yourself out trying.
>
>  IMHO involving MS in any way is shooting ourselves in the foot.
>
>  >
>  > -Original Message-
>  > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf
>  Of
>  > [EMAIL PROTECTED]
>  > Sent: Friday, April 25, 2008 12:55 AM
>  > To: Raymond F. Hayes Jr.
>  > Cc: 'OLPC Devel'
>  > Subject: RE: A technical assessment of porting "Sugar" to Windows.
>  >
>  > why climb aboard a sinking ship, particularly when yours is moving
fast...
>  >
>  > On Fri, 25 Apr 2008, Raymond F. Hayes Jr. wrote:
>  >
>  > > These might be stupid questions since I just joined the newsgroup
today
>  so
>  > > my apologies in advance but I wasn't able to find an answer on the
site.
>  > >
>  > > When you're talking about running Sugar on Windows XP, are you
talking
>  > about
>  > > a running the "retail" version of XP or a version of Windows XP
Embedded
>  > > with a customized shell as described here:
>  > > http://msdn2.microsoft.com/en-us/library/ms940134.aspx or some
special
>  > > version to be decided later on.
>  > >
>  > >
>  > > Ray
>  > >
>  > >
>  > > -Original Message-
>  > > From: [EMAIL PROTECTED]
>  > [mailto:[EMAIL PROTECTED]
>  > > On Behalf Of Wade Brainerd
>  > > Sent: Thursday, April 24, 2008 3:11 PM
>  > > To: C. Scott Ananian
>  > > Cc: [EMAIL PROTECTED]; Michail Bletsas; OLPC Devel
>  > > Subject: Re: A technical assessment of porting "Sugar" to Windows.
>  > >
>  > > Hey Scott, thanks for this.  It's nice to see a clear, unbiased
>  > > analysis of a complex problem.
>  > >
>  > > It shows that there are some clear technical advantages to the
>  > > GNU/Linux stack, while correctly stating that there are options for a
>  > > Windows port which would not be impossible.
>  > >
>  > > I personally can't imagine that the experience would be any better
for
>  > > users, or a good use of OLPC's time and energy, and the apparent cost
>  > > of community goodwill *should not* be underestimated by management.
>  > > But if it means more sales versus the Classmate, a massive donation
>  > > from the Gates foundation, and a large team at Microsoft working on
>  > > the project, it may ultimately be for the best for the children to
>  > > have Windows available as an option on XO (it's an education project,
>  > > not a

Re: (unknown)

[C. Scott Ananian]

On Fri, Apr 25, 2008 at 12:45 PM, Chris Ball <[EMAIL PROTECTED]> wrote:
> Hi,
>
>> The question has come up from Peruvians who bought G1G1 machines:
>> how can we get Sugar to use Spanish, while keeping an English
>> keymap (because G1G1 machines have english keyboards) ?
>
>  I'd edit /home/olpc/.i18n, change it to "es_ES.UTF-8" and restart Sugar.
>  I think there is a more friendly way involving the control panel, too.

I think you need LANG="es.UTF-8" or LANG="es_PE.UTF-8" -- ie, you need
to prefix the setting with LANG= and Spain-spanish is almost certainly
the Wrong Thing to use.
 --scott

-- 
 ( http://cscott.net/ )
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re:

[C. Scott Ananian]

On Fri, Apr 25, 2008 at 12:31 PM, John Watlington <[EMAIL PROTECTED]> wrote:
>
>  The question has come up from Peruvians who bought G1G1 machines:
>  how can we get Sugar to use Spanish, while keeping an English keymap
>  (because G1G1 machines have english keyboards) ?

Bernie's got the canonical answer; I have to look at
/etc/init.d/olpc-configure every time I answer this question.
But IIRC, there is ~olpc/.kbd to set the keyboard map and ~olpc/.i18n
to set the language.  I certainly changed the language of my build
703/C2 while in Brazil (via ~olpc/.i18n) without affecting the
keyboard map.

In anyone knows where this information is on the wiki (or where is
should be), please let me know.
 --scott

-- 
 ( http://cscott.net/ )
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: (unknown)

[Chris Ball]

Hi,

   > The question has come up from Peruvians who bought G1G1 machines:
   > how can we get Sugar to use Spanish, while keeping an English
   > keymap (because G1G1 machines have english keyboards) ?

I'd edit /home/olpc/.i18n, change it to "es_ES.UTF-8" and restart Sugar.
I think there is a more friendly way involving the control panel, too.

- Chris.
-- 
Chris Ball   <[EMAIL PROTECTED]>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

[PATCH] Fix Keep Icon in Journal (Was: Recursive Signal Loop.)

[Eben Eliason]

Well, here's what I've got at present.  It seems to be a worthwhile
cleanup patch even though it doesn't fix the problem I set out to fix.
 It's true that the new Journal designs will eliminate the problem
once we get around to implementing them.  I suppose we'll have to live
with the slow feedback on the favorite buttons in the interim.

- Eben


On Fri, Apr 25, 2008 at 10:55 AM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote:
>
> On Thu, Apr 24, 2008 at 11:37 PM, Eben Eliason <[EMAIL PROTECTED]> wrote:
>  > On Thu, Apr 24, 2008 at 5:25 PM, Bert Freudenberg <[EMAIL PROTECTED]> 
> wrote:
>  >  >
>  >  >
>  >  >  On 24.04.2008, at 22:56, Eben Eliason wrote:
>  >  >
>  >  >
>  >  > > On Thu, Apr 24, 2008 at 4:47 PM, Jameson Chema Quinn
>  >  > > <[EMAIL PROTECTED]> wrote:
>  >  > >
>  >  > > > you check the keep property before you set it, and do not touch it 
> if
>  >  > you
>  >  > > > are not going to change it.
>  >  > > >
>  >  > >
>  >  > > That does in fact sound like a reasonable way to handle it.  It
>  >  > > doesn't require an extra time around "the loop"it simply stops it
>  >  > > directly at the signal handler for the KeepIcon change event by not
>  >  > > overwriting with the same value.  Don't I feel stupid now
>  >  > >
>  >  >
>  >  >
>  >  >  I'd even consider it a bug if overwriting a property with the same 
> value
>  >  > would emit a change event - but maybe this is how the framework works?
>  >
>  >  Good point.  That seems not to be the case.
>  >
>  >  In other news, despite the much cleaner underlying code, my initial
>  >  treatment fails to alleviate the symptom!  It appears that the redraw
>  >  doesn't happen until after all of the signal handling business has run
>  >  its course.  This includes, as mentioned in my first message,
>  >  refreshing the entire view.  I looked at this again, and there is no
>  >  check for the particular CollapsedEntry which changed at all.
>  >  Instead, it loops over each one, refreshing each by setting the
>  >  jobject property of each, which of course resets the keep icon, resets
>  >  the object icon, creates a brand new palette from scratch and attaches
>  >  it to the object icon, looks up and formats the date, reads the list
>  >  of buddies and creates their associated objects and palettes, and a
>  >  number of other smaller tasks.  That's for /each/ entry shown, all
>  >  because one toggle button was clicked!  This seems like serious
>  >  overkill, but I'm not sure if there's an obvious way to isolate the
>  >  changes.  It does seem that, if anything, either the query.py or
>  >  listview.py code should be more intelligent about determining what
>  >  changes are worth doing such comprehensive updates for.  This is not
>  >  one of them.
>  >
>  >  Tomeu, you worked on the query and list code.  Do you have any insight
>  >  into this?
>
>  The lazy programmer that coded this (me) thought that the simple
>  solution implemented was efficient enough and could be written in a
>  simple way with many mainteinance advantages.
>
>  Eben, your new designs will render this code totally obsolete, so
>  what's the point in changing this right now?
>
>  About the signal loop, it's my opinion that most property setting code
>  should only do its thing if the new value is different to the current
>  one. This can affect performance considerably, as well.
>
>  Thanks,
>
>  Tomeu
>
diff --git a/collapsedentry.py b/collapsedentry.py
index c99208a..d365dfa 100644
--- a/collapsedentry.py
+++ b/collapsedentry.py
@@ -118,8 +118,7 @@ class CollapsedEntry(hippo.CanvasBox):
 
 def _create_keep_icon(self):
 keep_icon = KeepIcon(False)
-keep_icon.connect('button-release-event',
-  self._keep_icon_button_release_event_cb)
+keep_icon.connect('notify::keep', self._keep_changed_cb)
 return keep_icon
 
 def _create_date(self):
@@ -223,25 +222,21 @@ class CollapsedEntry(hippo.CanvasBox):
 return self._jobject.metadata.has_key('keep') and \
self._jobject.metadata['keep'] == 1
 
-def _keep_icon_button_release_event_cb(self, button, event):
-logging.debug('_keep_icon_button_release_event_cb')
+def _keep_changed_cb(self, keep_icon, event):
 jobject = datastore.get(self._jobject.object_id)
 try:
-if self.get_keep():
-jobject.metadata['keep'] = 0
-else:
-jobject.metadata['keep'] = 1
-datastore.write(jobject, update_mtime=False)
+if keep_icon.props.keep != jobject.metadata['keep']:
+if keep_icon.props.keep:
+jobject.metadata['keep'] = 1
+else:
+jobject.metadata['keep'] = 0
+datastore.write(jobject, update_mtime=False)
 finally:
 jobject.destroy()
 
-self._keep_icon.props.keep = self.get_keep()
-self._update_color()
-
 return True
 

Re: An olpcfs experience report

[C. Scott Ananian]

On Fri, Apr 25, 2008 at 12:30 PM, Joshua N Pritikin <[EMAIL PROTECTED]> wrote:
> On Fri, Apr 25, 2008 at 12:12:28PM -0400, C. Scott Ananian wrote:
>  > In the current olpcfs1 implementation, all metadata is stored in
>  > Berkeley DB; the actual file contents are stored in a simple
>  > content-addressable store.
>
>  You say "content-addressable store," but what does that mean
>  implementation-wise? Does that mean that OLPCFS hashes the content of
>  the file into a metadata tag when the file is closed?

yes.  the code is not very difficult; you should read it.

>  In particular, I am wondering what happens when I save a movie made with
>  Record (i.e. save a big file). How much additional overhead does OLPCFS
>  add?

Benchmark it.

>  I presume that the file is not copied an additional time. However, does
>  OLPCFS need to read the file again to calculate the hash? If it does,
>  can it (eventually in version 2) do this in the background?

It could update the hash incrementally as the file is written, or any
one of a number of other strategies.
Hashing the entire 1G NAND filesystem takes about two minutes; most of
that is I/O time, not hashing time.  If you hash as you write, you
don't have to pay the I/O time.

>  > If you use BDB correctly, it seems to me to be pretty solid and mature
>  > -- a conclusion which concurs with the long list of BDB users.
>
>  Sure, but BDB would be even more trustworthy if I could 'rm -rf' the
>  database and regenerate it from scratch without losing data. If metadata
>  was stored in POSIX xattrs then it would seem like your design permits
>  this mode of operation.

Yes, it does, but I doubt we'd want to waste precious NAND space on
storing this data redundantly.  Perhaps.

>  I have seen enough instances of "foolproof" databases that I think we
>  should minimize reliance on them.

Yes, certainly I refuse to use GMail because there's a database behind
it.  Or Firefox for that matter.  Or Linux, since it maintains many
internal databases, and they're not even standard well tested
userspace ones!  And don't get me started on resierfs.  Or  ext2.  Or
ext3!
 --scott

-- 
 ( http://cscott.net/ )
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

[no subject]

[John Watlington]

The question has come up from Peruvians who bought G1G1 machines:
how can we get Sugar to use Spanish, while keeping an English keymap
(because G1G1 machines have english keyboards) ?

Please pardon my ignorance...
wad
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: An olpcfs experience report

[Joshua N Pritikin]

On Fri, Apr 25, 2008 at 12:12:28PM -0400, C. Scott Ananian wrote:
> In the current olpcfs1 implementation, all metadata is stored in
> Berkeley DB; the actual file contents are stored in a simple
> content-addressable store.

You say "content-addressable store," but what does that mean 
implementation-wise? Does that mean that OLPCFS hashes the content of 
the file into a metadata tag when the file is closed?

In particular, I am wondering what happens when I save a movie made with 
Record (i.e. save a big file). How much additional overhead does OLPCFS 
add?

I presume that the file is not copied an additional time. However, does 
OLPCFS need to read the file again to calculate the hash? If it does, 
can it (eventually in version 2) do this in the background?

> If you use BDB correctly, it seems to me to be pretty solid and mature 
> -- a conclusion which concurs with the long list of BDB users.

Sure, but BDB would be even more trustworthy if I could 'rm -rf' the 
database and regenerate it from scratch without losing data. If metadata 
was stored in POSIX xattrs then it would seem like your design permits 
this mode of operation.

I have seen enough instances of "foolproof" databases that I think we 
should minimize reliance on them.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: A technical assessment of porting "Sugar" to Windows.

[Jeffrey Kesselman]

>From my POV, Ray?

Anything you can do that is cross platform and open is a great service
to the open source community.

But, with no disrespect intended, some of us have been in the way of
Micrsoft's muscling before and seen how at least the corporate side of
your company is not shy to try to get total control over a market by
controlling the core APIs.  Or to then use that control to muscle out
anything tht doesn't serve Microsoft's financial interests.

I think its this that worries people about a "Windows based" OLPC.  If
Microsoft committed to supporting a completely free and open set of
APIs that were controlled by the community, and not by them.  And to
live within those community decisions, then I don't personally see
anything wrong with a Windows kernel option for the OLPC.

But I'm not sure I believe its within your employer's corporate
culture to do so.

JK

On Fri, Apr 25, 2008 at 12:21 PM, Raymond F. Hayes Jr.
<[EMAIL PROTECTED]> wrote:

>  Say though, I did manage to get something working on all three platforms and
>  put it all back out into the open source community. How does that "limit the
>  freedom" of anyone? It would seem to me that every bit of knowledge and
>  every bit of code contributed to the open source community increases the
>  freedom of everyone.
>
>  Ray
>
>  (to be completely transparent, I do work as a developer for MS though in
>  Group Policy not anything remotely connected to the OS or the kernel or
>  OLPC)
>
>
>  -Original Message-
>  From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
>  [EMAIL PROTECTED]
>
>
> Sent: Friday, April 25, 2008 8:16 AM
>  To: Raymond F. Hayes Jr.
>  Cc: 'OLPC Devel'
>  Subject: RE: A technical assessment of porting "Sugar" to Windows.
>
>
>
>  On Fri, 25 Apr 2008, Raymond F. Hayes Jr. wrote:
>
>  > I've been reading "Cross-Platform Development" in C++ by Syd Logan. It's a
>  > fun read if you like coding for fun. I've got all the source; just want
>  all
>  > the information before I start playing.
>
>  Seems like most everyone involved currently considers this at best a bad
>  idea, but if limiting the freedom of a large chunk of a generation is your
>  idea of fun, go ahead and knock yourself out trying.
>
>  IMHO involving MS in any way is shooting ourselves in the foot.
>
>  >
>  > -Original Message-
>  > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
>  Of
>  > [EMAIL PROTECTED]
>  > Sent: Friday, April 25, 2008 12:55 AM
>  > To: Raymond F. Hayes Jr.
>  > Cc: 'OLPC Devel'
>  > Subject: RE: A technical assessment of porting "Sugar" to Windows.
>  >
>  > why climb aboard a sinking ship, particularly when yours is moving fast...
>  >
>  > On Fri, 25 Apr 2008, Raymond F. Hayes Jr. wrote:
>  >
>  > > These might be stupid questions since I just joined the newsgroup today
>  so
>  > > my apologies in advance but I wasn't able to find an answer on the site.
>  > >
>  > > When you're talking about running Sugar on Windows XP, are you talking
>  > about
>  > > a running the "retail" version of XP or a version of Windows XP Embedded
>  > > with a customized shell as described here:
>  > > http://msdn2.microsoft.com/en-us/library/ms940134.aspx or some special
>  > > version to be decided later on.
>  > >
>  > >
>  > > Ray
>  > >
>  > >
>  > > -Original Message-
>  > > From: [EMAIL PROTECTED]
>  > [mailto:[EMAIL PROTECTED]
>  > > On Behalf Of Wade Brainerd
>  > > Sent: Thursday, April 24, 2008 3:11 PM
>  > > To: C. Scott Ananian
>  > > Cc: [EMAIL PROTECTED]; Michail Bletsas; OLPC Devel
>  > > Subject: Re: A technical assessment of porting "Sugar" to Windows.
>  > >
>  > > Hey Scott, thanks for this.  It's nice to see a clear, unbiased
>  > > analysis of a complex problem.
>  > >
>  > > It shows that there are some clear technical advantages to the
>  > > GNU/Linux stack, while correctly stating that there are options for a
>  > > Windows port which would not be impossible.
>  > >
>  > > I personally can't imagine that the experience would be any better for
>  > > users, or a good use of OLPC's time and energy, and the apparent cost
>  > > of community goodwill *should not* be underestimated by management.
>  > > But if it means more sales versus the Classmate, a massive donation
>  > > from the Gates foundation, and a large team at Microsoft working on
>  > > the project, it may ultimately be for the best for the children to
>  > > have Windows available as an option on XO (it's an education project,
>  > > not a linux project).  It's a calculated risk to be taken by the
>  > > project management.
>  > >
>  > > Anyway, I use tons of open source software every day on Windows XP,
>  > > and the fact that the operating system is closed source (as is the
>  > > processor, motherboard, and video card) doesn't bother me.  It's worth
>  > > noting that I can install a complete KDE environment on my XP machine
>  > > via Cygwin in about 2 hours.  Major OSS projects like QT, Firefox and
>  > > OpenOffice

RE: A technical assessment of porting "Sugar" to Windows.

[Raymond F. Hayes Jr.]

Realistically this is a big project but I do have MAC/PC/Linux platforms to
work with so implementing and testing some of Mr. Logan's methodologies is
interesting. I'm also working with Sparx Systems's Enterprise Architect
which has a roundtrip software engineering feature that supports Python. I'd
like to explore the architecture used in the OLPC XO machine also. There's a
lot to learn and so little time.

Say though, I did manage to get something working on all three platforms and
put it all back out into the open source community. How does that "limit the
freedom" of anyone? It would seem to me that every bit of knowledge and
every bit of code contributed to the open source community increases the
freedom of everyone.

Ray

(to be completely transparent, I do work as a developer for MS though in
Group Policy not anything remotely connected to the OS or the kernel or
OLPC)

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Friday, April 25, 2008 8:16 AM
To: Raymond F. Hayes Jr.
Cc: 'OLPC Devel'
Subject: RE: A technical assessment of porting "Sugar" to Windows.



On Fri, 25 Apr 2008, Raymond F. Hayes Jr. wrote:

> I've been reading "Cross-Platform Development" in C++ by Syd Logan. It's a
> fun read if you like coding for fun. I've got all the source; just want
all
> the information before I start playing.

Seems like most everyone involved currently considers this at best a bad
idea, but if limiting the freedom of a large chunk of a generation is your
idea of fun, go ahead and knock yourself out trying.

IMHO involving MS in any way is shooting ourselves in the foot.

>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of
> [EMAIL PROTECTED]
> Sent: Friday, April 25, 2008 12:55 AM
> To: Raymond F. Hayes Jr.
> Cc: 'OLPC Devel'
> Subject: RE: A technical assessment of porting "Sugar" to Windows.
>
> why climb aboard a sinking ship, particularly when yours is moving fast...
>
> On Fri, 25 Apr 2008, Raymond F. Hayes Jr. wrote:
>
> > These might be stupid questions since I just joined the newsgroup today
so
> > my apologies in advance but I wasn't able to find an answer on the site.
> >
> > When you're talking about running Sugar on Windows XP, are you talking
> about
> > a running the "retail" version of XP or a version of Windows XP Embedded
> > with a customized shell as described here:
> > http://msdn2.microsoft.com/en-us/library/ms940134.aspx or some special
> > version to be decided later on.
> >
> >
> > Ray
> >
> >
> > -Original Message-
> > From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> > On Behalf Of Wade Brainerd
> > Sent: Thursday, April 24, 2008 3:11 PM
> > To: C. Scott Ananian
> > Cc: [EMAIL PROTECTED]; Michail Bletsas; OLPC Devel
> > Subject: Re: A technical assessment of porting "Sugar" to Windows.
> >
> > Hey Scott, thanks for this.  It's nice to see a clear, unbiased
> > analysis of a complex problem.
> >
> > It shows that there are some clear technical advantages to the
> > GNU/Linux stack, while correctly stating that there are options for a
> > Windows port which would not be impossible.
> >
> > I personally can't imagine that the experience would be any better for
> > users, or a good use of OLPC's time and energy, and the apparent cost
> > of community goodwill *should not* be underestimated by management.
> > But if it means more sales versus the Classmate, a massive donation
> > from the Gates foundation, and a large team at Microsoft working on
> > the project, it may ultimately be for the best for the children to
> > have Windows available as an option on XO (it's an education project,
> > not a linux project).  It's a calculated risk to be taken by the
> > project management.
> >
> > Anyway, I use tons of open source software every day on Windows XP,
> > and the fact that the operating system is closed source (as is the
> > processor, motherboard, and video card) doesn't bother me.  It's worth
> > noting that I can install a complete KDE environment on my XP machine
> > via Cygwin in about 2 hours.  Major OSS projects like QT, Firefox and
> > OpenOffice are pushing cross platform development with the aim of
> > greater adoption, I don't see why that's such a bad idea for Sugar.
> >
> > Anyway, it's nice to see the OLPC core people are able to keep level
> > heads and think pragmatically.  Particularly when *you* were the one
> > implicated by Ars Technica as "extremely unhappy with Negroponte's
> > statement and argue that his goals are not technically feasible."
> >
> > Best,
> > Wade
> >
> > On Thu, Apr 24, 2008 at 2:32 PM, C. Scott Ananian <[EMAIL PROTECTED]>
> wrote:
> > > This document will give a technical overview of the challenges facing
> > >  any "Sugar on Windows" project.  Mary Lou Jepson of OLPC was proud of
> > >  the fact that the XO did "seven new things" when most hardware
> > >  projects try to limit themselves to only one "new thing" per product.

Re: A technical assessment of porting "Sugar" to Windows.

[Jeffrey Kesselman]

On Fri, Apr 25, 2008 at 12:15 PM, Jeffrey Kesselman <[EMAIL PROTECTED]> wrote:
> On Fri, Apr 25, 2008 at 12:01 PM, NoiseEHC <[EMAIL PROTECTED]> wrote:
>  > You mean everything that actually calls into GDI.
>
>  Right, my mis-speak.  Given that almost all my interaction with
>  Windows has been through GDI I tend to blur that distinction in my
>  mind.

I should add that Ive also done a fair bit with DirectgX, which also
has major threading issues.

JK
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: A technical assessment of porting "Sugar" to Windows.

[Jeffrey Kesselman]

On Fri, Apr 25, 2008 at 12:01 PM, NoiseEHC <[EMAIL PROTECTED]> wrote:
> You mean everything that actually calls into GDI.

Right, my mis-speak.  Given that almost all my interaction with
Windows has been through GDI I tend to blur that distinction in my
mind.


-- 
~~ Microsoft help desk says: reply hazy, ask again later. ~~
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: An olpcfs experience report

[C. Scott Ananian]

On Fri, Apr 25, 2008 at 10:24 AM, Joshua N Pritikin <[EMAIL PROTECTED]> wrote:
>  I wish I had more time to study the implementation.
>
>  What is stored in Berkeley DB? Only the indexes? The dependency on
>  Berkeley DB makes me nervous. I recall the Subversion Berkeley DB
>  backend suffered from the occational need to recover the database in a
>  non-automatic way.

The current implementation is primarily intended as a
proof-of-concept.  Many of the datastructures would be more-or-less
similar in any implementation, but things like the choice of Berkeley
DB are certainly not fixed.

In the current olpcfs1 implementation, all metadata is stored in
Berkeley DB; the actual file contents are stored in a simple
content-addressable store.

My experience with Berkeley DB is that it is very sensitive to
programming errors.  If you mishandle it, it *will* corrupt your
database, and that will likely require manual intervention.  But if
you use the API properly, BDB seems extremely robust and
fault-tolerant.

My original commits for olpcfs1 used a very complicated multi-index
scheme on some of the databases.  BDB is pretty intolerant of your
mucking around in the secondary indices, especially during iteration.
I certainly had some frustrating BDB experiences during this period.
Upgrading to the latest versions of the BDB bindings made these
problems more transparent to me (since I got failures more directly
correlated with the places I was doing the Bad Things), and eventually
(for other reasons) I switched to a much simpler single-index scheme.
This minimized my ability to inadvertently do things which violated
BDB's API, and BDB has been much happier since.  Reverting to the
'stock' versions of the BDB bindings didn't change BDB's happiness.

So, in summary: I fully understand where the BDB horror stories come
from, but in my (limited) experience the blame is primarily on the
users of the APIs, and secondarily on the BDB documentation, which
doesn't always spell out its intolerance for mucking around with the
secondary indices.  If you use BDB correctly, it seems to me to be
pretty solid and mature -- a conclusion which concurs with the long
list of BDB users.
 --scott

-- 
 ( http://cscott.net/ )
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: A technical assessment of porting "Sugar" to Windows.

[NoiseEHC]

You mean everything that actually calls into GDI. The kernel is fully 
thread safe and preemptive on NT.
Since as I know GTK is thread affine as well, probably it is not a problem.

Jeffrey Kesselman wrote:
> This may be obviosu to everyone, but just a note if it isnt
>
> I have a lot of experience *trying* to tlak Win32 into doing things
> other then its own way from my time in the Sun Java Performance tuning
> team.  Java has a very X inspired window system.  Retting that to run
> reliably on Windows has been a HUGE effort.
>
> The single biggest issue is this: Win32 is not a multi-threaded OS.
> What I mean by that is that, while you can throw off multipel user
> threads, it is *vital* that everything that actually calls into the
> windows kernel happen on a single thread-- the message pump thread.
> Doing anything else is either unstable or outright fails.
>
> Keep this in mind when trying to figure out the work involved in
> making your GUI work on top of it.
> ___
> Devel mailing list
> Devel@lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>
>
>   
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: A technical assessment of porting "Sugar" to Windows.

[Jeffrey Kesselman]

This may be obviosu to everyone, but just a note if it isnt

I have a lot of experience *trying* to tlak Win32 into doing things
other then its own way from my time in the Sun Java Performance tuning
team.  Java has a very X inspired window system.  Retting that to run
reliably on Windows has been a HUGE effort.

The single biggest issue is this: Win32 is not a multi-threaded OS.
What I mean by that is that, while you can throw off multipel user
threads, it is *vital* that everything that actually calls into the
windows kernel happen on a single thread-- the message pump thread.
Doing anything else is either unstable or outright fails.

Keep this in mind when trying to figure out the work involved in
making your GUI work on top of it.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Auto backlight management?

[C. Scott Ananian]

>> On Apr 24, 2008, at 10:39 PM, Frank Ch. Eigler wrote:
>>> Opportunistic use of the on-board camera and the time-of-day clock
>>> could yield such heuristics.

Just for reference, in my mind the best mechanism to do this on the
current hardware would have been to use the battery-status LED "in
reverse" to detect ambient light level:
http://www.merl.com/papers/docs/TR2003-35.pdf.  Unfortunately, all the
display LEDs on our current hardware are behind drive transistors that
make this impractical.  For Gen 2, a simple photocell (or LED wired as
such) would be sufficient to provide proper backlight power management
while preserving privacy.

I have discussed with Chris implementing a hackish "low-power mode" to
demonstrate optimal power management on the Gen 1 hardware to
illustrate the potential of the XO.  Until software catches up, this
would disable USB (hence wireless) and SD to allow sub-200ms resume;
it might be interesting to make this manually-selected mode also do
the camera-as-light-sensor trick to properly manage backlight
intensity.  The goal of this would be to show what battery life is
possible; we could also enable/disable the backlight management
separately to justify (or not) inclusion of a light sensor in Gen 2
hardware.
 --scott

-- 
 ( http://cscott.net/ )
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

RE: A technical assessment of porting "Sugar" to Windows.

[scott]

On Fri, 25 Apr 2008, Raymond F. Hayes Jr. wrote:

> I've been reading "Cross-Platform Development" in C++ by Syd Logan. It's a
> fun read if you like coding for fun. I've got all the source; just want all
> the information before I start playing.

Seems like most everyone involved currently considers this at best a bad
idea, but if limiting the freedom of a large chunk of a generation is your
idea of fun, go ahead and knock yourself out trying.

IMHO involving MS in any way is shooting ourselves in the foot.

>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
> [EMAIL PROTECTED]
> Sent: Friday, April 25, 2008 12:55 AM
> To: Raymond F. Hayes Jr.
> Cc: 'OLPC Devel'
> Subject: RE: A technical assessment of porting "Sugar" to Windows.
>
> why climb aboard a sinking ship, particularly when yours is moving fast...
>
> On Fri, 25 Apr 2008, Raymond F. Hayes Jr. wrote:
>
> > These might be stupid questions since I just joined the newsgroup today so
> > my apologies in advance but I wasn't able to find an answer on the site.
> >
> > When you're talking about running Sugar on Windows XP, are you talking
> about
> > a running the "retail" version of XP or a version of Windows XP Embedded
> > with a customized shell as described here:
> > http://msdn2.microsoft.com/en-us/library/ms940134.aspx or some special
> > version to be decided later on.
> >
> >
> > Ray
> >
> >
> > -Original Message-
> > From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> > On Behalf Of Wade Brainerd
> > Sent: Thursday, April 24, 2008 3:11 PM
> > To: C. Scott Ananian
> > Cc: [EMAIL PROTECTED]; Michail Bletsas; OLPC Devel
> > Subject: Re: A technical assessment of porting "Sugar" to Windows.
> >
> > Hey Scott, thanks for this.  It's nice to see a clear, unbiased
> > analysis of a complex problem.
> >
> > It shows that there are some clear technical advantages to the
> > GNU/Linux stack, while correctly stating that there are options for a
> > Windows port which would not be impossible.
> >
> > I personally can't imagine that the experience would be any better for
> > users, or a good use of OLPC's time and energy, and the apparent cost
> > of community goodwill *should not* be underestimated by management.
> > But if it means more sales versus the Classmate, a massive donation
> > from the Gates foundation, and a large team at Microsoft working on
> > the project, it may ultimately be for the best for the children to
> > have Windows available as an option on XO (it's an education project,
> > not a linux project).  It's a calculated risk to be taken by the
> > project management.
> >
> > Anyway, I use tons of open source software every day on Windows XP,
> > and the fact that the operating system is closed source (as is the
> > processor, motherboard, and video card) doesn't bother me.  It's worth
> > noting that I can install a complete KDE environment on my XP machine
> > via Cygwin in about 2 hours.  Major OSS projects like QT, Firefox and
> > OpenOffice are pushing cross platform development with the aim of
> > greater adoption, I don't see why that's such a bad idea for Sugar.
> >
> > Anyway, it's nice to see the OLPC core people are able to keep level
> > heads and think pragmatically.  Particularly when *you* were the one
> > implicated by Ars Technica as "extremely unhappy with Negroponte's
> > statement and argue that his goals are not technically feasible."
> >
> > Best,
> > Wade
> >
> > On Thu, Apr 24, 2008 at 2:32 PM, C. Scott Ananian <[EMAIL PROTECTED]>
> wrote:
> > > This document will give a technical overview of the challenges facing
> > >  any "Sugar on Windows" project.  Mary Lou Jepson of OLPC was proud of
> > >  the fact that the XO did "seven new things" when most hardware
> > >  projects try to limit themselves to only one "new thing" per product.
> > >  I will outline the "new things" which the XO system intends to
> > >  accomplish, and discuss the feasibility of each of them if/when
> > >  reimplemented on a Windows substrate.
> > >
> > >  I will start by addressing nomenclature.  What do we mean when we say
> > >  "Sugar"?  Is it the activities?  The zooming UI interface?  The
> > >  complete system?  What do we mean when we say "Sugar on Windows"?
> > >
> > >  For this document, I will assume that "Sugar" means the "new things"
> > >  which are goals of the XO system.  As we will see, some of these "new
> > >  things" as easy to accomplish, regardless of underlying operating
> > >  system, while others are extremely difficult or impossible.  Clearly,
> > >  what is meant by "Sugar on Windows" is that some subset of the "new
> > >  things" will be implemented on a Windows platform.  It is up to those
> > >  who argue for "Sugar on Windows" to be clear about which of these "new
> > >  things" they intend to accomplish; the costs and benefits of "Sugar on
> > >  Windows" critically depend on this definition.
> > >
> > >  I will present 12 items which comprise the cur

Re: A technical assessment of porting "Sugar" to Windows.

[Aaron Konstam]

Below is exactly my attitude about getting in Bed with Microsoft. They
are not in the business of helping to distribute OPEN Software.

On Thu, 2008-04-24 at 15:00 -0700, Edward Cherlin wrote:
> Thanks, Scott, for taking us away from the direction of flamage to
> many of the real issues. I have nothing to add about the difficulty of
> the actual technical issues that you discuss, but I have some comments
> on the significance of the technical issues for corporate strategy and
> marketing.
> 
> The first point here is that the Windows kernel and API work can only
> be done by Microsoft itself (details in Scott's message snipped). I
> would argue that OLPC should leave all of the Sugar on Windows work to
> Microsoft (except for GPL audits), unless we get the kind of financial
> commitment from Microsoft that Red Hat and others have made. In that
> case, we could discuss it, but I still wouldn't automatically agree to
> it. I would also consider, as an example, trading a seat on OLPC's
> board for seats on the boards of both Microsoft and The Gates
> Foundation. If the proposed contract is published in advance and
> passes public scrutiny. Maybe.
> 
> But consider the effects of GPL auditing of Microsoft Windows kernel
> software, or rather the implications of Microsoft using any GPLed
> software in its kernel. I don't see any chance of it, which means that
> Microsoft will have to reimplement everything. And we would still want
> to do the audits to make sure that nobody cheats. Given Microsoft's
> ferocious opposition even to escrowing Windows source code that nobody
> should ever need to look at, I don't see an audit happening. In which
> case I don't see Sugar on Windows happening, and especially not Sugar
> on XP/XO.
> 
> It's funny. Before the IBM PC and PC/MS DOS, Microsoft took out ads
> saying, "Microsoft is pleased to announce that there will be no 16-bit
> software crisis." That was about their original AT&T Unix license,
> which they later spun off to The Santa Cruz Operation (not in any way
> the current SCO). But now we are actually having a 64-bit software
> crisis and an XO software crisis. Welcome to the future.
> 
> On Thu, Apr 24, 2008 at 11:32 AM, C. Scott Ananian <[EMAIL PROTECTED]> wrote:
> > This document will give a technical overview of the challenges facing
> >  any "Sugar on Windows" project.  Mary Lou Jepson of OLPC was proud of
> >  the fact that the XO did "seven new things" when most hardware
> >  projects try to limit themselves to only one "new thing" per product.
> >  I will outline the "new things" which the XO system intends to
> >  accomplish, and discuss the feasibility of each of them if/when
> >  reimplemented on a Windows substrate.
> >
> >  I will start by addressing nomenclature.  What do we mean when we say
> >  "Sugar"?  Is it the activities?  The zooming UI interface?  The
> >  complete system?  What do we mean when we say "Sugar on Windows"?
> >
> >  For this document, I will assume that "Sugar" means the "new things"
> 
> Understood.
> 
> >  3. Window manager: Mesh/Friend/Home view, frame, etc.
> >
> >  This is a more difficult task than merely porting the standalone
> >  activities; this feature entails replacing the existing Windows file
> >  and application chooser mechanisms with ones which mimic that of
> >  Sugar/GNU/Linux.
> 
> Augmenting, I think you mean, rather than replacing? But we know what
> you are talking about.
> 
> >  It is possible to imagine Sugar/Windows without a fully-functioning
> >  datastore implementation.  It is likely that the Journal in such a
> >  port would be replaced by a Windows Explorer window which
> >  would allow straightforward manipulation of files using the
> >  traditional metaphor.
> 
> Some people love the journal, and some hate it. I assume that they
> would evaluate this possibility differently. I like the Journal in
> principle, but it needs a lot more work. Basically, it doesn't scale
> to a year's work or more yet. If the children like it, then not having
> it can be a deal-breaker. I know lots of people who hate hierarchical
> file systems because they don't know where to put things or how to
> find them again.
> 
> >  5. Collaboration.
> >
> >  Note that this feature is distinct from mesh networking (item #6
> >  below).  Collaboration is simply implementing the APIs used by activity
> >  authors to "share" activities, and the corresponding features in the
> >  UI (item #3) which allow users to find friends and shared documents
> >  and publish or join shared activities.
> 
> Right. All of this works over ordinary Internet and local networks, so
> it does not affect decision-making for us or Microsoft. Unless they
> decide to go for obfuscation of these distinctions in their marketing.
> 
> >  6. Mesh networking.
> >
> >  Aside from collaboration, the XO also supports 802.11s mesh
> >  networking.  I have been told that the basic driver support for the
> >  Marvell device we are using has been ported to Windows

RE: A technical assessment of porting "Sugar" to Windows.

[Raymond F. Hayes Jr.]

I've been reading "Cross-Platform Development" in C++ by Syd Logan. It's a
fun read if you like coding for fun. I've got all the source; just want all
the information before I start playing.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Friday, April 25, 2008 12:55 AM
To: Raymond F. Hayes Jr.
Cc: 'OLPC Devel'
Subject: RE: A technical assessment of porting "Sugar" to Windows.

why climb aboard a sinking ship, particularly when yours is moving fast...

On Fri, 25 Apr 2008, Raymond F. Hayes Jr. wrote:

> These might be stupid questions since I just joined the newsgroup today so
> my apologies in advance but I wasn't able to find an answer on the site.
>
> When you're talking about running Sugar on Windows XP, are you talking
about
> a running the "retail" version of XP or a version of Windows XP Embedded
> with a customized shell as described here:
> http://msdn2.microsoft.com/en-us/library/ms940134.aspx or some special
> version to be decided later on.
>
>
> Ray
>
>
> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
> On Behalf Of Wade Brainerd
> Sent: Thursday, April 24, 2008 3:11 PM
> To: C. Scott Ananian
> Cc: [EMAIL PROTECTED]; Michail Bletsas; OLPC Devel
> Subject: Re: A technical assessment of porting "Sugar" to Windows.
>
> Hey Scott, thanks for this.  It's nice to see a clear, unbiased
> analysis of a complex problem.
>
> It shows that there are some clear technical advantages to the
> GNU/Linux stack, while correctly stating that there are options for a
> Windows port which would not be impossible.
>
> I personally can't imagine that the experience would be any better for
> users, or a good use of OLPC's time and energy, and the apparent cost
> of community goodwill *should not* be underestimated by management.
> But if it means more sales versus the Classmate, a massive donation
> from the Gates foundation, and a large team at Microsoft working on
> the project, it may ultimately be for the best for the children to
> have Windows available as an option on XO (it's an education project,
> not a linux project).  It's a calculated risk to be taken by the
> project management.
>
> Anyway, I use tons of open source software every day on Windows XP,
> and the fact that the operating system is closed source (as is the
> processor, motherboard, and video card) doesn't bother me.  It's worth
> noting that I can install a complete KDE environment on my XP machine
> via Cygwin in about 2 hours.  Major OSS projects like QT, Firefox and
> OpenOffice are pushing cross platform development with the aim of
> greater adoption, I don't see why that's such a bad idea for Sugar.
>
> Anyway, it's nice to see the OLPC core people are able to keep level
> heads and think pragmatically.  Particularly when *you* were the one
> implicated by Ars Technica as "extremely unhappy with Negroponte's
> statement and argue that his goals are not technically feasible."
>
> Best,
> Wade
>
> On Thu, Apr 24, 2008 at 2:32 PM, C. Scott Ananian <[EMAIL PROTECTED]>
wrote:
> > This document will give a technical overview of the challenges facing
> >  any "Sugar on Windows" project.  Mary Lou Jepson of OLPC was proud of
> >  the fact that the XO did "seven new things" when most hardware
> >  projects try to limit themselves to only one "new thing" per product.
> >  I will outline the "new things" which the XO system intends to
> >  accomplish, and discuss the feasibility of each of them if/when
> >  reimplemented on a Windows substrate.
> >
> >  I will start by addressing nomenclature.  What do we mean when we say
> >  "Sugar"?  Is it the activities?  The zooming UI interface?  The
> >  complete system?  What do we mean when we say "Sugar on Windows"?
> >
> >  For this document, I will assume that "Sugar" means the "new things"
> >  which are goals of the XO system.  As we will see, some of these "new
> >  things" as easy to accomplish, regardless of underlying operating
> >  system, while others are extremely difficult or impossible.  Clearly,
> >  what is meant by "Sugar on Windows" is that some subset of the "new
> >  things" will be implemented on a Windows platform.  It is up to those
> >  who argue for "Sugar on Windows" to be clear about which of these "new
> >  things" they intend to accomplish; the costs and benefits of "Sugar on
> >  Windows" critically depend on this definition.
> >
> >  I will present 12 items which comprise the current XO system.  Most of
> >  these are implemented to some degree on the current GNU/Linux-based
> >  stack ("Sugar/GNU/Linux"), although several of them are
> >  works-in-progress.  For each I will attempt a rough measure of the
> >  difficulty of porting or reimplementing this feature on a
> >  Windows-based stack ("Sugar/Windows").
> >
> >
> >  1. Sugar design guidelines.
> >
> >  In this minimal "Sugar on Windows" proposal, the only thing common
> >  between Sugar/GNU/Linux and Sugar/Windows are the 

Re: [sugar] Recursive Signal Loop.

[Tomeu Vizoso]

On Thu, Apr 24, 2008 at 11:37 PM, Eben Eliason <[EMAIL PROTECTED]> wrote:
> On Thu, Apr 24, 2008 at 5:25 PM, Bert Freudenberg <[EMAIL PROTECTED]> wrote:
>  >
>  >
>  >  On 24.04.2008, at 22:56, Eben Eliason wrote:
>  >
>  >
>  > > On Thu, Apr 24, 2008 at 4:47 PM, Jameson Chema Quinn
>  > > <[EMAIL PROTECTED]> wrote:
>  > >
>  > > > you check the keep property before you set it, and do not touch it if
>  > you
>  > > > are not going to change it.
>  > > >
>  > >
>  > > That does in fact sound like a reasonable way to handle it.  It
>  > > doesn't require an extra time around "the loop"it simply stops it
>  > > directly at the signal handler for the KeepIcon change event by not
>  > > overwriting with the same value.  Don't I feel stupid now
>  > >
>  >
>  >
>  >  I'd even consider it a bug if overwriting a property with the same value
>  > would emit a change event - but maybe this is how the framework works?
>
>  Good point.  That seems not to be the case.
>
>  In other news, despite the much cleaner underlying code, my initial
>  treatment fails to alleviate the symptom!  It appears that the redraw
>  doesn't happen until after all of the signal handling business has run
>  its course.  This includes, as mentioned in my first message,
>  refreshing the entire view.  I looked at this again, and there is no
>  check for the particular CollapsedEntry which changed at all.
>  Instead, it loops over each one, refreshing each by setting the
>  jobject property of each, which of course resets the keep icon, resets
>  the object icon, creates a brand new palette from scratch and attaches
>  it to the object icon, looks up and formats the date, reads the list
>  of buddies and creates their associated objects and palettes, and a
>  number of other smaller tasks.  That's for /each/ entry shown, all
>  because one toggle button was clicked!  This seems like serious
>  overkill, but I'm not sure if there's an obvious way to isolate the
>  changes.  It does seem that, if anything, either the query.py or
>  listview.py code should be more intelligent about determining what
>  changes are worth doing such comprehensive updates for.  This is not
>  one of them.
>
>  Tomeu, you worked on the query and list code.  Do you have any insight
>  into this?

The lazy programmer that coded this (me) thought that the simple
solution implemented was efficient enough and could be written in a
simple way with many mainteinance advantages.

Eben, your new designs will render this code totally obsolete, so
what's the point in changing this right now?

About the signal loop, it's my opinion that most property setting code
should only do its thing if the new value is different to the current
one. This can affect performance considerably, as well.

Thanks,

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

Re: Better anti-aliasing

[Bert Freudenberg]

On 25.04.2008, at 16:02, Paul Fox wrote:

> bert wrote:
>>
>> On 25.04.2008, at 15:07, Paul Fox wrote:
>>> unlike a traditional display, every pixel has a single color.
>>> given this, it seems wrong to talk about the "red channel of the
>>> first pixel".  you either use some of that pixel, or you don't.
>>> in effect, the display is implementing sub-(full-color-)pixel
>>> rendering all by itself.  (which i think is what bert was saying,
>>> but the "channel" thing confused me.)
>>
>> In the display memory (a.k.a. framebuffer), each pixel has a red  
>> and a
>> green and a blue value. I called these components "channel", which is
>> not entirely correct. Still, the DCON selects only the red component
>> of a framebuffer pixel to be displayed for a red physical pixel, the
>
> ah!  the missing piece.  thanks.  i was so focused on the display  
> itself
> that i'd never worked backwards to think about it from the
> perspective of the framebuffer.

great :)

>> value of the green and blue components do not matter. If the 5-tap
>> antialising filter is enabled, then the 4 adjacent pixel's red
>> components are averaged, and mixed with the center pixel's red
>> component. Again, the green and blue components are ignored, hence I
>> spoke of "selecting". Makes sense?
>
> yes.
>
>>
>>> with the backlight off, this doesn't matter -- all pixels are the
>>> same color anyway.  but with the backlight on in monochrome mode,
>>> you see a lot of color in single-pixel-width lines.  if the line
>>> is perfectly aligned with the diagonal of the pixels, it will be
>>> completely colored (i just tried it), but mostly you just get a
>>> lesser or stronger fringing effect.
>>>
>>> for backlit ebook mode, this might not matter so much, since ebooks
>>> might not have a lot of diagonal single-pixel-width lines, but the
>>> effect is definitely there.
>>
>>
>> But it is greatly diminished by the antialiasing hardware filter. See
>> if reading
>>
>>  http://wiki.laptop.org/go/Display
>>
>> clears things up. With "selecting the red channel" I meant the DCON
>> "swizzling" as described on that page.
>
> yes, i see.
>
> since this sub-topic came up in the context of using the
> backlight in e-book (monochrome) mode, are you saying that the
> unimplemented "swizzled not antialiased" mode would be better
> than either of the two modes currently available ("monochrome"
> and "swizzled antialiased")?


Oh, I was not suggesting one mode was better than another. Ben brought  
up the "better aa" discussion again. The "swizzled not aa" mode would  
be needed to experiment in that direction. IMHO the display is great  
as it is, I find text highly readable even in color with aa.

That said, the available monochrome-with-backlight-no-aa mode is  
slightly more crisp, so for an ebook reader some people might prefer  
it. You get more visible color fringes though, and for my taste the  
edges are too jagged. But then I am used to Apple's font antialiasing  
which others find too blurry, they prefer FreeType's and ClearType's  
crispness. I could counter that with Alvy-Ray's "A Pixel Is NOT A  
Little Square" chanting which would get us soon into the whole Nyquist– 
Shannon sampling theory discussion, but I'll stop here ;)

- Bert -


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

Re: An olpcfs experience report

[Joshua N Pritikin]

On Fri, Apr 25, 2008 at 10:25:53AM +0200, Bert Freudenberg wrote:
> On 25.04.2008, at 04:05, Michael Stone wrote:
> > [1]: http://wiki.laptop.org/go/Olpcfs
> 
> This is not a technical assessment, but I like the olpcfs idea.

I like it too.

I wish I had more time to study the implementation.

What is stored in Berkeley DB? Only the indexes? The dependency on 
Berkeley DB makes me nervous. I recall the Subversion Berkeley DB 
backend suffered from the occational need to recover the database in a 
non-automatic way.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Better anti-aliasing

[Paul Fox]

bert wrote:
 > 
 > On 25.04.2008, at 15:07, Paul Fox wrote:
 > > unlike a traditional display, every pixel has a single color.
 > > given this, it seems wrong to talk about the "red channel of the
 > > first pixel".  you either use some of that pixel, or you don't.
 > > in effect, the display is implementing sub-(full-color-)pixel
 > > rendering all by itself.  (which i think is what bert was saying,
 > > but the "channel" thing confused me.)
 > 
 > In the display memory (a.k.a. framebuffer), each pixel has a red and a  
 > green and a blue value. I called these components "channel", which is  
 > not entirely correct. Still, the DCON selects only the red component  
 > of a framebuffer pixel to be displayed for a red physical pixel, the  

ah!  the missing piece.  thanks.  i was so focused on the display itself
that i'd never worked backwards to think about it from the
perspective of the framebuffer.

 > value of the green and blue components do not matter. If the 5-tap  
 > antialising filter is enabled, then the 4 adjacent pixel's red  
 > components are averaged, and mixed with the center pixel's red  
 > component. Again, the green and blue components are ignored, hence I  
 > spoke of "selecting". Makes sense?

yes.

 > 
 > > with the backlight off, this doesn't matter -- all pixels are the
 > > same color anyway.  but with the backlight on in monochrome mode,
 > > you see a lot of color in single-pixel-width lines.  if the line
 > > is perfectly aligned with the diagonal of the pixels, it will be
 > > completely colored (i just tried it), but mostly you just get a
 > > lesser or stronger fringing effect.
 > >
 > > for backlit ebook mode, this might not matter so much, since ebooks
 > > might not have a lot of diagonal single-pixel-width lines, but the
 > > effect is definitely there.
 > 
 > 
 > But it is greatly diminished by the antialiasing hardware filter. See  
 > if reading
 > 
 >  http://wiki.laptop.org/go/Display
 > 
 > clears things up. With "selecting the red channel" I meant the DCON  
 > "swizzling" as described on that page.

yes, i see.

since this sub-topic came up in the context of using the
backlight in e-book (monochrome) mode, are you saying that the
unimplemented "swizzled not antialiased" mode would be better
than either of the two modes currently available ("monochrome"
and "swizzled antialiased")?

paul
=-
 paul fox, [EMAIL PROTECTED] (arlington, ma, where it's 70.7 degrees)
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Better anti-aliasing

[Benjamin M. Schwartz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Bert Freudenberg wrote:
| One thing that someone (Albert IIRC) proposed was doing a better
| filtering job than the DCON does - it uses a simple 5-tap filter which
| adds a noticeable amount of blur. It is still vital to do filtering,
| otherwise a single red pixel surrounded by black background that
| happens to fall on a blue physical pixel would not be seen at all, the
| filter ensures that at least half of its energy is distributed to the
| adjacent red physical pixels. Or a single white pixel would appear
| colored.

This is precisely what I was talking about.  Actually, it is possible to
go one step further than improved filtering, and alter the contents of the
display in response to the precise subpixel layout.  This is essentially
what subpixel font rendering does.  It not only uses a many-tap filter to
avoid local colorations, but also rerenders the fonts with a hinting
scheme that is sensitive both to their subpixel alignment and to the
filter that is about to be applied.

Currently, the caps and feet on serif characters might be rendered as a
single pixel, which is then blurred out by the deswizzling filter.  If the
font renderer were aware of this, it might be made to alter its rendering
to increase the size of caps and feet.

As I said before, I do not think this is important, useful, or likely to
happen.  It is, however, a fun exercise: if your software knew in advance
which channel was actually going to be displayed at each pixel, what would
its optimal strategy be?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIEeOIUJT6e6HFtqQRAkenAJ9FKAvOqutjFJOA/LQ6vIjID60S9QCfbAe3
fniOgX8yCdyFNU/iZy4AqZ0=
=q459
-END PGP SIGNATURE-
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Better anti-aliasing

[Bert Freudenberg]

On 25.04.2008, at 15:07, Paul Fox wrote:

> bert wrote:
>>
>> There is no need for "fancy color-adaptive subpixel rendering". The
>> framebuffer with its 1200x900 resolution maps 1:1 to physical display
>> pixels. The DCON simply selects the red channel of the first pixel,
>> and the green of the second, and the blue of the third, and so on.
>> This does not affect pixel geometry. Thus normal full-pixel anti-
>> aliased software rendering will do The Right Thing.
>
> i think there's something odd with this description.  (and, as
> someone who has clearly been confused about the display for some
> time, i'd like to be sure i understand.)
>
> unlike a traditional display, every pixel has a single color.
> given this, it seems wrong to talk about the "red channel of the
> first pixel".  you either use some of that pixel, or you don't.
> in effect, the display is implementing sub-(full-color-)pixel
> rendering all by itself.  (which i think is what bert was saying,
> but the "channel" thing confused me.)

In the display memory (a.k.a. framebuffer), each pixel has a red and a  
green and a blue value. I called these components "channel", which is  
not entirely correct. Still, the DCON selects only the red component  
of a framebuffer pixel to be displayed for a red physical pixel, the  
value of the green and blue components do not matter. If the 5-tap  
antialising filter is enabled, then the 4 adjacent pixel's red  
components are averaged, and mixed with the center pixel's red  
component. Again, the green and blue components are ignored, hence I  
spoke of "selecting". Makes sense?

> with the backlight off, this doesn't matter -- all pixels are the
> same color anyway.  but with the backlight on in monochrome mode,
> you see a lot of color in single-pixel-width lines.  if the line
> is perfectly aligned with the diagonal of the pixels, it will be
> completely colored (i just tried it), but mostly you just get a
> lesser or stronger fringing effect.
>
> for backlit ebook mode, this might not matter so much, since ebooks
> might not have a lot of diagonal single-pixel-width lines, but the
> effect is definitely there.


But it is greatly diminished by the antialiasing hardware filter. See  
if reading

http://wiki.laptop.org/go/Display

clears things up. With "selecting the red channel" I meant the DCON  
"swizzling" as described on that page.


Btw, could someone replace the wrong close-up:

http://wiki.laptop.org/go/Image:LCD-olpc.png

This illustrates MLJ's "color by refraction" idea but does not  
represent the actually shipping color filters. The image at wikipedia  
is much nicer:

http://en.wikipedia.org/wiki/Image:XO_screen_01_Pengo.jpg

- Bert -


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

Re: Potential Rainbow changes for #6797 and improved compatibility.

[Tomeu Vizoso]

On Fri, Apr 25, 2008 at 1:42 AM, Michael Stone <[EMAIL PROTECTED]> wrote:
> Friends,
>
>  Pursuant to issues raised in #6797, I'm trying to figure out whether the
>  module-preloading hack can be chivvied into a releasable state.  Having
>  written several tentative patches to this effect, I've decided that I
>  might as well christen the code-review [1,2,3] list that Ivan set in his
>  last days here. (As I understand it, the idea was that we should really
>  be soliciting reviews on all our code [Sugar team++] but that the
>  envisioned patch volume might make devel@ too hard to follow.)
>
>  Please comment.
>
>  Michael
>
>  [1]: http://lists.laptop.org/listinfo/code-review
>  [2]: http://lists.laptop.org/pipermail/code-review/2008-April/thread.html
>  [3]: [EMAIL PROTECTED]

Fine with the code review thing. About that particular bug, which
options do we have other than patching gtk to not connect to X on
import (or not to stacktrace, like in ubuntu)?

Thanks,

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

Re: Auto backlight management?

[John Watlington]

On Apr 25, 2008, at 8:41 AM, Carl-Daniel Hailfinger wrote:

> On 25.04.2008 06:25, Ivan Krstić wrote:
>> On Apr 24, 2008, at 10:39 PM, Frank Ch. Eigler wrote:
>>
>>> Opportunistic use of the on-board camera and the time-of-day clock
>>> could yield such heuristics.
>>>
>>
>>
>> The camera lights up an LED when enabled, alerting the laptop  
>> operator
>> to its use. This privacy-preserving feature would be rendered
>> ineffective if kids got used to seeing the LED flash on and off every
>> so often as the system autonomously attempts to adjust the backlight.
>>
>
>
> Is there a "warning time" period from activating the LED to activating
> the camera? Just that when someone works in front of the laptop,  
> can he
> simply close it fast enough when the camera light goes on  
> unexpectedly?

No.  There is some integrating of the "camera on" signal, so that  
turning it
on for a single frame should ensure a visible flash, but this has the
opposite effect...

wad

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

Re: Better anti-aliasing

[Paul Fox]

bert wrote:
 > 
 > There is no need for "fancy color-adaptive subpixel rendering". The  
 > framebuffer with its 1200x900 resolution maps 1:1 to physical display  
 > pixels. The DCON simply selects the red channel of the first pixel,  
 > and the green of the second, and the blue of the third, and so on.  
 > This does not affect pixel geometry. Thus normal full-pixel anti- 
 > aliased software rendering will do The Right Thing.

i think there's something odd with this description.  (and, as
someone who has clearly been confused about the display for some
time, i'd like to be sure i understand.)

unlike a traditional display, every pixel has a single color. 
given this, it seems wrong to talk about the "red channel of the
first pixel".  you either use some of that pixel, or you don't. 
in effect, the display is implementing sub-(full-color-)pixel
rendering all by itself.  (which i think is what bert was saying,
but the "channel" thing confused me.)

with the backlight off, this doesn't matter -- all pixels are the
same color anyway.  but with the backlight on in monochrome mode,
you see a lot of color in single-pixel-width lines.  if the line
is perfectly aligned with the diagonal of the pixels, it will be
completely colored (i just tried it), but mostly you just get a
lesser or stronger fringing effect.

for backlit ebook mode, this might not matter so much, since ebooks
might not have a lot of diagonal single-pixel-width lines, but the
effect is definitely there.

paul
=-
 paul fox, [EMAIL PROTECTED] (arlington, ma, where it's 58.3 degrees)
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Auto backlight management?

[Carl-Daniel Hailfinger]

On 25.04.2008 06:25, Ivan Krstić wrote:
> On Apr 24, 2008, at 10:39 PM, Frank Ch. Eigler wrote:
>   
>> Opportunistic use of the on-board camera and the time-of-day clock
>> could yield such heuristics.
>> 
>
>
> The camera lights up an LED when enabled, alerting the laptop operator  
> to its use. This privacy-preserving feature would be rendered  
> ineffective if kids got used to seeing the LED flash on and off every  
> so often as the system autonomously attempts to adjust the backlight.
>   


Is there a "warning time" period from activating the LED to activating
the camera? Just that when someone works in front of the laptop, can he
simply close it fast enough when the camera light goes on unexpectedly?


Regards,
Carl-Daniel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

boot problem

[Daly Ikbel]

I try to copy a repositery of 258Mb.
I get an error of lack of space.
while rebooting I get this message:

"OSError: [Errno 28] No space left on device "

and the XO freeze.

Any help?

best regards
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Auto backlight management?

[karl]

Bert Freudenberg wrote:
> On 25.04.2008, at 10:46, Martin Dengler wrote:
>
>   
>> On Fri, Apr 25, 2008 at 12:07:12AM -0400, Eben Eliason wrote:
>> 
>>> On Thu, Apr 24, 2008 at 10:43 PM, John Watlington <[EMAIL PROTECTED]>  
>>> wrote:
>>>   
 Bert misread the spec.  When the backlight is switched off, the  
 screen
 automatically switches to B&W mode.   Why would you want to take
 that out of the control of the user ?
 
>>> It's clear to me that it would be quite useful to have a
>>> bright backlight AND black & white mode for reading a book at night,
>>> for instance, and this isn't possible in the current UI.
>>>   
>> The camera could be checked once when the device went into/out of  
>> ebook mode
>> and the backlight changed appropriately.
>> 
>
>
> Malicious software also could snap a picture of the user at that  
> moment. This is the privacy issue that Ivan mentioned, and I agree, we  
> cannot use a camera image for this.
>
> What I suggested before, but which was not practicable, would be some  
> "passive" readout-hardware in the camera that only reports a single  
> brightness value. But I was told the current design would require to  
> power the camera on for that. And in a new hardware design it may be  
> cheaper and better to add a photo sensor than this.
>
> The biggest benefit I see from adding this is power savings. The  
> backlight should be automatically turned off when there is enough  
> ambient light, to save power. Switching it back on could easily be  
> done by the user (or automatically for convenience).
Hey, why not let the kids build this them self ? Here is a DIY light 
sensor project:
http://www.evilmadscientist.com/article.php/nightlight

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

Re: Auto backlight management?

[Martin Dengler]

On Fri, Apr 25, 2008 at 09:47:29AM +0100, Martin Dengler wrote:
> On Thu, Apr 24, 2008 at 10:54:34PM -0700, [EMAIL PROTECTED] wrote:
> > my machines are out on loan right now. is this monochrome mode the 
> > high-res mode, or is this still using multiple screen pixels per display 
> > pixel like color does? (or another way to put it, does the screen get much 
> > sharper when you do this?)
> 
> It's the high res mode.  It looks really nice.

I stand corrected.  Doing

echo 0 > /sys/devices/platform/dcon/output

with the backlight off does make displayed text look blurrier to me,
though.

> > David Lang
> 
> Martin

Martin

PS: might save people looking it up:
 http://wiki.laptop.org/go/DCON#.2Fsys.2Fdevices.2Fplatform.2Fdcon.2Foutput
 http://wiki.laptop.org/go/Display#The_theory
 http://wiki.laptop.org/go/Display#DCON_screen_driver_chip





pgpDh8WzgLfdQ.pgp
Description: PGP signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Auto backlight management?

[Martin Dengler]

On Fri, Apr 25, 2008 at 11:05:10AM +0200, Bert Freudenberg wrote:
>
> On 25.04.2008, at 10:46, Martin Dengler wrote:
>
> >On Fri, Apr 25, 2008 at 12:07:12AM -0400, Eben Eliason wrote:
> >>It's clear to me that it would be quite useful to have a bright
> >>backlight AND black & white mode for reading a book at night, for
> >>instance, and this isn't possible in the current UI.
> >
> >The camera could be checked once when the device went into/out of
> >ebook mode and the backlight changed appropriately.
>
> Malicious software also could snap a picture of the user at that
> moment. This is the privacy issue that Ivan mentioned, and I agree,
> we cannot use a camera image for this.

Well sure...but it seems to raise slightly different concerns:
activating the camera when switching to/from ebook mode would be 1)
infrequent; and 2) in response to user action.  That seems quite
different from activating the camera frequently enough to set the
backlight during normal, interactive use, and not in response to any
specific user action.

For my personal use case, if someone manages to get me to install an
activity that gets an up-nose picture of me without my knowledge, only
when the back of the screen has hit/left the keyboard top, but my
backlight goes off/on if it's dark/light, that'd still work for me.
I'll send the patch around if I get to it without any expectation
it'll get merged.

> What I suggested before, but which was not practicable, would be
> some "passive" readout-hardware in the camera that only reports a
> single brightness value. But I was told the current design would
> require to power the camera on for that. And in a new hardware
> design it may be cheaper and better to add a photo sensor than this.

The activities/projects made possible with a light sensor / the
information you describe are very cool.

> - Bert -

Martin


pgpZe0NkBw9Tn.pgp
Description: PGP signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Auto backlight management?

[Bert Freudenberg]

On 25.04.2008, at 10:46, Martin Dengler wrote:

> On Fri, Apr 25, 2008 at 12:07:12AM -0400, Eben Eliason wrote:
>> On Thu, Apr 24, 2008 at 10:43 PM, John Watlington <[EMAIL PROTECTED]>  
>> wrote:
>>>
>>> Bert misread the spec.  When the backlight is switched off, the  
>>> screen
>>> automatically switches to B&W mode.   Why would you want to take
>>> that out of the control of the user ?
>>
>> It's clear to me that it would be quite useful to have a
>> bright backlight AND black & white mode for reading a book at night,
>> for instance, and this isn't possible in the current UI.
>
> The camera could be checked once when the device went into/out of  
> ebook mode
> and the backlight changed appropriately.


Malicious software also could snap a picture of the user at that  
moment. This is the privacy issue that Ivan mentioned, and I agree, we  
cannot use a camera image for this.

What I suggested before, but which was not practicable, would be some  
"passive" readout-hardware in the camera that only reports a single  
brightness value. But I was told the current design would require to  
power the camera on for that. And in a new hardware design it may be  
cheaper and better to add a photo sensor than this.

The biggest benefit I see from adding this is power savings. The  
backlight should be automatically turned off when there is enough  
ambient light, to save power. Switching it back on could easily be  
done by the user (or automatically for convenience).

- Bert -

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

Better anti-aliasing

[Bert Freudenberg]

On 25.04.2008, at 07:54, Benjamin M. Schwartz wrote:
>
> Nope.  Take out your magnifying glass and look: each pixel is either  
> red,
> green, or blue, even in monochrome mode. Those are not software- 
> controlled
> filters; they're formed by a fixed physical diffraction grating.
> Monochrome mode just tells the software to set R=G=B, but with the
> backlight on only one of those three is actually displayed at each  
> pixel.

So far we agree ...

> One amusing question is: could software potentially set monochrome  
> mode
> and then use fancy color-adaptive subpixel rendering to do optimized
> display of fonts and images?  Maybe, but at 200 dpi the gains would be
> small, and the computational overhead would be huge.


... but here you lost me.

There is no need for "fancy color-adaptive subpixel rendering". The  
framebuffer with its 1200x900 resolution maps 1:1 to physical display  
pixels. The DCON simply selects the red channel of the first pixel,  
and the green of the second, and the blue of the third, and so on.  
This does not affect pixel geometry. Thus normal full-pixel anti- 
aliased software rendering will do The Right Thing.

One thing that someone (Albert IIRC) proposed was doing a better  
filtering job than the DCON does - it uses a simple 5-tap filter which  
adds a noticeable amount of blur. It is still vital to do filtering,  
otherwise a single red pixel surrounded by black background that  
happens to fall on a blue physical pixel would not be seen at all, the  
filter ensures that at least half of its energy is distributed to the  
adjacent red physical pixels. Or a single white pixel would appear  
colored.

To experiment with this, it would be necessary to disable the DCON 5- 
tap filter, but to not switch on its color transformation (which  
translates colors into gray values using a perception-based formula,  
green contributes more energy than red or blue). These two settings  
are coupled in recent hardware and/or software versions. I remember I  
could toggle them separately on a display prototype in 2006, but not  
anymore. This does make sense for normal use, it would only be nice  
for experimenting. Is it a hardware thing?

- Bert -


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

Re: Auto backlight management?

[Martin Dengler]

On Thu, Apr 24, 2008 at 10:54:34PM -0700, [EMAIL PROTECTED] wrote:
> my machines are out on loan right now. is this monochrome mode the 
> high-res mode, or is this still using multiple screen pixels per display 
> pixel like color does? (or another way to put it, does the screen get much 
> sharper when you do this?)

It's the high res mode.  It looks really nice.

> David Lang

Martin


pgp3TiYMUvRWo.pgp
Description: PGP signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Auto backlight management?

[Martin Dengler]

On Fri, Apr 25, 2008 at 12:07:12AM -0400, Eben Eliason wrote:
> On Thu, Apr 24, 2008 at 10:43 PM, John Watlington <[EMAIL PROTECTED]> wrote:
> >
> >  Bert misread the spec.  When the backlight is switched off, the screen
> >  automatically switches to B&W mode.   Why would you want to take
> >  that out of the control of the user ?
> 
> It's clear to me that it would be quite useful to have a
> bright backlight AND black & white mode for reading a book at night,
> for instance, and this isn't possible in the current UI.

The camera could be checked once when the device went into/out of ebook mode
and the backlight changed appropriately.

> - Eben

Martin


pgpKJYfXKxP4y.pgp
Description: PGP signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: A technical assessment of porting "Sugar" to Windows.

[Olly Betts]

C. Scott Ananian <[EMAIL PROTECTED]> writes:
> Our current implementation is based on Xapian,
> which "compiles" on Windows (but perhaps not much more):
> http://lists.tartarus.org/pipermail/xapian-devel/2006-March/000311.html

Um, "2006-March" - that message is over two years old!  And even back then
Xapian worked nicely when built with cygwin or mingw.

Back in the present day, MSVC support has been pretty solid for some time.
You can even download prebuilt binaries of the core library and python
bindings:

http://www.raptorized.com/xapian-python-win32/

Cheers,
Olly

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

Re: Walter leaving and shift to XP.

[Aaron Kaplan]

On Apr 23, 2008, at 1:25 AM, Joshua N Pritikin wrote:

> By my judgment, I'm glad Richard Stallman isn't running OLPC. He would
> have delayed the launch until we have a GPL'd replacement for the mesh
> firmware. As it is now, we have a laptop which is more pure license- 
> wise
> than any other laptop available at about half the cost of the
> competition. And we have had mesh networking in production for  
> about six
> months. Who else has mesh networking? Nobody. That's not an ideal
>

not true ;-)

there are plenty of open source solutions out there which just need  
to be installed.
see www.olsr.org for one example.



---
there's no place like 127.0.0.1



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

Re: An olpcfs experience report

[Bert Freudenberg]

On 25.04.2008, at 04:05, Michael Stone wrote:

> Over the last few weeks, I've spent a fair bit of time producing  
> several
> essay drafts and transcriptions of IRC conversations. Something you  
> may
> not have known is that I did so on top of olpcfs [1,2]. Yesterday, 1cc
> experienced a power failure which briefly took down my working  
> machine.
> Today, with some trepidation, I remounted my olpcfs and was pleased to
> discover that my data were intact.
>
> While I cannot claim to have stressed olpcfs in any serious fashion, I
> am happy to report that it is suitable for capturing versions of  
> simple
> plain-text essays and that it maintained its data integrity through at
> least one hard power failure. On the basis of this experience, I
> encourage others to download it, follow the instructions, and give  
> it a
> whirl:
>
>  git clone git://dev.laptop.org/users/cscott/olpcfs1
>  cat olpcfs1/README
>
> Michael
>
> [1]: http://wiki.laptop.org/go/Olpcfs
> [2]: http://dev.laptop.org/git/users/cscott/olpcfs1


This is not a technical assessment, but I like the olpcfs idea.

- Bert -


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

Re: Walter leaving and shift to XP.

[Ivan Krstić]

After taking a few days to collect my thoughts about everything that's  
going on, I'll add my last message to this thread to encourage the  
community to continue to stand tall and proud:

 

You did good, folks, and it was a pleasure and a privilege of a  
lifetime to work with you on enabling learning for children who need  
it most. The recent developments don't change a thing about what  
you've accomplished.

--
Ivan Krstić <[EMAIL PROTECTED]> | http://radian.org
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

RE: A technical assessment of porting "Sugar" to Windows.

[scott]

why climb aboard a sinking ship, particularly when yours is moving fast...

On Fri, 25 Apr 2008, Raymond F. Hayes Jr. wrote:

> These might be stupid questions since I just joined the newsgroup today so
> my apologies in advance but I wasn't able to find an answer on the site.
>
> When you're talking about running Sugar on Windows XP, are you talking about
> a running the "retail" version of XP or a version of Windows XP Embedded
> with a customized shell as described here:
> http://msdn2.microsoft.com/en-us/library/ms940134.aspx or some special
> version to be decided later on.
>
>
> Ray
>
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> On Behalf Of Wade Brainerd
> Sent: Thursday, April 24, 2008 3:11 PM
> To: C. Scott Ananian
> Cc: [EMAIL PROTECTED]; Michail Bletsas; OLPC Devel
> Subject: Re: A technical assessment of porting "Sugar" to Windows.
>
> Hey Scott, thanks for this.  It's nice to see a clear, unbiased
> analysis of a complex problem.
>
> It shows that there are some clear technical advantages to the
> GNU/Linux stack, while correctly stating that there are options for a
> Windows port which would not be impossible.
>
> I personally can't imagine that the experience would be any better for
> users, or a good use of OLPC's time and energy, and the apparent cost
> of community goodwill *should not* be underestimated by management.
> But if it means more sales versus the Classmate, a massive donation
> from the Gates foundation, and a large team at Microsoft working on
> the project, it may ultimately be for the best for the children to
> have Windows available as an option on XO (it's an education project,
> not a linux project).  It's a calculated risk to be taken by the
> project management.
>
> Anyway, I use tons of open source software every day on Windows XP,
> and the fact that the operating system is closed source (as is the
> processor, motherboard, and video card) doesn't bother me.  It's worth
> noting that I can install a complete KDE environment on my XP machine
> via Cygwin in about 2 hours.  Major OSS projects like QT, Firefox and
> OpenOffice are pushing cross platform development with the aim of
> greater adoption, I don't see why that's such a bad idea for Sugar.
>
> Anyway, it's nice to see the OLPC core people are able to keep level
> heads and think pragmatically.  Particularly when *you* were the one
> implicated by Ars Technica as "extremely unhappy with Negroponte's
> statement and argue that his goals are not technically feasible."
>
> Best,
> Wade
>
> On Thu, Apr 24, 2008 at 2:32 PM, C. Scott Ananian <[EMAIL PROTECTED]> wrote:
> > This document will give a technical overview of the challenges facing
> >  any "Sugar on Windows" project.  Mary Lou Jepson of OLPC was proud of
> >  the fact that the XO did "seven new things" when most hardware
> >  projects try to limit themselves to only one "new thing" per product.
> >  I will outline the "new things" which the XO system intends to
> >  accomplish, and discuss the feasibility of each of them if/when
> >  reimplemented on a Windows substrate.
> >
> >  I will start by addressing nomenclature.  What do we mean when we say
> >  "Sugar"?  Is it the activities?  The zooming UI interface?  The
> >  complete system?  What do we mean when we say "Sugar on Windows"?
> >
> >  For this document, I will assume that "Sugar" means the "new things"
> >  which are goals of the XO system.  As we will see, some of these "new
> >  things" as easy to accomplish, regardless of underlying operating
> >  system, while others are extremely difficult or impossible.  Clearly,
> >  what is meant by "Sugar on Windows" is that some subset of the "new
> >  things" will be implemented on a Windows platform.  It is up to those
> >  who argue for "Sugar on Windows" to be clear about which of these "new
> >  things" they intend to accomplish; the costs and benefits of "Sugar on
> >  Windows" critically depend on this definition.
> >
> >  I will present 12 items which comprise the current XO system.  Most of
> >  these are implemented to some degree on the current GNU/Linux-based
> >  stack ("Sugar/GNU/Linux"), although several of them are
> >  works-in-progress.  For each I will attempt a rough measure of the
> >  difficulty of porting or reimplementing this feature on a
> >  Windows-based stack ("Sugar/Windows").
> >
> >
> >  1. Sugar design guidelines.
> >
> >  In this minimal "Sugar on Windows" proposal, the only thing common
> >  between Sugar/GNU/Linux and Sugar/Windows are the design guidelines.
> >  Windows developers would port existing applications (Word, for
> >  example) and provide simplified interfaces matching the Sugar UI
> >  guidelines, but these activities would not share any code or
> >  interoperate in any way with Sugar/GNU/Linux.  The collaboration and
> >  other features itemized below would exist in Sugar/Windows only to the
> >  extent to which the original or newly-written applications supported
>

RE: A technical assessment of porting "Sugar" to Windows.

[Raymond F. Hayes Jr.]

These might be stupid questions since I just joined the newsgroup today so
my apologies in advance but I wasn't able to find an answer on the site.

When you're talking about running Sugar on Windows XP, are you talking about
a running the "retail" version of XP or a version of Windows XP Embedded
with a customized shell as described here:
http://msdn2.microsoft.com/en-us/library/ms940134.aspx or some special
version to be decided later on.


Ray


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Wade Brainerd
Sent: Thursday, April 24, 2008 3:11 PM
To: C. Scott Ananian
Cc: [EMAIL PROTECTED]; Michail Bletsas; OLPC Devel
Subject: Re: A technical assessment of porting "Sugar" to Windows.

Hey Scott, thanks for this.  It's nice to see a clear, unbiased
analysis of a complex problem.

It shows that there are some clear technical advantages to the
GNU/Linux stack, while correctly stating that there are options for a
Windows port which would not be impossible.

I personally can't imagine that the experience would be any better for
users, or a good use of OLPC's time and energy, and the apparent cost
of community goodwill *should not* be underestimated by management.
But if it means more sales versus the Classmate, a massive donation
from the Gates foundation, and a large team at Microsoft working on
the project, it may ultimately be for the best for the children to
have Windows available as an option on XO (it's an education project,
not a linux project).  It's a calculated risk to be taken by the
project management.

Anyway, I use tons of open source software every day on Windows XP,
and the fact that the operating system is closed source (as is the
processor, motherboard, and video card) doesn't bother me.  It's worth
noting that I can install a complete KDE environment on my XP machine
via Cygwin in about 2 hours.  Major OSS projects like QT, Firefox and
OpenOffice are pushing cross platform development with the aim of
greater adoption, I don't see why that's such a bad idea for Sugar.

Anyway, it's nice to see the OLPC core people are able to keep level
heads and think pragmatically.  Particularly when *you* were the one
implicated by Ars Technica as "extremely unhappy with Negroponte's
statement and argue that his goals are not technically feasible."

Best,
Wade

On Thu, Apr 24, 2008 at 2:32 PM, C. Scott Ananian <[EMAIL PROTECTED]> wrote:
> This document will give a technical overview of the challenges facing
>  any "Sugar on Windows" project.  Mary Lou Jepson of OLPC was proud of
>  the fact that the XO did "seven new things" when most hardware
>  projects try to limit themselves to only one "new thing" per product.
>  I will outline the "new things" which the XO system intends to
>  accomplish, and discuss the feasibility of each of them if/when
>  reimplemented on a Windows substrate.
>
>  I will start by addressing nomenclature.  What do we mean when we say
>  "Sugar"?  Is it the activities?  The zooming UI interface?  The
>  complete system?  What do we mean when we say "Sugar on Windows"?
>
>  For this document, I will assume that "Sugar" means the "new things"
>  which are goals of the XO system.  As we will see, some of these "new
>  things" as easy to accomplish, regardless of underlying operating
>  system, while others are extremely difficult or impossible.  Clearly,
>  what is meant by "Sugar on Windows" is that some subset of the "new
>  things" will be implemented on a Windows platform.  It is up to those
>  who argue for "Sugar on Windows" to be clear about which of these "new
>  things" they intend to accomplish; the costs and benefits of "Sugar on
>  Windows" critically depend on this definition.
>
>  I will present 12 items which comprise the current XO system.  Most of
>  these are implemented to some degree on the current GNU/Linux-based
>  stack ("Sugar/GNU/Linux"), although several of them are
>  works-in-progress.  For each I will attempt a rough measure of the
>  difficulty of porting or reimplementing this feature on a
>  Windows-based stack ("Sugar/Windows").
>
>
>  1. Sugar design guidelines.
>
>  In this minimal "Sugar on Windows" proposal, the only thing common
>  between Sugar/GNU/Linux and Sugar/Windows are the design guidelines.
>  Windows developers would port existing applications (Word, for
>  example) and provide simplified interfaces matching the Sugar UI
>  guidelines, but these activities would not share any code or
>  interoperate in any way with Sugar/GNU/Linux.  The collaboration and
>  other features itemized below would exist in Sugar/Windows only to the
>  extent to which the original or newly-written applications supported
>  them: native Word collaboration via a SharePoint server, for example,
>  would replace the Abiword-based peer-to-peer collaboration of
>  Sugar/GNU/Linux.
>
>  This course of action is rather difficult, as it requires essentially
>  a complete reimplementation of the XO software, but it imposes
>  min