Philippe F a écrit 2214 commentaires

Certes. Mais, très honnêtement, connais-tu la marque de tous les objets, produits et services que utilise ?

Quelle est la marque de le chaise sur laquelle tu es assis ? De ton clavier ? De la fourchette avec laquelle tu manges le midi ? De ton verre ? Du sac-poubelle de la poubelle de ta cuisine ? Du post-it que tu utilises pour laisser un message ?

Sans pour autant approuver la politique de Gnome, on peut s’interroger légitimement sur la nécessité de connaitre toutes les marques et leurs vertus respectives.

Oui, j'ai quelques arguments. Tout d'abord, un panorama des logiciels existants. Si tu regardes l'ensemble des logiciels libres comme propriétaires, tu vois que cette pratique de version paire vs impaire est extrêmement marginale. Sans condamner ce qui est exceptionnel, cela questionne sur la légitimité de la pratique.

Dans le cas de Linux, cette pratique a été introduite à une époque où l'outil de gestion de source des gens modernes était CVS (les gens plus conservateurs utilisaient encore RCS). A cette époque, Linus dumpait toutes les 2 ou 3 semaines un gros tar.gz du noyau que tous les barbus s'empressaient de tester. Il y avait une réelle nécessité de nommer ces dumps de développement et Linus a utilisé une pratique plutôt originale: les versions impaires. Quand le bazar finissait par marchoter, il le passait en version paire. Linus étant un dictateur, personne n'a eu grand chose à discuter quant à la pratique.

Déjà à l'époque, les projets qui utilisaient un gestionnaire de source moderne (CVS donc), n'avaient pas ce besoin puisqu'il suffisait de récupérer la version en cours de développement avec un CVS up et qu'on s'en sortait avec une date.

Linus a fini pour trouver un système de gestion de source qui lui convient et a pu gérer confortablement les différents niveaux de stabilité du noyau avec différents dépotoirs. Il a en toute logique fini par abandonner les versions paires et impaires puisque les raisons qui avaient présidé à leur utilisation n'étaient plus.

Le seul argument qu'on opposait à l'époque où Gnome a fait ce choix que je critique, c'est "si Linux le fait, c'est une bonne pratique, faisons le aussi". J'imagine que ces même supporters de l'époque militent maintenant pour un versionnage classique, comme Linux. Si ce n'était pas le cas, ils seraient en flagrant délit d'incohérence !

Gnome n'est pas le seul projet à s'être posé la question de sa numérotation de version. Je me souviens d'avoir vu ce débat sur kde-core-devel. Récemment sur python-dev, les développeurs ont réfléchi à un autre schéma de sortie et de numérotation de version. Gentoo et Ubuntu ont aussi proposé un nouveau système plutôt basé sur des dates. On voit que Linux et Samba ont abandonné le système des versions paire et impaires, donc il y a clairement eu des discussions sur le sujet. Il y a aussi debian avec ses noms à la con dont personne ne se rappelle parfaitement identifiables.

Dans toutes les discussions auxquelles j'ai assisté, la réflexion sur la numérotation des version est axée pratiquement sur un seul sujet: l'utilisateur.

Les questions qui vont autour:
- comment l'utilisateur va-t-il comprendre quelle version il utilise ?
- comment l'utilisateur distingue les caractéristiques d'une version par rapport à une autre ? Plus stable, plus récente, avec des fonctionnalités en plus, qui plante plus, quelle version signaler dans les rapports de bug, etc
- comment l'utilisateur sait que sa version est à jour ?
- comment communiquer à l'utilisateur un changement important (on casse tout, plus rien de ce qui marchait avant ne marche) ?

Le schéma le plus courant est:
- un numéro de version majeur pour distinguer une famille de version
- un numéro de version mineur pour distinguer une mise à jour avec des nouvelles fonctionnalités
- un sous numéro de version pour distinguer des correctifs sans nouvelle fonctionnalité.
- un vocable particulier pour désigner les versions en cours de développement: instable, preview, alpha, beta, release candidate, demo,

Ce schéma est très courant, donc l'utilisateur "classique" s'y retrouve assez facilement: Python 2.6 est plus récent que Python 2.7, KDE 3 est une évolution majeure de KDE 2, Windows 8 Consumer Preview n'est pas la version finale mais une version en cours de développement, à tester par les utilisateurs et développeurs aventureux. Et Gnome 2.4.3, c'est comme Gnome 2.4.0 mais en plus stable.

