Journal Le noyau linux change de mode de développement

Posté par (page perso) .
Tags : aucun
0
22
juil.
2004
En résumé, et d'après ce que j'ai compris, le 2.6 n'est plus considéré comme une vrai branche stable, mais une branche ou on peut expérimenter.

La stabilisation du 2.6 sera donc maintenant confié au distribution.

http://kerneltrap.org/node/view/3513(...)

J'ai pas fait de dépêche, mon niveau en anglais et en histoire du noyau sont trop faible pour ça. Si quelqu'un en a envie, qu'il le fasse :^)
  • # heu

    Posté par . Évalué à 1.

    j'ai peut être mal compris, mais en tout vas j'ai rien vu de tel dans le lien ...
  • # Utilisation du noyau d'origine

    Posté par . Évalué à 8.

    Personnellement, j'utilise le noyau d'origine car au moins je suis sûr d'avoir une base commune stable de référence pour appliquer les patches que je juge nécessaire pour mes besoins, tel que le patch lck1.

    En fait, d'après le "thread" en question de l'article, le noyau officiel ne sera plus forcément considéré comme le noyau le plus stable, la stabilisation étant laissée aux distributions, donc avec leurs propres patches comme le fait remarquer un posteur. On risque de se retrouver avec autant de noyaux différents que de distribution, et le problème est que les patches diffusés publiquement, comme le patch lck1 pour ma part, risquent de ne plus pouvoir s'appliquer correctement car entrant en conflit avec d'autres patches "maison".

    Personnellement, je doute que ce soit une bonne chose pour l'utilisateur final qui maintient un noyau "propre" à partir d'une base stable officielle ...

    « Je vous présente les moines Shaolin : ils recherchent la Tranquillité de l'Esprit et la Paix de l'Âme à travers le Meurtre à Main Nue »

    • [^] # Re: Utilisation du noyau d'origine

      Posté par . Évalué à 2.

      L'utilisateur final "non avancé" de toute façon maintient son noyau à partir du site de sa distribution ...
      Il vaut mieux également quand on a une distribution (sauf pour Slackware à ma connaissance qui utilise les source officiels du noyau) récupérer les sources sur le site de la distribution pour recompiler son noyau, car chaque distribution apporte déjà ses modifs.
      Ca ne changera donc pas grand chose en pratique pour beaucoup de monde (sauf pour ceux qui passent leur temps à recompiler leur noyaiu en prenant des bouts de code à droite et à gauche ...).
      • [^] # Re: Utilisation du noyau d'origine

        Posté par . Évalué à 10.

        Ca risque d'induire encore d'avantage d'incompatibilité entre les distributions.

        Si chaque distributeur est incité à mettre ses propres patchs et si un 2.6.42 fonctionne totalement differement et est completement incompatible avec un 2.6.43, alors on court déplorablement vers un système de plus en plus fermé ou les distribution ne pourront plus fonctionner qu'avec un noyeau précis et sous un control unique. A ce niveau la autant achetter du windows. De plus la disponibilité pereine des noyeau des distributeurs est bien moins assurée que celle des noyeaux officiels (sur kernel.org tu peux recuperer a peu près tous les noyeaux officiels qui ont existé).

        Bref je ne vois pas ca d'un très bon oeil. D'autant que meme si les utilisateurs ne s'en rendent pas forcement compte, les changement d'API peuvent etre desastreux dans le user space et certaine applications sont aujourd'hui cassées en partie à cause de ca.
        • [^] # Re: Utilisation du noyau d'origine

          Posté par . Évalué à 3.

          >on court déplorablement vers un système de plus en plus fermé ou les distribution ne pourront plus fonctionner qu'avec un noyeau précis et sous un control unique

          Bof !
          Les noyaux des distribs sont déjà patchés dans tous les sens.
          Je pense que les mainteneurs du noyau se sont dit que maintenir un noyau stable avec les distribs qui patchent comme des folles ne servaient à rien.
          • [^] # Re: Utilisation du noyau d'origine

            Posté par . Évalué à 2.

            C'est ce que je voulais dire quand j'ai posté (Antion, je n'ai pas dit que c'était bien, hein, bien au contraire).

            Ce que j'espère quand même c'est que les différentes distribs feront un retour des paths appliqués de façon à les intégrer au noyau officiel (et qu'elles n'attendront pas que ce soien les mainteneurs du noyau qui aillent chercher les modifs).
        • [^] # Re: Utilisation du noyau d'origine

          Posté par . Évalué à 0.

          Il serait peut-etre temps au développeur du kernel de stabilisé/fixé l'API modules kernel.

          Meme si Linus s'est déjà exprimé sur ce sujet, je trouve cela regrettable d'avoir à recompiler certains modules pour switcher de version (meme minime)

          Selon Linus, si on a les sources cela ne devrait pas poser de problème... mais pour ceux qui ne les ont pas; et bien ils sont obligés d'installer une version du kernel compatible avec le module en question (le monde à l'envers quoi !)

          Je sais que Dell ou IBM ont crée une couche d'abstraction pour cela.
          Pour éviter ce genre de problème de compatibilité kernel/modules
    • [^] # Re: Utilisation du noyau d'origine

      Posté par (page perso) . Évalué à 5.

      on va alors assiter a une multiplication des :
      compatible RedHat 9.0 (ou autre), au lieu d'un compatible Noyau 2.6.4,....
  • # Numéro deux

    Posté par . Évalué à -4.

    Ça s'appelle un article ( et des courriers ) au second degré, des sous-entendus, des avis personnels de quelques individus, mais y'a rien à dire ....
  • # c'est complétement n'importe quoi

    Posté par . Évalué à 10.

    il va falloir faire des efforts en anglais mon gars et ne pas rapporter ce que tu as compris d'articles en faisant contre-sens sur contre-sens...

    Il y est dit que linux et andrew ne voit pas le besoin de se presser à créer une branche 2.7. Pas avant que divers choses soit merger d'abord dans la branche -mm puis eventuellement dans le 2.6 (comme MODULE_PARM etc...) ET puis seulement à ce moment là créer une branche 2.7 en laissant au fabriquant de distrib produire des patchs (qui seront mergés dans la branche stable 2.6) pour le stabiliser ....
    • [^] # Re: c'est complétement n'importe quoi

      Posté par (page perso) . Évalué à 2.

      Comme le 2.5 avec le 2.4 si jai bien compris. Rien de nouveau
    • [^] # Re: c'est complétement n'importe quoi

      Posté par (page perso) . Évalué à 5.

      Non, non, il a (presque) parfaitement compris ça:
      http://slashdot.org/article.pl?sid=04/07/22/0138244(...)
      Les deux liens sont relativement différents et j'avoue ne pas trop suivre:
      /. dit "le 2.6 sera expérimental... le coup du pair=stable, impair=instable c'est fini"
      KT dit "on va tester (patch mm) avant de les refiler au 2.6 si ça marche (eventually).
      J'ai l'impression que l'auteur du journal a découvert ça sur /., a traduit puis a donné le lien vers KT, en oubliant le lien vers /.
      • [^] # Re: c'est complétement n'importe quoi

        Posté par (page perso) . Évalué à 2.

        en fait ils disent qu'ils sont contents de leur travail d'équipe et que le 2.7 c'est pas pour demain...

        tant que ça peut faire progresser le kernel je vois pas trop où est le mal

        et puis on finira sans doûte par retomber sur l'alternance pair/impair lorsqu'il y aura la première release du 2.7

        mais tant que le duo Andrew/Linus fonctionnera bien ils ne verront pas l'intérêt d'appliquer une nouvelle fois la contraignante division en une branche dév et une branche stable
    • [^] # Re: c'est complétement n'importe quoi

      Posté par (page perso) . Évalué à 3.

      > dans la branche -mm puis eventuellement dans le 2.6

      Attention, "eventually" est un faux-ami, ça veut pas dire "eventuellement", mais "finalement", ou "par la suite".
  • # Re:

    Posté par . Évalué à 0.

    Vrai fausse nouvelle.
    C'était déjà le cas depuis un bon moment.

    L'upstream fait le travail de fond et les distributeurs corrigent les petits bobo qui restent. Corrections qui sont reportés à la version suivante de Linux.

    Ça fait déjà depuis longtemps qu'une nouvelle version de Linux n'est pas sortie uniquement pour corriger un trou de sécurité ou un bug. Ce sont les distributeurs qui font ça.

    Je trouve ça normal. Puis qui compile depuis les sources ?
    A part quelques "rebelles".

    Par contre, les fantasmes de fork par distribution, restent ...
    des fantasmes.
    • [^] # Re: Re:

      Posté par (page perso) . Évalué à 2.

      Puis qui compile depuis les sources ?
      A part quelques "rebelles".


      Moi, et je pense pas être un rebelle ni être le seul.
      <sondage a 2 balles> Et vous ? </sondage a 2 balles>
      • [^] # Re: Re:

        Posté par (page perso) . Évalué à 2.

        Moi aussi...

        Etant sous Nasgaïa qui est basée sur le noyau officiel sans aucune modif, je maintient mon noyau a jour avec les noyeau officiel, je suis encore au noyau 2.4 (j'ai essayée 2.6 mais pour l'instant je suis revenu au 2.4) et à chaque fois qu'une nouvelle version sort je dl le patche et je recompile. Jamais eu de problème avec.
        • [^] # Re: Re:

          Posté par . Évalué à 2.

          Normalement, il n'y a pas de problème pour passer au 2.6 sur Nasgaïa. Richard a fait une documentation et les Nbuilds qui conviennent.
          Cela dit, nous sommes d'accord pour dire que Nasgaïa est une exception de ce côté puisque nous n'avons pas encore fait d'outils permettant facilement les mises à jour de paquetages.
          Je rappelle quand même que Slackware ne patche pas les noyaux (à part failles de sécu).

          Pour rejoindre le file de discussion, je ne compile mon noyau que pour les distributions non-binaires et sur Nasgaia. Sinon, je prends les noyaux officiels de la distribution. Mandrake par exemple inclut dans les noyaux le driver eagle-usb sous forme de module, ce qui est extrêmement pratique.

          Par contre, j'ai un gros coup de gueule à faire sur les distributions (pas de nom, faites une recherche sur kerneltrap) pour lesquelles des patchs sont obligatoires pour pouvoir booter. C'est une connerie manifeste et je ne vois pas quelle pourrait être la raison ultime.
          • [^] # Re: Re:

            Posté par (page perso) . Évalué à 2.

            Mon retour au noyeau 2.4 n'est pas du a Nasgaia mais a mon materiel, j'ai eu du mal a le faire fonctionner avec le 2.4, et en ce moment je n'ai pas trop le temps de refaire tout le bouleau pour le 2.6. Alors vu que le passage au 2.6 ne m'apportait pas énormément, je me contente du 2.4 en attendant la Nasgaïa 1.1... (vivement le BS)
      • [^] # Re: Re:

        Posté par . Évalué à 1.

        Moi également (sous Slackware).

        J'avais tenté il y a longtemps avec une RedHat .... LA machine ramait à mort ...
      • [^] # Re: Re:

        Posté par . Évalué à 1.

        Moi aussi ( ca va faire beaucoup de r3b3lz je crois )
    • [^] # Re: Re:

      Posté par (page perso) . Évalué à 1.

      ben... on compile depuis les sources quand les kernels des distrib ne sortent pas assez vite... quand ils ne font pas encore ce qu'on veut...

      regarde le merveilleux travail du projet fedora legacy.
      c'est vraiment un projet que j'admire (pas seulement parce qu'il me retire une sacree epine du pieds...)

      pour le dernier kernel, je ne peux pas attendre la longue phase de test.
      je compille depuis kernel.org.

      autre exemple.

      si tu veux monter un firewall transparent, il faut patcher un noyau en accord avec le patch en rapport avec le projet ebtables...
      ta distrib ne l'inclu pas forcement (je ne connais pas l'ensemble des kernels des differente distrib...)
      donc, encore une fois...

      je suis pas un rebelle moi ?
    • [^] # Re: Re:

      Posté par . Évalué à 2.

      > A part quelques "rebelles".

      Des rebels utilisant fedora et qui aimerai bien que leur noyau n'Oops pas sur des cp massif sur de l'ext3 (2.6.6) ou qui trouve ridicule d'activer le 4:4 par defaut sur une distrib (je suis sur que 99% des gens utilisant fedora ont plus de 16GB de RAM ce qui justifie le cout a l'execution...) etc.

      J'ai jamais autant de problèmes qu'en utilisant le noyau des distribs qui "reparent les ptits bobo". C'est bizarre mais les vanillas ne m'ont jamais posés de problèmes...
      • [^] # Re: Re: Re:

        Posté par . Évalué à 1.

        > C'est bizarre mais les vanillas ne m'ont jamais posés de problèmes...

        ok ok ok.
        Les vanillas sont nickels et ce sont que les méchants distributeurs qui ajoutent des bugs dedans. C'est connu... D'ailleur dès qu'il y a un bug dans Linux une nouvelle version sort. Mais oui...
        Voir ça par exemple :
        http://linuxfr.org/2004/06/15/16537.html(...)

        Mais redevenons sérieux.

        Avant de vous énerver encore plus, je recompile aussi mon noyau car REGPARM ne marche pas avec un driver que j'utilise. Mais sinon je garderai celui par défaut.

        Tu vois quoi sur les forum :
        - Comment on recompile un noyau ?
        - tu copies /boot/config-.... /usr/src/linux, puis "make install"

        La majorité c'est ça. L'autre grande majorité ne recompile pas.
        Il m'arrive aussi de me tromper dans la configuration de mon noyau "customiser" alors que je compile linux depuis 1.2 (et à l'époque c'était pratiquement obligatoire).

        Cette "histoire" de recompiler le noyau, c'est comme pour apache. Avant il fallait recompiler apache, maintenant c'est plus nécessaire et ceux qui recompile apache sont rares. Avant il fallait recompile mplayer (obligatoire) et maintenant presque tout le monde fait "apt/yum install mplayer". C'est une tendance lourde et qui est absolument normale. Je me trompe ?

        Ce qui est arrivé aux autres (apache, mplayer, mod_ssl, etc) va arriver à Linux.

        > Des rebels utilisant fedora et qui aimerai bien que leur noyau n'Oops pas sur des cp massif sur de l'ext3 (2.6.6)

        T'as un rapport de bug ? C'était sûrement un noyau de développement (rawhide). J'ai utilisé tous les noyau FC2 depuis la FC2T2 et j'ai pas vu ce problème.

        Fedora est un peu particulier. Fedora est là pour "imposer" des nouvelles techno (dont 4kstack qui ne marche pas avec NVidia).
        Pour l'"esprit" Fedora, relire :
        http://fedora.redhat.com/about/(...)

        Si tu me trouves une distribution grand public ou entreprise qui dans le manuel d'installation ou d'administration indique "il faut recompiler le noyau", tu me fais signe.
        • [^] # Re: Re: Re:

          Posté par . Évalué à 2.

          > Les vanillas sont nickels et ce sont que les méchants distributeurs qui ajoutent des bugs dedans.

          Oui parmis la tonne de patch appliqués par mdk, rh ou SuSE y'en a qui merdent et d'autre merdes aussi dans le vanilla.
          J'ai eu des problemes avec ces trois distribs et repasser sur un vanilla reglait le problème. Maintenir de tels patchs n'est clairement pas evident, moi ce que je constate c'est qu'il y en a au moins un qui m'emmerde et qui fait se vautrer ma machine lors d'un bete cp (de quelque GO quand meme) ou mount.

          > http://linuxfr.org/2004/06/15/16537.html(...(...))

          Le problème c'est que tu mélange tout. Faire une update de sécu ce n'est pas grave, c'est normal et il y a peu de risque de pourrir la chose avec.

          > Tu vois quoi sur les forum :

          Je m'en fou je lis pas les forums des apprentis compileurs de kenelle.

          > C'est une tendance lourde et qui est absolument normale. Je me trompe ?

          Oui c'est une tendence lourde. On a tous debuter et cru qu'on gagnait 13,30495% de perf en compilant (et en cassant tout au passage). Je ferais un apt-get install de kernel-vanilla ca me derange pas non plus si les options sont pas débiles :-)

          > T'as un rapport de bug ?

          non pas le temps d'investiguer je pars en vacance demain. On verra au retour 'il est toujours present. Mais c'est 100% reproductible et peut probable que ce soit materiel vu que j'ai fait 5 x 20Go en XFS et 4 x 20Go en reiserfs et ca n'a jamais explosé (avec md5 pour verifier)

          > Si tu me trouves une distribution grand public ou entreprise qui dans le manuel d'installation ou d'administration indique "il faut recompiler le noyau", tu me fais signe.

          A aucun moment je n'ai parle de recompiler son noyau. Personellement j'en compile un paquet par ce que je m'interesse a certaines parties en devel ou fait de petites exprerimentations mais sur une machine de desktop je demande juste que ca fonctionne rien de plus rien de moins. Par contre quand tu vois des choix absurdent tel que 4:4 de base ca ne va pas inciter les gens a moins recompiler...
          • [^] # Re: Re: Re:

            Posté par . Évalué à 0.

            > ce que je constate c'est qu'il y en a au moins un qui m'emmerde et qui fait se vautrer ma machine lors d'un bete cp (de quelque GO quand meme) ou mount.

            Des fichiers de plusieurs Go, mon PC en bouffe. J'utilise mon PC pour enregistrer la TV et je te garanti que ça bouffe cette "saloperie" quand tu veux une bonne définition.
            J'ai un uptime tout frais car j'ai mis à jours (trou de sécurité qui n'est pas en upstream...). Mais avant j'avais plus de 30 jours. A 10 Go par jours (minimum) ça fait dans les 300 Go de donnée de brassé (ext3 avec 4:4 :-)). Chaque fichier fait dans les 2 à 6 Go.

            > Oui parmis la tonne de patch appliqués par mdk, rh ou SuSE y'en a qui merdent et d'autre merdes aussi dans le vanilla.

            Oui. Mais ...
            Si Mdk, etc ajoutent ces patchs, c'est pas pour rien. Globalement l'objectif est d'améliorer l'expérience de l'utilisateur. Si globalement ça ne fait qu'emmerder l'utilisateur, tu penses pas bien qu'ils ne vont pas se faire chier à maintenir ces patchs.

            Puis il y a une différence entre Linux upstream (le développement) et les distributions. Les distributions peuvent fait une patch "moche" mais qui corrige un bug très génant pour l'utilisateur.
            Linux (upstream) ajoutera ce patch lorsqu'il sera propre. Il ne faut pas qu'un hack "moche" soit la base des autres développements.

            C'est un élément important et même très important.
            Il faut bien différencier le développement (mettre en place une infrastructure solide) et la maintenance (corriger les petits bobo même si c'est fait de façon immonde).

            > Le problème c'est que tu mélange tout. Faire une update de sécu ce n'est pas grave, c'est normal et il y a peu de risque de pourrir la chose avec.

            Tu parles en "rebelle" (je suis un "rebelle", ne vous énervez pas). Tu trouves normal de demander à l'utilisateur final de suivre les failles de sécurité, de patcher un noyau, de recompiler ? Normal pour un "rebelle". Pas normal pour un utilisateur lambda.
            Depuis longtemps (au moins le 2.4), le Linux vanilla n'est plus un noyau "out of the box". C'est un noyau qu'il faut utiliser en étant abonné à la lkml (faille de sécurité, gros bug (genre le dernier ext3)).

            > non pas le temps d'investiguer je pars en vacance demain.

            Bonne vacance (enfoiré :-)).

            > Personellement j'en compile un paquet par ce que je m'interesse a certaines parties en devel ou fait de petites exprerimentations

            Le "rebelle touch". C'est respectable. J'utilise Fedora, donc je vais pas critiquer l'attitude.

            > Par contre quand tu vois des choix absurdent tel que 4:4 de base ca ne va pas inciter les gens a moins recompiler...

            Pssss...
            C'est pour Fedora ( relis http://fedora.redhat.com/about/(...) ).
            Puis ce patch est limite "vieux" (devait "trainer" dans FC1 (peut-être RH9 ?), est dans RHEL 3 depuis longtemps).
            Tu ne te sers pas de 4:4 et moi non plus. Mais ça interressent des gens. Pour les clients de Red Hat c'est important (sinon pourquoi Red Hat ce fait chié avec ça ?).
            Il faut que Red Hat sorte un noyau avec 4:4, un sans 4:4, un avec usb, un sans usb, un autre avec SeLinux, un autre sans SeLinux, etc...
            Non, c'est ingérable.

            Il faut que le noyau "de base" supporte le maximum de configuration sinon c'est l'enfer à maintenir, tester (trouver des testeurs pour 50 configurations de noyau différente pour chaque correction de bug/sécurité, c'est dure...).

            Tu fais une fixation sur le noyau mais je suis sûre que si tu regardais d'autres programmes tu verrais plein de truc que tu n'utilises pas non plus.
            Installes une Gentoo.

            btw, les patchs Red Hat se retrouvent très souvent dans le vanilla. Donc c'est débile pour toi quand c'est Red Hat "only" et c'est bien quand c'est dans vanilla.
            4kstack dans FC2 c'est nul. Mais maintenant que c'est dans 2.6.7 c'est bien. Logique... (tu peux m'expliquer ?).

            Pour que ça rentre en upstream (et fasse ton bonheur) et faut faire du travail en amont. Linus ne va pas accepter des patch intrusifs sans un minimum de test et de feedback des utilisateurs. Et Fedora est fait aussi pour ça.
            J'insiste, relis ça :
            http://fedora.redhat.com/about/(...)
            • [^] # Re: Re: Re:

              Posté par . Évalué à 2.

              > Tu ne te sers pas de 4:4 et moi non plus. Mais ça interressent des gens. Pour les clients de Red Hat c'est important (sinon pourquoi Red Hat ce fait chié avec ça ?).
              Il faut que Red Hat sorte un noyau avec 4:4, un sans 4:4, un avec usb, un sans usb, un autre avec SeLinux, un autre sans SeLinux, etc...

              Le problème c'est que ca sert a 0.000001% des utilisateurs de fedora (tu connais beaucoup de personnes assez debiles pour avoir 16..64Go de RAM sur un x86) et que ca plombe les perfs de tout le reste de facon non negligeable (ca depend surtout du type d'applis en fait). Dans ce cas oui ca me parait plutot approprie de proposer un noyau special pour les 3 personnes qui vont utiliser la chose.

              Les mecs de RH font de tres bonne choses, plus ou moins utile (mais toujours utiles pour certains de leurs clients :-). Ce que je remet en cause c'est de faire manger a tout le monde des patches "degeulasses" sur le plan esthetiique/technique alors que le besoin n'est pas la.
              • [^] # Re: Re: Re:

                Posté par . Évalué à 0.

                > Le problème c'est que ca sert a 0.000001% des utilisateurs de fedora

                Ah bon. Si tu le dis...
                N'empêche que des gens installent Fedora sur du 64 bits car 32 ça commence a être un peu limité.

                > tu connais beaucoup de personnes assez debiles pour avoir 16..64Go de RAM sur un x86

                Beaucoup non mais j'en connais. D'ailleur Windows a un équivalent de 4g/4g.

                > et que ca plombe les perfs de tout le reste de facon non negligeable

                Un bench ?

                > Dans ce cas oui ca me parait plutot approprie de proposer un noyau special pour les 3 personnes qui vont utiliser la chose.

                Rererererererererelire : http://fedora.redhat.com/about/(...)

                Red Hat fait une distribution gratos et en profite pour faire RHEL avec. Les utilisateurs de Fedora sont contents car c'est gratos et ça aide le logiciel libre et Red Hat est content car ça leur permet de développer RHEL qui rapporte du pognon et qui permet de développer le logiciel libre.

                Comme d'habitude, les gens veulent tout de Red Hat et sans contre partie. Ben faut pas rèver.

                http://fedora.redhat.com/(...)
                What is The Fedora Project?
                The Fedora Project is a Red-Hat-sponsored and community-supported open source project. It is also a proving ground for new technology that may eventually make its way into Red Hat products.


                C'est sur la homepage et au tout début. Tu es prévenu. Si ça te plait, tu passes ton chemin.
                Merci au revoir.
                • [^] # Re: Re: Re:

                  Posté par . Évalué à 2.

                  > N'empêche que des gens installent Fedora sur du 64 bits car 32 ça commence a être un peu limité.

                  Tiens le bon sens parle :-)

                  > Un bench ?

                  http://lkml.org/lkml/2004/4/6/84(...)
                  y'a eu d'autre discutions sur le sujet. A partir du moment ou tu as des applis qui syscall a fond ca fait assez mal.
                  • [^] # Re: Re: Re:

                    Posté par . Évalué à 0.

                    > http://lkml.org/lkml/2004/4/6/84(...)

                    Merci. Instructif.
                    Pour un usage desktop ça change rien (au pire 1 %).

                    > y'a eu d'autre discutions sur le sujet.

                    Pour ma part, Linux (upstream) n'a pas a intégrer ce patch. Ce patch est une optimisation temporaire car il y a encore beaucoup de système 32 bits.
                    Dans 3 ans tous les serveurs seront en 64 bits et ce patch ne sera plus nécessaire.
                    Le prix d'un système 64 bits a dramatiquement (dans le sens positif :-)) baissé.
            • [^] # Re: Re: Re:

              Posté par . Évalué à 1.

              Tu parles en "rebelle" (je suis un "rebelle", ne vous énervez pas). Tu trouves normal de demander à l'utilisateur final de suivre les failles de sécurité, de patcher un noyau, de recompiler ? Normal pour un "rebelle". Pas normal pour un utilisateur lambda.


              Il est normal a mon avis que l'utilisateur suive les failles de sécurité. Par contre effectivement, il est du ressort de la distribution de mettre à disposition les outils qui permettent de pallier à ces problèmes de la façon la plus simple possible.
    • [^] # Re: Re:

      Posté par . Évalué à 2.

      Ben euh, mon portable marche pas avec les noyaux de base... enfin il n'y a presque rien qui marche... alors je recompile avec les bonnes options... je suis un r3b3l, m'sieur ?
    • [^] # Re: Re:

      Posté par (page perso) . Évalué à 2.

      Moi pour avoir un support complet du chipset (pour l'AGP) + puce réseau de mon portable (SiS648 + SiS900).

      Suis en 2.6.8-rc2 pas pour le fun mais juste pour avoir la 3D ET le réseau en même temps.
      • [^] # Re: Re:

        Posté par . Évalué à 1.

        Oui il y a les sources de Linux et c'est très pratique.
        Oui il faut profiter des sources pour se sortir de "la merde".
        Oui à toussa.

        Mais n'empêche que dans la grande majorité des cas, c'est plus un "workaround", un "pis-allé" que la solution définitive.

        Je dis ça et des programmes j'en ai compilé des tonnes. Mais il faut être honnète. C'est actuellement une faiblesse de Linux (en grande parti du au manque de support des contructeurs de périphérique) d'être parfois obligé de compiler un noyau.
        La compilation d'un noyau ne doit pas être considéré comme la procédure "normal". C'est aussi pour ça que Linux a les modules. Pour ne pas avoir a compiler systématiquement un noyau.
  • # C'est grave...

    Posté par . Évalué à -1.

    Si ce que tu dis est vrai (j'ai pas le temps d'aller voir le lien), c'est grave....
    En effet, le travail es distributions n'est certainement pas de stabiliser le noyau.
    Si les devellopeurs du kernel font bien leur boulot, celui sur kernel.org doit etre stable.
    Le boulot des distributions est de compiler un version stable du noyau (avec eventuellement quelques patches qui doivent aussi etre considérés comme stable), de packager celui-ci et de faire agancer tous les autres programmes autour. Mais leur rôle s'arrête là. Il ne faut pas confondre le rôle des devellopeurs avec celui des distributeurs.
  • # Situation périlleuse....

    Posté par (page perso) . Évalué à 3.

    Je trouve que ce concept "le 2.6 doit être le plus rapide, riche en fonctionalités, laissant les distributions fournir des versions plus stables, tout en attendant que leurs patchs soient soumis dans les plus brefs délais", je trouve ce concept très dangereux.

    Je veux revenir à comme on a toujours fait, une version impaire en test surfing on the top of the wave et une version paire stable au possible.

    Laisser de l'instabilité en version paire, laisser les distributions "finir" le travail de stabilité, c'est livrer le kernel aux distribs, leur laissant toute latitude d'offrir une valeur ajoutée derrière leurs contrat de maintenance.

    La mission des dev noyau n'a a mon point de vue pas changé, elle doit poursuivre la voie dictée par linus.

    Jusqu'içi ça a parfaitement fonctionné qualitativement, aucune raison de changer.

    Linus doit parler pour clarifier le sujet

    Rafael
    • [^] # Re: Situation périlleuse....

      Posté par . Évalué à 1.

      Ça fait depuis longtemps que c'est comme ça (lis le lien du journal).

      Final stabilization is to be done by distributors (as happens now, really)

      Ça va s'accélérer.
      Je trouve ça assez bien. Par contre, le problème c'est pour les petits distributions. Il faudra plus de ressources maintenant.

      Par exemple devfs va être viré et Mdk utilise devfs. C'est maintenant à Mdk de maintenir devfs pour ses produits qui l'utilisent.
      • [^] # Re: Situation périlleuse....

        Posté par (page perso) . Évalué à 3.

        Mdk utilise devfs uniquement car udev n'était pas jugé assez avancé (sur un 2.6.3, je le rappelle). Quand udev sera mature, il sera utilisé par défaut.

        Ils ne sont pas masos au point de maintenir un truc deprécié si une meilleure alternative existe.
        • [^] # Re: Situation périlleuse....

          Posté par . Évalué à 2.

          > Ils ne sont pas masos au point de maintenir un truc deprécié si une meilleure alternative existe.

          Certe. Mais tu ne comprends.
          Mdk pour maintenir la 10.0 devrait maintenir devfs. Pas le chois.
          Je sais bien que les prochaines Mandrake ne font pas utiliser devfs.
  • # option de compilation: pas de code experimental

    Posté par . Évalué à 3.

    il existe une option de compilation: pas de code experimental

    donc est-ce vraiment un problème ?

Suivre le flux des commentaires

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