staging.inyokaproject.org

Da mein neuer Abschnitt doch etwas länger und spezifischer wurde (Terminal als Voraussetzung fehlt im Übersichtsartikel auch), sollte er in einen eigenen Artikel ausgegliedert werden, oder?

Wäre er so weitestgehend in Ordnung für einen eigenen Artikel?

Grüße, Benno

Benno-007 schrieb:

Da mein neuer Abschnitt doch etwas länger und spezifischer wurde (Terminal als Voraussetzung fehlt im Übersichtsartikel auch), sollte er in einen eigenen Artikel ausgegliedert werden, oder?

Ja.

Wäre er so weitestgehend in Ordnung für einen eigenen Artikel?

Nein, denn Howtos sind nicht im Wiki erwuenscht. Allerdings koennte man in eine Baustelle/pam time noch Hintergrundinformationen einflechten und die Beschraenkung der Nutzungszeit dann als praktisches Beispiel verwenden.

Hallo,

ich bin gerade dabei, den Abschnitt vorerst wieder rauszunehmen und mir eine passende Baustelle zu überlegen. Dass keine Howtos gewünscht sind, hab ich so aufgefasst, dass der Pflegeaufwand zu hoch ist, ist das korrekt?

Nun wollte ich das gar nicht ansprechen und einfach umsetzen. Das Problem ist aber, dass mein Abschnitt ja noch zwingend aus einem zweiten Teil cron bestehen muss. Was machen wir denn da?

Einerseits glaube ich, dass es gute Gründe dafür gibt, andererseits frage ich mich: Was ist wichtiger, vorhandene Funktionalität oder Prinzipien, die keiner nachvollziehen kann? Es steht ja sogar im Wiki, dass hier ein Mangel vorherrscht. Und Scripte sind auch sowas wie Howtos, nur in Code und mit weniger Pflegeaufwand (vielleicht). Warum also nicht eine Howto-Sektion im Wiki, wurde bestimmt schon mal wo begründet verworfen - hast du einen Link zur Hand?

Fakt ist: Ich hab eine Lösung anzubieten und die gibt's nur ganz oder gar nicht. Weil sie nur im Zusammenspiel der Komponenten funktioniert. Und sie gehört ins Wiki, weil das ein erheblicher Mangel von Linux/ Ubuntu/ dem Artikel ist. Und nicht irgendwo verstreut auf Blogs. Ich seh spontan nur folgende Wege:

a) Baustelle mit umfangreichen Beispiel. Erweitern ist zwar schwer, aber weniger ein Problem als ein halbes Konzept, welches am Ende gar keinem für den Anwendungsfall nutzt, wo es die Lücke gibt.

b) Es wird als Script verpackt, was aber aufwendige Tests umfasst und nicht so ungefährlich wie manuell ist. Und kommt dann in die Skripte-Sektion.

c) Es wird eine Howto-Sektion neben der Scripte-Sektion geschaffen, mit Warnkasten darüber, dass diese von Benutzern sind und nur bedingt aktuell oder mit Getestet-Tag, wie üblich.

d) Euch fällt noch was andres ein?

Ich leg jetzt jedenfalls los und mach irgendwas draus, aber es wäre davor/ dabei schön zu wissen, was. Derweil ergänze ich mal den PAM-Teil... Umbenennen kann man die Baustelle ja auch nochmal.

Ich weise auch mal drauf hin, dass es Artikel gibt, die zwingend Ausnahmen brauchen, beispielsweise GRUB 2/Reparatur (Abschnitt „Standard-Desktop-System“) geht auch auf EFI, LUKS als auch chroot/Live-CD ein, weil nur eine integrierte Lösung funktioniert. Ich hoffe, du bist mit mir weiterhin an einer Lösungsfindung interessiert, was ich ja bisher daran sehe, dass mir Tipps gegeben werden und ich die Seite selbst zurückrollen kann. 😉

Grüße, Benno

aasche schrieb:

Wäre er so weitestgehend in Ordnung für einen eigenen Artikel?

Nein, denn Howtos sind nicht im Wiki erwuenscht. Allerdings koennte man in eine Baustelle/pam time noch Hintergrundinformationen einflechten und die Beschraenkung der Nutzungszeit dann als praktisches Beispiel verwenden.

Dass keine Howtos gewünscht sind, hab ich so aufgefasst, dass der Pflegeaufwand zu hoch ist, ist das korrekt?

