Philippe F a écrit 2203 commentaires

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.

Si tu te contredis:

"qu'on leur demande de contribuer, comme c'est possible, plus personne. "

Or le monsieur te montre que Suse contribue au logiciel libre.

Pour ma part, je prefere 100 fois avoir plus de contributeurs sur des elements qui posent des problemes en logiciel libre comme l'affichage ou le son que savoir que Yast est libre mais que c'est la seule contribution qu'aura jamais cette boite au logiciel libre.

Refuser d'utliiser Suse parce que Yast n'est pas libre, (entre autres, si je ne m'abuse Suse contient aussi les drivers nvidia, acroread, netscape, un ou deux jeux close source), c'est ton droit.

Mettre cote a cote Suse et SCO en revanche, je trouve ca douteux. Suse a prouve son engagement dans le logiciel libre. SCO au contraire, vient de prouver son engagement contre le logiciel libre et pour le fric.

Je trouve egalement exagere ton qualificatif de "logiciel proprietaire" un logiciel dont tu as les sources, que tu peux modifier et redistribuer a condition de ne pas le vendre.

Desole, mais pour moi le libre a une definition plus large que "compatible avec la GPL".

Il serait interessant de connaitre les budgets alloues par les differentes distributions commerciales au developpement de logiciel libre pour la communaute (yast et drakbidule ne rentrent pas dans cette categorie). A vue de nez, je dirai que c'est :
1. Suse (XFree, alsa, kernel, KDE)
2. Redhat (rien sur XFRee, rien sur KDE, bcp sur Gnome et Gtk, kernel)
3. Mandrake (un peu de KDE, plex86, frozen bobble, un peu de kernel)

Ca en dit long sur OpenOffice. Tous les gens que je connais qui ont regarde le code ont eu le meme genre de diagnostic: "Chez OO, ils ont reinventees la roue au moins une cinquantaine de fois, mais en plus en la faisant carre".

Avec la roue, ils ont aussi fait le char a boeufs, le bullduzer, la moissoneuse batteuse (tous ces outils m'evoquent allegerement OpenOffice).

OpenOffice, sa grande qualite, c'est que ca marche (et j'en suis tres content). En dehors de ca, leur methode de developpement (on reecrit tout nous-meme) fait qu'il est tres difficile a integrer dans quoi que ce soit.

Et puis c'est drolement lourd. Fini les arguments "Avec linux, tu peux utliser de vieux matos." J'ai un bi-pro avec un 1G de ram. Si je lance une compile en parallele d'OO, il devient inutilisable.

Moi c'est pour introduire subrepticement des failles de securite pour pouvoir attaquer ensuite les ordinateurs des autres qui utilisent des logiciels libres (gniark gniark gniark).

Rigolez pas, c'est ce que m'a sorti mon chef de service il y a un mois. Il soupconne les developpeurs du libre de chercher a introduire des chevaux de troyes, sous pretexte qu'il ne comprend par leurs motivations. Il m'a montre un bug tordu de mozilla qui peut effectivement etre utilise comme faille en disant : "tu vois, qu'est ce qui me prouve que le mec n'a pas mis cette faille expres" !

Non, ce sont des entreprises tout a fait classique. D'ailleurs ma boite l'a fait il y a quelques temps. On gagne pas beaucoup parce que ca prend enormement de temps en management. On avait chiffre environ 2 mois-hommes de management pour un projet de plus de 3 mois. En plus, il faut etre hyper rigoureux dans les specs, ecrire beaucoup de mails pour bien preciser ce que tu veux dire, passer beaucoup de temps en correction de bug. Et les mecs te font des super estimations ("quoi 2 mois pour faire ca ? Attend, je le torche en une semaine!").

Ce qui est pas mal, c'est que ca permet d'externaliser les developpements hyper chiants, genre portage de l'application bidule d'il y a 15 ans qui est encore en windows 3.1 en appli moderne.

Un autre probleme, c'est qu'on flippe et qu'on ne veut leur envoyer aucune information qui puisse les aider trop a comprendre notre techno. Ils ne bossent donc que sur des projets non sensibles.

Ca pose aussi des problemes internes. Il y a eu un plan social, donc on a vire des francais mais on a conserve l'equipe de l'Inde, parce que ce n'est pas sur le meme budget (c'est pas la meme ligne dans le bilan comptable qu'on presente aux actionnaires). Difficile a justifier aupres de tes employes.

De toute facon, il ne faut pas se leurrer. La terre est ronde. Dans moins de 10 ans, beaucoup de ces pays auront rattrape leur retard technologique est la difference de cout sera beaucoup plus faible.

La solution delocaliser en province me parait beaucoup plus saine, a la fois pour le tissu economique francais et d'un point de vue pratique.