The Testing Area :: September Extensions



upx and advdef have both been discusses before. If DSL were only  offered a traditional hard drive install, then a smaller download size with a 'single expense' to uncompress several layers of compression would be acceptable.

However, DSL is designed to be a nomadic live CD, or frugally 'installed' system. As such the initial savings in download time is lost if it means upon every boot one must again have the 'expense' to uncompress several layers of compression. It would mean slower startup times for each extension and much slower boot up times for systems where many extensions are auto loaded upon boot. Plus the extra burden on the less powerful CPUs that DSL still fully supports.

Given the design philosply of DSL I cannot see a benefit of layering compressions.
Quote (curaga @ Sep. 28 2007,18:53)
There is still one major drawback with using upx: you cannot see the dependencies without a patched file.. and there is no patch for the busybox version

Yes. But on running, the program will show "Cannot find libxyz.so.x. ...".
And then it should be easy to find what is missing. Also, let's say the user does not know what "Cannot find libxyz.so.x. ..." means. In this case, even if he could do 'ldd xyz', it won't be of use to him..

But, let's say we have a worst-case scenario where a large number of libraries go missing, and the app won't start.
There are 2 possibilities:
1. The missing library is an important system library. In this case, many other programs that depend on this library will also fail.
2. The missing library is a minor library, possibly used only by this specific app. In this situation:
(a) The .info file for the extension should describe what other extension(s) is needed. (This assumes the user has read the .info file before downloading. Also, this assumes the .info file is clear and easy to understand.)
(b) In the case of a .dsl or .tar.gz, where installed files may be accidentally deleted, we can reinstall by reloading the .dsl/.tar.gz.
© In the case of a .uci, the $PREFIX is read-only, so libraries shouldn't go missing.
advdef shouldn't have any difference on the end user.  It is only during (re)compression where it takes more time.  So that is up to the extension maker as it provides an advantage only -- in the size.  However, upx is a different case altogether and I would be against implementing it due to all the disadvantages (and would not be a viable option in every extension anyways, regardless of implementation).
Robert:
It seems to me that upx operates in much the same manner as a cloop-mounted uci. Assuming (for the sake of argument) that their speeds and memory usage are similar, I do not see an appreciable difference between the two. If so, why is uci acceptable and not upx?
I don't force everyone to use UCI. Typically we have extensions in many flavors.  Typically the user has a choice of extension flavor depending on hardware capabilities.

If I understand this correctly, you would be upx compressing all the binaries and then again, the tarred package with gzip or advdef. That double (second) compressing is not going to yield much.

It would be like me gzipping the ucis or for that matter gzipping the isos. Not much advantage for the effort during creation and during unpacking.

I still think this approach is best for a traditional hard drive installed system and providing smaller downloads.


Lets try this...

Make one of a significant size, i.e., not a trivial extension, and one that takes argument(s).

I will post it in testing and will test and compare on a 32MB 90Mhz machine.

Hopefully we can get one of our Libertto users to also test and report back and anyone else with a low end machine.

No promises that this approach will be implemented. Just a test and comparision of actual results.

Next Page...
original here.