Site News :: Current Issues &



I think that there are more "happy customers" with kernel 2.4.31 than it seems.

This is because you usually only hear feedback when something goes wrong instead of when something goes right.

This non-smp thing stumps me, because DSL 1.5 comes with an SMP enabled kernel.  I see two penguins when booting on my HT Pentium 4 machine.

But if the need to go backwards is still considered to be a must, I would like to make the following request:

Instead of jumping back to 2.4.26 / KNOPPIX 3.4 / DSL 1.5,
can you instead jump back to a 2.4.27 / KNOPPIX 3.7 base system?

This will include the knoppix autodetection scripts for the last 2.4.x version that was supported before the jump to kernel 2.6.x in knoppix 3.8

It will also include SATA support, which will be a big requirement in order for the "Small" DSL to be able to work with just about any modern PC shipped in the last couple of years.

So the end result might be:
Some newer hardware is supported
SATA is supported
More up-to-date KNOPPIX autodetection scripts
Still the same stability as the knoppix 3.4/2.4.26 systems

Is it worth a try?
What about a "dsl-devel" mailing list, ideally hosted on lists.debian.org?
I was very happy with dsl 2.1 and the 2.4.31 kernel.  I loved being able to view my SATA ntfs hard drive again (thanks), and the additions and changes Robert and John have made have been great.  I understand that drivers needed to be written, but look how long it took to get all of the drivers for the earlier kernel.

I think getting two versions working is going to be even more work than getting the 2.4.31 kernel up to speed.  It might be best to stick to your target audience, drop the kernel back, and leave it at that.
Is it possible to add a full X-server in the 2.6 kernel version?
As far as the myDSL extensions are concerned, when they're packaged, why not just add the release number.

That is, if a .dsl of mplayer is packaged for 2.1, write the filename as mplayer-2.1.dsl.  That way, at a glance, the user will know for which release the program was packaged.  That will result in multiple versions of packages if they're incompatible between releases, but if the old package works with the new release, a symlink can point to the old package, or a copy with the new version number can be uploaded.

That would effectivly eliminate the incompatible package problems.

If I get a vote for text-mode browsers, I vote that links-hacked goes back in.  I used links-hacked more than I use firefox (I'm using it right now) and even though it's no longer actively developed, it's extensible with lua, which DSL heavily employs, and even though it's a few megs, it's useful.  I'm sure it's not coming back, but I use the hell out of it, and it'll always find a place in my toolbox until something better comes along.

The only other thing I was wondering about is whether or not we've thought about using upx or another form of executable compression.  Upx will shrink links-hacked to half it's size.  Run that on half a dozen stand-alone executables and we might be able to shoehorn another app or two that previously wouldn't make the cut.

(I wonder how small nvi and zile would be after packing?)
Next Page...
original here.