---

in which the Pre unsuprisingly continues to suck My Palm Pre was killed by a forced over the air WebOS upgrade. You can't avoid those upgrades, even if you are sure they'll be bad news. The previous WebOS upgrade spared my Debian partition, but lost all other customizations (including Palm Pre privacy fixes), and wasted hours. When I went to use my phone and it didn't even boot, and displayed only "http://palm.com/rom", I knew that was the last straw. (Shouldn't forcing an upgrade that breaks a working phone to the point that it can't even call 911 be well, illegal?) switching cell providers in the US: suprisingly doable I thought about ditching the smart phone and using VOIP, but I seem to have gotten addicted. So I got a Droid. That meant switching cell phone companies. I've heard a lot about how horrible the US cell phone company contracts are. My experience has me wondering if all that is well... not overblown, but oversimplified. I was half a year into a two year contract. Today I got my closing statement, and I really got out of it with no early termination fee. The trick seems to be, switch to a different cell phone company. They'll be happy to get you out of your old contract, salivating at the chance of locking you in to a new one. They probably have a script to use when calling to cancel. Or "know a guy". Or claim to know a guy, then just use a script, and get lucky. Given the hard sells and vague promises they tried on me, I assume that these places are where all the car salesmen ended up. Trust == 0. But it worked. If you're good on the phone, and are looking for a new business idea: Start a business of getting people out of their cell phone contracts, for a reasonable fee and no other obligation. Use loopholes like rate changes. As long as the cell phone companies can raise their monthly rate 2 cents, and 99.9999% of their users accept it, and they make untold millions of dollars, for free, they seem to not care if the remaining fraction use a loophole to get out. Especially if they're able to take advantage of other comanies loopholes to switch over users. So there seems to be a niche there in which one could prosper. droid first impressions So now I have a slightly larger lump in my pocket and the Pre is on a shelf, and will either be used for future development and testing of Debian piggyback ideas, or donated to someone like Lennart who can make good use of it. Compared with the Pre, the droid's hardware is all superior. The keyboard, especially, is great, with arrow keys, and all the symbols I need. At the same time, the phone is bigger, and oddly clunky. But in an endearing way. Only thing I really dislike about the hardware is the "back" button is easy to accidentially swipe while typing on the keyboard. Compared with WebOS, the Android UI has some clunkiness and non-obvious things. Like the status bar at the top not doing anything when you click on it. And there being no way to close an app. Especially annoying is that this means opening the web browser returns to whatever page I was on last, which is never what I want. The UI is however much, much snappier. I don't use the Google email, etc services so can't comment on them; I assume the amount of info Google is gathering about me went up by a few percentage points; I've blocked their analytics on my network to knock it back down. (PS: DuckDuckGo now avoids logging IP addresses at all.) The best thing is the ConnectBot application, which is a very usable shell and ssh client. It's a terminal, in my pocket, which I can easily use for an hour without feeling like my interactions are feeding through a stifling soda straw. Between the keyboard and the app, the Pre has nothing at all that compares. Under the hood, Android annoys me terribly, with its lack of busybox, its kernel that does not even have the ext* filesystem, its hard-partitioned storage, and its general lack of every single thing I like in a Linux system. Compare this with the Pre, which has a package manager, a userspace based on busybox with a full standard Linux stack (all the way up to PulseAudio) and a kernel with lots of standard filesystems, and even LVM. Sigh. It's amazing that WebOS and Android have found such broadly different ways to suck. There is significant interest and activity around running a Debian chroot on the Droid. The best tries so far put it on a loop mounted ext2 filesystem (which means you need to get ahold of a matching ext2.ko somehow), living on the FAT formatted SSD. And there are apparently some bad problems with IO to that starving/locking the system, so I have not tried it.

And now for the third image this week, I'm not really too happy with todays shot, I will hopefully get outside during lunch tomorrow.

