Just a few more recently-released books that I had to pick up. Sheila Bair Bull by the Horns (non-fiction)
Elizabeth Bear Book of Iron (sff)
Steven Brust & Skyler White The Incrementalists (sff)
J.M. Coetzee The Childhood of Jesus (mainstream)
Elizabeth Wein Rose Under Fire (mainstream)
Walter Jon Williams Knight Moves (sff) Time to get back into the reading habit. That's the plan for the next couple of weeks.

Almost every time he got off the bus for the past month and a half, Jacob started his afternoon in the same way. Before toys, before his trains and his toy bus, before anything indoors, he went for our cats. Here he is, cradling his favorite, Tigger: Laura and I both grew up around cats. We had been talking about kittens, and shortly after we got engaged, one of my relatives offered us some free kittens. We went to his place one evening and selected two of them one calico and one tiger-colored. Since what is now my place will soon be our place, they came to live with me. Our cats were one of the first things we did to prepare for our lives together. Oliver wanted to name them some rather impractical sentence-long names ( The Cat Who Always Likes To Run ), so Laura and I suggested some names from one of their favorite books: Tigger and Roo. They both liked the names, but Oliver thought they should be called Tigger the Digger and Roo the Runner . Never mind that they were just 6 weeks old at the time, and not really old enough to either dig or run. Here s Oliver with Roo, the day after the kittens arrived here. I have always had outside cats, both because I m allergic to cats so I need them to be outside, and because they sometimes literally quiver with joy of being outdoors. Tigger and Roo often chased insects, wrestled with each other, ran up (and slowly came back down) trees, and just loved the outside. Sometimes, I have taken my laptop and wireless headset and work from the back porch. The kittens climb up my jeans, inspect the laptop, and once Roo even fell asleep on my lap at one of those times. Jacob has been particularly attached to Tigger, calling him my very best friend. When Jacob picks him up after school, Tigger often purrs while cradled in Jacob s arms, and Jacob comments that Tigger loves me. Oh dad, he knows I am his friend! The kittens have been growing, and becoming more and more comfortable with their home in the country. Whenever I go outside, it isn t long before there are two energetic kittens near my feet, running back and forth, sometimes being very difficult to avoid stepping on. I call and I see little heads looking at me, from up in a tree, or peeking out from the grain elevator door, or from under the grill. They stare for just a second, and then start running, sometimes comically crashing into something in their haste. Yesterday when I went to give them food, I called and no cats came. I was concerned, and walked around the yard, but at some point either they come or they don t. Yesterday afternoon, just after the bus dropped off Jacob, I discovered Tigger on the ground, motionless. Once Jacob was in the house, I went to investigate, and found Tigger was dead. As I was moving his body, I saw Roo was dead, too. Both apparently from some sort of sudden physical injury a bit mysterious, because neither of them were at a place where they had ever gone before. While all this was happening, I had to also think about how I was going to tell the boys about this. I tried to minimize what he could see, Jacob had caught an unavoidable glimpse of Tigger as we were walking back from the bus, but didn t know exactly what had happened. He waited in the house, and when I came back, asked me if Tigger was dead. I said he was. Jacob started crying, saying, Oh Dad, I am so sad , and reached up for a hug. I picked him up and held him, then sat down on the couch and let him curl up on my lap. I could quite honestly let him know he wasn t alone, telling him I am sad, too. Oliver arrived not long after, and he too was sad, though not as much as Jacob. Both boys pretty soon wanted to see them. I decided this was important for them for closure, and to understand, so while they waited in the house, I went back out to arrange the kittens to hide their faces, the part that looks most unnatural after they die. The boys and I walked out to where I put them, then I carried both of them the last few feet. We stood a little ways back close enough to see who was there, far enough to not get too much detail and they were both sniffling. I tried to put voice to the occasion, saying, Goodbye, Tigger and Roo. We love you. Oliver asked if they could hear us. I said No, but I told them what I felt like anyway. Jacob, through tears, said, Dad, maybe they are in heaven now. We went back inside. Jacob said, Oh dad, I am so sad. This is the saddest day of my life. My heart is breaking. Hearing a 7-year-old say that isn t exactly easy for a dad. Pretty soon he was thinking of sort of comfort activities to do, saying I think I would feel better if we did So they decided to watch a favorite TV program. Jacob asked if Laura knew yet, and when I said no, he got his take-charge voice and said, Dad, you will start the TV show for us. While we are watching, you will send Laura an email to tell her about Tigger and Roo. OK? What could I say, it wasn t a bad idea. Pretty soon both boys were talking and laughing. It was Big Truck Night last night, at a town about half an hour away. It s an annual event we were already planning to attend, where all sorts of Big Trucks firetrucks, school bus, combine, bucket truck, cement truck, etc show up and are open for kids to climb in and explore. It s always a highlight for them. They played and sang happily as we drove, excitedly opened and closed the big door on the school bus and yelled All Aboard! from the top of the combine. We ate dinner, and drove back home. When we got home, Jacob mentioned the cats again, in a sort of matter-of-fact way, and also wanted to make sure he knew Laura had got the message. A person never wakes up expecting to have to dump a bowl of un-eaten cat food, or to give an impromptu cat funeral for little boys. As it was happening, I wished they hadn t been around right then. But in retrospect, I am glad they were. They had been part of life for those kittens, and it is only right that they could be included in being part of death. They got visual closure this way, and will never wonder if the cats are coming back someday. They had a chance to say goodbye. Here is how I remember the kittens.

