Giving up on a position within a free software project when you know you re no longer managing to do an effective job is a wonderfully liberating experience. Now that I have started to talk with Miriam Ruiz about handing over the Debian Jr. project, I can stop worrying about the leadership task and just have fun with it. I can always count on Miriam for recommendations for games in Debian my kids may enjoy, as she has a passion for finding good games to package for Debian, and in particular, games for children. Over the past few weeks we ve had some fun with her picks. At the same time, I always have Debian Jr. in mind. How can we ensure kids can have the most fun with this? How do we equip their guides to help them? What we ve done with each new piece of software is to find a quiet time when one or more of the children can start playing with it on their own while we watch, offering such guidance as they need, but for the most part just letting them loose with it. Each wrinkle of the brow, each impetuous thump of the mouse, every illuminated grin and exclamation of delight is noted. We try to see what frustrates or pleases our kids and discuss it both with them and the Debian maintainers and upstream developers. This is an excercise we ve managed to pull off without being overly intrusive and the results have been well worth the effort. Using a few of Miriam s picks we tried this week, we were able to draw their play into the free software development process. Here s a brief summary of those sessions: Platinum Arts Sandbox puts into children s hands the ability to role play in a 3D world and edit that world using simplified controls. The expressions on the faces of our kids as they played were priceless: both the ups and the downs. I wanted to capture this on video and share it. After having established a rapport with upstream, we took a 20 minute clip of one of our play sessions and gave a copy to them to use to help further their work. Here is the edited result. They were very pleased to have that kind of feedback and found the video valuable for determining where the software still needed improvement and to notice which aspects particularly pleased the children. I happen to know that Hex-a-hop is one of Miriam s personal favourites. We have a household full of puzzle-lovers so this puzzle game was an instant hit. While on irc on #debian-jr with Miriam we relayed in real-time some of the reactions as they played this and a handful of her other picks. This gave her some confirmation of areas she knew needed work as well as inspiration for upcoming releases of these packages. During this play session, which also included StegaVorto, kartofel, Anagramarama, Funny Boat and Vodovod, my youngest girl, age 7, plunked down on the couch next to me as her 10-year-old sister played. Then she started to notice I was typing what people in the livingroom were saying and doing on irc. She took a mild affront to me copying her own words and actions, so I decided it would be better to let her participate so she would feel included. At this point, I started playing secretary for her, typing what she dictated to me while she read the responses from the display. Later, I just handed her the keyboard so she could type and read the responses on her own. She was still at it long past bedtime and it was with some reluctance that she finally gave up the keyboard. We all had a lot of fun and look forward to doing this again. We are particularly careful with privacy, taking care to share pictures, videos, and other personal details only so far as we believe it does not put our children at risk. Also, we need to ensure we observe in a way that is welcome and doesn t interfere with their enjoyment. But with a little bit of prudence and a practiced eye and ear for what increases or diminishes enjoyment of the software, we can involve our children directly in the free software development process. I commend to anyone who has the privilege to share free software with children to use this method to communicate with maintainers and developers, increasing your own enjoyment of the software in the process and that of children and their guides everywhere.

I found a reference on the 'net about a week ago about SimTower. I remembered playing it a long time ago and thought it would be fun to try again since I hadn't beaten it. so I found my old copy and started playing. I've acheieved TOWER status in the game in 9 years.

The basic plan I used to beat the game was to build as wide as possible and to use 3 normal elevator shafts per 15 floors, 8 stairs and 2 escalators. Primarily my building was all offices. For the there are two sets of stairs going up 3 floors from each lobby. There is also an escalator going down from the lobby for each set of stairs and one more set of stairs going down a floor from the escalator. For the floors that have stairs going to them, there should be no elevator for that floor.

Now there are only 9 floors left that need elevator transportation. The best strategy I figured out for these floors was 3 elevators, each hitting 5 floors. That way each floor got one elevator shaft and a 3rd elevator shaft provided a bit of extra transport.

