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.

Neue C# Bücher

In den letzten Wochen lese ich meine neuen C# Bücher.
Einmal C# 2008 - Profihandbuch und Referenz von Terry Nash aus der Franzis Professional Series und Mono - .NET goes Linux von Kaan Candar ebenfalls von Franzis Professional Series.

Das erste Buch basiert mehr auf dem Microsoft .NET Framework und geht etwas sehr auf das Laufzeitverhalten sowie die CLR ein.
Dabei kann man viel über das Verhalten von .NET Programmen erfahren.

Das zweite Buch basiert natürlich auf Mono und geht teilweise auch auf das .NET Framework ein.
Dort geht es mehr um die Mono Version von C# und den dazugehörigen Entwicklungsumgebungen.

Beide Bücher ergänzen sich sehr gut, wenn man auf beiden Plattformen arbeitet.

Sie sind auch sehr gut geschrieben und sind deshalb auch sehr gut zu lesen.
An Know-How und Fachwissen mangelt es definitv nicht.

C# 2008 ist zwar schon, wie der Titel sagt, ein Buch bis .NET 3.0 dies macht dankt der Architektur von .NET keine großen Probleme.

Insgesamt lese ich C# 2008 gerade intensiv um finde es als gutes Handbuch sehr nützlich.

Zusätzlich dazu kommt nächste Woche nach das Visual C# 2010 Buch von Galileo Computing als Gesamtpaket.
Mal schauen ob es genauso gut wie "Java ist auch eine Insel" ist.
Wenn ja habe ich eine neue C# Bibel :)

jsync reift wieder

Nachdem ich in letzter Zeit durch den Abschluss meiner Ausbildung wenig Zeit für jsync hatte, habe ich in den letzten Tagen mehr Zeit in das Projekt gesteckt.
Dabei habe ich mir einige Gedanken zum Speicherverbrauch gemacht und wie ich diesen etwas optimieren kann.

Durch einen Thread in einem Forum, in dem ich das Problem angesprochen hatte, bekam ich auch einen interessanten Anfangspunkt.

So wäre eine Möglichkeit statt rekursiv durch alle Verzeichnisse zu gehen einfach alle Pfade von Ordner rekursiv einzuladen um diese dann iterativ durchzulaufen.
Dies klingt im ersten Augenblick nach einer guten Lösung hat aber auch einen Speichernachteil.
Bei vielen Ordnern und Unterordnern kann dies viel mehr Speicher kosten als die rekursive Methode.

Da dies aber eine Lösung sein kann um den Speicherverbrauch unter bestimmten Umständen zu verringern, werde ich dafür eine Option in jsync einbauen.
Ansonsten muss ich noch schauen ob es eine Möglichkeit gibt einige Methoden zu optimieren um den Garbage Collector dazu zu bewegen nicht benötigte Objekte zu löschen.
Leider gibt es nicht viele Möglichkeiten den GC per Programmierung zu optimieren.

Hier muss das Programm java mit entsprechenden Parametern aufgerufen werden.
Ich werde am Wochenende mal ein paar Durchläufe an einigen Testdaten machen umd einen möglichst optimalen Aufruf zu finden.

Sobald ich was passendes habe werde ich die Dokumentation von jsync um einen Eintrag erweitern.

Ausbildung beendet

Nach 2 Jahren habe ich nun erfolgreich meine Ausbildung am 16.06 mit meiner Präsentation und dem Fachgespräch bestanden.
Mit 75% und somit einer 3 habe ich erfolgreich den Abschluss geschafft.

Anbei habe ich mal das Design des Blogs etwas angepasst, was man wohl seit geraumer Zeit machen kann.
Ich hoffe das neue Design gefällt.

jsync geht in die nächste Runde

Da ich mal wieder etwas Lust auf Java hatte, habe ich mal wieder an jsync gebastelt und einige kleine Idee umgesetzt.

So wurde erst einmal der Code des ConfigHelpers aufgeräumt.
Die Zeilen zum erstellen und validieren der Sektionen haben sich schon unnötig vermehrt.
Dies habe ich auf 4 Methoden runter gebrauchen die jeweils aufgerufen werden um die Werte anzulegen.

