Google seems to become more and more annoying. Package download http://dl.google.com/linux/chrome/deb/ is slow. Not just slow, but slow. Any random apt-get update will take ages; just sitting there waiting for Google's servers to send any data. Downloading actual packages is slow, as well. Ironically, Google's PageRank will punish sites for loading slowly; it's a pity they don't use their considerable server & bandwidth capacities to fix slowness they are causing, themselves. Chrome Copy and paste is a central part of what I use a mouse for. X has had two copy buffers for as long as I can remember, one for mouse selection, pasting with middle mouse button and one for CTRL-c/CTRL-v. Chrome merges the two. That's bad enough in and as of itself, but every time Chrome gets focus, it will clobber anything you may have in your copy buffers at that time with anything that's selected. No matter if you selected it via mouse, via keyboard, a context switch autoselected something. Selection goes into buffer. Every time. Every. Single. Time. To add insult to injury, this is dependent on which tab is active. And if you happen to search on the site (CTRL-f), it will always use what's in the search bar to clobber buffers, no matter if anything on the actual website has been selected. I can't find the bug report about this at the moment, but Google's stance is that this is a feature and introducing an option for traditional copy & paste handling is not desirable. Google+ I get that they feel a need to combat Facebook, but still, pushing Google+ on you is just annoying. At least the Android application has had a permission change on ICS so it can not auto-update. It's the little things ;) WWW Unified branding, the need to support touch-based devices in their UI, etc. Still, GMail's new interface sucks and the old one will be going away for good. And while making some UI elements larger or displaying them unconditionally makes sense for hand-held portrait displays, this is highly annoying on wide-screen landscape displays. 1366x768 may have overtaken 1024x768, but 768 is a constant here and still not a lot. As an aside, hopefully the Apple Effect and the iPad 3 will break the age-long stalemate with regards to screen resolution. More is better, here. Android Bloatware Using stock Android means you won't get Facebook and other useless apps pre-installed. Yet, uninstalling stock applications, like Google+, is impossible. Rights management It's nice that I get to see what kind of access an application would like to have. It's not nice that I can not choose what access I am willing to grant any given application. I can make a binary decision, install or not install, but I can't refuse random access rights to applications. There are custom versions of Android out there which allow you to do this and many applications seem to cope with being unable to do some things. This should be a standard feature. Access management The concept of "access to USB storage" meaning "whatver your SD card or, in the Galaxy Nexus' case, just a specific directory" is also broken. There is a middle ground between "this application needs access to a large chunk of storage" and "this application needs complete access to said large chunk". Just assign the application a specific directory to write into and read from and done's done. Multi-user I can not hand anyone my phone to play a game or surf the Internet without giving them the ability to look through all my email, contacts, calendar, you name it. While I only give my phone to people I trust completely, this still sucks. How hard can it be to create a minimal guest mode which allows people to access a few pre-selected applications with a custom setting of if they are allowed to use cellular data and/or WiFi? Data access Authorized Access Ah, the big one.... Keep in mind that I am using Google's latest and greatest, the Samsung Galaxy Nexus GSM. It's as cutting-edge as you can get. Yes, having one continuous storage device is nice. But MTP support on Linux is abysmal and you are forced to access your data by means of MTP or PTP. gphoto2, gwenview, and gthumb are all unable to import any photos via PTP; no program I tried can transfer anything via MTP. gphoto2 will transfer the background images which APOD (highly recommended, by the way; there's also a donation application for this) stores on my phone. That's it. So, unless I send email to myself, use WiFi-based hacks, or root my phone, I can not access my data. On the strongest mobile platform in the world. Using the most powerful and versatile OS with up-to-date packages. In 2012. Yay. Unauthorized Access Not being able to access my data is a Bad Thing. Even worse is when others can access my data. Contrary to older Android versions, someone decided that it would be a good idea to allow MTP or PTP, only. As in "you can not disable MTP and PTP. One of them has the be activated." This is awesome when you want to charge your phone at an airport or at an acquaintance's possibly malware-ridden Windows machine. Everyone and their bot-herder can potentially access my data while I can not. Usability And while MTP/PTP is an either/or decision, they are using check-boxes, not radio buttons. There's a decade or more of UI experience about check-box versus radio button, so why not use it? I know of at least one owner of a Galaxy Nexus who was not even aware that he couldn't turn off MTP (the default) as the UI pretends otherwise. Opaqueness And good luck trying to contact anybody about this. Having filed a few bugs against Google stuff in the past, I simply gave up on it. Back when Gmail's mailing list filtering and labelling system was somewhat broken, I spent months hunting down people who knew people who knew someone who was able to actually do something about it.

Still waiting for mine - though I did buy a case for when it comes. News from www.raspberrypi.org - the prototype submitted for EMC testing has apparently passed, though the paperwork has to be validated (blog posting).
It has passed CE marking, FCC part 15 marking, Canadian certification and the Australian C-Tick scheme. There is also an updated trademark policy at new trademark rules ( http://www.raspberrypi.org/trademark-rules ) and a video over at the Farnell/Element14 website from Eben Upton detailing how to set up the Raspberry Pi, shots of booting, explanations of how to use an editor, compile a first Python program and how to build the graphics demos provided. ( http://www.element14.com/community/docs/DOC-44459 )

Since some years, there has been a movement towards standardization: mobile devices are now using Micro-USB for data transfer and charging, and SD or Micro-SD for storage extension (except Apple of course). One piece is lacking to this perfection, however; as far as I know, digital camera producers did realize that SD won for storage, but they do not seem to have acknowledged the Micro-USB standard yet. Now, since manufacturers and resellers do not indicate the connector type, I have no way to be sure that this is still the case. So, dear lazyweb, do you know if, by chance, there exists a compact digital camera that would use SD cards and a Micro-USB connector for data transfer and integrated charging?

One of my clients is currently investigating new hosting arrangements. It s a bit of a complex process because there are lots of architectural issues relating to things such as the storage and backup of some terabytes of data and some serious computation on the data. Among other options we are considering cheap servers in the EX range from Hetzner [1] which provide 3TB of RAID-1 storage per server along with reasonable CPU power and RAM and Amazon EC2 [2]. Hetzner and Amazon aren t the only companies providing services that can be used to solve my client s problems, but they both provide good value for what they provide and we have prior experience with them. To add an extra complication my client did some web research on hosting companies and found that Hetzner wasn t even in the list of reliable hosting companies (whichever list that was). This is in some ways not particularly surprising, Hetzner offers servers without a full management interface (you can t see a serial console or a KVM, you merely get access to reset it) and the best value servers (the only servers to consider for many terabytes of data) have SATA disks which presumably have a lower MTBF than SAS disks. But I don t think that this is a real problem. Even when hardware that s designed for the desktop is run in a server room the reliability tends to be reasonable. My experience is that a desktop PC with two hard drives in a RAID-1 array will give a level of reliability in practice that compares very well to an expensive server with ECC RAM, redundant fans, redundant PSUs, etc. My experience is that the most critical factor for server reliability is management. A server that is designed to be reliable can give very poor uptime if poorly maintained or if there is no rapid way of discovering and fixing problems. But a system that is designed to be cheap can give quite good uptime if well maintained, if problems can be repidly discovered and fixed. A Brief Overview of Managing Servers There are text books about how to manage servers, so obviously I can t cover the topic in detail in a blog post. But here are some quick points. Note that I m not claiming that this list includes everything, please add comments about anything particularly noteworthy that you think I ve missed.

1. For a server to be well managed it needs to be kept up to date. It s probably a good idea for management to have this on the list of things to do. A plan to check for necessary updates and apply them at fixed times (at least once a week) would be a good thing. My experience is that usually managers don t have anything to do with this and sysadmins either apply patches or not at their own whim.
2. It is really ideal for people to know how all the software works. For every piece of software that s running it should either have come from a source that provides some degree of support (EG a Linux distribution) or be maintained by someone who knows it well. When you install custom software from people who become unavailable then it puts the reliability of the entire system at risk if anything breaks then you won t be able to get it fixed quickly.
3. It should be possible to rapidly discover problems, having a client phone you to tell you that your web site is offline is a bad thing. Ideally you will have software like Nagios monitoring the network and reporting problems via a SMS gateway service such as ClickaTell.com. I am not sure that Nagios is the best network monitoring system or that ClickaTell is the best SMS gateway, but they have both worked well in my experience. If you think that there are better options for either of those then please write a comment.
4. It should be possible to rapidly fix problems. That means that a sysadmin must be available 24*7 to respond to SMS and you must have a backup sysadmin for when the main person takes a holiday, or ideally two backup sysadmins so that if one is on holiday and another has an emergency then problems can still be fixed. Another thing to consider is that an increasing number of hotels, resorts, and cruise ships are providing net access. So you could decrease your need for backup sysadmins if you give a holiday bonus to a sysadmin who uses a hotel, resort, or cruise ship that has good net access. ;)
5. If it seems likely that there may be some staff changes then it s a really good idea to hire a potential replacement on a casual basis so that they can learn how things work. There have been a few occasions when I started a sysadmin contract after the old sysadmin ceased being on speaking terms with the company owner. This made it difficult for me to learn what s going on.
6. If your network is in any way complex (IE it s something that needs some skill to manage) then it will probably be impossible to hire someone who has experience in all the areas of technology at a salary you are prepared to pay. So you should assume that whoever you hire will do some learning on the job. This isn t necessarily a problem but is something that needs to be considered. If you use some unusual hardware or software and want it to run reliably then you should have a spare system for testing so that the types of mistake which are typically made in the learning process are not made on your production network.

