[linux-l] DB (war: keine Limits eingestellt)

[Matthias Kranz]

On Tue, 2007-02-13 at 20:03 +0100, Volker Grabsch wrote:
> Genau dazu bin ich hier. Genaugenommen ist jeder dazu hier, von anderen
> zu lernen.

Mal abgesehen davon, dass du prinzipiell Recht haben könntest, ist es
gewagt von dir, einfach für alle zu sprechen.

> Stimmt, ein wesentlicher Unterschied. Außerdem muss ich zugeben, dass
> mein Eindruck mehr von SLES als von RHEL geprägt ist. Und in SLES ist
> beweitem nicht alles "weiß". :-)

Ich habe auch nicht behauptet, dass alle RH-Produkte heute schon diesem
Anspruch genügen, was aber eher historisch bedingt ist. Die
Einschränkungen gelten für den Red Hat Satellite Server, in dem im
Standard ein Embedded Oracle mitgeliefert wird, und für den Red hat
Directory Server, der ursprünglich von Netscape stammt. Der in Fedora
Core 6 enthaltene Directory Server steht allerdings schon komplett unter
GPL.

> ... was darauf hinaus läuft, dass der Support erstmal alle Schuld
> an irgendwelchen Problemen deinen Modifikationen zuschiebt, richtig?

Falsch. Red Hat lebt ausschließlich von Support, den der Code, den Red
Hat vertreibt, ist frei (in diesem Fall im Sinne von Freibier). Der
Support wird abonniert. Das heißt, dass Red Hat's Erfolg von der
Fähigkeit abhängt, seinen Support so zu liefern, dass die Kunden das
Abonnement verlängern.

In fast jedem Support-Fall fragt der Support nach einem so genannten
sysreport. Das Werkzeug sysreport fasst alle möglichen elementaren
Informationen auf einem System zusammen und packt sie in ein Archiv. Der
Support kann mittels dieses Reports sehr gut offline entscheiden, welche
Bestandteile des Systems vom Kunden modifiziert worden sind und welche
nicht.

Und noch einmal: Support ist nicht ein notwendiges Übel, welches Red hat
zu seinen Produkten anbietet, weil jeder Software-Hersteller das eben
macht. Sondern es ist ein Hauptbestandteil der Leistung für die der
Kunde Red Hat bezahlt. Nur wenn das Problem des Kunden schnell und für
ihn zufriedenstellend gelöst ist, hat das Produkt funktioniert.

> Bitte nicht aus dem Zusammenhang reißen. Mein Kommentar bezog sich
> konkret auf deine Worte:

Uiuiui. Jetzt verwechselst du mich mit Peter Ross, von dem die von dir
zitierten Worte stammten.

> Sicher gibt es gute technische Gründe, nicht zu viele verschiedene Unixe
> in der Firma herumrennen zu lassen. Diese hast du aber erst an zweiter
> Stelle (nach den "politischen Gründen") genannt.

Nicht ich sondern Peter hat sie genannt, aber egal.

Unabhängig davon bleiben die meisten Gedanken einfach naiv. Natürlich
gibt es politische Gründe, die manches Mal die Entscheidung für ein
Produkt beeinflussen. Keine Frage. Aber das für 99% aller
Enterprise-Unternehmen in produktiven Umgebungen der Einsatz eines
Systems wie Debian GNU/Linux oder FreeBSD nicht in Frage kommt ist ein
anderer, viel entscheidenderer: Ich bin eine große Bank und möchte Teile
meiner zentralen Geschäftsprozesse auf einem komplexen IT-System
betreiben. Ich habe also einen großen Stapel von Produkten, die ich
übereinander lege: SAN, Kabel, Switch, Kabel, HBA, PC, Betriebssystem,
Applikationssoftware. Und wenn ich bei fünf Minuten Stillstand einige
hundert Tausend oder sogar noch mehr Euro verliere, dann brauche ich
jemanden, den ich dafür ggf. zur Verantwortung ziehen kann. Im
allerschlimmsten Fall (tritt sehr, sehr selten ein, muss aber
berücksichtigt werden) will ich sogar Schadensersatz oder zumindest den
Erlös einer saftigen Vertragsstrafe in meine Risikovorsorge
einkalkulieren dürfen. Das kann ich aber nur, wenn ich im gesamten Stack
jemanden habe, mit dem ich das Spiel spielen kann. Damit scheiden ganz,
ganz viele Anbieter bzw. Möglichkeiten von vorn herein aus.

Um die großen Enterprise-Unternehmen in Schutz zu nehmen: Die wenigsten
tun es freiwillig, aber sie sind durch Regulation dazu gezwungen. Sie
müssen es dokumentieren und belegen, sonst sind sie im Ernstfall haftbar
zu machen.

Matthias
-- 
Matthias Kranz
Berlin/München
http://mkr.oerks.de