die alte GUI-Diskussion 2 / Re: Hoffnung

Hi,

-- Oliver Fromme <olli(at)lurza.secnetix.de> wrote:

> > Bei Windows gibt es de fakto keine Shell.
>
> Doch, gibt es, ich verwende sie sogar ab und zu (notge-
> drungen).

dass es eine gibt weiß ich auch, deswegen schrieb ich ja "de fakto". In
meinen Augen ist das Teil allerdings ziemlich unbrauchbar und wenns denn
sein musste habe ich immer gleich Cygwin installiert.

Allerdings muss man Windows zugestehen, dass die in den NT-Versionen
immerhin rudimentär brauchbar ist.

> > Zumindest kann man dieses Ding nicht guten Gewissens so
> > bezeichnen.
>
> Warum nicht? Was sind Deine Kriterien für eine »Shell«?

dass sie brauchbar ist ;-)
Wobei das nicht nur das Shell-Programm selbst, sondern auch alles was
dazu gehört betrifft:
History, Tab-Completion usw. sind mal das wichtigste, ein less (o.ä.)
sollte scrollbar funktionieren und ein Texteditor sollte erreichbar sein.
Unten schreibst Du, die Windows-Shell hätte History und Tab-Completion;
mag sein, evtl. aber auch erst in neueren Versionen? Naja, wie gesagt:
ich habe mir unter Windows immer Cygwin installiert, und wenn ich in der
Zwischenzeit mal an einer Windows-Kiste sitze brauche ich höchstens mal
ein ipconfig oder ping ... ;)

> 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).

ich weiß.

Was ich meinte ist, dass sich die ganze Umgebung nicht sehr komfortabel
anfühlt und dass eben viele typische Shell-Sachen nicht vorhanden sind,
z.B. ein grep.

> > 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.

doch, siehe andere Mail.
Nur weil es Windows nicht kann, heißt das ja noch lange nicht, dass es
gar nicht geht ;-)

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

siehe andere Mail; der Suchdialog von OS X kann nicht alle Spezialfälle
die man sich konstuieren kann (insbesondere wenn man find mit -exec
nutzt), aber dafür ist er auch nicht gemacht. Denn nicht weil es nicht
geht, sonder nur weil eine bestimmte Funktion einfach nicht implementiert
wurde. So wie es bei Shell-Befehlen unterschiedlicher Systeme eben auch
unterschiedliche Funktionalität gibt.

Dafür gehen die einfachen Sachen auch viel einfacher und es gehen
Sachen, die mit find nicht möglich sind. BTW: Es gibt mit "mdfind" unter
OS X natürlich auch ein Kommandozeilentool für Spotlight.

 
> > 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.

wenn ich ein GUI nutze muss ich eben rein gar nichts durchlesen. ;-)

> > 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).

Du weißt also nach einmal durchlesen dutzende Optionen auswendig?

>
> > 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.

deswegen nutze ich es auch.

> 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.)

warum sollte man das nicht in ein GUI packen können?
De Fakto ist das in Spotlight natürlich drin, die Suche kannst Du Dir
sogar als Ordner auf den Desktop legen ;-)

> 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.)

warum sollte man das nicht in ein GUI packen können? Das Vergleichsdatum
ist dann eben nicht nur "älter als zwei Wochen" und "neuer als <datum>"
usw. sondern eben auch noch "neuer als <datei>".

> 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

warum sollte man das nicht in ein GUI packen können?
Der Knopf "finde alle harten Links auf diese Datei" im Info-Dialog zu
einer Datei wäre zum Beispiel viel einfacher und intuitiver.

> > > 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).

naja, wenn die zufälligerweise irgendwo erscheinen, dann ist das wohl
ein Bug. Ich meinte eher, dass man sich darüber streiten kann, ob ein
Dialog an der aktuellen Mausposition, in der Bildschirmmitte, in der
mitte des aktuellen Fensters, links oben oder an der alten Position
erscheinen sollen.

Kommt natürlich auch drauf an, ob es modale oder nicht-modale Dialoge
sind. Und ob die betreffende Applikation alles in ein Fenster packt oder
alles in eigene Fenster.

Windows-User sind es ja eher gewohnt, dass ihre Applikation alles in ein
Fenster packt und das Fenster den ganzen Schirm benutzt, während
Mac-Nutzer eher mit einzelnen kleineren Fenstern arbeiten.

> > 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.

Ja und nein. Das kommt ganz drauf an, was man machen will.

Wenn ich ein Schlüssel und Zertifikat für meinen Mailserver bauen will,
dann reicht es wenn ich weiß was das ist und wo ich es hinlegen muss.
Wenn es von einer CA zertifiziert werden soll, dann muss ich auch das
noch wissen und muss da die Dateien hinschicken und viel mehr muss ich
erstmal nicht wissen.

Wieviele Bits der Key haben soll und welches Verfahren etc, das sind
alles Sachen bei denen ein Interface helfen 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.

ja, klar, ich habe auch ein Skript, das mit Keys generiert; aber ein
entsprechendes GUI könnte solche einfachen Sachen auch einfach machen,
während es die komplizierten nicht unmöglich macht.

> > 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 es ein schlechtes GUI wäre, dann hätte es zumindest das.

Ein gutes GUI würde das sauber gruppieren und Automatismen für
Standard-Sachen anbieten.

> > 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.

dem Anwender ist es doch wurscht, wie komplex das hinten ist. Wenn er
sich einen Schlüssel für den Webserver generieren will, dann will er
seinen Namen und die Adresse eingeben und evtl. noch die Sicherheitsstufe.

Man muss ihn ja nicht gleich mit allen Optionen erschlagen.

> 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.

Mit Ethereal kannst Du auch nachträglich filtern, kannst einfacher und
übersichtlicher die Inhalte der Pakete anschauen (bzw. selektiv des
gewünschten Pakets) usw.

[MTU]
> > 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.

hmmm, ich hatte sie auf jeden Fall schnell gefunden.

> Das Registry-Editor-GUI ist übrigens auch so eine Kata-
> strophe.

Da gebe ich Dir vollkommen recht. Die gesamte Registry ist eine
Katastrophe.

> > 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.

also, beim Überfliegen habe ich jetzt nichts gefunden, was nicht
einstellbar ist (mal abgesehen von den Optionen für Interfaces, die ich
nicht habe).

> > 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.

Demnach wären GUIs ja überflüssig und jeder erstzunehmende Anweder
würde ohne arbeiten ... ;-)

> 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.

Dafür gibt es Tastenkürzel. ;)

> > 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 ich in der c't so die Horrormeldungen zu Linux auf Notebooks lese,
dann habe ich durchaus den Eindruck dass es mit FreeBSD besser läuft. ;-)

Aber nichtsdestotrotz funktioniert mit OS X eben einfach alles ohne dass
man erstmal hoffen muss, dass es wirklich geht.

Selbst die zsh ist schon installiert :-) (allerdings ist die Bash default)

Ciao
  Alvar

-- 
** Alvar C.H. Freude, http://alvar.a-blast.org/
** http://www.wen-waehlen.de/
** http://odem.org/
** http://www.assoziations-blaster.de/

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Wed 01 Mar 2006 - 16:49:28 CET