2.4.19 est enfin sorti

Posté par  (site web personnel) . Modéré par Benoît Sibaud.
Étiquettes :
0
3
août
2002
Noyau
Comme dit le Changelog :

« 2.4.19-rc5 was released as 2.4.19 with no changes. »

Au programme, un nombre de corrections de bogues très important. On relèvera notamment des mises à jour importantes de Netfilter, avec notamment l'inclusion du port forwarding local.


Ce noyau, qui m'a l'air d'être aussi interessant que l'avait été le kernel 2.2.18 à sa sortie, est enfin là et il est peut-être pour longtemps le dernier noyau 2.4. Ne serait-ce que de part le temps qu'il a mis à sortir ;-)

Aller plus loin

  • # Depuis le temps ...

    Posté par  (site web personnel) . Évalué à 10.

    Ce que je veux dire par ce titre, c'est que les temps de maj et de tests ont ete allonges depuis la 2.4.18 et il semblerait que cela soit une bonne chose pour obtenir un 2.4.19 qui soit encore plus stable que le 2.4.18

    D'ailleurs, on dirait que les gars du kernel aient eu un peu peur de le sortir trop vite.

    En tout cas, tres bien, faudra que je mette a jour dans une semaine :)

    Steph
    • [^] # Re: Depuis le temps ...

      Posté par  . Évalué à 7.

      Il etait important de prendre son temps, on aura certainement un 2.4.20 avant la sortie officielle du 2.6

      En attendant, je ne comprend toujours pas pourquoi Alan Cox s'evertue a mettre plein de -ac alors que Tosatti lui semble les ignorer pour la plupart
      • [^] # Re: Depuis le temps ...

        Posté par  . Évalué à 10.

        « En attendant, je ne comprend toujours pas pourquoi Alan Cox s'evertue a mettre plein de -ac alors que Tosatti lui semble les ignorer pour la plupart »

        Parce que Red Hat, comme pas mal de distributions, ne fournira pas le noyau officiel, mais un noyau patché jugé meilleur ?
      • [^] # Re: Depuis le temps ...

        Posté par  . Évalué à 10.

        Ils ont des méthodes de travail et des capacités différentes. De plus, ils suivent des buts différents : Marcelo doit fournir une base de travail saine pour l'ensemble des développeurs, une sorte de référence alors que Alan teste les modifications qui lui sont envoyés et tache de fournir un noyau un peu plus "saignant" qui par ailleurs est souvent le noyau des distributions majeures. J'ai l'impression personnelle que Alan s'amuse à collectionner les noyaux alors que Marcello travaille à la stabilité et qu'ils ne travaillent pas à la même vitesse ni avec les même outils (Alan n'utilise pas BK alors que Marcello l'utilise).

        De plus, regarde un peu les statitiques [1], le plus gros contributeur est Alan Cox avec 207 submittions à Marcello [2], le second étant, de peu, Dave Miller [3] devant Marcello.



        [1] : http://linux.bkbits.net:8080/linux-2.4/stats?nav=index.html(...)

        [2] : http://linux.bkbits.net:8080/linux-2.4/user=alan?nav=!-(...)|index.html|stats|!+

        [3] : http://linux.bkbits.net:8080/linux-2.4/user=davem?nav=!-(...)|index.html|stats|!+


        A+
    • [^] # Re: Depuis le temps ...

      Posté par  (site web personnel) . Évalué à 10.

      C'est bon signe, cela veut dire que le noyau 2.4 tend vers son asymptote de perfection.
      A vrai dire, nous avons maintenant un OS GNU/Linux très stable, auquel il ne manque aucune fonction essentielle, ni même utile. Il n'y a donc aucune raison de se presser car la recherche de la fiabilité a définitivement pris le pas sur la recherche de fonctionnalités nouvelles.
      • [^] # Re: Depuis le temps ...

        Posté par  . Évalué à 10.

        Euh, excuses moi mais je vais te contredire.

        Si il est vrai que le noyau 2.4 est devenu tres stable, il lui manque encore pas mal de fonctions essentielles qui manquent.

        Je ne suis pas contributeur donc je ne critique pas, mais il faut avouer que :
        - Linux n'a pas une VM aussi performante que FreeBSD (meme si la VM de Rik et de Arcangeli sont devenues de bonnes VM)
        - Linux a encore des efforts sur USB 1.1
        - USB 2.0 ne fait qu'arriver (2.4.19), il va encore y avoir du boulot !
        - IEEE 1394 a encore des lacunes sous Linux
        - Temps de latence
        - Linux a du retard sur Windows (sic) au niveau Bench concernant les serveurs de fichiers, je ne me rappelle plus de cette lacune (un expert pourra dire davantage), et cela concernait le noyau 2.418 : c'etait le seul domaine ou Linux etait a la traine (largement) face a Windows XP (Le reste , Linux etait plus performant)
        - <REVE> Une meilleure implementation permettant aux editeurs/constructeurs de greffer des drivers Proprios comme sous Windows ou MAC OS, et eviter les incompatibilites quand on passe du noyau 2.4.17 au 2.4.18 (Exemple les drivers Olitec). Zut alors, des drivers Win 95 restent compatibles sous Win 98 ! Quand on passe du 2.4 -> 2.6 OK, mais faut pas exagerer !</REVE>


        Voili
        • [^] # Re: Depuis le temps ...

          Posté par  . Évalué à 10.

          > Bench concernant les serveurs de fichiers,

          Il me semble que c'était un problème avec Samba, que c'est vieu et que les derniers bench montre des différences très faible.

          > Une meilleure implementation permettant aux editeurs/constructeurs de greffer des drivers Proprios

          1) ce n'est actuellement pas voulu par Linux (bien que souvent les modules reste compatible au niveau binaire entre version mineure

          2) Si dans Linux on peut mettre plein de truc propriétaire bien caché, je ne suis pas sûre que le free software y gagne.
        • [^] # Re: Depuis le temps ...

          Posté par  . Évalué à 4.

          Linux a encore des efforts sur USB 1.1

          A quel niveau, au niveau contrôleurs ou au niveau périphériques?
          Pour le niveau périphérique, tant que les constructeurs ne supportent pas directement leurs produits sous Linux, il y aura toujours un temps de latence plus ou moins grand relatif au niveau d'accès aux specs et/ou d'intérêt d'écrire un pilote par ceux qui savent.

          - USB 2.0 ne fait qu'arriver (2.4.19), il va encore y avoir du boulot !

          Soyons déjà heureux que cela sorte avec cette release officielle et pas dans la prochaine version stable du noyeau, comme pour la 1.1. Les périphériques USB2.0 ne sont pas encore trop répendus (nouvelles cartes-mères,(dv|c)d-(rom|r[w]) et HD externes, scanner, contrôleurs USB 2.0 et quelques MP3Players) et ne concernent pas les périphériques de première nécessité comme clavier et souris.

          Il me semble que d'autres OS (W2K...) ne supportent pas en natif l'USB 2.0.
        • [^] # Re: Depuis le temps ...

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

          Il manque surtout d'éviter que les perf s'effondrent en quadriprocesseurs...

          nicO

          "La première sécurité est la liberté"

    • [^] # Oui mais ...

      Posté par  . Évalué à 10.

      On ne peut que se rejouir que le noyau avance a grands pas et soit teste sous bien des angles afin d'eliminer tous problemes.
      Malheureusement cela ne les elimine pas tous ...

      J'ai constate deux Pb lors du test de celui-ci que voici :

      -Le controleur IDE ATA100 secondaire Promise 20265 (ide2 & ide3) est inverse par rapport au primaire (comme si l'option "Boot off-board devices first" etait activee ce qui n'est pas le cas), mais si on inverse l'ordre des controleurs tout rentre dans l'ordre.
      Pq prendre la decision de considerer comme hda le peripherique de boot ?

      -Mon controleur ATA100 (encore) est sur la meme IRQ que ma carte son EMU10K, or des qu'il y a une activite disque XMMS produit un tres desagreable craquement comme si on ecoutait un disque raye.

      Je precise qu'aucun de ces deux Pb ne s'etait jamais manifeste auvec aucun des noyaux de la serie 2.4 jusqu'a maintenant, c'est bien uniquement le 2.4.19 qui prevoque cela, je preciserai meme depuis le rc3 pour le son et rc5 (mais bon c'est comme le final) pour l'inversion des controleurs.

      Si quelqu'un constate le meme soucis ... je ne pense pas etre le seul au monde a avoir une Promise 20265 et une EMU10K.
      • [^] # Re: Oui mais ...

        Posté par  . Évalué à 3.

        Et moi ma souris USB marche plus
        Le driver est loadé, mais quand je fait un cat
        du fichier de periphérique, ya rien qui sort.
        • [^] # Re: Oui mais ...

          Posté par  (site web personnel) . Évalué à 8.

          C'est normal, les mouses ont toujours eu peur des cats...

          -1, je sors...
        • [^] # Re: Oui mais ...

          Posté par  . Évalué à 5.

          ça, c'est normal, les dépendances ont changées, car un des modules USB a été séparé en deux.
          il faut bien vérifier que tu as tous les modules HID USB de compilés, recopier le .config de ton noyau antérieur ne suffit pas, il faut retourner dans la section USB de la config et cocher le "nouveau" module qui ne l'est pas par défaut.
          faites gaffe tout le monde avec ce truc, parce que je sens que ça va en gêner plus d'un.
          • [^] # Re: Oui mais ...

            Posté par  . Évalué à 3.

            En regle générale, quand on utilise un ancien .config, on fait un make oldconfig pour le prendre en compte.
            comme ca, si y'a des nouvelles options ou des options qu'ont changé, il pose la question, mais ne redemande pas ce qui n'a pas changé.

            de l'importance de lire les docs (README) fournies avec son noyau...
    • [^] # Re: Depuis le temps ...

      Posté par  . Évalué à 5.

      C'est vrai qu'il a mis beaucoup de temps à sortir, mais ce qui compte c'est qu'il fonctionne mieux que le précédent. En même temps, j'ai jamais vu un patch pour le noyau aussi énorme (5.5 Mo)
  • # Avec Debian?!?

    Posté par  . Évalué à 0.

    Quelqu'un a essayé de le compiler avec make-kpkg de Debian unstable?

    à chaque fois que je le fais, ça se termine avec des erreurs depmod du genre :
    depmod: *** Unresolved symbols in /root/kernel/linux-2.4.19/debian/tmp-image/lib/
    modules/2.4.19/kernel/drivers/char/rtc.o
    depmod: register_sysctl_table_Rab92f33e
    depmod: mod_timer_R1f13d309
    depmod: remove_wait_queue_Rd2d1a4c6
    depmod: __request_region_R1a1a4f09
    depmod: ioport_resource_R865ebccd
    depmod: proc_dointvec_R4d74e374
    depmod: create_proc_entry_R3045c2ce
    depmod: add_timer_Ra19eacf8
    depmod: add_wait_queue_R7539aa0e
    depmod: jiffies_R0da02d67
    depmod: fasync_helper_R536f5ddf
    depmod: free_irq_Rf20dabd8
    depmod: del_timer_Rfc62f16d
    depmod: sprintf_R1d26aa98
    depmod: remove_proc_entry_R24b93092
    depmod: schedule_R4292364c
    depmod: __release_region_Rd49501d4
    depmod: __wake_up_R2c77a2af
    depmod: printk_R1b7d4074
    depmod: kill_fasync_Rabddf4af
    depmod: no_llseek_R5ca5c314
    depmod: request_irq_R0c60f2e0
    depmod: misc_deregister_R055a03f1
    depmod: __pollwait_R701f80e6
    depmod: misc_register_R3629ec20
    depmod: unregister_sysctl_table_R78dab9ed

    qu'est-ce que je dois faire pour régler le problème?
    • [^] # Re: Avec Debian?!?

      Posté par  . Évalué à 0.

      Moi aussi j'ai ce problème. En le compilant avec la methode traditionnelle ca marche (make bzImage, make modules).
      • [^] # Re: Avec Debian?!?

        Posté par  . Évalué à 0.

        ... mais cette méthode n'est pas tellement pratique si je veux transporter mon kernel sur une autre machine...
        • [^] # Re: Avec Debian?!?

          Posté par  . Évalué à 1.

          Tu as bien raison, mais c'est le seul moyen que j'ai trouvé pour le moment pour compiler le 2.4.19!!
    • [^] # ais je tort?

      Posté par  . Évalué à -1.

      pour compiler avec make-kpkg comme je le fait, je pensais, qu'il fallait le kernel .deb de debian qui est (il me semble) un peu rangé de facon differente...
      mais bon, je dis ca a tout hasard, parceque moi j'attend les .deb pour installer le 2.4.19:)

      bref
      --
      a bas les anti-k et vive les anti-anti-k !!
      • [^] # Re: ais je tort?

        Posté par  . Évalué à 0.

        pour compiler avec make-kpkg comme je le fait, je pensais, qu'il fallait le kernel .deb de debian qui est (il me semble) un peu rangé de facon differente...

        Avec testing (sarge) make-kpkg fonctionne sans problèmes... Un bug dans unstable ne serait pas étonnant...
    • [^] # Re: Avec Debian?!?

      Posté par  . Évalué à 5.

      J'ai trouvé !!!
      Si tu installe modutils_2.4.19-1_i386.deb qui est sur incoming.debian.org la compilation marche.
      Ce package devrait arriver dans unstable ce soir je pense.
      • [^] # Re: Avec Debian?!?

        Posté par  . Évalué à 1.

        Super!! ça fonctionne maintenant!!
        J'attendais juste une mise-à-jour de ce type sur unstable... je me doutais bien que cela pouvait avoir un rapport avec modutils.

        Merci!
  • # Amélioration pour les portables

    Posté par  . Évalué à 8.

    Le noyau 2.4.19 apporte aussi le support du framebuffer pour les cartes neomagic dont sont équipés de nombreux portables.

    D'autre part, un patch pour le support XFS est disponible sur
    ftp://oss.sgi.com/projects/xfs/download/patches/2.4.19(...)


    Etienne
  • # support TV-Out pour la Matrox G450 !

    Posté par  . Évalué à 5.

    Avec ce nouveau noyau, devrait enfin être disponible
    un début de support pour la sortie TV de la Matrox G450 !
    Pour + d'infos, voir à l'URL

    http://www3.sympatico.ca/dan.eriksen/matrox_tvout(...)
    [matrox_tvout, j'arrive pas à terminer l'URL, :-(]
    Note: apparemment, aucun support n'a été fourni par Matrox pour développer ceci ...

Suivre le flux des commentaires

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