Yoav's post about twitter was interesting: http://yoavs.blogspot.com/2009/01/one-curious-thing-about-twitter.html Personally, I don't really see the appeal. So far there are only two uses I have for it:

• Lance Armstrong writes a fair bit, and even posts some pictures, and since I am a huge cycling fan, that's kind of fun to read.
• I use the search API to keep track of people talking about my stuff... Hecl, LangPop.com, and so on. That's kind of handy, but it feels more like a big wiretap than a "conversation".

Other than that, it's another firehose of data that I really don't need - I probably read too much junk on the internet as it is.

I m not a big new year resolution maker (new year is just a side-effect of a calendaring system), but if you are, I suggest the following resolutions to avoid three bad ideas:

1. Change your passwords and do not set it to the ship number for the Starship Enterprise, or any other of The Top 500 Worst Passwords of All Time - if you re a sysadmin, make sure you are comparing user passwords against these sort of lists;
2. Fight against cinema-style ratings for web-sites and the campaign against free speech [because of] a wider public interest which that implies;
3. (Debian developers) Vote against the proposal for future GRs would need 30 other [DDs, not people - the proposal is wrong] to support because There seems little rationale to support it. The more I ve looked, the more places I ve not found evidence for such a large seconding requirement and I know a few anecdotes about raising numbers too high and accidentally killing an organisation

Happy New Year!

The following went out to the R-announce and R-SIG-Finance mailing lists a few days ago. The conference already has a very strong lineup of invited speakers, and we are now asking R / Finance users from both academia and industry to submit suitable one-page abstracts:

Call for Papers The Finance Department of the University of Illinois at Chicago (UIC),
the International Center for Futures and Derivatives at UIC, and
members of the R finance community are pleased to announce R/Finance 2009: Applied Finance with R on April 24 and 25, 2009, in Chicago, IL, USA Confirmed keynote speakers include:

Patrick Burns (Burns Statistics)
David Kane (Kane Capital)
Roger Koenker (U of Illinois at Urbana/Champaign)
David Ruppert (Cornell)
Diethelm Wuertz (ETH Zuerich)
Eric Zivot (U of Washington)

We invite all users of R in Finance to submit one-page abstracts or
complete papers (in txt/pdf/doc format). We encourage papers both on
academic research topics and related to use of R by Finance practitioners.
Presenters are strongly encouraged to provide working R code to accompany
the presentation/paper. Datasets need not be made public. Please send submissions to committee@RinFinance.com.
The submission deadline is January 31st, 2009.
Submissions will be evaluated and submitters notified via email on a rolling basis. Additional details about the conference will be announced as available. For the program committee:

Gib Bassett, Peter Carl, Dirk Eddelbuettel, John Miller,
Brian Peterson, Dale Rosenthal, Jeffrey Ryan

See you in Chicago in April!

http://ping.fm/QZ4Lf
So this is the new year.
And i don't feel any different.
And I have no resolutions
For self assigned penance
For problems with easy solutions

So everybody put your best suit or dress on
Let's make believe that we are wealthy for just this once
Lighting firecrackers off on the front lawn

Time for another ftpmaster blog. It s not like we stopped doing things. :) It seems we, somehow, got a pretty active coder (yay), Michael Casadevall. In the last few days I merged multiple code changes from him. The first was a different output format for our NEW queue overview page. It is now also available in 822 Format for all those people that want to use the data in their tools. Like QA for example. Today got a second change touching this, we now not only list NEW/BYHAND in there, but also our incoming (accepted) and Proposed-Updates queue. There is also a patch waiting to fix up the pretty weird code thats around the DM stuff. Will fix some of the many bugs and weirdnesses in the current implementation. And it seems he is right now trying to get rid of apt-ftparchive, the beast that makes our dinstall run take so long. Oh we will be so happy when we got rid of it. :) Also, we do have two new people as trainees for ftpteam. If that works out, we will have yet another 2 new members in our team. Yay.

Recently the Debian Administration website has been besieged by spammers submitting bogus comments. I also run a couple of blogs which are constantly having random gibberish submitted to them - although it is less of a problem there because I approve them manually due to the offline nature of my blog, and the blog compiler I use. Regardless I figured it was time to do something about it, in part because Chris Searle suggested that I should be able to query arbitrary text for spammyness due to my experience with fighting email spam. (As it turns out that is not so useful experience. Comments and emails are not the same. The same header-trickery you see in bogus email, false EHLOs, etc, are not useful concepts to carry accross.) Anyway we were saying, I was going to do something? So I did. My solution? An XML-RPC server which you submit your comments to. This will return either:

