Softwarekrise (was: Re: [linux-l] Slightly off topic: Jagd auf Spam)

[Steffen Dettmer]

* Jan Krueger wrote on Fri, Oct 31, 2003 at 21:16 +0100:
> On Thu, 2003-10-30 at 09:45, Steffen Dettmer wrote:
> > . Mach mal was grosses wie Word, aber
> > ohne Bugs. Wird nicht trivial. Der Schlüssel müßte IMHO dadrin
> > liegen, die "1 Bug je 500 Zeilen" auf "1 Bug 2000 Zeilen"
> > reduzieren zu können. Vielleicht wäre es auch mal an der Zeit,
> > sich "redundante" Programmiertechniken anzugucken
> 
> gute Idee, werde gleich mal auf die Suche gehen...

Jo, da gibt's bestimmt was. Beim Studium hatte ich mit Ada zu
tun. Da gibt's irgendwas annotated ada weiß ich was. War ne
formale Beschreibung von Vor- und Nachbedingungen für Funktionen
(und noch viel mehr). Macht natürlich Arbeit, aber eigentlich
ist das ja nur ne formale Notation der Spec. Interessanterweise
harmoniert das mit der Test-Idee von extreme Programming (erst
Test, dann Code), weil es ja im Prinzip Unittests vereinfacht
(man muß im Wesentlichen aufrufen, die Bedingungen stehen an den
Funktionen und prüfen das dann). Ob und wie das funktioniert und
in der Praxis Sinn macht, weiß ich nicht, hab mir das nur mal
durchgelesen.

> > Weiß nicht, ob wir hier die Idee finden, die sonst noch niemand
> > hatte :)
> 
> Was spricht dagegen?

Na, gibt da sehr schlaue Leute, die machen den ganzen Tag nix
anderes, und wir finden hier nebenbei was besseres? mmm... Schwer
vorstellbar, find ich.

> > Was bleibt denn da?? snprintf gilt als "sicheres sprintf",
> > aber oft sieht man sowas wie snprintf(str+strlen(str),
> > sizeof(str)-1, ...) - das ist schon wieder zu komplex. Also
> > C-strings gehen IMHO gar nicht für "sicher". Das ist aber so
> > grundlegend, daß schon mal so viel wegfallen müßte, daß da
> > wohl nix übrig bleibt, mit dem man noch was machen könnte...
> > Am Ende kommt dann vermutlich sowas wie std::string raus :)
> 
> Gut, wir behalten POSIX, ergänzen es um sichere Funktionen (wie
> zb.  OpenBSD es vor macht) und über die nächsten Jahrhunderte
> migrieren alle zu den neuen Funktionen.

LOL, ja, Jahrhunderte... Außerdem werden weiterhin die unsicheren
verwendet. Seh ich auch oft in der Praxis, heißt's eben sprintf
(also ohne das "n"), z.B. auch, weil das bei Windows dann
plötzlich _snprintf heißt (warum auch immer). Gut, man kann ein
define machen oder einfach sprintf nehmen. Viele nehmen
sprintf... Bei solchen Funktionen ist das nächste Problem (IMHO),
daß es ja ein Fehler ist, wenn so eine Grenze zuschlägt. Müßte
man auswerten oder Programm abbrechen. Macht man in der Praxis
gerade bei C und snprintf wohl nie. Und wer prüft schon den
Rückgabewert von printf? Schätze mal, so ca. niemand.

> > (zusammen auch 100K LOC) plus Appl. Macht dann 710K LOC. Weil man
> > so schöne Libs hat, hat man nur noch 1 Bug je 2000 Zeilen,
> > bleiben aber immer noch 305 Bugs, also dreimal so viel.
> > 
> > Ja, die Rechnung hinkt überall, ist für'n Eimer und völlig
> > unrealistisch
> 
> trotzdem überzeugend. Also doch höhere Programmiersprachen mit
> denen man mehr in weniger Code ausdrücken kann?