The 14th floor in each set is a good place to put cafes, and shops. I put a couple cafes and shops in, a security office at on one end, then put some offices in to use up some of the remaining space on the outside of the building. I left a bunch of space between the cafes and offices.

The first 15 floors are special since those floors should have 3 floors of offices, 6 floors of hotel rooms, one housekeeping station per floor, and a service elevator between the hotel floors. Then topped off with offices.

The basement floors had shops, cafes, restaurants and a cinema on floors b1 and b2. Parking was on floors b3, b4, and b5. The recycling centers were on floors b6 and b7, then the metro was on floors b8, and b9 with the metro taking up b10. I also put shops and cafes on floors b8 and b9 with the metro.

For the express elevator I tried to have on each express elevator go to the basement floors and 1 above ground floor. This way floor 15 and floor 30 has separate elevators shafts. Each elevator had as many elevator cars as it could take.

Using this strategy I used 63 above ground floors to get to 15k people and had 128 million dollars. I didn't lower the rent on any offices until I was building up to floor 100 for my cathedral, where I lowered prices on many offices between floors 45 and 60 where I did lower the price to keep tenants. I did lower the price on some hotel rooms much earlier in the game.

You can browse with my wide tower.

I went to watch Slumdog Millionaire this afternoon. The movie is good, but doesn't live up to the hype around it. However, the initial sequence where the kids are chased by the police through the slums of Dharawi was excellent. The movie is very Indian, but one thing that stands out is that Jamal Malik is accused of cheating because he is a boy from the slums, and IMO, India is country where people believe that anything is possible and if someone from a slum wins on a game show, it wouldn't surprise a lot of people let alone make them suspicious.

Pretty much everybody seems to describe SDM as the story of a boy from Mumbai's slums who answers all the questions on who wants to be a millionaire and is suspected of cheating. While that is how the plot goes, I don't know if that was how Danny Boyle intended people to know the movie as. I felt that SDM is the story of a young man who wants to be on the TV game show for as long as possible so that his love can watch him. Neither the money nor the intellectual challenge of being on the show matter to him at all.

I am watching The Mystic Masseur at home right now. Most movies from The Merchant Ivory 'period movie' collection are available at a discounted price in the stores these days :-).

Oh, I finally made myself a Hackergotchi

I've been using my G1 phone for a month now. It is nice, but the one that I like more about my old phone was that it had a real number pad. So, I'm pondering how well a touch screen would work on a cell phone with designed sort of like the LG MediaFLO phone.

When I explain the importance of free software, I often use some variation of the following example:

Suppose I see a beautiful sunset and I want to describe it to a loved one on the other side of the world. Today's communication technology makes this possible. In the process, however, the technology in question puts constraints on message communicated. For example, if I pick up my cellphone, my description of the sunset will be limited to words and sounds that can be transmitted by phone. If I happen to have a camera phone and the ability to send a picture message, I will be able to communicate a very different type of description. If I'm limited to 150 characters in an SMS message, my message will be constrained differently again.

The point of the example is this: the technology I use to communicate puts limits and constraints on my communication. Technology defines what I can say, how I can say it, when I can say it, and even who I can say it to. This is neither good nor bad. It is simply the nature of technology. But it means that those who control our technology control us, to some degree. As information technology becomes increasingly central to our lives, the way we experience, understand, and act in the world is increasingly controlled by technology and, by extension, by those who control technology. I believe that the single most important struggle for freedom in the twenty first century is over the question of who will set these terms. Who will control the technology that controls our lives? Free software can be understood as an answer to this question: An answer in the form of an unambiguous statement that technology must be under the control of its users. When free software triumphs, we will live in a world where users control their technological destiny. We simply cannot afford to fail. The Free Software Foundation is the most important organization fighting for the rights of users in this struggle. Here are some of the ways that I plan to direct the FSF to support software freedom in the coming year:

Network Services Last year, the FSF organized a meeting on software freedom and network services that lead to the creation of the Autonomo.us group and the release of the Franklin Street Statement on Freedom and Network Services. As network services --- like those built by Facebook, Google, and others --- continue rise in popularity, progress in this conversation is of increasing importance. This year, I will direct the FSF to build on the work of Autonomo.us to launch the first of what I hope will be several FSF position statements on software freedom and network services. More importantly, the FSF will begin to provide support and planning for solutions --- technologies, social campaigns, and legal steps --- that will protect computer users whose freedom is currently threatened by network services. Enforcing free software licenses Early on, people who decided to work on free software did so because they agreed with --- or, at the very least, were willing to abide by --- the principles and rules laid out in our licenses. In our push for software freedom, we have created software of immense value and attracted companies and individuals to our community who are less willing, or simply less interested, in protecting users' freedom. In December 2008, the FSF went to court for the first time in the organization's history to force Cisco to uphold the freedom of the users of FSF copyrighted software. This lawsuit asks Cisco to live up to its obligations under the GPL and to ensure that it does so in the future. The FSF needs the support of its community in this and in future enforcement actions. The FSF has operated a compliance lab for several years and has ensured software freedom for countless users. As free software becomes more successful in the next year, the FSF will be playing an increased role in protecting software freedom from those who do not share its principles. Continuing the fight against software patents As I said last year, one cannot write non-trivial software today without running a serious risk of infringing patents. The software patent minefield we've found ourselves in is a very fundamental threat to the success of free software and we've already begun to see the first casualties and costs. We must eliminate software patents. Now. The FSF will continue its work toward this end. The FSF's End Software Patents project's major contribution this year was a brief submitted in the In Re Bilski case at the U.S. Court of Appeals for the Federal Circuit. Recently, an opinion was issued which seems to mark an important shift away from broad protection for software patents. With this victory, now is the time to keep up this momentum. The FSF is drawing up a strategy to do just this and will be announcing the relaunch of its campaign on February 9,2009 led by Ciaran O'Riordan.

Every recent fundraising appeal seems to mention the difficult economic climate and it seems to cliche to do so here. That said, the effect of a bad economy is, in fact, felt most strongly in non-profits dependent on donations. The FSF is not immune. The FSF's work is essential for success on the issues I've described here and on all of its other campaigns and projects. Although the cost of a membership or donation may be less easy to afford this year for many of you, the free software movement cannot afford a weakened FSF at this important moment. If you are not an FSF associate member, now is the time to become one. If you are already a member, please join me in giving generously through a tax-deductible donation. The FSF is a very lean, very humble organization of passionate and dedicated individuals working tirelessly for software freedom. Every single gift makes a difference.

On Tuesday afternoon I gave a talk on behalf of KaiGai Kohei about SE Linux and the LAPP (Linux Apache, PostgreSQL, PHP/Perl) stack. KaiGai has blogged about this [1], unfortunately Google Translation does a poor job of Japanese and has particular problems with KaiGai s work (could anyone who knows Japanese and English well please submit some tips to Google). KaiGai s post is useful for links to his notes which are good background reading. My talks about SE-LAPP and SE-PostgreSQL have been getting some notice, Bob Edwards referenced SE-PostgreSQL in his talk about database security. It s good to see KaiGai s great work getting the notice that it deserves. I hope that it becomes a standard feature of the PostgreSQL code base in the near future! Also Casey Schaufler, James Morris, and I have bought KaiGai a present of some Tasmanian wine, in recognition of his great work.

Sarah came up a great idea for us to do over the long, long weekend after New Years. She wanted to go to the Grand Canyon, and hike in it. I, also enjoying hiking trips, went along.

We organized the trip rather late, I think on the 27th of Dec from my parents house (I think my mom enjoys being around for trip planning since it reminds her of the trips she should plan). Given our late planning we could only get a reservation at Phantom Ranch for the night of the 1st. So the trip plan was get back to SF on 30 Dec 2008. Take bart from the airport, sleep/pack (in either order), then drive to Williams, AZ on the 31st. Take a bus the to Grand Canyon on the 1st, hike down to Phantom Ranch, sleep, hike back up to the top, see the Grand Canyon from the top. Take a bus back to Williams and drive somewhere near the Hoover Dam. Sleep. Drive, see the Hoover Dam, get to Las Vegas, and see the Cirque du Soleil show Ka. Sleep. Drive home.

So that was the plan, now for the execution. We got back to SF on time and picked up our bags from the baggage claim without any issue. The next morning we got up and moving. The optimistic hope was that we would be on the road by 8am to Williams, then stop in Fresno for gear and food. It turns out we weren't ready to go until 10, so we got hiking poles and fake crampons at the REI in SF. We also did our grocery shopping in SF. We were on the road to Williams by noon. We shared the driving Sarah took the parts with traffic, I took the 4 and two lane highways. The fortunate part about this is that I drove through the San Joaquin. One the way there, it was basically IFR conditions (I had no instruments), so I was driving through a cloud (some call it fog) and I couldn't see anything that wasn't on the road. It was really pretty but not the best for a road with lots of ups, downs and turns. I felt like a race car driver. The other interesting part (at least while I was driving) was going through the Mojave desert at sundown. I don't think Sarah has any pictures, but it was very pretty.

Finally we arrived in Williams, AZ and got to the Grand Canyon Railway Hotel, at 2345hrs, (for those counting that means we were on the road for 10h 45m). We checked in by 2358hrs on 31 Dec 2008. So we stood by the fire for two minutes, counted down, and kissed for New Years.

In the morning, things went as expected, we backed our bags to hike 10 miles, and put the rest of the stuff in the car. We got in a van that took us to the Grand Canyon. Our driver up to the Grand Canyon was very nice and showed us the sites along the way. We also met two Japanese exchange students on their way to see the Grand Canyon.

On the way was slow since we took a lot of pictures (Sarah has them all since I lots my 1GB SD card before it made its way into my camera). Unfortunatly, Sarah got tired on the way down, and also hurt her ankle. So we stumbled our way to Phantom Ranch around 1600. From the time we got to the ranch until supper at 1830, we laid back and relaxed, we needed it, our feed were sore and Sarah iced her ankle. The food at Phantom Ranch was good, not great, and there was enough of it after being on our feet all day. At end end of the day, we slept, as planned. In the morning we got up for the early breakfast. Again, it was decently, but not great, but there was enough food. Unfortunatly, Sarah was sick (She'd figured out how to deal with her ankle though) (Oh, and she isn't pregnant). So we harrassed the rangers, got some imodium, and started on our way back up the Bright Angel Trail, we took the Bright Angel Trail down and were planning on the South Kaibab trail up but the Bright Angel Trail has places to stop the South kaibab trail doesn't. Again were were planning on an early 630hrs start, but started a little later at 745hrs. We used our poles with gusto on the way back up and made it up by 1345, 6hrs on the way back up, the same time it took us to get down. The rest of the daylight hours was spent taking the village bus around the Grand Canyon village and seeing the sights from the top.

After the Grand Canyon, we drove to Kingman, stayed there, then continued on, saw the Hoover Dam, it is like Itaipu, but less political and taller, then went on to vegas. In Vegas we saw the inside of a couple hotels, I spent $1 on a slot machine, then we say Ka. Ka is an amazing show, I don't think it really suck in until after the show was over all the things the performers pulled off. That said, the stage itself was an engineering marvel that I watched almost as much as the performers.

After Vegas, the drive back was mostly uneventful, the fog in San Joaquin was a little lighter, but still heavy, Mojave is prettier at sunset and it is still good to sleep in my own bed.

What a difference a border makes.

Compare Windsor to Detroit.

Over two years ago, the FSF started its BadVista campaign with the goal of educating the public on problems related to software freedom, DRM, and more, with Microsoft's latest operating system. Today, the FSF is declaring victory; the name "Vista" is synonymous in the public eye with failure. The real credit, I suppose, should go to Microsoft. Vista's design put the desires of big media companies, software companies, and Microsoft itself ahead of the desires of users. Vista defeated itself. But the FSF's campaign drew a huge amount attention to the problems with Vista --- especially early on --- and provided a central location aggregating and amplifying criticism of Vista. In doing so, the FSF played an important role in helping the whole process along and in balancing this criticism with a more positive message about free software alternatives. Gratitude is due to the FSF staff, members, and supports who made BadVista a success. Please read the announcement, Digg the article, support the FSF, and follow its other work in its other campaigns so that all the FSF's work can be as successful as BadVista.

One change and one addition to my current European tour. First, it looks like we'll be skipping Amsterdam this time and heading straight to London from Zagreb on the evening of January 10th. We'll still plan to arrive in Cambridge before the 13th. Second, I'll be giving a redux of my Revealing Errors talk at Mama in Zagreb on January 10th at 14:00 as part of the normal skill sharing meeting. It's the longer version of my OSCON keynote with many more examples. Folks who have seen earlier versions of the talk seem to think it's a lot of fun. If you are in or near Zagreb, you should come!

I was thrilled to be part of a successful Debian bug squashing party organized by MIT's Student Information Processing Board on December 13th. Greg Price, who helped organize the event, did a wonderful write up which he sent to the debian-devel email list. I though it was worth mentioning the BSP now because I think it's a wonderful model that I'd love to see replicated in Debian and beyond. The event was initiated, organized, run, and executed by people with little or no direct experience with the project. While the organizers went out of their way to recruit several Debian developers and other experts to the party, these experts' role was more in answering questions and helping others. The the majority of the participants -- around 30 of them in total -- had no previous experience doing Debian development. While the 11 bugs closed or dealt with are the most visible outcome, I'm not sure that it is the most important. The event acted as an important learning experience for everyone involved and, perhaps most centrally, an important first step for most participants from using free software to giving back and participating in the community. You don't need experience, connections, or a @project.org email address to organize a party like this for Debian or your own free software project. All you really need is a few people, some technical knowledge, an Internet connection, and the desire to make it happen. Other things can help, of course. In particular, the SIPB folks have packaged up some scripts they used to select bugs to work on and put them online.

Is Richard Stallman leading a secret life as Serbian Nationalist "Chetnik" Zoran Radovanovic?

For those following d-devel, you may notice that I've recently been working on improving one of the cornerstones of Debian infrastructure; the Debian Archive Kit, or dak for short. Most DDs and DMs don't notice dak exists expect when trying to determine why their latest upload was rejected, and then yelling at the powers that be. I'm here to shead some light on this mythicial beast.

First off, a quick history lesson:

dak (also known as projectb) is a replacement for Debian's original archive software, known simply as dinstall. dinstall itself was a fairly large perl script that does what dak process-unchecked/process-accepted does today. James Troup did a fairly decent summary of dinstall, and its issues

James Troup's README.new-incoming (from dak's git repo):

The old system:
---------------
o incoming was a world writable directory

o incoming was available to everyone through http://incoming.debian.org/

o incoming was processed once a day by dinstall

o uploads in incoming had to have been there > 24 hours before they
were REJECTed. If they were processed before that and had
problems they were SKIPped (with no notification to the maintainer
and/or uploader).

dak's first commits were in 2000, and rolled out onto ftp-master.d.o sometime in 2001 or 2002 (I can't find an exact date for this). Since then, dak is also used on security.d.o, and on backports.org (fun fact for bpo people; the dak installation there is now up to date, and tracking git's tip).

So now that you know the history lesson, what specificially does dak do is the next question. Simply put, dak is the glue that binds the rest of the Debian's backends together; both britney and wanna-build/buildd depend on it. It handles management of uploads to the archive, handles stable release updates, as so forth. It is also the only Debian archive software that uses an actual database backend, and scales fairly well handling over 10,000 packages, and 12 architectures. Unfortunately, there are also a lot of issues with dak as it stands.

Sections of the code base have bitrotted over the years; legacy and legacy-mixed support have died, the import-archive function is shot (more so now than ever, see below), the test suite is non-functional (never a good sign), the docs are out of date, and in many places non-existant, doing a release (both point and full) requires editing the database and so forth.

In addition, dak, while written in python, is written in a fairly procedural style, and and some very ugly code in some places. For instance, the original Debian Maintainer code was handled by having the uid's in the database prefixed by dm: vs having a flag somewhere, and had some hardcoded variables like checking for "unstable", as well as quite a few bugs which caused interesting behavior when uploading to a non-unstable suite such as experimental or one of the proposed queues. (for those of curious, I recommend checking the dak git tree to see what the old DM code looked like, and then aside from the design, find the two major bugs which caused a lot of the weirdness with DMs). It should be stated that the last merge from redid the DM code and design sanely using the new update framework.

These issues have lead to the genesis of the dak v2 project, which is an attempt to replace dak with a module, rewritten from the ground up to be more secure and modular, although its not gotten very far as of writing. I personally don't believe that the current iteration of dak is so bad as scrapping and rewritting is necessary. Instead, I've been working to implement v2 features in dak by aggressive refactoring and cleanup, with the hope of negating the need for a rewrite.

So now thats out of the way, I bet you probably are interested in my .plan for dak. Well, lets go over I've implemented so far.

* An update database framework for dak, which will allow for easy database upgrade and migration, vs the "does it work yet?" approach to applying schema updates. Simply type dak update-db, and your done!

* 822 formatted output for queues (http://ftp-master.debian.org/new.822); this information is now used on DDPO pages

* Rewriting DM management code to have more of a brain than the previous implementation.

What's next on the TODO list

* Content file generation from the database (part of removal of apt-ftparchive, but thats another blog post ;-)).

Oh, as a side note to my current readers, my blog has changed names to "Notes from Underground", after one of my favorite novels, and futher in reference to exploring the mysterious underground that is Debian's backend code. We're also now on Planet Debian :-).

Mika and I are going to be in Europe for the next few weeks. The tentative plan seems to include these stops:

• Berlin (December 24-31) - Attending the CCC
• Stuttgart (December 31-January 3) - At/around Akademie Schloss Solitude
• Undetermined location in Slovenia (January 3)
• Belgrade (January 3-8)
• Zagreb (January 9-11)
• Amsterdam (January 11-13)
• Cambridge (and or) London (13-15)

I've got very little planned in the ways of talks or meetings with free software folks and would, as always, be open to arranging these. If you are in or near any of these places and want to plan a dinner, drinks, keysigning, talk, etc., don't hesitate to get in contact with me. I'll try to keep this wiki page updated with details on the latest plans.

I read my rss feeds through Google Reader. I like it, it is fast and easy to use. I also really like the 'share with note' button. I dislike the share button since you are sharing something without telling me why! Anyway, as a public service announcement.

NEVER SHARE XKCD COMICS ON GOOGLE READER!

