Wuala, der Speicherhunger und der Mac

Cloud-Storage-Lösungen sind sind – wie so etliche wolkige Technologien – gekommen um zu bleiben. Sie versprechen Vereinfachung in technischer, organisatorischer und kostenseitiger Hinsicht. Also greift man gerne zu.
Ob es bei Storage-Vorreitern im Consumer-Segment wie Dropbox beginnt oder bei etlichen Konkurrenten endet, ein schaler Nachgeschmack bleibt:
Und zwar die Frage, wer aller auf die outgesourcten Daten zugreifen darf. Oftmals halten auch die Anbieter selbst die erforderlichen Schlüssel, um zumindest theoretisch auf die Daten zugreifen zu können.
Sagen wir so: Nicht alle Cloud-Storage-Implementierungen schließen diesen Zugriff explizit aus.

Möchte man die Vorteile des Cloud-Storage-Konzepts nutzen (unabhängig ob im Consumer- oder im Business-Segment), bleiben nicht allzuviele Anbieter übrig.
Aber beispielsweise Wuala schließt allein schon vom Konzept her aus, dass der Anbieter, oder irgendwer sonst, dem nicht explizit vom Nutzer Zugriff gewährt wurde, die eigenen Daten einsehen könnte. Immerhin liegen die für die Entschlüsselung erforderlichen Schlüssel nur beim Nutzer. (Hoch lebe das Backup.)
Die verschlüsselten Daten werden in Blöcken redundant über unterschiedliche europäische Rechenzentren verteilt. Unabhängig davon, ob man Wuala zum Synchronisieren von Verzeichnissen über unterschiedliche Rechner hinweg verwendet oder einfach nur zum Sichern von Verzeichnissen.

Alles prächtig?

Naja, nicht so ganz. Zumindest nicht bei der Implementierung des Wuala-Clients unter Mac OS. Wenn man Wuala einfach installiert und munter drauf los laufen lässt dauert es nämlich nicht lange und der Wuala-Client entwickelt einen verblüffenden Appetit auf Hauptspeicher. 3 GB musste ich ihm bereits opfern.
Aber dann die Lösung: In den Java-Einstellungen (Dienstprogramme / Java-Einstellungen) die Reihenfolge der zu verwendenden Java-Version dahingehend ändern, dass 32-Bit-Java bevorzugt wird. Dank dem Wuala-Forum.

Und jetzt ist alles prächtig.