Reprise du message précédent :
je dis ça, je dis rien mais tous les point releases
sont dus à la prochaine sortie de la Suse
donc vous savez ce qui vous reste à ne pas faire  

slt tlm, je suis tjs avec un 2.6.15-8 ( celui de debian testing ) et je rencontre un probleme au niveau du FS ext3. quelqu'un d'autre a t'il constaté un probleme de cette nature avec les 2.6.15 ( je rencontre ce probleme egalement avec un kernel 2.6.15-cks7 recompilé par mes soint ...)

Quel genre de problème?

bas en fait j'ai mon /boot ( /dev/hda1 ) qui a commence a merder y a quelque jours
avec le dossier grub qui etait devenu un fichier grub et plus de place sur la partcohe ( alors qui il y en restait normalement ) ou des taille de fichier completement fausse.... j'ai fait tout les test du constructeur sur mon dur : il est nickel tout passe, j'ai fait un formatage bas niveau. j'avais ghoster avec partimage / et /home je les ai remis , j'ai manuelement /boot qui est de nouveau aussi merdique qu'avant .. cepandant ces probleme ne semble pas surevenir quand je boot avec un live cd ou avec un autre dur sur lequel grub et un 2.6.12  
c'est pourquoi je pense au kernel...
j'ai fait un topic sur mon probleme..

non, j'ai un 2.6.15-ck5 compilé maison depuis le 7 mars, avec 3 dur en ext3 et pas de probleme
désolé  

le pire c'est que j'ai le meme kernel au boulot qu'a la maison et ca me le fait pas au boulot....

Vu ce que tu indiques, moi je pense que c'est ton disque dur qui est moisi quelque part    
 
Un jugement abitraire de ma part ? Non que neni : avec un LiveCD ça passe (n'utilise pas le disque dur), avec un autre disque dur ça passe, le noyau avec qui ça foire fonctionne ailleurs... cherche plus ya un truc qui n'est pas clair avec ton disque dur.
 
Le fait que les diagnostiques n'indiquent rien et que tu as fait un formatage de bas niveau ne veulent pas forcément dire que ton disque dur n'a rien. J'ai eu il n'y a pas si longtemps le même genre de problème avec un disque SCSI : corruption de fs, j'ai fait un check + un formatage de bas niveau avec les utilaires SCSI intégrés au BIOS de la carte contrôleur et rien d'anormal de décelé ; quelques jours après le disque était mort (corruptions à répétition avant de finir par être inutilisable).

et ben apres avoir utilisé un ghost d'il y a 3 mois, gardé mon /home, remis a jour et reinstallé mon kernel perso :  
c'est repartie comme avant plus un seul problème.... je pense donc a un packet defectueux mais lequel alros ?

2.6.16.12 out  

Comment ca se fait qu'il y est autant de release qui sortent aussi rapidement ?
Ils sortent des version foireuses alors ils doivent sortir des versions corrigées ou ils sont super actifs de la mort qui tue ?

 
c'est pareil comme avant, mais là il sorte les versions 2.6.xx.yy officiellement au lieu que les patchs se promene dans les mm, les ck, etc et que ca soit dispo officiellement seulement à la version 2.6.xx+1

2.6.13->2.6.15 on a pas eu le droit à tellement de versions (environ la moitié) et on n'est pas encore en 2.6.17, on peut comprendre qu'il se poser des questions là.

J'ai donné la réponse à vos questions + haut    

fais chier Linus à utiliser Suse.

il n'est plus sur RH ?

chez lui c'est Suse sur Mac, aui boulot RH sans doute.

ok je ne savais pas, le RPM c'est son dada.

2.6.16.13 dispo .

C'est absolument nimporte quoi
 
Heureusement que gnu/kfreebsd commence a marcher

ca tourne bien cela ? les paquets debian habituels sont compatibles ou bien ce sont des repos différents ? et dans le dernier cas quel intéret par rapport à freebsd tout court ?
 
Merci

Je confirme.  
Je n'aime pas du tout leur nouvelle façon de procéder...

Bah disons qu'il n'est absolument pas nécéssaire de mettre à jour les versions mineures si je me rappelle bien. Ce sont juste des corrections de bugs (importants certes) mais qui ne dérangent que ceux qui en sont victimes

[HS]
C'est presque entièrement fonctionnel (le système de base tourne parfaitement) mais en terme de perfs, honnêtement, ça reste un peu à la traîne comparé au noyau GNU/Linux ; cela dit c'est spécifique au noyau FreeBSD, le fait que Debian intervient là-dedans n'a rien à voir à ce niveau. Il est prévu pour Sarge+1 (donc Etch   ) de voir apparaître une release et un support officiel.
 
Il y a des dépôts différents et spécifiques pour ce portage :
   ---> http://archive.gnuab.org/debian-repos
 
D'autres infos ici : http://www.debian.org/ports/kfreebsd-gnu/
 
 
Quel intérêt par rapport à freebsd tout court ? les avantages typiquement inhérent à l'utilisation d'une Debian, présence des outils d'administration qui font le succès de Debian (Debconf, APT, etc.), qualité des paquets fournis, robustesse, etc, etc.
[/HS]

[HS]Merci[/HS]

The latest stable version of the Linux kernel is:   2.6.16.14
 
avec un mini changelog ...

 
Dont t'aurais pu mettre l'url ici. Ca aurait plus pratique pour tout ceux qui apprennent la nouvelle ici et qui veulent justement lire le changelog.

Et pas toi?
 

à la demande générale http://www.kernel.org/pub/linux/ke [...] -2.6.16.14
petite feature, pour ceux qui ont la flemme d'aller sur le site, le mini changelog:
 

 
++

 
Ouais pour le coup, j'aurais pu le faire désolé   . (Faut dire que je l'ai pas encore regardé).
 