OK	The comment is clean.
SPAM:[reason]	The comment is spam, and the optional reason explains further

The server itself is very simple, and it comes with a collection of simple plugins which do the job of testing different things. More plugins will almost certainly be added over time - so far I've seen the lotsaurls plugin capturing most of the SPAM, although the DNSRBL lookup is also working nicely having captured live spam without my touching it. Huzzah. & etc.. If there is any interest feel free to let me know, although as the server is open, and the client side usage is documented I imagine other people could run with it easily enough too - avoiding me becoming a single point of failure. For reference my initial change to hook this up live on the site was only a few lines of code - although later I did need to make some additional changes to make it cope with failures, & etc. ObFilm: Ghostbusters

Old train! Smoke inside. That s what Jacob said today when he saw an old steam locomotive at the old Union Station in Wichita, KS. Never mind that it s been sitting there for decades he s got that concept of smoke coming out of steam engines down, and apparently realizes that for smoke to come out of them, it must start out inside them. But I don t think I ve ever heard anyone talk about a steam engine in a more cute way. Two is a fun age. Today I needed to return a power supply to Circuit City, so Jacob and I made a day of it. He came with me to town (yes, us country folk go to town ). We returned the power supply, then ate lunch at a Mexican place. Jacob would call it a chips and salsa place. Today he drank from a straw for the first time, and loved it so much that I think he got more liquid than food in him over lunch. Oh well. After that, we went to the eye cream (ice cream) store - Cold Stone Creamery. Whenever Jacob hears talk of Wichita, he comments with something like Go ichita. Eat eye cream. Go town. Jacob ate his entire kid-sized chocolate ice cream with sprinkles. He loves sprinkles. While we were eating ice cream, I asked him, After you are done, would you like to see skyscrapers or trains? NO! Eat eye cream! I don t think he quite got the after bit, so I asked him again in the car after we were done eating. His eyes lit up. SEE KYCRAPER!! So we drove to downtown Wichita and saw the skyscrapers. (Yes, I am aware that other cities have much taller buildings. It doesn t matter when you re 2.) We got out of the car and he got to touch a few of them. In fact, the only way I got him back into the car without a meltdown was by pointing out the train crossing above the road on a bridge, and the fact that he d still be able to see it from in the car. That, of course, led to us needing to see trains. I drove him up the ramp to be trackside by the old Wichita Union Station. There weren t any trains going past right then, but he did get to see the locomotives at the Great Plains Transportation Museum through the fence. We started to head home, but he really wanted to see the train again. So we stopped at the park in Newton to see the old ATSF locomotive there. By that point, it was waaaay past naptime and we narrowly averted a fit when I informed him that no, we could not go inside the adjacent grain elevators. So all told, I think Jacob had a fun day with his dad. Now, in case there is any doubt out there about what kind of child Jacob is, I should point out the things he notices in church lately. First off, when we get into the sanctuary, we sit in the back. But first thing he said lately when we walked in was TWO THERMOSTATS! Yes, he saw two thermostats at opposite ends of the room up front, pointed right at them, and was very excited. He also notices the organ speakers ( oran peaker ), big cross , ceiling fans, and now furnace vents . Yes, furnace vents. At the Christmas Eve service, there was a candlelight part. He loved it. Daddy hold fire! A few people nearby smiled. While we sang Silent Night, he really wanted to blow out the candle. When it was time, I said OK Jacob, now you can blow it out. A very excited Fffffffffffffffff followed, and several people nearby were chuckling by then. I also let Jacob put the candle in the box on our way out. He said, I put fire in box. I did it!

A recent post by Adrian von Bidder got me to reread the "Printing dialogs and GNOME" thread that Linus started on the GNOME mailinglists a few years ago. I don't know how or why I missed it back then, but I did see this little gem in a post by Mike Shaver:

You and I are not interesting GNOME users, in part because we already _are_ GNOME users. The interesting GNOME users are the ones that haven't tried it yet, and we need to figure out why they haven't. There are lots of things that I want in GNOME, but if they aren't going to bring a hundred thousand of my closest friends along as well, I would hope that nobody goes out of their way to do them.

