Easy one-time git subtree merge

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:[shell]
   cd debian/
   mkdir ../1
   git format-patch --root -o ../1/
   rm ../1/0000-*
   [/shell]
   
   (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:
   [shell]
   cd drlaunch/
   git am --directory=debian/ ../1/*
   [/shell]


3. Ta-da! Ready! Now compare the tree to be sure that nothing bad happend:
   [shell]
   diff -uR debian ../debian/
   [/shell]

Don't forget to commit your changes.

$

Multiple Monitors with Opensource Radeon Driver and Xorg

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:
[code language="bash"]
$ 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
[/code]
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:
[code]
(II) RADEON(0): Output HDMI-0 using initial mode 1920x1200
[/code]
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:
[code]
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
[/code]

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:
[code]
(II) RADEON(0): Output HDMI-0 using monitor section HDMI-0
(II) RADEON(0): Output DVI-0 using monitor section DVI-0
[/code]
which indicates that monitor sections where properly matched with outputs.

pyzor problem after debian squeeze upgrade

After upgrading some servers to Debian squeeze, the following log was filling the logs:
[code]
Feb 18 12:49:38 aetos check[982]: pyzor: [19952] error: TERMINATED, signal 15 (000f)
[/code]

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:
[code]
82.94.255.100:24441
[/code]

This file is created automatically (with a proper value) so it is safe to remove it. That's what it should have (for now):
[code]
public.pyzor.org:24441
[/code]

In order to get rid of the error message all users' files should be deleted:
[code]
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
[/code]

That's it. There should be no more "TERMINATED" messages.

A fast interpreted language

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

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):

[python]
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_()
[/python]

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

[python]
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_()
[/python]

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:

[bash light="true"]
# apt-get install python-qt4
[/bash]

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

Double slit experiment

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:


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:
   
   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:



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...

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 :-)