User:NeoAmsterdam/Notes to Self: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
NeoAmsterdam (talk | contribs) mNo edit summary |
||
Line 1: | Line 1: | ||
<div style="float: right;">__TOC__</div> |
<div style="float: right;">__TOC__</div> |
||
* A temping recipe for [http://gsoc.cat-v.org/people/ameya/blog/2007/08/10/1_Booting_plan9_on_OLPC/ booting Plan 9] (and the [http://gsoc.cat-v.org/people/ameya/blog/2007/08/19/1_Plan9_Kernel_Booting_on_OLPC/ evidence] to prove it's possible) |
* A temping recipe for [http://gsoc.cat-v.org/people/ameya/blog/2007/08/10/1_Booting_plan9_on_OLPC/ booting Plan 9] (and the [http://gsoc.cat-v.org/people/ameya/blog/2007/08/19/1_Plan9_Kernel_Booting_on_OLPC/ evidence] to prove it's possible) |
||
* Radio streaming? (transmitting from "[http://www.thevoiceofpeace.co.il/gallery2/showphoto.php?photo=439_e3a0a0732ff8dc75d7dd77d26e72d22e.jpg ...somewhere in the mesh]"?) |
* Radio streaming? (transmitting from "[http://www.thevoiceofpeace.co.il/gallery2/showphoto.php?photo=439_e3a0a0732ff8dc75d7dd77d26e72d22e.jpg ...somewhere in the mesh]"?) |
||
** A [[Skype|certain well-known VoIP app]] can't hack it on an XO. Considering that it's effectively the equivalent of audio streaming (albeit p2p), this might not be feasible. Then again, it's just was probably a half-***ed port of a known pile of slop... |
|||
* Rebuild [[Mini vMac]] (multiple drives, 576x448 or 1184x900 screen, max speed by default; X11 v. GTK builds) |
* Rebuild [[Mini vMac]] (multiple drives, 576x448 or 1184x900 screen, max speed by default; X11 v. GTK builds) |
||
** A rebuild requires steps not possible using the Mini vMac activity ( |
|||
* <del>Write a "hack ~/.sugar/default/config" note (builds before 852; after ~/.gconf/desktop.sugar/user/%gconf.xml)</del> fairly self-explanatory. |
* <del>Write a "hack ~/.sugar/default/config" note (builds before 852; after ~/.gconf/desktop.sugar/user/%gconf.xml)</del> fairly self-explanatory. |
||
* Extracting XO splash sound (possibly replace) from w/in OFW |
* Extracting XO splash sound (possibly replace) from w/in OFW |
||
*:'''Q''': is the <nowiki>[filesize|duration]</nowiki> an upper limit? Are the resolution, bit-depth, and channel count fixed? |
|||
* SOS/Post-catastrophe app (how to fit a collaborative documentation effort into ≤512MB? or make it decentralized?) |
* SOS/Post-catastrophe app (how to fit a collaborative documentation effort into ≤512MB? or make it decentralized?) |
||
*# Each XO gathers info, establishes pt-2-pt comm links with nearest 2 neighbors (min. for msg. relay) |
*# Each XO gathers info, establishes pt-2-pt comm links with nearest 2 neighbors (min. for msg. relay) |
||
Line 11: | Line 20: | ||
*# Once a relief center shows up (w/ hard drives), acts as XS/server…<br /><small>or a real one - it would make sense that schools would become impromptu first-aid and triage stations</small><br />…XOs spot it in the mesh (?) or by mesh-relay and U/L upon discovery (deltas thereafter) |
*# Once a relief center shows up (w/ hard drives), acts as XS/server…<br /><small>or a real one - it would make sense that schools would become impromptu first-aid and triage stations</small><br />…XOs spot it in the mesh (?) or by mesh-relay and U/L upon discovery (deltas thereafter) |
||
*#* But how long until relief shows up? How much data captured in that time? What data would be the most urgent? |
*#* But how long until relief shows up? How much data captured in that time? What data would be the most urgent? |
||
*# Comms are transient (vid/pic/voice), but written info (chat/DIY wiki) would need context awareness - geo/GPS, people/relations, needed items, status (Injured/killed/infirm) |
*# Comms are transient (vid/pic/voice), but written info (chat/DIY wiki) would need context awareness - geo/GPS, people/relations, needed items, status (Injured/killed/infirm)<br />Might be better served by smart-phones? Might too gruesome for kids to do, but parents would probably rely on the kids to do the data entry... hmm... :-/<!-- Plus, this sort of thing oughtn't be circulating - it might be too much even for 1st aid/responders to deal with... isn't the 'net gory enough already? --> |
||
**Caveat emptor: Batteries might drain before relief arrives, and there might not be any power source. |
**Caveat emptor: Batteries might drain before relief arrives, and there might not be any power source. |
||
* <del>Running <tt>sugar-emulator</tt> on F12/PPC64 |
* <del>Running <tt>sugar-emulator</tt> on F12/PPC64 (<tt>/usr/share/sugar/activites</tt>??)</del> Horrible. Just plain horrible. Shame on Fedora. |
||
* Build KDE 3 from scratch (because KDE4 is almost Java-like in resource hogging). |
* Build KDE 3 from scratch (because KDE4 is almost Java-like in resource hogging). |
||
** Takes a whole day on a 2,5GHz G5 Quad; it'll probably take a week on an XO :-( |
|||
* Social network/cultural exchange/distance learning activity? o_O |
Revision as of 18:05, 13 February 2011
- A temping recipe for booting Plan 9 (and the evidence to prove it's possible)
- Radio streaming? (transmitting from "...somewhere in the mesh"?)
- A certain well-known VoIP app can't hack it on an XO. Considering that it's effectively the equivalent of audio streaming (albeit p2p), this might not be feasible. Then again, it's just was probably a half-***ed port of a known pile of slop...
- Rebuild Mini vMac (multiple drives, 576x448 or 1184x900 screen, max speed by default; X11 v. GTK builds)
- A rebuild requires steps not possible using the Mini vMac activity (
Write a "hack ~/.sugar/default/config" note (builds before 852; after ~/.gconf/desktop.sugar/user/%gconf.xml)fairly self-explanatory.
- Extracting XO splash sound (possibly replace) from w/in OFW
- Q: is the [filesize|duration] an upper limit? Are the resolution, bit-depth, and channel count fixed?
- SOS/Post-catastrophe app (how to fit a collaborative documentation effort into ≤512MB? or make it decentralized?)
- Each XO gathers info, establishes pt-2-pt comm links with nearest 2 neighbors (min. for msg. relay)
- Is there a way to make long-distance multi-node pt-2-pt contact?
- As users enter information, suggestions could be given to the user (how much water x number of people need, how to recognize possible water-borne diseases, triage how-to)
- Once a relief center shows up (w/ hard drives), acts as XS/server…
or a real one - it would make sense that schools would become impromptu first-aid and triage stations
…XOs spot it in the mesh (?) or by mesh-relay and U/L upon discovery (deltas thereafter)- But how long until relief shows up? How much data captured in that time? What data would be the most urgent?
- Comms are transient (vid/pic/voice), but written info (chat/DIY wiki) would need context awareness - geo/GPS, people/relations, needed items, status (Injured/killed/infirm)
Might be better served by smart-phones? Might too gruesome for kids to do, but parents would probably rely on the kids to do the data entry... hmm... :-/
- Caveat emptor: Batteries might drain before relief arrives, and there might not be any power source.
- Each XO gathers info, establishes pt-2-pt comm links with nearest 2 neighbors (min. for msg. relay)
Running sugar-emulator on F12/PPC64 (/usr/share/sugar/activites??)Horrible. Just plain horrible. Shame on Fedora.
- Build KDE 3 from scratch (because KDE4 is almost Java-like in resource hogging).
- Takes a whole day on a 2,5GHz G5 Quad; it'll probably take a week on an XO :-(
- Social network/cultural exchange/distance learning activity? o_O