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

[Steffen Dettmer]

* Jan Krueger wrote on Wed, Oct 29, 2003 at 17:32 +0100:
> On Sunday 26 October 2003 22:56, Steffen Dettmer wrote:
> > Na, aber auch hier kann man die angebotene Leistung (also z.B.
> > Webserver trozdem noch empfindlich stören, beispielsweis aus dem
> > chroot herraus Unfug anstellen, weil der Server vielleicht
> > TCP-Verbindungen "darf", weil da ein URL-Validator liegt oder so.
> Diese verflixte Komplexität ist noch komplexer als ich dachte...

Ja, gibt's auch so'n Spruch für: "Things are more complex than
they seem to be". Man beachte, daß keine Einschränkung genannt
wird ;)

> > Ja, die Sicherheitslücke "Adminstrator" ist auch nicht zu
> > verachten. Es sollte schon KISS sein, damit man dem Kram noch
> > trauen kann...
> Was meinst Du, wenn Du "KISS" schreibst?

"Keep it simple&stupid" wurde ja schon genannt. Find ich wirklich
wichtig. Greift auch XP (extreme programming) massiv auf, BTW.
Ich find das oft wirklich elementar. Wenn man KISS hat, guckt man
sich das an, versteht und weiß was passiert. Man findet es
logisch und dann kann man damit arbeiten. Wenn man aber auswendig
lernen muß, warum die Funktion A nu vom Modul B zur Verfügung
gestellt wird (damit Modul C nämlich dies konfigurieren kann),
kommt man schnell durcheinander.

> > Na ja, die "Sandbox"-Idee ist ja so schlecht nicht, finde ich.
[Meinte eigentlich eher eine "Prozeßsandbox" wie ne JVM]

> Ja, find ich auch, den normalen Wuser zu sandboxen sollte
> Standard sein.  Mac OS X macht es ja beinahe vor.
> Geht aber mit den existierenden Filesystem-Hierarchie-Standards
> nicht so richtig wirklich da Wuser-kram und Systemkram schön
> miteinander vermixt sind ...

Fänd ich erstmal egal. Ist von der Logik her eben vermischt, wenn
man so will, weil ein User das System benutzt. Find ich natürlich
und logisch. In der Theorie funktioniert das ja auch immerhin
schon mal: ein User kann eben da nix manipulieren.

KISS und security kann auch ein Zielkonflikt sein, nämlich dann,
wenn man Bibliotheken oder Kernel bastelt. Soll es sicher werden,
muß viel geprüft und so weiter werden, weil man (als
Kernel/Libentwickler) der späteren Anwendung nicht traut. (Traut
man ihr, ist's ja sicher, also trivial Fall, uninteressant hier.)

Also baut man da was ein, was dann paar Sachen prüft und
zusätzliche Komplexität einbringt, klar. In C kann man auch
schnell mit einfachen logischen Funktionen nette Codekomplexität
erzeugen: haste ne Funktion, die Prüfdaten z.B. iteriert, kopiert
und konvertiert, nimmste zwei pointer in einer Schleife - kann
schon nett werden, und die Speichergrößen muß man auch
überwachen. In C arbeitet man ja nicht mit Modulfunktionen auf
Bufferstrukturen, sondern werkelt i.d.R. direkt in char[]s rum.
Macht man sich ein Modul dafür (vielleicht ein byte_buffer.[hc]),
sieht es zwar komplexer aus, weil 30 Zeilen Code mehr, aber ich
find das ist eher KISS. Teile-und-Herrsche paßt nämlich, find
ich. Ich persönlich bin auch zu blöd, irgendwas überblicken zu
können, muß mir da immer teilen. Irgendwann hat man sich was
erteilt, was so einfach ist, daß man es sofort schreiben könnte
(sollte man dann trozdem nie :)). So ein byte_buffer ist dann
recht einfach und verständlich, macht man ein paar Unittests für
und gut. Dann stellt man (hoffentlich) fest, daß die Anwendung
den anwendenden Code auch einfacher (aber länger) macht. Macht
man aber nicht - weiß auch nicht, warum.

> > Ja, eine sehr interessante Aussage! Vielleicht ist ein solch
> > buntes System mit Millionen von Funktionen (die man vielleicht
> > gar nicht braucht ;)) mit den gewohnten Techniken einfach nicht
> > sicher zu realisieren.
> Da bin ich mir auch nicht so sicher. 

Gut, hier hätte stehen müssen: "... einfach nicht sicher und
zuverlässig zu realisieren.". 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 oder
auszudenken. Beispiel Trägerrakete: hier wird auch alles mehrfach
gerechnet. Klingt erstmal blöd, aber immerhin kann man Fehler
wohl besser erkennen. Weiß nicht, ob sowas realistisch wäre.

> Ich hoffe immernoch, daß eines der nächten BeLUG Patente
> (welches nicht unbedingt von mir sein muß) einen Weg aus dieser
> Software-Krise aufzeigen kann :)

Weiß nicht, ob wir hier die Idee finden, die sonst noch niemand
hatte :)

> > Möchte man es "unten" abfangen, hat man
> > Ärger, Aufwand, Funktionseinschränkung und sowas, "oben" kann man
> > es nicht abfangen, weil viel zu kompliziert. Macht man einen
> > Kompromis und nennt den POSIX? mmm...

> Gut, dann nehme man diesen Kompromis, schmeiße all das raus was
> unsicher ist und sowieso überflüssig und nenne es POSIX light
> oder POSIX secure 

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

> und ist schon mal einen schritt weiter oder man baut einen
> neuen Kompromiss welcher dann dank seiner Natur neu zu sein,
> neue Erkenntnisse umsetzt und nicht auf den Erkenntnissen
> welche vor 20 Jahren aktuell waren, beharrt.

Ich seh das bißchen anders. Heute hat man ne riesen libc, nehmen
wir mal 100.000 Zeile Code an. Früher bauten Anwendungen darauf
auf. Nehmen wir mal 10.000 Zeile Code an. Bei 1 Bug je 1000
Zeilen also 110 Bugs. 

Heute hat man ne glibc, eine STL (angenommen 100K LOC), ne CORBA
lib (100K LOC), ein Application Framework/Application
Server/irgendwas (100K LOC), OpenSSL (100K LOC), XML-irgendwas
(100K Loc) und dann noch ne Million Libs für alles mögliche
(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 - sollte nur zeigen, daß heute "kleine Systeme"
alles sprengen, was man vor 20 Jahren kannte. Das kann man nur
noch mit neuen Tools bearbeiten, die neue Bugs haben etc. pp.
Aber heute braucht man ja animierte Dialoge...

> > Ja, das fragt man sich dann! Letzeres mag wohl wieder mal an der
> > Komplexität liegen.

> Nun, nicht nur, ich denke, daß hier auch sämtliche Vendors
> welche OpenSSH einsetzen (OpenSSH wird auch ohne Linux in
> zahlreichen Kommerziellen Produkten eingesetzt, ich meine aber
> auch Rotk. und Susie) ihrer Verantwortung nicht nachgekommen
> sind. Verkaufen ja, Code audit, wozu?

Gerade bei OpenSSL wurden wohl mehrere gemacht. Ein Audit kann
aber schlecht feststellen: zu viel komplexe direkte
Buffermanipulationen, zurück an Entwicklung, Kommando "highlevel lib
einsetzen". Erstens würde es nur halbsoschnell (runtime)
zurückkommen, zweitens erst in drei Jahren, wenn überhaupt. Die
Audits werden schon genug Sachen gefunden haben, aber testen kann
man ja bekanntlich nur die Anwesenheit von Fehlern, nicht deren
Abwesenheit. Früher konnte man noch mit "noise" was machen:
schmeiß einfach Zufallsdaten oder fast-Zufallsdaten in Dein
Programm. Stürzt es ab, ab in die Entwicklung. Mach mal "ASN.1
noise"! Dazu mußte ja Zufallsdaten ASN.1 kodieren (als DER
kodieren). Dabei hier und da Kodierungsfehler einbauen, aber
bloß nicht überall, dann testet man ja nur die Längenprüfung oder
sowas. Jedenfalls wird sowas schon ziemlich komplex. 

> Vielleicht tue ich Susie und Rotk. damit unrecht, weiß nicht,
> jedenfalls steht auf den Webseiten viel Marketingbla und bitte
> kaufen. Audit?  Rotk. und Susie tun ja einiges für die
> Community, das muß man ihnen schon zu gute halten.

Ja, tun sie, weil sie Geld verdienen wollen. Beide interessiert
es überhaupt nicht, wieviel Bugs KDE hat. Sie packen das auf CD,
was sich verkauft, und so, wie es sich verkauft. Inzwischen ist
die Zielgruppe für Win und Linux sehr ähnlich, also auch die
Anforderungen sehr ähnlich. Die sind also gar nicht mehr "Stabil
bis der Arzt kommt", sondern bunt und animierte Dialoge.

> > Schreibt man ne Routersoftware, hat man vermutlich in der
> > Regel höhere Qualitätsansprüche als an ein PC Programm, von
> > dem ja eh jeder erwartet, daß 10% der Funktionen nur in 10%
> > der Fälle richtig funktionieren ;)
> Dieses angelernte Niedrigsterwartungsverhalten zeugt doch nur
> von der schlechten Qualität, oder? 

Erstmal "Ja". Aber es gibt auch ein Aber :) Qualität ist ja das
Erreichen von Anforderungen (Qualitätskriterien). Wenn die
Anforderungen (wie vermutlich bei Dir) sind: "stabil, bis der
Arzt kommt", ist es schlechte Qualität, weil nicht erreicht. Wenn
die aber (wie bei vermutlich der absoluten Mehrheit) sind: "Bunt
und animierte Dialoge" sind die Ziele schon erreicht.

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. 

> Es ist schon ein Unterschied ob ich erstmal 100 Zeilen
> Programmieren muß, bis ich ein Fenster habe, dann ein Menü,
> dann Menüeinträge, Fensterinhalt, buttons oder ob ich schreibe
> (lisp-like):
> 
> (window
> 	(menu
> 		(submenu1)
> 		(submenu2))
> 	(frame
> 		(image "/root/tollesbild.jpg")
> 	(button "bla")))

Fehlt sicherlich die Fehlerbehandlung, daß sind 90 der 100
Zeilen. Am Ende also in etwa gleich, oder?

Ich finde, Komplexität hängt nicht direkt von der Codelänge ab.
Oft ist längerer, "auf Lesbarkeit optimierter" Code einfacher,
als kompakter.

> > Interessant, dann ist OSS also ein prima Beispiel für "CMM Level 0"
> >
> > :) Keine Community, sondern eine Einzelkämpfersammlung?
> Möchte ergänzend hinzufügen:
> ... einzelner Individuen ergibt, welche eine ihnen gerechte und entsprechende 
> community um sich scharen. 

Na, "Mitläufer" oder Teamkollegen - was meinst Du jetzt?
Sicherlich gibt's viele Teams mit einer Handvoll "Guter", klar.
Ich meinte eben nur, "die Community" gibt es so nicht mit den
"alten Idealen", sondern mit "bunt und animierten Dialogen".

> Die Masse der OSS Entwickler sind wohl eher zu eint, zu weit
> oder zu dritt unterwegs. Ich glaub das könnte man durch analyse
> von SourceForge bestätigen.

Ja, mag sein, genau. Das von "überall Patches" kommen, ist nicht
mehr so. Es mag 10.000 Leute geben, die patches schicken, früher
wie heute (und das mein ich ernst, ich glaub, es sind nicht mehr
geworden). Früher gabs z.B. 10 Millionen Zeilen Code und 100.000
Leute. Also haben 10% der Leute gepatcht, eintausend Zeilen Code
kamen auf jeden Patcher. Heute hat man 200 Millionen Zeilen Code
und 1 Millionen Leute. Also patchen nur 1% der Leute, und 20.000
Zeilen Code je Patcher. Ich find, daß hat sich schon ganz schön
verändert :)

> > Na, das KDE funktioniert dann mindestens genauso schlecht wie
> > WinXP, ist dafür bißchen bunter.
> Jupp, mein neuester Favorit ist der, daß die Verzeichnisse in
> Baumansicht ständig an meinem Mauszeiger kleben bleiben obwohl
> ich nur einmal drauf klicke, also die Maustaste gleich wieder
> löse, aber irgendwie ignoriert KDE das lösen der Maustaste...

Nimm doch was anderes. Das ist eine Linuxstärke :) 

> Microsoft Longhorn, hab mir die Demo Videos im Netz angeschaut,
> whooaa, coool.  

Kenn ich nicht. Was ist da CooL? Kann man endlich ein Video als
Hintergrund vor transparenten Fenstern installieren?

> Ich glaub da wird die OSS Community ne ganze Weile
> hinterherhecheln wenn das weiter so geht mit den X-Forks (Hat
> jemand mitgezählt wie viele X-Forks und Y-Versionen es schon
> gibt?)

Weiß nicht, wovon Du redest. Welchen Longhorn-Feature(s) wird man
nachhechlen?

> > Aber bei den Internet-Domains sieht man, was die Mehrzahl
> > wünscht: ne Domain direkt unter TLD.
> Vielleicht liegt bei diesem speziellen Beispiel daran, daß bei
> den Domains einfach keine Struktur angeboten wird?

"angeboten" von wem? Von der Technik natürlich, klar. In UK
gibt's immerhin schon co.uk, gut, iss egal, sind sie alle da :)
Strukturen muß man schaffen, aber genau das passiert in unserer
sozialen Welt eben nicht, weil es 90% überhaupt nicht
interessiert. Hauptsache geht (und bunt), ob gut oder schlecht
ist egal. Seh ich z.B. anders.

> > > Der Nachahmungstrieb wird ersichtlich, die Innovation bleibt
> > > unsichtbar.
> >
> > Ja, eigentlich erstaunlich. Da gibt's ein Linux, weil Leute was
> > freies mit anderen Eigenschaften wollte. War ne Elite übermüdeter
> > Studenten oder so, egal. War schick, daß es einfach nur läuft,
> > wen interessiert bunt und GUI und sowas. Dafür druckts auch wenn
> > man es eilig hat.
> :)
> Jo, nur mit drucken allein kann man den Desktop nicht erobern.

Ich frag mich heute noch, wer auch die dämliche Idee kam, Linux
sollte den Desktop erobern. Vielleicht hätte man Linux
geheimhalten sollen, dann gäbe es vielleicht kein KDE aber es
wäre stabil :) Aber vielleicht könnte ich es nicht bei der Arbeit
verwenden, wäre auch doof...

Die Stärke von Linux (oder besser: GNU und OpSrc) muß doch sein,
sich eben nicht von der Masse sondern von Klasse leiten zu
lassen. Wenn man ein Windows look-a-like haben will, warum
installiert man sich dann nicht einfach Windows? Versteh ich
nicht - hat doch animierte Dialoge?! Gut, Windows geht nicht im
Netzwerk, muß man also ne Schnittstelle bauen, ein FTP client
oder so (was schlaues, vernünftiges) und gut ist.

> Hab mir mal verschiedene IDEs angeschaut: Quanta, Kdevelop, NetBeans, Eclipse 
> Daraufhin habe ich beschlossen mich wieder in emacs einzuarbeiten, den ich 
> damals, vor Jahren, für einen Texteditor zu groß befand (6MB bei 32MB RAM), 
> heute aber als schlanke IDE (Nur 12MB), welche leicht zu erweitern ist, 
> betrachte :)  

Ich brauch gar keine IDE, also das I vor allem nicht. Ich hab den
vim, auch sehr schlank. Schätze, vim und Emacs können für 90% der
Leute das gleiche. Mag Detailunterschiede geben, aber sind beides
erstmal Hightech-Editoren. Ich bin mit dem vim ziemlich schnell
geworden und kann damit gut programmieren (und Du eben mit dem
Emacs). Da IDE und externer Editor nicht gut geht, weil's da
keine (ja, außer Emacs -server :)) Schnittstellen gibt, also für
mich schlecht mit IDE. 

Ich benutz manchmal bissel MS Visual Studio, eigentlich ne gute
Software. Aber nix für mich: haste da 100 Zeichen-Zeilen,
formatieren geht nicht (insbesondere in mehrzeiligen Kommentaren
sehr nervig). Dafür kommt er mit einer schlauen Contextabhängigen
Vervollständigung. Gut, ich hab auch mal gesagt, daß sowas nur
verhindert, gute Bezeichner zu vergeben, weil man sich die ja
nicht mehr merken muß :) 

IDE und Texteditor sind IMHO zwei paar Schuhe, von denen ich
erstere trage. Gut, ich nehm eben den gdb im Textmode, wenn ich
mal was nicht finde, hab das aber sehr selten (einmal die
Woche?). Leute, die mit MS VC arbeiten, verwenden oft den
Debugger schon als Erstellungswerkzeug: Code ausprobieren nenn
ich das. Das ist IMHO für die Qualität sehr gefährlich. Debuggen
muß schon bißchen umständlich sein, damit man es eben nicht "per
Default" verwendet :)

> > ... und gerade dieses Argument hat sicherlich wenige von denen
> > überzeugt, die Linux selbst verwenden.
> > Vielleicht spielt es bei
> > gewissen Entscheidungsträgern eine Rolle, aber das war's auch
> > schon. Und man muß ja dagegen halten, daß jeder Sicherheitsbug
> > teurer ist, als ne CPU mit 100 MHz mehr :)

> Ja, hast recht, so habe ich das noch nicht gesehen. Das
> Hautargument für Linux ist wohl, daß es in _wohl_definierten_
> Bereichen (Server, "desktops" mit klar eingegrenzten
> Funktionsbereichen, also zb. darstellung einer eingabemaske für
> Versicherungskram und e-mail) konstengünstig einzusetzen ist
> und dabei gleichzeitig genügend flexibilität für eventuelle
> erweiterungen bietet.

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.

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ß". In Firmen
werden Briefe geschrieben und eMails beantwortet. Beides keine
Windowsgründe. Linux *geht schon jetzt* auf dem Firmendesktop -
man will es aber nicht. Mit einer guten IT ist Linux billiger,
aber man hat weder gute IT noch überhaupt ausreichend IT
Resourcen (kostet ja erstmal Geld!). Flexiblität nutzt man gar
nicht mehr aus. Früher war ein Unix-System immer irgendwie
angepaßt. Jetzt kommen auf einemal welche, die erzählen was von
"LAMP" (und gerade mySQL dabei! Unglaublich! Und PHP! Ohh Gott!)
aus der Dose, aus'm Regal - und genau das ist Unix eben nicht,
hier macht es keinen Sinn, finde ich.

>  Aber als Wuser Desktop ist das nix, weil der Wuser alles will,
>  jetzt, sofort, per Mausklick, Fehlerfrei, Bunt? egal,
>  Benutzerfreundlich. Treiber? Wozu?  -> Start!

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!

> möchte mich daher anders ausdrücken:
> Ich glaub die Community will nix. Einzelne Individuen, kleine
> Gruppen wollen vielleicht das, oder jenes ...

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

oki,

Steffen

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