Le choix de numérotation des versions instables en impaires embrouille un peu le message vers l'utilisateur. Raisonnablement, un utilisateur qui a un Gnome 2.4 et qui veut passer à la version suivante de Gnome s'attend à passer à la version 2.5 . Il faut alors lui explique que "oui mais non, parce que tu comprends, Gnome la version 2.5, c'est que pour les développeurs et les testeurs, donc c'est directement 2.6". Sans en faire tout un fromage, ça complique quand même le message vis à vis de l'utilisateur. Autre scenario, l'utilisateur vient de passer de Gnome 2.4 à Gnome 2.6 grâce à sa distrib et se dit ben zut, moi qui aime bien avoir la dernière version stable de mes logiciels, j'ai raté Gnome 2.5 .

Alors, pourquoi compliquer le message vis à vis de l'utilisateur ? En particulier pour un logiciel qui se veut accessible au plus grand nombre et pas juste aux barbus ?

De mon point de vue, il n'y a pas de bonne justification. Certes, c'est vaguement plus pratique pour les développeurs et les testeurs, mais ce public est justement capable de s’accommoder d'à peu près n'importe quel schéma de numérotation vu qu'ils sont impliqués dans le projet. Et les outils de gestion de conf modernes (déja avec subversion, encore plus avec git) permettent de gérer cette problématique extrêmement simplement.

Je trouve ça étrange pour Gnome de payer le prix d'une certaine incompréhension des utilisateurs pour un gain que je peine à voir.

Je comprends ce que vous dites, vous parlez des pratiques qui président au choix de la roadmap. Tout projet un tant soit peu évoluée en a (KDE, Python, Linux, etc), avec des numérotations qui fonctionnent très bien: un planning, des dates, des fonctionnalités ciblées, des numérotations de version qui permettent de distinguer ce qui est instable de ce qui est stable. Sur ce point-là, Gnome est comme tous les projets bien gérés.

Par contre, j'ai toujours pas vu un argument solide pour justifier l'absence de version impaire stable vis à vis du grand public.

Bon, j'espère que les développeurs de ton projet ne feront pas l'erreur de sortir encore une version instable dans deux ans. Sinon, on est mal barré…