So, from the last post, it appears that most people got fed up with trying to get twirssi working in Lenny, and it was suggested that twircd was the viable alternative - I've not tried that (yet) mostly because it's PHP based, and (strangely) I try to avoid running any PHP unless I absolutely have to. Might be of interest to others though! I'm likely to see about making a cleaner package of libnet-twitter-lite at some point over the next week (for Lenny), but for the moment it's mostly working (I'm fairly sure the URL shortening bit won't, but I haven't tested that yet... right - tested and it doesn't work - fairly sure that's because it relies on a newer version of LWP than in stable... so I'll add that to the list of things I need to work around :)

For ages, we've been using PHP variables to do the localisation. It was not really easy to maintain, but it worked quite well. However impossibility of using standard tools for translations was still annoying. So I really wanted to move to some standard, what seems to be Gettext. Once I've played with Gettext in PHP, I realised how broken it is and that it is not a good idea to use it. However it is not that hard to implement in PHP and some people already did that. From these findings it was just a small step to implement it. Well not really small step, because at first I've chosen the more complicated way and tried to create sed magic to move all strings to places where they belong. But this turned out to be nearly impossible and at FOSDEM I realised that there is also much easier way to just keep the messages in one file and migrate them as needed. This way the migration is really fast and not touching most of the code. So here we are. Currently it is in separate branch (called gettext), however I hope to merge it soon, because I'm not aware of any problems right now. The nice benefit this gives to us is web based interface for translations.

Some time ago Yubico were kind enough to send me an evaluation copy of their Yubikey device. I ve finally got around to reviewing it and making deployment plans for buying some more. Above is a picture of my Yubikey on the keyboard of my Thinkpad T61 for scale. The newer keys apparently have a different color in the center of the circular press area and also can be purchased in white plastic. The Yubikey is a USB security token from Yubico [1]. It is a use-based token that connects via the USB keyboard interface (see my previous post for a description of the various types of token [2]). The Yubikey is the only device I know of which uses the USB keyboard interface, it seems that this is an innovation that they invented. You can see in the above picture that the Yubikey skips the metal that is used to surround most USB devices, this probably fails to meet some part of the USB specification but does allow them to make the key less than half as thick as it might otherwise be. Mechanically it seems quite solid. The Yubikey is affordable, unlike some token vendors who don t even advertise prices (if you need to ask then you can t afford it) and they have an online sales site. $US25 for a single key and discounts start when you buy 10. As it seems quite likely that someone who wants such a token will want at least two of them for different authentication domains, different users in one home, or as a backup in case one is lost or broken (although my experiments have shown that Yubikeys are very hardy and will not break easily). The discount rate of $20 will apply if you can find four friends who want to use them (assuming two each), or if you support several relatives (as I do). The next discount rate of $15 applies when you order 100 units, and they advise that customers contact their sales department directly if purchasing more than 500 units so it seems likely that a further discount could be arranged when buying more than 500 units. They accept payment via Paypal as well as credit cards. It seems to me that any Linux Users Group could easily arrange an order for 100 units (that would be 10 people with similar needs to me) and a larger LUG could possibly arrange an order of more than 500 units for a better discount. If an order of 500 can t be arranged then an order of 200 would be a good thing to get half black keys and half white ones you can only buy a pack of 100 in a single color. There is a Wordpress plugin to use Yubikey authentication [3]. It works, but I would be happier if it had an option to accept a Yubikey OR a password (currently it demands both a Yubikey AND a password). I know that this is less secure, but I believe that it s adequate for an account that doesn t have administrative rights. To operate the Yubikey you just insert it into a USB slot and press the button to have it enter the pass code via the USB keyboard interface. The pass code has a prefix that can be used to identify the user so it can replace both the user-name and password fields of course it is technically possible to use one Yubikey for authentication with multiple accounts in which case a user-name would be required. Pressing the Yubikey button causes the pass code to be inserted along with the ENTER key, this can take a little getting used to as a slow web site combined with a habit of pressing ENTER can result in a failed login (at least this has happened to me with Konqueror). As the Yubikey is use-based, it needs a server to track the usage count of each key. Yubico provides source to the server software as well as having their own server available on the net obviously it might be a bad idea to use the Yubico server for remote root access to a server, but for blog posting that is a viable option and saves some effort. If you have multiple sites that may be disconnected then you will either need multiple Yubikeys (at a cost of $20 or $15 each) or you will need to have one Yubikey work with multiple servers. Supporting a single key with multiple authentication servers means that MITM attacks become possible. The full source to the Yubikey utilities is available under the new BSD license. In Debian the base functionality of talking to the Yubikey is packaged as libyubikey0 and libyubikey-dev, the server (for validating Yubi requests via HTTP) is packaged as yubikey-server-c, and the utility for changing the AES key to use your own authentication server is packaged as yubikey-personalization thanks Tollef Fog Heen for packaging all this! The YubiPAM project (a PAM module for Yubikey) is licensed under the GPL [4]. It would be good if this could be packaged for Debian (unfortunately I don t have time to adopt more packages at the moment). There is a new model of Yubikey that has RFID support. They suggest using it for public transport systems where RFID could be used for boarding and the core Yubikey OTP functionality could be used for purchasing tickets. I don t think it s very interesting for typical hobbyist and sysadmin work, but RFID experts such as Jonathan Oxer might disagree with me on this issue.

