Update the docs and website

4 files changed, 515 insertions, 270 deletions

diff --git a/docs/FAQ.txt b/docs/FAQ.txt
deleted file mode 100644
index 87322174c..000000000
--- a/docs/FAQ.txt
+++ /dev/null
@@ -1,186 +0,0 @@
-This is a collection of some of the frequently asked question
-about uClibc.  Some of the questions even have answers. If you
-have additions to this FAQ document, I'd love to add them,
-
- -Erik
-
-
-Q: What platforms does uClibc run on?
-
-    Currently uClibc runs on arm, i386, m68k, mipsel, powerpc, sh,
-    sparc, and v850.  
-    
-
-
-Q: Does uClibc support shared libraries?
-    
-    Yes.  uClibc has shared library support on x86, arm, and powerpc.  
-    Shared Libraries are _not_ currently supported on MMU-less systems. 
-
-
-
-Q: Why is it called uClibc?
-
-    The letter 'u' is short for the greek letter "mu".  "Mu" stands for
-    "micro", and the "C" is for "controller".  uClibc was originaly created to
-    support uClinux, a port of Linux for MMU-less microcontrollers such as the
-    Dragonball, Coldfire, and ARM7TDMI.  
-
-
-
-Q: Can I use it on my desktop x86 system?
-
-    Sure!  In fact, this can be very nice during development.  By using it on
-    your development system, you can be sure that the code you are working on
-    will actually run on your target system.
-
-
-
-Q: Why are you doing this?  Whats wrong with glibc?
-
-    The inital reason, is that glibc does not support MMU-les systems.  But
-    additionaly, the GNU C library has a different set of goals then uClibc.
-    The GNU C library is a great piece of software.  It complies with just
-    about every standard ever created, and runs on just about every operating
-    system as well -- no small task!  But there is a price to be paid for that.
-    It is quite a large library, and keeps getting larger with each release.
-    It does not even pretend to target embedded systems.  To quote from Ulrich
-    Drepper, the maintainer of GNU libc: "...glibc is not the right thing for
-    [an embedded OS]. It is designed as a native library (as opposed to
-    embedded).  Many functions (e.g., printf) contain functionality which is
-    not wanted in embedded systems." 24 May 1999
-
-
-
-Q: So uClibc is smaller then glibc?  Doesn't that mean it completely sucks?
-    How could it be smaller and not suck?
-
-    uClibc has been designed from the ground up to be a C library for embedded
-    Linux.  We don't need to worry about whether we support MS-DOS, or Cygwin,
-    or any other system.  This lets us cut out lots of complexity, and very
-    carefully optimize for Linux.  By very careful design, we can also make a
-    few shotcuts.  For example, glibc contains an implementation of the
-    wordexp() function, in compliance with the Single Unix Specificaion,
-    version 2.  Well, standards are important.  But so is pragmatism.  The
-    wordexp function adds almost 100k to glibc, and yet I am not aware of even
-    one Linux application that uses wordexp.  So uClibc doesn't have wordexp().
-
-    Glibc is a general purpose C library, and so as policy things are optimized
-    for speed.  uClibc has a large number of routines that have been very
-    carefuly written to optimize for size instead of speed.
-
-    The end result is a C library that will compile just about everything you
-    throw at it, thet looks like glibc to application programs when you
-    compile, and is many times smaller.
-
-    
-
-Q: Why should I use uClibc?
-
-    I don't know if you should use uClibc or not.  It depends on your goals.
-    If you are building an embedded system, and you are tight on space, then
-    using uClibc instead if glibc should allow you to use your storage for
-    other things.
-
-    If you are trying to build a ultra fast fileserver for your company that
-    has 12 Terabytes of storage, then you probably want to use glibc... 
-
-
-
-Q: I want to create a closed source commercial application and  I want to
-    protect my intellectual property.  If I use uClibc, don't I have to 
-    release my source code?
-
-    No, you do not need to give away your source code just because you use
-    uClibc and/or run on Linux.  
-
-
-
-Q: I want to create a closed source commercial application using uClibc.  
-    Is that legal?
-
-    Yes.  uClibc is licensed under the LGPL, just like GNU libc.  If you are
-    using uClibc as a shared library, then your closed source application is
-    100% legal.  Please consider sharing some of the money you make.  :-)
-    
-    If you are staticly linking your closed source commercial application with
-    uClibc, then you must take additional steps to comply with the uClibc
-    license.  You can sell your application as usual, but you must also make
-    your closed source application available to your customers as an object
-    file which can then be linked with updated versions of uClibc.  This will
-    (in theory) allow your customers to later link with updated versions of
-    uClibc.  You do not need to make the application object file available to
-    everyone, just to those you gave the fully linked application.
-
-
-
-Q: How do I compile stuff?
-
-    The easiest way is to use the compiler wrapper built by uClibc.  Instead of
-    using your usual compiler or cross compiler, you can use i386-uclibc-gcc,
-    (or whatever is appropriate for your architecture) and it will automagically 
-    make your program link against uClibc.
-
-
-
-Q: How do I make autoconf and automake behave?
-
-    First run
-	export PATH=/usr/i386-linux-uclibc/bin:$PATH
-    (or similar adjusted for your target architecture) then run you can simply
-    run autoconf/automake and it should _just work_.
-
-
-
-Q: When I run 'ldd' to get a list of the library dependancies for a uClibc
-    binary, ldd segfault!  Or it runs my application?  Anyways, it doesn't 
-    work!  What should I do?
-
-    Use the ldd that is built by uClibc, not your system's one.  When your
-    system's ldd looks for the library dependancies, it actually tries to
-    _execute_ that program.  This works fine -- usually.  I doesn't work at all
-    when you are cross compiling (thats why ldd segfaults).  The ldd program
-    created by uClibc is cross platform and doesn't actually try to run the
-    target program like your system one does, so it should do the right thing,
-    and won't segfault, even when you are cross compiling.
-
-
-
-Q: I need you to add <favorite feature> now!   How come you don't answer all my
-    questions on the mailing list withing 5 minutes?  I demand that you help me
-    Right Now!
-
-    You have not paid me a single cent and yet you still have the product of
-    over year and a half of my work, and lots of work from other people.  How
-    dare you treat me that way!  I work on uClibc because I find it
-    interesting.  If you go off flaming me, I will ignore you.
-    
-
-
-Q: I need you to add <favorite feature>!  Are the uClibc developers willing to 
-    be paid in order to add in <favorite feature>?  Are you willing to provide
-    support contracts?  
-
-    Sure!  Now you have our attention!  What you should do is contact 
-    Erik Andersen of CodePoet Consulting to bid on your project.  If Erik
-    is too busy to personally add your feature, there are several other
-    active contributors who may be able to help you out.
-    
-    
-Q: I think you guys are great and I want to help support your work!
-
-    Wow, that would be great!  You can visit 
-	    http://paypal.com/ 
-    click on "Send Money" and donate to andersen@codepoet.org
-
-
-
-I hope that was helpful...  If you have and comment, corrections, insults,
-suggestions, or bribes, email me at andersen@codepoet.org.
-
- -Erik
-
---
-Erik B. Andersen             
-andersen@codepoet.org
-http://codepoet-consulting.com/
diff --git a/docs/uclibc.org/FAQ.html b/docs/uclibc.org/FAQ.html
new file mode 100644
index 000000000..92b227edb
--- /dev/null
+++ b/docs/uclibc.org/FAQ.html
@@ -0,0 +1,436 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd"> 
+
+<HTML>
+<HEAD>
+    <TITLE>uClibc FAQ-- a C library for embedded systems</TITLE>
+</HEAD>
+
+<body text="#000000" alink="#660000" link="#660000" bgcolor="#dee2de" vlink="#660000">
+
+<basefont face="lucida, helvetica, arial" size="3">
+
+
+<CENTER>
+<p>
+
+<TABLE BORDER=0 CELLSPACING=1 CELLPADDING=2>
+    <TR>
+	<td bgcolor="#000000">
+	  <FONT FACE="lucida, helvetica" COLOR="#ccccc0">
+	      <B>µ&nbsp;C&nbsp;l&nbsp;i&nbsp;b&nbsp;c</B>
+	  </FONT>
+	</TD>
+    </TR>
+</TABLE>
+<p>
+
+
+<!-- Begin NOT Working List -->
+
+
+<TABLE WIDTH=95% CELLSPACING=1 CELLPADDING=4 BORDER=1>
+<TR><TD BGCOLOR="#ccccc0" ALIGN=center>
+    <A NAME="notworking"> <BIG><B>
+		uClibc Frequently Asked Questions (FAQ)
+    </font>
+    </A></B></BIG>
+</TD></TR>
+<TR><TD BGCOLOR="#eeeee0">
+
+<p> 
+This is a collection of some of the frequently asked questions
+about uClibc.  Some of the questions even have answers. If you
+have additions to this FAQ document, we would love to add them,
+<br>
+When you are done, <a href="http://uclibc.org/">you can click here to return 
+to the uClibc home page.</a>
+
+<p>
+<TR><TD BGCOLOR="#ccccc0" ALIGN=left>
+    <B>
+    What platforms does uClibc run on?
+    </B>
+</TD></TR>
+<TR><TD BGCOLOR="#eeeee0">
+
+    Currently uClibc runs on arm, i386, m68k, mipsel, powerpc, sh,
+    sparc, and v850.  
+    
+
+<p>
+<TR><TD BGCOLOR="#ccccc0" ALIGN=left>
+    <B>
+    Does uClibc support shared libraries?
+    </B>
+</TD></TR>
+<TR><TD BGCOLOR="#eeeee0">
+    
+    Yes.  uClibc has shared library support on x86, arm, and powerpc.  
+    Shared Libraries are _not_ currently supported on MMU-less systems. 
+
+
+
+<p>
+<TR><TD BGCOLOR="#ccccc0" ALIGN=left>
+    <B>
+    Why is it called uClibc?
+    </B>
+</TD></TR>
+<TR><TD BGCOLOR="#eeeee0">
+
+    The letter 'u' is short for µ (the greek letter "mu").  µ is commonly used
+    as the abbreviation for the word "micro".  The capital "C" is short for
+    "controller".  So you uClibc is simply the microcontroller C library. 
+    This is because uClibc was originaly created to support uClinux, a port of
+    Linux for MMU-less microcontrollers such as the Dragonball, Coldfire, and
+    ARM7TDMI.  For simplicity, it is pronounced "yew-see-lib-see".
+
+
+
+<p>
+<TR><TD BGCOLOR="#ccccc0" ALIGN=left>
+    <B>
+    Can I use it on my desktop x86 system?
+    </B>
+</TD></TR>
+<TR><TD BGCOLOR="#eeeee0">
+
+    Sure!  In fact, this can be very nice during development.  By using it on
+    your development system, you can be sure that the code you are working on
+    will actually run when you deploy it your target system.
+
+
+
+<p>
+<TR><TD BGCOLOR="#ccccc0" ALIGN=left>
+    <B>
+    Why are you doing this?  Whats wrong with glibc?
+    </B>
+</TD></TR>
+<TR><TD BGCOLOR="#eeeee0">
+
+    The inital reason, was that glibc does not support MMU-less systems.  But
+    also because uClibc is so much smaller then the GNU C library.  The GNU C
+    library has a different set of goals then uClibc.  The GNU C library is a
+    great piece of software.  It complies with just about every standard ever
+    created, and runs on just about every operating system as well -- no small
+    task!  But there is a price to be paid for that.  It is quite a large
+    library, and keeps getting larger with each release.  It does not even
+    pretend to target embedded systems.  To quote from Ulrich Drepper, the
+    maintainer of GNU libc: "...glibc is not the right thing for [an embedded
+    OS]. It is designed as a native library (as opposed to embedded).  Many
+    functions (e.g., printf) contain functionality which is not wanted in
+    embedded systems." 24 May 1999
+
+
+
+<p>
+<TR><TD BGCOLOR="#ccccc0" ALIGN=left>
+    <B>
+    So uClibc is smaller then glibc?  Doesn't that mean it completely sucks?
+    How could it be smaller and not suck?
+    </B>
+</TD></TR>
+<TR><TD BGCOLOR="#eeeee0">
+
+    uClibc has been designed from the ground up to be a C library for embedded
+    Linux.  We don't need to worry about whether we support MS-DOS, or Cygwin,
+    or any other system.  This lets us cut out lots of complexity, and very
+    carefully optimize for Linux.  By very careful design, we can also take a
+    few shortcuts.  For example, glibc contains an implementation of the
+    wordexp() function, in compliance with the Single Unix Specificaion,
+    version 2.  Well, standards are important.  But so is pragmatism.  The
+    wordexp function is huge, and yet I am not aware of even one Linux
+    application that uses wordexp.  So uClibc doesn't provide wordexp().  There
+    are many similar examples.
+
+    Glibc is a general purpose C library, and so as policy things are optimized
+    for speed.  Most of uClibc's routines have been very carefuly written to
+    optimize them for size instead of speed.
+
+    The end result is a C library that will compile just about everything you
+    throw at it, that looks like glibc to application programs when you
+    compile, but is many times smaller.
+
+    
+
+<p>
+<TR><TD BGCOLOR="#ccccc0" ALIGN=left>
+    <B>
+    Why should I use uClibc?
+    </B>
+</TD></TR>
+<TR><TD BGCOLOR="#eeeee0">
+
+    I don't know if you should use uClibc or not.  It depends on your needs.
+    If you are building an embedded system, and you are tight on space, then
+    using uClibc instead if glibc should allow you to use your storage for
+    other things.
+
+    If you are trying to build a ultra fast fileserver for your company that
+    has 12 Terabytes of storage, then you probably want to use glibc... 
+
+
+
+<p>
+<TR><TD BGCOLOR="#ccccc0" ALIGN=left>
+    <B>
+    I want to create a closed source commercial application and  I want to
+    protect my intellectual property.  If I use uClibc, don't I have to 
+    release all my source code for free?
+    </B>
+</TD></TR>
+<TR><TD BGCOLOR="#eeeee0">
+
+    No, you do not need to give away your source code just because you use
+    uClibc and/or run on Linux.  
+
+
+
+<p>
+<TR><TD BGCOLOR="#ccccc0" ALIGN=left>
+    <B>
+    I want to create a closed source commercial application using uClibc.  
+    Is that legal?
+    </B>
+</TD></TR>
+<TR><TD BGCOLOR="#eeeee0">
+
+    Yes.  uClibc is licensed under the LGPL, just like GNU libc.  If you are
+    using uClibc as a shared library, then your closed source application is
+    100% legal.  Please consider sharing some of the money you make.  :-)
+    
+    If you are staticly linking your closed source commercial application with
+    uClibc, then you must take additional steps to comply with the uClibc
+    license.  You can sell your application as usual, but you must also make
+    your closed source application available to your customers as an object
+    file which can then be linked with updated versions of uClibc.  This will
+    (in theory) allow your customers to later link with updated versions of
+    uClibc.  You do not need to make the application object file available to
+    everyone, just to those you gave the fully linked application.
+
+
+
+<p>
+<TR><TD BGCOLOR="#ccccc0" ALIGN=left>
+    <B>
+    How do I compile stuff?
+    </B>
+</TD></TR>
+<TR><TD BGCOLOR="#eeeee0">
+
+    The easiest way is to use the compiler wrapper built by uClibc.  Instead of
+    using your usual compiler or cross compiler, you can use i386-uclibc-gcc,
+    (or whatever is appropriate for your architecture) and it will automagically 
+    make your program link against uClibc.
+
+
+
+<p>
+<TR><TD BGCOLOR="#ccccc0" ALIGN=left>
+    <B>
+    How do I make autoconf and automake behave?
+    </B>
+</TD></TR>
+<TR><TD BGCOLOR="#eeeee0">
+
+    First run
+    <pre>export PATH=/usr/i386-linux-uclibc/bin:$PATH</pre>
+    (or similar adjusted for your target architecture) then run you can simply
+    run autoconf/automake and it should _just work_.
+
+
+
+<p>
+<TR><TD BGCOLOR="#ccccc0" ALIGN=left>
+    <B>
+    When I run 'ldd' to get a list of the library dependancies for a uClibc
+    binary, ldd segfault!  Or it runs my application?  Anyways, it doesn't 
+    work!  What should I do?
+    </B>
+</TD></TR>
+<TR><TD BGCOLOR="#eeeee0">
+
+    Use the ldd that is built by uClibc, not your system's one.  When your
+    system's ldd looks for the library dependancies, it actually tries to
+    _execute_ that program.  This works fine -- usually.  I doesn't work at all
+    when you are cross compiling (thats why ldd segfaults).  The ldd program
+    created by uClibc is cross platform and doesn't actually try to run the
+    target program like your system one does, so it should do the right thing,
+    and won't segfault, even when you are cross compiling.
+
+
+<p>
+<TR><TD BGCOLOR="#ccccc0" ALIGN=left>
+    <B>
+    What is the history of uClibc?  Where did it come from?
+    </B>
+</TD></TR>
+<TR><TD BGCOLOR="#eeeee0">
+
+    This history and origin of uClibc is long and twisty.
+    In the beginning, there was <a href="http://www.gnu.org/software/libc/libc.html">GNU libc</a>.  Then, libc4
+    (which later became linux libc 5) forked from GNU libc version 1.07.4, with
+    additions from 4.4BSD, in order to support Linux.  Later, the <a
+    href="http://www.cix.co.uk/~mayday/">Linux-8086 C library</a>, which is part of
+    the <a href="http://www.elks.ecs.soton.ac.uk/">elks project</a>, was created,
+    which was, apparently, largely written from scratch but also borrowed code from
+    libc4, glibc, some Atari library code, with bits and pieces from about 20 other
+    places.  Then uClibc forked off from the Linux-8086 C library in order to run
+    on <a href="http://www.uclinux.org">µClinux</a>.
+    <p>
+
+    I had for some time been despairing over the state of C libraries in Linux.
+    GNU libc, the standard, is very poorly suited to embedded systems (and it just
+    gets bigger with every release).  I spent quite a bit of time looking over the
+    other Open Source C libraries that I knew of (listed below), and none of them really
+    impressed me.  I felt there was a real vacancy in the embedded Linux ecology.
+    The closest library to what I imagined an embedded C library should be was
+    uClibc.  But that had a lot of problems too -- not the least of which was that,
+    traditionally, uClibc had a complete source tree fork in order to support each
+    and every new platform, resulting in a big mess of twisty versions, all
+    different.  I decided to fix it and the result is what you see here.
+    My source tree has now become the official uClibc source tree and it now lives
+    on cvs.uclinux.org.
+
+    <p>
+
+    To start with, (with some initial help from <a
+    href="http://www.uclinux.org/developers/index.html">D. Jeff Dionne</a>), I
+    ported it to run on x86.  I then grafted in the header files from glibc 2.1.3
+    and cleaned up the resulting breakage.  This (plus some additional work) has
+    made it almost completely independant of kernel headers, a large departure from
+    its traditional tightly-coupled-to-the-kernel origins.  I have written and/or
+    rewritten a number of things that were missing or broken, and sometimes grafted
+    in bits of code from the current glibc and libc5.  I have also built a proper
+    platform abstraction layer, so now you can simply edit the file "Config" and
+    use that to decide which architecture you will be compiling for, and whether or
+    not your target has an MMU, and FPU, etc.  I have also added a test suite,
+    which, though incomplete, is a good start.  Several people have helped by
+    contributing ports to new architectures, and a lot of work has been done on
+    adding support for missing features.
+
+
+
+<p>
+<TR><TD BGCOLOR="#ccccc0" ALIGN=left>
+    <B>
+    I need you to add &lt;favorite feature&gt; now!   How come you don't answer all my
+    questions on the mailing list withing 5 minutes?  I demand that you help me <em>Right Now</em>!
+    </B>
+</TD></TR>
+<TR><TD BGCOLOR="#eeeee0">
+
+    You have not paid us a single cent and yet you still have the product of
+    over year and a half of work from Erik and Manuel and lots of other people.  
+    How dare you treat us that way!  We work on uClibc because we find it
+    interesting.  If you go off flaming us, we will ignore you.
+    
+
+
+<p>
+<TR><TD BGCOLOR="#ccccc0" ALIGN=left>
+    <B>
+    I need you to add &lt;favorite feature&gt;!  Are the uClibc developers willing to 
+    be paid in order to add in &lt;favorite feature&gt;?  Are you willing to provide
+    support contracts?  
+    </B>
+</TD></TR>
+<TR><TD BGCOLOR="#eeeee0">
+
+    Sure!  Now you have our attention!  What you should do is contact <a
+	href="mailto:andersen@codepoet.org">Erik Andersen</a> of <a
+	href="http://codepoet-consulting.com/">CodePoet Consulting</a> to bid
+    on your project.  If Erik is too busy to personally add your feature, there
+    are several other active uClibc contributors who may be able to help you out.
+    Erik can contact them and ask them about their availability.
+    
+    
+<p>
+<TR><TD BGCOLOR="#ccccc0" ALIGN=left>
+    <B>
+    I think you guys are great and I want to help support your work!
+    </B>
+</TD></TR>
+<TR><TD BGCOLOR="#eeeee0">
+
+    Wow, that would be great!  You can click here to help support uClibc and/or request features.
+    
+    <!-- Begin PayPal Logo -->
+    <center>
+    <form action="https://www.paypal.com/cgi-bin/webscr" method="post">
+	<input type="hidden" name="cmd" value="_xclick">
+	<input type="hidden" name="business" value="andersen@codepoet.org">
+	<input type="hidden" name="item_name" value="Support uClibc and/or request features">
+	<input type="hidden" name="image_url" value="https://codepoet-consulting.com/images/codepoet.png">
+	<input type="hidden" name="no_shipping" value="1">
+	<input type="image" src="images/donate.png" border="0" name="submit" alt="Make donation using PayPal">
+    </form>
+    </center>
+    <!-- End PayPal Logo -->
+
+    If you prefer to contact us directly for payments (we have a credit card machine so
+    you can avoid online payments), hardware donations, support requests, etc., you can
+    contact <a href="http://codepoet-consulting.com/">CodePoet Consulting</a> here.
+
+<p>
+<TR><TD BGCOLOR="#ccccc0" ALIGN=left>
+    <B>
+	Ok, I'm done reading all these questions.
+    </B>
+</TD></TR>
+<TR><TD BGCOLOR="#eeeee0">
+</TD></TR>
+</TABLE>
+</P>
+
+<a href="http://uclibc.org/">Well then, click here to return to the uClibc home page.</a>
+
+
+<!-- Footer -->
+<HR>
+<TABLE WIDTH="100%">
+    <TR>
+	<TD>
+	    <font size="-1" face="arial, helvetica, sans-serif">
+	    Mail all comments, insults, suggestions and bribes to 
+	    <a href="mailto:andersen@codepoet.org">Erik Andersen</a><BR>
+	    </font>
+	</TD>
+
+	<TD>
+	    <a href="http://www.vim.org"><img border=0 width=90 height=36
+	    src="images/written.in.vi.png" 
+	    alt="This site created with the vi editor"></a>
+	</TD>
+
+	<TD>
+	    <a href="http://www.gimp.org/"><img border=0 width=90 height=36
+	    src="images/gfx_by_gimp.png" alt="Graphics by GIMP"></a>
+	</TD>
+
+	<TD>
+	    <a href="http://www.linuxtoday.com"><img width=90 height=36
+	    src="images/ltbutton2.png" alt="Linux Today"></a>
+	</TD>
+
+	<TD>
+	    <p><a href="http://slashdot.org"><img width=90 height=36
+	    src="images/sdsmall.png" alt="Slashdot"></a>
+	</TD>
+
+	<TD>
+	    <a href="http://freshmeat.net"><img width=90 height=36
+	    src="images/fm.mini.png" alt="Freshmeat"></a>
+	</TD>
+
+    </TR>
+</TABLE>
+
+
+</CENTER>
+</BODY>
+</HTML>
+
+ 
+ 
diff --git a/docs/uclibc.org/index.html b/docs/uclibc.org/index.html
index 96b3ebfd2..c5e18e333 100644
--- a/docs/uclibc.org/index.html
+++ b/docs/uclibc.org/index.html
@@ -38,7 +38,24 @@
 <TR><TD BGCOLOR="#eeeee0">
 
 
