Here is Kite’s farewell for you to read.

Kite did open-source many parts of their technology/software stack, though I didn’t check how comprehensive those parts are, and if that is anywhere near enough to fork/continue their work.
I wonder if there already exists an open-source project focusing on ML-based code completion for e.g. Python – let me know in the comments if you know one!

Kite cites two reasons for a shutdown: 1) technology not being quite there yet, and 2) failure to monetize.
Kite had up to 500k daily developers using the platform, but apparently extremely few were willing to pay for it.
If you do look at current ML code assistants, there seems to always exist at least some free tier – I wonder if that is forced by the same lackluster, non-paying developers attitude as for Kite.

Kite’s farewell had another interesting number: 18%.
That is by how much individual developer’s productivity could increase thanks to Kite’s assistance.
This isn’t bad at all; for a team of 5 largely independent developers, it’s almost one extra “affordable” developer.
Kite was striving to achieve a “10x improvement”, but at least to me the 18% improvement sounds good enough for sales.

I’m very curious to try some of these assistants out.
I can imagine them to be very helpful for relatively experienced developers when starting to work with a new library/ecosystem – for example, OpenVision Python bindings.
Even the common autocomplete can significantly simplify “onboarding” to a new library – and a more intelligent autocomplete should be able to help with boilerplate code (that you usually don’t have when you begin), as well as with some idiomatic expressions and statements.

Have you already played with some of the smarter code assistants?
What was your experience?
Please share

This will duplicate both metadata and btrfs system data.
Verify with: sudo btrfs fi df /toplevel:

Data, single: total=10.00GiB, used=3.88GiB
System, DUP: total=64.00MiB, used=4.00KiB
Metadata, DUP: total=512.00MiB, used=286.18MiB
GlobalReserve, single: total=96.00MiB, used=0.00B

Explanation: on SSDs, mkfs.btrfs creates metadata in single mode (because of widely spread SSD deduplication algorithms negating duplicate entries). However, second copy of metadata increases recovery chances, especially so if your SSD does not deduplicate writes. Hence the desire to add metadata/systemdata duplication after the filesystem is created.

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.

the notebook you are searching in has been moved or renamed since the saved search was created

(which is not true).

I had this problem, and found a solution.

Go to your Evernote on a client where you can edit saved searches (Windows for me),
edit all the searches, and make sure that notebook name is quoted in the search (and also, possibly, with all proper letter cases).

I found this solution by first creating a search from the web-beta interface, it looked like this: notebook:"Mynotebook" tag:1-now
All the crossed-out searches (despite working totally fine on Windows) looked like this: notebook:Mynotebook tag:1-now
or even like this (note the lower-case 1st letter of the notebook name): notebook:mynotebook tag:1-now.

After editing saved searches and synchronizing, they all appear (and work) just fine in the beta web-interface.

If you cannot edit your searches right now, there is another workaround: all the saved searches work fine for me from the Shortcuts menu (a star in the left panel).

Hope this helps!

There is an easy solution to get Notes-only without editing the PDF.

If you have a PDf printer installed (most Linux distributions, and Windows 10), just do File -> Print from Impress,
then under the Print sub-header choose Notes from the Document drop-down (see picture).
Make sure to set the proper paper format for the PDF printer (A4 in my case).
Then print, and save the resulting PDF.

Sources:

• question on ask.libreoffice.org
• LibreOffice bug report

I wanted to use it with compressed (gzipped/bzipped2) FASTQ input files.
As I do not need to store decompressed input files, the most efficient solution is to use pipes.
This works well for a single file, but not for 2 files (paired-end reads).

For 2 files, named pipes (also known as FIFOs) can be used.
You can create a named pipe in Linux with the help of mkfifo command, for example mkfifo R1_decompressed.fastq.
To use it, start decompressing something into it (either in a different terminal, or in background), for example zcat R1.fastq.gz > R1_decompressed.fastq &;
we can call this a writing/generating process, because it writes into a pipe.
(If you are writing software to use named pipes, any processes writing into them should be started in a new thread, as they will block until all the data is consumed.)
Now if you give the R1_decompressed.fastq as a file argument to some other program, it will see decompressed content (e.g. wc -l R1_decompressed.fastq will tell you the number of lines in the decompressed file); we can call program reading from the named pipe a reading/consuming process.
As soon as a consuming process had consumed (read) all of the data, the writing/generating process will finally exit.

This, however, does not work with prinseq-lite.pl (version 0.20.4 or earlier), with a broken pipe error.

Named pipes are very similar to usual files, with two major differences:

• named pipes are not seekable: you cannot move file pointer (at least not backwards, not sure about skipping forward);
• you cannot arbitrarily close/re-open a named pipe from the consuming end: closing a pipe on the consuming end also closes it for the writing/generating process.

The reason why prinseq-lite.pl does not work with named pipes is that it performs file format checking first – by opening the file, reading the first 3 lines, and closing it.
Closing a named pipe causes broken pipe for the writing process, and when prinseq-lite.pl attempts to open the pipe again – it succeeds, but there is no data there anymore, so it just sits and waits for data

I’m ok with a quick and dirty solution, so here it is: prinseq-lite.pl patch to enable mkfifo named pipes as input files (also local prinseq-lite.pl.patch).
WARNING: this patch simply disables file format checking!

I must admit the 16.04 demo does look very pleasant to work with.

However, bringing in ZFS into Linux reminded me of a fairly recent comparison of ZFS and btrfs that I had to do when building my home NAS.
At that time, few months ago, I’ve arrived (among others) at the following conclusions:

• ZFS on FreeBSD is reliable, though a memory hog;
• on Debian, OpenVault seems to be a good NAS web-management interface;
• on FreeBSD, FreeNAS is good (there is also Nas4Free fork of an older version, but I haven’t looked into it deep enough);
• running ZFS on linux (even as a kernel module) is the least efficient solution, at least partially because kernel’s file caching and ZFS’s ARC cache are two separate entities;
• although btrfs offers features very similar to ZFS, as of few months ago OpenVault did not offer btrfs volumes support from the web-interface.

In the end, I’ve decided to go with FreeNAS, and it seems to work well so far.

But had anything changed in the btrfs vs ZFS on Linux field?

Luckily, in the comments section of the original post Brian Mullan linked to a recent Bachelor degree project titled A performance comparison of ZFS and btrfs on Linux (local copy). Here’s an excerpt from the abstract:

The main conclusions that can be drawn from the analysis of the gathered data is that
Btrfs has improved greatly in recent years and is today showing great throughput whereas
ZFS on Linux is performing considerably worse than Btrfs.

The document is definitely worth looking at – actual results start on page 22, and there are figures for easy comprehension
XFS and ext4 are also added to the comparison, so if you are thinking about changing your FS – the document may help you, too.
The only area where ZFS excelled was database-like load; btrfs and XFS were the leaders in the majority of other tests.
(In fact, somewhat lower btrfs performance for database-like loads seems to be a well-known thing, and can be cured with the nodatacow mount option – see e.g. this nice rant about PostgreSQL on btrfs.)

I do believe that ZFS is still more stable than btrfs, but I’m also still not convinced that ZFS and Linux are a good combination.

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

DEFAULT -d sat -H -f -p -t -W 0,40,45 -n standby -S on -m example@example.com
# Attributes 1, 230, and 231 are very important (-r 1! -r 230! -R 230! -r 231! -R 231!), but likely covered by -t.
/dev/sda -s (S/../../6/01|L/../(01|02|03|04|05|06|07)/7/00) -C 0 -I 189 -I 194
# -a implies -f and -p (through -t)
DEFAULT -d sat -a -I 194 -W 0,40,45 -n standby -o on -S on -m example@example.com
/dev/sdb -s (S/../../6/02|L/../(01|02|03|04|05|06|07)/7/02)
# This drive does not decrement Offline_Uncorrectable (198) after re-allocation,
# so only monitoring for increase, not for non-zero value.
/dev/sdc -s (S/../../6/03|L/../(01|02|03|04|05|06|07)/7/04) -U 198+
# This drive has 40 “normally”.
/dev/sdd -s (S/../../6/04|L/../(01|02|03|04|05|06|07)/7/06) -W 0,42,45

Note: explanations below are intentionally simplified; please consult man smartd.conf for more precise, complete, and up-to-date information.

Ok, so what do these settings mean, and how is this different from default settings?

By default, smartd assumes a DEVICESCAN directive, which auto-detects all HDDs, and enables reasonable default monitoring of SMART attributes.
However, there are several benefits to individually specifying your disks:

• less verbose smartd startup log messages (no messages about auto-detection and missing attributes)
• ability to run scheduled offline, short, and long SMART self-tests
• ability to monitor or exclude attributes individually for each drive (including temperature)

Reasonable default mentioned above is the -a option, equivalent to the following individual options:

-H -f -t -l error -l selftest -C 197 -U 198

This is important to know, because my only SSD has no attribute 197, no self-test log, no error log, and no automatic offline testing.
But I still want to start with quasi-default settings, and that is why the first configuration line includes all the options from -a, except those that my SSD does not support:

DEFAULT -d sat -H -f -p -t -W 0,40,45 -n standby -S on -m example@example.com

Here and in the -a options above,

• -H: monitor overall health status (passed/failed)
• -d sat: HDD type is SATA
• -f: check if any of the Usage attributes (those not marked as Pre-fail) are below the manufacturer-set thresholds
• -p: report changes in Pre-fail attributes (implied by -t below, so can be omitted)
• -t: same as -p (above) with -u (report changes in Usage attributes)
• -W 0,40,45: log a message if drive’s temperature goes above 40 degrees Celsius; log a critical messages if above 45
• -n standby: do not wake-up (spin-up) the HDD if it is in sleep or standby mode (in which platters do not spin)
• -S on: enable attributes auto-saving
• -m example@example.com: address (or several comma-separated addresses) to receive warnings from smartd

The DEFAULT directive is for convenience: options set by this directive apply to all the individual disk configuration lines below, until a different DEFAULT line is encountered.
Here, I had used it to separate all /dev/sda options into 2 logical groups: supported defaults, and drive-specific configuration.
SSD’s configuration is

/dev/sda -s (S/../../6/01|L/../(01|02|03|04|05|06|07)/7/00) -C 0 -I 189 -I 194

Here,

• -C 0: explicitly disable attribute 197 monitoring (which is not present in this SSD)
• -I 189 and -I 194: ignore attributes 189 and 194 (they both show temperature in this SSD)
• -s (S/../../6/01|L/../(01|02|03|04|05|06|07)/7/00): schedule for short and long tests

As for the tests…
I want short self-tests every Saturday night, between 1 AM and 5 AM (shifted by 1H for every disk).
I want long self-tests on the 1st Sunday of every month, between midnight and 8 AM (shifted by 2H for every disk).
This is exactly what is encoded in my configuration for all drives. The easiest way to figure out the format is to read the relevant section of man smartd.conf.

The remaining 3 drives are all HDDs, so I had defined a different common DEFAULT for them.
The only new option that we see is -U 198+, which instructs smartd to only report increases of the Offline_Uncorrectable (198) attribute.
This is necessary because my /dev/sdc does not decrement this attribute after sector re-allocation.

I hope you found this post helpful.

Running a short SMART self-test (sudo smartctl -t short /dev/sdc) produced a read error at sector 1289:

Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
1 Short offline Completed: read failure 80% 22339 1289

Looking at the partition table of /dev/sdc, we see that this sector is outside of the only RAID partition on the disk, which starts at sector 2048:

Device Boot Start End Blocks Id System
/dev/sdc1 2048 117209087 58605088 fd Lnx RAID auto

To make sure that sector 1289 is re-allocated, some data needs to be written to it, e.g. with sudo dd if=/dev/zero of=/dev/sdc count=1 seek=1289.
You may also try to read the sector first, then – if successful – write it back to the disk:
i=1289 ; sudo dd if=/dev/sdc of=/tmp/sector count=1 skip=$i && sleep 1 && sudo dd if=/tmp/sector of=/dev/sdc count=1 seek=$i

Another solution (untested!) would be to read/write a bunch of sectors around the problematic one (this is similar to what badblocks -n does):

export i=1280
while [ $i -lt 1300 ]
do echo $i
# read once (count=1) 512 bytes (default ibs/obs values of dd) to a temporary file, skipping first $i ibs-sized blocks (skip=$i);
# if successful, then (wait a bit and) write the same data back to disk, skipping $i obs-sized blocks (seek=$i)
dd if=/dev/sdc of=/tmp/sector count=1 skip=$i && sleep 1 && dd if=/tmp/sector of=/dev/sdc count=1 seek=$i
let i+=1
done


After sector re-allocation both Reallocated_Sector_Ct (5) and Reallocated_Event_Count (196) SMART attributes increased from 0 to 1, while Current_Pending_Sector (197) decreased from 1 to 0. In addition, running badblocks /dev/sdc and diskscan --output diskscan-sdc-out-25-02-2015.json /dev/sdc (both in read-only mode, of course) has not shown any read errors, and another short SMART self-test also finished successfully. So, is the problem solved?

Unfortunately, Offline_Uncorrectable (198) stayed at 1, and I kept getting warning emails. Apparently, my HDD simply does not decrease the Offline_Uncorrectable (198) attribute after sector re-allocation.

In this case the proper solution is to edit /etc/smartd.conf so that it only sends emails if Offline_Uncorrectable (198) attribute increases, and not if it is non-zero. Just add this option to your HDD scan line in smartd.conf: -U 198+.

Sygic

• no way to store maps on the card
• navigation isn’t free (there is a 7-day trial)

