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.