Das alte System der Sektionen sources, targets und connections habe ich ebenfalls abgeändert.
Also neue Option muss man nun einen Ordner angeben in dem .con Dateien liegen müssen.
Diese Dateien enthalten dann die sources, targets und connections Sektionen.
Somit kann man per Leserecht steuern ob bestimmte Dateien ausgelesen und entsprechend synchronisiert werden sollen.

Dies vereinfacht z.B. die Verwaltung von kritischen Pfaden.
Somit muss man nur noch entsprechend die Leserechte für spezielle Kombinationen setzen oder entfernen.
Somit entfallen ewige hin und her Änderungen an der jsync.conf

Ansonsten habe ich endlich alle Warnungen aus dem Code entfernen können.
Dabei handelt es sich um Warnungen die in den Bibliotheken von jsync befanden und schon seit Ewigkeiten vorhanden waren.

News von der Front

Heute gibt es mal wieder einen kleinen Zwischenstand.


Nachdem ich in der letzten Zeit mal etwas fernab jeglicher privater Programmierung war, habe ich mal wieder an jsync gebastelt.
Es gibt eine neue Option, verifyTransaction, die nach dem kopieren oder abgleichen einer Datei abhängig davon wie eine Datei auf Änderungen geprüft wird, vergleicht ob die Datei korrekt kopiert oder abgeglichen wird.
Bei einem Fehler wird dann lediglich ein Hinweis dazu ausgegeben.

Dies ist eine sehr brauchbare Option, da es vorkommen kann, dass eine Datei durch einen Fehler beim kopieren nicht richtig übertragen werden kann.
Wenn dies der Fall ist, ist die Datei unbrauchbar.
Somit kann man nun auf Nummer sich gehen und die Transaktion überprüfen lassen.

Leider ist diese Funktion noch nicht komplett optimiert.
Aktuell wird bei aktivem Hashing die Quelldatei nochmals gehasht.
Hier werden ich noch eine Optimierung einbauen.
Den bei aktivem Hashing ist der Hash beim gegenprüfen bereits bekannt.

Diese Optimierung spart Zeit, da große Dateien lange brauchen bis sie gehasht wurden, und schont die Festplatte.

Die Optimierung werde ich aber noch genauen planen müssen da der aktuelle Stand schon recht stabil ist und dies eine problematische Änderung ist.

Ansonsten gibt es auch noch erfreulichere Nachrichten.
Ich habe meinen Arbeitsvertrag am Freitag unterschrieben.
Sobald ich die letzte Prüfung am 16.Juni erfolgreich bestehe und mir die schriftliche Abschlussprüfung keinen Strich durch die Rechnung macht, bin ich ab dem ersten Juli offiziell bei DeDeNet angestellt.

Nach zwei ein halb Jahren bei DeDeNet wäre dies wirklich ein Traum.
Nachdem ich nun auch schon seit vier Jahren auf mein Ziel zum Fachinformatiker Fachrichtung Anwendungsentwicklung hinaus arbeite scheint mein kleines Lebensziel schon fast erreicht.

Am fünften Juni wird auch das Ergebnis der schriftlichen Prüfung bekannt sein.
Bis dahin heißt es noch warten und hoffen.

Zuletzt noch ein paar News des Tages.
Da ich heute mal viel Zeit habe und mein Zimmer wie ein Kriegsgebiet aussieht, werde ich mal die Zeit nutzen und aufräumen und die Schränke mal putzen.
Mal will ja nicht auf einer Müllkippe leben.

Ansonsten heißt es, dank Pfingsten, die Beine hoch machen und den Tag genießen.
Da das Wetter auch gut mitspielt, kann man den Tag wirklich gut nutzen.

Schriftliche Prüfungen sind durch

Heute habe ich mit meinem Kollegen die schriftliche Abschlussprüfung durchgearbeitet.
Diese war auch recht interessant und teilweise auch einfach.

