The Betacantrips Travelogue

I spent a few hours today dicking with my N900 and thought I’d write up some of the things I dealt with.

For a long time I’ve been using Dropbear SSH client/server on my phone, due to an alleged less-memory-usage. (When your phone starts swapping, it sucks big time.) Dropbear even supports serving SCP, but does not support SFTP. This prevents you from using any relatively-nice "file transfer over SSH" GUI, such as Nautilus’s "ssh" support or gFTP. (I think Konqueror’s fish mechanism would still work, but that is of limited utility to me right now.) It may be possible to use the sftp from OpenSSH with dropbear, but since the Dropbear packages conflict with the OpenSSH packages in the Maemo repository, that’s not especially on an N900. In fact, dropbear-scp conflicts with openssh-common (both provide /usr/bin/scp, which I think is silly, but there you are).

Of course, if you insist on using Dropbear, you can use Bluetooth to copy files over Obexftp (which Nautilus supports nicely). But since this requires Bluetooth hardware to be powered on both the laptop and the phone, I decided to replace Dropbear with OpenSSH.

Installing OpenSSH server on your N900 forces you to change your root password (the default is "rootme"), whether you’ve already changed it or not. Kind of annoying. The user account by default "doesn’t have a password", which I think means all password access is disabled. Folk wisdom suggests that giving a password to the user account "could" cause problems, but I think this is based on an (incorrect) belief that the default password is "blank" (in fact, it’s invalid, meaning there is no phone software that relies on using a password to switch to the user account, so there should be no problem with granting a password). Nevertheless I decided to just drop in a key using authorized_keys. But if you don’t set a password, OpenSSH won’t let you log in (even using publickey access); the log messages will tell you that your account is "locked". The reason is that OpenSSH looks at /etc/passwd to decide whether to let you in using any access methods at all; since the password hash is "!", it locks you out.

This page shows how to fix the "locked account" status.

I saw Emacs Got Git, sometimes called "Egg", listed on the list of git-related software on the git wiki (although now taken down) and of course on the EmacsWiki. I decided I’d give it a whirl. The most recent version I could find was the one listed on the EmacsWiki, the version from bplayer, which seems to still be actively developed. The incumbent here is either magit, which is by far the best user interface I’ve ever seen for any version control anywhere, or VC mode, which was written once to support SCCS and has largely survived unchanged since then.

A brief digression about magit and vc-mode. Magit is a little bit of a challenge to pick up: you actually have to read the manual. But the short version is: M-x magit-status to open a view of your repository, and then TAB things open and closed. You can press "s" to stage files, hunks, or even "highlight" lines using the region and stage only those. "u" to unstage; "c" to start a commit, and then C-c C-c to make the commit. You can create a commit that amends the previous commit by pressing C-c C-a in the log message buffer. It probably offends some that there are already conventions here for VC system integration, notably vc-mode. But vc-mode takes a file-based view of version control, has no support for staging hunks, and in general just doesn’t feel good to use. magit is much better — so much better that it is easily worth the break in convention.

So I thought I’d check out Emacs Got Git, to see if it was any better than magit. This isn’t a detailed analysis — actually I’ve probably spent longer writing this post than I did looking at Egg.

I find a screenshot is worth a thousand words. On my ~/etc repository, magit looks like this:

Magit highlights all the important details: which files are changed? Which are untracked? What commits exist locally that don’t exist on the remote?

On the same repo, Egg looks like this:

This is what we call the "angry fruit salad" school of UI design. Also, it doesn’t have a section for "unpushed" commits.

I’m going to be sticking with magit for the forseeable future.

Seen on LWN, an article about porting an application from C# to Java. Punchline: automated translation. Quote:

The inspiration for this was an article about Boeing and automatic conversion. Well we thought "if Boeing can do it so can we". Sounds stupid? Well it is. Luckily for us we did not think that at the time.

