Etienne Bagnoud a écrit 1852 commentaires

En même temps le commentaire est "Autotransliteration of native chesslanguage code for C" et dans liste de lien du à "b code" (le b étant un caractère particulier) qui est le "chesslanguage".
À priori IPPOLIT.C est une traduction d'un language particulier prévu pour les échecs.

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

Je télécharge le code source de Robbolito, j'ai un fichier zip comprenant une cinquantaine de fichiers sources, j'en ouvre 1 au hasard, je trouve ça :


/*
RobboLito is a UCI chess playing engine by
Yakov Petrovich Golyadkin, Igor Igorovich Igoronov, Roberto Pescatore
copyright: (C) 2009 Yakov Petrovich Golyadkin
date: 92th and 93rd year from Revolution
owners: PUBLICDOMAIN (workers)
dedication: To Vladimir Ilyich

RobboLito is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published
by the Free Software Foundation, either version 3 of the License,
or (at your option) any later version.

RobboLito is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program. If not, see http://www.gnu.org/licenses/.
*/


Donc pour un programme sans le nom des auteurs et un gros fichier source magique, je trouve que ça le fait pas vraiment.

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

En fait la régate multicoque c'est juste une excuse pour donner du travail aux avocats de la boîte.

D'ailleurs ils ne font pas de régate. Ils montent le matin sur le bateau et redescendent le soir. Le bateau n'a pas bougé lui, c'est trop dangereux, ils risquent de le casser.

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

Ça a un compte gmail et ça parle de vie privée ! Le prochain tu ronchonnes parce que tu as Windows mais pas le code source ?

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

Non un vieux de 2009 je crois. Je peux fouiller chez moi et je te redis si tu veux.

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

Oui je sais, il y a eu un article dans un Linux mag sur le sujet. C'est presque exactement ce que je souhaite, c'est pas encore un CA, mais c'est déjà excellent.
Comme quoi supprimer le gouvernement de temps à autre, ça a du bon.

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

Quand c'est verisign ou autre, ben le fait qu'aucun certificats delivres par ces gars la n'a pu etre spoofe

Verisign avait refilé un certificat de signature de code Microsoft a un type rien à voir. http://support.microsoft.com/kb/293817

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

Oui et non. L'autorité de certification est uniquement la pour garantir que "X" est bien "X". Par exemple, aujourd'hui même, j'ai rencontré mon premier "assureur" pour cacert.org. En gros je lui ai donné un papier avec mon nom, mon prénom, mon adresse email et ma date de naissance, je lui ai montré deux documents (au moins 1 officiel) avec ma photo, mon nom mon prénom et ma date de naissance. On a signé tous les deux ce papier. Il doit conserver ce document et il se porte garant auprès de cacert.org que je suis bien qui j'ai annoncé être.

C'est ça le travail de l'autorité de certification, de garantir que X est bien X. Donc tu as une confiance qui est établie comme ça. Ce n'est pas un réseau de confiance comme GPG, mais bien une hiérarchie de confiance. Il y a ceux au sommet qui font le travail pour garantir l'identité et après il signe le certificat. C'est comme ça que ta banque est reconnu comme ta banque et que personne peut venir s'interposer. Sinon ton navigateur met un message d'avertissement si le certificat n'est pas reconnu (par une autorité).

Ensuite pour mon site perso, l'authentification se fait à travers un certificat à moi que c'est moi qui est généré parce que je me fais confiance, le flux est crypté et c'est ça qui m'intéresse (et j'ajoute mon propre CA dans mon navigateur comme ça je suis avertit si mon certificat a été changé (donc si on m'a piraté)). Au travail on utilise aussi des CA "self-signed" (bien que j'aimerais passer à cacert.org, justement).

C'est donc pas "une vaste fumisterie" car le jour où ta banque produit une erreur, je te déconseille fortement de continuer, le système est perfectible (perso je suis pour qu'on puisse obtenir un CA signé par notre pays d'origine (gratuitement) et uniquement les pays soient au sommet de la hiérarchie. Quand tu reçois ton CA, il contient ton nom, prénom et un id. Ensuite tu peux générer tes certificats, ta banque peut t'authentifier par certificat, ... mon rêve quoi :-)


