This weekend I finally updated my LG X130 netbook to Slackware 13.37. This is one of my “stable” machines that I use all the time for day-to-day tasks, so I do not run -current on it, as I depend on it too much. Slackware-current is very interesting for research and testing all the new stuff, but it can break when you least expect it. And then you need a “stable” installation to at least access the internet, pay the bills, read e-mail, etc. So I left this netbook as one of the last machines to update to Slackware 13.37.

And it went quite smoothly. Except for one thing: the wireless adapter was not working…

Old problem returning?

I remembered that when I first installed Slackware on this netbook about a year ago, I also had a problem with this rt3090 card. The kernel confused it with the rt2800 and tried to load the rt2800pci module – which did not work with this adapter.
At the time, I found a simple solution by ‘Googling”: putting the rt2800pci module on the blacklist by creating a simple text file in /etc/modprobe.d/ with a single line:

blacklist rt2800pci

So I checked if that file was still there, and it was…
I did a “lsmod | grep rt2” and the result was:

rt2860sta 483303 1
crc_ccitt 1087 1 rt2860sta

So the correct module was loaded!

More investigation was needed

“ifconfig” did not show the wlan0 interface, but “ifconfig -a” did.
I tried “ifconfig wlan0 up” but it returned with:

SIOCSIFFLAGS: Operation not permitted

So what do we do when a kernel module has problems? Check the dmesg log…
I did a “dmesg | grep -i rt” and found this interesting line:

rt2860 0000:02:00.0: firmware file rt3090.bin request failed (-2)

So, the rt2860 module is looking for the rt3090.bin firmware and not finding it!

But isn’t the rt2860 driver used for the rt3090? I remembered reading (don’t know where, probably when I first installed Slackware 13.1 on this netbook) that the rt3090 adapter was handled 100% by the rt2860 driver.
I decided to check the /lib/firmware directory, where all the firmware files are installed in Slackware. There were several rt2xxx.bin files, but no rt3090.bin.

This is where I decided to get bold

I thought: It’s not working anyway, so what can I loose?
And I created a symlink rt3090.bin to rt2860.bin They are the same in the kernel anyway, right?
I rebooted, and… It worked!

My wireless adapter was working again and my netbook was fully operational as before the update.

But was this really the correct solution?

I decided to go straight to the source and browse around on kernel.org. And in their git repository I found this commit:

rt2860sta: Use latest firmware for RT3090

author Ben Hutchings
Sat, 30 Apr 2011 18:31:32 +0000 (19:31 +0100)
committer Ben Hutchings
Tue, 17 May 2011 04:22:12 +0000 (05:22 +0100)

Ralink’s original drivers for RT2800P/RT2800E-family chips used
multiple different versions of the firmware for different chips. The
rt2860sta driver in staging was briefly converted to load different
files for different chips. However, the current rt2860.bin is
supposed to work on all of them, so replace rt3090.bin with a symlink.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

Well, well! So the official solution was to create a symlink as well!
I checked the tree in their git repository and there you can see they have the symlink “rt3090.bin” pointing to the rt2860.bin file, just as I did.
I also noticed a second symlink: rt3070.bin is pointing to rt2870.bin.

Report it back to “The Man”

Now that I was reassured that my solution was the correct one, I sent an e-mail to Pat Volkerding about my findings.
It would be nice to see the rt2860-firmware-26-fw-1 package create the symlink on installation, to prevent some headaches around the world

This is a question that pops up once in a while on IRC and the forums, and the answer is yes, but there are some little details to take care of.
I made a step-by-step how-to once for myself, so I thought I might as well put it here on my blog

What is needed

• an image editor – I use the Gimp in this post, since it is included in Slackware
• an image file – basically anything readable by the Gimp can be used
• root access to edit lilo.conf and run lilo

Choosing an image

Like I wrote above, basically any image can be used, as long as you can open it with the Gimp, but results may vary.

At boot time, you have a screen with 640×480 pixels resolution, capable of showing 256 different colors. The bitmap format used for the logo file works with a 256-color index, so you can theoretically have an image with 256 shades of blue, with reasonable results.
If you use an image with many different colors to start with, the result can be quite ugly…

First I’ll show the basic steps, then the results with some different images.

Converting the image

