staging.inyokaproject.org

Hallo,

klingt IMHO plausibel. Sollen wir dir den Artikel in die Baustelle schieben?

Gruß, noisefloor

Ich hab nie den Sinn der Baustelle verstanden, denn für mich entwickeln sich Wikis kontinuierlich weiter. Ich hab mir Mal erlaubt das jetzt einfach so reinzuschreiben.

Bitte Mal überlesen und die sicherlich noch vorhandenen Grammatik- und Rechtschreibfehler entfernen.

Ggfs. kann man den Anfang des Artikels noch kürzen. „Aktenkoffer“ gab es mal in Windows 98. Heute sind USB-Sticks so schnell, dass sich das Runterkopieren nicht lohnt. Ich denke man könnte einfach knapp die Funktionalität zwei Dateistrukturen zu synchronisieren, erklären und dann direkt in meinen 6-Schritte-Plan überleiten.

Ich weiß ja nicht, wie es bei euch ist, aber ich nutze Unison ausschließlich um zwischen Rechnern zu synchronisieren, nicht innerhalb eines Rechners.

Diese Skripte Zenity und Sucsynct sind mir etwas suspekt. Von mir aus kann das auch raus, wollte es aber nicht einfach entfernen, aber vllt. ist nicht jeder so ein Kommandozeilenliebhaber wie ich.

Grüße MPW

/edit: Kann man die Aufzählung noch schöner formatieren? Mir ist nichts schöneres eingefallen.

Und, kann man die Optionen auto/batch/logfile etc. noch etwas einrücken? Hab es mit Leerzeichen versucht, die werden aber verschluckt.

Hallo,

Danke für die Ergänzung. Habe ein paar Kleinigkeiten korrigiert.

MPW schrieb:

Ich hab nie den Sinn der Baustelle verstanden, denn für mich entwickeln sich Wikis kontinuierlich weiter. Ich hab mir Mal erlaubt das jetzt einfach so reinzuschreiben.

Und genau _darum_ gibt's die Baustelle. Damit a) die Wikiartikel inhaltlich immmer in sich konsistent und richtig sind und b) mein Ergänzungen (aka Weiterentwicklungen) etc. machen kann, ohne unter Zeitdruck zu stehen und "one shot" alles richtig machen zu müssen. ☺

Gruß, noisefloor

Danke für's Kontrolle lesen. Über die Baustelle diskutieren wir mal ein anderes Mal, ihr habt da mehr Erfahrung 😀.

Würdest du noch die Einleitung kürzen oder diese Skripte entfernen, oder wollen wir es einfach erstmal so belassen?

Hallo,

MPW schrieb:

Würdest du noch die Einleitung kürzen

Meinst du die Einleitung des Artikels an sich? Die ist doch kurz...

oder diese Skripte entfernen,

Nee, weil: solange diese korrekt sind, kein Sicherheitsrisiko darstellen etc. gibt es keinen Grund, diese zu entfernen.

Gruß, noisefloor

Gut, dann lassen wir das so. Und das nächste Mal halte ich mich auch an die Baustellenpolitik 😀.

Klingt für mich als unison-User ganz gut. Punkt 5 würde ich aber rauslassen.

Die Automation ist kein Element mit direktem Bezug zu Unison. Sonst könnte man ja zu jedem Anwendungs-Artikel auch einen Automationsabschnitt schreiben. Wer etwas automatisiert, sollte immer auf Mehrfachaufrufe a.G. zu lange Laufzeiten des vorherigen Aufrufs checken. Das versteht sich von selbst.

Das besagte Feauter, was du in Punkt 5 beschreibst wird auch gerade unter den Devs diskutiert, ob und wie das in Unison zu integrieren ist.

Dem stimme ich nicht zu. Es ist gerade wichtig auf die Eigenheiten bzgl. Automatisierung und Unison hinzuweisen. Es nutzt einem hier nichts, wenn man weiß, wie Cron funktioniert, aber nicht weiß, dass Unison nicht merkt, dass es in zweiter Instanz aufgerufen wurde.

MPW schrieb:

Dem stimme ich nicht zu. Es ist gerade wichtig auf die Eigenheiten bzgl. Automatisierung und Unison hinzuweisen. Es nutzt einem hier nichts, wenn man weiß, wie Cron funktioniert, aber nicht weiß, dass Unison nicht merkt, dass es in zweiter Instanz aufgerufen wurde.

Ich kann deine Perspektive schon nachvollziehen. Aber 1. ist das eben gerade keine "Eigenheit" von Unison, da die Automatisierung kein Feauter von Unsion ist. Und 2. checken die meisten Anwendungen nicht, ob sie ne zweite Instanz laufen haben. Ist auch meist unnötig. Es gibt durchaus Gründe, mehrere Instanzen laufen zu haben.

