The Holy Grail (of computing?)

Carl SHAW carl.shaw at st.com
Wed Sep 5 08:40:39 UTC 2007


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rob Landley wrote:
> On Tuesday 04 September 2007 11:12:55 am Mark Shelby wrote:
>> I enjoyed reading the discussion regarding (in)activity with the
>> project. I have been watching the whole uClibc/buildroot project for
>> several years now. I have joined and exited the list a few times. I
>> recently got interested again in uClibc and figured I'd check out the
>> progress...
>>
>> I am dismayed that it is still in a "pre 1.0" release stage!
>>
>> So I thought I'd just throw out a few questions to anyone on the list
>> and see what kind of responses we get. Keep in mind, I am not a
>> developer, nor am I advocating drastic changes in uClibc. I just
>> wanted to throw out a few thought provoking questions.
>>
>> I know that the *typical* answer is to go to www.uclibc.org and look
>> at the answers for myself, but I don't think I'ld get as complete an
>> answer as I will in discussing it here.
>>
>> I'll first make a few assumptions. For purposes of discussion I am
>> going to consider a uClibc system as "Busybox / uClibc / buildroot" in
>> companionship or combined with one another.
> 
> I don't use buildroot at all.  Lots of other projects (like Gentoo Embedded or 
> my own Firmware LInux) use uClibc but not buildroot.

I agree with that - I work in the commercial embedded Linux market and
most people I'm aware of in it actually use an embedded distribution
containing uClibc that isn't based on buildroot.  We produce our own
embedded distribution (ST Linux) mainly for the SH4.  Our customers seem
to like "packaged" software rather than one great big tarball (or most
of them anyway).

> 
>> If you chose to single out 
>> one aspect over another, please point out if you are addressing the
>> project as a whole, or one of the three aforementioned components.
>>
>> 1.) Who is the target audience for a uClibc system?
>>
>> Seems to me that I read that the primary target is for the embedded
>> market. Does that still hold true? Or has the embedded market passed
>> on uClibc. Either way, I'm looking for some real in depth answers. not
>> just "Oh, anybody could use it," stuff.
> 
> The embedded market uses uClibc heavily.  I don't consider it restricted to 
> that though, it's a nice fit for bootable CD distros (where an extra megabyte 
> or two of free space is still noticed), and in general it's nice to have a 
> simple, readable C library.  (Being tied to a single implementation is bad.)
> 

The embedded market is strange - because ram is relatively cheap and
performance is an issue, a lot of embedded systems still use glibc (e.g.
Maemo).  What we have found recently is that more of our customers are
now using our uClibc (or migrating to it) since we wrote our uClibc NPTL
support.  I guess they are finding less glibc/uClibc differences or
better thread performance now with their multi-threaded apps?  Our next
distribution release will have all our packages (about 400) in both
glibc and uClibc versions.  The hype around GPLv3 may also have had some
impact in the commercial world.

>> 2.) What other needs (niches) might the uClibc system meet? When
>> thinking of other applications for uClibc, why not rank them in order
>> of "coolness?" (Very subjective, I know!)
> 
> Because it sounds too much like work?  (Well you asked.)
> 
>> 3.) How heavily is uClibc tied to GNU software?
> 
> Not at all.  One of the long term goals of my Firmware Linux project is to 
> come up with a Linux system that has no GNU software in it, not even in the 
> build toolchain used to compile it.
> 
>> 4.) How does this project feel about the proposition of Mark
>> Shuttlesworth to engage in a predictable 6 month release cycle?
> 
> "This project" doesn't feel anything, but some of the developers consider that 
> a very good thing, and I used to send Erik (the previous maintainer) cakes to 
> try to stimulate new releases (the first one was to commemorate the one year 
> anniversary of the 0.9.26 release).  The Linux kernel is also aiming at 
> regular periodic releases, and BusyBox is doing this too.

- From our point of view having a development branch with stable releases
on a predictable cycle would be ideal.  But (unfortunately) it is
already what we have to do internally these days for uClibc.

> 
>> 5.) What do mailing list participants for uClibc system feel is the
>> most crucial step(s) needing to be taken to maximize the usage or
>> stability of the uClibc System?
> 
> *shrug*  I try to use it to build lots of packages, actually use the results, 
> and send in bug reports.
> 
>> 6.) What are the greatest 5 inherent strengths of the system? What are
>> it's 5 most glaring weaknesses?
> 
> You have a homework assignment?
> 
>> 7.) Is the system "developer friendly?" Why, or why not? If yes, what
>> can be done to encourage more participation? If no, what fundemental
>> things need to be changed?
> 
> Explain the nature of the universe.  Provide three examples.  Go.
> 
> I consider Firmware Linux relative developer friendly (and if it isn't I'd 
> like to hear about it).  I consider uClibc a low-level component that by 
> itself does nothing.
> 
>> 8.) As far as "philosophies" go, would this project more closely align
>> itself with the Free Software Foundation group or the Linux Foundation
>> group? If you had to pick one or the other, that is...
> 
> I'm Open Source, not Free Software.  I actively oppose the FSF on several 
> points (such as deprecating GPLv2 in any way, and Stallman's GNU/Linux/dammit 
> campaign).  I think the Hurd failed, Linux would have happened without him 
> (obvious if you study the history, it forked off of _minix_, not GNU), and 
> Stallman needs to get over it.
> 
>> 9.) How do you use your uClibc system?
> 
> I press keys on a keyboard and view patterns on a screen.  Sometimes a network 
> card is involved.

We use it to watch TV and DVDs - no keyboard involved.

> 
>> 10.) How well does uClibc support your computing activities (scale of 1 to
>> 10) ?
> 
> Blue.

42

> 
> Rob

Carl
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG3muHsOYe+9JwoiQRAttnAJkBhboTtiVeHMtCe3Od+Vlx9IIJXQCdHLuO
2WeQNTB6NFEXeY3Q5wQG6FQ=
=VCnF
-----END PGP SIGNATURE-----



More information about the uClibc mailing list