After almost a year of working on and off on the package, glest is now in the new queue.

Glest is really a free 3D real time strategy game with amazing graphics and really interesting game play.

So maybe you're wondering why did it took me so long to package it. Well, glest is mainly developed on a Windows platform and GNU/Linux is the platform it was later ported to. So this came with some problems:

• the game uses jam as a build system; don't get me started on the intelligence of this build system; I had to go through real pain to make it build
  
• the game is entirely written with "little endian" assumtion in mind
• apparently the editor is not functional on Linux yet, but there is a patch (I will enable this later, after some testing)
• the build system was not bootstrapped before building the tarball
• the linux build creates some symlinks and I had to do some really nasty tricks so that there are no unrepresentable changes in the source
• the upstream is currently not that active, but it used to be a lot less last year; it seesm that there is a motivation/time issue with the leader of the project
  
• upstream moved the project to sourceforge and they keep the code now in subversion, but I wasn't aware about this until recently
• there are a few people talking about forks and a real fork which proclaims itself ast the real project continuation; I suspect that all this mess appeared due to inactivity of upstream last year
• the game used a non-free font
  

Since when I started the packaging work I was using a PowerBook G4 as my main machine I was upset that the game was little endian only, so I started working on a patch. I made an incomplete patch but I got stuck at some point. Time passed by and I replaced my laptop and I wasn't able to continue working on the patch. So I kind of forgot about it. Before debconf I decided is time to do the upload for little endian machines, add the endianess patch disabled.

During debconf I asked Tolimar to make an upload, and it turns out that for some reason I still don't know, the build resulted in a statically linked binary. I was amazed since I didn't recall doing any changes that might have triggered this. At some point I suspected that the build system is broken on other arches than i386 (my main machine is amd64) and halted. This until a few days ago Joey Hess added a comment in the ITP bug pointing out that the game is ok. After a couple of emails I realized that the static issue was just some strange temporary issue on my machine and now the package is in NEW.

So, that's my excuse. I hope that upstream glest issue get fixed. If not, I'll probably package glevolution, too.

I’ve found two major uses for my N800:

• Web browsing while watching TV. Seriously. Being able to check up on questionable facts or look up that actor you half recognized on the IMDB without moving or having something large enough to be noticeable sitting there really does make a difference. Less often it’s price checks in shops.
• Sometimes a laptop is just too big to carry around. There are a lot of times when I’m going out for the day and carrying a laptop would mean having to carry a bag of some kind. The N800 I can just shove in my pocket - much nicer if I’m going to be spending all day on my feet.

Really, they’re both just variations on the theme of “It’s tiny but has a screen big enough to render most web pages sensibly and do other internet access too” but it did surprise me just how useful this turned out to be once I started using the N770. This reminds me, I meant to have a look at the Pentabarf code and see if I could make it play sensibly with devices like the Nokias. I’d have loved that during Debconf, especially when I was running around making sure speakers showed up.

UK military spokesman Major Mike Shearer said: "We can categorically state that we have not released man-eating badgers into the area."

Source: BBC

As you probably already heard, the GPL, version 3 has been released, together with the LGPL, version 3. I haven't yet read the licenses in detail, so I cannot say much about them, but more information is available in the (updated) GPL FAQ. The compatibility table from the GPLv3 Discussion Draft FAQ can be pretty helpful, too. There's a Why Upgrade to GPLv3? text and even a video of Richard Stallman (Ogg Theora, transcript available) introducing the GPLv3, the rationale behind it and some of the changes in this new version. (One nice advantage of the GPLv3 I like is that it's compatible with the Apache license now, btw.) Probably the most interesting GPLv3 resource at the moment is Palamida's list of projects which already switched to the GPLv3, which includes a number of GNU tools (sed, tar, ed, bison, texinfo, cpio, coreutils) and some other major projects such as Samba. Currently the page lists ca. 140 projects which switched. It'll be interesting to see how the adoption proceeeds. My guess is that in a few months it'll be hard to build distributions or embedded (GNU/Linux-based) hardware devices without GPLv3 code...

Status Page for OCaml Transitions Today my spare time (not necessarily driven by me) produced the OCaml package status page. Even if a lot of improvements have already been requested by other fellow caml-ers (i.e. more work to do), I'm kinda happy about the result ... I've even enjoyed using Genshi more than in the past. Unfortunately the page reminds me that there's still a lot TODO before starting to upload OCaml 3.10.0 packages to unstable. Damned status pages!

Stefano Zacchiroli blogs his thoughts about collaborative maintenance. He identifies two arguments/religions about it:

1. it is good because duties are shared among co-maintainers
2. it is bad because no one feels responsible for the co-maintained packages

And he says he stand for the first one. I’m not sure that those two positions really contradict. Sure, collaborative maintenance is a good thing, because it allows to share the load between co-maintainers, which often results in bugs being fixed faster. But collaborative maintenance creates the problem of the dilution of responsabilities, and the dilution of knowledge. In many cases, a single maintainer will have a better knowledge of a package than the sum of the knowledge of all co-maintainers. Also, sometimes, teams don’t work very well, and everybody start thinking that a specific bug is another co-maintainer’s problem. In the pkg-ruby-extras team, we have been trying different organizations over the past two years. We have now settled with the following:

• each package has a “main responsible person”, listed in the Maintainer field
• the team address is listed in the Uploaders field, as well as all the team members that are willing to help with that package (people add themselves to Uploaders manually. Another variant is pkg-kde and pkg-gnome’s automatic generation of the Uploaders field based on the last X entries of debian/changelog (pkg-kde variant, pkg-gnome variant).)
  Interestingly, we discovered that for several packages, nobody was really willing to help, so I’m wondering how other teams with (nb of packages) >> (nb of active team members) work.

Stefano also raises the point of infrastructure issues caused by the switch to the team model. I ran into one recently. My “Automated mails to maintainers of packages with serious problems” are currently only sent to the maintainers of the packages with problems, unless someone has problems in both maintained and co-maintained packages (in that case, all problems are mentioned). I thought for a while about sending mails to co-maintainers as well, but that would mean sending more mails… I might try that and see if I get flamed :-)

Sometimes, putting up an arbitrary limit for your network connection can actually improve the performance.A typical setup will look like this: your computer is connected via 54-100 mBit to a router, which has a DSL line of let's say 2 mBit downstream and 192 kBit upstream (and then tons of other links).When you overload one of these connections, performance can go down a lot.The simples case how this can happen is when you upload data. 192 kBit are the weakest link here, and rather easy to fill up.What happens then is that your computer will start sending out data at his full link speed, until the buffers at the router are full and it starts dropping packets. TCP/IP will then adopt and - lacking 'ACK' packets - slow down sending data. It will likely still keep the send-buffer of the router full.Now if the router isn't very smart, it just keeps a first-in-first-out buffer. As long as you have just this single upload, you don't need to care. But if you have other connections, like a download, you do care.For your download to run at full speed, the sender needs to get those ACK packets from you. They're basically a "got your data, send more" kind of message. Really tiny packets, but essential for signaling.A simple trick you can use now is to limit your bandwith at the sending computer already. Since you're going to limit it just to the next link anyway it doesn't mean it will actually be getting much slower. But your network stack is smarter than the router's (probably). It can send out these ACK packets at a higher priority, so you end up with a better download-and-upload performance.If you know your network connection speed, just use it. Otherwise you can still measure it or guess it. I'm always going for 95% of the speed I see. You might want to limit it a bit more if you are sharing the connection with others.Now enough theory, here's what I use:

IFACE=wifi0
# setup ingress filtering
/sbin/tc qdisc add dev $IFACE handle ffff: ingress
# local network is unrestricted
/sbin/tc filter add dev $IFACE parent ffff: protocol ip \
  prio 10 u32 match ip src 192.168.2.0/24 \
  police conform-exceed ok/ok flowid :1
# incoming internet traffic is limited.
/sbin/tc filter add dev $IFACE parent ffff: protocol ip \
  prio 50 u32 match ip src 0.0.0.0/0 police \
  rate 1500kbit  burst 10k drop flowid :2
# outgoing traffic
/sbin/tc qdisc add dev $IFACE root handle 1: htb default 30
# local network is unrestricted
/sbin/tc class add dev $IFACE parent 1: classid 1:10 htb \
  rate 54mbit burst 15k
/sbin/tc qdisc add dev $IFACE parent 1:10 handle 10: sfq perturb 10
/sbin/tc filter add dev $IFACE parent 1:0 protocol ip \
  prio 10 u32 match ip dst 192.168.2.0/24 flowid 1:10