Nein - es geht primär darum, dass es ein Wiki für Einsteiger ist. Da sollen alle Schritte nachvollziehbar sein. HowTos sind zwar schnell abgearbeitet aber helfen nur kurzfristig, wenn man nicht versteht was man da eigentlich macht. Nebenbei sind sie meistens auf einen Anwendungsfall ausgerichtet. pam_time ist aber einen eigenen Artikel wert. Durch das Praxisbeispiel, welches man in dem anderen Artikel wunderbar einbinden/gebrauchen kann, ist es möglich den Inhalt einfacher zu verstehen und man hat eine Sache geschaffen, welche für mehr als eine Sache nutzbar ist. Hoffe mein Grundgedanke ist verständlich beschrieben. ☺

Hallo march.

Danke für die schnelle Antwort. Wegen dem letzten Satz lass ich meine Antwort hier statt in Rund um Ubuntuusers, weil es mir um das Beispiel hier geht, sonst hätte ich es wohl besser in ein eignes Thema gepackt.

Das macht mich nachdenklich, da ich z.B. auf meiner Benutzerseite oft versuchte, Dinge auf die wesentliche Substanz von viel Infos drumrum (die kein Einsteiger versteht oder verstehen will) einzudampfen - quasi den umgekehrten Weg gehe, vom Anwendungsfall hin zum Verständnis einiger weniger Optionen statt einem Artikel mit vielen Optionen, ohne zu wissen, wie man dieses Werkzeug dann anwendet.

Ist aber wahrscheinlich beides wichtig und ergänzt sich, wobei sich das Wiki von Howtos abgrenzt - Ausnahmen sind die, wo die Werkzeuge im Howto auch erklärt werden, kann man das so sagen? Wobei das wahrscheinlich trotzdem immer eine Relevanzentscheidung sein wird, meist zu Ungunsten eines Howtos, wenn die Werkzeuge im Wiki schon gut abgebildet sind und es nicht um Grundlagen-Howtos (!) wie System verschlüsseln geht. Was in meinen Augen genauso ein Howto ist wie die eben verlinkte Grub-Reparatur.

Und das Wiki muss gut verlinkbar sein, indem es nachvollziehbar ist. Und Nutzer zu eigenständigem Denken anregen soll. Das motiviert, Unnachvollziehbarkeit demotiviert, auch wenn es funktioniert. Ist mir auch schon mal aufgefallen.

Also bekomme ich cron in dem pam_time Artikel im Beispiel auch noch mit unter, wie es für den Sachverhalt nötig wäre? Dessen Erklärungen sind dann aus meiner Sicht auch kein Howto, sondern ein Beispiel im Zusammenhang mit pam_time. Wobei die Werkzeuge von cron ja mehrfach verlinkt sind. Also erkläre ich die auch nicht nochmal, sondern "nur" für pam_time, ja?

Grüße, Benno

Ich würde nach nochmals einem Tag Arbeit den Artikel erst mal zur Diskussion stellen wollen und hoffe, dass maximal noch Kleinigkeiten zu ändern sind, da ich meine Zeit dafür weit überstrapaziert habe. Mir wegen wäre er nämlich soweit zum Veröffentlichen bereit.

Ich finde, man kann manches vielleicht anders machen, aber er ist sicher nicht schlecht. Er muss sicher nicht perfekt sein, sondern im Wesentlichen dem Mindestmaß an Qualitätskriterien genügen. Das sollte ich bei weitem erreicht haben, bis auf vielleicht kleinere Nacharbeiten, die nötig sein könnten. Aber ich hab das ja nicht zu entscheiden, ich will nur meine Eigenbewertung als Beweis meiner Motivation zu einem gelungenen Artikel rüberbringen.

In den Kommentaren der Baustelle stand, dass man die Bilder anhängen soll - damit kann dann nur die Diskussion gemeint sein, weil es in der Baustelle keine Anhangfunktion zu geben scheint. Ich hänge es daher nun hier mal direkt mit an, im Artikel ist die png bereits verlinkt, wobei ich die Größe momentan nicht einschätzen kann. Das Bild soll den Artikel etwas auflockern, Vertrauen in das Beispiel schaffen und die ansonsten doch recht trockene Methode attraktiver machen. Und einem die Funktion des Beispiels in einem Bild nahebringen.

Der ablehnende Anmeldebildschirm stellte sich zudem als inhaltlich und von der Lesbarkeit her nicht als gehaltvoll genug heraus. Daher lieber die Integration des bildlichen Hinweises, wie dieser aussieht und mit dem Hinweis, dass bald die Sperre wirksam und der Computer heruntergefahren wird.

(Eigentlich hatte ich heute noch einen Artikel vor, aber wenn das jedes Mal zwei Vollzeittage dauert, dann...)

