Antoine a écrit 5722 commentaires

Alors si les outils libres ne sont pas au niveau, pourquoi ne s'investissent-ils pas d'abord là dedans avant de venir chier dans les bottes des gens qui essayent de porter un projet qui leur tient à cœur ?

Tout ceci serait tout de même plus crédible si les projets libres étaient la plupart du temps hébergés sur des plateformes libres, plutôt que (par exemple) GitHub. Comme toujours, la critique est facile, l'art est difficile.

D'autant que, dans le LL, un contributeur bénévole s'investit dans ce qui l'intéresse : si ça intéresse quelqu'un de faire du design plutôt que de développeur un logiciel de dessin libre, c'est ce qu'il fera et il est ridicule d'essayer de le convaincre de changer de sujet. Imagines si tu contribues une correction de bug à un projet libre et qu'on te réponde : « c'est gentil, mais en ce moment on a plutôt besoin d'un bug tracker, peux-tu nous le coder stp, ce sera plus utile ? »… est-ce que tu coderais le bug tracker en question, ou est-ce que tu laisserais tomber l'affaire ?

Bref, des mecs dans leur tour d'ivoire […]

Cette remarque me rappelle une histoire de poutre et de paille.

il existe une FAQ spéciale pour les journalistes XD c'est dire le niveau de la profession

Ainsi, il suffisait à François Fillon de publier une FAQ pour qu'on ne le dérange pas à propos de ses petites turpitudes…

En quoi est-ce un hack ? Pas mal d’outils font ça.

J'adore le raisonnement : pas mal d'outils le font, donc ce n'est pas un hack. Ben non : ce n'est pas parce que pas mal d'outils le font que ce n'est pas un hack. Juste parce qu'ils sont obligés de contourner ce genre de limitations.

Par exemple pour ansible :

