These articles cover my way to DebConf 11 through Hrvatska and Bosna i Hercegovina. After telling my initial plans to go by train (mostly) and bus (where it couldn't be avoided) on IRC, I was warned that public transport is quite bad and unreliable. Also, as I live in M nchen, of course this part of Europe was always known as "near" and "could be visited any time" (which means "one never gets to it"; and I can still remember the time when it was Yugoslavia - there are and always were many people living here from that part of Europe; in fact, it's nearer than some parts of Germany). I plan to publish more parts of my way within the next days. Already at home I also learned that most trains in Hrvatska (and all in Bosna i Hercegovina) are not part of the usual train information system, so it was a bit more advanced to find out the appropriate connections. And in both countries there are only a few trains running, so one shouldn't miss a train ("few" means e.g. two per day and direction - but one at most unappropriate times, so really only one suiteable). The first day saw me boarding the Suburban train (S-Bahn) at my usual station, changing platforms and trains at M nchen Ost station and then I was sitting in a train to Zagreb. Nothing strange there, except that the coach I had an seat reserved in was missing. I learned later on that it happens more often that the coach from Serbia is not there because it's technically too unfit to send it to Germany -- and usually, there will be more coaches added in Ljubljana. Border checks were uneventfull but at the slovenijan border my passport was stamped (not sure why, didn't happen on the way back).
Train in sterreich After arriving in Zagreb and dropping off my luggage in the hotel, I first got some Kunas and then bought my ticket to Split for the next day (as a direct ticket from M nchen to Split was not available). After having done that, I took a brief tour through Zagreb until it became dark, with visiting some of the tourist places.
Zagreb

TL;DR: Since a few months Debian also hosts a Gobby server. You can find it at gobby.debian.org. To use it, install gobby-0.5.

Gobby is a realtime collaborative editor, much like Etherpad, but as a standalone desktop application. (It's also open source since the beginning.) It resembles gedit somewhat. In retrospect plugging into gedit would've made more sense than to develop yet another editor.

Sadly there's a catch: Gobby had multiple iterations at getting its protocol right. So there are two incompatible versions: Gobby 0.4 and Gobby 0.5. But to confuse you, Gobby 0.4.9x is currently called Gobby 0.5. The lead developer wants to get self-hosting (i.e. the one-click creation of a server) back into the application before he calls it stable.

So to use the aforementioned server you need to apt-get install gobby-0.5, invoke gobby-0.5 and type gobby.debian.org into the "direct connection" field in the lower left bottom. This will give you a document tree on the left, where you can create new documents and folders. Please don't be destructive.

If you have a problem, if no one else can help, and if you can find them, you might contact the admins at admin@$service.

Four and a half years after Sam Hocevar started a draft proposal on the Debian Wiki, we've published revision 1.0 of the machine-readable format for debian/copyright files. The format (as DEP-5) has been in widespread use for some time, but there have been multiple versions of the format and multiple transitional versioned URLs. Everyone can now update to the same version of the document and use a stable format URL. Below is the text of the annoucement that I just sent to debian-devel-announce. Version 1.0 of the machine-readable format for debian/copyright files (the culmination of the DEP-5 process) has now been published. The canonical URL (and also the URL to use in the Format field in such files) is:

http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

For those who have adopted various iterations of the DEP-5 format for your packages, please consider updating to this format the next time you revise your package. Use of this format in Debian packages is optional. Thanks to all of the people who have contributed to this work over its long evolution. Particular thanks go to Steve Langasek, Charles Plessy, and Lars Wirzenius, who kept this document moving through its extended DEP discussion process, and Sam Hocevar, who started this work in 2007. The copyright format specification is now being maintained as part of the debian-policy package and will follow the same update process that's used for other parts of Policy. See:

http://wiki.debian.org/PolicyChangesProcess

for that process. For this specification, we're trying something new for Debian technical policies. This document is versioned, and older versions of the specification will be maintained to not invalidate older references in copyright files that have not been moved to newer versions. This is similar to the way that specifications are handled by some other projects, particularly the freedesktop.org standards. The plan, going forward, is that informative changes (changes that do not change the requirements or the contents of compliant copyright files) will be made following the same relaxed procedure as other informative changes to Policy, and new versions will only informative changes will be published with the same version number. So the existing 1.0 document may receive further improvements in wording, examples, or similar changes that don't modify its meaning. Normative changes (changes that change requirements for compliant files, which includes addition of new standardized license short names) will follow the normative Policy change process, including formal seconds. Once normative changes are accepted, the next release of this specification will receive a new version number (1.1, for example). The previous version, prior to the normative changes, will be frozen, and from that point forward will not be changed except as required to continue to publish it. This includes further informative changes. We will continue publishing these frozen older versions of the standard on www.debian.org and in the debian-policy package for some time: possibly forever, and at least as long as they're still referred to by packages distributed by the project. The hope is that this will provide a good balance between specification stability, editing for clarity, and specification changes to meet changing requirements, while not invalidating the URLs in older files and while continuing to provide the information required to interpret older files.

This might be interesting if you are using git-annex with one default remote and don't modify files once added:

git config [--global] alias.annex-push \
'!git pull && git annex add . && git annex copy . --to $REMOTE --fast --quiet && git commit -a -m "$HOST $(date +%F--%H-%M-%S-%Z)" && git push'

Optional parameters include --global (you will need to name all your remotes the same for this) and --fast (don't use this if you modify files). The timestamp is not-quite-ISO-8601, but it\'s human-readable and trivial to parse for computers.

Hello I ve (finally) released a new version of Config::Model. The main change for users is the deprecation of the config-edit program in favor of cme program. Instead of using options, this cme uses command keywords like git, so users will have more possibilities while typing less. bash completion is provided for cme command and options. Following Debian annoucement regarding the recommended format of Debian copyright file (aka DEP-5), I ve also updated the URL in Debian copyright model. If your package is already in a DEP-5 format, you can update the URL with this simple command: cme fix dpkg-copyright Check the wiki on github for more example of cme command. All the best

Removing alsaconf was one of the very few rewarding moments of these ten years of taking care of ALSA in Debian. Not everyone agreed back then, and we still get some retaliation. :)

Date: Thu, 23 Feb 2012 02:59:31 +0100
From: <CENSORED>
To: jordi@debian.org
Subject: sabotage!
the removing of alsaconf without working(!) alternatives  was (AND IS!)  an
act of sabotage against millions of debian/alsa - users who needs stable
productive systems
you and all those proponents of removing this still needed alsaconf - program
will have to take the responsibility in front of an (us-) court for damages in
millions of dollars - amounts (lost man hours) all over the world
only a short while and we will have enough sponsors and witnesses around the
globe (and a very specialised, international labouring bureau of advocates) to
go to the court for prosecution.
we will not tolerate such an betray ("stable"? - do you believe, we're
fools??!!) against broad sections of the population and against the spirit of
free software!
it will be intresting to investigate, in whoms interests you've done so and
who the beneficiaries are ...
L.B.
conductor, publicist, whistleblower

If you want to enable all Lintian tags, just remember the phrase:

Some sponsors are evil and pedantic

Or on the command-line:

 $ lintian -EvIL +pedantic ...

It works for Lintian 2.5.5 (and newer), which handles pedantic like other severities. If you need help understanding the tags, you can add an extra i (-i) to evil . That being said, remember that experimental (-E) and pedantic (-L +pedantic) tags are what they are for a reason. Also quite a few people will probably find verbose (-v) too noisy. However, leaving any of them out would have ruined the mnemonic. Of course, you can also ask Lintian to enable all tags via your lintianrc file. Here is a quick-start:

display-info = yes # or no
display-experimental = yes # or no
pedantic = yes # or no
verbose = yes # or no

Consider the following foo.c source file:

extern int bar() __attribute__((weak));
int foo()
return bar();


And the following bar.c source file:

int bar()
return 42;


Compile both sources:

$ gcc -o foo.o -c foo.c -fPIC
$ gcc -o bar.o -c bar.c -fPIC

In the resulting object for foo.c, we have an undefined symbol reference to bar. That symbol is marked weak. In the resulting object for bar.c, the bar symbol is defined and not weak. What we expect from linking both objects is that the weak reference is fulfilled by the existence of the bar symbol in the second object, and that in the resulting binary, the foo function calls bar.

$ ld -shared -o test1.so foo.o bar.o

And indeed, this is what happens.

$ objdump -T test1.so grep "\(foo\ bar\)"
0000000000000260 g DF .text 0000000000000007 foo
0000000000000270 g DF .text 0000000000000006 bar

What do you think happens if the bar.o object file is embedded in a static library?

$ ar cr libbar.a bar.o
$ ld -shared -o test2.so foo.o libbar.a
$ objdump -T test2.so grep "\(foo\ bar\)"
0000000000000260 g DF .text 0000000000000007 foo
0000000000000000 w D *UND* 0000000000000000 bar

The bar function is now undefined and there is a weak reference for the symbol. Calling foo will crash at runtime. This is apparently a feature of the linker. If anyone knows why, I would be interested to hear about it. Good to know, though.

I've just uploaded version 3.9.3.0 of Debian Policy. The really big change in this version is the 1.0 version of the copyright format specification, but that will get a separate announcement once the www team has had a chance to put it in place on the web site. There are a bunch of other fixes, though, including some normative changes. Here's the upgrading checklist (duplicated from my announcement, but formatted a bit prettier):

2.4

New archive sections education, introspection, and metapackages added.

5.6.8

The Architecture field in *.dsc files may now contain the value any all for source packages building both architecture-independent and architecture-dependent packages.

7.1

If a dependency is restricted to particular architectures, the list of architectures must be non-empty.

9.1.1

/run is allowed as an exception to the FHS and replaces /var/run. /run/lock replaces /var/lock. The FHS requirements for the older directories apply to these directories as well. Backward compatibility links will be maintained and packages need not switch to referencing /run directly yet. Files in /run should be stored in a temporary file system.

9.1.4

New section spelling out the requirements for packages that use files in /run, /var/run, or /var/lock. This generalizes information previously only in 9.3.2.

9.5

Cron job file names must not contain "." or "+" or they will be ignored by cron. They should replace those characters with "_". If a package provides multiple cron job files in the same directory, they should each start with the package name (possibly modified as above), "-", and then some suitable suffix.

9.10

Packages using doc-base do not need to call install-docs anymore.

10.7.4

Packages that declare the same conffile may see left-over configuration files from each other even if they conflict.

11.8

The Policy rules around Motif libraries were just a special case of normal rules for non-free dependencies and were largely obsolete, so they have been removed.

12.5

debian/copyright is no longer required to list the Debian maintainers involved in the creation of the package (although note that the requirement to list copyright information is unchanged).

copyright-format

Version 1.0 of the "Machine-readable debian/copyright file" specification is included.

mime

This separate document has been retired and and its (short) contents merged into Policy section 9.7. There are no changes to the requirements.

perl

Packages may declare an interest in the <perl-major-upgrade> trigger to be notified of major upgrades of perl.

virtual

ttf-japanese- mincho,gothic have been renamed to fonts-japanese- mincho,gothic .

Please review and update your packages as necessary the next time you make an upload.

Nagios or Icinga users probably know the problem that neither the default plugin packages (nagios-plugins-basic and -standard) nor the few other plugin packages ship all the plugins you need to monitor your hardware and software properly. And unless you have puppet, cfengine or some other automation software, you probably just start searching plugins on Nagios Exchange, MonitoringExchange or some other machines you are monitoring already. Your problem shall be solved! nagios-plugins-contrib passed NEW today. It is a collection of various useful plugins, maintained within the Debian Nagios Maintainer Group. So far it contains only 6 plugins (check_email_delivery, check_ipmi_sensor, check_lm_sensors, check_memcached, check_raid, check_rbl), but more are going to come. To have your favorite plugins added to the package we would like to encourage you to send pull requests, either using github, alioth or your personal repository. Please keep in mind that you'll be added to the Uploaders of the package automatically to ensure that you keep your plugin updated and in a good shape. See debian/README.source for some instructions on adding new plugins. Unmaintained plugins will be removed! Of course you can also submit bug reports to have a new plugin added, but you have to convince somebody to maintain it for you (or that he wants to use the plugin and needs to maintain it therefore ). We might also also have a similar package in contrib as a lot of commonly used plugins require non-free software, so don't hesitate to prepare plugins for inclusion in such a package and let us know! Suggestions and ideas for improvement are always welcome. And so is help to maintain the packages!

phpMyAdmin is quite popular software (to give some numbers let's mention 10000 downloads daily on SourceForge.net or 122685 reports in Debian's popcon) and as such is quite attractive target for various scripted attacks. If you run phpMyAdmin installation somewhere you should really make sure it is enough secured, so that these script kiddies don't get through. In past month I've looked at what kind of attacks are these guys trying and in all cases these are pretty old vulnerabilities, some of them fixed years ago. So the first thing you should do is to update. It is always good to run latest stable version, but in case you can not for whatever reason, try at least taking the most important fixes and using them. In ideal world your distribution would do this job for you, but in case it did not, you can for example take patches from Debian, which is pretty good at taking our patches (surprisingly it is not much related to my involvement there). To check which patches they have applied you can use excellent patch-tracker tool, which exposes patches from all released packages. To give you overview of which issues are mostly being attempted to exploit by script kiddies right now, here is the list:

• PMASA-2010-3 - yes, more than two years old, but still unpatched in some places
• PMASA-2011-5 - "only" half year old
• PMASA-2011-6 - only useful together with wrongly configured PHP

If you have fixed these, you should be pretty safe for now, but follow our security announcements for possible future issues (you can use RSS feed or subscribe to news mailing list, where all security issues are announced as well). However there are more things you can do to keep you safer:

• remove setup directory from phpMyAdmin, you will probably not use it after initial setup
• prevent access to libraries directory from browser, as it is not needed, supplied .htaccess file does this
• properly choose authentication method - cookie is probably the best choice for shared hosting
• in case you don't want all MySQL users to be able to access phpMyAdmin, you can use AllowDeny rules to limit them
• consider hiding phpMyAdmin behind authentication proxy, so that MySQL credenticals are not all users need to login

So these are the basic steps which will help you against possible compromise, I might return to some of these in more details in future posts.

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

The meeting was as long as the kernel changelog, the decision was as difficult as a Debian release, but in the end Le Camp has won in the voting 5 to 4. It was lucky that one member of the 10 man committee was not present or we could have had a tie, just like there was one in the first round of voting. Well, congratulations to the poor sods of the Swiss team, who will now have to fulfil what they promised and also all the small things that everyone always forgets that also need to be done for every Debconf! I think that I will try again for 2015, but before that we will try to get a few people from Latvian community to go to Debconf13 to get the Debconf and Debian experience and exposure. Meanwhile, it looks like I will be skipping this years Debconf12 it is very far away for me and as I could not find a reasonable business rationale for me being there, it would be a far and expensive vacation for me. I don t think there is enough benefit from me being there to ask for any Debian funds for this either, especially hearing how tight money is this year. So if you re going, make sure to take a camera and take a bunch of pictures, so we at home can see it too

Now is the point in the Debian release cycle where I usually try to go through my packages and bring them generally up to date. In case other people are doing the same thing, here are a few new facilities or techniques that I'm rolling out across my packages. (This is apart from the obvious stuff, like multiarch where appropriate and debhelper 9, and the older stuff, like using dh.)

• dh-autoreconf is a new helper tool that runs autoreconf on the package during the build and cleans up properly afterwards. I've started switching all of my packages that use Autoconf and Automake and can use autoreconf over to it. (Some upstreams have more complex scripts that have to be run to regenerate the build system.) It plugs in trivially as a dh add-on, and even adds support for --as-needed (see below). I'm doing this even for packages where I don't patch the build system, on the grounds that rebuilding everything from source, including the build system, is a good idea. It also means that I can patch the build system when I need to without having to add additional machinery at the time.
• Linking with --as-needed. As I build new packages, I'm looking for anything that has warnings about generating unnecessary dependencies and adding --as-needed to the linker flags. The combination of dh-autoreconf and the new dpkg-buildflags support makes this trivial to do for most packages. Just add something like:

      export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed

  to debian/rules. It's worth being aware that --as-needed can break some unusual uses of special cases around shared library loading, but I've not run into any of those cases with any of the software that I package.
• dpkg-buildflags comes essentially for free with debhelper 9, but it's worth mentioning that, as mentioned above, it's a really easy way to add additional flags. And if you have to pass in flags via some other mechanism, use dpkg-buildflags to get the default flags.
• Once you're up to debhelper 9 and are using dpkg-buildflags, adding hardening flags is easy. You get the default ones for free, and that's a pretty good start. (Install hardening-includes and use hardening-check to check the status of the binaries built by your package.) I always add at least hardening=+bindnow to DEB_BUILD_MAINT_OPTIONS (set with export in debian/rules), since the minor speed hit at startup doesn't matter for anything that I'm packaging. (It might for something like ls that runs all the time.) I usually try to also add +pie, but be careful of that. Libtool will cope correctly with it and switch it back to PIC for shared libraries, but other shared library build processes may not. And it doesn't always work; for example, gnubg (GNU Backgammon) just immediately dies if built PIE, for reasons that I didn't track down.
• If, like me, you maintain your packaging in Git without using a separate tool that exports a patch series, and therefore use the single-debian-patch option, there is new support for applying that option only to your build as the maintainer but not to any other build that people do of your source package. This is good, since it means that any NMU diffs will be kept separate from your maintainer diff because they'll get the version of the NMU package added. To get this behavior, move debian/source/patch-header to debian/source/local-patch-header and debian/source/options to debian/source/local-options (assuming that's your only option; otherwise, you might need to split it). Then the patch header and options won't be included in the generated source package and hence won't apply to NMUs or other packaging changes based on the source package in the archive instead of on the packaging repository.

It's also worth mentioning that Ubuntu was responsible for breaking a lot of ground here. Due to bug reports and patches submitted from Ubuntu, several of my packages already had hardening build flags and --as-needed issues fixed before this round of packaging refresh, which made adding these features much easier than it would be otherwise.

Ben mentions he left Google Reader and went back to Liferea, but mentions a series of bugs that keep him from being happy. After pondering it a bit, a couple of months ago I also left Google Reader, but I turned to a free webapp: rssLounge aggregator. Although it does not fully cover Ben's wishlist (I'll get to it now), I am happy using it as it covers my main need: Being able to read my stuff from just about everywhere, without installing even a ssh client (that would make public Windows machines a liability for me, as they could sniff my keystrokes while authenticating to my ssh server). So, for me, a webapp is basically a must. Well, as for Ben's list:

1. MAY be a desktop or web application.
   Check. Well, I don't know what would fail this :)
2. If it's a web application, it MUST be reasonably secure, e.g. it must not be written in PHP.
   Fail. It's PHP. And that's my main reason for not uploading it to Debian I use and enjoy this app every day, but it has some bugs I don't really feel like looking into. And yes, maintaining PHP code is ugly.
3. If it's a web application, it MUST allow for multiple independent users on the same server.
   Don't really remember, I set it up just for myself. But in any case, you could install a different instance per user?
4. If it's a desktop application, it MUST embed a browser engine (presumably Gecko or WebKit) so I can follow links without having to switch windows.
   N/A
5. MUST support organisation of feeds by folders or tags, including combined item lists.
   Pass.
6. MUST keep track of which items have been read.
   Pass.
7. MUST support a global 'unread items' list. SHOULD only remove items from this list when I refresh it, not as soon as I move away from an item.
   Pass. In fact, given that storage is cheap, I have set it to never expire old entries. I don't know if it will ever be useful, but as long as it does not hurt me...
8. SHOULD support a three-pane (folder/list/item) view or something similar. Google Reader's list view with expanding items is perhaps even better, though it means links must be opened in a separate tab.
   It's more like Google Reader's
9. SHOULD support folder and item navigation by keyboard.
   Pass.