Conclusion If you have a business which depends on running servers on the Internet and you don t do all the things in the above list then the reliability of a service like Hetzner probably isn t going to be an issue at all.

• [1] http://www.hetzner.de/hosting/produktmatrix/rootserver-produktmatrix-ex
• [2] http://aws.amazon.com/ec2/

Related posts:

1. Servers vs Phones Hetzner have recently updated their offerings to include servers with...
2. Why Internet Access in Australia Sucks In a comment on my post about (relatively) Cheap Net...
3. The National Cost of Slow Internet Access Australia has slow Internet access when compared to other first-world...

I previously wrote about my first experiences with BTRFS [1]. Since then I ve been using BTRFS on more systems and have had good results. The main problem I want to address is with the reliability of RAID [2]. Requirements for a File Server Now one of my clients has a need for a new fileserver. They need to reliably store terabytes of data (currently 6TB and growing) which is mostly comprised of data files in the 10MB 15MB size range. The data files will almost never be re-written and I anticiapte that the main bottleneck will be the latency of NFS and other network file sharing protocols. I would hope that saturating a GigE network when sending 10MB data files from SATA disks via NFS, AFS, or SMB wouldn t be a technical challenge. It seems that BTRFS is the way of the future. But it s still rather new and the lack of RAID-5 and RAID-6 is a serious issue when you need to store 10TB with today s technology (that would be 8*3TB disks for RAID-10 vs 5*3TB disks for RAID-5). Also the case of two disks entirely failing in a short period of time requires RAID-6 (or RAID-Z2 as the ZFS variant of RAID-6 is known). With BTRFS at it s current stage of development it seems that to recover from two disks failing you need to have BTRFS on another RAID-6 (maybe Linux software RAID-6). But for filesystems based on concepts similar to ZFS and BTRFS you want to have the filesystem run the RAID so that if a block has a filesystem hash mismatch then the correct copy can be reconstructed from parity. ZFS seems to be a lot more complex than BTRFS. While having more features is a good thing (BTRFS seems to be missing some sysadmin friendly features at this stage) complexity means that I need to learn more and test more before going live. But it seems that the built in RAID-5 and RAID-6 is the killer issue. Servers start becoming a lot more expensive if you want more than 8 disks and even going past 6 disks is a significant price point. As 3TB disks are available an 8 disk RAID-6 gives something like 18TB usable space vs 12TB on a RAID-10 and a 6 disk RAID-6 gives about 12TB vs 9TB on a RAID-10. With RAID-10 (IE BTRFS) my client couldn t use a 6 disk server such as the Dell PowerEdge T410 for $1500 as 9TB of usable storage isn t adequate and the Dell PowerEdge T610 which can support 8 disks and costs $2100 would be barely adequate for the near future with only 12TB of usable storage. Dell does sell significantly larger servers such that any of my clients needs could be covered by RAID-10, but in addition to costing more there are issues of power use and noise. When comparing a T610 and a T410 with a full set of disks the price difference is $1000 (assuming $200 per disk) which is probably worth paying to delay any future need for upgrades. Buying Disks The problem with the PowerEdge T610 server is that it uses hot-swap disks and the biggest disks available are 2TB for $586.30! 2TB*8 in RAID-6 gives 12TB of usable space for $4690.40! This compares poorly to the PowerEdge T410 which supports non-hot-swap disks so I can buy 6*3TB disks for something less than $200 each and get 12TB of usable space for $1200. If I could get hot-swap trays for Dell disks at a reasonable price then the T610 would be worth considering. But as 12TB of storage should do for at least the next 18 months it seems that the T410 is clearly the better option. Does anyone know how to get cheap disk trays for Dell servers? Implementation In mailing list discussions some people suggest using Solaris or FreeBSD for a ZFS server. ZFS was designed for and implemented on Solaris, and FreeBSD was the first port. However Solaris and FreeBSD aren t commonly used systems so it s harder to find skilled people to work with them and there is less of a guarantee that the desired software will work. Among other things it s really convenient to be able to run software for embedded Linux i386 systems on the server. The first port of ZFS to Linux was based on FUSE [3]. This allows a clean separation of ZFS code from the Linux kernel code to avoid license issues but does have some performance problems. I don t think that I will have any performance issues on this server as the data files are reasonably large, are received via an ADSL link, and which require quite a bit of CPU time to process them when they are accessed. But ZFS-FUSE doesn t seem to be particularly popular. The ZFS On Linux project provides source for a ZFS kernel module which you can compile and load [4]. As the module isn t distributed with or statically linked to the kernel the license conflict of the CDDL ZFS code and the GPL Linux kernel code is apparently solved. I ve read some positive reports from people who use this so it will be my preferred option.

• [1] http://etbe.coker.com.au/2012/02/10/starting-with-btrfs/
• [2] http://etbe.coker.com.au/2012/02/06/reliability-raid/
• [3] http://zfs-fuse.net/
• [4] http://zfsonlinux.org/

Related posts:

1. ECC RAM in a Cheap Machine In a comment on my previous post about ECC RAM...
2. Starting with BTRFS Based on my investigation of RAID reliability [1] I have...
3. Dell PowerEdge T105 Today I received a Dell PowerEDGE T105 for use by...

Now that our departure is looming ahead of us, it's time to give a short update. (Turns out it's not so short, after all...) Preparation Visa Mongolian and Russian visas are done; we will apply for the Chinese ones next Monday. Travel All train tickets, hotels, hostels, and tents have been booked and both a horse-back tour through Mongolia and scuba diving in Lake Baikal have been pre-arranged. The Russian railway seems to do maintenance and development on the live website all the time which meant we were forced to book through a local travel agent. We paid a hefty extra charge for that privilege but still, that was less than half of what we would have paid if we had booked through a German agent. With the help of #china-lug on irc.freenode.net, we found accommodation in a traditional Siheyuan in an old Hutong. Hopefully, this will be a interesting as it sounds. Locals By the power of attending conferences and this blog, I now have local contacts in Moscow, Beijing, and Shanghai. Everyone who contacted me was extremely nice and helpful. I have been getting hints and tips galore; I doubt our preparations would be as neat as they are without this invaluable help. Thanks; you know who you are :) Packing list Apparently there's an interest in what we will be bringing; also, this will be a nice reminder for the future. Information and note-keeping

• Travel guides for the Trans-Siberian and Beijing (in case you use Lonely Planet books, the new layout they are using as of late is a lot better)
• Phrase books for Russian, Mongolian, and Mandarin
• Print-out of all bookings, etc.
• Paper notebook to track expenses, make notes, cross-reference photos, and various other uses
• Several sturdy ball pens
• Post-It notes and those neon-colored self-adhesive marker flags
• Permanent marker

Luggage