That is precisely what is wrong with the GNOME people. While encouraging new users to try and use GNOME certainly is a good and worthy goal, it is this mentality of 'only the new users matter, the existing ones can go f*ck themselves' which will ultimately drive away users. Of course this post is a few years old, and I'm not involved in GNOME development in any way, so this mentality might have gone away now; but I don't hold my breath.

No, I don't claim KDE is perfect. Especially the way the transition to KDE 4 is (not) being handled. (I don't mean within Debian, this is a KDE problem.) But beyond dumbing down the UI as even a very prominent Linux developer repeatedly commented on, Josselin Mouette just confirmed my decision to stay away from GNOME. Yes, there are other desktop environments and window managers, and I haven't done more than look at XFCE very briefly, but just now I'm quite happy with KDE 3.5, and am waiting for KDE 4 to become actually useable.

Given the recent brouhaha in Debian, and General Resolution regarding Lenny s Release policy as it relates to Firmware and Debian s Social Contract, which has led to the resignation of Manoj Srivastava from the position of Secretary for the Debian Project, I m reminded of the following passage from Gordon Dickson s Tactics of Mistakes (part of Dickson s Childe Cycle, in which he tells the story of the rise of the Dorsai):

No, said Cletus. I m trying to explain to you why I d never make an Exotic. In your calmness in the face of possible torture and the need to kill yourself, you were showing a particular form of ruthlessness. It was ruthlessness toward yourself but that s only the back side of the coin. You Exotics are essentially ruthless toward all men, because you re philosophers, and by and large, philosophers are ruthless people. Cletus! Mondar shook his head. Do you realize what you re saying? Of course, said Cletus, quietly. And you realize it as well as I do. The immediate teaching of philosophers may be gentle, but the theory behind their teaching is without compunction and that s why so much bloodshed and misery has always attended the paths of their followers, who claim to live by those teachings. More blood s been spilled by the militant adherents of prophets of change than by any other group of people down through the history of man.

The conflict between idealism and pragmatism is a very old one in the Free and Open Source Software Movement. At one end of the spectrum stands Richard Stallman, who has never compromised on issues regarding his vision of Software Freedom. Standing at various distances from this idealistic pole are various members of the Open Source Community. For example, in the mid-1990 s, I used to give presentations about Linux using Microsoft Powerpoint. There were those in the audience that would give me grief about using a non-free program such as MS Powerpoint, but my response was that I saw no difference between driving a car which had non-free firmware and using a non-free slide presentation program. I would prefer to use free office suite, but at the time, nothing approached the usability of Powerpoint, and while dual-booting into Windows was a pain, I could do a better job using Powerpoint than other tools, and I refused to handcap myself just to salve the sensibilities of those who felt very strongly about Free Software and who viewed the use of all non-Free Software as an ultimate evil that must be stamped out at all costs. It is the notion of Free Software as a philosophy, with no compromises, which has been the source of many of the disputes inside Debian. Consider, if you will, the first clause of the Debian Social Contract:

Debian will remain 100% free We provide the guidelines that we use to determine if a work is free in the document entitled The Debian Free Software Guidelines. We promise that the Debian system and all its components will be free according to these guidelines. We will support people who create or use both free and non-free works on Debian. We will never make the system require the use of a non-free component.

This clause has in it no room for compromise. Note the use of words such as 100% free and never make the system require the use of a non-free component (emphasis mine). In addition, the Debian Social Contract tends to be interpreted by Computer Programmers, who view such imperatives as constraints that must never be violated, under any circumstances. Unfortunately, the real world is rarely so cut-and-dried. Even the most basic injunctions, such as Thou shalt not kill have exceptions. Few people might agree with claims made by the U.S. Republican Party that the war in Iraq qualified as a Just War as defined by Thomas Aquinas, but rather more people might agree that the July 20, 1944 plot to assassinate Hitler would be considered justifiable. And most people would probably agree most of the actions undertaken by the Allied Soldiers on World War II battlefields that involved killing other soldiers would be considered a valid exception to the moral (and for those in the Judeo-Christian tradition, biblical) injunction, Thou shalt not kill . As another example, consider the novel and musical Les Mis rables, by Victor Hugo. One of the key themes of this story is whether or not Thou shalt not steal is an absolute or not. Ultimately, the police inspector Javert, who lived his whole life asserting that law (untempered by mercy, or any other human considerations) was more important than all else, drowns himself in the Seine when he realizes that his life s fundamental organizing principle was at odds with what was ultimately the Right Thing To Do. So if even the sixth and eighth commandments admit to exceptions, why is it that some Debian developers approach the first clause of the Debian Social Contract with a take-no-prisoners, no-exceptions policy? Especially given the fourth clause of the Debian Social contract:

Our priorities are our users and free software We will be guided by the needs of our users and the free software community. We will place their interests first in our priorities. We will support the needs of our users for operation in many different kinds of computing environments. We will not object to non-free works that are intended to be used on Debian systems, or attempt to charge a fee to people who create or use such works. We will allow others to create distributions containing both the Debian system and other works, without any fee from us. In furtherance of these goals, we will provide an integrated system of high-quality materials with no legal restrictions that would prevent such uses of the system.

This clause does not have the same sort of absolutist words as the first clause, so many Debian Developers have held that the needs of the users is defined by 100% free software . Others have not agreed with this interpretation but regardless of how needs of the users should be interpreted, the fact of the matter is, injuctions such as Thou shalt not kill are just as absolute and yet in the real world, we recognize that there are exceptions to such absolutes, apparently unyielding claims on our behavior. I personally believe that 100% free software is a wonderful aspirational goal, but in particular with regards to standards documents and firmware, there are other considerations that should be taken into account. People of good will may disagree about what those exceptions should be, but I think one thing that we should consider as even higher priority and with a greater claim on how we behave is the needs of our users and fellow developers as people. For those who claim Christianity as their religious tradition, Jesus once stated,

Thou shalt love the Lord thy God with all thy heart, and with all thy soul, and with all thy mind. This is the first and great commandment. And the second is like unto it: Thou shalt love thy neighbour as thyself. On these two commandments hang all the law and the prophets.

Even for those who do not claim Christianity as their religious tradition, most moral and ethical frameworks have some variant on the Golden Rule: Do unto others as you would have them do unto you . I would consider, for example, that the Golden Rule is at least a high priority claim on my behavior as the notion of free speech, and in many cases, it would be a higher priority claim. The recent controversy surrounding Josselin Mouette was started precisely because Joss has taken a something which is a good thing, namely Free Speech, and relegated it to a principle more important than all else, and claiming that any restraint on such a notion was equivalent to censorship. I think the same thing is true for free software, although it is a subtler trap. Philosophical claims than 100% free software as most important consideration is dangerously close to treating Free Software as the Object of Ultimate Concern or in religious terms, idolotry. For those who are religious, it s clear why this is a bad thing; for those who aren t if you are unwilling to worship a supernatural being, you may want to very carefully consider whether you are willing to take a philosophical construct and raise it to a position of commanding your highest allegiance to all else, including how you treat other people. Ultimately, I consider people to be more important than computers, hardware or software. So over time, while I may have had some disagreements with how Mark Shuttleworth has run Canonical Software and Ubuntu (but hey, he s the multimillionaire, and I m not), I have to give him props for Ubuntu s Code of Conduct. If Debian Developer took the some kind of Code of Conduct at least as seriously as the Social Contract, I think interactions between Debian Developers would be far more efficient, and in the end the project would be far more successful. This may, however, require lessening the importance of philosophical constructs such as Free Speech and Free Software, and perhaps becoming more pragmatic and more considerate towards one another.

A few years ago, I had some ideas about a real-world trading game. In short, a combination of the game play of Settlers of Catan , the cute pseudo-medieval world of The Settlers (the computer game), which you can play in your every day live along, without having to sit in front of the computer for a long time. I then started some code, lost motivation and let it sit there for a while.Recently, I re-developed interest in the idea and started from scratch, using Haskell and HAppS. To avoid losing interest again, I m now putting the code online and set up the server. I invite everyone to play around with it, maybe have a look at the code, send me patches or comments. As you can see, the web user interface is plain ugly HTML and could need some love. Some CSS is definitely needed, some AJAX would be nice. Also, the resource tree is very small at the moment there are a lot of things to work on, even if you don t want to touch Haskell!You can register at http://mumer.net/. You will be either given a forest (a source for wood) or a source of stone. You can reap your source, and trade on the Free Market , which is where you can always trade online, at bad prices. The idea is that you find real trade partners, to get better prices.For now, trading without physical contact is possible. You can create so-called issue ids, which represent stips of paper. You can then load resources on them, and give the paper (i.e. the number) to other players, who can then redeem them. Eventually, it is planned that these pieces of paper are provided centrally and (sufficiently) unforgeable, so that it is clear who owns a resource.You can also bid on certain stuff, such as a sawmil, which allows you to turn wood into boards. It will regularily be re-leased to the highest bidder.You can get the code (in a darcs repository) from http://darcs.nomeata.de/mumer2 and also browse the code.If you happen to be at the CCC right now and would like to talk about it, please do so!

