staging.inyokaproject.org

Moin,

ich habe resticgui-Howto erstellt und würde mich auf ein Feedback zum Artikel freuen.

gruss, pantomime

Hallo,

es gibt einen Wikiartikel zu Restic, den solltest du in der Einleitung verlinken (statt den Wikipedia Artikel).

Den ersten Satz "Linux-Anfänger sind mit dem Problem konfrontiert, dass die Eingabe von Befehlen im Terminal fehleranfällig und sehr zeitraubend sein kann." halt ich für Vollschrott. Wieso haben Fortgeschrittene oder Pro nicht das Problem? Weil die sich grundsätzlich nie vertippen oder zudem auch grundsätzlich schneller tippen?

Das Howto setzt stillschweigend voraus, dass Chromium als Browser installiert ist - das ist aber bekanntlich unter *buntu _nicht_ OOTB der Fall.

Das Howto setzt stillschweigend voraus, dass der gnome-terminal installiert ist - das ist aber nicht bei allen *buntus der Fall.

Außerdem stimmt das Howto so nicht - mein Ubuntu hat kein Verzeichnis /home/username/.local/share/applications... oder anders: du verschweigst total, dass bei einigen Exec= Zeilen die Befehl noch für das jeweilige System angepasst werden müssen. Zum einem willst du es "Linux-Anfängern" vermeintlich leichter machen, setzt aber gleichzeitig so viel Wissen voraus, dass die jeweiligen Zeile selbstständig fehlerfrei angepasst werden können. Halte ich für ein bisschen Schizo.

Grundsätzlich halte ich das ganze Howto für suboptimal, da es IMHO aktiv dazu beträgt, "Linux Einsteiger" "dumm" zu halten, indem es Klickbunti Verknüpfung propagiert statt das Wissen zu fördern, was eigentlich die Kommandozeilen Befehle machen. Wenn man das gecheckt hat ist das Anlegen von .desktop-Dateien ja nur ein kleiner Schritt. Einen allgemeinen Artikel zu .desktop -Dateien gibt es schon lange im Wiki.

Eigentlich sollten Howtos und Wikiartikel idealerweise auch ohne Bilder funktionieren. Stichwort: Barrierefreiheit

Gruß, noisefloor

Bei flüchtigem Überfliegen sind mir bisher aufgefallen:

• Was ist der Anwendungsfinder? Gibt es diesen nur in bestimmten Derivaten? Die Suchfunktion im meinem Standard-Ubuntu mit Gnome-Desktop findet jedenfalls so etwas nicht.

• desktop-Dateien müssen nicht ausführbar gemacht werden und sollten auch nicht ausführbar sein.

• Sollen Dateien als Anhänge im Wiki nicht besser als Wiki-Artikel-Anhänge statt über die Dateiablage realisiert werden?

• Bei Links, die aus dem Wiki heraus springen, fehlen die Fähnchen.

noisefloor schrieb:

[…] mein Ubuntu hat kein Verzeichnis /home/username/.local/share/applications

Der Ordner ~/.local/share/applications/ ist schon der richtige Ort zur Ablage von benutzerspezifischen .desktop-Dateien. Allerdings existiert das Verzeichnis nach frischer Installation nicht und muss immer erst vom Benutzer selbst angelegt werden. Dieser Umstand gehört aber in den allgemeinen Artikel .desktop-Dateien.

Hallo noisefloor,

danke für die Rückmeldung und Verbesserungsvorschläge.

noisefloor schrieb:

es gibt einen Wikiartikel zu Restic, den solltest du in der Einleitung verlinken (statt den Wikipedia Artikel).

erledigt

noisefloor schrieb:

Den ersten Satz "Linux-Anfänger sind mit dem Problem konfrontiert, dass die Eingabe von Befehlen im Terminal fehleranfällig und sehr zeitraubend sein kann." halt ich für Vollschrott. Wieso haben Fortgeschrittene oder Pro nicht das Problem? Weil die sich grundsätzlich nie vertippen oder zudem auch grundsätzlich schneller tippen?

Habe den Einführungstext mit Rücksicht auf deine Anregungen noisefloor angepasst.

noisefloor schrieb:

Das Howto setzt stillschweigend voraus, dass Chromium als Browser installiert ist - das ist aber bekanntlich unter *buntu _nicht_ OOTB der Fall.

Ist eine Gratwanderung und Herausforderung für jede/-n Autor/-innen bei der Erstellung eines Howto's.

