Philippe F a écrit 2225 commentaires

En fait, c'est pas tres clair. Dans le lien vers Qt2, il s'agit bien d'un port natif. Dans le lien vers Qt3, il est plutot sous-entendu un port via cygwin.

Je suis passionne par Trolltech et Qt et je vais te dire pourquoi: je trouve que leur produit est excellent, a la fois du cote technique, du cote fun, et du cote documentation. 1. Ils ont permis de gommer les defauts du C++ en fournissant un jeu de classe de tres bonne qualite et des mecanismes pratiques. 2. J'ai beaucoup de plaisir a programmer avec Qt car je suis tres efficace 3. Grace au fait que leur toolkit soit completement portable, on a vraiment pas l'impression de s'isoler quand on developpe avec Qt. On sait qu'on pourra toujours si besoin est porter son application sous d'autres environnements 4. Ce sont des ardents supporteurs du libre 5. Grace a la qualite de leur toolkit, sous windows, des gens vont se convertir peu a peu a Linux car une fois que tu commences a utiliser Qt sous windows, tu fais un pas vers le logiciel libre. << Qt est passé sous GPL car GTK commençais a faire une grosse concurrence. C'est le marché qui a poussé Trolltech a faire ça car une bonne partie de la communauté était "remonté" >> Faux. Ca fait deux interviews que je fais avec le PDG de Trolltech et a chaque fois il confirme: tout le monde a Trolltech a une profonde foi dans le logiciel libre. Simplement ils avaient peur en mettant Qt sous GPL qu'un fork se produise et qu'une boite fasse de l'argent sur leur dos. Mais mettre Qt sous GPL a toujours fait partie de leurs objectifs et Gtk n'a jamais rien change a ca. Pour ce qui est de la concurrence de Gtk, il confirme aussi: pas de concurrence. En gros, soit les gens veulent faire du C et ils choisissent Gtk. Soit ils veulent faire du C++ et ils choisissent Qt (le binding Gtk/C++ est une franche rigolage). Il est pratiquement impossible de convertir au C++ quelqu'un qui aime faire du C et vice versa, donc il n'y a pas de concurrence. De plus, perso, je trouve que Gtk2 commence a etre potable, mais Gtk1 avait vraiment un train de retard par rapport a Qt. Pas de gestion de l'unicode, pas police anti-aliasee, bcp de widgets nettement inferieurs a ceux de Qt. Je vois pas trop comment ca pourrait faire de la concurrence. Dernier point, comme Qt est payant pour un produit commercial (close source) et Gtk gratuit, il ne se font pas directement de la concurrence. Soit la boite est pret a payer et prend Qt, soit elle ne veut pas payer et prend Gtk. A ma connaissance, il n'y a pas de moyens officiels d'avoir une licence commerciale Gtk vendue avec un support, contrairement a Qt.

cf aussi le projet qui m'a l'air interessant: http://www.iidea.pl/~js/qkw/ Par contre, je suis decu, le projet ne parle que de porter Qt3 sous cygwin/XFree pour windows. J'esperais un port natif. Ca veut dire que celui qui veut faire tourner un logiciel ecrit avec ce Qt devra deja avoir installe cygwin et XFree. Reserve aux plus motives donc. Sinon, je vous ai promis une interview du PDG de Trolltech il y a quelques semaines. Elle a ete faite en anglais il y a deux jours, au telephone. Je cherche de l'aide pour retranscrire les 45 minutes de questions/reponses. Ceux qui participeront auront l'interview en exclusivite. Si ca vous tente: phil at freehackers dot org

Ces nombreuses boites continueront a acheter des licences. D'apres le CEO de Trolltech, elles achetent deja leur licence unix mais pour des outils internes. Je ne pense pas que ca fasse tant de concurrence que ca a Trolltech, mais ca nous permettra d'avoir plus de logiciels libres sous windows. Ou bien de developper a la fois au boulot (sous windows, boulot de merde!) et a la maison. Ou bien ca permettra aux gens qui bossent sous windows d'utilise des outils logiciels libres plus souvent, meme s'ils le font deja le soir a la maison (je parle encore de moi).

