About a month ago, I blogged about extremon. As a reminder, ExtreMon is a monitoring tool that allows you to view things as they are happening, rather than with the ~5 minute delay that munin gives you, and also avoiding the quad-state limitation of Nagios' "good", "bad", "ugly", and "unknown" states. No, they're not really called that. Yes, I know you knew that. Anyway. In my blog post, I explained how you can set up ExtreMon, and I also set up a fairly limited demo version on my own server. But I have since realized that while it is functional, it doesn't actually show why ExtreMon is so great. In an effort to remedy that, I present you an example of what ExtreMon can do. Let's start with a screenshot of the ExtreMon console at the customer for which I spent time trying to figure out how to get it up and running: Click for full sized version. You'll note that even in that full-sized version, many things are unreadable. This is because the ExtreMon console allows one to move around (right mouse button drag for zoom; left mouse button drag for moving around; control+RMB for rotate; center mouse button to reset to default); so what matters is that everything fits on the screen, not whether it is all readable (if you need to read, you zoom). The image shows 18 rectangles. Each rectangle represents a single machine in this particular customer's HPC cluster. The top three rectangles are the cluster's file servers; the rest are its high performance nodes. You'll note that the left fileserver has 8 processor cores (top row), 8 network cards (bottom row, left part), and it also shows information on its memory usage (bottom row, small rectangle in the middle) as well as its NFS client and server procedure calls (bottom row, slightly larger rectangles to the right). This file server is the one on which I installed ZFS a while back; hence the large amount of disks visible in the middle row. The leftmost disk is the root filesystem (which is an ext4 off a hardware RAID1); the two rightmost "disks" are the PCIe-attached SSDs which are used for the ZFS L2ARC and write log. The other disks in this file server nicely show how ZFS does write load balancing over all its disks. The second file server has a hardware RAID1 on which it stores all its data; as such, there is only one disk graph there. It is also somewhat more limited in network, as it has only two NICs. It does, however, also have 8 cores. The last file server has no more than four processor cores; in addition, it also does not have a hardware RAID controller, so it must use software RAID over its four hard disks. This server is used for archival purposes, mostly, since it is insufficient for most anything else. As said, the other nodes are the "compute nodes", where the hard work is done. Most of these compute nodes have 16 cores each; two have 12 instead. When this particular screenshot was taken, four of the nodes (the ones showing red in their processor graphs) were hard at work; the others seem to have been mostly idling. In addition to the familiar memory, NFS (client only), network, and processor graphs, these nodes also show a "swap space" graph (just below the memory one), which seems fine for most nodes, except for the bottom left one (which shows a few bars that are coloured yellow rather than green). The green/yellow/red stuff is supposed to represent the "ok", "warning", "bad" states that would be familiar from Nagios. In this particular case, however, where "processor is busy all the time" is actually a wanted state, a low amount of idleness on the part of the processor isn't actually a problem, on the contrary. I did consider, therefore, to modify the ExtreMon configuration so that the processor graphs would not show red when the system was under high load; however, I found that differences in colour like this actually makes it more easy to see, at a glance, which machines are busy -- and that's one of the main reasons why we wanted to set this up. If you look carefully, you can find a particular processor core in the graph which shows 100% usage for "idle", "system", and "softirq", at the same time. Obviously that can't be the case, so there's a bug somewhere. Frank seems to believe it is a bug in CollectD; I haven't verified that. At any rate, though, this isn't usually a problem, due to the high update frequency of ExtreMon. The amount of data that's flowing through ExtreMon is amazing:

• 22 values for NFS (times two for the file servers) per server: 22x2x3+22x15
• 4 values for memory: 4x18
• 3 values for swap: 3x15
• 8 values per CPU core: 8x8x2+8x4+8x12x2+8x16x13
• 2 values per disk: 2x25+2+2x4
• 2 values per NIC: 2x8x12+2x2x2+2x4x4

Which renders a grand total of 2887 data points that are shown in this particular screenshot; and then I'm not even counting all the intermediate values, some of which also pass through ExtreMon. Nor am I counting the extra bits which have since been added (this screenshot is a few days old, now, and I'm still finetuning things). Yet even so, ExtreMon manages to update those values once every few seconds, in the worst case. As a result, the display isn't static for a moment, constantly moving and updating data so that what you see is never out of date for more than a second or two. Awesome.

LCA 2015 is next week so it seems like a good time to offer some suggestions for other delegates based on observations of past LCAs. There s nothing LCA specific about the advice, but everything is based on events that happened at past LCAs. Don t Oppose a Lecture Question time at the end of a lecture isn t the time to demonstrate that you oppose everything about the lecture. Discussion time between talks at a mini-conf isn t a time to demonstrate that you oppose the entire mini-conf. If you think a lecture or mini-conf is entirely wrong then you shouldn t attend. The conference organisers decide which lectures and mini-confs are worthy of inclusion and the large number of people who attend the conference are signalling their support for the judgement of the conference organisers. The people who attend the lectures and mini-confs in question want to learn about the topics in question and people who object should be silent. If someone gives a lecture about technology which appears to have a flaw then it might be OK to ask one single question about how that issue is resolved, apart from that the lecture hall is for the lecturer to describe their vision. The worst example of this was between talks at the Haecksen mini-conf last year when an elderly man tried at great length to convince me that everything about feminism is wrong. I m not sure to what degree the Haecksen mini-conf is supposed to be a feminist event, but I think it s quite obviously connected to feminism which is of course was why he wanted to pull that stunt. After he discovered that I was not going to be convinced and that I wasn t at all interested in the discussion he went to the front of the room to make a sexist joke and left. Consider Your Share of Conference Resources I ve previously written about the length of conference questions [1]. Question time after a lecture is a resource that is shared among all delegates. Consider whether you are asking more questions than the other delegates and whether the questions are adding benefit to other people. If not then send email to the speaker or talk to them after their lecture. Note that good questions can add significant value to the experience of most delegates. For example when a lecturer appears to be having difficulty in describing their ideas to the audience then good questions can make a real difference, but it takes significant skill to ask such questions. Dorm Walls Are Thin LCA is one of many conferences that is typically held at a university with dorm rooms offered for delegates. Dorm rooms tend to have thinner walls than hotel rooms so it s good to avoid needless noise at night. If one of your devices is going to make sounds at night please check the volume settings before you start it. At one LCA I was startled at about 2AM but the sound of a very loud porn video from a nearby dorm room, the volume was reduced within a few seconds, but it s difficult to get to sleep quickly after that sort of surprise. If you set an alarm then try to avoid waking other people. If you set an early alarm and then just get up then other people will get back to sleep, but pressing snooze repeatedly for several hours (as has been done in the past) is anti-social. Generally I think that an alarm should be at a low volume unless it is set for less than an hour before the first lecture in which case waking people in other dorm rooms might be doing them a favor. Phones in Lectures Do I need to write about this? Apparently I do because people keep doing it! Phones can be easily turned to vibrate mode, most people who I ve observed taking calls in LCA lectures have managed this but it s worth noting for those who don t. There are very few good reasons for actually taking a call when in a lecture. If the hospital calls to tell you that they have found a matching organ donor then it s a good reason to take the call, but I can t think of any other good example. Many LCA delegates do system administration work and get calls at all times of the day and night when servers have problems. But that isn t an excuse for having a conversation in the middle of the lecture hall while the lecture is in progress (as has been done). If you press the green button on a phone you can then walk out of the lecture hall before talking, it s expected that mobile phone calls sometimes have signal problems at the start of the call so no-one is going to be particularly surprised if it takes 10 seconds before you say hello. As an aside, I think that the requirement for not disturbing other people depends on the number of people who are there to be disturbed. In tutorials there are fewer people and the requirements for avoiding phone calls are less strict. In BoFs the requirements are less strict again. But the above is based on behaviour I ve witnessed in mini-confs and main lectures. Smoking It is the responsibility of people who consume substances to ensure that their actions don t affect others. For smokers that means smoking far enough away from lecture halls that it s possible for other delegates to attend the lecture without breathing in smoke. Don t smoke in the lecture halls or near the doorways. Also using an e-cigarette is still smoking, don t do it in a lecture hall. Photography Unwanted photography can be harassment. I don t think there s a need to ask for permission to photograp people who harass others or break the law. But photographing people who break the social agreement as to what should be done in a lecture probably isn t. At a previous LCA a man wanted to ask so many questions at a keynote lecture that he had a page of written notes (seriously), that was obviously outside the expected range of behaviour but probably didn t justify the many people who photographed him. A Final Note I don t think that LCA is in any way different from other conferences in this regard. Also I don t think that there s much that conference organisers can or should do about such things.

