Je veux bien que tes trips ressentes les basses mais pas les aigües !
"le son du microsillon est plus chaud, j'en connais des masses"
C'est le cas ! Le microsillon tout comme les amplis à lampes déforment énormément le son : la courbe d'amplification n'est pas plate et à tendance à compacter le spectre.
Je sais c'est "Hipe" d'avoir un ampli à tubes. Mais je suis sur que cela doit être possible d'avoir le même son avec un effet numérique... Mais, c'est sûr cela sera moins jolie sur la commode.
Et la source, elle ne s'arrête pas à 22khz! Le Super-Audio CD monte à 100khz
96 khz et 24 bits, il me semble. 144dB de rapport signal sur bruit contre 96 pour un CD 16 bits.
Manque de bol, quasiment aucun enregistrement est fait à la base pour cette précision. Un des gros problème est l'application de filtre anti souffle qui détruise les hautes fréquences et les détails. Le silence est en effet autour de 70 dB.
Et d'ailleurs un très bon ampli ne restitue rarement plus que 100/110 db de snr sois en gros le SNR de 19 bits ...
Et le sur-echantillonnage permet justement à des CD classiques de monter à 50khz.
C'est ça que j'appelle la branlette. Comment tu veux tiré de l'information supplémentaire d'une source limité à 22khz !
Pour avoir cherche un ampli audiophile pas trop mal, j'ai pu me rendre compte a quel point le monde de l'audiophile se confine a de la bonne branlette, les nerds avec le Ghz a cote, c'est vraiement des rigolo !
Les trucs genre mp3/ogg coupe a 16khz sans que cela fasse hurler.
L'exemple typique concerne les cables audio, le top du top est le cable OFC de 2.5mm2 a 3e le m. C'est deja chere mais tu entends la difference... or tu trouves des cables a 10 000e ! Evidement personne ne veut faire de teste en double aveugle avec...
Bref ton 1 et ton 2, c'est pour les personnes qui font le concours de la plus grosse. A quoi sert de monter a 50 khz si ta source s'arrete a 22Khz ? A rajouter du bruit ?
Quand a l'histoire de surechantillonage, je crois que tu dois te melanger. On parle de source numerique ! Du point de vue qualite, tu as la tenu de l'horloge (le jitter) et le fait de ne pas faire d'erreur de lecture (correction en tenant compte du codage reed solomon). Et rien d'autre.
Pour ton histoire de lissage, tu devrair relir le theoreme de shannon...
"Bien entendu. Mais pourquoi un compilo C le fait par fichier .c ?"
J'en sais trop rien. Sans doute une histoire de limitation des compilateurs C à l'époque ou l'on avait 512Ko de mémoire.
On est d'accord. Mais comment allez vous gérer l'intégration avec le langage C que vous proposez dans le langage ? Dès qu'un bout de code apparaît vous désactivez quelles optimisations ?
L'inclusion du C permet la réutilisation de lib, il ne faut pas chercher plus loin...
Tu crois que dans l'embarqué ils ne se soucient pas du tout de la modularité, de la lisibilité du code ?
C'est aussi l'intérêt d'un langage de haut niveau par rapport au C.
Dans un cas, on parle d'un compilo de haut niveau qui peut gérer différentes structures de controle et dans l'autre, il s'agit de lib wraper dans du sucre syntaxique par modif du compilo.
Au final, à part que la solution 2 est moche, je ne vois pas vraiment de différence.
"Le code c'est quoi dans un projet, à allez à la louche 25% du temps ? gagner 20% de temps sur 25% d'un projet ? C'est où la révolution ?"
On ne doit pas bosser sur les mêmes projets...
"Ca ne répond en rien à la problématique que j'ai posée concernant lea divergeance d'intérêt entre les algos d'optimisation globale et le besoin de modularité..."
Quand tu es au niveau d'optimisation d'une lib, tu peux déjà faire beaucoup plus que le faire par fichier .c comme le C actuellement. C'est un boulot prévus cette année, il me semble, la modularité.
"avant de chercher à optimiser, il faut voir le gain global potentiel par rapport à l'effort mis en place, c'est pour ca que j'essai de replacer dans un contexte réel les gains potentiels d'optimisation que pourrait apporter Lisaac..."
Je ne vois pas de quoi tu parles. De l'effort sur un programme particulier ou sur le compilo ? C'est évidement vrai pour un programme particulier. C'est faux pour le compilo dont les efforts bénéficient à tous les programmes.
"1- La question doit être posée différement : quelle est la difficulté de constuire un programme "optimale" en Lissac par rapport à la difficulité d'optimiser un code en C ?
Autre question : 2 - pourquoi les mêmes optimisations ne peuvent-elles pas être appliquées à un autre langage ?
Mince tu viens d'avoir une crise d'intelligence ! C'est les 2 points essentiels qui ont amené la création de Lisaac.
Lisaac ayant une sémantique de plus haut niveau, le compilo peut faire plus de choses que dans d'autres langages. Le principe de l'algo d'étude du flot peut marcher sur tous les langages je pense. Il marche bien avec Lisaac, c'est un plus.
Niveau optimisation automatique, il y a plein de choses infaisables en C : notamment, tu ne peux pas toucher le layout mémoire des données, or pour la vectorisation automatique cela peut être nécessaire. L'utilisation de pointeur te fait pointer sur un trou noir et les alias peuvent être compliqué à détecté.
"T'as émis l'hypothèse que tu comprenais pas ce que je disais ou qu'on parlait pas de la même chose ?"
Tu parlais de l'embarqué d'une façon un peu "à coté de la plaque". Dans l'embarqué, tu veux un code qui marche, un développement rapide, une empreinte mémoire minimum.
Il n'y a aucun intérêt à personnalisé cela. Je ne comprends pas pourquoi tu te focalise la dessus. Le seul intérêt est d'avoir un compilo qui ne comprends que l'évaluation retardé de blocs, ainsi tout le reste est dans la lib. Le compilo est donc hyper simplifié et peut donc faire des choses puissante comme la preuve.
"mais tu as de grosses lacunes en informatique théorique.
et toi en informatique pratique."
Ontologia bosse pour un éditeur il me semble...
Cela dit je reste perplexe : la quantité de ligne de code n'est pas un critère révolutionnaire à mon sens
Manque de bol pour toi, il a été prouvé que le nombre de ligne de code est directement proportionnel au temps passé à écrire/valider le truc.
Que cela soit en C, en Perl, en assembleur, c'est le nombre de ligne qui détermine le temps passé et quelques soit le langage.
Donc, c'est évidement un argument primordial en développement logiciel.
Je critiquais le côté "trop ouvert" des constructions syntaxique de Lisaac
Mais qu'est-ce que l'on s'en fout ! Dans n'importe qu'elle langage tu peux écrire des horreurs, pourquoi cela serait différent en Lisaac ?
"Concernant la vitesse, je doute que vous obteniez des gains exceptionnel style de facteur 4 ou 5. Peut être dans certains contexte bien précis vous obtiendrez 50% de perf en plus (peut être plus j'en sais rien), mais a-t-on vraiment besoin de ça ?"
toi peut-être pas...
"Parcqu'un OS c'est pas un simple encodeur."
Et là paf, tu passes pour une andouille. sisi. Isaac est un projet d'OS, à la base. Et il tourne déjà très bien...
"Peut être dans certains contexte bien précis vous obtiendrez 50% de perf en plus (peut être plus j'en sais rien), mais a-t-on vraiment besoin de ça ?"...
"Et à part leur promettre 20% de gains de perf potentiel, quel intérêt auront-ils à utiliser un nouveau langage ?" ..."Si vous partez dans des délires d'optimisations qui font gagner encore 3 ou 5% de perf par ci par là"
On a compris que tu ne comprends rien à l'optimisation, c'est pas la peine de l'étaler autant. Dans certain cas, tu peux avoir des facteurs 10 entre un mauvais et un bon code. Le but de lisaac sera d'avoir le bon code. Donc, certe, entre un code C tuné à mort et lisaac, tu aura 1% de mieux en lisaac (et 30% de ligne de code en moins). Mais entre du C normal et du Lisaac, tu pourras avoir des facteurs 2 ou plus.
"Sans parler du fait que même dans le monde de l'embarqué des critères comme la portabilité et la sécurité peuvent être mis en avant..."
Pourquoi tu parles de trucs qui tu ne connais pas ? La portabilité pour un code qui ne bougera pas... Certe java commence à arriver, mais c'est tellement rien en comparaison de tous les trucs en C !
J'imagine que pour la sécurité, tu parles de la sureté de fonctionnement et non d'attaque logiciel... Cela n'aurait rien à voir et surtout on s'en fout beaucoup dans l'embarqué, c'est rare d'avoir un train ou une voiture branché sur internet...
"Quel va être l'intérêt du gain de perf sachant que le gros boulot d'optimisation sera surtout à faire au niveau de la VM ?"
C'est évident que les optimisations de haut niveau n'ont aucun intérêt. C'est bien connu... sic... (surtout pour un langage qui à la base crache du C, re-sic)
Il n'y pas encore de mode strict, mais cela n'est pas le plus compliqué à utilisé même si cela a peu de sens. Lisaac n'est pas prévus pour tourner dans une jvm, sont but est d'être un langage rapide (+ que le C) et productif (que ruby/perl/python).
Si tu parles sécurité, c'est d'un point de vue attaquant. Je préfaire parler de respect de la spec. C'est déjà énorme par rapport à ce qui existe actuellement.
Tous les discussions qu'il y a ici, c'est pour prendre la température et avoir des avis de personne diverse et varié. Et si on ne parle pas plus des features à venir, c'est parce qu'elle n'existe pas encore.
Ontologia balance ses réflexions pour avoir du retour. Le but n'est pas de faire de la pub pour Lisaac. Ce qui est horripilant de ta part, c'est de condamner le langage sans le moindre doute, en y connaissant si peu.
Si tu veux, l'auteur de Lisaac est à situer entre ceux de Java, des pures codeurs, et ceux de OCaml des pures universitaires. Benoit est dans la catégorie pur codeur universitaires... Il utilises ses outils tous les jours et connait les concepts avancé "universitaires". Cela fait la différence.
Je sais pas si ca a changé depuis la dernière fois que je me suis intéressé aux specs du langage, mais dans mes souvenirs on pouvait allègrement mixé du Lisaac avec du code écrit en C. Partant de là, niveau preuve et sécu...
C'est évident que rien ne sera prouvé sur le C ! et on ne parle pas de sécurité mais de prouver les contrats, cela n'a à peu pret rien voir.
" Tu crois que les lib fleuves sont l'aboutissement de tout langage ?"
C'est quoi le rapport ?
Le même rapport qu'il y a avec "comme il est sans doute possible de le faire en Lisaac, mais ce dernier ne va pas apporter grand chose comme a pu apporter la locomotive par rapport à la charrette."
En fait, les principales protections contre les flash sont logiciels en "étalant l'exécution" pour détecter une erreur de cohérence. Pas mal. Mais, générer une erreur est déjà une information en soit.
La grille est inefficace pour les attaques laser, puisque l'on a accès au dessous de la puce, qui n'est pas protégé.
Je suis heureux de lire en enfin quelqu'un qui écrit : "Etant donné un équipement illimité et un temps illimité, c'est toujours le craqueur qui va gagner. " C'est pour relativiser ceux qui pense que la carte à puce est inviolable...
Il existe des cartes qui résistent à ses attaques ? J'aimerais bien savoir comment.
Pour info, le laser s'amuse à faire changer de localement la valeur d'un bit. Cela permet de modifier l'état interne de la puce et de faire plein de chose.
Les contre mesure que j'imagine, c'est des photodiodes qui détectent le laser et qui bloquent définitivement la carte. Mais qu'est-ce qui empêche de prendre une autre carte et de taper à coter de la photodiode ?
"Une preuve fausse n'a pas beaucoup d'intérêt."
Si, on sait qu'on peut foutre le programme à la poubelle, ou au moins le corriger pour le rendre valide.
Je dirais même plus, c'est le plus utile !
Il est souvent beaucoup plus facile de trouver un contre exemple à un moteur de preuve que de d'assurer que l'ensemble des possibles est couvert.
De plus, d'un point de vue psychologie d'un programmeur, on comprend mieux une erreur avec le contre exemple qui force la correction. Si le programme rend "prouvé", il y a beaucoup de monde qui n'y croira pas.
Cela signifie qu'il vaut mieux chercher "large" que tenter de prouver complètement des bouts minuscules.
Les 2 téchniques que je connais c'est la résolution d'équation logiques SAT et les BDD (parcoure de tous les états possible).
C'est le moyen de faire une preuve "définitive" mais qui finit toujours par exploser en temps. Dans ce cas, des méthodes basé sur un montecarlo peut tout à fait fonctionner pour trouver un contre exemple.
[^] # Re: GLMF bizarre!
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Revue de presse - janvier 2008. Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: GLMF bizarre!
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Revue de presse - janvier 2008. Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Son
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Revue de presse - janvier 2008. Évalué à 5.
"le son du microsillon est plus chaud, j'en connais des masses"
C'est le cas ! Le microsillon tout comme les amplis à lampes déforment énormément le son : la courbe d'amplification n'est pas plate et à tendance à compacter le spectre.
Je sais c'est "Hipe" d'avoir un ampli à tubes. Mais je suis sur que cela doit être possible d'avoir le même son avec un effet numérique... Mais, c'est sûr cela sera moins jolie sur la commode.
Et la source, elle ne s'arrête pas à 22khz! Le Super-Audio CD monte à 100khz
96 khz et 24 bits, il me semble. 144dB de rapport signal sur bruit contre 96 pour un CD 16 bits.
Manque de bol, quasiment aucun enregistrement est fait à la base pour cette précision. Un des gros problème est l'application de filtre anti souffle qui détruise les hautes fréquences et les détails. Le silence est en effet autour de 70 dB.
Et d'ailleurs un très bon ampli ne restitue rarement plus que 100/110 db de snr sois en gros le SNR de 19 bits ...
Et le sur-echantillonnage permet justement à des CD classiques de monter à 50khz.
C'est ça que j'appelle la branlette. Comment tu veux tiré de l'information supplémentaire d'une source limité à 22khz !
"La première sécurité est la liberté"
[^] # Re: GLMF bizarre!
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Revue de presse - janvier 2008. Évalué à 4.
Les trucs genre mp3/ogg coupe a 16khz sans que cela fasse hurler.
L'exemple typique concerne les cables audio, le top du top est le cable OFC de 2.5mm2 a 3e le m. C'est deja chere mais tu entends la difference... or tu trouves des cables a 10 000e ! Evidement personne ne veut faire de teste en double aveugle avec...
Bref ton 1 et ton 2, c'est pour les personnes qui font le concours de la plus grosse. A quoi sert de monter a 50 khz si ta source s'arrete a 22Khz ? A rajouter du bruit ?
Quand a l'histoire de surechantillonage, je crois que tu dois te melanger. On parle de source numerique ! Du point de vue qualite, tu as la tenu de l'horloge (le jitter) et le fait de ne pas faire d'erreur de lecture (correction en tenant compte du codage reed solomon). Et rien d'autre.
Pour ton histoire de lissage, tu devrair relir le theoreme de shannon...
"La première sécurité est la liberté"
[^] # Re: C'est trop compliqué !
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Des langages de haut niveau. Évalué à 2.
Le même genre d'optim que fait gcc quand on inclue de l'asm : aucune.
"La première sécurité est la liberté"
[^] # Re: C'est trop compliqué !
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Des langages de haut niveau. Évalué à 2.
J'en sais trop rien. Sans doute une histoire de limitation des compilateurs C à l'époque ou l'on avait 512Ko de mémoire.
On est d'accord. Mais comment allez vous gérer l'intégration avec le langage C que vous proposez dans le langage ? Dès qu'un bout de code apparaît vous désactivez quelles optimisations ?
L'inclusion du C permet la réutilisation de lib, il ne faut pas chercher plus loin...
Tu crois que dans l'embarqué ils ne se soucient pas du tout de la modularité, de la lisibilité du code ?
C'est aussi l'intérêt d'un langage de haut niveau par rapport au C.
"La première sécurité est la liberté"
[^] # Re: C'est trop compliqué !
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Des langages de haut niveau. Évalué à 2.
Au final, à part que la solution 2 est moche, je ne vois pas vraiment de différence.
"La première sécurité est la liberté"
[^] # Re: C'est trop compliqué !
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Des langages de haut niveau. Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: C'est trop compliqué !
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Des langages de haut niveau. Évalué à 2.
On ne doit pas bosser sur les mêmes projets...
"Ca ne répond en rien à la problématique que j'ai posée concernant lea divergeance d'intérêt entre les algos d'optimisation globale et le besoin de modularité..."
Quand tu es au niveau d'optimisation d'une lib, tu peux déjà faire beaucoup plus que le faire par fichier .c comme le C actuellement. C'est un boulot prévus cette année, il me semble, la modularité.
"avant de chercher à optimiser, il faut voir le gain global potentiel par rapport à l'effort mis en place, c'est pour ca que j'essai de replacer dans un contexte réel les gains potentiels d'optimisation que pourrait apporter Lisaac..."
Je ne vois pas de quoi tu parles. De l'effort sur un programme particulier ou sur le compilo ? C'est évidement vrai pour un programme particulier. C'est faux pour le compilo dont les efforts bénéficient à tous les programmes.
"1- La question doit être posée différement : quelle est la difficulté de constuire un programme "optimale" en Lissac par rapport à la difficulité d'optimiser un code en C ?
Autre question : 2 - pourquoi les mêmes optimisations ne peuvent-elles pas être appliquées à un autre langage ?
Mince tu viens d'avoir une crise d'intelligence ! C'est les 2 points essentiels qui ont amené la création de Lisaac.
Lisaac ayant une sémantique de plus haut niveau, le compilo peut faire plus de choses que dans d'autres langages. Le principe de l'algo d'étude du flot peut marcher sur tous les langages je pense. Il marche bien avec Lisaac, c'est un plus.
Niveau optimisation automatique, il y a plein de choses infaisables en C : notamment, tu ne peux pas toucher le layout mémoire des données, or pour la vectorisation automatique cela peut être nécessaire. L'utilisation de pointeur te fait pointer sur un trou noir et les alias peuvent être compliqué à détecté.
"T'as émis l'hypothèse que tu comprenais pas ce que je disais ou qu'on parlait pas de la même chose ?"
Tu parlais de l'embarqué d'une façon un peu "à coté de la plaque". Dans l'embarqué, tu veux un code qui marche, un développement rapide, une empreinte mémoire minimum.
"La première sécurité est la liberté"
[^] # Re: Dune le livre
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Nostalgie avec Dune. Évalué à 2.
C'est le designer d'Alien non ?
"La première sécurité est la liberté"
[^] # Re: C'est trop compliqué !
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Des langages de haut niveau. Évalué à 2.
Il n'y a aucun intérêt à personnalisé cela. Je ne comprends pas pourquoi tu te focalise la dessus. Le seul intérêt est d'avoir un compilo qui ne comprends que l'évaluation retardé de blocs, ainsi tout le reste est dans la lib. Le compilo est donc hyper simplifié et peut donc faire des choses puissante comme la preuve.
"La première sécurité est la liberté"
[^] # Re: C'est trop compliqué !
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Des langages de haut niveau. Évalué à 2.
"mais tu as de grosses lacunes en informatique théorique.
et toi en informatique pratique."
Ontologia bosse pour un éditeur il me semble...
Cela dit je reste perplexe : la quantité de ligne de code n'est pas un critère révolutionnaire à mon sens
Manque de bol pour toi, il a été prouvé que le nombre de ligne de code est directement proportionnel au temps passé à écrire/valider le truc.
Que cela soit en C, en Perl, en assembleur, c'est le nombre de ligne qui détermine le temps passé et quelques soit le langage.
Donc, c'est évidement un argument primordial en développement logiciel.
Je critiquais le côté "trop ouvert" des constructions syntaxique de Lisaac
Mais qu'est-ce que l'on s'en fout ! Dans n'importe qu'elle langage tu peux écrire des horreurs, pourquoi cela serait différent en Lisaac ?
"Concernant la vitesse, je doute que vous obteniez des gains exceptionnel style de facteur 4 ou 5. Peut être dans certains contexte bien précis vous obtiendrez 50% de perf en plus (peut être plus j'en sais rien), mais a-t-on vraiment besoin de ça ?"
toi peut-être pas...
"Parcqu'un OS c'est pas un simple encodeur."
Et là paf, tu passes pour une andouille. sisi. Isaac est un projet d'OS, à la base. Et il tourne déjà très bien...
"Peut être dans certains contexte bien précis vous obtiendrez 50% de perf en plus (peut être plus j'en sais rien), mais a-t-on vraiment besoin de ça ?"...
"Et à part leur promettre 20% de gains de perf potentiel, quel intérêt auront-ils à utiliser un nouveau langage ?" ..."Si vous partez dans des délires d'optimisations qui font gagner encore 3 ou 5% de perf par ci par là"
On a compris que tu ne comprends rien à l'optimisation, c'est pas la peine de l'étaler autant. Dans certain cas, tu peux avoir des facteurs 10 entre un mauvais et un bon code. Le but de lisaac sera d'avoir le bon code. Donc, certe, entre un code C tuné à mort et lisaac, tu aura 1% de mieux en lisaac (et 30% de ligne de code en moins). Mais entre du C normal et du Lisaac, tu pourras avoir des facteurs 2 ou plus.
"Sans parler du fait que même dans le monde de l'embarqué des critères comme la portabilité et la sécurité peuvent être mis en avant..."
Pourquoi tu parles de trucs qui tu ne connais pas ? La portabilité pour un code qui ne bougera pas... Certe java commence à arriver, mais c'est tellement rien en comparaison de tous les trucs en C !
J'imagine que pour la sécurité, tu parles de la sureté de fonctionnement et non d'attaque logiciel... Cela n'aurait rien à voir et surtout on s'en fout beaucoup dans l'embarqué, c'est rare d'avoir un train ou une voiture branché sur internet...
"La première sécurité est la liberté"
[^] # Re: DES?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Bye bye les tags mifare. Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: C'est trop compliqué !
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Des langages de haut niveau. Évalué à 2.
C'est évident que les optimisations de haut niveau n'ont aucun intérêt. C'est bien connu... sic... (surtout pour un langage qui à la base crache du C, re-sic)
"La première sécurité est la liberté"
[^] # Re: Du RPM warez !!!
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Nostalgie avec Dune. Évalué à 5.
"La première sécurité est la liberté"
[^] # Re: Ha, ça tombe bien…
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Nostalgie avec Dune. Évalué à 4.
"La première sécurité est la liberté"
[^] # Re: C'est trop compliqué !
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Des langages de haut niveau. Évalué à 2.
Si tu parles sécurité, c'est d'un point de vue attaquant. Je préfaire parler de respect de la spec. C'est déjà énorme par rapport à ce qui existe actuellement.
Tous les discussions qu'il y a ici, c'est pour prendre la température et avoir des avis de personne diverse et varié. Et si on ne parle pas plus des features à venir, c'est parce qu'elle n'existe pas encore.
Ontologia balance ses réflexions pour avoir du retour. Le but n'est pas de faire de la pub pour Lisaac. Ce qui est horripilant de ta part, c'est de condamner le langage sans le moindre doute, en y connaissant si peu.
Si tu veux, l'auteur de Lisaac est à situer entre ceux de Java, des pures codeurs, et ceux de OCaml des pures universitaires. Benoit est dans la catégorie pur codeur universitaires... Il utilises ses outils tous les jours et connait les concepts avancé "universitaires". Cela fait la différence.
"La première sécurité est la liberté"
[^] # Re: DES?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Bye bye les tags mifare. Évalué à 2.
Il avait le code source ? Ils ont bossé en boite blanche ? Combien de samples ?
(à part ça, 4 semaines, c'est hyper court...) 6 mois, c'est autre chose.
"La première sécurité est la liberté"
[^] # Re: C'est trop compliqué !
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Des langages de haut niveau. Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: C'est trop compliqué !
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Des langages de haut niveau. Évalué à 2.
Cela me fait marrer de lire ça ! Surtout sans rien connaitre de Lisaac ou presque et de sa todo list.
"La première sécurité est la liberté"
[^] # Re: C'est trop compliqué !
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Des langages de haut niveau. Évalué à 2.
C'est évident que rien ne sera prouvé sur le C ! et on ne parle pas de sécurité mais de prouver les contrats, cela n'a à peu pret rien voir.
" Tu crois que les lib fleuves sont l'aboutissement de tout langage ?"
C'est quoi le rapport ?
Le même rapport qu'il y a avec "comme il est sans doute possible de le faire en Lisaac, mais ce dernier ne va pas apporter grand chose comme a pu apporter la locomotive par rapport à la charrette."
"La première sécurité est la liberté"
[^] # Re: DES?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Bye bye les tags mifare. Évalué à 2.
La grille est inefficace pour les attaques laser, puisque l'on a accès au dessous de la puce, qui n'est pas protégé.
Je suis heureux de lire en enfin quelqu'un qui écrit : "Etant donné un équipement illimité et un temps illimité, c'est toujours le craqueur qui va gagner. " C'est pour relativiser ceux qui pense que la carte à puce est inviolable...
"La première sécurité est la liberté"
[^] # Re: bon
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Soekris sous linux. Évalué à 2.
http://f-cpu.seul.org/~nico/astromech/astrolinux/astrolinux.(...)
"La première sécurité est la liberté"
[^] # Re: DES?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Bye bye les tags mifare. Évalué à 2.
Il existe des cartes qui résistent à ses attaques ? J'aimerais bien savoir comment.
Pour info, le laser s'amuse à faire changer de localement la valeur d'un bit. Cela permet de modifier l'état interne de la puce et de faire plein de chose.
Les contre mesure que j'imagine, c'est des photodiodes qui détectent le laser et qui bloquent définitivement la carte. Mais qu'est-ce qui empêche de prendre une autre carte et de taper à coter de la photodiode ?
"La première sécurité est la liberté"
[^] # Re: C'est trop compliqué !
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Des langages de haut niveau. Évalué à 2.
Si, on sait qu'on peut foutre le programme à la poubelle, ou au moins le corriger pour le rendre valide.
Je dirais même plus, c'est le plus utile !
Il est souvent beaucoup plus facile de trouver un contre exemple à un moteur de preuve que de d'assurer que l'ensemble des possibles est couvert.
De plus, d'un point de vue psychologie d'un programmeur, on comprend mieux une erreur avec le contre exemple qui force la correction. Si le programme rend "prouvé", il y a beaucoup de monde qui n'y croira pas.
Cela signifie qu'il vaut mieux chercher "large" que tenter de prouver complètement des bouts minuscules.
Les 2 téchniques que je connais c'est la résolution d'équation logiques SAT et les BDD (parcoure de tous les états possible).
C'est le moyen de faire une preuve "définitive" mais qui finit toujours par exploser en temps. Dans ce cas, des méthodes basé sur un montecarlo peut tout à fait fonctionner pour trouver un contre exemple.
"La première sécurité est la liberté"