Am Rande notiert ...

git-annex. Definitiv wert für zwei oder drei Blicke. Im Prinzip ist das sowas wie ein manuell betriebenes Dropbox – man kann Ordner mit anderen Ordnern verknüpfen und Sync-Beziehungen definieren. Aber man kann auch zum Beispiel Redundanzen definieren, wodurch sichergestellt ist, dass von Files genügend Kopien vorliegen – löscht man eine Datei, gibts was auf die Finger wenn es die letzte Kopie war (und sie wird wiederhergestellt). Viele Kommandos zur effizienten Verwaltung verschiedenster Szenarien kommen dazu und es gibt verschiedenste Backends für die Daten – z.B. kann man Amazon S3 integrieren und mit geeigneten Mitteln als Backup-Repository einbinden, oder URLs aus dem Web referenzieren und darüber Dateien jederzeit wieder rekonstruierbar machen (damit kann man z.B. auch einen eigenen Fileserver mit http Oberfläche integrieren). Oder sogar sowas wie Google Mail als Backend benutzen und seine Daten in Dateianhängen. Oder alle Mittel von git benutzen um z.B. temporäre Ergebnisse von Synchronisierungen auszuschließen. Im Gegensatz zu Sparkleshare – welches ja auch auf git aufbaut – werden hier aber nur die Metadaten in git versioniert, nicht die Dateien selber. Das hat natürlich den Nachteil, dass Dateiänderungen darüber nicht zurückgedreht werden können – dazu bräuchte man ein versionierendes Backend wie z.B. bup, welches dann als Datensicherung mit Versionierung und Definition der Backup-Zyklen benutzt wird. Der Vorteil der git-annex Methode ist aber, dass die Daten nicht so gigantisch wachsen wie bei Sparkleshare wenn man z.B. große Dateien wie Videos oder Digitalbilder syncen will – nur an der definierten Backup-Schnittstelle würdenm die Versionen anfallen und man kann explizit bestimmen welche Daten da hin gehen. Nix für Mäuseschubser, aber klasse für Kommandozeilenfetischisten.

SparkleShare – Sharing work made easy. Mal geblogmarkt, denn das sieht erstmal recht vielversprechend aus – als Server kommt einfach ein Git zum Einsatz. Leider scheinbar grundsätzlich nur ssh basiertes Git, nicht https, zumindestens sehe ich in den Docs nichts dazu – https wäre universeller (auch wenn dann natürlich Passwörter abgelegt werden müssen). Was noch fehlt ist ein iOS oder Android Client (Android soll wohl in der Mache sein), aber OSX wird schon unterstützt. Sieht so aus als ob hier die größte Aktivität in den Open-Source-Alternativen zu Dropbox stattfindet – allerdings frage ich mich noch, wie sich der Server bei massivem Dateizufügen und Löschen verhält – ich hab ja z.B. die aktuellen Raw-Fotos der letzten Monate in meiner Dropbox. Ein „rohes“ Git Repository wächst da ganz schnell ins unermessliche … (und man muß wohl auch regelmäßige Packs machen, damit z.B. Änderungen an DNG Files das Repository nicht explodieren lassen). Ein kleines Detail am Rande ist noch wichtig: SparkleShare benutzt einen öffentlichen IRC Server für die Synchronisationsmeldungen – also auch bei selbsthosting hängen alle Clients auf diesem Server und tauschen darüber ihre Trigger aus. Sollte man im Hinterkopf behalten, denn sowas wäre ein klassischer Angriffsvektor (und wenn der IRC Server ausfällt, hängt auch das selbstgehostete System). SparkleShare ist aber Open Source, also kann man sicherlich auch da einen eigenen IRC Server einklinken und einfach eigene Pakete nutzen.