Blosxom 2.1.0 released //at 02:01 //by abe

Today I had the honour to prepare and announce the first Blosxom release after exactly two years and six days.

The primary cause for the Blosxom 2.1.0 release date this week was to get our development efforts of the last two year into Debian Lenny with a nice version number (i.e. one without snapshot dates in the package version ;-). The second biggest cause was that it just was time. But Debian Freezes always give you a good kick in the ass. ;-)

Rhonda plans to prepare an updated blosxom package for Debian during the day. So if Planet Debian is broken in a few days, you know whom to blame: Me and my last minute bug fixes. ;-)

But since you seem to be able to read this, the release shouldn’t be too broken – because of course my blog already runs the very fresh Blosxom 2.1.0 release. ;-)

Conkeror in the Debian NEW queue //at 21:39 //by abe

I already mentioned a few times in the blog that I’m working on a Debian package of the Conkeror web browser. And now, after a lot of fine-tuning (and I still further new ideas how to improve the package ;-) Conkeror is finally in the NEW queue and hopefully will hit unstable in a few days. (Update Thursday, 03-Jul-2008, 18:13 CEST: The package has been accepted by Jörg and should be included on most architectures in tonight’s updates.)

Those who could hardly await it can fetch Conkeror .debs from http://noone.org/debian/. The conkeror package itself is a non-architecture specific package (but needs xulrunner-1.9 to be available), and its small C-written helper program spawn-process-helper is available as package conkeror-spawn-process-helper for i386, amd64, sparc, alpha, powerpc, kfreebsd-i386 and kfreebsd-amd64. There are no backported packages for Etch available, though, since I don’t know of anyone yet, who has successfully backported xulrunner-1.9 to Etch.

Interestingly the interest in Conkeror seems to have risen in the Debian community independently of its Debian packaging. Luca Capello, who sponsored the upload of my Conkeror package, pointed me to two blog post on Planet Debian, written by people being fed up with Firefox 3 already and are looking for a more lean, but still Gecko based web browser: Decklin Foster is fed up with Firefox’ -eh- Iceweasel’s arrogance and MJ Ray is fed up with Firefox 3 and its SSL problems.

Since my previously favourited Gecko based web browser Kazehakase never became really stable but instead became slow and leaking memory (and therefore not much better than Firefox 2), I can imagine that it’s no more an candidate for people seaking for a lean and fast web browser.

Conkeror has some “strange” concepts of which the primary one is that it looks and feels like Emacs:

• The current location is shown in a status bar below the website, where Emacs usually shows buffer names. All input, even entering new URLs to go to, is done via the mini-buffer, an input line below the status bar.

• Instead of tabs it uses Emacs’ concept of buffers. So no tab bar clutter and though easy access to all currently open pages.

• It has no buttons, menu-bar or such. And except the status bar and mini-buffer, it uses the whole size of the window for the displayed web page. This is the main reason why I prefer Conkeror on the 7” EeePC: I don’t want to waste any pixels for buttons or menu bars and still have a fully functional web browser.

• It of course has Emacs alike keybindings (with a slight touch of Lynx). While this may seem awkward for the vi world (Hey, they have the vimperator^*, also in Debian since a few days!), as an Emacs user you just have to remember that you web browser now also expects to be treated like an Emacs. It just works:

  C-x C-c

  Exit Emacs -eh- Conkeror

  C-x C-f

  Open File -eh- web page in new buffer

  C-x C-b

  Change to some other tab -eh- buffer

  C-x C-v

  Replace web page in this buffer and use the current URL as start for entering the new one

  C-x 5 2

  Open new frame -eh- window

  C-x 5 0

  Close current frame -eh- window

  C-x k

  Close tab, -eh- kill buffer

  C-h i

  Documentation

  C-s

  Incremental search forward

  C-r

  Incremental search backward

  C-g

  Stop

  l

  Go back (Think info-mode)

  g

  Go to (Open web page in this buffer)

  (Hehe, I like the faces of vi users having read these keybindings and now wondering how to remember them. SCNR. Well, sometimes vi key bindings are a mystery to me, too. :-)

  There are of course many more and nearly all are the same as in Emacs, even the universal argument C-u and the M-x command-line are there. E.g. C-u g lets you open a web page in a new buffer, too.

• Conkeror also has very promising concept for following and copying links with the keyboard only. Opera is very inefficient here since you have to jump from link to link to get to the one you want. In Conkeror you just press f for following or c for copying links and then all links on the currently shown part of the page show a small number attached to it. Then you just enter the number (and additionally press enter if the number is ambigous) and the link is either opened or copied to the clipboard.

  A funny anecdote about how this concept grew over the time: Early versions of Conkeror (back in the days when it just was a Firefox externsion as vimperator) numbered all links on the page, not only the visible ones. On large pages with many links or buttons (e.g. my blog ;-), this took minutes to complete. The idea to just number the visible links is so simple and important – but someone first needed to have it. :-)

Footnotes

*) I just noticed that there is now also muttator, making Thunderbird look and behave like vim (and probably also mutt), too. Wonder into which e-mail client the Emacs community will convert Thunderbird. GNUS? RMAIL? VM? Wanderslust? What will it be called? Wunderbird? Thunderslust? (SCNRE ;-)