Là ce n'est pas la même chose. ansible te permet de modifier la config de l'outil en utilisant des variables d'environnement. CGI passe les entêtes d'une requête HTTP dans les variables d'environnement : la différence paraît assez claire. Note que cela conduit à mélanger l'environnement de la machine (contrôlé par l'admin, normalement) avec les paramètres de requête passés par le client distant (totalement arbitraires et pas fiables a priori).

puisque même en FastCGI la logique est la même

FastCGI est un autre hack. Mais de nos jours on utilise surtout des approches plus modernes, comme WSGI.

stdio est toujours utilisé dans des application modernes quand c’est intéressant

Oui, bien sûr, quand c'est intéressant. Mon argument n'est pas de pire que ce n'a pas d'intérêt, mais que c'est loin d'être la réponse à tous les problèmes, et que dire qu'il n'y a « rien de plus génial » est un poil exagéré : il y a des applications où on a remplacé stdio par des choses « un peu plus géniales » (ou, disons, moins pourries).

Effectivement, le shell ne définit pas la sémantique de 100% des applications existantes et non-existantes

Hors sujet. HTTP non plus ne définit pas la sémantique de 100% des applications existantes et non-existantes, pourtant il définit une multitude de codes de retour, dont plusieurs correspondent à un succès. Chaque application utilise le sous-ensemble de codes de retour qui l'intéresse.

Rien de plus génial que les redirections et les pipes, par exemple

C'est au contraire très limité. Dès que tu as plus de deux flux (un en entrée, un en sortie), ça devient assez casse-gueule… Ne parlons pas du côté bas niveau et non structuré : CGI, c'était des pipes (avec des variables d'environnement en plus pour essayer de contourner la limitation à un flux en entrée, bonjour le hack), c'est pas pour rien qu'on a fini par le remplacer par d'autres outils.

Surtout en ayant dans l’idée de faire un truc génialissime révolutionnaire.

Je ne vois pas qui a parlé de faire un « truc génialissime révolutionnaire » (ça veut dire quoi ?). Tu sembles penser que quelqu'un qui se présente comme designer est forcément une victime de la mode, abreuvée aux derniers gadgets, mue par des lubies inconsistantes. Tu juges l'auteur de l'article en fonction d'un préjugé qui te le fait imaginer comme un type versatile et incompétent.

La mode et autres tendances actuelles étant plutôt à l’opposé des préoccupations d’accessibilité.

Au contraire, l'accessibilité fait partie des tendances actuelles au sens où sa prise en compte devient obligatoire dans pas mal de domaines (pas qu'en informatique, mais aussi dans le monde physique : cf. normes dans le bâtiment).

Ça ne répond pas à la question. Rien n'indique que le design « texte clair sur fond noir et bandeau orange » soit le seul design à même de satisfaire les contraintes d'accessibilité pour les daltoniens. Donc quand tu dis que ce design ne peut pas être changé parce qu'il faut qu'il reste accessible aux daltoniens, c'est un argument fallacieux.

Pas de bol, il y a une personne daltonienne dans l’équipe. Ces couleurs permettent d’avoir un site accessible y compris pour elle.

Et c'est la seule manière que le site soit accessible à cette personne daltonienne ? Ou c'est juste une excuse un peu ridicule pour justifier ce design ?

Pardon, mais les exigences d'accessibilité sont aujourd'hui de plus en plus prises en compte (c'est même devenu une exigence règlementaire pour de nombreuses administrations publiques), or assez peu de sites Web adoptent de design proche de celui de « nos-oignons.net ». J'en suis amené à déduire que l'explication fournie ne tient pas, sauf à penser que tous les professionnels du domaine soient des quiches (et que « nos-oignons.net », eux, ont tout compris du sujet, alors que leur spécialité, si j'ai bien compris, ce serait plutôt les relais Tor…).

Ton commentaire illustre assez bien le phénomène que décrit l'auteur : la tendance à rembarrer toute critique ou toute proposition en utilisant des arguments fallacieux sur un sujet que l'on ne maîtrise pas, le tout sur un ton défensif voire hostile, comme si tu répondais à une agression personnelle.

L'ironie, c'est que Gnome Shell est, il me semble, l'exemple typique d'un projet libre qui a commencé son cours en adoptant l'approche conseillée dans l'article : à savoir laisser une équipe de designers faire son boulot tranquillement, en ignorant royalement les retours des autres contributeurs (ce qui leur a valu des critiques acerbes).

Je n'aime pas non plus Gnome Shell pour ma part : cela ne veut pas forcément dire que l'approche est mauvaise.

Même avec le « hack » décrit dans l’article de Thomas Hühn ?

Imagine que tu démarres toujours ta VM depuis le même instantané (dans un usage « stateless » façon Docker). Alors tu initialiseras toujours ton PRNG avec les mêmes valeurs « aléatoires ».

Pourquoi est-ce que c’est pas implémenté de la même manière sous Linux plutôt que d’avoir 3 API (les deux devices et un syscall) ?

Honnêtement, je n'en sais rien. L'avantage d'un syscall, c'est qu'on n'a pas besoin d'ouvrir un descripteur de fichier, et on peut tailler la sémantique sur mesure. Mais je ne connais pas l'historique.

La discussion est un peu compliquée par le fait que parler de /dev/urandom peut désigner deux choses:

• l'API /dev/urandom elle-même, c'est-à-dire le fait de lire depuis ce fichier, a le problème de renvoyer des octets théoriquement prédictibles au démarrage ; cette API devient progressivement obsolète (sous Linux) au profit de getrandom() qui résoud ce problème précis ;

• le RNG sous-jacent, souvent désigné par raccourci de la même manière, mais qui est aussi utilisé par getrandom() avec des garanties différentes

La proposition de Stephan Müller corrige certains problèmes du RNG sous-jacent, pas de l'API qui, elle, reste toujours problématique pour des usages nécessitant un degré élevé de sécurité (par exemple pour générer une clé privée utilisée pendant tout l'uptime dans d'un démon). Ainsi la proposition de Stephan Müller raccourcit le temps pendant lequel l'API /dev/urandom peut renvoyer des octets prédictibles, elle ne l'élimine pas.

L’article que j’ai cité explique bien comment fonctionne /dev/random et /dev/urandom (ils utilisent le même PRNG).

La différence n'est pas là. La différence est dans le fait que /dev/random est bloquant jusqu'à ce qu'il y ait assez d'entropie (garantissant ainsi que les bits renvoyés ne peuvent être prédits), alors que /dev/urandom peut renvoyer des bits uniquement pseudo-aléatoires (donc théoriquement prédictibles) s'il n'y a pas assez d'entropie.

L'auteur de l'article prétend que ce n'est pas un problème. Mais ce n'est pas ce que pense l'auteur de la proposition de nouveau RNG, qui considère que la sécurité actuelle est insuffisante. La question n'est pas aussi tranchée que l'article semble le dire.

Ce qui est vrai, c'est que pour la plupart des applications, /dev/urandom est largement suffisant. Mais il y a des usages, minoritaires mais importants, où la possibilité de retomber sur une génération uniquement pseudo-aléatoire (typiquement, au démarrage du système) peut poser de réels problèmes de sécurité.

Et puisque tu parles de getrandom, voilà ce que dit l’auteur de l’article

Oui, et je ne vois pas en quoi cela contredit ce que j'ai dit. getrandom() a un comportement différent de /dev/urandom/ pendant le démarrage du système.

Ainsi (page de manuel de getrandom()) :

By default, when reading from /dev/random, getrandom() blocks if no random bytes are available, and when reading from /dev/urandom, it blocks if the entropy pool has not yet been initialized.

=> au démarrage du système, getrandom() bloque jusqu'à ce que le pool d'entropie soit initialisé (i.e. rempli une première fois)

Tandis que (page de manuel de /dev/urandom):

A read from the /dev/urandom device will not block waiting for more entropy. If there is not sufficient entropy, a pseudorandom number generator is used to create the requested bytes. As a result, in this case the returned values are theoretically vulnerable to a cryptographic attack on the algorithms used by the driver.

=> au démarrage du système, il est possible que /dev/urandom renvoie des bits théoriquement prédictibles.

Encore une fois, l'article pense que cette différence n'a pas d'importance, l'auteur de la proposition de nouveau RNG (et aussi l'auteur des pages de manuel Linux) pense que si.

Il y a bien une différence : /dev/random/ garantit de renvoyer des bits réellement aléatoires (et non pseudo-aléatoires), tandis que /dev/urandom peut retomber sur un comportement prédictible s'il est utilisé avant que le pool d'entropie soit suffisamment plein. Cela pose problème pour les programmes lancés pendant le démarrage d'un système, qui font alors face à un dilemme :

• soit lire depuis /dev/urandom, qui est non-bloquant mais risque dans certains cas de fournir une entropie insuffisante (et donc rendre ces programmes potentiellement vulnérables, s'ils utilisent ces bits aléatoires pour des fonctions de sécurité)

• soit lire depuis /dev/random et risquer de bloquer pendant de longues secondes, le temps que le pool d'entropie soit initialisé

C'est très bien expliqué dans le document de proposition du nouveau RNG, avec des mesures concrètes assez édifiantes : le pool d'entropie actuel peut ainsi prendre 30 secondes pour collecter suffisamment d'entropie (notamment sur une VM, qui dispose de sources d'entropie limitées), ce qui est beaucoup trop long pour les besoins des programmes lancés au démarrage. Avec la proposition de nouveau RNG, ce délai descend à une seconde ou moins, ce qui est beaucoup plus supportable.

Pour un exemple concret, Python utilise désormais la version bloquante de l'appel système getrandom(), ce qui offre des garanties plus fortes que de lire depuis /dev/urandom:
https://www.python.org/dev/peps/pep-0524/

C'est quand même violent de dire que c'est moche et pas drôle,

Mouais… Sur Linuxfr, la critique est rarement à fleurets mouchetés. Pour le coup, c'est réellement mal dessiné et d'un humour inexistant. Même la typo des phylactères est laide.

Le minimum serait de les afficher dans une taille deux à quatre fois plus petite, histoire que ces images ne bouffent pas la moitié de l'espace vertical. Ceci d'autant plus que la dépêche est par ailleurs excellente (merci aux rédacteurs).

Tout ça pour dire que ce n'est pas comme si on avait plusieurs propositions pour illustrer les dépêches du kernel

Je ne vois pas trop le rapport, en fait. Une illustration n'est pas nécessaire, et si elle n'apporte rien au message de l'article, elle est même superflue. Ça me fait penser aux magasins ou aux bars qui insistent pour passer une musique pénible en fond sonore.

Aucun des liens que tu donnes ne mentionne (et ne parlons même pas de le prouver) que le glyphosate en particulier aurait été reconnu responsable de leucémies chez des enfants de moins de 10 ans.

Et puis c'est tellement plus mignon quand c'est des enfants qui crèvent dans la douleur à cause de la stupidité de leurs aînés.

Ce qui n'est pas très mignon, c'est de présenter de simples allégations comme des faits avérés (tout en faisant de la démagogie de très mauvais goût en brandissant des photos d'enfants morts). La pente obscurantiste et anti-scientifique d'une partie de l'idéologie écologiste est inquiétante, surtout quand cette idéologie se trouve propagée en toute bonne foi par des tas de gens qui ne cherchent pas à contrôler leurs sources d'information.

C'est le même mode de pensée qui permet aux mouvements anti-vaccination de trouver des appuis chez certains parlementaires Verts, par exemple :
http://www.pseudo-sciences.org/spip.php?article2776

(eh oui, pas besoin d'aller chez Donald Trump pour trouver de l'obscurantisme : une partie de la « gauche » actuelle contribue largement sa part)

Prétendre que l'utilisateur devrait changer lui-même le mot de passe de ses « objets connectés », c'est faire peser sur l'utilisateur la responsabilité d'un défaut de conception : si le fabricant sait que la plupart des utilisateurs ne changeront pas le mot de passe, alors c'est au fabricant de régler un mot de passe différent sur chaque machine vendue (un peu comme sur les modems ADSL qui viennent d'office avec des identifiants wifi uniques).

La sociologie des utilisateurs n'est pas un bug, c'est une contrainte de conception.

C'est un peu comme dire que chez Monsanto c'est des humains tout en regardant les photos de tous les enfants de moins de 10ans souffrant d'une leucémie à cause du glyphosate.

Hum… Elle a été prouvée où, la responsabilité du glyphosate dans les leucémies d'enfants de moins de 10 ans ?

Faire payer pour un système préconfiguré (plutôt que de dire aux gens de se débrouiller avec un HOWTO), ce n'est pas choquant en soi. Je ne me souviens pas qu'on ait traité MandrakeSoft d'escrocs à l'époque où ils vendaient des CD pressés de leur distrib dont n'importe qui pouvait télécharger l'ISO gratuitement sur Internet.

Mais vu la forme des arguments utilisés par ce fabricant, ça sent en effet l'entourloupe : aucun mot sur la maintenance, le support, les matériels pris en charge…

Quelqu'un a-t'il plus de réussite que moi et saurait me dire pourquoi cela ne fonctionne pas chez moi ?
(je tourne sous Xubuntu 16.04)

Ça marche ici (Xubuntu 16.04, carte NVidia). En allant sur about:support tu auras des infos sur l'accélération graphique.

Après une courte investigation, le responsable n'est pas NVidia mais le profil AppArmor d'Ubuntu pour Firefox :
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1660051

(pour ceux qui rencontrent le même problème, une solution est donnée dans le rapport de bug ci-dessus)

Avec la mise à jour Ubuntu vers Firefox 51, je viens d'essayer Electrolysis en désactivant mes modules Firefox. Verdict : ça marche très mal, l'affichage n'est pas rafraîchi correctement quand je passe d'un onglet à l'autre. Le tout sur une carte GeForce GT 730 utilisant, bien sûr, les pilotes proprios. Est-ce que quelqu'un a eu la même expérience que moi ?

Avant même de parler de performances, le premier problème est de savoir si cette émulation de fork sous Windows a bien la même sémantique que sous Unix (par exemple sur le comportement des descripteurs de fichiers hérités). Franchement, vu comme fork sous Unix peut mener à des problèmes subtils, j'hésiterais très fort à tenter d'utiliser une émulation officieuse sous Windows, c'est-à-dire un système qui n'a rien à voir.

Le code « classique » est le suivant :

Je ne suis pas sûr du tout que ce soit ce qui est mesuré ici. Il n'y a pas de support OpenMP dans Python, ni (probablement) dans Go. Le benchmark ici est probablement beaucoup plus simple : on fait tourner fib(N) sur un certain nombre de threads à la fois, et on graphe le nombre d'exécutions par seconde en fonction du nombre de threads.

Surtout qu'en pratique, sur du code serveur, on se fiche pas mal de l'overhead de création de threads ou de processus, parce qu'on crée un pool de threads statique au début de l'application…

Si c'était vrai pour Maréchal-Le Pen, ça devrait être vrai pour tous ceux qui apparaissent autant qu'elle à la télé, et il y en a pas mal (par exemple Valls, Hollande, etc.). Il leur suffit d'apparaître à la télé pour être crus sur parole, eux aussi ?

Peut-être que les gens croient les politiciens qui leur paraissent crédibles. C'est vrai que ça fait chier certains que des électeurs puissent considérer le FN ou tout autre parti présentable comme « crédible » : il est plus agréable de considérer que ces électeurs sont des crétins.

C'est toi qui nous prends pour des imbéciles

C'est qui, « nous » ? Tu parles de toi au pluriel ?
Personnellement, je ne te prends pas pour un imbécile, mais je note que comme un certain nombre de gens ici, tu penses que la majorité des gens sont des idiots manipulables à souhait. C'est une idéologie radicalement anti-démocratique assez courante de nos jours chez les classes moyennes.

si tu cherches a nous faire croire qu'aujourd'hui les gens qui utilisent internet sont tous à même de comprendre comment le ranking fonctionne

Et où est-ce que je cherche à faire croire cela ?
Il n'y a pas besoin de comprendre comment le ranking fonctionne, il suffit de savoir que les résultats de recherche sont basés sur des automatismes et non sur une entrée des données par des humains. Et ça, désolé, mais à peu près tout le monde le comprend.

quand tu veux nous faire croire que la majorité des gens qui utilisent internet en font le meilleur usage en allant directement sur le site vie-publique.fr ou servce-publique.fr sans passer par Google

J'adore comme tu as décidé quel était le « meilleur usage » d'Internet.

C'est bien ce que je disais au-dessus : tu penses être au-dessus de tout le monde, de connaître le « meilleur usage », mais que les autres sont des ignorants qui vont penser sincèrement que les résultats de recherche obtenus sur Google sont le fait d'un tri fait par des experts.

d'ailleurs pourquoi l'équipe de MLN aurait fait l'effort d'y être sinon ?

Comme je l'ai dit au-dessus : pour que les gens cherchent à s'intéresser au FN. Tu crois que les autres partis ne font pas de même ? Bien sûr que si : ils achètent de la présence sur Internet comme le FN.

Soit ce status-quo (les gens ont qu'a pas être bête) t'arranges pour une raison ou pour une autre soit tu te méprends sur le temps et le niveau de compréhension qu'ont les AUTRES a passer sur ces sujets.

Encore une fois, il n'y a pas besoin d'y passer du temps pour comprendre que les résultats de recherche de Google sont le fait d'automatismes…

Pense juste a un enfant qui doit faire une recherche pour un devoir a l'école

Oui, et alors ? C'est aux parents d'encadrer les enfants dans leur découverte du monde. Je te signale que les pages du FN sont loin d'être la seule ressource critiquable qu'un enfant peut trouver sur Internet…

On ne va pas rendre l'espace public bisounours-compliant sous prétexte que sinon les enfants risquent de se faire abuser par certaines choses.