Waze

• not offline, needs internet
• has nice social features

Osmand

• Allows maps on SD
• Free navigation
• Allows only 10 maps; for Germany, this means only 10 federal lands

Navfree

• Allows 1 country map for free
• Not sure about SD support
• Works good

Navigator

• Unlimited maps on SD with payment

Here Navigation beta

• stores maps on the SD card; voices are stored in the phone’s memory
• navigation is free, both online and offline
• you can download the entire Earth navigation maps for offline use (over 20 GB as of 2014-11-26)
• navigation test: works, but in my case GPS signal was slow to acquire and lost for some seconds quite often; could be the device, though.

Will update as soon as I am forced to really use any of these (usually I have my Garmin with me).

I am updating a multisite Drupal 6 installation. To the best of my knowledge, the only difference for Drupal 7 is that instead of the site_offline D6 variable the maintenance_mode variable is used in D7.

On Debian stable and later, you can sudo aptitude install drush and then just use it immediately after that.

Note: I recommend su webuser (or sudo -s followed by sudo -s -u webuser) before you run any non-testing drush commands, where webuser is the user which owns your web-exposed files (e.g. Debian’s default is, I think, www-data). I’ve seen a lot of recommendations to run drush as a super-user, but that does not make sense, and may actually cause problems with file ownership.

One last thing before we start: if your drush seems to work fine but hangs when untarring modules – check this solution.

1. Run some innocent command in drush to see if it produces any PHP warnings/errors you may want to fix before running actual update: drush @sites core-status. In my case, all the sites had the CacheRouter module for in-RAM caching with a server daemon back-end, which was not initialized properly when drush bootstrapped Drupal from the command line. In my case, the only working solution was to edit settings.php files of every site to comment out the CacheRouter configuration for the period of update. If you get no warnings/errors, proceed to the next step. Note: I was running drush from the Drupal’s root (directory which has top-level index.php and .htaccess files), but this should also work if you run from sites/ or even sites/sitename.
2. Here would be several more steps – copying your production website(s) to a dev-server (if you do not have one already), performing an update on the dev-server first to see if anything breaks and needs fixes, then migrating updated website(s) from the dev-server to production server. Drush actually has tools to simplify all of these procedures. However, the websites I was updating were not critical, and short downtime was not a problem, so I was updating live websites. Modify these steps as you see fit to make the process more reliable.
3. Backup databases of all your sites. With drush: drush @sites sql-dump --result-file --gzip. This puts backups somewhere into the home directory of your webuser. Backups are named with a human-readable timestamp. Of course, you can also create a manual Backup and Migrate backup, or use phpMyAdmin, or just mysqldump.
4. Backup your site’s files. This step might be unnecessary, as drush seems to backup modules it is upgrading. I would still recommend making a backup, e.g. with tar -acf multidrupal.tar.bz2 html, where html is the directory containing your multisite Drupal’s root index.php.
5. Put the websites into maintenance mode and clear all caches; see the D7-specific note above: drush @sites variable-set site_offline 1 ; drush @sites cache-clear all.
6. The actual update! The easiest way would probably be to drush @sites pm-update, but I haven’t tested that and used a process which I understand better, and which seems more reliable to me (if anything goes wrong). If in your drupal root you have sites/site1 and sites/site2, then run:
   
drush site1 pm-updatecode
drush @sites updatedb
drush site2 pm-updatecode
drush @sites updatedb

   The pm-updatecode command only updates files, and does not run database update. So with these commands I am first updating modules from site1, then running database update on all sites, then update modules of site2, and run database update on all sites again. Running drush @sites updatedb multiple times, even when there are no updates, should be safe. Take note of any warnings/errors reported, you will want to fix them later, for example:

   WARNING: Updating core will discard any modifications made to Drupal core files, most noteworthy among these are .htaccess and robots.txt. If you have made any modifications to these files, please back them up before updating so that you can re-create your modifications in the updated version of the file.

7. Disable maintenance mode. Cleaning the cache seems unnecessary, as updatedb command does that. drush @sites variable-set site_offline 0.
8. Finalize: re-enable anything disabled before the updates, fix warnings/errors you noted during the update.

This worked well for me, and I hope it works well for you.

Symptoms