A while ago I dropped from a number of IRC channels, in a quest for a more productive work environment. The problem was that I look at my IRC window often, and if I see any windows with activity, I will go and read them. Recently I ve wanted to hang around in #git, because I was writing some (minor) patches and thought it d be nice to be available there. This is a fairly active channel, and whenever there was activity, I couldn t help go and look, knowing in advance it d be (mostly) uninteresting for me. So I concluded that what I really needed was to tell irssi: don t tell me there s activity in #git, unless somebody highlights me. And this is precisely what the activity_hide_targets option does. Just set it to a list of channels you want to ignore. This has also allowed me to return to a couple Debian channels that I had dropped, and maybe I ll add an extra two back.

For various reasons (which in the end boil down to lack of manpower), we are quite late in the process of packaging GNOME 2.24. (This is almost finished now, I ll keep you informed.) Which is why I may sound coming a bit late on noticing this one, but I was really speechless. The problem: session management has flaws Currently, a session manager uses XSMP (the X Session Management Protocol) to talk to applications. What it means is that for applications supporting this protocol, it is able to do more than simply starting and killing them: it will also remember their state, and offer them a way to shut down gracefully. However, XSMP is really a shitty protocol I won t explain why here, you will find tons of better explanations on the intarweb. The gnome-session developers, being quite aware of this issue, did what anyone interested enough would have done: they designed a new protocol, based on D-Bus, and implemented it. The new protocol is not considered stable yet, but it is simple, efficient and above all, reliable that s a giant leap forward. For this reason, I was very excited to see what gnome-session 2.24 would look like, since it brings major cleanups in the code. The solution: remove session management! When I first started it, it did not restore my saved session. I simply supposed that the format of the saved session had changed, and that writing a conversion tool would be in order. Wrong. Let s bring the session preferences: The UI of this dialog hasn t changed since 2.22. However, I do not resist the urge to show you the code behind the Remember Currently Running Applications button:

static void
on_save_session_clicked (GtkWidget           *widget,
                         GsmPropertiesDialog *dialog)
 
        g_debug ("Session saving is not implemented yet!");
 

As for the check box on top of it, it sets a GConf value that is never read anywhere. If you know the long term plans for GNOME, it makes sense: when gnome-shell replaces the panel and the window manager, it will also be responsible for starting the visible applications, while gnome-session will deal with what s happening behind the scenes. But gnome-shell is still far from ready, and you need something in the meantime for the basic requirements of a session manager! Backwards compawhat? The surprises don t stop here. I also noticed that logout was much faster instantaneous instead of the usual 2-3 seconds. The reason why logging out is this long currently is not because it takes long to kill applications; it s because the session manager kindly requests applications supporting XSMP to shut down before killing them. If a document isn t saved, an application will be able to prevent the logout process. Guess what? Now gnome-session completely ignores XSMP applications. Since it doesn t need them to register for saving the session, it also saves the time to ask them to close cleanly. The result is that you will see a lot of such dialogs: It s very nice to replace a flawed protocol ; and really, the new protocol goes in the correct direction. But let s be realistic, it s impossible to immediately port hundreds of applications to a new protocol without having a transition time during which both protocols are supported. You also need to consider your protocol as stable before asking other developers to port their applications. And to get it accepted, you need to standardize it; freedesktop.org would have been the correct body. (Currently, the protocol lies in the org.gnome namespace, not org.freedesktop.) Release management at its best Wait aren t there some distributions out there which already released stable versions with GNOME 2.24? The answer is yes. At least Ubuntu Intrepid and Fedora Core 10 ship with a session manager that:

• is unable to restore applications;
• kills applications without letting you save your work.

It s good to see such improvements on the session manager coming, and I m really thankful to the gnome-session developers to work on it. What I wonder is:

• How could it slip into a stable GNOME release?
• How could two major distributions let it slip into a so-called stable release?

It definitely looks like we re not the only ones who could improve our release management processes. So what? This is a very good example of a lack of big picture thinking. On one side, there is a brilliant design and its good implementation. On the other side, two major regressions from the user s point of view the kind of regressions that make people fly away. If there s one thing that I ve learned from working in IT, it s that you must often keep your brilliant designs as long-term goals. In the short term, you will run a bastardized version of your brilliant design that will make you cry; but it will work. When you need to talk to shitty applications or with shitty protocols, you need to write shitty code.

