Le noyau nouveau est arrivé

Posté par  (site Web personnel) . Modéré par Fabien Penso.
Étiquettes :
0
26
nov.
2001
Noyau
Comme promis suite aux déboires du noyau 2.4.15, le nouveau noyau 2.4.16 vient de sortir.

Il corrige le problème de corruptions des inodes du 2.4.15 et aussi quelques autres corrections.

Voici un morceau du ChangeLog :

- Fix 8139too oops (Philipp Matthias Hahn)
- Correctly sync inodes in iput()(Alexander Viro)
- Make pagecache readahead size tunable via /proc (was in -ac tree)
- Fix PPC kernel compilation problems (Paul Mackerras)

Maintenant que Linus ne s'occupe plus de la branche 2.4.x, espérons que ça ira mieux ;-)

Aller plus loin

  • # Juste pour dire...

    Posté par  . Évalué à 1.

    Que les 4 lignes dans la nouvelle ne sont pas un "morceau" du ChangeLog, mais l'intégralité du ChangeLog...

    Marcello ferait-il de l'excès de zèle ? ;)
    • [^] # Re: Juste pour dire...

      Posté par  . Évalué à 1.

      De plus, je pense que le troll la dernière ligne ne fait pas partie du ChangeLog d'origine. ;-)
      • [^] # Re: Juste pour dire...

        Posté par  . Évalué à 1.

        C'est pas tant que ça un troll, c'est la vérité.
        A partir de maintenant, les patchs seront testés dans le noyau instable puis backportés dans le noyau 2.4, on n'aura plus de problèmes de ce genre (ou alors beaucoup plus rarement) car tout sera mieux testé. On se plaindra tôt ou tard que tout n'est pas backporté assez vite dans le noyau stable comme pour l'USB, mais c'est une autre histoire ;)

        Les développeurs ont enfin un noyau "on the bleeding edge" pour s'amuser entre eux et faire péter toutes leurs données dans la joie et la bonne humeur. Ils vont s'arrêter de tout casser dans le noyau stable en voulant réécrire des VM et toucher aux inodes à tout bout de champ!
        C'est quand même dingue de toucher à des parties aussi sensibles sur un noyau stabilisé sans les tester à fond. Je sais y'avait de très bonnes raisons pour ça, dont leur frustration de pas avoir de *vrai* noyau de dev, mais de toute façon c'est un troll sans fin.
        • [^] # Re: Juste pour dire...

          Posté par  . Évalué à 1.

          C'est quand même dingue de toucher à des parties aussi sensibles sur un noyau stabilisé sans les tester à fond. Je sais y'avait de très bonnes raisons pour ça, dont leur frustration de pas avoir de *vrai* noyau de dev, mais de toute façon c'est un troll sans fin.

          Mais arretez un peu avec cette histoire... Le noyau 2.4.x, avec x<=15 n'etait pas un noyau stable, dixit Linus en personne. C'est quand meme lui que l'on peut croire, non ? Il change les regles comme cela l'arrange (car depuis les 1.2.x, cela a change souvent, notamment le backport de code stabilise d'une version en dev). Qu'il y ait eu des problemes ou des changements majeurs dedans est normal. Il n'y a rien a dire d'autre sur le sujet (si ce n'est que d'utiliser un 2.2.x pour les serveurs).

          C'est quand meme pas difficile a comprendre...

          PK, qui n'arrive pas a comprendre comment on peut disserter la-dessus.
          • [^] # Re: Juste pour dire...

            Posté par  . Évalué à 1.

            >si ce n'est que d'utiliser un 2.2.x pour les serveurs

            vi, vi, mais y a quand meme certains trucs du 2.4 qui sont trop importants pour laisser un serveur en 2.2.

            Eternel probleme de "ceux qui se mouillent les premiers" ...
            • [^] # Re: Juste pour dire...

              Posté par  . Évalué à 1.

              Et comment faisais-tu lorsque le 2.4 n'existait pas ?
              Les principales évolutions entre le 2.2 et le 2.4 concernent des éléments multimédia et USB. Pour le reste, la VM a changé, la stack IP a été refaites, mais les fonctionnalités équivalentes sont présentes dans les kernel 2.2.

              Alors si tu préfères utiliser un noyau optimisé (ce que je suppose être tes 'trucs') mais instable sur un serveur, libre à toi, mais ne viens pas te plaindre qu'il est instable... Personnellement, je préfère laisser les optimisations aux autres et garder un noyau stable pour les applis importantes.
              • [^] # Re: Juste pour dire...

                Posté par  . Évalué à 1.

                Et reiser FS ?? les systeme de fichiers journalisés sont quand même utiles sur les serveurs !
              • [^] # Re: Juste pour dire...

                Posté par  . Évalué à 1.

                > principales évolutions entre le 2.2 et le 2.4 concernent des éléments multimédia et USB

                non non ca c'est du pipi de chat. et d'ailleurs l'USB a ete back porté sur le 2.2

                Je parle plutot des fonctionnailté SMP, des locks , du raw data, ... tout un tas de trucs indispensables pour faire un serveur sgbd digne de ce nom par exemple.
                Les entreprises sous unix n'ont vraient commencé a s'interresser a linux qu'avec le 2.4. Le 2.2 ne tient absolument pas la comparaison avec Sparc , HPUX, AIX, ... Le 2.2 est ok pour un poste client, un firewall, un petit serveur web ou de fichier. Ca fait beaucoup de machines. Mais pour les choses vraiment serieuses c'est pas ca.
                • [^] # Re: Juste pour dire...

                  Posté par  . Évalué à 1.

                  Mais pour les choses vraiment sérieuses, tu as vraiment intérêt à utiliser un système totalement stable... Et donc ne pas utiliser ces nouvelles fonctionnalités, qui comme toute chose nouvelle a l'inconvénient majeur d'être partiellement instable.

                  Le problème avec la branche 'stable' du noyau linux, c'est qu'elle ne représente pas la branche des noyaux stables, mais seulement la branche des noyaux dont les évolutions sont figées afin de lui apporter de la stabilité. Elle ammène à un noyau stable, mais n'est pas composée de noyaux stables.

                  En conclusion, comme tu le dis, linux est pour l'instant parfaitement adapté pour un firewall, un serveur web, de fichiers, mail, etc. Il sera adapté pour des serveurs plus conséquents, mais il ne l'est pas actuellement. Et l'utiliser comme tel est dangeureux pour le service en lui-même, et pour l'image de linux aussi qui se trouve ainsi dévalorisé par son inadaptation actuelle pour les utilisations sur des gros serveurs.

                  PS: pour le post précédent: reiserfs fonctionne très bien sur noyau 2.2 (j'étais passé sur reiserfs bien avant d'upgrader mon poste de travail en 2.4.x)
                  • [^] # Re: Juste pour dire...

                    Posté par  . Évalué à 1.

                    On ne parle pas de la meme chose. Tu parle de stabilité atteinte, moi de fonctionnalites disponibles.

                    A ton avis qui c'est qui a besoin du raw data sinon les grosses bases de donnees sur des machines multipro tres chargees ? Tu peux simuler ca sur ta becane a toi ? Il s'agit de machines 16 proc et de teraoctets de donnees.
                    C'est bien pour ca qu'Oracle 9i ne marche que sur 2.4
                    Evidement qu'on ne met pas ces machines en production mais faut bien tester en "semi-production" . Sinon on ne reglera jamais les bugs ! Et le fait que certain s'y mettent c'est la preuve que ca interresse *beaucoup* les grosses entreprise. Car ca coute cher. Elles savent bien que ca ne marchera pas aussi bien que solaris mais elles croient en l'avenir Linux. Les problemes rencontres ne devalorisent aucunement linux au contraire.

                    Tu as completement sauté mon commentaire :
                    'Eternel probleme de "ceux qui se mouillent les premiers" ...'

                    (dernier message. j'arrete la)
          • [^] # Re: Juste pour dire...

            Posté par  . Évalué à 1.

            Hé! je voulais pas lancer de troll!

            Je me cite:
            Je sais y'avait de très bonnes raisons pour ça [les développements sauvages sur les noyaus stables]
            mais de toute façon c'est un troll sans fin.

            Justement, je voulais préciser que *maintenant* qu'on a un noyau de développement, sur lequel les développeurs vont pouvoir bosser et qu'on va pouvoir tester, il n'y aura (presque?) plus de problèmes de ce genre, le noyau stable va enfin pouvoir *commencer* à devenir mature.

            D'ailleurs je pense suivre dorénavant le noyau instable au lieu du noyau stable pour pouvoir tester les nouvelles évolutions. Je sais que c'est dangereux, mais bon si on sauvegarde suffisamment ses données...
        • [^] # Re: Juste pour dire...

          Posté par  . Évalué à 1.

          les releases 2.4.X sont des appels a TEST

          comprenez qu en AUCUN CAS ils representent un produit fini et parfait

          ils sont juste une estimation d'un noyau a peu prés correct qui peut etre testé par des NON developpeurs

          mais en realité, jamais il n'a été pensé qu'ils etaient parfait

          comprenez bien que vous sautez une ETAPE par un rapport aux logiciels proprietaires types, vous avez accés aux developpements reguliers du NOYAU
          et il vous est demandé en tant que communauté de les tester et dire trés vite s'il y a des bugs pour vite ameliorer le noyau linux

          en fait 2.4.15 ou 2.4.88 ca ne sera _jamais_ un produit fini completement.

          c'est la nature meme du developpement de linux depuis des siecles

          "stables" c est qu ils sont censé aller vers une stabilisation des fonctionnalités et ne plus en rajouter.

          (par exemple un noyau 2.4 ne vas pas se mettre a rajouter les ACL subitements )


          ce n'est pas nouveau, il en est ainsi depuis les 2.0.x ce genre de troll (quand linux a commencé a devenir populaire et que plus en plus de gens pris de la manie du updateur fou ont cru que "stable" voulait dire : pret a etre vendu et garantie sur place)


          vous dites qu ils doivent les tester ? mais comment et avec quel moyen ???

          confondez pas suse ou redhat ou ibm qui EUX ont les ressources de tester ce qu ils vendent avec les _developpeurs_ comme linus ou cox qui vous donnent un accés a leurs developpements en quasi temps reel

          les tests, c'est a VOUS (moi ,nous, ceux qui utilisont linux regulierement) de les faire

          OU

          on attends qu un distributeur fasse le job et on le paye pour ca. (achat d une redhat 7.2 parce qu'il y a une valeur ajoutée, redhat fait des tests et justement n ont pas le temps d implanter le tout dernier kernel de la mort dans leur distrib ,comme tout distrib un peu serieuse)


          ne confondez pas les roles, sinon vous allez longtemps continuer le troll

          tien,s je le prevois deja pour le 2.6.23 qui aura un bug sur la gestion de l ajout a chaud d un disque dur (ca fera boum! "mais que font ces developpeurs? rhalalalal")


          hmmf... toujours la meme routine
          • [^] # Re: Juste pour dire...

            Posté par  . Évalué à 1.

            tu parles comme un enfant prodique.

            Score -1 : Je n'ai pas pu me retenir tellement j'en ai marre de ces critiques faciles sur le noyau.
          • [^] # Re: Juste pour dire...

            Posté par  . Évalué à 1.

            OK, le 2.4 n'est pas censé être parfait, d'ailleurs il est reconnu qu'un noyau n'est pas stable avant un niveau de patch suffisamment élevé. Le noyau réellement stable actuellement, c'est le 2.2 On est d'accord.

            Ce que je trouve dommage, c'est que le 2.5 n'ai pas pu être lancé plus tôt. C'est à ça qu'il sert: pouvoir tout casser, mettre du code tout neuf, puis tester avant intégration dans le noyau stable. Comme ça on n'a pas de mauvaise surprise. De toute façon il faut être STUPIDE pour installer les derniers noyaux en croyant que tout va forcément bien se passer.

            Mais globalement c'est satisfaisant, car ça nous a permis entre autres d'avoir au hasard ext3 et une VM sensiblement meilleure dans le noyau stable sans attendre le 2.6
            • [^] # Re: Juste pour dire...

              Posté par  . Évalué à 1.

              > une VM sensiblement meilleure

              C'est pas au sens perf que ca compte c'est au sens "possibilite de maintenance future" .
              L'ancienne VM devenait de plus en plus infernale a maintenir d'ecquere, C'etait une source potentielle de bug sournois a n'en plus finir.
              La nouvelle aura des bugs c'est sur, mais elle est bien plus "propre" et on peut donc raisonablement arriver a court terme a un etat de "bug free".
            • [^] # Re: Juste pour dire...

              Posté par  . Évalué à 1.

              C'est à ça qu'il sert: pouvoir tout casser, mettre du code tout neuf, puis tester avant intégration dans le noyau stable.

              C'est pas tout à fait comme ça que ça se passe...

              Les développements de linux, comment ça marche ? (bilan de mon observation... ; à quelques exceptions près, c'est comme ça que ça se passe)

              Les développeurs travaillent sur la branche instable du noyau (x.y.z avec y impair), en partant d'une version qu'ils estiment suffisament stable de la branche stable.

              Sur cette version, ils ajoutent des fonctionnalités, innovent, font des changements en profondeur (on a par exemple vu apparaitre la modularité du noyau dans le 1.3, ipchains dans le 2.1 et iptables dans le 2.3), débugguent, etc.

              Si d'aventure ils découvrent un bon vieux bug tout pourri des familles qui traine dans la branche stable, ils back-portent le patch.

              Une fois que les fonctionnalités sont suffisamment avancées et stabilisées, la dernière version de la branche instable devient la première de la branche stable suivante (à un patch près).

              On fige les fonctionnalités, on lâche les utilisateurs dessus, qui vont apporter tous les bug-reports voire bug-fixes nécessaires.

              Par ailleurs, gel des fonctionnalités ne veut pas dire gel du support matériel, on ne refuse pas l'ajout de drivers pour certains matériels (anciens pas encore supporté ou tout nouveau tout beau)

              ... et ainsi de suite ...

              C'est pour ça que les patches 2.5.1pre1 et 2.4.16 ne comprennent pas les mêmes choses...

              PS: Je te vois venir, tu vas me parler de la VM de la 2.4.

              La VM de la 2.4 a souffert de sa complexité : la maintenance du code et les problèmes qui étaient rencontrés avec ont fait qu'il valait mieux en changer (et pourtant, tout le monde s'accorde pour dire qu'il y avait de bonnes idées)
  • # Changelog

    Posté par  . Évalué à 1.

    Pourquoi dire que c'est un morceau du changelog alors que c'est un copier coller ENTIER ?

    ... no comment...
  • # A propos de noyaux qui sortent trop vite

    Posté par  . Évalué à 1.

    Pour tous ceux qui se plaignent des release trop rapprochées des noyaux, Linus s'explique (très clairement) sur ce point dans le mail disponible à cette adresse : http://linuxtoday.com/news_story.php3?ltsn=2001-11-26-004-20-OP-KN(...)

    Voila, pour ceux que ca intéresse, je trouve que ses arguments sont tout ce qu'il y a de plus valable.
    • [^] # Re: A propos de noyaux qui sortent trop vite

      Posté par  (site Web personnel) . Évalué à 1.

      hum... je sais que j'ai trollé sur la derniere news, et que ca n'est pas bien.
      Je suis d'accord avec ce que dit Torvalds ici.
      En effet, le noyau 2.4 n'avait plus besoin d'attendre avant de sortir.
      le noyau etait stable depuis deja longtemps, et c'etait correcte de le sortir.
      Le sujet d'un des trolls de la derniere fois, c'etait :
      dans une branche "dite" stable, la sortie des nouvelles version ne doit elle pas
      etre plus lente, que sur une version de developpement ?
      laissons l'innovation au 2.5
      et continuons à avancer dans la stabilité du 2.4
      "qui va piano, va sano"
      • [^] # Re: A propos de noyaux qui sortent trop vite

        Posté par  . Évalué à 1.

        Il faut peut-être voir également la quantité de changements apportés entre deux versions.
        La fréquence de sortie des versions peut être élevée sans que les changements soient importants. Ainsi, il est probable qu'il y ait plus de différences entre deux versions de développement du noyau qu'entre deux versions stables.
      • [^] # Re: A propos de noyaux qui sortent trop vite

        Posté par  . Évalué à 1.

        Il n'empêche que pour aboutir à la stabilité, il faut faire beaucoup de tests. Et la branche de développement n'est utilisée (presque) que par les développeurs, ce qui ne permet pas de tester toutes les configs/situations/bizarreries. Je trouve normal qu'il y ai dans chaque branche stable une première phase « un peu plus à risque » mais ouverte à plus de monde pour aboutir à ce que l'on a actuellement.
        Parce que faut pas charrier, maintenant, il est bien le noyau, et avec un autre système de dev ça aurait pu prendre bien plus de temps.
        D'un autre côté, les gens qui qualifient les premiers noyaux de la branche 2.4 « de noyaux de tests tous buggués et absolument pas utilisables » (bon, ok j'exagère un poil ;) ) eh bien c'est qu'il n'ont jamais utilisé de noyaux de branche instable.
        • [^] # Re: A propos de noyaux qui sortent trop vite

          Posté par  (site Web personnel) . Évalué à 1.

          D'un autre côté, les gens qui qualifient les premiers noyaux de la branche 2.4 « de noyaux de tests tous buggués et absolument pas utilisables » (bon, ok j'exagère un poil ;) ) eh bien c'est qu'il n'ont jamais utilisé de noyaux de branche instable.


          Sans troll aucun, peut etre que si ils s'interessent au noyau stable, c'est justement parce qu'il n'ont pas envie d'utiliser un noyau instable non ?

          Bon, maintenant, je suis d'accord, on peut trouver son bonheur avec certaines versions du noyau 2.4.x

          Bref, c'est juste mon avis qui n'engage que moi hein !
          • [^] # Re: A propos de noyaux qui sortent trop vite

            Posté par  . Évalué à 1.

            Sans troll aucun, peut etre que si ils s'interessent au noyau stable, c'est justement parce qu'il n'ont pas envie d'utiliser un noyau instable non ?

            Exactement ! C'est bien pour ça que je dis simplement qu'il faut avertir les utilisateurs que l'ouverture de la nouvelle branche stable ne veut pas dire que le noyau peut être mis en production, ni même qu'il va être stable à 100% sur une machine utilisateur. Cela veut juste dire qu'on entre dans une phase de tests plus complète à laquelle peut participer n'importe qui. Et si les utilisateurs ne veulent vraiment aucun problème, qu'ils attendent l'ouverture de la branche de dev suivante, à ce moment là le noyau de la branche stable sera vraiment stable.
          • [^] # Re: A propos de noyaux qui sortent trop vite

            Posté par  . Évalué à 1.

            Effectivement, mais si la rumeur "n'utilisez pas de noyau avant le x.y.10" se répands, Linus sera obligé de sortir le 2.6.10 directement pour que les gens testent le noyau...
            La bonne démarche, de notre part (les adeptes de linux qui savent compiler et patcher) serait d'utiliser les noyaux "dits stables" dès qu'ils sortent sur toutes les machines pas critiques.
            Voir de tester les noyaux un minimum sur les hardware de prod (sur le spare par exemple).

            par exemple, si j'ai un serveur web en 2.2.19, il faut tester le 2.4.0 des qu'il sort sur le meme hardware pour signaler les problèmes de drivers et autres complications. Sinon quand le 2.4.16 devient interessant, je ne pourrai pas changer de noyau si personne n'utilise la meme config bizarre.Le serveur Web n'est pas forcement un bon exemple non plus, testez systématiquement sur les portables, y a encore pas mal de surprises, notement avec le suspend/resume ...

            les problemes de scheduleur/vm/inodes, tout le monde y est confronté quel que soit sa configuration, il y a donc un maximum de chances que cela soit détecté. Par contre les configurations exotiques (3 cartes son, 4 controleurs ieee1394, 6 controleurs ide ... le tout en eisa et token ring) on peut etre sur qu'il y a des problemes de driver/detection
            • [^] # Re: A propos de noyaux qui sortent trop vite

              Posté par  (site Web personnel) . Évalué à 1.

              Meme sans aller à l'extrème de le tester sur une machine un peu risquée...

              Mais il est courrant d'avoir une machine de test/bidouille avec aucune donnée importante dessus (un vieux pentium par exemple).
              Alors meme si on ne test pas les pilotes dernier cris...
              Au moins on test la compilation et le bon fonctionnement sur du vieux matériel !
              C'est déjà un grand pas !
      • [^] # Re: A propos de noyaux qui sortent trop vite

        Posté par  . Évalué à 1.

        En effet, le noyau 2.4 n'avait plus besoin d'attendre avant de sortir.
        le noyau etait stable depuis deja longtemps


        bof ... loin de moi l'idee de vouloir troller, mais la stablite du 2.4 a ete grandement mise a l'epreuve (voir les differents deboires des version bugees). J'ai constement mis a jour mon noyau jusqu'au 2.4.13, et j'ai regulierement rencontre des pb (lies principalement a ReiserFS, l'allocation memoire et autres). L'integration de la nouvelle VM, meme si elle est +performante a ete rapide, peut-etre trop rapide (pour preuve les bugs corriges par la suite).

        Je n'ai aucune config exotique, n'ayant que du vieux matos, et depuis qq temps je suis victime de trop nombreux "kernel oops", tres svt lies aux applications X ... ce qui donne un reset immediat, ca m'arrive 4-5 fois par semaines, et pour une branche dite stable, c'est carrement decevant.

        Je ne critique pas le boulot des kernel-coders, srtt pas, mais j'ai juste l'impression que de nombreux changements recents n'auraient pas du etre integre ds une version stable.
        • [^] # Re: A propos de noyaux qui sortent trop vite

          Posté par  (site Web personnel) . Évalué à 1.

          Des problèmes avec le 2.4, moi j'en rencontre moins qu'avec le 2.2...

          Ainsi, meme si tout le monde tape sur la VM du 2.4, moi je dis : elle est bien mieux que celle du 2.2.

          Encore ce matin, j'ai balancé un processus très gourmand en mémoire (plus que la swap et la RAM physique) sur mon 2.4 et il a tué le processus et j'ai pu réutiliser ma linuxbox aussitot...
          Alors qu'avec le 2.2, j'ai été obligé d'attendre 20 min avec la meme manip et la meme machine...
  • # 8139too oops ?

    Posté par  . Évalué à 1.

    Quelqu'un qui est abonné à la LKML pourrait donner des précisions ? J'ai remarqué des problèmes mineurs sur ma Realtek qui utilise ce pilote, du genre "Unable to signal thread" à l'arrêt de la machine, ou encore des problèmes reportés par ifconfig au démarrage. Ces problèmes n'ayant aucune incidence apparente sur le fonctionnement de la carte, je ne me suis pas penché dessus plus que ça.
    Merci.
  • # [url] Linus Torvalds: Comments on Kernel Releases

    Posté par  . Évalué à 1.

    extrait du site : linuxtoday.com
    Nov 26, 2001, 10 :03 UTC

    http://linuxtoday.com/news_story.php3?(...)
    ltsn=2001-11-26-004-20-OP-KN
  • # Linus doit faire de l'hyper-stable ?

    Posté par  . Évalué à 1.

    Je trouve facile les gens qui dissertent sur la fréquence des versions de sortie du noyau, si telle modif est pertinente ou non, ...

    Le noyau 2.4 est la branche stable, çà ne veut pas dire qu'il n'évolue pas avec les risques que celà impliquent. La seule chose que garanti un noyau 2.4 durant ces versions est que l'API ne change pas pour les programmes en user-mode (quoique parfois...). Compte-tenu de cette contrainte, les développeurs font le maximum pour avoir le meilleur noyau possible (même si c'est une branche stable).
    On reproche parfois le changement de VM dans le 2.4. mais celà c'est aussi produit avec le 2.2.

    Le travail de fiabilisation, de garantir que tout fonctionne sans accros est du ressort des distributeurs (Mandrake, Debian, etc...). Distributeurs qui ajoutent des patchs souvent refusés par Linus. Car le rôle de linus est de fournir une infrastructure pour obtenir un noyau hyper stable et pas de fournir au premier jet un noyau hyper stable, optimiser MMX, avec tous les derniers drivers etc...

    Les gens veulent le beurre et l'argent du beurre :
    - Les dernières techno/perfo
    - Une super fiabilité.

    => faut par rêver. Bien qu'avec Linux çà arrive parjois ;-) ...
    • [^] # Re: Linus doit faire de l'hyper-stable ?

      Posté par  (site Web personnel) . Évalué à 1.

      En plus, un bon paquet des ces "bugs" n'étaient que des fautes de frappe empéchant la compilation, pas des bugs de fonctionnement (une fois la faute de frappe corrigée).

      Le 2.4.14 par exemple, une fois viré les 2 lignes en trop dans loop.c (oubliées aprés un changement de nom d'une fonction) fonctionnait très bien.

      Si on veut un noyau prémaché et testé corrigé de partout, on ne compile pas son noyau soi même, on installe une distrib depuis un CD et on n'y touche plus que pour installer les correctifs officiels.

      Si on compile son noyau soi même, on doit être prêt à faire ce genre de modifs, à lire LKML pour y pécher les dernières infos et a "adapter un peu".

      C'est comme quand on compile une appli soi-même : "./configure; make; make install", ça ne passe pas toujours du premier coup.

      PS : Je suis déçu, aprés "EXTRAVERSION = -greased-weasel" dans Makefile, j'ai été déçu de ne pas trouver ""EXTRAVERSION = -brown-bag" dans le 2.4.16 :-)
      • [^] # Re: Linus doit faire de l'hyper-stable ?

        Posté par  . Évalué à 1.

        <coup de gueule>
        Alors c'est tout ou rien, soit on se contente de ce que nous fournis notre distrib soit on est un vrai développeur capable de corriger lui-même les erreurs du noyau.
        Pas de juste milieu du genre "je vais recompiler mon noyau pour n'avoir que ce dont j'ai besoin et avoir la fonctionnalité X qui n'était pas dans les noyaux pré-compilés de ma distrib".
        J'ai souvent recompilé mon noyau pour qu'il soit le plus adapté possible à mes besoin mais c'est tout juste si je sais appliquer un patch et ne me parle pas de reporter des bugs du noyau je ne sais même pas comment les mettre en évidence, quand à la LKML j'ai pas le temps de lire les centaines de messages par jours qui y sont postés.
        Tiens je parie que tu va me répondre une connerie du genre "connait pas touche pas" mais après tu te plaindra que les gens sont pas capables de penser par eux-mêmes.
        </coup de gueule>
        Aaaaah, ça fait du bien...
        • [^] # Re: Linus doit faire de l'hyper-stable ?

          Posté par  (site Web personnel) . Évalué à 1.

          Personne ne t'empeche de recompiler ton noyau depuis les sources fourni sur le CD de ta distrib, comme ca tu l'aura ton noyau...
          Apres si tu comprend rien, tu attends sagement que Monsieur Chaporouge te file ses sources qu'il aura tester, et que tu pourras utiliser.

          Ne pas confondre 'avoir le dernier truc de suite' et 'avoir le premier truc qui marche'...
        • [^] # Re: Linus doit faire de l'hyper-stable ?

          Posté par  (site Web personnel) . Évalué à 1.

          Pas besoin d'être un développeur aguerri pour compiler le noyau. Mais si on n'est pas capable d'appliquer un petit patch et qu'on n'a pas envie de se documenter un minimum sur ce qu'on fait, on ne compile pas un noyau !

          Compiler un noyau est facile mais pas "foolproof" !

          C'est d'autant plus vrai que tous les bugs récents ont été détectés aussitôt et tout les sites de news (dont LinuxFr) en ont parlé aussitôt en indiquant les modifs à faire. C'est quand même pas sorcier !
    • [^] # Kernel 2.0

      Posté par  (site Web personnel) . Évalué à 1.

      Quelqu'un sait-il si le kennel 2.0.37 est considéré comme stable ;-) ?
      Un peu dans le même esprit cependant, mes machines de production sont restées en noyau 2.2.19, après une brève incursion en 2.4.x.
      C'est quand même bien mieux quand y'a aucun problème, et c'est bien pour cela que Linux est apprécié a priori.
      En conclusion c'est très bien d'avancer en développement, mais les releases annoncées comme stables ne le sont plus forcément, c'est dommage. Si on veut une machine à la pointe du dev mais pas stable, chacun son tuc...
      • [^] # Re: Kernel 2.0

        Posté par  . Évalué à 1.

        > Quelqu'un sait-il si le kennel 2.0.37 est considéré comme stable ;-) ?

        Il est pas stable car il y a le 2.0.39.

        Chez moi je suis sous 2.2.19 qui roulaize mortel. Et je n'ai pas de grosses motivations pour passer en 2.2.20 ou faire le grand saut en 2.4.
        • [^] # Re: Kernel 2.0

          Posté par  . Évalué à 1.

          >> Quelqu'un sait-il si le kennel 2.0.37 est considéré comme stable ;-) ?
          >Il est pas stable car il y a le 2.0.39.

          Dans mes souvenirs, il a ete remplace assez rapidement par le 2.0.38 qui lui est tres stable.
          Longtemps apres, AC a fait les derniers updates de drivers pour le 2.0.39.

          Donc utilise le 2.0.39 si tu as le choix !!
      • [^] # Re: Kernel 2.0

        Posté par  . Évalué à 1.

        > En conclusion c'est très bien d'avancer en développement, mais les releases annoncées comme stables ne le sont plus forcément, c'est dommage.

        C'est pourquoi il est communément conseillé d'attendre quelques jours/semaines pour utiliser un noyau (sauf si on veut tester bien sûr). Si le 2.4.16 sort, tu peux estimer par exemple que le 2.4.13 a été pas mal utilisé, et donc qu'il n'a pas de bugs "évident".
        D'ailleurs je peux t'assurer que le 2.4.13, du moins chez moi, ne pose aucun problème :)
        • [^] # Re: Kernel 2.0

          Posté par  . Évalué à 1.

          Je veux pas faire le plus malin, mais si le 2.4.16 est sorti, c'est qu'il y a eu des bugs à corriger depuis le 2.4.13 inclu... Ou alors ils changent les numeros de versions pour nous faire croire que ça bouge ?

          A mon avis quand un noyau sort, le mieu est de vérifier dans le changelog si les changements avec la version précédente te concernent, et sinon tu installe la version précédente.
  • # petit historique Linux

    Posté par  . Évalué à 1.

    Le 13/03/1994 : Version 1.0.0 taille du tar.gz : 1 259 161
    Le 07/03/1995 : Version 1.2.0 taille du tar.gz : 2 301 256
    Le 09/06/1996 : Version 2.0.0 taille du tar.gz : 5 843 677
    Le 26/01/1999 : Version 2.2.0 taille du tar.gz : 13 080 195
    Le 04/01/2001 : Version 2.4.0 taille du tar.gz : 24 378 762

    Avec une telle inflation, il est plus dure d'avoir un noyau sans le moindre bug.
    • [^] # Re: petit historique Linux

      Posté par  . Évalué à 1.

      Mais ça ressemble à une croissance exponentielle ça!
      Si ça continue ainsi on peut estimer que le 2.6 fera de l'ordre de 45MO, et combien pour le suivant?
      La perspective fait peur.
      • [^] # Re: petit historique Linux

        Posté par  . Évalué à 1.

        C'est pas en partie au moins, du au support de matos en plus ? Bin oui, les drivers sont dans le noyau, et vu que de plus en plus de matos est supporté, ca prend de plus en plus de place.
        Bon, le kernel en lui meme aussi, mais ce que je veux dire, c'est qu'il faudrait peut etre plutot voir la taille du noyau une fois qu'il est compilé et que t'as que ce qui te concerne :)
        • [^] # Re: petit historique Linux

          Posté par  . Évalué à 1.

          J'utilise linux depuis la 1.2.13.
          Les souvenir du zImage sont :
          1.2 : 180 k (de tête)
          2.0 : 320 k (de tête)
          2.2 : 430 k (réel)
          2.4 : 480 k (réel)

          Il faut noté que le 1.2 n'a pas de support de module. Et les valeurs que je donne ne sont pas à configuration équivalente !

          -1 : car c'est pas très interessant...
        • [^] # Re: petit historique Linux

          Posté par  (site Web personnel) . Évalué à 1.

          du moment que ça tient sur une disquette bootable DVD-rom bootable...

          Axel - 584
    • [^] # Re: petit historique Linux

      Posté par  (site Web personnel) . Évalué à 1.

      C'est vrai que la taille augmente vraiment très vite ! (et tant mieux).

      Mais ce qu'on va peut-être voir arriver c'est une distribution du noyau dans une forme différente... en effet, pourquoi télécharger tous les modules gérant les drivers pour le réseau 1Gbits alors que la machine est sur un réseau 10M ou même pas sur le réseau du tout...

      Donc, il y aurait une archive pour le corps du noyau (VM...) et plusieurs archives par types de périphériques... (sous forme de patch).

      Ca serait peut-être une bonne idée non ?
  • # 2.4 ça marche plus pas si mal...

    Posté par  . Évalué à 1.

    Juste pour dire que personnellement je n'ai jamais eu de probleme avec le 2.4...
    • [^] # Re: 2.4 ça marche plus pas si mal...

      Posté par  . Évalué à 1.

      Damned, il y en a un !

      Il faut que tu publies les sources en mettant un README.txt pour expliquer ce mistère.

      hop : -1 (je suis bête et méchant).
  • # Scoring des messages

    Posté par  . Évalué à 1.

    attention, quand vous donnez des notes aux messages, il ne s'agit pas de donner une note pour dire qu'on est d'accord ou pas avec les propos, mais plutot de scorer en fonction de l'intéret du message: réponse hors sujet, troll, (fud).

    concernant les pro-microsoft, les pro-mandrake, les pro-debian, les anti-trucs ... je crois que ca reste affaire de conviction, et les notation ne devraient pas tenir compte de certains de ces aspects.

    bonne journée.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n’en sommes pas responsables.