bubar🦥 a écrit 6992 commentaires

Encore une fois il joue sur les mots.
PA sur des téléphones ? Non pas exactement. PA sur les systèmes de certains téléphones. Systèmes. Les contraintes GSM et téléphonie pure mettent ko pulseaudio. PA se contente de mixer la sonnerie avec la musique, et de couper cette dernière lorsque le bouton "répondre" est actionné. PA ne peux pas supporter les hautes contraintes de gsm, il travaille à plus haut niveau.

En fait, PA est utilisé là où il excelle absolument : la politique. Il ne devrait pas faire serveur de son, il est pas bon pour ça. Il devrait se "contenter" de donner des ordres au serveur de son. Mais comme "ils ont des objectifs différents" (sic) p.a et jack continueront de se marcher sur les pieds sur les fonctions essentielles.

Comme quoi, même les utilisateurs les plus avancés n'aiment pas les changements imposés, même les plus simples, et sur les interfaces les plus simples

(...)

Imr, je crois (il me semble) qu'on est d'accord sur pas mal de choses, et entre autre là, sur ce bourrage de mou permanent qu'opèrent certains. Quant les mêmes ne s'amusent pas à faire touner en bourrique les utilisateurs... (du genre passer une demi heure avec un utilisateur sur un bug, en le disant lourdement bien dire à chaque moment "toi utilisateur tu es en bas et tu a de la chance que je t adresse la parole."
Mandriva a trop changé, du moins certains ont trop changés pour moi. Moi aussi certainement, mais je reste simplement le pragmatique que j'ai toujours été. Quant Debian ou la FSF écrit "c'est pas libre ça pu" j'écoute et je lis, ça me fait réflechir. Mais tout le monde n'est pas Debian ou la fsf. L'illustration au dessus c'était juste pour dire que tout le monde dit ou fait des conneries, on ne peux pas juger de manière lapidaire et définitive sur qq mots ou qq conneries.
Enfin, pour rebondir (en h.s ici) sur ton questionnement sur les developpeurs et les choix qu'ils font, moi avant d'aller critiquer les dev je critiquerais l'encadrement de certaines boites du "libre" qui n'hésitent pas à virer, à laisser partir, à ne pa retenir juste parcequ'ils se disent "c'est libre on retrouvera qq un" et finir par vider un projet de tout les gens qui en sont l'essence réelle, le vrai coeur.
Imr, merci pour tout, pour ton accueil à l'époque, pour ta constance, pour ta patience pour ta compréhension, et c'est vraiment dommage qu'il n'y en pas plus des imr...

en même temps, il est très facile, imr, de retrouver certains de tes posts sur un forum où tu le fait aussi le coup du "c'est pas liiiibre" .... Donc, bon...

Tiens, : google recherche "imr libre pas libre" sur le fofo en question :
http://forum.mandriva.com/viewtopic.php?t=60885
Où tu fais la leçon de morale "c'est pas libre en plus reversent rien c'est que des méchants" à un utilisateur qui trouve ça juste bien d'avoir des jeux sur son linux... Et la recherche, elle en donne des exemples ou tu cris "c'est pas liiiibre" aux autres.

moi j'me casse et regarde avant tout mes erreurs, et ne rejete pas ce qui me fait me casser sur les autres même si certaines m'ont vraiment gonfler, oui, du genre le très bon exemple que tu donnes ailleurs sur linuxfr. Mais je regarde d'abord *mes* erreurs. Après tout chacun est liiiibre.

C'est intrinsèquement lié à la notion même de groupe.

"C'est comme dans Lost,
Il y a les autres, et ils sont bizarres"
(...)

ps : le "c'est souvent poilu" il s'est pris un coup de rasoir ? :)

ouhai certainement qu'on exprime mal par demi exagération.
cet exemple de conso cpu excessive est souvent lu parceque tout simplement on est nombreux a l'avoir vu, et souvent.
mais cela ne va pas dire que pa consomme *tout le temps* beaucoup.

moi j'ai juste du mal à saisir le pourquoi ...
pourquoi pa parfois se met à bouffer 15 de 2 xeons à 3ghz alors qu'il ne mixe que 2 flux. 2 flux. Et paf il se fait une monté sur les cpu, comme ça, pendant qq secondes. Cela fait un peu peur.

Pour rendre justice, j'ai collé les 2 mêmes xeon à 96% d'utilisation chacun pendant plusieurs heures d'affilé avec Jack. Mais jack a un côté rassurant : il s'emballe pas tout seul. C'est proprotionnel à la charge demandé : pour 64 pistes dont de nombreuses qui sont trafficotés avec des effets ou d'autres sots, avant d'atterir dans l'enrgistreur, et le tout avec une config de jack un peu folle... Jack bouffait alors 96% des cpu pour faire ça, tenir ce cahier des charges.
Par contre je n'ai jamais vu jack se faire des montées sur cpu tout seul sans raison, sans demande.

FreeBSD et OSS sont les meilleurs exemples que Jackd peux tourner sans problèmes sur des systèmes où les contraintes seront plus simples (attention me faite pas dire ce que j'ai pas dit :p) que le "super studio" et illustrent parfaitement que jack peux aussi remplir à merveille le rôle d'une belle "interface" pour tous.

Je connais encore moins freebsd que linux, c'est juste que les noyaux ont pris des chemins bien différents et qu'il est est difficile de demander à freebsd de remplir un cahier des charges tel que celui ci : "64 pistes dont de nombreuses sont re-routées et travaillées au moins une fois avant d'être "piste" sur l'enregistreur. Le tout tenant une latence sans faille de 0,002millisecondes (...)". Pourtant jack fonctionne très bien en dehors de ces contraintes un peu folles. "qui peux le plus peux le moins". Et sur un desktop freebsd, avec oss pour le noyau, jack met en valeur ses autres atouts : proposer un routage aisé et efficace. Franchementc'est sympa de faire un seul glisser déposer pour enregistrer une conversation ekiga avec audacity...

pour moi c'est pas au core du serveur de son de s'occuper de cela. C'est à kio / Dbus ou whatever, parfois épauler par / ou directement udev, de s'en occuper : en charge d'une politique de fonctionnement. Le serveur de son lui il sert du son, il le route. Il reçoit un ordre "coupe tout sauf x" ou "additonne x et y et route vers z", et exécute cet ordre. Mais ce n'est pas à lui de réflechir au pourquoi.

Vivi
Et sur ce même évènement on peux dire que Canonical en sort en fait grandi, grâce à l'attitude cette personne. Elle a pas "pété plus haut que son cul" si vous me permettez l'expression, en ne se trompant pas de hierarchie pour lui, en posant la question ailleurs d'abord. Donc Canonical a du personnel compétents et attentifs. Pas du gros cadors partout, malheureusement pour eux (vais pas paraphraser ce qu'as dit GeneralZ un peu plus haut sur ça précis) et pour tout le monde. N'empeche que le type il s'est pas pris pour dieu le père et a fait son taf convenablement, proprement, à hauteur de ses moyens. Par cela il 'grandi' canonical (et tempère les insupportables triades de leur dictateur bienveillant).
Et puis ... faut reconnaitre que ce bug il est découvert chez ubuntu. Preuve s'il en est que ubuntu rempli son role, là : pas la distro pour entreprises certes, mais la distro la plus usitée et la plus active en terme d'utilisateurs.

c'est effectivement possible. Si tu dé-installes quelques briques de pulseaudio, tu va alors retrouver uné dé-configuration complète des couches dessous. C'est bizarre j'ai pas creuser pourquoi le retrait de certaines briques de pa touchait et cassait la config de la brique au dessous, mais avec les paquets mandriva c'est effectivement possible. La solution est de relancer une interface pour alsa et dmix, comme aumix, afin de remonter les potards, sur la ou les cartes sons.

Autre chose, si tu dé-installes tout pa, le mplayer du paquet mdv va segfaulter à coup sûr. Il faut au minimum laisser la biblio principale, juste ce paquet suffit.

Néanmoins mdv propose draksound : un clique suffit pour ne pas utiliser pa et laisse l'utilisateur libre de ses choix : ceci suffit à utiliser facilement mandriva dans tout les cas. Le problème d'une casse si on touche au choix du système est alors secondaire car il n'est que dans un objectif de choix différent, voir de 'construction' d'une base différente. Et non de l'utilisation du système sans utilisation de pa.

Voyons comment utiliser Jack. Lançons lash_control
Là tu ne va pas voir comment utiliser jack, tu vas déjà lancer tout un cadre de travail.

pour permettre à quelques applications de faire pouet lorsque je clique sur un bouton il faudrait que tout un framework ait des permissions permettant de bloquer tout le système ? (...) Par design, Jack semble être tourné vers les pros.
+ 1
On retombe sur ton exemple au dessus : pour une utilisation lambda, il n'est pas nécessaire de donner tant de droits. Jack le permet : il sait fonctionner comme un serveur de son basique permettant de faire pouet quant je clique sur un bouton. On abandonne là ses possibilités spéciales en terme de latence, de traitement, et on se concentre sur ses possibilités de 'routeur' et de liberté d'action pour faire pouet.
Mais si la personne le veux, il peut alors, avec la même solution, "que tout un framework ait des permissions (...)" et avoir ainsi, avec une seule solution, une réponse à ses besoins là également.


La taille du code est ainsi réduite. Pourquoi vouloir transformer cela en un machin à tout faire ?!
encore + 1
c'est un des mes reproches envers pa (mais qui, je le repête, ne sont que des reproches d'utilisateur) : un truc qui veux tout faire. Moi ça me semble bizarre que soit au "core" de la gestion du son et de ses "routages" de faire également de la gestion évènementielle externe au son lui même. Quant le téléphone sonne, pour moi, ce n'est pas au "core" de gérer une politique de coupure des autres volumes... Quant à la gestion multi-cartes, moi il me semble que là non plus c'est pas son taf, là c'est plutot alsa lui même.

