Can the OLPC support "power users" ?

[Mikus Grinbergs]

>> So, is there some way I could list the OpenJDK dependency in the
>> activity.info file and have the system offer to download and install
>> OpenJDK if it has not yet been installed?
> 
> No, activity bundles are supposed to be self-contained, not depending
> on anything else other than the standard Sugar platform.
> 
> As long as Java is not part of the Sugar platform, the JRE will need
> to be bundled inside every activity that uses Java.

Back in Nov 2007 (before I got my G1G1 XO), I decided that the XO-1 
did not have enough "disk space" to keep all the executables and 
data that I wanted to have.  So my "architecture" for the XO has 
always included a "permanent" SD card, to __off-load__ significant 
content from my OLPC's "disk space".  [Also, I am familiar with the 
Linux command line, and with writing "batch scripts" to make that 
command line more efficient.]

The way this works for me for Java:  I have a "Package Repository" 
on my SD card, into which I download (NOT through the Journal !!) 
Java distributions as they become available.  [Sometimes internet 
servers are not accessible -- I prefer to keep local copies of the 
important resources I've downloaded.]  I also have a "Provide 
Executables" set of directories on my SD card.  Supplying a version 
of Java (I'm currently using jre1-6.0_13) to the system means 
unpacking that package into my SD's "Provide Executables" area.


The overall design of Linux software typically places many 
"resources" into the protected (i.e., operating system) area of main 
memory.  The catch is that whenever a new build gets installed, some 
of the "resources" contained in that protected area may thereby be 
modified.  That is why I keep a separate "Provide Executables" area 
on my SD card -- that SD area is NOT affected by whatever gets done 
(e.g., install new kernel) with the protected area of main memory.

I have written a "batch script" to __hook__ (as root) the places 
where the protected area of memory expects Java "resources" to be, 
to instead link (symbolically) those places to my actual Java 
"resources" as they reside in my SD's "Provide Executables" area. 
Now whenever I install a new build, I simply run my "batch script" 
to 'install' Java -- that immediately makes Java accessible to 
__any__ application (or Activity) the user chooses to run.


Bottom line:  In my run-time environment, I was able to just install 
(sugar-install-bundle) the Java-dependent SarynPaint Activity bundle 
-- and it immediately had access to what it needed to run.  [I did 
*NOT* have to concern myself about how much OLPC "disk space" might 
get eaten if every Activity needing Java packaged its own JRE.]


mikus



p.s.
On F11-on-XO1, I have extended this "Provide Executables" concept to 
include __Sugar Activities__ -- they too reside on my "permanent" SD 
card, and they too get "hooked" into /home/olpc/Activities by 
another "batch script".  The result - I have over 100 Activities 
installed on my system (and launchable from Home View), yet still 
have 400 MB free in my XO-1's NAND.