Re: Hoffnung

Alvar Freude <alvar(at)a-blast.org> wrote:
> Oliver Fromme <olli(at)lurza.secnetix.de> wrote:
> > Alvar Freude <alvar(at)a-blast.org> wrote:
> > > Oliver Fromme <olli(at)lurza.secnetix.de> wrote:
> > >
> > > > Wenn es nicht out-of-the box klappt, hilft einem auch das
> > > > schönste GUI nichts. Wie heißt es so schön: A GUI makes
> > > > simple tasks easier, and complex tasks impossible.
> > >
> > > das ist schlicht falsch und kommt auf das GUI und das dazu
> > > alternative Interface an.
> >
> > Vielleicht, aber existiert bisher kein entsprechendes GUI.
>
> Bei Windows gibt es de fakto keine Shell.

Doch, gibt es, ich verwende sie sogar ab und zu (notge-
drungen).

> Zumindest kann man dieses Ding nicht guten Gewissens so
> bezeichnen.

Warum nicht? Was sind Deine Kriterien für eine »Shell«?

Der »Befehlsinterpreter« von Windows (oder auch »Eingabe-
aufforderung«) hat alle grundlegenden Eigenschaften einer
Shell, wie man sie auch von UNIX her kennt:

 - Sowohl skriptfähig als auch interaktiv verwendbar.
 - Kommando-History und Filename-Completion.
 - Verzeichnis-Stack.
 - Globbing (Wildcards).
 - Schleifen, if-Abfragen und Unterroutinen.
 - Variablen.

Damit ist sie sogar eine turing-vollständige Sprache.
Completion und Verzeichnis-Stack hat noch nicht einmal
BSD's /bin/sh (und »goto« auch nicht).

Es gibt sogar so eine Art Manual-pages, nur daß man sie
per »help« statt »man« aufruft. Die »Manpage« der Shell
selbst erhält man mit »help cmd« (der Befehlsinterpreter
heißt cmd.exe).

> Aber komplexe Aufgaben sind da nicht
> unmöglich.
>
> (Achduschreck, jetzt ist es sogar so weit gekommen dass ICH Windows
> verdeidige! ;-) )

Ähm, wer verteidigt hier gerade Windows? :-)

Aber um auch mal negative Kritik anzubringen: Die Syntax
von cmd.exe ist ziemlich unschön (noch unschöner als die
der csh/tcsh), was wohl daran liegt, daß sie historisch aus
der alten MS-DOS command.com gewachsen ist, von der sie
einige Altlasten geerbt hat.

> > Für alle GUIs, die ich bisher kennengelernt habe, gilt im
> > wesentlichen obiger Satz. Bestes Beispiel ist der Datei-
> > Such-Dialog von Windows: _Simple_ Suchanfragen sind damit
> > einfach zu realisieren, z.B. wenn ich den Namen der Datei
> > kenne, die ich suche. Aber sobald es komplizierter wird,
> > leistet der Dialog das einfach nicht. Da muß man zu einem
> > Kommandozeilentool wie find(1) greifen.
>
> das liegt aber nicht rein prinzipiell daran, dass ein GUI das nicht
> leisten kann, sondern schlicht daran, dass dieser Dialog das nicht kann.

Kein sinnvoll designter Dialog kann das im Falle von
find(1). Dafür ist die Aufgabe, die find(1) erfüllt,
einfach nicht geeignet.

> > Klar, theoretisch
> > könnte man alle Features von find(1) in so einen graphi-
> > schen Dialog einbauen, aber der wird dann so unübersicht-
> > lich, komplex und aufwndig zu bedienen, daß man sich das
> > nicht wirklich antun möchte.
>
> das ließe sich problemlos in einen übersichtlichen Dialog packen.

Nein. Beschreibe einen solchen Dialog, und ich nenne Dir
einen Beispielaufruf von find(1), der damit nicht abbildbar
ist.

> Aber: um find zu beherrschen, muss ich sehr viel *wissen*.

Überhaupt nicht. Man muß grundlegend wissen, was find(1)
tut: Es liefert eine rekursive Liste von Dateipfaden, die
sich nach bestimmten Kriterien filtern lassen. Punkt.
Wenn man nach etwas ganz bestimmten filtern will, braucht
ma nur genau _diesen_ Abschnitt in der Mapage nachzulesen
(z.B. -name, wenn man nach Namen suchen will). Man kann
sich natürlich auch die Zeit nehmen und die ganze Manpage
durchlesen (dürfte nicht länger als 10 Minuten dauern),
wenn man möchte. Das dürfte aber anfänglich kaum notwendig
sein.

