anaseto a écrit 2229 commentaires

Je trouve assez curieux cet acharnement pour défendre la longueur de l'embargo et interdire à OpenBSD de se plaindre : parce que c'est la seule chose qu'ils ont fait sans accord, se plaindre sur la longueur, l'erreur de donner l'accord (Edit: qui est une erreur, et une illustration des risques de faiblesse avec les embargos) ne leur appartient tout simplement pas ; ou alors se plaindre, c'est être coupable aujourd'hui :) D'ailleurs, ce post de tedu pour Heartbleed montre bien leur position que, même s'ils n'aiment pas, ils respectent les embargos si ce n'est pas leur bug et qu'ils n'ont pas la permission.

Et ce n'est pas comme si du côté de Linux ça aime plus les embargos, je dirais même que Linus Torvalds est bien plus extrême en la matière, si ça ne tenait qu'à lui il n'y aurait même pas d'embargo court, et les embargos pour Linux, arrivés malgré Linus, ont actuellement une limite très faible (entre 14 et 19 jours max, avec préférence pour moins de 7 jours, d'après un lwn d'il y a quelques années).

J'en suis au tout début, c'est codé en java, et ça a pour but ultime de fournir un rogue adaptable au niveau des règles de jeu, multijoueur.

Ça ressemblerait peut-être donc plus à un roguelite (jeu temps réel et pas par tour ?).

Graphistes ! Là je suis nul de chez nul.

Si le graphisme est un problème, pour un roguelike, tu peux utiliser l'approche traditionelle de l'ASCII, qui n'est pas sans avantages: plus facile à parser pour l'œil, et plus simple à coder :) Je ne connais pas grand chose à Java, mais il y a ce tutoriel pour Java utilisant ASCIIPanel, qui est relativement connu.

Et bonne chance, en tous cas, écrire un roguelike, c'est d'expérience super amusant !

exclure les personnes disant explicitement qu'elles ne respecteront pas les décisions communes

Je pense effectivement que c'est le mieux en cas d'embargo long : ça évite à la personne d'avoir à attendre de façon d'incompatible avec son éthique (ne pas savoir est une solution parfois). Après, en l'occurrence, c'est un embargo rallongé, donc c'est plus difficile à prévoir, j'imagine.

le sujet est la vie en communauté

En effet, c'est pourquoi je pense que la solution de prévenir OpenBSD plus tard est plus en accord avec l'éthique des deux parties, plutôt que celle de prévenir trop tôt, rallonger l'embargo, puis conflit prévisible étant donné la position du projet sur ces choses. Je ne sais pas exactement comment marchent ces diffusions de failles, mais la possibilité de demander à ne pas être prévenu trop tôt aurait du sens à mon avis.

Et je suis assez de ton avis que, pour la Catalogne, c'est juste le bordel, mais on est un peu dans la méthaphore HS, quand même :)

Je pense qu'on est plutôt d'accord, donc :)

Ceci dit, je me pose la question si ton 99% est vraiment un 99%. Que je sache, c'est pas exactement toutes les entreprises et agences gouvernementales de tous les pays du monde qui sont prévenues non plus. Suivant le type de faille ça sera plus ou moins pertinent, mais ça n'a pas l'air si évident comme estimation.

Et vu la non-criticité de cette faille (car bon, honnêtement, tu dois avoir des failles bien plus importantes corrigées dans les mises à jour habituelles de ton OS et navigateur), je peux comprendre que cela ne justifie pas de se précipiter.

Cet argument, que tu répètes plus d'une fois, n'est pas convainquant, car utilisable dans le sens contraire : vu que c'est pas critique, c'est pas grave si les plus lents patchent un peu en retard.

Il reste à démontrer si dans les entreprises prévenues, il y avait des paresseux. Je pense que non, mais c'est à toi de démontrer qu'ils le sont.

Ça c'était la partie légèrement trollesque d'un commentaire écrit un peu vite (pas vraiment voulu, et plus sorti d'un sentiment qu'autre chose, mais ça a eu son effet ^^).

Je ne vois aucun avantage objectif à ce que les petits projets type OpenBSD soit privilégié dans ce dossier.

