If you demand respect, you don't deserve it.

Many moons ago while doing fieldwork I went to a radical tech activist camp sponsored by The Ruckus Society to give a presentation on Free Software (which I actually still have online in the gaudy orange I so loved. I could only stay 2 days as I had to go to Debconf2 in Toronto for fieldwork but it forever changed my life in pretty significant ways. One remarkable thing about Ruckus was that for the first time I meet a particular kind of geek I had yet to come across: the crunchy and chewy granola/environmentalist/hippie hacker– a type of hacker that can be found world over but is likely to be (unsurprisingly) living, sometimes in the trees (literally) in the Pacific Northwest. They are one of my favorite kind of people as I can talk endlessly to them about 2 of my great passions: Free Software and environmental justice. Comfrey, pictured above, was one such hacker from Portland who I met at the Ruckus event and now routinely shows up, usually unannounced to our house at least 1-2x a year. I woke up this morning to find him on our couch, got a bunch of knot-weed to chew on compliments of his foraging, and took the afternoon off to share some food. Among many stories, he told me of a new transportational pursuit of his, Roller-Hitching, which he uses to get around the country. He uses old school roller skates to skate along the road, even highways, until he gets picked up and get where he needs to go. Naturally, these old school states are not just functional in the sense that they are faster than two feet in motion, but since they signify a particular spirit of the 1970s–you know, the groovy, dynamite, free love spirit of things, they draw positive attention and apparently when he roller-hitches, he gets picked up frequently (and made it from Minneapolis to Portland in 2 hours and 2 days: not shabby). In California while on the 101 north of Arcata, California, Comfrey got stopped by the highway patrol and basically the cop wanted to kick him off on the grounds the he was a pedestrian (apparently prohibited on this patch of the 101). Comfrey, being a bright fellow, basically noted that roller skating is not really a pedestrian activity, that he was using, much a like a biker, a transportation device of sorts, so that he was in a grey zone between bikes and walking. At the time, the cop was convinced enough but did tell Comfrey to look up the law in the library cuz the next time he would give him a ticket and the next time after that throw him in jail. Comfrey has yet ’sourced’ the law but soon will. When he does, since I like to report on geeks and the law, I too will report on whether one can roller skate down or up the highway for those that might want to give Roller-Hitching a try.

This is the gist of it: $ cd /usr/src/ # $ sudo chmod a+rwx . $ wget ftp://ftp.suse.com/pub/projects/kernel/kotd/SLE11_BRANCH/src/kernel-source-2.6.27.39-0.0.0.25.15a4c6f.src.rpm $ alien -tg kernel-source-2.6.27.39-0.0.0.25.15a4c6f.src.rpm $ cd kernel-source-2.6.27.39 $ tar xfj linux-2.6.27.tar.bz2 $ for f in patches.*.tar.bz2; do tar xfj $f || break; done $ for p in $(./guards x86_64 patch -d linux-2.6.27 -p1 done $ cd linux-2.6.27 $ fakeroot make-kpkg debian $ fakeroot make-kpkg build $ sudo make install modules_install $ cd /usr/src $ hg clone http://xenbits.xen.org/xen-unstable.hg $ cd xen-unstable.hg/unmodified_drivers/linux-2.6 $ XEN=/usr/src/xen-unstable.hg/xen XL=/usr/src/kernel-source-2.6.27.39/linux-2.6.27 ./mkbuildtree x86_64 $ make -C /usr/src/kernel-source-2.6.27.39/linux-2.6.27 M=$PWD modules $ sudo make -C /usr/src/kernel-source-2.6.27.39/linux-2.6.27 M=$PWD modules_install //

[Russell Coker writes about shellscripts. I have a different suggestion. Whenever you think that a shellscript is the right solution to a problem, you are mistaken: do it in a proper scripting language instead. Having access to proper data structures will mean you don't have to contort your code to fit values into scalar strings, or write loads of temporary files, or call cut/awk/sed/grep etc. repeatedly on the same inputs to get at different fields, etc. etc. etc. I reckon nine times out of ten it's the right decision. But when you just have to use a shellscript, use set -e (as Andrew Pollock points out, this is safer than putting it on the hashbang line) and set -u too.

I've really enjoyed reading some of Matthew Garrett's entries about legacy PC hardware features - specifically the cute hack involving A20 and the keyboard controller. Reading things like that really takes me back. I remember when the z80 was cutting edge, and I discovered you could switch to a whole new set of shadow registers via "exx" and "ex af,af'". I remember using undocumented opcodes, and even now I can assemble and disassemble simple z80 machine code. (Don't get me started on the speedlock protectors and their fiendish use of the R register; that'll stick in your mind if you cracked it. I did.) I remember being introduced to the PC, seeing subdirectories appear in MS-DOS 2.0, network redirectors appearing in DOS 3.x, and support for big hard drives appearing in MS-DOS 4.0. I remember the controvosy over the AARD code in the betas of Windows 3, and the focus that was given in the book "Undocumented DOS" which mostly focussed upon the "list of lists". (At that time I'd have been running GEM on an IBM XT with hercules (monochrome) graphics.) I remember learning about that a .COM file was a flat image, limited to 64k which loaded at offset 100h, to accomodate the PSP (program segement prefix) for compatbility with CP/M (something I've never seen, never used, and known nothing about. I just know you could use the file control blocks to get simple wildcard handling for your programs "for free") I wrote simple viral code which exploited this layout, appending new code to end of binary, replacing the first three bytes with a jump to the freshly added code. Later you could restore the original bytes back to their original contents and jump back to 100h (I even got the pun in the name of 40Hex magazine.) I recall when COM files started to go out of fashion and you had to deal with relocation and segment fixups. When MZ was an important figure. I even remember further back to when switching to protected mode was a hell of tripple-faults, switching back from protected mode to real mode was "impossible" and the delight to be had with the discovery and exploitation of "unreal mode". All these things I remember .. and yet .. they're meaningless to most now, merely old history. Adults these days might have grown up and reached age 20 having always had Windows 95 - never having seen, used, or enjoyed MS-DOS. How far have we come since then? In some ways not far at all. In other ways the rise of technology has been exponential. Back then when I was doing things I'd not have dreamed I could update a webpage from a mobile phone whilst trapped upon a stalled train. There are now more mobile phones than people in the UK. In some ways that's frightening - People miss the clear seperation between home & work for example - but in other ways .. liberation. I have no predictions for the future, but it amazing how far we've come just in my lifetime; and largely without people noticing. The industrial revolution? Did that happen with people mostly not noticing? Or was there more concious awareness? Food for thought. ObFilm: Terminator

Such was the scene I arrived at on Wednesday last week at the municipal health center at Kyllö, Jyväskylä, Finland. A queue extended a hundred meters beyond the door. It was not hard to guess what it was about, as it had been announced that the pandemic influenza A/H1N1 vaccine would be administered there to people in specific risk groups from 10 am to 3:30 pm. I should explain here the Finnish health care setup. There are three parallel systems – a comprehensive public health care system maintained by the municipalities to standards set by the state, a network of private for-profit health care providers, and a national foundation dedicated to university student health care. Employers are required by law to provide a minimal level of health care to their employees, and most of them also provide, free of charge to the employees, access to near-comprehensive general-practice-level care; most employers buy this service from the for-profit providers. The public system suffers from resource starvation at the general-practice level but provides excellent care in the central hospitals that handle the difficult cases. Anyway, the H1N1 vaccine is only available through the public system and through the foundation – free of charge if you qualify for the vaccine, and no amount of money buys it for you in this country if you don’t. Thus, I and many others, normally cared by the employee services, found ourselves queuing up at a public health care institute. And clearly, the public health care system was overwhelmed on that first day. When I entered the queue, its tail was a traffic hazard. Fortunately, the queue moved faster than new people arrived thereafter, and the hazard ended. The queue moved surprisingly fast – it took me one hour to advance the 100 meters to the door. Even so, this was a failure in the system – there is no good reason to have people with underlying illnesses (and we all had them, to qualify for the vaccine) stand around in freezing cold weather for an hour! Once, a nurse came and asked us if any of us was 63 years old or older. Apparently no-one was, since no-one was asked to leave (they will be vaccinated later). Later, another nurse asked everyone in the queue outside to show their KELA cards – KELA is the national health insurance system, and its card carries information about extra coverage one qualifies for due to underlying illnesses. Eventually, I reached the door. Two guards stopped anyone who tried to enter directly, sidestepping the queue, and let in only those who had legitimate business other than vaccination. The main hall was full of people, and I quickly realized that the queue took a full circle inside the hall to reach the multiplexing point. It took me another hour to slowly advance my way though the hall. At the multiplexing point, I was asked to wait a bit, and then I was assigned a vaccination room and a waiting number. Some twenty minutes later I was called in. The vaccination room I was assigned to was a nurse’s office. Two nurses were there, one who would administer the vaccine, and another at the computer, to keep a record. I gave them my KELA card, and shed my coat and my outer shirt, and bared my left shoulder. I was quickly given the pandemic vaccine; there was no question I was qualified for it, not with my obesity being obvious. Then they asked what my diagnosis was. “Prmarily I’m here because of my obesity,” I said. “But I also have paroxysmal atrial fibrillation.” “That’s not what your KELA card says,” accused the nurse at the computer. “The diagnosis is so new,” I countered. “There has been no time to do the paperwork for KELA.” (And indeed, I later learned, it would come up in my next checkup in the spring.) They stared at each other. “I can show you my prescriptions,” I said, making no move for them. Stares. I stared back. “Do you want the seasonal vaccine or not?” asked the nurse with the injectors. I lauged briefly. “I might as well.” It had, honestly, never crossed my mind that I might qualify. She injected me on my right shoulder. “You should stay in out there for ten minutes.” I picked up my clothes and found the cafeteria with coffee and pastry. Then the real fun started. Next day, I woke with horrible upper back pain. The thermometer showed mild fever; but since i didn’t have any respiratory symptoms, I decided to go to work. In the evening, turning in bed was excruciatingly painful. It took days for the pain to subside. I left the building three hours after I arrived at the end of the queue. What? You think that’s excessive? So do I and many others; queuing feels so Soviet Union! But honestly, while it did take time, it worked. I am vaccinated; are you?

Russell Coker advocates putting -e on the shebang line of shell scripts. I disagree. From my experience this is extremely unhelpful to people who may be debugging your shell scripts in the future. Consider this, you've added -e to the shebang of a script, and some poor schmuck down the track is trying to debug why it spontaneously exits. What's the most obvious way to do this? Run the script with sh -x or bash -x. What happens when you do this? The shebang is completely ignored, and the script is directly run by the shell interpreter. If the person doing the debugging doesn't happen to transpose all of the shell options on the shebang line to the manual shell interpreter invocation, you're going to get different behaviour. So I advocate an explicit set -e on the second line of shell scripts instead. As much as making shell scripts set -e is a good practice, it drives me absolutely batty having to deal with scripts that spontaneously exit as soon as something they run exits non-zero. Particularly when you've chained a bunch of shell scripts together, or have one sourcing a bunch of script fragments from a directory. For this reason, I prefer to write in Bash and use an exit handler, to make it very obvious when a shell script has abended due to set -e.

In the ’90s, you had a large machine and several thin clients accessing it by using X11 via network. In 2010, you will have large datacenters providing applications to and storing the data of millions of users. As you might have guessed, I am talking about Google Chrome OS. It seems that the PC era is slowly coming to an end, with devices being increasingly connected ‘to the cloud’ and people being always online; and storing their data on Google’s servers. We do emails online using Google Mail, we do navigation online using Google Maps, we edit and view our documents using Google Docs, our newspaper is Google News; and when we want entertainment we open the browser and type youtube.com into the URL bar. Even if we were formatting the hard disk and reinstalling the system, most people wouldn’t even notice; because all there data is stored online. There is also the question of freedom. Free software is not very widespread in the SaaS world. You also lose the control over your data. But RMS can tell you more about it. So it seems that 2010, Google is the new mainframe and netbooks and smartphones are the new terminals. Whether this is good or not cannot be said. The question you have to ask yourself is whether you can trust Google to keep your data secure or not. I trust them enough to host all of my emails, the RSS feeds I read, my searches. Posted in General

Bastien mentioned the Chromium OS xorg.conf file, which includes an irritating wart - namely, Option "SHMConfig" "on". This tells the Synaptics touchpad driver to export its configuration data to a shared memory region which is accessible to any user on the system. The reason for this is that in the past, there was no good way for configuration information to be passed to input drivers through the X server at runtime. This got fixed with the advent of X input properties, and synaptics can now be configured sensibly over the X protocol.But why was it off by default? Because, as I said, the configuration data is exported to a shared memory region which is accessible to any user on the system. And while it contains a bunch of information that's not terribly interesting (an attacker being able to disable my touchpad or turn on two finger emulation may be a DoS of sorts, but...), it also contains some values that are used to scale the input coordinates. Which means that anyone with access to the SHM region can effectively take control of your mouse. The current position is exported too, so they can also track all of your mouse input.Now, this isn't stunningly bad. The attacker can only do this while you're touching the pad. You'll see everything that happens as a result. There's no way to fake keyboard input. They need to be running code as another user on the system - if they're running as the logged in user then they can already do all of this. And for a device as single-user as Google seem to be looking at, it's obviously not a concern at all.But there's still plenty of places on the web suggesting that you enable SHMConfig, and various distributions that ship with it turned on (Ubuntu on the Dell mini used to, but got turned off after I contacted them about it). It's absolutely fine to do this as long as you're aware of the security implications of it, but otherwise please use X input properties instead.

po4a, including the new po4a-build script, has been released and po4a (0.37.0-1) has been uploaded to Debian. This release also includes a fully updated Spanish translation, including the new po4a-build documentation, thanks to Omar Campagne. po4a-build will be used as a build-dependency by emdebian-rootfs and svn-buildpackage (both due to have updated releases in a couple of days). (po4a-build itself was developed and tested within these packages - as 'genmanpages'.) po4a-build is intended to make it as easy to produce translated documentation as it can be to produce the current untranslated content. When po4a prepares the translated content as POD or DocBook XML, the final documentation can then be built using po4a-build. Both the untranslated and translated content is built as a single process, updating the POT files at the same time. Existing build instructions are replaced by a single call to po4a-build and a simple configuration file is used to tell po4a-build how to build each element and which binary packages will include the translated and untranslated content. See po4a-build (1) and po4a-build.conf (5) from the installed po4a package. Feel free to try it out with any package that builds translated documentation, *especially* if it also builds binary gettext translations of program output without using autotools, e.g. perl scripts using $(MAKE) but not ./configure. This should be a useful step in encouraging more packages to translate their script output and manpages. It is trivial to add translation to packages using the full autotools|intltool setup, now po4a-build brings the same level of ease to packages only using $(MAKE). (If someone wants to investigate how CMake can do the same, let me know.) http://alioth.debian.org/projects/po4a/ http://alioth.debian.org/frs/download.php/3183/po4a-v0.37.0.tar.gz http://freshmeat.net/projects/po4a/releases (0.37.0 announcement pending approval by FM)

Although it does not reflect my experiences at the university, I wrote a song text about teachers that do not care about their students, to the melody of „Private Dancer“ of Tina Turner. My list of parody songs now contains 22 entries!

When writing a shell script you need to take some care to ensure that it won’t run amok. Extra care is needed for shell scripts that run as root, firstly because of the obvious potential for random destruction, and secondly because of the potential for interaction between accounts that can cause problems.

• One possible first step towards avoiding random destruction is to start your script with “#/bin/sh -e” instead of “#/bin/sh“, this means that the script will exit on an unexpected error, which is generally better than continuing merrily along to destroy vast swathes of data. Of course sometimes you will expect an error, in which case you can use “/usr/local/bin/command-might-fail || true” to make it not abort on a command that might fail.
• #!/bin/sh -e cd /tmp/whatever rm -rf * #!/bin/sh cd /tmp/whatever || exit 1 rm -rf * Instead of using the “-e” switch to the shell you can put “|| exit 1” after a command that really should succeed. For example neither of the above scripts is likely to destroy your system, while the following script is very likely to destroy your system: #!/bin/sh cd /tmp/whatever rm -rf *
• Also consider using absolute paths. “rm -rf /tmp/whatever/*” is as safe as the above option but also easier to read – avoiding confusion tends to improve the reliability of the system. Relative paths are most useful for humans doing typing, when a program is running there is no real down-side to using long absolute paths.
• Shell scripts that cross account boundaries are a potential cause of problems, for example if a script does “cd /home/user1” instead of “cd ~user1” then if someone in the sysadmin team moves the user’s home directory to /home2/user1 (which is not uncommon when disk space runs low) then things can happen that you don’t expect – and we really don’t want unexpected things happening as root! Most shells don’t support “cd ~$1“, but that doesn’t force you to use “cd /home/$1“, instead you can use some shell code such as the following: #!/bin/sh HOME=`grep ^$1 /etc/passwd|head -1|cut -f6 -d:` if [ "$HOME" = "" ]; then   echo "no home for $1"   exit 1 fi cd ~ I expect that someone can suggest a better way of doing that. My point is not to try and show the best way of solving the problem, merely to show that hard coding assumptions about paths is not necessary. You don’t need to solve a problem in the ideal way, any way that doesn’t have a significant probability of making a server unavailable and denying many people the ability to do their jobs will do. Also consider using different tools, zsh supports commands such as “cd ~$1“.
• When using a command such as find make sure that you appropriately limit the results, in the case of find that means using options such as -xdev, -type, and -maxdepth. If you mistakenly believe that permission mode 666 is appropriate for all files in a directory then it won’t do THAT much harm. But if your find command goes wrong and starts applying such permissions to directories and crosses filesystem boundaries then your users are going to be very unhappy.
• Finally when multiple scripts use the same data consider using a configuration file. If you feel compelled to do something grossly ugly such as writing a dozen expect scripts which use the root password then at least make it an entry in a configuration file so that it can be changed in one place. It seems that every time I get a job working on some systems that other people have maintained there is at least one database, LDAP directory, or Unix root account for which the password can’t be changed because no-one knows how many scripts have it hard-coded. It’s usually the most important server, database, or directory too.

Please note that nothing in this post is theoretical, it’s all from real observations of real systems that have been broken. Also note that this is not an attempt at making an exhaustive list of ways that people may write horrible scripts, merely enough to demonstrate the general problem and encourage people to think about ways to solve the general problems. But please submit your best examples of how scripts have broken systems as comments.

SME Web – Internet advertisers: New cookie laws approved: reports that: “internet users will have to provide consent to cookies being stored on their computers. This could result in them being bombarded with pop-ups seeking their permission to accept the cookies.” However, the site doesn’t link to a text supporting that interpretation. The only reference is to a directive which doesn’t seem explicit. Further, the article states “The current EU telecom law allows the use of cookies if web users are notified of them and are able to opt-out. “ but there are tons of sites which don’t comply with that and are simply broken if they can’t store their cookies. That includes several gov.uk ones – very annoying, but surely there wouldn’t be so many if it was illegal, would there? Is that article accurate and does anyone have plain English that I can send to gov.uk webmasters to persuade them to fix their sites?

For about a month or so Squid v3.1 is now in experimental ready to use and ready for getting tested by a wider community base. So I installed it by changing my sources.lists deb-src line to experimental instead of unstable, apt-get update, apt-get build-dep squid3 and apt-get -b source squid3. Compilation went fine and flawlessly on unstable. On stable/lenny you'll need to install squid-langpack as well from unstable. After installing the resulting *.deb files, there was no need to change or update the configuration for squid3: if a request/domain lookup results in an IPv6 address, squid3 will use it and gives precedence over the IPv4 address. If there's no IPv6 address for that requested domain, nothing changes from the old behaviour. So, when a page is requested by an IPv4 client, squid3 will contact the site via the IPv6 address if possible and deliver the page to the client via IPv4. This is the same (and naturally expected) behavior as in polipo, another IPv4/IPv6 capable proxy. Polipo is a small proxy with less functionality than squid3, but it has some issues from time to time that needs a restart of its service. Additionally I would prefer just one proxy running on my system. So, now I'm able to just use squid3 for all of my proxy tasks again. Using a IPv4/IPv6 capable proxy is by the way a good method to increase IPv6 visibility, especially when you fear the (amazing small) workload to deploy IPv6 in your own network.

Whew! Is it karma or what? What makes me get involved in two horribly complex, two-week-long conferences, year after year? Of course, both (DebConf and EDUSOL) are great fun to be part of, and both have greatly influenced both my skills and interests. Anyway, this is the fifth year we hold EDUSOL. Tomorrow we will bring the two weeks of activities to an end, hold the last two videoconferences, and —finally— declare it a done deal. I must anticipate the facts and call it a success, as it clearly will be recognized as such. One of the most visible —although we insist, not the core— activities of the Encounter are the videoconferences. They are certainly among the most complex. And the videoconferences' value is greatly enhanced because, even if they are naturally a synchronous activity (it takes place at a given point in time), they live on after they are held: I do my best effort to publish them as soon as possible (less than one day off), and they are posted to their node, from where comments can continue. This was the reason, i.e., why we decided to move at the last minute tomorrow's conference: Due to a misunderstanding, Beatriz Busaniche (a good friend of ours and a very reknown Argentinian Free Software promotor, from Via Libre) thought her talk would be held today, and we had programmed her for tomorrow. No worries - We held it today, and it is already online for whoever wants to take part :-) So, I don't want to hold this any longer (I will link to the two conferences that I'm still missing from this same entry). Here is the list of (and links to) videoconferences we have held.

Tuesday 2009-11-17

• Debian-Women, by Margarita Manterola (Buenos Aires, Argentina) (PDF presentation, .ogg file, IRC log)
• Personal networks, by Isidro Maya Jariego (Sevilla, Spain) (.ogg file, IRC log)

Wednesday 2009-11-18

• Social networks, by Sofía Liberman Shklonikoff (Mexico City, Mexico) (PDF presentation, .ogg file, IRC log)
• Open Social Education, by Dolors Reig Hernández (Barcelona, Spain) (PDF presentation, .ogg file, IRC log)

Thursday 2009-11-19

• Politics 2.0, by Txopi, Bilbao, Basque Country (ODP presentation, .ogg file, IRC log)
• OpenSocial, by Rodrigo Gallardo (Portland, USA) (.ogg file, IRC log)
• Informatic analfabetization, or why does privative software work towards analfabetization? (.ogg file, IRC log)

Friday 2009-11-20

• Education and cognition from Free Software, by Offray Luna (Bogotá, Colombia)PDF material, .ogg file, IRC log)/li>
• EDUSOL's state / EDUSOL projects, by the EDUSOL organizer team (which attempts to be distributed ;-) )

As two last notes: Regarding the IRC interaction photos I recently talked about, we did a very kewl thing: Take over 2000 consecutive photos and put them together on a stack. Flip them one at a time. What do you get? But of course — A very fun to view and interesting interaction video! We have to hand-update it and it is a bit old right now, but nevertheless, it is very interesting as it is. Finally... I must publicly say I can be quite an asshole. And yes, I know I talked this over privately with the affected people and they hold no grudge against me... But still - yesterday we had an IRC talk about NING Latin American Moodlers, by Lucía Osuna (Venezuela) and Maryel Mendiola (Mexico). One of the points they raised was they were working towards (and promoting) a Moodle certification. And... Yes, I recognize I cannot hear the mention of the certification word without jumping and saying certifications are overrated. Well, but being tired, and not being really thoughtful... I should have known where to stop, where it was enough of a point made. I ended up making Maryel and Lucía feel attacked during their own presentation, and that should have never happened. A public and heartfelt apology to them :-(

How did Facebook come up with this?

[The following story is fictional and does not depict any actual person or event, just like in Law & Order.] James filed an RC bug on a package, complaining that it attempted to execute an illegal instruction on a Netwinder, running Linux 2.6.xx. This was sort of an ironic hipster tribute to the olden times when buildd admins would actually do their jobs, keeping chroots clean and current, reviewing buildd logs, and filing FTBFS bugs where appropriate, except that he didn't actually do any of those things. 18 minutes later, Aurelien replied, asking for more information in order to debug the problem. « Teh-oh » said James, but nobody could hear him because he was talking to his Raggedy Ann doll. Stephen suggested that Aurelien contact Vince or Steve to get access to different Netwinders, and Aurelien tried to reproduce the problem on other ARM machines unsuccessfully. « Could you tell me the exact kernel version on this Netwinder, and the one on europa, which seems to have the same problem? » Aurelien asked James. « Aaagh, they're trying to steal my precious bodily fluids! » hissed James, but nobody could hear him because he was talking to his inflatable astronut. « Also, the contents of /proc/cpuinfo would be nice. » Aurelien added. « We hates them, Clive Oven! » James announced, but nobody could hear him because he was talking to his EASY-BAKE REAL MEAL Oven. « The Netwinder you were talking about is europa, wasn't it? Could you tell us the kernel versions on europa and elara? There's no problem on other Netwinders, so it's probably a kernel issue. » « THE MARTIANS ARE COMING! » James cried, but nobody could hear him because he was talking to a small band of subservient deaf-mute milkmen. « It's been more than a week since this bug has been filed, and there has been no useful information provided at all. Can anybody help? » asked Peter. « HELLO. IS THIS THING ON? Could you have the elementary courtesy to follow up to the bugs you report? » asked Pierre. « Bromeliads.. I'll buy you some bromeliads, » James muttered, but no one could hear him because he was talking to his ficus plant. Loïc looked around, slipped into a cave, sprinted through a maze of tunnels, and sped in a small nuclear-powered submarine to James's secret undersea lair. Rapping on the bulkhead three times, he uttered the code phrase and James let him in. After a conversation that took place strictly through pantomime, Loïc departed and James said, « For fuck's sake, » but no one could hear him because he was talking to a broken sonar antenna. « Yo, James is busy, but he said that it's okay to downgrade the bug since it's not a problem with other Netwinders, » reported Loïc. « I never said that! I don't even know who that guy is! I'm going to convert him into a kangaroo! » James sang, but no one could hear him since he was alone on a beach in Normandy. A month later, Riku wrote to Woody, « Hey, we have this bug. Could you take a look? » « Sure, » replied Woody, and he gave Aurelien access, and Aurelien debugged the problem in under an hour. « Now everyone knows that europa and elara were running Linux 2.6.11. This is a breach of national security! » declared James, but nobody could hear him because he was talking to the crushed skull of a kitten who had recently been sunning himself.

By now everybody has now heard about Go, Google's expressive, concurrent, garbage collecting language. One big, glaring thing stuck out at me when I was reading the documentation: Do not communicate by sharing memory; instead, share memory by communicating. One of the examples given is a semaphore using a channel, which I'll copy here for posterity. var sem = make(chan int, MaxOutstanding) func handle(r *Request) { sem Here is a little illustration of that in operation. Serve creates goroutines via the go keyword; each of which tries to get a slot in the channel. In the example there are only 3 slots, so it acts like a semaphore of count 3. When done, each thread returns its slot to the channel, which allows anyone blocked to be woken and continued. This instantly reminded me of the very first thing you need to do if you ever want to pass Advanced Operating Systems -- write a semaphore server to provide synchronisation within your OS. In L4, threads communicate with each other via inter-process communication (IPC). IPC messages have a fixed format - you specify a target thread, bundle some data into the available slots in the IPC format and fire it off. By default you block waiting for a reply -- this all happens within a single call for efficiency. On the other side, you can write servers who are listening for remote IPC connections, where everything happens in reverse. Here's another illustration the of the trivial semaphore server concept Shehjar and I implemented. Look familiar? Instead of a blocking push of a number into a slot into a channel, you make a blocking IPC call to a remote server. My point here is that both take the approach of sharing memory via communication. When using IPC, you bundle up all your information into the available slots in the IPC message and send it. When using a channel, you bundle your information into an entry in the channel and call your goroutine. Receiving the IPC is the same as draining a channel - both result in you getting the information that was bundled into it by the caller. IPCGo Start threadStart goroutine New thread blocks listening for IPC messageGoroutine blocks draining empty channel Bundle information into IPC messageBundle data into type of your channel Send IPC to new threadPush data into channel Remote thread unbundles IPCgoroutine drains channel and gets data Whenever you mention the word "microkernel", people go off the deep-end and one thing they seem to forget about is the inherent advantages of sharing state only via communication. As soon as you do that, you've broken open an amazing new tool for concurrency, which is now implicitly implied. By communicating via messages/channels rather than shared global state, it doesn't matter where you run! One of those threads in the example could be running on another computer in your cloud, marshalling up it's IPC messages/channel entries and sending them over TCP/IP -- nobody would care! At any rate, do not communicate by sharing memory; instead, share memory by communicating is certainly an idea whose time has come.

Last night I was in the middle of checking my email when I found that clicking on a URL link wouldn’t work. It turned out that my web browser had become unavailable due to a read error on the partition for my root filesystem (the usual IDE uncorrectable error thing). My main machine is a Thinkpad T41p, it is apparently possible to replace the CD-ROM drive with a second hard drive to allow RAID-1 but I haven’t felt inclined to spend the money on that. So any hard drive error is a big problem. Fortunately I had made a backup of /home only a few days ago. I use offline IMAP for my email so that my recent email (the most variable data that matters to me) is stored on a server with a RAID-1 as well as on my laptop and my netbook. The amount of other stuff I’ve been working on in my home directory is fairly small, and the amount of that which isn’t on other systems is even smaller (I usually build packages on servers and then scp the relevant files to my laptop for Debian uploads, bug reports, etc. The first thing I did was to ssh to one of my servers and paste a bunch of text from various open programs into a file there. That was the contents of all open programs, the URLs of web pages I was reading, and the contents of an OpenOffice spread-sheet which I couldn’t save directly (it seems that a read-only /tmp will prevent OpenOffice from saving anything). Then I used scp to copy 600M of ted.com videos that I hadn’t backed up, I don’t usually backup such things but I don’t want to download them twice if I can avoid it (I only have a quota of 25G per month). After that I made new backups of all filesystems starting with /home. I then used tar to backup the root filesystem. The hard drive in the laptop only had a single bad sector, so I could have re-written it so that it would be remapped (as I have done before with that disk), but I think that on a 5yo disk it’s probably best to replace it. I had been thinking of installing a larger disk anyway. On restore I restored the root filesystem from a month-old backup and then used “diff -r” to discover what had changed, it took me less than an hour to merge the changes from the corrupted root filesystem to the restored one. Now I have lots of free disk space and no data loss! I am now considering making an automated backup system for /home. My backup method is to make an LVM snapshot of the LV which is used and then copy that – this gets the encrypted data so I can safely store it on USB devices while traveling. I could easily write a cron job that uses scp to transfer a backup to one of my servers at some strange time of the night. The next issue is how many other disks I will lose this summer. I have installed many small mail server and Internet gateway systems running RAID-1, it seems most likely that some of them will have dead disks with the expected record temperatures this summer.

Keith and I have been pretty quiet about TeleMetrum for a while... but that doesn't mean we've been idle! In recent weeks, I've built up several more flight units and two more ground station boards, as noted in my production log. We're both trusting rockets solely to our boards and Keith's firmware at this point. In fact, we've accumulated a significant number of succesful flights, including a cool drag-race between 4" airframes at NCR Oktoberfest where we both put brand-new, nearly identical rockets fully at risk flying only TeleMetrum boards, and a flight by Keith the same weekend on a full-K Loki K350W moon-burner in which he set a new personal altitude record! I've also flown a board with 100-g accelerometer installed successfully in a flight that peaked at 52.8 g! We're now hard at work on a "next version" of the hardware, incorporating everything we've learned so far. There are a number of significant changes planned:

• Fully integrated, on-board GPS receiver and patch antenna, with support for off-board amplified antennas when airframe geometry or materials demand it.
• A change in the design of the circuit for firing e-matches to ignite ejection charges that will improve mechanical reliability, plus explicit support for using a separate pyro battery if desired.
• Inclusion of a "companion board interface" that we envision using for a pyro channel expansion board to support staging and air starts, among other things.
• Dramatic increase in the capacity of the on-board data logging memory.
• Changes in connector series to eliminate our dependency on expensive crimping tools for making cables.

To make all this fit, I'm stretching the board an extra 1/4 inch to a total outline of 1 by 2.75 inches. We're also moving all the connectors, the GPS patch antenna, and the beeper to the "back side" of the PC board. This is a win on several levels... it will allow us to have silk-screen labels for the connectors, will help protect the baro sensor from sunlight and the various surface mount parts from physical damage during rocket prep, and opens up more board surface area for component placement and routing on the "top side" of the board. In practice, this means that boards will be mounted on standoffs with all the active components facing "down" and the connectors facing "up." Before we'll be ready to build some of these, we need to get in some more flights to test the various changes we're making. In particular, the change in ejection charge circuit, and the GPS receiver chip and antenna choices we're now favoring. Unfortunately, Keith and I are now both into the time of year where launch opportunities come less frequently, even before we consider the weather. Meanwhile, Keith's firmware and ground station software are now doing nearly everything we've envisioned wanting from this project. It seems entirely likely that he'll be ready to declare "version 1.0" soon after we obtain and verify the functionality of our next version of the hardware... In the meantime, our friends at Woot have posted a really funny video combining material from a couple launches this summer of my 10-inch Goblin, on one of which we flew some of their screaming flying monkey dolls... Enjoy!