Deux facon de s'en debarasser:
1. cramer la puce
2. desactiver la puce de facon soft (dans le cas d'un tag a memoire un d'un tag a puce)


Pb de 1: cramer la puce peut etre difficile, peut mettre le feu a l'emballage mais ca reste la solution la plus fiable

pb de 2: desactive la puce, oui, mais doit-on l'autoriser pour tout le monde ? Des petits malins pourraient s'amuser a desactiver en serie tout un jeu d'article et foutre la merde. Dans ce cas on pourrait imaginer de proteger l'article avec un code. Mais ca veut dire que si jamais la caissiere "oublie" de te le desactiver, tu ne pourras pas le desactiver toi-meme.

J'en profite quand meme pour rajouter un lien vers un projet qui developpe des modules open source permettant d'acceder a des lecteurs de cartes a contact (style votre carte bancaire) et sans-contact (style votre carte navigo). Ce projet developpe aussi un OS OpenSource pour carte sans-contact:

http://www.sf.net/projects/jayacard(...)

Mouai, si c'est des cartes a memoires, il y a quand meme des protections avec un bout de crypto donc ca ne se casse pas comme ca.

Ont-ils mis l'options hyper over super pratique qui consiste a memoriser le .config dans /usr/proc ?

Si non, c'est bien dommage parcque j'ai nique mon .config la semaine derniere et que je vais me taper deux a trois jours de reboot avant de le refaire marcher!

La RFID est en effet un enjeu important, a la fois du point de vue de la vie privee et du point de vue de ce qu'elle apporte.

Pour tout ce qui est suivi, ca remplace tres avantageusement le code barre. Ca coute plus cher mais ca permet de faire un suivi "a distance". C'est super pratique pour par exemple, faire tres rapidement l'inventaire d'un magasin ou d'un camion. Donc les industriels sont tres interesses par cette techno dans une optique d'amelioration de la gestion des stocks.

Du point de vue de la vie privee en revanche, c'est vrai que c'est effrayant. On achete un article, qu'est-ce qui nous dit qu'on est pas suivi a la trace.

D'un point de vue pratique cepedant, je pense qu'il est plus simple de mettre dans un tag RFID le type de produit, tout comme ca se fait avec le code barre, que un identifiant unique par produit. Sinon, la base de donnee derriere, elle va souffrir.

Il faut voir que derriere le mot RFID se cachent trois technos potentielles:
- un tag stupide: il renvoit un no de serie des que tu le mets dans un champs. Pas de possiblites d'ecriture. La, on est au niveau du code barre. Souvent, on a pas tellement besoin de plus

- un tag a memoire: on peut lire dedans et ecrire moyennant une authentification. D'un point de vue securutaire, l'authentification n'est pas tres bien protegee dans la mesure ou un labo avec quelques outils tres perfectionnes pourra sans trop de probleme lire le contenu de la memoire et ecrire dedans. Je ne pense pas cepdndant que cela soit a la portee du particulier.

- un processeur complet avec ROM, EEPROM et RAM, entierement securise, qui fait tourner un systeme d'exploitation lui-meme securise. Ca c'est le truc incraquable. A priori, comme ca coute plus cher a implanter, c'est reserve a des marches ou il y a une tres forte demande en securite, qui peut justifier un cout plus eleve du tag.

Dans les supermarches, on va utiliser soit le tag stupide, soit le tag a memoire.

Remarque: pour ceux qui ont une carte de fidelite et qui s'inquiete des tags RFID, vous devriez commencer par jeter votre carte de fidelite. Quel meilleur moyen en effet que de suivre un consommateur ?

J'ai plein d'autres choses a dire mais je prefere discuter directement sur la mailing-list de Loic, sur le projet RFID / Savannah

