Autarchy of the Private Cave

Recently in hacker news the following was posted: ZFS is the FS for Containers in Ubuntu 16.04.

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?
Read the rest of this entry »

I am using an excellent photo-management suite digiKam, which offers 3 lossless compressed formats for photos versioning and storage: PNG, JPEG 2000, and PGF. I wanted to know which one should I use, which urged me to perform this comparison.

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.

Read the rest of this entry »

There is no way I’m aware of to do what the title says. However…

I’m sure that you are aware of the fact that floats representation in any programming language is limited by the precision of the internal binary representations. In other words, you can never have an exact float representation – there will always be some precision associated with the float you are working with. The simplest example is the difference in precision between the float and double types in C.

Suppose I have the following code fragment:
[C] if ( result.score >= input->raw_cut_off ) [/C]

Both result.score and input->raw_cut_off are of type float, and can have positive and negative values. When compared with the greater than or equal ( >= ) operator, it is not always that condition is true – for the precision reasons shortly mentioned above.

As I already said, there is no precision specification for equality operators in C. But it is quite simple to “invent” precision specification; e.g. if I wanted to test for equality only, I could write
[C] if ( fabsf( result.score – input->raw_cut_off ) < 0.000001 )[/C] In this example, I'm effectively asking for 6-digit precision for the equality comparison of floating-point values. Note, that if you replace that 0.000001 with the actual precision limit of the floating type you are using, you will be "exactly" comparing floating-point numbers - up to that type's precision, of course .

The first-most example with the >= operator can be rewritten as
[C] if ( result.score > ( input->raw_cut_off – precision) ) [/C]
where precision is exactly what it is named, e.g. precision = 0.000001.

Sources used:

• comment by Randy A. Ynchausti
• scientific programming