Les cartes mifare sont des tags RFID bas-coût utilisé un peu partout. En gros, c'est comme un passe
Navigo simplifié (les parisiens comprendront). Ca fait des cartes qui fonctionnent à environ 5 cm
de distance d'un lecteur RF. Les cartes Mifare peuvent stocker de 256 à 1024 octets de façon dite
sécurisée.

Pour les boites comme la mienne qui bossent dans la carte à puce, les mifare sont une chienlit. Tout
le monde les utilise, elles ne coûtent pas cher, elles font de la crypto propriétaire ce qui fait
qu'il faut aussi un lecteur ou chipset Philips pour les lire. Et tout le monde était content parce
que "ca marche". On peine à justifier pourquoi on propose un truc plus cher avec du DES.

Et bien maintenant, ça ne marche plus: la crypto mifare a été cassée par Karsten Nohl et Henryk Plötz, et pas qu'un peu:
http://www.ziki.com/en/groups/craft/archives/5925269-24c3-mi(...)


Pour ceux qui n'ont pas le temps de regarder la vidéo mais veulent quand même se payer une bonne
tranche de rigolade, voici les points à retenir:

- la crypto est basée sur un random 16 bits, c'est à dire qu'il y a 65 000 valeurs possibles du
random. Il cycle environ toutes les secondes.

