ownCloud: Open-Source, Ja – Open-Speech, Nein!

11 Kommentare Autor: Jürgen (jdo)

Update: Mein Kommentar wurde nun doch noch freigegeben, mit dem Hinweis, dass Sync-Client 1.2.4 ausgegeben wurde – der das Problem auch nicht löst.

Nach meiner letzten Meckerei, dass man sich im ownCloud-Lager doch bitte erst als Dropbox-Problemlöser aufspielen möchte, wenn man einen vernünftigen Sync-Client zur Verfügung stellt, kamen mindestens zwei weitere dieser “Wir lösen das Dropbox-Problem”-Beiträge.

Einer davon ist hier. Nun hab ich mir einfach mal erlaubt, direkt zu meckern und meinen Unmut in Form eines ganz gewöhnlichen Kommentars abzugeben. Aber die Firma hinter dem Open-Source-Projekt ownCloud lässt wohl nur Kommentare zu, die nicht negativ sind.

Also fast 24 Stunden nach meinem Beitrag, wartet dieser immer noch auf Moderation. Ausgesiebt wurde aber in der Zwischenzeit, denn der freigegebene Kommentar inklusive Antwort war heute morgen noch nicht da.

Kann natürlich sein, dass ich im Spam-Ordner gelandet bin, wobei ich weder einen Link noch “Viagra” im Text verwendet habe. Kann aber auch sein, dass man bei dem Open-Source-Projekt zensiert und offene Sprache unerwünscht ist. Ich kann beides nicht ausschließen. Sollte letzteres der Fall sein: DER SYNC-CLIENT FUNKTIONIERT TROTZDEM NICHT – UNABHÄNGIG VON EINER FREIGABE MEINES KOMMENTARS! UND DIE ERDE DREHT SICH DOCH UM DIE SONNE!

ownCloud: Kritik unerwünscht!

ownCloud: Kritik unerwünscht!




 Alle Kommentare als Feed abonnieren

11 Kommentare zu “ownCloud: Open-Source, Ja – Open-Speech, Nein!”

  1. Stefan Lohmaier says:

    Die _conflicht-Dateien sind des eine. Ich hatte auch korrupte Files. Inakzeptabel. Probier doch Seafile. Damit hab ich gar keine Probleme.

  2. rr says:

    Dafür finde ich es nett, dass Du hier auch das Gemecker freischaltest *mähhh* 🙂 ne, is ne Unart und kommt ja häufiger mal vor, dass so ein Gebahren im Social-Web für unmut sorgt. Die nehmen das bestimmt noch mit in ihre Mediations-Runden und beraten drüber, wie sie darauf reagieren sollen, bevor sie das freischalten.

    • jdo says:

      Solange es kein SPam ist, keie rassistischen oder beleiidigenden Inhalte und so weiter sind (wenn es sich im Rahmen hält), sehe ich keinen Grund für Zensur ...

  3. std says:

    Naja, nach 24 Stunden "Zensur!" zu schreien finde ich ziemlich übertrieben bei einem moderierten Kommentarsystem. Vielleicht ist Kommentare freischalten bei denen nicht so die Top-Priorität.
    Wenn es weitere 48 Stunden dauert, kann ich dich aber verstehen.

    • jdo says:

      Ich habe ein versehentliches Landen im Spam-Ordner nicht ausgeschlossen. Aber es wurde ein Kommentar bereits moderiert - sonst hätte ich länger gewartet.

    • jdo says:

      btw. nun sind es fast 48 Stunden und mein Kommentar ist immer noch nicht freigeschalten ...

  4. Wir nehmen Kritik generell ernst und versuchen mit einer Lösung darauf zu antworten. In diesem Fall ist es, zunächst, der 1.2.4. Desktop Client den wir am Freitag freigegeben haben. Respektive habe ich jetzt Ihren Kommentar mit einem Kommentar versehen und freigegeben.
    Ich kann versichern das unsere Kunden in der praktischen Anwendung weit weniger Konflikt-Dateien haben, als das bei Ihnen der Eindruck ist.
    Worüber wir uns sehr freuen würden sind detaillierte, reproduzierbare Bug Reports aus der praktischen Anwendung (touch gehört nicht unbedingt dazum IMHO 😉

    Marketing und Technik gehen Hand in Hand. Das Dropbox Problem ist ja ein Problem von IT Abteilungen, nicht von End Usern, für die funktioniert Dropbox für nicht private Daten ja wunderbar.

    Danke für die Kritik auf alle Fälle!

    • jdo says:

      Hallo,

      Das ist nicht nur mein Eindruck, sondern wurde mir auch von anderen Anwendern bestätigt (auch von beschädigten Dateien war die Rede!). Weiterhin ist es nicht auf ein Betriebssystem genagelt, sondern ich bin erst draufgekommen, als meine Freundin von vielen Konflikt-Dateien auf Ihrem Mac gesprochen hat. Danach habe ich angefangen, zu untersuchen. Der Client stürzte auf dem Mac immer wieder ab und so habe ich die Reproduktion angefangen.

      touch gehört wohl dazu, weil es nicht sein kann, dass eine Änderung des Zeitstempels so ein Chaos verbreitet, wenn die md5-Summen gleich sind. Ich bin mir nicht 100% sicher, aber anscheinend mauschelt da das Apple-Betriebssystem mehr mit den Zeitstempeln, wenn die nach einem Absturz wieder vom ownCloud-Client angefasst werden. 110.000 _conflict-Dateien mit 50.000+, die auf den Mac zurück synchronisiert wurden hört sich auch in der praktischen Anwendung nach einem echten Problem an. Auf dem Mac haben wir nichts mit touch unternommen, da ist einfach der Client gelaufen und immer wieder abgeraucht. Somit lässt sich dass Problem mit touch wunderbar testen und man könnte aufgrund dessen einen Mechanismus implementieren: statt eine Konflikt-Datei zu erzeugen, die ich sehr schlecht wieder aus dem System bekomme, in diesem Fall die md5-Summen vergleichen und unterscheiden sich diese nicht, wird die Datei auf dem Server überschrieben, weil es ganz offenbar die selbe Datei ist.

      Das Problem mit Dropbox haben auch Endanwender, weil diese auch die Daten auf einen Fremdserver in die USA legen. Es ist meines Erachtens irrelevant "IT-Abteilungen zu meinen", aber das Problem als "Allgemein" darzustellen - wobei ich Ihnen ja generell sogar Recht gebe, dass es für alle Anwender ein Dropbox-Problem gibt, für das ownCloud tatsächlich eine sehr befriedigende Lösung wäre - wenn die Synchronisation funktionierte ...