Message 07707 [Homepage] [Navigation]
Thread: oxdeT07707 Message: 1/1 L0 [In index]
[First in Thread] [Last in Thread] [Date Next] [Date Prev]
[Next in Thread] [Prev in Thread] [Next Thread] [Prev Thread]

[ox] Schnipsel 4/6



Liebe Liste,

und noch mehr. Jetzt bin ich sogar im vergangenen Jahr angekommen ;-) .


						Mit Freien Grüßen

						Stefan

--- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< ---

Aus: Linux-Magazin 1/03, Seite 21

Fundierte Linux-Studie der Deutschen Bank

Das Geschäftsmodell Open Source ist gescheitert, der Siegeszug von
Linux ist trotzdem nicht aufzuhalten. Das ist die Quintessenz einer
Studie von DB Research, der wirtschaftswissenschaftlichen
Forschungsabteilung in der Deutschen Bank. Linux werde zunehmend von
den Hardwareherstellern als Katalysator für weiteres Wachstum
verwendet und deshalb unterstützt.

Die Gefahr der Vereinnahmung besteht laut DB Research dabei durchaus.
Als weiteren Motor der Linux-Entwicklung sieht DB Research die
öffentliche Verwaltung, übrigens nicht nur in Europa und China,
sondern durchaus auch in den USA. Die klassischen Argumente gegen Open
Source, zum Beispiel fehlender Support und haftungsrechtliche
Erwägungen, hätten zunehmend ausgedient. Demgegen über seien die alten
Argumente dafür nach wie vor gültig: günstiger Anschaffungspreis,
Stabilität und überschaubare Supportkosten.

Ein Argument gegen Open Source stellten die Autoren an den Schluss des
zwölfseitigen Papiers: Bisher habe Open-Source-Software lediglich
vorhandene Funktionalitäten auf neuen, besseren Wegen realisiert, kaum
jedoch neue Bedürfnisse erkannt und danach deren Lösung versucht.

--- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< ---

Aus: Linux-Magazin 1/03, Seite 21

Microsoft räumt Fehler beim Kampf gegen Linux ein

In einem internen Microsoft-Papier gibt die Firma zu, dass die
Konfrontationsstrategie gegen Linux bisher keinen Erfolg hatte.
Äußerungen wie Steve Ballmers berühmter Krebsgeschwür-Vergleich hätten
in der Öffentlichkeit kaum etwas bewirkt.

Das Memo fand seinen Weg auf die Website der Open-Source-Initiative
OSI [www.opensource.com]. Laut OSI-Informationen sei es auf einer
Strategietagung Microsofts in Berlin präsentiert worden. Es nimmt
Bezug auf eine Umfrage unter IT-Entscheidern.

Microsoft musste feststellen, dass, wer sich einmal mit Open Source
beschäftigt hat, diesem Gedanken positiv gegenübersteht. 78 Prozent
der Befragten, die solche Software kennen, mögen sie. Auch die von
Microsoft oft angeführten Gegenargumente konnten wenig ändern.
Besonders die niedrigen Total Costs of Ownership (TCO) sind ein
Hauptargument für Linux. Die größte Akzeptanz stellte Microsoft in
Deutschland, Frankreich und Brasilien fest.

--- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< ---

[Und wieder was zum OHA-Thema. Aus Zacks Kernel-News, die übrigens
allgemein sehr interessant sind und auch häufiger diesen Komplex
berühren.]

Aus: Linux-Magazin 1/03, Seite 22

Gedanken zum Feature Freeze

Seit Monaten stand das Datum für das Feature Freeze von Kernel 2.5
fest: Halloween, der 31. Oktober 2002. Es scheint, als hätte die
Entwicklergemeinde diesmal das Datum ernst genommen. Objektiv
feststellen lässt sich das freilich nur schwer. Vor dem Stichtag
standen die Entwickler jedenfalls regelrecht Schlange, um ihre
Änderungen integrieren zu lassen; nötig war das aber nicht immer. Neue
Features, bei denen keine Störung anderer Komponenten zu erwarten ist,
können unter Umständen auch nach diesem Datum noch eine ganze Weile
berücksichtigt werden.