Announcement After a very long work, over the course of 4 months, I have finished packaging the first RC1 of OpenStack. This comes on time, just 9 days before the official Havana release. Please do try this RC1 before the official 2013.2, code name Havana, is released, and hopefully uploaded to Debian. All of the packages are available from Debian Experimental, keeping Grizzly in Sid. However, there is also some private repositories that I maintain, holding Wheezy backports: deb http://havana.pkgs.enovance.com/debian havana main deb http://archive.gplhost.com/debian havana-backports main The first repository holds the packages maintained within the Alioth group. These are built directly from my Jenkins machine, on each git push. The 2nd repository is holding backports from Sid to Wheezy for the packages that I don t actively maintain (though a lot of them are in the Python module team, in which I do a lot of packaging and updates as well). A few numbers A few numbers about this now. I had to work on 145 source packages: at least backport them to Wheezy, and push them in the GPLHost archive repository above. This generates 360 binary packages. Out of these, I maintain 77 source packages within the Alioth OpenStack group, generating 209 .deb files. That s a lot of stuff to deal with (and I feel sometimes a bit dizzy about it). While OpenStack is a big jigsaw puzzle to solve for the users, it is even more for someone who has to deal with all the (sometimes buried in the the code) Python dependencies. I hope others will come and join me in this packaging effort, since over the time, there s more and more work to be done, as the project grows. Note that most of the work is unfortunately done on packaging (and updating) the Python dependencies, working on the packages themselves is done last, at the end of the cycle. Other things not packaged (yet) Before the release (and the forthcoming Hongkong summit on the 5th of November), I hope to be able to finish packaging TripleO. TripleO is in fact OpenStack on OpenStack, which works with nova-baremetal. I have no idea how to test or install this, though it sounds like a lot of fun. There are 6 source packages that need to be done. Also, pending on the FTP masters NEW queue, is Trove: Database as a Service. I hope this one can get through soon. There is, also, Marconi, which is an incubated project for a new message queuing service, which probably will replace RabbitMQ (I m not sure yet what it does, and I will be happy to hear about it at the summit). Lastly, there s Ironic, which will at some point, replace nova-baremetal. That is, it does cloud computing over bare metal, without virtualization. All of these new projects are still in an incubation stage, and are not part of the official release yet. Though, I have learned over the course of this past year, that with OpenStack, it s never early enough to start the packaging work. Thanks to my sponsor! Please note that all of this wouldn t be possible without eNovance sponsoring my packaging work. A big up to all of them for supporting and loving Debian! You guys rox. Also a special thanks to Mehdi / Sileth, for his work testing everything with the Tempest functional tests and the CI platform.

Just as last year, BalaBit applied to become a mentoring organisation for this year's Google Summer of Code, but like the year before, were not accepted. Instead, the openSUSE project was kind enough to give us two slots of their own, similarly to the year before - we are very thankful for this, and this year, both of the projects we took were closed successfully! So much so, that one of them was already merged into syslog-ng 3.5.0beta2, and the other one is being prepared for getting merged into the Incubator. I also helped out a little with Clojure & Leiningen packaging, although my contributions there were minimal at best.On the whole, I really liked this year's programme, our students accomplished a lot, and the whole summer was a great experience in itself, I learned a lot about mentoring, and about working with other people, people who are very new to the codebase they're working on. I would like to summarise what I learned and observed this year, in the hopes that others may find them useful too.This year, we set fairly ambitious goals for our students: they had to write a Redis and a MySQL destination, both of which presented interesting challenges to the students. None of them had prior experience with the syslog-ng source code, and their programming knowledge was mostly in C#, not plain old C which syslog-ng is written in. They also had to dabble a bit in the bowels of our overly complex configure.ac and a few Makefiles. Wasn't an easy task.In the beginning, we tasked the students to write proof of concept code, to get familiar with the libraries they will need to use - no syslog-ng involved at this point. This sounded like a good idea on paper, but without clear goals and milestones, a lot of time was spent on this task, and the students ran into a few dead-ends which could have been avoided, if we, the mentors, were more careful. This resulted in a reasonably poor first term, frustration and caused many a sleepless nights. We had to change our approach if we wanted to see the projects succeed.So we sat down with the students, and took one big leap: in person, we explained some of the internals of syslog-ng, did code reviews with them, and so on. But the best thing we did was what my colleague (and the main mentor), Viktor Tusa, came up with: we wrote a test script, that started syslog-ng, configured it, and ran tests against it. Students had to make their code pass the test by the next in-person meeting. This helped tremendously, and increased the speed they worked at by an order of magnitude at least. We kept developing the test script further, and so did the projects improve.ConclusionsThere are a couple of conclusions I arrived at as the programme concluded, things we (or other mentors, as I plan to participate as a student next year) will need to improve upon in the coming years.

• We need milestones at the time of announcing the project, not later, but by the time we put a project online, we need clear milestones.
• We need a way to help students track their own progress. We can't always be there for them, and that's OK. They need to be able to see how they're doing, though. Automated tests, whenever possible, are a great aid.
• In person meetings, with code reviews and explaining idiosyncrasies of the existing code-base are a great help to students, and also help us better understand how others would like to use our APIs, which in turn makes it easier to write APIs that are actually good.
• Lack of experience in the programming language is no big deal, experience can be gained during the programme, if the student is dedicated. We should not be afraid of involving smart, but less experienced students. As a consequence, requiring code samples may not be the best idea. That's a very high barrier to jump over. I would rather have a talk - in person, preferably - with the student, and see if they have the potential to bring the project to the finish line.
• We need to start preparing for next year soon, if we want to participate on our own. Can't wait for the last minute, starting just a month before the application period for organisations open is already too late.
• Involving the students in the project, letting them do useful work that gets merged during the programme is a huge accomplishment. Both our students expressed interest in not only participating next year too, but also continuing their work after GSoC. We need to keep this up in the coming years too!

Review: Grimspace, by Ann Aguirre

Series:	Sirantha Jax #1
Publisher:	Ace
Copyright:	March 2008
ISBN:	0-441-01599-9
Format:	Mass market
Pages:	312

