Re: [sugar] Automatic transfer/update of activities on the mesh (Was: Sharing behavior in the core Read activity)

[Jameson "Chema" Quinn]

Develop clearly needs to be aware of whatever solution we come up with for
activity updates. This means that Develop has to be able to do the signing.
Right now, bitfrost does not give out the private key to activities
(correctly) and does not allow activities to request a signature for
something (wrongly - there is a P_IDENT bitfrost privilege which should
allow activities which have it to sign things).

I raised this issue on IRC and got two responses.

1. neuralis/ ivan krstic was the security guy on the team and he has just
left. Do not expect this to be fixed soon.

2. Do not try to fix this yourself, as security must be done right or not at
all.

(apologies for stripping the nuances)

I disagree with #2. Security must not be done wrong, but it can be done
partially if we think things through. Adding a hook so that activities with
P_IDENT can request signatures, without seeing the private key, is IMO safe
and simple enough to be worth doing if it helps us with activity updates.

(More summary from IRC: the tricky, unresolved issue is key trust - does a
given public key mean what we think it means? This is separate from key
security. Let me give a scenario.

Activities spread virally by sharing. Alicia codes a new activity V1 and
signs it, it starts to spread. Bad Bob replaces Alicia's sig with his own
and keeps spreading it. Now Bad Bob can add his malicious code to the
activity later, and all the people who got the activity downstream from him
will automatically update to the malicious version.

To me this is not a problem, because Bob could have added his code to the
activity in the first place. It just lets him be a little lazier. It is 100%
equivalent if Bob had added some general-purpose trojan to the app
immediately, so auto-update has not created any new vulnerabilities. Also,
if there are two versions of the same activity floating around with
different signatures, noticeable things will start to happen - either
someone downstream from Bob will get an update from Alicia that will
mysteriously fail to autoinstall, or vice versa.)

On Wed, Mar 26, 2008 at 7:10 AM, Guillaume Desmottes <
[EMAIL PROTECTED]> wrote:

> Le mardi 25 mars 2008 à 16:02 -0400, Benjamin M. Schwartz a écrit :
> > This works, and will work for the proposed case.  For the future, I see
> > file transfer as precisely the sort of thing that should be handled
> > internally to Telepathy.  Perhaps Telepathy should implement XEP-0234
> > (file transfer)[2] or even XEP-0214 (file sharing)[3].
> >
>
> We have a draft of spec for file transfer (but it will be probably
> modified) and a Salut branch implementing it. So that's definitely
> something that could be done at some point.
>
>
>G.
>
> ___
> Sugar mailing list
> [EMAIL PROTECTED]
> http://lists.laptop.org/listinfo/sugar
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [sugar] Automatic transfer/update of activities on the mesh (Was: Sharing behavior in the core Read activity)

[Jameson "Chema" Quinn]

>
> As I said in my previous email, Bitfrost clearly states (correctly, in
> my mind) that even justified belief that code originates from some known
> individual implies no trust relationship with that code. Period. Use
> isolation to make it safer to play with code and use signing to help
> reduce attackers' abilities to lie to you about what code you're going
> to be running.
>

If you take this to the extreme, then you would reset manually-granted
bitfrost privileges on every activity update, and even remove the default
"resume" behavior from the journal for instances of that activity (if it is
not the same code, it cannot be trusted to handle to handle the same data
without an explicit "resume with new version" choice by the user).

I think new versions which are from the same source should get an implied
trust level - the same trust as prior versions, which, in general, will be
strictly limited by Bitfrost. I think that the fact that such "same source"
may be the same corrupted source does not affect this.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [sugar] XO-user's communications security needs

[Jameson "Chema" Quinn]

I see 3 meaningful possibilities:

1. P_IDENT activities can sign/unencrypt anything with users private key,
with no user knowledge. Thus a signature means only that communication comes
from a given laptop, and has no implication about the awareness or assent of
the user of that laptop.

2. P_IDENT only lets activities use signatures/unencryption within strictly
limited communications protocols OR with some explicit, trusted-UI agreement
from the user. The communications protocols are designed such that each
encrypted/signed block is identifiable and validated as part of that
protocol (ie, header in every block, or only the temporary private key is
encrypted against the real private key and the OS refuses to unencrypt
temporary private keys unless they are marked as part of that protocol).
Thus a signature on, or the ability to unencrypt, data that is not marked as
part of that protocol, implies user assent.

3. There is one private key used for communications security, and another
one used for user identity verification.

Are my possibilities comprehensive? If so, which one are we aiming for?

Jameson

On Wed, Mar 26, 2008 at 11:40 AM, Michael Stone <[EMAIL PROTECTED]> wrote:

> Folks,
>
> Pursuant to recent discussions about P_IDENT, I've begun drafting
> principles and use cases in order to discover some of the communications
> security needs of XO-users.
>
> My thoughts to date (with substantial input from both Daf and
> Polychronis) are recorded, haphazardly, at
>
>  http://wiki.laptop.org/go/Communications_security
>
> Finally, I will be meeting briefly with Jonathan Herzog tomorrow morning
> in order to review this material. If you have the opportunity, please
> examine my thoughts, let me know what you consider to be the most
> pressing concerns either by replying to this email or on the wiki page.
> I'll do what I can to dig up convincing answers. :)
>
> Michael
>
> ___
> Sugar mailing list
> [EMAIL PROTECTED]
> http://lists.laptop.org/listinfo/sugar
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Fwd: Tkinter in olpc

[Jameson "Chema" Quinn]

-- Forwarded message --
From: Jameson Chema Quinn <[EMAIL PROTECTED]>
Date: Thu, Mar 27, 2008 at 4:36 PM
Subject: Re: Tkinter in olpc
To: Noah Kantrowitz <[EMAIL PROTECTED]>




2008/3/27 Noah Kantrowitz <[EMAIL PROTECTED]>:

Aaron Konstam wrote:
> > Does anyone have and opinion on whether python's Tkinter facility could
> > be added to python on the XO by simply copying the contents of lib-tk
> > from an f7 system?
>
> Why in the name of all that is good would we do that? I would rather
> curses to a Tk GUI most of the time. GTK works fine.
>
> --Noah
>
> The obvious reason would be to test or even use a Tk-based app. Obviously
it would need to be ported before becoming an activity (though a temporary
hack would be to include tk in the activity directory and run the activity
from a shell which first did "export LD_PRELOAD".)

The question is, what tk-based app? IDLE? Wouldn't you prefer Develop?

As to how, I would definitely try yum install before copying directories
willy-nilly.

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

Develop app

[Jameson "Chema" Quinn]

It's getting to be time to share my work on Develop on this list. The latest
version is now up on the wiki. Below, I've pasted a copy of some relevant
text from that page. Please, try it out, and of course, all patches are
welcome.

Jameson

...copy from wiki page follows...

WARNINGS

Currently this version only edits activities that are stored in
~olpc/Activities, but that at least means that you can use it to develop
itself.

