If you are like me and you like your user interfaces to be as dark as possible, you have the dark mode preference of your browser enabled. You may have noted that this site has now a dark mode which is activated by default. This is done by querying the prefers-color-scheme setting in the browser. This post describes how this is done, and it discusses a few tweaks I have implemented design-wise to simplify things and remove useless visual elements.

I have a Wacom Intuos graphics tablet for my occasional drawing and signing. By default, the tablet area is mapped to the whole screen area, making it almost unusable if you are using two or more monitors, as your drawing application of choice (Krita in my case) usually resides in one display only. Well, turns out there’s a very easy way to map the tablet to a single display in Linux with xinput.

A while ago Erwan Leroy, a VFX professional and trainer, contacted me with some questions regarding the catalogs in Gaia Sky. Basically, he was trying to decode the binary format used in Gaia Sky to load the stars using a Python script. Of course, my documentation was lacking in that very aspect, so I walked him through the format and then improved the docs. Today, he has come back to me to share his results.

In my re-implementation of the Gaia Sky level-of-detail (LOD) catalog generation in Rust I have been able to roughly halve the processing time, and, even though I do not have concrete numbers yet, everything points towards a drastic decrease in memory usage as well. In this project, I need to read a metric ton of gzipped csv Gaia catalog files, parse and process them into a functional in-memory catalog with cartesian positions, velocity vectors, RGB colors, etc. Then I need use them to generate an octree that represents the LOD structure, and finally write another metric ton of binary files back to disk. Using memory mapped files helps a lot in avoiding copies and speeding up the reading and writing operations; that’s something I tried out in the Java version and have come to also re-implement in Rust. Here’s the thing though: working with memory mapped files in Java is super straightforward. In Rust? Not so much. And the lack of available documentation and examples does not help. I was actually unable to find any working snippets with all the parts I needed, so I’m documenting it in this post in case someone else is in the same situation I was.

A little over a year ago, in January 2020, I got myself a QNAP TS-351-2G 3-bay NAS in order to store all of my and my family’s data in a failsafe RAID configuration. I opted for the somewhat unconventional 3-bay setup in an attempt to trade off limited physical space at home with storage capacity. I don’t have much space in my living room for a big NAS, and the 2-bay options, albeit being very compact, are limited to RAID-1, where half of the space is used for storage and the other half is used for redundancy protection (data is basically mirrored on the second drive). In QNAP’s website there are three 3-bay Home options: the entry-level TS-332X, the middle-range TS-328 and the high-end TS-351. So I thought to myself, “I’m getting the high-end unit, how bad can it be?”. Well, now that I have been using this NAS for a year I think I can answer this question.