-uClibc is a C library for embedded systems.
+<a href="http://uclibc.org">uClibc</a> (aka µClibc but pronounced
+yew-see-lib-see) is a C library for embedded Linux systems.  It is much smaller
+then GNU libc, but nearly all applications supported by the 
+<a href="http://www.gnu.org/software/libc/libc.html">GNU C Library (aka glibc)</a> 
+also work perfectly with uClibc.  Porting applications from
+glibc to uClibc typically involves just recompiling the source code.  uClibc
+supports standard Linux systems (such as x86, strongArm, and powerpc), and also
+supports <a href="http://www.uclinux.org">MMU-less (also known as µClinux)</a>
+systems, such as those based on the Coldfire, dragonball, or arm7tdmi
+micro-controllers.  If you are building an embedded Linux system, and you fine
+the GNU libc is eating up too much space, you should consider using uClibc
+instead.  If you are working on an older system with limited memory (such as an
+oldworld Mac), uClibc may also be useful for you.  If you are using a standard
+desktop Linux workstation to develop applications for an embedded Linux system,
+you can use run uClibc on your workstation while doing development.  If you are
+trying to build a ultra fast fileserver for your company that has 12 Terabytes
+of storage, then you probably want to use glibc...
+
 <p>
 
 <p>
@@ -46,9 +63,11 @@ uClibc is maintained by
 <a href="http://www.codepoet.org/andersen/erik/erik.html">Erik Andersen</a>
 and is licensed under the 
 <a href="http://www.gnu.org/copyleft/lgpl.html">GNU LIBRARY GENERAL PUBLIC LICENSE</a>
