Ich habe seit dem 26.11 den 2.4.16pre1 laufen und hatte mit dem noch keine Probleme. Allerdings weiss ich nicht, wie oft und "zuverlaessig" der Fehler auftritt oder sich bemerkbar macht.
Ich kann die Ideen von Marcelo auch wirklich nur begrüßen; Sowohl dass er einen bereinigten 2.4.16 herausbringt, als auch, dass er etwas mehr Qualität in die Release-Kernel bringen will.
Mal ne Frage, die vielleicht etwas Offtopic ist: Bei welchem 2.2.x wurde der 2.3er-Zweig eröffnet?
... da sieht man mal wieder was sich hier für leute rumtreiben *kopfschüttel* vielleicht solltest du doch bei windows bleiben, da kriegste dein kernelupdate zu kaufen... gleiches gilt für die "ist peinlich"-leute! nimand zwingt euch linux zu benutzen, wenns euch zu peinlich ist, benutzt windows!!!
Dann kommen ja jetzt hoffentlich mit Marcelo bessere Zeiten. Was Linus die letzte Zeit so abgesegnet hat, war ja beim besten Willen und beide Augen zudrücken nicht so das Gelbe. Das mit den Release Kandidaten halte ich auch für eine gute Idee. Zudem kann man es ruhig in Zukunft etwas ruhiger angehen lassen. Schliesslich gibt es keinen Preis für den schnellsten Versionwechsel beim Kernel (oder verheimlicht uns Linus etwas )
Egal wie man das jetzt nennt, ich hoffe das diese peinlichen Fehler in den sogenannten "stabilen" Kernelversionen endlich der Vergangenheit angehören. Mit solchen Nachrichten bekommt man sonst schnell einen schlechten Ruf in der Industrie. Ich zumindest finde das es sich gut anhört was Marcelo da schreibt. Ich wünsche ihm viel Erfolg.
Bei mir läuft der auch gut, werde heut Nacht noch ein paar Belastungstests durchführen und hoffe mal das der weiterhin gut läuft. Das mit den Release Kandidaten halte ich auch für eine gute Idee, ich meine wenn Alan in der 2.2 Serie was ähnliches macht ist das ein recht guter Beweis für eine bessere Qualitätssicherung, also bei mir liefen auf jeden Fall alle 2.2 recht gut.
P.s. weis zufällig jemand ob USB Drucker unter Linux laufen, will mir demnächst nen neuen Drucker zulegen
Mfg Jensemann (happy testing and hopefully no patching)
Ja, USB Drucker laufen, aber es geht um einiges leichter mit einem Drucker am Parallel-Port ... Überhaupt würde ich zu so einem Drucker raten, wenn bei dir nicht schon andere Geräte dranhängen ...
Jop.. der Meinung bin ich auch. Parallelport oder USB ist gleichschwer einzurichten. Hier läuft z.B. ein HP 970Cxi an USB mit Cups+Gimp-print 4.2. Supereinfach einzurichten. Klick, klick (Cups hat den Drucker am USB beim einrichten schon gefunden).
Ältere Programme sind auch kein Problem. Statt /dev/lp0 nimmt man halt /dev/usb/lp0. Was solls...
Das ist ja der größte Schwachsinn, den ich seit Tagen gelesen habe. Nicht dumm daher labern, sondern mal Fakten liefern - hier die Übertragungsgeschwindigkeiten der typischen Ports (MBit/s):
Seriell 0,115 Parallel 0,920 USB 1.x (low) 1,5 USB 1.x (high) 12 USB 2.0 ~480 Firewire (iLink) 100-400
Wobei USB (low) für Mäuse und Tastaturen verwendet wird und die high-variante für Drucker, Scanner, Kameras, usw.
Wobei man aber nicht vergessen darf, dass der Parallelport für die Arbitrierung extra Leitungen hat. Bei allen seriellen Protokollen wird die theoretische Transferrate in der Praxis nie erreicht (und im Falle von USB auch noch auf mehrere Geräte aufgeteilt), insofern kann es durchaus sein, dass der Parallelport schneller ist. Das hängt aber natürlich auch von der Qualität des Druckers ab
Nochmal so ein Schwachsinn. USB ist schneller. Seit ich meinen Drucker an USB angeschlossen habe, hält der bei Photodrucken nicht mehr an und wartet auf weitere Daten, wie früher beim parallel Port. Der druckt und druckt. Einfach nur genial. Außderdem ist die CPU Last wesentlich geringer als bei dem alten parallel Port. Also ich bin froh, daß ich den endlich im Bios abschalten konnte dank USB.
USB 2 ist auf jedenfall Unsinn, da hast du recht. Soweit ich weiss, ist USB 2 noch nicht einmal Steckerkompatibel (bin aber nicht sicher), was für mich der einzige Vorteil gegenüber des schon eingeführten, erprobten und schnelleren Firewire wäre (Firewire wurde doch gerade für die 4x-fache Geschwindigkeit spezifiziert, oder?)
Aber für Tastatur, Scanner und Drucker reicht USB1 doch eigentlich aus. Ich denke auch, dass dieses etwas günstiger als Firewire ist, daher halte ich es schon für sinnvoll.
Ich glaube, dass die viele verschiedenen Stecker wie die Parallele und Seriellen Schnittstelle, aber auch die PS/2-Anschlüsse an Neugeräten demnächst wegfallen, daher greife ich jetzt schon zu USB-Geräten. Aber USB2 werde ich so gut es geht vermeiden (Wollte VIA nicht Boards mit Firewire Onboard rausbringen?) :)
*LOL* von wegen USB ist langsamer als der Parallel. Ihr haut euch hier die Taschen mit Unsinn voll ;)
Der USB1 arbeitet mit einer Datenrate von 12 MBit pro Sekunde. Daraus ergibt sich eine maximale theoretische Datenrate von 1.5 MByte pro Sekunde. Aufgrund des Codierungsverfahrens und des Overheads liegt die praktisch erzielbare Datenrate bei etwa 1 MByte pro Sekunde. Zusätzlich unterstützt USB auch einen "Low-Speed" Modus mit 1.5 MBit/s. Die Übertragung dieser Daten erfolgt innerhalb des 12 MBit/s Datenstroms. Die niedrigere Datenrate eignet sich insbesondere für Geräte wie Tastatur und Maus. USB2 liegt wie schon gesagt bei ca. 480 MBit/s dürfte aber noch nicht
Im Standard-Mode schafft der Parallel-Port ca. 100-150Kb/s. Im ECP/EPP Modus bis zu 1MB/s.
Resume: USB1 und der Parallelport im ECP/EPP Modus liegen fast gleich. Bei USB2 sieht das natürlich ganz anders aus.
Es ist schon erstaunlich, was manche Leute für einen Müll zusammen quasseln. USB1 nicht Steckerkompatible zu USB2 . Mein Gott?! Lasst es doch einfach mit dem posten, wenn ihr keine Ahnung habt. Und dann immer dieses Rumgelabere "ist besser...quak...quak...quak". Natürlich ist Firewire technisch besser wie USB, aber dass interessiert einfach (niemanden wäre das falsche Wort) zu wenige. Dumm-User (davon gibt es eben wesentlich mehr) kaufen einfach was im Laden steht und wenig kostet, aber nach viel aussieht -> USB. Das wars...nix Firewire und so...dies wird sich auch mit 4xFirewire nicht ändern. Sobald USB2 auf den ersten Mainboards hängt, werden (leider) nach Firewire noch weniger Leute krähen. Aber dass hier immer wieder Leute zu geistigen Ergüssen kommen müssen, die keinerlei Inhalt haben wundert mich doch immer wieder.
Da kann ich Dir nicht rechtgeben, denn USB2 tut sich _sehr_ schwer gegenüber Firewire, es gibt mehr und mehr Mainboards mit FW-Support, und das nicht nur im PPC-Lager ;). Abgesehen davon ist die FW-Hardware auch (noch ?) deutlich billiger als die USB2-Hardware. USB2 ist schon lange am Markt, aber kaum einer springt auf den Zug, vor allem nicht seitdem viele der großen Hersteller auf der IFA gesagt haben, daß Firewire der zukünftige Standard sein wird für digitale (Video/MM)-Übertragung.
Moin, hmmmm, USB, langes Kabel.... habe seit einiger Zeit einen kleinen Printserver. Da kann die Leitung noch laenger sein.....
Zum Thema: Die Releasepolitik der 2.4 Kernel hat mir auch nicht gefallen, zuviele Kernel wurden als stabil herausgegeben, obwohl es Entwicklerkernel waren (DuD, Device under Development). Ich hoffe jedenfalls auch, dass das jetzt wieder strenger gehandhabt wird.
Suspend to disc. Seit wann braucht man da einen Patch. Ich habe hier ein Dell Inspiron 4000. Wenn ich da den Suspend Knopf drücke geht Linux bei mir Out of the Box in einen Suspend to disc Modus. Nix mit Patch. Und das sogar mit Kernel 2.2.18. Ohne Patch oder sonstwas. Nur Suspend to RAM ist stressig, aber wer braucht das schon. Suspend to disc ist wesentlich sinnvoller.
Suspend to Disc läuft unter Linux auch auf meinem Thinkpad. Aber: Das Hybernation-File habe ich mit einem Tool des Biosherstellers unter DOS gemacht. Windows hingegen nutzt sein eigenes File und hat das auch selbst erstellt. Für die meisten Desktop-PC wird es wohl schwierig ein Hybernation-File-Utility vom Bioshersteller zu finden.
Ich denke der Vorschlag ging eher in diese Richtung. Wäre schön, wenn Linux out-of-the-box Hybertnation-Files herstellen könnte.
@Hey Der Suspend to Ram Patch nutzt soweit ich das gelesen habe den Swap als "Hybernation-File". Wenn da laut Info nicht die Compiler-Probleme mit dem Patch wären, hätte ichs mal ausprobiert. War ja klar, daß ich hier genau den Compiler am Laufen habe, der mit dem Patch nicht klar kommt...
Ich kann zwar mit meinem Vaio-FX-301 auch ein Suspend to Disk machen, aber bei Wakeup wird neu gebootet :-(, bei APM-Suspend hängt sich das ganze System auf (beim Wakeup, bei manchen Kernel-Versionen sogar beim suspend). Das Hibernation File kann man auch unter Linux anlegen, bei mir 4. Primäre Partition, die Daten müssen am Ende der Festplatte liegen (und natürlich größer als RAM Wieviel größer ist denn bei euch der Platz (RAM+Swap+x oder das doppelte ?). Die Tools heißen lphdisk( www.procyon.com/~pda/lphdisk/)
Vor ein paar Tagen hatte ich geschrieben [...und NUR: Widerspruch erhalten... ]
"Waran es hier FEHLT, ist dass breitangelegte Tests durchgeführt werden, BEVOR ein Kernel schließlich freigegeben wir. (!)"
Nur so als Gedanke [zu QA]... VOR dem Final gibt es eben noch einen Pre-Final Kernel.
Und wenn da dann GROBE Schnitzer auftauchen, wie jetzt, werden die eben noch gefixt, SONST aber nichts! (D.h. der übrige Code wird nicht mehr angerührt!!!)
Mit so einer Release-Politik hätte man ALL die unschönen Sachen im Zusammenhang mit den letzten Kernel-Releases LEICHT vermeiden können!
Ich hatte das dann noch präzisierte:
"Dieser pre-final sollte also ähnlich wie jetzt der final "veröffentlicht" werden: und schön wäre es sogar, wenn sich Linux-User darum BEMÜHEN würden, in diesen "Vorabversionen" noch Fehler zu finden!!!
Überleg mal, WIE GUT, dann der wirkliche Final sein könnte!"
Und n u n darf ich hier lesen:
Tosatti plant für die zukünftigen Versionen eine langsamere Abfolge von Versionen, die vor der endgültigen Version besser getestet sind. Unter Umständen wird es vor jeder offiziellen Version einen oder mehrere »Release-Kandidaten« geben.
Was ich enen etwas sonderbar finde... Dass das offenbar alles von der "Lust und Laune" eines Menschen (in diesem Fall der Kernel-Maintainer) abhängt...
SEHR seltsam...
Tosatti hält das für g u t, also wird es gemacht. Wenn Tosatties NICHT für gut halten würde, würde es OFFENBAR nicht gemacht...
Mein Eindruck ist, dass in der Linux-Community für DERARTIGES einfach kein "Problem-Bewusstsein" vorhanden ist; was ich für bedenklich halt: Alle wollen offenbar nur BEUTZEN, dass man dafür aber auch etwas BEITRAGEN muss, scheint nur wenigen klar zu sein... :-(
Was ich eben etwas sonderbar finde..., dass das offenbar alles von der "Lust und Laune" eines Menschen (in diesem Fall der Kernel-Maintainer) abhängt...
SEHR seltsam...
Tosatti hält das für g u t, also wird es gemacht. Wenn Tosatti es NICHT für gut halten würde, würde es OFFENBAR nicht gemacht...
Mein Eindruck ist, dass in der Linux-Community für DERARTIGES einfach kein "Problem-Bewusstsein" vorhanden ist; was ich für bedenklich halt: Alle wollen offenbar nur BENUTZEN, dass man dafür aber auch etwas BEITRAGEN muss, scheint nur wenigen klar zu sein... :-(
"Wow, du hast das Prinzip hinter Open Source kapiert! Glückwunsch!"
***ROFL***
D.h. EIN Vollkoffer kann also darüber entscheiden, was 100.000de Anwender zu akzeptieren haben...?!
Plädierst Du hier also für das Herdenwesen?! :-)) // "Führer befiehl wir folgen Dir!!!"?
Und ich dachte immer: Open Source wäre eine "Gemeinschaftssache"... :-)
F.
P.S. Wenn Du Dich zu einem "Almosen-Empfänger" herabwürdigen willst, der (gefälligst) NIMMT, was man ihm GIBT - ohne selbst seine Meinung einzubringen [geschweige denn etwas zu hinterfragen/ kritisieren oder gar ANZUREGEN]... ist das DEINE Sache, meine ist es nicht.
Ich habe auch schon mal ein Programm unter der GPL veroeffentlicht (OK, es waren nur ein paar hundert Zeilen ).
Ich habe es geschrieben, weil ICH Spass daran hatte, weil ICH etwas lernen wollte und weil ICH es benoetigt habe. ICH habe den Funktionsumfang festgelegt und ICH habe den Releasetermin bestimmt. Natuerlich duerfen die Leute das Programm benutzen, es fuer ihre Zwecke anpassen und erweitern, soviel Bugreports und Wunschlisten an mich schreiben wie sie wollen. Wer das will, darf sogar ein Qualitaetssicherungsprojekt fuer mein Programm ins Leben rufen (Hallo Franz!). Aber ICH entscheide, was in MEINEM persoenlichen Entwicklungszweig davon beruecksichtigt wird und was nicht und wann das in welchem Zustand veroeffentlicht wird.
Ob, wann, was und wie Du das machst bei Deinem Privaten kleinen Programmierprojekt (ob nun GPL oder nicht) bleibt ganz Dir überlassen.
Jedoch sieht die Sache bei einem Kernel, der von 100.000en Leuten (privat) verwendet wird, und auch in Industrie und Wirtschaft zunehmend eine Rolle spielt, IMHO etwas anders aus...
D A S ist *kein* privates Hobbyprojekt mehr. Und m.E. sollte so was auch NICHT von Lust und Laune EINER Person abhängen... // Du solltest auch nicht vergessen, dass der Kernel nicht das Ergebnis des Arbeit eines einzelnen, sondern ein REINES "Gemeinschaftswerk" ist! ( Insofern verstehe ich den Zusammenhang Deines Postings mit meinem nicht wirklich... [?] )
Daher ist Tosatti auch nur Maintainer und nicht "Eigentümer"...
Aber SELBST das sollte IMHO nicht [nur] in einer einzigen Hand sein...; so was wie ein "Beratergremium" wäre sicher nicht schlecht...; letztlich muss natürlich _einer_ dafür verantwortlich zeichnen, klar...
Angenommen, mein Programm entwickelt sich zu einer echten Killerapp, jeder Linuxanwender benutzt es (*traeum*).
Da ich es nicht mehr alleine schaffe, gestatte ich einigen von mir ausgewaehlten Mitprogrammierern CVS-Schreibzugriff auf die Sourcen, wir sind jetzt also ein Programmiererteam. Ja, inzwischen baue ich auch schon mal Patches von Dritten ein, das betrachte ich dann als kleines Dankeschoen fuer meine Bemuehungen.
Ploetzlich werden wir von allen Seiten bedraengt, unser Programm sei jetzt ja nicht mehr ein persoenliches Projekt, wir sollen gefaelligst ein demokratisches Gremium einberufen (hmm, von wem sollen die Mitglieder gewaehlt werden?), das uns von jetzt an vorschreibt, was wir zu programmieren haben, und wann wir es veroeffentlichen duerfen. Und wenn wir uns nicht daran halten, werden wir dann gefeuert?
Nein Danke!
Wem das nicht passt, kann sich ja die Sourcen nehmen, einen eigenen Ableger entwickeln und unter diesen Rahmenbedingungen weiterentwickeln.
Leute, ihr kapierts echt nie. Open Source hat längst ein Demokratisches Verfahren für wichtige Entscheidungen: Die Anwender entscheiden. Wenn niemand mehr den Kernel eines bestimmten Maintainers benutzt, sondern andere Kernel von Maintainern, die den Anwendern besser gefallen, ist das doch sehr demokratisch. So funktioniert das. Was nicht mögich ist: Irgendein Gremium sagt, was der Kernelmaintainer zu tun hat. Denn der macht, was er für richtig hält und niemand kann es ihm verbieten (das sagt die Lizens so). Wenn jemand was dagegen hat, muss erŽs selber besser machen. Das kann wiederum auch niemand verbieten. Sagt auch die Lizens.
Ich weiß WIRKLICHT nicht, was Du da zusammenfaselst... : Du quargelst Da irgendwas von DEINEM Programm... usw.
Alles schön und gut. Du scheinst aber übersehen zu haben, dass der Kernel kein "Privatprojekt" eines einzelnen ist... // Ja, es WAR einmal das "Privatprojekt" eine Typen namens Linus... - dies ist ja auch der Grund, dass ihm niemand den Führungsanspruch streitig macht (bislang)... - Ganz abgesehen davon BESITZT der Mann "Linux" auch als TM... :-)
DANN scheinst Du auch den Unterschied zwischen einer APPLIKATION und einem OS-Kernel zu übersehen...
Wenn mir eine Applikation nicht passt, gibt es sicher eine andere, die mir mehr entspricht... : d.h. ich nehme dann halt einfach eine andere... bei einem OS-(Kernel) ist das nicht ganz so einfach... Wenn die Qualität der Linux-Kernel-Releases immer schlechter wird, kann ich nicht einfach auf einen Anderen Kernel setzen..
*GRINS* - DE FAKTO haben das aber zunehmend mehr Leute gemacht, indem sie statt Linus' Kernel den von Alan verwendet haben... :-)
Aber ich denke, Du weißt schon was ich meine: D A S ist doch auch keine Lösung!
(Das würde in letzter Konsequenz zu einem Kernel-Forking führen, und ich glaub nicht, dass das *irgendjemand* will!)
Aber zurück zu Deinem Entwicklungsbeispiel:
"Ploetzlich werden wir von allen Seiten bedraengt, unser Programm sei jetzt ja nicht mehr ein persoenliches Projekt, wir sollen gefaelligst ein demokratisches Gremium einberufen (hmm, von wem sollen die Mitglieder gewaehlt werden?), das uns von jetzt an vorschreibt, was wir zu programmieren haben, und wann wir es veroeffentlichen duerfen.
Da hast Du schon recht. Solange das Dein Projekt ist...
Im Grunde kann Dir da niemand reinreden...
Dennoch gibt es eben auch VENUNFTSGRÜNDE... für einen solchen Schritt.
"Wem das nicht passt, kann sich ja die Sourcen nehmen, einen eigenen Ableger entwickeln und unter diesen Rahmenbedingungen weiterentwickeln."
Ja, diese Gefahr besteht dann wohl...
(Am denke nur an die -ac und -aa Kernel... ;-)
Trotzdem ist diese Sichtweise ZU ENG m.E.
Für QA gibt es eine ganze Reihe von Vernunftgründen - denen man sich m.E. als halbwegs vernünftiger Mensch, der mit seiner Entwicklungstätigkeit auch etwas ERREICHEN will, kaum entziehen kann.
Es geht hier also nicht um "Zwang", sondern darum, dass sich die Vernunft durchsetzt. Ein Projekt mit dem Umfang das inzwischen das Kernel-Projekt angenommen hat OHNE vernünftig implementierte QA zu betreiben, ist schlichtweg "Wahnsinn" - bestenfalls "kontraproduktiv"... (Wie man ja sieht...)
Gruß, Franz
P.S. Etliche Projekte in der Freien Szene funktionieren aber sehr wohl über sog. Steering Committees... (der GCC z.B..., oder FreeBSD...)
Ich denke schon, dass der Linus-Tree immer noch Linus "Privatprojekt" ist, solange er alleine entscheidet, was in "seinen" Kernel kommt und was nicht. Es kann ihm auch niemand "wegnehmen". Im schlimmsten denkbaren Fall laufen ihm die Mitentwickler weg, so dass er irgendwann wieder alleine davorsitzt. Abgesehen davon ist der Kernel schon lange gespalten. Da gibt es die 2.0.x, 2.2.x, 2.4.x, 2.5.x, ac-Kernel, SuSE-, Redhat-, Mandrake-Kernel usw. usw..
Wie viele Trottel dürfen eigetlich da draußen so rumlaufen? Und dann auch noch das Internet nutzen?
Diese "Wenn ich etwas nutzen will, muß es passen ..." Mentalität ... bäh, das ist doch wohl wahrlich zum reiern!!! Warum wird denn auf Teufel komm raus aus 2.4.15 gewechselt? Weil es sein [b]muß[/b]????? Wohl kaum, doch wohl eher damit man Hip ist. Wenn es euch nicht paßt .... kein Problem, kauft euch Caldera OpenUnix (ab $500) für eine Einzellizenz, und da habt ihr dann auch einen gewissen Anspruch auf Leistung. Solange ihr nichts tut, haltet gefälligst mit solchen Äußerungen hinterm Berg.
Genau wie bei den pre-Kerneln werden alle auf das Final-Release warten, bis der neue Kernel dann in praktischen Tests eingesetzt wird. Die seltener auftretenen Fehler werden in diesem Fall auch erst zu spät auftreten. Softwarefirmen haben massive Probleme beim Testen, und das obwohl große Summen ausgegeben werden.
Linux kann nur stabil werden bzw. bleiben, wenn seeeehr viele Leute, und nicht nur die Kernelentwickeler, testen, da viele Fehler nur unter sehr speziellen Bedingungen auftreten, bei denen automatische Tests auch nicht helfen (ganz zu schweigen von der Betriebsblindheit).
Bei Softwareprojekten, die Testmatrizen (QMS) verwendeten, funktionierten nur die getesten Fälle, da sich niemand mehr die Mühe machen musste, Testbedingungen zu entwicklen.
Ja, klar und DESHALB plädiere ich ja dafür, dass sich eben neben der reinen Nutzer-Community auch noch eine eigene Tester-Community etablieren sollte.
Hat für mich auch ein wenig was mit einer "ethischen" Fragestellung zu tun.
Nuuur... Man muss es a) halt auch WOLLEN von Seiten der "Linuxer"...; und b) auch noch organisieren...
Aber das TRAURIGE ist, dass ich den Eindruck habe, dass noch nicht mal a) gegeben ist! :-(
@dil
Pre-Final muss natürlich ähnlich offiziell gemacht werden, wie derzeit die eigentliche Kernel-Release, sonst hat's natürlich keinen Zweck.
Die Qualität muss dabei schon SO GUT sein, dass ein Privatanwender ruhig versuchen kann das Teil zu installieren, und in 9 von 10 Fällen sollte das dann auch klappen...
Anders formuliert: diese Pre-Finals haben dann die Qualität, die derzeitige "Finals" haben...
"Die seltener auftretenen Fehler werden in diesem Fall auch erst zu spät auftreten."
Absolut richtig: es geht in so einem Fall darum, OFFENSICHTLICHE Fehler, wie eben den jetzt wieder sofort "abzufangen". SO WAS darf einfach nicht in einer Final sein!
Softwarefirmen haben massive Probleme beim Testen, und das obwohl große Summen ausgegeben werden.
...Softwarefirmen haben auch massive Probleme bei der ENTWICKLUNG von Software: "und das obwohl große Summen ausgegeben werden." (Man denke an MS...)
Versteht doch: Die "Freie Software" darf sich nicht nur auf die PRODUKTION der Software erstrecken, sondern sollte auch die QA umfassen!!!
"Linux kann nur stabil werden bzw. bleiben, wenn seeeehr viele Leute, und nicht nur die Kernelentwickeler, testen, da viele Fehler nur unter sehr speziellen Bedingungen auftreten" 100% meine Meinung!!! (Siehe oben)
"...die Testmatrizen (QMS)..."
ALLEIN ein derartiges Projekt, dass sich um die Etablierung derartiger Matrizen für Linux kümmert würde wohl einen enormen QA-Boost bedeuten für Linux... --- Das alles sollte im Rahmen eines groß angelegten "Test-Projekt" aufgezogen werden...
(Seufz... Ich hab mir zu dem Thema schon die Finger wundgeschrieben... Ohne da auf sonderliche Resonanz zu stoßen, ich lass es daher jetzt...)
Ich versteh das Problem nicht. Es gibt eine Release. Ein Fehler wird entdeckt *und noch am gleichen Tag behoben*.
Was soll das Gejammere? Software enthält nunmal Fehler.
Und dann dieser Unfug über "das Ansehen in der Industrie". Klar doch: Alle Betreiber von kritischen Servern spielen sich immer sofort die letzte Kernel-Version ein. Ein Wunder, dass bei 2.4.15 nicht das Internet kaputt gegangen ist!
Es geht nicht darum, dass Fehler gemacht werden und Probleme auftreten, sondern wie schnell diese behoben werden.
Und da sehe ich - im Gegensatz zu den Bedenkenträgern hier - ehrlich gesagt überhaupt kein Problem.
@b. >Ich versteh das Problem nicht. Es gibt eine Release. Ein Fehler wird entdeckt *und noch am gleichen Tag behoben*. Für was braucht man dann deiner Meinung nach noch Entwicklerkernel?
>Klar doch: Alle Betreiber von kritischen Servern spielen sich immer sofort die letzte Kernel-Version ein. Was spricht gegen das einspielen des LETZTEN STABLE RELEASE, wenn dort gemäss Changelog ein Fehler behoben wird, den man mit der vorversion hatte, oder er einfach neue benötigte Features hat? Deiner Argumentation(?) zufolge, kann letztlich niemand mehr einen Kernel isntallieren.
>Es geht nicht darum, dass Fehler gemacht werden und Probleme auftreten, sondern wie schnell diese behoben werden. Das ist lächerlich. Unter anderem scheitert das ja an deinen eigenen Ausführungen. Ich denke an: Wer in der Industrie spielt schon den aktuelsten kernel ein (ein patch ist ja nichts anderes). tut mir leid, aber du widersprichst dir hier selbst.
>Und da sehe ich - im Gegensatz zu den Bedenkenträgern hier - ehrlich gesagt überhaupt kein Problem. DAS kann ich mir gut vorstellen.
auch etwas off-topic aber (vielleicht kann mir ja jemand der Herren/Damen helfen bzw. einen Rat geben): seit ich weiss nicht 2.4.9 oder so tut meine TV-Karte nicht mehr
Werden denn alle Module (bttv,msp3400 usw.) geladen (was zeigt lsmod an)? Was zeigt cat /proc/video/dev/video0? Wurde bei einem neuen Kernel nochmal ein z.b make menuconfig/xonfig gemacht und kontrolliert ob bei den Multimedia-Devices alles richtig ausgewählt worden ist? Wurden die richtigen Optionen in der /etc/module.conf eingestellt z.b.
# ... bei einer WinTV alias char-major-81 videodev alias char-major-81-0 bttv options bttv radio=1 card=10 tuner=5
existieren überhaupt die Video-Devices /dev/video* usw. Was "sagt" z.b xawtv oder zapping beim Start und was steht in den log-files z.b. in "/var/log/sys.log"
aber die idee der release candidates is gut... bringt hoffentlich was mehr stabilität ins geschehen
Das hoffe ich auch! Ich denke mal, dass allein die Einführung der 2.5er Serie einiges Beta-Zeugs von dem Stable Tree fernhalten wird.
Gruss Hendric
wurde auch höchste Eisenbahn das sich was tut
an der Kernelreleasepolitik.
Hoffen wir, daß man irgendwann nen neuen 2.4er genaus bedenkenlos testen konnte wie seinerzeit nen neuen 2.2er.
Bye
Stefan
-----------------------
Das OS-Forum: http://beta.forumprovider.de/?user=stefan3x&board=test2
Ich kann die Ideen von Marcelo auch wirklich nur begrüßen; Sowohl dass er einen bereinigten 2.4.16 herausbringt, als auch, dass er etwas mehr Qualität in die Release-Kernel bringen will.
Mal ne Frage, die vielleicht etwas Offtopic ist: Bei welchem 2.2.x wurde der 2.3er-Zweig eröffnet?
cu Johannes
gleiches gilt für die "ist peinlich"-leute! nimand zwingt euch linux zu benutzen, wenns euch zu peinlich ist, benutzt windows!!!
also bei mir läuft's perfekt.
Der 2.4.16 is bei mir 4 mal gepacht worden. (Forher 2.4.12)
:)
cu
P.s. weis zufällig jemand ob USB Drucker unter Linux laufen, will mir demnächst nen neuen Drucker zulegen
Mfg Jensemann (happy testing and hopefully no patching)
Überhaupt würde ich zu so einem Drucker raten, wenn bei dir nicht schon andere Geräte dranhängen ...
modprobe printer
/dev/usblp0 statt /dev/lp0 verwenden .. fertig
außerdem ist es doch erheblich günstiger mal ein 10m-USB-Kabel zu verwenden, als eine vergleichbares parallel-kabel
mfg Matthias
Mfg Jensemann
Ältere Programme sind auch kein Problem. Statt /dev/lp0 nimmt man halt /dev/usb/lp0. Was solls...
Ich wünsche noch eine schöne Nacht...
USB sollte doch schneller gehen ?!
Das ist ja der größte Schwachsinn, den ich seit Tagen gelesen habe.
Nicht dumm daher labern, sondern mal Fakten liefern - hier die Übertragungsgeschwindigkeiten der typischen Ports (MBit/s):
Seriell 0,115
Parallel 0,920
USB 1.x (low) 1,5
USB 1.x (high) 12
USB 2.0 ~480
Firewire (iLink) 100-400
Wobei USB (low) für Mäuse und Tastaturen verwendet wird und die high-variante für Drucker, Scanner, Kameras, usw.
Das hängt aber natürlich auch von der Qualität des Druckers ab
Also ich bin froh, daß ich den endlich im Bios abschalten konnte dank USB.
daherreden.
USB braucht eine Host (PC), firewire nicht.
Wäre es nicht besser NUR Firewire
zu benutzen? Die Technik ist doch besser, oder?
USB 2 ist auf jedenfall Unsinn, da hast du recht. Soweit ich weiss, ist USB 2 noch nicht einmal Steckerkompatibel (bin aber nicht sicher), was für mich der einzige Vorteil gegenüber des schon eingeführten, erprobten und schnelleren Firewire wäre (Firewire wurde doch gerade für die 4x-fache Geschwindigkeit spezifiziert, oder?)
Aber für Tastatur, Scanner und Drucker reicht USB1 doch eigentlich aus. Ich denke auch, dass dieses etwas günstiger als Firewire ist, daher halte ich es schon für sinnvoll.
Ich glaube, dass die viele verschiedenen Stecker wie die Parallele und Seriellen Schnittstelle, aber auch die PS/2-Anschlüsse an Neugeräten demnächst wegfallen, daher greife ich jetzt schon zu USB-Geräten. Aber USB2 werde ich so gut es geht vermeiden (Wollte VIA nicht Boards mit Firewire Onboard rausbringen?) :)
cu Johannes
Der USB1 arbeitet mit einer Datenrate von 12 MBit pro Sekunde. Daraus ergibt sich eine maximale theoretische Datenrate von 1.5 MByte pro Sekunde. Aufgrund des Codierungsverfahrens und des Overheads liegt die praktisch erzielbare Datenrate bei etwa 1 MByte pro Sekunde. Zusätzlich unterstützt USB auch einen "Low-Speed" Modus mit 1.5 MBit/s. Die Übertragung dieser Daten erfolgt innerhalb des 12 MBit/s Datenstroms. Die niedrigere Datenrate eignet sich insbesondere für Geräte wie Tastatur und Maus.
USB2 liegt wie schon gesagt bei ca. 480 MBit/s dürfte aber noch nicht
Im Standard-Mode schafft der Parallel-Port ca. 100-150Kb/s. Im ECP/EPP Modus bis zu 1MB/s.
Resume:
USB1 und der Parallelport im ECP/EPP Modus liegen fast gleich. Bei USB2 sieht das natürlich ganz anders aus.
Mein Gott?! Lasst es doch einfach mit dem posten, wenn ihr keine Ahnung habt. Und dann immer dieses Rumgelabere "ist besser...quak...quak...quak". Natürlich ist Firewire technisch besser wie USB, aber dass interessiert einfach (niemanden wäre das falsche Wort) zu wenige.
Dumm-User (davon gibt es eben wesentlich mehr) kaufen einfach was im Laden steht und wenig kostet, aber nach viel aussieht -> USB. Das wars...nix Firewire und so...dies wird sich auch mit 4xFirewire nicht ändern. Sobald USB2 auf den ersten Mainboards hängt, werden (leider) nach Firewire noch weniger Leute krähen.
Aber dass hier immer wieder Leute zu geistigen Ergüssen kommen müssen, die keinerlei Inhalt haben wundert mich doch immer wieder.
Suamor.
hmmmm, USB, langes Kabel....
habe seit einiger Zeit einen kleinen Printserver.
Da kann die Leitung noch laenger sein.....
Zum Thema: Die Releasepolitik der 2.4 Kernel
hat mir auch nicht gefallen, zuviele Kernel
wurden als stabil herausgegeben, obwohl es
Entwicklerkernel waren (DuD, Device under Development).
Ich hoffe jedenfalls auch, dass das jetzt wieder strenger gehandhabt wird.
73
Peter
Hat eigentlich schonmal jemand den Suspend to RAM - Patch ausprobiert?
Gruß
Marc
(Leerzeichen entfernen)
Gruß
Marc
Nur Suspend to RAM ist stressig, aber wer braucht das schon. Suspend to disc ist wesentlich sinnvoller.
Ich denke der Vorschlag ging eher in diese Richtung. Wäre schön, wenn Linux out-of-the-box Hybertnation-Files herstellen könnte.
Der Suspend to Ram Patch nutzt soweit ich das gelesen habe den Swap als "Hybernation-File".
Wenn da laut Info nicht die Compiler-Probleme mit dem Patch wären, hätte ichs mal ausprobiert. War ja klar, daß ich hier genau den Compiler am Laufen habe, der mit dem Patch nicht klar kommt...
Gruß
Marc
Die Angst den 2.4.16 einzusetzen sitzt mir noch in den Knieen. Wenn das man gut geht...
-Sven-
weisst Du (oder sonst einer) auch, wie das geht, wenn nicht out of the box?
thx
kamome
Das Hibernation File kann man auch unter Linux anlegen, bei mir 4. Primäre Partition, die Daten müssen am Ende der Festplatte liegen (und natürlich größer als RAM
Suamor.
Vor ein paar Tagen hatte ich geschrieben [...und NUR: Widerspruch erhalten...
]
"Waran es hier FEHLT, ist dass breitangelegte Tests durchgeführt werden, BEVOR ein Kernel schließlich freigegeben wir. (!)"
Nur so als Gedanke [zu QA]... VOR dem Final gibt es eben noch einen Pre-Final Kernel.
Und wenn da dann GROBE Schnitzer auftauchen, wie jetzt, werden die eben noch gefixt, SONST aber nichts! (D.h. der übrige Code wird nicht mehr angerührt!!!)
Mit so einer Release-Politik hätte man ALL die unschönen Sachen im Zusammenhang mit den letzten Kernel-Releases LEICHT vermeiden können!
Ich hatte das dann noch präzisierte:
"Dieser pre-final sollte also ähnlich wie jetzt der final "veröffentlicht" werden: und schön wäre es sogar, wenn sich Linux-User darum BEMÜHEN würden, in diesen "Vorabversionen" noch Fehler zu finden!!!
Überleg mal, WIE GUT, dann der wirkliche Final sein könnte!"
Und n u n darf ich hier lesen:
Tosatti plant für die zukünftigen Versionen eine langsamere Abfolge von Versionen, die vor der endgültigen Version besser getestet sind. Unter Umständen wird es vor jeder offiziellen Version einen oder mehrere »Release-Kandidaten« geben.
Seufz... Leute, Leute... (Kopfschüttel).
F.
SEHR seltsam...
Tosatti hält das für g u t, also wird es gemacht. Wenn Tosatties NICHT für gut halten würde, würde es OFFENBAR nicht gemacht...
Mein Eindruck ist, dass in der Linux-Community für DERARTIGES einfach kein "Problem-Bewusstsein" vorhanden ist; was ich für bedenklich halt: Alle wollen offenbar nur BEUTZEN, dass man dafür aber auch etwas BEITRAGEN muss, scheint nur wenigen klar zu sein... :-(
Naja...
F.
SEHR seltsam...
Tosatti hält das für g u t, also wird es gemacht. Wenn Tosatti es NICHT für gut halten würde, würde es OFFENBAR nicht gemacht...
Mein Eindruck ist, dass in der Linux-Community für DERARTIGES einfach kein "Problem-Bewusstsein" vorhanden ist; was ich für bedenklich halt: Alle wollen offenbar nur BENUTZEN, dass man dafür aber auch etwas BEITRAGEN muss, scheint nur wenigen klar zu sein... :-(
Naja...
F.
Wow, du hast das Prinzip hinter Open Source kapiert! Glückwunsch!
Es nervt mich an, dass einige Leute hier das Kernelteam offenbar für ihre Angestellten halten ...
b.
***ROFL***
D.h. EIN Vollkoffer kann also darüber entscheiden, was 100.000de Anwender zu akzeptieren haben...?!
Plädierst Du hier also für das Herdenwesen?! :-)) // "Führer befiehl wir folgen Dir!!!"?
Und ich dachte immer: Open Source wäre eine "Gemeinschaftssache"... :-)
F.
P.S.
Wenn Du Dich zu einem "Almosen-Empfänger" herabwürdigen willst, der (gefälligst) NIMMT, was man ihm GIBT - ohne selbst seine Meinung einzubringen [geschweige denn etwas zu hinterfragen/ kritisieren oder gar ANZUREGEN]... ist das DEINE Sache, meine ist es nicht.
Ich habe es geschrieben, weil ICH Spass daran hatte, weil ICH etwas lernen wollte und weil ICH es benoetigt habe. ICH habe den Funktionsumfang festgelegt und ICH habe den Releasetermin bestimmt.
Natuerlich duerfen die Leute das Programm benutzen, es fuer ihre Zwecke anpassen und erweitern, soviel Bugreports und Wunschlisten an mich schreiben wie sie wollen. Wer das will, darf sogar ein Qualitaetssicherungsprojekt fuer mein Programm ins Leben rufen (Hallo Franz!).
Aber ICH entscheide, was in MEINEM persoenlichen Entwicklungszweig davon beruecksichtigt wird und was nicht und wann das in welchem Zustand veroeffentlicht wird.
Ist das jetzt Totalitarismus?
Ob, wann, was und wie Du das machst bei Deinem Privaten kleinen Programmierprojekt (ob nun GPL oder nicht) bleibt ganz Dir überlassen.
Jedoch sieht die Sache bei einem Kernel, der von 100.000en Leuten (privat) verwendet wird, und auch in Industrie und Wirtschaft zunehmend eine Rolle spielt, IMHO etwas anders aus...
D A S ist *kein* privates Hobbyprojekt mehr. Und m.E. sollte so was auch NICHT von Lust und Laune EINER Person abhängen... // Du solltest auch nicht vergessen, dass der Kernel nicht das Ergebnis des Arbeit eines einzelnen, sondern ein REINES "Gemeinschaftswerk" ist! ( Insofern verstehe ich den Zusammenhang Deines Postings mit meinem nicht wirklich... [?] )
Daher ist Tosatti auch nur Maintainer und nicht "Eigentümer"...
Aber SELBST das sollte IMHO nicht [nur] in einer einzigen Hand sein...; so was wie ein "Beratergremium" wäre sicher nicht schlecht...; letztlich muss natürlich _einer_ dafür verantwortlich zeichnen, klar...
F.
Angenommen, mein Programm entwickelt sich zu einer echten Killerapp, jeder Linuxanwender benutzt es (*traeum*).
Da ich es nicht mehr alleine schaffe, gestatte ich einigen von mir ausgewaehlten Mitprogrammierern CVS-Schreibzugriff auf die Sourcen, wir sind jetzt also ein Programmiererteam. Ja, inzwischen baue ich auch schon mal Patches von Dritten ein, das betrachte ich dann als kleines Dankeschoen fuer meine Bemuehungen.
Ploetzlich werden wir von allen Seiten bedraengt, unser Programm sei jetzt ja nicht mehr ein persoenliches Projekt, wir sollen gefaelligst ein demokratisches Gremium einberufen (hmm, von wem sollen die Mitglieder gewaehlt werden?), das uns von jetzt an vorschreibt, was wir zu programmieren haben, und wann wir es veroeffentlichen duerfen. Und wenn wir uns nicht daran halten, werden wir dann gefeuert?
Nein Danke!
Wem das nicht passt, kann sich ja die Sourcen nehmen, einen eigenen Ableger entwickeln und unter diesen Rahmenbedingungen weiterentwickeln.
Open Source hat längst ein Demokratisches Verfahren für wichtige Entscheidungen: Die Anwender entscheiden.
Wenn niemand mehr den Kernel eines bestimmten Maintainers benutzt, sondern andere Kernel von Maintainern, die den Anwendern besser gefallen, ist das doch sehr demokratisch.
So funktioniert das. Was nicht mögich ist: Irgendein Gremium sagt, was der Kernelmaintainer zu tun hat. Denn der macht, was er für richtig hält und niemand kann es ihm verbieten (das sagt die Lizens so).
Wenn jemand was dagegen hat, muss erŽs selber besser machen. Das kann wiederum auch niemand verbieten. Sagt auch die Lizens.
Ich weiß WIRKLICHT nicht, was Du da zusammenfaselst... : Du quargelst Da irgendwas von DEINEM Programm... usw.
Alles schön und gut. Du scheinst aber übersehen zu haben, dass der Kernel kein "Privatprojekt" eines einzelnen ist...
// Ja, es WAR einmal das "Privatprojekt" eine Typen namens Linus... - dies ist ja auch der Grund, dass ihm niemand den Führungsanspruch streitig macht (bislang)... - Ganz abgesehen davon BESITZT der Mann "Linux" auch als TM... :-)
DANN scheinst Du auch den Unterschied zwischen einer APPLIKATION und einem OS-Kernel zu übersehen...
Wenn mir eine Applikation nicht passt, gibt es sicher eine andere, die mir mehr entspricht... : d.h. ich nehme dann halt einfach eine andere... bei einem OS-(Kernel) ist das nicht ganz so einfach... Wenn die Qualität der Linux-Kernel-Releases immer schlechter wird, kann ich nicht einfach auf einen Anderen Kernel setzen..
*GRINS* - DE FAKTO haben das aber zunehmend mehr Leute gemacht, indem sie statt Linus' Kernel den von Alan verwendet haben... :-)
Aber ich denke, Du weißt schon was ich meine: D A S ist doch auch keine Lösung!
(Das würde in letzter Konsequenz zu einem Kernel-Forking führen, und ich glaub nicht, dass das *irgendjemand* will!)
Aber zurück zu Deinem Entwicklungsbeispiel:
"Ploetzlich werden wir von allen Seiten bedraengt, unser Programm sei jetzt ja nicht mehr ein persoenliches Projekt, wir sollen gefaelligst ein demokratisches Gremium einberufen (hmm, von wem sollen die Mitglieder gewaehlt werden?), das uns von jetzt an vorschreibt, was wir zu programmieren haben, und wann wir es veroeffentlichen duerfen.
Da hast Du schon recht. Solange das Dein Projekt ist...
Im Grunde kann Dir da niemand reinreden...
Dennoch gibt es eben auch VENUNFTSGRÜNDE... für einen solchen Schritt.
"Wem das nicht passt, kann sich ja die Sourcen nehmen, einen eigenen Ableger entwickeln und unter diesen Rahmenbedingungen weiterentwickeln."
Ja, diese Gefahr besteht dann wohl...
(Am denke nur an die -ac und -aa Kernel... ;-)
Trotzdem ist diese Sichtweise ZU ENG m.E.
Für QA gibt es eine ganze Reihe von Vernunftgründen - denen man sich m.E. als halbwegs vernünftiger Mensch, der mit seiner Entwicklungstätigkeit auch etwas ERREICHEN will, kaum entziehen kann.
Es geht hier also nicht um "Zwang", sondern darum, dass sich die Vernunft durchsetzt. Ein Projekt mit dem Umfang das inzwischen das Kernel-Projekt angenommen hat OHNE vernünftig implementierte QA zu betreiben, ist schlichtweg "Wahnsinn" - bestenfalls "kontraproduktiv"... (Wie man ja sieht...)
Gruß,
Franz
P.S. Etliche Projekte in der Freien Szene funktionieren aber sehr wohl über sog. Steering Committees... (der GCC z.B..., oder FreeBSD...)
Es kann ihm auch niemand "wegnehmen". Im schlimmsten denkbaren Fall laufen ihm die Mitentwickler weg, so dass er irgendwann wieder alleine davorsitzt.
Abgesehen davon ist der Kernel schon lange gespalten. Da gibt es die 2.0.x, 2.2.x, 2.4.x, 2.5.x, ac-Kernel, SuSE-, Redhat-, Mandrake-Kernel usw. usw..
Diese "Wenn ich etwas nutzen will, muß es passen ..." Mentalität ... bäh, das ist doch wohl wahrlich zum reiern!!!
Warum wird denn auf Teufel komm raus aus 2.4.15 gewechselt? Weil es sein [b]muß[/b]????? Wohl kaum, doch wohl eher damit man Hip ist.
Wenn es euch nicht paßt .... kein Problem, kauft euch Caldera OpenUnix (ab $500) für eine Einzellizenz, und da habt ihr dann auch einen gewissen Anspruch auf Leistung. Solange ihr nichts tut, haltet gefälligst mit solchen Äußerungen hinterm Berg.
Und W E R testet dann die neuen Releases, Anonymous?! ???
F.
Als Tester hast Du halt keinen Anspruch auf irgendetwas ....
das Problem der unzureichenden Tests sind die fehlenden Tester.
Gerrit
Linux kann nur stabil werden bzw. bleiben, wenn seeeehr viele Leute, und nicht nur die Kernelentwickeler, testen, da viele Fehler nur unter sehr speziellen Bedingungen auftreten, bei denen automatische Tests auch nicht helfen (ganz zu schweigen von der Betriebsblindheit).
Bei Softwareprojekten, die Testmatrizen (QMS) verwendeten, funktionierten nur die getesten Fälle, da sich niemand mehr die Mühe machen musste, Testbedingungen zu entwicklen.
dil
Ja, klar und DESHALB plädiere ich ja dafür, dass sich eben neben der reinen Nutzer-Community auch noch eine eigene Tester-Community etablieren sollte.
Hat für mich auch ein wenig was mit einer "ethischen" Fragestellung zu tun.
Nuuur... Man muss es a) halt auch WOLLEN von Seiten der "Linuxer"...; und b) auch noch organisieren...
Aber das TRAURIGE ist, dass ich den Eindruck habe, dass noch nicht mal a) gegeben ist! :-(
@dil
Pre-Final muss natürlich ähnlich offiziell gemacht werden, wie derzeit die eigentliche Kernel-Release, sonst hat's natürlich keinen Zweck.
Die Qualität muss dabei schon SO GUT sein, dass ein Privatanwender ruhig versuchen kann das Teil zu installieren, und in 9 von 10 Fällen sollte das dann auch klappen...
Anders formuliert: diese Pre-Finals haben dann die Qualität, die derzeitige "Finals" haben...
"Die seltener auftretenen Fehler werden in diesem Fall auch erst zu spät auftreten."
Absolut richtig: es geht in so einem Fall darum, OFFENSICHTLICHE Fehler, wie eben den jetzt wieder sofort "abzufangen". SO WAS darf einfach nicht in einer Final sein!
Softwarefirmen haben massive Probleme beim Testen, und das obwohl große Summen ausgegeben werden.
...Softwarefirmen haben auch massive Probleme bei der ENTWICKLUNG von Software: "und das obwohl große Summen ausgegeben werden." (Man denke an MS...)
Versteht doch: Die "Freie Software" darf sich nicht nur auf die PRODUKTION der Software erstrecken, sondern sollte auch die QA umfassen!!!
"Linux kann nur stabil werden bzw. bleiben, wenn seeeehr viele Leute, und nicht nur die Kernelentwickeler, testen, da viele Fehler nur unter sehr speziellen Bedingungen auftreten"
100% meine Meinung!!! (Siehe oben)
"...die Testmatrizen (QMS)..."
ALLEIN ein derartiges Projekt, dass sich um die Etablierung derartiger Matrizen für Linux kümmert würde wohl einen enormen QA-Boost bedeuten für Linux... --- Das alles sollte im Rahmen eines groß angelegten "Test-Projekt" aufgezogen werden...
(Seufz... Ich hab mir zu dem Thema schon die Finger wundgeschrieben... Ohne da auf sonderliche Resonanz zu stoßen, ich lass es daher jetzt...)
F.
Was soll das Gejammere? Software enthält nunmal Fehler.
Und dann dieser Unfug über "das Ansehen in der Industrie".
Klar doch: Alle Betreiber von kritischen Servern spielen sich immer sofort die letzte Kernel-Version ein. Ein Wunder, dass bei 2.4.15 nicht das Internet kaputt gegangen ist!
Es geht nicht darum, dass Fehler gemacht werden und Probleme auftreten, sondern wie schnell diese behoben werden.
Und da sehe ich - im Gegensatz zu den Bedenkenträgern hier - ehrlich gesagt überhaupt kein Problem.
b.
Hab nachsicht mit Franz.
Er hat das alles noch nicht soo verstanden, möchte aber immer seinen Senf dazugeben. ;-)
mfg
Raver
>Ich versteh das Problem nicht. Es gibt eine Release. Ein Fehler wird entdeckt *und noch am gleichen Tag behoben*.
Für was braucht man dann deiner Meinung nach noch Entwicklerkernel?
>Klar doch: Alle Betreiber von kritischen Servern spielen sich immer sofort die letzte Kernel-Version ein.
Was spricht gegen das einspielen des LETZTEN STABLE RELEASE, wenn dort gemäss Changelog ein Fehler behoben wird, den man mit der vorversion hatte, oder er einfach neue benötigte Features hat? Deiner Argumentation(?) zufolge, kann letztlich niemand mehr einen Kernel isntallieren.
>Es geht nicht darum, dass Fehler gemacht werden und Probleme auftreten, sondern wie schnell diese behoben werden.
Das ist lächerlich.
Unter anderem scheitert das ja an deinen eigenen Ausführungen. Ich denke an: Wer in der Industrie spielt schon den aktuelsten kernel ein (ein patch ist ja nichts anderes). tut mir leid, aber du widersprichst dir hier selbst.
>Und da sehe ich - im Gegensatz zu den Bedenkenträgern hier - ehrlich gesagt überhaupt kein Problem.
DAS kann ich mir gut vorstellen.
Gruß
Lutz
Kann man NUR FROH SEIN, dass man D i r nicht die das Kernel-Maintaining angetragen hat... :-)
F.
P.S.
@Lutz: Dem was b. da zusammenschreibt, kann ich auch nichts abgewinnen. (...)
seit ich weiss nicht 2.4.9 oder so tut meine TV-Karte nicht mehr
# ... bei einer WinTV
alias char-major-81 videodev
alias char-major-81-0 bttv
options bttv radio=1 card=10 tuner=5
existieren überhaupt die Video-Devices /dev/video* usw. Was "sagt" z.b xawtv oder zapping beim Start und was steht in den log-files z.b. in "/var/log/sys.log"
;-)