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/
Journal Slackware, E17 et NVIDIA
5
mai
2008
# Stabilité
Posté par patrick_g (site web personnel) . Évalué à 4.
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 Jérôme Pinot (site web personnel) . Évalué à 5.
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 LaBienPensanceMaTuer . É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 Tonton Benoit . Évalué à 7.
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 aurel . Évalué à 6.
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 BAud (site web personnel) . Évalué à 4.
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 libre Cuauhtémoc . Évalué à 3.
D'autant plus, qu'avec le package dkms-nvidia, je n'ai JAMAIS eu à m'en occuper
[^] # Re: Hmmm...
Posté par GeneralZod . Évalué à 3.
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 libre Cuauhtémoc . Évalué à 1.
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 LaBienPensanceMaTuer . Évalué à 4.
[^] # Re: Hmmm...
Posté par GeneralZod . Évalué à 2.
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 libre Cuauhtémoc . Évalué à 1.
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 GeneralZod . Évalué à 3.
Si GNU/Linux sortira de sa niche ce ne sera pas grâce au pilote binaire de nVidia.
[^] # Re: Hmmm...
Posté par libre Cuauhtémoc . Évalué à 0.
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 GeneralZod . Évalué à 6.
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 Jérôme Pinot (site web personnel) . Évalué à 2.
C'est l'intérêt de la version patchée que je propose dans le journal.
[^] # Re: Hmmm...
Posté par totof2000 . Évalué à 1.
... 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 Olivier Serve (site web personnel) . Évalué à 9.
[^] # Re: Hmmm...
Posté par totof2000 . Évalué à 2.
[^] # Re: Hmmm...
Posté par Gof (site web personnel) . Évalué à 3.
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 LaBienPensanceMaTuer . É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 Aldoo . Évalué à 4.
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 Jérôme Pinot (site web personnel) . Évalué à 5.
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 Aldoo . Évalué à 2.
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 Jérôme Pinot (site web personnel) . Évalué à 4.
Ç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 GeneralZod . Évalué à 2.
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 plagiats . Évalué à 5.
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 GeneralZod . Évalué à 2.
* 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 plagiats . Évalué à 3.
[^] # Re: Hmmm...
Posté par libre Cuauhtémoc . Évalué à 0.
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 dguihal . Évalué à 4.
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 libre Cuauhtémoc . Évalué à 0.
[^] # Re: Hmmm...
Posté par Gniarf . Évalué à 0.
# tres bien ton blog
Posté par Anonyme . Évalué à 3.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.