Je vois pas très bien d'où tu tires l'information que ça marchait pas du tout pour Linux et très bien pour Gnome. Ce dont je suis sûr, c'est que les release impaires de Linux sont bien plus testées en terme de nombre d'utilisateurs que celles de Gnome (sans méchanceté, mais juste parce que Linux a une base d'utilisateurs supérieure).

Quant à ton serpent qui se mord la queue, tous les projets logiciels ont ce problème, que la version en cours de test soit appelée alpha, beta, 2.5, unstable, preview release ou autre, elle est toujours insuffisamment testée du goûts de développeurs. Je ne vois pas en quoi Gnome s'en sort mieux que n'importe quel autre projet sur ce plan.

Chez GNOME, ça ne change rien : on sait que ça sort tous les 6 mois.

Euh, donc tu penses que faire des release "time-based" est une justification pour utiliser la numérotation actuelle de Gnome. Tu peux détailler tes arguments ?

De nouvelles releases mineures sont faites après la sortie officielle pour corriger les plus gros bugs passés à travers des mailles du filet lors de la validation de la version de développement.

Oui, comme pour à peu près 95% des projets logiciels.

Du coup les versions x.y avec y impair servent juste de convention pour les alpha/beta/rc de la version x.(y+1),

Donc ça, je pense que j'avais compris.

et ont l'avantage de permettre une comparaison numérique (pas de alpha/beta/rc dans le nom de la version)

Bon, c'est un bon argument, mais orienté vraiment très très développeur. Et des projets qui utilisent le vocable alpha / beta / rc / preview arrivent quand même à faire des numérotations de versions qui se comparent numériquement.

On peut donc indiquer que telle fonction est obsolète depuis GTK 3.3.90, ce qui est plus précis pendant le cycle de développement que de dire que c'est obsolète depuis GTK 3.4.0.

Euh, tu veux dire que 3.4.0 , c'est moins précis que 3.3.90 ? De quel point de vue ?

Bon, c'est une petite pique cette histoire de version. Mais autant je comprends que des vieux projets comme apache ou samba utilisent encore cette façon de faire (ah tiens non, samba a arrêté depuis longtemps il semblerait), autant pour un projet qui se veut aussi moderne et dans le vent que Gnome, je trouve ça ridicule.

Le vraie problème, c'est que faire un desktop normal comme c'était le but de KDE ou Gnome il y a 10 ans, c'est devenu ennuyeux. Ce qui est fun maintenant, c'est les tablettes. Et les développeurs ont l'air d'aimer le fun, ou aimer croire qu'ils vont faire des trucs funs.

Donc les projets ont été convertis de force au monde des tablette alors que fondamentalement, c'était des desktop.

Moralité : vive XFCE.

J'ai volontairement utiliser les deux verbes, d'une part simplifier et d'autre part abêtir car je fais tout à fait la distinction. Je suis un grand fan de la simplification et de ce qui marche tout seul. Et de l'ergonomie intelligente.

Mais je suis contre « l'abetisation ». De mon point de vue, Gnome fait les deux en même temps.

Un truc qui me chiffonne sous Gnome, c'est d'avoir adopté une pratique de numérotation de version qui au moment où ils l'ont adopté, était déjà obsolète. Maintenant que même Linux a renoncé à ce système, que reste-t-il comme argument pour le défendre ?

Vis à vis d'un bureau qui se veut accessible au quidam novice en informatique, comment vous lui expliquez que il rate à chaque fois des mises à jour puisqu'il saute des versions ?

D'ailleurs à part Gnome, qui utilise encore des versions paires et impaires, surtout dans l'ère des gestion de sources décentralisés ?

Alors, il faut quand même pas exagérer: quand on utilise le vocable "ultra-expérimental", "essayer", "tatonner", "semblent", on est vraiment très très loin du domaine scientifique où une loi est établie et on peut s'appuyer dessus.

On est dans l'expérimentation, le brouillard, les annonces de campagnes politiques, les essais. La science commence en effet par ne rien savoir et découvre. Mais on est tout autant dans l'art et de l'artisanat que dans la science dans ce cas précis.

Donc dire "c'est une science, ferme ta gueule si t'es pas d'accord avec les choix qui sont faits", c'est vraiment du n'importe quoi.

Surtout que l'ergonomie est quelque chose de très subtile. Il y a des paramètres psychologiques, des paramètres sociétaux, liés aux habitudes, qui varient dans le temps.

Les utilisateurs qui ne connaissent que Windows trouvent le Mac pas ergonomique du tout. Tu peux aussi fabriquer des nouvelles habitudes d'ergonomie. Le coup du redimensionnement de la photo sur un téléphone est par exemple peu intuitif à la base (= tu peux pas savoir si tu ne l'as jamais fait ou vu faire) mais très ergonomique à l'usager. Alors que le réglage du son sur un Ipod est ergonomique et intuitif.

Bref, ce qu'il faut retenir (et je rejoins patrick_g à 100%), c'est que l'ère des bureaux qui proposent une interface générale en acceptant tous les composants extérieurs est révolue. Le but de Gnome, (tout comme Ubuntu et peut-être aussi pour le Spark de KDE, à voire …), c'est de proposer une interface controlée uniquement par Gnome et les autres éléments extérieurs sont priés de se ranger dans la catégorie "truc mal foutu que l'utilisateur utilisera que si il fouille son grenier et qu'on lui met le couteau sur la gorge".

C'est sur que c'est un choix qui se défend d’abêtir et de simplifier les interfaces pour l'utilisateur. Mais je trouve ça triste que ce soit maintenant le futur des bureaux Linux, plutôt que la recherche de la qualité, ce la compatibilité et l'acceptation de la diversité qui était auparavant leur roadmap.

C'est au contraire un système que se prête très bien aux tests unitaires et aux tests fonctionnels.

Donc la réponse à la question est non, il n'y a pas de tests unitaires bien que ce serait très facile à tester.

Je plussoie. Etant moi-même très pragmatique, je suis souvent d'accord avec les arguments avancés par Zenitram. Et je dois dire que je trouve l'auteur de ce journal complètement à côté de la plaque.

Visiblement, dès qu'on ne se complaît pas dans l'idéalisme du libre et qu'on s'en retourne aux stricts définitions de la GPL, on est vite incompris ici.