• [1] http://etbe.coker.com.au/2014/01/06/length-conference-questions/

Every few days, someone publishes a new guide, tutorial, library or framework about web scraping, the practice of extracting information from websites where an API is either not provided or is otherwise incomplete. However, I find these resources fundamentally deceptive the arduous parts of "real world" scraping simply aren't in the parsing and extraction of data from the target page, the typical focus of these articles. The difficulties are invariably in "post-processing"; working around incomplete data on the page, handling errors gracefully and retrying in some (but not all) situations, keeping on top of layout/URL/data changes to the target site, not hitting your target site too often, logging into the target site if necessary and rotating credentials and IP addresses, respecting robots.txt, target site being utterly braindead, keeping users meaningfully informed of scraping progress if they are waiting of it, target site adding and removing data resulting in a null-leaning database schema, sane parallelisation in the presence of prioritisation of important requests, difficulties in monitoring a scraping system due to its implicitly non-deterministic nature, and general problems associated with long-running background processes in web stacks. Et cetera. In other words, extracting the right text on the page is the easiest and trivial part by far, with little practical difference between an admittedly cute jQuery-esque parsing library or even just using a blunt regular expression. It would be quixotic to simply retort that sites should provide "proper" APIs but I would love to see more attempts at solutions that go beyond the superficial.

A new release of the RcppCNPy package is now on CRAN. This release mostly solidifies and fixes things. Support for saving integer objects, which was expanded in release 0.2.3, was not entirely correct. Operations on big-endian systems were not up to snuff either. Wush Wu helped in getting this right with very diligent testing and patching particularly on big-endian hardware. We also got a pull request from Romain to reflect better const correctness at the Rcpp side of things. Last but not least we obliged by the CRAN Maintainers to not assume one could call gzip from system() call because, well, you guessed it.

Changes in version 0.2.4 (2015-01-05)

• Support for saving integer objects was not correct and has been fixed.
• Support for loading and saving on 'big endian' systems was incomplete, has been greatly expanded and corrected, thanks in large part to very diligent testing as well as patching by Wush Wu.
• The implementation now uses const iterators, thanks to a pull request by Romain Francois.
• The vignette no longer assumes that one can call gzip via system as the world's leading consumer OS may disagree.

CRANberries also provides a diffstat report for the latest release. As always, feedback is welcome and the rcpp-devel mailing list off the R-Forge page for Rcpp is may be the best place to start a discussion. GitHub issue tickets are also welcome.

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

I promised to write about this a long time, ooops... :-) Another ARM port in Debian - yay! arm64 is officially a release architecture for Jessie, aka Debian version 8. That's taken a lot of manual porting and development effort over the last couple of years, and it's also taken a lot of CPU time - there are ~21,000 source packages in Debian Jessie! As is often the case for a brand new architecture like arm64 (or AArch64, to use ARM's own terminology), hardware can be really difficult to get hold of. In time this will cease to be an issue as hardware becomes more commoditised, but in Debian we really struggled to get hold of equipment for a very long time during the early part of the port. First bring-up in Debian Ports To start with, we could use ARM's own AArch64 software models to build the first few packages. This worked, but only very slowly. Then Chen Baozi and the folks running the Tianhe-2 supercomputer project in Guangzhou, China contacted us to offer access to some arm64 hardware, and this is what Wookey used for bootstrapping the new port in the unofficial Debian Ports archive. This has now become the normal way for new architectures to get into Debian. We got most of the archive built in debian-ports this way, and we could then use those results to seed the initial core set of packages in the main Debian archive. Second bring-up - moving into the main Debian archive By the time that first Debian bring-up was done, ARM was starting to produce its own "Juno" development boards, and with the help of my boss^4 James McNiven we managed to acquire a couple of those machines for use as official Debian build machines. The existing machines in China were faster, but for various reasons quite difficult to maintain as official Debian machines. So I set up the Junos as buildds just before going to DebConf in August 2014. They ran very well, and (for dev boards!) were very fast and stable. They built a large chunk of the Debian archive, but as the release freeze for Jessie grew close we weren't quite there. There was a small but persistent backlog of un-built packages that were causing us issues, plus the Juno machines are/were not quite suitable as porter boxes for Debian developers all over the world to use for debugging their packages on the new architecture. More horsepower - Linaro machines This is where Linaro came to our aid. Linaro's goal is to help improve Free and Open Source Software on ARM, and one of the more recent projects in Linaro is a cluster of servers that are made available for software developers to use to get early access to ARMv8 (arm64) hardware. It's a great way for people who are interested in this new architecture to try things out, port their software or indeed just help with the general porting effort. As Debian is seen as such an important part of the FLOSS ecosystem, we managed to negotiate dedicated access to three of the machines in that cluster for Debian's use and we set those up in October, shortly before the freeze for Jessie. Andy Doan spent a lot of his time getting these machines going for us, and then I set up two of them as build machines and one as the porter box we were still needing. With these extra machines available, we quickly caught up with the ever-busy "Needs-Build" queue and we've got sufficient build power now to keep things going for the Jessie release. We were officially added to the list of release architectures at the Cambridge mini-Debconf in November, and all is looking good now! And in the future? I've organised the loan of another arm64 machine from AMD for Debian to use for further porting and/or building. We're also expecting that more and more machines will be coming out soon as vendors move on from prototyping to producing real customer equipment. Once that's happened, more kit will be available and everybody will be able to have arm64-powered computers in the server room, on their desk and even inside their laptop! Mine will be running Debian Jessie... :-) Thanks! There's been a lot of people involved in the Debian arm64 bootstrapping at various stages, so many that I couldn't possibly credit them all! I'll highlight some, though. :-) First of all, Wookey's life has revolved around this port for the last few years, tirelessly porting, fixing and hacking out package builds to get us going. We've had loads of help from other teams in Debian, particularly the massive patience of the DSA folks with getting early machines up and running and the prodding of the ftpmaster, buildd and release teams when we've been grinding our way through ever more package builds and dependency loops. We've also had really good support from toolchain folks in Debian and ARM, fixing bugs as we've found them by stressing new code and new machines. We've had a number of other people helping by filing bugs and posting patches to help us get things built and working. And (last but not least!) thanks to all the folks who've helped us beg and borrow the hardware to make the Debian arm64 port a reality. Rumours of even more ARM ports coming soon are entirely scurrilous... *grin*