"mehr in weniger Code" liegt IMHO weniger an der Sprache als
vielmehr an Bibliotheken und Design. In einem guten Design hat
man ja kaum Coderedundanz, und damit drückt man es i.d.R. mit so
wenig wie möglich (aber eben so viel wie nötig) Code aus. Klar,
man braucht ne Sprache, in der man schreiben kann, was man meint.
Wird z.B. in C zum Problem, C++ geht schon besser, Java mag man
auch noch akzeptieren, obwohl strenggenommen Garbage Collection
und die Art der Exceptionhandlung schon wieder "schlechtere"
Designs begünstigen - auch nicht ideal.

Vielleicht bräuchte man was, in dem man Designpatterns verwendet,
und ne Art Framework, Sprachunterstützung oder weiß ich was dabei
irgendwie hilft. Bleibt das Problem, daß Designpattern meiner
Meinung nach nicht einfach anwendbar sind: oft sind die Probleme
komplex. Wem gehört dies, ist A ein B oder vielleicht ist's
logisch eher ein Aggregat? Ist's gut, wenn C beide beerbt oder
nicht? Das liegt selten sichtbar und richtig vor einem. Hier
macht man schnell Designfehler, die dann die Implementierung
versauen oder vergewaltigen, oft ohne das man es merkt. Zu
abstrakt? Ich versuch mal zwei Beispiele.

Erstmal ne dumme Frage: "Ist eine Öllampe ne spezielle Kerze, die
mit flüssigem, nachfüllbaren Wachs arbeitet, oder ist eine Kerze
eine spezielle Öllampe mit festem Öl?". Chemisch ist Wachs und Öl
ja die gleiche Richtung, die Idee (Docht etc.) ist die gleiche,
die Frage ist daher berechtigt. Wie würde man das designen? Man
muß die Frage dazu beantworten. Vielleicht sind auch beides
"AbstraktDochtBrenner". Letzeres klingt erstmal spannend, aber
irgendwie riskant, weil es in das Natur keinen
AbstraktDochtBrenner gibt und so die Gefahr von Über- oder
Unterdesign entsteht: man baut zuviel ein oder zuwenig. Später
kommt dann jemand an, hat irgendwas, was eigentlich auch ein
AbstraktDochtBrenner sein müßte, aber irgendwas paßt nicht. Dann
*muß* man meiner Meinung nach später das Design anpassen, was
aber in der Praxis oft wieder nicht richtig passiert, so daß man
dann den AbstraktDochtBrenner vergewaltigt oder nicht nutzt -
beides oft falsch.

Zweites Beispiel ist die JDK 1.4 Logging API. Hier mal kurz die
Idee: Man hat "Logger". Da schreibt irgendjemand was rein, was
später irgendwo wieder rauskommt. Das hier "irgendwo" steht ist
gut, weil es den Loggerbenutzer nicht interessieren muß - genau
das möchte man ja. Logger haben Namen und sind daher
unterscheidbar. Logger werden von einem Manager verwaltet, der
dann die sogenannten Records in Handler schiebt. Ein Handler
schreibt den Record dann z.B. in eine Datei.

Erstmal toll: jede Klasse oder Package kann sich einen Logger
ausdenken und reinschieben. Der Benutzer der Package kann über
den Manager dann "einstellen", was damit passiert (also Logdatei,
dessen Format, wie sie heißt und ob sie XML oder Text ist).
Soweit toll. Allerdings IMHO auch nur so weit. Jetzt haste ne
Applikation, die in vielen Threads arbeitet und Packages damit
mehrfach nebenläufig verwendet. Die schreiben ihrer Records damit
letztendlich in die gleiche Datei und so richtig hilfreich ist
das dann nicht mehr! Die Applikation möchte jetzt die Logger der
Threads unterscheiden können, bzw. jedem Thread einen Handler
geben, damit jeder Thread eine eigene Datei bekommt. Auch andere
Teilungen sind denkbar (wenn man z.B. eine Package mehrfach
nacheinander/durcheinaner verwendet). Das System ist nicht
hierachisch (geht ja auch nicht so einfach, weil der Manager ein
zentrales Singelton ist). Das ist IMHO eine Designschwäche. Eben
weil es ein Singelton gibt, geht keine wirkliche Hierachie: man
kann nicht einem Subsystem was "anderes" geben als einem anderen.
Es geht einfach nicht. Das ist für mich ein praktisches Problem,
für das ich noch keine Lösung fand.

