[SGVLUG] Linux based web-server appliance

[Dustin Laurence]

On Thu, May 18, 2006 at 08:57:22PM -0700, David Lawyer wrote:
> > 
> On Thu, May 18, 2006 at 06:54:49PM -0700, Dustin Laurence wrote:
> > It takes very little to run a website, though it depends on what you
> > want to host.  If it is static HTML then you can probably buy an NSLU2
> > for $100, install Linux, and pay very little in power as well. 
> 
> Will the entire server run on NSLU2?

Yes, and I'm considering buying one specifically for web serving because
of the low cost and power efficiency.  My guess is that I'm not likely
to be doing anything the NSLU2 can't fill up my pipe with anytime soon.
The website says that Apache stresses it pretty hard ("it will really
whack your slug") but they supply it so it's probably OK as long as
that's the machine's main job.  (The site also shows how to overclock
the machine by nearly double--I'd normally never overclock a serious
machine, but in this case the issue is that Linksys underclocked it from
266MHz down to 166 MHz for no known reason, so you're still running it
within the CPU manufacturer's specs).  If you serve static pages,
though, you can run a simple lightweight HTTP daemon which ought to do
just great on almost anything that has a network card.  Serving simple
HTML actually doesn't take much at all--I have a link to a HTTP daemon
written in shell (as a joke, to be sure) which apparently limps along
but does the job!  For that matter, I have actually visited a web site
served by a Commodore 64 (6502-derivative chip).  If a C64 can serve
static pages you better believe an NSLU2 can.

http://www.nslu2-linux.org/wiki/Info/ComparingWebServers

AppWeb looks pretty interesting, though I'm not familiar with it.  I've
been thinking about an NSLU2 ever since I noticed how much power even an
ancient Pentium-II sucks down.

> ...I read that there is a problem
> with endiness and that byte-swapping is needed.

The problem is that there is too much choice. :-)  ARM processors, like
a bunch of others, can run either little-endian or big-endian (I suspect
it may not be native both ways and just automatically swaps in one mode,
probably little-endian), and most decent software should be endianness
agnostic.  In general it *isn't* an issue--pretty much all the current
CPUs are big-endian or bytesexuan AFAIK, except for the *huge* exception
of x86.  Anyway...Linux in general obviously doesn't care because it
runs on architectures of all sorts of endianness (Sparc is strictly
big-endian and AFAIK Linux supports it very well).

Byte swapping isn't necessarily a huge issue either--almost all of us
are running Linux on x86, which as a little-endian arch has to swap
bytes to and from network (big-endian) order just to use networking.
Linux networking is OK. :-)

My understanding is that the essential problem with the NSLU2 is that
Linksys chose to run it in big-endian mode and so the proprietary binary
drivers are big-endian (drivers are a place where endianness is likely
to matter, and often the code is written such that the choice is made at
compile time rather than run-time), while the ARM Linux port
specifically (as opposed to Linux in general) is much better tested in
little-endian mode (i.e.  there could be hidden endianness assumption
bugs that haven't been properly ferreted out).  So the ARM Linux guys
would rather run little-endian, and I guess may consider switching once
they can support all the devices in little-endian mode.  That's for
OpenSLUG--I think Unslung probably has to stick with big-endian because
it's based on Linksys' code.  DebianSlug is little-endian, though.  I'm
not sure where Debian is making endianness assumptions but it must be.

Debian seems rather heavyweight for a NSLU2, but if it floats your
boat....

http://www.nslu2-linux.org/wiki/Info/EndianNess

> ...Someone has patched
> the code, but will this support continue?

I'm not worried about that too much.

> ...Endiness is whether
> or not you put the most significant byte first (like we do when
> writing out a number) or put it last.

Yes, C programmers generally know what endianness is because C allows
you to manipulate values at the sub-word level (many languages don't)
and thus write endianness-dependent code.  Enormous flame wars have been
waged over which one is The Right Thing.  Of course I know the answer,
but I'm not telling. :-)

Hmm, I fear my mental model may not be entirely firm on this: my big
picture is big-endian, as is English text with Hindu numerals, but I'm
not sure but what my pointer instincts are little-endian.  Better keep
an eye on that, huh.  I can't remember when the last time was I cared
about endianness, so very likely I'm capable of pulling
clueless-n00b-who-learned-on-a-PC stunts.

Small trivia bonus for those who know where the name "endian" comes from
in the first place.  Much bigger bonus for knowing why it's also called
the 'NUXI' problem without looking it up.

> > If you use an old PC you'll be paying a noticable power bill (for a
> > home--for a school it might well be *way* below the noise).
> 
> It depends on how old.  My old 486 (held as a backup) is energy star
> and claimed it was a "green" model and used under 30 watts, excluding
> the monitor.

Even a Pentium or Pentium II can consume 200 W, so I'd have expected a
486 to consume more.  Anyway, a NSLU2 apparently consumes less than 10 W
even run flat-out.  The 486 isn't energy efficient, it just is slow
enough for the total consumption to still be low (much as lawnmower
engines aren't efficient but don't consume much gas either).  You can
get, say, a Via chip that will run *much* faster without consuming more
than that.  For that matter I think some Pentium-M's and Turion64's run
in that range while running still faster.

> Supposedly, a Plone generated site can be made static.  But then why
> use Plone?

I have no idea whatsoever.  Because you like generating your static
pages with Plone instead of an HTML editor, I guess.

> ....I've got Plone on my old Pentium I PC but never used it.

Great Jumpin' Jehosaphat On A Purple Pogo Stick, why do you have *that*
package on *that* machine.  Better be careful, firing up Plone might let
the smoke out of a PI. :-)

Dustin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://www.sgvlug.net/pipermail/sgvlug/attachments/20060518/e81b940a/attachment.bin