DSL Ideas and Suggestions :: OpenOffice - can it be split?
OK, I'll start by making it clear that I haven't tried using openoffice under DSL, and don't really know much about how it works. Just had another one of those passing thoughts that I figured I'd throw in to see if it might actually help somewhere...
From how I understand it, uci's are kinda dsl packages that can load and unload in and out of memory? My query, seeing that openoffice has several different sections, is whether the entire package loads into memory, and, if so, whether it would be possible to split it up so that only the sections you want to use at that time load into memory?
ie., say you want to use a spreadsheet - is there a way to only load the parts of openoffice needed to run the spreadsheet app, rather than the whole package? So you could run OO with less memory than is currently required?
As I said, I don't really know how it currently works, but I thought I'd just throw it in for discussion.
I think you may have gotten the mechanics of the uci extensions wrong. With uci extensions, very little is actually loaded into the memory. They are supposed to be mounted as a compressed loopback device (/dev/cloop) and are decompressed and read on-the-fly. The only possible ways you run out of memory with these extensions are as follows:
- There is a single, huge executable file inside it bigger than the available memory.
- The executable creates a dynamic data structure larger than what is left in the memory.
- The contents of the user.tar.gz decompresses to something big. This archive is the only part of the uci extension that will actually reside in the ramdisk without invoking the mkwriteable script. Most of the time, though, it just contains icons, menu items, and user resource files. For openoffice it is about 1.2M uncompressed.
I was able to use openoffice with 120MB of RAM without swap, and with 64MB of RAM with 100 MB swap file. I was able to start it on 64MB of RAM without swap, but a simple cut and paste shut it down.
original here.