Nicolas Boulay a écrit 16010 commentaires

Sauf qu'un humain mettra infiniment plus de temps à le générer que le compilo Lisaac.

"La première sécurité est la liberté"

Disons que si tu prends 2 codeurs moyen avec un temps fixe de développement, tu auras un binaire plus rapide sous Lisaac que sous C. Car c'est plus costaux d'optimiser à mort pour C.

Ce sont les processus exécutants des tâches aux finalités équivalentes sur un même matériel qui sont plus où moins performants. Éventuellement les programmes qu'éxécutent ces processus sont écrit dans un langage différent.

c'est ça un bench. Même algo, même machine, même donné, seul change le langage, donc toute différence de performance peut-être imputé au langage, ou au codeur. C'est l'intérêt du développement ouvert du shoutout tout le monde peut proposer mieux.

"La première sécurité est la liberté"

et passer un temps hyper long...

"La première sécurité est la liberté"

Dire que Lisaac c'est du C, c'est aussi débile que dire que du C, c'est de l'assembleur car c'est ce que génère gcc.

"La première sécurité est la liberté"

"Et puis bon le pb de shootout, c'est que les "tests" ne sont pas forcement représentatif."

C'est pas le problème du shoutout, c'est le problème des microbenchs en général par rapport à un bench applicatif.

Mais si un langage n'est pas devant dans ce genre de cas, il a très peu de chance d'être devant dans des cas plus gros.

"La première sécurité est la liberté"

A bah, non, c'est de l'assembleur puisque le C génère de l'assembleur.

"La première sécurité est la liberté"

L'idée principal est de ne pas pouvoir demander un nouveau mot de passe de façon logiciel.

Il existe des cartes à puces ayant une interface USB, il doit être possible de les utiliser, sauf si elle implémente une norme spécial.

"La première sécurité est la liberté"

J'utilise juste mon cerveau et le bon sens.

A quoi sert de définir une norme sur les dates et les dessins vectoriels si c'est pour inventer de nouvel façon de faire à la première occasion !

Un format n'a pas à tenir compte de l'existant, mais à préparer le futur. C'est juste du bon sens technique.

"La première sécurité est la liberté"

pas le fast-track

Norme 10 fois plus grosse que les autres ?

A lire et assimiler en quelques mois... c'est d'un ridicule.

"La première sécurité est la liberté"

Tu es d'une mauvaise foie affligeante !

On te montre une statistique avec plus de 300 documents, un graphique qui montre que OOXML est un monstre obèse 10 fois plus gros que n'importe qu'elle autre norme en fast track, et tu continues à défendre l'indéfendable !

Faut-il rappeler que ODF n'est pas passé en fast track ?

Que MPEG4 a mis 6 ans et 17 revues pour 4000 pages ?

"La première sécurité est la liberté"

il n'y a pas de regles disant qu'un standard ne doit pas essayer d'etre compatible avec l'existant, "

C'est juste la définition d'un standard, qu'une norme implémente. Juste la définition...

"La première sécurité est la liberté"

Cites-nous un nouveau p-member qui était contre OOXML, histoire de voir ?

"La première sécurité est la liberté"

Et niveau sécurité de l'engin ? Il faut protéger sa source de temps ? Il faut empêcher a tout prix l'accès a la clef prive ?

Par ce que réaliser ce genre de compteur avec un écran, cela représente rien en électronique. (en gros, je sais faire)

Par contre, faire la même chose en protégeant toutes les IOs, c'est une autre paire de manche. (protection de la RTC, utilisation de puce de carte a puce pour planquer la clef, utiliser sans doute un autre uP pour gérer l'affichage, etc...)

J'imagine qu'un truc le moins chére possible mais non sécurisé pourrait amorcer le projet. Déjà si la clef prive dépend du porteur et non du systèmes, il y a moins besoin de sécuriser la calculette contre les attaques hardware (en gros que chaque carte contient une clef différente, cela complique les attaques sur la clef).

