Re: Touch pads
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
Re: using wiki pageviews per country of origin to motivate translations
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: [sugar] video bleeds through somewhat between sessions
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)
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 http://www.esosoft.com/support/mailinglist/mailman/topics.html 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: Terminals
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
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: Terminals
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
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
http://dev.laptop.org/ticket/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 = []
registry =
Re: [OLPC Security] preliminary [PATCH] and discussion for #5657: activity isolation for all activities in ~/Activities
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
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: [sugar] Congratulations! but Sugar sucks
| 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] Activity versioning schema
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
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] Activity versioning schema
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 severalhttp://wiki.laptop.org/go/User:Mstone/Bundle_commentary discussions http://wiki.laptop.org/go/User:Mstone/Commentaries/Bundles_2(+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
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/*Ashvasthahttp://en.wikipedia.org/wiki/Ashvastha * (buddha), juniper (navajo), buttonwood (wall street), blossoming pear (african-american - from their eyes were watching god), mulberry (china/silk), baobab, thorn tree http://www.thorntreeproject.org/ 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
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
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: Activity versioning schema
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
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
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
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
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
-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: Security for launching from URL
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: Security for launching from URL
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
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 dangerous thing? dialogs, may not be acceptable solutions
Re: While we're on Cerebro, Telepathy, etc... Cerebro + bitfrost?
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
While we're on Cerebro, Telepathy, etc... Cerebro + bitfrost?
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: Project hosting application: Bundlemaker
Cool! I would call this bookbinder if it were an activity. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Bitfrost and dual-boot
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
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
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
Bitfrost and dual-boot
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: [sugar] Release process
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
Re: [PATCH] Maintain a metadata copy outside the index (was Re: Datastore backup - request for help)
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 datastore_path/.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: Priorities for Develop?
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?
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?
* 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
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
Priorities for Develop?
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 http://wiki.laptop.org/go/Bityi/GSoC, 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: [sugar] OLPC priorities for Sugar in the August release
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
Re: very simple datastore reimplementation
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
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
-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: Rainbow 0.7.12 Announcement
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: Journal Suggestions
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: More planning thoughts
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] Usability testing
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: Build Debate: Followup on Build Naming
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. component major minor bugfix organisation 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-Version.bugfix 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: Bundles, versions, and updates - oh my!
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!
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. [edithttp://wiki.laptop.org/index.php?title=Bundles_and_updatesaction=editsection=4 ] 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. [edithttp://wiki.laptop.org/index.php?title=Bundles_and_updatesaction=editsection=5 ] 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. [edithttp://wiki.laptop.org/index.php?title=Bundles_and_updatesaction=editsection=6 ] 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 cjb 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. [edithttp://wiki.laptop.org/index.php?title=Bundles_and_updatesaction=editsection=7 ] 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. [edithttp://wiki.laptop.org/index.php?title=Bundles_and_updatesaction=editsection=8 ] Not considered - Push - type updates - Blacklists of known trojans (this is only remotely useful if there is a limited store of keys usable for
Re: [sugar] Summer of Code update : applications so far, and thanks
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 http://wiki.laptop.org/go/Bityi/GSoC 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 pagehttp://wiki.laptop.org/go/Talk:Bityi/GSoC- 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 http://wiki.laptop.org/go/Talk:Bityi/GSoC. 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: [sugar] Mini-Conference Proposal: Automatic transfer/update of activities on the mesh
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 automatically pushes
MANIFEST and .xo bundles
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?)
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. Dictionary.com 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: Mini-Conference Proposal: Frameworks for Collaboration
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?)
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 that these
Develop app
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.xohttp://wiki.laptop.org/go/Image:DoppelJournal-79.xo
.*. (ticket *#6639* http://dev.laptop.org/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*http://dev.laptop.org/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: [sugar] Automatic transfer/update of activities on the mesh (Was: Sharing behavior in the core Read activity)
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
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
Re: Raise the level of the Hardware specifications... or let's do some field tests!
Now that there are a significant number of laptops in Peru, high-altitude testing may be more feasible. What test plan would you want followed in order to be able to raise the specs? On Tue, Mar 11, 2008 at 9:00 AM, John Watlington [EMAIL PROTECTED] wrote: I understand your concern. I requested that the laptops be tested to at least 15,000 ft operationally, but was ignored. I will inquire into the reasons. John On Mar 10, 2008, at 3:05 PM, [EMAIL PROTECTED] wrote: Hello, I am trying to pass this info to some hardware development list... but I don't know where it is or if it exists. Anyway, maybe some person can register this bug (?) to the tracking system... if you consider that this is a bug.. or if it is something valuable to be taken in account... -- http://wiki.laptop.org/go/Hardware_specification Environmental specificationsMaximum altitude: –15m to 3048m (14.7 to 10.1 PSIA) (operating), –15m to 12192m (14.7 to 4.4 PSIA) (non- operating); -- The Huancavelica city (big city, poor city) is at 12,100 feet (around 3,688 meters) altitude. There are tons of computers in that city, they work without any modification. I think that the 3.048 m altitude capacity must been raised... maybe it has not been tested accurately.. or.. other reasons? The more isolated children are in the 4,500 meters (around 15,000 feet) Cuzco city is at 12,500 feet = 3,810 meters altitude. (so... no XOs for Cuzco city.. and that is the capital of the region... there are hundreds of smaller villages in higher altitude in the Cuzco surrounding areas). Table 10,000 feet = 10.11 PSIA 11,000 feet = 9.73 PSIA 12,000 feet = 9.35 PSIA 13,000 feet = 8.96 PSIA 14,000 feet = 8.63 PSIA 15,000 feet = 8.29 PSIA Andahuaylas city = 13,000 feet The maximum altitude in hardware specification for all the equipment should be raised. In Peru the towns (villages) that you can find in the 3,048 meters vecinity are not the poorest or the ones that are more isolated. Our national president (Mr. Alan García) launch a law proposal to do all territories over the 3,200 meters altitude a tax free territories. That is because, in the words of the President, and according to all our national statiscall records, the deep poverty and the isolation starts at 3,000 meters altitude. Below the 3,000 meters altitude... well... there is poverty in whole Peru... but some tests should be done to see if the XOs (and the rest of the hardware) can work at more than 3,048 meters altitude. I think they will work because I have seen normal standard PCs and all kind of equipment working at 4,500 meters altitude. That is the altitude were all the isolated communities (the ones that need more our help) are located. There are around 5,000 villages and small communities (with 100 families each village, averaged) over the 4,000 meters altitude. Deep poverty in those areas. Maybe the manufacturer (Quanta?) can put more light over the issue. My guess is that the capacity of the XOs is underestimated by the manufacturer... Best regards, Javier Some useful for those interested in the issue... About PSIAs: http://www.aempower.com/Faqs.aspx?FaqCategoryID=30 About the 2006 peruvian map of poverty: www.foncodes.gob.pe ___ 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: Microsoft? (was Re: OLPC seeks a CEO -- who was your favorite CEO elsewhere?)
On Tue, Mar 11, 2008 at 3:59 PM, Charles Merriam [EMAIL PROTECTED] wrote: Is there *any* suggestion that the entire Microsoft on OLPC story is anything other than: 1. A small group of experimenters at Microsoft playing around in the slack time. 2. FUD stories to downplay OLPC. You forgot 3. Name dropping by lazy journalists to provide an appearance of understanding and context. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Salut and Suspend/Resume issues
Just some bikeshedding here: Quasi-synchronising the avahi peer still there? queries so that they all happen together - say, within a 1-minute period every 10 minutes - was proposed as a solution so that laptops could wake up in anticipation (Benjamin Schwartz). The fact that this solution did not get attention may mean that people are not considering that it would also make a night-and-day difference in power consumption even if the laptops are able to wake-on-multicast. The fact that I can wake up and answer the phone, or that I sometimes stay up late, doesn't mean I wouldn't rather the calls were bunched together so I can get some sleep. This could be implemented using the system clock, without any new ultra-synchronization plan. If it's a fuzzy window anyway, it still helps even if synchronization is fuzzy and the occasional laptop is totally unsynchronized. The only thing necessary is that all timeouts involved should be an even divisor of one hour if they are not already. Obviously this has nothing to do with the mdns problem, which now has its own depressing thread. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: The XO and email
I don't have anything too useful to contribute, I just wanted to say that it would be great if you could make a new activity. I looked into making one based on Tinymail as my initial get-to-know-sugar exercise, but I have ended up working on Develop. I only saw enough to see that tinymail is really a large set of useful components, you have to glue everything together yourself. Therefore, if you are creating an innovative interface, and if you're up to it, it may be just as effective to shop around for the components you really need (such as Dovecot) and then do more in your own application, rather than learning all the bits of tinymail. Reduce the surface area of contact between your code and foreign code, as it were. This is great that somebody is doing this. On Thu, Feb 21, 2008 at 7:55 PM, Asheesh Laroia [EMAIL PROTECTED] wrote: On Thu, 21 Feb 2008, Shikhar wrote: Hi, I would like to get the general feeling about the XO and email. There is a Gmail activity but no possibility of composing and viewing emails offline, which I think is important. I think that might be nice also! - With Python, an email activity can be accomplished with the RFC-compliant email modules (for POP, SMTP, IMAP, MIME) and using sqlite for storage. So while building upon Tinymail (http://wiki.laptop.org/go/Tinymail) is an idea, it makes sense to just go with Python email modules and sqlite if the next point is to be implemented :-) You suggest using sqlite for storage, and further, as I understand it, writing your own mail storage layer. But on the other hand, you could use an existing top-notch Free Software mail store, like Dovecot. Dovecot comes with full-text indexing for search of email, for example, and header caching to optimize common queries (Tell me all the From, Subject, To, and Date headers). That's my main contribution to this thread - I fear you won't re-use some already great software. The rest of your suggestions could perhaps be implemented as Dovecot plugins to minimize wasted work; for the most part, I agree with them. (-: Once you start thinking of this in terms of interoperability with existing mail systems, I think you'll find you have way less work to do. For example: - Email threading: there is some Python code at http://www.amk.ca/python/code/jwz, which could be adapted Built-into IMAP, which Dovecot implements. - Search using sql queries I have a good mental picture of what I want to do - maybe I am not communicating it too well, but I am willing to elaborate. I would really like your feedback especially on the fundamental idea of using Python email modules and sqlite in case I am thinking in the wrong direction, although this appears to me to be the best approach IMAP provides SEARCH TEXT, which Dovecot can now (as of 1.1.rc1) store an index for, and therefore return answers in split-second times in many cases. -- Asheesh. -- You're already carrying the sphere! ___ 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: [OLPC library] Overweight Wiki Page
SJ's answer is the best one. However, if you want a kludgey hack, you could do something like http://wiki.laptop.org/go/User:Homunq/toctest This uses template substitution to manually create links to subpage#section in the section headers. It means that someone editing the subpage later will see: == [[subpage#section|section]] == as the section headers, and will have to edit the section name twice; but at least those two instances are right in the same place. Any new sections they create would have to use the template or follow the format above, or they would be unreachable directly from the main TOC. Obviously, you could write a bot to fix your headers the first time, or even write one which periodically checks and fixes any newly-created == normal headers == . Again, the better solution would be a mediawiki extension, if you do PHP. Jameson On Thu, Feb 21, 2008 at 2:34 AM, Samuel Klein [EMAIL PROTECTED] wrote: Derw, Having a way to generate an aggregate table of contents for a set of pages without transcluding the text of those pages could be useful. I don't believe it has been written; as far as I know this would be the first magic word[1] in MediaWiki that parses the text of another wikipage and outputs some function of that in the current page. Note that a common workaround is to make such a table of contents by hand, not to make it too finely grained, and to update it by hand when subpages change. See for instance the [[HIG]] header. SJ [1] http://meta.wikimedia.org/wiki/Help:Magic_words On Wed, Feb 20, 2008 at 5:46 PM, drew einhorn [EMAIL PROTECTED] wrote: Hi, I've got a couple variations on a way overweight wiki page. It began as a MS Word file, and it's been through Open Office, shell, sed, perl, awk, python and the result is not too shabby. Should publish it, but really ought to rewrite it all in python first. Is there a way to use the command line to open a .doc file in Open Office and save it as html an can add to my polyglot assortment of scripts, in the meantime? The first version at: http://wiki.laptop.org/go/VistA_Monograph_Wiki gets: WARNING: This page is 246 kilobytes long; some browsers may have problems editing pages approaching or longer than 32kb. Please consider breaking the page into smaller sections. I've been looking at breaking it up and reassembling it using templates and there is a partial version at: http://wiki.laptop.org/go/WV_VM Is there a easy way to transfer all 70 some pieces at once, instead of doing them one at a time using http://wiki.laptop.org/go/Special:Upload But wait that's only for Images not for Pages. And when the templates all get reassembled it's going to be just as big, if not a little bigger. What I really need is a syntactic variant, that builds a combined Table of Contents, but does not put all the pieces together into a combined wiki page, the links in the Table of Contents take you the right spot in one of the component pages. Does that capability exist, or am I just dreaming? -- Drew Einhorn ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Library mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/library ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC library] Overweight Wiki Page
Making a mediawiki bot is not too hard - all the skeleton exists in python, you only have to flesh it out with your own logic. As for the TOC, the template idea is that you use noinclude ... /noinclude around all the parts of the templates that are NOT headers (or you can start the noinclude after one paragraph, to give the idea). The problem is, then you need a way to go from the main page to the right section of the corresponding subpage, and from one subpage to the next - it may be possible, I haven't done it On Wed, Feb 20, 2008 at 4:46 PM, drew einhorn [EMAIL PROTECTED] wrote: Hi, I've got a couple variations on a way overweight wiki page. It began as a MS Word file, and it's been through Open Office, shell, sed, perl, awk, python and the result is not too shabby. Should publish it, but really ought to rewrite it all in python first. Is there a way to use the command line to open a .doc file in Open Office and save it as html an can add to my polyglot assortment of scripts, in the meantime? The first version at: http://wiki.laptop.org/go/VistA_Monograph_Wiki gets: WARNING: This page is 246 kilobytes long; some browsers may have problems editing pages approaching or longer than 32kb. Please consider breaking the page into smaller sections. I've been looking at breaking it up and reassembling it using templates and there is a partial version at: http://wiki.laptop.org/go/WV_VM Is there a easy way to transfer all 70 some pieces at once, instead of doing them one at a time using http://wiki.laptop.org/go/Special:Upload But wait that's only for Images not for Pages. And when the templates all get reassembled it's going to be just as big, if not a little bigger. What I really need is a syntactic variant, that builds a combined Table of Contents, but does not put all the pieces together into a combined wiki page, the links in the Table of Contents take you the right spot in one of the component pages. Does that capability exist, or am I just dreaming? -- Drew Einhorn ___ Library mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/library ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Fwd: Open Simulator with Physics Engine
Oops, I sent the below off-list by mistake. -- Forwarded message -- From: Jameson Chema Quinn [EMAIL PROTECTED] Date: Fri, Feb 15, 2008 at 2:28 AM Subject: Re: Open Simulator with Physics Engine To: Joshua Minor [EMAIL PROTECTED] Making a good learning simulator is an art. Too few degrees of freedom, and it is just boring; but too many are sometimes just distracting from the concept being discovered. There are some good ones in Java at http://phet.colorado.edu/web-pages/simulations-base_es.html ... these have gone through usability testing, and each is tailored to learning a related concept set. I do not know how open the University of Colorado would be to putting these under some kind of open license, but it is certainly worth a shot - they distribute them pretty openly. Jameson ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Community-news] OLPC News (2008-02-09)
re: turn off the network when not contributing I second this idea, if it can be implemented. Separate from suspended battery life, there is sleep life (I have to say I still think these words are backwards. Suspend = automatic, screen on, sleep= power button or close case, screen off; right?). One of my very biggest gripes with the laptop as a whole is that the battery inevitably runs down unless you turn it all the way off (which no kid will do). I understand the concept of participating in mesh, but this should only happen when there are 1-6 visible neighbors and actual traffic (waking it up for one minute an hour to check? On the hour, so they all wake up together?). Also, no matter what the mesh situation, a sleeping laptop should shut down the network when it gets below some threshold - I'd guess about 10-15% battery - and possibly even turn off completely to save the RAM power drain too. (if you really want to get fancy, the plenty-of-neighbors threshold should be lower when the laptop is closed, since a closed laptop has a lower range than the presumably ears-up laptops in use, so it takes fewer ears-up hops to saturate its little neighborhood. On the other hand, if you go offline when nobody seems to be handing you any meaningful traffic, you lose built-in redundancy, but this comes free.) On Sun, Feb 10, 2008 at 11:53 AM, Frank Ch. Eigler [EMAIL PROTECTED] wrote: Walter Bender [EMAIL PROTECTED] writes: [...] Chris Ball provided Richard with some power readings from our newly enhanced power tinderbox running a C2 (mass production) laptop. [...] The top auto-suspend power-draw breakdown: WLAN: 734 mW backlight:362 mW memory: 239 mW LCD: 218 mW EC: 108 mW other:339 mW total:2064 mW [...] A next step will be to see if the wireless power can be reduced during suspend. [...] Has the following idea already come up? How about just turning off the wlan entirely during suspend, if the machine has reason to believe that its contribution to mesh connectivity is negligible? - FChE ___ 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: How to create a new MIME type for a Sugar activity?
This is a little off-topic, but just wondering... In my work on Develop, I am looking at a similar situation: application bundles. These are zip files with the extension .xo. My question is, why bother zipping them if the file system compresses anyway? Why not, you ask. I know that ziptools can work on them in place (actually I don't want to anyway). But if the journal is going to eventually do version control, it may one day want to do diffs, and stuffing everything into a zip makes that a lot tougher. OTOH, these things do fly over the net, there is bandwidth. The same questions could be asked about any bundle file which is really a zip. Especially if it is full of jpg files, which zip doesn't compress any anyway. Just a thought, Jameson ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PyCON-Organizers] OLPC Sprint(s) at PyCon
It would be great to get z3p's new Develop activity hosted on git before this sprint happens, as I am sure it would be a popular target for the audience. See the thread Activity Hosting Application: Develop, and see also its newly-revised wiki page: http://wiki.laptop.org/go/Develop . ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
EC Problem
Running joyride 1551 and q2d07, I was running a bunch of apps with backlight off, it went to sleep on me, I tried to wake it up and got a BSOD-like message about EC problem. (Had logging turned on as described in 5485, echo 0x6184 /sys/module/libertas/parameters/libertas_debug) I searched trac but couldn't find it, but it is not much help to just trac it crashed, so can anybody point me to what logs I should post if I can manage to reproduce this? ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Update.1 testing
I know that we're supposed to all be developers here, and know how to change the firmware in our sleep; but it would be great to include a link to instructions. I searched the wiki - http://wiki.laptop.org/go/Manual_Firmware_Install is worse than useless, and http://wiki.laptop.org/go/OLPC_Firmware_q2d09#Unsecure_Machines is the wrong place (why include separate instructions on each firmware build page, instead of having a general instructions page?) and also does not tell you how to do it using SD instead of USB or internal. I'll take responsibility for putting the instructions on the wiki and making appropriate links to them, if someone tells me how to do it with SD. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Update.1 testing
Simple. Put the manual install instructions in
http://wiki.laptop.org/go/Manual_Firmware_Install and then, in each
relnotes page add {{:Manual_Firmware_Install}}, which will include the text
of that page in the one it is as a template in.
If you want to be even cooler, in Manual_Firmware_Install, put the tags
onlyinclude and /onlyinclude on the stuff that you want to be included.
I've done this - and, even cooler, I used a template parameter so that you
can have the instructions refer to the right version, like this:
{{:Manual_Firmware_Install|version=q2d09}} .
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: Violent games on the OLPC Activities page
Wasn't it the Nazi's who first used censorship? On the other hand, people who died in Nazi concentration camps have unanimously refused to play Doom. New thread please? ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Violent games on the OLPC Activities page
Finally, any suggestions about how to extent, augment, or replace Media Wiki with tools to make these sorts of things easier for the community to manage would be appreciated. There are several mediaWiki extensions that might help: 1. You could do an evil hack using the well-tested PageFunctions (for variables declared at the top of an including page) and ParserFunctions (for using in templates that can hide themselves depending on the variable values). This would involve significant, hard-to-maintain work for each new slice view you wanted to implement. However, if all views were just a series of subsets of the 'all' view (all, unproblematic, core), this would not be too hard, and populating it could be done by anyone able to copy and edit wiki templates. 2. The WikiDB extension [1] appears to be precisely, exactly what is wanted here. From quickly browsing its homesite, it appears to be working, but possibly too buggy to slap onto a wiki as large as the OLPC one. Significantly, it does not guarantee that the databases it creates will stay in sync under rarer operations (restoring deleted pages...), nor does it appear at first to have a way to regenerate its databases if they do get hosed. Go have a look if you're interested and tell us what you think. 3. Semantic mediawiki is a heavyweight replacement version of Mediawiki with some tools that, while they are not precisely what we want, would work for this issue. Probably overkill. [1] http://www.kennel17.co.uk/testwiki/WikiDB ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Fwd: Activity search/browse on wiki (was violent activities)
I'm rescuing this concrete suggestion, since most people probably have the 'violent activities' thread in their killfile by now. (Sorry about that, I'm as guilty as any of adding personal anecdotes instead of productive contributions). The problem: have a community-maintained list of activities that is viewable and/or searchable in different cross-sections based on need. It should integrate well with the wiki, so probably the first place to look is for mediawiki extensions. There are several that might help: 1. You could do an evil hack by combining page inclusion with the well-tested PageFunctions (for variables declared at the top of an including page) and ParserFunctions (for using in templates that can hide themselves depending on the variable values). This would involve hacktastic, hard-to-maintain work for each new slice view you wanted to implement. However, if you keep things simple (all, unproblematic, core), this would not be too hard, and populating it could be done by anyone able to copy and edit wiki templates. 2. The WikiDB extension [1] appears to be a beta version of precisely what is wanted here. From quickly browsing its homesite, it appears to be working, but possibly too buggy to slap onto a wiki as large as the OLPC one. Significantly, it does not guarantee that the databases it creates will stay in sync under rarer operations (restoring deleted pages...), nor does it appear at first to have a way to regenerate its databases if they do get hosed. Go have a look if you're interested and tell us what you think. 3. Semantic mediawiki is a heavyweight replacement version of Mediawiki with some tools that, while they are not precisely what we want, would work for this issue. The focus is more on browse than on preconstructed views integrated with a wiki page - I think that for us the latter would probably be better. Probably overkill. [1] http://www.kennel17.co.uk/testwiki/WikiDB (sorry if you get this twice, I first sent it to devel@lists.laptop.org and since I did't get a copy I'm assuming the address doesn't work with lists in it.) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Activity search/browse on wiki (was violent activities)
I'm rescuing this concrete suggestion, since most people probably have the 'violent activities' thread in their killfile by now. (Sorry about that, I'm as guilty as any of adding personal anecdotes instead of productive contributions). The problem: have a community-maintained list of activities that is viewable and/or searchable in different cross-sections based on need. It should integrate well with the wiki, so probably the first place to look is for mediawiki extensions. There are several that might help: 1. You could do an evil hack by combining page inclusion with the well-tested PageFunctions (for variables declared at the top of an including page) and ParserFunctions (for using in templates that can hide themselves depending on the variable values). This would involve hacktastic, hard-to-maintain work for each new slice view you wanted to implement. However, if you keep things simple (all, unproblematic, core), this would not be too hard, and populating it could be done by anyone able to copy and edit wiki templates. 2. The WikiDB extension [1] appears to be a beta version of precisely what is wanted here. From quickly browsing its homesite, it appears to be working, but possibly too buggy to slap onto a wiki as large as the OLPC one. Significantly, it does not guarantee that the databases it creates will stay in sync under rarer operations (restoring deleted pages...), nor does it appear at first to have a way to regenerate its databases if they do get hosed. Go have a look if you're interested and tell us what you think. 3. Semantic mediawiki is a heavyweight replacement version of Mediawiki with some tools that, while they are not precisely what we want, would work for this issue. The focus is more on browse than on preconstructed views integrated with a wiki page - I think that for us the latter would probably be better. Probably overkill. [1] http://www.kennel17.co.uk/testwiki/WikiDB ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fwd: Dailymotion for XO laptop
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
Re: [OLPC-Games] Violent games on the OLPC Activities page
Oops - I have to stop using that 'reply' button in gmail. This was meant to go to the list in general, the first half is now obsolete (except to make me look like a fool) because Antoine responded, but the second half is still valid. You use the word us very often. Please tell the list members which country you have lived in where bombs went off next to you. I'm trying to understand you better. Sorry. Here in Guatemala, I have second-degree relatives (first-degree to my wife) who were tortured and third-degree relatives who were killed. And if my wife were to hear me say that, she would be angry, because when you live in a dirty-war zone, where calling names can get people killed, you get a different attitude to security and information. Responding to a call for empathy towards a population we all agree exists, with prying individual questions, should be rethought, not answered. Just my opinion. Back on topic: This is an opportunity for two-birds-with-one-stone. The structure of a wiki, and the programming principle of SPOT/DRY (don't repeat yourself) means that one big list of activities is the natural state of things. Yet the activity list is too long, and there are some activities in there which, for all kinds of different reasons, should not be in our public face. One solution: 1. one big list with everything, in sections, using templates to list each activity. 2. A field or fields in the template which say whether the activity should be generally advertised. 3. General guidelines of what fits (works, open source, no graphic violence or sex?) 4. A public-facing page which just includes the big list of everything 5. Mediawiki magic using functions and variables to hide inappropriate activities from the public-facing page. This is possible. It is a programming effort. I am volunteering to do one third of the work, that is, to share responsibility for getting this done if any other person or people claim they'll do 2/3ds or more. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Classroom tools
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
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
Classroom tools
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 http://wiki.laptop.org/go/User:Homunq 08:12, 14 January 2008 (EST) [edithttp://wiki.laptop.org/index.php?title=Software_ideasaction=editsection=16 ] 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?
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
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?
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: Status of Develop.activity?
- 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
Copy-on-write for develop
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: Sugar UI design and Tux Paint
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, which leaves check free as a
modifier
key to use as shift with the arrow buttons...
Re: Sugar UI design and Tux Paint
On Jan 2, 2008 2:17 PM, Eben Eliason [EMAIL PROTECTED] wrote:
selections: verb-object or object-verb
... discussion running on... the next step is example code... not gonna do
it next.
global preferences
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 responding to just ONE
extra event,
Re: Sugar UI design and Tux Paint
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... http://dev.laptop.org/ticket/1310 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 ideas there, of course. I think we can come to a good compromise between my issues (more across-activity-consistency and complete-access, including sugar) and yours (in-activity applicability and usability). One
Re: Sugar UI design and Tux Paint
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: Oprofile, swap
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: Status of Develop.activity?
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: Telling time (was: StopWatch activity)
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
Use-case for turning off display smoothing
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
Bityi (Develop i18n) happening on OLPC's git in idly-develop
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