• Two Backpacks
• Deuter Helion 80, a duvel bag with wheels which transforms into a proper backpack. This. Is. Awesome.
• Rain covers for all bags

Clothing

• Heavy-duty hiking boots
• Sneakers
• Fleece jacket
• Hard shell jacket
• Worker's pants (pockets, pockets, pockets!)
• Base-ball cap (against sund and for propping up the hood of hood if neccessary)
• Wind-tight hat with close-fitting ear flaps (looks like crap, but is the best I ever had)
• Long underwear
• Assorted T-Shirts, socks, etc.

Personal and computer security

• Kubotan
• Copies of all documents, tickets, visas, etc.; apparently you should never hand originals of any documents to Russian police
• Hand-held GPS
• Two-way GPS tracking beacon with satellite uplink
• US Dollars as backup currency
• Second pair of glasses
• Old laptop with 1 TB drive and a fresh installation of Debian with no personal data, ssh keys, etc.
• VPN & SSH access to a throw-away virtual host back home
• Old dumbphone

Fastening, storage, and tools

• Reflective guy-wire with knot-less tighteners
• Bracelets made from braided para cord with whistle built into the clasp
• Stainless steel bolt-snaps
• Zip ties, assorted lengths
• Zip-Loc bags
• Plastic clamps for open bags, etc.
• Victorinox Swisstool with ratchet and bits (Leatherman, Gerber, you name it, can't even get close in quality)
• Pocket knife
• Cut-proof Kevlar gloves with latex anti-slip covering
• Ballistol (oil, skin protection, dealing with cuts, and for cleaning cutlery)
• Silicone grease
• MoS₂ grease
• Duct tape
• Super-glue (for deeper wounds, closing holes in fabric, etc.)
• Power outlet adapter (Russia and Mongolia use CEE 7/4 while China uses four different sockets)
• Electrical extension cord with multiple outlets
• Swedish firesteel
• Cigarette lighter
• Make-up remover pads (compressed cotton wool; great for starting fires)
• Various flashlights, headlamps, and key-chain lights (no power in the Mongolian desert, remember?)
• Laser pointer
• Tritium everglow key-chain marker
• Chemical hand and foot warmers

Health

• Gold/silver foil rescue blanket
• Water purifying tablets
• Medkit with painkillers, disinfectant, bandages, you name it

Photography

• DSLR with spare battery and battery grip that uses AA cells (again, no power in the Mongolian desert)
• Wide angle, prime and super-zoom lens
• Filters
• Backup point-and-shoot
• USB thumb drive
• 2 external HDDs
• SD cards
• Tripod

Minimal scuba gear

• Scuba mask
• Dive computer
• Dive compass
• Dive light

Food

• Picnic cutlery
• Plastic cup
• Folding 1.5 liter plastic bottles with sippy top
• Instant coffee
• Pulverized cocoa
• Teabags
• Muesli bars
• Hard sausages and cheeses
• Thermos
• Compact 8-spice shaker
• TupperWare box
• "Typically German food" that we will trade for local food on the train; Russians tell me that's their go-to food when in Germany and that we should bring it
  • Beer
  • Frankfurters
  • Mustard

Convenience

• Toilet paper
• Single-use washcloths
• Anti-mosquito head nets
• Silk sleeping bag liners (for train compartments and when sleeping in borrowed sleeping bags in the Gers)
• Old towel (can be thrown away if need be)
• Microfiber towel (light, packs to less than fist size)
• Sleeping mask
• Noise-cancelling earbuds
• Heavy-duty hand cleaning paste
• Washing paste for clothes
• Toiletries

Leisure

• Several card games
• Travel Trivial Pursuit
• Nintendo DS
• MP3 player
• e-book reader
• USB surround speakers
• Headphones
• Various movies and TV shows
• zsnes plus ROMs of legally-owned games
• Snuff tobacco (for socializing with Mongolian nomads)

That's it. Re-reading this list, I wonder how we managed to fit all of this into an 80-liter travel bag and a 15-liter backpack, but we did and with room to spare.

All aboard the Choo Choo train! As some of you know, we are planning our trip on the Trans-Siberian (well, Trans-Mongolian to be exact) railway, at the moment. Given the wall of text my post about Svalbard turned out to be, I am trying to split early and often. The plan Our three-week itinerary is pretty much fixed, by now:

• Fly to Moscow, tour the city
• Take the train to Novosibirsk, tour the city and industrial area (if anyone knows of good photo opportunities, do let me know! Novosibirsk is supposedly incredible if you know where to look... and I don't...)
• Take the train to Irkutsk, continue to Listvyanka near Lake Baikal, scuba dive, maybe take train around Lake Baikal just because
• Take the train to Ulan Bator, tour Mongolia for five days
• Take the train to Beijing, visit usual places, have chinese candy
• Take the train to Shanghai, marvel at skyline at night, visit one of the water cities nearby
• Fly back home

Visa issues Not wanting to just book any random package with any random travel agent, we are picking and mixing our own, as usual. Given visa requirements, language barriers and things that are plain weird, it's been an interesting ride before we even pack our bags a month or two from now. Being European, visas are something that do not concern us a lot, normally. I am starting to realize how incredibly lucky we are... barring India, we never needed to do much to be allowed to enter any foreign country. Not so on this trip... While Mongolia has rather lax, or let's just say reasonable, terms, China and Russia are different. To get a visa for Russia, you need:

• Passport, valid for at least six months after your planned departure
• Photo, not older than six months
• Personal invitation (you simply buy those from agencies within Russia)
• Voucher from an accredited travel agency
• Detailed itinerary
• Proof of health insurance for exact time of stay, i.e. dates of entry and departure; make it too long and you may have trouble getting your visa
• Copy of one of the following:
  • Current pay slip
  • Bank statement
  • Registration of real estate
  • Registration of company in your name

For China, you need to provide a night-to-night itinerary of hotel stays. This may be a remnant of Mao's philosophy of restricting free movement of the population within China, I don't know. On the plus side, they don't require an invitation, health insurance or means of industrial espionage. With processing times ranging from one to four weeks per visa, you will wait one to two months until your passports are back with you and properly visa'ed by everyone. Tickets, please Purchasing tickets in advance, but not through a travel agent, is turning out to be rather complicated. As you can not book train tickets with RZD, the Russian rail company, more than 45 days in advance, you end up with nice circular dependencies. We could pay a premium for faster processing of our visas and buy via travel agencies which sell train tickets from their special contingents, but that's kinda boring, innit? Also, rzd.ru offers Russian order forms, only. With the help of Google translate, ##russian on irc.freenode.net, and a lot of guess-work, we were able to hammer out the connections from Moscow to Novosibirsk and from there on to Irkutsk. Yet, it's quite a different experience not to not be able to fall back to English. No matter where we went in the past, English was the lingua franca, at least to some extent. That's not the case in any of our three intended destinations so those phrase books will get used a lot, I suspect... We are still not sure if the 4-people cabins in second class have a door, let alone one that can be locked, but we decided that this is not too much of an issue. Generally speaking, people are nice and there are train attendants so crime should not be an issue. And even if things do disappear, as long as we stay healthy and I still have one of my several copies of all photos I will take, I will be reasonably happy. As to getting from Irkutsk to Ulan Bator... even a Russian travel agent we contacted claimed you can only purchase tickets on site, not online. From Ulan Bator to Beijing, it's a different booking system. And from Beijing to Shanghai, it's yet another one. This is the most fragmented booking process we ever went through. Other than a few moments of stress and frustration, the hunting for information, cross-referencing and having the occasional eureka moment is tons of fun, though; no complaints here. When in Rome... According to Lonely Planet, the Trans-Siberian is more or less one large picnic where everyone shares whatever they have with them with everyone else. I poked a few Russians about what typically German food they like and they came up with Frankfurters, mustard, and beer. Guess that's what we will be stuffing our backpack with once everything else is packed. And snuff; apparently it's common courtesy to offer your snuff to other men you meet in Mongolia and then snuff from their bottle. When in Rome... German snuff tends to be mixed with menthol, I suspect that will raise some eyebrows ;) No idea if there is any non-obvious social grease to bring to China; still working on that. Initially, we wanted to tour Mongolia's main attractions, but we would either have to sit in a car for days on end or go by plane. Driving for days in between a solid week(!) spent on trains is not very appealing and neither is breaking our personal ground travel record by cheating flying. Thus, we decided to take the eco-tourism route: After a two-hour orientation course in Mongolian behaviour and manners, we will travel a few hundred kilometers by public bus, be picked up by a local, driven out into the outback and ride from ger to ger by camel and horse before returning to Ulan Bator by bus. The stays at the gers are immersive, if short; we will live with the families, help them do their daily chores, and visit local places of interest in between. Oddly enough, I am looking to forward to the bus ride even more than to the gers. At the gers, at least one person is able to speak basic English. Not so with the local bus. People on the various trains will be used to strangers, as are the families at the gers. People on the bus are, most likely, not. Communicating with hand, foot, phrasebook, and a smile will, hopefully, be a lasting experience. If time permits, we will try to visit kiva.org borrowers while in Ulan Bator; this is something we never had a chance to do before and it's been on the bucket list for some time, now. As an aside, the local agent in Mongolia asked us if our sleeping bags are rated down to -26 degrees Celsius. I do hope he was joking... On the privileges of living in a first-world country... Travelling by horse means travelling light. Not a problem for us as we pack light by default and still manage to bring everything from Swiss Tool to water bottles, zip ties, medkit, and everything in between. Still, there's one major thing I have been taking for granted all my life: electricity. Being without any source of power for four to five days is... challenging. Even more so as every single gadget I rely on uses a different type of battery. Flashlight: CR123A and AA; GPS: Ni-MH AA rechargeables and Lithium AAA primaries respectively; Laptop, cameras, cell phone, ebook reader, Nintendo DS and MP3 player: proprietary. I am starting to truly understand why NATO has a hard rule of allowing AA-powered devices, only; planning spares is a pain. Obviously, I am focusing on flashlights, GPS, and, above all, cameras. Battery grips with AA adapters to the rescue! Another even more unsettling realization came when I asked if it would be possible to have boodog (vegetarians/vegans: don't click). Mongolians do not usually prepare boodog in spring as the animals which survived the harsh winter need to fatten and breed before being killed for food. All my life, I have never even once considered the remote possibility of not being able to slaughter domesticated animals due to outside constraints. Mongolian nomads need their animals. This is not about wanting to do things one way or another; this is about survival. Quite fascinating, and humbling, to think about. I am incredibly privileged and, as you are reading this, so are you. An exercise for the reader If you have any information regarding:

• Good places to see in and around Novosibirsk in one day
• Social grease and tips, especially regarding China
• Getting from Irkutsk to Ulan Bator
• Reliable solar chargers for Ni-MH AA batteries
• Interesting things I didn't mention in this post

please let me know. As usual, but just a little bit more than usual, comments are appreciated.

Behind Debian Edu and Skolelinux there are a lot of people doing the hard work of setting together all the pieces. This time I present to you Andreas Mundt, who have been part of the technical development team several years. He was also a key contributor in getting GOsa and Kerberos set up in the recently released Debian Edu Squeeze version. Who are you, and how do you spend your days? My name is Andreas Mundt, I grew up in south Germany. After studying Physics I spent several years at university doing research in Quantum Optics. After that I worked some years in an optics company. Finally I decided to turn over a new leaf in my life and started teaching 10 to 19 years old kids at school. I teach math, physics, information technology and science/technology. How did you get in contact with the Skolelinux/Debian Edu project? Already before I switched to teaching, I followed the Debian Edu project because of my interest in education and Debian. Within the qualification/training period for the teaching, I started contributing. What do you see as the advantages of Skolelinux/Debian Edu? The advantages of Debian Edu are the well known name, the out-of-the-box philosophy and of course the great free software of the Debian Project! What do you see as the disadvantages of Skolelinux/Debian Edu? As every coin has two sides, the out-of-the-box philosophy has its downside, too. In my opinion, it is hard to modify and tweak the setup, if you need or want that. Further more, it is not easily possible to upgrade the system to a new release. It takes much too long after a Debian release to prepare the -Edu release, perhaps because the number of developers working on the core of the code is rather small and often busy elsewhere. The Debian LAN project might fill the use case of a more flexible system. Which free software do you use daily? I am only using non-free software if I am forced to and run Debian on all my machines. For documents I prefer LaTeX and PGF/TikZ, then mutt and iceweasel for email respectively web browsing. At school I have Arduino and Fritzing in use for a micro controller project. Which strategy do you believe is the right one to use to get schools to use free software? One of the major problems is the vendor lock-in from top to bottom: Especially in combination with ignorant government employees and politicians, this works out great for the "market-leader". The school administration here in Baden-Wuerttemberg is occupied by that vendor. Documents have to be prepared in non-free, proprietary formats. Even free browsers do not work for the school administration. Publishers of school books provide software only for proprietary platforms. To change this, political work is very important. Parts of the political spectrum have become aware of the problem in the last years. However it takes quite some time and courageous politicians to 'free' the system. There is currently some discussion about "Open Data" and "Free/Open Standards". I am not sure if all the involved parties have a clue about the potential of these ideas, and probably only a fraction takes them seriously. However it might slowly make free software and the philosophy behind it more known and popular.

On my everyday netbook (a very reliable first generation ASUS EeePC 701 4G) the disk (4 GB as the product name suggests :-) is nearly always close to full. TL;DWTR? Jump directly to the HowTo. :-) So I came up with a few techniques to save some more disk space. Installing localepurge was one of the earliest. Another one was to implement aptitude filters to do interactively what deborphan does non-interactively. Yet another one is to use du and friends a lot ncdu is definitely my favourite du-like tool in the meanwhile. Using du and friends I often noticed how much disk space /usr/share/doc takes up. But since I value the contents of /usr/share/doc a lot, I condemn how Nokia solved that on the N900: They let APT delete all files and directories under /usr/share/doc (including the copyright files!) via some package named docpurge. I also dislike Ubuntu s solution to truncate the shipped changelog files (you can still get the remainder of the files on the web somewhere) as they re an important source of information for me. So when aptitude showed me that some package suddenly wanted to use up quite some more disk space, I noticed that the new package version included the upstream changelog twice. So I started searching for duplicate files under /usr/share/doc. There are quite some tools to find duplicate files in Debian. hardlink seemed most appropriate for this case. First I just looked for duplicate files per package, which even on that less than four gigabytes installation on my EeePC found nine packages which shipped at least one file twice. As recommended I rather opted for an according Lintian check (see bugs. Niels Thykier kindly implemented such a check in Lintian and its findings are as reported as tags duplicate-changelog-files (Severity: normal, from Lintian 2.5.2 on) and duplicate-files (Severity: minor, experimental, from Lintian 2.5.0 on). Nevertheless, some source packages generate several binary packages and all of them (of course) ship the same, in some cases quite large (Debian) changelog file. So I found myself running hardlink /usr/share/doc now and then to gain some more free disk space. But as I run Sid and package upgrades happen more than daily, I came to the conclusion that I should run this command more or less after each aptitude run, i.e. automatically. Having taken localepurge s APT hook as example, I added the following content as /etc/apt/apt.conf.d/98-hardlink-doc to my system:

// Hardlink identical docs, changelogs, copyrights, examples, etc
DPkg
 
Post-Invoke  "if [ -x /usr/bin/hardlink ]; then /usr/bin/hardlink -t /usr/share/doc; else exit 0; fi"; ;
 ;

So now installing a package which contains duplicate files looks like this:

~ # aptitude install perl-tk
The following NEW packages will be installed:
  perl-tk 
0 packages upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 2,522 kB of archives. After unpacking 6,783 kB will be used.
Get: 1 http://ftp.ch.debian.org/debian/ sid/main perl-tk i386 1:804.029-1.2 [2,522 kB]
Fetched 2,522 kB in 1s (1,287 kB/s)  
Selecting previously unselected package perl-tk.
(Reading database ... 121849 files and directories currently installed.)
Unpacking perl-tk (from .../perl-tk_1%3a804.029-1.2_i386.deb) ...
Processing triggers for man-db ...
Setting up perl-tk (1:804.029-1.2) ...
Mode:     real
Files:    15423
Linked:   3 files
Compared: 14724 files
Saved:    7.29 KiB
Duration: 4.03 seconds
localepurge: Disk space freed in /usr/share/locale: 0 KiB
localepurge: Disk space freed in /usr/share/man: 0 KiB
localepurge: Disk space freed in /usr/share/gnome/help: 0 KiB
localepurge: Disk space freed in /usr/share/omf: 0 KiB
Total disk space freed by localepurge: 0 KiB

Sure, that wasn t the most space saving example, but on some installations I saved around 100 MB of disk space that way and I still haven t found a case where this caused unwanted damage. (Use of this advice on your own risk, though. Pointers to potential problems welcome. :-)

Hello Like all kids, my kids really enjoy watching cartoons. Unfortunately, most of them are broadcast during the morning, sometimes very early in the morning. Since I don t want my kids to wake up (or wake me up ) too early in the morning to watch cartoon, I record the most interesting programs with vdr (I also edit out commercials before my kids watch them) To limit my carbon (or equivalent radio-active waste) footprint, I do not want to leave the computer on 24/24, so the machine has to power up by itself before a recording time. So I ve setup vdr to automatically setup the wake up time of the computer and shutdown the machine once the recording is finished. Note that this machine is also my main home machine, so it must not shutdown while I m working on it (typing this blog, for instance). This should have been easy and fairly documented. Well, it was not that easy. A lot of doc mentions nvram-wakeup which is more or less obsolete. Other docs were in German. So, here s a summary of the setup so other can benefit from my experience. First, this was done on a Debian/sid machine, this post should be usable on other distros, provided some adaptations. These adaptations are left as an exercise to the reader (which is marketing lingo for I don t have a clue ) First add this line in /etc/default/vdr:

 ENABLE_SHUTDOWN=1

When vdr has nothing to do, it will run some shutdown scripts, including /usr/share/vdr/shutdown-hooks/S90.custom, which is a link to /etc/vdr/shutdown-hooks/S90.custom. The output of this script will be eval ed by vdr, so vdr knows what to do next (e.g. abort shutdown, display a message to user, retry later ). Here are the possible output of a vdr shutdown script (list taken from vdr-wiki):

• To abort the shutdown, exit with an errorlevel != 0.
• If you want a message to be displayed on the OSD when aborting a shutdown,
  then write to stdout:
  ABORT_MESSAGE=<message to display>
• If you want to defer the shutdown, write to stdout:
  TRY_AGAIN=<minutes to wait before next shutdown request>
• To overwrite the command that will be executed to shutdown the machine
  after all shutdown hooks have been processed, write to stdout:
  SHUTDOWNCMD=<new shutdown command>
  i.e.:
  echo "ABORT_MESSAGE=\"I do not want to shutdown now!\"" ; exit 1

This script will mess with /sys/class/rtc/rtc0/wakealarm so it must be run as root. But vdr will launch this script and does not run as root. Instead of setting a suid bit, let s setup sudo to enable this script to gain root privilege from vdr. Add this line in /etc/sudoers (with visudo):

vdr ALL= NOPASSWD: /etc/vdr/shutdown-hooks/S90.custom *

And here s a commented Perl script that handle the shutdown test:

#!/usr/bin/perl
use IO::File ;
use 5.10.0 ;
use English;
use Path::Class; 
use Sys::Syslog qw(:standard :macros);  # standard functions & macros
openlog('vdr-shutdown', "", "user");

Here s the call to sudo to gain root privilege (if not already run as root):

if ($EUID)  
    system('sudo','/etc/vdr/shutdown-hooks/S90.custom', @ARGV) ;
    syslog(info => "vdr-shutdown: sudo myself returned $@") ;
 

Get the next timer info from the command arguments provided by vdr:

my ($next_timer,$interval) = @ARGV ;

Setup the next alarm in the mother board:

if ( $next_timer)  
  my $dev_fh = IO::File->new("> /sys/class/rtc/rtc0/wakealarm");
  die "cannot open $dev_fh: $!" unless $dev_fh ;
  my $newtime = $next_timer - 300  ;  # Start 5 minutes earlier
  $dev_fh->print( "$newtime\n" ) ;
  $dev_fh->close ;
  syslog(info => "vdr-shutdown: set wakeup to $newtime") ;
 

Now, let s check if someone is logged on the system. Weirdly enough, forking a command from this Perl script does not work when it s run by vdr. Calling the who command always return empty. The trick to find if anyone is logged is to check the content of /dev/pts directory. No files in there means that nobody is logged:

my @pts  = dir('/dev/pts')->children;
syslog(info => "vdr-shutdown:  found pts @pts") ;
if (@pts > 1)  
    syslog(info => "vdr-shutdown: retry later: someone is logged") ;
    say 'ABORT_MESSAGE="someone is logged, shutting down deferred"';
    say 'TRY_AGAIN=30'
 
else  
    syslog(info => "vdr-shutdown: nobody is logged, halting") ;
 

Now some cleanup then exit:

closelog() ;
exit 0;

This script has been working for one month, and not a single programs was missed. My kids are happy. I m not so happy because I now have a lot of commercials to edit out All the best
Tagged: debian, Perl, vdr

Two weeks ago, I was at LOAD, where I did a tutorial on Debian Packaging. Unfortunately, I wasn't doing very well physically, and as a result my preparation wasn't what I had hoped for. It ended up being not so much a tutorial as a walking the audience through packaging a piece of software in casu NBD with debhelper in dh mode. Not very difficult, but since there's nothing for people to fall back on afterwards, it may help if they have a writedown of what I said during the session; and I promised to put it on my blog. So, here goes. However, note that the canonical written tutorial on Debian Packaging is here. With apologies to readers of Planet Debian, most of whom for which all this is probably old hat. Unlike RPM packaging, in Debian, the data that tells the debian packaging system how to package a piece of software is functionally split among a number of files. All these files go in a toplevel directory in the source package, (unsurprisingly) called 'debian'. There are four files that are required for every Debian package: the control, changelog, copyright, and rules files. Without these files, dpkg-dev will fail to produce a package any package. The first, the control file, contains metadata on packages: the name of the package, its description, the dependencies, etc. Basically, almost all the information you see when you run 'apt-cache show <package>' (with one exception) is in the control file. If you have a source package that builds multiple binary packages, then you should have multiple 'Package' stanzas in the control file. In my opinion, creating a control file is easiest done by copying a control file from another (similar?) package, and modifying it to suit the software you're dealing with. The one exception, the one bit of metadata that is not found in the control file is the version number: this data is contained in the changelog file. This file looks like a free-form file for the most part, but it really is a machine-parsable format; as such, it's best to edit it with specialized tools, such as the debian-changelog-mode in the emacs editor, or the debchange script, also available as dch, from the devscripts package. In the changelog, you should document any changes you make to the package, making sure the version number (top line), distribution (unstable, experimental, stable, ...; top line), urgency (top line; used mainly when testing needs to be updated urgently for things like security updates), author (bottom line) and date and time (also bottom line) are correct. The copyright file, unsurprisingly, should contain the copyrights statements of the original software, and the license (or a reference to a copy of the same license text under /usr/share/common-licenses). This file is still free-format in most packages today, although a machine-readable format for this file has recently been defined. Of the four required files, this is probably the most boring one, but hey, we can't like everything we do. The last file, the rules file, is where all the action happens. This file is defined as a Makefile, of which the targets are called for various parts of the build system. The rules file has a number of required targets (such as build, clean, and others), but if you're using debhelper in dh mode, you don't need to worry about those; instead, you can use the following simple rules file:

#!/usr/bin/make -f
%:
	dh $@

With the first line, the shebang, we make clear that this is a makefile, and that it should be called by make. The next is a generic target (the % is a wildcard for make), with just one command: 'call dh with the name of the target being called'. Since dh implements all required rules targets, that immediately gets you a working package. Go ahead, try! Run 'dpkg-buildpackage -rfakeroot', and see what happens. Did that work? Maybe, maybe not. First, you'll have seen loads of warnings about something involving a "compatibility level". This is from debhelper; this compatibility level, or 'API level' if you wish, allows debhelper to move forward and make incompatible changes without breaking all the existing packages out there; whenever the compat level is bumped, some new functionality will only be made available if you also raise the compat level in your source package (and then you'll know you may have some changes to do in your package). Since the original debhelper, over a decade ago, did not have a compat level, the absense of a compat level signals compat level 1, which is far outdated now, and about to be unsupported. Hence the warning. The fix is simple: create a file debian/compat containing a single number: the compatibility level you're working with. It's best to use the most recent level which debhelper supports when you create your package, which as of this writing is level 9. Ignoring the compatibility level, if you're building a software package which uses a well-established build system, and you only build one binary package out of that, chances are pretty high that everything worked as expected. If not, you'll have more work. Building multiple packages requires that you tell debhelper somehow which file goes in which package. You can do this with a file debian/package.install, where package is the name of the binary package you're building. The install file is read by dh_install, one of many tools in the debhelper suite. You see, in the old days (before debhelper 7), debhelper was just a suite of tools, which required that you wrote a debian/rules file containing all the individual tools to be called in the correct order. This mode is still supported; in fact, even if you do use dh, you do, since all that tool really does is call the right tools in the right order; the real work is done by the invidual tools. They all have their own man page; to understand how dh_install chooses which file to put in which package, go read man dh_install. Go ahead, do it now; I'll wait. Back? Good. You've now learned that dh_install can install files either from the source directory (useful for packages containing only scripts or so), or from a directory debian/tmp. If you use an autotools-based software package, this is what dh will do for you. When you called dpkg-builpackage above, you may also have noticed that the output contained many lines starting with dh_, one of which said dh_install. As you may have guessed, dh echoes every debhelper command just before it will execute them. This allows you to look at the output, and see what's happening. For more detail, set the environment variable DH_VERBOSE to a non-zero value. I'm sure you'll have seen one or two debhelper tools that could make your package better. Go ahead, go and read their man pages to see what they do, and how they do it. Most of these will require you to create a file debian/package.toolname to specify details. In some cases, you may need to specify command-line arguments to the tool to get it to do what you want. In yet other cases, the tool won't support what you need it to do, and you'll have to do something manual. What to do now? The dh command line doesn't support adding extra commands easily. Does this mean you'd have to revert to old-style long, non-dh debian/rules files? Luckily, no. You can create an override target. If dh detects that you have such a target for a particular tool, it will call that target instead of the tool. This target's rules can then call the tool in question (or not), and add any command line arguments, or extra commands, as needed. An override target is a normal Makefile target with a name of the form override_dh_something, where dh_something is the name of the tool you wish to override. At this point, I'd reached almost the end of my two allotted hours, and a member of the audience asked how to make dpkg deal with configuration files. The answer is, you don't need to do anything! Not if you use debhelper, anyway; all you need to do is install the file in /etc. Since debian policy specifies that all files in /etc need to be configuration files and that no conffiles may be placed anywhere but in /etc, debhelper will automatically mark any file installed in /etc as a conffile, which will cause dpkg to ask the user what to do with changes to such files. Note that in Debian parlance, a conffile is not the same thing as a configuration file: a conffile is a configuration file that is part of the binary package (i.e., if you call 'dpkg --contents' on the .deb file, you'll see it in the output), whereas a configuration file is a file (any file, including files generated during or after installation of the .deb file on a system). Occasionally, this is also why some differences to configuration files are managed through debconf, while others aren't: the ones managed through debconf are non-conffile configuration files managed through ucf, whereas the others are conffiles. So in the simplest of cases, if you want to install a configuration file and you want to make sure it's protected against accidental overwrites by package upgrades, all you need to do is make sure it's installed to /etc; debhelper will do the rest. And that concludes this introduction. Please note it's only an introduction, not a full-blown tutorial; while this will allow you to get started, you may have to learn a bit more if you wish to eventually upload a package to Debian.

from the whinge of the day dept: I started a bzr branch of calibre about 2.5 hours ago because I wanted to see how difficult it would be to understand the code and make a few changes. The calibre Get Involved page warns that it can take about an hour .which is excessive to begin with and, worse, a huge understatement.

$ date ; ps u -Cbzr
Sat Apr 14 15:10:00 EST 2012
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
cas      14279  3.0  1.3 286836 215976 pts/3   S+   12:39   4:36 /usr/bin/python /usr/bin/bzr branch lp:calibre

It's still far from finished.

cas@ganesh:/usr/local/src/calibre$ bzr branch lp:calibre
You have not informed bzr of your Launchpad ID, and you must do this to
write to Launchpad or access private data.  See "bzr help launchpad-login".
1395260kB    65kB/s - Fetching revisions:Inserting stream:Estimate 178815/203940

a git clone of a much larger project would have been finished in mere minutes. WTF is bzr so horrendously slow? It's not my connection, I'm on an otherwise idle ADSL2 connection, that syncs about 14Mbps. i.e. capable of downloads of up 1.4 megabytes per second, not the 50-70kB/s that bzr is dawdling along at. It's not my CPU, an AMD 1090T hex-core overclocked to 3.7GHz (and almost completely idle) and since I have 16GB RAM, it's not lack of RAM either. Is there anything good about bzr that makes people actually want to use it? or is it just the association with ununtu and launchpad? maybe the purpose is to actively discourage casual involvement .you have to make a massive life commitment and run the gauntlet of tediously long waits before you can even look at the code. No wonder github is so popular. why is bzr so slow? is a post from: Errata

The other day, I was a bit puzzled over a seemingly simple task: Enable core files to be generated from a PostgreSQL instance running on Debian. That instance has unfortunately been segfaulting on occasion, but never left a core file.

Now in principle it is clear that

ulimit -c unlimited

is the incantation to get this done. But where do you put this? You could hack it into the init script, but that seemed a bit ugly, and I wanted a sustainable solution.

A useful thing in the meantime is to check the current settings. That information is available in /proc/$PID/limits with the PID of the postmaster process (or any child process, really), and it looked like this to begin with:

Limit                     Soft Limit           Hard Limit           Units     
Max cpu time              unlimited            unlimited            ms        
Max file size             unlimited            unlimited            bytes     
Max data size             unlimited            unlimited            bytes     
Max stack size            8388608              unlimited            bytes     
Max core file size        0                    unlimited            bytes     
...

Use sudo grep core /proc/$(sudo cat /var/run/postgresql/8.4-main.pid)/limits if you want it automated.

So it's good to know that we only need to set the soft limit.

One way to configure this properly would appear to be in /etc/security/limits.conf. There you can add a line like

*               soft    core            unlimited

to enable core dumps globally. I'm not actually sure whether that would work if the service is started during the boot without PAM. In any case, I didn't want to enable core files globally; who knows what that would lead to.

One could replace the * by a user name, such as postgres, and then enable pam_limits.so in /etc/pam.d/su. But the postgresql init script in Debian is nested about four levels deep, so it wasn't clear whether it called su at all.

Now as it turns out, the init script ends up changing the user using this Perl code:

$) = $groups;
$( = $gid;
$> = $< = $uid;

(see change_ugid in /usr/share/postgresql-common/PgCommon.pm), so the whole PAM line of thought wasn't going to work anyway. (Other packages such as pgbouncer and slony1 do got through su, so that would be a solution for those.)

The way to solve this is the pg_ctl -c option, which sets the soft limit for core files to unlimited. And the way to pass this option through the init script maze is the file /etc/postgresql/8.4/main/pg_ctl.conf, which should contain a line like this:

pg_ctl_options = '-c'

Then restart postgresql, and check /proc/$PID/limits again:

Limit                     Soft Limit           Hard Limit           Units     
Max cpu time              unlimited            unlimited            ms        
Max file size             unlimited            unlimited            bytes     
Max data size             unlimited            unlimited            bytes     
Max stack size            8388608              unlimited            bytes     
Max core file size        unlimited            unlimited            bytes     

OK.

Another thing that's recommendable in this context is to change the core file names to have a unique element, so that if multiple backends crash before you can take a look, they don't overwrite each other's core files. The core(7) man page explains the configuration options; I went with this sysctl setting:

kernel.core_pattern = core.%e.%p

which includes process name and PID. The PID file still ends up in the data directory of the PostgreSQL instance, which could also be changed, but I didn't find it necessary.

Stick the above line in /etc/sysctl.d/local.conf and reload with

service procps force-reload

I actually use a setting like that on all machines now; it's just nicer.

OK, and now I'll wait for the next core file. Or not.

Normally people aren't stupid or evil enough to demand that I not use a word at all. On the occasions that they are that stupid or evil, typically only one word is singled out. Thus, when someone demonstrates enough unwisdom to give me a list, I feel the need to share publicly:

• moist
• foodie
• panties
• partner in crime

Seriously.

I ve just updated the Debian Packaging Tutorial. This new version addresses a few comments and questions I received over the past months. Note that there are also french and spanish versions of the tutorial, and I m of course open to adding other translations. The tutorial can be found in the packaging-tutorial package (PDF files are in /usr/share/doc/packaging-tutorial/), or on www.debian.org (see links above).

It take all kind of contributions to create a Linux distribution like Debian Edu / Skolelinux, and this time I lend the ear to Justin B. Rye, who is listed as a big contributor to the Debian Edu Squeeze release manual. Who are you, and how do you spend your days? I'm a 44-year-old linguistics graduate living in Edinburgh who has occasionally been employed as a sysadmin. How did you get in contact with the Skolelinux/Debian Edu project? I'm neither a developer nor a Skolelinux/Debian Edu user! The only reason my name's in the credits for the documentation is that I hang around on debian-l10n-english waiting for people to mention things they'd like a native English speaker to proofread... So I did a sweep through the wiki for typos and Norglish and inconsistent spellings of "localisation". What do you see as the advantages of Skolelinux/Debian Edu? What do you see as the disadvantages of Skolelinux/Debian Edu? These questions are too hard for me - I don't use it! In fact I had hardly any contact with I.T. until long after I'd got out of the education system. I can tell you the advantages of Debian for me though: it soaks up as much of my free time as I want and no more, and lets me do everything I want a computer for without ever forcing me to spend money on the latest hardware. Which free software do you use daily? I've been using Debian since Rex; popularity-contest says the software that I use most is xinit, xterm, and xulrunner (in other words, I use a distinctly retro sort of desktop). Which strategy do you believe is the right one to use to get schools to use free software? Well, I don't know. I suppose I'd be inclined to try reasoning with the people who make the decisions, but obviously if that worked you would hardly need a strategy.

I m back from one of the best experiences a father can have a whole day with two happy boys. I took Jacob (5) and Oliver (2) camping with me out by our creek. This was the first time we d camped there, and also the first time I d taken the boys camping without Terah along. So there were some unknowns, but it worked out great. When we got out there, I started to get the tents set up. The boys were interested, but pretty soon invented some games. A large nearby tree with plenty of low branches on its trunk became their locomotive, and certain sticks made the train go forward or backward, whistle, or ding its bell. This was good for quite some entertainment. Another nearby tree, near the bank of the creek, had some erosion near it. Combined with its roots, this made some natural steps. Jacob named some the enter steps and others the exit steps , and I sure heard about it if I walked the wrong way on the exit steps. We then gathered up sticks and the things we needed to build a campfire. We cooked up brats and zucchini. Although it was later than usual for supper, they loved it just the same. After that, we made smores for dessert another thing they loved. Then, one of the big highlights: sleeping in tents and sleeping bags. I had showed them the sleeping bags earlier, and they were excited to try them out. Morning was beautiful when the sun came out, it was shining right on the heavy dew on the ground, making the grass shine brightly. It s not every day that they get to start their morning slowly waking up by a warm fire. They were content to sit for quite awhile while I got things going for breakfast. It was chilly outside, so I helped them change clothes by the fire where. I then cooked them some scrambled eggs which, despite the lack of salt and pepper, seemed so much better than normal to the boys and then we went exploring. I took them to some areas with erosion, which Jacob called the big holes in the ground. It s really quite beautiful in spring, which this cellphone photo completely fails to capture. The boys loved climbing up and down these areas, some of which were quite tall. They discovered different kinds of rock on the way up and down, and with my help avoided discovering too much of the mud at the bottom. We hiked back to our camping spot through grass almost as tall as Oliver much to his delight and then after warming up by the fire for a bit, went off in the other direction. There is a grove of trees by the creek over there, which surprise became another train. Here are the boys explaining how it works. <iframe allowfullscreen="allowfullscreen" frameborder="0" height="315" src="https://www.youtube.com/embed/43EcEK8F_ic?rel=0" width="560"></iframe> They helped pack things back up, too. Actually, it took some convincing to get Jacob to not pull up all the stakes for the tent before I was ready for them. Things didn t go perfectly, but then, they never do, and that was OK with everyone. Camping is an adventure, and it wouldn t be an adventure if you knew every detail beforehand. It is rare in life to be able to think that I have enough time to do anything the boys might want to do. Spend half an hour pretending a tree is a train sure, no problem. Today Oliver asked to go camping again, and was a bit disappointed when I didn t agree to go camping again right this minute, today. Jacob said, we had an EXCELLENT time and gave me hugs thinking about it. I have a lot of happy memories about the creek. We camped at the same spot where I went fishing or camped as a child. There have been family gatherings and even a birthday party out there. The boys and I have enjoyed a hike or a wagon ride to the area, but as I learned, nothing could possibly match the excitement of camping there. It is wonderful to add another happy memory of a time at the creek. And it s even better to see another generation of Goerzens discover that there s a lot of fun to be had down by the creek.

AoE is one of the protocols supported by Linux to access storage via network. It uses plain Ethernet for communication and includes a discovery mechanism to find all available targets. I use it to provide disk space to VMs running on different machines. Next step is to boot via AoE. It is no real problem to use AoE in running systems. However with some help it is even possible to actually boot disk-less machines via AoE. The PXE implementation iPXE provides the AoE support to actually boot from. I will describe the necessary parts.

I met Francesca in Debconf 11 in Banja Luka. If I recall correctly, it s Enrico Zini who introduced me to her, because she was the madamezou (her IRC nickname) who started to get involved in the publicity team. Since then and despite having a bachelor thesis to complete she got way more involved and even gained official responsibilities in the project. Before starting with the interview, I wanted to mention that Francesca is drafting a diversity statement for Debian I was expecting the discussions to go nowhere but she listened to all objections and managed to improve the text and build a consensus around it. Thank you for this and keep up the good work, Francesca! Rapha l: Who are you? Francesca: My name is Francesca, I m 30 and I studied Social Sciences. Currently I live in Italy but I m planning to go abroad (not a lot of jobs here for geeky social scientists). Apart for Debian and FLOSS world in general, I have unrestrained passions for chocolate; zombie movies; sci-fi; zombie books; knitting sewing crafting and DIY in general; zombie videogames; bicycles; pulling apart objects to look inside them; splatter B movies, David Foster Wallace s books, playing trumpet, and did I already mentioned zombies? Days are too short for all this stuff, but I try to do my best. Raphael: How did you start contributing to Debian? Francesca: Some years ago I was stuck in bed for literally some months, due to a grave series of migraine attacks. I wasn t able to do anything: no social life, no books or television. So, I decided to turn on the laptop and do something constructive with it: I was already a Debian user and it seemed quite logical to me to try to give back to the community. I am not a coder and I ve not studied Computer Science, so my first step was to join an Italian Debian on-line community (Debianizzati) and help with tutorials, users support, wiki management. In a couple of months I learnt many things: helping other users with their problems forces you to do lots of research! My first contributions to the Debian project were mostly translations of the main website. Translators are the perfect typos spotters: they work so precisely on the text to be translated that they finish to do a great QA job. This is how I ve started to contribute to the Debian website: with very simple things, fixing typos or wrong links or misplaced wml tags. I still remember my first commit to the website: the idea was to undercase some tags, but it ended up that I misplaced some of them and in addition I fixed them only in the English page and not on the translations as well. When after a couple of minutes, K re Thor Olsen a long time contributor of the team and now webmaster reverted my commit, I felt so stupid and full of shame. But, to my great surprise, no one treated me like an idiot for that error: Gerfried Fuchs, one of the guru of the team, replies me in a really helpful and polite way explaining what I did wrong and how to do things correctly. I think this episode was a turning point in my Debian life: there s this idea that Debian Developers are just a bunch of arrogant assholes and maybe it was true in the past, but for my experience they are not. Well, at least the ones I met and work with .

To my great surprise, no one treated me like an idiot for that error.

Since then, I joined the WWW team and helped them apply the shiny new design provided by Kalle S derman. A lot of work was done during the week immediately before the release of the new website. Oh that was a week! We worked night and day to have the new design ready for February 6th, and it was fantastic when we finally published it, simultaneously with the release of Squeeze. At the same time, I started to contribute more actively to the Debian Publicity team, not only translating news but also writing them. It can sound scary for a non native English speaker to write something from scratch in English, but you have to keep in mind that your text will be reviewed by native speakers before being published. And we have some fantastic reviewers in the English localisation team: particularly Justin B Rye, who is tireless in his effort and more recently Moray Allan. I think I m particularly lucky to work with all these people: there s a special mood in both Publicity and WWW team, which makes you feel happy to do things and at the same time pushes you to do more just because it s fun to work with them sharing jokes, ideas, rants, patches and hugs. Rapha l: I believe that you have been trough the new member process very quickly. You re now a Non-Uploading Debian Developer. How was the experience and what does this mean to you? Francesca: Becoming a Debian Developer was not so obvious for me, because I didn t need to be a DD for the work I do in Debian. For instance, I don t maintain packages, so I had no reasons to want to become a DD in order to have uploading rights. For a while I didn t really feel the necessity of being a DD. Luckily, some people started to pester me about it, asking me to apply for the NM process. I remember Martin Zobel-Helas doing this for an entire week every single day, and Gerfried Fuchs doing it as well. Suddenly, I realized that people I worked with felt that I deserved the DD status and that I simply had thought I didn t. As a non coder and a woman, there probably was a bit of impostor syndrome involved. Having people encouraging me, gave me more confidence and the desire to finally become a DD. And so I did. The process for non uploading DD is identical to the one to become an uploading DD, with one exception: in the second part of the process (named Tasks and Skills) instead of questions about how to create and maintain packages, there are questions about the non packaging work you usually do in Debian. The general resolution which created the possibility to become a non uploading DD gave us a chance to recognize the great effort of Debian contributors who work in various area (translations, documentation, artworks, etc.) that were not always considered as important as packaging efforts. And this is great because if you are a regular contributor, if you love Debian and you are committed to the project, there are no reasons to not be an official member of it. With regards to this, I like the metaphor used by Meike Reichle in her recent talk about the Debian Women Project (video recording here):

a Debian Developer status is a lot like a citizenship in a country that you re living in. If you live in a country and you don t have citizenship, you can find a job, buy a house, have a family [...] but if this country at any point in time decides to go into a direction that you don t like, there s nothing you can do about it. You are not in the position to make any change or to make any effect on that country: you just live there, but there s no way that you can excercise influence on the people who run this country.

Rapha l: You recently joined the Debian Press Team. What does it involve and how are you managing this new responsibility? Francesca: The Press Team is basically the armed wing of the Publicity Team: it handles announcements that need to be kept private until the release, moderate the debian-announce and debian-news mailing list and maintain contacts with press people from outside the project. The real job, so, is done within the Publicity Team. The most important part of our work is to write announcements and the newsletter: while the newsletter is published bi-weekly, the announcements need to be write in a shorter timeframe. Localization is really important in spreading Debian word, so we work closely with translators: both announcements and DPN are usually translated in four or five different languages. The publicity work could be stressful, as we have strict deadlines, we need to take quick decisions and often do last-minute changes. Personally, I like it: I work better under pressure. But I know that is sometimes difficult for contributors to accept that we can t debate endlessly on details, we have just to go on and do our best in a given timeframe.

The publicity work could be stressful, as we have strict deadlines, [ ]. Personally, I like it.

Raphael: You re one of the main editor behind the Debian Project News. What s the role and scope of this newsletter? Francesca: Debian Project News is our beloved newsletter, direct successor of the Debian Weekly News founded by Joey Hess in 1999 and later kept alive by Martin Schulze. In 2007, Debian Weekly News was discontinued but in 2008 the project was revived by Alexander Reichle Schmehl. The idea behind DPN is to provide our users an overview of what is happening inside and outside the project. As the core team of editors is formed by three people, the main problem is to be able to collect enough news from various sources: in this sense we are always glad when someone points us to interesting blogposts, mails and articles. DPN is also a good chance for non coders to contribute to Debian: propose news, write paragraphs and review the draft before the publication are quite easy tasks but very useful. English native speakers can do a proofread (as no one of the main editors is a native speaker) while others can always translate DPN in their native language. People who want to help us can take a look at our wiki page.

DPN is also a good chance for non coders to contribute to Debian.

Just yesterday I realized that since January we don t miss or delay an issue: so I d like to thank the fantastic team of editors, reviewers and translators who made it possible. The team is now working on another way of spreading Debian s message: a long-time project is finally becoming real. Stay tuned, surprise arriving! Raphael: You re trying to organize IRC training sessions but that doesn t seem to take off in Debian, while it s quite common in the Ubuntu community. How do you explain that? Francesca: I m not sure about it: both Debian users and contributors seemed to appreciate this initiative in the past. I was quite surprised by the amount of Debian members present during the various sessions and by the amount of interesting questions asked by the users. So the only reason I can think about is that I need to put more enthusiasm in convincing the teams to do it: they need more encouragement (or to be pestered more!). I, for myself, think that IRC training sessions are a great way to promote our work, to share our best practice, to talk about our project to a wider audience. And I ll sure try to organize more of them. Help, suggestions, ideas are really welcome! Raphael: If you could spend all your time on Debian, what would you work on? Francesca: There is a project I d like to give more love, but I always end up without the time to do it: the debian-community.org project. Back in 2007, Holger Levsen founded it with the aim of reducing the gap between Debian contributors and Debian users, giving all an opportunity to contribute, share ideas and more. The project was discontinued and I d really like to revive it: in these years various things have changed, but I think that the core idea of having a node to connect existing local communities is still good and doable. In Debian we don t have the wide and well articulated local infrastructure present in other distributions (Ubuntu, particularly, but also Fedora): even if I don t like too centralized structures, I think that a better connection between the project and local groups of users and on-line communities would be a step forward for the project. Being part of the Events Team, I m aware of how much we need to improve our communication with local groups. An example is the events organization: sometimes, Publicity and Events teams even don t know about regional Debian related events (like booth at conferences, workshops, talks, install parties, etc) and this is a shame because we could offer a lot of help in organizing and promoting local events. What we lack is better communication. And debian-community.org project could give us exactly this. Could be a cluster of local groups, a platform for events organization and even a useful resource for newbies who want to find a local group near them. I started some effort in this sense, sending a proposal about it, working on a census of Debian local groups. Any help is appreciated! I m really curious to see how many Debian communities (from all around the world and the web) are out there, and I d love to have members from these communities better connected with the Debian Project. Raphael: What s the biggest problem of Debian? Probably the bikeshedding feticism of almost all of us. It s the other side of the coin of Debian s commitment to technical excellence and our perfectionism, but sometimes it leads just to endless discussions about details, and it is a blocker for various initiatives. In Debian, you have to be really patient and in a way stubborn to push some changes. This is frustrating sometimes. On the other hand, I really appreciate how people take some times to think to each proposals, give some feedback and discuss about it: the process could be annoying, indeed, but the result is often an improvement of the initial proposal. Raphael: Is there someone in Debian that you admire for their contributions? Most of my teammates are simply brilliant and adorable and hard-working. But I have to admit that I particularly admire David Pr vot: beside being a webmaster he does a lot of things, from French translations to DPN editing. All his contributions have a great quality and he s able to push you always further in doing things and doing them better. He is a good example of how I d like to be as contributor: smart, tireless, friendly.

---

Thank you to Francesca for the time spent answering my questions. I hope you enjoyed reading her answers as I did. Note that older interviews are indexed on wiki.debian.org/PeopleBehindDebian.

Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Google+, Twitter and Facebook.

3 comments Liked this article? Click here. My blog is Flattr-enabled.