The not-slug: SheevaPlug

popcon lists approximately 1000 arm/armel Debian installations. There is also listed 864 installations of nslu2-utils, letting us estimate that approximately 85% of debian/arm(el) installations are Linksys nslu2's. It is nicked sympathetically as "The Slug", which pretty accurately describes the performance of nslu2. Still, people have found absolutely amazing amount of ways to use their slugs. What would you do with something approximately 10x more powerful with same prize/size range?

Enter the Marvell SheevaPlug

| What | Slug     | SheevaPlug |
| CPU  | 266Mhz   | 1.2Ghz     |
| Cache| 32KB     | 32+256KB   |
| Flash| 8MB      | 512MB      |
| MEM  | 32MB     | 512MB      |
| Net  | 100Mb    | 1Gb        |

And that's not everything - SheevaPlug comes with SDIO slot and miniusb to be used as a serial console (and JTAG). No soldering needed for hacking.

Some more details on the LinuxDevices article.

For those of you who think that has one port too few of something, or don't like the wall-wart design, Other devices based on kirkwood SoC (which SheevaPlug is based on) are on the way from various ODM/OEM houses.

obligatory lenny post

In practice for me, this that I finally had to setup stable buildd chroots for armel (ya!). This makes the Debian the first general purpose distribution to release with a ARM EABI port. Thanks for everyone who made this happen, even when the naysayers were claiming that Debian would be too inflexible for another arm port! The list of people who made this possible is simply too long to include in a blog post, and I'm afraid I would still forget someone...

For squeeze, I hope we can keep the name as the release theme and squeeze minimal Debian install into smaller disk and memory than what it takes with lenny :) For more specific squeeze plans on the armel port, we are looking at least into providing optimized versions of various libs (using HWCAP feature) and extending the amount of hardware supported. Not ARM-related directly, but I'd really like to see #206684 fixed finally.

re: how many bugs have you fixed today?

Sorry Bastian, but that marthyrdon thing doesn't work. Debian has no shortage of talkers, GR-proposers, etc. We have shortage of people of actually doing stuff. Therefor it's only fair that people not bothering fixing bugs get criticized too. And not to mention that there is enough RC bugs open that you could *easily* fix one of them before making another blog post.

This post has been brought to you by fixing #508781 and #496104. (Can I has a meme plz?)

ps, that said, pretending reaching 0 RC bugs means we have a perfect release is delusional. Bugs are found at constant rate. If we fixed bugs faster and reached 0 RC bugs a month a go, the released lenny would now have all the RC bugs found during this month. Therefor it would make much more sense to align the release schedule based on something else, such as d-i schedule and fix any RC bugs left at that point with stable release updates. update: As noted by Dato, the release update essentially says the same.

armel/experimental buildd running

As the continued freeze of lenny has driven lots of interesting uploads to experimental, it was finally time to setup a armel buildd for lenny. It' now approximately half away done, and with the current rate it should be building the last package of the queue (openoffice) in the end of this week.

Our priorities are literal interpretation of SC and DFSG

The vocal extremists are not writing free software replacements for the propiertary firmwares. The only offered solution is "remove those non-free firmwares". That disconnects real world users from free software we provide. Which is directly against the *spirit* of SC:

Our priorities are our users and free software.

4222213

I am willing to change my opinion as soon as there are free firmwares for pc peripheral devices.

pimp my x40

After a brief look at the market, I decided to keep using my sturdy X40. Looking at what could be done to improve the 4 years old workhorse, three things came to mind:

* new battery (old one dies in 45min, new one lasts easily 5+h)
* replace the hard drive (preemptively before it breaks)
* more ram (from 512MB -> 1.5G)



The only one worth detailing is the hard drive upgrade, since I decided to go SSD. less moving parts, less heat, less power consumption. I followed the Thinkwiki CompactFlash boot howto. This basically involves getting a CF-IDE adapter (from ebay, around $5) and any CF card. The first CF-IDE adapter $2.99, but it didn't work. After some research it was concluded that the SMT soldering was bad. The second adapter bought worked fine, and as a bonus the dimensions match the X40 HD perfecty:

In order to minimize writing to flash:

* Make sure root filesystem is mounted noatime,nodiratime (see /etc/fstab)
* make /tmp a tmpfs partition
* disable swap
* more tips can been seen at Linux on Flash guide

Generally I'm very happy with the results of the upgrade. X40 is now most of the time completly silent, without the spinning and clicking HD. Fan turns on less often than previously. The cheapo compactflash is fast enough on reading, and the REALLY slow write speed is usually not a problem thanks to the loads of RAM. Ofcourse, the exception is when a application uses fsync() ... which leads to.

FIREFOX SUCKS GOAT BALLS WHEN RAN FROM A SLOW SSD

Seriously. It's like watching snail cross a tarpit. That's what happens when you fsync() a 30MB places.sqlite on a 6MB/s write speed flash media every fucking time a page has finished loading (and seeming every now and then too). Now here's a really simple workaround: make ~/.mozilla tmpfs and rsync it to/from a backup dir every time you log in/out.

* /etc/fstab: tmpfs /home/user/.mozilla tmpfs size=100m,user 0 0
* and two helper scripts:

aardvark:~$ cat bin/mozilla-mount
#!/bin/sh
mount /home/$USER/.mozilla
rsync -av /home/$USER/.mozilla-safe/ /home/$USER/.mozilla/
aardvark:~$ cat bin/mozilla-umount
#!/bin/sh
rsync -av /home/$USER/.mozilla/ /home/$USER/.mozilla-safe/
umount /home/$USER/.mozilla

It does what mozilla should be doing in the first place - write to temporary files when running and on exit synchronize to the real database and fsync(). With this hack, suddenly the web browser UI doesn't freeze every time a page has finished loading.

You'll also want to disable the urlclassifier anti-forgery tool, which can grow to a over 50MB sqlite database which also gets fsynced all the time...

When Linux doesn't mean freedom

I actually think it's a bit of an insult if people think of Motorola's EZX or MAGX (and now Android) phones as "Linux phones". Because all the freedoms of Linux (writing native applications against native Linux APIs that Linux developers know and love, being able to do Linux [kernel] development) are stripped.

- Harald Welte

This is something that has worried me too for quite a while. For years we have now had Linux phones available in form or another (well, mostly in far away countries you happen not to be at). Yet with the exception of openmoko none of them allow native application development. Yet all the same time you can go to the nearest phone shop and grab HTC windows CE phone or a Nokia Symbian phone, which actually give you the freedom to writing and running your own software on them.

Now we have the situation that HTC's most locked device* is their only Linux device - The Android G1.

Incidentally, you can install Debian/armel on T-mobile G1, but only until Google engineers manage to fix the hole that gives you r00t.

*The only one that doesn't allow native app development.