Sirantha Jax is a jumper: a person with the rare genetic ability to jump spaceships through the shortcut dimension of grimspace. It's a science fiction idea with a long pedigree. It creates a separate in-group for the characters to belong to, a society with its own rules, and sets up tension with the rest of the institutions of the world. In Aguirre's version, jumpers can provide the transition but direction in grimspace has to be done by a pilot, and the jumper and the pilot develop a deep psychic bond. Jax had been jumping with her husband piloting, but on their last trip their ship crashed, killing everyone on board except her. As Grimspace opens, Jax is in a treatment facility that's much more like a prison. In theory, they're trying to figure out whether she's still able to (and safe to allow to) jump. In practice, something quite a bit more sinister is going on, a fact that the reader senses early but only learns more about after Jax is helped to escape. Scarred, deeply depressed, and nearly suicidal, she's pulled into the subversive plans of a small ship of renegades who are trying to break open the Corp monopoly on grimspace travel and their tight hold over every jumper. But she's not sure whether she trusts them, or whether she cares enough about their crusade to truly join in. Grimspace follows well-trod SF paths of special cadres of pilots and navigators, lawless corners of space with local warlords, and rebellion against smothering centralization, but its first-person protagonist and point of view have more in common with urban fantasy. It's written in first-person and, at times, nearly stream of consciousness from Jax's perspective, and Jax displays plenty of profanity, acidic commentary, and emotional angst. If her special ability were shapeshifting or magic instead of jumping spaceships, one could easily see her as the typical burned-out urban fantasy detective. I liked that. It's a fun point of view when it's written well, and it felt fresh when applied to a science fiction background instead of the more typical fantasy. That said, Grimspace has a rather rough start. Jax isn't sure what's going on at first and also isn't sure she cares, and I thought that carried over to the reader's experience. The first section of the book is rough and jagged, with staccato bursts of character introduction, world-building that doesn't quite cohere, and an extended stop on a very odd outback planet that felt to me like a repurposed stage from a western. Part of the early problem is that Jax and the reader are being intentionally kept in the dark about the real goal of this group, but part of the problem is also that none of the characters start off as very likable. That includes Jax, who is a complete mess and who is both scared and despairing to the point of being almost nihilistic. The world-building unfortunately does not carry the reader through that part of the story, and at about eighty pages in I wasn't sure I was going to like this book. It does, however, get much better. For one, Jax calms down and starts making emotional connections with the rest of the crew, and that lets her demonstrate skills as a fearless problem solver. For another, while the goal of the group of people she's fallen in with isn't exactly deep, it does make sense and it does slowly become a cause the reader (and Jax) can believe in. The frenetic pace of introduction and discovery also slows down, the cast stabilizes, and the surroundings get a bit less weird (and a bit more conventional for a science fiction novel). I didn't care for the alien baby subplot I rarely do but the rest of the story slowly pulled me in. One thing Aguirre did extremely well was surprise me. There are several points later in the book where Jax gets put in a fairly typical high-stress position and does something very atypical in reaction to it, twisting the story into a shape quite a bit unlike what I had been expecting. That made Jax feel like a true free agent, establishing her independence and her desire to control her own life, and that appealed to me. Aguirre also palms one card exceptionally well, setting up an ending that I thought was the best set of scenes in the whole book, and that had me thoroughly engrossed. One can see the bones of the urban fantasy heroine inside Jax's character, but they're fresh and interesting in an SF world, and they work better than I would have expected. There is a romance, in fitting with the urban fantasy inspiration, and it didn't quite work for me, but Aguirre also builds in a reason why it might not make sense and makes it spiky and fragile without being too cliched. By the end of the book, I was, if not entirely persuaded, at least willing to go along for the ride. And that's the best summary of Grimspace, I think. Parts of it don't make a great deal of sense, and parts of it are quite choppy. But I liked Jax once she starts getting a handle on her trauma, the other characters grew on me, and the plot surprised me in some interesting ways. It's not the smoothest or most polished SF novel I've read, but it has a lot of energy and an unusual genre mix. I think I'll stick along for the ride. Followed by Wanderlust. Rating: 7 out of 10

This is a rather huge release of my password strength checking package for Heimdal and MIT Kerberos KDCs, incorporating quite a bit of new work as well as some substantial restructuring. The largest change is that MIT Kerberos is now fully supported, not just with provided patches, thanks to work by Greg Hudson and MIT. The package can now build plugins for either MIT or Heimdal, as well as an external password quality program for Heimdal (the preferred method for that implementation). Alongside that change, the plugin installation path has changed to fit the layout of MIT plugins (as well as I understand it). This version also now supports password dictionaries other than CrackLib. You can generate a CDB dictionary from a wordlist using a utility included in the package and use it instead of or as a supplement to CrackLib. This dictionary lookup uses a much simpler set of permutations (the password as given plus removing some leading and trailing characters), providing a simpler approach suitable for much larger dictionaries. (CrackLib does a lot of transformations before dictionary lookup that are dubious, such as ignoring case and punctuation.) Also in this release are new configuration options to control additional checks: minimum password length (independent of whatever length CrackLib requires), requiring at least one non-alphabetic character, and rejecting non-ASCII or non-printable characters. The latter isn't to make the password stronger, but to prevent user frustration since those characters often can't be reliably entered in different situations and can result in an unreproducible password, particularly since Kerberos doesn't define a password normalization. In support of these changes, and to make testing easier, the plugin can be configured without a dictionary of any kind, or with any combination of CDB and CrackLib dictionaries. The checks for passwords based on principals are now more comprehensive, checking not only the local part but also each component of the principal with leading or trailing digits. Since many sites put their institution name in the Kerberos realm, this will also check for passwords based on the institution name. There are also some fixes to the internal CrackLib implementation, in case it is used instead of the system CrackLib, to better handle long passwords by scaling the test for simplistic passwords. You can get the latest release from the krb5-strength distribution page.

First day of hackweek did not really go as planned. I had to spend too much time on tasks which I did not now I will have to do in advance. I've started with releasing Weblate 1.7. As a part of that I update SUSE Studio images with Weblate. Unfortunately this turned out to be more challenging than usual as with new version the build script always failed but without any obvious error. After some time, I've realized that it just does not show whole output, so the last (and most important) lines are missing. Then it was easy to spot that the problem is in Whoosh version and it's just matter of providing newer version. After fixing the image, I could finally focus on Weblate's issue tracker and resolved few issues and questions. I've also improved some of the in application documentation and links to documentation or other resources. Meanwhile I could also setup translation hosting for monkeysign, happy translating!

Filed under: English SUSE Weblate 0 comments Flattr this!

Weblate 1.7 has been released today. It comes with lot of improvements, especially in translation speed and many new features. Full list of changes for 1.7:

• Please check manual for upgrade instructions.
• Support for checking Python brace format string.
• Per subproject customization of quality checks.
• Detailed per translation stats.
• Changed way of linking suggestions, checks and comments to units.
• Users can now add text to commit message.
• Support for subscribing on new language requests.
• Support for adding new translations.
• Widgets and charts are now rendered using Pillow instead of Pango + Cairo.
• Add status badge widget.
• Dropped invalid text direction check.
• Changes in dictionary are now logged in history.
• Performance improvements for translating view.

You can find more information about Weblate on it's website, the code is hosted on Github. If you are curious how it looks, you can try it out on demo server. You can login there with demo account using demo password or register your own user. Ready to run appliances will be soon available in SUSE Studio Gallery. Weblate is also being used https://l10n.cihar.com/ as official translating service for phpMyAdmin, Gammu, Weblate itself and others. If you are free software project which would like to use Weblate, I'm happy to help you with set up or even host Weblate for you. Further development of Weblate would not be possible without people providing donations, thanks to everybody who have helped so far!

Filed under: English SUSE Weblate 1 comments Flattr this!

Review: Captain Vorpatril's Alliance, by Lois McMaster Bujold

Series:	Vorkosigan #14
Publisher:	Baen
Copyright:	November 2012
ISBN:	1-4516-3845-0
Format:	Kindle
Pages:	432

This is the fourteenth book in the long-running Vorkosigan series (not counting a few side works). It shifts viewpoint characters, following Ivan Vorpatril instead of either Miles or Cordelia, and could be read on its own since the necessary background is at least briefly explained. But it's probably best read in its proper context in the larger series, since otherwise many of the prior events mentioned here won't have much resonance. Ivan Vorpatril, Miles's cousin, has appeared in multiple previous books along with the rest of Miles's extended family, but he's stayed out of the center of the plot. And he clearly likes it that way. Ivan is not at all ambitious, tries to avoid politics, and just wants to live a quiet life (insofar as that's possible in the Barrayan military), sleep with a few women, and stay out of trouble. But given his relations and his job as aide-de-camp to an admiral this doesn't always work. In this book, the not working comes in the form of Byerly, ImpSec (Imperial Security, the Barrayan equivalent of the CIA), and a request to find out more about a woman who seems to be the target of a bounty. Fairly quickly, Ivan finds himself hopelessly entangled in both politics and in someone else's complex life, and is not entirely sure what to do about either. It's been months since I read this book and I'm only now writing a review, in part because I find it hard to know what to say about it. While Ivan doesn't have Miles's manic energy, the tone of this book is very similar to the rest of the Vorkosigan series, as is the plot and most of the characters. Ivan tries a more laid-back approach and doesn't actively seek danger the way that Miles does, but his persistent efforts to do the right thing in the face of unexpected events lead mostly to the same places. There's a bit of humor, a bit of danger, some galactic politics, some scheming, and a slow process of understanding other people better in short, Captain Vorpatril's Alliance is very similar to the thirteen books that proceeded it. This is obviously not a bad thing. If you've read this far in the series, more of the same is probably just fine. I enjoyed the book. Bujold is great at telling stories, the plot mostly moved right along, and I quite liked the two women Ivan meets over the course of the story. But there wasn't much about the story that grabbed me or, I suspect, that I will find particularly memorable. One reason for my somewhat "meh" reaction is that the core of this story is a romance, and while much of that romance is well-done, there is a large segment in the middle of the book where the suspense of the plot derives mostly from one of the two characters refusing to confide in the other. This is Bujold, so this isn't as much of a train wreck as it might be in the hands of another author, and it is for valid plot reasons. But even with those justifications, I never like that plot element. There were about a hundred pages where I wanted to grab Tej and shake some sense into her, which doesn't endear a character to me. And the leads in a romance, at least this sort of romance, should be endearing. I think one reason why Bujold went for that approach to building tension is that there weren't a lot of options available. The basic outlines of what's going to happen are obvious from early in the book and essentially forced by the structure of the series. We know from past books that Ivan is both trustworthy and related to a staggering variety of powerful people, almost all of whom are highly competent and honorable. It's fairly obvious that, as soon as the necessary people trust Ivan and let him and his family solve their problems, all the problems will be solved. It's also fairly obvious how the romances will play out, and that all the new characters will end up a little in awe of how competent and trustworthy all the Barrayans are (a few misdirections aside). Therefore, much of the book, for a long-time reader of the series, involves waiting until those things happen, and meanwhile getting increasingly annoyed at characters who refuse to trust obviously trustworthy people. All that said, I still quite liked the beginning of the book, because Tej and Rish are a wonderful pair and have a great interpersonal dynamic, and the very end of the book once everyone gets past the communication problems and the plot can deliver on its promises. Both together make up for some noticeable sagging in the middle section of the book. Captain Vorpatril's Alliance is not up to the standards of the most memorable books of the series, but it's a solid dose of "more of the same" and provides its money's worth of entertainment. I'm still hoping for more Ekaterin and more fireworks in the next book, though. Rating: 7 out of 10