-<p>
+.  This license allows you to make closed source commercial applications using 
+uClibc (Please consider sharing some of the money you make ;-).  You do not need 
+to give away all your source code just because you use uClibc and/or run on Linux.
 
-It is my sincere hope that this is as useful to you as it is to me.
+<p>
 
 <!-- Begin Mailing list section -->
 
@@ -68,6 +87,36 @@ To subscribe, go and visit
 
 
 
+<!-- Begin Applications section -->
+
+<TR><TD BGCOLOR="#ccccc0" ALIGN=center>
+    <A NAME="applications"><BIG><B>
+    Known Working Applications List
+    </A></B></BIG>
+</TD></TR>
+<TR><TD BGCOLOR="#eeeee0">
+
+    uClibc now has a <a href="http://uclibc.org/uClibc-apps.html">list of applications</a> 
+    that are known to work.  Submissions are welcome! 
+    Since most applications work just fine with uClibc, we are especially 
+    interested in knowing about any applications that either do not compile
+    or do not work properly with uClibc.
+
+    
+    
+<!-- Begin Applications section -->
+
+<TR><TD BGCOLOR="#ccccc0" ALIGN=center>
+    <A NAME="faq"><BIG><B>
+    Frequently Asked Questions
+    </A></B></BIG>
+</TD></TR>
+<TR><TD BGCOLOR="#eeeee0">
+
+	uClibc now has a <a href="http://uclibc.org/FAQ.html">list of Frequently Asked Questions</a>.
+	You might want to take a look.
+    
+    
 <!-- Begin Download section -->
 
 <TR><TD BGCOLOR="#ccccc0" ALIGN=center>