Il y a deux faits objectifs. D'un côté plus de produits, plus d'utilisateurs (tes critères). D'un autre, des minorités libres ou non prévenues qui ont tout à perdre avec un embargo long accompagné de possibles fuites (mes critères). Il est à noter que si toutes les minorités sont prévenues, la fuite est assurée, donc le procédé est intrinsèquement impossible à rendre équitable.

Après, il y a l'argument subjectif : le mieux pour la majorité (tes critères) prime sur l'équité (mon critère). En tous cas, perso, je vois pas comment tu peux dire qu'il n'y a aucune part de subjectivité à ce raisonnement.

il va falloir un jour expliquer bien posément, avec des arguments prenant en compte le fait que certains déploient sur 1 milliard de machines dont des machines qui ne doivent pas avoir de régressions, comment tu déploies sur 1 milliard de machines en 2 heures sans aucun risque.

En 2h, tu ne peux pas. Mettons que tu aies vraiment besoin de trois mois : dans tous les cas, c'est le choix de l'équité ou de favoriser la majorité par rapport aux minorités, comme je dis plus haut, donc on va forcément pas tous être d'accord, puisqu'il est question d'éthique et pas que de technique.

Bah si, si OpenBSD délivre un correctif en lien avec la sécurité, des gens vont l'analyser si cela n'impacte pas d'autres systèmes et donc générer des attaques contre les dits systèmes qui n'ont pas encore corrigé la faille.

Ma phrase est probablement ambigüe, je voulais dire que ça va pas changer grand chose pour OpenBSD d'être prévenu deux jours avant, ou d'être prévenu trois mois à l'avance et de devoir attendre (le commentaire laissait sous-entendre qu'OpenBSD aller pâtir significativement du fait d'être prévenu plus tard).

Déjà, la faille est surfaite, elle n'est pas si critique que présentée.

Je suis bien d'accord :)

Donc bon, non ils ne sont pas fainéants, paresseux ou incompétents. Mais assurer une qualité de service pour des millions / milliards de produits diffusés dans le monde, utilisés par des non informaticiens, cela ne s'improvise pas. Même un changement banal nécessite de gros efforts pour éviter des problèmes. Du coup ils ne peuvent pas se permettre de faire comme OpenBSD ou Debian de faire un correctif rapidement et de le diffuser dans la foulée ou presque.

J'ai dit « en particulier pour les paresseux », je conçois bien que pour certains, c'est honnêtement compliqué. Toujours est-il, qu'il y a un part de jugement éthique subjectif sur la chose et qu'il est difficile d'être tous d'accord. Pour toi, rallonger significativement l'embargo si ça peut être utile aux gros systèmes non libres (donc à beaucoup plus de monde) justifie un avantage par rapport à une minorité (les systèmes libres, qui doivent attendre la publication avant de patcher, ainsi que les acteurs plus méconnus qui ne seront même pas prévenus), plutôt que de donner le même temps (idéalement le même, ou embargo court à défaut) de réaction pour tous, quitte à que ce soit moins bien pour la majorité. C'est une position qui se défend et que je comprends, mais que je ne réussis pas à partager, je penche plus du côté des minorités.

On fait doublon avec le précédent journal, mais pour reciter le développeur OpenBSD chargé du truc : d'un, ils avaient l'accord, de deux, ils n'ont pas besoin de trois ou quatre mois pour préparer un patch, 2h en l'occurrence pour adapter le patch fourni, donc c'est pas comme si ça va changer grand chose, et de trois, attendre presque deux mois après que CERT et donc les agences gouvernementales soient au courant, ça montre un peu les limites de ce genre d'embargo à rallonge : de quoi laisser largement le temps à ceux qui voudraient en profiter parmi les nombreux acteurs au courant. Trois mois (ou plus pour certains en fait), c'est pour les gros vendeurs, en particulier les négligents et paresseux, et pour assurer la médiatisation, ça n'a pas grand chose à voir avec la sécurité.

C'est bien ce que je dis, on n'a visiblement pas droit au moindre faux pas : je ne suis pas en train de dire qu'il faut trouver le journal pertinent. Le précédent journal de l'auteur du journal date visiblement d'il y a trois ans : c'est pas comme s'il s'agissait de réprimander un contributeur turbulent. Un petit commentaire bon enfant pour dire, youhou, t'as raté le réveil, ça date d'il y a deux semaines, et pis c'est la mort, les BSDs aussi sont affectés, mais t'inquiète c'est pas si grave, c'est suffisant et plus contributeur-friendly, je trouve :)