1. Einerseits sich auf das Wesentliche, auf das Kernthema zu konzentrieren. Das Kernthema im Baustelle/resticgui-Howto ist: Die Anwender:innen dazu zu befähigen mit Hilfe von .desktop-Dateien im Terminal verfügbare Befehle in eine grafische Oberfläche zu verpacken und dann zeitsparend einzusetzen. Ob die Anwender:innen diese GUI-Verpackung selbst erledigen oder einen Bekannten, Verwandten, IT-Dienstleister, ... damit beauftragen, dürfen diese jeweils selbst entscheiden.

2. und gleichzeitig versuchen auf die Eventualitäten auf dem System der Leser:in soweit eingehen, um dafür zu sorgen, dass möglichst viele Leser:innen (Anfänger:innen und Expert:innen) auf Anhieb die Anleitung einsetzen können

3. die Anleitung darf aber auch nicht zu detailliert sein, sonst a) langweilen sich die Expert:innen b) das Risiko ist groß, dass die Expert:innen wie Anfänger:innen den Faden verlieren und Schwierigkeiten haben, zu erkennen, wozu denn NOCH EIN Howto, wo in diesem weiteren Howto Dinge beschrieben sind, die zig mal woanders (kompakt und ausführlich, vlt. auch besser) bereits vorhanden sind

noisefloor schrieb:

Das Howto setzt stillschweigend voraus, dass der gnome-terminal installiert ist - das ist aber nicht bei allen *buntus der Fall.

S. oben "ausführlich vs. knackig". Ich bin ein Ubuntu-Anfänger, bin mit Ubuntu 22.04 gestartet, bei mir war meines Wissens "gnome-terminal" standardmäßig installiert. Hier Baustelle/resticgui ist ein Hinweis enthalten:

Dieser Artikel wurde für die folgenden Ubuntu-Versionen getestet: Ubuntu 22.04

Gern können die Anwender:innen über die Testergebnisse für weitere Versionen berichten und das Howto ergänzen.

noisefloor schrieb:

Außerdem stimmt das Howto so nicht - mein Ubuntu hat kein Verzeichnis /home/username/.local/share/applications... oder anders: du verschweigst total, dass bei einigen Exec= Zeilen die Befehl noch für das jeweilige System angepasst werden müssen.

Habe entsprechend ergänzt.

noisefloor schrieb: Zum einem willst du es "Linux-Anfängern" vermeintlich leichter machen, setzt aber gleichzeitig so viel Wissen voraus, dass die jeweiligen Zeile selbstständig fehlerfrei angepasst werden können. Halte ich für ein bisschen Schizo.

Sehe ich ähnlich. S. "ausführlich vs. knackig" 😕

noisefloor schrieb:

Grundsätzlich halte ich das ganze Howto für suboptimal, da es IMHO aktiv dazu beträgt, "Linux Einsteiger" "dumm" zu halten, indem es Klickbunti Verknüpfung propagiert statt das Wissen zu fördern, was eigentlich die Kommandozeilen Befehle machen.

= = = = = = = = = = = = = = = = = =

halte ich das ganze Howto für suboptimal, da es IMHO aktiv dazu beträgt, "Linux Einsteiger" "dumm" zu halten, indem es Klickbunti Verknüpfung propagiert.

Ist deine Meinung, die respektiere ich.

Klickbunti Verknüpfung propagiert statt das Wissen zu fördern, was eigentlich die Kommandozeilen Befehle machen.

Meines Wissens wird im Wiki konsequent die Linie praktiziert, propagiert, dass man tunlichst darauf verzichtet, den Anwender:innen vorzuschreiben, welche Tools und WIE diese anzuwenden haben. Gibt es einen Grund, von dieser Linie für Baustelle/resticgui abzuweichen?

In der Problembeschreibung habe ich mit keinem Wort erwähnt, dass ich Klickbunti Verknüpfung propagieren möchte. Ich beschreibe einen Lösungsansatz, von dem - meine Meinung - fortgeschrittene Anwender:innen und Anfänger:innen dadurch profitieren können, dass sie Kommandozeilen-Funktionen in barrierearme GUI verpacken und so dafür sorgen, das Anwender:innen mit weniger know-how dank .desktop-GUI-Schnipsel weniger Fehler beim Einsatz von Kommandozeilen machen. Anfänger:innen machen hoffentlich weniger Fehler, stellen weniger Fragen, die Expert:innen und Anfänger:innen können sich jeweils auf die Kernaufgaben konzentrieren.

noisefloor schrieb:

Wenn man das gecheckt hat ist das Anlegen von .desktop-Dateien ja nur ein kleiner Schritt. Einen allgemeinen Artikel zu .desktop -Dateien gibt es schon lange im Wiki.

Sehe ich genauso. Ich freue mich auf die Zukunft, in der dank zahlreichen barrierearmen .desktop-GUI-gestützten-Anleitungen im Wiki oder auch woanders die leistungsfähige Kommandozeilen-Tools für immer mehr Anwender:innen niederschwellig zugänglich gemacht und auch genutzt werden 😀 .