• [1] http://www.yubico.com/
• [2] http://etbe.coker.com.au/2010/03/15/security-tokens/
• [3] http://henrik.schack.dk/yubikey-plugin/
• [4] http://www.securixlive.com/yubikey/index.php

Other day I read Refreshing The Ubuntu Brand , upcoming visual style changes for Ubuntu 10.04 Lucid Lynx and my only comment to this whole story was Don t tell me you re moving window control elements to the left side of window in Lucid
Either way if this is the revolutionary change for Ubuntu, then I have a visual style suggestion for Squeeze as well. Since Gnome is default desktop environment in Debian and as it looks like right now 2.30 will be what s going to be included into Squeeze; nothing much, or nothing really will visually change in Gnome by then. So how about this For some time now I ve been troubled by some things in Gnome, and what s bothering me the most is System menu. Why? Well because the list of utilities listed both under Administration and Preferences is so long that it s almost useless. So without losing your precious seconds of your life and losing fair amount of nerves well this is what s required to find what you were initially looking for. Interesting enough is the fact (please do stress) that Gnome consists of a fine thing called gnome-control-center which is not included in any of Gnome menus. I really do enjoy Gnome vanilla flavor (overall am fan of vanilla flavored apps.) but what I ve been doing for quite time now is fixing this ridicule by having my own version of Systems menu, which consists of Add/Remove App. (synaptic) and Fool Control (gnome-control-center) Final result is that I get what I m looking for in couple of seconds without any lost nerves Either way, after reading the redesigning Ubuntu article, this only encouraged me to go live with this suggestion. I know it s a minor change, but how about we have this implemented into Squeeze? Of course change my silly button labels; if not, what are my options? Make package that will do this for you? I m really interested to hear your input on this topic. Talking about redesigning stuff, is anyone up to do start doing this with Debian homepage? Yea? Count me in

A while ago I blogged about squashing release-critical bugs in stable. Yesterday we have reached a big milestone on that area: The amount of release-critical bugs in stable dropped below 1000 (blue graph). This might sound like it's still pretty high but given that we were well over 1600 RC bugs in stable a while ago I consider this quite a success. This is though no time for rest. There is still way too many RC bugs in stable, there are definitely still a lot of bugs that just aren't affecting stable and thus can be marked as such meaning no upload needs to get done for them. I'm taking a close look at those with higher numbers and most of those seem to be validly affecting stable too so they might require a bit more work than just tagging them. Thanks to all people who helped on that area, I can just remember a few names and don't want to make anyone else also working on stable to feel singled out, though I want to thank Lucas for tagging his FTBFS rounds with squeeze sid right from the start because the packages obviously have built before due to his regular rebuilds. Thanks to all, but like said, not the time to rest. The green squeeze graph is still around 250 bugs away from us!