Früher lagen oft Jahre zwischen aufeinander folgenden stabilen
Kernel-Reihen - und der Kernel ist auch nicht das einzige freie
Projekt, das Schwierigkeiten bei der Einführung stabiler Versionen
hatte. Fast alle großen Projekte und viele kleinere zeigen das gleiche
Verhalten. Der Übergang von einem Entwicklungsmodus in einen Zustand,
in dem die Stabilität Priorität genießt, gilt somit als eines der
großen, noch ungelösten Probleme der freien Software.

Sollte diesmal die Kernel-Entwicklung tatsächlich einen Gang
hochschalten und einen neuen stabilen Baum innerhalb eines annehmbaren
Zeitraums hervorbringen - und das ist zu erwarten -, so ist das eine
bedeutende Leistung in der Evolution des Entwicklungsprozesses. Linus'
großartige Entdeckung im Jahr 1991 war, dass ein Projekt, das alle
interessierten Teilnehmer - ungeachtet ihrer technischen Fähigkeiten -
zum aktiven Mitmachen einlädt, wächst, gedeiht und sogar die Leistung
von kleinen,in der Abgeschiedenheit arbeitenden Expertenteams
übertreffen kann.

Dieser Entwicklungsansatz führte zwar zu einer riesigen Menge an
Features, aber er lässt sich nur schwer in Richtung Vollendung eines
Produkts lenken. Kaum war ein Feature stabilisiert, wurde mit einem
neuen angefangen. Und während man auf eine Stabilisierung des neuen
Features wartete, hatte das ältere jede Gelegenheit, Ausflüge in
weniger stabile Gefilde zu wagen.

Es war also nötig, Code von einer Gruppe zu akzeptieren und
gleichzeitig darauf zu bestehen, dass die Entwicklungsarbeit anderer
Gruppen eingefroren wird. Das hat viele Male Wut und Verbitterung bei
den freiwilligen Mitarbeitern hervorgerufen. Mit diesem Problem sieht
sich ein Großteil der Free-Software-Projekte konfrontiert. Der
Fortschritt des 2.5er Kernels in Richtung einer 2.6.0er Version wird
zeigen, wieweit diese Aufgabe gelöst werden konnte.

--- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< ---

Aus: c't 3/03, Seite 132

Börsen-Trends

Tauschrausch - am Ende oder nicht zu bremsen?

http://www.heise.de/ct/03/03/132/

--- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< ---

[Mehr oder weniger more of the same - ich nehme aus dem folgenden
Artikel nur ein paar besonders interessante Abschnitte raus.]

Aus: iX 4/03, Seite 18

Zahlenspiele

IT-Konsolidierung mit Open Source

Sebastian Hetze

*Bei der Entscheidung für oder wider eine Einführung von Linux als
neuer Plattform spielen die Kosten eine zentrale Rolle. Eine Konferenz
unter dem Motto "Die Pinguin-Lösung IT-Konsolidierung mit Open Source"
bot Einblicke in reale TCO-Betrchtungen.*

Linux kann heute nicht nur einen erheblichen Marktanteil vorweisen,
sondern verfügt auch über eine installierte Basis. Damit lassen sich
für Wirtschaftlichkeitsbetrachtungen neben den beauftragten Studien
der jeweiligen Protagonisten auch erste Erfahrungswerte aus
Unternehmen heranziehen, die nicht im Verdacht einer mutwilligen
Färbung für die eine oder andere Seite stehen. Eine von Marcus Evans
organisierte Konferenz im Februar 2003 unter dem Motto "Die
Pinguin-Lösung - IT-Konsolidierung mit Open Source" stellte sieben
Fallstudien mit interessanten Einsichten vor.

[...Erkenntnis: Linux ersetzt vor allem andere Unices...]

Offensichtlich tut sich Linux auf der anderen Seite schwer, das von
Unix bisher an Windows NT abgegebene Terrain zurückzuerobern. Ein
interessanter Aspekt im Vergleich von Windows und Linux trat in der
IT-Wirtschaftlichkeitsbetrachtung der Bertelsmann-Tochter Avarto
Systems zu Tage. Hier administriert ein Mitarbeiter im Schnitt 60 bis
80 Windows-Server, während nicht weniger qualifizierte Mitarbeiter nur
25 Linux-Server betreuen können. Im Vergleich sind es rund 30
traditionelle Unix-Server je Mitarbeiter. Setzt man pro Administrator
Kosten von 50000 Euro im Jahr an, ergibt sich für die TCO an diesem
einen Posten ein Vorteil von rund 1300 Euro je Server und Jahr für die
Windows-Seite.

