While I've only skimmed the available protocol draft and whitepapers, I do have a couple thoughts about wave. Firstly, I can imagine something like this supplanting not just email and instant messaging, but also web forums, blog comments, mailing lists, wikis, bug tracking systems, twitter, and probably various other forms of communication. (But not, apparently, version control systems.) While one might have an attachment to a few of those things, I think most of us would be glad to see most of them collectively die (especially twitter and web forums of course) and be replaced by a data-driven standard, with multiple clients, rather than their general ad-hoc, server-side generated nastiness. (The Project Xanadu guys would be probably be proud.) Secondly, while Google are making all the right noises about open protocols, multiple providers, etc, and probably only plan to lock in about five nines percent of users to wave.google.com before competing implementations arrive, wave is not a fully distributed system. Spec says:

The operational transform used for concurrency control in wave is [currently] based on mutation of a shared object owned by a central master. The wave server where the wave is created (IE that has the first operation) is considered the authoritative source of operations for that wave.

If the master server goes away, it sounds like a wave will become frozen and uneditable. There seems to be no way to change the master server after a wave is created, without ending up with an entirely different wave. (Update: The demo, around minute 70, seems to show a private modification to a wave being made on another server -- so I may be missing a piece of the puzzle.)

The concurrency control protocol will be distributed at some point in the future

How many centralized systems have been successfully converted into distributed systems? In a similar vein, after reading this whitepaper, I'm left unsure about whether it will be possible to respond to (edit) a wave while offline. Maybe, as clients can cache changes, but how well will conflict resolution work? It seems it would have to be done in the client, and there are some disturbing references here to clients throwing their local state away if they get out of sync with the server.

Last weekend I finally managed to travel to Barcelona to visit my family and some friends. As my agenda was quite packed with stuff to do, I was unable to find out if any of the Ubunteros had arrived early for UDS, and I left just after lunch on Sunday. Unfortunately, I had totally missed that before UDS, Canonical held their allhands meeting, and it would have been easy to meet them on Friday night after I got in the city. What a pitty, and sorry about this, mdz, I would have loved to meet... :( In other Barcelona news, I'm sure that UDS attendees will be astonished (or fed up!) by the football crazyness going on right now. Last night I went to a culer bar near Woody and enjoyed watching how Bar a claimed brilliantly their 3rd Champions Cup. For someone who normally doesn't care that much about football, the last few weeks have been incredible. Today I visited my 96 year old grandfather, and even if he has lost much of his expressiveness and energy since the last few months, today he was visibly happy and proud of what his Bar a has managed to accomplish this season. Three titles, plus literally going over Real Madrid in Santiago Bernabeu. Bar a is definitely m s que un club, and I'm happy that my grandfather was able to enjoy it.

Some people asked me how's the book writing is going. Ah you're right, it's a loooong time I didn't say anything of the progress, and here it is.

I've just turned the half of the book: about 10 days ago I've sent the 5th chapter (out of 10) and up to now I've covered this (high-level) contents by chapter:

1. installation & setup
   
2. first contact with mpl
3. some more stuff (like graph types)
4. OO style and some advanced things
5. GTK embedding

6th (and current) chapter is about Qt, so even KDE guys will be happy :)

I found several problems when working with GUI design programs: both Glade and Qt Designer made me scream a lot; but probably it's just me that I'm not so used to GUIs :)

Other arguments will be: Wx, web, real use cases.

In particular for the last part (real cases) I'd like to hear some proposals from you. I've already got something in mind, but users opinion will help me direct my work better.

Sorry, I've got to "drop/reduce" the science chapter (it was superseded by the real use-cases one) since I don't think this is the right place for it. Of course, a couple of "science examples" might come into the mentioned chapter, but your proposals have to be at a low-medium level.

While drinking my coffee, I stumbled over http://www.longurlplease.com/ on Golem.de (sorry, it's German).

They say, that when you get a shortened URL, you

• have no idea where it links to
• are unaware you've been there
• may secretly linked to yucky websites

That sounds correct, esp with the "funny" "new" ideas of the German government about blocking sites with 'Kinder"pornographie"' (sorry for the German again, and for the multi-quotes, but they say I have to call it like this...) and recording those who try to access such sites.

