Philippe F a écrit 2214 commentaires

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!

La doc de qmake est pas trop mal, mais l'outil lui-meme a encore des limitations:
- maintenant qu'il est en C++, il est tres difficile a etendre
- tres grave: il ne gere pas la dependance d'un executable sur une bibliotheque statique, alors qu'un Makefile et que Visual serait capable de le gerer. J'ai discute avec un mec de Trolltech, il ne prevoit pas de le faire.
- il limite a un fichier.pro par repertoire, ce qui est chiant. typiquement, si tu as un executable qui depend de bibliotheques statiques, c'est ingerable parce que il te faut un template subdir dans le repertoire principal, puis un template staticlib pour les sous repertoires, mais il ne te reste plus de template pour ton executable. Ou bien tu dois le mettre dans un sous-repertoire mais le ne se recontruit pas quand tu changes les bibliotheques statiques.

Pour l'instant j'utilise tmake qui est aussi pas tres bon pour gerer les dependances. Il y a plein de fichiers .h dont la modification n'entraine pas une recompilation alors qu'elle devrait.

En lisant les commentaires, je vois que Java a rate son coup. Si j'ecrit un programme consequent en java, disons autour des 20000 lignes, genre un navigateur, j'ai combien de chance qu'il soit effectivement portable entre toutes les jvm ? Et si on ajoutes les versions, ca donne quoi ?

Tu as mal saisi ce que je voulais dire. Si je tape:

./configure --with-qt-lib=/opt/my_qt

configure va ignorer silentieusement mon option parce que j'ai oublie le s (--with-qt-libs) et utiliser un qt standard. Si je ne remonte pas 25 page en arriere pour verifier qu'il a le pris le bon qt, je n'aurai aucun indice d'une erreur. Et apres, je passerai trois jour a essayer de comprendre pourquoi mes programmes crashent quand je genere une exception.

Des programmes plus intelligents, comme il me semble le configure de mplayer (ou est-ce xine ?) t'affichent a la fin ce qu'ils ont detecte d'important sur ton systeme.

Moi j'ai eu tous les problemes de l'auteur plus quelques autres. Genre, tu tapes:
./configure --with-qt-lib=/opt/my_qt

et configure te dit qu'il ne trouve pas qt!! Comment se fait-il ? Tu verifies ton disque dur, tu refais un ./configure --help pour etre sur. C'est qu'au bout de 10 minutes que tu t'apercois que la seule option utile de ./configure etait --with-qt-libs (le s, vous le voyez) et pas --with-qt-lib. Et me dite pas que c'est specifique a qt/kde, on en voit partout. La vraie questions, c'est pourquoi configure ne m'a-t-il pas dit que je m'etais plante dans le nom d'une option ? Ca doit etre trop user-friendly!

Pire, si j'ai un qt standard mais que je voulais utiliser mon qt a moi avec mes options a moi (de /opt/my_qt), le configure ne se plantera meme pas et moi je ne realiserai pas qu'il n'a pas pris mon qt.

Pour l'instant, j'utilise tmake dans mes projets. Super simple a utiliser, pas parfait au niveau de la generation mais bien quand meme. Et surtout, il a une fonctionnalite que je ne retrouve pas dans les autres make-like: il permet de generer des projets pour Microsoft Visual C++. Ca va pas plaire a certains mais c'est un besoin pour moi.

Pour gerer ce genre de problematique, a savoir editer le source d'un utilisateur avec des reglages tab/space differents, j'ai ecrit un petit utilitaire qui detecte automatiquement l'indentation utilisee dans un fichier:

http://www.vim.org/scripts/script.php?script_id=513(...)

Depuis, plus de problemes. Je suis pret a le reecrire en C si une forte pression s'exerce.

> Python et les blocs:
Moi je trouve ca genial parce que ca permet une syntaxe beaucoup plus legere. Python n'utilise que deux elements syntaxiques: les parentheses et l'indentation. Ca donne des programmes tres lisisbles et tres rapide a taper. Le C/C++ se tapes des accolades, des parentheses, des point-virgules. C'est relativement lourd. Mais ca fait tellement longtemps qu'on en fait qu'on ne les voit plus.


> ++

