WangLu's Notes

I recently tried to install Qubes OS alongside an existing Windows installation. It turned out to be surprisingly difficult—way harder than my last attempt—likely due to a combination of my encrypted  /boot  setup and older hardware. Here are some notes from the process. Shrinking an NTFS Volume I needed to free up some space from a Windows NTFS volume. Normally, this just takes a few clicks in Disk Management. This time, however, Windows reported a "shrinkable volume" that was suspiciously small. Following  this answer , I tried the standard fixes: Disabled hibernation ( powercfg /h off ) Disabled the pagefile Disabled system protection This increased the shrinkable volume a bit, but nowhere near the actual free space left on the partition. Digging into the Windows Application logs in Event Viewer, I finally found the culprit:  The last unmovable file appears to be: \$Mft::$DATA . It turns out  $Mft  is a special block in NTFS that cannot be easily moved, ...

I've been running Qubes OS on Machine A alongside Windows for a while. My setup involved storing the unencrypted  /boot  partition and the LUKS header on an external USB drive. Recently, I planned to install Qubes on Machine B, also in a dual-boot configuration. However, the complexity jumped significantly: Machine B has Secure Boot enabled because BitLocker requires it. On previous installs, I grew tired of toggling Secure Boot in the BIOS every time I switched operating systems. I only have one USB drive. Managing separate  /boot  partitions for two different Qubes installations on a single thumb drive is messy. After some experimentation, I found a way to solve both problems. Sharing One USB Drive for Multiple Qubes Installations The solution is elegant: Don't store  /boot  on the USB drive. Instead, move  /boot  to the encrypted internal disk partition. The USB drive's only job is to unlock that partition and hand over control to the system. O...

After writing a Nonogram solver, I decided to tackle a Sudoku solver to practice Rust. My goal wasn't just to support classic Sudoku rules, but also to handle variants like Thermometer, Arrow, and Cage etc. 1. Brute Force It is fairly easy to write a brute force or backtracking algorithm. This approach is sufficient for most classic Sudoku puzzles, but it becomes unbearably slow as soon as variant rules are introduced. I considered this step a warmup—a baseline to improve upon. 2. Constraint Propagation Here, I tried to introduce "logical thinking" to the algorithm. I used  u16  as a bitmask to represent the possible values of a cell. Whenever a cell's state changes (due to guessing, backtracking, or propagation), the algorithm consults all constraints to eliminate impossible candidates. While Nonogram is technically an NP-Complete problem, in practice, my constraint-propagation solver (without guessing) can solve almost all puzzles found online. I’ve only seen one ex...