• current HDD is /dev/sda, it has a GPT (with bios_grub being /dev/sda1), separate /boot partition (/dev/sda2), and a physical LVM volume (/dev/sda3), where LVM holds all the remaining partitions (root, /home, /srv, …); LVM is properly configured, and system reboots with no problems
• your new drive is /dev/sdb, it is identical to /dev/sda, and it comes empty from the manufacturer (this is important! wipe the drive if it is not empty, especially if it used to be a part of another RAID)
• your system is Debian or Debian-based; in this exact example I’ve been using Ubuntu Server 10.04
• your LVM volume group is named vg0
• make sure you understand what each command does before executing it
• you do have an external backup of all your important data, and you do understand that the following operations are potentially dangerous to your data integrity

Inspired by: Debian Etch RAID guide, serverfault question.

1. Create the GPT on the new drive:
   parted /dev/sdb mklabel gpt
2. Get the list of partitions on /dev/sda:
   parted -m /dev/sda print
3. Create /dev/sdb partitions similarly to what you have on /dev/sda (my example numbers follow, use your numbers here):
   parted /dev/sdb mkpart bios_grub 1049kB 2097kB
   parted /dev/sdb mkpart boot 2097kB 258MB
   parted /dev/sdb mkpart lvm 258MB 2000GB
4. Set proper flags on partitions:
   parted /dev/sdb set 1 bios_grub on (GPT doesn’t have MBR, so you create a 1-MB partition instead to hold grub2′s boot code)
   (possibly optional) parted /dev/sdb set 2 raid on
   (possibly optional) parted /dev/sdb set 3 raid on
5. (possibly optional) To make sure /dev/sdb1 (the bios_grub) indeed contains grub’s boot code, I did dd if=/dev/sda1 of=/dev/sdb1
6. apt-get install mdadm
7. Note: at this point, older tutorials suggest adding a bunch of raid* kernel modules to /etc/modules and to grub’s list of modules to load. I’m not sure this is really necessary, but do see the tutorials mentioned at the top for more information. If you do modify the lists of modules – don’t forget to run update-initramfs -u.
8. Create two initially-degraded RAID1 devices (one for /boot, another for LVM):
   mdadm ––create /dev/md0 ––level=1 ––raid-devices=2 /dev/sdb2 missing
   mdadm ––create /dev/md1 ––level=1 ––raid-devices=2 /dev/sdb3 missing
9. Store the configuration of your RAID1 to the mdadm.conf file (important! this is not done automatically!)
   mdadm -Es >> /etc/mdadm/mdadm.conf
10. Verify the contents of your mdadm.conf:
    cat /etc/mdadm/mdadm.conf
    dpkg-reconfigure mdadm, and enable booting in degraded mode