I’ll start with a picture that uses mainly red and green colors:

The first thing we need to do is resize it to 640×480. Open it in the Gimp and choose: > Image > Scale Image... from the menu, and type 640 in the “width” box:

As this picture was taken with a digital camera, it already comes in the right width:height ratio of 4:3. In the second example I’ll show how to deal with pictures with different ratios.
Click on “Scale” and the first step is done.

The next step is to create the 256 color index, as that is the maximum number of color we can display at boot time. Choose: > Image > Mode > Indexed... from the menu.
Select “Generate optimum palette” with a maximum of 255 colors:

Click on “Convert” to create the index and convert the picture.

This is a good time to take a close look at the result. Use the zoom to enlarge the result, as this picture will be shown full-screen on your monitor at boot time. You will only have 255 different colors at this time.
Here is a sample of the picture I used:

As you can see, the shades of green and red are limited now, but the result is acceptable.

Now save the image in the bitmap format with: > File > Save As...
Do not close the Gimp yet, as we will need to get some information from the image in a while.

Preparing lilo

The following steps need to be run as root. As always, be careful here…

First of all, copy the bitmap file to the /boot directory.
Second, edit /etc/lilo.conf with your favorite editor. There s a section that defines the filename of the boot logo we need to edit. I called mine “flower.bmp”, so the result looks like this:

...
# Boot BMP Image.
# Bitmap in BMP format: 640x480x8
 bitmap = /boot/flower.bmp
...

That was the easy part

Now we need to change the positions and colors of the menu and the timer.

First, let’s think about the positions. This usually takes some “trial-and-error” to get nice results, but there are some general ideas:

• Positions are in “columns” (1-80) and “lines” (1-30) normally (pixels are possible for finer positioning)
• Try to choose a more neutral part of the picture, like a darker spot, or a part where there is only blue sky visible

For the first run, just try to make an educated guess (experience helps), and change after booting if you don’t like the result.

Second, we need to select the colors for the menu.
Remember, we now have these 255 colors to choose from after indexing the picture. But the trick is to know the number of the color…
Luckily, this is easy to find out in the Gimp. Choose: > Colors > Map > Rearrange Colormap... from the menu:

From this list, I’ll choose a pair of light and dark colors for the menu and the timer.
This is the combination I selected:

...
# Menu colors (foreground, background, shadow, highlighted
# foreground, highlighted background, highlighted shadow):
 bmp-colors = 188,253,188,13,253,188
# Location of the option table: location x, location y, number of
# columns, lines per column (max 15), "spill" (this is how many
# entries must be in the first column before the next begins to
# be used. We don't specify it here, as there's just one column.
 bmp-table = 62,5,1,16
# Timer location x, timer location y, foreground color,
# background color, shadow color.
 bmp-timer = 65,27,188,253,188
...

Save your lilo.conf and run lilo to recreate the boot loader with the new settings.
If you get an error running lilo about an invalid image format, recheck your image with the Gimp.

Now reboot and see the result:

(I was able to take a “screenshot” while booting because I did this in a virtual machine…)

Advanced tips & tricks 1 – Different width:height ratio

My example was based on a picture that already had the 4:3 width:height ratio, but what if you have a different picture?
As an example, I’ll use this picture that comes in the “FullHD” format of 1920×1080 pixels (ratio 16:9):

(This is the train station of Cabangu, where the great aviator Santos-Dumont was born)

In this case, in the > Image > Scale Image... dialog, we’ll choose “480″ for the height:

Now the width is too large for the 640×480 standard we need, so we’ll choose: > Image > Canvas Size... from the menu, and:

1. Click on the “chain” to break the link between the width and height
2. Enter “640″ as the width
3. Change the X Offset by value or by moving the image with the mouse

This is my example:

For the rest, just click on “Resize” and follow the steps as in the first example. This should be the result:

Advanced tips & tricks 2 – Widescreen monitors

This all looks nice, but if you have a modern wide-screen monitor, your boot logo will probably look distorted when shown full-screen, something like this:

We can “trick” this to look a bit better by distorting the bitmap image the opposite way, a technique commonly used in movies to record widescreen images on standard 4:3 film (see this explanation about anamorphic recording).

