Search Members Help

» Welcome Guest
[ Log In :: Register ]

Mini-ITX Boards Sale, Fanless BareBones Mini-ITX, Bootable 1G DSL USBs, 533MHz Fanless PC <-- SALE $200 each!
Get The Official Damn Small Linux Book. DSL Market , Great VPS hosting provided by Tektonic
Pages: (8) </ [1] 2 3 4 5 6 ... >/

[ Track this topic :: Email this topic :: Print this topic ]

reply to topic new topic new poll
Topic: Would it be time for DSL to shed its skin?, some ideas< Next Oldest | Next Newest >
curaga Offline

Group: Members
Posts: 2163
Joined: Feb. 2007
Posted: July 13 2007,18:11 QUOTE

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.
Back to top
Profile PM 
lucky13 Offline

Group: Members
Posts: 1478
Joined: Feb. 2007
Posted: July 13 2007,19:22 QUOTE

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.

"It felt kind of like having a pitbull terrier on my rear end."
-- meo (copyright(c)2008, all rights reserved)
Back to top
Profile PM WEB 
humpty Offline

Group: Members
Posts: 655
Joined: Sep. 2005
Posted: July 13 2007,21:08 QUOTE

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.
Back to top
Profile PM 
roberts Offline

Group: Members
Posts: 4983
Joined: Oct. 2003
Posted: July 13 2007,22:24 QUOTE

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
Back to top
Profile PM WEB 
curaga Offline

Group: Members
Posts: 2163
Joined: Feb. 2007
Posted: July 14 2007,07:13 QUOTE

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..

There's no such thing as life. Those mean little jocks invented it ;)
Windows is not a virus. A virus does something!
Back to top
Profile PM 
37 replies since July 13 2007,18:11 < Next Oldest | Next Newest >

[ Track this topic :: Email this topic :: Print this topic ]

Pages: (8) </ [1] 2 3 4 5 6 ... >/
reply to topic new topic new poll
Quick Reply: Would it be time for DSL to shed its skin?

Do you wish to enable your signature for this post?
Do you wish to enable emoticons for this post?
Track this topic
View All Emoticons
View iB Code