The Security Token Wikipedia page doesn t seem to clearly describe the types of token. Categories of Security Token It seems to me that the following categories encompass all security tokens:

1. Biometric tokens which seems rather pointless to me. Having a device I control verify my biometric data doesn t seem to provide a benefit. The only possible benefit seems to be if the biometric token verifies the identity of the person holding it before acting as one of the other types of token.
2. Challenge-response devices. The server will send a challenge (usually a random number) and will expect a response (usually some sort of cryptographically secure hash of the number and a shared secret). A challenge-response device may take a password from the user and combine it with the challenge from the server and the shared secret when calculating the response.
3. Time-based tokens (one-time passwords). They will provide a new pseudo-random number that changes periodically, often a 30 second time interval is used and the number is presumably a cryptographically secure hash of the time and a shared secret. This requires a battery in the token and the token will become useless when the battery runs out. It also requires that the server have an accurate clock.
4. Use-based tokens. They will give a new pseudo-random number every time a button is pressed (or some other event happens to indicate that a number has been used). These do not work well if you have multiple independent servers and an untrusted network.

Here is my analysis of the theory of token use, note that I am not sure how the implementations of the various token systems deal with these issues.

1. Biometric security seems like a bad idea for most non-government use. I have seen a retina scanner in use at a government office that made some sense as the people being scanned were in a secure area (they had passed some prior checks) and they were observed (to prevent coercion and the use of fake eyes). Biometric authentication for logging in over the net just seems like a bad idea as you will never know if you can trust the scanner.
2. It seems to me that challenge-response devices are by far the most secure option. CR is resistant to replay attacks provided that it is not possible to have re-used challenges. If the calculation of the response includes a password (which is performed on some tokens that resemble pocket calculators) then a CR token will meet the something you have and something you know criteria.
   One potential problem with CR systems is that of not including the server or account ID in the calculation. So if I was to use a terminal in an insecure location to login to a server or account with data that is not particularly important then it would be possible for an attacker who had compromised the terminal to perform a Man In The Middle (MITM) attack against other servers. Of course you are supposed to use a different password for each account, if you do this then a CR token that includes a password will be resistant to this attack but I expect that people who use tokens are more likely to use one password for multiple accounts.
3. Time-based tokens have a weakness in that an attacker who can immediately discover the number used for one connection could then immediately login to other servers. One example of a potential attack using this avenue would be to compromise a terminal in an Internet cafe, steal a hash used for logging in to server A and then immediately login to server B. This means that it may not be safe to use the same token for logging in to servers (or accounts) that have different sensitivity levels unless a strong password was used as well I expect that people who have hardware tokens tend to use weaker passwords.
   Also one factor that will make some MITM attacks a lot easier is the fact that the combination of the hash from the token and the password are valid for a period of time so an attacker could establish a second connection within the 30 second interval. It seems that only allowing one login with a particular time-coded password is the correct thing to do, but this may be impossible if multiple independent servers use the same token.
   Time based tokens expire when the battery runs out. The measures taken to make them tamper-proof may make it difficult or impossible to replace the battery so a new token must be purchased every few years.
