Debian Squeeze Released

Eigentlich ist dies schon eine Woche überfällig aber trotzdem auch die News von mir.
Debian 6.0 Codename Squeeze wurde am Sonntag dem 6. Februar endlich released.
Ich habe Squeeze bereits seit einigen Monaten ohne Probleme im Einsatz gehabt.

Squeeze enthält, wie es von Debian nun einmal bekannt ist, Software die bereits etwas älter ist aber dafür auch eine lange Testphase hatte.
Als Kernel kommt 2.6.32.5 mit USB 3.0 Support daher was ich bei Zeiten mal testen werden :)

Mein Vater nutzt seit einigen Monaten auch Debian für seine gewerbliche Arbeit als Händler und konnte sich bis auf ein paar Probleme mit dem Drucker, der zusätzliche Treiber benötigte, nicht sonderlich beschweren.

Mal schauen ob er es noch in ein paar Jahren nutzt :)

Kleine Neuigkeiten am Abend

Mal wieder ein kleiner Zwischenstand der Dinge.

Aktuell ist bei jsync fast nichts los.
Liegt etwas daran, dass ich aktuell nach den Feiertagen mal wieder etwas Freizeit nutzen möchte und nicht nur rund um die Uhr Software entwickeln will.

Neben bei mache ich noch ein paar Erfahrungen mit dem Thema RAID.
Ein kleines Raid lässt sich mit Linux und mdadm recht einfach einrichten.

Mit den richtigen Platten kann man da schon was machen.
In meinem Dekstop mit Debian Squeeze komme ich mit einem RAID 0 mit 2 Caviar Blue Platten von WD auf eine Lesegeschwindigkeit von stolzen 250 MB als Spitze.
Da spart man sich doch gerne mal das Geld für eine 150€ SSD und nimmt lieber 2-3 HDDs und bündelt daraus ein kleines RAID 0.
Dann kommt man an die Geschwidnigkeit einer guten SSD ran und hat zusätzlich noch eine größere Kapazität.
Natürlich hat man mit einem RAID 0 einige Nachteile, aber dies sollte klar sein.

Leider eigenen sich Platten von der Caviar Green Serie nicht so ganz.
Die Spitze beträgt beim lesen zwar auch schon bis zu 150 MB aber selbst beim kopieren von Daten zwischen 2 RAID 0 mit cp/jsync komme ich gerade mal auf 80-100 MB.

Fern ab von Linux habe ich aber wieder meine Nostalgie für die 90er Jahre entdeckt.
Man mag es kaum glauben aber zu dieser Zeit war ich noch ein Kind :)

Und damals war einiges besser als Heute.
Nicht wegen der Schule, die kann ich heute noch genauso wenig wie früher leiden, sondern wegen den guten alten Filmen, der Musik und den Spaß :)

Da wäre man gerne wieder in den alten Tagen.

Java bald am Ende?

Ich habe in den letzten Wochen mal die Situation rund um Java im Auge behalten.
Leider durfte ich mit der Abstimmung im JCP über Java SE 7 und 8 feststellen, was aus dem ganzen geworden ist.

Die Idee hinter dem Java Community Process ist es eigentlich Java eine offene Entwicklung zu bringen.

In JCP werden alle Java Specification Requests(JSP) überprüft und bei bestehen auch in Java übernommen.
Leider ist dieser Prozess in der letzten Zeit eher zu einem Trauerspiel geworden.

Grund dafür gibt die aktuelle Abstimmung zu Java SE 7 und 8.
Diese Versionen verschleppen sich nun schon seit mehreren Jahren und sollen nun endgültig auf den Weg gebracht werden.
An sich ist hier noch alles in Ordnung.

