Hi!
From: Adalbert Michelic [mailto:adalbert+list@lopez.at] * On Tue, 07 Jan 2003 at 13:11 +0100, Antwerpen, Oliver wrote:
From: Christian [mailto:christian@powerusers.de] Am Dienstag, 7. Januar 2003 10:27 schrieb Antwerpen, Oliver: <snip>
Der Unterschied liegt zB darin, dass der SLES für zB Oracle zertifiziert ist. Außerdem ist er auf zB diversen Compaq-Servern zertifiziert und es gibt verschiedene Support-Level seitens SuSE. Für den 'normalsterblichen' User ist das wohl egal, für den Business-Einsatz aber extrem wichtig... Extrem wichtig? Soso. Wen interessiert denn eine Zertifizierung?
Hmm, im Business-Bereich ist das schon wichtig. Was tust Du, wenn Deine DB nicht läuft, und der DB-Hersteller das NOS verantwortlich macht, der auf die Hardware tippt, und der Hersteller der Hardware die Software für fehlerhaft hält?
Sagst Du den jeweiligen Herstellern dann, daß es doch funktionieren muß, weil ja auf dem Papier steht, daß es funktioniert? Und dann siehst Du ihnen zu, wie sich sich trotzdem gegenseitig die Schuld in die Schuhe schieben?
Ja, und zur Not schalte ich einen Anwalt ein, der mir diese zugesicherte Eigenschaft einklagt. Oder eben einen Betrag X, der dadurch als Schaden entstanden ist.
Da ist es dann schon wichtig auf dem Papier stehen zu haben, dass alles zusammen funktioniert.
Papier ist leider sehr geduldig, schade ums Geld.
Ich glaube wir reden hier von ganz unterschiedlichen Standpunkten. Wenn ich meinem Kunden etwas anbiete, dann möchte ich sicher sein, dass es funktioniert. Mein Kunde läßt sich das ja auch von mir bestätigen und ich wiederum lasse es mir von Compaq/SuSE/Oracle bestätigen. So bin ich auf einer sehr viel sichereren Seite als ohne Zertifikat auf zB Debian. Für alles andere setze ich Debian ein, aber im kritischen Business-Bereich? Da geht leider nur sehr, sehr wenig ohne Papier.
So lange alles geht ist das eh egal, aber im Fehlerfall fangen die Probleme an.
Ja. Wenn nicht schon früher.
Probleme gibt's immer. Sonst wär's ja langweilig. Olli
* On Tue, 07 Jan 2003 at 14:04 +0100, Antwerpen, Oliver wrote:
From: Adalbert Michelic [mailto:adalbert+list@lopez.at] * On Tue, 07 Jan 2003 at 13:11 +0100, Antwerpen, Oliver wrote:
From: Christian [mailto:christian@powerusers.de] Am Dienstag, 7. Januar 2003 10:27 schrieb Antwerpen, Oliver: <snip>
Der Unterschied liegt zB darin, dass der SLES für zB Oracle zertifiziert ist. Außerdem ist er auf zB diversen Compaq-Servern zertifiziert und es gibt verschiedene Support-Level seitens SuSE. Für den 'normalsterblichen' User ist das wohl egal, für den Business-Einsatz aber extrem wichtig... Extrem wichtig? Soso. Wen interessiert denn eine Zertifizierung?
Hmm, im Business-Bereich ist das schon wichtig. Was tust Du, wenn Deine DB nicht läuft, und der DB-Hersteller das NOS verantwortlich macht, der auf die Hardware tippt, und der Hersteller der Hardware die Software für fehlerhaft hält?
Sagst Du den jeweiligen Herstellern dann, daß es doch funktionieren muß, weil ja auf dem Papier steht, daß es funktioniert? Und dann siehst Du ihnen zu, wie sich sich trotzdem gegenseitig die Schuld in die Schuhe schieben?
Ja, und zur Not schalte ich einen Anwalt ein, der mir diese zugesicherte Eigenschaft einklagt.
Und wenns trotzdem den Hersteller nicht interessiert, den Fehler zu beheben? Betrag X einklagen.
Oder eben einen Betrag X, der dadurch als Schaden entstanden ist.
Okay, nun hast Du den Betrag X, einen Hersteller der nix tut und immer noch einen Bug. Schöne Aussichten.
Da ist es dann schon wichtig auf dem Papier stehen zu haben, dass alles zusammen funktioniert.
Papier ist leider sehr geduldig, schade ums Geld.
Ich glaube wir reden hier von ganz unterschiedlichen Standpunkten.
Ich spreche vom Standpunkt des Kunden - ich arbeite teilweise für ein Krankenhaus, wo diese zertifizierten Sachen alle nur so durch die Gegend schwirren.
Wenn ich meinem Kunden etwas anbiete, dann möchte ich sicher sein, dass es funktioniert. Mein Kunde läßt sich das ja auch von mir bestätigen und ich wiederum lasse es mir von Compaq/SuSE/Oracle bestätigen. So bin ich auf einer sehr viel sichereren Seite als ohne Zertifikat auf zB Debian. Für alles andere setze ich Debian ein, aber im kritischen Business-Bereich? Da geht leider nur sehr, sehr wenig ohne Papier.
Bevor ich $BIGNUM EUR ausgebe, um ein Stück zertifizierte Software zu bekommen, schaue ich lieber, daß ich einen fähigen Programmierer und die Sourcen meiner Produkte zur Hand habe, dann kann ich wenigstens selbst eingreifen, wenns Fehler gibt. Wenn ich mir ansehe, wie die Hersteller mit den 3 Buchstaben langen Namen reagieren, wenns hier wirklich mal kriselt - Danke, ich verzichte auf Zertifizierungen. Im Fall des Falles hat man auch nichts als Scherereien und 2 Hersteller, die sich gegenseitig die Schuld zuschieben. -- Adalbert GPG welcome, request public key: mailto:adalbert+key@lopez.at
Hallo, Am Dienstag, 7. Januar 2003 14:49 schrieb Adalbert Michelic:
* On Tue, 07 Jan 2003 at 14:04 +0100, Antwerpen, Oliver wrote:
[...]
Wenn ich meinem Kunden etwas anbiete, dann möchte ich sicher sein, dass es funktioniert. Mein Kunde läßt sich das ja auch von mir bestätigen und ich wiederum lasse es mir von Compaq/SuSE/Oracle bestätigen. So bin ich auf einer sehr viel sichereren Seite als ohne Zertifikat auf zB Debian. Für alles andere setze ich Debian ein, aber im kritischen Business-Bereich? Da geht leider nur sehr, sehr wenig ohne Papier.
Bevor ich $BIGNUM EUR ausgebe, um ein Stück zertifizierte Software zu bekommen, schaue ich lieber, daß ich einen fähigen Programmierer und die Sourcen meiner Produkte zur Hand habe, dann kann ich wenigstens selbst eingreifen, wenns Fehler gibt.
Wenn ich mir ansehe, wie die Hersteller mit den 3 Buchstaben langen Namen reagieren, wenns hier wirklich mal kriselt - Danke, ich verzichte auf Zertifizierungen. Im Fall des Falles hat man auch nichts als Scherereien und 2 Hersteller, die sich gegenseitig die Schuld zuschieben.
Betrachte es mal umgekehrt: Hersteler wie Oracle oder SAP wollen sich auch absichern (kann ich nachvollziehen). Die schreiben sich dann in Ihre Supportbedingungen rein: "nur mit zertifizierter Hard- und Software". Und dann kommst du an mit einem Problem welches möglicherweise überhaupt rein gar nichts mit zertifizierter oder nicht-zertifizierter Umgebung zu tun hat sondern ganz simple ein Problem von SAP oder Oracle ist. Aber du kriegst keinen Support weil du dir zuvor deine "$BIGNUM EUR" für die zertifizierte Umgebung gespart hast. Schade, oder (deinen tollen "fähigen Programmierer" kannst du dir in dem Moment natürlich auch in der Pfeife rauchen, denn der wird dir den Bug in SAP bzw. Oracle auch nicht fixen können - egal wieviel Source-Code ihm zur Verfügung steht)? Und wenn du dann deinem Chef oder Auftraggeber gegenüber erklären musst, warum du (bzw. er) den Support von SAP bzw. Oracle nicht bekommt sieht's für dich ziemlich schlecht aus würde ich mal denken ... Schöne Grüße aus Bremen hartmut
* On Tue, 07 Jan 2003 at 19:00 +0100, Hartmut Meyer wrote:
Am Dienstag, 7. Januar 2003 14:49 schrieb Adalbert Michelic:
* On Tue, 07 Jan 2003 at 14:04 +0100, Antwerpen, Oliver wrote:
[...]
Wenn ich meinem Kunden etwas anbiete, dann möchte ich sicher sein, dass es funktioniert. Mein Kunde läßt sich das ja auch von mir bestätigen und ich wiederum lasse es mir von Compaq/SuSE/Oracle bestätigen. So bin ich auf einer sehr viel sichereren Seite als ohne Zertifikat auf zB Debian. Für alles andere setze ich Debian ein, aber im kritischen Business-Bereich? Da geht leider nur sehr, sehr wenig ohne Papier.
Bevor ich $BIGNUM EUR ausgebe, um ein Stück zertifizierte Software zu bekommen, schaue ich lieber, daß ich einen fähigen Programmierer und die Sourcen meiner Produkte zur Hand habe, dann kann ich wenigstens selbst eingreifen, wenns Fehler gibt.
Wenn ich mir ansehe, wie die Hersteller mit den 3 Buchstaben langen Namen reagieren, wenns hier wirklich mal kriselt - Danke, ich verzichte auf Zertifizierungen. Im Fall des Falles hat man auch nichts als Scherereien und 2 Hersteller, die sich gegenseitig die Schuld zuschieben.
Betrachte es mal umgekehrt:
Hersteler wie Oracle oder SAP wollen sich auch absichern (kann ich nachvollziehen). Die schreiben sich dann in Ihre Supportbedingungen rein: "nur mit zertifizierter Hard- und Software".
Und dann kommst du an mit einem Problem welches möglicherweise überhaupt rein gar nichts mit zertifizierter oder nicht-zertifizierter Umgebung zu tun hat sondern ganz simple ein Problem von SAP oder Oracle ist. Aber du kriegst keinen Support weil du dir zuvor deine "$BIGNUM EUR" für die zertifizierte Umgebung gespart hast.
Schade, oder (deinen tollen "fähigen Programmierer" kannst du dir in dem Moment natürlich auch in der Pfeife rauchen, denn der wird dir den Bug in SAP bzw. Oracle auch nicht fixen können - egal wieviel Source-Code ihm zur Verfügung steht)?
Und wenn du dann deinem Chef oder Auftraggeber gegenüber erklären musst, warum du (bzw. er) den Support von SAP bzw. Oracle nicht bekommt sieht's für dich ziemlich schlecht aus würde ich mal denken ...
Ach - nett, dass Du SAP erwähnst: Durfte mir da gerade mal (nachdem eine OSS-Meldung mit Priorität Hoch über 3 Wochen einfach nicht bearbeitet wurde, und wir uns über das etwas besorgt äusserten) anhören, daß für das Testen schon der Kunde zuständig ist; der Hersteller hat ja nicht die Resourcen um sein Produkt auf allen Plattformen zu testen. Und ja, das Zeug läuft auf einer "zertifizierten Plattform". Jetzt etwas verständlicher, daß ich diesen Zertifizierungskram etwas kritisch betrachte? -- Adalbert GPG welcome, request public key: mailto:adalbert+key@lopez.at
Hallo, Am Dienstag, 7. Januar 2003 19:39 schrieb Adalbert Michelic:
* On Tue, 07 Jan 2003 at 19:00 +0100, Hartmut Meyer wrote:
Betrachte es mal umgekehrt:
Hersteler wie Oracle oder SAP wollen sich auch absichern (kann ich nachvollziehen). Die schreiben sich dann in Ihre Supportbedingungen rein: "nur mit zertifizierter Hard- und Software".
Und dann kommst du an mit einem Problem welches möglicherweise überhaupt rein gar nichts mit zertifizierter oder nicht-zertifizierter Umgebung zu tun hat sondern ganz simple ein Problem von SAP oder Oracle ist. Aber du kriegst keinen Support weil du dir zuvor deine "$BIGNUM EUR" für die zertifizierte Umgebung gespart hast.
Schade, oder (deinen tollen "fähigen Programmierer" kannst du dir in dem Moment natürlich auch in der Pfeife rauchen, denn der wird dir den Bug in SAP bzw. Oracle auch nicht fixen können - egal wieviel Source-Code ihm zur Verfügung steht)?
Und wenn du dann deinem Chef oder Auftraggeber gegenüber erklären musst, warum du (bzw. er) den Support von SAP bzw. Oracle nicht bekommt sieht's für dich ziemlich schlecht aus würde ich mal denken ...
Ach - nett, dass Du SAP erwähnst: Durfte mir da gerade mal (nachdem eine OSS-Meldung mit Priorität Hoch über 3 Wochen einfach nicht bearbeitet wurde, und wir uns über das etwas besorgt äusserten) anhören, daß für das Testen schon der Kunde zuständig ist; der Hersteller hat ja nicht die Resourcen um sein Produkt auf allen Plattformen zu testen. Und ja, das Zeug läuft auf einer "zertifizierten Plattform".
Jetzt etwas verständlicher, daß ich diesen Zertifizierungskram etwas kritisch betrachte?
Genauso verständlich wie vorher. Der Punkt den du ansprichst hat rein gar nichts mit der Problematik zu tun, die ich dargestellt habe. Du sagst: auch mit zertifizierter Umgebung ist der Support durch den Hersteller nicht notwendigerweise toll. Ich sage: duwirst ein Problem haben wenn du deinem Chef bzw. Auftraggeber erklären musst, dass ihm deshalb jeglicher Hersteller-Support verwehrt wurde, weil du vorher die zertifizierte Umgebung eingespart hast. Stell dir beide Szenarien vor und überleg dir, wie unbeschadet _du_ aus der einen und aus der anderen Situation rauskommst. Das auch der Fall unschön ist, den du beschreibst ist völlig unbestritten. Er kostet dich aber nicht deinen Kopf. Schöne Grüße aus Bremen hartmut
participants (3)
-
Adalbert Michelic
-
Antwerpen, Oliver
-
Hartmut Meyer