4. Use-based tokens are very similar to time-based tokens, it s just a different number that is used for generating the hash. The difference in the token is that a time-based token needs a battery so that it can track the time while a use-based token needs a small amount of flash memory to store the usage count. The difference at the server end is that for a use-based token the server needs a database of the use count of each token, which is usually not overly difficult for a single server.
   One problem is the case of a restore from backup of the server which maintains the use count database. The only secure way of managing this is to either inspect every token (to discover it s use count) or to issue a new password (for using password plus token authentication). Either option would be really painful if you have many users at remote sites. Also it would be required to get the database transaction committed to disk before an authentication attempt is acknowledged so that a server crash could not lose the count this should be obvious but many people get these things wrong.
   An additional complication for use-based tokens comes with the case of a token that is used for multiple servers. One server needs to maintain the database of the usage counts and the other servers need to query it by secure links. If a login attempt with use count 100 has been made to server A then server B must not accept a login with a hash that has a use count less than or equal to 100. This is firstly to cover the case where a MITM attack is used to login to server B with credentials that were previously used for server A. The second aim of this is to cover the case where a token that is temporarily unguarded is used to generate dozens of hashes while the hashes could be immediately used it is desirable to have them expire as soon as possible, and having the next login update the use count and invalidate such hashes is a good thing.
   The requirement that all servers know the current use count requires that they all trust a single server. In some situations this may not be possible, so it seems that this only works for servers within a single authentication domain or for access to less important data.

Methods of Accessing Tokens It seems that the following are the main ways of accessing tokens.

• Manual entry the user reads a number from an LCD display and types it in. This is the most portable and often the cheapest but does require a battery.
• USB keyboard the token is connected to a PC via the USB port and reports itself as a keyboard. It can then enter a long password when a button is pressed. This is done by the Yubikey [1], I am not aware of anyone else doing it. It would be possible to have a token connect as a USB keyboard and also have it s own keypad for entry of a password and a challenge used for CR authentication.
• USB (non-keyboard) or PCCard/Cardbus (AKA PCMCIA). The token has it s own interface and needs a special driver for the OS in question. This isn t going to work if using an Internet cafe or an OS that the token vendor doesn t support.
• Bluetooth/RFID has similar problems to the above but also can potentially be accessed by hostile machines without the owner knowing. I wouldn t want to use this.
• SmartCard the card reader connects to the PC via Cardbus or USB and it has all the same driver issues. Some SmartCard devices are built in to a USB device that looks to the OS like a card reader plus a card, so it s a USB interface with SmartCard protocols.

To avoid driver issues and allow the use on random machines it seems that the USB keyboard and manual entry types of token are best. While for corporate Intranet use it seems that a SmartCard is best as it can be used for opening doors as well, you could use a USB keyboard token (such as a Yubikey) to open doors but it would be slower and there is no off the shelf hardware. For low cost and ease of implementation it seems that use-based tokens that connect via the USB keyboard interface are best. For best security it seems that a smart-card or USB interface to a device with a keypad for entering a password is ideal.

• [1] http://www.yubico.com/

The upload reduced RC count by one as klibc builds against recent linux-libc-dev including 2.6.34-rc1. Also libklic-dev uses them directly once installed thanks to a patch from Ben Hutchings. The klibc build saw several fixes from a big and refined Google patch queue. The klibc-utils mount grew several useful features and ipconfig saw lots of bug fixes (send requested optional hostname, raise field length for rootpath DHCP option, ..): hpa klibc 1.5.16 release announce, Git klibc repo. Update: According to build log there is still work todo for i386 and sparc. :)

not many closed bugs in the last two weeks, & not even one RC bug per day worked on. anyway, here's my recent list:

• #567144 libavg: "libavg FTBFS: python LOCALMODLIBS causes -lssl link failure"
  add a comment
• #568940 libswt-gtk-3.5-java: ""symlink /usr/share/java/swt.jar missing""
  add another comment to the bug report
• #569091 libvideo-capture-v4l-perl: "Uses obsolete V4L1 API"
  improve patch, run tests ... (pkg-perl)
• #569408 src:libdbix-class-perl: "libdbix-class-perl: FTBFS: tests failed"
  upload new upstream release prepared by jawnsy with a versioned build dependency (pkg-perl)