> Ich kann nicht
> das Ding anwenden und jedes mal eine weitere Option nebenher (!)
> auffinden, die ich nutzen kann, sondern ich muss jedesmal die Anleitung
> lesen.

Nö, wieso mußt Du das? Ich persönlich habe irgendwann mal
die find-Manpage vollständig durchgelesen (ich war halt
neugierig, was alles geht, habe aber nicht nach einer kon-
kreten Funktion gesucht). Danach habe ich nur gelegentlich
mal das eine oder andere Detail in der Manpage nachgeschla-
gen, z.B. ob bei "-path" Wildcards auch "/" erwischen oder
nicht. Solche Details müßte ich im Falle eines GUI aber
ebenso nachlesen (in der Online-Hilfe oder sonstwo).

> find zum Beispiel ist mir i.d.R. sowieso viel zu doof, ich nutze es meist
> gerade mal als ein erweitertes ls -R | grep -- aber eben auch mit grep.

Kannst Du durchaus machen, hat beides Vor- und Nachteile.
Wenn Du den genauen Pfad einer Datei wissen willst, dann
geht natürlich nur find(); ls -R hilft Dir da nicht wei-
ter.

Ich verwende find häufig, um nach irgendwas zu suchen, z.B.
eben mal herauszufinden, wo der syscall mount() definiert
ist: find /usr/src/sys -type f | xargs grep '^mount'
(Als billiger Ersatz für ein Crossreferenz-Tool, dessen
Installation sich für mich meistens nicht lohnt.)

Häufig verwende ich es auch, um Dateien zu finden, die
älter oder jünger als eine bestimmte Referenzdatei sind,
Zum Beispiel: find /var/log -newer /var/log/lastlog
(Liefert mir alle Log-Dateien, in die seit dem letzten
User-Login etwas geschrieben wurde.)

Eine andere typische Aufgabe: Hardlinks finden:
find . -type f -links +1 -ls | sort
Und natürlich, um herauszufinden, wo die anderen Hardlinks
einer bestimmten Datei sind:
find . -inum 123456

Es gibt noch zahlreiche andere Anwendungen. find(1) ist
eines der Tools, die ich am häufigsten verwende.

> > Nichtmal einfachste Dinge werden
> > berücksichtigt, z.B. daß ein Dialog sich an derselben
> > Stelle öffnet, an der man ihn zuletzt geschlossen hat,
>
> Da kann man sich trefflich drüber streiten, ob man das wirklich will und
> für welche Art von Dialog man das will.

Also, _ich_ will das, und ich denke mal, die meisten ande-
ren Anwender wollen das auch. Ich finde es sehr kontra-
produktiv wenn z.B. derselbe Pop-Up mal links oben und
mal rechts unten aufgeht (unvorhersagbar und ohne ersicht-
lichen Grund).

> > oder daß ein Scrollbalken persistent bleibt (das konnte
> > AmigaOS vor 20 Jahren besser).
>
> persistenter Scrollbalken? Du meist Scrollbalken, deren Größe sich an
> den Fensterinhalt anpasst?

Nö, das können viele Windows-Programme inzwischen auch.

Mit persistent meine ich, daß der Scrollbalken an der
Stelle bleibt, an die ich ihn hinschiebe. (Das gilt
nicht nur für Scrollbalken, sondern auch für andere
veränderliche Objekte).

> Oftmals ist aber auch gar nicht die Tatsache, dass es sich um ein
> Kommandozeilenteil handelt das Problem. Sondern das Problem ist der
> Zustand, in dem das Ding ausgeliefert wird.

Stimmt.

> Schlüssel- und Zertifikatgenerierung mit OpenSSH zum Beispiel ist eine
> Katastrophe.

Naja, ein komplexes Problem erfordert nunmal ein komplexes
Programm, und X509-Zertifikate sind numal keine Sache, die
man mit Null-Wissen handhaben kann.

Zugegeben, die Syntax von openssl ist nicht »hübsch«, aber
immerhin halbwegs konsistent, und mit Ralf Engeschalls Koch-
rezepten auf www.modssl.org ist es recht einfach. Die habe
ich mir irgendwann mal in einem Shellskript verpackt, und
seitdem ist alles in bester Ordnung. Sofern es um Zertifi-
kate für Webserver geht, nimmt einem auch das Makefile des
FreeBSD-modssl-Ports einiges an Arbeit ab.

