Veni, Vidi, VISA

Ich habe unter /eigenes/tmux.html mal einen Userguide für tmux geschrieben und hochgeladen. Fragen/Wünsche/Anträge via Mail oder hier in den Kommentaren.

Aso.. bevor ich es vergesse: ""Userguide" zu tmux " vollständig lesen

Ich hab gerade die Anleitung von/zu vsftpd auf den neusten Stand gebracht (zu finden unter http://strcat.de/eigenes/vsftpd.html). Einige Passagen sind noch nicht übersetzt, sondern via Copy&Paste aus der Manpage kopiert worden. Sollte also jemand mal nichts zu tun haben..

Unter http://strcat.de/eigenes/vsftp.html habe ich vor Jahren mal ein Tutorial ueber vsftpd verfasst und das bis ~2006 auch relativ aktuell gehalten. Mittlerweile ist das aber hoffnungslos veraltet (Stand: vsftpd 2.0.3 / Aktuell: 2.0.6). Wenn ich mal etwas mehr Zeit habe, werde ich die Anleitung auf den neusten Stand bringen und ggf. anders strukturieren (insbesondere den Abschnitt Parameter der Konfigurationsdatei.
Wenn jemand (realisierbare!) Vorschlaege, Wuensche, Antraege, .. hat, dann immer her damit. Das gilt nicht nur fuer die Strukturierung, sondern auch fuer den Inhalt.

Diese Woche hatte ich einen interessanten Mailaustausch mit einem Newbie, der seit einem Jahr Linux nutzt und Fragen zu meinen Konfigurationsdateien hatte. In einer Mail hatte ich "Free software: Contribute nothing, expect nothing." als Signatur stehen und als Antwort kam von ihm

Schön und gut, aber wie soll ich freie Software unterstüzen? Ich kann nicht programmieren und hab auch nicht soviel Kohle das ich was spenden könnte.

Jetzt muss ich dazu sagen, dass mir persoenlich ein User der "zugibt" nicht programmieren zu koennen lieber ist, als 100 User die meinen sie koennten es, aber egal. Man muss nicht programmieren koennen um OpenSource zu unterstuetzen. In der Mail mit dem Subjekt Greyday? Eher ein Tag zum Feiern. von Kristian Koehntopp steht wie er "zu Linux gekommen ist". Es gibt etliche Moeglichkeiten wie man OpenSource unterstuetzten kann.

Dokumentationen:
Jeder User kann Dokumentationen schreiben! Wichtig dabei ist nur, dass sie uebersichtlich und technisch korrekt sind. Mit "$foo herunterladen und installieren!" kann ein Anfaenger nicht sonderlich viel anfangen. Schreibt den genauen Vorgang; am besten fuegt die von euch eingegebenen Kommandos via copy&paste ein und erklaert sie kurz.
Ueberlegt euch was ihr dokumentieren wollt. Niemand braucht die 2342. Erklaerung wie man ein rpm-Paket installiert oder wie man ein tar.gz-Archiv entpackt; sowas sollte allenfalls der Vollstaendigkeit halber in einer Anleitung erwaehnt werden. Sorgt dafuer das der Text uebersichtlich bleibt und hebt wichtige Passagen hervor (pre, blockquote, ..). Korrekturlesen! Das ist besonders bei technischen Dokumentationen unverzichtbar! Einige User arbeiten mit copy&paste; wenn ein Leser nach diesem Prinzip vorgeht, sorgt ein Fehler in einer Kommandozeile u. U. dafuer, dass er entweder sein System schrottet oder die Anleitung als "unbrauchbar" einstuft (auch wenn der Rest korrekt ist).
Wenn man eine Dokumentation schreibt, sollte man dazu sagen auf welches System sich nachfolgende Anleitung bezieht oder ob sie "Distributionsunabhaengig" ist. In beiden Faellen sollte man angeben welche Programme benoetigt werden, welche Programmversionen eingesetzt wurden und woher man diese beziehen kann (bzw. wie man diese ggf. installiert). Gebt dem Leser die Moeglichkeit euch kontaktieren zu koennen. Auch Dokumentationen ziehen Support nach sich. Man bekommt immer wieder Mails in denen Fragen gestellt werden oder man auf Fehler aufmerksam gemacht wird. Interessant ist auch noch der Text Irgendwann wie Stevens schreiben aus der Datenschleuder des CCC. mikas Artikel Die Gesetze von OpenSource... sind ebenfalls lesenswert (auch wenn sie auf eine andere Zielgruppe bezogen sind).

Konfigurationsdateien/Scripte:
Dokumentiert und veroeffentlicht die Konfigurationsdateien der von euch eingesetzten Programme. Je ausfuehrlicher, desto besser. Aber auch ein kurzer Kommentar traegt zum besseren Verstaendnis bei. Innerhalb von Scripten sollte man function()en aussagekraeftige Namen zuweisen. Mit function hurga() { perl -ne 'while ( m/"((www|ftp|http):\/\/.*?)"/gic ) { print $1, "\n"; }' $* } werden die wenigsten User was anfangen koennen, waehrend ein

# PERL: Get all www/ftp/http- URIs of a given file

function getlinks() { perl -ne 'while ( m/"((www|ftp|http):\/\/.*?)"/gic ) { print $1, "\n"; }' $* }

mehr oder weniger selbsterklaerend ist.
Gleiches gilt auch fuer Scripte. Wenn ihr Scripte veroeffentlicht, dann spart nicht mit Kommentaren; Kommentare sind genauso wichtig wie uebersichtlich formatierter Quelltext. Und bevor elise mich jetzt wieder schimpft: Ja. Auch wenn das notwendig ist halte ich mich selber selten daran. Kommentierter und uebersichtlich formatierter Quelltext erleichtert das Lesen und Verstehen erheblich.
Der groesste "Fehler" der bei Shellscripten gemacht wird, ist das ueberfluessige Benutzen einer Shebang-Zeile, welche die Bash aufruft. Die Bash ist nur ein Standard; nicht *der* Standard! Oder - um genauer zu werden - die Bash ist nur auf GNU/Linux - Systemen die Standardshell (und selbst hier nicht auf allen Distributionen). Ein Shellscript, welches /bin/bash als Interpreter nutzt, wird unter Free-/Open-/NetBSD, AIX, IRIX, SunOS und HP-UX nicht funktionieren. Verzichtet also wenn moeglich auf #!/bin/bash als Shebang und verwendet stattdessen #!/bin/sh. /bin/sh ist naemlich auf jedem Linux/Unix vorhanden.

Mailinglisten/Foren:
Tragt euch in den offiziellen Mailinglisten ein und/oder registriert euch in den Foren. Dort koennt ihr Fragen stellen (nachdem ihr die FAQ bzw. HowTo RTFM gelesen habt) und anderen Usern bei Problemen helfen. Je mehr Arbeit ihr den Developern abnehmt, desto mehr Zeit haben diese ihre Software weiter zu entwickeln. Anfaengern hilft man am besten, wenn man ihnen Hilfe zur Selbsthilfe gibt. Ein "Lies Dir das Handbuch durch (http://link.zum.handbuch/abschnitt.html)!" ist sinnvoller als eine Step-by-Step - Anleitung.
Man sollte sich auch darueber im Klaren sein, dass eine "Step-by-Step" - Anleitung u. U. andere User faul werden laesst. Wenn sie wissen wer ihnen das Denken abnimmt, werden sie mit Sicherheit nicht selbst anfangen Eigeninitiative zu entwickeln. Diverse Kiddies reagieren zwar etwas .. komisch darauf aber solche Reaktionen sind Gott sei Dank nicht die Mehrheit. Schweigen mit arrogantem Unterton ist manchmal die beste Antwort.

Push it, don't hype / Werbung:
Jeder hat sein favorisiertes Programm; nur sollte man nicht davon ausgehen das andere User die gleichen Vorlieben haben. Menschen Programmieren und Menschen machen Fehler; ergo sollte man auch eingestehen koennen, dass $FOO auch Vorteile gegenueber $BAR hat. Linux/Unix - User finden immer wieder einen Grund einen Holy war zu beginnen (Es wurde zwar schon ueber jedes Thema einer gefuehrt, aber egal. Da gehts ums Prinzip.); laecherlich wird es erst, wenn ein Teilnehmer die Scheuklappen aufsetzt und entgegen aller Argumente "sein" System verteidigt.
Aehnliches gilt auch fuer Werbung; es spricht absolut nichts dagegen wenn man fuer "seine" Software Werbung macht, jedoch sollte man dann auch die Nachteile auflisten, damit andere User auch wissen ob das Programm fuer sie geeignet ist. Meine Meinung ueber Debian sollte hinreichend bekannt sein, aber Debian steht im Gegensatz zu dem Grossteil der Benutzer wenigstens dazu nicht perfekt zu sein.

$ cd /usr/pkgsrc/lang/php5

$ make PKG_OPTIONS.php="fastcgi" install clean ; make clean-depends

$ cd /usr/pkgsrc/www/lighttpd ; make install clean

$ $EDITOR /usr/pkg/etc/lighttpd/lighttpd.conf

mod_fastcgi auskommentieren, bin-path in 

"bin-path" => "/usr/pkg/libexec/cgi-bin/php" in fastcgi.server aendern; 

anschliessend lighttpd=YES in die /etc/rc.conf reinschreiben und lighttpd starten

$ /etc/rc.d/lighttpd start

Extremst quick&dirty!

$ /usr/ports/infrastructure/build/out-of-date > ~/ports

$ for i in `awk '{print $1}' ports | cut -d, -f1`; do (cd /usr/ports/$i && ls); done

Probleme gibt es nur bei Ports, denen zusaetzliche Flavors uebergeben wurden. Dort sieht die Zeile dann naemlich nicht so

editors/vim

sondern so

editors/vim,huge,no_x11,perl

aus.
Man koennte solche Zeilen jetzt heraus'grep(1)'en und anschliessend die Spalten mit awk(1) vertauschen, allerdings kann man dann gleich ein Perlscript schreiben.

Ich hab vorhin mal ein Plugin installiert, das Favatars und Gravatars anzeigt. Gravatars sind vergleichbar mit X-Faces in Mails und im Usenet. "Gravatar/Favatar - Plugin" vollständig lesen

Gestern hab ich auf meinem Dyndns-Host mal just for fun Serendipity 1.1-alpha7 installiert und das erste was mir aufgefallen ist, war das man die Plugins via Drag&Drop mit der Mouse verschieben kann. Technische Details dazu gibts in Garvins Blog.
Als ich es das erste Mal ausprobiert hab war mein erster Gedanke ein "Yep. Total eklig.", aber es hat auch seine Vorteile. Wenn man naemliche mehrere {Event,Sidebar}-Plugins verwendet, kann man diese sehr einfach und komfortabel zwischen den vorhandenen Sidebars an eine beliebige Position verschieben. Wer das nicht haben will, muss lediglich JavaScript deaktivieren oder in der include/tpl/config_personal.inc.php den Array eyecandy suchen und den default-Wert von true auf false aendern. Genaueres steht aber im Blog von Garvin.

Linux is Not Windows || Linux ist nicht Windows

---

Nein. Nicht so umstaendlich wie "Firefox starten -> http://javimoya.com/blog/youtube_en.php -> Speichern unter". Schneller und einfacher..
http://marginalhacks.com/index.0.html#myfilm herunterladen, ausfuehrbar machen (oder mit Perl als Interpreter starten) und anschliessend ./myfilm "http://www.youtube.com/watch?v=2EE3a0DQyIk" und sich die *.flv ansehen; alternativ dazu kann man folgende function() verwenden

vlf2mpeg () {

        if [[ -z "$1" || ! -e "$1" ]]

        then

                echo Usage: $0 VideoFile.vlf

        else

                ffmpeg -i $1 -ab 56 -ar 22050 -b 500 -s 320x240 ${1:r}.mpeg

        fi

}

und man hat danach eine *.mpeg. Its evil.. isn't it?!