I hacked together this little ruby script to read the G-measuring device in the Thinkpad’s harddisk (HDAPS) and rotate the desktop cube of Beryl when sudden movement occurs. A bit like what has been done for the MacBook already.
http://w-nz.com/~darkshines/projects/rtollina.rb
GPL, obviously. It’s not really perfect yet. I’ll try to improve it tomorrow and add support for compiz and maybe even make a little widget out of it.
It’s based on code by Fer, which is for Compiz instead of Beryl.
I tried to get AIGLX to work on my Thinkpad yesterday. AIGLX is an API similar to XGL, but is a better implementation. Unfortunately AIGLX requires implementation by the video-card driver (which is good because it allows more performance), but the proprietary drivers of ati still doesn’t support it. (nvidia’s do, note to myself: get nvidia next time).
So I had to revert to XGL. A lot has changed since the last time I installed XGL. Other gentoo overlays, other windows managers, other hacks.
I used the gentoo-xeffects overlay to get Xgl.
Installing Xgl was a lot more straight forward and less of a problem than it used to be. An emerge and writing a simple startxgl script was enough.
The compiz-quinstorm patchset seems to have evolved to a proper branch of the compositing window manager, now called Beryl. It also includes a nice settings manager now.
Even hibernation and suspend finally seem to work. 🙂
A nice screenshot:
One thing left to do: integrate Xgl into xdm.
Sometimes you need to lock several resources. If you don’t take great care you are likely to get yourself into dead-locks. A simple example with just two lockable resources A and B:
function foo {
lock A;
lock B;
// Do something with A and B
unlock A;
unlock B;
}
function bar {
lock B;
lock A;
// Do something different with A and B
unlock B;
unlock A;
}
When foo and bar are called at about the same time then there is the change that foo locks A and bar locks B which will make bar wait on foo‘s lock on A and vice versa.
Solution: fixed order on memory address
The simplest way to get rid of the deadlock is to always try to acquire a lock on A before on B. A generic solution would be to always lock the resource with the lowest memory address first.
This only works when memory addresses are fixed or that there is an otherwise fixed order-able property.
I’ve always been bothered by the fact that you need to be root to mount anything (like an usb stick). It can be solved a bit by setting up udev rules and putting a specific device in /etc/fstab, but that only works for that single usb stick. Pretty annoying.
Googling only gives you stupid and silly solution (like allowing users to mount /dev/sd[a-z] — security risk).
Luckily I’ve recently been pointed to ivman, which is an automounter. It automatically mounts removable media for you in /media.
I looked at the internals of ivman, and noticed that it uses pmount, which is a wrapper around mount which allows users to mount removable media on a /media folder. Great!
Btw, you need to be in the plugdev group to use pmount.
Update It seems that gnome-mount also works fine when you’re in the plugdev group. Gnome-mount does about the same as pmount with the advantage that gnome-mount has got the nice gui integration everywhere in gnome.
I found this patch: reiser4-for-2.6.19.patch.gz.
In Internet Explorer in some cases backgrounds disappear seemingly randomly. The fix? Add the position: relative; style entry to the concerned div tags.
Instead of limiting your long key (for instance a path) to approximately 800 characters (on mySQL with generic UTF8), you can hash your key and store the hash as index.
The drawback is that you need to use a quite good hash function to avoid duplicates if you want to use it for a unique or primary key. These good hash functions tend to require some computing time.
md5(microtime())Don’t use md5(microtime()). You might think it’s more secure than md5(rand()), but it isn’t.
With a decent amount of tries and a method of syncing (like a clock on your website) one can predict the result of microtime() to the millisecond. This only leaves about a 1000 different possible return values for microtime() to be guessed. That isn’t safe.
Just stick with md5(rand()), and if you’re lucky and rand() is backed by /dev/random you won’t even need the md5(). In both cases it will be quite a lot more secure than using microtime().