Over the last couple of days, I've found some time to work on Lintian for the first time in quite a while. It's been a good feeling both for getting back to a project that I've done very little on for several months and finally feeling energized about a coding project. I think after a week of vacation, I'm starting to recover my energy. I uploaded Lintian 2.1.3 earlier today and am currently doing a fresh archive-wide run for lintian.debian.org. This version has several new checks for watch files from Raphael Geissert, several fixes for the lintian.d.o output, a few other random bug fixes, and an attempt to tackle unversioned shared libraries in a more comprehensive fashion. Shared libraries with an SONAME that doesn't contain a version number can't be represented in the shlibs system (but can in the symbols system), so Lintian always reports them as missing from shlibs when they're installed in public directories. That's not really the right tag, since they don't belong in shlibs. The more basic problem is that, except for a few special cases mostly coming from libc, they really don't belong in public directories. With no versioning in the SONAME, we can't handle changes to the ABI without completely changing the library name and can't use the shlibs system to manage them. Most of the libraries in this situation are actually private libraries for one particular application. As Policy already says, those libraries shouidn't be installed in public directories like /usr/lib; they should be installed in private subdirectories of /usr/lib for that application. The biggest group of offenders here currently seems to be KDE; for some reason, unless I'm missing something, this seems to be a semi-standard KDE way of doing things. This version of Lintian will hopefully handle this better. Such libraries won't be expected to be in shlibs files and won't get erroneous tags about not being listed there. We'll also do a better job of distinguishing between versioned shared libraries and shared library names that just contain a hyphen. Such unversioned libraries will get a separate tag pointing at the portion of Policy that says to put private libraries and plugins in a subdirectory instead of /usr/lib. Thanks as always to Frank Lichtenheld, Adam D. Barratt, and Jord Polo for all the hard work they've been putting into Lintian. It's gotten much better over the few months that I've not been able to work on it, which is making me more excited to get back to it and do more.

This is the follow-up on my Asus EEE PC configuration. Next on my TODO list was to make the webcam work, and as Ben Armstrong had pointed it worked fairly well, proving to be a non-issue. After that, I decided it would be a good thing if the presence of my bluetooth-enabled cellphone were tested, so that if I walk away from the PC, it called xscreensaver -lock. After some googling, I found a tool that did just that: BlueProximity. It really seemed a good idea, except that my cellphone (a Palm Treo 650) kept warning me about a connection going on, which was quite unpleasant. This happens because BlueProximity tests the RSSI of a bluetooth connection Beautiful, but a little overkill for what I wanted: I just wanted to know if it is there or not. First I tested the bluetooth discovery with hcitool scan, but for that I would have to keep my cellphone Discovery On, which is not a smart thing to do So I tested other things, and found out that hcitool name XX:XX:XX:XX:XX:XX only returned the name of my cellphone if it were around. So that was what I used. This is treo-presence.sh script:

#!/bin/bash
TREO='XX:XX:XX:XX:XX:XX'
NAME='name_of_my_cellphone'
CMD="/usr/bin/hcitool name $TREO" 
if [ " $CMD " = "$NAME" ]; then
  exit 1
fi
exit 0

It returns 0 or 1 if the TREO device is absent or present, respectively. I use it from the following cron script:

#!/bin/bash
/usr/bin/w   /bin/grep $LOGNAME > /dev/null 2>&1
if [ $? -ne 0 ]; then
  # Running user is not logged in
  exit 1
fi
CMD="/usr/local/bin/treo-presence.sh" 
LOCK_CMD="/usr/bin/xscreensaver-command -lock" 
FILE="/tmp/no-treo-lock.txt" 
TMPFILE= /bin/tempfile 
/bin/touch $FILE
/usr/bin/tail -2 $FILE > $TMPFILE
$CMD; echo $? >> $TMPFILE
/bin/mv $TMPFILE $FILE
/bin/rm -f $TMPFILE
for line in  cat $FILE ; do
  if [ "$line" = "1" ]; then
    exit 1
  fi
done
# Got here: all 3 lines are not 1
$LOCK_CMD > /dev/null 2>&1
exit 0