Nun wollte die Apache Software Foundation(ASF) von Oracle eine Lizenz für die Testsuite ihrer Java Implementierung.
Somit kann Apache die Kompatibilität zur Original Java Implementierung überprüfen.
Durch die Übernahme von Oracle wäre dies eigentlich kein Problem gewesen.
Oracle selbst war Jahre lang sogar dafür das Sun Microsystems, ehemaliger Besitzer von Java nun aber durch Oracle aufgekauft, eine Lizenz an ASF aushändigt.

Nun hat Oracle aber eben seine Position geändert und verharrt wie Sun nun eben darauf, dass ASF keine volle Lizenz bekommt.
Die Lizenz die Oracle ASF zugesteht beschränkt aber die Nutzung der Java Implementierung von ASF.
Dies ist aber eben gegen den Gedanken von Freier Software und Open Source.
Ein Grundgesetz der freien Software ist es nämlich, dass die Software uneingeschränkt genutzt werden darf.

ASF hat deshalb bei der aktuellen Sitzung zur Abstimmung der Spezifikation für Java SE 7 und 8 zusammen mit Google für ein Nein gestimmt.
Die restlichen Teilnehmer haben dies korrekterweise mit Ja aber mit einigen Kommentaren zu dem Problem gestimmt.

Oracle selbst vor der Abstimmung ebenfalls gesagt, dass man mit oder ohne Zustimmung des Komitees die Spezifikationen umsetzen wird.

Somit wird sich Java wohl in den nächsten Jahren wohl selbst ins aus Katapultieren.
Ich finde diese Entwicklung sehr traurig, da ich Java wegen seiner Verbreitung und Möglichkeiten schätze.

Leider scheint Oracle ähnlich wie bei MySQL und OpenOffice mit aller Gewalt zu versuchen diese Produkte los zu werden.
Wo keine Wartungs- und Entwicklungskosten anfallen, da kann man eben Geld sparen.

Traurig was aus den guten Produkten von Sun geworden ist.
Ich werde die ganze Geschichte noch weiter verfolgen aber auf gute Nachrichten sollte man dank Oracle nicht mehr hoffen.

Ob die Übernahme durch IBM besser gewesen wäre?

jsync Überarbeitung

Nachdem ich mit den letzten Optimierungen noch nicht ganz zu frieden bin, werde ich noch ein paar Tests und Anpassungen machen.
Aktuell verbrennt immer noch zu viel Speicher bei der Auflistung der Dateinamen.
Bei einer Synchronisation von mehren Dateien kann dies schnell zu Speicherfressern werden.

Deshalb werde ich in den nächsten Tagen mal wieder ein paar Kernprobleme angehen.
Anbei werde ich auch die Verarbeitung der Konfigurationsdateien noch überarbeiten.
Aktuell ist dies nur Case Sensitive was bei einem Tippfehler zu Defaultwerten führt.
Dies werde ich in der nächsten Version anpassen.

Erste Gehversuche mit PostgreSQL

Ich habe mir vor ein paar Tagen mal PostgreSQL in der Version 8.4 unter Debian eingerichtet.
Grund dafür war, dass ich für die Arbeit einen kleinen versuch mit .Net machen wollte.
Leider reichte eine Express Version vom Microsoft SQL Server wegen der 4 GB Limitierung pro Datenbank nicht aus.
Deshalb habe ich unter PostgreSQL einen Benutzer, eine Datenbank und entsprechende Tabellen angelegt.

Insgesamt konnte ich auch endlich mal live erleben um welchen Faktor man einige Select Abfragen mit einem guten Index beschleunigen kann.
Leider war hier der Knackpunkt.

Unsere Datenbank für ein Projekt benötigte zwar einen einfachen Index auf zwei Spalten, dieser konnte aber wegen einer hohen Verfügbarkeit nicht erstellt werden.

Nun planen wir aber diese Daten auszulesen um diese im Dateisystem abzubilden.
Dafür habe ich auch die Datenbank verwenden können um somit ein gutes Programm mit Mono, und somit auch in .Net, implementieren zu können.