Cependant, cher Zenitram, j'ai moi aussi des critiques à émettre vis à vis de ton propos systématique.

Il est vrai que quand on remonte à la définition même de la GPL, le receveur d'un logiciel libre n'a nulle obligation vis à vis de l'auteur du logiciel. Et même, le fournisseur du logiciel n'a d'autres obligations que de fournir les sources de sons logiciel à celui qui l'utilise et à personne d'autre (je ne t'ai d'ailleurs jamais vu troller à propos de ce sujet pourtant trollifère, la non distribution des sources au grand public est 100% compatible avec la GPL).

Et pourtant, la communauté du logiciel libre en général s'est aussi construite sur d'autres principes, non écrits, mais qui existent réellement. Ne serait-ce que celui de rendre disponibles les sources des logiciels libres "au grand public" et pas seulement aux utilisateurs du logiciel.

Je défends pour ma part que envoyer des patchs en upstream fait partie des "bonnes pratiques" de la communauté et permet d'entretenir un écosystème sain, même si ce n'est pas une obligation. En particulier quand un logiciel libre est au coeur du succès d'un autre projet ou d'une société, je trouve ça raisonnable d'attendre une contribution en retour sous forme de patch quand c'est possible, ou sous une autre forme : retour de bug, donations, sponsor, matériel [1].

Si tout le monde s'en tenait à la définition stricte de la GPL, la communauté et l'écosystème des logiciels libres n'existeraient pas.

Par ailleurs, beaucoup de logiciels libres sont publiés sous GPL, mais combien d'auteurs comprennent réellement la portée de cette licence ? Le fait qu'elle soit massivement répandue la rend incontournable et les problèmes de compatibilité de licence fait qu'il est difficile de publier sous une autre licence, moins opensource [2].

Je pense comme tu le soulignes que certains auteurs préféreraient une licence CC-BY-NC pour leurs logiciels mais n'y ont pas réfléchi à temps. Du coup, argumenter sur le fait que le respect strict de la GPL représente bien le souhait de l'auteur est quand même biaisé.

Le fait qu'il y aie une GPL v3 et même une AGPL montre bien que la GPL ne réflétait pas que "la stricte et l'unique volonté de l'auteur initial dans les obligations qu'il t'impose" mais qu'il y avait bien d'autres obligations non explicites (et parfois qui ne pourraient être légales) vis à vis du logiciel libre, et que ces nouvelles licences tentent d'en capturer une nouvelle partie.

En conclusion, bien que souvent d'accord avec ton pragmatisme, je trouve que ton raisonnement uniquement centré sur la définition de la GPL confine à l'étroitesse d'esprit.

Voilà.

[1]: par contre, dire que Ubuntu ne contribue pas à l'écosystème du logiciel libre en comptant ses contributions au noyau Linux, c'est avoir vision assez pauvre de ce qu'est le monde du logiciel libre.

[2]: normalement, vous ne devez pas laisser passer ce troll: soit on est Open Source, soit on l'est pas mais on ne peut pas être "moins" Open Source.

Perso, j'ai cependant un faible pour la licence CC-BY ou l'ancienne licence MIT avec clause de publicité. Mais elles sont incompatibles avec la GPL, donc je ne les utilise pas. Pour un logiciel libre que je développe en Python + PyQt, je choisira bien une telle licence, mais acheter une licence Qt + une licence PyQt rien que pour ça me semble un peu cher. Donc allons y pour la GPL imposée, je respecte la volonté des auteurs des logiciels que j'utilise mais je me sens légèrement contraint. D'ailleurs, l'ancienne licence de Qt était plus permissive mais les gens râlaient parce qu'elle était pas assez GPL.

Je dois dire que tout comme Zenitram, je trouve ton raisonnement extrêmement limité.

Rares sont les logiciels propriétaires qui fonctionnent tout seuls, ceux-ci nécessitent toujours dans mon expérience une installation, configuration, administration, maintenance, support. Toutes ces activités doivent en général être réalisées en local, dans la langue de l'utilisateur. De ce point de vue, le logiciel proprio génère de l'activité locale.

Cela est vrai aussi pour le logiciel libre.