Et puis j'ai l'impression que la note du journal a fait des hauts et des bas, donc peut-être qu'il n'a pas été si inutile que ça et que certains qui avaient raté le précédent, assez éloigné, ont appris la nouvelle maintenant :)

Bref, ça s'offusque un peu vite pour pas grand chose parfois par ici, un peu d'optimisme ! ;)

le ton alarmant de ton journal est pas vraiment justifié.

En défense du journal, je dirais quand même que les sources officielles font aussi preuve d'un peu d'alarmisme, comme on peut en juger par la médiatisation de la chose. Ce qui explique aussi sans doute pourquoi c'est pas si surprenant qu'on se retrouve avec un journal doublon, journal qui se fait à mon avis trop sévèrement moinser, ça arrive à tout le monde de rater un journal.

L'erreur, à mon avis, est de penser qu'il existe une quelconque logique permettant de mesurer le droit à plus ou moins d'aisance d'une personne de façon éthique. Les mesures en termes de diplômes, productivité/rentabilité, etc. sont totalement dépendantes d'une situation et système économiques donnés, et n'ont rien à voir avec l'éthique, donc dire que tel ou tel autre devrait être mieux payé n'a pas de sens. Parce que si on prend les choses d'un point de vue éthique, mais là on part dans l'imaginaire, je pense qu'on va pas tous être d'accord ; par exemple, pour moi, le seul point important, ce serait la qualité d'être humain, pas les diplômes, l'âge, les qualifications, la rentabilité ou autres détails bureaucratiques.

C'était plus une remarque que les inégalités sociales sont bien représentées en recherche également, avec des variations significatives autour du salaire médian (de 1700 et quelques, il me semble), allant de proche du RSA (stagiaires), à une partie significative de chercheurs dans le 10% des plus riches (tous ceux qui sont à un peu plus de trois mille, donc probablement au moins tous les chercheurs avec statut de directeur de recherche ou professeur). Je n'avais pas l'intention de commenter sur le fait que ce soit plus ou moins juste par rapport à d'autres domaines.

Mon bureau n'a pas été rafraîchi depuis 30 ans… trous dans les murs, sales, sans parler de l'eau qui s'infiltre les jours de pluie. Et je ne suis pas sous les toits :s Les fenêtres ne se ferment pas totalement, il y a des courants d'air… Je ne sais pas où sont les moyens pour avoir de nouveaux bâtiments. Je ne suis jamais allé dans des hôtels 4 ou 5 étoiles.

