Fedora 17 will be shipping next week. It's got a bunch of new features, none of which I contributed to in the slightest. What I did work on was improving our support for installation on x86 Apple hardware. There's still a few shortcomings in this so it's not an announced or supported feature, but it's sufficient progress that it's worth writing about.

There's a few ways that Apple platforms differs from normal PC hardware. The first is that Apples are very much intended to be EFI first and BIOS second, while that's still not really true for commodity PC hardware. Apple launched Boot Camp shortly after they started shipping x86 Macs (and shortly after I'd got Ubuntu running on one for the first time[1]) but the focus of Boot Camp has always been to be good enough to boot Windows and not much else[2]. The other is the integration with the boot environment. You can boot Linux easily enough by setting the standard EFI boot variables, but if you ever boot back into OS X it's easy to trigger deletion of those. There's then no straightforward way of resetting them, and you're left having to recover your installation.

The other difficult bit has been actually starting the installer at all. If you're happy to use BIOS emulation than this can be done without too much misery, but you're then left with dealing with Apple's custom synchronised GPT/MBR. More modern Macs will boot via the standard EFI mechanisms, but there's a range of problems that can be caused that way. Fedora 17 is the first Linux distribution to ship install media that will EFI boot a Mac when either written to optical media or a USB stick[3]. Put the install media in your system and then either select it in the OS X Startup Disk preferences menu and reboot, or reboot and hold down the alt key. In the latter case there'll be a nice Fedora logo. Click on it and it'll boot.

The biggest difference between Apple hardware and anyone else is that we'd normally put the bootloader in a FAT partition that's shared with any other installed operating systems. That does actually work on Apples, but then you run into the earlier point I mentioned. The Apple startup picker that you get by holding down the alt key doesn't pay any attention to the standard EFI boot variables, so it won't show a FAT partition merely because it's got an EFI bootloader on it. The same is true of the OS X Startup Disk preferences. The best way to get a drive to appear in the menu is to make it look like an OS X drive.

This was problematic in a few ways, due to the requirement for an OS X drive to be HFS+. The first was that we didn't have any support for that in our installer, so work had to be done there. The second was that the state of HFS+ was woefully poor in Linux[4]. Linux will refuse to write to an HFS+ filesystem if it hasn't been cleanly unmounted or fscked, and since we can't rely on everyone always shutting their machine down cleanly that means a working fsck.hfsplus. In theory we were shipping one of those. In practice, it reliably segfaulted on 64-bit systems[5]. So I had to package the latest version of Apple's code, and doing that involved dealing with the fact that Apple now use blocks almost as much as Grub 2 uses nested functions, and that meant using Clang and that meant dealing with a bug where Clang segfaulted if it had been built with gcc 4.7[6], but finally once all of those yaks had been shaven we could trust our filesystem.

Of course, more problems existed. You can't just drop a bootloader onto an HFS+ partition and expect it to work. You need to write its inode value into the superblock. Trivial, except that if you do this from userspace then the kernel kindly overwrites your update when you unmount the disk and it updates the superblock. That required a mechanism for updating that data via the kernel, which meant adding an ioctl. This would have been fine, except the OS X Startup Disk preference looks for a bootloader in a location other than where Fedora installs it. Changing our bootloader install path wasn't a great option, so the easiest thing to do was just to link them together. Except HFS+ doesn't really support hardlinks. When you hardlink something the original file gets moved into a magic directory in the filesystem root and the links are special files that refer to it. And it turns out that it's not actually the inode that the firmware wants when finding the bootloader, it's the catalogue ID, and these aren't the same when hardlinks are involved. So, another kernel patch.

All that was left for the boot partition then was adding an icon and a drive label. We already had code for generating the icon, and the drive label wasn't that difficult. Hurrah!

Ok, so we can construct a filesystem that (a) appears in the bootpicker, and (b) appears in the OS X Startup Disk preferences. We can even put a bootloader on it. This led to the next problem. The bootloader started without any trouble. But the bootloader couldn't read any files off the boot partition, including its configuration. This should have been obvious with hindsight - the problem was simply that grub legacy[7] doesn't support HFS+. Writing an HFS+ driver seemed like an excessive amount of work, especially since the firmware already supported reading HFS+, so instead I wrote a simple grub filesystem driver that uses the UEFI interfaces to read files.

A working bootloader! One more problem there. grub looks in its startup directory to find its configuration file. We have two "copies" of grub hardlinked to each other, each looking in a different directory for configuration. Hardlinking the config files together worked fine, except that most tools that update config files have this irritating habit of writing to a temporary file and moving that over the original, thus breaking the hardlink. Easily solved by using a symlink instead, except that the UEFI filesystem semantics don't really support symlinks because UEFI only really envisaged using FAT. If you use Apple's UEFI HFS+ driver to open a symlink, you get a short file containing the target path of the symlink. Rather less than ideal, and a rather gross hack to cope with it.

All set now, other than a bug in some older Mac firmware where read would return BUFFER_TOO_SMALL without returning the real buffersize and the odd way that Apple treat CDs. Oh, and a bug in Apple's Broadcom wifi driver that could overwrite the kernel, and case-sensitivity, something that obviously isn't something you often hit on UEFI when all you usually see is FAT.

Kernel-side, we had a couple of things. Obviously there the bugs I'd mentioned in the past, but those had already been dealt with. New issues included the fact that we were frequently picking the wrong framebuffer address, especially on machines with multiple GPUs. Fixed now, along with another issue where we'd sometimes get confused by models with different GPU configurations. And at that point, most of the implementation work was done.

Of course, there was also the work of integrating this into the tools that we use to generate our install media, and I'd like to thank Will Woods, Brian Lane and Dennis Gilmore for the work they put into that, along with anyone I've forgotten. Tom Calloway handled getting the device label graphics generated right before deadline. A cast of thousands helped with testing.

So why did I mention shortcomings? First, this only works on machines with 64-bit firmware. Early 64-bit Apples still had 32-bit firmware. In theory we can support that case - in practice it's a moderate amount of writing, including some mildly awkward kernel code. But anything later than mid-2007 should have 64-bit firmware, so it's not a massive concern. Second, we seem to have fairly significant trouble with Radeon hardware on a lot of Macs. We fixed one bug there, but something's still going wrong in setup and you'll frequently end up with a black screen. And thirdly, I'm sure there's some other machines that still don't work for (as yet) undetermined reasons.

With luck we'll get these things dealt with by Fedora 18. But even with these flaws, Fedora 17 will work fine on a lot of Apple hardware, and testing it is as simple as downloading and booting a live image. Bugs go in the usual place.

[1] Note my charming belief that the Ubuntu installer would fully support this hardware via EFI in the near future. 6 years ago. It still doesn't.
[2] This can be fairly easily seen from little things like the name "Windows" being hardcoded into every UI that sees a Boot Camp drive.
[3] I cover this in more depth here
[4] To be fair, it mostly still is - there's plenty of work to be done there.
[5] Approximately nobody had noticed this, which is all kinds of unreassuring.
[6] Thanks to Kalev Lember for dealing with that
[7] Still the EFI bootloader in Fedora 17. We've already swapped Fedora 18 over to grub 2.

comments

Something a little low level for this post. I have been asked recently how to "test" for the maximum duration of an Interrupt Service Routine (ISR) in Linux

To do this I probably ought to explain what the heck an ISR is!

A CPU executes one instruction after another and runs your programs. However early in the history of the electronic computer it soon became apparent that sometimes there were events happening, generally caused by a hardware peripheral, that required some other code to be executed without having to wait for the running program to check for the event.

This could have been solved by having a second processor to look after those exceptional events but that would have been expensive, difficult to synchronize and the designers took the view that there was a perfectly good processor already sat there just running some users program. This Interruption in the code flow became known as, well, an Interrupt (and the other approach as polling).

The hardware for supporting interrupts started out very simply, the processor would complete execution of the current instruction and when the Program Counter (PC) was about to be incremented if an Interrupt ReQest (IRQ) was pending the PC would be stored somewhere (often a "special" IRQ stack or register) and then execution started at some fixed address.

The interrupting event would be dealt with by some code and execution returned to the original program without it ever knowing the CPU just wandered off to do something else. The code that deals with the interrupt is known as the Interrupt Service Routine (ISR).

Now I have glossed over a lot of issues here (sufficient to say there are a huge number of details in which to hide the devil) but the model is good enough for my purpose. A modern CPU has a extraordinarily complex system of IRQ controllers to deal with numerous peripherals requesting the CPU stop what its doing and look after something else.

This system of controllers will ultimately cause program execution to be delivered to an ISR for that device. If we were living in the old single thread of execution world we could measure how long execution remains within an ISR, perhaps by using a physical I/O line as a semaphore and an external oscilloscope to monitor the line.

You may well ask "Why measure this?" well historically while the ISR was running nothing else could interrupt it executing which meant even if there was an event that was more important it would not get the CPU until the first ISR was complete. This was known as IRQ latency which was undesirable if you were doing something that required an IRQ to be serviced in a timely manner (like playing audio)

This is no longer how things are done while the top half runs with IRQ disabled many are threaded interrupt handlers and are preemptable (I.e. can be interrupted themselves) which leads to the first issue with measuring ISR time in that the ISR may be executed in multiple chunks if something more important interrupts. Indeed it may appear an ISR has taken many times longer one time than another because the CPU has been off servicing multiple other IRQ.

Then we have the issue that Linux kernel drivers often do as little as possible within their ISR, often only as much as is required to clear the physical interrupt line. Processing is then continued in a "bottom half" handler this leads to ISR which take practically no time to execute but processing is still being caused elsewhere in the system.

The next issue is the world is not uniprocessor any more, how many processors does a machine have these days? even a small ARM SoC can often have two or even four cores. This makes our timing harder because it is now possible to be servicing multiple interrupts from a single peripheral on separate cores at the same time!

In summary measuring ISR execution time is not terribly enlightening and almost certainly not what you are interested in. The actual question is much more likely that you really want to be examining something that the ISR time was an historical proxy for like IRQ latency or system overheads in locking.

Released a few days ago, I am happy to announce that LLVM and clang 3.1 are already available in the Debian archive in Unstable. RC versions were already available for the last few weeks in Debian experimental. They are very likely to be part of wheezy.
We will soon try a new rebuild of the Debian archive with the version 3.1. Talking about clang, a couple of months ago, I proposed a GSoC project to extend the Debian infrastructure in order to use clang instead gcc to build Debian packages. The goal is not to replace gcc but it is more about building packages with a new compiler. With Paul Tagliamonte as co-mentor, Alexander Pashaliyski is going to work during the summer on this subject. The final deliverables should be:

• Build services modified to be able to use clang instead of gcc/g++
• Integration into the Debian infrastructure (buildd.d.o, and similar services)
• An easy way to switch of compiler between gcc/g++ and clang
• A way to build a package with a different compiler (gcc, clang, intel compiler, etc)
• Time permitting, a fully clang-built Debian installation

For now, Alexander is working on an installation of the wanna-build and buildd services in order to have a dedicated testing environment.

This will be a repost for anyone subscribed to Planet Debian, sorry. In case you have not heard about git-annex yet and you care about syncing, tracking, and managing your private or public files, go click the link; it's OK, I will wait. The use cases sound intriguing, don't they? But unless you are comfortable with a shell and git, don't bother using it; pain is inevitable. joeyh announced a kickstarter project to make git-annex more user friendly, support automated adding and syncing of files, and a web front-end. Notwithstanding the cut that kickstarter and amazon payments will take and the inherent questions that are being raised by paying for FLOSS, this is a very worthwhile endeavour to support. PS: Yes, this feels a tad circle-jerky inasmuch joeyh's post links to my blog; I would have linked to his post anyway, though. If anything, this made me think twice about posting this here. PPS: Yes, I will continue writing my Trans-Siberian series even though I am home already. Air China decided to keep me in China longer than planned, real life is busy, and, truth be told, Diablo 3 came out. The second Mongolian post is half-way finished, at least.

I'm doing a Kickstarter! The plan is to take git-annex and use it as the foundation to build a DropBox-like application, that can be used without any knowledge of git. The other part of the plan is for me to get through the summer with my finances intact. :) My Kickstarter page explains in more detail, but the basic idea is to make git-annex watch a directory, with inotify, and automatically add and sync files placed there. Then build a local web app to control and configure it. I have a working prototype of the inotify part already; getting the distributed syncronisation to work well will be a major challenge; and overall it's going to be a challanging but I think very achievable project. One thing I'm really excited about is the potential of Kickstarter to connect me with a diverse group of potential users, who are interested enough in a distributed and autonomous equivilant to DropBox to fund my project. Because, with luck, their involvement won't stop at giving some money, but will extend to actually using what I'm developing, and giving me feedback on it. I hope this will widen the sphere of git-annex users, beyond the current very technically inclined crowd. It's awesome to have users doing things like taking git-annex on the transiberian railroad to help manage all their photos, and others using it to store scientific data ... but getting more regular folks using git, even if they don't know about it, is something I'm very interested in. BTW, I was surprised how much I got into doing the video for the Kickstarter. Using xkcd-style drawings used to explain technical concepts is a medium I enjoy working in. My own git-annex is stuffed with 17 gigabytes of video clips -- 99 separate takes! -- that boiled down to a 2 minute video. Anyway, please consider backing me if you can, and more importantly, do anything you can to help spread the word. Thanks!

Puppet has a built-in functionality to serve small files to its clients. However, for my internal use I sometimes find easier to create a custom debian package to install a specific component then to write a puppet recipe and to copy files around. To create a local debian repository I use the package reprepro. This is a simple tool that creates and manages apt repository, it is easy to configure and for the moment it lived fully to my expectations. First of all you need to create a configuration file where you describe your distribution. In this case I choose /var/www/debian/conf/distributions and add the following content : Notice that since reprepro wants to sing you repository, you need to provide a gpg keyid for it. To add a package to the repository it is straightforward : As I said, since the repository is signed, we need to make have a way to add the keyid to the known keys of the target machine. In order to achieve this, we add the following puppet recipe : First we copy the keyid that we have stored in the puppet file bucket in the root directory of the client, then we exec the apt-key command. Note that since puppet executes each action in parallel, we must specify an execution order using the attributes subscribe and notify. Similarly as soon as the file /etc/apt/sources.list.d/puppet.list is added to the machine, we run apt-get update to refresh the cache of apt. The last stanza simply installs the package that we added to the local repository.

Puppet has a built-in functionality to serve small files to its clients. However, for my internal use I sometimes find easier to create a custom debian package to install a specific component then to write a puppet recipe and to copy files around. To create a local debian repository I use the package reprepro. This is a simple tool that creates and manages apt repository, it is easy to configure and for the moment it lived fully to my expectations. First of all you need to create a configuration file where you describe your distribution. In this case I choose /var/www/debian/conf/distributions and add the following content : Notice that since reprepro wants to sign your repository, you need to provide a gpg keyid for it. To add a package to the repository it is straightforward : As I said, since the repository is signed, we need to make have a way to add the keyid to the known keys of the target machine. In order to achieve this, we add the following puppet recipe : First we copy the keyid that we have stored in the puppet file bucket in the root directory of the client, then we exec the apt-key command. Note that since puppet executes each action in parallel, we must specify an execution order using the attributes subscribe and notify. Similarly as soon as the file /etc/apt/sources.list.d/puppet.list is added to the machine, we run apt-get update to refresh the cache of apt. The last stanza simply installs the package that we added to the local repository.

Update There is a better way to add a gpg key, that is to put it in the /etc/apt/trusted.gpg.d directory. Thanks for the suggestion !

Below are four of my (150!) browser tabs opened, that I oddly had in sequence. There has been much made of the pheonmen of lifelong learning and although I thought I had finished my exams when I finished University, I'm still doing them. From left to right:

Duolingo, where I am learning Spanish.

Quite a reasonable site, currently invite-only. My worry is my pronounciation will be crap though. I do wish that it did not have to use Flash to accomplish things though.

Udacity, where I am doing CS212 - Design of Computer Programs

Nice interface, annoying that it uses YouTube to host videos as that meant I had to whitelist YouTube in Flashblock.I picked this course as one of the other ones I wanted to do had already closed. I suspect I'll eventually do each of the courses they have on offer. One nice thing is that courses run every 8 weeks or so.

Codeacademy, I am currently doing their Codeyear course.

Well presented, but I find that their Javascript interface is extremely slow to startup. It consistently lags behind my typing speed by about 3 seconds.I'm using Firefox beta, so I'm always running something fairly fast and modern too.I'm primarily doing this course to see how/what they are trying to teach non-programmers. My feedback is that it is not geared towards someone with no programming knowledge. The initial 10 weeks of Javascript presentation proceeded at a very fast pace. If I weren't a programmer already, I'd have stuggled to keep up.

Coursera, here I am doing the Machine Learning class.

I'm not a fan of this interface at all, which is why I find it hard to come back to the site each week. I'm not sure exactly why though, since it uses WebM and no Flash. Hurray!!Either way, I'm doing the Machine Learning class. I tried this last time it was offered and got to week 5 same week I'm on now and then I got suddenly busy IRL, so was not able to complete the course.Unlike Udacity, courses run at set times and you have to do the work on the required dates in order to get the statement of attainment, which can be hard when you are juggling multiple things

Keep in mind, these are just the extra things I have decided to learn. I'm also learning more about Django, Puppet and Python in my work everyday. Plus I'm actually doing a Spanish course in real life too. Oh, and I have a job and I go out. I'm generally actually pushed for time. Which probably explains why I have not been keeping up with the blog. It isn't because I hate you, although it might be too ;-) , I'm just busy.

