Can the OLPC support "power users" ?
mikus at bga.com
Sat Aug 29 11:59:08 EDT 2009
>> 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.]
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.
More information about the Devel