Des développements sont nécessaires pour adapter le logiciel à l'environnement local ? Mais c'est pas comme si Microsoft n'avait pas d'employés en France, on peut considérer que la prise en compte des problématiques locales génère aussi de l'activité en France.

Ensuite pour les nouvelles versions des logiciels majeurs sont développés dans le pays du fournisseur de logiciel. Si on prends une distrib libre par exemple, on est sur que tout le licensing et probablement une partie du support ira .... à RedHat, Suse, Ubuntu, entreprises notoirement françaises !

Pour être sur que l'argent reste en France, il faut choisir des logiciels dont le développement se produit en France. Mais l'équation est la même que le logiciel soit propriétaire ou libre dans ce cas. Voire, si on prends les logiciels libres en général, j'en connais vraiment peu dont le dev est réellement en France. Il me semble que l'industrie du logiciel propriétaire est bien plus française que l'industrie du logiciel libre.

Reste le cas des logiciels développés à façon en France, pour des français, par des français. On est sur que l'argent reste en France pour ceux-là (et encore ...) mais la situation est la même que le logiciel soit libre ou propriétaire.

Perso, je pense que ton raisonnement ne tient pas beaucoup. Le logiciel libre a des qualités qui font qu'ils méritent d'être considérés par les pouvoirs publics. Mais leur avantage en terme de relocalisation de l'emploi ne me parait pas évident du tout.

Par contre, il est clair que le logiciel libre est bien adapté à des opportunités locales, dans le cas où le logiciel demande une forte adaptation à l'environnement et un service de proximité. Les entreprises de logiciel libre étant beaucoup tournées vers le service, ça se marie bien. Le logiciel libre a aussi une culture de la réactivité et de l'adaptabilité qui convient bien à ce type de marché. Mais c'est pas comme si il était pas aussi accessible au monde du propriétaire.

Entre un logiciel de compta écrit un python + django par une boite française, livré sous licence libre, et un logiciel de compta écrit en ASP.NET écrit par une boite française, livré sous licence payante, je ne vois pas beaucoup de différence en terme de relocalisation de l'emploi...

J'avais essayé de l'utiliser mais, malheur à moi, je faisais du ssh sur une machine linux depuis un terminal sous Windows. Et, cela créait des problèmes douloureux d'encoding, car le codepage de mon terminal Windows ne savait pas afficher ce que weboob voulait afficher...

C'est résolu ?

Intéressant cette histoire de patch. Dans les projets où on est plusieurs, j'estime que tous les patchs doivent avoir été relu par quelqu'un. En général, c'est en post-commit via une mailing liste qui mail un diff de tous les changements.

Ce processus fonctionnait super bien avec svn, mais avec du décentralisé, c'est un poil plus compliqué. De ta description, j'en conclus que tu relis tout ce qui est poussé vers ta branche avant intégration. Et donc tes commits arrivent directement sur cette branche et ne sont pas relus par les autres...

A mon avis, tu devrais te plier au même processus que les autres. Non pas pour t’embêter, mais pour que tes collègues puissent relire tes patch. Personne n'est à l'abri d'une erreur à la con...

J'avais interviewé Guido Van Rossum au FOSDEM il y a quelques années et je l'avais interpellé sur le fait qu'il arrivait avec un Windows XP. Il m'avait répondu que ça lui posait aucun problème, et qu'il utilisait un certains nombre de gadget hardware qui ne fonctionnent que sous Windows XP...

D'ailleurs, le libre est-il réduit a un PC sous Linux ou sous BSD ? Quid des logiciels qui sont censés être portables, ils ne doivent être testés que par des non libristes ? VLC, Firefox, KDE, KDiff3, mplayer, Wireshark, TortoiseHg, Mercurial, SVN, PGP, Python, Qt, Audacity, Truecrypt pour ne faire que la liste de ceux que j'ai sur mon Windows.

Pire, quid des logiciels qui n'existent que sous Windows, et qui sont sous GPL. Ceux-là sont-ils vraiment libre d'après ta définition ? Ont-ils droit de cité au FOSDEM ?

En fait, les utilisateurs de MacOs que tu as vu ne faisait que tester la portabilité des soft Gnu écrits que pour Linux et faisaient des reports de bugs!

J'ai construit mon argumentation en référence à Grunt qui encense usenet. D'où les références à NNTP et aux questions cons.

