Journal Slackware, E17 et NVIDIA

Posté par  (site web personnel) .
Étiquettes :
0
5
mai
2008
Un petit journal pour vous parlez de :

- La sortie de SlackE17

SlackE17 est un ensemble de packages pour la distribution Slackware qui contient de très nombreuses applications en relation avec Enlightenment DR17, le gestionnaire de fenêtres. La version 20080504 est compatible avec la toute nouvelle Slackware 12.1 et contient pas moins de 64 packages. En plus du code de base, des bibliothèques et du gestionnaire en lui-même, vous trouverez de nombreux modules pour rajouter des fonctionnalités à votre bureau, des thèmes plutôt élaborés et des logiciels de toute sorte dont un gestionnaire de réseau utilisant uniquement les EFL.
Ce n'est pas encore Gnome ou KDE mais l'environnement s'enrichit.

- Le pilote graphique NVIDIA

Pour ceux d'entre vous qui, comme moi, tourne régulièrement avec un noyau très récent, vous devez avoir des soucis pour compiler le driver propriétaire NVIDIA à cause des changements d'API. Actuellement, le pilote a d'ailleurs presque 2 versions de retard sur le kernel. C'est pénible et ça montre bien l'incapacité de l'entreprise à fournir un support correct pour nos systèmes en plus de ne pas contribuer au libre.
Pour ne pas avoir à attendre la Saint Glinglin, j'ai patché le pilote et je me suis dit que ça pourrait servir d'en parler ici:

Les sources :
http://ngc891.blogdns.net/pub/projects/patches/nvidia-2.6.26(...)
Le patch :
http://ngc891.blogdns.net/pub/projects/patches/nvidia-2.6.26(...)

Il n'y a que le module noyau, vous devez installer en plus les bibliothèques avec le script de NVIDIA :
# sh NVIDIA-Linux-*-169.12-pkg2.run --no-kernel-module

