JN a écrit 30 commentaires

Alors, c'est moutarde, ciboulette, coriandre, cayenne, poivre,…

Je n'y connais pas grand-chose en matière de chiffrement, mais je me demande si on ne pourrait pas avoir un système à 2 clés, l'une pour ouvrir et l'autre pour détruire les données?

La première règle dans le post-mortem, c'est de copier les données et de travailler hors du système d'origine. Donc, j'imagine que l'utilisation de la clé fournie se fera sur un système en lecture seule de la police judiciaire. Donc, adieu toute idée d'activer un fonction d'effacement…

Pour les logiciels, on utilise les outils proposés par le quadriciel d'internationalisation, mais pour le texte, comment vous-y prenez-vous ? Comment suivre les évolutions du texte par la suite ?

Par exemple, la doc de Git est écrite en asciidoc : à part po4a, il n'y a pas grand'chose qui puisse faire le boulot de gérer les évolutions en encore, ce n'est pas mirobolant (les saveurs d'asciidoc trompent quelque fois l'extraction des textes).

Je serais curieux de connaitre les outils/méthodes utilisées par ailleurs…

Certaines boîtes du vrai monde annonce la conformité xkcd 806, ce qui n'est pas une mince affaire.

Parce qu’on n’imaginait pas à l’époque le genre d’attaques par canaux cachés que l’on imagine à présent.

Peut-être que les ingénieurs de l’époque étaient nuls, peut-être qu’ils étaient tous achetés par la NSA. Ou peut-être qu’ils n’avaient pas le bénéfice des quinze dernières années de recherche.

Enfin, les recherches sur les canaux cachés ne sont pas neuves non plus.

Mon sentiment sur cet épisode regrettable :

Sans avoir idée des moyens de les mettre à profit, une énumération à froid de tout ce qui n'est pas effacé lors des changements de contexte suffirait à savoir ce qui est à risque et ce qu'il faut protéger en particulier. Pour les canaux cachés (enfin pas tant que ça, quand on parle de cache), tout ce qui n'est pas explicitement permis devrait être interdit. Facile à dire, je le concède, mais le principe est simple.

Dans l'industrie manufacturière, on a un mantra : "sécurité d'abord". Pour l'informatique, c'est "sûreté d'abord" mais on a franchement l'impression que les fondeurs n'ont pas cherché à suivre les nouveautés en matière de sécurité. Et on ne parle pas de petite startup avec 3 pelés et pas de moyens. La réflexion de Torvalds me paraît amplement méritée.

Un petit bout, et encore, pas forcément stabilisé…

Un truc que je ne comprends pas : en regardant le fil sur LKLM, on voit ça,c'est-à-dire des patchs qui sont encore en cours de discussion sur une première proposition, alors qu'on est en fenêtre de stabilisation. Il y a eu un embargo de 6 mois, et on n'en est que là ?

À ce régime, comment peut-on annoncer que les kernels patchés seront dans nos distros sous peu ?

Je pense que la certification doit se focaliser sur la protection des données. Donc, les données doivent être structurées et enrichies de telle manière à garantir au maximum que toute altération apparaîtra clairement. Le code qui fait tourner ça est sans intérêt, parce qu'il reste modifiable, ou imitable.

Je ne vois pas en quoi un logiciel propriétaire pourrait fournir plus de garantie. À moins qu'on parle de sécurité par l'obscurité, mais dans ce cas, on n'est même pas à l'obligation de moyen…

Donc, mis à part une protection du journal d'évènements par procédé cryptographique (type chaîne de hashs), en y ajoutant l'inclusion d'éléments externes ( références de transactions CB, virements), je ne vois aucun système capable d'être garanti sans possibilité de détournement. Avec la bonne dose de volonté, il est toujours possible de réécrire l'histoire et que celle-ci ait l'air véritable.

Le gestionnaire de paquets de OCaml, Opam contient une extension depext qui permet depuis Opam de vérifier les dépendances système et le cas échéant indiquer quels paquets systèmes supplémentaires sont nécessaires pour pouvoir compiler et installer le paquet opam demandé.

Sous ma Debian, ça marche®, mais je ne sais pas si cette option ne pourrait pas être "généralisée" pour uniformiser et industrialiser le protocole de dépendances entre les systèmes à paquet des distrib et ceux "embarqués" pour les écosystèmes.

Juste une question: Pourquoi déclarer un type fantôme si on utilise déjà les modules et les types masqués ?

Et du coup, ça veut aussi dire qu'on ne peut plus passer une paire pré-existante au constructeur. Par contre le message d'erreur est vraiment contre-intuitif…

# type bar = Bar of int *int;;
type bar = Bar of int * int
# let x = (1, 2);;
val x : int * int = (1, 2)
# let y = Bar x;;
Error: The constructor Bar expects 2 argument(s),
but is applied here to 1 argument(s)
# let y = Bar (1,2);;
val y : bar = Bar (1, 2)

Sur la dernière ligne, on comprends qu'on passe un argument unique, qui est une paire…

Ça me fait penser au documentaire sur "une autre histoire d'Internet" où la voix off dit à un moment qu'à force, il fallait bien qu'il arrive que les hackers s'attaquent à la politique (parti pirate, CCC, la quadrature du net). Pourquoi pas essayer de s'y attaquer de l'intérieur, même si je doute fort qu'on puisse faire bouger la bouse de l'intérieur…

Je m'étais déjà attaqué aux deux problèmes…

Enfin, cette deuxième session bénéficie déjà de toutes les corrections apportées aux problèmes soulevés lors de la première.

Tu veux prendre de l'avance :-p ?