Everyone who you are going to share it with already reads xkcd and 6 of your friends
have already shared it. They are wasting your time, as well as mine. (I was tempted to share this annoucement by sharing an xkcd comic.

- - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
[ 5 ] Choice 1: Reaffirm mango as the only acceptable flavour for lassi [3:1]
[ 7 ] Choice 2: Allow gulab jamun but only if you clear your plate what do you think I'm made of money or what?
[ 6 ] Choice 3: Allow gulab jamun but give what you can't eat to your sister I'm never bringing you here again
[ 3 ] Choice 4: Empower the release team to order extra naan
[ 4 ] Choice 5: Assume the green bits are really spicy
[ 2 ] Choice 6: Exclude nutritional info -- trust me you don't want to know
[ 1 ] Choice 7: Further Discussion
- - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-

This bottle was found in Mika's biosafety level 2 laboratory. To address any confusion, isoamyl alcohol is not drinking alcohol and this bottle was bought for use in a scientific lab from a scientific lab supply company. Explanations are welcome.

At Kinokuyina in New York, I noticed that Playboy was sorted into the "Men's Fashion" section of the magazine rack. Funny. I wasn't under the impression that Playboy's primary selling points included either either men or clothing.

I wrote last month about my failed first attempt to achieve a "level 3" high power rocketry certification. Last week, I learned that one of the commercial altimeters I flew for control of the ejection sequence has a firmware bug, which can cause premature ejection of the main parachute on flights above 10k feet! So it may in fact be the case that everything I did was perfect and I was simply the victim of a bug in software... how ironic! Yesterday, on my second certification attempt, I was successful! The rocket I flew this time was based on a Polecat Aerospace ten inch Goblin kit. I incorporated several modifications in my build, including additional fiberglass and carbon fiber reinforcement, and a payload bay in the nose cone. Once again, my wife Karen graced me with a parachute sewn from the Team Vatsaas design, this time a slightly larger one in burgundy and black rip-stop nylon. She incorporated several design tweaks based on her experiences sewing the first one which we'll try to write up at some point, that allowed her to sew this one in less time. The motor selected was again an Aerotech M1297W reload. The launch went perfectly, and the ascent was impressive. At apogee, the nose cone separated as planned and the drogue parachute deployed. Unfortunately, when the backup charge fired two seconds later, the main parachute also deployed. That wasn't intended... the main was supposed to deploy much lower, at 1300 feet. Luckily, the winds were light enough that the rocket touched down only about a mile downrange from the launch rail, well within the waiver distance, and was easily recovered without damage. There are three things I'll consider changing before flying this rocket again. First, the chute size calculator used to design the main parachute seems way off. The actual descent rate was around 32 feet per second, while our goal was 20. Other than that, the parachute performed admirably! Second, the premature deployment of the main at apogee could be cured by replacing the paper taped over that parachute bay with another piston capping the bay and held in with a pair of shear pins. Finally, the hard touch down snapped some of the nylon wire ties holding the batteries in place in the avionics bay. While no damage was done, and reducing the descent rate might prevent it happening again, improving the battery mounting would be an easy upgrade. For more information, see my project page for this rocket. James Russell took some pictures at the launch, including a great one of the rocket under boost just leaving the launch rail. And Jeff Lane captured video of the ascent and descent. It was a great flight and a great day, and represents a major milestone in our hobby rocket activities!

I spent more time than I would like to admit massaging the process that ultimately led to the release of the the GNU Free Documentation License 1.3 (GFDL) by the Free Software Foundation (FSF). Hours counted, it was probably one of my biggest personal projects this year. The effect is to allow wikis under the GFDL to migrate to the Creative Commons BY-SA license or, as Wikimedia's Erik M ller has proposed, to some sort of dual-license arrangement. There are many reasons for this change but the most important is that the move reduces very real barriers to collaboration between wikis and free culture projects due to license compatibility. BY-SA has become the GPL of the free culture world and Wikimedia wikis were basically locked out from sharing with a larger community, and vice-versa; projects will no longer have to choose between sharing with Wikipedia and sharing with essentially everyone else. The GFDL has done a wonderful job of helping get Wikimedia projects to where they are today and M ller's proposed switch seems, in my opinion, the best option to continue that work going forward. The FSF gets a lot of credit (and a lot of flack) for what it does. Offering to "let go" of Wikipedia -- without question the crown jewel of the free culture world -- represents a real relinquishing of a type of political control and power for the FSF. Doing so was not done lightly. But giving communities the choice to increase compatibility and collaboration by switching to a fundamentally similar license was and is, in my opinion, the right thing to do. Everyone who has worked hard to make this happen deserves the free culture movement's thanks. This list includes Richard Stallman, Brett Smith and Peter Brown of the FSF; James Vasile and Eben Moglen of the SFLC; Erik M ller, Mike Godwin and Shunling Chen of the Wikimedia Foundation. The FSF in general, and RMS in particular, deserves a huge amount of credit for what it has decided to not do in this case and for giving up control in a way that was responsible and accountable to its principles and to GFDL authors and in the interest of free culture movement more generally. It has not been easy or quick. If you support or appreciate work like this, please support the FSF and express this while doing so. Doing so is an important way to support these essential and almost inherently underappreciated efforts.