Le ++ est une construction pratique du C qui permet de faires des programmes plus courts du genre de while(i--) { ... }. Mais c'est completement a l'oppose de la philosophie de python (clarte, simplicite) car il y a deux effets caches: une incrementation delayee et un retour de valeur. Tu peux te rabattre sur le +=.

Au contraire de ce que tu dis, un interpreteur est tres tres partique. Pour travailler souvent en python, je peux te dire que j'apprecie. Les gros avantages que j'y vois:
- meme si la recompilation est rapide, quand il n'y en a pas, c'est encore plus rapide
- ca permet de tester vite fait des petites construction. Chez moi j'ai un repertoire pour faire ce genre de tests
- en python en tout cas, ca me permet de verifier rapidement des trucs sans en passer par le necessaire printf. Typiquement, quand j'ecris des regexps, je passe 10 minutes a les valider dans l'interpreteur.
- une des lourdeurs du C++, c'est la gestion du Makefile. Je ne sais pas comment fonctionne cet interpreteur mais s'il arrive a s'en affranchir, il rendre certainement le developpement plus rapide.
- quand on debuge, c'est pratique d'avoir une session interactive pour valider le comportement de certaines fonction. gdb est tres limite de ce cote la.

A mon avis, ca ne peut que faciliter l'apprentissage du C++ et c'est tout a fait complementaire d'un compilateur en phase finale. Cela dit, le C++ a une syntaxe et une grammaire tres compliquee qui doit le rendre lourd a utiliser sous un interpreteur. Je lui prefere des langages a la syntaxe plus legere: python!!!!

Depuis le temps, il a du changer de distribution. Enfin, j'espere. Moi je le verrai bien avec une gentoo ou avec une slack.

<< Le plus extrémiste de tous est justement le fondateur de la communauté du logiciel libre... >>

Fondateur, il ne faudrait pas exagerer. Il a formalise une pratique (l'echange de logiciels avec leurs sources) sous forme d'une licence, il a ecrit un programme sous cette licence et il a organise le developpement d'un systeme d'exploitation qui serait completemenmt libre (et il s'est completement plante sur l'OS).

Donc oui, on doit pas mal a Papa Stallman. Mais faut pas croire qu'avant lui, il n'y avait rien et que sans lui, il n'y aurai rien. ESR aime a rappeler qu'il a developpe sons premier logiciel libre plusieurs annees avant que Riri ne fasse sa pub pour Gnu et Emacs.

Avant Riri, les gens s'echangeait deja des programmes avec leurs sources. C'etait le temps beni ou on en avait rien a foutre d'une quelconque licence puisqu'on etait "entre potes".

<< Enfin, pour ta gouverne, il n'y a pas deux bords, mais au moins 4 >>

Je trouve cette position extremement reductrice. Si tu frequenetes un peu la communaute du logiciel libre, tu t'apercois qu'il y a a peu pres autant de bords que d'individus. Seule les sectes et le entrerprises arrivent a faire croire que beaucoup d'individus peuvent tous etre d'accord.

Tres bien mais pas aussi souple que Qt ou GTK puisque la communication se fait pas evenements et pas par signaux/slot. On peut aussi noter que WxWindow n'est pas aussi sur niveau portabilite que Qt. Certains ports ont du retard sur les autres, il y a des bugs qui sont specifiques a certains ports, ...

Avec Qt, tu as vraiment une architecture unifiee. Comme ils attaquent les systeme graphique a un tres bas niveau, ils gerent eux-meme 80% de l'affichage et ont donc tres tres peu de bugs qui sont specifiques a la plate-forme. Je dirai meme qu'ils ont tres tres peu de bugs en tout.

Qt, c'est aussi une boite derriere qui se fait de la thune, et une 60aine de developpeurs payes a plein temps pour l'ameliorer en permanence. Ca explique beaucoup d'avantages sur WxWindows.

Si tu travailles uniquement avec PyQt (et je te le recommande), tu peux acheter une version commerciale de PyQt a Phil Thompson qui est _beaucoup_ moins cher que Qt: 1500F. Certe il faut raquer, mais apres tu peux vendre ton programme GPL sous windows. Apres tout, sous windows, les moutons sont habitues a payer.