It seems the intel driver in the Ubuntu repositories is still pretty old. You can download a new one from their website, though and install it manually.

I wish there was an updated package available for hardy. You can probably use the intrepid package again, though. It has version number 2.3.2. Then you can leave the EXA acceleration enabled without the related problems with e.g. Opera.

I switched on the RCU Preemption in the Linux 2.6.25.7 kernel and suddenly noticed stuttering video-playback in mplayer. Seems that sometimes it didn't get its data in time anymore. After I added the -cache 4096 parameter, it was fixed. But I really wonder how that could be, as there was nothing going on in the background.

I really wish the b43 driver would work better... I keep losing the connection after a certain time. It is much better in 2.6.25.7 than in 2.6.26.6, but it's still disappointing to keep having to remove and reinsert the module to stay online. I'm really disappointed in Broadcom. The intel wireless drivers are a lot more reliable and obviously broadcom could do much more to ensure its hardware works well in Linux. The b43 team still does a great job at the open source driver for the seemingly pretty limited hardware. Still I guess if you want good Linux support, avoid Broadcom, prefer Intel or other Linux-friendly hardware manufaturers.

This will work with KDE4 and should as well work with newer Gnome versions. Tested with KDE 4.1 beta1. It needs the display variable to be set and be run as the appropriate user.e.g. su $user -c "DISPLAY=:0 dbus-send... "

In Ubuntu 8.04 you can change your /etc/acpi/resume.d/90-xscreensaver.sh to lock the screen on resume like this:

I could not resume from standby anymore after upgrading the bios on my notebook. Turns out I just had to reset the hard disk password in the BIOS settings. The BIOS somehow forgot to unlock the hard disk during resume after the update. Removing it and setting it again fixed the problem.

"Please do contribute to Linux, and a great way of doing that is to test latest mainline or linux-next or -mm and to report on any problems which you encounter.

Nothing special is needed - just install it on as many machines as you dare and use them in your normal day-to-day activities.

If you do hit a bug (and you will) then please be persistent in getting us to fix it. Don't let us release a kernel with your bug in it! Shout at us if that's what it takes. Just don't let us break your machines.

Our testers are our greatest resource - the whole kernel project would grind to a complete halt without them. I profusely thank them at every opportunity I get :)"

I recommend using the release candidates(-rcX), you can get them at www.kernel.org and report bugs at bugzilla.kernel.org. The nice thing is that this way you can make sure the next kernel will work on your system before it's even out. And you're usually not the only person who would suffer from these bugs of course.

I've installed Opera 9.5. It's really nice and I'm actually writing this entry with it right now. But then because of unfortunate resume problems after a BIOS upgrade with my Acer notebook, I've installed and tried the new version in Windows as well.

And frankly, I was amazed. The websites loaded so quickly it seemed they were just there immediately. Awesome work, Opera. But then I started wondering:

If you wonder, just as I just did, what the different options in the Advanced section of System Settings: Desktop: Desktop Effects: Advanced Options in KDE4 means, here is the answer:

OpenGL is the fastest solution as it uses your graphics card's 3d acceleration for rendering.

Texture from Pixmap is the fastest option, as it stores the texture directly in the graphics card's memory, which is usually faster than the system ram.

Shared Memory stores the textures in X's shared memory, which resides in the system RAM and is usually much slower than the graphics card's memory.

Fallback tries Texture from Pixmap first and Shared Memory if that does not work.

XRender is less fast as it only uses 2d acceleration but much more compatible and works with older graphics cards as well.

The other options:

Direct rendering passes the commands directly to the graphics card and bypasses the X server. This is much faster as it the commands have to be copied less, but can be more instable and less compatible.

VSync stands for vertical synchrosation and ensures that the pictures are drawn in sync to the vertical display updates. This can be more soothing to the eyes, but is a little slower and just drawing the frames any time the graphics card is ready to do so.

It's also supposed to help with some memory issues. I will see if that maybe fixes my problems with plasma x shared pixmap cache I just posted about earlier. Even though its the older one of the two x acceleration infrastructures, the intel driver's support of it seems much more stable and fast.

It seems plasma leaks into x shared memory. This would explain why I had such a high value xrestop. After I restarted X it was down to only around 6 MB. It's funny but I don't even really notice these things anymore now that I have 2 GB RAM.

I wonder how many memory won't get noticed because developers have "too much" RAM in their developing systems...

By the way, if plasma constantly crashes for you and your settings get lost, you can just quit it with "kquitapp plasma", this saves its settings and then quits plasma.

Update: I've found a bug report on bugs.kde.org and it seems to be already fixed in SVN trunk.

If you find out that Xorg grows bigger and bigger with time, chances are high that this is not actually Xorg, but a program that uses its pixmap cache.

xrestop will tell you just that. It lists the applications by how much pixmap cache they use. Mine starts with "" using about 226 MB(!), looking up the process id shows that "" stands for plasma! (Nice try at hiding, budddy!)

To use the KDE4 eye candy, you don't have to do much. You can activate the effects under System Settings and Desktop. Then you go to All effects and activate cover switch. I really like how it displays the windows while flipping through them with alt-tab.