Sinon pour pycurl, je penses qu'il est intéressant d'utiliser ça. Peu importe s'il fait toutes les vérifications "aujourd'hui", demain il les fera peut-être. Vaut mieux se baser sur une librairie qui va forcément évoluer (ou pas de bol c'est celle qui disparaît :-).

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

Je pensais, tu devrais peut-être utiliser un truc comme stunnel ou la librairie cURL ...

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

N'importe quoi (une entrée trollesque, je l'avoue). La confidentialité c'est pas des trucs farfelues comme éviter les hotspots, avoir un écran à vision réduite et un bordel de mots de passe différents et compliqués.
La confidentialité sur le net c'est de ne pas se faire pomper des données à notre insu. Pour ça Javascript doit être désactivé.

Ensuite on sait que pour l'accessibilité, mal-voyant par exemple, Javascript est un frein à la lecture d'un site Web. Donc au XXIème siècle ne pas faire un site qui soit accessible _sans_ javascript, c'est une insulte vulgaire aux personnes ayant des déficiences physiques. C'est vrai quoi, on a toutes les technologies pour faire ça bien et on est pas capable de le faire.

Alors la première chose à faire, c'est le site _sans_ javascript, ensuite faire de la détection de fonctionnalités javascript pour ajouter du dynamisme si tel est la volonté du créateur du site Web.

http://www.w3.org/TR/WCAG10/

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

Oui les programmes de streaming stocke uniquement en mémoire les données téléchargées, tu n'as rien sur le disque dur, en effet. Mais comme tu as des outils pour enregistrer les web-radio et les web-TV.

En visio tu télécharges, parce que télécharger c'est transférer des données d'une machine distante à une machine locale. En visio tu enregistres même sur le disque parce que tu veux garder une trace de la conférence. Et en visio tu n'es pas en direct mais en différé parce que le protocole prévois un petit tampon pour pallier les ralentissements réseaux.

C'est clair si chacun redéfini les mots, on va pas s'en sortir. Si je décide que pour moi le téléchargement c'est l'effacement de toutes les données sur le disque dur local, je te promets qu'on peut avoir des sacrés discussions sans aucun sens.

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

Ok non.

le CA va recevoir des requêtes pour signature (CSR). Un fois ces requêtes signées, cela fait des certificats utilisables pour les fonctions prévues (les contraintes). La différence entre un CA et un certificat c'est le champs CA:FALSE ou CA:TRUE. Un CA c'est un certificat X.509 comme un certificat X.509 serveur, comme un certificat X.509 client, ...
La CRL c'est une liste qui contient les certificats révoqués par le l'autorité de certification, donc le CA. Celle-ci est signée par le CA et va contenir, grosso-modo, ça :

Certificat_avec_ID_1: revoqué: date: ...
Certificat_avec_ID_2: revoqué: date: ...
Certificat_avec_ID_3: revoqué: date: ...

Donc toi tu prends cette CRL, tu contrôle la signature (et la chaîne entière, en vérifiant tout (y compris CRL)).
Et un la revoquation d'un CA c'est un peu différent, si je ne me trompe pas :
Tu signes le nouveau CA avec le CA que tu va révoquer, tu créés une CRL signée avec le nouveau CA contenant l'ancien CA. Mais ça je suis pas sûr.

Donc c'est relativement lourd comme procédure, en effet, mais ne pas la mettre en place, c'est utilisé du SSL pour dire qu'on fait du SSL, mais c'est du SSL sans sécurité.
Tu peux regarder si un outil existe et fait ce travail ou une librairie (qui existe certainement).

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

je ne pense pas ...
mais je comprends bien qu'il faudrait le faire pour être exhaustif.

Si tu ne vérifies pas la CRL, ça sert à rien de faire la moindre vérification (à part consommer du temps processeur).

Sinon c'est pour le reste, si j'ai bien compris :
- Tu prends le certificat du site disons example.com
- Quand tu trouves un réseau wifi tu te connectes et tu récupères le certificat du serveur
- Tu compares les deux certificats.

