Le monde actuel, ça n'est pas un paradis, mais c'est probablement le monde le plus sûr, en moyenne, que l'humanité n'ait jamais connu.
Honnêtement, au niveau mondial ce n'est pas exact (source) : la période 1950-2000, c'est de l'ordre des taux de morts dans les siècles 1400-1600, malgré l'explosion démographique énorme à certains endroits qui contribue grandement à faire diminuer les taux. Et le graphique en question s'arrête en 2000 et ne compte pas les cinq ou six millions de morts de la guerre du Congo.
Si on veut vraiment voir le côté positif, c'est que ça pourrait être encore pire, car au moins aujourd'hui il y a moins de morts du fait de famines et maladies, grâce aux avancées technologiques — par exemple, des déplacements de populations de plusieurs millions de personnes, comme pour la Syrie, auraient été probablement accompagnés de plus de famines et maladies il y a quelques centaines d'années.
Je ne savais pas que sur certains systèmes, cette fonctionnalité étaient absente.
La plupart des OS passent par procfs, mais pas tous, d'autres ont un syscall. Sur OpenBSD il n'y a ni l'un ni l'autre, même si il y a un moyen détourné d'y arriver : par exemple en Go ils récupèrent le dossier courant en début d'exécution, puis déduisent ensuite le chemin de l'exécutable à partir du premier argument du programme et suivant les cas déterminent s'il faut aller jusqu'à chercher dans $PATH (juste le nom de la commande, auquel cas c'est plus forcément fiable si l'environnement a changé) ou non (chemin complet ou relatif, auquel cas c'est fiable).
Les millénaires passés n'ont accouchés d'aucune grandes communautés sans tout le fourbi social : loi, taxes, etc. Je ne trouve pas que c'est de la spéculation.
Un peu, au sens, ça n'a pas été testé à grande échelle depuis la révolution industrielle, du coup on ne sait pas si dans le monde actuel ça peut marcher, mais avant on peut considérer que les communautés agricoles étaient des tests décentralisés à échelle assez grande, même si dans les leçons d'Histoire on parle surtout des grands faits et gestes politiques des rois et seigneurs. Les lois, taxes, etc. ont souvent eu du mal à s'imposer et ça ne s'est pas toujours fait dans la douceur, car les paysans étaient attachés à leur vie collective. Il a fallu des siècles pour réussir à détruire les dernières communautés agricoles, leur faire payer des taxes, leur enlever le pouvoir de justice et, enfin, leur imposer la propriété privée (la révolution en France, par exemple). Peut-être que c'est l'évolution naturelle des civilisations humaines, mais la société individualiste actuelle est un phénomène relativement récent, donc conclure sur la base de deux-trois siècles, c'est pas évident, surtout avec la mondialisation actuelle qui fait un peu effet boule de neige et rend difficile la construction d'une société différente au sein du système globalisé.
J'ai vaguement en mémoire qu'à partir du moment où chaque personne ne connais pas plus de 66 % des individus de la communauté, les violences sont inévitables s'il n'y a pas une sorte d'autorité pour gérer cet aspect.
Organisation décentralisée collective ne veut pas dire absence d'autorité, juste absence d'autorité administrative centralisée.
Moi ce qui me chagrine là dedans, c'est le vide après «Base path». Mais bon, sur un système Unix, ce n'est pas très grave.
Sur OpenBSD il n'est en effet pas possible d'avoir accès au répertoire du binaire exécuté, du coup en général les packageurs patchent si nécessaire avec un chemin en dur.
Et je suis très satisfait de savoir que sous OpenBSD, ça compile et ça fonctionne correctement.
Ça m'encourage aussi à penser qu'il y a probablement pas trop de bugs du genre buffer overflow — des logiciels qui tournent “normalement” sous Linux ont tendance à faire segfault sous OpenBSD du fait des protections mémoire du noyau (c'est le genre de trucs qui m'arrive parfois, par exemple à un moment une version d'inkscape était inutilisable sous OpenBSD).
Et voilà le gf_info !
Le seul truc qui m'a fait bugguer, c'est le Platform: Linux, mais j'ai découvert qu'en fait c'est normal :
modify SDL_GetPlatform to pretend we are Linux which allows FNA based games to run before the upstreamed change trickles down to released games
Du coup, j'ai trouvé. La version de zlib utilisée par OpenBSD est un peu trop vieille (version 1.2.3).
Ah là là, c'est vraiment pas évident d'être portable ! Ceci dit, d'habitude j'ai souvent bien plus de problèmes lorsque j'essaie de compiler des jeux sous OpenBSD qui sont pas dans les ports, gf s'en sort plutôt bien :)
Moi je parie qu'il y a aussi des vieux idéalistes, et tout un tas de jeunes anti-idéalistes aussi :)
On reparlera de tout ça à la première récolte ruinée par une mauvaise météo.
Dans l'environnement étatique actuel, ils vont sans doute avoir du mal à faire des alliances avec des copains ailleurs, donc c'est pas (du tout) gagné, en effet.
Encore une très grosse concession. Imagine le risque qu'ils prennent: si leur mode de vie est massivement adopté, qui s'occupera de tous les services publiques dont ils dépendent comme l'a souligné Zenitram?
Si je devais parier aussi, je dirais les mêmes personnes qui s'en occupent aujourd'hui, moins quelques personnes dégoûtées par leur métier actuel, plus quelques-uns qui trouvent leur vocation sans devoir passer par une administration qui les avait freinés précédemment.
Par contre j'arrive à entendre qu'ils exprime un besoin de conflit (sinon ils iraient squatter ailleurs, mais ailleurs il n'y a pas de conflit on les laisserai tranquilles), tout en récupérant le RSA ("autonome", mais bon avec l'argent des autres).
En attendant d'avoir le droit d'être libérés de l'État, autant qu'ils fassent valoir leurs droits :)
La partie sur le passage à l'échelle est importante
Sans doute, mais tes arguments sont essentiellement de la spéculation, ce n'est pas évident d'avoir quelque chose qui ressemble à une preuve à ce sujet, on manque trop d'expérimentation. Des communautés agricoles (pas forcément homogène politiquement a priori) ont par exemple existé jusqu'à la révolution française — au cours des siècles elles ont peu à peu perdu des pouvoirs au profit d'un seigneur ou d'un roi, jusqu'à les perdre totalement au profit de l'État, mais ces idées n'ont vraiment rien de nouveau et on retrouve des exemples jusqu'au moyen âge et sans doute bien avant — contrairement à ce que pourrait laisser penser le journal, d'ailleurs, qui présente un peu tout ceci comme une nouveauté sans précédents :)
Voilà, j'ai testé tous les jeux :) J'ai pas trop d'expérience en C++, mais j'aime bien les jeux 2D donc ça fait plaisir de voir des bibliothèques libres et qui plus est ça a l'air solide et pas gourmant en ressources.
Juste deux petits soucis lors de la compilation (sous OpenBSD, clang 5.0.1), je ne saurais pas dire exactement pourquoi vu mon manque d'expérience en C++.
Je pense que personne ne voulait faire référence aux dépendances directes, mais bien aux dépendances vers des paquets Haskell (directes ou indirectes, sans compter les paquets standard qui viennent avec GHC), qui sont au moins au nombre de cent.
Mais c'est plus une observation qu'une critique en ce qui me concerne, au sens, si un jour Haskell devient très populaire et tous les OS disposent de suffisamment de main d'œuvre pour assurer un support de base fiable de tous ces paquets, ça deviendra raisonnable pour plus de monde, comme pour d'autres logiciels connus en C/C++/Python/… tout sauf minimalistes et avec beaucoup de dépendances. En attendant, il faut juste être conscient que dépendre de pandoc est un choix personnel, dans le sens où ça ne me surprendrait pas que sur un OS ou distrib donnée, des difficultés empêchent occasionnellement d'utiliser le logiciel pendant plusieurs semaines/mois/années — si j'ai fui pandoc il y a déjà quelques années, c'était en partie parce que je me suis justement retrouvé à ne pas réussir à le compiler sous OpenBSD à un moment donné et que je n'ai pas suffisamment l'âme d'un packageur pour y passer des heures et des heures.
Vu la quantité de formats que supporte Pandoc et sans parler des extensions (à la fois celles mentionnées dans la dépêche et celles-ci), il n'est pas étonnant d'avoir des dizaines de paquets comme dépendances.
En effet, ce n'est pas étonnant, il s'agit plutôt d'un choix, typique pour des logiciels dans des langages comme Haskell/Python/Perl/Javascript : priorité à intégrer un maximum de fonctionnalités en réutilisant ce qui est fait ailleurs (même de tous petits paquets), même si ça explose le nombre de dépendances. Ça a du bon comme du mauvais.
Pandoc est en effet devenu assez impressionnant avec le temps et extrêmement complet pour transformer entre langages de balisage légers et de là vers d'autres formats. L'auteur du logiciel est d'ailleurs, me semble-t-il, la personne la plus impliquée dans l'effort de standardisation de Common Mark (même si pandoc offre par défaut beaucoup d'extensions sur celui-ci, plus que toute autre implémentation du langage).
La lecture de formats plus complexes comme LaTeX n'est pas contre pas très fiable (même si ça s'améliore avec le temps j'imagine), ni bien définie : il faut vérifier le résultat à la main et ajuster le LaTeX pour rester dans le sous-ensemble géré — ce qui n'est pas évident, car ce n'est pas quelque chose de bien défini (définir de façon concise un sous-ensemble de LaTeX, c'est peine perdue) et qui pourra difficilement devenir complet, vu que le langage utilisé en interne est (et doit être) beaucoup plus pauvre que LaTeX.
Dans les points qui me chagrinent un peu dans ce logiciel, c'est qu'il est assez lent (pas gênant pour de petits documents ou si on va exécuter LaTeX de toutes façons après), et surtout le nombre de dépendances (exagéré même selon les standards Haskell, autour de 100 !), qui fait que je ne me risquerais pas à dépendre de ce logiciel pour un truc important que je voudrais pérenne.
Plus compact, je veux bien — et encore, pas tant que ça dès que la fonction anonyme à appliquer n'est pas triviale et ne tient pas sur une ligne.
Plus lisible, honnêtement, je suis mitigé là-dessus. D'un point de vue scientifique, la lisibilité me semble être un sujet pas évident : il ne s'agit pas de compter le nombre de caractères ou de lignes, mais la vitesse avec laquelle on les comprend, qui dépend de beaucoup de facteurs, entre autres individuels. Comme cas extrême, les langages style APL comme J permettent d'écrire des fold et des map de façon plus concise que OCaml ou Haskell, et se vantent d'être plus lisibles et productifs avec suffisamment d'entraînement. Certains allergiques au scroll vont jusqu'à essayer d'APLiser du C et soutenir qu'il s'agit là d'un style avec une longue courbe d'apprentissage mais plus lisible et moins propice aux erreurs avec de l'entraînement (si, si, il y en a qui soutiennent ça).
Personnellement, je suis assez sceptique — j'ai pas d'avis tranché, car pas assez d'habitude avec ces langages extrêmement concis pour les fonctions d'ordre supérieur (et encore, j'ai passé quand même pas mal d'heure à m'amuser avec, car c'est sympa de pouvoir écrire des algos non triviaux interactivement en repl). En vrai, j'ai quand même l'impression que pour un logiciel « normal » (disons où tout ne s'emboîte pas à coup de fold/map et avec 90% de logique simple), c'est même pas significativement plus court. Donc on met tous quelque part la barre pour un optimum de densité du code pour une meilleure lisibilité, est-ce que ça penche plutôt vers le fold/map d'OCaml ou un range de Go, ou du code à la J, je pense que ça dépend des gens, mais sauf besoin spécifique, je parie que plus de monde pencherait pour un simple range à la Go (perso, je saurais pas trop dire).
S'il s'agissait de C j'aurais tendance à penser pareil, mais les map ou fold sur des listes deviennent des itérations avec range sur un tableau en Go, donc ça évite les soucis typiques des boucles, ça demande juste d'introduire explicitement la variable ou le tableau où on construit un nouveau résultat, donc c'est juste plus verbeux, avec l'avantage que la même construction sert à faire map et fold, et qu'il n'y a pas à se souvenir que c'est fold_left qu'il faut faire et pas fold_right, ni se rappeler (ou demander à merlin) l'ordre des arguments pas forcément intuitif (l'inverse entre OCaml et Coq, par exemple). Pour les types somme, je suis assez d'accord, mais c'est pas intrinsèquement fonctionnel comme truc, je dirais.
La seule construction que je ne vois pas comment réaliser à la fois efficacement et de façon commode dans un langage impératif un peu haut-niveau, c'est la récursivité terminale entre fonctions mutuellement récursives (comme truc approchant, je vois que le retour de pointeur vers une fonction, qui a le défaut de faire des sauts calculés non prévisibles).
Autant je suis d'accord que les langages fonctionnels sont souvent très pratiques pour manipuler des structures de données non mutables (comme les arbres), autant je trouve que le résumé sur le « style impératif » est un peu simpliste : sur beaucoup d'algorithmes, boucle while avec variables locales ou récursivité terminale, c'est à peu près équivalent pour relecture et maintenance (de ce point de vue, la récursivité terminale, c'est juste une espèce de boucle while avec potentiellement des returns prématurés).
Et la partie sur les performances, le « efficacité d'exécution comparable, … voire un peu supérieure », est un peu simpliste aussi : sur certains algorithmes, la possibilité de les faire en place et en évitant des allocations mémoire inutiles (donc en utilisant la partie impérative du langage), change beaucoup les performances, rester dans le fonctionnel pur ça coûte cher. Le pdf d'état des lieux dit que « L'usage de traits impératifs peut se justifier dans certains cas », mais ils donnent comme exemple le fait d'éviter de passer un argument en paramètre à toutes les fonctions, qui me semble pour le coup évitable (rien n'empêche d'utiliser un record pour ne pas avoir une prolifération du nombre d'arguments).
Un truc qui serait intéressant, du coup, ce serait d'évaluer l'intelligence d'un tel algo en lui laissant s'entraîner que sur un nombre de parties correspondant au nombre de parties jouées par un joueur humain. S'il perd, c'est qu'il est plus bête, au sens, il a besoin de s'entraîner sur plus de parties. Après, c'est sûr, d'un point de vue pratique une telle comparaison est artificielle, vu que la machine peut se permettre de s'entraîner plus, car plus rapide.
fzf a plus de fonctionnalités, dont le support Unicode (ou alors fzy a un bug chez moi), et j'ai remarqué à l'utilisation que fzy attend de recevoir toute l'entrée, alors qu'avec fzf on peut commencer à taper le motif et ça filtre au fur et à mesure que l'entrée se complète, ce qui peut se faire sentir dans des cas comme locate / | fzy (cas un peu limite, mais bon).
il est plus surprenant de ne pas retrouver d'outils en Go, en D, en OCaml ou en Haskell.
Le platinium searcher que tu cites (pt), est en fait écrit en Go. Il y a aussi sift en Go. En C++ il y a ucg, mais j'ai pas testé, et il y en a d'autres. Après, c'est possible en effet que ripgrep soit le plus avancé de tous ces projets, en tous cas l'auteur semble étudier la chose à fond.
Deux petites chaînes de caractères, je pense que ça rentre dans le droit de citation ou quelque chose comme ça. Et de toutes façon, ça m'a l'air fort : j'imagine un cas analogue où un langage de programmation renvoit un certain message d'erreur dans certains cas, est-ce que différentes implémentations du langage (avec licences incompatibles) peuvent utiliser le même message d'erreur ?
Sinon la plupart des journaux sont illégaux vus qu'ils disent publier le code sous CC-BY-SA et pas sous GPLv3 :)
PS : En passant, je publie les miens aussi sous license ISC ou CC0, en plus de CC-BY-SA, au choix (même si j'ai du mal à considérer qu'on puisse mettre une licence sur si peu de code).
Avec tous ces caractères Unicode j'ai l'impression de jouer à Dwarf Fortress ;-)
Maintenant que tu le dis, ça me fait penser à Brogue :)
Au passage, il y a quelques phrases marrantes sur la page Wikipédia à la rubrique Quelques_opinions.
Celle de Dijkstra est marrante, mais c'est pas trop surprenant venant de lui, il avait l'habitude de sortir des phrases comme ça sur tout et n'importe quoi. Entre autres, il y a aussi FORTRAN, Cobol, la programmation objets, etc. qui prennent cher :)
Disons que pour Meltdown, le débit de fuite c'est jusqu'à 500KB/s, c'est-à-dire beaucoup et c'est en partie là le problème qui rend la vulnérabilité vraiment pratique. Pour Spectre c'est moins, je me souviens plus exactement, quelque chose comme 10 fois moins je crois (ce qui n'est pas négligeable non plus).
Oui, enfin, “late December” pour un embargo de six mois, qui a en plus été écourté d'une semaine à la fin suite aux déductions de la communauté par rapport aux patches appliqués dans Linux (qui même sans le patch bavard du gars d'AMD étaient très curieux pour une rc6), c'est pas vraiment être prévenu, ils en sont au même stade que les autres (voire en retard par rapport à DragonFly).
Les autres BSDs n'ont pas été prévenus non plus (ou juste un peu avant) aussi, on dirait, donc cela semble ne pas être lié à une quelconque philosophie vis-à-vis des embargos. Dragonfly semble avoir patché déjà, mais pas dans -stable, uniquement dans la branche de développement, mais la vitesse de réaction est impressionante.
Ceci dit, au moins maintenant on est conscients de la faille, ce qui permet de savoir quels genre de services sont particulièrement risqués et à désactiver si possible (grosso modo, n'importe quoi qui permette d'exécuter à un tiers du code en tant qu'utilisateur local du système ou dans une vm).
Il est intéressant, mais pas surprenant (divulguer plus largement est un risque), de voir que pour des failles moins critiques, avec des embargos plus courts, la plupart des BSDs, ainsi que beaucoup de distros sont mis au courant, alors que pour une faille de ce type avec 6 mois d'embargo uniquement Linux, Mac OS et Windows reçoient une alerte bien à l'avance.
[^] # Re: bitcoin
Posté par anaseto . En réponse au journal Solution au conflit de la ZAD de Notre-Dame-des-Landes. Évalué à 5.
Honnêtement, au niveau mondial ce n'est pas exact (source) : la période 1950-2000, c'est de l'ordre des taux de morts dans les siècles 1400-1600, malgré l'explosion démographique énorme à certains endroits qui contribue grandement à faire diminuer les taux. Et le graphique en question s'arrête en 2000 et ne compte pas les cinq ou six millions de morts de la guerre du Congo.
Si on veut vraiment voir le côté positif, c'est que ça pourrait être encore pire, car au moins aujourd'hui il y a moins de morts du fait de famines et maladies, grâce aux avancées technologiques — par exemple, des déplacements de populations de plusieurs millions de personnes, comme pour la Syrie, auraient été probablement accompagnés de plus de famines et maladies il y a quelques centaines d'années.
[^] # Re: Testé tous les jeux :)
Posté par anaseto . En réponse au journal Gamedev Framework 0.7.0 et 0.8.0. Évalué à 3. Dernière modification le 25 avril 2018 à 12:16.
La plupart des OS passent par procfs, mais pas tous, d'autres ont un syscall. Sur OpenBSD il n'y a ni l'un ni l'autre, même si il y a un moyen détourné d'y arriver : par exemple en Go ils récupèrent le dossier courant en début d'exécution, puis déduisent ensuite le chemin de l'exécutable à partir du premier argument du programme et suivant les cas déterminent s'il faut aller jusqu'à chercher dans
$PATH(juste le nom de la commande, auquel cas c'est plus forcément fiable si l'environnement a changé) ou non (chemin complet ou relatif, auquel cas c'est fiable).[^] # Re: Tant que tout va bien
Posté par anaseto . En réponse au journal Solution au conflit de la ZAD de Notre-Dame-des-Landes. Évalué à 0.
Un peu, au sens, ça n'a pas été testé à grande échelle depuis la révolution industrielle, du coup on ne sait pas si dans le monde actuel ça peut marcher, mais avant on peut considérer que les communautés agricoles étaient des tests décentralisés à échelle assez grande, même si dans les leçons d'Histoire on parle surtout des grands faits et gestes politiques des rois et seigneurs. Les lois, taxes, etc. ont souvent eu du mal à s'imposer et ça ne s'est pas toujours fait dans la douceur, car les paysans étaient attachés à leur vie collective. Il a fallu des siècles pour réussir à détruire les dernières communautés agricoles, leur faire payer des taxes, leur enlever le pouvoir de justice et, enfin, leur imposer la propriété privée (la révolution en France, par exemple). Peut-être que c'est l'évolution naturelle des civilisations humaines, mais la société individualiste actuelle est un phénomène relativement récent, donc conclure sur la base de deux-trois siècles, c'est pas évident, surtout avec la mondialisation actuelle qui fait un peu effet boule de neige et rend difficile la construction d'une société différente au sein du système globalisé.
Organisation décentralisée collective ne veut pas dire absence d'autorité, juste absence d'autorité administrative centralisée.
[^] # Re: Testé tous les jeux :)
Posté par anaseto . En réponse au journal Gamedev Framework 0.7.0 et 0.8.0. Évalué à 2.
Sur OpenBSD il n'est en effet pas possible d'avoir accès au répertoire du binaire exécuté, du coup en général les packageurs patchent si nécessaire avec un chemin en dur.
[^] # Re: Testé tous les jeux :)
Posté par anaseto . En réponse au journal Gamedev Framework 0.7.0 et 0.8.0. Évalué à 3.
Ça m'encourage aussi à penser qu'il y a probablement pas trop de bugs du genre buffer overflow — des logiciels qui tournent “normalement” sous Linux ont tendance à faire segfault sous OpenBSD du fait des protections mémoire du noyau (c'est le genre de trucs qui m'arrive parfois, par exemple à un moment une version d'inkscape était inutilisable sous OpenBSD).
Et voilà le
gf_info!Le seul truc qui m'a fait bugguer, c'est le
Platform: Linux, mais j'ai découvert qu'en fait c'est normal :[^] # Re: Testé tous les jeux :)
Posté par anaseto . En réponse au journal Gamedev Framework 0.7.0 et 0.8.0. Évalué à 3.
Ah là là, c'est vraiment pas évident d'être portable ! Ceci dit, d'habitude j'ai souvent bien plus de problèmes lorsque j'essaie de compiler des jeux sous OpenBSD qui sont pas dans les ports, gf s'en sort plutôt bien :)
[^] # Re: Contradictions
Posté par anaseto . En réponse au journal Solution au conflit de la ZAD de Notre-Dame-des-Landes. Évalué à 1.
Moi je parie qu'il y a aussi des vieux idéalistes, et tout un tas de jeunes anti-idéalistes aussi :)
Dans l'environnement étatique actuel, ils vont sans doute avoir du mal à faire des alliances avec des copains ailleurs, donc c'est pas (du tout) gagné, en effet.
Si je devais parier aussi, je dirais les mêmes personnes qui s'en occupent aujourd'hui, moins quelques personnes dégoûtées par leur métier actuel, plus quelques-uns qui trouvent leur vocation sans devoir passer par une administration qui les avait freinés précédemment.
[^] # Re: Ha l'utopie..
Posté par anaseto . En réponse au journal Solution au conflit de la ZAD de Notre-Dame-des-Landes. Évalué à 6.
En attendant d'avoir le droit d'être libérés de l'État, autant qu'ils fassent valoir leurs droits :)
[^] # Re: Tant que tout va bien
Posté par anaseto . En réponse au journal Solution au conflit de la ZAD de Notre-Dame-des-Landes. Évalué à 3.
Sans doute, mais tes arguments sont essentiellement de la spéculation, ce n'est pas évident d'avoir quelque chose qui ressemble à une preuve à ce sujet, on manque trop d'expérimentation. Des communautés agricoles (pas forcément homogène politiquement a priori) ont par exemple existé jusqu'à la révolution française — au cours des siècles elles ont peu à peu perdu des pouvoirs au profit d'un seigneur ou d'un roi, jusqu'à les perdre totalement au profit de l'État, mais ces idées n'ont vraiment rien de nouveau et on retrouve des exemples jusqu'au moyen âge et sans doute bien avant — contrairement à ce que pourrait laisser penser le journal, d'ailleurs, qui présente un peu tout ceci comme une nouveauté sans précédents :)
# Testé tous les jeux :)
Posté par anaseto . En réponse au journal Gamedev Framework 0.7.0 et 0.8.0. Évalué à 5.
Voilà, j'ai testé tous les jeux :) J'ai pas trop d'expérience en C++, mais j'aime bien les jeux 2D donc ça fait plaisir de voir des bibliothèques libres et qui plus est ça a l'air solide et pas gourmant en ressources.
Juste deux petits soucis lors de la compilation (sous OpenBSD, clang 5.0.1), je ne saurais pas dire exactement pourquoi vu mon manque d'expérience en C++.
Première erreur :
Pour cette première erreur, j'imagine que glibc doit inclure
<cstddef>dans un autre header de façon non standard.Deuxième erreur :
[^] # Re: Pandoc
Posté par anaseto . En réponse à la dépêche Trois outils pour développeur : MailHog, Tokei et Pandoc. Évalué à 4.
Je pense que personne ne voulait faire référence aux dépendances directes, mais bien aux dépendances vers des paquets Haskell (directes ou indirectes, sans compter les paquets standard qui viennent avec GHC), qui sont au moins au nombre de cent.
Mais c'est plus une observation qu'une critique en ce qui me concerne, au sens, si un jour Haskell devient très populaire et tous les OS disposent de suffisamment de main d'œuvre pour assurer un support de base fiable de tous ces paquets, ça deviendra raisonnable pour plus de monde, comme pour d'autres logiciels connus en C/C++/Python/… tout sauf minimalistes et avec beaucoup de dépendances. En attendant, il faut juste être conscient que dépendre de pandoc est un choix personnel, dans le sens où ça ne me surprendrait pas que sur un OS ou distrib donnée, des difficultés empêchent occasionnellement d'utiliser le logiciel pendant plusieurs semaines/mois/années — si j'ai fui pandoc il y a déjà quelques années, c'était en partie parce que je me suis justement retrouvé à ne pas réussir à le compiler sous OpenBSD à un moment donné et que je n'ai pas suffisamment l'âme d'un packageur pour y passer des heures et des heures.
En effet, ce n'est pas étonnant, il s'agit plutôt d'un choix, typique pour des logiciels dans des langages comme Haskell/Python/Perl/Javascript : priorité à intégrer un maximum de fonctionnalités en réutilisant ce qui est fait ailleurs (même de tous petits paquets), même si ça explose le nombre de dépendances. Ça a du bon comme du mauvais.
# Pandoc
Posté par anaseto . En réponse à la dépêche Trois outils pour développeur : MailHog, Tokei et Pandoc. Évalué à 7.
Pandoc est en effet devenu assez impressionnant avec le temps et extrêmement complet pour transformer entre langages de balisage légers et de là vers d'autres formats. L'auteur du logiciel est d'ailleurs, me semble-t-il, la personne la plus impliquée dans l'effort de standardisation de Common Mark (même si pandoc offre par défaut beaucoup d'extensions sur celui-ci, plus que toute autre implémentation du langage).
La lecture de formats plus complexes comme LaTeX n'est pas contre pas très fiable (même si ça s'améliore avec le temps j'imagine), ni bien définie : il faut vérifier le résultat à la main et ajuster le LaTeX pour rester dans le sous-ensemble géré — ce qui n'est pas évident, car ce n'est pas quelque chose de bien défini (définir de façon concise un sous-ensemble de LaTeX, c'est peine perdue) et qui pourra difficilement devenir complet, vu que le langage utilisé en interne est (et doit être) beaucoup plus pauvre que LaTeX.
Dans les points qui me chagrinent un peu dans ce logiciel, c'est qu'il est assez lent (pas gênant pour de petits documents ou si on va exécuter LaTeX de toutes façons après), et surtout le nombre de dépendances (exagéré même selon les standards Haskell, autour de 100 !), qui fait que je ne me risquerais pas à dépendre de ce logiciel pour un truc important que je voudrais pérenne.
[^] # Re: Fonctionnel vs Impératif
Posté par anaseto . En réponse au lien État des lieux des langages fonctionnels. Évalué à 2.
C'est pour ça que j'avais écris « de façon commode » :)
[^] # Re: Fonctionnel vs Impératif
Posté par anaseto . En réponse au lien État des lieux des langages fonctionnels. Évalué à 2.
Plus compact, je veux bien — et encore, pas tant que ça dès que la fonction anonyme à appliquer n'est pas triviale et ne tient pas sur une ligne.
Plus lisible, honnêtement, je suis mitigé là-dessus. D'un point de vue scientifique, la lisibilité me semble être un sujet pas évident : il ne s'agit pas de compter le nombre de caractères ou de lignes, mais la vitesse avec laquelle on les comprend, qui dépend de beaucoup de facteurs, entre autres individuels. Comme cas extrême, les langages style APL comme J permettent d'écrire des fold et des map de façon plus concise que OCaml ou Haskell, et se vantent d'être plus lisibles et productifs avec suffisamment d'entraînement. Certains allergiques au scroll vont jusqu'à essayer d'APLiser du C et soutenir qu'il s'agit là d'un style avec une longue courbe d'apprentissage mais plus lisible et moins propice aux erreurs avec de l'entraînement (si, si, il y en a qui soutiennent ça).
Personnellement, je suis assez sceptique — j'ai pas d'avis tranché, car pas assez d'habitude avec ces langages extrêmement concis pour les fonctions d'ordre supérieur (et encore, j'ai passé quand même pas mal d'heure à m'amuser avec, car c'est sympa de pouvoir écrire des algos non triviaux interactivement en repl). En vrai, j'ai quand même l'impression que pour un logiciel « normal » (disons où tout ne s'emboîte pas à coup de fold/map et avec 90% de logique simple), c'est même pas significativement plus court. Donc on met tous quelque part la barre pour un optimum de densité du code pour une meilleure lisibilité, est-ce que ça penche plutôt vers le fold/map d'OCaml ou un range de Go, ou du code à la J, je pense que ça dépend des gens, mais sauf besoin spécifique, je parie que plus de monde pencherait pour un simple range à la Go (perso, je saurais pas trop dire).
[^] # Re: Fonctionnel vs Impératif
Posté par anaseto . En réponse au lien État des lieux des langages fonctionnels. Évalué à 2.
S'il s'agissait de C j'aurais tendance à penser pareil, mais les map ou fold sur des listes deviennent des itérations avec
rangesur un tableau en Go, donc ça évite les soucis typiques des boucles, ça demande juste d'introduire explicitement la variable ou le tableau où on construit un nouveau résultat, donc c'est juste plus verbeux, avec l'avantage que la même construction sert à faire map et fold, et qu'il n'y a pas à se souvenir que c'estfold_leftqu'il faut faire et pasfold_right, ni se rappeler (ou demander à merlin) l'ordre des arguments pas forcément intuitif (l'inverse entre OCaml et Coq, par exemple). Pour les types somme, je suis assez d'accord, mais c'est pas intrinsèquement fonctionnel comme truc, je dirais.La seule construction que je ne vois pas comment réaliser à la fois efficacement et de façon commode dans un langage impératif un peu haut-niveau, c'est la récursivité terminale entre fonctions mutuellement récursives (comme truc approchant, je vois que le retour de pointeur vers une fonction, qui a le défaut de faire des sauts calculés non prévisibles).
# Fonctionnel vs Impératif
Posté par anaseto . En réponse au lien État des lieux des langages fonctionnels. Évalué à 4.
Autant je suis d'accord que les langages fonctionnels sont souvent très pratiques pour manipuler des structures de données non mutables (comme les arbres), autant je trouve que le résumé sur le « style impératif » est un peu simpliste : sur beaucoup d'algorithmes, boucle while avec variables locales ou récursivité terminale, c'est à peu près équivalent pour relecture et maintenance (de ce point de vue, la récursivité terminale, c'est juste une espèce de boucle while avec potentiellement des returns prématurés).
Et la partie sur les performances, le « efficacité d'exécution comparable, … voire un peu supérieure », est un peu simpliste aussi : sur certains algorithmes, la possibilité de les faire en place et en évitant des allocations mémoire inutiles (donc en utilisant la partie impérative du langage), change beaucoup les performances, rester dans le fonctionnel pur ça coûte cher. Le pdf d'état des lieux dit que « L'usage de traits impératifs peut se justifier dans certains cas », mais ils donnent comme exemple le fait d'éviter de passer un argument en paramètre à toutes les fonctions, qui me semble pour le coup évitable (rien n'empêche d'utiliser un record pour ne pas avoir une prolifération du nombre d'arguments).
[^] # Re: Bêtise naturelle
Posté par anaseto . En réponse au journal "Intelligence artificielle", vraiment?. Évalué à 3.
Un truc qui serait intéressant, du coup, ce serait d'évaluer l'intelligence d'un tel algo en lui laissant s'entraîner que sur un nombre de parties correspondant au nombre de parties jouées par un joueur humain. S'il perd, c'est qu'il est plus bête, au sens, il a besoin de s'entraîner sur plus de parties. Après, c'est sûr, d'un point de vue pratique une telle comparaison est artificielle, vu que la machine peut se permettre de s'entraîner plus, car plus rapide.
[^] # Re: fzf
Posté par anaseto . En réponse à la dépêche Des alternatives à grep, ls et find. Évalué à 3.
fzfa plus de fonctionnalités, dont le support Unicode (ou alorsfzya un bug chez moi), et j'ai remarqué à l'utilisation quefzyattend de recevoir toute l'entrée, alors qu'avecfzfon peut commencer à taper le motif et ça filtre au fur et à mesure que l'entrée se complète, ce qui peut se faire sentir dans des cas commelocate / | fzy(cas un peu limite, mais bon).# D'autres
Posté par anaseto . En réponse à la dépêche Des alternatives à grep, ls et find. Évalué à 9.
Le platinium searcher que tu cites (pt), est en fait écrit en Go. Il y a aussi sift en Go. En C++ il y a ucg, mais j'ai pas testé, et il y en a d'autres. Après, c'est possible en effet que ripgrep soit le plus avancé de tous ces projets, en tous cas l'auteur semble étudier la chose à fond.
[^] # Re: version awk
Posté par anaseto . En réponse au journal Le vrai problème avec toutes ces ré-implémentations de TapTempo c'est .... Évalué à 2. Dernière modification le 16 mars 2018 à 13:33.
Deux petites chaînes de caractères, je pense que ça rentre dans le droit de citation ou quelque chose comme ça. Et de toutes façon, ça m'a l'air fort : j'imagine un cas analogue où un langage de programmation renvoit un certain message d'erreur dans certains cas, est-ce que différentes implémentations du langage (avec licences incompatibles) peuvent utiliser le même message d'erreur ?
Sinon la plupart des journaux sont illégaux vus qu'ils disent publier le code sous CC-BY-SA et pas sous GPLv3 :)
PS : En passant, je publie les miens aussi sous license ISC ou CC0, en plus de CC-BY-SA, au choix (même si j'ai du mal à considérer qu'on puisse mettre une licence sur si peu de code).
[^] # Re: Didactique
Posté par anaseto . En réponse au journal À propos du langage APL et portage de TapTempo en bonus. Évalué à 3. Dernière modification le 12 mars 2018 à 09:03.
Maintenant que tu le dis, ça me fait penser à Brogue :)
Celle de Dijkstra est marrante, mais c'est pas trop surprenant venant de lui, il avait l'habitude de sortir des phrases comme ça sur tout et n'importe quoi. Entre autres, il y a aussi FORTRAN, Cobol, la programmation objets, etc. qui prennent cher :)
# Petite erreur…
Posté par anaseto . En réponse au journal Portage de TapTempo en Tcl. Évalué à 3.
Il manque un
-1, m'en suis rendu compte en faisant la version en C. D'ailleurs, tout le calcul du tempo se simplifie en :[^] # Re: Risque ?
Posté par anaseto . En réponse au journal Noyau vulnérable ou pas ?. Évalué à 4.
Disons que pour Meltdown, le débit de fuite c'est jusqu'à 500KB/s, c'est-à-dire beaucoup et c'est en partie là le problème qui rend la vulnérabilité vraiment pratique. Pour Spectre c'est moins, je me souviens plus exactement, quelque chose comme 10 fois moins je crois (ce qui n'est pas négligeable non plus).
[^] # Re: OpenBSD
Posté par anaseto . En réponse à la dépêche Deux failles critiques : Meltdown et Spectre. Évalué à 10.
Oui, enfin, “late December” pour un embargo de six mois, qui a en plus été écourté d'une semaine à la fin suite aux déductions de la communauté par rapport aux patches appliqués dans Linux (qui même sans le patch bavard du gars d'AMD étaient très curieux pour une rc6), c'est pas vraiment être prévenu, ils en sont au même stade que les autres (voire en retard par rapport à DragonFly).
[^] # Re: OpenBSD
Posté par anaseto . En réponse à la dépêche Deux failles critiques : Meltdown et Spectre. Évalué à 9.
Les autres BSDs n'ont pas été prévenus non plus (ou juste un peu avant) aussi, on dirait, donc cela semble ne pas être lié à une quelconque philosophie vis-à-vis des embargos. Dragonfly semble avoir patché déjà, mais pas dans
-stable, uniquement dans la branche de développement, mais la vitesse de réaction est impressionante.Ceci dit, au moins maintenant on est conscients de la faille, ce qui permet de savoir quels genre de services sont particulièrement risqués et à désactiver si possible (grosso modo, n'importe quoi qui permette d'exécuter à un tiers du code en tant qu'utilisateur local du système ou dans une vm).
Il est intéressant, mais pas surprenant (divulguer plus largement est un risque), de voir que pour des failles moins critiques, avec des embargos plus courts, la plupart des BSDs, ainsi que beaucoup de distros sont mis au courant, alors que pour une faille de ce type avec 6 mois d'embargo uniquement Linux, Mac OS et Windows reçoient une alerte bien à l'avance.