Versucht man die VMware tools in der neuesten Version unter Ubuntu 8.04 LTS zu kompilieren, so erhält man diese Fehlermeldung:
Your compiler "/usr/bin/gcc" version "gcc-Version 4.2.4 (Ubuntu 4.2.4-1ubuntu4)" is not supported by this version of VMware Tools.
Die Ursache dafür ist, dass das vmware-config.pl-Skript nicht mit einem auf deutsch lokalisierten GCC klar kommt. Dies muss man vorher auf englisch umstellen:
Zuerst sicher stellen, dass alle zum Kompilieren notwendigen Pakete vorhanden sind:
apt-get install build-essential linux-headers-generic
und dann kompilieren:
LANG=C vmware-config-tools.pl
Montag, 14. Dezember 2009
Donnerstag, 26. November 2009
Google Trends geht zusammen mit InternetExplorer unter
Schaut man sich die Google Trends verschiedener Webseiten an, so gewinnt man den Eindruck, dass immer weniger Leute ins Internet gehen:
Heise.de:
Spiegel.de
Microsoft.com:
Vergleicht man den Google-Trend seiner eigenen Seite aber mal mit den eigenen Statistiken, so fällt auf, dass der Google-Trend nicht stimmen kann: auf der eigenen Seite werden mehr Zugriffe verzeichnet, obwohl der Trend nach unten zeigt. Woher kommt diese Diskrepanz? Nun ja, schauen wir uns mal die Browser-Trends in diesem Zeitbereich an:
Die Grafik zeigt zwar einen längeren Zeitbereich, als die Google-Trends - 2000 bis 2009 statt nur 2007 bis 2009, aber wenn man den Marktanteil des InternetExplorers mit den Trend-Kurven vergleicht, sieht man eine frappierende Ähnlichkeit. Dies bringt mich zu meiner Vermutung, warum die Grafiken alle nach unten zeigen: die Trends werden u.A. aus dem Nutzerverhalten von Benutzern mit dem Google-Toolbar ermittelt. Mit dem Rückgang des InternetExplorers und dem Aufstieg von Firefox verwenden immer weniger Nutzer diesen Toolbar und damit greifen scheinbar weniger Leute auf die Webseiten zu.
Also Google: rechnet den Marktanteil des IEs in eure Trends rein, dann stimmen die Grafiken wieder!
Heise.de:
Spiegel.de
Microsoft.com:
Vergleicht man den Google-Trend seiner eigenen Seite aber mal mit den eigenen Statistiken, so fällt auf, dass der Google-Trend nicht stimmen kann: auf der eigenen Seite werden mehr Zugriffe verzeichnet, obwohl der Trend nach unten zeigt. Woher kommt diese Diskrepanz? Nun ja, schauen wir uns mal die Browser-Trends in diesem Zeitbereich an:
Die Grafik zeigt zwar einen längeren Zeitbereich, als die Google-Trends - 2000 bis 2009 statt nur 2007 bis 2009, aber wenn man den Marktanteil des InternetExplorers mit den Trend-Kurven vergleicht, sieht man eine frappierende Ähnlichkeit. Dies bringt mich zu meiner Vermutung, warum die Grafiken alle nach unten zeigen: die Trends werden u.A. aus dem Nutzerverhalten von Benutzern mit dem Google-Toolbar ermittelt. Mit dem Rückgang des InternetExplorers und dem Aufstieg von Firefox verwenden immer weniger Nutzer diesen Toolbar und damit greifen scheinbar weniger Leute auf die Webseiten zu.
Also Google: rechnet den Marktanteil des IEs in eure Trends rein, dann stimmen die Grafiken wieder!
Freitag, 18. September 2009
DB2 auf Ubuntu 9.04 Jaunty installieren
Bei der Installation von DB2 9.7 gibt es einen "geringfügigen Fehler", der leider zur Folge hat, dass DB2 nicht startet. Der Ursache ist ein fehlendes Verzeichnis. Zum Korrigieren sind folgende Befehle auszuführen:
cd /opt/ibm/db2/V9.7
rm logs
mkdir logs
chown bin.bin logs
Statt dem Verzeichnis existiert nur ein Link auf ein nicht existierendes Verzeichnis.
cd /opt/ibm/db2/V9.7
rm logs
mkdir logs
chown bin.bin logs
Statt dem Verzeichnis existiert nur ein Link auf ein nicht existierendes Verzeichnis.
Sonntag, 13. September 2009
Azureus auf AMD64 (x86_64)
Azureus verweigert unter einem 64-Bit-Linux den Dienst mit der Meldung, dass ihm das 32-Bit SWT unter 64-Bit nicht passt. Zur Abhilfe lädt man das 64-Bit SWT herunter und ersetzt mit der darin enthaltenen swt.jar diejenige von Azureus. Aktuell (12. Juni 2009) ist die URL für SWT diese hier:
http://www.eclipse.org/downloads/download.php?file=/eclipse/downloads/drops/R-3.5-200906111540/swt-3.5-gtk-linux-x86_64.zip
Da die Zeit vergeht und diese Seiten bestehen bleibt, hier der Weg zur jeweils aktuellsten Version:
http://www.eclipse.org/downloads/download.php?file=/eclipse/downloads/drops/R-3.5-200906111540/swt-3.5-gtk-linux-x86_64.zip
Da die Zeit vergeht und diese Seiten bestehen bleibt, hier der Weg zur jeweils aktuellsten Version:
- Auf der SWT-Seite unter "Releases - Stable" den Link "more..." anklicken
- dort unter "SWT Binary and Source" den Link "Linux (x86_64/GTK 2) verwenden.
Donnerstag, 3. September 2009
BASE Reisevorteil oder Reisenachteil?
Gerade mal die Preise fürs Ausland bei BASE geprüft: es gibt Reisevorteil, Reisevorteil Plus, International. Der Reisevorteil hört sich ganz gut an, also prüfen wir mal die Preise:
Bis 191 Sekunden (3 Minuten 11 Sekunden) ist der International mit der Ausnahme eines kleinen Fensters günstiger. Kurz mal "hallo wir sind gut angekommen" sagen kostet sogar nur 1/3. Der Reisevorteil hilft also nur Dauertelefonierern. Dann mal die eingehenden Anrufe anschauen:
Dann aber bestimmt bei den SMS-Preisen:
Und da ja!!! Ich spare beim Reisevorteil Plus tatsächlich 0,04€ pro SMS! Wer im Ausland also nur SMS versendet, der hat tatsächlich einen Vorteil. Nur darf niemand anrufen, denn dann schwindet der Vorteil wie Eis in der Sonne.
Bleiben nur noch die Datenverbindungen für Surfen und MMS, die Paketierung ist hier weniger wichtig, insbesondere, wenn es ums Surfen geht. Hier die Preise für 1MB Datentransfer:
Ist man in einem der Reisevorteilsländer, dann lohnt sich der Reisevorteil Plus mit einem knappen Euro / MB, wenn man unbedingt Mails abrufen und versenden muss.
- Reisevorteil: 0,75€ + 0,29€/Minute, Taktung 60/60
- Reisevorteil Plus: 0,75€ + 0,29€/Minute, Taktung 60/60
- International: 0,51€/Minute, Taktung 30/1
Bis 191 Sekunden (3 Minuten 11 Sekunden) ist der International mit der Ausnahme eines kleinen Fensters günstiger. Kurz mal "hallo wir sind gut angekommen" sagen kostet sogar nur 1/3. Der Reisevorteil hilft also nur Dauertelefonierern. Dann mal die eingehenden Anrufe anschauen:
- Reisevorteil: 0,29€/Minute, Taktung 60/60
- Reisevorteil Plus: 0,29€/Minute, Taktung 60/60
- International: 0,22€/Minute, Taktung 1/1 (!!!)
Dann aber bestimmt bei den SMS-Preisen:
Und da ja!!! Ich spare beim Reisevorteil Plus tatsächlich 0,04€ pro SMS! Wer im Ausland also nur SMS versendet, der hat tatsächlich einen Vorteil. Nur darf niemand anrufen, denn dann schwindet der Vorteil wie Eis in der Sonne.
Bleiben nur noch die Datenverbindungen für Surfen und MMS, die Paketierung ist hier weniger wichtig, insbesondere, wenn es ums Surfen geht. Hier die Preise für 1MB Datentransfer:
Ist man in einem der Reisevorteilsländer, dann lohnt sich der Reisevorteil Plus mit einem knappen Euro / MB, wenn man unbedingt Mails abrufen und versenden muss.
Samstag, 29. August 2009
MMS mit Android G1 und E-Plus/BASE/Blau O2/Fonic/Simply
Nach langer Zeit endlich funktionierende Einstellungen bei Android-Hilfe gefunden:
Für E-Plus/BASE/Blau:
###############
APN #1 für Internet...
###############
Name: internet
APN: internet.eplus.de
Proxy: Nicht festgelegt
Port: Nicht festgelegt
Nutzername: eplus
Passwort: eplus
Server: Nicht festgelegt
MMSC: Nicht festgelegt
MMS-proxy: Nicht festgelegt
MMS-port: Nicht festgelegt
MCC: 262
MNC: 03
APN-Type: default
###############
APN #2 für MMS........
###############
Name: mms
APN: mms.eplus.de
Proxy: Nicht festgelegt
Port: Nicht festgelegt
Nutzername: mms
Passwort: eplus
Server: Nicht festgelegt
MMSC: http://mms/eplus
MMS-proxy: 212.23.97.153
MMS-port: 8080
MCC: 262
MNC: 03
APN-Type: mms
Für O2/Fonic/Simply (Dank an raudi!)
###############
APN für Internet und MMS
###############
Name: internet
APN: internet.interkom.de
Proxy: Nicht festgelegt
Port: Nicht festgelegt
Nutzername: mms
Passwort: eplus
Server: Nicht festgelegt
MMSC: http://10.81.0.7:8002
MMS-proxy: 82.113.100.6
MMS-port: 8080
MCC: 262
MNC: 07
APN-Type: mms
Für E-Plus/BASE/Blau:
###############
APN #1 für Internet...
###############
Name: internet
APN: internet.eplus.de
Proxy: Nicht festgelegt
Port: Nicht festgelegt
Nutzername: eplus
Passwort: eplus
Server: Nicht festgelegt
MMSC: Nicht festgelegt
MMS-proxy: Nicht festgelegt
MMS-port: Nicht festgelegt
MCC: 262
MNC: 03
APN-Type: default
###############
APN #2 für MMS........
###############
Name: mms
APN: mms.eplus.de
Proxy: Nicht festgelegt
Port: Nicht festgelegt
Nutzername: mms
Passwort: eplus
Server: Nicht festgelegt
MMSC: http://mms/eplus
MMS-proxy: 212.23.97.153
MMS-port: 8080
MCC: 262
MNC: 03
APN-Type: mms
Für O2/Fonic/Simply (Dank an raudi!)
###############
APN für Internet und MMS
###############
Name: internet
APN: internet.interkom.de
Proxy: Nicht festgelegt
Port: Nicht festgelegt
Nutzername: mms
Passwort: eplus
Server: Nicht festgelegt
MMSC: http://10.81.0.7:8002
MMS-proxy: 82.113.100.6
MMS-port: 8080
MCC: 262
MNC: 07
APN-Type: mms
Dienstag, 25. August 2009
GWT Compiler beschleunigen
Der GWT-Compiler erzeugt aus dem Java-Quellcode für verschiedene Browser JavaScript und zwar für jede Sprache eine eigene Datei. Die Browser mit Kennungen sind:
- ie6: IE 6 und 7
- ie8: IE 8
- gecko: Mozilla
- gecko1_8: Firefox
- safari: Safari
- opera: Opera
- Folgenden Eintrag machen:
<set-property name="user.agent" value="gecko1_8"> - Die Optionen
<extend-property name="locale" values="de">
auskommentieren.
Freitag, 24. April 2009
Das schnellste Dateisystem für USB-Sticks
Ich habe mal getestet, wie schnell die unterschiedlichen Dateisysteme auf meinem Transcent 64 GB USB-Stick sind. Hierzu habe ich den Stick jeweils mit dem entsprechenden Dateisystem formatiert und dann mein NetBeans-Projektverzeichnis mit viel Quellcode und Bibliotheken auf den Stick kopiert und mit sync sichergestellt, dass es auch geschrieben war. Danach das Verzeichnis wieder gelöscht, wieder sync und ein zweites Mal draufkopiert. Hier das Ergebnis mit Zeiten in Minuten:Sekunden:
Wie man sieht ist ReiserFS deutlich schneller als die anderen. Schade eigentlich, dass Hans Reiser jetzt im Gefängnis sitzt.
Dateisystem | Kopieren 1 | Löschen | Kopieren 2 |
---|---|---|---|
ReiserFS | 1:17 | 0:06 | 1:14 |
XFS | 2:20 | 0:27 | 2:15 |
EXT3 | 3:10 | 0:08 | 3:03 |
EXT2 | 3:13 | 0:19 | 3:26 |
Wie man sieht ist ReiserFS deutlich schneller als die anderen. Schade eigentlich, dass Hans Reiser jetzt im Gefängnis sitzt.
Dienstag, 31. März 2009
Glassfish, JDBC und DB/2
Der JDBC-Treiber von IBM für DB/2 hat es in sich: normale Verbindungen über den DriverManager funktionieren, aber der Zugriff über eine DataSource - was der Glassfish macht - bricht ab mit einer Fehlermeldung in der Art
Caused by: com.ibm.db2.jcc.a.SqlException: jcc10389122453.51.90
Beim Laden der nativen Bibliothek db2jcct2,
java.lang.UnsatisfiedLinkError: no db2jcct2 in java.library.path ist ein Fehler aufgetreten: ERRORCODE=-4472, SQLSTATE=null
Dies kommt daher, dass der Treiber standardmäßig als Typ-2-Treiber eine native Bibliothek nachladen will. Ich hab es selbst nach Kopieren von 36 MB Bibliotheken nur geschafft, dass er nicht mehr über fehlende Bibliotheken meckert, dafür aber mit einem Segmentation Fault abstürzt. Die Lösung für das Problem ist es dem Treiber zu sagen, dass er ein Typ-4-Treiber sein soll. Beim DriverManager reicht hierfür die Angabe des Ports in der URL. Bei der DataSource muss man die Methode "setType(4)" aufrufen:
DB2DataSource dB2DataSource = new com.ibm.db2.jcc.DB2DataSource();
dB2DataSource.setDriverType(4);
dB2DataSource.setServerName("192.168.1.194");
dB2DataSource.setPortNumber(50000);
dB2DataSource.setUser("XXX");
dB2DataSource.setPassword("YYY");
dB2DataSource.setDatabaseName("ZZZ");
dB2DataSource.setSysSchema("XYZ");
dB2DataSource.getConnection();
und schon klappt es. Im Glassfish ist dies folgendermaßen einzurichten: man wählt als Datenbank DB/2 aus, ändert die Datasource-Klasse in "com.ibm.db2.jcc.DB2XADataSource" und setzt als Type "javax.sql.XADataSource".
Bei den Properties muss man eine zusätzliche Property "driverType" einfügen und sie auf den Wert 4 setzen:
Hat man das gemacht, wir der Ping grün und das ganz ohne native Bibliotheken. Natürlich nicht vergessen, die Treiberdatei in das lib-Verzeichnis der Glassfish-Domain zu kopieren, damit er ihn überhaupt finden kann.
Caused by: com.ibm.db2.jcc.a.SqlException: jcc10389122453.51.90
Beim Laden der nativen Bibliothek db2jcct2,
java.lang.UnsatisfiedLinkError: no db2jcct2 in java.library.path ist ein Fehler aufgetreten: ERRORCODE=-4472, SQLSTATE=null
Dies kommt daher, dass der Treiber standardmäßig als Typ-2-Treiber eine native Bibliothek nachladen will. Ich hab es selbst nach Kopieren von 36 MB Bibliotheken nur geschafft, dass er nicht mehr über fehlende Bibliotheken meckert, dafür aber mit einem Segmentation Fault abstürzt. Die Lösung für das Problem ist es dem Treiber zu sagen, dass er ein Typ-4-Treiber sein soll. Beim DriverManager reicht hierfür die Angabe des Ports in der URL. Bei der DataSource muss man die Methode "setType(4)" aufrufen:
DB2DataSource dB2DataSource = new com.ibm.db2.jcc.DB2DataSource();
dB2DataSource.setDriverType(4);
dB2DataSource.setServerName("192.168.1.194");
dB2DataSource.setPortNumber(50000);
dB2DataSource.setUser("XXX");
dB2DataSource.setPassword("YYY");
dB2DataSource.setDatabaseName("ZZZ");
dB2DataSource.setSysSchema("XYZ");
dB2DataSource.getConnection();
und schon klappt es. Im Glassfish ist dies folgendermaßen einzurichten: man wählt als Datenbank DB/2 aus, ändert die Datasource-Klasse in "com.ibm.db2.jcc.DB2XADataSource" und setzt als Type "javax.sql.XADataSource".
Bei den Properties muss man eine zusätzliche Property "driverType" einfügen und sie auf den Wert 4 setzen:
Hat man das gemacht, wir der Ping grün und das ganz ohne native Bibliotheken. Natürlich nicht vergessen, die Treiberdatei in das lib-Verzeichnis der Glassfish-Domain zu kopieren, damit er ihn überhaupt finden kann.
Freitag, 27. Februar 2009
mod_jk und SSL-Verbindungen hängen
Das Problem
Mehrere Probleme mit einer Ursache: Verbindungen von Apache über mod_jk zu einem JBoss (genauer zu dem darin enthaltenen Tomcat) hängen und SSL Verbindungen wollen sich einfach nicht aufbauen. Das Problem tritt manchmal auf, ein Apache-Neustart oder die Option "JkOptions +DisableReuse" scheinen manchmal zu helfen.
Die Ursache
Die Ursache ist aber eine ganz andere: fehlender Zufall! Linux stellt zwei Geräte zur verfügung, die Zufall liefern: /dev/random und /dev/urandom. Diese greifen beide auf eine Kernel-interne Entropie-Quelle zu, die sich aus recht unvorhersehbaren Ereignissen im System füllt, wie Festplattenzugriffe, Netzwerkaktivität, Tastatur- und Mauseingaben usw. Der Unterschied zwischen den beiden ist, dass /dev/random sich nur auf diese Ereignisse verlässt, während /dev/urandom auch einen Pseudozufallszahlengenerator (PRNG) verwendet. In der Praxis bedeutet dies, dass /dev/random "hängen" kann, wenn zuviel Zufall abgerufen wurde, während /dev/urandom immer ein Ergebnis liefert.
Man kann sich leicht anzeigen lassen, wieviel Zufall der Kernel gerade zur Verfügung hat:
cat /proc/sys/kernel/random/entropy_avail
Mit einem
cat /dev/random
kann man den Zufall auslesen. Der Befehl hängt recht schnell und kann mit Strg-C abgebrochen werden. Eventuell ist das Terminal dann verkonfiguriert, was man durch Eingabe von "reset" wieder korrigiert. Versucht man das Gleiche mit /dev/urandom, so erhält man ständig neue Werte.
Java verwendet standardmäßig /dev/random für java.secure.SecureRandom, was wiederum für SSL-Verbindungen u.ä. verwendet wird. JBoss Seam verwendet es für seine Session-IDs. Gibt es nicht genug Zufall, dann wartet Java auf /dev/random und deshalb teilweise recht lange, bis es weiter geht.
Die Lösung
Hängt ein Prozess aktuell, so muss man für mehr Zufall sorgen, indem man beispielsweise mit einem
ls -lR /
oder
hdparm -t /dev/sda
für Festplattenaktivität sorgt. Besser ist es, den Hänger gar nicht erst auftreten zu lassen. Hierzu muss man Java lediglich anweisen, statt /dev/random einfach /dev/urandom zu verwenden. Dies geht mit einer einfachen Kommandozeilenoption für die JVM:
-Djava.security.egd=file:/dev/urandom
oder direkt im Programmcode mit
System.setProperty("java.security.egd", "file:/dev/urandom");
Der Nachteil dieses Ansatzes ist, dass sich der Zufall von /dev/urandom leichter vorhersagen lässt und damit beispielsweise ein Angriff auf SSL-Verbindungen denkbar ist. Wer hier auf der sicheren Seite bleiben will, der muss über einen Hardware-Zufallszahlengenerator nachdenken. Ein leicht zu realisierender Ansatz ist ein Mikrofon vor einem Lüfter. Die damit aufgenommenen Samples aber noch etwas nachbearbeiten, aber das ist ein ganz anderes Thema.
Mehrere Probleme mit einer Ursache: Verbindungen von Apache über mod_jk zu einem JBoss (genauer zu dem darin enthaltenen Tomcat) hängen und SSL Verbindungen wollen sich einfach nicht aufbauen. Das Problem tritt manchmal auf, ein Apache-Neustart oder die Option "JkOptions +DisableReuse" scheinen manchmal zu helfen.
Die Ursache
Die Ursache ist aber eine ganz andere: fehlender Zufall! Linux stellt zwei Geräte zur verfügung, die Zufall liefern: /dev/random und /dev/urandom. Diese greifen beide auf eine Kernel-interne Entropie-Quelle zu, die sich aus recht unvorhersehbaren Ereignissen im System füllt, wie Festplattenzugriffe, Netzwerkaktivität, Tastatur- und Mauseingaben usw. Der Unterschied zwischen den beiden ist, dass /dev/random sich nur auf diese Ereignisse verlässt, während /dev/urandom auch einen Pseudozufallszahlengenerator (PRNG) verwendet. In der Praxis bedeutet dies, dass /dev/random "hängen" kann, wenn zuviel Zufall abgerufen wurde, während /dev/urandom immer ein Ergebnis liefert.
Man kann sich leicht anzeigen lassen, wieviel Zufall der Kernel gerade zur Verfügung hat:
cat /proc/sys/kernel/random/entropy_avail
Mit einem
cat /dev/random
kann man den Zufall auslesen. Der Befehl hängt recht schnell und kann mit Strg-C abgebrochen werden. Eventuell ist das Terminal dann verkonfiguriert, was man durch Eingabe von "reset" wieder korrigiert. Versucht man das Gleiche mit /dev/urandom, so erhält man ständig neue Werte.
Java verwendet standardmäßig /dev/random für java.secure.SecureRandom, was wiederum für SSL-Verbindungen u.ä. verwendet wird. JBoss Seam verwendet es für seine Session-IDs. Gibt es nicht genug Zufall, dann wartet Java auf /dev/random und deshalb teilweise recht lange, bis es weiter geht.
Die Lösung
Hängt ein Prozess aktuell, so muss man für mehr Zufall sorgen, indem man beispielsweise mit einem
ls -lR /
oder
hdparm -t /dev/sda
für Festplattenaktivität sorgt. Besser ist es, den Hänger gar nicht erst auftreten zu lassen. Hierzu muss man Java lediglich anweisen, statt /dev/random einfach /dev/urandom zu verwenden. Dies geht mit einer einfachen Kommandozeilenoption für die JVM:
-Djava.security.egd=file:/dev/urandom
oder direkt im Programmcode mit
System.setProperty("java.security.egd", "file:/dev/urandom");
Der Nachteil dieses Ansatzes ist, dass sich der Zufall von /dev/urandom leichter vorhersagen lässt und damit beispielsweise ein Angriff auf SSL-Verbindungen denkbar ist. Wer hier auf der sicheren Seite bleiben will, der muss über einen Hardware-Zufallszahlengenerator nachdenken. Ein leicht zu realisierender Ansatz ist ein Mikrofon vor einem Lüfter. Die damit aufgenommenen Samples aber noch etwas nachbearbeiten, aber das ist ein ganz anderes Thema.
Abonnieren
Posts (Atom)