Que je sois con pour ton toi c'est ta constatation ou ton droit.

'est au moins de lire ce qu'il raconte,
Tu exagères : crois tu que je ne sois pas aller lire son blog ou/et les échanges sur les principales listes ?

PA et Jack ont des objectifs TRÈS différents
Cela n'a pas toujours été le cas : pa devait amener l'unification des fonctions de gestion du son et de plus être adoptés de manière uniforme.
Ensuite je ne reproche pas cela à pa, au contraire. Je pose des questions et rale un peu sur l'impression et ma constatation d'utilisateur que pa ne permet pas et ne permettra pas dans un futur proche de remplir cette fonction d'être là pour tous.
Enfin les objectifs différents je marre dessus, si tu permet ces expressions ...

Si tu espères une aide sur linuxfr, va sur le forum
Ai je demander un support ? Les commentaires des dépêches et journaux sont ils fait pour cela ?

oui c'est vrai tu as raison, dans tout les sens à cette phrase, c'est vrai, désolé, oui

Oui mais c'est également vrai qu'il s'agit là d'un comportement d'une personne. Donc c'est vrai que la manière trollesque de présenter l'évènement (que j'adore :p ) c'est exagéré. Auriez vous préféré que la personne ai fait ce post sur le bugzilla du projet directement ? Peut être que cette personne a juger judicieux par rapport à ses connaissances du sujet de soumettre en premier lieu à redhat (heu pardon, fedora) afin de voir ce que fedora en pense et de le reporter au projet ensuite ou de laisser fedora faire selon son choix. Sur cet acte réel et bien concret, effectivement cela découvre ubuntu (heu pardon canonical) comme n'ayant pas les compétences recquises sur le sujet, mais peut être que cette personne au final a eu raison de procéder ainsi ? Pourquoi reporter au projet si ce n'est pas assez précis, avec des pistes de solutions voir mieux, et si cela ne puisse être fait sur un terme plus long qu'un seul rapport ? On peux voir le même évènement comme quelque chose de positif, du moins pour la personne chez canonical qui a procédé ainsi.
non ?

