This is more an entry for future reference

In Karmic the version of nanoblogger will be 3.4. So I figured, why wait? I currently have some time, lets try to upgrade nanoblogger.

Also another nanoblogger user mailed me, saying 3.4 was three times faster... but with all my custom tweaks for 3.3 I'm hoping for the best.

With some packaging foo (had to install quilt and debhelper from Karmic), I now have a nanoblogger package for Jaunty (dpkg-source, dpkg-buildpackage and dpkg are your friends).

 sudo dpkg -i nanoblogger_3.4-1_all.deb

OKay, no errors, only one config question....

nb -l

still works.

nb -l cat

still works (looks to be sorted differently).

Just to be sure, lets make a small backup:

cp -rap miek.nl /tmp/backup-miek-nl

And now

nb -u

I'm seeing sed: -e expression #1, char 207: unterminated s command, but I have no idea where to look to fix this. Also I'm not getting the feeling that this is not so much faster than version 3.3: My zsh tells me it took this long:

313.27s user 517.06s system 687.68s elapsed 120%CPU (nb -u)

A quick reload on my homepage... it's looking good except the 'recent articles' is kaput, some css issues.

Finally the complete upgrade

nb -u all

also works.

Bug fixing

It looks like $NB_ArticleLinks is now done differently, so I need to update the templates a bit. The $NB_ArticleLinks now needs to be properly wrapped in a sidetitle div.

Different stuff

Adding a new entry now must be done as follows:

nb -a entry -c 7

Which is slightly different in 3.3

I'm going to upgrade my nanoblogger installation to version 3.4 after this post. I'm expecting some breakage...

This is an English translation of a blog item I wrote for AT Computing

While giving a course a student showed me the following:

$ ps -ef > /tmp/file

Where /tmp is 100% filled yields no errors and seems to have worked!

Lets try to see what is going on here.

Firstly, lets fill up a file system. We are going to use an fs mounted under /media/disk:

$ cp /dev/zero /media/disk/HUGE                 
$ cp: writing `/media/disk/HUGE': No space left on device

Further we need a little program to test a few things:

int 
main(void) 
{
    write(1, "hello\n", 6);
}

This writes the 6 bytes hello\n to standard output. Notice how I don't do any error checking. If this were implemented correctly I should check how many bytes are actually written by the write() system call. Also see man 2 write.

After compilation we have our program output:

$ gcc output.c -o output

The usual I/O redirection works as expected:

$ ./output > tmp_file
$ cat tmp_file
hello

Now try this on our 100% filled file system:

$ ./output > /tmp/tmp_file

No errors - looks like this went OK.

$ ls -l /tmp/tmp_file
-rw-rw-r-- 1 miekg miekg 0 Jun 10 12:47 /tmp/tmp_file

We do have a file in /tmp, but its size is only 0 bytes. We are left with two questions. How is it that you can create a file in a full file system? And, why do we not see any data in /tmp/tmp_file given the fact that we saw no errors?

Directories

If you create a directory in Linux (and Unix), then an ls -ldn will say this (empty) directory has a size of 4.0K:

$ mkdir /tmp/test
$ ls -ldh /tmp/test
drwxrwxr-x 2 miekg miekg 4.0K Jun 10 12:52 /tmp/test

That 4.0K is reserved. When we create files and or subdirectories under /tmp/test the size of the directory will only be enlarged when we cross the 4.0K boundary. When doing a little bit of testing I saw that Linux then sets the new size to 12.0K:

$ cd /tmp/test
$ for i in $(seq 0 260); do echo $i; touch file.$i; done
$ ls -ldh /tmp/test
drwxrwxr-x 2 miekg miekg 12K Jun 10 12:59 /tmp/test

So as long as you don't cross that 4.0K boundary the system will allow you to create files. Even on otherwise full file systems!

Writing the data

If we do a ./output > /tmp/tmp_file, output does not know it is writing to disk. output just writes to its stdout and in this case output does not check if the writing succeeds. If we add this check we get a different story.

First amend the source:

int 
main(void) 
{
    if (write(1, "hello\n", 6) != 6) {
        write(2, "ouput: write error\n", 20);
        return 1;
    }
    return 0;
}

Recompile:

$ gcc output.c -o output

Retest:

$ ./output > /tmp/tmp_file
ouput: write error

Now we have fixed output, but there are still a lot of programs which also have this bug:

The next set of commands all fail without any errors:

$ ps -ef > /tmp/tmp_file  

$ free > /tmp/tmp_file     

$ grep 'as' testfile > /tmp/tmp_file           

$ perl -e 'print "hallo";' > /tmp/tmp_file

Luckily a lot of other programs do the right thing:

$ who > /tmp/tmp_file
who: write error: No space left on device

Also many (if not all) programs made by GNU do the correct thing.

Re-watching the Power of Nightmares again. A very nice serie about terrorism and how Bush et al used it to change the world.

Yes... I rule.

Still seems a bit low as I should have 100 Mb/s...

Jacques has made a nice script which tries to discover all the people who have an account with Hyves.

Currently there are:

$ bzcat miek.nl/downloads/2009/hyves.txt.bz2|wc -l
3169894

Already 3.1 million of them! Interested in the list? (17 MB download).

Well, thanks to Ubuntu I'm now running the new (new!) 2.6.30 kernel on my systems.

No ill effects as of yet...

Btw, I've written the following script to download the latest kernels from Ubuntu:

SYNOPSIS: latest 29.4, this will fetch 2.6.29.4 or latest 30 which will get 2.6.30.

#!/bin/bash
# download the latest ubuntu mainline kernels
ubuntu="http://kernel.ubuntu.com/~kernel-ppa/mainline/"
version="2.6.$1" # need 29.n as argument
arch="i386"  # or amd64
major=${version%.[0-9]}
minor=${1%.[0-9]}
patch=${version#2.6.*.}

[ -z "$1" ] && { echo -e "Usage: $0 MINOR\n$0 29.3"; exit 1; }
[ -n "$2" ] && arch="$2"

if echo "$patch" | grep -q '\.'; then
printf -v versionstr "0206%d" $minor
else
printf -v versionstr "0206%d%02d" $minor $patch
fi

printf -v generic "%s-${versionstr}-generic_%s-${versionstr}" $major $major
printf -v all "%s-${versionstr}_%s-${versionstr}" $major $major

echo "${ubuntu}v${version}/linux-headers-${generic}_${arch}.deb"
wget --progress=bar "${ubuntu}v${version}/linux-headers-${generic}_${arch}.deb"
echo "${ubuntu}v${version}/linux-headers-${all}_all.deb"
wget --progress=bar "${ubuntu}v${version}/linux-headers-${all}_all.deb"
echo "${ubuntu}v${version}/linux-image-${generic}_${arch}.deb"
wget --progress=bar "${ubuntu}v${version}/linux-image-${generic}_${arch}.deb"

After a few years of development I'm releasing rdup 1.0.0.

I went on a active bug hunt for this release. This has resulted in several bugfixes and 27 tests in the DejaGNU test suite.

You can download it from the usual location

(sha1sum: 5ecb6d60bccfc01d660b20b8fabffef3732ca6ec)

Of course this does not mean the end of development :)