J'imagine bien que ça doit dépendre des confs et des labos. C'est probablement un traumatisme personnel, je ne me suis toujours pas remis de la conf dans un hôtel de 5 étoiles, où pour dormir on avait le choix (à faire dans l'inscription) entre l'hôtel 5 étoiles de la conf et un hôtel de 4 étoiles à côté, j'ai choisi le 4 étoiles et quelle n'a pas été ma surprise de me retrouver avec une suite qui était plus grande que mon appartement à moi ! o_O Et rien qu'en rentrant dans l'hôtel 5 étoiles, avec une file de taxis devant et je sais plus quoi d'autre, j'avais plus envie de me retrouver n'importe où sauf là, tellement je me sentais ridicule et pas à ma place, et si j'avais pas eu à présenter moi-même un papier, je ne sais pas si je serais resté.

En tant que doctorant, quand je vois le temps que les chercheurs titulaires perdent à faire des démarches pour obtenir des financements ou autres paperasses, plutôt que de faire de la recherche, ça enlève un peu l'envie de continuer dans cette voie.

Et pour ce qui est de la propriété intellectuelle, j'ai l'impression que c'est le flou total sur ce qu'on a le droit de faire et ce qui se fait en pratique. Par exemple, pour les publications, j'ai toujours pas compris comment ça se fait qu'on donne nos droits à des entités tierces pour les conférences sans démarche particulière (alors qu'ils appartiennent à l'employeur, les droits, j'imagine), et qu'on se permet quand même de mettre les choses par exemple sur HAL après, ou son site web.

Et quand je vois que pour fournir des macs et autres joyeusetés, rénovations diverses, hôtels quatre ou cinq étoiles pour les confs, etc. il y a par contre visiblement de l'argent plus facilement que pour d'autres choses… ou encore quand je vois les inégalités sociales, allant du stagiaire qui est payé presque moins que rien au professeur au grade je sais pas quoi qui atteindra les quatre voire cinq mille euros par mois, je me dis que c'est quand même pas beaucoup plus rose qu'ailleurs, la recherche, et que les économies se font pas au bon endroit ni de façon à préserver le temps de recherche :(

Je sais pas, c'est quelque chose sur quoi ce serait intéressant d'avoir des stats : suivant le type d'application, quel pourcentage de code (ou autre façon plus pertinente de mesurer l'impact) cela représente, soit par redondance (technique on réinvente la roue/copie-colle), soit à la Python (technique assertion de type), ou génération (à la lex/yacc), sachant qu'on dispose quand même d'un minimum de généricité ad hoc et d'interfaces.

Avant de programmer en Go, j'aurais dit, beaucoup (où sont mon fold, map, filter ?). Maintenant, je dirais pas vraiment significatif quand on voit le programme dans son ensemble, mais je me risquerais pas à généraliser mes cas d'usages particuliers, surtout que je dois avoir écrit à peine une quinzaine de milliers de lignes de code dans ce langage, pas beaucoup, donc mon évaluation est tout autant subjective, probablement :)

L'argument sur le nombre d'occurrences de type-switches n'est pas très convaincant

Non, c'est juste pour relativiser un peu, et ça dit quand même qu'en pratique le nombre de fois où on perd l'information de types est peut-être pas énorme, qu'on aille pas croire qu'en Go on a les mêmes garanties statiques qu'en Python :)

il suffit que quelques bibliothèques de base l'adoptent en interne, et tout le code qui s'en sert a perdu l'information de typage entre ce qui entre dans ces bibliothèques et ce qui en sort.

Statiquement, oui, mais à supposer qu'il n'y a pas de bugs dans les bibliothèques de base, cloisonner la chose avec des fonctions safe, par exemple pour utiliser la structure générique de tas :

func (pq *PriorityQueue) SafePush(item *Item) {
        heap.Push(pq, item)
}

func (pq *PriorityQueue) SafePop() *Item {
        return heap.Pop(pq).(*Item)
}

limite quand même pas mal les dégâts si on va s'en servir souvent, au prix d'une légère verbosité avant première utilisation.

Ce qui va probablement se passer, à court ou moyen terme, puisque c'est une propriété de la généricité d'être plus utile dans les bibliothèques de base (ou alors on s'en passe et le code devient plus lourd, plus redondant).

La philosophie du langage, c'est quand même d'encourager l'utilisation des tableaux dynamiques et tables de hachage avec généricité ad hoc, en s'inspirant de ce que font souvent les langages dynamiques. On fait quand même beaucoup avec, mais c'est pas adapté à tous les programmes. Si une bonne partie du programme est dédiée à utiliser diverses structures génériques moins courantes, Go n'est sans doute pas le bon choix. Normalement, on voit quand même venir le mur à temps :) Après, que des gens soient fâchés d'utiliser Go alors que ce n'est pas adapté parce que le boss dit que, ça, ça peut devenir triste, ça arrive sans doute déjà, mais c'est une autre histoire, et c'est pas nouveau.

