DSL Ideas and Suggestions :: wish list, 2.6

Sounds cool, i really like the fact u chose that 2.6.24 kernel, i think the rt2500 wireless chipset drivers are included in that one, and that would mean that i am going to put 5.0 on my newer laptop

Anyway, as far as i can read, dsl 5.0 is going to be just a core dsl with X and some small apps? Thats cool

. Would be easier for u to keep dsl in the 50mb limit, and easier for us to install new programs and customize dsl for our daily use

I also will be happy to have a core, small Base-DSL and the rest as extentions.
Frank

Quote

I also will be happy to have a core, small Base-DSL and the rest as extentions.

I think it will be well-suited for most hardware already using DSL depending how users intend to set it up. That's one of the things about modularizing it as much as possible that makes it accessible to more users, regardless of targets in the 256/512+ MB RAM area. It's still useful below that if users are mindful about what all they stack on it.

I've been tweaking things to reduce resource drain (using another supposedly "light fast" distro) on my laptop, on which I never wanted to run 2.6. I've made a big dent but still have plenty room to go. But it's definitely an improvement over the default install. I'm kind of in a holding pattern for Robert to release before I go much further in reducing the footprint/demands of what I'm currently using (or making the packages available as a low resource slackbuild).

Update:

Still making progress on the tiny core. Based on observations, both my own, and recent remarks. Some directions that I am working towards...

I want to try to address many of the older computers that DSL has traditionally targeted. The most often reason cited, from those who know frugal yet still perform traditional hard drive installation, is the slowness from running from compressed read-only images. I now find myself experiencing such with the very large Firefox v2.

Yet I am pleased to see that many are contributing UCI type extensions. With the new system, I want to run those uncompressed. The UCI will morph into mountable application directories. Only the download delivery method will be compressed (TBD). I am planning on only supporting two extension types, our traditional .dsl, which is really a gzipped tarball with menu and optional icon. The second will be the mountable application directory.

Doing this should provide a boost in performance. With the physical size of pendrives ever increasing, and all that unused hard drive disk space, storing and running mountable uncompressed applications seems natural.

Also is the advantage of avoiding the issues with read-only. No more sym linking out to a writable area. Yet still we have the advantage of simple removal of either the .dsl or the application directory.

For those with much ram, use .dsl, and those without use .map (Mountable Application Directory)

Currently I am running a mix of tradtional .dsl and mounted application directories with better results than everything in compressed loops.

I can easily switch 'flavors' by boot options.

Quote

With the new system, I want to run those uncompressed. The UCI will morph into mountable application directories.

Sounds RISC-y to me.

Next Page...
original here.