Why not uClibc?

[lordtangent]

Could you share any reasons why you rejected uClibc and went with regular glibc instead? (I'm hoping to avoid frustration if there are technical reasons why uclibc wouldn't be a good idea!)

And could you also clarify if all the bins are static. (I'm assuming they are but I figured it would be easier to just ask!)

The reason I'm asking is, if stuff is static (as I assume it would be considering how Tiny seems to work) I may try and do my own custom version of Tiny by just replacing a few of the binaries with uclibc versions compiled in my own env.

[curaga]

No binaries here are static, not in the base or in the extensions. That would bring a huge size increase (I recall a hello world statically with glibc is 600kb..). However if you compile your own binaries statically with uclibc, they will work here too ignoring the shared glibc.

[lordtangent]

Cool. Thanks for the info!

Maybe Roberts can explain why you guys shun uClibc. It seems like it would be a great fit for the project but I'm sure you have your reasons.

[mikshaw]

According to roberts, "I opted not to use uClibc and the external cpio for easy remastering."
I assume that means he thought it would be easier to allow people to import binaries from other distros rather than having to build everything from source for uclibc.  This would also apply to extensions...I'm pretty sure there are some that were built from Debian or Slackware packages.

[lordtangent]

That makes sense. Though the extra RAM and disk savings might still be worth the extra effort of going with uclibc.

Building stuff with uclibc is actually pretty easy under the embedded branch of Gentoo.  In the past what I've done is keep a separate uclibc "tree" and then chroot into it for compiling. But you could just as easily create a fully bootable setup and use it to host development sessions.

Huh... I just thought of a totally crazy idea. As I have already read on the forums (and it seems to be reiterated over and over) "There are no build scripts or environments for Tiny Core" ...  But what would be possible is  to create a Gentoo "ebuild" for the entire Tiny Core. There are your build scripts right there.  A distro hosted in a distro!

Add a couple or wrapper scripts (That could parse the ebuild to get the binaries to make the initrd, TCE/TCZ) the and at that point making new TCE or TCZs from anything in the Gentoo Portage tree would be trivial. Building the whole thing under uclibc would not be too tough.

Just an Idea. Not saying I'm quite ready to bite it off myself but I am considering it! (It would still be a lot easier than trying to totally re-create Tiny Core from scratch)

[jpeters]

I don't know if this would present a problem:

" uClibc does not even attempt to ensure binary compatibility across releases.
When a new version of uClibc is released, you may or may not need to recompile
all your binaries."

[roberts]

mikshaw, quoted my response correctly.
I opted for glibc to allow users to easily add in binaries and not have to be source based.
Even though, we won't host binary only extensions, because of GPL, I wanted to be perhaps, a little more open for the user community. I am still happy with this decision.

[lordtangent]

@jpeters

That could be a a problem.  Of course, if the commitment was made to uclibc you could Just lock on a version of uclibc.

@roberts

I've been thinking about my particular interest in Tiny (making an ad hoc disk-less grid / render farm that can boot off a Thumb Drive and not touch the hard drives of the host machine) uclibc is totally inappropriate for what I ACTUALLY want to do as it needs to be compatible with commercial software I can't count on being statically linked and/or OSS software (like ffmpeg) that might be too complex to get compiled correctly under uclibc. Not to mention the likely performance hit of compiling high performance software under uclibc.   I imagine pretty much the same circumstances are true for 99% of the uses most people have for Tiny Core. Your choice to go with regular glibc for the vanilla Tiny Core is a really good choice now that I hear your reasons and think about it a little more. It's amazing you can still keep it as small as you do!

I am however still fixated on the idea of uclibc for the purely academic interest in shrinking Tiny even further, just to see how small the core could actually be made.

[jpeters]

..let me know if it works with flash10 

[tobiaus]

..let me know if it works with flash10 

you're probably joking, but perhaps a version of uclibc in a hypothetical getflash10.tce (i think we should keep the older version too) would be worth it, if uclibc has anything to do with it.

[roberts]

Tiny Core could be smaller by using lzma compression, but then it is not just about delivery size. Performance weighed heavily on our decision to stay with gzip. The difference in boot times were very much impacted when lzma was used. Again, I am happy with the decisions that were made for Tiny Core. A balance of size and performance that servers a wide spectrum of uses.

[curaga]

Not sure either if you were joking, but as Adobe Flash is a binary linked against glibc...

[jpeters]

Not sure either if you were joking, but as Adobe Flash is a binary linked against glibc...

That's why I started using the smiley's.....

[lordtangent]

Tiny Core could be smaller by using lzma compression, but then it is not just about delivery size. Performance weighed heavily on our decision to stay with gzip. The difference in boot times were very much impacted when lzma was used. Again, I am happy with the decisions that were made for Tiny Core. A balance of size and performance that servers a wide spectrum of uses.

Tiny Core is so small already, making it smaller doesn't seem worth it at the expense of a speed hit. However, for my particular application it might make sense to create the "payload" binaries as a LZMA image, to save on RAM. (The image would be copied to memory before mounting so this is a case where compactness would be more important than speed. The binaries would be used in a non-interactive capacity, so a slight speed hit would never be felt by the user.)  How much sense LZMA would make depends on how  big the payload ends up being. Depending on plug-ins, etc, it could end up being pretty large.

Does the current kernel still support LZMA?

My concept  for customizing Tiny Core is to  package the scripts/tools required to BUILD the images needed as a TCZ. The tools would help the user make a bootable USB stick with their renderer bundled in a TCZ (since I can't re-distribute the commercial renderer) It would also include wrappers or a basic gui to configure the lave nodes as required. (though if everythign works correctly that could be automatic)  This would be for Lightwave Core, the next generation version of Lightwave 3D (Core is really the name!). Lightwave historically provides free (as in beer) network rendering and this new version  will have a Linux native port. Anyway, I don't know exactly what LW Core will require from a distro just yet (it still hasn't shipped) ... but I figure I can at least start familiarizing myself with Tiny Core now so I'm ready to tweak it and hit the ground running once LW ships.

[tobiaus]

Tiny Core is so small already, making it smaller doesn't seem worth it at the expense of a speed hit.

i agree.

However, for my particular application it might make sense to create the "payload" binaries as a LZMA image, to save on RAM.

i like the way you think. there is an unlzma in /usr/bin if that helps, but it would probably require changes in tce-load, or some fancy packaging to use an lzma image inside a normal package.