• #570160 nsd3: "nsd3: Installation fails because of missing /etc/nsd3/nsd.conf"
  apply patch from BTS, upload to DELAYED/2
• #570500 svn-workbench: "svn-workbench: crash on start: AttributeError: 'NoneType' object has no attribute 'lower'"
  grab fixed package from mentors.d.o, upload to DELAYED/2
• #572719 libx11-protocol-perl: "libx11-protocol-perl: perl X11 application does not launch"
  add a comment and tag unreproducible (co-maint)
• #573657 src:libfile-fu-perl: "libfile-fu-perl: FTBFS: tests failed"
  triage, comment (pkg-perl)
• #573661 src:libdbix-class-schema-loader-perl: "libdbix-class-schema-loader-perl: FTBFS: tests failed"
  add missing dependency and upload (pkg-perl)
• #573679 src:libwx-perl: "libwx-perl: FTBFS: xvfb-run: error: Xvfb failed to start"
  triage, comment (pkg-perl)

So, I finally gave in and got my self a twitter account, it is (as one would guess) http://twitter.com/sommitrealweird, me, being me, I hate having to have lots of browser tabs open for things that I should be able to access in my IRC client, with twitter this is even more obvious that an IRC client is better for reading it, lots of short messages that are text, why would you need a browser tab for that? Also it means that I've got a log of the twitter messages and can look when I feel like it. All of my IRC is done from my main virtual machine, which is also my e-mail server and web server, and thus, it's running Debian stable (currently lenny), unfortunately this does not include the Net::Twitter library that twirssi relies on. So, first step first, how much of a PITA would backporting Net::Twitter be... well, I took a look at the dependencies and went "Well, that looks like rather more effort than I want to put in right now", however I then found Net::Twitter::Lite, which you can satisfy the dependencies (well, sortof) in Lenny... they're a few versions out, but they're close... First part was doing :

dh-make-perl --cpan Net::Twitter::Lite

Once that's finished you'll have a Net-Twitter-Lite-blah directory, which in turn contains a debian/ directory, so you can go in there and do:

dpkg-buildpackage -rfakeroot

That should tell you roughly what you're missing etc, from there you can check for the debian packages providing the missing libraries, and what versions they are. Install them and edit Makefile.PL to have the version numbers of the debian packages, you might also need to update debian/control to change some of it's restrictions. Once all that is done, you should have a libnet-twitter-lite-perl package, install that and you're most of the way there. I then cloned the twirssi source, and edited it to use Net::Twitter::Lite rather than Net::Twitter, my source is available via gitweb at http://git.sommitrealweird.co.uk/gitweb?p=twirssi-net-twitter-lite.git;a=summary. To clone do:

git clone git://git.sommitrealweird.co.uk/twirssi-net-twitter-lite.git/

or

git clone http://git.sommitrealweird.co.uk/twirssi-net-twitter-lite.git/

Hope that helps someone else out there! If you want my Net::Twitter::Lite package, let me know!

I wonder what happens if I package Tiberian Sun with a WINE wrapper and upload it to non-free.

