The Opera-Mini Dispute I have just read an interesting article about the Opera browser [1]. The article is very critical of Opera-Mini on the iPhone for many reasons most of which don t interest me greatly. There are lots of technical trade-offs that you can make when designing an application for a constrained environment (EG a phone with low resolution and low bandwidth). What does interest me is the criticism of the Opera Mini browser for proxying all Internet access (including HTTPS) through their own servers, this has been getting some traction around the Internet. Now it is obvious that if you have one server sitting on the net that proxies connections to lots of banks then there will be potential for abuse. What apparently isn t obvious to as many people is the fact that you have to trust the application. Causes of Software Security Problems When people think about computer security they usually think about worms and viruses that exploit existing bugs in software and about Trojan horse software that the user has to be tricked into running. These are both significant problems. But another problem is that of malicious software releases. I think that this is significantly different from Trojan horses because instead of having an application which was written for the sole purpose of tricking people (as is most similar to Greek history) you have an application that was written by many people who genuinely want to make a good product but you have a single person or small group that hijacks it. Rumor has it that rates well in excess of $10,000 are sometimes paid for previously unknown security vulnerabilities in widely used software. It seems likely that a programmer who was in a desperate financial situation could bolster their salary by deliberately putting bugs in software and then selling the exploits, this would not be a trivial task (making such bugs appear to be genuine mistakes would take some skill) but there are lots of people who could do it and plausibly deny any accusation other than carelessness. There have been many examples of gambling addicts who have done more foolish things to fund their habit. I don t think it s plausible to believe that every security flaw which has been discovered in widely used software was there purely as the result of a mistake. Given the huge number of programmers who have the skill needed to deliberately introduce a security flaw into the source of a program and conceal it from their colleagues I think it s quite likely that someone has done so and attempted to profit from it. Note that even if it could be proven that it was impossible to profit from creating a security flaw in a program that would not be sufficient to prove that it never happened. There is plenty of evidence of people committing crimes in the mistaken belief that it would be profitable for them. Should We Trust a Proprietary Application or an Internet Server? I agree with the people who don t like the Opera proxy idea, I would rather run a web browser on my phone that directly accesses the Internet. But I don t think that the web browser that is built in to my current smart-phone is particularly secure. It seems usual for a PC to need a security update for the base OS or the web browser at least once a year while mobile phones have a standard service life of two years without any updates. I suspect that there is a lot of flawed code running on smart phones that never get updated. It seems to me that the risks with Opera are the single point of failure of the proxy server in addition to the issues of code quality while the risks with the browser that is on my smart-phone is just the quality of the code. I suspect that Opera may do a better job of updating their software to fix security issues so this may mitigate the risk from using their proxy. At the moment China is producing a significant portion of the world s smart-phones. Some brands like LG are designed and manufactured in China, others are manufactured in China for marketing/engineering companies based in Europe and the US. A casual browse of information regarding Falun Gong makes the character of the Chinese leadership quite clear [2], I think that everything that comes out of China should be considered to be less trustworthy than equivalent products from Europe and the US. So I think that anyone who owns a Chinese mobile phone and rails against the Opera Mini hasn t considered the issue enough. I don t think it s possible to prove that an Opera Mini with it s proxy is more or less of a risk than a Chinese smart-phone. I m quite happy with my LG Viewty [3] but I wouldn t use it for Internet banking or checking my main email account. Also we have to keep in mind that mobile phones are really owned by telephone companies. You might pay for your phone or even get it unlocked so you can run it on a different network, but you won t get the custom menus of your telco removed. Most phones are designed to meet the needs of telcos not users and I doubt that secure Internet banking is a priority for a telco. Update: You can buy unlocked mobile phones. But AFAIK the Android is the only phone which might be described as not being designed for the needs of the telcos over the needs of the users. So while you can get a phone without custom menus for a telco, you probably can t get a phone that was specifically designed for what you want to do. The Scope of the Problem Mobile phones are not the extent of the problem, I think that anyone who buys a PC from a Chinese manufacturer and doesn t immediately wipe the hard drive and do a fresh OS install is taking an unreasonable risk. The same thing goes for anyone who buys a PC from a store where it s handled by low wage employees, I can imagine someone on a minimum income accepting a cash payment to run some special software on every PC before it goes out the door that wouldn t be any more difficult or risky than the employees who copy customer credit card numbers (a reasonably common crime). It s also quite conceivable that any major commercial software company could have a rogue employee who is deliberately introducing bugs into it s software. That includes Apple. If the iPhone OS was compromised before it shipped then the issue of browser security wouldn t matter much. I agree that having the minimum possible number of potential security weak points is a good idea. They should allow Opera Mini users to select that HTTPS traffic should not be proxied. But I don t think that merely not using a proxy would create a safe platform for Internet banking. In terms of mobile phones most things are done in the wrong way to try and get more money out of the users. Choose whichever phone or browser you want and it will probably still be a huge security risk. Harald Welte is doing some really good work on developing free software for running a GSM network [4]. But until that project gets to the stage of being widely usable I think that we just have to accept a certain level of security risk when using mobile phones.