• running drush @sites pm-update results in normal execution up to after answering ‘y[es]‘; then drush seems to hang indefinitely (haven’t waited beyond about 10 minutes, maybe it does produce an error after a long while);
• running the same command with --debug shows that drush hangs when trying to untar the downloaded module.tar.gz archive; there are no errors/warnings, it just hangs with no CPU usage;
• trying to untar any of the modules downloaded from drupal.org manually is also unsuccessful: tar -xzvf module.tar.gz seems to do nothing, it also hangs with zero CPU usage/time and no warnings/errors;
• interestingly, if I create some test.tar.gz locally, tar does happily extract that;
• finally, running strace tar -xzvf module.tar.gz shows a number of unexpected lines, such as references to NSS and libnss files (I am only showing some of the lines of strace output, including the last line):
  

  open(“/etc/nsswitch.conf”, O_RDONLY) = 4
  read(4, “# /etc/nsswitch.conf\n#\n# Example”…, 4096) = 683
  open(“/lib/x86_64-linux-gnu/libnss_nis.so.2″, O_RDONLY) = 4
  open(“/lib/x86_64-linux-gnu/libnss_files.so.2″, O_RDONLY) = 4
  open(“/etc/passwd”, O_RDONLY|O_CLOEXEC) = 4
  open(“/usr/lib/x86_64-linux-gnu/libnss_mysql.so.2″, O_RDONLY) = 4
  open(“/etc/group”, O_RDONLY|O_CLOEXEC) = 4
  open(“/etc/libnss-mysql.cfg”, O_RDONLY) = -1 EACCES (Permission denied)
  open(“/etc/libnss-mysql-root.cfg”, O_RDONLY) = -1 EACCES (Permission denied)
  futex(0x7fd0816e8c48, FUTEX_WAIT_PRIVATE, 2, NULL

Analysis
strace output provided enough information to understand the issue and generate a workaround. Briefly, we see tar querying users and groups information. On the system where this problem was identified, MySQL is used as a name-service back-end. This is why we see references to mysql libraries in the trace. Apparently, tar is trying to resolve some user/groups information, but for some reason does not get what it is asking in a timely manner, or possibly never gets it and will only fail/proceed when the request times out.

Workaround
Not a solution, but works: tar -xzv --numeric-owner -f module.tar.gz. The --numeric-owner switch asks tar to use numeric file/directory owner information as-is, without trying to resolve the name of the owner. This works. I have not checked strace for the workaround, but I expect to see no MySQL/NSS references in it with the switch.

To actually be able to use drush with this workaround, I had to edit drush.inc somewhere under /usr/share/drush/; look for ‘tar ‘ string, and add --numeric-owner where necessary. Do not forget that -f has to be just in front of the archive filename, otherwise your edits will not work.

• 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

• First comes make itself – the oldest and the most widely used software build tool. Stable and powerful. Still, even people who got used to using make, have some gripes about it. The most detailed list of gripes is probably here.
• SCons is a build tool written in Python. I guess I like that “configuration files are Python scripts” – maybe knowing Python is enough to use SCons, which makes SCons a better choice than make for me. SCons seems to have gained some support (scroll down for comments/discussion). There were some doubts about SCons performance (1, 2, and 3); not sure where SCons is at right now in that regard.
• waf, a Python-based framework for configuring, compiling and installing applications.
• pyDoIt is a Python automation tool. It seems to use Python syntax. It aims at bringing the power of build-tools to execute any kind of task, where a task describes some computation to be done (actions), and contains some extra meta-data. Based on the description alone, I’m quite intrigued! I wonder if anyone had already worked with pyDoIt and can share experiences?…
• Rake – Ruby make – is a simple build program with capabilities similar to those of make. Had seen a lot of positive feedback about this one – mostly regarding simplicity of use. Still [py]DoIt so far looks more attractive to me personally.
• Ruffus is a lightweight python module for running computational pipelines. Sounds like some good competition to [py]DoIt!
• Anduril is an open source component-based workflow framework for scientific data analysis. Sounds promising, though the latest downloadable version is over 400 MBs… It probably already contains a bunch of binaries and maybe even data and complete workflows for data analysis. Probably worth a look, but may turn out a little overweight for simple pipelining.
• snakemake is a scalable bioinformatics workflow engine. I get the feeling that Python is truly dominating the pipelines/workflows world: snakemake, as even the name suggests, is in Python, too. The front-page example is so simple and clear, that snakemake immediately pushes DoIt down from the 1st place! Awesome.
• Paver is a yet-another Python-based software project scripting tool along the lines of Make or Rake, designed to help out with repetitive tasks with the convenience of Python’s syntax. Sounds similar to DoIt. Have no idea how they actually compare to each other.

That is it for now.

What were your experiences with automating repetitive tasks and building simple pipelines?

My personal choice was RStudio: it is good-looking, intuitive, easy-to-use, while powerful.

Next step would be using some R-equivalent of the excellent ipython’s Mathematica-like Notebook webinterface…