La grande question éternelle du moment est que penser de Lennart qui casse tout. Selon Brian Proffitt dans un article sur itworld -- qui rapporte en outre que Rainer Gerhards, développeur de rsyslog, pense que l'analyse de Lennart pose le bon diagnostique mais y apporte une mauvaise solution -- la somme de changement d'infra initiée du côté RH montre que ce dernier est plus en train d'essayer de se différencier fortement dans l'écosystème (traduction franche : forker l'écosystème) que quoique ce soit d'autre, peut-être pour s'attirer les fans du buzzword très fashion en ce moment de "app".
L'article : http://www.itworld.com/it-managementstrategy/229513/red-hats-linux-changes-fixes-or-isv-positioning
# ...
Posté par M . Évalué à 8.
on peut lire aussi la réponse aux problèmes soulevé par Lennart par le dev de rsyslog : http://blog.gerhards.net/2011/11/serious-syslog-problems.html
Sinon après systemd pourquoi ne pas continuer a tout casser ?
[^] # Re: ...
Posté par Chris K. . Évalué à 1.
Oui pourquoi pas... le système de gestion du son ?
[^] # Re: ...
Posté par pralines . Évalué à 2.
ah NON, trop facile, ça va pas recommencer avec PA :-) !
tiens ça me fait penser qu'un icône "Plier/Déplier tout" serait appréciable, voire quelques options pour filtrer les commentaires (par date/heure, par auteur...)
Envoyé depuis mon Archlinux
[^] # Re: ...
Posté par totof2000 . Évalué à 7.
Et pourquoi pas la possibilité de modifier son commentaire tant qu'on y est ?
[^] # Re: ...
Posté par vladislav askiparek . Évalué à 6.
Le Hurd sera Michu compliant avant que cette feature soit sur DLFP.
[^] # Re: ...
Posté par eastwind☯ . Évalué à 2.
Entre temps le Hurd sera forké :)
[^] # Re: ...
Posté par Chris K. . Évalué à 2.
Mince pourtant c'est vendredi...
Tu plaisantes un peu et pouf ton troll pauvre troll velu est rasé stérilisé filtré et hadopié.
N’empêche quand je vois ça : http://blogs.adobe.com/penguinswf/files/penguinswf/linuxaudio.png je me dis que l'INIT à coté c'était propre et pas si urgent.
[^] # Re: ...
Posté par Thomas Debesse (site web personnel) . Évalué à 7.
Oui, et on se demande donc pourquoi Lennart s'est lancé dans PulseAudio : l'audio était déjà cassé.
il aurait mieux fait de s'attaquer tout de suite à l'init ou aux logs. C'était une fausse piste, l'audio est un domaine qu'on sait casser tout seul ! S'il n'avait pas perdu de temps sur PA je suis sûr qu'aujourd'hui il ne serait déjà plus à s'attaquer aux logs mais au 'tout est fichier' ou bien au 'sauf le réseau'.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: ...
Posté par M . Évalué à 2.
//
Mince pourtant c'est vendredi...
Tu plaisantes un peu et pouf ton troll pauvre troll velu est rasé stérilisé filtré et hadopié.
//
Surtout que la partie non velue le lien vers le blog (qui est fort instructive) est passé inaperçu.
[^] # Re: ...
Posté par Kekun (site web personnel, Mastodon) . Évalué à 10.
S'il te plaît utilise les balises de citation et la prévisualisation, surtout si tu fait ça à tout les messages, ça serait plus lisible.
[^] # Re: ...
Posté par vladislav askiparek . Évalué à 2.
Bah, il peut éditer son message pour la correction.
[^] # Re: ...
Posté par redo_fr . Évalué à 10.
Ah oui! On pourrait s'attaquer au bureau: Par exemple remplacer les environnements configurables par une barre à gros boutons à gauche et sans interface pour personnaliser...Heu...Attendez...
Celui qui pose une question est bête cinq minutes, celui qui n'en pose pas le reste toute sa vie.
[^] # Re: ...
Posté par undeuxtroisout . Évalué à 3.
Où ça à gauche ? En plein milieu oui ! Enfin, à la gauche de l'écran de droite, ce qui revient au même. J'ai tenu 15 minutes, le temps de chercher comment modifier l'emplacement des gros boutons ou de les éjecter. Finalement, XFCE me plaît beaucoup.
[^] # Re: ...
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 1.
Ben justement, ça c'est la future grosse nouveauté de la prochaine version : on pourra caler les gros boutons au milieu, en bas (ou à gauche en bas si on préfère)
Puis on remettra le Big Fucking Button en haut à gauche, on lui fera invoquer directement les icônes des applications installées et... heu attendez.
[^] # Re: ...
Posté par imr . Évalué à 5.
Non, il faudra télécharger et activer une extension "dock to the right please i'm not worthy i know" après avoir téléchargé et désactivé l'extension "dock to the left is the right way".
[^] # Re: ...
Posté par Maclag . Évalué à 4.
Pourtant, le projet Gnome est clair: pour les fonctions "avancées", la manip sera légèrement plus compliquée.
Dans ton cas, la proposition est d'inverser le positionnement de tes écrans, les retourner à 180°, et tenir ta souris à l'envers.
Ils attendent ton retour pour savoir si c'est viable en prod...
[^] # Re: ...
Posté par Pierre Tramal (site web personnel) . Évalué à 2.
Il faut déplacer les écrans (physiquement). Comme ca tu peux mettre la barre tout à gauche. Et en retournant l'écran contenant la barre, tu peux même l'avoir à droite (renversée, mais faut pas trop demander...).
Et oui, avec GNOME, c'est l'utilisateur qui doit s'adapter.
[^] # Re: ...
Posté par reno . Évalué à 5.
Hum, avoir un "super init" a la systemd m'a parut avoir des arguments intéressant (surtout pour généraliser le démarrage "à la demande"),
maintenant par contre pour journald là j'avoue je n'ai rien compris a ses supposés avantages:
-déjà son comparatif était biaisé car il ne prenait en compte que le syslog initial et pas les améliorations déjà apporté
-je ne vois pas en quoi ajouter des hash aide en quoi que ce soit, il y a 3 possibilités:
1) les logs sont recopiés sur une machine distante sécurisée alors tu peux analyser l'intrusion et les hash ne servent a rien
2) les logs ne sont pas récopies et
2.a) le cracker est négligent: les hash ne servent à rien, tu peux analyser l'intrusion.
2.b) le cracker veut être discret: les hashs n'apportent rien, tu ne pourras pas analyser l'intrusion.
# ... ²
Posté par bubar🦥 (site web personnel) . Évalué à 8.
[^] # Re: ... ²
Posté par boq . Évalué à 5.
http://z0r.de/2268
[^] # Re: ... ²
Posté par VictorAche . Évalué à 6.
Putain, ça m'a pêté l'audio !
"The trouble with quotes on the internet is that it’s difficult to discern whether or not they are genuine.” Abraham Lincoln
[^] # Re: ... ²
Posté par plouf2123 . Évalué à 9.
c'est plus ce que c'était linuxfr... un commentaire avec une image de +3Mo evaluée à 9. en plus un gif animé. merde quoi !
[^] # Re: ... ²
Posté par pierre_80 (site web personnel) . Évalué à 0.
c'était mieux à vent
# Syndrome de la compatibilité ascendante
Posté par drakmaniso . Évalué à 10. Dernière modification le 02 décembre 2011 à 17:23.
La vraie question, c'est de savoir si on veut privilégier les changements dits "incrémentaux", qui dans la pratique consistent le plus souvent à ajouter des fonctionnalités par dessus une architecture qui n'était pas pensée pour ça, ou bien opter pour une approche "table rase", et repenser le système en vue des nouvelles fonctionnalités, quitte à jeter beaucoup de code existant.
Il fut une époque où le principal reproche que les linuxiens faisaient à Microsoft (et à Intel), c'étaient justement d'avoir une approche complètement incrémentale afin de garder le maximum de compatibilité ascendante. On était fier d'avoir un système avec une architecture adaptée, et de ne pas être l'esclave de la rétrocompatibilité.
J'ai l'impression aujourd'hui qu'une grande partie des linuxiens tombe dans le piège du Microsoft de jadis: s'accrocher à tout prix à l'existant, et refuser toute évolution qui ne soit pas incrémentale. (Heureusement, le noyau ne tombe pas dans ce travers)
On a vu ce que ça a donné avec PulseAudio: des cris, des pleurs, et au final, le bilan du nouveau système est très positif; notamment parce que cela a obligé plein de drivers à corriger leurs bogues et leurs incohérences.
Un bon exemple des méfaits des changement incrémentaux, c'est l'état de la couche graphique actuelle. Les fonctionnalités sont là, mais l'architecture est abérante et complètement inadaptée.
Bref, personnellement, j'aimerai qu'il y a plus de gens comme Lennart, qui aient le courage de proposer des changements de fond, plutôt que d'empiler des améliorations les unes par dessus les autres.
[^] # Re: Syndrome de la compatibilité ascendante
Posté par jseb . Évalué à 9. Dernière modification le 02 décembre 2011 à 17:38.
Personnellement, ce que j'ai le plus reproché à Microsoft, c'est sa «base de registre».
C'était une nouveauté de Windows 95.
J'aimerais qu'on calme Mr Lennart avant qu'il nous casse /etc .
Discussions en français sur la création de jeux videos : IRC freenode / #gamedev-fr
[^] # Re: Syndrome de la compatibilité ascendante
Posté par drakmaniso . Évalué à 3.
L'un des principaux problèmes de la base de registre (outre le format binaire), c'est justement que c'était une addition par dessus un système existant.
La même idée aurait put donner un bien meilleur résultat si cela avait fait partie d'une architecture cohérente. Par exemple le système de ressources du vénérable System 7 d'Apple était excellent, tant du point de vue développeur qu'utilisateur (les fonctionnalités ne sont pas tout à fait identiques à celles de la base de registre, mais les recoupent en partie).
[^] # Re: Syndrome de la compatibilité ascendante
Posté par vincent LECOQ (site web personnel) . Évalué à 4.
non, elle existait déjà dans windows 3.x
[^] # Re: Syndrome de la compatibilité ascendante
Posté par M . Évalué à 1.
//
C'était une nouveauté de Windows 95.
J'aimerais qu'on calme Mr Lennart avant qu'il nous casse /etc .
//
gnome n'a pas attendu Lennart avec gconf :)
Mais bon c'est vrai que tout le monde n'a pas migré : je propose d'intercepter les open/read/write de ces programmes pour les rediriger dans gconf !
[^] # Re: Syndrome de la compatibilité ascendante
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 7.
Des changements sismiques proposés par un seul type sans consultation préalable, ça fait forcément réagir.
[^] # Re: Syndrome de la compatibilité ascendante
Posté par totof2000 . Évalué à 10.
Et surtout ce type refuse de se remettre en question lorsqu'on lui dit que son truc ne marche pas.
De plus si son argument c'est la sécurité, le fait de monter une usine à gaz telle qu'il la voit est tout simplement aberrant.
[^] # Re: Syndrome de la compatibilité ascendante
Posté par dave . Évalué à 1.
Bonjour, je suis désolé mais je pense que Lennart sait ce qu'il fait. Si ses propositions manquaient à ce point d'intérêt, personne ne s'y intéresserait et elles ne seraient pas utilisées.
Systemd, the bright side of linux, toward a better user experience and on the road to massive adoption of linux for the desktop.
[^] # Re: Syndrome de la compatibilité ascendante
Posté par Maclag . Évalué à 7.
C'est-à-dire qu'on l'écoute histoire de pas se refaire avoir comme avec PulseAudio...
[^] # Re: Syndrome de la compatibilité ascendante
Posté par drakmaniso . Évalué à 8.
C'est justement pour cela que j'aimerai qu'il y ait plus de monde à proposer des changements; plus il y a d'options, plus y a de chance que l'une d'entre elles soit bonne.
Quand à la "consultation préalable", dans le logiciel libre, ça a toujours était très limité. On fait d'abord, et on choisit ensuite: c'est comme ça que la plupart des décisions se prennent, même du point de vue architectural (voir le fonctionnement du noyau, où souvent des implémentation concurrentes d'une même fonctionnalités sont développées en parallèle).
[^] # Re: Syndrome de la compatibilité ascendante
Posté par Gabin . Évalué à -9.
En avions-nous besoin?
Init suffisait, un petit néttoyage aurait été moins pénalisant ou pousser upstart plutôt qu'un system-D (porte bien son nom) qui bouscule tout.
Pulseaudio: pareil, peaufiner ALSA ou OSSv4 orchestré par JACKd (Ce qui n'excluerait pas les BSD ) aurait été bien bénéfique
Journald: No comment
/bin /sbin: RE-No comment
Comme on le voit, on aurait moins d'annonce fracassant et de fracas à l'usage et on resterait copains avec les systèmes BSD.
Bon cela dit, ils sont libres de faire ce qu'ils veulent, si ils veulent muter Linux en un hybride OS X/ReactOS/Redhat, libre à eux, ce qui m'ennuit par contre c'est que ça suive en général.
À croire que ça emmerde les gens d'avoir un système, une suite de soft stables plus de 5ans!
[^] # Re: Syndrome de la compatibilité ascendante
Posté par GeneralZod . Évalué à 7.
Tout le monde était d'accord pour dire que l'init SysV a fait son temps, d'ailleurs tout les concurrents de systemd sont incompatibles (launchd, upstart)
OSSv4 fait par les mecs qui ont rendu propriétaire OSSv3 ? jamais de la vie, améliorer ALSA ? avant PA, tout le monde passait son temps à contourner les bogues de celui-ci dans les couches supérieures, Lennart a permis de changer ça en refusant d'inclure le moindre hack.
Quant à Jackd, il n'a tout simplement pas les mêmes objectifs que PA.
C'est se voiler la face, les BSD avaient déjà un init différent, PA est posix-compliant et tourne sur différents système (OS X, Windows, FreeBSD, NetBSD), etc ...
Quant à Journald, tout le monde est d'accord pour dire que l'analyse de Lennart est correct, laissons lui le temps de développer sa solution et aux solutions existantes de corriger ça. Après, on pourra juger sur pièce.
[^] # Re: Syndrome de la compatibilité ascendante
Posté par totof2000 . Évalué à 10.
Arrete de généraliser avec tes "tout le monde" : c'est faux : je ne suis pas d'accord avec son analyse.
[^] # Re: Syndrome de la compatibilité ascendante
Posté par M . Évalué à 9.
idem, faudra d'ailleurs en parler aux utilisateurs de slackware pour l'init.
[^] # Re: Syndrome de la compatibilité ascendante
Posté par GeneralZod . Évalué à 3.
Slackware est un cas particuliers, ils ont un init BSD et ne cherchent pas à passer à autre chose (les *BSD ont eu déjà mis à jour leurs init depuis belle lurette). Ça fait des années que les distros avec un init SysV parlent d'en changer, launchd a été envisagé mais n'a pas été retenu pour des raisons de licence (Apple a passé launchd en licence Apache mais trop tard), upstart a été choisi mais n'avançait plus et personne hors ubuntu n'était passé au format natif (la compatibilité LSB est tout aussi temporaire que dans systemd).
Tu remarqueras que le procès "systemd casse toute ma façon de gérer l'init" s'applique tout autant à launchd et Upstart mais personne ne le leur a fait avec autant de virulence.
[^] # Re: Syndrome de la compatibilité ascendante
Posté par oinkoink_daotter . Évalué à 0. Dernière modification le 03 décembre 2011 à 14:18.
En même temps, Apple rilize un truc qu'il a pondu (launchd) en license "libre" fait pour leur OS à eux. Autant dire que la critique ils n'en ont rien à battre ...
edit: added missing woueurd.
[^] # Re: Syndrome de la compatibilité ascendante
Posté par GeneralZod . Évalué à 7.
tout le monde == les gens qui comptent c'est à dire les personnes qui ont expertise suffisante pour peser le pour et le contre (ie: le développeur d'upstart, les intégrateurs, etc ...), pas les trolls de LWN ou de DLFP qui se secouent la nouille parce qu'ils veulent pas changer leurs habitudes vieilles de 30 ans dont on a rien à foutre de leur avis. Je ne vois personne de sensé qui oserait dire que l'init SysV a encore sa place de nos jours.
Idem pour journald, le libre est une méritocratie, si ce que Lennart propose ne te plait pas, fais mieux encore !
[^] # Re: Syndrome de la compatibilité ascendante
Posté par totof2000 . Évalué à -10.
je n'ai qu'un mot (plutot 3 ): casse toi pauv' ...
[^] # Re: Syndrome de la compatibilité ascendante
Posté par Albert_ . Évalué à 0.
le libre est une méritocratie, si ce que Lennart propose ne te plait pas, fais mieux encore !
Si seulement cela etait vrai... Mais avec le poid de RH derriere lui c'est absolument pas vrai cette affirmation. Il peut proposer de la merde en boite (exemple PA) et etre acclame comme un dieu tant que RH suit cela ne pose pas de probleme.
[^] # Re: Syndrome de la compatibilité ascendante
Posté par ckyl . Évalué à 3.
Donc fais mieux encore et va bosser chez RedHat...
[^] # Re: Syndrome de la compatibilité ascendante
Posté par GeneralZod . Évalué à 10.
Je ne savais pas que RH avait le pouvoir magique d'imposer ses solutions à toutes les autres distros (Debian, SUSE, Ubuntu, Gentoo etc ...). Faut arrêter les conneries "Lennart bosse chez RH, gnagnagna, RH va pousser son truc".
Primo, la plupart de ses travaux ne sont pas des commandes de RH (RH n'a jamais demandé un remplaçant à Upstart, ça les a même bien emmerdé qu'il le fasse après la sortie de RHEL6), et il doit convaincre non seulement ses collègues mais également la communauté Fedora -hint: le FeSCo qui a la mainmise sur la partie technique est un comité 100% élu par les contributeurs- Secundo, le développement de PA a commencé bien avant que RH n'embauche Lennart, Tertio, faut pas prendre les développeurs de RH pour des buses, si Lennart proposait de la merde, tu crois sincèrement que les mecs diraient amen ?
Lennart a également pris l'habitude de travailler en collaboration avec des gens d'autres distros pour justement éviter l'effet "enfermement communautaire", ses derniers travaux ont été fait en collaboration avec Kay Sievert d'openSUSE (la différence, c'est que Kay Sievert n'est pas une grande gueule mais il est tout aussi efficace). Si ça t'amuses, tu peux parler de complot Chapeaux Rouges- Geckos Verts, mais c'était déjà ridicule dans la bouche du management de Canonical ...
[^] # Re: Syndrome de la compatibilité ascendante
Posté par Albert_ . Évalué à -2.
Qui a parle de pouvoir "magique"? De pouvoir financier ca oui mais magique non.
[^] # Re: Syndrome de la compatibilité ascendante
Posté par imr . Évalué à 6.
Il y a quand même une analyse d'une personne qui compte (le développeur de syslog) qui n'est pas d'accord avec l'utilité de développer journald et qui en a fait une analyse poussée.
Donc pourquoi dire "idem pour journald" sans en tenir compte?
[^] # Re: Syndrome de la compatibilité ascendante
Posté par ckyl . Évalué à 8.
Rainer Gerhards n'est pas le développeur de syslog mais de rsyslog. Mais plus important qu'être le dev d'un des démon syslog; c'est surtout l'auteur des RFC 5424, 5674 et 6012. Et un des contributeurs aux RFC 5425 et 5426. Bref il a passé beaucoup de temps à essayer de sortir un peu syslog de la vase dans laquelle il baignait. Sachant qu'il a fallut plus de 6 ans pour qu'un tout petit incrément comme la 5424 soit publié (et AFAIK pas encore implémenté partout), faut être armé de patience...
[^] # Re: Syndrome de la compatibilité ascendante
Posté par imr . Évalué à 2.
typo!
Tu dis ça dans le contexte de la discussion actuelle? Il est légitime d'essayer de développer quelque chose comme journald plutôt qu'essayer de contribuer à un processus trop lent qui ne bouge quasiment pas?
[^] # Re: Syndrome de la compatibilité ascendante
Posté par ckyl . Évalué à 6.
J'ai pas regardé en détail les propositions de journald et j'ai laché le draft de la 5424 depuis 2005; donc je pense pas avoir un avis très pertinent. Par contre beaucoup me semblent méconnaitre l'histoire de syslog, et m'ont l'air d'idéaliser un peu le truc (et le fait de mélanger sous le même nom API, protocole réseau et démon n'arrange rien). Le constat c'est qu'en dix ans on a à peine réussi à faire implémenter un protocole simplissime qui nettoie le bordel minimaliste existant. Donc ca ne m'étonne que moyennement que quelqu'un arrive avec ses gros sabots pour tout péter.
L'article de Gerhards Rainer cité plus haut me semble très juste. Comme lui, je préférerais que ca soit fait avec un peu de subtilité pour ne changer que ce qui est nécéssaire mais le monde syslog à peut être aussi cherché son sort en gardant la confusion sur le mot "syslog" et en restant sur quelques dizaines d'années d'historiques sans trop chercher à avancer.
[^] # Re: Syndrome de la compatibilité ascendante
Posté par GeneralZod . Évalué à 2.
TU confondrais pas analyse et réponse ? parce que ma citation originale c'est: Quant à Journald, tout le monde est d'accord pour dire que l'analyse de Lennart est correct.
Je n'ai pas dit que tout le monde était d'accord avec la réponse de Lennart mais avec l'analyse qu'il a fait du problème, c'est pas du tout la même chose.
[^] # Re: Syndrome de la compatibilité ascendante
Posté par imr . Évalué à 8.
Non, à amoins que tu aies mis de coté tout ce qui dans l'analyze de Rainer dit qu'il n'est pas d'accord avec l'analyse de Lennart, je ne vois pas comment on peut dire qu'il est d'accord.
Voici le résumé de son analyse de l'analyse de Lennart point par point, j'ai mis en gras les points de désaccord:
True
Mostly True and hard to make any argument against this
Partly True
Partly True
Misleadingly True.
Mostly wrong
Trivial
Partly Wrong
Rhetorically True
True
Wrong
Wrong
Il n'est bien sur pas d'accord avec les réponses de Lennart à son analyse puisqu'il n'est pas d'accord avec l'analyse.
Concluding my remarks, I do not see anything so broken in syslog that it can only be fixed by a total replacement of technology.
So extending existing applications, or writing new ones that tightly integrate into the existing toolset is the right thing to do.
Je précise que je n'ai pas d'avis sur la question dans un sens ou dans un autre, d'où les questions que je pose ailleurs pour m'informer.
Mais cette attitude de dénier des critiques parfaitement claires comme celles de Rainer, d'une personne qui compte, n'aide pas à penser qu'il n'y a pas une volonté de faire passer en force tout ce qui vient de redhat. Et comme à l'autre bout du projet, Lennart a exactement le même genre d'attitudes, il ne faut pas s'étonner de créer plus de résistances qu'il n'y en aurait eu, ni de jouer les victimes ensuite.
[^] # Re: Syndrome de la compatibilité ascendante
Posté par Anonyme . Évalué à -1.
Ha donc, on doit se refuser toute contribution à X.org alors.
Ou alors, on peut forker OSS et garder les copyrights de tous les contributeurs. Vu le niveau atteint par OSS, l’amelliorrer au lieu de créer PulseAudio aurait été bien utile (et avant ça, ne pas créer ALSA aurait été une bonne chose pour les systèmes UNIX).
Mais bon…
[^] # Re: Syndrome de la compatibilité ascendante
Posté par coïn . Évalué à 6.
yaca faukon, caifacile
show me the code
[^] # Re: Syndrome de la compatibilité ascendante
Posté par Anonyme . Évalué à -2.
Quel code, celui de OSSv4 ? Il est sur opensound.com.
Je ne comprends définitivement pas ton commentaire !
[^] # Re: Syndrome de la compatibilité ascendante
Posté par drakmaniso . Évalué à 8. Dernière modification le 02 décembre 2011 à 23:38.
Il faut vraiment arrêter avec cette manie d'essayer de réhabiliter OSS.
Quelque soit les améliorations apportées et la qualité de son API, son architecture fait qu'il est impossible de faire de l'audio "temps réel" avec, et est donc inutilisable pour la MAO. Paul Davis, développeur de Jack et Ardour, l'a suffisamment expliqué. Alsa a beaucoup de défauts, mais est la seule option si on veut un système qui puisse servir à tout le monde.
[^] # Re: Syndrome de la compatibilité ascendante
Posté par Anonyme . Évalué à 0.
Tout le monde ça veut dire uniquement Linux maintenant ?
[^] # Re: Syndrome de la compatibilité ascendante
Posté par Albert_ . Évalué à -1.
Et PA ne fait pas mieux voir meme pire niveau temps reel.
[^] # Re: Syndrome de la compatibilité ascendante
Posté par GeneralZod . Évalué à -1.
t'es nouveau ici ? Parce que ça montre que tu n'as pas du tout suivi le pourquoi de la création d'ALSA et je te conseille vivement de te renseigner (wikipedia est ton ami). OSS [:lol]
[^] # Re: Syndrome de la compatibilité ascendante
Posté par Anonyme . Évalué à 5.
Ok, donc tu affirmes quelque chose et quand j’y répond tu changes de sujet ? Pas mal, ça fait avancer le débat et tout !
Bon, je reprends :
Toi tu me parle d’ALSA alors que c’était une parenthèse à mon message ? Merci d’arrêter de me prendre pour un con, je connais l’histoire d‘ALSA et d’OSS.
[^] # Re: Syndrome de la compatibilité ascendante
Posté par imr . Évalué à 7.
Tu es vraiment nouveau ici.
[^] # Re: Syndrome de la compatibilité ascendante
Posté par M . Évalué à 1.
//
OSSv4 fait par les mecs qui ont rendu propriétaire OSSv3 ? jamais de la vie, améliorer ALSA ? avant PA, tout le monde passait son temps à contourner les bogues de celui-ci dans les couches supérieures, Lennart a permis de changer ça en refusant d'inclure le moindre hack.
//
Avec alsa, on a perdu l'aspect tout est fichier du monde unix et les gens ont du ce taper la libasound au API incompréhensible (d'ailleurs si existe aujourd'hui des version light comme salsa ou tinyalsa). Pour info libasound embarque un interpréteur lisp...
Je serais curieux de savoir comment il a été accepté dans le noyau linux (pas d'autre alternative ?)
[^] # Re: Syndrome de la compatibilité ascendante
Posté par oinkoink_daotter . Évalué à 6.
Non : sous Linux, tout n'est pas fichier car point de /dev/ethX pour les périphériques réseaux.
[^] # Re: Syndrome de la compatibilité ascendante
Posté par rewind (Mastodon) . Évalué à 2.
Une socket est un descripteur de fichier et on peut l'utiliser avec read(2) et write(2) comme n'importe quel autre fichier...
[^] # Re: Syndrome de la compatibilité ascendante
Posté par oinkoink_daotter . Évalué à 1.
Euh... En quoi ça invalide ce que je dis ?
[^] # Re: Syndrome de la compatibilité ascendante
Posté par Alex . Évalué à 3.
parce qu'en fait, dire tout fichier est un abus de langage, il faudrait dire tout est file descriptor
mais bon, cest du chipotage
[^] # Re: Syndrome de la compatibilité ascendante
Posté par oinkoink_daotter . Évalué à 2.
Ben même en fait : je ne suis pas spécialiste en prog réseau système sous linux, mais de ce que je vois sur l'internet, quand tu crées une socket elle n'est pas liée à une interface. Il faut passer un paramètre textuel dans le struct ifreq que tu passes en paramètre à l'ioctl qui est fait sur le descripteur de la socket pour désigner l'interface que tu cibles. Alors pour le tout est fichier ou descripteur de fichier, je persiste : bof. On est quand même vachement loin de "je fais(faisais) des ioctl sur /dev/dsp0" pour paramétrer ma carte son !
[^] # Re: Syndrome de la compatibilité ascendante
Posté par Batchyx . Évalué à 2.
Quand tu crée une socket, elle est liée à un protocole. Et quand t'a besoin de "configurer le réseau", t'est plus souvent en train de configurer la couche protocolaire que de trafiquer l'interface réseau.
Parce que l'interface filaire, la seule chose que 90% des gens ont besoin de faire, c'est de l'upper et la downer, et ptet d'activer le mode promisc et changer d'adresse mac.
[^] # Re: Syndrome de la compatibilité ascendante
Posté par oinkoink_daotter . Évalué à 1.
Et donc, grâce à la magie des "t'es plus souvent" et des "90%", on passe de "sous linux presque tout est fichier/descripteur" (ma position) à "tout est fichier/descripteur" ?
Je pinaille, certes, mais je ne suis pas le seul !
[^] # Re: Syndrome de la compatibilité ascendante
Posté par Batchyx . Évalué à 2.
Personnellement, je connais pas d'OS ou, par exemple, une table de routage est un fichier.
Après, placer le curseur entre "tout est fichier" et "rien n'est fichier" pour savoir qui à la plus grosse, je trouve pas ça intéressant.
[^] # Re: Syndrome de la compatibilité ascendante
Posté par ondex2 . Évalué à 5.
# cat /proc/net/route[^] # Re: Syndrome de la compatibilité ascendante
Posté par reno . Évalué à 6.
Hum,:
1) pas vraiment
2) ~500 commentaires sur 2 articles sur journald sur lwn.net avec beaucoup de commentaires négatifs, "tout le monde" j'aimerai bien savoir d'où tu le sors ça.
[^] # Re: Syndrome de la compatibilité ascendante
Posté par Littleboy . Évalué à 2.
C'est du talking point de chez Redhat, laisse tomber...
[^] # Re: Syndrome de la compatibilité ascendante
Posté par Misc (site web personnel) . Évalué à 6.
Que je sache, GeneralZod ne bosse pas chez Red Hat, j'ai vu une conf de lui il y a 2 semaines ou il explique qu'il fait des paquets Debian pour son taf ( mais ça, il le dit pas sur dlfp ). ( j'ai pas retenu le nom de la startup ou il bosse par contre ).
[^] # Re: Syndrome de la compatibilité ascendante
Posté par coïn . Évalué à -3.
c'est pas beau de dénoncer
[^] # Re: Syndrome de la compatibilité ascendante
Posté par Maclag . Évalué à 10.
Je regrette, j'en parlais au bar hier soir avec des potes, et on était tous d'accord.
Enfin... je suis pas sûr qu'on parlait de la même chose, parce qu'en rentrant, Dédé a égorgé le cochon et Gérard a couché avec la sœur de Lucien.
Mais à un moment je suis sûr qu'on parlait de journal!
[^] # Re: Syndrome de la compatibilité ascendante
Posté par Guillaume Knispel . Évalué à 4.
Le problème par rapport à l'unilatéralité qu'on retrouve souvent ailleurs et qui fait moins bondir notre microcosme dans ces autres cas est que dans ce cas là RH a une position importante et ambiguë dans le monde des distro GNU/Linux, et que là elle est de plus à la fois upstream et distributeur (majeur).
[^] # Re: Syndrome de la compatibilité ascendante
Posté par Sufflope (site web personnel) . Évalué à 10.
Ouais enfin il est paraît-il relativement ouvert (sauf peut-être aux pull request "git rm -rf", forcément...) et il discute quand même un minimum avant.
Ensuite... c'est un codeur prolifique et il est employé dans une des grandes boîtes qui code effectivement le LL. Ce qui aide à voir ses idées implémentées par rapport aux gueulards improductifs qui limitent leurs contributions à gueuler sur DLFP. Bah ouais c'est celui qui allonge le pognon qui décide sur quoi on bosse.
[^] # Re: Syndrome de la compatibilité ascendante
Posté par Guillaume Knispel . Évalué à -10.
Quand j'ai la diarrhée je suis moi aussi prolifique d'une substance dont pourtant personne ne raffole.
[^] # Re: Syndrome de la compatibilité ascendante
Posté par lasher . Évalué à 7.
100 millions de mouches ne sont pas d'accord avec toi.
[^] # Re: Syndrome de la compatibilité ascendante
Posté par zebra3 . Évalué à 10.
En même temps, il ne fait que proposer. Si tu ne veux pas de ces logiciels, ne les installe pas. Et si ta distribution te force à les installer, c'est elle qu'il faut blâmer, pas lui.
Et surtout, quand il propose quelque chose, il a travaillé dessus : ce ne sont pas juste des paroles, il y a du code derrière.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Syndrome de la compatibilité ascendante
Posté par barmic . Évalué à 5.
T'es sur de ton coup ? Parce que Linus refuse systématiquement du code un peu trop intrusif. Donc un patch qui t'annonce qu'avec lui il va tout gérer mieux que les autres a vraiment peu de chances de passer.
Le noyau possède aussi un tas d'abstraction pour pouvoir être modulaire et réduire au mieux la dépendance envers tel ou tel module. C'est très loin de l'idée que Lennart se fait de la programmation.
Bref, je ne sais pas si ton exemple est bien choisi.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Syndrome de la compatibilité ascendante
Posté par drakmaniso . Évalué à 5.
Proposer une nouvelle approche n'est pas synonyme de code intrusif (d'ailleurs, l'inverse n'est pas vrai non plus).
Linus n'a jamais bloqué un changement parce qu'il cassait la compatibilité ascendante. Des sous-systèmes entiers ont été remplacés, là où il aurait été possible de rajouter une couche sur l'existant, ou à côté.
Le seul commentaire que je fait vis à vis de Lennart, c'est que j'apprécie le fait qu'il propose du neuf, et j'aimerais qu'il y ai plus de monde à en faire autant. Cela est totalement indépendant de la qualité de ses propositions.
[^] # Re: Syndrome de la compatibilité ascendante
Posté par Guillaume Knispel . Évalué à 3.
Linux fournit de la retrocompatibilité dans ses interfaces externes.
Concernant ton argument plus général, l'idée principale du journal cité n'est pas de refuser l'évolution mais de débattre de la solution proposée, notamment à la lumière des autres solutions existantes, et de tenter d'analyser le comportement de RH vis à vis de leur plateforme et l'implication pour les plateformes GNU/Linux en général.
[^] # Re: Syndrome de la compatibilité ascendante
Posté par ploum (site web personnel, Mastodon) . Évalué à 8.
Tu mets le doigt sur qqch: Lennart n'a pas encore touché à la couche graphique. J'attends ça avec impatience :-)
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Syndrome de la compatibilité ascendante
Posté par cedric . Évalué à 1.
Hum, GDM ca compte ? Car avec systemd, il a commence a patcher GDM et la gestion du multi-seat. Si tu veux du multi-seat avec X.org, aujourd'hui, il te faut GDM et systemd... Donc d'une certaine maniere, c'est deja fait !
[^] # Re: Syndrome de la compatibilité ascendante
Posté par GeneralZod . Évalué à 3.
Et derrière, on se débarrasse de ConsoleKit qui n'a jamais été plus qu'une rustine pour tracer les utilisateurs, les sessions etc ... systemd le fait nativement en utilisant cgroups ! Rien n'empêche d'utiliser autre chose que GDM par ailleurs.
[^] # Re: Syndrome de la compatibilité ascendante
Posté par pasScott pasForstall . Évalué à -6.
C'est pas un piège.
Ca veut tout simplement dire que Linux est arrive a un point ou il est utilise pour de vrai en production, par des systems qui marchent et qu'on n'a pas besoin/ne veut pas toucher.
Pas juste par des geeks qui sont heureux de voir un système en vrac, parce que ça va leur donner de quoi jouer pendant des heures.
Le mec qui arrive et t'explique qu'il va tout changer, qu'il va falloir tout revalider, et que ça va être vachement mieux, tu vas le calmer direct - a moins que ce qu'il propose change radicalement ta vie.
Les gens ont généralement autre chose a faire que de bousculer un paquet de code qui marche très bien pour un système qui va soit disant marcher (mais en fait non, parce que y'a toujours un truc qui echappe a la QA), tout ça pour des bénéfices qui paraissent faible (ben ouais, on a toujours fait comme ça, alors c'est pas si mal que ça).
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Syndrome de la compatibilité ascendante
Posté par Misc (site web personnel) . Évalué à 7.
En l’occurrence, dans le cas de pulseaudio, je vois pas en quoi ça impacte les sysadmins. Si le souci est de devoir revalider, je pense que le sysadmin 1) fait soit déjà le taf pour tout le reste de la stack qui bouge ( surtout le kernel ) 2) fait soit faire ça par un fabricant ( Novell, Red hat, etc ).
Ensuite, non, le système d'init basé sur des scripts shells est sous optimal :
- soft à la con qui gére mal le concept ( genre bind, qu'il faut éteindre de façon asynchrone avec un outil en cli, genre apache avec des process forkés qui sont pas toujours tués, voir non géré dans le cas de cgi ). L'usage des cgroups permet de tuer proprement tout ça.
aucun foutu standard pour les scripts d'init, donc le code est dupliqué à qui mieux mieux
ce qui implique aucune API haut niveau potable pour connaitre l'etat d'un process ( et je parle pas des erreurs subtiles liés à par exemple la gestion des fichiers de pid ). Systemd gére ça via une API dbus, ce qui permet d'avoir une véritable sémantique plus propice à l'automatisation et sans faire X forks/exec.
des problémes de maintenances à la con dés que tu veux toucher à un script d'init, vu que c'est pas de la config, mais traité comme tel par certain ssysadmins. Systemd permet l'utilisation de template propre, et d'utiliser 2 fichiers, un pour les modifs, un pour la distrib.
Le reste ( limitation d'io, du cpu, montage de chroot/namespace privé ), c'est bonus. Mais pour moi, le systéme d'init à base de script était fondamentalement moisi du point de vue d'une distribution et d'un sysadmin. C'est pour rien que Gentoo a refait un truc à sa sauce, que Solaris et Apple ont pris cette voie, et que Ubuntu a commencé à bosser sur upstart. Le script de démarrage d'une distro basé sur RH/sysV est quand même un monstre en shell, bloated et qui fait le café, et c'est faire preuve d'un mauvais gout que de vouloir garder ça.
Debian a un repertoire /etc/rcS.d/ ce qui permet d'avoir moins de souci, mais qui ne règle pas les autres points ( vu que update-rc.d ou chkconfig, c'est kifkif ).
[^] # Re: Syndrome de la compatibilité ascendante
Posté par pasScott pasForstall . Évalué à -8.
Les sysadmin, non, tout ceux qui ont des billes dans le desktop/multimedia, ca risque de les enerver.
Ou pas remarque, vu le bordel du son sous linux, sont pas forcement a ca pret.
Ensuit, que l'init soit pourri, surement, ou pas, j'en sais trop rien.
Ce qui est sur, c'est que ca marche, meme si c'est chiant.
Tout changer ne va pas forcement plaire a beaucoup, parce qu'ils ont des machines de prods qui marchent.
Ca veut pas dire que c'est pas necessaire, juste que ca va faire chier du monde, c'etait a ca que je repondais initialement, si ca gueule quand qq chose change, ca veut dire que le truc qui change est utilise en production.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Syndrome de la compatibilité ascendante
Posté par Etienne Bagnoud (site web personnel) . Évalué à 10.
Non mais en fait l'init c'est un truc qui, dans le cas idéal, devrait se produire une fois dans la vie d'un serveur.
Les gens qui parlent autant de l'importance d'init c'est ceux qui n'ont jamais vu démarrer un serveur qui met 10 minutes à arriver au chargeur de démarrage. Et l'exécution des scripts c'est infime car généralement ces scripts lancent des gros logiciels plein de données, donc l'optmisation est parfaitement inutile.
Ensuite, quand tu as un problème au démarrage, des scripts shell c'est bien plus facile à corriger.
Et dans certains cas les services tu les vire du démarrage parce que tu as une interaction pour lancer (tout ce qui nécessite un certificat SSL, tu ne laisses pas la clé privée non-chiffrée sur un serveur, donc entrer le mot de passe).
Lennart travaille en direction d'un linux pour le bureau, mais s'éloigne d'un linux pour le serveur.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Syndrome de la compatibilité ascendante
Posté par Misc (site web personnel) . Évalué à 5.
Parce que linux est passé d'un systéme pour innovateur à un systéme pour simple utilisateur. j'ai toujours dit que ce que les gens cherchent ( "séparation systéme/ application", "longue durée de vie" ), c'est un *bsd. Sauf que quand je dit ça, personne ne le fait, tout le monde reste bloqué. Et maintenant, tout le monde rale parce que du nettoyage de fond est fait, mais personne n'ose franchir le pas quand même.
# distribs
Posté par coïn . Évalué à 10.
bah, si les distributions intègrent les devs de Lennart, c'est qu'elles y trouvent un intérêt.
Et si c'est mal intégré, ou intégré trop tôt, c'est de la faute aux distribs
[^] # Re: distribs
Posté par Tonton Benoit . Évalué à 10.
+1, Faut arrêter de se victimiser, il se connecte pas par ssh la nuit sur nos PC pour y installer ses productions. Si la politique de gestion du son/de l'init ou d'autre chose de votre distrib vous convient pas, changez.
Je suis sous Gentoo et j'ai installé PulseAudio, aucune obligation, aucun programme ne le demande, je suis masochiste ? Non ! Juste qu'au final c’est mieux.
[^] # Re: distribs
Posté par Psychofox (Mastodon) . Évalué à 8.
En quoi c'est mieux ?
La qualité du son ne s'est pas améliorée.
Si au moins ça avait pu permettre de se débarasser de cette horreur d'alsa, la ce serait mieux. Mais en l'occurence c'est une surcouche inutile par dessus le même bordel qu'avant.
Tout ce que je vois en plus c'est de l'utilisation CPU. Bon au moins maintenant ça ne fous plus la merde comme avant.
[^] # Re: distribs
Posté par Tonton Benoit . Évalué à 8.
Déjà la surcouche à le mérite de me le cacher le bordel, à chaque fois impossible de me rappeler comment capturer le micro avec ma carte-son (y'a au moins trois réglages à faire, pour un truc que j'utilise rarement c'est pas intuitif), avec PA je sélectionne le micro et ça marche, j'ai plus de réglage de volume pour le « IEC958 machinChose », à la place des noms clairs, les Windosiens ne peuvent plus se foutre de ma gueule avec le mixeur de leur Vista, j'ai de quoi répondre.
Je peux enregistrer directement la sortie son de mon PC dans Audacity en sélectionnant le périphérique « pulse » (à noter le nom pas clair, Audacity utilise l'émulation alsa de pulse-audio), pour arriver à faire la même chose avec alsa faut ajouter les bons device dans le .asoundrc.
Tout ça pour quel inconvénient ? Chromium/Chrome gère encore mal PulseAudio, pas la faute à Lennart ça.
[^] # Re: distribs
Posté par Maclag . Évalué à 6.
Je pense que l'idée c'est quitte à avoir une transition douloureuse pendant laquelle on n'a plus grand chose qui fonctionne correctement, un gros boulot de développement et débogage et un tas de trucs côté applis à réécrire, il aurait peut-être été préférable d'imaginer une solution complète plutôt qu'une surcouche qui finira un jour comme ESD et Arts: remplacée par une autre couche plus révolutionnaire au-dessus du même bordel.
Dans une bagnole, on peut changer le volant, la moquette, même le calculateur. Si le moteur est mal branlé au départ, ça ne résoudra rien du tout sur le long terme.
Linux en embarqué, ça veut dire PulseAudio sur les smartphones??
[^] # Re: distribs
Posté par Misc (site web personnel) . Évalué à 7.
Donc, je rappelle :
"pulseaudio, ç'est juste une couche faut faire plus"
et
"systemd, c'est trop bloated, ça fait trop de chose".
Visiblement, Lennart doit lire linuxfr car il écoute les conseils schizophrènes de la foule de commentateurs. Ce qui n'empéche pas les gens de trouver des raisons de râler, bien sur :)
[^] # Re: distribs
Posté par Maclag . Évalué à 7.
D'abord ch'uis pas d'accord!!
Sérieusement:
-Alsa fait soit trop de choses, soit pas assez, mais a le cul entre deux chaises.
-PulseAudio a des fonctions redondantes avec Alsa, et désolé pour ceux à qui ça ne plait pas de l'entendre, mais la philosophie Unix, c'est faire une chose, et la faire bien. Quand on voit le bordel mis dans certaines distros trop pressées et la quantité de problème rencontrés par les utilisateurs, on a du mal à imaginer que PulseAudio a été pensé pour faire une seule chose bien...
-Systemd: Pareil. Usine à gaz qui de plus permet d'isoler la communauté Linux de toutes les autres.
Et puis plus généralement, les révolutions sont parfois nécessaires, mais là j'ai l'impression que c'est systématique.
On n'aime pas le son? Alors on va pondre un PulseAudio révolutionnaire qui fera le café.
On n'aime pas l'init? Et ben Systemd se charge d'être le plus différent possible de tout ce qui est connu.
Et on recommence avec les logs.
Pourquoi ne pas plutôt lancer une branche Alsa2, avec des bases saines et une vision claire de ce qui doit rester dedans et ce qui doit en sortir?
Pourquoi ne pas bosser avec init-ng et autres upstart au lieu de refaire la révolution?
Les critiques contre le manque d'utilité du démon journal vont aussi dans le même sens.
C'est sûr, on est moins célèbre pour avoir bossé sur la version 2 d'un outil déjà bien connu que pour avoir pondu LE truc à la mode que les distros veulent le plus vite possible...
[^] # Re: distribs
Posté par GeneralZod . Évalué à 3.
C'est déjà le cas avec WebOS et Meego, y a eu pas mal de conf à ce sujet aux Linux Plumbers Conf et Embedded Linux Conf ... AVoir une couche de haut-niveau ça facilite pas mal la vie. PA c'est fait pour le grand public et convient parfaitement à cet usage.
PA ne connaitra probablement pas le destin de ESD et Arts pour deux bonnes raisons:
* le refus des développeurs d'intégrer le moindre hack qui n'y a pas sa place. Si ALSA est bogué, on corrige ALSA point barre.
* une bonne conception, PA c'est l'équivalent de CoreAudio sous OS X, pas d'ESD.
Faut arrêter de comparer PA à Jackd, les deux n'ont aucun rapport, le premier vise le grand public, l'autre la MAO -et ne sont pas en compétition-. Jackd par défaut serait une idée complétement stupide que même les développeurs de Jackd déconseillent, et les gens qui font de la MAO, sont principalement sous Mac ou windows, ceux qui le font sous GNU/Linux sont pour la plupart soit des hobbyistes ou des chercheurs.
[^] # Re: distribs
Posté par claudex . Évalué à 2.
J'ai essayé mais le son était d'une qualité exécrable et n'ayant trouvé aucune doc pour changer ça, je l'ai viré.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# Perplexe
Posté par patrick_g (site web personnel) . Évalué à 9.
Tout l'article a été écrit pour pouvoir accuser Red Hat de forker l'écosystème Linux. J'avoue que je ne comprends pas du tout ce raisonnement. Il me semble que Lennart a travaillé sur journald avec Kay Sievert qui bosse chez Suse non ? Est-ce que ce simple fait ne remet pas en cause la théorie de la cabale redhatienne développée dans l'article ?
[^] # Re: Perplexe
Posté par feth . Évalué à 2.
Toi tu ne pourrais pas travailler chez http://scientistsofamerica.com
[^] # Re: Perplexe
Posté par Albert_ . Évalué à -10.
Enfin tu veux bien me rappeler le system de paquet utilise par Suse?
[^] # Re: Perplexe
Posté par imr . Évalué à 2.
Je me demande d'où vient cette idée?
Il faudrait que tu interviouves le journaliste total qui a écrit ça.
Et puis, c'est vrai qu'il y a des paranos pour dire qu'une des motivations de tous ces changements, c'est de se mettre en avant et de controler le développement de linux pour garder ses compétiteurs dans le trou. C'est ridicule.
[^] # Re: Perplexe
Posté par GeneralZod . Évalué à 3.
voilà le commentaire de Lennart Harald Hoyer get in the car! Come over to kill /lib, /bin and beer.
Les malcomprenants ont toujours du mal avec le concept de second degré, ici.
[^] # Re: Perplexe
Posté par imr . Évalué à -1.
A qui le dis tu!
[^] # Re: Perplexe
Posté par patrick_g (site web personnel) . Évalué à 2.
Je fais une différence entre l'écosystème Linux et les autres systèmes libres.
Lennart se fiche de tout ce qui n'est pas basé sur le noyau Linux car il a choisi d'utiliser à fond les technologies spécifiques du noyau. Ses logiciels sont donc compatibles avec toutes les distros Linux et dire que Red Hat forke par rapport aux autres est donc faux (d'autant que Kay Sievert bosse avec Lennart).
[^] # Re: Perplexe
Posté par imr . Évalué à 6.
Tes intentions, c'est pas le problème.
Tu vois pas en quoi ta phrase peut être reliée à certaines façons de penser ensuite? Et tu ne vois pas que l'origine de cette phrase est l'attitude de lennart? Elle est pourtant exposée dans la phrase que je cite au dessus (et pour les fanboys malcomprenants, elle est bien de lui, le post de kay sievert c'est la phrase en dessous) ?
Il aurait pu dire "yeaa, je suis content parce que c'est vraiment une super avancée pour linux, fedora a raison!" qui aurait produit le même effet sans induire qu'il fait les choses juste pour être devant les autres, ce qui est une composante de son comportement, il faut être aveugle pour pas s'en rendre compte.
Le débat n'est pas vraiment est ce que les technos poussées par redhat sont compatibles linux, le débat est "est ce que la manière dont redhat pousse ses technos fait plus de bien que de mal et pourquoi?"
Machiavélisme (c'était ma thèse, on oblige les technos à venir de redhat, on devient un upstream, on transforme les autres distros en contributeur, ceux qui veulent développer leurs solutions on les torpille et on les accuse de ne pas contribuer, pendant ce temps on développe pulseaudio plutot que contribuer à alsa ou radeon plutot que radeonhd, par exemple.)
ou incompétence (pas de controle des dommages sur la communication parce qu'on s'en fout des dommages, on est les plus forts, Lennart fait ce qu'il veut, NIH, pas assez de ressources donc 1 seul dév sur des projets pharaoniques et pas assez de matos par exemple filé à lennart sur pulseaudio, pas de contact pris avec les autres, par exemple on s'en fout de rsyslog, donc au final, on préfère développer des trucs qui ne marchent pas bien pendant 2 ans et plomber tout le desktop plutot que développer à coté tout en réutilisant un truc qui marche pendant ce temps).
Moi je reste partagé, j'ai bien reconnu que je me trompais avec la discussion sur upstart par exemple, donc tout semble indiquer une manière de faire qui n'est pas maitrisée plutot qu'un réel machiavélisme, le problème c'est que je préfèrerais que la distro leader de linux et qui est un contributeur important, soit un machiavel plutot qu'un énième projet qui se lance dans des modifications qu'elle ne peut pas assumer, comme sur les desktop actuellement.
En ce qui concerne systemd, j'ai bien reconnu que ça marchait bien "chez moi", dans les discussions sur journald, j'ai relancé le fait que lennart a dit avoir pris contact avec beaucoup des comptes utilisateurs de journaux et leur demande. Le problème c'est que ce genre de reconnaissance, je l'avais eu sur pulseaudio en 2008, j'était plutot un défenseur du concept, je voyais l'importance du besoin, jusqu'à ce que je vois dans les forum l'importance des dégats en 2009 et surtout la manière de ne pas assumer les problèmes causés et de les rejeter sur les utilisateurs ou sur canonical/ubuntu. Je ne peux pas oublier ça, ni les déclarations à l'emporte pièce du type "je suis génial, on est les meilleurs, vous comprenez rien" qu'il avait en parallèle.
Donc j'ai activé systemd sur une de mes machines, je vois les bons cotés, j'essaie de suivre les discussions, mais je vais pas m'aveugler sur les problèmes s'il y en a; je vais pas mettre de coté des analyses de gens qui comptent comme l'auteur de rsyslog; je vais suivre mieux upstart pour voir s'il y a du dev dessus et ses capacités (elles sont peut être plus adaptées à mon cas) et je vais être triste que mon linux soit de plus en plus hors de ma portée.
Et si ils ont changé leur méthode de développement et que le truc est sorti fini, tant mieux.
Parce que les logiciels libres, c'était pas seulement "release early, release often" c'était aussi, "it's ready when it's done".
A l'heure actuelle, le gros projet le plus stable et le mieux développé dans tous ceux que j'utilise, c'est le noyau. Pourtant, c'est celui qui est le plus à même de tout péter, et entre le 2.0, le 2.2 et le 2.4, je me souviens de pleins de pétages spectaculaires et de pleins de déclarations et de dénégations.
Mais il faut reconnaitre que linus s'est éloigné des déclarations et des manières de cowboy qu'il avait alors et que maintenant, il fait attention à ses utilisateurs et quand il se sert encore de ses manières de cowboys, c'est pour tenir ses contributeurs, pas pour faire la bite au cirage à ses utilisateurs.
Ou alors aussi pour faire la bite au cirage aux autres projets pas aussi bien géré que le sien, ça doit être rageant d'avoir amené le noyau à ce niveau et de voir ça torpillé par l'état des desktop et des distros.
Bref, j'aime bien redhat même quand je les imagine plus machiavéliques qu'ils sont, et j'aimerais bien pouvoir ne plus me méfier des projets qui sortent de leurs pattes.
# Toujours le même problème !
Posté par Ontologia (site web personnel) . Évalué à 3.
http://meta.libera.cc/2008/01/worse-is-better-versus-right-thing-dans.html
Syslog est un système efficace mais criticable. Son avantage premier est d'être simple, c'est la raison de son adoption.
Je serai très intéressé de voir si Lennart arrive à imposer "The Right Thing"... pour une fois...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Toujours le même problème !
Posté par Guillaume Knispel . Évalué à 10.
Worse is better aussi parce que la simplicité permet la souplesse à bas coût. Faire des usines à gaz, c'est interdire de les attaquer par les outils traditionnels Unix habituels génériques. The Right Thing n'est souvent que Right dans la tête et pour les besoins du concepteur. À voir les conceptions de Lennart, elles sont sans doute d'un très bon niveau mais ressemblent fortement à Win32 : une API géante avec des interdépendances de partout, et fuck les adeptes de la philosophie Unix.
Ça ne me gênerait pas si ce n'était pas fait par un type et une boite qui ont une telle influence sur l'écosystème, car d'un point de vue égoïste j'ai juste envi de continuer tranquillement d'utiliser un GNU/Linux qui ressemble dans sa philosophie technique à un Unix (même si l'érosion a malheureusement débuté depuis quelques années) et non à un hybride Unix-Windows mal fini.
À mon avis tout ce bordel relève du complexe de "oh mon dieu "Linux" est toujours pas prêt pour le desktop" qui est une connerie phénoménale (pas le diagnostique mais la malheureuse conclusion que certains veulent en tirer qui est d'essayer de le rendre prêt, et qui font des choses inadaptés pour et qui niquent toute la philosophie en passant) et aujourd'hui encore plus une connerie qu'avant vu les nouveaux marchés (téléphone tablette "cloud") et la pérennité de ceux existants sur lesquels GNU+Linux sous philosophie Unix à du succès (serveurs, box).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.