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...

[ Répondre ]

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.

[ Répondre ]

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.

[ Répondre ]

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.

[ Répondre ]

Ou une mauvaise volonté.

J'ai déjà signalé à plusieurs reprises la disponibilité de binaires pour Slackware sur la mailing-list. J'ai demandé à ce que soit rajouté une ligne avec le nom et l'adresse du projet dans le wiki. Je n'ai jamais eu de réponse. Je l'ai fait sur la mailing-list mais j'ai aussi contacté directement (au moins 2 fois) les responsables du site web.

Rien.

Alors, bon, moi je n'attends plus grand chose de www.enlightenment.org, SlackE17 va sur ses 3 ans, a été téléchargé plus de 26 000 fois (1,5To) et les slackeux savent bien trouver tout seul les packages. La publicité n'est plus nécessaire.

C'est néanmoins frustrant, à chaque fois que l'on parle de E17 et des binaires disponibles, de voir que SlackE17 est toujours ignoré alors que l'on parle d'autres distributions moins connues comme ArchLinux. Il faut croire que les développeurs d'E17 n'aiment pas Slackware, c'est pas possible autrement.

[ Répondre ]

Et Enlightenment DR17 \o/

Je suis tout juste en train d'envoyer la dernière version de SlackE17 sur les serveur de SourceForge. Ça faisait presque un an que c'était en maturation, il faut dire qu'il y a plus de 60 packages dans la version 20080504.

À voir sur :
http://slacke17.sourceforge.net/

Liste des packages :
http://slacke17.sourceforge.net/packages.html

Téléchargement :
http://sourceforge.net/project/showfiles.php?group_id=148645(...)

[ Répondre ]

Le captcha le plus efficace que je connaisse est celui-la :
http://hotcaptcha.com/

Il faut trouver quelles sont les 3 photos sexy sur un panel de 9 (il y a une version masculine aussi pour adonai<).

[ Répondre ]

Sauf que les insultes viennent toujours du coté d'OpenBSD. Si tu va voir la flamewar de décembre c'était symptomatique : Stallman qui faisait des mails courtois et Theo qui éructait des injures.

Alors que dans ton journal, tu écris :

les responsables de la nouvelle chanson [...] sont des gros cons.
cela aboutit à cette merde
le dessin qui accompagne la chanson est encore plus con
l'excellent projet OpenBSD est parasité par une poignée de connards

Et en même temps, tu critiques :
ces gens (qui) balancent leur venin sur d'autres membres de la communauté

Je ne sais pas trop ou tu veux en venir avec ce journal, mais je peux t'assurer que tu n'en sors pas grandi.

[ Répondre ]

Pour ceux qui s'y intéressent, il y a le projet slacke17 pour avoir un enlightenment E17, mais ça a pas l'air de trop bouger...
http://slacke17.sourceforge.net/

Il y aura une mise à jour pour la sortie de Slackware 12.1 et très probablement, nouveauté, des binaires pour Slamd64, le port x86_64 de Slackware.

[ Répondre ]

J'en sais rien, mais j'ai été surpris par le nom du développeur qui est placé exactement en plein milieu...

[ Répondre ]

Pourquoi pointer sur ce résumé du site linux-foundation alors que les sources de l'auteur de l'étude sont bien plus complètes ? ;-)

http://www.kernel.org/pub/linux/kernel/people/gregkh/kernel_(...)

[ Répondre ]

...je ne suis pas sur que ça règle les problèmes de freeze.

[ Répondre ]

Anyone who expects a source of power from the transformation of the atom is talking moonshine.
-- Ernest Rutherford

[ Répondre ]

> One-Click-Install (OCI)

openSUSE (je vous avais prévenu :) ) a introduis la technologie "One-Click-Install" dans le courant 2007, rétroactivement pour la version 10.2 (sortie en décembre 06), et de base dans la dernière version 10.3 (octobre 07).

Ou comment faire passer Novell pour une société innovante... Ils n'ont rien introduit, ils ont copié.

Un simple clic sur un lien web, et le package manager se lance et permet, après le mot de passe root, de cliquer sur "suivant" d'ajouter le dépot, le rafraichir, télécharger le logiciel et ses dependances, puis l'installer. A noter que OCI est le fruit d'un programmeur indépendant, et non des ingéneiurs de SuSE/Novell.

Ce système est dérivé du Click'N'Run, que Linspire (anciennement Lindows) a développé et utilisé depuis bien 5 ans. À l'origine non-libre, le code a été libéré il y a 2 ans.

On peut avoir des griefs contre Linspire et sa politique du libre, il n'empêche qu'elle est la première distribution Linux à avoir introduit le concept d'installation en un clic via le web, et cela, des années avant SuSE.

[ Répondre ]

C'est triste ton point de vue sur les projets d'hébergement de logiciels libres...

[ Répondre ]

Git a fusionné les fonctions de Cogito depuis plus d'un an. Ce projet ne sert plus a grand chose et n'est plus développé. Git a une interface simplifiée maintenant.

[ Répondre ]

Déjà, il faudrait être bien sur qu'un DSCM est ce qui est le mieux adapté à tes besoins. Les DSCM deviennent à la mode mais posent également des problèmes d'organisation. Ce n'est plus le logiciel qui centralise, mais une personne : tout le monde doit en être conscient. Il y a des projets vraiment communautaires, ou simplement avec plusieurs mainteneurs de "même poids", qui n'accepte pas cette philosophie. L'autre point, technique, est qu'avec un DSCM, tu auras plus de conflits à gérer qu'avec un SCM classique. Chaque personne pouvant faire sa sauce chez lui, cela complique les fusions de code.

Cela dit, que choisir entre Git et Mercurial ?

C'est probablement plus une affaire de gout qu'autre chose.

Pour ma part, j'ai choisi Git depuis un moment déjà. Il était plutôt complexe à utiliser directement à ses débuts mais il a fait d'énormes progrès dans le domaine. Pour moi, Git a passé l'épreuve du feu. Avoir été choisi pour gérer le kernel Linux, Xorg ou Wine est une preuve indéniable de qualité originelle, ou du moins acquise. De nombreux projets et forges l'on choisi. C'est rassurant : s'il y a des bugs, ils seront vite repérés et corrigés. D'autre part, les outils tiers se développent effectivement.

La critique que je ferai sur Git est le fait qu'il soit difficile de remonter dans l'historique d'un fichier. Le modèle de gestion est plutôt basé sur l'historique de tout l'arbre des sources par patches. Si tu veux suivre un seul fichier, c'est donc un peu compliqué. Si tu veux suivre l'évolution de ton projet dans sa globalité, c'est simple.

Je connais très mal Mercurial, je ne vais donc pas en parler ici. Je ne l'ai pas choisi car je ne suis pas très fan de Python (surtout sur un serveur) et je n'ai pas très bien compris l'intérêt de l'utiliser pour coder un DSCM sachant qu'on peut très bien faire sans. Mais bon, l'égout et les couleuvres...

[ Répondre ]

je dois faire un commentaire pour t'aider mais je n'arrive pas a saisir par ou commencer, étant donné que je maitrise dlfp et qu'il s'agit d'une application web
de rien

[ Répondre ]

http://musipedia.org/

Impressionnant, ça marche assez bien et c'est bluffant.

[ Répondre ]

Les trois mouvements de la sonate 17 pour piano "La tempête" de Beethoven.

L'interprétation de Wilhelm Kempff est de toute beauté.

[ Répondre ]