Je ne pense pas dévoiler beaucoup en disant que l'un tourne autour des chaînes de Markov et que l'autre propose de chercher la solution à un jeu de combinaisons.

Ce sont des problèmes suffisamment généraux et contenus pour que le développement de la solution ne nécessite pas d'apprentissage d'API.

Je ne vois aucune différence avec la première session au niveau programme.

C'est surtout au niveau exercices que je serais intéressé, parce que c'est plutôt là que la répétition manquera d'intérêt, même si je ne me fais pas d'illusion.

Une chose particulièrement frappante concernant les exercices, c'est qu'on utilise l'interpréteur compilé en javascript vers javascript directement dans notre navigateur web. Pas besoin d'installation (tout au moins au début) pour faire exercices, les faire tourner et les envoyer au test ! Enfin, à un moment, on préfère quand même éditer son code dans un vrai éditeur, surtout pour le projet final.

Les sous-titrages français ont été réalisés en parallèle de leur publication, par les élèves. Rien de répréhensible. Je préfère la version originale, surtout si la présentation contient déjà beaucoup de texte qu'il faut lire aussi.

Pour la suite, j'imagine qu'il ne doit pas être simple de monter MOOC.

Di Cosmo annonce dans sa lettre qu'il y a déjà 1600 inscrits. Pas mal !

J'ai participé à la première session du MOOC et ça a vraiment été un moment d'apprentissage intense. Pour les anciens qui n'ont connu que le paradigme objet, la marche peut être assez haute et le choc intellectuel assez déstabilisant. Les temps annoncés pour le suivi sont très en dessous de ce que j'ai du y passer, mais quand on aime, on ne compte pas… Je pense même rempiler (est-ce que le contenu de cette deuxième session est totalement identique à celui de la première ?).

Le point un peu ennuyeux reste que le cours est dispensé en anglais par des non anglophones, ce qui a tendance à le rendre plus difficile à comprendre. Mais le code parle de lui-même ;-).

Dans tous les cas, je le conseillerais sans aucune retenue à toute personne ayant déjà un peu tâté du développement logiciel, que ce soit dans des langages impératifs conventionnels ou des langages de script dynamiques non typés.

À la fin du MOOC, il était question de faire un second opus plus orienté sur la programmation asynchrone. A-t-on des nouvelles ?

Justement, c'est ça le plus étonnant, la macro-économie est dérivée de la micro-économie, comme si c'était logique.

Document intéressant par plusieurs aspects :

• C'est une critique de la première édition. Dans la seconde, Keen explique qu'il a essayé de répondre aux diverses critiques et remarques sur la première édition. Il en parle à plusieurs reprises, mais il manquait le contenu de ces remarques.
• La critique reste bien ancrée sur des conceptions que Keen a rejetées. De mon point de vue, il reste une incompréhension due à un changement de paradigme que les auteurs n'ont pas pas franchi (par ex., l'utilisation de "ceteris paribus"). D'ailleurs, ils qualifient Keen de néoclassique…
• L'accusation d'idéologie est plutôt drôle, je trouve, car Keen ne se défend pas d'idéologie, mais accuse les néoclassiques de s'en défendre !
• Je crois me rappeler que dans la seconde édition, les autrichiens ont aussi droit à leur ration d'étrillage… Juste retour des choses non ? ;-)

Au final, je ne prétends pas que Keen détienne la Vérité. Lui-même considère que son modèle a des défauts, comme l'absence de l'action gouvernementale, des schémas de Ponzi ou de l'énergie (ce que Gaël Giraud intègre). Néanmoins, il met clairement en lumière les trous encore plus béants de la théorie néoclassique, prônée et mise en pratique par les directeurs successifs des grandes banques centrales (ils en prennent pour leur grade), et a le mérite de chercher à proposer une alternative réaliste, qui a déjà apporté des résultats dans la vraie vie.

S'il y a des erreurs, ce sont sûrement les miennes, pas les siennes.

Ce n'était pas sur ces cycles que Keen reprend Marx, mais sur l'origine de la plus-value. Je me suis trompé et j'avoue que sur cette partie, je n'ai pas été aussi attentif.

Pour l'orthographe, comme noté dans le journal, on peut aussi indiquer à emacs les sections de texte qu'il ne faut pas passer au correcteur. Comme c'est une liste de regexp qui peut matcher sur plusieurs lignes, c'est suffisamment puissant pour la plupart des markup.

Pour la grammaire, c'est un peu ce qui manque à langtool, parce qu'il fait beaucoup de faux positifs sur les blocs de code.

ça avance :

http://www.dicollecte.org/thread.php?prj=fr&t=471

Apparemment, on aura une version autonome à tester sous peu.

C'est pas trolldi aujourd'hui ?

Sérieusement, pour saisir du texte au kilomètre (mode traitement de texte) en LaTeX, ou tout système de markup, je ne vois pas mieux qu'un éditeur de texte bien configuré.

1998, achat d'un PII chez un assembleur, je ne voulais pas d'OS préinstallé.

RH5 avec un CD trouvé dans un périodique… avec l'objectif d'avoir rapidement Spice pour faire de la simulation électronique et scilab pour quelques calculs de traitement de signal. Et bien sur, la joie de pouvoir à nouveau coder avec Emacs. Tout ce qui m'était inaccessible sur le poste de travail du boulot.

Et pas mal d'heures de lecture sur le "sag" (System Administration Guide), une des premières documentations que j'aie lue intégralement sur support informatique…

Aïe ! J'ai mal lu la question. J'ai confondu "processeur" et "professeur" ! Ça a fini en Z80, alors que c'est plutôt ARM aujourd'hui… D'ailleurs, ça vaudrait bien le coup de refaire un sondage sur le "processeur professeur".