This weekend procps-ng version 3.3.3 was tagged and released for distribution. There have been many patches and fixes involved in this release as we move from an unchanging static sort of code into something that is easier to maintain and build on various architectures. The good thing is I m down to 1 or 2 patches in the debian archive which is a big change from the 30 or 40-odd I used to carry. For the sole metric of getting that number down, the project fork has been a success. There were some post-release bugs I found and these were more to do with the various options turned on or off rather than what you d see if you did the basic ./configure && make. One of them was how the version numbers are defined in git, but would only appear if certain files were older than others (such as aclocal.m4 versus config.h.in) Others were when certain features were turned on. The make check doesn t see all of this because it uses the default configure flags. One annoying thing of the autotools is conditionally installing man pages. This is where you don t or cannot compile a binary so you don t install the corresponding man page. The automake documentation is of course obscure about this but I cannot see a way of distributing only a man page, so we have this fiddle where a file goes into distmanMANS or EXTRA_DIST depending. Interestingly, there has been some bike-shedding around Fedora-land (see the link below) regarding the name procps-ng versus procps. Debian is lucky that we do have different upstream and package names (though not ideal) so apt-get install procps still gives you procps. There also has been discussion about merging procps-ng into util-linux whichin the short-term won t be happening.

Related articles

• Fedora 18 Approves Controversial Feature (phoronix.com)
• Change top Command Default Delay (technologiquepark.wordpress.com)

Linux version 3.4 has been released. This was a very active release for ASoC in framework terms, in addition to the usual bug fixes and so on there were a large number of framework enhancements though most are fairly small or are laying the groundwork for more user visible features like dynamic PCM.

• Support for widgets not associated with a CODEC, an important part of the dynamic PCM framework.
• A library factoring out the common code shared by dmaengine based DMA drivers contributed by Lars-Peter Clausen. This will save a lot of code and make it much easier to deploy enhancements to dmaengine.
• Support for binary controls, used for providing runtime configuration of algorithm coefficients.
• A new DAPM widget type for regulator supplies allowing drivers for devices that can power down unused supplies while active to do without any per-driver code.
• DAPM widgets for DAIs, initially giving a speed boost for playback startup and shutdown and also the basis for CODEC<->CODEC DAI link support.
• Support for specifying the number of significant bits on audio interfaces, useful for allowing applications to know how much effort to put into generating data for a larger sample format.
• Support for a range of new TI reference boards including Panda, configured from platform data so new boards can be added without driver changes.
• Conversion of the FSI driver used on some SH processors to DMAEngine.
• New CODEC drivers for Maxim MAX9768 and Wolfson Microelectronics WM2200.

Note: All of the information linked to from this post is in Spanish and related to Mexico Part of it will be translatable via automated means, some will not. Sorry, that's what I have, and it's too much text to invest the effort to hand-translate

I have been following the development of the different e-vote modalities in Mexico for several years already, although I have only managed to do so methodically in the last half year or so. If you are interested in my line of reasoning as to why I completely oppose e-voting, you can look at the short article I published in 2010 or the slightly longer and more updated version published in our book in 2011. Currently, in Mexico there are two different venues of e-vote that are being pushed: Bad and worse. The bad one will be carried out for about 10% of the population of the state of Jalisco and somewhat less for the state of Coahuila (Distrito Federal was also to be in this list, but the contract was cancelled due to the provider company delivering booths with too many problems and unable to deliver in the due time). The worse one is, fortunately, likely to have the least impact. Why? Because it regards votes cast by Distrito Federal residents (the capital entity, where part of Mexico City is located) living abroad. And it will have less impact because of the amount of the population registered for it: We are about 9 million residents in DF, and in the last election (first time IIRC there was the right to vote from abroad) there were only about 10,000 people registered for casting a (enveloped and sent by post) vote. Even if this year we the campaign for this was better (and I'm not yet sure about it), the number of voters will not be enough to make a dent on the results. I'm not going into details as to why it is bad in this post I requested information from the DF Electoral Institute (IEDF) with academic interest, to try to find more information about it, and I want to share my results with you and, of course, to request for your input on how to continue with this. On May 3rd, I sent the following request (this I am translating to English :) You can look at the receipt for the request for the original redaction) to the official contact address, oficinadeinformacionpublica@iedf.org.mx:

• What company was hired to develop the system that will be used to receive the votes from Distrito Federal citizens residing abroad that have decided to use the Electronic Voting over Internet procedure ("Vota chilango")?
• What is the technical information for said system? That is, which technological basis was it developed on? Which operating base (hardware) will it be deployed on?
• How many revisions or security audits has the developed system ben exposed to? Which are the entities in charge of doing them? What has been their evaluation?

Of course, I wasn't very optimistic when receiving this information. Still, I have to share my results: My information request was largely denied:

( )
III. The divulgation of this information harms the interest it protects
Given that, were it to be divulged it would affect the informatic security of the refered system. Anyway, we have to point out that said systems have enough measures and security provisions, so that the citizen can emit his vote in a universal, free, secret and direct way.
IV. The damage that can be produced by making this information public is larger than the public interest to know it
This is so because making this information public puts at risk the correct development of the Internet-based voting, because were the technical, purpose-specific information be made public, it could be misused to carry out informatic attacks.
It is also important to mention that a confidentiality agreement was signed with the company that developed said systems.
( )
VI. The time for the information to be reserved
It will be seven years starting at the present resolution, this information will be made public when the reserve period is over or when the target is reached, except for the confidemtial information that it could contain. ( )

In case some other person is interested in following this information, the other two points were answered, and I'll try to get some relevant information from it:

• The company that provided the Internet-based voting solution was SCYTL SECURE INTERNET VOTING, S.A.
• The only entity in charge of conducting a security revision/audit is Telef nica Ingenier a de Seguridad de M xico S.A. de C.V.. The audit is still in process, and thus it is not yet possible to give any results from it.

So, I don't have any real conclusions yet. I'm just reporting how work is unfolding. Tomorrow evening (Wednesday May 23) I'll give a talk on the "e-voting in Mexico 2012" subject in Congreso Internacional de Software Libre in Zacatecas, Mexico. I'll talk on the situation on this and the other topics I have been able to work on.

Attachment	Size
Receipt of my information request	11.64 KB
Transparency Committee resolution	354.66 KB
Information request answered by UTCSTyPDP (IEDF)	85.75 KB

I previously wrote about a failure of a USB flash device in my Internet gateway [1]. I have since had another failure in the same system, so both the original 4G devices are now dead. That s two dead devices in 10 weeks. It could be that the USB devices that I got for free at an exhibition were just really cheap, I m sure that they weren t expecting them to be used in that way. The devices from the same batch which are used for their intended purpose (sneaker-net file sharing) are still working well. But in any case I m not going to resume this experiment until warmer weather. At this time of year some extra heat dissipation from computer gear in my home is more like a feature and less like a bug. The second USB device to fail appeared to have it s failure in the Ext4 journal (the errors were reported at around sector 2000), I didn t keep a record of the problem with the first device, but from memory I think it was much the same. Rumor has it that cheap flash storage devices don t implement wear-levelling to avoid patent infringement. If that rumor is correct then any filesystem that uses a fixed journal in the same way as Ext3/4 is probably unsuitable for any serious use on such devices, while a filesystem based on Copy On Write will probably perform better. In Spring I ll try using BTRFS on cheap USB flash devices and see if that works better. I have another spare device from the same batch to test so I can eliminate hardware differences. I can t do enough tests to be a good statistical sample, but if a device lasts from Spring to Autumn using BTRFS with the same use that caused failures with Ext4 in a few weeks then I will consider it a strong indication that BTRFS is better than Ext3/4 for such uses. For the next 5 months or so I ll be using a hard drive in my Internet gateway system again.

• [1] http://etbe.coker.com.au/2012/04/08/flash-storage-update/

Related posts:

1. Flash Storage Update Last month I wrote about using USB flash storage devices...
2. flash for main storage I was in a discussion about flash on a closed...
3. USB Flash Storage For some years I have had my Internet gateway/firewall system...

John Scalzi recently wrote a piece on straight white male privilege. If you haven't read it already, go and do so. No rush. I'll wait.

So. Some facts:

• Women are underrepresented in free software development
  
• Those women who are involved in free software development are overwhelmingly more likely to have been subject to sexual harassment, belittling commentary or just plain ignored because of their gender
  
• When asked, women tend to believe that these two facts are fairly strongly related

(If you disagree with any of these then that's absolutely your right. You're wrong, but that's ok. But please do me a favour and stop reading here. Otherwise you'll just get angry and then you'll write something ill-tempered and still wrong in the comments and then I'll have to delete it and why not just save everybody the time and effort and go and eat ice cream or something instead)

I know I've said this before, but inappropriate and marginalising behaviour is rife in our community, and at all levels of our community. There's the time an open source evangelist just flat out told a woman that her experiences didn't match his so she must be an outlier. There's the time a leading kernel developer said that most rape statistics were basically made up. There's the time that I said the most useful thing Debian could do with its money would be to buy prostitutes for its developers, simultaneously sexualising the discussion, implying that Debian developers were all straight men and casting sex workers as property. These aren't the exceptions. It's endemic. Almost all of us have been part of the problem, and in doing so we've contributed to an environment that has at best driven away capable contributors. You probably don't want to know what it's done at worst.

But what people have done in the past isn't important. What's important is how we behave in the future. If you're not angry about social injustice like this then you're doing it wrong. If you're reading this then there's a pretty high probability that you're a white male. So, it's great that you're angry. You should be! As a straight white male born into a fairly well-off family, a native English speaker in an English speaking country, I have plenty of time to be angry before going back to my nice apartment and living my almost entirely discrimination-free life. So if it makes me angry, I have absolutely no way of comprehending how angry it must make the people who actually have to live with this shit on a daily basis.


The point isn't to be smugly self aware of our own shortcomings and the shortcomings of others. The point is to actually do something about it. If you're not already devoting some amount of your resources to improving fairness in the world, then why not? It doesn't have to be about women in technology - if you're already donating to charity or helping out at schools or engaging in local politics or any of the countless other ways an individual can help make the world a better place, large or small, then keep on doing that. But do consider that many of us have done things in the past that contributed to the alienation of an astounding number of potential community members, and if you can then please do do something to make up for it. It might be donating to groups like The Ada Initiative. It might be mentoring students for projects like the GNOME Outreach Program for Women, or working to create similar programs. Even just making our communities less toxic by pointing out unacceptable behaviour when you see it makes a huge difference.

But most importantly, be aware that it was people like me who were responsible for this problem in the first place and people like me who need to take responsibility for solving it. We can't demand the victims do that for us.

comments

