Je te trouve bien peremptoire sur "buildsystem toujours en vrac". Tu t'en occupes pour savoir ce qu'il y a comme probléme ? Que je sache non, mais c'est pas grave, personne va vérifier de toute façon.
"tout contrib dans /opt", encore une fois, ça sent le même qui croit maitriser. Comme si changer de repertoire était la solution. C'est bien évident que ce qui géne, c'est d'avoir /usr, pas d'avoir /opt. Le simple fait d'avoir 3 lettres qui changent ça va tout changer.
Ah oui, et puis retirer de la QA sur les One et sur les Free, ça va surement aider la distribution. Tu as d'autres idées du même genre que "faire moins de test pour avoir plus de qualité" ?
Et tu t'es pas dit que la QA fait sur les Ones et sur la Free, ç'est toujours de la QA en moins pour les versions pros ?
Franchement, je sais que samedi, c'etait pas loin de vendredi, mais quand même...
Yvan M., tu ne sais pas être discret. Mais peut être que tu veux savoir ce qui t'a perdu, malgré le changement d'ip, de pseudo et de mail ?
Déjà, c'est facile. Les pseudos de gens que tu as donné sont tous des pseudos venant de mandrakefr. Donc j'ai supposé que tu étais un habitué. J'ai fait rapidement un peu de datamining sur les logs pour situer quelqu'un présent dans les années 2004/2006, au moins. Ça nous laisse un certain nombre de gens.
Ensuite, le style. Non pas le coté "je donne l'impression de savoir de quoi je parle, mais faut pas fouiller trop loin", même si j'aurais pu m'en servir. Mais je n'ai pas eu besoin de ressortir les théories complexes d'identification à partir du style ( http://portal.acm.org/citation.cfm?id=1251313 ), j'ai juste repris le datamining sur les fautes d'orthographes courantes. Et oui, peu de gens font la faute "ognions". En fait, tu as fait 9 fois la faute sur 15 occurences en 5 ans sur le chan en question, ça donne un indice.
Entre parenthéses, et juste parce que j'aimerais pas que d'autres pas te laisser dans l'erreur sur les histoires techniques, sache que Packagekit fait appel en interne à yum. Regarde le contenu de PackageKit-yum. Ou va lire le code source de packagekit. Et je le sais, j'ai completé rapidement une partie du support de urpmi.
En fait, tu peux aussi lire les présentations du projet fait par Richard Hughes ( http://www.packagekit.org/pk-intro.html ).
Donc dire "poubelle pour packagekit, yum se demerde mieux",
ça me fait rire.
De même, le fait de rebooter aprés partitionnement. Oui, c'est malheureux, et oui, faudrait pas, mais de mon expérience, le kernel n'arrive pas toujours à relire la table de partoche. Je doit reconnaitre qu'on m'avais dit qu'avec le 2.6, ça serait réglé, il suffit de faire partprobe. Ben non, la derniére fois, j'ai encore eu le probléme avec fdisk. Et visiblement, je suis pas le seul ( http://www.justlinux.com/forum/archive/index.php/t-150714.ht(...) )
Tu parles des uuids. Expliquons pourquoi ça marche comme ça. L'uuid identifie la partoche de maniére unique ( http://fr.wikipedia.org/wiki/Universal_Unique_Identifier ). Si tu l'effaces, tu en refait une autre, y a un autre uuid par définition, par fonctionnement de la RFC ( tirage au hasard, via un nombre pseudo aléatoire ). Et donc, tu voudrais garder l'UUID, ce qui revient à ne plus avoir un nombre si unique que ça, et ça reviens un peu à contourner la RFc et surtout, à avoir un comportement différent des autres outils. Donc une mauvaise idée.
Oui, c'est moche pour l'user qui fait une connerie. Mais tellement unixien : "UNIX was not designed to stop its users from doing stupid things, as that would also stop them from doing clever things."
En fait, quand tu parles de firefox et de upower, ça m'a mis la puce à l'oreille. Exactement le genre de truc typique de toi.
Comparer un navigateur qui sert de base à yelp, galeon, epihany ( en version < 2.27 ) et toute la clique de paquets mis à jours à chaque fois, et un sous systéme de hal, c'est juste totalement surréaliste.
Tu n'as pas l'air de te rendre compte que openoffice et firefox, face à upower, ça n'a juste rien à voir en terme d'impact, de lignes de code, ce genre de choses ?
Enfin bon, je vais pas passer des heures sur ça, c'est pas le but. Si tu veux continuer à parler de faux bugs avec l'air des vrais sans donner le moindre détail, c'est ton choix. Je préfére pour ma part faire des trucs constructifs. mais c'est vrai, tout le monde ne peut pas contribuer.
Pour en revenir au début, et pour finir, ce qui t'a vraiment trahi, en dehors des fautes récurrentes, du style, des pseudos sur irc et de la propension à changer de pseudo ( muny, bubar, tankey, charcler et surement d'autres ), c'est la mention de Christophe, président d'une grosse asso d'users. Des Christophes présidents de grosse asso d'users, j'en connait qu'un, et il est pas dur à trouver dans le Paysage Libre Francophone.
Et au passage, l'ex-responsable de formation que tu cites est aussi impliqué dans une autre assoce de distro basé sur rpm, directement dans une branche qui était sous la responsabilité du président de la même assoce. Et je parle pas de l'AUFML.
Oui, les 3 se connaissent, contrairement à ce qu'on pourrait croire. Bien sur, je comprends que tu ne veuilles pas entacher leur réputation, et uniquement dire du mal de Mandriva. Et c'est bien parce qu'ils ne le méritent pas que je donne pas leur nom exact.
Est ce que ce genre de pratique de mise en relation est courante ?
Je sais pas, je suis pas commercial. Mais franchement, je doute que ça soit le seul exemple de societé qui s'arrange avec d'autres. Mandriva a fait sous traiter une partie du boulot dans une SSII plus proche de chez toi. Bienvenue dans le monde réel. Cap Gemini fait pareil, j'ai deja vu de mes propres yeux.
Tarif d'une formation, je trouve des tarifs qui vont de 240 à 700 euros sur le net. Donc 10% par jour, ça va de 24 à 70 euros qui repartent vers Mandriva. C'est clair que ç'est avec ça qu'ils vont devenir riche. D'ailleurs, prix d'un hotel à toulouse, on va dire ~70 euros la nuit, en 2 étoiles. Ça fait 70 euros de différentiel par rapport à quelqu'un du cru.
Et je pense que si Christophe a dit oui à la proposition, c'est bien parce qu'il y trouve son compte.
Revenons à nos moutons, Christophe est toulousain, google le dit, sa SSII fait parti dans graine libre ( http://www.graine-libre.fr/ ).
Combien de mandrivistes du coin, qui donnes des formations, et qui correspondent au profil précédent ( fautes, chouineries, sur irc en 2005+/-1 ans, qui utilise parfois fedora ).
Un seul.
Donc la prochaine fois, je pense que c'est pas la peine de te cacher derriére un pseudonyme de plus.
Avec le grenelle 2, c'est dans l'air du temps, c'est une rumeur fait à partir d'autres rumeurs recyclés.
Sinon, je rappelle qu'il y a une AG de l'association des utilisateurs ( https://linuxfr.org/2010/05/04/26805.html ), et que parmi les fondateurs, certains veulent établir un contact régulier pour ce genre d'information, faire le point sur la santé, etc.
J'ai déjà dit plusieurs fois ce que je pense de ce genre de velléité inquistrice, mais visiblement, un certain nombre de gens sont sur la même longueur d'onde, et même si je suis pas d'accord, j'attire l'attention des gens sur le sujet. Donc n'hésitez pas à prendre contact avec l'association ( http://mandrivafr.org/node/71/article/les-listes-de-diffusio(...) ).
Il y a peut être une grande activité de revente de dvd pirates dans les pays ou l'accés au net n'est pas aussi bon qu'en europe. je me souviens avoir vu des dvds pirates vendus à la sauvette dans Chinatown à NYC, en 2002. ( oui, c'etait des dvds pirates, vu la tronche de photocopie de la couverture, et vu le fait que le film était encore au cinéma ).
Alors, dans des pays ou le reseau est tout pourri et couteux, ça peut rapporter.
Enfin, tout comme les dvcs actuelles, rien ne t'oblige à t'en servir de maniére decentralisé, donc la dichotomie que tu mets en place est totalement fausse. Si tu veux garder une façon centralisé de l'utiliser, tu peux, c'est juste que maintenant, les gens ne sont plus forcer de le faire. Si tu lit bien le site de SD, tu va voir qu'il est capable d'importer depuis trac, depuis redmine, etc.
L'exemple d'un bug qui est corrigé par plusieurs changeset est justement un exemple du probléme. Dans bugzilla, un bug affecte 1 version uniquement. Si je prends l'exemple de Mandriva, je trouve un probléme dans un paquet stable, le correctif doit passer la QA de façon formel, mais pas dans la version de dev. Le bug est donc dans un état sémi résolu ( corrigé dans une version et pas dans une autre ), et c'est un peu moche. Trac, mantis, et d'autres ont aussi ce modéle ( 1 bug == 1 version ).
Launchpad n'a pas ce modéle, mais du coup, comme il y a un fil de discussion par bug, on sait pas qui parle de quoi. Quand quelqu'un dit "le bug est corrigé pour moi", il faut qu'il précise dans quel version etc. Et donc ça entraine des risques d'erreurs.
Avec une instance forké d'un bug tracker par produit, c'est bien plus simple. On peut même imaginer qu'un revendeur d'un produit gére son propre bug tracker, ce genre de choses.
Les projets basés sur Ubuntu pourrait ainsi remonter les bugs plus facilement, tout comme les kernels hackers font passer leur patch d'un arbre à un autre aprés validation.
Tu parles de prendre les bugs pour debugger sans prevenir, je sais pas sur quel projet tu bosses, mais sur tout les projets ou je bosse, les gens corrigent sans prévenir, car les risques de collisions sont faibles. Quand il y a 5 personnes sur un projet, les gens vont rarement tous au même moment, sur le même truc. Et c'est bien plus lourd de prevenir que de corriger les rares problémes quand on le fait pas.
Et le probléme existe de toute façon deja avec un bts classique, donc je ne voit pas en quoi c'est génant ( à ce que je sache, personne ne va dire sérieusement "ah mais non, corriger le code sans le dire sur le bugzilla, ça va poser des problémes, faut empecher que ça arrive en forcant techniquement ça".
Quand à l'histoire des forks hostiles, rien ne dit que les gens doivent communiquer, le truc de base, c'est juste de pouvoir avoir une copie.
Pour l'histoire des bugs report, tu semble juste voir le coté "j'exporte les bugs chez les autres". Mais ça peut aussi être l'inverse, du style "j'importe le bug depuis les bts des distributions".
Et un point que j'ai oublié, c'est qu'on parle de web 2.0, de données captives, etc. Mais ce genre d'outil, c'est exactement dans l'optique des mouvements comme le DAta Liberation Front ( http://www.dataliberation.org/ ), ou finalement, si tu n'es pas content de tel ou tel presta, tu changes. Si tu veux faire des modifs à l'interface juste pour toi, tu le fait.
Peut être que ça va pas prendre, aprés tout, TLA n'a pas pris tout de suite, et n'aurait trés bien pu ne pas prendre. L'idée de dvcs, c'est que la théorisation de ce que foit la plupart des gens quand ils modifient dans leur coin un document.
C'est facile. Tu prends tout ce que tu peux faire avec un systéme distribué de gestion de sources, et tu appliques.
Tout d'abord, on peut imaginer ça pour travailler de maniére offline. Exemple, je suis dans le train, je suis la ou l'accés au net est pourri, ou je veux me concentrer sans être dérangé ( et donc je coupe le réseau ), j'ai mon bts offline pour bosser. Ça marche aussi si le bts est down, ou en maintenance.
Ensuite, pouvoir distribuer le bug tracker, ça permet aussi de faire facilement des forks.
Exemple, je fait une release, je fait un fork du code, pour la branche stable. Pour la liste des bugs reports, c'est pareil, j'ai une branche stable, et une branche dev. avec une gestion différente, et une durée de vie différente.
De même, si on veut forker un projet de maniére plus compléte, on peut. Le mainteneur est con, ne réponds pas, etc, on prends la liste des bugs, et on se barre. La liberté de base appliqué à la gestion de projet, comme pour le code.
Ça permet aussi d'avoir une TODO list personnel. Par exemple, je veut bosser sur tel driver du kernel. Je prends les bugs, je corrige, et je garde liste de ce que j'ai corrigé cote à cote avec le git.
Avoir la liste des bugs chez soi, ça permet de faire des traitements qu'on peut pas forcement faire à cause de la latence réseau, ou parce qu'on a pas les accés complets. De la recherche full texte, des requetes sql, des stats, etc.
Et au final, la problématique de la distribution est déja connu au niveau du code, il suffit de décreter une instance comme étant canonique, tout comme l'arbre git de linus est l'arbre officiel.
Dans le cas de Ubuntu, un bts distribué, ça permet aussi de pousser tout le bug upstream comme on pousse une branche git. Donc les commentaires sont preservés, et on peut imaginer merger les fils de discussions, ( ie, les discussions sur le bts fedora, sur le bts debian, etc ).
La soumission automatisé vers l'upstream est à mon avis complexe à faire. Je pense vraiment qu'on devrait s'orienter vers une espéce de git pour la gestion des bugs ( cf SD, comme dit plus haut, et qui va être présenté lors des rmll : http://2010.rmll.info/Gestion-de-bugs-peer-to-peer-avec-SD-e(...) ).
De plus, je pense qu'indépendament d'ubuntu, il est mieux d'aller directement voir upstream. Moins il y a d'intermediaire, mieux ça marche, au moins pour les grands projets. Et ça rappelle aux developpeurs, qu'ils ont des utilisateurs qui apprécient le logiciel, et qu'ils ne sont pas de simples producteurs à la solde des distros, mais bien au coeur du libre.
ouverture du bug : 21 mars, sur launchpad
prise en compte par surbhi palande : 29 mars
correctif avec un hack : 13 avril
ouverture du bug upstream : 4 mai
envoi d'un premier fix par un dev kernel : 12h plus tard
donc en gros, en une demi journée avec le bug au bon endroit, le bug est en passe d'être corrigé. On va dire qu'on rajoute 1 journée le temps de compiler un kernel vanilla pour vérifier si le bug vient d'un patch. A comparer avec les 3 semaines sur launchpad pour avoir un contournement.
Que les gens de Canonical n'arrivent pas à résoudre, ça me choque pas. Je sais à quel point les bugs peuvent être complexe, je sais qu'en période de release, on a pas le temps.
Mais bon, le fait de pas l'avoir rempli upstream plus tot me laisse perplexe. Je les blames pas, je suis sur que j'ai deja fait et que je ferait (hélas) surement pareil à un moment ou à un autre, par manque de temps, manque de soin, ou autres, personne n'est parfait, moi le premier.
Perso, je trouve que la méthode choisi par canonical pour le suivi des bugs upstreams est loin d'etre propre. Il aurait fallu plutot bossé en profondeur, pour décrire un bug dans un format indépendant ( xml, json, whatever, c'est pas le propos ), et ensuite faire en sorte que les différents bugs trackers fassent un export dans ce format.
Ça aurait permis de faire des outils comme SD plus facilement ( http://syncwith.us/sd/using ).Actuellement, la moitié du support, c'est de l'analyse du code html, c'est un peu moche et fragile.
Et même si skype peut demander, ç'est plus efficace de ne pas poser de questions surtout si la question est technique ( car bon, faut faire l'essai dans la rue, combien de gens vont pouvoir te dire "je sais ce qu'est un proxy" )
En même temps, pour une boite qui fonctionne, combien n'ont pas fonctionné ?
Et combien n'ont pas fonctionné à cause du manque de leadership ?
Je ne nie pas que ça peut marcher, bien sur, mais je pense qu'il faut avoir tout les chiffres pour juger de la viabilité de la chose dans des conditions qui ne sont pas trop spécifiques.
( si on voulait troller, on pourrait dire que c'est l'exemple de debian vs ubuntu, ou le fait d'avoir un dictateur benevole à vie fait que Ubuntu avance la ou Debian discutte, mais on est pas vendredi, donc je mentionne ça juste à titre indicatif )
Et je pense que c'est pas lié au monde de l'entreprise, car je vois bien que je fait un support bien plus conséquent sur les machines que je gére de maniére bénévole que ce que j'ai fait pour les clients.
Par exemple, j'arrive à dire "non, je ne suis pas payé pour répondre à 22h30" mais j'ai plus de mal à dire "non, je verrais ça demain, la, je vais me coucher" quand on me signale un probéme sur irc pour un truc ou la motivation n'est pas l'argent.
Donc l'autoresponsabilité aboutit parfois à renforcer sa propre tyrannie. La "direction" nous opprime toujours autant, et vu que c'est nous, c'est beaucoup plus dur de se dire non. La hiérarchie a aussi sa place à jouer pour séparer les responsabilités, et pour crystaliser et matérialiser l'entreprise. Si quelque chose va pas, on dit que ç'est la faute des autres, et c'est à mon sens plus sain que de se dire "c'est ma faute, donc faut que je bosse plus".
Ensuite, j'ai bien conscience que l'auto responsabilité a aussi des avantages ( plus leger, parfois plus épanouissant ( parfois ) ), et que la déresponsabilisation et la bureaucracie posent d'autres types de problémes bien connus et documentés.
Sur un projet de google de ton choix, ou un projet en rapport avec google, pas un projet perso. Tu va pas passer 20% de ton temps sur l'organisation de tes vacances, par exemple.
Le but de skype, c'est de faire des gros efforts pour marcher même avec les utilisateurs qui ne connaissent pas justement les variables d'environnements.
Il faut le reconnaitre, la gestion des proxys sous Unix est moisi. Je veux changer un truc, je doit me déconnecter. Donc tout le monde duplique la gestion à gauche et à droite ( dans ff, dans konqueror, dans gnome, etc ), et ça fout le boxon.
Donc si le fait d'aller fouiller les fichiers d'opera et co te parait porc, ç'est pour pallier aux problémes actuelles de l'architecture Unix basé justement sur des variables d'environement.
Skype marche aussi parce que le programme fait le maximum d'effort pour passer les firewalls, et ne pas faire chier l'utilisateur. Ça marche pas toujours, ça plait pas à tout le monde, mais je pense que ça plait quand même à suffisament de gens, et ça marche suffisament souvent pour qu'on puisse considérer ça comme un point différenciateur en leur faveur.
Ben le fait est que tout le monde n'est pas content d'avoir giwbber qui s'intégre avec ubuntu one :
- ça tire erlang ( car ubuntu one, ç'est desktop-couch, qui tire couchdb, donc erlang ), ce qui est embetant pour les livecds
- ça prends plus de ram que sans, et que certains pensent que ça prends plus de ram que requis, et que les fonctionnalités apportés ne veulent pas le surcout
- ça rends le soft plus compliqué à packager, surtout si tu n'as pas erlang ( même si je pense qu'une majorité de distros l'ont ), couchdb etant pas non plus trivial à intégrer
- il y a eu des tensions à ce sujet ( http://frederic.bezies.free.fr/blog/?p=3401 )
- ça ne pousse que vers u-1 ou vers les machines réseaux locales, la synchro vers d'autres services etant possible en théorie, mais non codé en pratique. On peut donc imaginer que ce coté commercial géne certaines personnes
- il y a eu un certain nombre de probléme de stabilité avec desktop-couch ( j'ai moi même eu un plantage de desktop-couch dans qemu quand j'ai lancé le livecd, mais j'ai pas réussi à reproduire ), et le blog des devs ( http://gwibber.com/blog/2010/04/introducing-gwibber-2-30/ ) parle de "performance limitations".
Donc Ryan Paul, un des codeurs de gwibber, a bien pris en compte ces critiques , et propose un branche de gwibber ou le stockage se fait dans sqlite au lieu de mettre ça dans le cloud avec ubuntu one, desktop couch et compagnie. J'ai même eu droit à un bug report le jour même ( https://qa.mandriva.com/show_bug.cgi?id=58845 ), alors que desktop couch est dispo dans mandriva ( et qu'il fonctionne sans trop de probléme ).
Pour ma part, j'ai pas grand chose contre desktop-couch, je trouve ça même intéressant, à part que le seul service vraiment intégré, c'est u-1, et qu'il n'y a rien d'ouvert dedans, contrairement à ce que les gens croient ( https://bugs.launchpad.net/ubuntuone-servers/+bug/375345 ). Je suis sur qu'avec un peu de temps, ce probléme peut se regler rapidement, bien sur, et il ne tient qu'à nous de nous en occuper.
À une différence prés :
"These are the people I call Architecture Astronauts. It's very hard to get them to write code or design programs, because they won't stop thinking about Architecture."
Et si tu as bien lu l'article, tu peux voir qu'il y a déja un dépot git, qui marche, qu'il est pas seul à coder dessus, et qu'il y a même des VMs de test afin de montrer que ça marche.
Je pense que tu devrais ressortir un systéme d'il y a 5 ans pour voir qu'il y quand même eu du changement. Les isos sont surle web, fait l'expérience ( et un journal pour nous raconter ça ). J'ai personnelement souvent des trucs minucules qui manquent quand je vais sur le pc que j'ai mis à mes parents, avec 3 ans de retard sur les distros courantes ( par manque de temps pour la mise à jour ).
[^] # Re: l'ambEUlance
Posté par Misc (site web personnel) . En réponse au journal Linux : Mandriva à vendre. Évalué à 5.
"tout contrib dans /opt", encore une fois, ça sent le même qui croit maitriser. Comme si changer de repertoire était la solution. C'est bien évident que ce qui géne, c'est d'avoir /usr, pas d'avoir /opt. Le simple fait d'avoir 3 lettres qui changent ça va tout changer.
Ah oui, et puis retirer de la QA sur les One et sur les Free, ça va surement aider la distribution. Tu as d'autres idées du même genre que "faire moins de test pour avoir plus de qualité" ?
Et tu t'es pas dit que la QA fait sur les Ones et sur la Free, ç'est toujours de la QA en moins pour les versions pros ?
Franchement, je sais que samedi, c'etait pas loin de vendredi, mais quand même...
[^] # Re: l'ambEUlance
Posté par Misc (site web personnel) . En réponse au journal Linux : Mandriva à vendre. Évalué à 7.
Déjà, c'est facile. Les pseudos de gens que tu as donné sont tous des pseudos venant de mandrakefr. Donc j'ai supposé que tu étais un habitué. J'ai fait rapidement un peu de datamining sur les logs pour situer quelqu'un présent dans les années 2004/2006, au moins. Ça nous laisse un certain nombre de gens.
Ensuite, le style. Non pas le coté "je donne l'impression de savoir de quoi je parle, mais faut pas fouiller trop loin", même si j'aurais pu m'en servir. Mais je n'ai pas eu besoin de ressortir les théories complexes d'identification à partir du style ( http://portal.acm.org/citation.cfm?id=1251313 ), j'ai juste repris le datamining sur les fautes d'orthographes courantes. Et oui, peu de gens font la faute "ognions". En fait, tu as fait 9 fois la faute sur 15 occurences en 5 ans sur le chan en question, ça donne un indice.
Entre parenthéses, et juste parce que j'aimerais pas que d'autres pas te laisser dans l'erreur sur les histoires techniques, sache que Packagekit fait appel en interne à yum. Regarde le contenu de PackageKit-yum. Ou va lire le code source de packagekit. Et je le sais, j'ai completé rapidement une partie du support de urpmi.
En fait, tu peux aussi lire les présentations du projet fait par Richard Hughes ( http://www.packagekit.org/pk-intro.html ).
Donc dire "poubelle pour packagekit, yum se demerde mieux",
ça me fait rire.
De même, le fait de rebooter aprés partitionnement. Oui, c'est malheureux, et oui, faudrait pas, mais de mon expérience, le kernel n'arrive pas toujours à relire la table de partoche. Je doit reconnaitre qu'on m'avais dit qu'avec le 2.6, ça serait réglé, il suffit de faire partprobe. Ben non, la derniére fois, j'ai encore eu le probléme avec fdisk. Et visiblement, je suis pas le seul ( http://www.justlinux.com/forum/archive/index.php/t-150714.ht(...) )
Tu parles des uuids. Expliquons pourquoi ça marche comme ça. L'uuid identifie la partoche de maniére unique ( http://fr.wikipedia.org/wiki/Universal_Unique_Identifier ). Si tu l'effaces, tu en refait une autre, y a un autre uuid par définition, par fonctionnement de la RFC ( tirage au hasard, via un nombre pseudo aléatoire ). Et donc, tu voudrais garder l'UUID, ce qui revient à ne plus avoir un nombre si unique que ça, et ça reviens un peu à contourner la RFc et surtout, à avoir un comportement différent des autres outils. Donc une mauvaise idée.
Oui, c'est moche pour l'user qui fait une connerie. Mais tellement unixien : "UNIX was not designed to stop its users from doing stupid things, as that would also stop them from doing clever things."
En fait, quand tu parles de firefox et de upower, ça m'a mis la puce à l'oreille. Exactement le genre de truc typique de toi.
Comparer un navigateur qui sert de base à yelp, galeon, epihany ( en version < 2.27 ) et toute la clique de paquets mis à jours à chaque fois, et un sous systéme de hal, c'est juste totalement surréaliste.
Tu n'as pas l'air de te rendre compte que openoffice et firefox, face à upower, ça n'a juste rien à voir en terme d'impact, de lignes de code, ce genre de choses ?
Enfin bon, je vais pas passer des heures sur ça, c'est pas le but. Si tu veux continuer à parler de faux bugs avec l'air des vrais sans donner le moindre détail, c'est ton choix. Je préfére pour ma part faire des trucs constructifs. mais c'est vrai, tout le monde ne peut pas contribuer.
Pour en revenir au début, et pour finir, ce qui t'a vraiment trahi, en dehors des fautes récurrentes, du style, des pseudos sur irc et de la propension à changer de pseudo ( muny, bubar, tankey, charcler et surement d'autres ), c'est la mention de Christophe, président d'une grosse asso d'users. Des Christophes présidents de grosse asso d'users, j'en connait qu'un, et il est pas dur à trouver dans le Paysage Libre Francophone.
Et au passage, l'ex-responsable de formation que tu cites est aussi impliqué dans une autre assoce de distro basé sur rpm, directement dans une branche qui était sous la responsabilité du président de la même assoce. Et je parle pas de l'AUFML.
Oui, les 3 se connaissent, contrairement à ce qu'on pourrait croire. Bien sur, je comprends que tu ne veuilles pas entacher leur réputation, et uniquement dire du mal de Mandriva. Et c'est bien parce qu'ils ne le méritent pas que je donne pas leur nom exact.
Est ce que ce genre de pratique de mise en relation est courante ?
Je sais pas, je suis pas commercial. Mais franchement, je doute que ça soit le seul exemple de societé qui s'arrange avec d'autres. Mandriva a fait sous traiter une partie du boulot dans une SSII plus proche de chez toi. Bienvenue dans le monde réel. Cap Gemini fait pareil, j'ai deja vu de mes propres yeux.
Tarif d'une formation, je trouve des tarifs qui vont de 240 à 700 euros sur le net. Donc 10% par jour, ça va de 24 à 70 euros qui repartent vers Mandriva. C'est clair que ç'est avec ça qu'ils vont devenir riche. D'ailleurs, prix d'un hotel à toulouse, on va dire ~70 euros la nuit, en 2 étoiles. Ça fait 70 euros de différentiel par rapport à quelqu'un du cru.
D'ailleurs, si les gens veulent évaluer l'annonce envoyé : http://www.mandrivafr.org/pipermail/association/2009-June/00(...)
Et je pense que si Christophe a dit oui à la proposition, c'est bien parce qu'il y trouve son compte.
Revenons à nos moutons, Christophe est toulousain, google le dit, sa SSII fait parti dans graine libre ( http://www.graine-libre.fr/ ).
Combien de mandrivistes du coin, qui donnes des formations, et qui correspondent au profil précédent ( fautes, chouineries, sur irc en 2005+/-1 ans, qui utilise parfois fedora ).
Un seul.
Donc la prochaine fois, je pense que c'est pas la peine de te cacher derriére un pseudonyme de plus.
[^] # Re: Déjà-vu
Posté par Misc (site web personnel) . En réponse au journal Linux : Mandriva à vendre. Évalué à 3.
Sinon, je rappelle qu'il y a une AG de l'association des utilisateurs (
https://linuxfr.org/2010/05/04/26805.html ), et que parmi les fondateurs, certains veulent établir un contact régulier pour ce genre d'information, faire le point sur la santé, etc.
J'ai déjà dit plusieurs fois ce que je pense de ce genre de velléité inquistrice, mais visiblement, un certain nombre de gens sont sur la même longueur d'onde, et même si je suis pas d'accord, j'attire l'attention des gens sur le sujet. Donc n'hésitez pas à prendre contact avec l'association ( http://mandrivafr.org/node/71/article/les-listes-de-diffusio(...) ).
[^] # Re: Enregistré ?
Posté par Misc (site web personnel) . En réponse à la dépêche Conférence Parinux - Le langage de programmation GO. Évalué à 5.
[^] # Re: Ses limites actuelles...
Posté par Misc (site web personnel) . En réponse à la dépêche Conférence Parinux - Le langage de programmation GO. Évalué à 10.
Car, sans go, anne le sait.
[^] # Re: Et la timeline ?
Posté par Misc (site web personnel) . En réponse au journal Canonical FAIL. Évalué à -1.
Surbhi est une femme, aussi hors norme que ça puisse paraitre, mais des personnes du sexe opposé codent aussi sur le kernel.
Donc je me demande comment tu fait pour savoir que c'est pas une experte noyau si tu sais déjà pas que c'est une femme :/
[^] # Re: En tout cas...
Posté par Misc (site web personnel) . En réponse au journal Comment MegaVideo parvient-il à financer sa bande passante ?. Évalué à 2.
Alors, dans des pays ou le reseau est tout pourri et couteux, ça peut rapporter.
[^] # Re: Et la timeline ?
Posté par Misc (site web personnel) . En réponse au journal Canonical FAIL. Évalué à 2.
http://syncwith.us/sd/using . Et l'auteur va en parler lors des RMLLs
et y en a d'autres, cf http://lwn.net/Articles/281849/
Enfin, tout comme les dvcs actuelles, rien ne t'oblige à t'en servir de maniére decentralisé, donc la dichotomie que tu mets en place est totalement fausse. Si tu veux garder une façon centralisé de l'utiliser, tu peux, c'est juste que maintenant, les gens ne sont plus forcer de le faire. Si tu lit bien le site de SD, tu va voir qu'il est capable d'importer depuis trac, depuis redmine, etc.
L'exemple d'un bug qui est corrigé par plusieurs changeset est justement un exemple du probléme. Dans bugzilla, un bug affecte 1 version uniquement. Si je prends l'exemple de Mandriva, je trouve un probléme dans un paquet stable, le correctif doit passer la QA de façon formel, mais pas dans la version de dev. Le bug est donc dans un état sémi résolu ( corrigé dans une version et pas dans une autre ), et c'est un peu moche. Trac, mantis, et d'autres ont aussi ce modéle ( 1 bug == 1 version ).
Launchpad n'a pas ce modéle, mais du coup, comme il y a un fil de discussion par bug, on sait pas qui parle de quoi. Quand quelqu'un dit "le bug est corrigé pour moi", il faut qu'il précise dans quel version etc. Et donc ça entraine des risques d'erreurs.
Avec une instance forké d'un bug tracker par produit, c'est bien plus simple. On peut même imaginer qu'un revendeur d'un produit gére son propre bug tracker, ce genre de choses.
Les projets basés sur Ubuntu pourrait ainsi remonter les bugs plus facilement, tout comme les kernels hackers font passer leur patch d'un arbre à un autre aprés validation.
Tu parles de prendre les bugs pour debugger sans prevenir, je sais pas sur quel projet tu bosses, mais sur tout les projets ou je bosse, les gens corrigent sans prévenir, car les risques de collisions sont faibles. Quand il y a 5 personnes sur un projet, les gens vont rarement tous au même moment, sur le même truc. Et c'est bien plus lourd de prevenir que de corriger les rares problémes quand on le fait pas.
Et le probléme existe de toute façon deja avec un bts classique, donc je ne voit pas en quoi c'est génant ( à ce que je sache, personne ne va dire sérieusement "ah mais non, corriger le code sans le dire sur le bugzilla, ça va poser des problémes, faut empecher que ça arrive en forcant techniquement ça".
Quand à l'histoire des forks hostiles, rien ne dit que les gens doivent communiquer, le truc de base, c'est juste de pouvoir avoir une copie.
Pour l'histoire des bugs report, tu semble juste voir le coté "j'exporte les bugs chez les autres". Mais ça peut aussi être l'inverse, du style "j'importe le bug depuis les bts des distributions".
Et un point que j'ai oublié, c'est qu'on parle de web 2.0, de données captives, etc. Mais ce genre d'outil, c'est exactement dans l'optique des mouvements comme le DAta Liberation Front ( http://www.dataliberation.org/ ), ou finalement, si tu n'es pas content de tel ou tel presta, tu changes. Si tu veux faire des modifs à l'interface juste pour toi, tu le fait.
Peut être que ça va pas prendre, aprés tout, TLA n'a pas pris tout de suite, et n'aurait trés bien pu ne pas prendre. L'idée de dvcs, c'est que la théorisation de ce que foit la plupart des gens quand ils modifient dans leur coin un document.
Et j'aurais tendance à dire qu'au dela des bts et du code, il y a aussi une place pour un wiki distribué ( comme http://ikiwiki.info/tips/distributed_wikis/ , ou http://wiki.laptop.org/go/MikMik ).
[^] # Re: Et la timeline ?
Posté par Misc (site web personnel) . En réponse au journal Canonical FAIL. Évalué à 3.
http://lwn.net/Articles/321473/
( tout comme d'autres distributions, au passage ).
Quand au fait que ça multiplie les comptes, c'est certes chiant, mais la solution est à mon avis d'un autre ordre, au hasard, openid.
[^] # Re: Et la timeline ?
Posté par Misc (site web personnel) . En réponse au journal Canonical FAIL. Évalué à 3.
Tout d'abord, on peut imaginer ça pour travailler de maniére offline. Exemple, je suis dans le train, je suis la ou l'accés au net est pourri, ou je veux me concentrer sans être dérangé ( et donc je coupe le réseau ), j'ai mon bts offline pour bosser. Ça marche aussi si le bts est down, ou en maintenance.
Ensuite, pouvoir distribuer le bug tracker, ça permet aussi de faire facilement des forks.
Exemple, je fait une release, je fait un fork du code, pour la branche stable. Pour la liste des bugs reports, c'est pareil, j'ai une branche stable, et une branche dev. avec une gestion différente, et une durée de vie différente.
De même, si on veut forker un projet de maniére plus compléte, on peut. Le mainteneur est con, ne réponds pas, etc, on prends la liste des bugs, et on se barre. La liberté de base appliqué à la gestion de projet, comme pour le code.
Ça permet aussi d'avoir une TODO list personnel. Par exemple, je veut bosser sur tel driver du kernel. Je prends les bugs, je corrige, et je garde liste de ce que j'ai corrigé cote à cote avec le git.
Avoir la liste des bugs chez soi, ça permet de faire des traitements qu'on peut pas forcement faire à cause de la latence réseau, ou parce qu'on a pas les accés complets. De la recherche full texte, des requetes sql, des stats, etc.
Et au final, la problématique de la distribution est déja connu au niveau du code, il suffit de décreter une instance comme étant canonique, tout comme l'arbre git de linus est l'arbre officiel.
Dans le cas de Ubuntu, un bts distribué, ça permet aussi de pousser tout le bug upstream comme on pousse une branche git. Donc les commentaires sont preservés, et on peut imaginer merger les fils de discussions, ( ie, les discussions sur le bts fedora, sur le bts debian, etc ).
[^] # Re: Exagéré
Posté par Misc (site web personnel) . En réponse au journal Canonical FAIL. Évalué à -1.
Developpement durable ?
Dunkins Donuts ?
Designated driver ?
un tag html, une commande unix
( en effet, google n'est pas trés utile sur le coup :) )
[^] # Re: Et la timeline ?
Posté par Misc (site web personnel) . En réponse au journal Canonical FAIL. Évalué à 4.
De plus, je pense qu'indépendament d'ubuntu, il est mieux d'aller directement voir upstream. Moins il y a d'intermediaire, mieux ça marche, au moins pour les grands projets. Et ça rappelle aux developpeurs, qu'ils ont des utilisateurs qui apprécient le logiciel, et qu'ils ne sont pas de simples producteurs à la solde des distros, mais bien au coeur du libre.
# Et la timeline ?
Posté par Misc (site web personnel) . En réponse au journal Canonical FAIL. Évalué à 10.
ouverture du bug : 21 mars, sur launchpad
prise en compte par surbhi palande : 29 mars
correctif avec un hack : 13 avril
ouverture du bug upstream : 4 mai
envoi d'un premier fix par un dev kernel : 12h plus tard
donc en gros, en une demi journée avec le bug au bon endroit, le bug est en passe d'être corrigé. On va dire qu'on rajoute 1 journée le temps de compiler un kernel vanilla pour vérifier si le bug vient d'un patch. A comparer avec les 3 semaines sur launchpad pour avoir un contournement.
Que les gens de Canonical n'arrivent pas à résoudre, ça me choque pas. Je sais à quel point les bugs peuvent être complexe, je sais qu'en période de release, on a pas le temps.
Mais bon, le fait de pas l'avoir rempli upstream plus tot me laisse perplexe. Je les blames pas, je suis sur que j'ai deja fait et que je ferait (hélas) surement pareil à un moment ou à un autre, par manque de temps, manque de soin, ou autres, personne n'est parfait, moi le premier.
[^] # Re: Exagéré
Posté par Misc (site web personnel) . En réponse au journal Canonical FAIL. Évalué à 1.
Ça aurait permis de faire des outils comme SD plus facilement ( http://syncwith.us/sd/using ).Actuellement, la moitié du support, c'est de l'analyse du code html, c'est un peu moche et fragile.
Mais bon, le but etait pas de faciliter la collaboration, mais de concurencer RH et progeny, cf http://www.erisian.com.au/wordpress/2005/09/04/launchpad
[^] # Re: BIDON
Posté par Misc (site web personnel) . En réponse au journal Cinq cent milliards de petits liens, et moi, et moi, et... Skype. Évalué à 3.
Et même si skype peut demander, ç'est plus efficace de ne pas poser de questions surtout si la question est technique ( car bon, faut faire l'essai dans la rue, combien de gens vont pouvoir te dire "je sais ce qu'est un proxy" )
[^] # Re: Prix libre
Posté par Misc (site web personnel) . En réponse au journal [HS] Favi, l'entreprise sans chef.. Évalué à 6.
Et combien n'ont pas fonctionné à cause du manque de leadership ?
Je ne nie pas que ça peut marcher, bien sur, mais je pense qu'il faut avoir tout les chiffres pour juger de la viabilité de la chose dans des conditions qui ne sont pas trop spécifiques.
( si on voulait troller, on pourrait dire que c'est l'exemple de debian vs ubuntu, ou le fait d'avoir un dictateur benevole à vie fait que Ubuntu avance la ou Debian discutte, mais on est pas vendredi, donc je mentionne ça juste à titre indicatif )
[^] # Re: complément
Posté par Misc (site web personnel) . En réponse au journal [HS] Favi, l'entreprise sans chef.. Évalué à 9.
Et je pense que c'est pas lié au monde de l'entreprise, car je vois bien que je fait un support bien plus conséquent sur les machines que je gére de maniére bénévole que ce que j'ai fait pour les clients.
Par exemple, j'arrive à dire "non, je ne suis pas payé pour répondre à 22h30" mais j'ai plus de mal à dire "non, je verrais ça demain, la, je vais me coucher" quand on me signale un probéme sur irc pour un truc ou la motivation n'est pas l'argent.
Donc l'autoresponsabilité aboutit parfois à renforcer sa propre tyrannie. La "direction" nous opprime toujours autant, et vu que c'est nous, c'est beaucoup plus dur de se dire non. La hiérarchie a aussi sa place à jouer pour séparer les responsabilités, et pour crystaliser et matérialiser l'entreprise. Si quelque chose va pas, on dit que ç'est la faute des autres, et c'est à mon sens plus sain que de se dire "c'est ma faute, donc faut que je bosse plus".
Ensuite, j'ai bien conscience que l'auto responsabilité a aussi des avantages ( plus leger, parfois plus épanouissant ( parfois ) ), et que la déresponsabilisation et la bureaucracie posent d'autres types de problémes bien connus et documentés.
[^] # Re: Rien de nouveau sous le soleil ...
Posté par Misc (site web personnel) . En réponse au journal [HS] Favi, l'entreprise sans chef.. Évalué à 3.
Et tu dois aussi demander l'avis du management.
[^] # Re: Ubuntu One
Posté par Misc (site web personnel) . En réponse à la dépêche Ubuntu 10.04 est sortie. Évalué à 2.
[^] # Re: Démarrage
Posté par Misc (site web personnel) . En réponse à la dépêche Ubuntu 10.04 est sortie. Évalué à 4.
Curieusement, il existe une équipe ( https://wiki.ubuntu.com/MarketingTeam ), mais ils ont pas du mettre leur travail suffisament en avant.
[^] # Re: BIDON
Posté par Misc (site web personnel) . En réponse au journal Cinq cent milliards de petits liens, et moi, et moi, et... Skype. Évalué à 10.
Il faut le reconnaitre, la gestion des proxys sous Unix est moisi. Je veux changer un truc, je doit me déconnecter. Donc tout le monde duplique la gestion à gauche et à droite ( dans ff, dans konqueror, dans gnome, etc ), et ça fout le boxon.
Donc si le fait d'aller fouiller les fichiers d'opera et co te parait porc, ç'est pour pallier aux problémes actuelles de l'architecture Unix basé justement sur des variables d'environement.
Skype marche aussi parce que le programme fait le maximum d'effort pour passer les firewalls, et ne pas faire chier l'utilisateur. Ça marche pas toujours, ça plait pas à tout le monde, mais je pense que ça plait quand même à suffisament de gens, et ça marche suffisament souvent pour qu'on puisse considérer ça comme un point différenciateur en leur faveur.
[^] # Re: Ubuntu One
Posté par Misc (site web personnel) . En réponse à la dépêche Ubuntu 10.04 est sortie. Évalué à 7.
- ça tire erlang ( car ubuntu one, ç'est desktop-couch, qui tire couchdb, donc erlang ), ce qui est embetant pour les livecds
- ça prends plus de ram que sans, et que certains pensent que ça prends plus de ram que requis, et que les fonctionnalités apportés ne veulent pas le surcout
- ça rends le soft plus compliqué à packager, surtout si tu n'as pas erlang ( même si je pense qu'une majorité de distros l'ont ), couchdb etant pas non plus trivial à intégrer
- il y a eu des tensions à ce sujet ( http://frederic.bezies.free.fr/blog/?p=3401 )
- ça ne pousse que vers u-1 ou vers les machines réseaux locales, la synchro vers d'autres services etant possible en théorie, mais non codé en pratique. On peut donc imaginer que ce coté commercial géne certaines personnes
- il y a eu un certain nombre de probléme de stabilité avec desktop-couch ( j'ai moi même eu un plantage de desktop-couch dans qemu quand j'ai lancé le livecd, mais j'ai pas réussi à reproduire ), et le blog des devs ( http://gwibber.com/blog/2010/04/introducing-gwibber-2-30/ ) parle de "performance limitations".
Donc Ryan Paul, un des codeurs de gwibber, a bien pris en compte ces critiques , et propose un branche de gwibber ou le stockage se fait dans sqlite au lieu de mettre ça dans le cloud avec ubuntu one, desktop couch et compagnie. J'ai même eu droit à un bug report le jour même ( https://qa.mandriva.com/show_bug.cgi?id=58845 ), alors que desktop couch est dispo dans mandriva ( et qu'il fonctionne sans trop de probléme ).
Pour ma part, j'ai pas grand chose contre desktop-couch, je trouve ça même intéressant, à part que le seul service vraiment intégré, c'est u-1, et qu'il n'y a rien d'ouvert dedans, contrairement à ce que les gens croient ( https://bugs.launchpad.net/ubuntuone-servers/+bug/375345 ). Je suis sur qu'avec un peu de temps, ce probléme peut se regler rapidement, bien sur, et il ne tient qu'à nous de nous en occuper.
[^] # Re: [:Mouaifff]
Posté par Misc (site web personnel) . En réponse au journal Rethinking PID 1. Évalué à 8.
"These are the people I call Architecture Astronauts. It's very hard to get them to write code or design programs, because they won't stop thinking about Architecture."
Et si tu as bien lu l'article, tu peux voir qu'il y a déja un dépot git, qui marche, qu'il est pas seul à coder dessus, et qu'il y a même des VMs de test afin de montrer que ça marche.
[^] # Re: Pourquoi ?
Posté par Misc (site web personnel) . En réponse au journal Rethinking PID 1. Évalué à 3.
[^] # Re: [:Mouaifff]
Posté par Misc (site web personnel) . En réponse au journal Rethinking PID 1. Évalué à 4.