The Debconf team is excited to announce that we are now accepting proposals for contributions to this year s Debian conference! We invite you to submit proposals for how you would contribute until the deadline: May 1st, 2010, 23h59 UTC. There are many ways you can contribute, you could present a technical paper, host a panel discussion, put on a tutorial, do a performance, an art installation, a debate, host a meeting (BoFs, or Birds of a Feather Session), or other possibilities that you devise. This year we are also accepting proposals for tracks a thematic grouping around a particular subject, and people to coordinate those tracks. If you are looking for ideas of things that you could contribute, or have ideas for things that you would like to see happen at Debconf, have a look at the Contribution Brainstorm page. DebConf talks will be broadcast live on the Internet where possible, unless otherwise requested. Videos of the talks will be published on the web along with the presentation slides and papers. Step 1. Submit Proposal Proposals should provide an overview of your proposed contribution, similar to an abstract, and be no more than 600 words. Since contributions can cover a range of issues, please describe what your proposal covers, be it political (Free Software, law, advocacy, access, etc.), technical (d-i, OpenPGP, etc.), social (Debian structures and groups). It s okay to hit all three of these. Your proposal should also include some information on why you re qualified to present, or coordinate this topic. For example, you can include links to posts you have made to Debian mailing lists or other material that indicates your qualifications. Proposals and their abstracts will be accepted until May 1st, 2010, 23h59 UTC. To submit your proposal, go to http://debconf10.debconf.org/register.xhtml and register as an attendee. Once you are registered, there is a Submit a proposal link. You will see your proposal on the site. You can choose between different presentation types. If you are unsure what type you should use, please read our definitions first. If it s not there for some reason, or you have questions, please contact us immediately. Step 2. Committee Review The review committee for this year will make its decision by May 1st, 2010. All correspondence will be done by email. Step 3. Paper Submission Like last year, we are asking for papers to be submitted along with the presentations. A full paper is optional, however we strongly encourage you to submit one if possible as we intend to provide written information along with transcripts of the sessions for later viewing. Having written papers in advance will allow us to get translations done to help non-native-English speakers feel more comfortable with the topics presented. Papers are due by July 1st, 2010, and should cover the topic in reasonable depth (3 pages A4 text, plus pictures and diagrams). We will use LaTeX to typeset the proceedings. Please submit your paper formatted in LaTeX. Should you be unfamiliar with LaTeX earlier submission in plain text is also fine. Step 4. Live Presentation Longer presentations may have a break in the middle and should include workshop items that directly involve the participants. If using slides or any other presentation, please consider that your audience will consist of people who use free software, and your choice of application to prepare and display the slides should reflect this if at all possible. Fine Print Publication Rights Debconf requires non-exclusive publication rights to papers, presentations, and any additional handouts or audio/visual materials used in conjunction with the presentation. The authors have the freedom to pick a DFSG-free license for the papers themselves and retain all copyrights. The presentations will be recorded, and may be broadcast over the Internet. Any copies of the presentation will be made available under a license like the MIT/X11 license. Failure to Submit In the event that a deadline is missed we reserve the right to revoke any offer to present.

It is a little later than we wanted but here it finally is: Debconf10 call for contributions. Do read as it has some new ideas, categories, and prospects. Also make sure to share with us on the brainstorming page.

It is a little later than we wanted but here it finally is: Debconf10 call for contributions. Do read as it has some new ideas, categories, and prospects. Also make sure to share with us on the brainstorming page.

I'm collecting information (or at least links) about functional programming languages on the the JVM. I'm going to intentionally leave "functional programming language" undefined here, so that people can have fun debating :). Functional Languages

• scala
• clojure
• CAL
• sisc
• OCaml
• Fantom

Languages with functional features

• jruby
• jython
• javascript

Projects and rumours.

• There has been discussion about making the jhc target the jvm. They both start with 'j', so that is hopeful.
• Java itself may (soon? eventually?) support closures

While writing the post about performance, I got interested in Template Haskell, specially in the $(lift) construction. Investigating a little bit about it, I got to the following code:

 -# LANGUAGE TemplateHaskell #- 
import Language.Haskell.TH.Syntax
import X
main :: IO ()
main = print $(lift $ x)

With X.hs:

module X where
import System.IO.Unsafe
x :: Int
x = read $ unsafePerformIO $ putStr "Number: " >> getLine

The result was a surprise to me. It asked for the number in compilation time.

$ ghc --make main
[2 of 2] Compiling Main             ( main.hs, main.o )
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package array-0.3.0.0 ... linking ... done.
Loading package containers-0.3.0.0 ... linking ... done.
Loading package pretty-1.0.1.1 ... linking ... done.
Loading package template-haskell ... linking ... done.
Number: 5
Linking main ...
marcot@zezinho:~/codigo/haskell$ ./main
5

