DV has been doing some great (and much needed) work to provide a stable API for managing Xen, by building the libvirt library. There are already APIs in C, and Python, but when it comes to system administration I’m really a Perl guy so I knocked up a set of XS bindings (in the Sys::Virt namespace) to allow libvirt to be called from Perl scripts. With DV’s recent 0.1.0 release of libvirt I thought it timely to upload the Perl bindings to CPAN, thus there is now a module Sys-Virt 0.1.0 available. There’s basic API docs, along with a couple of practical examples
On an unrelated note, its been great to be able to buy DVDs in Boston/the US at a fraction the price I’d have paid in London. So I was rather surprised to come across a DVD that actually costs more here – Abbas Kiarostami‘s film 10 comes in at 26.99 USD, vs 8.97 GBP (equiv ~15 USD). Never thought I’d be shipping DVD’s from the UK to the US! Now just got to get around to ordering one of the nice MultiSystem (PAL+NTSC) & MultiRegion Pioneer DVD players so I can watch DVDs on a real TV instead of my laptop…
I’m really rather puzzled by why people consider having non-English blogs on Fedora Planet so troublesome. I’m monitoring perhaps 20 big news / blog aggregator sites through the LiFeRea RSS reader, which makes managing large volumes of news output frankly trivial. Out of easily 100’s of articles that get published every day, I can quickly dismiss 90% just based on the title alone, for 10% I might read the short summary content, and 1% I’ll read in full. Dimissing a story I’m not interested in takes one key press to move to the next new article. So really, the inclusion of a handful of foreign language blogs is line-noise & with unmeasurable impact on the amount of time it takes to process my daily news feeds.
So for someone not interested in reading them, the inclusion of a handful of foreign language blogs is line-noise & with unmeasurable impact on the amount of time it takes to process a daily news feeds. Conversely for people who do want to read them there is a clear benefit from having all Fedora blogs on one aggregator.
If there is anything at all highlighted by the introduction of these new feeds its just how far technology regressed when the world ditched NNTP in favour of the web. The capabilities for organizing, filtering & generally managing news feeds over RSS pale in comparison to the old NNTP news readers – no I’m not talking about the lame Netscape news reader – I’m refering to tools like trn or tin – the mutt of news readers! The focus should be on producing better RSS readers…
I for one welcome our French Fedora bloggers, even though I (shamefully) can’t understand what they’re saying :-)
For a couple of years now I’ve been using a Nikon Coolscan V for scanning my 35mm negatives & slides into digital format. While it is not supported by the open source Sane software, the cross-platform VueScan software does a fanatastic job of driving it, even including support for the ICE (infrared) cleaning. VueScan is the first piece of commercial software I’ve bought in years, and I can say it is well worth the $80 for their professional edition which provides lifetime upgrades. If you’ve got a scanner which isn’t supported by Sane, then its worth checking it out.
This was all well and good, but I’ve got and ever increasing number of medium format negatives & slides taken with my Zero Image 2000 pinhole camera which won’t fit in the Nikon. So I went looking for a medium format scanner and finally settled on the Epson Perfection 4490 which was well rated by a number of photographic magazines, and a snip at only $200 – a small fraction the price of the dedicated Nikon film scanner when I bought it back in London.
Getting it working under Linux was a little bit of a roller-coaster ride. I plugged it in, added its USB vendor & product IDs to hotplug usermaps, re-plugged it, and fired up VueScan. “No scanners found”, damn. Checked the device permissions, fine. Tried Sane instead, “No scanners found”. Odd, because various web postings claimed it worked with both Sane & VueScan. Upgraded to the latest version of VueScan, still nothing. I was mildly worried that I had a dud unit now. I re-checked the release notes for VueScan, where-upon I discovered the small print – its only supported if you have the Epson drivers installed, because it needs a firmware loaded. Fortunately it turns out that Epson are a (reasonably) Linux friendly company, providing a Linux version of their scanner software for a large number of distros. The firmware itself is closed source & proprietry, but they do provide both a Linux version of their scanner software (IScan) and a SANE backend, under the GPL (+ an exception to allow them to deal with the firmware loading library). With this all installed, I now have a choice of 3 programs to do scanning with, Sane, IScan, and VueScan.
The only remaining problem is that if I try to scan at the full 4800 DPI my laptop (with 768 MB of RAM) goes into a swap death spiral, because the combination of the raw RGB scan, the infrared scan and the post-processing requires on the order of 1 GB of memory for a single medium format slide. So I’m stuck at 2400 DPI for while, until I talk myself into shelling out for a new desktop with 4 GB of RAM. That said, this is more than adequate for now – the image below is a scan of one of my first pinhole images from a year & a half ago in London, scaled down from 5000×5000 pixels.
One negative done, 195 to go…I may be some time…
For all my development projects I try to make use of code coverage tools to ensure the test suites are reasonably comprehensive, for example, with Test-AutoBuild I use the excellant Devel-Cover module. The nightly build runs the test suite and publishes a code coverage report giving a breakdown of test coverage for API documentation, functions, statements, and even conditional expressions. The colour coding of coverage makes it possible to quickly identify modules which are lacking coverage and, given knowledge about which modules contain most complexity, limited resources for writing tests can be directed to areas of the code which will have the biggest impact in raising application quality.
When using code coverage, however, one must be careful not to fall into the trap of writing tests simply to increase coverage. There are many aspects of the code which just aren’t worth while testing – for example areas so simple that the time involved writing tests is not offset by a meaingful rise in code quality. More importantly though, is that there is a limit to what source code coverage analysis can tell you about the real world test coverage. It is perfectly feasible to have 100% coverage over a region of code and still have serious bugs. The basic root of the problem is that the system being tested is not operating in isolation. No matter how controlled your test environment is, there are always external variables which can affect your code.
I encountered just such an example last weekend. A few months back I added a comprehensive set of tests for validating the checkout of code modules from Perforce, Subversion, and Mercurial. The code coverage report said: 100% covered. Great I thought, I can finally forget about this bit of code for a while. And then we passed the Daylight Savings Time shift and all the tests started failing. It turned out that the modules were not correctly handling timezone information when parsing dates while DST was in effect. There is no easy way test for this other than to run the same test suite over & over under at least 4 different timezones – UTC (GMT), BST (GMT+1), EST (GMT+5), EDT (EST+1/GMT+6). Just setting $TZ isn’t really enough – to automate reliably I would really need to run the builds on four different geographically dispersed servers (or perhaps 4 Xen instances each running in a different timezones).
A second example, testing that no modules have hardcoded the path separator is simply impossible to test for within a single run of a test suite. Running the test on UNIX may give a pass, and 100% coverage, but this merely tells me which tells me that no module has used ‘\’ or ‘:’ as a path separator. To validate that no module has used ‘/’ as a path separator the only option is to re-run the test suite on Windows. Fortunately virtualization can come to the rescue this time again, in the form of QEMU which allows emulation of an x86 CPU.
Going back to example of checking out code from a SCM server, another problem in Test-AutoBuild (which I must address soon) is ensuring that the different failure conditions in talking to the SCM server are handled. Some of the things which can go wrong include, incorrect host name specified, a network outage causes a connection to break mid-operation, incorrect path for the module to checkout, missing installation of local SCM client tools. 100% test coverage of the code for checking out a module can’t tell you that there is a large chunk of error handling code missing altogether.
In summary, no matter how comprehensive your test suite is, there is always room for improvement. Think about what code is not there – error handling code. Think about what external systems you interact with & the failures scenarios that can occur. Think about what environmental assumptions you might have made – OS path separators. Think about what environmental changes can occurr – time zones. In summary while code coverage is an incredibly valuable tool in identifying what areas of *existing* code are not covered, only use it to help priortise ongoing development of a test suite, not as an end goal. There really is no substitute for running the tests under as many different environments as you can lay your hands on. And not having access to a large server farm is no longer an excuse – virtualization (take your pick of Xen, QEMU, UML, and VMWare) will allow a single server to simulate dozens of different environments. The only limit to testing is your imagination….
Novell recently cranked up their marketing machine for AppArmour, claiming its technical design provides for greater ease of administration, development & customization than found with SELinux. While AppArmour FAQ admits that SELinux’s model of file security labels is superior to their own path based control, it makes the dubious assertion that a labelled security model is harder to administer. While it is true that the tools for SELinux did not previously provide an easy way to change the specs for file labels, as I previously discussed the introduction of the semanage tool in Fedora Core 5 has changed all that. It is now trival to update file security label definitions. So at this time any problem with SELinux is not one of design or implementation, but rather documentation & awareness of the progress made in SELinux development over the past 2 years or so. To that end here are a selection of useful documentation resources