Mich freuts wenn der kernel so schnell entwickelt wird (hat ja uach eine starke finanzelen rücken). Mich wuerds aber gerade mehr freuen wenn OS Anwendungs programm so schnell entwickelt werden würden.
Hier mal kleine umfragen: http://votter.de/votes/cat6/p0/f2/ -Welcher kernel? http://votter.de/votes/cat6/p0/f36/ - was muss entwickelt werden
Auch wenn ich auch das KMS für ein interessantes Projekt halte, was erwartest Du Dir im Alltag für große Konsequenzen davon? Und nachdem es Einzug in den Kernel gehalten hat, wird es wohl immer noch noch eine Weile daueren, bis es mit den verschiedenen Grafikkarten zusammenspielt.
Von Daniel Böhmer am Sa, 25. Oktober 2008 um 17:37 #
Hallo allerseits,
ich habe seit 1 Jahr einen Lenovo ThinPad T61. Mich hat schon immer gestört, dass der hdaps-Daemon nur mit alten Kerneln und vielem Herumpatchen funktioniert.
Leidet die Festplatte eigentlich sehr unter dem Beinahe-Parken??
Wisst ihr, ob schon ein spezieller Daemon in der Mache ist, der Beschleunigungsmesser und Festplatte koppelt?
Hi, die Änderungen von Release zu Release lesen sich gut und der Anfängliche "Chaos" scheint ja beseitigt (Versionierung usw...).
Was ist aber mit den Treiber für die Grafikkarten? Gleich vorne weg, ich will weder trollen noch irgendetwas schlecht machen!!! Mir gehts eigentlich nur um ein paar Ansätze die vor einiger Zeit besprochen worden sind, wie z.B. Teile in den Userland zu verschieben. Was geht da oder nicht... DKMS gibts ja schon, aber das ist ja Distri abhängig obs verwendet wird.
Ich habe letztens bei Mandriva 09 nen Testkernel installiert und daraufhin den fglrx de- und wieder installiert. DKMS hat in jedem gefundenen Kernel ein Treiber kompiliert. Ich war angenehm überrascht. Geht das auch mit einem Vanilla Kernel??? Wie sieht es bei einem Versions Upgrade des Grafiktreiber aus?? Ich hab nämlich den Treiber von der AMD/ATI HP runtergeladen und anfags hat es so ausgesehen als würde er kompilieren aber irgendwie hats nicht gefunzt, DKMS hat gemeckert und beim starten kam ne Meldung. X hat dann mit Vesa gestartet....
Weis jemand Bescheid ob man die User Experience im Puncto Grafiktreiber verbessern will, ist doch mitunter eines der ältesten Leiden die ich mit Linux erfahren hab.
Da solltest du die Hersteller der proprietären Grafiktreiber fragen, deren Entscheidung es ist einen Sonderweg zu gehen und die Welt freier Software mit proprietären Treibern zu verderben. Die User Experience steht in dessen Handeln nicht im Vordergrund sonst würden sie dafür Sorge tragen, dass ihre Treiber in den Kernel kommen.
Ja schon, muss dir recht geben und ich kenne schon den Zustand der closed Source Treiber (erlebe es gerade wieder mal mit meiner ATI Graka im Laptop, die ausschließlich mit dem fglrx funzt, in Intrepid isser aber im Moment BROKEN )
Um die open source Treiber mach ich mir mal keine Sorgen, da sie ja mit xorg mitgeliefert werden, aber ein Treiber upgrade oder noch schlimmer ein Kernel upgrade kann schon mal Nerven kosten... und da sollten sich Kernelhacker und Hardwarehersteller an einem Tisch setzen und eine Lösung finden! (Ist mein persönliches Wunschdenken)
Die Treiberhersteller sind aber nicht die einzigen, die für die "User Experience" verantwortlich sind. Das sind an diese Stelle ebenso die Kernel-Maintainer, die ihren Zirkus um stabile APIs nutzen, um externe Treiber zu behindern.
Hallo els, Vielleicht solltest Du Dich entscheiden ob du lieber auf das Paketsystem ODER die Downloadtreiber von AMD/Ati vertraust. Beides gleichzeitig geht schief. Gruß Hamsta
Irgendwie kommen meiner Meinung nach die "neuen" Kernel viel zu schnell hintereinander. 2.6.27 ist noch nicht so lange Verfügbar schon steht der nächste Kernel in den Startlöchern und der alte wird bald nicht mehr (richtig) mit Updates gepflegt (bzw. muss von den Distros gepflegt werden) und der Support beendet auch wenn eventuell noch einige Bugs ungefixt bleiben. Wäre es nicht besser nur alle 6 Monate einen neuen Kernel rauszubringen und so lange Bugfixing für den "alten" zu betreiben, da schließlich die meißten Bugs erst nach Veröffentlichung der finalen Version (bzw. wenn diese in die Distros eingebaut wurden) und somit bei (Heim)useranwendung gefunden werden. Doch bis die Bugs dann mal gemeldet sind, gibt es schon Kernel hastdunichtgesehen und man soll "auf einen neuen Kernel" aktualisieren.
Den richtigen Release-Zyklus zu finden ist immer ein Kompromiss aus vielen Faktoren. Bei einem längeren Release-Zyklus wird die Liste der Patches die auf Integration warten eben auch immer länger, und die Gefahr, daß sich dann zwei dieser Patches untereinander behaken steigt somit auch. Enwtwickler werden frustriert, wenn ihre Arbeit lange auf Aufnahme in den Kernel warten muß, usw, ...
Sei doch froh, daß die Entwicklung so zügig geht. Es gibt doch den Support durch die Distributionen, von daher betrifft Dich das Endanwender ohnehin nur, wenn Du selber immer den neusten Kernel haben willst. Aber auch von den Kernelentwicklern gibt es Kernelversionen die länger gepflegt werden (sollen) als andere.
Stimmt. Aber auch da ist es ja so, daß die Distributoren schon den Backport dringend benötigter Treiber übernehmen, bzw. diese jetzt schon vor der offiziellen Aufnahme in den Kernel in ihre Sourcen patchen. Auch das hat also, für Endanwender, meist wenig mit dem derzeitigen Release-Zyklus zu tun. Der e1000 Bug von vor ein paar Wochen hat doch eindringlich gezeigt, daß man, sollte man immer den aktuellen Entwickler-Kernel von kernel.org benutzen, dies ausdrücklich auf eigene Gefahr macht. Für den Endanwender sollte immer der jeweilige Distributionskernel relevant sein. Und da gelten andere Regeln, als daß ein Update zwingend fällig ist wenn Linus ein Release Tag in seinen Kernel-Tree schreibt.
Schön, daß man am Puls der Kernel-Entwicklung dabei sein kann, man sollte dann dann aber auch wissen was man tut.
Naja, da kamen ein paar Sachen zusammen, deswegen hat es ja auch ein wenig gedauert, bis man den Bug wirklich schließen konnte. Aber er war eine Erinnerung daran, daß die Entwickler-Kernel nicht umsonst Entwickler-Kernel heißen. Der OP bemängelte ja eine zu hohe Release Frequenz an offiziellen Kernel, und selbst von denen sollte man als Normalanwender eher die Finger lassen und auf die distributionseigenen Kernel warten.
Bei einigen ist das ja eine Art Volkssport jeweils den allerneusten Kernel zu nutzen. Das kann man auch gerne machen, aber man sollte sich dann eben nicht beschweren, wenn einige Patches des Distributors fehlen und manches nicht mehr so rund läuft. Und bei noch nicht mal offiziell veröffentlichten Test Versionen muß man eben schlimmstenfalls mit Hardwareproblemen rechnen. Wer sich allerdings das antut, wird sich auch nicht über zu schnelle Kernel Releases beschweren, wer dagegen die Distributions-Kernel benutzt ist von einem neuen offiziellen Releas zunächst mal nicht direkt betroffen.
Doch bis die Bugs dann mal gemeldet sind, gibt es schon Kernel hastdunichtgesehen und man soll "auf einen neuen Kernel" aktualisieren.Aehm, wo ist jetzt genau das Problem? Man kann doch keinen fehlerfreien Kernel haben wollen aber dann gleihzeitig nicht bereit sein, Aktualisierungen vorzunehmen wenn es notwendig ist. Ich musste in meinen Linux-Jahren weder auf Server- noch auf Desktopseite Kernel-Aktualisierungen vornehmen, damit ein bestimmter Kernel-Bug gefixt wurde. Meistens lag das an irgendwelchen proprietären Modulen oder Programmen, die irgendeinen Schweinskram gemacht haben.
Bitte lasst mal mit dem Tempo nach. Ich glaube nicht das der kurze Zyklus der Qualität des Kernels schadet.
Von Der Herr vom Berg am Mo, 27. Oktober 2008 um 08:09 #
Ich mag mich ja taeuschen, aber hiess es nicht, dass 2.6.28 den Code fuer Xen als Dom0 enthalten soll? Wurde das jetzt doch geaendert oder fehlt dieser wichtige Part in der Nachricht und ich sollte mir vielleicht dochmal das Changelog angucken?
"Über sysfs kann nun eine Festplatte angewiesen werden, ihre Köpfe anzuheben und sich auf einen Aufprall vorzubereiten."
hehe.. köpfe anheben ^^ is wohl eher gemeint, dass sich die leseköpfe parken... anheben können die sich noch nicht *g*
btw: die entwicklung ist schon interessant. kann mich noch gut an dos zeiten erinnern, wo mir gelernt wurde immer die festplattenköpfe mittels pctools zu parken bevor ich den pc ausmache. nun kommt es in ner anderen form wieder.
Bootet der neue Kernel denn nun wirklich so rasant? Ok, das ein System jetzt nicht in 5 Sekunden gebootet ist, das verstehe ich. Es sollte doch aber an Geschwindigkeit zugenommen haben. Kann das jemand bestätigen?
Ohne nun wirklich Ahnung von der Materie zu haben.
"Offenbar gibt es Anlass zur Vermutung, dass verschiedene BIOSe diesen Speicherbereich korrumpieren und damit zu Problemen bei Suspend oder zu Abstürzen führen können."
Naja.. ich kann mir sehr gut vorstellen, dass ein kaputtes BIOS irgendwelches wirres Zeug in diesen Bereich schreibt und man mit auslassen des Bereichs (sofern so konfiguriert) den Fehler quasi umgeht. Ich würde sagen, der Bereich wird einfach nicht mehr verwendet, wodurch es unwichtig wird, ob ein Bios nun da reinschreibt oder nicht.
Ich hab lieber 64k weniger ram, wenn suspend und standby dafür funktionieren
Mich wuerds aber gerade mehr freuen wenn OS Anwendungs programm so schnell entwickelt werden würden.
Hier mal kleine umfragen:
http://votter.de/votes/cat6/p0/f2/ -Welcher kernel?
http://votter.de/votes/cat6/p0/f36/ - was muss entwickelt werden
Kann man bloss hoffen das die Frühlings-Releases von den großen Distros schon den 2.6.29 enthalten werden und dieser dann KMS hat.
wie ist das zu verstehen ? uwb ist doch unabhängig von 802.11
ich habe seit 1 Jahr einen Lenovo ThinPad T61. Mich hat schon immer gestört, dass der hdaps-Daemon nur mit alten Kerneln und vielem Herumpatchen funktioniert.
Leidet die Festplatte eigentlich sehr unter dem Beinahe-Parken??
Wisst ihr, ob schon ein spezieller Daemon in der Mache ist, der Beschleunigungsmesser und Festplatte koppelt?
die Änderungen von Release zu Release lesen sich gut und der Anfängliche "Chaos" scheint ja beseitigt (Versionierung usw...).
Was ist aber mit den Treiber für die Grafikkarten?
Gleich vorne weg, ich will weder trollen noch irgendetwas schlecht machen!!! Mir gehts eigentlich nur um ein paar Ansätze die vor einiger Zeit besprochen worden sind, wie z.B. Teile in den Userland zu verschieben. Was geht da oder nicht... DKMS gibts ja schon, aber das ist ja Distri abhängig obs verwendet wird.
Ich habe letztens bei Mandriva 09 nen Testkernel installiert und daraufhin den fglrx de- und wieder installiert. DKMS hat in jedem gefundenen Kernel ein Treiber kompiliert. Ich war angenehm überrascht. Geht das auch mit einem Vanilla Kernel???
Wie sieht es bei einem Versions Upgrade des Grafiktreiber aus?? Ich hab nämlich den Treiber von der AMD/ATI HP runtergeladen und anfags hat es so ausgesehen als würde er kompilieren aber irgendwie hats nicht gefunzt, DKMS hat gemeckert und beim starten kam ne Meldung. X hat dann mit Vesa gestartet....
Weis jemand Bescheid ob man die User Experience im Puncto Grafiktreiber verbessern will, ist doch mitunter eines der ältesten Leiden die ich mit Linux erfahren hab.
Mfg
els
Um die open source Treiber mach ich mir mal keine Sorgen, da sie ja mit xorg mitgeliefert werden, aber ein Treiber upgrade oder noch schlimmer ein Kernel upgrade kann schon mal Nerven kosten... und da sollten sich Kernelhacker und Hardwarehersteller an einem Tisch setzen und eine Lösung finden! (Ist mein persönliches Wunschdenken)
Mfg
Vielleicht solltest Du Dich entscheiden ob du lieber auf das Paketsystem ODER die Downloadtreiber von AMD/Ati vertraust.
Beides gleichzeitig geht schief.
Gruß
Hamsta
Wäre es nicht besser nur alle 6 Monate einen neuen Kernel rauszubringen und so lange Bugfixing für den "alten" zu betreiben, da schließlich die meißten Bugs erst nach Veröffentlichung der finalen Version (bzw. wenn diese in die Distros eingebaut wurden) und somit bei (Heim)useranwendung gefunden werden. Doch bis die Bugs dann mal gemeldet sind, gibt es schon Kernel hastdunichtgesehen und man soll "auf einen neuen Kernel" aktualisieren.
Bitte lasst mal mit dem Tempo nach.
Sei doch froh, daß die Entwicklung so zügig geht. Es gibt doch den Support durch die Distributionen, von daher betrifft Dich das Endanwender ohnehin nur, wenn Du selber immer den neusten Kernel haben willst. Aber auch von den Kernelentwicklern gibt es Kernelversionen die länger gepflegt werden (sollen) als andere.
Schön, daß man am Puls der Kernel-Entwicklung dabei sein kann, man sollte dann dann aber auch wissen was man tut.
Bei einigen ist das ja eine Art Volkssport jeweils den allerneusten Kernel zu nutzen. Das kann man auch gerne machen, aber man sollte sich dann eben nicht beschweren, wenn einige Patches des Distributors fehlen und manches nicht mehr so rund läuft. Und bei noch nicht mal offiziell veröffentlichten Test Versionen muß man eben schlimmstenfalls mit Hardwareproblemen rechnen. Wer sich allerdings das antut, wird sich auch nicht über zu schnelle Kernel Releases beschweren, wer dagegen die Distributions-Kernel benutzt ist von einem neuen offiziellen Releas zunächst mal nicht direkt betroffen.
Doch bis die Bugs dann mal gemeldet sind, gibt es schon Kernel hastdunichtgesehen und man soll "auf einen neuen Kernel" aktualisieren.Aehm, wo ist jetzt genau das Problem? Man kann doch keinen fehlerfreien Kernel haben wollen aber dann gleihzeitig nicht bereit sein, Aktualisierungen vorzunehmen wenn es notwendig ist. Ich musste in meinen Linux-Jahren weder auf Server- noch auf Desktopseite Kernel-Aktualisierungen vornehmen, damit ein bestimmter Kernel-Bug gefixt wurde. Meistens lag das an irgendwelchen proprietären Modulen oder Programmen, die irgendeinen Schweinskram gemacht haben.
Bitte lasst mal mit dem Tempo nach.
Ich glaube nicht das der kurze Zyklus der Qualität des Kernels schadet.
hab ich zumindest wo gelesen.
Wurde das jetzt doch geaendert oder fehlt dieser wichtige Part in der Nachricht und ich sollte mir vielleicht dochmal das Changelog angucken?
In dieser Version kamen Xen/ia64, CPU-Hotplug und viele Verbesserungen hinzu, aber von Dom0 sehe ich nichts außer dem folgenden:
xen: clean up domain mode predicates
There are four operating modes Xen code may find itself running in:
- native
- hvm domain
- pv dom0
- pv domU
hehe.. köpfe anheben ^^
is wohl eher gemeint, dass sich die leseköpfe parken... anheben können die sich noch nicht *g*
btw: die entwicklung ist schon interessant. kann mich noch gut an dos zeiten erinnern, wo mir gelernt wurde immer die festplattenköpfe mittels pctools zu parken bevor ich den pc ausmache. nun kommt es in ner anderen form wieder.
http://www.pro-linux.de/news/2008/13237.html
Ist hier nicht eher auszulesen gemeint?
"Offenbar gibt es Anlass zur Vermutung, dass verschiedene BIOSe diesen Speicherbereich korrumpieren und damit zu Problemen bei Suspend oder zu Abstürzen führen können."
Naja.. ich kann mir sehr gut vorstellen, dass ein kaputtes BIOS irgendwelches wirres Zeug in diesen Bereich schreibt und man mit auslassen des Bereichs (sofern so konfiguriert) den Fehler quasi umgeht. Ich würde sagen, der Bereich wird einfach nicht mehr verwendet, wodurch es unwichtig wird, ob ein Bios nun da reinschreibt oder nicht.
Ich hab lieber 64k weniger ram, wenn suspend und standby dafür funktionieren