https://lkml.org/lkml/2012/12/23/75
Un dev de chez RedHat a récemment fait un changement dans le kernel qui casse le son sous KDE/pulseaudio (peut être aussi sous Gnome?) et qui fait planter knotify sous KDE.
Ce dernier répond au mail parlant de la régression en disant que c'est la faute de pulseaudio et que ce n'est pas une régression.
La réponse de Linus ne s'est pas fait attendre:
Mauro, SHUT THE FUCK UP!
…
If a change results in user programs breaking, it's a bug in the
kernel. We never EVER blame the user programs. How hard can this be to
understand?
…
Shut up, Mauro. And I don't ever want to hear that kind of obvious
garbage and idiocy from a kernel maintainer again. Seriously.
…
Fix your f*cking "compliance tool", because it is obviously broken.
And fix your approach to kernel programming.
Je pense qu'il y réfléchira à deux fois la prochaine fois avant de poster sur la liste :-)
J'aimais bien la définition du reportage d'Arte (The code): «Linus, le dictateur bienveillant».
# Du mal à comprendre.
Posté par nico_bobo . Évalué à 8.
Donc même si le programme fait de la daube, le kernel doit s'adapter pour rien casser niveau userspace ?
[^] # Re: Du mal à comprendre.
Posté par gnumdk (site web personnel) . Évalué à 9. Dernière modification le 11 janvier 2013 à 10:22.
Non, mais dans le cas précis, ce n'est pas le programme qui fait de la daube mais le patch du mec…
Je pense qu'il grossit le trait exprès, bien sur qu'il pourrait arriver qu'une erreur dans le kernel corrigée rende un programme se basant sur cette erreur non fonctionnel…
Sauf que la, le mec a fait de la merde et accuse directement le userland sans chercher à comprendre…
[^] # Re: Du mal à comprendre.
Posté par Yukito (site web personnel) . Évalué à 10.
Pour être plus précis, le mainteneur en question était relativement insultant vis-à-vis de pulse audio (le programme qui a fait remonter le bug en premier) :
In other words, only an application that handles video should be
using those controls, and as far as I know, pulseaudio is not a
such application. Or are it trying to do world domination?
On a un utilisateur qui rapporte un bug potentiel du noyau, et le mainteneur qui lui dit en substance qu'il ne devrait pas utiliser cette fonctionnalité à moins de vouloir tenter une domination du monde. Pas étonnant que Linus pète un câble. Surtout si c'est vraiment un bug du noyau (apparemment une valeur d'erreur non correcte dans ce contexte, si j'ai bien compris).
[^] # Re: Du mal à comprendre.
Posté par ckyl . Évalué à 8.
Même si c'était le programme qui fait de la daube c'est de la faute du kernel qui à permis ce comportement à un instant T et qui veut d'un seul coup le changer.
La décision est toujours un compromis entre la "beauté" pour le projet de reparer les erreurs sans laisser de trace du passé et faire que ce qui marchait continue de marcher. Selon ton produit tes choix changerons. Mais dans tout les cas c'est de ta faute si tu releases un truc et que tu changes d'avis après (même pour de bonnes raisons).
[^] # Re: Du mal à comprendre.
Posté par groumly . Évalué à 5.
Aussi connu sous le bon vieux principe de "il est trivial d'ajouter qq chose a une API publique, quasiment impossible de supprimer qq chose sans problemes".
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Du mal à comprendre.
Posté par JGO . Évalué à 3. Dernière modification le 11 janvier 2013 à 11:28.
En supposant que le dév comprenait les conséquences de son patch, il aurait dû contacter les dévs KDE avant d'introduire son code dans le noyau. Si ça devient une habitude chez RedHat de faire des changements (même sensés) sans se préoccuper si ça casse les projets qui ne les intéressent pas, ça va finir par devenir très agaçant.
[^] # Re: Du mal à comprendre.
Posté par gnumdk (site web personnel) . Évalué à 3.
En même temps, sur ce point, on ne peut pas trop lui en vouloir, si il n'utilise pas KDE, si son patch lui semble bon, il ne peut pas deviner que cela va rendre KDE fou.
Bon, par contre, ici, son patch fait, il semblerait, une erreur de débutant. Ce qui passe mal pour Linus quand on bosse sur le noyau depuis 2005…
[^] # Re: Du mal à comprendre.
Posté par xcomcmdr . Évalué à 6.
C'est ce que fait Microsoft dans son OS tout le temps pour garder une rétro-compatibilité maximale (ou quasiment maximale). Comme Windows 95 qui faisait tourner les applications Win16 en étant multitâche coopératif et en ayant aucune protection mémoire entre les applications Win16 ou DOS.
Le blog "The old new thing" a pas mal d' "histoires de guerre" là dessus…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
# Mouais...
Posté par Zenitram (site web personnel) . Évalué à -10.
Tu sélectionnes beaucoup… Le reste de la discussion est posé, il argumente.
Par exemple :
"Well, UVC should return the same error codes as the other drivers, for the same error types. That's what that patch was trying to fix"
Maintenant, pose-toi la question : si tu as un bug, et que le user space plante si tu corrige le bug, doit-on ne jamais corriger le bug car un "dictateur bienveillant" a décidé que les bugs doivent rester? Les nouveaux programmes doivent-ils se taper 1000 lignes de code alors qu'une suffirait si on corrige le bug parce qu'un autre programme a implémenté d'une certaine manière la gestion de ce bug et/ou attend une valeur précise alors que ton API dit qu'il peut retourner n'importe quelle erreur? Qu'est-ce qui dit qu'il faut absolument que l'API retourne EINVAL et pas ENOENT, même si un logiciel a été codé comme les pieds et attend une unique valeur?
On peut aussi constater le bug, proposer un plan de migration (long, ça peut être en années) entre les différents acteurs (user space est au courant et corrige, on attend un peu au kernel avant de changer), et corriger un jour.
bref, ce n'est pas aussi binaire que Linus (même si il est "bienveillant" pour toi, un dictateur est toujours bienveillant pour certains et pas pour d'autres) et toi le disent.
[^] # Re: Mouais...
Posté par gnumdk (site web personnel) . Évalué à 10.
Quand une API dit: "je retourne 1 ou 2", il est tout à faire normal de faire:
et de ne pas tester le else vu que l'API te dit que cela n'arrivera pas… Voilà ce que dit Linus.
[^] # Re: Mouais...
Posté par fabien . Évalué à 9. Dernière modification le 11 janvier 2013 à 10:34.
biensur que oui, mais ce n'est pas le cas ici.
c'est ce qui est dit dans le fil de la discussion..
morceaux choisis :
et
[^] # Re: Mouais...
Posté par SamG . Évalué à 5.
Il ne faut pas non plus prendre Linus pour un con :
[^] # Re: Mouais...
Posté par ckyl . Évalué à 10.
Laisse tomber. Zenitram il va faire un petit cours de gestion d'API et de backward compatibilité à Linus. La routine quoi.
[^] # Re: Mouais...
Posté par Zenitram (site web personnel) . Évalué à -8. Dernière modification le 11 janvier 2013 à 11:40.
La réponse de Linus ensuite (intérêt limité contre problèmes) me va très bien, c'est la sélection des phrases faite par gnumdk juste pour troller (et Linus a été bourrin aussi, mais comme c'est le "gentil dictateur", tout va bien, quand c'est Lennart qui est bourrin c'est un salaud, va comprendre) et son affirmation binaire qu'on doit toujours toujours laisser des merdes pour faire plaisir au user space qui me laisse pantois.
Je l'ai expliqué dans mon premier commentaire, maintenant si ça vous amuse de le travestir pour inventer une idée que je n'ai pas… Faites-vous plaisir.
[^] # Re: Mouais...
Posté par gnumdk (site web personnel) . Évalué à 10.
Euh non, ce n'est pas juste pour troller, je pense que tout le monde ici sait comment Linus fonctionnne… C'était juste que moi j'aime bien les pétages de plombs de Linus…
Sachant que je défend Lennart sur tous ces projets (même si je n'utilise pas pulseaudio), il serait temps que tu changes de disque, tu nous ressorts toujours les même arguments à toutes les sauces et souvent on ne sait même pas pourquoi.
Bienveillant ne veut pas dire gentil…
Et Linus n'est pas le seul, A.Seigo s'est énervé la semaine dernière parce que la team plasma est obligé de faire de la merde (en gros, dupliquer des classes un peu partout dans KDE) alors qu'il avait prévenu il y'a longtemps que si les devs ne corrigeaient pas leur mauvaise habitude, cela arriverait.
[^] # Re: Mouais...
Posté par barmic . Évalué à 3.
Je pense qu'il s'agit surtout de visibilité. Les développeurs peuvent tout à fait modifier le comportement du noyau mais ça doit être bien défini comme tell et pas passer dans le même patch qu'une correction. Ça permet d'en discuter et de le remonter aux développeurs de programmes utilisateurs au plus tôt.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Un thread G+ à lire
Posté par patrick_g (site web personnel) . Évalué à 8.
Au sujet de cette gueulante de Linus il faut absolument aller lire les commentaires sur ce thread G+ : https://plus.google.com/115480450168703320714/posts/ieV7oVASykP
Il y a divers commentaires très intéressants de hackers du noyau et il y a même un post de Linus qui explique bien ce qui l'a poussé à grogner (je ne connaissais pas l'expression "to go ballistic" mais elle est très imagée ;-).
[^] # Re: Un thread G+ à lire
Posté par saltimbanque (site web personnel) . Évalué à 2.
et un lien vers le tweet disant "je suis content de ne plus contribuer au noyau quand je lis ça"
https://twitter.com/bos31337/status/283394798830882819
# Comme quoi y'a pas que RMS
Posté par saltimbanque (site web personnel) . Évalué à 8.
Bien sûr c'est le style de Linus et d'autres parties des méls sont argumentées et posées. Bien sûr il grossit le trait.
On n'insulte pas les gens ainsi. D'ailleurs en l'occurrence le gens est un employé, même si c'est red hat l'employeur, quid si un contributeur kernel part en dépression suite aux propos trop virulents de Linus? Super le boulot!
Des gens qui bossent mal, ça arrive partout-tout-le-temps. On va pas les dépecer non plus, on aurait vite fait de se retrouver avec 3 survivants sur terre.
Et si tous les mainteneurs de projets libres se permettent ce genre de propos, aura t-on encore envie de défendre le libre? Les valeurs d'une informatique ouverte servent les êtres humains, pas les machines.
[^] # Re: Comme quoi y'a pas que RMS
Posté par flagos . Évalué à 3.
Oui enfin faut quand même voir comment le mec se permet de parler a quelqu'un qui lui trouve une régression, surtout qu'il reconnait lui même par la suite être a coté de la plaque sur le fond.
[^] # Re: Comme quoi y'a pas que RMS
Posté par saltimbanque (site web personnel) . Évalué à 5.
flagos, c'est justement ce que je trouve nul. Parce que le dév à tort, l'insulter? En face à face, Linus a sans doute un contact différent, mais dans ce fil de discussion, il mélange allègrement le technique - personne ne conteste qu'il refuse un patch dégueulasse- et l'humain ("ta gueule connard", en gros).
Tu imagine que ton chef de projet te dise "ton objet est mal codé -> putain t'es vraiment une merde enculé"?
Après je ne veux pas vraiment me mêler de leurs affaires. J'en venais juste à penser "autant bosser pour Satan si au moins la musique est sympa"…
[^] # Re: Comme quoi y'a pas que RMS
Posté par gnumdk (site web personnel) . Évalué à 7.
depuis quand fuck veut dire connard ? J'ai plus l'impression que fuck est un mot très utilisé en anglais pour montrer qu'on est pas content, non ? Même si cela reste surement impoli ;)
Oui, sauf que là t'es pas au boulot, le monde des faux culs ;)
[^] # Re: Comme quoi y'a pas que RMS
Posté par saltimbanque (site web personnel) . Évalué à 2.
Oui j'avoue, traduction de très mauvaise foi, c'était pour souligner.
Vi, je sais pas… peut être que ce fil me tique parce qu'on vit une période ou le mal-être au travail explose complètement. J'ai la chance de passer au travers, mais pas tout le monde, des développeurs y sont confrontés malheureusement.
Ou peut être ai-je peur du mauvais exemple que Linus pourrait offrir à d'autres.
[^] # Re: Comme quoi y'a pas que RMS
Posté par detail_pratique . Évalué à 8.
Si j'étais salarié,
si j'étais salarié dans une boite qui dépasse le millier de salariés,
si le boss me laissait à tout moment (moi et tous mes petits camarades) défendre mon point de vue,
si le boss n'était pas d'accord sur un truc et me prouvait que j'avais tort,
si je continuais à ergoter,
si le boss me pourrissait la gueule — en public, le salaud : ) — parce qu'il en a marre de discuter de mon point de vue foireux,
mais si le boss juste après me disait qu'il fallait que je corrige mon truc et voilà on passe à autre chose.
Je me dirais :
quel enfoiré,
mais que voilà une drôle de boite,
et je me demanderais sans doute si j'ai envie de continuer à risquer de me faire engueuler en public.
Sans être maso, je conclurais que oui, et ne vivrais pas ça comme un mal-être au travail.
[^] # Re: Comme quoi y'a pas que RMS
Posté par Anonyme . Évalué à 1.
Être courtois c'est être polie.
[^] # Re: Comme quoi y'a pas que RMS
Posté par Anonyme . Évalué à 2.
Ok, la drogue c'est mal…
Je voulais écrire : être courtois c'est être faux-cul maintenant ?
[^] # Re: Comme quoi y'a pas que RMS
Posté par saltimbanque (site web personnel) . Évalué à 2.
être courtois au boulot
[^] # Re: Comme quoi y'a pas que RMS
Posté par briaeros007 . Évalué à 2.
shut up = ta gueule
shut the fuck up = ta gueule en encore plus grossier.
C'est pas parce que les américains ont un vocabulaire argotique pauvre que le message n'est pas insultant.
[^] # Re: Comme quoi y'a pas que RMS
Posté par gnumdk (site web personnel) . Évalué à 3.
"Ta gueule" n'est pas une insulte, c'est grossier point à la ligne.
[^] # Re: Comme quoi y'a pas que RMS
Posté par Lucas . Évalué à 1.
Tout ceci me rappelle ce bon vieux Jean Yanne… http://www.youtube.com/watch?feature=player_detailpage&v=12cBaujFBCM#t=147s
[^] # Re: Comme quoi y'a pas que RMS
Posté par calandoa . Évalué à 3.
Heu, en l'occurrence, ça serait plutôt : « ferme ta putain de gueule », et si, c'est une insulte, et en particulier lorsqu'elle est dite en public et par écrit. Bon, maintenant, c'est Linus… personnellement, j'en tirerai une certaine gloire de me faire insulter par Linus pour du code que j'ai écrit, donc il n'y a pas de quoi fouetter un chat, mais bon techniquement ça reste une insulte.
Et je viens d'aller voir la page Wikipédia, et je trouve que l'expression « insulte rituelle » assez bien.
[^] # Re: Comme quoi y'a pas que RMS
Posté par fredoche . Évalué à 5.
Il y a pourtant encore des centaines de contributeurs, et une grande qualité globale malgré ces écarts d'autorité. Ça peut paraitre antisocial, mais visiblement, c'est la meilleure façon de mener de genre de projet. La prise de position semble radicale, néanmoins, il n'y a pas de raison de prendre des pincettes face aux erreurs. De même, avec du recul, c'est l'auteur du patch moisi qui est antisocial en cassant la compatibilité, et en blâmant l'userspace. Linus, lui, a simplement envoyé un mail.
[^] # Re: Comme quoi y'a pas que RMS
Posté par pasBill pasGates . Évalué à 5.
Ça peut paraitre antisocial, mais visiblement, c'est la meilleure façon de mener de genre de projet. La prise de position semble radicale, néanmoins, il n'y a pas de raison de prendre des pincettes face aux erreurs
Tu vois comment que c'est la meilleure facon ?
Tu crois vraiment qu'il n'y a pas d'autre maniere d'exprimer son desaccord qu'en insultant un gars qui bosse pour ton projet ?
En ce qui me concerne, il a depasse la barre de l'acceptable la.
[^] # Re: Comme quoi y'a pas que RMS
Posté par fredoche . Évalué à 3.
Simplement en regardant les faits: Le projet logiciel le plus complexe (techniquement et/ou en terme de nb de contributeurs) du monde est piloté par un type qui porte des propos très clair et abrasifs, souvent pour de bonnes raisons, aux collaborateurs qui font des erreurs, pour marquer la ligne autant que servir d'exemple.
[^] # Re: Comme quoi y'a pas que RMS
Posté par gnumdk (site web personnel) . Évalué à 10.
T'es nouveau ici ? C'est tout sauf la première fois ;)
Mais la plupart des devs sont d'accord avec sa façon de faire, sèche mais qui évite les fils de discussion de 50 mails ou le mec essaye d'expliquer qu'il a surement raison…
[^] # Re: Comme quoi y'a pas que RMS
Posté par pasBill pasGates . Évalué à 0.
Les devs qui bossent encore avec lui sont d'accord, et evidemment, parce que ceux qui n'aiment pas cette facon de faire ne vont pas bosser avec lui tout simplement.
[^] # Re: Comme quoi y'a pas que RMS
Posté par arnaudus . Évalué à 7.
Sauf que jusqu'à preuve du contraire, sa communication de psychopathe lui permet de rester le leader incontesté d'un des plus complexes (voire le plus complexe) projets logiciel qui n'a jamais existé, et ce depuis 20 ans. Mine de rien, ça veut quand même dire quelque chose.
[^] # Re: Comme quoi y'a pas que RMS
Posté par saltimbanque (site web personnel) . Évalué à 4.
Peut être plutôt ses compétences technique? évidemment là pas de réponse objective possible, mais mon petit doigt musclé. Mille milliard de fanboys plussoient chaque postillon sorti de sa bouche, mais ce n'est pas cela un noyau.
Et pis qu'on me prouverait par a+b que l'agressivité est efficace, j'en écrirai pas moins la même chose.
[^] # Re: Comme quoi y'a pas que RMS
Posté par arnaudus . Évalué à 8.
Bof, ses compétences techniques, je n'y crois pas trop. Je crois que lui-même reconnait que beaucoup de contributeurs sont meilleurs que lui techniquement. Il est assez fort pour comprendre ce qui se passe et il a forcément une grosse expérience des problèmes techniques liés aux gros projets complexes, mais son apport est avant tout managérial. Il gueule, donne des directives, prend des décisions. Il ne faut pas oublier que, contrairement à un patron, il ne peut pas donner d'ordres ; le respect que les gens lui porte n'est absolument pas imposé. S'il commence à merder, tout l'écosystème va s'effondrer.
Le libre est un peu particulier, le fait que la contribution soit volontaire (quand elle n'est pas bénévole) influence forcément les relations entre les gens. Si tu téléphones à Microsoft (ou même à n'importe quelle boite de support pour Linux), tu payes pour le service, ils vont être tout mielleux au bout du fil même si tes questions sont con. Si tu poses une question débile sur une mailing list de logiciels libres, tu vas te prendre un RTFM bien senti. Ce que tu appelles agressivité c'est peut-être aussi de la franchise, et c'est ça qui permet à une communauté de tenir ; les relations entre les gens ne sont pas faussées par des liens de subordination (patron-employé, client-fournisseur, …), elles sont certainement plus similaires à celles qu'auraient des gens qui ne se connaissent pas dans la rue : quand on te demande une direction, tu la donnes si tu la connais, si tu ne sais pas et que l'autre iniste, tu lui dis d'aller s'acheter une carte.
Après, on peut partir du principe que la franchise est nuisible ; c'est une position que prennent beaucoup de politiques et de diplomates. Sincèrement, j'ai plutôt l'impression que les meilleures réunions sont celles où les gens sont francs de bout en bout. Bon, de là à dire aux gens de fermer leur gueule, c'est un peu violent, mais au moins le gars réfléchira à deux fois avant de rebalancer des arguments foireux.
[^] # Re: Comme quoi y'a pas que RMS
Posté par Youssef Oualmakran (site web personnel) . Évalué à 3.
Pas bien les clichés sur les politiques. Juan Carlos, le roi d'Espagne a bien dit "Pourquoi tu ne te tais pas ?" au président vénézuelien Hugo Chávez [1][2].
[1] http://www.youtube.com/watch?v=ZwfGOGQRDmI
[2] http://en.wikipedia.org/wiki/%C2%BFPor_qu%C3%A9_no_te_callas%3F
Bon, je reconnais c'est plutôt l'exception que la norme ;-)
[^] # Re: Comme quoi y'a pas que RMS
Posté par pasBill pasGates . Évalué à 2.
J'ai du mal a voir en quoi le kernel Linux serait un des projets les plus complexes ayant jamais existe.
C'est un noyau, pas un OS entier. Il y a plein de projets plus complexes que cela (ce qui ne veut pas dire que c'est un petit projet non plus qu'on se comprenne)
Il est leader parce qu'il est le createur du projet, et qu'il est loin d'etre incompetent techniquement. Mais il donne de plus en plus l'impression d'etre le frère jumeau de Theo De Raadt avec sa maniere de s'exprimer. C'est une technique qui marche tant que les gens autour ont assez de reverence pour son 'aura' et ses competences techniques, de la a etre la meilleure maniere de rassembler les gens et les faire faire ce qu'il faut, on va dire qu'il y a un fosse.
[^] # Re: Comme quoi y'a pas que RMS
Posté par patrick_g (site web personnel) . Évalué à 8. Dernière modification le 11 janvier 2013 à 22:06.
J'aime ton art de la litote.
J'ai déjà donné plus haut le lien vers les commentaires sur G+ mais visiblement tu n'es pas allé les lire. Je te colle donc les explications sur pourquoi c'est une méthode efficace:
De Rusty Russel : "Linus' rants also form a bright line of policy for everyone, and make it clear that arguing is pointless. It does save a great deal of Linus' time; I know firsthand that some of our colleages mistake politeness for uncertainty ("No, actually, rewrite your damn code already")."
D'Ingo Molnar : "Saying "fuck" to a maintainer is a valuable tool: it gets the attention of a 100 other maintainers - as evidenced by this thread. I personally massively prefer explicit, temporary verbal violence over prolonged passive-aggressive clandestine violence.
It is actionable, deterministic, less disruptive, it scales better and it also, paradoxically, hurts less."
Et cet autre paragraphe d'Ingo : "Linux kernel maintainers, as central points of failure, can inflict a lot of damage if they deny reality.
Filtering that source of harm out is a lot more important than turning Linus into a second "you really are special!" Mommy for maintainers and developers."
De Dave Airlie : "I know I still have sub maintainers who I catch screwing with ABIs a bit too closely, and they always start trying to justify themselves with userspace was broken. I try to tell them nicely, I've noticed it has had no effect, I now curse a lot at them and stop pulling trees, suddenly they stop trying to justify their bullshit."
Je ne doute pas un instant que tu vas rétorquer que tous les devs qui sont choqués par cette brutale honnêteté sont partis et qu'il ne reste plus que les partisans de cette méthode. C'est peut-être vrai…mais le noyau semble bien se porter en dépit de ça ;-)
[^] # Re: Comme quoi y'a pas que RMS
Posté par pasBill pasGates . Évalué à 1.
Je les ai lu, mais, et comme tu l'as devine, le simple fait qu'il soit entoure de gens qui pensent uniquement comme lui n'en fait pas une methode efficace, ca montre simplement que sa methode n'attire que des gens qui aiment cela et repousse les autres.
La realite est que dans a peu pres n'importe quelle boite (ici au moins), si il avait ose faire un truc pareil, il se serait fait refaire les dents par tout le monde. Que ce soit a Google, Apple, Facebook, Boeing, nous ou autre, quasiment personne n'accepterait un tel comportement.
Et je pense pouvoir dire de maniere comfortable que ces societes n'ont pas grand chose a envier au kernel Linux niveau qualite des employes et complexite du developpement. Il n'y a pas besoin d'insulter les gens pour eviter qu'ils fassent des conneries et leur faire comprendre qu'ils sont dans l'erreur.
[^] # Re: Comme quoi y'a pas que RMS
Posté par oao . Évalué à 8.
Sans vouloir défendre Linus sur son ton, il y a une importante différence qui est que les sociétés peuvent profiter du lien hiérarchique, lien qui n'existe pas pour le noyau Linux. La structure d'entreprise marche dans les deux sens, elle réduit le besoin de messages agressifs, en faisant jouer l'autorité, mais aussi la possibilité de les faire, car cela dé servirait fortement la carrière de celui qui s'y risquerait. Les contextes sont différents, ce qui s'applique avec succès chez Microsoft ne peut peut-être pas être fait dans un projet libre, et inversement.
[^] # Re: Comme quoi y'a pas que RMS
Posté par pasBill pasGates . Évalué à 2.
Mais la hierarchie n'a pas grand-chose a voir ici.
Chez nous il n'y a pas de hierarchie qui entre en jeu pour ce genre de truc. C'est qui qui decide entre le team kernel et le team NTFS quand ils se renvoient la balle pour un bug ? le president de la division Windows ? C'est pas realiste. Les ingenieurs causent, ils trouvent un accord. Pour ce qui est des pratiques generales, les chefs de toutes les equipes se rencontrent et mettent a plat comment les choses fonctionnent.
Ca tient plus de la democratie que de l'autoritarisme.
[^] # Re: Comme quoi y'a pas que RMS
Posté par flagos . Évalué à 6.
C'est donc les chefs qui décident et les gars qui pissent le code obéissent à leurs chefs. Tu ne retrouves pas cette autorité dans le dev d'un logiciel libre comme le kernel Linux.
Si tu considères qu'obéir aux ordres de ton chef est une sorte de démocratie….
[^] # Re: Comme quoi y'a pas que RMS
Posté par pasBill pasGates . Évalué à -1.
Ah les raccourcis… Les chefs ils prennent l'avis de leurs gars avant de decider quoi dire si ils ne sont pas stupides hein. L'objectif n'est pas de jouer au chef et decider dans son coin pour tout le monde mais faire ce qui fonctionne le mieux.
[^] # Re: Comme quoi y'a pas que RMS
Posté par flagos . Évalué à 3.
Un chef peut être attentif a ses gars… ou pas. C'est effectivement mieux pour tout le monde si on peut donner son avis mais on s'en fiche c'est pas le sujet.
LE truc qui fait que ca marche, c'est qu'au final c'est le chef qui décide et les larbins qui exécutent. Dans une situation de ce genre en entreprise, le chef n'aurait pas tardé a donner son avis sur la question et le conflit aurait été résolu.
Tu ne retrouves pas cette autorité par supérieur hiérarchique sur un projet libre. Le moyen qu'il te reste alors, c'est de parler franchement par mail pour déverminer le conflit au plus tôt.
[^] # Re: Comme quoi y'a pas que RMS
Posté par groumly . Évalué à 6.
Le truc c'est que dans le milieu high tech west coast, les bons ingenieurs savent ce qu'ils valent - en l'occurence, beaucoup. Des salaires a 150+ jusqu'a 200k par an sont pas delirant pour des gens competents avec 10 annees d'experience par ici. Et je parle d'ingenieurs la, pas de managers.
Et ya beaucoup de boites qui cherchent des gens competents, qui sont dur a trouver, encore plus dur a debaucher: ben ouais, ces gens la ne restent pas sans boulot, et s'ils bossent pas, c'est par choix.
Quelqu'un comme pbpg recoit probablement plusieurs contacts par mois pour aller bosser pour machin pour une montagne de fric.
Le resultat, c'est que les bons gars bossent pour qui ils veulent quand ils veulent. Si t'es pas content, t'ouvres ta boite linkedin et tu trouves autre chose, vite.
Les chefs d'equipes (a tous les niveaux, du team lead au CTO) savent ca, et font en sorte que leurs gars soient contents et n'aient pas envie d'aller ailleurs, ce qui commence par les ecouter.
L'autre truc c'est que la culture high tech us integre vachement plus l'ingenieur dans le process global, et les hierarchies tendent a etre vachement moins profondes et plus large. En gros, si t'es a plus de 3 niveaux du CTO, tu bosses dans une enorme boite. Ya des exceptions, evidemment, mais dans l'ensemble, ca se passe comme ca.
Du coup le concept du "larbin" dans les grosses boites n'existe pas ou peu, la concurrence est rude et ya trop de fric en jeu pour laisser partir un gars competent parce qu'un chef a voulu "chefer" a la francaise.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Comme quoi y'a pas que RMS
Posté par Guillaume Knispel . Évalué à 7.
Sauf que tu as oublié de parler d'Alan Cox qui a clairement trouvé ça déplacé et contre-productif, même s'il a réussi (contrairement aux habitudes de certains) à le dire poliment.
Certes les autres sont majoritaires, mais la théorie de pBpG pour expliquer cela n'est pas absurde.
[^] # Re: Comme quoi y'a pas que RMS
Posté par saltimbanque (site web personnel) . Évalué à 2.
http://linux.slashdot.org/story/09/07/29/1925224/alan-cox-quits-as-linux-tty-maintainer-ive-had-enough
[^] # Re: Comme quoi y'a pas que RMS
Posté par detail_pratique . Évalué à 3.
Pour l'Histoire (qui parfois se répète) :
I've been working on fixing it. I have spent a huge amount of time
working on the tty stuff trying to gradually get it sane without breaking
anything and fixing security holes along the way as they came up. I spent
the past two evenings working on the tty regressions.
However I've had enough. If you think that problem is easy to fix you fix
it.
Have fun.
I've zapped the tty merge queue so anyone with patches for the tty layer
can send them to the new maintainer.
--- MAINTAINERS~ 2009-07-23 15:36:41.000000000 +0100
+++ MAINTAINERS 2009-07-28 20:09:32.200685827 +0100
@@ -5815,10 +5815,7 @@
S: Maintained
TTY LAYER
-P: Alan Cox
-M: alan@lxorguk.ukuu.org.uk
-S: Maintained
-T: stgit http://zeniv.linux.org.uk/~alan/ttydev/
+S: Unmaintained
F: drivers/char/tty_*
F: drivers/serial/serial_core.c
F: include/linux/serial_core.h
[^] # Re: Comme quoi y'a pas que RMS
Posté par Guillaume Knispel . Évalué à 2.
Oui ça n'est pas la première fois qu'Alan est en désaccord sur les manières de faire.
Ceci étant, ça n'a pas grand intérêt de copier coller un background qui frise hors sujet ici ; Internet ne va pas s'effondrer pour ne laisser que LFR comme unique site web.
[^] # Re: Comme quoi y'a pas que RMS
Posté par groumly . Évalué à 9.
Oui, et il pourrait aussi fouetter les mainteneurs a chaque bug, sur que les gens feraient gaffe. Evidemment que ca fait son effet, la question est de savoir si la mesure est proportionnee a la faute, et si ca n'a pas plus d'effet negatifs que positifs.
C'est tres simple, tu dis pas "shut the fuck up", this patch is total and utter crap, idiocy and fix your fucking tool a quelqu'un de ton equipe en public. Deja que tu le fais pas devant l'equipe, tu le fait encore moins devant le monde entier.
C'est tout simplement inacceptable et il n'y pas la moindre excuse. C'est juste la base de la politesse et du savoir vivre en societe, connu aussi sous le nom de "lave ton linge sale en famille", personne ne veut etre mele a ses engueulades.
Tu le dit en tete a tete si tu connais la personne et que tu sais que ca passe, peut etre, mais en public, jamais, o grand jamais.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Comme quoi y'a pas que RMS
Posté par Maclag . Évalué à 3.
Oui mais là on ne parle pas d'une boite qui bosse sur son projet en interne, on parle de répondre à un mec sur une liste publique qui est en train d'envoyer chier les dévs userspace.
Si tu ne veux pas prendre une baffe dans la gueule en public, tu commences par ne pas envoyer chier les gens en public!
Faut se rappeler aussi que si Linus palabre derrière avec le gars, ça laisse autant de temps au message pour être lu dans le monde entier: "ouai, j'ai pété le userspace, et je pense que c'est parce que le code userspace est foireux, tant pis pour vos gueules"
Et apparemment, y'avait du monde pour rapporter le problème. Ça aurait laissé quelle impression un truc comme çà?
Et pour ceux qui disent que "dans n'importe quelle boite ça se passerait pas comme ça", faut vous dire que si, des fois, en réunion ou par e-mail avec du monde en copie, ça peut fuser pas mal hein:
-"vu ce que t'as fait sur [projet], t'es pas en position de parler d'incompétence chez les autres, d'ailleurs ce serait mieux si tu ne faisais pas de commentaire du tout"
-"lui on ne lui demande plus rien, parce que lui c'est un faible! à partir de maintenant c'est toi le responsable, et y'a plus à discuter" (toutes les parties concernées autour de la même table, évidemment)
-"je sais pas pourquoi on discute, parce que la SEULE chose qu'on te demande c'est de faire ton putain de boulot, alors ferme-là et VAS BOSSER!"
[^] # Re: Comme quoi y'a pas que RMS
Posté par Guillaume Knispel . Évalué à 2.
hm?
[^] # Re: Comme quoi y'a pas que RMS
Posté par Guillaume Knispel . Évalué à 1.
hm?
[^] # Re: Comme quoi y'a pas que RMS
Posté par Anonyme . Évalué à 0.
Courriels.
« Mél. » c'est comme pour « Tel. », c'est un diminutif (à utiliser sur les cartes de visites ou dans les formulaires par exemple).
[^] # Re: Comme quoi y'a pas que RMS
Posté par Marotte ⛧ . Évalué à 3.
Mél est le diminutif de quel mot ?
[^] # Re: Comme quoi y'a pas que RMS
Posté par Kekun (site web personnel, Mastodon) . Évalué à 8.
Faut mettre l'email d'une Mélanie sans doute…
[^] # Re: Comme quoi y'a pas que RMS
Posté par Benoît Sibaud (site web personnel) . Évalué à 5.
Mél. est la forme abrégée de messagerie électronique, au même titre que etc. est la forme abrégée de et cetera (desunt).
[^] # Re: Comme quoi y'a pas que RMS
Posté par Marotte ⛧ . Évalué à 7.
Arf merci. Je croyais connement qu'on s'était contenter de transcrire mail phonétiquement :)
[^] # Re: Comme quoi y'a pas que RMS
Posté par kursus_hc . Évalué à 3.
La flemme de chercher mais il me semble vraiment qu'à la première publication de l'Académie francaçise sur le sujet, sans doute encore au XXème siècle, mel était la traduction officielle de mail, avant qu'on ne se rende compte que le courriel canadien était bien plus joli.
[^] # Re: Comme quoi y'a pas que RMS
Posté par Redskull . Évalué à 0.
Il me semble au contraire que l’Académie n’a jamais proposé « mél » comme mot. Avant le « courriel », on avait tout simplement le « courrier électronique ». ;)
[^] # Re: Comme quoi y'a pas que RMS
Posté par detail_pratique . Évalué à 9.
Étonnamment, il y a plus de 3 mainteneurs Linux.
Étonnamment, il y en a même de plus en plus, et il semble, de surcroit, qu'ils ne souffrent pas d'affection dermatologique particulière — bien que certains soient de moins en moins chevelus.
Je crois que tu ne saisis pas que malgré le côté industriel de Linux, il existe encore un esprit familial (artisanal si tu préfères), qui fait que les gens participent de manière à peu près horizontale. Dans une famille ou dans une petite boite, il arrive qu'on s'engueule sans faire appel à la DRH ou à un spécialiste de la gestion de conflit. On se rappelle les grands principes de la vie que tout le monde connait parfaitement : OUI on met la moutarde au frigo tu me fais putain de chier / we dot not break userspace, on contre-argumente foireusement, et on se prend un STFU parce que bon, faut pas pousser, il n'y a pas d'argument valable pour ne pas mettre la moutarde au frigo, un point c'est toute, alors on répond : ok, fully agreed, et fin de l'histoire.
Ça peut être choquant si tu as des habitudes policées, mais ce n'est pas grave : c'est juste une autre manière d'envisager les relations humaines et professionnelles. Si certaines personnes quittent le navire, c'est qu'elles ne sont pas en accord avec ce mode de fonctionnement, ce qui peut tout-à-fait se comprendre.
Mais pour l'instant, la grande majorité des développeurs a l'air en accord et heureuse de ce côté artisanal, non ?
[^] # Re: Comme quoi y'a pas que RMS
Posté par saltimbanque (site web personnel) . Évalué à 3.
Vous avez raison, tant que des contributeurs s'en satisfont, après tout personne ne m'a insulté je m'en tape. Il y a beaucoup d'effet pervers dans le courriel, qui peut rendre violente des remarques visant plus le code que la personne, ou ne se voulant pas tant méchantes que purement techniques.
Oui je plus plus sensible à ce type d'approche. Car l'approche de Linus de répondre en disant "oui mais enfin son code pue", bonjour l'autisme. On ne justifie pas d'insulter un gars en répétant pourquoi son travail est mauvais. Tant que l'interlocuteur est capable d'identifier que Linus parle comme ça faut pas s'affoler, tant mieux.
[^] # Re: Comme quoi y'a pas que RMS
Posté par oao . Évalué à 5.
Justement, il n'insulte pas, il écourte grossièrement la discussion. Ce n'est pas la personne qui est visée, mais les actes, ce n'est donc pas une insulte.
[^] # Re: Comme quoi y'a pas que RMS
Posté par Didrik Pining . Évalué à 1.
C'est une blague ? Man the fuck up, dude!
[^] # Re: Comme quoi y'a pas que RMS
Posté par napster2core . Évalué à 7.
Ce cas lui est déjà arrivé. Il avait laissé plusieurs fois des projets avancer avant des les refuser mais trop tard. Et il recevait un mail d'un amis qui lui disait qu'il fallait faire gaffe car le mec en question était suicidaire. Du coup depuis il refuse les "mauvais" projets selon lui directement et non plus après que le dev ait fournis un travail.
Je ne me rappel plus exactement la source mais c'était une conférence de Linus relativement ancienne.
Librement
Si tu ne sais pas demande, si tu sais partage !
# l'arroseur arrosé
Posté par fravashyo . Évalué à 10.
Ça me rappelle la gueulante qu'avait poussé Lennart Poettering vis à vis de son équipe de développeurs pour PulseAudio et SystemD quand il s'était apperçu que leurs 2 logiciels cassaient parfois des logiciels tiers.
Heu, attendez…
« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond
[^] # Re: l'arroseur arrosé
Posté par stopspam . Évalué à 5.
J'en ai mis du temps avant de trouver le troll du vendredi. Z'êtes tous en vacances ?
[^] # Re: l'arroseur arrosé
Posté par fravashyo . Évalué à 3.
et toi, combien de dépêche petit scarabée (et de journaux au contenu très intéressant) ?
En parlant de troll, dommage que Linus ne pousse pas de gueulante vis à vis d'Amazon qui entretien un écosystème privateur comme le Kindle avec son format moisi et remplis de DRM : https://plus.google.com/102150693225130002912/posts/Mm74Hgnm9ok
« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond
# Haine anti pulseaudio/systemd sur DLFP
Posté par Ife . Évalué à -10. Dernière modification le 11 janvier 2013 à 12:56.
Je tiens a signaler qu'il y a une grosse haine anti-pulseaudio et systemd sur LinuxFR.
Loin de moi l'idée de défendre pluseaudio et systemd dans ce thread, j'ai pas envie de perdre mon temps à défendre deux programmes révolutionnaires.
En revanche, je résume la situation du journal :
Dans n'importe quelle autre situation, tout le monde aurait reconnu que c'était de la faute du kernel.
Or, au moment ou je rédige ce commentaire, les autres commentaires sont principalement « c'est de la faute du programme en question », tout ça parce que c'est pulseaudio.
J'ai un peu l'impression que la majorité de la communauté DLFP aime les doubles standards : elle voudrait que les gens changent de Windows à Linux parce que c'est mieux ; en revanche quand on leur demande de changer parce que c'est mieux (alsa/oss/jack/… vers pulseaudio, et sysvinit vers systemd) il y a une grande résistance.
Ruby est le résultat d'un gamin qui apprend le Java, puis jette un œil à Perl et se dit « je peux le réparer! »
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2. Dernière modification le 11 janvier 2013 à 13:19.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Haine anti pulseaudio/systemd sur DLFP
Posté par TImaniac (site web personnel) . Évalué à 2.
Ton exemple est foireux : tu as forcement dû recompiler ton programme en changeant d'architecture (passage de 32 à 64bits) : tu as donc explicitement demandé à cibler une nouvelle "interface" de l'OS. Il est donc de la responsabilité du programmeur de s'assurer que son programme fonctionne face à cette nouvelle interface. L'exécutable produit contient un flag qui indique qu'il a été prévu pour fonctionner sur telle architecture, à l'OS de ne pas jouer au con. C'est pas pour rien que les OS tentent de garder la compatibilité avec l'architecture 32 bits même sur un OS 64 bits : éviter que le programme casse.
Là on parle d'une modification qui engendre un comportement différent de l'OS vis-à-vis des programmes, sans modifications de ces derniers : clairement c'est une erreur de l'OS, l'OS n'a pas à savoir (et ne peut savoir) ce qui est correct dans un programme utilisateur : il doit se borner à avoir un comportement constant pour assurer la compatibilité.
Il n'y a pour moi que quelques cas où un changement est acceptable : une API deprecated depuis un certain temps qui est finalement retirée/remplacée au bout de plusieurs années, généralement à travers une version "majeure" de l'OS, ou bien un problème de sécurité qui impose de casser la compatibilité plutôt que de laisser une faille ouverte.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4. Dernière modification le 11 janvier 2013 à 13:56.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Haine anti pulseaudio/systemd sur DLFP
Posté par TImaniac (site web personnel) . Évalué à -1.
Si tu n'as pas changé d'architecture, il n'y a aucune raison que la fonction time se mette à retourner une valeur sur 64 bits au lieu de 32.
Si c'est le cas, c'est clairement une erreur dans l'API : il aurait fallu créer une nouvelle méthode pour éviter de casser les programmes existants, quelque soit l'usage que puisse faire ton programme de cette méthode.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4. Dernière modification le 13 janvier 2013 à 14:19.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Haine anti pulseaudio/systemd sur DLFP
Posté par TImaniac (site web personnel) . Évalué à 0.
Il n'y a pas d'erreur vis-à-vis de la norme POSIX d'utiliser un nombre sur 64 bits ou sur 32 bits on est d'accord. Tout ce que ton exemple montre, c'est que la norme POSIX est loin d'être une API d'interopérabilité parfaite, et que d'un système à l'autre il faut effectivement mieux avoir des bonnes pratiques de programmation si tu veux pas que ton programme face n'importe quoi.
En revanche je persiste : c'est une erreur s'il y a un changement dans la taille (passage de 32 à 64 bits) pour une implémentation/OS donné : même si tu codes à coup de time_t, cela peut casser la compatibilité de ton programme : tu peux te retrouver à bouffer plus de mémoire et atteindre une limite par exemple.
C'est d'autant plus dangereux que ton exemple pointe une incompatibilité API mais également ABI : imagine, un programme qui n'est même pas recompilé se retrouve à planter !
Clairement, dans ce genre de situation, il faut mieux créer une nouvelle méthode ou explicitement changer d'API.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 5. Dernière modification le 13 janvier 2013 à 14:46.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Haine anti pulseaudio/systemd sur DLFP
Posté par TImaniac (site web personnel) . Évalué à -1.
On est d'accord : mais un OS est là pour offre une compatibilité au niveau binaire. Essai pas de déporter le débat sur POSIX.
J'ai pas dit que c'était une erreur : j'ai dit que c'était juste pas terrible pour la portabilité du code entre 2 machines : sur 32 ou 64 bits, tu as des valeurs possibles différentes, ton programme se retrouve donc avec des capacités variables d'une implémentation à l'autre, c'est quand même pas génial !
Ben moi je dis s'il vous plaît :)
Et pas besoin d'autant de méthodes que tu le décrits : t'as l'implémentation originale (32 signed ou pas, mais pas les 2) + la nouvelle.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Haine anti pulseaudio/systemd sur DLFP
Posté par TImaniac (site web personnel) . Évalué à 0.
T'es d'une malhonnêteté incroyable : c'est plus facile de tronquer une citation plutôt que d'argumenter.
Je n'ai jamais dit que le choix fait par POSIX d'avoir une compatibilité source, norme d'interopérabilité, était une erreur, malgré ta façon trompeuse de me citer.
Je parle d'une erreur dans le choix de casser la compatibilité dans un OS particulier, en l'occurrence une implémentation de POSIX, mais à la limite on s'en fou : POSIX ou non le problème est strictement identique.
Visiblement t'as du mal à comprendre la différence entre une norme d'interopérabilité et le userland d'un OS. La nature, les objectifs et exigences ne sont pas identiques.
[^] # Re: Haine anti pulseaudio/systemd sur DLFP
Posté par calandoa . Évalué à 2.
Je suis allé voir le standard et il faut se rendre à l'évidence :
« Implementations in which
time_tis a 32-bit signed integer (many historical implementations) fail in the year 2038. IEEE Std 1003.1-2001 does not address this problem. However, the use of thetime_ttype is mandated in order to ease the eventual fix. »Même si je ne m'amuserais pas à passer une implémentation 32 bits à 64 pour les raisons que tu donnes, utiliser du 32 bits explicitement est une erreur.
(The Open Group Base Specifications Issue 6 IEEE Std 1003.1, 2004 Edition)
[^] # Re: Haine anti pulseaudio/systemd sur DLFP
Posté par TImaniac (site web personnel) . Évalué à 0.
Je suis bien d'accord : mais le problème, c'est l'OS qui l'a introduit en fournissant une implémentation quelque peu limité dans le temps. C'est pas pour autant qu'il faut casser la compatibilité avec les programmes qui se sont basés sur cette implémentation, quelque soit l'usage pertinent ou non de la taille de la donnée retournée.
Une API a un cycle de vie, elle peut être deprecated et remplacée, mais elle ne doit pas être cassée.
[^] # Re: Haine anti pulseaudio/systemd sur DLFP
Posté par fearan . Évalué à 4.
tu confonds API et ABI, ici l'API n'est pas changé, mais l'ABI l'est ;)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Haine anti pulseaudio/systemd sur DLFP
Posté par TImaniac (site web personnel) . Évalué à 1.
Ce que j'ai dit plus haut, c'est que l'OS se doit de maintenir l'ABI.
Après je considère que le changement de taille d'une structure (time_t) est également une rupture d'API puisqu'elle implique une plage de valeurs min/max différentes.
[^] # Re: Haine anti pulseaudio/systemd sur DLFP
Posté par fearan . Évalué à 5.
Ça c'est ton point de vue; du mien, à partir du moment où tu peux recompiler c'est bon; ça peut faire chier les adepte des système fermés, mais ça c'est le cadet de mes soucis; quand la taille de time_t fut choisie, on avait pas des Go de mémoire; il a été choisi d'une taille suffisante (pour l'époque), et d'un type particulier.
Si pour toi lorsque l'on change de temps il faut réécrire tout le code utilisant time_t, dupliquer toutes les fonctions l'utilisant, part sous windows, ha, merde, même sous windows ils sont passé à 64bits pour time_t, et ce depuis 2005.
Il n'y a pas un os moderne qui n'ait pas fait le changement.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Haine anti pulseaudio/systemd sur DLFP
Posté par TImaniac (site web personnel) . Évalué à 1.
C'est vrai quoi, c'est tellement pertinent quand tu fais un update du kernel de devoir récupérer tous les paquets de ta distri qui ont dû être recompilés parcqu'une ABI du userland a été pété…
Quand tu regardes bien, sous Windows ils n'ont pas pété l'ABI : time_t n'est qu'une macro vers un time64 : les anciens programmes qui utilisaient time_t sur 32 bits continuent de marcher correctement, les programmes recompilés ont le choix entre spécifier qu'ils veulent garder l'ancien comportement ou passer par défaut au nouveau : ce sont d'autres méthodes qui sont appelées derrières, qui manipulent cette fois time64. Les anciennes sur 32 bits sont toujours là.
DOnc oui, ils ont dupliqué toutes les fonctions et ils ont pas cassé l'ABI et donc les programmes existant. L'OS fait bien son taf de compatibilité.
[^] # Re: Haine anti pulseaudio/systemd sur DLFP
Posté par Atem18 (site web personnel) . Évalué à 1.
Euh… Tout droit.
[^] # Re: Haine anti pulseaudio/systemd sur DLFP
Posté par Nonolapéro . Évalué à 10.
[3615 mavie]
J'ai installé Archlinux et Gnome3 sur l'ordi de mon épouse il y a peu pour virer un XP bien vermoulu. J'ai donc le droit à Systemd et PulseAudio. Lors de la lecture de vidéo gnome-shell bouffe 20 à 30 % du processeur, vlc une grosse partie également et PA nous fait des pointe à 90 %. Au final, l'ordi gelait régulièrement et mon utilisatrice préférée devenait quelque peu remontée envers ce système de merde pas capable de lire une vidéo.
La solution a donc été de virer PA, Gnome et Nouveau pour passer à Xfce, Alsa et le driver proprio nvidia. Finalement la paix du ménage est retrouvée. Conclusion Gnome et PA nuisent à la vie de couple.
[\3615 mavie]
[^] # Re: Haine anti pulseaudio/systemd sur DLFP
Posté par gnumdk (site web personnel) . Évalué à 2.
J'ai utilisé pulseaudio pendant quelques semaine à cause de ça:
http://code.google.com/p/clementine-player/issues/detail?id=3362
Ben, il devait consommé 1% de CPU sous Arch donc le problème doit être ailleurs mais c'est surement trop compliqué de faire un rapport de bug ?
[^] # Re: Haine anti pulseaudio/systemd sur DLFP
Posté par Nonolapéro . Évalué à 3.
Pour gnome-shell ya des rapports de bug ouverts https://bugs.archlinux.org/task/25870#comment82618
[^] # Re: Haine anti pulseaudio/systemd sur DLFP
Posté par gnumdk (site web personnel) . Évalué à 3.
Ok, désolé je suis malade et donc à la rue, j'avais lu ton message de travers…
En tout cas sous KDE, avec nouveau, VLC montre à 80% de CPU avec des vidéos HD mais seulement 6% avec un bête DIVX…
C'est sur que mon proc chauffait moins avec VPDAU et le driver proprio mais bon, nouveau me suffit.
[^] # Re: Haine anti pulseaudio/systemd sur DLFP
Posté par briaeros007 . Évalué à 3.
ou peut être que son cas ne correspondait à rien de ton cas et que c'était normal pour les dev de pulseaudio qu'il consomme autant ?
Pulseaudio c'est quand même le truc qui dit "on est bien meilleur qu'alsa" mais qui utilise alsa …
Il prendra forcément plus de performance qu'alsa (vu que c'est un daemon de son).
[^] # Re: Haine anti pulseaudio/systemd sur DLFP
Posté par detail_pratique . Évalué à 3.
Je ne l'appelle pas mon épouse, mais j'en suis arrivé à la même conclusion : )
[^] # Re: Haine anti pulseaudio/systemd sur DLFP
Posté par ʭ ☯ . Évalué à 2.
Ben et nouveau alors? Tu as quand même changé un composant très important dans la lecture de vidéos : la gestion de la carte graphique ;-)
Sinon, sur CPU mono-cœur inférieur à 2GHz, je désactive pulseaudio effectivement : il utilise plus de 5% du CPU dans ces cas-là, et la TV Free en HD saccade du coup. Mais ça ne me fait pas cracher sur pulseaudio, qui est génial pour gérer le son par HDMI…
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Haine anti pulseaudio/systemd sur DLFP
Posté par Gabin II . Évalué à 2.
Tu a aucune conso avec juste ALSA? Vu que les proco sons qu'on utilise de nos jours font tout le mixage en logiciel, je suis étonné que ça ne mange pas un peu de CPU.
Pour ma part, je n'ai pas aimé PA dans ses premières heures mais à présent j'accèpte de payer ces 5% de CPU pour la fléxibilité que ça a apporté. Branchement à chaud d'un casque bluetooth reconnu et fonctionnelle, casque-micro USB, changement à chaud de carte/puce audio, réglage par application sans que je ne doive me battre avec asoundrc ou dmix et leur syntaxe lourde.
Et puis il y a la grosse dépendance de nos applis à PA qui force à s'y soumettre.
Améliorons plutôt PA que de nous de troll sans fins.
[^] # Re: Haine anti pulseaudio/systemd sur DLFP
Posté par gnumdk (site web personnel) . Évalué à 6.
Pas vraiment, sous KDE, on peut vivre facilement sans PulseAudio…
De plus, le réglage du son par application existe dans toutes les applications sans PulseAudio…
Tu vas me dire que mon mixeur n'est pas capable de contrôler le son des applications mais pour toutes celle qui sont compatible MPRIS2, kmix le fait.
Perso, y'a quand même un truc qui j'ai trouvé chiant dans PulseAudio, c'est que si je montait le son global via un raccourcis, ca montait le son dans toutes les applications, je sais pas si c'est propre à Kmix mais c'est horrible comme comportement…
[^] # Re: Haine anti pulseaudio/systemd sur DLFP
Posté par Anonyme . Évalué à 3.
OSS le faisait y a 10 ans.
[^] # Re: Haine anti pulseaudio/systemd sur DLFP
Posté par gnumdk (site web personnel) . Évalué à 1.
On a pas du utiliser le même OSS… En tout cas si c'était le cas, pourquoi personne ne l'utilisait par défaut dans les distros ?
[^] # Re: Haine anti pulseaudio/systemd sur DLFP
Posté par Nonolapéro . Évalué à 2.
Il me semble qu'il y a eu des changements de licence qui l'ont rendu, un moment, incompatible avec les distributions.
[^] # Re: Haine anti pulseaudio/systemd sur DLFP
Posté par Anonyme . Évalué à 4.
Même pas, il aurait suffit de forker, de dire merde aux développeurs originels et de continuer avec un truc qui marche.
Au lieu de ça, on a fait ALSA, qui ne tourne que sous Linux et qu'on essaye d'améliorer en créant 42 surcouches.
[^] # Re: Haine anti pulseaudio/systemd sur DLFP
Posté par Anonyme . Évalué à 2.
Si je dis pas de bêtise tu es sous Arch donc :
Apprécie la gestion du son par applications.
Par contre OSS étant de moins en moins utilisé, il est laissé à l’abandon, l’expérience que tu pourras avoir avec sera forcément moins bonne qu’avec des applications bien intégrées.
[^] # Re: Haine anti pulseaudio/systemd sur DLFP
Posté par Moonz . Évalué à 2. Dernière modification le 12 janvier 2013 à 14:59.
C’est pas depuis OSSv4 ça ? Je me souvient pas que l’OSS qu’on trouvait dans le 2.4 avait de la gestion de son par application.
[^] # Re: Haine anti pulseaudio/systemd sur DLFP
Posté par Anonyme . Évalué à 2.
Je suis un petit jeune, j’ai pas connu l’époque 2.4.
Mais, même si c’est depuis OSSv4, je suis pas loin avec mes dix ans :)
[^] # Re: Haine anti pulseaudio/systemd sur DLFP
Posté par Nonolapéro . Évalué à 3.
Je sais que le pilote de la carte graphique joue énormément, j'ai d'ailleurs basculé vers le pilote proprio seulement après avoir constaté l'incapacité de nouveau à répondre au besoin.
# On ne peut plus avoir du caractère ?
Posté par rdhlnn . Évalué à 10.
Certains diront mauvais caractère… Soit… Moi je dis du caractère et plein de saintes colères.
Et quand on connaît le bonhomme, ce qu'il a réalisé (et il se connaît lui-même d'ailleurs… Message qui suit de 5 jours cette réaction), eh ben on accepte son caractère. Il y a une différence entre de la colère et de la méchanceté.
Mais après tout, il faut pas être vulgaire (n'est-ce pas ?), faut être bien lisse. Tout le temps !
Et quand le capitalisme culturel pousse une gueulante, c'est normal, même cocasse ! Personne ne connaît le calme d'un certain Ballmer ? Et quand ils essaient insidieusement de nous entuber, on doit dire : "Merci ! Merci beaucoup ! Et en plus vous faites du Green IT ! C'est fantastique ! Je suis tellement heureux que vous me vendiez ma rédemption en plus ! Le prix en vaut le coup (pour ne pas écrire le coût) !"
On peut citer par exemple Nvidia, et je les cite vraiment par hasard… Vous me voyez venir ? Bon, allons-y alors ! Alors quand Linus Torvalds devient tout rouge contre ce genre de constructeur, que doit-on faire ? Demander pardon de s'être énervé, de son caractère excessif ? Promettre de ne plus jamais être vulgaire et subir en silence les importantes décisions des importants décisionnaires ?
On critique toujours plus ceux avec qui on a le plus de liens. Stallman en est un bon exemple (et je suis le premier à critiquer sa maladresse, sa contre-productivité). Mais je suis heureux de me tenir de leur côté ! Et encore davantage qu'il y ait des types comme ça dans ce combat, des mauvaises têtes, des vieux routards du libre qui sont prêts à agacer, à s'énerver, à gueuler, à être détestés, mais surtout à toujours lutter ! Comme Theo de Raadt, Linus Torvalds, Richard Stallman pour ne citer qu'eux.
On est vendredi non ?
[^] # Re: On ne peut plus avoir du caractère ?
Posté par saltimbanque (site web personnel) . Évalué à 2.
Insulter nvidia, ne relève pas de la même chose. Peut être la différence entre entreprise et être humain est-elle difficile à cerner?
# mouai
Posté par steph1978 . Évalué à 1. Dernière modification le 11 janvier 2013 à 17:50.
Je n'ai pas lu le dossier en entier.
Mais difficile de donner une règle générale sur la régression du noyau.
Ce n'est pas parce que un programme tombe en marche (programmation par coïncidence) avec une version du noyau qu'il doit continuer à tomber en marche lors d'une mise à jour. Le code n'est pas tout, il faut connaître l'intention, décrite dans l'API.
[^] # Re: mouai
Posté par ʭ ☯ . Évalué à 2. Dernière modification le 15 janvier 2013 à 00:30.
Si la plupart des applications utilisent un bug, il devient une fonctionalité importante. ;-)
Je me souviens d'utiliser l'API W32 pour l'impression avec 98 et NT4. L'intention, décrite dans l'API, ne correspondait pas à l'implémentation. Bien sûr, on pouvait rester là à pleurer, mais on a préféré utiliser l'implémentation, et annoter le code pour y faire attention à la version suivante de Windows qui, ça n'a pas manqué, a gardé la mauvaise implémentation 8^O
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.