Si c'est ça, autant rien faire. Le principe de X.509 c'est une autorité qui signe des certificats. Tu dois vérifier si le certificat est signé par une autorité (et en fait toute la chaîne jusqu'au certificat racine (parce qu'un autorité peut avoir signé une autorité qui elle signe une autre autorité qui elle signe un certificat) et si le nom donné par le certificat correspond au nom du serveur.
Ensuite tu vérifies la CRL de l'autorité (parce que si le type est un méchant qui a obtenu un certificat qui a ensuite été révoqué, c'est bien de le savoir).
Il faut aussi vérifier les contraintes du certificat.

Si le but est de vérifier un truc (bidon) pour dire qu'on a vérifié un truc, c'est inutile, autant ne rien vérifier.

Regardes la page 15 à 20 pour te rendre compte de toutes les astuces qu'il existe pour attaquer SSL : http://www.blackhat.com/presentations/bh-dc-09/Marlinspike/B(...)

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

Ok un hacker il va rien faire, parce que les hackers sont gentils. C'est un mauvais usage du mot.

Sinon si un méchant arrive à flouter VeriSign, ... ou même cacert.org, tu peux rien faire. Il y a donc X.509 qui définit tous ces trucs avec CA, certificats et tous ça ... Donc soit tu t'en tiens et tu fais confiance aux autorités, soit tu fais ton propre truc. Mais bon je sais pas si tu es le plus qualifié pour décider qui est autorité de certification et qui ne l'est pas. Laisses ça à Debian/Ubuntu/Mozilla/... et contentes-toi de faire une bonne vérification.

Ensuite tu dois aussi vérifier les CRL, ta fonction elle le fait ?

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