Nun heißt es bis Anfang Juni warten bis es die vorläufigen Ergebnisse gibt.
Ich muss gestehen, dass die schriftliche Prüfung für mich der schwere Teil ist.
Leider ist meine Handschrift alles andere als gut Lesbar.
Und wenn man dann in 90 Minuten mehrere Seiten durcharbeiten muss, ist Chaos vorprogrammiert.

Ich kann nur hoffen, dass der Prüfungsausschuss gnädig gestimmt ist und sich die Qual an tun wird.

Ansonsten heißt es erst einmal abwarten und auf das noch anstehende Fachgespräch vorbereiten.
Dort werde ich meine Projektarbeit in 15 Minuten vorstellen, Probleme und deren Lösungen bei der Entwicklung durchgehen und zum Schluss folgen noch 15 Minuten für Fragen und Antworten.

Wenn dann alles gut geht, bekomme ich hoffentlich meinen Schein auf dem steht ob ich bestanden habe oder nicht.
Letzteres möchte ich nicht hoffen.

Mal wieder C++

Nach einer langen Zeit, 2 Jahre sind es nun schon, nicht mehr aktiv C++ entwickelt habe, habe ich Gestern mal wieder damit angefangen.

Ich wollte mal wieder direkt in die native Softwareentwicklung mit ein paar einfachen Aufgaben und mal mit Paramtern an Programmen rumprobieren.

Ich habe dafür ein kleines Programm geschreiben was Primahlen berechnet.
Diese werden dann zeilenweise in eine Datei geschreiben.
Damit das Programm nicht wieder bei 0 anfangen muss, nimmt es die zuletzt berechnete Primzahl und rechnet ab dort wieder weiter.

Ich hatte dieses kleine Programm erst mit Java entwickelt.
Leider was ich sehr unzufrieden damit, da Java für das Programm selbst 48 MB reserviert, was für ein einfaches Programm etwas zu viel ist.

Und ein Aufruf des Programms ist mit Java auch nicht besonders elegant.

Leider musste ich auch feststellen, dass ich im Bereich C++ schon sehr eingerostet war.
Alleine für einfache String Operationen und die Schreib- und Leseklassen musste ich in der C++ Referenz nachschlagen.

Nach einigen Anpassungen läuft nun alles sehr flott.
Mit den Parametern m= kann man das Limit zu berechnenden Zahlen angeben.
Der Standardwert beträgt dabei 1 Millisekunden.

Der Parameter s= gibt dann an wieviele Millisekunden das Programm anch einer berechneten Zahl, nicht Primzahl, es schlafen soll.
Der Standardwert beträgt hierfür 100.

Die aktuelle Version ist im Moment nur für Linux/Unix Systeme angepasst.
Da ich einige Systemfunktionen anspreche, muss ich noch eine Trennung für Windows/Unix Systeme einbauen.

Dank dem guten alten Präprozessor und einigen vordefinierten Makros ist dies aber weniger ein Problem.
Dies wäre auch mein erster Anlauf im per Makros für unterschiedliche Systeme zu entwickeln, was die Portierung leichter macht.

Umstellung auf dem Desktop von Debian zu Fedora

Ich habe mich dafür entschieden mich aktuell auf dem Desktop von Debian zu trennen.
Grund dafür ist, dass ich eine aktuelle Desktop Umgebung nutzen möchte.

Da ich Fedora bereits in einer VM betreibe und somit schon mit dieser Distribution auf dem Desktop Erfahrungen gesammelt habe, habe ich mich dafür entschieden.
Einen USB Installer Stick habe ich auch schon fertig.

Die Installation lief recht einfach und problemlos.
Da ich noch die Ur-Installations CD genutzt habe, waren 467 Pakete veraltet aber ein Update lief ohne Probleme durch.
Sobald Debian testing aka Squeeze stabiler ist und auch wieder Eclipse mit sich führt, werde ich dort wieder wechseln.

Solange betreibe ich erst einmal mit Fedora meinen freien Desktop :)

Windows und Batchscripts

Ich habe für die Backups meiner Windows Kiste ein kleines Sicherungsskript gebastelt.
Dies ruft per call vereinzelte Skripts auf, die dann entsprechende Verzeichnise und Dateien sichern sollten.

