Reprise du message précédent :
# uname -a
Linux pak 2.6.3-rc1 #1 Sat Feb 7 13:01:54 CET 2004 i686 GNU/Linux
 
alsa 1.0.2c
et mon pb de souris semble être réglé d'après la lkml
 
par contre le probleme de réactivité à pleine charge à l'air toujours aussi problèmatique

 
   
c'est quoi ces conneries, je fais rien avec mon pc là !  

hé&hé
Moi parfois jai des xterm vide qui me prennent 20% d'utilisation et meme mon top qui passe a 99% =)
Jsais pas skoi le probleme mais c'est fort
 
Par contre le nouvel ALSA, j'aime

le patch -mm1 sur le 2.6.2 a qqs problèmes avec les volumes LVM.
Lors d'un redémarrage il n'arrive pas à démonter les volumes correctement  

 
C'est clair, la nouvelle recette gateau au chocolat est trop bonne  

top - 13:56:32 up  1:59,  3 users,  load average: 2.27, 2.19, 2.11
 

 
bon, pas la peine de faire un report de bug, j'imagine qu'ils s'en sont aperçu  

 
J'aurais pas cru ca de toi.. je pensais que le choco c'etait pas ton gout preféré

En fait, j'ai pas à me plaindre, je fais un gros emerge et le système est bien réactif

Moi pas..
Genre quand je fais le tar -jxf linux-2.6.2.tar.bz2
Ca provoque des petits freeze du systeme meme apres avoir fini de le decompresser (pendant quelques secondes)
Bizarre..
 
edit: Ouais le reste du temps c'est nickel (fluxbox inside )

Même, deux bk avant une RC c'est pas vraiment suffisant. Je pense que le 2.6 devrait avoir une sortie toutes les 3 semaines minimum, et vu comme c'est parti on est sur des release toutes les 1-2 semaines, ca fait pas très serieux ...

+1 et le son grésille un peu d'ailleur pendant ces petit lags...
Mais sinon le reste du temps c hyper réactif (xfce4 powered )

 
pour moi aussi le reste du temps c'est nickel (kde inside )

On propose à Linus de te mettre comme maintaineur du 2.6 à la place de ce débile d'Andrew Morton qui est meme pas foutu d'identifier ses initiales?

 
bof, de toute façon quel est le but de sortir des bk et des rc ?
ils continuent à foutre plein de nouveaux trucs, règlent plein de bug
quand il y a une release, il y a encore des bug
moi j'ai l'impression que s'ils foutent des préfixes n'importent comme, c'est surtout pour insiter les gens à tester
je ne vois pas d'autres utiliter à ces préfixes qui sont utiliser un peu comme ça "arrange"
pourquoi pas avoir des pre et des test aussi
 
sinon si on considère que les bk sont là pour ajouter des features, et les rc pour régler les pb amener par ces nouvelles features, on peut considérer que c'est ce qui se passe, étant donné que les 2 rc du 2.6.2 ont amené plein de changement de code
peut-être que les bk qui vont venir ne vont servir qu'à régler les nouveaux pb, et dans ce cas la (certaine) "logique" qu'ils tentent de suivre serait à peu près respecter
c'est vrai que les rc sont passé vite mais il ne faut pas oublier que les patch inclu dans ces rc existent depuis longtemps déjà, qu'ils sont déjà testés par ceux qui utilise les branchent cvs (comme pour alsa par exemple) ainsi que par les utilisateurs des patches mm  (alsa 1.0.1 est dans les mm depuis un moment maintenant et il fait juste sont apparition maintenant)
 
donc si on considère que la logique des bk-rc-release est bonne, alors on peut dire que les devels (enfin linus et andrew) respectent à peu près cette logique
 
