For some time I ve been wondering how the wire size for power supplies limits the power. So I ve done some quick calculations to determine if it s a problem. The first type that is of interest are the Inverters that are used to convert 12VDC to 240VAC (mains power) to allow electric devices to be operated in a car. I ve seen some reports from dissatisfied user about Inverters not supplying as much power as expected and I ve had problems with my 150W Inverter not always supplying my Thinkpad (which definitely doesn t draw 150W). The second type is phone chargers as charging a phone in a reasonable amount of time is always a problem. Inverter Rating Fine Print vs Laptop PSU My Thinkpad Power Supply claims Efficiency Level IV which according to the US EPA document describing the efficiency marking protocol for external power supplies [1] means that it is at least 85% efficient when supplying 50W+. The peak output of the PSU is 4.5A at 20V which is 90W peak output, 90/0.85 == 106W power drawn. One would hope that wouldn t be a problem from a 150W PSU. But the fine print on the PSU says that it can provide 110W continuously and 150W for 10 minutes. So according to my calculations I m within 4W of overloading the PSU if my Thinkpad uses full power. It also says that it is designed for 13.8V input. I have no idea how the performance of the Inverter changes as the supply Voltage changes between the 12.6V that a 6 cell lead-acid battery is designed to provide and the 13.8V charge from the car alternator. But I have had occasions when my Inverter stopped working correctly presumably due to being unable to supply as much current as my Thinkpad draws. As an aside I measured the Voltage in my car (with the engine off) at 12.85V from the cigarette lighter socket and 13.02V directly from the battery. I wonder if there is some sort of overload protection on the cigarette lighter which has a side effect of reducing the Voltage. Resistance in wires reduces the Voltage, but all Voltage meters are designed to have a high resistance to prevent that from being an issue. If anyone has an explanation for the 0.17Volt drop then please write a comment! Can a Car Provide 130W from the Cigarette Lighter socket? If the Inverter is also 85% efficient (and it might be less as it has no indication of efficiency on the box) then when supplying 110W it would draw 110/0.85 == 129.4W (I ll round it up to 130W). The power in Watts is equal to the Voltage multiplied by the current in Amps (W=V*I). Therefore I=W/V so if the car battery was at 12.85V then 130W/12.85V == 10.12A will flow. The current that goes through a circuit is equal to the Voltage divided by the resistance (see the Wikipedia page on Ohm s law for more information). This also means that the resistance equals the Voltage divided by the current. 12.85V/10.12A == 1.27 Ohms. Note that this is the resistance of the entire circuit, all the wires going to the battery, the circuitry inside the Inverter, and the internal resistance of the battery. The Inverter s cable is 1M long (2 meters of wire) and each wire is about 3.5mm in diameter including the insulation which means that the copper wire is probably equivalent to a single core conductor that is about 1mm in diameter. According to one of the online guides to resistance [2] wire that is 1.02mm in diameter will have a resistance of 0.02 Ohms per meter which gives a resistance of 0.04 Ohms. 0.04 Ohms is 3% of the total resistance of the circuit which doesn t seem like it will be a real problem. In practice I ve noticed that the connector gets extremely hot when it s in use while the cable doesn t get warm enough to notice. I suspect that the quality of the connector limits the power that is available but I don t have an easy way of measuring this. Inverters that are rated at 300W are designed to attach directly to the battery. An Inverter that is rated at 300W would draw 300W/0.85 == 352W from the battery. That needs 352W/13.02V == 27.04A and therefore a circuit resistance of 13.02V/27.04A == 0.48 Ohms total resistance. I wonder whether dirt on the battery terminals would give a significant portion of that. Phone Charging I ve also been wondering about why mobile phones take so long to charge, and now I ve finally done the calculations. The latest standard for mobile phones is to use USB for charging. The Wikipedia page about USB says that the standard is for USB 2.0 to supply up to 500mA at 5V +-5%. That means 0.5A*5V == 2.5W +- 5%. If we assume that the internal power supply in a phone is also 85% efficient then that means 2.5*0.85 == 2.125W going to the battery. My Samsung Galaxy S3 has a battery which is rated at 7.98Wh. According to the Wikipedia page about Lithium Ion batteries the charge/discharge efficiency is 80% to 90% I ll assume that it s 85% for further calculations. If the battery in the phone is 85% efficient and the phone is doing nothing but charging then the charge time for a regular USB port would be 7.98Wh/0.85/2.125W == 4.42 hours (4 hours 25 minutes) of charge time. That probably means something closer to 5 hours to totally charge the phone while it s running. There are dedicated charging ports for USB which can supply up to 1.5A. The 3rd party charger which came with my phone was rated at 1A and would hopefully be capable of completely charging the phone in less than 3 hours (but in practice isn t). It s interesting to note that MacBooks expose the amount of current drawn from a USB port with a GUI, so it should be possible to measure a phone charge rate by connecting it to a MacBook (which is cheaper than cutting up a phone cable). My old Samsung Galaxy S has a battery which is rated at 5.55Wh, by the same calculations it would take slightly more than 3 hours to charge on a standard USB port or 1.5 hours on my newest USB charger. In practice it has never got anywhere close to that, I presume that the phone is designed to draw less than 500mA. Phone Cable Resistance The charger that came with my Galaxy S has a cable that is about 1.75M long, the cable is flat and measures just over 1mm thick and about 2mm wide. Presumably the wire is equivalent to a single core that s about 0.4mm in diameter thus giving it a resistance of about 0.134 Ohm per meter, or 1.75*2*0.134 == 0.469 Ohm for the cable. The charger is rated at 0.7A. To supply 0.7A at 5V the resistance would be 5V/0.7A == 7.143 Ohm so about 6.6% of the total resistance of the circuit would be in the wire from the charger to the phone. The charger that came with my Galaxy S3 has a round cable that s just over 3mm thick and about 90cm long. If each wire in the cable is equivalent to a solid wire that is 0.912mm in diameter then it would be 0.0264 Ohm per meter of wire or 0.9*2*0.0264 == 0.0475 Ohm. The total circuit resistance would be 5V/1A == 5 Ohm. So 0.0475 Ohm is less than 1% of the circuit resistance. Voltage Drop The Voltage across a part of a circuit is proportional to the resistance (see the Wikipedia page on Series and Parallel Circuits for a good explanation). Basically this means that if 1% of the resistance of a circuit is in the wire then 1% of the Voltage drop will also be in the wire, so if we have a 5V supply with my Galaxy S3 cable then each of the two wires in the cable will have a difference of about 0.025V between the ends and the phone will receive a supply of 4.95V, the difference isn t something that is worth worrying about. But the cable from my Galaxy S has a resistance equivalent to 6.6% of the circuit resistance which means that the theoretical charge time will be 6% longer than it might be or 6% more current will be drawn from the mains than should be needed. Conclusion The charger that came with my Samsung Galaxy S isn t much good. Wasting 6.6% of the power in the wire is unreasonable. Phones keep getting more power hungry and batteries keep getting larger. There are third party phone batteries and external batteries that are charged by USB which have more than twice the capacity of the stock phone batteries this means more than twice the charge time. This problem will keep getting worse. The problem of a phone in active use drawing more power than the charger can provide (and running out of battery while on the charger) seems likely to stay with us. So while an Android phone has the potential to be a great little embedded server it seems that hacking the power supply is going to be a required first step for realising that potential. The decision to make 5V the USB power standard was reasonable at the time as it was the voltage used for most things on the motherboard. The decision to use USB as the phone charging standard was also reasonable, it allows phones to be charged anywhere. The combination of those two decisions isn t good for the user. If a higher Voltage such as 12V was used then 5* the power could be supplied through the same wires at the same level of efficiency. It would be really good if cars came with built in Inverters and supplied 240VAC or 110VAC depending on the region they were manufactured for. It s becoming a fairly common feature to have a cigarette lighter port in the car boot as well as at least two ports inside the car. When a car has three sockets and only one device to actually light cigarettes (which I suspect is only provided to fill an empty socket) it s very obvious that people want to connect random devices. Also having USB charging ports inside the car would be a really good idea (one for each seat would be good for Ingress).

