I'm a happy NSLU2 user since a few months now, and I'm using it for all kinds of things, e.g. as a 24/7 remote ssh server at home (using DynDNS and the ddclient Debian package), as IRC logger (screen + irssi), etc. etc.
I was considering multiple options as to where/how to install the slug (USB thumb drive, Compact Flash, disk drive, ...) but I settled with a full Debian install on an 1 GB USB thumb drive for now. I implemented some measures to maximize the life time of the USB thumb drive, maybe I'll post some info on that later...
One new thing I've been trying lately is to use the slug as an audio player.
As it doesn't come with an integrated sound card, you have to use an external USB audio device. I've got mine (see photo) from eBay for ca. 5 Euro (+ shipping) and it works out of the box with Linux 2.6.18 using the
snd_usb_audio kernel module. You simply attach it via USB (the module is automatically loaded) and then attach external speakers to it. Here's an
lsusb of the device:
Bus 001 Device 011: ID 1130:f211 Tenx Technology, Inc.
One problem with playing audio on the slug is the slow CPU. At 266 MHz (and without FPU!) playing audio with "normal" audio players such as
mpg321 is not possible. But there are several ways to make the slug play your favorite music. Here's a list of players I tested and a status report of whether they work at all. If yes, I listed a rough percentage of CPU load resulting from playing the music.
$ madplay foo.mp3: 17% CPU load
$ mikmod foo.mod: 10% CPU load (even with compressed MOD files)
$ flac123 foo.flac: 17% CPU load
$ speexdec foo.spx: doesn't work, 100% CPU load. Any known alternatives?
Feel free to add comments if you know of other audio types which can be played on an NSLU2.
So very, very true.
Note: This article is part of my Testing stuff with QEMU series.
MenuetOS is an operating system with a monolithic preemptive, real-time kernel, including video drivers, all written in FASM assembly language, for 64-bit and 32-bit x86 architecture computers, by Ville Mikael Turjanmaa.
MenuetOS development has focused on fast, simple, efficient implementation. It has a graphical desktop, games, and networking abilities (TCP/IP stack), yet still fits on one 1.44MB floppy disk. It also facilitates easy, full-featured assembly language programming. This stands in marked contrast to the (as of 2007) widespread view that assembly languages are useful mainly for old and embedded systems.
Testing (the GPL'd) MenuetOS in QEMU is easy:
qemu -fda M32-084.IMG -m 384
There's also Menuet 64, written in 64-bit assembly, but that's not open source'd for some strange reason I don't understand. But you can try that one, too (the binary images, that is), using QEMU:
qemu-system-x86_64 -fda M64-059.IMG
I did not yet perform any long-term tests, i.e. measuring the average consumption over multiple days or so, only some quick ad-hoc checks. I just recorded the number of watts the respective device used when powered on.
Here are the results:
By removing all devices which draw more than 0 watts in stand-by mode, I was able to reduce the overall (useless) energy consumption (and costs!) quite a bit.
I also replaced a bunch of 40 W and 60 W lightbulbs with energy saving lightbulbs which are equally bright, but only consume 8 W or 12 W respectively. On the long run you can save quite some amount of energy (and money) with them. They do cost a little bit more than normal lightbulbs, but save lots of electricity costs and they also last a lot longer (8000-15000 hours vs. 1000 hours according to Wikipedia).
As I recently bought a NSLU2 ("slug") for 24/7 server usage and random ARM-based development (more on that later), I'm looking for a suitable storage device to use as the root filesystem for a complete Debian system.
The requirements are:
The last item is the most important.
The obvious choice is a USB memory stick, but unfortunately those are flash-based and only survive a certain number of write cycles. Thus I'm looking for something which at least survives enough write cycles to make it usable for a few years...
I do know several ways to reduce the number of writes via software, that's not what I'm currently interested in. I'd like to know which storage types will survive the longest amount of time (because of their hardware properties).
Has somebody else done something like this before and can share some experiences as to which storage type is best suited for such a scenario? I suspect my slug will be mostly idle, but there might also be phases where it runs on 100% CPU and heavy disk I/O for multiple days in a row...