This is run from the user crontab file every minute, recording the last 3 runs in a file in /tmp. If all 3 runs indicates the absence of my cellphone, xscreensaver -lock is called. Simple enough and doesn t give me connection warnings in my Treo. Other approaches are surely possible. Also, I am not sure treo-presence.sh would work for other devices This is just what works for me

In June 2007, I bought a new 9-cell-battery for my ThinkPad notebook. Since then, I recorded, via a cron job, every five minutes these bits of information:

• time
• design capacity
• reported last full capacity
• state (charging, discharging, charged)
• (dis)charge rate
• remaining capacity.

I had planned to make some detailed analysis of this, but I haven t gotten around to do more than this graph (warning, large), of which the following iis a cut out. Since I now got a new laptop (with a new battery), I ll share my records. I find it interesting that the last-full-state sometimes jumps up, closer to the design state. This could be re-calibration. Or the battery, after a while, re-scales iits output to appear less degraded. This might be checked by comparing the speed of discharge and charge at various points in time.If you want to do some analysis of your own, you can download the raw data (44354 data points). It has been anonymised by starting the time counter at zero, and shortening any gap of more than four hours to four hours. If you want to do some analysis in Haskell, you can take some code from my anonymizer script to parse the data. If you happen to find something interesting, appropriate crediting is appreciated.

In June 2007, I bought a new 9-cell-battery for my ThinkPad notebook. Since then, I recorded, via a cron job, every five minutes these bits of information:

• time
• design capacity
• reported last full capacity
• state (charging, discharging, charged)
• (dis)charge rate
• remaining capacity.

I had planned to make some detailed analysis of this, but I haven t gotten around to do more than this graph (warning, large), of which the following is a cut out. Since I now got a new laptop (with a new battery), I ll share my records. I find it interesting that the last-full-state sometimes jumps up, closer to the design state. This could be re-calibration. Or the battery, after a while, re-scales iits output to appear less degraded. This might be checked by comparing the speed of discharge and charge at various points in time.If you want to do some analysis of your own, you can download the raw data (44354 data points). It has been anonymised by starting the time counter at zero, and shortening any gap of more than four hours to four hours. If you want to do some analysis in Haskell, you can take some code from my anonymizer script to parse the data. If you happen to find something interesting, appropriate crediting is appreciated.

It's been a long time since I wrote about aptitude-gtk. Mostly that's because I haven't been doing any work on it, due to a combination of several holidays, sickness and (last but certainly not least) an unfortunate relapse of WoW-addiction. But we have moved the ball forward since the 0.5.0 release. Some of the changes since then are just polishing, with no major changes in functionality, but there are a few things that are very visible: Status pipe support aptitude now supports the dpkg status pipe. This means that it can display a progress bar showing how far through the install process it is. In fact, if you are using the Gnome frontend for Debconf, you don't even need to display the terminal at all, unless a package is so uncouth as to prompt directly on standard input. I'd like to thank the Synaptic developers -- although this is all my own code, their implementation of this functionality was very valuable documentation of how apt frontends use the status pipe in practice. Incidentally, the aptitude implementation is modularized and available in src/generic/apt/parse_dpkg_status.cc and src/generic/apt/parse_dpkg_status.h. If you want to parse dpkg messages in your own GPL project, you might want to take a look at that code. And if I don't forget, I'll ask about including this in apt once the lenny freeze is lifted. [0] Here's the dpkg progress bar in action, showing that dpkg is configuring libmad0: Clicking the "View Details" button on the dpkg progress bar will pop up a terminal in a new tab; you can close the tab and dpkg will go back to running in the background. And yes, I know that the progress bar for the download shouldn't hang around after the download completes. Searching for partial strings As noted in the release notes for 0.5.0, incremental searching from the curses frontend was broken by the 0.5.0 release. I've created a new match term named ?term-prefix which matches against any extension of the term; for instance, searching form ?term-prefix(comp) will find any package that matches the term compiler, the term computer, the term compromise, or any other extension of comp. The upshot is that incremental searching should work again. Editing the list of visible columns The current package list doesn't show very much information. That's deliberate: I don't want to clutter the default view with a lot of stuff that's only necessary from time to time. But until now, there was no way to change which columns were visible. Now there is: This is a very rough proof-of-concept dialog that I've just checked into the source tree. The checkboxes are fully functional (clicking them shows and hides columns), but the buttons to save the current setup or to apply it to all the active tabs are not working. With this in place, we can think about creating columns for most of the interesting information about a package (archive, maintainer, etc). [0] By which I mean, I'll say does anyone object if I add this utility code to apt?, and when no-one says no I'll commit it.

I use public-key based access for a number of things and gpg-agent is a useful way to avoid having to repeatedly type the passphrases needed to unlock the private-keys. The agent prompts you for the passphrase and then uses the unlocked keys for a user-determined time-period. For a number of reasons it is a "good thing" if this prompting happens in a different interface from that where the key is being used. In an X window environment this is done by the pinentry-gtk avatar of pinentry which pops up a new window. However, I use screen to multiplex operations within a single terminal session, often without an X session. It used to bother me that I could not get pinentry-curses to pop up in a different window. No more ;). Here is a hack that seems to work.

1. Decide on some location like $HOME/.gnupg/pin-tty and assign it to the variable PINTTY.
2. Use the additional options --ttypath $PINTTY, --ttytype screen and --keep-tty for gpg-agent.
3. Start a screen window with the command screen -M -t pin socat -,raw,echo=0 PTY,link=$PINTTY

Now everytime a program asks gpg-agent to use a secret-key, it will invoke pinentry-curses which will connect to the pin window under screen; the latter will warn you (-M) that something is asking for a passphrase. It would be nice if one did not have to invoke socat and screen could do step (3) directly. Is there any way to integrate the use of gpg-agent with openvpn when the latter uses SSL keys? There may be some security issues with such use! I can't see any at the moment but I may be wrong. :-(

I switched to git from mercurial about 4 months ago. As Matt Mackall (the main author of mercurial) has pointed out, my arguments were partially just excuses for the switch, because everything could be fixed in mercurial as well (eventually). On the other hand, I really wasn't expecting to switch when I invested time and energy to learn mercurial. Also because I thought that git doesn't have such a nice documentation, has a steep learning curve and the community is hostile, because it is developed by the kernel people who are famous for sometimes being not so nice on the mailinglists (as I now found out, none of these are true). I was getting annoyed by small things one by one, after finally I said to myself enough is enough, let's just switch.

So as to the steep learning curve --- it took me a day or two to being able to do what I want, so it seems to me it's really easy to learn once you know some distributed vcs. I found out the documentation is much better than in mercurial --- in git one just types "git help command" and a full man page fires up with lot's of information and examples. In mercurial, one just gets a couple lines (compared to git) of help in the terminal, without examples. Also the first (actually second) thing I noticed is that "git log" (and other commands like "git diff") doesn't scroll out my terminal, but uses "less" automatically -- that's just great. The first thing I noticed is that git is superfast for almost every operation, especially it's noticeable with "git diff". As to the community, I only had a chance to send a few emails to the git list, so I cannot really say, but so far it's very responsive and friendly.

However, those are just little things that can (and I am sure they will) be fixed in mercurial as well. What is a big thing are branches, especially remote branches. One just fetches a remote repository and then works with it like with any other local branch, e.g. one can switch to it, or just "git log some_remote_branch" to see what is in there. One can easily compare them etc. With mercurial, I was using "hg out" and "hg in" commands to see what changes I will pull or push, but those commands require internet connection, so it really sucks and it's slow. In mercurial, I was using different directories for different branches, but that's just extremely inconvenient and also slow (creating a new branch is just a matter of adding one file, not copying the whole repository --- for example with the sympy hg repository, I often had to wait several seconds to clone a repo, while with the git repository it's just instant) and big (in terms of megabytes).

The bible of Mercurial, the hgbook says:

In most instances, isolating branches in repositories is the right approach.

But I think it's the wrong approach. The only argument for doing this that I accept is that sometimes you are not sure which branch you are in in git --- well, I use this trick (actually, just read the documentation of __git_ps1 in /etc/bash_completion.d/git), so my bash line always says which branch I am in using the red color. I never do any mistakes with this.

Anyways, I could continue like this (e.g. check out "git svn", "git rebase -i" and many other things), but you can read why git is better for example here, no need to repeat here. I am very happy now and I can only recommend to learn git.

So let me also say some things that are worse in git --- one thing that could be improved are URLs of the gitweb (hgweb urls are neat, gitweb urls use "?id=..." stuff). Another thing is that the debian package git is not git! You need to install git-core to get git (but this seems to be getting fixed).

There is also an interesting discussion happening right now in the debian-python mailinglist about switching the DPMT repositories to git. I think almost all opinions (for and against) were already stated, but if you have some opinion that wasn't yet said, please do so.