Quick fix for X.org screensaver bypass

Posted by on

This vulnerability is quite annoying if you’re locking your desktop in work or anywhere else.

In short, one is able to kill xorg’s xscreensaver’s lock by just pressing alt-ctrl-* or alt-ctrl-/ (both * and / need to be from the keypad).

A workaround that was posted suggests to modify files in the system. If you don’t want to (like me – for various reasons) then you can do this on-the-fly.

Put the following script in a file and make it run whenever you log in to your X session (e.g. by putting it in ~/.kde/Autostart/ if you’re using KDE):

#!/bin/bash

xkbcomp :0 - > /tmp/xkbcomp
cat /tmp/xkbcomp \
 | sed -n '/key <KPMU> {/,/^ *}/ !p' \
 | sed -n '/key <KPDV> {/,/^ *}/ !p' \
 > /tmp/xkbcomp.new
xkbcomp /tmp/xkbcomp.new :0

On each login, this will get rid of the offending xkb entries.

fix for radeon + opensource driver + kde effects = crash

Posted by on

The problem

Kwin crashes when enabling opengl effects. It doesn’t crash immediately but it crashes after specific actions so it is 100% reproducible. For example when exiting from desktop-grid effect.

The situation

I’m using:

  • Radeon 4870 graphics card (RV770)
  • Kernel 3.1.5 (but seems irrelevant)
  • Open source ATI driver with KMS using Gallium
  • Xorg 1.11.2.902 (but happened with previous versions)
  • MESA 7.11.2
  • KDE 4.7.4 from debian
  • DRM 2.4.29
  • xserver radeon driver 6.14.3

I’m not using the blur effect

The solution

cd to ~/.kde/env/ (create it if it doesn’t exist)

create a file named gl.sh (or any other name) with execute permissions (should not be needed) and with the following contents:

#!/bin/bash

export LIBGL_ALWAYS_INDIRECT=1

The first line should not be needed as this file most probably gets source’d, but it will not hurt.

The drawback

Every GL app you’ll be using will inherit the LIBGL_ALWAYS_INDIRECT from environment, which may cause problems. If you want to play (for example) a game then open a terminal and run:

unset LIBGL_ALWAYS_INDIRECT
nexuiz  # or whichever opengl app you want to launch

Note: Fireofx is one of the applications that may use GL.

Big nfs_inode_cache

Posted by on

The story

Boxes with various kernel versions have weird free memory problems. After examining the memory usage it seems that processes don’t add up to the actual memory that is being used.

Taking a look at /proc/meminfo we see something like this:

MemTotal:      8161544 kB
MemFree:        115676 kB
Buffers:          3900 kB
Cached:         200520 kB
SwapCached:      42336 kB
Active:         546824 kB
Inactive:       138336 kB
HighTotal:           0 kB
HighFree:            0 kB
LowTotal:      8161544 kB
LowFree:        115676 kB
SwapTotal:     2096472 kB
SwapFree:       547480 kB
Dirty:            1020 kB
Writeback:           0 kB
AnonPages:      453480 kB
Mapped:          66928 kB
Slab:          7250176 kB
PageTables:      75408 kB
...

Notice that Slab is about 7.5GB, almost the whole memory (8GB) (!).

Slab is the kernel memory and we can see where it is allocated by examining /proc/slabinfo. Here’s an excerpt:

# name            <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> : tunables <limit> <batchcount> <sharedfactor> : slabdata <active_slabs> <num_slabs> <sharedavail>
nfs_direct_cache       0      0    136   28    1 : tunables  120   60    8 : slabdata      0      0      0
nfs_write_data        62     63    832    9    2 : tunables   54   27    8 : slabdata      7      7      0
nfs_read_data        215    297    832    9    2 : tunables   54   27    8 : slabdata     33     33     54
nfs_inode_cache   5384386 5399040   1032    3    1 : tunables   24   12    8 : slabdata 1799680 1799680     40
nfs_page             534    750    128   30    1 : tunables  120   60    8 : slabdata     25     25    264
rpc_buffers            8      8   2048    2    1 : tunables   24   12    8 : slabdata      4      4      0
...

Notice the nfs_inode_cache which is 5.3M objects of 1032 bytes each, adding up to about 5.4GB.

The workaround

Looking a bit about this on the internet we see that this is most probably a bug. Fortunately there are two workaround: A slow and a fast one:

Slow workaround: Login to that box and run “sync”. Then leave it alone for a couple of minutes while the nfs_inode_cache memory goes down and down. It make take a couple of minutes before starting going down and there may be pauses in the process. It can take more than an hour to free the memory.

Fast workaround: Login to that box and run:

# sync
# echo 2 > /proc/sys/vm/drop_caches

I’m not sure why the first one works, but it looks like it is triggering a chain reaction that frees the memory.

Easy one-time git subtree merge

Posted by on

The situation:

  • Have a git project (A)
  • Have a second git project (B) that I want to merge to A under a directory
  • This needs to be done once. After that, project B will not be re-sync to A’s subdirectory
  • Need to preserve history

The actual situation: I have a git project that is named “drlaunch” and another git project that is named “debian”. “debian” is the packaging directory for drlaunch. The problem occurred because I used to have two svn trees, one for the project and one for the debian/ directory for making this a package for maemo.

I found a number of related things but all of them were complicated because they were doing more than I wanted. Finally, I came to this simple solution:

Under project drlaunch, there is a subdir drlaunch. I want to include the project debian under a directory named debian in the drlaunch project. The tree looks like this:

drlaunch (project)
\-- drlaunch (dir)

debian (project)

And at the end I want it to look like this:

drlaunch (project)
|-- drlaunch (dir)
\-- debian (dir)

The solution is as simple as this:

  1. Go to the debian’s project dir and export all changes with format-patch: 
    cd debian/
mkdir ../1
git format-patch --root -o ../1/
rm ../1/0000-*

    (Note: The removal of the first file is required. The file should be empty and for me it triggers a git bug causing it to use 100% cpu indefinitely. Feel free to check it yourself)

  2. Go to the drlaunch’s project dir and import all changes to a directory: 
    cd drlaunch/
git am --directory=debian/ ../1/*
  3. Ta-da! Ready! Now compare the tree to be sure that nothing bad happend: 
    diff -uR debian ../debian/

Don’t forget to commit your changes.

$

Multiple Monitors with Opensource Radeon Driver and Xorg

Posted by on

Setting up multiple monitors is currently a nice experience. Doing this from krandrtray, which is a very very nice front-end, is easy. But doing it via xorg.conf can be … well … interesting. That’s mostly because each driver has its own method of properly setting up multiple monitors.

Here’s how to setup multiple monitors with xorg.conf when using the opensource radeon driver (tested with 6.14.1). The tricky part (and the one that took me aprox. 1 hour to figure) is to name the Monitors with the exact same name as the card’s outputs.

First, you need to launch X at least once with both monitors connected just to find out the output names. Look at /var/log/Xorg.0.log:

$ grep 'Output.*connected' /var/log/Xorg.0.log
(II) RADEON(0): Output HDMI-0 connected
(II) RADEON(0): Output DIN disconnected
(II) RADEON(0): Output VGA-0 disconnected
(II) RADEON(0): Output DVI-0 connected

From the above search you can see that the connected outputs are named HDMI-0 and DVI-0. You may be able to determine which monitor is connected to which output either by looking up its resolution:

(II) RADEON(0): Output HDMI-0 using initial mode 1920x1200

or other information in Xorg.0.log

Next you need to create or update /etc/X11/xorg.conf. The required relevant sections are as follows:

Section "Monitor"
        Identifier   "HDMI-0"
        Option          "Primary"       "On"
EndSection

Section "Monitor"
        Identifier   "DVI-0"
        Option          "LeftOf"        "HDMI-0"
EndSection

Section "Device"
        Identifier      "Card0"
        Driver          "radeon"
        BusID           "PCI:1:0:0"
        Screen          1
EndSection

Section "Device"
        Identifier      "Card1"
        Driver          "radeon"
        BusID           "PCI:1:0:1"
        Screen          1
EndSection

Section "Screen"
        Identifier "Screen0"
        Device     "Card0"
        Monitor    "HDMI-0"
        DefaultDepth    24
        SubSection "Display"
                Depth     24
                Modes   "1920x1200"
        EndSubSection
EndSection

Section "Screen"
        Identifier "Screen1"
        Device  "Card1"
        Monitor "DVI-0"
        DefaultDepth    24
        SubSection "Display"
                Depth 24
                Modes "1440x900"
        EndSubSection
EndSection

Section "ServerLayout"
        Identifier     "Layout0"
        Screen          "Screen0" 1440 0
        Screen          "Screen1" LeftOf "Screen0"
EndSection

Now I’m not sure about the second “LeftOf” because I stopped restarting X and KDM after it worked, but IIRC, it is not required.
As it was mentioned earlier, the tricky part is to named the Monitors as the outputs of the card (HDMI-0 and DVI-0 in my case).
Also, I remember that using the above naming for PciIDs is also required (observer that they are different) and I believe tht the “Monitor” statement inside the “Screen” section doesn’t affect anything.

If everything is setup correctly you should see this in Xorg.0.log:

(II) RADEON(0): Output HDMI-0 using monitor section HDMI-0
(II) RADEON(0): Output DVI-0 using monitor section DVI-0

which indicates that monitor sections where properly matched with outputs.

pyzor problem after debian squeeze upgrade

Posted by on

After upgrading some servers to Debian squeeze, the following log was filling the logs:

Feb 18 12:49:38 aetos check[982]: pyzor: [19952] error: TERMINATED, signal 15 (000f)

The problem was caused by wrong pyzor servers. Unfortunately, pyzor keeps a servers list in each home directory in file ~/.pyzor/servers. This is what this file used to have:

82.94.255.100:24441

This file is created automatically (with a proper value) so it is safe to remove it. That’s what it should have (for now):

public.pyzor.org:24441

In order to get rid of the error message all users’ files should be deleted:

find /home -name servers | grep pyzor/servers > /tmp/lst
# examine /tmp/lst by hand to verify that nothing bad is there
cd /home
cat /tmp/lst | xargs rm

That’s it. There should be no more “TERMINATED” messages.

A fast interpreted language

Posted by on

How can one claim that an interpreted language is fast?

Easily. If you implement the language using itself and the resulting interpreter is faster than the original then this means that the interpreted language manages to imprint the prorgammer’s intentions to the C language (or assembly) better than the programmer herself.

For example, I may create an interpreted language named V using C and try to make the implementation as fast as I can. Of course this means that I have to implement a number of data structures and handle them. Also I have to optimize code path etc etc.

Then I re-implement the V language using the V language itself. If the re-implementation if faster than the original implementation then this means that the interpreter’s logic produces faster code than me.

Well… here it is. The Python implementation in Python is faster than the Python implementation using C!

Read: It is very probable to end up with a faster program if you write it using python instead of C because the language will do better than you will in optimizing your data structures and your code. Just like it is better to write C than assembly and let your compiler to produce the optimized assembly code.

World’s smallest IPv6 compatible web browser program

Posted by on

For a long time now I’ve become a fan of the python+Qt combination. It is great to have an easy to learn, easy to use language with great portability and minimalistic syntax.

The following program has become my favorite showcase for python. To my knowledge, it is the smallest, easier to understand, portable, IPv6 compatible web browser in the world.

If you have IPv6 connectivity just lunch python and copy-paste it save it to a file and run it (it may crash python otherwise):

from PyQt4.QtCore import *
from PyQt4.QtGui import *
from PyQt4.QtWebKit import *

app=QApplication([])
win=QMainWindow()
w=QWebView(win)
win.setCentralWidget(w)
w.setUrl(QUrl("http://ipv6.google.com/"))
win.show()
app.exec_()

If you don’t then you can try the IPv4 version:

from PyQt4.QtCore import *
from PyQt4.QtGui import *
from PyQt4.QtWebKit import *

app=QApplication([])
win=QMainWindow()
w=QWebView(win)
win.setCentralWidget(w)
w.setUrl(QUrl("http://www.google.com/"))
win.show()
app.exec_()

In order to be able to run it you’ll need the Qt4 library and the python Qt bindings. If you’re under debian just run:

# apt-get install python-qt4

This should work at least under Linux, Windows, Maemo and perhaps Symbian.

Double slit experiment

Posted by on

Some time ago I read this and show this (The whole list here, especially the double slit experiments series) and this and this. Then I read some more and more.

While this is really amazing I wanted to test it myself. The following is an easy setup that anyone with a somehow programmable camera (i.e. you can change shutter speed) and a common laser pointer can do.

Results

Here are the results of 3 different experiments (you may need to click on the photos for better resolution):

Experiment 1:

  • One slit:
  • Two slits:

Experiment 2:

  • One slit:
  • Two slits:

Experiment 3:

  • One slit:
  • Two slits:

Amazing eh? :-)

Do it yourself

You can test it yourself. For the experiment you’ll need:

  • Blu tak
  • Pencil leads
  • A laser pointer
  • Some batteries for the laser pointer
  • Black thick paper (e.g. black carton. I used a black folder)
  • A camera where you can change the shutter speed and (optionally) with optical zoom.

The setup will look like this:
Setup of experiment

Here are the steps:

  1. First make sure you have fresh batteries for the laser pointer. I used 3 AA batteries instead of 3 LR41. They should last much longer (just compare their size :-) . Both of them (AA and LR41) are 1.5V.
  2. I used a paper clip to keep the button of the laser pointer pressed at all time. You’ll need to find a way to have the laser on without touching it.
  3. Get a small piece of the black paper and open a very small slit. Then put this in front of the laser and stick it at the bottom with the blu tak. This part ensures that only a small part of the laser beam will pass and that it will be very focused.
  4. Using blu-tak glue together 3 pencil leads as shown here:
    3 pencil leads, sticked together
    This will act as your double slit. The laser beam that passes through the one-slit paper should drop on those pencil leads and light two slits.
  5. Since light is tricky, you should make sure that no light passes outside of the two slits, so you will have to use two pieces of black paper to block light. See the setup picture for the idea. If you do it right, you should see the laser beam cut at the outside pencil leads.
  6. Put the camera directly in front of the laser beam. To do this you’ll have to first remove the pencil leads and aim at the beam. At this point you’ll have to make some adjustments to height of the camera and the laser. That’s why I used a book and a ruler bellow the laser pointer (moving it left-to-right allowed for smooth up-down movements of the laser beam).
  7. In order to adjust the camera you’ll need to become familiar with what moves what. For example, the beam is centered on the display by tilting the camera, while it is focused by moving the camera. Just do it yourself.
  8. Use as much zoom as possible and turn camera focus to infinity. Then adjust the shutter speed to appropriate values (I used values between 1/15 and 1/90 IIRC).
  9. From the first picture you’ll be able to see the distances that worked for me. That’s why I added the second ruler at the bottom of the image.

Here are two additional photos of the left and right sides of the setup:
Laser, connect to batteries and the single slit in front
Right side of setup: Camera, pencil leads

After setting up the experiment you’ll have to start testing it. First make sure that laser light passes between both slits and only between them. If you take a picture you should see something like the two-slit results (you may need to zoom inside the pictures to actually see it). Then move the black papers a bit to prevent light passing from one of the two slits and take another picture.

TATA! Now that you performed the experiment you may want to try and figure out why this happens. If you eventually figure it out you’ll have solved one great unsolved quantum mystery. So simple yet so tricky!

Explanation of the experiment results

The easiest result to explain is the result of experiment 2: The first photo shows what the camera captured when laser light was passing from one slit while the second show the result when light was passing from both slits. It is clear that there is some interference at the second case. In fact, allowing light to pass from both slits results in areas that are darker than when light was passing just from one slit (!). It is easy to see the two-slits because there are vertical lines. The height of each vertical line is no more than some millimeters.

Same thing for experiment 1 (click on the photos to actually see it): At first you may believe that this is a problem with focus, but the focus was fixed for both photos.

Experiment 3 is more eye-catching because it shows two different effects: The large light bands are the result of light diffraction while the smaller patterns are interference patterns. Diffraction is also visible with naked eye. Just put a piece of paper between the laser and the stencil leads and you will see the light bands. Unfortunately I could not get a photograph because they were not visible at the camera (i.e. the photos just showed a single spot and some artifacts. Test it yourself. It’s very impressing!)). Interference on the other hand is not visible with naked eye.

Let me end this post with a phrase from matrix: “Welcome to the real world”

And this month’s medal of stup^H^H^H^Hcleverness goes to…

Posted by on

Internet Explorer for this.

Really, if MS was not MS but a company that was payed to write applications, making this information public should be enough reason not to hire them.

Let me rephrase the explanation: “If you give me a letter and say that this letter is only handed once, I will drop it because… well… because… no reason…”

Following the KB’s logic, if a document expires after 1 second and an application takes more than a second to launch then it should not be able to open the file…

… and it gets better: If the document expires after 10 seconds, you should have 10 seconds to read it. Else the document will be closed…

… and finally: if you save this document to a file, the file should be automatically deleted after it has expired.

Those are not true, but according to MS’s logic, they could be. Perhaps in IE10 :-)