the notebook you are searching in has been moved or renamed since the saved search was created

(which is not true).

I had this problem, and found a solution.

Go to your Evernote on a client where you can edit saved searches (Windows for me),
edit all the searches, and make sure that notebook name is quoted in the search (and also, possibly, with all proper letter cases).

I found this solution by first creating a search from the web-beta interface, it looked like this: notebook:"Mynotebook" tag:1-now
All the crossed-out searches (despite working totally fine on Windows) looked like this: notebook:Mynotebook tag:1-now
or even like this (note the lower-case 1st letter of the notebook name): notebook:mynotebook tag:1-now.

After editing saved searches and synchronizing, they all appear (and work) just fine in the beta web-interface.

If you cannot edit your searches right now, there is another workaround: all the saved searches work fine for me from the Shortcuts menu (a star in the left panel).

Hope this helps!

There is an easy solution to get Notes-only without editing the PDF.

If you have a PDf printer installed (most Linux distributions, and Windows 10), just do File -> Print from Impress,
then under the Print sub-header choose Notes from the Document drop-down (see picture).
Make sure to set the proper paper format for the PDF printer (A4 in my case).
Then print, and save the resulting PDF.

Sources:

• question on ask.libreoffice.org
• LibreOffice bug report

The simplest solution to forward requests from the web-frontend to your API is by using mod_proxy.
If you want to forward any requests to /api/* to your custom back-end server on port 8000, you just add the following lines to your VirtualHost configuration:

ProxyPass “/api” “http://localhost:8000″
ProxyPassReverse “/api” “http://localhost:8000″

I’d suggest not wrapping this fragment with the classical IfModule: as your application will not really work without its API back-end, you actually want Apache to fail as soon as possible if mod_proxy is missing.

That was easy, right? What, it doesn’t work? Can’t be! It’s dead simple! No way you could make a mistake in 2 lines of configuration!!! :mad_rage:

Oh wait… I remember I had this problem before…

Let’s check:

1. Step 1. Did you disable (using a2dissite default or a2dissite 000-default, depending on your Debian-based GNU/Linux) the default website? If your application and the default website are configured in a similar way, then it might be the default site which is serving your app’s pages. The most sure way is to just disable it.
2. Step 2. Did you enable also the proxy_http sub-module? (Using a2enmod proxy_http, followed by service apache2 restart) mod_proxy is only the core module, actual per-protocol work is done by these sub-modules.

Your requests to /api should now be passed on to your API server. If not – please write in the comments what was the problem in your case and how you solved it. HTH!

• synchronization appears to work correctly;
• total count of steps is updated, but when you click it – there are no per-hour details;
• in the older app version: after sync completes, there is no green message “Updated X items”;
• night sleep tracker does not update at all: neither total hours slept, nor per-hour details;
• the band is otherwise functional, e.g. “Find the band” works – it vibrates and flashes diodes.

Warangelo00 found a solution, which worked for me (and no, you do not need to hard reset the device):
note: the fix below will most probably not work for Mi Band 2, see comments; iPhone owners may try switching iPhone from AM/PM (12-hour clock) to 24-hour clock to fix the non-synchronization problems with MiBand2 – please write in the comments if this method works for you.

1. enable Bluetooth, if it is disabled;
2. start Mi Fit, go to Play –> Incoming call (or, in older app version, Settings – Incoming calls);
3. enable it – set to On;
4. now call your mobile phone from a different one – wait for the band to vibrate and flash lights;
5. you should now be able to refresh Mi Fit main page, and see both current day and previous night per-hour details; in the older app version, it should also show the green “Updated X items” message after syncing;
6. you can now disable incoming calls notification if you don’t need it.

According to Holly, the trick may also work for Mi Pulse.

Not sure if this fix will last, but it did help me – thanks, Warangelo00!

I am updating a multisite Drupal 6 installation. To the best of my knowledge, the only difference for Drupal 7 is that instead of the site_offline D6 variable the maintenance_mode variable is used in D7.

On Debian stable and later, you can sudo aptitude install drush and then just use it immediately after that.

Note: I recommend su webuser (or sudo -s followed by sudo -s -u webuser) before you run any non-testing drush commands, where webuser is the user which owns your web-exposed files (e.g. Debian’s default is, I think, www-data). I’ve seen a lot of recommendations to run drush as a super-user, but that does not make sense, and may actually cause problems with file ownership.

One last thing before we start: if your drush seems to work fine but hangs when untarring modules – check this solution.

1. Run some innocent command in drush to see if it produces any PHP warnings/errors you may want to fix before running actual update: drush @sites core-status. In my case, all the sites had the CacheRouter module for in-RAM caching with a server daemon back-end, which was not initialized properly when drush bootstrapped Drupal from the command line. In my case, the only working solution was to edit settings.php files of every site to comment out the CacheRouter configuration for the period of update. If you get no warnings/errors, proceed to the next step. Note: I was running drush from the Drupal’s root (directory which has top-level index.php and .htaccess files), but this should also work if you run from sites/ or even sites/sitename.
2. Here would be several more steps – copying your production website(s) to a dev-server (if you do not have one already), performing an update on the dev-server first to see if anything breaks and needs fixes, then migrating updated website(s) from the dev-server to production server. Drush actually has tools to simplify all of these procedures. However, the websites I was updating were not critical, and short downtime was not a problem, so I was updating live websites. Modify these steps as you see fit to make the process more reliable.
3. Backup databases of all your sites. With drush: drush @sites sql-dump --result-file --gzip. This puts backups somewhere into the home directory of your webuser. Backups are named with a human-readable timestamp. Of course, you can also create a manual Backup and Migrate backup, or use phpMyAdmin, or just mysqldump.
4. Backup your site’s files. This step might be unnecessary, as drush seems to backup modules it is upgrading. I would still recommend making a backup, e.g. with tar -acf multidrupal.tar.bz2 html, where html is the directory containing your multisite Drupal’s root index.php.
5. Put the websites into maintenance mode and clear all caches; see the D7-specific note above: drush @sites variable-set site_offline 1 ; drush @sites cache-clear all.
6. The actual update! The easiest way would probably be to drush @sites pm-update, but I haven’t tested that and used a process which I understand better, and which seems more reliable to me (if anything goes wrong). If in your drupal root you have sites/site1 and sites/site2, then run:
   
drush site1 pm-updatecode
drush @sites updatedb
drush site2 pm-updatecode
drush @sites updatedb

   The pm-updatecode command only updates files, and does not run database update. So with these commands I am first updating modules from site1, then running database update on all sites, then update modules of site2, and run database update on all sites again. Running drush @sites updatedb multiple times, even when there are no updates, should be safe. Take note of any warnings/errors reported, you will want to fix them later, for example:

   WARNING: Updating core will discard any modifications made to Drupal core files, most noteworthy among these are .htaccess and robots.txt. If you have made any modifications to these files, please back them up before updating so that you can re-create your modifications in the updated version of the file.

7. Disable maintenance mode. Cleaning the cache seems unnecessary, as updatedb command does that. drush @sites variable-set site_offline 0.
8. Finalize: re-enable anything disabled before the updates, fix warnings/errors you noted during the update.

This worked well for me, and I hope it works well for you.

Current setup:

• MX records point to the spam protection mail servers, which then
• connect to my server and deliver (hopefully spam-free) mail.

Problem: some senders (like last.fm) do have proper, strict SPF records. Tumgreyspf on my server then rejects emails relayed through the spam-protection service.

If these spam protection relay servers are the only which send mail to your server, then it makes sense to fully disable/uninstall tumgreyspf. Putting tumgreyspf into the permanent “learning mode” (set defaultSeedOnly = 1 in /etc/tumgreyspf/tumgreyspf.conf) may not fix the SPF problem described above, as SeedOnly seems to only affect greylisting, and not rejecting unauthorized senders.

Solution: whitelist relay server IPs.

I will use MXGuardDog spam blocker as an example. This solution is a slightly extended version of this one, and used tumgreyspf README as the reference.

• For each of the IPs you want to whitelist, create a directory tree under /var/lib/tumgreyspf/config/client_address. Here is a copy-pasteable example for MXGuardDog, based on their list of server IPs, valid as of August 2013:
  
mkdir -p /var/lib/tumgreyspf/config/client_address/108/166/117
mkdir -p /var/lib/tumgreyspf/config/client_address/174/129/28
mkdir -p /var/lib/tumgreyspf/config/client_address/216/58/39
mkdir -p /var/lib/tumgreyspf/config/client_address/222/229/219
mkdir -p /var/lib/tumgreyspf/config/client_address/64/15/147
mkdir -p /var/lib/tumgreyspf/config/client_address/66/85/178

• Into each of these IP range-specific directories, put a config file, which disables checks (or symlink one). First, create /etc/tumgreyspf/disable.conf with the following lines in it:
  
SPFSEEDONLY = 0
GREYLISTTIME = 600
CHECKERS =
OTHERCONFIGS =

  It is just like the default.conf, but has empty CHECKERS and OTHERCONFIGS lines.
  Now, symlink it into each of the IP range directories:
  
ln -s /etc/tumgreyspf/disable.conf /var/lib/tumgreyspf/config/client_address/108/166/117/__default__
ln -s /etc/tumgreyspf/disable.conf /var/lib/tumgreyspf/config/client_address/174/129/28/__default__
ln -s /etc/tumgreyspf/disable.conf /var/lib/tumgreyspf/config/client_address/216/58/39/__default__
ln -s /etc/tumgreyspf/disable.conf /var/lib/tumgreyspf/config/client_address/222/229/219/__default__
ln -s /etc/tumgreyspf/disable.conf /var/lib/tumgreyspf/config/client_address/64/15/147/__default__
ln -s /etc/tumgreyspf/disable.conf /var/lib/tumgreyspf/config/client_address/66/85/178/__default__


Note the double-underscores to the left and right of default.

That’s it.

• 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 something like dd -if /dev/sda2 -of /dev/md0 here as well, but for some reason my attempt at dd failed writing 1 last byte of data)
    mkdir /mnt/md0
    mkfs.ext4 /dev/md0 (one can also use other filesystems here, e.g. mkfs.ext3 or even mkfs.ext2)
    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).


#!/bin/bash
git checkout --orphan temp $1
git commit -m "Truncated history"
git rebase --onto temp $1 master
git branch -D temp
# The following 2 commands are optional - they keep your git repo in good shape.
git prune --progress # delete all the objects w/o references
git gc --aggressive # aggressively collect garbage; may take a lot of time on large repos


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.

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

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.

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

Development: see http://www.ruzee.com/blog/2009/01/apache-virtual-hosts-a-clean-setup-for-php-developers. This setup works very well, unless you need to create several virtual hosts every day – in which case necessary actions could be partially scripted.

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:
[C] if ( result.score >= input->raw_cut_off ) [/C]

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
[C] if ( fabsf( result.score – input->raw_cut_off ) < 0.000001 )[/C] 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
[C] if ( result.score > ( input->raw_cut_off – precision) ) [/C]
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.

This is how to do that in Drupal 7 (Views 3):

1. edit the view which makes the block available (follow http://your.site/admin/build/views/viewname/edit)
2. in the Sort Criteria section (under Filter), look for and add Global:Random.

This is how to do that in Drupal 6 (Views 2):

1. edit the view which makes the block available (follow http://your.site/admin/build/views/viewname/edit)
2. in the Sort Criteria section, add the Random criteria.

It can’t be simpler than that.

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!

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.

I assume that the problem is caused by Google Analytics, namely the “track outgoing clicks” feature (as recalled, might be inaccurate feature name). “Track outgoing links” adds some JavaScript code to all outgoing links, and that script has tick characters like this one ‘ which, incidentally, are also used for delimiting the values of comment anchor tags.

To fix:

1. locate file wp-includes/comment-template.php
2. in that file, find the get_comment_author_link function (lines 140-150 in WP 2.7.1)
3. replace the line
   1. $return = "<a href='$url' rel='external nofollow' class='url'>$author</a>";

   with

   1. $return = '<a href="'.$url.'" rel="external nofollow" class="url">'.$author.'</a>';

This helped me and might help you.