Ensure Ease of Recovery with Asigra’s Agentless Software

FOSDEM The recent FOSDEM was great this year, and Belgium still had beer left before, during and after. Still lots of people, though with an extra building open – it was a little less crowded. There were over 400 sessions on themes from Mozilla, Java, cross-distro and embedded to Ada and law.

There was lots of Debian at FOSDEM, and I followed up with "Zack" – AKA Stefano Zacchiroli, Debian Project Leader – afterwards.

ARM Linux developer Wookey gave a presentation on the multiarch (warning: PDF) work to allow installation of libraries for multiple architectures simultaneously on a single system. This reminded me strongly of the cross-platform deliveries I used to do at a certain ex-bank, to Windows and several *nx variants, though my charges also included executables and header files and some data, plus debug and optimised versions where appropriate.

Multiarch moves on from having a single fixed location such as /usr/lib/ for a particular library, with renaming or other bodging when two or more instances need to cohabit. Instead, the architecture name is injected into the path using a GNU-triplet-style extra directory level eg /usr/lib/i386-linux-gnu/ or /usr/lib/arm-linux-gnueabi/. Packaging and build and making tools that currently 'know' where things are (read: "hardwired") needs some attention, but otherwise the project seems to be working and is visible in Debian and Ubuntu with many packages upgraded.

Meanwhile, the technical lead of Red Hat's open-source Java team – Andrew Haley – announced that the ARM Port Without a Name (APWaN) passed the Java Community Process' Technology Compatibility Kit, so now there are 'officially good' FLOSS ARM Java alternatives.

Also at the event, Codethink's vice president of of business development and marketing Gabriel Vizzard was busting to tell me about work by Luc Verhaegen reverse-engineering the ARM Mali graphics architecture to allow fully-open-source drivers, see limadriver.org. With the distros' (especially Debian's) resistance to being "captured" by narrow external interests, this should be frightening the socks off Intel, since an ordinary dev now really can do everything as freely and easily on ARM as in mainstream development.

Coder Lars Wirzenius used FOSDEM to talk about re-thinking system and distro development. While claiming to be controversial, he seemed to me to be making the entirely pragmatic point that as distros get bigger with tens of thousands of packages and cover multiple architectures, no two developers (or end users) will likely even have exactly the same combination of packages and versions on their machines, making testing and support unreasonably hard.

Tough packages

We agreed (from bitter experience) it is worth consolidating some of them into super-packages, at least for common use patterns, to reduce version-number hell – then automate the build process and add as many automated tests as possible to give rapid feedback to all developers that some innocent change broke something they may not even have been aware of.

Lars suggested that automated continuous integration and build across all packages and and architectures (and to my mind incremental releases) could generate dev feedback for such a 'bad' package change in under a day while it's still fresh in the mind.

I had visions of a dev's own CI system pushing their very latest tested build into (say) Debian's, getting through Debian's complete stack of tests and builds, and popping out in someone's apt-get of bleeding-edge/unstable on the other side of the world within hours without human intervention. How good might that be? Gabriel pointed out: "Monolithic Linux distributions... are enormously expensive to maintain."

Customer Success Testimonial: Recovery is Everything

Next page: Touchy feely time