Christophe Fergeau a écrit 1255 commentaires

Le code Xine dans rhythmbox à la fin ne marchait plus convenablement, et il n'y avait plus personne pour le maintenir, donc après 1 an dans cet état, le supprimer complètement c'était pas délirant...

Il se trouve que personne te dira que rhythmbox est efficace pour ça, même pas les auteurs donc bon... Si tu veux un logiciel avec un système de playqueue efficace, prend muine comme exemple.

Un francophone ça se définit par "personne parlant français et possédant un PC sous linux" ?

> dans 5 ans free lance le freeportable telephone IP sur le wimax, avec consomation illimité jour et nuit, sms gratos

Avec un service client méchamment surtaxé et des téléphones qui marchent ou ne marchent pas pour une durée plus ou moins longue en fonction de la phase de la lune et du cours du pétrole ? Je préfère peut être rester chez mon opérateur actuel...

Pour pouvoir trouver les bugs, il faut un maximum de gens pour faire les tests et trouver ce qui ne marche aps. C'est encore plus vrai pour tout ce qui touche au matériel ou un changement qui marchera sur la machine du développeur fonctionnera parfaitement mais risque de ne pas marcher sur une machine avec un matériel légèrement différent.
Donc pour faire un débuggage correct, il faut un maximum de gens qui testent le noyau. Et un des seuls moyens que Linus a trouvé pour attirer un maximum de testeurs, c'est de coller un -rc aux noyaux très tôt, les numéros de version instables ou les -pre ayant plutôt tendance à faire peur à des testeurs potentiels.
Si tu as une solution miracle à ce pb et que ça te tient tant à coeur que l'étiquette -rc corresponde à ce que les gens qui écrivent des jolis livres sur le génie logiciel appellent -rc, je pense que tu devrais en parler à Linus...

Comme dit, utilise uniquement les paquets de ta distrib ;) Pour t'assurer que pkg-config ne va pas chercher les trucs que tu as compilé à la main, fais un make uninstall dans les sources des divers trucs que tu as installé toi même... Vire au moins /usr/local/lib/*glib* /usr/local/lib/*gobject* /usr/local/lib/pkgconfig/*.pc et pareil dans /usr/local/include.

Ce qu'il faut bien comprendre, c'est que ce qui est important, c'est que le brevet soit accordé par l'office des brevets. Si t'es une grosse boîte, que le brevet soit valide ou non, tu t'en fous complètement du moment que l'office t'as accordé ton brevet. Comme ça, tu peux poursuivre tes petits concurrents, et ils auront le choix entre te filer de la thune, ou bien essayer de prouver au tribunal que le brevet est invalide, mais ça leur coutera tellement cher que le petit concurrent en question mettra la clé sous la porte avant d'avoir prouvé quoi que ce soit.

> À part les trois pelés qui vont linuxfr, personne en France n'est au courant du problème posé par les brevets logiciels

Quand je vois que les articles sur les brevets logiciels étaient à la une sur lemonde.fr, je me dis que y a des chances que la problématique des brevets logiciels soit connue d'un public plus large que je ne le pensais.

J'avais cherche des algos de TRM a une epoque, et si l'algo utilise par musicbrainz est decrit dans un article accessible publiquement, c'est loin d'etre explicite sur le site de musicbrainz. et tu trouves encore moins de lien direct vers des explications sur l'algo. Et si l'algo est decrit qque part. tu vas ensuite te heurter a des pbs de brevets, il me semble que musicbrainz disait a une epoque sur son site que la partie trm pouvait etre couverte par des brevets et tout ca.

En fait, dans ma tête musicbrainz et relatable sont fortement liés, par une relation du genre "les mecs de musicbrainz ont monté relatable plus ou moins en même temps que la mise en place de musicbrainz". Je pense ne rien avoir lu qui disait explicitement ça, j'ai dû créer cette hypothèse de toute pièce sans rien avoir pour l'étayer, mais dire "on n'y peut rien, ça dépend entièrement de relatable, pas de nous", à mon avis c'est l'excuse facile ;)

La dernière fois que j'avais regardé, l'algo pour générer un identifiant (trm) à partir d'un morceau était complètement proprio : les applis libres calculaient un certain nb de paramètres à partir du morceau, envoyaient tout ça à un serveur, et c'était le serveur qui faisait le calcul et qui renvoyait l'identifiant du morceau. Le soft tournant sur le serveur était bien évidemment complètement fermé. Est-ce que c'est toujours le cas, ou bien est-ce que cette partie là a été libérée aussi ? Parce musicbrainz passait son temps à dire partout que c'était complètement libre, qu'on pouvait faire ce qu'on voulait, ... alors qu'en pratique ça n'était pas le cas...

> il parlait de la performance des applications en traitement d'image, ce qui depend uniquement de la puissance CPU

Sur une image de 10000x10000 en millions de couleur, tu vas bien torturer ton bus mémoire et les caches du proc, y a pas uniquement les ALU du CPU qui vont morfler...