My LTS December In December 2014 I spent 11h on Debian LTS work and managed to get six DLAs released and another one almost done... I did:

• Release DLA 103-1 which was previously prepared by Ben, Raphael and myself. So while for this release in December I only had to review one patch, I also had to build the package, provide prelimary .debs, ask for feedback, do some final smoke tests, write the announcement and do the upload. In total this still took 2.5h to "just release it"...
• Doing DLA 114-1 for bind9 was rather straightforward,
• As was DLA 116-1 for ntp, which I managed to release within one hour after the DSA for wheezy, despite me having to make the patch apply cleanly due to some openssl differences...
• I mentioned the bit about openssl because noone ever made a mistake with such patches. Seriously, I mean: I would welcome a public review system for security fixes. We are all humans and we all make mistakes. I do think my ntp patching was safe, but... mistakes happen.
• DLA 118-1 was basically "just" a new 2.6.32.65 kernel update, which I almost released on my own, until (thankfully) Ben helped me wih one patch from .65 not applying (a fix for a wrong fix which Debian already had correctly fixed), which was due to a patch not correctly removed due to linenumber changes. And while I was still wrapping my head around applying+deapplying these very similar looking patches, Ben had already commited the fix. I'm quite happy with this sharing the work, due to the following benefits: a.) Ben can spend more time on important tasks and b.) the LTS user get more kernel security fixes faster.
• DLA 119-1 for subversion was a rather straight forward take from the wheez DSAs again, I just had to make sure to also include the 2nd regression fixing DSA.
• And then, I failed to finish my work on a jqueryui update before 31c3 started. And 31c3 really only ended yesterday when I helped putting stuff on trucks and cleaned the big hall... So that's also why I'm only writing this blog post now, and not two weeks ago, like I probably better had. Anyway, according to the security-tracker jqueryui is affected by two CVEs and that's wrong: CVE-2012-6662 does not affect the squeeze version. CVE-2010-5312 on the other hand affects the squeeze version, I know how to fix it, I just lacked a quiet moment to prepare my fix properly and test it, and so I've rather postponed doing so during 31c3... so, expect a DLA for jqeuryui very soon now!

Thanks to everyone who is supporting Squeeze LTS in whatever form! Even just expressing that you or the company or project you're working with is using LTS, is useful, as it's always nice to hear once work is used and appreciated. If you can contribute more, please do so. If you can't, that's also fine. It's free software after all

Review: Code Complete, Second Edition, by Steve McConnell

Publisher:	Microsoft
Copyright:	June 2004
ISBN:	0-7356-1967-0
Format:	Kindle
Pages:	960

As mentioned in the title, this is a review of the second edition of Code Complete, published in 2004. There doesn't appear to be a later edition at the time of this writing. I should say, as a prefix to this review, that I'm the sort of person who really likes style guides. When learning a language, a style guide is usually the second or third document I read. I enjoy debates over the clearest way to express a concept in code, trying to keep all the code in a large project consistent, and discussing the subtle trade-offs that sit on the boundary between mechanical style issues and the expressiveness of programming. I try to spend some time reading good code and getting better at expressing myself in code. Presumably, therefore, I'm the target audience for this book. It sounded good from the descriptions, so I picked it up during one of the Microsoft Press sales. The stated goal of Code Complete is to collect in one place as much as possible of the oral tradition and lore of the programming field, to try to document and communicate the techniques and approaches that make someone a good programmer. The table of contents sounds like a style guide, with entire sections on variables and statements in addition to topics like how to improve existing code and how to design a new program. If you're starting to think that a 960 page style guide sounds like a bad idea, you're wiser than I. (In my defense, I grabbed this as an ebook and didn't realize how large it was before I bought it.) I have not actually finished this book. I hate to do this: I don't like reviewing books I haven't finished (this will be the first), and I hate starting books and not finishing them. (This is probably not particularly wise, since some books aren't worth finishing, but I've gotten into a rhythm of reading and reviewing that works for me, so I try not to mess with it.) But I've been trying to finish this book off and on for about a year, I don't think it's worth the time investment, and I think I've gotten far enough in it to provide some warnings by others who are deceived by the very high ratings that it gets on Amazon and other places. The primarily problem with Code Complete is its sheer, mind-numbing comprehensiveness. It tries to provide a set of guidelines and a checklist to think about at each level of writing code. This is one of those ideas that might sound good on paper, but which completely doesn't work for me. There is no way I'm going to keep this many rules in my head, in the form of rules, while programming. Much of good style has to be done by feel, and the book I'm looking for is one that improves my feel and my sense of taste for code. What Code Complete seems to provide instead is a compilation of every thought that McConnell has ever had about programming. There's a lot of basic material, a few thoughtful statements, a ton of style advice, an endless compilation of trade-offs and concepts that one should keep in mind, and just a massive, overwhelming pile of stuff. Each chapter (and there are a lot of chapters) ends in a checklist of things that you should think about when doing a particular programming task. To give you a feel for the overwhelming level of trivia here, this is the checklist at the end of the chapter where I stopped reading, on quality assurance in software. This is one picked at random; a lot of them are longer than this.

• Have you identified specific quality characteristics that are important to your project?
• Have you made others aware of the project's quality objectives?
• Have you differentiated between external and internal quality characteristics?
• Have you thought about the ways in which some characteristics might compete with or complement others?
• Does your project call for the use of several different error-detection techniques suited to finding several different kinds of errors?
• Does your project include a plan to take steps to assure software quality during each stage of software development?
• Is the quality measured in some way so that you can tell whether it's improving or degrading?
• Does management understand that quality assurance incurs additional costs up front in order to save costs later?

I'm not saying those are bad things to think about with quality assurance, but you may notice a few issues immediately. They're very general and vague, they're not phrased in a particularly compelling or memorable way, and there are a lot of them. This falls between two stools: it's too much for the programmer who is thinking about quality as part of an overall project but not focusing on it (particularly when you consider that the book is full of checklists like this for everything from variable naming to how to structuring if statements to program debugging), but it's not nearly specific or actionable enough for someone who is focusing on quality assurance. It's not that the information isn't organized: there's a lot of structure here. And there are bits and pieces here that are occasionally interesting. McConnell is very data-driven and tries to back up recommendations with research on error rates and similar concrete measurements. It's just insufficiently filtered and without elegant or memorable summary. There is far too much here, an overwhelming quantity, and hopelessly mixed between useful tidbits and obvious observations that anyone who has been programming for a while would pick up, all presented in the same earnest but dry tone. It didn't help that there's a lot here I didn't agree with. Some of that is to be expected: I've never agreed completely with any style guide. But McConnell kept advocating variable and function naming conventions that I find rather ugly and tedious, and the general style of code he advocates feels very "bureaucratic" to me. It's not exactly wrong, but one of the things that I look for in style discussions is to be inspired by the elegant and simple way someone finds to phrase something in code. A lot of the code in this book just felt mind-numbing. It's functional, but uninteresting; perfectly adequate for a large project, but not the sort of discussion that inspires me to improve the quality of my craft. So, I didn't finish this. I gave up about halfway through. It's frustrating, since I was occasionally finding an interesting nugget of information. But they were too few and far between, and the rest of the book was mostly... boring. It's possible that I just know too much about programming to be the person for whom that McConnell was writing this book. It's certainly true that the book has not aged particularly well; it's focused on fairly old-school languages (C, C++, Java, and Visual Basic) and says almost nothing about modern language techniques, although it does have a bit about extreme programming. But whatever the reason is, it didn't work for me at all. I would rate it as one of the worst books about programming I've tried to read. And that's notably different enough from its reviews that it seems worth throwing this out there as a warning. I'm quite disappointed, since I'd heard nothing but praise for this book before picking it up. But it's not for me, and I'm now dubious of its value for any programmer outside of a fairly narrow, large-team, waterfall development process involving large numbers of people writing very large quantities of code in languages that aren't very expressive. And, well, in that situation I think one would get more benefit from changing that environment than reading this book. Rating: unfinished