@@ -77,13 +126,13 @@ To subscribe, go and visit
 </TD></TR>
 <TR><TD BGCOLOR="#eeeee0">
 <ul>
-    <li> I now have a script that creats a daily snapshot tarball of uClibc and posts it on  
+    <li> There is now a script that creates a daily snapshot tarball of uClibc and posts it on  
 	<a href="http://uclibc.org/uClibc-snapshot.tar.gz">here</a>.
-    <li> uClibc now has its own publically browsable
+    <li> uClibc also has a publically browsable
 	<a href="http://cvs.uclinux.org/cgi-bin/cvsweb/uClibc/">CVS tree</a> (this CVS tree is also mirrored onto 
 	<a href="http://uclibc.org/cgi-bin/cvsweb/uClibc/">uclibc.org</a> but they are both the same thing).
     <li> Anonymous
-	<a href="http://cvs.uclinux.org/cvs_anon.html">CVS access</a>, and
+	<a href="http://cvs.uclinux.org/cvs_anon.html">CVS access</a> is available, and
 	
     <li> For those that are actively contributing there is even 
 	<a href="http://cvs.uclinux.org/cvs_write.html">CVS write access</a>.
@@ -92,20 +141,6 @@ To subscribe, go and visit
 <!-- Begin Applications section -->
 
 <TR><TD BGCOLOR="#ccccc0" ALIGN=center>
