Was sollen denn Unternehmen davon halten? Die aktuelle Linux version ist ein spielplatz fuer entwickler.... Sowas schreckt doch mehr ab als zu linux zu bewegen.
Leider wäre der 2.7 eine Entwicklerversion und dann erst recht ein "Spielplatz für Entwickler" Ich glaube nicht das dies Entscheider abschrickt, da sie solche Sachen i.a. gar nicht mitkriegen.
Selbst wenn: In Firmen wird nicht mal eben auf saemtlichen Systemen ein frischer Kernel installiert. In der Regel nimmt man dort wahrscheinlich sowieso den Distributionskernel und ansonsten wird erstmal auf einem Testsystem ausprobiert.
Ist ja klar. Linux fängt erst jetzt an richtig auf zublühen. Die Entwicklung ist ja nicht unmoderiert, die Chef-Entwickler schauen schon dass alles im Rahmen bleibt, aber nur so lässt sich schnell und einfach ein genialer Kernel entwickeln. Das kann kein anderes System bieten, auch in Sachen Bugfix...
das heißt Entscheidungsträger *narf* ansonsten stimm ich dir aber zu ;-) Wie war das? Kernel mit gerader Endung "sind" stabil? Hoffentlich wirds demnächst wieder so.
Ich weiß nicht, was daran abschreckend ist, daß ein Bug innerhalb von 5 Stunden gefixt wurde. Also ich wäre froh, wenn das bei mir in der Firma eingesetzte OS auch so schnell Bugfixes bereitstellen würde.
Bugs passieren leider immer wieder und für diesen NFS Bug mache ich nicht das neue Entwicklungsmodell verantwortlich. Nach dem alten Model währe jetzt ein Kernel 2.6.10 notwendig, mit dem neuen Modell gibt es eine schnell geänderte Version 2.6.8.1. Das neue Modell ist weniger star und erlaubt somit, einfachere Bugfixes.
Zudem ist die Aussage "Spielplatz für Entwickler" so nicht richtig, da ja nicht alle Entwickler schreibrechte an den Quellen haben und mit den Kernelquellen sicher nicht gespielt werden wird. Wie der 2.4er Kernel gezeigt hatte kamen auch neue Entwicklungen in stabile Kernel rein, was bei der raschen Entwicklungsgeschwindigkeit des Kernels und neu hinzugefügten Treibern auch notwendig war.
Ich denke das neue Modell ist etwas flexibeler und verringert denn Arbeitsaufwand da die Anzahl der notwendigen Rückportierungen geringer ist. Bei den Konfigurationsoptionen gibt es eine Option, unausgereifte/experimentelle Optionen auszublenden und wenn die Kernelentwickler diese Option sinnvoll verwenden, ändert sich durch das neue Modell für Kernelselberbauer nicht viel.
Die Linuxdistributoren haben an dem neuen Modell wenig auszusetzen, da Bugfixes jetzt schneller in den Kernel kommen. Zudem besteht die Hoffnung, das die Anzahl der Distributionsspezifischen Patches verringert werden kann, da viele dieser Patches Rückportierungen von Treibern waren.
Gibt es so etwas wie einen Testprozess, ich meine Regressionstests für alle Sachen? Oder ein Rechenzentrum, auf dem die Kernel auf Referenzarchitekturen geteste werden? Gibt es formelle Security-audits? Sind Code-reviews nachvollziehbar protokolliert?
Von Meister Petz am So, 15. August 2004 um 15:19 #
"Dieses Vorgehen, nach dem Kernel 2.6.8 für nur 5 Stunden aktuell war, passt zu dem letztlich geänderten Entwicklungsmodell."
Und diese Formulierung, kann die Peinlichkeit des ganzen Vorganges auch nicht verschleiern, möchte ich mal hinzufügen.
Leute, wisst ihr was? - Am besten ihr macht die ganze Bude dicht!
Welche (vielleicht sogar noch große) Firma, soll denn angesichts solcher Hiobsbotschaften, auch nur einen ernsthaften Gedanken an Linux als Alternative verschwenden?
>Welche (vielleicht sogar noch große) Firma, soll denn angesichts >solcher Hiobsbotschaften, auch nur einen ernsthaften Gedanken an >Linux als Alternative verschwenden?
Tschuldigung, aber wo ist genau Dein Problem? Ich meine, wer Linux in kritischen Bereichen einsetzt, wird kernel-updates mit Sicherheit nicht in den ersten 5 Stunden einspielen. Es ist ein Fehler beim Release passiert, der Fehler wurde innerhalb kurzer Zeit behoben. Ich seh da keine Schwierigkeiten.
Von Kai F. Lahmann am So, 15. August 2004 um 16:25 #
im Grunde ist es zum heulen - nur: die Alternativen sind noch VIEL schlimmer!
Da wäre Microsoft, die mit allen Mitteln dafür sorgen wollen, dass es mehrere Jahre dauern kann, bis man an ein lebensnotwendiges Update kommt, welches bis man es endlich hat auch wieder veraltet ist. Außerdem ein System, wo ständig irgendwas auf irgendwas ganz anderes Auswirkungen hat.
Da wäre MacOS, wo man vor ein paar Jahren einfach das System 100%ig inkompatibel umgestellt hat, die alte Version kann man nur noch wegwerfen, weil es dafür NICHTS mehr gibt, die neue braucht aber viel schnellere - und damit viel teurere - Hardware.
Da wären die BSDs, die samt und sonders eine Installationsroutine haben, die von (da sie es selbst benutzen) Masochisten geschrieben sein muss.
Und da wären noch ein paar andere Systeme, die eigentlich schon lange tot sind und mit mahezu jeder Hardware Probleme haben.
Kurzum: eigentlich ist die IT-Welt eh noch nicht aus dem Kleinkindalter erwachsen, denn niemand bietet ein System, dass die allererste Regel erfüllt, die man braucht: es funktioniert ohne wenn und aber...
> Da wären die BSDs, die samt und sonders eine Installationsroutine haben, die von (da sie es selbst benutzen) Masochisten geschrieben sein muss.
Hä? Ok, ncurses-based, ein paar Ecken und Kanten, aber sonst... Ich nutze FreeBSD auf meinem Server wie auch früher bis zur 4.9 auf der Workstation. Und wenn BSD im USB-Bereich nicht so seine Lücken hätte, würde ich es auch sofort wieder auf der Workstation installieren.
Eines steht fest: An die Front, will sagen, auf meinem Router bleibt ein BSD. Andere Überlegungen wurden schnell verworfen. Die Sicherheitslücken im Kernel erscheinen mir doch in letzter Zeit einfach zu häufig...
Und installiert habe ich meine BSD's jeweils nur 1x, danach nur upgedatet, Stichwort "make world" sowie "ports". Ich kann mich kaum noch an die Installationsroutine erinnern...
Und nein, komme jetzt nicht mit 5.x, das ich _noch_ nicht der STABLE-Zweig!
Also ich weiss nicht, wenn ich die komische FreeBSD-CD einlege, dann beendet sich das Teil mit einem Kernelerror und bootet wieder neu, nur damit er mir dann erneut einen Kernelerror Präsentiert. Sowohl auf meinem Server als auch auf meinem Notebook. NetBSD scheint sich zwar zu installieren, aber beim Neuboot meldet mir das Bios, dass die Partitionstabelle nicht stimmt. Also bei mit geht es eben mit besten willen nicht.
Vergleiche doch mal die MD5 Summme deiner FreeBSD-CD mit der des FreeBSD-Iso-Image, wenn die nicht übereinstimmen kann es das schon gewesen sein... Schlechter Rohling / Zu schnell gebrannt / CD Zerkratzt / Brenner taugt nix usw... gruß...
Da wäre MacOS, wo man vor ein paar Jahren einfach das System 100%ig inkompatibel umgestellt hat, die alte Version kann man nur noch wegwerfen, weil es dafür NICHTS mehr gibt, die neue braucht aber viel schnellere - und damit viel teurere - Hardware.
Ach ja... da hat mal wieder jemand keine Ahnung... Klar, MacOS X kann man nicht auf jedem Mac installieren, aber auf vielen, und die Entscheidung, eine komplette Umstellung zu machen wurde dadurch vereinfacht, dass es eine MacOS 9 Emulation enthaelt. Dadurch kann man die alten Programme immer noch benutzen, wenn man denn muss, schleppt aber nicht die Last der Kompatibilitaet, unter der die PC-Architektur und Windows so leiden, mit.
Vielleicht solltest du es einfach mal ausprobieren anstatt es, ohne dich damit beschaeftigt zu haben, einfach schlechtzureden.
Kauf Dir mal ne AS400, echt erstaunlich, wie stabil die läuft. Naja, ist nichts für Privat, aber IMHO die billigste Alternative zum PC (so mit TOC kalkuliert), wenn man geschäftlich auf das System angewiesen ist.
MS kennt ähnliche Probleme mit Patches die "durchdrehen", warum betrifft es kaum grossen/mittleren Firmen ?
Diese zumeist eine Abteilung haben die sich mit der IT-Sicherheit auseinandersetzt, d.h. nicht nur die Sicherheit vor Einbrüchen, sondern auch die Betriebssicherheit, z.B. von neuen OS Versionen Programmversionen.
Grosse/mittlere Firmen benutzen auch nicht den Vanillakernel, sondern einen von den Distributoren, für den diese Support anbieten, der richtig intensiv getestet wurde,
und im Prinzip ist der Fehler auch für kleinere Firmen mit einem engagierten Linux/*BSD Admin kein Problem,
entweder
a.) nachdem man den Kernel gebaut hat, lässt man den Vorgängerkernel zur Sicherheit bestehen, so das man immer noch ein Fallback hat, für den Fall, dass die neue Lösung nicht gut funktioniert.
oder
b.) benutzt einen Testrechner, und testet die Stabilität, Datensicherheit und Funktionalität, bevor man Einsatzsysteme umrüstet
oder
c.) man hält eine 5 Tage Periode ein, d.h. Update erst nach 5 Tagen, in der Zeit werden die meisten schwerwiegenden Fehler gefunden.
Wie jeder weiß, gehört es zum 1mal eines jeden Sysadmins besonders in großen Firmen und auf lebenswichtiger Infrastruktur sofort nach erscheinen eines neuen Kernels diesen auch zu installieren.
Da können solche Fehler, deren Behebung sage und schreibe 5 Stunden dauerte, natürlich schnell mal zum Zusammenbruch ganzer Industriezweige, was rede ich, ganzer Volkswirtschaften führen.
Und natürlich hast du recht, angesichts solch schwerwiegender Konsequenzen, und ich möchte hinzufügen, dass meine hier vorgestellten Schadensszenarien, wie es meine Art ist, noch eher konservativ sind, kann von einer Alternative zu den bewährten Produkten des Marktführers natürlich keine Rede sein. Aber das ist natürlich für uns Profis nun alles andere als überraschend.
Aber zum 1x1 gehört auch Never-Change-A-Running-System und eben auch wenn etwas installiert werden soll es erstmal in einem Sandkasten zu testen. Dazu werden nur die Patches aufgespielt die zu der jeweiligen Distri gehören also von SuSE bei SuSE Distri, RH bei RH Distri, Mandrake .... einfach weil man nie wirklich weiss, was der Distributor selbst ver(schlimm)bessert hat und wie tief es in das System reicht.
Hehe, ist schon lustig, wie so manch ein Kommentar einen zum Lachen bringen kann!!!!
Was sollte Eurer Meinung passieren??? Fünf Wochen stillschweigen und dann erst nen Patch releasen??? Oder gleich wie Microsoft ein halbes Jahr warten und sowas wie ServicePacks anbieten!!! Vielleicht habt ihr noch nie etwas für eure Box runtergeladen und benutzt nur eure DistriCD's, vielleicht seit ihr auch zu **** mit 'patch' umzugehen, sollte es jedoch anders sein, muss ich mich echt fragen wie man sowas nur schreiben kann...
Wenn ein BUG gefunden wird, dann wird sofort ein Patch herausgegeben. Ob es dannach 2.4.8 oder 2.4.8.1 heisst ist doch jeder LinuxBOX scheiss egal und vor allem ist es nicht peinlich, gegenüber irgendeinem Unternehmen ein Patch herauszubringen (auch wenns 100 an einem Tag sind), im Gegenteil beweisst das nur KOMPETENZ UND SICHERHEIT, von welcher sich manch ein anderes OS eine grosse Scheibe abschneiden sollte...
Hast vollkommen recht. Hat wohl von denen (die hier nörgeln) nie einer was mit Softwareentwicklung zu tun gehabt, sonst wüssten sie, wie gerade der Entwickler selber den Bug übersieht, da er nicht alle Möglichkeiten der Software (des Kernels) durchspielen kann.
Sowas ist vollkommen normal und menschlich.
Was ich unmöglich finde sind solche Mega-Patches in Form von Service-Packs, die von bezahlten Programmieren in monatelanger Arbeit entstehen und noch so voller Bugs stecken, daß u.U. nachher kritischere Bugs hervorgebracht werden, oder manch alte bekannte Sicherheitslücke weiterhin besteht.
Sorry für die sehr langen Sätze - keine Ahnung, was heute mit mir los ist ...
Jeder Betriebsystemkern hat Fehler. Das ist schon mathematisch gesehen normal. Aber: die einen werden nie gefunden, die anderen spielen nie oder sehr, sehr selten eine Rolle und andere werden gefunden, aber dann kommt es auf den Hersteller an was dann passiert. Bei Linux schauen hunderte von Entwickler auf den Code - und finden Sie einen Fehler, so wird er idR gefixt. Die Frage ist hier nun, wie schwer dieser Fehler war und ob er jede Installation betrifft. Es ist eine Demonstration der Leistungsfähigkeit des Entwicklersystems, wenn bereits 5 Stunden nach dem Kernelrelease der Fehler gefixt ist. Bei MS kann das schon eine längere Zeitspanne dauern - mittlerweile ja jeden 2.Mittwoch im Monat (wenn ich mich recht erinnere). Gibt es eigentlich schon eine Vorschau auf 2.7 und der dortigen, neuen Features?
Von Jörg W Mittag am So, 15. August 2004 um 16:50 #
> Die Frage ist hier nun, wie schwer dieser Fehler war und ob er jede Installation betrifft.
Da, wie du selber schriebst, der Fehler bereits wenige Minuten nach der Veröffentlichung von Linux 2.6.8 entdeckt wurde, wenige Minuten darauf behoben wurde und eine neue Version nur Stunden später veröffentlicht wurde, ist offensichtlich, dass der Fehler wohl nicht jede Installation betrifft. Er betrifft ausschließlich Systeme, die innerhalb weniger Minuten nach Erscheinen von Linux 2.6.8 aktualisiert wurden *und* die als NFS-Clients eingesetzt werden *und* bei denen der Administrator beim Testen des Kernels geschlampt hat.
> Gibt es eigentlich schon eine Vorschau auf 2.7 und der dortigen, neuen Features?
Nein, gibt es nicht. Da es nach derzeitigem Kenntnisstand keinen 2.7er Zweig geben wird, wäre das auch etwas schwierig.
Von Jörg W Mittag am So, 15. August 2004 um 16:54 #
Ich vergaß den wesentlichen Punkt:
> Er betrifft ausschließlich Systeme, die innerhalb weniger Minuten nach Erscheinen von Linux 2.6.8 aktualisiert wurden *und* die als NFS-Clients eingesetzt werden *und* bei denen der Administrator beim Testen des Kernels geschlampt hat.
Dazu kommt natürlich noch, dass Vanilla-Kernel von kernel.org nach Aussage der Entwickler niemals auf Produktivsystemen oder von Endnutzern eingesetzt werden sollen, sondern dass für diesen Zweck die Kernel der Distributionen gedacht sind. Wenn also tatsächlich jemand Linux 2.6.8 von kernel.org eingesetzt hat, dann tat er dies gegen den ausdrücklichen Rat der Entwickler und ist mithin also selbst schuld.
wofür sind dann bitte die vanilla kernel gedacht? damit die distributoren sie an die eigenen distributionen anpassen? ich finde wenigstens der kernel sollte einheitlich sein oder nicht?!
Von Jörg W Mittag am So, 15. August 2004 um 19:05 #
> wofür sind dann bitte die vanilla kernel gedacht? damit die distributoren sie an die eigenen distributionen anpassen?
Zum Beispiel. Das ist schon seit Jahren so und hat bisher IMHO ziemlich gut funktioniert, warum also etwas verändern?
> ich finde wenigstens der kernel sollte einheitlich sein oder nicht?!
Ich finde, dass "One Size fits all" kein gutes Motto ist. Die Anforderungen in den verschiedenen Einsatzszenarien sind einfach viel zu unterschiedlich, als dass man sie mit einer Standardlösung erschlagen könnte. Es ist nun einmal so, dass es nicht ein Linux gibt sondern viele Linuxe für viele verschiedene Einsatzzwecke. Es gibt ein Linux von Linux Torvalds, das als eine Art gemeinsamer Basis dient, eines von Andrew Morton, das als Testumgebung für die Alltagstauglichkeit neuer Entwicklungen dient, eines von Andrea Arcangeli, das eine Testumgebung für die Speicherverwaltung auf großen Servern darstellt und außerdem die Basis für die SuSE-Kernel ist, eines von Matt Mackall, speziell für Geräte mit starken Speicher-Einschränkungen, eines von Nick Piggin und eines von Con Kolivas, beide mit Fokus auf Interaktivität bei Desktop-Anwendungen, eines von Marc-Christian Petersen mit dem Versuch, möglichst viele Features zu integrieren, eines von SuSE, eines von RedHat, eines von Fedora, eines von Mandrake, eines von Debian u.s.w..
Damit hat eben jeder die Wahl, welches Linux er für welchen Einsatzzweck auswählt.
> Ich finde, dass "One Size fits all" kein gutes Motto ist.
Sehe ich genauso, daher ist bei mir seit Linux 2.4.0 die erste Amtshandlung auf einem frisch installierten Linux, erstmal den Standardkernel der Distribution runterzuschmeissen und meinen eigenen, schlanken und (neuerdings auch) statischen Kernel zu backen.
Die Distributionskernel weil damit das Einspielen von Patches die gegen Vanilla erstellt wurden besonders viel Spass macht? Schon mal versucht einen Patch auf einen SuSE-Kernel anzuwenden?
Ich benutze nur Kernel.org-Kernel. Allerdings warte ich jeweils - wenn ich nicht gerade dringend ein Feature benötige - ein bisschen. Der Grund: Kernel 2.4.11 - dessen Bug war nicht ein Detail wie hier.
> Ah, endlich mal eine technisch fundierte und tiefgründig analysierte Aussage. So etwas > findet man in Webforen leider sehr selten.
Ein Punkt für den Kandidaten. Etwa genau so fundiert wie die Aussage der Kernelentwickler... Oder wollen die sich etwa ums Bugfixen drücken - Fehler in Distrokerneln meldet man wohl nicht bei Kernel.org...
> Nein, ich wüsste nicht, wozu ich das tun sollte.
Stimmt, den verwendet man gar nicht erst.
> Das bleibt dir unbenommen. Du musst dir halt nur der Tatsache bewusst sein, dass du > damit gegen die erklärte Empfehlung der Entwickler verstößt.
Schon so. Aber so ganz ernst meinen die das wohl nicht. Das heisst es ja auch bei Mozilla, oder? Und bei Debian Testing/Sid ist davon auch immer die Rede. Endanwender die nicht entwickeln sollen stable nutzen. Oder auch "wer das fragt will Woody".
Was ich noch vergessen hatte: Mit der Stabilität hatte ich keine Probleme mit Vanilla bisher. Bin äusserst zufrieden damit - kein Grund was anderes zu nehmen.
Dass Kernel von x dann besser laufen würde glaube ich nicht denn die sind: - manchmal zugepatcht (SuSE) - manchmal auch nicht (Debian) - aber sicher weniger gut getestet bzw. es hat weniger Leute die die testen
>Dazu kommt natürlich noch, dass Vanilla-Kernel von kernel.org nach Aussage der Entwickler niemals auf Produktivsystemen oder von Endnutzern eingesetzt werden sollen
Das ist das erste mal, dass ich von sowas höre. Quelle?
Von Jörg W Mittag am Mo, 16. August 2004 um 17:17 #
> Das ist das erste mal, dass ich von sowas höre. Quelle?
Alan Cox. Sorry, ich weiß nicht jeden Link zu jeder Aussage, die er jemals gemacht hat auswendig.
Es ging jedefalls um den ptrace()-Bug. Marcelo Tosatto wurde von Endanwendern stark kritisiert, weil er kein schnelles Bugfix-Release veröffentlicht hatte. Alan Cox meinte dazu, das sei unnötig, weil das die Distributoren bereits getan hätten und die Anwender ohnehin einen Distributionskernel einsetzen sollten.
Es gab noch einige andere Gelegenheiten, bei denen verschiedene Kernel-Hacker die Nutzung der Distributionskernel empfohlen haben. Dazu kommt natürlich speziell auf den 2.6er Kernel bezogen noch das neue Entwicklungsmodell, ohne einen dedizierten Entwicklungszweig.
2.6.8 hat den neuen code fuer aes verschlüsselung , dieser soll deutlich schneller auf der x86 architektur arbeiten. Ich freue mich schon(vpn + crypto fs)
Von Meineristlängeralsdeiner am So, 15. August 2004 um 22:53 #
Wirklich lächerlich wei sich einige hier wieder aufführen, als gäbe es eine Firma, die noch keine solchen Probleme hatte, gerade MS ist das beste Beispiel, wie oft da schon die Meldung kam, dass mit einem Patch der Vorgängerpatch gefixt wurde. Teilweise 3 Patches für ein Problem. Schreit ihr Deppen da auch, MS mach deinen Laden zu???? Außerdem ist das ja wohl kein so gravierendes Problem, eher ein Problemchen, das halt sofort gefixt wurde, bis ich von dem neuen Kernel erfuhr, war der .1 schon da mit nem Fix, wenn das andere Firmen auch so hinkriegen dann ein großes Lob an die.
Deswegen haltet einfach eure dämliche Schnauze, eure kindliches Gehabe ist einfach nur blöd.
Wer einen "stabilen" Kernel benutzt, für den noch keine nachfolgende Entwicklerversion existiert, wie es noch bei 2.6 der Fall ist, sollte sich nicht wundern. Sämtliche Patches fließen dann noch in diesen ein und das sind nicht nur Bugfixes. Es kann zu grundlegenden Schnittstellenänderungen kommen, was den Namen "stable" nun wirklich nicht verdient hat.
Mit diesem Wissen ist allerdings jedem selbst überlassen, ob er sich das antut, oder doch lieber auf den "richtigen" stable Kernel wartet (2.6.?), sobald die erste 2.7er-Version rausgebracht wird.
Das Problem ist, daß von denen, die die Fehler in "stable" entdecken, niemand die Entwicklerversionen getestet hat. Da liegt doch das Problem. Wer sich die Arbeit spart, den Kernel zu testen und hofft, andere würden das _gratis_ für ihn tun, der hat das Open Source Entwicklungsmodell nicht verstanden. Der Preis für freie Software ist, daß man den Test selber durchführen muß.
Der Vorteil liegt nicht in fehlerfreier Software, sondern in schneller Behebung der gefundenen Bugs.
Sorry, das mag der Entwicklungsgeschwindigkeit sicher zuträglich sein, aber auf Produktivsystemen halte ich das nicht für verantwortbar. Es ist ohnehin illusorisch einen Kernel alle paar Tage zu aktualisieren zu wollen (wohlgemerkt auf Servern, bei denen es auf die Verfürgbarkeit ankommt). Auf meinem Arbeitsplatz läuft derzeit ein Fedora Core 2 mit 2.6er Kernel - mit duraus einigen Macken und Problemen, aber das ist ok und aktzeptabel. Wenn meine Workstation abraucht hab ich maximal 30 Minuten zu tun und kann weiter machen, ohne das es jemanden stört. Wenn ein Server abraucht, hab ich meinen Chef im Nacken und der Support übt mit Mistgabeln vor meinem Büro den Aufstand. ;) Ich hoffe sehr, dass bald der 2.7er geforkt wird, damit ich mit der Evaluierung des 2.6er für die Server beginnen kann, da einige sehr interessante Änderungen und Verbesserungen enthalten sind. Im Moment ist das für mich noch reine Zeitverschwendung da ich den 2.6er Kernel als Entwicklerversion betrachte und ich ihn noch nicht als einsatzfähig betrachte.
Salve, diese Frage basiert auf die Nutzung von Routern mit ARM CPUs. Man läuft Gefahr, das man sich den Router zerflasht..... Kann man einmal einen Kernel mit USB-Unterstützung flashen, der dann den Kernel vom USBstick bootet (gegebenfalls USB to Ramdisk, booten des Kernel B von Ramdisk) und zwar auch, wenn die Versionen der Kernel unterschiedlich ist? Mann könnte so recht entspannt auf einem USBstick neue Kernels ausprobieren ;)
Im Archiv der Linuxbios mailingliste haben ich einen Hinweis gefunden, das dies scheinbar geht: "I'm fighting from another angle. I have a kernel booting another kernel working for an SMP kernel. Now if I just need to get it to work for a SMP kernel when more than 1 cpu is in the box and I'll be in good shape " http://www.linuxbios.org/faq/archive/0632.html
Sowas schreckt doch mehr ab als zu linux zu bewegen.
Ich glaube nicht das dies Entscheider abschrickt, da sie solche Sachen i.a. gar nicht mitkriegen.
ansonsten stimm ich dir aber zu ;-)
Wie war das? Kernel mit gerader Endung "sind" stabil? Hoffentlich wirds demnächst wieder so.
Zudem ist die Aussage "Spielplatz für Entwickler" so nicht richtig, da ja nicht alle Entwickler schreibrechte an den Quellen haben und mit den Kernelquellen sicher nicht gespielt werden wird. Wie der 2.4er Kernel gezeigt hatte kamen auch neue Entwicklungen in stabile Kernel rein, was bei der raschen Entwicklungsgeschwindigkeit des Kernels und neu hinzugefügten Treibern auch notwendig war.
Ich denke das neue Modell ist etwas flexibeler und verringert denn Arbeitsaufwand da die Anzahl der notwendigen Rückportierungen geringer ist. Bei den Konfigurationsoptionen gibt es eine Option, unausgereifte/experimentelle Optionen auszublenden und wenn die Kernelentwickler diese Option sinnvoll verwenden, ändert sich durch das neue Modell für Kernelselberbauer nicht viel.
Die Linuxdistributoren haben an dem neuen Modell wenig auszusetzen, da Bugfixes jetzt schneller in den Kernel kommen. Zudem besteht die Hoffnung, das die Anzahl der Distributionsspezifischen Patches verringert werden kann, da viele dieser Patches Rückportierungen von Treibern waren.
Ja, alle neuen Sachen kommen erst einmal in die mm Kernel-Serie.
> Oder ein Rechenzentrum, auf dem die Kernel auf Referenzarchitekturen geteste werden?
Ja gibt es auch, beim OSDL http://osdlab.org/ oder auch bei den Distributionen.
passt zu dem letztlich geänderten Entwicklungsmodell."
Und diese Formulierung, kann die Peinlichkeit des ganzen Vorganges
auch nicht verschleiern, möchte ich mal hinzufügen.
Leute, wisst ihr was? - Am besten ihr macht die ganze Bude dicht!
Welche (vielleicht sogar noch große) Firma, soll denn angesichts
solcher Hiobsbotschaften, auch nur einen ernsthaften Gedanken an
Linux als Alternative verschwenden?
>solcher Hiobsbotschaften, auch nur einen ernsthaften Gedanken an
>Linux als Alternative verschwenden?
Tschuldigung, aber wo ist genau Dein Problem? Ich meine, wer Linux in kritischen Bereichen einsetzt, wird kernel-updates mit Sicherheit nicht in den ersten 5 Stunden einspielen.
Es ist ein Fehler beim Release passiert, der Fehler wurde innerhalb kurzer Zeit behoben. Ich seh da keine Schwierigkeiten.
Da wäre Microsoft, die mit allen Mitteln dafür sorgen wollen, dass es mehrere Jahre dauern kann, bis man an ein lebensnotwendiges Update kommt, welches bis man es endlich hat auch wieder veraltet ist. Außerdem ein System, wo ständig irgendwas auf irgendwas ganz anderes Auswirkungen hat.
Da wäre MacOS, wo man vor ein paar Jahren einfach das System 100%ig inkompatibel umgestellt hat, die alte Version kann man nur noch wegwerfen, weil es dafür NICHTS mehr gibt, die neue braucht aber viel schnellere - und damit viel teurere - Hardware.
Da wären die BSDs, die samt und sonders eine Installationsroutine haben, die von (da sie es selbst benutzen) Masochisten geschrieben sein muss.
Und da wären noch ein paar andere Systeme, die eigentlich schon lange tot sind und mit mahezu jeder Hardware Probleme haben.
Kurzum: eigentlich ist die IT-Welt eh noch nicht aus dem Kleinkindalter erwachsen, denn niemand bietet ein System, dass die allererste Regel erfüllt, die man braucht: es funktioniert ohne wenn und aber...
Hä? Ok, ncurses-based, ein paar Ecken und Kanten, aber sonst... Ich nutze FreeBSD auf meinem Server wie auch früher bis zur 4.9 auf der Workstation. Und wenn BSD im USB-Bereich nicht so seine Lücken hätte, würde ich es auch sofort wieder auf der Workstation installieren.
Eines steht fest: An die Front, will sagen, auf meinem Router bleibt ein BSD. Andere Überlegungen wurden schnell verworfen. Die Sicherheitslücken im Kernel erscheinen mir doch in letzter Zeit einfach zu häufig...
Und installiert habe ich meine BSD's jeweils nur 1x, danach nur upgedatet, Stichwort "make world" sowie "ports". Ich kann mich kaum noch an die Installationsroutine erinnern...
Und nein, komme jetzt nicht mit 5.x, das ich _noch_ nicht der STABLE-Zweig!
es das schon gewesen sein... Schlechter Rohling / Zu schnell gebrannt / CD Zerkratzt / Brenner taugt nix usw...
gruß...
Ach ja... da hat mal wieder jemand keine Ahnung... Klar, MacOS X kann man nicht auf jedem Mac installieren, aber auf vielen, und die Entscheidung, eine komplette Umstellung zu machen wurde dadurch vereinfacht, dass es eine MacOS 9 Emulation enthaelt. Dadurch kann man die alten Programme immer noch benutzen, wenn man denn muss, schleppt aber nicht die Last der Kompatibilitaet, unter der die PC-Architektur und Windows so leiden, mit.
Vielleicht solltest du es einfach mal ausprobieren anstatt es, ohne dich damit beschaeftigt zu haben, einfach schlechtzureden.
MS kennt ähnliche Probleme mit Patches die "durchdrehen", warum betrifft es kaum grossen/mittleren Firmen ?
Diese zumeist eine Abteilung haben die sich mit der IT-Sicherheit auseinandersetzt,
d.h. nicht nur die Sicherheit vor Einbrüchen, sondern auch die Betriebssicherheit,
z.B. von neuen OS Versionen Programmversionen.
Grosse/mittlere Firmen benutzen auch nicht den Vanillakernel, sondern einen von den Distributoren,
für den diese Support anbieten, der richtig intensiv getestet wurde,
und im Prinzip ist der Fehler auch für kleinere Firmen mit einem engagierten Linux/*BSD Admin kein Problem,
entweder
a.) nachdem man den Kernel gebaut hat, lässt man den Vorgängerkernel zur Sicherheit bestehen, so das man
immer noch ein Fallback hat, für den Fall, dass die neue Lösung nicht gut funktioniert.
oder
b.) benutzt einen Testrechner, und testet die Stabilität, Datensicherheit und Funktionalität,
bevor man Einsatzsysteme umrüstet
oder
c.) man hält eine 5 Tage Periode ein, d.h. Update erst nach 5 Tagen, in der Zeit werden die meisten
schwerwiegenden Fehler gefunden.
Da können solche Fehler, deren Behebung sage und schreibe 5 Stunden dauerte, natürlich schnell mal zum Zusammenbruch ganzer Industriezweige, was rede ich, ganzer Volkswirtschaften führen.
Und natürlich hast du recht, angesichts solch schwerwiegender Konsequenzen, und ich möchte hinzufügen, dass meine hier vorgestellten Schadensszenarien, wie es meine Art ist, noch eher konservativ sind, kann von einer Alternative zu den bewährten Produkten des Marktführers natürlich keine Rede sein. Aber das ist natürlich für uns Profis nun alles andere als überraschend.
Gruß an Alle
Was sollte Eurer Meinung passieren??? Fünf Wochen stillschweigen und dann erst nen Patch releasen??? Oder gleich wie Microsoft ein halbes Jahr warten und sowas wie ServicePacks anbieten!!! Vielleicht habt ihr noch nie etwas für eure Box runtergeladen und benutzt nur eure DistriCD's, vielleicht seit ihr auch zu **** mit 'patch' umzugehen, sollte es jedoch anders sein, muss ich mich echt fragen wie man sowas nur schreiben kann...
Wenn ein BUG gefunden wird, dann wird sofort ein Patch herausgegeben. Ob es dannach 2.4.8 oder 2.4.8.1 heisst ist doch jeder LinuxBOX scheiss egal und vor allem ist es nicht peinlich, gegenüber irgendeinem Unternehmen ein Patch herauszubringen (auch wenns 100 an einem Tag sind), im Gegenteil beweisst das nur KOMPETENZ UND SICHERHEIT, von welcher sich manch ein anderes OS eine grosse Scheibe abschneiden sollte...
denkt mal drüber nach
Hat wohl von denen (die hier nörgeln) nie einer was mit Softwareentwicklung zu tun gehabt, sonst wüssten sie, wie gerade der Entwickler selber den Bug übersieht, da er nicht alle Möglichkeiten der Software (des Kernels) durchspielen kann.
Sowas ist vollkommen normal und menschlich.
Was ich unmöglich finde sind solche Mega-Patches in Form von Service-Packs, die von bezahlten Programmieren in monatelanger Arbeit entstehen und noch so voller Bugs stecken, daß u.U. nachher kritischere Bugs hervorgebracht werden, oder manch alte bekannte Sicherheitslücke weiterhin besteht.
Sorry für die sehr langen Sätze - keine Ahnung, was heute mit mir los ist ...
Bei Linux schauen hunderte von Entwickler auf den Code - und finden Sie einen Fehler, so wird er idR gefixt. Die Frage ist hier nun, wie schwer dieser Fehler war und ob er jede Installation betrifft. Es ist eine Demonstration der Leistungsfähigkeit des Entwicklersystems, wenn bereits 5 Stunden nach dem Kernelrelease der Fehler gefixt ist. Bei MS kann das schon eine längere Zeitspanne dauern - mittlerweile ja jeden 2.Mittwoch im Monat (wenn ich mich recht erinnere).
Gibt es eigentlich schon eine Vorschau auf 2.7 und der dortigen, neuen Features?
Da, wie du selber schriebst, der Fehler bereits wenige Minuten nach der Veröffentlichung von Linux 2.6.8 entdeckt wurde, wenige Minuten darauf behoben wurde und eine neue Version nur Stunden später veröffentlicht wurde, ist offensichtlich, dass der Fehler wohl nicht jede Installation betrifft. Er betrifft ausschließlich Systeme, die innerhalb weniger Minuten nach Erscheinen von Linux 2.6.8 aktualisiert wurden *und* die als NFS-Clients eingesetzt werden *und* bei denen der Administrator beim Testen des Kernels geschlampt hat.
> Gibt es eigentlich schon eine Vorschau auf 2.7 und der dortigen, neuen Features?
Nein, gibt es nicht. Da es nach derzeitigem Kenntnisstand keinen 2.7er Zweig geben wird, wäre das auch etwas schwierig.
jwm
> Er betrifft ausschließlich Systeme, die innerhalb weniger Minuten nach Erscheinen von Linux 2.6.8 aktualisiert wurden *und* die als NFS-Clients eingesetzt werden *und* bei denen der Administrator beim Testen des Kernels geschlampt hat.
Dazu kommt natürlich noch, dass Vanilla-Kernel von kernel.org nach Aussage der Entwickler niemals auf Produktivsystemen oder von Endnutzern eingesetzt werden sollen, sondern dass für diesen Zweck die Kernel der Distributionen gedacht sind. Wenn also tatsächlich jemand Linux 2.6.8 von kernel.org eingesetzt hat, dann tat er dies gegen den ausdrücklichen Rat der Entwickler und ist mithin also selbst schuld.
jwm
Zum Beispiel. Das ist schon seit Jahren so und hat bisher IMHO ziemlich gut funktioniert, warum also etwas verändern?
> ich finde wenigstens der kernel sollte einheitlich sein oder nicht?!
Ich finde, dass "One Size fits all" kein gutes Motto ist. Die Anforderungen in den verschiedenen Einsatzszenarien sind einfach viel zu unterschiedlich, als dass man sie mit einer Standardlösung erschlagen könnte. Es ist nun einmal so, dass es nicht ein Linux gibt sondern viele Linuxe für viele verschiedene Einsatzzwecke. Es gibt ein Linux von Linux Torvalds, das als eine Art gemeinsamer Basis dient, eines von Andrew Morton, das als Testumgebung für die Alltagstauglichkeit neuer Entwicklungen dient, eines von Andrea Arcangeli, das eine Testumgebung für die Speicherverwaltung auf großen Servern darstellt und außerdem die Basis für die SuSE-Kernel ist, eines von Matt Mackall, speziell für Geräte mit starken Speicher-Einschränkungen, eines von Nick Piggin und eines von Con Kolivas, beide mit Fokus auf Interaktivität bei Desktop-Anwendungen, eines von Marc-Christian Petersen mit dem Versuch, möglichst viele Features zu integrieren, eines von SuSE, eines von RedHat, eines von Fedora, eines von Mandrake, eines von Debian u.s.w..
Damit hat eben jeder die Wahl, welches Linux er für welchen Einsatzzweck auswählt.
jwm
> Ich finde, dass "One Size fits all" kein gutes Motto ist.
Sehe ich genauso, daher ist bei mir seit Linux 2.4.0 die erste Amtshandlung auf einem frisch installierten Linux, erstmal den Standardkernel der Distribution runterzuschmeissen und meinen eigenen, schlanken und (neuerdings auch) statischen Kernel zu backen.
iGEL
Die Distributionskernel weil damit das Einspielen von Patches die gegen Vanilla erstellt wurden besonders viel Spass macht? Schon mal versucht einen Patch auf einen SuSE-Kernel anzuwenden?
Ich benutze nur Kernel.org-Kernel. Allerdings warte ich jeweils - wenn ich nicht gerade dringend ein Feature benötige - ein bisschen. Der Grund: Kernel 2.4.11 - dessen Bug war nicht ein Detail wie hier.
MfG Peschmä
Ah, endlich mal eine technisch fundierte und tiefgründig analysierte Aussage. So etwas findet man in Webforen leider sehr selten.
> Was soll man denn nutzen?
Den Kernel, der nach Analyse der Anforderungen das Profil am ehesten trifft.
> Schon mal versucht einen Patch auf einen SuSE-Kernel anzuwenden?
Nein, ich wüsste nicht, wozu ich das tun sollte.
> Ich benutze nur Kernel.org-Kernel.
Das bleibt dir unbenommen. Du musst dir halt nur der Tatsache bewusst sein, dass du damit gegen die erklärte Empfehlung der Entwickler verstößt.
jwm
> findet man in Webforen leider sehr selten.
Ein Punkt für den Kandidaten. Etwa genau so fundiert wie die Aussage der Kernelentwickler...
Oder wollen die sich etwa ums Bugfixen drücken - Fehler in Distrokerneln meldet man wohl nicht bei Kernel.org...
> Nein, ich wüsste nicht, wozu ich das tun sollte.
Stimmt, den verwendet man gar nicht erst.
> Das bleibt dir unbenommen. Du musst dir halt nur der Tatsache bewusst sein, dass du
> damit gegen die erklärte Empfehlung der Entwickler verstößt.
Schon so. Aber so ganz ernst meinen die das wohl nicht. Das heisst es ja auch bei Mozilla, oder?
Und bei Debian Testing/Sid ist davon auch immer die Rede. Endanwender die nicht entwickeln sollen stable nutzen. Oder auch "wer das fragt will Woody".
MfG Peschmä
Dass Kernel von x dann besser laufen würde glaube ich nicht denn die sind:
- manchmal zugepatcht (SuSE)
- manchmal auch nicht (Debian)
- aber sicher weniger gut getestet bzw. es hat weniger Leute die die testen
MfG Peschmä
Das ist das erste mal, dass ich von sowas höre. Quelle?
Alan Cox. Sorry, ich weiß nicht jeden Link zu jeder Aussage, die er jemals gemacht hat auswendig.
Es ging jedefalls um den ptrace()-Bug. Marcelo Tosatto wurde von Endanwendern stark kritisiert, weil er kein schnelles Bugfix-Release veröffentlicht hatte. Alan Cox meinte dazu, das sei unnötig, weil das die Distributoren bereits getan hätten und die Anwender ohnehin einen Distributionskernel einsetzen sollten.
Es gab noch einige andere Gelegenheiten, bei denen verschiedene Kernel-Hacker die Nutzung der Distributionskernel empfohlen haben. Dazu kommt natürlich speziell auf den 2.6er Kernel bezogen noch das neue Entwicklungsmodell, ohne einen dedizierten Entwicklungszweig.
jwm
(sorry, den konnte ich mir nicht verkneifen)
Schreit ihr Deppen da auch, MS mach deinen Laden zu????
Außerdem ist das ja wohl kein so gravierendes Problem, eher ein Problemchen, das halt sofort gefixt wurde, bis ich von dem neuen Kernel erfuhr, war der .1 schon da mit nem Fix, wenn das andere Firmen auch so hinkriegen dann ein großes Lob an die.
Deswegen haltet einfach eure dämliche Schnauze, eure kindliches Gehabe ist einfach nur blöd.
Wer einen "stabilen" Kernel benutzt, für den noch keine nachfolgende Entwicklerversion existiert, wie es noch bei 2.6 der Fall ist, sollte sich nicht wundern. Sämtliche Patches fließen dann noch in diesen ein und das sind nicht nur Bugfixes. Es kann zu grundlegenden Schnittstellenänderungen kommen, was den Namen "stable" nun wirklich nicht verdient hat.
Mit diesem Wissen ist allerdings jedem selbst überlassen, ob er sich das antut, oder doch lieber auf den "richtigen" stable Kernel wartet (2.6.?), sobald die erste 2.7er-Version rausgebracht wird.
Gruß
L00NIX
d.h. es wird voraussichtlich noch recht lange nur 2.6.x geben.
MfG Peschmä
Der Vorteil liegt nicht in fehlerfreier Software, sondern in schneller Behebung der gefundenen Bugs.
- immer mehr geräte
- immer mehr code
- immer mehr file-systeme
es muss schlechter werden. zum glück ist das nicht nur bei linux so sondern bei jedem os
Ich hoffe sehr, dass bald der 2.7er geforkt wird, damit ich mit der Evaluierung des 2.6er für die Server beginnen kann, da einige sehr interessante Änderungen und Verbesserungen enthalten sind. Im Moment ist das für mich noch reine Zeitverschwendung da ich den 2.6er Kernel als Entwicklerversion betrachte und ich ihn noch nicht als einsatzfähig betrachte.
Gruss,
Thoralf
diese Frage basiert auf die Nutzung von Routern mit ARM CPUs. Man läuft Gefahr, das man sich den Router zerflasht.....
Kann man einmal einen Kernel mit USB-Unterstützung flashen, der dann den Kernel vom USBstick bootet (gegebenfalls USB to Ramdisk, booten des Kernel B von Ramdisk) und zwar auch, wenn die Versionen der Kernel unterschiedlich ist?
Mann könnte so recht entspannt auf einem USBstick neue Kernels ausprobieren ;)
Im Archiv der Linuxbios mailingliste haben ich einen Hinweis gefunden, das dies scheinbar geht:
"
"I'm fighting from another angle. I have a kernel booting another
kernel working for an SMP kernel. Now if I just need to get it to work
for a SMP kernel when more than 1 cpu is in the box and I'll be in good shape
http://www.linuxbios.org/faq/archive/0632.html
Blos wie? Irgendjemand einen Tip? URL?
Gruss
rob