(or: finally, a use for ActiveRecord#save!) I recently found Rescue To The Rescue!, a short article on structuring your Rails controllers differently. Today, I started using it in some code I was writing that I think really benefitted from the change. The code was a big case that did things like this:

 case some_variable
   when 'X'
     process-based-on-X
     if save
       post-processing
     else
       throw_an_error
     end
   when 'Y'
     process-based-on-Y
     if save
       some-other-post-processing
     else
       throw_an_error
     end
   when 'Z'
     process-based-on-Z
     if !save
       throw_an_error
     end
 end

In each case, the pre-save processing was unique, and -- more importantly -- the action to take after a successful save was different, so I couldn't just save-and-handle after the case statement. However, the throw_an_error code was the same in each case, so I just changed the code to do this:

 begin
   case some_variable
     when 'X'
       process-based-on-X
       save!
       post-processing
     when 'Y'
       process-based-on-Y
       save!
       some-other-post-processing
     when 'Z'
       process-based-on-Z
       save!
   end
 rescue ActiveRecord::InvalidRecord
   throw_an_error
 end

My mind was blown. Soooo much clearer now. I have an "everything's OK" code path, and a "bugger me, something broke" path, cleanly separated. But something didn't feel quite right... And now I know what it is. I'm bothered by the fact that I'm sailing very close to using exceptions as an ordinary, every day flow control mechanism. I think I've convinced myself that, in this case, it's OK, but I'm a little concerned that I might go power-hungry and start using it in places that it really isn't warranted. I guess I'll just have to keep an eye on myself. Just remember, everyone: save! isn't a dirty word!

I've gradually become happier and happier with Ruby on Rails. I've got mostly past the constant "WTF?WTF?WTF?" phase that's so frustrating when you try to understand the magic behind the scenes (after all, I like understanding what happens inside a framework - the bang and the bling are not what lured me into Rails).
So I've tried to become a more idiomatic, more complete. In the last project I started, I decided to -gasp- stop declaring my schema structure in SQL, and use migrations instead. All fine until I reached migration 008... The first one including a table modification (adding a admin column for users) instead of a creation. Well, that one went pretty fine, but 009 was also a table modification (adding an order column for tsgs). And I updated my server - with both migrations at the same time.
Bad news: Tsg has_many :users, and every User validates_associated :tsg as it should. And as migration 8 modifies (and saves, of course) a User, this validation was triggered... So, migration 8 died complaining about an undefined method order' for #<Tsg:0x2b2d2dd8d0d0>. WTF?WTF?WTF? all over again. It took me quite a while to realize.
What's the moral of the story? That a sleepy programmer can and will mess up. That batching up several migrations does not guarantee success, because the model is already up to the newest version. Crap. :-/
Or maybe it will just be safer if I abstain from directly instantiating models in migrations? umh... Does not feel right :-/

For some time I have ignored my blog so I did not notice that when my co-admin upgraded our system from etch to lenny, it broke. When I found some time to look at it, it turned out to be because the blog was no longer running in production mode, so it pointed at the empty development database. This caused every URL to redirect to the login page, but since I didn’t have a valid user for that db, I couldn’t login. This, in turn, was due to the upgrade of mod_fcgid from the old 1.10 version in Etch to 2.1. Apparently, this used to work. Note the name of the module:

<IfModule mod_fastcgi.c>
   <Directory /var/www/vir/syn.theti.ca/typo>
    FastCgiIpcDir /tmp/fcgi_ipc/
    FastCgiServer /var/www/vir/syn.theti.ca/typo/public/dispatch.fcgi -initial-env RAILS_ENV=production -processes 15 -idle-timeo
ut 60
   </Directory>
</IfModule>

It’s strange that the section is called mod_fastcgi.c, not mod_fcgid.c. Either that was done to make it a “drop in” replacement for fastcgi, and later changed in the next release, or else this config was not actually used, but somehow my blog started in production mode before the upgrade anyway. In any case, the blog is back in production node with the new fcgid with the following module section (based on this one from the mod_fcgid home page).

<IfModule mod_fcgid.c>
   DefaultInitEnv RAILS_ENV production
   <Directory /var/www/vir/syn.theti.ca/typo>
     FCGIWrapper "/var/www/vir/syn.theti.ca/typo/public/dispatch.fcgi" .fcgi
   </Directory>
</IfModule>

Hope this is helpful to others making the upgrade.

Since some time, Deutsche Bahn rolled public wireless lan called “WLAN am Bahnhof” out at 25 railroad stations, you can choose between 4 providers. Sounds really nice, but beside the economical conditions, there is also at least one security issue.
Connecting to the network and opening your favorite browser redirects you to a encrypted portal. So far, so good … the really bad news is, that the certificate expired over 6 years ago.

This seems to be a normal behavior, since it happens often, that invalid certificates are used. This leeds to blunted users, which aren’t verifying such certificates anymore, even when it’s important.
Does anybody know a reasonable way to notify anybody who can solve the problem there beside the normal contact forms? Networking, planet, security, WLan

The Age has published a remarkably stupid article about terrorism titled “It’s hard to prevent the hard to imagine” which contains some amusing statements such as “a plan to use liquid explosives hidden in soft-drink bottles and destroy commercial jets crossing the Atlantic. The scale of this plot, combined with the innovative bomb design, threatened to kill thousands of people and cause massive disruption to global commerce“. This however has been debunked by many chemists, here is one of the many expert analysis of the claims. Here’s another inane claim from The Age “So the perpetrators in the UK looked elsewhere and compiled a crude yet potentially deadly bomb from materials available in everyday life a mix of gas cylinders, petrol and nails. Finding a way to govern access to such otherwise mundane items will be expensive, and perhaps ultimately, impossible.“. It’s surprising that The Age editorial team were unable to find someone who knows the basics of chemistry or who has ever had a need to start a fire to review the article. Everyone should know that an oxidising agent is necessary for combustion - and a huge quantity of an oxidising agent is needed for an explosion. Petrol vapour won’t ignite if it’s too concentrated (it can displace enough oxygen to prevent combustion). When a gas cylinder is damaged and set alight you get a fireball surrounding it which may be several meters wide (the one occasion that I witnessed a damaged gas cylinder on fire the fire-ball was about 4 meters wide). But no explosion. To propell nails or other solid objects you need the combustion to be rapid and only on one side of the object. Combustion on all sides (IE a 4 meter wide fire-ball) will not propell nails. Here’s what a British Army bomb-disposal operator has to say about it in The Register. If you want to talk about dangerous items that are difficult to control how about cars? A terrorist who drove a 4WD along the footpath of Oxford St could potentially kill more people than the London bombings and would take almost no preparation. The article inevitably concludes with claims about the efforts that al Qaeda operatives are supposedly making to recruit people for terrorist missions. Naturally it ignores the best recruiting method of al Qaeda - the huge civilian death toll in Iraq since the US led invasion. The best available medical research (by researchers from Johns Hopkins University and published in The Lancet - the most reputable and prestigious medical journal) estimates that there were 655,000 “excess deaths” as a result of the invasion in the period up to July 2006. Over the last year the best available reports suggest that the violence in Iraq has got worse (among other things the number of US air-strikes is twice what it was last year). For more analysis of the fear-mongering being done by much of the media (including The Age) here’s another article from The Register. It’s interesting to read The Age’s article Truth first casualty of the internet?. Maybe they should publish an article titled Intelligence first casualty of print media?.

Share This

Always when I have to deal with RPM systems I feel so handicapped and it feels so wrong from multiple PoV.

This is a rant and a dear lazyweb (not that lazy, actually) type of post.

I would like to be able to have a few things solved when dealing with RPMs:

1. I would like a pbuilder like builder for specs
• I know about mock, but
• it accepts only src.rpm files (I know about rpmbuild -bs, but is broken, read further for the groovy details)
  
• I have some specs that have %include directives for the maintainer scripts and when rpmbuild -bs is ran, guess what, the extra files are left outside the src.rpm;oh yes, the directives are processed correctly for the binary rpm
• mock relies on bootstrapping a system using fedoralegacy.org, which was recently discontinued
• I have a redhat-9 chroot tarball which I would like to use and tell mock to use that without caring about upgrades (since my packages are not at all that dependent on the build system)
• mock fails to bootstrap even for fedora-devel-i386-core with the message "Cannot find a valid baseurl for repo: extras"
• the older versions fail to bootstrap because, apparently, it "Could not find useradd in chroot, maybe the install failed?"
• plague (how's that for irony?) relies on mock, which is broken
• mach seems to be deprecated
2. I would like a simple repo creation and maintainance tool, something in the line of mini-dinstall, which should have apt4rpm and yum support, but it seems that repos are still the "new shiny thing" which has no proper tools
3. I would like to be able to know from which version I am upgrading from the current package, not only that I am upgrading (in case you didn't knew, the only way to know that you are upgrading in a post/pre install/remove script, is the wonderful $1 parameter which indicates the number of packages installed after the script finishes or something along that line..
   

So my question is, is there any way to fix any of the issues above in a sane way, without me reimplementing apt-like functionality in rpm land?

As those of you who’ve been a bit more observant may have noticed, I now have a new company - Codethink Ltd. It’s really just starting up, but so far we’ve been doing work on HAL, OHM and Tinymail and it’s been good fun. However I don’t want to go the normal contracting house route of taking on employees to supply demand. This inevitably leads to static power structures and static role assignments which generally seems to lead to inefficiency, conflict and boredom as a company grows. Where I want to take Codethink: In business, I believe the future lies in loosely connected individual contractors, dynamically coming together to attack a project or idea, much as was described a few years ago in the seminal article ‘The Dawn of the E-lance Economy’ by Malone and Laubacher (Though I have to admit I hate the term ‘E-lance’..). Back then a few businesses were started up to try to facilitate this, like guru.com and elance.com, but I think these fail fundamentally as they don’t represent the knowledge of the network - that requires real people who actually know each other. Of course here in open source we implicitly understand the importance of knowing each other’s strengths, the importance of introducing new people to our community and building new expertise. This can only happen in loosely-bound structures, where cost of entry is negligible - quite the opposite of the standard large-corporation model. So with Codethink I propose to act as an agent of change. I plan to provide support and help to groups and individuals who want to strike out on their own. I will use my knowledge of the management, architectural and coding expertise of these individuals to provide the service of assembling teams to attack projects for clients. There needs to be another side to the equation. For this to scale, I also need to invest in bringing new people into our open source world and training them as experts able to strike out on their own. So that means taking on employees of a kind - but with the covenant that I will be expecting each employee to be looking at becoming her own boss in time. So my cards are on the table now - for this plan to work it needs to be transparent by default. It may turn out to be a crazy idea that’ll never work in practice, but lets see. If anyone wants to chat with me about these plans, you can find me at rob.taylor@codethink.co.uk on email and XMPP and I’m always around as robtaylor on Freenode and GIMPNet.

I've been receiving a number of bugreports, both formal bugreports through the BTS and just people contacting me through regular mail or otherwise, about the packages for the Belgian Electronic ID card that I maintain for Debian. I think I'm starting to see a pattern in the bugs, but I'd like to be sure; and in order to be sure, I'd like for people who use beid on Linux to please send me the following information:

• Does it work for you? If not, does nothing work, or can you use some of the eID functionality? E.g., it might be that you can get the 'beidgui' application to start and do useful stuff, but that the firefox plugin doesn't work.
• Are you using Debian (or a derivative, like Ubuntu)? If not, what distribution are you using, and do you use a package or did you compile from source?
• What chipset does your smart card reader have? Does your reader use the PC/SC API, or do you use OpenSC? (note: this is a change that I made to the beid packages; the official government source does not contain OpenSC support, and I suppose neither do packages for other distributions)
• What processor do you have? (powerpc, amd64/em64t, i386-based, m68k, ...?)

I'd appreciate it if people willing to help me out could send me an email with their answers to the above at wouter+beid@grep.be. Thanks. The pattern that I'm seeing currently is that people using the ACR38u chipset (as in the eID cardreaders sold by Zetes and the government) on amd64- or em64t-based machines cannot get it to work. What I'd like to find out is whether it works on other 64bit architectures, and/or whether it is acr38u-specific. Of course, I'm not doing this on a for-pay basis (I 'simply' maintain the Debian packages), so there's no guarantees of me fixing these issues here. Your cooperation is greatly appreciated.

Mark Greenaway writes about writes about robots being designed to remove weeds from farms. This seems like a bad idea given that we currently have an energy crisis due to CO2 emissions from power plants causing environment change (including reduced water supplies), and coal and nuclear power plants requiring water to produce electricity (pity about the reduced water supply). Introducing robots that require either electricity of petrol for operation and also maintenance (which probably requires plastic parts on occasion) seems to be more of a problem than a solution. Fortunately there is already work in progress on training sheep to eat weeds. Given that we already raise sheep for wool and food it makes more sense for them to eat unwanted vegetation (weeds in a vineyard is the example given) than to grow grass specially for them. Also Mark says that the recent increase in oil price is not good news. What would be ideal is a slow steady increase in petrol prices that allows individuals and companies to change to more efficient vehicles (smaller and slower vehicles, hybrid vehicles, and more use of public transport) and also allows governments to make changes (such as building new public transport infrastructure). Having the oil remain cheap until it starts to run out doesn’t do anyone any good (apart from the short-term interests of oil companies).

Share This

Over the past few days, I've returned to python for the first time in three or four years. My two excuses for not really liking python in the past were 1) a bad experience editing someone else's mixed tab-and-space indented code and 2) the language never really flowed out of me for some reason. I've gotten over the bad taste from the former after being assured by everyone I talked to that this sort of thing doesn't happen often, although I'm still wary of how easy it is for people to do this sort of thing.

The latter seems to have changed by a surprising avenue: learning haskell. I spent months trying to learn haskell, and I've gotten far enough along where I can sorta kinda construct useful programs with it. I'm not comfortable enough with it yet to do everything I want, but I like the language a lot because I always feel like I'm doing the right thing when I actually get a program to work. Strangely though, when I came back to python, all of a sudden how to write a lot of the code just made sense. Python lends itself well to a functional style of programming, especially given that it's started to consciously steal things like the new itertools and partial functions in version 2.5. I guess I shouldn't be too surprised that learning haskell suddenly made it a lot easier to understand other languages, but it's funny that haskell should be my gateway to python and not the other way around.

Well, the last day in Greece went swimmingly. It was mostly just relaxing, playing on the Internet, chatting with lovely Di, and working out logistics of taking a long flight back to the United States. The only strange thing about it is that I haven't slept since the last post, which is away from the norm. It's a kind of forced all-nighter caused by the bad scheduling that I made for myself. The flight from to Athens happened at 10:20pm in the evening. This was the latest flight that I could get and assure that I could get to the Athens airport in time for my 7:20 flight to Madrid, which connects through Chicago and back to Minneapolis at last.

I've spent a total of 10 days outside of the United States now, the longest time since I have been alive, according to my knowledge. It has caused some interesting results. I realized that I am inextricably connected to the people who I am familiar with in my life, and being without them decreases my mood significantly, and without contact to them decreases my mood sharply.

I am not alone in this fact. There are many studies that show that people who have more social connections lead happier lives. I am lucky in that I am technologically ept and can connect to my near and dear in a number of ways, and be resourceful in finding other ways to contact them if necessary. I feel that I am lucky to live in a time which it is possible for me to spend so much time apart and still be in connection with people. I am also lucky that I was born in a geological area which enables me to be as such.

At the same time, I am sad to leave this place. It is a nice area, with good food and a very long history. As Nikos reminded me the other day, it is the birthplace of Democracy, which I hold to a fairly high regard. It is also the birthplace of modern medicine, and a significant portion of many early sciences. The wealth of the nation as a whole and as parts is clear to me, and I wish to return.

I've learned part of the language while I am here, and it has made me more cognizant of communication with other cultures. People in Athens seemed put off when I tried to talk in Greek, but in Kos they were at the worst amused at my attempts. The language may not be as romantic to learn as French or Italian, and may not be as useful in the long term as Latin, but it would be interesting to speak nonetheless. I am tempted to start working on some of the i18n Greek QA issues in Debian -- It would help me learn the language more, and also keep me aware of the issues in software when you start working with other countries' characters. I have been lucky to be using a MacBook this entire time with decent Greek support, allowing me to type at least some greek while I was here. It helped me understand even more of the language - I now know mostly the numbers 1-9 at least.

The trip has highlighted for me something which is highly lacking in airports: power. Every airport that I have been to has prominently displayed the signs of wireless access, and has people using their laptops in almost every direction you can look (I am one of those), but they are sorely without power points for people who are using those laptops. This may be a designed flaw in order to save energy, but I don't really believe that 50 or even 5,000 laptops at 65-150W will put a significant dent in the power grid at somewhere as large as an airport, where LCD screens are running 24/7 with ads and bright lights illuminate every corner for all to be seen. I won't even start talking about the airplanes themselves.

All in all, the trip has been a happy one, and I would very much repeat it. I will make different decisions on lodging at some places and probably plan a shorter trip. I however wholly endorse Greece as a vacation spot, and even would consider moving here if offered a position (that would depend highly on Diana as well, obviously). I find it entirely favorable. I hope that this small series on the site has caused you, the reader some pleasure at least, even if it was at my expense.

Now begins the long trip home, on three planes and with 14.5 hours in the airplane and 18 hours in total. It'll be only 10 hours counting local time, unfortunately -- the jet lag will, I'm sure, be horrible.

Comments: (0) Trackbacks: (0)

Comments

1. No comments

Trackbacks

1. No Trackbacks

So with the GPLv3 and LGPLv3 finally out (hurray!) it’s time to actually pay attention to the practical consequences of an upgrade to the world’s premier copyleft licenses. One of the things I hadn’t noticed, though I should have, is that the LGPLv3 is not compatible with the GPLv2 – that is, GPLv2 programs that used LGPLv2 libraries cannot make use of new versions of those libraries released under the LGPLv3 without also updating their license to GPLv3 (or “GPLv2 or above”, or LGPLv2 or LGPLv3 or something similar). Fortunately one of the major LGPLv2 libraries out there – glibc – is reportedly going to remain available under the LGPL v2.1 but for other libraries, it could become a problem, and it’s something GPLv2 authors will need to pay attention to. Also fortunately the opposite problem – GPLv3 apps using LGPLv2 libraries isn’t a problem, because the LGPLv2 explicitly allows redistribution and modification under the terms of GPLv2 or later, so you can take an LGPLv2 library and incorporate it in a GPLv3 application and just release the whole thing under the GPLv3. Unfortunately, the LGPLv3 doesn’t have a similar clause, so when the GPLv4 comes out, if it ever does, we could easily find the GPLv4 apps can’t use LGPLv3 libraries, and GPLv3 apps can’t use LGPLv4 libraries. Really these are side-effects of a fundamental change: up until now, almost everything we’ve distributed – and certainly all the low level stuff: the kernel, the C library, the compiler, the shell and basic tools – have all been under a GPLv2 compatible license. Some of them have been more flexible than that, due to being under a BSD or MIT license, or being under the LGPL or having a “GPLv2 or later” clause, but we’ve been essentially able to ignore all that and just treat everything as GPLv2. There are a few exceptions that we have to deal with – the occassional app that’s not GPL compatible doesn’t cause much of a problem, because things that depend on it don’t usually create copyleft issues, which just leaves checking that it doesn’t use any GPL-only libs, such as gnutls or libreadline. Openssl is a nuisance, in that it’s a popular, GPL-incompatible library, but it’s also reasonably easy to deal with on a case by case basis. But with the GPLv3, that changes: as GPLv3 apps and LGPLv3 libraries get uploaded, the assumption that more or less everything is GPLv2 compatible goes out the window, and while some things are GPLv2 only (such as the kernel!) we also can’t assume everything is GPLv3 compatible. Fortunately, both the GPLv2 and GPLv3 have what is known as the “system library” exception, which allows you to not bother distributing the source to your C compiler or C library or kernel with your app, because everyone’s assumed to have one of those already. Unfortunately, the GPLv2 version of that exception includes the phrase “unless that component itself accompanies the executable”, so Debian has always cautiously assumed the exception doesn’t apply to us, because everything we distribute in main “accompanies” everything else in main – kernel, C library, C compiler, etc. Equally unfortunately, while the GPLv3 avoids that problem, but ends up with a clause that’s not terribly comprehensible, despite a couple of rewrites during the drafting process. What’s all that mean? The big thing is that it means Debian’s going to have to put a bit more attention into the system library exception, both for GPLv2 and GPLv3 apps, because our current policy of trying to avoid needing it is probably not going to be sustainable. I’m not sure how in depth we’ll need to go for that; we’ve already contacted the FSF licensing folks for an explanation of the GPLv2 clause in relation to the CDDL, but it’s possible the FSF might prefer to be ambiguous in responding so as to keep their options open for defending or enforcing the GPL later, in which case we might need to get legal advice of our own as to what we should do. The second thing is that in reviewing our understanding of the system library exception, we might be in a position to have a Debian GNU/OpenSolaris port, making use of the exception for the CDDL-licensed OpenSolaris kernel and libc, as Nexenta do. That seems to me to be almost certainly possible for GPLv3 (or “GPLv2 or above”) applications, and probably possible for GPLv2 apps as well. If so, that’ll let us expand Debian to supporting four kernels in the near future: Linux, Hurd, FreeBSD and OpenSolaris, which will be pretty fun, in my book. The downside, is that if we find an interpretation of the system library exception that lets us mix and match licenses comfortably, that same interpretation might be able to be used to let propietary software vendors mix and match GPLed software with non-free software, rather than just free software with different copyleft licenses – and thus defeat the entire point of copyleft. What’s worse, is that by following Debian’s lead, they’d have some moral authority in doing that, beyond just having a legal argument as to why it’s okay. And that’s the rub. (My thoughts on the license texts as posted to -legal are here, here, here and here.)

Yesterday was pretty much a long day of preparation and presenting. The day started with no internet, possibly for the entire island of Kos, I wasn't really every that clear on the whole of it. Apparently there are 2 underwater lines coming to Kos island and both had been severed or put out of service by someone. This was a bad thing, because I had intended to finish some final experiments and do some statistics on results, and Excel wasn't working. I suspect it is because I hadn't installed the updating tool of Office 2004 for Mac. Anyway I could do what I needed to do with R or Gnumeric, but they were both not installed yet. No internet = no new applications.

I finished the experiments and data gathering and the internet came back on just in time for me to download Gnumeric and get some of the stats working correctly. The final presentation didn't change that much, only changing on one slide and adding one small table, but the added result was significant enough to justify all of the work that it entailed. Indeed, it proved that the entire premise of the paper and simulation was valid. That made me feel all warm and fuzzy inside.

The talk was at 3:30, the first in a session which was mostly unrelated papers. I don't feel as bad because many of the other papers were kind of a hodge-podge as well, and we were probably all placed in the session because we didn't really fit anywhere else. I met a nice researcher who was chairing the session because the actual chair was presenting in another session (something we had worked out with software in the ICRA2006 schedule, but apparently wasn't taken into account here). The actual presentation went well, and Nikos lent me his laser pointer which added a little to the presentation I believe. Nikos said the talk was good, but I also got a comment that it was well-presented later in the day from a unrelated researcher. I was so-so about the presentation until I got the unsolicited comment.

After the talk I called up Diana on Skype and chatted for a while, but the network was too flaky at the conference, so she called my cell phone. Using Skype is one of the things that I have done more in this trip than I have done before ever. It is really a wonderful program and network for people who are far away from each other, and it actually has much more impact when you consider the costs of calling home with other methods. I estimate I saved about $200 in just three days of Skype calling instead of regular calling, even with calling to cell phones in the US every once in a while, and with Diana calling my Hellenic cell phone when my network was flaky as well. It is much more of a disruptive technology in the non-US world where every call isn't already paid for.

The banquet was next. Usually I don't like going to banquets, but this was set up different than the normal ones that accompany these conferences. Instead of a large service crew bringing out fancy food to a large set of tables, it was setup in a buffet with a large selection of Greek food so you could pick and choose your favorites and even go back for more food if you liked. I ended up trying a large variety of foods and discovering some new tastes that I hadn't had before. It was throughly enjoyable especially when listening to the others at my table of which three or four were Greek.

Then it was back to the hotel by bus, and an early bedtime in order to stock up on sleep for the long hours in the next day. Today I plan on just relaxing, sleeping a bit when I get tired, and maybe trying out some local snacks. I've already arranged for a Taxi. The last installment will be written from the Athens airport tomorrow.

Comments: (0) Trackbacks: (0)

Comments

1. No comments

Trackbacks

1. No Trackbacks

A comment on my previous post about my Linux Jobs Blog suggested that I shouldn’t fragment the information. However I believe that fragmenting the information is ideal due to the ability of RSS syndication to drive the cost of coalescing the information to almost zero! Currently there is a Linux job web site run by Linux Australia. It doesn’t have many adverts and isn’t even linked from the main Linux Australia web site. I believe that we can do better for the people who want Linux jobs and the people who have such jobs to advertise. If you have a central site the jobs have to be moderated (which takes work and delays listing), the larger the area that the site covers the greater the work is to do this. The solution is to have a distributed system with different people running listings for various regions and a syndication service to aggregate them. To start this I have created a blog which will have categories for the states and territories of Australia. Someone who is only interested in one region can visit the category for that region. Then recruiting agencies and companies which regularly hire Linux people can start their own RSS feeds to be syndicated in a planet instance for each state and territory. This gives a faster and more efficient response (adverts will appear quickly, can be changed or removed at any time, and less effort for moderation. I expect that recruiting agencies will occasionally post off-topic entries - but when their feed gets removed from the Planet installation they will probably make a commitment to do the right thing in future. Planet installations can syndicate other Planet installations, so we can easily have a Linux jobs Planet for Australia (possibly run by Linux Australia) that syndicates the feeds from each state and territory. In the long term I think that the best way of running this is to have Linux Australia run the central Planet instance and a LUG in each region run the local site. I started running it myself because I didn’t get a positive response when suggesting it to the relevant people in Linux Australia and LUV. That didn’t deter me, so I decided to set it up myself. If the idea takes off and if Linux Australia and the LUGs want to take it over I’ll be happy to use HTTP redirects to send the traffic to them - and help them with the sys-admin work if asked. Also there is nothing specific to Australia in this idea. I am only interested in Australia because if I was to attempt to do it in a larger area (such as the EU) then I could spend all my time on it without gaining a critical mass in any region. If you are interested in running this in your region then you need to set up a blog (for adverts that are sent to you via email) and a Planet installation that feeds from your blog and any other Linux job advert blogs in your region. If your country doesn’t already have a central Planet for jobs then creating a separate Planet installation for your country would be a good idea too. I will be happy to run a Planet installation for world-wide Linux job adverts (at least until I can convince an organization such as Linux International to run it) if this idea takes off in other countries. Some people have asked what the benefit of a Planet is over a mailing list. You have to subscribe to a mailing list while with a Planet you can immediately visit it if you suddenly decide to find a new job. Subscribing to mailing lists for jobs from all countries would never work, but visiting a Planet for Linux jobs world-wide and then visiting a sub-planet for regional jobs would be quick and easy.

Share This

Just graduated… and now what? Well, I had the opportunity to choose among several options: a PhD position at the TU/e, a PhD position at Heriot-Watt University in Edinburgh, or pursue a job at Google. After much consideration, I have chosen the first option. I found it to be impossible to decide based on the research assignment or the people I would work with, so I looked at more personal and practical reasons which led me to my current decision. I will start my job on August 1, 2007 and hope to finish the PhD in 2011. My research will involve working on project MoCaP, Models of Computation: Automata and Process, in which we try to achieve a better integration of the concurrency theory with the classical theory of automata. The thought behind the project is to make undergraduate computer scientists more aware of concurrency theory.

Kevin Mark commented:

"I see--Redarded Terrorist--ok. So this Gareth fellow is making a comparison with smarter, more intelligent terrorist that was the IRA. Which kind of says that everyone should be far less afraid of the current crop of folks and yet the media, as it does so well, inflates their dangerousness for the sake of ... well, beats me. Oh, maybe it help Tony get a job ;-) If the IRA came to the US, what color (or is that colour) code would their activities get on our terror scale as opposed to these Tardorrists?"

How about Emerald Green? More seriously, I think it's entirely fair to suggest we should fear this lot less than the often-USian-funded Provisional IRA, or local groups like animal liberationists. Those didn't just attack the big cities - it was everywhere, an attempt at terrorism. I lived about three miles outside Milton Keynes, then a fairly small midlands city, which was firebombed by both those groups. Ultimately, it didn't work. Most people weren't terrified. We carried on regardless. The government may be over-hyping this threat to ride in a new load of "expensive and ineffective" Security Theatre measures, like ID cards. Some media is sceptical, but the Murdoch-run media is mostly complicit, which is hardly surprising given the historic relationship. We should not let these "tardorrists" change our way of life, yet that is exactly what our spineless politicians seem to be doing. Let's continue as before: beware, but be happy. Update: niq comments:

"Recommended reading: Terry Pratchett "Interesting Times". Written before "9/11" and set in the wrong part of the world, but nevertheless beautifully relevant."

Proactive Bug Reporting We can do better than Proactive Bug Discovery. Now we have "Proactive Bug Reporting", i.e. reporting bugs for stuff which isn't yet in the Debian archive: #431820. Thanks madduck, that made my day LOL PS the Italian cabal has started chasing you this morning ...

With the development of rebuildd and the fact that several people are interested in re-using my scripts, I feel the need to explain how this stuff works. Grid’5000 First, Grid’5000 is a research platform used to study computer grids. It’s not really a grid (it doesn’t use all the classic grid middleware such as Globus). Grid’5000 is composed of 9 sites, each hosting from 1 to 3 clusters. Inside clusters, nodes are usually connected using gigabit ethernet, and sometimes another high speed network (Myrinet, Infiniband, etc). Clusters are connected using a dedicated 1OG ethernet network. Grid’5000 is in a big private network (you access it through special gateways), and one can access each node from any other node directly (no need for complex tunnelling). Using Grid’5000 nodes When you want to use some nodes on Grid’5000, you have to use a resource manager to say “I’d like to use 50 nodes for 10 hours”. Then your job starts. At that point, you can use a tool called KaDeploy to install your own system on all the nodes (think of it as “FAI for large clusters”). When KaDeploy finishes, the nodes are rebooted in your environment, and you can connect as root. At that point, you can basically break the nodes the way you want, since they will be restored at the end of your job. Running Debian QA tasks on Grid’5000 None of that was Debian-specific. I will now try to explain how QA tasks are run on Grid’5000. The scripts mentioned below are in the debcluster directory of the collab-qa SVN repository. When the nodes are ready, the first node is chosen to play a special role (it’s called the master node from now on). A script is run on the master node to prepare it. This consists in mounting a shared NFS directory, and run another script located on this shared NFS directory to install a few packages, configure some stuff, and start a script (masternode.rb) that will schedule the tasks on all the other nodes. masternode.rb is also responsible for preparing the other nodes. Which consists in mounting the same shared NFS directory, and executing a script (preparenode.rb) that installs a few packages and configures some stuff. After the nodes have been prepared, they are ready to execute tasks. To execute a task, masternode.rb connects to the node using ssh and executes a script in the shared directory. Those scripts are basically wrappers around lower-level tools. Examples are buildpackage.rb, and piuparts.rb. Now, some specific details:

• masternode.rb schedules tasks, not builds. Tasks are commands. So it is possible, in a single Grid’5000 job, to mix a piuparts test on Ubuntu and an archive rebuild on Debian. When another QA task is created, I just have to write another wrapper.
• Tasks are scheduled using “longest job first”. This doesn’t matter with piuparts tests (which are usually quite short) but is important for archive rebuilds: some packages take a very long time to build. If I want to rebuild all packages in about 10 hours, openoffice.org has to be the first build to start, since building openoffice.org takes about 10 hours itself… So one node will only build openoffice.org, and the other nodes will build the other packages.
• I use sbuild to build packages, not pbuilder. pbuilder’s algorithm to resolve build-dependencies is a bit broken (#141888, #215065). sbuild’s is broken as well (#395271, #422879, #272955, #403246), but at least it’s broken in the same way as the buildds’, so something that doesn’t build on sbuild won’t build on the buildds, and you can file bugs.
• I use schroot with “file” chroots. The tarballs are stored on the NFS directory. Which looks ineffective, but actually works very well and is very flexible. A tarball of a build environment is not that big, and this allows for a lot of flexibility and garantees that my build environment is always clean. If I want to build with a different dpkg-dev, I just have to:
  • cp sid32.tgz sid32-new.tgz
  • add the chroot to schroot.conf
  • tell buildpackage.rb to use sid32-new instead of sid32
• Logs and (if needed) resulting packages are written to the NFS directory.

Comments and questions welcomed :)