Increasing Google Chrome’s Scroll Speed
On my Ubuntu 11.10 system, scrolling through pages using Google Chrome was terribly slow using the mouse wheel.
Here is an easy way to fix this: Launch Chrome with the parameter --scroll-pixels=n, where n is the number of pixels to scroll. For example:
google-chrome --scroll-pixels=400
To integrate this parameter into the desktop shortcut link, open the following file as root: /usr/share/applications/google-chrome.desktop
Search for the line "Exec=/opt/google/chrome/google-chrome %U" and replace it with "Exec=/opt/google/chrome/google-chrome --scroll-pixels=400 %U". Now, you can easily start Chrome using your desktop shortcut and the mouse scroll speed should be improved.
Java’s SecureRandom.generateSeed() on Linux
On my Ubuntu server, running the following Java code caused the application to hang:
for (int i=1; i<=1000; i++) { SecureRandom random = new SecureRandom(); // Deprecated: byte[] iv = random.getSeed(16); byte[] iv = random.generateSeed(16); System.out.println(i); }
The code runs smoothly on Windows, but hangs on Linux. I found out that with Java 5 or later, you need to run your application with the following parameter:
-Djava.security.egd=file:/dev/./urandom
Alternatively, you can modify the file jre/lib/security/java.security so that the following property is set permanently:
securerandom.source=file:/dev/./urandom
This applies to JRE 5, JRE 6 and JRE 7.
By the way: In Java 1.4, the default setting is /dev/random, which tends to block if there is no I/O action. Changing the setting to /dev/urandom (as above) fixes the issue here.
For further information, have a look at this bug report.
How to set up a chrooted Debian Environment on Fritz!Box Fon WLAN 7390
Setting up a chrooted Debian Environment on the Fritz!Box 7390 allows you to run almost any software on your Fritz!Box (at least, if it's compatible with the box' MIPS CPU). These instructions shouldn't harm your Fritz!Box if you follow them carefully - however, there's no warranty, you do it on your own risk.
To get started, you need the following:
- A Debian based system with debootstrap installed (aptitude install debootstrap)
- Telnet must be activated on the Fritz!Box (with latest firmware, just call #96*7*)
- An USB flash drive with at least 512 MB free space, formatted as ext2/3
Note: We will set up Debian Lenny, as Debian Squeeze seems not to be compatible with the kernel employed by the Fritz!Box. You will get errors like "Cannot utime: Unknown error" using dpkg or tar with Squeeze. Read here (German) and here for more information.
The entire setup takes about one hour.
Let's start:
- On the Debian based system, mount the USB flash drive and create a new directory 'lenny' on it.
- Execute the following command (after correcting the path to your lenny folder):
debootstrap --foreign --arch=mips lenny /mnt/usb/lenny ftp://ftp.de.debian.org/debian/ - After debootstrap completed, connect the USB flash drive to the Fritz!Box.
- Log in to the Fritz!Box via Telnet. When prompted for a password, use the one you set for the web interface.
- Change directory to /var/media/ftp/. Your USB flash drive should be mounted automatically as USB2-0-FlashDisk-00.
- Get a Busybox version that features chroot, such as the busybox_1.16.1_7390_static.bz2 from here and extract it into the current folder.
- Mount proc: mount -t proc proc /var/media/ftp/USB2-0-FlashDisk-00/lenny/proc
- Let debootstrap complete the installation: ./busybox_1.16.1_7390_static chroot /var/media/ftp/USB2-0-FlashDisk-00/lenny /debootstrap/debootstrap --second-stage
- The installation is completed now. You can use the following script to chroot into your freshly installed Debian environment:
cd /var/media/ftp export DISTDIR=USB2-0-FlashDisk-00/lenny umount $DISTDIR/proc mount -t proc proc $DISTDIR/proc rm -f $DISTDIR/etc/fstab touch $DISTDIR/etc/fstab cp -f /etc/resolv.conf $DISTDIR/etc hostname > $DISTDIR/etc/hostname cp -f /etc/hosts $DISTDIR/etc ./busybox_1.16.1_7390_static chroot $DISTDIR /bin/bash
Thanks to the users at IP-Phone-Forum.de and Freetz.org!
Error 0×80070021 when using lighttpd’s WebDAV with Windows 7
When trying to use WebDAV provided by a lighttpd installation with Windows 7, you will probably encounter the following error message when copying files to the WebDAV folder:
Error 0x80070021: The process cannot acess the file because another process has locked a portion of the file.
The reason for this error is that mod_webdav is "far away from 100%" (see http://redmine.lighttpd.net/wiki/1/Docs:ModWebDAV). I guess it's caused by the circumstance that shared locks are handles as exclusive locks (not sure about that). There is a bug open in lighttpd's issue tracker for 3 years: http://redmine.lighttpd.net/issues/1492
For now, the only opportunity I see is to switch to Apache. That's really sad, lighty is so nice except for this bug.
Tomcat & Apache: High CPU Usage
Summary: Tomcat running behing an Apache Frontend Server can cause high CPU Usage on the Java Process. Here are several approaches how to fix it.
Setup: Debian GNU/Linux, Java Runtime Environment (JRE) 1.6, Apache 2.2, Tomcat 6.0.29, mod_jk/mod_proxy
Effect: Accessing web applications directly through Tomcat doesn't cause any problems. When accessing web applications through the Apache Frontend Server (forwarding requests by using mod_proxy), it took a few seconds and the cpu usage of the Java process went up to 99.9 %. Obviously, the combination of Apache and Tomcat is causing this problem.
Fix: There are several approaches that could help to fix the issue:
- Make sure you're using a newer version of the APR Tomcat Native Library than 1.1.4. See: https://issues.apache.org/bugzilla/show_bug.cgi?id=40909
- If you're using mod_proxy to forward requests from Apache to Tomcat, switch to mod_jk. It is more mature than mod_proxy, although mod_proxy is sometimes consideres to be the successor of mod_jk. For a comparison of both, see: http://community.jboss.org/blogs/mladen.turk/2007/07/16/comparing-modproxy-and-modjk
- What finally solved the issue for me: Set a Connection Timeout for the AJP Connector in Tomcat's server.xml (see http://tomcat.apache.org/tomcat-6.0-doc/config/ajp.html). Here is an example:
<!-- Define an AJP 1.3 Connector on port 8009 --> <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" enableLookups="false" keepAliveTimeout="20000" executor="default" connectionTimeout="5000"/>