A view from the hill - Computer

I'll never be anybody's hero now

nospam@example.com (Holger Schauer) — Fri, 20 Apr 2012 09:00:26 +0200

One aspect I think is important for a Scrum Master or Project Manager is to make sure that your team doesn't go on a trip to Vienna (if that term doesn't ring a bell, search for "Tom DeMarco peopleware"). Quite contrary to popular management belief, I think in general it's not okay if "occasionally" somebody on the team "puts in some extra work". There is a reason why many agile methodologies insist on keeping a sustainable pace. Besides all of the very good reasons for making sure your team members stay healthy (see this Burnout story as a negative example), there is also a management point to it: your understanding of what the team is capable of (in terms of results/effort, aka velocity) decreases substantially if you have to take "heroic behaviour" into account. It's particular bad when you don't see the connection between reached goals and involved effort, i.e. when team members just move their card from "working" to "done" late in the evening without making clear that it involved five hours more than initially estimated.

Heroic behaviour just can't be counted on, because nobody will be able to keep it up over a substantial amount of time (that's the very definition of not being substainable). It's highly understandable that project members after having committed to some goal can be tempted to go out of their way to reach it. What team members might miss is that "heroic behaviour" can only have an influence on the "time" aspect of the magic triangle of "time, budget and quality". Extra effort is just that: effort. Hence, it comes with a cost, with the cost it just takes to reach the goal. I've also seen that there is a misunderstanding of the term "commitment". It's not an unconditional promise of "I can do that task with the effort I think it takes", there is also the implicit condition of "I understand correctly what the task involves and there is no other external negative influence" (e.g. the urgent bug that needs to be looked at, or the lack of sleep during three days of the week due to the kids being sick at home).

Commitment to a particular goal might at times conflict with taking responsibility for the project as a whole. As a general rule of thumb it's nearly always much more important to think about the entire project / the big picture than about a small aspect of it. There is the exceptional situation that needs exceptional reaction and maybe exceptional effort. But it's important to treat it like an exceptional situation. And for these exceptional situations it's vital that they get treated like a mini project: they should have a clear purpose and have fixed start and end dates. Plus, they should come with a compensation. Scrum Masters and project managers alike should communicate clearly that exceptions are exceptions, not the rule. And team members should clearly communicate that it takes what it takes. When it comes to professional work, follow the 501 manifesto (in case you don't directly understand the "501" part like I did: it's not about jeans, but about leaving at 5:01pm).

ObTitle: Morrissey, from "Ringleader of the tormentors"

New year meme

nospam@example.com (Holger Schauer) — Wed, 28 Dec 2011 22:38:00 +0100

Tarek Ziades repeated his Python new year meme in which he summarizes his accomplishments in the Python world this year and his considerations for the new year. As I stopped working as a Python developer some time ago, I will hence drop the Python restriction although I will keep the restriction on only looking at developer questions.

1. What’s the coolest developer application, framework or library you have discovered in 2011?

Mostly stuff I already new about but hadn't specifically the chance to use previously, so actually there was probably nothing which I would call 'cool'. For one, I started using git this year. For other projects, I took the next step and started hosting my Mercurial repositories at bitbucket. For another, I used nose for unit testing my Python stuff.

2. What new programming technique did you learn in 2011?

Probably the most interesting stuff I learned this year was from me finally reading AMOP (the Art of the Meta-Object Protocol), thereby learning a lot about the meta object protocol in Common Lisp and how it's related to CLOS. However, I didn't really put it to use much, although in hindsight I recognized that I've used stuff from it previously without understanding the complete picture. There was also a lot of 'enterprise technology' I looked into this year but nothing could be directly be labeled a 'programming technique'. Otherwise I think I mainly stuck to the techniques I'm used to.

3. What’s the name of the open source project you contributed the most in 2011? What did you do?