Voila, pour finir, un peu de publicité pour mon blog, je crois que je l'ai mérité, non ? ;-)
http://ngc891.blogdns.net/
  • # Stabilité

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

    >>> Pour ceux d'entre vous qui, comme moi, tourne régulièrement avec un noyau très récent

    Effectivement ! Tourner avec un RC-1 c'est quand même un poil téméraire non ? J'ai vu sur la lkml qu'il y avait des problèmes avec dvb et que beaucoup de gens ne pouvaient même pas compiler cette RC-1.
    • [^] # Re: Stabilité

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

      D'un autre côté, si on ne peut pas le compiler, on est plutôt bien protégé des bugs :-)

      Le problème de la -rc1 c'est qu'elle est le produit d'une somme astronomique de patchs agglutinés en deux semaines. Il y a donc souvent des régressions, mais de là à avoir un noyau qui ne boote pas, ou même un "kernel panic"...

      Si tu lis la LKML, tu as du voir le troll fil de discussion initié par David Miller qui proteste parce que les changements vont trop vite et qu'il n'a plus le temps de tester. La position de Linus est plutôt inquiétante car il pense que le système actuel est satisfaisant sous prétexte que c'est le seul moyen d'effectuer suffisamment vite toutes les fusions de code. Mais est-il vraiment obligé d'accepter TOUT ce qu'on lui donne ? A-t-il peur de voir son noyau forké dans le cas contraire ?

      Quand on voit la quantité de code qui entre dans Linux, la fréquence des régressions, bugs, code qui ne compile pas, pour une branche dite stable, on est vraiment en droit de se demander où en est la démarche qualité. Et si Linus se satisfait du résultat, car au final la large base d'utilisateurs permet de remonter et corriger la plupart des bugs, on peut aussi se poser la question des trous de sécurité qui sont beaucoup plus difficiles à détecter.

      Seul espoir, que la branche -mm, qui va migrer vers linux-next, permette enfin d'avoir un vrai test des patchs. Andrew Morton a, sur ce point, une vraie volonté d'améliorer la qualité du noyau.
  • # Hmmm...

    Posté par  . Évalué à 2.


    C'est pénible et ça montre bien l'incapacité de l'entreprise à fournir un support correct pour nos systèmes en plus de ne pas contribuer au libre.


    Je crois qu'ici c'est plus les dev noyaux qui sont responsables en pétant régulièrement l'API ... c'est d'ailleurs le point le plus critiqué par les BSDistes intégristes dans les discussions kisaykalaplugrosse.
    En passant ... t'as envoyé ton patch à nvidia ?
    • [^] # Re: Hmmm...

      Posté par  . Évalué à 7.

      D'un autre coté personne n'a dit que l'API de Linux était stable !

      NVIDIA a choisi de développer son drivers hors du noyau, à NVIDIA d'en assumer la charge de travail supplémentaire que cela entraîne !
      • [^] # Re: Hmmm...

        Posté par  (site web personnel, Mastodon) . Évalué à 6.

        Par ailleurs NVIDIA semble bosser: un driver est disponible en version beta :

        http://www.nvidia.com/object/linux_display_ia32_173.08.html

        Trouvez le votre ici : http://www.nvidia.com/Download/Find.aspx?lang=en-us

        Quitte à etre bleeding edge, autant en profiter pour faire des bug reports ;)

        A., qui l'utilise sans problème.
        • [^] # Re: Hmmm...

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

          Quitte à etre bleeding edge, autant en profiter pour faire des bug reports ;)
          et concernant nouveau http://nouveau.freedesktop.org/wiki/ tu ne préfères pas faire du libre plutôt que de tenter des bugs dans un pov' forum où les dév nvidia se font insulter tant par les utilisateurs qui ont essayé la toute dernière version qui ne marche pas que celui qui n'a pas regardé que sa distribution fournissait leur blob ?
          • [^] # Re: Hmmm...

            Posté par  . Évalué à 3.

            Me concernant, je préfère avoir les effets bling bling de compiz, j'attends donc que nouveau ait des capacités techniques identiques au driver nvidia, et je lui souhaite bonne chance pour ça.
            D'autant plus, qu'avec le package dkms-nvidia, je n'ai JAMAIS eu à m'en occuper
            • [^] # Re: Hmmm...

              Posté par  . Évalué à 3.

              Si demain, nVidia annonce qu'il ne supporte plus ton GPU, tu seras bien content de trouver Nouveau.
              Ou bien tu rachèteras une nouvelle carte ? Ah ben non, quand un GPU n'est pas supporté par un pilote libre, on ne se fait pas chier à en racheter un autre, la logique veut qu'on fasse de même si son GPU n'est plus supporté par le pilote propriétaire.

              Si Nouveau n'avance pas aussi vite que tu le voudrais, c'est parce qu'ils ont besoin de petites mains pour coder, tester, faire des rapports de bogues.
              • [^] # Re: Hmmm...

                Posté par  . Évalué à 1.

                Franchement, cela est déjà arrivé où nvidia avait des soucis à supporter un nouveau noyau (2.6.15 je crois), et j'étais resté à l'ancien noyau qui marchait sans soucis.
                si Nvidia arrête le développement de linux, je pense que je rachèterais une carte qui développe un driver 3D sous linux, et si cela n'existe pas, j'irais vers macOS X

                quant à nouveau, je comprends bien les lenteurs du devels, mais je n'ai pas envie de l'utiliser, et je préfère utiliser le pilote binaire, on va pas me forcer non plus à utiliser nouveau, j'espère.
                • [^] # Re: Hmmm...

                  Posté par  . Évalué à 4.

                  Ce bon vieil intégrisme des libristes (mot qui tend limite à devenir péjoratif) qui consiste à vouloir que le monde entier n'utilise que du libre....
                  • [^] # Re: Hmmm...

                    Posté par  . Évalué à 2.

                    Quel intégrisme ?
                    Libre à chacun d'installer ce qu'il veut, mais si on veut que les systèmes libres puissent accéder au grand public, il est impératif d'éradiquer les pilotes propriétaires au profit de pilotes libres.
                    Tant qu'on trainera des pilotes mal fagotés, mis à jour au petit bonheur la chance, GNU/Linux ne sortira pas de sa niche.
                    • [^] # Re: Hmmm...

                      Posté par  . Évalué à 1.

                      Libre à chacun d'installer ce qu'il veut, mais si on veut que les systèmes libres puissent accéder au grand public, il est impératif d'éradiquer les pilotes propriétaires au profit de pilotes pouvant intégrer toutes les capacités du matériels, qu'ils soient propriétaire,ou mieux: libre.
                      Tant qu'on trainera des pilotes pour carte 3D ne pouvant pas exécuter toutes les extensions glx, GNU/Linux ne sortira pas de sa niche.
                      • [^] # Re: Hmmm...

                        Posté par  . Évalué à 3.

                        Tant qu'on continuera à ne pas soutenir les pilotes libres et à pousser les constructeurs à libérer les spécifications, il n'y aura pas de pilotes libres avant longtemps.
                        Si GNU/Linux sortira de sa niche ce ne sera pas grâce au pilote binaire de nVidia.
                        • [^] # Re: Hmmm...

                          Posté par  . Évalué à 0.

                          mais je soutiens les pilotes libres.
                          Pilotes souris/clavier: pilote libre
                          Pilote imprimante: pilote cups
                          pilote scanner: xsane

                          JE lles utilise plutôt que d'hypotetique drivers propriétaires je doute de leurs existence) car ceux çi satisfont à mes besoins, ce qui n'est pas le cas de Nouveau.

                          Le besoin utilisateur devraient être la première préoccupation des développeur plutôt que la compatibilité des licences
                          je pense que si linux ne perce pas, c'est qu'il y a trop de masturbation intellectuelle sur les licences.

                          chacun son point de vue
                          • [^] # Re: Hmmm...

                            Posté par  . Évalué à 6.

                            > Le besoin utilisateur devraient être la première préoccupation des développeur plutôt que la compatibilité des licences

                            Les questions sont intimement liés, tu ne peux pas améliorer l'expérience utilisateur avec un pilote fermé.
                            Quant un pilote libre est inclus dans le noyau, il est supporté à vie, il sera amélioré. Même un pilote libre non inclus dans le noyau tout pourri est mieux dans le sens où on peut l'améliorer et plus tard l'inclure dans le noyau. Avec un pilote binaire, c'est impossible.
                            Si tu n'as pas remarqué, je parle principalement des pilotes et non pas des applications, parce que de fait pas de pilotes libres == pas d'expérience utilisateur viable. C'est véritablement le dernier frein à l'expansion du libre.
                            On est capable de construire aujourd'hui des machines entières reposant sur du matériel ayant des pilotes libres, la pression s'alourdit sur les mauvais joueurs comme nVidia.

                            Le libre ce n'est pas de la branlette du cerveau, c'est avant tout un humanisme, ou le partage des connaissances et des sources est central, la licence n'est qu'un garde-fou rien de plus.
                            nVidia refuse de partager ses sources et fait un gros doigt à la communauté libriste, je ne vois pas pourquoi on devrait les soutenir.
        • [^] # Re: Hmmm...

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

          Ce pilote en beta ne supporte que les noyaux <=2.6.25 mais pas le 2.6.26 qui est actuellement en développement.

          C'est l'intérêt de la version patchée que je propose dans le journal.
      • [^] # Re: Hmmm...

        Posté par  . Évalué à 1.

        D'un autre coté personne n'a dit que l'API de Linux était stable !

        ... ce qui est stupide pour une API ...... Alors apres, effectivement on peut casser la compatibilité mais dans ce cas on incrémente la version majeure du noyau ....
        • [^] # Re: Hmmm...

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

          Il ne s'agit pas de l'API "externe" du noyau, mais son API interne. Aucune raison de changer de version majeure.
          • [^] # Re: Hmmm...

            Posté par  . Évalué à 2.

            Peux-tu expliquer un peu la différence entre "api externe" et "api interne", et pourquoi dans ce cas ça ne pose pas problème de la changer souvent sans garder de compatibilité ? Je n'arrive pas à comprendre l'intéret ...... Au passage, si ce n'est pas gênant, pourquoi les drivers propriétaires ont-il du mal a s'adapter ?
            • [^] # Re: Hmmm...

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

              API externe c'est l'API entre les applications et le noyaux. La compatibilité est gardée ici.

              Mais l'API interne utilisée à l'intérieur du noyaux et de ces modules ne garentil pas la compatibilité.
              La raison est que si on souhaite garder la compatibilité ça ralentirais le développement, puisqu'on ne pourrais pas changer certains trucs.
              Et ce n'est pas grave puisque les changement d'API sont tout de même assez faibles, et donc il est souvent très facile de mettre à jour... quand on a les sources.
      • [^] # Re: Hmmm...

        Posté par  . Évalué à 2.


        D'un autre coté personne n'a dit que l'API de Linux était stable !

        C'est rigolo cette tolérance à l'inconstance de GNU/Linux qu'on ne retrouve pas pour Windows (combien de fois les libristes se sont moqué de vista à cause de ses changements internes rendant le matos non compatible faute de driver approprié ... et ce coup ci c'était pas la faute des constructeurs ...).
        De plus, si il n'y avait que l'API interne qui n'était pas stable ça irait ... mais il me semble que l'ABI n'est pas beaucoup beaucoup mieux ce qui est tout de suite plus facheux (et paf le troll issu de la gueguerre BSD vs GNU/Linux).


        NVIDIA a choisi de développer son drivers hors du noyau, à NVIDIA d'en assumer la charge de travail supplémentaire que cela entraîne !

        La je dois avouer que je comprend pas ... que tu développes un LKM ou un driver en direct dans le kernel ça change pas grand chose ... et le driver aurait été pété de la même façon.

        Pour info, j'utilise un système exempt de tout soft proprio .... c'est juste que cette intolérance et ces exigences me semblent particulièrement déplacés: une boite tâche développer un driver pour notre OS qui reste très minoritaire, on trouve encore moyen de lui demander d'être aussi réactif que les devs kernel, de lui demander de tout libérer. Prochaine revendication une carte graphique offerte à ceux qui pourront prouver qu'ils tournent sous un OS libre ?
        • [^] # Re: Hmmm...

          Posté par  . Évalué à 4.

          Ben l'inconstance des API et ABI n'est pas un problème dans le monde du libre : au mieux on recompile (ABI), au pire on modifie là où les API ont vraiment changé.
          Dans le monde du propriétaire, on n'a pas cette ressource-là, donc garder une compatibilité ascendante des interfaces est vital.
          • [^] # Re: Hmmm...

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

            l'inconstance des API et ABI n'est pas un problème dans le monde du libre

            Je crois que tu sous-estimes légèrement la difficulté de la tache. Il y a de plus en plus de projets libres qui n'arrivent plus à suivre le rythme de développement du noyau.

            Juste un exemple : le projet grsecurity, qui essaie de renforcer la sécurité du noyau, vient de jeter l'éponge : trop de travail. Ils vont se rabattre sur le noyau LTS d'Ubuntu. Tant pis pour les autres. http://grsecurity.net/pipermail/grsecurity/2008-May/000927.h(...)

            Ce n'est pas un problème libre/propriétaire, car au final, NVIDIA sort bien un nouveau driver régulièrement ; mais force est de constater, que sans l'appui financier d'une entreprise, il deviendra de plus en plus difficile de contribuer sérieusement au noyau. Je ne parle pas de coder des nouvelles choses, mais bien de maintenir son code.

            Le diff entre Linux 2.6.20 et 2.6.25 fait 143Mo (19 319 patches), ce qui fait une moyenne (je ne l'ai pas inventé :-) de 42 patches par jour, ça donne de quoi s'occuper...
            • [^] # Re: Hmmm...

              Posté par  . Évalué à 2.

              On est d'accord, le libre ce n'est pas non plus de la magie, hein !
              C'est juste que dans le proprio, le changement d'API c'est la cata, alors que dans le libre on peut y faire quelque chose sans être la boîte qui développe le pilote ou le logiciel tiers, même si c'est du boulot, ok.
    • [^] # Re: Hmmm...

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

      Je crois qu'ici c'est plus les dev noyaux qui sont responsables en pétant régulièrement l'API

      Ça devient une tradition de casser des choses à chaque nouvelle sortie de 2.6.X. Je n'ai rien contre les changements d'API, mais ça devrait, autant que possible, se faire dans une branche de développement et pas dans une branche stable. Parce que là, c'est "marche ou crève".

      En passant ... t'as envoyé ton patch à nvidia ?

      Non. D'une part parce que ce que j'ai fait est trivial, ne s'applique qu'au 2.6.26-rc et n'a surtout pas la prétention de remplacer le pilote officiel.
      C'est juste un hack pour ceux qui ne veulent pas attendre 2 ou 3 mois.
      • [^] # Re: Hmmm...

        Posté par  . Évalué à 2.

        C'est au propriétaire de s'adapter au libre et non pas l'inverse.
        nVidia a fait le choix de développer un pilote non-libre et de ne pas collaborer avec les développeurs noyaux. A eux d'assumer leurs responsabilités, et nVidia a largement les moyens de payer un développeur à temps complet pour suivre les changements du noyau et adapter le pilote en conséquence.

        > Ça devient une tradition de casser des choses à chaque nouvelle sortie de 2.6.X.

        ça a toujours été le cas ! La branche impaire servait à introduire les changements profonds dans l'architecture du noyau, les changements graduels se sont toujours fait dans la branche paire.
        Le fait est que le noyau 2.6 est relativement mature, la branche impaire n'a pas de sens à moins de vouloir révolutionner le noyau Linux -intégrer le support du temps réel nativement ?-
        • [^] # Re: Hmmm...

          Posté par  . Évalué à 5.

          C'est au propriétaire de s'adapter au libre et non pas l'inverse.

          Règle d'or édictée par qui ? Les dev du libre ?

          et si les dev du proprio édictent la règle suivante :
          Nous on fait notre truc, c'est au libre de s'adapter au propriétaire et non pas l'inverse. ?

          On est bien avancés maintenant.
          • [^] # Re: Hmmm...

            Posté par  . Évalué à 2.

            Tu poses mal l'équation:
            * d'un côté le logiciel libre: source accessible, ouverture.
            * de l'autre le logiciel propriétaire: source non accessible, fermeture.
            Explique-moi comment le logiciel libre pourrait s'adapter au logiciel propriétaire dans ces conditions ?
            Quant un pilote binaire casse la gestion d'énergie dans le noyau, tu fais comment pour corriger ça ? Tu fais du reverse engineering et tu envoies ton patch en binaire ?

            Si on poursuit la logique de ta réflexion, ce serait pas à Microsoft de s'adapter à la norme ISO mais à l'ISO d'adapter sa norme au tas de merde de Microsoft. Oups, avec OpenXML, c'est déjà le cas.

            Si on suivait cette logique, le noyau Linux serait devenu une vraie poubelle avec 40,000 APIs et je ne sais combien de hacks pour supporter tout les pilotes binaires. Même Anton Blanchard finirait par s'arracher les cheveux pour déboguer une merde pareille.
            • [^] # Re: Hmmm...

              Posté par  . Évalué à 3.

              J'ai pas dit que l'un ou l'autre avait raison et c'est justement mon point : à rejeter le travail sur les autres, rien n'avance (désolé d'être cru). Qui a besoin de quoi dans cette histoire ? Les utilisateurs d'accélération 3D. Ca l'avance à quoi l'utilisateur qu'on lui dise "c'est pas notre faute, c'est la faute à nvidia" ? Ou "ce n'est pas à nous de le faire c'est au fabricant" ? Au final, l'OS est fait pour qui ? Pour ses développeurs ou pour ses utilisateurs ?
              • [^] # Re: Hmmm...

                Posté par  . Évalué à 0.

                Néanmoins, s'i lfalalti s'adapter à tous les fournisseurs (nvidia/Ati etc...) qui fournissent des drivers binaires, ça en ferait du boulot pour un nouveau noyau.
                Par contre, le driver bêta fonctionne sans aucun problème..
                Avec ce noyau ,j'ai même pu redécouvrir xfce (kde est en grand chantier du côté de cooker, et comme prochainement, j'aurais pas le temps de bugreporter, je préfère utiliser autre chose).
          • [^] # Re: Hmmm...

            Posté par  . Évalué à 4.

            Pour autant que je sache C'est NVidia qui fait un driver binaire pour le noyau linux, et non pas les développeurs linux qui font un noyau autour du driver Nvidia

            La règle est simple pourtant, la majorité a toujours raison ;-)

            Sur une plateforme GNU/Linux ou xBSD c'est au proprio de s'adapter au libre, par contre sur un plateforme proprio ( Windows, OSX, ...) C'est l'inverse. Ce n'est pas vraiment un règle écrite/imposée , mais les faits sont là.
        • [^] # Re: Hmmm...

          Posté par  . Évalué à 0.

          je pense surtout que c'est aux devs de s'adapter aux besoins utilisateurs et administrateurs.
          • [^] # Re: Hmmm...

            Posté par  . Évalué à 0.

            et le besoin identifié ici a été de fournir un système libre, voili voilou...
  • # tres bien ton blog

    Posté par  . Évalué à 3.

    j'aime l'indicateur du crude oil :) hop adopté. si tu as la meme choses en plugin kde transparent je prend

Suivre le flux des commentaires

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