Hallo :-) > Den Parser "script-cache search" hatte ich doch eh angeregt.
Das ist generell eine gute Idee - aber das wird sehr aufwendig werden :-) >>>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. In dem Fall kann man auch gleich als .deb die Pakete anbieten, das kommt auf den selben Effekt hinaus und ist schon vorhanden. Nur wenn ich an die Vielzahl von Skripten, Code-Snippets denke, dann wird es sehr schnell sehr viel was verwaltet werden muss (denn das setzt alles eine gewisse Pflege voraus). >>Eine Suche in einem Wiki hat den selben Effekt. Nur dort kann man natÃrlich besser stÃbern ;-) > Ok, aber wie finde ich ohne Webbrowser mit einem installierten Debian > System diese mbox oder maildir Pakete von der shell aus? Lynx? Links? Aber da bin ich schon dabei, richtige Pakete anzufertigen, wenns was neues gibt meld ich mich... > IMHO ist dies inkonsistent - Arbeitsschritte, die mit Programmen > funktionieren sollte genauso mit Dokumentationen, Skripten, > Beispielkonfigurationen funktionieren. Dann bleibt nur .deb :-) > 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. Ack ;-) > FÃr Binarys und Source gibt es .deb dpkg und apt > fÃr Skripte, Beispielconfigs, Tutorials, Knowledgebase fehlt etwas. Subversion? Mit Namen der Repositories die dem Skript entsprechen und eine einheitliche Struktur aufweisen > - eine 100% Shell Nutzung zulÃÃt Subversion :-) Und eventuell ein Wrapper-Skript drumherum, dass die Bedinung 'aptiger' macht. > - eine effiziente Suche zulÃÃt Wrapper-Skript :-) > - mit wenig lokalen Speicher arbeiten kann Kommt natÃrlich auf die GrÃÃe der einzelnen Projekte an, aber sollte auch gehen. > - einfach spiegelbar, bzw auf CD packbar ist Eine wget-Kopie des Subversion-Servers... Spiegeln fÃr Development ist vielleicht ein Fall fÃr arch - hab ich mir aber nie nÃher angesehen. > - passive Server (ftp) nutzen kann Eine wget-Kopie des Subversion-Servers - die kann man als Spiegel problemlos lagern. > - Eindeutige und ewige ID verwendet Repository-Namen kann man ja genau so wÃhlen. > - jede Information durch eine Signierung/Hashwert sichert Klarer Fall fÃr GnuPG :-) > 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. Das sind beides Dinge, die man in einem Wiki abbilden kann. Aber ein Wiki automatisch per Skript auf der Kommandozeile zugÃnglich machen kÃnnte etwas schwieriger werden. > 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.... Jepp, alle haben auch einen speziellen Fokus gelegt. IMHO ist ein Wiki fÃr so ein Vorhaben (vielleicht in abgewandelter Form) das ideale, denn es geht ja nicht nur darum, ein Paket mit Skripten/Doku/Configs zu bekommen sondern auch einen Durchblick. Und oft ist es ja auch so, dass man ein Code-Snippet viel dringender braucht als ein komplettes Skript. Aus meiner eigenen Erfahrung heraus, ist ein Wiki eine schÃne offene Umgebung in der man sich austauschen, korrigieren und mitteilen kann, ohne auf ein spezielles Tool angewiesen zu sein. > 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. Also etwas wo Du deine Configs hinterlegen kannst und dann wieder im Falle eines Falles ein Backup hast? Also eine auf eine spezielle Person personalisierte und angepasste Fassung des Dokuments? > 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. Das wÃrde ich nie auf einem Ãffentlichen Server hinterlegen wollen :-) > 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. Das klingt nach einen groÃem Software-Projekt (in klein fÃr unsere Firma habe ich schon sowas in der Art mal gebastelt). Vielleicht bietet sich wirklich eine auf Subversion basierende LÃsung an, denn wenn ich die Skripte in einem Repository halte und eine feste Struktur dazu, dann kann ich auch automatisch Webseiten zum Durchsuchen, stÃbern und finden generieren und gleichzeitig entsprechende Versionen per Kommandozeile vom Wrapper-Skript holen lassen. > Aber vielleicht 2005? Mal sehen *fg* > Aber auch ein einfach "losbasteln" kann nicht schaden ;) Sollten nur schauen, was alles gewÃnscht wird und was umsetzbar ist :-) Ein Wiki spende ich: http://debian.dafuer.de/twiki/bin/view/Main/WebHome Dort lÃuft jetzt ein TWiki, etwas schÃner als das phpwiki. Und einen Subversion-Server kann ich auch gerne beisteuern, daran solls nicht liegen. Cheers und schÃnes Wochenende, Jan
signature.asc
Description: OpenPGP digital signature