Ich hoffe, das Wiki damit bereichern zu können, indem ihr mir helft, die Punkte zu benennen, die vielleicht noch zwingend oder wünschenswert zu ändern sind.

Grüße, Benno

Benno-007 schrieb:

Ich würde nach nochmals einem Tag Arbeit den Artikel erst mal zur Diskussion stellen wollen und hoffe, dass maximal noch Kleinigkeiten zu ändern sind.

Gut, dann warten wir ein paar Tage, bevor der Artikel ins Wiki kommt. Vielleicht findet sich noch jemand, der ein Review machen kann.

Gut, kein Problem. Steht dazu dann vielleicht ein Aufruf im UWR?

Grüße, Benno

Benno-007 schrieb:

Steht dazu dann vielleicht ein Aufruf im UWR?

Ja - wenn Du das UWR-Team darauf hinweist.

😉

m.E. verschiebbar. Verlinken nach?

frustschieber schrieb:

m.E. verschiebbar.

sorry, aber davon ist der bisherige Entwurf nach meiner persoenlichen Meinung noch weit entfernt.

aasche schrieb:

Benno-007 schrieb:

Ich würde nach nochmals einem Tag Arbeit den Artikel erst mal zur Diskussion stellen wollen und hoffe, dass maximal noch Kleinigkeiten zu ändern sind.

Gut, dann warten wir ein paar Tage, bevor der Artikel ins Wiki kommt. Vielleicht findet sich noch jemand, der ein Review machen kann.

Das hier war eine Zusage. Und nun das, ohne bisherige weitere Anforderungen. Was soll denn das?

Und mal was andres: Das kocht langsam hoch, diese stinkende Brühe: Unzufriedenheit mit dem Wiki-Team

Grüße, Benno

Benno-007 schrieb:

Das hier war eine Zusage.

Zusage? Fuer was oder an wen?

Folgende Punkte koennten noch gemaess den Wiki-Regeln und hinsichtlich der Wiki-Syntax ueberarbeitet werden:

• keine Doppelpunkte in Ueberschriften

• keine gelben Markierungen (in Befehlen)

• Nummerierung in Ueberschriften vermeiden

• Das enthaltene Bild sollte verkleinert dargestellt werden, um mehr Platz fuer den eigentlichen Text zu lassen. Faustregel, damit es auch auch auf Smartphones ohne Scrollen anzeigen laesst: max. 300 Pixel.

• bitte die Sprache externer Links mit Flaggen kennzeichnen

• Wissensblockverweise idealerweise in aufsteigender Reihenfolge

• nano ist ein moeglicher Editor. Bei einem Verweis auf den Wissensblock kann jede/r ihren/seinen Lieblingseditor einsetzen. Und wenn ein Editor erwaehnt wird, braucht es IMHO keine Befehlszeilen mit sudo sh -c "echo ...", sondern ein einfacher Codeblock reicht aus.

• Kommentare zum Einfuegen in andere Artikel bitte auskommentieren und an den Anfang des Artikels verschieben. Dann wissen die Kollegen, die den Artikel aus der Baustelle holen Bescheid, wohin und mit welchem Text er verlinkt werden soll.

Inhaltlich:

• Gelten die Aenderungen sofort oder ist ein Neustart des Rechners erforderlich?

• eindeutigere Gliederung (Spruenge zwischen "time.conf" und "Services aktivieren" vermeiden)

• was hat die crontab mit der crypttab zu tun?

• Warum wird root als Beispiel genutzt, um einen Benutzer auszusperren? Service und Wartung jetzt nur noch zwischen 8 und 10 Uhr vormittags an allen Tagen ausser Mo, Mi und allen ungeraden Wochenenden?

• Insgesamt sehr viel umschreibender Text. Evtl. ginge es auch ein wenig zielfuehrender bzw. praegnanter?

Um es auf den Punkt zu bringen: meiner Meinung nach wimmelt es im bisherigen Entwurf von etlichen kleineren und groesseren Umgereimtheiten - nicht nur, was die Wiki-Syntax angeht. Und genau darauf wollte ich den Kollegen hinweisen, bevor ein halbgarer Artikel ins Wiki wandert, der dann auch fuer den Autor nicht besonders schmeichelhaft ist.

Macht dir Spaß, einem so eine Liste vorzuklatschen, oder? Du kannst motivieren. 👍 Hauptsache, deine eignen Artikel sind SPITZE - beteilige dich doch mal bei denen, die Hilfe brauchen!

Grüße, Benno