Tu as les certificats racines officielles (VeriSign et co) et d'autres comme ca-cert.org. C'est un paquet Debian (je supposes qu'il est présent sur Ubuntu) et c'est le projet Debian qui décide d'inclure ou non un CA.

Ensuite je supposes que ton application est prévue pour fonctionner de manière générique. Donc faire confiance aux certificats que ta distribution à choisi d'avoir confiance c'est le meilleur moyen (en laissant la possibilité de changer ça pour l'utilisateur).

Finalement tu as aussi tous les certificats séparé dans ce même répertoire. Donc à toi de décider. Mais perso j'aimes bien qu'une application utilise ce que mon système au lieu de réinventer un Xème système. Surtout que l'utilisateur peut librement ajouter ou supprimer des certificats avec dpkg-reconfigure ca-certificates.

Mais si ça marche avec ta fonction, j'en sais rien. Mais je supposes qu'elle le fait.

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

Le paquet ca-certificates, et tu lis le fichier /etc/ssl/certs/ca-certificates.crt qui contient tous les certificats racines (y compris ceux de cacert.org).

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

Il marche ce truc ? J'ai cru qu'il s'agissait d'un outil pour les cours sur la "détection de pannes" les étudiants.

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

Des sources ?
Non parce que wikipedia[1] et diverses autres sources (liens 2 et 3 postés précédemment + [2][3][4] ...) ne sont pas d'accord avec ta description du streaming (lecture en continu).
Surtout je vois mal intervenir l'histoire de la "vitesse réelle" dans les communications réseaux ... j'ai de la peine à me le représenter : si on a une vidéo d'une voiture allant à 60km/h ça voudrait dire que les paquets de données doivent parcourir 60km par heure sur le net ? Plus tu es proche du lieu plus tu as l'information tôt, c'est ça ?
Donc durant un match de foot le ralenti c'est du téléchargement et le reste du streaming ?

[1] http://fr.wikipedia.org/wiki/Lecture_en_continu
[2] http://www.afnic.fr/doc/lexique/d#diffusioncontinue
[3] http://www.techterms.com/definition/streaming
[4] http://www.answers.com/topic/streaming-media

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

C'est du téléchargement quand même. Après du téléchargement à vitesse réel à travers du HTTP ou du RSTP ou du RTP c'est la même chose, sauf que certains protocoles sont spécialisés pour du téléchargement temps réel et d'autres pas.
Et le streaming n'implique pas du forcément du direct, mais peut être aussi légèrement différé (ce qui est généralement le cas car il y a une mémoire tampon généralement pour pallier les ralentissements du réseau).

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

Ton streaming web
Ce n'est pas des termes que j'ai créés, mais bien les termes qui sont utilisés sur différentes sources (liens 2 et 3 notamment). Mais appelons ça comme vous voulez.
Le fait est que Théora n'a pas besoin d'être découpé en morceau avec un fichier d'index, alors que la solution pour H264 (enfin le conteneur MPEG TS) c'est de découper en morceau avec un fichier d'index. Là aussi c'est pas moi qui le dit, c'est Apple.

Finalement le streaming c'est du téléchargement (et peu importe le protocole) avec un logiciel capable de démarrer la lecture avant la fin du chargement. Donc la visio c'est du téléchargement tout bête, les radio Internet c'est du téléchargement tout bête, ... Par contre il faut un conteneur qui supporte ça (si les informations sur le codec utilisé, le type de conteneur, ... sont à la fin du fichier, c'est clair qu'il va falloir attendre ça pour commencer la lecture). En fait, tous les transferts de données à travers un réseau depuis un ordinateur distant vers un ordinateur local sont du téléchargement ... C'est pas moi qui le dit, c'est Wiktionnaire, http://fr.wiktionary.org/wiki/télécharger .

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

donc le H264 est déjà la et le flash, c'est aussi du H264 !
C'est pour ça que Google annonce son support H264 sur Youtube. Dans la situation actuel de Google :
- Une librairie de vidéo en H264
- Un navigateur H264 et Theora[1]
- Un rachat de On2 en cours
- Un navigateur OpenSource
En restant pragmatique, Google a son navigateur qui lit tout. Apple lit H264 et quitte Flash (non support sur iPhone, iPad).
Reconvertir toute la librairie vers Theora prend du temps.
Le rachat de On2 ouvre des portes pour un autre codec plus intéressant (à priori).

Donc :
1) On fait du H264 (c'est ce qu'on a déjà)
2) Quand le rachat de On2 est ok, on a un codec de qualité équivalente consommant moins de bande passante
3) On sort ce codec, on le met libre et ouvert.
4) Tout le monde implémente ce codec (Mozilla, Opéra, Safari et Microsoft).
5) On a notre librairie convertie (parce qu'on avait prévue ça)
6) On diffuse Youtube avec ce codec. Les autres sont largués parce qu'ils font faillites à cause du prix H264 (et le coût de conversion n'est pas mieux).
7) On garde notre place de plus gros diffuseur de vidéo Web.

Bref, les non-visionnaires suivent Google dans H264 et vont être largués.

Ensuite, dire que le H264 n'est pas fait pour le stream, je trouve cela un peu fort. Le H264 a été fait pour le visio, par la visio et donc pour le temps réel (d'ou son appellation commençant par H). La visio, cela fait partis du stream...

C'est une partie. Je parlais du streaming _Web_. Tu dois pouvoir te déplacer dans la vidéo, dans la vision tu as juste un flux continu, tu peux "sauter" en avant. Donc le streaming temps réel bien entendu, mais le streaming Web (possibilité de "naviguer" dans la vidéo) c'est natif chez Théora[2] et bricoler chez H264[3].

