There is a special font, called Sans Forgetica, designed to better retain the text that you read… Wow.

I can see how this may become abused – for example, for advertising

Anyway, you can download the font, and even a Chrome extension to show any text chunk in this Unforgettable font from the font’s website: http://sansforgetica.rmit/.

Here’s my blog URL for you to remember, hehe

The 2018 World Cup is now underway in Russia. The story of how it ended up there involves some names you might recognize: James Comey, Robert Mueller and Christopher Steele. Guest: Ken Bensinger, author of “Red Card: How the U.S. Blew the Whistle on the World’s Biggest Sports Scandal,” who has written about this story for The New York Times.

Exactly what the title says: Raspberry Pi colocation service, yay! At only 30 EUR/year as of this writing.

My current email server was configured eons ago, it works well,
but I have no desire to painfully transfer all the configuration…
Better install something new, shiny and exciting, right?

I had 3 #self-hosted, #mail-server bookmarks:

• Mail-in-a-box
• iRedMail
• Modoboa
• Sovereign

(Sovereign, the 4th one, was addded after reading more about Mail-in-a-box.)

Here are my notes on what seemed important about these 4.

• iRedMail
• has free and paid web-UIs
• no DNSSEC, DMARC, HSTS
• amavisd with clamav
• has useful manual parts
• containerized
• not attractive
• Modoboa
• less sophisticated than Sovereign or Mail-in-a-box
• web-UI, also for amavisd filters
• overall: focuses on better UI
• has useful manual parts
• recent (experimental?) LetsEncrypt support
• has (some) unit tests
• containerized
• not that attractive
• Sovereign
• has more than I need, but components can be deactivated
• has EncFS support (useful, but questionable because of reboots…)
• no dedicated web-interface, configs are text
• has proper testing against a vagrant virtual machine
• can be dockerized using github.com/kisamoto/dancible
• attractive as “the next solution”, or to borrow EncFS support
• Mail-in-a-box
• the most sophisticated email server (except for EncFS which is not used here)
• simple but useful web-UI
• no amavisd, clamav, UI for filters
• has good relaying manual
• more or less requires a separate machine (overwrites configs?)
• has no well-established testing, not even for development; this is being worked on as of New Year 2017
• problems with owncloud (which I don’t really need)
• hub.docker.com/r/mtrnord/mailinabox/ , github.com/mail-in-a-box/mailinabox/blob/docker/containers/docker/run
• postscreen is not yet configured, it is not obvious if it were beneficial
• the most attractive; might be reasonable to fork and modify (e.g. drop owncloud?)

MIAB appeared really attractive,
but then – do I really want to dedicate one of the VPS to the mail server only?
Not in my case – too low emails volume/traffic.

So running it in an LXC (or some other) container would make sense.
And this is actually possible, some of the users over at MIAB’s discussion forum
have been running MIAB inside docker container for over a year now with no issues.
(An extra upside is that web-UI can be left unexposed, preventing external access to it.)
A possible long-term downside is, of course, lack of tests – Sovereign looks much better in this regard.

Sovereign looks very good overall. In fact, MIAB feels like
“Sovereign’s email component + webui for it” (MIAB was inspired by Sovereign).

One extra MIAB-specific feature is DNSSEC support.
MIAB takes on the role of your nameserver, and thus is able to setup (and refresh, when necessary)
all the DKIM/DNSSEC/etc-relevant DNS records for you.

As soon as I’ve started adding “containerization” to the mix, dozens of other projects entered my field of view:

• github.com/indiehosters/email, inspired by MIAB, looks ok; lacks webmail, fail2ban, SPF, DANE, DNSSEC, but uses vimbadmin instead of a custom-coded MIAB UI
• github.com/tomav/docker-mailserver looks great! No UI, no SQL backend, only 2 text files (accounts and aliases) for all configuration – yay!
• github.com/lava/dockermail, much less active/polished, not really interesting
• github.com/frankh/docker-compose-mailbox adds roundcube and vimbadmin containers; uses SQL; not sure why it has only 10 stars on github…
• github.com/adaline/dockermail – looks ok, less active and seems simpler than docker-mailserver
• poste.io : has free (downloadable) and 2 paid versions; packed with many features and containerized; there is no Dockerfile, but of course you can examine what’s inside the public image anyway; actually, looks good – not sure how posteio-specific the data directory structure is, though… still something to try
• mailgun.com – SMTP service with a more than sufficient free quota for a few low-traffic websites; can be coupled with some forwarding service to avoid any need in an email server; but not this time, I want a mail-server
• yunohost.org : I’m not entirely sure why this is here, maybe it does have email support built-in? ok, yes it does – this is a debian-based “home-server” software, which also includes LDAP and SSO and XMPP and DNS and nginx. Hmm, not bad. I wonder how well it works out of the box.
• kolab.org : groupware; looks interesting as well, but I have no group (yet) to have a use for a full groupware solution
• not reviewed: mailcow.email, mailcow.email/dockerized, github.com/andryyy/mailcow

Finally, one can build an own LXC container, either by following this ArsTechnica series,
or after examining the install scripts of MIAB or Sovereign.
Then automate all of this, keep it well-maintained – and there you have it, one more mail-server solution!

To re-cap:

• MIAB looks very good – feature-rich, easy to install, and just works – you should try it!
• docker-mailserver looks great – I should try it!
• poste.io, yunohost.org and kolab.org are also some interesting solutions to try, along with Sovereign

Not much of a summary, but this is definitely an accurate reflection of reality.

But I always keep looking for new/improved tools, as right now I feel the best one does not exist…
(If the best one can exist at all – requirements and conditions change all the time, so there is no fixed perfect immovable target.)

I have been contemplating trying out the TSW methodology, but neither Keep nor Trello are quite there yet.
I ended up using Evernote; after recent management changes and actually trying to become profitable it may as well last long enough.

Everything was fine and calm until I have found workflowy yesterday.
In essence, it is very similar to the text-file-based system that I have been using for at least half a year.

Briefly, it is a web-based text editor on steroids, with possibly infinite nesting lists and seemingly full keyboard shortcuts control – no mouse needed.
I recommend that you try the demo – it seems to be fully functional, and there is no need to sign up.

This discovery made me read through pages and pages of this class of software tools.
Here is a very brief summary of my findings:

• org-mode for emacs: taking notes, organizing to-do lists and projects, writing structured text; I can definitely see the benefits – especially for tasks/projects management; however, for rich content – with attached/embedded files/images – this probably won’t work that well; see also orgzly;
• TagSpaces (also on github) is a tags-based files manager; cross-platform, offline, stores tags in filenames (in square brackets) – this is probably the least interfering/locking-in solution, the only things changing are file names; TagSpaces users are expected to synchronize the tag-controlled filesystem (which can be some specific directory tree) using 3rd-party tools such as [BT]Sync, SyncThing, Dropbox, Box, etc;
• many kinds of Evernote-like tools and wikis, that people also use to take notes; the two most mature and usable and feature-rich are probably Laverna (looks great, uses markdown, can be self-hosted, unclear how to search by multiple tags) and Paperwork (same thing with multiple tags); WizNote also deserves a mention; among other tools: git-backed magpie, yipgo, Marks, KeepNote, zim, etc;
• hamster-GTD is a (yet another?) variation of TSW/GTD – not a tool, but a system;
• Artificer (formerly Overlord S-RAMP), a system for any kind of interconnected, hierarchical data; see also Artificer GTD example;
• magnolial, workflowy clone (haven’t tried it yet); another clone is HackFlowy – trying its offline demo shows that only a basic list functionality is present.

Now that I think of it, TagSpaces is a neat idea…
Especially for photos – assigning tags actually updates filenames, which is great for photos.
And you can easily search by those tags later in TagSpaces.
In fact, TagSpaces looks very interesting for organizing lots of directory/file-based data.

Laverna looks quite exciting! And seems to be actively developed.
But there seems to be nothing quite comparable to WorkFlowy… Need to test it some more.

This anime is the best that I have watched since (all seasons/full features of) Ghost in the Shell. In fact, I like this one more than Steins;Gate – which I can also recommend, but it takes patience to watch the first 3-4 episodes. With Parasyte, no patience is necessary: it is a very smooth flow from the very start until the very end. Luckily, season 1 is all there is. Just like with the legendary single season of Firefly

This post is not intended to be an in-depth comparison, but should be sufficient to choose one of the three file formats for your purposes. For more format details and history simply follow the links provided. File formats are reviewed roughly in “historical” order.

PNG (Portable Network Graphics) was designed as GIF replacement.

• It is lossless.
• It is suitable for photos.
• PNG is more space-efficient in the case of images with many pixels of the same color, such as diagrams/plots (as compared to PGF and JPEG2000). However, PNG photos are almost always larger than lossless PGF/JPEG2000 photos (real photo example: 9.9 MB in PNG, 7.0 MB in JPEG 2000).
• PNG is fairly fast at (en|de)coding.
• PNG is widely supported by web-browsers, image editors, and other software.
• PNG uses CRCs internally for each data block, so if damage occurs only the damaged block(s) should be lost – theoretically. However, in practice, according to the Just One Bit paper (local copy), PNG is actually much less damage-resilient than JPEG 2000.

JPEG 2000 (JPEG 2000) was designed as JPEG replacement.

• It has both lossless and lossy modes. Lossy mode is “better” (perceptually at the same file size) than JPEG.
• Lossless mode is the smallest of all 3 file formats tested.
• JPEG 2000 is slower at (en|de)coding than PGF and PNG.
• JPEG 2000 has several associated ISO and other standards. Software support for JPEG 2000 is not as good as for PNG, but better than for PGF.
• JPEG 2000 has good bit errors resilience (local copy).

PGF (Progressive Graphics File) was also designed to replace/enhance JPEG.

• PGF uses the same wavelet-based method as JPEG 2000, so it shares a lot of features with JPEG 2000, including support for lossless and lossy modes, with lossy being “better” than JPEG.
• Lossless mode file is marginally larger than the same image in JPEG 2000 (real photo example: 7.0 MB in JPEG 2000, 7.4 MB in PGF).
• It is much faster at (en|de)coding than JPEG 2000 (this is major difference #1 of 2).
• Software support for PGF is not as good as for JPEG 2000 (this is major difference #2 of 2).
• Being under-appreciated, PGF doesn’t seem to have received any error resilience testing, yet. However, one should expect error resilience similar to that of JPEG 2000, because essentially the same compression method is used (albeit with different “parameters”, resulting in a speed/size trade-off/gain). It is not clear if PGF has any resilience features like JPEG 2000.

Fun fact #1 from the links above: best error resilience was observed for bitmap files.
Fun fact #2: after about 1% of data damage none of the compressed formats is able to reliably reproduce the original image.

I would be happy to use PGF for its speed, compression ratio, and features, but lacking software support is detrimental (in a self-reinforcing manner) to widespread adoption of PGF; being quite similar to the more popular (or better promoted) JPEG 2000, I do not know if PGF will gain sufficient traction to get e.g. browser support.

PNG has very good support, but produces noticeably larger files, and exhibits significantly lower error resilience than JPEG 2000.

So as of today my choice is JPEG 2000 (lossless, with resilience features).

Yesterday I got somewhat distracted, and thus found lbzip2 -

an independent, multi-threaded implementation of bzip2. It is commonly the fastest SMP (and uniprocessor) bzip2 compressor and decompressor

- as it says in the Debian package description. Is it really “commonly the fastest” one? How does it compare to pbzip2? Should I use lbzip2 instead of pbzip2?

This minor distraction had grown into a full-scale web-search and comparison, adding to the mix plzip (a parallel version of lzip), xz, and lrzip. After reading thousands of characters, all of these were put to a simple test: compressing an about 2 gigabyte FASTQ file with default options.

All the external links and benchmarks, as well as my own mini-benchmark results, are provided below.

The conclusion is that out of all the tested compressors lbzip2 is indeed the best one (for my practical use). It is only slightly better than the trusty pbzip2, which takes the second place. All the other compressors performed so poorly, that they do not get any place in my practical rating…

So, let us first ask internet wisdom/foolishness, if lbzip2 or pbzip2 is faster/better?

• this askubuntu question shows that lbzip2 is compressing faster (1:43) than pbzip2 (2:34)
• this nice benchmark also confirms that lbzip2 is indeed faster at compressing; lbzip2 also appears to use less RAM and a little bit less CPU during compression; during decompression, lbzip2 (reportedly) uses much more RAM. lbzip2 achieved at least as good (and even marginally better) compression ratios as pbzip2.
• lbzip2 github page and also this unrelated page both say that lbzip2 is fully cross-compatible with bzip2
• probably most importantly, lbzip2 github readme says that even bzip2-compressed archives get a decompression speedup (which is definitely not the case with pbzip2)
• lbzip2 also uses 100-900k blocks (900k by default)
• it is not clear if lbzip2 is somewhat less widely tested than pbzip2
• lbzip2‘s author has performed some testing (back in 2009, mind you!), and these were the most important results:
• lbzip2 is better when decompressing from a pipe, no matter the producer, and also when the compressed input coming from a regular file is single stream
• pbzip2 beats lbzip2 when the compressed input is coming from a regular file and is multi-stream (yes, pbzip2 can decompress even lbzip2′s compressed output faster than lbzip2 itself, when it’s coming from a regular file) note: if you check the vbsupport benchmark above, you’ll see that lbzip2 had probably fixed slight lagging behind pbzip2 for regular multi-stream files; this improvement is also confirmed by my testing

So, at least in theory lbzip2 is indeed better than pbzip2, even if only at faster decompression of bzip2-compressed files.

While looking for benchmarks, I’ve found this one (old but good), which highly praises lzop compressor. Apparently, lzop is noticeably faster than even gzip, and compresses only a little bit worse. However, I am not really interested in a faster gzip: I need something with much better compression, but still fast enough for multi-gigabyte files.

Next, I have stumbled upon lzip and plzip (.lz). What are these compressors?

• plzip is a parallel version of lzip, and fully lzip-compatible
• lzip is an LZMA compressor
• reading the documentation leaves an impression that [p]lzip achieves better compression, is slower, and needs much more RAM than competing compressors
• there is a special utility called lziprecover, which helps recover data from damaged lzip archives, by leveraging, on the one hand, CRC checksums of compressed blocks, and, on the other, multiple damaged copies of the archive (if available)
• from the official website:
  

  Lzip is a lossless data compressor with a user interface similar to the one of gzip or bzip2. Lzip is about as fast as gzip, compresses most files more than bzip2, and is better than both from a data recovery perspective.

• default “member” (compressed block/chunk) size is 4 petabytes, but can be set to a lower value (minimal 100kb), mimicking bzip2′s chunk size
• supports multiple, independent volumes (loosing one volume will still allow recovering data from all other volumes)
• with multiple cores, plzip creates multi-member files by default (but it is not clear, what is the size of these members? Default is said to be twice the dictionary size, but default for dictionary size is not specified in the manual – so lzip/plzip seem to require compression level -1…-9 specification)
• here lzip compresses a little bit better than xz without the --extreme option
• (l|p)bzip2 should still be faster than either lzip or xz
• I started mentioning xz, because lzip and xz (at least historically) are competing LZMA-based compressors
• a 1 year old opinion makes the following statements about lzip:
• lzip is a marginal archiver with no real benefits since the appearance of xz (note: xz is a successor of lzma-utils)
• xz is more popular, more widely accepted
• xz has a community, while lzip has 1 author
• performance of xz and lzip is comparable
• xz has more features
• but lzip does indeed have a recovery utility that xz doesn’t

That doesn’t really tell us much on how plzip/lzip compare to, say, pbzip2. But before performance, let us pay some more attention to long-term storage features of lzip:

The lzip file format is designed for data sharing and long-term archiving, taking into account both data integrity and decoder availability:

• The lzip format provides very safe integrity checking and some data recovery means. The lziprecover program can repair bit-flip errors (one of the most common forms of data corruption) in lzip files, and provides data recovery capabilities, including error-checked merging of damaged copies of a file.
• The lzip format is as simple as possible (but not simpler). The lzip manual provides the code of a simple decompressor along with a detailed explanation of how it works, so that with the only help of the lzip manual it would be possible for a digital archaeologist to extract the data from a lzip file long after quantum computers eventually render LZMA obsolete.
• Additionally, the lzip reference implementation is copylefted, which guarantees that it will remain free forever.

(I really liked the part about the digital archaeologist! And the copyleft, to a lesser extent.)

Looks really attractive! Because what I am using compressors for is, essentially, longer-term archiving, with unpredictable needs to sometimes decompress some of the files. And, of course, storage media will fail fully or partially, so recovering is important, too. But what is this xz compressor?.. I’ve seen it before, in the contexts with words “overtake the world” or similar…

xz

• much more complex file format than lzip, but maybe it has some benefits for client programs and/or recovery?
• supports integrity checks and multiple compressed blocks
• according to this post from 2012, xz (single-threaded) both compressed and decompressed much faster than lzip… and lrzip (depends on settings, of course)
• lzip is older than xz, and was better than xz predecessor – lzma-utils
• xz is adopted by some linux distributions and software projects for package compression
• xz does not seem to have an equivalent of lziprecover
• tar supports both --lzip and --xz, also with --auto-compress

This hasn’t really added any clarity, has it? Moreover, we now have one more unknown – the lrzip compressor. lrzip is a redundancy compressor with LZO, gzip, bzip2, ZPAQ and LZMA back-ends. It is highly efficient for highly redundant data, even if redundancies are separated with long stretches of other data. (FASTQ files are fairly redundant, though bzip2 seems to utilize that fairly well already; can lrzip do better?)

However, what if a part of the archive is damaged? How much information is lost then? Is it at all possible to recover some of the data from damaged .lrz archives?
Author’s benchmarks showcase how good lrzip is at redundant data compression (although lrzip is multithreaded, so comparison in the benchmark to non-multithreaded algorithm implementations is not quite correct…). Damaged archive recovery concerns would have prevented me from using lrzip anyway, but I was really interested if a “long-range redundancy” compressor can do better than usual, “short-range redundancy” compressors.

My testing setup

• Debian testing 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt7-1 (2015-03-01) x86_64 GNU/Linux
• Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz (4 physical cores with HT enabled: 8 hardware threads)
• 16GiB RAM
• test file name: test.fastq
• test file size: 2 223 860 346 bytes (a little over 2 gigabytes)
• test file was copied once to RAM-mounted /tmp, to exclude any I/O bottleneck effects on compression speeds
• bzip2: 1.0.6
• lbzip2: 2.5
• pbzip2: 1.1.9
• xz: 5.1.0alpha
• plzip: 1.2
• lrzip: 0.616
• command execution time and maximal process RSS memory were measured with /usr/bin/time -f '%C: %e s, %M Kb' compressor arguments (note: this is not bash’s built-in time); please note that memory measurement can be incorrect for multithreaded compressors

Below come testing results. I have not put them into a single table, but I do comment the results in a few places. Entire testing followed this pattern:

• compress test.fastq, deleting the original
• test compressed archive (note: this was done only for some compressors, not all)
• decompress archive back to test.fastq, delete archive
• if 3 previous steps are fast enough: repeat 1-2 more times (but only show the best result below); otherwise continue
• repeat with the next compressor

bzip2: 309 159 275 bytes
bzip2 was used as a baseline, to highlight speed benefits of both lbzip2 and pbzip2.

test.fastq: 7.193:1, 1.112 bits/byte, 86.10% saved, 2223860346 in, 309159275 out.
bzip2 -v test.fastq: 190.63 s, 7608 Kb
bzip2 -v -d test.fastq.bz2: 51.58 s, 4620 Kb

Bzip2 is neither particularly slow, nor particularly fast. It also seems to have modest memory requirements.

pbzip2: 310 462 610 bytes
pbzip2 is the currently used reference. For any other compressor to become a successor of pbzip2, that other compressor must be either a little faster (while compressing as good as pbzip2), or a little better compressor (while being as fast as pbzip2), or both. Note that compressed file size is only a tiny bit larger than with bzip2.

“test.fastq.bz2″: compression ratio is 1:7.163, space savings is 86.04%
pbzip2 -v test.fastq: 46.22 s, 67436 Kb
pbzip2 -dv test.fastq.bz2: 19.80 s, 46672 Kb

Interestingly, pbzip2 --test uses 1 thread only (but also consumes only 6MB RAM), resulting in decompression times similar to those of bzip2. lbzip2 uses all 8 threads also during testing.

lbzip2: 311 040 543 bytes

lbzip2: compressing “test.fastq” to “test.fastq.bz2″
lbzip2: “test.fastq”: compression ratio is 1:7.150, space savings is 86.01%
lbzip2 -v test.fastq: 22.67 s, 49812 Kb

lbzip2: decompressing “test.fastq.bz2″ to “test.fastq”
lbzip2: “test.fastq.bz2″: compression ratio is 1:7.150, space savings is 86.01%
lbzip2 -vd test.fastq.bz2: 18.86 s, 46652 Kb

I repeated pbzip2 and lbzip2 tests several times, and it was always that lbzip2 compressed this same file about twice as fast… Wow! Decompression speed is about the same, compressed file size is marginally larger than with pbzip2. Overall, lbzip2 does look like a new drop-in replacement of bzip2/pbzip2 for me.

xz -0 ––threads=8: 517 967 372 bytes
I would call this one major test disappointment. Default setting, -6, was way too slow (estimated 28 minutes to compress!!!). Even the fastest -0 setting was still too slow! And here’s one of the reasons, straight from the xz man page:

Multithreaded compression and decompression are not implemented yet, so this option has no effect for now. As of writing (2010-09-27), it hasn’t been decided if threads will be used by default on multicore systems once support for threading has been implemented.

Also, I forgot to use the --block-size=900k option, but that seems to be of no concern with such results:

100 % 492.5 MiB / 2,120.8 MiB = 0.232 18 MiB/s 1:59
xz -0 -v test.fastq: 119.25 s, 4780 Kb
xz ––test ––verbose ––threads=8 test.fastq.xz: 36.00 s, 2568 Kb
100 % 492.5 MiB / 2,120.8 MiB = 0.232 58 MiB/s 0:36
xz -d -v test.fastq.xz: 36.54 s, 2500 Kb

xz -0 was both slower and had significantly worse compression when compared to lbzip2 and pbzip2. xz -0 was faster than good old bzip2, but had significantly worse compression… Really, major test disappointment.

plzip: between 407 696 562 and 498 708 539 bytes
One more major test disappointment. (Or am I somehow using these compressors in a wrong way?…) I haven’t found a way to set block/member size (for lzip, that would be the -b option). Default speed setting -6 was also way too slow, but settings -1 to -3 were comparable to pbzip2, so I did all three.

plzip -1: 498 708 539 bytes

test.fastq: 4.459:1, 1.794 bits/byte, 77.57% saved, 2223860346 in, 498708539 out.
plzip -1 ––verbose ––threads=8 test.fastq: 30.27 s, 126360 Kb (this seems to be per-thread memory…)
plzip ––test ––verbose ––threads=8 test.fastq.lz: 6.86 s, 11640 Kb
plzip -d ––verbose ––threads=8 test.fastq.lz: 7.24 s, 11644 Kb

Compression speed and ratio: both worse than lbzip2. But the fastest testing and decompression so far.

plzip -2: 456 301 558 bytes

test.fastq: 4.874:1, 1.641 bits/byte, 79.48% saved, 2223860346 in, 456301558 out.
plzip -2 ––verbose ––threads=8 test.fastq: 38.81 s, 193416 Kb
plzip ––test ––verbose ––threads=8 test.fastq.lz: 6.26 s, 14828 Kb
plzip -d ––verbose ––threads=8 test.fastq.lz: 6.38 s, 14736 Kb

Compression time worse than lbzip2, a little better than pbzip2, but compression ratio worse than any one of these. But even faster testing and decompression.

plzip -3: 407 696 562 bytes

test.fastq: 5.455:1, 1.467 bits/byte, 81.67% saved, 2223860346 in, 407696562 out.
plzip -3 ––verbose ––threads=8 test.fastq: 63.74 s, 245756 Kb
plzip ––test ––verbose ––threads=8 test.fastq.lz: 5.82 s, 18936 Kb
plzip -d ––verbose ––threads=8 test.fastq.lz: 6.10 s, 18944 Kb

Even faster testing and decompression! But compression ratio and speed are still worse than lbzip2 and pbzip2.

And the final contestant, lrzip! All 5 back-ends were tested: LZO, gzip, bzip2, LZMA, ZPAQ.

lrzip has several peculiarities, which hinder its use as a drop-in replacement for, say, bzip2. Most importantly, when a file is compressed, it is not deleted, unless a -D options is specified. Unlike pbzip2 and lbzip2, which use all available CPUs/cores by default, lrzip only uses 2 by default (-p 8 in the results below requests use of 8 cores). Another unusual feature is that during testing a file is uncompressed to a storage medium, and then deleted; almost all the other compressors only verify the decompressed data stream, which is then immediately discarded and never written to storage medium. Related feature is a -c option, which performs file verification after decompression by reading the decompressed file from storage medium and comparing it to the decompressed stream. lrzip also stores MD5 hashes of data, and allows verifying these. lrzip comes with several helper scripts – for example, one which allows tarballing and lrzipping a chosen directory in a single command. Actually, lrzip is more of an archive utility, and not just a compressor.

lrzip -D -p 8: 334 504 383 bytes
In this default (LZMA) mode, lrzip starts with 1 thread, but eventually uses more and more cores (though never all 8, or I haven’t noticed this). Decompressing seems to use more threads, but that also depends on the back-end used (the slower it is – the more threads will be used, e.g. ZPAQ versus LZO).

test.fastq – Compression Ratio: 6.648. Average Compression Speed: 3.113MB/s.
Total time: 00:11:21.85
lrzip -D -p 8 test.fastq: 681.84 s, 3331080 Kb

Decompressing…
100% 2120.84 / 2120.84 MB
Average DeCompression Speed: 124.706MB/s
[OK] – 2223860346 bytes
Total time: 00:00:17.13
lrzip -t -p 8 test.fastq.lrz: 17.21 s, 2567608 Kb

Decompressing…
100% 2120.84 / 2120.84 MB
Average DeCompression Speed: 117.778MB/s
Output filename is: test.fastq: [OK] – 2223860346 bytes
Total time: 00:00:17.59
lrzip -d -p 8 -D test.fastq.lrz: 17.67 s, 2567664 Kb

In the default LZMA mode, lrzip is significantly slower than even bzip2, and has somewhat worse compression ratio. Yes, this is the 3rd major test disappointment.

gzip back-end: lrzip -g -L 9 -D -p 8: 430 013 769 bytes
Despite specifying -p 8, lrzip mostly operates in 1 thread, and only sometimes in 2 (probably invokes gzip library). Testing is also done with 1 thread only, but is very fast (but slower than plzip). The -L 9 option is supposed to be translated into -9 for gzip; as this normally has nearly no effect, it wasn’t used in the following lrzip tests.

test.fastq – Compression Ratio: 5.172. Average Compression Speed: 0.704MB/s.
Total time: 00:50:11.34
lrzip -p 8 -g -L 9 -D test.fastq: 3011.34 s, 2745520 Kb

100% 2120.84 / 2120.84 MB
Average DeCompression Speed: 163.077MB/s
[OK] – 2223860346 bytes
Total time: 00:00:12.71
lrzip -t -p 8 test.fastq.lrz: 12.79 s, 2577632 Kb

Decompressing…
100% 2120.84 / 2120.84 MB
Average DeCompression Speed: 163.077MB/s
Output filename is: test.fastq: [OK] – 2223860346 bytes
Total time: 00:00:12.88
lrzip -d -p 8 -D test.fastq.lrz: 12.95 s, 2577728 Kb

And again, compression speed and ratio are worse than for bzip2…

LZO back-end: lrzip -l -D -p 8: 766 520 776 bytes

test.fastq – Compression Ratio: 2.901. Average Compression Speed: 4.690MB/s.
Total time: 00:07:32.89
lrzip -l -D -p 8 test.fastq: 452.88 s, 2714452 Kb

Decompressing…
100% 2120.84 / 2120.84 MB
Average DeCompression Speed: 212.000MB/s
[OK] – 2223860346 bytes
Total time: 00:00:10.58
lrzip -t -p 8 test.fastq.lrz: 10.66 s, 2582516 Kb

Decompressing…
100% 2120.84 / 2120.84 MB
Average DeCompression Speed: 192.727MB/s
Output filename is: test.fastq: [OK] – 2223860346 bytes
Total time: 00:00:11.32
lrzip -d -p 8 -D test.fastq.lrz: 11.39 s, 2582504 Kb

No comments.

bzip2 back-end: lrzip -b -D -p 8: 353 473 476 bytes

test.fastq – Compression Ratio: 6.291. Average Compression Speed: 4.473MB/s.
Total time: 00:07:53.95
lrzip -b -D -p 8 test.fastq: 473.94 s, 2781104 Kb

Decompressing…
100% 2120.84 / 2120.84 MB
Average DeCompression Speed: 68.387MB/s
[OK] – 2223860346 bytes
Total time: 00:00:30.69
lrzip -t -p 8 test.fastq.lrz: 30.77 s, 2583156 Kb

Decompressing…
100% 2120.84 / 2120.84 MB
Average DeCompression Speed: 66.250MB/s
Output filename is: test.fastq: [OK] – 2223860346 bytes
Total time: 00:00:31.92
lrzip -d -p 8 -D test.fastq.lrz: 32.00 s, 2583108 Kb

Hadn’t I done all of these simple tests myself, by now I’d think that this test was rigged to show how good pbzip2 and lbzip2 are at compressing FASTQ files

ZPAQ back-end: lrzip -z -D -p 8: 292 380 439 bytes

test.fastq – Compression Ratio: 7.606. Average Compression Speed: 2.804MB/s.% 7:100%
Total time: 00:12:36.51
lrzip -z -D -p 8 test.fastq: 756.51 s, 3585740 Kb

Decompressing…
100% 2120.84 / 2120.84 MB 1:100% 2:100% 3:100% 4:100% 5:100% 6:100% 7:100%
Average DeCompression Speed: 3.970MB/s
[OK] – 2223860346 bytes
Total time: 00:08:54.57
lrzip -t -p 8 test.fastq.lrz: 534.65 s, 2583424 Kb

Decompressing…
100% 2120.84 / 2120.84 MB 1:100% 2:100% 3:100% 4:100% 5:100% 6:100% 7:100%
Average DeCompression Speed: 3.759MB/s
Output filename is: test.fastq: [OK] – 2223860346 bytes
Total time: 00:09:24.27
lrzip -d -p 8 -D test.fastq.lrz: 564.36 s, 2583460 Kb

Finally!!! We have compression better than bzip2! But it is also much slower than bzip2 (and some 12 times slower than pbzip2), so not really an option. Alas. And decompression time is the worst in the test – almost 10 minutes for what plzip does in under 7 seconds! (I do realize that compression ratio is also different – but not that much.) I wonder if slow lrzip speeds have anything to do with test.fastq being effectively in RAM? I do not know if there are any performance penalties to mmaping a file which is already on a RAM-mounted partition.

The test.fastq file that I’ve used was somehow really hard for the tested compressors to tackle as fast and as good as lbzip2 and pbzip2 could…

Questions? Comments? Improvements, including plots of these figures? Comment below.

• Google Keep, an awesome note-taking and to-do lists application with a really good web-interface, and free;
• Trello, convenient lists/projects/tasks management platform (especially for group work), and free;
• Google Calendar, the de facto calendar standard for Android phones, and free;
• my A5 format weekly paper planner, and… the only not free component.

It is easy to see that I am using too many tools.

In an effort to use less tools, and also to try some of the features of TSW, I’ve performed a brief search for GTD/TSW-compatible Android apps.

TSW website is built around the Evernote app. However, I am not sure if this would be a good solution for me, as I have been already using Evernote since several years for longer-term note-keeping, and thus already have a bunch of notepads, notes, and tags there. Moreover, Evernote’s website mentions something about “offline notes” in the Premium (non-free) tier for mobile apps; this hints at the requirement to have internet connectivity to be able to work with TSW+Evernote efficiently through the day.

Oh, before I forget: all the 4 tools that I am using have their purpose, with overlap between Keep and Trello.
My A5 format paper planner (weekview compact 2015) is not a simple weekly planner; it has a structure that stimulates goal-oriented planning.
More specifically, it provides means to plan:

• the entire life, by specifying (succinct) goals in several categories (personal, work, family, social, and some others);
• the next several years (there is enough space for just a few keywords for each year);
• the entire current year (as an overview or a list of goals, without too many details);
• each quarter of the current year (with more details: goals/tasks can have specific days or date ranges assigned, and have 3 priorities);
• each week has 3 priorities for what you would like to accomplish;
• there are also other important, useful, and well-designed elements, all with high attention to details.

I mostly use the paper planner for quarter-level goals and tasks.

Trello is my primary project and task management tool, both for work and personal matters (using different boards).
It also really simplifies my weekly reports: I only have to check the Done list of the primary/project work board,
and show it to my supervisor – which (showing/sharing) is also easy with Trello.

I’m using Calendar for all the events which have specific dates/times, like meetings, deadlines, celebrations, etc.

Finally, I’ve started using Keep not that long ago as a to-do list and note-taking application. It is extremely easy and quick to use, which explains this new adoption. I use it mostly as a short-term buffer for quick (shorter than 2 hours) tasks. I have 3 separate lists: home, work, and shopping The only component which is missing if I want to use TSW is tagging of individual checklist items, together with tags search. Other than that, Google Keep is plain perfect.

The first app I had a look at was DGT GTD (alpha):

• has “@-contexts”;
• has tags;
• has search for arbitrary tag combinations (both AND and OR logic);
• no web interface, uses toodledo/dropbox/ftp for sync;
• web-interface might be available through toodledo (which has its own limitations, see below);
• overall: alpha, no easy-to-use web-interface, unclear future… though otherwise seems good.

Next, I had a look at Toodledo:

• has a free, but (seemingly quite strongly) limited version; in addition, it felt
• somehow not easy to register, thus I have not tried it.

Next was MyLifeOrganized:

• way too commercial all over – you seem to need many pieces of (paid) software, (paid) cloud sync, (paid) plans…
• no web-interface and no Linux support, only Win/Mac/iOS/Android, thus have not tried this one as well.

I was leaving better contestants (like RTM, Remember The Milk) for later:

• nice, convenient, light, keyboard-friendly web-interface;
• free version syncs with web, but only once every 24 hours;
• has locations (GPS-based) and tags;
• has inbox, personal, work, study, sent pre-defined lists of tasks; you can define your own (and delete 3 of the pre-defined, if you wish);
• can search for multiple tags using brackets, logical operators, and multiple per-task attribute filters (like timeEstimate, dueDate, etc – many of these!);
• can save searches as smart lists (at least in the Android app);
• tasks cannot be ordered manually, they can only be sorted by priority, due date, or name.

I can see myself using RTM, which feels like a quality tasks-management environment. Syncing once every 24 hours is the only free version limitation that I am sensitive to, because I tend to use web-versions (Trello, Keep) while at the computer. If you are using for planning your phone only, then RTM might be a very good fit for you.

Another detail which I find inconvenient is the inability to manually sort tasks. As I know from using Keep, manually sorting smaller tasks into their logical order by dragging is quick and easy. This RTM drawback could be worked around by sorting task list by name, and devoting the first 2 characters of the task text to its number (e.g. ’06 start scaffolding’). I am still unsure about RTM.

Given the failure of the new contestants to fit my needs, I also had a quick formal look at the tools I am already using.

Evernote:

• recommended by TSW website;
• has tags and saved tag searches;
• not sure if it keeps all notes available offline – it likely needs connection to function; it may keep the most recent notes offline, though – still have to test this;
• not exactly a to-do list, thus (much more?) cumbersome to use than Google Keep (again, this wasn’t tested yet – consider this a prejudice);
• free version has a 60 MB/month data upload limit, which should be more than enough for tasks management.

I am going to try Evernote with TSW, and see if that works good enough. I’ll update the post with the results.

Google Keep:

• very easy and convenient to use checklists;
• keeps all tasks local and always available; works offline, syncs when you have connection;
• has an efficient, quick-to-use web-interface;
• does not have tagging (only colors for notes);
• lightweight in terms of size and resources needed.

I’ll keep using keep, even if some other app becomes my primary for tasks management. It is simply too good not to use.

Trello:

• has a fairly convenient web-interface (though more complicated than Keep because of more features);
• allows easy collaboration;
• supports multiple boards, containing task lists, containing tasks, containing checklists and other elements, which all together enable fairly complex project management;
• phone app caches tasks/boards that you access while online, and can later show those while offline, but
• phone app does not allow changes while offline – you must have connection for the changes to have effect;
• has tags (labels), but these are board-specific, so it is impossible to get a flat list of all tasks from all boards filtered by some labels/criteria.

Right now I have tons of tasks in Trello, so I am not going to abandon it any time soon (unless I find a perfect alternative solution). I have already seen recipes online to adapt Trello to TSW/GTD use. This will not fix the necessity for internet connection for the app to work, though. It is also quite possible that tags + global flat list of all tasks from all boards might get introduced as new features into Trello, as it is developing dynamically and new features do get added quite often… Maybe I should leave a feature request for the developers, together with a thank-you for their excellent product.

That’s it for now, I’ll update after some more app testing.

Update 1: Trello can be quite convenient as a general GTD-like (but not quite TSW-like) app. I’ve set up a separate GTD board, with lists inbox, now, next, later, 8 project/watching/reading lists, 2 goal lists (one for the current year, one with general goals), some day, contemplate (no clear decision if an item has to be done at all), waiting, done, and discarded (something from any of the other lists which is [no longer] worth doing).

Update 2: Google Keep now has labels (aka tags)! (It now also has recurring reminders, which is cool as well.) Tags seemed to be the only thing keeping (no pun intended) Keep from being a perfectly simple and lightweight GTD/TSW app! Or so I thought. Unfortunately, there does not appear to be any way to search by several labels right now. You can search by note colors, and can select a single label to list all notes that have it, but no multiple labels… One last step missing to perfection?

Leave comments if some of my statements seem wrong, or if you know a solution which would be capable of satisfying my needs

I really hope that phone manufacturers offer something that:

• is about the size of E71, possibly slightly higher/wider/thicker
• has a physical QWERTY keyboard, either E71-style or a slider
• runs Android Lollipop
• has decent (but not necessarily the best) smartphone hardware (5-8+MP camera, 1.4+GHzCPU, 1.5+GB RAM, 8+GB internal storage, etc)
• has a good screen, e.g. HD (~4.3-4.7″) for a slider-keyboard version, or half-HD for Nokia-style keyboard
• is minimally waterproof (can withstand heavy rain for 30 minutes)

Reasonable price would also be welcome…

• it does mention the software tool implementing the maximum likelihood approach,
• it is likely the earliest mention of the PHYLIP software (which was distributed since around 1980),
• it refers to a journal indexed by pubmed, and
• according to Google Scholar, it was already cited over 6660 times

Below is a short summary table I’ve used to compare available solutions. Feel free to contribute to the table in the comments – I’ll update the post, then.

Dropbox vs BitTorrent Sync vs AeroFS vs SparkleShare

This information is not available in one piece, but there are some of the pieces at the following URLs:

A mistery hidden in the Genesis Block
Who is Satoshi Nakamoto?
Four years and $100 million later, Bitcoin’s mysterious creator remains anonymous
Ted Nelson Says That Bitcoin’s Satoshi Nakamoto Is Shinichi Mochizuki
Where in the World is Satoshi Nakamoto?
The Rise and Fall of Bitcoin

Below is a huge graphical brief history of Bitcoin, including the continued growth of its exchange rates.

Redmine is also really cool, and is actually more feature-reach than what BitBucket has to offer, but maintaining it needs just a tiny bit more time and attention than I’m willing to spend these days. So, migration it is!

Redmine has issue 3647 titled “Data import/export system”; it is not resolved, but has a number of links to other resources. Like the redmine exporter at hostedredmine.com, which provides free hosted redmine service. Redmine itself has REST API, though I have no idea if it allows exporting all the data I may need. There’s also an XLS export plugin, but it has to be installed first, and I’m too lazy There’s also TaskAdapter, but they do not support BitBucket (yet?).

For the complete backup, I think of using the pure-ruby redmine project data export script. To migrate issues only, I’ll consider the redmine2bitbucket script.

P.S. Not implying anything (yet?), but my previous migration was from Trac to Redmine… At that time, Trac seemed to have less features than I wanted. And now I’m migrating back to “less features”, but with a benefit of no support required from me.

I had personally settled on using pbzip2 for these simple reasons:

• performance scales quasi-linearly with the number of CPU cores (until one hits an I/O bottleneck);
• when archive is damaged, you are only guaranteed to loose the damaged block(s) of size 100-900 KiB – remaining information might be salvable.

Compared to pbzip2, neither gzip nor 7z (lzma) offer quasi-linear speedups proportional to the number of CPU cores.
pigz, the parallel gzip, does parallelize compression, but gzip compresses not as good as bzip2, and decompression is not parallel like in pbzip2.
7z is multi-threaded, but it tops out at using 2 CPU cores (see links below for tests).

pbzip2 is also quite a good choice for FASTQ data files: even if a few blocks get lost due to data corruption, this should not noticeably affect the entire dataset.
Specialized tools for FASTQ compression do exist (see e.g. this article, also Fastqz, fqzcomp, and samcomp project pages.) I think I liked fastqz quite a bit, but I still have to examine data recoverability in the case of archive damage. It is possible to use external parity tools which support file repair using pre-calculated recovery files – like the linux par2 utility, also for bzip2 archives and any other files in general – but adding parity file may negate the higher compression ratio benefits. Also, if there is no independent block structure of the archive, insufficient parity file may lead to the loss of the entire archive. In other words, this still has to be tested.

Now the long-promised web-links!

• gzip vs bzip2: bzip2 is ~2.5x slower to compress, ~10x slower to decompress, and produces 26% smaller file
• gzip, bzip2, lzma: bzip2 best on low-entropy data; gzip is the fastest; lzma is the slowest, and also not the best
• gzip, bzip, 7z: 7z decompresses faster than bzip2
• 7z, bzip2: 7z only uses up to 2 cores, bzip2 can use all; for the same time of compression, 7z yields smaller file – e.g. 7z fast 926, bzip2 maximum 987MB, both took 7 minutes
• 7z, gzip, compress, bzip2 (graphs): bzip2 is at least 2x faster than 7z, and up to 2x slower than gzip; bzip2 is the slowest at decompression, 7z is up to 2x better, while gzip is easily 6x faster
• bzip2, gzip: superuser answer provides a simple 5-axis ranking:
  decompression speed (fast > slow): gzip, zip > 7z > rar > bzip2
  compression speed (fast > slow): gzip, zip > bzip2 > 7z > rar
  compression ratio (better > worse): 7z > rar, bzip2 > gzip > zip
  availability (unix): gzip > bzip2 > zip > 7z > rar
  availability (windows): zip > rar > 7z > gzip, bzip2
• Gzip vs Bzip2 vs LZMA vs XZ vs LZ4 vs LZO (with nice tables): bzip2 is up to 3x slower to decompress; lzma may use up to 16x bzip2′s memory for decompression, which is 64 mb; bzip2 only needs up to 7.2 MB for compression; lzma needs up to 670 MB; fastest lzma is as fast as gzip, but produces smaller files; bzip2 compression time is nearly unaffected by -1..-9 settings; with the same running time, lzma-3 and bzip2-9 produced the same-size file
• lzop vs compress vs gzip vs bzip2 vs lzma vs lzma2/xz: xz-2 is comparable to bzip2-3 in file size, but is faster to compress and decompress; xz-0 is overall better than gzip-9
• gzip, bzip2: bzip2 is better at heterogeneous data
• gzip, bzip2, xz: bzip2 here is faster and smaller than gzip, while still slow to decompress

Previously, I’ve used gitosis to setup git repository hosting on my server. I’m still using it for long-living projects, but I’m now lazy enough to dislike the steps needed to setup a new repo (and I’m creating more and more new repos, some of which are likely to die very young). Some kind of GUI would help, but gitweb seems not that useful to me (here’s how to make it work with gitosis, and another recipe, or maybe just try gitosis-web or gitosis-web-admin).

Another downside is that gitosis is no longer actively maintained and was even removed from ubuntu repositories. Suggested course of action for gitosis users is to migrate to gitolite. However, basic design of gitolite is the same, so personally (looking for something easier to use) I see only minor gains in this migration (which I’ll have to perform anyway sooner or later).

Another interesting self-hosted option is girocco. Too bad I have absolutely no experience with http://repo.or.cz/, so it’s hard to tell if girocco is convenient to use or not… Comments are welcome.

Using dropbox for git repositories (also here) seems a nice and fairly easy option, with only a few downsides: it’ll eat your dropbox space (which is still much more than you get from free git hosters), and it isn’t that easy in a multi-user environment. Also, you will have to setup dropbox on your headless servers where you may want to run your code, which isn’t exactly what I’d want to do. Same arguments apply to git on google drive.

An alternative to various self-hosted systems would be to use an existing system with free private projects. Git wiki has a list of hosts to start with.

Here’s a brief summary of the options I’ve found relatively attractive (see below for my experience with 3 of the listed services). (See also this recent comparison.)

Initially, I found GIT Enterprise and Assembla to be the most attractive options to try. After trying both, I found Assembla faster and generally more attractive to work with. It wasn’t immediately obvious how to create more than one source repository, but after figuring that out everything is smooth.

However, after trying BitBucket, I had immediately switched all my assembla repositories to it BitBucket is just like github, but with free private repositories. It also has an issues tracker and a wiki. It even allows small teams to work on private repositories!