Release Candidates :: DSL v4.0 alpha1

I wonder what causes the partition size limitations on usb-zip?
This would seem simple to fix.

Robert:

Quote

And finally also provides a more RISOS type of feel.

You might be interested in this interview with Thomas Leonard about rox:
http://www.drobe.co.uk/riscos/artifact2002.html

Quote (lucky13 @ July 25 2007,13:22)

Robert:

Quote

And finally also provides a more RISOS type of feel.

You might be interested in this interview with Thomas Leonard about rox:
http://www.drobe.co.uk/riscos/artifact2002.html

As you know, I was ready to do a Rox/DSL system. I have developed a prototype. However, I have just too much legacy stuff to support to continue its development.

Also, as I have mentioned, all the additional directories, cause excessive inode use, which impacts the very very low memory systems. I would not be able to support these very low memory systems.

Also you can see, some of the feedback on DSL 4, from long time DSL users is not glowing. To change the UI after 4 years is difficult. Even though there are boot options to make the impact minimal. If I had done only a Rox/DSL I think I would lose many traditional *nix users.

Given both of the above situations and having spent the time to prototype Rox/DSL inspired me in my implementation of dfm and my xxx.app wrappers to emluate a Rox-like DND experience using the dynamic loadable MyDSL extensions.

I could have certainly gone off in another direction, using only UCIs, a natural for Rox, do a live CD Rox/DSL. But I would lose to many users and small machines.

There are parts of Rox that I do not especially like. For example, every program executeable is named AppRun. You use the directory name to find the actual executeable. My spin was to use xxxx.app, so that I can still easily use my unix tools to find executeables. I also do not like large taskbars and pagers. I like to save screen real estate for the task at hand. I have many small screen systems. The latest Rox is all Gtk2 and that is even more bloat.

What I have tried to achive with DSL 4.0 is to cover the spectrum of operational use from application centric to document centric.

Prior DSL versions where application centric, i.e., menu driven. Icons were only a convenience as application "start" buttons.

DSL 4 still supports this application/menu driven mode. But I wanted to introduce document centric/icon/DND mode of operation. I want to have this implemented as far as possible, i.e, no "application menu" needed (swm).

Having to support all previous operating and installation modes of DSL is a challenge, while still supporting the smallest of machines that were previouly supported and remain under 50MB. As well as still be able to leverage the MyDSL repository.

I don't want to bloat up. I don't want to be a small distro that requires 128MB+ to operate. Even if THAT (128MB) is new low-end machine.

And partly, I just wanted the challenge to try to implement this within the existing framework that I have built upon over the last 4 years.

Perhaps, it is time to make DSL bigger. But I am still having fun with this one. Perhaps a larger one will be based on this one. For now, lets work to improve DSL 4 and its many modes of operation.

Quote

There are parts of Rox that I do not especially like. For example, every program executeable is named AppRun.

That's the part that's driving me crazy now, as I'm pulling my AppRuns from wrapper AppDirs and renaming so they can be used for dfm. I posted another video showing my shredder in action in DSL 4:
http://lucky13linux.wordpress.com/2007....r-video

Quote

I want to have this implemented as far as possible, i.e, no "application menu" needed (swm).

That definitely will be more RISCOS-like than using fluxbox or jwm. I haven't tried swm, but it sounds like it has almost as many features as oroborus.

Quote

Perhaps, it is time to make DSL bigger.

Heresy!

Quote

Perhaps a larger one will be based on this one. For now, lets work to improve DSL 4 and its many modes of operation.

I'd rather see DSL-N pick up where we left off since it's tied to being bloat-free rather than having a specific base size limit. I don't think DSL needs to grow to maintain its relevance and utility -- you've already proven that. Moving DSL-N along a rox-ish path would make more sense to me since it already has GTK2, could justify using python instead of lua, etc., and that way the legacy DSL users won't be put off. It could be a clean slate using CRBs.

I think that the problem with using an SATA DVD-ROM/CD-ROM is that the libata module for 2.4.34 needs atapi_enabled=1 before the drive will be recognized.

I guess that it will need to be added to the miniroot.gz so that the DSL image can be found on a SATA CD-ROM drive.

This page has some info on this for the 2.6 kernel:

http://www.thinkwiki.org/wiki....ognized

Next Page...
original here.