11. Copy your current /boot (/dev/sda2) to the new /dev/md0 /boot partition:
    (one can use dd here as well, but for some reason my attempt at dd failed writing 1 last byte of data)
    mkdir /mnt/md0
    mount /dev/md0 /mnt/md0
    cp -a /boot/* /mnt/md0/
    umount /dev/md0
    rmdir /mnt/md0
12. Now extend your existing volume group to include the newly-created /dev/md1:
    pvcreate /dev/md1
    vgextend vg0 /dev/md1
13. Verify the list of logical volumes you curently have: enter lvm shell, and type lvs. Here’s what I had:
    LV VG Attr LSize Origin Snap% Move Log Copy% Convert
    home vg0 -wi-ao 1.70t
    logs vg0 -wi-ao 4.66g
    root vg0 -wi-ao 10.24g
    srv vg0 -wc-ao 100.00g
    swap vg0 -wi-ao 1.86g
    tmp vg0 -wi-ao 4.66g
14. Now, you can move all the logical volumes to new physical volume in one command: pvmove /dev/sda3 /dev/md1. Personally, remembering the problem I had with dd from /dev/sda2 to /dev/md0, I decided to move all logical volumes one-by-one; as this takes time, you may consider joining these operations with ; or &&, and putting the /tmp last (as the easiest one to re-create if it fails to move):
    pvmove ––name home /dev/sda3 /dev/md1
    pvmove ––name srv /dev/sda3 /dev/md1
    pvmove ––name logs /dev/sda3 /dev/md1
    pvmove ––name swap /dev/sda3 /dev/md1
    pvmove ––name root /dev/sda3 /dev/md1
    pvmove ––name tmp /dev/sda3 /dev/md1
15. To be safer, I ran FS check on a few volumes I could umount:
    umount /dev/mapper/vg0-srv
    fsck -f /dev/mapper/vg0-srv
    mount /dev/mapper/vg0-srv
    umount /dev/mapper/vg0-tmp
    fsck -f /dev/mapper/vg0-tmp
    mount /dev/mapper/vg0-tmp
16. Remove /dev/sda3 from the physical space available to your volume group:
    vgreduce vg0 /dev/sda3
17. Install grub2 to both drives, so as to make them both bootable in case of failure:
    grub-install ‘(hd0)’
    grub-install ‘(hd1)’
18. Edit /etc/fstab, pointing /boot to /dev/md0. You may use UUIDs here, but please do not use UUIDs from mdadm.conf – those are different from FS-UUIDs, instead do ls -l /dev/disk/by-uuid to find the UUID of /dev/md0. Personally, I had no problems just using /dev/md0.
19. Now is the time to add your original /dev/sda to the RAID1; be absolutely sure you have moved all the data off that drive, because these commands will destroy it:
    mdadm ––manage ––add /dev/md0 /dev/sda2
    mdadm ––manage ––add /dev/md1 /dev/sda3
    Re-syncing array will take some time.
20. To be on the safe side, you may want to run again update-initramfs -u and update-grub; I have also edited /etc/grub.d/40_custom, adding there 2 more boot options: from /dev/sda2 and /dev/sdb2 (/boot on both drives) – have no idea if that will work, but having more boot options didn’t hurt
21. Reboot into your new system. Actually, at this point reboot is only necessary to verify that your system is bootable – you may delay this reboot as long as you want to.
22. Many tutorials also suggest testing your RAID1 by manually “degrading” it, trying to boot, and then rebuilding it back. I haven’t done that, but you may want to.

Improvement suggestions, criticism and thank-you are welcome in the comments.

Here's a sample script (call it e.g. git-truncate and put into your ~/bin or whichever location you have in PATH).

Invocation: cd to your repository, then git-truncate refspec, where refspec is either a commit's SHA1 hash-id, or a tag.

Expected result: a git repository starting with "Truncated history" initial commit, and continuing to the tip of the branch you were on when calling the script.

If you truncate repositories often, then consider adding an optional 2nd argument (truncate-commit message) and also some safeguards against improper use - currently, even if refspec is wrong, the script will not abort after a failed checkout.

Thanks for posting any improvements you may have.

Source: Tekkub's post on github discussions.
See also: how to remove a single file from all of git's commits.

Nokia Ovi Suite could not connect to the Nokia account server. Make sure the internet connection is working properly and try again.

However, both my internet connection, and logging into ovi.com using a browser work fine. Even looking for updates from within Ovi Suite works fine!

Here's the solution (tested on Nokia Ovi Suite 3.0.0.290):

Important: before trying the solution below, try downloading and running root certificates update program from Microsoft, then restarting Ovi Suite to see if the problem is gone. (Thanks Finn for sharing this one.)

• Navigate to Start - Control panel - Internet options (or: start Internet Explorer - Tools - Internet options). It doesn't matter that your default browser is not IE.
• Select Content tab.
  
• Click Certificates, select Trusted root certification authorities tab, and sort ascending by expiration date.
  
• Now delete all GTE CyberTrust certificates whose expiration date has passed.
• Click Close, then OK
• Restart Ovi suite.

If that didn't help: try removing all expired certificates:

A word of warning

Deleting all expired trusted root certs is not a good idea. You could end up with vital parts of the system not working, or unable to access some documents (especially if you have encryption turned on). Thing is, expired certs can still be valid for anything signed or encrypted before they expired.

Sources used:

• http://discussions.europe.nokia.com/t5/Nokia-Ovi-Suite/NOKIA-OVI-Suite-could-not-connect-to-the-nokia-account-server/m-p/878427
• http://betalabs.nokia.com/apps/nokia-ovi-suite-3-0-beta/bugreport/19143/ovi-sign-in-failed
• http://betalabs.nokia.com/node/5251

• if you don't have the python-stdeb package: sudo aptitude install python-stdeb
• pypi-install pycassa

That's it.

Refer to stdeb readme for more information. You will need that if there are dependencies - which might not be resolved automatically by stdeb.

Before stdeb, it wasn't exactly trivial to make a .deb from python module.

ENSRNOG00000018677 1368832_at 25233
ENSRNOG00000002079 1369102_at 25272
ENSRNOG00000043451 25353
ENSRNOG00000001527 1388013_at 25408
ENSRNOG00000007390 1389538_at 25493

In the example above I need '25353', which does not have corresponding affy_probeset_id in the 2nd column.

It is clear how to do that:

This outputs a column of required IDs (EntrezGene in this example):

116720
679845
309295
364867
298220
298221
25353

However, I need these IDs as a comma-separated list, not as newline-separated list.

There are several ways to achieve the desired result (only the last pipe commands differ):

These solutions differ in efficiency and (slightly) in output. sed will read all the input into its buffer to replace newlines with other separators, so it might not be best for large files. tr might be the most efficient, but I haven't tested that. paste will re-use delimiters, so you cannot really get comma-space ", " separation with it.

Sources: linuxquestions 1 (explains used sed commands), linuxquestions 2, nixcraft.

It might be easier to achieve the same results with a Perl script calling NCBI's e-utils.

Step-by-step:

1. Identify current swap UUID: grep swap /etc/fstab ; you should see a line starting with UUID=b4e6e... - note that UUID; let us assume our UUID is b4e6e5d8-8854-4a3e-8edb-f423ded31e2a
2. Identify swap partition device. If you are using Debian or Ubuntu, device might have been shown to you when running command #1 as a comment of the form
   

   # /dev/sdX4 none swap sw 0 0

   Just to be sure, run cat /proc/swaps (or sudo swapon -s), to be shown something like this:

   Filename Type Size Used Priority
/dev/sdX4 partition 2104504 0 -1

   You can also use partition managers to identify swap device, e.g. sudo fdisk -l. Let us assume our partition device is sdX4.

3. If that swap partition is in use, you need to disable it first: sudo swapoff /dev/sdX4
4. Now that you have both the UUID and the device, run
   sudo mkswap -L new_swap_label -U b4e6e5d8-8854-4a3e-8edb-f423ded31e2a /dev/sdX4
   Do not forget replacing sample values above (label, UUID and device) with your actual values.
5. Enable swap: sudo swapon /dev/sdX4

Now, if you wish so, you may proceed to edit /etc/fstab and replace UUID=.... with LABEL=your_new_swap_label, leaving all other spaces and values in that line untouched.

1. Back up important data from partition just in case
2. Find out size of '$Bad' attribute in $Badclus using ntfsinfo -i 8 partition (partition is for example /dev/sda1). It will be the “Allocated size” value in the “Dumping attribute $DATA (0x80)” (there will be two 0x80 attributes. Only one has an “Allocated size” line). Let us write down (remember) this size as ntfs_size.
3. Use ntfstruncate partition 8 0x80 '$Bad' 0 to set $Bad's attribute length to zero.
4. Use ntfstruncate partition 8 0x80 '$Bad' ntfs_size to set $Bad's attribute length back to proper value ntfs_size which was recorded in step 2.
5. Boot into Windows and run chkdsk -f diskname. It will find errors and should fix them.

However, Debian's ntfsprogs package does not have the ntfstruncate binary.

Here's how you can easily build one yourself (you may need a few extra packages with build tools for that):

1. apt-get source ntfsprogs
2. cd linux-ntfs-2.0.0
3. ./configure && make extra
4. cd ntfsprogs && ./ntfstruncate

You can also install ntfstruncate system-wide, but I have no idea if that will interfere with the already-installed ntfsprogs package, so I just used this binary directly from linux-ntfs-2.0.0/ntfsprogs.

Bad clusters happen not only when cloning an NTFS partition between 2 physical hard disk drives. Once, after a brief blackout (with a turned on PC, and not on a UPS), the SMART status of my new HDD started showing 1 'Pending sector'. Correspondingly, all the SMART tests (performed with a smartctl utility) reported read errors. To help my HDD examine and fix the problem itself, I performed a write operation to that single unreadable sector, which restored it (and reset the 'Pending sector' counter back to zero). It was possible, because not the physical sector itself, but the hidden CRC field had errors after power failure; modern hard drives can detect and fix this kind of errors upon write operations (read operations only mark the sector as 'pending', because data read is not consistent with the stored CRC).

However, NTFS partition still had 4096 bytes in 'bad clusters'. A little research revealed the presence of internal NTFS bad clusters counter, which can be reset following the procedures above.

UPDATE `table_name` SET `table_field` = REPLACE(`table_field`,'string to search for and replace','replacement string');

If you need a database-wide search-and-replace, you could try this script (I haven't tested/used it myself).

Beware of the following gotchas:

1. wrong query syntax may ruin the field you are performing replace on, so always backup first!
2. be sure to provide "search-for" string as specific as possible, or you will get unexpected replacements (e.g. replacing mini with little will also convert all minivans into littlevans); also, do use WHERE clause when necessary to limit the number of rows modified
3. the function in the example is case-sensitive, so replacing all minivans with vehicles won't replace Minivans. However, I believe there exists a case-insensitive version of REPLACE function

Error in openPDF(vif) :
getOption('pdfviewer') is ''; please use 'options(pdfviewer=...)'

and you are tired of running this command every time:

> options(pdfviewer="okular")

then you should check if your system-wide Renviron file has proper PDF viewer set:

grep -i pdf /etc/R/Renviron

R_PDFLATEXCMD=${R_PDFLATEXCMD-${PDFLATEX-'/usr/bin/pdflatex'}}
R_RD4PDF=${R_RD4PDF-'times,hyper'}
## Default PDF viewer
R_PDFVIEWER=${R_PDFVIEWER-''}

It wasn't in my case.

To set one, either edit the system-wide Renviron (e.g. by editing the R_PDFVIEWER=${R_PDFVIEWER-''} line to look like R_PDFVIEWER=${R_PDFVIEWER-'/usr/bin/xdg-open'} - this will use MIME types to open your preferred PDF viewer), or one of the per-user/per-directory Renviron files to fix this minor annoyance (format is the same, e.g. R_PDFVIEWER=okular ).

[ 0.004000] Checking aperture...
[ 0.004000] No AGP bridge found
[ 0.004000] Node 0: aperture @ 20000000 size 32 MB
[ 0.004000] Aperture pointing to e820 RAM. Ignoring.
[ 0.004000] Your BIOS doesn't leave a aperture memory hole
[ 0.004000] Please enable the IOMMU option in the BIOS setup
[ 0.004000] This costs you 64 MB of RAM
[ 0.004000] Mapping aperture over 65536 KB of RAM @ 20000000

and you are using AMD-based system w/o AGP video, then my advice is: just leave that as is, do not bother "improving"! Any tinkering with kernel boot options won't do you any good, as the kernel has already done the best it could.

Just a note: all those messages at the top of the post should only happen if you have 4 or more GiBs of RAM. If you have less than that, and do have those messages – my experience might be inappropriate for your case.

Another note: my BIOS does not have any IOMMU settings (or “Memory hole remapping” settings), so I didn’t try that. You should check if your BIOS has IOMMU-related options first, just as kernel message suggests.

Read on for details.

My system's kernel at the moment of writing is 2.6.30-1-amd64 (Debian testing), running on MSI's 790GX-G65 with integrated Radeon HD 3300 video, with 4 GiB DDR3 RAM and a quad-core Phenom II CPU.

Following are the options you shouldn't try on a similar system:

• passing iommu=noagp kernel boot option. If you run dmesg|grep -i agp, most likely you will see something in the lines of
  

  $ dmesg|grep -i agp
  [ 0.004000] No AGP bridge found
  [ 0.392098] PCI-DMA: Disabling AGP.
  [ 0.392142] PCI-DMA: Reserving 64MB of IOMMU area in the AGP aperture
  [ 0.774847] Linux agpgart interface v0.103

  which tells you that your kernel has automatically discovered the absence of AGP bridge, disabled it and is using 64MB of AGP aperture for IOMMU. On my system, adding that boot option had no effect.

• passing iommu=off kernel boot option. When I did this, there were loads of "nommu overflow" errors during boot, so I didn't wait until GDM start and rebooted immediately. Clearly, tons of "overflow" errors won't do any better than a harmless "This costs you 64 MB of RAM". Also, systems with over 3 GiB RAM do need IOMMU.
• passing iommu=noaperture kernel boot option. On my system, this option has taken 1 more MiB from my available RAM (as reported by free -m or htop), and also enabled software double-buffering IOMMU method (in dmesg, a string similar to SW TIOLB). Performance-wise this is worse than AMD's GART-based IOMMU, and you loose 1 more MiB of RAM , so don't do this.
• passing iommu=noagp,noaperture for me had the same effect as passing iommu=noaperture alone, for the reason from point #1 of this list.
• I haven't tried any of the memaper=[1|2|3|...] options, as I had no problems with the default 64 MiB.
• passing mem=4G may remove that message (I do not recollect if it did for me), but will eat a good deal more of your available RAM (might be because devices are now mapped within those 4G, and not above). So don't do this.

I'm not aware of any other solutions to the missing 64 MiB RAM message. There were notices of using pci=nommconf boot option, but that is too much for such a simple message - unless you have problems booting.

Below I'm pasting IOMMU-relevant part of the linux-source-2.6.30/Documentation/x86/x86_64/boot-options.txt file, which I believe is the source of ultimate knowledge You should read that file whenever you feel like tinkering with boot options of your AMD64 machine.

I ***highlighted*** some fragments, to support the points from the list above.

IOMMU (input/output memory management unit)
 Currently four x86-64 PCI-DMA mapping implementations exist:
   1. : use ***no hardware/software IOMMU at all***
      (e.g. ***because you have < 3 GB memory***).
      Kernel boot message: "PCI-DMA: Disabling IOMMU"
   2. : ***AMD GART based hardware IOMMU***.
      Kernel boot message: "PCI-DMA: using GART IOMMU"
   3.  : Software IOMMU implementation. Used
      e.g. ***if there is no hardware IOMMU*** in the system and it is need because
      you have ***>3GB memory*** or told the kernel to us it (iommu=soft))
      Kernel boot message: "PCI-DMA: Using software bounce buffering
      for IO (SWIOTLB)"
   4.  : IBM Calgary hardware IOMMU. Used in IBM
      ***pSeries and xSeries servers***. This hardware IOMMU supports DMA address
      mapping with memory protection, etc.
      Kernel boot message: "PCI-DMA: Using Calgary IOMMU"
 iommu=[][,noagp][,off][,force][,noforce][,leak[=]
	[,memaper[=]][,merge][,forcesac][,fullflush][,nomerge]
	[,noaperture][,calgary]
  General iommu options:
    off                Don't initialize and use any kind of IOMMU.
    noforce            Don't force hardware IOMMU usage when it is not needed.
                       (default).
    force              Force the use of the hardware IOMMU even when it is
                       not actually needed (e.g. because < 3 GB memory).
    soft               Use software bounce buffering (SWIOTLB) (default for
                       Intel machines). This can be used to prevent the usage
                       of an available hardware IOMMU.
  iommu options only relevant to the AMD GART hardware IOMMU:
                 Set the size of the remapping area in bytes.
    allowed            Overwrite iommu off workarounds for specific chipsets.
    fullflush          Flush IOMMU on each allocation (default).
    nofullflush        Don't use IOMMU fullflush.
    leak               Turn on simple iommu leak tracing (only when
                       CONFIG_IOMMU_LEAK is on). Default number of leak pages
                       is 20.
    memaper[=]  Allocate an own aperture over RAM with size 32MB<4GB.
                       DAC is used with 32-bit PCI to push a 64-bit address in
                       two cycles. When off all DMA over >4GB is forced through
                       an IOMMU or software bounce buffering.
    nodac              Forbid DAC mode, i.e. DMA >4GB.
    panic              Always panic when IOMMU overflows.
    calgary            Use the Calgary IOMMU if it is available
  iommu options only relevant to the software bounce buffering (SWIOTLB) IOMMU
  implementation:
    swiotlb=
[,force]
            Prereserve that many 128K pages for the software IO
                       bounce buffering.
    force              Force all IO through the software TLB.
  Settings for the IBM Calgary hardware IOMMU currently found in IBM
  pSeries and xSeries machines:
    calgary=[64k,128k,256k,512k,1M,2M,4M,8M]
    calgary=[translate_empty_slots]
    calgary=[disable=]
    panic              Always panic when IOMMU overflows
    64k,...,8M - Set the size of each PCI slot's translation table
    when using the Calgary IOMMU. This is the size of the translation
    table itself in main memory. The smallest table, 64k, covers an IO
    space of 32MB; the largest, 8MB table, can cover an IO space of
    4GB. Normally the kernel will make the right choice by itself.
    translate_empty_slots - Enable translation even on slots that have
    no devices attached to them, in case a device will be hotplugged
    in the future.
    disable= - Disable translation on a given PHB. For
    example, the built-in graphics adapter resides on the first bridge
    (PCI bus number 0); if translation (isolation) is enabled on this
    bridge, X servers that access the hardware directly from user
    space might stop working. Use this option if you have devices that
    are accessed from userspace directly on some PCI host bridge.

I'm sure that you are aware of the fact that floats representation in any programming language is limited by the precision of the internal binary representations. In other words, you can never have an exact float representation - there will always be some precision associated with the float you are working with. The simplest example is the difference in precision between the float and double types in C.

Suppose I have the following code fragment:

Both result.score and input->raw_cut_off are of type float, and can have positive and negative values. When compared with the greater than or equal ( >= ) operator, it is not always that condition is true - for the precision reasons shortly mentioned above.

As I already said, there is no precision specification for equality operators in C. But it is quite simple to "invent" precision specification; e.g. if I wanted to test for equality only, I could write

In this example, I'm effectively asking for 6-digit precision for the equality comparison of floating-point values. Note, that if you replace that 0.000001 with the actual precision limit of the floating type you are using, you will be "exactly" comparing floating-point numbers - up to that type's precision, of course .

The first-most example with the >= operator can be rewritten as

where precision is exactly what it is named, e.g. precision = 0.000001.

Sources used:

• comment by Randy A. Ynchausti
• scientific programming

Recursively set directories only to drwx-rx-rx (755):

find . -type d -exec chmod 755 {} \;

Recursively set files only to rwx-r-r (644):

find . -type f -exec chmod 644 {} \;

Recursively remove carriage returns (^M) from the end of all *.php files:

find . -type f -name "*.php" -exec /home/user/dos2unix.sh {} \;

In all these cases, {} is replaced with the filename/directory find has found matching your parameters; \; at the end just stops exec processing.

I've created a PDF of that article, containing some of the comments (all the 'thank-you' and 'help-me-hack' comments were removed): sql injection walkthrough pdf download.

Note: there were no specific license terms attached to the article; I believe that the word "free" on the SecuriTeam site logo refers to the "right of free use and copying". If you know this is not the case - please let me know to remove this PDF from public access. (see Brian's comment)

However, the default FTP connection format string [username[:password]@]hostname has a drawback of not allowing the use of usernames with '@'-symbol in them - which is very common for virtual hostings.

One of the solutions is (done in your home directory):

1. if there is no .netrc file in your home directory -- touch .netrc && chmod 600 .netrc
2. mcedit .netrc (or use vi, nano, or any other editor you prefer)
3. add the following line to the file (replace all-caps words with your actual credentials): machine HOSTNAME login USER@HOSTNAME password PASSWORD

Now, start MC, choose FTP connect, and enter only the hostname. You will be automatically logged in to the remote FTP.
This will also work for console ftp clients like lftp.

cat styles.css | tr -d "\r" > styles-nocarriage.css

will create styles-nocarriage.css with ^M's removed.

Alternative syntax:

tr -d "\r" < styles.css > styles-nocarriage.css

Most editors have global replace features which allow to get rid of control characters using regular expressions (exact instructions are editor-specific).

For multiple files, try this:

for f
do
mv $f ${f}~ && tr -d "\r" <${f}~ >$f
rm ${f}~
done

Save this shell script as a file (e.g. dos2unix.sh), then do ./dos2unix.sh . This script accepts wildcards (e.g. ./dos2unix.sh *.php), so be careful!

The aroma.affymetrix R package google group has a how-to: create a CDF annotation file from scratch.

Also useful: how to convert CDF into an R package, which has all CDF data available (as a PDF with more details).

First of all, sudo aptitude install mesa-utils. Then run in a Terminal/Konsole glxgears, and wait for ~15 seconds; if your FPS is ~400 or less, then you do have sluggish video performance (usually manifesting itself as slow scrolling in Firefox/Iceweasel, slow window switching/minimziing/maximizing etc).

After reading through several forums and bug reports and blog posts, I've ended with the following modifications to my /etc/X11/xorg.conf:

1. backup your current xorg.conf: sudo cp /etc/X11/xorg.conf /etc/X11/xorg.conf.before-exa
2. open your /etc/X11/xorg.conf with a favourite editor; I've added these lines to section "module":
   

   Load "dbe"
   Load "xtrap"
   Load "record"
   Load "GLcore"

   These are not really performance-related and could be skipped; I'm giving them here, because they were suggested as default entries by dexconf or some other xorg.conf-generator utility. Again - they are not supposed to improve performance, so you can skip these.

3. my "Device" section is now:
   

   Section "Device"
   Identifier "Intel Corporation 82915G/GV/910GL Integrated Graphics Controller"
   BoardName "82915G/GV/910GL Integrated Graphics Controller"
   Vendorname "Intel Corporation"
   #Driver "i810"
   Driver "intel"
   BusID "PCI:0:2:0"
   Option "DRI" "true"
   Option "AccelMethod" "exa"
   Option "MigrationHeuristic" "greedy"
   Option "ExaNoComposite" "false"
   EndSection

   Driver i810 (xserver-xorg-video-i810 package) was about 10-20 FPS slower than Driver intel (xserver-xorg-video-intel package) for me. The most important lines here are Option AccelMethod exa (which enables EXA acceleration instead of the older XAA; if you run 2.6.28 or later kernel, you can try UXA instead of EXA) and Option MigrationHeuristic greedy. Option ExaNoComposite false doesn't make a difference for me, and Option DRI true might be redundant (didn't bother trying to remove it).

4. at the end of xorg.conf I have two more sections:
   

   Section "DRI"
   Mode 0666
   EndSection

   Section "Extensions"
   Option "Composite" "enable"
   Option "MIT-SHM" "Yes"
   EndSection

5. sudo nano /etc/environment, and add one line: INTEL_BATCH=1 (if you have graphics stability issues or screen corruption - try removing this change first)
6. you can test if your xorg.conf is syntactically correct by running X -config /etc/X11/xorg.conf (provided that you edited this exact file)

This is it. Before these modifications, my FPS in glxgears was around 430; after these modifications it is ~915.

As time permits, I might try the XAA configuration, suggested at foolcontrol.

Update: with compiz enabled, XAA configuration recommended at foolcontrol is definitely faster in 2D.

Improvements, suggestions, corrections are welcome.

1. cd gitosis-admin && git pull - enter your gitosis administrative repository and ensure it is up-to-date
2. $EDITOR gitosis.conf
3. add [group newreponame] section (newreponame is the name of your new repository being added); add yourself with members = yourlogin@yourhost line; also add writable = newreponame line:
   

   [group newreponame]
   members = yourlogin@yourhost
   writable = newreponame

4. based on my assumption of a correctly setup gitosis-admin repository, you should already have the appropriate public key in the keydir directory, but if not - copy your user's ssh public key to keydir in the form of yourlogin@yourhostname.pub, then do git add keydir/yourlogin@yourhostname.pub
5. git commit -am 'new repository: newreponame'; git push;
6. now that you have the new repo permissions configured, let's actually create it. Navigate to the directory holding the files of your project (e.g. cd ~/newreponame), and do git init; git add . - this initializes empty git repository, and then adds all the files to it. If you have no files - you can skip the 'git add .' command, as it will do nothing for you.
7. git commit -m 'initial commit'. If you had no files added to the commit, git will complain that it cannot create an empty commit. In this case use the command git commit ––allow-empty -m 'initial commit'
8. git remote add origin ssh://gitosis@yourGitosisServerName/newreponame.git
9. git push ––all
10. final thing: git config ––add branch.master.remote origin && git config ––add branch.master.merge refs/heads/master; alternatively, cd .git && $EDITOR config, and then add these lines:
    

    [branch "master"]
    remote = origin
    merge = refs/heads/master

    Without these lines, you won't be able to git pull.