You can also let it snow on your desktop, show stars around the mouse cursor, etc. And with a simple click you can add one of the high (and probably quickly increasing) number of kde4 plasma widgets, also known as plasmoids.

There is some issue related to knotify4, which causes around 100 wakes / second to show up in powertop. It looks like there have already been issues with KDE 4.0.x and there has been improvements since. But it's still too much for notebook use.

The suggested fix is to turn off the notifications, which did not work for me, though. What worked for me was a good old killall knotify4. ;)

I just finished the very basic work of my first very own plasmoid. It's pretty fun and very low on resources.

KDE4 still crashes a lot. Ktorrent crashed while exiting, When the main panel is removed, there is a crash. And when you put the panel back it doesn't stay there. It crashes every time on logout then as well.

But it's really pretty. Finally 3d-cards get some good use! :) And I really like the themes. How automatic and smooth everything runs and looks. It feels totally different to use it. Different than anything I've tried before.

It almost like my keyboard feels softer. That's just how smooth it looks.

I hope that it will stabilize well during the beta testing. And no matter how long it takes, one thing is clear for me:

KDE 4 will be an amazing desktop environment. It will go further than any other desktop environment before it.

It is crossing the borders of not only architectures, but also programming and scripting languages and even operating systems.

It is nowadays simply too easy to manipulate network traffic. There is for example a Chinese Software called Netsense, which makes it so easy, smooth and effortless, the people using it really might not even know it's using illegal techniques. I don't have any idea, though because I don't know what the manual or description says -> I don't speak Chinese.

ARP is the address resolution protocol. It resolves a computer's IP address to a computer's hardware MAC address. ARP poisoning means that one computer(A) claims to be the owner of the IP address of another computer(B). Computer(A) then gets all network traffic destined for that computer(B). This would mean that the computer(B) the network traffic is actually destined to would not get it anymore. Therefore the spying host(A) is usually configured to forward the packages to the actual host(B) after inspecting them.

Now let's see what you can do against ARP Poisoning under Linux.

First let's find out, what's going on. For that purpose wireshark is very helpful. Wireshark displays all network traffic on your interface. For our purposes we do not need to use the promiscuos mode, as we only have to see the packages directed at our machine. If you want to watch for other machines being poisoned you need to activate the promiscous mode. Usually activating it shouldn't hurt, so let's activate it. What you will see characteristically is that (1) one hosts keeps announcing its MAC address via ARP without any other hosts actually having asked for it beforehands. Wireshark may detect a duplicate use of IP addresses (3). And the normal ARP resolutions process(2) of a host asking for the IP address and then gettings its answer usually does not happen anymore for that particular address. (1) is called IP spoofing, as a host claims to have an IP address which it actually does not.

Let's see what we can do about it. There are two things you can do. The easy one, which works under Windows as well, is to set the MAC address manually, called static mac assignment. Type in run, or in a console:

arp -s 192.168.0.1 00-12-34-56-78-90

You should replace 192.168.0.1 with the ip address of the host that is constantly shown in (1) and the mac address behind it with the real mac address of that host, which you can either look up manually or if you're lucky, see as in (2), e.g. when the ARP poisoning is not active at the moment.

Under Linux you can often chose a more flexible approach and simply ban the host that is poisoning your machine. Now don't even try using the normal iptables against it, in my tests it had absolutely no effect. But there is a version of it called arptables, which can help you.

sudo arptables -A INPUT -m mac --source-mac ff:ee:dd:cc:bb:aa -j DROP

While ff:ee:dd:cc:bb:aa should be replaced with the mac address of the host that can bee seen as sources mac address in (1). Now the host should not be able to poison your arp table (or communicate with you) anymore at all. Of course you can also just manually set the IP address just as under windows above

sudo arp -s 192.168.0.1 00-12-34-56-78-90

This will still allow the host to communiate with you.

To check what hosts and what mac address are in the arp table simply use

sudo arp

Remember that while the ARP poisoning is active and working, the hosts poisoning your arp table can usually see all your network traffic. This means the host can log and save everything in your network traffic, such as your passwords, emails, instant messages and everything that is not or poorly unencrypted, even some poorly configured online banking pages. It will most probably also have an impact on the connection speed, especially if you're using a wireless network with a bad reception.

I hope it helped. Any questions or remarks in the comments are welcome.

I just downloaded and tried KDE4.1 Beta 1 for Ubuntu. It's got some quirks still, but it really rocks. It's very beautiful and smooth.You see the desktops with some widgets: Notes, Dictionary, Slideshow, Fuzzy Clock(pretty cool), Logout&Lock, Trash Can.

Here is a list of bugs I have found so far:

knotify4 causes a very high wakeup rate (>100/sec) in powertop

many screensavers don't seem to show up, esp. kde3 ones

the display settings change the display, but don't change the settings of guidance-displayconfig, which is called at/etc/X11/Xsession.d/40guidance-displayconfig_restore

when the display resolution is changed, the panel at the bottom does not change until explicitly reset, not even after logout and login

it often gets stuck during logout and has to be killed with ctrl-alt-backspace