Bei der genaueren Untersuchung dieser großen Diskrepanz stellte sich
heraus, dass die Administratoren beider Systeme etwa die gleiche Zahl
betriebssystem-begründeter Vorgänge je Server zu bearbeiten hatten.
Allerdings behob man die Probleme mit den Windows-Servern in der Regel
per Reboot, während man bei den Linux-Servern Zeit in eine Fehlersuche
und -lösung investierte. Das Verblüffende daran: Offenbar ist die
Benutzerzufriedenheit auf der Windows-Seite nicht geringer als die auf
der Linux-Seite. Inwieweit die Benutzer die Windows-typische
Reboot-Strategie auch bei Linux-Servern akzeptieren würden und wie
sich die eine oder andere Strategie auf die Motivation der
Administratoren auswirkt, wurde bisher nicht untersucht.

Ein beeindruckendes Beispiel für ein ganz anderes Verhältnis bei den
Administrationskosten liefert das Massenhosting von Webservern bei
1&1/Schlund + Partner. Hier betreut ein Mitarbeiter rund 500
Linux-Server. 1&1 hostet weniger als 1% von mehr als 3 Millionen
Domains auf Windows-Servern und benötigt für deren Administration
genau so viele Mitarbeiter wie für alle anderen Domains zusammen.
Diese krasse Diskrepanz erklärt sich zum einen daraus, dass Linux auf
identischer Hardware das 4- bis 5-fache an Domains hosten kann. Der
eigentliche Schlüssel für die bessere Effizienz der Linux-Server liegt
im hohen Automatisierungsgrad, den man auf Basis von Debian Gnu/Linux
bei der Installation und Konfiguration sowie dem Monitoring der
Systeme erreichen konnte.

[...]

--- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< ---

[Und nochmal zur OHA-Frage in der Freien Software.]

Aus: Linux-Magazin 4/03, Seite 46

Entwickler-Dramen

Der Entwicklungsprozess der IDE-Treiber - ein Blick hinter die
Kulissen

*Bei der Entwicklung des Linux-Kernels spielen sich wahre Dramen ab,
das zeigt die Historie der IDE-Schicht am besten. Deutlich wird hier
aber auch, wie die Community schwere Krisen bewältigt.*

Zack Brown, Ulrich Wolf

IDE, Kürzel für Integrated Driver Electronics, ist jenes Protokoll,
das für die Flachbandkabel von der Festplatte zum Mainboard gilt. Wer
also kein SCSI- oder Diskless-System betreibt, kann ohne
funktionierende IDE-Schicht mit seinem Rechner gar nichts anfangen.
Umso erstaunlicher, dass gerade die Entwicklung dieser wichtigen
Treiberschicht mehrfach auf Messer Schneide stand.

Die IDE-Schicht - von Natur aus schwierig

IDE ist nicht irgendein ganz normaler Treiber oder Standard. Das
ursprüngliche Design definierte Compaq Mitte der 80er Jahre, seitdem
hat sich daraus ein Gemisch aus unterschiedlichen anderen Standards
und herstellerspezifischen Variationen entwickelt, die den Support zum
Alptraum machen. Bis zur Mitte der 90er Jahre hatte Mark Lord bei der
IDE-Treiberentwicklung den Hut auf, letztlich eine Sisyphosarbeit.

IDE-Treiber gehören zu den ersten Verdächtigen, wenn bei irgendeinem
Nutzer Daten beschädigt werden. Aus diesem Grunde analysierten Mark
und sein Team unzählige Reports über verlorene Daten: Sie führten die
meisten Ausfälle auf Hardwarefehler zurück, gelegentlich auch auf Bugs
im Kernel, manchmal aber tatsächlich auf die IDE-Schicht selbst. Die
Treiber verbesserten sich, aber die Reports wurden nicht weniger, für
kaputte Dateisysteme gibt es viele Ursachen. Oft schob man der
IDE-Schicht so lange die Schuld zu, bis die wahre Ursache offen lag.
Dagegen ließ sich kaum etwas tun.