Leider stört es mich sehr, dass ich in der einfachen cmd von Windows nicht wie bei Linux per & einen Aufruf in den Hintergrund schicken kann.
Dies wird bestimmt den ein oder anderen Nutzer stören.
Damit man aber nicht zwangsweise größere Änderungen machen muss, kann man einen kleinen Fake bauen.

Dafür verwende ich den Befehl start und cmd.
start ruft startet ein Programm, in diesem Fall cmd.
cmd bekommt dann die Parameter /k und den Pfad zu den Batch Datei.
Somit wird cmd dazu aufgerufen per /k die Batchdatei auszuführen.

Ein Beispiel zum kopieren meiner Sicherungen sieht dann wie folgt aus.

start cmd /k "D:\crons\backup.bat"

Somit startet sich ein weiteres cmd Fenster.
Man kann hier noch einen exit einfügen, damit die Fenster wieder geschlossen werden.
Ist zwar nicht so schön wie ein & aber es reicht alle mal für den einfachen Zweck.

Neues Java Buch :)

Ich habe mal an der Buch Verschenk Aktion von tutorials.de teilgenommen und dabei ein neues Java Buch ergattert.
Darin werden die Themen rund um Java abgedeckt.
Egal ob es Programme mit einer Java UI oder Web Anwendungen sind.
Alle Themen werden darin abgedeckt.

Der Preis liegt mit 8 Euro in einem guten Rahmen.
Leider wäre eine CD von Vorteil gewesen auf der alle Beispiele darauf sind, die im Buch behandelt werden.

Hardware, Hardware und Hardware

Ich bin mal wieder am planen meiner Hardware Aufrüstung.
So werden 2 neue Festplatten und 2 neue Grafikkarten demnächst bei mir eingeplant.

Aktuell sind meine 1 TB Platten bereits gut gefüllt.
Leider mit einem größeren Teil der eigentlich nicht gesichert werden müsste.

Deshalb wird eine neue 640 GB Platte für größere Anforderungen im Netzwerk angeschafft.
Eine 500 GB Platte wird vermutlich für meinen Debian Desktop eingeplant.
Eine neue Zocker Grafikkarte von Nvidia mit DirectX 10.1 und eine Radeon Karte für meinen Debian Server wird eingeplant.

Aktuell läuft mein Server zwar rund, doch ungefährt 150 Gigabyte müssten nicht gesichert werden, was nochmals Platz schaffen würde.
Und die Grafikkarte stört durch aktive Kühlung sehr.

jsync, nio und der Speicherverbrauch

Gestern habe ich mal einen Test gemacht, der mich doch sehr überrascht hat.
So hat sich die Implementierung zum Dateien kopieren ohne nio als Speicher schonender und effizienter herausgestellt.

Grund für die Umstellung war, dass mir die Tools top und htop unter Debian Lenny immer zeigten, dass der Speicher immer im Gigabyte Bereich gefüllt ist sobald größere Dateien kopiert werden.

Legt man nun aber eine Speichergrenze von 1 MB in der jsync.conf und stellt nio ab, kommt man nur auf 1 MB Speicherverbrauch zusätzlich zu den intern gespeicherten Pfaden.
Bei einer Kopieraktion lag ich im Schnitt bei 100 MB.

Deshalb empfehle ich, auch wenn nio in Java 7 eine wichtigere Rolle spielen wird als die alten io Schnittstellen, eher auf die klassische Art zu setzen, wenn man Speicher schonen will.

Von apt-mirror zu debmirror

Ich mache gerade eine Umstellung von apt-mirror zu debmirror um den main Zweig von Debian stable und testing zu spiegeln.
Grund dafür ist, dass apt-mirror einen seit mehr als 1 Jahr unbehandelten Bug besitzt.
Ebenfalls scheint sich in Sachen apt-mirror in der Entwicklung nichts mehr zu tun.

Deshalb habe ich Gestern mal debmirror isntalliert und bin sehr zufrieden damit.
Das Programm wird nur mit Parametern aufgerufen, weshalb eine statische Konfigurationsdatei komplett entfällt.
Leider muss ich mir durch diese Umstellung das gesamte main Archiv für stable und testing erneut ziehen.

