Philippe F a écrit 2182 commentaires

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.

On est pas obliger d'attaquer, simplement de leur rappeler leurs obligations. Ces gentils monsieur utilisent quand meme gratuitement le travail de milliers de contributeurs. Ce ne me parait pas exagere de leur demander de respecter la _seule_ contrainte du logiciel libre, distribuer les sources.

Moi ce qui m'arrive parfois, c'est non pas que le terminal se bloque completement, mais simplement qu'il n'affiche les lignes que apres les avoir taper. Genre s'il etait en mode 'echo off'.

Vous savez d'ou ca vient et comment on peut corriger ca ?

A noter que ces projets sont a des annees lumieres en avance de ce qui se fait sous Windows.

Les "On Screen Reader" sous windows sont bases sur des bidouilles liees directement a l'interface de rendu (gdi) et ne beneficient donc pas de l'acces aux widgets (boutons menus, ...) ce qui fait qu'ils sont tres tres bas niveaux.

Pour les rendre utilisable, les constructeurs s'interfacent directement au niveau de l'application. C'est a dire que si tu n'utilises (sous windows) ni excel, ni word, ni IE, tu l'as dans le c..

Au contraire, ce qui a ete fait sous Unix par l'equipe de Sun est bien propre et generique avec une tres bonne integration dans le bureau et un acces intelligent aux widgets. C'est tres tres prometteur.

Du cote de KDE, on va se brancher sur ATK, le backend accessbilite de Gnome. Beaucoup de boulot et peu de developpeurs, donc on a besoin d'aide.

KOffice est capable de relire du format OpenOffice sans trop de probleme. Ils essayent de migrer vers du format OpenOffice en natif mais ca prend pas mal de temps.

Ce que je voudrai, c'est l'inverse. Que mozilla s'integre enfin proprement au bureau. Par exemple: - qu'il partage sa base de donnee mime avec le bureau (vraiment, a quoi ca sert a mozilla d'avoir une base separee ?) - qu'il utilise les themes du bureau - qu'il permette de partager (non pas d'exporter/importer) ses bookmarks entre avec galeon et konqueror - qu'il utilise des dialogues du bureau, comme le file dialog ou le print dialogue. Bref, le probleme de mozilla comme celui d'OpenOffice, pour moi, c'est que ce sont des bons softs mais qu'ils ne sont pas assez integres. C'est penible par exemple de se retrouver avec un dialogue d'impression minable quand on sait ce que peut fournir KDE!

Ouai, bonobo sert a faire communiquer tous les composants du systeme ensemble, de facon etroite. Quoi comme meilleur exemple que le bonobo ? :-) (c'est veridique)

Moi je ne comprends pas cet entetement a se plaindre de Yast qui est juste non revendable mais qui respecte quand meme la majorite des libertes defendues par notre bon RMS. Si la suse ne vous plait pas, ne l'utilisez pas.

En revanche, ne vous genez pas pour utiliser tous les jours ce que Suse vous a apporte: des meilleurs drivers X, des meilleurs drivers sons, ...

Vous pronez l'exemple Mandrake, c'est ca ? Tout en GPL, et cessation de paiement au bout de 5 ans ? Si Suse s'en sort mieux financierement, c'est peut-etre aussi parce que il est plus difficile de la copier. Et franchement, sur le long terme, on a vraiment interet a ce que des boites survivent parce que ce qu'elles apportent au logiciel libre est enorme. Et non, je ne pense pas a Yast ou a drakConf.