• [1] http://counternotions.com/2010/02/18/mini/
• [2] http://www.faluninfo.net/
• [3] http://etbe.coker.com.au/2009/05/31/lg-u990-viewty/
• [4] http://laforge.gnumonks.org/weblog/2010/02/13/#20100213-six_weeks_to_bcch

I guess it's time to finally announce libopenstm32, a Free Software firmware library for STM32 ARM Cortex-M3 microcontrollers me and a few other people have been working on in recent weeks. The library is licensed under the GNU GPL, version 3 or later (yes, that's an intentional decision after some discussions we had). The code is available via git:

 $ git clone git://libopenstm32.git.sourceforge.net/gitroot/libopenstm32/libopenstm32
 $ cd libopenstm32
 $ make

Building is done using a standard ARM gcc cross-compiler (arm-elf or arm-none-eabi for instance), see the summon-arm-toolchain script for the basic idea about how to build one. The current status of the library is listed in the wiki. In short: some parts of GPIOs, UART, I2C, SPI, RCC, Timers and some other basic stuff works and has register definitions (and some convenience functions, but not too many, yet). We're working on adding support for more subsystems, any help with this is highly welcome of course! Luckily ARM stuff (and especially the STM32) has pretty good (and freely available) datasheets. We have a few simple example programs, e.g. for the Olimex STM32-H103 eval board (see photo). JTAG flashing can be done using OpenOCD, for example. Feel free to join the mailing lists and/or the #libopenstm32 IRC channel on Freenode. The current list of projects where we plan to use this library is Open-BLDC (an Open Hardware / Free Software brushless motor controller project by Piotr Esden-Tempski), openmulticopter (an Open Hardware / Free Software quadrocopter/UAV project), openbiosprog (an Open Hardware / Free Software BIOS chip flash programmer I'm in the process of designing using gEDA/PCB), and probably a few more. If you plan to work on any new (or existing) microcontroller hardware- or software-projects involving an STM32 microcontroller, please consider using libopenstm32 (it's the only Free Software library for this microcontroller family I know of) and help us make it better and more complete. Thanks!

During recent weeks, not only sbuild and buildd were changed, but also wanna-build. Many changes were small and don't have direct impact, but will ease our life in future. This includes a bunch of code cleanups. Most changes were done by Kurt Roeckx and me, but as usual Marc Brockschmidt and Philipp Kern were also involved. This round of changes was started with redoing our priority calculation. Up to now, any package had a fixed place in the list, and our list was built from top to bottom as far as buildd power was available (putting aside manual intervention by setting build-priority by admins). That meant of course that some packages could be stalled if buildd time isn't enough anymore, like currently on mipsen. (The queue order was determined by the following sort options: build-priority, (>= standard?), already built in the past, priority, section, name, and the first difference decided list order.) Now, of course >= standard packages are still built first, but waiting days increase priority so that old extra packages could be built before young optional package (in other words, they shouldn't stall. The new formula is about: required: 50, important: 40, standard: 30, optional: 5 [priority] + libs: 4, devel: 2 [section] + contrib: -20, non-free: -40 [component] + out-of-date: 20 [notes] + max(6, waitingdays) * 2 + manual priorities, and packages are ordered by this number, then by waitingdays, then by name.) While adding code to add bonus for long-waiting packages, we stumbled across the fact that there were non-C dates in the database stored, which in turn means that export of the database stopped to work. For fixing that we replaced the last change field in the database by an postgres now() on insert, and converted that field to an date field (instead of freetext). Which in turn broke mkstats and a few more things, which are fixed as of now. While doing that, we also introduced the format option, which allows to do queries like:

wanna-build --format='%t %u: %p/%v% +b B%B' -A mipsel --list=building

which gives output like:

2010-03-03 15:24:38.642988 buildd_mipsel-mayer: cracklib2/2.8.16-1
2010-03-03 15:30:00.341313 buildd_mipsel-rem: liblouisxml/2.1.0-1+b1

Of course, there are even better possibilities what one could do with that. :) More changes are pending, like the injector for log files was changed so that we record building times in the database. This will allow us to include build time on at least a few buildds, so that large packages cannot so easily stall all buildds completely anymore. So, more to come ...

I spent the day working with Daniel. He has been trying to get the correct runes for a GCC build in a strange environment. Turns out all he needed was me to throw stupid ideas at him until one caused him to examine some of the generated intermediate symbol maps...

(This has ended up longer than I intended, largely because I felt I should then get into why. I'm aware I haven't got into all the nuances, so I hope readers familiar with the area will appreciate this is the compact version.)

Thorsten had a rant last week about PGP keysigning problems. He apologises for his tone, but that's not the issue I take with his rant.

It starts "Keysigning is useless". And yet his complaints seem to be:

• Dealing with the private half of your GPG key securely involves some faff (in this case booting with a live CD and having to set things up ready to keysign).
• He doesn't get on with caff.
• People reject email from machines with invalid HELOs and perform other anti spam measures on ISP access ranges (I'm not clear if it's just greylisting or outright rejects as that's not made clear).
• PGP/MIME is a protocol violation (yes, but it's much better than inline OpenPGP. Unless you have to deal with RT, which mangles it. *sigh*)

None of these seem to actually be about keysigning being useless. The process of doing it, maybe, though he misses the main valid rant about this I'd have, which is that most mass keysignings don't actually allow you to accurately verify the identity of other participants unless you already know them reasonably well. (The LCA2010 keysigning and DebConf5 in Helsinki spring to mind as 2 good examples of bad keysignings I've attended, but speaking to others suggests it's far from an isolated thing.)

Torsten does say that he'll continue to do keysigning on a per-person basis, so it doesn't sound like he's completely given up. I'm posting this largely so other Debian related people don't get the idea that it's not important to think about keysigning.

Why should we care?

Firstly, let's clarify what I mean when I sign someone else's key. If I sign your key then I think that I believe you hold the private part of a key that has your name and an email address I believe I can use to contact you on it. It means I have seen government issued ID that matches that name. It also means that I have interacted with you (and watched others interact with you) under that persona. In short I am happy that the key is a reasonable digital representation of your identity - something signed by it either comes from you or has involved the key being compromised or you coerced into using it against your will.

Why is this useful?

It gets useful thanks to the web of trust; ie the idea that there are a bunch of people I trust partially to sign other keys, and if enough of them have signed a key then I can have a reasonable expectation that the key belongs to the person I want to talk to. Which means I might be prepared to send private data to them. Or Debian might be prepared to accept an upload from them. Which, when you're dealing with a community that spans the planet and where most of the contributors haven't met each other, is pretty freakin' useful - I, as part of Debian's keyring team, don't need to personally be able to identify every Debian developer. All I need to do is be able to trust other DDs to be able to do so. (Though maybe I'm missing out on something here - perhaps Debian should be paying for Gunnar and me to travel the world verifying fingerprints. \o/)

(I still do mass keysignings btw. I'm picky about which keys I actually sign - this is in no way intended as a slight against those I don't, but a mass keysigning at least lets me know that the people involved are happy to exchange fingerprints. Though, FWIW, I normally have ID on me and frequently have fingerprint slips, so if you know me and want me to sign your key/want to sign mine then by all means ask me when you see me!)

Or should I say *we* are going to Debconf 10? Last week-end, I booked the whole set of plane tickets for the Perrier family to fly to USA next summer:

• Jean-Baptiste (aka "Habanero" on IRC) and myself will from from Paris Charles de Gaulle on Wednesday July 28th, arriving in NYC after a connection in Dublin (shame that connection flights are much cheaper than direct flights). As I already wrote earlier, I'll attend Debconf with my son, yay!
• Elisabeth, Sophie and Magali will fly the same route on Aug 5th. We'll stay partly separated during the first days: JB and I at Debconf and them doing some sightseeing in NYC.
• On Aug 8th, we'll start ou family holidays: first stay a 1 or 2 more days in NYC, sightseeing together
• Later on, we plan some trip in the NE part of USA: probably something around Boston and New England, wandering around undertermined places in NY and Vermont states, maybe up to Montreal...then back to NYC
• Finally 5-6 days in our family in the Kansas City area
• Then back to Paris, via New York again, on Aug 23rd and 24th

Nice.

RCBW - #23 Wacky week, last week. Not only I've (almost) completed my moving to the new house, but we have also had guests in the lab for some full-immersion-paper-writing. That had left very little time for RC squashing, but I've catched up a bit in the week-end. Without any further ado, here are this week's squashes:

• bug #516336 - haskell-utils - requested removal (superseded by haskell-devscripts)
• bug #547278 - elvis - downgrade, unwarranted RC severity
• bug #559833 - imagemagick - libltdl CVE, investigated and closed as false positive
• bug #567706 - mailcrypt - drop support for emacs flavours older than 23
• bug #547810 - ccsm - fix FTBFS with python 2.6
• bug #571185 - padre - requested removal from testing
• bug #561524 - pyjamas - fix FTBFS with python 2.6 (Ubuntu patch by Fabrice Coutadeur)

Random points:

• call for help, if you are a libtool guru there is some work for you: bugs like bug #559822 need your help (very old code, using very old libltdl stuff, need to be ported to recent, non-buggy libltdl code and to use the system copy of the library ...).
• my personal RC bug monitor (hence very biased) currently reports 278 RC bugs. Also, I've the impression that the ratios of new bugs coming in vs ancient ones getting fixed equate. If that is true, it would be a pity not to freeze this month.
  ... what are you doing here? still reading this blog post? go squash a RC bug!

In totally unrelated news: I've bought my ticket for DebConf10 (YAY!), according to my usual debconf customs: 4 days of debcamp + all the conf. See you there (in a while). ... and congrats to Adnan for the winning DebConf11 bid!

DoctorMO is calling Paypal the Pocketing Police after this Paypal [...] decided we were scammers and took our money comment by Daniel Stone during the Xorg foundation election discussions. Our co-op has avoided Paypal for a number of years for two reasons:

1. Paypal didn t recognise UK company registration numbers that contain letters (like ours) for years after they first occurred, so we couldn t register as a seller;
2. the terms and conditions are very unequal, there are shedloads of complaints like paypalsucks.com and I don t believe they re all fiction.

We ve not boycotted it yet because there are two of our current suppliers who are very expensive for us to pay by international bank transfer, accept Paypal and don t offer much alternative. I think I ll go ask them again. At least one of them should be sympathetic to Xorg.

Thomas blogs about some issues he had with his N900's facebook plugin. This post isn't about that, as I don't use facebook. But as part of his blog post, he mentions the following:

This reminded me of a pet peeve I have with those people who claim Debian s packaging system to be far superior to rpm apparently dpkg doesn t have any equivalent of rpm -qv which allows you to verify that the files that should be installed by a package are indeed on disk

True, probably because the script would be so trivial:

for i in $(cat /var/lib/dpkg/info/nbd-client.list)
do
	[ -f "$i" -o -d "$i" ]   echo "$i missing"
done

There, that wasn't hard, was it? Now I'm not sure whether rpm's -qv option actually checks the checksum of the files, too. If it does that, then the semantically similar way would be:

(cd / && md5sum -c var/lib/dpkg/info/nbd-client.md5sums)

... except that MD5 is totally and utterly useless these days, and that we should be changing to something else. And that md5sums is an optional feature, provided by some, but not all, packages. And it may also be that maemo packages don't have md5sums (which would make sense). But, anyway.

Experimental 2.6.33 will do the switch to UUID based root args, if you haven't switched already. Please test it out and report bugs on it, before we add the libata switch to squeeze 2.6.32. 2.6.32-9 includes 2.6.32.9 and several other fixes. For the following 2.6.32-10 Ben Hutchings pulled in newer drm for lots of intel fixes: Status of kernel X drivers. It also features radeon and nouveau KMS modules. Current 2.6.32 is stabilizing well and we are seeing lots of external patches lining up. Update: Sorry due to jet lag got aboves version number wrong. You might want also to checkout: The season I have mostly been building kernels.

I don't know if anyone else has been tracking this recently, but a while back I got curious about the relative proportions of dh(1) and CDBS in the archive, and started running some daily analysis on the Lintian lab. Apologies for my poor graphing abilities, but the graph is here (occasionally updated): Although dh is still a bit behind CDBS, the steady upward trend is quite striking - it looks set to break 20% soon, up from under 13% in September - compared with CDBS which has been sitting within half a percentage point of 25% the whole time. Incidentally, was that an ftpmaster trying to sign his name in the graph over Christmas or something? :-)

Sorry; I didn't made it in the promised 15 minutes (as someone turned the internet off), but here is finally the link to my (German) slides of my Debian GNU/kFreeBSD talk. (Sorry, no fancy website arround that, yet.) I would also like to make clear, that Debian does not plan to drop it's support for the Linux kernel. Debian will continue to release a linux based distribution. You may install the very same distribution based upon a FreeBSD kernel. It's your choice. A several people asked that at our booth, I guess there is somewhere a missunderstanding, but I don't know the root if that missunderstanding. If someone could tell me, why he thought so (maybe I missed a unclear formulation somewhere?) I would be very glad and try to improve it. So, thanks again for the kbsd people, who helped alot and really tried to answer every stupid question I came up with during preparing my talk :)

I wonder why the federal minister for consumer protection (hopefully a good enough translation for Verbraucherschutzministerin ) Ilse Aigner has concerns about Street View, because those concerns are completely unrelated to protecting the consumer, because the consumer is the one viewing the images in the browser, and not the person being photographed. I have no reason to believe that Google Street View is illegal, I see no difference between a photo taken by a company and a photo taken by a single person. If Google Street View were illegal, distribution of every picture taken in the public would have to be considered illegal as well. And creating laws limiting the height at which the camera is placed to e.g. 1.8 meters sounds like discriminating against persons who are e.g. 1.85 meters ( You re too tall, you re not allowed to take a picture ). More information about this topic can be found on e.g. http://www.spiegel.de/international/germany/0,1518,676616,00.html.
Filed under: General

Here are some more examples of libguestfs usage: What kernels, modules and packages are in a (currently powered off) libvirt based virtual machine vmfoo:

virt-inspector -c qemu:///system vmfoo

Show free space in virtual machine vmfoo:

virt-df -c qemu:///system vmfoo

List file systems:

virt-list-filesystems -c qemu:///system -l vmfoo

Edit /etc/passwd in vmfoo:

virt-edit -c qemu:///system lenny-base-clone /etc/passwd

Tell guestfish to mount all filesystems of virtual machine vmfoo for more complex inspection and manipulation tasks like LVM operations, partitioning, resizing or filesystem check or creation:

guestfish $(virt-inspector -c qemu:///system --ro-fish vmfoo)

Debian packages are still on alioth.

Nathanael Boehm wrote a nice essay last month called The Future of Employment?, about a disconnect between workers' and employers' views of social networks. (This post is based partly on my comment in the ensuing Hacker News thread.) Boehm wrote:

When I need help with a challenge at work or need to run some ideas past people I don t turn to my co-workers, I look to my network of colleagues beyond the walls of my workplace. Whilst my co-workers might be competent at their job they can t hope to compete with the hundreds of people I have access to through my social networks...

The late Sun Microsystems taught us that the network is the computer. It's true: we still use non-networked computers for specialized tasks, but nobody wants one on their desk it's just so useless compared to one that talks to the entire world. Boehm could have titled his essay The Network is the Employee. There are still tasks that people do in isolation, but the ability to contact a network of peers and experts makes the difference in my job, and many others. Alone together The lone computer programmer in a small business has thousands of colleagues on Stack Overflow, Reddit, and so on. It's a chaotic and messy way to find answers, but it's better than the days when your only choice was to call tech support or smack the box with your fist, whichever seemed more useful. I can't begin to list all the problems I've solved and things I've learned by Googling for others with relevant experiences, and getting help from a different expert for every problem. Decades before the web, computer geeks had virtual communities for on mailing lists, Usenet, and IRC. Now any job in the world has an online forum. Even the night clerk at the gas station has Not Always Right. Teaching has long been a solitary profession. Despite working in a crowded classroom, teachers are isolated; they rarely have colleagues observing or participating directly in their work. This has such an impact that teacher education sometimes includes training in meditation or reflection, to compensate for lack of external feedback. So I'm really curious what happens when teachers start to work together remotely the way programmers do. You will be assimilated Boehm's essay reminded me of a vague sci-fi-like idea I've been kicking around: the first group minds will evolve from the intersection of Mechanical Turk, virtual assistants, social networking, and augmented reality. Starting around the 1990s, it was possible to instantly "know" any fact that was published online. Since then, we've increased the amount of content online, our tools for searching it, and ways of connecting to the network. Today we have instant access to almost any published knowledge, anywhere. The number of people on the net has grown too, and the number of ways to find and talk to them. Most of us can contact dozens of friends at any given moment, plus friends-of-friends, co-workers, fellow members of communites like Hacker News or MetaFilter, and also complete strangers. Along with raw facts, we now have access to vast amounts of human judgement, experience, and skill. One result of this is the "virtual assistant," who provides a service that was once available only to high-powered executives. The new personal assistant can work remotely (often overseas), spread costs by serving many masters, and leverage the internet superpowers listed above. Today their services are targeted at small business owners and the Tim Ferriss crowd, but I'm sure someone soon will start marketing virtual personal assistance to all sorts of other creative workers, teachers, even stay-at-home parents. So, how long before I can simply touch a button to let a remote assistant see what I'm seeing in real-time and help me make transportation plans, translate foreign signs and speech, look up emails related to whatever I'm doing or thinking, or even advise me on what to say? Some of these queries will go to my circle of friends, others to the general public, and some to a personal assistant who is paid well to keep up with my specific needs. And that assistant of course will sub-contract out portions of each job as needed to computer programs, legions of cheap anonymous Turkers, or to his or her own network of assistants. At that point, I'm augmenting my own perception, memory, and judgement with a whole network of brains that I carry around ready to engage with any situation I meet. If nothing else, I hope someone writes a good sci-fi thriller story in which a rogue virtual assistant subtly manipulates the actions of unknowing clients, leading them to some unseen end.

This project blows ass.

I was reminded this morning after a bit of chatter on #debian-cli that my previous write-up on setting one s locale on Ubuntu is out-of-date. Instead of running dpkg-reconfigure locales and selecting your locale, the new incantation is as follows: Magic

$ sudo locale-gen en_US.UTF-8

Environment Variables You ll also want to set some environment variables. Put something like the following in your ~/.bashrc:

LANG=en_US.UTF-8
LANGUAGE=en_US.UTF-8
LC_CTYPE=en_US.UTF-8
LC_MESSAGES=en_US.UTF-8
LC_ALL=en_US.UTF-8
export LANG LANGUAGE LC_CTYPE LC_MESSAGES LC_ALL

You would of course replace en_US.UTF-8 with whichever locale you want to generate.

The Debian Packages Tracking System has a great feature: you can subscribe to packages that matter to you, and be informed of all uploads, bugs, testing migrations, etc. However, when (co-)maintaining a lot of packages, it is easy to forget to subscribe. And then you might miss important information about your packages (uploaders don t receive bugmail by default, for example). Since PTS subscriptions are now imported into Ultimate Debian Database, it is easy to find out if you missed some subscriptions. It s just a matter of going to http://udd.debian.org/cgi-bin/pts-check.cgi and entering your email! And for those concerned with privacy, it should be noted that the unauthenticated access to UDD only gives you the hash of the subscribers emails. You need to be a DD, and use the guestdd account to see the email addresses (which DDs can already see on master.d.o).

Generalizations are fun, they always are because they tend to offend people and offended people by stupid shit is usually lots of fun. Here Debian, as a whole, fails; it sucks. Here Debian blows ass, the entire project is whack. My good friend Chris Lee sent me this: <iframe height="500" src="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=380731" style="border:2px solid #000000" title="Debian fails" width="100%"></iframe> If you can't see the above iframe, go here. Debian, full of fail. Wasn't this generalization fun? Let the non-sense bullshit horses be released.

This moment has finally arrived! Last Saturday (27-th) on #debconf-team decision was made, DebConf11 is coming to Bosnia and Herzegovina! Our team and myself were working on this whole candidature for last ~9 months, and even though we put incredibly amounts on energy, hard work, enthusiasm and everything else that goes along with it, suspense and uncertainty were there until the very last minute! One of our local team members (trip0d s) wife almost gave a birth to their child during the decision process that lasted full 4 hours As a remainder we were competing with Ecuador and Germany to win this bid, whole process was excruciating and very emotionally distressful in every possible aspect for every team member; at one point Germany took a slight lead ahead of Bosnian team, while in the end by points Bosnia was in slight lead by 0.25 points, and this is exactly what touched me the most about this whole bid/decision/process. This is not a great advantage or anything for that matter, but what happened is that in decision process Debian debconf team and its developers picked Bosnia and Herzegovina as a place where they want to have DebConf11! Our main competitors from M nchen, Germany showed a real fair play and at the end even yielded to our side; really to both of you, Michael Banck (azeem) and Andreas Barth (aba) it was a pleasure and honor to compete with you guys! See you in NYC for proper handshake and possibly a hug? Also I d like to thank Jimmy Kaplowitz (Hydroxide), Moray Allan (moray) who had chairs and who did absolutely incredible job I guess I ll just have to thank the whole debconf orga team for all their amazing work ( can t name names individually because I ll definitely forget someone!) This bid really reunited whole Bosnia and Herzegovina, this whole process also united all of Balkans and whole of Ex Yugoslavia, which makes me especially happy since today (March 1st) we are celebrating the day we officially separated from Yugoslavia. Now this just one small step forward, since the real work is ahead of us and we re starting it all as soon as tomorrow since there s really a lot that needs to be done. Again thank you all, we ll give our best for this to be a DebConf you ll remember (as a great one of course!), in the meantime see you in New York City! Adnan Hodzic aka AbsintheSyringe team leader on behalf of whole debconf11-team. DebConf11 Banja Luka wiki Debconf11 decision log (#debconf-team log)