gasche a écrit 1151 commentaires

Mais c'est trop intéressant, ça, comme commentaire ! Merci de participer de façon constructive à un débat de fond !

Franchement je n'ai pas trouvé ce panel très intéressant, et ça a contribué à me faire penser que les panels, sauf quand c'est vraiment très très bien fait, sont toujours un peu ratés. Ce que j'ai retiré de cette présentation c'est que Simon Peyton-Jones a trop la classe, et que Martin Odersky et Don Syme auraient aimé travaillé ensemble plutôt que faire deux langages séparés (idée qui m'a surpris et intéressé).

J'ai écrit un commentaire reddit sur les exposés intéressants du Milner Symposium d'un point de vue langages de programmation. À mon avis dépenser son temps en lisant les slides des présentations citées sera beaucoup plus productif et intéressant que regarder la vidéo de ce débat.

Je profite du fait que LinuxFR et reddit utilisent tous les deux markdown pour citer le commentaire en plein ci-dessous. En espérant que ça motivera les gens à comprendre l'anglais.

The most programming-related talks of the symposium were probably Xavier Leroy's The continuation of functional programming by other means and Martin Odersky's Objects and modules: two sides of the same coin?. For more foundational aspects of language and type systems, Benjamin Pierce's Types à la Milner and Robert Harper's Defining a programming language were also very interesting.

If you like pi-calculus and concurrent communication calculi, I personally enjoyed Davide Sangiorgi's Some remarks on bisimulation and coinduction and Jean Krivine's Jobbers, sentient buildings and lions: a short walk into Robin Milner's tower. Finally, if you're into weird little mathematics puzzles (I think notfancy might enjoy this for example), Jan Rutten's Coalgebraic bisimulation felt to me like a possibly anecdotic, but nice and interesting presentation.

Tout à fait. Il s'agit d'une spécification pour une approche plus propre (car plus formalisée) des problèmes de gestion de dépendances. CUDF est un format texte prévu pour que les gestionnaires de paquets expriment leurs problèmes de mise à jour dans ce format, le passent à un solveur séparé donc c'est la spécialité, et reçoivent des indications sur le bon plan de mise à jour à choisir (garder telle version de tel paquet pour éviter un conflit entre la dépendance de sa version suivante et tel truc que l'utilisateur tient à obtenir, etc.).

Le jour où des guéguerres de licences (L)GPL/BSD empêcheront la communauté du logiciel libre de profiter de la recherche qui est fait par ses propres membres et dans son intérêt, on sera tombé bien bas.

Et les problématiques de CUDF ne concernent pas que les distributions de systèmes d'exploitation, mais les gestionnaires de paquets au sens large : les outils de packaging de langages de programmation comme Ocaml, Python, Haskell, Ruby, la gestion des plugins Eclipse, potentiellement les scripts Emacs, classes LaTeX, etc. Tout ce qui a évolué vers un "gestionnaire de paquet" séparé de l'outil d'installation de logiciels de la distribution (souvent parce que ces outils n'étaient pas jugés assez flexible ou que la communauté en question voulait quelque chose de portable) peut bénéficier d'une approche commune et raisonnée à la gestion des dépendances, et de la délégation de certaines responsabilités à des outils spécialisés. On a tout à gagner à centraliser les efforts sur ce front difficile (et pour lequel les problèmes ne se font souvent sentir qu'une fois que le nombre de paquets atteint une masse critique, moment où il peut être difficile de changer les algorithmes ad-hoc employés jusque là).

À chaque fois que je vois un nouveau gestionnaire de paquet qui sort et qui doit gérer les épineux problèmes de gestion des dépendances lors des mis à jour, je sens un petit pincement au cœur à l'idée qu'il y ait une base de code de plus qui essaie de résoudre ce problème difficile de façon approximative et certainement peu satisfaisante.

