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.

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.

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:

1. On the Debian based system, mount the USB flash drive and create a new directory 'lenny' on it.
2. 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/
3. After debootstrap completed, connect the USB flash drive to the Fritz!Box.
4. Log in to the Fritz!Box via Telnet. When prompted for a password, use the one you set for the web interface.
5. Change directory to /var/media/ftp/. Your USB flash drive should be mounted automatically as USB2-0-FlashDisk-00.
6. 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.
7. Mount proc: mount -t proc proc /var/media/ftp/USB2-0-FlashDisk-00/lenny/proc
8. Let debootstrap complete the installation: ./busybox_1.16.1_7390_static chroot /var/media/ftp/USB2-0-FlashDisk-00/lenny /debootstrap/debootstrap --second-stage
9. 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!

javax.net.ssl.SSLPeerUnverifiedException: No peer certificate.

Here is a "quick and dirty" solution which makes the HttpClient trust any certificate without verifying it (not recommended to be used in productive environments, of course). Read more...

1. Getting the necessary classes

Get the classes EasySSLSocketFactory and EasyX509TrustManager from here.

Open the EasySSLSocketFactory class and modify the following method in this way:

public Socket createSocket(Socket socket, String host, int port, boolean autoClose)
throws IOException, UnknownHostException {
	//return getSSLContext().getSocketFactory().createSocket();
	return getSSLContext().getSocketFactory().createSocket(socket, host, port, autoClose);
}

The modification is necessary to avoid the following error:

javax.net.ssl.SSLException: SSL handshake aborted: ssl=0x2cb0e8: I/O error during system call. Broken Pipe

2. Making it work

Use the following code to create an instance of DefaultHttpClient which will accept connections to HTTPS hosts without verifying the SSL certificate:

SchemeRegistry schemeRegistry = new SchemeRegistry();
schemeRegistry.register(new Scheme("http", PlainSocketFactory.getSocketFactory(), 80));
schemeRegistry.register(new Scheme("https", new EasySSLSocketFactory(), 443));
 
HttpParams params = new BasicHttpParams();
params.setParameter(ConnManagerPNames.MAX_TOTAL_CONNECTIONS, 30);
params.setParameter(ConnManagerPNames.MAX_CONNECTIONS_PER_ROUTE, new ConnPerRouteBean(30));
params.setParameter(HttpProtocolParams.USE_EXPECT_CONTINUE, false);
HttpProtocolParams.setVersion(params, HttpVersion.HTTP_1_1);
 
ClientConnectionManager cm = new SingleClientConnManager(params, schemeRegistry);
this.httpClient = new DefaultHttpClient(cm, params);

Source: http://stackoverflow.com/questions/1217141/self-signed-ssl-acceptance-android

Only very few WBXML parsers for Java seem to be available. One of the libraries you will probably come across when searching for a WBXML Java Library is kXML. kXML is a small XML pull parser, specially designed for constrained environments such as Applets, Personal Java or MIDP devices (see kXML's about page).

Getting started with kXML is a bit tricky, since you find only a handful of tutorials that are suitable for kXML 2. These snippets should make it easier for you. Read more...

Converting WBXML to XML:

InputStream in = ...... // TODO
WbxmlParser parser = new WbxmlParser();
// You may want to set some code pages here using parser.setTagTable()
parser.setInput(in, "UTF-8");
Document dom = new Document();
dom.parse(parser);
 
ByteArrayOutputStream out = new ByteArrayOutputStream();
KXmlSerializer ser = new KXmlSerializer();
ser.setOutput(out, null);
dom.write(ser);
ser.flush();
 
byte[] b = out.toByteArray();
System.out.println(new String(b));

Converting XML to WBXML:

InputStream in = ...... // TODO
KXmlParser parser = new KXmlParser();
parser.setInput(in, "UTF-8");
Document dom = new Document();
dom.parse(parser);
 
ByteArrayOutputStream out = new ByteArrayOutputStream();
WbxmlSerializer ser = new WbxmlSerializer();
// You may want to set some code pages here using ser.setTagTable()
ser.setOutput(out, null);
dom.write(ser);
ser.flush();
 
byte[] b = out.toByteArray();
System.out.println(new String(b));

Working with Code Pages / Tag Tables

Code pages/tag tables specify which tag string is encoded by which integer. The protocol you're about to implement defines its own tag table - so you will have to tage a look at its specifications. Please refer to the the W3C WBXML documentation for further information.

Here is a small example:

public static final String [] TAG_TABLE_0 = {
	"Tag1", // 0x05
	"Tag2", // 0x06
	"Tag3", // 0x07
};
 
public static final String [] TAG_TABLE_1 = {
	// ...
};
 
parser.setTagTable(0, TAG_TABLE_0);
parser.setTagTable(1, TAG_TABLE_1);
parser.setTagTable(2, ...);

Instead of installing the 32bit version of JDK, try the following workaround that I've found in the codearetoy blog.

Warning: Use these instructions at your own risk! Damaging the registry may lead to unexpected results and/or data loss!

1. Open regedit.
2. Navigate to HKEY_LOCAL_MACHINE\Software\JavaSoft\
3. Export the entire content.
4. Open the .reg-File you've saved the export to with an editor and replace "HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\" with "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\JavaSoft\".
5. Double-click the .reg-File to run the import.
6. Run the Android SDK installer again - it should work now.

Here are the steps:

1. Edit the site's binding and add an HTTPS Binding. Ignore the host header now, this will be added later.
2. Open a command prompt (cmd).
3. Change directory to C:\Windows\system32\inetsvr
4. Enter the following command (replace "Your Site Name" and "www.yoursite.com" with the appropriate values): appcmd set site /site.name:"Your Site Name" /bindings.[protocol='https',bindingInformation='*:443:'].bindingInformation:*:443:www.yoursite.com

Update: Unfortunately, this doesn't seem to be a solution for  SNI. IIS can only bind certificates to IP addresses, not hosts. So if you change the certificate for one site on one IP address, all sites hosted on this IP address will be updated as well. So far, the only solution to use different certificates with a single IP address is to use different TCP Ports. However, the guide above allows you to set up multiple SSL hosts sharing one certificate on one IP address/port.

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.

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:

1. 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
   
2. 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
   
3. 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"/>