Mais tu remarqueras que pour les dernières modifications du kernel, c'est toujours le même message sans lien. C'est simplement un appel pour les prochaines annonces.
 
Edit: Merci noritaka  

et de 15 http://www.kernel.org/pub/linux/ke [...] -2.6.16.15  

Ca rale beaucoup, sur ce topic et ailleurs, sur le mode de developpement du kernel, et sur l'instabilite des versions stables.
Moi au contraire le mode de dev actuel me plait bien, mais, handicape du clavier des ma plus tendre enfance, je ne savais pas comment l'exprimer.
 
Et pis je suis tombe sur ce post sur slashdot qui resume parfaitement mon point de vue
 
 
Avec les branches de dev stable / instable, le cycle de dev de la version instable etait vraiment trop long, et les changements par rapport a la version stable radicaux.
Comme les nouveaux drivers allaient seulement dans la version de dev (en attendant un eventuel backport), il fallait parfois installer un kernel instable pour que son materiel soit supporte. Mais c'etait toujours bien complique (modifs utilitaires userland et des options de base du kernel) et parfois dangereux.
Les nouvelles versions stables 2.x.0 mettaient aussi un bon paquet de temps a se stabiliser tellement les changements etaient importants et les tests par la communaute insuffisants pendant le cycle de la version instable.
 
Alors geler le 2.6 pendant 3-4 mois pour regler les problemes de stabilite que perso je n'ai pas recontres, pourquoi pas  
Mais revenir aux 2 branches separees et avoir droit au 2.8 en decembre 2009 ..... NON    
 

 
Ca, c'est de l'argument pertinent    

2.6.16.16 :

mais qu'est-ce qu'ils ont avec le 2.6.16 là ?
le dhcp marche une fois sur 2 et pas moyen que nxtvepg puisse utiliser son vbi slicer...

++      
 
De toute façon, même pour ceux qui trouvent la branche 2.6.x.x trop instable en l'état (donc tel que fournie par kernel.org), pour régler cette problématique rappelons qu'il existe spécialement les noyaux patchés fournis par les différentes distributions (ce sont d'ailleurs les versions recommandées par Linus depuis quelque temps pour les utilisateurs ou développeurs avant tout soucieux d'une certaine stabilité).

 
Alors là, je trouve çà carrement à chier. C'est pas au paquetageur de réparer les merdes de Linus et de sa bande.  
Dire moi je fais joujou à faire du code dégueulasse et experimental, et vous vous le débugguer, c'est n'importe quoi. La seule véritable raison d'installer les noyaux des distribs, c'est pour garder l'harmonie de la distrib et pas avoir des programmes qui viennent d'on ne sait où (orthographe ?).
 
Maintenant, je connais pas énormement l'architecture du code du noyau, mais s'il faut passer par un cycle 2.8 très long pour revenir à qqch de plus propre, alors je vois pas où est le problème. Peut-être que pour vous, ne pas installer de kernel pendant plusieurs mois, çà vous plait pas mais mettez vous à la place d'un développeur du noyau qui s'arrache les cheveux parce que c'est mal foutu. Peut-être que pour lui, un 2.8 serait le paradis.

 
C'est aussi un peu pour plaire aux distributions que ce mode de fonctionnement est entré en vigueur. Avant, les distros étaient obligé de backporter des centaines de patchs de la version instable pour pouvoir par exemple supporter du nouveau matériel.

 
Certes.
 
En même temps il y a une prise de conscience de la perte de la qualité du code du noyau, et je ne vois absolument pas en quoi cela devrait remettre en cause le développement actuel. Je le trouve d'ailleurs bien plus cohérent et adapté à ce genre de projet.
 
Quitte à retarder l'avancement des fonctionnalités, c'est tout a leur honneur de venir dire que les efforts vont se concentrer sur de la résolution de bugs. D'autres boites ne menent pas cette politique depuis belle lurette...

Bonsoir,

 
bof :
 
$ gzip -d linux-2.6_2.6.16-12.diff.gz
$ grep patches/ linux-2.6_2.6.16-12.diff | grep -v '\-\-\-' | wc -l
91
 
-10 entrées dans le changelog que je liste avec grep sans le faire exprès. Ca fait quand même 80.
 
D'ailleurs, c'est quoi ce que vous appelez la version instable ? Car normalement, ce sont les versions avec le deuxième chiffre impair. Et elle n'était utile que lorsque Linus bossait dessus. Dès qu'on avait la version x.y+1.0 (considérée comme stable), la branche x.y.z (instable) devenait pratiquement obsolète. Donc, je vois mal pourquoi il fallait backporter depuis cette version.

 
je te parle du mode de fonctionnement pré-2.6...
 
Quand Suse backportait plus d'un millier (1000) de patch de la branche 2.5 pour avoir un noyau 2.4 à son goût, c'est à dire supportant du matériel récent surtout.

 
Je suis bien trop mal placé pour ouvrir ma gueule sur le schéma de developpement du noyau. Mais aucune des 2 façons de développer me parait meilleure pour un projet comme ca. Il faut noter que les cycles instables ne servaient pas à la base à ajouter des nouvelles fonctionnalités mais à repenser le noyau ce qui pouvait être nécessaire même au prix de l'incompatibilité.  
 
D'un autre coté, la nouvelle façon, c'est sur le papier : free-style pendant 2 semaines puis on debuggue. A mon avis, ca peut vite partir en vrille aussi ce truc-là. Et c'est peut-être ce qui s'est passé. Maintenant, je ne sais pas comment Linus s'y prend, donc je peux pas vraiment avoir de jugement.
 
Evidemment, s'arrêter pour corriger des bugs est une sage décision et comme toi je l'approuve. C'est dommage quand même d'en arriver là.