Let’s get back to the original Cabangu picture. Instead of scaling it to 853×480, we’ll break that chain again and scale it to 640×480:

After color-indexing this horizontally “compressed” or “anamorphic” picture should be the result:

But the result should show up nicely on a wide-screen monitor:

Conclusion

This post just showed some basic examples of creating your own boot-logo screens. Use your imagination to create our own!
If you think you created something nice, feel free to post a link to the image in a comment.

For more advanced lilo options, do read the manual (# man lilo.conf)

The system

Recently I upgraded a system that was still running Slackware 13.0. It’s a not-so-new system, but should be good enough to serve as a desktop for some more time: 2.6GHz P4, 1GB of memory, 160GB hard drive. Video, sound, network are all on-board, using a cheap Via chipset.
This box has had some stability problems before, like freezing with several tabs open in Firefox, but I thought it was simply because that browser was getting more and more “obese”

Youtube or not Youtube?

After upgrading it to Slackware 13.1, it showed very “consistent” behavior: All videos from Youtube were without sound or stuttering sound. I checked the usual suspects: flashplayer-plugin, alsaconf, etc., but without success. All I found on the internet about Youtube videos without sound was old information from years ago that did not apply.
I tried to save some videos locally, and found that they played well in mplayer, but also with stuttering sound in gxine. So the problem was not related to Youtube…

Comparing with another system

Next step was comparing the configuration with a similar box, with the same sound chip (at least I thought…). On this second system I had no problems at all with sound, although the configuration is quite similar – it’s just a bit newer and has some better specs (memory, processor, etc.)
But… there was a small difference between the two HDA Intel chips…

This is the one that stutters:

02:01.0 Audio device: VIA Technologies, Inc. VT1708/A [Azalia HDAC] (VIA High Definition Audio Controller)
 Subsystem: ASUSTeK Computer Inc. Device 818f
 Flags: bus master, fast devsel, latency 0, IRQ 17
 Memory at fbefc000 (32-bit, non-prefetchable) [size=16K]
 Capabilities: [50] Power Management version 2
 Capabilities: [60] MSI: Enable- Count=1/1 Maskable- 64bit-
 Capabilities: [70] Express Legacy Endpoint, MSI 00
 Capabilities: [100] Virtual Channel 
 Capabilities: [130] Root Complex Link 
 Kernel driver in use: HDA Intel
 Kernel modules: snd-hda-intel

and this is the one that works fine:

00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01)
 Subsystem: ASUSTeK Computer Inc. P5KPL-CM Motherboard
 Flags: bus master, fast devsel, latency 0, IRQ 44
 Memory at f9ffc000 (64-bit, non-prefetchable) [size=16K]
 Capabilities: [50] Power Management version 2
 Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+
 Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00
 Capabilities: [100] Virtual Channel 
 Capabilities: [130] Root Complex Link 
 Kernel driver in use: HDA Intel
 Kernel modules: snd-hda-intel

Google is our friend again

So, back to Google, and after some browsing I found an interesting article about nvidia chips that had the same problem here.

I edited the /etc/modprobe.d/sound.conf file and added this line:

options snd-hda-intel enable_msi=0

And, after a reboot, the system played videos in Youtube and locally without any stuttering

The kernel patch that is suggested in the article is already included in the kernel that comes with Slackware 13.1, but it only checks for the nvidia chip.
If this box continues to work fine, I might patch the source for the HDA Intel driver (hda_intel.c) and compile a custom kernel. If that works fine, I’ll send the patch to the maintainer of this module.

Installation of Slackware 13.1 went smoothly, as always, except for one thing: the maximum resolution with the NVIDIA driver (built with the script from SlackBuilds.org) was 1280×1024. This annoyed me and intrigued me at the same time, as the Debian spin-off worked flawlessly at 1600×900.

In the /var/log/Xorg.0.log (the first place to look when X does not work the way you expect) I noticed the following strange error message:

Failed to allocate primary buffer: out of memory

The /etc/X11/xorg.conf created by the nvidia-settings program was almost the same on both Linux flavors, so that was not the problem.

Then I started to check the differences between the two installations…
I noticed that the Debian spin-off used an older kernel and an older version of the NVIDIA driver, but I never had problems with the newer versions on other systems.

Next step: Google.