Im Sommer 1998 kam es dann zum Eklat. Der Kernel steckte tief in der
2.1-Entwicklungsphase, auf dem Weg zu 2.2, und immer wieder tauchten
Meldungen über Beschädigungen von Festplatten bei angeschaltetem
DMA-Support auf. Alan Cox ging Hinweisen nach, dass es nicht an diesem
liegt, sondern an dem SMP-Code, also einer ganz anderen Baustelle.
Damals war SMP-Unterstützung per Default aktiviert, vor allem weil
Linus Torvalds selbst ein SMP-System benutzte. Das machte es schwer,
Fehlerursachen einzugrenzen; deaktivierte SMP-Systeme zu
Vergleichszwecken waren selten.

Linus weigerte sich SMP schon in 2.1 zu deaktivieren. Ihn frustrierte
hingegen, dass Mark Lord den DMA-Support nicht per Default
abschaltete. Mit einem einzeiligen Patch in Version 2.1.111 klemmte
Linus schließlich DMA komplett ab, es gab nicht einmal eine
Konfigurationsoption. Linus war sich zwar fast sicher, dass die
Probleme nicht durch Marks Arbeit verursacht wurden, wollte aber mit
dieser Aktion die "Angelegenheit aufs Radar bringen".

Damit hatte er den Bogen überspannt. Mark trat offiziell als
Maintainer zurück, lieferte eine Zeit lang aber nach wie vor Patches,
sogar das umstrittene zur Default-mäßigen DMA-Deaktivierung, das Linus
so sehr wollte. In diesen Wochen des Interregnums begann Andre
Hedricks Aufstieg zu einem der aktivsten IDE-Entwickler, was
allerdings, wie sich zeigen sollte, das weitere Schicksal der
IDE-Schicht nicht einfacher machte. Zunächst aber wurde Andre mit
Kernelversion 2.1.122 IDE-Maintainer und leistete zusammen mit einer
Handvoll anderer Leute, inklusive Mark Lord, jahrelang gute Arbeit.

Der Treiber unterstützte mehr und mehr Hardware und alle waren sich
einig, dass Datenverlust durch schlechte Linux-Treiber das absolut
Unakzeptable ist. Andre trat deshalb mit Hardwareherstellern und
Standardisierungsgremien in Verbindung, unterzeichnete NDAs, die ihm
Zugang zu vertraulichen Informationen über zukünftige Hardware
erlaubten; aber er durfte sein Wissen nicht mit anderen Linux-Hackern
teilen.

Geheimnisvolle Hardware

Trotz aller Fortschritte blieb der IDE-Code verwirrend, wurde sogar
durch die zahlreichen, nun eingeflossenen Geheimnisse der
Hardwarehersteller noch undurchschaubarer. Manches, was wie simpelste
Aufräumarbeit aussah, wirkte sich verheerend auf das Gesamtsystem aus.
Naive Einsteiger lasen die Spezifikationen, um besser zu verstehen,
was vorging - nur um zu erfahren, dass diese oft völlig andere
Intentionen haben, als der Text aussagt.

Ohne eine riesige Menge an Arbeit ließ sich nicht das kleinste
Schräubchen bewegen, selbst wer diese Arbeit leistete, stieß oft auf
ein Industriegeheimnis und alles war vergebens. Im Februar 2002
(Kernelversionen 2.4.17 und 2.5.3) wurde klar, dass nur Andre Hedrick
und vielleicht noch zwei bis drei andere den Code verstehen konnten.
Selbst sehr erfahrene Programmierer hatten keine Chance mehr. Zu
dieser Zeit häuften sich erneut die Fehlerreports. Das motivierte zwar
viele Entwickler, sich auf den IDE-Code zu stürzen, die meisten
mussten aber hilflos akzeptieren, dass Andre ihre Patches zurückwies -
das tat er gelegentlich auch, wenn sie laut Linus korrekt waren.

Manchen gelang es aber doch, nützlichen Code beizutragen, allen voran
Marcin Dalecki. Er begann immer mehr Aufräum-Patches an Andre zu
schicken, die tief in das System eingriffen. Andre fühlte sich
bedrängt und verdächtigte Marcin sogar, einen Geheimplan zu verfolgen,
zusammen mit der Wagniskapital-Firma, die ihn beschäftigte. Der
Konflikt spitzte sich zu und Linus wurde zu einer Entscheidung
gedrängt. Er stellte sich auf die Seite von Marcin und warf Andre
Kritikunfähigkeit und bewusste Lügen über die Funktion mancher Patches
vor. Schließlich machte Linus Marcin zum Maintainer.

