Il est vrai que cela dépend beaucoup des structures de données en "ligne" possible. Ocaml utilise beaucoup la liste chainé simple, elle pourrait avoir un traitement particuliers. Je pensais que la complexité venait de l'inexistence de syntaxe "statique" pour les conteneurs. Il n'y a pas d'équivalent à JSON ou aux structures de Perl en OCaml.
La voie alternative suivie par MetaOCaml est d'être très explicite sur les phases de la compilation.
De son côté le C++ a fait le choix de laisser le choix aux compilateurs la taille de la pile de récursion lors des calcul templates.
D'un coté on a une impossibilité théorique forte, de l'autre un choix pragmatique. D'un coté, on a un syntaxe incompréhensible, de l'autre une syntaxe moche sauf pour les cas simples et des lib ultra puissante. D'un coté, on a un outil quasiment pas utilisé même dans la communauté ocaml et de l'autre le langage qui doit avoir le plus de ligne de code écrite, et qui est encore dans le top5 des langages utilisées malgré son age.
Bref, le fait de mettre une limite de temps de compilation est une fonctionnalité très rationnelle, sachant qu'une compilation infinie est forcément une erreur.
C'est vrai que les linker devrait faire un plus gros effort pour nettoyer le code inutile.
Mais leur conception date de l'époque, ou les machines étaient tellement faible que la compilation se faisait fichier par fichier, et donc le programme final de link devait faire le minimum de travail. Aujourd'hui ce découpage n'a aucun sens.
Magnifique…
let rec spower n x =
if n = 0 then .<1>.
else if n mod 2 = 0 then .<square .~(spower (n/2) x)>.
else .<.~x * .~(spower (n-1) x)>.;;
(* val spower : int -> int code -> int code = <fun> *)
let spower7_code = .< fun x -> .~(spower 7 .< x >.)>.;;
Je trouve cela particulièrement illisible. Et avec de la bête propagation de constante on aurait
let spower7_code = spower 7
Les templates de C++ sont connu pour pouvoir à la fois générer du code à la compilation, ce qui permet d'avoir du code très performant, et d'être parfaitement illisible en tant que langage dans le langage un peu pourris.
Je me demandais à quel point la propagation de constante pouvait remplacer les templates, voir même la génération de code. En général, la propagation de constante se limite aux littéraux( 10, 'c'). Pourquoi ne pas aller au delà, et faire de la propagation de constante de conteneur ?
Imaginez la propagation d'une string qui définit une expression régulière : cela revient à générer le code lié à cette expression.
On peut imaginer la même chose avec une structure arborescente : un interpréteur d'AST classique devient un générateur de code sur un AST statique.
"mais évidemment, cela n'empêche nullement vente du produit fini."
De toute façon, cela serait impossible de l’empêcher. Au début d'opencore, F-cpu et autres, il y a eu beaucoup de tentatives pour faire l'équivalent de la "vaccination" de la GPL sur les objets produits. Mais c'est impossible, il n'existe aucun lien juridique entre un "plan" et un objet fabriqué.
Il faut alors passer par un brevet ou par un dépôt de dessin.
C'est très chaud quand même. Les templates ne sont que de la propagation de constante explicite, non ? Si on ajoute les conteneurs dans la propagation de constante (ce que je n'ai pas encore vu dans un langage de programmation), qu'est-ce qui reste aux templates ?
La licence que tu pointes est celle de la libgcc qui accompagne chaque exe compilé par gcc. Si la licence était GPL, cela serait compliqué de devoir démontrer que son apport est ridicule par rapport à la taille du reste, pour démontrer que ce n'est pas un travail dérivé.
"Si un patron n'est pas libre, quels sont les droits de production d'un vêtement associé à ce patron ?"
Les fichiers relèvent du droit d'auteur et donc des licences.
Les produits dont peuvent être issue de ces fichiers. Ils relèvent du droit de vente classique. Avez-vous déjà vu une licence pour un objet ? Il s'agit de contrat de vente normal.
La licence concerne des fichiers, la licence enter l'outil et le modèle de tricot peuvent avoir des licences différents, tout comme gcc et le programme compilé sont différents.
Pour la mode se rajoute le droit des dessins et modèles, qui protège le design, mais cela recoupe la licence du fichier de modèle.
On peut ajouter que dans le monde linux il n'y a pas que les administrateurs et les utilisateurs. Il y a ceux qui font la distribution, et c'est eux qui ont toutes les billes pour mettre ses restrictions en place. L'approche de pledge semble bien plus facile à mettre en œuvre industriellement que l'approche par utilisateur.
Je rajouterais qu'il manque des privilèges user qui serait sympa : impossible de faire .. pour sortir d'un répertoire de lancement, n'ouvrir que les fichiers créés par l'application en question et rien d'autre, ne pas pouvoir lire des fichiers locales, mais parcourir les répertoires, et écrire dedans si on veut. On pourrait même imaginer que le shell détecte les fichiers données en ligne de commande et donne l'accès uniquement à eux.
La gestion de sécurité est complexe, car on la fait reposer soit sur les exécutables, soit sur des droits de chaque utilisateurs. Cela marche depuis SELinux, mais c'est hyper complexe. Le système de base root/user a le mérite d'être simple à mettre en œuvre.
Je pensais que la modèle de sécurité a été "plié" en utilisant la méthode du moindre privilège : en gros, un exécutable root bien élevé est cessé faire tomber tous les privilèges dont il n'a pas besoin (et ni lui, ni ses enfants ne peuvent les récupérer). Si on reprend l'exemple de tcpdump, avec une telle approche le script obtenu ne serait pas vraiment root.
On peut utiliser aussi ce principe pour lancer des utilitaires "wrappés".
Il y a un gros reproche à faire à tous ses modes de sécurités : souvent il est question de l'intégrité de la machine, mais souvent l'utilisateur s'en fout, il a surtout peur de perdre les 10 ans de photos à cause d'un crypto-locker. Et même un programme ayant simplement l'id de l'utilisateur peut faire très mal.
Je pense qu'il faudrait repenser les "capabilities" en fonction des données utilisateurs qui est finalement ce qu'il le plus de valeurs dans le système (perte de données ou fuite de données).
Si vous arrivez à faire en sorte qu'une faille mozilla soit impossible à utiliser pour sortir des données, le tout sans 3 tonnes de configuration, vous êtes très fort.
"Reste alors à vérifier par exemple qu'il ne s'agit pas de tas de petites allocations de ~1-8 octets (métrique min_size)"
Il y a des gens qui font des allocations de 8 octets ?! Une si petite allocation implique l'utilisation massive de pointeurs, qui prennent de la place, qui implique beaucoup d'indirection dans la mémoire, et une utilisation des mémoires caches toutes pourris (une ligne de cache L1 est de 32 octets, cela veut dire qu'à chaque lecture, 32 octets sont transférés). Le CPU et gcc veulent des gros morceaux de mémoire (multiple de 2 ou 4 Mo, pour utiliser les 'huge' pages) avec des accès séquentiels ou avec un pattern qui peut se prédire, de 32 ou 64 octets. De préférence, il faut grouper lectures, puis écritures, pour éviter de forcer l'unité mémoire à vérifier, que l'on ne relit pas, ce que l'on est en train d'écrire, ce qui créé des cycles d'attentes.
"Formel" dans beaucoup de cas veux simplement dire "correctement définit", par exemple en C, "(i <> 32" ne donne pas tout le temps le même résultat. Ensuite, il faut un moyen pour décrire les attendus ("théorème" ou "spec" ou "HLR"), et ensuite, il faut bien les trouver, ce qui est souvent beaucoup plus complexe qu'on ne le croit.
Une bonne suite de teste permet de vérifier le comportement attendu mais à tendance à congeler le code. Car il devient couteux de le modifier si la suite de teste n'est pas assez souple. Le cas typique est le fait de changer une constante dans le code, ce qui prend 1 min, mais qui nécessite de recalculer à la main des centaines de valeurs de testes. Personne ne veut le faire.
Il y a une nouvelle méthode de teste qui permet de vérifier que les tests sont corrects. C'est bien plus intéressant que la couverture de code qui ne vérifie que la "traversé" du code et non son résultat. Cela permet de trafiquer les entrée pour augmenter le taux de couverture sans rajouter un seul test.
Il s'agit de la technique de "mutation testing". L'idée est de modifier un peu le code automatiquement et de vérifier que cela plante bien un teste.
Un moyen assez simple pour éviter de congeler une application est d'avoir un "golden model", en gros la même application recodé autrement, ou par une autre équipe (l'équipe de teste ?). Ce code de test permet de calculer les sorties attendues, et sa complexité ne dépasse jamais celle de l'application testée. Ainsi, changer une constante prendra seulement 2 fois 1 min.
Le teste consiste a vérifier que les 2 codes se comportent de la même façon. il faut évidement travailler en "boite noir", sinon le copier-coller va tuer l’intérêt de la méthode.
Il reste à générer les entrées du code comme le font déjà les "fuzzers".
Pour faire ça, il faudrait encore avoir des cours et des livres de C++ "moderne". Les 3 quart ne font que reprendre le livre d'origine complètement obsolète sur les bonnes manières de faire.
[^] # Re: optimisation et propagation de constante
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche OCaml 4.06 et 4.07. Évalué à 4.
Il est vrai que cela dépend beaucoup des structures de données en "ligne" possible. Ocaml utilise beaucoup la liste chainé simple, elle pourrait avoir un traitement particuliers. Je pensais que la complexité venait de l'inexistence de syntaxe "statique" pour les conteneurs. Il n'y a pas d'équivalent à JSON ou aux structures de Perl en OCaml.
D'un coté on a une impossibilité théorique forte, de l'autre un choix pragmatique. D'un coté, on a un syntaxe incompréhensible, de l'autre une syntaxe moche sauf pour les cas simples et des lib ultra puissante. D'un coté, on a un outil quasiment pas utilisé même dans la communauté ocaml et de l'autre le langage qui doit avoir le plus de ligne de code écrite, et qui est encore dans le top5 des langages utilisées malgré son age.
Bref, le fait de mettre une limite de temps de compilation est une fonctionnalité très rationnelle, sachant qu'une compilation infinie est forcément une erreur.
"La première sécurité est la liberté"
[^] # Re: À boire et à manger
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Un développeur qui dénonce. Évalué à 3.
C'est vrai que les linker devrait faire un plus gros effort pour nettoyer le code inutile.
Mais leur conception date de l'époque, ou les machines étaient tellement faible que la compilation se faisait fichier par fichier, et donc le programme final de link devait faire le minimum de travail. Aujourd'hui ce découpage n'a aucun sens.
"La première sécurité est la liberté"
[^] # Re: optimisation et propagation de constante
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche OCaml 4.06 et 4.07. Évalué à 3.
f-lambda semble être une liste d'optimisation typique que l'on voit pour gcc par exemple (inlining, spécialisation, dead code elimination…).
L'idée est de faire ça avec des conteneurs et pas seulement des constantes simples.
"La première sécurité est la liberté"
[^] # Re: optimisation et propagation de constante
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche OCaml 4.06 et 4.07. Évalué à 3.
Magnifique…
let rec spower n x =
if n = 0 then .<1>.
else if n mod 2 = 0 then .<square .~(spower (n/2) x)>.
else .<.~x * .~(spower (n-1) x)>.;;
(* val spower : int -> int code -> int code = <fun> *)
let spower7_code = .< fun x -> .~(spower 7 .< x >.)>.;;
Je trouve cela particulièrement illisible. Et avec de la bête propagation de constante on aurait
let spower7_code = spower 7
"La première sécurité est la liberté"
# optimisation et propagation de constante
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche OCaml 4.06 et 4.07. Évalué à 3.
Les templates de C++ sont connu pour pouvoir à la fois générer du code à la compilation, ce qui permet d'avoir du code très performant, et d'être parfaitement illisible en tant que langage dans le langage un peu pourris.
Je me demandais à quel point la propagation de constante pouvait remplacer les templates, voir même la génération de code. En général, la propagation de constante se limite aux littéraux( 10, 'c'). Pourquoi ne pas aller au delà, et faire de la propagation de constante de conteneur ?
Imaginez la propagation d'une string qui définit une expression régulière : cela revient à générer le code lié à cette expression.
On peut imaginer la même chose avec une structure arborescente : un interpréteur d'AST classique devient un générateur de code sur un AST statique.
Qu'en pensez-vous ?
"La première sécurité est la liberté"
[^] # Re: Clause NC vs vendre
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Faire ses modèles de pulls au tricot avec LibreOffice. Évalué à 6.
De toute façon, cela serait impossible de l’empêcher. Au début d'opencore, F-cpu et autres, il y a eu beaucoup de tentatives pour faire l'équivalent de la "vaccination" de la GPL sur les objets produits. Mais c'est impossible, il n'existe aucun lien juridique entre un "plan" et un objet fabriqué.
Il faut alors passer par un brevet ou par un dépôt de dessin.
"La première sécurité est la liberté"
[^] # Re: Ça pique les yeux
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Mémorisation partielle de fonction constexpr. Évalué à 3. Dernière modification le 27 septembre 2018 à 10:50.
C'est très chaud quand même. Les templates ne sont que de la propagation de constante explicite, non ? Si on ajoute les conteneurs dans la propagation de constante (ce que je n'ai pas encore vu dans un langage de programmation), qu'est-ce qui reste aux templates ?
"La première sécurité est la liberté"
[^] # Re: Très intéressant, mais moins pratique que pledge
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Linux capabilities : se passer des commandes su et sudo. Évalué à 3.
Il y a un name space pour mount, il me semble qu'il y en a une capabilities pour avoir accès au device (mkdevice, qui permettait de sortir de chroot).
Je pense qu'il manque juste l'outil qui recréait un mouting point avec les bons fichiers ou un device specific à mounter qui filtre les fichiers.
"La première sécurité est la liberté"
[^] # Re: Clause NC vs vendre
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Faire ses modèles de pulls au tricot avec LibreOffice. Évalué à 5.
La licence que tu pointes est celle de la libgcc qui accompagne chaque exe compilé par gcc. Si la licence était GPL, cela serait compliqué de devoir démontrer que son apport est ridicule par rapport à la taille du reste, pour démontrer que ce n'est pas un travail dérivé.
"La première sécurité est la liberté"
[^] # Re: Clause NC vs vendre
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Faire ses modèles de pulls au tricot avec LibreOffice. Évalué à 5.
Les fichiers relèvent du droit d'auteur et donc des licences.
Les produits dont peuvent être issue de ces fichiers. Ils relèvent du droit de vente classique. Avez-vous déjà vu une licence pour un objet ? Il s'agit de contrat de vente normal.
La licence concerne des fichiers, la licence enter l'outil et le modèle de tricot peuvent avoir des licences différents, tout comme gcc et le programme compilé sont différents.
Pour la mode se rajoute le droit des dessins et modèles, qui protège le design, mais cela recoupe la licence du fichier de modèle.
"La première sécurité est la liberté"
[^] # Re: Très intéressant, mais moins pratique que pledge
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Linux capabilities : se passer des commandes su et sudo. Évalué à 3.
Je me demande si sous linux, il n'est pas déjà possible de limiter l'exploitation du système de fichier avec les namespaces et chroot.
"La première sécurité est la liberté"
[^] # Re: Très intéressant, mais moins pratique que pledge
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Linux capabilities : se passer des commandes su et sudo. Évalué à 2.
Aujourd'hui si on a besoin de droit spéciaux, on utilise docker.
"La première sécurité est la liberté"
[^] # Re: Très intéressant, mais moins pratique que pledge
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Linux capabilities : se passer des commandes su et sudo. Évalué à 2.
On peut ajouter que dans le monde linux il n'y a pas que les administrateurs et les utilisateurs. Il y a ceux qui font la distribution, et c'est eux qui ont toutes les billes pour mettre ses restrictions en place. L'approche de pledge semble bien plus facile à mettre en œuvre industriellement que l'approche par utilisateur.
Je rajouterais qu'il manque des privilèges user qui serait sympa : impossible de faire .. pour sortir d'un répertoire de lancement, n'ouvrir que les fichiers créés par l'application en question et rien d'autre, ne pas pouvoir lire des fichiers locales, mais parcourir les répertoires, et écrire dedans si on veut. On pourrait même imaginer que le shell détecte les fichiers données en ligne de commande et donne l'accès uniquement à eux.
"La première sécurité est la liberté"
[^] # Re: Petite question ...
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Linux capabilities : se passer des commandes su et sudo. Évalué à 6.
La gestion de sécurité est complexe, car on la fait reposer soit sur les exécutables, soit sur des droits de chaque utilisateurs. Cela marche depuis SELinux, mais c'est hyper complexe. Le système de base root/user a le mérite d'être simple à mettre en œuvre.
Je pensais que la modèle de sécurité a été "plié" en utilisant la méthode du moindre privilège : en gros, un exécutable root bien élevé est cessé faire tomber tous les privilèges dont il n'a pas besoin (et ni lui, ni ses enfants ne peuvent les récupérer). Si on reprend l'exemple de tcpdump, avec une telle approche le script obtenu ne serait pas vraiment root.
On peut utiliser aussi ce principe pour lancer des utilitaires "wrappés".
Il y a un gros reproche à faire à tous ses modes de sécurités : souvent il est question de l'intégrité de la machine, mais souvent l'utilisateur s'en fout, il a surtout peur de perdre les 10 ans de photos à cause d'un crypto-locker. Et même un programme ayant simplement l'id de l'utilisateur peut faire très mal.
Je pense qu'il faudrait repenser les "capabilities" en fonction des données utilisateurs qui est finalement ce qu'il le plus de valeurs dans le système (perte de données ou fuite de données).
Si vous arrivez à faire en sorte qu'une faille mozilla soit impossible à utiliser pour sortir des données, le tout sans 3 tonnes de configuration, vous êtes très fort.
"La première sécurité est la liberté"
[^] # Re: simd explicite ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pythran - 0.8.7. Évalué à 3.
Mais appeler ses libs ne demandent pas d'utiliser des intrasecs SIMD, si ?
C'est vrai aussi que les compilo ont rarement remplacé des bouts de code, par des fonctions optimisé, en dehors de memcpy().
"La première sécurité est la liberté"
[^] # Re: simd explicite ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pythran - 0.8.7. Évalué à 3. Dernière modification le 20 septembre 2018 à 12:32.
Je ne comprends pas trop l"exemple. Il n'existe pas d'instructions SIMD pour cos(). Sinon, Le code de l'addition est correctement vectorisé, non ?
"La première sécurité est la liberté"
[^] # Re: J’ai testé MALT
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Profileurs mémoire MALT et NUMAPROF. Évalué à 3.
Il y a des gens qui font des allocations de 8 octets ?! Une si petite allocation implique l'utilisation massive de pointeurs, qui prennent de la place, qui implique beaucoup d'indirection dans la mémoire, et une utilisation des mémoires caches toutes pourris (une ligne de cache L1 est de 32 octets, cela veut dire qu'à chaque lecture, 32 octets sont transférés). Le CPU et gcc veulent des gros morceaux de mémoire (multiple de 2 ou 4 Mo, pour utiliser les 'huge' pages) avec des accès séquentiels ou avec un pattern qui peut se prédire, de 32 ou 64 octets. De préférence, il faut grouper lectures, puis écritures, pour éviter de forcer l'unité mémoire à vérifier, que l'on ne relit pas, ce que l'on est en train d'écrire, ce qui créé des cycles d'attentes.
"La première sécurité est la liberté"
# simd explicite ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pythran - 0.8.7. Évalué à 4.
Pourquoi utiliser du SIMD explicite ? Les intrasec et vectorisation automatique de GCC ne suffisent pas ?
"La première sécurité est la liberté"
[^] # Re: Méthodes formelles ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Un peu d’Open Hardware pour la rentrée (et beaucoup de LinuxBoot). Évalué à 4.
"Formel" dans beaucoup de cas veux simplement dire "correctement définit", par exemple en C, "(i <> 32" ne donne pas tout le temps le même résultat. Ensuite, il faut un moyen pour décrire les attendus ("théorème" ou "spec" ou "HLR"), et ensuite, il faut bien les trouver, ce qui est souvent beaucoup plus complexe qu'on ne le croit.
Une bonne suite de teste permet de vérifier le comportement attendu mais à tendance à congeler le code. Car il devient couteux de le modifier si la suite de teste n'est pas assez souple. Le cas typique est le fait de changer une constante dans le code, ce qui prend 1 min, mais qui nécessite de recalculer à la main des centaines de valeurs de testes. Personne ne veut le faire.
Il y a une nouvelle méthode de teste qui permet de vérifier que les tests sont corrects. C'est bien plus intéressant que la couverture de code qui ne vérifie que la "traversé" du code et non son résultat. Cela permet de trafiquer les entrée pour augmenter le taux de couverture sans rajouter un seul test.
Il s'agit de la technique de "mutation testing". L'idée est de modifier un peu le code automatiquement et de vérifier que cela plante bien un teste.
Un moyen assez simple pour éviter de congeler une application est d'avoir un "golden model", en gros la même application recodé autrement, ou par une autre équipe (l'équipe de teste ?). Ce code de test permet de calculer les sorties attendues, et sa complexité ne dépasse jamais celle de l'application testée. Ainsi, changer une constante prendra seulement 2 fois 1 min.
Le teste consiste a vérifier que les 2 codes se comportent de la même façon. il faut évidement travailler en "boite noir", sinon le copier-coller va tuer l’intérêt de la méthode.
Il reste à générer les entrées du code comme le font déjà les "fuzzers".
"La première sécurité est la liberté"
[^] # Re: Méthodes formelles ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Un peu d’Open Hardware pour la rentrée (et beaucoup de LinuxBoot). Évalué à 4. Dernière modification le 03 septembre 2018 à 08:05.
De quelles genres de méthodes formelles vous parlez ? "formel" est utilisé pour beaucoup de chose très différent.
"La première sécurité est la liberté"
[^] # Re: Beaucoup de bruit pour rien
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Le comble du ridicule. Évalué à 3. Dernière modification le 09 août 2018 à 17:21.
pour être à la page, il ferait mieux de dessiner des vulves à la place.
"La première sécurité est la liberté"
[^] # Re: *cough*
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Le comble du ridicule. Évalué à 5.
En fait, il n'assume rien des conséquences, justement.
"La première sécurité est la liberté"
[^] # Re: *cough*
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Le comble du ridicule. Évalué à 9.
comme la libcaca, en gros :)
"La première sécurité est la liberté"
[^] # Re: Conclusion?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Faut‐il continuer à apprendre le C++ ?. Évalué à 4.
Pour faire ça, il faudrait encore avoir des cours et des livres de C++ "moderne". Les 3 quart ne font que reprendre le livre d'origine complètement obsolète sur les bonnes manières de faire.
"La première sécurité est la liberté"
[^] # Re: Image from scratch + Go = 🎉
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Une image de base docker. Évalué à 6.
L'isolation avec le reste, l'outillage de gestion.
"La première sécurité est la liberté"