J'ai jamais fait de test pour vérifier moi-même, mais pour go 1.8 ils annoncaient moins de 1ms, et souvent moins de 100μs pour les pauses, 10ms c'était pour go 1.5 (la première version à avoir un Gc concurrent, il me semble, même s'il faisait des stop the world pour le rescan encore). Ce qui est intéressant, c'est que le fil montre aussi que ça a des implications sur les performances totales (ils disent 2% de CPU au total en plus sur leur exemple à la fin, mais 20% en relatif, pas très bien compris par rapport à quoi).

Un Gc doit normalement faire une pause lorsqu'il fait le ménage : optimiser pour la latence signifie assurer que ces pauses sont courtes ; c'est utile si l'on a besoin d'une application qui soit en état de répondre à de nouvelles requêtes à chaque instant (je sais pas, par exemple un serveur qui doit gérer tout plein de requêtes et être réactif), ou qui ne gêle jamais (intéressant pour les jeux 3D, même si Go est pas vraiment utilisé pour ça actuellement).

Cependant, parfois, réduire le temps des pauses peut entrer en conflit avec la performance en temps d'exécution total de l'application, au sens, au final l'application fera juste plus de petites pauses, le pourquoi du comment se trouvant dans le détail des algos, mais comme je suis pas spécialiste, je me risquerai pas à en dire plus :)

C'est pas vraiment le void * de C. En soi, utiliser interface{} est type-safe : ce qui n'est pas type-safe (au sens crash à la Python, pas au sens tu as carte blanche pour faire n'importe quoi comme en C), c'est l'assertion de type qui accompagne souvent les utilisations de interface{} côté utilisateur lors de l'utilisation d'un conteneur générique.

Notons que, dans ces cas là, au prix d'un peu de verbosité, il est facile d'isoler ces assertions en faisant un wrapper des fonctions de la librairie qui n'utilise pas interface{}, ce qui en pratique mitige quand même pas mal les risques d'erreur.

D'autant plus qu'à la base, ça représente déjà quand même pas grand chose comme proportion du code : je viens de faire un grep sur un de mes projets et les assertions de type ou switch sur des types représentent 0.1% du code (une ligne sur mille), c'est peut-être pas représentatif d'autres projets, mais peut-être même en pire, parce que j'ai pas fait particulièrement d'efforts pour réduire leur nombre : je me rends compte qu'en utilisant la méthode du wrapper je pourrais diviser leur nombre par à peu près deux.

Bref, le méchant interface{} est à relativiser grandement : je pense qu'un projet quelconque Haskell ou OCaml a bien plus de 0.1% de code utilisant des exceptions (ou autre code sensible) à vérifier avec tout autant d'attention.

Ok, je pense avoir à peu près tout compris, merci pour ces explications limpides !

Dans la discussion reddit, quelqu'un pose la question évidente quand on sait ce qu'est un type somme, et qui résoud les faux-problèmes mentionnés ici:

indil7: Why not model types like in Haskell, with sum/algebraic types and interfaces as just types, not values that can be inspected at runtime for the real type? Those are orthogonal ideas, and they reduce errors by keeping you from breaking the interface abstraction.

J'ai repensé après coup à ça, sur le moment acceptant ceci sans problèmes (rust fait ça avec ses traits), mais, que faire de la reflection si les interfaces ne sont plus des valeurs ? Ça semble être utile pour des choses comme un Marshall type-safe automatique d'une structure quelconque ou avec quelques restrictions (donc pas comme celui d'OCaml, qui n'est pas type-safe à la lecture) : je serais intéressé de savoir s'il y a des alternatives sans réflection, à la rigueur à coup de deriving semi-automatisé.

Visiblement, pour les auteurs et l'échantillon considéré, entre typer et faire de la prose, le choix est vite fait :) (O.K., je trolle, c'est vendredi …)

À un moment, en faisant du Perl et du Tcl, surpris par leurs documentations très exhubérantes (même trop pour Perl parfois), je m'étais fait la réflexion presque inverse : dans un langage totalement dynamique, les développeurs ressentent peut-être plus l'urgence de la documentation et des exemples, parce que n'ayant même pas d'outil extrayant des signatures automatiques pour les fonctions, même pas le nombre et les noms des arguments, ils ne sont jamais tentés de laisser quelque chose implicite à intuiter à partir d'une signature. En pratique, dans le pire des cas, c'est bien sûr pas d'exemples ni de signatures :)

Je n'ai pas convenablement lu la thèse, ne pourrai donc en faire un juste résumé et place la référence ici comme un bookmark contextualisé (à mon usage). Peut-être qu'en y creusant, tu trouveras des pistes quant à ton questionnement.

Merci pour le pointeur ! Il y a peut-être en effet de la matière à lire sur le sujet :)

La voie des tutoriels, conférences, et autres postes de blogs me paraît être la bonne dans ce cas.

Je sais bien que c'est celle qui est souvent choisie en Haskell, et c'est peut-être juste une question d'habitude et un lien au point d'entrée de la doc de référence vers un de ces tutoriels ferait l'affaire.

Ceci dit, il y a des contre-exemples de bibliothèques implémentant des concepts généralistes mais dont la doc est bourrée d'exemples pour quelques restrictions d'applications ; voir par exemple la fameuse lens.

