> Parce que la seule chose que les spammers ne peuvent deviner c'est l'adresse de vos amis.
Faux. Les spammeurs sont tres intelligents et tres ruses. J'ai deja recu des messages avec des adresses de copains, de collegues, et meme de rms@gnu.org avec du spam ou des virus (au choix).
Je pense qu'ils ont recolte ca sur des mailing lists ou sur des forums de discussion.
Par ailleurs, je suis abonne a une dizaine de mailinst-list et je recois environ 100 mails par jour. Je ne me vois pas mettre tout ce beau monde en while-liste, surtout que ca change tout le temps.
Pour moi le filtrage bayesien (bogofilter en l'occurence) reste la solution vraiment performante et peu couteuse.
La news dit une connerie: l'introduction de mot aleatoires dans les mails permet de passer les filtres statiques et ceux qui se basent sur la signature du mail (puisque la signature change a chaque mail).
En revanche, un filtre bayesien bloque ca "finger in the nose" puisqu'il ne va regarder que les mots qui sont particulierement significatifs sur le mail. Difficile d'envoyer un mail sur le viagra sans utiliser les mots "viagra" ou "performance sexuelle". Le filtre bayesien verra ces mots et leur accordera plus d'importance que les "saldhjadhcxnzweqiy" ajoutes pour tromper l'ennemi.
> En ce qui concerne les filtres, et notamment les filtres Baysiens, la pire
> chose qui puisse arriver ets une norme.
Une norme ? Tu veux dire que tous les mails ont le meme contenu ? Dans ce cas, c'est sur que le filtre tout court aura du mal, bayesien ou pas. Le concept de spam aura meme disparu.
> Je m'explique si un filtre devient connu et se repend
De quelle norme tu parles ?
> les spammeurs serot tout a fait capable de le contourner, soit en
> comprenant sa methode d'apprentissage dans le cas d'un filtre evolutif
Vision naive du truc. Je regarde comment ca marche et je sais tout comment il faut faire pour le contourner. On peut imaginer un spammeur etudiant les regles de spamassassin et s'amusant a les contourner mais ca lui prendrait vachement de temps. En revanche, contre un filtre evolutif, tu ne peux rien faire car le fonctionnement du filtre est particulier a chaque utilisateur. Son fonctionnement depend de tes mails normaux et de tes spams. Contre ca, un spammeur ne peut rien faire d'efficace. Il peut essayer de trouver des nouveaux trucs pour que ses mails soient moins reconnaissables mais des qu'ils seront digeres par ton filtre bayesien, il seront de nouvau bloques.
> soit en evitant soigneusement les mots clefs dans le cas de filtres
> statiques.
Tu ne peux pas eviter tous les mots-cles.
Cela dit, tu as raison sur un point, je pense que les spammeurs passent leur spam via des logiciels anti-spam sous windows. Ces derniers sont en general pathetiquement mauvais : les auteurs se sont dit, "on va faire comme pour les virus, on va faire une liste de tous les virii avec leur signatuer et on va bloquer tout ca". Donc ils ont fait des filtres statiques a la con avant de s'apercevoir que il se produisait plus de spam par jours qu'ils ne pouvaient generer de signature. Maintenant, ils en sont au niveau de reflexion de spamassassin (on va detecter les spams avec des regles a la con). Dans un ou deux ans, ils auront compris comment faire un filtre bayesien.
En attendant, mon bogofilter me bloque ses 300 spam par jours. Pas mal. Seul probleme, le fichier base de donnee est tres sollicite et sur un vieux disque dur, il semble que ca le fasse bcp souffir. Ca fait trois fois que le fichier se nique en un an. Probablement temps de changer de disque dur.
Apprendre un autre langage plus utile. C'est toujours utile a la fois professionellement, et aussi pour te donner du recul par rapport aux langages que tu connais. Perso, je recommande python. Simple, puissant avec plein de bibliotheques. Il y a quoi s'eclater et aider des projets sans etre une brute a mon avis.
Juste pour info, je developpe avec un copain un OS pour carte a puce a contact et sans-contact (comme Navigo): www.jayacard.org
Le code de l'OS est telechargeable dans des cartes de type flash (AVR) bien que le portage en lui-meme ne soit pas fini.
Il existe deja des modules PAM pour authentification par carte a puce, donc bientot, vous pourrez vous authentifier aupres de votre OS opensource avec un OS open source.
gcc sous cygwin est vraiment tres tres lent. Il dit qu'il a compile avec les lib windows donc il se pourrait que ce soit plus rapide que ce que je connais. Mais quand meme. Il faut compter un rapport 10 entre gcc et visual sous windows.
Pour gcc/windows vs gcc/unix, je dirai qu'il y a un rapport de 5.
Sinon, c'est connu que gcc est loin d'etre une foudre de guerre. Pas facile de supporter 350 architecture et d'avoir une equipe de dev reduite.
> Mais avec Glade et Qt Designer il faut tout de meme programmer en > dur les actions que vont avoir l'interface sur le reste du programme.
Sans blague ? Tu veux dire qu'il ne t'ecrit pas ton programme tout seul, tu as encore du code a ecrire ? Mon dieu, c'est atroce. Vivement l'IDE qui comprend tout seul ce que tu veux faire, et ou tu n'as meme pas besoin de toucher le clavier.
> XUL est plus puissant qu'un truc comme libglade car il va encore plus
> loin au niveau de la separation de l'interface et du programme.
> XUL a ete pense depuis le debut dans cette optique.
Ok, on peut faire des boutons et des machins en XUL. Mais on peut deja le faire avec Qt Desgner. Sous KDE, les menu d'une application et sa barre d'outils sont aussi definis par un fichier XML donc on est a mon avis au meme niveau que XUL.
Mais si tu crois que faire une interface grapnique, c'est faire un programme tu te trompes. Mon experience de programmation en Qt et de KDE, c'est que l'interface devient facile a coder. Il reste plus qu'a faire l'intelligence et pour ca, XUL ne peut pas t'aider.
De plus, si tu veux faire un programme evolue, tu as besoin d'avoir un controle tres precis de tes elements graphiques, et souvent, tu es amenu a en inventer. J'aimerai voir un KOffice, KDevelop ou khtml ecrit en XUL. Pour khtml, je sens venir le "mais il y a gecko justement". Et bien non, gecko, c'est un composant de mozilla ecrit un C avec les Netscape Portable Library, il n'apporte rien de plus en terme de facilite de develloppement par rapport a Qt. C'est juste que l'interface est plus facilement modifiable, mais c'est aussi le cas avec Qt si tu utilises des .ui charges dynamiquement.
Citation du "joy of XUL" sur le site de Mozilla, a propos du calendrier ecrit en XUL:
<<
the UI code is written in JavaScript, [...] the interaction logic worked with no effort. However, since the libical library is written in C, more significant effort was required to migrate this component to the other platforms.
>>
Donc en resume, c'est tout pareil que Qt, sauf que tu as du C et du javascript pour developper ton appli. L'avantage de Qt, c'est qu'au moins, la portabilite est _tres_ facile, contrairement a l'exemple donne ici.
Pour ce qui est de la legerete de XUL, firebird prend 27 mo de memoire en ce moment sur ma machine windows alors que opera qui fait la meme chose tourne autour de 12 Mo. Et Komodo, l'IDE d'ActiveState developpe en technos mozilla est un IDE les plus lents que j'ai jamais utilise (ceci dit, c'etait avant d'utiliser des IDE full java). Donc, je suis tres scriptique face a cet argument.
Tout a fait, c'est gdi, pas win32. Win32 est aussi une boite a outil graphique.
Pour dessinage, hum, je me suis un peu laisse aller.
Pour ce qui est de mozilla, en y resongeant, je crois que les controles graphiques (boutons, barre URL, ...) sont en fait en gtk et beneficient du theme gtk mais que mozilla a des themes pour autre chose: le jeu d'icones, la couleur du navigateur, ...
En reponse a Guillaume, pour l'instant, on a pas en effet de melange de deux toolkits dans une meme fenetre donc en effet, pas de GtkButton dans un QWidget. Cela dit, ca pourrait arriver dans le futur.
-> qq'un a prouve qu'on pouvait connecter des signaux Gtk a des slots Qt et l'inverse.
-> En utilisant QXEmbed, il est possible d'encastrer une fenetre X dans une autre. Tout widget Qt est une fenettre X, donc il est deja possible d'encastrer n'importe quel widget Qt dans une appli Gtk.
Donc les deux peuvent etre utilises en parallele sans trop de problemes.
> Les deux dessinent à coup d'appels à la XLib.
Oui et non. Oui parce sous X11, a un moment donne, pour dessiner sur un serveur X, il faut faire appel a la Xlib.
Non, car dans gtk comme dans Qt, il a deux niveau de dessinage. Le premier, c'est celui ou tu dessines sur le contexte graphique, x11 donc sous unix, cocoa sous macos, win32 sous windows.
Le second, c'est celui ou tu dessines les controles graphiques. Qt et Gtk passent tous deux par un moteur de theme. Ce n'est donc pas Qt ou Gtk qui dessinne, mais le moteur de theme a qui on dit "dessine moi un bouton enfonce, dessine moi une checkbox, ..."
A noter que sous windows XP, Qt utilise le moteur de theme de XP, et donc les applis Qt ont un look natif.
Ce qu'a fait le mec dans le cas qui nous occupe, c'est appeler le moteur de theme de Qt depuis le moteur de theme de Gtk. Il serait tout aussi facile (mais c'est un exercice different) d'utiliser le moteur de Gtk dans des applications Qt ou KDE.
En ce qui concerne Mozilla, je suis moins sur. Il me semble qu'il y a un moteur de theme Mozilla, qui utilise gtk pour dessiner sur l'ecran, sans utiliser les themes gtk proprement dit. Ca fait donc un troisieme moteur de theme.
A priori, avec un peu de volonte, il est possible de croiser des themes dans tous les sens, voire de developper un meta-moteur de theme qui serait utilise par tous les autres moteurs de themes.
C'est vrai que depuis que je suis sous gentoo, j'apprécie mon bi-pro 866 (qui commence a vieillir). Cela dit, un bi-pro ca fait trois ventilateurs donc plus de bruits. En plus le mien est mal refrigere et je peux pas compiler comme un bourrin.
Il reste quoi quand on enlève le néant ? Cela dit, cela aurait pu être le nez en moins, qui eut fait le bonheur de Cyranno.
Bon, pour ton information, néamoins s'écrit en un seul mot et il n'y a pas de nez ni de neant dedans. Cela dit, c'était joli.
[remarque à caractère général]
Je suis loin d'être un pro de la grammaire et de l'orthographe mais il y a quand même des contresens sémantiques qui sont faciles à éviter.
C'est bizarre tous ces gens qui savent configurer des linux mais n'arrivent pas a comprendre les règles les plus simples du français.
Pourquoi ne pas plutot chercher a regrouper toutes ces bonnes informations dans un seul site, lea par exemple. La dispersion (au sens geographique) de tout ce qui touche au libre n'est pas facile a gerer du point de vue utilisateur. Un coup sur freshmeat, un coup sur sourceforge, trois coup sur google, un coup sur linux-doc, un coup sur le tldp, on s'en sort plus quand on cherche de la doc.
Le terme "voler" est exagere car ce qu'on te vole, tu l'as toujours.
A mon avis, l'auteur du commentaire veut dire ici "utiliser sans aucune contrepartie financiere de notre cote". Ce qui est particulierement le cas dans l'utilisation d'une licence BSD.
Dans le cas d'une licence GPL, la precedente news parle des problemes de Kiss qui a bien vole du code ouvert. Le vol ici consiste a fermer le code :-)
J'en recois environ 300 par jour et une dizaine passent a travers bogofilter. Le leger probleme, c'est qu'au fur a mesure que le nombre de spam enregistre augmente, la base bogofilter augmente. J'en suis a environ 200 Mo. Mais bon, c'est pas cher paye, pour se debarasser de 300 spams par jour.
A noter que les suggestions plus haut, genre filtrer sur l'encodage des mails sont deja prises en compte par bogofilter mais avec plus de finesse que ce qu'on peut configurer a la main.
Le principe de bogofilter est assez simple mais efficace. Pour un spam ou ham, il stocke tous les mots dans sa base de donnee avec un petit calcul de relevance. Ensuite pour un mail recu, il prend le 10 ou 15 mots les plus importants et utilise ca pour estimer si le mail est un spam ou un ham en regardant l'occurence de ces mots dans ses deux bases de donnees. Le fait que le mail soit du html, ou que l'encodage soit particulier sera pris en compte comme un mot. Les dernieres versions sont vraiment tres efficaces.
Pour ce qui est du triage, j'avoue que je m'amuse bien aussi:
- d'abord, les mails sont recus sur le serveur d'un pote.
- je les classe en tant que spam ou non-spam avec procmail ou maintenant dropmail. Les spam sont mis dans une boites au lettre speciale
- seul les non-spams sont deposes dans ma boite pop3 normale.
- je vais les chercher ensuite avec kmail en pop3, ou je lis mon mail par webmail (parfois)
- pour les spams qui passent quand meme a travers le filtre, je les sauve via kmail dans un repertoire special (.spam) et une fois par jour, un cron va prendre tous les mails stockes dans ce repertoire et mettre a jour le filtre sur le serveur par un acces ssh
- pour savoir si j'ai des faux positifs, je me connecte une fois par jour en imap et je regarde les titres et regarde parfois un peu le contenu. J'ai encore jamais eu de faux positif.
Les avantages:
- je peux lire mon mail en pop3 ou en webmail sans etre emmerde par les spam
- j'efface les spam en me connectant par imap donc je ne les telecharge pas et ils ne remplissent pas mon folder poubelle de kmail
- le filtrage est tres efficace
Je pense que l'auteur a oublie quelques mythes auxquels beaucoup de temps croient dur comme fer dans le monde open source:
mythe: Un projet open source est intrinsequement plus securise qu'un projet proprietaire
realite: La securite d'un projet depend de beaucoup de parametres et l'open source n'est pas une baguette magique qui va rendre un projet securise. Rappelons que:
- beaucoup de projets open source sont codes par des debutants qui le font pour apprendre a programmer
- securiser un projet demande une experience de la securite et une comprehension des attaques qui ne s'aquiert pas en 5 minutes. Il faut un audit d'expert pour valider la securite d'un projet
- le source a beau etre ouvert, rien ne dit qu'il va etre audite par qui que ce soit
- les audits de securite sont ausssi possible dans des projet close source (mais c'est la boite qui developpe qui doit s'en charger)
- meme sans le source, on peut trouver plein de bugs de securite.
- le source permet aussi aux crackers de monter plus facilement une attaque.
En resume, ouvrir le source n'est qu'un parametre parmis beaucoup qui influe sur la securite d'un logiciel. Pour certains projets tres populaires, comme apache, le kernel linux ou nmap, on peut considerer que il ya eu des revues de code qui ont ameliore la securite. Pour mon_apppli_que_personne_connait, on peut rien dire.
mythe: Parce que un projet est open source, les bugs sont corriges tres rapidement
realite: certains projets open source qui ont une large communaute dediee corrigent des bugs tres rapidement (KDE, le kernel, Gnome, ...). Ceci est egalement le cas de certains projets close source. A l'inverse, des projets open-source cles sont tres lents a corriger des bugs ou a integrer des patchs: le kernel aussi, gcc, ...
L'auteur fait ici reference aux a priori qu'on a sur le code des autres. Tres souvent beaucoup de projets rejettent de code existant parce qu'il est "sale ou mal ecrit".
L'auteur ici inicite a regarder de plus pres l'option qui consiste a reutiliser du code et a ne pas s'arreter a quelques problemes initiaux.
Il a raison dans la mesure ou on a tendance a tres vite rejeter le code des autres quand on demarre un projet.
Cependant, la raison n'est pas qu'il est "sale ou mal ecrit" (bien que ca arrive) mais plutot que:
- developper son propre code, c'est plus fun
- comprendre le codes des autres, c'est difficile
- souvent, des problemes d'architectures rendent la reutilisation impossible
- coopererer n'est pas facile
- deux projets peuvent avoir un but different ou des imperatifs incompatibles.
Tout cela ne fait que conforter mon idee que au dela du politiquement correct "la FSF, c'est vraiment genial et RMS est super", la FSF n'a pas du tout une approche professionelle de quoi que ce soi. En dehors du message politique, j'ai pas souvenir d'avoir vu la FSF agir sur un sujet quelconque, contrairement a ses homologues francais ou europeens (dont je salue le travail (reprenez avec moi : "Contre l'EUCD, pour le droit d'auteur!" ))
On a l'impression d'une organisation dominee par des individus tres tetus et peu ouvert a l'argumentation ou a la collaboration. Comme RMS en fait.
Le jour ou j'ai vu sourceforge apparaitre, je me suis demande comment il se faisait que ce n'etait pas la FSF qui proposait une telle plateforme de developpement de logiciel GPL. En effet, c'etait l'outil parfait pour supporter son ideologie. Mais zon pas l'air d'etre tres fort cote realisation pratique.
Il a fallu qqch comme 5 ans pour voir apparaitre savannah et la ca par en couille. Je crois que je vais retourner a sourceforge pour mes futurs projets parce que non, j'ai pas envie de passer deux semaines sans acces CVS.
Tout a fait. Pour ma part, j'utilise source navigator et c'est du bon Tcl/Tck comme on en fait plus (et c'est pas moi qui vais le regretter :-) ). Il n'y a rien de mieux pour apprehender un code de 50 000 lignes qui ne t'appartient pas. Meme quand il t'appartient d'ailleurs :-) Source navigator aime tellement Tcl/Tck qu'il n'hesite pas a installer sa propre version a lui quand il s'installe!
Par exemple, regarde bien ta facture EDF. Il y a une ligne "TVA sur les taxes". Qui peut m'expliquer dans l'assistance la valeur ajoutee qui est taxee par cette TVA ?
> Par contre, la ou c'est fort (mais peut-etre que finalement cette
> separation existe aussi chez Qt et Gtk) c'est que le theme peut faire
> appel a une API pour dessiner les controles.
De fait, c'est aussi comme ca que fait Qt. Sous Windows XP et sous MacOs/X et il me semble sous KDE, Qt utilise l'API native de l'OS pour dessiner les controles (si tu choisis le theme qu'il faut) et tu obtiens une application parfaitement homogene a ton environnement.
Gtk a un mecanisme similaire, mais n'utilise l'API native sur MacOs/X ou sous Windows. Rien au niveau technique ne s'y oppose, il faut juste que qq'un le fasse mais cela ne semble pas des plateforme prioritaires pour les developpeurs de Gtk.
Et dans les prochaines news hot, qq'un est en train de bosser sur un theme Gtk qui en fait utiliserait le theme courant KDE. Ca permettrait aux applications Gtk de s'integrer proprement dans KDE.
Oui, j'ai manque de precision. En fait, c'est BlackAdder, de TheKompnay, qui coute 500$ . Il vient avec PyQt . C'est ce que j'utilise au boulot et ca marche nickel linux/windows. J'ai pas encore lance BlackAdder mais ca doit surement etre bien :-)
Sinon, le PyQt vendu par riverbank-computing est en effet complementaire d'une licence Qt, ce qui le rend tres onereux.
Le prix des licences Qt est tout a fait abordable dans une entreprise, compte tenu de la qualtie du toolkit. Perso, j'ai vu une licence a 1500$ passer dans une start-up ou les gens n'etait pas payes.
Sinon, il y a PyQt, nettement moins cher puisque pour 500$, on a toutes les plateformes accessibles.
Cette seperation ne sera effective que dans OpenOffice 2, ou ils utiliseront un langage generique (VCL il me semble) qui sera implemente dans l'un ou l'autre toolkit.
<<
Cette modularité très cartésienne est dans la suite logique de l'évolution du logiciel libre et elle est un gage d'évolutivité d'OpenOffice.org.
>>
Certe, mais elle est un poids tres lourd au niveau technique. Toute fonctionnalite doit etre codee dans un premier temps au niveau de l'abstraction (la partie document du modele document/vue), puis au niveau graphique pour le rendu, donc dans ce cas en VCL, puis transposee via VCL dans un GUI natif (Qt, KDE, Windows, ...). Dans le cas ou une fonctionnalite manque a VCL, elle doit etre recree dans chacun des ports.
Tout ce processus est extremement lourd a maintenir et a developper. KOffice, a l'oppose, en s'appuyant a fond sur des technologies choisies et directes, fait un bien meilleur boulot. Si on compare le nombre d'annees hommes investies sur chacun des projets, KOffice doit representer le 1/10 de OpenOffice.
Quand on songe que StarOffice etait une boite allemande, on se demande vraiment pourquoi ils n'ont pas choisi Qt des le depart. Ils ont du commencer leur truc avant 1993. C'est dommage quand meme parce que avec Qt, il se serait epargnes bien du boulot.
[^] # Re: Bill Gates veut signer l'arrêt de mort du spam
Posté par Philippe F (site web personnel) . En réponse à la dépêche Bill Gates veut signer l'arrêt de mort du spam. Évalué à 1.
Faux. Les spammeurs sont tres intelligents et tres ruses. J'ai deja recu des messages avec des adresses de copains, de collegues, et meme de rms@gnu.org avec du spam ou des virus (au choix).
Je pense qu'ils ont recolte ca sur des mailing lists ou sur des forums de discussion.
Par ailleurs, je suis abonne a une dizaine de mailinst-list et je recois environ 100 mails par jour. Je ne me vois pas mettre tout ce beau monde en while-liste, surtout que ca change tout le temps.
Pour moi le filtrage bayesien (bogofilter en l'occurence) reste la solution vraiment performante et peu couteuse.
[^] # Re: Bill Gates veut signer l'arrêt de mort du spam
Posté par Philippe F (site web personnel) . En réponse à la dépêche Bill Gates veut signer l'arrêt de mort du spam. Évalué à 2.
En revanche, un filtre bayesien bloque ca "finger in the nose" puisqu'il ne va regarder que les mots qui sont particulierement significatifs sur le mail. Difficile d'envoyer un mail sur le viagra sans utiliser les mots "viagra" ou "performance sexuelle". Le filtre bayesien verra ces mots et leur accordera plus d'importance que les "saldhjadhcxnzweqiy" ajoutes pour tromper l'ennemi.
> En ce qui concerne les filtres, et notamment les filtres Baysiens, la pire
> chose qui puisse arriver ets une norme.
Une norme ? Tu veux dire que tous les mails ont le meme contenu ? Dans ce cas, c'est sur que le filtre tout court aura du mal, bayesien ou pas. Le concept de spam aura meme disparu.
> Je m'explique si un filtre devient connu et se repend
De quelle norme tu parles ?
> les spammeurs serot tout a fait capable de le contourner, soit en
> comprenant sa methode d'apprentissage dans le cas d'un filtre evolutif
Vision naive du truc. Je regarde comment ca marche et je sais tout comment il faut faire pour le contourner. On peut imaginer un spammeur etudiant les regles de spamassassin et s'amusant a les contourner mais ca lui prendrait vachement de temps. En revanche, contre un filtre evolutif, tu ne peux rien faire car le fonctionnement du filtre est particulier a chaque utilisateur. Son fonctionnement depend de tes mails normaux et de tes spams. Contre ca, un spammeur ne peut rien faire d'efficace. Il peut essayer de trouver des nouveaux trucs pour que ses mails soient moins reconnaissables mais des qu'ils seront digeres par ton filtre bayesien, il seront de nouvau bloques.
> soit en evitant soigneusement les mots clefs dans le cas de filtres
> statiques.
Tu ne peux pas eviter tous les mots-cles.
Cela dit, tu as raison sur un point, je pense que les spammeurs passent leur spam via des logiciels anti-spam sous windows. Ces derniers sont en general pathetiquement mauvais : les auteurs se sont dit, "on va faire comme pour les virus, on va faire une liste de tous les virii avec leur signatuer et on va bloquer tout ca". Donc ils ont fait des filtres statiques a la con avant de s'apercevoir que il se produisait plus de spam par jours qu'ils ne pouvaient generer de signature. Maintenant, ils en sont au niveau de reflexion de spamassassin (on va detecter les spams avec des regles a la con). Dans un ou deux ans, ils auront compris comment faire un filtre bayesien.
En attendant, mon bogofilter me bloque ses 300 spam par jours. Pas mal. Seul probleme, le fichier base de donnee est tres sollicite et sur un vieux disque dur, il semble que ca le fasse bcp souffir. Ca fait trois fois que le fichier se nique en un an. Probablement temps de changer de disque dur.
[^] # Re: probleme de langage
Posté par Philippe F (site web personnel) . En réponse à la dépêche Un cri de désespoir du développeur d'un projet Open Source.. Évalué à 2.
# Re: Authentification par clé USB: pam_usb
Posté par Philippe F (site web personnel) . En réponse à la dépêche Authentification par clé USB : pam_usb. Évalué à 6.
Le code de l'OS est telechargeable dans des cartes de type flash (AVR) bien que le portage en lui-meme ne soit pas fini.
Il existe deja des modules PAM pour authentification par carte a puce, donc bientot, vous pourrez vous authentifier aupres de votre OS opensource avec un OS open source.
[^] # Re: Comparaison de neuf langages sur un micro-benchmark
Posté par Philippe F (site web personnel) . En réponse à la dépêche Comparaison de neuf langages sur un micro-benchmark. Évalué à 2.
[^] # Re: Comparaison de neuf langages sur un micro-benchmark
Posté par Philippe F (site web personnel) . En réponse à la dépêche Comparaison de neuf langages sur un micro-benchmark. Évalué à 5.
Pour gcc/windows vs gcc/unix, je dirai qu'il y a un rapport de 5.
Sinon, c'est connu que gcc est loin d'etre une foudre de guerre. Pas facile de supporter 350 architecture et d'avoir une equipe de dev reduite.
[^] # Re: Vivement qu'on arrete de s'enfoncer
Posté par Philippe F (site web personnel) . En réponse à la dépêche GTK-Qt-OpenOffice.org: un pas de plus vers une meilleure intégration. Évalué à 2.
Sans blague ? Tu veux dire qu'il ne t'ecrit pas ton programme tout seul, tu as encore du code a ecrire ? Mon dieu, c'est atroce. Vivement l'IDE qui comprend tout seul ce que tu veux faire, et ou tu n'as meme pas besoin de toucher le clavier.
> XUL est plus puissant qu'un truc comme libglade car il va encore plus
> loin au niveau de la separation de l'interface et du programme.
> XUL a ete pense depuis le debut dans cette optique.
Ok, on peut faire des boutons et des machins en XUL. Mais on peut deja le faire avec Qt Desgner. Sous KDE, les menu d'une application et sa barre d'outils sont aussi definis par un fichier XML donc on est a mon avis au meme niveau que XUL.
Mais si tu crois que faire une interface grapnique, c'est faire un programme tu te trompes. Mon experience de programmation en Qt et de KDE, c'est que l'interface devient facile a coder. Il reste plus qu'a faire l'intelligence et pour ca, XUL ne peut pas t'aider.
De plus, si tu veux faire un programme evolue, tu as besoin d'avoir un controle tres precis de tes elements graphiques, et souvent, tu es amenu a en inventer. J'aimerai voir un KOffice, KDevelop ou khtml ecrit en XUL. Pour khtml, je sens venir le "mais il y a gecko justement". Et bien non, gecko, c'est un composant de mozilla ecrit un C avec les Netscape Portable Library, il n'apporte rien de plus en terme de facilite de develloppement par rapport a Qt. C'est juste que l'interface est plus facilement modifiable, mais c'est aussi le cas avec Qt si tu utilises des .ui charges dynamiquement.
Citation du "joy of XUL" sur le site de Mozilla, a propos du calendrier ecrit en XUL:
<<
the UI code is written in JavaScript, [...] the interaction logic worked with no effort. However, since the libical library is written in C, more significant effort was required to migrate this component to the other platforms.
>>
Donc en resume, c'est tout pareil que Qt, sauf que tu as du C et du javascript pour developper ton appli. L'avantage de Qt, c'est qu'au moins, la portabilite est _tres_ facile, contrairement a l'exemple donne ici.
Pour ce qui est de la legerete de XUL, firebird prend 27 mo de memoire en ce moment sur ma machine windows alors que opera qui fait la meme chose tourne autour de 12 Mo. Et Komodo, l'IDE d'ActiveState developpe en technos mozilla est un IDE les plus lents que j'ai jamais utilise (ceci dit, c'etait avant d'utiliser des IDE full java). Donc, je suis tres scriptique face a cet argument.
Pour resumer le fond de ma pensee: XUL, c'est bien pour des applications relativement simples, qui peuvent tout aussi bien etre ecrites en Visual Basic, PyQt voire Kommander (http://quanta.sourceforge.net/main2.php?snapfile=snap02(...)).
Quand tu dois coder des choses complexes, tu as besoin d'un vrai toolkit, et c'est la ou tu apprecie la puissance d'un vrai truc comme Qt ou Gtk.
[^] # Re: GTK-Qt-OpenOffice.org: un pas de plus vers une meilleure intégration
Posté par Philippe F (site web personnel) . En réponse à la dépêche GTK-Qt-OpenOffice.org: un pas de plus vers une meilleure intégration. Évalué à 1.
Pour dessinage, hum, je me suis un peu laisse aller.
Pour ce qui est de mozilla, en y resongeant, je crois que les controles graphiques (boutons, barre URL, ...) sont en fait en gtk et beneficient du theme gtk mais que mozilla a des themes pour autre chose: le jeu d'icones, la couleur du navigateur, ...
En reponse a Guillaume, pour l'instant, on a pas en effet de melange de deux toolkits dans une meme fenetre donc en effet, pas de GtkButton dans un QWidget. Cela dit, ca pourrait arriver dans le futur.
-> qq'un a prouve qu'on pouvait connecter des signaux Gtk a des slots Qt et l'inverse.
-> En utilisant QXEmbed, il est possible d'encastrer une fenetre X dans une autre. Tout widget Qt est une fenettre X, donc il est deja possible d'encastrer n'importe quel widget Qt dans une appli Gtk.
[^] # Re: GTK-Qt-OpenOffice.org: un pas de plus vers une meilleure intégration
Posté par Philippe F (site web personnel) . En réponse à la dépêche GTK-Qt-OpenOffice.org: un pas de plus vers une meilleure intégration. Évalué à 4.
C'est tout a fait vrai.
> l'un ne peut pas utiliser l'autre
C'est tout a fait faux.
cf la derniere release de sodipodi qui integre des dialogues KDE dans une appli gtk.
L'etape d'apres est deja prevue:
http://webcvs.kde.org/cgi-bin/cvsweb.cgi/kdenonbeta/qtgtk/README?re(...)
Donc les deux peuvent etre utilises en parallele sans trop de problemes.
> Les deux dessinent à coup d'appels à la XLib.
Oui et non. Oui parce sous X11, a un moment donne, pour dessiner sur un serveur X, il faut faire appel a la Xlib.
Non, car dans gtk comme dans Qt, il a deux niveau de dessinage. Le premier, c'est celui ou tu dessines sur le contexte graphique, x11 donc sous unix, cocoa sous macos, win32 sous windows.
Le second, c'est celui ou tu dessines les controles graphiques. Qt et Gtk passent tous deux par un moteur de theme. Ce n'est donc pas Qt ou Gtk qui dessinne, mais le moteur de theme a qui on dit "dessine moi un bouton enfonce, dessine moi une checkbox, ..."
A noter que sous windows XP, Qt utilise le moteur de theme de XP, et donc les applis Qt ont un look natif.
Ce qu'a fait le mec dans le cas qui nous occupe, c'est appeler le moteur de theme de Qt depuis le moteur de theme de Gtk. Il serait tout aussi facile (mais c'est un exercice different) d'utiliser le moteur de Gtk dans des applications Qt ou KDE.
En ce qui concerne Mozilla, je suis moins sur. Il me semble qu'il y a un moteur de theme Mozilla, qui utilise gtk pour dessiner sur l'ecran, sans utiliser les themes gtk proprement dit. Ca fait donc un troisieme moteur de theme.
A priori, avec un peu de volonte, il est possible de croiser des themes dans tous les sens, voire de developper un meta-moteur de theme qui serait utilise par tous les autres moteurs de themes.
[^] # Re: Les processeurs 64 bits
Posté par Philippe F (site web personnel) . En réponse au sondage Les processeurs 64 bits. Évalué à 1.
[^] # Re: Les processeurs 64 bits
Posté par Philippe F (site web personnel) . En réponse au sondage Les processeurs 64 bits. Évalué à 2.
Bon, pour ton information, néamoins s'écrit en un seul mot et il n'y a pas de nez ni de neant dedans. Cela dit, c'était joli.
[remarque à caractère général]
Je suis loin d'être un pro de la grammaire et de l'orthographe mais il y a quand même des contresens sémantiques qui sont faciles à éviter.
C'est bizarre tous ces gens qui savent configurer des linux mais n'arrivent pas a comprendre les règles les plus simples du français.
# Re: Xenux.net - site documentaire
Posté par Philippe F (site web personnel) . En réponse à la dépêche Xenux.net - site documentaire. Évalué à 3.
[^] # Re: Voix sur IP : Teamspeak
Posté par Philippe F (site web personnel) . En réponse à la dépêche Voix sur IP : Teamspeak. Évalué à 3.
A mon avis, l'auteur du commentaire veut dire ici "utiliser sans aucune contrepartie financiere de notre cote". Ce qui est particulierement le cas dans l'utilisation d'une licence BSD.
Dans le cas d'une licence GPL, la precedente news parle des problemes de Kiss qui a bien vole du code ouvert. Le vol ici consiste a fermer le code :-)
Donc oui, on peut voler du code ouvert.
[^] # Re: Combien de spams recevez-vous par jour ?
Posté par Philippe F (site web personnel) . En réponse au sondage Combien de spams recevez-vous par jour ?. Évalué à 8.
A noter que les suggestions plus haut, genre filtrer sur l'encodage des mails sont deja prises en compte par bogofilter mais avec plus de finesse que ce qu'on peut configurer a la main.
Le principe de bogofilter est assez simple mais efficace. Pour un spam ou ham, il stocke tous les mots dans sa base de donnee avec un petit calcul de relevance. Ensuite pour un mail recu, il prend le 10 ou 15 mots les plus importants et utilise ca pour estimer si le mail est un spam ou un ham en regardant l'occurence de ces mots dans ses deux bases de donnees. Le fait que le mail soit du html, ou que l'encodage soit particulier sera pris en compte comme un mot. Les dernieres versions sont vraiment tres efficaces.
Pour ce qui est du triage, j'avoue que je m'amuse bien aussi:
- d'abord, les mails sont recus sur le serveur d'un pote.
- je les classe en tant que spam ou non-spam avec procmail ou maintenant dropmail. Les spam sont mis dans une boites au lettre speciale
- seul les non-spams sont deposes dans ma boite pop3 normale.
- je vais les chercher ensuite avec kmail en pop3, ou je lis mon mail par webmail (parfois)
- pour les spams qui passent quand meme a travers le filtre, je les sauve via kmail dans un repertoire special (.spam) et une fois par jour, un cron va prendre tous les mails stockes dans ce repertoire et mettre a jour le filtre sur le serveur par un acces ssh
- pour savoir si j'ai des faux positifs, je me connecte une fois par jour en imap et je regarde les titres et regarde parfois un peu le contenu. J'ai encore jamais eu de faux positif.
Les avantages:
- je peux lire mon mail en pop3 ou en webmail sans etre emmerde par les spam
- j'efface les spam en me connectant par imap donc je ne les telecharge pas et ils ne remplissent pas mon folder poubelle de kmail
- le filtrage est tres efficace
[^] # Re: Les mythes du développement Open Source
Posté par Philippe F (site web personnel) . En réponse à la dépêche Les mythes du développement Open Source. Évalué à 5.
mythe: Un projet open source est intrinsequement plus securise qu'un projet proprietaire
realite: La securite d'un projet depend de beaucoup de parametres et l'open source n'est pas une baguette magique qui va rendre un projet securise. Rappelons que:
- beaucoup de projets open source sont codes par des debutants qui le font pour apprendre a programmer
- securiser un projet demande une experience de la securite et une comprehension des attaques qui ne s'aquiert pas en 5 minutes. Il faut un audit d'expert pour valider la securite d'un projet
- le source a beau etre ouvert, rien ne dit qu'il va etre audite par qui que ce soit
- les audits de securite sont ausssi possible dans des projet close source (mais c'est la boite qui developpe qui doit s'en charger)
- meme sans le source, on peut trouver plein de bugs de securite.
- le source permet aussi aux crackers de monter plus facilement une attaque.
En resume, ouvrir le source n'est qu'un parametre parmis beaucoup qui influe sur la securite d'un logiciel. Pour certains projets tres populaires, comme apache, le kernel linux ou nmap, on peut considerer que il ya eu des revues de code qui ont ameliore la securite. Pour mon_apppli_que_personne_connait, on peut rien dire.
mythe: Parce que un projet est open source, les bugs sont corriges tres rapidement
realite: certains projets open source qui ont une large communaute dediee corrigent des bugs tres rapidement (KDE, le kernel, Gnome, ...). Ceci est egalement le cas de certains projets close source. A l'inverse, des projets open-source cles sont tres lents a corriger des bugs ou a integrer des patchs: le kernel aussi, gcc, ...
[^] # Re: Les mythes du développement Open Source
Posté par Philippe F (site web personnel) . En réponse à la dépêche Les mythes du développement Open Source. Évalué à 4.
L'auteur ici inicite a regarder de plus pres l'option qui consiste a reutiliser du code et a ne pas s'arreter a quelques problemes initiaux.
Il a raison dans la mesure ou on a tendance a tres vite rejeter le code des autres quand on demarre un projet.
Cependant, la raison n'est pas qu'il est "sale ou mal ecrit" (bien que ca arrive) mais plutot que:
- developper son propre code, c'est plus fun
- comprendre le codes des autres, c'est difficile
- souvent, des problemes d'architectures rendent la reutilisation impossible
- coopererer n'est pas facile
- deux projets peuvent avoir un but different ou des imperatifs incompatibles.
[^] # Re: Y a-t-il un futur pour Savannah ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Y a-t-il un futur pour Savannah ?. Évalué à 1.
[^] # Re: Y a-t-il un futur pour Savannah ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Y a-t-il un futur pour Savannah ?. Évalué à 3.
On a l'impression d'une organisation dominee par des individus tres tetus et peu ouvert a l'argumentation ou a la collaboration. Comme RMS en fait.
Le jour ou j'ai vu sourceforge apparaitre, je me suis demande comment il se faisait que ce n'etait pas la FSF qui proposait une telle plateforme de developpement de logiciel GPL. En effet, c'etait l'outil parfait pour supporter son ideologie. Mais zon pas l'air d'etre tres fort cote realisation pratique.
Il a fallu qqch comme 5 ans pour voir apparaitre savannah et la ca par en couille. Je crois que je vais retourner a sourceforge pour mes futurs projets parce que non, j'ai pas envie de passer deux semaines sans acces CVS.
[^] # Re: Kernel 2.6.0 annoncé stable
Posté par Philippe F (site web personnel) . En réponse à la dépêche Le noyau Linux 2.6.0 annoncé stable. Évalué à 5.
[^] # Re: L'UFC-Que Choisir passe à l'action contre les CD protégés.
Posté par Philippe F (site web personnel) . En réponse à la dépêche L'UFC-Que Choisir passe à l'action contre les CD protégés.. Évalué à 1.
Par exemple, regarde bien ta facture EDF. Il y a une ligne "TVA sur les taxes". Qui peut m'expliquer dans l'assistance la valeur ajoutee qui est taxee par cette TVA ?
[^] # Re: Lancement d'un projet officiel d'intègration de d'OpenOffice.org à KDE
Posté par Philippe F (site web personnel) . En réponse à la dépêche Lancement d'un projet officiel d'intégration d'OpenOffice.org à KDE. Évalué à 3.
> separation existe aussi chez Qt et Gtk) c'est que le theme peut faire
> appel a une API pour dessiner les controles.
De fait, c'est aussi comme ca que fait Qt. Sous Windows XP et sous MacOs/X et il me semble sous KDE, Qt utilise l'API native de l'OS pour dessiner les controles (si tu choisis le theme qu'il faut) et tu obtiens une application parfaitement homogene a ton environnement.
Pour voir a quoi ce ressemble d'un point de vue dev:
http://doc.trolltech.com/3.2/qstyle.html(...)
Gtk a un mecanisme similaire, mais n'utilise l'API native sur MacOs/X ou sous Windows. Rien au niveau technique ne s'y oppose, il faut juste que qq'un le fasse mais cela ne semble pas des plateforme prioritaires pour les developpeurs de Gtk.
Et dans les prochaines news hot, qq'un est en train de bosser sur un theme Gtk qui en fait utiliserait le theme courant KDE. Ca permettrait aux applications Gtk de s'integrer proprement dans KDE.
[^] # Re: Lancement d'un projet officiel d'intègration de d'OpenOffice.org à KDE
Posté par Philippe F (site web personnel) . En réponse à la dépêche Lancement d'un projet officiel d'intégration d'OpenOffice.org à KDE. Évalué à 2.
Sinon, le PyQt vendu par riverbank-computing est en effet complementaire d'une licence Qt, ce qui le rend tres onereux.
[^] # Re: Lancement d'un projet officiel d'intègration de d'OpenOffice.org à KDE
Posté par Philippe F (site web personnel) . En réponse à la dépêche Lancement d'un projet officiel d'intégration d'OpenOffice.org à KDE. Évalué à 3.
[^] # Re: Lancement d'un projet officiel d'intègration de d'OpenOffice.org à KDE
Posté par Philippe F (site web personnel) . En réponse à la dépêche Lancement d'un projet officiel d'intégration d'OpenOffice.org à KDE. Évalué à 4.
Sinon, il y a PyQt, nettement moins cher puisque pour 500$, on a toutes les plateformes accessibles.
[^] # Re: Lancement d'un projet officiel d'intègration de d'OpenOffice.org à KDE
Posté par Philippe F (site web personnel) . En réponse à la dépêche Lancement d'un projet officiel d'intégration d'OpenOffice.org à KDE. Évalué à 10.
<<
Cette modularité très cartésienne est dans la suite logique de l'évolution du logiciel libre et elle est un gage d'évolutivité d'OpenOffice.org.
>>
Certe, mais elle est un poids tres lourd au niveau technique. Toute fonctionnalite doit etre codee dans un premier temps au niveau de l'abstraction (la partie document du modele document/vue), puis au niveau graphique pour le rendu, donc dans ce cas en VCL, puis transposee via VCL dans un GUI natif (Qt, KDE, Windows, ...). Dans le cas ou une fonctionnalite manque a VCL, elle doit etre recree dans chacun des ports.
Tout ce processus est extremement lourd a maintenir et a developper. KOffice, a l'oppose, en s'appuyant a fond sur des technologies choisies et directes, fait un bien meilleur boulot. Si on compare le nombre d'annees hommes investies sur chacun des projets, KOffice doit representer le 1/10 de OpenOffice.
Quand on songe que StarOffice etait une boite allemande, on se demande vraiment pourquoi ils n'ont pas choisi Qt des le depart. Ils ont du commencer leur truc avant 1993. C'est dommage quand meme parce que avec Qt, il se serait epargnes bien du boulot.