My contributions to the free software world continue to be at a very low level (typically, I don't contribute anything of value besides small hints on the net, complaints and the occasional bug report), which I keep seeing as a personal weak spot. This year at least I managed to implement something for CL-SQL. I also wrote two small utilities, mainly to scratch my own itch, which I still need to clean up a more before I could publicly present them.

4. What was the development blog or website you read the most in 2011?

That's certainly proggit, followed by InfoQ. I also follow Planet Lisp and Planet Python quite closely. I started again to listen to the podcasts by Heise developer and the software engineering radio, but I have to admit I'm too easily distracted to really keep going.

5. What are the three top things you want to learn in 2012?

I would like to continue to learn Clojure, finally writing some useful code in it. In particular, I would like to mess around with parallel computations, although there is a huge chance I'll apply it for small silly tools or web programming first. I would also like to work on some semantic web stuff, probably with RDFa. And maybe I'll take a look at programming with some of the more or less free tablet stuff, either WebOS or Maemo/Qt. I'll probably also continue to look into Java programming and common architectures on that platform, which is an enormous universe.

6. What are the top software, app or lib you wish someone would write in 2012?

I would like to see the semantic web getting a little bit more traction, mainly by easy integration of stuff like RDFa into content management systems. And, like probably every year since 1999, I wish somebody would finally write an (open source) application/set of clients to finally solve the synchronisation problems between different computers/phones/tablets. Note: I've given up on the wish that somebody writes an enterprise acceptable open source replacement for Lotus Notes or Outlook (and I'm talking only about calender and mail, sigh).

Agile development -- what is the benefit for the business?

nospam@example.com (Holger Schauer) — Mon, 24 Oct 2011 14:38:00 +0200

In a recent meeting, a colleague of mine mentioned that we wanted to use agile development this time with that new project and that I would provide some insight as an 'agile development expert' (not that this would be a term I would use). This in turn brought me some curious looks and a pretty general question during the discussion: what is the benefit of an agile development model from a business perspective anyway?

If I remember correctly, my answer went in the direction that with an agile approach you can change your mind about what you really need/want to implement throughout the project, if you learn something 'new' about what is really required. The second important aspect is that you get quicker feedback which allows for more influence in case things don't turn out right. After the meeting I started pondering the question a little, as I had the impression that my answer wasn't that convincing, so what you find below is a more detailed written elaboration of it.

Basically, what "you can change your mind throughout the project" boils down to is that agile development gives you more options to make use of opportunities coming up along the way/throughout the time you need to implement the project. The most important idea here is that you don't make decisions too early, because that limits your options. For an example, let's assume that one feature we specify is that we want to have a 'Facebook like'-button on the order page. Now, if we're following the waterfall style 'implementation follows after specification has been completed' development model, you would specify that and design the page with the button and at some time in the future, you hopefully get your Facebook button. But maybe during the hypothetical nine months from now in which development happens, what if Germany's privacy laws enforce new severe restrictions on the use of such buttons and, btw., Google+ is now the new hip site you have to support? You have to go through a (with larger features typically quite costly) change process, redo the specification, etc. This essentially makes the cost you had in writing the specification as well as for the design etc. a double problem: you didn't get out any ROI, obviously, but additionally time has passed while writing specs, doing design etc. in which you didn't really work on any results for the customer (lost opportunity: gather new clients with at least some new features).

So, you would have been better off with having the idea that at some point throughout the project you want 'social media integration for marketing reasons' and delaying what to do exactly until you're really there (from a priority point of view) where this is a feature that you want implemented -- i.e. you do the specification when your planning that feature to get implemented in the next development phase (which is typically two to four weeks with an agile development team). The idea is to take small, well defined steps that can be taken fast and starting out with the most important/valuable ones first, rather than to spend a lot of time on some 'complete specification' which withers fast throughout the projects implementation time.

The problematic point here is obviously, that it's pretty difficult to say when exactly is the right point in time to make a decision. In general, there is no 'right point' -- also often called the last responsible moment after which some opportunity is lost (I think the phrase was coined by Mary and Tom Poppendieck, see the excerpt from 'Lean software development') -- but multiple points in time, depending on many aspects. Influencing aspects are things like business opportunities (e.g. a new feature nobody else has at that time) or reducing risks (projects risks) (cf. Alistair Coburn reconsidering the least responsible moment). The best answer I currently have seen when to make a decision is that it should be taken when you have 'enough knowledge', i.e. when you have carefully considered your options and evaluated them (cf. real options). Even thinking about options alone is typically a highly valuable undertaking in itself, because all to often people just assume that the 'obvious way' is the best one.

So, the general answer is probably along the way of: for the business side, agile development has the benefit that it provides more flexibility and more influence throughout the project phase while at the same time (possibly) generating real value/revenue more early. There is, of course, more to it that also has appeal from a business perspective, but that's probably the main point. Feel free to add different opionions.

It took quite a while but ...

nospam@example.com (Holger Schauer) — Mon, 02 May 2011 18:41:00 +0200

After a period of nearly two years in which XEmacs beta stayed at version 21.5.29, XEmacs 21.5.30 and even XEmacs 21.5.31 (beta) have been released. The most noteworthy change (and the reason I'm blogging this at all) is that XEmacs is now licensed under the GPL v3 and is hence back in a position in which it can incorporate (port) over code from Gnu Emacs. This in turn means that the increasing gap between XEmacs and Gnu Emacs, which has been widening in last years, may get a little narrower if people put some effort into porting stuff over. Hopefully, we'll also see a release of a stable XEmacs 21.6 some time this decade (21.4.12, the first version of 21.4 which was promoted to 'stable' was released in 2003, so it's arguably due in two years ...)

Report about the European Lisp Symposium 2011

nospam@example.com (Holger Schauer) — Mon, 04 Apr 2011 21:25:00 +0200

So, ELS 2011 is over which was the first conference I attended that was solely aimed at Lisp programmers. Overall I am quite happy with it although not all talks have been of the same quality. In particular I wasn't too excited about all three key notes, although all had interesting topics. The first one by Craig Zilles about best effort code optimization was about things intelligent compilers could do. Very interesting stuff for sure and I learned a lot about low-level soft- and hardware architectures but there was no apparent direct relation to Lisp. A similar problem troubled the talk about Scala: perhaps it was due to my late arrival (I got on the right subway but in the wrong direction, not for the first time) but the part I attended left me wondering why Scala is relevant on a Lisp conference. Marc Battayani's invited talk about his use of Common Lisp for programming FPGAs was nice, but first of all it was difficult to follow (not due to the content) and not many details were given about how the specialized Lisp embedded DSLs get converted to the FPGA specific code and what problems he had to overcome.

Now for some of the interesting regular talks: on Thursday, the report about porting SBCL to the supercomputing Blue Gene/P was nice and raised an interesting question: what can/needs to be re-discovered from old Lisp dialects for parallel programming for Lisps when more and more parallel cpus are becoming available to programmers. An issue that came up in both the talk about the futures implementation for ACL2 and in Nicolas Neuss' initial digression about his experiences in parallelizing Femlisp was that garbage collection can get in the way of effective parallelization, up to the point where much of the expected speedup is lost. The motivation of the talk about actors framework named Jobim for Clojure nicely fitted in with an immediate question that came to my mind when I saw how Clojure connects to Java: What do you do so that Java's semantics don't leak into your application code? They seem to have found a nice way to abstract away the underlying Java libraries in their framework. In the last session of the first day, the lightning talk session, two things were interesting: Ralf Möller talked about using user-defined method combinations as a more powerful approach than design patterns, showing how one might implement html specific print-object methods, and Didier Verna talked about user-extensible format directives which he wants to turn in as a CLRFI. Having done a lot of work in computational linguistics, the talk about S-NLTK, the Scheme toolkit for natural language processing, was nice to see. Damir Cavar did a good job promoting the toolkit which has a similar aim like the Python NLTK, although I would have liked to learn more about the API and implementation issues. Finally, Alec Berryman by ITA gave a last minute presentation about things ITA learned about optimizing stuff for SBCL and about issues arising when adopting the old code to multi-threaded programming. Interestingly they didn't report about gc issues but that may be related to their extensive use of object caches of pre-allocated objects.

The final panel discussion with James Knight, Christophe Rodes, James Anderson and Martin Simmons went back and forth about concurrency, distribution and efficiency vs. performance. The discussion took up several points from the talks, including gc and hardware issues. I took away from the discussion that unsurprisingly a lot of open questions need to be solved of which people are aware while at the same time there doesn't seem to be much momentum, which, given that the community isn't that big, isn't surprising either after all.

Summing up I liked it a lot. For one, it was very nice to see people you only know via the net (while I haven't been active in the community in the last years, I was surprised to see people recognize my name). For another, I also think that the organizers made a good decision to select a main theme for the conference and an important one, too. It really set the main theme for the conference and the discussions, and hence nicely reached its goal. Generally speaking, the conference was nicely organized so thanks for a pleasant time in Hamburg.

Lisp, sql, git and mercurial

nospam@example.com (Holger Schauer) — Tue, 29 Mar 2011 21:25:00 +0200

This has been a rather unpleasant month (don't ask, I won't tell) but right now I'll look forward toward its end because of two reasons: for one, I'll be in Hamburg for the European Lisp Symposium for the next two days; the program for the ELS has also been published in between. I'm really looking forward to an interesting set of talks. For another, some patches to CL-SQL which add support for autoincrement behaviour for Postgresql, are probably going to be released soon. To clarify, "autoincrement" is a column constraint in MySQL (among others) that automatically increments the value of the column when a new row is inserted when no value for the autoincrement column is given (cf. MySQL docs on AUTOINCREMENT), a behaviour that Postgresql supports with the serial constraint (cf. this wikibook on converting between MySQL and Postgres). Actually, that has been my first substantial amount of Common Lisp programming in the last two years, which has been triggered by an upgrade of my Debian system. This upgrade implied that an old application of mine would now use CL-SQL version 5.0 which in turn broke the app: I had simply specified a db-type of "serial" previously, but the new CL-SQL code wouldn't recognize that it had to fetch the automatically generated value from the DB when inserting a new record. More details on the patches can be found on the CL-SQL mailing list.

The developement of this addition was also the first time I had a real-world setup developing with git. In my own projects I use mercurial, so I was eager to learn a little bit more about the differences. It's funny that a recent opinonated article "Why I like mercurial better than git" more or less talks only about the one point that I found confusing: branch handling. For more background information, I suggest reading this article "A guide to branching in mercurial". Basically, in my current projects where I use mercurial, I'm using the "branching with clones" approach Steve is describing there. When working on the patches for CL-SQL, I was working on the existing autoincrement branch but when I was through I wanted to port my patches to the master branch. When using mercurial with the described approach, selecting (pulling or pushing) my patches and only my patches to the master branch is dead easy: you just issue a pull/push command restricted to the "right" changesets. Doing this is even supported by Subversion these days via svn cherry picking. Looking at the docs for git pull, fetch and merge, I wasn't able to figure out what the corresponding "right" incantation for git might look like, if there is one at all. As I didn't want to hose my "working copy" (sorry for the SVN term again), I resorted to git format-patch, git am resp., which worked fine. Please note that I'm not suggesting that it's not possible with another approach, quite to the contrary I would be happy to learn about it. One thing that I found rather useful is git's stash command which let's you safely abandon your current work to fall back to the last commited version, in order to be able to work on something that popped up in between (typically a minor unrelated problem you encounter while working on a larger piece of changes). I understand that mercurials patch queues enable a similar functionality, but I haven't used them sofar. Another thing that I found very useful is git's very easy way to correct (or in git terminology "amend") a commit by just issuing "git commit -a". I also like the idea of the "index" or more exactly that you have to explictly "add" which changes you want to commit. A similar behaviour is possible with SVN "changelist" command, but the mere existance of a changelist is not automatically honoured by SVN's commit.

European Lisp Symposium 2011 in Hamburg

nospam@example.com (Holger Schauer) — Sun, 27 Feb 2011 17:13:00 +0100

Hamburg, I'll see you soon -- for the 2011 edition of the European Lisp Symposium. I haven't done much Lisp programming in the last two years, but as I can combine visiting a good friend with a nice conference, I just couldn't resist. I'm really looking forward to meet several people I've had contact with over the net in reality. (And don't forget about that unresolved tension.

Wenn Du denkst, du denkst, dann denkst du nur, du denkst

nospam@example.com (Holger Schauer) — Mon, 07 Feb 2011 10:16:55 +0100

Heute nur ein kurzer Verweis: Wenn ihr denkt, es gilt das freie Netz zu beschützen, solltet ihr noch mal genauer hinschauen. So zensiert ist das Internet schon heute. Interessant ist vor allem auch die grobe Kategorisierung, was und warum zensiert wird (via Fefe).

GNUPG and locale weirdness

nospam@example.com (Holger Schauer) — Sun, 16 Jan 2011 17:19:43 +0100

Today, I solved a really troubesome problem for me: I couldn't access my GPG secret key. Which means that whenever I needed my secret key, for example when I wanted to sign some text and I typed in my key, I just received a "bad passphrase" error message. Not using GPG on a regular basis, I wasn't at all sure that I had used the right passphrase. However, today I recognized that I had another secret key for special usage, for which I had specifically written down the passphrase -- and which didn't work as well.

This finally convinced me that there was something else wrong beside a faulty memory of the passphrase. And indeed, when I tried signing a mail in Gnus/PGG, typing in the exact same passphrase as I had on the command line, everything was fine and the message got signed. But then what was the difference to using gpg from the command line? I was suspecting that some non-ASCII characters I have in my passphrase might not reach GPG as intended, so I started looking at the locale settings. Some more experiments confirmed it: nowadays, my xterm (which is an lxterm really) is highly probably using a different key setting as it used to, after a re-installation of my desktop some time ago. I'm not too sure what it used to be, probably ISO-8859-1 (aka Latin-1) or ISO-8859-15 (aka Latin-9) or "C", but it's now using de_DE.UTF-8. Simply setting LANG to C inside a running xterm didn't work out as I hoped, probably because of the way the locale settings (probably LC_CTYPE) are used by xterm to set up keyboard handling. But when I start up a different xterm with LANG set to C in advance, i.e. do a "LANG=C xterm &", gpg happily accepts my passphrase. Problem solved.

Moral of the story: charsets and input formats are a constant source of joy unless everything is unicode.

Laziness for the win

nospam@example.com (Holger Schauer) — Tue, 14 Dec 2010 19:10:00 +0100

Loren Segal writes a blog discussing the question whether users of dynamically typed languages are just too lazy to type? The argument goes roughly like this: The dynamic is not in "passing wildly arbitrary ever-changing types to methods" and we're just (okay, not only just, but mainly) doing dynamic code generation and are too lazy to add type information. Regarding a particular, but not too relevant code example, Loren says:

It’s easy to see that this code is executed immediately at load time. Although it’s possible for someone to generate a method at run-time (by run-time I mean much later after the initial .rb file was require‘d), it’s a fairly rare occurrence. What we’re really doing here is just avoiding to extra LoC involved in typing out those def’s each time. What we’re doing here really is just runtime code generation.

Yes, Loren, it's just runtime code generation, but calling it 'just' is somewhat misssing the point. I mean, if runtime code generation is not dynamic, what is? Loren goes on to say that programs in dynamic languages with these runtime modification behaviours often stop modifying their behaviour after a certain amount of "load time". I agree, this is also what I would expect. But the entire point is that once again, "dynamic" means that it is not necessary that you have to (statically) pre-determine at some fixed time (compile time or initial process launch time) which stable behaviour it should be. Of course, after a certain amount of load time, it's likely that the behaviour of your program (or better said of the running process) becomes stable and all functionality needed is loaded. But a different process of the same program may use a different set of possible behaviour. Plus: you might be able to add new functionality to a running programm. Additionally, you don't necessarily have to provide all possible behaviours at start-up time, runtime code generation (or runtime code loading) allows you to add new behaviour later on. In some cases (Ruby and Lisp come to mind) it is even possible to alter existing behaviour. Now, if "typical" dynamic programs really don't do that routinely (as suggested by the studies Loren is citing) this says more about how often we (really don't) need such dynamic behaviour but it sure is dynamic.

However, I must admit that I'm a little surprised by the cited results of the studies. I've seen systems that have the ability to change their behaviour at runtime one time too often. First, there are programs that embed some extension mechanism (be it embedded scripting languages, plugin mechanisms or other) that are specifically crafted for users to tinker with the running system, which clearly is all runtime code generation. Second, a particular interesting aspect of web programming is that many templating engines have some kind of import/include statement that are typically used to build complex templates out of smaller ones. In combination with other features of template languages, specifically conditions, loops and even macros (cf. stupid template languages, not so stupid template languages) this feature can be and is used to alter behaviour at runtime. So, obviously there is a need for dynamic behaviour, and people find ways to scratch their itch. Note that neither of my two examples require dynamic languages, so it's not a rebuttal of the studies or Lorens claims. However, thinking about it, I would expect that a lot of programs written in your todays typical dynamic language are 'scripts', which might be the reason why most people treat the idea of 'dynamic language' as synonym to 'scripting language' (it isn't -- Common Lisp, for instance, is surely a dynamic language, but hardly a scripting language). That such scripts don't require much dynamic change in runtime behaviour isn't too surprising, after all.

Now ultimately I wouldn't really disagree with the impression that quite often one "value" of dynamic languages lies in reduced typing and that on the contrary some type related problems would be found more quickly in static typed languages. I would even go so far and say that wrt.

I’d really love to see some research on case studies of how often arbitrary structural typing (that cannot be refactored into polymorphic relationships) is really used in dynamically typed languages. If anyone knows of any research/papers in this field, I’d love to hear about it.

it's highly likely that it's extremely rare to find "arbitrary structural typing", if such a thing exists at all (ironically I would guess that using 'void *' as a type specifier in C functions is where one comes closest to "arbitrary"). To me the very idea looks suspiciously like a strawmen for an argument that if there were "no arbitrary structural typing", we could/should go for static typing anyway, as we could "reduce" the solutions we implement with dynamic typed languages to solutions in statically typed languages (an argument coming close to the 'turing complete' hammer). This looks like a distinction between 'we can't use type information at all' and 'we need to use type information at each and every place' and I don't believe that the world is only black or white.

The point I want to make is this: Let's assume it may be very much the case that in all places where dynamic typing is used you can find a static typed solution, too. Then the benefit is of course not that "you're doing something that's not possible in statically typed languages" (which might still be true under the interpretation that the statically typed solution probably looks rather different). But there might be plenty of room for benefit in that coming up with a solution in the dynamic language might reduce cost (e.g. less development time, greater flexibility for extension later on). The arguments by proponents of static languages that the cost reduction lies in other aspects (e.g. earlier detection of errors) are surely worth a comparison. If studies for this question of associated costs beyond anecdotical tales exist, I would be interesting in seeing them.

Update: Uncle Bob raises another important point that with introducing static type information we'll get closer coupling:

But in the end, we like dynamic language not because we are too lazy to "Type". We like dynamic languages because we are tired of untangling couplings.

Coders at work

nospam@example.com (Holger Schauer) — Wed, 22 Sep 2010 20:38:00 +0200

For the holidays I finally bought Peter Seibels Coders at work, which is a very unusable book about programming: it consists solely of interviews with pretty well known programmers or "coders". It's an interesting constellation: On the one hand, Peter Seibel is well known in the Common Lisp community for his book Practical Common Lisp which gives a modern view on Lisp: not only is it an introduction to the language but also to several libraries and the general setting of modern lisp programming. On the other (fifteen) hands, there are people like Jamie Zawinski (XEmacs, Netscape), Don Knuth (TeX, Art of Computer Programming), Guy Steele (Lisp, Scheme, Java), Peter Norvig (PAIP, Google), Brendan Eich (Javascript) and Ken Thompson (Unix) -- just to note the ones that are probably the most well known.

I've had resisted the urge to buy the book because I've always felt that programming is a craft that ultimately forces you to make your own experiences. I mean, you can read all the books you like but ultimately you have to make your own hands dirty to really get knowledge about the issues involved. So, what could I learn from other peoples experiences? On the other hand, as a lightweight (in terms of reading attention) holiday book it seemed about right, so I finally gave in.

Well, the book turned out to be a real page turner for me. It's a fascinating read because of the re-occuring topics Seibel is addressing and the various opinions he got. He addresses topics you would expect like preferred tools (e.g. editor), worst bugs, debugging techniques, asssertions and verification, literate programming (which suprises me a little), design approaches and team work, but of course the main focus is the personal experiences and how they wound up with whatever made these guys known. One thing that I liked is that Seibel has a way to ask good follow-up questions to the responses he gets, without ever letting his own experiences or opinions getting in the way, which I can imagine has probably made for pleasant interview situations (at least I take away that impression). I wouldn't have imagined beforehand that I would find the different stories how the guys (and one woman) got into coding so interesting. There are very few people in this book whose experience doesn't go back to teletype and time sharing systems. Of course, as a result these stories tend to be similar, but the details differ enough that's it doesn't get too boring. Starting with computers in the early 80s, I don't have any experiences with such systems and which I frankly don't miss at all after reading more about it. But just to get to this conclusion is interesting: the constant comparison with your own experiences and opinions you can't help but make while reading this book alone is worth buying and reading it.

Over all, it's hard to say which interviews I found the most interesting one, essentially each has some unique point or other. That being said, the interviews with Joe Armstrong and Guy Steele made a lot of impresssion on me, whereas I'm a little disappointed by the one with Peter Norvig (though he had the funniest quotes), but I can't really nail down why. I didn't particular like the interview with Brad Fitzpatrick, it didn't seem to contain as much information as the others. And Joshua Bloch seemed to hype Java all the time which I found not very convincing -- the idea that todays larger context for programming contains quite a few different languages and approaches seems to elude him.

There are some points I took away from this book: For one, most of the interviewed people seem to be much more concerned with data types than I am, even the ones who have done extensiv work on dynamically or weakly typed languages. I guess I should really take a closer look at that topic and, to make it more concrete, play around with e.g. Haskell. Another point is that concurrency or parallel programming is a topic that (IIRC) all of the interviewees have seen as being responsible for the worst bugs they encountered and as a result are interested in newer approaches like STM. So, it might be worthwhile to look closer into such developments, for example by playing with Clojure, Erlang. or the transaction monad, if I'll ever really play around with Haskell. A third point is that I realized that I'm not keeping up with academic research in CS and, not having TAoCP, might never have been up to date at all. I'm following a few online references like LtU, but not closely and it's pretty rare these days that I look deeply into some research paper. This is something else I should probably change, if time permits.

Every planet we reach is dead

nospam@example.com (Holger Schauer) — Thu, 29 Jul 2010 21:02:00 +0200

When I bought a new workstation some time ago, I made sure it would have much more power than I would probably need. One reason for this was that I wanted to toy around more with virtualization. I had successfully used VMware server on a comparingly weak laptop some time ago, but opted to try out the more recent open source solutions. I looked briefly at VirtualBox but that seemed to be very similar to VMware which I already knew, so I didn't really pursue this path. Xen had caught my interest for quite a while, but it looked to me as not to straight forward to setup and as of not-so-recent time, KVM seems to be the new kid on the block that nearly everybody seems to see as the more natural solution for linux users.

What got me going was that I wanted to take a look at how far Debian Squeeze had already got. In particular, I wanted to try the amd64 bit variant, but as I quickly discovered that requires a 64bit host installation. So, off I went, re-installing my lenny system to be 64bit instead of the original 32bit system I had been using up to then, thinking that I could easily re-establish that 32bit system as a virtual system on top of my 64bit host. The general idea was to have a relatively clean host system with several guests for developing, surfing and working running on top of it.

Given the considerations above and that Debian ships with easy to install KVM packages (see the debian wiki on KVM for details), that was the way I choose. In particular, I installed the KVM and qemu packages as well as virt-manager, a graphical frontend to manage virtual machines. And sure enough, setting up a first virtual machine really looked easy: click a few buttons, decide on a few things like image size and feed the machine an installation medium of the OS to boot. For this installation medium, I choose a squeeze netinstall image. However, as I soon discovered, the squeeze guest couldn't see/access the net on boot. No problem, I thought, I'll fix it later on. Unfortunately, though, it turned out that although virt-manager claimed to provide a network card, dnsmasq and stuff was running, the squeeze guest wasn't able to see the outside world -- which is, of course, quite problematic when the guest requires network access to complete installation. The guest was provided a network interface, but it wouldn't recive an IP via DHCP and even setting routes manually didn't allow to access the net.

So I thought, maybe updating the host to squeeze might help -- as the host has a real small and lean installation, this was neither problematic nor taking much time. This time, with the new KVM and virt-manager packages in squeeze, again I had no net on installation, but I had success with regard to the network access afterwards, so I could happily install a complete squeeze system in the guest. Update:What I forgot to mention was that I fiddled around with the available virtual networks with virt-manager, adding a new network. As I recognized that the guest was using the provided default network, I deleted the additional one and re-enabled auto-start on the default one. This, however, doesn't really work: whenever I startup virtmanager, I have to manually restart the virtual net, now (no, virsh net-auto-start didn't help) and worse, I have to first manually add an iptables rule (that then gets deleted on start up of the virtual net) and restart dnsmasq. Sigh

Afterwards, I turned to re-install my private data in the guest which I had previously copied to an external USB drive. This turned out to be a bad idea. First of all, you can't easily assign new hardware to a running virtual machine -- you have to startover the guest. But second, and much more problematic, was IO time. Looking at iotop, I saw an average data transfer of 500k/sec with reads from the USB disk, which means copying a single gigabyte would nearly take forever. Compared to copying the same data from the same disk on the host, iotop showed an average of 31M/sec! I haven't as of yet tried to verified that the problem is accessing the USB or if a similar problem exists with accessing "local" disks (i.e. reading/writing to the virtio disk/image is equally slow). If it's only USB access, the problem is a lot smaller in everyday usage, but still this experience was a real disappointment. Update:In the meantime I've verified that the problem is reading from the USB disc. Reading and writing to the guest virtio filesystem is, of course, slower than IO on the host, but it's not that huge a difference.

But that's still not the end of the story. Given that I really wanted to more or less live inside my guests, I also wanted to use multimedia stuff there. That this idea might turn out to have restrictions with regard to video performance was clear to me from the beginning. However, I didn't expect that I might have trouble to have audio. It looks like the problem is best summarized in this ubuntu bug report on virt-manager and vnc: while qemu/KVM of course can hand over audio to the host, this fails when using virt-manager with VNC because the vnc viewer virt-manager is using doesn't handle audio. There are ways around this, for instance Russel Crockers advise to use Xephyr, but this a) takes even more time to setup and b) takes away the bit of comfort of using virt-manager.

So, in summary, using KVM as provided by Debian Lenny and or Squeeze turned out to be quite a disappointment. I would go so far and claim that it's not really recommandable unless you're willing to invest a substantial amount of time. I've had my fair share of trouble with VMware, too, but getting things up and running was never so troublesome as this.

ObTitle: Gorillaz, "Demon Days"

On password safety

nospam@example.com (Holger Schauer) — Fri, 23 Jul 2010 14:31:50 +0200

I'm using computers for quite a while and since fifteen or more years I've been using multi-user systems and the internet. Having a computer science and linguistics background, security of passwords is not exactly a new issue for me. Quite to the contrary, I've been telling a lot of my friends that using good passwords is important.

However, this week I've stumbled about some interesting pieces that shed new light on the topic for me. The first is a not exactly new article by Bruce Schneier about how secure passwords keep you safer, which contained quite some information that was new to me. It's a very interesting piece on possible approaches to break passwords as of three years ago. Now combine that with a more recent piece on using cloud computing to crack passwords and you might get an idea how important using really good passwords might have become today. The second piece that hit the same spot for me, takes known approaches to come up with a new method to let users pick their passwords -- that is, which ever password they want, unless it is too popular.

This brings me back to my current usage of passwords. Until now, I've seen my passwords as reasonably hard to break. They contain all the usual stuff, a mix of upper and lower case letters, numbers and some symbols. However, reading Schneiers article made it clear to me that not all my passwords may really be as secure as I thought they would be, so it's time to overhaul these.

In addition, I've been using some passwords for more than one site (though not for critical/important ones), to ease the mental cost of having to remember particular passwords for some sites. On the other hand, some time ago, I already started using a password manager to store my passwords, synchronizing the db over several installations. So, the cost for using unique passwords is lower as it used to be, so I'm going to correct that error, too.

What this amounts to at the end of the day, though, is a really old lesson: security is a permanent issue not a one-time shot. What once might have been enough security measure might be totally insufficient soon.

Firefox plugins

nospam@example.com (Holger Schauer) — Fri, 09 Jul 2010 11:16:18 +0200

Kristian hat eine interessante Liste von Firefox Plugins. Meine weicht an einigen Stellen ab, insbesondere habe ich eben auch das ein oder andere Webentwickler-Plugin mit drin.

Continue reading "Firefox plugins"

Men in love

nospam@example.com (Holger Schauer) — Wed, 27 Jan 2010 11:23:16 +0100

When I got a Handspring Visor (a Palm Pilot offspring) roughly ten years ago, I was amazed about all the nice things you could do with the device. I even wrote a German version of the visor linux howto, although I never really finished it. What I especially liked was the possibility to install a ssh client and use it to connect on the push of a button to my workstation -- which I took to good use several imes when my Xserver went beserk. Unfortunately, over time the major incentive to use the thing, syncing calender and address book vanished, as it turned out to be a major hassle when the main calendar to sync with was Lotus Domino. So, since some years my trusty Visor has only gathered dust. But even back in 2000, it was clear to me that the Palm Pilot would only be the starting point and that at some time in the then-unknown future, we would have small devices that would allow issuing phone calls, taking pictures, listening to music as well as providing the "usual" features of handhelds.

Back then, I didn't really think about when exactly that device would arrive but I think the time has come finally. Some days ago I bought a Nokia N900, which is a mobile device running Maemo on top of a Linux kernel on an ARM platform (see this overview of the hardware for more details). This is really a neat little gadget which is really as close to my ten year old dream as you can get: It comes with mobile phone capabilitiy, UMTS and wlan connection, 5MP camera, media player, RSS feed reader, etc. and also has a quite usable sliding keyboard. It's not really a mobile phone but a pocket computer which you can also use to call people with, which shows for instance in that most applications require the device to held in landscape position.

Of course, what's most interesting to me is the software on the device. Basically, Maemo 5 is a linux distribution based on Debian technology, e.g. apt/dpkg and friends work as expected. You don't get all of your favourite linux applications of course, but still there are quite a lot of the regular stuff you would expect. This includes the mobile version of Firefox, Fennec, vim, OpenSSH (client and server) and even Emacs. Being the geek that I am, nearly the first thing I did was a remote login via ssh from my workstation on the N900 (also see this overview of USB networking on the N900). Native maemo applications are typically developed with Python and GTK, although that is probably going to change for Maemo 6 (Nokia has announced it favours Qt over GTK). The community seems quite active, too: just shortly, a port of Clisp (a Common Lisp compiling to byte code) was announced (including a running Swank backend, so you can connect from your development Emacs remotely), although I imagine that the development environment for Python is, generally speaking, more advanced (for Maemo development, this is). I haven't looked any closer into developing for Maemo up to now, but it surely looks interesting.

ObTitle: Gossip, "Music for men"