Dennoch gilt die Logging-API als "gut". In Programmen muß man
aber unter Umständen komische Sachen machen, beispielsweise dafür
sorgen, daß jeder Thread ein- und denselben Loggernamen
verwendet. Ist auch doof: warum muß eine Package wissen, ob sie
in Threads benutzt wird oder nicht? In der Praxis nimmt man hier
manchmal "Contexte", oft ne Universal-Factory: ne Package sagt
dem Context, gibt mir mal meinen Logger oder dieses und jenes.
So ein Context hat aber automatisch mehr, als ne spezielle
Package braucht, ist also mindestens wieder ne Prinzipverletzung
(nicht so lokal wie möglich und nicht so geheim wie möglich und
enthält viel "trampdata"). Also auch keine saubere Lösung.

Ich hab den Eindruck, daß Logging immer unsauber ist, jedenfalls
kenne ich keinen wirklich sauberen Weg. Ich glaub, daß wird
bißchen unterschätzt - selbst von der Logging API.

> >  - sollte nur zeigen, daß heute "kleine Systeme"
> > alles sprengen, was man vor 20 Jahren kannte.
> 
> ergo: Windows kann gar nicht funktionieren :)

Genau, und X und Co genauso. Also hat man einen Kompromiss: geht
ein bißchen, so "meistens" eben. Was richtiges kann man nicht
bezahlen, also nimmt man ein "fast". Ganz prakmatisch.

> > Unser Problem ist IMHO: wenn 90% der Leute letzeres wollen, ist
> > es schwer, ersteres zu bekommen - da ist einfach kein Markt da,
> > es macht niemand, es wird zu teuer, es lohnt nicht. Ist wie bei
> > den Musik-CDs. 
> 
> Ich sehe diesen Aspekt doch noch ein wenig anders. Der Markt
> wäre meiner Ansicht nach schon da nur gibt es im Moment keinen
> der ihn besetzen könnte, weswegen sämtliche Nutzer (also jene
> 96%) davon ausgehen, dass das was MS mit Windows abliefert
> besser nicht sein kann und wenn etwas nicht funktioniert eher
> an sich selber zweifeln als an den Fertigkeiten von MS.

Ich weiß nicht. Über ein Abstürzendes Windows (oder Telefon!) ist
heute keiner mehr wirklich überrascht, jeder kennt das. Die einen
meckern dann über Windows, die 90% dann vielleicht "über den
Scheißcomputer", egal, zu frieden sind sie nicht. Dennoch wären
sich nicht bereit, für ein sehr viel langsameres "Word" mehr als
1000 EUR zu bezahlen, selbst wenn es so gut wie nie Fehler machen
würde. Und die 1000 EUR schafft man auch nur, wenn es die
Mehrheit kaufen würde - doch die wollen es ja nichtmal dann!

Also bleibt nur, wegzulassen, ein EUR 100 Word zu machen, was
dann keine automatischen Tabellen kann oder weiß ich was. Will
dann bestimmt auch keiner haben. Mit Word kriegt man es ja trotz
der Bugs meistens irgendwie hin - wenn man es denn mal braucht,
so ein Feature.

Unterm Strich sehe ich daher keinen Markt für viel bessere und
viel teurere oder viel einfachere Software.

> > > (window
> > > 	(menu
> > > 		(submenu1)
> > > 		(submenu2))
> > > 	(frame
> > > 		(image "/root/tollesbild.jpg")
> > > 	(button "bla")))
> > 
> > Fehlt sicherlich die Fehlerbehandlung
> 
> Das dachte ich auch immer als ich begann mich mit funktionaler
> Programmierung zu beschäftigen und habe mich so gewundert, wie
> das alles funktionieren kann. Kann es. Man könnte sagen: Fire
> and forget ;) Die Fehlerbehandlung ist irgendwo hinter window,
> menu usw. oder der Funktionsweise der Sprache versteckt und
> soll den Programmierer nicht interessieren, in diesem Fall.

Das ist aber blöd. Wenn tollesbild.jpg nicht lesbar ist, weil der
Programmierer aus irgendwelchen Gründen das verbotene Verzeichnis
"/root/" verwendet hat, was passiert dann? Vermute mal crash der
Applikation? Was ist mit den Daten, die man vorher alle
eingegeben hat? Oder denkt man dran, die zu speichern, bevor man
das Menü aktiviert? Irgendwo wird man es schon vergessen.

Bei deskriptiven Sprachen ist IMHO das ein Problem: man kann
vorher nicht überall beschreiben, was in welchen Fehlerfall
passieren soll (sowas wie Exceptions kann und darf es ja per
Konvention nicht geben) - also was macht man, wenn man doch eine
hat? Was passiert, wenn Komponente A Komponente B vom Aufrufer /
oberer Ebene übergeben bekommt, Komponente B einen Fehler macht,
so daß Komponente A nicht funktionieren kann? Wie merkt man das?
Wie kommt die richtige Fehlermeldung in das Logfile? (Ich rede
hier natürlich nicht von kleinen 5000 Zeilen Progrämmchen, klar,
da hat man das Problem sicherlich gar nicht.)

> Es gibt andere Fälle da sollte man die Auswirkung des
> Funktionsaufrufs lieber nochmal überprüfen.

Na ja, und was dann? Das ist schwierig. Nicht wegen der Sprache,
sondern wegen der Logik. Klar geht das Menü auch ohne Icon.
Implementiert man das? Und wie macht man das geschickt? Und macht
man es an allen Stellen? Momement, wenn man von "allen Stellen"
spricht, ist die Abtraktion vermutlich schon wieder falsch,
sollte ja nur eine geben, sonst ist's ja redundant. Also muß ne
schlaue, spezielle Funktion her.

So, daß war jetzt nur ein Bildchen. So viel Arbeit dafür. Es gibt
noch Scrollbalken an Bildschirmgrenzen, Knöpfe, die nicht ganz
ins Fenster passen und viel viel mehr. Für jedes Detail müßte man
solche Überlegungen anstellen: Kommt Fehler. Gut, probieren wir
den Knopf mal mit kleiner Schrift. usw. Dann kann man natürlich
ne schicke GUI bauen, aber es dauert ewig und wird schweine
teuer. Also läßt man es. Geht's eben ohne Icon nicht und Ruhe
ist.

Deshalb sind GUIs oft so Scheiße.

> > Ich finde, Komplexität hängt nicht direkt von der Codelänge
> > ab.  Oft ist längerer, "auf Lesbarkeit optimierter" Code
> > einfacher, als kompakter.
> 
> Bei der Betrachtung von C allein sicherlich mag das so sein.
> Beim Vergleichen von C mit anderen Sprachen stimmt das nicht
> mehr.  Es ist möglich, je nach Sprache, das selbe gut oder
> besser lesbar in weniger Zeilen auszudrücken. 

Sagt ja keiner was gegen. Ich sag ja nur: die kompakteste,
kürzeste Schreibweise ist selten die am besten lesbarste und
klarste. Schon allein, weil "i" weniger sagt als "listIndex" und
das weniger als "buttonListIndex". Obwohl in der Praxis oft "i"
genau richtig ist.