I found several reports of the same problem, and the “solution” (more like a work-around) was adding the “nopat” parameter to the kernel.
I checked the configuration of the kernel used by Slackware 13.1 (/boot/config) against the configuration used to build the kernel that came with the Debian spin-off and they were different indeed:

in Slackware it is:

CONFIG_X86_PAT=y

While the other has:

# CONFIG_X86_PAT is not set

I added the “nopat” parameter in /etc/lilo.conf:

...
append=" vt.default_utf8=0 nopat"
...

After running lilo and rebooting, the resolution went to 1600×900 without problems!

Now it’s just a lot of irony that I have to set “nopat” to use Slackware, but I hope he forgives me until I compile my own kernel for this box

I have configured several other USB modems on my Slackware systems, so I was sure I could get this one to work as well. I did it in about 20 minutes and here are the basic steps:

1) Switching from “drive” to modem
Many of these USB modems first present themselves as “media”, so that Windows users can install the built-in software from them. Then the installed driver “ejects” the media and the modem presents its real identity as a modem.
On Linux, we have to “eject” the media as well by software, and for this we can use a udev rule.
When plugged in the first time, we can check the ID of the media / modem in a terminal window with lsusb. The result included the following line:

Bus 001 Device 005: ID 0421:060c Nokia Mobile Phones

So this is the ID of the modem presenting itself as removable media.

Now we need a udev rule to “eject” the media. This is what I wrote, based on some previous experience and this guide on writing udev rules:

SUBSYSTEMS=="usb", SYSFS{idVendor}=="0421", SYSFS{idProduct}=="060c", ACTION=="add", RUN+="/usr/bin/eject -s %k", OPTIONS+="last_rule"

Now let’s analyze this rule:

• SUBSYSTEMS=="usb" – speaks for itself: we are handling a USB device
• SYSFS{idVendor}=="0421", SYSFS{idProduct}=="060c" – this identifies our Nokia modem
• ACTION=="add" – means that this rule is only for when the device is added
• RUN+="/usr/bin/eject -s %k" – calls the “eject” program with the parameters -s (a “SCSI” device, like /dev/s??) and %k (the device name the kernel gave it, like /dev/sdb0 or whatever the “media” is named)
• OPTIONS+="last_rule" – make sure that later rules for this device have no effect

Save this rule as 91-nokiacs10.rules in /etc/udev/rules.d/
This is the directory where we save all our “custom” rules, as opposed to the standard rules that stay in /lib/udev/rules.d where we should not mess around (as they will be overwritten with the next update of udev).

So now, pull out the modem and plug it in again. If everything is fine, after a short time you can check your usb devices again with lsusb and now the line should be:

Bus 001 Device 005: ID 0421:060e Nokia Mobile Phones

Check that the Product ID has changed from 060c to 060e

2) Check your modem device
Now check your devices with ls /dev/tty* and you should see in the list ttyACM0 and ttyACM1.
Use ttyACM0 in your favorite dialer to connect to your internet provider. I use pppd, but it should work with kpppd or whatever you prefer!

3) Next steps
I actually use a second script that automatically “dials” my provider and connects me to the internet. This is done by creating a second rule in the same file, but this time for the 060e device, starting a small shell script.
This script checks if the ttyACM0 device is available, calls pppd, checks ifconfig if the ppp0 device is up and creates an entry in the routing table.
Since my script is very ugly, I won’t put it here, but it was not that difficult to write, so I’ll leave this as an exercise!

Something went wrong when I canceled the “CNAME” entry in the DNS server that pointed “underpop.online.fr/n/nielshorn” to the old blogspot site. When I created the new “underpop.online.fr/n/nielshorn” subdomain I couldn’t get it to point at my own server. :-/

But with a little help from my hosting provider everything is OK now.

Feel free to look around and to comment on any errors or broken links!

One question that pops up every now and then is about the “ideal” partitioning scheme for Linux.
The short answer is that there is no such thing as an “ideal partitioning scheme”. It all depends on so many things, like:
- your hardware
- how you are going to use your system
- your future needs
- etc…

