• An example of kqueue

    The documentation of kqueue is quite decent but it lacks some examples. After reading its main manual pages (kqueue(9) and kevent(9)), I wasn’t sure about how it worked, so I had to write a test program to verify its behavior. Let’s start by analyzing the test program to later see its full code. The program will monitor changes to the /tmp/foo file and will print messages whenever it is deleted, modified or their attributes change.

  • FAM and kqueue

    The File Alteration Monitor, or FAM for short, is an utility that monitors changes made to files and directories and delivers asynchronous notifications to applications interested in them. GNOME uses it to keep Nautilus windows in sync with the on-disk contents, among other uses. For example, if you have your home folder open, and you do touch ~/foo from a terminal, you can see how the folder immediately updates its status to show the new file.

  • Trying Bogofilter...

    A few days ago I did some maintenance of the software installed on my small server: among other things, the packages in it were outdated and I wanted to get the Libtool changes in (something that happened in pkgsrc...). So, I seized this oportunity to give Bogofilter a try, because SpamAssassin brought the machine to its knees. I configured Bogofilter to parse all my incoming mail, fed to it by Procmail, following the examples given in the manual page; a painless process.

  • Pipes over SSH

    Today I had to copy a bunch of files and symlinks to a remote machine. My first attempt was to use scr directly: $ scp -r directory host:/some/directory But that went wrong: the symlinks were not preserved, which resulted in several files being transferred multiple times. A simple solution could have been to create a tarball of the whole directory, copy it to the remote host and unpack it there. However, I thought.

  • New versioning scheme for NetBSD

    Although this has not been announced publicly yet, it is not a secret anymore because the version changes are visible. NetBSD has changed its versioning scheme to a less confusing one. Up until now, major releases increased the number of the previous version by one; i.e., after 1.4 we had 1.5, and then 1.6... all of these being releases with lots of new features. There were minor releases too, used to provide enhancements to major releases (mostly bug fixes); their name was the same as the major version they enhanced, but with a third digit in them, like 1.

  • The AM_GCONF_SOURCE_2 macro

    GConf comes with an m4 file to ease its usage from third party configure scripts; it provides a macro, known as AM_GCONF_SOURCE_2, which provides many features (and most importantly, encapsulates all GConf related stuff). Among these, it is used to determine the directory where .schemas files should be installed, a setting that can be fine-tuned by the end user through the --with-gconf-schema-file-dir argument. However, many configure scripts use this macro incorrectly.

  • NetBSD/mac68k soft-float support

    Two days ago I commited some code to NetBSD's CVS HEAD to let the mac68k port be built with soft-float support. All this work was originally done by Bruce O'Neel, so if you want to thank somebody, thank him. In order to build a release with this feature enabled, it's as easy as passing the -V MKSOFTFLOAT=yes argument to the build.sh script. But what's known as soft-float? Simply put, it's a way to build binaries that do not use the FPU at all.