/mode jeje/
Je ne parlais pas de cette philosophie là, mais plutôt d'intégration et de propreté du système. Là on va se retrouver à coup sûr avec du Windows-like :
pulseaudio pour les taches courantes.
jack qui sera lancé par les appli pros.

C'est complètement con, j'attendais un PulseAudio qui soit capable de remplacer Jack.
Bien maintenant j'attends un Jack qui soit capable de remplacer PulseAudio.

J'attends en continuant de me demander à quoi cela a servi que les gens du kernel se décarcassent. jack aujourdhui il se lance en rt sur un kernel vanille par défaut, c'est fantastique. Et moi j'ai PulseAudio qui bouffe 40% de mon cpu le temps de router un flux vers une nouvelle entrée, et pendant qu'il fait ça, j'ai le temps de préparer un maté.

Bref, je fais aujourdhui le même choix que celui qui m'a conduit à conserver linux à mes débuts : j'ai quelques restrictions certes, avec jack, mais je sais que là il y a qq chose de meilleur.
/mode/

Non, jackd ne fait pas cela par défaut.

Tu soulèves le point essentiel : l'intégration michu-ready.
Pulseaudio a toujours eu cela en ligne de mire, en objectif primaire (avant même un fonctionnement correct). On a tous constaté que PA faisait des trucs sympas de ce style, mais que d'un autre côté il était capable de consommer 12% de 2 xeon à 3ghz juste pour mixer 2 sources. Y a du bon et du moins bon. J'essaye de ne pas juger. Après toutes ces années, PA commence tout juste à faire ce genre de choses.

