summaryrefslogtreecommitdiff
path: root/docs/uclibc.org
diff options
context:
space:
mode:
authorEric Andersen <andersen@codepoet.org>2003-09-09 10:02:31 +0000
committerEric Andersen <andersen@codepoet.org>2003-09-09 10:02:31 +0000
commit83d06c569c280324874460374f5b2ca3ebe63263 (patch)
treef94e2426d9d875173068e9f3c2587c681f276456 /docs/uclibc.org
parent6a402bb07f0368747cf7157bc9734ff418b21208 (diff)
Yet more trivial doc updates
Diffstat (limited to 'docs/uclibc.org')
-rw-r--r--docs/uclibc.org/FAQ.html14
-rw-r--r--docs/uclibc.org/index.html13
2 files changed, 16 insertions, 11 deletions
diff --git a/docs/uclibc.org/FAQ.html b/docs/uclibc.org/FAQ.html
index 53cd52f88..1017e22a0 100644
--- a/docs/uclibc.org/FAQ.html
+++ b/docs/uclibc.org/FAQ.html
@@ -53,8 +53,8 @@ to the uClibc home page.</a>
</TD></TR>
<TR><TD BGCOLOR="#eeeee0">
- Currently uClibc runs on alpha, ARM, i386, i960, h8300, m68k, mips/mipsel,
- PowerPC, SH, SPARC, and v850 processors.
+ Currently uClibc runs on alpha, ARM, cris, h8300, i386, i960, m68k,
+ mips/mipsel, PowerPC, SH, SPARC, and v850 processors.
<p>
@@ -166,10 +166,12 @@ to the uClibc home page.</a>
<p>
- If you are trying to build a huge fileserver for your company that will
- have 12 Terabytes of storage, then using glibc may make more sense.
- Unless, for example, that 12 Terabytes will be Network Attached Storage
- and you plan to burn Linux into the system's firmware...
+ If you are building an embedded Linux system and you find that
+ glibc is eating up too much space, you should consider using
+ uClibc. If you are building a huge fileserver with 12 Terabytes
+ of storage, then using glibc may make more sense. Unless, for
+ example, that 12 Terabytes will be Network Attached Storage and
+ you plan to burn Linux into the system's firmware...
diff --git a/docs/uclibc.org/index.html b/docs/uclibc.org/index.html
index 6d83c33a6..30b8703bc 100644
--- a/docs/uclibc.org/index.html
+++ b/docs/uclibc.org/index.html
@@ -47,14 +47,17 @@ uClibc. Porting applications from glibc to uClibc typically involves
just recompiling the source code. uClibc even supports shared libraries
and threading. It currently runs on <a href="http://kernel.org/">standard Linux</a>
and <a href="http://www.uclinux.org">MMU-less (also known as µClinux)</a>
-systems with support for alpha, ARM, i386, i960, h8300, m68k, mips/mipsel,
+systems with support for alpha, ARM, cris, i386, i960, h8300, m68k, mips/mipsel,
PowerPC, SH, SPARC, and v850 processors.
<p>
-If you are building an embedded Linux system and you find that glibc is
-eating up too much space, you should consider using uClibc. If you are
-building a huge fileserver with 12 Terabytes of storage, than using
-glibc may be a better choice...
+If you are building an embedded Linux system and you find that
+glibc is eating up too much space, you should consider using
+uClibc. If you are building a huge fileserver with 12 Terabytes
+of storage, then using glibc may make more sense. Unless, for
+example, that 12 Terabytes will be Network Attached Storage and
+you plan to burn Linux into the system's firmware...
+
<p>
uClibc is maintained by