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



I haven't voted yet either (still thinking), but I would probably like a 2.4 upgrade first.  As for the libs, that is welcome as well (particularly the libc.. but that may cause a decrease with woody repository compatibility?).  And the tiny core would be nice to have, but I don't see that coming.

Since 2.4.31 was reverted to 2.4.26 due to incompatibility with some old hardware, will a 2.4.26 version also be offered in addition to 2.4.34?
Personally, I am running a live version that contains both, but the size is considerably large with the added modules (and this doesn't even count the additional modules that DSL contains for other devices).

One of my ideas (reminder: this is just me testing things out) is to separate the modules from the rest.  For example, KNOPPIX/KNOPPIX and a KNOPPIX/MODULES.  That's okay so far changes are transparent to the user.  Where I can see this come into play is the ease of switching kernels+modules, and toram.  Right now toram will load KNOPPIX to memory, but this way you won't have the uneeded modules also stored in memory (saving 8-16 mb?) and they're mounted in MODULES loaded.

This method could _possibly_ open up for toram use in lower-end systems.  Of course, there's probably many problems and questions with this that I can't see right now.  Like if someone wants to eject the media, is it safe to unmount MODULES?  (probably have to modify modprobe, insmod etc. then to ask for the media).  This is possibly off-topic so I'll back off now :P
I am in favor of backporting and maintaining DSL 2.4.26, whether it will be called 3.4 or 3.3.1. In fact I plan on another 2.4.26 release before releasing anything else.

As long as there is interest in DSL classic I will maintain it. I have learned from the 2.4.31/dsl 2.x.adventure to not do otherwise.

I also have a PXE version of DSL that I will likely post as an additional image. Many have been asking for this. This will mean that I have 5 versions (images) of DSL.

You are right about breaking Debian Woody with these phased in updates. That is really the big question.  Is the effort worth it, If it means no Debian Woody compatibility? These are issues that John and I are discussing and why I posted this survey. It seems to me, that one of the big factors in our decision on 2.4kernel version is how important is Woody.

I could also start anew with Debian Etch but that would likely be a much larger system. Trying to maintain current Debian compatibility seems to necessarily imply more bloat, which is contrary to the original design of DSL

And then there is DSL-N which I have already stripped to a tiny core that has more current libs and could be updated to the latest 2.6.20. I just recently updated Lua and all the Lua scripts.
ok... I never read all 12 pages of comments, so feel free to flame me... :)

Here is my take on all this. I think that the 2.4 kernel is fine. 2.6 is bigger, and I am not 100% sure what we would gain from it. I also think that removing any programs that are not needed in the base is a good idea. Just keep the stuff that absolutly needs to be in there. We can make extentions for anything else. The way extentions load on boot is nice, and mostly transparent anyway.

Now for my opinion on Woody... The stuff you can install from apt is almost 2 years out of date. Building stuff from source really isn't that hard. I made a dev extention with my gtk2 stuff, so really, that is the hard stuff anyway. GAIM and most other apps are cake. I think at this point if we are going to have anything that is even remotly up to date, it needs to be built from source anyway. If the extentions are all 2 year old programs, people won't want to use DSL execpt for verry special applications. Every extension I have made useing the Woody stuff has resulted in allot of bugs, or huge dsl/unc files. Ya, apt was a nice invention, but isn't that really what dsl/uci/unc is anyway?
Glad there's no move afoot to lose the heart of dsl - a mean little 50MBs for which stability, completeness and lightness are the dominant requirements.  I like new packages where these make a big difference eg media players, encryption etc.  But for the vast majority of basic CLI apps, it's not always easy to see what you get by upgrading to bigger and fatter.

Lately I've been looking at Puppy and I'm struck by just how different the two approaches really are.  Different.  Puppy has the whole modular, scalable thing really worked out, though the resulting diversity of releases (many by community members, with Barry's blessing) is initially confusing.  It takes a while to work out what you are supposed to be downloading! But the lesson there is that the diversity has tended to strengthen the community, rather than weaken it (the forums are very strong), and has attracted very committed developers ready to take over when Barry reduces his role (apparently planned to be at the end of the year).   And their repos are a bit of a mess - there's unofficial packages all over the place and it;s hard tok knwo what works and what doesn't.  DSL's centralized repo with testing is to be applauded.

John Murga produces a small Puppy, but I don't think there's any doubt DSL remains the No1 50MB ruling distro.  Once you get bigger though, Puppy has a lot going for it.

DSL is simpler and cleaner in many ways, but without Puppy's gui niceties (they have some nice - if perhaps verbose - guis, which are very appealing to newbies but of passing interest only to geeks.

The simple purity of DSL's uci/unc system also really shines - the equivalent in Puppy have to be loaded during boot, and can interact buggily with their regular packages (so I discovered to my chagrin).  But I like Puppy too.

A scalable DSL-N could give Puppy a run for its money though in the 2.6.xx area.

Anyway I thought some of these comparisons might be helpful.
I have an idea for that KNOPPIX/MODULES approach. Why not mount the modules dir by supermount? It's a readonly cd, and supermount umounts stuff automagically when the media is removed, and if writing is in action, it won't let you eject the media (though that's not possible with floppies).

Then if one tries to modprobe/insmod something, it tells module isn't found, and this is the only part we need to change. It's a lot easier changing only a print line, not touching the source. It could be changed to "Module <mod> not found, you sure the cd is still in the drive?"
Next Page...
original here.