vi users have their . (dot) redo command for repeating the last command. The article Repeating Commands in Emacs in Mickey Petersen s blog Mastering Emacs explained Emacs equivalent for that, namely the command repeat, by default bound to C-x z. I though seldomly use it as I mostly have to repeat a chain of commands. What I use are so called Keyboard Macros. For example for the CVE-2011-3192 vulnerability in Apache I added a line like Include /etc/apache2/sites-common/CVE-2011-3192.conf to all VirtualHosts. So I started Emacs with all the relevant files: grep CVE-2011-3192 -l /etc/apache2/sites-available/*[^~] xargs emacs & To remove those Include lines again M-x flush-lines is probably the easiest way in Emacs. So for every file I had to call flush-lines with always the same parameter, save the buffer and then close the file or in Emacsish kill the buffer. So while working on the first file I recorded my doing as a keyboard macro:

C-x (

Start recording

M-x flush-lines<Enter>CVE-2011-3192<Enter>

flush all lines which contain the string CVE-2011-3192

C-x C-s

save the current buffer

C-x C-k<Enter>

kill the current buffer, i.e. close the file

C-x )

Stop recording

Then I just had to call the saved macro with C-x e. It flushed all lines, saved the changes and switched to the next remaining file by closing the current file with three key-strokes. And to make it even easier, from the second occasion on I only had to press e to call the macro directly again. So I just pressed e for a bunch of time and had all files edited. (In this case I used git diff afterwards to check that I didn t wreck anything by half-automating my editing. :-) Of course there are other ways to do this, too, e.g. use sed or so, but I still think it s a neat example for showing the power of keyboard macros in Emacs. More things you can do with Emacs Keyboard Macros are described in the EmacsWiki entry Keyboard Macros. And if you still miss vi s . command in Emacs, you can use the dot-mode, an Emacs mode currently maintained by Robert Wyrick which more or less automatically defines keyboard macros and lets you call them with C-..

Since there are probably going to be some questions about this in the near future:

The UEFI secure boot protocol is part of recent UEFI specification releases. It permits one or more signing keys to be installed into a system firmware. Once enabled, secure boot prevents executables or drivers from being loaded unless they're signed by one of these keys. Another set of keys (Pkek) permits communication between an OS and the firmware. An OS with a Pkek matching that installed in the firmware may add additional keys to the whitelist. Alternatively, it may add keys to a blacklist. Binaries signed with a blacklisted key will not load.

There is no centralised signing authority for these UEFI keys. If a vendor key is installed on a machine, the only way to get code signed with that key is to get the vendor to perform the signing. A machine may have several keys installed, but if you are unable to get any of them to sign your binary then it won't be installable.

This impacts both software and hardware vendors. An OS vendor cannot boot their software on a system unless it's signed with a key that's included in the system firmware. A hardware vendor cannot run their hardware inside the EFI environment unless their drivers are signed with a key that's included in the system firmware. If you install a new graphics card that either has unsigned drivers, or drivers that are signed with a key that's not in your system firmware, you'll get no graphics support in the firmware.

Microsoft requires that machines conforming to the Windows 8 logo program and running a client version of Windows 8 ship with secure boot enabled. The two alternatives here are for Windows to be signed with a Microsoft key and for the public part of that key to be included with all systems, or alternatively for each OEM to include their own key and sign the pre-installed versions of Windows. The second approach would make it impossible to run boxed copies of Windows on Windows logo hardware, and also impossible to install new versions of Windows unless your OEM provided a new signed copy. The former seems more likely.

A system that ships with only OEM and Microsoft keys will not boot a generic copy of Linux.

Now, obviously, we could provide signed versions of Linux. This poses several problems. Firstly, we'd need a non-GPL bootloader. Grub 2 is released under the GPLv3, which explicitly requires that we provide the signing keys. Grub is under GPLv2 which lacks the explicit requirement for keys, but it could be argued that the requirement for the scripts used to control compilation includes that. It's a grey area, and exploiting it would be a pretty good show of bad faith. Secondly, in the near future the design of the kernel will mean that the kernel itself is part of the bootloader. This means that kernels will also have to be signed. Making it impossible for users or developers to build their own kernels is not practical. Finally, if we self-sign, it's still necessary to get our keys included by ever OEM.

There's no indication that Microsoft will prevent vendors from providing firmware support for disabling this feature and running unsigned code. However, experience indicates that many firmware vendors and OEMs are interested in providing only the minimum of firmware functionality required for their market. It's almost certainly the case that some systems will ship with the option of disabling this. Equally, it's almost certainly the case that some systems won't.

It's probably not worth panicking yet. But it is worth being concerned.

comments

The sixth in a series; see also parts 1, 2, 3, 4, and 5. It s been about two weeks now since we got back home. Every few days, our boys still talk about Mexico. Jacob talks about what he will want to do when we go back and how he d like to see Jonathan over there again. Jacob, Oliver, and I look at photos from our trip a few times a week. This is all a sure sign that our boys loved the trip. And I keep trying to find Mexican food that tastes as good as the real thing (and, so far, failing). Another sign of a good trip! I think it is possible to have fun, relax, and enjoy new experiences all at the same time. We did that in Mexico. We had a lazy afternoon or two with the boys taking naps or playing with other children at the house we stayed at. And we stayed in a beautiful hotel without air conditioning, explored old downtown areas and ancient ruins, and bought things from crowded markets and people selling things from a table along a road. To anyone thinking about visiting: Go. Enjoy it, bring back memories, and live a little more serendipitously than usual. That s what I hope to do when we visit Greece before too long. Finally, here s a photo of the painting I bought from a roadside vendor for $17. Make sure to view it full screen. I think it says more about Mexico than 6 blog posts do.

I m listening to quite a few podcasts recently. Here are my current favourites:

• Cyberunions which covers the tech/work crossover space and is appearing as Ogg near the start of most weeks. I reviewed an earlier episode and it s kept on improving. It s under CC-BY-NC-SA, so you can share it, but it isn t free software (FOSS) itself. Thanks to John Atherton for the tip.
• The Command Line is more tech, but with a leaning towards activism too. This podcast is actually FOSS sadly the only one of this round-up! It s recently dropped to once a week on Sundays, which is a shame in one way, but suits me better. I don t remember how I got started on this.
• More or Less: Behind the Stats is about numbers in the news. Maybe my love of statistics influences me, but I think this is brilliant, puncturing the pompous politicians who try to mislead (figures don t lie, but liars do figure). Imagine the FactCheck Blog with its own show and a sense of humour. It s just gone on a break, but there s plenty of recent episodes to catch up on.
• Real Peloton is about pro cycling, by reporter-presenter Ned Boulting and journalist Matt Rendell. They probably should not be left alone to make podcasts, but it s great that they do. They appear sporadically, depending on other work schedules of the presenters. The Banjo Cycles team including Matt Rendell won the IG Markets Hot Lap during the final stage of the Tour of Britain in London and the world championships are this week so maybe they ll have something to say soon.
• Answer Me This appears on Thursdays (although it has just gone on a month s break) and gives right-but-sideways answers to listener questions.

And now for number six, what are you listening to? Anything you d recommend?

There are certian things haskell is very good at, and I had the pleasure of using it for one such thing yesterday. I wanted to support expressions like find(1) does, in git-annex. Something like:

git-annex drop --not --exclude '*.mp3' --and \
    -\( --in usbdrive --or --in archive -\) --and \
    --not --copies 3

So, parens and booleans and some kind of domain-specific operations. It's easy to build a data structure in haskell that can contain this sort of expression.

 - A Token can either be a single word, or an Operation of an arbitrary type. - 
data Token op = Token String   Operation op
        deriving (Show, Eq)
data Matcher op = Any
          And (Matcher op) (Matcher op)
          Or (Matcher op) (Matcher op)
          Not (Matcher op)
          Op op
        deriving (Show, Eq)

(The op could just be a String, but is parameterized for reasons we'll see later.) As command-line options, the expression is already tokenised, so all I needed to do to parse it is consume a list of the Tokens. The only mildly tricky thing is handling the parens right -- I chose to not make it worry if there were too many, or too few closing parens.

generate :: [Token op] -> Matcher op
generate ts = generate' Any ts
generate' :: Matcher op -> [Token op] -> Matcher op
generate' m [] = m
generate' m ts = uncurry generate' $ consume m ts
consume :: Matcher op -> [Token op] -> (Matcher op, [Token op])
consume m [] = (m, [])
consume m ((Operation o):ts) = (m  And  Op o, ts)
consume m ((Token t):ts)
          t == "and" = cont $ m  And  next
          t == "or" = cont $ m  Or  next
          t == "not" = cont $ m  And  (Not next)
          t == "(" = let (n, r) = consume next rest in (m  And  n, r)
          t == ")" = (m, ts)
          otherwise = error $ "unknown token " ++ t
        where
                (next, rest) = consume Any ts
                cont v = (v, rest)

Once a Matcher is built, it can be used to check if things match the expression the user supplied. This next bit of code almost writes itself.

 - Checks if a Matcher matches, using a supplied function to check
 - the value of Operations. - 
match :: (op -> v -> Bool) -> Matcher op -> v -> Bool
match a m v = go m
        where
                go Any = True
                go (And m1 m2) = go m1 && go m2
                go (Or m1 m2) = go m1   go m2
                go (Not m1) = not (go m1)
                go (Op o) = a o v

And that's it! This is all nearly completly generic and could be used for a great many things that need support for this sort of expression, as long as they can be checked in pure code. A trivial example:

*Utility.Matcher> let m = generate [Operation True, Token "and", Token "(", Operation False, Token "or", Token, "not", Operation False, Token ")"]
*Utility.Matcher> match (const . id) m undefined 
True

For my case though, I needed to run some IO actions to check if expressions about files were true. This is where I was very pleased to see a monadic version of match could easily be built.

 - Runs a monadic Matcher, where Operations are actions in the monad. - 
matchM :: Monad m => Matcher (v -> m Bool) -> v -> m Bool
matchM m v = go m
        where
                go Any = return True
                go (And m1 m2) = liftM2 (&&) (go m1) (go m2)
                go (Or m1 m2) =  liftM2 ( ) (go m1) (go m2)
                go (Not m1) = liftM not (go m1)
                go (Op o) = o v

With this and about 100 lines of code to implement specific tests like --copies and --in, git-annex now supports the example at the top. Just for comparison, find(1) has thousands of lines of C code to build a similar parse tree from the command line parameters and run it. Although I was surprised to see that it optimises expressions by eg, reordering cheaper tests first. The last time I wrote this kind of thing was in perl, and there the natural way was to carefully translate the expression into perl code, which was then evaled. Meaning the code was susceptible to security holes. Anyway, this is nothing that has not been done a hundred times in haskell before, but it's very nice that it makes it so clean, easy, and generic.

I searched forever for a way to just build the examples in the Android NDK, preferably from the command line. Here's how. First step: build the C++ code:

cd /usr/src/android-ndk-r6/samples/san-angeles/
/usr/src/android-ndk-r6/ndk-build

Simple enough. Second step:

You will then need to generate your final .apk through the usual means. -- Android NDK Dev Guide

Thanks a ****ing lot! In addition the documentation is very much Eclipse-centered - and I can't be bothered to install and configure all the Eclipse stack for a mere Java wrapper for the above-generated .so file XD We first need to use the 'android' wrapper and download the "SDK Platform Android 2.2, API 8, revision 3" - aka "android-8", the first environment to support OpenGL ES 2.

/usr/src/android-sdk-linux_x86/tools/android

It appears we first need to "manage the project", more precisely import from an existing project: http://developer.android.com/guide/developing/projects/projects-cmdline.html So we create a project by importing the sources from the current directory:

/usr/src/android-sdk-linux_x86/tools/android update project \
  --name san-angeles --path . --target "android-8"

Then we use ant to build the thing: http://developer.android.com/guide/developing/building/building-cmdline.html

apt-get install ant openjdk-6-jdk
ant debug  # avoid messing with signing

We now have a bin/san-angeles-debug.apk and we can run it in the emulator. Create a new "Virtual device" using the "android-8" platform we downloaded above, and launch it. Given the time needed to boot the OS, I suggest enabling snapshots. Scaling to display resulted in a very tiny, dark and slow display, in a first step I suggest using a non-scaled one.

/usr/src/android-sdk-linux_x86/tools/android

At last we can run it! Install it in the emulator:

/usr/src/android-sdk-linux_x86/platform-tools/adb install -r bin/san-angeles-debug.apk

You'll find a DemoActivity in your apps directory

---

Note: I tried to compile the "hello-gl2", showcasing OpenGL ES 2.0, but sadly it crashes:

Sorry! The application GL2JNI (process com.android.gl2jni) has stopped unexpectedly. Please try again.

The emulator apparently doesn't advertise EGL_OPENGL_ES2_BIT (checked in in GL2JNIView.java). If you try to by-pass it, you'll get loads of:

E/libEGL ( 333): called unimplemented OpenGL ES API

It's worth noting the OpenGLES20 sample from the "API Demos" application uses a fall-back OpenGL ES 1 renderer if v2 is not available - it made me mistakenly believe that OpenGL ES 2 was supported only from Java >( OpenGL ES 2 is not supported in the emulator as of 2011-09-17 - period.

A while ago I've been interviewed for a forthcoming article in the LinuxUser magazine on the topic of why there are so many Debian derivatives and on the potential impact, on them, of the (potential) advent of the so called "Debian Rolling" experiment. Below you can find my take on those topics. Questions are by Ferdinand Thommes, who has been involved in various Debian derivatives, including the forthcoming Siduction.

---

1.) Why do you think people base distributions on Debian? Looking at how many there is, since Corel and Libranet set sail in 1999, there must be a reason why, for one, people fork Debian in the first place, and secondly, why they choose Debian to do so and not some other distribution.

There are always advantages in creating a so called "derivative" distribution with respect to creating one from scratch. The main one is the possibility of reusing the packaging work which is already done in the "upstream" distro, focusing derivatives' efforts on customization, usually with clear target public in mind. Debian pushes most of those advantages (for derivatives) at their extremes.

• The Debian archive is huge (about 30'000 packages with Squeeze), meaning that the amount of packaging work that can be reused is similarly huge.
• Debian has a long history and a well established community, which reduces the risk of "betting" the efforts of derivatives on a distro that might disappear anytime soon.
• Debian is well known for its obsession with package quality, meaning that the risk of trusting pre-existing packages is greatly reduced, and that package behavior is on average very dependable as well as documented in standard documents such as the Debian Policy
• Debian is also well known for its obsession with licensing, at the point of being considered by many one of the authoritative sources for deciding what constitutes Free Software and what does not. For derivatives that implies that they do not need to worry---as long as they trust Debian, of course---neither about legal redistribution risks nor about software freedom claims on their distro.

But there are also a couple of "political" reasons for basing derivatives on Debian. One is quite subtle and applies mostly to commercial distributions. If you are designing one such commercial distro, you have to be based on an independent distro with no commercial interests, lest risking that petty (technical or otherwise) choices might be made just to undermine your business. Among "popular" GNU/Linux distros, Debian is essentially the only one which is both volunteer-based and not ascribable to any specific company. The last reason why I think many derivatives are based on Debian is our vocation to universality. Since we are not targeting any specific public, but rather trying to provide an operating system suitable for several different use cases (e.g. the tasks supported by the Debian installer or the choice of Debian Pure Blends), we offer an ideal starting point for those who are going to have customization as their main business.

2.) What could be the benefits for Debian and for its Derivates, if the discussions about a second Debian Release based on the Testing branch really come to be reality?

We are considering the possibility of adding a new Debian suite which is "rolling" like Testing, in the sense that new software releases flow in regularly rather than only at periodic bumps corresponding to major distribution releases. There seem to be user demand for that and I personally believe that such a scheme could address the needs of both advanced desktop users and of developers, which are now strand to mix and match Debian suites ending up using package combinations which benefit, as a whole, of very little quality check. The main issues to face to get there is how to make sure that adding such a suite would not get in the way of preparing high quality Stable releases, in terms of quality control, developer focus, etc. Note that such a hypothetical "rolling" suite needs does not necessarily need to be based on Debian Testing, although that is a good starting point. The reason why it's not a good endpoint is that Testing has been created (circa 2000), and is still used, as an internal tool to prepare the forthcoming Debian Stable release. As such, it is not entirely suitable for final user consumption. For instance, during the Debian "freeze" period the flow of new software releases that reach Testing is greatly reduced up to stopping completely just before the release of a new Debian Stable. I've been told that users of testing-based (derivative) rolling releases regularly complain about this aspect during Debian freezes, which is not surprising. The main advantage for derivatives which are already offering a Debian-based "rolling" release will then be the possibility of basing their work on a suite less bound to the life cycle of Debian Stable than Testing is at present. On the converse side, that would also mean that derivatives will need to differentiate more from Debian than by just saying they are "rolling", which is a good thing: differences among distros are healthy and drive innovation. With those derivatives, on the other hand, which will recognize their goals as being aligned with Debian's goals---Debian Stable today, maybe Debian "rolling" tomorrow---we will be happy to join efforts.

Two tiny bits:

• Thanks to Micha Lenk and after a fruitful discussion with Andrew Ruthven, you can finally find the Python bindings for Gnucash in the archive.
• If you want to check how your favourite package evolved over time: All historic build times and disk space information available in the Debian build logs are now imported into our database and are hence visible on log overview pages such as the insighttoolkit one.

Our friend Susan was going to be in Chicago for a conference, and as we hadn't seen Chicago yet, and it was on the list of cities we wanted to visit, we made the semi-spur of the moment decision to have a three day weekend there last weekend. We got the Virgin America red-eye flight from SFO, which left on Friday at around 5pm, and got into Chicago at around 11:30pm, local time. Zoe didn't do as well as she has previously, and didn't sleep very well on the flight over, despite us getting lucky and scoring an empty seat between us on an otherwise fairly full flight. I think she's getting too big to comfortably sleep in the Ergo baby carrier (or isn't keen on sleeping vertically any more). We stayed at the Swissotel, because that was where Susan was staying (and was where her conference was) and nearby hotels seemed to be around the same price range. When we checked in, we let them talk us into an upgrade to a larger room, which had fantastic views of Lake Michigan and the Chicago River. Lake Michigan is just mind-bogglingly big. It's an inland sea. What can I say? I was totally in love with Chicago. The weather while we were there was unbelievable. Clear skies. High 20's (Celsius). It was more humid than the Bay Area, but less humid than Brisbane. The first thing we did on Saturday was go visit a friend of Sarah's who lived in Bryn Mawr. We took the "L" there. The elevated train was an interesting affair, and turned out to be less accessible than we'd been led to believe from some light research in advance. In fact, I found Chicago in general to be fairly wheelchair (and by extension, stroller) unfriendly. We had to lug Zoe's stroller up and down stairs quite a bit to get from the river level to where the hotel was. Zoe seemed to find it amusing, at least. Aside from that problem, the city seemed pretty flat. I'm really glad that we got out of the city and into Bryn Mawr, because it was really great to see that aspect of Chicago life as well. Lovely, quiet, tree-lined streets with wide sidewalks. Beautiful buildings. Sarah's friend was fostering 8 kittens, so Zoe got to have a play with all of them, which she thought was pretty cool. After we returned to the city, Sarah and I kicked back in Millennium Park while Zoe napped in the stroller. Saturday, being 9/10/11 in US date format, seemed to be particularly popular for weddings, and there were a lot of couples getting wedding photos taken in the park. That night, we tried to have some deep dish pizza at Uno, the home of deep dish pizza, but the line was ridiculous. We subsequently learned about Due, and went there the following night. The pizza was good, and I found the crust to be slightly different from what we'd get at Patxi's. We checked out the Navy Pier on both Sunday and Monday, taking Zoe to the Chicago Children's Museum both days (we got free entry thanks to our membership at the Children's Discovery Museum of San Jose). We had grand plans of checking out the Shedd Aquarium, but it turned out that Monday was a "free for all Illinois residents" day, and the line at 11am was ridiculous, so we gave it a miss and took at water taxi back to Navy Pier. It was Zoe's first boat ride, and she enjoyed it. I got some unbelievably good photos of the city skyline from the boat. Our flight out was at 7pm, so we took the train to Midway. I was very impressed that we could get all the way to the airport by train for the standard price. I love flat-rate fares. I really love a city with good mass public transit. The only thing that detracted from this in Chicago was the accessibility issues. We explicitly went to the Orange Line Clarke/Lake station to go to Midway because it was listed as being wheelchair accessible, and we had a stroller and a suitcase. We ended up going up to the wrong platform, and getting across to the other side was a bit of a mission. We'd entered the station from the street level, took the elevator up, and then realised we were on the wrong side. We had to go back down the elevator to the level below the street, cross the street from underneath it, and then go back up the elevator on the other side. Aside from these sorts of shenanigans, the whole elevated train thing was pretty cool (but I wouldn't have wanted to have an apartment with the train line right outside my window). If only the cars had glass roofs, the Loop would have been a lot more scenic. Overall, it'd be hard to say whether I liked Chicago or New York City better. I liked the clean, flat nature of Chicago, the architecture and the lower density of buildings, but I also really love New York just because it's New York, and has an awesome (probably equally stroller-unfriendly) subway system. Photos from the trip are here.

So I decided, once the disk was in place, that the whole system should move to a RAID1 over the two disks. Basically this is not that hard as it may seem at a first glance, but I had some problems due to a new sector size in some recent harddisks, which is called Advanced Format.

1. Install mdadm with apt-get. Make sure to answer 'all' to the question which devices need to be activated in order to boot the system.
2. Partition the new disk (almost) identical.
   Because the new drive is somewhat bigger that wouldn't make sense, but at least the two partitions which should be mirrored on the second disk, need to be identical.
   Usually this is achieved easily by using

   sfdisk -d /dev/sda sfdisk /dev/second/sdb

   
   
   In this case, it wasn't that easy. But I will come to that in a minute.
3. Change the type of the partitions to 'FD' (Linux RAID autodetect) with fdisk
4. Erase evidence of an eventual old RAID from the partitions, which is probably pointless on a brand-new disk, but we want to be sure:

   mdadm --zero-superblock /dev/sdb1

   mdadm --zero-superblock /dev/sdb2

5. Create two DEGRADED raid1 arrays from the partitions:

   mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sdb1 missing

   mdadm --create /dev/md1 --level=1 --raid-devices=2 /dev/sdb2 missing

6. Create filesystem on the first raid device, which will become /boot.
7. Mount that filesystem somewhere temporary and move the contents of /boot to it:

   mount /dev/md0 /mnt/somewhere

8. Unmount /boot, edit fstab to mount /boot from /dev/md0 and re-mount /boot (from md0)
9. Create mdadm configuration with mdadm and append it to /etc/mdadm/mdadm.conf:

   mdadm --examine --scan >> /etc/mdadm/mdadm.conf

10. Update the initramfs and grub (no manual modification needed with grub2 on my system)
    and install grub into the MBR of the second disk.

    
    

    update-initramfs -u

    update-grub

    grub-install /dev/sdb

11. The first point to pray: Reboot the system to verify it can boot from the new /boot.
12. Create a physical volume on /dev/md1:

    pvcreate /dev/md1

13. Extend the volume group to contain that device:

    vgextend <volgroup_name> /dev/md1

14. Move the whole volume group physically from the first disk to the degraded RAID:

    vgmove <volgroup_name> /dev/md1

    
    
    (Wait for it to complete... takes some time ;)
15. Reduce first disk from the VG:

    vgreduce <volgroup_name> /dev/sda2

16. Prepare it for addition to the RAID (see step 3 and 4) and add it:

    mdadm --add /dev/md0 /dev/sda1

    mdadm --add /dev/md1 /dev/sda2

17. Hooray! Watch into /proc/mdstat. You should see that the RAID is recovering.
18. When recovery is finished pray another time and hope that system is still booting with it running from the RAID entirely. If it does: Finished :-)

There is some action taking place with the hardware vendors to move to a new sector size. Physically my new device has a size of 4096 bytes per sector. Somewhat different to the 512 bytes disks used to have the last decade.

Device Boot Start End Blocks Id System

/dev/sdb1 2048 291154 144553+ fd Linux raid autodetect

/dev/sdb2 291160 625139334 312424087+ fd Linux raid autodetect

Just completed watching Ireland-Australia. What could I say except "I knew they could make it"? This so Irish team won the fight against Australia and, of course, I'm happy. Let's dream for IRL-FRA in final...:) Oh, that Rugby World Cup in case you hadn't noticed and such a game is exactly why I like rugby.

Is there a syscall to ask the system whether a file is sparse in a particular region? I.e., if I say dd if=/dev/zero of=./foo seek=10 count=10, then I should get a "yes" for the first half of the file, but a "no" for the second half. Case in point: I need to write a test for the newly-implemented NBD_CMD_TRIM which uses fallocate with the FALLOC_FL_PUNCH_HOLE option to sparsify a file. kthxbye,

Triaging bugs is one of the easiest way to start contributing to Debian. I ll teach you the basics in this article. 1. Prerequisites All interactions with the Debian Bug Tracking System (BTS) happen through email so you need to have an email account with an address that you re willing to make public. All the mail that you send to the BTS will be archived and publicly available through its web-interface. This also means that you should have some spam filters in place because it will inevitably be harvested by spammers. To ensure that this email address is consistently used by the various tools that we re going to use, it s a good idea to put this email address in the DEBEMAIL environment variable. You can also specify your full name in DEBFULLNAME (in case you don t want to use the name associated with your Unix account). You usually do this by modifying ~/.bashrc (if you use bash as login shell):

export DEBEMAIL="hertzog@debian.org"
export DEBFULLNAME="Rapha l Hertzog"

You should also install the devscripts package, it provides the bts command that we re going to use. 2. Find a package or a team with too many bugs You can literally pick any popular software that s in Debian, they almost always get more bug reports than the maintainers can handle. Instead of picking a package, you can also select a packaging team and concentrate your efforts on the set of packages managed by the team. In any case, it s important to receive the bug traffic for the packages that you re going to work on. If you went for a specific package, you should subscribe to the package via the Package Tracking System (there s a subscribe box on the bottom left corner once you selected the source package of interest). If you decided to help a team, there s usually a dedicated mailing list receiving all bug traffic. You can browse a list of packages with the most bugs if you have troubles finding a package to work on. 3. Triage bugs! Bug triaging is all about making sure that bugs are correctly classified so that when a developer looks at the bug list, he can quickly find bugs with all the information required to be able to fix them! 3.1 Adding information to bug Adding supplementary information is easily done just by sending a mail to XXXX@bugs.debian.org (replace XXXX with the bug number). But often you want to reply to a message in the bug history, in that case bts --mbox show XXXX is for you. It will grab the corresponding mailbox and open a mailer (mutt by default) on it. Now you can directly reply in your favorite mailer. 3.2 Classifying bugs The Debian BTS uses tags (click the link and read the doc!) to classify bugs. bts tag XXXX + foo will add the foo tag (replace the + with a to remove a tag). If you want to explain why you re adding a tag, you should instead reply in the bug log as explained above, put control@bugs.debian.org in Bcc (Blind Carbon Copy) and start the body of your message with your tag command:

tag XXXX + foo
thanks

But what tag should you add? When a bug is submitted, you should try to reproduce the bug. If you can reproduce it, then tag the bug confirmed (example in #641710). If you can t, you should request more information (ex: a sample document triggering the bug, a configuration file, the output of some relevant command, etc.) until you can reproduce it or conclude that it was a user mistake. When you request supplementary information due to this, you should tag the bug unreproducible moreinfo (example in #526774). moreinfo should be later dropped when the requested information are provided, and unreproducible should be dropped if those information were enough to actually help reproduce the bug (example in #526774). During that initial evaluation, it s also worth differentiating packaging bugs (which are specific to Debian) from upstream bugs (which are relevant also for non-Debian users). The latter should be tagged upstream (and forwarded upstream if the bug is reproducible or contains enough information for the upstream developers, example in #635112). If you saw a (viable) patch in the bug log, the bug should be tagged patch . This is usually done by the patch submitter but sometimes it s forgotten (example in #632460). Take care though to not reinstate the patch tag if it was initially set but then dropped by the package maintainer after a review of the patch. If the title of the bug report is not descriptive enough, you can change it with a retitle XXXX new-title command (example in #170850). You can also change the severity of the bug report depending on the impact of the problem (with a command severity XXXX new-severity , what a surprise!). Request for new features are wishlist , most documentation problems are minor . On the other side of the scale, you can use important for bugs that are very annoying but that should not block a release. serious , grave and critical are used for release critical bugs, check the official definitions of the severities (examples in 502738 or #506498). 3.3 Closing non-bugs and bugs that are already fixed If your analysis of the bug report is that it s not really a bug but a user mistake, then you should close it by sending a mail to XXXX-done@bugs.debian.org with some explanations of the user s mistake so that he can get past his problem (example in #592853). If the problem was a real bug, but one that is apparently already fixed, you should try to quickly find the version that fixed the bug. If you can t find it in the changelog (there s a link to it in the PTS, or you can use /usr/share/doc/package/changelog.Debian.gz), you ll make the safe assumption that the upstream version you re currently using is the first one where this is fixed. Then you send a mail to XXXX-done@bugs.debian.org but you start your mail with Version: version-that-fixed-the-bug and continue with a small explanation of why you believe the bug to be fixed by this version (example in #122948). 3.4 Reassigning misfiled bug reports Bug reports are not always filed against the proper package. Users file bugs against applications where they experience the bugs, but the real bug might be in an underlying library or application. When that happens, you should use the reassign XXXX correct-package version command to get it filed against the correct package. The version parameter is optional but should be provided if possible, it should be the oldest version that we know to have the problem (example in #626232). 3.5 Forwarding bugs Forwarding bugs means opening bug reports in the upstream bug tracker for issues that have been reported in Debian but that applies to the upstream (unmodified) source code. Be sure to include all the relevant information and a link to the corresponding Debian bug. Depending on the upstream bug tracker, you might have to open an account to be able to file new bug reports. On the Debian side, you must record that a bug has been forwarded with bts forwarded XXXX upstream-bug-url . upstream-bug-url is the URL corresponding to the upstream bug report you created (ex: http://projects.ciarang.com/p/feed2omb/issues/21/ recorded in #609345 ). If the upstream authors fix the bug you reported, you can tag the Debian bug with fixed-upstream so that it s easier to find bugs to close when the next upstream release comes out (example in #637275). 3.6 Updating version information The Debian BTS uses version tracking to know which package versions are affected by a given bug. It s particularly important to have correct version information for release critical bugs since it might affect the migration of packages to testing. You can learn more on this topic here: http://wiki.debian.org/HowtoUseBTS. 4. More advice Colin Watson wrote a constructive rant explaining some mistakes that bug triagers are often doing. While it refers mainly to Ubuntu s launchpad, the advice apply equally as well to Debian. Check it out to become a better bug triager! Note that you can refer to this article with this shorter URL: http://raphaelhertzog.com/go/bugtriaging/

Do you want to read more tutorials like this one? Click here to subscribe to my free newsletter, you can opt to receive future articles by email.

One comment Liked this article? Click here. My blog is Flattr-enabled.

The fifth in a series; see also parts 1, 2, 3, and 4. One piece of advice we got in Mexico went like this: the nicer a place looks, the worse the food and prices will be. Roadside taco stands will be great, and nice-looking restaurants not so much. That seemed to be accurate. We only tried one real nice-looking restaurant and it was very good (though pricy), but it may have been sort of an exception. But perhaps the most interesting bit about eating in Mexico wasn t the food. It s the adventure. We ate one day at Guadalajara s San Juan de Dios market. In that huge labyrinth somewhere was a set of restaurants. They d tend to have a small cooking area, usually just open, and a few tables. We chose one. And at this point, I have to take brief detour and explain something. There are a lot of people in Mexico that do things for tips, and quite often without being asked. Some other examples might be washing a car s windshield at a stoplight. So anyhow, we had ordered our food, and before long, a guy wanders down the aisle and plonks down a boombox. And turns it on. And then he pulled out a microphone, which we quite soon realized was connected to the boombox. (I guess making it more of a karaoke box.) Anyhow, he started singing a song decently and seemed to be enjoying it. About 45 seconds into it, a competing boombox man plonked down a competing boombox 25 feet away, turned it on, and yes, you guessed it pulled out a microphone and started singing a different song. Worse than the first person but louder. Eventually the boombox people left and our lunchtime conversation could resume. But pretty soon a drum guy showed up. He had a bunch of drums on a strap so he could just walk around and play them. He apparently decided that an excellent place to play them would be directly behind my head. I did not entirely agree with his decision, but hey, it beat the competing karaoke guys. Eventually the drum guy left, and somehow between the time I looked down to get out money to pay our bill and the time I had it counted out, a clown had shown up and made several balloon animals for our boys. I tipped him, we paid, and then headed on. You might think from this story that this would be an annoying series of events. And honestly, if it had happened in a big mall in the USA, it would probably have been both annoying and creepy. But really I enjoyed it. The fact that dueling karaoke happened, despite sounding really awful, was pretty funny and really seeing this whole parade of people was interesting too. It made American restaurants seem a little boring. You always know what s going to happen here (and if something surprising does happen, the place probably gets a bad review on Yelp.) Interesting things sometimes happen at mealtimes in Mexico and I like it that way. I had a torta ahogada (drowned sandwich) at that restaurant. And at this point, another brief aside. I m the kind of person that can go to an average American restaurant, see items on the menu helpfully indicated as spicy, order one, and genuinely wonder if other people would find them spicy, because I either don t notice spiciness at all, or maybe notice a tiny bit if I concentrate really hard. Others, meanwhile, might take a bite and lunge for the water. Having said that, I know people that lived in Thailand for awhile and I have nowhere near their tolerance for spiciness. So, having been in Mexico a whole 24 hours or so, I decided not to follow Jonathan s wise lead in ordering a torta with the spicy sauce on the side. I figured I hadn t had anything spicy yet, so maybe this was would be nice and mild for me. Via Jonathan s translation, I ordered it with the spicy sauce. I believe the phrase I heard him use was con chile . The waitress looked at me, gave me an amused the American is ordering it con chile? Hahaha . sort of smile, and went off. Pretty soon our food arrived. (The food always seems to arrive pretty soon in Mexico, by the way.) Oliver was having a bit of a culture shock that day, and mostly refusing to eat (once hunger got the best of him later, he really enjoyed Mexican food.) But the rest of us dug in, including me. I enjoyed my torta. It was spicy, but not too bad. I took some big bites (it was, after all, a thick sandwich) and was really enjoying it. For about a minute. Slowest-acting spiciness I ve had in awhile. Then it hit me. Spiciness, and lots of it. I took a big gulp of my horchata (a creamy sweet rice drink that I found at many restaurants). That helped. A little. I really liked the torta and ate it, but it wouldn t surprise me if the waitress noticed how extremely quickly a drank my horchata Another interesting experience was in Guanajuato. It was raining as we walked towards the Guanajuato market. Their market was large and similar in concept to the Guadalajara one, though a lot smaller. The restaurants were all in a row, in a side of the building that was open to the outside. Most were on the ground level but it looked like a restaurant or two were upstairs. As we approached, all of a sudden people were yelling at us. First it was a guy on the second story, then pretty soon people at the restaurants on the first floor did so as well. They were yelling rapidly in Spanish, waving their menus around in the air. I m imagining they were naming foods they sold or reasons to eat there, but I don t know enough Spanish to know. As we walked down the long row of restaurants, the ones we left behind would quiet down in disgust and other hopeful restaurant owners would take up the yelling and waving cause. I imagine if we did some time-lapse videography and walked up and down that row, we could produce an effect not unlike the sound of a dot-matrix printer going back and forth on the page. Anyhow, we selected one of the quieter restaurants pretty much random. The others then quieted down until another person chanced to walk past at which point it would get loud again. The lunch there was good but I think I mainly will remember it for the selection process! On our way into Guanajuato, we stopped at a wonderful roadside taco place. In typical fashion, they had a large vertical pork thing (I don t know the proper word for it) from which they would carve off meat on the spot anytime someone ordered something with pastor. We found a table. And we ordered a few tacos and such. They were usually a few pesos each (working out to less than a dollar), small round things on a soft tortilla, with meat, cilantro, and onion on top. And typically delicious. They had very little in common with an American taco . We d often order a few, and if we wanted more, just order more. They were made quickly enough for that. Tacos were very similar from one restaurant to the next. My favorite flavors were pastor (pork), chorizo (sausage), and bistec (beef steak). A restaurant in Guadalajara sadly I ve forgotten its name, since we kept calling it the potato place had what I might call a Mexican version of the loaded baked potato, with a meat, queso (cheese), a delicious sauce with a flavor unlike anything I d had before, and some garnish. But really my favorite thing from that restaurant was their amazing juices. I am not much of a juice drinker normally, but in Mexico I went for them whenever they were offered. What passes as fruit juice in the USA has about as much resemblance to a real Mexican fruit juice as Taco Bell has to a real Mexican taco stand. (Very little, in case that wasn t crystal clear.) That particular restaurant offered three types of juices, which were, if I m remembering right, aguas, frescas, and jugos. I has a jugo verde (green juice) on the first visit there. It was good, but the one I can still remember was called, I think, the fresa fresca (fresh strawberry juice). And it was incredible. I m not sure how to describe it, other than real. One observation before I end. It seemed a common thread at some Mexican roadside taco stands to not have soap in their restrooms. Instead there would be a plastic cup holding I kid you not powder-form Tide laundry detergent. It was amusing anyhow. My hands left those places extremely soft and smelling like laundry. One of the last restaurants we visited on our trip was in Ajijic, near the Chapala lake. It was actually right on the lake and served seafood. This was the only restaurant with prices as high as I d be used to in the United States. I ordered a stew served in a stone bowl. It came out sizzling, and since the very thick stone bowl retains heat well, it kept sizzling the entire time I was eating. It was excellent as usual. Coming up in part 6: some thoughts on returning to the United States, our decision to visit, communication, and tips for anyone else considering a first visit to Mexico.

In this screencast, I implement a new feature in git-annex. I spend around 10 minutes writing haskell code, 10 minutes staring at type errors, and 10 minutes writing documentation. A normal coding session for me. I give a play-by-play, and some thoughts of what programming is like for me these days. <video controls="controls" src="http://kitenet.net/~joey/screencasts/git-annex_coding_in_haskell.ogg"></video> git-annex coding in haskell.ogg (38 MB) on vimeo Not shown is the hour I spent the next day changing the "optimize" subcommand implemented here into "--auto" options that can be passed to git-annex's get and drop commands.

There are several reasons why someone would want to build a custom kernel for their Android phone. In my case, this is because I wanted performance counters (those used by the perf tool that comes with the kernel source). In Julian Seward s case, he wanted swap support to overcome the limited memory amount on these devices in order to run valgrind. In both cases, the usual suspects (AOSP, CyanogenMod) don t provide the wanted features in prebuilt ROMs. There are also several reasons why someone would NOT want to build a complete ROM for their Android phone. In my case, the Nexus S is what I use to work on Firefox Mobile, but it is also my actual mobile phone. It s a quite painful and long process to create a custom ROM, and another long (but arguably less painful thanks to ROM manager) process to backup the phone data, install the ROM, restore the phone data. And if you happen to like or use the proprietary Google Apps that don t come with the AOSP sources, you need to add more steps. There are however tricks that allow to build a custom kernel for the Nexus S and use it with the system already on the phone. Please note that the following procedure has only been tested on two Nexus S with a 2.6.35.7-something kernel (one with a stock ROM, but unlocked, and another one with an AOSP build). Also please note that there are various ways to achieve many of the steps in this procedure, but I ll only mention one (or two in a few cases). Finally, please note some steps rely on your device being rooted. There may be ways to do without, but I m pretty sure it requires an unlocked device at the very least. This post doesn t cover neither rooting nor unlocking. Preparing a build environment To build an Android kernel, you need a cross-compiling toolchain. Theoretically, any will do, provided it targets ARM. I just used the one coming in the Android NDK:

$ wget http://dl.google.com/android/ndk/android-ndk-r6b-linux-x86.tar.bz2
$ tar -jxf android-ndk-r6b-linux-x86.tar.bz2
$ export ARCH=arm
$ export CROSS_COMPILE=$(pwd)/android-ndk-r6b/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-

For the latter, you need to use a directory path containing prefixed versions (such as arm-eabi-gcc or arm-linux-androideabi-gcc), and include the prefix, but not gcc . You will also need the adb tool coming from the Android SDK. You can install it this way:

$ wget http://dl.google.com/android/android-sdk_r12-linux_x86.tgz
$ tar -zxf android-sdk_r12-linux_x86.tgz
$ android-sdk-linux_x86/tools/android update sdk -u -t platform-tool
$ export PATH=$PATH:$(pwd)/android-sdk-linux_x86/platform-tools

Building the kernel For the Nexus S, one needs to use the Samsung Android kernel tree, which happens to be unavailable at the moment of writing due to the kernel.org outage. Fortunately, there is a clone used for the B2G project, which also happens to contain the necessary cherry-picked patch to add support for the PMU registers on the Nexus S CPU that are needed for the performance counters.

$ git clone -b devrom-2.6.35 https://github.com/cgjones/samsung-android-kernel
$ cd samsung-android-kernel

You can then either start from the default kernel configuration:

$ make herring_defconfig

or use the one from the B2G project, which enables interesting features such as oprofile:

$ wget -O .config https://raw.github.com/cgjones/B2G/master/config/kernel-nexuss4g

From then, you can use the make menuconfig or similar commands to further configure your kernel. One of the problems you d first encounter when booting such a custom kernel image is that the bcm4329 driver module that is shipped in the system partition (and not in the boot image) won t match the kernel, and won t be loaded. The unfortunate consequence is the lack of WiFi support. One way to overcome this problem is to overwrite the kernel module in the system partition, but I didn t want to have to deal with switching modules when switching kernels. There is however a trick allowing the existing module to be loaded by the kernel: compile a kernel with the same version string as the one already on the phone. Please note this only really works if the kernel is really about the same. If there are differences in the binary interface between the kernel and the modules, it will fail in possibly dangerous ways. To use that trick, you first need to know what kernel version is running on your device. Settings > About phone > Kernel version will give you that information on the device itself. You can also retrieve that information with the following command:

$ adb shell cat /proc/version

With my stock ROM, this looks like the following:

Linux version 2.6.35.7-ge382d80 (android-build@apa28.mtv.corp.google.com) (gcc version 4.4.3 (GCC) ) #1 PREEMPT Thu Mar 31 21:11:55 PDT 2011

In the About phone information, it looks like:

2.6.35.7-ge382d80
android-build@apa28

The important part above is -ge382d80, and that is what we will be using in our kernel build. Make sure the part preceding -ge382d80 does match the output of the following command:

$ make kernelversion

The trick is to write that -ge382d80 in a .scmversion file in the kernel source tree (obviously, you need to replace -ge382d80 with whatever your device has):

$ echo -ge382d80 > .scmversion

The kernel can now be built:

$ make -j$(($(grep -c processor /proc/cpuinfo) * 3 / 2))

The -j part is the general rule I use when choosing the number of parallel processes make can use at the same time. You can pick whatever suits you better. Before going further, we need to get back to the main directory:

$ cd ..

Getting the current boot image The Android boot image living in the device doesn t contain only a kernel. It also contains a ramdisk containing a few scripts and binaries, that starts the system initialization. As we will be using the ramdisk coming with the existing kernel, we need to get that ramdisk from the device flash memory:

$ adb shell cat /proc/mtd awk -F'[:"]' '$3 == "boot" print $1 '

The above command will print the mtd device name corresponding to the boot partition. On the Nexus S, this should be mtd2.

$ adb shell
$ su
# dd if=/dev/mtd/mtd2 of=/sdcard/boot.img bs=4096
2048+0 records in
2048+0 records out
8388608 bytes transferred in x.xxx secs (xxxxxxxx bytes/sec)
# exit
$ exit

In the above command sequence, replace mtd2 with whatever the previous command did output for you. Now, you can retrieve the boot image:

$ adb pull /sdcard/boot.img

Creating the new boot image We first want to extract the ramdisk from that boot image. There are various tools to do so, but for convenience, I took unbootimg, on github, and modified it slightly to seemlessly support the page size on the Nexus S. For convenience as well, we ll use mkbootimg even if fastboot is able to create boot images. Building unbootimg, as well as the other tools rely on the Android build system, but since I didn t want to go through setting it up, I figured a minimalistic way to build the tools:

$ git clone https://github.com/glandium/unbootimg.git
$ git clone git://git.linaro.org/android/platform/system/core.git

The latter is a clone of git://android.git.kernel.org/platform/system/core.git, which is down at the moment.

$ gcc -o unbootimg/unbootimg unbootimg/unbootimg.c core/libmincrypt/sha.c -Icore/include -Icore/mkbootimg
$ gcc -o mkbootimg core/mkbootimg/mkbootimg.c core/libmincrypt/sha.c -Icore/include
$ gcc -o fastboot core/fastboot/ protocol,engine,bootimg,fastboot,usb_linux,util_linux .c core/libzipfile/ centraldir,zipfile .c -Icore/mkbootimg -Icore/include -lz

Once the tools are built, we can extract the various data from the boot image:

$ unbootimg/unbootimg boot.img
section sizes incorrect
kernel 1000 2b1b84
ramdisk 2b3000 22d55
second 2d6000 0
total 2d6000 800000
...but we can still continue

Don t worry about the error messages about incorrect section sizes if it tells you we can still continue . The unbootimg program creates three files:

• boot.img-mk, containing the mkbootimg options required to produce a working boot image,
• boot.img-kernel, containing the kernel image,
• boot.img-ramdisk.cpio.gz, containing the gzipped ramdisk, which we will reuse as-is.

All that is left to do is to generate the new boot image:

$ eval ./mkbootimg $(sed s,boot.img-kernel,samsung-android-kernel/arch/arm/boot/zImage, boot.img-mk)

Booting the image There are two ways you can use the resulting boot image: one-time boot or flash. If you want to go for the latter, it is best to actually do both, starting with the one-time boot, to be sure you won t be leaving your phone useless (though recovery is there to the rescue, but is not covered here). First, you need to get your device in the fastboot mode, a.k.a. boot-loader:

$ adb reboot bootloader

Alternatively, you can power it off, and power it back on while pressing the volume up button. Once you see the boot-loader screen, you can test the boot image with a one-time boot:

$ ./fastboot boot boot.img
downloading 'boot.img'...
OKAY [ 0.xxxs]
booting...
OKAY [ 0.xxxs]
finished. total time: 0.xxxs

As a side note, if fastboot sits waiting for device , it either means your device is not in fastboot mode (or is not connected), or that you have permissions issues on the corresponding USB device in /dev. Your device should now be starting up, and eventually be usable under your brand new kernel (and WiFi should be working, too). Congratulations. If you want to use that kernel permanently, you can now flash it after going back in the bootloader:

$ adb reboot bootloader
$ ./fastboot flash boot boot.img
sending 'boot' (2904 KB)...
OKAY [ 0.xxxs]
writing 'boot'...
OKAY [ 0.xxxs]
finished. total time: 0.xxxs
$ ./fastboot reboot

Voil .

The fourth in a series; see also parts 1, 2, and 3. This post is going to be more a photolog than a narrative, and I apologize in advance for it being a bit disjointed. I ve already touched on these themes a bit in the other post, but now it s time to focus on them. Immediately after leaving the airport, it s quite clear that things are a little different. Trees are square. People ride around in the backs of pickups sometimes on top of piles of debris. Left turns are made in front of other lanes of traffic going the same way. But those are just the things obvious from the road. It s a lot of fun to enjoy the differences. First, the ubiquitous square trees. They look pretty, and are found all over. I also found carefully-manicured trees in cone shapes, more cylindrical shapes, etc. It seems that tree care is taken seriously in Mexico. It was also not uncommon to see the bottom few feet of a tree painted white. A park in Guanajuato had a whole bunch of trees carefully trimmed. And from up on the mountain, it still looked impressive (the green area behind the dome). Driving in Mexico was interesting for a lot of reasons. The highways there aren t quite as limited access as the freeways in the USA. It was quite common to see bicyclists, walkers, a mule, or some cattle ambling along the side of the road. Roadside taco stands don t require taking an exit. You just pull off the road because it s right there. Some sights were a bit surprising. Cattle in a pickup, with rope, for instance. Or cattle crossing the highway on the overpass. Street vendors were everywhere. Stop at a red light and someone might spring from the side of the road and suddenly start washing your windshield (expecting a tip); try to sell you flowers, juice, or bug zappers; or even throw business card-sized advertisements for adult websites into any open windows they can find. One night we saw an incredible fire juggler. I would have tipped him well but he was too far away to do so before the light turned green. Mexico s history stretches back into prehistoric times, and we saw the Teuchitlan ruins at Guachimontones one day. It was truly a remarkable feeling to be able to walk down the middle of the ancient ball court, or to climb up one pyramid and see the other from it. It s not exactly architecture, but Jacob and Oliver sure enjoyed visiting the hot springs at Bosque de la Primavera. Jacob still remembers that where the steam is, the water is 200 degrees, and we CAN T TOUCH IT THERE! Back in Guadalajara, here s a photo from the inside of the grand old cathedral. Compared to the cathedrals we saw in Europe, this was of a similar general size and design, and perhaps only slightly newer. But one big difference: worshipers outnumbered tourists at every Mexican cathedral I saw, whether in the center of Guadalajara or at a rainy intersection in Guanajuato or a plaza in Tlaquepaque. It made them feel more alive, and perhaps more sacred as well. One surprise was seeing people sitting on the steps of the cathedral in downtown Guadalajara selling trinkets such as beads. I think the only other place I had seen something like that was in New Orleans. All of Guadalajara s Centro was beautiful. Much of it survives from colonial days; I think a person could spend days exploring its museums and buildings. Way too many of my 900 photos were taken in Centro to post on the blog, but just for flavor, here s one of the less than historic scenes. Yes, that is a bus shaped like a tequila bottle. Fountains were beautiful and common across Mexico. A few of them were easily reachable by boys, and ours sure loved those. There was a lot of public art, including this interesting chair/skeleton/I m not sure what it is: And, just for good measure while walking around Centro, they tossed in an apparent Redundant Array of Inexpensive Typewriters. I don t know what they were doing, but there were about a dozen guys sitting out in the sun typing on their manual typewriters on their identical tables. And who can leave Guadalajara without seeing one of North America s most impressive traffic circles. I ve got to hand it to the Mexicans for making something that is normally really boring into an interesting work of art. Over in Guanajuato, a lot of driving takes place in the city s vast underground tunnel system. Here s a scene emerging from one of them. Guanajuato was already getting decorated for Mexican independence day festivities (Sept. 15-16) while we were there. Here s a typical Guanajuato street scene. Many of the streets were closed to traffic and perhaps not wide enough to handle vehicles anyway. Those streets had a wonderful peaceful and slow feel to them. I feel that I ve barely done the trip justice with this post. The feelings of walking down a beautiful Guanajuato street, or stepping into a Spanish cathedral, or even seeing a bunch of guys with typewriters, just can t be replicated. It s brimming with history and character, and shouldn t be missed.

Using plain C arrays of coordinates, instead of Vertex Buffer Objects, confused some readers. I did it so that the very first tutorials would be simpler. However, it also appears that plain C arrays are not supported at all starting with OpenGL 3.0. Plus, specifying offsets is done differently in each case, and people will use VBOs in the end for performances. So the basic tutorials are now rewritten to use VBOs It took me longer than expected!

http://en.wikibooks.org/wiki/OpenGL_Programming#The_basics_arc

I must admit that I m a bit lost about the conclusions of the Don t fear the fsync()! (lf.org down; google cache) debate. My understanding was that using fsync() was the right thing to do when we cared about data being written to disk. When using cp or tar, I usually care about my data being written to the disk, so why don t they use fsync()? Shouldn t they?