- le random (et c'est là le plus drôle) ne dépend que de la durée d'allumage de la carte. Même durée
d'allumage, même random.

- la pseudo-authentification des cartes basée sur une numéro unique de carte est tellement faible
que n'importe que utilisateur peut prétendre en être un autre avec une simple attaque "man in the
middle" et quelques XOR.

Le plus instructif, c'est pas à quel point la sécurité par l'obscurité ne marche pas, c'est à quel point
l'obscurité est là pour cacher l'absence de sécurité.

Jusqu'ici, on a déjà complètement cassé la sécurité d'un système mifare, mais on a pas encore
attaqué les cartes. On a juste mis à jour les gouffres de sécurité lié à la conception.

Ensuite, nos deux amis ont réellement cassé l'algo en analysant le silicium. Ce fut facile au final, c'est celui_là:
http://en.wikipedia.org/wiki/Linear_feedback_shift_register#(...)

Pour casser une clé mifare avec une attaque par la force brute, il faudrait:
- une semaine sur un FPGA à 100$
- une journée sur un FPGA à 700$

je vous laisse imaginer la suite.

Les cartes mifare sont utilisées vraiment partout, notamment pour du contrôle d'accès, des
porte-monnaies, des cartes de transport, ... Par exemple, la carte Oyster du métro londonien est une
mifare.

Un grand merci a Karsten et Henryk, grâce à lui, ma boite va pouvoir mieux faire son boulot. En
effet, il y a de par le monde des boites qui implémentent correctement la sécurité. Sauf qu'on a du
mal à vendre nos solutions correctement sécurisées parce que ca coûte trop cher et que ca apporte
aucun avantage par rapport à une mifare. Maintenant, ca sera
un peu plus facile.

Quand je dis que les boites comme la mienne vendent des trucs correctement sécurisé, c'est à dire que on utilise des algos de
clés publiques, connus et reconnus, qu'on applique les recommendations de sécurité, que nos cartes
passent en laboratoire et que les labos s'amusent à essayer de les peter dans tous les sens sans
succès.

Les conséquences de ce craquage, c'est pas la fin de la carte à puce, c'est au contraire le début de
la reconnaissance que faire un microcontrolleur et faire une carte à puce sécurisée sont deux choses
bien différentes.

A noter par exemple que le passe Navigo est basé sur de la vraie sécurité, c'est à dire des algos
publiques et en l'occurence un DESX. La plupart des cartes déployées au niveau institutionnel
(Vitale, Carte Bleue, ...) utilisent de la vraie sécurité. Par contre, pour l'ouverture à distance
de votre voiture ou pour pénétrer dans la zone hyper-sécurisée de votre société, c'est une autre
histoire

> Lire le journal (81 commentaires, moyenne: 1,8).

Apparemment, Linus vient de s'inscrire sur http://www.ohloh.org . Il est pas encore le plus reconnu mais tout ça n'est qu'une affaire de quelques heures à mon avis.

Ce qui est intéressant, c'est qu'il a rempli un peu la pile de logiciels qu'il utilise :
http://www.ohloh.net/accounts/9897/stacks/default

On voit sans surprise make, gcc, git, linux (non, sans blague ?) et ... KDE !

Maintenant, j'aimerai bien savoir quel éditeur il utilise. Je le vois bien utiliser vim, mais uniquement en attendant de réécrire un éditeur à la hauteur de ses besoins.

> Lire le journal (36 commentaires, moyenne: 2,9).

Coverity est une société faisant des outils d'analyse de code pour détection de vulnérabilité. Ils ont mis en place en avril 2006 une page qui montre le nombre de vulnérabilités sur différents projets Open Source en analysant le code contenu dans leur repository CVS/SVN. La page est mise a jour régulièrement.

KDE vient de repasser à 0 vulnérabilité et je voulais voir où en était Gnome depuis la dernière fois. Or, grande fut ma surprise de constater que Gnome n'est plus listé dans cette page. A la sortie de Gnome 2.16, c'est un peu dommage puisqu'on ne sait pas avec combien de vulnérabilités la release de Gnome a été faite.

Avec l'objectivité qui me caractérise et qui caractérise aussi linuxfr, je me permets d'avancer quelques hypothèses quant aux raisons de ce retrait :

- il y avait trop de vulnérabilités et Gnome a voulu rester discret sur le sujet et à demandé à coverity de cacher les resultats de Gnome durant la période de la sortie.

- Gnome ne compilait pas donc coverity n'a rien scanné. Etonnait au moment de la sortie d'une version majeure.

- Comme coverity, sapusepalibre, Gnome a demandé à ne plus être scanné.

- le rachat de Ximian par Novell a fait que la boite allemande XXX s'est rapprochée de Gnome et comme le PDG de XXX couche avec la femme du PDG de YYY, lequel est lui-même un super pote au PDG de coverity, il a demandé à coverity d'arrêter de scanner Gnome.

- comme Gnome dépend maintenant de C# et de Microsoft et que en plus, gnome a trop simplifié son interface que c'est devenu un bureau pour neuneu et que même que sur mon ordinateur, KDE est bien plus rapide que Gnome, coverity a décidé d'arrêter de scanner Gnome.

- on est entré dans un univers parallèle dans lequel Gnome n'a jamais été scanné par coverity.

Si des gens bien éclairé ont des idées pour ce mystère, qu'ils se manifestent.


Trollement votre.


http://lists.imendio.com/pipermail/planner-dev/2006-April/00(...)

> Lire le journal (12 commentaires, moyenne: 3,1).

La trollosphere se déchaîne sur phonon depuis que Christian Schaller, un des auteurs de gstreamer l'a critiqué : http://blogs.gnome.org/view/uraeus/2006/05/11/0

On a droit comme d'habitude a un gros lot de commentaires de chocs niveau slashdot qui sont toujours aussi intelligents et bien argumentés :
- KDE est en train de se tirer une balle dans le pied
- phonon est une surcouche d'une surcouche déjà complexe donc ça va tout ralentir
- gstreamer assure, c'est débile de ne pas l'utiliser

et j'en passe. On est tout juste au niveau de "KDE devrait fusionner avec Gnome" et "on devrait réécrire Qt en utilisant la glib".

Heureusement, on a eu droit a quelques réponses bien argumentées des développeurs KDE :
- http://aseigo.blogspot.com/ : Aaron Seigo (développeur KDE important)
-http://grammarian.homelinux.net/~mpyne/weblog/kde/phonon-whi(...) Michael Pyne (Auteur de JUK)
- http://www.kdedevelopers.org/node/2007 Scott Wheeler (auteur de Amarok)

A noter que ces deux derniers ont fait des bindings gstreamer pour KDE et travaillent tous les deux sur des applications musicales. Ils font donc partie des rares personnes qui savent de quoi elles parlent quand le sujet est évoqué. Je trouve leurs arguments techniques tout à fait convaincants sur les raisons d'existence de phonon. J'ai du mal à imaginer qu'on puisse les lire et continuer à affirmer que "KDE devrait utiliser gstreamer comme Gnome" sans être de mauvais foi.

Pour les flemmards, les arguments qui m'ont le plus marqué :

- que faire sur les plate-formes où gstreamer ne tourne pas ?
On pourrait imaginer que les applications détectent si gstreamer est présent et l'utilisent et sinon utilisent l'autre moteur multimedia disponible. C'est exactement ce que va faire phonon

- KDE 3 a duré à peu près 3 ans sans changement binaires incompatibles. Pour KDE 4, on espère faire beaucoup mieux. En 3 ans, non seulement la compatibilité binaire de gstreamer a été cassée 3 fois, mais en plus, l'API a évolué de façon importante de sorte qu'il est difficile de maintenir facilement une application l'utilisant. Si KDE choisissait une version de gstreamer, il serait obligé de faire un fork pour garder une vieille version compatible pendant que le reste de gstreamer continuerait à évoluer et que KDE ne pourrait pas en tirer partie.

- l'API de gstreamer est complexe est mal adaptée aux besoins raisonnablement simple des auteurs d'application de KDE. Me vient à l'esprit le fameux "Bonhomme Patate".

Mais j'en viens au coeur de mon journal. En lisant tout ça, j'ai eu une forte impression de déjà vu. Certes, beaucoup de "batailles au lance-flamme" se ressemblent mais vraiment, ça dépassait la simple familiarité.

Alors l'éclair m'est venu. Remplacez gstreamer par Corba, phonon par DCOP et KDE 4 par KDE 2 et on se retrouve quelques années en arrière. Tout y est :

- les commentaires façon slashdot de ceux qui n'ont pas la moindre idée de ce dont ils parlent.

- les "KDE va mourir s'il fait ce choix-là"

- le mépris de l'expérience des développeurs de KDE qui ont utilisé gstreamer de façon approfondie mais "qui n'ont rien compris à tout ce que gstreamer peut apporter".

- les "vous n'arriverez jamais à maintenir [ une API multimedia / un framework de communication inter-processus ] à vous tout seul, c'est beaucoup trop compliqué.

- les "ça ne sert à rien de faire [ de la communication inter-procesus / une API multimedia ] si vous n'avez pas toutes les fonctionnalités de [ Corba / du moteur multimedia sous-jacent ] :

Au final, je prédis exactement le même sort à phonon qu'à DCOP. Regardons la situation présente de DCOP vs Corba :
- la complexité de Corba a rendu le développement de bonobo long et difficile.
- très peu d'applications Gnomes utilisent au final bonobo
- Gnome a pratiquement renoncé à cette technologie
- la légèreté de DCOP a fait qu'il a été facilement maintenu et qu'il est devenu très populaire
- toutes les applications KDE supportent DCOP et beaucoup en tirent avantage : il suffit de lancer kdcop sous KDE pour le voir et de jouer avec dcop pour faire des trucs sympa
- DCOP a tellement bien marché qu'il a donné naissance à DBUS, le même principe mais avec moins de dépendances et fonctionnant dans un contexte plus large que un environnement de bureau.


Donc ma prédiction :
- phonon sera léger et maintenu
- il sera vite populaire et toutes les applications KDE l'utiliseront avec plaisir
- le problème qu'il résout continuera de se poser et au final, freedesktop adoptera ou développera une technologie extrèmement similaire en bénéficiant de l'expérience de phonon.

Rendez-vous en 2009 pour le résultat des courses. A noter que je suis prêt à prendre des paris.

> Lire le journal (66 commentaires, moyenne: 3,4).

Bonjour cher journal,

Depuis un peu plus d'un mois, à la suite de la lecture d'un article sur kuroshin ( http://www.kuro5hin.org/story/2005/12/10/155850/89 ) je me suis inscrit sur topcoder :

http://www.topcoder.com/tc

Le principe est simple : une à deux fois par semaine, des épreuves sont proposées. Chaque épreuve est composée de 3 exercices, un facile, un moyen et un difficile, que l'on doit résoudre en moins d'une heure. Apres on dispose d'un quart d'heure pour observer le code de ses camarades et essayer de trouver un exemple pour planter leur code.

Il y a un classement global qui évolue au gré des épreuves.

J'étais plutôt attiré par l'aspect compétition et par l'idée de programmer un peu, puisque mon boulot n'implique plus de développement, juste de la gestion de projet.

Le dev est en C++, C# ou java. Pas trop de place pour le logiciel libre .

Au bout d'un mois, ce que j'en retire :

Une heure, c'est super court. Ca veut dire qu'il faut apprendre à coder vite et juste.

Pour l'instant, je n'ai pas réussi à terminer plus de deux programmes et systématiquement, l'un de ces deux programmes s'est fait allumé sur un test. Ca peut aller d'un test à la con à une vraie erreur de programmation. Ou bien à une sous-estimation de la complexité de mon implémentation : chaque programme doit résoudre le problème posé en moins de deux secondes.

Je note un énorme progrès dans ma capacité à écrire du code concis et juste. Sur la dernière compétition, sur les trois programmes que j'ai écrit, les trois ont compilé du premier coup et ont résolu le problème du premier coup. Je n'en revenais pas ! Seuls deux étaient corrects cependant, j'avais une variable globale contenant une liste qui grossissait systématiquement et qui a épuisé toute la mémoire sur le plus gros test.

En terme de langage, le C++ semble être assez populaire. J'aurai bien aimé participer en python mais python ne pourrait jamais à mon avis faire tourner les problèmes en moins de deux secondes.

Cette compétition est vraiment impitoyable. Dans un programme concret, on est finalement rarement exposé directement à tous les bugs qu'on laisse passer. Beaucoup ne sont jamais activés. La, rien ne passe. Entre tes concurrents qui cherchent la petite bête pour gagner des points, les concepteurs de problèmes qui pensent à tous les cas tordus, je me suis vraiment pris une grosse claque. Je savais que je n'étais pas un cador, mais se ramasser sur des problèmes plutôt facile, ca fait mal. Sur mon premier programme, il fallait compter le nombre d'éléments vérifiant un pourcentage et j'ai eu le malheur de faire une division avec des floats : blam, le problème était conçu pour que les imprécisions sur les floats soient mis à jour. Il fallait en fait faire une multiplication et rester dans l'espace entier (je m'en doutais de toute façon).

Ou bien j'avais fait un petit programme où le calcul de complexité me paraissait bon, sauf que j'avais une initialisation qui rajoutait une boucle for non prévue dans mon calcul initial : je me suis fait dégager.

Donc là, je suis vraiment content parce que je pense que j'ai franchi une étape. Mes programmes semblent être corrects et conformes à ce que je veux en faire.

Côté connaissance, j'ai appris à utiliser la STL et j'ai découvert quelques algos ou quelques concepts comme la programmation dynamique. Beaucoup de problèmes se résolvent par récursion vu que les récursions font des programmes concis et efficaces.

J'ai appris à bien lire les problèmes et à faire au plus simple et plus direct. Beaucoup de problèmes demandent de retourner le nombre d'éléments vérifiant une certaine propriété. La tentation initiale est de trouver tous les éléments et d'en retourner le nombre, mais c'est souvent infaisable. On découvre que juste compter le nombre d'éléments sans les calculer est en revanche faisable dans les temps et de façon concise.

Quand le temps est compté, on réfléchit à tous les racourcis. Tout le monde a une macro FOR(i,0,n) qui génère for(i=0; i<=n; i++) et toutes les variables utilisées sont sur un ou deux caractères. On découvre des nouveaux trucs au fur à mesure : le problème balance une suite de chaines de caractère contenant des chiffres. Au début, je convertissais naivement en double tableau d'entier. Maintenant, je travaille directement dans la chaîne avec str_lst[i][j] - '0' pour accéder aux différents éléments. S'il y avait une structure avec trois entiers, j'etais tenté de créer une structure pour les contenir. Maintenant, soit je fais des pair< int, pair< int, int > >, soit je les mets tous les trois dans un tableau simple en indexant par multiple de trois. Bref, tous les trucs sont bons pour que le code à ecrire soit plus concis et plus simple. On hésite pas non plus à dimensionner des tableaux aux tailles max supportées par le problème, genre int tab[20000][50][50] parce que c'est plus rapide à écrire qu'une allocation dynamique.

Sur les aspects programmation, dans la division 2 (la division des newbie comme moi), je pense avoir fait le tour des problèmes. C'est toujours soit de la récursion, soit des graphes, soit de la programmation dynamique, soit un chouia de math. La difficulté est de reconnaitre un algorithme connu derrière le problème et de l'implémenter dans les temps.

Côté division 1, il y a vraiment des killers. Le problème difficile demande souvent une véritable analyse mathématique, plus des astuces subtiles de programmation et d'algorithmie. En général, je ne trouve pas la solution. Et je suis épaté par des mecs qui trouvent et codent une solution en moins de 10 minutes.


Voila, si vous voulez vous amuser un peu dans l'arène des programmeurs, je vous invite à faire un tour.

Ah, j'oubliais. Il va surement y avoir un troll pour savoir si topcoder aide à mieux programmer. Il est clair qu'un certain nombre de trucs du codeurs sont des mauvais trucs à utiliser dans la programmation courante (nommage succints des variables, variables globales à tout va, ...) mais dans l'ensemble, je pense que ca aide à devenir un meilleur programmeur. Et en tout cas, c'est super fun !

> Lire le journal (15 commentaires, moyenne: 2,9).

Cher journal,

Dans ma PME, je souhaiterai mettre en place un systeme de partage de contact et de calendrier. Vous savez, le truc qu'on a en claquant des doigts avec Exchange + Outlook.

Ca doit marcher pour les commerciaux et pour moi, donc ca doit marcher sous windows. Les usages c'est :
- mon commercial regarde mon emploi du temps pour me caser un rendez-vous
- chacun rentre les contacts qu'il a pour les partager avec tout le monde
- rappel de rendez-vous ou de taches importantes qu'on a place sur le calendrier

Rien de mortel, mais en cherchant, je n'ai pas trouve de solution simple qui marche pour tout le monde. J'ai installe horde mais il faut 5 minutes pour prendre un rendez-vous (lancer le browser, se connecter, etc) donc ca ne fonctionne pas trop. Il faut un truc plutot simple.

J'ai jete un coup d'oeil au plugin sunbird sous thunderbird : on en est loin. Pas moyen de le mettre en arriere-plan pour qu'il me balance mes alertes. J"ai plusieurs bureaux sous windows, et il ne popup pas dans le bureau actif.

P'tet qu'il me faut juste un LDAP. Comme je n'y connais rien, j'ecouterai vos conseils.

> Lire le journal (18 commentaires, moyenne: 2,4).

Bon, je cherche un routeur de bonne qualite. Je travaille dans une PME ou je gere un reseau local de 6 personnes sur mon temps libre.

Il y a en gros 6 machines et un serveur. Le serveur doit etre joignable en ssh et http depuis l'exterieur. Les machines doivent pouvoir eventuellement etre joignable depuis l'exterieur pour faire du vnc (le top pour aider un client sur un probleme sans se deplacer).

Pour l'instant, j'avais achete un routeur netgear wifi a 70 euro. Mais je me suis rendu compte de pas mal de problemes :
- quand on passe par le routeur, les donnees arrivent en burst. Genre il envoie des bursts toutes les secondes et c'est super lent !
- meme quand on passe par le routeur depuis le reseau local vers le reseau local (connexion vers le port redirige vers le serveur), on recupere les donnees en burst => il n'a pas route directement sur le reseau local.

Le seul truc de bien avec ce routeur, c'est qu'il est facile a configurer. J'ai songe a utiliser le serveur en tant que routeur mais j'aime bien l'idee d'avoir un firewall physique devant mon serveur.

Un autre inconvenient, c'est que si on doit monter des redirections de ports firewall -> machine interne, c'est super simple a faire avec le routeur via l'interface web a 3 sous alors qu'avec un serveur/routeur, il faut passer root et savoir quelle commande taper (je ne la connais pas d'ailleurs, j'ai jamais rien compris aux histoires de routage).

Quels sont vos conseils ? Ou est-ce qu'on peut trouver un routeur de moyenne qualite ? J'ai upgrade le firmware du routeur : que dalle. Je pense que c'est un routeur grand public vraiment oriente partage de connexion et pas du tout routeur dans les deux sens.

> Lire le journal (20 commentaires, moyenne: 2,4).

Bonjour,

Alors voila, ma boite cherche des stagiaires en python et PyQt. Ca s'appelle InSeal (http://www.inseal.com) et c'est une start up qui a deux an et demi d'age (on a passe le cap le plus difficile des deux ans). C'est pour bosser sous windows et faire du logiciel close source, mais avec des technos libres. C'est toujours mieux que de faire du C#.NET . Bon, on cherche des developpeurs programmeurs codeurs, si possible avec un peu d'experience dans le logiciel (= contribution a un logiciel libre quelconque).

> Lire le journal (37 commentaires, moyenne: 3,7).

Voila la lettre que je viens d'envoyer a nos deputes.

Tous les lecteurs de Linuxfr devrait en envoyer une similaire.

Je tiens a la disposition de qui le demande la liste d'adresse email de deputes pour envoyer la lettre. Toutes les adresses ne marchent pas mais meme avec 20% d'echec, ca reste une bonne action.

Bougez-vous, c'est pas en lisant linuxfr qu'on lutte contre les brevets, il faut agir aupres de nos deputes. Envoyer la lettre avec la liste des addresses prend 2 minutes a tout casser, plus 10 minutes pour rediger une belle lettre.

12 minutes de votre temps pour lutter activement contre les brevets, ca les vaut bien.

-----------------------------------------------------------------


Bonjour,

je me permet d'attirer votre attention, personnellement et en tant que
fondateur et président de ma société InSeal, sur la bataille qui se joue
actuellement à Bruxelles pour l'indépendance de l'Europe dans le domaine des technologies de l'informations.

Parmi 70 témoignages d'autres chefs d'entreprises (dont par exemple
celui du PDG d'ILOG, numéro 3 français du logiciel):

http://www.economic-majority.com/testimony/index.fr.php(...)

auxquels s'ajoutent le soutien de 1586 sociétés à ce jour:

http://www.economic-majority.com/index.fr.php(...)

des 424998 signataires de la pétition contre les brevets logiciels en
Europe:

http://petition.eurolinux.org/(...)

des 2081 sites web à ce jour fermés en guise de manifestation en ligne contre
le projet de directive:

http://wiki.noepatents.eu.org/webdemo/list.php(...)

et enfin d'organisations représentatives des PME européennes comme l'UEAPME
(confédération qui représente 11 millions (!!!) de PME en Europe):


http://www.ueapme.org/docs/press_releases/pr_2005/050621_Computer_P(...)
http://www.ueapme.org/docs/press_releases/pr_2005/050427_CIIcampaig(...)

ne semblent malheureusement pas convaincre les parlementaires européens
du fait que les brevets logiciels ne sont pas souhaités par les
principaux acteurs de l'économie du logiciel en Europe.

Les brevets logiciels sont soutenus par un lobbying organisé et
particulièrement bien financé de représentants des acteurs américains (BSA) ou
des géants de l'industrie électronique européenne (EICTA), et d'un petit
nombre de PME qui leurs servent d'alibi.

Aucune étude économique sérieuse, depuis que cette triste affaire a commencé à
la fin des années 90, n'a pu démontrer que le brevet logiciel allait favoriser
l'innovation. Bien au contraire, toutes les études, y compris celle commandées
par la Commission et mises au placard immédiatement après, démontrent que les
brevets logiciels ne peuvent avoir pour conséquence que:

- un renforcement des monopoles et des positions dominantes d'acteurs
majoritairement étrangers à l'Europe (notamment américains)

- une diminution de l'innovation

- une augmentation des coûts de production des logiciels de 30% à 50%

- un risque juridique énorme pour le PME

- une remise en cause du "principe d'interopérabilité", avec là encore comme
conséquence le renforcement des monopoles et la diminution de la
techno-diversité dans le secteur du logiciel.

En effet, les seuls acteurs à s'enrichir dans un système qui autorise les brevets logiciels sont:

- les acteurs dominants du marché qui pourront tuer les petits acteurs
innovants dès qu'ils deviendront menaçant par le biais du "terrorisme
juridique", tout en s'entendant entre eux par des accords de licences
croisées, et sans avoir à innover eux-même.

- les fonds de brevets qui ne produisent pas de logiciels (c'est beaucoup trop
risqué dans un monde qui autorise les brevets logiciels) mais se contentent
d'attaquer les vrais créateurs de logiciels lorsque les opportunités se
présentent.


En effet, on a tort de penser que les PME pourront se protéger efficacement à
l'aide de brevets. Entretenir un brevet coûte cher, le protéger devant un
tribunal coûte bien plus. Se défendre contre une grosse société qui fait un
procès pour cause de brevet, même dans le cas où la grosse société n'a pas
gain de cause est hors de prix pour une PME. Si une PME est menacée sur un
brevet, elle va tout simplement renoncer à utiliser le produit cité, même si
elle est dans ses droits.

Le brevet a été inventé pour protéger l'innovation, mais aujourd'hui, les
brevets logiciels ne servent qu'à faire du terrorisme juridique. Les grosses
sociétés qui se sentent manacées par les innovations des PME vont tout de
suite déballer l'artillerie du brevet logiciel pour tuer ces concurrents
dangereux.

Un autre aspect important est que l'industrie logicielle, de la même façon que
les mathématiques, s'appuie énormement sur le savoir-faire commun. Que serait
un monde où le théoreme de Pythagore serait breveté, et où il serait interdit
de l'utiliser sans payer une licence a M. Pythagore ? Des pans entiers de
développement en mathématiques ne seraient plus possibles. Ou bien, si le
mélange d'oeufs et de farine était breveté en tant que recette de cuisine ?
Tout recette de cuisine utilisant des oeufs et de la farine serait soit
interdite, soit soumise à des "royalties" à verser au détenteur de ce brevet.

Lorsqu'on l'applique à des domaines non matériel comme la musique, les
recettes de cuisine et les mathématiques, le principe du brevet ne fonctionne
plus et devient un danger pour le partage de la connaissance. Le danger est le
même pour l'industrie logicielle, mais n'apparaît pas aussi clairement que
pour les exemples que j'ai cité.

Les Microsoft et les IBM seront ravis de voir les brevets logiciels arriver.
Ils vont pouvoir taxer toute l'industrie européenne, avec leur porte-feuille
de brevets immense, et leurs équipes dédiées au dépot de brevet. L'industrie
logicielle europeenne (fortement composée de PME) ne pourra pas lutter.

Par ailleurs, il existe un mouvement mondial de partage de logiciels, connu
sous le nom de logiciel libre, dont les plus connus sont probablement Linux,
Apache ou Firefox (navigateur web). Les logiciels libres sont reconnus
aujourd'hui comme patrimoine de l'humanité par l'Unesco, et sont surtout un
mode de production de logiciel ouvert de tres bonne qualité. Le gouvernement
français soutient via diverses initiatives comme l'ADAE (
http://www.adae.gouv.fr/adele/(...) ) le développement du logiciel libre. Pourtant,
les brevets logiciels vont tout simplement tuer ce mode de développement et de
partage.

Je suis convaincu que les dispositifs actuels de protection du
logiciel, basés sur le droit d'auteur, sont parfaitement adaptés pour protéger
les créateurs de logiciels originaux en leur permettant de distribuer ceux-ci
selon les termes qui leurs conviennent.

Je garde l'espoir, ténu il est vrai, que l'opinion des vrais créateurs de
logiciels européens sera entendue par les parlementaires européens, et qu'ils
voteront en deuxième lecture des amendements similaires à ceux déja votés en
première lecture, amendements qui posent une limite claire entre ce qui est
brevetable (solutions technique, i.e. impliquant l'usage contrôlé des forces de
la Nature, à un problème technique), et ce qui ne l'est pas (notamment tout ce
qui relève du traîtement des données). M. Rocard a notamment tres bien expose
la problematique et les solutions a y apporter.

C'est pourquoi, à titre personnel, en tant que PDG de InSeal , et en me faisant
l'écho des 400000 citoyens européens opposés aux brevets logiciels, je demande
expressément aux Députés Européens de réaffirmer la position de septembre 2003
du Parlement garantissant la liberté de publication et de distribution de
logiciels originaux, l'interoperabilité, et définissant une invention technique
comme une solution impliquant les forces contrôlables de la nature, en votant
les amendements permettant de répondre aux 10 questions suivantes:


http://www.ffii.fr/Travail-parlementaire-europeen-sur-les-brevets-l(...)

ou, si le Parlement n'arrive pas à imposer ce qui précède, de rejeter
entièrement la directive.

Cordialement,

Philippe Fremy,
PDG/CEO, InSeal SAS

> Lire le journal (9 commentaires, moyenne: 2,3).

Dans le cadre d'yzis (http://www.yzis.org),(...) je suis en train d'ecrire du code lua et d'embarquer une partie dans yzis. Je suis vraiment impressionne par la qualite de ce langage. Ca me rappelle un peu la philosophie unix par certains aspects.

Lua a un coeur extremement simple : des tables, des nombres, des strings, des booleens, des flottants et des fonctions. C'est du classique. La ou ca assure, c'est qu'a partir de ca, on peut faire des objets. Les tables servent a la fois aux listes et aux dictionnaires. Avec une adaptation syntaxique, elles peuvent servir d'objet. Avec un mecanisme de metatable, on peut meme faire des trucs vraiment sympa comme de l'heritage, ou bien remplacer des operateurs.

Le concepteur a donc reussi a faire un langage avec seulement quelques concepts, mais qui est tres puissant. Comme le langage est simple, il est relativement leger et s'embarque facilement. Ecrire du code C/C++ accessible en lua est vraiment facile.

Bref, je ne regrette pas ce choix pour yzis et je le recommande chaudement a quiconque veut rendre une application scriptable.

> Lire le journal (9 commentaires, moyenne: 2,8).

Ca fait deux ans que j'ai cree ma societe, InSeal, pour developper un OS pour carte a puce sans-contact. Apres deux ans de galeres et de batailles pour obtenir des partenariats, on en est finalement a un point ou on a besoin et surtout ou on a les moyens de recruter une ou deux personnes en plus.

C'est vraiment une etape importante pour nous et je peux vous dire que ca m'a coute pas mal d'heures de stress pour en arriver la. Mais finalement, on y est. Le futur n'est pas encore assure mais il se profile de plus en plus rose chaque jour. Peut-etre meme que un jour, je pourrai me payer un smic, pour vous dire si ca se passerai bien (pour l'instant, c'est les assedics qui me payent).

Alors, pour ce qui est des postes, les linuxiens seront decus: on est sous windows. Et oui, les outils proprietaires dont on a besoin pour faire de developpement sur l'OS ne fonctionnent que sous windows. Le deuxieme aspect qui peut paraitre negatif, c'est qu'on ne fait pas d'open source. On essaye de manger et pour ca, on fait des outils proprietaires. J'invite tout ceux qui pensent qu'on a tort et qu'on devrait faire nos developements en open source a fonder eux meme leur societe et a nous concurrencer avec leurs outils open source et a essayer de manger le soir en meme temps. Je serai ravi qu'on me prouve que j'ai tort mais pour l'instant, c'est moi qui choisis ou je mets mon argent (100 000 euro pour l'instant).