This is a reply to Roman Cheplyaka s post Why PVP doesn't work , where he argues that Haskell packages should not per default put upper bounds on their build dependencies (as mandated by the Package Versioning Policy), at least not without good reason. I disagree, and I d like to explain why. I assume that you are packaging your libraries and programs not only for your fellow developers, but also for users. Hackage has turned not only into a hub for developers sharing their libraries, but also for users to conveniently download stuff from. And when I say users, I include xmonad users (although they write a bit of Haskell for their configuration) and beginners (who we certainly don t expect to understand and make sense of error messages that occur if some obscure crypto-related dependency of their favourite web framework fails to build). And for their benefit we should try hard to make sure cabal install either succeeds (great) or fails early with an error message that the user can understand as I could not find a package configuration of which the maintainers believe with good confidence that it works. Please talk to them. I speak with some experience, because as a maintainer of the >666 Haskell packages in Debian, I am, in a sense, a very heavy user. In the years after the PVP got commonly accepted, we could noticeably reduce the number of build failures that we encounter on our machines and the Debian build farms, simply because the meta data (which we transfer to the Debian package level) prevented such builds from being attempted. We now even have a build compatibility prediction system: We maintain a text file with all Haskell packages in Debian, together with a directory of patches (where we sometimes indeed override the packages Cabal file), and a script that runs cabal-install s dependency checker against this day. This way, when I want to upgrade a package, I can simply change the version in the file and know what packages will be broken. So I change their version until I either find a fixed-point (and only then actually upload packages to the user) or find a problem, which I then report to the maintainers or start cooking up my own patches. This works really well, but it only does because most maintainers are following the PVP. That s why I argue: Please continue to do so. (What we would probably need instead of less using the PVP is more tools in helping us with it. I could imagine a build bot that finds packages on Hackage with an upper bound on a package where a newer version exists, fetches those and automatically tries to build against the new version, and if it succeeds, sends a message to the maintainer: Your dependency on bar in foo also builds against version 0.42 of bar; please check for incompatibilities that are not expressed in the type system and upload a new version of foo allowing bar-0.42. Isn t that something the Stackage infrastructure can be used for?) (What we could probably use as well (and is probably a stepping stone towards what I just said) is a way to tell cabal-install to ignore a certain build dependency version bound. This way we still prevent normal users from trying a dependency version that the maintainer did not test, but nevertheless make it as easy as possible for the advanced user to try nevertheless, and then hopefully report about it to the maintainer. Of course, other had that idea before, someone just has to make it happen.)

