Les attaques au laser appelées communément "attaques flash" (parce qu'un bricoleur du dimanche peut en réaliser une avec un flash d'appareil photo) consistent à changer un bit, soit en RAM, soit dans un registre, soit à faire avancer le pointeur d'instruction de plusieurs pas sans que le processeur execute lesdites instructions.
Les conséquences possibles :
- lire à une mauvaise adresse en EEPROM et retourner des données secrètes au lieu de données banales
- sauter le "if (code is incorrect) exit" pour sauter les tests de vérification
- faire faire des calculs erronés au DES et en déduire la clé
- faire du bit flipping sur les clé DES et en déduire des choses
Les contre-mesures sont assez simples : puisque tu ne peux pas faire confiance à ta RAM ou au déroulement de ton programme à un instant t, il suffit d'ajouter de la redondance et de vérifier qu'elle est toujours là :
- les valeurs en EEPROM sont lues, relues et parfois encore relues. Les adresses sources et destination sont stockées à deux endroits différents et comparées en permanence.
- les valeurs écrites en EEPROM sont écrites puis relues puis encore relues. Idem, double copie des adresses.
- les copies de RAM à RAM sont vérifiées avant, pendant la boucle puis après avec encore une double-vérification.
- les chemins d'exécution du code comportent des sémaphores qu'on incrémente à côté de chaque instruction sensible et qu'on vérifie régulièrement
Il y a aussi des petites protections matérielles, comme une grille au dessus de la puce pour détecter si la puce est mise à nue. Mais ça ne fait perdre que quelques heures à l'attaquant, le temps qu'il reroute les courant ailleurs et qu'il gratte la grille.
La sécurité vient donc de la combinaison des protections physiques et logicielles.
Etant donné un équipement illimité et un temps illimité, c'est toujours le craqueur qui va gagner. Quand une carte passe trois semaines dans un labo, ils sont capables de dire exactement quelle instruction est executée à quel moment, synchroniser une attaque laser dessus et voir si le programme pète.
Avec un peu plus de temps, ils peuvent carrément modifier le silicium et rerouter des chemins électroniques, donc concrètement, reprogrammer le hardware de la puce. Tiens, si je mettait un random nul ? Face à ça, il y a bien sur des protections logicielles, mais étant donné qu'ils comprennent tout ce qui est fait au niveau logiciel, ils peuvent prendre le temps de les contourner.
Au final, une carte obtient une note de résistance, qui correspond à la quantité de moyen qu'il faut pour la craquer, et à la disponibilité de ces moyens pour le grand public.
C'est marrant cette idée que la 3D va améliorer l'ergonomie de l'interface utilisateur. Ca sort d'où ?
Vous pensez vraiment que ça va être plus simple parce que c'est en 3D. Les gens ont déjà du mal avec la représentations d'un "bureau" en deux dimensions et la notion de "fenêtre".
Pour ma part, je pense plutôt que la 3D va compliquer encore plus l'interaction. Il y a plein de gens qui ne voient pas du tout en 3D, sont incapables de se projeter en relief dans une surface plane. Il y a aussi la fatigue oculaire engendrée par ce type de visualisation.
Autre truc sympatique, le guichet disparait et les deux automates de distribution des billets qui ne marchent pas, et la gare voisine qui est fermée.
Je me souviens d'un dimanche 30 où j'ai voulu acheter ma carte orange de mois suivant. Environ une quarantaine de personne à faire la queue devant les deux pauvres automates. L'un des automates ne gérait pas les passes navigo. Ces automates plantaient souvent. Il a planté juste devant moi donc la dame SNCF l'a rebooté devant mes yeux. Un bon vieux windows. Il a du mettre environ 7 minutes entre le moment du reboot et le moment où il fut prêt à me distribuer mon billet. Sachant qu'elle le rebootait environ tous les 3 clients, ça fait un super débit !
Et encore, j'habite à Enghien, une gare plutôt bien pourvue vu le fric que possède la municipalité. J'ose pas imaginer comment ça doit être dans des villes un peu moins favorisées.
La politique de la SNCF, c'est donc de virer les guichetiers mais surtout pas de rajouter des bornes automatiques. Ou bien l'idée d'ajouter les veilles de 1er et le 1er lui-même une personne exceptionnelle pour faire face à la charge supplémentaire prévisible, annoncée et connue, ce serait trop leur demander.
Il reste encore 6 jours pour laisser le temps aux packageurs de préparer des paquets et éventuellement pour corriger un bug bloquant de dernière minute.
Concernant les paquets debian, il faut demander à Debian si ça arrivera et où.
Oui, il est tout à fait possible de lancer des applications KDE3 dans un environnement KDE4 et vice-versa. A noter que certaines applications KDE3 matures ne sont pas dispo dans KDE4, c'est donc non seulement possible, mais aussi reconnu comme une nécessité.
Les applications KDE4 seront disponible sous windows plus probablement aux alentours de KDE 4.1 . Le portage sous windows est long et pénible, il faut lui laisser le temps de se faire.
Je doute qu'il soit possible de supprimer le window manager, bureau, panneau de contrôle et lanceur de windows en les remplaçant par KDE4. D'une part, c'est loin d'être simple à faire (même si c'est possible), d'autre part, seules les applications sont portées sous windows. Typiquement, KDM n'est pas porté.
Philips / NXP a senti le vent venir depuis plusieurs années. C'est signe d'une boite mature, ils ont beau avoir un produit référence, ils préparent quand même la suite.
La Mifare DESFire n'a plus de Mifare que le nom commercial. C'est en fait un OS qui supporte du triple DES classique et un protocole de communication standardisé ISO. Elle contient aussi la compatibilité Mifare, donc c'est une carte qui permet de faire la transition vers un peu plus d'interopérabilité et un peu moins de verrouillage client. Sauf que en fait, la DESFire ne supporte presqu'aucune des commandes ISO de carte à puce, uniquement des commandes propriétaires disponibles après avoir signé un gros NDA avec NXP.
On peut donc dire que la DESFire permet de s'affranchir du gouffre de sécurité de la Mifare classique, mais en aucun cas n'ouvre vers plus d'interopérabilité ou sort du verrouillage client.
Et la carte qui est déployée en millards d'exemplaires dans le monde, c'est pas la DESFire, c'est de la mifare classique.
Sur le jeu de commande de la DESFire, une petite anecdote qui donne une idée du pouvoir de lobbying de NXP : le département de la défense américain a sorti il y a deux-trois ans une spécification pour toutes les cartes des employés des administrations américaines, suite à la course sécuritaire post-11 septembre. Les administrations ont obligation à partir d'une certaine date que tous les fonctionnaires ou contractuels bossant pour le gouvernement aient une telle carte. Autant dire, beaucoup de monde, un marché bien juteux pour les fabricants de cartes. Ces naïfs d'informaticiens avaient spécifié une carte supportant uniquement des commandes ISO, donc la DESFire était exclu, ne supportant que des commandes propriétaires. Quelques mois plus tard, le gouvernement américain a révisé sa spécification en diminuant le nombre de commande ISO à supporter à 3. Dans le même temps la spécification de la DESFire a été modifiée pour supporter 3 commandes ISO (les seules !). Intéressant hein ?
Ca donne une idée de l'ouverture de ce genre de marché. Autant dire qu'il faut plus qu'un produit répondant aux spécifications officielles pour rentrer dans ce type business.
> A quand une carte où on peut mettre plusieurs banques dessus et choisir son code?
A priori jamais.
D'un point de vue commercial, ça n'a aucun sens. C'est un peu comme si tu demandais une carte de fidélité qui marche à la fois chez Leclerc et chez Carrefour.
Le problème de fond des langages de haut niveau est qu'ils sont difficiles à appréhender par le commun des mortels. Aussi bien soient-ils, ils demandent de penser différemment. Au final, un langage impératif est quelque chose de vraiment facile à assimiler. Donc bien que ce soit une source d'erreurs, comme c'est _vraiment_ facile à comprendre, c'est ce que les gens apprennent.
Les gens qui se posent un peu la questions d'approches différentes de la programmation, notamment avec des langages utilisant des concepts différents sont en général ceux qui déjà dans leur pratique de la programmation sont très rigoureux.
Quand on propose à un étudiant qui vient de faire trois années pour apprendre péniblement le java de faire du lisp, ça lui sort par les yeux.
Pour reprendre ton exemple du sous-marin, tu peux dire que le sous-marin a trois états et que décider de plonger, c'est faire un changement d'état global qui entraine des mises à jour automatiques en cascade, pour le commun des mortels, c'est plus simple de dire qu'on donne l'ordre au sous-marin de plonger et qu'il faut faire des trucs pour ça. La description impérative est tout simplement beaucoup plus simple à appréhender, même si elle est beaucoup plus sujette à une erreur lors de la mise en oeuvre.
Les problèmes détéctés par Humpich correspondait à des vieilles vielles versions de la norme de paiement, qui était moins sécurisée ( B0' il me semble). La nouvelle norme, c'est EMV et c'est super carré. Sur certains lecteurs de paiement, c'est affiché. Si il te dit CB EMV, c'est tout bon. Si il te dit B0' c'est moins bon. J'ai noté que ma carte bleue est passée en EMV lors de mon renouvellement il y a un an.
Comme les terminaux restent déployés jusqu'à 10 ou 15 ans sans être changés, beaucoup de cartes fonctionnent soit avec la nouvelle norme méga-sécurisée, soit avec l'ancienne beaucoup moins sécurisée. Un choix est fait au moment du paiement. Tant que EMV n'est pas déployé partout, le système comporte donc des failles facile à exploiter. Il suffit de dire au lecteur "je suis une vieille carte, soit gentil avec moi et n'utilise pas de sécurité" et il obéira gentiment.
C'est le problème de la sécurité théorique versus la mise en place pratique. Il est difficile de demander aux commerçants de jeter leur terminal à la poubelle tous les 5 ans, sachant qu'ils payent le terminal et qu'ils payent aussi pour les transactions.
Si je me souviens bien (mais je ne suis pas expert dans le marché du paiement français), le problème mis en avant par Humpich était que pour des automates hors-ligne, le système de vérification était léger et il l'avait cassé. C'est pas un gros exploit, ce qu'on fait les mecs que je cite est quand même déjà plus impressionnant : reverse engineering de circuit, c'est fun bien que ce soit quand même une pratique courante dans l'industrie.
Ce qu'a fait Serge Humpich n'est pas possible de façon généralisée avec des cartes EMV. Pour des cartes EMV, la vérification hors-ligne se fait soit avec un certificat RSA, soit ne se fait pas mais il y a un montant maximum hors-ligne qui peut être dépensé. Si c'est en ligne, la vérification est systématique. J'imagine que Humpich arriverait à se faire de la presse en montrant que dans certains cas, il n'y a pas de vérification hors ligne des transactions. Ca impressionnerait toujours les journalistes, bien que cela soit une information publique.
Ce qui a changé depuis Humpich, outre le passage bien amorçé à l'EMV, c'est que c'est beaucoup beaucoup plus facile de faire des terminaux en ligne maintenant. Par exemple, pas mal de terminaux sont GPRS aujourd'hui ( == utilisent le réseau GSM). Ca laisse beaucoup moins de marge aux frauderus.
Je tiens à ajouter que Humpich n'a pas du tout remis en questions la sécurité de la carte. Une carte à puce correctement implémentée (et la grande majorité le sont) est une coffre fort inviolable. Personne n'est en mesure d'aller lire votre PIN dans votre carte ou de trouver la clé privée des certificats de la carte. Par contre si le code PIN est écrit sur un autocollant au dos de la carte, le fait que la carte soit un coffre fort ne change rien au fait qu'on pourra dépenser tous vos sous.
A chaque fois que tu passes un portique, l'heure et le nom du portique sont stockes sur la carte. Si ils verifient ton passe navigo, ils verront que la derniere entree est trop vieille par rapport à ton voyage actuel.
Cela dit, dans bien des cas, le passe navigo est juste regardé, pas vérifié.
Les autres algos qu'on trouve sur les cartes à puces sont soit du triple-DES (cartes pas trop cher), soit du RSA pour les cartes de compétition. Faut voir que dans l'industrie, on se base sur des standards qui tournent depuis longtemps. Ceux deux-là (DES et RSA) sont pas prêt de disparaître.
Pour les passeports, ils utilisent aussi de l'AES et de l'ECC mais ça reste une utilisation exceptionnelle. Poussée par les allemands et les français d'ailleurs.
Pour ta carte bleue, c'est du RSA par exemple.
Pour élaborer un peu plus sur la crypto, quand un nouvel algo est introduit, il ne suffit pas de l'implémenter pour qu'il apparaisse sur les cartes à puces. Il faut aussi :
- qu'il aille suffisamment vite
- qu'il ne consomme pas trop de courant
- qu'on puisse le sécuriser contre tout un tas d''attaques tordues dites "attaques par des canaux cachées" et attaques au laser
- que les fabricants de silicium l'intègre à leur offre
- que les clients le demande
- que tous les outils actuels de test qui fonctionnent allègrement avec du DES ou du RSA s'adaptent
- que les développeurs se forment
Bref, dans quelques années, si RSA et 3DES montrent vraiment leurs limites, on passera à autre chose.
Pour les réseau de revente à l'unité, c'est pas simple. Le mieux est de contacter une intégrateur comme ABC Smartcard ou ProActive qui peuvent probablement te faire ça. Il y a pas vraiment de place sur le marché pour la carte du bricoleur, donc c'est difficile à obtenir à l'unité. A partir de 10000 en revanche, je peux te donner plein d'adresses, dont ma boite.
Il y a des parties de Qt qui sont optimisées comme du difficilement imaginable. Avec des problématiques complexes.
Ca me parait pas choquant que ce code soit illisible. Souvent mon code optimisé devient illisible parce que certains raccourcis sont effectivement illisibles.
Je peux pas dire que un switch touffu résulte nécessairement de ce type d'optimisation mais ca semble quand même probable, surtout quand tu parles de dessin de widget noù la vitesse doit être la priorité.
Note qu'un gros switch s'optimise en général pas mal par le compilateur, en générant (horreur) des goto.
D'ailleurs, j'ai pas vu de goto dans Qt, preuve qu'ils codent proprement :-) Je suis même prêt à soutenir un troll qu'on code avec un goto peut être plus propre et plus lisible *dans certaines conditions* qu'un code sans goto (ou sans switch touffu puisqu'on y est).
Ca me fait penser à un userfriendly où le dialogue ressemblait à cela :
- nous demandons 5 années d'expérience avec Windows XP
- mais Windows XP n'est sorti que depuis 3 ans !
- dommage. Vous pourrez repostuler dans deux ans si vous voulez...
- bah, d'ici là vous demanderez 7 ans d'expérience avec Windows XP.
Dans les sources de la lib, j'ai jamais vu de gros immondices.
Par contre, niveau design des outils, je pense qu'ils peuvent mieux faire. Je m'explique. Quand Qt Designer est sorti, tout ceux qui ont voulu l'intégrer ont constate que l'architecture interne du bousin ne permettait pas une integration exterieure. Il a fallu attendre quelques années et une reecriture partielle pour que ça soit possible. même histoire avec qmake. Encore même histoire avec Qt/Help.
Je révere trolltech mais je suis quand même surpris que leurs outils ne soient plus pensés pour une intégration extérieure.
Espérons que QtHelp + QtDesigner + qmake leur aura fait comprendre cela.
Après avoir testé 4 ou 5 gestionnaire de bug dans ma boite, on s'est arrêté sur mantis et vraiment, on en est très satisfait.
Une mise en place assez facile, un fonctionnement intuitif, des notifications par mail, une bonne apparence visuelle, la possibilité d'avoir des commentaires privés ou publics, un bonne gestion du flux de développement (bug reporté --> assigné --> résolu --> assigné --> fermé dans notre cas, mais c'est configurable).
On peut facilement gérer plusieurs projets, sans que ceux-ci ne se marchent sur les pieds les uns les autres.
Je n'utilise aucun des plugins externes parce que je voulais juste un bug tracker et j'en suis très content.
Un assert, ca arrete l'application comme une grosse brutasse. Il y a des applications ou c'est le comportement desiré, mais dès qu'il y a un utilisateur en face, c'est pas une bonne idée. Un beau message d'erreur disant le module dans lequel s'est produit l'erreur est quand même bien plus informatif. Il peut y avoir aussi du nettoyage à faire en cas de plantage (cf ce que je dis à la fin de mon message).
Autre inconvenient de l'assert : compare les messages d'erreurs suivants :
v1:
ASSERTION FAILED at file toto.c line 38
v2:
ASSERTION FAILED at file toto. c line 38 : a >= 0
v3:
CardCommunication Error : some_func() : a should be > 0 but is -3
Les grands fans des asserts sont en général des fainéants et dans 80% des cas, on se retrouve avec des message type v1. Tracer le problème est un peu lourd.
Dans quelques cas chanceux, on est en v2.
Dans mes programmes, on est en v3. Sachant que j'ai par ailleurs tout le log de l'execution, je suis capable de diagnostiquer le problème beaucoup plus rapidement. Et c'est bien car en général, quand on cherche un problème, on est pressé.
Je suis sur que les fans des asserts auraient écrit un code 3 fois plus petit. Mais je pense que le mien est beaucoup beaucoup mieux avec des messages d'informations et des messages d'erreur qu'avec des asserts.
Si t'es un vrai utilisateur de vim, tu n'utilises que jhkl pour te déplacer dans ton fichier. Il te reste donc des touches avec des flèches qui ne servent à rien.
Chez moi, elles sont remappées :
- :bp
- :bn
- :cp
- :cn
et hop, se déplacer d'un fichier à un autre est tout de suite plus rapide.
Après avoir essayé divers approches, je suis retourné au mode "je teste les valeurs de retour" de toute mes fonctions.
Pour moi, une gestion d'erreur propre, ca commence par de l'information. Avant de savoir ce qu'on va faire d'une erreur, on commence par donner un maximum d'information sur où elle s'est produite et pourquoi. Pour ça, le mieux est d'avoir un bon module de log, qui permet de partitionner les logs en domaines et en niveaux. Si j'ai trois couches d'API, je pouvoir activer ou désactiver le log de chacune des couches indépendamment, passer la couche basse en mode debug si c'est nécessaire. Ca permet de se lacher un terme de log dans les couches basses, sans pour autant inonder complètement les logs. Dans mes programmes à l'heure actuelle, j'ai un niveau de log "deepdebug". Par défaut, mes programmes sont en "debug". En mode "deepdebug", les couches basses sont très très bavardes et je sais tout ce qu'il se passe. Très très pratique.
Le système de log doit à mon sens :
- permettre à un client qui n'y connait rien de t'envoyer une trace si tu le lui demandes
- être suffisamment détaillé et précis pour que tu puisses débugger ton programme sans lancer un debugger.
Vu la qualité plutôt minable des divers debuggers sous Linux, c'est de toute façon intélligent de miser sur un bon système de log.
Avec les logs, tu sais maintenant que tu pourras traiter correctement ton erreur a posteriori.
Maintenant que faire de l'erreur quand elle se produit ? En regardant les programmes que j'ai écrit, je m'aperçois qu'il est exceptionnel qu'une erreur ne soit pas absolument bloquante. Dans mon cas, une erreur signifie que le programme ne peut plus s'exécuter. Donc le mieux est de remonter l'erreur vers les couches hautes pour en informer l'utilisateur et le laisser corriger le problème.
Les exceptions permettent de s'affranchir du problème localement, en disant : "je traiterai cette erreur dans les couches hautes". Personnellement, je trouve que ce n'est pas une bonne approche parce que ça encourage à ne pas traiter le problème. C'est vite fait d'oublier dans les couches hautes qu'il pouvait y avoir l'exception X dans les couches basses. Ou bien on finit par attraper toutes les exceptions indifféremment mais alors le message de l'exception peut être cryptique.
Exemple : tu reçois un IOError sur un programme avant même de toucher à un seul fichier dans un programme. Quel est le problème ? Impossible pour l'utilisateur de bien comprendre donc de résoudre.
Problème réel: le programme utilise un système de log basé sur des fichiers mais il ne peut créer de nouveau fichier (la partition est pleine) donc il ne peut pas initialiser le système de log. Dans le cas de mes programmes, le message d'erreur sera plutôt "Could not initialise log system : file /tmp/toto.log could not be created."
Je préfère traiter les erreurs localement parce que c'est là où on peut le mieux les décrire. Et je les gère avec des valeurs de retours. Tous mes programmes ou presque me conduisent à gérer mes propres valeurs et message d'erreur, que j'étends au fur à mesure des erreurs que je découvre. Les code d'erreurs doivent avoir un message correspondant. J'ai souvent des fonctions pour mapper les erreurs typiques de la couche en dessous vers des erreurs de ma propre lib d'erreur.
Ca fait du code lourd à écrire mais ça fait du code robuste. J'ai horreur du code qui plante sans que tu saches ce qui s'est passé. Le pire, c'est le code qui plante loin dans le programme à cause d'une erreur qui s'est produite au début du programme. C'est typiquement le genre de code que tu mets des heures à debugger parce que tu cherches au mauvais endroit. S'il y a erreur, le programme doit s'interrompre et dire ce qui ne va pas.
Mon code ressemble souvent à ca :
jresult some_function( int a, int * b )
{
int ret;
if (a < 0) {
jlog_err( "my module", "a should > 0 but is %d", a );
return JERR_INVALID;
}
if (b == NULL) {
jlog_err( "my module", "b can not be NULL");
return JERR_INVALID:
}
ret = some_sub_func( a, *b );
if (ret != JOK) {
jlog_err( "my module", "error when calling some_s_b_func");
return ret;
}
....
return JOK;
}
Cela m'arrive aussi d'avoir des macros en C du type :
#define TRY( some_call ) { ret = some_call ; if (ret != JOK) { jlog_err("my_module", "calling %s returned error %s", #some_call, error_msg( ret ) } }
qui s'utilise avec :
TRY( some_sub_func(a, *b) )
C'est sur que c'est plus pratique avec des langages qui génère des exceptions et affichent toute la pile d'appel.
Voila. On peut penser que c'est lourd et que ca fait perdre du temps d'écrire du code aussi verbeux mais je pense au contraire que ça fait gagner du temps car :
- un programme vite fait finit toujours par durer beaucoup plus longtemps que prévu initialement. Mieux vaut l'écrire proprement du premier coup.
- quand une erreur se produit, je sais tout de suite où et pourquoi. Et développer un programme, c'est bien passer son temps à comprendre pourquoi le ne réagit pas normalement.
Un dernier point sur ce qu'on doit faire quand un programme plante réellement. A mon sens, on doit toujours essayer de sauver les meubles et de réduire l'impact du plantage pour l'utilisateur. Par exemple, j'ai utilisé longtemps le navigateur Opéra à une période où il plantait deux ou trois fois par jour. Ca m'est arrivé plein de fois de le voir planter avec 25 onglets ouverts. Horreur ! Sauf que quand je le relançais, je retrouvais mes 25 onglets. J'ai perdu 15 secondes à le relancer mais je n'ai à peine été dérangé. Il a fallu très très longtemps à firefox pour envisager de faire de même.
Il doit y avoir pour chaque programme une réflexion sur ce qui est fondamental pour l'utilisateur de ne pas perdre et un mécanisme sur comment sauver cette information même dans les cas les plus critiques.
C'est pour ça aussi que je suis plutôt contre les asserts. C'est un truc des fainéant et ça ne permet pas de sauver les meubles correctement.
C'est vrai, c'est scandaleux. Ils devraient plutôt faire des sondages sur linuxfr pour savoir quelle prochaine direction donner à Qt, ce serait bien plus intelligent.
En fait google, ne vit pas du libre, il exploite tout le potentiel du libre.
Google vend un service, le libre est un produit. Le produit permet d'acceder plus facilement au service donc plus il est dispo, mieux c'est. C'est la que utiliser le libre, ca vaut le coup.
Pour les avantages de Perl, par rapport a Ruby ou un autre :
- des centaines de milliers de modules existants qui font des tas de trucs facon grosse bidouille
- vraiment bien oriente je crache un script en une minute pour faire des manipulations texte un peu chiadees. C'est le champion de la moulinette.
Pour les inconvenients :
- du code write-only == illisible deux jours plus tard, meme par celui qui l'a ecrit
En fait c'est dur de developper mais globalement, perl est un langage qui permet de sortir facilement des moulinettes textes, mais qui a l'inconvenient de ne pas du tout encourager des pratiques de programmation moderne tournees vers la qualite logicielle (re-utilisabilite, maintabilite, lisibilte, ...). Des que tu depasses le stade de la moulinette, le langage te fait perdre du temps par son manque de lisibilite.
Conclusion : il y a de plus en plus de contributeurs qui font du python et les projets python bougent plus.
Je pense que perl est en train de perdre la course...
Pour reboucler avec tes stats, ça veut dire que étalé sur 15 ans, il y a plus de projets perl et plus de contributeurs perl que python, mais que si on prend les dernières années, il y a plus de nouveaux sous python que sous perl.
Au fait, perl 6, c'est pour avant notre mort ? (gniark gniark)
Génial ce comparateur ohloh en tout cas. Ca permet enfin de faire des trolls de qualité. Dans les autres trucs sympa à regarder, zsh vs bash. KDE vs Gnome serait génial si il n'y avait pas un gros problème avec le svn de KDE, qui fait que le projet semble commencre en 2006.
Je pousse un peu le raisonnement, mais aujourd'hui, si je regarde autour de moi, savoir utiliser un ordinateur est plus utile que savoir écrire sur du papier.
Loin de moi l'idée que l'ordinateur est la réponse à tout et que les autres techniques ou savoirs sont obsolètes mais il est important de constater que notre monde est aujourd'hui dominé par l'utilisation d'ordinateurs, évolués comme les P(ersonal) C(omputer) ou sous forme embarquée comme tous les machine qu'on tripatouille au quotidien (gare, aéroport, télévision, ...).
Si j'essaye de ne pas réfléchir comme tu as l'air de te complaire à le faire, je dirai que fournir du papier et un crayon à ces enfants est un moyen de s'assurer qu'ils resteront inadaptés à notre monde moderne. On peut aussi leur fournir des bancs de copistes ou les plans de la machine de Gutenberg en leur disant que c'est grâce à ça qu'ils vont diffuser du savoir dans leur pays.
Leur fournir un ordinateur avec du logiciel modifiable, c'est vraiment leur ouvrir une porte d'acquisition du savoir. Leur donner le savoir pour fabriquer une pompe à eau peut être bien plus utile que de leur en fabriquer une.
[^] # Re: DES?
Posté par Philippe F (site web personnel) . En réponse au journal Bye bye les tags mifare. Évalué à 1.
Les conséquences possibles :
- lire à une mauvaise adresse en EEPROM et retourner des données secrètes au lieu de données banales
- sauter le "if (code is incorrect) exit" pour sauter les tests de vérification
- faire faire des calculs erronés au DES et en déduire la clé
- faire du bit flipping sur les clé DES et en déduire des choses
Les contre-mesures sont assez simples : puisque tu ne peux pas faire confiance à ta RAM ou au déroulement de ton programme à un instant t, il suffit d'ajouter de la redondance et de vérifier qu'elle est toujours là :
- les valeurs en EEPROM sont lues, relues et parfois encore relues. Les adresses sources et destination sont stockées à deux endroits différents et comparées en permanence.
- les valeurs écrites en EEPROM sont écrites puis relues puis encore relues. Idem, double copie des adresses.
- les copies de RAM à RAM sont vérifiées avant, pendant la boucle puis après avec encore une double-vérification.
- les chemins d'exécution du code comportent des sémaphores qu'on incrémente à côté de chaque instruction sensible et qu'on vérifie régulièrement
Il y a aussi des petites protections matérielles, comme une grille au dessus de la puce pour détecter si la puce est mise à nue. Mais ça ne fait perdre que quelques heures à l'attaquant, le temps qu'il reroute les courant ailleurs et qu'il gratte la grille.
La sécurité vient donc de la combinaison des protections physiques et logicielles.
Etant donné un équipement illimité et un temps illimité, c'est toujours le craqueur qui va gagner. Quand une carte passe trois semaines dans un labo, ils sont capables de dire exactement quelle instruction est executée à quel moment, synchroniser une attaque laser dessus et voir si le programme pète.
Avec un peu plus de temps, ils peuvent carrément modifier le silicium et rerouter des chemins électroniques, donc concrètement, reprogrammer le hardware de la puce. Tiens, si je mettait un random nul ? Face à ça, il y a bien sur des protections logicielles, mais étant donné qu'ils comprennent tout ce qui est fait au niveau logiciel, ils peuvent prendre le temps de les contourner.
Au final, une carte obtient une note de résistance, qui correspond à la quantité de moyen qu'il faut pour la craquer, et à la disponibilité de ces moyens pour le grand public.
# Amélioration ?
Posté par Philippe F (site web personnel) . En réponse au journal Une véritable interface en 3 dimensions. Évalué à 1.
Vous pensez vraiment que ça va être plus simple parce que c'est en 3D. Les gens ont déjà du mal avec la représentations d'un "bureau" en deux dimensions et la notion de "fenêtre".
Pour ma part, je pense plutôt que la 3D va compliquer encore plus l'interaction. Il y a plein de gens qui ne voient pas du tout en 3D, sont incapables de se projeter en relief dans une surface plane. Il y a aussi la fatigue oculaire engendrée par ce type de visualisation.
Côté innovation en terme d'interface, il faut plutôt regarder de ce côté :
http://rchi.raskincenter.org/index.php?title=Home
Sauf que ce propose de tels changements d'interaction que c'est déroutant, pour tous les humains intoxiqués aux interfaces actuelles notamment.
[^] # Re: Navigo
Posté par Philippe F (site web personnel) . En réponse au journal Bye bye les tags mifare. Évalué à 1.
Je me souviens d'un dimanche 30 où j'ai voulu acheter ma carte orange de mois suivant. Environ une quarantaine de personne à faire la queue devant les deux pauvres automates. L'un des automates ne gérait pas les passes navigo. Ces automates plantaient souvent. Il a planté juste devant moi donc la dame SNCF l'a rebooté devant mes yeux. Un bon vieux windows. Il a du mettre environ 7 minutes entre le moment du reboot et le moment où il fut prêt à me distribuer mon billet. Sachant qu'elle le rebootait environ tous les 3 clients, ça fait un super débit !
Et encore, j'habite à Enghien, une gare plutôt bien pourvue vu le fric que possède la municipalité. J'ose pas imaginer comment ça doit être dans des villes un peu moins favorisées.
La politique de la SNCF, c'est donc de virer les guichetiers mais surtout pas de rajouter des bornes automatiques. Ou bien l'idée d'ajouter les veilles de 1er et le 1er lui-même une personne exceptionnelle pour faire face à la charge supplémentaire prévisible, annoncée et connue, ce serait trop leur demander.
[^] # Re: une dépèche !!!
Posté par Philippe F (site web personnel) . En réponse au journal KDE 4.0.0 is out \o/. Évalué à 1.
Concernant les paquets debian, il faut demander à Debian si ça arrivera et où.
Oui, il est tout à fait possible de lancer des applications KDE3 dans un environnement KDE4 et vice-versa. A noter que certaines applications KDE3 matures ne sont pas dispo dans KDE4, c'est donc non seulement possible, mais aussi reconnu comme une nécessité.
Les applications KDE4 seront disponible sous windows plus probablement aux alentours de KDE 4.1 . Le portage sous windows est long et pénible, il faut lui laisser le temps de se faire.
Je doute qu'il soit possible de supprimer le window manager, bureau, panneau de contrôle et lanceur de windows en les remplaçant par KDE4. D'une part, c'est loin d'être simple à faire (même si c'est possible), d'autre part, seules les applications sont portées sous windows. Typiquement, KDM n'est pas porté.
[^] # Re: je ne comprend pas ??
Posté par Philippe F (site web personnel) . En réponse au journal Bye bye les tags mifare. Évalué à 1.
La Mifare DESFire n'a plus de Mifare que le nom commercial. C'est en fait un OS qui supporte du triple DES classique et un protocole de communication standardisé ISO. Elle contient aussi la compatibilité Mifare, donc c'est une carte qui permet de faire la transition vers un peu plus d'interopérabilité et un peu moins de verrouillage client. Sauf que en fait, la DESFire ne supporte presqu'aucune des commandes ISO de carte à puce, uniquement des commandes propriétaires disponibles après avoir signé un gros NDA avec NXP.
On peut donc dire que la DESFire permet de s'affranchir du gouffre de sécurité de la Mifare classique, mais en aucun cas n'ouvre vers plus d'interopérabilité ou sort du verrouillage client.
Et la carte qui est déployée en millards d'exemplaires dans le monde, c'est pas la DESFire, c'est de la mifare classique.
Sur le jeu de commande de la DESFire, une petite anecdote qui donne une idée du pouvoir de lobbying de NXP : le département de la défense américain a sorti il y a deux-trois ans une spécification pour toutes les cartes des employés des administrations américaines, suite à la course sécuritaire post-11 septembre. Les administrations ont obligation à partir d'une certaine date que tous les fonctionnaires ou contractuels bossant pour le gouvernement aient une telle carte. Autant dire, beaucoup de monde, un marché bien juteux pour les fabricants de cartes. Ces naïfs d'informaticiens avaient spécifié une carte supportant uniquement des commandes ISO, donc la DESFire était exclu, ne supportant que des commandes propriétaires. Quelques mois plus tard, le gouvernement américain a révisé sa spécification en diminuant le nombre de commande ISO à supporter à 3. Dans le même temps la spécification de la DESFire a été modifiée pour supporter 3 commandes ISO (les seules !). Intéressant hein ?
Ca donne une idée de l'ouverture de ce genre de marché. Autant dire qu'il faut plus qu'un produit répondant aux spécifications officielles pour rentrer dans ce type business.
[^] # Re: ...
Posté par Philippe F (site web personnel) . En réponse au journal Bye bye les tags mifare. Évalué à 1.
A priori jamais.
D'un point de vue commercial, ça n'a aucun sens. C'est un peu comme si tu demandais une carte de fidélité qui marche à la fois chez Leclerc et chez Carrefour.
# C'est trop compliqué !
Posté par Philippe F (site web personnel) . En réponse au journal Des langages de haut niveau. Évalué à 1.
Les gens qui se posent un peu la questions d'approches différentes de la programmation, notamment avec des langages utilisant des concepts différents sont en général ceux qui déjà dans leur pratique de la programmation sont très rigoureux.
Quand on propose à un étudiant qui vient de faire trois années pour apprendre péniblement le java de faire du lisp, ça lui sort par les yeux.
Pour reprendre ton exemple du sous-marin, tu peux dire que le sous-marin a trois états et que décider de plonger, c'est faire un changement d'état global qui entraine des mises à jour automatiques en cascade, pour le commun des mortels, c'est plus simple de dire qu'on donne l'ordre au sous-marin de plonger et qu'il faut faire des trucs pour ça. La description impérative est tout simplement beaucoup plus simple à appréhender, même si elle est beaucoup plus sujette à une erreur lors de la mise en oeuvre.
[^] # Re: ...
Posté par Philippe F (site web personnel) . En réponse au journal Bye bye les tags mifare. Évalué à 2.
Comme les terminaux restent déployés jusqu'à 10 ou 15 ans sans être changés, beaucoup de cartes fonctionnent soit avec la nouvelle norme méga-sécurisée, soit avec l'ancienne beaucoup moins sécurisée. Un choix est fait au moment du paiement. Tant que EMV n'est pas déployé partout, le système comporte donc des failles facile à exploiter. Il suffit de dire au lecteur "je suis une vieille carte, soit gentil avec moi et n'utilise pas de sécurité" et il obéira gentiment.
C'est le problème de la sécurité théorique versus la mise en place pratique. Il est difficile de demander aux commerçants de jeter leur terminal à la poubelle tous les 5 ans, sachant qu'ils payent le terminal et qu'ils payent aussi pour les transactions.
Si je me souviens bien (mais je ne suis pas expert dans le marché du paiement français), le problème mis en avant par Humpich était que pour des automates hors-ligne, le système de vérification était léger et il l'avait cassé. C'est pas un gros exploit, ce qu'on fait les mecs que je cite est quand même déjà plus impressionnant : reverse engineering de circuit, c'est fun bien que ce soit quand même une pratique courante dans l'industrie.
Ce qu'a fait Serge Humpich n'est pas possible de façon généralisée avec des cartes EMV. Pour des cartes EMV, la vérification hors-ligne se fait soit avec un certificat RSA, soit ne se fait pas mais il y a un montant maximum hors-ligne qui peut être dépensé. Si c'est en ligne, la vérification est systématique. J'imagine que Humpich arriverait à se faire de la presse en montrant que dans certains cas, il n'y a pas de vérification hors ligne des transactions. Ca impressionnerait toujours les journalistes, bien que cela soit une information publique.
Au fait, les specifications EMV sont publiques et librement téléchargeable : http://www.emvco.com/specifications.asp?show=3
Ce qui a changé depuis Humpich, outre le passage bien amorçé à l'EMV, c'est que c'est beaucoup beaucoup plus facile de faire des terminaux en ligne maintenant. Par exemple, pas mal de terminaux sont GPRS aujourd'hui ( == utilisent le réseau GSM). Ca laisse beaucoup moins de marge aux frauderus.
Je tiens à ajouter que Humpich n'a pas du tout remis en questions la sécurité de la carte. Une carte à puce correctement implémentée (et la grande majorité le sont) est une coffre fort inviolable. Personne n'est en mesure d'aller lire votre PIN dans votre carte ou de trouver la clé privée des certificats de la carte. Par contre si le code PIN est écrit sur un autocollant au dos de la carte, le fait que la carte soit un coffre fort ne change rien au fait qu'on pourra dépenser tous vos sous.
[^] # Re: Navigo
Posté par Philippe F (site web personnel) . En réponse au journal Bye bye les tags mifare. Évalué à 1.
A chaque fois que tu passes un portique, l'heure et le nom du portique sont stockes sur la carte. Si ils verifient ton passe navigo, ils verront que la derniere entree est trop vieille par rapport à ton voyage actuel.
Cela dit, dans bien des cas, le passe navigo est juste regardé, pas vérifié.
[^] # Re: DES?
Posté par Philippe F (site web personnel) . En réponse au journal Bye bye les tags mifare. Évalué à 2.
http://en.wikipedia.org/wiki/DESX
Les autres algos qu'on trouve sur les cartes à puces sont soit du triple-DES (cartes pas trop cher), soit du RSA pour les cartes de compétition. Faut voir que dans l'industrie, on se base sur des standards qui tournent depuis longtemps. Ceux deux-là (DES et RSA) sont pas prêt de disparaître.
Pour les passeports, ils utilisent aussi de l'AES et de l'ECC mais ça reste une utilisation exceptionnelle. Poussée par les allemands et les français d'ailleurs.
Pour ta carte bleue, c'est du RSA par exemple.
Pour élaborer un peu plus sur la crypto, quand un nouvel algo est introduit, il ne suffit pas de l'implémenter pour qu'il apparaisse sur les cartes à puces. Il faut aussi :
- qu'il aille suffisamment vite
- qu'il ne consomme pas trop de courant
- qu'on puisse le sécuriser contre tout un tas d''attaques tordues dites "attaques par des canaux cachées" et attaques au laser
- que les fabricants de silicium l'intègre à leur offre
- que les clients le demande
- que tous les outils actuels de test qui fonctionnent allègrement avec du DES ou du RSA s'adaptent
- que les développeurs se forment
Bref, dans quelques années, si RSA et 3DES montrent vraiment leurs limites, on passera à autre chose.
[^] # Re: Question
Posté par Philippe F (site web personnel) . En réponse au journal Bye bye les tags mifare. Évalué à 1.
[^] # Re: Phonon
Posté par Philippe F (site web personnel) . En réponse au journal Qt 4.4 : Version de démonstration. Évalué à 1.
Ca me parait pas choquant que ce code soit illisible. Souvent mon code optimisé devient illisible parce que certains raccourcis sont effectivement illisibles.
Je peux pas dire que un switch touffu résulte nécessairement de ce type d'optimisation mais ca semble quand même probable, surtout quand tu parles de dessin de widget noù la vitesse doit être la priorité.
Note qu'un gros switch s'optimise en général pas mal par le compilateur, en générant (horreur) des goto.
D'ailleurs, j'ai pas vu de goto dans Qt, preuve qu'ils codent proprement :-) Je suis même prêt à soutenir un troll qu'on code avec un goto peut être plus propre et plus lisible *dans certaines conditions* qu'un code sans goto (ou sans switch touffu puisqu'on y est).
[^] # Re: troll de noel
Posté par Philippe F (site web personnel) . En réponse à la dépêche Ruby 1.9.0 est sorti pour Noël. Évalué à 1.
_ la création de wrapper de bibliothèques C est franchement pas dur. (je sais pas ce qu'il en est en python?)
En Python tu peux utiliser Pyrex, ou bien ctypes, ou bien swig, ou bien tout faire à la main.
ou boost.
[^] # Re: un technicien linux ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Nouveau serveur LinuxFr.org mis en production. Évalué à 1.
- nous demandons 5 années d'expérience avec Windows XP
- mais Windows XP n'est sorti que depuis 3 ans !
- dommage. Vous pourrez repostuler dans deux ans si vous voulez...
- bah, d'ici là vous demanderez 7 ans d'expérience avec Windows XP.
[^] # Re: Phonon
Posté par Philippe F (site web personnel) . En réponse au journal Qt 4.4 : Version de démonstration. Évalué à 1.
Par contre, niveau design des outils, je pense qu'ils peuvent mieux faire. Je m'explique. Quand Qt Designer est sorti, tout ceux qui ont voulu l'intégrer ont constate que l'architecture interne du bousin ne permettait pas une integration exterieure. Il a fallu attendre quelques années et une reecriture partielle pour que ça soit possible. même histoire avec qmake. Encore même histoire avec Qt/Help.
Je révere trolltech mais je suis quand même surpris que leurs outils ne soient plus pensés pour une intégration extérieure.
Espérons que QtHelp + QtDesigner + qmake leur aura fait comprendre cela.
Sinon, Qt, c'est bon mangez-en !
# Mantis : mangez-en !
Posté par Philippe F (site web personnel) . En réponse à la dépêche Éclosion de Mantis 1.1.0. Évalué à 2.
Une mise en place assez facile, un fonctionnement intuitif, des notifications par mail, une bonne apparence visuelle, la possibilité d'avoir des commentaires privés ou publics, un bonne gestion du flux de développement (bug reporté --> assigné --> résolu --> assigné --> fermé dans notre cas, mais c'est configurable).
On peut facilement gérer plusieurs projets, sans que ceux-ci ne se marchent sur les pieds les uns les autres.
Je n'utilise aucun des plugins externes parce que je voulais juste un bug tracker et j'en suis très content.
[^] # Re: Vive les exceptions !
Posté par Philippe F (site web personnel) . En réponse au journal Qu'est-ce que bien gérer les erreurs dans ses programmes ?. Évalué à 1.
Autre inconvenient de l'assert : compare les messages d'erreurs suivants :
v1:
ASSERTION FAILED at file toto.c line 38
v2:
ASSERTION FAILED at file toto. c line 38 : a >= 0
v3:
CardCommunication Error : some_func() : a should be > 0 but is -3
Les grands fans des asserts sont en général des fainéants et dans 80% des cas, on se retrouve avec des message type v1. Tracer le problème est un peu lourd.
Dans quelques cas chanceux, on est en v2.
Dans mes programmes, on est en v3. Sachant que j'ai par ailleurs tout le log de l'execution, je suis capable de diagnostiquer le problème beaucoup plus rapidement. Et c'est bien car en général, quand on cherche un problème, on est pressé.
Tu peux regarder ça pour voir ce que ça donne en pratique :
http://svn.yzis.org/filedetails.php?repname=Yzis&path=%2(...)
Je suis sur que les fans des asserts auraient écrit un code 3 fois plus petit. Mais je pense que le mien est beaucoup beaucoup mieux avec des messages d'informations et des messages d'erreur qu'avec des asserts.
# Les touches du curseur ne servent à rien
Posté par Philippe F (site web personnel) . En réponse au journal Gvim moins bien que Vim ?. Évalué à 1.
Chez moi, elles sont remappées :
- :bp
- :bn
- :cp
- :cn
et hop, se déplacer d'un fichier à un autre est tout de suite plus rapide.
[^] # Re: Vive les exceptions !
Posté par Philippe F (site web personnel) . En réponse au journal Qu'est-ce que bien gérer les erreurs dans ses programmes ?. Évalué à 1.
Pour moi, une gestion d'erreur propre, ca commence par de l'information. Avant de savoir ce qu'on va faire d'une erreur, on commence par donner un maximum d'information sur où elle s'est produite et pourquoi. Pour ça, le mieux est d'avoir un bon module de log, qui permet de partitionner les logs en domaines et en niveaux. Si j'ai trois couches d'API, je pouvoir activer ou désactiver le log de chacune des couches indépendamment, passer la couche basse en mode debug si c'est nécessaire. Ca permet de se lacher un terme de log dans les couches basses, sans pour autant inonder complètement les logs. Dans mes programmes à l'heure actuelle, j'ai un niveau de log "deepdebug". Par défaut, mes programmes sont en "debug". En mode "deepdebug", les couches basses sont très très bavardes et je sais tout ce qu'il se passe. Très très pratique.
Le système de log doit à mon sens :
- permettre à un client qui n'y connait rien de t'envoyer une trace si tu le lui demandes
- être suffisamment détaillé et précis pour que tu puisses débugger ton programme sans lancer un debugger.
Vu la qualité plutôt minable des divers debuggers sous Linux, c'est de toute façon intélligent de miser sur un bon système de log.
Avec les logs, tu sais maintenant que tu pourras traiter correctement ton erreur a posteriori.
Maintenant que faire de l'erreur quand elle se produit ? En regardant les programmes que j'ai écrit, je m'aperçois qu'il est exceptionnel qu'une erreur ne soit pas absolument bloquante. Dans mon cas, une erreur signifie que le programme ne peut plus s'exécuter. Donc le mieux est de remonter l'erreur vers les couches hautes pour en informer l'utilisateur et le laisser corriger le problème.
Les exceptions permettent de s'affranchir du problème localement, en disant : "je traiterai cette erreur dans les couches hautes". Personnellement, je trouve que ce n'est pas une bonne approche parce que ça encourage à ne pas traiter le problème. C'est vite fait d'oublier dans les couches hautes qu'il pouvait y avoir l'exception X dans les couches basses. Ou bien on finit par attraper toutes les exceptions indifféremment mais alors le message de l'exception peut être cryptique.
Exemple : tu reçois un IOError sur un programme avant même de toucher à un seul fichier dans un programme. Quel est le problème ? Impossible pour l'utilisateur de bien comprendre donc de résoudre.
Problème réel: le programme utilise un système de log basé sur des fichiers mais il ne peut créer de nouveau fichier (la partition est pleine) donc il ne peut pas initialiser le système de log. Dans le cas de mes programmes, le message d'erreur sera plutôt "Could not initialise log system : file /tmp/toto.log could not be created."
Je préfère traiter les erreurs localement parce que c'est là où on peut le mieux les décrire. Et je les gère avec des valeurs de retours. Tous mes programmes ou presque me conduisent à gérer mes propres valeurs et message d'erreur, que j'étends au fur à mesure des erreurs que je découvre. Les code d'erreurs doivent avoir un message correspondant. J'ai souvent des fonctions pour mapper les erreurs typiques de la couche en dessous vers des erreurs de ma propre lib d'erreur.
Ca fait du code lourd à écrire mais ça fait du code robuste. J'ai horreur du code qui plante sans que tu saches ce qui s'est passé. Le pire, c'est le code qui plante loin dans le programme à cause d'une erreur qui s'est produite au début du programme. C'est typiquement le genre de code que tu mets des heures à debugger parce que tu cherches au mauvais endroit. S'il y a erreur, le programme doit s'interrompre et dire ce qui ne va pas.
Mon code ressemble souvent à ca :
Cela m'arrive aussi d'avoir des macros en C du type :
qui s'utilise avec :
C'est sur que c'est plus pratique avec des langages qui génère des exceptions et affichent toute la pile d'appel.
Voila. On peut penser que c'est lourd et que ca fait perdre du temps d'écrire du code aussi verbeux mais je pense au contraire que ça fait gagner du temps car :
- un programme vite fait finit toujours par durer beaucoup plus longtemps que prévu initialement. Mieux vaut l'écrire proprement du premier coup.
- quand une erreur se produit, je sais tout de suite où et pourquoi. Et développer un programme, c'est bien passer son temps à comprendre pourquoi le ne réagit pas normalement.
Un dernier point sur ce qu'on doit faire quand un programme plante réellement. A mon sens, on doit toujours essayer de sauver les meubles et de réduire l'impact du plantage pour l'utilisateur. Par exemple, j'ai utilisé longtemps le navigateur Opéra à une période où il plantait deux ou trois fois par jour. Ca m'est arrivé plein de fois de le voir planter avec 25 onglets ouverts. Horreur ! Sauf que quand je le relançais, je retrouvais mes 25 onglets. J'ai perdu 15 secondes à le relancer mais je n'ai à peine été dérangé. Il a fallu très très longtemps à firefox pour envisager de faire de même.
Il doit y avoir pour chaque programme une réflexion sur ce qui est fondamental pour l'utilisateur de ne pas perdre et un mécanisme sur comment sauver cette information même dans les cas les plus critiques.
C'est pour ça aussi que je suis plutôt contre les asserts. C'est un truc des fainéant et ça ne permet pas de sauver les meubles correctement.
[^] # Re: Je ne comprend pas ...
Posté par Philippe F (site web personnel) . En réponse à la dépêche KDE4 déchaîne les passions. Évalué à 8.
[^] # Re: Je ne comprend pas ...
Posté par Philippe F (site web personnel) . En réponse à la dépêche KDE4 déchaîne les passions. Évalué à 2.
Il existe des forks de qualités, qui durent dans le temps et finissent même par remplacer les projets originaux.
[^] # Re: Le libre et le pognon
Posté par Philippe F (site web personnel) . En réponse au journal Google Android. Évalué à 3.
Google vend un service, le libre est un produit. Le produit permet d'acceder plus facilement au service donc plus il est dispo, mieux c'est. C'est la que utiliser le libre, ca vaut le coup.
[^] # Re: Perl vs Ruby
Posté par Philippe F (site web personnel) . En réponse à la dépêche Les Journées Perl, plus que 10 jours pour s'inscrire !. Évalué à 4.
- des centaines de milliers de modules existants qui font des tas de trucs facon grosse bidouille
- vraiment bien oriente je crache un script en une minute pour faire des manipulations texte un peu chiadees. C'est le champion de la moulinette.
Pour les inconvenients :
- du code write-only == illisible deux jours plus tard, meme par celui qui l'a ecrit
En fait c'est dur de developper mais globalement, perl est un langage qui permet de sortir facilement des moulinettes textes, mais qui a l'inconvenient de ne pas du tout encourager des pratiques de programmation moderne tournees vers la qualite logicielle (re-utilisabilite, maintabilite, lisibilte, ...). Des que tu depasses le stade de la moulinette, le langage te fait perdre du temps par son manque de lisibilite.
[^] # Re: gérontophilie
Posté par Philippe F (site web personnel) . En réponse à la dépêche Les Journées Perl, plus que 10 jours pour s'inscrire !. Évalué à 5.
http://www.ohloh.net/languages/compare?commit=Update&l0=(...)
http://www.ohloh.net/languages/compare?commit=Update&l0=(...)
Conclusion : il y a de plus en plus de contributeurs qui font du python et les projets python bougent plus.
Je pense que perl est en train de perdre la course...
Pour reboucler avec tes stats, ça veut dire que étalé sur 15 ans, il y a plus de projets perl et plus de contributeurs perl que python, mais que si on prend les dernières années, il y a plus de nouveaux sous python que sous perl.
Au fait, perl 6, c'est pour avant notre mort ? (gniark gniark)
Génial ce comparateur ohloh en tout cas. Ca permet enfin de faire des trolls de qualité. Dans les autres trucs sympa à regarder, zsh vs bash. KDE vs Gnome serait génial si il n'y avait pas un gros problème avec le svn de KDE, qui fait que le projet semble commencre en 2006.
[^] # Re: Vue d'un pays en voie de développement
Posté par Philippe F (site web personnel) . En réponse à la dépêche Comment faire avancer le projet OLPC ?. Évalué à 2.
Loin de moi l'idée que l'ordinateur est la réponse à tout et que les autres techniques ou savoirs sont obsolètes mais il est important de constater que notre monde est aujourd'hui dominé par l'utilisation d'ordinateurs, évolués comme les P(ersonal) C(omputer) ou sous forme embarquée comme tous les machine qu'on tripatouille au quotidien (gare, aéroport, télévision, ...).
Si j'essaye de ne pas réfléchir comme tu as l'air de te complaire à le faire, je dirai que fournir du papier et un crayon à ces enfants est un moyen de s'assurer qu'ils resteront inadaptés à notre monde moderne. On peut aussi leur fournir des bancs de copistes ou les plans de la machine de Gutenberg en leur disant que c'est grâce à ça qu'ils vont diffuser du savoir dans leur pays.
Leur fournir un ordinateur avec du logiciel modifiable, c'est vraiment leur ouvrir une porte d'acquisition du savoir. Leur donner le savoir pour fabriquer une pompe à eau peut être bien plus utile que de leur en fabriquer une.