Faudrait que je lise ça sérieusement un jour. J'avoue avoir utilisé une fois seulement les lens un tout petit peu avec un des framework web Haskell : j'avais commencé par faire du simple copié-collé d'un exemple qu'ils avaient sans comprendre exactement les agencements et, comme je voulais avoir un résultat vite, pas le temps d'apprendre, j'avais finalement recodé le truc vite-fait en Perl (de quoi faire peur à certains ^^), et c'est toujours ça qui tourne sans grands changements depuis :)

C'est un peu lié à ce qu'on dit juste avant : quand on approche le concept avec la volonté d'apprendre, la lecture de tutoriels est une expérience très positive, mais quand on a un besoin un peu urgent, c'est facile de perdre patience en lisant en diagonale ce type de ressource pédagogique, plus adapté pour une lecture tranquille.

Et n'oublions pas que c'est du logiciel libre : je ne doute pas que tu as les compétences nécessaires pour rédiger un patch de la documentation que tu as potassée ; pourquoi ne pas contribuer ?

Parce que je fais d'autres choses aussi, qu'Haskell est plus très frais dans ma mémoire et que mon temps libre est limité, donc je me contente de faire du retour d'expérience, c'est pas beaucoup, mais mieux que rien peut-être :)

D'ailleurs, quand je critique la doc, je fais pas vraiment un reproche, mais plutôt une remarque sur le fait que toutes les communautés n'ont pas la même approche à ce niveau et que c'est probablement un point à étudier d'un point de vue humain avec ses éventuels liens avec le langage en soi. C'est un sujet sur lequel j'aimerais bien savoir s'il y a une quelconque recherche sérieuse : l'influence du langage sur la communauté (style de la doc, outils, etc.) et les moyens de contrôler ça. Pas évident.

Pour maximiser le sous-hors-sujet Haskell dans un déjà hors-sujet Go

Ça part un peu dans tous les sens, mais c'est pas si mal d'avoir des exemples concrets pour alimenter la réflexion, même si ça part plus dans l'humain/les outils et leur interaction pas évidente avec le langage en soi :)

à propos des opérateurs qui seraient horribles comme tu l'écrivais ailleurs dans les commentaires

Je sais pas si c'était moi, ça, je me souviens juste avoir mentionné la prolifération des pragmas, mais je commence à m'y perdre un peu dans mes propres commentaires dans ce fil :)

Ah, oui, là, tout à fait, ce n'est pas quelque chose d'intrinsèque au langage, c'était plus une remarque que, visiblement, quand un langage est très expressif, la tentation de faire complexe semble grande et qu'il faudrait, je sais pas, tout un mouvement communautaire avec une vision bien définie pour proposer des approches alternatives moins puissantes et plus accessibles. L'approche Haskell c'est plutôt de faire des tutos de vulgarisation, mais à mon avis, bien qu'utile, c'est pas suffisant : c'est les bibliothèques elles-mêmes qu'il faudrait vulgariser sans honte (après, en Haskell, des choses comme monade IO vs ST, ou Strict vs Lazy, je sais pas comment les éviter).

Par contre ça a un impact important sur la flexibilité du mécanisme, son ergonomie à l'usage et sa modularité

C'est un point intéressant, oui, mais tu as raison, la différence n'est pas très visible ni importante au premier abord.

Je pense que le paquet transformers est ce à quoi je pensais, même si j'ai pas mal oublié, donc un peu oublié si c'était inclus avec GHC (mais c'est un paquet à part, c'est pas dans base, je dirais). Après, je viens de regarder la doc, pour vérifier, et après plusieurs années sans faire de Haskell, je t'assure que tu mets un moment à te dire, ah oui, ça y est je comprends, parce que Reader et Writer sont carrément dans des modules différents (deux pour Writer, versions strictes et lazy) au milieu d'un tas d'autres, avec zéro exemples pour Reader et Writer, donc le nombre de fonctions plus de détails techniques liés au monades et compagnie accompagné de zéro exemples est déroutant pour moi ; imagine pour un débutant après quelques jours… J'aurais osé espérer qu'après plusieurs années ce genre de choses (en particulier la doc) s'améliorerait, là j'ai un peu peur :)