reno a écrit 3879 commentaires

Je déteste cette mode "moderne", mais non ça n'était pas le cas: le script a remplacé les commentaires par des lignes blanches, donc il restait "l'empreinte" des commentaires..

Par "coïncidence", l'université qui a crée le projet vend du support..

Non, les 2 n'ont aucun rapport bien sûr..

Tu peux expliquer ce que tu entends par '"deforestation" quand les map/fold sont dans le langage (haskel),etc…'?

Je ne sais pas de quoi tu parles..

Il est si bien écrit qu'il m'a fait passer énormément de temps à lire les autres articles sur le blog..

Je n'utilise pas beaucoup python donc il est peu probable que je me serve de Trio mais nom de dieu qu'est ce que c'est bien conçu!
Les articles ou il explique les problèmes et les solutions possibles et celle qu'il a choisi sont vraiment intéressants..

Alors pourquoi est-ce un problème (et pourquoi le processus ferait-il comme ça plutôt que d'accéder directement à la mémoire) ? Tout simplement parce qu'un script tournant sur une VM (de type VM javascript) peut exploiter la faille pour lire n'importe où dans la mémoire du processus

Je pense que le problème n'est pas seulement pour un interpréteur: ça remet en cause la sécurité par capabilities non?

A mon avis, tes utilisateurs potentiels ne vont pas être très nombreux: les utilisateurs avancés des shells qui en ont marre des langages de shell actuels, et bien ils ont quand même leurs habitudes dans un/des langages impératifs (shells, Perl, Python) leur proposer un langage fonctionnel comme remplacement bof..

Quand je vois ton exemple avancé, tout ces 'in(' ça me pousse plutôt à être 'out'!

Ca n'est pas la première fois que je note ça, j'ai commencé à lire un livre sur OCaml et bien qu'OCaml soit sensé être un langage "mixte" fonctionnel OU impératif, l'auteur du livre ne s'intéressait qu'à l'aspect fonctionnel: je n'ai pas terminé le livre..

Désolé mais je n'ai pas gardé la référence.

Le but de la manœuvre étant de retenir le contenu des cartes et bien écrire les cartes aide à les mémoriser..

De la même manière qu'on s'est rendu compte que ceux qui écrivaient leurs notes de cours retenaient mieux le cours par rapport à ceux qui les tapaient sur un ordinateur.

Le contraire aurait été surprenant Eiffel étant un language de "haut niveau".

Je suis surpris, c'est le cas aussi en mode 'release', je m'attendais à ce que ça soit le cas uniquement en mode debug.

Quand tu vois du code avec 2 fonctions treatBCCH et treatBcch :-( :-(
Une notation qui ne fonctionne pas bien avec des acronymes est une notation de m..

Je ne sais pas pourquoi elle est si populaire.

La documentation de Nix est plutôt mal organisée donc dès qu'on sort de l'utilisation de base ça devient vite très compliqué donc bof: j'ai fini par me recompiler a la main le gcc dont j'avais besoin.

Le principe de Nix parait sympa mais l'implémentation bof: 1) la doc 2) le DSL.

GUIX parait intéressant pour résoudre (2), après est-ce que la doc est meilleure?

J'ai remplacé le HDD de mon portable par un SSD 128Go a l'époque ou ça coûtait cher la Flash et je le regrette rien que pour stocker les photos de mes enfants c'est juste.
Après Windows est + gourmand en place que Linux alors..

À ma connaissance, seuls les langages fonctionnels typés offrent cette possibilité de différencier des types structurellement identiques, autrement qu'en faisant des classes.

Hum, Ada?

1) La compatibilité avec l'historique.
2) Les MAJ qui se passent bien.

De ce point de vue là le monde Linux (sauf le noyau) n'est pas à la hauteur..

Pas avec Wayland: avec GNOME Wayland!
C'est une extension de GNOME au dessus de Wayland: si tu essaye d'utiliser ça sur un DE qui utilise un autre compositeur Wayland (KDE par exemple) ça ne marchera pas.

Oui, c'est(c'était?) le but de libweston dont je parle, mais pour autant que je sache ça n'est pas utilisé (ni par GNOME, ni par KDE).

Entre "rien n'empêche" et que dans les faits ça soit le cas..

Donc osfe a raison, ils font de l'argent en vendant les composants ET en vendant les outils de développement, curieux mélange..

Autant pour le FPGA c'est compliqué d'imaginer une chaîne complètement libre car les fabriquant protègent leur bébé. On voit mal altera ou xilinx balancer toutes les specs de leur dernier bébé fondu en 10nm et qui leur a coûté plusieurs millions de dollars de R&D.

? Même si tu as une chaîne logicielle totalement libre, il faut bien que tu l'achète le FPGA, donc je ne vois pas trop en quoi ça coûterai de l'argent au fabriquant.
Ou alors ils se font de la marge sur le composant ET sur les outils de programmation?
Il me semblait que ça n'était pas le cas et qu'ils ne vendaient pas les outils de programmation de manière indépendante (l'achat du FPGA te donne le droits d'utiliser les outils de programmation (au moins ceux de base)), quelqu'un peut confirmer/infirmer?

Je ne suis pas fan non plus du design de Wayland (j'aurais préféré un "X12") mais bon n'oublie quand même pas qu'on parle d'un remplacement d'X11 qui coté sécurité est totalement nul donc ça reste une grosse amélioration pour la sécurité.

Après, toute cette duplication de code c'est vrai que ça pique..

J'avais compris mais je pense quand même qu'il est important de faire remarquer qu'avec Wayland, pour avoir vraiment l'équivalent de RedShift (qui n'avais besoin je pense que de travailler avec le serveur X quelque soit le DE) il faut que
1) chaque compositeur implémente la fonctionnalité (je n'ai pas l'impression que libweston soit beaucoup utilisé, je me trompe?)
2) l'accès a la fonctionnalité soit standardisée (dans le protocole XDG-Shell je pense)

Chaque DE reproduisant en interne ce genre de fonctionnalité, bonjour la fragmentation..

du compositeur --> DES compositeurS

Contrairement à X chaque compositeur fait tout le travail donc chacun doit (ré)implémenter les fonctionnalités..

Les avis divergent sur le sujet.

Certains considèrent que comme Intel a réussi à implémenter les mêmes techniques que les RISC et a obtenir de très haute performance la différence d'ISA n'a plus grande importance.

D'autres pensent que la raison pour laquelle Intel n'a pas réussi à concurrencer ARM sur l'embarqué est que le "décodeur x86" qui est très complexe est un inconvénient au niveau consommation d'énergie,
bon l'ARM n'est pas vraiment un RISC(*) et son décodeur d'instruction doit quand même être assez compliqué aussi alors..

*:il y avait une vidéo de présentation sur le RISC-V qui montrait bien toutes la complexité de l'ISA ARM mais je n'ai pas le lien désolé.

Ça dépend.. Le pare-feu dans la machine de NAT, ça implique que tu est "à poil" si quelqu'un se connecte derrière le pare-feu: acceptable chez soi probablement, mais pas dans une entreprise..

Click long??
C'est juste une aberration quand on a une souris avec click droit..