Avian’s Blog

I just managed to clean up and somewhat document the Templator script I made for the OpenOffice.org conference web site last September.

This is the first of a series of tools I developed in a hurry during those three days and that also proved useful for other projects. Other tools and scripts will probably follow in the more or less near future, depending on my free time and sleep patterns.

GNOME Bugzilla presents the Ultimate Bug Report.

I have just found an amusing little program by Taper Wickel on my (half-broken) hard disk. It uses some simple math to predict how long it will take for humanity to destroy itself. And if your simulated little earth manages to survive the next 500 years (which in my case is yet to happen) you win.

It's a fine replacement for fortune in your .bashrc.

Here is the link to source (it is in the public domain). Have fun.

Last August a 6 year old 13GB Seagate Medalist failed in my server. In October, a 5 year old 30GB IBM Deskstar failed in my desktop.

Now, my desktop won't boot from a three months old 200GB Western Digital because of the infamous { DriveReady SeekComplete Error }

Before August, none the disks in my machines have ever died. Should I expect this row of failures since I was cheating on the specified mean time between failures for the drives I have been using?

The road to hell is paved with NAND gates.

-- J. Gooding

I still can't find the cause of XKB error messages, but I'm getting close.

I suspect there is a race condition when something runs xkbcomp to compile the XKB keymap, but I can't find who exactly is doing that. After going through the source or gnome-settings-daemon, libgswitchit and libxklavier I filled a bug report at Debian BTS.

To be continued...

This is the condition of the road to Javornik near Črni vrh (that round thing is the top of a road sign).

One fact about computers that even technical people often forget: The job of the computer is to make your job/task easier - it is not the other way around.

-- Joeytsai on Slashdot

My friendly incompetent internet service provider is again blocking all external mail traffic. So don't be surprised if you can't send me a mail or use one of the mailing lists at tablix.org.

This time I'll restrain myself from calling their support line. Everytime I call and complain about mail problems the marketing droid on the other side wants me to open my Dial-up networking properties and Outlook express settings. After I tell him that I don't have this stuff on my machine and that their mail server is returning 450 Unable to find domain after MAIL FROM SMTP command he simply rewinds his tape and starts again: OK, I understand. Now click on the Start button and open the Control panel...

After some reading of the stuff in /usr/share/doc/udev I found out that putting lp into /etc/modules brings back the lp0 device. Suddenly things don't look that bleak anymore.

Still have to figure out how to get /dev/ttyS0 and friends back though.

It's almost midnight, I've just spent 5 straight hours writing a report for one of the term projects I've been working on and now I just have to print it.

No problem. I click on the Print button, but the printer remains silent. Great, why must things always break when you need them the most? Some 5 minutes later, I dig out this from /dev/log:

Jan 18 23:38:50 orion lpd[9645]: /dev/lp0: No such file or directory
Jan 18 23:39:30 orion lpd[9669]: /dev/lp0: No such file or directory
Jan 18 23:40:18 orion lpd[10641]: /dev/lp0: No such file or directory

WTF?!

Ok, no problem. Some broken script obviously wiped out some of my device files. Luckily, I still have MAKEDEV, right?

orion:/dev# MAKEDEV lp
.udevdb presence implies active udev.  Aborting MAKEDEV invocation.

Argh. So MAKEDEV thinks that udev should take care of device files and udev obviously only cares about fancy new stuff like USB and Firewire. How on earth am I supposed to use my printer on the parallel port? I don't remember the major and minor numbers for the lp0 device and I don't feel like greping the kernel source right now. Maybe there's another lp0 somewhere?

avian@orion:/dev$ locate lp0
/home/avian/morphix/live/dev/lp0

Finally! I knew that all that junk in my home directory will someday turn useful. A quick edit of the /etc/printcap and the printer begins churning out first pages of my report.

I guess it's time to switch to CUPS or something.

It seems these damn GNOME xkb errors are spreading. Now my home machine has contracted them too after upgrading from GNOME 2.10 to 2.12. And unfortunately the solution I mentioned previously no longer works.

Deleting all dot files in my home directory also doesn't help.

Making /var/lib/xkb world-writable - no effect.

/etc/X11/xkb/rules/xorg - check.

Asking for help on IRC in #gnome - no answer, since this problem has already been discussed to death on all sorts of message boards, mailing lists, wikis, bugzillas (earliest posts I could find regarding this were from 2002!). Of course, it could be that the error or my machine is caused by something completely different than in all those other hundred case, but how can I tell? The fscking error message is exactly the same and offers no clues on what caused it.

Today was the last day of lectures in my five year undergraduate study program. Basically this means that I'm getting near the end of step one in the three-steps to profit of the new economy:

1. Study
2. ????
3. Profit!

The only problem is that I still haven't quite figured out what step two is supposed to be.

If you are getting annoying error messages like these every time you start GNOME or try to change the keyboard layout with gnome-keyboard-preferences and if setxkbmap seems to be working fine, check if you have this file: /etc/X11/xkb/xkbcomp. If you don't have it, try to find it somewhere (I found it in /usr/X11R6/bin) and make a symlink like this:

$ ln -s /usr/X11R6/bin/xkmcomp /etc/X11/xkm/xkbcomp

Why exactly one needs to spend a couple of hours stracing various Gnome binaries to get to this conclusion is left as an exercise for the reader (hint: try running a rogue gnome-settings-daemon from a terminal).

This description of the microwave oven I found in the Slovenian translation of How things work by Steve Parker is terribly wrong.

It says that there is a fan with reflective blades that reflects microwave rays into the interior of the oven in random directions to ensure that the food is evenly cooked.

This can't be further from the truth. First, you can't even speak of microwave rays in this context. Microwave ovens operate at the frequency of 2450 MHz which means that the wavelength of the microwaves is around 12cm. This is large enough to be comparable with the dimensions of the oven. It means that propagation of radiation can't be modeled with rays at all as this is only acceptable when the wavelength is very small (for example for visible light).

In reality the microwave oven is designed so that the radiation inside behaves in a predictable pattern called a standing wave. This has something to do with better energy efficiency but also has the side effect that some spots in the oven will be heated more than others. In fact you can use this effect to measure the speed of light with chocolate cookies (there is a web page about that somewhere, but I can't find the link right now).

I know this is a book intended for kids, but I believe there is a big difference between giving a simplified explanation and giving a completely wrong explanation because children can't understand the correct one.

This is another fine example of how not to code your web application. The following window opened when I clicked on a link saying something like click here for details.

For english speakers: the text in red says "System error report" and the smaller text says "System error: Error".

So as I understand this, the detailed description of this error is that the system error report had a system error reporting an error which was caused by an error. Just great!

I nominate popcorn noise for the best named phenomenon in the MOS field effect transistor.

This happens if you try to compress a picture with Ogg Vorbis.

Original picture:

Same picture after compression (highest quality) and decompression:

Original picture:

After compression and decompression:

I think this gives a whole new meaning to the phrase lossy compression.

Here is the shell script I used to make these pictures.

Update: This was not meant to be a serious experiment. I was just curious what would I get if I would try to compress something that is not audio with an audio codec. I did expect pictures to look bad, however I was surprized at just how much a specialized lossy compression sucks for arbitrary data. I mean I didn't expect to just get static - there are some similarities between audio and image compression after all.