noisefloor schrieb:

Eigentlich sollten Howtos und Wikiartikel idealerweise auch ohne Bilder funktionieren. Stichwort: Barrierefreiheit

Ich gehe nochmal die Anleitung hinsichtlich barrierearme Alternativen für Bilder durch. Barrierefreiheit genauso wie Datenschutz ist ein scharfes Schwert. Damit wird aber auch viel Unfug betrieben - meine Meinung.

gruss, pantomime

kB schrieb:

Bei flüchtigem Überfliegen sind mir bisher aufgefallen:

• Was ist der Anwendungsfinder? Gibt es diesen nur in bestimmten Derivaten? Die Suchfunktion im meinem Standard-Ubuntu mit Gnome-Desktop findet jedenfalls so etwas nicht.

Habe den Text im Howto für ein besseres Verständnis im Abschnitt "Verwendete Software" ergänzt.

kB schrieb:

• desktop-Dateien müssen nicht ausführbar gemacht werden und sollten auch nicht ausführbar sein.

Habe ich den Hinweis entfernt.

kB schrieb:

• Sollen Dateien als Anhänge im Wiki nicht besser als Wiki-Artikel-Anhänge statt über die Dateiablage realisiert werden?

Meinst du diese Dateien:

1. resticgui.7.gz ?

2. und resticgui.pdf ?

Ich habe diese Dateien über Konfiguration → Anhänge verwalten hier Baustelle/resticgui/a/attachments im "Howto erstellen"-Dialog eingebunden. Kannst du mir evtl. einen Beispiellink zu der Datei schicken, die als Wiki-Artikel-Anhänge verlinkt ist? "Wiki-Artikel-Anhänge" suggeriert mir, dass dies über ein Dialog für die Artikelerstellung gemacht wird oder irre ich mich?

kB schrieb:

• Bei Links, die aus dem Wiki heraus springen, fehlen die Fähnchen.

Habe Fänchen angebracht.

gruss, pantomime

pantomime schrieb:

kB schrieb:

• Sollen Dateien als Anhänge im Wiki nicht besser als Wiki-Artikel-Anhänge statt über die Dateiablage realisiert werden?

Meinst du diese Dateien:

1. resticgui.7.gz ?

2. und resticgui.pdf ?

Außerdem müssen Download-Links mit ⮷ gekennzeichnet sein.

Setze bitte beim Erstellen eines Howtos den Präfix Howto/ vor den Seitennamen! Das erspart das Umbenennen.

Für deine Befehle nutze bitte die

Vorlage Befehl 

Exec=/snap/bin/chromium https://restic.readthedocs.io/

Warum nimmst Du nicht einfach Firefox? Das ist keine Gratwanderung.

Die Linksammlung bitte umstrukturieren in

Und was sollen eigentlich die Hunderttausende von Revisionen für „Kleinigkeiten“? Kann man das nicht bündeln?

karzer schrieb:

Außerdem müssen Download-Links mit ⮷ gekennzeichnet sein.

erledigt

Setze bitte beim Erstellen eines Howtos den Präfix Howto/ vor den Seitennamen! Das erspart das Umbenennen.

Das bezieht sich auf zukünftige Howtos? Beim resticgui bleibt das erstmal so, richtig?

Für deine Befehle nutze bitte die

Vorlage Befehl 

Exec=/snap/bin/chromium https://restic.readthedocs.io/

Warum nimmst Du nicht einfach Firefox? Das ist keine Gratwanderung.

Habe Chromium durch Firefox ersetzt und getestet.

Die Linksammlung bitte umstrukturieren in

Links¶

Extern¶

und

Intern¶

Ist es nicht doppelt gemoppelt, dass zusätzlich zu den Fähnchen noch die Links Sortierung in "Extern" und "Intern" zu sortieren? Es gibt doch klare Zuordnung/ Sortierung:

• mit Fähnchen - "Extern",

• ohne Fähnchen - "unbuntuusers.de-Intern".

Hier Howto sind diese "Extern"/"Intern"-Abschnitte nicht erwähnt. Rein technisch kein Problem, als Problem sehe ich, dass durch die Einführung von weiteren Überschriften/ Unterabschnitten die Webseite und der Scrollaufwand weiter aufblähen. Nur weil - wie hier Baustelle/resticgui wegen drei Links zusätzlich zwei Unterabschnitte gebaut werden. Finde ich nicht besonders schön.

Zudem sollte meiner Meinung nach für jede Datei ein Unterabschnitt erstellt werden. Oder zumindest die Dateinamen fettdrucken.

