User Feedback :: Moving Forward - What's Your Desire?

Quote (buzzard @ April 15 2007,18:42)

I notice there are 3 ways to add mydsl: .dsl, .uci, and .unc. Does this mean that the ultimate best way to add modules is still being searched for? I wouldn't mind it if the add-on apps were loaded via bootlocal.sh, with bootlocal.sh being loaded from a location specified in the kernel command line

Loading apps from bootlocal isn't a good idea, because they won't have a menu button. Loading from aterm (via a bash script, etc.) will cause intermittant crashes if you're using jwm. By far, the fastest and safest way is to load from a mydsl folder at bootup, or from the mydsl panel if you need something on the fly.

I'll join the consensus regarding eliminating Firefox to save space. Dillo serves the purpose until a user gets around to understanding how to load an extention. First, however, he complains bitterly about not knowing how to update the old one.

Quote (jpeters @ April 15 2007,14:38)

By far, the fastest and safest way is to load from a mydsl folder at bootup,

& the mydsl folder can be nominated at boot time - even from a live-cd boot so you can boot a live cd with different apps loaded during the boot process, depending on what you require at the time.

I suggested the removal of Firefox, but I concede I *actually* use that version, not the updated one, for the sites that require me to use Javascript or something.

A desktop icon stating that it will download xxMB and *then* launch Firefox would be desirable, but I don't know if that means downloading GTK 2.0 also, if GTK 2.0 would be included in DSL and GTK 1.2 left behind, if the possibility to download the outdated and hopefully small version persist or if all options would be presented after clicking.

I can't actually remember what I voted for, but the more I think about this, the more I believe it would be better to update the DSL kernel to 2.4.34 and the DSL-N kernel to 2.6.20 whilst (hopefully) keeping compatibility for the majority of old machines and maintaining a minimum set of applications.

In order to keep the size down, non-essential applications could always be stripped out and posted in the repository to be loaded as extensions.

The more I compile applications/modules, the more I come across the same problem in that once compiled/loaded, the application/module will not work because the kernel needs patching. Using a patched kernel with DSL/DSL-N would be a pain, but the patches don't start until 2.4.26+ and 2.6.12+ anyway...

In summary there will usually be somebody who can post a "heroic" compilation as an extension (thus no need to concentrate on the applications) but if the kernel will not work for that application then you face a show-stopper (thus better to concentrate on upgrading the kernel).

I think that this will be the approach taken.
First a 2.4.34 upgrade then ...
Some apps upgrade with libs etc.
This will be a phase in approach over several/many future releases.

Next Page...
original here.