Anyways, that great service over at longurlplease.com will make the world a safer place:

• You see you've been there before
• Tell it links to youtube
• More information before you click

(the lists are copied from their site, without care about proper rewording for my context)

Sounds great, huh? And they even support 65 different shorturl services. But lets see how they support the same service twice in a row (should be easy too, right?).

1. Go to http://tinyurl.com/
2. Create a shorturl for http://gpl.imageafter.com/ (= http://tinyurl.com/oae8sx)
3. Go to http://tinyurl.com/
4. Create a shorturl for http://tinyurl.com/oae8sx (= http://tinyurl.com/r6n74h)
5. Ask the longurlplease.com API about http://tinyurl.com/r6n74h (curl "http://www.longurlplease.com/api/v1.1?q=http://tinyurl.com/r6n74h")
6. See "http:\/\/tinyurl.com\/r6n74h": "http:\/\/tinyurl.com\/oae8sx" as result
7. Laugh and spread double-shortened Rick-Rolls (people will love you!)

That makes the whole service somehow useless, as you gain exactly nothing, and tell longurlplease.com about each shorturl that comes to your browser (if you have the Firefox plugin installed).

On the other hand, the creator could easily add a recursive resolver, but I bet he (or she? or they?) won't do that, when one does not want the service to die completely in a endless loop (I don't have a black hat, neither I have a white one - I actually don't like hats at all, but it should be possible to construct some funny redirection loops with such services).

Update:
It seems tinyurl.com was intelligent and changed that behaviour now:
Error: TinyURL redirects to a TinyURL.
The URL you followed redirects back to a TinyURL and therefore we can't directly send you to the site. The URL it redirects to is http://tinyurl.com/oae8sx.

But one still can fake this:
http://ow.ly/9Arf -> http://tinyurl.com/oae8sx -> http://gpl.imageafter.com/

DebConf9 is getting closer so I was browsing the Internet and the DebConf9 wiki for information. When I'm travelling I enjoy having maps to be able to get around and not get lost. For DebConf8 I relied on TangogGPS with OpenStreetMap on my OpenMoko Freerunner since my laptop is fairly cumbersome and has relatively little battery life these days. For DebConf9 I'll probably do the same since navit doesn't seem too reliable for me yet. During my information gathering for DebConf9 I came across the DebConf9 map overlay and the Madrid free Wi-Fi map. I wanted to have these available in TangoGPS so I wrote a short python script to import them into the TangoGPS POI (points of interest) database. It requires the feedparser and beautifulsoup python modules. First download the GeoRSS feeds you are interested in and then run the script on the machines where you want to use TangoGPS with the filenames as arguments. It only handles points, not lines or polygons since TangoGPS doesn't allow that. Hopefully it will be included in TangoGPS upstream or the Debian TangoGPS package soon. If you want to update the feed you'll need to manually delete the relevant points from the database or remove and recreate the database and then import the feed(s) again.

It has been more than a month since I last wrote about my work on update-manager during this year s Google Summer Of Code and I am somewhat ashamed I wasn t able to provide you with updates more regularly. So first of all, yes, I did do some work and yes, there has been quite some progress. Basically both private and university stuff have kept me from writing and that s why I d like to start with this series of weekly updates today.
This series are meant to summarize what has happened during a week of writing code and give you an overview of what s happening. This first issue however will sum up the past month. So let me begin explaining what has happened since my last post. update-manager bazaar repository All code I have written so far is available through a public bazaar branch on launchpad.net. My branch s page can be found here and provides you with its history and of course instructions on how to obtain the code. The location is only temporary though, as I am going to move hosting over to alioth.debian.org. This is on my task list for next week. modular design I have ripped apart nearly all of update-manager and put it together in a more modular way, which should implementing new frontends or backends more easy, whilst also simplifying code maintenance. The new design consists of four major parts:

• The application class is responsible for parsing command line arguments, initializing all other components correctly and coordinate communication between the frontend and the backend.
• The backend itself is defined through the UpdateManager.Backend.BackendBase class and each implementation subclasses BackendBase. It is responsible for interacting with apt.
• The frontend is again defined through a base class, UpdateManager.Frontend.FrontendBase. This part of update-manager provides the userinterface, handles user input and starts operations accordingly.
• Lastly there is the distribution-specific part, which lives inside the UpdateManager.DistSpecific Python module and is defined by its own base class, DistBase.

