Faux. Qt >= 3.1 utilise des widgets natifs sous Aqua, windows et KDE. Pour les versions inferieur, c'est aussi le cas, mais pas sur toutes les plateformes.
Enfin, quand je dis widgets natifs, c'est un peu exagere. Ils utilisent l'api de style natif du systeme d'exploitation pour dessiner leurs widgets. Mais normalement, ca ne doit faire aucune difference visuelle.
Quand j'installe gimp sous windows, il me demande si je veux utiliser le style wimp. Je suppose que gtk est donc exactement comme qt, ils utilisent au mieux le style de la plateforme et au pire,un style similaire recode a la main.
euh, j'ai du mal lire. Le hurd etait tres attendu quand Linus a commence Linux. Depuis, plus personne ne l'attend...
Ok, c'est gratuit et ca n'enleve rien au respect que j'ai pour les developpeurs du Hurd. C'est juste que le monde ne s'arrete pas de tourner en attendant leur prochaine version.
Pour des petits patchs, correction de bugs, il est communement accepte que ce n'est pas un "travail derive" et que la licence n'entre pas en compte.
En revanche, tu as raison, si tu veux coder une fonctionnalite qui interesse Trolltech, te devras le faire soit avec une licence type BSD, soit renoncer a ton copyright, soit autoriser aussi la licence commerciale.
Dans la pratique, ce n'est pas un gros probleme pour Trolltech. Comme ils ont des revenus, ils peuvent embaucher une armee de developpeurs super competents et recoder eux-meme ce qu'ils ont envie d'avoir dans Qt. Ca fait une grosse difference par rapport aux projets open source qui ne fonctionnent que par contribution.
Exemple, les qcanvas de Qt ont d'abord ete developpe par Varwick Allison en dehors de Trolltech. Ils ont ete rajoute dans Qt quand il a ete embauche. Autre exemple, QSA, le moteur javascript de Qt a ete code par le mec qui a code le moteur javascript de KDE. Trolltech l'a embauche pour qu'il refasse ce qu'il avait deja fait, mais en mieux (il avait des contraintes differentes).
Pour finir, si tu veux fournir une version de Qt avec des modifs a toi qui ne sont que GPL, tu peux faire un fork ou fournir un patch.
Sinon, contrairement a toi, je trouve leur modele excellent. Grace a leur revenus, ils peuvent payer 80 programmeurs a plein temps pour faire un super boulot sur Qt, et tous les developpeurs Open Source en beneficient. Marier son metier et l'open source, c'est un peu le reve de tous les programmeurs de logiciel libre.
<< Rely only on low-level system facilities. FOX relies only on core system facilities, and does NOT wrap native GUI libraries or toolkits. This has the following benefits: >>
Ben justement, Qt fait la meme chose. Ca c'est une difference avec wxWidget.
Bon, si tu enleves les classes non graphiques de Qt (qui sont super pratiques, plus faciles a utiliser que la STL) et le systeme de signaux/slot qui est une des plus belle reussite de Qt, il ne reste pas grand chose.
J'ai pas essaye, mais tel que tu le decris, fox, c'est qt en moins bien.
Non. Le choix de passer par un pre-processeur apporte plus que juste les signaux et les slots. On gagne les proprietes, de l'introspection et une generation dynamique de slots. Tout ca, tu ne l'as pas par les template.
C'est un sujet debattu et rebattu. Trolltech repond regulierement qu'ils ont envisage le passage en template mais que le moc presente de nombreux avantages techniques qui font qu'ils gardent cette approche.
Tu utilises quoi quand tu n'utilises pas qmake ? Avec tous les generateurs de projets/makefile, gerer les mocs est trivial donc je suis curieux de voir ou ca te pose probleme.
> les boîtes commerciales programmant des applis proprio vont
> continuer à l'utiliser, préférant surement recoder 2 fois l'interface (win, X) que des payer des redevance a Qt...
Tu reves. 1500 $ par plateforme et par developpeur, ce n'est rien pour une boite. Si tu gagnes un mois de dev, tu t'es rembourse. Pour ce prix, tu peux obtenir un toolkit avec un support 24h, des developpements custom, un moteur javascript pour scripter tes applications, integrations complete dans microsoft windows (objets ActiveX) et tu programmes en C++ (pour votre info, l'industrie a laissee tombe le C il y a longtemp). Gtk n'a aucune chance. Va voir les success story du site de trolltech pour t'en convaincre.
C'est marrant, il y a un mosfet qui est un excellent developpeur et qui a bosser sur KDE. Bon, apparamment, ce n'est pas toi
> Je trouve que wxwidgets est un tres bon toolkit
On a pas dit qu'il etait mauvais, on a dit qu'ils avaient fait le mauvais choix.
> et un de ses enormes avantages que tu condamnes justement est le
> fait qu'il est tres proche des MFC
Ca presente un interet pour toi parce que tu programme en MFC. Maintenant, l'approche mutli-toolkit pose de nombreux problemes. Par exemple, un widget dispo un gtk mais pas en MFC devra etre recode en MFC avant d'etre disponible en wxWidget. Et plus il y a de toolkit supportes, plus la maintenance devient difficile.
Il y a ensuite les bugs specificques plateformes, qui alourdissent encore la maintenance.
Ensuite, il a les optimisations. Typiquement, le mec qui developpe sous linux se fait un super rich text control qu'il utilise pour stocker 2000 lignes de log. Il est content, ca marche bien et il pense que ca marche bien partout. Seulement pas de bol, le rich text control des MFC est _tres_ lent donc son appli sous windows est inutilisable.
Au contraire, l'approche de Trolltech enleve tous ces problemes. Le portage se reduit a porter les trois classes qui decrivent la plateforme. Les optimisations sur le rendu sont faites une fois pour toute et il n'y a pas de bugs specifique plate-formes. Ensuite, tous les widgets foncitonnent de la meme facon sur toutes les plateformes, le portage est vraiment une affaire de minutes.
Autres remarques:
- je ne sais pas comment tu peux preferer MFC a gtk. J'aime pas beaucoup gtk mais au moins, leur API est logique, deterministe, facile a comprendre, exempts de bugs bizarre et tres bien documentee. Aucun de ces adjectifs ne s'appliquent a MFC a mon avis.
- l'interface graphique en XML, gtk a ca depuis 7 ou 8 ans (cf glade) et Qt aussi (cf Qt Designer)
Tu devrais essayer Qt, ca te changera de paradigme et tu verras que tu seras plus efficace qu'en MFC.
Un soft peut avoir plusieurs licences tout comme un citoyen peut avoir plusieurs nationalite. Quand il passe la frontiere, il choisit le passport qu'il a envie de montrer et quand tu utilises un soft, tu choisis (si il a plusieurs licences) la licence avec laquelle tu veux l'utiliser.
Ce que je constate, c'est que la confiance qu'ont toujours eu les developpeurs KDE dans Trolltech est une fois de plus justifiee.
Quand KDE s'est lance, tout le monde a critique la licence de Qt mais les developpeurs KDE sont restes confiants que cela ne serait pas un obstacle pour le futur. Deux ans plus tard, Trolltech sortait la QPL qui resolvait tous ces problemes-la.
Ensuite, apres les seances de ralage industrialises, Trolltech est passe de la QPL a la GPL.
Et maintenant le GPL sous windows. Vraiment, c'est des gars bien !
Cette haine peut avoir de nombreuses explications et la rattacher a de l'incompetence, c'est le racourci ideologique facile qui t'evitera d'etre intelligent.
J'ai decouvert au bout de 2 heures que ca fait partie de gcc, et ca me semble le plus robuste comme approche. Mais tu peux essayer les autres, ca peut etre interessant (enfin, ceux qui sont libres).
La methode bourrin ou tu pre-process tes sources et ou tu rajoutes des macros de couveture de code, tu peux aussi te la redevelopper a la main.
> Essayer de couvrir tout le code d'une classe pour chaque état de l'objet reviendrait à explorer un arbre de possibilité infinie
Je ne suis pas d'accord. Le principe de la programmation objet est bien d'isoler les composants de facon a pouvoir les faire evoluer de facon autonome. Le corollaire, c'est que tu peux aussi les tester de facon autonome et donc de facon relativement finie.
S'il y a des conditions difficile a reproduire, c'est peut-etre aussi celle-la qui peuvent s'averer dangereuses. Par exemple, j'ai un protocole de communication sans-contact. C'est dur de simuler la perte de paquet dans le protocole, mais c'est hyper important de le faire, quitte a modifier un peu l'architecture de la gestion du protocole.
> Je trouve ça plus logique qu'on code une fonction à partir des spécifs
Dans le monde ideal, c'est comme ca. Dans le monde reel, il faut s'adapter. Moi je preconise deux approches:
- une approche black-box ou le testeur se base sur les specifs et test ce qui lui parait le plus important
- une approche transparent box ou le developpeur titille son programme la ou il sait que ca peut faire mal. Dans l'exemple que j'ai donne plus haut, un testeur ne pensera pas forcement a tester avec a = -b mais le developpeur lui saura que c'est une valeur cle a verifier.
Le plus proche d'un outil de couverture de code et couverture de chemin d'execution, c'est le cerveau du programmeur. Faire des tests uniquement en black-box (a partir des specifs), c'est se passer de cet outil.
> Il s'agit de générer des mutants
Super idee. Je vais chercher des references et voir si je peux mettre ca en pratique. En c, ca va etre un peu lourd...
En fait, il y a deux niveau. Le premier but d'un test, c'est de montrer que ton appli fait ce qu'elle doit faire. C'est le test fonctionnel, ou unitaire lorsqu'on se concentre sur un bout de code.
Moi j'interesse ici a la fiabilite (j'avais pas realise en ecrivant le journal, mais c'est vraiment le sujet). Comment prouver que l'appli ne fait jamais ce qu'elle ne doit pas faire. En gros, comment eviter a tout prix le segfault. Un utilisateur peut comprendre qu'une fonction ne fontionne pas bien. Mais un crash, ca reste incomprehensible et ca donne une tres tres mauvaise impression.
Apres, l'extension de "comment prouver que l'appli ne fait jamais ce qu'il faut pas meme quand on a la torture" peut etre vu comme "comment trouver le jeu de test qui torture l'appli suffisamment pour etre sur qu'elle resiste bien". On peut penser au cas simpliste du mec qui se code son strlen et qui est tout content parce que il marche. Sauf que quand tu lui passes un pointeur nul, paf, ca plante.
La preuve formelle, je ne connais que de nom mais apparemment, c'est tres difficile a conciler avec le travail quotidien du developpeur. Il faut y consacrer des resources et une intelligence non negligeable pour un resultat qui peut sembler minimal a cote de ce qu'on est capable de coder avec les memes resources.
Je developpe un OS pour carte a puce (proprietaire, mais aussi open source, cf jayacard.sf.net) et je voudrai etre sur qu'il est securise.
La technique de la mutation de code me parait une bonne approche. En plus de la couverture de code, ca permet de localiser des zones sombres. Je suis preneur d'autres trucs.
Les methodes que tu proposes pour peter le systeme sont plutot minables. La methode du bulldozer, ca se faisait au Bresil, ca ne se fait plus en France. Le plus simple, c'est de mettre un mini-lecteur de bande magnetique sur la fente ou tu enfonces ta carte, ou de mettre une webcam en fibre optique derrier le mec qui tape (sur le plafond du distributeur).
En plus, le besoin, ce n'est pas de casser une carte donnee, c'est de faire des fausses cartes. Ca tombe bien parce que c'est beaucoup plus facile. Donc ce qui devrait faire rire les professionnels, ce n'est pas la carte.
Le rapport un mois / 1h est aussi tres fantaisiste.
Bref, tes affirmations sont plutot a cote de la plaque, ce qui me fait dire que tu ne connais pas grand chose sur le sujet a part les trucs que tu as entendu a gauche et a droite.
Le gros probleme du systeme de paiement francais, c'est qu'il y a des vieux terminaux de paiement encore presents chez les commercants, donc on ne peut pas faire evoluer le systeme facilement. Si il suffisait de changer les cartes, il y a longtemp que ce serait fait, on les change tous les 4 ans. Il faut voir que les commercants payent pour le terminal de paiement et qu'ils n'ont pas envie de le changer tous les ans (an 2000, euro, moneo, EMV 2000, bon voyons !)
Pour vous consoler,on a le systeme le plus securise du monde pour la gestion de cartes bancaires. Je vous laisse imaginer ce que c'est ailleurs...
Ce que tu attribues au fonctionnariat , c'est tout simplement l'attitude lamentable qu'ont les societes francaises vis a vis du support client. Tu trouveras la meme chose chez free, cegetel, bouygues, etc etc.
Il y a plein de facteurs qui jouent contre toi. Par exemple, certains supports sont remuneres au nombre de coup de fil traites. Client emmerdant = moins d'argent pour le mec a l'autre bout du fil. Pour ce qui est des prenoms qu'on te donne, ils sont rentres sur ta fiche de facon a etre utilises la prochaine fois qu'on te recontacte mais soit sur que ca ne sera pas la meme personne.
Le moyen le plus efficace de se faire entendre reste le "passer mois le service des resiliations..."
Tu as beaucoup d'exemples ou tu as eu besoin de coder une classe a laquelle tu peux ajouter 1, mais qui ne serait pas convertible en entier/float ?
C'est super dans le principe, mais je pense que c'est plus dangereux a l'usage que le gain que ca apporte. En tout cas, ca l'es dans le contexte ou j'utilise python.
> Une des grandes forces de python est sa capacité d'instrospection, réflexivité et auto modification. Typiquement on peut tout à fait imaginer
> des variables dont le type dépende de données disponibles uniquement à l'exécution.
Je pense que ce type d'exemple donne du code particulierement complexe a comprendre et a maintenir. Dans certains cas, c'est pratique, mais dans la plupart, c'est plutot risque.
Faut voir que si tu leves une exception dans ton code, tu es "foutu", c'est comme si tu avais fait un segfault.
Un des problemes de python, c'est que sur un gros programme, tu as beaucoup de chances d'avoir dans un coin un fonction qui te renvoie un type qui va faire planter tout ton programme. J'ai eu le cas il y a quelques semaines avec un stagiaire qui m'a code une fonction renvoyant une liste ou bien None quand il n'y avait rien a renvoyer. Le none a foutu la merde, alors que renvoyer une liste vide serait passe sans probleme.
En s'appuyant sur un typage fort, statique mais non declaratif ni impose (c'est a dire comme en ocaml, avec juste de l'inference de type), on peut avoir plus de certitudes sur la fiabilite d'un programme, ce qui me parait un eujeu fondamental du developpement logiciel de nos jours.
L'evaluation critere commun (EAL4+) t'empeche dans une large mesure de publier le code source de tes cartes. Ils considerent que cela represente une aide trop grande aux cradker pour peter ton OS. Les specs du hardware sont egalement protegees, accessibles uniquement sous NDA.
Ces evaluations comprennent aussi l'audit de code et la soumission de la carte a un labo qui essaye de la peter. Cela dit, je suis d'accord que c'est loin d'etre suffisant.
Pour ce que c'est qu'un OS securise, tu peux aller voir jayacard.sf.net . Cet OS open source pour carte a puce est protege contre les attaques connues au moment ou il a ete ecrit: Static Power Analysis, Dynamic Power Analysis, Fault injection, Electromagnetic Power Analysis.
Le reste de reseau est a mon avis bien plus fragile, c'est ce que j'ai dit dans mon post. Mais la carte honnetement, c'est du costaud. C'est un peu comme critiquer OO parce qu'il charge mal les document word. C'est pas a ce probleme qu'il faut s'attaquer.
Desole de te decevoir, mais le monsieur a tout a fait raison. Les cartes a puces sont aujourd'hui de veritables forteresses et il est tres difficile de les casser. Le hard est protege contre bien plus d'attaques que tu pourrais n'en imaginer, et le soft aussi. Bien sur, tout systeme est craquable et peut contenir des failles, mais pour peter une carte a puce concue aujourd'hui, il faut etre tres tres riche.
Le cas de Serge Humpich n'est pas forcement a generaler. Dans ce cas-la, on avait une vieille carte (une CB-B0' si je me souviens bien, ca date des annees 80) avec un systeme d'authentification offline minable. La faiblesse ne venait pas de la carte (d'ailleur, Humpich n'a pas casse la carte mais de l'automate) mais de la plateforme complete de paiment.
Je travaille actuellement sur les passeport electronique. Ils vont effectivement contenir photo, empreintes digitales et empreintes retiniennes. Les prochaines carte d'identite seront certainement derivees de ces specs.
Je peux t'affirmer une chose: les specs sont bien concues. Les principales objection par rapport a la protection de la vie privee sont prise en compte. Le seul hic, c'est que la securite maximale n'est pas exigee par defaut, mais seulement recommandee.
Concernant le passport, je vous decrit brievement comment ca marche:
- la carte ne contient pas les informations ecrites sur le passport. Notamment, le nom, le no du passport et la nationalite ne sont pas sur la carte. Un hash de ces infos est stockee sur la carte
=> lire la carte ne revele pas ces infos importantes
- toute lecture d'informations biometriques sur la carte est protegee par une authentification dynamique a la base des infos visuelles contenues dans le passport (nom, nationalite, etc). Donc, il est necesssaire de lire le passport optimquement avant de pouvoir lire le contenu de la carte.
=> impossible de scanner a distance le contenu du passport, il faut que le porteur le presente de facon ouverte pour qu'on puisse y acceder
- l'authentification se fait en s'appuyant sur un random
=> impossible de rejouer
- l'authentification est basee sur une signature avec une cle RSA et du DES ou de l'AES
=> pas facile a craquer
- la laison entre le passport et le lecteur est encryptee avec du DES et une cle de session generee a partir du random, de la cle de la carte et de l'authentificatino
=> impossible d'esploinner la communication
- la distance de fonctionnement est < 10 cm
=> on peut pas scanner toutes les personnes d'une piece. A moderer quand meme car on peut faire des super lecteurs, pas legaux, qui pourraient faire ce genre de chose.
On est quand meme loin du scenario noir decrit dans la plupart des cas.
Donc en ce qui concerne la carte, c'est bien securise. Maintenant, il reste les questions sur le systeme global:
- pourquoi est-ce que la securite max de la carte n'est pas obligatoire ? Ce serait les US qui ont refuse que ce soit obligatoire.
- que fait le lecteur des infos qu'il a lu ? Pour gerer le visa electronique, on parle de faire une connexion a une super base de donnee contenant toutes les infos des utilisateurs. Ca, c'est inquietant
- est-ce legitime de demander autant d'informations d'authentification sur une personne ? La fraude d'identite n'est pas a priori qqch que les gouvernements aiment, donc tout moyen pour la combattre est en general accueilli avec joie.
Il y a des choses a combattre sur ce syteme, mais ne vous trompez pas de cible. C'est pas la carte qu'il faut viser pour trouver des defaillances techniques.
Les specs du passeport electronique sont dispo pour tout le monde sur le web. Je ne retrouve pas les references, mais je peux diffuser le document si certains sont interesses.
Ouai, pour adopter un truc pareil, il va falloir changer de planete parce que la terre continue a faire un tour sur elle-meme en 24h.
Cela dit, dans "Les cavernes d'acier", Asimov nous dedrit un monde du futur ou toutes les villes du monde sont recouvertes d'un toit et ou elles vivent toutes a la meme heure.
Tu supposes qu'il n'est pas du tout naturel de dormir par petite sieste plutot que 8h d'un coup. Pourtant, quand on etait des singes chasses par des predateurs, on avait plutot interet a ne pas tomber dans le coltar pendant 8h de suite, mais a rester plutot alerte en permanence, et ne dormir que quand on pouvait se le permettre.
En tout cas, l'idee de faire des siestes pendant la journee me semble plutot bonne, et peut coller avec une reduction du nombre d'heure de sommeil total.
> Mais de façon générale celà n'influence pas l'égalité des chances car fcelà concerne souvent une minorité
Tu crois vraiment ce que tu dis ? Pour avoir ete toujours ete dans les meilleures classes, je peux te dire qu'il y a pas du tout egalite des chances.
Si tu comptes les fils/filles de profs et d'ingenieurs, tu arrives a plus de 80% de l'effectif de la classe. L'egalite des chances, tu la perds des ta naissance.
Toutes les sciences humaines s'appuient sur un savoir qui est dispense certe a l'ecole, mais qui est surtout diffuse via la famille (cinema, theatre, lecture, ...). Qq'un dont les parents ne sont pas cadres a beaucoup moins acces a cette culture et a beaucoup moins de chances d'assurer des bonnes notes dans ces matieres pendant sa scolarite. Heureusement, il n'y a pas ce probleme pour les matieres scientifiques ou les capacites d'analyses priment sur le savoir culturel.
Le fait est que le systeme educatif est construit par des gens instruits, pour faciliter la vie des gens instruits. Le systeme s'auto-nourrit et les changements de classe sociale parent/enfants sont tres tres rares.
Tu peux ajouter a ca que les profs et les ingenieurs maitrisent souvcent tres tres bien le systeme educatif et sauront te placer dans les tres bonnes classes et les tres bon lycees alors que ceux qui pensent naivement que l'ecole donne leur chance a tous de la meme facon se retrouveront soit dans les classes moyennes, soit dans les classes pourries. Pourquoi j'ai fait "Allemand/Anglais/Latin" ? J'ai beau pareler couramment allemand, ca ne me sert jamais. Par contre, l'espagnol me serait plus util mais ca te mettais dans les mauvaises classes, alors il ne fallait pas y songer...
Pour les tres bons eleves, le systeme ne penalise pas trop. Ils arriveront quand meme a monter. Mais pour tout ceux qui sont dans la moyenne, le niveau de la classe est nivele globalement par le lycee, les profs et les eleves de la classe. Dont tous ceux qui ne sont pas dans les bonnes classes sortiront moins bons a la fin de l'annee.
Le mythe de l'ecole doit etre la meme pour tous est en train de tomber, et on se rend compte que pour donner les memes chances a tout le monde, il faut donner plus a certains qui sont moins favorises.
[^] # Re: 1 de perdu...
Posté par Philippe F (site web personnel) . En réponse au journal Qt 4.0 en GPL sous Windows. Évalué à 2.
Enfin, quand je dis widgets natifs, c'est un peu exagere. Ils utilisent l'api de style natif du systeme d'exploitation pour dessiner leurs widgets. Mais normalement, ca ne doit faire aucune difference visuelle.
Quand j'installe gimp sous windows, il me demande si je veux utiliser le style wimp. Je suppose que gtk est donc exactement comme qt, ils utilisent au mieux le style de la plateforme et au pire,un style similaire recode a la main.
[^] # Re: 1 de perdu...
Posté par Philippe F (site web personnel) . En réponse au journal Qt 4.0 en GPL sous Windows. Évalué à 3.
euh, j'ai du mal lire. Le hurd etait tres attendu quand Linus a commence Linux. Depuis, plus personne ne l'attend...
Ok, c'est gratuit et ca n'enleve rien au respect que j'ai pour les developpeurs du Hurd. C'est juste que le monde ne s'arrete pas de tourner en attendant leur prochaine version.
[^] # Re: et wxWidgets dans tout ça ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Trolltech va publier Qt 4 pour Windows sous double licence. Évalué à 2.
- sous windows, Qt utlise l'api de style de windows, donc les widgets ont exactement la meme tete que les widgets MFC
- idem sous aqua/mac os X, et sous KDE.
[^] # Re: c'est toujours pas libre ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Trolltech va publier Qt 4 pour Windows sous double licence. Évalué à 6.
En revanche, tu as raison, si tu veux coder une fonctionnalite qui interesse Trolltech, te devras le faire soit avec une licence type BSD, soit renoncer a ton copyright, soit autoriser aussi la licence commerciale.
Dans la pratique, ce n'est pas un gros probleme pour Trolltech. Comme ils ont des revenus, ils peuvent embaucher une armee de developpeurs super competents et recoder eux-meme ce qu'ils ont envie d'avoir dans Qt. Ca fait une grosse difference par rapport aux projets open source qui ne fonctionnent que par contribution.
Exemple, les qcanvas de Qt ont d'abord ete developpe par Varwick Allison en dehors de Trolltech. Ils ont ete rajoute dans Qt quand il a ete embauche. Autre exemple, QSA, le moteur javascript de Qt a ete code par le mec qui a code le moteur javascript de KDE. Trolltech l'a embauche pour qu'il refasse ce qu'il avait deja fait, mais en mieux (il avait des contraintes differentes).
Pour finir, si tu veux fournir une version de Qt avec des modifs a toi qui ne sont que GPL, tu peux faire un fork ou fournir un patch.
Sinon, contrairement a toi, je trouve leur modele excellent. Grace a leur revenus, ils peuvent payer 80 programmeurs a plein temps pour faire un super boulot sur Qt, et tous les developpeurs Open Source en beneficient. Marier son metier et l'open source, c'est un peu le reve de tous les programmeurs de logiciel libre.
[^] # Re: et wxWidgets dans tout ça ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Trolltech va publier Qt 4 pour Windows sous double licence. Évalué à 2.
Ben justement, Qt fait la meme chose. Ca c'est une difference avec wxWidget.
Bon, si tu enleves les classes non graphiques de Qt (qui sont super pratiques, plus faciles a utiliser que la STL) et le systeme de signaux/slot qui est une des plus belle reussite de Qt, il ne reste pas grand chose.
J'ai pas essaye, mais tel que tu le decris, fox, c'est qt en moins bien.
[^] # Re: preprocessing
Posté par Philippe F (site web personnel) . En réponse à la dépêche Trolltech va publier Qt 4 pour Windows sous double licence. Évalué à 3.
C'est un sujet debattu et rebattu. Trolltech repond regulierement qu'ils ont envisage le passage en template mais que le moc presente de nombreux avantages techniques qui font qu'ils gardent cette approche.
Tu utilises quoi quand tu n'utilises pas qmake ? Avec tous les generateurs de projets/makefile, gerer les mocs est trivial donc je suis curieux de voir ou ca te pose probleme.
> les boîtes commerciales programmant des applis proprio vont
> continuer à l'utiliser, préférant surement recoder 2 fois l'interface (win, X) que des payer des redevance a Qt...
Tu reves. 1500 $ par plateforme et par developpeur, ce n'est rien pour une boite. Si tu gagnes un mois de dev, tu t'es rembourse. Pour ce prix, tu peux obtenir un toolkit avec un support 24h, des developpements custom, un moteur javascript pour scripter tes applications, integrations complete dans microsoft windows (objets ActiveX) et tu programmes en C++ (pour votre info, l'industrie a laissee tombe le C il y a longtemp). Gtk n'a aucune chance. Va voir les success story du site de trolltech pour t'en convaincre.
[^] # Re: et wxWidgets dans tout ça ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Trolltech va publier Qt 4 pour Windows sous double licence. Évalué à 3.
> Je trouve que wxwidgets est un tres bon toolkit
On a pas dit qu'il etait mauvais, on a dit qu'ils avaient fait le mauvais choix.
> et un de ses enormes avantages que tu condamnes justement est le
> fait qu'il est tres proche des MFC
Ca presente un interet pour toi parce que tu programme en MFC. Maintenant, l'approche mutli-toolkit pose de nombreux problemes. Par exemple, un widget dispo un gtk mais pas en MFC devra etre recode en MFC avant d'etre disponible en wxWidget. Et plus il y a de toolkit supportes, plus la maintenance devient difficile.
Il y a ensuite les bugs specificques plateformes, qui alourdissent encore la maintenance.
Ensuite, il a les optimisations. Typiquement, le mec qui developpe sous linux se fait un super rich text control qu'il utilise pour stocker 2000 lignes de log. Il est content, ca marche bien et il pense que ca marche bien partout. Seulement pas de bol, le rich text control des MFC est _tres_ lent donc son appli sous windows est inutilisable.
Au contraire, l'approche de Trolltech enleve tous ces problemes. Le portage se reduit a porter les trois classes qui decrivent la plateforme. Les optimisations sur le rendu sont faites une fois pour toute et il n'y a pas de bugs specifique plate-formes. Ensuite, tous les widgets foncitonnent de la meme facon sur toutes les plateformes, le portage est vraiment une affaire de minutes.
Autres remarques:
- je ne sais pas comment tu peux preferer MFC a gtk. J'aime pas beaucoup gtk mais au moins, leur API est logique, deterministe, facile a comprendre, exempts de bugs bizarre et tres bien documentee. Aucun de ces adjectifs ne s'appliquent a MFC a mon avis.
- l'interface graphique en XML, gtk a ca depuis 7 ou 8 ans (cf glade) et Qt aussi (cf Qt Designer)
Tu devrais essayer Qt, ca te changera de paradigme et tu verras que tu seras plus efficace qu'en MFC.
[^] # Re: Double licence ?
Posté par Philippe F (site web personnel) . En réponse au journal Qt 4.0 en GPL sous Windows. Évalué à 5.
# Nous avons eu raison de croire en Qt
Posté par Philippe F (site web personnel) . En réponse au journal Qt 4.0 en GPL sous Windows. Évalué à 10.
Quand KDE s'est lance, tout le monde a critique la licence de Qt mais les developpeurs KDE sont restes confiants que cela ne serait pas un obstacle pour le futur. Deux ans plus tard, Trolltech sortait la QPL qui resolvait tous ces problemes-la.
Ensuite, apres les seances de ralage industrialises, Trolltech est passe de la QPL a la GPL.
Et maintenant le GPL sous windows. Vraiment, c'est des gars bien !
[^] # Re: surtout pas
Posté par Philippe F (site web personnel) . En réponse au journal Besoin d'arguments de chocs contre Microsoft. Évalué à 2.
[^] # Re: surtout pas
Posté par Philippe F (site web personnel) . En réponse au journal Besoin d'arguments de chocs contre Microsoft. Évalué à 6.
Nan, je plaisante
[^] # Re: Un truc en C++ qui fait ca
Posté par Philippe F (site web personnel) . En réponse au journal couverture de code. Évalué à 2.
http://ltp.sourceforge.net/coverage/lcov.php(...)
http://www.semdesigns.com/Products/TestCoverage/CppTestCoverage.htm(...)
Bon, en fait, il n'y a pas grand chose.
J'ai decouvert au bout de 2 heures que ca fait partie de gcc, et ca me semble le plus robuste comme approche. Mais tu peux essayer les autres, ca peut etre interessant (enfin, ceux qui sont libres).
La methode bourrin ou tu pre-process tes sources et ou tu rajoutes des macros de couveture de code, tu peux aussi te la redevelopper a la main.
[^] # Re: Pas si simple...
Posté par Philippe F (site web personnel) . En réponse au journal couverture de code. Évalué à 2.
Je ne suis pas d'accord. Le principe de la programmation objet est bien d'isoler les composants de facon a pouvoir les faire evoluer de facon autonome. Le corollaire, c'est que tu peux aussi les tester de facon autonome et donc de facon relativement finie.
S'il y a des conditions difficile a reproduire, c'est peut-etre aussi celle-la qui peuvent s'averer dangereuses. Par exemple, j'ai un protocole de communication sans-contact. C'est dur de simuler la perte de paquet dans le protocole, mais c'est hyper important de le faire, quitte a modifier un peu l'architecture de la gestion du protocole.
> Je trouve ça plus logique qu'on code une fonction à partir des spécifs
Dans le monde ideal, c'est comme ca. Dans le monde reel, il faut s'adapter. Moi je preconise deux approches:
- une approche black-box ou le testeur se base sur les specifs et test ce qui lui parait le plus important
- une approche transparent box ou le developpeur titille son programme la ou il sait que ca peut faire mal. Dans l'exemple que j'ai donne plus haut, un testeur ne pensera pas forcement a tester avec a = -b mais le developpeur lui saura que c'est une valeur cle a verifier.
Le plus proche d'un outil de couverture de code et couverture de chemin d'execution, c'est le cerveau du programmeur. Faire des tests uniquement en black-box (a partir des specifs), c'est se passer de cet outil.
> Il s'agit de générer des mutants
Super idee. Je vais chercher des references et voir si je peux mettre ca en pratique. En c, ca va etre un peu lourd...
[^] # Re: pas une preuve
Posté par Philippe F (site web personnel) . En réponse au journal couverture de code. Évalué à 3.
Moi j'interesse ici a la fiabilite (j'avais pas realise en ecrivant le journal, mais c'est vraiment le sujet). Comment prouver que l'appli ne fait jamais ce qu'elle ne doit pas faire. En gros, comment eviter a tout prix le segfault. Un utilisateur peut comprendre qu'une fonction ne fontionne pas bien. Mais un crash, ca reste incomprehensible et ca donne une tres tres mauvaise impression.
Apres, l'extension de "comment prouver que l'appli ne fait jamais ce qu'il faut pas meme quand on a la torture" peut etre vu comme "comment trouver le jeu de test qui torture l'appli suffisamment pour etre sur qu'elle resiste bien". On peut penser au cas simpliste du mec qui se code son strlen et qui est tout content parce que il marche. Sauf que quand tu lui passes un pointeur nul, paf, ca plante.
La preuve formelle, je ne connais que de nom mais apparemment, c'est tres difficile a conciler avec le travail quotidien du developpeur. Il faut y consacrer des resources et une intelligence non negligeable pour un resultat qui peut sembler minimal a cote de ce qu'on est capable de coder avec les memes resources.
Je developpe un OS pour carte a puce (proprietaire, mais aussi open source, cf jayacard.sf.net) et je voudrai etre sur qu'il est securise.
La technique de la mutation de code me parait une bonne approche. En plus de la couverture de code, ca permet de localiser des zones sombres. Je suis preneur d'autres trucs.
[^] # Re: URL
Posté par Philippe F (site web personnel) . En réponse au journal Carte d'identité biométrique. Évalué à 4.
Les methodes que tu proposes pour peter le systeme sont plutot minables. La methode du bulldozer, ca se faisait au Bresil, ca ne se fait plus en France. Le plus simple, c'est de mettre un mini-lecteur de bande magnetique sur la fente ou tu enfonces ta carte, ou de mettre une webcam en fibre optique derrier le mec qui tape (sur le plafond du distributeur).
En plus, le besoin, ce n'est pas de casser une carte donnee, c'est de faire des fausses cartes. Ca tombe bien parce que c'est beaucoup plus facile. Donc ce qui devrait faire rire les professionnels, ce n'est pas la carte.
Le rapport un mois / 1h est aussi tres fantaisiste.
Bref, tes affirmations sont plutot a cote de la plaque, ce qui me fait dire que tu ne connais pas grand chose sur le sujet a part les trucs que tu as entendu a gauche et a droite.
Le gros probleme du systeme de paiement francais, c'est qu'il y a des vieux terminaux de paiement encore presents chez les commercants, donc on ne peut pas faire evoluer le systeme facilement. Si il suffisait de changer les cartes, il y a longtemp que ce serait fait, on les change tous les 4 ans. Il faut voir que les commercants payent pour le terminal de paiement et qu'ils n'ont pas envie de le changer tous les ans (an 2000, euro, moneo, EMV 2000, bon voyons !)
Pour vous consoler,on a le systeme le plus securise du monde pour la gestion de cartes bancaires. Je vous laisse imaginer ce que c'est ailleurs...
[^] # Re: HS ?
Posté par Philippe F (site web personnel) . En réponse au journal Job: développeur XUL demandé. Évalué à 3.
Ou bien personne n'a repondu ? Pourquoi tu rejettes d'emblle l'explication la plus simple ?
> Parler d'une "mission de trois ans", c'est franchement limite.
Moi j'ai pris ca comme un CDI. C'est possible que ca ne soit pas le cas ?
[^] # Re: Titin chez les soviets
Posté par Philippe F (site web personnel) . En réponse au journal 3939, parce qu'ils ne vallent rien..?. Évalué à 10.
Il y a plein de facteurs qui jouent contre toi. Par exemple, certains supports sont remuneres au nombre de coup de fil traites. Client emmerdant = moins d'argent pour le mec a l'autre bout du fil. Pour ce qui est des prenoms qu'on te donne, ils sont rentres sur ta fiche de facon a etre utilises la prochaine fois qu'on te recontacte mais soit sur que ca ne sera pas la meme personne.
Le moyen le plus efficace de se faire entendre reste le "passer mois le service des resiliations..."
[^] # Re: OCaml & python ont vraiment des approches et possibilités différente
Posté par Philippe F (site web personnel) . En réponse au journal pas d'inference de type a la ocmal en python. Évalué à 2.
C'est super dans le principe, mais je pense que c'est plus dangereux a l'usage que le gain que ca apporte. En tout cas, ca l'es dans le contexte ou j'utilise python.
[^] # Re: OCaml & python ont vraiment des approches et possibilités différente
Posté par Philippe F (site web personnel) . En réponse au journal pas d'inference de type a la ocmal en python. Évalué à 4.
> des variables dont le type dépende de données disponibles uniquement à l'exécution.
Je pense que ce type d'exemple donne du code particulierement complexe a comprendre et a maintenir. Dans certains cas, c'est pratique, mais dans la plupart, c'est plutot risque.
Faut voir que si tu leves une exception dans ton code, tu es "foutu", c'est comme si tu avais fait un segfault.
Un des problemes de python, c'est que sur un gros programme, tu as beaucoup de chances d'avoir dans un coin un fonction qui te renvoie un type qui va faire planter tout ton programme. J'ai eu le cas il y a quelques semaines avec un stagiaire qui m'a code une fonction renvoyant une liste ou bien None quand il n'y avait rien a renvoyer. Le none a foutu la merde, alors que renvoyer une liste vide serait passe sans probleme.
En s'appuyant sur un typage fort, statique mais non declaratif ni impose (c'est a dire comme en ocaml, avec juste de l'inference de type), on peut avoir plus de certitudes sur la fiabilite d'un programme, ce qui me parait un eujeu fondamental du developpement logiciel de nos jours.
[^] # Re: EAL
Posté par Philippe F (site web personnel) . En réponse au journal Carte d'identité biométrique. Évalué à 2.
[^] # Re: URL
Posté par Philippe F (site web personnel) . En réponse au journal Carte d'identité biométrique. Évalué à 2.
Ces evaluations comprennent aussi l'audit de code et la soumission de la carte a un labo qui essaye de la peter. Cela dit, je suis d'accord que c'est loin d'etre suffisant.
Pour ce que c'est qu'un OS securise, tu peux aller voir jayacard.sf.net . Cet OS open source pour carte a puce est protege contre les attaques connues au moment ou il a ete ecrit: Static Power Analysis, Dynamic Power Analysis, Fault injection, Electromagnetic Power Analysis.
Le reste de reseau est a mon avis bien plus fragile, c'est ce que j'ai dit dans mon post. Mais la carte honnetement, c'est du costaud. C'est un peu comme critiquer OO parce qu'il charge mal les document word. C'est pas a ce probleme qu'il faut s'attaquer.
[^] # Re: URL
Posté par Philippe F (site web personnel) . En réponse au journal Carte d'identité biométrique. Évalué à 9.
Le cas de Serge Humpich n'est pas forcement a generaler. Dans ce cas-la, on avait une vieille carte (une CB-B0' si je me souviens bien, ca date des annees 80) avec un systeme d'authentification offline minable. La faiblesse ne venait pas de la carte (d'ailleur, Humpich n'a pas casse la carte mais de l'automate) mais de la plateforme complete de paiment.
Je travaille actuellement sur les passeport electronique. Ils vont effectivement contenir photo, empreintes digitales et empreintes retiniennes. Les prochaines carte d'identite seront certainement derivees de ces specs.
Je peux t'affirmer une chose: les specs sont bien concues. Les principales objection par rapport a la protection de la vie privee sont prise en compte. Le seul hic, c'est que la securite maximale n'est pas exigee par defaut, mais seulement recommandee.
Concernant le passport, je vous decrit brievement comment ca marche:
- la carte ne contient pas les informations ecrites sur le passport. Notamment, le nom, le no du passport et la nationalite ne sont pas sur la carte. Un hash de ces infos est stockee sur la carte
=> lire la carte ne revele pas ces infos importantes
- toute lecture d'informations biometriques sur la carte est protegee par une authentification dynamique a la base des infos visuelles contenues dans le passport (nom, nationalite, etc). Donc, il est necesssaire de lire le passport optimquement avant de pouvoir lire le contenu de la carte.
=> impossible de scanner a distance le contenu du passport, il faut que le porteur le presente de facon ouverte pour qu'on puisse y acceder
- l'authentification se fait en s'appuyant sur un random
=> impossible de rejouer
- l'authentification est basee sur une signature avec une cle RSA et du DES ou de l'AES
=> pas facile a craquer
- la laison entre le passport et le lecteur est encryptee avec du DES et une cle de session generee a partir du random, de la cle de la carte et de l'authentificatino
=> impossible d'esploinner la communication
- la distance de fonctionnement est < 10 cm
=> on peut pas scanner toutes les personnes d'une piece. A moderer quand meme car on peut faire des super lecteurs, pas legaux, qui pourraient faire ce genre de chose.
On est quand meme loin du scenario noir decrit dans la plupart des cas.
Donc en ce qui concerne la carte, c'est bien securise. Maintenant, il reste les questions sur le systeme global:
- pourquoi est-ce que la securite max de la carte n'est pas obligatoire ? Ce serait les US qui ont refuse que ce soit obligatoire.
- que fait le lecteur des infos qu'il a lu ? Pour gerer le visa electronique, on parle de faire une connexion a une super base de donnee contenant toutes les infos des utilisateurs. Ca, c'est inquietant
- est-ce legitime de demander autant d'informations d'authentification sur une personne ? La fraude d'identite n'est pas a priori qqch que les gouvernements aiment, donc tout moyen pour la combattre est en general accueilli avec joie.
Il y a des choses a combattre sur ce syteme, mais ne vous trompez pas de cible. C'est pas la carte qu'il faut viser pour trouver des defaillances techniques.
Les specs du passeport electronique sont dispo pour tout le monde sur le web. Je ne retrouve pas les references, mais je peux diffuser le document si certains sont interesses.
[^] # Re: Dormir plus !
Posté par Philippe F (site web personnel) . En réponse au journal Sommeil polyphasique. Évalué à 4.
Cela dit, dans "Les cavernes d'acier", Asimov nous dedrit un monde du futur ou toutes les villes du monde sont recouvertes d'un toit et ou elles vivent toutes a la meme heure.
[^] # Re: Bon
Posté par Philippe F (site web personnel) . En réponse au journal Optimiser son sommeil. Évalué à 2.
En tout cas, l'idee de faire des siestes pendant la journee me semble plutot bonne, et peut coller avec une reduction du nombre d'heure de sommeil total.
[^] # Re: Je m'y colle
Posté par Philippe F (site web personnel) . En réponse au journal Epitech quelle est votre avis ?. Évalué à 3.
Tu crois vraiment ce que tu dis ? Pour avoir ete toujours ete dans les meilleures classes, je peux te dire qu'il y a pas du tout egalite des chances.
Si tu comptes les fils/filles de profs et d'ingenieurs, tu arrives a plus de 80% de l'effectif de la classe. L'egalite des chances, tu la perds des ta naissance.
Toutes les sciences humaines s'appuient sur un savoir qui est dispense certe a l'ecole, mais qui est surtout diffuse via la famille (cinema, theatre, lecture, ...). Qq'un dont les parents ne sont pas cadres a beaucoup moins acces a cette culture et a beaucoup moins de chances d'assurer des bonnes notes dans ces matieres pendant sa scolarite. Heureusement, il n'y a pas ce probleme pour les matieres scientifiques ou les capacites d'analyses priment sur le savoir culturel.
Le fait est que le systeme educatif est construit par des gens instruits, pour faciliter la vie des gens instruits. Le systeme s'auto-nourrit et les changements de classe sociale parent/enfants sont tres tres rares.
Tu peux ajouter a ca que les profs et les ingenieurs maitrisent souvcent tres tres bien le systeme educatif et sauront te placer dans les tres bonnes classes et les tres bon lycees alors que ceux qui pensent naivement que l'ecole donne leur chance a tous de la meme facon se retrouveront soit dans les classes moyennes, soit dans les classes pourries. Pourquoi j'ai fait "Allemand/Anglais/Latin" ? J'ai beau pareler couramment allemand, ca ne me sert jamais. Par contre, l'espagnol me serait plus util mais ca te mettais dans les mauvaises classes, alors il ne fallait pas y songer...
Pour les tres bons eleves, le systeme ne penalise pas trop. Ils arriveront quand meme a monter. Mais pour tout ceux qui sont dans la moyenne, le niveau de la classe est nivele globalement par le lycee, les profs et les eleves de la classe. Dont tous ceux qui ne sont pas dans les bonnes classes sortiront moins bons a la fin de l'annee.
Le mythe de l'ecole doit etre la meme pour tous est en train de tomber, et on se rend compte que pour donner les memes chances a tout le monde, il faut donner plus a certains qui sont moins favorises.