Until now qcontrol has mostly only supported only ARM (kirkwood) based devices (upstream has a configuration example for the HP Media Vault too, but I don't know if it is used). Debian bug #712191 asked for at least some basic support for x86 based devices. The mostly don't use the QNAP PIC used on the ARM devices so much of the qcontrol functionality is irrelevant but at least some of them do have a compatible A125 LCD. Unfortunately I don't have any x86 QNAP devices and I've been unable to figure out a way to detect that we are running on an QNAP box as opposed to any random x86 box so I've not been able to implement the hardware auto-detection used on ARM to configure qcontrol for the appropriate device at installation time. I don't want to include a default configuration which tries to drive an LCD on some random serial port since I have no way of knowing what will be on the other end or what the device might do if sent random bytes of the LCD control protocol. So I've implemented debconf prompting for the device type which is used only if auto-detection fails, so it shouldn't change anything for existing users on ARM. You can find this in version 0.5.2-3~exp1 in experimental (see DebianExperimental on the Debian wiki for how to use experimental). Currently the package only knows about the existing set of ARM platforms and a default "unknown" platform, which has an empty configuration. If you have a QNAP device (ARM or x86) which is not currently supported then please install the package from experimental and tailor /etc/qcontrol.conf for you platform (e.g. by uncommenting the a125 support and giving it the correct serial port). Then send me the result along with the device's name. If the device is an ARM one please also send me the contents of /proc/cpuinfo too so I can implement auto-detection. If you know how to detect a particular x86 QNAP device programmatically (via DMI decoding, PCI probing, sysfs etc, but make sure it is 100% safe on non-QNAP platforms) then please do let me know.

I wish I had known about that quote from Michael Graves before now. I would have perhaps had an answer to some recent visitors to makespace.

There are regular scheduled visits to makespace where people can come and view our facilities, and perhaps start the process of becoming a member if they decide they like what they see.

However, we sometimes get people who just turn up at the door. If a member feels charitable they may choose to give a short tour rather than just turn the person away. I happened to be in one Friday afternoon recently varnishing a folding chair when two such people rang the doorbell. There were few other members about and because watching varnish dry was dull I decided to be helpful and do a quick tour.

I explained that they really ought to return for a scheduled event for a proper tour, gave the obligatory minimal safety briefing, and showed them the workshops and tools. During the tour it was mentioned they were attending a certain local higher education establishment and were interested in makespace as an inexpensive studio.

Before they left I was asked what I was working on. I explained that I had been creating stools and chairs from plywood. At this point the conversation took a somewhat surreal turn, one of them asked, well more demanded, who my principle influence had been in designing with plywood.

When I said that I had mainly worked from a couple of Google image searches they were aghast and became quite belligerent. They both insisted I must have done proper research and my work was obviously influenced by Charles and Ray Eames and Arne Jacobsen and surely I intended to cite my influences in my design documents.

My admission that I had never even heard the names before and had no design documents seemed to lead to a distinctly condescending tone as they explained that all modern plywood design stemmed from a small number of early 20th century designers and any competent designers research would have revealed that.

At this point in proceedings I was becoming a bit put out that my good deed of showing off the workshop had not gone unpunished. I politely explained that I designed simply by generating a requirement in my head, maybe an internet search to see what others had done, measuring real things to get dimensions and then a great deal of trial and error.

I was then abruptly informed that my "design process was completely invalid and there were well established ways to design furniture correctly and therefore my entire design was invalid" and that I was wasting time and material. I thanked them for their opinion and showed them out, safe and well before anyone gets any ideas.

I put the whole incident out of my mind until I finished writing up the final folding chair post the other day. It struck me that perhaps I had been unknowingly influenced by these designers. It was certainly true I had generated ideas from the hundreds of images my searches had revealed.

I did some research and it turns out that from the 1930s to the 1950s there were a string of designers using plywood in novel ways from the butterfly stool by Sori Yanagi through formed curvy chairs by Alvar Aalto and eero saarinen.

While these designers produced some wonderfully iconic and contemporary furniture I think that after reviewing my initial notes that two more modern designers Christian Desile and Leo Salom probably influenced me more directly. Though I did not reference their designs beyond seeing the images along with hundreds of others, certainly nothing was directly copied.

And there in lies an often repeated observation: no one creates anything without being influenced by their environment. The entire creative process of several billion ape descendants (or Golgafrincham telephone sanitisers if you prefer) is based on the simple process of copying, combining and transforming what is around us.

I must accept that certain individuals at points in history have introduced radical improvements in their field, people like Socrates Galileo Leonardo Newton Einstein. However, even these outstanding examples were enlightened enough to acknowledge those that came before. Newtons quotation "If I have seen further it is by standing on the shoulders of giants" pretty much sums it up.

In my case I am privileged enough to live in a time where my environment has grown to the size of the world thanks to the internet. My influences, and therefore what I create, is that much richer but at the same time it means that my influence on others is similarly diminished.

I have joined the maker community because I want to create. The act of creation teaches me new skills in a physical, practical way and additionally I get to exercise my mind using new techniques or sometimes things I had forgotten I already knew. I view this as an extension of my previous Open Source software work, adding a physical component to a previously purely mental pursuit.

But importantly I like that my creations might provide inspiration for someone else. To improve those chances in the wider world I force myself to follow a few basic rules:

Release

Possibly one of the hardest things for any project. I carefully avoided the word finish here because my experience leads me to the conclusion that I always want to improve my designs.

But it is important to get to a point in a project where you can say "that is good enough to share", this is more common in software but it really applies to any project.

Share

If your aim here is to improve your society with your contribution sharing your designs and information is important. I think there is nothing better than someone else taking one of your designs and using it and perhaps improving on it, remember that is what you probably did in one way or another better to make it less hard for that to happen.

Ensure your design files are appropriately licensed and they are readily accessible. I personally lean towards the more generally accessible open source licences like MIT but the decision is ultimately yours.

Licencing is important, especially in the current copyright happy society. I know it sounds dull and no one takes that seriously, right? Sorry, but yes they do and it is better for you to be clear from the start, especially if there is a software component to your project. Oh one personal plea, use an existing well known licence, the world simply does not need another one!

Write about it

The blog posts about the things I have made sometimes take almost as much time as the creation. The clear recording on my thoughts in written and photographic form often gives me more inspiration for improvements or other projects.

If someone else gets pleasure from the telling then that can only be good. If you do not do this then your voice cannot be heard and you wasted an opportunity to motivate others.

Feedback

If you do manage to get feedback on your creation, read it. You may disagree or not be interested for the current project but the feedback process is important. In software this often manifests as bug reports, in more physical projects this often becomes forum or blog comments.

Just remember that you need a thick skin for this, the most vocal members of any society are the minority with inflammatory opinion, the silent majority are by definition absent but there is still useful feedback out there.

Create again

By this I simply mean that once you are satisfied yourself on a project move on to the next. This may sound a little obvious but once you have some creative momentum it is much easier to keep going project to project than in you leave time between.

Also do not have too many projects ongoing, by all means have a couple so you do not get stuck waiting for materials or workshop time but more than three and four and you will never be able to release any of them.

Those students were perhaps somewhat misguided in how they stated their opinions, but they are correct that in the world in which we find ourselves we are all influenced. Though contrary to received wisdom those influences are more likely to be from the internet and our peers in the global maker society than historical artists.

We learn to code by actually writing code and we did it because we enjoyed it. Now it is my day job and I get to do it a lot more. The only difference being its a lot more Java now. Jaseem and I have decided to take up a pet project of ours and finish it in a week. Jaseem is writing Conway s Game of Life in Elisp and I will be implementing a single player AI powered Reversi game in Erlang. I have been learning and writing Erlang for some time now it is something I enjoy. I believe actor model is one of the best ways to express concurrency primitives and the functional way of things is beautiful in itself, but I digress. Back in college we used to write code because it was something we enjoyed. Now there is not much that I write, apart from what I do at my day job, and this is an exercise in bringing those glory days back. Now read about this in his words.

A recent discussion on debian-project remind me I have to do this:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1,SHA256
Hello,
I am transitioning GPG keys from an old 1024-bit DSA key to a new
4096-bit RSA key.  The old key will continue to be valid for some
time, but I prefer all new correspondance to be encrypted in the new
key, and will be making all signatures going forward with the new key.
This transition document is signed with both keys to validate the
transition.
If you have signed my old key, I would appreciate signatures on my new
key as well, provided that your signing policy permits that without
reauthenticating me.
The old key, which I am transitional away from, is:
   pub   1024D/9057B5D3 2002-02-07
         Key fingerprint = 7AA1 9755 336C 6D0B 8757  E393 B0E1 98D7 9057 B5D3
The new key, to which I am transitioning, is:
   pub   4096R/31ED8AEF 2009-05-08
         Key fingerprint = DE8F 92CD 16FA 1E5B A16E  E95E D265 C085 31ED 8AEF
To fetch the full new key from a public key server using GnuPG, run:
  gpg --keyserver keys.gnupg.net --recv-key D265C08531ED8AEF
If you have already validated my old key, you can then validate that
the new key is signed by my old key:
  gpg --check-sigs D265C08531ED8AEF
If you then want to sign my new key, a simple and safe way to do that
is by using caff (shipped in Debian as part of the "signing-party"
package) as follows:
  caff D265C08531ED8AEF
Please contact me via e-mail at <vanicat@debian.org> if you have any
questions about this document or this transition.
  Remi vanicat
  vanicat@debian.org
  remi.vanicat@gmail.com
  remi.vanicat@ens-lyon.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
iD8DBQFST8iPsOGY15BXtdMRAggfAJ4z5wEpUy8Bcicv9KTGOjsUAZF2xACfYKv9
GWXh8iT1N2Qqjhwtpvx9B3aJAhUDBQFST8iP0mXAhTHtiu8BCPldEADYM9e/22yu
En8lcZ5UUI/eQ5jFgZaxTZ90ShS0vPD/Mgn6xyKoeigA0Bk4ltTjDXA7vEWXLjOK
gbGv3SvffPJIsR1WJmhYtVyNquJXXjyElEBsbxvCJ/awYdU9BFXPqtLlLVCObvSc
bE9xlJhoLdk3bDqSSTO3nqoDa0qgPnJvwKNYIMBrNavGyIW3QT0BRUCKyBssqh+u
P4x8VhpHiR2Ee4LHfRVeJk+5ncvSXYluAohOXka5AnV2GgFQoVYfFqxn2Gh3BMWC
sqf/NUPnFOCSRw++oNP3mBv3jn/jZuo8BcVOECKL+/dO6/3otgO6a/5tUspfnAJA
m/UxBdc2vs7LkZ0wUipIHg10x4154f+hZfx4WuCJ05X0dqcKeh4eJ0zFBvxMyh+A
o2TfifT9WJlyb+Hah/w1MFAXI8cAj5RvwdVgTzcodXpggtpBpdLDvv3G1KYFm/TG
Zev480N6bGrBb3JKgUtAMuTls8+FngYtYg9YKBiajEDM3MVC+H4MiOzVNKV++y/n
YW3z59Oc04ZMi9hV+uR3kwq8D7aUJmc0QFeOGmq7W9LOjvVO+lTf87l3jh2ahxx/
FgiinSZr1YzE+9OtNj8CTsmAmApIxsTJUCR6h554z+lyrTwc0pdeUwzSWqV84k7G
V6HBmTiw9IGs22+W15pRzq/mCVYdrYT7zQ==
=c5fJ
-----END PGP SIGNATURE-----

Here is the link to the .txt version for easier checking of signature.

This is my monthly summary of my free software related activities. If you re among the people who made a donation to support my work (86.18 , thanks everybody!), then you can learn how I spent your money. Otherwise it s just an interesting status update on my various projects. Package Tracking System^U Distro Tracker Marko Lalic implemented quite a few interesting features in the last weeks of the Google Summer of Code (support of teams most notably). Unfortunately he didn t deploy (yet) the latest changes on pts.debian.net. Given the good work he made over the summer, I marked him as successful in his GSOC. Hopefully he will stick around and continue to contribute, he promised to try to handle some mass renaming that we agreed upon. Effectively, after much bike-shedding, I decided that the software would be called Distro Tracker . Once those last-minute cleanups are done, I plan to request tracker.debian.org to Debian System Administrators. This means that it will be deployed in parallel to the current PTS at least until we re at feature parity in the new codebase. The new codebase should be much more easy to get started with, so I should do some promotion and invite people to contribute to it possibly by writing some short how to get started documentation. I started by creating a dedicated wiki page: http://wiki.debian.org/qa.debian.org/distro-tracker
Misc packaging I got two REJECTs from ftpmasters this month (one for galette, one for dolibarr). I took care of fixing the various issues in galette and the package has been promptly accepted afterwards. For dolibarr, I mentored the upstream maintainer about the various problems and got him to fix it. It took a bit more time and the package is thus still in NEW. I packaged wordpress 3.6, and then wordpress 3.6.1 (security update). python-django also had multiple security updates this month, I took care of one or two uploads but Luke Faraone dealt with most of them (including backports to Squeeze!). I packaged Publican 3.6.1 and uploaded dh-linktree 0.4 to fix a FTBFS issue introduced with Perl 5.18. Of anecdotal importance, but I also filed bug #721849 after seeing how much energy was spent to ensure debian/rules didn t contain an improper copyright statement. Thanks See you next month for a new summary of my activities.

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

I just received an USB headset from Plantronics. Since it has a keypad on it, with buttons to mute the microphone and to adjust the volume, it appears as both a sound card and a keyboard. Problem: that keyboard sends a mouse ButtonPress 1 (yes, a mouse button event, do not ask me how that is materially and logically possible) when the microphone is muted, and only sends the corresponding ButtonRelease 1 when it is unmuted. As a result, the pointer behaves as if the mouse button was pressed continuously, rendering the desktop quite unusable.This situation has been the object of many discussions and bug reports. All of them always suggest the same solution: making X.Org ignore the keyboard associated to the headset, with an important side effect: volume adjustment will no longer be possible using the headset buttons. Microphone muting will still be available though, since it is implemented directly in the headset. There is a better solution however: remap the mouse button 1 of that keyboard (yes, the idea that a keyboard has mouse buttons is quite funny) to disable it. To do that temporarily:

 $ # Get the identifier of the Plantronics keyboard
$ xinput --list
  Virtual core pointer            id=2  [master pointer  (3)]
      Logitech USB Optical Mouse  id=10 [slave  pointer  (2)]
  Virtual core keyboard           id=3  [master keyboard (2)]
      Power Button                id=6  [slave  keyboard (3)]
      Logitech USB Keyboard       id=8  [slave  keyboard (3)]
      Plantronics .Audio 400 DSP  id=11 [slave  keyboard (3)]
$ # Remap its mouse button 1 to 0 (disable)
$ xinput --set-button-map 11 0

And to do it permanently, create a file /etc/X11/xorg.conf.d/plantronics.conf and restart X.Org:

 Section "InputClass"
    Identifier "Plantronics"
    MatchVendor "Plantronics"
    Option "ButtonMapping" "0"
EndSection

This way, the mouse button 1 events from the headset keyboard are ignored, while all the other events it generates, that is KeyPress/KeyRelease XF86AudioLowerVolume and XF86AudioRaiseVolume, are not.

Weblate, a free web-based translation management system, of course also needs to be translated. Now it's right time to complete translation into your language before Weblate 1.7 will be released. The release is currently planned on Monday, to have clean table before hacking on Weblate during Hackweek. There is not much time left so jump in right now and start translating :-).

Filed under: English SUSE Weblate 0 comments Flattr this!

Continuing in photo blog posts, here is our last vacation - in the beginning of September we've traveled around Slovenia, mostly for hiking, but we've enjoyed other things as well. Our first short hike was around lake Bled, which is nice lake placed in between mountains: Afternoon we had some time left, so we've walked around Peri nik waterfall, which was close to Mojstrana where we were accommodated (if you will be looking for accommodation there, check River Cottage): Then it came time for some serious hiking and we went up to the mountains, in the end we did not make it to Triglav because of weather, but we've gone on Cmir: After that we had to relax a bit and visited Ljubljana and ended up near kocjan Caves which we've visited on next day: After relaxing evening in Saksida winery, it was time to go back to mountains. We've started visiting Tolmin gorges, which is nice natural area worth short detour: Last days we've spent near Bovec and hiked around a bit, one of the things we've enjoyed most is trip to Krnsko lake: This was definitely not our last trip to Slovenia as there are still some places we want to visit :-).

Filed under: English Photography Travelling 2 comments Flattr this!

Dustin Kirkland recently wrote that "Fingerprints are usernames, not passwords". I don't really agree, I think fingerprints are fine for lightweight authentication. iOS at least allows you to only require a pass code after a time period has expired, so you don't have to authenticate to the phone all the time. Replacing no authentication with weak authentication (but only for a fairly short period) will improve security over the current status, even if it's not perfect. Having something similar for Linux would also be reasonable, I think. Allow authentication with a fingerprint if I've only been gone for lunch (or maybe just for a trip to the loo), but require password or token if I've been gone for longer. There's a balance to be struck between convenience and security.

Here in the US, the Affordable Care Act is finally going into effect, with accompanying drama. I managed to get signed up today at healthcare.gov. After not having health insurance since 2000, I will finally be covered starting January 1 2014. Since my income is mosty publically known anyway, I thought it might be helpful to blog about some details. I was uninsured for 14 years due to a combination of three factors:

1. Initially, youthful stupidity and/or a perfectly resonable cost/benefit analysis. (Take your pick.)
2. Due to the US health insurance system being obviously broken, and my preference to avoid things that are broken. Especially when the breakage involved insurers refusing to cover me at any sane level due to a minor and easily controlled pre-existing condition.
3. Since I'm not much motivated by income levels, and am very motivated to have time to work on things that are important to me, my income has been on average pretty low, and perhaps more importantly, I have intentionally avoided being a full-time employee of anyone at any point in the past 14 years (have rejected job offers), and so was not eligible for any employee plans which were the only reasonable way to be covered in the US. (See point #2.)

So, if you're stuck waiting in line on healthcare.gov (is this an entirely new online experience brought to us by the US government?), or have seen any of the dozen or so failure modes that I saw just trying to register for a login to the site, yeah, it's massively overloaded right now, and it's also quite broken on a number of technical levels. But you can eventually get though it. Based on some of the bugs I saw, it may help to have an large number of email addresses and use a different one for each application attempt. It also wouldn't hurt to write some programs to automate the attempts, because otherwise you may have to fill out the same form dozens of times. And no, you can't use "you+foo@bar.com" for your email; despite funding the development of RFC-822 in the 80's, the US government is clueless about what consititutes a valid email address. But my "favorite" misfeature of the site is that it refuses to let you enter any accented characters, or characters not in the latin alphabet when signing up. Even if they're, you know, part of your name. (Welcome back to Ellis Island..) I want to check the git repository to see if I can find the backstory for these and other interesting technical decisions, but they have forgotten to push anything to it for over 3 months. The good news is that once you get past the initial signup process, and assuming you get the confirmation mail before the really short expiration period of apparently less than 1 hour (another interesting technical choice, given things like greylisting), the actual exchange is not badly overloaded, and nor is it very buggy (comparatively). I was able to complete an application in about an hour. The irony is that after all that, I was only able to choose from one health insurer covering my area on the so-called "exchange". (Blue Cross/Blue Shield) I also signed up for dental insurance (it was a welcome surprise that the site offers this at all) and had a choice of two insurers for that. The application process was made more uncertian for me since I have no idea what I'll end up doing for money once my current crowdsourced year of work is done. The site wants you to know how much income you'll have in 2014, and my guess is anywhere between $6000 (from a rental property) and about what I made this year (approx $25000 before taxes). Or up, if I say, answered the Google pings. The best choice seemed to be to answer what I made this year, which is also close to what I made last year. So, I'll be paying around $200/month for a combination of not very good health insurance, and not very good dental insurance. There is around $750/year of financial aid to people at my guesstimated 2014 income level, which would drop that to $140/month, but I will let them refund me whatever that turns out to be in a lump sum later instead. For comparison, I am lucky to spend rather less renting a three bedroom house situated in 25 acres of woods.. It's strange to think that all of this is an improvement to the system here in the US, especially given all the better options that could have been passed instead, but it seems that it probably is. Especially when I consider the many people around me who are less fortunate than myself. If you'd like a broader perspective on this, see Tobias Buckell's "American healthcare was already socialized by Reagan, we re just fighting about how to pay for it".