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/
- 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/
> Lire le journal (34 commentaires, moyenne: 3,1).
Vous avez demandé le commentaire #928489.



Hmmm...
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...
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...
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...
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...
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...
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...
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...
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...
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...
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...
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...
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...
> 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...
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...
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...
Il ne s'agit pas de l'API "externe" du noyau, mais son API interne. Aucune raison de changer de version majeure.
[^]Re: Hmmm...
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...
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.
:-D !!!NOUVEAU!!!
[^]Re: Hmmm...
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...
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...
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...
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...
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...
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...
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.
La mort est un phénomène naturel qui se produit par l'avalement répété de petites quantités de salive au cours d'une grande période de temps. - George Carlin
[^]Re: Hmmm...
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...
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 ?
La mort est un phénomène naturel qui se produit par l'avalement répété de petites quantités de salive au cours d'une grande période de temps. - George Carlin
[^]Re: Hmmm...
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...
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...
je pense surtout que c'est aux devs de s'adapter aux besoins utilisateurs et administrateurs.
[^]Re: Hmmm...
et le besoin identifié ici a été de fournir un système libre, voili voilou...
Windows has no users. It has hostages.