In April this year, Iain Banks announced that he had inoperable cancer. At the time I was reading what became his last Culture novel, "The Hydrogen Sonata". Banks died shortly afterwards in June. I came across this passage in "The Hydrogen Sonata" which struck me as poignant:

Living either never has any point, or is always its own point; being a naturally cheery soul, I lean towards the latter. However, just having done more of it than someone else doesn't really make much difference.

Much belated RIP, Iain Banks.

This is a quick bug-fix release of my collection of POD formatters. When I fixed a problem with the latest Pod::Simple and added some tests, I had assumed that the behavior of Pod::Simple with invalid POD would always be the same. Unfortunately, for the particular invalid POD that triggered the bug, versions of Pod::Simple from Perl 5.16 and earlier didn't produce any errors. That caused the test case to fail everywhere since it didn't find the error section it expected. This release now skips those specific tests on older versions, while still ensuring that no unexpected exceptions or warnings are thrown. It also fixes a documentation bug I noticed while working on other things. You can get the latest release from CPAN or from the podlators distribution page.

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.

The tail end of this week was mostly spoiled by the discovery that libbeanstalkclient-ruby was not included in Wheezy. Apparently it was removed because the maintainer had no time, and there were no reverse dependencies - #650308. Debian maintainers really need to appreciate that no official dependencies doesn't mean a package is unused. Last year I needed to redesign our companies monitoring software, because we ran out of options that scaled well. I came up with the (obvious) solution:

• Have a central queue containing jobs to process.
  • e.g. Run a ping-test on host1.example.com
  • e.g. Run an SSH-probe on host99.example.com
  • e.g. Fetch a web-page from https://example3.net/ and test it has some text or a given HTTP status code.
  • (About 15 different test-types are available).
• Have N workers each pull one job from the queue, execute it, and send the results somewhere.

I chose beanstalkd for my central queue precisely because it was packaged for Debian, had a client library I could use, and seemed to be a good fit. It was a good fit, a year on and we're still running around 5000 tests every minute with 10 workers. The monitoring tool is called Custodian Custodian, and I think I've mentioned it before here and on the company blog. It looks like we'll need to re-package the Ruby beanstalk client, and distribute it alongside our project now. That's not ideal, but also not a huge amount of work. In summary? Debian you're awesome. But libraries shouldn't be removed unless it can't be helped, because you have more users than you know.

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.

Despite the fact that I've had very little time to either read or write reviews, I haven't stopped buying a few books here and there. And, of course, Powell's Indiespensable keeps coming. Matt Bell In the House Upon the Dirt Between the Lake and the Woods (mainstream)
Steven Brust Orca (sff)
Steven Brust Dragon (sff)
John W. Campbell Collected Editorials from Analog (non-fiction)
Jane Fletcher The Walls of Westernfort (sff)
Mira Grant How Green This Land, How Blu This Sea (sff)
Tate Hallaway Tall, Dark, & Dead (sff)
Diana Wynne Jones Howl's Moving Castle (sff)
Rebecca Lee Bobcat and Other Stories (mainstream)
Victor Lombardi Why We Fail (non-fiction)
George R.R. Martin & Gardner Dozois (ed.) Songs of Love and Death (sff anthology)
Seanan McGuire In Sea-Salt Tears (sff)
Seanan McGuire Late Eclipses (sff)
Justina Robson Selling Out (sff)
John Scalzi Muse of Fire (sff)
Mark Slouka Brewster (mainstream)
Tor.com (ed.) The Stories (sff anthology)
Carrie Vaughn Kitty and the Midnight Hour (sff) This is a wide variety of random stuff, including some stuff that was free (the Tor.com anthology, which is every piece of short fiction they've published and is about 4000 pages, the Campbell editorials from the Internet Archive) and a lot of stuff that was on sale. As well as another two shipments of Indiespensible. The Brust books I've already read and are already in the family, but I hooked a friend of mine on the Vlad Taltos series, and those were the only two that I both didn't have and that weren't available on Kindle. So I picked them up while he was visiting so that he could read the whole series.

This release rolls up various changes made as part of current work on other packages. I have several releases coming up, hopefully soon, but I've had a lot of other things going on, so neither review writing nor software releasing is going quite as fast as I'd like. In this release is a refactoring of the OpenSSL library probes to change the names of the macros and variables and to add a macro when the libraries are optional. Also added are Autoconf macros to probe for the TinyCDB library. In the standard Perl tests, Test::RRA now supports module version numbers containing an underscore and reports the required version of a module if a test is skipped. The standard Perl strictness tests now support a configurable ignore list for Perl scripts that shouldn't be tested. In Kerberos portability, krb5_free_default_realm is now replaced with krb5_xfree instead of free on Heimdal, and portable/kadmin.h handles portability for kadmin error codes. Finally, the portability library now avoids leaking a dummy symbol when built with GCC and incorporated into a shared object. You can get the latest version from the rra-c-util distribution page.

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.

Now that GSOC is over and DebianDroid is in a more functional state i ve decided to finally publish the app to the Google Play Store and to F-Droid. That way I can get way more feedback about it plus it might already be useful for some people.

---

You can find a features and todo list in the readme in my github repo or alioth mirror. Special thanks to Hans-Christoph Steiner (my gsoc mentor) and to Paul Tagliamonte for their help and feedback along the way. If you want to help send me your feedback about the app via mail to onexemailx@gmail.com or via github or play store. I m looking for bugs, new feature ideas, suggestions for rest/soap/any other apis I can use to implement features in the todo list and also possibly for other icon or design ideas. That s all for now. :) Edit: I did a last minute rename of the app package to net.debian.debiandroid (since debian.com doesn t exist) and it was a bit more complicated that I expected so I had to republish the app in the play store. Just uninstall the old one and install it again from the link above. I changed the description of the old app as well so it should be clear which is which. Sorry for the inconvenience. The good thing is that I fixed some bugs/crashes as well.

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!

For a while I have been eyeing with the TI eZ430 Chronos watch, a slightly bulky sports watch that not only comes with a built-in thermometer, barometer and accelerometer, but also a freely programmable micro controller (from the TI MSP430 family hence the name). In addition it has a small radio chip included and can communicate wirelessly with the computer, or possibly other devices. All in all, a very geeky toy. A week ago I managed to buy one quite cheaply via eBay (30 including shipping). It took me a while to get an overview of the various resources about the device. Here is what I have learned.

• Hardware: I have the new edition (the included debug board and wireless access point are white). This means that I cannot update the software of the watch via the wireless connection, and it means that most software written for it does not support the new altimeter sensor (yet).
• Development: Debian is a very suitable development platform; the packages mspdebug and gcc-msp430 provide all I need to compile (make config && make) and upload (mspdebug rf2500 "prog ../foo.txt") new software.
• Code: Besides the original software that comes with the device (which supports the new hardware), there are two main lines of community-driven developments: OpenChronos and openchronos-ng. The former is (as the name suggests) older and maintained mostly by forks in various places. The latter is newer, its UI deviates further from the original software and seems to be slightly more active.
• Communication: Both of these have their own mailinglists (openchronos, where I did not get a reply yet, and ti-chronos-development, where my messages are still waiting for moderation). I found only one IRC channel, #openchronos on freenode, with similarly little activity.

After I found that out, I tried to hack a bit on the various software. The first issue I had (and still have) is that I cannot use the buttons of the device while it is attached to the debug board. They do work if forget to take out the battery, but supposedly that is bad for the battery. So my compile-upload-test-cycle becomes a compile-upload-detach-insert-battery-test-remove-battery-attach-cycle. I could not find out how to emulate button presses using mspdebug. Any suggestions are welcome. The other problem was the new altimeter hardware: Neither OpenChronos nor openchronos-ng support that yet. I originally planned to port the driver from the official software to a random OpenChronos fork when I read that Richard Rondu did that to openchronos-ng yet. I found the code in a month-old merge-request. I tried it, it worked, and I started to clean up the code a bit and add a variometer mode to it, e.g. displaying the current rate of climb my ultimate goal is to use this as a surprisingly cheap variometer for paragliding. After a day of hacking and quickly lifting the watch from the room floor to the room ceiling and back I believe that it works okish, although quite a few parameter can benefit from more tweaking: sample rate (currently 20Hz), length of history (currently 2s) and the linear regression method (currently simply the difference between the average of the samples of the current second with the samples of the last second). As always, patches welcome, the code is in my fork on sf.net.
Next to do would be to enable some buzzing noise depending on the rate of change; during flight I don t want to decipher a low-contract LCD screen. But it is questionable whether the buzzer is loud enough we ll see. I was also happy to hear that there are other zE430-hackers in Karlsruhe, one of them for example tries to make the alarm clock sleep-cycle-aware.

The license says you can use free and open source software for any reason, but the FBI wouldn t agree with your questions Silk Road operator identified by asking a PHP related question on stackoverflow. See The Bonehead Mistake That Brought Down an Online Drug-Dealing Empire on Slate.com
Filed under: Uncategorized

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".

XMir's been delayed from Ubuntu 13.10. The stated reason is that multi-monitor support isn't sufficiently reliable. That's true, but it's far from the only problem that XMir still has:

• It's still broken on some single-monitor systems

Some machines have display corruption. There are writes to freed memory. To be fair, some of the behaviour that's been seen has been down to underlying bugs in the Xorg drivers that were never triggered under normal use but are hit by XMir. Others are down to implicit assumptions made in the drivers that XMir happens to violate. The problem is that there doesn't appear to have been enough room in the schedule to deal with these interactions, presumably because nobody accounted for the inevitable "This thing we thought would be easy turns out to be difficult" part of the project.


• The input driver bug still isn't really fixed

I've mentioned this bug before. It's now marked "Fix released" which is kind of true but not really. Mir now tells XMir that the VT is changing before the VT is changed, but it doesn't wait for that to complete before switching the VTs. Until XMir is scheduled and runs, it's still receiving input events. In most circumstances that window is small, so there's no real risk of triggering it accidentally.

There's one corner case where it might still cause problems. Simply running isn't enough - XMir has to make progress through its event loop. That'll only happen if the X server is processing its wakeup events, and it's possible to effectively stall that by submitting a sufficiently awkward drawing request to the server. The X server will appear to freeze, and if the user then attempts to work out what's going on by switching to a VT and logging in, those input events will still be going to XMir. It's left as an exercise to the reader to construct ways to take advantage of this.

This can't happen in Xorg because the VT switch is blocked until the input devices have been released. Mir could have done the same, but doesn't because of a conscious design decision - in the Ubuntu Phone world, clients stop doing things when they're told to. Ubuntu Desktop is expected to behave the same way.

This is an unfortunate situation to be in. Ubuntu Desktop was told that they were switching to XMir, but Mir development seems to be driven primarily by the needs of Ubuntu Phone. XMir has to do things that no other Mir client will ever cope with, and unless Mir development takes that into account it's inevitably going to suffer breakage like this. Canonical management needs to resolve this if there's any hope of ever shipping XMir as the default desktop environment.


• It's still missing features

XMir doesn't support colour profiles. XRandR properties aren't exposed, so there's no way to control TV output encoding or overscan. There's still no hardware cursor support. Switching to XMir now would reduce functionality without providing any user-visible gain.

It's clear that XMir has turned into a larger project than Canonical had originally anticipated, but that's hardly surprising. There's only one developer with previous X experience working on it full-time, and the announced schedule provided no opportunity to deal with unexpected problems. As if that weren't enough, there's obvious conflict between Ubuntu Desktop and Ubuntu Phone when it comes to developer time and required functionality. The one hardware vendor who's willing to take a public stand has demonstrated that they have no interest in supporting XMir, despite Canonical assuring people that they were already engaging in productive negotiations with GPU manufacturers.

Multiple monitor support may be the single most obvious feature where XMir is lacking, but it's not the only one. Technically and politically, this code is a long way from being ready for prime time. Without significant community contribution, Canonical need to focus on prioritising it appropriately rather than expecting a tiny number of developers to perform miracles. Or, alternatively, they could just drop XMir entirely and focus on Unity 8.

comments