Habe die Dateinamen fett hervorgehoben.

karzer schrieb:

Und was sollen eigentlich die Hunderttausende von Revisionen für „Kleinigkeiten“? Kann man das nicht bündeln?

Ich speichere möglichst oft die Zwischenstände, da ich mehr als einmal schmerzhaft erfahren habe, dass die Browser die Gewohnheit haben abzustürzen und den Text nach dem Neustart zu vergessen. Wenn für die Prüfer relevant ist, ob bestimmte Änderungen bereits geprüft sind, reicht es doch sich zu notieren, welche Änderung (Zeitmarke) bereits geprüft ist. Oder was ist das Problem @karzer?

pantomime schrieb:

... , da ich mehr als einmal schmerzhaft erfahren habe, ...?

Da bist du nicht alleine ... vermeide die "Schmerzen" mit einem simplen Texteditor oder InyokaEdit. Letzteres ungetestet.

sh4711 schrieb:

Da bist du nicht alleine ... vermeide die "Schmerzen" mit einem simplen Texteditor oder InyokaEdit. Letzteres ungetestet.

Darauf bin ich auch gekommen und verwende dort, wo dies praktikabel ist. Nur in einem Texteditor kann ich nicht testen, wie die Änderungen dann "in echt" auf der Webseite dargestellt werden 😐 .

Hallo,

Wenn für die Prüfer relevant ist, ob bestimmte Änderungen bereits geprüft sind, reicht es doch sich zu notieren, welche Änderung (Zeitmarke) bereits geprüft ist.

Das ist ziemlicher Unfug. Geprüft wird dann, wenn du sagst: fertig. Gibt's noch Verbesserungen, wird nochmals alles geprüft. Die Arbeit, nur Anhand des Diffs zu prüfen und sich zu merken, was wann wie schon geprüft wurde, gibt sich freiwillig keiner.

Der Punkt ist, dass du die Historie unnötig aufbläst - auch wenn Inyoka da kein Limit hat. Und wenn dein Browser abstürzt solltest du dem nachgehen. Bei mir ist der Firefox auch bei Edits über eine längere Zeit, also 30 Minuten plus, noch nie abgestürzt.

Abgesehen davon: was dir glaube ich (noch) fehlt ist das IMHO notwendige Abstraktionsvermögen, von "ich haben ein Problem für mich gelöst" auf "ich stelle die Lösung möglichst verständlich und allgemeingültig" auf wiki.ubuntuusers.de bereit. Das Wiki ist _kein_ persönliches Notizbuch - vieler deiner bisherigen Vorschläge erwecken aber gerade diesen Eindruck bei dir. Man muss da schon seine Gedanken einen Schritt weiter schweifen lassen, abstrahieren und seinen eigenen Mikrokosmos verlassen.

Beispiel:

Ich bin ein Ubuntu-Anfänger, bin mit Ubuntu 22.04 gestartet, bei mir war meines Wissens "gnome-terminal" standardmäßig installiert.

Letzteres ist richtig. Für Ubuntu. Aber nicht für alle Derivate. Die sind im Wiki aber gleichberechtigt. Und der "getestet" Tag geht grundsätzlich davon aus, dass das für _alle_ *buntus in der angegebenen Version gilt. Es ist völlig legitim, ein Howto oder einen Wikiartikel auf ein Derivat zu beschränken - aber dann muss man das halt explizit direkt in der Einleitung sagen.

Gruß, noisefloor

Hallo,

gerade nochmal gelesen: ich halte die Einleitung immer noch für ziemlich schrottig.

Grund: die erklärt IMHO erst mal wortreich, dass das alles irgendwie kompliziert ist, Anfänger grundsätzlich zu doof dafür sind und das ggf. nicht verstehen. IMHO ist der kapitale Fehler, dass du erst mal komplett in den Rechtferigungsmodus verfällst, warum das Howto erstellt wurde. Und das ist: falsch. Lass' den ganzen Mist weg und beschreib' nur, _was_ in dem Howto abgehandelt wird. Das _warum_ ist komplett sekundär. Mal abgesehen davon, dass eine Einleitung, in der sinngemäß steht "ich halte euch für zu doof, deswegen schreibe ich mal was" nicht wirklich zielführend ist und zum Lesen animiert.

Gruß, noisefloor

pantomime schrieb:

... Darauf bin ich auch gekommen und verwende dort, wo dies praktikabel ist. Nur in einem Texteditor kann ich nicht testen, wie die Änderungen dann "in echt" auf der Webseite dargestellt werden 😐 .

von mir markiert
aha, das sagt mir jetzt aber, Du hast InyokaEdit noch nicht benutzt.