Il s'agit là d'un exemple de scénarios de fonctionnement. Un de ces exemples qui rendent le desktop linux meilleur. Meilleur dans la mesure où cela ne l'ampute pas ailleurs... Parceque si c'est juste pour couper le son de la musique quant un appel est reçu et que cela se fait au détriment des développeurs audio de linux, je ne sais plus quoi penser.

Il a peut être là une grave erreur de design, mais je ne peux pas vraiment le savoir, je n'ai pas les compétences pour.

Pour revenir à ton exemple, il illustre la demande de routage automatique de flux audio, ainsi que de politiques appliquées par défaut à ces flux. Revenons sur terre : il s'agit là de théorie, car même la dernière Ubuntu, la dernière Fedora et la future Mandriva ne permettront pas cela par défaut. Nous sommes donc dans un exemple d'objectifs, et pas un exemple de réalité.

La dissociation des flux audio et d'informations sur l'audio dans jack2 permet de pouvoir jouer sur cela sans perturber les capacités réelles du serveur de son. Jack peux déjà faire de la "synchronisation" de fonctions sur les flux, en fait il a toujours pû. Il est possible de stopper la lecture d'une piste (et donc de toutes les applications de cette piste) en en gardant une autre. Il est possible de faire une appli par pistes ou une multitudes d'applis sur une piste. Donc en théorie c'est possible aussi... Mais là encore on est dans la théorie car jamais personne n'a proposé des scénarios de fonctionnement pré-établis par défaut permettant de faire cela "automatiquement out-of-the-box). Théorie car Jack ne s'occupe pas de cela, il permet de le faire, nuance de taille. On peux reprendre l'adage "il fait une chose et la fait bien".
Par contre il est intéressant de regarder du côté de la "grande bataille des sessions" (des solutions permettant de faire cela : enregistrements de sessions et prévision-intégration de fonctionnements, de scénarios) car une excellente nouvelle est tombé récement : un mouvement d'unification des solutions jusqu'alors disparates :
http://linuxmao.org/tikiwiki/tiki-read_article.php?articleId(...) (lien en Français d'un des meilleurs sites au monde de musique sur linux (!) renvoyant vers les archives des diverses ML en anglais pour suivre l'évènement)

Jack fait une chose, et la fait bien. Jack_session en fait une autre et commence à bien la faire ... En fait on est dans le cheminement inverse de pulse : ils ont d'abord fait quelque chose de solide et de stable, consommant quasiment rien tout en répondant à un cahier des charges 'pros', et maintenant il est question d'intégration et de facilités... qui bénéficeront à tous y compris à moi ou mr michu...

PA permet le temps réel. Ils ont même fait rtkit, qui a aussi été implémenté très rapidement, afin d'éviter des rt-bombs. bon franchement rtkit il est moins réactif que le simple code de 200 lignes de das_watchdog... mais bon voilà, tout le monde s'est jetté dessus comme des morfales sur une tartiflette...

PA supporte donc le temps réel, mais c'est en théorie. Pour l'avoir trituré aussi pas mal (moins que jack mais quant même) c'est pas ça. Et là je ne jetterai pas la pierre à Pa, ne sachant pas si les pb ne viennent pas d'ailleurs ( de dbus par exemple ?). D'ailleurs Lennart lui même le dit : il déconseille d'utiliser PA en RT. C'est un "work in progress" (depuis plus de 2 ans...) Le support de Flash et du bluetooth ayant été des priorités plus importantes.

