The forcedeth driver for nVidia NICs had some interrupt handling issues in earlier kernels. However, as Debian/etch is still using 2.6.18, these boxen may still get flooded with messages like:
eth0: too many iterations (6) in nv_nic_irq.A fix has been posted in 10/2007 (~2.6.22?) and as a workaround we could put the following into /etc/modprobe.conf:
options forcedeth max_interrupt_work=10
Oh, how wonderful is that: code_swarm takes a SVN/CVS activity log and visualizes the development progress. It's really impressing, even for smaller projects, how development went on over time. Short mini howto:
# cd project-svn # svn log -v > /tmp/project.log # cd ../codeswarm # python convert_logs/convert_logs.py -s /tmp/project.log -o /tmp/activity.xml # cp data/sample.config data/project.config # vi data/project.config [point InputFile to /tmp/activity.xml] # vi build.xml [point arg:value to data/project.config] # ant runYou'll need X11 and a JDK for that. OpenJDK will do just fine.
When the MacMini arrived, I forgot that I might need a keyboard as well. Not that often, as it'll be some kind of "server", but once in a while one might have to free the box from an ugly panic or just play around locally. Anyway, now a slim Apple keyboard is connected and suffering from a nasty bug in Ubuntu/Hardy. Fortunately, this is already documented in Launchpad and the almighty blogosphere.
In short: when accidently hitting the NUMLOCK key, my keyboard is basically unsuable. Hitting F6 twice does the trick for me. Plugging in a 2nd (non-Apple) keyboard and hitting NUMLOCK again seems to resolve it as well :-)
What's the subject line about?
Whenever I install Ubuntu these days, opening OpenOffice looks like this. There's LP#53574, with no solution in sight. However, every time I was able to solve this by reinstalling openoffice:
$ dpkg -P openoffice.org-common openoffice.org-core openoffice.org-help-en-gb \
openoffice.org-help-en-us openoffice.org-hyphenation-de \
openoffice.org-hyphenation-en-us openoffice.org-l10n-common \
openoffice.org-l10n-en-gb openoffice.org-l10n-en-za \
openoffice.org-style-human openoffice.org-thesaurus-de \
openoffice.org-thesaurus-de-ch openoffice.org-thesaurus-en-au \
openoffice.org-thesaurus-en-us language-support-writing-en \
language-support-writing-de python-uno language-support-translations-en \
language-support-en thunderbird-locale-en-gb
$ apt-get install openoffice.org-core openoffice.org-thesaurus-de
openoffice.org-hyphenation-de openoffice.org-hyphenation-en-us \
openoffice.org-thesaurus-en-us language-support-writing-en \
language-support-writing-de thunderbird-locale-en-gb \
openoffice.org-style-human openoffice.org-writer openoffice.org-calc \
openoffice.org-impress
And no, it does NOT feel good applying Windoze techniques in a current Linux system :-\
There's always something new to learn when working with sed. Although using this beast for quite a while, I just discovered that sed is *really* working line-by-line. That's why things like this
sed 's/\n/ /'
won't work as expected (removing the newlines). Yes, tr could do this:
tr '\n' ' '
...but it's not as flexible as sed(1). So I found this:
sed ':a;N;$!ba;s/\n//g'
...which is working just fine with GNU/sed 4.1.2 but won't work with the version of sed from Solaris10:
sed ':a;N;$!ba;s/\n//g' Label too long: :a;N;$!ba;s/\n//gWhat now?
I think I've never even tried that and thus learned just now that "rm -rf /" is not allowed since Solaris 10b36. Wow.
Got myself new diskspace today: 2x1TB Samsung HD103UJ, enclosed in an Taurus RAID case. First tests in Leopard say 35MB/s over FireWire400, more testing ahead. I was surprised to see that the bonnie++ filesystem benchmark was not available via Fink. Compiling from source failed with:
g++ -O2 -DNDEBUG -Wall -W -Wshadow -Wpointer-arith -Wwrite-strings -pedantic
-ffor-scope -c getc_putc.cpp
getc_putc.cpp: In function ‘int main(int, char**)’:
getc_putc.cpp:174: error: no matching function for call to
‘min(long unsigned int, unsigned int)’
make: *** [getc_putc.o] Error 1
There is a patch for some 64-bit platforms, but the ifdef does not catch MacOS X, I guess. So, here's a slightly edited version of this very patch:
--- getc_putc.cpp.ORIG 2008-07-12 22:43:34.000000000 +0200
+++ getc_putc.cpp 2008-07-12 22:53:11.000000000 +0200
@@ -17,6 +17,10 @@
#include "duration.h"
#include "getc_putc.h"
+/* Work around for: line 168, no matching function for call to... */
+#include <sys/param.h>
+#define min MIN
+
static void usage()
{
fprintf(stderr, "usage:\n"
Btw, first benchmarks of GNU/Linux 2.6.24 with the internal 120GB drive are here.
/etc/cron.daily/spamassassin was unhappy for some time now:
error: GPG validation failed!
The update downloaded successfully, but the GPG signature verificationfailed.
channel: GPG validation failed, channel failed
Apparently GnuPG checks for cross-certification now, hence the error message.
Here is how to solve it:
wget http://spamassassin.apache.org/updates/GPG.KEY sa-update --import GPG.KEYOh, and can somebody explain to me, what this sleep(1) thingy in
/etc/cron.daily/spamassassin is about? What's it used for?
Every now and then I come across this:
$ touch a
$ mv a{,.bak}
$ ls
a.bak
And everytime I think what a great deal of typing this could save, but shortly after I'm forgetting about this. Curly brackets are not that easy to type on a German keyboard though. Btw, an XPG4 sh(1) cannot handle this - ksh and bash do support this.