water cooler :: Would it be time for DSL to shed its skin?



Would it be time to throw away Debian compatibility?

I've watched these threads about non-compatible libs & headers, which are because the extension was made separately from the base.

Also many have wished for updated libs & apps.

A solution for that would be to follow compile-from-scratch philosophy.
If a new base was compiled, it would be up-to-date, small, and work well.

As uClibC has become mature enough to support nearly all apps, it could be used, and that along with optimization for size and 486 for all libs & apps would drop the size of DSL quite much.

Doing something like this would increase the gap between DSL and other distros, like Puppy..

From this new base we could separate a build system, totally compatible with the base without any conflicts.

--
So, to sum up:

Pros: smaller size -> can fit more into DSL
       up to date
       fully compatible build system

Cons: it would be a lot ™ of work
        extensions would have to be redone


For me dropping Debian compat is a pro, but for others it might be a con.. so I didn't list it in either one.

It's a radical idea, not likely to happen, but tell still what you think.
Those are two separate issues: Debian compatibility and whether DSL is in need of overhaul. Both issues are complicated by how different people view DSL.

If it's viewed primarily as a live CD, it doesn't matter what you do or how you do it so long as it works; so nothing needs to be done. If it's frugal or USB or so on, then it needs some minor upgrades to freshen it up enough that newer apps can be compiled for it; it wouldn't require a total overhaul to do that.

The third option is one I think is probably one headed for deprecation because it will eventually require what you suggest, and because it duplicates too many better current alternatives: hard drive install. This isn't DSL's niche, and DSL increasingly pales in comparison to other distros because people want newer versions of apps than are in Woody (or even Sarge -- hence adoption of Ubuntu's repositories instead of Debian's by other distros like Mepis). While MyDSL extensions tend to work pretty well for hard drive installs, that's not how they're intended. And I think more of them will increasingly be in forms (UCI, UNC) not best suited for hard drive installs.

The total overhaul would require far too much work both on the ISO and current extensions. I'm not convinced that newer apps and libraries would be smaller. I'm also pretty sure that in making things tighter with newer (more bloated) libraries, someone would take exception to something being left out that would require recompiling it just to make something with a certain feature. So then we're right back where we started. At least now people can try to grab something from Knoppix 3.4.

So I would say no to a total overhaul and yes to deprecating hard drive installs (even though I have several partitions with DSL installed traditionally) in the very near future. I think Robert's already doing what he can in freshening things up. And maybe this talk should follow the release of 4.0, not precede it.
The HD installs (though i hate them) does serve a purpose for low ram systems.
Did you know ram for old laptops cost twice that of newer ones?
And that's if you're lucky enough to find them!

Having ties with Debian is not necessarily a bad thing.
It means extensions can be easily converted to work on a Debian system.
(I don't know if you can say the same for puppy).

Separating the library from the base system is an interesting idea.
Although I can't think of any benefits and it would probably cause
more confusion with apps having to match the library module.
Unless ofcourse each library upgrade is backwards compatible,
which really defeats the purpose of being small.
A new DSL (like DSL-N) would have to be launched.
Seems to me, that we have already had this discussion.

It is not fair to compare a 2.6 kernel, gtk2 distribution, of any kind, and the applications offered therein, with a 2.4 kernel, gtk1 system like DSL.

If you want/need the latest applications and don't mind the bloat and your computer can handle it, then there are many, last count over 500, linux distributions for you to choose from. Please stop the 2.6 gtk2 comparisions.

Additionally, I tried the DSL-N (2.6/gtk2) route with no Debian and no gtk1. All I got has gripes about not being Debian compatible. Even thought it was never claimed to be. I got much grief because users tried to load gtk1 extensions and of course would not work. I got complaints because no syslinux boot floppy version, and on and on.

Based on these experiences...

I conducted a poll, on the direction of DSL and a newer 2.4 kernel was decided. Realize many things have moved to 2.6 kernel and therefore compiling the latest may remain as issue. I have already run into that with compiling some of the additional non-kernel modules.

Again, it is a matter of what works, what is smallest versus the latest and the inheirt bloat. DSL has always chosen the smaller and what works. DSL supports many smaller memory limited machines.

I realize that I cannot please everyone. With the soon to be released alpha of DSL 4, I have tried to make DSL easier to use with a totally new UI and sporting a 2.4.34 kernel. Many changes throughout. During the alpha cycle, I will likely release with different default configurations. I will do this to showcase the areas that have changed the most.

I am sure there will be some who will hate it and some who will love it. It may take some time to get used to it. And for some, they will see no change at all. It depends on how you run DSL. DSL has always been about offering many choices. And it shall remain so  I am not planning on deprecating any of the major functions in DSL.

So goes the life of a developer. Much work. Little thanks; and even less pay
When I said update, I was thinking about minor updates, like latest gtk1 etc, not moving to gtk2 and linux 2.6.

Building with uclibc makes everything smaller, even when dynamically linked.

--
slightly out-of-topic:

if there's some app that would require gazillion libs not in core DSL, and the extension would grow because of all those, would there be need for a uClibC compiling environment where extensions like that could be compiled statically?

That way they would be smaller than with glibc dynamic linking and no need for starting wrappers etc..
And the result would work on all versions of DSL etc..
Next Page...
original here.