10. SHOULD have some way to flag/bookmark items for later attention.
    Pass.
11. If it's a desktop application, it SHOULD have some sort of download manager to support podcasts.
    N/A

So, Ben, with only one (big) fail, it might be a good candidate for you. PS- And hard as it might seem, I am leading an almost-Google-free life now! :) But don't let them hear this, as we want them to keep sponsoring Summer of Code and DebConf.

Intro RAID sucks, and so do all other Free alternatives in the Linux world. Having been in exactly the same situation several times in the past, I have been following Russell Coker's posts regarding data integrity with interest. FWIW, the correct answer to "BTRFS (sic) and Xen" is: subvolumes. Now that Fedora has, once again, decided to postpone their switch to Btrfs as default file system, I decided to write up my own take on this topic. Any and all my considerations are made under the assumption that important data is backed up while semi-important data is at least living on two different machines. Beware, this is a long post, but I do like to think it's well worth reading. RAID Disk failures Let's recap the current situation for "traditional" file systems like xfs, ext 2..4 , etc. In case you need to freshen up on the technical details go here.

• Single disks: Fine for many use cases like Laptops, Desktops, etc, they are what most of us are using for most storage needs.
• RAID 0:If you are using that, you are most likely doing it wrong. Barring increasing caches for SSD-based volumes on machines which you simply take out of your cluster if there is any kind of problem, I don't know of not a sigle valid use case. Other than to get rid of data, that is.
• RAID 1: The default for small servers and important machines which don't need a lot of disk space.
• RAID 5: OK for personal storage servers, avoid once disks become larger than 500GB-1TB, depending on personal preference. To write data, you need to calculate new checksums and thus read all data from all corresponding slices, impacting write performance significantly.
• RAID 6: The RAID 10 people will disagree, but I like this RAID level best. While your write performance will definitely take a hit, you can mitigate this by decreasing your volume sizes. The extra cost in ways of power, disks, controllers, and rack space are a price we gladly pay for the ability to lose two disks and still retain all data.
• RAID 10: Great write performance until the day when two disks in the same RAID position die right after each other and your company's main mail storage dies. Yes, this has happenend to me and it sucks.
• RAID 2,3,4,50,60,foo: Mostly irrelevant in the real world; disregard.