This was my first month working on Debian LTS. My first project at Codethink was winding down, so Freexian's Debian LTS initiative was able to hire me via Codethink. I spent all of the assigned 11.5 hours working on an update to the kernel package (linux-2.6, version 2.6.32-48squeeze9). We had stopped following the upstream stable branch maintained by Willy Tarreau after 2.6.32.60 (released October 2012). Since then, we have only applied specific security fixes and other critical fixes. Rapha l Hertzog and Holger Levsen started to rebase our package on 2.6.32.64 (released November 2014), bringing in a few security fixes we didn't yet have and a larger number of fixes for functional and performance issues. I spent most of my time reviewing the several hundred changes from the upstream stable branch. I found a number of mistakes that would have caused regressions. Those should all be fixed in the update to linux-2.6, though I did not have nearly enough time for a thorough regression test. I sent my fixes to Willy for inclusion in 2.6.32.65. I also reviewed and applied fixes for several security flaws in the kernel entry and exit paths. Andy Lutomirski identified and fixed a number of problems upstream, the most serious of which was CVE-2014-9322 (though this is not listed in the changelog because the details weren't yet public). Willy found and backported the upstream fixes for inclusion in 2.6.32.65. I checked that these make sense (so far as I understand this code) and verified that Andy's test cases now have the expected results when run on the new kernel version. Updated: Added references to Codethink and Freexian.

My monthly report covers a large part of what I have been doing in the free software world. I write it for my donators (thanks to them!) but also for the wider Debian community because it can give ideas to newcomers and it s one of the best ways to find volunteers to work with me on projects that matter to me. Debian LTS This month I have been paid to work 20 hours on Debian LTS. I did the following tasks:

• CVE triage: I pushed 47 commits to the security tracker this month. Due to this, I submitted two wishlist bugs against the security tracker: #772927 and #772961.
• I released DLA-106-1 which had been prepared by Osamu Aoki.
• I released DLA-111-1 fixing one CVE on cpio.
• I released DLA-113-1 and DLA-114-1 on bsd-mailx/heirloom-mailx fixing one CVE for the former and two CVE for the latter.
• I released DLA-120-1 on xorg-server. This update alone took more than 6h to backport all the patches, fixing a massive set of 12 CVE.

Not in the paid hours, but still related to Debian LTS, I kindly asked Linux Weekly News to cover Debian LTS in their security page and this is now live. You will see DLA on the usual security page and there s also a dedicated page tracking this: http://lwn.net/Alerts/Debian-LTS/ I modified the LTS wiki page to have a dedicated Funding sub-page. This avoids having a direct link to Freexian s offer on the main LTS page (which surprised a few persons) and allows to give some more background information and makes it possible for other persons/companies to also get listed in the same way (since there s no exclusive relationship between Debian and Freexian here!). And I also answered some questions of Nguyen Cong (a new LTS contributor, employed by Toshiba with explicit permission to contribute to LTS during work hours! \o/), on IRC, on ask.debian.net (again) and on the mailing list! It s great to see the LTS project expanding beyond current members of the Debian project. Distro Tracker I want to give again some more priority to Distro Tracker at least to complete the transition from the old PTS to this new service last month has been a bit better than November but not by much. I reviewed a patch in #771604 (about displaying long descriptions), I merged another patch in #757443 (fixing bad markup which rendered the page unusable with Konqueror), I fixed #760382 where package gone through NEW would never lose their version in NEW. Kali related contributions I m not covering my Kali work here but only some things which got contributed upstream (or to Debian). First I ensured that we could build the Kali ISO with live-build 4.x in jessie. This resulted in multiple patches merged to the Debian live project (1 2 3 4). I also submitted a patch for a regression in the handling of conditionals in package lists, it got dropped and has been fixed differently instead. I also filed #772651 to report a problem in how live-build decided of the variant of the live-config package to install. Kali has forked the sysvinit package to be able to disable the services by default and I was investigating how to port this feature in the new systemd world. It turns out systemd has such a feature natively: it s called Preset files. Unfortunately it s not usable in Debian because Debian does not call systemctl preset during package installation. I filed bug #772555 to get this fixed (in Stretch, it s too late for Jessie :-(). Saltstack I m using salt to automate some administration task in Kali, at home and at work. I discovered recently that the project tries to collect Salt Formulas : those are ready to use instructions for as many services as possibles. I started using this for some simple services and quickly felt the need to extend salt-formula , the set of states used to configure salt with salt. I submitted 5 pull requests (#73 and #74 to configure salt in standalone mode, #75 to enable the upstream package repositories, #76 to automatically download and enable the desired salt formulas, #77 for some bugfixes) and they have all been merged in less than 24 hours (that s the kind of thing that motivates you to contribute again in the future!). I also submitted a bug fix for samba-formula and a bug report in salt itself (#19180). BTW I have some salt states to setup schroot and sbuild. I will try to package those as proper salt formulas in the future Misc stuff Mailing list governance. In Debian, we often complain about meta-discussion on mailing lists (i.e. discussions about how we discuss together) and at the same time we need to have that kind of discussions from time to time. So I suggested to host those discussions in a new mailing list and to get this new list setup, our rules require to have other people interested in having this list. The idea had some support when we discussed it on debian-private, so I relaunched it on debian-project while filing the official request in the BTS: #772645. Unfortunately, I only got one second. So if you re interested in pursuing this idea, speak up now Sponsorship. I sponsored another Galette plugin this month: galette-plugin-fullcard. Thanks to Fran ois-R gis Vuillemin for his work. Publican. Following one of my bug report against Publican and with the help of the upstream author, we identified the problem and I submitted a patch. Thanks See you next month for a new summary of my activities.

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

If you re a Unix person instead of e.g. a Microsoft Windows person, you ve probably been annoyed by Iceweasel (or Mozilla Firefox ) creating a ~/Desktop directory, among others (things like ~/Downloads). Here s a quick fix I found somewhere in the net:

mkdir -p -m0700 ~/.config
cat >~/.config/user-dirs.dirs <<'EOF'
XDG_DESKTOP_DIR="$HOME/"
XDG_DOCUMENTS_DIR="$HOME/"
XDG_DOWNLOAD_DIR="$HOME/"
XDG_MUSIC_DIR="$HOME/"
XDG_PICTURES_DIR="$HOME/"
XDG_PUBLICSHARE_DIR="$HOME/"
XDG_TEMPLATES_DIR="$HOME/"
XDG_VIDEOS_DIR="$HOME/"
EOF

Upon next start, Iceweasel (and other XDG-compliant applications) will throw stuff into ~/ instead.

Review: Ancillary Sword, by Ann Leckie

Series:	Imperial Radch #2
Publisher:	Orbit
Copyright:	October 2014
ISBN:	0-316-24665-4
Format:	Trade paperback
Pages:	354

This is the second book in the Imperial Radch series and a direct sequel to Ancillary Justice. You don't want to read this book out of order, since the previous book sets up the background of everything that happens here. Besides, Ancillary Justice is an amazing book. It's going to be challenging to review Ancillary Sword without spoiling the previous book. If you're planning on reading Ancillary Justice but haven't gotten to it, you may want to stop here and come back to this review after you've read it. Or, even better, just read both books. They're some of the best science fiction I've read. Ancillary Justice started small, with one person and their quixotic search for revenge, and grew large, to encompass conflicts and confrontations that would shake the Radch. Ancillary Sword returns to a smaller scale and stays there. This means that much of what was left unresolved at the end of the previous book is still unresolved; Leckie does not continue escalating into large-scale conflict. It also means that we see a lot more of Breq making personal choices and trying to work out her own sense of morality, plus semi-adopting a couple more injured people along the way. One of my favorite types of stories is where I get to watch someone who is very good at something do the thing that they're very good at. Breq's unique background and experience makes her a wildcard outsider with vast experience in her new role. (Not to mention the special advantages she has from her implants.) Her long experience with people, similarly from a unique perspective, lets her use her power to effectively navigate political situations while keeping people slightly off-balance. And now she has some real power, made more potent for being somewhat ill-defined. In short, this is a story of political agency, given to someone who hasn't had it before but who is very good at using it. It's immensely satisfying, in part because it's not a simple wish fulfillment. Breq can't just reshape the world to her preferences; in fact, she can't do much about one of the social conflicts she runs into, except treat the people involved with unexpected respect. But she can occasionally do something, and she can always upset existing power structures in subtle ways, and the way Leckie writes this makes it so much fun to read. I think one of the reasons why I enjoyed this so much is that Breq is not relentlessly introspective. She just acts. Usually this sort of book involves lots of soul-searching and analysis, and the lack is refreshing. The other people in the story analyze Breq much more than she analyzes herself, sometimes incorrectly, and Breq finds the whole thing faintly amusing. Not only does this keep the story from bogging down in too much internal drama, it means that Breq frequently surprises the reader, usually in ways that had me grinning. And, despite not mulling things over incessantly, she is growing and developing, finding her own sense of morality and and ethics in a way that's sometimes only apparent in retrospect. The one caveat I will mention is that this is a book that concerns itself a great deal with colonialism and racial slavery, but it's a fantasy of political agency focused on someone who's part of the dominant culture. While it's not quite accurate to say that Breq is this world's equivalent of white, she can pass, and she's Radchaai. I thought the book handles the issues reasonably well, but it is still using oppressed cultures to focus on the agency and power of someone who is, comparatively, privileged. This didn't bother me while I was reading the story, but it started to bother me a little afterwards once it was pointed out. There's nothing inherently wrong with that story, but it's a rather common pattern, and I'm afraid Ancillary Sword doesn't do much to broaden the pattern. That said, it's a caveat rather than a fatal flaw, at least for me. Ancillary Sword is obviously the middle book of a trilogy, and normally the lack of forward progress on the overarching story and the sense of filling in background and setting the scene would undermine the book. But Breq and the other characters in this world are so fascinating that I didn't mind. The ending was not quite what I expected, but worked better the more that I thought about it. I'm really looking forward to the next book. Followed by Ancillary Mercy. Rating: 9 out of 10

These changes to a couple of my scripts were done some time ago, but I never pushed them out or announced them. faq2html, which I use to convert package README files and other documentation to something suitable for the web, no longer tries to parse the document for leading headers when a title is specified with -t. This makes the web page generation for new copyright-format 1.0 LICENSE files a little less awful, although I really need to write an HTML converter specifically for that file format. (That will require me to figure out what a reasonable web conversion of that file format actually is.) You can get the latest version of faq2html from my web tools page. The release script I use to prepare and move around copies of my software releases has been updated to handle Perl distributions that use Build.PL a little better, and to generate xz-compressed tarballs if the upstream build system only generates gzip-compressed tarballs (as Perl's does). I'm moving towards standardizing on xz compression for all of my software releases, although I'll also provide gzip-compressed tarballs for the forseeable future. You can get the latest version of release from my scripts page.

Review: Programming Ruby, by Dave Thomas, et al.

Publisher:	Pragmatic Bookshelf
Copyright:	2005
Printing:	May 2006
ISBN:	0-9745140-5-5
Format:	Trade paperback
Pages:	785

There are a few different editions of this book. The version I read is the second edition, written by Dave Thomas with Chad Fowler and Andy Hunt and published in 2005, covering Ruby 1.8.2. There's now a fourth edition, covering Ruby 1.9 and 2.0, which is probably what you'd want if you were buying this book today. This book, in whatever edition, is called the Pickaxe in the Ruby community after its cover. I've used a lot of different programming languages, so I can usually pick one up on the fly reasonably well, but I still like to read a good introductory book before using one seriously. It's a bit too easy to get lost or to fall into habits that don't match the best practices of the language community without a solid introduction. I've been using a bit of Ruby off and on since I started using Puppet, but I'm looking at doing more serious development using Chef, so I decided it was time to get that introduction. (It helped that I had this book sitting around, although that's also why I read an older edition.) Programming Ruby starts with the obligatory introduction to installing and running Ruby, and then provides a high-level introduction to the language and its basic types just enough to make Ruby comprehensible before starting into the object system. Everything is an object in Ruby, so the book introduces the object system as early as possible, and then shows the rest of the language from constants up in the light of that object system. The rest of part one follows the normal language introduction path, building up from constants and methods to exceptions, modules, and basic IO. It closes with chapters about threads and processes, unit testing, and the debugger. Part two is a grab-bag of one-chapter topics describing how to use Ruby in a particular setting, or showing one angle of the language. The best of those chapters for me was the one on RDoc, partly because I'm quite impressed by Ruby's documentation system. A few of these chapters are oddly in-depth for an introductory book I doubt I'm ever going to use all the details about special irb configuration, and if I do, I'd just look them up but I greatly appreciated the solid chapter on how to write Ruby extensions in C. There is also the obligatory chapter on writing GUI applications with Tk, which always seems to show up in these sorts of introductions and which always baffles me. Does anyone actually do this any more instead of writing a web application? Part three dives back into the language and provides a more complete and formal description. The authors aren't afraid to get into some of the internals, which I appreciated. There is a good chapter here on the details of the type system and how objects and classes interact, and a much-needed extended discussion of duck typing. This type of weak typing and runtime binding is fundamental to how Ruby approaches objects, for better or worse. (I have mixed opinions; it makes some things easier, but I increasingly appreciate strong typing and more formal interface definitions.) Some discussion of marshalling and introspection closes out the discussion portion of the book. That's about 420 pages of the material. The rest of the book is a detailed reference on all of the core classes, and a quicker overview of the standard library. Normally, this sort of thing is thrown into language introductions to pad out the page count, but usually the language's official documentation is better at this sort of reference. But I found Programming Ruby to be an exception. The reference is succinct, sticking to a paragraph or two for each method, and did a great job of providing enough cross-reference and discussion to put each class into a broader perspective. It's the most useful example of this type of reference section I've seen. I still probably won't use it after this initial reading, but I think I got a better feel for the language from reading through it. It's hard to review a book like this without reviewing the language it documents, at least a little bit. I'll indulge: it entertains me how much Ruby is obviously based on Perl, including borrowing some of Perl's more dubious ideas. The global punctuation variables will look familiar to any Perl programmer, and the oddly-named global variables for the interpreter flags are in the same spirit. The language unfortunately has similar problems as Perl with safely running commands without using the shell; it's possible, but not the default and not what the built-ins do. There are places where I wish Ruby were a little less like Perl. The plus side for an experienced Perl programmer is that Ruby feels quite familiar and has made some clear improvements. The ? and ! convention for methods that return booleans or modify objects in-place is brilliant in its simplicity, and something I'd love to see in more languages. And the way Ruby implements ubiquitous code blocks for both iterators and for any temporary objects is lovely once one gets used to it. It's similar to Python's context managers, except more general and built deeper into the language. Returning to the review of the book, rather than the topic, Programming Ruby has a good, clear explanation of blocks, iterators, and yield. If you're interested in getting a grounding in Ruby, this book still feels like a solid introduction. The edition I read is getting a bit long in the tooth now that we're on Ruby 2.1, but the pace of language change has slowed, and most of the book is still applicable. (If you're buying it new, you should, of course, get the later edition.) The table of contents makes it seem like the book is covering the same ground multiple times, but that organizational strategy worked better than I expected. Ruby is not the most organized language in the world, so I still felt a bit overwhelmed with random method names in places, but I never felt lost in the mechanics of the language. In short, recommended if you want a good introduction to the language, although probably in a later edition. Rating: 8 out of 10