-    <A NAME="applications"><BIG><B>
-    Known Working Applications List
-    </A></B></BIG>
-</TD></TR>
-<TR><TD BGCOLOR="#eeeee0">
-
-    uClibc now has a <a href="http://uclibc.org/uClibc-apps.html">list of applications</a> 
-    that are known to work.  If you have any applications to add to the
-    list, submissions are welcome!
-    
-    
-<!-- Begin Applications section -->
-
-<TR><TD BGCOLOR="#ccccc0" ALIGN=center>
     <A NAME="contribute"><BIG><B>
     Help Support uClibc development
     </A></B></BIG>
@@ -116,10 +151,11 @@ To subscribe, go and visit
 	added to uClibc?  Then why not help out?  We are happy to accept
 	donations, provide support contracts, and implement funded feature
 	requests.  Additionally, uClibc is looking for corporate sponsors to
-	help sponsor development, pay for bandwidth, and help with hardware
+	assist development, pay for bandwidth, and help with hardware
 	donations, especially donations of hardware for non-Intel
-	architectures.  Click here to help support uClibc and/or request features.
-    
+	architectures.  Click here to help support uClibc and/or request
+	features.  
+	
     <!-- Begin PayPal Logo -->
     <center>
     <form action="https://www.paypal.com/cgi-bin/webscr" method="post">
@@ -133,6 +169,11 @@ To subscribe, go and visit
     </center>
     <!-- End PayPal Logo -->
 
+    If you prefer to contact us directly for payments (we have a credit card machine so
+    you can avoid online payments), hardware donations, support requests, etc., you can 
+    contact <a href="http://codepoet-consulting.com/">CodePoet Consulting</a> here.
+    
+
 <!-- Begin Latest News section -->
 
 <TR><TD BGCOLOR="#ccccc0" ALIGN=center>
@@ -279,7 +320,7 @@ To subscribe, go and visit
 <!-- Begin TODO section -->
 
 <TR><TD BGCOLOR="#ccccc0" ALIGN=center>
-    <A NAME="download"><BIG><B>
+    <A NAME="todo"><BIG><B>
     TODO
     </A></B></BIG>
 </TD></TR>
@@ -290,7 +331,7 @@ Here are a few things on the TODO list:
 <ul>
     <li> Shared library support for all supported architectures.
 	We now have our own ld.so, but it needs to be ported to
-	support each architecture.
+	support each architecture. 
     <li> Shared library support for mmu-less systems.  This is
 	very doable (think of C++ vtables for example), but will
 	take some work.
@@ -322,6 +363,7 @@ Here are a few things on the TODO list:
 <ul> 
 
 
+<li><a href="http://www.gnu.org/software/libc/libc.html">GNU C Library (aka glibc)</a> 
 <li> <a href="http://www.k9wk.com/cdoc.html">Al's FREE C Runtime Library</a>
 <li><a href="http://www.fefe.de/dietlibc/">diet libc </a>
 <li>the <a href="http://www.cs.vu.nl/~ast/minix.html">minix</a> 
@@ -336,64 +378,6 @@ Here are a few things on the TODO list:
 
 
 
-<!-- Begin History section -->
-
-<TR><TD BGCOLOR="#ccccc0" ALIGN=center>
-    <A NAME="history"><BIG><B>
-    History
-    </A></B></BIG>
-</TD></TR>
-<TR><TD BGCOLOR="#eeeee0">
-
-This history and origin of uClibc is long and twisty.
-In the beginning, there was <a
-href="http://www.gnu.org/software/libc/libc.html">GNU libc</a>.  Then, libc4
-(which later became linux libc 5) forked from GNU libc version 1.07.4, with
-additions from 4.4BSD, in order to support Linux.  Later, the <a
-href="http://www.cix.co.uk/~mayday/">Linux-8086 C library</a>, which is part of
-the <a href="http://www.elks.ecs.soton.ac.uk/">elks project</a>, was created,
-which was, apparently, largely written from scratch but also borrowed code from
-libc4, glibc, some Atari library code, with bits and pieces from about 20 other
-places.  Then uClibc forked off from the Linux-8086 C library in order to run
-on <a href="http://www.uclinux.org">µClinux</a>.  
-<p>
-
-I had for some time been despairing over the state of C libraries in Linux.
-GNU libc, the standard, is very poorly suited to embedded systems (and it just
-gets bigger with every release).  I spent quite a bit of time looking over the
-other Open Source C libraries that I knew of (listed below), and none of them really
-impressed me.  I felt there was a real vacancy in the embedded Linux ecology.
-The closest library to what I imagined an embedded C library should be was
-uClibc.  But that had a lot of problems too -- not the least of which was that,
-traditionally, uClibc had a complete source tree fork in order to support each
-and every new platform, resulting in a big mess of twisty versions, all
-different.  I decided to fix it and the result is what you see here.
-My source tree has now become the official uClibc source tree and it now lives 
-on cvs.uclinux.org.  
-
-<p>
-
-To start with, (with some initial help from <a
-href="http://www.uclinux.org/developers/index.html">D. Jeff Dionne</a>), I
-ported it to run on x86.  I then grafted in the header files from glibc 2.1.3
-and cleaned up the resulting breakage.  This (plus some additional work) has
-made it almost completely independant of kernel headers, a large departure from
-its traditional tightly-coupled-to-the-kernel origins.  I have written and/or
-rewritten a number of things that were missing or broken, and sometimes grafted
-in bits of code from the current glibc and libc5.  I have also built a proper
-platform abstraction layer, so now you can simply edit the file "Config" and
-use that to decide which architecture you will be compiling for, and whether or
-not your target has an MMU, and FPU, etc.  I have also added a test suite,
-which, though incomplete, is a good start.  Several people have helped by 
-contributing ports to new architectures, and a lot of work has been done on
-adding support for missing features.
-
-<p>
-
-
-
-
-
 <!-- Begin Links section -->
 
 <TR><TD BGCOLOR="#ccccc0" ALIGN=center>
@@ -414,7 +398,13 @@ adding support for missing features.
     <li> <a href="http://cvs.uclinux.org/">The uClinux CVS reporitory</a>.
     <p>
 
-    <li> <a href="http://uclibc.org/">The uClibc.org home page</a>.
+    <li> <a href="http://uclibc.org/">The uClibc home page</a>.
+    <p>
+
+    <li> <a href="http://busybox.net/">BusyBox</a>.
+    <p>
+
+    <li> <a href="http://codepoet-consulting.com/">CodePoet Consulting</a>.
     <p>
 
 </ul>
diff --git a/docs/uclibc.org/uClibc-apps.html b/docs/uclibc.org/uClibc-apps.html
index 6989efb9b..a85274b28 100644
--- a/docs/uclibc.org/uClibc-apps.html
+++ b/docs/uclibc.org/uClibc-apps.html
@@ -39,6 +39,11 @@
 
 <p> The following applications are known to NOT work with uClibc. Please 
 tell us if you know of any applications that fall into this category! </p>
+<br>
+When you are done, <a href="http://uclibc.org/">you can click here to return 
+to the uClibc home page.</a>
+
+
 
 <!-- Not Working List -->
 <center>