Should have committed earlier

Lots of changes:
- Article about IPC
- New TUWF release
- New ncdu release
- Atom feeds for the bug tracker
- Bug tracker switch to sqlite

dat/ncdu-jsonfmt

@@ -1,8 +1,8 @@
 =pod
 
-This document describes the file format that ncdu 1.9 and 1.10 uses for its
+This document describes the file format that ncdu 1.9 and later use for the
 export/import feature (the C<-o> and C<-f> options). Check the L<ncdu
-manual|http://dev.yorhel.nl/ncdu/man> for a description on how to use that
+manual|https://dev.yorhel.nl/ncdu/man> for a description on how to use that
 feature.
 
 =head2 Top-level object
@@ -29,7 +29,7 @@ the existing format.
 =head2 Metadata
 
 The C<< <metadata> >> element is a JSON object holding whatever (short)
-metadata you'd want. This block is currently (1.9-1.10) ignored by ncdu when
+metadata you'd want. This block is currently (1.9-1.11) ignored by ncdu when
 importing, but it writes out the following keys when exporting:
 
 =over
@@ -109,10 +109,10 @@ C<< 0 <= dev < 2^64 >>.
 Number. Inode number as reported by C<lstat().st_ino>. Together with the Device
 ID this uniquely identifies a file in this dump. In the case of hard links, two
 objects may appear with the same (C<dev>,C<ino>) combination. A value of 0 is
-assumed if this field is absent. This is currently (ncdu 1.9) not a problem as
-long as the C<hlnkc> field is false, otherwise it will consider everything with
-the same C<dev> and empty C<ino> values as a single hardlinked file. Accepted
-values are in the range of C<< 0 <= ino < 2^64 >>.
+assumed if this field is absent. This is currently (ncdu 1.9-1.11) not a
+problem as long as the C<hlnkc> field is false, otherwise it will consider
+everything with the same C<dev> and empty C<ino> values as a single hardlinked
+file. Accepted values are in the range of C<< 0 <= ino < 2^64 >>.
 
 =item hlnkc