Wow, I cannot believe it has already been 2 weeks from MiniDebConf Barcelona.
It has been the first Debian event (and free software conference) that I have attended in person, and I took the opportunity to get more involved, giving a talk about translations together with Francesca Ciceri, and two lightning talks about two free software projects that I use and love and I d like to see them packaged for Debian: Pump.io and GNU MediaGoblin (videos coming soon). I also somehow-promoted Keysigning during the conference (well, in fact, I just sent some two emails to the mailing list before, and printed stickers with May I sign your key? slogan so we could keysign easily in the freetime between talks). The people I ve met some people in person, who I was following in the Debian mailing lists and identi.ca for long time (years, in some cases \o/). It has been amazing to meet Francesca Ciceri and Enrico Zini, since their blogposts and vision about Debian diversity skills have influenced very much in my involvement in Debian. It has been very important to me to be able to say THANK YOU to Tiago from the Debian video team (sorry Holger, I couldn t manage to meet you face to face), because I have learned so many things watching videos from Debconfs! Videos helped me to feel that I m part of the community, even when I cannot attend to the events, by following the streaming and being able to recognize the faces of the people and the work they do in Debian. I ve met many Debian Women, of course. I m so fan of all of them! I m enjoying a welcoming and diverse community thanks to many of them that worked since many years ago to make Debian what it is now, and faced bitter moments too. I cannot say that I engaged in many deep conversations (well, maybe some 2 or 3, and me mostly listening), but the most important thing that I keep from them was simply being there , watching and listening, enjoying the voices of the experience like Ana and Miriam, and the freshness and joy of Tassia, Solveig and Elena, for example. I ve tried to be welcoming too, I m not a newbie anymore as new people come to the group :) New projects (and renewing forces for other) Debian contributors I wanted to get more involved in the Debian contributors project and it has been a perfect opportunity to understand better all what I had read and watched about it before going to Barcelona. My plan is, apart of doing promotion as with all the projects that I use and love, to try to get translator work credited via Debian Contributors. That means to hack the l10n bot that now gathers info from the mailing lists to build the coordination pages for translators. It shouldn t be difficult to make it send that info to contributors.debian.org site, but I ll try to understand how it works and propose an elegant patch. No idea about Perl, btw, but anyway, it s a good excuse to start learning. Mediagoblin and pump.io packaging I m not sure I can help on this, but I ll keep an eye in the evolution of the Debian packaging of GNU MediaGoblin and the Pumpiverse software. I ll give moral support, at least, to the people actually working on that :) Website and Publicity team After Solveig s talk about bug triaging I ve been thinking about some bugs that I reviewed in the Website and Publicity team, and I think I should make a new round on the pending bugs to close them if they don t apply anymore, or to try to push a bit more towards a solution, if I can. Tails website translation Tails is a Debian derivative preconfigured to work out-of-the-box with privacy and anonymity features, since uses the Tor network for all the outgoing and ingoing connections.
Solveig proposed me to join the Spanish translators team at Tails. I just joined the translators mailing list, in order to help translating the Tails website into Spanish (the software is already translated, under the Tor Project). This is a new challenge from the translation point of view, since they work with PO files. And now, what? Well, first, I ll try to clean a bit my TODO list, mainly about translations, and other things not related to Debian. From now on until summer, I ll keep an eye and a hand on all the projects in which I am involved, and also I ll try to keep on engaging with the community via pump.io, the mailing lists, and IRC channels. Next summer, if I can put in order my GPG keys (long story), I ll try to join the Debian New Member process. If not, I ll try to get new keys and some signs, and then I ll apply. OTOH, thanks to the end of Windows XP support, it seems that some people are willing to migrate to any GNU/Linux distribution, and of course I m recommending Debian. Expect some blog posts about these migrations (wow, I should migrate some servers that still run Squeeze too ) and my new role of Debian help desk at job, if finally some people decide to migrate. I have gathered Debian stickers to proudly give to anyone that installs Debian in their computer!
Filed under: Events, My experiences and opinion, Videos Tagged: Communities, Contributing to libre software, Debian, English, Free Software, libre software, MediaGoblin, Moving into free software, pump.io, translations

Continuing with my tendency to vent about stuff, today I want to talk about telephony. Since a few years ago, I need to use different VoIP providers to keep in touch with friends and family, in different parts of the world. So, I have a DID in Argentina (bought trough the excellent DIDWW), and another one in Ireland (which came for free when I was using BlueFace for call termination). I also have a service to handle outbound calls (FlowRoute), but it is not necessarily the only one I use, as cost and quality of Internet calls vary wildly. I have also used several Betamax providers, the aforementioned BlueFace, tried Netelip, etc. This results in having soft-phones installed in my mobile devices and laptop, and a hardware SIP phone that I carry around; all of them having configurations for at least 3 different providers. This does not lead to hilarity. In light of this, it's been a long time since I want to set up my own SIP router to be able to handle all of this, and be able to register to a single SIP proxy that will handle all the complexity. Last Friday, the Irish DID decided to stop working. It turns out, that since I don't have my own setup, I was using that provider as a kind of hub, with their provided voicemail, and terminating the Argentinian DID there. So the damage was big. This made me spend way too many hours during the weekend trying to set up some SIP solution. And I am not pleased.

Asterisk First, I went with the old and known Asterisk. The default installation in Debian puts 95 configuration files in /etc/asterisk, which you are supposed to review and adjust. Yes, you've read correctly: ninety-five different configuration files. None of them having anything close to a sensible explanation of their syntax or function. Also, not a remote hint of consistency. I could not find any configuration helper in the Debian archive, just hundreds of PHP-based projects scattered around the web. All the started guides I've found only guided you for the most basic tasks, but did not give you a way to have a functioning system. Needless to say, after a short time I grew tired of this, and decided to try something else.

Way too many options After this, I have spent an inordinate amount of hours, just trying to comprehend the difference between the gazillion different VoIP systems out there, I am still struggling to see that. Even if I understand that X is not a PBX, I don't exactly need a PBX, and most products deliver at least some of the features I need. It seems none of them makes a good job of just explaining what you can or can't do with their software. Documentation is awful in all the projects I researched. When it is there at all, it is incomplete, maybe super detailed at points, but in most cases, there is just no big picture view of the system to just start understanding how things work, and how to find your way. Sadly, not even the distros seems to be able to put a list of "recommended VoIP software for different needs".

Yate Finally, I've found YATE (Yet Another Telephony Engine). It seemed promising: not too bloated, fairly extensible, and scriptable in a few languages! Sadly, after many hours, it turned out to be a fiasco. The documentation seems decent, until you realise there are many key details left out. Basic information about how a call is handled cannot be found anywhere. Using the scripting power, I was able to find out at least the variables that were available, but that was not enough. I found a mailing list (with the worst archive reader I've seen in ages), where people made the very same questions I have, and nobody has replied. In years. So here I am, stuck with not being able to tell if a call is coming from a random host on the internet, or one of my DIDs, or one of the authenticated clients. I guess I will have to start from scratch with Yet Another (Another) Telephony Engine.

I've been referring to Anshu as "my girlfriend" in all my blog posts because I haven't gotten around to writing this post yet. I've finally gotten around to it. Anshu and I met at a speed dating event 8 months ago. I quite enjoyed the speed dating experience, and having done it, would prefer it over Internet dating. I think it helped that at the time I was working from home, getting above and beyond the amount of alone time that my introversion required for me to recharge, so I was in the right frame of mind for it. I did pretty well, I got 6 matches from the night, one of which was Anshu. Anshu is an Indian-Australian dual national. She emigrated about 12 years ago to do her Masters degree here, and decided to stay. This is my first inter-ethnic relationship, and it's been a very interesting expansion of my cultural horizons. Anshu is vegetarian, so I've expanded my vegetarian cooking repertoire significantly since we've been seeing each other. I already do "Meatless Monday" with Zoe, so it wasn't that difficult a transition for me.

Zoe slept really well last night, and had a good breakfast of porridge this morning. We biked to Kindergarten for the first time in ages, as it wasn't raining. Drop off went nice and smoothly. I can't believe this is the last week of term 1 already. Today was an exceptional day, because Sarah had the day off, and picked up Zoe from Kindergarten instead of me. As tonight Zoe is with her, I got about 3 extra hours up my sleeve. The house was a bit of a mess, I decided to switch today with my Wednesday "clean the house day" and use the extra time to do a more thorough clean. Part way through that, an acquaintance, who recently separated from his wife, dropped by for a chat. We ended up chatting for about 3 hours, so I dialed back my cleaning to something more standard. My business debit card arrived in the mail today. It was exciting to see something with my name and my company name on it. I've scheduled a bank transfer to fund my business with the first loan I'll be making to it, so it'll have some cash as of the start of second quarter. All I need now is the cheque book to arrive, and I can go pay the patent lawyer a visit. I had contemplated going for a run tonight before my yoga class, but I ended up faffing around with trying to fix the song order on the USB stick that has all of Zoe's music on it. The new head unit isn't playing one album in the right order, and it's phenomenally annoying. To this end, I discovered fatsort, which is a godsend. Yoga was in the new studio tonight for the first time. I'm really happy that my teacher is growing her business. The new studio is even closer to home than the old one, which is lovely.

Review: Sundiver, by David Brin

Series:	Uplift #1
Publisher:	Bantam
Copyright:	February 1980
Printing:	September 1995
ISBN:	0-553-26982-8
Format:	Mass market
Pages:	340

Sundiver is the first book of Brin's Uplift series, which I think it's fair to say are the books that made his reputation as an author. It's less well-known than the later sequels Startide Rising and The Uplift War for reasons that I'll get into in a moment. This was a re-read; I've read the first Uplift series before (and Startide Rising separately before that), but not in many years, and I wanted to re-read them and review them. I haven't finished doing that yet, several months after I re-read Sundiver, largely because this book wasn't as enjoyable as I remembered. The Uplift series is set in a heavily populated galaxy with a multitude of alien races. It follows the SF alien life pattern where the galaxy was well-populated and fully developed long before humans discovered it. The Earth is a relatively obscure backwater, and humans are expected to adopt to and follow the rules and restrictions that the other races had long-since established. This primarily means a complex and very formal system of caste and patronage: species brought to sapience by the technology of their patrons are expected to serve their patron races for millennia, and one's status in the galaxy is determined by the length of those patronage chains and the number of species one has fostered in turn. As is typical for stories of this sort, humans break the rules in unexpected ways. They have no known patrons, having apparently evolved sapience entirely on their own (although the galactic races are quite dubious of this theory). And they have uplifted two species to sapience (chimpanzees and dolphins) before their discovery by the rest of galactic civilization, although in fairly primitive ways and not properly by galactic standards. Set against this background, Sundiver is a science fiction puzzle story of a fairly old style. The protagonist, Jacob Demwa, is a scientific investigator who retired after a tragedy that killed his love. He's recruited out of that retirement and into this plot by an alien who is sympathetic to humans. A human exploration mission into the chromosphere of the Sun, treated as ridiculous by most of the galactics since the shared Library Institute certainly contains more information about stars than human technology could possibly uncover, has found strange and apparently sapient creatures living there: flocks of cattle-like creatures that are apparently being herded. There is no reference to such star-dwellers in the Library, which raises the possibility that humans have discovered something novel. That would be quite a coup against the galactics. But after the destruction of one of the solar exploration ships, it starts looking like these creatures are hostile. Jacob reminded me of a mix between a Larry Niven short story protagonist, working through the practical impact of a physics puzzle, and Isaac Asimov's Elijah Baley. What exactly is going on, both scientifically and politically, remains unclear for nearly the entire book. Both Jacob and the reader are constantly forming and then discarding hypotheses as events overtake them. The stakes are more interesting than a lot of science fiction novels: rather than survival or war, the stakes are prestige, influence, and status, with subtle but possibly vital effects on what position humans will take among the other species of the galaxy. All this sounds promising, and is why I remembered this book fondly. Unfortunately, re-reading it was a disappointing experience on several fronts. First, the characterization varies between trite and stereotyped. The aliens suffer from the standard alien characterization problem: each of them is an exemplar of their species, and all of the aliens feel like archetypes. While there are some twists in the inter-alien politics, one never gets a sense of the aliens as varied and complex societies in their own right. The humans are more varied, but that primarily means varieties of irritating. The worst is Peter LaRoque, a journalist who is set up as a villain of the story, and who is such an unremitting and over-the-top stereotype of everything possibly bad about journalists (and French people) that every scene containing him felt like someone scraping fingernails on a chalkboard. The other characters are a bit better, but not by much. Jacob himself has a bizarre, semi-mystical psychological problem from trauma that seems to give his amoral subconscious a life of its own. Brin appears to be setting this up to have major plot significance, but it never made any sense to me, didn't matter much in the end, and seems to mostly be an excuse for Jacob's hypercompetence. Sundiver's treatment of female characters also annoyed me enough to be worth a mention. The primary female character, Helene, is clearly intended to be a strong character with her own agency (she's both station commander and a starship captain), and Brin makes a lot of the humans switching to different words than male and female as a sign of a more egalitarian future. But this all feels skin-deep. The inevitable romance is all about Helene's attractiveness and ability to listen to Jacob, her logic is described as unscientific, and I got more and more annoyed by her portrayal as the book went along. She's not entirely without agency in the story, but she's much closer to a damsel in distress than the independent character Brin appeared to be trying for. It's hard to shake the feeling that she's being persistently belittled by the story. But this is a scientific puzzle story more than a mystery; characterization would be nice, but isn't strictly required. On re-read, the part of Sundiver that annoyed me the most was how much of a letdown the plot resolution was. I'm going to avoid any specific spoilers here, but I found the ending of both quite disappointing and a sign of the major problem with this series as a whole. The setup over-promises and Brin fails to deliver, a pattern that will repeat itself in this series. We get tantalizing hints of a new solar species, of revelations about the past of humanity, of deep galactic politics, and of vast knowledge contained in the Library that humans don't yet have access to. We get superficial archetypes for characters, politics that seem more like the bickering of children, plot twists that persistently take the story in more mundane and less interesting directions, and a sense of wonder, or lack thereof, that feels more like a Scooby Doo story than what I expect from science fiction. Some of the plot twists are unexpected and almost add some interest to the story, but don't make enough sense in the context of the story to be satisfying. And, of course, there's an climactic action sequence involving physical combat, as is required of all good Star Trek (original series) episodes. (I was waiting for Jacob's shirt to fall off.) The problem I have always had with Brin as a writer is that his ideas are far better than his ability to write characters and plots. In the hands of a better author, the Uplift universe background has so much potential. And I think Brin is a better author a few years later; my recollection is that both Startide Rising and The Uplift War do a better job of delivering on their promises. But Sundiver is deservedly forgettable. The good ideas rarely go anywhere beyond the obvious, the characters are irritating and often don't make sense, and the story is disappointing. I can't say I'm sorry to have read it, since my memory edited it down into a much better story, but I can only recommend it as background for later, better books. Rating: 4 out of 10

I m currently working on a wiki converter allowing me to transfer old TWiki wikis (hosted on picoforge) to MediaWikis hosted on FusionForge. Unlike existing tools that I ve found that more or less target the same needs, mine will address two peculiarities :

• using MediaWiki s API to perform the import, where many tools seemed to use SQL requests: this should allow non-administrator users to do the job,
• importing to wikis of projects hosted on FusionForge instances, even when the project is not public, which means that the API calls need to authenticate to FusionForge first.

The tool is written in Python, and will include my own crappy wiki syntax converter in Python, instead of spawning existing Perl scripts, as others did. It may happen to work for FosWiki too, but I don t intend to use it beyond our old TWiki installations, for a start. Stay tuned for more progress updates. Edit: I ve now released a first version.

Debian Edu / Skolelinux keep gaining new users. Some weeks ago, a person showed up on IRC, #debian-edu, with a wish to contribute, and I managed to get a interview with this great contributor Roger Marsal to learn more about his background. Who are you, and how do you spend your days? My name is Roger Marsal, I'm 27 years old (1986 generation) and I live in Barcelona, Spain. I've got a strong business background and I work as a patrimony manager and as a real estate agent. Additionally, I've co-founded a British based tech company that is nowadays on the last development phase of a new social networking concept. I'm a Linux enthusiast that started its journey with Ubuntu four years ago and have recently switched to Debian seeking rock solid stability and as a necessary step to gain expertise. In a nutshell, I spend my days working and learning as much as I can to face both my job, entrepreneur project and feed my Linux hunger. How did you get in contact with the Skolelinux / Debian Edu project? I discovered the LTSP advantages with "Ubuntu 12.04 alternate install" and after a year of use I started looking for an alternative. Even though I highly value and respect the Ubuntu project, I thought it was necessary for me to change to a more robust and stable alternative. As far as I was using Debian on my personal laptop I thought it would be fine to install Debian and configure an LTSP server myself. Surprised, I discovered that the Debian project also supported a kind of Edubuntu equivalent, and after having some pain I obtained a Debian Edu network up and running. I just loved it. What do you see as the advantages of Skolelinux / Debian Edu? I found a main advantage in that, once you know "the tips and tricks", a new installation just works out of the box. It's the most complete alternative I've found to create an LTSP network. All the other distributions seems to be made of plastic, Debian Edu seems to be made of steel. What do you see as the disadvantages of Skolelinux / Debian Edu? I found two main disadvantages. I'm not an expert but I've got notions and I had to spent a considerable amount of time trying to bring up a standard network topology. I'm quite stubborn and I just worked until I did but I'm sure many people with few resources (not big schools, but academies for example) would have switched or dropped. It's amazing how such a complex system like Debian Edu has achieved this out-of-the-box state. Even though tweaking without breaking gets more difficult, as more factors have to be considered. This can discourage many people too. Which free software do you use daily? I use Debian, Firefox, Okular, Inkscape, LibreOffice and Virtualbox. Which strategy do you believe is the right one to use to get schools to use free software? I don't think there is a need for a particular strategy. The free attribute in both "freedom" and "no price" meanings is what will really bring free software to schools. In my experience I can think of the "R" statistical language; a few years a ago was an extremely nerd tool for university people. Today it's being increasingly used to teach statistics at many different level of studies. I believe free and open software will increasingly gain popularity, but I'm sure schools will be one of the first scenarios where this will happen.

The annoucement below just went to the R-SIG-Finance list. More information is as usual at the R / Finance page: See you in Chicago in May!

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

Although there wasn't too many comments on my what would you pay for? post I did get some mails. I was reminded about this via Mario Langs post, which echoed a couple of private mails I received. Despite being something that I take for granted, perhaps because my hosting comes from the Bytemark, people do seem willing to pay money for DNS hosting. Which is odd. I mean you could do it very very very cheaply if you had just four virtual machines. You can get complex and be geo-fancy, and you could use anycast on a small AS, but really? You could just deploy four virtual machines0 to provide a.ns, b.ns, c.ns, d.ns, and be better than 90% of DNS hosters out there. The thing that many people mentioned was Git-backed, or Git-based DNS. Which would be trivial if you used tinydns, and no much harder if you used bind. I suspect I'm "not allowed" to do DNS-things for a while, due to my contract with Dyn, but it might be worth checking... ObRandom: Beat me to it. Register gitdns.io, or similar, and configure hooks from github to compile tinydns records. In other news I started documenting early thoughts about my caching reverse proxy, which has now got a name stockpile. I wrote some stub code using node.js, and although it was functional it soon became callback hell:

• Is this resource cachable?
• Does this thing exist in the cache already?
• Should we return the server's response to the client, archive to memcached, or do both?

Expressing the rules neatly is also a challenge. I want the server core to be simple and the configuration to be something like:

is_cachable ( vhost, source, request, backened )
 
    /**
     * If the file is static, then it is cachable.
     */
    if ( request.url.match( /\.(jpg png txt html? gif)$/i ) )  
        return true;
     
    /**
     * If there is a cookie then the answer is false.
     */
    if ( request.has_cookie? )   return false ;  
    /**
     * If the server is alive we'll now pass the remainder through it
     * if not then we'll serve from the cache.
     */
    if ( backend.alive? )  
        return false;
     
    else  
        return true;
     
 

I can see there is value in judging the cachability based on the server response, but I plan to ignore that except for "Expires:", "Etag", etc ,etc) Anyway callback hell does make me want to reexamine the existing C/C++ libraries out there. Because I think I could do better.

Since I have to do a lot of backports for the OpenStack packages in Debian Wheezy, I got tired of doing them by hand. Therefore, I have created a script to automate the task. I m not particularly proud (or ashamed) of that script, but I just want to share it. Probably some fellow readers will happily provide me with enhancements and ideas. Note that the use of mk-build-deps implies that the equivs package has to be installed. What I do is run this build-backport script within a cowbuilder, to make sure I always have a clean backport environment.

#!/bin/sh
set -e
set -x
PKG_NAME=$ 1 
BPO_DISTRO=wheezy-backports
BPO_POSTFIX=bpo70+1
REPO_ROOT=/home/ftp
REPO_DEST=icehouse-backports
if [  whoami  = "jenkins" ] ; then
        BUILD_ROOT=/var/lib/jenkins/jobs/openstack-pkg-tools/builds/$ BUILD_NUMBER 
else
        BUILD_ROOT=~/sources
fi
# Get info from packages.debian.org
PKG_INFO_FILE= mktemp -t pkg_info_file.XXXXXX 
wget --no-check-certificate -O $ PKG_INFO_FILE  http://packages.debian.org/sid/$ PKG_NAME 
DEB_VERSION= rmadison $ PKG_NAME    grep sid   awk ' print $3 ' 
UPSTREAM_VERSION= echo $ DEB_VERSION    cut -d'-' -f1    cut -d":" -f2 
DSC_URL= cat $ PKG_INFO_FILE    grep dsc   cut -d'"' -f2 
rm $ PKG_INFO_FILE 
# Prepare build folder and go in it
MY_CWD= pwd 
rm -rf $ BUILD_ROOT /$PKG_NAME
mkdir -p $ BUILD_ROOT /$PKG_NAME
cd $ BUILD_ROOT /$PKG_NAME
# Download the .dsc and extract it
dget -d -u $ DSC_URL 
PKG_SRC_NAME= ls *.dsc   cut -d_ -f1 
PKG_NAME_FIRST_CHAR= echo $ PKG_SRC_NAME    awk ' print substr($0,1,1) ' 
dpkg-source -x *.dsc
echo "Now running mk-build-deps -i $ PKG_SRC_NAME -$ UPSTREAM_VERSION /debian/control"
mk-build-deps -i $ PKG_SRC_NAME -$ UPSTREAM_VERSION /debian/control
# Build the package as backport using cowbuilder
cd $ PKG_SRC_NAME -$ UPSTREAM_VERSION 
dch --bpo -m "Backported for $ BPO_DISTRO ."
dpkg-buildpackage
cd ..  
PKG_FINAL_DEST=$ REPO_ROOT /debian/pool/$ REPO_DEST /main/$ PKG_NAME_FIRST_CHAR /$ PKG_SRC_NAME 
ssh archive.gplhost.com "mkdir -p $ PKG_FINAL_DEST "
scp *.orig.tar.* *$ DEB_VERSION ~$ BPO_POSTFIX * archive.gplhost.com:$ PKG_FINAL_DEST 

As some of you know, I ve started to take Sundays off, and this is mostly a post to continue to hold myself accountable, and to assure everyone that yes! That s still going on! I ve found my Saturdays to be more productive, and my Sundays to be much more enjoyable and stress-free. For those that don t know, I m not even using any computer through my Sundays (hilariously dubbed paul-tag by my friends (only Germans would find this funny, though :) )), but my tablet and phone seem to be OK (but I actively avoid email) If anyone s on the fence, I highly recommend doing this, it s really great.

So a good friend of mine talked about something in the debian-private mailing list. And we should not disclose that something outside such a sensible space without his approval. But Jakub is right. Once the discussion goes over to only messages talking about non-private stuff, the discussion should be moved to a non-private area. After all, we will not hide problems yada yada, right? So, not knowing where in the Debian lists this should go to, it will land on my blog, reformatting mail to make sense in this media:

Luca Filipozzi dijo [Wed, Mar 26, 2014 at 03:36:49PM +0000]:

Or don't use a mouse. When I started getting shoulder strain from using a mouse too much, I switched to an Adesso touchpad keyboard and was very happy with the positive outcome. I'm a touch (that's punny) less efficient with the touchpad compared to a mouse, but the lack of permanent injury and ongoing pain is worth it.

Right. I also have this keyboard (same brand even, different model). The keyboard is not that good (keys are not as smooth as in my previous, stock-Dell keyboard), but not having to move my right hand just to feed the rodent has made my back way way happier. I even feel better using a trackpad than a mouse (mabye because I use too much my netbook?). Luca, just out of curiosity: Did you ever manage to recognize the keyboard under the Synaptics driver, or to get it running under ChordMiddle or Emulate3Buttons? I had to fall to a ugly hack, mapping the "XF86Search" key to the middle button by telling my window manager (i3) to "bindsym X86Search exec xdotool click 2".

[ this can be declassified at any time ]

my contributions to this thread too...

my contribution unclassified, also

My classifications remain contributed. Do as you will with my bits of this message.

Recently I ve been doing some hacking for Chamilo LMS, a Free Software E-Learning system. For various reasons I had to do this on OSX, which meant setting up a web development environment. This lead me to MAMP, an OSX bundle with Apache + MySQL + PHP. However MAMP had many weird quirks that forced me to maintain a local set of patches just to get things working. I finally had the time to look into a saner option, take some notes in the process, and write a blog post. A popular alternative was using OSX s installed Apache with a newer PHP version from Homebrew. This sounded dangerous because you can t just apt-get install --reinstall apache if you break something. I preferred a pure Homebrew installation also because:

• No need for root. Everything is user writable in /usr/local.
• Vanilla versions for everything, and easy to keep up to date with upstream.
• Easy to destroy and replicate.
• Usable, non root, PEAR.
• You would brew most of this for a hybrid setup anyway.

I couldn t find a simple and straightforward resource for this specific setup, so I present you with my tutorial/recipe to get Apache + MySQL + PHP, via Homebrew, running on OSX. I took these notes on OSX 10.7.5 while building Apache/2.2.26 (Unix) with PHP 5.5.10 and MySQL 5.6.16. #1- A healthy Homebrew install First of all you need to install Homebrew. Head over to Homebrew s homepage for instructions. Even if you already have it, I recommend a health check and an update+upgrade: $ brew doctor
$ brew update && brew upgrade Pay attention to whatever that says and follow the instructions if there s any. You also want to add Homebrew binary paths to your $PATH, even if the directories don t exist yet. Add this to .bash_profile or whatever your shell uses:
PATH=/usr/local/opt/php55/bin/:/usr/local/sbin:/usr/local/bin:$PATH #2- PHP and all its additional recipes The PHP recipes are maintained in a different repo, but don t worry, this is not a duct taped chaos, it s properly maintained: $ brew tap jgonzales/php
$ brew install php55 --with-intl You might want to add --with-pgsql if you want to work with PostgreSQL. MySQL, Apache and CLI support is built by default. After the installation there are two quick things to do. First, timezone configuration:
(editing /usr/local/etc/php/5.5/php.ini)
date.timezone = America/Lima (or whatever works for you) And second, PEAR permissions:
$ chmod -R ug+w /usr/local/Cellar/php55/5.5.10/lib/php #3- Setting up boring MySQL Now let s brew MySQL:
$ brew install mysql With that done, go ahead and start the server so we can initialize the basic tables, and secure the installation defaults:
$ unset TMPDIR
$ mysql_install_db --verbose --user= whoami --basedir="$(brew --prefix mysql)" --datadir=/usr/local/var/mysql --tmpdir=/tmp
$ mysql.server start
$ mysql_secure_installation

Remember: You shouldn t use sudo, so be careful with your muscle memory! #4- Brewing Apache (httpd) And finally, it s time to brew Apache. You can do so with:
$ brew install httpd When that s done burning your lap, you can start configuring Apache. I chose to keep httpd.conf as pristine as possible and do everything in a VirtualHost. Remember you need to run this on something other than port 80 because you won t run httpd as root:

• httpd.conf changes in a GitHub gist (diff)
• httpd-vhosts.conf is in this other GitHub gist (full file)

Note that I m enabling virtual hosts and using my own paths. If you want to configure Apache differently, you probably know what you are doing. So, get off my lawn you damn kid. #5- Brownie points: PHPMyAdmin In my virtual hosts configuration I included some lines for PHPMyAdmin. That s because I m old school and I love PHPMyAdmin. You can follow into my wrinkled foot steps with:
$ brew install phpmyadmin #6- Profit You can check everything is fine by creating an index.php with a call to phpinfo() inside your configured root from httpd-vhosts.conf. Make sure OSX s Apache is not running and start (or restart) the servers:
$ apachectl start/stop/graceful(restart)
$ mysql.server start/stop/restart Now open go to http://localhost:8000/ and http://localhost:8000/phpmyadmin. Enjoy your success. Maybe do a victory dance: This might seem like a lot of work, but it s fairly quick with this cheat sheet. It s also very safe and easy to keep updated with brew update && upgrade. A final note: All the suggestions and instructions that are printed after installing each package can be read again with brew info <recipe>. No need to write them down. Happy hacking!

I am often asked about my accent . The most common guess is that it s a British accent, while I lived in London for about a year I don t think that my accent changed much during that time (people have commented on the way I speak since I was in primary school). Also there isn t a British accent anyway, the Wikipedia page of Regional Accents of English has the first three sections devoted to accents in the island of Britain (and Northern Ireland is part of the United Kingdom which people often mean when they sat Britain ). The Received Pronounciation is the main BBC accent and the accent that is most associated with Britain/England/the UK (which are three different things even though most people don t know it) and I don t think that I sound like that at all. I ve had various other guesses, the Netherlands (where I lived for a few years but mostly spoke to other foreigners), New Zealand (which I ve visited a couple of times for conferences), Denmark (the closest I got was attending a conference in Sweden), and probably others I can t remember. If I actually had developed an accent from another country then it would probably be from the US. The amount of time I ve spent watching Hollywood movies and watching US TV shows greatly exceeds the amount of time I ve spent listening to people from all other countries. The fact that among all the people who wanted to try and guess where my accent supposedly originated none have ever included the US seems like strong evidence to suggest that I don t have any sort of accent that really derives from another country. Also I have never had someone mistake me for being a resident of their own country based on accent which seems like clear evidence that all claims about me having a foreign accent are bogus. Autism forums such as WrongPlanet.net [1] always turn up plenty of results for a search on accent . In such discussions it seems that a British accent is most common mistake and there are often theories raised about why that is often related to speaking in a formal or precise way or by using a large vocabulary. Also in such discussions the list of countries that people supposedly have accents from is very inclusive, it seems that any country that the listener has heard of but doesn t know that well is a good candidate. The fact that Aspies from outside the US are rarely regarded as having an American accent could be due to the fact that Hollywood has made most of the world population aware of what most American accents sound like. Also if I really had some sort of accent from another country then probably someone would comment on that when I m outside Australia. When I m travelling people tend to recognise my accent as Australian, while it doesn t please me when someone thinks that I sound like Crocodile Dundee (as happened in the Netherlands) it might not be entirely inaccurate. This is Annoying The way the issue of accent is raised is generally in the form of people asking where I m from, it seems to imply that they don t think I belong in Australia because of the way I speak. It s particularly annoying when people seem unable to realise that they are being obnoxious after the first wrong guess. When I reply no to the first are you from $COUNTRY question and don t offer any further commentary it s not an invitation to play 20 questions regarding where I m supposedly from, it s actually an indication that I m not interested in a conversation on that topic. A Social Skills 101 course would include teaching people that when someone uses one-word answers to your questions it usually means that they either don t like your questions or don t want to talk to you. Social Skills vs Status The combination of persistence and misreading a social situation which are involved when someone interrogates me about my supposed accent are both parts of the diagnostic criteria for Autism. But I generally don t get questions about my accent in situations where there are many Aspies (IE anything related to the Free Software community). I think that this is because my interactions with people in the Free Software community are based around work (with HR rules against being a jerk) and community events where no-one would doubt that I belong. I mostly get questions about my accent from random middle-class white people who feel entitled to query other people about their status who I meet in situations where there is nothing restraining them from being a jerk. For example random people I meet on public transport.

• [1] http://www.wrongplanet.net/

My late biological maternal grandmother ("Nana"), remarried late in her life to a long-time friend named Bryce. I was probably an early teenager. He was a nice guy, and I kept in loose contact with him after my Nana passed away. After my Nana passed away, he moved out of the retirement home he'd been living in with my Nana, and in with one of his sons. Sometime before I moved back to Australia, in ailing physical health, he moved from his son's place into Masonic Care's aged-care hostel in Sandgate. He turned 90 last year. Mentally, he's doing pretty good. Physically, he's very wobbly on his legs. He's had a few falls, which was the main catalyst for moving from his son's place to the aged-care hostel. Other than that, he's in pretty good physical health though. I remember the first time I visited him in the hostel. After I left, I wept uncontrollably. Here was a man who was literally just waiting out the rest of his life in a small cupboard of a room. I was appalled at how small the room was, and the fact that he was just sitting around waiting to die really upset me. I've visited him a few times since I've been back. I've taken him over to my parent's place when I've taken Zoe to visit them, just so he gets out. I should say that I'm sure his own family do spend some time with him, so it's not like he's spending all his time rotting in this place, but probably still a fair chunk of it. Growing old sucks. Yesterday, when the weather forecast for today was looking like it was going to be pretty wet and miserable, I decided I'd use the day to take Zoe to Underwater World (which I've since learned has rebranded it self as "Sea Life: Mooloolaba". I had the presence of mind to call up Bryce yesterday to see if he'd like to join us today. We had to pass in his general direction to get up there, so it wasn't particularly out of my way. He informed me that he was now in a wheelchair, which I thought was fine for this excursion. So this morning, after we got ourselves going, we stopped at Sandgate to pick up Bryce, and made it to Underwater World by about 10am. I was a bit leery of the drive, because from home, it was another 30 minutes on top of the drive to Wet and Wild, and 15 minutes on top of the drive to Sea World, so I wasn't sure how Zoe would take that length car trip. It turned out that she took it pretty well. She started getting a bit restless in the last 30 minutes, but it was manageable. I was a little apprehensive about how wrangling Zoe and looking after a frail 90 year old in a wheelchair was going to work out. It turned out it worked out just fine. I could leave Bryce wherever he was, if I had to chase after Zoe, and Zoe quite liked helping push the wheelchair around. Towards the end of the day, when she got tired, I could just pop her in Bryce's lap, and push the pair of them around. It was a really good outing. I have only vague memories of visiting the place in my childhood, and it's become significantly better since then. Zoe really enjoyed going through the glass tunnels under the main ocean exhibit. We did several laps of that. We were fortunate enough to catch the sting ray feeding almost immediately upon arrival, and we also saw the seal show and made the otter feeding. The place was more focused on salt water aquatic life, hence the name, but there was also some freshwater exhibits. I never thought that much of the Monterey Aquarium, much preferring the California Academy of Science's aquariums, especially in terms of drive time accessibility. If you ignore the freshwater/salt water diversity, I think Sea Life is even better than the California Academy of Sciences. We left at about 2pm, and after a lot of hunting around, tracked down the photo they took when we entered, and then drove home closer to 3pm. To my surprise, Zoe didn't fall asleep immediately, but she did fall asleep on the way back to Bryce's place. She woke up to say goodbye to him, and then we drove home, stopping off in the Valley to check my post office box along the way, and arrived back home about 15 minutes before Sarah arrived to pick her up. It ended up being a very full day. Bryce really enjoyed himself, and I felt really happy that I was able to relatively easily brighten up his day. I've resolved to try another such outing again, I just need to figure out what to do. I thought I'd try for a 10km run, but it started to rain at the 4km mark. I was also not feeling particularly confident about lasting the distance, so I decided to just turn it into a 5km run instead.

Packaging LAVA for Debian unstable with notes on other distributions I ve been building packages for LAVA on Debian unstable for several months now and I ve been running LAVA jobs on the laptop and on devices in my home lab and on an ARMv7 arndale too. Current LAVA installations use lava-deployment-tool which has only supported Ubuntu 12.04 LTS Precise Pangolin. There has been a desire in LAVA to move away from a virtual environment, to put configuration files in FHS compliant paths, to use standard distribution packages for dependencies and so to make LAVA available on more platforms than just precise. Packaging opens the door to installing LAVA on Debian, Ubuntu, Fedora and any other recent distribution. Despite LAVA currently being reliant on 12.04 Precise, some of the python dependencies of LAVA have been able to move forward using the virtual environment provided by builtout and pypi. This means that LAVA, as packaged, requires a newer base OS suite than precise for Ubuntu, the minimal base is Saucy Salamander 13.10 and for Debian it would be Jessie (testing) although there is currently a transition ongoing in Debian which means that uwsgi is not in testing and Debian unstable would be needed instead. The work to migrate configuration snippets out of deployment-tool and to ensure that the tarball built using setuptools contains all of the necessary files for the package has already been done. The packaging itself is clean and most of the work is done upstream. There is, as ever, more to do but the packages work smoothly for single install LAVA servers where the dispatcher is on the same machine as the django web frontend. The packages have also migrated to Django1.6, something which is proving difficult with the deployment-tool as it has not kept pace with the changes outside the virtual environment, even if other parts of LAVA have. LAVA will be switching to packages for installation instead of deployment-tool and this will mean changes to how LAVA works outside the Cambridge lab. When the time comes to swich to packaging, the plan is to update deployment-tool so that it no longer updates /srv/lava/ but instead migrates the instance to packages. Main changes

1. Configuration files move into /etc/
   • Device configuration files /etc/lava-dispatcher/devices/
   • Instance configuration files/etc/lava-server/
2. Log files move into /var/log/
   • Adding logrotate support no more multi-Gb log files in /srv/lava/
3. Commitment to keeping the upstream code up to date with dependencies
4. Support for migrating existing instances, using South.
5. Packaging helpers
   • add devices over SSH instead of via a combination of web frontend and SSH.
   • Developer builds with easily identifiable version strings, built as packages direct from your git tree.
6. New frontend
   • Although django1.6 does not change the design of the web frontend at all, LAVA will take the opportunity to apply a bootstrap frontend which has greater support for browsers on a variety of devices, including mobile. This also helps identify a packaged LAVA from a deployment LAVA.
7. Documentation and regular updates

The Plan LAVA has made regular releases based on a monthly cycle and these will be provided as source tarballs at http://www.linaro.org/downloads/ for distributions to download. The
official monthly release and any intervening updates will be made available for distributions to use for their own packaging. Additionally, Debian packages will be regularly built for use within LAVA and these will be available for those who choose to migrate from Ubuntu Precise to Debian Jessie. LAVA will assist maintainers who want to package LAVA for their distributions and we welcome patches from such maintainers. This can include changes to the developer build support script to automate the process of supporting development outside LAVA. Initially, LAVA will migrate to packaging internally, to prove the process and to smooth out the migration. Other LAVA instances are welcome to follow this migration or wait until the problems have been ironed out. The Issues

• Remote workers this is work to be completed during the migration to packaging within LAVA as well as pending work upstream on the internals of the connection between a remote worker and the master scheduler. Expect some churn in this area whilst the code is being finalised. A lava-worker package is being prepared which borrows enough code from lava-server to run the lava-scheduler-daemon on the remote worker, until such time as the remote worker communications are refactored.
• Integration there are plans to integrate some of the modules which LAVA uses which are not commonly packaged: linaro-dashboard-bundle and linaro-django-xmlrpc
• OpenID the certificates which underpin OpenID use with Launchpad have been removed in Debian and LAVA is currently investigating alternatives.
• json-schema-validator currently has a broken test suite, so this will need to be patched by LAVA to allow the package to build. The code may be replaced with a different validator if the issue persists.
• namespace handling the current package install is unnecessarily noisy with complaints about the lava namespace. This will need a fix but does not affect current operation.
• Unit tests LAVA is working hard to add a much larger coverage of internal unit tests. These use a temporary database which is not generally available during the build of a distribution package. LAVA is already running continuous integration tests to ensure that these tests continue to pass and the packages will gain documentation on how to run these tests after installation.

Build Dependencies For Debian unstable, the list of packages which must be installed on your Debian system to be able to build packages from the lava-server and lava-dispatcher source code trees are:

debhelper (>= 8.0.0) python   python-all   python-dev   python-all-dev 
python-sphinx (>= 1.0.7+dfsg)   python3-sphinx python-mocker 
python-setuptools python-versiontools

(python-versiontools may disappear before the packages are finalised) In addition, to be able to install lava-server, these packages need to be built from tarballs released by Linaro (the list may shorten as changes upstream are applied)

linaro-django-pagination, 
python-django-restricted-resource (>= 0.2.7), 
lava-tool (>= 0.2), lava-utils-interface (>= 1.0), 
linaro-django-xmlrpc (>= 0.4),
python-versiontools (>= 1.8),
python-longerusername,
linaro-dashboard-bundle (>= 1.10.2), 
lava-dispatcher (>= 0.33.3)
lava-coordinator, lava-server-doc

The list for lava-dispatcher is currently:

python-json-schema-validator, lava-tool (>= 0.4), 
lava-utils-interface, linaro-dashboard-bundle (>= 1.10.2), 

The packages available from my experimental repository are using a new packaging branch of lava-server and lava-dispatcher where we are also migrating the CSS to Bootstrap CSS. Installing LAVA on Debian unstable
$ sudo apt-get install emdebian-archive-keyring
Add the link to my experimental repository (amd64, i386, armhf & arm64) to your apt sources, e.g. by creating a file /etc/apt/sources.list.d/lava.list containing:

deb http://people.linaro.org/~neil.williams/lava sid main
Update with the new key

$ sudo apt-get update
It is always best to install postgresql first:

$ sudo apt-get install postgresql
There are then three options for the packages to install (Please be careful with remote worker setup, it is not suitable for important installations at this time.):

1. Single instance, server and dispatcher with recommended tools
   apt-get install lava
   Installs linaro-image-tools and guestfs tools.
2. Single instance, server and dispatcher
   apt-get install lava-server
   Installs enough to run LAVA on a single machine, running jobs on boards on the same LAN.
3. Experimental remote worker support
   apt-get install lava-worker
   Needs a normal lava-server installation to act as the master scheduler but is aimed at supporting a dispatcher and boards which are remote from that master.

The packages do not assume that your apache2.4 setup is identical to that used in other LAVA installations, so the LAVA apache config is installed to /etc/apache2/sites-available/ but is not enabled by default. If you choose to use the packaged apache config, you can simply run:

$ sudo a2ensite lava-server
$ sudo apache2ctl restart
(If this is a fresh apache install, use a2dissite to disable to default configuration before restarting.) Information on creating a superuser, adding devices and administering your LAVA install is provided in the README.Debian file in lava-server:

$ zless /usr/share/doc/lava-server/README.Debian.gz
Provisos and limitations Please be aware that packaged LAVA is still a work-in-progress but do let us know if there are problems. Now is the time to iron out install bugs and other issues as well as to prepare LAVA packages for other distributions. It will be a little while before the packages are ready for upload to Debian I ve got to arrange the download location and upload the dependencies first and some of that work will wait until more work has gone in upstream to consolidate some of the current dependencies.

Kerberos is a great protocol for single sign-on authentication. It's supported by many protocols, allowing you to not have to enter a password to each and every one of them; instead, the protocols behind the scenes (not "just" Kerberos, but also the things that embed tickets, such as GSSAPI, or the things that embed GSSAPI, such as SASL or SPNEGO) use your ticket-granting-ticket to ask for security credentials for the service you're trying to use, magic happens, and you're authenticated. I blogged about kerberos before (even if it was ages ago); since then, I've not only used it on my own systems, but also on the systems of various customers. One thing I've learned in that time, however, is that most web application developers have a bad case of NIHilism when it comes to authentication. Most webservers that I've seen have a wide range of methods to do authentication in the webserver through various means, including things like certificate-based authentication, one-time password modules, and, yes, kerberos. Yet almost no webapp out there will look at the magic variables that those webservers set to explain we're authenticated, instead reinventing the wheel through webforms and other various stupid means. Sigh. So, that means, no kerberos authentication for webapps. Worse, if the application has no way to pass on authentication to something external, that means users will now have to learn another password: one for Kerberos, one for the webapp. And, probably, one for this other webapp, too -- because once you add one webapp, people expect you to add more of them. Well, mostly. In some cases, webapps do have ways to externalize authentication. In most cases this means "store passwords in a database", or "try authenticating against this other service here". When "this other service here" is an IMAP server, then all you need to do is make sure cleartext authentication on the IMAP server eventually ends up trying to authenticate against the Kerberos server, and you're all set. When "this other service here" is an LDAP server, however, you're out of luck. Right? It turns out that no, you're not. I recently learned that OpenLDAP can, in fact, check "simple" bind requests by checking some other service, and that this other service can be a Kerberos realm. Doing so is called "Pass-through authentication" in the OpenLDAP documentation, and this is how you do it:

• Add a "userPassword" attribute to the user who will authenticate, with a value of the form " SASL principal@KERBEROS.REALM". That is, take the user's principal name, tack " SASL " in front of it, and put that in the userPassword attribute.
• Make sure you have saslauthd installed and running, with the kerberos5 mechanism active. In Debian, that means you have to install sasl2-bin, and edit /etc/default/saslauthd, so it has the variable START set to yes (yuck), and the variable MECHANISMS set to kerberos5.
• Create a file /etc/ldap/sasl/slapd.conf, and add the following contents:

mech_list: plain
pwcheck_method: saslauthd

This directs the SASL libraries, loaded by slapd, to talk to saslauthd when trying to authenticate some SASL things - Make sure slapd has the correct permissions to access the saslauthd unix domain socket. On Debian, that means you need to add the "openldap" user to the "sasl" group:

 adduser openldap sasl 

(obviously that won't be active until the next slapd restart) And that's it; if you now try a simple bind against the LDAP directory, and enter your Kerberos password, you should be in. If it doesn't work, try running "testsaslauthd"; if that works, it means the error is in your slapd configuration. If it doesn't, then the problem is in saslauthd. Some notes:

• this is not the same thing as using Kerberos authentication for LDAP. OpenLDAP has the ability to allow SASL binds for LDAP, which is way more interesting (since it allows authentication to actually be done by Kerberos rather than by "entering a password"); instead, with this method, it is possible to verify a password for a simple bind against a Kerberos password.
• Since this can't use hashed passwords, this method is inherently insecure. Only use it if all else fails, and for the love of $DEITY, at least make sure all the network connections which are going to contain such passwords are encrypted with SSL or TLS or similar. Otherwise, everyone who can sniff anything on your network will learn all the Kerberos passwords, which is a very very bad thing.

Oh, and if you're a webapp developer: please please please make it easy for me to use an external authentication mechanism. This isn't hard; all you need is a separate page that will read the magic variables (probably REMOTE_USER if you're using apache), set a session variable or whatever, and then redirect to your normal "we've just logged in" page. ikiwiki gets this right; you can too! (for added bonus points, have some way to declare a mapping from REMOTE_USER values to internal, readable, usernames, but it's not too crucial)

I used to host my internet infrastructure at Hurricane Electric. It all started in october 1998 with POP3/SMTP, HTTP and DNS. In the coming years, I began to host all services except DNS on my own. But I kept using he.net for its DNS management interface. It was dead simple, and therefore accessible. All they had was a basic textarea with BIND alike configuration in it. I could log in to their admin interface and change my DNS records as desired. A few years ago, they auto-upgraded my account to their new shiny DNS panel, which, surprise surprise, is no longer accessible with a simple text browser. After a bit of bitching with support, they ended up downgrading my account back to the old functionality, so I was happy again. However, as you might guess, last time I needed to change a DNS record, I found that the DNS panel has been ugpraded yet again and is again no longer accessible to me. So it was time to leave the sinking ship. But I needed to find an accessible DNS hosting service. Not an easy task, given that everyone seems to do more or less the same thing these days.

Further improvements to the shared infrastructure I use for my various packages. This release adds new Autoconf macros for detecting SQLite. These use the same strategy that I used for libevent, and which I'm slowly adopting for all libraries that support pkg-config. pkg-config is tried first if available, and unless the Autoconf flags to point to particular install paths for the library are given. Autoconf then falls back on manual probing. Also in this release are all the changes to the Perl support modules for test programs and the various generic Perl tests to implement the change that I started in the last Term::ANSIColor release: using the Lancaster Consensus environment variables to control whether tests run when they don't directly test package functionality, and skipping a lot more tests for the average end user who doesn't really care if, say, the POD syntax is correct or all the supporting Perl scripts past strictness checks. You can get the latest release from the rra-c-util distribution page.

And done! It took me just 8 months to do this entire book project around Python. From the first day I started writing to today, where I finally publish and sell almost entirely myself this book. I'm really proud of what I've achieved so far, as this was something totally new to me. Doing all of that has been a great adventure, and I'll promise I'll write something about that later on. A making of. For now, you can enjoy reading the book and learn a bit more about Python. I really hope it'll help you bring your Python-fu to a new level, and help you build great projects! Go check it out, and since this is first day of sale, enjoy 20% off by using the offer code THGTP20.