Marcin schüttelte eine Menge hässlichen Code raus, musste sich aber
den Vorwurf gefallen lassen, dass er ihn nicht immer durch besseren
ersetzte. Die IDE-Schicht des 2.5er Entwicklungskernels büßte mehr und
mehr Funktionalität ein und wurde immer instabiler. Die
Entwicklergemeinde zeigte Nervosität. Schließlich landete Jens Axboe
einen Befreiungsschlag in Form der Vorwärtsportierung der 2.4-Treiber
auf 2.5. Daraufhin schöpften einige wieder Mut und das
Entwicklungstempo zog an.

Ausmisten reicht nicht

Marcin sah sich nun mit der Frage konfrontiert, warum er nicht von
Anfang an zwei Entwicklungslinien gefahren hätte: eine mit dem
stabilen 2.4er Code und eine zum Aufräumen. Im Nachhinein ist jeder
klüger, aber bei der damaligen Situation, mit chaotischem Code,
chaotischer Politik und Entwicklern, die ausgebrannt waren und ihren
Ärger auf Linus oder Mitentwickler pflegten, stellte sich die Lage
anders dar. Im August 2002 warf Marcin das Handtuch. Die Vorwürfe
gegen ihn hatten nicht aufgehört, einstige Mitstreiter waren
abgewandert. Der Code befand sich in erbärmlichem Zustand und alle
Anwärter auf den Maintainer-Posten waren auf die eine oder andere
Weise diskreditiert.

An diesem Punkt ließ sich Alan Cox überreden, vorübergehend als
Maintainer zu arbeiten und zwischen Linus und Andre Hedrick zu
vermitteln. Auch Jens Axboe nahm einen Teil der Verantwortung auf
sich. Beide leiteten Patches von Andre an Linus weiter. Nun platzte
der Knoten. Andre hatte sich in der Zwischenzeit einen soliden Plan
zur Umstrukturierung des Treibers ausgedacht. Er konsultierte sich mit
Alan und dieser begann mit einer derartigen Geschwindigkeit an Design
und Implementierung zu arbeiten, dass nicht einmal Andre selbst folgen
konnte.

Happyend mit Alan Cox

Der Kern des neuen IDE-Treibers unterstützt jetzt ausschließlich das
offizielle Protokoll und ignoriert hardwarebedingte Ausnahmen, die
finden außerhalb des Kerns Platz. Chipsets und Controller sind
abstrahiert und ausgelagert, ein generisches API deckt erstmals alle
Spezialfälle und Inkonsistenzen ab. Das wirkt sich auch auf andere
Kernelbereiche aus, vor allem auf den PCI-Code, der anschließend eine
massive Überarbeitung brauchte.

Wer aber nun glaubt, dass derart massive Umbauten im Entwicklerkernel
stattfinden, also in 2.5, sieht sich getäuscht. Alan hatte sich für
sein Redesign den immer noch umfangreichen 2.4er Treiber genommen,
nicht das abgemagerte 2.5-Pendant. Marcello Tosati akzeptierte
schließlich das Patch für 2.4.21. Die Entwicklergemeinde nahm diesen
Schritt mit Freude auf.

Es bleibt jedoch nach wie vor genug zu tun, einschließlich der
Vorwärtsportierung in 2.5. Aber trotzdem scheint die ganze Geschichte
auf ein Happyend zuzusteuern. Ob Alan tatsächlich Maintainer bleibt,
ist offen, im Gespräch sind außerdem sowohl Jens Axboe als auch ein
geläuterter Andre Hedrick. Mittlerweile erscheint eine wesentliche
Erweiterung von IDE, Serial ATA, am Horizont. Neue Technik, neue
Treiber, Raum für neue Dramen. (uwo)

________________________________
Web-Site: http://www.oekonux.de/
Organisation: projekt oekonux.de



[English translation]
Thread: oxdeT07707 Message: 1/1 L0 [In index]
Message 07707 [Homepage] [Navigation]