• [1] http://tinyurl.com/cd6jpcv
• [2] http://www.daycounter.com/Calculators/AWG.phtml

I did not realize how much I was missing this sort of heads-down programming time in my life until the last two days. I think the last time that I had this much fun with my job was when I was learning Java, and even that wasn't quite this much fun since it was a lot of experimentation rather than being directly productive in a language I know well. Here's a short list of modern Perl, Perl techniques, and interesting modules that I'd not had a reason to use before today:

• Profiling and Devel::NYTProf. What a lovely piece of software. I'm starting to like this trend towards useful developer tools dumping their output in HTML, particularly when many of them are this pretty. (Devel::Cover by way of Test::Strict also does this, and I've been making heavy use of it.)
• Memoize. I've known it existed for years, but I've never had a reason to use it. Memoizing str2time when doing log parsing cut the time by a quarter. (I'll probably write a hand-rolled date parser for the specific date format eventually, since str2time is really slow since it's so general, but wrapping Memoize around it takes five seconds.)
• Module::Build. I was staying away from this because of all the problems Debian had with embedded code copies, but it appears to not be doing that any more (or at least I can use it in a way that it doesn't). And it really is so much nicer than ExtUtils::MakeMaker. I will probably convert all of my packages over time, although I have to see what it's like for XS modules. ETA 2013-01-24: Gregor pointed out that I was confusing Module::Build with Module::Install. I feel silly now; I've been avoiding Module::Build solely because I've been confusing it with something else entirely!
• HTTP::BrowserDetect. This isn't a general piece of software, of course, but once again it was lovely to discover that CPAN already contained exactly the piece of software that I needed. I'm trying to produce a summary of what browsers our authenticated users use as part of a general software inventory, and this turned the nonsense that browsers send into exactly the sort of management-consumable classifications I needed.
• IO::Compress and IO::Uncompress. Yes, this is much nicer than what I used to have to do with Compress::Zlib. It's like people kept working on Perl while I've been using all the things I learned five years ago!

I still have tomorrow morning to continue focusing on this and will hopefully finish up the work to feed long time periods of logs into my analysis tool. And, even better, I have a log parsing framework that I really like and that I think will make any number of things easier in the long run. (Also, it has a remarkably thorough test suite. I love test-driven development. Although I haven't written comprehensive tests for the very final front-end piece, since generating sanitized log input to trigger all the cases is too much effort right at the moment.)

If anyone s in the area, there will be a Debian BSP this weekend at SIPB s MIT office. Hope to see everyone there! Check out details @ http://sipb.mit.edu/iap/#7

With the arrival earlier today of the stochvol package onto the CRAN network for R, our Rcpp project reached a new milestone: 100 packages have either a Depends:, Imports: or LinkingTo: statement on it. The full list will always be at the bottom of the CRAN page for Rcpp; I also manually edit a list on my Rcpp page. But for the record as of today, here is the current list as produced by a little helper script I keep:

 acer                apcluster           auteur             
 bcp                 bfa                 bfp                
 bifactorial         blockcluster        ccaPP              
 cda                 classify            clusteval          
 ConConPiWiFun       EpiContactTrace     fastGHQuad         
 fdaMixed            forecast            fugeR              
 GeneticTools        gMWT                gof                
 gRbase              gRim                growcurves         
 GUTS                jaatha              KernSmoothIRT      
 LaF                 maxent              mets               
 minqa               mirt                mRMRe              
 multmod             mvabund             MVB                
 NetworkAnalysis     ngspatial           oem                
 openair             orQA                parser             
 pbdBASE             pbdDMAT             phom               
 phylobase           planar              psgp               
 quadrupen           Rchemcpp            Rclusterpp         
 RcppArmadillo       RcppBDT             rcppbugs           
 RcppClassic         RcppClassicExamples RcppCNPy           
 RcppDE              RcppEigen           RcppExamples       
 RcppGSL             RcppOctave          RcppRoll           
 RcppSMC             RcppXts             rforensicbatwing   
 rgam                RInside             Rmalschains        
 Rmixmod             robustgam           robustHD           
 rococo              RProtoBuf           RQuantLib          
 RSNNS               RSofia              rugarch            
 RVowpalWabbit       SBSA                sdcMicro           
 sdcTable            simFrame            spacodiR           
 sparseHessianFD     sparseLTSEigen      SpatialTools       
 stochvol            surveillance        survSNP            
 termstrc            tmg                 transmission       
 trustOptim          unmarked            VIM                
 waffect             WideLM              wordcloud          
 zic                

And not to be forgotten is BioConductor which has another 10:

 ddgraph            GeneNetworkBuilder GOSemSim          
 GRENITS            mosaics            mzR               
 pcaMethods         Rdisop             Risa              
 rTANDEM  

As developers of Rcpp, we are both proud and also a little humbled. The packages using Rcpp span everything from bringing new libraries to R, to implementing faster ways of doing things we have before to doing completely new things. It is an exciting time to be using R, and to be connecting R to C++, especially with so many exciting things happening in C++ right now. Follow the Rcpp links for more, and come join us on the Rcpp-devel mailing list to discuss and learn.

Weblate 1.4 has been released today. It comes with lot of improvements, especially in configurability, admin interface and usability. Full list of changes for 1.4:

• Fixed deleting of checks/comments on unit deletion.
• Added option to disable automatic propagation of translations.
• Added option to subscribe for merge failures.
• Correctly import on projects which needs custom ttkit loader.
• Added sitemaps to allow easier access by crawlers.
• Provide direct links to string in notification emails or feeds.
• Various improvements to admin interface.
• Provide hints for production setup in admin interface.
• Added per language widgets and engage page.
• Improved translation locking handling.
• Show code snippets for widgets in more variants.
• Indicate failing checks or fuzzy strings in progressbars.
• More options for formatting commit message.
• Fixed error handling with machine translation services.
• Improved automatic translation locking behaviour.
• Support for showing changes from previous source string.
• Added support for substring search.
• Various quality checks improvements.
• Support for per project ACL.
• Basic unit tests coverage.

You can find more information about Weblate on it's website, the code is hosted on Github. If you are curious how it looks, you can try it out on demo server. You can login there with demo account using demo password or register your own user. Ready to run appliances will be soon available in SUSE Studio Gallery. Weblate is also being used https://l10n.cihar.com/ as official translating service for phpMyAdmin, Gammu, Weblate itself and others. If you are free software project which would like to use Weblate, I'm happy to help you with set up or even host Weblate for you (this will be decided case by case as my hosting space is limited).

Filed under: English Phpmyadmin Suse Weblate 0 comments Flattr this!

Shogun Toolbox Days 2013 - Give Your Data a Treat Dear all, save the date - July 12, 2013! we just received confirmation from the c-base crew [1], [2] - the first shogun machine learning toolbox workshop will take place at c-base this Summer July 12 in Berlin! Anyone interested in participating / this event / or interested in helping to organize it - please talk to us on IRC or post on the mailinglist...

Debian meeting system. I'm updating the AppEngine application to handle enquete related parts. Hopefully my changes will improve response rates.

Redirecting stdout and stderr to the same file or file descriptor with &> is common and nice, except that it is not required to be supported by POSIX:2001. Moreover, trying to use it with shells not supporting it will do exactly the opposite:

1. The command's output (to stdout and stderr) won't be redirected anywhere.
   
2. The command will be executed in the background.
   
3. The file will be truncated, if redirecting to a file and not using >>.
   

Are the characters saved worth those effects? I don't think so. Just use this instead: "> file 2>&1". Make sure you get the first redirection right, "&> file 2>&1" isn't going to do the trick.

I have a problem I have to solve for work that involves correlating Apache access and error logs. Part of WebAuth logs successful authentications to the Apache error log, and I want to correlate User-Agent strings with users so that we can figure out what devices our users are using by percentage of users rather than percentage of hits. The problem, as those who have tried to do this prior to Apache 2.4 know, is that Apache doesn't provide any easy way to correlate access and error log entries (made even more complex because two separate components are involved). I could have just hacked something together, but I've written way too many ad hoc log parsers, and, see, I was reading this book.... The book in question is Mark Jason Dominus's Higher Order Perl. I'm not quite done with it, and will post a full review when I am. I have some problems with it, mostly around the author's choice of example problems. But there is one chapter on infinite streams, and the moment I read that chapter on the train, it struck me as the perfect solution to log parsing problems. I'm not much of a functional programming person (which is where Dominus is drawing most of the material for this book), so I don't know if this terminology is standard or somewhat unique to the book. An infinite stream in this context is basically a variation on an interator that lets you look at the next item without consuming it. The power comes from putting this modified iterator in front of a generator and use it to consume one element at a time, and then compose this with transformation and filtering functions. That gives you all the power of the iterator to store state and lets you process one logical element from the stream at a time, without inverting your flow of control. Dominus provides code in the book for a very nice functional implementation of this that's about as close as you're probably going to get to writing Haskell in Perl. Unfortunately, his publisher decided to write their own free software license, so the license is kind of weird and doesn't explicitly permit redistribution of modified code. It's probably fine, but I didn't feel like dealing with it, and I'm more comfortable with writing object-oriented code at the moment (at least in Perl), so I decided to write an object-oriented version of the same code specific for log parsing. That's what I've been doing since shortly after lunch, and I can't remember the last time I've had this much fun writing code. I have a reasonable first cut at a (fully tested and fully test-driven) log parsing framework built on top of a reasonably generic implementation of the core ideas behind infinite streams. I also used this as an opportunity to experiment with Module::Build, and have discovered that the things I most disliked about it have apparently all been fixed. And I'm also using Perl 5.10 features. (I was tempted to start using some things from 5.12, but I do actually need to run this on Debian stable.) It's rather satisfying to write a thoroughly modern Perl module. There are some definite drawbacks to writing this in an object-oriented fashion. There's rather more machinery and glue that has to be set up, it's probably a bit slower, and it tends to accumulate layers of calls. One of the advantages of the method with standalone functions and a very simple, transparent data structure is that it's easier to eliminate unnecessary call nesting. But I suspect the object-oriented version will do what I want without any difficulties, and if I feel very inspired, I can always fiddle with it later. Maybe I'll eventually use this as a project to experiment with Moose as well. I'm surprised that no one else has done this, but I poked around on CPAN a fair bit and couldn't find anything. This will all show up on CPAN (as Log::Stream) as soon as I've finished enough of it to implement my sample application. And then I'll hopefully find some time to rewrite our metrics system using it, which should simplify it considerably....

ITWire ran a story on the 12th of January entitled "Fedora still has problems with secure boot". It ends up discussing two issues with the author's experience with the Fedora installer - that he can't reclaim any free space on existing drives, and that the installer didn't automatically add entries for Windows to the grub menu. These are certainly legitimate issues, and I don't want to suggest that it's reasonable for people to have to manually alter their configuration in order to support dual boot. But they're not issues with Fedora's support for secure boot, despite the enthusiasm with which certain people have jumped on the story. We've received one credible report of a secure boot related problem with Fedora on a couple of Toshiba laptops, which appears (and I want to stress that we're still working on diagnosing it) to be a firmware bug rather than any kind of problem with Fedora.

Mistakes happen in journalism, and sometimes there are differences of opinion. But this story is simply wrong. When asked about it in the comments, the author failed to support his position. When contacted, the editor in chief was willing to add a note saying that I disputed the arguments but was unwilling to remove the incorrect claims. As a result, the internet remains full of links and reposts of an article that unashamedly tells users that the current Linux distribution with the best UEFI hardware support has issues with something it has no issues with.

For reasons that are unclear to me, ITWire seems to have some sort of well regarded status in the Australian technical industry. It seems entirely undeserved.

comments

Recently I recieved a MyAudio Tablet Series9 as a gift. From the factory it runs some version of Android, but I already got enough Android devices. Instead I wanted to play a bit with a basic Linux install. This tablet is based on the AllWinner A10 System on a Chip. Some of these instructions might work for other systems based on the same chip set: Step 1: Install the rescue system from http://forum.doozan.com/read.php?6,9396 on a SD-card. You can configure network settings in rescue/interfaces and rescue/wpa_supplicant.conf. Step 2: Boot the rescue system. The MyAudio table will boot from the SD-card if it contains a bootable system, so this is quite easy. The first time you boot the rescue system tries to locate a system.bin file from the tablet. this file contains the hardware configuration and is needed for initializing all the hardware. This means that the screen can t be initialized the first time you boot and will just appear off. Unless the system automatically boots again you need to locate the system.bin yourself from the tablet. It is usually located on /dev/nanda and have names like system.bin, script.bin, or evb.bin. To find the file you can use the log the rescue system places in log/deviceinfo.log on the SD-card during boot. You should now have console access to the tablet and using a USB keyboard you should be able to work in the console. Step 3: Setting up the network Having configured rescue/interfaces and rescue/wpa_supplicant.conf the network ought to work. I am experiencing some problems getting it to connect to my Access Point (using WPA2). Patience works, but you might need to monitor the status with wpa_cli(8) and then run udhcp -i wlan0 when it succeeds. Step 4: Install Debian using the installer at http://forum.doozan.com/read.php?6,8906 This just worked fine Step 5: Getting the touch screen to work. The system.bin file can be decoded with the fexc utility either available on the rescue system (compiled for arm) of from https://github.com/linux-sunxi/sunxi-tools. Finding the ctp_para section we can see that this tablet uses a ft5x touch screen. Adding ft5x_ts to /etc/modules on our installed system will make sure that the correct kernel module gets loaded on boot time. But for some reason the kernel driver and the X11 evdev driver will not talk together. So we need to compile our own kernel patched as described on https://www.miniand.com/forums/forums/development/topics/how-do-i-get-the-lcd-display-and-touch-screen-working-on-an-a10-tablet#post-1225. I have made kernel packages for Debian available at http://hacking.dk/files/linux-image-3.0.57-sun4i+_1.0+nomultitouch_armhf.deb or http://hacking.dk/files/linux-image-3.4.24-sun4i+_1.0+nomultitouch_armhf.deb. Install the kernel package you want and run this as root:

# KERNEL_VERSION=3.4.24-sun4i+
# /usr/bin/mkimage -A arm -O linux -T kernel  -C none -a 0x40008000 -e 0x40008000 -n Linux-$KERNEL_VERSION -d /boot/vmlinuz-$KERNEL_VERSION /boot/uImage
# /usr/bin/mkimage -A arm -O linux -T ramdisk -C gzip -a 0x00000000 -e 0x00000000 -n initramfs-$KERNEL_VERSION -d /boot/initrd.img-$KERNEL_VERSION /boot/uInitrd

After a reboot X11 will respond to the touch screen, but Step 6: Configure the touch screen the pointer does not point where I touch the screen. The transformation between the points are wrong. This is fixed by adding this to your xorg.conf:

Section "InputClass"
    Identifier     "touchscreen"
    MatchProduct   "ft5x_ts"
    Option    "TransformationMatrix" "0 1 0 1 0 0 0 0 1"
    Option    "Calibration" "0 768 0 1024"
EndSection

or more dynamically by running:

$ xinput set-prop ft5x_ts "Coordinate Transformation Matrix" 0 1 0 1 0 0 0 0 1
$ xinput set-prop ft5x_ts "Evdev Axis Calibration" 0 768 0 1024

For more information about the Transformation Matrix, see the X.Org Wiki Step 7: Install a on-screen keyboard. I have not found the perfect keyboard application yet. Currently I am using matchbox-keyboard

I want to like LDAP. Every so often I do interesting things with it, and I start to think I like it, then some software that claims to support LDAP fails to do so properly and I remember I hate it again. I guess the problem with LDAP is that most people are scared by it, unless you reach a certain level of scale you don't need it. That makes installing it out of the blue a scary prospect, and that means that lots of toy-software applications don't even consider using it until they're mature and large. When you bolt-on support for LDAP to an existing project you have to make compromises; do you create local entries in your system for these scary-remote-LDAP-users? Do you map group members from LDAP into your own group system? ANd so on. To be fair to the application developers if the requirements for installation were "Install LDAP" they'd probably have a damn smaller userbase, and so we cannot blame OpenLDAP, or the other servers. All the same it is a shame. The very next piece of software I ever write that needs to handle logins will use LDAP and only LDAP. How hard can it be? In happier news I re-deployed http://www.debian-administration.org/ over the weekend. It now uses the Bytemark BigV platform which rocks. The migration was supposed to be a "Christmas Project", but took longer than expected due to the number of changes I need to make to the software, and my deployment plan. Still I'm very happy with the way things are running now, and don't expect I'll need to move or make significant changes for the next nine years. I just hope there is still interest in such things then. ObQuote: "Would you like a treatment? " - Dollhouse

Last year whilst shopping for a birthday present for my dad, I took a chance on some ex-display headphones that were on sale at my local Richer Sounds. Up until then the best pair of 'phones I owned were some AKG-512 closed headphones. Otherwise I used a parade of low-end Sennheiser or Sony in-ear buds for listening on the move. The AKGs were a slight upgrade on the in-ear buds, but not much. They were noticeably bassier. Whether that was an improvement or not was up for debate. The Sennheiser HD438s are quite an upgrade on the AKGs. It's the biggest improvement I've ever heard when listening to my music. It's the first time I've ever noticed a significant improvement using different headphones, confirming that my ears are good enough to benefit from better equipment. Until then I simply wasn't sure. This goes to show that my existing equipment is not that great. No surprises there, but my lifestyle at the moment doesn't really have any room in it for anything better. I'm also glad I've amassed a nice music collection and discovered so much that I enjoy listening to before investing in the equipment with which to listen: I've heard new things in all my old favourites these these 'phones. Perhaps I will with a future upgrade, too.

I just read this excellent blog post called "Linux Future" which defines a term "FLOS" to describe what the current direction of Linux development appears to be. Specifically, it addresses the divergence from what one might call the "UNIX" philosophy in new core technologies like systemd. I think sticking a new name to define this philosophical direction is a great idea. "FLOS" is something that both proponents and haters can rally around. It acknowledges the move away from the UNIX way of doing things, and doesn't overload a term like Linux, "ownership" of which is claimed by both camps (and others who just want to keep their heads down and get on with things!) The next step, after embracing it, would be to define the strategy and the roadmap. Where is FLOS going? What's the endgame? Perhaps with such a vision we may end up with some technologies which will stand the test of time, like Apple's CoreAudio (10 years old) or Microsoft's win32 API (now 20 years old), rather than the ludicrously high plumbing turnover we endure right now. (Oh my goodness, I finally wrote an actual Linux blog post.)

GNOME 3.4 for Debian wheezy is shaping up quite well. A handful of bugs remain to be fixed, but we are now in a polishing phase, as expected given the freeze status. With upstream introducing heavy changes in new versions, it is time to think of what will happen with GNOME when we introduce version 3.8 in unstable. Namely, there are two categories of changes that have a heavy impact on Debian:

• several components now heavily relying on systemd for components that interact with low-level parts of the system,
• the fallback code (a.k.a GNOME Classic ) being removed, causing problems for people without 3D support for x86 this shouldn t be a problem thanks to llvmpipe, but i386 and amd64 are not the only architectures we want to support.

Upstream is not hostile to people working on making their modules compatible with these setups (non-3D, non-systemd). However, there is a limit to what the Debian GNOME team can do, and people have to make choices. The consensus in the Debian GNOME team is to focus the extra amount of work we can provide to the fallback code. We are already in touch with other distributions and people who are interested in keeping the differences with upstream GNOME minimal. Our common goal is to be able to provide a GNOME installation for all Linux systems, with or without 3D. However, none of us is willing to spend time on getting GNOME to work without systemd. We will not work actively against it either, but some components will certainly recommend systemd, and the functionality with other init systems will be degraded. So if people want to keep GNOME fully working on non-Linux systems, now is the time to start hacking on the missing pieces for this to work. For the time being, it does not look infeasible although we don t know what jessie will be made of.

In this article, I'm going to explain you how you can extend Swift, the OpenStack Object Storage project, so it performs extra action on files at upload or at download time. We're going to build an anti-virus filter inside Swift. The goal is to refuse uploaded data if they contain a virus. To help us with virus analyses, we'll use ClamAV. WSGI, paste and middleware To do our content analysis, the best place to hook in the Swift architecture is at the beginning of every request, on swift-proxy, before the file is actually stored on the cluster. Swift proxy uses, like many other OpenStack projects, paste to build his HTTP architecture. Paste uses WSGI and provides an architecture based on a pipeline. The pipeline is composed of a succession of middleware, ending with one application. Each middleware has the chance to look at the request or at the response, can modify it, and then pass it to the following middleware. The latest component of the pipeline is the real application, and in this case, the Swift proxy server. If you've already deployed Swift, you encountered a default pipeline in the swift-proxy.conf configuration file:
This is a really basic pipeline with a few middleware. The first one catches error, the second one is in charge to return 200 OK response if you send a GET /healthcheck request on your proxy server. The third one is in charge of caching, the fourth one is used for rate limiting, the fifth for authentication, the sixth one for logging, and the final one is the actual proxy server, in charge of proxying the request to the account, container, or object servers (the others components of Swift). Of course, we could remove or add any of the middleware here at our convenience. Be aware that the order matters: for example, if you put healthcheck after tempauth, you won't be able to access the /healthcheck URL without being authenticated! ClamAV If you don't know ClamAV, it's an antivirus engine designed for detecting trojans, viruses, malware and other malicious threats. Wwe're going to use it to scan every incoming file. To build the middleware, we'll use the Python binding pyclamd. The API is quite simple, see:
Anatomy of a WSGI middleware Your WSGI middleware should consist of a callable object. Usually this is done with a class implementing the __call__ method. Here's a basic boilerplate:
I'm not going to expand more on why this is built this way, but if you want to have more info on this kind of filter middleware, you can read their documentation on Paste. This middleware will just do nothing as it is. It's going to simply pass all requests it receives to the final application, and returns the result. Testing our basic middleware Now is a really good time to add unit tests. I hope you didn't think we were going to write code without some tests, right? It's really easy to test a middleware, as we're going to use WebOb for that.
We create a FakeApp class, that represents a fake WSGI application. You could also use a real application, or write a fake application looking like the one you want to test. It'll require more time, but your tests will be closer to the reality. Here we write the simplest test we can for our middleware. We're just sending a GET / request to it, so it passes the request to the final application and returns the result. It is transparent, it does nothing. Now, with that solid base we'll able to add more features and test these features incrementally. Plugging ClamAV in With our base ready, we can start thinking about how to plug ClamAV in. What we want to check here, is the content of the file when it's uploaded. If we refer to the OpenStack object storage API , a file upload is done via a PUT request, so we're going to limit the check to that kind of requests. Obviously, more checks could be added, but we'll keep things simple here for the sake of comprehensibility. With WSGI, the content of the request is available in env['wsgi.input'] as an object implementing a file interface. We'll scan that stream with ClamAV to check for viruses.
That's it. We only check for PUT requests and if there's a virus in the file, we return a 403 Forbidden error with the name of the detected virus, bypassing entirely the rest of the middleware chain and the application handling. Then, we can simply test it.
The first test test_put_empty simulates an empty PUT request. The second one, test_put_no_virus simulates a regular PUT request but with a simple file containing no virus. Finally, the third and last test simulates the upload of a virus using the EICAR test file. This is a special test file that is recognized as a virus, even if it's not real one. Very handy for testing virus detection software! Configuring Swift proxy Our middleware is ready! We can configure Swift's proxy server to use it. We need to add the following lines to our swift-proxy.conf to teach it how to load the filter:
We'll assume that our Python modules is named swiftclamava here. Now that we've defined our filter and how to load it, we can use it in our pipeline:
Just before reaching the proxy-server, and after the user being authenticated, the content will be scanned for viruses. It's important here to put this after authentication for example, because otherwise we may scan content that will get rejected by the authtemp module, thus scanning for nothing! Beyond scanning And voil , we now have a simple middleware testing uploaded content and refusing infected files. We could enhance it with various other things, like configuration handling, but I'll let that as an exercise for the interested readers. We didn't exploited it here, but note that you can also manipulate request headers and modify them if needed. For example, we could have added a header X-Object-Meta-Scanned-By: ClamAV to indicates that the file has been scanned by ClamAV. You should now be able to build your own middleware doing whatever you want with uploaded data. Happy hacking!

Review: Fantasy & Science Fiction, March/April 2011

Editor:	Gordon van Gelder
Issue:	Volume 120, No. 3 & 4
ISSN:	1095-8258
Pages:	258

Charles de Lint's book review column sticks with the sorts of things he normally reviews: urban and contemporary fantasy and young adult. Predictably, I didn't find that much of interest. But I was happy to see that not all the reviews were positive, and he talked some about how a few books didn't work. I do prefer seeing a mix of positive and negative (or at least critical) reviews. James Sallis's review column focuses entirely on Henry Kuttner and C.L. Moore (by way of reviewing a collection). I'm always happy to see this sort of review. But between that and de Lint's normal subject matter, this issue of F&SF was left without any current science fiction reviews, which was disappointing. Lucius Shepard's movie review column features stunning amounts of whining, even by Shepard's standards. The topic du jour is how indie films aren't indie enough, mixed with large amounts of cane-shaking and decrying of all popular art. I find it entertaining that the F&SF film review column regularly contains exactly the sort of analysis that one expects from literary gatekeepers who are reviewing science fiction and fantasy. Perhaps David Langford should consider adding an "As We See Others" feature to Ansible cataloging the things genre fiction fans say about popular movies. "Scatter My Ashes" by Albert E. Cowdrey: The protagonist of this story is an itinerant author who has been contracted to write a family history (for $100K, which I suspect is a bit of tongue-in-cheek wish fulfillment) and has promptly tumbled into bed with his employer. But he is somewhat serious about the writing as well, and is poking around in family archives and asking relatives about past details. There is a murder (maybe) in the family history, not to mention some supernatural connections. Those familiar with Cowdrey's writing will recognize the mix of historical drama, investigation, and the supernatural. Puzzles are, of course, untangled, not without a bit of physical danger. Experienced fantasy readers will probably guess at some of the explanation long before the protagonist does. Like most Cowdrey, it's reliably entertaining, but I found it a bit thin. (6) "A Pocketful of Faces" by Paul Di Filippo: Here's a bit of science fiction, and another mystery, this time following the basic model of a police procedural. The police in this case are enforcing laws around acceptable use of "faces" in a future world where one can clone someone's appearance from their DNA and then mount it on a programmable android. As you might expect from that setup, the possibilities are lurid, occasionally disgusting, and inclined to give the police nightmares. After some scene-setting, the story kicks in with the discovery of the face of a dead woman who, at least on the surface, no one should have any motive to clone. There were a few elements of the story that were a bit too disgusting for me, but the basic mystery plot was satisfying. I thought the ending was a let-down, however. Di Filippo tries to complicate the story and, I thought, went just a little too far, leaving motives and intent more confusing than illuminating. (6) "The Paper Menagerie" by Ken Liu: Back to fantasy, this time using a small bit of magic to illustrate the emotional conflicts and difficulties of allegiance for second-generation immigrants. Jack is the son of an American farther and a Chinese mother who was a mail-order bride. He's young at the start of the story and struggling with the embarassment and humiliation that he feels at his mother's history and the difficulties he has blending in with other kids, leading to the sort of breathtaking cruelty that comes so easily from teenagers who are too self-focused and haven't yet developed adult empathy. I found this very hard to read. The magic is beautiful, personal, and very badly damaged by the cruelty in ways that can never really be fixed. It's a sharp reminder of the importance of being open-hearted, but it's also a devastating reminder that the lesson is normally learned too late. Not the story to read if you're prone to worrying about how you might have hurt other people. (6) "The Evening and the Morning" by Sheila Finch: This long novella is about a third of the issue and is, for once, straight science fiction, a somewhat rare beast in F&SF these days. It's set in the far future, among humans who are members of the Guild of Xenolinguists and among aliens called the Venatixi, and it's about an expedition back to the long-abandoned planet of Earth. I had a lot of suspension of disbelief problems with the setup here. While Earth has mostly dropped out of memory, there's a startling lack of curiosity about its current condition among the humans. Finch plays some with transportation systems and leaves humanity largely dependent on other races to explain the failure to return to Earth, but I never quite bought it. It was necessary to set up the plot, which is an exploration story with touches of first contact set on an Earth that's become alien to the characters, but it seemed remarkably artificial to me. But, putting that aside, I did get pulled into the story. Its emotional focus is one of decline and senescence, a growing sense of futility, that's halted by exploration, mystery, and analysis. The question of what's happened on Earth is inherently interesting and engaging, and the slow movement of the story provides opportunities to build up to some eerie moments. The problem, continuing a theme for this issue, is the ending. Some of the reader's questions are answered, but most of the answers are old, well-worn paths in science fiction. The emotional arc of the story is decidedly unsatisfying, at least to me. I think I see what Finch was trying to do: there's an attempted undermining of the normal conclusion of this sort of investigation to make a broader point about how to stay engaged in the world. But it lacked triumph and catharsis for me, partly because the revelations that we get are too pedestrian for the build-up they received. It's still an interesting story, but I don't think it entirely worked. (6) "Night Gauntlet" by Walter C. DeBill, Jr., et al.: The full list of authors for this story (Walter C. DeBill, Jr., Richard Gavin, Robert M. Price, W.H. Pugmire, Jeffrey Thomas, and Don Webb) provides one with the first clue that it's gone off the rails. Collaborative storytelling, where each author tries to riff off the work of the previous author while spinning the story in a different direction, is something that I think works much better orally, particularly if you can watch facial expressions while the authors try to stump each other. In written form, it's a recipe for a poorly-told story. That's indeed what we get here. The setup is typical Cthulhu mythos stuff: a strange scientist obsessed with conspiracy theories goes insane, leaving behind an office with a map of linkages between apparently unrelated places. The characters in the story also start going insane for similar reasons, leading up to a typical confrontation with things man was not meant to know, or at least pay attention to. If you like that sort of thing, you may like this story better than I did, but I thought it was shallow and predictable. (3) "Happy Ending 2.0" by James Patrick Kelly: More fantasy, this time of the time travel variety. (I call it fantasy since there's no scientific explanation for the time travel and it plays a pure fantasy role in the story.) That's about as much as I can say without giving away the plot entirely (it's rather short). I can see what Kelly was going for, and I think he was largely successful, but I'm not sure how to react to it. The story felt like it reinforced some rather uncomfortable stereotypes about romantic relationships, and the so-called happy ending struck me as the sort of situation that was going to turn very nasty and very uncomfortable about five or ten pages past where Kelly ended the story. (5) "The Second Kalandar's Tale" by Francis Marion Soty: The main question I have about this story is one that I can't answer without doing more research than I feel like doing right now: how much of this is original to Soty and how much if it is straight from Burton's translation of One Thousand and One Nights. Burton is credited for the story, so I suspect quite a lot of this is from the original. Whether one would be better off just reading the original, or if Soty's retelling adds anything substantial, are good questions that I don't have the background to answer. Taken as a stand-alone story, it's not a bad one. It's a twisting magical adventure involving a djinn, a captive woman, some rather predictable fighting over the woman, and then a subsequent adventure involving physical transformation and a magical battle reminiscent of T.H. White. (Although I have quite likely reversed the order of inspiration if as much of this is straight from Burton as I suspect.) Gender roles, however, are kind of appalling, despite the presence of a stunningly powerful princess, due to the amount of self-sacrifice expected from every woman in the story. Personally, I don't think any of the men in the story are worth anywhere near the amount of loyalty and bravery that the women show. Still, it was reasonably entertaining throughout, in exactly the way that I would expect a One Thousand and One Nights tale to be. Whether there's any point in reading it instead of the original is a question I'll leave to others. (7) "Bodyguard" by Karl Bunker: This is probably the best science fiction of the issue. The first person protagonist is an explorer living with an alien race, partly in order to flee the post-singularity world of uploaded minds and apparent stagnation that Earth has become. It's a personal story that uses his analysis of alien mindsets (and his interaction with his assigned alien bodyguard) to flesh out his own desires, emotional background, and reactions to the world. There are some neat linguistic bits here that I quite enjoyed, although I wish they'd been developed at even more length. (The alien language is more realistic than it might sound; there are some human languages that construct sentences in a vaguely similar way.) It's a sad, elegiac story, but it grew on me. (7) "Botanical Exercises for Curious Girls" by Kali Wallace: One has to count this story as science fiction as well, although for me it had a fantasy tone because the scientific world seems to play by fantasy rules from the perspective of the protagonist. Unpacking that perspective is part of the enjoyment of the story. At the start, she seems to be a disabled girl who is being cared for by a strange succession of nurses who vary by the time of day, but as the story progresses, it becomes clear that something much stranger is going on. There are moments that capture a sense of wonder, reinforced by the persistantly curious and happy narrative voice, but both are undercut by a pervasive sense of danger and dread. This is a light story written about rather dark actions. My biggest complaint with the story is that it doesn't so much end as wander off into the sunset. It set up conflict within a claustrophobic frame, so I can understand the thematic intent of breaking free of that frame, but in the process I felt like the story walked away from all of the questions and structure that it created and ended in a place that felt less alive with potential than formless and oddly pointless. I think I wanted it to stay involved and engaged with the environment it had created. (6) "Ping" by Dixon Wragg: I probably should just skip this, since despite the table of contents billing and the full title introduction, it's not a story. It's a two-line joke. But it's such a bad two-line joke that I had to complain about it. I have no idea why F&SF bothered to reprint it. (1) "The Ifs of Time" by James Stoddard: This certainly fits with the Arabian Nights story in this issue. The timekeeper of a vast and rambling castle (think Gormenghast taken to the extreme) wanders into a story-telling session in a distant part of the castle. The reader gets to listen to four (fairly good) short stories about time, knowledge, and memory, told in four very different genres. All of this does relate to why the timekeeper is there, and the frame story is resolved by the end, but the embedded stories are the best part; each of them is interesting in a different way, and none of them outlast their welcome. This was probably the strongest story of this issue. (7) Rating: 6 out of 10

digest version 0.6.1 is now on CRAN, and I will push the corresponding version into Debian shortly. Duncan Murdoch added AES support, and helped me fix two issues which (annoyingly) made the Rout.save output differ on another platform. CRANberries provides the usual summary of changes to version 0.6.0. As usual, our package is available via the R-Forge page leading to svn and tarball access, my digest page and the local directory here.

It's been a long time since I've posted any photographs here (about 15 months, it looks like), so have some clouds. This also serves as a test for whether the scripts I use to post photographs have been properly converted to Git. (And a test to see if the occasional amateur photograph eating up screen real estate will provoke annoyed mutters from the direction of Planet Debian, although so far no complaints over my even-longer book reviews.) I'm still taking photographs occasionally, although not as much as I was at one point. Too many hobbies and not enough time. Part of why I've been slow in posting them is that I was bad about keeping notes about where I took them and bad about keeping up with sorting through them. So I have large collections of photographs from some days where I don't remember exactly where I was, and where I've not already singled out the ones that are worth sharing. One of the things my hobbies always seem to generate is yet another pile of stuff that's not organized quite to my liking. Maybe some evening I'll feel inspired to do a bit more sorting. This is a long weekend in the US for some of us, myself included, so I get another day in this weekend. Which is good, since I've only gotten to a fraction of what I wanted to get to, although at least I found several hours to play video games today. I have finally converted PGP::Sign to Git, so I have no more personal Subversion repositories, but I forgot how much code I'd written to handle its build-time configuration. All of that desperately needs to be reworked, so it's going to take a bit longer than I expected before I can push out another release.