Mathieu Segaud a écrit 136 commentaires

non

ouais, mais justement finalement, si tu lisais et comprenais ce qui a été dit, CM n'a JAMAIS eu besoin de ce truc inutilisable sur les phones qu'est Honeycomb. tu es gentil à toujours faire l'avocat du diable en permanence, c'est utile. Par contre l'avocat du diable n'a pas vocation a être malhonnête et à dire volontairement de la merde insensée.

non

et faut qu'elles soient honnêtes aussi. parce qu'y en a un paquet qui disent tout simplement pas qu'ils utilisent "ci" ou "ça" dans leur produit...

c'est sur le code de FreeBSD, pas NetBSD, que Darwin est syncé régulièrement gros chunks après gros chunks.

bah au moins, autotools/autocrotte ne te plombe pas la cross-compilation comme cmake le fait régulièrement

euh, dans ce mail non plus, je ne vois pas où il dit qu'il veut changer "make". Il dit juste, et c'est ni la première ni la dernière fois, que les mécanismes de prefetching sont pourris, et trop génériques, et qu'on finit tjs pas trouver des benchmarks, qui te montreront que c'est nuisible dans 50% des cas, et utile dans les 50%. A priori, ce qu'il peut reprocher au build system, c'est pas que c'est "make" qui est nul, mais que le system permet d'exhiber un cas complètement contre-performant de prefetching quand selinux est activé, dans le cas d'un compilation lancée après qq changements seulement dans l'arbre des sources (qui prend du coup des plombes).

la folie du rachat de Skype par Microsoft, c'est qu'en même temps, MS essaye de faire adopter son OS pour mobile... je me demande ce que font les spécialistes de la prospective chez Microsoft:
1) faire dire à Elop que Windows Phone destiné pour les prochains Nokia contiendra Skype
2) faire dire à Elop que Skype sur Windows Phone sera l'une des composantes les plus importantes du nouvel ecosystème "téléphonie" que Microsoft entend créer...

du coup les opérateurs ont fait retirer TOUS les tel windows phone 7 (y en avait pas beaucoup) de leurs boutiques: aucun opérateur n'acceptera jamais que Skype utilise leurs tuyaux...

En téléphonie, on utilise g711 A et B, mais c'est plutot le codec le moins en vogue. Celui que les opérateurs déploient dans leurs réseaux pour les protocoles VOIP, c'est g729 (breveté... :( ). Faut dire que g711 c'est "libre", mais par contre aucun opérateur n'en veut, à cause de la taille monstrueuse des paquets (la compression est très mauvaise en PCMA et PCMB (g711))
du coup je reste dubitatif quant à l'utilisation de ce codec, à mon avis, gsm ou speex seraient quand même moins gourmands et violents pour nos réseaux. Si les g711 sont pas trop gourmands côté cpu, c'est parce qu'ils sont pas optimisés pour une utilisation sur le réseau. :(

génial

trop de nucléaire => trop de sieverts

ça parait peu probable, .gov est celui de l'administration US. .gouvfr pour faire la différence entre le gouvernement français et les gouvernements des autres pays francophones serait plus logique

en fait, je pense qu'avant de continuer à baver des conneries, apprends à les écrire en français. parce que bon le mot communité n'existe pas en français. et puis il y a des règles d'accord dans cette langue. Toutes ces lacunes font craindre qu'un gamin de CM1 essaye de remplacer Schestowitz...
c'est plutôt pathétique en fait.

à un moment, faut se prendre par la main, et commencer à vivre sa vie. et oublier boycottnovell. après ça fait des gens bêtes.

pour preuve: ironique ou pas, écrire "Tant qu'on aura pas brûlé le dernier consultant en propriété intellectuelle" c'est s'exposer à se faire traiter d'à peu près tout ce qu'il est possible d'imaginer.

et ce, même un vendredi.

1) SVN ou CVS ne sont pas des systèmes de gestion distribuée, mais complètement centralisée
2) SVN, CVS, Git, et Mercurial sont très bien intégrés à GNU/Emacs, merci
3) RCS, SCCS, CVS, SVN sont dépassés

1) C'est pas le bon logo en tete de dépêche, c'est dommage
2) le nom du projet est DragonFly pas DragonFly BSD

