DSL Ideas and Suggestions :: wish list for the new version, dsl 5.0



Quote (humpty @ May 25 2008,14:41)
Quote (curaga @ May 25 2008,21:18)
I guess the difference between a .map and a .tar.gz is the unpacking - saves time just to mount.

Seems to me like the only advantage for compression is for smaller
files for distribution. The files have to reside somewhere eventually,
and compression would only benefit the older devices with limited
capacity, say a 10MB hard disk. The programs all load to ram at
full space don't they? (perhaps I am wrong here).

Hence stay with tar.gz for distribution and go for permanent self-contained installation.

Also, is it possible for mydata.tgz so that the backup files can be
manipulated in freedos (8+3) ? (infact, is fat16/32 still on the cards?)

I will adopt the 8.3 and call it mydata.tgz.

I am mainly supporting the .tgz extension type. But my thoughts on the self contained are the following:

1. There is a difference from the usually static collection of files and directories that make up an extension and their run time memory consumption. With a tgz both the actual files and directories and the run time would consume memory. Fine for large memory system.  Bad for small memory based systems.

2. Self contained applications, or application directories could be stored on persistent media in their native state as files and directories. Only then when invoked do their run time memory demands come into play. This should greatly reduce memory demands. They would need to be mounted to become part of the run time filesystem.

3. In regard to number 2 above, I was thinking of a highly compressed download and then store uncompressed and in a write enabled state. We could stay with using mountable iso9660 read-only images. But what would be the benefit? Perhaps the benefit is that the write enabled areas that we have already become familiar with are more easily included in the backup if links are created to a single simple location. Otherwise one would have to maintain a growing filetool.lst file. I am still open to ideas here. I plan to release an early alpha with only number 1 supported.

i really think that madwifi is the solution for the eee pc. what do u mean? or is it better to wait for a new version of damn small linux?
Quote
i really think that madwifi is the solution for the eee pc. what do u mean?

This can't be targeted at specific computers; it has to be broad enough to support lots of computers. With the size of the 2.6 kernel, that means that some support will come from MyDSL module extensions rather than be included on the ISO.

If I'm reading Robert correctly, it wouldn't support specific hardware straight off the ISO aside from the most common hardware (e.g., PCI, USB, etc.). You'd download the ISO and any peculiar drivers (modules) you need from MyDSL. If you need madwifi, you'd download that separately from the ISO but probably burn it to the same CD like the MyDSL remaster script. That way you can run bootcodes or bootlocal for your particular modules.

In a sense and assuming it's comparable to DSL status quo, you'll end up with a CD (or frugal install or USB-HDD) that will be relatively personalized with only what your computer requires rather than a lot of modules you don't need.

I don't know if you've compiled one of the more recent 2.6 kernels, but it's too bloated to include modules for every possible wireless device.
Quote (roberts @ May 25 2008,14:48)
Quote (humpty @ May 25 2008,14:41)
Quote (curaga @ May 25 2008,21:18)
I guess the difference between a .map and a .tar.gz is the unpacking - saves time just to mount.

Seems to me like the only advantage for compression is for smaller
files for distribution. The files have to reside somewhere eventually,
and compression would only benefit the older devices with limited
capacity, say a 10MB hard disk. The programs all load to ram at
full space don't they? (perhaps I am wrong here).

Hence stay with tar.gz for distribution and go for permanent self-contained installation.

Also, is it possible for mydata.tgz so that the backup files can be
manipulated in freedos (8+3) ? (infact, is fat16/32 still on the cards?)

I will adopt the 8.3 and call it mydata.tgz.

I am mainly supporting the .tgz extension type. But my thoughts on the self contained are the following:

1. There is a difference from the usually static collection of files and directories that make up an extension and their run time memory consumption. With a tgz both the actual files and directories and the run time would consume memory. Fine for large memory system.  Bad for small memory based systems.

2. Self contained applications, or application directories could be stored on persistent media in their native state as files and directories. Only then when invoked do their run time memory demands come into play. This should greatly reduce memory demands. They would need to be mounted to become part of the run time filesystem.

3. In regard to number 2 above, I was thinking of a highly compressed download and then store uncompressed and in a write enabled state. We could stay with using mountable iso9660 read-only images. But what would be the benefit? Perhaps the benefit is that the write enabled areas that we have already become familiar with are more easily included in the backup if links are created to a single simple location. Otherwise one would have to maintain a growing filetool.lst file. I am still open to ideas here. I plan to release an early alpha with only number 1 supported.

What about onthefly loading? Instead of downloading, saving to /tmp, then loading it with mydsl, can some packages (tgz or dsl) just be piped from wget to tar?
Code Sample
wget $dslpackageurl -O - | tar -xzvf -
Quote
What about onthefly loading? Instead of downloading, saving to /tmp, then loading it with mydsl, can some packages (tgz or dsl) just be piped from wget to tar?
That would be *really* harmful when your connection snaps out, or you get a corrupted file..
Next Page...
original here.