Re: startup question
>>> http://dev.laptop.org/git?p=journal-activity;a=blob;f=volumesmanager.py
>
>> adding
>>
>> if os.path.exists(device.GetProperty('volume.mount_point') + '.do_not_scan'):
>> return False
>>
>> to that method and putting a file named .do_not_scan in the devices
>> top level directory should prevent it from scanning it.
>
> Thank you. I did the above, and it worked.
I see now that not only did this remove the SD card icon from the
Journal view, it also removed the 'mount' itself (of the SD card).
Not a big deal - I can issue the 'mount' myself.
mikus
___
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?
Personally, I agree with just about everything John Gilmore said in
his Tue, 12 Feb 2008 13:59:49 -0800 message to Bert Freudenberg.
I frequently ftp materiel to my XO. Wanted to put one of these into
the datastore (Journal). Have picked up the .py scripts posted by
Phil Bordelon and Reinier Heeres. But when I tried to use the
'to-Journal' script, it asked me for the mime-type of the object
(which I did not know, and could not even guess) - so I gave up.
[Currently the OLPC fallback seems to be to have all accesses made
through 'Browse', then asking 'Browse' to store the item. Bypass
the intermediary ('Browse'), and you've got a whole mess of worms.]
What happened to me brought up visions in my mind of semi-literate
users being asked to fill out "Catalogue Cards" for materiel _given_
to them (Please supply: Title, Author, Date, Publisher, Edition,
Category, Index string, Country of Origin, Copyright, Keywords,
Pertinent remarks, Contact persons, etc., etc., etc., etc.).
mikus
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: startup question
>> http://dev.laptop.org/git?p=journal-activity;a=blob;f=volumesmanager.py
> adding
>
> if os.path.exists(device.GetProperty('volume.mount_point') + '.do_not_scan'):
> return False
>
> to that method and putting a file named .do_not_scan in the devices
> top level directory should prevent it from scanning it.
Thank you. I did the above, and it worked.
mikus
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
startup question
I'm used to "regular" Linux, where I can access files from a command without having to go through the Journal. I have an SD card in my XO, on which I keep files regarding setting up / customizing the XO. Apparently, the XO goes out and "scans" my SD card, so that it can show me the SD content if I were to click on the SD icon in the Journal view. Is there a way for me to __inhibit__ this scan of the SD card -- the scan takes time, and it is unlikely that I will ever want to access these SD directories/files through the Journal view ? mikus ___ 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?
I've concluded that the nature of the difficulty I ran into did not come across in what I wrote earlier to the list. I apologize. I was not commenting on the mechanics of ENTERING a mime-type when trying to store an object to the Journal. Rather, I was commenting on __me__ not knowing the list of mime-types (complete with an explanation of under what circumstances should which value be used). Being asked to "categorize" what I want to be stored can divert my mental focus. The answer for "how should *this* object be distinguished from other objects?" might not be associated with whatever I was doing before I decided to store this object. Encountering 'enter the mime-type', when __I__ do not have an answer at hand, can derail me completely from my previous lines of thought. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
telepathy - request for guidance
I'm an user with a G1G1, not a developer. I don't know telepathy. At home there is no wireless; wired connection is through a PROXY. Looking at the jabber_server packets the XO writes to my home LAN, they are IP-addressed directly to the server, not to the proxy. [The XO eventually decides its jabber_connection is timing out. It makes no difference which build (recent joyride) or rom (latest) I use, nor which jabber_server I try to reach on the internet.] I'm looking for guidance in how to specify to telepathy that its jabber_connection needs to go through my proxy. Tried putting the proxy address&port in /usr/share/telepathy/managers/gabble.manager, but .sugar/default/logs/telepathy-gabble.log shows the not-changed values as the ones still being used by /usr/libexec/telepathy-gabble Did not want to write up a ticket unless I can specifically identify something as broken. I am not asking anyone else to work on my problem, but would like guidance on what it might take to "proxify" the jabber_server connection. Thanks for any help, mikus p.s. I am able to satisfactorily reach the internet (through my wired proxy) with programs on the XO such as Opera and rsync. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: telepathy - request for guidance
Guillaume Desmottes wrote (regarding my wired connection + proxy):
> Gabble has https-proxy-{server,port} options that could do the job.
> Try to edit server_plugin.py in presence-service source code, look for
> the _get_account_info() method and add these 2 options (with the right
> values) in the returned dict.
Thank you, Guillaume - that has gotten me further.
I haven't looked at the packets flowing on my local LAN, but the
tail of my telepathy-gabber.log is now:
| ** (telepathy-gabble:2008): DEBUG: do_connect: calling
lm_connection_open
| Going to connect to proxy 192.168.1.1
| Trying 192.168.1.1 port 8080...
| ** (telepathy-gabble:2008): DEBUG:
tp_base_connection_change_status: was 429496
| 7295, now 1, for reason 1
| ** (telepathy-gabble:2008): DEBUG:
tp_base_connection_change_status: emitting s
| tatus-changed to 1, for reason 1
| ** (telepathy-gabble:2008): DEBUG:
gabble_roster_factory_iface_connecting: addi
| ng callbacks
| ** (telepathy-gabble:2008): DEBUG:
gabble_muc_factory_iface_connecting: adding
| callbacks
| ** (telepathy-gabble:2008): DEBUG:
gabble_media_factory_iface_connecting: addin
| g callbacks
| ** (telepathy-gabble:2008): DEBUG:
gabble_im_factory_iface_connecting: adding c
| allbacks
|
| ** ERROR **: file lm-connection.c: line 364
(_lm_connection_succeeded): asserti
| on failed: (source != NULL)
| aborting...
That to me implies I am now getting through my proxy. The last two
(ERROR) lines occur only when I have specified olpc.collabora.co.uk
as my jabber server - they don't show in the log when I try a local
jabber server.
With xochat.org specified as my jabber server, presenceservice.log :
| 1203387352.438895 DEBUG s-p-s.telepathy_plugin: : Starting up...
| 1203387353.037316 DEBUG s-p-s.telepathy_plugin: ::: IP4 address
now 192.168.1.6
| 1203387353.077116 DEBUG s-p-s.buddy: Successfully preloaded buddy
props
| 1203387353.082014 DEBUG s-p-s.telepathy_plugin: : connecting...
| 1203387353.084915 DEBUG s-p-s.telepathy_plugin: : Connect()
succeeded
| 1203387355.014069 DEBUG s-p-s.telepathy_plugin: : connected
| 1203387355.055661 DEBUG s-p-s.buddy: Setting current activity to
'' (handle 0)
Still have not seen *any* other XOs in my Neighborhood view.
mikus
p.s. [Other modules besides server_plugin.py have different
_get_account_info() methods -- I gather despite the common name,
each method's scope applies only within its containing module.]
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
where did cross-build customization come from ?
FYI -- don't intend to do anything about it -- just letting you know I had a strange experience. I keep both a Joyride build and an Update.1 build on my G1G1; I switch between them with the 'O' button at boot. Today I used 'olpc-update' (from Joyride) to install the latest Update.1, then used 'olpc-update' (from Update.1) to install the latest Joyride. I normally apply various customizations in /etc and in /usr (e.g., to disable frame "auto-raise", and to preset some environmental variables). The way I remember it, having booted this latest Joyride build I manually edited-in my changes. But then when I booted the latest Update.1 build, I found the /etc and /usr changes already made. It might be Alzheimer's that is making me forget applying my changes twice. But I am left with the question: "how come my edits showed up with both builds, when I remember making my edits only once ?" mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: telepathy - request for guidance
> Could be a loudmouth bug. Could you provide telepathy-gabble log with > LM_DEBUG=net defined please? I was already using that definition, and earlier posted the ending part of my telepathy-gabble.log. Just in case you need it, here is the beginning of that log (constant string deleted from each line): > started version 0.7.1 (telepathy-glib version 0.6.1) > set_param_from_value: account = "[EMAIL PROTECTED]" > set_param_from_value: password = > parse_parameters: server not given, using default behaviour > set_param_from_default: resource = "Telepathy" > set_param_from_default: priority = 0 = 0x0 > set_param_from_value: port = 5223 = 0x1467 > set_param_from_value: old-ssl = TRUE > set_param_from_default: require-encryption = FALSE > set_param_from_value: register = FALSE > set_param_from_default: low-bandwidth = FALSE > set_param_from_value: https-proxy-server = "192.168.1.1" > set_param_from_value: https-proxy-port = 8080 = 0x1f90 > set_param_from_value: fallback-conference-server = > "conference.olpc.collabora.co.uk" > parse_parameters: stun-server not given, using default behaviour > set_param_from_default: stun-port = 3478 = 0xd96 > set_param_from_value: ignore-ssl-errors = TRUE > parse_parameters: alias not given, using default behaviour > parse_parameters: mac not given, using default behaviour > parse_parameters: btid not given, using default behaviour > tp_base_connection_class_init: Initializing (TpBaseConnectionClass > *)0x80c81f8 > gabble_connection_class_init: Initializing (GabbleConnectionClass *)0x80c9120 > tp_presence_mixin_class_init: called. > tp_base_connection_init: Initializing (TpBaseConnection *)0x80cc020 > gabble_connection_init: Initializing (GabbleConnection *)0x80cc020 > tp_base_connection_constructor: Post-construction: (TpBaseConnection > *)0x80cc020 > tp_base_connection_constructor: Handle repo for type #0 at (nil) > tp_base_connection_constructor: Handle repo for type #1 at 0x80cab50 > tp_base_connection_constructor: Handle repo for type #2 at 0x80cab80 > tp_base_connection_constructor: Handle repo for type #3 at 0x80bec00 > tp_base_connection_constructor: Handle repo for type #4 at 0x80cabb0 > tp_base_connection_constructor: Channel factory #0 at 0x80cac30 > tp_base_connection_constructor: Channel factory #1 at 0x80c5418 > tp_base_connection_constructor: Channel factory #2 at 0x80ce408 > tp_base_connection_constructor: Channel factory #3 at 0x80bed40 > tp_base_connection_constructor: Channel factory #4 at 0x80bed80 > gabble_connection_constructor: Post-construction: (GabbleConnection > *)0x80cc020 > tp_presence_mixin_init: called. > tp_base_connection_register: bus name > org.freedesktop.Telepathy.Connection.gab > ble.jabber.ba81920cf9668efb7045c9f65ab5f875151e304d_40olpc_2ecollabora_2eco_2eu > k_2fTelepathy > tp_base_connection_register: object path > /org/freedesktop/Telepathy/Connection > /gabble/jabber/ba81920cf9668efb7045c9f65ab5f875151e304d_40olpc_2ecollabora_2eco > _2euk_2fTelepathy > olpc_buddy_info_set_properties: called > olpc_buddy_info_set_properties: Not connected: will perform OLPC buddy > propert > y update later Here (ACKs omitted) are the last packets on my LAN from an identical telepathy situation (this was run today on 693; telepathy log shows the same lines): > -- #:43 -- > Delta Time: 19.944sec Packet Length: 74 bytes (4A hex) > DIX: Dest: 00:90:27:8C:F4:49 Source: 00:10:60:16:9D:F6 > DIX: Dest: 192.168.001.001Source: 192.168.001.006 > -- TCP HEADER -- > TCP: Source Port: 53473 (Unassigned port) Dest Port: 8080 > (Unassigned port) > TCP: Sequence #: 1745295937 > TCP: Ack #: 0 > TCP: Offset: 40 bytes > TCP: Flags: 02 > TCP: ..0. Urgent bit Off > TCP: ...0 Ack bit Off > TCP: 0...Push bit Off > TCP: .0..Reset bit Off > TCP: ..1. Synchronize bit On > TCP: ...0Finish bit Off > TCP: Window: 5840 Checksum: 913B (Correct) > TCP: Option Code: 02 Length: 4 bytes [MSS] > TCP:Max Segment Size 1460 (x5B4) > TCP: Option Code: 04 Length: 2 bytes [] > TCP:Unknown option > TCP: Option Code: 08 Length: 10 bytes [TIMESTAMP] > TCP:TimeStamp Value 4294945253 (xA9E5) > TCP:TimeStamp Echo Reply 0 (x0) > TCP: Option Code: 01 Length: 1 bytes [NOP] > TCP:No Operation > TCP: Option Code: 03 Length: 3 bytes [WIN_SCALE] > TCP:Window scale factor 4 (x4) > TCP: No data or not output. > > -- #:44 -- > Delta Time: 0.000sec Packet Length: 62 bytes (3E hex) > DIX: Dest: 00:10:60:16:9D:F6 Source: 00:90:27:8C:F4:49 > DIX: Dest: 192.168.001.006Source: 192.168.001.001 > -- TCP HEADER -- > TCP: Source
physically feeble adults
I realize the intent of the OLPC project is to make "booting the system" as quick as possible. There is one situation for which introducing a deliberate __delay__ might be beneficial: It appears the XO is testing its front panel buttons as soon as it starts running. If an individual used his strongest finger to push the (recessed) 'power on' button, there does not seem to be enough time for that individual to transfer that same finger to one of the other front panel buttons. Those other buttons are small; if the individual does not have enough dexterity in his other fingers, the "which buttons were pressed" indication as picked up by the XO may be different from what the individual wanted to convey. Let me suggest the XO pause a half second following a 'power on', to allow a feeble user time to re-position his fingers (from the task of turning on the XO, to the task of indicating "what is special about this boot"). mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
suspend vs. SD card
I don't yet know how repeatable this is. I have an SD card inserted into my G1G1. On that SD card I keep "persistent" files, including some bash scripts. In my .bashrc I add this SD-card-directory to the PATH. Was demonstrating the XO (693) to an acquaintance, and physically configured it into e-book mode (screen flat). When I unfolded the XO (screen perpendicular), it was suspended (screen dim). In using Terminal afterward, the response given when I entered an SD-card bash_script_name was 'unknown command'. It appeared to me that the 'resume' following the suspension had re-interrogated the SD card (was power to it turned off by suspend?) and had somehow "mixed up" access to it. My recovery was to reboot. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
perceiving connectivity
Have G1G1. Today for the first time was in a room with multiple XO users. The chief thing that was __NOT__ evident to me from moment-to-moment was: "What is connected to what"? I do not claim to understand the big picture. [I completely agree with the 'danw' comment to Ticket #1385.] To me, there appear to be three populations my XO might be connected to: 1) Connected to LOCAL radios (XOs ?) -- presumably using 'mesh'. We all agreed to "connect" using channel 11 - and it appeared to work. I am willing to go to the 'Neighborhood' view, and hover over the circle icons there, to determine __if__ I am connected to other XOs. PLEASE do away with the current "rapid blinking" behavior of the (*) indicator. If you want to associate (*) with "mesh", let 'on' mean "there is a LOCAL system I can communicate with" (and 'off' mean there currently isn't any). [See below for alternate possible assignment of bezel lights.] 2) Connected to the school SERVER (or perhaps the jabber server). While in the room, we did not manage to "chat" to users on the jabber server. [To me, the wiki is unclear -- can one have a jabber server in *addition* to a school server ?] We concluded the existence of the "mesh" connection was interfering with the "jabber" connection. [Chat did not indicate whether it had opened for mesh connectivity, or for jabber connectivity.] Let the (!) indicator being 'on' mean "there is someplace I can transfer data from my Journal to" (and 'off' mean there currently isn't any). Let me suggest that if there is a "mesh" (direct) connection to the __SERVER__, that such a connection *not* affect (i.e., turn 'on') the LOCAL indicator. 3) Connected to the global INTERNET. There are only two lights on the front bezel of the XO. My connection from the room to the establishment's access point happened to drop out, and I did NOT notice in the 'Neighborhood' view that the rim of the circle had changed from white to black. At least in the developed world, there is a NEED to indicate when an existing connection to the INTERNET (perhaps to a "standard" site such as Google) has failed. I don't know how to show this if no dedicated light - perhaps a control setting that permits slow blinking of an existing connection indicator. Alternatively, use of a bezel light for the existence of LOCAL connectivity could be dispensed with. Instead, use one light for SERVER connectivity, and one for INTERNET connectivity. My thoughts regarding the existing writeup of the two lights: Will a child behave differently when a connection attempt does not succeed than when there is no connection at all? If yes, whether to show attempts (e.g., by rapid blinking) can be a control setting. The (*) indicator was meant to show "use" of the "mesh". If it is important to the child to see that data transfer is taking place, whichever data path <(*) or (!)> is being used can be blinked once a second. Absence of medium rate blinking would alert the child that, though the connection was there, data transport was not occurring. The writeup describes that if an XO is connected to an access point, and is serving as the "internet portal" for the mesh, BOTH indicators should be lit (is this meant as a warning to the child to not power-off his XO ?}. I don't think both indicators 'on' should be used as a warning. Perhaps a __special__ icon in 'Neighborhood', plus telling the child using internet to always visit 'Neighborhood' before turning off the XO. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
storing Activity parameters
There has been discussion of the use of the Journal, versus other places, to store information associated with an Activity. What I've noticed is that some Activities are now storing their parameters in the Journal. For instance, I prefer to change the shape of the eyes in 'Speak'. If I launch 'Speak' from the menu frame, it shows the "default" eye shape. If I launch 'Speak' from the Journal, it shows the eye shape I specified earlier. Personally, I would prefer having Activities store user-specified overrides someplace other than in the Journal. Then when a new 'instance' of the Activity gets invoked, it can come up looking the way the user likes it, not just with its "built-in" appearance. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Why is Terminal 'extra' ?
Was not aware of the implications of "the official builds from now on will contain only _base_ Activities" (discussed in Ticket #6598), until I saw a recent post to the Sugar list. I happen to be a heavy CLI user. It appears the target countries for OLPC deployment have not insisted on CLI - hence Terminal is being omitted from the _base_ software distribution. I'm presuming not all users in the field will have a connection whereby to download 'extra' Activities omitted from the _base_. That leaves the text console as the "approved" OLPC CLI interface. Admittedly Terminal can be used to delete/alter things that should be left alone. But to me personally, it is easier to use than the text console. Do the benefits of initially leaving Terminal out of the _base_ distribution outweigh having to subsequently install it for those who wish to use it ? mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
How can I prevent 'suspend' ?
No wireless; instead an USB-ethernet adapter. Whenever the XO suspends, it drops power on the USB. Then, when it resumes, it connects eth0 to the radio instead of to the ethernet. To avoid the XO disconnecting, I've done 'touch /etc/ohm/inhibit-suspend' Was looking at the "local library" with Browse. Clicked on something that invoked 'Read'. When the 'Read' Activity had started up, the XO went into suspend (power light blinking, USB power off) __despite__ the /etc/ohm/inhibit-suspend file still being there. How do I prevent 'Read' (or whatever) from letting my XO 'suspend' ? mikus p.s. I believe I've also seen an unwanted 'suspend' when I temporarily closed the lid (despite the inhibit-suspend file). ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Why is Terminal 'extra' ?
> Terminal, Log Viewer, and Analyze are not included in the core build, > but they *are* included in the core *library*. That is, you can > always install them, even though they may not show up by default in > the toolbar. I did not realize that - your answer settles my concern (i.e., that a user "under a tree" ought to be able to install Terminal if it was not "included" in the build). But it would be nice if the documentation were clearer. The wiki mentions "library" many times, but most of those references are to libraries out in cyberspace, or at the school. There is info about the Activities resident in the XO; there ought to be more info about the Library resident in the XO. [Because I originally had problems with Browse, had not explored its sidebar capabilities.] mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
User's customizations
Regarding what is in the build "core", Scott said > The "core" activities are just those which we insist all countries > include on the left hand side of the (current) activity bar. Then there are those individuals who prefer to organize things their way. The second thing I've changed on my XO is which activities get shown on the left hand side of the current activity bar. [The first thing I changed on my XO was to get rid of the "frame auto-raise".] mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
I/O scheduling (pdflush) on the XO
For the fun of it, started a resource-intensive task (100% CPU,
sporadic floods of disk writes) on my G1G1 XO. Eventually, it
failed with a "severe (38)" fortran error trying to write its
checkpoint file {mikus note: many quick small write operations}.
That situation may be a pathological one -- but what I found
interesting was that in again doing something similar (different
worktask), 'top' showed 'pdflush' requiring lots of CPU (up to
52%!!). [And 'jffs2_gcd_mtd0' keeps showing up on 'top', too.]
I take it that my XO is *struggling* when presented with heavy
"disk I/O".
mikus
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: I/O scheduling (pdflush) on the XO
>> For the fun of it, started a resource-intensive task (100% CPU,
>> sporadic floods of disk writes) on my G1G1 XO. Eventually, it
>> failed with a "severe (38)" fortran error trying to write its
>> checkpoint file {mikus note: many quick small write operations}.
>
> Why? This device has a 433 MHz 32-bit processor, 256 MB of RAM and
> a 1 GB jffs2 flash disk. What do you expect?
I did not know what to expect -- perhaps that it would run slowly,
but that it _would_ run. What I posted was a report of my
experience. [I do expect that sooner or later some other XO owner
will try to run a resource-intensive task on it.]
>> ... 'top' showed 'pdflush' requiring lots of CPU ...
>
> Again, where's the surprise here? An XO is *not* a scientific
> workstation! It's a computer for elementary school students!
To me it *was* a surprise to find at times 'pdflush' using more than
half of the CPU power of my XO. I thought this was worth reporting.
mikus
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: Opening Browse programatically
>> I want to make a button in my activity that opens a particular URL >> with Browse. > As Marco said, we cannot do this currently. An observation (this is NOT any kind of request for action): Traditionally, computers have had a "console stack" (usually LIFO). Software could "push" a text string to it, then request that it be "popped" by the command interpreter, as a means to start a program. In my XO I can in Terminal type in 'opera URL' (without the quotes, and specifying the URL), and the Opera activity will launch. Seems to me whatever mechanism works for launching from Terminal, ought to be adaptable to launching from Joshua's activity. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Why is Terminal 'extra' ?
Installed 698 (using 'olpc-update' from Joyride). There was __no__ Terminal activity anywhere (that I could find) in the newly installed 698 image. I happen to *require* using the command line to set my environment. After boot, had to use a console terminal just to see what was what. [There was the "footprint" of Terminal in Journal, from the last time Terminal had run. But it could not be "restarted", since it no longer existed. (Betcha you'll get help requests about this.)] Found it simplest to reboot Joyride (which was already set up for my environment), in order to download Terminal and install it in /home/olpc/Activities. If there are users in Peru with requirements like mine, will they have to go through hoops (to get Terminal) like I did ? mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
698 - 'su' does not pick up customized environmental variables
I need to set some environmental variables (e.g., http_proxy) because I have a wired connection which goes through a proxy. It used to be that issuing 'su' put me into root, but kept the environmental variables set by /etc/bashrc for user 'olpc'. With 698, 'su' gives me environmental variables *without* my customizations. [The (alt-ctl-F1) text console correctly gives me the customizations set by /etc/profile.] When I issue 'su -l', that gives me the customizations set by /etc/profile. How come a plain 'su' now sets up its own environmental variables, _bypassing_ both /etc/bashrc and /etc/profile, when previously it would pick up the environmental variables of the user it was issued from ? mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
/usr/share/activities content
Installed 699 (by running olpc-update from Joyride). Noticed that the only Activity now in /usr/share/activities is Journal. I understand that you want to allow the target countries to choose which Activities will be pre-installed on their laptops. But if you are going to empty /usr/share/activities of Activity data, let me suggest you also empty it of *other* non-essential data. For instance, the 'music' subdirectory there contains 7 MB bytes in 699 - yet there may be countries which do not wish to pre-install 'music'. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
699 responsiveness
Don't know if this is reproducible or not. Am in the process of customizing 699. After I installed the Adobe flash player, there was an appreciable lag in the system's response to my CLI commands. Looked with 'top', and found 'gtk-gnash' was using up to 70% of my CPU cycles. Killed 'gtk-gnash' and my system is back to normal. mikus (G1G1) p.s. Needed to earlier manually install Browse (now put into /home/olpc/Activities). That means that if there were two users defined for my XO, *each* would have his own copy of Web.activity. Much preferred it in /usr/share/activities. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New update.1 build 699
Chris answered: >> what does inhibit-idle-suspend do? > > It allows you to disable automatic idle suspend while keeping enabled > the explicit suspend on power button press or lid close. Previously, > there was only the inhibit-suspend file that inhibits both of the above. I no longer have 699 on my G1G1, so I can't test that. But on 700 (with q2d14), despite me having the inhibit-suspend file in my /etc/ohm directory, the XO __does__ suspend as soon as I close the lid. [I *don't* want that, because on an inadvertent lid closure it drops power on my USB-ethernet adapter (with the result that my wired connection does NOT get re-established when I open the lid).] mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
1789 - sugar does not boot
Once upon a time my OLPC laptop (G1G1) was reliable. No longer. I've been dual-booting it, by installing a recent Joyride build plus a recent Update.1 build. But the most recent Joyride builds do not boot for me: The symptom seen most often is that the circle of dots gets drawn, then the doughnut gets drawn, and then the system just sits there (it will NOT accept any input from the keyboard). If before booting I uncomment things in .xsession (for instance, the 'exec xterm' line), a blank screen gets drawn instead of the doughnut. After a bit, the blank screen disappears (reverts to the ctl-alt-F3 console) then is drawn again. [This sequence cycles over and over, forever.] Nothing helpful gets output to the console, nor to /var/log. I've now gone backwards with Joyride, and reinstalled build 1784. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
UI responsiveness
> ... Performance, or for us, UI responsiveness, the most visible > and painful issue being start up time of applications is paramount. I'm impressed by the start up time of the (giant) TuxPaint activity. From the time I click on its icon in the Frame, it takes about two seconds to draw the initial view. Then a tune is played, and the screen is populated with tool icons (and the latest drawing). In less than 15 seconds *everything* has been initialized - but the user has not perceived that wait, since things kept happening. This is on Joyride -- shows what can be done *today*. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Mini-Conference Proposal: removable activities
This is probably too complex to implement soon. But please keep the *idea* in mind as you improve the OLPC laptop. Once the 'base system' has been installed, things that are typically added over time are data and executables. Sooner or later, the built-in "disk space" might run out. There is a design for off-loading excess data to the school server. It would be an useful "expansion capability" to be able to access added executables that are somewhere other than on the built-in "disk". [When there are 400 activities available, I'd probably want to try most of them.] Currently, activities reside in /home/olpc/Activities. What I am thinking of is an equivalent to the 'mount/umount' process - it would ADD a table of the activities in the designated directory to the path used to access XO activities. [My idea is that if the contents of this added directory were to change, it would have to be re-accessed in order to pick up those changes.] For security reasons, to be recognized the activities in this additional directory ought to be signed. "Temporary space" used by an added activity would be allocated from within this same directory (i.e., device). If the added directory/device were removed unexpectedly, I'd let the associated activities fail; a sugar restart should clean any "garbage" they left. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
mock.laptop.org server down
For Update.1 build 702, the yum configuration files now point to mock.laptop.org as the server. But that server is currently not responding. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Update.2 goal - game buttton orientation and rotate
I have not been following the current status of "game button" support, but on the original G1G1 release the existing button definitions stayed in place when the display output was rotated. Consensus had been deferred on which keys (and trackpad) should change orientation when the display output orientation changes. [See #5549, #2249. #1444, #808] It would make the XO more user-friendly if when Update.2 is released, there is an easy-for-users-to-understand definition of how the buttons behave when the display output is rotated -- PLUS, for Update.2, Sugar and the Activities need to *follow* that definition. ["Waiting for X.future" should be a last resort, since in the meanwhile hand-held-mode users are left with an awkward XO.] "Clearing up" game buttons should be a priority for Update.2 mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: update.1 "breaking" wrapped activities?
> in a description of how non-sugar apps need some help to run > properly under sugar, the current front page of OLPC News > contains the following quote: > > "... there is some discussion that Update 1, a forthcoming > upgrade to Sugar, will break all existing wrappers, and > current Activities will need to be re-coded and re-wrapped." I assumed that what's behind this is the introduction of rainbow. [I'm not sure of the date of the transition to rainbow, but perhaps G1G1 participants might be exposed to it when installing Update.1] I myself have had to go into activityfactory.py and add the classes of several Activities (to those rainbow skips), in order to be able to launch these Activities from the Frame. The explanation I received when asking was that these Activities *stored* into locations to which the UID-renaming by rainbow denied access. Obviously, to be compatible with OLPC security, such Activities would need to be re-coded to write to approved locations. [I think "break all existing wrappers" is an exaggeration - but a number of these mis-behaving activities *are* "imported" software.] mikus p.s. It is amusing to observe that the XO will insert a "no name" circular icon in the active-Activity-circle in Main view, when the executing Activity starts a second task. Perhaps users who first encounter such a "no name" circle are thinking "something's broken". ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] new sugar work into joyride
Tomeu wrote > the last joyride build (1825) includes a big part of the shell > redesign explained in http://wiki.laptop.org/go/Designs. I'm running Joyride 1825 now on my G1G1. The principal difference I've noted is in my use of the Home view - now that the currently running activities are depicted in the Frame, I no longer need to press F3 when I want to return to a running Activity by clicking on its icon. There is a "learning curve" involved with the revised Home view (F3). It took me a while to realize that NOTHING appears in the "circle view of launchable Activities" until I have gone into the "list" view and marked the star on each desired Activity. And then it took a while more to realize that if I clicked within the Home view (as opposed to on the Frame) on the icon of an already-running Activity, a NEW INSTANCE of that Activity would be launched. [The small icon (in the graphic F3) for "most recent Activity" is the only icon within the Home view that provides a 'Resume' option.] In the "list" view of available Activities, I can't press PgUp PgDn to scroll - to view the whole list, I have to laboriously click (or drag) the scrollbar. Also, in that list I can only click on the icon to launch that Activity -- it would require less "positioning" if I were able to select a whole line and click anywhere within it. [I dual-boot between Joyride and Update.1. It amuses me that the "list of launchable Activities" includes both those installed by Joyride (in /usr/share) and those I manually installed for Update.1 (in /home/olpc). If the same Activity is installed both places, seems like I get to choose which version to launch.] mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Choosing "defaults" for the activity ring
Removing icons from the activity ring is just a matter of "unstarring" them in the list view - simple enough to do each semester. My vote is Option 1. A much more interesting question is the __order__ in which to show the Activities: List view: Since there appears to be an intent to make the list searchable, there might be no need for alphabetization. What I think useful is to distinguish "newly arrived" Activities. My suggestion - as an Activity is "installed for the first time" (not "replaced"), insert its entry at the TOP of the list view. The 1825 list view appears "all mixed up". Being a control freak, I would like to organize it myself. An ability to drag-n-drop the entries within the list would be handy. Ring view: One question - should it be easy for BB to sit down at AA's laptop? [This implies that 'Chat' (for example) should be at two o'clock on everyone's XO.] My opinion is to let every user put 'Chat' wherever he wants. But do let the user be able to control the order in which the icons are presented (this is an artifact now provided by the 650 file 'activities.defaults'). mikus p.s. The "drop-down menu" from an icon can obscure the adjacent icon (should the user merely want to view the label of the current icon). Let me suggest positioning such a menu outside the circle. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
UI for "working on it"
The recent talk on Sugar about notifications reminds me that the OLPC currently appears to lack easy-to-check "I'm working on that" feedback to the user. Combined with Sugar's "a single screen for whatever one is doing" philosophy, this serves to HIDE "what is going on" from the user. I had originally thought "as long as information is shown somewhere, that's good enough" -- let the user come looking. But seeing how much I myself resent interruptions to what I am involved in, status ought to be available "where the user is looking", and notification ought not to impose non-deferrable "taking the user away from his current task". [I hate it if I'm typing something, and the Frame pops up and obscures where I was working.] Two recent 1825 experiences have raised my sensitivity to "how to know what is/is_not going on": (1) I clicked (in Home "list" mode) on a rarely-used icon. Nothing seemed to happen. Losing patience, I navigated to a Terminal activity I had previously opened, and was about to type in something when the XO screen changed over to the newly-launched activity. [From the information available "where I was looking", I thought the XO was not "working on it" (was not launching the new activity).] [On Linux (and Windows), once the user has clicked on something, the cursor changes (e.g., includes a bouncing ball). As long as the cursor change persists, the user can feel "I don't need to do anything more RIGHT NOW about what I clicked on". Normally, the requested action will start (accompanied by a visual indication). Else, when the cursor reverts to its non-changed form, the user knows that he should investigate the possibility that the requested action never started.] On 1825 the only place that shows "activity being launched" is an obscure corner of the Frame -- and I had gotten rid of the Frame to be able to switch Home view into "list" mode. [I'm sorry, but to me the Frame is too intrusive so far to be useful as a "current status" display -- I only use it when I want to perform some "action".] For me, showing "loading is going on" by in a corner blinking a dark icon on a dark background is much too easily overlooked. At least, both Home view modes need to give a *positive* indication at the clicked-on icon that "your click-request was accepted". [Perhaps have the background of the icon be "highlighted" until "launching" completes.] [All "to be noticed" areas of the Frame should have a WHITE (or at the least, a contrasting) background.] (2) I had attempted to connect to an AP, by clicking on its icon in the Neighborhood view. I got bored after several minutes waiting for that icon in the Neighborhood view to stop blinking, and went back to working within activities. I don't know what the ultimate result was of me having done that click in Neighborhood view. [From the information available "where I was looking", I believed the XO had kept on "working on it" (was still trying to connect).] I think the XO ought to have notified me, either when it decided it had accomplished that connection, or when it decided it could *not* make that connection. Elsewhere (#1385) I've proposed that the two LEDs on the XO front show "peer connection" status and "data server connection" status. It's a pity that there are not three LEDs - "AP connection" status also deserves a "front LED" (visible all the time, which the Frame is not). [If important information changes status on the Frame (or on a different screen than what the user is currently looking at), let me suggest "blinking" (i.e., one-time dimming and brightening) the current screen. Then, when he is ready to be interrupted from what he was doing, the user can go off to view whatever that status change was.] mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Clipboard Notification
> When an activity launches it brings up an instance of the notification icon > in the activity tray. I'm trying to make it so when someone copies something > instead of it popping up the frame for a second it shows a pulsing > notification icon in the top left hand corner. Personal note: Been running the "new look" Sugar/Joyride for a while. [It does what you describe when an Activity is launched.] I've now trained myself to notice the pulsing icon in the top left hand corner -- but I think that is an easily-overlooked location (particularly since current notification icons have the same background color as the "border" in which they sit). I am a believer in "show notifications where the user is looking, not off in a corner somewhere": When an asynchronous notification occurs, the user should NOT be "taken away" from what he is doing. Absent a "bell", the simplest "alert" I can think of is to "flash" the screen once (change its brightness for half a second, then go back to the way it was). That tells the user: "a notification has occurred". [It is up to the user, at his convenience, to look for the actual notification.] When a _synchronous_ notification occurs (i.e., 'feedback' to confirm the user's action), such as when an activity is launched, I would like that feedback (unless it takes more than five seconds) to occur right where the user performed the action (e.g., where the cursor was). [If there is a notification associated with *putting* something where the Frame would show it, "pulse" (or temporarily distinguish) whatever is being put. If the user wants to *verify* that the thing is sitting where it was put, *then* let him call up the Frame.] mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
fun and games with trying to un-suspend
G1G1, approximately Joyride 1858. No wireless. Have done 'touch /etc/ohm/inhibit-idle-suspend' When I pushed the "power" button briefly, the XO suspended. Wanted to "un-suspend" the XO. But no matter what I pushed on the keyboard (or front), the "power" LED lighted up briefly (about three seconds), then went back to indicating 'suspended' (i.e., blinking slowly). The display stayed dark. Finally was able to get the display to light up (and the XO to come back to life) by judicious pressing of the "power" button. It was hit or miss (with more than 95% "miss"). Press it too short - back to suspended; press it too long - back to suspended; press it at the wrong instant - back to suspended. Took what seemed a minute (from awakening) for the XO to recognize my (external) USB keyboard again. The whole experience was a bummer. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: fun and games with trying to un-suspend
> The issue seems a lot more often / prevalent > when I had an SD card inserted before suspending. Bingo! I have a permanent SD card which I (manually) use for my "datastore" (I'm not a Journal lover). I wrote up #6584 because I'd as soon have the OLPC software KEEP ITS HANDS OFF my SD. [I'd be perfectly happy to do the 'mount' myself.] http://lists.laptop.org/pipermail/devel/2008-February/010870.html suggested a way for me to prevent scanning of my SD (presumably including when coming out of suspend). At that point in time, I made the changes to volumesmanager.py, and it worked as I wanted. Unfortunately, as I kept updating to more recent OLPC software versions, this "patch" stopped working. As far as I can tell, I was applying the same code instructions as before - so the resumption of scanning (despite my "patch") might have been due to OLPC software changes elsewhere. Though I would want to *inhibit* the XO from scanning my SD, I don't currently know how to do that. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
purpose of ticket
Recently there was a post to this list which I read as saying "if you see internal-to-XO situation XYZ, write a ticket and enclose log". [I leapt to the assumption that XYZ "ought not to occur".] Well, I saw situation XYZ, and wrote a ticket. But that ticket has been closed. The impression I was left with was "we already know that external-to-XO situation UVW can cause the internal-to-XO XYZ". It now appears to me that the reason for asking XYZ to be logged was to "triage" situation XYZ - in case as-yet-unknown causes led to it. I wish that when the only ticket_mechanism result is "information gathering" (e.g., from logs), another _resolution_ than 'invalid' were used for closing such a submitted ticket. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
TP interface assignment keeps changing
I don't have wireless. My XO is connected through an USB-ethernet adapter. Way back when, this wired interface was always being assigned to eth0. From time to time I install a newer Joyride build. More than a week ago (1852 ?) the wired interface was being assigned to eth1 instead. Then (1871 ?) it was back to eth0. Now (1894) it is eth1 again. Why is my wired_interface_assignment different from build to build ? mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Joyride
I'm running Joyride 1894, manually updated to 1896 level. My installed sugar-presence-service is 0.79.3-1.olpc2 [Had a bit of trouble with 'telepathy-plugin.py' -- changed some single quotes to double quotes.] Write (and all other Activities I've tried) work for me. mikus (G1G1) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Journal Suggestions
> The SD card > is deliberately made difficult to remove. If someone buys and installs > an SD card perhaps it should be considered a part of the Journal > itself. More like buying a second hard drive for your system than > plugging in something removeable. So now I have just one Journal with > 2.5 gigs free instead of 500 megs free. That's the way I was hoping to > use the SD card when I got it. I have a significant problem with the speed of the OLPC. Even on NAND, if I (manually, in Terminal) copy a 5 MB file from one place to another, it takes seconds and seconds (as opposed to a desktop, where such a transfer happens in the blink of an eye). I have not tried any measurements, but my concern is that with an external device (*particularly* an SD card), access is even slower than with NAND. [And SD cards come in several speed ranges - the cheapest are usually the slowest). Empirically, I haven't noticed 'olpc-update' being significantly faster from an USB stick than over the internet. What raises my concern about treating an SD card as an extension of the Journal is - how fast will the XO be once there are a great many items for it to keep track of? I don't use 'suspend'; but the few times I've tried it - typically when attempting 'resume', my "Power" light stays on for more than three seconds, then goes back to blinking (in other words, the "un-suspend" times out). I suspect some of those seconds are being spent accessing the 100 or so files on my SD card. [Would be nice if the OLPC had a 'Storage Device Busy' light for me to look at.] What will be the performance of the OLPC (including: how long will it take to boot?) when I have several thousand files on my SD card? mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Gamepad and Rocker Images?
Eben writes: > We're actually going to be putting some more > effort behind handheld mode in the relatively near future From my point of view, better button support is an ESSENTIAL part of making the OLPC easier to use than it has been. One intent for the OLPC is "to replace textbooks". Good "human factors" facilities ought to be provided for manipulating the displayed information when the OLPC is configured in handheld mode. Judging by the number of comments I have read, the 65x builds did not achieve that. The goal should be to have the same button do the same thing, no matter which Application is displaying the information. (Plus rotate the button functions when the screen content is rotated.) [I'm willing to have games be an exception to how buttons are used for "information" viewing.] mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Rainbow 0.7.12 Announcement
> in order to solicit more widespread testing Installed it manually (yum) on my G1G1. 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. Activities I tried for which even the new Rainbow shows error exceptions were 'TuxPaint' and 'KuKu'. mikus p.s. [I had already increased the values in the 'rainbow' script.] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Rainbow 0.7.12 Announcement
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
Re: Rainbow 0.7.12 Announcement
To follow on (regarding Sonata and Opera) : Noticed that whereas the without-Rainbow Activities had their files located in /home/olpc/.something, with-Rainbow-0.7.12 those files were apparently assigned as /root/.something That would explain why these Activities did not find their previous configurations. [Had to go in and manually clean out /root after excluding these Activities from the scope of the Rainbow-0.7.12 affect.] I had started these Activities by clicking on their respective icons in the F3 "Activity Ring". Even though I invoked F3 at a time when I had been (F4) in Terminal running as root, I would have expected these Activities to have been launched with HOME=/home/olpc. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: very simple datastore reimplementation
> Opnions? ( we get an useful replacement that lacks ... )
> - Support for mounting removable datastores. We have agreed on moving
> to just list the files in removable devices, without the DS having
> anything to do.
I heartily agree with the need for simplification here. Please keep
in mind that a removable device might have THOUSANDS of files on it.
It appears that a major problem with removable devices is "What if
the device changed status while the XO was suspended?" It defeats
the purpose of 'resume in milliseconds' to go out and check the
content of removable devices during 'resume'.
Let me suggest a two-tier 'explore-the-system' (i.e., on resume).
The first tier brings the XO back to the state it was in when it was
suspended. If some operation cannot now be completed (because the
device no longer responds), I would like to see an option presented
to the user (abort vs. retry). The "retry" choice would kick off
the second tier, in which the XO re-establishes the status of all
devices. Depending on what it found, the XO would allow the "retry",
or would again ask the user (thus allowing the user time to plug the
device back in).
> - Filtering by arbitrary metadata properties. If only the journal is
> allowed to execute find() calls, then we can restrict the properties
> that need to be stored in the index, gaining disk space and speed when
> searching. Do we really need this functionality?
When I first read a description of the Journal, I mentally
familiarized myself with the concept ("instead of locating objects
by means of their position in an access hierarchy, locate what you
are looking for by employing 'filters' operating upon metadata
associated with the objects"). So far, so good.
But then I tried actually using the Journal. Perhaps because I am
not a kid, I find its current characteristics more or less unusable.
For instance, order -- my memory is now so weak that I can't
remember why I started Terminal last Monday, nor why I saw a need to
start it again last Tuesday. [And it bugs me that there is no
simple 'touch' to reset the date of a Journal entry.]
Further, since most of the objects I access are on removable
devices, they have been placed there by software other than OLPC
activities -- meaning they DO NOT HAVE the metadata that would make
Journal 'filters' efficient. [The principal facility that I can
think of that would help me would be "full text search".]
<< This brings up a philosophical point. It can be important to a
kid to __describe__ what he was doing (by filling in the 'Title'
field in the Activity, and perhaps by adding tags to the Journal
entry) -- this allows him to later *extract* that same Activity from
all the things in the Journal. But I myself *resent* having to take
my attention away from what I am focused on, just to "fill in" a
description to assist subsequent retrievals -- so I don't bother. >>
Also, in using Google I often "narrow down" my search by iterating
'search within results' operations. I have not yet learned how to
"string together" the Journal 'filters', to achieve the same result.
In summary, I am concerned that by disallowing filtering (when using
Journal) by arbitrary metadata properties, you will take away the
freedom of __kids__ to explore/create "virtual database schemes".
I think 'flexibility' for the user is worth the performance penalty.
mikus
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: An OLPC Development Model
> It also needs to be decided how the available activities are > displayed. Initially we'd planned on simply launching Browse and > pointing to a predetermined URL (an "easy" way out, but requires > setting up the server side). That requires including Browse as part > of the base image. Another option is to use an extension of Bert's > script to fetch (potentially from a number of locations, if > necessary), a list of activities and format a list with nice icons, > titles, and short descriptions presented as a modal dialog From the viewpoint of a G1G1 user who likes to "keep up with the Joneses", I am perfectly happy to fetch individual activities with 'wget' and to install them with 'sugar-install-bundle'. My biggest problem is simply *knowing* that updated Activities are available. I believe TWO sets of Activities need to be made available to users who are not schoolkids linked to a school server. One set I'll call 'stable Activities' - they are packaged in "Activity Packs" such as the ones for Peru or for G1G1. Users need a documented way to install these. If the build they have put on their OLPC does not provide Browse, they need a way to access an "Activity Pack". I will use 'development Activities' to describe the second set -- they represent the most recent versions built by their authors. Currently these are scattered on mock.laptop.org and dev.laptop.org and wiki.laptop.org (and others). I would prefer there to be a SINGLE repository containing the very latest level of each Activity -- barring that, there should exist an "official" list which gives the location from where the latest version of each individual Activity can be fetched. [The existing http://wiki.laptop.org/go/Activities webpage lists a number of not-the-latest-version bundles. It is not suitable for a catalog of what I'm calling 'development Activities', unless more care is given to updating it as authors come up with new versions.] mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: An OLPC Development Model
> *But* I also think it should be possible to run a Sugar activity on a
> standard desktop and a desktop application in the Sugar shell. Integration is
> great and we should encourage it, but we can't assume it will always happen.
> And in the cases it doesn't happen, not-integrated is better than nothing.
Frankly, I don't see a logic difference between Negroponte talking
about extending the OLPC hardware to Windows (presumably to increase
recognition of the OLPC), and those talking about extending Sugar
to a standard desktop (presumably to increase recognition of Sugar).
I'm under the impression that the Sugar shell was specifically
designed to be EASY TO LEARN for people lacking Western education.
Yes, there are many who desire to run desktop applications (without
having to re-program them) in the Sugar shell. But *already* there
have been successful efforts at 'sugarizing' certain applications
('opera' comes to mind). From my perspective, what is needed is an
__excellent__ "thunk" layer to wrap around desktop applications.
Developers -- don't agonize -- go do it !! [The most intractable
problem seems to be Bitfrost - the security model for Sugar is NOT
the same as the security model for current desktop applications --
something has to give (or be re-programmed).]
But I don't see a pressing need to run individual Sugar activities
(without the Sugar shell) in another environment. [Would it really
increase the world's recognition of Sugar?] [The Sugar environment
is "pared down" -- why should for example users of non-Sugar
environments be asked to install applications which can draw just a
single small screen ?] If there *is* a market, again availability
of a "thunk" layer might provide the most wide-spread benefit.
I *do* see a two-fold use for porting the Sugar shell to various
distributions: (1) People without a Western education, who have
access only to a "standard desktop", ought to find the Sugar shell
(together with a set of Activities that runs under it) easier to
learn. (2) By exposing more people to Sugar (including making
development resources available), hopefully the pool of contributors
to "providing computerized help/information to those who previously
could not afford it" will grow.
My $.02 mikus
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: [sugar] jumpy cursor problem and sugar issue
It might not be purely a touchpad issue. Once in a while I've seen the cursor jump to a corner -- this is while I'm using an USB trackball, not the XO touchpad. mikus p.s. When using the XO touchpad, a sure way to get erratic cursor behavior is contacting its surface with two fingers (instead of one). ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] OLPC priorities for Sugar in the August release
> * 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. Is that satisfactory ? mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] OLPC priorities for Sugar in the August release
> If you could download the latest joyride, time startup and open a > ticket that would be useful. 25 seconds are too much obviously. I took the time on Joyride 1932, which had been manually updated (via yum install) with cups-libs 1:1.2.12-11.fc7 and telepathy-glib 0.7.8-1.olpc2, to bring it up to equivalence with Joyride 1938 (and following). I __doubt__ that downloading the latest joyride would make any difference. Why should I open up a ticket? I don't have my G1G1 instrumented, to *prove* how many seconds it took. I was not the one who said "too much". > Please take both time on the very first start and after a reboot, I don't understand how a "very first start" differs from a "reboot". I get 25 seconds when clicking on the Browse icon is the first thing I do after a reboot. It currently is difficult for me to restart Browse after having closed it - Rainbow won't let me (ticket #6989). Just to check that 'faster' is no better, I installed faster 1944. On my G1G1, it too takes the same 25 seconds to bring up Browse. mikus ___ 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 There are .pyc files here and there in the XO core software. I do not expect to myself be changing Activity code -- but if the OLPC is supposed to be "easy enough for a kid to program" - *someone* will. For myself, I don't have wireless at home; to make my communications setup work properly I need to "patch" some "telepathy/presence" .py files. [Having changed a .py file, I delete the same-name .pyc file, and reboot.] I'm not sure what created those corresponding .pyc files. I __wish__ there was an easy-to-find GUIDE explaining how and when the various .pyc files were installed. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New joyride build 1970
Joyride 1970 has the OLD 'Frame', instead of the 'Circle of Activities' in the Home view. Please fix. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New joyride build 1971
Now have the 'Circle of Activities'. But Journal does not start automatically. [Did not have Journal on Joyride 1970, either.] What are the steps to start Journal manually ? Thanks, mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
comment on touchpad problems
G1G1, Joyride 1971. Was visiting a friend. Apparently, he keeps his house less humid than mine. Noticed that when I waved my hand in the air some two inches above the touchpad, the cursor (e.g., in Terminal) would move around uncontrollably, and even jump. In fact, I had difficulty controlling cursor movement when using a finger on the touchpad. The cursor would move, but would typically be only halfway across the screen by the time my finger had reached the touchpad edge. When I would lift the finger (to reposition it for a repeat movement), the cursor would jump backward or sideways. (Also, sometimes when I was touching the pad, the cursor would not move even when I moved my finger.) Within the top right quadrant of the screen, it was extremely difficult to accurately position the cursor. [The four-corner-calibration keypress did not help.] I ended up licking my finger (to make its skin more moist). That cut back on the wild jumps the cursor was making, although there was not always a correlation between the distance my finger moved, and the distance the cursor moved. [Back home, the cursor again behaved correctly.] mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
XO communications interface naming
> From a practical perspective though, in XOs, the onboard interface is > always eth0 these days. I don't have wireless - am using an USB-ethernet adapter instead. Once upon a time, my G1G1 XO would set up its wired interface on 'eth0'. I normally run Joyride, and in the last couple of months there has been __NO__ regularity in which interface name is used for which communications interface -- one build will give the 'eth0' name to the wired interface, the next build will give the 'eth1' name to the wired interface, the subsequent build is back to 'eth0', and so on. [Often, when the interface is 'eth1', the radio interface (to the non-existent school ?) is given the name 'eth2' -- but the mesh interface name remains 'msh0'.] I've given up trying to make any sense out of the names given to the communications interfaces - I just 'ifconfig' and look for the wired IP address. mikus p.s. If my XO ever suspends, the wired interface is NOT resumed (and all interfaces get set to the inboard radio). [Maybe 'suspend' is something to be avoided by systems having an active antenna.] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: what about having network connections inhibit sleep?
> The real fix is to only force a suspend when the kernel knows no > process is scheduled to run now or soon, and to waken in less than a > whole second. I'm just a user, exercising whatever functions have been made available in Joyride. [I manually 'touch/rm' the various inhibit files in /etc/ohm and in /etc, to prohibit/allow 'suspend'.] I have a *number* of additional devices plugged in to my XO (principally a "permanent" SD card). It is my personal opinion that 'waken' will be made to happen in less than a second __ONLY__ if what 'resume' performs is "re-establishing the *original* software environment (as it existed at the moment when suspend took place)", and leaves "device discovery" to some sort of a follow-on process. I do not have my XO instrumented, to see what is actually happening during 'resume'. But in the past it has appeared to me that the system was trying to re-index the content of the SD card (in case cards were swapped while suspended ??). Given the hundreds of files on that card, one common result was that 'resume' gave up (timed out ??), and the XO went back into suspend state (power light blinking). Also, I use an USB-ethernet adapter. 'Suspend' drops power to USB, and my adapter re-initializes so slowly after power-on that 'resume' replaces the system's previous wired IP-address (on 'eth_') by a radio IP-address. Lately, I've been attaching my ethernet adapter through an independently-powered USB hub -- and having that ethernet adapter be still "powered up" when 'resume' runs in the XO *does* allow the system to keep its wired IP-address (though currently the ethernet network connection does not work after the 'resume' -- some sort of 'route' information seems to have been lost by 'resume'). What I'm saying is that in my opinion, performing "discovery of external devices" during 'resume' might make "wake in less than a second" an impossibility. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Build streams
Chris Ball wrote: > ... we discussed creating some new build streams > in preparation for our August "8.2" release. > Joyride: This will move immediately ... Despite everybody denying this, it seems to me that the OLPC group and the SugarLabs group are _NOT_ talking to each other. Finally, finally, Joyride 2024 managed to 'make available to users' some of the newer Sugar changes (packaged in a build, as opposed to only available in source). But what the 'Build Streams' topic proposes is making Joyride a "copy of the the olpc-3 stream" (does that mean a re-focus on kernel work as opposed to UI work ?). I'm interested in how the new Sugar behaves on my XO -- it is not clear to me how much broken F9 stuff I might run into in the meantime. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Build streams
> The F9 build does boot into Sugar -- we aren't going to leave everyone > with a broken build for long. It has bugs, though. We need help fixing > the bugs more than we need a demand for constantly stable developer > builds and an unwarranted supposition of conflict. Not long ago, when I tried to describe trying the F9 build, someone said "this is not close to ready for use". On my XO, olpc3_17 booting will only complete if I manually switch into the text console (ctl-alt-F1). I can't dim the screen (small sun-burst key); there are other screen anomalies; some keys don't work in Terminal; there are modules missing from site-packages; etc.. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Koji Tags for 8.2.0
> Is the piece we're missing the correlation with koji branches / > repository names? One problem I have with the current olpc3-19 build is that when I use 'yum', it offers to download some packages named "f7". Should the /etc/yum.repos.d in olpc3-19 be limited to "f9" only ? mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: SuperUser permission for the Driver??
> ... to install the activity and having it running > I have to copy the rules file into /etc/udev/rules.d folder. The preferred short answer seems to be NO. But if an Activity (application) *does* need something to be put into the operating system, should the "Sugar environment" provide a way to add that ? A benefit (to people who manipulate their systems) of putting add-on Activities into /home/olpc was to make them independent of an 'olpc-update' which replaced the operating system. One solution to the problem above would be to create TWO packages, one (.xo) to install the user-permissions material (done once), and the second (.rpm ?) to install the system modifications (done every time the system is replaced). [Etoys already supplies two such packages.] An RPM is static, and platform/version dependent. Ought the "Sugar environment" provide an "intelligent" facility which would 'hook/unhook' drivers [and objects on removable devices] into the running system (e.g., to add/remove "Sugar Activities") ? mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OLPC-Update + RPMs
Erik wrote: > We should move away from using olpc-update to upgrade systems. Am having a hard time understanding the problem Erik is addressing. I do *not* consider the effort that has gone into olpc-update to be "wasted" effort. I think decent 'one-click-installs' are wonderful when they work, but leave the user stranded when they don't. [It's hard to anticipate *everything* that might go wrong, and provide "automatic" recovery.] For an OLPC upgrade, I think there will always need to be a person to make sure everything worked (a person who can follow "cookbook" instructions). Let's look at how many users need that specific upgrade. [All these methods are suggestions - any of them might be used in any particular situation.]: * If it's one user, then I believe the "mechanism" best suited to do the upgrade is determined by where the fix is available: - If it is a "whole-OLPC" upgrade, skip down to '100 users'. - If the fix is in a koji-type repository, use a package manager (e.g., yum) to install that fix. - If the fix is a file, fetch (e.g., wget) that file, then use the appropriate tool to install it (e.g., 'rpm' for system stuff, or 'sugar-install-bundle' for application stuff. * If it's more than a dozen users (e.g., one school), then I believe a "mechanism" like 'customization' key should be used. It would be an administrator/technician who prepares the portable device with the fix. If it does not exist already, OLPC development needs to create the script which performs the actual upgrade from the files on the portable device. [Provision needs to be made for upgrading both system stuff and application stuff.] * If it's more than 100 users (e.g., one country), a "whole-OLPC" reload might be easiest to manage (using e.g., 'olpc-update' to affect system stuff only, or a 'customization' key to affect application stuff only; else the whole OLPC could be wiped with Secure Upgrade, or even with the 'customization' method. The "country release team" would probably be the ones to prepare the media from which such a "whole-OLPC" upgrade is distributed. With all of these methods, a form of 'dependency hell' may arise. If only some modules are replaced, they might not work with whatever that user has done to the rest of his system. If all the system modules are replaced, whatever system customizations that user had already applied may have to be re-applied; also, some applications the user had already installed may not work with the new system. Erik makes the suggestion that a package manager ought to be used to implement software update procedures (e.g., as in 'dist-upgrade'). The difficulty that I see is that the __packages__ made available to that package manager will have to include 'rules' to address the 'dependency hell'. Currently, modules at a certain level are gathered together into a build; if that build is to be "official", the working together of its modules is tested extensively. Package managers handle individual packages - each would have to indicate which other modules/versions it would conflict with. Lots of work. > What functionality do we certainly lose by using a package management > system as our default software distribution system? The "country release team" loses some degree of control. With an "official" build installed monolithically, there is some degree of assurance (to the end OLPC user, and to whoever paid for that OLPC) that it will "just work". When package management as the distribution method, who knows whether any OLPC user might accidentally end up with an oddball mix of installed modules. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
my XO has difficulty with f9
Been running reasonably happily with f7 builds (primarily Joyride 2056). G1G1; Q2D16. When I couldn't stand sitting still any longer, I installed yesterday's Joyride (f9). Ran almost acceptably (needed manual intervention during boot). One problem I had was that my USB removable storage devices (except for my SD card) were not being recognized, neither by OFW nor by the system drivers. The insoluble problem was that when I installed a build (e.g., Joyride 2089), the first boot would work -- but thereafter every attempt at booting would "stop" somewhere. [If I used the 'check' key to get out of "pretty boot", the booting process would always stop after the console message "Starting anacron:". If I used manual intervention to get to the text console, after the "Starting anacron:" message there would be periodic "msh0: link becomes ready" messages, sometimes interspersed with messages complaining about bad checksums in the jffs2 filesystem -- but sooner or later the XO would just sit there.] My problem is that I do not know if I did something after the first boot to cause this situation, Nor do I know how to "correct" jffs2. Each time the XO would not allow me to boot, I re-flashed the entire nand. Eventually got tired of it - am now back to running f7 builds. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: my XO has difficulty with f9
>> I may have caused that by (at that first >> boot) making some sort of change that worked with f7 but not with f9 > > That seems likely, but the olpc-update system should ensure that > you've got a clean system (no extra RPMs) when you revert. I would > hope that even if X doesn't start (especially if X doesn't start) you > can still get a console and/or use alt-boot (hold down 'O' at boot) to > fix things. That's the whole point, after all. Close, but no cigar. The first time (after X did not start) I booted with 'O'. The previously-running version came up, but without Journal or any Activities. I looked everywhere (/var/log, /home/olpc/.sugar/default/logs, etc.) for a clue as to how come -- but found no "footprints" anywhere. And could not start anything meaningful from the text console - kept getting messages like "no display". To be able to continue, did a nand reflash. And that wiped having something for 'O' to load. Don't remember what all customizations I had tried to apply to f9, that could have screwed up X starting. > http://dev.laptop.org/ticket/7357 and > http://dev.laptop.org/ticket/7348 looks like the two biggest blockers > to more people trying joyride right now. To me they're not. If I can bypass 7357 with 'check', that's good enough for me. And I actually LIKE 7348 -- I normally do not use the Journal to access removable storage devices, so having no Journal icon is no problem for me. In fact, I wrote http://dev.laptop.org/ticket/6584 to complain about the Journal scanning removable storage devices for their content; that ticket has now been closed with this notation about removable storage devices: "USB sticks will stop being available from the journal, instead being accessible in a simpler view in the shell". I am perfectly willing to do outside-of-Journal mounts. If I remember correctly (things were not going right), when in Joyride 2089 I plugged an USB stick directly into the XO, nothing of any note happened. In particular, the drivers did not create (recognize?) a /dev DEVICE that I could manually use in a 'mount' command. mikus p.s. IIRC, the time I tried plugging my USB hard drive directly into the XO (Joyride 2089, Q2D16), OFW complained mightily about partition-type being Linux on a DOS or something device. [OFW in f9 was not able to access that hard drive - telling me 'Can't open disk label package'. OFW in f7 has no problem, even though it's the same firmware !] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New joyride build 2097
> as far as mesa goes, the list has been very adament that the XO laptop > cannot run any opengl stuff, and my understanding is mesa exists to > implement a software version of opengl. either position is reasonable (no > opengl+ no mesa or mesa with slow opengl support), but right now it's a > contradiction (mesa installed and eating up resources, but instructions to > not use it for anything) "the XO laptop cannot run any opengl stuff" -- that's cast-in-stone language. I'm currently using f7 builds rather than f9, but (just to show that it *will* run) I've installed a binary Linux application that was compiled to require opengl. I did 'yum install freeglut' to keep that application happy. (Not sure whether that particular application can actually *use* opengl -- it tells me that some application-specific-images are not present -- but the rest of that application works fine.) mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
[OT] what does it mean to remove an activity
Possibly Off-Topic ! There was discussion of a GUI for removing an activity. But what does "to remove an activity" mean ?? Two extremes of user intent: User AA wants to install a new version of an Activity. He would like to remove the existing "executables", in case what any of them do might conflict with what he will install next. [Here the principal question is "will the existing Journal entries (of performing that Activity) be able to 'resume' once the subdirectory of /home/olpc/Activities has been replaced ?" User ZZ is mentally disturbed, and wants to "purge" his system of EVERY trace of an Activity having been present. Besides the subdirectory of /home/olpc/Activities, what needs to be removed is "wherever Rainbow allowed that Activity to store data", plus everything pertinent being kept by the Journal & database, plus everything pertinent in .sugar/default/logs, plus anything installed elsewhere (presumably indicated by that Activity's MANIFEST), plus anything in /usr/share/activities/bundle-archive. [If that Activity was NOT installed by user 'olpc', perhaps doing a system-wide 'find' would be the best way to discover its pieces (e.g., in /usr/share).] mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Inappropriate use of private meetings & lists. (reply to).
> I would like just remind you that the real > question is that if this "right" reply to setting is more or less > important than keeping discussions on the devel list or not. I > personally think that the latter is more important IMHO. This can often be controlled by using 'mail-reader' facilities. For instance, for messages that came from a list, my 'mail-reader' is set up to automatically provide "reply to the list", but also supports an explicit "reply to 'Reply-to:". On general-distribution lists, the intent often is: [1] to discourage off-list conversations - let everybody see everything (even though it may not be of interest to everybody), and [2] to "automate" participation by those whose 'mail-reader' only provides a "reply to 'Reply-to:" action. It is my hope that on a __developer's__ list, "hand-holding" would not be needed. [Please note that when one writes an original message (not a reply) to a list, then normally a 'Reply_to' action isn't available.] > its a very standard convention to keep list mail on lists. Again, it's a function of the 'mail-reader' being used. I have set mine up to filter mail that appears on a list to the folder in which I keep mail from that list. [And to show it to me only once, even if it is addressed both to the list and explicitly to me.] [Also, I can move individual mails from one folder to another, if I want to.] > if you need to take something off list then you should go through > the steps needed to do so. * If I want to reply to 'Reply_to:', I tell my 'mail-reader' to do that -- otherwise it would "automatically" send any reply to the list the message came from. [I've configured my 'mail-reader' with the addresses of the lists I subscribe to; it does not need to look in 'Reply_to:' to find out how to send to the list.] * But, if the originator's email address does not appear in the header or body of the message I am reading, and I *do* want to send a private message, I may have to go to considerable trouble to find out what the originator's email address is. Since many people do not sign their messages with their email address, I'm saved this effort if that address appears in the header. And since my 'mail-reader' gives me the option of sending to the 'Reply_to:' address of what I am reading, that's where I prefer the originator's email address to be. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Managing computer content in a schoolroom
There are at least two ways to manage the content of the laptops in
a classroom -- "bottom-up" (let the kids choose) or "top-down" (let
an administrator choose). Was reading a two-weeks-old Linux Weekly
News, which described Func (Fedora Unified Network Controller - see
https://fedorahosted.org/func). For top-down management, seems to
me Func would be something worthwhile having an intern look into --
can it be applied to a schoolroom with OLPCs? [Without looking into
it myself, I would venture 'yes'. ('yum install func' takes 1.8 M)]
mikus
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Home View appearance
> There is certainly not consensus regarding the merits of the > "free-form" Home View, but it is being accepted upstream, AFAIK. Sorry, but I couldn't resist : The principal merit I see in the "free-form" Home View is that it makes the screen look more like what is familiar (reassuring) to a Windows user. Last time I tried a relatively recent Joyride, the non-list Home View gave me a choice of whether I wanted to see "free-form" or "ring". As long as upstream continues to give me that choice of optionally selecting "ring view", I don't care what else is decided. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: (another) WebKit port of Browse
> Not everyone likes tabbed browsing. That may be true - but what if the user needs to reference two (or more) separate pages of information. If while looking at one page he can't remember *exactly* what the other page said, he may want to switch between pages. What are the alternatives to tabbed browsing? [To me, it is more logical to select a tab created under my control, than to select from the "previously-seen" list as presented by the Browse 'Back' button. And to open several instances of the existing Activity seems wasteful.] mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: (another) WebKit port of Browse
A reference was made to Gears: > My point was exactly that it is a plugin. > There are other plugins that are educationally useful. Security. I believe that 'Browse' is restricted as to how much it is allowed to modify the operating system itself. Such restrictions would apply to plugins as well. That concept NEEDS to be enforced. [War story: When plugins first became available for Netscape, I installed one. But Netscape started behaving differently from how I had thought I had set it up. I investigated, and found out that "under the covers" the plugin had CHANGED (without telling me) some Netscape settings to the way *it* wanted them. Got rid of it fast.] My point is that a 'plugin' is typically a "binary blob" -- the person installing it on his computer has NO IDEA as to what that plugin might surreptitiously be doing "under the covers". mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Home View appearance
Not 'Home View', but still: >> Another problem is that the Activity button (the 4th zoom level) can >> select the Journal if that was the last active activity. It has an own >> button so I cannot see any reason why it has to be the way it is. It is >> an annoyance that when I download several things then go from Browse to >> the Journal, open the pdf in Read, close Read and click the button it >> switches back to Journal and not Browse. It should not treat Journal as >> an application. Eben wrote: > Hmmm, that's not quite how it should work. While we do technically > treat the Journal as an activity, it should always be the bottom-most > activity on the stack. That is, you should only ever be switched to > it when there are no other open activities left, which is reasonable, > since the Journal is a point to resume activities from. If you can > confirm this behavior in a recent joyride, could you make a ticket and > indicate what build number you tested on? If Eben's description (Journal is at the bottom of the stack) gets implemented soon, my complaint will be moot. But in older Joyride implementations (I don't know about the latest), the Journal *does* get put where the Activity Zoom key goes to it. The result is that when I press the 'Magnifying Lens' key, I go to Journal. Then when I press the 'Activity Zoom' key, I stay in the Journal (and need to use an alt-tab sequence, or Frame) to get back to the Activity I was in. I would like a 'simple' way to get back to where I was. If 'Activity Zoom' will not do that, perhaps the 'Magnifying Lens' key could be made into a TOGGLE -- if one is not in Journal, the screen switches to Journal; if one *is* in Journal, the screen switches to the non-Journal Activity on the stack. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Activity dependency upon resident functions
I often have builds (in /versions) on my XO from dissimilar streams (e.g., Joyride vs. Update.1). Now that installation of Activities is a separate process, I'm assuming that if an Activity in /home/olpc/Activities works when one stream has been booted, then it will work as well when the other stream has been booted. But are there Activities which have a "version dependency" regarding the services they receive from resident modules ? [For instance, does it matter which level of libraries any Activity binaries were compiled against ?] I'm particularly thinking of "two-part" applications such as Etoys, where both an Activity bundle and an RPM package are needed. If I install Etoys-84.xo (the latest bundle) in /home/olpc/Activities, but then boot 708, will Etoys-84 be able to work with whatever level of services is provided in build 708 ? [If not -- does any Activity_version <--> Build_version compatibility checking get done at activity launch time ?] mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
sugar-update-control
> Changes in build 2153 from build: 2149 > +sugar-update-control 0.2-1 Manually installed this (via 'rpm') on my approximately Joyride 2146 system (G1G1; Q2D16). Now, whenever I clicked on the 'Control Panel' entry in the drop-down list from the center icon in Home view, Sugar would vanish (and be eventually restarted). Could not find any traces of anything suspicious in .sugar/default/logs nor in /var/log. Used 'rpm -e' to deinstall sugar-update-control. Then I again could use 'Control Panel' on my system. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Activity Backward Compatibility
The way I see it, there are TWO kinds of items for which "compatibility" needs to be provided -- executables + data : * Executables : The problem arises from the "quickness" with which some users (such as I) can switch operating system versions. I sometimes have two different "streams" on my XO (for example, the two "builds" in the /versions directory might be from Update.1 vs. Joyride) -- I can switch in minutes to a different "stream" by just rebooting. Others (including kids) can switch in tens of minutes to a different "stream" by installing a new build from an USB stick. The problem (of providing "compatibility" between Activities and the operating system on which they run) originated when Activities were no longer packaged into the "build". Now, unless the "build" to be fetched is accompanied by a set of Activity EXECUTABLES known to be compatible with that build, any "leftover from previous times" XO Activities might *not* receive the particular version of services from the new-fetched operating system "build" that they expect. The only solution I see is to provide a set of "compatible" Activity versions whenever a "build" version is provided. For kids, that would mean using a facility similar to 'Customization' to put BOTH a "build" and its "Activities" on the same USB stick. [I used the word 'similar' because the kid ought to have the options of either doing a "completely clean" install, or else installing the new build+Activities __without__ wiping out the existing /home/olpc content. (The question of providing "backward compatibility" between leftover /home/olpc data and changed Activity executables is left to another discussion.)] * Data : The problem is that Activities compiled in July might not work correctly with DATA placed into the datastore in February (by the version of the Activity that was installed at that time). The only solution I see is to *insist* that each new version of the Activity __verify__ that it can work with the data (e.g., formats) that are made available to it. If not, the Activity should notify the user of the incompatibility. mikus p.s. One of my "hot buttons" is 'hooking up' additional Activities which are resident on a removable storage device. Obviously, such Activities might be at the wrong version level. Therefore I am interested in there being a "checker" at activity-launch time, which would compare the current operating-system level against the level expected by the activity to be launched -- and at least warn the user if an incompatibility is found. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Activity versioning schema
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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
OFW sad face doesn't say why
Happened to put in laptop BB a SD card copied over from laptop AA. Pushed power-on, laptop BB showed me a sad face and powered down. Figured out why -- that SD card had a directory on it called /security, and in that directory there was a file called develop.sig. Since this file's content did not match BB's identity, BB powered down. I erased that file - then BB would boot o.k. If you have a cheap SD card, and an enemy with an XO, why not create /security/develop.sig on that SD card, and surreptitiously insert that SD card into his OLPC - he would be extremely UNLIKELY to think of examining the sd-card-slot for the cause of his XO not booting. If the OFW identified its reason for not proceeding with booting, this opportunity for mischief would not work. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
pacing oneself
The "visual speed of operation" of palette opening/closing on the screen is noticeably slower on the OLPC than on a workstation. When the OLPC user fails to "slow down" with his actions, unintended consequences can result. Was working (Joyride 2177) in Terminal with a removable storage device. Issued an 'umount' command - it was rejected with "device is busy". Went to the Journal, selected that device's icon, and (rapidly) invoked the pop-up palette to unmount that device. But (being spastic, and not pausing to make sure where the cursor was positioned) I had managed to click on the 'base' of the palette instead of on the 'Unmount' entry. Not realizing what had happened, what I *did* notice was the XO becoming extremely unresponsive. Went (took a long time) back to Terminal, and issued 'top'. It showed Journal taking 100% of the available CPU cycles. Decided to wait out whatever was going on. After two minutes or so, the high Journal usage stopped. Went over to Journal, and *now* I saw what I had done - Journal was showing me the files on that device. [Apparently it had taken Journal a couple of minutes to "scan" that device.] Switched what the Journal was showing to "normal", clicked (more carefully) on the 'Unmount' of the removable device, and all was back to what was supposed to be. I am *not* posting for help. But I *do* wish to point out that (particularly when dissimilar functions are visually adjacent -- e.g., "unmount" vs. "show"), failure to 'pace oneself' on the OLPC can bring on the unexpected. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OFW sad face doesn't say why
Scott wrote (regarding me booting with the wrong develop.sig on an SD card): > Do you normally use a developer key in order to boot -- ie, are you > running a joyride build on BB? Is the root problem here, perhaps, > that after OFW finds a develop.sig on the SD card which doesn't work, > it doesn't continue to look in other places (like NAND)? Yes, I am running a joyride build on that system. This whole business of "what indicators need to be placed where" is a complete mystery to me. That is why I use a "permanent" SD card, with my develop.sig on that card -- then if I need to re-flash NAND I don't have to worry about who/how puts a develop.sig file in NAND. [Yes, there was the correct develop.sig for that system in NAND; only the SD card (looked at first by OFW) had the incorrect one.] mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OFW sad face doesn't say why
Mitch wrote: > If you hold down the check key while booting, the firmware will give > additional information about the boot progress, in both iconic and > textual form. I did not realize that. Now that I went searching for this, saw it mentioned in the wiki on the 'XO_Troubleshooting_PowerOn' page. And yes, with the check key pressed, the firmware did print "trying sd:\security\devel.sig" and some sort of "invalid" message. [These "stand out" from the other texts if one KNOWS to look for them.] [I haven't been using "chatty" (check key held) mode for booting -- but I've been seeing icons-drawn-by-firmware anyway.] I WISH there was a comprehensive description accessible of the __iconic__ information shown by the boot process. For instance, for me the green 'olpc' icon disappears from the firmware display whenever I have a SD card plugged in (but then I normally *would* see an orange 'SD card' icon). I seem to get the additional red? 'plugin' icon whenever I have an USB stick or an ethernet adapter plugged in. And I have only vague notions about what the various symbols (that can appear underneath an icon) are trying to tell me. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
experiencing unexpected OLPC behavior from a misplaced click
I posted about an experience I had, where I was surprised to find that my OLPC had become unresponsive. My reason for posting was to "alert" others that "surprises may be lurking" for OLPC users. Greg, you quoted my post, and wrote: > Can you file a bug on this (dev.laptop.org) and include steps to > reproduce and test? I am put into a difficult position when I see comments like this. If I am prevented from doing something by the current behavior of the OLPC, and would like that behavior changed to allow me to go ahead and do the thing I wanted, *then* I will write a ticket. But here is a case where I did not wait long enough for the OLPC to draw a pop-up palette, and did not make sure that the cursor was correctly positioned on the appropriate entry in that palette, before I 'clicked'. In other words, it was __I__ who misbehaved. It is my intention to *not* write a ticket on this. Aside from the __user's__ behavior needing to be corrected, I'm not sure what else would be "ticketable" ?? It might help impatient users if palettes (e.g., in the Journal screen) were 'instantaneous' instead of 'slow' -- but I imagine the graphics speed is established by the OLPC processing capability (low power draw is imperative) and the overall Sugar GUI 'Look_And_Feel' design -- and can't be changed. I see nothing in this particular situation for which writing a ticket would improve matters. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
dropping mkinitrd from recent Joyrides
Came across an XO on which 'rpm -q kernel' listed two packages -- from 0716 and from 0718. Wanted to do 'rpm -e' on the one from 0716. That failed, because file '/sbin/new-kernel-pkg' could not be found. Did 'yum install mkinitrd'. Now the 'rpm -e' of the 0716 package worked. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: NAND Full Requirement
This is not meant as an implementation suggestion, but as a philosophy-of-purging comment: Greg listed some requirements, among them: > - Must not disable any activities or other functionality The discussion mentioned that in Uruguay it was precisely 'Activities' that often filled the NAND. To me, an 'Activity' is something static - if a kid could obtain it once, he can probably obtain it again. As such, I think in the case of a full NAND, database entries showing the __fetching__ of Activities would be ideal for "automatic deletion". To minimize the impact on the kid, don't delete these kinds of entries for his 'favorite' Activities. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Remarks on the Work of Sugar
[This does not fit the 'Subject:', but is still worth remarking.]
Walter wrote:
> It is clear from even a casual review of the devel and sugar lists and trac
> that much of the frustration experienced by both users and developers
> resides not in the details of, for example, dbus or Python, but rather
> in more catastrophic and unpredictable failures of the network ...
My comment arises out of my dissatisfaction with the use of the
"network lights" on the front panel of the OLPC. My problem is that
although "how the OLPC communicates" has been written about, I have
been UNABLE to form a clear picture of how 'destinations' interact.
[The current use of the lights is confusing and uninformative. I
think a light being off should show the corresponding connectivity
does not exist. Flashing could show that connectivity is being
(re)attempted; and pulsing could show "this connectivity is being
actively used at this moment".]
I can identify five different 'destinations' for OLPC communication:
(1) To another XO, via the mesh ("under the tree")
(2) To the "school server", via the mesh [e.g., no AP "relay"]
(3) To another user (XO?), via an AP relay [today - via jabber]
(4) To the "school server", via an AP "relay"
(5) To a (non-school) server on the internet, via an AP [wget]
It is difficult to "intelligently" map the states of these five
modes onto just two lights (all that are available on the XO-1).
What "from the lights" information will best guide the behavior of
the kid using the XO?
I think it makes a difference to the kid's future behavior if he is
connected to the internet or not -- that makes showing "AP status" a
good candidate for a front panel light.
I also think the kid would like to see at a glance whether he can at
this instant fetch_from/save_to the school server -- in my opinion
showing "school server status" is a good candidate for using a front
panel light.
Then, for instance in "under the tree" situations, the kid wants to
know whether he can communicate with his buddy. Right now it
involves an explicit invocation of Neighborhood View to check on
that -- a good use for a THIRD light would be to show "mesh status".
[With only two lights available, perhaps a Control Panel function
could assign what those lights show, Then G1G1 users would likely
not ask to see the "school server" status.]
And clearly written DOCUMENTATION would be helpful -- particularly a
"guide for connecting to 'destinations"". For instance, HOW does
switching communication to the school server between mesh-IP-address
access and AP access (presumably with an internet-IP-address) work ?
And if buddies were formerly accessed through the mesh, but
starting at 1 p.m. are to be accessed through the school server
jabbber - what needs to happen at the XO (does the kid have to do
anything) ?
mikus
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Joyride 2201 blocker
I do most of my work with CLI from the Terminal. On my XO with Joyride 2201 there is no "bash history" accessible in Terminal -- hitting up-arrow at the prompt does NOT call up what had been previously entered at the prompt. ["bash history" is accessible from the text console (alt-ctl-F1).] mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Joyride 2201 blocker
I get the same result on Joyride 2202 (manually upgraded to 2203). What is happening is that in Terminal on my XO certain keypresses (e.g., up-arrow, right-arrow, end) are not being recognized. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Congratulations! but Sugar sucks
I'm not familiar with the details of the Rainbow implementation, but I question this claim: > Sugar, as it currently stands, is among the least secure operating systems > ever, far less secure than any modern Linux or Windows OS. I can easily > write an Activity that, when run by the user, escalates to root privileges > and does anything I like with the system. My understanding was that something called an 'Activity' would be assigned its own userid-groupid. The standard Linux permissions would prevent such an 'Activity' from messing up the system. I agree that "as of this date", the 'su' (or its equivalent) provision sucks -- a decision has been made that the kid does not have to enter a password, even if one has been defined for root. But that can be improved to not remain the 'least secure ever'. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
help - how to tell apart signed build from unsigned build ?
From reading the wiki, I am assuming that 'olpc-update --usb' can install a new build on a secured XO (G1G1, without developers key). Suppose I am handed two USB sticks. One contains files os1.toc and os1.usb; the other contains files os4.toc and os4.usb. If I'm told only that one of these USB sticks contains a signed build, and the other contains an unsigned build, HOW can I tell which USB stick I should use to use to install a *runnable* build on that secured XO ? Thanks, mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New joyride build 2222
> The size increase suggests that maybe my pilgrim hack to zap the big > dictionaries did not work. I'll look later... Noticed that sugar-evince 2.20.1.1-3.olpc3 brought in poppler 0.6.2-5.olpc3, which is 3 MB. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
inconsistent identification regarding full-screen "sessions"
FYI - I am not writing a ticket at this time (until I can reproduce consistent misbehavior). G1G1. Joyride manually updated to 2216. My biggest confusion arises because I __cannot visually tell__ which icon in the Frame top bar is associated with which running task. I did not want to tie up a whole Terminal session to a job which can peacefully run in the background -- so I normally start such a job (from Terminal) by appending '&' to the command. Afterwards, I can enter other (foreground) commands using that same Terminal session. Happened to call up Frame. Noticed in the top bar a NUMBER of small dark circle icons. Turned out that when I clicked on one of these small dark icons, the "frame top bar highlight" shifted to that icon (and a drop-down palette was shown, offering 'Resume' and 'Stop' -- but not identifying what session/task that icon was for). Not wanting to have these small dark circle icons in my Frame top bar, I clicked on 'Stop' in the palette in several of them. Did NOT see any of the small dark circle icons go away. [But afterwards, I found out that my background job had received a signal 11.] mikus Speculation: After I have started the background job, I start a full-screen (ported Linux) application from that same Terminal session. If I now enter a sequence of alt-tab presses, sometimes I see just the full-screen application (in its proper place in the sequence of session screens being shown), but sometimes I see __BOTH__ the full-screen application and (on a SEPARATE screen in the sequence of screens) the Terminal session from which I launched the full-screen application. I think it likely that when two screens get thus shown for what was just a single Terminal session, the "extra" screen (is it the 'full-screen'? I don't know) gets represented in the Frame top bar as a small dark circle icon. If my speculation happens to be true, then I see 3 inconsistencies: - If the full-screen application sometimes shows up as an "extra" screen, and as an "extra" icon within the Frame top bar, it should *always* show up that way. - If running a full-screen application can cause an "extra" icon on the Frame top bar, then when the full-screen application is exited (goes away), its "extra" icon in the Frame top bar should 'go away" as well. [Today my Frame top bar had a considerable number of small dark circle icons, presumably created on earlier occasions when I started (and stopped) that full-screen application. Yet at any one time I had run only a single instance of the full-screen application, plus the one background job.] - If running a full-screen application can cause an "extra" icon on the Frame top bar, then that icon should be *labeled* with the name of the command that started that application. [Also, I normally have two Terminal sessions active -- but I have filled in the "label" in the Application top bar to distinguish between them. Yet when I hover over the icons in the Frame top bar, both say 'Terminal Activity' instead of using my labels. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New joyride build 2222
> Anyone whose activities use Numerical arrays in Python should check that > they still work in +. If anything is broken, I'll be happy to help > fix it. The only Activity I am sure needs to be checked is Measure. I can confirm that Measure does NOT work. Neither does PlayGo. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
specifying what services Activities may use
There was an earlier discussion of how to provide the right build level for users out in the field, since now Builds can be installed separately from Activities -- leading to the possibility that for someone an Activity_version on his XO will find itself *mismatched* with the Build_version on his XO. The problem is bigger than that. Since Joyride 2210, I have seen three of the Activities I often show off get broken by the *removal* of services from the Joyride builds. If the current software distribution process has trouble matching existing Activities to the services_provided_by_a_Build -- how will NOT YET EXISTING Activities be accommodated by the software that Sugar is supposed to run on top of ??? I'm thinking of someone in a far-off land who has an idea for a "killer" Activity, to be run under Sugar. HOW does he learn which (library, or kernel, or whatever) services will be available *everywhere* Sugar can be installed, which services will be available only with *specific* builds/platforms, and which services would *never* be available for functions fitted into Sugar ? mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
TuxPaint woes
There are people like me who like TuxPaint better than Oficina. However, to run TuxPaint, users of current Joyride need to re-install SDL_mixer and libmikmod. Also, TuxPaint is not being "checkpointed" by Journal (and seems to start slower than it did on build 65x). I realize there is a serious shortage of resources. But should it be up to the Activity developers (or in this case, those who first "fitted" the software to Sugar) to keep supporting their submission as the Sugar/operating_system platform keeps evolving ? mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: specifying what services Activities may use
A DECISION NEEDS TO BE MADE !!! I've been randomly launching Activities on 2226. __Far too many__ of them fail -- because csound was changed, numeric was changed, mixer was changed, etc., etc., etc. Given that there *are* Activities out in the hands of users (both with G1G1 and with country distributions), the question becomes: HOW IMPORTANT IS IT TO AVOID USER-PERCEIVED REGRESSIONS ? For what it's worth, my opinion is that if users who *had* been able to run many different Activities were to be offered 2226, they would be better off staying with what they have. mikus p.s. I started this topic to point out that "slimming down the build" could inhibit Activities *yet to be developed*. But it turns out that "slimming down the build" is killing *existing* Activities. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] specifying what services Activities may use
> Please ensure that you have filed tickets for each and every one of them What good will that do? At the beginning of this year, I wrote a ticket saying an Activity would not start. Without notifying me, someone re-assigned *me* as the owner of that ticket -- presumably making it my responsibility to fix that Activity so it would start. Fixing Activities is not what I am being paid to do. All I want to do here is to point out the bad publicity that regression (from what previously "worked") might cause. Is that an opinion worth filing a ticket about? mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New joyride build 2222
>> > Anyone whose activities use Numerical arrays in Python should check that >> > they still work in +. If anything is broken, I'll be happy to help >> > fix it. The only Activity I am sure needs to be checked is Measure. >> >> I can confirm that Measure does NOT work. > > Which version of Measure? 17 > What is the problem with it? When I launched it from Home View, its icon blinked and blinked and eventually disappeared. The screen drawn by the Activity itself never appeared. > Which version of joyride did it last work in? I do not remember. > You may be seeing #7467 No. #7467 describes a "Not implemented" error. What I described never got that far. >> Neither does PlayGo. > > Same questions. Version 1. Same problem. Don't remember which version it last worked in. #7467 does not mention PlayGo. > Do both of these activities use Numeric? I have no idea. For me, both of these activities logged an error something along the lines of "'numeric' not found". After I installed the rpm for python-numeric, both activities launched into their Activity-drawn screens. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Notes from 7/29 Release Meeting(s)
> 1. We're going to begin nominating this week's 'joyride-weekly' tomorrow at > 0900 EDT. If you have risky changes you want to contribute, please provide > them > _after_ we deliver our nomination. If you want to help more peoples' changes > make the deadline, then please help smoke-test joyrides built close to the > deadline. Please record your results on > >http://wiki.laptop.org/go/Test_Group_Release_Notes > > and file bugs liberally. When we deliver the build nomination, we will > summarize the currently available testing notes in the announcement mail. This looks to be focussed on the wide testing of proposed changes. If you also want to "wring out" agreed-upon changes, why not every week create a new build version in the '8.2' stream? Then anyone who wants to verify how things behave in the "latest 8.2 candidate" can test that version. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Your journal is empty
Recently, I have on two occasions with Joyride (2229+, 2232) pressed ctl-alt-erase in order to "restart" Sugar. Both times. when Sugar came up, the Journal screen told me 'Your journal is empty'. If "unwanted emptying of the Journal" were to be experienced by others (in addition to me), then I think this problem should be a SERIOUS blocker to 8.2. mikus (G1G1) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: identifying which builds are signed
>> I have a general question. I'm going to be helping some Ship.2 G1G1 >> users (without developer keys) to perform off-line-upgrades of their >> systems. Currently I have to "data mine" through the wiki to verify >> which builds are "signed" (and can be "applied" from an USB stick). > > Things in > > http://download.laptop.org/xo-1/os/official/ > http://download.laptop.org/xo-1/os/candidate/ > > can be installed on locked machines. > > When we sign candidates or make candidates official, we send > announcements and publish the signed build in the appropriate directory. Thank you for the information. I'm concluding from your answer that there is _no_ way to tell, by examining the 'binary' of the build (e.g., os___.ucb), whether that build is "signed" or not. My interpretation of the wiki is that the 'fs.zip' file from the "signed" build is needed only when one is doing a "clean install" which wipes out the ENTIRE NAND. If one wants to preserve /home/olpc on a secured machine, one can instead use 'olpc-update' to upgrade to the new build -- and the description of 'olpc-update' says NOTHING about any 'fs.zip' file needing to be input. Thanks, mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: identifying which builds are signed
> olpc-update is presently only runnable on machines which have already > passed the boot-lock; therefore its operation does not require any > additional signatures. Thank you. Now it makes sense to me -- a wrongdoer can insert a device and try booting it (e.g., the four-game-button press) -- so *what* he is trying to load needs to be verified for authenticity. Whereas the 'olpc-update' user already has a running system, and root privilege, so he is allowed to load. Michael, thank you for this explanation (and for describing where the signatures are contained). This is *much* clearer than the wiki, which gives cookbook explanations but does not say "how come". mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