Da debmirror aber weiterentwickelt wird und wirklich mit einfachen Parametern konfiguriert wird, ist die Einstellung recht simpel.

Man benötigt für die Spiegelung wirklich nur ein Skript mit dem Aufruf von debmirror und den Parametern.

Einige gute Anleitungen gibt es hier:
http://wiki.debianforum.de/debmirror
http://www.lug-wr.de/wiki/index.php/Debmirror

jsync, GPL und der erste Release

Gestern hat sich ein Sourceforge Benutzer bei mir nach den aktuellen jsync Dateien informiert.

Leider musste ich diesem sagen, dass es aktuell noch keinen Release gab.
Ich habe mir dies aber auch zu Herzen genommen und habe mich heute um die letzten Probleme in der aktuellen Version gekümmert.

Dazu zählt eine Anpassung zum Validieren der jsync.conf, Einbau des GPL Hinweis in den Kopf einer jeden Code Datei, Anpassungen der aktuellen Dokumentation und und und.

Ich habe auch einen positiven Kommentar auf sourceforge bekommen.
Dort hat sich ein Mac User bedankt und mir mitgeteilt, dass er mit jsync seine Dokumente mit seinem PC synchronisiert.

Es ist schon sehr cool wenn man solche Kommentare lesen kann :)

Google wird zum Provider

Wie ich gerade gelesen habe, will Google in Amerika zum Internet Provider werden.
Das ganze wird erst einmal als Versuch ablaufen.
Dabei sollen Anbindungen von 1GBit/s drin sein.

Man versucht dabei 50.000 bis 500.000 Haushalte anzubinden.
Ich wäre froh wenn ich solch ein Experiment mitmachen dürft.

Ich stelle mir nur die Frage wozu man eine 1GBit/s Leitung benötigt.
Damit kann man schon Dateien in einer extremen Größenordnung verteilen und dies über einen schnellen Ablauf.

Für Torrents wäre es mal eine angenehme Geschwindigkeit.
Aber für den privaten Surfer sehe ich keinen Sinn in dieser Größenordnung.

jsync beherrscht nun symbolische Links

Ich habe bei mehren Tests in der Vergangenheit immer das Problem gehabt, dass jsync nicht mit einem Link angesprochen werden konnte.

Hierbei war das Problem, dass doe jsync.conf immer direkt neben der jsync.jar liegen muss.
Der Pfad zu dieser Datei war bisher immer relativ.
Wenn man nun aber einen symbolischen Link als Verweis nutzt, dann wird versucht in dem Verzeichnis des Links nach der jsync.conf zu suchen.

Dieses Problem lässt sich auch leider nicht wie in C# mit einer Klasse einfach lösen.
Das Problem habe ich so gelöst, dass ich mit die Url für die ConfigHelper.class aus der jar Datei habe geben lassen.

Das Format ist dann file://D:/jsync/jsync.jar!/jsync/helpers/ConfigHelper.class

Somit musste ich nur die URL um file:// kürzen und den Pfad von jsync.jar nehmen um dem absoluten Pfad zu ermitteln.

Dies ist etwas trickie aber funktioniert ohne Probleme.
Im Code liegt auch ein Fix für Entwickler vor.
Den in einer Entwicklungsumgebung hat man keine fertige .jar Datei.

Ansonsten bin ich froh, dass dieses Problem endlich gelöst ist.
Somit kann ich endlich meine ganzen Backup Skripte anpassen.
Es ist ziemlich nervig immer wieder per cd in das Verzeichnis von jsync zu wechseln.

Große Architektur Änderung bei jsync

Ich habe Gestern eine neue Architektur bei jsync eingeführt.
Diese soll lediglich die jFileLib erweitern.

So gibt es nun die Klassen File, Directory und Path.
Diese dienen um Attribute von Dateien zu prüfen.
Path dient hierbei als eine sehr gute Helferklasse zum überprüfen ob es sich um eine Datei oder ein Verzeichnis handelt.

Somit kann man dann über die File oder Directory Klassen dann spezifische abfragen machen.