Je souscrit a 200% a cet avis. WinCVS n'est qu'une excuse pour dire que CVS a un client graphique sous windows, mais ce client ne simplifie en rien l'utilisation de CVS, plutot le contraire. L'interface en ligne de commande de CVS est bien plus simple a utiliser. Tortoise au contraire, est simple et intuitif. Tu regardes tes repertoires, tu vois tout de suite les fichiers qui ont besoin de ton attention (marques en rouge). Quand tu fais un click-droit dessus, il te propose uniquement les actions qui sont intelligentes par rapport a l'etat du fichier, ce qui donne une impression de facilite incroyable. Tu cliques sur un fichier modifie, il te propose soit un diff, soit de le committe. Sur un fichier non encore dans la base, il te propose de l'ajouter ou de l'ignorer. Je regrette que le monde linux n'est pas un aussi bon client CVS mais j'envisage un jour de modifier Cervisia pour obtenir ce genre de fonctionnalite.

Surtout que si c'set pour attaquer joe, qui a ecrit joe_my_software_with_qt a deux balles, ils vont pas gagner beaucoup d'argent.

Version serveur simple pour laquelle il est precise sur le site qu'elle n'est pas maintenue et pas developpee parce que les developpeurs ont d'autres priorites en ce moment.

Perso, j'ai pas trop envie d'installer Apache + webdav et j'aime bien l'installation minimaliste de CVS. Dommage.

Ou bien boson:
http://boson.eu.org(...)

Comment ca, a l'epoque ?

Les recommendations Gnu, en general, on peut se torcher avec. cf par exemple les coding standard du kernel linux.

En ce cas precis, c'est une recommendation de RMS. Je trouve ca abuser de dire que c'est Gnu, a moins de penser que toute la FSF leche les bottes de RMS. En bon chercheur du MIT, RMS est tres familier avec les langages fonctionnels, pense qu'ils sont tres adaptes a plein de chose et souhaite leur diffusion.

D'un certain point de vue, je le comprends: c'est vrai que les langages fonctionnels ont bcp d'interet et permettent de faire plein de chose plus facilement et avec moins de bugs. Le probleme, c'est qu'ils sont plus durs a aborder car ils demandent un autre mode de pensee, et souvent une syntaxe qui n'a rien a voir avec des langages plus courants (C, C++, Java, Python, Perl, ...)

Alors que le but d'un langage de script est de pouvoir etendre facilement l'application, on se retrouve avec Guile avec un truc qui est plus complique a aborder que l'application elle-meme. Le programmeur bourrin aura plus vite fait de patcher en C que d'apprendre Guile pour faire plaisir a RMS. D'ou ma remarque intiale, on peut se torcher avec cette recommendation.

