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

good feedback, guys. I am not great at compiling anyway, so I was not aware of the pitfalls.

Obviously, we want extension building to be a fairly straightforward process so that the community will be able to contribute without becoming frustrated with an overly difficult process.

Chris

I think curaga linked to detaolb, which is a Linux 2.6-based live CD (targeted at embedded/virtualized environment use) that uses uclibc. I downloaded it to check it out some time ago but never bothered burning to CD. I just mounted it to see if I could see what came with it and was surprised at the number of included apps ("modules"). Obviously, uclibc can be made to work in such an environment. I just don't know if the size savings would be worth the aggravations of compiling everything against a non-standard C library.

If anyone wants to look at detaolb (and maybe compare file sizes and such between it and DSL where possible), its link is:
http://detaolb.sourceforge.net/

My impression of uclibc was generally positive; I got space savings way above those mentioned in that Puppy thread, about one third at best. It had some outstanding bugs however, which prevented me from going forward with it. They have since been fixed in cvs, but other stuff has probably been broken, and there has been no new release since May 2007.

I have not played with uclibc, so I don't have experience of it yet. But if ublibc is a compliant standard libc implementation, I'd be suprised if a lot of apps wouldn't be able to compile with it. Also if uclibc is provided in the base, a glibc.dsl extension could probably be provided for the apps that prefer to be linked against glibc.

I'm not necessarily asking that DSL would be uclibc-based. I just thought that as tinycore is being prepared, it's perfect timing to give it some thoughts as this is the type of idea that really could push the envelope. Well, I'm happy I've raised the subject as there are already quite many opinions here.

All libs would need to be compiled for the specific libc, so a glibc.dsl would become quite huge, not to mention it would need to have a different prefix to avoid overwriting all libraries expect libc.

Next Page...
original here.