PA c'est juste le nouvel ESD, rien de plus, mais rien de moins. Un ESD en bien mieux, mais son auteur ne cesse de le répéter : PA n'est pas fait pour les fortes contraintes. Donc faudra pas attendre d'évolutions de ce côté là.

La seule voie actuellement possible c'est de faire comme sous Windows : un truc de base de merde mais qui marche bien pour les trucs de base, et des softs "Pro" qui implémentent en douce un jackd lorsqu'ils sont lancés. Bref, moi je comprends plus rien à la philosophie de gnu, en matière de son.

Il faut aussi compter le doublon présent dans Jack2 :
Jack2 fourni jackd, tel que jack1 mais ré-écrit en c++ donc, avec support des multi-coeurs.
Jack2 fourni aussi jackdbus, qui lui est beaucoup plus soumis à controverse (attention : de manière réellement objective).


Jackd de jack2 :
Il est logique que les distributions tendent à remplacer jack1 par jack2, pour et uniquement pour son jackd. On y gagne en fiabilité et en stabilité. Objectivement. Jackd de jack2 n'est jamais emporté avec une application qui plante sévèrement, ce qui a tjs été un point noir de jack. [C'est certainement possible, néanmoins je ne l'ai jamais vu, et pourtant je le maltraite fort et le pousse à bout, le jackd). Il n'est pas seulement question donc de portabilité, ni même de choix de langage : il s'agit là de débat allant bien au delà. Plus basiquement il s'agit d'utilisation : jackd de jack2 est objectivement meilleur que jack1.
Bravo à grame.fr ...

Jackdbus de jack2 :
il y a là un côté enfermement qui fait bizarre, avec les outils ladish. On aime ou pas. En tout cas une large majorité de développeurs Linux Audio ne semblent pas vouloir l'adopté, et quasiment aucune application ne supporte actuellement et ne s'oriente vers le support de jackdbus. On revient donc sur Ladish, qui apporte des éléments assez essentiels de manière facile : les enregistrements des studios [ie : on retrouve facilement toutes ses connections] mais d'un autre côté tout se passe dans ladish...
Et puis il y a le problème Dbus : je ne crois pas, avec mes humbles tests, que Dbus soit réellement prêt pour cela (les contraintes sont très fortes quant même). Au final jackdbus me semble quelque peu inutile, avec un arrière goût de ré-écrire la roue, et avec le danger de voir certains des atouts de jack disparaitre "parceque dbus utilisation" ... Là seul les dev peuvent vraiment dire en fait. En tant que simple utilisateur, j'ai des doutes quant à son utilité réelle.

Ensuite, on peux comprendre sans mal les réticences d'un côté comme de l'autre et la difficulté de rester objectif. Par exemple ce post de Lenard c'est du pur fud. C'est vraiment désolant de lire des billets pareil de la part de gens de cette valeur.
Il repart sans cesse sur son principe (qui n'est pas de base, qui a fait jour suite aux limitations de pulse lors de la confrontation avec l'utilisation IRL) : Jack et PA n'ont pas le même objectif. C'est vraiment chagrin de lire encore ça aujourdhui. Ce n'est pas faux mais c'est de la manipulation mentale : en mettant en avant le fait que Jack soit taillé pour de fortes contraintes, et en ne disant jamais, simplement, que jack peux tout à fait être utilisé en dehors de ces fortes contraintes. Un jack de base avec de grosses latences, un gros buffer, et avec tout simpement les softs qui se connectent à l'entrée système, c'est possible,.. Jack n'oblige nullement son utilisateur à avoir l'énorme panoplie décrite. Il peux le faire, il peux encaisser ces contraintes. Mais il peux aussi se contenter d'un pc de base et d'une utilisation de base.

Tout comme on peux comprendre la réaction des autres développeurs de jack1 devant le fait que jackd de jack2 est en train de remplacer jack1.

Moi je regrette juste que les distributions grands publics n'aient pas fait l'effort de porter jack au niveau Michu. Et se contenter de copier aveuglement le taf de redhat, dont ce dernier ce contre-fout : ni l'embarqué ni le desktop ne l'importe.