Insgesamt habe ich aus dem ehemaligen Speicherfresser ein kleines Programm mit ThreadPool für Parallele Anfragen gebastelt.
Dies belastet zwar die Datenbank bewirkt aber keine totale Blockierung wie zuvor.

Erste Gehversuche mit Mono

Ich mache gerade einige Gehversuche mit Mono.
Insgesamt ist der Umstieg von Microsofts .Net Framework zu Mono keine große Hürde.
Mono enthält alle wichtigen Basisklassen des .Net Frameworks.

Mit Monodevelop kann man auch sehr gut Software entwickeln.
Ein Intellisense wie bei Visual Studio gibt es ebenfalls.
Eine Verbindung mit allen gängigen Datenbanken, auch zu Microsoft's SQL Server, ist möglich.

Macht eine Menge Spaß unter Linux auch .Net Entwickeln zu können.
Im Gegensatz zu Java habe ich als Entwickler auch eine Klasse GC mit der man den Garbage Collector etwas steuern kann, wenn man es den muss.

Der Speicherverbrauch ist nur ein Bruchteil von Java was auch nochmal ein großer Pluspunkt ist.
Auch lange Optimierungsoptionen an den Befehl "mono", Gegenstück zu "java", kann man sich auch sparen da dort alles rund läuft.
Somit entfallen lange Optimierungen über die VM Parameter.

Insgesamt ist mono für mich das bessere Java.

jsync wird schneller

Nachdem ich mit dem Speicherverbrauch und der Geschwindigkeit von jsync nicht sehr zufrieden bin, bastle ich in letzter Zeit mal wieder am Fundament.
Akutell habe ich durch eine Umstellung der Verarbeitung von String auf StringBuilder schon den Speicherverbrauch und die Geschwindigkeit verbessert.

Aktuell ist aber noch ein Manko beim Thema Threadsicherheit.
Dort werden ich auch noch basteln damit es zu keinen Kollisionen kommt.

jsync beherrscht nun Excludes

Nachdem es seit einigen Wochen eine Sicherung mit jsync mache habe ich immer wieder folgende Situation.
Ich sichere mein Benutzerverzeichnis mit allen Dateien und Ordnern.

Dabei werden aber immer große Ordner für Musik, Videos und Downloads gesichert.
Diese habe ich sonst per Skript nach der Sicherung löschen lassen.
Da dies aber immer wieder zu langen Wartezeiten führte, habe ich mich entschlossen Excludes einzubauen.
Diese können in den jeweiligen Verbindungsdatei unter der Sektion excludes eingefügt werden.
Die Ordner oder Dateien werden dann beim synchronisieren ausgelassen.

Lebenszeichen

Seit längerem ist es etwas still um mich, den Blog und jsync geworden.
Dies liegt daran, dass ich aktuell eher wenig Zeit für Java und co. verwende.
Aktuell nutze ich mal die Zeit um nach der Arbeit etwas zu entspannen, Musik hören, Filme schauen und mal etwas von allem abzuschalten.

Ich werde die Zeit auch mal wieder nutzen um Abends wieder etwas unterwegs zu sein.
Die nächsten Tage wird dann auch mal wieder eine Runde um den Block gedreht.

Neue Ideen für jsync gesucht

Seit einigen Wochen geht es bei jsync nicht mehr wirklich weiter.
Grund dafür ist einfach, dass ich nicht weiß wie man jsync noch erweitern könnte damit der Nutzen für den Anwender verbessert werden kann.
Ein paar Sachen wären natürlich schon möglich aber nicht umbedingt nützlich.

So könnte ich jsync um eine Optimierung der maximalen Threads erweitern.
Pro CPU Kern würde dann ein Thread arbeiten, was optimal für eine schnelle Ausführung wäre.
Auch eine automatische Buffer Vorgabe wäre bestimmt anhand des vorhandenen Speichers erstellbar.

Trotzdem wären dies eher kleine Erweiterungen die nicht umbedigt von großem Nutzen wären.
Ansonsten bin ich für Ideen offen.