JDBC 4.0
Welche neuen Features es in JDBC 4.0 gibt, listet dieser Artikel kurz auf.
Posted at 01:00vorm. Juli 23, 2005 by cetixx in News | Kommentare [0]
Today's Links
Grafische 2D Applikationen mit Java und SVG
Eine kleine Einführung in das serverseitige erzeugen von SVG-Dateien.
JXCSS
Ein CSS2-Parseradapter geschrieben in Java zum Umschreiben bestehender Stylesheets oder zum Erzeugen Neuer.
GUI-Commands
Ein Kommando-Framework für Swing-GUI's
xmlenc
xmlenc ist eine schnelle Stream basierende XML-Output-Library. Damit
kann man sehr schnell ein XML-Dokment in Java zusammenbasteln.
Posted at 12:33vorm. Juli 23, 2005 by cetixx in Links | Kommentare [0]
LINUX: I/O Scheduler ändern
Unter Linux mit Kernel 2.6 hat man eine relativ elegante Möglichkeit,
soz. online den I/O Scheduler zu verändern. Vorallem bei USB- und
Firewire-Festplatten sollte man durchaus mal den CFQ-Scheduler
probieren:
echo "cfq" > /sys/block/<FESTPLATTE>/queue/scheduler
Wenn also die erste Firewire-Platte unter /dev/sda reingehängt wird, schreibt man also bei obigen Befehl bei <FESTPLATTE> sda einsetzen. Wenn es interessiert, mit welchen Scheduler gerade seine Platten laufen, kann sich folgendes Skript downloaden: show_io_scheduler.sh.
Es zeigt alle Platten im System an und welchen Scheduler jede einzelne
Platte verwendet. Das Skript wurde mal auf der Firewire-Mailingliste
gepostet.
Posted at 11:59nachm. Juli 22, 2005 by cetixx in Tipps | Kommentare [0]
Linux, Firewire, SATA oder warum ich mit Linux manchmal die Krise bekomme
Nun... Es war einmal ein Rechner, da war ein Firewire-Controller Adaptec FireConnect 8300 eingebaut. Dieser läuft auch recht gut. An diesen hingen 3 x 1 TByte LaCie Bigger Disk Extreme und 2 x 1,6 TByte LaCie Bigger Disk Extreme Platten. Mal davon abgesehen, das diese Platten recht anfällig für Ausfälle sind (man kann dazu auch gerne mal in der Linux Firewire Mailingliste
mehr nachlesen), hatte ich mit den 1,6 TB Platten immer nur Probleme unter Linux (egal mit welcher Kernelversion).
Ein Problem äußerte sich z.B. darin, das man für ein paar Sekunden
Daten ganz normal auf die Platte geschrieben wurden, aber dann
plötzlich die Platte "mit sich selbst" beschäftigt war. Das konnte man
mit iostat sehen. Dort lag die Auslastung (%util) plötzlich bei 100% und bei top
unter wa
sah man ebenfalls 100%. Nach ein paar weiteren Sekunden schrieb die
Platte dann wieder und das Ganze ging dann wieder von Vorne los. Es kam
dann mal der Vorschlag auf, für diese Platte den cfq-I/O-Scheduler
einzustellen (echo "cfq" >
/sys/block/<FESTPLATTENNAME>/queue/scheduler). Das bringt
tatsächlich etwas Speed, löst das Problem aber
nicht. Seltsamerweise hatte und habe ich mit
den 1 TByte LaCie Platten in dieser Hinsicht keine Probleme. Da nun
Firewire-Support unter Linux unter Kernel 2.6.12 das erstemal als
stable deklariert wurde, hab ich gleich Ubuntu 5.10 installiert, das
diesen Kernel schon mitbringt. Die 1,6 TB Platten liefen aber immer
noch nicht vernünftig. Nun, da
diese LaCie-Platten intern immer im Raid 0-Verbund arbeiten (die Bigger
Disk Extreme Platten haben intern 4 Festplatten) und diese
Platten im Dauerbetrieb nicht unbedingt gut aussehen (heißt oft kaputt gehen), mußte eine andere
Lösung her.
Also geguggt und gefunden: Ein 3ware 9500S-4LP SATA-Controller und ein Stardom-RAID-Tower
sollte es sein. 3ware deshalb, weil der Linuxsupport wirklich
vorbildlich ist. In den RAID-Tower 5 x 400 GB Seagate Platten rein und
ein RAID 5 konfiguriert. Damit war dann schon mal das RAID 0 Problem
der LaCie's gelöst und der Ausfall einer Platte kann dann schon mal
nicht mehr alle Daten vernichten. Der RAID-Tower hat das nette Feature
nicht nur Firewire 800 und USB 2.0 sondern auch einen SATA-Anschluß zu
haben (es gibt auch einen mit SCSI). Das war dann auch das Kaufargument, da ich eigentlich von
Firewire weg wollte. Große Platten, Firewire und Linux scheint momentan noch nicht der letzte Brüller zu sein - auch wenn die
Firewire-Mailingliste sehr hilfreich ist und gerne weiterhilft. Gesagt
getan: SATA-Controller rein, Tower per SATA angeschlossen... Und der
Controller erkennt natürlich den Tower nicht. Aha. Toll. Alle
SATA-Ports durchprobiert, Controller in verschiedene Slots gesteckt,
div. Konfigurationen probiert.... War nix zu machen. Der Controller
tauchte in der Plattenliste nicht auf. Also 3ware-Support angerufen.
Dort teilte mir dann auch gleich mit, das man solche RAID-Tower gar
nicht unterstütze und man gefälligst einzelne Platten anschließen
solle. Ich wollte dann den technischen Hintergrund wissen, wieso das
nicht funktionieren sollte, denn für den Controller stellt sich das
RAID nach aussen ja nur als eine Platte dar und SATA unterstützt ja
immerhin 48bit-Adressierung, so das die 1,6 TByte netto ja eigentlich
kein Problem machen sollten. Funktioniert nicht, wird nicht supportet. Ende der Durchsage... Aha. Toll. Also bei Raidsonic
angerufen. Dem Support-Techniker erzählte ich dann gleich von meinem
Telefongespräch von eben mit 3ware. Der mußte dann gleich schmunzeln
und verwieß mich auf's Handbuch Kapitel 4. Dort steht nämlich, das man
den IDE-Kanal wechseln muß, denn Kanal 0 wird von Firewire genutzt und
Kanal 1 von SATA. Und Default ist Firewire. Drum erkennt der
SATA-Controller den Tower nicht. Blöderweise befindet sich aber Kapitel
4 nicht in der gedruckten Anleitung (die ich gelesen habe) sondern auf
der mitgelieferten CD als PDF. Also: Gesagt und eingestellt und siehe
da: Der Tower erscheint als 1,6 TByte Platte in der Festplattenliste
des Controllers. :-) Feini fein...
Also Ubuntu Linux Version 5.10 gebootet, Treiber für den 3ware-Controller lädt ohne Probleme und mit fdisk -l
sehe ich dann auch gleich die Platte und richte die Partition ein, XFS
Filesystem installieren, mounten und is gut. :-) Aber wir sind ja noch
nicht fertig. Ich möchte erstmal sehen, wie das Ganze performend. Also
ein ganz einfacher Test mit dd:
dd bs=1024 if=/dev/zero of=/sataplatte
Ungefähr 5 MByte/sec Write-Speed. Nicht berauschend. Und das trotz (scheinbar)
aktivierten Write-Back-Cache des Controllers? Also wieder an Firewire
800 ran und Test wiederholt. Ergebnis: Ungefähr 27 MByte/sec
Write-Speed. Aha. Toll. Jetzt blick ich gar nicht mehr durch. Na dann
bleib ich erstmal bei Firewire. Vielleicht finde ich in diesem
Jahrtausend noch raus, woran die schlechte Performance der
SATA-Kompontenten liegt.
Update:
Tja... Also an SATA scheint nicht das eigentliche Problem zu sein. Denn
in der Praxis hat sich jetzt gezeigt, das bei Firewire der Durchsatz
genauso schlecht ist wie bei SATA. Ich muß wohl weitersuchen...
Update:
Aha... Wenn man den richtigen Schalter findet, läuft die Sache gleich
viel besser ;-) Da ich bei dem Controller die RAID-Funktionalität nicht
nutze, kann ich im BIOS des Controllers nur JBOD einstellen. Das
aktiviert allerdings den Write-Back-Cache nicht. Das macht die Sache
relativ langsam. Mit aktivieren Write-Back geht's schon erheblich
flotter. Trotzdem hätte ich mir selbst ohne Write-Back mehr Performance
erwartet. Der Write-Back-Cache ist halt immer so eine Sache bei
Stromausfall oder so was in der Gegend...
Posted at 11:16nachm. Juli 21, 2005 by cetixx in Computers | Kommentare [0]
ORACLE: ORA-01033: ORACLE initialization or shutdown in progress
Wenn man diesen Fehler bekommt beim einloggen (z.B. bei sqlplus username), sollte man einen Blick ins Oracle alert.log
werfen. Zum Einen kann es sein, das die Datenbank tatsächlich gerade
runter- oder rauffährt, zum Anderen kann die Ursache aber auch eine
Andere sein, die sich einen nicht gleich erschließt. Der Blick ins alert.log sollte aber weiterhelfen.
Posted at 10:07nachm. Juli 21, 2005 by cetixx in Tipps | Kommentare [0]
GNU Classpath 0.17 released
Kurz nach V 0.16 gibt es nun eine neue Release. Hauptsächlich wurden Bugfixes gemacht, die kurz nach dem Erscheinen von Eclipse 3.1 aufgetaucht sind.
Posted at 11:37nachm. Juli 20, 2005 by cetixx in News | Kommentare [0]
Today's Links
MSDN Magazine
Die neueste Ausgabe sowie ein Archiv aller Ausgaben des Microsoft Developer Network Magazine gibt es auf dieser Seite.
Practically Groovy
Andrew Glover gibt einen Einblick in die letzten Änderungen der Groovy
Syntax und warum jetzt die Zeit ist, sich Groovy näher anzuschauen.
Sleep
Eine weitere Java Scripting Sprache: Angelehnt an Perl und ein bißchen Objective-C.
Posted at 11:22nachm. Juli 20, 2005 by cetixx in Links | Kommentare [0]
Neue Versionen von Firefox und Thunderbird
Von beiden Programmen gibt es jetzt Version 1.0.6 die vorallem die "API-Stabilität" wieder herstellt. Durch geänderte API's in 1.0.5 gab es Probleme mit div. Erweiterungen.
Posted at 11:17nachm. Juli 20, 2005 by cetixx in News | Kommentare [0]
Google Moon
In Andenken an die erste Mondlandung gibt es bei Google Moon in Anlehung an Google Earth jetzt eine zoombare Mondkarte mit den Landestationen von Apollo 11 bis 17.
Posted at 11:09nachm. Juli 20, 2005 by cetixx in News | Kommentare [0]
Volltextsuche bei Amazon
Amazon bietet jetzt auch in Deutschland die Möglichkeit der Volltextsuche in momentan über 100.000 Büchern.
Posted at 10:58nachm. Juli 20, 2005 by cetixx in News | Kommentare [0]
PostgreSQL: Wie kann man psql das Loginpasswort übergeben?
Wenn in der pg_hba.conf von PostgreSQL bei einem User als
Authentifizierungsmethode md5 oder sowas eingestellt ist und man sich
per psql connecten möchte, frägt dieses nach dem Passwort. In Skripten
oder Cronjobs ist das natürlich blöd. Man kann in diesem Fall einfach
die Umgebungsvariable PGPASSWORD=<MYPASSWORD> setzen. Dann entfällt die Abfrage. Man sollte das Skript dann aber auch nicht für alle Welt lesbar machen...
Posted at 10:34nachm. Juli 19, 2005 by cetixx in Tipps | Kommentare [0]
Squid: Wie startet man Squid mit einem leeren Cache?
Erstmal den Squid beenden. Dann wechselt man in das/die Cache-Verzeichnis(se) des Squids. Dort finde man eine Datei namens swap.state. Diese muß man exakt mit einem Byte überschreiben. Das geht am Besten so:
echo "" > swap.state
Das macht man für jedes Cache-Dir. Aufpassen, das sich die Rechte nicht
ändern! Squid starten und der Squid holt sich wieder alle Objekte neu.
Posted at 09:49nachm. Juli 19, 2005 by cetixx in Tipps | Kommentare [0]
SSH: SSH-Daemon Sicherheit erhoehen
Man hört ja immer wieder von Brute Force Attacken auf den SSH-Dienst.
Um diesen Attacken besser wiederstehen zu können, gibt es ein paar
relativ einfache Tipps:
*) Wenn möglich, Zugriff nur für bestimmte IP's zulasssen. Hat man
keine Firewall ist ein Schutz über den TCP-Wrapper (/etc/hosts.allow,
/etc/hosts.deny) auch schon nicht schlecht. Man kann dann z.B. in
diesem Fall den TCP-Wrapper für den sshd auch per signierter Mail soz.
von außen freischalten.
*) Man sollte nur den unbedingt nötigen Usern SSH-Zugriff erlauben. Dazu kann man bei OpenSSH z.B. die Option AllowUsers verwenden.
*) root Remote-Login's sollte man nicht erlauben.
*) Zu guter Letzt sollte man den Zugriff ausschließlich per Public-Key erlauben und die Passwortauthentifizierung abschalten.
Posted at 05:03vorm. Juli 19, 2005 by cetixx in Tipps | Kommentare [0]
Cacao JVM
Von der GPL-lizenzierten JVM Cacao gibt es eine neue Version. Hier wird GNU Classpath als Klassenbibliothek verwendet.
Posted at 04:09vorm. Juli 19, 2005 by cetixx in News | Kommentare [0]
Sun's neue Sparc Chips
Wer sich dafür interessiert, wie es bei Sun mit den Sparc-Chips weitergeht, findet hier einen sehr interessanten Artikel.
Posted at 03:57vorm. Juli 19, 2005 by cetixx in Computers | Kommentare [0]