When a new Linux user asks me how to partition his new drive for Linux, I usually say that he should just use two partitions: one for swap and one for the rest. Yes, even with a 500+ GB drive…
Why? Because new users can get into trouble filling up a partition that was created too small and then things stop working.
Sometimes I get funny reactions like: “But I read that it is better to create a partition for /home, another for /usr/local etc…”. And some even show expressions of disbelief…

But, since the question keeps coming back, I decided to write how I partition my system.
Like I said – it all depends… So the partitioning for my situation might not apply to yours, but reading through this post you might learn a thing or two.

First of all, I “don’t do windows”, so you won’t read anything about how to double boot between Linux and Microsoft Windows, but basically you can just create an extra primary partition to waste some part of your hard disk and configure your preferred boot loader (Lilo or Grub) to access the alternative.

What follows is “the long answer” on partitioning your hard drive

1. About types of partitions
Partitions come in two types: Primary and Extended. You can have a maximum of 4 partitions on one hard disk. But one of them can be of the “Extended” type, in which you can create several “Logical” partitions.

Remember this when you create your partitions, as you cannot transform a Primary in an Extended partition without backing up all your data, deleting the primary partition, creating the Extended and Logical partitions and then restoring your data.
After you created four Primary partitions, you’re done… No way to go back without erasing!

2. The first partition – SWAP
The SWAP partition was originally invented to use as an overflow for your memory needs. If your system needs more memory than it has available, it starts “swapping” unused data from memory to this SWAP area. This was very common in the days when computers had less memory.
For the readers to have an idea: the first systems I worked with had 1 MB of RAM…
The old rule was that the SWAP partition should be twice the amount of RAM in your system.

Nowadays memory is cheap and plentiful in modern systems, so you might think you won’t need a SWAP partition.
But don’t just skip right now…
First of all, the SWAP partition is also used to ‘hibernate’ your system if it is capable of doing this (actually, I think *all* systems are capable, but normally only notebooks use this).
Hibernating simply saves all memory to the hard drive and reloads it when you reboot your system.
Guess where the memory is saved? Yes, on the SWAP partition.
So, despite the old rule, it should be at least the size of your RAM.
If you have like 4 GB of RAM, you won’t need 8 GB of SWAP space. A SWAP partition of 4.1 GB is good enough.

If you use several Linux flavors on your system, you can have a single SWAP partition for all of them. Just remember you’ll loose the ‘hibernate’ function if you reboot in a different flavor!

The SWAP partition is of the type “82″ for those using fdisk under Linux.

3. The second partition – “root”
The “root” partition is the base (or ‘root’) of the hierarchical file system. It is mounted as “/” in Linux and from there you can go down the hierarchy to any folder or device.
The standard of how this hierarchy is set up is well defined in the Filesystem Hierarchy Standard (or FHS) for all Unix-like operating systems. You can read more on this standard here and here.
Unfortunately, not all Unix or even Linux flavors adhere 100% to the standard, but that’s life…

The root partition is where the basic operating system is installed and all files needed to boot your system, get it connected to the network, etc., should be installed here.
Other files, like data, applications not needed for basic operations, user files, etc., can be on other partitions that are mounted later in the boot process.
The “/root” – the ‘home’ directory of the “root” user must be on the root partition to guarantee that root can login, even if the network is unavailable or external hard drives are not accessible.

Most modern Linux distributions are about 5 to 7 GB in size when fully installed.
To have some extra space, I usually create my root partitions with a size of 15 GB.

4. Extra “root” partitions
Why create extra root partitions? Because you might want to experiment with newer versions of programs, without messing up your working installation.
Or you might want to try out a completely different distribution of Linux for a change.
I personally keep three “root” partitions on my drive, but two should be enough in most setups.
If you make them 15 GB, like your first root partition, you should be ready for most installations.

5. The “/boot” partition
In Linux the /boot folder is used to store the kernel and the ‘initrd’ files. It is (normally, but do read on…) only used during the boot process.

Most people forget to make a separate partition for /boot. If you run only one installation of Linux on your system, that’s fine. But if you plan to setup a multiple-boot system, with more than one Installation of Linux, possibly mixing different flavors, you might get confused when configuring your boot loader.