> Ein GUI-Programm könnte es sich schlicht nicht leisten, so
> etwas anzubieten: da hätte ich zumindest alle Optionen anklickbar in
> einem Fenster

Alle? In einem Fenster? Ist Dir bewußt, daß openssl etwa
100 Kommandos hat (die Optionen noch nicht eingerechnet!)?
Gib mal »openssl help« ein ...

Wenn das alles in einem Fenster wäre, wäre das nicht beson-
ders übersichtlich. Da ziehe ich definitiv die Kommando-
zeile vor.

> Ein positives Beispiel hingegen ist da der sshd bzw. dessen Einbindung:
> da muss ich eben nicht erst irgendwelche Schlüssel mit irgendwelchen
> kryptischen Befehlen generieren,

Das liegt aber daran, daß ein SSH-Schlüssel erheblich
einfacher aufgebaut ist als ein X509-Schlüssel von
OpenSSL. Letzterer braucht zwangsläufig mehr Parameter
und einen komplexeren Aufruf.

> der macht das im Normalfall von alleine
> (oder FreeBSD macht es, kann auch sein).

FreeBSD ruft ssh-keygen auf, wenn noch keine Host-Keys
vorhanden sind. Da die Host-Keys keinerlei Benutzerdaten
enthalten, ist das ohne Interaktion möglich.

Wenn Du Dir z.B. einen Benutzerkey anlegen willst, mußt
Du ssh-keygen manuell aufrufen. (Was aber auch relativ
einfach ist.)

> Ein anderes Beispiel wäre Ethereal: mit GUI kommt man da relativ fix
> zurecht (auch wenn das nicht der Superhit ist). Bei tcpdump braucht man
> deutlich mehr konkretes Wissen, um damit mehr zu machen als mal eben auf
> alle Pakete zu lauschen.

Was meinst Du mit »deutlich mehr konkretes Wissen«?
Was ist z.B. an »tcpdump port 80 or port 25« schwer?
Wenn man weiß, wie TCP/IP funktioniert und daß man
Begriffe mit "or", "and", "not" und Klammern kombinie-
ren kann, hat man eigentlich schon alles an der Hand,
um tcpdump zu verwenden.

> > Man kann höchstens ausprobieren, auf alle mögli-
> > chen Buttons zu drücken (»erweiterte Einstellungen«), um
> > dann zu staunen, wo sich welche Dinge verbergen -- sofern
> > sie überhaupt vorhanden sind (such z.B. mal, wo man die
> > MTU einstellen kann).
>
> oh, die hatte ich letztens vor mir, als ich hier OpenVPN installiert
> habe. Wenn ich mich recht erinnere war die nicht wirklich versteckt.

Doch, die ist nämlich gar nicht in den Netzwerkeinstel-
lungen, sondern in den Einstellungen des Kartentreibers.
Sofern man Glück hat und die richtige Karte hat; bei
manchen ist eine Änderung der MTU nämlich gar nicht vor-
gesehen, oder nur per manuelles Basteln in der Registry.
Das Registry-Editor-GUI ist übrigens auch so eine Kata-
strophe.

> Bei OS X zum Beispiel ist das alles einfach und übersichtlich -- und wer
> will hat ja immer noch ifconfig ;-)

Ich kenne das ifconfig-GUI von OS X nicht, aber wenn ich
mir so die manpage von FreeBSD's ifconfig anschauen, dann
bezweifle ich auch, daß man das vollständig (!) in ein
effizient verwendbares GUI verpacken könnte.

> > Und wie gesagt: Wer ein UNIX-System nutzt und nicht einmal
> > die Befehle "man" und "apropos" kennt, dem ist eh nicht zu
> > helfen. Der sollte entweder kein UNIX benutzen, oder sich
> > von seiner Lernresistenz kurieren lassen.
>
> Ich sprach ja davon, dass man bei einem kommadozeilenbasiertem UI mehr
> Wissen benötigt als bei einem grafischen.

Das einzige zusätzliche Wissen ist das über die Shell (so
wie man beim GUI wissen muß, wie eine Maus funktioniert).
Alles andere Wissen ist bei beidem im wesentlichen iden-
tisch.

Eines der Probleme mit GUIs ist auch, daß man häufig mit
der Hand zwischen Maus und Tastatur wechseln muß. Das
tötet die Effizienz, insbesondere für 10-Finger-Tipper.

> apropos ist nicht immer eine Hilfe,
> "apropos network" zum Beispiel: da kann man dann lange lesen ;)