> Mais non, une fois de plus ils sont partis faire leur cuisine dans leur coin ...

Ouais, les gars de trolltech par contre se sont plongés dans Xrender pour l'optimiser dans tous les sens quand c'était trop lent à leur gout...

> Et puis oui, Subversion résoud toutes les absurdités de CVS

Aux dernières nouvelles c'était pas encore ça pour tout ce qui concerne la fusion de branches (ie c'était aussi mauvais que CVS).

Le premier. Tu peux vérifier celui qui est utilisé avec 'which kopete'

« Un indice ... Qu'est-ce que je peux faire de plus avec mon Duron 800/512Mo que je ne pouvais pas faire avec mon Pentium 133/48Mo "à l'époque", soit il y a 8/10 ans ? »

Je parlerai essentiellement d'une grosse différence entre gtk1 et gtk2, c'est pango, qui permet d'afficher correctement du texte dans la plupart des écritures possibles et imaginables, quel que soit le sens dans lequel elles s'écrivent et tout ça, ce qui n'était pas vraiment le cas avec gtk1. Et forcément, c'est le genre de trucs qui ont un coût...

Y a tellement moyen de se tirer dans le pied avec les fonctions standards de la libc, et elles sont tellement limitées que je ne saurais que trop conseiller d'utiliser la glib (g_strdup et g_strdup_printf en particulier.

Si t'as pas installé ton kde à la main, un make install va mettre kopete dans /usr/local/ et ton kopete "d'origine" sera dans /usr, donc ils devraient être tous les deux présents en même temps.

Tu peux définir une variable MACHIN correspondant au chemin que tu veux aux cflags que tu mets dans ton Makefile.am, un truc du genre -DMACHIN="$prefix" (je me vautre probablement sur les guillemets, faut peut être passer "\"$prefix\"" ou une variation de ce style)
Sinon tu peux peut être le définir dans ton config.h à partir du configure.ac avec un AC_SUBST, mais je suis pas sûr à 100%
Le mieux pour des trucs "basiques" comme ça, c'est de regarder un projet existant (je prends totem en général).

LE pb de free à mes yeux, c'est l'absence totale de vraies personnes que tu peux joindre au téléphone et avec qui tu peux avoir une discussion et qui sont réellement compétentes pour résoudre les pbs "inhabituels" (ie ceux qui sont pas dans la liste des gars de la hotline, ou bien qui nécessitent un engagement/un geste commercial de la part de free). Donc quand ça marche, free ça marche bien, par contre en cas de pb, t'as absolument personne qui peut t'aider chez free...
Pour la petite histoire, j'ai eu un pb "inhabituel" chez orange aussi, la personne du service client a reconnu qu'elle avait aucune idée de ce qu'il fallait que je fasse, et m'a dit qu'elle me rappellerait le lendemain pour me dire ce qu'il en était, ce qu'elle a effectivemnet fait...

En tout cas ils sont beaux ;)
T'as les noms exacts des softs qu'ont été utilisés pour ça ? J'imagine que ça peut être extrait des divers noms que t'as copié, mais je sais pas exactement lesquels sont significatifs ;) (j'imagine latex + la classe beamer, mais quid de pfdetex par ex ?)

Oula, la glib 1.2.10 c'est pas gagné pour qu'elle soit corrigée... :-/

C'est quoi l'ABI pour toi si ce que tu décris en 3 ça fait pas partie de l'ABI ?
Pour info, depuis gcc 3.qqchose, l'ABI c++ est censée être stable et à peu près normalisée car basée sur une ABI définie par Intel (je crois) entre autres. Ca n'empêche pas qu'ils trouvent toujours le moyen de faire des petits changements (dûs à des bugs) d'une version à l'autre de gcc :(
Mais tout espoir n'est pas perdue pour une interoperabilité! :)
Le C c'est quand même bien pour ça, y a pas tous ces pbs...

« Ils ne pourraient pas faire une version pour les pays qui de reconnaissent pas [encore] les brevets logiciels ? »

Ca ne devrait pas être reformulé en « une version pour les pays où cette techno n'est pas brevetée » ? J'imagine qu'il peut y avoir des pays reconnaissant les brevets logiciels mais où Ms n'a pas déposé un tel brevet.

> Quand toutes les distribs utiliseront gcc4, toutes les applis seront "obligées" de compiler dessus..

J'aurais tendance à dire « vivement qu'*une* distrib utilise gcc 4, comme ça la plupart des applis compileront avec »

> comment feront ceux qui font une LFS et qui veulent compiler plus vite ? Patcher tous les programmes pour ça est tout sauf marrant !

Il suffit qu'il y ait une personne utilisant une LFS qui envoie un patch aux mainteneurs, comme ça tout le monde en bénéficie...

> (et profiter de -fvisibility)

Yay, -O3 -march=xxx -mcpu=xxx est mort, long vie à -fvisibility, lanouvelle option de la mort qui tue qui fait aller un 486 à la vitesse d'un p4!!