backend implementation When I started working on update-manager it heavily relied on synaptic and used it to do the dirty-work. However, together with my mentor, mvo, I decided to drop synaptic support and rather concentrate on using python-apt. This means that the only backend implementation right now is a python-apt backend. The python-apt backend is currently a work in progress, but already includes some basic functionality. Right now it can (re-)load the package cache and package lists and is able to provide a list of packages which are upgradable to the frontend.
Whilst implementing these functions I noticed some shortcomings of python-apt itself, fixed those and got mvo included in his python-apt branch at launchpad. frontend implementation I started re-implementing the Gtk frontend as provided through current update-manager and right now it visualizes the package cache reloading process and provides users with a list of upgradable packages. However, that s pretty much all of the functionality it includes right now, which is why implementing more functions is pretty much on the top of my todo list. Additionally I have ported the text frontend, as included in Ubuntu, to the new modular system, and this frontend s code really shows how easy adding a frontend with the new modular design is. This frontend contains the same functionality as the Gtk frontend. distribution specific code The core described above does not include any distribution specific code anymore, which is the main focus of this project. The implementations of distribution-specific functionality contains classifiers for update categories for both Debian and Ubuntu, whilst I focused on getting things right with the Debian implementation for now. These classifiers allow the frontend to let the user know which kind of update they are about to install, like a security update, a recommended upgrade or a third-party (unofficial) upgrade. documentation As update-manager was poorly (read: hardly at all) documented I started documenting the API using sphinx. However, right now the generated documentation cannot be found anywhere yet. This should change as soon as an alioth project for update-manager has been created. next week s tasks I would also like to provide you with my task list for the coming week. The list, ordered by priority, is:

• Register an alioth project and move the bazaar branch to bzr.debian.org
• Generate an HTML version of the API documentation and put it on alioth.
• Implement changelog-fetching for the Debian-specific module and make use of that from within the code and the Gtk frontend.

As you can see this list is rather short. This can mainly be attributed to a few university assignments, and instead of providing a long list of tasks which I probably won t be able to finish I rather keep the list short and hopefully get things not on this list done too.

Something I have been thinking a lot about lately is why social science and humanities journals have been slower to move toward the land of open access in comparison to the hard sciences. There are a few obvious reasons but there are others which are still a mystery to me. I understand why existing journals can t easily pry away from established relations and obligations so I am not all that surprised that these journals, whether in the hard sciences or soft , have not gone open access. But perhaps newly minted journals are in better position to start right off the bat with an OA agreement. This is what the International Journal of Communication recently did and I am sure there are other examples. So today I was disappointed to find out that the following new Anthropology journal theJournal of Legal Anthropology has seemingly gone down a traditionalist copyright route. But I don t just want to point fingers here as I know editors are often in a very difficult position when seeking sponsorship and support for a new journal. That is, achieving OA, I understand is no walk in the park. And yet given their mission and given that it is a legal journal, it also makes sense to have some sort of open format:

International in scope, we hope it will be accessible beyond a specialist legal anthropology area and, in practice, both widen what is understood within the discipline of anthropology as legal and position the legal as also socio-cultural in terms of contemporary anthropology. The journal is produced by anthropologists interested in making anthropology accessible (translatable) in other settings and disciplines, and by legal practitioners with support from academics working in human rights, conflict and related areas

A walled garden is not suited for the flowers of access to grow. But perhaps they tried and failed. If this is the case, it would also be good to learn of these experiences, which can be used in future cases to pave the path toward greater access.

Something I have been thinking a lot about lately is why social science and humanities journals have been slower to move toward the land of open access in comparison to the hard sciences. There are a few obvious reasons but there are others which are still a mystery to me. I understand why existing journals can t easily pry away from established relations and obligations so I am not all that surprised that these journals, whether in the hard sciences or soft , have not gone open access. But perhaps newly minted journals are in better position to start right off the bat with an OA agreement. This is what the International Journal of Communication recently did and I am sure there are other examples. So today I was disappointed to find out that the following new Anthropology journal theJournal of Legal Anthropology has seemingly gone down a traditionalist copyright route. But I don t just want to point fingers here as I know editors are often in a very difficult position when seeking sponsorship and support for a new journal. That is, achieving OA, I understand is no walk in the park. And yet given their mission and given that it is a legal journal, it also makes sense to have some sort of open format:

International in scope, we hope it will be accessible beyond a specialist legal anthropology area and, in practice, both widen what is understood within the discipline of anthropology as legal and position the legal as also socio-cultural in terms of contemporary anthropology. The journal is produced by anthropologists interested in making anthropology accessible (translatable) in other settings and disciplines, and by legal practitioners with support from academics working in human rights, conflict and related areas

A walled garden is not suited for the flowers of access to grow. But perhaps they tried and failed. If this is the case, it would also be good to learn of these experiences, which can be used in future cases to pave the path toward greater access.

Hola all,
So this is my first blog post since UDS started (although I have been doing some work microblogging this session around (I find that if I treat it like multicast IRC using gwibber, it suddenly makes more sense to me). We're now three days into UDS, and working hard on defining what Ubuntu karmic will be, and I must say I am excited with the way things are shaping up to UNR discussions, to the Android Execution Environment (and if anyone has any questions on it, please direct those emails to Michael Frey and Debbie Beliveau as they are the people behind it, despite Slashdot's reports on the subject).

There are loads going on, including Moblin (which you'll see this afternoon), Android (same), ports kernel handling, and loads of other cool things come up. I'll comment on some of the more interesting things as time goes on.

In other news, as of late last night, I'm officially an upstream KDE developer with SVN commit writes. I've written an email detailing my plans for working on KDE to kde-core-deveonl, where is it is happily stuck in a moderation queue, so hopefully those involved in upstream KDE development will soon learn of my intentions :-).

I'll write more later,
Michael

I finally find time to make another release of Gammu. This time there are major changes in SMS decoding, especially for recent Nokia phones, what should fix several problems seen with previous code. Besides this there is usual bunch of bug fixes. Full list of changes follows:

• Fix code problems caught by GCC 4.5.
• Compile static libraries with -fPIC (they might be later linked into shared ones) (bug #909).
• Handle own number error code in 6510 driver (bug #910).
• Add ID for Nokia 5220 (bug #910).
• Handle SMSC error code in 6510 driver (bug #910).
• Disable gcc warnings about non literal format strings (bug #901).
• Add more fuzzy logic to detect bad encoding from phone (bug #874).
• Add ID for Nokia 7500 and Nokia 7210s.
• Improve searching for Bluetooth stack on OS X.
• Fix ctype compile time warnings on NetBSD (bug #908).
• Nokia 3110c has SMS on filesystem (bug #904).
• Add ID for Nokia 5130 (bug #911).
• Faster reading of Nokia filesystem.
• New PDU decoder which properly parses PDU data.
• AT driver uses new PDU decoder.
• 6510 driver uses new PDU decoder and understands most formats of filesystem Nokia SMS messages (bug #911).

You can download from usual place: http://cihar.com/gammu/, Debian users will find packages in experimental soon, SUSE, Fedora and Mandriva users can check experimental repository in OpenSuse Build Service.

---

What can I say, it's been a while since I last posted something and just lose all the data of my cli .
This happened after I failed to transfer the ROM image to POSE and close the ROM Transfer application.

It isn't the first time I'm welcomed by a blinking "PalmOS Powered" screen (which basically means you have to hard reset it; i.e. erase all data) after soft-resetting it after it freezes or a fatal exception occurs, but I must confess I didn't remember how bad and angry it makes me feel to lose data because of such bugs.

Good news is: now I don't have any, more, data to lose so am free to play with it trying to get uclinux to boot on it.
I just tried an old already-built image of uclinux and was welcomed by Tux on the framebuffer, which felt good :)

Now I need to get the prc-tools back to work so that I can build and try the latest uclinux, which is based on linux 2.6.26 (yes, that's the version of the kernel shipped in lenny!); and probably need to build a serial cable, to get access to the console and start playing with it.

So, here I am, playing with old stuff: a cli , palm os, m68k; who would have guessed.

Hope some day I will see Debian booting on it.

Yesterday I finally found some time to analyze all filesystem message dumps for Nokia phones. I always hated way Gammu used to decode these messages, because in most cases decoding was almost same function just with added some random offsets. After some time looking into the dumps, I finally came out with description of the format. It it still not complete, but it allowed to simplify the code a lot while fixing bugs with some messages previous solution did not catch. Now I hope I did not miss anything and new code will not introduce new regressions.

... you might be bitten by this Java bug rendering arcs as straight lines at large zoom levels.It looks like a classic to me: in order to improve rendering performance, you approximate arcs with straight lines at small resolutions (if it's just 2 pixels big, nobody will be able to tell the difference). Except of course, when you end up doing the same approximation at a large zoom value - of course a 100-pixel circle looks different from a 100-pixel diamond.Reported in 2005, still not fixed in current Java (we're in 2009 now).Sun is really slow at fixing Java bugs.See also a related Apache Batik bug report. Fortunately, this only applies to Java rendered graphics - SVG export, PDF, Postscript are all fine.

As there're several, more or less well working howtos about creating udev rules to allow access to the USB debug devices of Android phones out there in the wild, I decided to write my own one. It works at least for Debian Testing/Squeeze. The udev rules file I provide here works at least for the HTC Dream models (aka T-Mobile G1 and Google Devphone). As a computer may be used by more than one user, I've decided to create a group called androiddev. Members of the group will be allowed to access the debug interface. Running (hint: become root first) addgroup --system androiddev will create the group for you. Add your developers to the group with adduser username androiddev (of course replace username with the user you'd like to add) and we're ready to configure udev. Open /etc/udev/android.rules in an editor and add the following lines:

SUBSYSTEMS=="usb", ATTRS idVendor =="0bb4", ATTRS idProduct =="0c01", MODE="0660", OWNER="root", GROUP="androiddev", SYMLINK+="android%n"
SUBSYSTEMS=="usb", ATTRS idVendor =="0bb4", ATTRS idProduct =="0c02", MODE="0660", OWNER="root", GROUP="androiddev", SYMLINK+="android%n"

Now we need to link the created rules file into /etc/udev/rules.d ln -s ../android.rules /etc/udev/rules.d/90-android.rules and tell udev to reload the rules: /etc/init.d/udev reload That's it. Don't forget to re-login to make sure your new shiny group will show up! Now have fun with adb and fastboot Thanks to TauPan from #debian/freenode.net who gave me the idea for this blog post.

Many people have moaned about SF and the hassle of making a release - if you're in that category and haven't checked with the current file release system at SF, you could be in for a pleasant surprise.

SF has added lots more ways to upload files and has a nice simple interface - I'm just using:
$ scp foo-ver.tar.gz sf-release:uploads

Copy and paste the NEWS and Changelog content into the release announcement and I'm done. It's no harder than Alioth (which was my strong preference before this change at SF).

(This also serves as an announcement that gpe-expenses and pilot-qof have been updated with upstream releases as well as supporting the recent QOF transition.)

Some (not so) short news from the samba packaging team... Recent package uploads:

• Last "stable" upstream branch: 3.3.4. 3.3.4-2 is in unstable, quietly ageing before entering testing. 3.3.4-1 is in testing. In short, we have the latest upstream in squeeze
• Next upstream version: 3.4.0~pre1 is in experimental. That includes many packaging changes as upstream is now providing samba3 and samba4 altogether, which lead to source tree reorganization. Good news: there are no more "FHS" patches and upstream included needed changes for the file layout to finally be able to cope with the FHS entirely.
• We maintain many backports:
  • 3.3.4 was just uploaded to lenny-backports on backports.org. Maybe soon to come a 3.3.4 upload for etch-backports
  • unofficial backports on http://pkg-samba.alioth.debian.org: here we will maintain "the latest upstream version of the same upstream branch than what we have in Debian stable suites". That seems complicated to say and an example says it better: lenny has 3.2.5, so this repository has upstream 3.2.11 with the same packaging than 3.2.5. We made an exception for etch: instead of backporting the latest 3.0 upstream (etch has 3.0.24, upstream has 3.0.34), we backported the latest 3.2: we consider that nobody is now seriously considering to run 3.0, except those people who are very happy with the official packages in etch.
  • All these backports will be useful when tracking down bugs and ask our users if they reproduce them with the latest upstream versions, as samba setups are often very tricky to reproduce in our own environments.

Other things are coming, such as the work on having samba3 and samba4 packages coexist. Jelmer Vernooij prepared everything after our discussions at the SambaXP conference and it should be uploaded "soon". A few patches we have should be integrated upstream as well, therefore making the Debian diff smaller and smaller. Also, Luk Claes joined the maintenance team and helped setting up the unofficial repository for backports. The bug count is going up again these days as I don't spend much time triaging the bugs and some are very tricky to reproduce. As usual, help would be welcomed. I'm fairly sure that several of these are user errors but I often lack time to prove this enough for closing the bug. We should go to to 50-60 bugs or so.

So, I'm considering a backup system that has as its goal to let you backup all your data from third party websites, easily. The idea I have for its UI is you enter in the urls for all the sites you use, or feed it a bookmark file. By examining the URLs, it determines if it knows how to export data from each site, and prompts for any necessary login info. The result would be a list of sites, and their backup status. I think it's important that you be able to enter websites that the system doesn't know how to handle yet; backup of such sites will show as failed, which is accurate. It seems to almost be appropriate to have a web interface, although command-line setup and cron should also be supported. For the actual data collection, there would be a plugin system. Some plugins could handle fairly generic things, like any site with an RSS feed. Other plugins would have site-specific logic, or would run third-party programs that already exist for specific sites. There are some subtle issues: Just because a plugin manages to suck an RSS feed or FOAF file off a site does not mean all the relevant info for that site is being backed up. More than one plugin might be able to back up parts of a site using different methods. Some methods will be much too expensive to run often. As far as storing the backup, dumping it to a directory as files in whatever formats are provided might seem cheap, but then you can check it into git, or let your regular backup system (which you have, right?) handle it.

---

Thoughts, comments, prior art, cute program idea names (my idea is "?unsilo"), or am I wasting my time thinking about this?

Lenny well supported We re pleased that Lenny released with good support for the Eee PC and are now turning our efforts to make Squeeze even better, while continuing to provide support for our Lenny user base. The standard Lenny installer can install Debian on all models of Eee and our custom installer provides the ability to install over wireless for almost every model (more about this later) from a very small image. The latter continues to be our recommended install method, since in addition to being wireless-ready, the custom installer also handles a few other small eee-specific configuration chores to make as much as possible just work right after the install. Solid mainstream support We ve made good on our promise to make Debian work on the Eee PC, not a derivative, many of which use a custom kernel instead of the stock kernel as we do and use a special desktop instead of our users favourites. While we agree that some intriguing things can be done in these areas, it is no substitute for mainstream support. Our users are better served by a solid foundation than specialised modifications that limit their choices. We want them to be able to enjoy the freedom to mold Debian, the universal OS, into whatever suits them best. Squeeze support started Work is well underway on supporting all Eee models in Squeeze. For months, several team members have been experimenting with new kernels, producing support for them in eeepc-acpi-scripts. The current release of this key package (version 1.1.0) supports Linux 2.6.29 and contains enhancements for wifi, sound hotkeys, bluetooth, external displays and OSD. Squeeze will support wired & wifi on all current models With the appearance of 2.6.29 in Sid, all ethernet and wifi cards used in all models of Eee today are supportable without the need for out-of-kernel or non-free drivers. Madwifi is replaced by the free ath5k driver, the non-free rt2860 package is replaced by mainstream kernel support, (though it still requires non-free firmware provided separately,) rtl8187se is included, making it possible now for us to support the model 701SD, and ath9k is included, making full support for newer models such as the 1000HE possible. Lenny backports and live demo All of these changes can be enjoyed today by Lenny users. Just add Daniel Baumann s Lenny kernel backport repository and then install the 2.6.29 kernel and an updated acpid. See our upgrade howto for details. You can try a small (less than 256M) demo of this configuration by downloading beta 2 of our Live USB image. Accessibility Late last year, we discussed how to make it easier for the blind to install Debian unassisted on their Eee PCs. As it was a simple change, we now include brltty in the custom installer, but we understand that some users also need software synthesized text-to-speech, something for which there is no support yet in the standard Debian-installer. We understand this isn t an easy thing to fix, but hope someone will rise to the challenge. Growing team of developers We welcome Darren Salt and Raphael Geissert to the team this year. Both have been actively making contributions to the eeepc-acpi-scripts package over the past months, fixing some outstanding bugs and readying it to handle changes in more recent kernel releases. Moved eeepc.debian.net to new hosting Nico Golde, who hosted eeepc.debian.net for the first year development, has turned his focus to other areas of Debian. Glenn Saberton has stepped in to provide a new home for it. We thank them both for their efforts and for a smooth, uneventful transition from one host to the other. Size of user community Speaking of the move, earlier this year, Glenn shared with us some interesting archive traffic statistics that give us a rough idea how many users we have. For the months of December and January, after factoring out bot hits, we were seeing about 300,000 hits from 15,000 unique users per month. The site handles roughly 60G of traffic per month, most of that from thousands of downloads of our custom installer image. It s hard to draw any firm conclusions about the size of our user base from these stats, as many users may be on dynamic IP numbers, inflating the numbers, but we can conservatively say we have at least 5000 users. Other interesting statistics are that we have anywhere up to 80 users at any given time on our irc channel and over 250 users on the mailing list. Help wanted The Asus Eee PC line continues to expand, with 24 models listed so far. It is a challenge to keep up support for all of them. We re encouraged to see Asus choose a new b/g/n wifi chipset for their 1002HA that is supported by a DFSG free driver ath9k in this case. It appears that the new Atom N280-based 1000HE uses the same chipset as well (though be careful: I know of at least one user who bought a 1000HE in Argentina expecting it to have this chipset and was disappointed to find it had the Ralink chipset instead, we guess because of availability). If this trend continues, we ll be that much closer to our goal of full support for Squeeze main. As it stands, we re already as close as we can get given the state of rt2860 and no prospect on the horizon for replacing the non-free firmware. If you would like to help us out in any way, whether by testing, debugging, patching, or improving our documentation, get in touch with our team. We rely on your feedback to keep Lenny in good shape and work towards making Squeeze even better for all users of Debian on the Eee PC.

A few dud universes can really clutter up your basement. - Neal Stephenson, In The Beginning. . . was the Command Line

What a fun read. It s about technology, sure, but more about culture. Neal takes a good look at operating systems, why we get emotionally involved with them, and why Windows is still so popular. He does this with a grand detour to Disneyland, and a hefty dose of humor. The above quote was from near the end of the book, where he imagines hackers creating big bangs from the command line. He starts out the book from some anecdotes from the early 1970s, when he had his first computer class in high school. His school didn t have a computer, but they did have a teletype (the physical kind that used paper) with a modem link to some university s system. But time on that system was so expensive that they couldn t just dial in and run things interactively. The teletype had a paper tape device. You d type your commands in advance, and it would punch them out on the tape. Then when you dial in, it would replay the tape at high speed . Neal liked this because the stuff punched out of the tape were, actually, bits in both the literal and the mathematical sense. This, of course, led to a scene at the end of the schoolyear where a classmate dumped the bin of bits on the teacher, and Neal witnessed megabytes falling to the floor. Although the book was written in 1999, and needs an update in some ways, it still speaks with a strong voice today and is now also an interesting look at what computing was like 10 years ago. He had an analogy of car dealerships to operating systems. Microsoft had the big shiny dealership selling station wagons. Their image was all wrapped up in people feeling good about their purchase like they got something for their money. And he said that the Linux folks were selling tanks, illustrated with this exchange:

Hacker with bullhorn: Save your money! Accept one of our free tanks! It is invulnerable, and can drive across rocks and swamps at ninety miles an hour while getting a hundred miles to the gallon! Prospective station wagon buyer: I know what you say is true but er I don t know how to maintain a tank! Bullhorn: You don t know how to maintain a station wagon either! Buyer: But this dealership has mechanics on staff. If something goes wrong with my station wagon, I can take a day off work, bring it here, and pay them to work on it while I sit in the waiting room for hours, listening to elevator music. Bullhorn: But if you accept one of our free tanks we will send volunteers to your house to fix it for free while you sleep! Buyer: Stay away from my house, you freak! Bullhorn: But Buyer: Can t you see that everyone is buying station wagons?

That doesn t mean that Stephenson is just a Linux apologetic. He points out that the CLI has its place, and has a true love-hate relationship with the text-based config files (remember XF86Config before the days of automatic modelines? Back when you had to get out a calculator and work some things out with pencil and paper, or else risk burning out your monitor?) He points out that some people want to just have the thing work reasonably well. They don t want control in fact, would gladly give it up if offered something reasonably pretty and reasonably functional. He speaks to running Linux at times:

Sometimes when you finish working with a program and shut it down, you find that it has left behind a series of mild warnings and low-grade error messages in the command-line interface window from which you launched it. As if the software were chatting to you about how it was doing the whole time you were working with it.

Even if the application is imploding like a damaged submarine, it can still usually eke out a little S.O.S. message.

Or about booting Linux the first time, and noticing all sorts of cryptic messages on the console:

This is slightly alarming the first time you see it, but completely harmless.

I use emacs, which might be thought of as a thermonuclear word processor. . . Microsoft Word, were devoted to features like mail merge, and the ability to embed feature-length motion pictures in corporate memoranda, were, in the case of emacs, focused with maniacal intensity on the deceptively simple-seeming problem of editing text. If you are a professional writer i.e., if someone else is getting paid to worry about how your words are formatted and printed emacs outshines all other editing software in approximately the same way that the noonday sun does the stars. It is not just bigger and brighter; it simply makes everything else vanish. For page layout and printing you can use TeX: a vast corpus of typesetting lore written in C and also available on the Net for free.

I love these vivid descriptions: programs secretly chatting with us, TeX being a corpus of typesetting lore rather than a program. Or how about this one: Unix. . . is not so much a product as it is a painstakingly compiled oral history of the hacker subculture. It is our Gilgamesh epic. Yes, my operating system is an oral history project, thankyouverymuch. The book feels like a weird (but well-executed and well-written) cross between Douglas Adams and Cory Doctorow. Which makes is so indescribably awesome that I can t help but ending this review with a few more quotes.

Because Linux is not commercial because it is, in fact, free, as well as rather difficult to obtain, install, and operate it does not have to maintain any pretensions as to its reliability. Consequently, it is much more reliable.

what really sold me on it [Debian] was its phenomenal bug database (http://www.debian.org/Bugs), which is a sort of interactive Doomsday Book of error, fallibility, and redemption. It is simplicity itself. When had a problem with Debian in early January of 1997, I sent in a message describing the problem to submit@bugs.debian.org. My problem was promptly assigned a bug report number (#6518) and a severity level (the available choices being critical, grave, important, normal, fixed, and wishlist) and forwarded to mailing lists where Debian people hang out.

That should be our new slogan for bugs.debian.org: Debian s interactive Doomsday Book of error, fallibility, and redemption.

Unix is hard to learn. The process of learning it is one of multiple small epiphanies. Typically you are just on the verge of inventing some necessary tool or utility when you realize that someone else has already invented it, and built it in, and this explains some odd file or directory or command that you have noticed but never really understood before.

I ve been THERE countless times.

Note the obsessive use of abbreviations and avoidance of capital letters; this is a system invented by people to whom repetitive stress disorder is what black lung is to miners. Long names get worn down to three-letter nubbins, like stones smoothed by a river.

It is obvious, to everyone outside of the United States, that our arch-buzzwords, multiculturalism and diversity, are false fronts that are being used (in many cases unwittingly) to conceal a global trend to eradicate cultural differences. The basic tenet of multiculturalism (or honoring diversity or whatever you want to call it) is that people need to stop judging each other-to stop asserting (and, eventually, to stop believing ) that this is right and that is wrong, this true and that false, one thing ugly and another thing beautiful, that God exists and has this or that set of qualities.

The stone tablets bearing the Ten Commandments carved in immutable stone the original command-line interface

Apparently this actually works to some degree, for police in many lands are now complaining that local arrestees are insisting on having their Miranda rights read to them, just like perps in American TV cop shows. When it s explained to them that they are in a different country, where those rights do not exist, they become outraged. Starsky and Hutch reruns, dubbed into diverse languages, may turn out, in the long run, to be a greater force for human rights than the Declaration of Independence.

Unix has always lurked provocatively in the background of the operating system wars, like the Russian Army.

Available for free online, or as a 160-page book from Amazon.