For instance, let’s say you install Slackware and Ubuntu on your system.
From Slackware, you configure your /etc/lilo.conf to read the kernel from /boot/vmlinuz-xxxx
To include Ubuntu in your lilo menu, you would need define your image as /dev/sdxx/boot/vmlinuz-yyyy
And to make things worse, after booting Ubuntu, your /etc/lilo.conf there will have to be different, referring to the Slackware kernel as /dev/sdyy/boot/vmlinux-xxxx

To keep things simple, have a separate /boot partition on your drive that is accessible from all your Linux installations as /boot. Just take care to name your kernels in an organized way, so that you can remember which kernel belongs to which Linux distro.

Now you will still have several copies of your /etc/lilo.conf, as it stays on the root partition of your Linux installations.
I solved this by creating an /etc folder in /boot, where I put the lilo.conf file and then create a symbolic link in /etc with this command:
# ln -s /boot/etc/lilo.conf /etc/lilo.conf
This way I can edit my lilo configuration from any Linux installation and keep things simple.

As for the size of the /boot partition, I make it 250 MB and that has always been enough for me, even with several kernels from several concurrent installations.

6. The (optional) “/home” partition
The /home partition is the subject of many discussions. Each user on a Unix or Linux system has its own /home/<username> folder, accessible only to this user and the all-powerful root.
User-specific configuration files are stored there as well, mostly in hidden sub-folders like .mozilla, .mc, etc.
If your system is only going to have one user, you might as well store everything you want in your “home” folder. But if your system has several users that share files, it is not a good idea to store them here.

The /home partition also can cause problems if one specific user put a lot of files in his home folder, filling up the whole partition and effectively locking the system for other users that can’t even save a simple configuration file. The solution to this problem is configuring a quota-system, but that is beyond the scope of this post.

As a simple rule, I create my /home partition with the size of (number of users) x 2 GB. That should be enough to save all configuration files. Shared data (downloaded MP3 files, pictures from digital cameras, etc.) go in a separate partition for data (just continue reading…)

7. The (optional) “/usr/local” partition
As I wrote above, I create my root partitions with the size of 15 GB. This is normally more than enough for a standard Linux installation plus several extra programs.
If you are installing a server with lots of local, non-standard (read: not provided by the standard installation of your Linux distribution) programs, you might want to create a /usr/local partition.

The size of this partition depends on your specific needs.

8. The (optional) “data” partition
Your desktop (or server) might contain data files you want to share with other users – locally or over the network.
I have seen many discussion on where these files should be saved on a Linux system.
Some prefer the “home” folder of the user, but then they will be available only to that particular user (unless you change the standard permissions, which is not a good idea).
Others prefer a special folder in the root directory, like “/data”, “/photos”, “/mp3″, etc. I personally don’t like this idea, as it goes against the FHS mentioned before.

In *my* opinion, data should be stored under /srv/xxxx, which is defined by the FHS as “site-specific data which is served by this system”.
If you are sharing your pictures or mp3 files, you are “serving specific data” on your system.
So I mount my “data” partition on /srv/data with sub-folders like “pictures”, “music”, etc.

The size of this partition is limited by your hard drive only and your specific needs.

9. Final conclusions
Do not forget to define all your partitions in your /etc/fstab file to mount them at boot time.

And – I can’t say this enough – it all depends on your needs.
You might not need all these partitions. You can very well survive with just a SWAP and a single root partition on a 1 TB drive. You just might encounter some problems when updating your system…

(My KDE is in Portuguese, but you’ll get the idea…)

I never bothered about it, as I prefer to do all configuring the ‘Slackware-way’: editing text files. This way I know what’s happening and I am in control.

But I understand that this is not for everyone, so this subject pops up once in a while on the forums and I decided to take a look again.

The knetworkconf tool uses several Perl scripts that are stored in /usr/share/apps/knetworkconf/backends
I am definitely not a Perl-guru, but browsing through the several files, I discovered it was nothing too complicated. Basically, network configuration hasn’t changed much in Slackware over the last several versions so first I just added the newer version numbers to all files where they were checked.

Posting the first patch file on LinuxQuestions.org a fellow forum member (thanks Woodsman!) discovered that the KDE tool did not show the configured domain correctly.
This actually was a bug in the tool, not my patch, but I managed to solve it.

After some more testing I discovered that every time I saved any changes with knetworkconf, my Samba server stopped working and was even disabled.
This turned out to be another silly bug in knetworkconf, where they forgot to use a variable that holds the current status of Samba.

