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 ).
C'est en effet une solution, vu que Canonical intervient de maniére minimal dans la distribution ( cf divers commentaires ici, et cf le fait que ça reste toujours un dérivé alors que la majorité des developpements sont fait en gtk pour gnome, ou sur des softs gnome, genre gwibber, rhythmbox, etc ).
Mais bon, si il veut garder gnome, il y a d'autres distributions, comme Mandriva, Opensuse, Fedora, ou Debian, qui proposent toute un gnome de bonne facture, et assez souvent les mêmes versions de soft que ubuntu ( genre gwibber est dans mandriva, desktopcouch aussi ).
Je peux pas vraiment parler pour d'autres que moi, mais j'ai de temps en temps à passer sous os x, et je doit reconnaitre que les habitudes se changent finalement assez vite.
C'est comme passer du qwerty à l'azerty, au début, ça fait chier, mais avec l'habitude, tu voit plus la différence. Par contre, pour les gens qui ont et qui ont eu déja du mal avec le réglage classique, ils vont avoir autant de mal avec le changement.
[^] # 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.
[^] # Re: Merci Canonical
Posté par Misc (site web personnel) . En réponse à la dépêche Ubuntu 10.04 est sortie. Évalué à 4.
Mais bon, si il veut garder gnome, il y a d'autres distributions, comme Mandriva, Opensuse, Fedora, ou Debian, qui proposent toute un gnome de bonne facture, et assez souvent les mêmes versions de soft que ubuntu ( genre gwibber est dans mandriva, desktopcouch aussi ).
[^] # Re: Merci à yellowiscool pour avoir proposé et réalisé la CSS lucid
Posté par Misc (site web personnel) . En réponse à la dépêche Ubuntu 10.04 est sortie. Évalué à 2.
[^] # Re: Merci Canonical
Posté par Misc (site web personnel) . En réponse à la dépêche Ubuntu 10.04 est sortie. Évalué à 3.
C'est comme passer du qwerty à l'azerty, au début, ça fait chier, mais avec l'habitude, tu voit plus la différence. Par contre, pour les gens qui ont et qui ont eu déja du mal avec le réglage classique, ils vont avoir autant de mal avec le changement.
[^] # Re: Ubuntu One
Posté par Misc (site web personnel) . En réponse à la dépêche Ubuntu 10.04 est sortie. Évalué à 1.
[^] # Re: L'instant culture
Posté par Misc (site web personnel) . En réponse au journal Internet mobile... mais pour quoi faire ?. Évalué à 4.
# Comparé au secteur privé
Posté par Misc (site web personnel) . En réponse au journal Google joue la transparence sur l'espionnage étatique. Évalué à 5.
un projet du MIT qui surveille youtube et qui regarde les videos qui se font retirer.
[^] # Re: Argh
Posté par Misc (site web personnel) . En réponse au journal Xorg 1.8: épatant ?. Évalué à 4.