Il y a eu en europe deux projets de recherche européens, EDOS puis MANCOOSI, dédiés aux problématiques liées aux grosses bases de paquet. Entre autre résultat (par exemple des outils d'administration des répertoires de paquets côté distribution), ils ont défini un format généralisé d'expression des dépendances d'un paquet, CUDF, qui permet d'utiliser des SAT solveurs divers pour avoir des résultats de bonne qualité.

(Pour quelques exemples de problème de mise à jour, cf. cette page de résultats du projet EDOS qui compare plusieurs algorithmes de révolution, libres.)

La prochaine fois que vous voulez créer un gestionnaire de paquet, ne réinventez pas la roue et utilisez CUDF et les outils associé pour une gestion raisonnée des dépendances.

Les traits de rust sont en fait assez éloignés des traits/mixins des langages objets habituels puisqu'ils peuvent s'implémenter sur un peu n'importe quel type. Mais oui il y a l'idée qu'il s'agit d'un ensemble de fonction, que les traits ne portent eux-mêmes pas d'état, c'est le type sur lequel on implémente le trait qui doit porter l'état nécessaire.

Si tu veux te renseigner sur les traits de Rust tu peux regarder la documentation (lire sur "impl" aussi en dessous, c'est lié) mais c'est un peu court en explications, ou alors ce billet qui explique l'état actuel après le changement du système de traits cet été, ou éventuellement ce document de travail qui explique les choix de conception.

Les goroutines n'ont rien de nouveau dans le sens où elles étaient déjà présentes sous des noms un peu différents dans toute la famille de langages de Rob Pike basé sur le formalisme CSP de Hoare (en gros, avec des canaux; cf. ici pour un historique). Newsqueak (qui a été développé en gros entre 1985 et 1990) avait un mot clé begin qui faisait comme go aujourd'hui, et ces fonctionnalités ont été repris par les langages Alef puis Limbo utilisés sur les systèmes basés sur Plan9. Le fait que ces langages aient bénéficié de moins de publicité que Go ne fait pas des goroutines une idée nouvelle : c'est quelque chose de bien connu des concepteurs de Go qui ont repris dans ce nouveau langage une idée qui marche bien. C'est bien ce mode "best-of" dont je parle, et je ne critique pas forcément, c'est utile d'avoir des langages qui consolident les acquis des développements précédents.

Pour les traitements de la concurrence, j'apprécie personnellement beaucoup ce qui se fait dans le langage Oz/Mozart sorti en 1991, où le mécanisme de communication entre fils concurrents est une unification à la Prolog. Je trouve aussi intéressant ce qui se faisait sur le Join calculus (1995-2000), où on utilise une communication par canaux avec des conditions de réception sur plusieurs canaux simultanés (si machin, truc et bidule ont reçu des données et que l'entrée de bidule est de la forme chose), qui est une primitive expressive et assez intéressante.

Rust est en effet un langage très intéressant (à mon humble avis ce qui se fait de mieux en ce moment niveau collaboration entre l'industrie, la communauté du logiciel libre et la recherche). Les changements de la 0.4 sont variés et plus intéressants pour la plupart que des renommages de mots-clés. Quelques détails (essentiellement une traduction de mon message reddit à ce sujet):

• comme évoqué dans la dépêche, les développeurs sont en train de s'éloigner de la présentation des langages objets typiques (les valeurs sont la combinaison d'un état privé et des opérations qu'elles gèrent) vers une présentation séparée, avec d'un côté des records pour les données, et un système de "traits", qui correspondent en fait assez exactement aux type classes de Haskell, pour transporter les implémentation. L'idée est qu'on définit des interfaces/traits (mettons Printable) et que chaque type peut dire ensuite "je sais être Printable, voilà comment m'afficher"; ensuite le compilateur passe ces implémentations avec les valeurs de façon implicite, en utilisant les types des valeurs. Il n'est pas encore clair de savoir comment les programmeurs vont s'organiser, mais pour l'instant ça ressemble à un mouvement vers des types abstraits de données plutôt que des objets (selon le sens de l'article On Understanding Data Abstraction, Revisited de William Cook en 2009)

• les développeurs et développeuses de Rust ont pas mal réfléchi aux question d'export de modules, de résolution des noms (à quoi fait référence tel nom ?), et bougent vers un système plus propre avec des séparations entre les différentes étapes de résolution

• l'utilisation de types de méthodes où apparaît explicitement l'argument self, comme en Python, permet de mettre des quantificateurs de type sur cet argument pour indiquer comment la méthode se comporte avec l'état interne de l'objet : si elle le considère comme immutable, le passe en référence, etc. C'est une évolution intéressante.

• les notions d'état mutable / non mutable / const, et de fonctions pure, continuent à évoluer en Rust. C'est un point de conception délicats des langages mainstream qui essaient de combiner effets de bords et bonnes propriétiés (D a eu le mêmes genre d'errances): on essaie de ne pas utiliser un système explicite trop compliqué comme peuvent le faire les chercheurs du domaine, mais d'avoir un truc pas totalement stupide non plus, et le compromis est difficile à trouver—à mon avis on n'a pas fini de voir des changements sur ce front là.

Rust est un langage qui essaie d'apporter des idées nouvelles à la programmation système (… contrairement à Go qui fait un best-of des anciennes idées déjà bien connues, ce qui est très utile en soi mais quand même moins excitant), les concepteurs n'ont pas peur d'expérimenter et de faire encore longtemps des changements fondamentaux. Ça veut dire qu'il ne faut pas vouloir l'utiliser pour des projets sérieux à maintenir sur le long terme aujourd'hui, mais plutôt le voir comme un véhicule en déplacement.

Par ailleurs, voir des chercheurs se mettre à travailler ensemble suite à une news sur LinuxFR, c'est sans doute ce qui peut arriver de plus intéressant dans des commentaires de news; le titre de "pollution" est bien pessimiste !

L'article sur "les métiers de l'Open Source" est trompeur et donc mauvais. L'extrait cité est inepte (des langages de programmation "open source", et alors ?) mais le reste de l'article n'est pas tellement meilleur. Il ne s'agit pas du tout de travailler à produire du logiciel open source !

ceux-ci laissent en effet entrevoir un avenir des plus engageants pour ceux qui possèdent des expertises liées à Android, à Linux et aux logiciels libres.

Les développeurs de logiciels et les responsables qualité figurent en tête de liste, et parmi ceux-ci on trouve également les professionnels de Python, Ruby on Rails, Android et JBoss. « Le besoin en compétences autour des langages de programmation Open Source utilisés pour de nombreuses applications et technologies web est évidente concernant Python et Ruby »

On demande des développeurs qui connaissent les technologies Open Source (surprise, il y a un marché pour les applications Android, et on peut développer des sites webs avec des langages open source tels que Ruby, Python, ou tiens PHP d'ailleurs…), mais il ne s'agit absolument pas en premier lieu de développer des logiciels open source. Tout le monde utilise de l'open source en interne, c'est une évidence, et il y a un besoin de compétence. Mais tant que c'est pour produire au final du logiciel propriétaire, je ne vois pas pourquoi on appellerait ça "les métiers de l'Open Source", ça n'a rien à voir.

(Je ne dis pas que ce n'est pas bien que les gens développent leurs sites webs propriétaires avec HTML/JS plutôt que Flash/Silverlight, quand ils peuvent; c'est bien, mais ça n'en fait pas pour autant un "métier de l'Open Source".)

J'ai le sentiment d'avoir déjà répondu à cette question : les architectures CPU n'influent que très peu sur les choix de design du langage, alors que le choix d'une machine virtuelle contraint beaucoup l'espace de design possible. Si demain tout le monde passe à du PowerPC, les compilateurs ne changeront pas des masses. Par contre prendre un langage .NET et le faire tourner sur la JVM ou inversement, et ce alors que ce sont pourtant des machines virtuelles assez proches (je ne parle pas de Parrot ou quoi), c'est très difficile (par exemple il y avait eu des essais de porter Scala sur .NET, ça n'a pas été un franc succès et depuis Scala a encore évolué pour mieux supporter l'interopérabilité avec Java).

Je voulais bien sûr parler des "auteurs de compilateurs", désolé du lapsus idiot—et merci d'avoir su comprendre tout de même ma pensée en corrigeant cette erreur évidente… en fait non. S'il était possible d'éditer ses messages sur LinuxFR, je corrigerais le mien avec joie pour qu'il soit plus facile à comprendre pour les lecteurs qui vont suivre, tout en mettant en bas un petit message pour te remercier de la correction.

Les auteurs de compilateurs que je connais ont écrit des backends plusieurs architectures non-x86, et sont donc au courant des différences entre architectures (et ont leurs petites préférences personnelles sur tel ou tel sujet) même si le grand public n'utilise presque pas les autres. Dans le cas de Compcert par exemple, si je me souviens bien le backend PowerPC a été écrit en premier.

Mon argument tiens donc toujours : dans le cas d'une compilation vers la machine, j'ai l'impression que le support de telle ou telle architecture a souvent une influence assez limitée sur le design d'ensemble du langage, contrairement aux auteurs de compilateurs qui visent des formats pas vraiment prévus pour ça comme le bytecode JVM ou le Javascript. (Après il reste la question de la FFI et de la compatibilité de l'ABI, et ça peut aussi être important et galère selon les systèmes. Et les problématiques sont toutes autres quand on compile vers des choses exotiques comme un GPU.)

Une remarque qui n'a pas grand chose à voir : pendant ma première intervention je me plaignais du peu de contenu technique dans les commentaires, j'ai l'impression que la tendance a un peu changé… En contrepartie, j'ai l'impression d'avoir perdu mon temps et d'être frustré, mais je me le reproche à moi-même, pas aux autres.

Je ne comprends pas le rapport entre le choix de cibler Java ou pas et le choix de cibler l'architecture x86 ou pas. Tu as déjà souvent rencontré des auteurs de logiciels qui te disent avec passion "ah ma vie serait tellement plus simple si tout le monde utilisait tel modèle de SPARC" ? À l'extrême rigueur je pourrais l'imaginer pour le Cell (mais en réalité c'est l'inverse, les gens fuient cette archi jugée trop difficile à bien programmer) ou quelques machins exotiques, mais ça m'a l'air assez anecdotique. Au contraire les gens qui visent la JVM vont pouvoir te fournir une longue liste des problèmes que ça leur pose (sauf bien sûr s'ils reprennent exactement la sémantique dynamique de Java, comme en gros Kotlin ou Ceylon).

(Quand au jeu de qui a raison en regardant wikipédia, je t'envoie à la page anglaise correspondante qui dit explicitement "Machine code should not be confused with so-called "bytecode", which is executed by an interpreter." dans l'introduction. Malheureusement cette explication n'est pas au dessus de toute critique et je suis convaincu que ça ne règle pas le débat; peut-être que la mention proéminente et cohérente de la JVM dans l'article Bytecode t'en dira un peu plus, et sinon on en est limité aux arguments d'autorité : bien que non expert dans le domaine, je connais relativement bien la compilation, et je peux t'assurer que si je parle du bytecode JVM comme d'un "langage machine" aux gens que je connais et qui eux sont experts, ils ne vont pas être d'accord; il me semble que c'est avant tout l'usage qui prime et l'usage, en tout cas chez les spécialistes, est très clair sur ce sujet.)

Je voudrais souligner que, indépendamment de la définition qu'on donne à "tourner dans un navigateur", la remarque de Timaniac (sur le fait que ça différence TypeScript et Dart) est fausse : si l'on considère que ça veut dire "peu se traduire en JS" c'est aussi le cas de Dart (comme l'a fait remarquer Barret Michel), et si on considère comme toi une notion très stricte de "est prévu prévu directement comme type de script dans la norme HTML" ce n'est le cas d'aucun des deux comme tu le fais remarquer.

Je ne trouve pas le bytecode JVM spécialement immonde, c'est un bytecode raisonnable (bien qu'un peu miné par les problématiques de compatibilités) pour représenter du code Java ou ayant la même sémantique qu'un programme Java, et des gens (Scala par exemple) sont arrivés, au prix de beaucoup d'efforts, à lui donner un peu plus de flexibilité.

Par contre je ne suis toujours pas d'accord pour l'appeler un "langage machine"; c'est au mieux un "langage pour machine virtuelle" (ce qui indique bien qu'il s'agit en fait d'une représentation intermédiaire). Je pense que dans le désaccord entre cykl et toi sur "peut-on dire que la compilation vers la JVM relève du même genre de victoire de l'existant au dépend de la pertinence technique absolue que Javascript", il a raison et tu as tort, et que ta contre-argumentation sur la question ("mais non, le bytecode JVM est une forme d'assembleur"), une fois passée la confusion de vocabulaire entre "compiler vers un source Java" ou "compiler vers un bytecode JVM" (il voulait bien entendu dire vers la JVM), est incorrecte.

Mais visiblement nous sommes en désaccord et, au bout du bout, toute la question repose sur le sens qu'on choisit de donner ou pas au terme "langage machine", donc ça n'a pas grand intérêt. Par contre la remarque de cykl (on se force à viser la JVM ou Javascript alors que c'est souvent malcommode) est juste, intéressante et tient toujours, quoi que les amateurs de "java processors" en disent.

(Et pour moi la question de dire que tu as tort sur ce point technique particulier est relativement indépendante de la critique que j'ai formulée avant, sur la façon dont vous avez discuté. Enfin je l'ai pris en compte quand j'ai dis que tes messages n'apportaient pas de contenu technique : on pourrait considérer la distinction "JVM langage machine ou non" comme un point technique, mais comme je pense que tu as tort¹ je ne l'ai pas vraiment pris en compte comme un apport qualitatif à la discussion.)

¹: il y a des débats où on peut tirer des informations très intéressantes de gens avec qui on n'est pas d'accord ou qui pensent des choses partiellement fausses, je ne dis pas que par définition une personne avec qui on est en désaccord n'apporte rien, pour nous, à la conversation; c'est en poussant les deux côtés du débat à avancer des arguments précis qu'on apprend des choses. Mais ici le débat porte sur une question de terminologie, sans vraiment d'argument précis puisque ça reste au final assez subjectif, donc on n'a pas gagné grand chose.

x86 est chiant à implémenter en hardware parce que trop complexe, le problème des CISC ne se pose pas du côté du software (enfin x86 spécifiquement a très peu de registres ce qui casse les pieds pendant la compilation, et il se trouve que la plupart des RISC en ont plus mais c'est une question indépendante). La solution pour les ingénieurs côté hard a été de traduire au vol les instructions x86 vers un microcode RISC bien choisi (qui peut changer selon le modèle du CPU) qui permet de faire des optims au vol; en gros c'est comme ça que x86 est resté un peu compétitif par rapport aux architectures RISC. Mais tout ça ne concerne pas trop l'auteur de compilateur.

Dans le cas de la JVM c'est l'auteur du compilateur (machin -> JVM) qui souffre (enfin les implémenteurs de machine virtuelle aussi mais pour d'autres raisons). Je connais assez mal la JVM mais les exemples que j'ai retenus sont les suivants : pas de support des appels terminaux, un modèle de dispatch très particulier qui convient bien à Java mais pas forcément à tous les langages OOs, tu as intérêt à avoir un modèle d'exceptions qui ressemble à celui de Java, etc. Enfin on a un peu le même genre de problèmes quand on compile vers du C d'ailleurs.

Je ne comprends pas ce que tu essaies de faire en faisant le sophiste sur un point de la définition du mot "assembleur". D'avoir raison ? Quel est l'intérêt ?

Les définitions des mots sont flexibles, mais le but c'est de pouvoir communiquer et faire comprendre des concepts intéressants avec. cykl a écrit un message pour souligner la différence entre la compilation vers du code machine et les méthodes, de plus en plus populaire, consistant à viser un langage de destination pas prévu pour ça à la base (JVM ou Javascript). Dans ce contexte il est important de différencier "langage machine" de "langage pas prévu pour ça à la base", sinon le propos n'a plus de sens et on ne peut plus transmettre d'information.

En quoi le bytecode Java serait-il "directement exécuté par un CPU" ? La question de savoir si un langage est ou non un assembleur est l'existence d'un CPU qui le fait tourner en te faisant croire que c'est son mode de base ? Un CPU qui existe dans le monde réel, ou une expérience de pensée te convient ? Puisqu'il existe des Lisp Machines, Lisp est un assembleur aussi ? Encore une fois, quel est l'intérêt ?

Sans reprendre le ton contestataire du précédent message, l'auteur a raison: on ne peut pas trop considérer le bytecode JVM comme "un assembleur" parce qu'il est trop spécialisé à certains langages de programmation bien particuliers (Java) et pas une bonne cible généraliste pour tous les langages (contrairement aux vrais jeux d'instruction des processeur qui, malgré une légère tendance à favoriser ce qui ressemble à du C (pile d'appel tout ça), sont très polyvalents). L'existence d'immondices technologiques qui interprètent le bytecode directement en hard ne justifie pas trop cet amalgamme, ou alors avec une notion de "code machine" très large qui passe à côté de distinctions importantes (celles que faisait cykl dans son message initial).

Le fait de se forcer à viser la JVM comme langage cible d'une étape de compilation est donc bien un choix pragmatique entre base de support utilisateur et réelle pertinence technique, comme le choix aujourd'hui de viser Javascript. Et dans les deux cas on a des gens qui font pression pour intégrer peu à peu à la plateforme de quoi en faire de meilleures cibles polyvalents.

N'ayant été que très irrégulièrement actif sur LinuxFR, je ne pourrai pas commenter sur l'aspect "c'était mieux avant", mais je suis d'accord sur le fait que le rapport signal/bruit pose problème aujourd'hui, et c'est pour ça que j'essaie d'en parler un peu plus.

Je ne suis pas d'accord. Pour moi on peut cacher une couche inférence si l'interface de communication entre les couches est propre (ce n'est pas une "leaky abstraction"). Par exemple ce qui se passe en interne dans un processeur est extrêmement complexe, personne ou presque ne connaît le microcode qui est réellement exécuté, on ne voit que le jeu d'instruction "haut niveau" qui correspond essentiellement à l'assembleur utilisé, et je ne pense pas qu'on puisse dire que cette isolation est "illusoire" (sauf dans certains cas très, très spécialisés qui ne concernent qu'une poignée de personnes dans le monde).

John Regehr a un billet à ce sujet : It's All About Interfaces.

Oh. Et alors ? Dès le départ je parle de la forme si quelqu'un voulait parler du fond il aurait mieux était avisé de créer un autre fil (c'est l'une des grande force de linuxfr autant s'en servir).

Excuse-moi, ma formulation était fausse. Je voulais dire que peu de choses intéressantes avaient été dits dans l'ensemble des commentaires de ce journal.

La comparaison avec Reddit est foireuse. Le journal n'a que peu de ressemblance avec celui de reddit. Sur ce dernier il parle technique et montre des aspects concrets de typescript (je ne suis pas certains de savoir comment fonctionne ce site), l'histoire nous montre que des journaux (ou dépêches) qui parlent technique ont des commentaires techniques. Au contraire un journal qui s'amuse à lancer des petites piques à droite à gauche (surtout quand ce n'est pas approfondis) génère généralement du troll. Dis autrement « on récolte les commentaires que l'on sème ».

Je ne suis pas du tout d'accord avec cette vision des choses. Pour moi ce type de journal est là avant tout pour amener la discussion sur un sujet donné (ici Typescript). On ne va pas refaire un nouveau journal TypeScript pour dire "ici le journal technique, là-bas c'était le journal pour les trolls". Pour avoir une discussion intéressante il faudrait que les participants se sentent incités à contribuer des commentaires pertinents, intéressants et constructifs sur le sujet du journal.

D'ailleurs je ne vois pas en quoi le journal présent "s'amuse à lancer des petites piques de droite à gauche", au contraire le message de gnumdk est très neutre et en reste aux aspects objectifs sans aucun commentaire sur la politique sous-jacente ou quoi. Le journal est concis et n'entre pas dans les détails techniques mais je comprends ça comme "je lance la discussion avec le minimum, je vous encourage à apporter votre contenu en commentaires".

Du coup je ne sais pas trop quoi penser de ton idée selon laquelle il y a des journaux qui orientent vers de la technique et d'autre qui orientent vers le troll. Quand je parle de technique ce n'est pas pour glorifier les aspects les plus informaticiens ou de recherche, c'est à prendre au sens large (un journal sur le cinéma je m'attends à trouver une discussion intéressante sur le cinéma, donc "poussée, approfondie, constructive, intéressante" serait plus adapté que "technique" pour qualifier la discussion que j'aimerais trouver). Est-ce qu'il y aurait sur LinuxFR des journaux amenant à ce genre de discussion, et d'autres servant de défouloir parce qu'ils "lancent des piques" et donnent donc un signal que c'est le journal où on peut se chamailler un peu dans le vide ? Dans ce cas là peut-on discuter de la proportion entre les journaux "intéressants" et les journaux "défouloir" ? Laquelle est-elle aujourd'hui, et peut-on la faire évoluer ?

Moi mon dada principal c'est l'étude des langages de programmation. Je viens voir les discussions sur les langages de programmation (Coffeescript, Go, TypeScript, Ceylon, whatever) quand elles ont lieu sur LinuxFR, et je suis systématiquement déçu. Peut-être que ces discussions envoient des signaux ambigus aux gens qui, comme tu l'expliques, s'auto-modèrent en fonction du ton qu'ils observent dans le contenu existant, et voient surtout du troll là où il y aurait de la place pour du contenu intéressant.

Je trouve qu'il y a un problème dans votre discussion qui vient en partie de toi. cykl est venu sur ce topic avec une remarque pertinente et intéressante qui voulait dire ce qu'elle voulait dire. Ensuite vous vous êtes chamaillés pour des raisons de forme sans grand intérêt, jusqu'à qu'il répète ce qu'il voulait dire en encore plus détaillé, et tu lui réponds :

Tu vois c'est pas si difficile d'expliciter le fond de sa pensée et c'est la différence entre un troll moisi et une critique constructive.

En plus dans tout le fil ses messages (qui sont ceux qui apportent réellement du contenu, au moins jusqu'à ton "Parlons de fond") sont à des notes négatives et les tiens à des notes élevées, ce qui rend les siens plus difficile à lire et donne une fausse impression que la partie intéressante de la discussion est de ton côté—mais ça tu n'es pas responsable, ce sont les lecteurs de LinuxFR qui notent comme des branques.

Je ne sais pas si on peut dire que ton comportement pose problème : tu es de bonne fois, et si on cherchait à distribuer des blâmes on commencerait par accuser cykl d'avoir réagi de façon agressive. Mais on a un problème quand le contenu intéressant est noyé dans les remarques purement réthoriques, et quand les gens se mettent à penser qu'une argumentation n'est pas valide ou "constructive" tant qu'elle n'est pas explicitée dans le moindre détail. Je suis désolé mais le passage que tu cites comme "explicitant le fond de [sa] pensée" n'apporte pas grand chose par rapport à sa formulation initiale que tu sembles pourtant qualifier de "troll moisi".

Il faut arrêter d'avoir une attitude passive-agressive vis-à-vis des messages d'autrui, c'est aussi à nous, lecteurs et lectrices, de réfléchir à ce qui est dit et faire un effort pour comprendre l'argumentation en profondeur, au lieu de juste répondre des platitudes pour forcer l'intervenant à dérouler son propos et nous éviter tout effort de réflexion. Ta remarque a un ton de "tu vois, j'ai bien fait de chipoter et nous en avons tous profité", mais je pense que c'est une erreur est qu'en réalité cette discussion a été alourdie par des messages moins pertinents que nous aurions pu éviter.

Ce n'est pas une attaque contre toi en particulier et je ne dis pas que ton comportement dans ce fil de discussion est particulièrement désagréable—au contraire, je vois très souvent des façons de discuter bien pire sur LinuxFR. Mais j'utilise cet exemple pour souligner un problème qu'a ce site à mon avis, où les discussions ne peuvent souvent pas se dérouler normalement et de façon intéressante. L'ambiance n'est pas très agréable et ça n'invite pas au contenu technique pertinent.

D'ailleurs très peu de choses intéressantes ont été dites sur ce fil; je vous invite à comparer avec les discussions du même sujet sur Reddit (et encore ce n'est qu'un des fils de discussion, il y a aussi celle-ci par exemple. Alors certes, c'est un forum anglophone donc il y a plus de monde et donc plus de compétences ce qui amène à plus de discussion technique, mais il y aussi des francophones bien informés sur ces sujets, et s'ils évitent de discuter sur LinuxFR à mon avis c'est en partie liée à l'ambiance souvent hostile présente ici.

Merci de brancher ton cerveau la prochaine fois que tu écris un commentaire. Je me fatigue à expliquer les problématiques de sécurité qui entourent le fait de capturer les informations graphiques produites par une application à son insu, et toi tu me matraques avec des conclusions hâtives sur une citation sortie de son contexte. J'ai réfléchi à la question, il y a de vraies problématiques intéressantes qui demandent de la réflexion, j'aimerais que tu fasses un effort pour comprendre ce que je dis avant de tirer dessus au bazooka.

Dire qu'une application sans privilège n'a pas le droit de prendre un screenshot n'a pas, en soit, les effets négatifs des DRMs (ou alors l'interdiction pour les process userspace d'accéder à la mémoire du kernel est aussi un DRM dans ton esprit ?). Dans tous les systèmes de sécurité il y a plusieurs niveaux de privilège et il faut aller vers un niveau plus élevé pour avoir certains droits. Là on est juste en train de dire "la capture du rendu graphique d'une appli étant sensible du point de vue de la sécurité, il faut pouvoir interdire certains niveaux bas de privilèges de le faire". Évidemment ça veut dire qu'on envisage aussi un niveau de privilège plus élevé qui a ces droits; qui est dans ce niveau dépend de la politique de sécurité (ça peut être seulement le processus dont on veut prendre le screenshot, ou alors seulement le window manager (solution mentionnée dans l'article LWN), ou alors toutes les applis à tel niveau de droit, etc.).

Le problème des DRMs n'est pas de faire une distinction entre qui a certain droits et qui ne l'a pas (empêcher le compte SSH anonyme sans droits sur ta machine de lire ta collection de films, ce n'est pas mettre un DRM). Le problème est quand une entreprise grande ou riche ou puissant force l'utilisateur à ne pas avoir accès à ce niveau de droit plus élevé, en le sortant de son contrôle et en le donnant seulement à certains programmes propriétaires fournis par la boîte et sur lesquels il n'a aucun droit.
On peut créer des frameworks de sécurité plus fins sans restreindre les libertés des utilisateurs; c'est les gens qui essaient de te priver du droit, toi administrateur de la machine, d'avoir accès à l'ensemble des niveaux de droits qui restreignent ta liberté. Alors oui, tu pourrais dire qu'avoir le framework de sécurité en place facilite pour les grosses boîtes d'imposer les DRMs (par exemple l'interdiction du clic droit est d'autant plus facile dans un navigateur web qui a les technos prévues pour ça, et on n'est pas trop pressé d'avoir les fonctionnalités de boot sécurisé vu les risques que les vendeurs s'en servent pour bloquer certains OS). Mais il rend aussi la vie plus difficile aux attaquants qui veulent utiliser ces droits à ton insu, ce qui peut aussi avoir des conséquences graves. Je n'utilise pas su ma machine de logiciel propriétaire susceptible d'essayer de m'interdire des captures d'écran d'un contenu protégé; et je ne veux pas que ce cas de figure empêche les développeurs de mon système de me protéger des virus espions siphonant les numéros de carte bleue.

Mais tu cliques sur tout ce qui bouge sans réfléchir pour avoir besoin de ce genre de restriction [..] ?

Je fais tourner du code tiers en lequel je n'ai pas confiance en permanence, oui. J'utilise un navigateur web, des logiciels de lecture/rendu de fichiers multimédias, des utilitaires de compression, un noyau de système d'exploitation, et je suis convaincu que dans tous ces logiciels il existe des failles d'exécution de code qui permettraient à un attaquant disposant d'une faille zero-day de faire tourner le code qu'il veut sur ma machine avec mes droits utilisateurs (puisque chaque mois on trouve et corrige au moins une faille de ce genre dans un logiciel qui tourne sur ma machine).

Ces failles rendent mon système troué d'un point de vue de sécurité. Je suppose qu'il n'est pas infecté par un programme malicieux caché tournant en mode utilisateur, parce que je ne suis pas une cible particulièrement intéressante et que je n'ai pas encore entendu parler d'attaques à grande échelle visant les systèmes que j'utilise, mais c'est plus un hasard des circonstances qu'une sécurité technique. Techniquement, la "trusted code base", la quantité de code auquel je devrais faire confiance pour supposer que personne ne peux exécuter de programmes malicieux avec mes droits utilisateurs (je ne parle pas des droits root de ma machine) est gigantesque. Et la conception même du système fait que, sans une révolution du point de vue de la conception (sandboxing généralisé et ré-architecture des applications pour minimiser les privilèges requis), ça restera le cas dans le futur.

Il y a parfois un compromis à faire entre les "fonctionnalités" et la sécurité. Donner à n'importe quelle application le droit de prendre un screenshot de tout l'écran est aberrant d'un point de vue sécurité, si tu pars du principe que l'utilisateur va exécuter du code tiers dans lequel il n'a pas forcément confiance (sujet de la discussion sur les modèles de sécurité des applications mobiles, par exemple). Imagine par exemple un démon qui est lancé par l'utilisateur plus ou moins à son insu, qui périodiquement prend des captures de l'écran, dans le but de repérer les pages webs correspondant à des paiement en ligne (c'est facile, on cherche les icônes visa / carte bleue) et utilisant de la reconnaissance de caractères pour extraire ton numéro de carte bleue.

Ça s'appelle une "attaque par canaux cachés" : même si tu as sécurisé ton navigateur web en le faisant tourner avec des privilèges différent, en chiffrant les fichiers qu'il stocke en mémoire et en empêchant les programmes non-privilégier de prétendre le débugguer, tu te retrouves à avoir une fuite d'information potentiellement critique parce que n'importe qui peut prendre des screenshot de l'écran. C'est l'équivalent visuel d'un keylogger.

L'important est de trouver un moyen de concilier cette "fonctionnalité" et la sécurité, en la modifiant pour éviter ces fuites d'information indésirables. Par exemple tu peux autoriser les applications à dire "je refuse qu'on me screenshot", et le compositeur va envoyer une image vide à la place qu'elles occupent à l'écran. Ou alors tu peux autoriser chaque application à prendre un screenshot de sa propre zone mémoire, mettre en place un système de tokens de sécurité que les applications peuvent partager (une application screenshot ne verra la zone graphique que des applications dont elle a fourni le token, donc c'est un design général qui subsume les deux précédents), etc… Il y a de nombreux moyens de raffiner cette fonctionnalité pour la sécuriser, mais ça demande de la réflexion et du travail sur les applications; oui, c'est moins simple que le "tout est permis" existant, mais l'existant est une bouse du point de vue sécurité, et c'est quand même quelque chose d'assez critique.

Ce genre de compromis délicats entre fonctionnalités et sécurité est justement le sujet de l'article et des discussions précédentes que j'ai cité-e-s dans mon billet.

Je suis pour ma part qu'on peut concilier sécurité et utilisabilité, et même que la "bonne conception" pour la sécurité coïncide avec la "bonne conception" pour l'interface utilisateur et la sémantique, et qu'on a donc tout à gagner en poussant cet aspect.

Justement les "suscriber links" sont une bonne façon de faire connaître le modèle commercial de LWN et d'inciter des gens à payer un abonnement pour faire vivre les journalistes. Si j'attends une semaine pour faire un journal, moins facile de botter en touche pour dire "… et envisagez de vous abonner", et si j'écris un journal "si vous payez tant vous pourrez lire un article très intéressant" personne ne lira l'article.

Je t'invite à lire la FAQ LWN.net sur les Suscriber Links:

Where is it appropriate to post a subscriber link?

Almost anywhere. Private mail, messages to project mailing lists, and blog entries are all appropriate. As long as people do not use subscriber links as a way to defeat our attempts to gain subscribers, we are happy to see them shared.

Au bout du bout, c'est à chacun de faire ses choix sur la façon dont les Suscriber Links peuvent être utilisés (évidemment ils sont là pour laisser des gens non-abonnés lire les articles payants, donc c'est que la pratique n'est pas uniformément bannie). Je juge que cet usage là est raisonnable. J'ai déjà posté des liens semblables et eu des retours positif de la part de l'équipe LWN.net, qui confirme qu'ils sont là aussi pour ça.

Le lien que tu cites pour critiquer PHP n'est qu'une référence à l'article originel PHP: a fractal of bad design qui est très complet (pourquoi le journal LinuxFR a choisi l'exemple de empty qui est parmi les moins convaincants du document, je l'ignore, tout comme l'intérêt de pointer vers ce journal et pas l'article de départ) et qui montre avec une argumentation très fournie que PHP est un langage horrible.

Ton argumentation c'est "PHP est facile à déployer et utilisé par des gens". Mon commentaire porte sur le fait que, techniquement, le langage de programmation est une bouse. Je suis le premier à reconnaître qu'il est facile à déployer, et je sais que des gens l'utilisent. Justement quand je parle de "souhaiter une belle mort à PHP" c'est que j'espère qu'il va mourir, et que donc les hébergeurs feront des efforts pour rendre des langages moins pourris aussi faciles à déployer (pour un développeur sérieux il est facile aujourd'hui de trouver un hébergement web qui propose de nombreux autres langages; Alwaysdata propose un plan gratuit limité qui propose quand même PHP, Ruby, Python et Perl, MySQL, PostgreSQL, MongoDB et CouchDB), et que les gens qui font du web développeront leurs applications/bibliothèques/frameworks/whatever dans un langage moins pénible à utiliser (car oui parfois aujourd'hui on est forcés de déployer un logiciel PHP, pas à cause des qualités du langage et du plaisir de maintenance qu'on va en retirer, mais parce que les développeurs de CMS ont choisi de l'utiliser car il y quelques années il était le plus populaire sur le web).

Le contre-troll sur Python m'a l'air hors sujet et, bien qu'il a effectivement réussi à dérailler la discussion sur PHP, je ne vois pas trop quel est le rapport avec la question de l'usage du langage pour le web (et par ailleurs je n'ai pas une affection immodérée pour Python; mais au moins c'est un langage que je respecte, contrairement à PHP qui ne mérite que le mépris).