# internet traffic is limited.
/sbin/tc class add dev $IFACE parent 1: classid 1:20 htb \
  rate 160kbit ceil 196kbit burst 15k
/sbin/tc qdisc add dev $IFACE parent 1:20 handle 20: sfq perturb 10
/sbin/tc filter add dev $IFACE parent 1:0 protocol ip \
  prio 50 u32 match ip src 0.0.0.0/0 flowid 1:20

Long example, I know. The main reason is that I'm not limiting traffic to local computers. Furthermore, I'm also limiting my incoming traffic to use up at most 1.5 mbit of the 2 mbit connection, so my housemates will be able to use the internet as well (Debian mirrors send data fast - fast enough to kick them out of any online game they might be playing...).There is one important detail hidden in there: sfq. This stands for "stochastic fair queueing". It tells the network stack to basically send "one packet for each connection in turn". This way, the small packets needed for download or interactive SSH sessions will get out quickly even when doing a larger upload.It works great for me - I'm having a good download rate, using the 160 kBit upload limit completely (I don't want to completely fill up the 192k upload link either) and I'm actually writing this blog entry remotely via SSH. The lag when writing is okay, probably around 300ms. Without shaping, this wouldn't work this well.(And no: just using 'sfq' for your outgoing traffic is not enough, since the key scheduling is happening at the weakest link. So you have to limit your traffic shaping setup to be just below the actual weakest link.)

At the risk of seeming a self-aggrandizing, I wanted to point folks to a nice biographical profile that Linux.com is running about me upon my election my to the FSF board. I'm pretty honored, and excited, by the whole thing. The article talks a little bit about my road to free software and the FSF board in particular and about some of my ideas about the foundation and its work. There are three little footnotes I thought I would add to what I think is a great article:

• The phrase "rebel with rather too many causes" was a phrase originally directed at protest.net -- a event calendaring system for activists that I was briefly involved in over a summer during college. I like the phrase and use it frequently but I didn't want to take credit for it. Google indicates that it originates in NTK #53 I'm not at all surprised.

• My parents worked as doctors in Kenya, Papa New Guinea, and elsewhere before they had children. This probably doesn't matter to anyone else but they worked with an organization that was like MSF in that it was a humanitarian organization that sent physicians around the world but it was not actually MSF as the article states. I don't think MSF had grown beyond French doctors when my parents were practicing overseas.

• When LWN pointed to the article, and in the original was well, there a focus on some comments I make about non-profit organizations. Since in a context of talk about my political work I just want to clarify my comments in a little more depth here. I think that one problem that has stemmed form Open Source's emphasis on businesses and efficiency is that free/open source software people end up making arguments in business terms: you should use application X because it is more efficient and faster. For many of the folks who have built this whole movement though, and for most in the free software camp, it's about freedom, not efficiency. By targeting businesses, we encounter a skeptical audience. More importantly though, we end up making arguments that, while true, are not the ones that motivate us. I think that low-hanging fruit for free software activists might include groups that already support free software ideas of sharing and user empowerment and that are looking for ways to use free software already. Groups we don't need to be afraid about saying "freedom" around. Not so coincidentally, these are sometimes organizations that I have a lot in common with politically. But that's far from always the case. There's a big group of philosophically aligned organizations in the NGO/non-profit community and the problems keeping them away are often technical. This is good news, of course, since solving technical problems is the free software movement's core competency. This is something I've been thinking about for a long time: Debian-NP was one project I helped start that tried to address this issue. Now, many people involved in the FSF, including myself, have political convictions that go beyond software. I do not want these convictions, and my statements about philosophically aligned organization, to be interpreted as call for a political shift in the organization in mainstream political terms. I deeply respect the way that RMS has kept his political opinions separate from the Foundation's. Biella and I have ever written about the importance of this political demarcation to free software's success. It's certainly not something I would want to change.

More Uploaders, Less Maintainers: Infrastructure Issues When yet another discussion about "is collaborative maintenance good or not?" starts on debian- lists, the average lurker can easily identify two arguments / religions:

1. it is good because duties are shared among co-maintainers
2. it is bad because no one feels responsible for the co-maintained packages

