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
Attachment:
signature.asc
Description: OpenPGP digital signature