Matthieu Moy a écrit 3249 commentaires

Si j'ai bien compris, ce que tu appelles « groupe » est l'équivalent des cadres de ion3 : un rectangle de l'écran, qui affiche une seule fenêtre, mais qui en contient plusieurs (sous ion3, il y a une barre de titre qui fait des tabs quand il y a plusieurs fenetres).

Est-ce que tu penses que c'est utilisable par quelqu'un qui ne connait pas common-lisp ? (je connais l'Emacs-lisp, c'est pas si loin, mais ...)

Pour l'instant, je n'arrive pas à l'installer. J'ai pas essayé très fort, et si je suis convaincu de l'utilité, je suis prêt à y passer du temps, mais j'avoue qu'apprendre tout ça si c'est juste pour évaluer la bête, c'est assez rebutant.

> À propos, le repository darcs principal est inaccessible ? c'est délibéré je suppose,

Oui :

http://article.gmane.org/gmane.comp.window-managers.ion.gene(...)
I'm not going to make it easy for all the forkers...

Les dernières versions n'ont pas été publiées via darcs, et je ne connais pas de mirroir.

C'est une vraie question et elle mérite d'être posée.

Effectivement, je risque fort de rester sur la dernière version de ion3, mais je ne trouve pas ça très satifsaisant d'utiliser un truc plus ou moins abandonné en upstream. Enfin, là, c'est prèsque pire que « abandonné », l'auteur fait une crise de nerfs, il supprime des fonctionalités en insultant les gens qui les utilisaient, ... C'est une solution qui peut marcher un moment, mais par exemple, le jour où il y a un truc qui casse (typiquement, une mise à jour incompatible d'une dépendance de ion3 comme lua), c'est foutu. Et puis ça divise la communauté. Ion3 est configurable et extensible en lua, et on trouve pas mal de choses sur le web. Seulement, si moi je tourne avec la version X de ion3, que d'autres gens utilisent une hypothétique future version Y fournie en binaire seulement, et d'autres encore sont restés à la version Z qui date d'il y a un an parce qu'ils voulaient continuer à utiliser des trucs qui ont été retirés entre temps, la collection de scripts partagés par les utilisateurs n'a plus lieu d'être, tout est incompatible.

Et puis honnetement, vu la quantité de conneries que l'auteur écrit par jour en ce moment, en dehors de l'aspect technique, ça ne me fait pas envie.

Le langage python impose des règles de codage :
[ ] vrai
[ ] faux
?

>>> Ruby ou Python sont bien meilleur sur ce point la..
>> ces languages imposent d'avantage de rigueur et de normalisation dans la façon de coder.
> C'est faux. La normalisation n'est pas imposée par un langage, mais par ensemble de règles

Je ne sais pas pour ruby, mais essayes de faire du code mal indenté en Python, et reviens discuter après si tu penses toujours que la normalisation n'est pas imposée par le language dans ce cas ...

Le gros intérêt de ce genre de système, c'est que c'est activable pour un sysadmin, sans que les utilisateurs n'aient à s'en occuper. Par exemple, il y a des systèmes ou une restauration de backup se fait avec un truc du genre

$ cd .snapshot/hourly/12
$ cp machin-truc ~/la/ou/ca/devait/etre/avant

C'est très pratique pour réparer des erreurs. Par exemple, essayes « rm -fr .git/ », ou d'autres trucs plus vicieux genre « find . -quelquechose -exec perl -pi -e 's/mahin/truc/' » qui te corromp les fichiers de ton gestionnaire de versions, ou une connerie sur du code pas (encore) commité, ...

Par exemple, j'ai déjà eu à utiliser le système ci-dessus en arrivant en temps que formateur sur un site. Bon, tout est installé comme convenu dans le répertoire machin/bidule. Sauf qu'il y avait un cron job qui faisait rm -fr machin/bidule/ toutes les nuits :-(.

Ce qui est rigolo avec les firmwares, c'est que si le même firmware avait été dans une mémoire flash dans le périphérique, personne ne s'en serait rendu compte, et personne n'aurait râlé (on me soufle dans l'oreillette que c'est le cas pour les BIOS classiques).

Mais là, « c'est différent ».

Euh, launchpad n'a jamais fait partie d'ubuntu que je sache.

Si tu vas par là, tout les logiciels hébergés sur sourceforge (qui est dans le même cas que launchpad) sont non-libres.

Que le libéralisme « fair play » soit meilleur pour les pays du sud que le libéralisme « pas fair play », c'est pas un scoop.

Et c'est certainement pas un argument pour le libéralisme. C'est un constat qu'on peut faire pire que le vrai libéralisme, c'est tout.

> Cycle de Doha = cycle de négotiation devant l'OMC dans lequel les pays du sud
> (Brésil, Inde, argentine....) demandent un arrêt des pratiques protectionniste de
> l'europe et des Etats Unis.
> En d'autre termes, les pays du Sud demandent une libéralisation de l'agriculture.

Euh, pas vraiment.

On leur impose, via l'OMC, une agriculture libérale, c'est à dire que eux, ne peuvent pas être protectionnistes. Ils ne sont pas vraiment en position de force, et ils ne peuvent pas changer ça.

Mais finalement, les pays riches ne se gènent pas pour subventionner leur propre agriculture, éventuellement en bafouant les règles de l'OMC. Mais ceux-là, ils sont en position de force, et c'est pas le bangladesh qui va faire pression sur les USA en les menaçant d'embargot.

Le problème n'est même pas d'être libéral ou pas, c'est juste une question de concurrence déloyale. On leur impose le libéralisme, et on ne le respecte pas de notre côté.

Mais personnellement, que ce soit les gens des pays du sud, ou les spécialistes des questions de développement que j'ai vu dans des ONG françaises, j'en ai pas vu qui disaient que le libéralisme était bon pour les pays du sud. On n'a pas du voir les mêmes.

Au passage, le fait qu'un logiciel privé n'est ni vraiment libre, ni vraiment propriétaire est tout à fait admis par la FSF (qui n'a rien contre) :

http://www.gnu.org/philosophy/categories.html
« Private software »

Le problème de Launchpad, ça n'est pas que les sources ne soient pas distribuées, c'est que Canonical incite des projets libres à en devenir dépendants.

https://launchpad.net/faq
En gros, ça dit qu'ils aimeraient bien mettre Launchpad en open-source, mais que comme ils ont codé avec les pieds un truc monolitique avec des trucs confidentiels mélangés avec des trucs qui devraient être libres, ils peuvent pas.

http://news.zdnet.co.uk/software/0,1000000121,39286658,00.ht(...)
"I won't commit to a date for open-sourcing Launchpad. I think it's inevitable," he said. The reason Shuttleworth won't do so now: he doesn't want the project to fork into incompatible versions.

Bref, on dirait un peu qu'ils se cherchent des excuses, non ?

$ LANG=fr_FR.UTF-8 g++ toto.cpp
toto.cpp: In member function `void foo::f() const':
toto.cpp:7: erreur: passant « const foo» comme «cet» argument de « void foo::g() » écarte les qualificateurs

Euh, franchement, l'apprentissage d'une nouvelle théorie etc. soit tu n'as jamais essayé, soit c'est de la mauvaise foi.

Par exemple, avec darcs :

$ darcs get http://ton.projet.com/
#hack hack hack
$ darcs record
#hack hack hack
$ darcs record
# allez, j'ai assez contribué pour cette fois.
$ darcs send

J'avais jamais utilisé Darcs avant, je l'ai utilisé pour contribuer à ion3, le plus long a été de tapper « aptitude install darcs ». T'as vu où une nouvelle théorie ? Et avec SVN, tu aurais fait comment ?
(pour être honnete, les autres systèmes ne sont pas tous aussi simples)

L'énorme intérêt de ces systèmes, c'est justement pour le contributeur occasionnel. Tu n'as pas besoin d'avoir de droits sur le repository principal pour contribuer dans des bonnes conditions. Un « get », « clone » ou « branch » (selon l'outil) et tu es pret à contribuer, à faire une succession de patchs, autant de commit intermédiaires que tu veux, ...

Avec un outil centralisé, tu as le choix :

* Demander à l'admin d'avoir les droits pour commiter sur le SVN du projet. Si c'est pour une contribution de <100 lignes, je devine comment tu seras reçu.

* Oublier la commande « commit », oublier les branches, oublier qu'un gestionnaire de version sait faire autre chose que « diff » et « update ». Et si tu veux envoyer deux patchs séparés qui dépendent l'un de l'autre, je te souhaite bien du courrage.

Après, personnellement, je trouve qu'il y a trop de projets différents. Mais c'est la diversité qui a apporté des idées. À mon avis, il y a quelques grands qui vont émerger, et les autres qui resteront marginaux. Pour l'instant, les faits ont l'air de mettre Git et Mercurial en avant. On verra ce que l'avenir nous réserve.

Je n'ai jamais utilisé monotone donc je ne sais pas. Mais ce que disent les gens de Mozilla, c'est qu'ils ont eu de gros problèmes de perfs sous Windows.

> Il me semble que les problèmes de montée en charge de darcs viennent
> de son algo de gestion des conflits

Tout à fait (enfin, pas seulement des conflits je crois. Du merge en général plutôt). Darcs repose sur une théorie différente des autres (en gros, l'algo de merge basic, c'est trouver l'ancetre commun des deux révisions à fusionner, puis un coup de diff3 dessus). C'est à la fois puissant et gourmand en ressources. Quand on tombe sur un cas où Darcs part en vrille, il faut attendre que l'auteur trouve une meilleure théorie :-\.

Mais en échange, Darcs est relativement imbattable pour la selection des patchs un par un. Grosso-modo, un projet est un « tas » de patchs, et c'est Darcs qui réordonne les patchs comme il faut pour minimiser les conflits.

> Pas nécessairement. Mais si tu voulais utiliser le protocole de Skype, tu serais
> obliger de leur demander une licence.

Y compris si tu l'a fait par reverse-engineering, c'est ça le problème.

À l'heure d'internet, difficile de parler de logiciel sans parler d'intéropérabilité, et le brevet tue l'interopérabilité. Si c'était juste sur des algos utilisés en interne, je serais pas forcément contre, mais les algos utilisés purement en interne sont rares. 9 fois sur 10, l'algo utilisé se répercute quelque part sur un format de stockage, de transmission de données (par exemple, un super algo de compression aura forcément un impact sur le format de stockage, puisque c'est lui qui permet de changer la taille du fichier).

> La grosse base de google n'est pas en lecture seule, sinon il ne se mettrait pas à jour...

Oui, c'est évident qu'elle n'est pas en lecture seule stricto sensus.

Mais la lecture et l'écriture sont completement décorrélées. Une grosse partie du boulot, c'est quand même les recherches, qui elles, sont en lecture seule (enfin, ils logguent les requettes, mais c'est un boulot différent). Par exemple, on imagine très bien un système de cache distribué qui fait qu'une recherche faite à un instant t peut aller chercher dans la base de la veille, ou de l'avant veille. Chez une banque, c'est pas le genre de truc imaginable.

Oui, c'est à dire qu'un beau jour, tu vas te retrouver avec une distribution hybride, avec la moitié des paquets d'une distrib et l'autre moitié de l'autre.

D'ailleurs, je viens de réaliser que le « Sam » en question est le même que celui de

http://sam.linuxfr.org/

(D'ailleurs, des Linuxiens qui s'appellent sam, et qui parlent toujours de VLC, doit pas y en avoir 36 ...)

« stable » : à éviter, parce que d'ici quelques mois, tu auras oublié que tu avais « stable » dans ton source.list, et le jour de la release, un « aptitude update && aptitude upgrade » tappé machinalement pour faire une mise à jour va tout chambouler sur ton système.

Et a priori, c'est tout le contraire de ce que veut un utilisateur de stable.

Je m'en rend très bien compte, et c'est pour ça que les étudiants qui pompent, ça se voit ;-).

(genre les mecs qui changent tous les commentaires, mais qui laissent les fautes de frappe dans les noms de variables, ...)

>> Y avait-il vraiment besoin de remettre en cause le travail de plusieurs mois d'un
>> autre développeur du libre sur un driver qui n'était ni opérationnel, ni terminé
>
> Je ne vois pas ce que l'état du driver a à voir avec la choucroute. A partir du
> moment où le code est distribué, la licence doit être respectée.

Ouaip, ça me rappelle les excuses de mes étudiants : « non m'sieur, je suis pas en train de copier, je m'inspire juste de la version d'un autre étudiant, mais je fais moi-même. D'ailleurs, c'est une coincidence si on a le même code ».

Dans le jargon, on appelle ça un informaticien ;-).

Moi, justement, je la trouve pas mal sa réponse.

Les autres candidats font un exposé détaillé, qui serait intéressant si on leur demandait de nous convaincre que les brevets, c'est mal, et que les formats ouverts, c'est bien, mais je trouve ça super long (15 pages multiplié par le nombre de candidats, j'ai pas eu le courrage d'éplucher en détails).

Là, il donne son avis, je trouve qu'il y a à peu près tout ce qu'il faut, et seulement ce qu'il faut.

Ceci dit, je ne vais pas choisir mon bulletin de vote en fonction de ça...