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 ;)