Silent corruption All the RAID levels with redundancy are fine and dandy if you lose a whole disk and put in a new one. Of course, that does not help you the tiniest bit once you get read errors. Controllers which manage RAID 1 or 10 may or may not compare the data while it's being read and may or may not tell you about discrepancies. They can then toss a coin and give you either result. There is no way to determine which is correct. RAID 2, 3, 4, 5, and 6 could, in theory, verify the data as it's being read, but that would limit your read rate to that of a single disk so no one does that. We actually had a massive web presence fail over night, once. No one knew what the cause was as there hadn't been any kind of access logged. As that particular deployment is done directly from a VCS, we simply ran a diff and found one change. We traced the failure down to a syntax error; a one character change made everything fail. Looking at the ASCII table, it was clear that one single bit had flipped. This sucked. A lot. Mitigation So you end up scrubbing your RAID sets on a weekly basis, recovering from silent corruption with the help of your RAID 6's two parity stripes. And even though you schedule the scrubbings with the least priority, you still take a performance hit when randomly seeking a lot. ZFS Some smart people at Sun set out to fix these problems and more, and fix it they did. The "Z" in ZFS is meant to imply that this is the last file system you will ever need and if not for its license, this might have worked. Of course, "last" and "forever" mean "not now" and "10 years" respectively, in computer terms. The limits within ZFS have been chosen so that the entropy needed to create a disk able to max out a ZFS volume would, literally, require our oceans to boil. Let's just say that you won't encounter these limits any time soon. While that is a nice thing to know, it does not say anything about data integrity. There are several mechanisms ensuring data integrity built in ZFS, the most fundamental being extensive checksumming. Checksums are vastly superior to live comparisions which RAID would have to perform as it does not need to sacrifice any significant i/o reading checksum data. With HDD access, you are i/o-bound, and not CPU-bound, anyway, so performing the checksum calculations is laughably cheap when factoring in the added safety. Everything, be data, metadata, inodes, you name it, is checksummed. Every read operation must go through the checksumming functions, ensuring that all data which reaches your user space is correct. If ZFS can't verify the checksum, it will not deliver any data at all, ensuring noticeable, as opposed to silent, corruption. So how does ZFS recover when the checksum does not match the data? copies= 1..3 The easy way is to store several copies of your data within your volume. Mount a ZFS volume or subvolume with copies=2 or 3 and all data that is being written from then on will be copied twice or three times. Trivial in principle, but powerful when built into a file system. RAIDz 1..3 This is where things start to get interesting. RAIDz1, 2, and 3 will allow you to lose 1, 2, or 3 disks respectively while still retaining your data; at the obvious expense of the storage capacity of as many disks. Basically, RAIDz2 is ZFS' variant of RAID 6, but it's so much better than mere RAID 6. Moo! RAIDz will not assign fixed slices and fill them up like RAID does. It will look at the current write speeds and use appropriate slice sizes dynamically. As a direct result, data which has been written at roughly the same time will always be near other data written at the same time. This is very nice for functionality like snapshots, writeable subvolumes and other things and is called COW, ZFS' variant of super cow powers. This also enables ZFS to write data, read it back and verify the checksum and only then point to the new data. Atomic commits done right. Keep rollin' As ZFS has to keep track of what data is still in use in which volumes and subvolumes anyway, it knows which regions are free to be reclaimed. Instead of filling up random places, ZFS will roll over your disks, overwriting unused data on the fly. This bears repeating: Contrary to RAID 5 and 6, ZFS will never need to read old data in order to write new data. Write performance galore and anyone still stuck on RAID 10 can finally enjoy the increased data security. Btrfs To be completely honest, I do not know Btrfs as well as I know ZFS. If I get anything wrong, correct me. If I offend anyone with my outsider's interpretation, that is not my intention. Btrfs has been initiated by Oracle way before it ever even thought about buying Sun or history might have run a different course, for worse or a lot worse. The closing of Java, Solaris, ZFS, Hudson, OpenOffice (since then "gifted" aka thrown away), and others makes me think the latter. As there are few technological developments which caused me as much stress, overtime and pain as OCFS2, I am naturally wary of file systems sponsored by Oracle and their data focus integrity/availability. The fact that there's still no way to fsck a Btrfs volume could be birthing pain or yet another facet of Oracle's stance on this topic, I honestly don't know. Either way, it's a good idea to be wary for now. I can't say too much on Btrfs' technical underpinnings, but I know it uses COW and that it has its own variant of RAID. Toss in snapshots (writeable?), subvolumes and integrated block device management, and you have the building blocks of a decent file system. Still, Btrfs is not ready for prime time. Btrfs has been "one or two years in the future" for a few years now so I will not be holding my breath. And once the first distributions are starting to use Btrfs by default, people will lose data. A year or three after that, I will feel comfortable to use it myself and in production. Commercial solutions You can either hand a lot of money to proprietary vendors who will not tell you a thing about how things work internally (and no way to fix things directly) or you can buy solutions that employ ZFS in the back-end. I prefer my storage hardware to be relatively dumb while keeping the intelligent bits where I can see and poke them so this is not really part of these considerations. So what can you do? Test your disks before deploying them Easy, but vitally important:

disk=/dev/foo
smartctl -a $disk
smartctl -t long $disk
badblocks -swo $vendor_$model_$serial_$timestamp.badblocks.swo $disk
smartctl -a $disk

If you are lazy, get a copy of disktest, a tool I wrote to do exactly this. It should wait for the long self-test to finish, can not read out all vendor names, and does not have a way to document who ran the test, but it's a start. Patches and feedback are, obviously, welcome. And yes, I will package this soonish. Using your disks This list is surprisingly short. You can use

• distinct disks
• RAID as per above
• ZFS-FUSE
• Debian/kFreeBSD
• Nexenta

And that's it. At work, I prefer small RAID 6 volume sets. It sucks, but there is nothing better. For personal use, I have a machine with a FUSE-based RAIDz2 mounted with copies=2. Three disks can fail and my data is still secure. While this setup is slow as molasses due to FUSE, speed is not a consideration for me here; data safety is. A migration to Debian/kFreeBSD in the medium term is still likely. If you have things to add or disagree with me, I would love to hear from you. Update: Jan Christian Kaessens pointed out that, contrary to my experience, zfsonlinux did not bring down his sytem in flames. As zfsonlinux is a kernel module, potential performance is a lot better. Also, it supports ZFS Pool Version 28 as opposed to FUSE-ZFS' 23. While the really nice features are in v 29 and 30 (which are closed thanks to Oracle) v 28 still has some nice changes.