résolver => résoudre c'est plus français.
et je ne compte pas les fautes de grammaire, mais parait qu'on a le droit d'en faire,...

ha ha ha
désolé mais à mon avis, le mainteneur de GCompris dans Debian ou Fedora a une très claire et bonne idée de la stabilité des différentes versions. Le problème que tu ne saisis pas c'est que quand on est mainteneur pour une distribution, le "distributed as is" n'est pas un blanc-seing, et on a la responsabilité de ce qui va se passer lorsqu'en uploadant un package _peu_ testé sur un dépôt officiel, on met en marche la mise à jour de 100000 machines réparties dans le monde entier. Ce mec qui soit-disant te censure semble selon moi te rendre service. Mais si tu es prêt à prendre la responsabilité de la grosse trentaine d'entrées dans le bugzilla de Debian concernant GCompris, tu peux soit devenir mainteneur Debian, soit demander à ce que Debian arrête de distribuer sous cette forme GCompris (mais rien ne les y obligerait) et t'en charger en préparant le .deb qui va bien.

Cependant, ce qu'on voit aussi dans ce troll, c'est que vous oubliez que le travail d'un packageur ne se résume pas seulement à rendre disponible tel soft pour telle distro: il s'agit dans le cas de Debian ou de Fedora, de séparer le résultat en groupes logiques (les différents paquets, +20 pour GCompris) pour ne pas installer de choses inutiles sur un système, et il s'agit la plupart du temps de corriger ou d'adapter certains détails à telle distro (il s'agit aussi souvent de faire respecter FHS et LSB que différents développeurs piétinent allégrement).

il s'agit aussi de corriger tous les bugs qui sont très certainement spécifiques à la distribution en question. Vu ton discours tu ne t'occuperas jamais de ces problèmes, et vu la taille de GCompris, tu n'en aurais pas le temps. Ce que tu préconises nuirait à la stabilité de ton logiciel à terme, puisque tu te priverais de la remontée des problèmes "distro"-spécifiques qui ne sont pas forcément le fait de la distro, et des corrections apportées par ce biais.

Ton discours étant plus que réducteur par rapport au travail d'une communauté qui tr rend plus que service, je me demande ce que tu attends vraiment de ce troll.

Or tu parles de "censure" à propos de quelqu'un qui se casse le cul pour que ton soft soit disponible proprement sur un système. Tu t'envoies des fleurs en parlant de codage multi-plateforme mais tu refuses de voir la diversité que ce multi-targeting impose.... la vie est faite de compromis, si t'es pas content de la manière dont ton soft est distribué par d'autres, fallait pas prendre la GPL comme licence...

tu racontes n'importe quoi. GTK+ n'a pas à lier statiquement les plugins chargés par dlopen(): c'est au build system d'un programme qui utilise GTK+ de le permettre, et de linker statiquement toutes les parties dont elle a besoin (peut avoir besoin) si on veut en faire un binaire statique. Par exemple avec Gimp ça marche, pourtant c'est un soft qui compilé en statique appelle plus souvent dlopen() que je ne respire.
ça signifie qu'une distribution "complète" de gtk+ va comprendre libgtk-x11.so.bidule, libgtk-x11.a (qui contient le code compilé pour être lié PLUS TARD dans un binaire statique si un utilisateur en a envie), les .la qu'il faut pour le faire plus facilement avec libtool et la meme chose pour les plugins (.so et .a, mais pour ça il faut que le "packager" l'ait voulu)

sauf qu'une QA team sainement constituée refusera tout paquet avec des bundles, parce que c'est une plaie pour la sécurité: une faille dans une librairie et ces 2000 paquets à regénérer.

il n'y a pas de solutions miracles. et la plupart des distributions ont des process à respecter concernant la "stabilisation" des logiciels. Elles prennent rarement le risque de mettre à jour tant qu'il n'y a pas eu assez de tests pour la déclarer stable. Ce que vous ne faites pas upstream (la QA), faut bien que qq1 le fasse pour vous. Soyez contents que des packageurs se fassent ***** à attendre avant de VOUS laisser vous ridiculiser avec une nouvelle version qui n'a pas d'intérêt supplémentaire à part de pouvoir doser le sucre qu'on met dans le café...

toujours ce problème de beurre et d'argent du beurre (et du *** de la crémière).

surtout que dans cette "acception", "template" ne veut surtout pas dire "gabarit", mais "patron"...

> L'avenir nous dira ce que cette division nous apportera, ceci-dit
> l'initiative est inétendue à mes yeux, je suis curieux de voir ce qui
> vas en découdre ! =)

aussi bien, je vais me faire moinsser, mais à un moment, il faut quand même mettre le "hola!".
Ce que tu as écrit, c'est pas qu'il y a des fautes ou non, c'est juste totalement pas français (au sens du sens)

"inétendue" ? (première fois que je vois ça) => inattendue
"ce qui vas en découdre" ? je connais pas cette expression dans ce contexte, désolé, je connais la variante "en découler", mais "en découdre", là désolé c'est pas français.

> j'ai confondu l'espace d'un instant pidgin et gajim

ça n'a guère plus de sens, empathy a déjà remplacé pidgin. faut retourner dormir à ce compte

c'est effectivement une feature "intéressante" mais pour ce type d'appli elle n'est pas fondamentale, pour la simple et bonne raison que Bundler est fait pour aider à la distribution d'un logiciel, en gérant au mieux (et là, c'est vraiment génial dans Bundler) les dépendances, et qu'on ne devrait JAMAIS distribuer un logiciel "stable" dépendant d'un dépot git qui par définition est constamment mouvant. Il n'y a bien que dans la communauté ruby qu'on n'oublie cette règle dont le seul but est la protection des utilisateurs (déboguer les problèmes quand on dépend d'un logiciel "mouvant" c'est l'enfer).

Evidemment, il suffit de distribuer un logiciel avec une utilisation correcte de Bundler quand on release une version "stable". Cependant, mon expérience avec Ruby est que c'est un enfer de maintenir une machine stable qui utilise Ruby intensivement (serveur d'applis rails), parce que la moitié des projets ruby ne releasent JAMAIS de tarballs versionnés et il n'y a qu'un dépot git (merci GitHub pour ça...)

en même temps, vous attribuez au système de gestion de paquets des défauts qu'il n'a pas. comment sous windows ils font pour distribuer des binaires qui marchent sur toutes leurs versions: parce qu'ils distribuent de manière dégueulasse le binaire ET les bibliothèques nécessaires à l'exécution de l'appli. Ou comment avoir 150 fois les mêmes bibliothèques dans 150 répertoires d'installation différents.

C'est possible sous n'importe quel GNU/Linux. Mais c'est demander par exemple, aux développeurs de Gimp de distribuer à la fois le binaire de Gimp, tout en embarquant aussi une version spécifique de GTK+, Glib, Pango, .... donc prendre la responsabilité de distribuer une version spécifique pour laquelle ils ne fourniront pas de support.

Sous Windows, ça risque pas de poser de problème, y a 4 logiciels qui utilisent ces bibliothèques. Sous un GNU/Linux, de quoi péter une installation "stable" de Gnome.
Et puis, je comprends qu'un utilisateur puisse se foutre de l'état de jachère des systèmes de fichiers de sa machine, des répertoires système, a priori, mais avoir 4 versions de GTK+ 2.0 (pas forcément de compatibilité binaire descendante) c'est le meilleur moyen de devenir prématurément chauve en séance de déboguage.

Dans le cas précis de FreeBSD, il existe une "distribution" (PC-BSD) qui utilise la méthode du "j'embarque tout dans le tarball", et qui à l'installation de chaque soft utilisant le protocole X (donc toute appli graphique), copie sa propre version de libX11, libXi, ... dans un répertoire précis utilisé par ce seul logiciel. Cela marche, mais pour les mises à jour de sécu, faut attendre que chaque logiciel est regénéré un tarball avec la librairie corrigée...

donc il y a de bonnes raisons d'utiliser telle ou telle méthode. Mais tout comme il est totalement con d'utiliser Debian Stable pour un bureau SI on veut pouvoir se la raconter "j'ai les derniers soft installés même pas testés par les développeurs", il est aussi complètement stupide d'utiliser Postgresql 9.0beta en prod sur une Debian Stable...