Si vous etes ok avec ces deux principes, vous pouvez venir. Meme si on ne developpe pas sous linux, on est des passionnes de logiciel libre (vous pouvez voir ma page web par exemple, http://phil.freehackers.org(...)) et on utilise majoritairement des technos libres: python, Qt, cygwin, cppunit, ....

Pour ceux qui se posent la question, nous avons effectivement une licence commerciale PyQt pour faire du close source en Qt.

Au niveau des postes, on cherche en gros un developpeur avec profil C embarque, et un developpeur avec profil "je fais des outils graphiques".

L'ambiance est relaxe (pas de contrainte vestimentaire et on accepte meme les barbus). Vous bosserez dans une toute petite societe (1 employe, 2 stagiaires et 2 fondateurs) et vous pourrez participer au developpement de l'activite, voir ce que c'est que le developpement logiciel commercial en petite structure. Autant vous dire que ca n'a rien a voir avec un boulot a Alcatel ou a Cap Gemini. Vous avez 99% de chances d'etre implique sur la totalite de la phase de vie du logiciel, finalement, un peu comme en logiciel libre.

Ah oui, je suis fan de tests unitaire et de qualite logicielle. Donc si vous venez, vous apprendrez (ou bien vous appliquerez si vous savez deja) a faire du logiciel fiable dans la duree.

Bon, je vous mets le descriptif des annonces que j'ai redigees. Contactez-moi sur phil at inseal dot com si ca branche l'un d'entre vous.


==================================================================

Poste: developpeur logiciel embarque

Vous mangez du C pour votre petit dejeuner ? Vous verifiez souvent
l'assembleur de vos programmes pour etre sur qu'ils sont "bien compiles" ?
Vous voulez vous plonger dans la carte a puce ? Alors, vous avez surement une
place chez InSeal.

Nous recherchons des developppeurs pour travailler sur notre OS pour carte a
puce sans-contact. Vos taches quotidiennes comprendront:
- developpement sur notre OS en C et assembleur
- ecriture de tests unitaires et tests fonctionnels
- amelioration de la securite de l'OS

Connaissances:
- C, assembleur, protocoles carte a puce
- le plus: python, crypto

===========================================================================

Poste: developpeur logiciel pour un SDK

Vous avez amenage votre appartement de facon orientee objet ? Vous aimez les outils qui font gagner du temps aux utilisateurs ? Alors, vous avez surement une place chez InSeal.

Nous recherchons des developpeurs pour developper un SDK pour notre OS cartes
a puce sans-contact. Les outils seront developpes en python + Qt, avec
quelques morceaux en C++.

Taches a effectuer:
- developpement d'un SDK pour notre OS sans-contact
- developpement d'outils de tests et de demonstration
- integration de lecteurs sans-contact

Connaissances:
- C, C++, programmation orientee objet, programmation graphique
- le plus: python, Qt, protocoles


==================================================================

PS: Pour ce qui est du non open source, je mets un bemol: on a commence le dev de notre OS en open source (http://www.jayacard.org(...)) et on reprendra ca d'ici un an ou deux, quand le reste de l'activite sera stabilisee. Il est aussi possible de mettre un ou deux outils qui ne sont pas dans notre core business en open source. Mais bon, si vous vous appelez RMS, c'est pas la peine de venir chez nous.

> Lire le journal (74 commentaires, moyenne: 3,1).

Un lecteur de linuxfr a dit "je ne fais pas de tests unitaires parce que je suis faineant". Cette remarque m'a profondement interpelle.

Donc laissez-moi vous raconter une parabole: l'autre jour, je rangeais les courses dans le frigidaire en discutant avec un pote, informaticien et faineant (pleonasme ?), comme moi. Il me voit enlever l'emballage en carton du paquet de 16 yaourts avant de les mettre au frigo.
- tu enleves l'emballage ?
- oui
- mais c'est beaucoup de travail. Je croyais que tu etais un faineant comme moi ?
- oui, mais vois-tu, j'ai decouvert que c'est beaucoup plus de travail de prendre un yaourt si on n'a pas enleve l'emballage avant. Et il y a 16 yaourts a prendre. Il est plus economique d'enlever l'emballage des le debut.

Le faineant amateur va simplement mettre les yaourts au frigo, mais le vrai faineant va enlever l'emballage car il sait que celui-ci le fatiguera plus tard.

Apres cette parabole hautement philosophique, j'en reviens a mon sujet: si je fais des tests unitaires, c'est justement parce que je suis faineant. C'est beaucoup moins fatiguant d'ecrire un test unitaire puis de le valider avec du code, que d'ecrire du code en songeant a toutes les facons dont il sera utilise et en essayant de garantir que ca marchera a tous les coups. En plus, quand on n'a pas de suite de test unitaire, on est souvent oblige de lancer l'application et de faire quelques manip a la main. C'est super fatiguant.

Quand j'aurai un bug, je pourrai me permettre d'etre faineant: je le rajouterai a ma suite de test unitaire, je pourrai facilement faire la modif du code pour le corriger puisque j'aurai deja ma suite de test unitaire pour valider les autres fonctionnalites.

Voila, tout ca pour dire que le vrai faineant, c'est celui qui fait des tests unitaires.

Les tests unitaires, c'est bon, mangez-en !

> Lire le journal (28 commentaires, moyenne: 2,7).

Bon, c'est la 2e fois que j'abuse du systeme des journaux de linuxfr, avec une certaine honte. Je cherche un mec qui a deja fait du JavaCard, pour une mission codage de environ un mois. Si ca vous tente, contactez-moi.

Bon, sinon, pour justifier ce journal, on va essayer de se racrocher au libre. Alors, voyons javacard, machine virtuelle java pas libre, c'est un peu ecule comme troll. Je dois pouvoir trouver mieux.

Alors, disons : est-ce que le logiciel qui fait tourner votre carte bleue devrait etre libre ? Et celui de la carte a puce qu'il y aura bientot dans votre passeport ? Et celui qui est dans votre carte vitale ?

La position de RMS est si je me souviens bien : "dans la mesure ou on peut modifier le soft, il doit etre libre".

De toute facon, independamment de la position de RMS, c'est pas possible. Dans ma boite on fait des OS pour carte a puce (sans-contact comme pour le passe navigo). Au debut, on voulait naivement faire un OS open source, en apportant des arguments de securite, relecture du code, bla bla. Ben en fait, ce n'est pas possible. Pour faire une carte bancaire, GSM, de sante ou un passport, il faut passer une evaluation securitaire EAL4+ (critere commun). Cette evaluation demande de fournir une pile de doc monstrueuse concernant les specifications, la gestion des risques, la gestion de bugs, pour mener une analyse de votre processus de developpement. Il y a aussi un audit de code dans le tas.

La ou ca coince, c'est que si votre code est disponible sur le net, vous perdez des points en terme de securite puisque c'est plus facile pour un vilain cracker de monter une attaque sur votre carte. C'est meme probablement redhibitoire. En revanche, vous gagnerez probablement quelques points en terme de validation, puisque votre carte est probablement plus fiable.

Comme notre business depend de cette evaluation, on n'a pas le choix: ce sera du close source de chez close source de ta mere.

Du coup, notre projet jayacard (http://jayacard.sf.net(...)) est a l'abandon. Mais ne desesperez pas, d'ici un an ou deux, on le remettra en route avec une offre de carte sans-contact + kit de dev pour OS open source pour particulier.

Bon, finalement, je m'en tire pas si mal pour raccomoder le sujet. Ah, pour javacard, c'est une implementation de java pour carte a puce. C'est un truc completement debile, il s'agit de faire tourner une jvm sur un microcontrolleur 8 bit avec entre 500 et 5000 octets de RAM. Sachant que les jvm consomment beaucoup en RAM (java est un langage qui s'appuie enormement sur la pile), vous avez une idee des perfs globales et de l'utilisabilite du truc. Le plus drole avec JavaCard, c'est que a cause des contraintes de RAM, il faut ecrire un code Java tres tres reflechi, ce qui est au final une operation bien plus complexe que d'ecrire le meme code en C.

> Lire le journal (2 commentaires, moyenne: 6,5).

Comment garantir que un jeu de test teste vraiment un programme ? Il y a la couverture de code, mais est-ce que ca donne vraiment des garanties suffisante ? Un programme avec une couverture de code de 100% peut-il ne pas etre teste a 100% ?

le cas simple:

1. if  (a == 0)

2.           do_a();

3. else 

4.            do_b();

Dans ce cas, si je couvre les lignes 1, 2 et 4, j'ai couvert tout mon programme.

Un autre cas:

1. while( a < 15 )

2.       do_something( a );

La, ca ne marche plus: si j'execute avec a = 14, j'aurai couvert tout mon programme (ligne 1 et 2) mais je pourrai toujours faire des bugs. On peut imaginer par exemple que la valeur a = -3 fasse literalement planter le bazar.:

int do_something( int  a)  {

     return 15 / (a + 3);.

}

Donc en plus d'avoir une couverture de code, il faut encadrer les intervalles de valeur possibles de toutes les variables du programme. Et evidemment, il faut tester toutes les combinaisons possible. On peut imaginer:

int do_something( int  a, int b)  {

     return 15 / (a + b);.

}

Il faut ici soit garantir que a sera toujours different de -b, soit tester conjointement toutes les valeurs de a et b.

Si on combine tout ca, on arrive a des tests exponentiels.

Conclusion 1 : meme avec la meilleure volonte du monde, il est difficile de tester completement un programme.

Cependant, les gars qui ont pense XP ne sont pas cons : ils mettent en avant le white box testing (transparent box serait plus approprie). Le developpeur titille son programme la ou il sait que celui-ci risque d'avoir mal. Couple avec une bonne couverture de test, on a qqch de tres fiable.

Finalement, le test et l'analyse des resultats reste un melange d'exhaustivite et d'appreciation personelle du developpeur.

Dommage, j'aimerai bien pouvoir apporter plus de preuves sur la fiabilite du code que j'ecris.

> Lire le journal (38 commentaires, moyenne: 2,3).

pour l'instant.

C'est un sujet qui me tarabustait depuis pas mal de temps. Pourquoi python ne serait-il pas capable de faire de l'inference de type et de relever des erreurs evidentes qui sont relevees dans d'autres langages a la compilation ? Je me disais que pychecker pourrait faire qqch de similaire.

Pour mettre dans le contexte:
def f1( a ): return a + 1

def f2():
b = f1( 3 ) # ca va marcher
c = f1( [] ) # ca va pas marcher

# autre exemple
def f3(a):
if a is None: b = "toto"
else: b = 1
b = b + 1 # ne marche que si a != None, sinon, ca plante

J'ai pose la question sur ocaml et sur comp.python. Bon, la reponse est arrivee. En fait, en ocaml, il y a un typage fort des variables, qui fait qu'elles ne changent pas de type. A partir de ca, on peut faire des maths et trouver les variables qui sont mal typees.

En python, le typage est dynamique donc une variable peut prendre plusieurs types au cours de sa vie. A cause de cela, on peut pas faire tourner des algos de deduction de type, il y a trop de variantes possibles.

En fait, si le typage en python etait statique (impossible de changer le type d'une variable, mais possibliite de changer sa valeur), ca pourrait marcher.

Des nouveaux projets comme pypy permettront probablement de faire des interpreteurs python avec des proprietes particulieres, comme d'imposer un typage statique, optimiser du code a la volee (facon psyco mais en plus intelligent), etc.

Donc, si je veux avancer, il faut contribuer a http://codespeak.net/pypy/(...)

> Lire le journal (11 commentaires, moyenne: 2,3).

Bonjour journal,

Apres lecture d'un journal faisant reference a l' ``Uberman sleep schedule'' (
http://www.kuro5hin.org/story/2002/4/15/103358/720(...)), j'ai decide de tenter
qqch de similaire. Pour ceux qui ont la flemme de lire, l'uberman sleep
schedule propose de dormir 3 heures par jour seulement, sous forme de siestes
d'une demi-heure toutes les 4 heures. Apres qqs jours d'adaptation, ces
siestes de 30 minutes deviennent tres tres intenses et reprennent tous les
cycles normaux du sommeil en concentre, dont notamment le sommeil paradoxal
(phase du sommeil nous aidant a recuperer mentalement et memoriser pendant la
nuit).

J'ai decide d'opter pour qqch de plus modeste. Je doute que le cycle de
sommeil uberman soit sain sur du long terme. Le corps manque d'occasion de se
reposer completement.

Donc en ce qui me concerne, j'ai choisi de garder 4h30 de sommeil et d'espacer
ensuite 30 minutes de siestes a peu pres toutes les 5 heures. Quand j'y
reflechis, beaucoup de gens vivent avec un rythme a peu pres similaire: mon
pere par exemple, se leve toujours aux environs de 6h du matin, mais fait une
sieste de 20 minutes apres manger et quand il revient du boulot. Ensuite, il
se couche vers 23h00. Il est aussi connu et accepte que les siestes sont
bonnes pour la sante, surtout dans un contexte ou on travaille 9h de suite
(ok, l'info, c'est pas physique, mais quand meme).

Le cycle de sommeil mode uberman est tres difficile a atteindre. J'ai lu de
nombreux mecs disant qu'ils avaient echoue au bout de qqs jours. Je pense que
mon rythme sera beaucoup plus facile a maintenir. J'ai aussi lu un mec qui l'a
suivi pendant 3 a 4 mois. La raison pour laquelle il a arrete, c'est que c'est
dur a concilier avec un environnement social, il trouvait ca trop
contraignant.

Tel que j'ai choisi mon rythme, je dois pouvoir faire une sieste vers 8h00
avant d'aller au boulot, une vers midi pendant la pause dejeuner et une vers
18h00, en fin de journee. Ensuite, je compte me coucher vers 11h00 ou minuit,
donc il semble possible d'accomoder cet emploi du temps avec une vie normale.

Normalement, je dors entre 8h00 et 9h00 par jour, et un peu plus que ca le
week-end. Je passe a 6h00, ce qui me fait 3 heures de plus par jour. Ouaa!!!

J'en suis a ma 3e nuit. Samedi et dimanche, j'ai fait une activite physique,
ce qui change un peu de mes habitudes, donc j'etais plutot fatigue
physiquement. J'ai trouve les siestes tres reparatrices, meme si je n'ai pas
reussi a dormir. Hier, j'etais plutot fatigue dans la journee, mais pas tant
que ca.

La, ca va, c'est plutot ce midi que je devrai accuser le coup. Le plus dur,
c'est pas de me reveiller, c'est de quitter le lit tout chaud ou il y a ma
copine. Hier, j'ai en envie de me recoucher pendant toute la matinee. On va
voir ce que ca donne aujourd'hui.

> Lire le journal (41 commentaires, moyenne: 3,8).

Je cherches des stagiaires geek pour quelques mois ou plus.

C'est pour faire du Qt, python et C++ pour des cartes a puces sans-contact (sujet plutot sympa). On est une startup, ambiance jeune et detendue, pas de prise de tete. Les locaux sont a cote de Denfert-Rocherau, a Paris.

Niveau experience, je prends des gens qui savent programmer, le diplome et les etudes etant pour moi des considerations subjectives. Bienvenu aux autodidactes s'il y en a.

Bon, le seul point negatif, c'est que c'est pour bosser sous windows (une bonne partie du temps) et que c'est sur des logiciesl proprio. Bienvenu dans le monde reel.

En dehors de ca, on est pro-libre a fond, on utilise un max d'outils libres (cygwin, python, qt, cppunit, roundup, thunderbird, enigmail, etc etc).

Le fait que ce soit une petite boite garantit une experience interessante. Vous ne serez pas laisses dans votre coin avec un cahier des charges et validation un mois avant la fin du stage. Je fais un suvi precis, des audits sur la qualite de code que vous produisez et je vous apprend a produire du code en mode "enterprise ready", c'est a dire un peu plus haut niveau que la majorite des projets open source ou de pas mal de produits commerciaux.

Je demande beaucoup d'autonomie et d'adaptation parce que vous allez bosser sur des sujets divers et critiques pour la boite et qu'il faudra vraiment etre en phase avec les besoins reels et les moyens qu'on a.

Tous les stagaires que j'ai eu jusqu'a present en sont ressortis enchantes et moi aussi. Vous pouvez me contacter via linuxfr. Ma page web est down (http://phil.freehackers.org(...)) mais vous pourrez voir que je ne suis pas un debutant du logiciel libre

> Lire le journal (86 commentaires, moyenne: 2,3).

Si ca interesse qq'un, j'ai recu une offre d'emploi pour bosser sous Qt, a laquelle je ne peux pas repondre car j'ai deja un bon boulot:

<<
Je recherche quelqu'un qui maitrise parfaitement l'environnement QT pour réaliser une IHM sur Windows portable sous Linux.
C'est un projet sur 4 mois à compter de tout de suite.
Si vous même, ou l'une de vos connaissances, êtes intéressé pout travailler dans une petite équipe, n'hésitez pas à me contacter ou à transférer mes coordonnées.

Bien entendu, d'autres compétences nous intéressent comme C/C++, Linux, la VOIP ou la connaissance d'environnements hardware comme les processeurs ARM, car nous sommes spécialisés dans le domaine du système embarqué (Linux, uCLinux, pSOS) et avons un très haut niveau d'expertise en voix sur IP.
>>

Me contacter pour que je vous donne le contact si vous etes interesses.

> Lire le journal (5 commentaires, moyenne: 3,4).

Je suis vraiment tres decu par lolix d'un point de vue employeur. J'ai vu un CV qui m'interessait. J'ai demande a pouvoir le consulter et rentrer en contact avec son auteur. Apres trois mois, toujours aucune nouvelle. Mon mail a du partir dans /dev/null . C'est surtout dommage pour la personne qui a pris la peine de deposer son CV.

Donc si vous deposez un CV sur lolix, mettez un truc pour qu'on puisse vous contacter sans passer par lolix, sinon vous perdez votre temps.

> Lire le journal (14 commentaires, moyenne: 1,2).

Vous croyez que c'est de la science-fiction ? Non, c'est la realite:


http://www.kuro5hin.org/story/2003/10/8/201119/758(...)

La version courte pour ceux qui ont la flemme de lire: un super systeme de mega anti-copie de CD pour windows fonctionne avec la fonction autorun du CD, qui installe automatiquement un driver pour empecher la copie du CD par l'ordinateur. Il suffit de desactiver l'autorun ou de presser shift quand on insere le CD pour pouvoir l'utiliser normalement (le ripper a merci). En effet, ils ont ete obliger d'inclure les pistes normales du CD pour le rendre lisible par un maximum d'equipements. Cela dit, il y a toujours la version wma DRM securise a mort a la fin du CD. On se demande qui va l'utiliser.

Le fun, c'est que ce chercheur est attaque par la boite qui avait fait ce super systeme mega-securise, puisqu'il explique tranquillement que vous pouvez bypasser le systeme en pressant shift.

Ce serait bien drole si ce n'etait pas si pathetique.

> Lire le journal (9 commentaires, moyenne: 1,4).