[gelöst] Eigene Linux (Wissens-)Bibliothek

[novalix]

Viele Wege führen nach Rom, oder nach Orten, die so ähnlich oder ganz anders heißen.

Ein großes Problem, was entstehen kann, wenn man sich auf einen Einzeiler stürzt, den man vor langer Zeit mal wie und wo auch immer hinterlegt hat:
Was macht dieses kryptische Geschwurbel eigentlich?
Habe ich das geschrieben?
War ich dabei nüchtern?

Irgendwie fehlt einem dabei dann doch oftmals der Kontext. Und wenn ich so einen Awk-Einzeiler erst mal dekonstruieren muss, um zu begreifen, was er eigentlich tut, kann ich ihn wahrscheinlich fast genau so gut von Grund auf neu komponieren.

Der Nachteil bei vielen Wikis ist, dass die Inhalte nur über eine funktionierende Implementation desselben aus der jeweiligen Datenbank gelesen werden können.
Das ist der Vorteil von Wiki-Compilern wie ikiwiki. Da habe ich die Quellen als durchaus lesbare Markdown-Dateien und die Erzeugnisse als Baum von verlinkten HTML-Dateien vorliegen, selbst dann, wenn das Programm "ikiwiki" schon gar nicht mehr auf meinem Rechner verweilt. It is text, sugar.

Ein Bewohner von Emacs hat in einem Blogbeitrag (und Screencast) seinen Workflow beschrieben, den er Literate DevOps(englisch) nennt.
Allemal interessant.

[kuleszdl]

Ich empfehle ebenfalls tiddlywiki, allerdings nur mit Markdown-Plugin. Es hat nur den Nachteil, dass es mit Bildern nicht sonderlich gut umgehen kann (Performance wird bei vielen Bildern spürbar schlecht).

Falls die Sammlung größer wird sind Dokumentationswerkzeuge wie mkdocs (markdown) oder sphinx (rst) eine gute Wahl. Alternativ kann man auch einen statischen Seitengenerator wie hugo, jekyll o.a. nehmen, ich bevorzuge aber die vorgenannten Dokumentationswerkzeuge.

[Korodny]

Der Nachteil bei vielen Wikis ist, dass die Inhalte nur über eine funktionierende Implementation desselben aus der jeweiligen Datenbank gelesen werden können.

Richtig, weswegen ich Zim nur empfehlen kann, das speichert die Inhalte von Haus aus als (Markdown-) Textdateien.

Ich würde ein Desktop-Wiki nicht mehr missen wollen. Baumstruktur samt Verwaltung per Drag'n Drop, Suchfunktion, die Möglichkeit kurze Erläuterungen oder gar Screenshots zu den Notizen/Shell-Befehlen hinzuzufügen, einfache ToDo-Listen anlegen usw. - und das alles in einer sinnvoll strukturierten Anwendung...

[pferdefreund]

Hinter jeden Befehl in der Textdatei einen Suchbegriff eintragen so ala ::loeschen von... usw.
Dann ein Mini-Script mit grep -i suchbegriff /deine/textdatei und selbst bei 10.000 Einträgen ist das immer noch viel schneller wie irgendein grafisches Tool starten. Wie schon geschrieben wurde -- keep it simple. und der Clou dabei ist,
mit Markieren im Terminalfenster mit der Maus und mittlerer Maustaste in der Eingabezeile steht der Befehl dann auch gleich da, wo er hingehört und kann nach Anpassung abgesetzt werden.

[jph]

Für die vielen kleine und großen "Merkzettel", die sich im Laufe der Zeit ansammeln, habe ich z.B. Mediawiki auf meinem Heimserver laufen.

Das Problem ist ja schon als gelöst markiert, möchte dennoch meinen Senf dazugeben und diese Aussage unterstützen. Ein Wiki hat den Vorteil, dass ich dort nicht nur Computerthemen dokumentieren kann, sondern auch andere Dinge. Welche Farbe wird wo im Haus verwendet, wie ist welche Verkabelung gelegt, wie genau funktioniert die Einstellung dieses verflixten Rolladenmotors, an den ich hoffentlich nie wieder dran muss… (Meine Frau könnte dort theoretisch ihre Kochrezepte ablegen. Sie nutzt dann aber doch lieber die Chefkoch-App auf dem iPad.)

Ich habe dokuwiki auf dem Heimserver laufen. Fehlt in stretch, lässt sich aber problemlos manuell anhand des Paketes aus buster installieren. Dokuwiki arbeitet mit Dateien und braucht kein RDBMS.

[DeletedUserReAsG]

Ich selbst bin da eher ein Fan von KISS, und finde daher zim auch ziemlich passend. Selbst recht komfortabel, kann man aber auch ohne die Software recht einfach auf die gespeicherten Daten zugreifen.