Dilbert.com became even more better //at 16:07 //by abe

nion argued about the new Dilbert.com website now using flash instead of GIFs and I responded that it’s not as bad since Dilbert.com now also officially offers RSS feeds — without Flash.

It looks as if Scott Adams got more responses from nion type people since he divides the feedback to the new Dilbert.com site into three groups: Those who are angry about flash and bloat (mostly techies and linuxers), those who are fine with the design and features, but angry about the slowness due to overload and those who are fine with the design and features and ignore the speed. I’m in none of these groups.

But Scott Adams valued the feedback and responded especially to the first two groups of critics with something for which he couldn’t have found a better URL:

http://dilbert.com/fast

With this pure Dilbert, nion should now be happy again. I still prefer the RSS feeds though.

Dilbert.com changed - to the better //at 13:00 //by abe

nion argues about the new Dilbert.com website now using flash instead of GIFs.

Well, he hasn’t looked right: Dilbert.com offers now flash and static images. And the last ones are now much easier than ever to view or fetch, because Dilbert.com now has RSS feeds. Ok, at the moment, the feed seems broken respectively empty, but I have the last week of Dilbert comics in my feed reader. In colour!

Additionally Dilbert.com is opening its archive. (The link to the blog post currently broken, too.) Back to 2001 is said to be available now, the reminder is in the works

The new Dilbert.com site worked fine yesterday but seems to have some problems today. But I expect that they will fix that soon. :-)

Noticed it btw. because the inofficial Dilbert feed from tapestry included a broken image yesterday. (Works fine now, but no new comic in that feed today…)

Is ikiwiki a Website Meta Language killer? //at 22:29 //by abe

On this year’s Chemitzer Linux-Tage (CLT, engl. “Chemnitz Linux Days’) I attended a few talks of which especially formorer’s ikiwiki talk was very interesting.

I attended his talk since I found out that ikiwiki is command line wiki compiler in contrary to the thousands of solely web based wikis out there. As a big fan of statically generated content this idea sounded very interesting to me.

But just having a short look at ikiwiki’s web page didn’t help to get started and it seemed as if I had not the right idea of how ikiwiki works to get started. So formorer’s talk seemed to be a good possibility to get an idea of how ikiwiki works without much effort.

During the talk I noticed that ikiwiki can many things I do with the Website Meta Language (WML), but can do some more things WML can’t do out of the box:

1. It’s not only a framework to generate web pages, it’s more like a content management system (CMS).
2. Versioning is intergal part of ikiwiki without reinventing the wheel: It works out of the box with — beyond others — Subversion, Git and Mercurical (Hg).

And when formorer showed that even Tobi Oetiker uses ikiwiki, I noticed that ikiwiki probably could be a WML killer, since I knew Tobi as a WML fan. And ikiwiki looks very appealing for the WML fan inside me, too…

OTOH: Intergrating WML as a backend to ikiwiki could be an interesting idea, though.

Hearing what kind of input files ikiwiki can process, I also got the idea of using hnb (Hierachical Notebook) files as input for ikiwiki. hnb files are already XML and so a conversion to XHTML shouldn’t be that hard.

But when searching the web for “ikiwiki hnb” I found the blog postings of a few people switching away from hnb, e.g. to vimoutliner. Since I’m an Emacs addict and don’t like vim very much (if I use a vi, I use nvi or elvis), I searched for “emacs hnb” and indeed found someone who switched from hnb to org-mode – of which I never heard before. Unfortunately org-mode doesn’t seem to be in Debian (Update 00:23: Yeah, yeah, I now know it’s included in emacs22, but emacs22 hasn’t made it into kfreebsd-i386 yet, so I didn’t notice. See the comments. :-) but I’ll play around with it a little bit. Unfortunately a first test wasn’t that promising. But we’ll see.

Now playing: Men at Work — Down Under

WTF per minutes and yet another popular Blosxom-alike I didn’t know about //at 02:42 //by abe

Today while reading Planet Webtuesday, I stumbled upon a nice cartoon about the one and only measurement of code quality: WTF per minute.

Somehow I noticed that the blog in which this cartoon was posted in is powered by Blojsom, a Blosxom derivative written in Java (and nowadays database powered). I already have heard of a lot of blogging software which works similar to Blosxom and often is also named similar, e.g. Pyblosxom or Blosxonomy, but Blosjom hasn’t been noticed by yet although it is mentioned in Children of Blosxom where I first noticed Blosxonomy.

So far, so good, but what really surprised me is that a blog engine developed after Blosxom’s ideas officially made into MacOS X 10.4 Server. (BTW at a time, I neither had a blog nor knew about Blosxom. :-)

Why I’m happy that FreeWRT doesn’t need a web interface //at 15:37 //by abe

When I have to read things like drive-by pharming (via Heise, Symlink article), I’m really happy that there are free 3rd party router firmwares out there, that don’t need any shitty web interface.

My ASUS WL-500g Premium runs FreeWRT and the only possibility to change the configuration is to login via ssh and edit the configuration files as root.

I really pity all those out there who have to cope with the partially really sleazy web interfaces home routers currently offer.