Happy New Year everyone! How did you celebrate the year change? I've been at the Seestadt Aspern listening to electric:indigo (who is also part of the open:sounds project powered by artists of the female:pressure collective), watching a show called "Laser-City", enjoying the really chilly air. With so much female power mentioned in the former paragraph, it is almost hard to find a matching artist/band to present you today. Almost I said, because Beth Ditto and her band Gossip are definitely up for the challenge. That woman is pure power and has a uniquely great voice. They are definitely worth listening into closer, and here are my suggestions:

• Standing In The Way Of Control: I guess this is a well known one.
• Pop Goes The World: Also pretty typical for their sound. And no, this has nothing to do with the 80ies classic from Men Without Hats. ;)
• Move In The Right Direction: Guess these lyrics can help people keep their new year's resolutions. :)

Like always, enjoy!

/music permanent link Comments: 0 Flattr this

Review: The Ring of Charon, by Roger MacBride Allen

Series:	Hunted Earth #1
Publisher:	Tor
Copyright:	December 1990
ISBN:	0-8125-3014-4
Format:	Mass market
Pages:	500

Larry Chao is a junior scientist at a gravity research on Pluto, at the very outer limits of human reach in the solar system. The facility is for researching artificial gravity, which is one reason it's in the middle of nowhere. Another is that their experimental generator is built in a ring around Charon, and the close proximity of the two bodies is useful for scientific observation. Unfortunately, there hasn't been much to observe. They can create very short-lived gravity fields in very small areas, but nothing like the artificial gravity that was the original promise of the facility. As a result, the government is shutting the facility down. The authoritarian director, Simon Raphael, is... not exactly happy with that decision, but resigned to it and running the facility to completion with a sullen anger. When Larry makes a startling breakthrough at nearly the last minute for the society, Simon is uninterested and hostile. This leads Larry and his fellow scientist Sondra Berghoff to attempt a more radical demonstration of Larry's success and prove to the rest of the solar system that the facility should be kept open. That decision has a far deeper impact on humanity and the solar system than they could have possibly imagined. The Ring of Charon and its sequel, Shattered Sphere, were recommended to me as good harder science fiction. It took me a while to track down copies in fact, it took an in-person trip to Powell's. Once I found them, a relatively straightforward, old-school science fiction novel seemed like just the thing to read during my commute. Allen delivers there. I'm not spoiling the main plot driver of the book even though it's given away on the back cover, since it's some time in coming in the novel. But The Ring of Charon turns into a multi-viewpoint cross between a disaster novel and a scientific investigation. Larry and Sondra stay central to the plot, of course, but Allen adds a variety of other characters who are attempting to figure out what happened to the solar system and then deal with the consequences: everyone from scientists to pilots to communications officers in weird surrealistic stations. The science is mostly believable, apart from the scientific breakthrough that motivates the plot. Characterization isn't absent completely, but it's simple and unsubtle; dialogue is a bit wooden, characters aren't entirely multidimensional, but Allen does a reasonably good job with both pacing and the sense of mystery and investigation, and a surprisingly good job portraying organizational politics. As you might guess from the tone of my review, this is not the book to reach for if you want something ground-breaking. It's a very conventional, multi-viewpoint SF novel full of scientists and investigation of unknown and possibly hostile phenomena. If you've read much science fiction, you've read books like this before. But one thing that Allen does surprisingly well, which makes The Ring of Charon stand a bit above the pack, is that he doesn't write villains. Even Simon, who goes out of his way to make the reader hate him at the start of the book, becomes a surprisingly sympathetic character. The characters who are usually villains or at least foils in books like this the smooth PR person, the religious man, the blindly-focused scientist who isn't interested in anyone else's theories never turn into caricatures, play important roles in the plot, and turn out to be competent in their fields of expertise. There are actual villains, sort of, but I found myself feeling sympathetic even towards them, at least in places. Allen takes a rather old SF dodge to achieve conflict without an evil enemy, and, because of that, the end of the book felt like a bit of an anticlimax. But I did like the feel of the book where there isn't a good versus evil fight, just a wide variety of people (and others) trying to understand and control the universe in the best ways they know how. I'm not sure I can quite recommend this book. The quality of the writing is not particularly high, and I'm not generally a fan of the disaster novel style of storytelling. But despite not being very original, there's just something likable about it. It moves along reasonably well for a 500 page book, and it's refreshingly light on irritating stereotypes. I think one has to be in the right mood when reading it and set expectations accordingly, but it fit what I was looking for when I picked it up. One warning, though: although The Ring of Charon reaches a climax, the major plot conflict is not resolved at the end of this book, so you may want to have the sequel around. Followed by Shattered Sphere. Rating: 6 out of 10

The combination of GnuPG and a OpenPGP smartcard (such as the YubiKey NEO) has been implemented and working well for around a decade. I recall starting to use it when I received a FSFE Fellowship card long time ago. Sadly there has been some regressions when using them under GNOME recently. I reinstalled my laptop with Debian Jessie (beta2) recently, and now took the time to work through the issue and write down a workaround. To work with GnuPG and smartcards you install GnuPG agent, scdaemon, pscsd and pcsc-tools. On Debian you can do it like this:

apt-get install gnupg-agent scdaemon pcscd pcsc-tools

Use the pcsc_scan command line tool to make sure pcscd recognize the smartcard before continuing, if that doesn t recognize the smartcard nothing beyond this point will work. The next step is to make sure you have the following line in ~/.gnupg/gpg.conf:

use-agent

Logging out and into GNOME should start gpg-agent for you, through the /etc/X11/Xsession.d/90gpg-agent script. In theory, this should be all that is required. However, when you start a terminal and attempt to use the smartcard through GnuPG you would get an error like this:

jas@latte:~$ gpg --card-status
gpg: selecting openpgp failed: unknown command
gpg: OpenPGP card not available: general error
jas@latte:~$

The reason is that the GNOME Keyring hijacks the GnuPG agent s environment variables and effectively replaces gpg-agent with gnome-keyring-daemon which does not support smartcard commands (Debian bug #773304). GnuPG uses the environment variable GPG_AGENT_INFO to find the location of the agent socket, and when the GNOME Keyring is active it will typically look like this:

jas@latte:~$ echo $GPG_AGENT_INFO 
/run/user/1000/keyring/gpg:0:1
jas@latte:~$ 

If you use GnuPG with a smartcard, I recommend to disable GNOME Keyring s GnuPG and SSH agent emulation code. This used to be easy to achieve in older GNOME releases (e.g., the one included in Debian Wheezy), through the gnome-session-properties GUI. Sadly there is no longer any GUI for disabling this functionality (Debian bug #760102). The GNOME Keyring GnuPG/SSH agent replacement functionality is invoked through the XDG autostart mechanism, and the documented way to disable system-wide services for a normal user account is to invoke the following commands.

jas@latte:~$ mkdir ~/.config/autostart
jas@latte:~$ cp /etc/xdg/autostart/gnome-keyring-gpg.desktop ~/.config/autostart/
jas@latte:~$ echo 'Hidden=true' >> ~/.config/autostart/gnome-keyring-gpg.desktop 
jas@latte:~$ cp /etc/xdg/autostart/gnome-keyring-ssh.desktop ~/.config/autostart/
jas@latte:~$ echo 'Hidden=true' >> ~/.config/autostart/gnome-keyring-ssh.desktop 
jas@latte:~$ 

You now need to logout and login again. When you start a terminal, you can look at the GPG_AGENT_INFO environment variable again and everything should be working again.

jas@latte:~$ echo $GPG_AGENT_INFO 
/tmp/gpg-dqR4L7/S.gpg-agent:1890:1
jas@latte:~$ echo $SSH_AUTH_SOCK 
/tmp/gpg-54VfLs/S.gpg-agent.ssh
jas@latte:~$ gpg --card-status
Application ID ...: D2760001240102000060000000420000
...
jas@latte:~$ ssh-add -L
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDFP+UOTZJ+OXydpmbKmdGOVoJJz8se7lMs139T+TNLryk3EEWF+GqbB4VgzxzrGjwAMSjeQkAMb7Sbn+VpbJf1JDPFBHoYJQmg6CX4kFRaGZT6DHbYjgia59WkdkEYTtB7KPkbFWleo/RZT2u3f8eTedrP7dhSX0azN0lDuu/wBrwedzSV+AiPr10rQaCTp1V8sKbhz5ryOXHQW0Gcps6JraRzMW+ooKFX3lPq0pZa7qL9F6sE4sDFvtOdbRJoZS1b88aZrENGx8KSrcMzARq9UBn1plsEG4/3BRv/BgHHaF+d97by52R0VVyIXpLlkdp1Uk4D9cQptgaH4UAyI1vr cardno:006000000042
jas@latte:~$ 

That s it. Resolving this properly involves 1) adding smartcard code to the GNOME Keyring, 2) disabling the GnuPG/SSH replacement code in GNOME Keyring completely, 3) reorder the startup so that gpg-agent supersedes gnome-keyring-daemon instead of vice versa, so that people who installed the gpg-agent really gets it instead of the GNOME default, or 4) something else. I don t have a strong opinion on how to solve this, but 3) sounds like a simple way forward.

