[linux-l] Dokumentenspeicher

[Volker Grabsch]

On Thu, Oct 05, 2006 at 01:02:29AM +0200, Frank Reker wrote:
> Am Wed 04. Oct 2006 14:20 +0000 schrieb Volker Grabsch:
> 
> >Jep. Sowas nennt man "bug for bug compatibility". Im Ernst, einige
> >Systeme *müssen* das tatsächlich können. Hier ist der Programmierer
> >an vielen Stelle gezweungen entgegen der Dokumentation zu arbeiten,
> >und es ist einer der unangenehmsten Aufträge, die man als Programmierer
> >IMHO haben kann.
> 
> also - so etwas DARF nicht sein. erst einmal MUSS man etwas so 
> schreiben, dass es ohne bug funktionieren wuerde! DANN kann oder
> muss man ein bug-workaround schreiben.

Eine gute Idee. Kommt aber darauf an, ob man die "bugfreie Variante"
überhaupt haben will.

Wenn auf ein existierendes System viele automatische Dienste zugreifen,
so sind sie von den Features genauso anhängig wie von den Bugs.

Klassisches Beispiel: Reimplementierung der Win32-API.

> dieses aber in ein makro
> kapseln, dass dann vom makefile aktiviert, bzw. deaktiviert werden
> kann. dass ganze kapselt man dann im config script in einen 
> automatischen test ob besagter workaround noetig ist, und gut ist!

Das merkt man erst im Einsatz. Wenn ein kommerzielles Computerspiel
mit Wine nicht funktioniert, muss Wine eben angepasst werden.

> aber eine "bug for bug 
> compatibility" vorauszusetzen ist ein gaenzlich falscher ansatz.
> und zeugt von einer INKOMPETENZ des programierers!
> ich bin programmierer, und hab manchmal mit schraegen systemen
> oder bugs zu tun. aber so einen miserablen programmierstil
> wuerd ich mir nicht erlauben.

Wenn ich die win32-API *benutze*, dann ist es völlig klar, dass
ich bei Bugs einen extra Layer programmiere, der mir ne "korrekte"
win32-API vorsetzt. Ich stimme dir vollkommen zu, dass dies kein
Anwendungsfall für "bug-for-bug-compatibility" ist.

Wenn ich aber ReactOS oder Wine schreiben, dass ist "bug for
bug compatibility" der einzig praktikable Weg. Und was ist mit
SNES- und ähnlichen Emulatoren?

Er ist nicht schön, aber das liegt nicht an den Programmieren,
sondern am Projekt selbst. Jetzt kann man natürlich argumentieren,
dass die Emulation von buggigen Systemen kein Projekt ist, das
ein guter Programmierer jemals annehmen würde.

Diese Projekte sind die Ausnahme. Und nicht umsonst habe ich gesagt,
dass sie die unangenehmsten sind. Es war lediglich ein Beispiel
dafür, dass die offizielle Doku nochmal neu geschrieben werden muss,
ergänzt um die "Bugs", die es mit zu implementieren gilt, da sonst
die für diese Systeme geschriebene Software einfach nicht läuft.

> wenn der kunde das nicht will, dann muss er eben einen dilletanten
> dran setzen. ICH mach nur vernuenftige arbeit - und ende der 
> diskussion.

Genau das hab ich ja gesagt. :-)
Diese Sorte von Projekten gehört zu den unangenehmsten. Ich würde
sowas auch nicht machen wollen, außer vielleicht aus Nostalgie.

Ich denke, du wusstest einfach nicht, worauf ich hinaus wollte.
Bei End-User-Anwendungen ist Bug-for-Bug-Kompatibilität natürlich
*niemals* das, was man will. OpenOffice sollte niemals Bugs von
MS-Office übernehmen. Aber Wine muss nunmal einige Dinge anders
machen als in der Win32-API beschrieben.

> einmal kam ich nicht umhin. da musste ich etwas programmieren,
> obwohl ich genau wusste, dass es eine sicherheitsluecke ist. nach
> stundenlangen diskussionen hab ich mich schliesslich drauf eingelassen,
> aber! ich habe den kram konfigurierbar gemacht. die standardeinstellung
> war die ohne sicherheitsluecke. hab dann ins handbuch einen _riesen_
> warnhinweis geschrieben, dass es absolut unratsam waere dieses
> "feature" zu aktivieren. dann hab ich selben hinweis auch ins 
> config-file geschrieben und besagtes "feature" deaktiviert. dann bin
> ich zum kunden gegangen und hab gesagt. "wenn du dieses feature willst,
> dann aktiviere es selbst, du musst nur besagte variable von "no" auf
> "yes" setzen." - das resultat: der kunde hat die konfiguration nie 
> veraendert, und auf das "feature" verzichtet... - mit anderen worten
> auch er hatte keine lust die verantwortung zu uebernehmen...
> der punkt ist - deligiert ist schnell. aber wenn man selbst vor
> der entscheidung steht - sieht die welt ganz anders aus...

Das ist ein guter Tipp. Werde ich mir merken, wenn ich mal vor
solch einer Entscheidung stehen sollte. Bisher hatte ich aber das
Glück, wenn auch manchmal erst nach Diskussionen, immer "sauberen"
Code produzieren zu können.

> ok - meine arbeit ist fuer qualitaet bekannt, deshalb akzeptieren
> kunden auch meine eigenheiten. auf der anderen seite, waere meine
> arbeit nicht fuer qualitaet bekannt, wenn ich mich nicht hin und
> wieder stur stellen wuerde.

So geht's mir auch. Ich hoffe, zukünftige Auftraggeber werden das
ebenfalls so sehen. Ich bin ebenfalls nicht sehr schnell und habe
pedantische Züge. Manchmal muss ich auch gebremst werden, das sehe
ich dann auch ein. Manchmal muss ich aber auch den Auftraggeber
bremsen. :-)


Viele Grüße,

    Volker

-- 
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR