Moin,
wir planen gerade unseren zentralen Firmenserver neu aufzusetzen und da gerade sarge draußen ist, würde ich auf dem Gerät gerne Debian sehen (momentan SuSE 8.0). Ich habe meinem Chef die administrativen Vorteile erklärt und natürlich auch den sattsam bekannten Nachteil. Er hat dann etwas geschluckt, da er z.B. ganz gerne ein aktuelles Samba auf der Kiste sähe. Ich habe ihm gesagt, daß es inoffizielle Backports gibt, aber das will ihm nicht so richtig schmecken (verständlich). Testing oder unstable kommt aus meiner und seiner Sicht für die Kiste nicht in Frage. Man kann bei neuen Samba Releases dann selber zurückportieren, aber IMHO ist unsere Zeit dafür zu schade. Frage an die Masse: Welche Möglichkeiten seht ihr noch, an aktuelle Software für Debian heranzukommen (also nicht nur jetzt sondern auch meinetwegen in einem Jahr)? Ja, debian volatile soll kommen, aber ich glaube nicht, daß die sowas wie Samba aufnehmen. An die Verkürzung der Relasezyklen bei Debian glaube ich erst, wenn ich sie sehe.
Greets, Hilmar
On Sunday 12 June 2005 23:04, Hilmar Preusse wrote:
Testing oder unstable kommt aus meiner und seiner Sicht für die Kiste nicht in Frage.
Testing ist vergleichbar mit dem, was bei SuSE released wird - ich setze es ziemlich problemlos auf meiner Workstation und auf meinem Root-Server ein.
Üblicherweise gehe ich so vor: 1) ein Stable installieren 2) ein paar wichtige Pakete aus Testing ziehen 3) bei Security-Updates kommen ab und zu auch mal unstable-Pakete drauf (wenn es nicht anders geht)
Konrad
On 13.06.05 Konrad Rosenbaum (konrad@silmor.de) wrote:
On Sunday 12 June 2005 23:04, Hilmar Preusse wrote:
Moin,
Testing oder unstable kommt aus meiner und seiner Sicht für die Kiste nicht in Frage.
Testing ist vergleichbar mit dem, was bei SuSE released wird - ich setze es ziemlich problemlos auf meiner Workstation und auf meinem Root-Server ein.
Das kann ich ihm sagen -- mal sehen, ob ihn das beruhigt.
Üblicherweise gehe ich so vor:
- ein Stable installieren
Dann kann ich mal den neuen Installer ausprobiern...
- ein paar wichtige Pakete aus Testing ziehen
Solange testing und stable nicht allzuweit divergiert sind ist es auch nicht weiter wild. Nehmen wir aber mal den worst case an und etch kommt 2008. Dann wird es schwer werden die Build-Depends in stable zu erfüllen, ohne das gesamte System hochzuziehen oder tagelange Compilerorgien zu durchleben.
- bei Security-Updates kommen ab und zu auch mal unstable-Pakete
drauf (wenn es nicht anders geht)
Kein Thema. Welche Listen muß ich lesen um Security Announcements für unstable zu kriegen? debian-bugs-rc? Was mache ich, wenn der Bug zwar beim Maintainer ist, er aber tagelang nicht reagiert und es auch keinen Patch gibt?
H.
On Saturday 18 June 2005 10:01, Hilmar Preusse wrote:
On 13.06.05 Konrad Rosenbaum (konrad@silmor.de) wrote:
On Sunday 12 June 2005 23:04, Hilmar Preusse wrote: 2) ein paar wichtige Pakete aus Testing ziehen
Solange testing und stable nicht allzuweit divergiert sind ist es auch nicht weiter wild. Nehmen wir aber mal den worst case an und etch kommt 2008. Dann wird es schwer werden die Build-Depends in stable zu erfüllen, ohne das gesamte System hochzuziehen oder tagelange Compilerorgien zu durchleben.
Ich ziehe dann normalerweise den Grossteil des Systems auf testing hoch.
- bei Security-Updates kommen ab und zu auch mal unstable-Pakete
drauf (wenn es nicht anders geht)
Kein Thema. Welche Listen muß ich lesen um Security Announcements für unstable zu kriegen? debian-bugs-rc?
debian-security-announce
Üblicherweise werden die Patches zuerst in unstable ausprobiert und dann in stable eingepflegt. Einige Maintainer pflegen es auch in testing ein (wenn es sich nicht zu sehr von unstable unterscheidet - ist z.B. bei PHP so).
Was mache ich, wenn der Bug zwar beim Maintainer ist, er aber tagelang nicht reagiert und es auch keinen Patch gibt?
Das selbe was Du auch bei SuSE machen würdest:
*wild fuchtelnd und schreiend durch die Gegend rennen (nicht empfohlen) *wütende Artikel auf Newsforge schreiben (möglich, aber beeinträchtigt das eigene Karma) *selbst kompilieren (stressig) *jemanden für's kompilieren bezahlen (teuer)
Konrad
On 18.06.05 Konrad Rosenbaum (konrad@silmor.de) wrote:
On Saturday 18 June 2005 10:01, Hilmar Preusse wrote:
Moin,
[ein paar wichtige src-Pakete aus Testing ziehen, insbesondere security]
Solange testing und stable nicht allzuweit divergiert sind ist es auch nicht weiter wild. Nehmen wir aber mal den worst case an und etch kommt 2008. Dann wird es schwer werden die Build-Depends in stable zu erfüllen, ohne das gesamte System hochzuziehen oder tagelange Compilerorgien zu durchleben.
Ich ziehe dann normalerweise den Grossteil des Systems auf testing hoch.
Gut, dann kann ich das auch von Anfang an machen. Dann brauche ich den Compiler gar nicht anzuwerfen.
Kein Thema. Welche Listen muß ich lesen um Security Announcements für unstable zu kriegen? debian-bugs-rc?
debian-security-announce
Dort habe ich noch nie Annoucements für unstable/testing gesehen. Wenn ich eines für stable sehe, kriege ich natürlich auch Infos inwiefern das äquivalente Paket in unstable betroffen ist aber umgekehrt nicht.
Üblicherweise werden die Patches zuerst in unstable ausprobiert und dann in stable eingepflegt. Einige Maintainer pflegen es auch in testing ein (wenn es sich nicht zu sehr von unstable unterscheidet
- ist z.B. bei PHP so).
Klingt gut, nützt mir aber nix.
Was mache ich, wenn der Bug zwar beim Maintainer ist, er aber tagelang nicht reagiert und es auch keinen Patch gibt?
Das selbe was Du auch bei SuSE machen würdest:
*selbst kompilieren (stressig)
Das ist der wahrscheinlichste Weg.
H.
On Sat, Jun 18, 2005 at 10:01:34AM +0200, Hilmar Preusse wrote:
Solange testing und stable nicht allzuweit divergiert sind ist es auch nicht weiter wild. Nehmen wir aber mal den worst case an und etch kommt 2008. Dann wird es schwer werden die Build-Depends in stable zu erfüllen, ohne das gesamte System hochzuziehen oder tagelange Compilerorgien zu durchleben.
Dank gcc-4.0 wird es mit den Binary-Depends sehr bald schwierig, im C++-Bereich möglicherweise auch mit Build-Depends. Natürlich kann man alle Pakete auch so anpassen, dass sie unter stable gebaut werden können. Nur machen muss das jemand.
Viele Grüße, Torsten
Hi!
Hilmar Preusse [2005-06-12 23:04 +0200]:
Frage an die Masse: Welche Möglichkeiten seht ihr noch, an aktuelle Software für Debian heranzukommen (also nicht nur jetzt sondern auch meinetwegen in einem Jahr)?
Ubuntu hat wegen seines 6-Monats-Releasezyklus immer recht aktuelle Software, und jede Release bekommt 18 Monate Support. Allerdings beschränkt sich der Support nur auf einen kleinen Teil der Software ("main"), die Debian unterstützt, der Rest lebt in einer Komponente "universe", die Security Updates nur sehr spät bekommt. Die üblichen Allerwelts-Serveranwendungen sind in Ubuntu main, wenn ihr nur die braucht, wäre das eine Alternative. Wenn Ihr etwas ausgefallenere Software braucht, die in Universe ist, und für die Ihr unbedingt Support braucht, würde ich allerdings eher davon abraten.
Martin
On 13.06.05 Martin Pitt (martin@piware.de) wrote:
Hilmar Preusse [2005-06-12 23:04 +0200]:
Moin,
Frage an die Masse: Welche Möglichkeiten seht ihr noch, an aktuelle Software für Debian heranzukommen (also nicht nur jetzt sondern auch meinetwegen in einem Jahr)?
Ubuntu
Das mußte ja kommen. Ich hab hier 3 CD's von einem alten Ubuntu (IIRC Nov 2004) rumzufliegen, hab aber noch keinen Rechner/keine Zeit zum Installieren gefunden.
hat wegen seines 6-Monats-Releasezyklus immer recht aktuelle Software, und jede Release bekommt 18 Monate Support. Allerdings beschränkt sich der Support nur auf einen kleinen Teil der Software ("main"), die Debian unterstützt, der Rest lebt in einer Komponente "universe", die Security Updates nur sehr spät bekommt.
Hört sich erstmal gut an. Wie Debianisch ist Ubuntu? Ich bevorzuge Debian, weil ich das kenne und wahrscheinlich werde ich die Kiste dann auch betreuen (müssen).
Die üblichen Allerwelts-Serveranwendungen sind in Ubuntu main, wenn ihr nur die braucht, wäre das eine Alternative.
Ich werde mal von ihm ein Pflichtenheft einfordern und dann werden wir ja sehn, was die Kiste braucht.
Thanks, Hilmar
On 18.06.05 Hilmar Preusse (hille42@web.de) wrote:
On 13.06.05 Martin Pitt (martin@piware.de) wrote:
Moin,
[Ubuntu statt Debian]
Die üblichen Allerwelts-Serveranwendungen sind in Ubuntu main, wenn ihr nur die braucht, wäre das eine Alternative.
Ich werde mal von ihm ein Pflichtenheft einfordern und dann werden wir ja sehn, was die Kiste braucht.
OK, Liste hab ich und teilweise ausgewertet. Die meisten Sachen sind tatsächlich in main drin. Offen sind noch:
- Support für RAID-Adapter, voraussichtlich HighPoint, inkl. Management (*)
(hängt dann vom Kernel ab und wie OS-spezifisch dieses Management-Modul ist).
- Support für Zinto-UPS (*)
(sind Binary Blobs, die ich ainfach mal installieren und ausprobieren muß).
- NFS-Server (kernel-Server ist in main, user-Server in universal). Ist der Kernel-Server brauchbar?
- Amanda (nur in Universe)
- System Edge (kommt von unserem Hersteller -> ausprobieren (geht)
- sendmüll (auch nur in universe, evntl. gegen pestfux austauschen) unkritisch, da das nicht der zentrale Mailserver ist.
- xdm (auch nur in universe). Was bedeutet das übrigends, daß xdm in universe ist, aber xlibs in main obwohl beide aus denselben Quellen gemacht werden? Heißt das bei Security Geschichten gibts zwar Updates fpr xlibs, aber für xdm nicht?
- mirror (auch nur in universe)
OK, ich beiß mich weiter durch. Die erste Installation hier scheint erstmal heavy broken zu sein, aber zu der war ich auch nicht sonderlich freundlich... Die nächste sicher, wenn die Hardware da ist.
Greets, H.
Hilmar Preusse schrieb:
Moin,
wir planen gerade unseren zentralen Firmenserver neu aufzusetzen und da gerade sarge draußen ist, würde ich auf dem Gerät gerne Debian sehen (momentan SuSE 8.0).
[...]
Frage an die Masse: Welche Möglichkeiten seht ihr noch, an aktuelle Software für Debian heranzukommen (also nicht nur jetzt sondern auch meinetwegen in einem Jahr)?
[...] Ich habe zzt. 10 Maschinen mit sarge, vorher woody. Ich bin da so vorgeganden, dass ich entweder source packages aus testing auf stable gebaut habe (ggfs mit kleinen Modifikationen) und dann diese aus eigenem Repository nativ installiert. Die andere Variante war selbst aus sourcen bauen. Es ist nicht wirklich viel aufwaendiger als man glaubt. Es gibt auch brauchbare tools um das leichter zu machen. Sonst ist backports.org an der Reihe. Die verwenden auch das was in testing/unstable als Sourcecode einfliesst und bauen das fuer das aktuelle stable release.
Was samba betrifft: zzt. ist dort die 3.0.14a drin. Ich glaube nicht dass sich die nexten 3er releases signifikant voneinander unterscheiden. Erst wenn samba4 draussen ist, wirds interessant. Das kann man dann aus testing zurueckportieren. Ich wuerde samba4 ab Release nicht gern auf einer Produktionsmachine sehen. Ich hatte schlechte Erfahrungen mit der neuesten (damals) 3er gemacht. Es bedarf viele Tests bevor es etwa die Qualitaet der aktuellen 3er erreicht. IMO ist es auf einem Server nicht wichtig jedes .x Release mitzunehmen, weshalb ich mir dort keine grossen Gedanken machen wuerde.
MfG -Dimitri
On 13.06.05 Dimitri Puzin (tristan-777@ddkom-online.de) wrote:
Hilmar Preusse schrieb:
Moin,
wir planen gerade unseren zentralen Firmenserver neu aufzusetzen und da gerade sarge draußen ist, würde ich auf dem Gerät gerne Debian sehen (momentan SuSE 8.0).
[...]
Frage an die Masse: Welche Möglichkeiten seht ihr noch, an aktuelle Software für Debian heranzukommen (also nicht nur jetzt sondern auch meinetwegen in einem Jahr)?
[...] Ich habe zzt. 10 Maschinen mit sarge, vorher woody. Ich bin da so vorgeganden, dass ich entweder source packages aus testing auf stable gebaut habe (ggfs mit kleinen Modifikationen) und dann diese aus eigenem Repository nativ installiert.
Klingt sinnvoll wenn man mehr als 1 Rechner hat. Da es nur einen Fileserver gibt (der Mailserver läuft auf FreeBSD -- Hallo Matthias!) ist das nicht sinnvoll. Was sind die erwähnten "kleinen Modifikationen"? In den letzten Tagen von potato waren das regelrechte Compiler-Orgien IIRC.
Die andere Variante war selbst aus sourcen bauen. Es ist nicht wirklich viel aufwaendiger als man glaubt.
Bei mir zu Hause (noch woody) gibts ein Unterverzeichnis /usr/local/src/debian/not-compiling. Kann sein, daß ich zu blöd dafür bin, aber letztendlich muß ich die Kiste administrieren und dann muß ich solche Cases behandeln können.
Es gibt auch brauchbare tools um das leichter zu machen.
-v, please
Sonst ist backports.org an der Reihe. Die verwenden auch das was in testing/unstable als Sourcecode einfliesst und bauen das fuer das aktuelle stable release.
Hab ich ihm gesagt. Wird das Zeug von den offiziellen Maintainern signiert, so daß man die Echtheit prüfen kann? Immerhin ist es der zentrale Fileserver unserer Firme, der einen ssh-Port zum Internet offen hat.
Was samba betrifft: zzt. ist dort die 3.0.14a drin. [Samba ist Bananen-Software: reift beim Kunden]
Wenn unsere Sales-!&%/(&$/%&)$/"&" gehört haben, was man mit W$-XP so alles Schönes anfangen kann und spitzkriegen, daß das letzte Samba-Release das auch können soll, dann bin ich Mode und muß genau das aufsetzen. Gut, Samba ist kein KDE, was kiloweise BD's einschleift. Trotzdem muß man sich erstmal hinsetzen und das Zeug backen und notfalls maintainen (i.e. Security, other grave bugs etc.). Das Argument da oben hilft mir insofern, als ich dadurch eine Ausrede kriege, nicht Bleeding Edge zu fahren.
H., hat zu Hause auch ein Repository
Hilmar Preusse schrieb:
On 13.06.05 Dimitri Puzin (tristan-777@ddkom-online.de) wrote:
Hilmar Preusse schrieb:
Moin,
wir planen gerade unseren zentralen Firmenserver neu aufzusetzen und da gerade sarge draußen ist, würde ich auf dem Gerät gerne Debian sehen (momentan SuSE 8.0).
[...]
Frage an die Masse: Welche Möglichkeiten seht ihr noch, an aktuelle Software für Debian heranzukommen (also nicht nur jetzt sondern auch meinetwegen in einem Jahr)?
[...] Ich habe zzt. 10 Maschinen mit sarge, vorher woody. Ich bin da so vorgeganden, dass ich entweder source packages aus testing auf stable gebaut habe (ggfs mit kleinen Modifikationen) und dann diese aus eigenem Repository nativ installiert.
Klingt sinnvoll wenn man mehr als 1 Rechner hat. Da es nur einen Fileserver gibt (der Mailserver läuft auf FreeBSD -- Hallo Matthias!) ist das nicht sinnvoll.
Wenn sich die source-backports problemlos kompilieren lassen, ist es recht wenig Aufwand, IMO. Natuerlich, skaliert diese Variante mit jeder Machine besser und besser :-)
Was sind die erwähnten "kleinen Modifikationen"? In den letzten Tagen von potato waren das regelrechte Compiler-Orgien IIRC.
Ich habe ca 25 Pakete incl. Abhaengigkeiten unterhalten. Teils aus den Backports, teils selbst eingerichtet. Es war nicht so schlimm, wie Du dir das vll. jetzt ausmalst.
Die andere Variante war selbst aus sourcen bauen. Es ist nicht wirklich viel aufwaendiger als man glaubt.
Bei mir zu Hause (noch woody) gibts ein Unterverzeichnis /usr/local/src/debian/not-compiling. Kann sein, daß ich zu blöd dafür bin, aber letztendlich muß ich die Kiste administrieren und dann muß ich solche Cases behandeln können.
Ich habe zumindest das, was ich haben wollte, so bauen koennen, wie ich es haben wollte. Es haengt natuerlich in erster Linie von den eigenen Kenntnissen und Fertigkeiten ab.
Es gibt auch brauchbare tools um das leichter zu machen.
-v, please
checkinstall, stow, dpkg-* ... um nur einige zu nennen :-)
Sonst ist backports.org an der Reihe. Die verwenden auch das was in testing/unstable als Sourcecode einfliesst und bauen das fuer das aktuelle stable release.
Hab ich ihm gesagt. Wird das Zeug von den offiziellen Maintainern signiert, so daß man die Echtheit prüfen kann? Immerhin ist es der zentrale Fileserver unserer Firme, der einen ssh-Port zum Internet offen hat.
Wenn du _so_ sicher gehen willst, musste eigentlich einen Review der Sourcen veranstalten, um sicher zu gehen.
Was samba betrifft: zzt. ist dort die 3.0.14a drin. [Samba ist Bananen-Software: reift beim Kunden]
Hm, bin ich nicht dieser Meinung.
Wenn unsere Sales-!&%/(&$/%&)$/"&" gehört haben, was man mit W$-XP so alles Schönes anfangen kann und spitzkriegen, daß das letzte Samba-Release das auch können soll, dann bin ich Mode und muß genau das aufsetzen.
Stell dir eine Experimentierbox hin, bau das dort, probier es aus etc... Bau dann nen Paeckchen und installier den auf dem Produktionsserver. So hab ich's gemacht :-)
Gut, Samba ist kein KDE, was kiloweise BD's einschleift. Trotzdem muß man sich erstmal hinsetzen und das Zeug backen und notfalls maintainen (i.e. Security, other grave bugs etc.).
Ja. Deswegen ist es rel. einfach zu maintainen, IMO.
Das Argument da oben hilft mir insofern, als ich dadurch eine Ausrede kriege, nicht Bleeding Edge zu fahren.
H., hat zu Hause auch ein Repository
Was Du am Ende Dir leisten kannst, hinzustellen, zu betreuen und wieviel Erfahrung Du damit hast, wieviel Zeit Du dafuer hast etc pp... fuer all diese Fragen wirst Du keine Antwort auf dieser Liste finden. Diese Entscheidung liegt allein bei Dir. Dass vieles geht, hast Du ja sicherlich an den zahlreichen Antworten auf Dein Posting gesehen. :-)
MfG -Dimitri
On Sun, Jun 12, 2005 at 11:04:56PM +0200, Hilmar Preusse wrote:
Ich habe ihm gesagt, daß es inoffizielle Backports gibt, aber das will ihm nicht so richtig schmecken (verständlich). Testing oder unstable kommt aus meiner und seiner Sicht für die Kiste nicht in Frage. Man kann bei neuen Samba Releases dann selber zurückportieren, aber IMHO ist unsere Zeit dafür zu schade.
Ich finde alle drei Varianten gangbar. Man kann natürlich auch jemanden bezahlen, der die Arbeit macht.
Passende Geschichte aus dem Bayrischen Rechnungshof: Suses Fileserver kackte dauernd ab und weder Suse noch IBM waren in der Lage, dass zu fixen trotz teurer Supportverträge. Motto: 'alle anderen Kunden haben kein solches Problem'. Erst als jemand ein funktionierendes Debian daneben stellte, haben sie heraus gefunden, dass ihr Kernel kaputt gepacht war.
Ich hätte mit Suse mehr Bauchschmerzen, aber das ist natürlich völlig subjektiv...
Viele Grüße, Torsten
On 13.06.05 Torsten Werner (email@twerner42.de) wrote:
On Sun, Jun 12, 2005 at 11:04:56PM +0200, Hilmar Preusse wrote:
Moin,
Ich habe ihm gesagt, daß es inoffizielle Backports gibt, aber das will ihm nicht so richtig schmecken (verständlich). Testing oder unstable kommt aus meiner und seiner Sicht für die Kiste nicht in Frage. Man kann bei neuen Samba Releases dann selber zurückportieren, aber IMHO ist unsere Zeit dafür zu schade.
Ich finde alle drei Varianten gangbar. Man kann natürlich auch jemanden bezahlen, der die Arbeit macht.
Erzähl das unserem Finanzminister.... Nein, das wäre dann mein Job. Und wenn ich Debian auf der Kiste will, dann muß ich auch dafür gerade stehen.
Passende Geschichte aus dem Bayrischen Rechnungshof: [SuSE patcht Kernels kaputt]
Altbekanntes Problem. Notfalls halt einen von kernel.org nehmen. Problematisch ist hier, daß ich die Release Policy von 2.6.x immer noch nicht verstanden hab..
Ich hätte mit Suse mehr Bauchschmerzen, aber das ist natürlich völlig subjektiv...
Solange der Kernel auf der speziellen Hardware tut, sehe ich kein Problem auch SuSE zu nehmen. Ich nehme an, die neue Kiste wird erstmal installiert, kriegt ihre Streßtests und läuft dann zunächst ein paar Wochen parallel zum alten Server, bevor der zum Secondary und dann abgeschaltet wird. Die HW^1, die dann den Job übernehmen soll, haben wir schon hier. Bei Interesse kann ich ja mal die Daten posten.
H., bevorzugt Debian, weil er es kennt.
^1 Achso, im Initialposting hörte es ich so an, als ob wir die Kiste neu aufsetzen. In Wirklichkeit haben wir neue HW, die jetzt Software drauf kriegen muß und dann ans Netz geht, ja auch ans Internet.
Am 18. Juni 2005 schrieb Hilmar Preusse:
On 13.06.05 Torsten Werner (email@twerner42.de) wrote:
Passende Geschichte aus dem Bayrischen Rechnungshof: [SuSE patcht Kernels kaputt]
Altbekanntes Problem. Notfalls halt einen von kernel.org nehmen.
Geht nicht, weil der teure Supportvertrag flöten geht. Ja, es ist bei suse/redhat fast wie bei Microsoft: man hat nur scheinbar open source, weil man die sourcen *nicht* ändern darf!
Viele Grüße, Torsten
On Sat, Jun 18, 2005 at 12:11:23PM +0200, Torsten Werner wrote:
Geht nicht, weil der teure Supportvertrag flöten geht. Ja, es ist bei suse/redhat fast wie bei Microsoft: man hat nur scheinbar open source, weil man die sourcen *nicht* ändern darf!
Die Quellen sind dabei, und wenn du keinen Wert darauf legst, daß sich innerhalb garantierter Reaktionszeiten mehrere dutzend Kernel- Experten um dein Problem kümmern, dann darfst du natürlich deinen Kernel selbst kompilieren. Allerdings wird es dann halt entsprechend schwerer dir zu helfen, was dann im Standard-Maintenance-Vertrag nicht mehr abgedeckt ist.
Du wirst kaum eine Firma finden, die dir solchen Support für deine selbstgebackenen Kernel anbietet und wenn, dann wirst du sie vermutlich früher oder später nicht mehr finden. Das rechnet sich nämlich schlicht und einfach nicht: der Aufwand ist einfach zu groß.
On Sat, Jun 18, 2005 at 03:12:27PM +0200, Stefan Seyfried wrote:
Die Quellen sind dabei, und wenn du keinen Wert darauf legst, daß sich innerhalb garantierter Reaktionszeiten mehrere dutzend Kernel- Experten um dein Problem kümmern, dann darfst du natürlich deinen Kernel selbst kompilieren.
Das Beispiel hatte ich genannt (Bayrischer Rechnungshof), wo sich im Ernstfall bei SuSE überhaupt niemand geregt hat. Gleiche Erfahrungen hatten wir in der Vergangenheit mit Redhat.
Allerdings wird es dann halt entsprechend schwerer dir zu helfen, was dann im Standard-Maintenance-Vertrag nicht mehr abgedeckt ist.
Das nächste Problem ist, dass der komplette Support flöten geht, nicht nur der Kernelsupport und das, weil ich am Kernel vielleicht eine Mini-Änderung gemacht habe. Das hat mit der Open-Source-Idee überhaupt nichts mehr zu tun.
Du wirst kaum eine Firma finden, die dir solchen Support für deine selbstgebackenen Kernel anbietet und wenn, dann wirst du sie vermutlich früher oder später nicht mehr finden. Das rechnet sich nämlich schlicht und einfach nicht: der Aufwand ist einfach zu groß.
Bisher haben wir alles selber lösen können - d.h. mit Hilfe von Mailing-Listen und mit Hilfe der Software-Autoren. Und kleine Firmen/Selbständige finde ich an jeder Ecke, die mir Support leisten können, zumindest dann, wenn man schon eine Weile die Community kennt.
Viele Grüße, Torsten
On Sun, Jun 19, 2005 at 12:40:09PM +0200, Torsten Werner wrote:
On Sat, Jun 18, 2005 at 03:12:27PM +0200, Stefan Seyfried wrote:
Die Quellen sind dabei, und wenn du keinen Wert darauf legst, daß sich innerhalb garantierter Reaktionszeiten mehrere dutzend Kernel- Experten um dein Problem kümmern, dann darfst du natürlich deinen Kernel selbst kompilieren.
Das Beispiel hatte ich genannt (Bayrischer Rechnungshof), wo sich im Ernstfall bei SuSE überhaupt niemand geregt hat. Gleiche Erfahrungen
Ja, ich kann es allerdings nicht so recht glauben, insbesondere habe ich von keinem L3-Call dazu gehört. Es ist natürlich möglich, daß der betreffende Supporter das versaubeutelt hat, aber im allgemeinen würde ich als Kunde dann auf den Buchstaben des Supportvertrags bestehen und das durcheskalieren.
hatten wir in der Vergangenheit mit Redhat.
Dazu kann ich nichts sagen.
Allerdings wird es dann halt entsprechend schwerer dir zu helfen, was dann im Standard-Maintenance-Vertrag nicht mehr abgedeckt ist.
Das nächste Problem ist, dass der komplette Support flöten geht, nicht nur der Kernelsupport und das, weil ich am Kernel vielleicht eine Mini-Änderung gemacht habe. Das hat mit der Open-Source-Idee überhaupt nichts mehr zu tun.
Naja: das Problem beim Kernel ist halt, daß du mit minimalen Änderungen beliebig viel kaputt machen kannst - auch im Userspace. Wenn du (beispiel) dir dein aktuelles postgresql kompilierst und installierst, so ist es recht unwahrscheinlich daß dadurch dein NFS-Server, samba oder named nicht mehr funktioniert. Wenn du aber z.B. den Kernel - ohne ihn sonst zu ändern - mit anderen Optionen konfigurierst, so kann das evtl. durchaus das Signalhandling oder deinen (vorher zertifizierten) Filesystemtreiber eines Drittanbieters durcheinander bringen.
Du wirst kaum eine Firma finden, die dir solchen Support für deine selbstgebackenen Kernel anbietet und wenn, dann wirst du sie vermutlich früher oder später nicht mehr finden. Das rechnet sich nämlich schlicht und einfach nicht: der Aufwand ist einfach zu groß.
Bisher haben wir alles selber lösen können - d.h. mit Hilfe von Mailing-Listen und mit Hilfe der Software-Autoren. Und kleine Firmen/Selbständige finde ich an jeder Ecke, die mir Support leisten können, zumindest dann, wenn man schon eine Weile die Community kennt.
Ja, ich weiß. Ich war lange genug Admin und Consultant und habe das auch so selbst verkauft. Das Problem ist immer: was kostet der Tag Ausfallzeit den Kunden (und mich als Vertragsstrafe).
BTW: IIRC kann man bei Novell jetzt auch Support für selbstgebaute Installationen kaufen, aber ich vermute es wird teurer sein. ;-)
On Sunday 19 June 2005 21:36, Stefan Seyfried wrote:
BTW: IIRC kann man bei Novell jetzt auch Support für selbstgebaute Installationen kaufen, aber ich vermute es wird teurer sein. ;-)
Das kann man bei allen großen Supportfirmen: HP, Novel, IBM, etc.pp. Die Preise sind meines Wissens aber so hoch, dass sich selbst sehr große Firmen überlegen, ob sie das wirklich wollen. Letztlich machen das nur Forschungsabteilungen, die hochoptimierte Spezialsoftware einsetzen.
Konrad
On 18.06.05 Torsten Werner (email@twerner42.de) wrote:
Am 18. Juni 2005 schrieb Hilmar Preusse:
On 13.06.05 Torsten Werner (email@twerner42.de) wrote:
Moin,
Passende Geschichte aus dem Bayrischen Rechnungshof: [SuSE patcht Kernels kaputt]
Altbekanntes Problem. Notfalls halt einen von kernel.org nehmen.
Geht nicht, weil der teure Supportvertrag flöten geht. Ja, es ist bei suse/redhat fast wie bei Microsoft: man hat nur scheinbar open source, weil man die sourcen *nicht* ändern darf!
Ich hab gerade mal den Kollegen gefragt. Den haben wir noch nie in Anspruch genommen. Gut, die Zeiten ändern sich.
H.
lug-dd@mailman.schlittermann.de
-
Dimitri Puzin -
Hilmar Preusse -
Konrad Rosenbaum -
Martin Pitt -
Stefan Seyfried -
Torsten Werner