The new year is starting with a new release of ctioga2, with a lot of new features, such as:

• patterned fills (shown on the right)
• loops in command files
• a CSS-like styling system (with full XPATH support)
• a backend for mathematical functions of two variables
• the possibility to hide elements that have been drawn before, useful for making animations using output-now for instance
• the possibility to have grid elements spanning two or more columns and/or rows
• many other improvements and bug-fixes

The new release is of course available using rubygems:

~ gem update ctioga2

It can also be downloaded from sourceforge.The possibilities of the new styling system are particularly interesting, and I'm working on ways to make it more powerful, and providing series of default style files that anyone could use as they want. Among other future changes, I want to improve the position of ticks, especially when using non-linear axes, and add functions to draw vector fields (though this still needs some thinking). Enjoy, and a happy new year to everyone !

Having seen the end of December and the beginning of January, this is the time of year where we say "Happy new year!" But this is a very interesting new year: We have also went past our much announced deadline for the <2048 bit keys to be removed from the Debian keyrings. And yes, our highly efficient keyring-maint team managed to deliver on the promised time And, I'd say, with much success. Lets see the numbers Only before that, refer to Jonathan's mail to debian-devel-announce for further, fuller information. So, first of all, how do overall numbers look? Just remember, the following are not the number of DDs, just the number of active keys. That is, the holders to the 252 DD and 35 DM keys we removed are still valid Debian Developers/Maintainers, but have to get a new key accepted to perform many of their tasks in the project. The graph above shows the sharp change between tags 2014.12.31 and 2015.01.01. But my definition of success is that we managed to get the number down to just 252+35=287 from what we had back in August, when we did our DebConf presentation and started the aggressive push: 490 DD keys and 49 DM keys. Since then, 34 DDs requested their retirement, becoming emeritus, and practically all of the rest managed to get their key transition done! So, lets go again easiest-to-hardest. First, the Non-uploading Debian Developers keyring: As this is the newest keyring in existence, and is also the smallest one, we were already without <2048 keys since 2011. Nothing to see, move along. Then, as for the Debian Maintainers: We did have a sensible migration from weaker to stronger keys, but it was not as sharp as I'd have liked. That makes sense, after all, since DMs have less involvement and compromise in the project in regard to DDs. So, we only processed 15 DM keys since August, which is almost a third of the keys we needed to process to reach the ideal 100% migration. Now, as for our biggest and oldest keyring, and the one that denotes more project involvement, here is the graph for the uploading Debian Developers: And yes, here you can see the sharp turn we saw in the second half of this year: By DebConf time, we were happy because the red and yellow lines had just crossed. But we were still sitting at 490 DD keys needing to be migrated. Half of the DD keys (compared to almost a fourth for the DM keys). I'm almost sure we anticipated in our presentation (I know, I should check the video) that, by January 1st, we would have to retire around 300 keys. And I'm very, very happy and proud that we managed to get the number down to 252. And, yes, people leave things to the end: We already have some more pending requests in the Request Tracker to introduce new keys for our fellow friends who were disabled. We will be working to make keyring pushes more frequent than our usual monthly uploads until requests go back to a sane level. So, if everything runs smoothly, this will probably be the last of my posts in this regard. This has been quite an interesting (and exhausting!) experience!

Review: An Imaginary Tale, by Paul J. Nahin

Publisher:	Princeton University
Copyright:	1998, 2007
Printing:	2010
ISBN:	0-691-14600-4
Format:	Trade paperback
Pages:	259

Subtitled The Story of -1, An Imaginary Tale is a history of the use of the number mathematicians normally call i. Nahin starts in the 15th century with the discussion of the time on solving cubic equations, specifically del Ferro's solution to the depressed cubic. He walks through how to approach that solution with imaginary numbers, provides a brief introduction to the complex number plane, and then explains that del Ferro didn't follow the logic in those directions at all. Mathematicians at the time were dubious about negative numbers because they were not intuitive representations of real-world quantities. The square root of negative numbers was considered simply impossible. Nahin continues on in this historical vein for three chapters, walking through the mathematical problems that arose from analysis of cubics and the constant appearance of imaginary numbers, the early attempts to find a geometric interpretation, and then the slow development of the modern conception of imaginary numbers in the 19th century. The emphasis throughout is on the specifics of the math, not on the personalities, although there are a few personal tidbits. Along the way, he takes frequent side journeys to highlight the various places complex numbers are useful in solving otherwise-intractable problems. After that initial history come two chapters of applications of complex numbers: vector analysis, Kepler's laws, applications in electrical engineering, and more. He does win a special place in my heart by walking through the vector analysis problem that George Gamow uses to demonstrate complex numbers in One Two Three... Infinity: a treasure map whose directions depend on landmarks that no longer exist. Following that is a great chapter on deeper mathematical wizardry involving i, including Euler's identity, iⁱ, and a pretty good explanation of hyperbolic functions. The final chapter is an introduction to complex function theory. One's opinion of this book is going to vary a lot depending on what type of history of math you like to read. Unfortunately, it wasn't what I was hoping for. That doesn't make it a bad book other reviewers have recommended it highly, and I think it would be a great book for someone with slightly different interests. But it's a very mathematical book. It's full of proofs, calculations, and analysis, and assumes that you remember a reasonable amount of algebra and calculus to follow along. It's been a long time since I studied math, and while I probably could have traced the links between steps of his proofs and derivations with some effort, I found myself skimming through large chunks of this book. I love histories of mathematics, and even popularizations of bits of it (particularly number theory), but with the emphasis on the popularization. If you're like me and are expecting something more like The Music of the Primes, or even One Two Three... Infinity, be warned that this is less about the people or the concepts and more about the math itself. If you've read books like that and thought they needed more equations, more detail, and more of the actual calculations, this may be exactly what you're looking for. Nahin is fun to read, at least when I wasn't getting lost in steps that are obvious to him. He's quite enthusiastic about the topic and clearly loves being able to show how to take apart a difficult mathematical equation using a novel technique. His joy reminds me of when I was most enjoying my techniques of integration class in college. Even when I started skimming past the details, I liked his excitement. This wasn't what I was looking for, so I can't exactly recommend it, but hopefully this review will help you guess whether you would like it. It's much heavier on the mathematics and lighter on the popularization, and if that's the direction you would have preferred the other similar books I've reviewed to go, this may be worth your attention. Rating: 6 out of 10