I’ve been spending a bit of time steeping myself in EmacsLisp these last few days. I’ve been looking for information on elisp "best practices" — specifically, is it OK to rely on (require 'cl)?

Here’s one page wondering the same thing. There’s always a ton of interesting stuff whenever you go poking at emacs packages; most surprising to me this time around was ELPA, the Emacs Lisp Package Archive. Perl has CPAN, Python has PyPI, Ruby has Rubygems.

I also found the blog emacs-fu pretty interesting looking — approximately one post a week, I think. Lots of stuff I wish I could absorb better.

Emacs Coding Conventions from the Elisp manual is also pretty helpful. To this point (about CL), it says:

Please don’t require the cl package of Common Lisp extensions at run time. Use of this package is optional, and it is not part of the standard Emacs namespace. If your package loads cl at run time, that could cause name clashes for users who don’t use that package.

However, there is no problem with using the cl package at compile time, with (eval-when-compile (require 'cl)). That’s sufficient for using the macros in the cl package, because the compiler expands them before generating the byte-code.

For me, this is enough, because I want to use dolist. But there are programmers out there like David O’Toole, who writes in his interactive guide to the GNU Emacs CL package:

Despite what people say about still being able to use the macros while complying with the policy, in my opinion the policy is still a discouragement. You have to memorize which of its features you must abstain from using (and therefore lose the benefit of those features) if you are to have any hope of someday contributing Lisp code to GNU Emacs.

I think the GNU Emacs maintainers are hesitant to allow use of a package, like cl, which isn’t "namespaced". I bet if all the functions in cl were prefixed with cl-, nobody would mind…

[Update, 2010-Apr-27: From an email on the magit email list:

There's also the small matter that many of the function implementations in cl, striving for the full generality of Common Lisp (much of which is completely useless in Emacs), turn out to be horrible.

E.g., for a fun time, dig down through

(find-if pred list :from-end t),

and look at what it ACTUALLY does when you finish macroexpanding everything. It tests every element of the list against the predicate, not just the rightmost ones stopping when it finds the first match. Once it determines the rightmost match, it then retains NOT the element itself, but its ordinal position N, which then gets used in (elt list N), meaning ANOTHER listwalk, just to get the element back in order to return it. Nor is the byte-compiler anywhere near smart enough to optimize this away (I'm not sure any compiler would be...)

I'll grant cl has some useful macros in it, but it comes bundled with a lot of crap and you need to be really careful about what you use. For many things, you're better off rolling your own functionality using the standard routines available (e.g., while, mapcar, and reverse are all written directly in C).

And you most definitely do NOT want to be foisting the crap on everybody else, hence the need to keep it out of the runtime.

Thanks!]

Seen on Planet Debian: ‘Can you get cp to give a progress bar like wget?’ The solution starts:

#!/bin/sh
cp_p()
{
   strace -q -ewrite cp -- "${1}" "${2}" 2>&1 \
...

The author notes in the comments:

If you feel the need to point out an alternative solution, then you have missed the entire point by a wide margin.

—lamby

At PyCon, I saw a lightning talk about scrape.py, a lightweight Python library for parsing webpages/interacting with them programmatically. For example, finding page elements:

>>> from scrape import *
>>> s.go('http://zesty.ca/')
<Region 0:17780>
>>> d = s.doc
>>> t = d.first('title')
>>> t
<Region 247:258 title>
>>> t.tagname
'title'
>>> t.text
u'Ka-Ping Yee'

The presentation I saw focused on the use case of testing your website. This is definitely a pain point for me personally: I currently either grep the HTML with regexes or I parse the whole thing using ElementTree and use XPath. But there’s still a couple of problems: 1. JS isn’t usually testable this way; 2. you often have to construct your HTML with an eye towards testability. For example, to test pagination, you might need to add a class or id specifying that this is the pagination section and that these pages link to pagination things.

One of the neat things I saw at PyCon was a project called OpenHatch, which (among other features) indexes bugs and makes them easy to find according to your skillset and experience level. For example, lots of projects tag bugs as "easy" or "beginner" to promote newbie involvement and ramp-up; openhatch makes it easy to get involved with a project you can contribute to.

I think there’s still some work to be done — bugs about "you need a better logo" or "help, our docs are crap" don’t quite fit into this workflow. Still, good effort.

Did you know (via the Debian NEW and BYHAND package list) that there’s a new kid on the IM software block? Behold: instantbird, based on the XUL framework and the pidgin libpurple codebase.

Instantbird is a multi-protocol Instant Messaging client. Using it, you can connect to all your different IM accounts.

It uses the Mozilla rendering engine to display IMs, and the Pidgin libpurple to connect to the different networks.

Thanks Adam — how to safely store a password.

Use bcrypt. Use bcrypt. Use bcrypt. Use bcrypt. Use bcrypt. Use bcrypt. Use bcrypt. Use bcrypt. Use bcrypt.

Good to know!

Some coverage of the recent announcement: Nokia, Intel merge Maemo, Moblin into Meego on Slashdot, Moblin and Maemo to merge on LWN, Maemo + Moblin = MeeGo = Failure on Planet Debian. Some quotes:

A stupid name is a prerequisite for being a successful FOSS product. Nokia and Intel have clearly done their homework.

Also indicating huge potential, MeeGo has already ignited a flamewar between RPM and DEB supporters. Welcome to the community!

—EvilTNUser (here)

And:

Today, Nokia and Intel announced the merge of Maemo and Moblin into the MeeGo project. This is sad, because it will end the era of the Debian-based mobile operating system Maemo and replace it with a system using RPM and probably some other evil stuff as well. In fact, dpkg & apt-get where two of my main reasons to buy the N900.

And another question is why yet another name. Moblin was already a well-known name and they shouldn’t have changed the name just because they switch the servers and add some Nokia developers.

Furthermore, does this all mean that there will be no Maemo 6? What will happen to the Maemo users on the N900, will it be possible for them to use MeeGo?

I recently bought an N900 (very recently — like, using it four three or four days now. Review forthcoming) and I have to admit to a few moments of shock and terror. But having thought things over, I’m giving in to "cautious optimism". Here’s my take on it:

1. Like Julian Klode, my getting an N900 was prompted by my extremely positive experience on the Nokia N810. And it’s true that part of that experience was the discovery you can apt-get pretty much anything in the Debian repository. But the mechanism whereby this occurs is a little subtle: although apt-get is the application-installation mechanism for Maemo apps, the Maemo repositories aren’t really compatible with Debian. You can’t just open a terminal and sudo apt-get install emacs. Cross-compiling Debian packages is possible but (in my experience) a really bad idea; I broke APT on my N810 this way.

   The preferred mechanism for getting access to the Debian repository is a package, installable by default, called easy-deb-chroot. As you might guess, what this does is to set up a Debian chroot, wherein you have free range of whatever you want to do. In other words — the mechanism by which applications are installed by default on the device is completely independent of having access to the Debian universe. This is important: it means they can switch to RPM for installing packages, and still give us our easy-deb-chroot, which is what we really want anyhow.

2. I’m surprised that they chose a new name — I think both Maemo and Moblin have great brand recognition in the community.

Nokia is the only hardware company in the mobile space that I think really "gets it" (some examples occur to me). Intel has been making strides towards getting it. And best of all, there are no telecoms involved in MeeGo yet. For these reasons, I’m going to take a wait-and-see approach. After all: there’s lots of work ahead of us if we’re going to build a better mobile stack than Google and Apple.