thanks to the Paris BSP & other activities we're seeing a nice decline in RC bugs. here are my recent contributions:

• #554752 src:gtklp: "FTBFS with binutils-gold"
  add patch from Hideki Yamane, upload to DELAYED/2
• #640613 src:jaminid: "jaminid: FTBFS: xargs: /usr/lib/jvm/java-6-openjdk/bin/javac: No such file or directory"
  build-depend on default-jdk and set JAVA_HOME in debian/rules accordingly, upload to DELAYED/2
• #640630 src:policycoreutils: "policycoreutils: FTBFS: chmod: cannot access /build/policycoreutils-r6ObWS/policycoreutils-2.0.82/debian/policycoreutils/etc/init.d/policycoreutils': No such file or directory"
  apply patch from Ubuntu / Mitsuya Shibata, upload to DELAYED/4
• #640633 src:tunnelx: "tunnelx: FTBFS: xargs: /usr/lib/jvm/java-6-openjdk/bin/javac: No such file or directory"
  build-depend on default-jdk and set JAVA_HOME in debian/rules accordingly, upload to DELAYED/2
• #642686 src:javamorph: "javamorph: FTBFS: /bin/sh: 1: /usr/lib/jvm/java-6-openjdk/bin/javac: not found"
  build-depend on default-jdk and set JAVA in Makefile accordingly, upload to DELAYED/2
• #645493 src:postler: "Will FTBFS with libindicate 0.6"
  apply patch from Evgeni Golov, upload to DELAYED/2
• #646388 speech-dispatcher: "FTBFS due to locally changed files without patch"
  update autotools handling, partly taken from Ubuntu / Luke Yelavich, upload to DELAYED/2
• #646647 src:latex-cjk-chinese-arphic: "latex-cjk-chinese-arphic: FTBFS: The requested file, gbsn00lp.ttf, does not exist"
  apply (modified) patch from Hideki Yamane, upload to DELAYED/2
• #652222 src:sensors-applet: "sensors-applet: FTBFS: Could not parse DTD http://scrollkeeper.sourceforge.net/dtds/scrollkeeper-omf-1.0/scrollkeeper-omf.dtd"
  add patch to use local DTD, upload to DELAYED/2
• #652758 src:policycoreutils: "policycoreutils: FTBFS: cc: error: /usr/lib/libsepol.a: No such file or directory"
  multiarchify, based on patch by Hideki Yamane, upload to DELAYED/4
• #658054 instead: "Can not upgrade package instead, because new package instead-data try rewrite files from old package instead."
  add a comment to the BTS

A few people have been using the license-count tool that I wrote to analyze the breakdown of licenses in Debian and draw some conclusions. Unfortunately, some of those conclusions can't be drawn from the output of this specific tool (which doesn't make them wrong, just unproven). So here are a few cautions. license-count was written for a specific purpose: to see how many references there are to a particular license in Debian so that we had some facts behind our discussion of whether to include it in common-licenses. It was not written to classify packages into particular categories, only to find out how many copies of a license we could save by adding it to common-licenses. This means that using it to determine how much software in Debian is covered by a particular license fails in the following ways:

1. license-count numbers cannot be added. Since the goal is to find every reference to a given license, each package is not classified as under one and only one license. If a package has material under the GPL, the LGPL, and the GFDL, it will add one to each of those counts. This means that you cannot determine, from its output, questions like "how many packages are covered under one of the GPL family of licenses?" You will double- or treble-count packages when you add the numbers together.
2. license-count counts any reference, not just "important" ones. If the license is referenced in debian/copyright, that counts, since the goal is to see how many packages might benefit from being able to reference it in common-licenses. This may not be the license that the package is under, just some small portion of the package. For example, all of my packages that use Autotools add to the GPL count because I include all the source code licensing statements, including the statements for libtool and the Automake helper scripts, which say that the files can be released under either the GPL or the license of the including package. These packages are generally under a BSD-style license (or in some cases the Apache 2.0 license), not under the GPL, but since the reproduced license text has a reference to the GPL, license-count adds one to the GPL column for each of those binary packages. For most purposes for counting GPL-covered software, these are false positives. I don't know how many people are as complete in documenting license statements as I am, but just the binary packages that I maintain probably count for at least 50 false positives because of this alone.
3. license-count numbers include dual-licensing. Whether this matters for your analysis or not depends on what question you're asking, of course. If you're asking whether the package is covered under a copyleft license, including the thousands of packages that are dual-licensed under the Artistic license and the GPL may be okay, since the Artistic license is a sort of copyleft (although it allows you to avoid the copyleft requirement by renaming executables, providing the originals, and documenting your changes). But, for example, one of my packages is dual-licensed under a BSD-style license and the GPL (for reasons that aren't worth getting into). This package is not covered by copyleft under any reasonable definition of the term, but license-count will count it as a package using the GPL.

In order to draw interesting conclusions like "how much software in Debian is protected by copyleft," I'm afraid that you'd have to write a much more sophisticated tool than license-count.

I've released version 0.25 of Obnam, my backup application.

• Log files are now created with permissions that allow only the owner to read or write them. This fixes a privacy leak.
• The nagios-last-backup-age subcommand is useful for setting up Nagios (or similar systems) to check that backups get run properly. Thanks to Peter Palfrader for the patch.
• Some clarification on how the forget policy works, prompted by questions from Peter Palfrader.
• New settings ssh-known-hosts (for choosing which file to check for known host keys), strict-ssh-host-keys (for disallowing unknown host keys), and ssh-key (for choosing which key file to use for SSH connections) allow better and safer use of ssh.
• Checkpoints will now happen even in the middle of files (but between chunks).
• The --pretend option now works for backups as well.

BUG FIXES:

• obnam ls now shows the correct timestamps for generations. Thanks, Anders Wirzenius.

When I told people of my plans to move to Montreal, it usually prompted one of two reactions: one was some version of joyful envy, many people exclaiming breathlessly Montreal is one of my favorite cities, one person once even clutching my arm and told me as he looked me straight in the eye: you are so lucky, there is no city quite like Montreal in North America. The second reaction came off as a thinly veiled mixture of disdain and disbelief usually peppered with many reallys: oh wow, really, really you would really leave NYC? I am pretty certain they really were thinking something along the lines of what a fool, how dare she leave a great job, a great university, a world class city (the only city to live) for some Canadian mid-sized city, which is like tundra for a good chunk of the year? The decision to move weighed heavily on me, if for no other reason I had a choice to stay or to go and I honestly have not had a choice, a decision to make about where to go since I got accepted to graduate school (and even then the choice was more obvious than this one). So over a month into my move what is my verdict? In a word, win. I don t miss NYC at all though I get why some people cannot leave the place and know that despite some oddities and difficulties of living in Montreal, it fits my tastes and needs much better than NYC which dwarfed me in so many ways. I never felt I could enjoy it, I grew tired of the cramped living quarters, the noise ate at my soul, and I simply felt more overwhelmed by the fact that I could not even get a handle on the neighborhoods in my vicinity, much less all the other hoods in the area. Instead of dogging NYC anymore, I think I will spend a little time on first impressions, as they will soon be lost to the familiarity borne with time and experience. In essence Montreal is chock full of life but rather intimate, a quirky city with lots of charm but some grit and lacking the way over designed and done feel of cities like Portland. Here are some of quirks: 1. The Hawt Metro: I fell in love with the Metro when I first rode it a few years ago. I just love the powder blue color of the cars and the super sweet 1960s aesthetic of many stations. Even better and unlike NYC, they are just clean and quiet. The downside? The temperatures approximates a sauna during the winter and while you would think this is a good thing, when you are layered with the clothing necessary to survive outside (re: long underwear along with Canada-coat, gloves, hat, and scarf), it is hooooooot down there and you feel like you need to pass out. 2. Spend money, get free stuff: In many establishments you get free stuff (like blueberries or some like sports bar) when you spend over a certain amount of money, like 70 bucks. Quirky local tradition. 3. The culture of negotiation and the kick ass standard lease: Housing is amazing here. There is plenty of it, there are many different styles, and it is rather fun exploring all the different hoods that make up the city. Problem is too that lots of apartments have weird problems and issues and I had to steer clear of anything that could even possibly have mold. I spent weeks day in day out looking for a place, desperate to move out of my corporate apartment very nicely provided by the university but still not my ideal living situation. Finally found a place that fit all my needs in the perfect location and I took it to only find out that places are priced to negotiate and I was faced with the decision to negotiate or not. Sort of did, was not thrilled about it (thinking that I might lose the place) but it sort of worked and I scored the place. If price is up to haggling, the lease on the other hand, is standard (you can buy one at your local bodega ). It is the law to use it and it is like a no nonsense, straightforward lease, which is very protective of renters. 4. Montreal is known for its exceptional food but you know Poutine is just plain gross: Food here is good and I can tell that I will get a handle of restaurants in a way that felt impossible in NYC. The gluten free religion seems to be spreading, thankfully. There are many little Fruiterias! to get your fruits veggies which I am still exploring and right around my house is a crazy supermarket that is so cheap, which is weird because consumer goods generally ain t cheap in Montreal like they are in the states but this place is a gem and everyone agrees (and almost impossible to notice from the street!). Now Poutine is disgusting. Ok it did not help that the first night I went out to eat it, I was still under the clutches of Noro virus, and I think it re-activated the nausea that had been zapped by some strong medicine and the hospital, the day before, which brings me to the next point, the health care system. 5. Healthcare, I had to use it way too early: So last week I came down with the Noro virus and you usually wait it out as it runs through you quickly but I was dehydrated before I even started to vomit to for 8 hours straight, at which point severely tired and so nauseous (I was yelling to make it stop), I went to the hospital. Now I had talked to lot of people about the healthcare system in Montreal as it seems good, really great but a bit over taxed, especially compared to where I had lived in Edmonton where it was like a magic fairy tale dream. I had heard of two things: the care is excellent but the facilities are shocking and the wait times unless dire can be atrociously long. So facilities, yea they are kinda shocking, somewhat shabby but who cares, so long as the care is good, no? Packaging is irrelevant so long as the goods are derived. Before going I was scared of the long wait times (and also the taxi took me by mistake to Montreal General Hospital was looked too much like a HUGE version of the creepy buildings in The Shining for me, and I was supposed to go to Jewish General so left for there). The wait time: nearly none, somewhat as shocking as the facilities first looked to me. I think it was a combination of the time I arrived, with the fact that my lounge was parched and yellowish-gross (sorry, it was gross), indicating I was dehydrated, oh and I was crying bit hysterically, for despite my high threshold for pain, nausea terrorizes me. I was covered by insurance and since I did not yet have my McGill health cards (it takes three months to qualify for the local stuff), I did pay and the price was laughably cheap compared to what I would pay in NYC for the same treatment. 6. Now for my favorite, snow so nice, ice oh Christ: Well this winter has been, by all accounts, weak and warm, the spirit of winter barely making its way from the underworld to the outerworld. But even though it is has been more idle than full throttle, I still got a pretty accurate taste of what winter is like, with a few days of 20- c temps, and having to walk a number of times on a layer of frozen ice that makes it feel like a very dangerous mini-ice age in the making. I do rather love the quiet snow falling and just love love sprinting through the snow with my dog, Roscoe, who has taken a liking for prancing in the white stuff and looks awful cute with his winter man s ice beard. After a sizable snowfall, it is clear they city does not toy with the snow removal although the sidewalk snow plows do look somewhat like very large and dangerous but kinda cute toys. But let s be frank, winters are hard, so hard that I think I would go mad if I had to stay through the entire thing, being born and raised in the tropics So the fact that I am writing this from the southern hemisphere in the height of summer gives me the assurance I can handle the rest of the snow, ice, ice and snow upon my return.

At FOSDEM, John Sullivan delivered an interesting talk titled Is copyleft being framed? to verify alleged claims on the decline of GPL-d software. (Slides are available.) The crux of the talk is the analysis he performed on the Debian archive to discover the amount of software we distribute that is covered by GPL, LGPL, or AGPL ("GPL-d" for short in the remainder). John's talk steps in an interesting and long running debate (a recent summary of which is available in this ITWire article). The most interesting part is the discrepancy among John's results and Blackduck's, which are often used to argue how the popularity of the GPL license is declining. That might be the case. Or not. The more analyses we do to find it out, the better. The underlying assumption on John's work is that Debian is a representative sample of the Free Software out there, which I think is a reasonable assumption. I find the analysis presented in the talk completely satisfactorily from a purely scientific point of view. The same cannot be said about Blackduck's result: both their methods and data are secret, making it impossible to reproduce their experiments. Highly unscientific. Still, John's results are surprising: as much as 87 percent of Lenny's packages and 93 percent of Squeeze's are GPL-d. That seems a lot. Puzzled about that, John discussed with me the issue before his talk, in search for pitfalls in his methods or data. Finding none, I pointed him to the almighty DktrKranz for some extra review; who found nothing either. To stay on the safe side, even during his talk John called for independent reviews of his results. What could be wrong? The tool used to gather the data is license-count from the debian-policy package. Input data are the debian/copyright files of all Debian source packages. If license-count is not bugged, our debian/copyright files might be. One thing that occurred to me only a few days ago is the habit of declaring a different license for Debian packaging (the files under debian/) than the software being packaged itself. That's a bad habit because it might cause unwanted license mixtures via patches that live under debian/ but I've seen several occurrences of it in the Debian archive. For name and (self-)shame: I've also been guilty of it in the past, when I was young . Is that reason enough to skew results and overestimate GPL-d software? I don't think so, I hope not, but ultimately I don't know. It'd be nice to rule out the possibility entirely. So if anyone is willing to do some sampling of affected debian/copyright files and propose patches for license-count to exclude those "false positives", please shout. (As a bonus point: that would also help to take more sound decision for the typical use case of license-count, i.e. deciding when a license should be added to /usr/share/common-licenses.) Other independent reviews of the results are equally welcome. Note: the above, as well as John's analysis, would be a trivial exercise if DEP-5 were already widely deployed in the Debian archive.

---

Update: add link to John's slides
Update 19/02/2012: Russ Allbery, author of license-count, posted a way more likely cause of data skew in John's analysis: double counting among the different types of copyleft licenses