[1] http://standblog.org/blog/post/2010/01/26/Video-Theora-ou-H2(...)
[2] (en fin de l'article) http://www.0xdeadbeef.com/weblog/2010/01/html5-video-and-h-2(...)
[3] http://developer.apple.com/iphone/library/documentation/Netw(...)

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

Concernant l'H264, je crains que le combat soit perdu d'avance face aux alternatives libres, le format est déjà trop implémenté sur et en dehors du monde informatique.

Le sujet c'est H264 sur le _Web_. Sur le Web actuellement c'est Flash pour la vidéo, maintenant la "guerre" pour le remplacer a commencé.

Il y avait un commentaire sur un blog (si tu suis un peu les liens, je me souviens plus trop duquel) qui disait genre "dans l'hôtellerie on est obligé d'utiliser H264 parce que techniquement il supporte ceci, cela que Theora n'a pas". Mais le sujet n'est pas de remplacer H264 dans le _monde_ mais d'imposer un format libre et ouvert là où il n'y encore rien (parce qu'il n'y a rien, il y a une balise video, mais rien derrière).

De plus H264 n'est _pas_ fait pour le streaming, ce que Theora fait nativement. Si tu suis un peu les liens tu vas tomber sur la méthode d'Apple pour faire du streaming à grand coup de fichier d'index avec H264. Theora le fait et sans "workaround".

Actuellement on a une partie du Web qui part vers H264, une partie du Web vers Theora et Google qui rachète On2, une entreprise ayant développé un codec qui serait mieux que H264.
Il est fort probable que Google utilise une technologie lui appartenant pour diffuser les vidéos plutôt que de s'enfermer dans un truc payant. Ensuite le support de Theora est disponible sur plusieurs navigateur (Opera, Firefox et un autre je crois). IE n'a aucun support video et les autres c'est H264.

La bataille ne fait que commencer. D'un côté on a Theora -> Firefox et Opéra dans les navigateurs, Wikipedia et Dailymotion dans les diffuseurs. C'est des arguments de poids.
De l'autre on a H264 -> Chrome et Safari côté navigateurs, Youtube et Vimeo côté diffuseur.
Avec bonus : Chrome et Youtube appartiennent à Google, Google rachète On2, donc un troisième codec pourrait faire son apparition.
Finalement on a le retardataire habituel : IE avec rien (mais qui aura certainement le support des codecs installés sur Windows, donc H264 et Theora).

On a des gros de chaque côté, on a Google qui pourrait apporter un autre codec (et qui pourrait le faire libre et ouvert s'il reste dans l'ideal "don't be evil"). Le match va être passionnant, mais rien n'est joué.

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

Le point positif de ce genre d'incidents et qu'ils sont parfois solvables avec des outils libres, c'est l'occasion de promouvoir cette informatique de confiance dans mon entreprise : on peut corriger en interne les bugs et trouver une solution fiable et rapide.

C'est grâce à ça que le directeur est très ouvert aux outils Libres. Malheureusement on peut pas en avoir partout, mais quand on peut, on a toujours le feu vert. Dernièrement (ce matin), on a eu le feu vert pour passer la centrale téléphonique sur Asterisk. Bien que dans un premier temps ça sera moins stable qu'un truc tout prêt (le temps d'apprentissage de la technologie puisque personne n'en a fait avant), mais à court terme on aura un truc de qualité, fiable et ouvert.
Dans ce cas là, l'élément déclencheur, c'est la facture à 3 zéros parce qu'on a éteint la centrale téléphonique à XXh00 (toutes les heures précises la centrale se synchronise avec la mémoire morte et une interruption de ce processus entraîne de graves problèmes de corruption (ce qui nous a été expliqué)). On doit éteindre la centrale de temps à autre pour contourner un bug du fabricant (c'est la solution du fabricant, éteindre la centrale et la rallumer), mais le fabricant a omis de nous dire "pas le faire à des heures précises".
Donc deux jours sans téléphone et une facture à 3 zéros, tout ça pour une centrale qu'il faut éteindre de temps à autre pour contourner les bugs du fabricant et qui coûterait une fortune à mettre au niveau technologique d'aujourd'hui (offre à 4 zéros).

Donc oui, c'est vrai que ce genre de problèmes permettent de faire la promotion d'une informatique ouverte. Et ça on peut vraiment appeler de "l'informatique de confiance".

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

Non c'est juste pour rappeler que des solutions "Il y a bientôt le nouveau standard X" ne sont pas des solutions. Avoir un standard c'est bien, mais ça veut pas dire qu'il va être déployé partout et correctement.

J'entends de plus en plus souvent "il y a html5" ... Actuellement il y a un "Working Draft", on peut donc se préparer à ça mais miser sur des standards qui n'existent pas encore, j'ai un peu arrêter.

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

Mais bientôt se sera basé sur les fonctionnalités offline du HTML5 [...]

IPv6 ça fait 15 ans que ça existe.

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell