Today both memory and disks are cheap enough to make this question insignificant in many cases. One can usually buy enough memory to prevent swapping, and with terrabyte disks it makes no real difference whether the swap partition is 1 Gb or 4 Gb in size.

I still use the old rule of thumb and allocate twice the size of RAM for a swap partition. But the intention is not so much to swap memory pages but rather to always have enough space for kernel core dumps. My basic reasoning is:

1. In case of kernel errors I want to get a core dump.
2. A later RAM upgrade is relatively cheap and easy, thus probable over a system’s lifetime.
3. A later disk re-partitioning is more difficult, thus to avoid.
4. Disk space is cheap, allocating ≤ 5% for a mostly unused swap partition has no significant cost.

2011-11-19T01:31:21 frodo kernel: pid 47812 (try), uid 0: exited on signal 10 (core dumped)

Source of the program is Perl’s Configure script, which compiles its C library test cases into programs named try. And apparently amd64 systems need to use the function va_copy() because the test case without this function leads to a segfault.

[Short english explanation:] I finished my diploma thesis: Design and Implementation of an IPv6 Plugin for the Snort Intrusion Detection System.

Both techniques give the OS more control over processes and the ability to kill running applications. At first sight this looks scary and a loss of control over your computer. But it is viable for the OS to provide better resource management. Think of it as Swapping 2.0 — only instead of moving virtual memory pages to disk and back, the application is simply killed to free its memory pages.

It might get even more interesting if developers accept this new model and design their application accordingly. Then there could be quite an incentive to reduce startup times (maybe also to reduce the overall size of a process’s state and use transaction safe I/O). Finally: Recovery-Oriented Computing on the desktop :-)

Once upon a time I had to extract some application data using the antiqe DDE API and send it to a webservice. Once I found the Win32::DDE::Client it was quite easy to write 200 lines of Perl for the task. Because the script should not require a Perl installation on every machine it is used on, I used the Cava Packager to put everything into an .exe file. (Now I have to extend that old script and find that Cava is no longer free, but requires a subscription for commercial use.)

In order to know my alternatives I tried the Python Win32 extensions and py2exe and these seem to be just as good (or in case of the undocumented DDE module: just as bad) as their Perl counterparts. (Py2exe is not as easy to use as Cava; but not too difficult either.)

I found three ways to get complexity measures for PHP code.

The most advanced technique is to use a continuous integration server. One good example is the server at test.pear.php.net which uses CruiseControl (a Java CI server) with phpUnderControl for the PHP specific parts. Certainly a nice solution for big projects, but nothing to use on your own laptop to improve a single package.

Often the easiest way is to use PHP_CodeSniffer, which includes checks for cyclomatic complexity and nesting level (causing warnings and errors above some thresholds). If you already use it to maintain a uniform coding style (e.g. PEAR, Zend) then you just have to add these checks to your standard definition. These commands add metrics to the PEAR standard:

cd /usr/local/share/pear/PHP/CodeSniffer/Standards
sudo cp -R Generic/Sniffs/Metrics PEAR/Sniffs
sudo sed -I .bck -e 's/Squiz_/PEAR_/' PEAR/Sniffs/Metrics/*

The program PDepend creates a more detailed analysis of methods, classes, and projects (see this release note for details). Because it is intended as a component within a CI server its primary output is in XML. So I wrote myself a small wrapper (pdepend_summary.php) to format the data as an ASCII table. This allows for quick edit-check-cycles and now I run it along with phpcs and phpunit before I commit PEAR code.

Example output:

Package              Class                                  LoC %Comment Variables Methods Class_SiZe   WMC
-------              -----                                  --- -------- --------- ------- ----------   ---
Payment_DTA          DTA                                   1084     36.3         3      15        114   111
Payment_DTA          DTAZV                                  757     37.1         1      12         72    71
Payment_DTA          DTABase                                563     33.0         6      19         33    27
Payment_DTA          Payment_DTA_ChecksumException            3      0.0         0       0          0     0
Payment_DTA          Payment_DTA_FatalParseException          3      0.0         0       0          0     0
Payment_DTA          Payment_DTA_Exception                    3      0.0         0       0          0     0
Payment_DTA          Payment_DTA_ParseException               3      0.0         0       0          0     0
 
Package/Class             Method                                   LoC %Comment    CCN    NPath
-------------             ------                                   --- --------    ---    -----
Payment_DTA/DTA           _generateCrecord                         158     25.9     13     1600
Payment_DTA/DTA           _parseCextension                          81     30.9     13       93
Payment_DTA/DTA           _processCextension                        47      2.1      8        8
Payment_DTA/DTA           parse                                     59     35.6      7       36
Payment_DTA/DTAZV         _exchangeFillSender                       33      0.0      7       64
Payment_DTA/DTAZV         parse                                     41     17.1      7       36
Payment_DTA/DTAZV         _exchangeFillReceiver                     26      7.7      6       24
Payment_DTA/DTA           _exchangeFillArrays                       31      0.0      6       32
Payment_DTA/DTA           _parseCrecord                            109     27.5      6       72
Payment_DTA/DTAZV         setAccountFileSender                      41      0.0      5       15
Payment_DTA/DTA           _parseErecord                             49     30.6      5       16
Payment_DTA/DTABase       getStr                                    18      0.0      4        8
Payment_DTA/DTAZV         __construct                               19     10.5      4        4
...

Probably every TeX-User knows the advocacy about how powerful the language is… but do (or can) you proofread everything before you compile it?

M0n0wall: I have already used this as a NAT router and liked the web-based configuration (which I percieved as convenient but not limiting), so it was the first candidate. But I found it to be ‘too small’ for my plans. It allows neither the installation of additional software, nor does it allow ssh login for scriptable configuration changes. It also does not use pf, which I tend to prefer for its concise configuration and dynamic tables.

pfSense: M0n0wall’s big brother; bigger, more complete, and more customizable. But with one major problem: no IPv6 support. It is 2010, with only 1-2 years until the IPv4 address pool exhaustion… deploying network infrastructure without IPv6 support is ridiculous and not an option. – Another problem seems to be a limited support for bridge setups: There are always a number of standard pf rules, which are hard to circumvent in case of problems. I nearly settled to use the web-interface for IPv4, and insert my own IPv6 rules into the PHP scripts. But this would have made it even harder to maintain than a solution without any web-interface.

NanoBSD: So I finally took the chance to build my own small FreeBSD system for the task. NanoBSD is basically a script to do a FreeBSD ‘make world’, allow for some customization, and finally put everything into a CF-ready disk image. Of course the first attempt required several changes after installation (it’s really hard to think of all configuration steps beforehand), but everything went well without major problems.

Thus I chose NanoBSD. YMMV, and I would not recommend it for anyone not familiar with BSD. – But with four other BSD servers the additional maintenance effort is really small; possibly even easier than with any non-standard or web-based configuration.

[Update, 2011-02-24: If you use NanoBSD yourself then take a look at the useful scripts and patches from BSDRP.]

I like the new logo for Mailman.

To extract single DB dumps from a complete dump find the line numbers where the single DB dumps start. Then use sed to print only the lines from the start of the searched DB and the next one. mysqldump seems to use separate passes for data, stored routines, and triggers — so there may be multiple ranges of lines in a complete dump:

fgrep -n 'Current Database: ' dump_all.sql
sed -n -e '86226,93282p' -e '123249,123254p'
  dump_all.sql > db_test.sql

diff loads the files it works on into memory, thus it cannot be used for large files (>= 1Gb). To extract multiple DBs or to compare dumps it is useful to split the SQL dump at DB boundaries:

split -p 'Current Database: ' dump_all.sql

The resulting partial files can be renamed/concatenated to one file per DB (using tcsh syntax here):

foreach f ( x?? )
  set dbname=`head -1 $f
  | sed -e 's/^-- Current Database: .(.*).$/1/'
    -e 's/^-- MySQL dump.*$/dumpheader/'`
  test $dbname && cat $f >> part-${dbname} && rm $f
end

If we did this with two SQL dumps in $dir1 and $dir2, then we can compare them chunk by chunk (assuming every DB on itself is small enough to fit into memory for diff):

foreach f ($dir1/part-*)
  diff --ignore-case --ignore-space-change
    --ignore-blank-lines -u
    $dir1/$f $dir2/$f >> /tmp/diff.out
end