- Cette version 2.6.23 a eu un cycle de développement assez long puisqu'il y a eu neuf versions de test. La version RC-1, première des release candidate, a été annoncée par Linus le 22 juillet soit quinze jours après l'ouverture de la fenêtre des modifications.
(traduction libre):Il y a des *tonnes* de changement (..) beaucoup de mises à jour d'architectures (pour toutes - x86[-64], arm, alpha, mips, ia64, powerpc, s390, sh, sparc), beaucoup de mise à jour de pilotes (encore une fois pour tous les sous-systèmes - usb, net, dvb, ide, sata, scsi, isdn, infiniband, firewire, i2c, etc.).
Les systèmes de fichiers, la mémoire virtuelle, le réseau, ACPI, tout est là. Et la virtualisation est présente partout (kvm, lguest, Xen). Une nouveauté notable est l'inclusion de l'ordonnanceur CFS, et aussi l'infrastructure de pilote UIO qui peut intéresser quelques personnes.
Oh et personnellement j'aime le fait que "sendfile" soit totalement éliminé en interne et que le noyau fasse tout ce travail avec splice à la place. Bon débarras, même si évidemment nous allons devoir supporter la vieille interface en espace utilisateur pour un long moment.
- Comme d'habitude Linus a ensuite un peu grogné en constatant que les modifications soumises pour la RC-2 étaient plus invasives que prévu et ne se limitaient pas aux corrections de bugs.
(traduction libre):Donc j'ai essayé de faire respecter la fenêtre des modifications et j'ai dit non à quelques demandes d'inclusion, mais cette nouvelle mode du "RC-2 est le nouveau RC-1" est une vraie plaie. En plus non seulement la seconde release candidate est en retard mais en plus elle est plus grosse que ce qu'elle devrait être. Bon, c'est comme ça.
- Le rappel à l'ordre a été entendu et le cycle a été plus calme par la suite. Linus l'a reconnu dans son annonce de la RC-3 le 12 août.
(traduction libre):Soit les gens se calment vraiment et se rendent compte que nous sommes dans la phase de stabilisation, soit c'est juste que c'est le milieu du mois d'août et la plupart des gens, au moins en Europe, sont en vacances. Quoi qu'il en soit, la RC-3 est sortie et n'a pas les tonnes de changement qu'avait la RC-2.
- La version RC-4 (nom de code "Belette rose péteuse") est sortie deux semaines après la précédente du fait d'un oubli de Linus. (traduction libre):
Le résultat c'est que RC-4 est un peu plus grosse qu'elle devrait être, mais j'ai bon espoir que tout baigne et nous avons corrigé la plupart des régressions.
- De moins en moins de problèmes étant rapportés, le flot des correctifs s'est ralenti par la suite pour la RC-5.
(traduction libre):Je me prépare à partir pour le Kernel Summit (comme probablement beaucoup d'autres codeurs du noyau) et, à part ça, il y a une version RC-5 qui est sortie. Donc amusez-vous bien, testez-bien, et attendez-vous à une semaine tranquille.
- De retour du sommet Linus a annoncé le 10 septembre la sortie de la RC-6 qui corrige de nombreuses régressions. La saga s'est ensuite poursuivie avec la RC-7 et la RC-8 qui corrigent d'ultimes bugs.
(traduction libre):Ok je pense que je suis proche de sortir le 2.6.23 et je suis content à propos de son état. Naturellement, ce sentiment de contentement est habituellement suivi immédiatement par l'irruption de nouveaux problèmes soulevés par certaines personnes désagréables...mais je vais juste ignorer cela et apprécier le sentiment aussi passager puisset-t-il être.
- Linus avait raison d'être prudent car il a finalement dû sortir une RC-9 (ce qui est très inhabituel dans un cycle normal). Constatant un grand nombre de corrections de bugs il a préféré ne prendre aucun risque et sortir cette ultime version de test.
(traduction libre):Je ne pourrai vraiment pas supporter le fait d'annoncer la sortie du 2.6.23 en prenant le risque d'un bug idiot.
- Le noyau 2.6.23 incorpore l'ordonnanceur CFS créé par Ingo Molnar (et incorporant des idées de Kon Colivas). CFS remplace le précédent ordonnanceur des processus qui a bien servi puisqu'il était apparu dans le noyau 2.5.2-pre10 en janvier 2002. Ce dernier, bien que d'excellente qualité, était handicapé par l'incorporation d'un code spécifique devant estimer l'interactivité des processus. Cet estimateur (basé sur des statistiques donc pouvant se tromper) posait plus de problèmes qu'il n'en résolvait et, grâce à Kon Colivas, le nouvel ordonnanceur peut se passer de tout ce code spécifique. Maintenant tous les processus sont parfaitement égaux ce qui explique le nom de Completely Fair Scheduler ou "Ordonnanceur complètement équitable". Le design proposé par Ingo Molnar incorpore également une idée très novatrice qui est l'utilisation d'arbres de recherche triés en fonction du temps au lieu de l'ancien système des deux queues de tâches qui alternaient entre elles (en posant des problèmes lors de la transition). D'après les tests cet ordonnanceur tout neuf est beaucoup plus robuste que l'ancien (il n'est plus vulnérable aux "attaques" du type fiftyp.c, thud.c, chew.c, ring-test.c, massive_intr.c) et il améliore sensiblement l'interactivité. Le seul problème qui reste est qu'actuellement CFS n'incorpore pas encore la fonction d'ordonnancement de groupe. Jonathan Corbet, du site LWN, explique parfaitement de quoi il est question. (traduction libre):
Si cinquante processus essayent de tourner sur une machine alors CFS s'assurera que chacun aura 2% du temps de processeur. Il se peut néanmoins que l'un de ces processus soit le serveur X de l'utilisateur Alice alors que les quarante-neuf autres sont une compilation massive du noyau lancée par l'utilisateur Karl (...) Il est raisonnable de dire que ces 49 processus de compilation devraient être traités en tant que groupe et partagés avec le serveur X d'Alice. En d'autres termes le serveur X devrait avoir 50% du temps de processeur (si il en a besoin) tandis que tous les processus de Karl devraient se partager les 50% qui restent.
Cette fonction d'ordonnancement de groupe est prête à être incluse et si elle n'a pas été incorporée tout de suite, c'est qu'elle dépend de l'existence de "containers" au sein du noyau qui permettent d'isoler les processus de façon efficace. Ce devrait être le cas dès le prochain noyau 2.6.24.
- L'appel système fallocate() a été implémenté dans ce nouveau noyau et, à l'heure actuelle, les systèmes de fichier ext4 et ocfs2 l'utilisent. Cet appel système permet de pré-allouer de l'espace sur le disque lors de l'enregistrement d'un fichier. Cela évite, en cas d'augmentation de taille du fichier dans le futur, de le fragmenter sur tout le disque dur puisqu'on peut utiliser l'espace contigu réservé dès le début. On améliore ainsi très largement les temps d'accès lors de la lecture. De plus, avantage annexe, le fait de réserver par avance de l'espace permet d'avoir l'assurance que le fichier pourra croitre, même si le système de fichier est plein. La pré-allocation d'espace est déjà disponible dans la bibliothèque glibc au travers de l'appel standardisé posix_fallocate(). Cependant celui-ci est extrêmement lent puisqu'il écrit des zéros dans tous les blocs de l'espace réservé. Le nouvel appel système fallocate() étant bien plus efficace, la glibc va être modifiée. Si un programme utilise l'appel posix_fallocate() c'est le nouveau fallocate() qui sera utilisé de façon transparente avec, bien entendu, un recours à l'ancien code seulement si le système de fichier ne supporte pas le nouvel appel.
- Le patch implémentant la fonction de lecture spéculative à la demande (On-demand readahead) a été incorporé. La lecture spéculative permet le chargement à l'avance dans la mémoire du contenu d'un fichier que le noyau est en train de lire. L'idée est de pouvoir fournir les données plus rapidement aux applications : par exemple si un fichier vidéo est en train d'être lu, il est raisonnable de précharger à l'avance la suite du fichier afin de diminuer les accès au disque. Actuellement, la logique déclenchant la lecture spéculative est très simple mais elle permet déjà une augmentation des performances comprise entre 0% et 8%. Maintenant que la fonction basique fait partie du noyau Linux, des améliorations futures sont à prévoir (plusieurs patchs sont déjà prêts) pour lancer la lecture spéculative de façon encore plus précise avec des critères plus fins.
- Une partie de la technologie de virtualisation Xen fait son entrée dans le noyau Linux 2.6.23. Bien qu'étant intégrée en tant que patch dans plusieurs noyaux de distributions, Xen ne faisait jusqu'à présent pas partie du noyau officiel (mainline). Maintenant il est possible de démarrer au sein d'un environnement paravirtualisé par dessus l'hyperviseur Xen (c'est donc juste le support du mode Guest qui fait son entrée). Le reste n'est pas considéré comme répondant pour l'instant aux standards de Linux et reste donc à l'extérieur.
Aux cotés de Xen, une autre solution est intégrée dans le noyau : lguest. Cet outil a été écrit par Rusty Russell qui trouvait les autres virtualiseurs beaucoup trop complexes. C'est donc une tentative de créer un virtualiseur le plus simple et le plus propre possible. Avec juste 6000 lignes de code le but est atteint et l'intégration dans la branche principale du noyau va permettre d'avoir une solution de virtualisation ultra-basique pour attirer de nouveaux contributeurs désirant s'initier à ce genre d'outil et faire toutes sortes d'expérimentations techniques.
Comme le virtualiseur déjà présent, KVM (qui peut maintenant accueillir des machines multiprocesseurs en mode Guest), les deux nouveaux entrants sont basés sur l'infrastructure commune d'abstraction paravirt_ops.
- L'environnement de support des pilotes en espace utilisateur UIO a été intégré au noyau. Il permet de créer des pilotes très simples qui n'ont pas vocation à fonctionner en espace noyau (au niveau noyau il ne reste plus qu'une toute petite couche qui s'occupe d'enregistrer les pilotes et de gérer les interruptions). Bien entendu UIO est un environnement qui ne permet pas de profiter de toute les fonctions du noyau puisque seul le mode caractère est supporté (pas de mode bloc ou de réseau) et pas d'accès direct à la mémoire. En dépit de ces limitations il peut être intéressant d'utiliser cette nouvelle infrastructure. Ainsi, selon Thomas Gleixner, le nouvel outil lui a permis de convertir un pilote noyau en pilote UIO avec pour résultat une grande simplification du code. On passe de 8539 lignes (5264 dans le kernel et 3275 en espace utilisateur) à 3126 lignes (156 dans le kernel et 2970 en espace utilisateur).
Bien entendu, le risque engendré par UIO est d'inciter des entreprises à proposer des pilotes non-GPL en espace utilisateur. Andrew Morton s'en est inquiété : «J'ai la vague impression qu'il serait préférable d'encourager les gens à mettre plus de pilotes sous GPL dans le noyau plutôt que de les encourager à faire des implémentation binaires en espace utilisateur qui en plus seront probablement plus lentes, moins fiables et non disponibles sur certaines architectures.» Il lui a été répondu qu'UIO était réservé à des pilotes simples, principalement pour le monde de l'embarqué et qu'il valait mieux qu'il y ait une infrastructure propre et standardisé plutôt qu'une multitude anarchiques de solutions incompatibles.
- Comme évoqué plus haut dans le mail de Linus à l'occasion de la RC-1 on notera que la très importante fonction sendfile() est maintenant exécutée en interne par l'appel système splice(). Celui-ci a été introduit dans le noyau 2.6.17 afin de permettre aux applications en espace utilisateur d'utiliser un buffer de données (en fait un pipe) en espace noyau. Le gros avantage de splice() est qu'il n'y a plus de copies de données et pas d'allocation de mémoire virtuelle pour l'application en espace utilisateur. C'est donc un mécanisme très efficient et générique et Linus, dans un mail d'avril 2006, annonçait déjà le remplacement de sendfile() qui vient juste d'avoir lieu dans le noyau 2.6.23. (traduction libre):
Splice() est vraiment un concept tellement puissant qu'avoir sendfile() n'a plus vraiment de sens à l'exception qu'en tant qu'ancienne couche de compatibilité autour du bien plus puissant splice().
- Bien entendu, de nombreuses autres nouveautés sont présentes et un grand nombre de pilotes font leur entrée dans cette version 2.6.23 du noyau. On peut citer en vrac le passage de SLUB (introduit dans le noyau précédent) comme allocateur de mémoire par défaut, le support complet de la carte son de la Playstation 3 ou du gamepad de la Xbox360, L'inclusion du patch anti-fragmentation de la mémoire vive ou des premiers pilotes utilisant la nouvelle pile Wi-Fi mac80211, la réécriture complète du code d'initialisation de l'architecture x86...etc etc.
Comme d'habitude un résumé très complet de toutes ces nouveautés est disponible sur le site Kernel Newbies qui fait un travail extraordinaire pour centraliser tous les changements. Le site LWN propose également une analyse des contributions au noyau 2.6.23. L'employeur le plus important est Red Hat et le développeur ayant soumis le plus de patchs est Ingo Molnar.
Du coté des nouveautés prévues pour les prochaines versions, il faut tout d'abord noter la naissance d'une page spécifique qui fait le point sur les futures évolutions : Les prévisions météorologiques du noyau. Cette page est maintenue par Jonathan Corbet, le rédacteur de Linux Weekly News, et elle est très riche et informative.
Comme évoqué plus haut, l'ordonnancement de groupe (ou group scheduling) est sur le point de venir compléter CFS. On peut également s'attendre à ce que la compartimentalisation du noyau se poursuive (pas seulement sur les processus mais sur toute les ressources globales).
L'outil de tracing de nouvelle génération, utrace, continue sa maturation et devrait faire son entrée en mainline dès le noyau 2.6.24. La gestion dynamique des interruptions va être étendue à l'architecture x86_64, un outil amélioré de profilage mémoire est également attendu ainsi que l'introduction de points de sondage statiques (static probe points) dans le noyau pour permettre le traçage des performances.
Du côté des systèmes de fichier, le travail continue avec l'introduction des timestamps précis à la nanoseconde pour le futur système de fichier Ext4 ainsi que pour GFS2.
Aller plus loin
- Les nouveautés de Linux 2.6.23 (27 clics)
- Le bilan des ajouts - Partie 1 (5 clics)
- Le bilan des ajouts - Partie 2 (7 clics)
- La liste des régressions connues (5 clics)
- Les futurs ajouts au noyau (4 clics)
- Les contributeurs du noyau 2.6.23 (3 clics)
# Re:
Posté par IsNotGood . Évalué à 8.
Reconnaissons que kernelnewbies fait un excellent travail aussi et les répercutions sont visibles.
> Le noyau 2.6.23 incorpore l'ordonnanceur CFS
> On peut citer en vrac le passage de SLUB
J'utilise "par hazard" l'ordonnanceur CFS et SLUB. J'ai une FC6 et la dernière mise à jour noyau (2.6.22.7) intégre CFS et SLUB.
D'un point de vu utilisateur qui n'a pas une utilisation très exigente, c'est un petit plus. La machine ne tourne pas plus vite mais répond un peu plus comme on s'y attend.
J'avais utilisé RSDL scheduler de Con Kolivas (avec Linux 2.6.20). C'était parfois un plus, parfois un moins. Généralement plus de plus que de moins.
CFS c'est presque que du plus.
> Maintenant tous les processus sont parfaitement égaux ce qui explique le nom de Completely Fair Scheduler ou "Ordonnanceur complètement équitable".
Je crois que ce n'est pas tout à fait vrai. CFS fait un traitement particulier pour les processus endormis (ils sont dans sleep(), etc...).
> L'employeur le plus important est Red Hat
Ce n'est peut-être pas vrai. Je crois que l'employeur le plus important est "inconnu" et après c'est Red Hat. Dans la catégorie employeur inconnu, il y a aussi ceux sans imployeur.
> le développeur ayant soumis le plus de patchs est Ingo Molnar.
Employé Red Hat de longue date. Il est sous le feu des projecteurs aujourd'hui mais ces contributions à Linux sont énormes et il travail sur Linux depuis de nombreuses années.
[^] # Re: Re:
Posté par GeneralZod . Évalué à 10.
J'étais très content de la -rc9 qui donne de bons résultats avec le patch PREEMPT_RT d'Ingo Molnar et Thomas Gleixner.
On se rapproche d'une véritable solution Linux Temps Réel sans co-noyau pour les applications dont les latences sont < 1ms. ça élargirait l'offre déjà riche des solutions Temps Réel libres avec Xenomai et RTAI.
Quant à UIO, il est destiné à un public très particulier notamment les cartes industrielles, souvent du matériel exotique. Les constructeurs souvent de petites boites n'ont pas les ressources pour développer un pilote selon les standards du noyau , encore moins de le maintenir. Avec UIO, on a un module noyau simpliste qui crée une entrée du type /dev/uioX auquel peut accéder un pilote en espace utilisateur.
Pour eux, le problème n'est pas au niveau de la licence mais de la qualité du code. Un pilote pourri en espace utilisateur n'a pas le même impact qu'en espace noyau. UIO fournit à ce public une interface stable, standardisée et saine toutefois limitée, ce qui de fait ne changera pas grand chose pour les périphériques "grand public" qui ont des besoins plus évolués.
PS: le kernel hacker c'est Con Kolivas (branche -ck) Kon c'est la peluche dans Bleach.
http://members.optusnet.com.au/ckolivas/kernel/
[^] # Re: Re:
Posté par patrick_g (site web personnel) . Évalué à 10.
Putain je fais à chaque fois la connerie !
Désolé. Je vais me le tatouer sur les doigts comme dans "La nuit du chasseur".
[^] # Re: Re:
Posté par plic . Évalué à 5.
La faculté de citer est un substitut commode à l'intelligence -- Somerset Maugham
[^] # Re: Re:
Posté par GeneralZod . Évalué à 2.
Soit dit entre-nous, la qualité de la dépêche compense largement ce petit écart. ;-)
[^] # Re: Re:
Posté par Crao . Évalué à 4.
Pour référence :
http://fr.wikipedia.org/wiki/Bleach_%28manga%29
http://fr.wikipedia.org/wiki/La_Nuit_du_chasseur
# Merci
Posté par eMerzh (site web personnel) . Évalué à 8.
Beau gros boulot comme à chaque fois de la part de patrick_g!
[^] # Re: Merci
Posté par JP Martin . Évalué à 2.
Enfin, cela fait du bien d'avoir des nouvelles fraiches sur le kernel.
Merci pour le temps pris.
Merci beaucoup et un grand bravo !
Un utilisateur linux
# Et l'avenir ?
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
[^] # Re: Et l'avenir ?
Posté par windu.2b . Évalué à 1.
Actuellement, rien de tel n'est envisagé loin de là (pour autant que je sache). Et puis créer une branche de dév entraine un ralentissement notable de l'avancement du noyau. Je pense que les dév du noyau préfèrent continuer ainsi, en publiant une nouvelle version toutes les 6-8 semaines plutôt que de lancer un chantier de 2 ans, qui diviserait les efforts (certains travailleraient sur le 2.6 d'autres sur le 2.7).
[^] # Re: Et l'avenir ?
Posté par Maclag . Évalué à 2.
Maintenant qu'ils font des évolutions "un peu plus osées" mais toujours pas-à-pas entre chaque version, il va falloir attendre qu'ils bloquent sur quelquechose qui nécessite de tout casser avant d'avoir un 2.8 ou un 3.0. (qui passeront ou pas par un 2.7 dans lequel ils pourront allégrement tout casser?)
Enfin, ce n'est que mon très humble avis.
[^] # Re: Et l'avenir ?
Posté par IsNotGood . Évalué à 7.
Je n'y crois pas.
Linux a changé de modèle de développement. Les anciennes branches de développement stables avaient de "petites" modifications entre version mineur. Avec Linux 2.6 ce n'est plus le cas (d'où le fait qu'il peut se passer plusieurs mois entre versions mineurs de Linux 2.6).
L'un des objectifs du nouveau modèle de développement (celui de Linux 2.6) est justement aussi d'éviter d'avoir une branche expérimentale en parallèle d'une branche stable durant de nombreux mois. Le modèle branche stable/expérimentale sucks pour un élément aussi compliqué qu'un noyau. Il disperse les énergies. La sortie d'un x.x.0 n'est jamais très brillante. Il faut attendre des mois de stabilisation. Les distributions "entreprise" font alors des backports des fonctionnalités les plus importantes sur l'ancienne branche stable au-lieu de bosser sur la dernière branche stable.
Dire que Linux 2.6 est une branche stable est un peu abuser. Linux 2.6.0 et linux 2.6.23 sont très différent. La branche 2.6 a été le lieu d'important développement. Je ne serais pas étonné qu'à interval de temps équivalent il y ait beaucoup plus de modifications dans Linux 2.6 que dans Linux 2.5.
Je connais et utilise Linux depuis le noyau 1.2. Le nouveau modèle de développement est pour moi incontestablement supérieur. Peut-être que ce nouveau modèle de développement n'était pas possible il y a quelques années.
L'histoire n'est pas écrite, il y aura peut-être un Linux 2.8 ou 3.0.
[^] # Re: Et l'avenir ?
Posté par Quzqo . Évalué à 5.
A contrario, j'ai vraiment le sentiment que la lisibilité de l'utilisateur en pâtit.
Aujourd'hui ce n'est plus un 2.4-cequ'onveut qui constitue la référence stable mais un 2.6-quelquechose et ce quelque chose varie d'une distribution à l'autre. Si je ne dis pas de bêtise :
- 2.6.18 pour Debian
- 2.6.20 pour Ubuntu
- 2.6.22 pour SuSE
- 2.6.XX pour RedHat
Du coup, l'utilisateur "personnel" (i.e. à la maison) éprouve plus de mal à décrire ses problèmes sur les forums ou ailleurs car il ne s'agit plus de parler de branche du noyau mais aussi de version anciennement dite mineure et d'un certain nombre de logiciels/technos à côté (genre udev, dbus...).
De même, l'utilisateur "professionnel" (i.e. en entreprise et/ou développeur pour Linux) ne bénéficie plus de cette pérennité connue avec les noyaux <= 2.4 et le diagnostic est d'autant plus difficile.
Bref, hors développeurs du noyau lui-même, il n'y a pas que des avantages.
Après attention, il ne s'agit pas d'une critique de ce nouveau modèle de développement. A titre personnel, j'y vois beaucoup d'intérêt comme, en vrac :
- des migrations entre versions plus simple même si plus fréquentes
- un support plus rapide des nouveaux matériels
- une meilleure appréhension des changements
- un moins grand nombre de patchs en parrallèle de la version officielle.
Bref, je suis plus nuancé.
PS: Magnifique article, détaillé, clair et documenté. Bravo
[^] # Re: Et l'avenir ?
Posté par GeneralZod . Évalué à 8.
Actuellement: Fedora 6 et 7 tournent avec un 2.6.22.x, Rawhide (F-8 en gestation) 2.6.23. F-7 connaitra également un 2.6.23 et probablement un 2.6.24.
L'avantage est qu'on a toujours un noyau à jour, l'inconvénient est que les modules noyaux proprios ont parfois du mal à suivre les mises à jours, enfin nVidia & cie, ils n'ont qu'à faire des pilotes libres. :o)
De plus, ça permet de tester plus largement le noyau donc le stabiliser très rapidement et ça profite à tout le monde.
[^] # Re: Et l'avenir ?
Posté par IsNotGood . Évalué à 3.
> Du coup, l'utilisateur "personnel" (i.e. à la maison)
Lequel ?
Madame Michu ?
Pour un utilisateur, c'est toujours du boulot que de suivre les évolutions d'un projet dynamique. Ce n'est pas spécifique à Linux.
Madame Michu ne doit pas utiliser kernel.org, mais une distribution avec du support.
> un 2.6-quelquechose et ce quelque chose varie d'une distribution à l'autre.
Ce n'est pas un problème Linux. C'est le libre, c'est le choix des distributions.
Par exemple RHEL 5 (et ses clones) utilise un 2.6.18 (et sur toute la durée de vie de RHEL 5, c-à-d au moins 7 ans). Libre à toute distribution d'utiliser aussi le 2.6.18. Mais (et ce n'est pas un reproche) elles préfèrent prendre la dernière version lorsqu'une distribution est en gestation (exactement comme le fait Red Hat).
Il y a de bonnes raisons à ça et ce n'est pas que pour la frime. C'est aussi pour avoir le support de la communauté des développeurs Linux lors de la gestation de la distribution (les développeurs ont le nez dans la dernière version, pas dans les vieilles versions).
Il n'y a pas de solution unique au désagrément du modèle de développement de Linux. S'il y a une solution uniquement, c'est d'avoir les drivers en libre et upstream.
Mais voyons aussi ce qu'a apporté l'évolution rapide de Linux et qui répond à ton soucis. Aujourd'hui Linux marche "les doigts dans le nez". A l'époque de Linux 2.0, 2.2 et même le 2.4 (sauf peut-être les dernières versions de 2.4) beaucoup d'utilisateurs devaient recompiler le noyau, faire un checkout d'un CVS pour avoir un driver pour leur carte télé, etc...
Ce que je veux dire, c'est que remettre en cause la rapidité de développement de Linux (c-à-d aussi son modèle de développement), c'est aussi reppousser le moment où on a la solutions qui va bien (pour une carte télé qui marche "les doigts dans le nez", etc).
Aujourd'hui très peu recompile leur noyau, c'est aussi grace au modèle de développement de Linux. Certe, de façon indirect.
> De même, l'utilisateur "professionnel" (i.e. en entreprise et/ou développeur pour Linux) ne bénéficie plus de cette pérennité connue avec les noyaux <= 2.4 et le diagnostic est d'autant plus difficile.
Le professionnel veut une garantie de service (c'est-à-dire du support). Donc il prend (ou devrait prendre) une distribution professionelle (ou un clone de distribution professionnel s'il ne veut pas de support mais seulement la stabilité de l'api) et ne pas se poser de question et ne pas demander l'impossible à Linux (le Linux upstream). Linux ne peut pas évoluer vite (ce qui est hypra important sinon Linux est dépassé par les autres et ne répond pas aux attentes) et être figé.
Kernel.org n'a pas pour cible Madame Michu ni les professionnels.
> d'un certain nombre de logiciels/technos à côté (genre udev, dbus...).
Ces technos étaient en développement intensif. Ça devrait se calmer.
Notons que le libre est ouvert. Donc les technos en pleine gestation sont disponibles (ça a les inconvéniants de ses qualités).
> Bref, hors développeurs du noyau lui-même, il n'y a pas que des avantages.
Il faut penser à l'offre de GNU/Linux globalement. kernel.org n'est "que" le développement.
Si tu veux du stable (api), tu trouves.
Si tu veux du "chaud", tu trouves aussi.
Comme l'a faire remarquer le GeneralZod (c'était toi ?), beaucoup utilisent Fedora (c'est "chaud", c'est pour le développement, c'est pour la veille technologique, etc) ET RHEL ou ses clones (c'est "froid", ça ne bouge pas, c'est sans intérêt pour la veille technologique, etc). Il faut deux distributions (ou plus de façon plus générale) car il y a des objectifs d'utilisation incompatibles.
Linux (de kernel.org) ne peut pas répondre aux utilisateurs type Fedora et aux utilisateurs type RHEL (ou Debian stable ou Mandriva CS etc). C'est impossible.
# Petite coquille...
Posté par windu.2b . Évalué à -2.
Il semble qu'il manque la partie en gras, non ?
[^] # Re: Petite coquille...
Posté par Étienne . Évalué à 3.
ou pas.
Cela évite [...]de le fragmenter sur tout le disque dur.
L'appel système permet en effet d'éviter la fragmentation en préallouant l'espace.
[^] # Re: Petite coquille...
Posté par windu.2b . Évalué à 1.
C'est moi qui ne sais pas lire >.<
bon, la machine à café c'est par où ?
# efficient ?
Posté par benoar . Évalué à 6.
s/efficient/efficace/ ... ?
[^] # Re: efficient ?
Posté par patrick_g (site web personnel) . Évalué à 7.
Efficient est bien présent sur le site du Grand Dictionnaire : http://atilf.atilf.fr/dendien/scripts/tlfiv4/showps.exe?p=co(...)
[^] # Re: efficient ?
Posté par eMerzh (site web personnel) . Évalué à 7.
un de mes profs donnait toujours un exemple pour illustrer leurs différences :
tu tues un moustique avec un bazooka ....le moustique est mort, c'est efficace....
tu tues un moustique avec une tapette à mouche... le moustique est mort aussi... c'est efficace mais aussi efficient...
[^] # Re: efficient ?
Posté par Gniarf . Évalué à -3.
# Yaisse.
Posté par farib . Évalué à 10.
(humour, toussa)
[^] # Re: Yaisse.
Posté par IsNotGood . Évalué à 6.
# Patchs pour Xen ?
Posté par GEDsismik (site web personnel) . Évalué à 2.
> Linux 2.6.23. Bien qu'étant intégrée en tant que patch dans plusieurs noyaux de
> distributions, Xen ne faisait jusqu'à présent pas partie du noyau officiel
> (mainline). Maintenant il est possible de démarrer au sein d'un environnement
> paravirtualisé par dessus l'hyperviseur Xen (c'est donc juste le support du mode
> Guest qui fait son entrée). Le reste n'est pas considéré comme répondant pour
> l'instant aux standards de Linux et reste donc à l'extérieur.
Il faut donc toujours patcher le noyau pour utiliser Xen ? Les ajouts dans le noyau sont pour le dom0 ou les domU (ou les deux) ?
[^] # Re: Patchs pour Xen ?
Posté par inico (site web personnel) . Évalué à 3.
Le dom0 est toujours sous forme de patch.
Je peut pas tester maintenant sinon je finirai jamais ce DM de Math (qui n'avance pas depuis 1h) ...
# Prions ...
Posté par polytan . Évalué à 1.
Espoir car j'avais un 2.6.20 tunné suspend2 (tuxonice maintenant) qui fonctionnait à merveille.
Cependant, comme tout bon geek, j'aime les dernières nouveautés, l'innovation et les dernières versions des programmes que j'utilise.
Erreur !!!
Que ce soit 2.6.21 (ah ben tiens, plus de son) ou 2.6.22 (ni de son, ni de perfs, le système est très mou, ne répond pas bien, ne demande qu'à être balancé), c'est la même galère, vive la régression.
C'est un des trucs qui me gonflent, quand ca ne marche plus alors que ça marchait avant...
Espérons que le 2.6.23 fera apparaitre un beau sourire sur mon joli visage, que les performances seront au rendez-vous (ou au moins aussi bien qu'en 2.6.20) avec quelques innovations (temps qu'à faire).
J'ai evidement testé avec des noyaux plus traditionnels, même des sources officielles...
# Mes impressions
Posté par Phibrizo (site web personnel) . Évalué à 2.
Ces derniers temps, mon pointeur de souris avait tendance à se bloquer par intermittence, en particulier quand plusieurs applications étaient lancées. (et quand j'ouvrais de nombreux onglets sous firefox). Comme j'ai changé de souris sans fil récemment et que le clavier ne semblait pas impacté, je pensais plutôt à un souci matériel mais, depuis que j'ai compilé ce dernier noyau, le souci a disparu et la souris réagit mieux que jamais..
Bref, j'imagine que ce n'est pas très scientifique comme impression, mais je suis très satisfait de ce nouveau noyau.
[^] # Re: Mes impressions
Posté par Antoine . Évalué à 2.
Moi mon clavier est devenu mou, j'ai du mal à ta
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.