bkil vs. programming

While it may sound like utter nonsense at first, on second thought maybe it really is: cron.standard: please provide configuration facility to avoid given filesystems Someone should really be thinking more about a serious reminder system. I've put together an iotop oneliner that logs disk actions with timestamps which pointed me to anacron. Daily mlocate updating was easy to reproduce and fine tune: simply add your HDD mount points to tho PRUNEPATHS variable of /etc/updatedb.conf . On the other hand, it took a few more attempts and many days in total to track down what causes the HDDs to still start up. When trying to further examine the issue by hand, /etc/cron.daily/standard didn't start them up on first look, perhaps because of caching. However, today after randomly testing things again, it finally did, which took me to adding CHECK_LOSTFOUND=no to /etc/default/cron . It's a pity though, that I'll have to use an alarm clock from now on.

One day, I was playing with a chroot jail. This whole incident has taken place some months ago. I wanted to test if I could install software from user mode because my apt-get was doing a system update. Well, building from source via "apt-get -b source" would have also solved the issue, though dependency handling in this case is not automatic if I understand correctly. In order for this process to take as little overhead as possible, I wanted to simulate a manual copy-on-write filesystem by creating links to the parts that are common with my root system, and recreating directories which are partially different. I first tried to use symbolic links, but I had to realize that relative links that point outside the sandbox were dysfunctional. Hence I made a hardlink for my root in the chroot. Well, it was a read-only bind-mount to be more exact. Note that I did succeed previously with a different system and kernel (Gentoo 2005.x) by using symbolic links, that's why I gave it a...