Das ist wie bei Google: Man sollte schon wissen, wonach
man sucht, und entsprechend intelligente Suchanfragen for-
mulieren.

Wenn Du nach irgendwas mit Netzwerk suchst (»apropos net-
work«), dann kriegst Du halt alles, was paßt. Du mußt die
Suche dann halt entsprechend eingrenzen.

> > Ob ich in einem GUI in der Online-
> > Hilfe lese oder bei einem Kommandozeilentool in der Man-
> > page, ergibt keinen substantiellen Unterschied.
>
> bei einem GUI braucht man aber deutlich seltener die Online-Hilfe,
> weil man alle Optionen schon im Klartext vor sich stehen hat.

Da weiß man aber noch lange nicht, was die Optionen genau
tun. (Davon abgesehen listen viele Kommandozeilen-Tools
ebenfalls die Optionen im Klartext auf, häufig mit einzei-
ligen Beschreibungen.)

> > > Es gibt Millionen von Nutzern, die nicht bereit sind mit der Shell zu
> > > arbeiten und trotzdem ein UNIX-System nutzen: OS X.
> >
> > Falsch. Diese Leute nutzen kein UNIX-System. Sie nutzen
> > eine graphische Oberfläche. Ob darunter ein UNIX-System
> > oder irgendwas anderes läuft, ist völlig unerheblich und
> > interessiert diese Leute auch nicht.
>
> Es ging mir darum die Behauptung, dass die Benutzung eines Unix-Systems
> Fachwissen und Kommandozeile erfordert zu widerlegen. Da kann man sich
> natürlich fragen: was IST Unix? Wenn man sagt: Unix ist Kommandozeile:
> dann hast Du Recht.

UNIX ist das Betriebssystem, nicht die graphische Ober-
fläche. Letztere kann sonstwie aussehen; es gibt ja z.B.
auch Windows-GUI-Clones als Windowmanager für XFree86/Xorg
(z.B. fvwm95, qvwm). Aus der Sicht des Anwenders benutzt
er dann ein Windows.

Bei Windows ist das (leider) vermischt, da die Oberfläche
untrennbarer Teil des Betriebssystems ist. Bei UNIX ist
das nicht so.

> Ich stand vor der Wahl:
> Holst Du Dir einen neuen Notebook mit Wintel-Technologie? Dann gibt es da
> viel Gefrickel, um FreeBSD laufen zu lassen und um anständig arbeiten zu
> können.

Kommt drauf an. Auch ich habe mir ein neues Notebook ge-
kauft, habe aber bei der Auswahl sorgsam darauf geachtet,
was für Hardware drin ist und wie gut sie unterstützt wird.
Und für den Notfall habe ich mir ein Rückgabe recht vom
Händler zusichern lassen (wenn man per Versandhandel kauft,
hat man ja eh 14 Tage Rückgaberecht). Und siehe da: Fast
alles lief auf Anhieb mit FreeBSD. Ganz ohne Gefrickel.
Nur für die 3d-Beschleunigung (die ich eh nicht brauche)
mußte ich auf die nächste Xorg-Version warten, aber das war
auch kein Problem.

Wenn man dagegen einfach »blind« ein Notebook greifen will,
ohne sich über FreeBSD-Support Gedanken machen zu wollen,
dann ist die Entscheidung für ein PowerBook natürlich nicht
von der hand zu weisen.

Ich wollte aber auf jeden Fall auf meinem Notebook ein
freies Open-Source-Betriebsssytem laufen lassen, vorzugs-
weise halt FreeBSD, und da muß man sich halt schon ein
wenig umgucken und sorgfältig auswählen.

> > Wer sich bewußt ein UNIX-System installiert, hat dagegen
> > ganz andere Beweggründe und will es i.allg. auch als sol-
> > ches nutzen, bzw. er hat in vielen Fällen gar keine andere
> > Wahl, weil das GUI halt nicht allmächtig ist.
>
> Manche wünschen sich aber auch einen vollwertigen Ersatz für Windows.
> Im Heim-Bereich für Nicht-Freaks ist das eben nur eingeschränkt drin,

Das ist eigentlich die primäre Zielgruppe für OS X, würde
ich sagen. FreeBSD ist eher nicht so die typische Wahl für
solche Leute, und ich würde es ihnen auch nicht empfehlen.

Gruß
   Olli

-- 
Oliver Fromme,  secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing
Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.
"I invented Ctrl-Alt-Delete, but Bill Gates made it famous."
        -- David Bradley, original IBM PC design team
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message