Uwe Hermann | A slightly paranoid Debian developer

According to Jurij Smakov's announcement, the Debian port for 32bit SPARC machines is about to be retired.

This is really sad in my opinion, as we should rather support more architectures instead of less architectures. After all, Debian is "The Universal Operating System" [1].

Now, I know that my opinion doesn't matter much in this case, but many other people who own sparc32 boxes seem to feel the same, judging from the thread which was started by the announcement.

Also, I do realize that nobody wants to retire the port just for fun. To my understanding there is one major problem which needs to be sorted out in order to "save" the sparc32 support in Debian (and also in Linux!):

There is no Linux kernel maintainer for the sparc32 Linux code at the moment!

This seems to be the root of the whole problem. It makes maintaining a Debian port for sparc32 really hard, as you can surely imagine. Also, there seem to be too few people who actively work on the surrounding toolchain stuff (gcc, binutils, etc) which is also very important.

My suggestion would be to not drop the Debian support for now, but rather set the status to "needs help" or something and actively search for contributors and/or maintainers. Heck, list it on Unmaintained Free Software, or write a "call for help" Slashdot article, post the issue on all Linux-/Debian-/SPARC-related mailing lists etc. etc. (or write funny blog posts, heh).

I guess if two or three experienced SPARC developers would step up and take care of the kernel and toolchain maintenance for sparc32, there would be no reason to drop it anytime soon.

Anyone?

There are a gazillion HOWTOs out there for flashing a BIOS image without having to resort to ugly "boot DOS from floppy" or "run Windows *.exe file from BIOS vendor" and other ugly stuff. Unfortunately, the proposed solutions are equally ugly (e.g. creating custom CD-ROMs which contain the "floppy" with DOS/Windows flash tools).

Folks, this is so much simpler than you think:

The flashrom tool (GPL'd, written for LinuxBIOS purposes, but works perfectly fine with proprietary BIOSes, too) will easily do what you want, on a running Linux system. No floppy crap, no CD-ROM crap, no DOS/Windows crap, no rebooting crap.

Install it:

  $ apt-get install flashrom

Detect whether flashrom knows about your chipset/mainboard/BIOS chip:

  $ flashrom

Read the BIOS image into a file:

  $ flashrom -r backup.bin

Write a BIOS image (proprietary or LinuxBIOS) on the ROM chip:

  $ flashrom -wv newbios.bin

WARNING: This will overwrite your current BIOS! Make sure you know what you're doing!

For the Debian-challenged, flashrom is available in source form too, of course:

  $ svn co svn://linuxbios.org/repos/trunk/util/flashrom
  $ cd flashrom
  $ make

The list of supported chipsets, mainboards, and ROM chips is limited of course, but it's constantly expanding. Contact us on the LinuxBIOS mailing list if you want other hardware supported (or even better: if you have patches!). In many cases adding support for new hardware is pretty easy...

As you probably already heard, the GPL, version 3 has been released, together with the LGPL, version 3.

I haven't yet read the licenses in detail, so I cannot say much about them, but more information is available in the (updated) GPL FAQ. The compatibility table from the GPLv3 Discussion Draft FAQ can be pretty helpful, too. There's a Why Upgrade to GPLv3? text and even a video of Richard Stallman (Ogg Theora, transcript available) introducing the GPLv3, the rationale behind it and some of the changes in this new version.

(One nice advantage of the GPLv3 I like is that it's compatible with the Apache license now, btw.)

Probably the most interesting GPLv3 resource at the moment is Palamida's list of projects which already switched to the GPLv3, which includes a number of GNU tools (sed, tar, ed, bison, texinfo, cpio, coreutils) and some other major projects such as Samba. Currently the page lists ca. 140 projects which switched.

It'll be interesting to see how the adoption proceeeds. My guess is that in a few months it'll be hard to build distributions or embedded (GNU/Linux-based) hardware devices without GPLv3 code...

If you're coming to LinuxTag 2007 in Berlin (May 30 - June 2), you might want to also visit the LinuxBIOS booth (Hall 12, Stand 80).

We will be showing a couple of different systems all using LinuxBIOS to boot. There is a boot time competition in the booth (nice T-shirts to win!).

On Saturday there's a hands-on LinuxBIOS workshop by Peter Stuge titled "Bring your EPIA, EPIA-M or EPIA-MII board and make it run LinuxBIOS!". Please register in advance at LinuxBIOS booth (Hall 12, Stand 80).

If you always wanted to know what this LinuxBIOS stuff is all about — here's your chance to find out!

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 mplayer or 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.

• MP3:
  • mplayer, mpg321, aplay, playsound, and splay don't work.
  • $ madplay foo.mp3: 17% CPU load
    
• Ogg vorbis:
  • mplayer, aplay, playsound, and ogg123 don't work.

  • $ apt-get install libvorbisidec-dev
    $ cd /usr/share/doc/libvorbisidec-dev/examples
    $ make
    $ cat foo.ogg | ./ivorbisfile_example | aplay -f cd
    

    Result: 40% CPU load

• MOD, XM, S3M, IT, etc.:
  • $ mikmod foo.mod: 10% CPU load (even with compressed MOD files)
• WAV:
  • $ mplayer foo.wav: 10% CPU load
  • $ aplay foo.wav: 10% CPU load
  • $ playsound foo.wav: 10% CPU load
• FLAC:
  • $ flac123 foo.flac: 17% CPU load
• SPEEX:
  • $ speexdec foo.spx: doesn't work, 100% CPU load. Any known alternatives?
• AU:
  • $ cat foo.au > /dev/dsp: 3% CPU load (but sounds crappy)
  • $ cat foo.au > /dev/audio: 3% CPU load (sounds better)
  • $ mplayer foo.au: 5% CPU load
  • $ aplay foo.au: 5% CPU load
  • $ playsound foo.au: 5% CPU load
• AIFF:
  • $ sox foo.aiff -t wav - | aplay: 50% CPU load (a bit stupid, but it works)
• Streaming MP3:
  • $ mplayer http://www.example.com/foo.mp3: doesn't work, 100% CPU load.
  • $ wget http://www.example.com/foo.mp3 -O - | madplay - : 17% CPU load
• Streaming Ogg Vorbis:
  • $ cd /usr/share/doc/libvorbisidec-dev/examples
$ wget http://www.example.com/foo.ogg -O - | ./ivorbisfile_example | aplay -f cd: 40% CPU load

The SlugAsAudioPlayer page in the NSLU2-Linux wiki might have further information on this topic.

Feel free to add comments if you know of other audio types which can be played on an NSLU2.