This saves modified versions of activities in the journal. In order to
continue editing these saved activity bundles, *you need to also install the
patched version of the journal called
Image:DoppelJournal-79.xo
.*. (ticket *#6639* ) In DoppelJournal,
go to the details page for your saved application bundle, put the mouse over
the resume button in the upper right, and wait a fraction of a second until
the pulldown shows the options "Develop" and "Start". "Develop" works, but
"start" doesn't because bitfrost prevents DoppelJournal from reinstalling
the activity.

So in order to open these modified versions, you need to use your regular
journal. When you do, you run into ticket
*#6497*,
which means that you cannot run/test your modified activities unless you
change the version number in activity.info for each test.

Also, this app has been known to cause *TOTAL LOSS OF JOURNAL CONTENTS*. The
data is still on your XO, in /home/olpc/.sugar/default/datastore1234567890
(your numbers will be different). You can recover this data by copying it
onto an external USB and then letting the files be recognized by the
journal... (I think, I have not tried this yet. The problem is that the
files have no extension, but at least my Ubuntu system can guess the correct
file type for most.) I do not understand this bug and am not sure that it
still occurs with the latest version of Develop, but you have been warned.

This uses bundlebuilder.py to save its XO files. This means that if MANIFEST
is not correct, it can either fail to save, or fail to save all of its
files. Again, you have been warned. I have a plan to fix this, it is not too
hard.

The other known bugs are very minor issues that I already know how to fix as
soon as I get around to it. The F8 (big circle on the XO slider) key is
getting grabbed by the window manager in some cases, I have two identical
tabs of logs in some cases, and ignore-case in find is unimplemented.
 Enough bad things, what is good about it?

It really works! Not just a toy.

Rudimentary version control, using the journal.

Good find/replace support, check out the UI (though there is still room for
improvement - search history, shift-fkeys to hard-open the palettes...).
F5-F8 (the circle-slider on the XO) are set find, find prev, find next, and
{set replace or, if replace was set since find, do replace}, respectively.

Ability to view log files from within the app. Better than logviewer, since
you can see logs from previous 4 sessions, and the list is filtered to the
ones relevant to your app.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Mini-Conference Proposal: Frameworks for Collaboration

[Jameson "Chema" Quinn]

On Sat, Mar 29, 2008 at 1:05 PM, Benjamin M. Schwartz <
[EMAIL PROTECTED]> wrote:

> C. Scott Ananian wrote:
> | On Sat, Mar 29, 2008 at 1:47 AM, Benjamin M. Schwartz
> | <[EMAIL PROTECTED]> wrote:
> |>  We will have an open discussion of how to build a framework that will
> ease the
> |>  creation of reliable collaborative activities.  I will also outline a
> proposal
> |>  for "Collisionless", a particular message-based API that encompasses
> both
> |>  real-time and offline collaboration.  The key idea of Collisionless is
> to break
> |>  down high-level tasks into a sequence of messages whose significance
> does not
> |>  depend on the order in which they are received.
> |
> | Hmm.  I've always thought of a high-level framework here as based on a
> | shared undo/redo list, since most mature applications support
> | undo/redo.  The idea is that we provide the necessary distributed
> | consensus algorithms to allow all participants to agree on the order
> | of the entries in their undo/redo list; anyone who had actions applied
> | in the wrong order performs undos, then redos to adjust their order.
> | When you present your proposal, I'd love to hear a comparison to this
> | approach.
>
> That is a very interesting perspective.  I will definitely think hard
> about that and try to come up with a sensible comparison.
>
> Offhand, I think the Collisionless idea is like a design where each
> person's Undo/Redo list can be in a different order, and yet always reach
> the same final state, as long as they contain the same total set of edits.
>
> --Ben
>
>
On any data structure with internal order (ie, anything much more complex
than a set), it is impossible to have an arbitrary set of edits result in
the same final state independently of order. Obviously, from both the name
"collisionless" and from this logic, you must add constraints: a given set
of edits is "collisionless" if you can apply them in any order; in the
example of a text file, collisionless essentially means that they edit
different portions of a file. When there is a dispute about the order of
"collisionfull" edits, some explicit merge algorithm is needed - either one
edit wins and the other loses, or you arbitrarily assume an order, or you
ask for user intervention.

I would simply pose the case of source control - the one I'm interested in
for Develop. Even if two people edit entirely different files, it is not
100% safe to have an automatic merge of their code - say both fixed the same
bug by incrementing the same variable, but now it gets incremented twice.
Honestly, in a loose kind of environment, as most XO coding will be, "fine,
we'll catch that in testing" is an OK answer to that, especially if you have
automatic tests. But in order to debug that once you catch it, you need
tools for seeing who did what when, ones which highlight any automatic
merges as possible sources of problems.

I know, source control is a special case, and you don't want to contort your
framework for this special case. My main point here is that the framework
will be most useful if:
- it allows its client app to decide what to do in the case of "collisions"
- it notifies  the client app even of "crossovers" that aren't "collisions"
- it provides some support for keeping track of who did what, even when
there aren't crossovers or collisions

In other words, do your magic, please, but tell me about it if I care. It is
easy to think of non-source-control use cases for all of the three cases
above. This is not to say that a totally black-box solution wouldn't be
useful for many, just that a more open solution would be more so for more.

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

Teachers and researchers (miniconference?)

[Jameson "Chema" Quinn]

Part of the allure of constructivism is that it supposedly reduces the role
of the teacher and the bureaucrat, allowing a country where teaching jobs
have been political handouts to the incompetent, to improve its education
system "from the bottom up". There are many good arguments for
constructivism; this is not one of them. You do not build an educational
system by expecting Ramanujan.

Good teachers inspire, decent teachers help guide, and bad teachers get in
the way. The effects of this are (after the "cultural capital" of the
parents and the nutrition of the students) one of the biggest sources of
variance in learning success. If the XO, as a tool, can take some of the
load off of teachers, that will help keep good teachers from burning out and
moving to other professions, it will help decent teachers do a better job,
and it will even turn some of the bad teachers into decent teachers. Many of
the things teachers need - communication with students, ways to facilitate
inter-student communication, resources of information, resources for student
experimentation and experience-building - are already big focuses of OLPC
development. But I would argue that helping teachers *keep track of student
progress* better, with less hassle, and then using that information to
inform your lesson-plans going forward, is a huge part of the job of
teaching. This needs to be "designed in" to many activities just as much as
sharing does, or just as much as the journal metaphor.

The educational researcher also plays an important role. I hated the focus
on standardized tests when I was a student (even though the system is very
explicitly designed to benefit highly-advantaged, successful students like
me - a question that I would get wrong and a less-successful student would
get right is guaranteed to be eliminated from the test - sorry, the
"instrument" - as a drag on "reliability".) And as a classroom teacher, I
hate the even-more-absurd levels to which standardized tests have been
elevated recently in the US (OK, most of my teaching experience is in
Guatemala, but I subbed for a year in  the post-No-Child-Left-Behind US).

But the truth remains that here in Latin America and much of the third
world, the education system is in really, really bad shape, and that it is
literally impossible to improve things without having some perspective on
them. There are also plenty of people with supposed panacea solutions; you
can spend forever if you just chase the latest trendy fashion, so you need
some perspective to see what helps and what doesn't. Educational research is
the only way to get that perspective. If, out of the 2 weeks of filling in
bubbles that the average student in the US spends per year, they could
export one day to each Latin American subregion, we'd all be better off.

Enough blah-blah. This is an list for engineers, do I have an engineering
proposal? Not really, but I have some ideas.

-All activities should keep anonymized usage statistics, and these
statistics should be copied to the central server on backup. Activities
should be encouraged to keep numeric information that can be anonymized and
statistically agregated - including scores, total active usage time in
different "parts" of the activity, etc. - in file metadata, rather than
inside files.

-Keeping statistics on every use of an activity is useful for proving that
the laptops are serving some purposes. However, if use by the child "owner"
is mixed in with even 5-10% of use by parents, siblings, or friends, these
statistics become nearly worthless in tracking individual progress. Also,
automated statistics should not violate privacy. Therefore, there should be
a separate mechanism for "turning in" student activity instances, which
would include information like time spent on the activity, as well as
additional usage information which would make it possible to catch simple
forgeries. There should be a teacher-focused activity which enables the
teacher to organize information that they have about a student. The
"classroom toolkit" is absolutely central here too - if a teacher poses
problems in-class over the mesh, they need to be able to slice the response
data later by student OR by problem, they need to be able to publish
rubrics/expectations with the problems, they need to be able to score
against those rubrics, they need to be able to see score averages AND score
totals (Diego is absent half the time but scores 100, Francisco is here all
the time but scores 50).

I don't pretend to have all the answers for how to balance student privacy
with this. Certainly it is a real concern; a constant feeling of eyes over
your shoulder, especially eyes that are only out to grade you on some scale
of good to bad, is bad for creativity among other things. I am sure that
other people on this list will argue eloquently for privacy. What I am
saying here is that, without compromising on privacy, we can have explicit,
opt-in mechanisms for tracking student progress, and

MANIFEST and .xo bundles

[Jameson "Chema" Quinn]

Since Develop now relies on bundlebuilder to create its journal entries (.xo
files), I have become familiar with the fragility of the activity bundle
format. The original sin is that, if you have a bundle of files, you
shouln't need a separate list of those files in MANIFEST. The various
symptoms all flow from this: mistyped files (doesn't save), including the
root directory in the paths (ditto), adding a file with cp but forgetting to
add it to MANIFEST (deleted on next activity update), including MANIFEST
itself in the manifest (no effect, a random source of variation)

What is the MANIFEST supposed to accomplish in the first place?

1. Something like .gitignore
problems: because it's a whitelist instead of a blacklist, there is always
the possibility that, even if Develop carefully maintains the integrity,
someone will add an important file behind Develop's back. This file would
tend to be deleted on the next update.
suggested solution: just use a file named .gitignore - follow the standard
(though for simplicity's sake it would be OK to only obey the top-level
gitignore). Moreover, we could have an implicit global .gitignore which
would ignore (at least) .pyc files.

2. Give a clear ordering of the files for cryptographic signing purposes.
problems: obvious
solution: obviously just use a well-defined and documented ordering
algorithm

So, my suggestion would be to abandon the MANIFEST and use .gitignore, with
an implicit global default.

If not, I will have to rewrite Develop to take care of the MANIFEST
automatically, and not show it for manual editing. Problems ensue: if the
MANIFEST is absent or missing files, Develop will have to use a modal dialog
box to ask what to do. This solution seems ugly to me.

.

While I'm writing an email on this stuff, I should include a brief
discussion of activity auto-updates. Currently, an activity is reinstalled
iff it is currently installed in Activities/ and the user runs a bundle with
a different version in activity/activity.info . This means that in Develop,
you have to change the version for every debugging cycle - pretty annoying.
It also means that downgrades are treated identically to upgrades, and of
course there is no security.

I suggest that:
-when running the same or previous versions (or, in the future, versions
signed by someone you don't recognize as a developer for that activity), a
modal dialog box should come up for a few seconds with the default option to
not reinstall (which, if attempting to join a shared activity with a newer
version, would mean not joining. Backwards compatibility, on the other hand,
would be assumed, and graceful failure would be the activity's
responsibility)

-develop a two level system of signing activity bundles: "maintainers" would
have to sign/revoke "maintainers" and "developers", and "developers" would
sign specific versions of the activity bundle; credentials would be chained
and kept, so that missing intermediate versions would not be a problem.
Ideally the signature would be valid for the unpacked directory with the
same ignores as .gitignore, not just for the specific compressed version of
it, so that activity bundles could be recreated on the fly for sharing
purposes. (I forget who's idea this is based on, apologies). (This may be
overdesign, but the good part is that it keeps simple "I sign this bundle"
separate from the whole maintainer/developer chain, so the simple part could
be implemented first and remain unchanged later.)

-Any activity signed by the current user is reinstalled always (allows easy
debug cycle and reverts)

-For now, develop would create its own key pair. When bitfrost's P_IDENT is
implemented, it would use that.

(it may be that even when P_IDENT is implemented, it requires activities to
include their own hash in all signed data: "signed by me using Develop
activity" instead of just "signed by me". I suspect that this would not
require any backwards-incompatible change to the signature format used)

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

Re: Teachers and researchers (miniconference?)

[Jameson "Chema" Quinn]

Of COURSE you need to empower students. What I'm saying is that the program
will be more successful if you also empower teachers. A lot of the needs are
the same - access to materials for learning - but one of them is different -
tools for keeping track of learning.

Actually, to be honest, good tools for tracking learning could be used to
keep track of one's own progress too.

On Sun, Mar 30, 2008 at 10:43 AM, Kent Loobey <[EMAIL PROTECTED]> wrote:

> Relax teachers!  No laptop will ever replace the "good" a good teacher can
> do
> for a student.
>
> What a laptop / activity / software / internet can do is make available to
> a
> student information / resources / experience that any particular teacher
> does
> not have / know / have-access.
>
> What I have been told by good-intentioned / over-worked / bigoted / dumb /
> ignorant teachers is don't-think-about-it / no-one-knows-about-it /
> we-don't-do-that / learning-about-it-is-dangerous / etc. / etc. / etc.
>
> What I believe a laptop / activity / software / internet can do is
> facilitate
> empowerment.
>
> "empowerment." The American Heritage(R) Dictionary of the English Language,
> Fourth Edition. Houghton Mifflin Company, 2004. 30 Mar. 2008.
>  http://dictionary.reference.com/browse/empowerment>.
>
> "To equip or supply with an ability; enable: "Computers ... empower
> students
> to become intellectual explorers" (Edward B. Fiske).",
> ___
> 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: [sugar] Mini-Conference Proposal: Automatic transfer/update of activities on the mesh

[Jameson "Chema" Quinn]

OK, the mini-conference happened - thanks for trying to let off-siters like
me participate. Here's the Gobby doc which resulted, below are my
post-meeting comments:

Activity sharing:

* Should we show people what the size/download time for a package is before
d/l?
* We might download something more readily if it's coming from a friend.
  * Michael:  Trusting a friend isn't the same as trusting code coming from
that friend.

Ben:  The only security question is whether it's safe to *replace* an
activity
  with a new one.  Bitfrost guarantees that running untrusted code is
safe.

Scott:  You can always modify code, but you have to give it a new name.

Michael:  Making something default is a separate UI action from downloading
it.
Should distinguish between activities by their hashes; version numbers
shouldn't
be used for equality.

homunq: unsigned versions should obviously not get the same preference
directory.

proposals for naming:
  * centralized registry, e.g. microsoft.com
  * mstone:  first person to get there owns the space (and others get
"another version of %s")
  * each activity has a random guid for "same activity" and ...


http://wiki.laptop.org/go/Talk:Activity_bundles#A_proposal_for_Activity_Signing

How to put related activities together?
  * group by tag
  * add prefix in name, sort by name
  * group by magic "sortkey" tag
  decision: A and/or B as author decides.


SJ:  Attach names to the inherent identity of an activity
.. okay, SJ can type what he meant ;-)
I make a new activity, *E*.  It gets a ¨unique¨ id, E.id and a ¨pretty
unique¨ package name, ¨E¨.  ¨E¨ is the friendly name you use locally to
identify the activity.  There is also a pretty name ued in interfaces, which
is ¨E!¨ this can be translated, changed from version to versiion.

when I join a larger group that has some other activity named E, I should
change my public activity-name (andraelly should change the display name).
Everyone can see that my ¨E¨ is differnet from the existing one, since they
have different unique IDs, but to supprot simple intreface-driven updates
and version selection, the friendly package name should change.

aside: there is some confusion about the hisotrical and practical use of
sortkeys.  this is some piece of metadata that an author can acontribuet,
which will help to sort a cluster of related activities with one another.

similarly, which activities appear nextto which other ones in the circle
view is improtnt.   note - this is NOT aout ¨favorites¨.


Grouping   Version   Identity
  P10 X
   \- P 9 O  <-- change in ownership
  N 8 X
   \- N 7 X

Eben:  Use tags to support grouping, e.g. "tamtam" or "mamamedia" or "draw"
Scott: Localisation of tags is hard.

note : having ¨signed¨ versions of activities, and the ecure model, is not
necesarily relevant to lots of activities and use caes.  we should support
identifying versions that claim to e of the same underlying activity, and
claimed merges and forks, without worrying about keys and signing.


THINGS ABOUT WHICH THERE IS NOT CONSENSUS.
how to bulk update a set of activities soeveryone in a room has the same
version

update on share?  is this a good idea?  how would it work in ui?

push updates - is this a good idea? how would it work?

My post-meeting comments:

1. for "version threading", what we need for an activity is not a claim like
"I am a version of activity ID " but "My prior version was XXX and the
one before that was YYY". What is the granularity of XXX and YYY? I'd say, a
hash on the activity.info would be fine - that way, version changes are
automatically picked up, but not every change in the source code. If, later,
activity.info picks up some elements which are too volatile (thus leading to
unnecessarily-long geneologies), we could filter those out before hashing.
Note that this is totally orthogonal to whether an activity version is
signed by the original devteam, and yet allows for forks to become
independent without fighting over who is the "real pippy
org.laptop.XYZ1FFE3". I submit that merges are unnecessary.

2. If we get the version threads right, then the auto-update on sharing
becomes safer. I still don't understand who has to sign to avoid a break in
the ownership chain - I would presume a given set of maintainer/developers,
and I would presume that there would be some way for the group to change
over time - but those details can be worked out.

3. For "push updates" and "school versions", I would presume you'd in some
manner beyond the scope of this discussion get an xo bundle (or a bundle of
bundles), the only problem here is how to install it and mark it as the
official school version. Stated like that, it seems to be obviously a
problem of tagging. How do you securely tag documents you receive from
external sources? I'd say that only signed tags should be allowed to move
from one XO to another, and that it should be possible to have a filter
which au

Re: [sugar] Summer of Code update : applications so far, and thanks

[Jameson "Chema" Quinn]

>
>
> Finally, to stimulate discussion, below are a few applications that
> deserve more feedback and mentor attention.
>

2 points:
1. A lot of these are not on the wiki, or were not in the [[Category:GSoC
proposals]]. I've rectified that for the ones I could find, but I'd really
like to read some that I couldn't find. I understand that some people may
not have found all the different places for communication - the GSoC
website, this list, the wiki, IRC, the other mailing lists, trac it is a
lot to keep track of. So it would be great if mentors could use the GSoC
website to suggest to students that putting an application on the wiki will
get more feedback.

2. My app  has gotten more feedback
than most, so I understand why I'm not on this list, but I still feel left
out. My idea is to modify Develop let you program in a Python based on your
own language, but keep it as English-based python on disk - it takes maybe a
few more words to describe than most applications because nothing like it
really exists anywhere else. And yet most of the feedback I've gotten has to
do more with technical or logistical points, not the basic question of
whether this new idea is worth doing. For those of you whose first language
is not English - do you think it would help people learn to program if the
keywords and basic modules were readable in your own language? (Don't just
think about your own case, think about your average potential programmer -
would it help?) If you have an answer, add it to the talk
page- of course I'd love
any yesses, but if I get a couple of no's there's still
(barely) time for me to submit another Develop-related application.


>
> = Good applications that need review by a mentor with topic-specific
> expertise =
>
> * An XO Eclipse environment - Phan quoc huy


I really want to see this, it sounds very interesting.


> * Handwriting recognition - Juliana Lipková (Thomas Breuel, call your
> office)
> * "your voice on XO" - Alex Escalona, on community-wide building of new
> Festival voices for TTS
>
>
> = Projects attracting more than one good application =
> (e.g., where there are detailed comparisons to be made)
>
> * Typing tutor - at least three good proposals
> * Flashcards - at least two good proposals
> * [[Elements]] extension - at least two good proposals
> * Artificial neural network simulations - at least one good proposal
> * A light email client - a few proposals that need clarification
> * Blogging platforms -   "  "  "
> * Finance activities  -  [[Finance One]], &c
>
>
> = Other applications of note =
>
> == Core system components ==
> * The publish/share button - Robson Mendonça, Eric Burns
> * Server interface design - Michał Ściubidło and others
> * LustreFS for XO (Distributed mesh filesystem) - Evelina Stepanova
> * Memory/disk tuning (schoolserver) - Waseem Shaukat
>
>  == Fundamental activities ==
> * [[Listen and Spell]] - Assim Deodia
> * Homework manager - Jason Tran
> * [[VideoEdit]] - Roberto Fagá
> * [[Coding Tutor]] - Rahul Bagaria


This is where I'd put my proposal, "Bityi - on-screen code i18n in XO
Develop activity" . In other
words, the activity is Develop

>
>
> == Learning games ==
> * Incredible machine - Alex Levenson, with a prototype
> * [[PlayGo]] extensions - Brandon Wilson
> * Water Game - Lin Zhou, for learning water sanitation and safety
> * Garden Game - Javier Trejo, for learning genetics; developing in both en
> and es.
>
>
> Cheers,  SJ
>
> ___
> Sugar mailing list
> [EMAIL PROTECTED]
> http://lists.laptop.org/listinfo/sugar
>
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [OLPC library] Lieutenant Governor Pat Quinn on HB5000

[Jameson "Chema" Quinn]

This is fascinating. I would say that the first triaging you should do to
make this a reality for September is to reduce the number of grade levels
you target to an absolute minimum. More than 3 would be crazy, two is
better. Possibilities:
6/7: pros: 2/3 of the students in a junior high, yet you can count on having
most of them there for 2 or 3 years. cons: late grade = lots of testing;
jealous 8th graders.

3/4 or 4/5 : good ages, but not good saturation.

3/6 : good variety, more logistics.

Once you decide this, a lot more will follow.

Also I had a link for you: http://www.ck12.org/ <-- just starting up but has
some funding and possibly an inside track to getting more, trying to make
open-source textbooks attractive to public schools, worth giving them a call
to see if they are interested in (ready to) collaborating with you. Illinois
would definitely be a feather in their cap. You need all the help you can
get with can get with content.

Good luck!

Jameson

On Tue, Apr 8, 2008 at 4:49 PM, Edward Cherlin <[EMAIL PROTECTED]> wrote:

> I talked with Ryan Croke of Illinois Lieutenant Governor Pat Quinn's
> office today. They are keen on this project, and would like to arrange
> for us to assist in getting the program designed for the best possible
> outcome. HB5000 is moving rapidly through the House, and will then go
> to the Senate, which is likely to turn it over to the Education
> Committee for public hearings. We should organize to bring our XOs and
> our children to Springfield for the hearings.
>
> Among the questions:
>
> Schools will be allowed to choose from among the available laptops.
> The program should capture the differences in outcomes between schools
> using different hardware and software, using appropriate measures LG
> Quinn's office agrees. Nicholas Negroponte is strongly opposed to
> "bake-offs", but the world doesn't work the way he wants.
>
> We need to work with the legislature, the Education authority, and
> with schools on appropriate integration of laptops into curricula, and
> provide at least draft versions of electronic textbooks on all
> requested subjects. Much of what we want to do has yet to be designed.
> In fact, the software that we want to build the textbooks on has in
> some major cases yet to be designed. How much can we promise for the
> start of the next school year in September? That depends very strongly
> on who steps up to do it.
>
> It is very important in pilot projects to do good experimental design
> before hand so that the results contain usable information, not merely
> data. We need to talk to people who know something about these issues,
> who also understand what we are trying to measure.
>
> What training can be put together for the summer before? We need to
> demonstrate the meaning and value of learning by doing through
> collaborative discovery, aka Constructionism. Then we need to provide
> the toolkit for teachers to apply it, and provide feedback mechanisms
> so that their experience and insights steadily improve the process.
>
> This program requires dedicated resources, and management, on our side
> and several others. That means that we need to look for funding.
> Anybody know a good grant writer?
>
> No Child Left Behind creates perverse incentives that can interfere
> with the program. Can we get waivers from the Federal Government for
> the trials?
>
> --
> Edward Cherlin
> End Poverty at a Profit by teaching children business
> http://www.EarthTreasury.org/
> "The best way to predict the future is to invent it."--Alan Kay
> ___
> Library mailing list
> [EMAIL PROTECTED]
> http://lists.laptop.org/listinfo/library
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Bundles, versions, and updates - oh my!

[Jameson "Chema" Quinn]

*The story so far:*

The Develop activity uses the bundle format natively. Thus, it relies on
bundlebuilder.py to create bundles and activitybundle.py to install them.
But many activities have developed their own way of creating bundles, and do
not follow the bundle spec (missing or incorrect MANIFEST). This means that
their bundles do not rebuild correctly in Develop, which could lead to data
loss in the current incarnation.

So, I have to fix bundlebuilder to have more error checking, and
activitybundle to throw warnings to encourage people to follow the spec.

Also, there is a major part of the sugar spec unimplemented - the part where
people can install activities by joining a shared instance of them.
Implementing this will, almost inevitably, mean changes in the bundle spec.
If I am going to start enforcing the spec, *it would seem like the logical
time to update the spec to work for updates.*

*Some terminology, and **an idea from the mini-conference:*

By "*a bundle*" I mean a specific set of bytes. Any change in those bytes
means it's a different bundle. Yet actually there are some changes I
generally don't care about. Using a different zip algorithm on the same set
of files, for instance. Another *possible* instance is a change in
translation strings/ localizable icons that does not touch any executable
code. I have a proposal (see below) in which such "extras" would be exempt
from signature. Thus, when precision is important, I will use "*executable
bundle*" to denote everything with the same valid main signature - that is,
everything which has identical executable code.

At the mini-conference, a shortcut to key management was proposed, where a
developer would create a special-purpose key when they started a new
activity, and sign all versions of that activity with their key. This is
called the "*activity's key*" and the signature using this key is the "*main
signature*". This idea assumes that key management is manual - either they
send the key itself to collaborating developers, or they accept and apply
patches and sign the results locally. If we decide that there are important
key management issues missing from this picture, we could do something like
SPKI. Thus the original developer would become an authority, and they would
grant signing rights to other keys. Even in this case, "main signature" will
refer to whatever set of data constitutes a valid signature under this
scheme. Generally speaking, such data should not require network
confirmation, although a finite lifetime is acceptable.

All bundles signed with the same activity's key are known as an "*unbroken
activity thread*". It is assumed that key management would work and that
there would be no forking within an activity thread (aside from, possibly,
temporary experimental branches which never move beyond one machine). I
propose that the unbroken activity thread should be the basic unit of
analysis in sugar, and that each such thread should have a unique "*bundle
ID*" (like org.laptop.392A7F).

If the key is lost or somebody wants to create a new version (and risk
forking), there could be different bundle ID's that are ancestor and
descendant (and handle the same files). These are part of the same "*[broken]
activity thread*", which inevitably means that forks are possible. In my
proposal, broken activity threads can be identified using the alleged
history from the later version, which consists of prior bundle IDs and
last-common-versions.

Also relevant to this discussion is the new planned journal design at
http://wiki.laptop.org/go/Designs/Journal. Note that there are two kinds of
things in the journal: "*actions*", which, as m_stone puts it, are "like UI
completions", and "*objects*", which are more like normal files (pictures,
documents, etc.) with mime types. Actions contain objects, but those objects
are also accessible independently.

See also http://wiki.laptop.org/go/Designs/Activity_Management. "*Favorite*"
bundles are visible in the "*Home screen*" (or "*donut*"), while all
activities are available in the "*activity list [view]*".
*
The issues
*The point of all of this is the user experience that it enables. Some
possible goals (including straw men):

1"no such thing as versions": all actions are associated with a given
executable bundle, and can only be opened with that bundle. The favorites
can be any set of bundles, whether or not these have an ancestry
relationship. The XO does not garbage collect (GC) old bundles until there
are no more instances which use them.

1a"NSTAV ++": there is some way to manually open an action with a different
bundle. What is the UI to make this easier?

2"latest version, but no such thing as forks": All actions are 100%
upward-compatible across unbroken activity threads (when they aren't, you
just break the thread). All actions open with latest version in an unbroken
thread and "favorite" is an attribute of an unbroken thread - the latest
version available is the one that opens. Broken ac

Re: "Chilling Effects" paper at USENIX

[Jameson "Chema" Quinn]

The paper is over-alarmist due to 2 fundamental errors:

1. Assumes the spec has been implemented (forgivable, could be fixed by a
global tense change to the conditional).

2. Paper reads: "The P IDENT policy states that "all digital *peer*interactions
or communication (e-mails, instant messages, and so forth)
can be cryptographically signed to maintain integrity even
as they're routed through potentially malicious peers on the
mesh." Since the policy does not state the conditions under
which traffic will or will not be signed, and the "unobtrusive
security" goal emphasizes that "strong unobtrusive security"
will occur "behind the scenes" unless it impacts usability—
not privacy—we must assume that *all outgoing traffic* will be
signed by default when possible." (emphasis mine, for contrast). HTTP
requests are not *peer* interactions, and this is makes all that follows
invalid.

Nevertheless, the paper does point to 2 serious flaws in the spec.

1. Key escrow - This is fundamental, and I have proposed a mechanism for
automatic peer-escrow (using key shares) that would accomplish the backup
goal yet be significantly resistant to the flaws the paper points to. It
will probably be about a year before this would be implemented, at current
rates of development; nevertheless, if they're going to judge us on our
goals and not our accomplishments anyway, it may behoove us to update the
spec with some scheme like this.

2. Unauthorized backup servers - the simplest, most obvious response to this
issue is to specify that all private data is encrypted before being backed
up. (This is actually left as an open question in the spec, so it is
possible to argue that the criticism in the paper should have been
qualified.)

I think, therefore, that the best response is summed up in the paper itself:
"As there has been much work on privacy-preserving systems
in recent years, it is our intuition that most, if not all,
of the problematic aspects of Bitfrost can be eliminated by
refining the specification". In other words, let's ignore some of the
chicken-little language of the paper, but take its valid criticisms to
heart.

Jameson

On Wed, Apr 9, 2008 at 10:58 AM, Carl-Daniel Hailfinger <
[EMAIL PROTECTED]> wrote:

> On 09.04.2008 05:50, Jaya Kumar wrote:
> > On Tue, Apr 8, 2008 at 8:38 PM, Joshua N Pritikin <[EMAIL PROTECTED]>
> wrote:
> >
> >> On Tue, Apr 08, 2008 at 10:24:34PM -0400, Benjamin M. Schwartz wrote:
> >>  > A paper called "Freezing More Than Bits: Chilling Effects of the
> OLPC XO
> >>  > Security Model" will be presented next Monday at USENIX UPSEC'08
> [1].  The
> >>  > author has kindly posted the paper at [2], which I discovered after
> Google
> >>  > took me to her weblog [3].
> >>
> >>  This paper is depressing. Why didn't the authors step up and
> >>  contribute instead of criticizing from the citadel?
> >>
> >>  This paper is dead on arrival.
> >>
>
> No, the paper is dead-on.
>
> > I think your reaction is dismissive rather than addressing the
> > author's criticism.
> >
> > Forgive me if I'm wrong, I'm no expert, but it looks to me like the
> > paper makes specific technical criticisms and seems quite detailed. I
> > think it would be more positive and productive to respond to the
> > technical statements made in the paper rather than to be dismissive
> > and ignore what looks to some of us like valuable feedback.
> >
>
> Some of the criticisms in the paper have been mentioned on the security@
> list over a year ago. The reactions were twofold: Some were ridiculed,
> others were ignored.
> It seems this academic paper was the only way to get meaningful
> responses. Then again, most of the comments about the paper were either
> flames or otherwise dismissive instead of disproving any of the claims
> made in the paper.
>
> Anybody who has not completely read both the bitfrost spec and the
> USENIX paper should shut up now. I have read the Bitfrost spec and was
> one of the first persons to comment on it directly after it was
> published. That's why I dismiss most of the comments on this list about
> the USENIX paper - it is too obvious that commenters did not read and
> understand the Bitfrost spec.
>
> Oh, and by the way, http://wiki.laptop.org/go/OLPC_Bitfrost states "We
> welcome feedback on this document, preferably to the public OLPC
> security mailing list
> ". There is NO
> point in contacting any Bitfrost author privately to point out flaws -
> it would go squarely against published official OLPC policy.
>
> Regards,
> Carl-Daniel
> ___
> 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: Bundles, versions, and updates - oh my!

[Jameson "Chema" Quinn]

My terminology in the preceding letter was bad. Rather than resend the fixed
version, I put it on the wiki:
http://wiki.laptop.org/go/Bundles_and_updates. Please read that
instead of the letter above: it has all the same content,
but with better clarity, and one added paragraph near the end.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Bundles, versions, and updates - oh my!

[Jameson "Chema" Quinn]

Sorry for clogging people's inboxes, but, in the spirit of having a livelier
discussion on the mailing list, here are the most-changed sections from the
wiki page. If we reach some conclusion here, I will take responsibility for
keepint the wiki page up-to-date.

[edit
] The issues (from a user experience point of view)

The point of all of this is the user experience that it enables. There are
three basic possibilities; sugar can understand just the bundle level, it
can understand the unbroken activity thread level, or it can understand
activity threads including breaks and forks. In the email I had some names
for those based on sugar's perspective of what exists, I have renamed them
below. I believe all of the below options are technically possible, although
of course some are easier than others.
[edit
] Main options

   1. *bundle level* (was called "no such thing as versions"): all
   actions are associated with a given executable bundle, and can only be
   opened with that bundle. The favorites can be any set of bundles, whether or
   not these have an ancestry relationship. The XO does not garbage collect
   (GC) old bundles until there are no more instances which use them.
   2. *unbroken thread level* (was called "latest version, but no such
   thing as forks"): All actions are 100% upward-compatible across unbroken
   activity threads (when they aren't, you just break the thread). All actions
   open with latest version in an unbroken thread and "favorite" is an
   attribute of an unbroken thread - the latest version available is the one
   that opens. Broken activity threads are treated as different activities, as
   in bundle level.
   3. *broken thread level* (was called "no such thing as security"): As
   NSTAF, but auto-updates cross breaks in activity threads. If you have both
   sides of a fork, whichever one you got second shows up as a separate
   activity.

[edit
] Ways of modifying one of the main options:

   - There could be some way to manually open an action with a different
   bundle. What is the UI to make this easier?


   - cute extra possibility: when you update your favorite activity to a
   new version, the UI asks you "why did you do that?". If you give an answer,
   this answer is visible in your shared instances of that activity to those
   with lower versions. This is safer than advertising new versions with
   changelogs from the author, since this way by nature they come from friends/
   known sources. Dubbed "user-generated changelogs" on IRC, which moniker
   prompted " homunq: OH MY GOD STOP".


   - "offloading garbage collection": The lower options above can easily
   lead to many actions on the same machine which refer to different bundles
   from the same thread. If disk space is short, it is possible to aggressively
   upload these to the school server, and download them as needed. This can
   lead to actions which do not work until you have connectivity. Note,
   however, that these actions would still be *visible* in the journal and that
   their object contents (the actual files) would still be accessible from
   there. Since we've all lived with just objects, no actions, until now (ca.
   1987 MacOS "Switcher", and other "save workspace" gizmos, aside), I think
   this is acceptable.

[edit
] Ways of combining two of the main options

   - "friendly reminders": Basic behavior is as one of the lower above
   options, but when you get a new bundle which, by one of the higher above
   options, would count as a different version of the same activity, there is
   some UI reminder (icon badges in the favorite view and on actions?) to
   update your favorite and your actions to the new version. Possibilities:
   bundle level with friendly reminders for unbroken threads (1 fr 2); bundle
   level with friendly reminders for broken threads (1 fr 3); unbroken thread
   level with friendly reminders for broken threads (2 fr 3).


   - "Serious magic": keep usage statistics of all bundles on the school
   server, including who manually chooses which bundle version and what their
   choices were. If these statistics show a clear and stable preference for
   version Y over version X, tell all local XOs to make Y a default over X.
   Possibilities: 1 sm 2, 1 sm 3, 2 sm 3.


   - "Serious local magic", where switching from X to Y is auto-defaulted
   the Nth time you do it manually on a given machine. Possibilities: 1 slm 2,
   1 slm 3, 2 slm 3.

[edit
] Not considered

   - "Push" - type updates


   - Blacklists of known trojans (this is only remotely useful if there
   is a limited store o

Re: Build Debate: Followup on Build Naming

[Jameson "Chema" Quinn]

Redundancy is not bad. There are people who care about year (it is far
easier to remember that the last time I updated was 2 years ago, than
remember the build number then) and they should have something to "hold on
to". I vote including the year in addition to whatever else, but not using
it to replace major.

2008/4/10 Samuel Klein <[EMAIL PROTECTED]>:

> Agreed.  The date doesn't need to be in the build #, and only makes it
> longer.
> And I don't know how meaningful it is to have a build named "OLPC" -- as
> noted a few times, we are building more than one thing.  If anything, that
> should be a clarifier at the end noting that OLPC was the 'customizer' of
> the build.
>
> SJ
>
>
> On Thu, Apr 10, 2008 at 11:39 AM, Aaron Konstam <[EMAIL PROTECTED]>
> wrote:
>
> > On Thu, 2008-04-10 at 10:32 -0500, Dennis Gilmore wrote:
> > > On Thursday 10 April 2008, Charles Merriam wrote:
> > > > >  Thanks for formalising this, I would also strongly suggest that
> > the
> > > > >  organisation is moved to the far right, and that we get rid of
> > year.
> > > > >
> > > > >  
> > > >
> > > > I strongly suggest we keep the year.
> > > >
> > > > Yes, really, OLPC should release new software at least once per
> > year.
> > > > It should dump support for software two or more years old.   It
> > should
> > > > release based on time, not feature.
> > > >
> > > > Also, why add a minor-minor (bugfix) number?
> > >  I strongly feel that we should not put the year in releases.
> > >
> > > I personally think that we should use
> > > OLPC-. for the os
> > > so what has previously been called update.1  should be OLPC-2.0
> > >
> > > any bug fixes based on this would be OLPC-2.1 etc
> > >
> > > Dennis
> > The question is really would the date be information that is useful. I
> > am not sure. My feeling is that at the rate things are going with
> > development it would not. Who cares for example if f8 came out in 2007
> > or 2008 and why would that be important information?
> > --
> > ===
> > The means-and-ends moralists, or non-doers, always end up on their ends
> > without any means. -- Saul Alinsky
> > ===
> > Aaron Konstam telephone: (210) 656-0355 e-mail: [EMAIL PROTECTED]
> >
> > ___
> > 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
>
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [sugar] Usability testing

[Jameson "Chema" Quinn]

I'm going to take a flier here...

I live in Guatemala and could try to organize a rural test site here. More
usability data would be the least of the outcomes.

This is obviously not a simple task. Looking at the "give many" numbers
(>100 XOs @ $299; >1000 @ $249; >10,000 @ $199) these numbers are over my
horizon. I know that if I go to local rotary clubs and other such
small-scale funding sources, it will be more than 3 times easier to get
arount $10,000 (50 laptops @ $199 each) than $30,000 (100 laptops @ $299).
Is there any way those "give many" numbers could have 3rd world
pricing/volumes? (On the other hand, I also plan to try to get XOs adopted
by a wealthy private school here; for them, current prices would be fine and
the issue is speedy delivery. You'd have to define "3rd world" not just by
country but by target population.)

I understand that devel and sugar may not be the right places to ask this
question, but I don't really know where the right place is.

Jameson

On Sun, Apr 13, 2008 at 2:56 AM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote:

> On Sun, Apr 13, 2008 at 2:37 AM, Patrick Dubroy <[EMAIL PROTECTED]> wrote:
> >  If there's one conclusion we can make here, it's that we could do a
> >  better job in coordinating our usability efforts. In the next few
> >  days, I'll try to set up a central place on the wiki that can use to
> >  do this. Anyone else who is interested in this can feel free to do so,
> >  of simply get in touch with me to let me know you're interested.
>
> Thank you very much, the developers have no means to organize such
> things, so the only way I see is the community stepping up and
> organizing themselves.
>
> I have heard discussions inside OLPC about the need of using usability
> testing in order to gather a better understanding of how the UI
> decisions work when a kid is finally put in front of Sugar. I think
> we'll see at some point OLPC resources dedicated to this task, but I
> don't think it's wise to wait for that to happen.
>
> In my opinion, things would work better if an OLPC employee/contractor
> is later integrated into an existing wider community effort for
> usability improvement, rather than people waiting for things to happen
> from OLPC.
>
> Thanks again,
>
> Tomeu
> ___
> Sugar mailing list
> [EMAIL PROTECTED]
> http://lists.laptop.org/listinfo/sugar
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: More planning thoughts

[Jameson "Chema" Quinn]

Here's my POV on the issues...


   issue

affects all users

affects all developers

radical change suggested

tolerability of current state of affairs

how hard to improve

power management

6

2

?

5

3

mesh

6

4

6

4

5

both of the above together




 7

datastore

8

8

10

3

5*

sugar UI

8

4 (many changes are inside sugar)

5

6

3-5*

collaboration

6

6

6

7

3*

compatibility/

interoperability

2

7

4 (mostly clever hacks)

6

3

performance

8

2

4

6

5


* Requires work by activity developers.


... As you can probably see from the above table, I'd vote putting the
datastore first in line, as it is the one issue which causes data loss.

More later,
Jameson
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [sugar] Recursive Signal Loop.

[Jameson "Chema" Quinn]

I may not be understanding this right, but what if the CollapsedEntry, when
it got the signal, checked if it was actually going to have to change the
jobject, and if it was already kept, it would just abort? This would quash
the signal the second time around - one step more than strictly
necessary/ideal, but I don't know how to convince gtk not to send the signal
if it was already pressed, which is what would be necessary to quash it
exactly the first time.

Either that or on this step:

and updates the
entry as required.  This includes setting the keep property

you check the keep property before you set it, and do not touch it if you
are not going to change it.


On 4/24/08, Eben Eliason <[EMAIL PROTECTED]> wrote:
>
> Hello, my name is Eben Eliason, and I have a problem...
>
> Symptom: The keep buttons in the Journal (the stars) take 1 second or
> so between being clicked and visually reflecting that change.  This
> is, admittedly, a rather minor problem, but as you'll see, it spells
> out a larger underlying ugliness.  I expect the feedback to be instant
> both because it's better that way, and also because the identical
> (well, nearly so, as shown below) favorite icons used in the list view
> of the new Home already function perfectly, and quickly.
>
> Diagnosis: Upon inspection, the KeepIcon class used in the Journal
> differs from the FavoriteIcon class used in Home in one crucial way.
> The former does not connect to a button-release-event at all, and
> instead depends on the code which uses it to do so for it, take the
> necessary actions based on the toggle, and then tell the KeepIcon
> itself that it has been clicked on in order to update its internal
> state and reflect that with visual changes.  This is obviously the
> incorrect approach to the problem, as the KeepIcon should abide by all
> the wonderful properties that makes object oriented programming
> useful, manage its internal state so that, if nothing else, it remains
> consistent when clicked (it's basically a checkboxa boolean
> toggle), and notify anything that may happen to care about its value
> when it changes.
>
> Treatment: Take the object oriented approach above, which works nicely
> in Home, and should also work nicely in the Journal.  This cleans up
> the code, and allows the KeepIcon to update its internal state
> immediately before emitting the signal, thus redrawing before anything
> which wishes to be notified of its state has a chance to waste lots of
> time, slowing feedback.
>
> Side-effects: This is where things get ugly.  The above changes were
> trivial, but they create an ugly signal loop which makes the treatment
> worthless in its purest state as described above.  Here's what goes
> down:
>
> When a KeepIcon is clicked, its button-release-event handler updates
> its internal state, including its keep property, which thus emits a
> notify::keep signal.  The CollapsedEntry object which contains the
> KeepIcon connects to this signal in order to update the value of the
> keep key in the metadata of the associated JObject.  So far so good.
> The DS then emits an updated signal, which includes a reference to the
> JObject which has been updated.  Off in Never-Never-Land, query.py is
> listening for the update signal from the DS, and the handler for this
> signal replaces the JObject in its internal dict, and then emits its
> own modified signal.  The listview.py connects to the modified signal,
> and its handler then calls self._do_scroll, which in turn calls
> self._refresh_view.  The latter of these functions takes it upon
> itself to loop over all of the CollapsedEntry objects visible on
> screen, updating a match for the changed JObject by setting its
> corresponding jobject property.  The method responsible for handling
> the setting of this jobject property within the CollapsedEntry then
> reads all of the info out of the newly passed JObject, and updates the
> entry as required.  This includes setting the keep property of the
> KeepIcon within the entry, which cannot assume that it has previously
> been set, since this is also the function that gets called to
> initialize the CollapsedEntry in the first place.  This, of course,
> triggers the do_set_property of the KeepIcon, which in turn emits a
> notify::keep signal. Hooray.
>
> Treatment of side-effects: Anyone know the best way to handle this
> issue?  I'm fairly convinced that the fundamental changes to the
> KeepIcon class suggested above are the correct approach logically and
> semantically.  I'm unsure about the correct way to sever the recursive
> loop, however.  Any thoughts are very much appreciated, since I've now
> spent considerable time messing with an issue that I thought would
> have a 10 minute fix.
>
> - Eben
>
> PS.  Thanks for listening!
> ___
> Sugar mailing list
> [EMAIL PROTECTED]
> http://lists.laptop.org/listinfo/sugar
>
___
Devel mailing list
D

Re: Journal Suggestions

[Jameson "Chema" Quinn]

>
> storage.  The mechanisms required for handling removable media, USB hard
> drives, and networked storage, are all essentially the same.
>

++

Technically, I think this would mean that the metadata are stored on the
NAND, with some UID of the associated file. The file, if not present on the
NAND, would be looked for on SD, USB, and then server, in that order.

ps to Mikus: I think the "slowness" of NAND is due to the automatic
compression (and of course decompression) of JFFS. This is based on no data,
just intuition. I would be interested to know if there are any comparative
speed tests with/without this feature.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Rainbow 0.7.12 Announcement

[Jameson "Chema" Quinn]

Current versions of Develop should not need special dispensation. Versions
up to about 24 did need it.

On Tue, May 6, 2008 at 9:16 AM, Mikus Grinbergs <[EMAIL PROTECTED]> wrote:

> Earlier, I had written:
> >Of various Activities to which I previously gave "special dispensation"
>  >from Rainbow, three now launch from the activity ring without
> needing that
>  >dispensation -- Develop, Sonata, and Opera.
>
> I spoke too soon.
>
> I'm not familiar with 'Develop', so I don't know how it was affected
> by Rainbow.  But the other two Activities use /home/olpc/.something
> for their files (Sonata: .mpd; Opera: .opera).  In both cases, the
> new Rainbow "substituted" isolation paths which were different, so
> the existing configurations of those Activities were not accessed.
> [Query - does Rainbow respect case?  Sonata refers to '.mpd/Music'.
>  With Rainbow the substitute name was 'isolation-something/music'.]
>
> I've now reverted to excluding Sonata and Opera from Rainbow.
>
> mikus
>
> ___
> 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: very simple datastore reimplementation

[Jameson "Chema" Quinn]

>
> I think expanding the space available to the DS through usb devices or
> sd cards is a use case we should take in consideration when designing
> the DS, even if we don't plan to support it right now.
>
> Marco
>

To be more clear about this use case: I think that there should definitely
be a way for the onboard datastore to store the metadata for an absent file,
with hints about what place(s) to find that file (networked backup, sd
cards, usb devices) and how to recognize it when you do. This should include
the possibility for offloading old intermediate versions. Then, even when
you do not have access to the backup storage, you can see what you are
missing. This makes the result of suddenly yanking the SD card out more
well-defined (assuming no filesystem corruption), and means you do not ever
have to merge/separate two indexes (there is just one index).

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

Re: very simple datastore reimplementation

[Jameson "Chema" Quinn]

On Fri, May 9, 2008 at 6:43 PM, C. Scott Ananian <[EMAIL PROTECTED]> wrote:

> On Fri, May 9, 2008 at 2:26 PM, Joshua N Pritikin <[EMAIL PROTECTED]>
> wrote:
> > On Fri, May 09, 2008 at 12:10:07PM -0600, Jameson Chema Quinn wrote:
> >> To be more clear about this use case: I think that there should
> definitely
> >> be a way for the onboard datastore to store the metadata for an absent
> file,
> >> with hints about what place(s) to find that file (networked backup, sd
> >> cards, usb devices) and how to recognize it when you do. This should
> include
> >> the possibility for offloading old intermediate versions. Then, even
> when
> >> you do not have access to the backup storage, you can see what you are
> >> missing. This makes the result of suddenly yanking the SD card out more
> >> well-defined (assuming no filesystem corruption), and means you do not
> ever
> >> have to merge/separate two indexes (there is just one index).
> >
> > I was surprised to read this. My opinion is that the index should only
> > include files which are available on local storage. Otherwise the index
> > can fill up with broken links, and it will be difficult to explain why
> > the broken links don't work. Access to backups is a good idea, but not
> > via such a by-default mechanism.
>
> http://wiki.laptop.org/go/Olpcfs#Absent_content_and_merging_remote_stores
>  --scott
>
> --
>  ( http://cscott.net/ )
>

Let me be a little clearer still about what I am envisioning. I do not
imagine that, except in rare cases (restore after total data loss) the
journal would ever scan external/network storage for an absent file, or
explicitly import one or more files (as distinct from opening them or
otherwise doing something meaningful with them, using a traditional
tree/folder view). The journal index would know exactly where things were,
but only if it put them there itself, or had used them there itself. It
would then keep track of whether the containing volume/resource was
available and show the links as broken/real on that basis. If the file had
been deleted foreignly, it might mistakenly show as available but turn out
to be unavailable when clicked on.

This model has several advantages. It does not require any scanning on
mount; it does not add files to the journal if they have never been used;
and its behaviour is generally understandable and predictable. If I am
reading c_scott's link above correctly, it is not precisely what was on his
mind, but it is supported by the same capacities of olpcfs, with the
addition of an index by storage volume and some metadata (indexed only if
you need to search it) for external path(s).

A couple of UI points:
- broken links could be filtered out by default in most views, but it would
be a simple boolean switch (checkbox or the sugar equivalent) in the
interface to show them.

-If UID can hide in the metadata, which, if I understand, is preserved as
part of the file even on foreign (unix-only?) filesystems (wow!), I do not
see any compelling reason for it to be in the filename. Locally-stored files
could have their real filenames, with 2 random characters at a time added in
case of collisions; for external storage, collisions could simply be
forbidden, and you could rename or choose a different directory.

-some file formats already include a compatible metadata spec - for
instance, an MP3 file already specifies artist. a by-format plugin api to
keep the olpcfs metadata in sync with this metadata would be a nice future
feature.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: very simple datastore reimplementation

[Jameson "Chema" Quinn]

>
> -If UID can hide in the metadata, which, if I understand, is preserved as
> part of the file even on foreign (unix-only?) filesystems (wow!), I do not
> see any compelling reason for it to be in the filename. Locally-stored files
> could have their real filenames, with 2 random characters at a time added in
> case of collisions; for external storage, collisions could simply be
> forbidden, and you could rename or choose a different directory.


I re-read the OLPFS page on the wiki and realized that, of course, metadata
needs to be kept separately on external VFAT devices. I also realized that,
even if all the metadata is in the index, it is scattered all over - you
need an explicit copy for efficiency. I think that this copy should be, by
default, on internal flash; that the external metadata copy in a hidden
directory (separate per-file) should be used only on import (that is, when
opening a file off external storage causes importing it). This could be the
same mechanism as the metadata-synching plugins I envisioned - whenever
adding something new to the journal, metadata would be imported, and after
that, any metadata changes from the journal would be copied to external
backup.

Jameson
ps. yes, I realize that this thread has morphed from a discussion of tomeu's
thing to OLPCFS, but I am leaving the subject for reference)
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [sugar] OLPC priorities for Sugar in the August release

[Jameson "Chema" Quinn]

One low-hanging fruit for faster activity start is having activity install
compile .pyc files, with (tiny) extra points if the .pyc gets hints to not
use jffs2 compression. This is on my gameplan with the bundle format update
stuff, but I have gotten stuck on the signatures (openssl cannot read ssh
public keys) so I am behind on that. I had hoped to finish it in my free
time this week but starting next week I cannot be so sure I'll have time.

On Wed, May 14, 2008 at 6:57 AM, Marco Pesenti Gritti <[EMAIL PROTECTED]>
wrote:

> On Wed, May 14, 2008 at 1:46 PM, Mikus Grinbergs <[EMAIL PROTECTED]> wrote:
> > >  * More responsive UI - faster launch of activities
> >  >
> >  > Is the solution currently in joyride satisfactory for the August
> release?
> >
> >  I use a recent Joyride on my G1G1.  My average time to launch Browse
> >  (from the time I click in the F3 Activity Ring on the Browse icon,
> >  to the time when I can click on the entry field in Browse itself (so
> >  that I can start typing in an URL) is 25 seconds.
>
> If you could download the latest joyride, time startup and open a
> ticket that would be useful. 25 seconds are too much obviously.
>
> Please take both time on the very first start and after a reboot,
> xulrunner does component registration on the very first start which
> could be expensive
>
> Thanks.
> Marco
> ___
> Sugar mailing list
> [EMAIL PROTECTED]
> http://lists.laptop.org/listinfo/sugar
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Priorities for Develop?

[Jameson "Chema" Quinn]

I am planning to apply to OLPC for a job as a contractor, working on
Develop. I have been told that my first-priority feature, automatic code
localization , would be hard to
justify on the OLPC roadmap. So I'd like to hear some votes/priorities on
the following "dream" features, listed roughly from easiest to hardest (+/-
two slots):

1. auto-pylint
2. doctools
3. peekaboo-like (figleaf with xmacro - throw autogenerated events at an
activity, watch coverage, and log stack traces. When I worked at
Palm/3Com/PalmSource, they called it "gremlins".)
4. autocompletion
5. move towards collaboration, starting with support for merges and
changelogs (new-version notification and real-time collaboration would both
come later than this)
6. automatic code localization (program in Python with
Spanish/Chinese/whatever keywords, but it is real python on-disk)
7. debugger
8. Gui designer (a la glade)
9. other (bug tracking)

(for those unfamiliar with Develop currently, it has source coloring, good
find-replace, log viewing, rudimentary version control through the journal.
Currently I am working on updating Sugar's bundle format, this will make
Develop more useful for existing activities, and make sugar smarter about
updates; for instance you will be able to have a dev version and a stable
version of your activity coexist on a given XO. This current work would be
done before I would even begin with anything from the above list.)

Personally, I would most like to work on feature number 6 (code
localization). In my view, with hundreds of thousands of Spanish-speaking
kids on the xo, this feature would be, not only a great addition to the
education mission of OLPC, not only (if done right) an advancement for
computer science in general, but also an investment in getting future
activities written. So I would be happy if that got a broad acclaim of
support. But I want to be able to feed my family and code for the XO at the
same time, so I will apply for a contract with whatever looks to me has the
best cost/votes ratio.

For easier voting, I have pretty much copied this same email to
http://wiki.laptop.org/go/Develop/roadmap . Feel free to vote here on mail
if you have something to contribute to the discussion, and I will copy any
results of this thread to that page, but if you just have some votes you can
just vote there.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Priorities for Develop?

[Jameson "Chema" Quinn]

OK, here's the status on your list. In general, I had taken it as a given
that most of what you said would work before I moved on.


> Develop should be really really good at creating new activities, and
> editing existing ones, without any need for using Terminal and other
> editors. That should be stable, reliable and effective.
>
> Features required for this, IMHO, are:
> * Integration with the View Source key for arbitrary activities


For arbitrary *python* activities, all necessary code exists. View source
would rebundle current activity and take you to the journal where you could
open it. (Minor missing UI: that bundle should default to editing instead of
running - needs new journal features.) I'm waiting for a few joyrides which
include my other patches before pushing this as a patch.


>
> * NO TOTAL LOSS OF JOURNAL CONTENTS.


Haven't seen it in months. Datastore should be made more sturdy anyway. I
know that this answer is lame, but how do I debug what I can't now
reproduce?


>
> * No need for DoppelJournal


The two necessary patches have existed for months now, Tomeu had promised to
review them, but that is apparently going slowly.


>
> * Support for editing single file activities


Not on my roadmap - that is Pippy's job (unless you mean "editing n-file
activities where n=1").


>
> * Support for editing multiple file activities


check.


>
> * Producing valid activity bundles as they now exist


check*

*currently also very easy to lose changes by producing invalid activity
bundles by munging MANIFEST. This is the main motivation for updating bundle
format, hopefully this should be fixed soon.


>
> * Access to activity/activity.info


check. Text-only access, no smarts included. This is generally the plan,
except as indicated below.


>
> * Icon editing for activity/*.svg


No svg editor on XO, not a current plan. Mid-term plan: export and import
subfiles as separate journal entries, an easy change. Long-term plan:
journal understands subfiles natively (this is part of eben's plan for
journal).


>
> * Ability to easily continue editing an activity (keep version number,
> service name, other metadata) or do a new release (increment version
> number) or fork (change relevant metadata)


Currently works, just by editing activity.info. To make this "smarter"
requires new bundle format. Once new bundle format exists, I intend toolbar
support for all of this; this would auto-edit activity.info among other
things. You would still have text access to activity.info.


>
> * Ability to start a new activity, populated with relevant minimum
> boilerplate code (Hello World) that runs immediately and can be worked
> on immediately ("Look, I did a program!")


Planned, unimplemented. Pretty simple (basically means including a hello
world bundle template inside the activity).


>
>
> Some of the above require changes to Sugar or Journal. Take that as
> your responsibility to keep those patches up to date and get them
> reviewed and merged.


I don't know how much more I could bug Tomeu for the two existing patches,
or what else I should be doing. He definitely knows they exist and I bug him
once a week or so.

...

>
> As a lower priority feature, I would be interested in seeing the
> ability to view (and possibly edit) python "system" (non activity)
> code, including sugar, sugar-toolkit (sugar libs), presence service,
> journal, datastore. As someone said of having a Free Software kernel
> on the XO, it's not like the kids will start developing the platform,
> but at least they will see that it is developed by mere mortals and
> say "Oh, Python! So *I* can get from here (my simple activity) to
> there (sugar itself)!"
>

well, for Journal this is an easy change. The rest sounds like a good idea,
but honestly I think it should be a separate activity - trying to shoehorn
it into Develop would clutter the interface IMO. I may be wrong, ESPECIALLY
if Develop gets some dream features (class browser? I added that to the
voting list on the dream page).

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

Re: Priorities for Develop?

[Jameson "Chema" Quinn]

On Fri, May 16, 2008 at 5:50 AM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote:

> 2008/5/16 Jameson Chema Quinn <[EMAIL PROTECTED]>:
> >> * No need for DoppelJournal
> >
> > The two necessary patches have existed for months now, Tomeu had promised
> to
> > review them, but that is apparently going slowly.
> >
> >> Some of the above require changes to Sugar or Journal. Take that as
> >> your responsibility to keep those patches up to date and get them
> >> reviewed and merged.
> >
> > I don't know how much more I could bug Tomeu for the two existing
> patches,
> > or what else I should be doing. He definitely knows they exist and I bug
> him
> > once a week or so.
>
> My fault, these days I'm trying to not assume more responsibility than
> what I'm capable to, and at the same time push Sugar forward. It's not
> being easy.
>
>
> Tomeu
>

You do a great job, Tomeu. I guess you realize that the above was not meant
as criticism, just as creative pressure, but I should have said so anyway.

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

Re: Priorities for Develop?

[Jameson "Chema" Quinn]

>
> >> * NO TOTAL LOSS OF JOURNAL CONTENTS.
> >
> > Haven't seen it in months. Datastore should be made more sturdy anyway. I
> > know that this answer is lame, but how do I debug what I can't now
> > reproduce?
>
> Perhaps you should revise http://wiki.laptop.org/go/Develop then :)
>


I don't trust magic fixes. (btw, I believe that this problem was xapian
corruption due to xapian not flushing correctly. I will update the page when
datastore can recover from xapian corruption.)


>
>
>
> > *currently also very easy to lose changes by producing invalid activity
> > bundles by munging MANIFEST. This is the main motivation for updating
> bundle
> > format, hopefully this should be fixed soon.
>
> I'm sure a sanity check of MANIFEST wouldn't be hard to add - make
> sure all files are listed - but not a high priority I'm sure.
>

On the contrary, this is my top priority, and what I am working on. But I´m
doing a comprehensive fix to bundle format, not just a band-aid. (partly
because there are many existing activities with broken MANIFEST, partly
because sugar's versioning/installation is currently too rudimentary to
support a decent Develop workflow). Dataloss is not good, and when the
target audience is kids you can't blame the victim. Activity.info can
be manual - errors are fixable - but MANIFEST must be bulletproof, because
errors mean dataloss.

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

Re: Google Summer of Code project, sugarbot

[Jameson "Chema" Quinn]

Hey Zach. I'm the maintainer for the Develop activity, over the long term
I would love to have this functionality in Develop. Got to go now, but we
definitely have to talk. You should start hanging out on the IRC channels -
I am homonq (actually I misspelled that to keep google from caching my real
name with my nickname, but you will recognize me).

On 5/16/08, Zach Riggle <[EMAIL PROTECTED]> wrote:
>
> Hello All
>
> My name is Zach Riggle, and I am participating in the Google Summer of Code
> this year.  I am working under the Python Software Foundation, under the
> mentorship of Grig Gheorghiu and Titus Brown.  My project, sugarbot, (you
> can find more information here: http://code.google.com/p/sugarbot/) is to
> implement a library or application that allows for GUI automation and
> testing for Sugar.  Because Sugar is unique in the world of GUI's, its
> automation library also requires a few unique features.  I am using a few
> existing Python GUI automation libraries to help me get started, and have
> high hopes for the project.
>
> You can track development progress at the sugarbot blog (
> http://gsoc-sugarbot.blogspot.com/).  If anyone has any recommendations,
> advice, best practices, or wants to offer their brain for me to pick, just
> send me an email.
>
> [My apologies if this gets sent to the mailing list twice.  I sent it
> yesterday, to [EMAIL PROTECTED], and didn't see it show up on any of
> the digests]
>
> Thanks,
> Zach
>
> ___
> 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: [PATCH] Maintain a metadata copy outside the index (was Re: Datastore & backup - request for help)

[Jameson "Chema" Quinn]

Yay, I am happy about this patch (when there is a patch :)

>
> > - at every create and update, a json file is created next to the object's
> file,
>

I definitely think it should be in the same directory as the object file,
with a related name. It might even be worth using the macintosh ._name
naming convention.

(Note that when we have directories as bundles, bundle-level metadata can
live in a ._. file. If all bundles had some kind of manifest, then any
subfiles which are used separately could grow their own metadata in
._subfile ; as long as that file were not in the manifest, it would not be
packed up when exporting the bundle to foreign storage.)

>
> >
> > - it's also deleted along the object,
> >
> > - at startup, if the file /.metadata.exported doesn't
> > exist, check how many objects need to get their metadata exported
> > (0.8s for 3000 entries)
>
> That's pretty good.
>
> > - in an idle callback, process each of those objects one per iteration
> > (3ms per entry with simplejson, 2ms with cjson).
>
> Exporting a few 100 per iteration probably is more efficient ;-)


This brings up the issue of TamTam imperfect timing - it would be great if
there were some way to turn off all unnecessary background CPU use for cases
like TamTam. If so, I'd say 12*3ms is about the right size for a background
click every second or two.

>
>
> > In my tests this has worked quite well, but I have one concern: can
> > something bad happen if we have 20k files in the same dir (for a
> > journal with 10k entries)?
>
> Ok, we can split it into a subdir (which will only have 10K files then).
>
> If there's a cost to large dirs in jfffs2 then we can use hashed dirs,
> and that change will be needed for both the main datastore storage
> _and_ the metadata files.


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

Re: [PATCH] Maintain a metadata copy outside the index (was Re: Datastore & backup - request for help)

[Jameson "Chema" Quinn]

But AFAICT json.py is the only one that supports "canonical json" (and even
that support is incomplete - there is no checker / strict decoder). Is there
any plan to move this "canonical" stuff into simplejson? I would like to
have it available for signature/crypto stuff - unless people think that I
should drop all json from signatures, instead using asn.1 and shoehorning
our signatures into PKCS7 format (in itself, not a bad fit; but to do the
whole job of PKCS7 implies supporting x.509, which is a standard everyone
uses but nobody likes).

Jameson

On Sat, May 24, 2008 at 1:57 AM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote:

> On Sat, May 24, 2008 at 2:56 AM, Martin Langhoff
> <[EMAIL PROTECTED]> wrote:
> > On Fri, May 23, 2008 at 8:19 PM, Tomeu Vizoso <[EMAIL PROTECTED]>
> wrote:
> >> Ouch, sorry, I should have been more explicit in that this patch
> >> introduces a dependency on cjson. I'm going to send next another patch
> >> that falls back to simplejson (slower) if cjson is not available.
> >
> > Ah, it was pebkac after all. I thought cjson was in the box.
> > Simplejson is not though (json.py is).
>
> simplejson is in joyride (not in u1), json.py is not maintained and
> only accepts the basic python types (not dbus.String, for example).
>
> Regards,
>
> Tomeu
> ___
> 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: [sugar] Release process

[Jameson "Chema" Quinn]

>
> Finding the balance of authority between these two people is IMHO a
> critical strategic issue.


yes.


> Without an explicit decision, there will be
> tension.
>

But some tension is good.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Bitfrost and dual-boot

[Jameson "Chema" Quinn]

Bitfrost protections are meaningless if they only work half of the time. If
you have a dual-boot box, how can one OS keep its protections even if the
other half is considered untrusted code? This is of course even harder
without passwords.

However, it is not impossible, with help from the firmware. Here are the
beginnings of one scheme:

An unactivated XO would have a blank space in the firmware for a key.
During activation, the OS would generate an RSA key and give it to the
firmware. It would also make any backups of that key that were necessary -
During boot, the XO would enter one of three states:
If booting with a signed OS, it would be "key-responsive". The
firmware would, on a special system call, encrypt/decrypt one block of data
using the private key. (one block is enough to sign a hash or encrypt a
session key). This system call would be available only to root. There would
be no way, even for root, to read the key itself.
If booting with an unsigned OS, it would be "key-unresponsive".
There would be no access to the key at all.
If booting with a particular cheat code (hardware buttons held
down), it would be "key-permissive". The private key could be read or
written.

Also, any OS in local flash would have its core files (kernel and anything
that could execute as root) in protected flash, other OS's would not be able
to write to this flash.

Those with a developer key would be able to mark an OS on their machine as
"signed".

With this system in place, it would be possible to protect against the worst
abuses from the untrusted OS. It might still be able to read or write in the
other OS's data, but the other OS would use encryption to keep private data
from being read, and signatures to keep invalid data from leading to
escalated privileges. So the worst the rogue OS could inflict would be
dataloss; the temptations for virus writers would be minimized.

What do people think? Is this a real problem? Is my hand-waving the
beginnings of a solution, or why not?

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

Re: Bitfrost and dual-boot

[Jameson "Chema" Quinn]

Actually, the goals are more limited. Say you have dual-boot; OS 1 has
bitfrost, OS 2 does not. Things OS 2 should not do:

1. Read private files from OS 1.
1a. Read encryption key from OS 1, thus subverting all security which that
key gives. This, in particular, should be avoided.
1a(i). By reading unitialized memory, snoop passwords which OS 1 had only in
volatile memory. This threat was not mentioned in my initial email because
such passwords are not envisioned by Bitfrost as being part of sugar - it is
the one case where OS 1 could be windows. However, it is easy enough to
prevent by clearing volatile memory on reboot. This would give the XO, which
has soldered-on RAM, better security characteristics than any laptop I know
of (until the macbook air updates its firmware).

2. By writing to OS 1's file system, subvert the bitfrost security within OS
1 itself, such that even if OS 2 is later deleted, malware can now do bad
things inside OS 1.
2a. By simple changes to files that should be writeable within OS 1 - that
is, chmod on a data file, or changing a file of user-granted extra Bitfrost
privileges.
2b. By changes to files that could be read-only within OS 1 - that is, by
replacing the kernel or bitfrost-related code or binaries.
2c. Do 2a and/or 2b in such a way that they are not detectable, or not
fixable simply through a reinstall. In other words, I would like to be able
to say "I just removed a major trojan from my Windows, please rescan Sugar
to ensure that system files have not been changed" or, more simply,
"reinstall Sugar".

3. Cause denial of service by erasing or changing files necessary for OS 1
to run.

4. Cause dataloss by erasing or changing OS 1's data files.

5. Insert data into OS 1's journal by writing new data files.

...

I am only focused on preventing 1 and 2 here. In particular, I think that 1a
and 1a(i) are worth considering. Also, If 2b is deemed impractical to guard
against, 2 may be acceptably addressed only by 2a and 2c.

3 would be very hard to accomplish. However, security measures to prevent 2b
should also help mitigate the risks of 3.

5 is arguably even desirable, and it is impractical to allow 5 without
allowing 4, so these should not be considered.

...

Ivan, could you elaborate on why you think that this is not a "good
extension of the threat model"? Do you believe that these threats is not
real, or do you believe that it will be impossible to guard against them, or
other?

Jameson

On Wed, May 28, 2008 at 7:01 PM, Ivan Krstić <
[EMAIL PROTECTED]> wrote:

> On May 28, 2008, at 8:33 PM, Benjamin M. Schwartz wrote:
>
>> What are you trying to prevent?
>>
>
>
> He doesn't want one OS to be able to screw with files from another in a
> dual-boot scenario. I don't think it's a good extension of the threat model.
>
> --
> Ivan Krstić <[EMAIL PROTECTED]> | http://radian.org
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Bitfrost and dual-boot

[Jameson "Chema" Quinn]

I just had an IRC conversation with Benjamin Schwarz in which we talked
about:

He said that 3,4, and 5 have been considered more serious than 1 and 2;
since they are impossible, there is little point doing 1 and 2. I disagreed.

There is no way with current hardware to write-protect the NAND storage, and
not too much space (<<512K) in the firmware storage. However, it would be
possible to hash NAND or some subset thereof, and complain loudly on boot if
it changed. Blanking RAM on reboot, and keeping the private key in firmware
instead of NAND are also possible.

There is little point spending much energy on this issue until more of
Bitfrost is in place.

Once this becomes salient, it might be worth doing something along these
lines. Also, it might be another good argument against dual-boot, especially
with highly insecure OS's like Windows.

On Thu, May 29, 2008 at 11:48 AM, Albert Cahalan <[EMAIL PROTECTED]> wrote:

> Jameson "Chema" Quinn writes:
>
> > Actually, the goals are more limited. Say you have dual-boot;
> > OS 1 has bitfrost, OS 2 does not. Things OS 2 should not do:
> >
> > 1. Read private files from OS 1.
> ...
> > 2. By writing to OS 1's file system,
>
> I do believe that, practically speaking, all of this is moot.
> Windows uses both SD card storage and the NAND flash storage.
>
> (NAND storage being what you'd hoped to protect)


I did not hope to protect all of it. I hoped to use encryption and/or
signatures to limit the kinds of damage that could be done.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Bitfrost and dual-boot

[Jameson "Chema" Quinn]

2008/5/29 <[EMAIL PROTECTED]>:

> On Thu, 29 May 2008, Jameson "Chema" Quinn wrote:
>
>  I just had an IRC conversation with Benjamin Schwarz in which we talked
>> about:
>>
>> He said that 3,4, and 5 have been considered more serious than 1 and 2;
>> since they are impossible, there is little point doing 1 and 2. I
>> disagreed.
>>
>> There is no way with current hardware to write-protect the NAND storage,
>> and
>> not too much space (<<512K) in the firmware storage. However, it would be
>> possible to hash NAND or some subset thereof, and complain loudly on boot
>> if
>> it changed.
>>
>
> not really, you would have to hash NAND on every shutdown. remember
> everything you do is in thr journal on NAND, and any change (including
> things like a file timestamp, including atime) will invalidate your hash.
>
> David Lang
>
> The idea would be to have a separate read-only volume on NAND, which
included everything executable as root (in other words, 90-100% of glucose
and ribose; the kernel, though, is already signed, so could be elsewhere).
Mounting this ro would prevent silly atime breakage, and there could be
strong protections to prevent anything NOT on this volume from being
considered "executable" by root. (Of course, this is not the whole story, as
there are uncountable ways for non-"executable" stuff to compromise
security; but it is a start. It would break any rpm's that only know how to
run as root - but these are broken anyway.)
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Bitfrost and dual-boot

[Jameson "Chema" Quinn]

> if you run everything as user olpc and user olpc can become root without a
> password, getting olpc is as good as getting root.


An arbitrary process running as user olpc should not be able to get root. My
impression is that it cannot, currently; am I wrong?

>
> not to mention the fact that you would need to audit every program to see
> what it will do with the data you feed it (if anything reads something from
> a file and then executes arbatrary commands based on it, you've lost)
>

If it switches to run as another user (or otherwise reduces its own
destructive capabilities) before doing so, not so. This is the principle
that Bitfrost is built on: ways to run untrusted code.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Project hosting application: Bundlemaker

[Jameson "Chema" Quinn]

Cool! I would call this "bookbinder" if it were an activity.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

While we're on Cerebro, Telepathy, etc... Cerebro + bitfrost?

[Jameson "Chema" Quinn]

Somewhat off-topic, but I want to get this idea out there. Disclaimer: I am
suggesting a mechanism for extra security that would build beyond bitfrost,
when we have yet to implement the relevant part of bitfrost in the first
place. If you think it is a waste of time to look beyond the next step, no
need to read on.


What is bitfrost's P_NETWORK trying to prevent? Some examples of
network-based misbehavior, which live entirely within bitfrost's bounds
otherwise:

- A spyware version of Browse, which reported all sites visited to an
specific URL.
- A spyware version of Write, which reported all texts written to a specific
crimethink-checking server.
- A bot-net slave, which periodically called a given server, and then
followed its orders to post spam comments on bulletin boards and blogs.
(This would run against the network rate limit, but could still potentially
do damage without breaking the rate limit).

On the other hand, some examples of legitimate network uses:

- Browse - able to go to an arbitrary URL
- Email - Able to talk to a given server (and thus to cause that server to
send messages to an arbitrary IP).
- Chat - able to connect to a friend/friends *visible in the frame* and
exchange messages with them.
- Write - able to share with a friend/friends, again *from the frame*, and
exchange state update data with them.

As things stand in the bitfrost spec, there is no way to prevent any of the
illicit actions without preventing all of the legitimate ones. This is a
problem, because the Sugar ideal is to make all activities shareable - that
is, essentially comparable to Write. It does not have to be that way.

One nice thing for a high-level comunications layer like Telepathy would be
if it would support bitfrost by being (in some configuration) solidly safer
than free network access. If an activity could be authorized (through user
actions in the frame) to talk to only certain "friends" (ie, ip addresses),
it would drastically reduce the possibility that the activity would break a
user's privacy. Thus, there would be three kinds of activities:

those with full network access, able to talk to arbitrary IP addresses
(browse is inescapably in this category);

those with some kind of "telepathy-only" access, which would only let them
talk to IP addresses that correspond to a friend sharing the specific
activity instance (Chat might fit here; certainly, Write would);

and those with no network permissions.

The telepathy-only, middle security level would allow the last two "good"
use cases, while preventing the last two "bad" use cases. It could be
implemented by sugar giving them some kind of key, valid only for that
specific instance (and renewed when the instance is resumed) that they could
use to "unlock" access to a given IP. I understand that the middle security
level would not necessarily be perfect - a man-in-the-middle attack could
well subvert any gains, and, especially in early versions, it would be hard
to guarantee that any abstraction layer was 100% successful at keeping
malformed requests from getting some illicit control over a lower layer -
but it would drastically reduce the practicality of any large-scale
snoop-net or bot-net for your average shareable activity. Assuming that the
connection to friend X was compromised; an activity would still have to hope
it was started with an instance that had been shared with friend X in order
to leak any data.

Go ahead - tell me why it's a bad idea.

Your friendly neighborhood security speculator,
Jameson Quinn
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: While we're on Cerebro, Telepathy, etc... Cerebro + bitfrost?

[Jameson "Chema" Quinn]

On Wed, Jun 11, 2008 at 3:08 AM, Bert Freudenberg <[EMAIL PROTECTED]>
wrote:

> On 11.06.2008, at 03:37, Jameson Chema Quinn wrote:
>
>  Thus, there would be three kinds of activities:
>>
>> those with full network access, able to talk to arbitrary IP addresses
>> (browse is inescapably in this category);
>>
>> those with some kind of "telepathy-only" access, which would only let them
>> talk to IP addresses that correspond to a friend sharing the specific
>> activity instance (Chat might fit here; certainly, Write would);
>>
>> and those with no network permissions.
>>
>> The telepathy-only, middle security level would allow the last two "good"
>> use cases, while preventing the last two "bad" use cases. It could be
>> implemented by sugar giving them some kind of key, valid only for that
>> specific instance (and renewed when the instance is resumed) that they could
>> use to "unlock" access to a given IP. I understand that the middle security
>> level would not necessarily be perfect - a man-in-the-middle attack could
>> well subvert any gains, and, especially in early versions, it would be hard
>> to guarantee that any abstraction layer was 100% successful at keeping
>> malformed requests from getting some illicit control over a lower layer -
>> but it would drastically reduce the practicality of any large-scale
>> snoop-net or bot-net for your average shareable activity. Assuming that the
>> connection to friend X was compromised; an activity would still have to hope
>> it was started with an instance that had been shared with friend X in order
>> to leak any data.
>>
>
>
> Err, hasn't that been the plan all along? P_NETWORK is only given to
> activities needing full network access. It is independent of sharing. An
> activity wanting to share must use telepathy, period. Your "no network
> permissions" above case does not exist separately, it is the same as
> "telepathy-only".
>
> - Bert -
>


It is great to hear that this is not a new idea. Looking back at the
implementation speculation, m_stone's
http://cr.yp.to/unix/disablenetwork.html idea would, of course, not prevent
access to a service like Telepathy which is available over DBus. Still, from
my outsider perspective, it is not quite fair to say that it is "the plan
all along". Here's what I've seen of the plan: (the bitfrost spec, emphasis
mine):

"Each program's network utilization can be constrained in the following
ways:

   - * Boolean network on/off restriction*
   - token-bucketed bandwidth throttling with burst allowance
   - connection rate limiting
   - * packet destination restrictions by host name, IP and port(s)*
   - time-of-day restrictions on network use
   - data transfer limit by hour or day
   - server restriction (can bind and listen on a socket), Boolean and
   per-port

Reasonable default rate and transfer limits will be imposed on all
non-signed programs. If necessary, different policies can apply to mesh and
access point traffic. Additional restrictions might be added to this list as
we complete our evaluation of network policy requirements. "
Neither of the relevant points makes any reference to poking holes in this
"firewall" for collaboration.

Also, there are some features in Telepathy/whatever that would be needed to
give it security characteristics

In order for an abstraction layer to have security characteristics, it would
probably need to:
-be in a separate process, communicating through DBus; done.
-Not allow an activity to do anything by itself that would be visible on the
network, except for maybe announcing its (un)willingness to share. The
network-visible name of the activity would be set by Glucose, sharing
partners would be set from Glucose (including any search, invitations, and
responses, as well as handling resuming shared instances). It is not my
impressiong that Telepathy worries about this kind of security; if I am
wrong, such thinking should certainly be documented.

...

I opened this thread to understand how people felt about this idea. If Bert
is right, and this is the unstated general plan, then great! I am not just
saying "you guys oughtta", I can start to look at this issue and post much
more specific bugs to continue the conversation on an implementation level.

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

Re: Security for launching from URL

[Jameson "Chema" Quinn]

On Fri, Jul 4, 2008 at 4:42 PM, Ivan Krstić <
[EMAIL PROTECTED]> wrote:

> On Jul 4, 2008, at 1:37 PM, Edward Cherlin wrote:
> > My guess is that there is a way to secure the
> > process, but it might require some extra effort beyond a software fix,
> > like teachers whitelisting URLs for lessons. Or perhaps just
> > whitelisting our Moodle instances. Signed lesson plans? At any rate,
> > _not_ allowing random outside URLs to launch local activities and give
> > them scripts to run.
>
> Mainstream desktop OSes allow installed applications to register
> themselves as handlers for particular URI schemes. The applications
> are called when a URI under their handled scheme is invoked (such as
> by clicking within a browser), and are passed the entirety of the
> invoking URI, but no other information.
>
> Assuming the invoked application treats the URI with no additional
> trust, just as if it were entered from within the application, there
> is no inherent security vulnerability to speak of. Issues would arise,
> for example, if the application had a code path that performed
> filtering or applied other restrictions to the URIs it used, but
> failed to invoke that code path when an URI was passed from the OS
> rather than being entered from within the application.
>
> That said, the URI handler approach should be used sparingly. It's one
> thing to allow starting an audio player by clicking an MP3 link in the
> browser, and another to arbitrarily execute code (e.g. through an
> execution environment such as Pippy or eToys) from a web page with a
> single click. While Bitfrost is designed to mitigate the side effects
> of arbitrary code execution, it's very unwise to make it trivial for
> the user to trigger such execution unknowingly.
>
> --
> Ivan Krstić <[EMAIL PROTECTED]> | http://radian.org
>
> ___
> Devel mailing list
> Devel@lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>

I do not think that URI's pointing to the local machine are what is needed
here. What about simply downloading/opening files? I click on a link, it
downloads the file, when the download is complete I get an alert asking me
if I want to see it in the journal, I say yes, I am taken to the journal
where I open it. Later, a UI improvement lets me open it directly from the
(trusted) alert (although this means running the alert from a non-activity
context, and may put impossible burdens on our nonexistent X security).

Security-wise, how is this different from the URI-based scheme? Only in that
it does not require the activity to be pre-registered to accept URIs.

There are two security holes to worry about here - incoming data that is
executed without sufficient Bitfrost protection, and outgoing private data -
that is, data that comes from an activity without P_NETWORK (which is, of
course, unimplemented right now, but still worth worrying about) and gets
handed to an activity with P_NETWORK. One at a time:

1. Incoming data. Imagine a future version of Terminal that saves its
history files in the journal and then allows opening with a given history
and using the up arrow to rerun commands. Terminal has no Bitfrost
protection, and so should absolutely refuse to open nonlocal histories. (In
the URI scheme, this just means not registering Terminal as a URI handler.
However, it is not clear how the URI handler registry interacts with
bitfrost. I think my solution below is better.)

2. Outgoing data. Imagine EvilSpyGame which does voice recognition for the
name of the illegal opposition party, then encodes this info into an
innocuous-looking URL. When you click on the URL, your Browse rats you out
to the secret police. (The obvious limitation here is the small amount of
data which fits into a URL, but that limitation is not part of Bitfrost and
so cannot be trusted - I remember the "upskirt security professional" who
came trolling #olpc a while back, if photos could be leaked there is a real
danger.)

One scheme which would deal with both of these issues is a "private"
metadata attribute on files. Say there were three new bitfrost privileges,
P_OPEN_PRIVATE, P_OPEN_NONPRIVATE, and P_SAVE_NONPRIVATE (in actual
implementation, some of these privileges might be inferred from existing
privileges.) P_OPEN_PRIVATE would be incompatible with P_NETWORK (except
through user intervention); P_SAVE_NONPRIVATE would be incompatible with
P_MIC_CAM; and P_OPEN_NONPRIVATE would be available to all activities, but
activities which give excessive code-execution power to "data" (eg, my
hypothetical future Terminal, above) could refuse this privilege at will.

This scheme, at a first approximation, resolves the two issues I mentioned.
However, the UI for setting the private attribute on a file becomes
important. If it is too easy to change the private attribute without
realizing the consequences, my scheme becomes useless; yet trying to
handcuff the user, or presenting "Are you sure you want to do that danger

Re: Security for launching from URL

[Jameson "Chema" Quinn]

The message had two points. In point 1, the simpler, I just pointed out that
downloading a file and opening it by mime type is equivalent, security-wise,
to having a special URL handler. A UI can be worked out to reduce the needed
clicks.

In point 2, I basically argued that data should remember whether it came
from a possibly private (ie, P_MIC_CAM) activity. Applications with
P_NETWORK should refuse to open this data by default. This is relevant here
because the main danger of opening URLs in another activity is not data
(evil code) that go from Browse to another activity - bitfrost should handle
this - but data (such as private pictures encoded in the URL) that go from
other activities to Browse.

2008/7/6 Ivan Krstić <[EMAIL PROTECTED]>:

> On Jul 5, 2008, at 9:27 AM, Jameson Chema Quinn wrote:
>
>> I do not think that URI's pointing to the local machine are what is needed
>> here.
>>
>
> Please try to make your messages simpler, shorter, and more to the point. I
> often find them difficult to follow and give up. I didn't read this one
> after the first line, since you didn't quote my message in context and thus
> I don't know why you're discussing URIs pointing to the local machine.
>
>
> --
> Ivan Krstić <[EMAIL PROTECTED]> | http://radian.org
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Security for launching from URL

[Jameson "Chema" Quinn]

>
> Finally: Ivan do you see security implications in a future
> implementation of this approach which also allows the resulting
> changes to an object launched in this manner from being passed back to
> the invoking activity.  For instance, consider a Website activity
> which you can import source images into, but allows you to select any
> of those images and say "Edit with [Paint]", which then automatically
> updates the image within the Website project as the Paint instance
> gets saved.  I think this might be a nice alternative to true aliases,
> which can be confusing for kids, while encouraging inter-activity
> projects and development.
>
> - Eben
>

I definitely see security implications here. This is potentially a way for a
web page to launch Record, let the kid take pictures of themselves, and
upload those pictures to the web.

I think that the solution is that, when the result is to be passed back, the
sub-activity (Record) gets the intersection of its privileges and the
super-activity's (Browse). This would mean that the pass-back functionality
would become frequently useless for activities like Record and Measure which
rely on the mic/cam, and limited for activities like Tamtam which use the
mic/cam peripherally.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Seamless Lessons & Security (commentary)

[Jameson "Chema" Quinn]

> In other words, to support Browse launching Pippy when a .py file is
> clicked, Rainbow would have to confer upon Browse the privilege of
> launching other activities (which may, and in the case of execution
> environments such as Pippy and eToys, regularly will) have higher
> privileges than Browse itself, have such launched activities operate
> on arbitrary input provided by Browse, and not require user approval
> anywhere in the process.


Higher privileges in what way? If all we're talking about is P_MIC_CAM, the
problem is only for data flows in the other direction (from Record to
Browse, for instance). That problem, though separate from the current use
case, is real, and I have suggested a mechanism ("private" files which are
not openable by an activity with P_NETWORK) which will prevent the problem
data flow, once Bitfrost is further implemented (and until then, it is not
actually a problem, because there's no security here anyway).


> The way to do it is to throw up a (system-, not Browse- rendered!)
> warning dialog indicating that a security boundary is about to be
> crossed, and allowing the user to stop the action -- unless this
> particular boundary traversal was specifically approved ahead of time.


I agree, this is good enough, precisely because the only* attack this should
allow is temporary DOS (ie, "I didn't mean to open that activity, now I have
to wait until it finishes opening and close it"). Since the consequences are
immediate and visible, it will condition the user to understand what's going
on, not to ignore the dialog.

If there is another attack possible, we will need more than just a dialog
for security. For instance, the private files mentioned above.

Jameson

*secondary spy attacks would be possible if a networked activity makes
stupid or deliberate security mistakes, using settings to corrupt later
instances of the same activity. These attacks would still be limited by the
access of the later instances.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Security for launching from URL

[Jameson "Chema" Quinn]

>
>
> At the risk of being ignored again I still think a menu instead of a
> dialog would be less intrusive.
>
> - Bert -
>

I see your point. However, there are advantages to a dialog. It makes
further sub-functions (open with non-default activity) easier to add, and
most of the code for this trusted UI can be reused for the "view source"
case. See http://dev.laptop.org/ticket/7370 . On balance, I'd vote for a
dialog.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Activity versioning schema

[Jameson "Chema" Quinn]

> I agree with the signature approach.  However, I don't really know what
> happens when I have 37, 38, and 39 where 39 is a "bugfix" release of 37, and
> 39 is a "brand new version"...I'd prefer to see them ordered 37, 39, 38, to
> coincide with the "level of newness".  This is something we will lose
> completely without a minor release number.  The logical assumption is that
> "the bigger the number, the better/newer it is", which is blatantly false
> when point releases are intermixed with brand new versions with
> ever-increasing version numbers.  I might decide I need to clear up space,
> and so delete versions 37 and 38, thinking I was keeping the latest and
> greatest version 39 and be quite disappointed.
>
> - Eben
>

This idea works well when developers time their new-features releases to
coincide with Sucrose updates. It starts to break down when that does not
hold - does version 3.x mean "runs on same Sucrose as 3.0" or "holds
essentially the same feature-set as 3.0" or some combination of both? I
think that Eben is assuming the former - that nobody would go back and
release lower version numbers except in order to maintain system
compatibility - but this conflicts with a common assumption that major
version changes are synonymous with major new features.

Basically, there are two separate problems here, and we should not be
solving them together. One is that the latest release may not be the
greatest - because of bugfix releases. I agree with Eben's proposal of minor
version numbers as a (totally optional) solution; as long as the minor/major
separator is not a decimal separator (that is, [.,]), the meaning is pretty
self-evident. (I think that : is the best candidate, by analogy with times
and bible verses.)

But the second problem is harder: how do you tell people which versions run
on which Glucose. Any attempt to encode this implicitly in version numbers
is, I think, bound to fail, and not too helpful anyway. The update_url
solution for #4951 fixes the most useful version of this problem - "what is
the latest working version on my system". I think we can live without a more
general solution to "will version X run on system Y" - even though that
means some ugly trial-and-error when sharing activities across Glucose
versions.

...

and cscott just wrote an email which says many of the same things.

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

Re: Code name for 9.1.0

[Jameson "Chema" Quinn]

On Mon, Jul 14, 2008 at 3:40 PM, C. Scott Ananian <[EMAIL PROTECTED]> wrote:

> On Mon, Jul 14, 2008 at 5:24 PM, Greg Smith <[EMAIL PROTECTED]>
> wrote:
> > My suggestion is to use names of famous pedagogues as code names. I
> > suggest we call this one Freire for Paulo Freire
> > (http://en.wikipedia.org/wiki/Paulo_Freire)
> >
> > Any other votes or code name suggestions?
>

I appreciate this, but think that it is a little confusing (there is no
particular philosophical relationship between Freire and his version, any
more than with any other version) and needlessly political ("No! Lasalle!",
"No! Makarenko!" - in my view, both deserve inclusion in such a set, but
either one might raise objections).

If we do choose this naming scheme, I think Freire is a good place to start.
If not, I think that something suggesting growth (names of trees?) might be
safer.



>
> Well, I'm not sure that would get my vote -- at least not until
> someone tells me how it's supposed to be pronounced.
>
> My original suggestion was to follow the Fedora model and (a) solicit
> suggestions from the community, followed by (b) a big fun vote.
> That's a little different from the model you are using.
>

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

Re: [sugar] Activity versioning schema

[Jameson "Chema" Quinn]

On Mon, Jul 14, 2008 at 4:18 PM, C. Scott Ananian <[EMAIL PROTECTED]> wrote:

> If we're going to a 'dotted decimal' scheme, we
> should use '.'.
>
> ...
>
>  Is 1.1 "newer" or "older" than 1.11?)


 This is exactly the reason I think that 1-1 ... 1-11 is clearer (you're
right, colon is unworkable because it cannot go in NTFS file names). From an
educational standpoint, 1.10 is teaching kids the wrong ideas about the
decimal system.

I do not think that hyphens are impractical. In most cases people will get
it right the first time by following examples. Those who don't will quickly
learn from installation warnings.

I think anything from 1-3 levels should be allowed, and that 3 == 3-0 ==
3-0-0. Leading zeroes should cause warnings - that will mostly keep things
from looking like dates (even in 2010, bugfix 10 should be rare).
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [sugar] Activity versioning schema

[Jameson "Chema" Quinn]

> I'd like to pose an alternative goal, inspired by your comment: Glucose
> should never attempt to parse version strings.  I believe that we can
> accomplish this without sacrificing any of the user-facing behaviors that
> we truly desire.  The choice of an appropriate versioning scheme may then
> be left to the author.
>

I disagree. It is desirable for Sugar to be able to compare versions and
guess which one is newer. If, as is the current plan, multiple versions of
an activity can coexist on an XO, it is reasonable to want sugar to present
these in some sane order, and possibly give hints and/or aid if the user
wants to update and/or garbage collect. Otherwise, we might as well just be
using activity hash, which can be calculated without being explicitly
included in activity.info.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Code name for 9.1.0

[Jameson "Chema" Quinn]

>
> So, that said, starting with Freire might still allow us to move in a
> different direction for 9.2 and avoid the learning philosophy wars.
>  --scott


I could easily propose my "trees" idea as a follow up to Freire. He spoke of
learning to write with a stick in the dirt under a mango tree. 9.2 = mango?
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [sugar] Activity versioning schema

[Jameson "Chema" Quinn]

-BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Jameson "Chema" Quinn wrote:
> | It is desirable for Sugar to be able to compare versions and
> | guess which one is newer.
>
> "Newer" means "more recent".  If this capability is important to you, then
> we may simply include a datestamp in each bundle, separate from the
> version.  However, I do not know of any planned Sugar feature that would
> require the ability to determine which bundle was created most recently.


I misspoke. I meant, "the latest", in the same sense that Eben is using it:
the version with all relevant new feature decisions (including added and
dropped features) and bugfixes. This is not always the one created at the
latest calendar date.


>
> | If, as is the current plan, multiple versions of
> | an activity can coexist on an XO, it is reasonable to want sugar to
> present
> | these in some sane order, and possibly give hints and/or aid if the user
> | wants to update and/or garbage collect. Otherwise, we might as well just
> be
> | using activity hash, which can be calculated without being explicitly
> | included in activity.info.
>
> I favor including a version string with every bundle.  I favor displaying
> this string in places where it is needed to disambiguate multiple versions
> of an Activity.  I'm merely suggesting that the system not attempt to
> parse it.
>
> You mention ordering.  The Journal designs have long called for all
> columns to be sorted, with the user selecting the order of sorting
> precedence.  One intermediate position would be for the Version column to
> be sorted according to a best-effort ordering that attempts to do
> something sane when faced with any of the common version string
> conventions.


 Two use cases:

1. I have a journal object. I want to choose which activity to open it with.
I am presented with a multilevel menu: the top level has all activities
which open the mime type, the next level has all major versions of those
activities, the next level minor versions, etc. If click without bothering
to move over to the sublevels, I get the default version from the sublevel
of my current menu, which is the starred version (if it exists) or the
highest version (applied recursively down the sublevels).

2. I just quit an activity version which is signed (ie, not just a
development build) and is a higher number than the starred version. A dialog
pops up asking if I want to "update" to that version. If I click yes, Sugar
moves the star to the new version (freeing the older version for possible
later GC). If I choose "no", the dialog will not appear again.

(Dealing with instances associated with the old version is more complicated.
Say I have an instance from Write 50 and Write 60 is starred. I suggest that
the ideal behaviour would be to open by default with Write 60, assuming it
handles the mime type, but ask after closing if that worked; if not,
remember that Write 50 instances may be incompatible with other versions and
open them by default with Write 50 always. An instance of Write 70 should
open with Write 70. This would not change GC behaviour: you might end up
GC-ing an old version and losing access to your instances, but the old
version would be available if necessary from the backup server.)

I guess you could argue that use case 2 should offer to assist downgrades as
well as upgrades (since we would be keeping separate already-showed-dialog
metadata for each version, any version would only show the dialog once, and
that would be more likely to be when it was newer), but I think that even
then it would be useful to include the words "higher version" or "lower
version" in the dialog.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [sugar] Activity versioning schema

[Jameson "Chema" Quinn]

On Mon, Jul 14, 2008 at 8:29 PM, Mikus Grinbergs <[EMAIL PROTECTED]> wrote:

>  If, as is the current plan, multiple versions of
>  an activity can coexist on an XO, ...
> > Two use cases:
> > 1. I have a journal object. I want to choose which activity to open it
> with.
> > I am presented with a multilevel menu: the top level has all activities
> > which open the mime type, the next level has all major versions of those
> > activities, the next level minor versions, etc. If click without
> bothering
> > to move over to the sublevels, I get the default version from the
> sublevel
> > of my current menu, which is the starred version (if it exists) or the
> > highest version (applied recursively down the sublevels).
>
> I'm sorry, but my mind boggles at the thought of a four-year old
> clicking on a Journal entry and being presented with a palette of
> seventeen different versions of 'TamTam' -- so that he may choose
> which of those versions is appropriate for whatever upgrade the
> adults had made to that XO last week.
>
> mikus
>
>
This is not, of course, the default behavior - if you just "click on a
journal entry", it opens with whatever version created it, or the starred
version (if the creator version is not marked as creating incompatible
entries), whichever is more mature. All that logic happens with no need for
human interaction (and yes, we need Glucose to understand something about
versions for that to work).

Nevertheless, the behavior I described is my best understanding of the
approximate consensus of
several
discussions (+2
more) I have had on IRC about this matter. I myself would (and did)
advocate for more automatic updating, and no decision is set in stone; but
no matter how automatic and smart we make things, we are going to have to
choose at some point between having a manual fallback, or having some things
break because we don't have a manual fallback. I'd rather have the fallback,
and I think that if we do, we should be hiding it in heirarchical menus as
much as possible (so that even if you DO need the fallback and even if you
DO have 6 installed versions of TamTam, Glucose is at every moment hiding as
many of them as possible until you deliberately, by hovering, ask it to show
you more).

If you have a better idea of how Glucose should handle these issues, please
share it. Simplifying assumptions are good, even if they're not 100% valid.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Code name for 9.1.0

[Jameson "Chema" Quinn]

Well, actually, the mango suggestion was made originally as a tree, not a
fruit - as the tree Freire learned to read underneath. Obviously the concept
of "learning under a tree" exists in many cultures around the world, and
there are several trees that would work for this:

apple (newton),
bodhi/banyan/fig/pipal/*Ashvastha
* (buddha), juniper (navajo), buttonwood (wall street), "blossoming pear"
(african-american - from "their eyes were watching god"), mulberry
(china/silk), baobab, thorn tree 

I definitely sympathize with the "general fruit" and "alphabetical is nice"
threads here. Verbs are good too. And the above list, even if we managed to
triple it, would still be a little too thin to make such wordplay easy. But
even if we decide against a list like the above, I would still advocate for
starting with mango, and then going alphabetical later (as Ubuntu did). The
Freire story is a good one, and mango is such a fun word to say.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [sugar] Activity versioning schema

[Jameson "Chema" Quinn]

On Tue, Jul 15, 2008 at 12:57 PM, C. Scott Ananian <[EMAIL PROTECTED]>
wrote:

> 2008/7/15 Jameson Chema Quinn <[EMAIL PROTECTED]>:
> > If you have a better idea of how Glucose should handle these issues,
> please
> > share it. Simplifying assumptions are good, even if they're not 100%
> valid.
>
> Versions in activity.info files are either plain integers, or
> RPM-standard version strings, with no pretense that these correspond
> in any way to sugar major releases or anything at all, except that
> they are ordered: if the activity updater sees that you have version
> N, and there is a version M announced[*] as compatible with your build
> where M > N, then it will suggest that you upgrade to M.  All other
> meanings are encoded with other mechanisms.
>  --scott
>
> I meant the UI issues, since that is what Mikus objected to. I.e., can
multiple versions of the same activity coexist on same xo? What about
journal instances from multiple versions of an activity? What can we do
concretely to try to avoid/deal with this situation?
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [sugar] Activity versioning schema

[Jameson "Chema" Quinn]

On Tue, Jul 15, 2008 at 12:57 PM, C. Scott Ananian <[EMAIL PROTECTED]>
wrote:

> 2008/7/15 Jameson Chema Quinn <[EMAIL PROTECTED]>:
> > If you have a better idea of how Glucose should handle these issues,
> please
> > share it. Simplifying assumptions are good, even if they're not 100%
> valid.
>
> Versions in activity.info files are either plain integers, or
> RPM-standard version strings, with no pretense that these correspond
> in any way to sugar major releases or anything at all, except that
> they are ordered: if the activity updater sees that you have version
> N, and there is a version M announced[*] as compatible with your build
> where M > N, then it will suggest that you upgrade to M.  All other
> meanings are encoded with other mechanisms.
>  --scott
>
> I meant the UI issues, since that is what Mikus objected to. I.e., can
multiple versions of the same activity coexist on same xo? What about
journal instances from multiple versions of an activity? What can we do
concretely to try to avoid/deal with this situation?
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [sugar] Activity versioning schema

[Jameson "Chema" Quinn]

On Wed, Jul 16, 2008 at 3:54 PM, Martin Langhoff <[EMAIL PROTECTED]>
wrote:

> On Thu, Jul 17, 2008 at 4:54 AM, Michael Stone <[EMAIL PROTECTED]> wrote:
> > What _should_ be happening in this thread is the collection of use
> > cases.
> >
> > For a "small" selection of the issues involved, please refer to
> >
> >   http://wiki.laptop.org/go/User:Mstone/Commentaries/Bundles_1
> >   http://wiki.laptop.org/go/User:Mstone/Commentaries/Bundles_2
>

+1 on creating use cases for activity versions.

-1 on that being necessary to resolve this particular thread (except insofar
as it makes "opaque version strings" less attractive). The security issues
are with the service ID, not the version.

...In the meantime, a simply obvious
> solution that meets our needs is standing in front of us, glowing
> warmly .
>
> grab it
>

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

Re: [sugar] Activity versioning schema

[Jameson "Chema" Quinn]

>
> For these reasons, in my humble opinion, choosing our software packaging
> format and guidelines (of which version numbering is but a single
> aspect) is NOT A TRIVIAL EXERCISE and is not as simple as picking an
> off-the-shelf format. (I wish that the reality were otherwise).


Absolutely agreed.  Except the part where we can't choose a version format
without resolving all other issues. I think it is clear what we want from a
version format: some simple, human-readable, comparable numbers.

If we want anything more, it ceases to be a version format and inevitably
becomes something far more complex. Which we may decide to implement,
although in the conversations you reference I was the very one suggesting we
wanted more complex things sooner, and I was shot down, I think justly. The
use case for versions is NOT source control, or keeping a record of forking
history, or determining network interoperability, or determining Glucose
version interoperability, or determining of identity relations, or
determining journal instance interoperability.

All of those are separate issues we will face one day, sooner or later, and
I doubt we will even look at the version numbers in the solution to any of
those. Versions are JUST for human-readable distinctions between two
versions of the same activity [in the future, "the same" will imply
"signed"], with the ability for humans or Glucose to make a reasonable (not
bulletproof) inference about which one has the maturer code. I think that
the rpm solution is just that, a solution.

Note: regarding the fact that versions are useless for determining identity
(whether two xo's are identical): this is currently ALL we use versions for.
This is bug 7534, which I will now nominate for 8.2.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [sugar] Congratulations! but Sugar sucks

[Jameson "Chema" Quinn]

|> 1. The datastore
|> 2. OS Updates
|> 3. File Sharing
|> 4. Activity Modification
|> 5. Bitfrost
|> 6. Power management

On Thu, Jul 24, 2008 at 11:02 PM, C. Scott Ananian <[EMAIL PROTECTED]>
wrote:

> On Thu, Jul 24, 2008 at 8:18 PM, Benjamin M. Schwartz
> <[EMAIL PROTECTED]> wrote:
> > really surprisingly short.  Each item on the list has been debated to a
> > stationary point over the last two years, so all that is left is to make
> a
> > final decision for the engineers to execute.  Each task could be
> completed
> > or hugely improved by a single developer in a few months, provided that
> we
> > do not allow changes to the requirements, and the developers are not
> asked
> > to split their time and focus.
>
> I do not believe that either of these statements is correct.
>
> We are not lacking in decisions: we have substantially complete
> designs; we are lacking implementation.
>
> Each of your items is not the work of "a single developer in a few
> months": solving these problems is realistically a year's work at
> least, if we have a single developer working full time on each.


I have experience with numbers 1, 3, and 5, and am the principal person
responsible for 4 right now. I would say that 3 and 4 are definitely within
the "single dev in a few months" time frame; depending on the definition, 4
is in the "as soon as currently applied patches percolate into production"
time frame. The further work on 4 - already started - is in the area of
activity signatures, which is actually encroaching on 5. In a few full-time
months of a single developer, this would put 4 at a place which other
platforms could envy, and make concrete strides towards 5, to the point
where security would be better, not worse, than other modern platforms
(though I agree that there is plenty more work to fulfill the true promise
of Bitfrost).

I agree that 1 is not so simple; while a rockstar developer might be able to
solve all our problems in a two-month all-nighter, 6 months to a year is a
more realistic timeframe to get something really solid and stable.

What I have accomplished - admittedly too slowly - on Develop, I have done
in under half-time commitment. I have made it pretty clear that I was
available for full-time work, pretty cheaply, but not for free. I could work
to contract, with payment working out to around what the GSoC students are
getting, and have Develop and Bitfrost in a significantly better place by
the end of September (activity signatures done, bitfrost privileges
by-application secure on that basis, the Terminal/Journal bitfrost
"loophole" mendedl; Develop collaboration/source control starting to be
usable).


>
> ps. and, of course, you've neglected "software for kids that does
> things kids want to do", "powerful and pervasive collaboration" and
> "mesh networking" in your list of items.


All of which are slightly less sucky in their current state than the items
mentioned, I think, but definitely need work too.

To sum up: if this is a matter of resources, just hire people. Me, and
others who want it - I have heard marcopg complaining that he should be
full-time, I think. In my case, the worst that could happen is that I don't
come through, and, since I am asking for contract work, that would mean you
don't pay me, so it would be identical to current situation. The best would
be that for less than the price of a classroom-full of XOs, you would get
large steps on two of these list items in a couple of months.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [sugar] Congratulations! but Sugar sucks

[Jameson "Chema" Quinn]

I think that one useful thing that we could work out in this thread would be
how many dollars and months it would take to get each of these areas from
suckage to ruleage. Here's some estimates out of my ... head:

1. datastore. Get consensus: 1.5 months from now (really, 1 month from 8.2).
Hire/reassignAndClearTheDecksOf someone to work on this full time: 1 month.
Actual work to reach The Next Level: 2-3 months. Cleanup: 2-3 months.
Realistically, we can't guarantee that this can make it by 9.1, but it
should be close. Time: 6+ months, cost: 4-6 months FTE. Someone with these
skills could cost up to $80K/yr in US, over half that internationally.

2. OS updates. Design and consensus: 2.5 months from now. Actual coding: 2
months. (This is the kind of problem that needs good clean design, but is
not too very hard to implement.) Time: 5 months, cost: using existing
resources.

3. File Sharing. Apparently there is already an intern on this. 3 months,
existing resources.

4. Activity Modification: 2 months and <<$5K.

5. Bitfrost
Blocked by 4 (activity bundle signatures), above. After that, there are
about 2 biggish (1-2 months) features to add, and then the rest is eternal
vigilance (much debugging). Say 2-4 months FTE, 6 months ETA

6. Power management
???

7. Software: if you build it, they will come.

8. Collab:
??? existing resources?

9. Mesh:
???

Add it all up, and I think that with about 3 expensive new-hire FTEs and me
(much, much cheaper), 90% of this list could be done in time for 9.1; the
other 10% could be done by 9.2 without even using the new FTEs, which would
free them up for nextgen development. On the other hand, I think that with
just existing resources, only about 30% will be done by 9.1, which will
Still Suck.

IMO this is a steal - I know nothing about funding here, but if there is a
chance of this level of funding I think it is a no-brainer. Say there's
$100,000,000 of hardware out there, shipped; I think that this list accounts
for easily 10% of the use-value of this hardware; and the costs above are
far under $300K, with the most pessimistic accounting. That means that the
*immediate* social-value for investment would be around a factor of 20.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Terminals

[Jameson "Chema" Quinn]

Note that I am currently working on a (somewhat large) patch which will not
turn off isolation for anything outside share/... (that is, the activities
in ~/Activities will all be isolated). This will close the gigantic security
hole where anything named "Terminal" or "Journal" was not isolated.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Terminals

[Jameson "Chema" Quinn]

2008/8/1 Eben Eliason <[EMAIL PROTECTED]>

>
>
> On Fri, Aug 1, 2008 at 4:07 PM, John Gilmore <[EMAIL PROTECTED]> wrote:
>
>> > Why does it matter that you cannot adjust the screen brightness from
>> > the console using the special keys? You can adjust it from Sugar
>> > without root access. The idea was to understand what limits we'd face
>> > using the console for root access instead of a special terminal
>> > activity. What are the Sugar/X Window actions that require root
>> > access?
>>
>> "It doesn't matter if you have to abandon Sugar to do system
>> administration or to recover from a problem?"  Walter, I'm shocked; I
>> would've expected you to be arguing on the other side: "Sugar should
>> be the preferred environment."  That we shouldn't be kicking people
>> out of Sugar, particularly when their system is fragile and in need of
>> diagnosis, repair, or upgrade.  We should keep them in the environment
>> they know and understand, where the Frame works, the controls work,
>> the tabs work the same way, the keyboard keys all do the same things.
>>
>> It was hard for the Support Gang to explain to people how to become
>> root so they could diagnose or fix something they reported as a
>> problem (like a full filesystem, a USB key that didn't work, ...).
>> OLPC was also changing the way you become root (su versus sudo) in
>> different software releases, based on Fedora changes.  We hashed all
>> this out in January, and the Terminal got a new "#" button at the top,
>> which injects the right command to make you root.  There's no such
>> button in the console.  If we push people back to the console, the
>> support load increases.  It's easier to get them to run the Terminal
>> applic...uh, activity, and press the root button, and type this
>> command.  Also, in Terminal, cut and paste works to send us back
>> diagnostic results via Browse.
>>
>> The owners of free software based machines also need the ability to
>> inspect and revise the free software in those machines -- or it isn't
>> free as in freedom.  Legally, OLPC can push that ability out to the
>> very corners of the system (e.g. "You can't do that in Sugar.").  But
>> morally and philosophically, we ought to be pulling it right into the
>> heart of the system ("Of course you can, and it's so easy; here, let
>> me show you!").
>>
>
> I agree with everything said above.
>
>>
>> Let's not lose sight of what's going on here.  The whole reason we are
>> having this discussion at all is because of OLPC's "security" model
>> (Bitfrost).  If the security model doesn't permit integrated,
>> interactive root access that lets people diagnose, repair,
>> investigate, and alter their systems, there's something wrong with the
>> security model -- not something wrong with root access.
>>
>
> And I wonder if it could really be so simple.  Is it possible that we could
> simply have a P_ROOT permission as well, or does that blow Bitfrost out of
> the water?  In a way I'd hope not, since the whole point is that the desire
> for root is requested/advertised, and therefore can (eventually) be denied;
> P_ROOT clearly wouldn't be granted  within the default permissions either,
> once we have them.
>
>
Coincidentally, I have a patch which does just that! See my thread on [EMAIL 
PROTECTED]
OK, I guess I should copy it to devel@ and security@ while I'm at it.

I write this assuming that this might not help matters at all...it could be
> too lenient.  But perhaps we could offer the P_ROOT only to activities which
> a) request it and b) are signed by some signing authority (could be us,
> could be a country, etc.), where the security section of the control panel
> offers a place to designate trusted signing authorities.  I'm no security
> guru, though, which I willingly admit!  Is anything I've mentioned worth
> even considering?
>

Once we have activity signatures, we can talk about this more concretely. I
expect that, for general bitfrost permissions, there will be a bitfrost
control panel that allows you to grant certain permissions to a specific
(hashed version of an) activity; or to delegate the power to grant certain
permissions to other signers (such as the author of an activity, so that
updates get same permissions). I think that it is reasonable to put
additional restrictions on the P_ROOT permission: perhaps it can ONLY be
granted to activities installed at build time OR signed by current XO?
(Then, to change the version of your terminal, you'd either have to do a
full update to a new build, or touch the new version of terminal activity
with Develop to "make it yours").
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

preliminary [PATCH] and discussion for #5657: activity isolation for all activities in ~/Activities

[Jameson "Chema" Quinn]

Problem: anything named "Journal", "Terminal", "Log", or "Analyze" is not
isolated. This is the biggest security hole we have right now: it is a
trivial way for any activity to get root access.

Idea: as a short-term hack (until we have good cryptographic signatures for
activities), only turn off isolation if an activity is in
.../share/sugar/activities. Installation here is only possible for root (or
at build time).

Implementation:
This makes sense to implement in activitybundle.py, respecting a line in
activity.info like:
bitfrost_requests = P_ROOT, P_OTHER_UNIMPLEMENTED_THING, ...
That means that the data then passes up the chain: to bundleregistry, to
activityregistryservice, to sugar.activity.registry, and then to
activityfactory. Passing it up the chain meant fixing the call signatures
all the way along, and doing some refactoring along the way.

Status:
Works, not well tested (I will test more before submitting it definitively.
Also I'll have to include the patch to Journal's activity.info. Patches to
the other activities and packaging concerns will wait for round 3.) Marcopg
or others, feel free to start the review on the included patches; there are
enough bigger design decisions evident that we can get a jump on review even
before I do the solid testing on Monday.

Consequences:
- Changing the four activities named above to be installed in
share/sugar/activities. To remove them, a country would need to use a
customization key.
- If the activities above are in a country's build, they cannot be
uninstalled by user. If they are upgraded by user, they lose their
unisolated powers; if the upgrade is removed, they regain them. (Not tested)

Related issues:
- The use of version numbers to distinguish two versions of a single
activity is improved by this patch, but is still inconsistent. Erratic
behaviour is expected when two versions of the same activity are present,
although in normal use (all installation through the journal) this would
never happen as the older versions would be uninstalled automatically.
- Of course, the long-term solution is activity signatures.
- It will still be possible for a web link to claim to be activity X, but to
actually replace Browse (or other) with a trojanned version. (I know, this
is only weakly related, but it came up while I was discussing this patch
with Eben, so I mention it here.) I tracced this: #7761
 
From 2c114c26003d10705e3d174d47eae11311bffaaf Mon Sep 17 00:00:00 2001
From: Jameson Quinn <[EMAIL PROTECTED]>
Date: Fri, 1 Aug 2008 13:40:25 -0600
Subject: [PATCH] bug #5657: gets security requests from activitybundle, checks them, and passes them up to registry

---
 service/activityregistryservice.py |   54 ++
 service/bundleregistry.py  |  107 
 2 files changed, 102 insertions(+), 59 deletions(-)

diff --git a/service/activityregistryservice.py b/service/activityregistryservice.py
index 6ba5598..7b3415a 100644
--- a/service/activityregistryservice.py
+++ b/service/activityregistryservice.py
@@ -24,6 +24,11 @@ _ACTIVITY_REGISTRY_SERVICE_NAME = 'org.laptop.ActivityRegistry'
 _ACTIVITY_REGISTRY_IFACE = 'org.laptop.ActivityRegistry'
 _ACTIVITY_REGISTRY_PATH = '/org/laptop/ActivityRegistry'
 
+def log_it(s):
+f = file("/home/chema/.sugar/default/logs/hardcoded","ab")
+f.write(s+"\n")
+f.close()
+
 class ActivityRegistry(dbus.service.Object):
 def __init__(self):
 bus = dbus.SessionBus()
@@ -64,11 +69,8 @@ class ActivityRegistry(dbus.service.Object):
 @dbus.service.method(_ACTIVITY_REGISTRY_IFACE,
  in_signature='', out_signature='aa{sv}')
 def GetActivities(self):
-result = []
 registry = bundleregistry.get_registry()
-for bundle in registry:
-result.append(self._bundle_to_dict(bundle))
-return result
+return (bundle for bundle in registry)
 
 @dbus.service.method(_ACTIVITY_REGISTRY_IFACE,
  in_signature='s', out_signature='a{sv}')
@@ -78,7 +80,8 @@ class ActivityRegistry(dbus.service.Object):
 if not bundle:
 return {}
 
-return self._bundle_to_dict(bundle)
+log_it("service about to return "+str(bundle))
+return bundle
 
 @dbus.service.method(_ACTIVITY_REGISTRY_IFACE,
  in_signature='s', out_signature='aa{sv}')
@@ -90,18 +93,15 @@ class ActivityRegistry(dbus.service.Object):
 name = bundle.get_name().lower()
 bundle_id = bundle.get_bundle_id().lower()
 if name.find(key) != -1 or bundle_id.find(key) != -1:
-result.append(self._bundle_to_dict(bundle))
+result.append(bundle)
 
 return result
 
 @dbus.service.method(_ACTIVITY_REGISTRY_IFACE,
  in_signature='s', out_signature='aa{sv}')
 def GetActivitiesForType(self, mime_type):
-result = []
   

Re: [OLPC Security] preliminary [PATCH] and discussion for #5657: activity isolation for all activities in ~/Activities

[Jameson "Chema" Quinn]

On Fri, Aug 1, 2008 at 4:01 PM, C. Scott Ananian <[EMAIL PROTECTED]> wrote:

> On Fri, Aug 1, 2008 at 5:01 PM, Jameson Chema Quinn
> <[EMAIL PROTECTED]> wrote:
> > Problem: anything named "Journal", "Terminal", "Log", or "Analyze" is not
> > isolated. This is the biggest security hole we have right now: it is a
> > trivial way for any activity to get root access.
>
> Another possible short-term hack is to simple disable
> activitybundle.install() and activitybundle.upgrade() for bundes with
> bundle_ids matching those of Journal, Terminal, Log, or Analyze.  This
> allows these activities to be installed in /home/olpc/Activites with a
> customization key, as usual, but prevents malicious attackers from
> using a web link or the activity updater to replace the
> originally-installed versions.
>
> This has the benefit of (a) not requiring us to revisit the
> "activities in /home" war, and (b) allowing us to upgrade the versions
> of these trusted activities in /home in (say) 9.1, using the "proper"
> mechanism.
>  --scott
>

I like this idea. Of course, it means that can install using "cp -r",
including installing a trojan activity which does not *look* like Terminal.

... My patch has activities requesting P_ROOT in activity.info. Could we
simply refuse to do a normal install for such activities? We could even keep
a list of them, and not respect what's not on the list, and only update the
list on a keyed install. This is not as secure as signatures, because a
sneaky attack could still modify the contents of an installed activity, but
it is getting pretty close.

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

Re: Terminals

[Jameson "Chema" Quinn]

>
> As you can see, the present security difficulties stem from the lack of
> effort spent on recording user intentions about what permissions should
> be applied to what activities. Signatures do absolutely nothing to
> address this problem -- they only permit an as-yet undesigned system
> interpreter to check whether the authors W of claim X about blob Y knew
> secret Z.


This is literally true, of course, but I think that it is a misunderstanding
of what Benjamin said. The "signatures" stumbling block is actually the
"hashes" stumbling block - that is, the ability to refer to blob Y in a way
that is stable across installation/repacking, .pyc compilation, etc, but
secure against changes.


> These assertions yield no new power because the Bitfrost
> security model asserts that trusting that author W wrote blob Y implies
> no trust in blob Y itself. It's a good reason to display hints about
> blob Y, to display blob Y nearby to blobs Y_1, Y_2, etc. also by author
> W, but it is _NOT_ sufficient to grant Y permissions in the initial
> default-deny configuration proposed by Bitfrost.


This is also close to true, but not entirely. In general, we will not trust
code simply because it comes from a given author. However, Bitfrost is not
quite as categorical as you imply. I think that the code/user distinction is
primarily a *distinction* between trust in a user and trust in their code,
not a firm declaration that the latter is impossible without explicit
intervention. Here's the relevant paragraph:

*"Unfortunately, software received through a friend or acquaintance is
completely untrusted code, because there's no trust mapping between people
and software: trusting a friend isn't, and cannot be, the same as trusting
code coming from that friend. The friend's machine might be taken over, and
may be attempting to send malicious code to all her friends, or the friend
might be trying to execute a prank, or he might have written—either out of
ignorance or malice -- software that is sometimes malicious."*

>
> No new bundle format is needed to track activities according to
> non-spoofable tokens. All that is needed is to teach the software making
> authorization decisions (Sugar) to use the correct token.
>

I disagree - for stronger security, a new bundle format which includes
hashes is, if not 100% necessary, at least clearly desirable. However, you
are right that we can do much better without this, and I am currently
working on a patch which does that - for 5657.

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

Re: Terminals

[Jameson "Chema" Quinn]

> As above, hashes can be computed on the unpacked activity bundles. No
> modification to the bundle format is necessary; moreover, why would you
> ever rely on the correctness of a manifest supplied by the bundle
> itself?
>

The current manifest format hashes everything in a directory. That includes
python compiled files (arguably correct, but also arguably a separate
issue); any signatures or subfiles of signatures (manifests and hashes)
which may be included in the future; git-related invisible files which may
be on a developer's machine; and the dist/ directory, likewise. This could
be a problem. A smart bundle format would, I argue, at a minimum exempt
signatures and cryptographic manifest (not MANIFEST, but HASHES) from being
hashed.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [sugar] video bleeds through somewhat between sessions

[Jameson "Chema" Quinn]

>
>
> Both persons who have answered me have talked about "how things from
> the video frame can be seen".  But I was not looking at video - I
> was looking at TEXT.  If I understand correctly what has been told
> me here, neither the 'black' of the text characters themselves, nor
> the 'white' of the background for the text, should have _allowed_
> "things from the video frame to be seen".  I definitely did not see
> any color.  What I did see was that some parts of the 'black' text
> characters changed briefly to _less_ 'black' (they went black <-->
> gray <--> black) depending on where on *its* screen the ongoing
> video 'session' WOULD HAVE depicted "bright" or "dark" areas.
>

I think that the operating theory is that, around the edges of the "black"
text, there are some pixels which are "grey" (or even, because of the funny
xo color magic, colored?). These pixels would then be "transparent".

Is this consistent with your experience? In other words, is it possible that
the video was fully visible in occasional pixels, instead of partially
visible in all the "black" text pixels?
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [sugar] Proposal: Activity developers mailing list)

[Jameson "Chema" Quinn]

>
>
> As opposed to a new list, we could use the "topics" function of mailman to
> enable
> people to select that they only want "python breakage" emails, for example,
> that
> contain a certin regexp. This topic can be addded by the list admin, per
> 


I think tags, or topics, or whatever you call them, would be the perfect
solution. In fact, I suggest that using this feature, we could even start to
merge lists - for instance, devel@ and [EMAIL PROTECTED]
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: using wiki pageviews per country of origin to motivate translations

[Jameson "Chema" Quinn]

On Mon, Aug 25, 2008 at 11:12 PM, Erik Garrison <[EMAIL PROTECTED]> wrote:

> It has recently come to my attention that the majority of the traffic on
> the wiki is coming from Uruguay XO users (students it seems).
>
> Could we track, or are we already tracking, pageviews per page by
> country of origin on wiki.laptop.org?  It would be an extremely useful
> metric in deciding which pages should be translated into which
> languages.
>
> Erik
>
> (a list of requested spanish translations:
> http://wiki.laptop.org/go/Category:Deseada)
> ___
> Devel mailing list
> Devel@lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>

+1

(if somebody figures out how to do this query, and can without excessive
effort make the query available live, that would be even cooler).
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Touch pads

[Jameson "Chema" Quinn]

I'm here in Guatemala, and I see it to the point where it is a serious
problem. This is an interesting data point, because it is more humid than
hot here - average temperature around 21C but average humidity in the 70s or
so -
http://www.bbc.co.uk/weather/world/city_guides/results.shtml?tt=TT001860 .
It seems to have gotten worse over the life of my machine.

The machine is usable, but I am sure that if it were this bad in Boston it
would be fixed by now. My daughter basically hands the mouse over to me half
the time unless my optical mouse is free, and drawing programs are not worth
it. I also think that improved keyboard navegability would be really worth
it, because even if this is significantly improved, there will probably be
thousands of units in the field getting bitten noticeably.

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

Requesting space on Git

[Jameson \"Chema\" Quinn]

1. Project name : Idly Develop
2. Existing website, if any : none
3. One-line description : A proof of concept for multilingual programming

4. Longer description   : An IDLE-based program editor demonstrating the
   concept of transparent non-English-based editing of
   real python code. See notes, below, for further
discussion.
:
:

5. URLs of similar projects : Well, there's IDLE, and from about
1995-98 Appletalk did something similar... but this is really a new
concept.

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 homunq Jameson Quinn www.casarizoma.org/id_dsa.pub
  [EMAIL PROTECTED]

I know that at least a couple of others would be interested, I'd be
happy to allow any who want to to sign up.


7. Preferred development model

   [X] Central tree. Every developer can push his changes directly to the
   project's git tree. This is the standard model that will be familiar to
   CVS and Subversion users, and that tends to work well for most projects.

   [ ] Maintainer-owned tree. Every developer creates his own git tree, or
   multiple git trees. He periodically asks the maintainer to look at one
   or more of these trees, and merge changes into the maintainer-owned,
   "main" tree. This is the model used by the Linux kernel, and is
   well-suited to projects wishing to maintain a tighter control on code
   entering the main tree.

   If you choose the maintainer-owned tree model, but wish to set up some
   shared trees where all of your project's committers can commit directly,
   as might be the case with a "discussion" tree, or a tree for an individual
   feature, you may send us such a request by e-mail, and we will set up the
   tree for you.

8. Set up a project mailing list:

   [ ] Yes, named after our project name
   [ ] Yes, named __
   [X] No

   When your project is just getting off the ground, we suggest you eschew
   a separate mailing list and instead keep discussion about your project
   on the main OLPC development list. This will give you more input and
   potentially attract more developers to your project; when the volume of
   messages related to your project reaches some critical mass, we can
   trivially create a separate mailing list for you.

   If you need multiple lists, let us know. We discourage having many
   mailing lists for smaller projects, as this tends to
   stunt the growth of your project community. You can always add more lists
   later.

9. Commit notifications

   [ ] Notification of commits to the main tree should be e-mailed to the list
   we chose to create above
   [ ] A separate mailing list, -git, should be created for commit
   notifications
   [X] No commit notifications, please

10. Shell accounts

   As a general rule, we don't provide shell accounts to developers unless
   there's a demonstrated need. If you have one, please explain here, and
   list the usernames of the committers above needing shell access.

11. Notes/comments:
A. For prior discussion of this concept, see (oldest to newest):
http://wiki.laptop.org/go/Develop#Human_Language_and_Culture_Concerns
http://wiki.laptop.org/go/Source-code_editor_with_transparent_native-language_display
http://wiki.laptop.org/go/Source-code_editor_with_transparent_native-language_display/design
http://lists.laptop.org/pipermail/sugar/2007-August/003012.html and
associated thread.


B. Note on terminology: For what follows,
(Spanish) is shorthand for "user's non-English native language".
(Arabic) is short for "another non-English language".
(*Spanish) and (*English) are interchangeable variables for two
languages, one of which is English.

C. Basic concepts and design philosophy
Write in Spanish-based quasiPython, save in English-based Python.
   reason: this keeps code fully portable, yet lowers the barriers to
entry, especially for younger children who are not comfortable with
English.

Built-in translations of python keywords for all OLPC target languages
   reason: it's easy, there are so few.

Easy, GUI-based and dictionary-supported tools for translation of identifiers
   reason: if everyone can translate, it will go fast. Wiki-style philosophy.

Ditto for line-by-line translation of docstrings and comments
   reason: line-by-line translation allows the possibility of twext,
not too fine or too granular.

Translate ONLY module "public interfaces", not internals.
(ie, what would go in a .h file if python had them - the things that
get used 

Resend: Requesting space on Git

[Jameson \"Chema\" Quinn]

Yesterday, I subscribed to the list and sent this message. I still haven't
gotten it, making me think that it got swallowed by moderation before my
subscription took effect. I'm resending it now to see if it gets through. If
you get two copies, I apologise.

On 8/9/07, Jameson Chema Quinn <[EMAIL PROTECTED]> wrote:
>
> 1. Project name : Idly Develop
> 2. Existing website, if any : none
> 3. One-line description : A proof of concept for multilingual programming
>
> 4. Longer description   : An IDLE-based program editor demonstrating the
>
>concept of transparent non-English-based editing of
>real python code. See notes, below, for further 
> discussion.
> :
> :
>
>
> 5. URLs of similar projects : Well, there's IDLE, and from about 1995-98 
> Appletalk did something similar... but this is really a new concept.
>
> 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 homunq Jameson Quinn www.casarizoma.org/id_dsa.pub
> [EMAIL PROTECTED]
>
> I know that at least a couple of others would be interested, I'd be happy to 
> allow any who want to to sign up.
>
>
> 7. Preferred development model
>
>[X] Central tree. Every developer can push his changes directly to the
>
>project's git tree. This is the standard model that will be familiar to
>CVS and Subversion users, and that tends to work well for most 
> projects.
>
>[ ] Maintainer-owned tree. Every developer creates his own git tree, or
>
>multiple git trees. He periodically asks the maintainer to look at one
>or more of these trees, and merge changes into the maintainer-owned,
>"main" tree. This is the model used by the Linux kernel, and is
>
>well-suited to projects wishing to maintain a tighter control on code
>entering the main tree.
>
>If you choose the maintainer-owned tree model, but wish to set up some
>shared trees where all of your project's committers can commit directly,
>
>as might be the case with a "discussion" tree, or a tree for an individual
>feature, you may send us such a request by e-mail, and we will set up the
>tree for you.
>
> 8. Set up a project mailing list:
>
>
>[ ] Yes, named after our project name
>[ ] Yes, named __
>[X] No
>
>When your project is just getting off the ground, we suggest you eschew
>a separate mailing list and instead keep discussion about your project
>
>on the main OLPC development list. This will give you more input and
>potentially attract more developers to your project; when the volume of
>messages related to your project reaches some critical mass, we can
>
>trivially create a separate mailing list for you.
>
>If you need multiple lists, let us know. We discourage having many
>mailing lists for smaller projects, as this tends to
>stunt the growth of your project community. You can always add more lists
>
>later.
>
> 9. Commit notifications
>
>[ ] Notification of commits to the main tree should be e-mailed to the list
>we chose to create above
>[ ] A separate mailing list, -git, should be created for 
> commit
>
>notifications
>[X] No commit notifications, please
>
> 10. Shell accounts
>
>As a general rule, we don't provide shell accounts to developers unless
>there's a demonstrated need. If you have one, please explain here, and
>
>list the usernames of the committers above needing shell access.
>
> 11. Notes/comments:
> A. For prior discussion of this concept, see (oldest to newest):
>
> http://wiki.laptop.org/go/Develop#Human_Language_and_Culture_Concerns
> http://wiki.laptop.org/go/Source-code_editor_with_transparent_native-language_display
>
> http://wiki.laptop.org/go/Source-code_editor_with_transparent_native-language_display/design
>
> http://lists.laptop.org/pipermail/sugar/2007-August/003012.html and 
> associated thread.
>
>
> B. Note on terminology: For what follows,
> (Spanish) is shorthand for "user's non-English native language".
>
> (Arabic) is sh

Re: some first impressions

[Jameson "Chema" Quinn]

I've archived this discussion on robotics/LED output, with some points of my
own, on the wiki at http://wiki.laptop.org/go/Electrical_output.

Jameson Quinn

On 8/11/07, Mitch Bradley <[EMAIL PROTECTED]> wrote:
>
> Hal Murray wrote:
> >>  - some parallel port (or similar) should be made available, for
> >> children to play with in physics. I remember playing with a PC
> >> parallel port with some simple software to turn leds on and off. When
> >> you are a kid, being able to send commands to projects you create is
> >> great (think about modern legos, but using simpler stuff like leds,
> >> motors, etc) : it translate the "virtual part" ie the software you
> >> create on the computer to the "real world" where you make leds blinks
> >> in sequence, or a motor move.
> >>
> > ...
> > There are USB connectors.
> >
> > ...
> > USB to printer port adapters are also available.  I've never played with
> one.
> >  Prices are under $40.
> >
> >
> > There are also things like this with 24 GPIO lines.
> >   USBIO24R
> >   http://www.elexol.com/
> >   US distributor: http://www.orteches.com/  $75
> > ...
> >
> > There is also the microphone input and audio output for A/D and D/A.  I
> think
> > the XO hardware supports a DC coupled mode.
> >
> > We should work on a collection of hacks to demonstrate how they work and
> a
> > list of which ones are known to work.
> >
>
> OLCP just had a summer intern, Arjun Sarwal, who developed some low-cost
> gadgets to plug into the mic port - temperature sensor, intrusion
> detector, etc.  He plans to document them and set up a framework for
> documenting other similar hacks.
>
> We also talked about an OLPC digital gadget prototyping dongle with a
> USB-equipped microcontroller like those available from, for example,
> Atmel.  Those chips cost a dollar or two and Arjun can get all the other
> parts really inexpensively in India where he lives.
>
> ___
> 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: #2819 NORM Trial-3: need way to make a non-sharable activity

[Jameson \"Chema\" Quinn]

Pardon my ignorance, but here's another possible reason for wanting the icon
and menu anyway: to decide whether the activity is hidden from others. I'm
not sure if this function exists or is planned, but it seems to me a good
idea: a user should be able to 'go invisible' when using a non-shared
activity. (If they're in a classroom, the teacher could notice their absence
from the visible neighborhood, but if they're at home they don't have to
constantly tell the world what they're doing when. Small town gossip is a
powerful force and some steps within reason to limit its scope are
definitely good.)
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Bityi (Develop i18n) happening on OLPC's git in idly-develop

[Jameson "Chema" Quinn]

This is about the status of my work on a translating editor for python,
based on IDLE. For those who don't already know (sorry for repeating myself
with those who do): the basic idea is to make an editor which dynamically
translates python code on load/save/execute into or out of a non-English
language. This would facilitate a non-English-speaker to code in Python,
while still leaving normal English python in the .py file on disk.

There is a more in-depth and up-to-date version of the status and some of
the main design choices on the OLPC wiki at
http://wiki.laptop.org/go/Bityi_(translating_code_editor) . Links on these
pages also explain how to get it from OLPC's git (version control).

I realize that many people already learn Python or other programming
languages without learning English. I also realize that a professional
developer will eventually benefit from learning English. This is intended as
a stepping-stone and a tool to help lookup, not as replacement for at least
understanding English-based code. It is aimed first of all at young
programmers, the very kind that the OLPC project is trying to form.

I am coding a demonstration-of-principle, based on IDLE. It has already
grown to nearly 700 lines of code and will probably reach to at least double
that before it's done. Still, it is starting to actually work in limited,
but interesting, ways. I'm happy to continue this project by myself, but I
think it's far-enough-along to invite others in. So: respond to this email
if you're interested.

There are many issues still incomplete, and several I'm still not clear on
how they'll end up (undo, "is not", translating keywords inside docstrings
and comments, etc.) but one thing I'd especially like help with would be
parsing import statements into actual file paths.

I will not send further routine status messages or discussions to this list,
but only to those people who have demonstrated interest.

I expect this work to result in a relatively-minor PEP (adding a fall-back
when importing files - for instance, if 'import
somemodule.translationversion.2' fails it will try to import somemodule).
I'd also love help working out the details of that PEP.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Use-case for turning off display smoothing

[Jameson "Chema" Quinn]

I'm thinking about syntax coloring. In cases like this, it is more important
to be able to see *whether* something is colored than to see what color it
is. Even with no backlight, the diagonal banding would give you that
information; the smoothing, by reducing that banding, would be getting in
the way.

Just a thought,
Jameson
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Pippy and Calculate

[Jameson \"Chema\" Quinn]

I agree. This would provide a good use case for Pippy, something directly
useful which would get kids involved. It would be great if some simple
programming like::

  for x in range(0,5,.1):
 y = x ^^ 2
 plot(x,y)

... would work without needing 'import plotter', then it would be a graphing
calculator too. Of course, as soon as you ran the above plot, you'd need to
follow up with::

 plotter.auto_rescale()

(That is, the invisible "from plotter import *" would include::
  Class Plotter
  ...
  def plot(self,x,y):
  self.show()
  ...
  ...
  plotter = Plotter() #Make a default plotter
  plot = plotter.plot #Make a shortcut so that a beginner can type plot
instead of plotter.plot
)

... As to the volunteer-power, I agree that it needs help, but that's a
separate issue.

The one place Calculator is clearly better than Pippy is as a nice simple
Sugar example app, we can let it be nothing but that (not in the default
build, but available and easily installable if anyone wants it).

my-two-cents-worth-ly y'rs,
Jameson

On 9/4/07, Yoshiki Ohshima <[EMAIL PROTECTED]> wrote:
>
>   Hello,
>
>   Now, we have Pippy.  Into Pippy, the user can type simple
> expressions with some mathematical functions there and execute the
> expression.  This means that there is large overlap between it and
> Calculate.  Since Calculate is overly under-developed and it has very
> complicated interface, we can now think that we have an option to
> remove it from the build without causing too much grief.
>
>   Imagine if Pippy has a button called "Print!", which would be
> located right next to the "Run!"  button.  And, if "Print!" prints out
> the results of running the program into the bottom pane, that is
> pretty much all we need.  (For the record, the workspace in Etoys has
> been there from day one for this purpose.)
>
>   Some small input assistance may be a plus but having the software
> keyboard for numbers is not a good idea anyway.
>
>   We have a real problem of shortage of man-power, so replacing
> smaller activities that take more time to maintain and document with
> more powerful ones is probably a good thing.
>
>   What do you think?
>
> -- Yoshiki
> ___
> 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

Help with git

[Jameson \"Chema\" Quinn]

I am having some problems with git - essentially, my .gitignore and
core/editor config options are not working.

If you can help, THANK YOU. Please respond to this problem on
http://wiki.laptop.org/go/Talk:Git to avoid clogging up the list.

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

Re: Telling time (was: StopWatch activity)

[Jameson "Chema" Quinn]

>
>
> What I was suggesting though is
> that there should *not* be a clock in the Sugar frame visible all the
> time.




+1 to including hooks to Sugar for frame-resident mini-apps.
+1 to making the frame clock optional (turned on from the clock activity -
another reason to keep it an activity) and not the default option. If people
want it, they will find it - vice versa is not as true.
+1 to a respect that there are vastly differing cultural views of time

-1 to the idea that any other culture's view of time is so inherently
fragile that it can be shattered by a simple digital clock. The percentage
of people who have NOT seen a clock is ever-shrinking - I suspect it's
a safe guess that many people reading this message may have grown up when
that percentage was several times what it is now. I'll hazard another bet:
the xo will NOT have any measurable impact on that trend. And another:
many cultural views of time are in fact just as compatible with the clock as
yours, even if you (naturally) think that yours is the logical result of the
clock.

-1 to the idea that we should deliberately leave out features in order to
encourage kids to program. O, ye of little faith.

My opinions,
Jameson
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Consistent sound

[Jameson "Chema" Quinn]

I also like the idea, although that and fifty cents will buy some gum. Just
wanted to add a pair of emotions:
"consternation" and "gotcha" (obvious responses to a check or an atari, from
the perspective of either player).
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Status of Develop.activity?

[Jameson "Chema" Quinn]

Starting January 6, I plan to be working 20 hours a week on Develop.
Actually I was gonna do tinymail first as Sugar practice. I estimate that I
will have something useable (for Develop) within a month, though "usable" is
very very far from feature-complete. No source control, language features,
activity sharing, or even a real debugger in the initial version, just a
python editor and shell. Any one of the aforementioned extra features would,
of course, more than double the total work, but all are important in my POV.
As soon as I can, I plan to start working on language features (my pet
project, search the wiki for "bityi" to see some of my ideas). I would be
happy to coordinate with MCFletch to split up the job, but it looks as if
they have plenty else on their plate too...

 I plan to apply for a developer machine, too, as soon as the Christmas rush
is over. Hopefully enough hours of developer work earns you one, even if
you're not working on hardware and drivers. (And don't y'all want somebody
demoing in Guatemala?)

Jameson

On Dec 5, 2007 2:03 PM, Michael Burns <[EMAIL PROTECTED]> wrote:

> http://blog.vrplumber.com/2009
>
> On Dec 5, 2007 8:30 AM, Charles Durrett <[EMAIL PROTECTED] >
> wrote:
>
> > Am I missing where the status of Develop activity is documented?
> >
> > Is it (1) in work, (2) frozen, (3) abandoned/orphaned, (4) unknown/no
> > consensus?
> >
> > Andrew Clunis had it for a while but last change was months ago.
> >
> > TIA
> >
> > ___
> > Devel mailing list
> > Devel@lists.laptop.org
> > http://lists.laptop.org/listinfo/devel
> >
> >
>
>
> --
> Michael Burns * Student
> Open Source {Education} Lab
> ___
> 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: Status of Develop.activity?

[Jameson "Chema" Quinn]

>
>
> Hey folks:
>
> I'm glad to see some interest in getting the Develop project going
> again.
>
> A few comments/notes:
>
> - we really need to hash out the requirements for the first iteration.
>

You, who have actually worked on this, are probably best positioned to make
a first draft... This email covers the trickier cases, I think almost
nothing here is a v0.5 requirement. I'd like to see your ideas on what is.

>
> - version control.  Activity Sharing (see below) only really covers the
> Pair Programming use case.  The version control concept covers a range
> of other issues.  Develop should track changes made by programmers, and
> provide them with a means to share and merge their changes. This one I
> spent a fair amount of time on.  The current version of Develop uses bzr
> for version control, and it actually works in a very minimal way (or
> did, anyway).  However, by doing so I was duplicating logic; in my view
> the correct approach would be to truly use DataStore/Yellow as our
> storage mechanism.  However, the DS isn't a true source code management
> system with merging and distributed history.  The models just don't
> *quite* fit.


Even  though this is probably not an initial requirement, it is clearly an
eventual feature. It would be great to hear some more details of what it
actually did with Bazaar and what would/would not have worked with Yellow.


>
> - the editor component has already been prepared for us;  AbiWord has
> added source editing features like a line number ruler, syntax
> highlighting, and of course the collaborative editing mode (which will
> be very useful for Pair Programming).


This is one case where an important decision needs to be made up front. In
favor of Abiword, there is the collaborative editing mode, and to a lesser
extent there are probably some minor UI quirks which will be familiar to
users from the Write activity. In contra, there is the data model. If we
hope to have live syntax coloring, translation, rudimentary error checking,
drag+drop UI editing while the source file is open, etc., we will want
higher-level code to be intimate with the data structure which holds the
text, able to link an arbitrary span of text with an arbitrary in-memory
data structure. But the AbiWord project (to their own chagrin) has no
concept in their data structures of "an arbitrary span of text". Formatting
is turned on and turned off by separate tags, not start/end tags.

My own instinct is that in the long run, it will be easier to add
collaboration to a clean underlying model, than to inherit and shoehorn a
giant codebase into a use it was not really designed for. There is a real
sacrifice there, though: it means that collaboration will come much later.

I've touched this issue with Andrew and I think we sympathize somewhat with
each other but not enough to change our overall vote. It would be good to
get some other opinions.

>
>
> - Pippy and Develop should be worked on in concert.  Right now Pippy
> just uses gtksourceview, and really should end up sharing a lot of
> common logic.


Check.

>
>
> - Chema's been looking into internationalising Python.  I do not envy
> him in this task. :)


That's me. It is, indeed, a bigger task the deeper I dig. I still think it's
feasible though, and worthwhile especially for OLPC.

>
>
> Develop also proved tricky to work on, simply because I was outside of
> OLPC proper.  Develop will likely require some work done on the design
> of the sugar platform itself (the DS comes to mind).
>
> The current code is rather over-engineered.  I tried to create a
> so-called "object model" to describe every aspect of an Activity, and
> eventually got lost in a big pile of classes and interactions.


Develop clearly needs some MINIMAL awareness of all the parts that make up
an activity. That includes source, graphics, .po language files, etc. I
think that it should do as little magic handling of interactions as possible
though - don't fix things for me, just give me the right tool to do it
myself.

>
>
> I began to tumble down the rabbit hole of stressing over all these
> issues, rather than focusing on having a minimal program that does the
> simplest thing that could possibly work.  I did have a working tabbed
> editor with TreeView and bzr version control, but it was very slow when
> working with large trees.  Eventually I ended up losing interest simply
> because I didn't really have much to show for my efforts, and now the
> code is both broken and incompatible with the current version of Sugar.
> Shame on me.
>
> I think it might be appropriate to start over, and merely use the
> current version as a reference.


>
> What do you guys think?


Starting over sounds good. However, as I said above, I'd love to hear some
more details about lessons learned - I'm sure you know more than your source
code comments.

>
> >
> --
> Regards,
> Andrew Clunis
>
___
Devel mailing list
Devel@lists.laptop.org
htt

Re: Oprofile, swap

[Jameson "Chema" Quinn]

>
> I suggest taking a look at PyPy for Python, which will dynamic recompile
> Python to native code and likely give some good performance benefits.  I
> really can't stand JIT compilation and would prefer something that takes
> advantage of Mono's own facilities, to centralize the effort in the JIT
> at least (Mono has nice stuff), but IronPython is Microsoft Permissive
> License which is not OSI approved.
>

Has anyone looked at Psyco on the XO? The point is, no generic mono JIT is
going to be as smart about guessing the 95% case for Python, as something
written specifically for Python.

Disclaimer: I have no experience to back this up.

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

Re: Oprofile, swap

[Jameson "Chema" Quinn]

On Dec 18, 2007 3:54 PM, Ivan Krstić <[EMAIL PROTECTED]>
wrote:

> On Dec 18, 2007, at 12:27 PM, Jameson Chema Quinn wrote:
> > Has anyone looked at Psyco on the XO?
>
>
> Psyco improves performance at the cost of memory. On a memory-
> constrained machine, it's a tradeoff that can only be made in laser-
> focused, specific cases. We have not done the work -- partly for lack
> of time, partly for lack of sufficiently good tools -- to determine
> those foci.
>
> --
> Ivan Krstić <[EMAIL PROTECTED]> | http://radian.org
>


Agreed. But with the right tools I believe that Psyco might be worth it in
the work/advantage ratio. If my understanding is correct, it's the only
optimization tool that "understands" python types and optimizes your code
for the types you use, in the Python Way (exceptions after rather than
checks before for the rare cases). And it's the only one that is easy to
laser-focus from inside Python. This gives it a niche, even if all the other
magic being discussed is performed. But as you point out, that niche is
dependent on having dead-easy Python profiling tools.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Sugar UI design and Tux Paint

[Jameson "Chema" Quinn]

Sugar entails a complete redesign of some basic UI concepts, so I thought a
thread on how to rethink applications to take advantage would be
appropriate.

One thing I've noticed in Tux Paint is that an Edit toolbar is far less
useful than an Edit menu. You want to copy something - you go to the edit
toolbar - you select the copy 'tool' - and nothing happens, because you
don't have anything selected. So how do you select something? Oh, that tool
is over in some other toolbar.

There are various possible solutions. In order from smallest to largest
changes:

1. Move the select tool onto the Edit toolbar, or put it in both places.
2. Automatically change to the select tool for as long as you're using the
edit toolbar.
3. Move from an select - action (object - verb) metaphor to an action -
select (verb - object) metaphor. In other words, have a 'copy tool' which is
just a select tool which copies as soon as you let up the mouse. In a larger
graphics program, like Inkscape, this would mean a separate selection tool
for every possible transformation, and some sort of UI 'pronoun' idiom (a
graphical menu on the side? Or a dropdown from the tool?) for reselecting a
recent selection set, for when you want to do various transformations on the
same set of objects.

Idea number 3 is more radical, but I would be inclined towards it. I
understand that for text, when the mouse is ALWAYS the selection tool, the
current object-verb metaphor is best - but for graphics, it's actually more
steps to get select tool, select, then transform, than it would be to get
transform tool then select. For a kid who's in the see-what-it-does
mentality, I feel verb-object is more direct too.

Some more random sugar-related UI ideas:

-- Obviously, the 'preferences dialog box' becomes the 'preferences screen',
to be selected via the toolbar tabs, as if it were a toolbar.
-- The current Sugar spec on the wiki says almost nothing about the game
buttons - a good interface should allow give a consistent way for you to
select any control or menu, including contextual menus, using just these
buttons. As it is, the directional rocker is just useful for moving around
inside text, and the four shape buttons seem to move around rather than
doing actions or changing modes (X=select, O=context menu, square=toggle
focus from main window/toolbar/frame, which leaves check free as a modifier
key to use as shift with the arrow buttons... but that would be another
thread)
-- The clipboard stack should show the first few characters of a text
fragment in the frame


That's plenty for now, I hope that other people opine here too. If this
thread goes anywhere, I'll try to distill it onto the wiki.

Happy new year,
Jameson
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Sugar UI design and Tux Paint

[Jameson "Chema" Quinn]

On Dec 30, 2007 12:02 AM, Albert Cahalan <[EMAIL PROTECTED]> wrote:

> Jameson "Chema" Quinn writes:
>
> > One thing I've noticed in Tux Paint is that an Edit toolbar is far
> > less useful than an Edit menu. You want to copy something - you go
> > to the edit toolbar - you select the copy 'tool' - and nothing
> > happens, because you don't have anything selected. So how do you
> > select something? Oh, that tool is over in some other toolbar.
>
> Huh? Tux Paint doesn't have any of that complicated stuff.
> Are you sure you're using Tux Paint? The icon is a penguin.


Oops sorry, I meant the OLPC "Paint" activity, I didn't realize there were
two.

(I read with interest your other comments on Sugar, and would say "I agree"
if it weren't just me bikeshedding.)

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

Re: Sugar UI design and Tux Paint

[Jameson "Chema" Quinn]

> > There are various possible solutions. In order from smallest to largest
> > changes:
> >
> > 1. Move the select tool onto the Edit toolbar, or put it in both places.
> > 2. Automatically change to the select tool for as long as you're using
> the
> > edit toolbar.
> > 3. Move from an select - action (object - verb) metaphor to an action -
> > select (verb - object) metaphor. In other words, have a 'copy tool'
> which is
> > just a select tool which copies as soon as you let up the mouse. In a
> larger
> > graphics program, like Inkscape, this would mean a separate selection
> tool
> > for every possible transformation, and some sort of UI 'pronoun' idiom
> (a
> > graphical menu on the side? Or a dropdown from the tool?) for
> reselecting a
> > recent selection set, for when you want to do various transformations on
> the
> > same set of objects.
>
> All of these are valid suggestions.  The drawback to all is that they
> make assumptions about the types of selections that can be made (More
> specifically, they don't allow for compound boolean selections).
> Perhaps that's not something many (any?) kids will want or need, but
> we have to observe the limitations that come with decisions we make.
> Actually, the 3rd is the only one which strictly limits this.  I'd
> lean to 1 or 2 myself, which would allow a complex compound selection
> to be made should a child desire one, and then offer a subset of
> selection tools to modify or change the selection with the toolbar
> visible.


This problem suffers not from too few solutions, but too many. Right clicks,
tool settings menus (from the tool or using a right click on the canvas),
little indicators in the corner of the tool pointer, modifier keys, and
doing compound actions part-by-part: these are all possibilities. Of course
there are disadvantages, too: obscurity (hard to 'discover'), complication,
limitations. I think that the best solution will end up being some judicious
combination.

A good interface would have a variety of selection styles - lasso, marquee,
fill ('magic lasso'), as well as add/subtract(/xor?) for all of the above.
This should be indicated in the pointer, and accessible using sticky
keyboard modifiers (I think all keyboard modifiers should be sticky for the
duration of one complete action), right-click context menus within the
canvass, or hover menus on the tool itself. Note that the possibility of a
compound selection means deviating from the verb-object model (choose tool -
construct selection - computer processes result and begins to blink result -
press enter or choose other tool to apply result).

 Of course, we're really
> talking about special cases of bitmap graphics, as with vector
> graphics, the model you speak of makes more sense, which the objects
> are truly discrete objects, and not part of a flattened whole.  I


Actually, as far as I can see, it's more case-by-case. 'Paint' has limited
selection possibilities, and most of the verbs are pretty commutative and
associative, so my model is simple. A more full-featured photo editor has
much trickier forms of selection; and a more full-featured vector editor
like Inkscape has some verbs which are neither commutative nor associative,
and some which can only act on different classes of objects (shapes, paths,
bezier points, or text).

> in
> fact, in most SVG editors, the transform 'tool' is implicitly
> available when an object is selected.


For simple translations or orthogonal dilations - but not rotations or
skews.


>
> > Some more random sugar-related UI ideas:
> >
> > -- Obviously, the 'preferences dialog box' becomes the 'preferences
> screen',
> > to be selected via the toolbar tabs, as if it were a toolbar.
>
> I'm not sure this is necessarily obvious.  The tabs should really be
> defining sets of tools, and not separate screens when at all possible.
>  Moreover, the design of palettes bears preferences in mind, with the
> intent that the secondary palette be used to provide contextual
> preferences for the specific control.  In this manner, preferences
> and/or parameters of the brush tool can appear in its secondary
> palette.  We're steering away from global preferences as much as
> possible.
>

Granted, and laudible. But I doubt they can be avoided altogether, even if
you end up calling them something else. An email program, for instance, will
always need its account settings... and yet you will not want the controls
for that to be everpresent on the screen.

>
> > -- The current Sugar spec on the wiki says almost nothing about the game
> > buttons - a good interface should allow give a consistent way for you to
> > select any control or menu, including contextual menus, using just these
> > buttons. As it is, the directional rocker is just useful for moving
> around
> > inside text, and the four shape buttons seem to move around rather than
> > doing actions or changing modes (X=select, O=context menu, square=toggle
> > focus from main window/toolbar/frame, wh

Re: Sugar UI design and Tux Paint

[Jameson "Chema" Quinn]

On Jan 2, 2008 2:17 PM, Eben Eliason <[EMAIL PROTECTED]> wrote:

> 
>

 ... discussion running on... the next step is example code... not gonna do
it next.


> 
>
> Quite true.  I think we'll probably introduce a form of fullscreen
> "modal dialog" for such a thing.  That is, you press an "account
> settings" button and get a fullscreen overlay containing all of the
> necessary settings, hiding the rest of the interface, including the
> toolbar itself, to focus the child on the task at hand and eliminate
> the presence of temporarily insensitive controls which don't respond
> and keeping this preferences screen independent from the persistent
> interface of the activity itself.


The whole point of a modal dialog box is that there are only 2 ways out, OK
and Cancel. This lets the program not apply the changes until you press OK -
like the 'save' command. But there is always another way out - killing the
activity from the user view. Sometimes it would be more kid-friendly to keep
changes as soon as they happen. If we do this, there's no reason to hide the
frame.

>
>
> > > Actually, while the HIG doesn't have too much to say on this yet, it
> > > does outline clearly that the UI will transition to fullscreen (no
> > > toolbars) when in Handheld mode, and the cursor itself will be hidden
> > > by default.  The shape buttons will then be assigned special functions
> > > relevant to the current activity, providing a limited but tailored set
> > > of functions for the current activity.  The spec for Browse on the
> > > wiki outlines in detail how this could work.
> > >
> > >
> >
> > 'Special functions relevant to the current activity' is fancy talk for
> > 'ad-hoc and obscure'. Some consistency is necessary - even if it's just
> > cell-phone-like, with an indicator of what the buttons do when you press
> > them (a little picture of the four buttons with meaningful text and
> icons
> > next to them) which shows up in the corner next to them for a short time
> > whenever you press one.
>
> Absolutely.  I wouldn't think of advocating this without a simple and
> consistent way to view the mapping for the current activity, in some
> form or another.
>

Oh yeah? So where's the spec? Or do you want me to write one?

(Sorry, I don't mean to imply that everything should be perfectly complete.
It is fine to have places in the HIG that say 'we're still writing the spec
for this'. But there should be some indication of how the thinking is
going.)

>
> > I would still advocate for a more comprehensive plan, like the one I
> began
> > to sketch out in the original message included above. It puts the load
> on
> > Sugar itself, instead of on the programmer of each individual acivity -
> an
> > obvious advantage.
>
> This isn't necessarily so straightforward.  For instance, in the
> Record activity the thing you really want to do most is [take a
> picture]. In browse, you probably want a [follow link/forward] and
> [back] buttons.  In a game of tic-tac-toe you need a [play piece]
> button.  I don't think there is a very good generic solution to the
> Handheld mode buttons, and therefore hope to focus on a consistent
> system by which activities can identify and map these buttons to a
> core set of functions relevant to the activity.
>

Your examples all give one or two default actions. I think this will be
typical. Also note that the only case with two - Browse - the two actions
can be thought of as movement in opposite directions along the same axis.
(The exception to my rule would be a media player, which wants 3: ff, rev,
and play/stop)

In order to use a set of controls efficiently, I think it takes about 7
buttons. Aside from the main 'do it' button, there are 6 for navigation: the
four physical directions and two more directions (in and out) to let you get
context menus ('in'), jump out of text fields ('out'), and get out to the
toolbar and frame. (I know, you want to hide the toolbar by default. But
there's no reason it shouldn't be accessible.)

That means that there's enough buttons for generalized navigation and ONE
activity-related button. It would be nice to have another sometimes but it
is enough. The special button can be 'back' for the browser, 'ff'
(toggleable using controls to 'rev') for a media player, 'take picture' for
the camera, etc. The nav arrows turn pages in a book reader, or, if you
REALLY need scrolling, you just have to give up on a dedicated turn
backwards button.

Concretely: the arrow keys would navigate a selector between controls, the X
key would choose the control with the selector, the square key would pop out
of context menus, out of text boxes or other complex controls, out to the
toolbar, and out to the frame, in that order (followed by out to user,
group, world view??); the check key would go in the opposite direction; and
the O key would be activity-specific.

The added benefit of doing things like this, as I mentioned, would be that
an activity programmer would need to worry about resp

Re: Sugar UI design and Tux Paint

[Jameson "Chema" Quinn]

On Jan 2, 2008 5:35 PM, Eben Eliason <[EMAIL PROTECTED]> wrote:

> > > Quite true.  I think we'll probably introduce a form of fullscreen
> > > "modal dialog" for such a thing.  That is, you press an "account
> > > settings" button and get a fullscreen overlay containing all of the
> > > necessary settings, hiding the rest of the interface, including the
> > > toolbar itself, to focus the child on the task at hand and eliminate
> > > the presence of temporarily insensitive controls which don't respond
> > > and keeping this preferences screen independent from the persistent
> > > interface of the activity itself.
> >
> > The whole point of a modal dialog box is that there are only 2 ways out,
> OK
> > and Cancel. This lets the program not apply the changes until you press
> OK -
> > like the 'save' command. But there is always another way out - killing
> the
> > activity from the user view. Sometimes it would be more kid-friendly to
> keep
> > changes as soon as they happen. If we do this, there's no reason to hide
> the
> > frame.
>
> That's a good point.  Here again, though, changing some preferences
> may result in more invasive changes to the interface, non-trivial
> computation to apply, or changes to the structure of the activity in
> such a way that they aren't undoable.  All of these things are reasons
> that an activity may want a strictly modal interface.


Agreed. I said, 'sometimes'. I think that it is better to stay non-modal if
possible. (For the last of your cases, changes to activity structure, eg
email settings or ftp server or something, an autosaving
dropdown/autocomplete list of previously-used settings is a way to provide
undo without overloading the 'undo' command. Invasive changes to the
interface should not be opaque - there should be some visible way to realize
what is going on, or even a cue to changing the preferences back. And as for
nontrivial computation, it is at least theoretically possible to save the
settings in real time but apply them later. So I think that the
modal-necessary cases still exist, but are rare exceptions.)

>
>
> > > > > Actually, while the HIG doesn't have too much to say on this yet,
> it
> > > > > does outline clearly that the UI will transition to fullscreen (no
> > > > > toolbars) when in Handheld mode, and the cursor itself will be
> hidden
> > > > > by default.  The shape buttons will then be assigned special
> functions
> > > > > relevant to the current activity, providing a limited but tailored
> set
> > > > > of functions for the current activity.  The spec for Browse on the
> > > > > wiki outlines in detail how this could work.
> > > > >
> > > > >
> > > >
> > > > 'Special functions relevant to the current activity' is fancy talk
> for
> > > > 'ad-hoc and obscure'. Some consistency is necessary - even if it's
> just
> > > > cell-phone-like, with an indicator of what the buttons do when you
> press
> > > > them (a little picture of the four buttons with meaningful text and
> > icons
> > > > next to them) which shows up in the corner next to them for a short
> time
> > > > whenever you press one.
> > >
> > > Absolutely.  I wouldn't think of advocating this without a simple and
> > > consistent way to view the mapping for the current activity, in some
> > > form or another.
> > >
> > >
> >
> > Oh yeah? So where's the spec? Or do you want me to write one?
>
> There is no spec yet.  There is a ticket outlining some thoughts on
> the subject: http://dev.laptop.org/ticket/1310


Interesting - you're considering taking over the rotate key...


>
> > > This isn't necessarily so straightforward.  For instance, in the
> > > Record activity the thing you really want to do most is [take a
> > > picture]. In browse, you probably want a [follow link/forward] and
> > > [back] buttons.  In a game of tic-tac-toe you need a [play piece]
> > > button.  I don't think there is a very good generic solution to the
> > > Handheld mode buttons, and therefore hope to focus on a consistent
> > > system by which activities can identify and map these buttons to a
> > > core set of functions relevant to the activity.
> > >
> >
> > Your examples all give one or two default actions. I think this will be
> > typical. Also note that the only case with two - Browse - the two
> actions
> > can be thought of as movement in opposite directions along the same
> axis.
> > (The exception to my rule would be a media player, which wants 3: ff,
> rev,
> > and play/stop)
>
> I only provided one or two, but I imagine that most activities will
> use them all.  Read my proposal for Handheld mode in Browse for a more
> complete understanding of the type of interface I was envisioning:
> http://wiki.laptop.org/go/Browse#Handheld_Mode.  In this paradigm, the
> buttons retain their pairings when needed, and they can have both
> instant and hold states (as modifiers which reveal an overlay menu
> which can be navigated via the directional buttons).


A lot of good 

Copy-on-write for develop

[Jameson "Chema" Quinn]

I'm doing some initial thinking about how I want the Develop activity to
work. I'd like it to start out with write access to a shallow (file-linked)
copy of the activity's whole directory, and then if there are any writes,
start up source control. I'm not an expert on file systems, though, so I
don't know how easy this scheme is. Is copy-on-write link breaking supported
on JFFS2? I google the ideas and I get a lot about the JFFS2 internals,
which do support COW, but nothing about whether that's accessible outside
the OS.

Does anyone know if it is possible for Sugar to support something like this?
That is, if it there's any way - either file-system-native or through some
strap-on - to safely hand a link to a process so that (either magically or
manually) it can replace the link with a local copy if needed, but it CANNOT
modify the original file?

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

Re: Copy-on-write for develop

[Jameson "Chema" Quinn]

>
>
> Jameson "Chema" Quinn wrote:
> > Does anyone know if it is possible for Sugar to support something like
> > this? That is, if it there's any way - either file-system-native or
> > through some strap-on - to safely hand a link to a process so that
> > (either magically or manually) it can replace the link with a local copy
> > if needed, but it CANNOT modify the original file?
>
> In the interest of simplicity, why not just use UNIX permissions and
> simple
> editor logic?
>
> The activity's files are all read-only to non-root.  Just read them into
> the
> editor.  If the user makes a change, save it as a new file, with
> appropriate
> permissions.
>
> - --Ben


This is one option. The problem is that the activity could depend on having
the right file names. So to do this, I think I'd have to make a copy of the
directory structure filled with activity-owned symbolic links, to be able to
delete and overwrite with the local copy. Some activities would probably
break even then, too, because of the difference between symbolic and hard
links.

Obviously, whatever I do in this direction is going to need special logic in
the activity isolation and the datastore, to allow Develop to get at
multiple files in funny places in the datastore, and to store in the
datastore some kind of 'key' to resume work on these files later.

In other words, this is a tough problem and I'll probably be bugging the
list dozens of times before all's done. I understand that this first issue
has workarounds, but if there's some way to get direct COWLB power in JFFS2,
that would help keep things simpler.

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

Re: Status of Develop.activity?

[Jameson "Chema" Quinn]

>
> - version control.  Activity Sharing (see below) only really covers the
> Pair Programming use case.  The version control concept covers a range
> of other issues.  Develop should track changes made by programmers, and
> provide them with a means to share and merge their changes. This one I
> spent a fair amount of time on.  The current version of Develop uses bzr
> for version control, and it actually works in a very minimal way (or
> did, anyway).  However, by doing so I was duplicating logic; in my view
> the correct approach would be to truly use DataStore/Yellow as our
> storage mechanism.  However, the DS isn't a true source code management
> system with merging and distributed history.  The models just don't
> *quite* fit.
>

I'd love to pick your brains on this. As I look at the same issues, I see it
as doubtful that the Datastore back-end will ever be a good fit, although
the interface may work. On the back-end, I envision Develop as going beyond
Pippy, to allow multiple-file projects; yet even an ideal and complete
Yellow would probably only work for single files. On the front-end, the
current Yellow interface does not appear version-aware, but I expect that
will change, and I can easily see the interface being a good fit once it
does. So you'd use Yellow just to store chits which index a revision in
Bazaar, and Yellow would do all the VC interface based on its copy of the
version history metadata.

Of course, a discussion of scope is appropriate at this stage. Should I
scale back my plans, should this be a standalone activity, or should some of
these functions be moved into the list of commonly-available sugar
libraries? As a standalone, this would shape up to be a heavyweight
activity, if it included Bazaar and IDLE (yes, I still favor building good
collaborative editing into IDLE later, over building good source editing
into AbiWord's flawed data model.) and my plans for Bityi (translating
editor, see the wiki page). Moreover, some of these services would be
appropriate for inclusion in other apps - Bazaar has some functions which
would be good for Yellow or anything else which is doing non-real-time
collaboration, and Bityi's translation would probably be appropriate
(eventually) for any of the programming activities, or even any other kind
of activity with a quasi-natural-language programming and/or logfile
component.


>
>
> - Pippy and Develop should be worked on in concert.  Right now Pippy
> just uses gtksourceview, and really should end up sharing a lot of
> common logic.


This is exactly the kind of thing I mean.

>
> I think it might be appropriate to start over, and merely use the
> current version as a reference.
>

The best reference is in your head, not in the code. When can we talk again?
(reply off-list)

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

Classroom tools

[Jameson "Chema" Quinn]

The idea of activity sharing supports several important forms of classroom
interaction, and can be stretched to accommodate many more. However the
focus on constructionism means there's a lack of support for teacher-centric
interactions, even ones which are useful in constructionist learning. Raising
hands

The fundamental model that's missing is the idea of questions or
assignments, posed by the teacher and answered separately by each student or
team of students. It is possible to accomplish this 'manually', but the
technical shuffling makes it impractical to do so in a real-time, classroom
situation, especially if it is desirable to keep data for later.

For instance, I as a teacher want to be able to pose a question and have
each student individually type a response. I could see, and record for
later, who responded what and who didn't respond. After giving a brief
interval, I could 'call on' a student either by my choice or randomly, and
continue the discussion based on their answer. There are several obvious
variations on this pattern - for instance, instead of typing a complete
answer they could just indicate whether they have an answer, ie, 'raise
their hands'; teams could present shared answers; etc. The software would
help the teacher to keep track of each student's participation and to 'call
on' students in a systematic manner.

This type of interaction is so fundamental that it would be great to have it
available independent of the currently shared activity. The obvious place to
put it, therefore, would be in the bulletin board. This means the bulletin
board would have to have some support for active logic. There are 3 ways to
do this that I can see: somehow using AJAX for the bulletin board
(advantages: highly flexible, tools exist; disadvantages: memory and
processor hog, needs some server technology on the teacher's side);
hard-coding this one case into the bulletin board (advantage: can be
optimized better; disadvantage: inflexible); or somehow making a plugin
system for the bulletin board (advantage: flexible; disadvantage: security
issues, the world doesn't need yet another plugin architecture)

(One disadvantage of using the bulletin board is that it could perpetuate
the UI chasm between on-line and off-line communication. In-class questions
are no more then small versions of out-of-class assignments, and the
interface should be as similar as possible. But that is a bigger problem,
one which permeates the XO, and deserves a separate discussion.)

Homnq  08:12, 14 January 2008 (EST)
[edit
] Classroom management

Motivation and interest are the best ways to achieve engagement, but social
pressure and good examples are also a part of the picture, and these are
impossible without transparency. If there is no easy way for teachers (or,
for that matter, other students) to tell the difference between a student
who is working on the laptop, and one who is playing DOOM, bad things
happen.

Intel/Microsoft's "Classmate" competitor is rumored to have tools for the
teacher to freeze or take over the student's laptop, "to guide them through
the interface". Regardless of whether this is a desirable relationship, it
would be hard to accomplish within the security model and memory constraints
of the XO.

However, it would be good to have tools for all members of a shared activity
to see the current state and recent history of all other current members.
This protects privacy (after all, you can just quit the shared activity for
privacy) while creating transparency. For it to be useful, it has to be
simple and fast. Useful things to see are which activities have been used,
and whether out-of-band communication has happened, over the last minute.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

libglade?

[Jameson "Chema" Quinn]

I'm still noodling around, trying to settle on a good design for develop. It
looks as if libglade would be nice to have. The interfaces it uses are
loaded directly from XML, which makes them separate from the source code. I
did a naive 'yum install libglade' and my XO pulled 100k for the library and
about 3.5 MB (uncompressed) of dependencies. For our purposes, under .5MB of
those dependencies are really needed.

If, after rebuilding to remove dependencies on gnome-libs and the like, the
whole thing came in at less than half a megabyte of uncompressed code, do
people think it should be included in the base system? Obviously, the OLPC
version would include all the sugar widgets...
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Classroom tools

[Jameson "Chema" Quinn]

Teacher screen grab: that would be good. A view of which people use what
applications is also useful, because it can fit the whole class on screen -
and it's pretty close to what you already get in the friends view. So, is it
possible under Bitfrost for a background activity to grab the screen AND see
the net? I would be surprised and upset if it were, so it probably needs a
special permission - and one that can't be set for an unsigned activity.
(note that this also protects against student hackers who would like to
write a version that always shows the teacher the screen the student
wants...)

Pop quiz: yes, this could be done as its own activity. The idea is maximum
flexibility - teacher can open or close questions in any order, can 'grade'
in real-time or offline, can reveal grades to students in real time,
offline, or never, has tools for choosing a random student to call on, can
let students see all or some of each others' answers.

It would make sense for these two activities to be rolled into one.
Otherwise you'd have to tell your students 'all right, now log into my
shared Big Brother activity, or else...'. Also it should be integrated with
some kind of gradebook/attendance sheet/etc.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: libglade?

[Jameson "Chema" Quinn]

Thanks for the reality check. But:


> I don't see any reason to include Glade, unless you also intend to include
> complete a complementary graphical interface builder tuned for Activities.
>  That
> would be a multi-year project.
>

I disagree, it's just a matter of making a widget catalog.

The reason I ask now, at the start, is that if eventually I plan to do this
- and there ARE real advantages, for instance it makes it much easier to
make an app which works on Sugar and other platforms - I want to do Develop
itself with libglade. I do not plan to spend any time making the GUI editor
until I have a usable release.


> I feel strongly that you are making Develop too ambitious.  A simple
> Python
> editor that supports collaboration and editing copies of installed
> activities
> would be groundbreaking, and cause for celebration.  It would be the most
> revered Activity of all.


Version control is at the heart of real collaboration. How many real-world
programs are done with pair programming? How many of them use version
control?

But actually, both of these are gravy. I want to first make something with
neither. But I'd rather know what I'm working towards before I start.

As for "copies of installed activities", you're right. I was wasting time
worrying about copy-on-write hard links, I should just copy for now and get
to that later. Still, for all my talk, I was not coding any Bazaar in, just
copy-on-write.

As for translatable code, sorry, that's the horse I rode in on. It's the
reason I first looked at the wiki and learned about the project beyond the
headlines. It's not in step one, but personally speaking its what I want to
contribute, and what I'll be working on as soon as step 1's done.

Jameson

ps. I'd feel better about how source control 'might be solved by the
journal' if I had more of a sense of the plans and priorities there. Even
the most basic possible Develop is going to be pushing the envelope (and
helping fine-tune the spec) with both Bitfrost and the Journal. Yet the only
coherent docs for either are way out of date, and though both are heavy with
promise, even the present reality is underdocumented, let alone the future
plans. If there are any secret archives on these, it would be great to know.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Classroom tools

[Jameson "Chema" Quinn]

>
> BTW, I am confused by this discussion thread. I thought OLPC was about
> bringing learning environments into the reach of the neglected children -
> those who don't have access to well-equipped school rooms or educated
> guides.
> Does XO really make sense in environments that already have well-equipped
> classrooms and teachers?
>

Any country in the world has dedicated, caring teachers. And in any country
in the world, teachers - whether dedicated or not - are an important
constituency in education decisions. If OLPC aims solely at
where-there-is-no-teacher, it's aiming at precisely nowhere. (I live and
teach in Guatemala, roughly middle-of-the-pack for the third world, if
that's worth anything.)

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

Fwd: Classroom tools

[Jameson "Chema" Quinn]

Let's keep our feet on the ground here.

Just because teaching is a field where mediocrity (or worse) often goes
unpunished, does not mean that expertise is irrelevant. It is possible for a
bunch of non-teachers on a mailing list to have good ideas, or to discuss
good ideas they've heard elsewhere. But some of the worst disasters in
education come from good ideas that turn into trendy dogma. Success comes
from thoughtful, flexible application and evaluation by experienced teachers
who believe, and then divulgation that respects the ideas and inclinations
of those who do not at first believe.

Most of us on this list are probably similar in our learning styles -
naturally oriented towards understanding and discovery, resistant to
repetition. I remember hating many of the most traditional aspects of
schooling, most particularly the emphasis on formulaic recipes. But when I
became a teacher and tried socratically to get my students to construct
their own recipes, refusing to tell them 'step 1 step 2' for anything, I had
some spectacular failures. One or two students would love it and figure out
what I was trying to teach in 5 minutes - then get even more bored than they
would have been from the formula, as I spent the rest of the period getting
frustrated with students who were frustrated with me because they didn't get
it and I wouldn't just tell them how. It is a hard balance to strike.

I've made constructivism work in the classroom a few times, too, and it is
great. But let me tell you: the less fired up and prepared I am, the more
likely I am to choose something more traditional. Because when things don't
go well, constructivism is much worse.

Luckily, we here do not actually have control of any schools. If we ossify
into dogmatic constructivists, we will just hurt our own project, not
students. If we do not make the tools teachers need, as well as the ones
kids need, nobody will pay any attention to us, and OLPC will just dry up
and blow away. I do not want that.

And there's another constituency besides teachers and students:
researchers/administrators/bureaucrats. It's easy to paint these guys as the
enemy. For instance, in the US, standardized testing companies, with their
seductive call of 'cheap, clean data', have seduced these guys into imposing
the nightmare of No Child Left Behind, where the test is king. But if, as I
said above, there are right ways and wrong ways to teach, who is going to
sort it out if not the researchers? Who is going to help the good mdels
spread faster than the bad ones, if not the administrators? So we need to
focus some attention on having the programs we write help to generate the
research data that they need, if we want to break the grip of standardized
testing.

To bring this all back to earth, here's another teacher-centrically-inspired
idea that I didn't include in the original message: a word processor that
saves the whole undo stack with the file. It's technically possible: it's
not actually so much more data, and text is lightweight. It would integrate
well (from a user perspective; as a programmer, this is no easy job) with
the Journal file paradigm. And it would help teachers focus on teaching
writing process instead of just results, and, by the way, provide a natural
barrier against computer-aided-plagiarism.


I sent the above message off-list by mistake. Edward Cherlin already
responded to paragraph 2:


From: Edward Cherlin <[EMAIL PROTECTED]>

...
Of course. I am well aware of the New Math disaster and several others.
That's why *I* am talking about helping teachers discover discovery, and
complaining that Nicholas dismisses teachers as irrelevant. I also know that
we have to ask teachers and children what will work in their schools under
the conditions they have to deal with.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Fwd: Dailymotion for XO laptop

[Jameson "Chema" Quinn]

That's great - a 'somebody oughta' thread that actually produces action!
Good job, guys!

Now, somebody oughta dodge the patents for MP3, too

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