I ve tried to see how slower can ghc be compared to gcc in compiling a simple
imperative program. I ve written this small test program in C:

/* loop.c */
#include 
int
main(int argc, char **argv)
 
    int i, j, k, t = 0;
    for(i = 0; i < 1000; i++)
        for(j = 0; j < 1000; j++)
            for(k = 0; k < 1000; k++)
                if(i * i + j * j + k * k % 7 == 0)
                    t++;
    printf("%d\n", t);
    return 0;
 

And a similar version in imperative Haskell, being as similar as possible to
the original C code:

-- loop.hs
import Control.Applicative
import Control.Monad
import Data.IORef
main :: IO ()
main
  = do
    i <- int
    j <- int
    k <- int
    t <- int
    for (i =: 0) (i <: 1000) (inc i)
      $ for (j =: 0) (j <: 1000) (inc j)
        $ for (k =: 0) (k <: 1000) (inc k)
          $ do
            i_ <- readIORef i
            j_ <- readIORef j
            k_  a -> IO ()
(=:) = writeIORef
( IORef a -> a -> IO Bool
i <: v = (< v)  readIORef i
inc :: Enum a => IORef a -> IO ()
inc i = modifyIORef i succ
for :: IO () -> IO Bool -> IO () -> IO () -> IO ()
for preface condition step code
  = preface >> for_ condition step code
for_ :: IO Bool -> IO () -> IO () -> IO ()
for_ condition step code
  = condition >>= flip when (code >> step >> for_ condition step code)

A functional version:

-- functional.hs
main :: IO ()
main
  = print
    $ length
      [i
          i <- [0 :: Int .. 999]
          , j <- [0 .. 999]
          , k <- [0 .. 999]
          , i * i + j * j + k * k  mod  7 == 0]

And a version using Template Haskell.

 -# LANGUAGE TemplateHaskell #- 
import Language.Haskell.TH.Syntax
main :: IO ()
main
  = print
    $ $(lift $ length
      [i
          i <- [0 :: Int .. 999]
          , j <- [0 .. 999]
          , k <- [0 .. 999]
          , i * i + j * j + k * k  mod  7 == 0])

The results:

$ time gcc -O3 -o loop -Wall loop.c
real    0m0.256s
user    0m0.148s
sys     0m0.040s
$ time ./loop
143
real    0m13.652s
user    0m11.629s
sys     0m0.052s
$ time ghc --make -O3 loop.hs
real    0m0.209s
user    0m0.160s
sys     0m0.020s
$ time ./loop
143
real    3m46.834s
user    3m24.313s
sys     0m0.712s
$ time ghc --make -O3 functional.hs
[1 of 1] Compiling Main             ( functional.hs, functional.o )
Linking functional ...
real    0m1.420s
user    0m1.016s
sys     0m0.220s
$ time ./functional
143
real    1m29.057s
user    1m25.809s
sys     0m0.224s
$ time ghc --make -O3 th.hs
[1 of 1] Compiling Main             ( th.hs, th.o )
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package array-0.3.0.0 ... linking ... done.
Loading package containers-0.3.0.0 ... linking ... done.
Loading package pretty-1.0.1.1 ... linking ... done.
Loading package template-haskell ... linking ... done.
real    90m54.226s
user    87m32.024s
sys     0m14.785s
marcot@zezinho:~/codigo/haskell$ time ./th
143
real    0m0.005s
user    0m0.000s
sys     0m0.004s

The time to build the code with TH is not the best, but the execution time
surely is. Maybe we could use this technic to improve the execution time of all
of the codes, interpreting a part of the code in build time automaticly,
without user indication. The results in a table:

Version	Build time (s)	Execution time (s)
C	0.256	13.652
Imperative Haskell (IORefs)	0.209	136.834
Functional Haskell	1.420	89.057
Template Haskell	5454.226	0.005