Des weiteren lagere ich auch viele Teile zum kopieren von Binärdateien aus.
So gibt es wieder das File, FileReader und FileWriter Konstrukt.
Somit kann ein eigenes File Objekt mit einem Reader und Writer als Eigenschaften erzeugt werden um die Operationen beim Lesen und Schreiben von Dateien zu vereinfachen.

Ich finde es leider sehr bedauerlich, dass Java nicht wie C# statische Methoden in der File Klasse bietet.
In Java muss immer ein Objekt erzeugt werden und dann kann erst gearbeitet werden.
Dies hat sich in den ersten Versionen von jsync als sehr Speicherraubend erwiesen.

Diese Architekturumstellung spart nochmals 10 Megabyte RAM bei der Ausführung ein.
Ich werde schauen, ob ich dies nicht noch mehr optimieren kann.

Netbeans ist aus Debian testing geflogen

Ich habe mich vor einiger Zeit mal wieder über die Paketsuche von Debian über Netbeans informiert.

Leider ist es zu etwas gekommen, was ich nicht erwartet hätte.
Da Netbeans in contrib einige .jars enthält die ohne Source Code geliefert werden, ist Netbeans nun aus testing ausgeschieden.

An sich ist dies leider sehr schade, da Netbeans auch in non-free hätte verschoben werden können.
Ich finde es aber auch recht schade, dass es nicht öffentlich bekannt gegeben wurde.
Den Netbeans ist genauso wie Eclipse eine große und anerkannte Entwicklungsumgebung.

Ich werde versuchen mal mit dem Maintainer zu sprechen.
Den obwohl es bereits Netbeans 6.8 gibt, ist in allen Repositories immer noch die uralte Version 6.0.1 aus debian Etch, was eigentlich unbegreiflich ist.

Hat den keiner Lust Netbeans zu maintainen?
Dabei ist diese IDE unter Entwicklern sehr beliebt.

jsync und der Arbeitsspeicher

Ich habe in den letzten Zeiten etwas recht positives festgestellt.

Trotz der Arbeit mit Dateien im Gigabyte Bereich läuft jsync immer mit der gleichen Anzahl an MB im RAM.
Aktuell verbrauch jsync bei einer Synchronisation mit 10 Threads und somit auch mit 10 Synchronisationen gleichzeitig, mit 100-120 MB RAM.

Dies wird manche natürlich doch etwas erschrecken.
Den so manches native C oder C++ Programm bräuchte für so etwas um die 20-30 MB.
Dies liegt an der Architektur von jsync.

Aktuell verwaltet jsync jede Ebene der Verzechnisse über interne Liste.
Diese enhalten dann die Dateipfade in einem Verzeichnis.
Dies wird mit absoluten Pfaden geregelt.

Dies ist bei vielen Dateien nicht gerade wenig Speicher.
Damit der Speicher aber nicht unnötig belegt bleibt, werden die abgearbeiteten Einträge aus der internen Liste entfernt, was wieder viel Speicher frei gibt.

Ich suche aber immer noch einen Weg, damit ich unter die 100 MB Ram bei jsync komme.
Die Möglichkeit mit einer Datei war mal ein guter Anfang aber erwies sich leider als Sackgasse.

Falls jemand eine gute Idee hat, ich höre immer gerne zu :)

Flaschenhals bei jsync.

Ich habe, wie bereits geschreiben, meine gesammte Platte gelöscht und bin dabei diese neu zu befüllen.

Bei einer USB 2.0 Platte ist dies leider alles andere als schön.
Aktuell sitzt in dem Home Server eine Western Digital Caviar Green mit 1 TB Speicher.
Leider ist dort die Schreib- und Lesegeschwingkeit sehr gering.

Grund dafür ist die geringe Umdrehungszahl.
Mit 5400 Umdrehungen ist dies leider sehr lahm aber dafür auch mit geringem Energie verbrauch.

Nun wird die verbaute Platte leider so stark belastet, dass es fast schon einem alten Prozessor mit 200 Mhz gleichkommt, wenn man an dem System arbeiten will.