"La première sécurité est la liberté"

Si apres ca, pbpg nous ressort que MS n'est pas malfaisant...

"La première sécurité est la liberté"

disons que si le sujet est le token, on ne sait pas quel doivent être ses propriétés. Je vois bien le genre de calculette RSA mais est-ce qu'une clef usb avec un seul bouton ne suffirait pas ?

"La première sécurité est la liberté"

Les démarrages sont fastidieux. Mais après un moment, l'application démarre. Amarok tourne très bien par exemple. Même quelques jeux en 3D tourne bien.

"La première sécurité est la liberté"

Il n'y a pas toujours besoin d'avoir une implémentation super forte. Et c'est toujours utile d'avoir des implémentations de références.

De plus, certain téléphone ont des fonctionnalités proche de celle des cartes a puces.

"La première sécurité est la liberté"

C'était une final avec tout plein d'officiel dans les tribunes, avec l'ambiance anti violence autour des stades (et le ra le bole des "je me fous du foot" de dépenser autant pour la sécurité), il ne fallait pas être devin pour connaitre la réaction des autorités.

"La première sécurité est la liberté"

tu a écris la banderole ou quoi ?

"La première sécurité est la liberté"

Si tu veux lancer une discussion sur linuxfr, il faut l'ouvrir !

Je connais un peu la sécurité et un peu plus l'électronique, mais difficile de commenter quand il n'y a pas de problématique posée.

Qu'elles sont vos difficultés ? Qu'elle forme électronique ont les tokens ? Est-ce des cartes a puce, des clefs usb ou rien a voir ?

"La première sécurité est la liberté"

"En revanche les droits moraux sont inaliénables (donc pas cessible ) , perpétuel et imprescriptible (Art. L. 121-1)."

Sauf que dans les faits ces droits ne servent quasiement à rien. Le plus intéressant est que l'on préserve la paternité, "personne ne peut dire c'est moi qui l'ai fait".

L'autre droit, c'est le droit moral d'utilisation de l'œuvre, ou encore le droit de modification ou de retrait. Dans les faits, on ne peut les exercer car il faut dédommager les propriétaires de toutes pertes.

"La première sécurité est la liberté"

Tentes avec le dernier kernel de Linus.

"La première sécurité est la liberté"

La corruption de donnés peut provenir de la RAM, du disque dure (mais j'aurais tendance à l'exclure vu la quantité de correction possible), le cablage, mais aussi un bug dma ou du contrôleur disque (fake raid?).

Bref, cela peut être plein de choses. Il faut aussi vérifier les messages d'insulte IDE qui pourrait se trouver dans les logs.

Le type de la machine, son age, pourrait aidé. Est-ce que tu viens de faire un upgrade ou pas ? (si elle est ressente, cela peut être un bug d'incompatibilité entre périphérique, essaye dans ce cas de virer l'utilisation des DMA par exemple ). A-t-elle plus de 4Go de RAM? c'est pas courant et cela semble parfois poser problème. En 64 bits ?

"La première sécurité est la liberté"

Je comprends tout à fait les problèmes des dev de kernel. Mais sa réponse ne parlait pas vraiment de ça.

De plus, le genre de code kernel dont tu parles est le coeur de Linux, pas vraiment les drivers par exemple. Or, c'est le plus gros du code.

"La première sécurité est la liberté"

Si tu fais un truc type seti@home, j'imagine qu'il ne faut pas compter à plus d'un échange par seconde entre la racine et chaque noeud. Si tu as le droits à quelques dizaines de seconde par coups, cela doit pouvoir être faisable en distribuant des sous-arbres à fusionner ensuite.

Chaque noeud peut partir dans son "délire" tout seul dans son coin et "resynchroniser" toutes les secondes. Même si tu doubles le boulot à faire, si tu as 1 000 machines, tu t'en fous.

"La première sécurité est la liberté"