Of the two religions, I stand for the first one. More generally I share the long term aim of decreasing as much as possible the "ownership" of Debian packages; collaborative maintenance is just a tool to achieve the goal. In the meantime, I believe the second religion is supported also by technical deficiencies in some pieces of our infrastructure. In particular some of our developer tools artificially enforce a distinction among Maintainers and Uploaders where it wouldn't be necessarily needed. In the last few days I thought about some of them:

• the BTS by-maintainer reporting mechanism. Years ago, I used to use the BTS as my personal Debian-related TODO list. When I had some time to kill, I just had to point my browser to http://bugs.debian.org/zack@debian.org and a lot of work I had to perform showed up. Today this is no longer the case: most packages of mine are co-maintained and only those with me as a Maintainer show up. Then I have to look for bugs belonging to debian-ocaml-maint@lists.d.o, pkg-vim-maintainers@lists.a.d.o, ... It's tiresome I'll never do that. Hence a request in #430986, shared by other: #225757, #310720.
• dd-list is frequently used to report work needed by maintainers on -devel posts. Since long time it supports a '-u' flag for listing also maintainers, but it's used very seldom, probably just because people do not know about it. It's just a matter of changing a default and developers will find more easily their names in such lists.

Think about such deficiencies, I'm pretty sure we can spot and fix easily a lot of them in our tools. Update: Lucas: I agree that the two arguments do not necessarily contradict, that's why I (initially) called them arguments. Then I moved to "religions", it was an oversimplification: there are of course pros and cons of collab maint. My main argument holds nevertheless: several perceived cons of collab maint are due to artificial distinctions maintainer/uploader in our tools, thanks for providing yet another example ... I want more!

An issue that causes some discussion and debate is the number and type of questions that may be asked during a lecture. In a previous post giving advice for speakers I suggested that questions can be used as a mechanism for getting a talk back on track if a nervous speaker starts presenting the material too quickly (a common mistake). This mechanism can be used by the speaker if they realise that things aren’t going to plan or by audience members who are experienced speakers and who recognise a problem. Due to this a blanket ban on questions during a talk will only work with experienced speakers who have planned their talk well. There are different styles of presentation favoured by different speakers. Some are determined by the nature of the topic (an example that I have seen cited is topics that are very contentious which would lead to a debate if questions were permitted during the talk), but for computer science I think that questions during the talk can always work well. To a certain extent the fact that code either works or doesn’t limits the scope for debate. Probably the major factor that determines the utility of questions is the size of the audience. If you have an audience of less than 50 people then a conversational approach can work, if you have less than 200 people then a reasonable number of questions can be accepted. But as the audience size increases above 300 the utility of questions approaches zero. If the majority of people who might want to ask questions are unable to do so due to lack of time then the value of allowing any questions diminishes. For the largest audiences there probably isn’t any point in having question time. Another major factor determining which style works best is where the speaker has had experience speaking. Most of my speaking experience is with less formal meetings (such as local LUGs) and in countries with an informal attitude towards such things (Australia, the US, and The Netherlands). A speaker who has primarily spoken for universities such as Cambridge or Oxford (which seem to have a very formal style and questions strictly reserved for the end) or who has come from a country such as Japan(*) where it’s reported that the audience are obliged to show respect for the speaker by being quiet will probably expect questions only at the end and may flatly reject questions during the talk. A speaker who has a background speaking for less formal audiences will expect a certain number of questions during the course of the talk and may plan the timing of their talk with this in mind. When I plan a talk for a one hour slot I plan at most 30 minutes of scheduled talking (IE covering my notes) expecting that there will be 15 minutes of questions along the way and another 15 minutes of questions at the end. Often with such plans my talks run over-time. Of course this means that people who have mostly had experience speaking to smaller and less formal audiences will find it exceedingly difficult to give talks to larger audiences. This may be an incentive for having more formal arrangements for LUG talks to increase the skills of speakers. The next issue is what level of contentious questions is acceptable. I believe that if you have a disagreement with points that the speaker is making (and have some experience in the field in question) and the audience is not particularly large then one hostile question is acceptable - as a speaker it’s reasonable to refuse to take any further questions from an audience member who has asked one hostile question. Another category of question is the challenging question (not to be confused with a hostile question), for example describing in one sentence what your business requirements are and asking how the topic being discussed will apply to that business requirement. One of the most useful questions I have been asked during a SE Linux talk was concerning the issue of backups of file security contexts, it was presented in a challenging way and the answer that I gave was not nearly as good as I could give now (the code base has improved over the last few years in this regard) - but I think that everyone learned something so that validated the question. In smaller groups there may be some heckling when the speaker is a well known member of the group, I don’t think that this is a problem either as long as it only consumes a tiny fraction of the time (maybe 20-30 seconds at the start). For larger audiences or for speakers who don’t know the audience well heckling is generally a bad idea. (*) When speaking in Japan I had a lot of audience interaction. I’m not sure if this is an indication of the Japanese culture changing in this regard, the fact that translation problems forced some interaction, or the audience was showing respect for the Australian culture by asking questions.

Share This

Well, I've hinted at it and told enough friends, I should get around to posting it: As of the end of this month, I'll be moving on from Canonical. By my calculations, I was something around employee #30, the first support tech, and I've had a great chance to build the support organisation up to where Linux Format magazine rated us as tied with RedHat ahead of Novell in this August's issue.

So what's up?

Well, those of you following along might remember a cute little bundle of joy entering my life. A couple of months in, I've realised that I can't stay on top of being with him and growing a 7x24 operation at this critical time in Canonical's growth. I'll be taking the month of August to be with Angie and Leif, and in September will start a new job with Google in the Open Source Program Office. I don't know the details of what I'll be doing there (The Google Omert , as one friend called it... *g*), but Google as a company is well aware of what happens with brand-new parents and the mad readjustment of priorities.

Angie and I are currently selling our place in Montr al in prep for moving to San Francisco at the end of August. I want to make sure I see people before we go, and if you're interested in buying the place, give us a call. =) Also, if you're in the Bay Area, a vegan, a parent, into Yoga/fitness, speaking French, etc., we'd love to meet you for tea sometime!

I'm pleased to announce that Tasks 0.10 is now available from the Pimlico Project. There are a few fixes here, but the big news is an initial port to Maemo (thanks to Rob Bradford for the bulk of this work).

• Basic Maemo port (currently for the N800 only, but should build for the 770)
• Internal refactoring of the grouping architecture
• Don't allow tabbing in the Notes field (#381)
• Make the Notes tab label bold if there is a note

The Maemo port of Tasks is a prime place for anyone who wants to learn about programming Maemo. The Maemo-specific code is currently 595 lines long (a chunk of which need to be factored out), so filling in the missing pieces (such as starting a web browser) is easy. If anyone wants to get their hands dirty, mail me. NP: Burial, Burial

It turns out that if you want to use includes in your .spec file and want the files to be included in the .src.rpm you have to declare those scripts as supplemental sources.

So instead of:
Name: foo
Version: x.y
Release: z
Summary: foo package
Group: Applications/System
Source: foo.tar.gz
Packager: Eddy Petrisor
BuildArch: noarch
BuildRoot: $RPM_BUILD_ROOT
....


You have to have:

Name: foo
Version: x.y
Release: z
Summary: foo package
Group: Applications/System
Source: foo.tar.gz
Source101: foo.pre.sh
Source102: foo.post.sh
Source103: foo.preun.sh
Source104: foo.postun.sh
Source105: foo.changelog
Packager: Eddy Petrisor
BuildArch: noarch
BuildRoot: $RPM_BUILD_ROOT
....

In case you want to have the scripts separated in different files and you use them all.

Note: the number in the "SourceXXX" is arbitrary but must be unique.

But mentioning the files as being Source... means you have to write:


%post
%include ../SOURCES/foo.post.sh

%preun
%include ../SOURCES/foo.preun.sh

%postun
%include ../SOURCES/foo.postun.sh


Instead of:


%post
%include foo.post.sh

%preun
%include foo.preun.sh

%postun
%include foo.postun.sh


Which should have been more reasonable...

RPM, please die... or grow some 21st century features... or some sense!!!


Update: Thanks to a few people, I was pointed out I am still not thinking in terms or RPM.
The proper way of writing the include without them looking odd is something like:

%post
%include % SOURCE102

Hi, as everybody else, I'm blogging about the status of my GSoC project, which now has a name: Pancut n. Pancut n is a lintian-like tool to check ISO images generated by debian-cd and friends. It aims to support CDDs, and even Debian-Live CDs. In case you're wondering, the name is a stupid pun about avoiding (skin) burns and unusable debian CDs (Pancut n is a vintage lotion for burns in Argentina, and I think most joungsters won't even recognise the name). In any case, it sounds good :-). Since it has a name, also it has a alioth project page, SVN repository and mailing list. If you want to try it out, just checkout the repository and run:
$ ./pancutan <list of iso files> If you set the environment variable DEBUG to a number greater than zero, you get debugging info. Its dependencies are currently libyaml-perl (or libyaml-syck-perl for faster operation), fuseiso9660 and an user which fuse permissions. Of course, as I've been working in the architecture, there aren't many tests. But you can try the powerpc business card ISO for which pancutan currently detects that it's too big for a business card cd:

$ ./pancutan /media/IOMega/mirror/isos/debian-40r0-powerpc-businesscard.iso
E: image-too-big
 - The ISO file is too big for the target media
 + 73207808

About the architecture. The general idea is that a directory is scanned for modules, "requires" them, and extracts metadata embedded into them (I'm still thinking that this can be separated to delay compiling of modules when they're needed, but I haven't decided it yet). From that metadata, tasks and tags (errors and warnings) definitions are loaded. Also a lot of internal sanity checking is performed. There isn't any fixed order of execution, it's constructed based on the dependencies the tasks define. And it has been thought from the start with parallelisation in mind, although that functionality hasn't been written yet (I'll do it during this week). I have written a draft spec for the plug-ins in the wiki. I have to properly document that, but you can get an idea from it. At this point, I'd like to other, more experienced people take a look at it. So feedback is very welcomed, specially from the people that will use the tool!

One of my examples to explain "the tragedy of targets" used to be councils meeting recycling collection targets by collecting the recyclable waste, then putting it in landfill because that was cheaper than actually recycling it. That's bad because it makes a lot of extra work for everyone, but only meets the collection target in fact, not in spirit. I stopped using that example because I thought it was too incredible and I didn't have a good reference to support it. So imagine my surprise to see a report in the Weston Mercury saying:

"If Veolia does not have enough manpower it will send out a green waste lorry, or a domestic refuse lorry which usually picks up black bag rubbish, to pick up both at the same time. [...] The staff will just take it for granted that green waste is in the green lorries and domestic waste is in the blue lorries."

This is bad on many levels, even worse than my old example where recycling-ready waste was knowingly tipped into landfill. There's green waste contamination and false collection statistics, for starters. The article continues to report that Cllr Carl Francis-Pester, North Somerset Council's executive member for environment, said:

"We are carrying out an immediate investigation into these allegations which we take very seriously indeed. This investigation will include urgent discussions with the contractor to ensure they are fulfilling the contract we have with them in the correct manner."

There doesn't seem to be any information about this investigation on North Somerset Council's web site. And if Veolia have spotted a loop-hole in the contract, then what? Even if they haven't, the council has to watch solely-profit-led contractors like hawks because if you give them a chance to cut costs (and therefore increase profits), they will try it. That is the hidden cost of outsourcing, not covered by the Best Value Indicators and other privatised council jargon. Incredibly, the councillor continues with:

"Thanks to the residents of North Somerset we have increased our recycling rate from 20.5 per cent to 30.8 per cent in the last 12 months."

If the allegations are true, then no, we haven't, because the statistics would be as full of toxic rubbish as the green waste lorries. Have private rubbish collectors been doing this elsewhere?

I'm disappointed to see that the Co-operative Bank was one of those chastised by the Information Commissioner for "dumping customers' personal information in bins outside their premises." At least it wasn't the Co-operative Bank I was calling stupid recently and its online banking works with GNU. I keep getting asked by banks (including the Co-op) and utilities to switch to e-mail billing, but they seem clueless about e-mail security and none of them have offered me encrypted e-mail yet (OpenPGP or S/MIME). E-mail without encryption is like post without envelopes - anyone along the route can read it without asking. This leaves customers at risk of identity theft and worse, even more so than dumping details into bins. When will the information commissioner tell companies to stop exposing customer details by e-mail billing and start using encryption? Would these companies be allowed to post bills without envelopes?

During the recent weeks, we started to hunt and hint large batches of packages together to testing (and this blog is just to show a bit of what is part of the tasks of release team members). This started with a large jasper hint, continued with a very large poppler / texlive / jack / abiword-hint (which moved about 75% of the packages that were ready for testing migration in at the same time), then moved a more recent linux-2.6 version in, and now finally ghc6 / haskell. However, now we reached a point where a few more release teamisch hints don't help anymore: The next large blocker is gcj-4.1 / gccdefaults / ecj. This is now blocked by different bugs on different architecture:

• mips* needs to have xulrunner built first to build gcj-4.1. This is discussed in bug #428582, and the porters are busy working on it.
• hppa fails for unknown reasons - probably it needs some porting. That should be discussed in bug #431865 but until now there was no answer from the hppa porters.
• arm already reached the state of being out-of-date to a degree that it needs bootstraping by hand - see http://lists.debian.org/debian-arm/2007/07/msg00014.html for reference.

Update: Aurelien Jarno informed me that gcj-4.1 had to be bootstrapped on all architectures, but it hasn't happened yet on arm due to bugs in gcj.

We finished watching Wal-Mart: The High Cost of Low Price last night, and, well, this user comment pretty much summed it up. It was a fairly poorly presented, heavily one-sided piece of "documentary" work. A lot of their claims we're really backed up with anything. I've no doubt that Wal-Mart is an evil mega-corporation, and we didn't really shop there much before, and we'll certainly never shop there again, but I would have preferred to have a seen a more balanced, better presented piece than what this had to offer. There were a lot of "Mom and Pop" businesses going "wah wah, Wal-Mart stole my lunch", and frankly, that's capitalism for you, sorry. I can appreciate that the "Mom and Pop" businesses may have provided better conditions for their employees, but that didn't seem to be the focus of those stories, just that various governments provided subsidies for Wal-Mart to come in, and all of the local small businesses had to shut up shop as a result. At no point was there any discussion about sales-tax benefits to the cities that provided incentives for Wal-Mart to move in. So yeah, the movie was an eye opener, even when taken with a large salt-shaker, but it could have been done a lot better. The user comments on IMDb are quite interesting in and of themselves.

I got a SIO2PC cable for my atari, hooked it up to a linux box, and used the atarisio tools to rip a few of my old BASIC disks. Now I can load them in the atari800 emulator, and will hopefully never lose this early code -- cuz it's in subversion now. The first disk I rescued ("finished programs disk 1") has a nice little menu on it with lots of games and stuff I'd put together. I've always been proud of the "vidio" game, which is the first game shown above. It'd give Pong a run for its money in simplicity, and has gameplay I still enjoy (for up to 5 minutes at a time). You're the green dot, which is flying from left to right. Each time it reaches the right side of the screen, it wraps back to the left -- but leaves a blue wall behind. Crash into the wall and you lose a life. Sometimes other dots appear that you can pick up to get new lives. This sounds easy, but it's not, mostly because the Atari joystick (or my code for reading it) is not very precise, so it's hard to line up to exactly the right place on the screen to go through a small hole in the wall. In contrast to that piece on innovation, the "jump" game is a pretty generic platformer, jump over the water and shoot the enemy that's crawling along the ceiling. It's also a bit buggy. I took a look at the code, but the bug on line 200 isn't very obvious, whatever it is. This is how everyone's old code looks to them after 20 years ... right?

---

Update: Some more games I found.. My version of Tetris for the Atari. It looks a lot better on a real TV tube. Two fun things in writing this were that I couldn't figure out how to program it to rotate the blocks on the fly -- so I just wrote out data with every possible rotation for every block. Also, Atari BASIC lacks arrays, so it uses strings for storing the game state.
(Colors are ok in 1st screenshot, but messed up in second.) Fatso's adventure had the best graphics I did on the Atari. It remapped parts of the the character set and used ATASCII characters as sprites. Ok, it's kind of a Lode Runner clone, but only the kind you write after having seen Lode Runner for 2 minutes. Looks kinda like it, but I don't think Lode Runner had spiders that dropped exploding eggs that broke all the rungs in the ladders..

---

Update 2: Disk images are nice, but regular files are nicer. I was able to explode files out of the disk images only with difficulty. I ended up using wine to run a windows program called Total Commander. It has a plugin that allows .atr disk images to be unpacked. To view the BASIC files, they have to be detokenized. I found a perl script to do that, that can be used on the fly of anything suspected of being a BASIC program. All the stuff is in my subversion repository.