I posted all patches on the forum and Pat has already included them in the -current branch (see the changelog).
I also sent the patches upstream to the fellows at KDE, so hopefully it makes it into the next versions there as well.

Those who use Slackware 12.1 (the most recent stable version), can copy the following lines and save them in a file:

*** orig/network-conf 2008-12-06 10:17:03.000000000 -0200
--- /usr/share/apps/knetworkconf/backends/network-conf 2008-12-06 10:25:17.000000000 -0200
***************
*** 78,83 ****
--- 78,84 ----
"vine-3.0", "vine-3.1",
"ark",
"slackware-9.1.0", "slackware-10.0.0", "slackware-10.1.0", "slackware-10.2.0",
+ "slackware-11.0.0", "slackware-12.0.0", "slackware-12.1.0", "slackware-12.2.0",
"gentoo", "vlos-1.2", "freebsd-5", "freebsd-6");

"gentoo" => "gentoo",
"vlos-1.2" => "gentoo",

Be careful with the longer lines!
Next, open a console as root and type the following:

cd /usr/share/apps/knetworkconf/backends
patch < (your_saved_patchfile)

This should work with all versions since 11.0, but I only tested it on 12.1 and 12.2-RC1, so all standard disclaimers apply…

The result is a working knetworkconf:

NTP is one of the oldest protocols on the internet and its predecessors, going back to the early eighties. If you are interested in reading a small article about the history of NTP, I recommend this text in PDF. The official ‘home’ of NTP is www.ntp.org

You can use NTP on your Linux desktop to automatically synchronize its clock to a pool of servers around the world that are official ‘timekeepers’. Usually you configure NTP to talk to about three different servers to guarantee that at least one is available at any time. It is best to choose servers near you, so that response times are shorter, which results in a more accurate clock on your computer. There are more than 1.500 servers to choose from, but some areas on our planet are better served than others. For instance: there are almost a thousand servers in Europe, but only 19 in South America (where I live).

Your first step should be to select three servers close to you – preferably in your country, or if there aren’t enough, in your ‘zone.
Go to www.pool.ntp.org and browse through the tree of zones and servers to select which ones are best for you.
The ‘pooling’ system automatically translates the addresses to the actual domain- and server names.
For instance, I use: 0.br.pool.ntp.org, 1.br.pool.ntp.org and 2.br.pool.ntp.org and these names are usually translated to servers at local universities or government institutions.
Don’t worry about this part, the pooling system takes care of it.

Now that you have selected your servers, let’s start configuring your system. As always, I’ll use Slackware as an example, but things will be similar in other distributions.

1. Configure /etc/ntp.conf
Edit this file with your favorite text-editor (I use vi) and go to the lines that say:

server <example-server-name>

and replace this line or lines with your servers. In my case, I put:

server 0.br.pool.ntp.org
server 1.br.pool.ntp.org
server 2.br.pool.ntp.org

While we’re editing the configuration, let’s make NTP a bit more secure, inserting some restrictions. Find the lines (usually at the end) that start with “restrict ….” and replace them with the following:

restrict default nomodify
restrict 127.0.0.1
restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap nopeer

The address 127.0.0.1 is our local IP address that has no restrictions.
The network / mask combination in the third line is my local network, so that my other desktops can use my system as a time-server, preventing all of them to send NTP queries to the internet.
On the rest of my desktops I put the line “server 192.168.1.1″ (my local IP) in their ntp.conf

2. Synchronize your clock manually
If your clock is too much behind or ahead, NTP might refuse to synchronize it, so let’s force the first synchronization with a simple command:

ntpdate 0.br.pool.ntp.org

Of course, you should substitute the server name with one from your list.

3. Make your ntp daemon executable
In Slackware this is done with the following command:

chmod +x /etc/rc.d/rc.ntpd

This (again, in Slackware) will make it start every time you boot up your system.

4. Start NTP now without rebooting
Again, a simple command:

/etc/rc.d/rc.ntpd start

That’s it!
After a few minutes, check if NTP is communicating with the server pool by running this command:

ntpq -p

It should show the servers it is talking to and one of them should have an ‘*’ in front of it.