Il est vrai que pas mal de communautés de logiciel libre sont très accueillantes même pour les débutants.

Pour ce qui est de la capacité des outils pre-stackoverflow à fournir des réponses à des problèmes ... c'est loin d'être aussi rose que ce que tu présentes. Depuis que je fais du logiciel libre et que je cherche des réponses sur le web, j'ai bien plus souvent trouvé deux ou trois mecs qui ont posé la même question 3 ans avant, sur une mailing liste, et auxquels personnes n'a répondu, mais dont on retrouve la question 20 fois du fait des archives et duplication qu'autre chose.

Les fois où j'ai trouvé pile la réponse à mon problème dans des archives de mailing list sont en fait plutôt rare si j'y réfléchis.

Alors que depuis StackOverflow, je trouve régulièrement et facilement des réponses à mes questions. A mon sens, StackOverflow fait bien plus que "pomper des communautés existantes", il motive des gens à répondre à des questions. Il y a donc plus de questions et plus de réponses sur le site.

Pour ce qui est de la centralisation, y a-t-il une réelle différence entre un projet qui centralise les questions réponses sur une mailing liste archivée et consultable, par rapport à StackOverflow dont le contenu est archivé et consultable.

c'est "bien" parce que tout le monde est dessus (pour diverses raisons : buzz, notoriété du fondateur, interface ludique...).

C'est marrant, tu as oublié plusieurs raisons. Ce serait surtout pas de la mauvaise foi de ta part. Je répars cet oubli:

c'est "bien":
- parce qu'on peut poser une question con, même sans installer un client nntp et obtenir une réponse utile (on a le droit de débuter)
- parce qu'on peut trouver des réponses à ses questions, cons ou intelligentes

T'as le droit de pas aimer StackOverflow, mais ton argumentation est pas super solide.

Stack Overflow, ses algorithmes comme ses administrateurs, n'ont aucune légitimité particulière pour accorder des « récompenses »

Ce n'est pas StackOverflow qui attribue des "récompenses", ce sont ses utilisateurs. Tu trouves qu'une réponse est pertinente, tu le signale et voilà. Le système ne fait donc que collecter du feedback utilisateur. Aucun des badges d'ailleurs ne te fait passer pour quelque chose que tu n'es pas (genre "Expert"). Au contraire, les badges parlent soit de ce que tu as fait en tant qu'utilisateur, soit de ce que les autres ont pensé de tes actions.

Et pour ce qui est de la légitimité, je vois pas pourquoi StackOverflow n'est pas légitime à décerner un badge "bonne question" pour une question que 10 personnes trouvent bonne.

Quant à la validité des badge d'un point de vue professionnel, il me semble que le système se défend pas mal. J'ai jamais reçu de bonus significatif pour les questions triviales que j'ai posées ou auxquelles j'ai répondu. Par contre, pour des réponses "chiadées", c'est à dire que c'est un problème compliqué à résoudre et que après l'avoir résolu, tu tombes sur quelqu'un qui a le même et tu lui balances ta solution, j'ai justement gagné beaucoup de points ou de badges. Et idem pour des questions que j'ai posé sur des trucs non triviaux. (d'ailleurs, j'en ai très peu vu que c'est pas tous les jours que tu peux trouver un truc super intelligent à répondre ou une question super intélligente à poser).

Sinon, avoir de l'expérience dans un domaine, c'est être aussi capable de résoudre des problèmes très variés lié à ce domaine. Sans prétendre que StackOverflow mesure ça précisément, je trouve que ça propose un bon reflet de la réalité.

Sinon, pour ce qui est de usenet (ou des mailing liste dédiées à des projets, ou encore des channels irc), le taux de réponse est assez aléatoire. Perso, j'ai bien plus souvent eu des déconvenues sur le sujet que ce que les libristes imaginent.

Pour prendre un exemple récent, je fais de l'automation COM en Python. Le sujet est assez pointu et c'est un sujet de niche. Si je n'avais compté que sur la mailing list python ou les doc microsoft pour m'en sortir, je serai encore dans les choux. La communauté StackOverlow là est sufisamment large pour que j'ai trouvé non seulement des gens qui ont le même problème que moi, mais aussi la solution...

Un gros malus, ce serait beaucoup de -1 et ta question supprimée. Dans le cas présent, le site t'a "éduqué" et tu as appris. Rien de bien méchant mais je note que la note "sociale", fonctionne bien puisque tu l'as pas super bien pris.

Le fait que les questions doivent être claires et fermées est à mon avis logique. C'est un site pour trouver une réponse à un problème, pas un site de débat. Surtout qu'avec une audience de plusieurs millions de personnes, difficile de débattre autrement que sur un sujet très très très précis.

Pour ce qui est des badge, c'est logique que le fait que tu soit expert en java ne te donne pas d'office un statut d'expert en recette de cuisine ou en droit.

Perso, je trouve le concept super et très cohérent. Ce matin, ça m'a résolu un bug auquel j'aurai à mon avis jamais trouvé la solution. J'ai deux-trois questions où ça m'a bien aidé et à une époque, je me suis amusé à me faire monter mon ranking en python (mais il faut se ruer sur les questions pour y arriver).

Cette notion que casser des programmes qui marchent, c'est toujours "les améliorer" me fatigue. Un programme qui a été développé, qui marche bien, qui est en prod depuis plusieurs années, pourquoi devrait-il être modifié ?

Perso, je me suis arrêté aussi au titre.

Un crime ? Un crime en France, c'est un meurtre, un viol ou quelque chose de tout aussi violent. Même dérober des millions d'euro va plutôt s'appeler du banditisme que un crime.

Le terme me parait totalement inapproprié. Comparer la fermeture d'un site qui flirte consciemment avec la légalité au fait de tuer quelqu'un avec préméditation ou de violer quelqu'un est vraiment ... triste. Si un jour tu as la malchance d'expérimenter de près un crime, je pense que tu ne t'amuseras plus à placer le mot de façon inconsidérée.

Megaupload, comme Napster en son temps savait très bien ce qu'il faisait et savait que ça risquait d'arriver un jour. J'espère juste que les accusations de blanchiment d'argent sont infondées, parce que si tel n'était pas le cas, ça rendrait ton article encore plus pathétique.

ps: "crime" en anglais se traduit par "délit" en général. Mais forcément, ça fait moins mélodramatique.

Ce qui me surprend, c'est que tu ne présupposes pas que c'est aussi le boulot de weboob de vérifier si une version plus récente du module qu'il utilise n'est pas disponible.

Weboob étant plutôt en ligne de commande, c'est peut-être pas approprié pour tous les appels, mais ça me parait quand même approprié:
- pour les applications construites au dessus de weboob (applications graphiques)
- en cas d'erreur renvoyée

Avec les lavables ça n'absorbe pas

Je n'irai pas jusque là. Cela absorbe mais moins qu'une couche jetable. La couche reste un peu mouillée, c'est tout...

Non mais, vous y allez fort dans l'excuse la plus bidon que vous pouvez trouver pour défendre vos idées.

C'est toi qui y va fort ! Je ne sors pas des excuses bidons, je te parle de mon expérience. Dirai tu que je te mens juste pour te convaincre ? Dans la commode, j'ai du réserver un tiroir au complet pour les couches jetables alors que j'y mettais avant des lavables et d'autres trucs.

Il y a surement un effet psychologique: comme on risque toujours de manquer de couches car elles sont consommées, on en stock plus alors qu'en lavable, on a toujours un stock pour une journée à peu près. Surtout qu'étant un peu plus grand, il a besoin de 4-5 couches pour une journée complète, donc ça prend vraiment peu de plac

les couches jetables donnent une odeur bizarre à la couche.
Voir les autres commentaires... (voir juste au dessus pour le reste du bla bla à ce sujet)

Donc je précise: avec les deux marques de couches jetables que j'ai essayé, l'odeur après pipi n'est pas du tout un odeur de pipi. Apparemment, je ne suis pas le seul à avoir fait cette expérience. Il est donc tout aussi faux de généraliser le fait que les couches jetables ne donnent aucune odeur que le fait qu'elles en créent une. Ton expérience est seulement différente de la mienne.

Le nettoyage des fesses était plus simple.

Par quel miracle le caca collé au fesses du bébé ne colle pas avec les couches lavables??? Désolé, mais j'ai beaucoup de mal à imaginer la chose, surtout que ce que j'ai vu avec les lavable c'est plutôt le contraire dans la pratique)

Nos expériences diffèrent alors. Quelqu'un a expliqué mieux que moi plus haut comment ça se passe concrètement.

L'étendoir à linge a fait partie de notre mobilier de salon pendant deux ans.
Mmm... Ca donne vachement envie.

C'est clair. J'aime pas trop mentir sur les inconvénients réels, je ne cherche pas à faire croire à un truc miracle.

Les lavables, c'est aussi un poil plus de boulot puisqu'il faut les étendre tous les soirs, nettoyer un peu le seau régulièrement, etc.

d'autres halte-garderies refusent avec des arguments ... peu argumentés

"Vous me les brisez avec vos couches à gérer, j'ai d'autres choses à faire avec le nombre de bébés que j'ai, que de gérer vos conneries" est pour moi un argument parfaitement valable.

C'est un argument que j'aurai pu entendre aussi mais ce n'est pas celui qu'on m'a donné. En l’occurrence, on m'a juste dit d'aller me faire foutre parce que ça avait été décidé comme ça.

Pourquoi en l'absence d'information, tu supposes aussitôt la mauvaise foi ? En tout cas, les autres haltes-garderies ont apparemment réussi à survivre avec des couches lavables. Les puéricultrices a qui j'ai présenté la manip ont été surpris à la fois de la simplicité et de l'absence de contrainte. Tout comme pour les couche jetables, elle doit avoir le sac du bébé à porté de main avec nouvelle couche nouveau vêtements éventuels, etc. Une fois le changement de bébé fait, elle doit mettre la couche lavable dans un sac dédié plutôt que la poubelle. Ça doit bien faire 20 secondes de différence...

Mais depuis le passage au jetables, elles absorbent mieux et il ne voit pas l’intérêt du pot ou des toilettes....

Serait-ce un aveux que les couches jetables, c'est quand même mieux?

Honnêtement, je ne sais pas si ça permet de dire que c'est mieux. Le fait que les fesses soient moins mouillées ne change pas le fait qu'elles restent en contact avec une partie du pipi. Alors qu'avec des lavables, on le changera plus vite.

Le fait que la propreté arrive plus tard en jetable peut s'avérer problématique. Pour mon fils, je stresse un peu pour l'instant car même s'il reste encore 8 mois avant son entrée en maternelle, s'il ne devient pas propre d'ici là, ce sera un gros problème.

En tous cas, le niveau pour réussir à se justifier est sacrément élevé, bravo pour l'imagination.

Je ne justifie rien, je parle de mon expérience. Les gens font le choix qu'ils veulent, ça me fait ni chaud ni froid. Mais c'est toujours intéressant de savoir comment ça se passe ailleurs. En l’occurrence, je trouve que c'est plutôt toi qui est de mauvaise foi, interprétant tous mes propos comme des tentatives de propagandes. A te croire, j'utilise mon imagination plutôt que des faits réels. Dit autrement, tu penses que je mens pour te convaincre. Tu as faux dans les deux propositions, je ne mens pas et je n'essaye pas de convaincre.

Il reste un argument subjectif et non argumenté scientifiquement qui m'a fait choisir les couches lavables, que je n'ai pas encore présenté. C'est le fait que la composition des couches jetable soit tenu secrète (elle n'est pas indiqué sur les paquets et ce n'est apparemment pas obligatoire). Les fesses de mon bébé sont en contact avec une matière "chimique", puissant absorbant, pendant presque 3 ans en continu.

Je n'ai aucune confiance dans l'absence d'effets à long terme du à ce contact prolongé et je pense (peut-être naïvement) que du coton bio sera beaucoup moins délétère pour la santé de mon enfant.

Comme je le dis, c'est non argumenté, mais quand on voit les récents scandales médicamenteux ou industriels, on mesure bien que pour toute activité industrielle, l'efficacité d'un composé chimique ou produit passe avant l'analyse de nocivité à long terme sur les individus. Et qu'ils n'hésitent pas à sortir la grosse artillerie si tu t'avances à te poser des questions contraires à leurs intérêts économiques.

Merci, c'est tout à fait l'expérience que j'ai. Alors Zenitram, je ne prétends pas te fournir une explication scientifique du pourquoi et du comment, mais je constate juste que en 3 mois de couches jetables, le nettoyage du caca est devenu une corvée alors que ce n'était qu'un désagrément auparavant.