- usb-storage - Anschluß einer USB-Harddisk (x86-pc-2.4.22)
Die in der üblichen Sorgfalt von Linux-Entwicklern zusammengestellte Kernel-Dokumenation
gibt auch zu diesem Thema erwartungsgemäß rein garnichts her. Darum, ganz kurz:
Der Kern muß mit Unterstützung sowohl für scsi als auch usb ggf
neu erzeugt ("compiliert") werden. Das Modul 'usb-storage' rsp. die enspr. Massenspeicher-Option
in der Linux-Konfiguration richtet eine SCSI-Schnittstelle zur USB-HD ein. Dafür wird
z.B. im Fenster von 'make menuconfig'
<SCSI SUPPORT -> SCSI DISK SUPPORT>
aktiviert. Für die USB-Schnittstelle genügt
<USB support –––> Support for USB –> USB Mass Storage support>.
Sofern z.B. ATAPI/IDE CD-ROM-Laufwerke vorhanden sind, aktiviert man ggf. auch die SCSI-Emulation mit
<ATA/IDE/MFM/RLL support –––> IDE, ATA and ATAPI Block devices –> SCSI emulation support>,
um einheitlichen Zugriff zu ermöglichen. Beim Start richtet der Kern dann eine
'normale' SCSI-Harddisk ein, mit Namen nach dem Muster "/dev/sd{a,b,c..}{1,2,3...}".
CD-ROM-Laufwerke werden "/dev/sr0" &c.
Nebenbei, (meine) Versuche, mit welcher Konfiguration/Option und in welcher plausiblen Kombination
davon auch immer, den Linux-Kern von einer usb-Platte aus zu starten, sind gescheitert. Es fand sich
nirgends in den Linux-Dokumenten auch nur der geringste Hinweis darauf, ob und ggf. wie sowas
überhaupt möglich ist.
- Wenn im X-Windows
einmal die Knöpfchen und Schleifchen von Programmen jenseits der Ränder verschwinden, kann nicht
einmal mehr die Lage des Fensters selbst verändert werden. Mist! wie Bernd so treffend weiß.
Jedoch, mit gedrückter (linker) ALT-Taste und der linken Maus-Knipse geht's dann doch! - sofern die
vorgegebene Tasten- und Maus-Konfiguration nicht verändert wurde.
Dank dem ex-'miserable man', der dies mitgeteilt hat...
- Kurz und praezis das Wichtigste von Perl.
Private mail, sicher auch anderen nützlich, drum (mit Zustimmung des Autors) hier greifbar gemacht.
- Es ist immer gut, die jeweils mitgelieferte Programmdokumentation auch
zu lesen.
Warum? - Offensichtlich!
Wenn nicht: Wieso sollte irgendwer sich die Mühe machen, ein Programm extra
zu beschreiben, wenn das unnötig wäre! Das ist keine Arbeit, die
besonders honoriert wird, sie wird gemeinhin auch anwenderseits nicht sonderlich
anerkannt, drum wird diese Last nur aufsichnehmen, wer das für absolut
unerläßlich hält...
Deutlicher:
Unangenehme Folgen und Ereignisse, die einen sich völlig unverständlich und gänzlich
unbegründbar für maßgebend haltenden Teil "der Öffentlichkeit" gelegentlich in
helle Aufregung versetzen, belegen das: Zu den Lächerlichkeiten des "Jahres 2000" gehört der
unter heftigem Gekreisch im Mai 2000 entdeckte angebliche email-Virus "I Love You" als
prägnantes Beispiel dafür, wie anscheinend auf das geistige Stadium von Kleinkindern reduzierte
Computerbenutzer, die alles Unbekannte anpatschen und daran herumnuckeln müssen, Opfer der eigenen
Ignoranz wurden. Besagtes Teil war ein in Klartext - und damit sicherlich nicht "Virus" - verfaßtes
ausführbares Script, jedermann ersichtlich, der sich die geringe Mühe gemacht hat, das als
"mail", also "Post", d.h. "Text" übermittelte Teil von dort aus anzusehen, wo es hingehört,
nämlich einem Text-Editor oder -Betrachter. Soviel zum "Lesen". Wer solches Zeug blindlinks
"ausführt", mag ja durchaus (und zurecht) an der eigenen Blödheit verzweifeln, aber
gefälligst, bitte, mit seinem Gejaul nicht auch noch in der Öffentlichkeit lästig werden...
Kleiner Tip zum Ansehen von Texten:
less filename
holt den Text in ein Betrachtungsprogramm, das in anderer Aufrufform auch die
Ausgabe beliebiger Kommandos zum Ansehen festhält:
programm | less
oder mit Zusammenfassung von Standardausgabe und Fehlermeldungen:
programm 2>&1 | less
Andererseits, Programme ohne hinreichende Dokumentation sind wertlos, nicht allein
dadurch, sondern auch durch die meist gleichermaßen "sorglose" Gestaltung ihrer selbst. Es hat nach
meiner Erfahrung keinen Sinn, mit sowas auch nur die geringste Zeit zu vergeuden.
Und auch das noch:
Wenn das von der Distribution mitgelieferte wundervolle Dokumentationssystem auf
einmal seinen Dienst versagt und im X-Windows dem Browser keine HTML-Texte mehr
liefern will, kann das an ungeeigneten Zugriffsrechten zum "home"-Verzeichnis
des betr. "user"s liegen, rsp des dort vorhandenen Unterverzeichnisses "public_html":
echo ${HOME}
schreibt den betr. Namen hin. Letzteres darf nur vom "Besitzer" - das ist
besagter "user" - schreibbar sein. Man kann das z.B. einstellen mit
chmod 755 public_html
Da ein CGI-Script ausgeführt wird, sind die Sicherheitsrichtlinien hier
besonders streng. Diese Scripte liegen meist in /var/lib/www/ oder in einem
Verzeichnis mit ähnlichem Namen. Der Pfad dorthin muß ebenfalls
"sicher" sein, in diesem Falle soll er nur durch "root" schreibbar sein, und
lesbar für Gruppe und Andere.
Vorsicht bei Änderungen, an besten vorher die alten Einstellungen
notieren.
-
"Linux Anwender-Handbuch"
alte Auflage (5.0) der deutschsprachigen Systembeschreibung, enthält manche
Details, die in den späteren Auflagen fehlen, u.a. Hinweise zum Compilieren
des Linux-Kerns. Empfiehlt sich als Ergänzung zur jeweils jüngsten
Auflage, die direkt von Lunetix
erhältlich ist - 7.0(?).
- Daneben wird anfangs ein weiterer deutschsprachiger Text,
LinuxSchulung.ps
(Quelle: ftp://sunsite.unc.edu im
Verzeichnis /pub/Linux/docs/linux-doc-project/ unter o.g. Namen, lesbar in X-windows z.b. mit gv oder ghostview)
sicher von großer Hilfe sein. Zum Inhalt gehört auch eine umfangreiche Liste Internet-Adressen von
allgemeinem Nutzen. Im zugehörigen lsm-File ("Linux Software Map") heißt es u.a.:
Title: The Austrian Linux Training Document
Version: 0.11.1-Draft
Entered-date: 1999-09-24
Description:
This Document is written in the austrian language (a german "dialect" ;-)) and
shall help a beginner to become familiar with Linux and the GNU Tools. It
describes commandes, gives examples, introduces into administration and system
knowledge -- and urges the doing of the reader :-).
It also contains demo-progs to show some of the internals of tools and a list of
useful links to more detailed infos. In other words: From beginner to expert ;-).
Author:
m.sejkora@online.edvg.co.at (Martin Sejkora)
Maintained-by:
m.sejkora@online.edvg.co.at (Martin Sejkora)
Primary-site:
metalab.unc.edu /pub/Linux/docs/LDP
Copying-policy:
OPL (http://www.opencontent.org/opl.shtml)
Feel free to request the \LaTeX{} sources from the maintainer.
Im Text wird u.a. auf den Kern 2.2.11 Bezug genommen, zwar mittlerweile auch nicht
mehr brandneu, jedoch, zumal die bisherigen (9/02) 2.4-Versionen an vielen Stellen
ein eher komisches Bild des Jammers abgeben, immernoch gut brauchbar und offenkundig
einer der wenigen Texte, die nicht aus irgendwelchen längst hoffnungslos
veralteten Ur-Versionen zusammengeklaubt sind...
Nebenbei, als restlos sichere Referenz ist nicht einmal die aus den aktuellen
Kernel-Quellen erzeugte Dokumentation zu gebrauchen - welche es mittlerweile
immerhin gibt. Mit wenigen Ausnahmen dokumentieren Kernel-"Programmierer"
grundsätzlich nicht, denn ihr Tun ist fehlerfrei und ihr Leben währet
ewiglich. In heiklen Fällen hilft darum nur die Untersuchung der
betr. Quellenpassage selbst.
-
Ein wenig grundlegende Übung in trivialem Englisch wird sich nicht vermeiden lassen,
wobei der Anspruch zwar gering ist, aber doch deutlich über dem aus Werbung, Journaille oder
Politik gewohnten eher peinlichen Niveau liegt: Nahezu alle wichtigen Texte zum Linux sind in
englischer Sprache - rsp dem, was u.s.-Amerikaner für sowas zu halten scheinen - verfaßt.
-
Dateienverlust z.B. durch versehentliches Löschen ist beim "ext2"-Filesystem des Linux
ein zunächst kaum lösbares Problem - das einzige zwar, denn sonst ist es von kaum
zu übertreffender Sicherheit, so etwa werden anderweitig zerstörte Files oft automatisch
repariert, ohne daß es überhaupt bemerkbar wird. Auch sind Varianten in Vorbereitung,
die diesem Manko abhelfen. Bis dahin kann eine Filesystem-Erweiterung helfen:
"undelete filesystem", derzeit (5/2000) "undel095", verfügbar bei
sunsite.unc.edu, tsx-11.mit.edu, reks.uia.ac.be (primary site)
Ein anderes - weit zuverlässigeres - Programm liegt in Quellen vor:
undelete-0.6, von/bei Lunetix.
Beide mehr als Behelf anzusehen; mit Linux 2.4. sind bessere Alternativen im Kommen ("journaling filesystem").
- mc
Um überhaupt erst einmal anfangen zu können, braucht man irgendeine möglichst bequeme
Übersicht über die vorhandenen Dateien zusammen mit dem ebensoleichten Zugriff darauf. "mc"
(Midnight Commander) ist ein "File-Browser"
nach Art des "Norton Commander", der alle Erwartungen erfüllt, von einfachster Bedienbarkeit bis hin
zu verwickelten Operationen an Dateigruppen, dem Editieren von Klartext- und Binaerdateien, u.v.m. Mehr
Kommentar erübrigt sich, es hat sich bei mir über etliche Jahre hinweg bestens bewärt.
JEDOCH: Seit "mc" in die GNU/FSF/GNOME-Entwicklung übergegangen ist, sind die Ergebnisse - wie bei
der Software der FSF ganz allgemein leider allzuoft - mitunter weniger beeindruckend. Eine gute Alternative
bietet das Mail- und News-Programm PINE
(Programmquellen) mit "pilot" und dem
zugehörigen Editor "pico" an, die ebenfalls in der Linux-Console so gut wie im X-Windows System
zu gebrauchen ist.
Nebenbei, falls jemandem die Farben im mc-Editor ebenso auf die Nerven gehen wie mir, hier eine Korrektur
- echo -e "\e]P40f0f0f\e]P0000038\e]P3c8c800"
womit aus dem aufdringlichen blau ein 'helles freundliches Schwarz' wird, 'Schwarz' wird ein wenig heller,
in Richtung 'Blau', und das von irgendeinem Farbenblinden (mehr oder weniger, oft nur schwach sichtbare)
braun in den Kern gemurkste 'Gelb' der Konsole wird tatsächlich gelb, allerdings geht dann das feine
'braun' vollends verloren...
- "Open Source Software", "GNU"
ist eine Antwort auf die seitens gewisser Software-Erzeuger stur und immer wieder versuchten
Übergriffe auf Rechner- und vor allem Informations-Systeme der betr. Betreiber - muß
aber leider auch als Warnhinweis gesehen werden (s.u.):
Die "GNU-Lizenz" der FSF ('Free Software Foundation') beschreibt ein
Rechtsgefüge für freie und offengelegte Software und sichert eben diese Freiheit ab
(samt dem Schwachsinn U.S.-amerikanischen "Rechts"- und "Sprachverständnisses").
Selbstherrliche, im Wahn unantastbarer Überlegenheit befangene "Programmierer" sind ein abgelaufenes
Modell, das mangels tragfähiger Arbeitsauffassung kläglich versagt hat. Der Anspruch, daß
ein Anwender sich deren unfehlbarer, keinerlei Kontrolle oder gar wirksamer Haftung unterworfenen Kunst
auszuliefern habe, ist allein schon angesichts allgemeiner Vernetzung längst restlos dahin. Wo jeder
Rechner ohne die Möglichkeit sicheren(!) Schutzes gegen das Eindringen in Daten- und Informationssysteme
durch unkontrollierbare Asoziale, Veranstaltungen der Art "Microsoft", und Regierungsinstitutionen ist
(die Recht und Gesetz längst schon als Handelsware der Beliebigkeit des jeweils Gewaltausübenden
unterworfen haben), dürfen Programme nicht geeignet sein, gegenüber dem Betreiber verborgene
Aktionen auszuführen. Die notwendige Kontrollierbarkeit setzt unabdingbar vollständig
offengelegte Programme voraus.
"GNU" steht zunächst einmal für rein garnichts, seitens der FSF erklärt man wohl, daß
'GNU Nicht Unix' sei, aber was es denn nun ist, wissen diese originellen Schlauköpfe
offenbar selber nicht. Aus damit zusammenhängenden Darbietungen läßt sich aber immerhin recht
sicher schließen, daß es einerseits auf besagte Lizensierungsform abhebt, und daß zum andern
die FSF als Organisation, die solche Software vertreibt, und die diese Entwicklung maßgeblich beeinflußt,
gemeint sein mag. Deren federführender Vertreter, ein gewisser R.Stallmann, benimmt sich mittlerweile kaum
weniger hochfahrend als sein Gegenspieler Gates, dennoch hat er auf die "Freie Software" keinerlei übergeordnete
Rechte, ebensowenig, wie ausgerechnet er als maßgebliche Bewertungsinstanz für irgendetwas gelten kann.
So sind seine "Goldenen Worte", etwa endlose Tiraden bezüglich des "KDE",
ebenso unerheblich, wie die Arroganz unverständlich ist, mit der er meint, über die berufliche Tätigkeit
anderer befinden zu dürfen.
Seit rund zwanzig Jahren faselt besagter Stallman auch noch von einen eigenen "GNU"-Betriebssystem, dessen
Name "Hurd" sei - welches allerdings noch immer unfertig ist und (zurecht) unbeachtet dahinkümmert.
So behauptet er ersatzweise einfach mal, nicht "Linux" sondern "GNU", äußerstenfalls "GNU/Linux",
sei das Betriebssystem, "Linux" aber nur ein für sich genommen wertloser Systemkern. Neben der
rein sprachlichen Deutung ("GNU", s.o.) liegt erst recht die konkrete Bewertung solcher Rede auf der Hand...
Mit dem immerhin teilweise nutzbaren "GNOME", einem traurigen "KDE"-Abklatsch, verhält es sich
ähnlich, insbes. depressiven Gemütern wird dessen Verwendung dringend abzuraten sein.
Bedauerlich auch, daß ein großer Teil gerade der Software, die unter Copyright jener "FSF"
rsp "GNU" selbst geht, aufällig plump programmiert, jämmerlich dokumentiert, und lieblos bis
konfus dargestellt erscheint; Beispiel ist nicht nur das grauenhafte "info"-System, mit dem man aus
welchem Grunde auch immer - glücklicherweise vergeblich - versucht, die bewährten "man-pages"
zu verdrängen. Ein praegnanter Auszug ('info stabs'):
* What ends the procedure scope? Is it the proc block's `N_RBRAC'
or the next `N_FUN'? (I believe its the first.)
"Programmdokumentation" als Glaubensbekenntnis? - leider kein Einzelfall.
Ebenso unangenehm die Tatsache, daß auch wesentliche Grundlagen zur Programmerzeugung unter Kontrolle der
FSF rsp. deren Ableger entwickelt werden, und daß diese "Entwicklung" ein geradezu klassisches Beispiel
des "management by accident" darstellt. Verfolgt man etwa den verworrenen Gang der "Entwicklung" in den betr.
news-Gruppen und mailing-Listen, erscheint es fast als unergründliches Mysterium, wenn z.B. mit den
"binutils" überhaupt Brauchbares zustande gebracht werden kann.
Und so stehen "FSF" und "GNU" neben der begrüßenswerten Absicht und dem großen
positiven Einfluß in der Vergangenheit zugleich eben auch für Software, die sicherheitshalber schon
vor der Übernahme in das eigene Rechnersystem immer erst gründlichen Prüfungen unterzogen werden
sollte.
Nicht zu vergessen die einleitende Passage der Lizenz: This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
welch letzter Halbsatz ein vorhandenes Ergzeugnis den noch unbekannten Bedingungen künftiger Varianten
einer Lizenz unterwirft, d.h. ein Autor liefert auf diese Weise seine dermaßen lizensierte Weichware
bedingungslos allen willkürlichen Eintscheidungen der Eigner jenes Textes (der FSF) aus! Natürlich
ist dergleichen vollkommen inakzeptabel, es sei denn, man wollte seine Software der FSF uneingeschränkt
zur freien Verwendung überlassen - kann man, ist auch schon geschehen; daß aber eine solch
zweifelhafte Passage in den Lizenztext aufgenommen wurde, läßt unschöne Absichten erwarten.
Darum sollte man wenigstens diese Blankovollmacht betreffs einer erst noch zu verfassenden Lizenz
ausdrücklich ausschließen, wie z.B. beim Linux-Kern.
- {paketname}.lsm
enthält im allgmeinen eine kurze Beschreibung des Programmzwecks. Weiter sind darin ggf.
erforderliche Zusatzprogramme aufgeführt, andere Systemvoraussetzungen sowie Autor und der
Ort, an dem die Original-Quelle erhältlich ist. Sämtliche Programme in der schon klassischen
"Sunsite"-Sammlung werden von einer derartigen
Kurzdokumentation begleitet.
Es fällt auf, daß viele Autoren ihre Werke für derart prominent (oder wertlos?!)
zu halten scheinen, daß sie sich weder der Mühe unterziehen, ein "..lsm"-File anzulegen,
noch im "README" oder an sonstwie plausibler Stelle wenigstens einen kurzen Hinweis dazu aufnehmen,
was denn eigentlich der Zweck ihres ach so einzigartigen Erzeugnisses sein soll. Mein Rat wäre,
dergleichen nicht weiter zu beachten, erfahrungsgemäß der Mühe nicht wert.
Sonst:
Hier hilft es oft, sofern man immerhin wenigstens den Namen erfahren hat, unter dem es aufzurufen
ist - selbst das wurde gelegentlich schon für entbehrlich gehalten (u.a. "Star-Office")
- diesen mit der Option "-h" oder "--help" auszuführen (durch Hinschreiben und ENTER):
programmname --help
was nebenbei und insbes. wenn ein "-v" o.dgl. fehlt, evtl. auch die Version anzeigt.
Der entnervenden Sucherei läßt sich vorbeugen, indem man die (Hand-)Installation
immer mit einem kleinen Umweg durchführt, der alle laufenden Meldungen aufzeichnet:
./configure 2>&1 | tee LOG.c
make all 2>&1 | tee LOG.m
make install 2>&1 | tee LOG.i
oder bei der Paketinstallation:
dpkg -i paketname 2>&1 | tee paketname.log
In "paketname.log" findet man dann (meist) alle nötigen Namen und Verzeichnisse, die
sonst schnell am Bildschirmrand unwiederbringlich verschwinden. "dpkg" ist das Installationsprogramm
der "Debian"-Sammlung. Entsprechend läßt sich mit anderen derartigen Programmen
verfahren (z.B. "rpm"), oder bei der Standardinstallation via "tar", etc.
Beschreibungen finden sich gelegentlich auch in /usr/lib/(programm), /usr/local/lib/(programm)
oder irgendwo in /usr/shared oder /usr/local/shared. - Soviel zum "file system standard"...
- Script
heißen als Programm ausführbare Textfiles. Beispielsweise das nach dem Compilieren
oft verlangte "ginstall" läßt sich ganz einfach und ohne besondere Hilfsmittel
folgendermaßen erzeugen: echo '#! /bin/sh' > ./ginstall
echo '/usr/bin/install -bVt ${*}' >> ./ginstall
chmod g+rx,u+rwx ./ginstall
(Für "echo" sind in diesem Falle nur die Hochkommata (') geeignet!) Hiermit wird zunächst
die Datei "ginstall" - überschreibend - erzeugt, dann in die erste(!) Zeile das Programm
eingetragen, das diese Datei seinerseits als Programm interpretieren soll, und schließlich
der eigentliche hier sehr kurze Programmtext, der nichts weiter ist, als der Aufruf eines anderen
Programms mit besonderen "optionen" und Weitergabe sämtlicher an "ginstall" übergebener
Aufrufparameter ("Argumente", auch ggf. mit weiteren "Optionen").
Mit "chmod" wird die Datei zum Schluß für die Gruppe ausführbar und für
den Besitzer zusätzlich schreibbar (z.B. zum Ändern oder Löschen) gemacht.
Alle Script-Programme sind in dieser Weise aufgebaut, wenn auch selten so simpel...
- Die Variablensubstitution der Bash
ist ein überaus vielseitiges Hilfsmittel in Shellscripten, das deren Ausführungszeit
beträchtlich verringern kann. Immer, wo ein externes Programm durch eine Variablenzuweisung
ersetzt wird, entsteht ein deutlicher Zeitgewinn. Ein paar Beispiele:
- function basename1 () { local v;v="${1##*/}";[ -z "${2}" ]&&echo "${v%.*}"||echo "${v%${2}*}"; }
- function dirname1 () { echo ${1%/*}; }
- function extname1 () { [ -z "${2}" ]&&echo ".${1##*.}"||echo "${2}${1##*${2}}"; }
- function sinstr () { [ ${1} != ${1/${2}/} ]; }
|
- basename1 "/path/file-ext.n" "-" => "file"
basename1 "/path/file-ext.n" "/" => "file-ext.n"
basename1 "/path/file-ext.n" => "file-ext"
- dirname1 "/path/file-ext.n" => "/path"
- extname1 "/path/file-ext.n" "." => ".n" => "n"
- sinstr "/path/file.ext.n" "file"&&echo JA||echo NEE => "JA"
|
| 'dirname1' rsp 'basename1' entsprechen 'dirname' rsp 'basename' des Linux, 'extname1' analog. |
- Als Bash Shell-Funktion kann jede eigenstaendig ausführbare
Folge von Anweisungen eingerichtet werden. Eine solche Funktion wird eingeleitet mit ihrem
Namen, einem "()" Klammerpaar und einer öffnenden geschweiften Klammer "{". Der Eindeutigkeit
halber setzt man ggf noch das Wort 'function' davor. Bei eindeutiger Bezeichnung kann das
Klammerpaar "()" entfallen.
# ---- < dot "36#MAUS" 16 > liefert < fe074 > ----
# dot "radix#zahl" radix_aus
# dot zahl radix_out # impliziert dezimale Eingabe
# dot zahl # impliziert dezimale Ein- und Ausgabe
# ---- -------------------------------------------- ----
function dot () {
local num="$((${1}))" radix="$2" sign digit
[ -z "${radix}" ]&&radix=10
result=""
if [ $((num)) ];then
[ "${num}" == "${num#*-}" ]||{ sign="-";num=${num#*-}; }
while [ $((num)) ]
do
digit=$((num % radix))
num=$((num/radix))
[ $((${digit})) -gt $((9)) ]&&digit=$((digit+39))
result=$(echo -en "\x$(printf %x $(($digit+48)))")$result
done
result=$sign$result
else
result="0"
fi
echo
echo $result
}
- MK-allman
Eine Gruppe Scripts; erzeugt speziell zum Lesen mit "pinfo"
ein Verzeichnis der in einem ../man/-Directory vorhandenen Seiten, die dann direkt daraus zu
erreichen sind, sowie die entsprechenden html-Varianten u.a. als Ziel der ergänzenden
Links in den "syscalls"-Beschreibungen.
- html nach ps
Mitunter stört die zerfranste Vielzahl von html-Texten einer Dokumentation und das Ganze
als Postscript-Datei zusammengefaßt mag bequemer zu lesen sein. Hilfestellung gibt dann
das Programm "html2ps", das eben diese Zusammenfassung erledigen kann. Man übergibt ihm
einen html-Text, in dem die zugehörigen Dokumente als Link direkt oder im Verfolg der
bezogenen Stellen verankert sind. Ein Script-Beispiel:
#! /bin/sh
html2ps -C 'bf' -n -R -W 'rL1' -oInhalt.ps Inhalt.html
wait
ps2pdf Inhalt.ps Inhalt.pdf
wait
pdftops Inhalt.pdf Inhalt.ps
Der Umweg über "ps2pdf" und "pdftops" baut auswählbare Seiten in die Postscript-Datei ein,
was mit "html2ps" allein (offenbar) nicht möglich ist, "-n" als Option zur Seitennumerierung
schreibt jene lediglich in den dargestellten Text. Das "pdf"-Format hat den Vorteil, daß neben
brauchbarer Seitennumerierung die html-Links darin ebenfalls aktivierbar sind, und so mag es sinnvoll
sein, die Wandlung bereits nach "ps2pdf" mit der ansonsten im Linux eher unangenehmen pdf-Variante
zu beenden. "pdftops", oder auch die Druck-Option in "xpdf", überschreibt zum Schluß die
ohne wirkliche Seiteneinteilung ziemlich nutzlose ursprüngliche "ps"-Datei mit der numerierten
Variante. Es gibt noch "pdf2ps", das aber nichts taugt, d.h. es produziert viele kaum lesbare Partien
- evtl. systemabhängig.
Allerdings geht "html2ps" außerordentlich unrationell mit dem Speicher um: Eine 4MB Quelle
mit ca 150 Dateien, je etwa zur Hälfte html-Texte und "jpg"-Bilder, brauchte neben ca. 700M
RAM noch (m)eine volle 1 GB swap-Partition sowie 260MB im /tmp-Verzeichnis, um schließlich
den ersten Postscript-Text mit 240M Größe zu erzeugen. Bei unzureichendem Speicherplatz
bricht das Programm ergebnislos ab, bei vollem /tmp-Verzeichnis ohne Fehler-Hinweis! Und die Angaben
nach "-W" interessieren offenbar auch nicht sonderlich (s. "man html2ps").
Alternativen zur Zwischenspeicherung sind nicht vorgesehen. Mit der zusätzlichen Option "-g"
('greyscale') für "html2ps" kann man Farbe und damit je nach Quelle immerhin rund 2/3 an
Speicherplatz und auch ein wenig Zeit sparen.
Wenn denn alles gutgeht: das Ganze dauert...
Andererseits gibt es auch Monstren, z.B. die "libc"-Dokumentation mit ihrer html-Variante in einer
einzigen Datei von 3,5MB Größe, deren Darstellung durch die üblichen graphischen
Leseprogramme (Netscape &c) einen derarigen Zeitaufwand erfordert, daß sie de facto zu nichts
zu gebrauchen sind. Im genannten Beispiel liest der Browser beim Zurückgehen zum vorigen Link immer
wieder die ganze Datei neu ein, sofern nicht gerade passende rückwärtsweisende Links vorhanden
sind. Selbst üppige 'memory chache' hilft da kaum weiter (so etwa das 100-fache der Filegröße
könnte genügen - wenn nicht auch noch 'Graphik' hinzukommt). "lynx"
oder andere Text-Browser sind eine Möglichkeit, die die Verwendung solcher Brocken überhaupt erst
akzeptabel machen, "lynx" etwa ist bereits ab ca 300K Textgröße sehr viel schneller. Oder Lesen
mit "gv" rsp. "xpdf" der nach obigem Muster entsprechend umgewandelten Texte.
- "fd" :
Eine der lästigsten Anfangs-Schwierigkeiten bestand für mich darin, die vielen großartigen
Programme der jeweiligen "distribution" überhaupt erst einmal zu finden, ganz zu schweigen von der
womöglich ja tatsächlich vorhandenen Dokumentation. Der "Copyright"- und "Changes"-Krempel, den
z.B. "Debian" in's doc-Verzeichnis packt, kann zum Stichwort 'Dokumentation' allenfalls als sehr dummer Witz
gelten, völlig nutzlos für den Gebrauch irgendwelcher Programme. Hat man aber wenigstens
den Namen oder auch nur einen mutmaßlichen Teil davon, hilft "find" weiter. Täte es immerhin,
wenn man es denn bedienen könnte. Die man-Seite dazu ist zwar hilfreich, doch auch derart beladen, daß die eigentlichen Anwendungen nur schwer erkennbar werden.
Zur Abhilfe entstand das Shellscript "fd", das eine stark vereinfachte und mit der Möglichkeit zur
Textsuche kombinierte Form von "find" darstellt. Es sucht Filenamen und Textteile unabhängig von der
Schreibweise in allen Verzeichnissen innerhalb des aktuellen oder eines angegebenen Pfades:
Suche im aktuellen Pfad (current working directory, c.w.d.):
fd filename
in einem bestimmten Verzeichnis, ausgehend vom cwd:
fd pfad filename
in einem bestimmten absoluten Pfad, d.h. ausgehend von "/":
fd /pfad filename
ein Textstück in irgendeiner Datei im cwd, hier mit "." bezeichnet:
fd "." "*" "text"
ein Textstück in einer Datei mit teilweise bekanntem Namen:
fd "file*" "text"
D.h. die Syntax ist:
fd [ suchpfad ] filename [ inhalt ]
fehlt der Suchpfad, gilt das cwd;
fehlt die Angabe zum Inhalt, gilt beliebiger Inhalt.
Für alle Angaben gilt, daß sie u.U. in Anführungszeichen <"> eingeschlossen werden
müssen, um die Shell an der eigenen Sonderzeichen-Bearbeitung zu hindern - was u.a. für den Stern "*"
gilt, und das Leerzeichen, wobei ggf. auch noch das betr. Fluchtsymbol (zumeist "\") vorangestellt werden
muß. Hinweise hierzu geben <man grep> und <man bash>.
"fd" benötigt "extname" (beigefügt) aus den "asmutils",
was in diesem Falle aber auch leicht ersetzt werden kann - s. File "fd".
- "hd-mount/hd-umount":
ist ein Script, das automatisch sämtliche im Rechner vorhandenenen und noch nicht zugänglichen
HD-Partitionen mit einem der Filesysteme ext2/ext3 (Linux), umsdos (m*dos) oder vfat (W*DOS) unter jeweils
einem neuen root-Directory "mount"et, d.h. in das Filesystem einreiht - für Linux bis 2.2 sowie Variante
für das dazu incompatible 'mount' aus Linux 2.4.19. Letztere ist die anscheinend einzige gebrauchstaugliche
2.4.-Version (Status bis 2.4.21, und man träumt bereits von 2.6 rsp 3.0...), andere weisen auch in den
Secundaerversionen noch unterschiedliche und schlecht rsp. garnicht dokumentierte und z.T. für die
Filesysteme ausgesprochen gefährliche (ext3 in 2.4.20!) Variationen rsp. Fehler auf, drum erst prüfen!
Ein anderes Script, ebenfalls im Archiv, gliedert ggf. diese Partitionen ebensoleicht wieder aus.
- isa-pnp
Creative's "VIBRA16" Sound-Karte wird vom eigenständigen Programm 'isapnp' einwandfrei und vor allem
richtig erkannt. Die später in den Kern übernommene Version liefert dagegen unbrauchbare rsp.
falsche Daten, aufgrund derer die Karte nicht ordentlich erkannt und das Modul zwar in's System eingefügt
wird, aber nutzlos bleibt. Anzunehmen, daß auch andere Hardware in ähnlicher Weise fehlerhaft
behandelt wird. Selbst eindringliche Hinweise in der Kernel-'Entwickler' Mailingliste blieben unbeachtet,
drum hier eine Schutzmaßnahme, die sich recht gut bewärt hat:
Im File 'modutils' des '/etc/init.d'-Verzeichnisses (oder entsprechendem) wird die Zeile
/sbin/isapnp /etc/isapnp.conf||:
dem eigentlichen Aufruf ('modprobe' o.dgl.) vorangestellt; im Verlaufe der modul-Einbindung werden dann
die richtigen Daten übernommen.
- Compilieren von Programmen
Die große Sicherheit der Linux-Systeme hängt unmittelbar auch damit zusammen,
daß reine Binär-Installationen ganz und gar unüblich sind. D.h., jedes
Programm ist in Gestalt seiner Quelldateien vollständig offengelegt. Mysteriöse
Geheimnisse gibt es darum nicht, und es können - prinzipiell - keine vom Benutzer
unerwünschten Aktionen stattfinden. Genauer, da die Verteiler solcher Programme
damit zu rechnen haben, daß die Quellen von irgendwem immerhin auch verstanden werden,
sind solche Angriffe auf das Benutzer-System sehr unwahrscheinlich.
Das heißt aber auch, daß es sich von selbst verbietet, Programme zu installieren,
die nicht auch in ihren Quellen angeboten werden. Compilieren daraus stellt dann sicher, daß
nicht irgendwelche fehlenden fremden Quellen vielleicht doch noch Dinge enthalten, die in welcher
Weise auch immer ungewollte Aktionen auslösen.
Kontrolle wird dem Anfänger zunächst mangels Kenntnis kaum möglich sein,
die nötige Erfahrung kommt jedoch nur mit der Zeit und wenn er es denn immerhin
(und immer wieder!) versucht.
Von Anfang an besteht aber ein weiterer Vorteil darin, daß dabei
automatisch Varianten entstehen, die das eigene System optimal ausnutzen.
Dies ist zudem im allgemeinen ausgesprochen unproblematisch:
1. Quelle(n) in einem Arbeitsverzeichnis auspacken.
2. "README" und "INSTALL" lesen,
evtl auch die Textausgabe von "./configure --help".
3. "./configure" ausführen.
4. "make" aufrufen, zusätzlich evtl. "make checks" o.dgl.
5. "make install" - Vorsicht, wenn ein Script "install-sh" existiert!
Kurzgefaßt ist das schon alles - fast immer, aber eben darum nun doch ein wenig
ausführlicher:
Man packt die Quellenarchive aus, "name.tar.gz" z.B. mittels
tar -xzpvf /pfad/name.tar.gz
bei "...tar.bz2" gibt man "tar -xIpvf" an oder "j" oder auch mal ein "y" statt des "I" (da gibt's
Unterschiede), nachdem man in ein - ggf. neues - Verzeichnis gewechselt hat, wohin
die Dateien übertragen werden sollen. Als erstes ist es nun ratsam, die Texte
"README" und "INSTALL"
zu lesen - wenn sie denn vorhanden sind, und in verständlicher Sprache. Geben diese
Texte nichts her, sucht man eine Datei
./configure
und führt sie mit der Option "--help" aus (hinschreiben und <enter>-Taste). Wo
sie fehlt, probiert man z.B. "make menuconfig", wenn das scheitert, "make config" oder
"make configure", wenn das auch scheitert, "make". Letzteres jedoch zur Sicherheit nur,
wenn das ganze Paket in einem Verzeichnis ohne "root"-Rechte steht und auch der Benutzer
solche Rechte nicht hat! - Eine "Word-Perfect"-Installation, und der Hersteller "Corel"
ist ja nicht irgendwer, hätte ohne diese Vorsichtsmaßnahme z.B. einmal nahezu
mein gesamtes '/opt'-Verzeichnis vernichtet. Dies zugleich auch als warnendes Beispiel zu
Programmen, deren Quellen nicht veröffentlicht werden (s.o.); nicht jeder, der
vertrauenswürdig scheint, ist es auch, und solche, die selbst lauthals die eigene
Vertrauenswürdigkeit propagieren, sind gerade das im allgemeinen nicht
!
Wenn selbst damit nichts zustandekommt, empfiehlt es sich für den weniger versierten
Benutzer nur, solche Weichware zu verwerfen. Deren Qualität dürfte dann ohnehin
zweifelhaft sein.
Bei den "configure"-Optionen ist es nun eher nützlich, wenn der Text über den
Bildschirm hinausrutscht, denn nur der Schluß ist hier von Belang. Da kann dann sowas
erscheinen wie "--disable-forced-install", und, wo immer dergleichen zu finden ist, sollte es
unbedingt auch angegeben werden. Andernfalls wird mit dem "make" zugleich auch automatisch
das Erzeugnis daraus installiert, ohne daß es vorher geprüft werden könnte!
- Muß mit dem Klammerbeutel gepudert worden sein, wer sich diesen Schwachsinn hat einfallen
lassen! Beispiel GLIBC, bei der die erzwungene Installation zum totalen Desaster, d.h. einem zur
vollständigen Unbrauchbarkeit verdorbenen Gesamtsystem, führen kann. Allerdings
ist gerade der Umbau auf eine neue libc-Version so ziemlich das Heikelste, was sich einem
Linux-System überhaupt antun läßt - einzig die Debian-Sammlung bereitet
hierbei kaum Probleme, und nur mutige und ausdauernde Benutzer sollten sich daran versuchen,
dennoch, diese Compile-Vorgabe war schon ein wenig überraschend...
Vor solcher Probiererei sorgt man dafür, daß das Original-Verzeichnis
wiederherstellbar ist, d.h. man legt ein Archiv davon an, am einfachsten etwa, indem man
das übergeordnete Verzeichnis aufsucht und eingibt:
tar -czpvf archivname.tar.gz verzeichnisname
Falls ein Compile-Versuch mißlingt, kann dann leicht der Ursprungszustand wiederhergestellt
werden mit
rm -rf verzeichnisname
rmdir verzeichnisname
tar -xzpvf archivname.tar.gz
Die Linuxprogramme sind aber keinswegs alle fehlerfrei, so auch "gcc", der C-Compiler,
der durch "make" zumeist aufgerufen wird. Dessen "Optimierung" ist vielfach nur ein
schlechter Witz (wer Assemblertexte zu deuten weiß, compiliere einmal mit "-save-temps"
und sehe sich den erzeugten Unsinn an). Dabei werden je nach Programm auch Processorbefehle
eingefügt, die zum einen völlig unsinnig sind, zum andern im Linux außer im
Kern selbst (und evtl. in Modulen) eindeutig nichts zu suchen haben - die Meldungen "illegal
instruction" oder "segfault" durch das fertige Programm geben einen Hinweis darauf.
Mit "-O2" oder einer niedrigeren Optimierungsstufe geht dagegen im allgemeinen alles gut.
Zu den Mängeln bei der Optimierung bleibt zu bemerken, daß das Ziel des GCC die
Übertragbarkeit von Programmquellen auf unterschiedliche Rechnersysteme ist, wobei der
Optimierung ausdrücklich untergeordnete Bedeutung beigemessen wurde. Das eigentliche
Ärgernis beruht eher auf der Redseligkeit ahnungsloser "Experten", die unverdrossen
von einem so außerordentlich gut optimierenden GCC faseln...
Nützlich kann es sein, auch den Processortypen und was computermäßig für
"architektur" gehalten wird, in die Variable CFLAGS aufzunehmen. Bei einem Rechner mit k6-Processor
trägt man z.B. in /etc/profile die folgenden Zeilen ein
export CC=gcc
export CFLAGS="-O2 -mcpu=k6 -march=k6"
Die Optimierungsstufe -O3 (s.o.) sollte nur nach eingehender Prüfung benutzt werden!
Auch andere Systemdaten können dort aufgenommen werden, da die Ermittlung der richtigen
Werte durch den Compiler auch so ihre Schwächen hat, rsp. mit der zeitgenössischen
Geräteausstattung mitunter restlos überfordert scheint. So 'kann' z.B der "gcc" mit den
Spezifika des K6-Processors (AMD) erst umgehen, seitdem jener soweit veraltet ist, daß
er im Handel nicht einmal mehr erhältlich ist... Näheren Aufschluß gibt u.a.
"info gcc", oder dasselbe mit dem Lynx-ähnlichen Programm
"pinfo" - "info" ist, wie viele der allem
Anschein nach ziemlich hilflos dahinprogrammierten GNU-"utilities", eher ein plumpes Bild des
Jammers aus der computermäßigen Frühsteinzeit.
Bei weitaus den meisten Programmen genügt aber die einfache Aufrufsequenz:
./configure
make
Wenn neben "configure" und "make" auch noch ein "make tests" o.dgl. angeboten wird, geschieht
dies im allgemeinen nicht ohne Grund, und es empfiehlt sich dringend, diese Tests auch wirklich
zu compilieren und ausführen zu lassen. Sollte dann nicht alles ordentlich durchlaufen werden,
ist die abschließende Installation sicher nicht zweckmäßig! Wie auch sonst,
wenn irgendwelche Ungereimtheiten auftreten - "wird schon gutgehn..." gibt es nicht, ebensowenig
Programme, die ihre Fehler selber reparieren!
Auch lasse man sich nicht von somnambulem Gefasel über 'instabile' Programme t&aum;uschen,
dergleichen gibt es nicht, das Wort ist billige Ausrede für nachlässige Programmierweise
- und Ausdruck einer jämmerlichen Arbeitsauffassung, solcherart bezeichneter Abfall ist einfach
nur fehlerhaft!
Zu allem Überfluß kommt noch hinzu, daß die Quellen, insbes. wenn sie nicht
direkt vom Autor rsp. von entsprechender Stelle im Inet kommen, oftmals derart kenntnislos in
"Pakete" gepackt sind, daß sie so ohne weiteres garnicht compilierbar sind - die
"SuSE"-Distribution zeichnet sich hier besonders aus, aber gelegentlich auch "Debian".
Die Installation kann am fehlenden Programm "ginstall" scheitern.
Wozu viele Makefiles auf dieser "install"-Variante bestehen, bleibt rätselhaft, zumal sie
selbst in kompletten "Distributionen" oft garnicht erst mitgeliefert wird ("Debian"). Kein Problem
immerhin, wenn man ein link anlegt:
ln -s /usr/bin/install /usr/bin/ginstall
(wo dieses "install" wirklich ist, erfährt man ggf. mit "type -p install") oder sich
ein mini-Script (s.u.) baut:
#!/bin/sh
/usr/bin/install -bVt ${*}
("GNU/FSF"-sches Gelaber fordert u.U. "--backup=t" statt "-bVt") und es unter dem Namen "ginstall"
z.B. in /usr/bin ablegt. Effekt dieser Variante ist auch, daß alte Versionen beim
Installieren nicht verlorengehen können, da das "-bVt" dafür sorgt, daß zuvor
numerierte Sicherungscopien erzeugt werden.
Ähliches trifft mitunter auch auf "make" zu, das gelegentlich als "gmake" erwartet
wird. Hier ändert man einfach die betr. Eintragung, oder legt ein link an:
d=$(dirname $(type -p make))
ln -s ${d}/make ${d}/gmake
und damit hat es sich.
Und auch noch diese eindringliche Warnung: Restlos überzogenes Selbstbewußtsein scheint
Anlaß zu dem grauenhaften, vorzugsweise in "GNU"-Quellen strapazierten "install-sh"
Script gegeben zu haben, das vorsorglich erst einmal die zu erneuernden Teile unwiederbringlich
entfernt, bevor es die Installation versucht. Scheitert jene, bleibt nicht einmal mehr die bisherige
Variante übrig. Man sollte sich einmal genau ansehen, was so eine 'mutige' Installationsprocedur
alles wegnimmt. Absoluter Wahnsinn, das. - Ändern:
In "install-sh" stehen anfangs ein paar Programmnamen nach dem Muster <mvprog="mv">. Dort
"rm" durch "true" ersetzen, zu den Definitionen für "cp" und "mv" die Option "--backup=t"
oder "-bVt" hinzufügen. Nachsehen, ob irgendwo "rm" oder "install" u.dgl. explizit aufgerufen
wird, ggf. auch dort "rm" ersetzen und "install" etc. ergänzen.
Das kann gewaltigen Ärger vermeiden!
Eleganter und allgemein wirksam, aber mit etwas mehr Aufwand kann ein
'Müllbunker' eingerichtet werden, in den ein umgeleitetes 'rm' die Files statt sie zu
entfernen zunächst einmal überträgt. Dazu bringt man das eigentliche 'mv' so
unter, daß es beim normalen Aufruf nicht gefunden wird, etwa in '/var/bin/', und richtet
ein Script ein:
#! /bin/sh
cp -f --backup=t ${@} /opt/trash/ 2>/dev/null||:
exec /var/bin/rm ${*}
das mit Namen 'rm' an vorrangige Stelle entsprechend dem (systemspezifisch) üblichen Suchpfad
lt. PATH gebracht wird. '/opt/trash' fungiert in obigem Beispiel als Depot der "gelöschten"
Files, das periodisch auf einem maximalen Inhalt hin überwacht wird, z.B. durch Eintrag in eine
'cron'-Datei, im 'Debian-Linux' etwa mit beliebigem Namen im Verzeichnis "/etc/cron.d".
16,36,56 * * * * root /usr/local/bin/rtrash 100000
Ein weiteres Script sorgt dann dafür, daß
dort ein Mindestmaß an freiem Platz sichergestellt ist (z.B. ca 100MB), indem es die jeweils
ältesten Dateien daraus tatsächlich entfernt.
Mit solch einer Mimik wird nun weder das dusselige 'install-sh' noch ein versehentliches 'rm' oder
welch andere phantastische Procedur auch immer so ohne weiteres wichtige Daten vernichten - völlig
idiotensicher ist dieses Verfahren zwar auch nicht, es deckt immerhin aber den weitaus größten
Teil solcher 'Unfälle' recht sicher ab. Doch ist auch Vorsicht angeraten: (wieder mal)
willkürlich veränderte Aufrufkonventionen für 'find' haben auch schon dazu geführt,
daß <rtrash>, worin dies zum Einsammeln der Files mit einer "~" Tilde am Ende ihres Namen
dient, mir das gesamte '/sbin'-Verzeichnis gelöscht hat - drum, unbedingt erst an einer harmlosen
Stelle die Funktion kontrollieren!
Das Archiv "rtrash" enthält einen kompletten Satz Script-Beispiele hierzu.
Und auch das noch: Merkwürdige Fehler gibt es u.U. wenn das "/tmp"-Verzeichnis voll ist.
Dann kann es passieren, daß Programme wie "ld" aus den 'binutils', das z.B. zum Zusammensetzen
der fertigen Teile eines Programms zur funktionstüchtigen Einheit dient, einfach nur nicht
spielen; Aufruf bleibt ohne irgendeine Aktion, insbes. auch ohne jede auf einen Fehler deutende
Textausgabe! D.h, Compilieren mit <make... > scheint ordnungsgemäß abzulaufen, nur
vielleicht unerwartet schnell, das Ganze geht aber in's Leere, es werden keine Ausgabedateien erzeugt!
Um die Sache vollends zu verwirren tritt der Fehler beim root-user oft nicht auf, bei allen anderen
aber ist 'ld' nicht einmal zur Ausgabe seiner Version zu bewegen. Das hängt mit der formatierten
Sicherheitsreserve an Plattenplatz zusammen, meist ca 5%, die dem root-user vorbehalten ist, damit
für Notfälle noch das Minimum an Platz etwa zum Reparieren des Systems übrig ist.
- Einkauf/Lieferverträge
Seit Februar 2001 gilt für den Handel via Internet in Umkehr bisheriger und im Inland
weiter unangefochten gültiger Regelungen die Gesetzgebung des Herkunftsortes, d.h. des
Landes, in dem der jeweilige Lieferant ansässig ist. Ganz im Gegensatz zu der daraufhin
erfolgten, irreführend öffentlich verbreiteten Bewertung fördert dies vor
allem und ohne Kompromiß gerade nicht die Sicherheit des Verbrauchers, sondern fast
ausschließlich Sicherheit und Bequemlichkeit des jeweiligen Lieferanten. Die ganze Last
zur Erlangung einer gewissen Rechtssicherheit liegt allein auf dem Abnehmer, dem zugemutet
wird, zunächst einmal das bei weitem nicht immer klar erkennbare Versenderland zu ermitteln,
um dann dessen besondere Rechtssituation in Erfahrung zu bringen - ein für den "normal",
d.h. nicht juristisch einschlägig gebildeten Käufer kaum zu bewältigendes
Unterfangen, absolut unzumutbar besonders auch angesichts der Vielzahl infragekommender
und oft genug sorgfältig verschleierter Herkunftsländer. Wie man die zugrundeliegende
Intention zu deuten hat, wird ohne weiteres klar sein; sie fügt sich reibungslos in den
aktuellen sozialen Kontext.
Einkauf über Internet ist damit zwingend auf zuverlässig bekannte inländische
Handelpartner reduziert.
- Bei der System-Installation
werden oft Disketten gebraucht. Wurden jene schon mehrmals benutzt, sieht man beim
Formatieren mitunter Fehlermeldungen, die anzeigen, daß irgendwelche Sectoren nicht in Ordnung sind.
Meist liegt die Ursache aber nur darin, daß die beteiligten Programme (Programmierer?) ihrer eigenen
"Intelligenz" nicht gewachsen sind und völlig unerhebliche alte Daten als vermeintlich bereits vorhandene
Formatangaben benutzen. Um dem abzuhelfen, macht man zuvor die betr. Sectoren ungültig - was nebenbei
auch Probleme bei Anlegen eines Filesystems auf Harddisk lösen kann, oder von grandiosen
"Windows"-sonstwas augenscheinlich zerstörte Laufwerke (CD-ROM, HD &c) wiederherstellen!
mehr dazu.
- Distribution
heißen die Programmsammlungen, die zusammen mit einer entsprechenden Installationsprocedur
ein vollständiges Linux-System liefern. "vollständig" ist dabei ein dehnbarer und
unterschiedlich interpretierter Begriff. Woraus die Frage nach der "richtigen" Distribution
erwächst. "richtig" ist ebenso vage und das Angebot ist mittlerweile kaum mehr überschaubar.
Darum zur Klärung einige subjektive(!) Hinweise zu ein paar Distributionen, die
mir selber bekannt sind.
Grundlage ist u.a. auch die "Linuxtag 2000"-CD und Installationsversuche auf der (offenbar
nur für "Debian" halbwegs unproblematischen) vierten Harddisk (hdd1). - Letzterer
"Härtetest" ist im allgemeinen kaum von Belang. Wer nicht darauf angewiesen ist, sein
Linux-Filesystem auf der vierten Platte zu verankern (d.h. sie für die "root"-Partition
zu verwenden), braucht sich darum nicht weiter zu kümmern, gewöhnlicher Zugriff
darauf und die ersten drei IDE-Platten bereiten keine solchen Probleme, weiß der Geier warum.
Distributionen, die mehrmals in eher mißratener Form erschienen sind, werden hier nicht weiter
beachtet.
Manche 'inoffizielle' oder 'aktualisierte' Distributions-Varianten zeichnen sich dadurch aus, daß
der Exhibitionismus betr. Autoren weit über deren Sachkenntnis hinauszugehen scheint. Das gipfelt
in so seltsamen Erscheinungen, wie einfach nur durch läppische Rechtschreibfehler ('extention'
statt 'extension') vermurksten Programmquellen, die eben darum nie auch nur ansatzweise zu irgendetwas
zu gebrauchen sein konnten - was sich allerdings erst festellen läßt, nachdem man (in diesem
Beispiel) rund 45MB(!) an Quellenpaketen aus dem Inet abgeholt hat. Woher einer den Mut nimmt, solchen
Mist als Debian-Quellenpaket öffentlich zu machen, bleibt mir rätselhaft. Die Tatsache, daß
das alles 'kostenlos' ist, scheinen viele 'Programmierer' als Legitimation noch größerer
Nachlässigkeit zu sehen, als ohnehin schon branchentypisch. Für 'gewöhnliche', am reinen
Nutzen eines Rechnersystems interessierte Anwender bedeutet das einzig Zeitverlust und überflüssige
Arbeit. Darum mein Rat, wirklich nur bestens bewährte Linux-Weichware zu verwenden, wozu von
den hier genannten kompletten Distributionen derzeit (2/2004) wohl nur Debian ("woody") und vor allem
SuSE gehören dürften.
Was mich betrifft, bin ich allerdings kurz davor, den ganzen Müll wieder gegen den wenigstens nicht
mit immer wieder neuem Schwachsinn aufwartenden Windos-Kram zurückzutauschen: Wenn nicht mal mehr
läppische Editorprogramme zu gebrauchen sind ("Kword", "AbiWord"), was soll dann einem Alltags- und
Feld-Wald-Wiesen-Verwender solcher "Systeme" der ganze aufgeblasene Rest nutzen? - Weil dergleichen
Stümperei zunehmend das gesamte GNU/Linux-System durchzieht und es allmählich restlos unbrauchbar
zu machen droht und ich dabei so gut wie NIE auch nur die geringste substantielle Resonanz auf einen
Fehlerbericht erhielt, habe ich nunmehr jegliche Bemühungen in Sachen Linux aufgegeben.
-
BeOS :
Caldera :
Corel :
Debian :
Mandrake :
SuSE :
Turbolinux :
Winlinux :
VMware
- "BeOS" (ca 6/2000),
um dieses Linux/Unix-ähnliche Teil gleich abzuhaken, hat mir bei einem Installationsversuch sämtliche(!)
Platten durch Zerstörung der Partitionstabellen verdorben. Wertlos...
- Caldera "OpenLinux"
Untergegangen in der Microsoft-gestützten 'SCO' als Organisation zur Abschöpfung
'patentierbaren' Wissens und zur Markt-Manipulation vermittels 'Patenten'.
- Corel
Wertlos.
- Debian (2/2004: 3.0r2, "woody")
ist die größte Sammlung ausschließlich freier und auch in Quellen gelieferter Programme.
Die derzeitige (9/2004) Entwicklung erschöpft sich allerdings schon seit geraumer Zeit in Fehlerkorrekturen
zur Programm- und System-Sicherheit sowie von organisatorischen Mängeln in den Programmpaketen (wo die
Verantwortlichen z.Teil völlig den Überblick verloren zu haben scheinen); ersteres aber nicht zuletzt
auch dank der restlos konfusen "Entwicklung" des Linux-Kerns und
wesentlicher Hilfsprogramme. So ist z.B. das "mount" m.E. derzeit ein ahnungslos dahingeschluderter
völlig vermurkster und gefährlicher Haufen Mist! was sich u.a. an der ansich vortrefflichen
"knoppix"-Installation zeigen kann, etwa sobald man versucht, die CD-gebundenen
Programme auf Harddisk verfügbar zu machen - Wenn's denn unbedingt sein muß, Vorsicht: Jede
HD, auf der mit "--bind" gemountete Teile existieren, sollte zuvor vollständig! mit
sämtlichen Partitionen gesichert werden. Weiterer Kommentar ist witzlos, wer Interesse hat,
sehe sich die Sache selber an.
- Mandrake
ließ sich denkbar leicht installieren, und liefert selbst auf der Sparversion der Linuxtag-CD
alles Nötige, nebst GNOME und KDE (Desktöppe) auch eine vielzahl von Sprachvarianten und entspr.
Terminals zum X-Windows. Start (von der vierten Platte) mit der bei Installation erzeugten Bootdiskette war
aber auch hier nur mit "Unterstützung" eines auf hdc1 vorhandenen Debian-Systems möglich. Dann aber
hat's immerhin ordentlich gespielt. Scheint die "sauberste" der hier erwähnten Distributionen zu sein.
- Redhat
ist mir neben großspuriger Selbstdarstellung allein vom "rpm"-Programm und als
Bunker der "binutils" bekannt. Großmäuligkeit läßt selten auf
Brauchbarkeit für überhaupt irgendetwas schließen, 'Redhat'-Erzeugnisse werden darum wohl
generell eher mit Vorsicht zu genießen sein. Geht zusammen mit "Cygnus".
- Slackware
...einer der Linux-"Pioniere" mit der Erfahrung vieler Jahre.
- SuSE
sehr gut für den Anfang, vor allem wegen der üppigen auch deutschsprachigen Dokumentation!
Nicht ganz billig, jedoch im Vergleich etwa zu "Debian" (s.o.) derart auf dem aktuellen 'Stand der Technik'
gehalten, daß der dafür nötige Aufwand dies sicher rechtfertigt. Leider sind aber auch
die ausgesprochen nachlässig zusammengestellten Quellen-Pakete, die sich auf reguläre Weise oft
nicht einmal auspacken lassen, kennzeichnend für bisher alle (mir bekanntgewordenen) Suse-Ausgaben.
Nebenbei: "suse"s internet-Server, ftp.suse.com &c, sind so ziemlich die langsamsten, die ich kenne...
- Turbolinux
Eindrucksvoll, (rein) äußerlich alles hübsch und nett, nur der Start war nicht möglich...
- Winlinux
Völlig vermurkste, grenzenlos schlampige "umsdos"-Installation, die allein schon aufgrund
zahlloser verdorbener Filenamen notwendigerweise versagt.
Wer mehrere Betriebssysteme gleichzeitig, ohne "Neustart" und den damit verbundenen Daten-
rsp. Zeitverlust verwenden will, sei auf "VMware"
verwiesen, das einen übergeordneten Aufbau für unterschiedliche Systeme liefert. Ein
"M$-Windows-werweißwieviel" wird im Linux z.B. aus einem Fenster des "X-Windows"
heraus betrieben - und selbst dessen gesamte Neu-Installation reibungslos bewältigt!
- Wenn der schier unglaubliche Leidenswille des gemeinen "Windows(sonstwas)"-Nutzers(?) endlich
erschöpft ist: switchtolinux (en).
- /dev/fb0 etc., der "framebuffer":
Diese Erweiterung des Linux-Kerns arbeitet nach dem Nordhoff'schen Prinzip der finalen Kostenmaximierung
(bekannt auch aus der mickeysoft-Ware): Sie erleichtert kenntnislosen "Programmierern" die Arbeit und kostet
den Anwender sowohl Zeit als auch Geld. Ohne jeden sonstigen Nutzeffekt belegt sie große Bereiche des
Speichers, in ihrer Ineffizienz lähmt sie das gesamte System.
Bei der Kernel-Konfiguration den "Support for frame buffer devices" möglichst garnicht
erst anknipsen - benötigt wird das Teil allerdings z.B. für die Schlepptöppe.