DSL Ideas and Suggestions :: wish list for the new version, dsl 5.0



Has uclibc been considered for tinycore?
uclibc could make a great deal of size difference for tinycore. And as tinycore is built entirely from source, compilation with uclibc could be possible, couldn't it? Also as tinycore is a departure from previous DSL version, I believe compatiblity is much less of an issue.

If anything is required to check if tinycore would benefit from uclibc, I'm willing to give a hand.

DeliLinux (http://www.delilinux.de/) is a mini desktop linux distro using uclibc and according to the website runs all its graphical apps smoothly with a 486 and 16Mb Ram.
Maybe this was mentioned, but I don't remember....
Would existing extensions be compatible with uclibc? If not, it would be a big problem.
I guess I had been thinking that DSL 5 would be a big enough departure from the other versions that new extensions would need to be built. Many of the existing extensions wouldn't be attractive to use because the new structure of the core will allow the use of much more updated versions of the apps in the existing extensions.

Does this sound right?

Chris
My thoughts are that even though there are many extensions that would have to be rebuilt or just reworked for the 5.0 series anyway, going with uclibc would increase the headache factor of building extensions quite a bit.  Even if the base system worked well with it.  And many things like Opera that are only available as binaries would not work or work poorly.  That seems to be the reasons Puppy Linux ditched uclibc earlier:

http://www.murga-linux.com/puppy....fe37754

I only have had brief experience with uclibc, so if I am wrong or if anyone else has had a more pleasant experience with it I would like to hear.  Uclibc, like busybox, has its place and purpose.  But I far prefer dealing with glibc if I have a choice.
My limited experience with uclibc was frustrating, too. It's not a 1:1 replacement for glibc. Most programmers of commonly used applications and utilities write with a presumption that their code will be compiled against glibc.

I don't think average users should have to learn C to tweak *standard* code so they can compile against a non-standard library when the same *standard* code will compile using standard tools and libraries. What may be ideal or acceptable in an embedded environment doesn't always scale well for desktop use (and vice versa -- which is why uclibc and dietlibc and so on exist). Unless there's a primary goal of making tiny core oriented for embedded use (I hope it remains targeted at desktop computer use), I hope we can stay away from uclibc.
Next Page...
original here.