Grundsätzlich würde ich es begrüßen, wenn Unison mehr Support für Automatisierungsmechanismen mitbringen würde. Aber solange das dort nicht drin ist, hat es IMO im Wiki-Artikel nix zu suchen. Hinweise auf Sekundärquellen, die solche Spezialszenarios in Form von Tutorials bspw. erklären fände ich aber ok.

Hier im Wiki werden IMO zu viele Spezialszenarios für die einzelnen Anwendungen (oft nicht ausreichend!) erläutert, mit irgendwelchen dubiosen Scripten usw. Das überfrachtet die Artikel oft unnötig.

MoonKid schrieb:

Und 2. checken die meisten Anwendungen nicht, ob sie ne zweite Instanz laufen haben. Ist auch meist unnötig. Es gibt durchaus Gründe, mehrere Instanzen laufen zu haben.

Zwei Mal Libreoffice führt auch nicht zum Datenverlust. Zwei Mal Unison überschreibt gerne mal Dateien. Kleiner Unterschied.

Ich hab bei der Unison-Mailingliste angefragt so ein Lockfile einzubauen. Sie sind dafür, aber keiner hat Lust es zu programmieren und ich kann es nicht. Daher wird es wohl so bleiben.

MoonKid schrieb:

Hier im Wiki werden IMO zu viele Spezialszenarios für die einzelnen Anwendungen (oft nicht ausreichend!) erläutert, mit irgendwelchen dubiosen Scripten usw. Das überfrachtet die Artikel oft unnötig.

Unser Ubuntu Wiki hier ist ja wohl das Beste, was es im Netz gibt. Lediglich einige Arch-Wikis sind noch besser, aber dann auch noch technischer. Ich kenne kein englisches Ubuntu Wiki, dass nur annähernd an die Qualität von diesem hier rankommt.

MPW> Unser Ubuntu Wiki hier ist ja wohl das Beste, was es im Netz gibt.

Korrekt! Und möchte, dass das so bleibt. 😉

Baus halt rein. Aber bitte deutlich vom eigentlichen Unison abgrenzen - sozusagen eine Extension.

Bei vieleln Artikeln mit irgendwelchen Workarounds, Skripten, etc fällt mir immer auf, dass die Existenzberechtigung des entsprechenden Abschnitts nicht ausreichend dargelegt wird und auch das Script (sofern vorhanden) nicht erklärt, sondern einfach nur ingeklatscht wird. Für Unison würde das ganz simpel bedeuten: Der Abschnitt kommt ganz nach hinten und bitte erklären, dass für Automation zusätzliche Software (z.B. cron) erforderlich ist und zu welchen Problem(!) es eben bei bestimmten Szenarien (große Files) kommen kann und das man darum diese "Extension" braucht.

btw: Ich hab den merkwürdigen bash-Aufruf nämlich nicht verstanden. Du sollst ja auch nich die bash-Syntax im Detail erläutern, aber wenigstens sinngemäß erklären, was das in etwa macht.

Es wird ja erklärt, dass es ein Lockfile ist, und wenn du noch einen Satz einfügen möchtest, nur zu.

Es steht deutlich in der Überschrift, dass es in dem Abschnitt um Automatisierung geht.

Und ich habe allein im letzten halben Jahr ein paar Mal genau diesen Ablauf zur Automatisierung von Unison erklärt. Du brauchst es vllt. nicht, aber andere scheinbar schon.

Hallo,

es tut mir leid diesen alten Artikel wieder auszugraben, aber mir ist ein Punkt unklar: Unter Schritt 5 (Automatisierung) wird empfohlen ein crontab-Eintrag vorzunehmen, bei welchem zunächst geprüft wird, ob bereits ein "Lock"-File besteht.

Im zweiten Listing des Abschnittes wird ein Bashskript vorgeschlagen, um trotz laufender Synchronisation eine weitere anstoßen zu können. Diese prüft allerdings auf die gleiche Weise das Vorhandensein des "Lock"-Files, wodurch ja dann ebenfalls der zusätzliche Sync nicht angestoßen wird, was aber im Text suggeriert wird!?

Ist Listing falsch oder verstehe ich den Text falsch?

Mfg Minfredo

Hallo!

Minfredo schrieb:

Im zweiten Listing des Abschnittes wird ein Bashskript vorgeschlagen, um trotz laufender Synchronisation eine weitere anstoßen zu können. Diese prüft allerdings auf die gleiche Weise das Vorhandensein des "Lock"-Files, wodurch ja dann ebenfalls der zusätzliche Sync nicht angestoßen wird, was aber im Text suggeriert wird!?

Das sehe ich genauso und habe diesen Abschnitt daher jetzt entfernt.

Viele Grüße

Vej