DSL Ideas and Suggestions :: wish list, 2.6

As you can imagine, I have been very busy with the launch of my retooled v4.x series. The last several releases have been to stablize the series based on community feedback. With over 750 extensions and all the incarnations that exist within I needed feedback to better support them.

I have been reviewing several frameworks and have protoyped a couple. Currently I am leaning away from Debian and more towards Slackware.

On a personal note, I am struggling with my Muscular Dystrophy and its effects on my vision due to extreme ptosis. I will be scheduling surgery to try to correct. Don't know how long that will put me down.

Quote (roberts @ Dec. 02 2007,18:16)

I will likely call upon the community to become more involved when it comes to support of devices and hardware that I cannot afford or have access.

Quote

I will likely call upon the community to become more involved when it comes to support of devices and hardware that I cannot afford or have access.

Any devices and hardware in particular? Hopefully not too pricey?

The thread is called wishlist afterall.

Quote

On a personal note, I am struggling with my Muscular Dystrophy and its effects on my vision due to extreme ptosis. I will be scheduling surgery to try to correct. Don't know how long that will put me down.

- best of luck with that.

Update:

I have been prototying various builds and want to share some of my thoughts with the community.
I am considering a non unionfs kernel 2.6 system for the next major DSL version..
Currently I am booting a prototype 36MB Knoppix 5.1 kernel and modules without unionfs.
It boots to JWM/DFM with all my Lua and custom Bash scripts. Other than that it is currently app-less.

DSL up to and including v2.4 did not have unionfs.

Community member clacker first created a unionfs.dsl extension to add unionfs to DSL.
So that could still be an option for the new version. There is also a fuse based overlay available.

Many of the DSL community seem to shun unionfs. It is too buggy even in newer releases.

To quote from the:
February 2007 Linux Storage and Filesystem Workshop:
"Some of these issues stem from the fact that the Linux Kernel has not been designed with stackable file systems in mind.

In hindsight, I sometimes wish I had not included unionfs into DSL. I am so glad that I have maintained a "legacy" style boot. As it is far more reliable.

Current count in the repostory is
53 unc
182 uci
463 dsl
237 tar.gz

There has been alot of recent builds of uci. Very little new unc.

My original concept of self-contained applications via iso/cloop was spot on.
Later, I see Klik using the same concept except they use cramfs.
Then I see zeroinstall being developed by rox group.
I see Gobol also trying to promote "chrooted build" self-contained applications.
PCBSD has PBI, similiar concept. And Macintosh uses self contained application folders.

All of these validate my early idea. My first DSL extension was called a .ci (compressed image)
I released .ci and .tar.gz as the first example myDSL extensions to the DSL community.

I actually was against the mkwriteable script used in DSL. It was only because of the challenges of building self contained applications that I added mkwriteable into DSL. Doing so caused a flood of new .dsl extensions.

I am thinking to wait out the unionfs/aufs/posixovl for better support. But I am also still wanting to promote my original concept of uci and see how it fares with the new knowledge that our community has built upon.

Have you see the gymnastics in the new knoppix-halt, knoppix-reboot scripts to try to handle busy inodes caused by stackable filesystems? It was the reason that I disabled tyring to un-mount a unc in DSL.

I guess I could delay a new build of DSL until stackable filesystems are better supported. But I am thinking a non-unionfs DSL might be a success. It would boot with mkwritable defaulted so we would still have all the current capabilities of a "legacy" booted DSL.

Comments

-- Robert

I just sent you a note updating my progress with Knoppix 5.1. Or lack of it. I did update the toolchain, though, and the Debian kernel (2.6.23.1) is a lot faster to download than to compile on this old wreck.

I wouldn't object to moving apps from the base to MyDSL. That was one of the things I lobbied for in DSL 4 -- I'm openly very biased in that direction. Doing so now would allow you room for more modules so both legacy and new hardware can be as evenly supported as possible. Your kernel is already way smaller than the Knoppix 5.1 one:

Code Sample

$ du --si --max-depth=0 /lib/modules/2.6.19
69M /lib/modules/2.6.19

And this is the update I did at Debian earlier today:

Code Sample

$ du --si --max-depth=0 /lib/modules/2.6.23-1-686/
55M /lib/modules/2.6.23-1-686/

My first 2.6.23.14 (gcc 3.3.4 against the base c lib in DSL) with *every* possible module was just over 80 MB. But I know you won't include bluetooth and irda in the base.

Moving more apps to MyDSL would also afford users more choice -- GTK1 versus GTK2 Firefox, Opera, etc. -- without duplicating what's already in the base.

Next Page...
original here.