libc

Robert Day zarin at dscn.net
Sun Jan 4 06:16:49 PST 2004


On Sun, 2004-01-04 at 06:45, Miguel Bazdresch wrote:
> * ashes <cendres at videotron.ca> [04-0104 11:51]:
> > Is there any reasons uclibc would be considered more secure then glibc? What 
> > sort of applications would not be able to build with uclibc? I'm pretty sure 
> > X will, if not then TinyX. Should at least be considered. uclibc and busybox 
> > is less code, should be less prone to bugs too.
> 
> That's an unwarranted and dangerous assumption. Code size and number

Assumption it is not - theory it is. Science tells us that a theory is
the first step in an experiment - aka thesis.  You have to make some
theories (call them assumptions if you must) to then create an
experiment. You then run the experiment, and gather results. If the
results match your theory, you proove something. If the results do not
match your theory, also proove something. Either way, facts cannot
always be found pre-formatted and written for your specific purpose, nor
can they always be trusted. One of the greatest things about HLFS - from
a developer standpoint - is the chance to play with new stuff,
experiment with it, and find something new about it - maybe making
progress towards new levels of security, maybe not.

> of bugs are not necessarily correlated. From uclibc's FAQ:
> 
> "Some of the space savings in uClibc is obtained at the cost of
> performance, and some is due to sacrificing features. Much of it comes
> from aggressive refactoring of code to eliminate redundancy."
> 
Maybe this is a good thing, maybe it is not - but the kind of gusto
ashes is showing for this project is what will make it a sucess.

> Now consider this quote from Kernighan:
> 
> "Debugging is twice as hard as writing the code in the first
> place. Therefore, if you write the code as cleverly as possible, you
> are, by definition, not smart enough to debug it."
> 
And a wise man once said "The Sun God will rise this morning, and make
his journy across the sky, towards his resting place under the (flat)
earth."  <Paraphrased of course> and this was when the earth was flat,
and the cneter of the universe.  
And don;t forget, that if Joe writes his best code, then according to
definition, he cannot debug it. Bob, although not a great coder, and
without creative gusto to write code, has a Vulcan type mind, and can
debug code with his eyes closed. When Joe writes an app, it is somewhat
buggy, but very clean, and tight. When Bob writes an app, it is bloated,
redundant, and ugly...  not to mention slow - but completely bug free.. 
Now, when Bob gets hold of Joes code, bob is amazed a how clean and
tight it is, and wishes he could code that nice, but he sees bugs, and
fixes them. Then Joe gets his code back, sees how bob fixed the bugs,
and then recodes the bugfixes to match his clean coding style and
performance oriented coding.  The end result is a flast, stable, and
tight code that is bug-free (mostly).

So, assumptions are good, as long as there is a plan to proove the
theory in place later on.

  Rob Day (BOFH)






More information about the hlfs-dev mailing list