Voilà un constat dénué de prise de position :
D'un coté on a PA qui commence seulement à marcher normalement... pour faire le taf de base, mais qui ne sera jamais capable (dixit son auteur : c'est pas pour ça que PA est fait) d'assurer un cahier des charges à fortes contraintes.
D'un autre côté on à Jack, qui est capable de tout faire mais qui ne bénéficie pas de l'intégration nécessaire pour être michu compliant par défaut.
Actuellement aucun des deux n'est réellement valables pour un "meilleur desktop".

Alors que franchement, un icone "volume" lorsque tu cliques dessus ça te sort une interface où il suffit de glisser déposer pour modifier les entrées et sorties de tout les logiciels entre eux... je vous laisse imaginer l'impact que ça aurait pu avoir, c'est pas du volume par applil ça monsieur, ça va bien plus loin si vous le souhaiter.

mes 2 cents.

Le vrai problème dans cette affaire c'est qu'un produit vendu cher (dû à son équipement : une grosse 32go carte min-SD par exemple, font gonfler la note, l'appareil reste compétitif au vue de son équipement, il n'en reste pas moins très cher), donc un produit très cher et qui ne marche pas correctement : je lui connaissait vaguement quelques bugs, mais là, n'importe quel "modeur" Android fait mieux.

Pas reluisant.

Espérons que Intel va améliorer les choses... Sinon bye bye Nokia, numéro un mondial...

Pour comparaison, quant même : un HTC magic valait 150 euros avec abonnement (10 euros aujourdhui) : la conception globale est tellement bonne qu'il supporte sans problème une immersion totale dans de l'eau. Le matériel est tellement bon qu'il supporte sans broncher Android 2.1 aujourdhui (livré avec 1.5, mis à jour en 1.6 sans besoin d'ordi...) Le système est tellement bon qu'il supporte même le chargement de règles iptables sans pb si on veux. Et les applications sont tellement nombreuses que je ne citerai que Layar, CopPilot live, PicSay Pro..., que tout le système est Libre sous licences Apache et Bsd essentiellement mais aussi Gpl. Et que de nombreuses applis le sont aussi.
Donc bon, Nokia, il est mal barré, là.
Si avec un seul OS, une seule version et un seul téléphone, il arrive pas à faire ce qu'il faut...

Ca me ferai ch*** perso, parceque Nokia c'est Européen, Qt aussi. Mais bon quant on apprends que les mms ne fonctionnent même pas...

l'exemple de debian vs ubuntu, ou le fait d'avoir un dictateur benevole à vie fait que Ubuntu avance la ou Debian discutte,
C'est plus facile un dictateur. Y a pas photos.
Mais il y a alors le problème du dictateur.

La démocratie est plus difficile, car il faut savoir parler certes, mais il faut aussi savoir se taire et écouter. Le consensus et/ou le vote par majorité est souvent immédiatement frustrant pour certains.

Bizzarement les pays les plus puissants ont tous adoptés un mode intermédiaire dit de délégation. L'histoire nous montre tout les jours que le choix du dictateur n'est possible que par la capacité du dictateur. A long terme la démocratie gagne, toujours.

Le dictateur bienveillant est une utopie déresponsabilitrice qui ne fonctionne que temporairement. N'est pas dictateur qui veux...

Peut ête parcequ'il faut prendre en compte les habitudes. Des habitudes souvent anciennes, nous ne sommes pas formé à l'autonomie, mais à l'execution et au compte rendu. La formation, l'éducation du savoir faire, est dès le départ faite dans ce cadre. Les pédagogies de type Montessorie sont rares.

En responsabilisant, en habituant à l'autonomie, aux échanges et au travail mutuel, il y aurait bien plus de personnes prêtes à évoluer dans ce cadre particulier décrit par l'expérience de cette entrerprise. Pas toutes, mais bien plus.

Dans ce cadre d'autonomie élargie, il est essentiel il me semble de considérer le traitement global. Car si une autonomie élargie est appliquée au type de management que nous connaissons aujourdhui sous diverses variantes, cela serait à n'en pas douter une formidable arme à pression, effectivement. L'autocensure et la peur sont toujours plus efficaces que la censure.