Ich habe deshalb werde ich wohl eine neue Platte anschaffen.
Bevor ich die 1 TB Platte drin hatte, steckte eine Western Digital Caviar Blue in dem Kasten.
Diese lief auch sehr schnell und bei einer Sicherung lief trotzdem noch alles.

Leider hat das Gehäuse des Servers, ein 5 Jahre altes Fujitsu Siemens Gehäuse, nur einen Schacht für 3,5 Zoll Platte und keinen Platz für weitere Schächte.

Somit muss ich wohl ein neues Gehäuse suchen um eine neue Platte zu verbauen.

Sobald dies alles geschehen ist, werde ich die Kiste mal umrüsten.
Dies gibt der Kiste dann mehr Geschwindigkeit und somit läuft auch jsync um einiges schneller.

jsync im Härtetest

Ich habe Gestern mal meine externe Sicherungsplatte komplett gelöscht.
Eigentlich wollte ich damit mal testen ob es schnellerer und effizienterer wären, wenn ich die wichtigen Ordner per tar als .tar.gz Archive sichere.

Insgesamt wäre dies eine nette Idee.
Dies hatte aber 2 Nachteile.

1.Die CPU ist extrem ausgelastet, da die Daten doppelte Verarbeitet werden müssen.
Einmal um die Daten zusammen zufügen und einmal um diese dann zu komprimieren.

2.Die Daten müssten später auch wieder dekomprimiert werden was ebenfalls wieder viel Rechnezeit kosten würde.

Also habe ich die Platte wieder mit jsync anfangen lassen zu füllen.

Leider scheint dies nun einige Tage zu dauern.
Den USB 2.0 ist leider nicht sonderlich schnell.
Und da die Platte nur mit 5400 Umdrehungen läuft, ist die Schreib- und Lesegeschwindigkeit nicht sonderlich hoch.

Mit ca. 35 MB/s kann es noch Ewigkeiten dauern.

Debian Spiegelserver mal aufgesetzt :)

Da ich sehr häufig Debian in allen Farben und Formen aufsetze, brauche ich langsam ein eigenes Repository.

Dies bedeutet, dass ich einfach die offiziellen Repositories spiegele.

Dies kann man dank dem Tool apt-mirrir aus den Main Repository von Debian recht einfach.

Dazu braucht man aber eine Dicke Leitung und etwas Platz.

Im Ubuntuuser.de Wiki findet man eine einfache Anleitung dafür.

Ich werde den lokalen Server heute befüllen und am Wochenende mal antesten.




Nachtrag

Ich habe den Spiegel nun aufgesetzt und bin recht zufrieden.
Es kostet zwar zum Anfang einiges an Platz und auch Zeit zum befüllen, aber danach kann man alle Programme für die jeweilige Einstellung kopieren.

Bei einem Gigabit LAN und einer ordentlichen Platte geht dies recht fix.

Ich werde darüber noch einen Eintrag im Blog schreiben.
Es lohnt sich für alle, die nicht immer wieder 20 Minuten bei einem Update warten wollen weil die Leitung wieder belastet wird.

jsync und seine kleinen Macken

Nach dem ich in letzter Zeit eigentlich dachte, dass jsync rund laufen würde, musste ich doch feststellen, dass es noch ein paar Macken gibt.
So habe ich in den letzten Tagen gemerkt, dass alte Ordner noch nicht richtig gelöscht wurden.
Dies ist nun angepasst und die aktuelle Version wandert gleich ins SVN.

Ich werde aber noch eine Erweiterung schreiben müssen.
Aktuell ist die Überprüfung auf ausreichend Speicherplatz auf einem Medium noch recht dünn.

In Zukunft wird dies aber etwas stabiler.
Dafür werde ich weitere Optionen einfügen.
Auch die jsync.conf wird sich in Zukunft noch gewaltig ändern.
So wird die options Sektion in den nächsten Zeiten in mehrere Sektionen wie hashing, threads und weiteren, aufgeteilt.

Somit soll die Übersicht in der config etwas klarer und passender werden.

Dies sind erst einmal die wichtigsten Aussichten für die Zukunft.