> d.h. Die Schwelle ein OSS Programmierer zu werden ist hoch, das Modell
> skaliert nicht so gut und alle schreien nach Wusern (Linux auf den
> Desktop) und Wuser sind nicht gleich Programmierer. Effekt: Mehr Wuser
> die meckern, relativ dazu weniger Programmierer.

und vor allem: viel mehr Code, viel komplexere Systeme, die oft
nicht mal genau beschrieben sind. 

> > Nimm doch was anderes. Das ist eine Linuxstärke :) 
> 
> Habe jetzt, da ich schon mal auf Evolution umgestiegen bin, gleich auf
> Gnome 2.4 umgestellt. Habe mich immer darum gedrückt, weil ich nicht
> diese Konfigurationsorgie durchmachen wollte, naja, jetzt habe ich es
> gewagt. Evolution startet ja eh 99% Prozent von Gnome wenn man es
> aufruft.

Evolution war dieses OpenOutlook? Hat das nicht die gleichen
Schwächen wie Outlook, z.B. Komplexität an Stellen, die mit eMail
nix mehr zu tun haben?

> Jetzt habe ich ein System mit anderen Fehlern welches nicht
> ganz meinen Wünschen entspricht, weil man bestimmte
> Einstellungen nicht tätigen kann bzw. weil das System auf das
> setzen der Einstellungen nicht reagiert.

Ich glaub, man kann unheimlich verdammt viel einstellen, muß bloß
lernen, wie das geht.

> Auch fällt es mir schwer einen Unterschied zwischen GConf und
> dem Windows-Registry Editor festzustellen. Das finde ich ein
> wenig traurig.

GConf kenn ich nicht. Gnome ist für mich ne Bibliothek, von der
ich nichts sehe. Aber wie gesagt, ich brauch ja keinen Fuß am
unteren Ende oder vor allem keine Icons auf dem Hintergrund (weil
da eh Fenster davor liegen).

Brauchst Du überhaupt so einen Desktop? Vielleicht reicht ja was
einfaches. Hat vermutlich oft weniger Bugs, weil weniger
Möglichkeiten. Nur blöd, wenn ein Detail, was Du liebst, dann
gerade nicht geht. 

> > > Microsoft Longhorn, hab mir die Demo Videos im Netz
> > > angeschaut, whooaa, coool.  
> > 
> > Kenn ich nicht. Was ist da CooL?
> 
> 3l33t haxor are kewl oder so?

Für Außenstehende weniger, oder?

> > Kann man endlich ein Video als Hintergrund vor transparenten
> > Fenstern installieren?
> 
> Ja, kann man.

Das ist doch mal was. Dann kann man sich ein Bugkaminfeuer als
Hintergrund legen, transparente Fenster darüber, beruhigt.
Anstatt Bildschirmschoner einfach Fenster gleichmäßig
transparenter machen. Beruhigt dann... Schöne Abstaktion, weil
Bildschirmschoner und exklusiver Hintergrund das gleiche sind.

Gut, man kann sich auch ein Aquarium kaufen, hat vermutlich
weniger Bugs. Oder einen Kamin anmachen. Ach nee, die werden ja
verboten.

> > Weiß nicht, wovon Du redest. Welchen Longhorn-Feature(s) wird man
> > nachhechlen?
> 
> Siehe andere Mail welche ich dazu schrieb.

Yo, hab ich. Ja, bißchen unix alike. Das WinFS erinnert an
"locate", was ich persönlich gern verwende. locate kriegt man
bestimmt auch netzwerkfähig, wollte ich schon mal probieren.
Mindestens mit einem Wrapperscript ist das einfach machbar. 

In der Praxis fällt auf, daß man öfter ältere Dateien sucht, als
die, die man vor 10 Minuten hatte. Daher ist updatedb per Cron
meistens völlig ausreichend :)

Ich glaub, für Volltext rechnet man ab 30% dazu. Na, wenn man
sowas braucht. Wenn man jetzt noch die Inhalte indizieren
möchte, braucht's Platz (neben Laufzeit). Na gut, so kann man
schlechte Strukturen besser einführen, weil man die Probleme
später erst merkt, vermutlich *das* Windows-Argument, was alle
haben ohne es zu wissen :) 

Ich behaupte erstmal völlig ohne irgendwelche Argumente: wer so
etwas *braucht*, organisiert seine Daten einfach falsch.

> > Ich frag mich heute noch, wer auch die dämliche Idee kam, Linux
> > sollte den Desktop erobern.
> 
> RedHat? Susie? IBM? SCO? Irgendeiner der da was verkaufen wollte.

Yep.

> > Wenn man ein Windows look-a-like haben will, warum
> > installiert man sich dann nicht einfach Windows?
> 
> Weil es nicht funktioniert. Klar.

Stimmt doch nicht. Windows funktioniert schon. Gut, ich muß öfter
mal mit komischen Wordphänomenen kämpfen, aber ich kriegs
meistens hin. Gut, ich möchte cygwin und bash nicht missen und
würde nicht exklusiv auf Win arbeiten müssen, aber für ne
Sekretärin reicht's ja aus. Wenn man dieser bekloppten MS Idee
[*] folgt, das das Dokument und nicht die Anwendung im
Mittelpunkt steht, braucht man auch keine virutellen Desktops und
nix.

[*] Die Idee klingt erstmal gut, aber so wie umgesetzt, nicht zu
    gebrauchen. Ich behaupte, daß der Arbeitsprozeß im
    Mittelpunkt stehen sollte - die Anwendung paßt eher darauf,
    das Dokument paßt eher zum Arbeitsprozeß*ergebnis*, finde
    ich. Ergo halte ich die Idee für "bekloppt" :)

Wenn man bei Win auf den Schnickschnack verzeichtet, läufts
jedenfalls. Gut, die meisten machen das nicht, aber ich denke,
die würden sich dann auch alle 3 Monate ein Linux
neuinstallieren...

> > Letzeres Argument, was mit dem Argument: "notfalls holt man sich
> > Sourcen und findet *jeden* Bug" harmoniert, find ich persönlich
> > wichtig. Wir haben SourceForge 2.5 in der Firma lokal installiert
> > und inzwischen schon viele Sachen im Code geändert. "customized"
> > nennt SAP sowas. Bei Win *geht* das einfach nicht.
> 
> Ja, das geht für Unternehmen welche diese Ressourcen haben. Ein
> kleines 5 Leute Unternehmen (keine Entwicklungsbude) kann das
> nicht immer tun.  

*Hier* nicht, aber persönliche Editoreinstellungen etc. gehen
schon. Bei Word haut das wieder nicht hin, weil die Einstellungen
zum Dokument und nicht zum Benutzer gespeichert werden. Kotzt
mich jedes mal an: Jedesmal muß ich die ganzen Optionen
umstellen, wenn ich ein neues Dokument bekomme... Aber man kann
damit leben, vor allem in kleinen Firmen, denke ich.

> Jemanden zu beauftragen kann teuer werden.  Folglich lässt sich
> die Flexibilität welche man durch die offen Quellen hat häufig
> gar nicht realisieren. Ich meinte auch eher die Unix-gegebene
> Flexibilität.

Wenn die Entwicklerfirmen die Flexibilität nutzen, hat am Ende
auch die kleine Firma was davon (weil der Bug eben nicht da ist).
Ich hab mit SuSE 6.3 mit unixODBC angefangen, was damals noch
einen kleinen Bug hatte, alles kein Problem, ging jedenfalls mit
eigenem RPM. Gut für den Anwender. Inzwischen ist bei SuSE alles
dabei und fein :)

> > Aber: Entscheidungsträger denken IMHO nicht so. Sie verstehen
> > nicht, was man meint, wenn man sagt: "Wenn man sich in den Fuß
> > schießen muß, ist es gut, wenn man es kann". Sie sagen dann:
> > "Aber dann schießen wir uns eben nicht in den Fuß".
> 
> Ja, da habe ich auch schon ein paar Diskussionen mit
> Entscheidungsträgern geführt.

