Joined: Oct. 2003
||Posted: July 29 2007,23:15
Lets try to stay on topic and positive here. While I may agree, I don't want to start any distro wars.
To the subject at hand:
I am not sure how to respond to this. Am I to take this as an affront to the result and conculsion of the very recent poll which resulted in a consenus of how DSL was to move forward? And now, when work has only just begun on a new interface and improved user experience?
I have many times posted why dsl-n development has stalled. The main of which was lack of community interest. Where DSL forums had an average of 100 users, DSL-N had 5. Five. Where do you think I should have spent my time? Follow that up, with the recent poll and there was not an overwhelming demand for a larger 2.6k DSL. DSL has built its reputation on supporting very low end hardware, the Libettro, and 32MB-64MB machines.
I realize that over time things change, but I am talking very recent. dsl4 is only at alpha1.
I also realize that some in the community want new hardware soultions ASAP.
Given all the above, and if I am not being excluded from this discussion. This is what I would propose...
1. Evolutionary not revolutionary, i.e, do not try to maintain two separate distributions.
2. Leverage what I am currently developing.
3. Leverage existing gtk1 extensions.
4. Leverage existing gtk2 and gtk2 extensions.
I am swamped with work on dsl4, but if one or several in the community, wish to compile a minimal 2.6 kernel, modules, and the core third party modules needed by DSL( ltmodem, unionfs, cloop, ndiswrapper, fuse, prism2, and madwifi). I will incorporate them into another "edition" of DSL.
Most likely this kernel and boot time modules, ide, cloop, usb, and sata will not fit on a single floppy disk. Therefore likely no syslinux edition. Most likely only an isolinux edition.
I would work to automate the process of simultaneously releasing both a 2.4k and 2.6k editions of isolinux DSL.
By adopting this approach, we would leverage current developemnt, use existing gtk1 extensions, easily add gtk2 and gtk2 extensions.
We would offer greater new hardware support while minimizing operational support questions and issues.
This would at least be a start on which we could later begin to update and/or replace core applications and libraries.
Any volunteer kernel builders?
Edited by roberts on July 29 2007,23:38