PHPUnit, according to its PTS, has been in Debian since 2009. But it was orphaned, and nobody took care of it for a while. That is until few weeks ago, Luis Uribe started to work on it. Since he isn t a DD, and that I take care of, I believe, about half of the all the PHP PEAR packages in Debian, I started working with him on re-doing the work of packaging PHPUnit for Debian. Previously, the old version was quite wrong, with missing dependencies, and not really working, what a shame PHPUnit 3.6 has been in Debian SID for 3 days now. And it s working well. I m now adding runs of unit testings from upstream packages at build time (of course, only if DEB_BUILD_OPTIONS doesn t contains nocheck , as per the policy). All together, it s been quite some fun to hack this, and I m quite happy of the results, even though there s still a lot of work remaining. PHP itself is running unit tests at build time. And not just a few: more than 11000 of them. The only small issue, is that they are totally outdated. Over the time, the vardump() function has evolved, and doesn t print things the same way. One may say that it prints things in a nicer way, but as a result, many of the tests that were suppose to work, actually fails because of these differences in vardump() over time. So I started working on fixing some of the tests. It s most of the time very easy to fix, but it takes a long time to fix all these small unit tests. So far, I ve been able to fix most of what s in the tests/, Zend/tests (more than 161 tests fixed), and the beginning of ext/*/tests: for the moment: bcmath, bz2, calendar, curl, date, dba, dom, ereg, and a part of exif, which for the moment represent 214 fixed tests, and I ll try to do more fixes when I have time. I hope to send the patches upstream soon. The final goal is of course to have the build of PHP to fail if unit tests are failing as well. For the moment, unit tests do run at build time, but the build don t care of the results, which I think is stupid (it s wasting CPU cycles for no reasons, IMO). If you maintain some PEAR packages, I would welcome you to first join the PKG-PEAR team on Alioth, and team maintain your packages, switch over to pkg-php-tools and dh 8 auto-sequencer, and to follow the PKG-PHP-PEAR packaging guide lines so that we have consistency in the archive. And of course, run unit testings, by doing a build-depends on phpunit (>= 3.6). Note that unit testings in PEAR packages are tracked on the Debian wiki. This post is also a call for help, because I feel quite alone doing this work of packaging PEAR packages, which many PHP applications depend on (think about roundcube, horde, extplorer, and many more). Other teams are doing very well, like the Perl team, and there s no reason why Debian wouldn t maintain PHP libraries as well as the ones for Perl.

Sisyphus is a piece of software that I wrote as a member of a team from Jacobs University led by Prof. Dr. Andreas N chter. It managed to place our team first in this year's IEEE ICRA 2012 Virtual Manufacturing Automation Competition in all three rounds. The goal was, to stack a given set of boxes of different length, height and width on a pallet in a way that achieved optimal volume utilization, center of mass and interlock of the boxes. Besides the cartesian placement of a box on the pallet, the only other degree of freedom was a 90 rotation of the box around a vertical axis. Since the arrangement of boxes into a three dimensional container is NP hard (three dimensional orthogonal knapsack), I decided for a heuristic for an approximate solution. The premise is, that there are many boxes of equal height which was the case in the test cases that were available from the 2011 VMAC. Given this premise, my heuristic was, to arrange the boxes into layers of equal height and then stack these layers on top of each other. A set of boxes that would be left over or too little from the start to form its own full layer, would then be stacked on the top of the completed layers. There is a video of how this looked like. My code is now online on github and it even documented for everybody who is not me (or a potential future me of course). This blog post is about the "interesting" parts of sisyphus. You can read about the overall workings of it in the project's README. Python dict to XML and XML to Python dict The evaluation program for the challenge is reading XML files and the pallet size and the list of articles with their sizes are also given in XML format. So I had to have a way to easily read article information from XML and to easily dump my data into XML format. Luckily, all the XML involved was not making use of XML attributes at all, so the only children a node had, where other nodes. Thus, the whole XML file could be represented as an XML dictionary with keys being tagnames and the values being other dictionaries or lists or strings or integers. The code doing that uses xml.etree.ElementTree and turns out to be very simple: Lets try this out:

>>> from util import xmlstringtodict, dicttoxmlstring
>>> xmlstring = "<foo><bar>foobar</bar><baz><a>1</a><a>2</a></baz></foo>"
>>> xmldict = xmlstringtodict(xmlstring)
>>> print xmldict
 'foo':  'baz':  'a': ['1', '2'] , 'bar': 'foobar' 
>>> dicttoxmlstring(xmldict)
'<foo><baz><a>1</a><a>2</a></baz><bar>foobar</bar></foo>'

The dict container doesnt preserve order, but as XML doesnt require that, this is also not an issue. Arranging items in layers When it was decided, that I wanted to take the layered approach, it boiled down the 3D knapsack problem to a 2D knapsack problem. The problem statement now was: how to best fit small rectangles into a big rectangle? I decided for a simple and fast approach as it is explained in Jake Gordon's blog article. There is a demo of his code and should the site vanish from the net, the code is on github. This solution seemed to generate results that were "good enough" while simple to implement and fast to execute. If you look very hard, you can still see some design similarities between my arrange_spread.py and his packer.js code. Jake Gordon got his idea from Jim Scott who wrote an article of arranging randomly sized lightmaps into a bigger texture. There is also an ActiveState Code recipe from 2005 which looks very similar to the code by Jake Gordon. The posts of Jake Gordon and Jim Scott explain the solution well, so that I dont have to repeat it. Should the above resources go offline, I made backups of them here and here. There is also a backup of the ActiveState piece here. Spreading items out The algorithm above would cram all rectangles into a top-left position. As a result, there would mostly be space at the bottom and left edge of the available pallet surface. This is bad for two reasons:

1. the mass is distributed unequally
2. articles on the layer above at the bottom or left edge, are prone to overhang too much so that they tumble down

Instead all articles should be spread over the available pallet area, creating small gaps between them instead big spaces at the pallet borders. Since articles were of different size, it was not clear to me from the start what "equal distribution" would even mean because it was obvious that it was not as simple as making the space between all rectangles equal. The spacing had to be different between them to accommodate for differently sized boxes. The solution I came up with, made use of the tree structure, that was built by the algorithm that arranged the rectangles in the first place. The idea is, to spread articles vertically first, recursively starting with the deepest nodes and spreading them out in their parent rectangle. And then spreading them horizontally, spreading the upper nodes first, recursively resizing and spreading child nodes. The whole recursion idea created problems of its own. One of the nicest recursive beauty is the following function: get_max_horiz_nodes() traverses all branches of the tree that node has below itself and returns a tuple containing the list of nodes that form the branch that stretches out widest plus the list of nodes that are in the other branches (which are shorter than the widest). Another interesting problem was, how to decide on the gap between articles. This was interesting because the number resulting of the subtraction of the available length (or width) and the sum of the articles lengths (or widths), was mostly not divisible by the amount of gaps without leaving a rest. So there had to be an algorithm that gives me a list of integers, neither of them differing by more than one to any other, that when summed up, would give me the total amount of empty space. Or in other words: how to divide a number m into n integer pieces such that each of those integers doesnt differ more than 1 from any other. Surprisingly, generating this list doesnt contain any complex loop constructs:

>>> m = 108 # total amount
>>> n = 7 # number of pieces
>>> d,e = divmod(m, n)
>>> pieces = (e)*[(d+1)]+(n-e)*[d]
>>> print pieces
[16, 16, 16, 15, 15, 15, 15]
>>> sum(pieces) == m
True
>>> len(pieces) == n
True

You can test out the algorithms that arrange rectangles and spread them out by cloning the git and then running:

PYTHONPATH=. python legacy/arrange_spread.py

The results will be svg files test1.svg and test2.svg, the latter showing the spread-out result. Here is an example how the output looks like (without the red border which is drawn to mark the pallet border): arrange_spread2.py contains an adaption of arrange_spread.py for the actual problem. Permutations without known length When creating a layer out of articles of same height, then there are four strategies that I can choose from. It is four because there are two methods that I can either use or not. I can rotate the article by 90 per default or not and I can rotate the pallet or not. So every time that I build a new layer, there are those four options. Depending on which strategy I choose, there is a different amount of possible leftover articles that did not fit into any layer. The amount is different because each strategy is more or less efficient. To try out all combinations of possible layer arrangements, I have to walk through a tree where at each node I branch four times for each individual strategy. Individual neighboring nodes might be the same but this outcome is unlikely due to the path leading to those neighboring nodes being different. To simplify, lets name the four possible strategies for each layers 0, 1, 2 and 3. I now want an algorithm that enumerates through all possible permutations of those four numbers for "some" length. This is similar to counting. And the itertools module comes with the product() method that nearly does what I want. For example, should I know that my tree does not become deeper than 8 (read: no more than eight layers will be built), then I can just run:

>>> for i in itertools.product([0,1,2,3], repeat=8):
...     print i
...
(0,0,0,0,0,0,0,0)
(0,0,0,0,0,0,0,1)
(0,0,0,0,0,0,0,2)
(0,0,0,0,0,0,0,3)
(0,0,0,0,0,0,1,0)
(0,0,0,0,0,0,1,1)
(0,0,0,0,0,0,1,2)
(0,0,0,0,0,0,1,3)

This would work if the number of layers created with each strategy was the same. But as each strategy behaves differently depending on the input, it cannot be known before actually trying out a sequence of strategies, how many layers it will yield. The strategy (0,0,0,0,0,0,0,0) might create 7 layers, resulting in (0,0,0,0,0,0,0,1), (0,0,0,0,0,0,0,2) and (0,0,0,0,0,0,0,3) yielding the same output as only the first 7 strategies count. This would create duplicates which I should not waste cpu cycles on later. It might also be that (0,0,0,0,0,0,1,0) turns out to be a combination of strategies that creates more than 8 layers in which case the whole thing fails. So what I need is a generator, that gives me a new strategy depending on how often it is asked for one. It should dynamically extend the tree of possible permutations to accommodate for any size. Since the tree will become humongous (4^11 = 4194304), already traversed nodes should automatically be cleaned so that only the nodes that make the current list of strategies stays in memory at any point in time. This sounded all complicated which made me even more surprised by how simple the solution was in the end. Here a version of the algorithm that could easily be ported to C: It would be used like this:

>>> tree = Tree(4)
>>> print tree.next(), tree.next(), tree.next()
>>> while tree.reset():
...     print tree.next(), tree.next(), tree.next()

Which would be equivalent to calling itertools.product([1,2,3,4], 3). The special part is, that in each iteration of the loop I can call tree.next() an arbitrary amount of times, just how much it is needed. Whenever I cannot generate an additional layer anymore, I can call tree.reset() to start a new permutation. For my code I used a python specific version which is a generator: It is used like this:

it = product_varlength(4)
print it.next(), it.send(False), it.send(False)
while True:
    print it.send(True), it.send(False), it.send(False)

Again, the expression in the loop can have any number of it.send(False). The first it.send(True) tells the generator to do a reset.

While wtf(1) always has been a bit central to MirBSD, and the acronym database has been accessible by CVSweb, what we never had was a DAU compatible (and shellsnippets compatible) lookup. This has now changed: the above link to the acronyms file is a persistent link to its latest version (well, latest when the website was last recompiled), tooltips may very well follow soon, and we ve got an online WTF lookup service.
Contributions to the acronym database are welcome, of course; just eMail them to tg mirbsd org. Not to stop there, our online HTML manpage search is also new, shiny, and should replace the !mbsdman DuckDuckGo hash-bang shortly. (Both of these services offer a DDG search as fallback. Note that DDG is an external service included herein by linking, under their request to spread it, and not affiliated with The MirOS Project. They do, however, donate some advertising money to Debian.)
For all those who didn t know: only manpages for software in the MirOS BSD base system and for the MirPorts Framework package tools are listed, not for third-party applications installable using ports or, recently, pkgsrc . Still, if you want to have a peek at a modern classic BSD s documentation, you re welcome. (Not to mention content like re_format(7) and style(9) and that some of our documentation is much more legible than others.) And because writing all that perl(1) made me ill, not to mention I don t even know that language, I ve hacked a bit more in the mir make(1) and mksh(1) parts of the MirWebsite, finally implementing pointing out where in the navigation sidebar the visitor currently is. We also have exciting mksh porting news involving RT trying a larger number of ancient platforms than I dare count, me fixing bugs in Linux klibc and diving into other things, learning more about why I consider me lucky for hacking a BSD operating system sorry, I want to keep this short as it s mostly an announcement. The MirWebsite source code is, of course, also available. Improvements welcome. Except for these three CGIs, our website is fully statically precompiled, and that s a good thing. Please help in making the CGIs secure.

The Maker Faire is one of those awesome Bay Area things that always fills me with excitement and gets my imagination going. Zoe and I went again this year to check it out, as best we could within the time constraints we had to work within (opening time and her nap time, minus travel time). She definitely enjoyed herself. We took the Caltrain, because historically driving and parking has been a bit of a nightmare. The optimal train to get to get there before it opened (at 10am) was the 9:19 train from Mountain View, which was scheduled to get in at Hayward Park a little before 10am. It just so happened that there was a Giants game on in San Francisco today as well, and the train was absolutely packed. We only got a seat because one kind gentleman was getting off and explicitly gave his seat to us. One lesson learned: don't try and take the BOB stroller on the train. Even when collapsed, it's way too bulky. For future Caltrain outings, I'll take our City Mini stroller instead, as it folds much flatter. I also took our macpac Possum child carrier backpack, and Zoe was pretty happy to just sit in it for the bulk of the time. I think it had novelty value for her, as we haven't used it for a while. I probably could have gotten away without taking a stroller at all. I was very glad I took the backpack, as it gave her a much better vantage point for everything that was going on than she would have gotten from sitting in the stroller. There was supposed to be a free shuttle from the Hayward Park station to the Maker Faire, but there was a huge crowd waiting for it, so I decided to just walk. It didn't take too long. For the return trip, I think I exited from the wrong side of the fairgrounds, and couldn't figure out the shuttles, so I just walked to Hillsdale station. At least the return train wasn't crowded. Overall, using Caltrain to get in and out was successful. Zoe was very well behaved for the ~30 minute train ride each way. The Faire was quite a bit bigger this year, and has spilled out into the parking lot on one side. I'd heard stories that O'Reilly had quadrupled booth prices as well. Trying to abide by the program was too difficult, so we mostly just wandered through the main Expo hall and looked at various booths. I just did a full read through the website of all the exhibitors to see what I missed out on. Here's some of the stuff I saw in person, or discovered via the website:

• there was a really excellent looking Dalek running around (way better than the photo on the page linked to here). I also learned that there's a whole Dalek-making website. Awesome.
• RAFT (Resource Area For Teaching) had lots of really simple, low cost projects for demonstrating various concepts in physics and science.
• Linux for makers was represented
• This Arduino-controlled automatic fish feeder looked cool. I didn't get to see it in person, I discovered it while I was trawling through the list of exhibitors.
• Shop-in-a-box. I'd have liked to have checked this out.
• Build a bug habitat. I'd have liked to check this out out as well.
• Solar bike trailer. My Dad would have liked this, as he has an electric bike. I imagine this wouldn't be all that hard to make. The trailer looked pretty long from the photo though, but hey, no pedaling.
• The water causeway. Now this looks interesting. I would have loved to have seen this one in person. I love clean tech. There's a whole bunch of videos linked off the page for this.
• Wave energy capture model. Another clean tech thing I'd have liked to have checked out.
• Roominate looks really cool. Something for Zoe when she's a bit bigger.
• There was a table extolling the virtues of growing your own algae for consumption (as spirulina) and bio-fuel. I'm interested in finding out more about the latter.
• I saw some HEXBUG-related stuff near the Geekdad table. This looked like a dressed up version of the "take a toothbrush head and glue an electric toothbrush motor on the back" type project. I'm curious to see how expensive the kits are, as they looked like a lot of fun.
• Ratduino sounds intriguing, but I can't find out much about it.
• Urban scale wind turbines. One that I needed to have seen in person. Unfortunately I missed it.
• GlueMotor looks cool.
• Low-cost push-button clicker. I'd have liked to have found out more about this. If it's what I imagine it is, this could be quite revolutionary in the classroom.
• Hardware Startup Showcase. I have ideas. I'd like to see them get out of my head and into existence. Turns out there's even a MeetUp group.
• Kits by Kids. I'll have to check this out to see what sort of stuff I can do with Zoe when she's a bit older.

Kickstarter is really becoming huge in the maker community. There were heaps of exhibitors there with (mostly robotics) projects that were past the initial prototyping phase and were seeking funding on Kickstarter to go into mass production. Some of the talks I'd have liked to have seen:

• Every Child a Maker
• "Kickstarters," Equity and the New Maker Pro
• Making Professional Makers - Career Tech Ed Instructors Talk Shop
• Manufacturing Open Source Hardware - Get Your Stuff Made!

Zoe was really well behaved for the entire expedition. I don't think she really gave me any grief at all. There was a brief period where she wanted me to carry her, but I managed to negotiate her back into the stroller after not long. I think her favourite was ArcBotics, which had a robot insect that would dance and wave at her. She kept asking for it to do more dancing.

I will start linking to places we stayed at etc, from now on. On the one hand, we already left those places so my paranoid self can rest assured that no one will come hunt us down, on the other hand, I decided to only to name and link to those places which really deserve a mention. If they are linked here, I can whole-heartedly recommend them. Mongolia After leaving through the Russian border fortifications, Mongolia was an instant and welcome change. Trees growing right next to the tracks, branches forming a bit of a natural tunnel; the trains passing by keeping branches at bay, but the trees free to grow wherever else they pleased. A few hundred meters later below a rocky ledge, a cow had apparently fallen down and died. Partially decomposed flesh still clinging halfway to its rib-cage, it proved to be a sign of the (mostly) more laid-back attitude Mongolians tend to take. After finally getting our passports back and being allowed to leave the train, we first headed to the station to get some money. At ~1800:1, the exchange rate for Tugruk against Euro speaks volumes about inflation; imagine my surprise that the MNT 20,000 note is the largest one. It's also the one and only amount any and all ATMs will default to. We were quite surprised by how cheap everything was, even in the one single store within the station directly behind the border. In Russia, travellers expect to pay hefty markups when shopkeepers know they can charge them, not so in Mongolia. The woman in the trash Upon returning from the station, our waggon was just merrily being driving away on its own by a lone engine, something we had not anticipated or appreciated a whole lot. A woman (we hadn't noticed her before) who was busy scavenging a trash container for food for herself and her scrawny-looking son happily stopped what she was doing and, with a big smile, moved her hands around and smacked them back together, signalling us that our waggon would be attached to a different train for the subsequent journey. To put it mildly, I was stunned; we had met people eating from the trash in Russia as well (yes, I always make a point of giving them enough for a few decent meals; anyone eating out of the trash actually needs and definitely deserves something good happening to them), but they were glum and disheartened. Here, there was someone who not only had to look out for herself, but for a three or four year old boy as well, and still was just so... positive... I don't know if I would have it in me to act the same way... As an aside, even though we were just a few kilometers across the border from Russia, she did not actually take the money from me, she cupped her hands to receive it by having me place it into her hands; this is a very Asian thing in my experience and something we would see both in Mongolia and China consistently. Later, when we were back in our waggon, she passed by and happened to see the Spot Messgenger 2 dangling in front of our window, its lights blinking every five seconds. For a solid twenty minutes, until the train started moving again, she squatted down with her son, oggling the Spot. I have no idea what she was thinking it was and I had no chance to explain it to her, but she was really fascinated and just kept staring and staring. When we finally left the station, we waved to and smiled at each other, she ran after us, and then she was gone. All in all, this was one the more memorable things which happened to us. Mongolian Infrastructure When I say that Mongolians as a whole tend to be a lot more laid back than Russians, this extends to infrastructure as well, but not in the good way.

• Where Russia uses concrete sleepers, Mongolia uses roughly-hewn wooden ones.
• Where Russia has two rail tracks, Mongolia has a single one which is extended by parking spots to let other trains pass then and now.
• Where Russia maintains a perimeter along their rail tracks, Mongolia has a mainly gapless barbed-wire fence against animals on both sides; said fence may be near or far, covered with bushes or standing on its own. Its there so serve a purpose, but that's it. There's nothing else in ways of track protection.
• Where Russia has well-built, if dirty, crossings with one design spanning across all of Russia, Mongolia has random crossings that happen to look like they look.
• While Russia's streets are covered with potholes, Mongolia's are covered with potcaves.
• Some smaller stations didn't warrant a stop, but they couldn't be passed at full speed, either. Basically, if someone was waiting at the station, the train would come to a complete stop. At night, attendants would lean out of the train with flashlights, scanning the station and its surroundings for potential customers. If anyone was found, they signalled the driver and we would stop. Strange, but it works.

Ulan Bator Little Dhingis Khan We arrived in Ulan Bator at six in the morning and started haggling with taxi drivers. Our hostel had (stale, it turned out) information about acceptable fare from station to their place on their website, 5,000 MNT was supposedly OK. Our driver tried to get 20,000, then 15,000, then 12,000, then 10,000, went down to 7,000 and finally settled for 5,000, all this interspersed with frequent "no" by us and walking away. Once on the road, he wanted to convince me that we had agreed upon 5,000 per person, something that did not quite work out for him. When we arrived, he started to tell me that he was good friends with the hostel manager and that said manager would surely want us to pay more; again, that did not work too well. He made the mistake of getting our luggage out of his trunk immediately (we always kept all our stuff in the passenger area afterwards...) before I paid and even though I only had a 10,000 or 20,000 note, I insisted on correct change. The same old dance began anew, with him edging closer to the correct change in steps of 1,000 MNT. He tried to get away several times, but I stood in his door and held it open; if he had just driven off, I couldn't have stopped him, but that thankfully didn't occur to him. After he shoved all small change (MNT is bill only, no coins) he had with him at me and wanted to make off yet again, I was close to throwing all the small crap at him, but after he, a man of maybe 1.65 meter and sitting down, tried to signal his willingness for a fist fight and me, a man of 1.94 meter and standing started laughing, he gave me 2,000 more and drove off cursing. In case you forgot, at that exchange rate, we argued about two to three Euro, but as he tried to cheat, it became a matter of principle. The Hostel, part one All parking lots and other property in Ulan Bator have a small watchtower with private 24/7 guards; said guard ambled down, let us in and woke the poor woman who was forced to let us check in. As she was Mongolian as well, we were a bit surprised when she switched from broken English to perfect German, but the owners of the OASIS are a German-Austrian couple so I guess that makes sense. Fighting through the war Traffic in Ulan Bator is war. Lonely Planet talks about the city being too newly motorized and that it did not have to develop a culture of driving, yet. This is a euphemism for "no one has any qualms maiming or killing you". Everyone is driving like mad, nudging and racing their way in front of each other. If a driver has an oppurtunity to get ahead by a few centimeters with his small car, thereby blocking the way for several buses, making a whole parking lot grind to a halt and thereby deadlocking themselves, they will take said opportunity, and gladly. Red lights are gentle suggestions, there to be mainly ignored; police will not drive over red lights, but they will not stop anybody else from doing so, either. A hearse will have a dozen or more cars following it, all driving in a tight pack, aggressively attacking anyone who dares to wedge in between them and expecting all other traffic to make way even if they are driving over a red light. Crossing a main street in Ulan Bator as a pedestrian is hell. There are a few traffic lights and they help to some extent, but you still need to be extremely careful when crossing a street. Thailand, India, Russia, China, no matter where it's supposedly hard to cross a street by foot, I never had any issues weaseling through. In UB, it takes planning, determination, and a lot of attention, especially as there are stretches where there's not a traffic light in sight. While maintaining eye contact with a driver usually ensures that they will try not to hit you, this does not work in the least in UB. In the evening, I took to shining a high-powered flashlight at the ground to the oncoming traffic's side to mark ourselves and decrease the likelihood of being hit. This worked well in combination with sprinting through gaps in the traffic, except for one guy who actively aimed for us and did not slow down. He even changed lanes, just to keep us in front of his car... Shining the flashlight directly at him in highest mode made him break quite violently though; a good thing, as he may have hit us had he not slowed down. UB itself Ulan Bator is weird. It has clear signs of westernization, but it's still very much an old city. There is one large store which would fit into any random shopping center in Germany (which are tiny when compared to most other countries) and which carries most goods, if with a limited selection. Its supermarket is extremely well stocked with food and drink from all other the world and laughably cheap (for us) prices. While its infrastructure is definitely crumbling, the city is clean, especially when compared to Russia. Two girls from Stuttgart who we met during our Trans-Siberian travels commented on how clean Russian cities were when compared to home, but that may be more of a statement about Stuttgart than about Russia... Anyway, in Mongolia in general and in UB in particular, there's a concise effort to make what they have look nice and clean. There is no trash in the streets, loose gravel and earth is removed from the curb by dedicated workers, all areas of packed earth are sieved and all large stones removed. All in all, it's a lot cleaner (if more dusty and sandy) than Russian cities if somewhat older and more shabby-looking. That being said, Mongolia's countryside is littered There were several street stalls consisting of nothing more than a cardboard box on a stool selling single chewing gums and cigarettes from the original packaging; it's normal for people to buy one cigarette or one piece of chewing gum and walk on. The sights of UB were nice, but nothing too special. Outlook In the next part, I'll cover "The Hostel, part disaster" and generally talk more about excrement than I thought one could write before moving on to China (were I am located at the time of this writing).

I read a translated poem about Russia being "the Motherland" and its vast bosom years ago. Having driven through a significant part of it, I can agree on the "vast" part... Also, as I am on a train and without access to the Internet, I will refrain from linking to a lot of pages; sorry. (Turns out I am posting this a week later, but I will still not link to stuff now; no time). Russia in general

• All receipts you receive are torn before you get them; this is most likely due to the old Soviet voucher system, more on that below.
• Russia was hot with temperatures ranging from 27 to 32 degrees Celsius between Moscow and Ulan Ude.
• There aren't a lot of pedestrians bridges, but a lot of pedestrian tunnels. The sides of those tunnels are packed with tiny shops, often only two meters wide and 50-70 cm deep. Everything from stockings to candy over glasses to flowers and watches is being sold through a tiny window by some poor woman who somehow managed to get in there.
• Toilet brushes stand in water. In Germany, that's a sure sign of a really dirty toilet; in Russia, it's the thing to do. If you are lucky, there's blue cleaning stuff added to the water. If not, it will still have color. You are free to guess which.
• Queuing is war.

Moscow Sights Kreml Our remaining time in Moscow was spent with touring the usual suspects; the Kreml is a lot less impressive in real life, the Red Square is tiny when compared to the stories I heard about it and the Chapel ofi St. Basil is even more colorful and impressive in real life. Lenin's body was inaccessible because workers built seats for the May 9th parade to the left and the right of it and they apparently thought it would be a good idea to block access to one of the main tourist attractions while doing so. A river tour of Moscow was a nice cool-off and we got to see quite a few things. We managed to see the weekly military parade within the Kreml grounds, but it was mostly pomp and little substance. The National Treasure which you can access with an extra ticket within the Kreml grounds is nice, but less impressive than the tourist guides would make you believe. That being said... There's another museum within the museum and.... Whoah... Tourists pay extra, visitors go through the only non-security-theater check I encountered in Russia, guards are armed, people can only enter and leave in batches, and the stuff which is presented is mind-boggling. Disregarding the fist-to-calf-sized chunks of gold and platinum which are still in their original form directly from the mine, there is real, actual treasure galore. Little heaps of uncut and cut diamonds, an outline of Russia filled with cut diamonds and other random "we have this stuff" displays can be found as well. Then, you have various tiaras and other jewellery made from various gems. Not incorporating, but largely made of. All that pales in comparison to the crown, royal apple, scepter, etc. It's hard to put the amount of tiny multi-colored light points that shine at you into words. I was just standing there, swaying back and forth to catch the moving pattern of pinpoints. It's said that this collection is equalled only by the ones in the Tower of London and the one Shaw of Iran had and boy do I believe it. TV Tower Getting up there was funny. The old-style Soviet queuing system was used:

• Go to a counter to tell an attendant what you want; receive stub
• Go to another counter, hand over stub to another attendant, pay for what you want; receive voucher
• Go to third counter, hand over voucher; receive ticket for tower The whole thing was made even more absurd by the fact that counter one was in the middle, counter two to the right and counter three to the left. As Russians do not believe in queuing and everybody just tries to get in first, this made for a nice little exercise.

"Security" for approaching the tower was multi-level, the guards see you approach along a long walkway way in advance and the main guard shed had several small cabins separated by thick glass. So good so menacing. But in a twist that would make Bizarro and Garry Larson proud, I was required, by means of metal detector gate, metal detector wand and even an x-ray machine to remove every shred of metal and other hard objects from myself and the camera bag and put them onto a table. Once I was without anything except my clothes and the bag was completely empty, I could pass. Everything I had had to remove was just laying there, not inspected in the least, for me to stuff back into pockets and bag and to take with me. This "everything" included a Spot Messenger 2 with lots of green and red blinky lights. The guard did not even glance and it. Security theater? Security theater. The view from 364 meters down on Moscow was nice, but there was a lot of Smog so I couldn't see very far. Jumping on the glass floor while looking down was a lot of fun, though. Subway to Thiefing I bet Christopher Nolan rode the subway in Moscow at least once. That unnerving sound you hear during several key scenes in "The Dark Knight"? Two thirds of all subways make the same sound while moving. Also, I had an encounter with a pickpocket down there; very classical, too. Guy approaches quickly, talks loudly and sounds as if it's really important (in Russian... duh... that's sure to keep me interested). His approach made me turn and protect my left leg pocket automatically, most likely marking the target for the tiny woman standing behind me. Now, I have to tell you something about my usual travel layout. As my normal pockets are very deep, it looks as if their content was in the leg pocket. Plus, there's an extra, hidden leg pocket where I keep the passports and train tickets. The outermost leg pocket is protected by a velcro flap, but it contains nothing of value; usually the appropriate phrasebook, local map, maybe a tissue or chewing gum. Due to this layering, the outermost pocket looks as if it's full to the brim with stuff. Also, I took pains to make it a habit to protect said leg pocket with my hand, nothing else. This looks as if that's the target, but what I am actually doing is protect my normal pocket with my forearm. The right side is different, but the most easily accessibly pocket always holds some small change. I pay from that stash but my actual wallet is well out of reach. Anyway, once the guy ran off, talking to several others, most likely marking all them for the actual pickpockets, I wanted to enter the subway. While the Russian-style queuing took place, I felt an unusual tug at the velcro flap. I looked down and saw a tiny woman to the left of me with a jacket held over her right side with the left arm; I look up to check no one is trying to steal from my permanently assigned female, feel another tug, look the woman into the eyes, look up again and around me, look down again and she is gone. All that took maybe three seconds and I had boarded the subway after an additional two. In hindsight, it makes sense to choose the time of entry for attack. It's crowded, you are being pushed around, and once you are in the subway, it will start moving more or less immediately while the thief remains in the station. In this case, she would only have gotten a grubby map of Moscow's subway and an English-Russian phrasebook, but she got nothing at all. Moscow-Novosibirsk Where to begin... If you think a few hours on a train are a long time, try over fifty hours. Things get so bad, you start getting land-sick while not in a moving train. You even start missing the familiar tunk-cachunk, tunk-cachunk, tunk-cachunk... of driving over rails with gaps in them when you are not moving. The defining element of the Trans-Siberian Railway are birch trees. And birch trees. And then more birch trees. You would not believe how many birch trees there are. This is made "worse" by the way the Russian Railway protects their rails. Left and right of the track, there's a cleared area of maybe ten to twenty meters, sometimes as little as three. Outside of that, they plant ten to twenty meters of birch trees, presumably to catch snow during winter. Beyond that protective perimeter, there's the normal landscape.As a result, on top of the near endless stretches of birch woods, you see most if not all scenery through a layer of birch trees. You get sick sick of birch trees after a few hours and you see them for days on end. Bullet points to save myself some typing and you some reading...

• More than a thousand kilometers without a single hill. Flat as a pan.
• The whole route is powered by electricity. No diesel engines in sight.
• Many stations are little more than a heap of smoothed gravel, bordered by some wooden planks. Some stations have obviously been built by locals and are even less well-defined.
• You can see people in the middle of nowhere, walking along the railway tracks. At first this seemed counter-intuitive, but most if not all roads out there are dirt tracks. As there seems to be standing water across a third of Russia, this dirt is turned into mud. After walking maybe twenty meters across a parking lot, I had to scrape a heavy, thick cake of black earth from my soles. The railway is the only functioning footpath those people have. Many people even build shoddy bridges towards the tracks from their homes, obviously preferring to walk along the tracks over walking through the village.
• Railway crossings along the Trans-Siberian route, no matter how tiny, have a small cabin beside them. While the train passes, there's one guy or gal standing in said cabin, holding a yellow stick vertically out towards the train. Sometimes, you have not seen any living thing, other than birch trees, for twenty minutes and there, in the middle of nowhere right beside a dirt track, there's someone holding a stick out towards the train. Weird.
• Railway crossings of paved roads will always have two steel plates coming out of the ground, angled towards oncoming traffic on each side. This may not stop a heavy truck at full speed, but a car will disintegrate on these barriers without touching a passing train.
• The railways is important for Russia. Two parallel tracks cut across the whole country, transporting everything back and forth. Where "everything" means mostly coal and birch wood, I guess.
• All freight trains are usually 70 tanker waggons or 100 box waggons long, but you see the odd 100 tanker waggons, as well. You have more than enough time and opportunity to count them and then some.
• There are supposedly women at every station, selling what they cook at home. Unfortunately, this was only true for two stations. The things we did manage to get were very nice; I do wonder why anyone would offer (or buy) cooked and peeled potatoes, though.
• Every waggon has its own hot-water stove. They are powered by coal. Yep, you have a coal fire burning in every single waggon on the Trans-Siberian.

Novosibirsk The non-existent hostel We arrived at ~0200 local and made our way to the hostel we had booked a room with. Walking to the correct address, we saw several signs but they all turned out to be for a police station and some other state agency. We walked back, forth, double-checked, triple-checked: no hostel. We then walked around the building through some not-quite-nice back alleys, but other than a few entries to private flats, there was nothing. Thankfully, the booking slip included a number which we called and after at least twenty rings (no kidding), when I had given up and wanted to hang up, it stopped ringing. Dead silence. After maybe ten seconds, someone started talking in Russian. I asked him if he spoke English and told him that we could not find the hostel. He mumbled something about being sorry and that we should wait, he would come down. Fast forward a minute or two and someone walked towards us. Again, he mumbled about being sorry, that the hostel "did not work" at the moment and that we would need to sleep in his private apartment. He ushered us into some back alley entrance, into his flat, and proceeded to remove the sheets from the couch on which he had slept; after putting on new sheets, we had our "hostel" bed, ready to sleep on. We briefly considered if he would murder us in our sleep, but him and me even got to talking a bit. Over cheese, sausage and rum (at 0300), he admitted that the hostel did not exist and he merely planned to turn his flat into a hostel for the summer while he and his family moved into their summer house (the Russian term of which escapes me, at the moment) in the countryside. He had accepted our reservation as he thought he would be finished by that time. He did not even get started, though. While he sent us an overbooking notice through booking.com two days before, we were on the train at that time, so... booking.com even called him to check what happenend to us as we did not book another place through them. Good customer service/protection, that. Next morning, he didn't even want to take our money (we paid anyway) and, as a means of compensation, drove us into the city in the morning and to a train museum well outside the city limits, one of the fabled scientist cities, and a large lake which everyone in Novosibirsk claims is an ocean, in the afternoon. Foreigners, foreigners! All in all, Novosibirsk was relatively uneventful, safe for one bizarre episode. We took our lunch in a local fast food joint (why do all the good stories happen there, and not at the various truly local places?) and threw the cashier our well-rehearsed "Niet Russkie; anglisky?" with phrasebook in hand and he actually understood a few words of English (beef, chicken, fries). We told him, in our worst Russian, that we are from Germany wished him a nice day and went to sit down. A few minutes later, a girl approached us, literally hopping from one foot to the other and wringing her hands. She told us that the cashier had told her that we spoke English and if it would be OK if she talked to us. We suspected some sort of elaborate ruse, but went with it. Turns out, she had English at school and really wanted someone to practice English on. Two young men passed our table and exchanged a few words with her, sitting down out of sight. When she told us that she had to leave now but if it would be OK if the two boys joined us we suspected a ruse yet again. But those two were law students, one with a minor in English and one with a minor in German; both of them also extremely nervous, asking us if we would talk to them. When they had to leave, they told us that the three of them worked at the burger joint and that their shift was just about to start when the news that foreigners were here spread amongst staff like wildfire. The girl stopped by several times in between cleaning tables, getting in a sentence or two before being cussed at by her supervisor. All in all, this took about twenty minutes and seeing three people so nervous and grateful to talk with us felt beyond absurd. On the other hand, not a single traveller we met even considered stopping in Novosibirsk during their transit so there really does seem to be a shortage of non-Russians there. Weird, and memorable. Novosibirsk-Irkutsk

• Birch trees.
• Lots of burnt underwood, presumably to prevent larger fires.
• Birch trees.
• Sticky, stuffy, 30+ degree waggon with windows that could be opened but which were locked (this is why I always carry a Swisstool with me).
• Birch trees.

Irkutsk / Listvianka / Lake Baikal Listvianka Aah, lake Baikal... the oldest and deepest lake on Earth which holds a fifth of the global non-salt water reserves; a must-see in my book. Quad tours at break-neck speeds, dry-suit diving with Russian regulators, walking barefoot in between and across drift ice that made its way onto the shorei, and extended hiking around the lake's coast... All of which I could not do because I was ill and had to spend two solid days in bed. The draft from the open window in between Novosibirsk and Irkutsk was enough to give me a rather bad cold which peaked at Lake Baikal. Still, the area was lovely and we were glad to be out of a train and able to unpack our stuff without having to repack immediately for once. I am not sure where my current losing streak with regards to diving is coming from (Grimsey, diving north of the Arctic circle with birds that plummet into the water and hunt fish: Only guy who does this is on the Icelandic mainland that day; Svalbard, diving north of the Arctic circle in permanent darkness: The few people who do this privately did not reply while I was there; Baikal, oldest, deepest, largest lake on Earth: ill), but I will most likely return to Russia for a week of ice diving in Lake Baikal next winter or the one after that. As an aside, I saw several people walking to Lake Baikal with buckets to get their water. Other people got it from a well which was still half frozen. If you have running water consider yourself lucky... Irkutsk Nice city, largely uneventful. The farther east you get within Russia, the more normal women look. In Moscow, just as in Paris, they are way over-dressed and even service personnel will walk with high heels. Thankfully, I don't have to wear heels, but for the other males out there: Walking and standing in these things hurts and thus most if not all people who stand and walk for a living have flat shoes. We happened upon preparations for a military parade, complete with cordon, viewing podests, at least half a dozen TV cameras etc, but were not sure if it would start soon enough for us to catch our train.We asked someone who told us it would start at 2100 local, at 1945 local it seemed about to start, and sure enough at 1955 sharp, the whole thing went under way. About a dozen groups of 50-100 people each, all in their own, respective uniforms stood against one side of a cordoned-off street and several higher-ups on the other side. Two highest-ups shouted into microphones and the throng of people on the other side shouted back answers. Then, the two highest-ups stood in the back of a jeep each and drove past said throng, stopping in front of each group, shouting into microphones mounted in the back of the jeeps and the groups shouted back once again. After that, all groups marched around the make-shift plaza once, saluting the higher ups. Once they were done, and they took ages, two trucks drove by with soldiers jumping out of the moving trucks and moving into crouching positions. They ran around in a circle a few times and engaged in pretend hand-to-hand combat. I am sure they are skilled at whatever style they wanted to show, but they were overdoing things so badly, they were funny, not imposing. When they jumped over some barriers, the barriers fell to pieces and everyone scrambled to make it look as if that was part of the show. While carrying off the gear, it fell into further pieces which was even more funny. An armoured personnel carrier ended the show; several tougher looking guys jumped off of that one and their mock combat involved fully automatic fire (of blanks), several flashbangs, smoke grenades and, to top things off, the machine gun mounted on the APC moving down the opposing team with blanks. I never witnessed a "real" military parade in person but this one was somewhat disappointing. On the one hand, there was a distinct lack of ballistic missile carriers and tanks like you see in movies, documentaries and games, on the other hand, the whole thing had a make-do feeling to it. The cordoning police had designated spots to stand on, yet walked around. They were standing to attention, yet checking their cell phones. Several people in one uniformed group were wearing track suits and jeans. Another uniformed guy had a grocery bag with him; yet another one was carrying a huge water bottle. Bikers zig-zagged through the cordon and when the whole show was just about to wrap up the police finally started putting up barriers around the unmoving pedestrians, not blocking the bikers. One little girl was standing well within the cordoned area, watching with big eyes and after she did not react to the police talking to her, they just built the barriers in a curve around her. And to top it all off, some guy with a cane walked all through the parade with his personal camcorder, trying to direct the whole show while being ignored by everyone. Still, I am sure he managed to mess up some otherwise perfectly good TV scenes. Irkutsk-Russian border

• Diesel-powered trains.
• Single track most of the time with frequent stops to let other trains pass.
• Distinctively less developed cities, stations, streets, and other infrastructure along the road.
• 32+ degrees in our waggon.
• The train attendant was extremely unfriendly and just generally miserable even by Russian standards.
  • No toilet paper or towels at all on toilets.
  • While the other attendants made a point of presenting themselves well, he shuffled around in slacks all the time (not bad per se, but Russia is big on uniforms, so...)
  • He took all our tickets and stubs (including the ones not from this part of the journey) and kept them without comment. After we asked for them several times, he barked at us that we would get them back before Ulan Bator. Why? No idea...
  • He refused to let us exit the train during the very few stops. We were unable to exit through other waggons as the connecting door was locked. Being stuck in a train sucks.
• Border and customs took NINE HOURS!!! Stuck in blistering heat without a breeze, without access to a toilet, just waiting for bureaucracy to go its way. I checked all doors, we were locked into said waggon and there were no 'break glass to leave in emergency' windows. Especially nice as there's a coal fire burning in the hot-water stove and the whole train is plastered with warning signs about fire and what to do. In our case, presumably, burn to death; preferably without disturbing the attendant.
• The Russian stamp for entering Russia (by plane) has a plane on it, the departure one a train.
• The Russian side of the border is built like a fortress. There are several towers and bridges over the rails so trains can be checked from above, and reinforced holes dug into the ground in which soldiers stand and check the train from below.

TL;DR 3000 kilometers of birch trees