Yo, und hier sitzt IMHO das Problem. Das gibt es, weil das MS
Marketing so gut ist. 

Bin mal gespannt, ob nach dem ".com" Desaster sich noch viele
finden, die das jetzt kommende ".net" Desaster mitmachen! Ich
fürchte, da werden noch viele reinfallen, bis sie zum gleichen
Schluß kommen: Plattformen generieren eben nicht automatisch
Business.

> > In Firmen werden Briefe geschrieben und eMails beantwortet.
> > Beides keine Windowsgründe. Linux *geht schon jetzt* auf dem
> > Firmendesktop - man will es aber nicht.
> 
> Ja, sag ich doch. In wohl zu definierenden Umgebungen mit
> begrenzten Aufgabenbereichen -> Unternehmen und deren
> Abteilungen, allerdings nicht für alle. 

Ja, klar, trifft auf Win genauso. Win geht auch nicht in
Kernkraftwerken. Aber beides geht in 90% der Fälle.

> Dagegen spricht der Mangel an bestimmten Anwendungen zb. im
> Finanziellen Bereich.

Yo, was auch kein Wunder ist, da ja 90% Win haben. 

> >  Mit einer guten IT
> 
> die teuer ist
> 
> >  ist Linux billiger,
> 
> oder auch nicht ;)

oki :) Aber ne gute IT hat mit unix bessere Chancen als mit Win,
denke ich.

> Genau, ein Server mit Weboberfläche und man benötigt keinen Admin mehr.

... denkt man. Bis zum ersten Problem. Und Designfehler sind auch
schon drin. Immer.

> Für die Firewall hat die Oberfläche auch eine Seite und da kann
> man ein Häkchen machen, entweder bei On oder bei Off.

Genau, dann macht man aktives FTP an und fühlt sich sicher :) Ja,
genau, da kann man nur ablachen.

> Und weil es in PHP realisiert ist kann die Firewall manchmal
> auch beide Zustände gleichzeitig annehmen. Das macht gar
> nichts, es ist ja Linux und Linux ist sicher, oder?

Nee, anders. Ich höre manchmal: "Aber wir haben doch eine
Firewall!". Ich fang dann immer mit dem Holzeimer an. Der ist
auch senkrechten Leisten, die kreisförmig angeordnet sind,
zusammengebaut. Natürlich paßt nur soviel Wasser rein, wie die
kürzeste Leiste lang ist. Ob daneben noch ne Mahagonie-Langlatte
ist, spielt keine Rolle. Das hilft dann bis zum nächsten: "Aber
wir haben doch eine Firewall!".

> > Die Standard-Sekretärin hat noch andere Ansprüche, glaub ich.
> > Interessanterweise kommt Win inzwischen mit dynamischen Menüs, in
> > denen erstmal nur das steht, was man benutzt. Ich fand das damals
> > erstaunlich! Genau so ist das nämlich: den meisten Mist braucht
> > man fast nie! Man möchte gar keine eine Millionen Funktionen!
> 
> sondern funktionierende Funktionen?

Yo, nur 1000, weil mehr eh oft verwirrt. Selbst wenn man die Bugs
mal außen vor läßt.

> > Ich denke, 90% will bunt, also "die Community will bunt und
> > animierte Dialoge". 
> 
> und transparente Fenster. 

Yo, die hab ich auch :)

> Nachdem sie das 2 Tage ausprobiert haben schalten sie es ab
> weil es der Leserlichkeit hinderlich ist.

Ich nicht :) Aber klar, Dein Argument trifft es genau. Es hilft
einem nicht. Man braucht das nur, weil man zu wenig spielt. Kein
Witz, ich seh das so. Man ist durch TV und Co so unkreativ, das
man eben mit dem Computer spielt - und das meint nicht nur
Minesweeper.

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.