Le dev de Lisaac est arreté. Le site est mort. Il y a eu un gros article sur les concepts manipulés publiés dans linux mag en début d'année dernière de mémoire.
Sauf qu'on aura toujours besoin de langage comme C/C++ pour implémenter des trucs qui doivent aller vite, comme les interpréteurs de langage haut niveau ou des compilateurs. Chacun son domaine.
Ou que non alors ! Lisaac a déjà prouvé que l'on peut être du niveau de smaltalk en terme d'expressivité et battre le C++ en terme de vitesse.
OCaml est de trés haut niveau, mais les optimisations dans la génération de code sont minimes (pas de déroulage de boucle ou de spécialisation de fonction). Il est pourtant dans le top10 en terme de vitesse.
Scala n'est pas du tout dérivé de java, il produit du code pour jvm, c'est tout. Et je suis d'accord que la syntaxe est encore pire que celle de Ocaml.
objet ou pas objet, le but est de pouvoir parcourir un arbre en séparant la définition de l'arbre et les parcours.
Et pour ça, les types sommes et le "pattern matching" sont totalement imbattables. C'est tellement puissant que je ne comprends pas pourquoi cela n'a pas été ajouter au C++.
C'est une très bonne alternative pour tous les cas ou il y a une pléthore de petit objet à gérer ensemble.
type base_t
type derived_t
type t =
| BASE of base_t * t list
| DERIVED of derived_t * t list
let rec visitor accumulator t =
match t with
| [] -> List.rev accumulator
| BASE (base_info, suite) :: tail
-> let a = visitor ((foo_base base_info) :: accumulator) tail in
visitor ((foo_base base_info) :: a) suite
| DERIVED (derived_info, suite) :: tail
-> let a = visitor ((foo_base base_info) :: accumulator) tail in
visitor ((foo_derived derived_info) :: a) suite
(*execution : *)
let resultat_list = visitor [] my_data_tree in
...
Et encore, dans le match on peut mettre des bouts d'arbres comme :
| BASE (base_info, BASE (base_info2, []))
Le petit point difficile est l'usage d'une liste dans le type, mais on peut utilisé un type Option pour faire la terminaison de récursion.
Pour info :
(item :: list) permet d'ajouter un item au début d'une list ou de décomposer une liste dans les matchs.
(foo plop) permet d'appliquer la fonction foo au paramètre plop
En conclusion, vive les types sommes et le "pattern matching" d'arbre.
Je n'aime pas trop le commentaire interne. Cela empêche souvent d'avoir la fonction entière sur un seul écran. Décrire l'intention au dessus de la fonction est pas mal. J'aime bien aussi les microfonctions qui porte le nom de ce qu'elles font même si il s'agit d'une ligne.
Si un compilateur vérifie le code, très peu vérifie les commentaires (si cela existe : nom de fonction avec erreur, ( ou [ non appairé, etc… ).
Cela me déprime d'avoir encore raison, 10 ans plus tart. Je parle beaucoup de mp3, qui ont laissé tomber les DRM, mais cela reste toujours valable pour les ebook et les vidéos.
Non, chaque fichier a sa propre licence, compatible entre elle. Et certains sont sous v3. Amusant, non ? lxr n'est pas pratique pour trouver un exemple. Mais je l'avais fait à une époque.
Si tu ne peux pas changer un binaire pour cause de DRM, par recompilation, cela reste du libre légalement. Mais on est loin de l'esprit. C'est même la raison de la création de la GPLv3. La GPL n'est pas le libre, on est d'accord. Mais le libre a été créé pour que les utilisateurs gardent le contrôle de leur code pour avoir un vrai contrôle sur leur donné. La tivoisation est un moyen détourner de casser les principes du libre.
Tu parles de la GPLv3 mais la lgplv2 l'interdit aussi (indirectement, car il doit être possible de remplacer une lib lgpl fournis par une version compilé par ces soins).
la LGPL dispose d'une clause assez spécial pour empécher qu'une library libre devienne dépendante de donné non libre ;
Vous pouvez modifier votre ou vos copie(s) de la Bibliothèque […] pourvu que vous satisfassiez également à chacune de ces conditions :
[…]
d) Si une facilité dans la bibliothèque modifiée se réfère à une fonction ou une table de données devant être fournie par une application utilisant la facilité, autre qu’un argument passé quand la facilité est invoquée, alors vous devez faire un effort en toute bonne foi pour vous assurer que, dans l’éventualité où une application ne fournirait pas une telle fonction ou table, la facilité restera opérationnelle et effectuera une partie quelconque de sa finalité de façon sensée.https://www.gnu.org/licenses/lgpl.html
Et je pense qu'une clef secrète peut tout à fait rentrer dans ce cadre.
"Secure Boot", ne va vérifier que grub, rien de plus.
"Secure Boot et d'autres idées sur les signatures, on peut signer la chaîne complète, et donc n'accepter que ce qui est "acceptable" par toute la chaîne."
Mais cela impose plein de complexité sur les mise à jour de faille. Le fameux TCPA voulait pousser ce genre d'approche, il y a des années. Dans ce cas, il faut savoir qui contrôle la clef master qui gère le tout. Dans toutes les implantations, c'est l'utilisateur de départ qui le gère. Si les clefs appartiennent à un tier, il y a tout de même un risque énorme de fuite.
Le seul moyen vraiment fiable serait d'avoir un secret unique par machine. Ainsi, une fuite n'aurait pas d'intérêt. Mais la mise en place serait d'une lourdeur énorme.
"Genre TiVo, qui utilise du libre (et même de la GPL bien en copyleft), rien de nouveau."
Ils sont au courant que des bouts de Linux sont sous GPLv3 ?
Sauf que l'outil qui fournit la clef doit être sacrément intrusif pour être efficace. Tellement intrusif, que je ne vois pas comment il peut exister sous un os libre, à moins de le mettre dans un superviseur contrôler par le BIOS.
En gros, tu ne peux pas attaquer pour faire valoir ton droit, mais tu as le droit de faire ce que tu veux et te défendre avec cette exception si on te traine en justice ?
Si tu parles d'un système de DRM avec clef envoyé à une boite noir de lecture, il suffit de donner la clef avec le média, comme au temps des DVD.
Si la clef est unique par utilisateur, il faut que la boite noire puisse avoir une autre source d'information commune avec l’émetteur de la clef pour retrouver la clef d'origine (par exemple, un XOR avec l'id du cpu, ou une carte à puce). Mais l'algorithme doit rester secret (ou une clef de crypto, ce qui revient au même).
Si tu veux que ton firefox soit signé pour qu'une autorité extérieur fournisse la clef, tu as forcément un outils qui vérifie cette signature, si l'OS est libre il est facile de détourner la vérification pour que le résultat soit la signature attendu (ex tu as 2 version de firefox, une signé et l'autre pas, en cas de demande de signature, tu détournes les appels systèmes vers la version signée).
Pour qu'un système DRM fonctionne, il faut que le "ring 0", le mode super utilisateur soit contrôlé par le DRM (comme trustzone pour ARM avec leur "ring -1"). Et encore, il ne faut pas non plus que l'utilisateur puisse prendre le contrôle de ce "ring -1" au démarrage ou avec des outils de debug. Dans ce cas, il pourra simuler les opérations de sécurité (de mémoire, TPS était complètement cassé de cette façon là : la carte à puce était simulé).
Tu sais très bien que faire la différence entre code et donnée peut-être très mince.
D'un point de vue compilation, c'est évident, entre d'un coté le code assembleur et de l'autre les données mémoire. Mais si tu montes d'un niveau d'abstraction, cela commence à devenir chaud : Un script perl avec un eval() au milieu, une page avec du SQL sous forme de string, un fichier d'option écrit en lua, une expression régulière dans une configuration d'un anti-spam ou d'un WAF, … Jusqu'à la fabrication de code offusqué qui ne sont que des AES avec une clef à l'intérieur comme pourrait le faire de la propagation de constante lors de compilation.
Le comportement du code pouvant changer selon les données, il est difficile d'être aussi tranché.
La question est plus technique. Comment faire un DRM standard, sachant que le concept même de DRM efficace est antagoniste avec le fait d'avoir des sources ouvertes.
BSP, c'est board support package. C'est en gros les drivers bas niveau pour faire tourner une carte embarqué, car même si 2 cartes utilisent un cpu identique comme 2 PC utilise un x86, le PC dispose de tout un tas de composant standard (BIOS, démarrage, RTC, lien série, PCI) qui aide au démarrage et aux choix dynamiques des drivers, ce qui n'existe pas dans une carte typique embarqué (suffit de regarder la tête du sous-système ARM sous linux).
D'ailleurs, je n'ai jamais compris pourquoi ARM n'imposait pas quelques périphériques standard pour faciliter le port des OS (un moyen de boot, un lien série, une RTC et une énumération des périphériques serait le minimum).
nico, dev d'un driver linux pour tester M-Shield de TI
[^] # Re: un inconvénient des templates
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Visiteurs en C++. Évalué à 2.
Le dev de Lisaac est arreté. Le site est mort. Il y a eu un gros article sur les concepts manipulés publiés dans linux mag en début d'année dernière de mémoire.
http://www.ed-diamond.com/produit.php?ref=lmag148&id_rubrique=1
Comme benchmark :
http://benchmarksgame.alioth.debian.org/u32/code-used-time-used-shapes.php
Lisaac a été premier de ce benchmark quelque temps avant que les téchniques soient copié pour les code C et C++.
"La première sécurité est la liberté"
[^] # Re: un inconvénient des templates
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Visiteurs en C++. Évalué à 3.
Sauf qu'on aura toujours besoin de langage comme C/C++ pour implémenter des trucs qui doivent aller vite, comme les interpréteurs de langage haut niveau ou des compilateurs. Chacun son domaine.
Ou que non alors ! Lisaac a déjà prouvé que l'on peut être du niveau de smaltalk en terme d'expressivité et battre le C++ en terme de vitesse.
OCaml est de trés haut niveau, mais les optimisations dans la génération de code sont minimes (pas de déroulage de boucle ou de spécialisation de fonction). Il est pourtant dans le top10 en terme de vitesse.
"La première sécurité est la liberté"
[^] # Re: Dire que certaine pense que le Ocaml est illisible...
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Visiteurs en C++. Évalué à 1.
Scala est un langage fonctionnel, pas java…
"La première sécurité est la liberté"
[^] # Re: Dire que certaine pense que le Ocaml est illisible...
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Visiteurs en C++. Évalué à 3.
Sans doute, mais quand tu as 2 niveaux de fold, mon cerveau fait un overflow.
"La première sécurité est la liberté"
[^] # Re: Dire que certaine pense que le Ocaml est illisible...
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Visiteurs en C++. Évalué à 3.
Scala n'est pas du tout dérivé de java, il produit du code pour jvm, c'est tout. Et je suis d'accord que la syntaxe est encore pire que celle de Ocaml.
"La première sécurité est la liberté"
[^] # Re: Dire que certaine pense que le Ocaml est illisible...
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Visiteurs en C++. Évalué à 5.
objet ou pas objet, le but est de pouvoir parcourir un arbre en séparant la définition de l'arbre et les parcours.
Et pour ça, les types sommes et le "pattern matching" sont totalement imbattables. C'est tellement puissant que je ne comprends pas pourquoi cela n'a pas été ajouter au C++.
C'est une très bonne alternative pour tous les cas ou il y a une pléthore de petit objet à gérer ensemble.
"La première sécurité est la liberté"
# Dire que certaine pense que le Ocaml est illisible...
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Visiteurs en C++. Évalué à 10. Dernière modification le 24 avril 2013 à 10:56.
Quand on voit la complexité du truc…
Et encore, dans le match on peut mettre des bouts d'arbres comme :
| BASE (base_info, BASE (base_info2, []))
Le petit point difficile est l'usage d'une liste dans le type, mais on peut utilisé un type Option pour faire la terminaison de récursion.
Pour info :
(item :: list) permet d'ajouter un item au début d'une list ou de décomposer une liste dans les matchs.
(foo plop) permet d'appliquer la fonction foo au paramètre plop
En conclusion, vive les types sommes et le "pattern matching" d'arbre.
"La première sécurité est la liberté"
[^] # Re: /* commentaire ou documentation inline ? */
Posté par Nicolas Boulay (site web personnel) . En réponse au journal To comment or not to comment. That is the question.. Évalué à 5.
Je n'aime pas trop le commentaire interne. Cela empêche souvent d'avoir la fonction entière sur un seul écran. Décrire l'intention au dessus de la fonction est pas mal. J'aime bien aussi les microfonctions qui porte le nom de ce qu'elles font même si il s'agit d'une ligne.
Si un compilateur vérifie le code, très peu vérifie les commentaires (si cela existe : nom de fonction avec erreur, ( ou [ non appairé, etc… ).
"La première sécurité est la liberté"
[^] # Re: DRM
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Vers l'abandon de Silverlight et de Flash. Évalué à 5.
Du moment, qu'il y a des gens pour y croire :)
"La première sécurité est la liberté"
[^] # Re: DRM
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Vers l'abandon de Silverlight et de Flash. Évalué à 3.
C'est aussi la différence entre la lettre et l'esprit. L'esprit importe à ceux qui ont créé le concept, la lettre pour les juristes.
Sinon, c'est bien connu que la GPL ne fait pas confiance dans la nature humaine, au contraire de la BSD.
"La première sécurité est la liberté"
[^] # Re: DRM
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Vers l'abandon de Silverlight et de Flash. Évalué à 3.
Dans une guerre des standards, en général, il en reste un à la fin. Ce qui n'a pas été le cas.
Par défaut, un truc sous DRM est mille fois plus chiant que le truc piraté (copy/transfert/sauvegarde compliqué).
"La première sécurité est la liberté"
[^] # Re: DRM
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Vers l'abandon de Silverlight et de Flash. Évalué à 2.
Cela me déprime d'avoir encore raison, 10 ans plus tart. Je parle beaucoup de mp3, qui ont laissé tomber les DRM, mais cela reste toujours valable pour les ebook et les vidéos.
"La première sécurité est la liberté"
[^] # Re: DRM
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Vers l'abandon de Silverlight et de Flash. Évalué à -2.
Non, chaque fichier a sa propre licence, compatible entre elle. Et certains sont sous v3. Amusant, non ? lxr n'est pas pratique pour trouver un exemple. Mais je l'avais fait à une époque.
"La première sécurité est la liberté"
[^] # Re: DRM
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Vers l'abandon de Silverlight et de Flash. Évalué à 2.
Tient cela me rappelle ce texte, que j'ai écrit, y'a presque 10 ans : (tin, je suis vieux :/)
http://www.unixgarden.com/index.php/gnu-linux-magazine/aliennation-2
"La première sécurité est la liberté"
[^] # Re: DRM
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Vers l'abandon de Silverlight et de Flash. Évalué à 4.
Si tu ne peux pas changer un binaire pour cause de DRM, par recompilation, cela reste du libre légalement. Mais on est loin de l'esprit. C'est même la raison de la création de la GPLv3. La GPL n'est pas le libre, on est d'accord. Mais le libre a été créé pour que les utilisateurs gardent le contrôle de leur code pour avoir un vrai contrôle sur leur donné. La tivoisation est un moyen détourner de casser les principes du libre.
Tu parles de la GPLv3 mais la lgplv2 l'interdit aussi (indirectement, car il doit être possible de remplacer une lib lgpl fournis par une version compilé par ces soins).
"La première sécurité est la liberté"
[^] # Re: DRM
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Vers l'abandon de Silverlight et de Flash. Évalué à 2.
la LGPL dispose d'une clause assez spécial pour empécher qu'une library libre devienne dépendante de donné non libre ;
Vous pouvez modifier votre ou vos copie(s) de la Bibliothèque […] pourvu que vous satisfassiez également à chacune de ces conditions :
[…]
d) Si une facilité dans la bibliothèque modifiée se réfère à une fonction ou une table de données devant être fournie par une application utilisant la facilité, autre qu’un argument passé quand la facilité est invoquée, alors vous devez faire un effort en toute bonne foi pour vous assurer que, dans l’éventualité où une application ne fournirait pas une telle fonction ou table, la facilité restera opérationnelle et effectuera une partie quelconque de sa finalité de façon sensée. https://www.gnu.org/licenses/lgpl.html
Et je pense qu'une clef secrète peut tout à fait rentrer dans ce cadre.
"La première sécurité est la liberté"
[^] # Re: DRM
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Vers l'abandon de Silverlight et de Flash. Évalué à 2.
"Secure Boot", ne va vérifier que grub, rien de plus.
"Secure Boot et d'autres idées sur les signatures, on peut signer la chaîne complète, et donc n'accepter que ce qui est "acceptable" par toute la chaîne."
Mais cela impose plein de complexité sur les mise à jour de faille. Le fameux TCPA voulait pousser ce genre d'approche, il y a des années. Dans ce cas, il faut savoir qui contrôle la clef master qui gère le tout. Dans toutes les implantations, c'est l'utilisateur de départ qui le gère. Si les clefs appartiennent à un tier, il y a tout de même un risque énorme de fuite.
Le seul moyen vraiment fiable serait d'avoir un secret unique par machine. Ainsi, une fuite n'aurait pas d'intérêt. Mais la mise en place serait d'une lourdeur énorme.
"Genre TiVo, qui utilise du libre (et même de la GPL bien en copyleft), rien de nouveau."
Ils sont au courant que des bouts de Linux sont sous GPLv3 ?
"La première sécurité est la liberté"
[^] # Re: DRM
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Vers l'abandon de Silverlight et de Flash. Évalué à -2.
Sauf que l'outil qui fournit la clef doit être sacrément intrusif pour être efficace. Tellement intrusif, que je ne vois pas comment il peut exister sous un os libre, à moins de le mettre dans un superviseur contrôler par le BIOS.
"La première sécurité est la liberté"
[^] # Re: DRM
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Vers l'abandon de Silverlight et de Flash. Évalué à 1.
En gros, tu ne peux pas attaquer pour faire valoir ton droit, mais tu as le droit de faire ce que tu veux et te défendre avec cette exception si on te traine en justice ?
Et au final, cela change quoi ?
"La première sécurité est la liberté"
[^] # Re: DRM
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Vers l'abandon de Silverlight et de Flash. Évalué à 2.
"la copie privée ne constitue pas un droit mais une exception légale".
J'ai bien ri en lisant plusieurs fois ce genre de chose. Quelle est la différence de nature entre un droit et un droit issue d'une exception ?
"La première sécurité est la liberté"
[^] # Re: DRM
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Vers l'abandon de Silverlight et de Flash. Évalué à 7.
Si tu parles d'un système de DRM avec clef envoyé à une boite noir de lecture, il suffit de donner la clef avec le média, comme au temps des DVD.
Si la clef est unique par utilisateur, il faut que la boite noire puisse avoir une autre source d'information commune avec l’émetteur de la clef pour retrouver la clef d'origine (par exemple, un XOR avec l'id du cpu, ou une carte à puce). Mais l'algorithme doit rester secret (ou une clef de crypto, ce qui revient au même).
Si tu veux que ton firefox soit signé pour qu'une autorité extérieur fournisse la clef, tu as forcément un outils qui vérifie cette signature, si l'OS est libre il est facile de détourner la vérification pour que le résultat soit la signature attendu (ex tu as 2 version de firefox, une signé et l'autre pas, en cas de demande de signature, tu détournes les appels systèmes vers la version signée).
Pour qu'un système DRM fonctionne, il faut que le "ring 0", le mode super utilisateur soit contrôlé par le DRM (comme trustzone pour ARM avec leur "ring -1"). Et encore, il ne faut pas non plus que l'utilisateur puisse prendre le contrôle de ce "ring -1" au démarrage ou avec des outils de debug. Dans ce cas, il pourra simuler les opérations de sécurité (de mémoire, TPS était complètement cassé de cette façon là : la carte à puce était simulé).
"La première sécurité est la liberté"
[^] # Re: DRM
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Vers l'abandon de Silverlight et de Flash. Évalué à 6.
Tu sais très bien que faire la différence entre code et donnée peut-être très mince.
D'un point de vue compilation, c'est évident, entre d'un coté le code assembleur et de l'autre les données mémoire. Mais si tu montes d'un niveau d'abstraction, cela commence à devenir chaud : Un script perl avec un eval() au milieu, une page avec du SQL sous forme de string, un fichier d'option écrit en lua, une expression régulière dans une configuration d'un anti-spam ou d'un WAF, … Jusqu'à la fabrication de code offusqué qui ne sont que des AES avec une clef à l'intérieur comme pourrait le faire de la propagation de constante lors de compilation.
Le comportement du code pouvant changer selon les données, il est difficile d'être aussi tranché.
"La première sécurité est la liberté"
[^] # Re: DRM
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Vers l'abandon de Silverlight et de Flash. Évalué à 10.
La question est plus technique. Comment faire un DRM standard, sachant que le concept même de DRM efficace est antagoniste avec le fait d'avoir des sources ouvertes.
"La première sécurité est la liberté"
[^] # Re: Wow
Posté par Nicolas Boulay (site web personnel) . En réponse au message [JOB] Embedded Linux Engineer - Lyon, Massy ou Etranger - Adeneo Embedded. Évalué à 1.
BSP, c'est board support package. C'est en gros les drivers bas niveau pour faire tourner une carte embarqué, car même si 2 cartes utilisent un cpu identique comme 2 PC utilise un x86, le PC dispose de tout un tas de composant standard (BIOS, démarrage, RTC, lien série, PCI) qui aide au démarrage et aux choix dynamiques des drivers, ce qui n'existe pas dans une carte typique embarqué (suffit de regarder la tête du sous-système ARM sous linux).
D'ailleurs, je n'ai jamais compris pourquoi ARM n'imposait pas quelques périphériques standard pour faciliter le port des OS (un moyen de boot, un lien série, une RTC et une énumération des périphériques serait le minimum).
nico, dev d'un driver linux pour tester M-Shield de TI
"La première sécurité est la liberté"
[^] # Re: Les fonctionnalites tactiles...
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Deux nouvelles pour Qt. Évalué à 10.
Ecran ductile ?
"La première sécurité est la liberté"