Si on veut rendre une application scriptable, il faut que le langage de script soit tres facile a aborder car le but est que des non experts puissent scripter (sinon, ils patcheraient directement). Un bon choix est donc un langage simple facile a apprendre. Un excellent choix est un langage que les gens connaissent deja par un autre contexte. D'ou le choix de VB dans le monde Microsoft. Javascript est aussi un bon choix puisque des millions de developpeurs web savent faire du Javascript (mais pas moi). D'apres un pote, avec mozilla, tu peux te coder une appli complete en javascript. Maintenant, tu pourras aussi scripter les applis Qt. Python me parait un bon choix aussi, car il est simple a apprendre, souple et facile a etendre. Mais embarquer python, c'est quand meme un peu lourd. Dans la categorie des poids leger, j'ai entendu bcp de bien de lua (http://www.lua.org/(...)).

Sous windows, il est rapide. Un copain m'avait demontre qu'il avait un rendu plus rapide que mozilla sur certains pages. Sauf que comme il prend un tiers de la memoire de mozilla (mouaarf), il est beaucoup plus _leger_.

Perso, je l'aime bien pour ca. Leger. simple, pas de prise de tete. Mozilla me gonfle avec son composer+mailer+im+browser+evier.

C'est pour faire des demos ou pour vendre a un client ? De toute facon, t'es sous windows, tu paye. Tu as paye ton OS, ton environnement de Dev, ta suite office, ton decompresseur, pourquoi tu ne payerais pas ta bibliotheque graphique ?

Le message n'est pas personnel, c'est juste pour rappeler que sous windows, payer est normal.

- libsig est un debat recurrent sur qt-interest. Disons qu'il y a des avantages et des inconvenients. Les templates sont quand meme une structure tres lourde du C++ qui est difficile a apprendre. Cf aussi:
http://www.kuro5hin.org/story/2003/5/26/22429/7674(...)

Les templates posent aussi des limitations si tu veux faire des plugins, puisque pour compiler ton plugin, tu as besoins de .h

Les signaux/slot etant bases sur des string, il est tres facile de les ajouter dynamiquement, ou de les binder dans un autre langage.

- Qt sous windows: il existe une version d'evaluation avec la toute derniere version de Qt donc je ne vois pas trop le probleme.

- KDE sous Qt. Mathias Ettrich avait propose qqch sur kde-core-devel mais c'est un peu tombe a l'eau. Il y a un petit probleme de dependance circulaire a resoudre.

- Qt base sur du C++ moderne: je suppose qu'il faut comprendre STL + template. Malheureusement, cette modernite a aussi l'inconvenient de ne pas etre bien portable et surtout, d'etre compliquee a aborder. J'avais lu qu'environ 10% des programmeurs C++ savent utiliser les template. Parmis ces 10%, 1% savent vraiment ce qu'ils font. (mavie.com: je connais le C++ depuis pratiquement 10 ans et je viens juste de rentrer dans les 10%)

- binding: je ne peux que recommander PyQt, excellent maintenu et pas cher sous windows.

Parce qu'ils perdraient beaucoup de sous ? Au mepris de toute licence, les utilisateurs se jetteraient sur la version windows pour coder des trucs non GPL.

Je demanderai en tout cas, mais il me semble que je l'avais deja fait dans ma derniere interview.

Il y a un tres gros filtres au niveau des bugs de rendu vers les developpeurs. Ils en avaient marre de perdre du temps sur les bugs "le site XY ne marche pas".

En revanche, si tu es capable de reproduire des bugs avec des morceaux de html tu seras plus que le bienvenu sur bugs.kde.org

OpenSource: the power is in your hand.

Tout a fait. C'est pas un post de 5 mots qui va me rassurer sur l'avenir de gentoo. Un peu comme XFree, c'est pas l'ouverture d'un forum qui va tout changer a la gestion de XFree.

Gentoo, c'est une tres bonne distrib mais du point de vue technique, je suis surpris que des choses n'aient pas encore ete faites, qui pourtant pourrait permettre de beaucoup mieux gerer la distribution.

1. distribuer gentoo par bittorrent ou p2p
2. utiliser un outil efficace en bande passante pour mettre a jour l'arbre portage. rsync est bien, mais avec une connaissance precise de ce qui doit etre synchornise, on peut arriver a des algorithmes plus efficaces
3. assigner un mainteneurs a chaque ebuild, comme pour debian
4. meilleure gestion de la proposition de nouveaux ebuild.

Quand on regarde, toutes ces solutions sont lies a la mise a contribution d'une communaute, qui ne va pas de pair avec l'autocratisme dont Daniel semble faire preuve.

Je comprends mieux avec ce post pourquoi ces choses ne se produisent pas. Et ca me rappelle avec fierte que je contribue a un projet pour lequel l'esprit communautaire double d'un tres fort esprit pratique a toujours prevalu: KDE.

Ouai, on sera deja tous morts ce jour-la.

cf l'article qui parle de leurs Bilan Financier. Ils peuvent tenir 15 ans sans rentrer un sous juste en tresorerie!

Tu crois pas que tu vas chercher un peu loin la, juste pour essayer de prouver que Apple a tort ? De nos jours, je ne connais pas de geek sans connection internet. Et qui d'autre qu'un geek pourrait s'amuser a modifier des logiciels sous APSL ?

J'ai profite pour rappeler que KDE a une interface parlante pour quelques programmes, geree par festival. D'apres ce qu'on m'a dit, ca marche surtout pour de l'anglais. Mais bon, si un "parleur" francais existe en open source ou meme close/source sous linux, je suis sur qu'on pourra l'interface.

http://accessibility.kde.org/(...)

Ce qui resume bien le schmilblick. En gros c'est un mec qui s'est fait chier a rendre l'outil plus convivial mais ca n'est pas du tout de base. C'est bien le probleme!