Mais si ce cadre est correctement défini, alors chaque caractère pourrait continuer de s'exprimer librement : celui qui fait des heures sup' à n'en pas finir parcequ'il est passionné, celui qui fait juste ce qu'il a à faire, mais aussi celui qui fait du zèle, celui qui dit blanc à l'un noir à l'autre, etc etc. Bref tout les caractères peuvent s'exprimer de la même manière (et peut être avec le même ratio) dès lors que le cadre est correctement défini : la prime au rendement est forcément collective, les heures sup forcément individuelles, la participation aux résultats annuels est identique pour chacun.

Un élément de plus qui donne envie de faire un grand bras d'honneur à tout ça, et de réfléchir sur ses besoins réels.

Et peut être de dire stop : vous ne m'aurez ni moi ni mes enfants. Allez vous faire foutre avec votre société de merde que vous essayer d'imposer en écrasant au passage le pouvoir politique, démocratique. Votre modèle de société ne tiens que parcequ'il y a des esclaves plus ou moins consentant, pensant qu'ils n'ont pas le choix et que même le simple fait de s'exprimer est dangereux et soumis à représailles. Allez vous faire foutre.

De nombreuses souches de nombreuses plantes sont spécifiquemenrt développées pour être moins résistantes aux maladies. Plus productives, mais moins résistantes. Et ce, depuis belle lurette. Mr Michu en a eu connaissance avec l'apparation des fameux ogm-roundup-ready... Mais ce n'était que la face moderne de l'iceberg. Avec l'obligation d'acheter les semences du trop fameux catalogue, les agriculteurs sont piégés : sans instecticides ni pesticides ils ne produiront rien de rentables.

Cependant, à titre personnel, il me semble que l'on ne doit pas regarder la chimie comme l'ennemie. Loin de là même. Il faut préserver la terre et la biodiversité (et foutre à la poubelle le remembrement, les exploitations intensives, bref tout ce qui "pollue", au sens large, la terre). La chimie est un outil. Juste un outil. En tant que tel les grandes sociétés spécialisées peuvent tout à fait fournir le nécessaire pour une culture propre (une culture propre pour moi c'est une culture qui épargne la terre). Maintenant il va falloir changer des mentalités, car le marché est bête, ne réagis qu'à court terme, et rien de censé ou moral le controle... "madame monsieur voici une tomate poussée hors sol, en dtw, impact environnement zéro, avec des techniques permettant de produire pour tous" ou alors "madame monsieur voici une tomate poussée en pleine terre, avec des techniques permettant de produire pour tous", ou enfin "madame monsieur voici une tomate poussée pleine terre avec des techniques ne permettant qu'un rendement d'auto-suffisance locale"... Laquelle allons "nous" choisir ? ça se pèse et ça se réfléchi, il me semble... Non ?

Peut être un peu, oui. Car le contrôle de la prolifération des prédateurs n'est pas évident. D'un produit chimique ravageur on passe à un déséquilibre de l'écosystème. Ca parait plus écolo parceque plus propre, mais c'est pas sûr que ne plus avoir que des coccinelles soit vraiment une solution viable. Non ?

Il y aussi les "recettes de grands mères" qui fonctionnent assez bien : du jus de tabac autour des plants éloignera à peu près tout les rampants. Du citron pourri empêchera les fourmis de faire de l'élevage intensif de puceron sur ces plants là. De la bouillie de beterave apportera des éléments essentiels à la plante pour se défendre et être en bonne santé, tout en étant vite dégradé dans l'environnement pour le surplus. Du trichoderma vivra en symbiose avec les racines pour empêcher le développement des champignons pathogènes et de nombreux problèmes liés aux racines. Du purin d'ortie sera à la fois source d'azote mais également sera répulsif pour pas mal de squatteurs, tout en étant vite dégradé lui aussi, si la main verte à un peu la main lourde ;)

Finalement, la manière la plus écolo de faire pousser c'est peut être soit :
de faire "son" jardin proprement (mais ceci n'est possible que pour nous, dans nos petits pays) afin d'être autonome.
ou de faire selon les canons de la chimie et uniquement en hors sol, avec des techniques proches du DTW en circuit ouvert (ou la soupe enrichie servant à arroser, à nourrir, sur substrat neutre, n'est pas jetée à l'issue !! mais ré-équilibrée puis ré-utilisée. Aucun impact sur la terre, et aucun déchets chimiques)

??