Salve Werner! Werner Mahr schrieb am Freitag, den 17. Dezember 2004 um 14:05h: > Und dann auch noch direkt zu mir. Ich lese diese Liste. Sorry zum 2. mal - ich werde muttrc anpassen ;) > > > Wenn man es aber in vielen Jahren einfach wiederfinden möchte, sollte > > die soetwas wie die ID des Skriptes gleich bleiben. Dies ist nicht nur > > für einen persönlich "nett" sondern wenn man in privaten/öffentlichen > > Listarchive durchsucht und den Tip findet Skript 352992 hilft.... > > ;)
> > Guter Punkt, also sollte jedes Skript in Headerkommentar eine Liste der > > notwendigen Programme haben und wenn man es ganz auf die Spitze treibt ab > > welcher Version (Zumindest wenn man Fedback hat, das es mit z.B. < 3.0 > > nicht geht). > > Dann brauchst du aber wieder einen Parser dafür. Den Parser "script-cache search" hatte ich doch eh angeregt. > > Ein script-get "sollte" notwendige .deb Pakete auflisten und > > script-cache "sollte" eine option haben, das nur mit dem bestehenden > > System kompatible skripte angezeigt werden. > > Eine Suche in einem Wiki hat den selben Effekt. Wozu gibt es apt? Damit man nicht in Verzeichnissen oder gar externen Servern per Hand suchen muß. > Guck mal ins Listenarchiv, da gibts mindestens 4 Adressen mit mbox und > maildir. Vielleicht macht sich auch noch jemand die arbeit das anständig zu > paketieren. > > > Ja, es gibt ein listenarchiv und eine suchfunktion auf der Webseite, > > Genau diese meinte ich eben. Ok, aber wie finde ich ohne Webbrowser mit einem installierten Debian System diese mbox oder maildir Pakete von der shell aus? Angenommen man setzt irgendwo ein neuen Server auf und kann alle Pakete per shell "ziehen" aber zusätzliche Dokumentationen um diese Programme nutzen zu können muß man z.Z. mit einem Webbrowser suchen :( IMHO ist dies inkonsistent - Arbeitsschritte, die mit Programmen funktionieren sollte genauso mit Dokumentationen, Skripten, Beispielkonfigurationen funktionieren. > > Wobei ich zugebe, das wenn man im Frühjahr eine neue Debianversion > > herausbringen wird, in allen Sprachen Wikipedia-Images beifügen würde, > > doch von der Größe "etwas" Debian als Distribution sprengen würde. > > (Vielleicht noch gutenberg.org, Hubblebilder....). > > Wobei man auch sagen muss, das das auch nicht zu dem gehört, was man im > allgemeinen unter Distribution versteht. Hey, das war etwas Selbstironie zu dem Brainstorming in diesen Thread ;) > > Ein Kompromis wäre, das man zwischen ausführbaren Code und Inhalten > > unterscheidet und z.B. im Falle der der Wikipedia die notwendige > > Software in einem .deb Paket hat und das Images der Wikipedia von > > wikipedia.org läd. > > Was man dabei von dem Script absplitten sollte musst du mir aber noch > erklären. Ich persönlich habe noch kein Script mit Bildern geschrieben. Mit Images meinte ich die Wikipedia-DBs: http://download.wikimedia.org/archives/de/20041209_cur_table.sql.bz2 Achtung bereits > 200 MB groß. Plural, weil man (ich) wenn gerne mehr als eine Sprache installieren würde. Die Wikipedia DB veraltet im Gegensatz zur DB-Software schnell. Ein wikipedia.deb würde alle nötige Pakete (PHP, MySQL) installieren und die DB vorbereiten, ein wikipeida -get German würde danach das letzte sql.bz2 holen. > > Jepp und wenn jemand forken möchte baut er ein neues skript und legt > > unter der Beschreibungsseite/Diskussionsseite unter > > siehe auch: > > [[bahn-355.sh]] Abfahrtsbahnhof (und zusätzlich) Zielbahnhof > > Oder einfach ein siehe auch, und den Rest auf die Site des anderen Skriptes. Ja, aber neben den Link sollte auch kurz erklärt werden was dieses Skript besser/mehr/anderes kann. > > Seiten wie knoppix.net, pro-linux... etc sind ja ganz nett, das wiki von > > knoppix.net ist z.Z. nicht online, wenn man mit einem Wiki beginnen > > würde, wäre es schön, wenn es mehr als eine privat initative ist, > > weitesgehend von Firmen und Einzelpersonen unabhänig und so möglichst > > lange nach dem gleichen Schema funktioniert. > > Dafür gibt es Lösungen, man muss sich nur Zeit nehmen und das ganze in Gang > bringen. Ich meinte das es "ewig" unter z.B. wiki.de.debian.org zu erreichen ist. > > Wie, wo könnte man mit einem Skripte-Wiki starten? > > Könnte dies, wenn es durchdacht, brauchbar und lebendig ist auch als > > offizielles Debianprojekt betreiben? > > Das wäre wahrscheinlich die beste und schlechteste Möglichkeit zugleich. Ein > Unterprojekt würde deine Probleme im obigen Absatz sofort zerschlagen, > andererseits wäre aber Nutzern anderer Distributionen mit den Skripten die > speziell auf Debian zugeschnitten sind nicht viel geholfen. Ich verstehe diese Skripte/Dokumentation als erweiterte Distribution und möchte ganz bewußt keine algemeine Linux-Skriptseite anregen, sondern eine Lösung für Debianer. Andere Distributionen mögen diese Sammlung übernehmen und auf ihre Eigenheiten anpassen, oder jemand eine zentrales Projekt starten... Um die Nutzung von Debian einfacher und populäre zu machen würden einzele "SuSE-only" Skripte stören und ein Skript mit 10 Zeilen Code, aber 30 Seiten Kommentar für 7 verschiedene Distributionen macht die Nutzung unnötig kompliziert. Apt-cache listet (normalerweise) auch keine Pakete von anderen Distributionen. Wenn ich bisher weitschweifend und unscharf mit Euch hier im Thread geschrieben habe - ich würde hart den Focus auf Debian legen, ob es anderen GNU/Linuxer hilft oder nicht wäre mir egal. Für Binarys und Source gibt es .deb dpkg und apt für Skripte, Beispielconfigs, Tutorials, Knowledgebase fehlt etwas. Meine Frage ist es, ob man für all diese viele kleine lesbare Objekte ein einheitliches System entwirft, das für die Nutzer - eine 100% Shell Nutzung zuläßt - eine effiziente Suche zuläßt - mit wenig lokalen Speicher arbeiten kann - einfach spiegelbar, bzw auf CD packbar ist - passive Server (ftp) nutzen kann - Trafficsparsam - Eindeutige und ewige ID verwendet - jede Information durch eine Signierung/Hashwert sichert Und für die Aktiven ein Kompromis aus restriktiver Rechtevergabe (pro Objekt nur begrenzte Anzahl von Autoren) und interakiver Möglichkeit wie in der Wikipedia ohne Bürokratie Korrekturen und Ergänzungen zu ermöglichen. Sowie zur Qualitätssicherung wie bei der Wikipedia "last Changes" "history"... zu ermöglichen. Eine Webseite/Forum aufzumachen und zu sammeln - das gibt es schon x mal und hat zu einer Abhänigkeit von einzelen Webseiten (Linux-usb...) geführt - alle sind anders.... Ich kann gerne noch etwas weiter utopisch denken - das system sollte auch private Einträge ermöglichen, nicht jedes configfile will ich komplett veröffentlichen, wenn ich einen Server habe würde ich vielleicht gerne jede Fassung eines von mir editierten configfiles zentral (verschlüsselt) mit Metainformationen zu meinem PC speichern. Genauso mitloggen wann ich (wo) welches skript/hilfe/dokumentations/manpages Objekt gelesen habe sowie Komentare und Lesezeichen in diesen Dokumenten ermöglichen. Auf diese privaten ergänzungen möchte ich, wenn ich für eine Firma etwas einrichte zugreifen können - ohne das diese Daten an dritte gelangen und so, das möglichst wenig Traffic entsteht. Und dann noch ein Update-watch, d.h. ich kann bestimmte Suchbegriffe "abonieren" d.h. lokal auf meinem Rechner auswählen und wenn das System einen neuen Text/Textänderung mit dem Suchbegriff (z.B. für mein 3Com Combo mini-PCI WinModem ---hüstel hab ich abgeschrieben) gefunden wird mich per Email, bzw per shell abfragbar informiert. Also die universielle Lösung **g** Ich glaube diesen Wunschzettel hätte ich etwas füher beim Weihnachtsmann abgeben sollen, für 2004 wird selbst der dies nicht mehr hinbekommen. Aber vielleicht 2005? Gruss rob PS: Ich kenn den Spruch von Kästner, "Es gibt nichts gutes, außer man tut es". Jedoch zeigt nichtzulezt die Geschichte von Newpedia vs. Wikipedia, das es sich lohnt nicht nur blind an etwas zu arbeiten, sondern ein möglichst effizientes System zu entwerfen. Aber auch ein einfach "losbasteln" kann nicht schaden ;)
