Au risque de sembler condescendant—ce qui n'est réellement pas mon but*—je vais essayer une autre approche.
La discussion semble bloquée parce que nous avons une vision différente. Tu vois le parser json comme une entité théorique, détachée du reste et qui ne devrait obéir qu'aux règles de sa spécification propre indépendemment des conséquences que cela peut avoir. Je vois le parser json comme faisant partie d'un tout et devant donc collaborer avec le reste pour assurer un fonctionnement optimal au système.
Deux exemples de cette dichotomie :
Le boulot d'un parseur json c'est de prendre une chaîne au format json et d'en faire une structure qui permet de se balader dans l'arbre que cette chaîne représentait. Et c'est tout. Et oui, cet arbre devra probablement être entre encodé autrement pour des temps d'accès efficace. Mais c'est pas le problème du parseur.
Si j'étais de mauvaise foi, je dirais que le json est en soi une "structure qui permet de se balader dans l'arbre". Mais surtout, tu mets de côté le fait qu'un parser json n'est jamais utilisé seul. Lorsque tu dis "en faire une structure", c'est donc que c'est le parser qui doit faire un choix de représentation de l'information. Or, ce choix constitue son interface avec le reste du monde. C'est donc le problème du parser que de déterminer et d'appliquer des limites (arbitraires certes) faisant en sorte que cette interface reste utile.
[À propos d'une zip bomb] Oui, un autre très bon exemple, c'est pas le problème de la lib qui dézippe, c'est celui de celui qui l'utilise !
Encore une fois, tu as raison si on observe le décompresseur en vase clos. Après tout, il ne fait que son travail. Pourtant, ton système, lui, sera loin d'avoir un comportement idéal—au contraire, ce sera plutôt une cible idéale. Un décompresseur capable de rejeter les cas totalement hors normes (même si formellement valides) avec une erreur claire sera bien plus utile et correct d'un point de vue global.
Pourquoi est-ce que l'argument que tu dis à propos des temps d'accès ne vaut pas pour l'utilisation de la pile ?
Ça s'applique, justement. Un bon système ne va pas se contenter de supposer qu'il existe dans un monde idéal avec une pile infinie, mais arrêter le massacre à un moment qu'il juge opportun (e.g. trop loin de la "norme" pour être réellement utile).
Pour terminer à propos du JSON : oui, on pourrait écrire des parsers différents. En fait, il semble déjà y en avoir. Mon propos ne réside pas tant dans l'impossibilité de le faire (quoique, soit dit en passant, même ces nouveaux parsers top cool auraient aussi des limites, que d'aucuns pourraient qualifier d'absurdes) mais plutôt dans l'argument général qu'il faudrait toujours pouvoir tout gérer, même les cas à la limite de l'impossible. La simplicité est aussi une belle vertu…
Lorsque je dis qu'un concept n'est pas facile à appréhender, ce n'est pas pour signifier que ceux qui ne le comprennent pas sont des idiots, mais justement pour souligner le fait qu'il est contre-intuitif. Le paradoxe des anniversaires, par exemple, est un concept "pas forcément facile à appréhender". Ça ne signifie pas pour autant que je suis condescendant à l'égard des gens qui ne le saisissent pas de prime abord.
Désolé que tu vois cet échange comme insensé; c'est vrai que ce genre de concept n'est pas forcément facile à appréhender, et qu'il peut être utilisé à mauvais escient pour mal faire les choses (un peu comme le out of spec en ingénierie traditionnelle, où on prend pour excuse que rien n'est garantit en dehors des spécifications pour faire vraiment n'importe quoi alors qu'une simple modification améliorerait beaucoup ce cas de figure).
Ceci étant, la question n'est pas tant de comparer les tailles respectives de la RAM et du fichier incriminé. On peut exploser la RAM tout en étant apparament bien des ordres de grandeur en dessous de sa taille, les zip bombs (ou bombes de décompression ) en étant un bon exemple. Après tout, le fichier original est un ZIP valide, et ne fait que 42 Ko. Quel insensé pourrait oser venir parler de limites physiques? Eh bien celui qui sait que ce fichier, une fois décompressé, fait 4.5 Po (pétaoctets)…
Et là, je ne parle que de la mémoire; discutons un peu du temps d'exécution. En Python (comme dans beaucoup de langages dynamiques), les ensembles pairs/valeurs du JSON sont représentés par des dictionnaires, qui ont un accès O(1) (amorti). Cependant, c'est un accès O(1) à un pointeur sur l'élément voulu. En temps normal, en s'en fiche complètement, une indirection de plus ou de moins, ça ne changera pas grand chose.
Et si c'était maintenant 15 000 indirections? Soudainement le temps d'accès explose…
Est-ce parce qu'on a dépassé les limites de la RAM? Non. Parce qu'on surcharge le processeur de calculs? Pas vraiment. Et pourtant ça ne va pas, tout simplement parce que la supposition de départ ayant mené à la conception des dictionnaires en Python est que les accès sont, en majorité, à plat.
Est-ce qu'on pourrait imaginer une autre structure de données plus adaptée à ce genre de chose? Bien sûr. Est-ce qu'on veut le faire? Certainement pas, et ce n'est ni par paresse, ni par esprit de contradiction. Les choix de design peuvent être discutés, mais peu importe ce que l'on choisit, il y aura des perdants.
J'étais bien content que chromium et firefox étaient suffisamment bien fait pour s'en accommoder
Et pourtant, on a ceci
Du code parfaitement valide qui fait crasher les navigateurs (j'en ai essayé quelques-uns sous les versions les plus récentes de Chromium et Firefox, ça peut prendre quelques secondes mais la plupart des tests crashent effectivement le navigateur ou l'onglet).
À un certain point, comme l'ont bien expliqué d'autres personnes, il faut poser des limites, même arbitraires. Je suis convaincu que GCC (ou n'importe quel compilateur) n'est pas capable de parser certains fichiers C parfaitement valides (mais complètement tordus). Même chose pour un parser XML ou l'interpréteur Python. À ce propos, connaissez-vous l'erreur "s_push: parser stack overflow"? Pourtant cette erreur apparaît sur du code parfaitement valide et limite certains cas d'application réels. C'est dommage, mais c'est une réalité avec laquelle il faut composer : nos grammaires nous permettent de composer des structures infinies, mais le parser possède par définition un nombre fini d'état, c'est donc inéluctable.
Je suis cependant d'accord que ces limites devraient clairement être indiquées dans la documentation.
JSONDecodeError will be raised if the given JSON document is not valid.
Or, le document est valide, lancer cette exception serait donc techniquement ne pas respecter l'interface promise au développeur. Ceci étant dit, oui, la possibilité d'une RecursionError devrait être au moins évoquée dans la doc.
Il reste que dans la plupart des langages interprétés, il y a certaines erreurs qui peuvent presque toujours se produire. En Python, les MemoryError en sont de bons exemples. Même si dans 99.9% des cas, cette erreur n'est lancée que si l'utilisateur fait quelque chose d'incorrect, elle peut techniquement se produire dans n'importe quelle opération.
S'il est critique d'attraper toutes les exceptions, alors le modèle except ExceptionPrecise (pour les cas prévus) suivi de except (tout court), suivi éventuellement de else et finally est probablement le meilleur à adopter. Mais dans tous les cas, ce genre d'exceptions "système" peuvent toujours jouer des tours et je ne pense pas que ce soit le rôle de chaque module de le considérer.
Pour ce genre de cas, il faut considérer deux possibilités :
Ces limitations risquent-elles de faire échouer le décodage d'un code JSON valable?
Dans le cas d'un code non-valable (autrement dit, conçu expressément pour faire échouer le parser), est-ce que cela constitue une faille de sécurité? Cette faille peut principalement prendre deux formes : A) permettre l'accès à une zone non autorisée de la mémoire voire, pire, une exécution de commande à distance ou B) crasher le parser et provoquer à la longue un DDoS.
Personnellement, je réponds à (1) par la négative. Plus de 100 niveaux d'intrication au minimum avant un crash (on parle de près de 1000 pour Python) n'est pas limitatif pour l'extrême majorité des usages.
En ce qui concerne (2), je pense que 2A est fort peu probable (à moins qu'un langage soit assez mal conçu pour laisser aller un débordement de pile sans conséquence). 2B est possible, mais il présuppose que l'attaquant contrôle le JSON parsé, ce qui n'est pas forcément évident.
En ce qui concerne la résolution, une possibilité éventuelle est de réécrire le code sous la forme d'une boucle et d'une pile explicite. Au lieu d'appeler récursivement une nouvelle fonction à chaque ouverture de liste ou de dictionnaire rencontrée, on ajoute le symbole d'ouverture sur la pile. Lorsque l'on rencontre un symbole de fermeture, on dépile et on s'assure que le précédent symbole d'ouverture correspond bien (sinon c'est une erreur de syntaxe). À la fin du décodage, la pile devrait être vide (sinon c'est toujours une erreur). La taille de cette pile peut être dynamiquement agrandie au fil de l'exécution.
Le code résultant est moins joli et plus difficilement extensible cependant. Je pense que la plupart des implémentations ont cependant fait le choix de la clarté. L'important est que l'erreur éventuelle soit claire. Par exemple, dans le cas de Python (je n'ai pas testé les autres), une exception est levée :
RecursionError: maximum recursion depth exceeded while decoding a JSON array from a unicode string
Ce qui est très clair, facilement attrapable si besoin est par le programmeur d'une section critique d'une application et ne cause aucun effet de bord indésirable.
Je ne sais pas si c'est la même chose pour tous les parsers, mais de manière générale je ne m'inquièterais pas trop de ce problème.
Bah tout dépend de ta définition de libre. Au final, à certains égards, cela se ramène à la sempiternelle question : est-on libre si on peut renoncer à cette liberté? Pour certains, interdire cette option est une forme de restriction, alors que pour d'autres, ce n'en est pas une puisque de toute façon tu t'apprétais à renoncer à bien plus.
Les licences sont copyleft te permettent de faire n'importe quoi tant que tu ne restreins pas la liberté des autres. Est-ce pour autant "moins libre" qu'une licence te permettant d'enfermer tes propres utilisateurs? À toi de juger…
Je ne suis pas certain de comprendre. Si je crée un logiciel sous GPL et qu'un individu le redistribue sans incorporer les sources, oui je peux le poursuivre et l'envoyer devant un tribunal. Est-ce que je le ferai? Peut-être pas, parce que les coûts associés à la poursuite sont trop élevés par rapport à ceux du préjudice que je subis, mais je peux tout autant le faire que pour une multinationale…
Par ailleurs, les textes de licence spécifient explicitement les libertés (permissions si tu préfères) accordées à l'utilisateur. Par exemple, dans la BSD :
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met […]
L'utilisateur a le choix de la prendre ou non (par exemple, en tant qu'utilisateur de logiciel sous GPL, je peux décider de ne pas me prévaloir de mon droit à obtenir le code source), mais c'est bel et bien la licence qui accorde ou non certaines libertés.
Dans le cas d'un clone intégral sans modifications, ça peut passer, mais que se passe-t-il si l'individu modifie le logiciel? À qui faut-il payer la licence? Est-ce que la licence est virale comme la GPL et que—par exemple—si le logiciel ne contient plus que 5% du code original sous "licence zero", il faut quand même payer l'entièreté des droits à l'auteur original?
Ça me paraît très difficile à mettre en oeuvre parce que 1) il faut suivre tous les clones et utilisations dérivées de ton logiciel et 2) parce que la limite d'utilisation n'est pas définissable en pratique.
L'article de la revue de presse de l'April lié au début du billet décrit justement plus les faits. Dans mon journal (que je suis tout à fait prêt à qualifier de bookmark, je ne prétends pas avoir procédé à une analyse quelconque), je trouvais intéressant de discuter de la réaction d'une des parties directement (ou quasi directement) impliquée.
Pour ta seconde critique, il est tout à fait commun de discuter d'une résolution ou d'un projet de loi avant qu'il ne soit officiellement déposé. Oui, techniquement, la ville de Munich peut encore changer l'entièreté de la résolution (je ne sais pas comment ils appellent ça en Allemagne) et décider de n'utiliser que OS/2 et WordPerfect. En pratique, scoop : ça n'arrivera pas.
Je comprends qu'il ne soit pas nécessairement approprié de discuter de chaque microscopique détail, mais sur le plan d'ensemble je ne vois pas pourquoi il faudrait attendre la décision "officielle" alors que la position qui sera défendue est déjà connue hors de tout doute raisonnable.
Comme je l'ai dit, je ne présume pas de ce qui se passe en Europe (je ne connais honnêtement pas du tout), mais j'ai donné un exemple réel et parlant de l'utilité des appels d'offre dans une situation similaire. Au Québec toujours, on pourrait parler de la commission Charbonneau, qui a utilisé les résultats d'appels d'offres pour démontrer une collusion entre les entreprises de pavage et de construction.
Est-ce que ça fonctionne toujours? Non. Y a-t-il moyen de contourner le système? Probablement. Est-ce que ça complique la vie aux fraudeurs et collusioneurs et facilite une éventuelle action en justice subséquente? J'en suis persuadé.
Le simple fait que ça force les tractations à se faire au grand jour est déjà un énorme avantage, à mon avis… Par ailleurs, des lois imposent des limites sur ce qui peut être exigé dans un appel d'offre. Je ne connais pas la situation en Europe, mais ici au Québec, FACIL et Savoir-Faire Linux ont pu contester avec succès des appels d'offre bidons.
Le rapport complet (450 pages tout de même) a été publié et est accessible à tous. Le billet de la Document Foundation le mentionnait, mais je n'ai pas trouvé pertinent de l'inclure ici puisqu'il est logiquement en allemand, que ma maîtrise de cette langue est en déça du parcelaire et que les outils de traduction automatiques donnaient des résultats franchement épouvantables. Ceci étant dit, si ça intéresse un germanophone, voici maintenant le lien : https://www.ris-muenchen.de/RII/RII/DOK/SITZUNGSVORLAGE/4277724.pdf
Sinon, la discussion a lieu aujourd'hui (le 15 février) donc pour le moment, les arguments détaillés de la ville ne sont pas connus—on a seulement une idée générale, à partir de ce qui a filtré dans les médias et des déclarations générales des politiciens.
Zenitram expliquait qu'il n'y avait pas que le prix de la licence à étudier et que le coût de formation et de transfert de l'existant pouvait dépasser celui des licences, par exemple. Ça peut venir de l'absence de support commercial, des employés qui râlent,… Il y a pleins d'argument possible qu'un puéril « de toute façon vous êtes fan de MS ! »
Bien sûr qu'il y a plein d'arguments, mais en l'occurrence un rapport a été produit (et pas par une association de libristes) et dit le contraire. Donc, à moins que la DocFo ait tout simplement travesti le résumé qu'ils font de ce rapport pour prétendre le contraire de ce qu'il dit—ce qui serait inacceptable, mais aussi peu probable—on peut considérer que, comme je l'ai expliqué dans mon billet, ces questions ont déjà été posées et que leurs réponses sont satisfaisantes pour le L.L.
Il est objectivement moins cher de n'avoir qu'un seul OS sur sa ligne de montage. Je précise simplement que ça n'a rien à voir avec Windows, cet OS pourrait aussi bien être Linux.
Par ailleurs, je suis dubitatif quant à l'importance relative de ce coût pour un fabricant. Les grosses marques produisent déjà des dizaines de déclinaisons d'un seul modèle (on peut regarder dans la page Dell que je lie plus haut, plus de 16 variantes d'un même modèle…), je ne suis pas convaincu qu'entre toutes ces variantes les coût supplémentaire pour offrir Linux soit important.
En ce qui concerne le coût de la licence de Windows XP, je n'adhère pas à tes conclusions: le fait que Microsoft ait été forcé de vendre XP à rabais sur les netbooks pour contrer Linux tend à montrer qu'il y a bien un avantage côté Linux, au moins sur cette gamme d'ordinateurs à très bas prix.
Dans tous les cas, je ne prétends pas que Linux réduise nettement le prix d'un ordinateur : je n'ai tout simplement aucun chiffre pour appuyer mes arguments. Ce que je dis, c'est que de prétendre à l'inverse que Windows rapporte forcément plus aux fabricants qu'il ne leur coûte est tout aussi peu appuyé par des arguments et que de se gausser de la naïveté de ses interlocuteurs qui ne "veulent même pas payer plus cher pour suivre leurs convictions" (ce qui est par ailleurs faux dans bien des cas) me semble quelque peu sophistique…
Un jour (car on vous la déjà expliqué) vous arriverez à vous mettre dans le crâne que la "licence Windows" permet de mettre plein d'autres logiciels (développés que pour Windows faut de marché correct ailleurs) avec un paiement de la part des développeurs pour que ce soit installé, et aussi qu'une seule chaine pour l'OS est moins cher, et que du coup si te fournir un Windows à toi l'emmerdeur qui veut autre chose mais est un peu seul est moins cher.
Un jour (lorsque tu seras descendu de tes grands chevaux), j'aimerais sincèrement voir une analyse démontrant que la licence Windows diminue les coûts par rapport à un portable nu. Le calcul est le suivant :
Coût du portable = coût matériel + coût de la licence - revenu des bidules installés par défaut
Je ne nie pas que les logiciels par défaut réduisent (légèrement) le prix du portable, mais je doute très fortement que cela puisse compenser le coût de la licence—soit dit en passant, je n'ai pas changé de position, c'est ce que je soutiens depuis le début.
et aussi qu'une seule chaine pour l'OS est moins cher
Ce qui n'a rien à voir avec Windows.
Je parie que les autocollants sont dans la négo et permettent d'alléger le prix
Permets moi de parier le contraire. Ils font tout simplement partie du programme de certification, tout comme par exemple l'UEFI avec les clés de Microsoft installées, ou l'autocollant de la licence OEM visiblement apposé sous le portable. Quelques gros fabricants peuvent probablement se négocier des particularités, par exemple certains portables où la licence est "cachée" sous une trappe, mais je doute fortement que Microsoft, qui a le gros bout du bâton dans cette histoire, ait un intérêt à consentir à quoi que ce soit financièrement…
vous ne voulez pas mettre plus d'argent pour avoir un Linux (sans bloat, sans autocollant, avec du taf en plus pas vraiment divisable par tête vu que pas foule veut ça, donc forcément plus cher même si la licence est gratos, gratos est trop cher)
Encore une fois, tout cela se base sur ta prémisse qu'un portable avec Windows est forcément moins cher parce que les revenus annexes couvrent plus que le coût de la licence. Je demande à voir des chiffres appuyant cela. Parce que quand je regarde les prix des gros OEM, ce n'est pas ce que je vois. Tiens, par exemple, chez Dell et son XPS 13 proposé avec Windows 10 ou Ubuntu 16.04 : le modèle avec Ubuntu et un i7 coûte 50 euros de moins à caractéristiques équivalentes et ce sans solde de part et d'autre. Un portable Windows du même prix possède un SSD 2 fois plus petit (128 GB vs 256). Sur le modèle tactile, c'est 30 euros de plus pour Ubuntu, et sur le modèle haut de gamme (16 Go de RAM), 50 euros de moins pour Ubuntu. Pas facile de conclure à un avantage pour Windows…
Alors je vais conclure comme toi : arrête tes gamineries. Autant dans certains débats tu amènes des statistiques et des points de vue fort bien documentés, autant dans ce genre de discussion on dirait que tu veux désespérément que Windows ait l'avantage pour pouvoir traiter tes interlocuteurs de gamins qui n'ont rien dans le crâne…
En effet, mais ce n'est donc pas lié à Windows et, par transposition, à son autocollant… Adobe pourrait très bien payer les constructeurs pour mettre son lecteur sur Linux—en fait, on n'a qu'à penser au cas d'Amazon et Ubuntu pour voir que ça c'est déjà fait.
Les softs désagréables, ça se désinstalle, et virer carrément la partition Windows pour y mettre Linux est un remède efficace. Mais l'autocollant reste.
Sinon, ces autocollants de merde, ben ils ont fait chuter le prix de ta machine un poil.
Je suis quand même dubitatif : sauf erreur de ma part, la licence Windows (qui vient avec l'autocollant, eh…) ne fait pas chuter le prix de la machine, loin de là… Bon, clairement, le prix d'une licence OEM en volume n'a rien à voir avec le prix d'une version boîte, mais je ne pense pas que ce soit compensé par une rentrée d'argent due à l'autocollant…
Pourquoi de nouveau omettre que ce code n'aurait jamais du être committé dans la mainline
Je me cite :
J'ai laissé le "par erreur" pour noter que dès le départ, ce n'était pas la situation voulu par les devs.
Si je voulais omettre cela, j'ai une bien drôle de façon de le faire…
Ceci étant dit, ce n'était pas mon propos. Pourquoi ce code "n'aurait jamais dû" se retrouver là? Il entraînait une régression ou contenait des bugs? Non. Il rendait plus difficile la maintenance du reste du code? Non. D'autres devs/mainteneurs s'y étaient opposés et l'auteur original avait passé outre? Non. Ce code s'est retrouvé dans la mainline, et a été retiré pour des questions idéologiques.
le mainteneur de emacs-mac est la même personne qui a enlevé le code
Oui, et? Qu'est-ce que ça change pour un utilisateur? D'autres ont commenté que c'était décourageant pour l'auteur du patch original, ce qui est effectivement faux dans ce cas-ci, mais ce n'était aucunement mon propos à la base.
En fait, cette affirmation est intéressante sur un aspect : loin d'être une décision de "l'intelligentsia" allant à l'encontre de la volonté des devs, c'est "la personne qui fait" qui a elle-même reverté son patch… Autant pour le complot des élites déconnectées du monde des programmeurs…
Ce qui implique que le support existe encore pour tous ceux qui le veulent, juste pas dans la mainline.
Oui, et c'est précisément ce que j'ai expliqué dans la dernière phrase de mon journal.
Quelqu'un sous mac utilise vraiment la mainline, alors qu'il y a des ports bien plus adéquats (pas rien que pour 3 emoji) ?
Aucun lien avec le propos du journal. Mon but n'était pas d'offrir un guide d'utilisation de Emacs sous macOS.
Que tu le vois pas est une chose. Que cela fut le cas en est une autre, surtout avec les 2 points cité précédemment.
Si les gens ne sont pas capables de comprendre le sens de "introduite par erreur" (en italique dans le texte), je ne peux pas y faire grand chose. Pour le mainteneur, c'est une information intéressante en effet, qui aurait pu se retrouver dans le journal, mais je ne le savais tout simplement pas (le changelog ne le mentionnait pas).
La prochaine fois n'était pas maintenant.
Puisque ne pas inclure un […] dans une traduction alors que la citation originale est présente 2 lignes plus haut te semble un manquement suffisament grave pour mériter une réponse aussi acerbe, je t'invite à inutiler mon journal scandaleux qui induit en erreur la populace.
Je ne voulais plus vraiment intervenir (après 180 commentaires, il n'y a plus grand chose à dire), mais je pense qu'il est important de préciser quelque chose.
oui, la partie non traduite du journal et omise dans l'article cité. « […] was accidentally added when Emacs 24.4 included the new Core Text based font backend code that was originally implemented for a non-mainline port », oulala, ils ont commité dans la mauvaise branche, omagad, cela mérite évidement les foudres du monde entier (et surtout de linuxfr) !
Pas un seul a vérifié/recroisé ou noté la non traduction d'une partie, …
Lorsque j'ai traduit la citation (que j'ai par ailleurs laissée dans sa version originale, littéralement 2 lignes au-dessus), j'ai simplement passé outre l'explication parce que je ne voyais pas en quoi ça avait un lien avec le débat. J'ai laissé le "par erreur" pour noter que dès le départ, ce n'était pas la situation voulu par les devs. La situation est :
1. Il y avait un support pour les emojis colorés sous MacOS
2. Ce support a été retiré
Peu importe comment 1) s'est produit (commit erroné, le chat du dev a implémenté la fonctionnalité en marchant sur son clavier, Stallman a une double personnalité où il est un adorateur d'Apple), il reste qu'une fonctionnalité introduite plusieurs mois auparavant et fonctionnelle a été retirée sans justification technique (uniquement politique).
Je l'ai dit dans mon journal, je suis d'accord avec cette justification politique. N'empêche que je ne vois pas en quoi la non-traduction d'une partie du changelog pourrait modifier la perception qu'on les détracteurs ou les partisans de cette décision.
J'imagine qu'il y a effectivement des dévôts de RMS, mais il y a une différence entre être intégriste et réagir à ça :
Le libre doit autant à Stallman que le progrès social à Staline: quelques bonnes idées au début et un tas de désastres ensuite.
Pour l'avoir rencontré en personne, ma perception de RMS est qu'il s'agit de quelqu'un de foncièrement désagréable, grossier même. Mais je suis capable d'apprécier néanmoins sa contribution, qui ne se résume pas à "quelques bonnes idées au début". On pourrait dire la même chose d'Ulrich Drepper : c'est une personne parfaitement incapable de dialoguer de manière constructive et d'une grossièreté absolument risible. N'empêche que je le défendrai si quelqu'un soutient qu'il est un piètre programmeur, parce que c'est simplement faux.
Stallman (ainsi que "l'autre icône à 3 lettres") ont des idées libertariennes bien arrêtées, que je ne partage absolument pas.
ici on a la même chose RMS dit que la pédophilie peut être acceptée du coup la pédophilie est acceptable pour certains, du moins ça ne leur pose aucun problème du tout de soutenir un tel personnage)
Si je soutiens quelqu'un, j'approuve automatiquement tout ce qu'il a dit et fait depuis sa naissance? Ça va être difficile… Pour le coup, personne n'a dit que la pédophilie était acceptable, simplement qu'il fallait la replacer dans le contexte du consentement et du principe selon lequel un enfant (la définition d'enfant variant pour chaque pays) ne peut consentir.
Dans tous les cas, si RMS constitue une figure indubitable du logiciel libre, il ne compose pas l'entièreté de la FSF, encore moins du monde du LL.
C'est curieux. Toi qui reproche toujours à la moitié de la planète libre de manquer de cohérence, qui explique la perte de vitesse de Firefox par le fait que Mozilla a déchiré ses principes en incluant un tracker sur sa page d'accueil et en incluant Pocket, un module propriétaire, à Firefox, j'aurais cru que cette position de la FSF te plairait.
Ils l'affirment haut et fort : leur objectif, c'est la liberté de l'utilisateur. Si une fonctionnalité d'un OS non libre fait de l'ombre à tous les OS libres, alors l'utiliser est contraire à cet objectif, puisque cela peut encourager une migration vers cet OS non libre.
Il ne dit pas "les OS libres sont moins bien"—ce qui n'a pas vraiment de sens d'ailleurs, comment décides-tu qu'une fonctionnalité parmi des millions fait qu'un OS est meilleur qu'un autre? Il dit "les programmes GNU, et particulièrement Emacs, ne doivent pas dépendre de fonctionnalités existant uniquement sur des OS non libres, au risque d'encourager leur utilisation".
En tant que libriste, je trouve que refuser un patch sous excuse bidon dogmatique est une insulte à ceux qui disent tout le temps "contribue! Et quand tu as fini, c'est mieux si tu files upstream". Et après on s'étonne que les gens ne veuillent pas "perdre leur temps" à préparer un patch upstream?
Encore une fois, non, je ne suis pas d'avis que c'est une excuse "bidon", mais au contraire réfléchie. Tu peux ne pas être d'accord (tout comme on peut être fâché qu'Intel ait refusé d'inclure le patch de support pour Mir en upstream), mais ce n'est pas un acte isolé pris sous le coup de l'émotion, ça fait partie d'une position défendue par la FSF de longue date.
Pour se suffire à lui-même, on ne compte pas sur la FSF ou RMS, mais sur Linux, Apache, Mozilla, VideoLAN…
Oui, tous des logiciels libres, comme je l'ai écrit. Et c'est GNU/Linux par ailleurs ;-)
L'intégrisme, quelque soit sa base, est source de bordel pour cacher une volonté de ne pas avoir envie de vivre avec les autres, et ne fait pas vraiment avancer (au contraire, ça donne une mauvaise réputation au mouvement).
Ne pas défendre ce que l'on juge et clame être le plus important, aller à l'encontre de ses idéaux, ça aussi ça donne mauvaise réputation au mouvement (et tu en profites largement lorsque l'on discute d'autres projets libres, d'ailleurs). RMS ne refuse pas de vivre avec "les autres" : il refuse de vivre avec du logiciel propriétaire.
de ce que la FSF espère comme résultat. Bien que directeur du W3C, cet organisme reste un consortium et Berners-Lee n'a tout simplement pas le pouvoir de s'opposer à une décision d'un comité prise en conformité avec les statuts et règles en vigueur.
Oui, bien sûr, d'un point de vue relations publiques, ne pas avoir le créateur du web de son côté, ce n'est pas génial, mais fort surmontable, compte tenu que les personnes chez qui cette situation créerait un sentiment de malaise sont les mêmes que celles qui sont déjà fortement opposées à Microsoft, Apple et les autres qui veulent imposer des DRMs.
Et même à la limite, si Berners-Lee mettait son poing sur la table et refusait le passage en W3C Recommendation de l'EME (en supposant que ce soit possible, ce dont, encore une fois, je doute) : le pouvoir ne résiste pas dans les spécifications, mais dans les implémentations. Avec plus de 80% de parts de marchés, si Microsoft, Apple et Google s'entendent sur une mise en oeuvre entre eux, alors ce sera ça qui deviendra un standard de facto, que le W3C le veuille ou non! Apparté : on se demandait dans un précédent journal à quoi pouvait bien servir Firefox maintenant que d'autres navigateurs libres existent; eh bien, précisément à ça.
Ceci étant, sur le site de la pétition, la FSF parle beaucoup plus du W3C que de TBL, ce qui me semble une bonne chose.
genre refuser des patchs sur MNG je crois juste parce que "trop lourd de quelqeus Ko, on a choisi l'autre"
Je n'ai pas vu cette histoire, mais en quoi est-ce une décision du "méchant management" plutôt qu'une décision technique? Peut-être que dans certains contextes, quelques Ko font une différence importante et que "l'autre" offre mieux?
genre refuser d'activer H264 même si l'Os le supporte
Que disais-tu de Mozilla? Ah oui, qu'ils n'étaient pas capables de suivre leurs principes, par exemple de refuser d'intégrer un codec propriétaire. Évidemment que dans ce cas-ci le point en litige n'était pas technique, mais politique…
mais bon 6 mois plus tard on cède on a juste gagné 6 mois de drame
Après que les mêmes qui reprochent à Mozilla l'intégration de Pocket comme service non-libre et la qualifie de trahison des utilisateurs aient déchiré leur chemise pour que Mozilla intègre un codec non-libre…
En pratique, c'est plus les gens "en haut lieu". Ce n'est pas les utilisateurs (ni les employés) qui on nommé Eich et sa casserole, hein… Pas mal étaient contre.
Oui, et pas mal étaient pour. Après tout, on pouvait raisonnablement supposer que le créateur du Javascript et un contributeur important du projet avait une certaine légitimité comme chef de projet… Je ne conteste pas son renvoi/démission, mais c'est loin d'être un cas où le "méchant management" a pris une décision sans queue ni tête…
Bam. Merci pour la démo. Quoi? Ben… Tous tes exemples, je en peux absolument pas le vendre à des utilisateurs! Trop technique. La force de Firefox, c'était une interface, un truc visible. Le problème est justement d'inventer un n-ième langage plutôt que de réfléchir à ce qui fait l'importance d'un navigateur, c'est à dire son interface utilisateur. L'interface actuelle a déjà trop de fois la critique qu'elle est suiveuse de l'interface de Chrome.
Bon, en fait, tu t'en fiches des "principes" de Mozilla… Ou plutôt, tu ne t'en sers que lorsque ça t'arrange : si tu peux critiquer Mozilla en disant qu'ils trahissent leurs utilisateurs de la première heure, c'est bon. Mais admettre que tous ces projets que "tu ne peux pas vendre à des utilisateurs" ont changé la façon dont ces utilisateurs perçoivent et utilisent le web, ça, non, ça n'est pas assez important pour que tu admettes que l'influence de Mozilla a suivi, au moins sur ces cas là, ses principes fondateurs. Non, c'est plus important d'avoir une jolie interface graphique.
Tiens, un autre exemple :
La dessus, je te suis, je suis le premier à fustiger les gens hurlant aux DRM dans Firefox, justement pour cette raison.
Ah bon là le fait que ce ne soit pas libre et diamétralement opposé au Mozilla Manifesto n'a pas d'importance. Fichus mozilliens qui freinent le progrès et "l'expérience utilisateur".
Après, en ce qui concerne tous les arguments de "défense du passé" et de "retour aux sources" : ne t'étonne pas de voir des attitudes défensives en réponse à tes commentaires. Contrairement à ce que tu sembles suggérer, le problème n'est pas que les gens jouent à l'autruche en psalmoldiant le Book of Mozilla, mais que tu soutiens des causes complètement fantasques pour expliquer des faits qui, eux, sont indéniables (le déclin de Firefox).
Oui, Mozilla doit se réinventer et non, je ne suis pas certain qu'ils vont y arriver, mais ce n'est pas parce qu'ils ont changé : c'est parce que le reste de l'écosystème a changé!
Super réponse si on oublie que même sur son principal "marché" (un navigateur web), Firefox meure doucement mais sûrement.
Il perd des parts de marchés, c'est indéniable. Mourir? Ça reste à voir. Firefox s'est bâti sur un idéal, et ça, ça ne meure pas. Il est possible que la MoFo finisse par disparaître (tout comme Netscape Corp. a disparu), mais ce n'est pas une fin en soi.
Il est vrai que Firefox a perdu beaucoup de ses avantages : se comparer à un navigateur sans aucune évolution durant des années (IE6) et un navigateur au développement très rapide et activement soutenu par une entreprise qui a tout avantage à contrôler ce qui se fait dans ce marché (Chrome), ce n'est pas la même paire de manches. Il y a deux choses à dire à ce sujet, cependant :
Si nous en sommes là, c'est parce que Mozilla a, au moins sur un point, gagné : la stagnation insupportable que Microsoft faisait subir au web a pris fin grâce à Firefox. Même si ce n'est pas Mozilla qui a tout fait, évidemment, on ne peut dénier leur apport à l'évolution du web et de ses standards.
Il y a une différence entre ne pas être la référence et ne pas être une référence. Je ne connais aucun développeur web qui ne prenne le temps de tester avec Firefox, et toutes les librairies javascript sont compatibles avec lui.
les "têtes de pont de la première heure" de Mozilla se sont barrées (c'est dire comme ça doit craindre en interne)
Oh non, Steve Ballmer et Bill Gates ont quitté Microsoft! C'est dire comme ça doit craindre en interne si ces "têtes de point de la première heure" s'en vont!
il faut accepter que le projet qui a tant fait rêver ne fait plus rêver
Effectivement, on n'a plus à rêver d'avoir un navigateur sécuritaire, évolutif et rapide : on l'a, et on a même le choix!
non, un moteur différent ne différencie pas, on s'en fout complet tant qu'il y a un autre moteur libre utilisable et plus performant
Faux, complètement faux. C'est orthogonal au libre. On veut plusieurs moteurs de rendu pour éviter que les développeurs "n'optimisent" leur code pour un moteur en particulier. En fait, à un certain point, la présence de Firefox est probablement bénéfique à Webkit/Blink : faire évoluer ce moteur serait probablement bien plus ardu s'il fallait tenir compte de tous les quirks que les gens exploiteraient s'il n'y avait que lui.
Mozilla s'est tellement fourvoyé dessus en forçant par exemple Pocket pas libre, en disant fuck à DoNotTrack et autres violation de leur idées d'origine qu'ils ont bien bousillé leur image de marque
"ben c'est quoi la différence avec Google?"
Je l'ai déjà expliqué en long et en large dans une précédente discussion : il est absurde de dire que des supporters de Mozilla, ceux qui sont là pour la protection de leur vie privée et la philosophie libre, s'en détournent au profit de Chrome, un navigateur soutenu par une multinationale dont le but est explicitement de récolter le plus de données possible sur tout le monde, simplement parce que Mozilla a sorti une extension Pocket non libre et a osé utiliser un tracker sur leur page d'accueil…
ça précise direct que tu vas plus vouloir troller que répondre.
Si je résume l'argumentaire présenté dans le journal : il y a sur le web d'autres problèmes que l'accès à un navigateur décent, donc Mozilla fait forcément fausse route en continuant à développer et améliorer son navigateur (et c'est parce qu'ils ne pensent qu'à la tune maintenant).
Mozilla n'a jamais été impliqué de manière importante dans le cloud computing. Ce que ce journal fait, c'est un peu comme reprocher à une Médecins sans frontières de faire fausse route parce que "en 2017, l'enjeu c'est l'accès à Internet pour tous". Même si la seconde proposition peut être vraie jusqu'à un certain point, en quoi cela remet-il en question le travail de MSF?
C'est la même chose avec Mozilla. Bien sûr qu'ils pourraient se diversifier (quoique ils se feraient alors critiquer sous prétexte qu'ils "s'éparpillent" et qu'ils devraient se "concentrer" sur leur mission première, comme ce fut le cas lors de la sortie de FirefoxOS), mais le fait qu'ils ne le fassent pas n'est pas une preuve de leur insignifiance.
Par ailleurs, les navigateurs web sont littéralement la colonne vertébrale du cloud. "Un moteur de rendu efficace et un moteur JS tout aussi efficace", c'est très loin d'être simple de nos jours. On demande aux interpréteurs javascript d'être quasiment aussi rapides que du code natif et aux moteurs de rendu de supporter un nombre sans cesse croissant de standards changeant très rapidement, sans pour autant exposer l'utilisateur à des failles de sécurité ou vider la batterie d'un dispositif mobile en cinq minutes. Qupzilla et consort ne peuvent exister que parce qu'ils utilisent justement des moteurs déjà développés par d'autres, et même Opera a renoncé à son moteur maison, historiquement à la fine pointe, pourtant.
Les gens de Mozilla ont proposé une myriade de projets au fil des ans : asm.js, Rust, Let's Encrypt, Persona, encodeur JPEG plus efficace, pdf.js, Hello, et j'en passe. C'est vrai, la plupart de ces projets ne touchent pas directement l'internaute, mais ont néanmoins eu un impact plus qu'appréciable sur la protection de la vie privée, la sécurité ou l'efficacité de nos navigateurs. Mettre tout ça de côté et minimiser l'importance capitale d'un navigateur libre et ouvert en prétextant à répétition que "Mozilla ne pense plus qu'à l'argent" en guise d'argument, c'est quelque peu spécieux…
En fait, c'est encore mieux : np.zeros est un cas à part. Il "initialise" la mémoire à zéro, mais le kernel garde toujours un page remplie de zéros sur laquelle il peut faire du copy-on-write. Si bien que tu peux sans problème appeler np.zeros, sans overhead particulier par rapport à np.empty (sur Linux du moins).
On ne peut pas en dire autant de np.ones par contre…
[^] # Re: Intérêt ?
Posté par Kalenx . En réponse au journal Tous les parsers JSON sont mauvais. Évalué à 8.
Au risque de sembler condescendant—ce qui n'est réellement pas mon but*—je vais essayer une autre approche.
La discussion semble bloquée parce que nous avons une vision différente. Tu vois le parser json comme une entité théorique, détachée du reste et qui ne devrait obéir qu'aux règles de sa spécification propre indépendemment des conséquences que cela peut avoir. Je vois le parser json comme faisant partie d'un tout et devant donc collaborer avec le reste pour assurer un fonctionnement optimal au système.
Deux exemples de cette dichotomie :
Si j'étais de mauvaise foi, je dirais que le json est en soi une "structure qui permet de se balader dans l'arbre". Mais surtout, tu mets de côté le fait qu'un parser json n'est jamais utilisé seul. Lorsque tu dis "en faire une structure", c'est donc que c'est le parser qui doit faire un choix de représentation de l'information. Or, ce choix constitue son interface avec le reste du monde. C'est donc le problème du parser que de déterminer et d'appliquer des limites (arbitraires certes) faisant en sorte que cette interface reste utile.
Encore une fois, tu as raison si on observe le décompresseur en vase clos. Après tout, il ne fait que son travail. Pourtant, ton système, lui, sera loin d'avoir un comportement idéal—au contraire, ce sera plutôt une cible idéale. Un décompresseur capable de rejeter les cas totalement hors normes (même si formellement valides) avec une erreur claire sera bien plus utile et correct d'un point de vue global.
Ça s'applique, justement. Un bon système ne va pas se contenter de supposer qu'il existe dans un monde idéal avec une pile infinie, mais arrêter le massacre à un moment qu'il juge opportun (e.g. trop loin de la "norme" pour être réellement utile).
Pour terminer à propos du JSON : oui, on pourrait écrire des parsers différents. En fait, il semble déjà y en avoir. Mon propos ne réside pas tant dans l'impossibilité de le faire (quoique, soit dit en passant, même ces nouveaux parsers top cool auraient aussi des limites, que d'aucuns pourraient qualifier d'absurdes) mais plutôt dans l'argument général qu'il faudrait toujours pouvoir tout gérer, même les cas à la limite de l'impossible. La simplicité est aussi une belle vertu…
[^] # Re: Intérêt ?
Posté par Kalenx . En réponse au journal Tous les parsers JSON sont mauvais. Évalué à 10.
Désolé que tu vois cet échange comme insensé; c'est vrai que ce genre de concept n'est pas forcément facile à appréhender, et qu'il peut être utilisé à mauvais escient pour mal faire les choses (un peu comme le out of spec en ingénierie traditionnelle, où on prend pour excuse que rien n'est garantit en dehors des spécifications pour faire vraiment n'importe quoi alors qu'une simple modification améliorerait beaucoup ce cas de figure).
Ceci étant, la question n'est pas tant de comparer les tailles respectives de la RAM et du fichier incriminé. On peut exploser la RAM tout en étant apparament bien des ordres de grandeur en dessous de sa taille, les zip bombs (ou bombes de décompression ) en étant un bon exemple. Après tout, le fichier original est un ZIP valide, et ne fait que 42 Ko. Quel insensé pourrait oser venir parler de limites physiques? Eh bien celui qui sait que ce fichier, une fois décompressé, fait 4.5 Po (pétaoctets)…
Et là, je ne parle que de la mémoire; discutons un peu du temps d'exécution. En Python (comme dans beaucoup de langages dynamiques), les ensembles pairs/valeurs du JSON sont représentés par des dictionnaires, qui ont un accès O(1) (amorti). Cependant, c'est un accès O(1) à un pointeur sur l'élément voulu. En temps normal, en s'en fiche complètement, une indirection de plus ou de moins, ça ne changera pas grand chose.
Et si c'était maintenant 15 000 indirections? Soudainement le temps d'accès explose…
Est-ce parce qu'on a dépassé les limites de la RAM? Non. Parce qu'on surcharge le processeur de calculs? Pas vraiment. Et pourtant ça ne va pas, tout simplement parce que la supposition de départ ayant mené à la conception des dictionnaires en Python est que les accès sont, en majorité, à plat.
Est-ce qu'on pourrait imaginer une autre structure de données plus adaptée à ce genre de chose? Bien sûr. Est-ce qu'on veut le faire? Certainement pas, et ce n'est ni par paresse, ni par esprit de contradiction. Les choix de design peuvent être discutés, mais peu importe ce que l'on choisit, il y aura des perdants.
[^] # Re: Intérêt ?
Posté par Kalenx . En réponse au journal Tous les parsers JSON sont mauvais. Évalué à 8.
Et pourtant, on a ceci
Du code parfaitement valide qui fait crasher les navigateurs (j'en ai essayé quelques-uns sous les versions les plus récentes de Chromium et Firefox, ça peut prendre quelques secondes mais la plupart des tests crashent effectivement le navigateur ou l'onglet).
À un certain point, comme l'ont bien expliqué d'autres personnes, il faut poser des limites, même arbitraires. Je suis convaincu que GCC (ou n'importe quel compilateur) n'est pas capable de parser certains fichiers C parfaitement valides (mais complètement tordus). Même chose pour un parser XML ou l'interpréteur Python. À ce propos, connaissez-vous l'erreur "s_push: parser stack overflow"? Pourtant cette erreur apparaît sur du code parfaitement valide et limite certains cas d'application réels. C'est dommage, mais c'est une réalité avec laquelle il faut composer : nos grammaires nous permettent de composer des structures infinies, mais le parser possède par définition un nombre fini d'état, c'est donc inéluctable.
Je suis cependant d'accord que ces limites devraient clairement être indiquées dans la documentation.
[^] # Re: Pas convaincu
Posté par Kalenx . En réponse au journal Tous les parsers JSON sont mauvais. Évalué à 4.
La documentation Python de ce module indique :
Or, le document est valide, lancer cette exception serait donc techniquement ne pas respecter l'interface promise au développeur. Ceci étant dit, oui, la possibilité d'une RecursionError devrait être au moins évoquée dans la doc.
Il reste que dans la plupart des langages interprétés, il y a certaines erreurs qui peuvent presque toujours se produire. En Python, les MemoryError en sont de bons exemples. Même si dans 99.9% des cas, cette erreur n'est lancée que si l'utilisateur fait quelque chose d'incorrect, elle peut techniquement se produire dans n'importe quelle opération.
S'il est critique d'attraper toutes les exceptions, alors le modèle except ExceptionPrecise (pour les cas prévus) suivi de except (tout court), suivi éventuellement de else et finally est probablement le meilleur à adopter. Mais dans tous les cas, ce genre d'exceptions "système" peuvent toujours jouer des tours et je ne pense pas que ce soit le rôle de chaque module de le considérer.
# Pas convaincu
Posté par Kalenx . En réponse au journal Tous les parsers JSON sont mauvais. Évalué à 10.
Pour ce genre de cas, il faut considérer deux possibilités :
Personnellement, je réponds à (1) par la négative. Plus de 100 niveaux d'intrication au minimum avant un crash (on parle de près de 1000 pour Python) n'est pas limitatif pour l'extrême majorité des usages.
En ce qui concerne (2), je pense que 2A est fort peu probable (à moins qu'un langage soit assez mal conçu pour laisser aller un débordement de pile sans conséquence). 2B est possible, mais il présuppose que l'attaquant contrôle le JSON parsé, ce qui n'est pas forcément évident.
En ce qui concerne la résolution, une possibilité éventuelle est de réécrire le code sous la forme d'une boucle et d'une pile explicite. Au lieu d'appeler récursivement une nouvelle fonction à chaque ouverture de liste ou de dictionnaire rencontrée, on ajoute le symbole d'ouverture sur la pile. Lorsque l'on rencontre un symbole de fermeture, on dépile et on s'assure que le précédent symbole d'ouverture correspond bien (sinon c'est une erreur de syntaxe). À la fin du décodage, la pile devrait être vide (sinon c'est toujours une erreur). La taille de cette pile peut être dynamiquement agrandie au fil de l'exécution.
Le code résultant est moins joli et plus difficilement extensible cependant. Je pense que la plupart des implémentations ont cependant fait le choix de la clarté. L'important est que l'erreur éventuelle soit claire. Par exemple, dans le cas de Python (je n'ai pas testé les autres), une exception est levée :
Ce qui est très clair, facilement attrapable si besoin est par le programmeur d'une section critique d'une application et ne cause aucun effet de bord indésirable.
Je ne sais pas si c'est la même chose pour tous les parsers, mais de manière générale je ne m'inquièterais pas trop de ce problème.
[^] # Re: C'est pourtant simple
Posté par Kalenx . En réponse au journal La fausse bonne idée de la licence "libre mais pas pour les méchants". Évalué à 5.
Bah tout dépend de ta définition de libre. Au final, à certains égards, cela se ramène à la sempiternelle question : est-on libre si on peut renoncer à cette liberté? Pour certains, interdire cette option est une forme de restriction, alors que pour d'autres, ce n'en est pas une puisque de toute façon tu t'apprétais à renoncer à bien plus.
Les licences sont copyleft te permettent de faire n'importe quoi tant que tu ne restreins pas la liberté des autres. Est-ce pour autant "moins libre" qu'une licence te permettant d'enfermer tes propres utilisateurs? À toi de juger…
[^] # Re: Dans la vraie vie
Posté par Kalenx . En réponse au journal La fausse bonne idée de la licence "libre mais pas pour les méchants". Évalué à 2.
Je ne suis pas certain de comprendre. Si je crée un logiciel sous GPL et qu'un individu le redistribue sans incorporer les sources, oui je peux le poursuivre et l'envoyer devant un tribunal. Est-ce que je le ferai? Peut-être pas, parce que les coûts associés à la poursuite sont trop élevés par rapport à ceux du préjudice que je subis, mais je peux tout autant le faire que pour une multinationale…
Par ailleurs, les textes de licence spécifient explicitement les libertés (permissions si tu préfères) accordées à l'utilisateur. Par exemple, dans la BSD :
L'utilisateur a le choix de la prendre ou non (par exemple, en tant qu'utilisateur de logiciel sous GPL, je peux décider de ne pas me prévaloir de mon droit à obtenir le code source), mais c'est bel et bien la licence qui accorde ou non certaines libertés.
[^] # Re: le texte de la licence ne varie pas
Posté par Kalenx . En réponse au journal La fausse bonne idée de la licence "libre mais pas pour les méchants". Évalué à 3.
Dans le cas d'un clone intégral sans modifications, ça peut passer, mais que se passe-t-il si l'individu modifie le logiciel? À qui faut-il payer la licence? Est-ce que la licence est virale comme la GPL et que—par exemple—si le logiciel ne contient plus que 5% du code original sous "licence zero", il faut quand même payer l'entièreté des droits à l'auteur original?
Ça me paraît très difficile à mettre en oeuvre parce que 1) il faut suivre tous les clones et utilisations dérivées de ton logiciel et 2) parce que la limite d'utilisation n'est pas définissable en pratique.
[^] # Re: Bof
Posté par Kalenx . En réponse au journal [Marque‐page] Réaction de la Document Foundation à la décision de Munich de repasser sous Windows. Évalué à 6.
L'article de la revue de presse de l'April lié au début du billet décrit justement plus les faits. Dans mon journal (que je suis tout à fait prêt à qualifier de bookmark, je ne prétends pas avoir procédé à une analyse quelconque), je trouvais intéressant de discuter de la réaction d'une des parties directement (ou quasi directement) impliquée.
Pour ta seconde critique, il est tout à fait commun de discuter d'une résolution ou d'un projet de loi avant qu'il ne soit officiellement déposé. Oui, techniquement, la ville de Munich peut encore changer l'entièreté de la résolution (je ne sais pas comment ils appellent ça en Allemagne) et décider de n'utiliser que OS/2 et WordPerfect. En pratique, scoop : ça n'arrivera pas.
Je comprends qu'il ne soit pas nécessairement approprié de discuter de chaque microscopique détail, mais sur le plan d'ensemble je ne vois pas pourquoi il faudrait attendre la décision "officielle" alors que la position qui sera défendue est déjà connue hors de tout doute raisonnable.
[^] # Re: C'est surtout une annonce à 2 balles !
Posté par Kalenx . En réponse au journal [Marque‐page] Réaction de la Document Foundation à la décision de Munich de repasser sous Windows. Évalué à 7.
Comme je l'ai dit, je ne présume pas de ce qui se passe en Europe (je ne connais honnêtement pas du tout), mais j'ai donné un exemple réel et parlant de l'utilité des appels d'offre dans une situation similaire. Au Québec toujours, on pourrait parler de la commission Charbonneau, qui a utilisé les résultats d'appels d'offres pour démontrer une collusion entre les entreprises de pavage et de construction.
Est-ce que ça fonctionne toujours? Non. Y a-t-il moyen de contourner le système? Probablement. Est-ce que ça complique la vie aux fraudeurs et collusioneurs et facilite une éventuelle action en justice subséquente? J'en suis persuadé.
[^] # Re: C'est surtout une annonce à 2 balles !
Posté par Kalenx . En réponse au journal [Marque‐page] Réaction de la Document Foundation à la décision de Munich de repasser sous Windows. Évalué à 10.
Le simple fait que ça force les tractations à se faire au grand jour est déjà un énorme avantage, à mon avis… Par ailleurs, des lois imposent des limites sur ce qui peut être exigé dans un appel d'offre. Je ne connais pas la situation en Europe, mais ici au Québec, FACIL et Savoir-Faire Linux ont pu contester avec succès des appels d'offre bidons.
[^] # Re: Bof
Posté par Kalenx . En réponse au journal [Marque‐page] Réaction de la Document Foundation à la décision de Munich de repasser sous Windows. Évalué à 10.
Le rapport complet (450 pages tout de même) a été publié et est accessible à tous. Le billet de la Document Foundation le mentionnait, mais je n'ai pas trouvé pertinent de l'inclure ici puisqu'il est logiquement en allemand, que ma maîtrise de cette langue est en déça du parcelaire et que les outils de traduction automatiques donnaient des résultats franchement épouvantables. Ceci étant dit, si ça intéresse un germanophone, voici maintenant le lien : https://www.ris-muenchen.de/RII/RII/DOK/SITZUNGSVORLAGE/4277724.pdf
Sinon, la discussion a lieu aujourd'hui (le 15 février) donc pour le moment, les arguments détaillés de la ville ne sont pas connus—on a seulement une idée générale, à partir de ce qui a filtré dans les médias et des déclarations générales des politiciens.
Bien sûr qu'il y a plein d'arguments, mais en l'occurrence un rapport a été produit (et pas par une association de libristes) et dit le contraire. Donc, à moins que la DocFo ait tout simplement travesti le résumé qu'ils font de ce rapport pour prétendre le contraire de ce qu'il dit—ce qui serait inacceptable, mais aussi peu probable—on peut considérer que, comme je l'ai expliqué dans mon billet, ces questions ont déjà été posées et que leurs réponses sont satisfaisantes pour le L.L.
[^] # Re: Fuck windaube, micro$oft suxXx, mort a bill gates
Posté par Kalenx . En réponse au journal Microsoft s'accroche jusqu'au bout. Évalué à 7.
Il est objectivement moins cher de n'avoir qu'un seul OS sur sa ligne de montage. Je précise simplement que ça n'a rien à voir avec Windows, cet OS pourrait aussi bien être Linux.
Par ailleurs, je suis dubitatif quant à l'importance relative de ce coût pour un fabricant. Les grosses marques produisent déjà des dizaines de déclinaisons d'un seul modèle (on peut regarder dans la page Dell que je lie plus haut, plus de 16 variantes d'un même modèle…), je ne suis pas convaincu qu'entre toutes ces variantes les coût supplémentaire pour offrir Linux soit important.
En ce qui concerne le coût de la licence de Windows XP, je n'adhère pas à tes conclusions: le fait que Microsoft ait été forcé de vendre XP à rabais sur les netbooks pour contrer Linux tend à montrer qu'il y a bien un avantage côté Linux, au moins sur cette gamme d'ordinateurs à très bas prix.
Dans tous les cas, je ne prétends pas que Linux réduise nettement le prix d'un ordinateur : je n'ai tout simplement aucun chiffre pour appuyer mes arguments. Ce que je dis, c'est que de prétendre à l'inverse que Windows rapporte forcément plus aux fabricants qu'il ne leur coûte est tout aussi peu appuyé par des arguments et que de se gausser de la naïveté de ses interlocuteurs qui ne "veulent même pas payer plus cher pour suivre leurs convictions" (ce qui est par ailleurs faux dans bien des cas) me semble quelque peu sophistique…
[^] # Re: Fuck windaube, micro$oft suxXx, mort a bill gates
Posté par Kalenx . En réponse au journal Microsoft s'accroche jusqu'au bout. Évalué à 10. Dernière modification le 04 janvier 2017 à 07:49.
Un jour (lorsque tu seras descendu de tes grands chevaux), j'aimerais sincèrement voir une analyse démontrant que la licence Windows diminue les coûts par rapport à un portable nu. Le calcul est le suivant :
Coût du portable = coût matériel + coût de la licence - revenu des bidules installés par défaut
Je ne nie pas que les logiciels par défaut réduisent (légèrement) le prix du portable, mais je doute très fortement que cela puisse compenser le coût de la licence—soit dit en passant, je n'ai pas changé de position, c'est ce que je soutiens depuis le début.
Ce qui n'a rien à voir avec Windows.
Permets moi de parier le contraire. Ils font tout simplement partie du programme de certification, tout comme par exemple l'UEFI avec les clés de Microsoft installées, ou l'autocollant de la licence OEM visiblement apposé sous le portable. Quelques gros fabricants peuvent probablement se négocier des particularités, par exemple certains portables où la licence est "cachée" sous une trappe, mais je doute fortement que Microsoft, qui a le gros bout du bâton dans cette histoire, ait un intérêt à consentir à quoi que ce soit financièrement…
Encore une fois, tout cela se base sur ta prémisse qu'un portable avec Windows est forcément moins cher parce que les revenus annexes couvrent plus que le coût de la licence. Je demande à voir des chiffres appuyant cela. Parce que quand je regarde les prix des gros OEM, ce n'est pas ce que je vois. Tiens, par exemple, chez Dell et son XPS 13 proposé avec Windows 10 ou Ubuntu 16.04 : le modèle avec Ubuntu et un i7 coûte 50 euros de moins à caractéristiques équivalentes et ce sans solde de part et d'autre. Un portable Windows du même prix possède un SSD 2 fois plus petit (128 GB vs 256). Sur le modèle tactile, c'est 30 euros de plus pour Ubuntu, et sur le modèle haut de gamme (16 Go de RAM), 50 euros de moins pour Ubuntu. Pas facile de conclure à un avantage pour Windows…
Alors je vais conclure comme toi : arrête tes gamineries. Autant dans certains débats tu amènes des statistiques et des points de vue fort bien documentés, autant dans ce genre de discussion on dirait que tu veux désespérément que Windows ait l'avantage pour pouvoir traiter tes interlocuteurs de gamins qui n'ont rien dans le crâne…
[^] # Re: Fuck windaube, micro$oft suxXx, mort a bill gates
Posté par Kalenx . En réponse au journal Microsoft s'accroche jusqu'au bout. Évalué à 4. Dernière modification le 04 janvier 2017 à 06:57.
En effet, mais ce n'est donc pas lié à Windows et, par transposition, à son autocollant… Adobe pourrait très bien payer les constructeurs pour mettre son lecteur sur Linux—en fait, on n'a qu'à penser au cas d'Amazon et Ubuntu pour voir que ça c'est déjà fait.
Les softs désagréables, ça se désinstalle, et virer carrément la partition Windows pour y mettre Linux est un remède efficace. Mais l'autocollant reste.
Ça peut servir à informer les gens, diront certains, mais quand on sait la légèreté avec laquelle Microsoft a traité sa certification par le passé, je ne suis pas convaincu de son utilité réelle…
[^] # Re: Fuck windaube, micro$oft suxXx, mort a bill gates
Posté par Kalenx . En réponse au journal Microsoft s'accroche jusqu'au bout. Évalué à 4.
Je suis quand même dubitatif : sauf erreur de ma part, la licence Windows (qui vient avec l'autocollant, eh…) ne fait pas chuter le prix de la machine, loin de là… Bon, clairement, le prix d'une licence OEM en volume n'a rien à voir avec le prix d'une version boîte, mais je ne pense pas que ce soit compensé par une rentrée d'argent due à l'autocollant…
[^] # Re: Au boulot ?
Posté par Kalenx . En réponse au journal De l'autarcie du projet GNU, ou comment Emacs ne veut pas devenir EmacOs. Évalué à 6. Dernière modification le 25 novembre 2016 à 21:19.
Je me cite :
Si je voulais omettre cela, j'ai une bien drôle de façon de le faire…
Ceci étant dit, ce n'était pas mon propos. Pourquoi ce code "n'aurait jamais dû" se retrouver là? Il entraînait une régression ou contenait des bugs? Non. Il rendait plus difficile la maintenance du reste du code? Non. D'autres devs/mainteneurs s'y étaient opposés et l'auteur original avait passé outre? Non. Ce code s'est retrouvé dans la mainline, et a été retiré pour des questions idéologiques.
Oui, et? Qu'est-ce que ça change pour un utilisateur? D'autres ont commenté que c'était décourageant pour l'auteur du patch original, ce qui est effectivement faux dans ce cas-ci, mais ce n'était aucunement mon propos à la base.
En fait, cette affirmation est intéressante sur un aspect : loin d'être une décision de "l'intelligentsia" allant à l'encontre de la volonté des devs, c'est "la personne qui fait" qui a elle-même reverté son patch… Autant pour le complot des élites déconnectées du monde des programmeurs…
Oui, et c'est précisément ce que j'ai expliqué dans la dernière phrase de mon journal.
Aucun lien avec le propos du journal. Mon but n'était pas d'offrir un guide d'utilisation de Emacs sous macOS.
Si les gens ne sont pas capables de comprendre le sens de "introduite par erreur" (en italique dans le texte), je ne peux pas y faire grand chose. Pour le mainteneur, c'est une information intéressante en effet, qui aurait pu se retrouver dans le journal, mais je ne le savais tout simplement pas (le changelog ne le mentionnait pas).
Puisque ne pas inclure un […] dans une traduction alors que la citation originale est présente 2 lignes plus haut te semble un manquement suffisament grave pour mériter une réponse aussi acerbe, je t'invite à inutiler mon journal scandaleux qui induit en erreur la populace.
[^] # Re: Au boulot ?
Posté par Kalenx . En réponse au journal De l'autarcie du projet GNU, ou comment Emacs ne veut pas devenir EmacOs. Évalué à 5. Dernière modification le 25 novembre 2016 à 16:54.
Je ne voulais plus vraiment intervenir (après 180 commentaires, il n'y a plus grand chose à dire), mais je pense qu'il est important de préciser quelque chose.
Lorsque j'ai traduit la citation (que j'ai par ailleurs laissée dans sa version originale, littéralement 2 lignes au-dessus), j'ai simplement passé outre l'explication parce que je ne voyais pas en quoi ça avait un lien avec le débat. J'ai laissé le "par erreur" pour noter que dès le départ, ce n'était pas la situation voulu par les devs. La situation est :
1. Il y avait un support pour les emojis colorés sous MacOS
2. Ce support a été retiré
Peu importe comment 1) s'est produit (commit erroné, le chat du dev a implémenté la fonctionnalité en marchant sur son clavier, Stallman a une double personnalité où il est un adorateur d'Apple), il reste qu'une fonctionnalité introduite plusieurs mois auparavant et fonctionnelle a été retirée sans justification technique (uniquement politique).
Je l'ai dit dans mon journal, je suis d'accord avec cette justification politique. N'empêche que je ne vois pas en quoi la non-traduction d'une partie du changelog pourrait modifier la perception qu'on les détracteurs ou les partisans de cette décision.
La prochaine fois, je mettrai un […] :)
[^] # Re: Mais ça suffit avec Stallman !
Posté par Kalenx . En réponse au journal De l'autarcie du projet GNU, ou comment Emacs ne veut pas devenir EmacOs. Évalué à 7.
J'imagine qu'il y a effectivement des dévôts de RMS, mais il y a une différence entre être intégriste et réagir à ça :
Pour l'avoir rencontré en personne, ma perception de RMS est qu'il s'agit de quelqu'un de foncièrement désagréable, grossier même. Mais je suis capable d'apprécier néanmoins sa contribution, qui ne se résume pas à "quelques bonnes idées au début". On pourrait dire la même chose d'Ulrich Drepper : c'est une personne parfaitement incapable de dialoguer de manière constructive et d'une grossièreté absolument risible. N'empêche que je le défendrai si quelqu'un soutient qu'il est un piètre programmeur, parce que c'est simplement faux.
Stallman (ainsi que "l'autre icône à 3 lettres") ont des idées libertariennes bien arrêtées, que je ne partage absolument pas.
Si je soutiens quelqu'un, j'approuve automatiquement tout ce qu'il a dit et fait depuis sa naissance? Ça va être difficile… Pour le coup, personne n'a dit que la pédophilie était acceptable, simplement qu'il fallait la replacer dans le contexte du consentement et du principe selon lequel un enfant (la définition d'enfant variant pour chaque pays) ne peut consentir.
Dans tous les cas, si RMS constitue une figure indubitable du logiciel libre, il ne compose pas l'entièreté de la FSF, encore moins du monde du LL.
[^] # Re: Ha les intégristes du libre...
Posté par Kalenx . En réponse au journal De l'autarcie du projet GNU, ou comment Emacs ne veut pas devenir EmacOs. Évalué à 10.
C'est curieux. Toi qui reproche toujours à la moitié de la planète libre de manquer de cohérence, qui explique la perte de vitesse de Firefox par le fait que Mozilla a déchiré ses principes en incluant un tracker sur sa page d'accueil et en incluant Pocket, un module propriétaire, à Firefox, j'aurais cru que cette position de la FSF te plairait.
Ils l'affirment haut et fort : leur objectif, c'est la liberté de l'utilisateur. Si une fonctionnalité d'un OS non libre fait de l'ombre à tous les OS libres, alors l'utiliser est contraire à cet objectif, puisque cela peut encourager une migration vers cet OS non libre.
Il ne dit pas "les OS libres sont moins bien"—ce qui n'a pas vraiment de sens d'ailleurs, comment décides-tu qu'une fonctionnalité parmi des millions fait qu'un OS est meilleur qu'un autre? Il dit "les programmes GNU, et particulièrement Emacs, ne doivent pas dépendre de fonctionnalités existant uniquement sur des OS non libres, au risque d'encourager leur utilisation".
Encore une fois, non, je ne suis pas d'avis que c'est une excuse "bidon", mais au contraire réfléchie. Tu peux ne pas être d'accord (tout comme on peut être fâché qu'Intel ait refusé d'inclure le patch de support pour Mir en upstream), mais ce n'est pas un acte isolé pris sous le coup de l'émotion, ça fait partie d'une position défendue par la FSF de longue date.
Oui, tous des logiciels libres, comme je l'ai écrit. Et c'est GNU/Linux par ailleurs ;-)
Ne pas défendre ce que l'on juge et clame être le plus important, aller à l'encontre de ses idéaux, ça aussi ça donne mauvaise réputation au mouvement (et tu en profites largement lorsque l'on discute d'autres projets libres, d'ailleurs). RMS ne refuse pas de vivre avec "les autres" : il refuse de vivre avec du logiciel propriétaire.
# Je suis quand même curieux...
Posté par Kalenx . En réponse au journal #WhatWouldTimblDo : nouvelle campagne de la FSF contre les DRM sur le Web. Évalué à 6. Dernière modification le 11 novembre 2016 à 15:14.
de ce que la FSF espère comme résultat. Bien que directeur du W3C, cet organisme reste un consortium et Berners-Lee n'a tout simplement pas le pouvoir de s'opposer à une décision d'un comité prise en conformité avec les statuts et règles en vigueur.
Oui, bien sûr, d'un point de vue relations publiques, ne pas avoir le créateur du web de son côté, ce n'est pas génial, mais fort surmontable, compte tenu que les personnes chez qui cette situation créerait un sentiment de malaise sont les mêmes que celles qui sont déjà fortement opposées à Microsoft, Apple et les autres qui veulent imposer des DRMs.
Et même à la limite, si Berners-Lee mettait son poing sur la table et refusait le passage en W3C Recommendation de l'EME (en supposant que ce soit possible, ce dont, encore une fois, je doute) : le pouvoir ne résiste pas dans les spécifications, mais dans les implémentations. Avec plus de 80% de parts de marchés, si Microsoft, Apple et Google s'entendent sur une mise en oeuvre entre eux, alors ce sera ça qui deviendra un standard de facto, que le W3C le veuille ou non! Apparté : on se demandait dans un précédent journal à quoi pouvait bien servir Firefox maintenant que d'autres navigateurs libres existent; eh bien, précisément à ça.
Ceci étant, sur le site de la pétition, la FSF parle beaucoup plus du W3C que de TBL, ce qui me semble une bonne chose.
[^] # Re: Homme de paille
Posté par Kalenx . En réponse au journal Mozilla: l'enjeu de 2017 est-il au niveau du navigateur web ?. Évalué à 5.
Je n'ai pas vu cette histoire, mais en quoi est-ce une décision du "méchant management" plutôt qu'une décision technique? Peut-être que dans certains contextes, quelques Ko font une différence importante et que "l'autre" offre mieux?
Que disais-tu de Mozilla? Ah oui, qu'ils n'étaient pas capables de suivre leurs principes, par exemple de refuser d'intégrer un codec propriétaire. Évidemment que dans ce cas-ci le point en litige n'était pas technique, mais politique…
Oui, et pas mal étaient pour. Après tout, on pouvait raisonnablement supposer que le créateur du Javascript et un contributeur important du projet avait une certaine légitimité comme chef de projet… Je ne conteste pas son renvoi/démission, mais c'est loin d'être un cas où le "méchant management" a pris une décision sans queue ni tête…
Bon, en fait, tu t'en fiches des "principes" de Mozilla… Ou plutôt, tu ne t'en sers que lorsque ça t'arrange : si tu peux critiquer Mozilla en disant qu'ils trahissent leurs utilisateurs de la première heure, c'est bon. Mais admettre que tous ces projets que "tu ne peux pas vendre à des utilisateurs" ont changé la façon dont ces utilisateurs perçoivent et utilisent le web, ça, non, ça n'est pas assez important pour que tu admettes que l'influence de Mozilla a suivi, au moins sur ces cas là, ses principes fondateurs. Non, c'est plus important d'avoir une jolie interface graphique.
Tiens, un autre exemple :
Après, en ce qui concerne tous les arguments de "défense du passé" et de "retour aux sources" : ne t'étonne pas de voir des attitudes défensives en réponse à tes commentaires. Contrairement à ce que tu sembles suggérer, le problème n'est pas que les gens jouent à l'autruche en psalmoldiant le Book of Mozilla, mais que tu soutiens des causes complètement fantasques pour expliquer des faits qui, eux, sont indéniables (le déclin de Firefox).
Oui, Mozilla doit se réinventer et non, je ne suis pas certain qu'ils vont y arriver, mais ce n'est pas parce qu'ils ont changé : c'est parce que le reste de l'écosystème a changé!
[^] # Re: Homme de paille
Posté par Kalenx . En réponse au journal Mozilla: l'enjeu de 2017 est-il au niveau du navigateur web ?. Évalué à 7. Dernière modification le 10 novembre 2016 à 08:00.
Il perd des parts de marchés, c'est indéniable. Mourir? Ça reste à voir. Firefox s'est bâti sur un idéal, et ça, ça ne meure pas. Il est possible que la MoFo finisse par disparaître (tout comme Netscape Corp. a disparu), mais ce n'est pas une fin en soi.
Il est vrai que Firefox a perdu beaucoup de ses avantages : se comparer à un navigateur sans aucune évolution durant des années (IE6) et un navigateur au développement très rapide et activement soutenu par une entreprise qui a tout avantage à contrôler ce qui se fait dans ce marché (Chrome), ce n'est pas la même paire de manches. Il y a deux choses à dire à ce sujet, cependant :
Oh non, Steve Ballmer et Bill Gates ont quitté Microsoft! C'est dire comme ça doit craindre en interne si ces "têtes de point de la première heure" s'en vont!
Effectivement, on n'a plus à rêver d'avoir un navigateur sécuritaire, évolutif et rapide : on l'a, et on a même le choix!
Faux, complètement faux. C'est orthogonal au libre. On veut plusieurs moteurs de rendu pour éviter que les développeurs "n'optimisent" leur code pour un moteur en particulier. En fait, à un certain point, la présence de Firefox est probablement bénéfique à Webkit/Blink : faire évoluer ce moteur serait probablement bien plus ardu s'il fallait tenir compte de tous les quirks que les gens exploiteraient s'il n'y avait que lui.
"ben c'est quoi la différence avec Google?"
Je l'ai déjà expliqué en long et en large dans une précédente discussion : il est absurde de dire que des supporters de Mozilla, ceux qui sont là pour la protection de leur vie privée et la philosophie libre, s'en détournent au profit de Chrome, un navigateur soutenu par une multinationale dont le but est explicitement de récolter le plus de données possible sur tout le monde, simplement parce que Mozilla a sorti une extension Pocket non libre et a osé utiliser un tracker sur leur page d'accueil…
Sans commentaires…
# Homme de paille
Posté par Kalenx . En réponse au journal Mozilla: l'enjeu de 2017 est-il au niveau du navigateur web ?. Évalué à 10.
Si je résume l'argumentaire présenté dans le journal : il y a sur le web d'autres problèmes que l'accès à un navigateur décent, donc Mozilla fait forcément fausse route en continuant à développer et améliorer son navigateur (et c'est parce qu'ils ne pensent qu'à la tune maintenant).
Mozilla n'a jamais été impliqué de manière importante dans le cloud computing. Ce que ce journal fait, c'est un peu comme reprocher à une Médecins sans frontières de faire fausse route parce que "en 2017, l'enjeu c'est l'accès à Internet pour tous". Même si la seconde proposition peut être vraie jusqu'à un certain point, en quoi cela remet-il en question le travail de MSF?
C'est la même chose avec Mozilla. Bien sûr qu'ils pourraient se diversifier (quoique ils se feraient alors critiquer sous prétexte qu'ils "s'éparpillent" et qu'ils devraient se "concentrer" sur leur mission première, comme ce fut le cas lors de la sortie de FirefoxOS), mais le fait qu'ils ne le fassent pas n'est pas une preuve de leur insignifiance.
Par ailleurs, les navigateurs web sont littéralement la colonne vertébrale du cloud. "Un moteur de rendu efficace et un moteur JS tout aussi efficace", c'est très loin d'être simple de nos jours. On demande aux interpréteurs javascript d'être quasiment aussi rapides que du code natif et aux moteurs de rendu de supporter un nombre sans cesse croissant de standards changeant très rapidement, sans pour autant exposer l'utilisateur à des failles de sécurité ou vider la batterie d'un dispositif mobile en cinq minutes. Qupzilla et consort ne peuvent exister que parce qu'ils utilisent justement des moteurs déjà développés par d'autres, et même Opera a renoncé à son moteur maison, historiquement à la fine pointe, pourtant.
Les gens de Mozilla ont proposé une myriade de projets au fil des ans : asm.js, Rust, Let's Encrypt, Persona, encodeur JPEG plus efficace, pdf.js, Hello, et j'en passe. C'est vrai, la plupart de ces projets ne touchent pas directement l'internaute, mais ont néanmoins eu un impact plus qu'appréciable sur la protection de la vie privée, la sécurité ou l'efficacité de nos navigateurs. Mettre tout ça de côté et minimiser l'importance capitale d'un navigateur libre et ouvert en prétextant à répétition que "Mozilla ne pense plus qu'à l'argent" en guise d'argument, c'est quelque peu spécieux…
[^] # Re: Langages modernes
Posté par Kalenx . En réponse au journal Gestion des erreurs d’allocation mémoire en C. Évalué à 2.
En fait, c'est encore mieux : np.zeros est un cas à part. Il "initialise" la mémoire à zéro, mais le kernel garde toujours un page remplie de zéros sur laquelle il peut faire du copy-on-write. Si bien que tu peux sans problème appeler np.zeros, sans overhead particulier par rapport à np.empty (sur Linux du moins).
On ne peut pas en dire autant de np.ones par contre…