[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ?Mediaplayer und automatische Updates ...



On Tue, Jul 02, 2002 at 11:25:59AM +0200, Peter Rossini wrote:
> Hi Holger,
> 
> Microsoft baut im Hause das Chaos, Linux ueberall. *BSD (zumindest 

Jein. Ich halte Microsoft durchaus auch fuer das Reich des Boesen,
aber nicht aus diesem Grund (der Grund steht im Grunde im Subject).
Selbstverstaendlich schreiben die jede Menge Bananensoftware, an-
gefuellt mit wackligen und unbrauchbaren und unsicheren Features,
aber man kann realistisch nicht behaupten, dass dies durch Open-Source
nicht genauso passiert - der technische Pfusch ist derselbe. Was
es aber gibt, insbesondere im Bereich Treiberentwicklung und API-
Dokumentation, ist ein recht komplettes Regelwerk, welches ich bei
Open-Source schmerzlich vermisse - ein lapidares "sieh doch im
Sourcecode nach" ist das Schlechtestmoegliche, und dass die Manpages
trotz einem "linux-documentation-project" schon seit den Anfangszeiten
von Unix als unbrauchbar angesehen wurden, ist bekannt. Note:
es geht jetzt nicht um den Vollstaendigkeitsgrad der Beschreibung
der Win32-API - auch da sind Luecken und Ungenauigkeiten, sondern es geht
darum, dass ueberhaupt Sekundaerdokumentation und -spezifikationen
existieren. Wo das nicht der Fall ist, herrscht Anarchie: alles darf
gemacht werden.

> FreeBSD, das ich selbst verwende) scheint besser zu sein, weil es wohl 
> kompetente Fuehrungsteams gibt. Dafuer dauert das eben alles etwas 
> laenger und der "gemeine" Nutzer ist nicht geduldig genug, auf einen 
> Treiber fuer die schicke 99-Euro-Bratpfanne mit USB-Interface zu 
> warten..

Ich beschaeftige mich seit langem mit OS/2 - frage Google nach meinem Namen,
und kenne daher die Problematik. Diese liegt schlichtweg darin, dass
die Anwender nicht nachdenken, bevor sie die 99-Euro-Bratpfanne kaufen,
sondern einfach aus dem Bauch entscheiden. Das ging bei OS/2 schon immer
schief, weil die Treibersituation da mangels Verbreitung dort deutlich
angespannter ist.

> Tja, wie stellt man das Ganze also sinnvoll an?
> 
> Du bist einfach auf die bei Vollmond geschriebenen Treiber angewiesen, 
> wenn Du die Bratpfanne doch verwenden willst. Wenn dann wenigstens 

Der Fehler lag wie gesagt darin, ueberhaupt die Bratpfanne vom Grabbeltisch
zu kaufen, statt sich vorher im Linux-Bratpfannenkatalog ueber unter-
stuetzte Pfannen zu informieren. Zwar mag es irgendwann mal der
Fall sein, dass es da dann einen Treiber geben wird, aber wer sich darauf
verlaesst, ist meist ziemlich verlassen, es sei denn, er macht es sich zur
Aufgabe, einen solchen zu basteln.

> der Quelltext da ist, kann vielleicht mindest ein kompetentes Menschlein 
> irgendwo auf der Welt draufgucken, warum es hier nicht laeuft, wenn 
> der Mond ueber Norden nach Westen wandert.

Das "Draufgucken" bei Open-Source ist meiner Ansicht ein viel gepflegter
Mythos der Szene. Es hat sich auch hier ein Kartell of Trust etabliert -
man verlaesst sich auf die Entwickler oder die Zusammenstricker einer
Distribution, dass alles zusammenspielt. Vielleicht meldet man einen
festgestellten Bug und hofft, dass dieser beim naechsten Release
beseitigt ist (und dieses Release dann nicht anderweitig die eigene
Konfiguration umreisst - neulich stelle ich fest, dass ich bei SuSE 7.2
als Client nicht mehr via ssh in unseren Server komme: da hat jemand auf
dem Server OpenSSH installiert und ssh-v1 abgedreht: Ja, da uebersetzt 
man doch einfach schnell mal eine neue ssh - nix da, das haette eine
neue ssl-Bibliothek, eine Pseudo-Random-Generator-Library und wer weiss was
noch fuer anderen Firlefanz benoetigt - bei nichts von dem ist klar, ob
durch die Installation nicht irgendwas anderes kaputt geht.

Sowas ist einfach unprofessionell und schlecht.

> Ich bin kein Linuxhacker und kenne die Umgangsformen nicht. Aber 
> vielleicht haut ja mal ein in der Entwicklung eines Entwicklerkernels 
> gestoerter Entwickler dem Mondsuechtigen auf die Pfoten und verbietet 
> ihm, nochmal so einen Mondfug zu verzapfen.

Es gibt die unterschiedlichsten "Philosophien" dazu; die Avantgarde ist
ueberhaupt nicht interessiert daran, dass man ernsthaft mit dem Gesamt-
system arbeiten koennen soll/will - der Weg ist das Ziel; es muessen
immer mehr neue Gimmicks aufeinandergetuermt werden: Journalling-
Filesysteme sind derzeit in Mode: aber keines ist fuer langfristigen
Betrieb brauchbar (ihr grosser Vorteil: der Filesystemcheck bei Absturz
geht schneller: das ist eigentlich eine Motivation, vorhandene Bugs
nicht auszubauen, weil sonst der Vorteil nicht mehr evident ist).
Die Traditionalisten versuchen ein stabiles System zu konstruieren.
Leider sind diese in der Minderzahl und werden von den nach immer
neuen Features geifernden Kiddiemassen ueberrollt.

Beiden Gruppen, den Avantgardisten wie den Traditionalisten, ist
allerdings die Bodensatzarbeit, die Systemeigenschaften zu
dokumentieren und festzulegen, zuwider; erstens ist es Drecksarbeit und
zweitens ist Kompatibilitaet fortschrittsfeindlich. Ein Standard wie
der Filesystem-Hierarchy-Standard wird von Distributoren nach Belieben
ignoriert, wo es geschaeftsbehindernd ist (Marktmacht rulez,
wie bei HTML zwischen Netscape und Explorer), und wenn man versucht,
einen Minimalstandard fuer Dokumentation oder Codingstyle (oder eine
API und einen Programmer's Guide zum Treiberschreiben) zu etablieren,
dann wird er bestenfalls ignoriert, schlimmstenfalls wird der Autor als
"Spalter" geaechtet. Als solcher will man in der Szene natuerlich nicht 
gelten. 

Und als "User", der mit Linux arbeiten will, auch nicht. Waere nicht 3L33t.

Gruesse
Holger

-- 
Please update your tables to my new e-mail address: 
holger.veit$ais.fhg.de  (replace the '$' with '@'  -- spam-protection)


-- 
To unsubscribe, e-mail: debate-unsubscribe@lists.fitug.de
For additional commands, e-mail: debate-help@lists.fitug.de