perso étant donné que le kernel est toujours en évolution (surtout à ces débuts comme c'est le cas maintenant avec le 2.6), je trouve cette logique un peu foireuse, mais ça vaut sans doute les autres solutions

Une rc deux jours après une release, à mon avis ca fait très court ... même si ca ne veut virtuellement rien dire.

Une bk c'est un snapshot, une proposition de code qui doit être testée et validée dans un stade beta et non dans un stade RC.

Je pense justement que les kernels Linux mériteraient un peu plus de test avant de sortir en release officielle, justement en stade RC. Si on regarde le développement des séries 2.4, une nouvelle release est vraiment testée et approuvée avant d'être publiée, dans le 2.6 on a l'impression qu'on inclu sans trop se poser de question des patches qui peuvent avoir une incidence néfaste sur le fonctionnement global du kernel (cf les régressions dans le preempt ...). Personellement j'ai une impression de précipitation, et je pense que pour encourager l'adoption du 2.6 comme kernel "standard" on devrait s'attacher à sa stabilité, ce qui implique une phase de test plus aprofondie.
 
Les devels ont sans doute raison de faire évoluer le kernel très rapidement puisqu'il est en début de vie, mais il ne faudrait pas voir systématiquement les utilisateurs standard comme des beta-testeurs.

AHMA c'est pas trop mal ce qu'ils font
 
l'utilisateur lambda ne compile pas son kernel, après c'est le boulot des distributions de choisir telle ou telle version
 
personnellement je sais bien que le 2.6 évolue vite pour me pousser à tester et à faire des rapports de bugs (que je ne fais pas car chez moi tout marche bien )
si je suis pas content je peux repasser à une version précédente ou au 2.4.24
 
concernant le domaine "pro", les distros font correctement leur boulot, tu trouveras pas le 2.6 dans RedHat avant un bout de temps, parcontre ils ont intégré le NPTL depuis un moment dans leur 2.4 car ils pensent sûrement que c'est bénéfique

C'est pas faux ... on devra sans doute leur laisser un peu de temps avant que la frénésie des versions "unitaires" se calme et que le 2.6 devienne "stable", mais la tendance actuelle n'encourage clairement pas à l'adoption massive du 2.6.

faut voir aussi que le 2.4 avait un rythme de sortie éffréné aussi jusqu'à la version 2.4.18 et c'est seulement après que ça s'est calmé, soit un peu plus d'un an après sa sortie.

ouaip.. Les utilisateurs généralement n'installe pas un linux avant son 10ieme patch.. Ils poussent a la migration alors?
Les 10premieres release ne seraient-elle en fait que des betas?

bon je tante une compilation du 2.6.2 patché mm en esépérant que sa marche avec mon nforce 2 :x
 
c'est quoi qui faut rajouter dans le module.conf au faite ?

c'est moi ou le kernel officiel a alsa en 0.97 tandis qu'avec les mm alsa est en 1.01?

Le 2.6.3-rc1 possède alsa 1.0.2c.

ok merci! le 2.6.3rc1 intégrant alsa 1.0.2, c'est peut-être la meilleure solution pour avoir alsa stable sans se casser la tête!

 
ratez
il y a des pend entier de code réécrit et ça a introduit de nouveau pb
en plus tu as un nforce2 toi si je ne me trompe ?
rappelle moi quand tu auras fini et que tu n'arrives pas à avoir de son sous quake ou enemy territory

tiens il m'est arrivé un truc bizarre avec ce 2.6.2 :
premier reboot dessus il scotch 10mn sur l'initialisation du socket unix : /tmp/.X11-unix  
Je reboot a la violente, reboot sur mon 2.6.1-mm4 (merci grub), la ca passe je supprome /tmp/.X11-unix.
Je reboot sur le 2.6.2 et la ca passe sans probleme ...
 
maintenant ce matin pour sur le 2.6.2 et la ca passe pas .. et galere ...
 
 
auriez vous une idee ?  
merci d avance

je comprends pas un truc sur la réactivité :
là je compile avec un nice de zero et tout va bien, les appli se lance un poil moins vite que d'habitude, mais pas trop de pb pour autant, la music saute pas (pourtant elle passe par arts de merde ), donc tout va bien
alors que dès que je fais un acces disque important, comme un déplacement de fichier, ou un rip de dvd avec tuxip qui pourtant met tous les process en nice 15 ou 19, ça chie dans la colle comme pas permi
je sais pas ce qu'ils ont foutu avec la gestion des io mais ça merde sec là
parait quand désactivant le preempt ça résoud le pb, faudrait que je vérifie mais ça serait un comble

Pour avoir du son sous q3 avec le 2.6.3-rc1 il suffit de regarder dans la console q3 et de voir qu'il faut donner les droit sur le fichier que pointe /dev/dsp
Perso c'est /dev/dsp0
Jai pas essayé d'enlever le PCM..
Bon Quake

Je crois avoir trouvé pourquoi j'avais ces freezes sous le 2.6.1 et 2.6.2
Mon disque dur /dev/hda n'est plus activé en DMA
root@glide: /etc/rc.d$ hdparm  -d /dev/hda
 
/dev/hda:
 using_dma    =  0 (off)
 
edit: rc1-bk1 out
edit3: autant pour moi, j'ai oublié d'activer une option dans le noyau..

man hdparm

Y'a pas de changelog pour le rc1-bk1 ?

Si, cliques sur le v et mattes les changements..

C'est pas un changelog, juste un diff sur les fichiers incriminés ; ça me dit pas grand chose....
 
cela dit il me semble que les bk des rc n'ont pas de changelog....

Bah, ca en dit deja pas mal..
C'est lourd a lire mais bon

 
oui je trouve qu'il y a un probleme de ce coté là dans les dernières séries...

 
autant je veux bien admettre l'utilité des rc ou bk, autant je comprends pas l'interet des bk de rc  

Ba les bk de rc deviennent des rc++ au bout d'un moment il me semble..

T'as quels droits sur /tmp/.X11-unix ?