Entre 2.6.8 et 2.6.9, il y a beaucoup de différences, qui représentent beaucoup de petites choses :
mises à jour de différentes architectures (Sparc, PPC, ARM), ACPI, i2c, USB, systèmes de fichiers, pilotes vidéo et réseau...
ALSA a bénéficié d'une mise à jour massive, grâce à une synchronisation avec leur CVS; les vérifications de types sont maintenant plus strictes (d'où l'augmentation du nombre de warnings à la compilation - corrigez-en!) et pas mal d'annotations ont été ajoutées (elles permettent d'identifier correctement ce qui vient de l'espace utilisateur et ce qui vient du noyau, afin d'éviter que le noyau patouille dans les données utilisateur). Cette version apporte donc beaucoup de nettoyages et quelques fonctionnalités supplémentaires (notamment dans ALSA, mais aussi quelques unes dans différents pilotes).
Certains utilisateurs pourront se rendre compte que les pilotes nVidia sont (encore) cassés, un patch est disponible.
À noter que le Changelog est pour l'instant incomplet, mais Linus Torvalds va le corriger pour qu'il couvre l'intégralité des changements depuis 2.6.8.
À noter aussi que le patch-2.6.9 disponible sur kernel.org est un patch du 2.6.8 au 2.6.9 et non du 2.6.8.1 au 2.6.9.
Aller plus loin
- Changelog 2.6.9 (16 clics)
- télécharger le 2.6.9 (37 clics)
- lien direct vers un miroir en france (20 clics)
- Le patch pour nVidia (7 clics)
# Quelques corrections assez importantes
Posté par un_brice (site web personnel) . Évalué à 6.
(au passage, il feraient mieux de prendre l'habitude de les anoncer plus lisiblement que dans le changelog, surtout qu'il y a eu quelques cas très douloureux y'a pas si longtemps).
Ainsi qu'une autre mise à jour critique de corruption des paquets UDP mais seulement pour "Linux en mode utilisateur".
[^] # Re: Quelques corrections assez importantes
Posté par 007 . Évalué à 5.
Le Linux vanilla n'est plus un noyau pour la production. Ou uniquement pour les personnes abonnées à la lkml et qui comprennent ce qui s'y dit.
C'est lié au nouveau modèle de développement défini durant le dernier sommet noyau :
http://lwn.net/Articles/94386/(...)
Andrew pointed out that, during the 2.6 process, he and Linus have been merging patches at a rate of about 10MB/month. There is, he says, no reason to believe that things will not continue that way. The traditional stabilization mechanism, where almost no patches are accepted for long periods of time, does not strike him as a good idea. Instead, Andrew would like to see a 2.6 tree which continues to change and evolve, and let the distributors do the final stabilization work. In his vision of the future, the kernel.org kernel will be the most featureful and fastest kernel out there, but it will not necessarily be the most stable.
Un autre article qui parle de la même chose :
http://lwn.net/Articles/95312/(...)
À lire attentivement avant de protester.
[^] # Re: Quelques corrections assez importantes
Posté par Colin Leroy (site web personnel) . Évalué à 2.
Exagéré, pour le moins.
let the distributors do the final stabilization work. In his vision of the future, the kernel.org kernel will be the most featureful and fastest kernel out there, but it will not necessarily be the most stable.
Il faut lire stable au sens stabilité des interfaces, APIs et tout ça, pas au sens ça va m'exploser à la figure à chaque branchement de périphérique USB.
[^] # Re: Quelques corrections assez importantes
Posté par 007 . Évalué à 1.
Non.
Au sens ou la stabilité/sécurité n'est pas la priorité. C'est pris en compte, mais ce n'est pas la priorité. Si tel ou tel driver sucks ou s'il y a un trou de sécurité : tant pis. Tu peux attendre plusieurs semaines avant d'avoir un noyau vanilla avec un fix de sécurité (c'est déjà arrivé plusieurs fois !).
Relis bien :
http://lwn.net/Articles/94386/(...)
...
The traditional stabilization mechanism, where almost no patches are accepted for long periods of time, does not strike him as a good idea.
...
These patches include API changes, incidentally. Stable internal kernel APIs have never been guaranteed, but the developers have usually tried to not make big changes during a stable kernel series. That looks to change now.
Ça me parait claire. Si t'as un serveur en production et met à jour vers Linux 2.6.n+1, ça peut ne pas marcher entre autre à cause d'incompatibilité. Mais évidemment que le noyau vanilla marchera sur la plus part des configurations. Sinon comme ils font les développeurs pour bosser :-)
[^] # Re: Quelques corrections assez importantes
Posté par Cali_Mero . Évalué à 1.
Ben si, c'est exactement ce qu'il dit....
[^] # Re: Quelques corrections assez importantes
Posté par 007 . Évalué à 1.
Oui, il a raison, :
- "pas au sens ça va m'exploser à la figure à chaque branchement de périphérique USB."
Effectivement, ça ne va pas exploser à la figure à chaque branchement de périphérique USB. C'est aussi bien qu'un 2.5.
Questions :
C'est bien qu'une machine en production ait les sécurités fix bien après les autres ?
C'est bien qu'une mise à jours (peut-être avec sécurité fix) soit incompatible avec la version production ?
Si pour toi ça aussi ça te parait adapté pour la production...., je ferme ma gueule. J'ai des exigences qui n'ont manifestement plus cours.
[^] # Re: Quelques corrections assez importantes
Posté par Colin Leroy (site web personnel) . Évalué à 3.
T'as pas dû essayer beaucoup de 2.5. C'est incomparable. Le 2.5.69 bootait avec 11472.3 jours d'uptime sur ppc, par exemple...
C'est bien qu'une machine en production ait les sécurités fix bien après les autres ?
C'est bien qu'une mise à jours (peut-être avec sécurité fix) soit incompatible avec la version production ?
C'est pour ça que les gens qui font des choses sérieuses utilisent le noyau de leur distribution. Ils font ça depuis très longtemps, entre nous. Depuis bien avant le "nouveau" modèle de développement qui n'est que l'officialisation de ce qui se passait déjà avant.
[^] # Re: Quelques corrections assez importantes
Posté par 007 . Évalué à -1.
> des choses sérieuses
La production n'est pas une "chose sérieuse" ?
> Depuis bien avant le "nouveau" modèle de développement qui n'est que l'officialisation de ce qui se passait déjà avant.
C'est ce qui est dit dans les url données. Mais il faut faire attention avec toi car tu as sûrement un "avant" et un "avant". C'est le nouveau modèle pour Linux >= 2.6 . L'url donnée ne dit pas que c'est le nouveau modèle pour Linux >= 2.6.9 .
Pour ton info, Linux 2.4 était la précédente branche stable. Donc avant, par rapport à 2.6, ce n'était pas comme maintenant.
[^] # Re: Quelques corrections assez importantes
Posté par Colin Leroy (site web personnel) . Évalué à 2.
C'est de ça dont je parle. T'es bouché, un peu, non?
Pour ton info, Linux 2.4 était la précédente branche stable. Donc avant, par rapport à 2.6, ce n'était pas comme maintenant.
Je pense à "avant" dans le sens < 2.6. Pour ton info, je suis au courant pour le 2.4. Je suis aussi au courant qu'avant encore il y avait le 2.2, etc.
[^] # Re: Quelques corrections assez importantes
Posté par 007 . Évalué à 1.
Ils ont tords aussi car ils n'ont pas ton niveau d'"expertise" ?
C'est le rédacteur de lwn qui affabule ?
Fais moi une explication de texte.
[^] # Re: Quelques corrections assez importantes
Posté par reno . Évalué à 5.
Mouai, le fait de devoir utiliser cdrecord avec le setuid bit maintenant, ce n'est pas tres "stable" comme interface, mais j'admets que c'est "presque stable" *cough*.
Et puis je crois que recemment il y avait une fuite mémoire lors de la gravure d'un CD justement, alors certes ça n'explose pas lors du branchement d'un périphérique USB mais..
D'un autre coté le 2.4 marche bien alors il y a peu de raison d'etre presser de passer en 2.6..
[^] # Re: Quelques corrections assez importantes
Posté par Colin Leroy (site web personnel) . Évalué à 3.
Ça c'est ce qu'on appelle un gros bug, comme le coup du NFS qui a motivé la sortie du 2.6.8.1. Ça n'a rien à voir avec le "nouveau modèle de développement", c'est un bug qui serait arrivé de toutes façons...
[^] # Re: Quelques corrections assez importantes
Posté par lezardbreton . Évalué à 0.
[^] # Re: Quelques corrections assez importantes
Posté par 007 . Évalué à 1.
Linus c'est fait remonté les bretelles pour le 2.6.8.1 (qui a été qualifié de "fiasco" pour le nom) et il a "promis" de ne plus recommencer pour une release officielle.
D'ailleur le patch du 2.6.9 est basé sur un 2.6.8 et non sur un 2.6.8.1. Ceux qui ont un 2.6.8.1 doivent faire un "downgrade" avant d'appliquer le patch.
> Avec l'ancien mode de développement du noyau
On aurait un 2.6.9 à la place de 2.6.8.1. J'avais EXTRAVERSION n'avait été utilisé pour une release officiel sauf pour le 2.6.8.1.
[^] # Re: Quelques corrections assez importantes
Posté par lezardbreton . Évalué à 2.
[^] # Re: Quelques corrections assez importantes
Posté par reno . Évalué à 4.
Bin si un peu quand meme: le systeme des "release candidate" est sens'e attraper ce genre de bug trivial a detecter, mais j'ai comme l'impression que comme ils ont decid'e que c'etait au distrib de stabiliser le kernel, ils vont parfois un 'peu vite' : sur une branche stable, livrer "quand ca compile", ca fait quand meme un poil desordre..
[^] # Re: Quelques corrections assez importantes
Posté par Ramso . Évalué à 2.
De toute façon, qui aurait l'idée de mettre un noyau Vanilla dès qu'il sort ? Les éditeurs font le travail de packaging et il faut laisser le temps de tester.
Bon bien sûr y'a les gentooïstes qui font leurs ports vite fait, comme si c'était critque de l'avoir le soir même... mais qui aurait l'idée de mettre et maintenir une Gentoo en production ?
[^] # Re: Quelques corrections assez importantes
Posté par 007 . Évalué à 2.
J'ai testé une Gentoo assez longuement et cette distribution m'a "bluffée" par sa qualité globale compte tenu de ses objectifs (dont je ne suis pas fou mais c'est une autre histoire).
Le noyau par défaut (stable, c-à-d USE="x86") est un 2.4.
Le noyau en développement (USE="~x86") est un 2.6 et a les patchs de sécurité/fix "qui vont bien".
Il faut bien tester les nouveaux noyaux. Que ce soit en parti fait pas les "gentooïstes" ne me dérange en rien.
Tiens, il y a Linux 2.6.9 dans Rawhide (Fedora). Chiao, je m'en vais tester tout ça.
[^] # Re: Quelques corrections assez importantes
Posté par 007 . Évalué à 1.
Ooops, c'est KEYWORDS="x86". Ou un truc comme ça, je n'ai plus de Gentoo pour vérifier.
[^] # Re: Quelques corrections assez importantes
Posté par Mathieu Pillard (site web personnel) . Évalué à 2.
- pas forcement en stable, sauf maj de sécu.
- ce n'est pas le kernel "officiel" et par défaut, simplement un parmis ceux que on te propose
Je sais que ca va te surprendre, mais oui, gentoo fait un travail de packaging et laisse le temps de tester.
(NB pour le commentaire a coté: c'est ACCEPT_KEYWORDS.)
[^] # Re: Quelques corrections assez importantes
Posté par Cali_Mero . Évalué à 8.
Pour les anglophobes qui ne tiltent pas, il s'agit de User-Mode Linux (UML), le patch de virtualisation de système (un noyau maître permettant de faire tourner plusieurs noyaux fils totalement isolés les uns des autres, partageant les ressources de la machine hôte), qui est une alternative à VServer.
http://www.usermodelinux.org/(...)
# Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Possibilité d'inclure DSDT perso
Posté par M . Évalué à 2.
Maintenant il serait capable de le recuperer dans /boot, ca ma l'air effectivement mieux.
T'as un lien sur cette nouvelle fonctionalite (je n'ai rien trouve dans Documentation/ ) ?
[^] # Re: Possibilité d'inclure DSDT perso
Posté par M . Évalué à 2.
[^] # Re: Possibilité d'inclure DSDT perso
Posté par Mathieu Pillard (site web personnel) . Évalué à 2.
Certaines distros incluent ca de base, la page mentionne suse et mandrake, quelqu'un peut confirmer ou en ajouter d'autres ?
[^] # Re: Possibilité d'inclure DSDT perso
Posté par Raphaël G. (site web personnel) . Évalué à 1.
# alsa ?
Posté par ploum (site web personnel, Mastodon) . Évalué à 2.
Sinon, j'attend toujours que ma carte graphique (une geforce2MX) supporte le frame-buffer :-(
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: alsa ?
Posté par Oni . Évalué à 2.
Sinon moi j'ai aucun problème grave avec le chip audio Nforce 2 et Alsa...
[^] # Re: alsa ?
Posté par M . Évalué à 2.
Ne fait pas comme moi un script dans /etc/init.d/ qui charge les soundfont midi, sinon vous riquez d'attendre longtemps ;)
[^] # Re: alsa ?
Posté par Colin Leroy (site web personnel) . Évalué à 3.
man vi, man gcc :-)
Sérieusement, c'est un projet de quelques semaines pour un non-professionnel de la programmation noyau. La plupart du code est "facile" à écrire en prenant exemple sur un autre driver framebuffer et en dégottant les trucs spécifiques dans le driver nv de Xorg... (d'où rivafb vient tout droit, apparemment - d'après les commentaires dans drivers/video/riva/*c)
[^] # Re: alsa ?
Posté par newbix . Évalué à 1.
Je vais essayer le 2.6.9 ce soir si j'ai le temps.
# Il n'y a pas que Alsa :-)
Posté par 007 . Évalué à 8.
- a lot of NTFS updates
- block I/O barrier support ( http://lwn.net/Articles/103183/(...) )
- patch allowing unprivileged process to lock small amounts of memory in RAM
http://lwn.net/Articles/96587/(...)
Rik van Riel and Arjan van de Ven have put together a new patch which allows normal users to lock memory into physical RAM without root privilege. The RLIMIT_MEMLOCK resource limit puts an upper bound on how much memory can be locked, and its default value is zero. By raising this limit, system administrators can enable users to lock a single page (useful for cryptographic applications which do not want to see passphrases and clear text swapped to disk) or larger amounts (for CD writing tasks, for example).
- new USB storage driver
- cluster-wide file locking infrastructure
- completely out-of-line spinlocks ( http://lwn.net/Articles/97537/(...) )
- AMD dual-core support
- support for the POSIX waitid() system call
- KProbes ( http://www-124.ibm.com/linux/projects/kprobes/(...) )
- USB "on the go" support
- the "flex mmap" user-space memory layout
- m32r architecture support ( http://www.linux-m32r.org/(...) )
- a bunch of latency-reduction work (Ingo Molnar)
- Nouvelle adressage mémoire : http://lwn.net/Articles/91829/(...)
- new I/O memory access mechanism ( http://lwn.net/Articles/102232/(...) )
- and lots of fixes :-)
Après le Kernel coding style, il y a maintenant le "Linux kernel management style" :
http://lwn.net/Articles/105375/(...)
Merci à lwn.
# Corruption avec gcc 3
Posté par j . Évalué à 3.
http://00f.net/blogs/index.php/2004/10/20/register_corruption_with_(...)
[^] # Re: Corruption avec gcc 3
Posté par maher b . Évalué à 2.
"Heh. Clearly there's a gcc bug.. What compiler version?
I've got gcc-3.2 and gcc-3.3, and neither seems to have any trouble, but
hey, I'm cursed by having fairly up-to-date systems.
That said, I know what's up, but it would be good to know what compilers
have this problem.."
http://kerneltrap.org/node/view/4026(...)
histoire aussi de comparer le nombre des différents warnings entre les versions de la branche 2.6 avec gcc 3.2.2 vous pouvez jetter un coup d'oeil sur ce lien:
http://developer.osdl.org/cherry/compile/(...)
# Patch grsec ou equivalent
Posté par FRLinux (site web personnel) . Évalué à 2.
Merci,
Steph
[^] # Re: Patch grsec ou equivalent
Posté par j . Évalué à 0.
# Graveur SCSI
Posté par Vincent Ternisien . Évalué à 1.
Je doit utiliser, en root, un console avec les programmes mkisofs/cdrecord et encore, ca ne passe pas a chaque fois.
J'ai finit par arreter le _gravationnage_ sous Linux et je doit repasser sous Window$ pour ne pas casser tous mes cdr(w).
Quelqu'un a t'il des informations les graveurs SCSI avec le 2.6.9 ?
[^] # Re: Graveur SCSI
Posté par 007 . Évalué à 2.
Normal :
http://lwn.net/Articles/98379/(...)
Pour le reste, j'ai entendu parlé de quelques problèmes qui doivent être corrigés.
Avec la dernière FC3T3 je peux graver sans être root et sans suid pour cdrecord (graveur IDE).
> avec une Fedora 2
Il y aura _peut-être_ une mise à jour pour FC2 après la sortie de FC3.
# Kernel 2.6.9 ? Yes ! Mais ...
Posté par Gaeldîr . Évalué à 0.
MAIS il y a un truc qui me choque : ils ont viré le supermount !
Comment je fais moi, maintenant, avec ma clef USB, sans supermount, sachant qu'avec submount, si je lance submountd, j'ai doit au message "submountd: 1 argument received, 6 needed." ?
Comment je fais, hm, pour utiliser ma clef USB avec le kernel 2.6.9 ?
Ils se seraient pas un peu ch*é dessus, Linus et les autres, en enlevant le supermount du kernel 2.6.9 ? :)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.