> Une bonne utilisation de Corba permettrait en théorie d'utiliser des objets KDE dans Gnome
> et vice-versa.
C'est ce que croient beaucoup de gens. Ce serait un rien plus facile avec Corba des deux cotes, mais ca ne resoud pas les problemes de fond pour avoir l'interoperabilite: des api et des fonctionnalites communes. A cote de ca, Corba ou pas Corba, c'est un detail. Pour l'instant, Gnome et KDE ont des trucs similaires, mais creer un pont entre les deux releve de la gagure, meme s'ils utilisaient tous les deux Corba.
En plus, KDE utilisait mico et Gnome utilisait Orbit. Je ne sais pas pourquoi mais ca posait de problemes. Le fait que l'un soit en C et l'autre en C++ avait aussi des consequences.
Et puis qui aurait developpe ce pont ? Probablement personne! Ca ne serait qu'un "cool hack" mais pas tres util. KDE a deja tous les composants dont il a besoin. Gnome n'en a pas beaucoup, mais il a presque les meme que KDE, donc il ne va pas aller chercher ceux de KDE.
Donc choisir Corba, ca aurait ete alourdir le desktop que pour des situation hypothetiques (composnants distribues, pont vers Bonobo) qui en pratique ne sont pas utilisees.
Bon, et en prime, je te donne une info: il est tout a fait possible d'avoir un composant Gnome sous KDE et vice versa. Il faut connaitre un peu Bonobo et connaitre un peu KDE (KPart et XPart) mais techniquement, il n'y a pas de problemes. Simplement, personne n'a envie de le faire pour l'instant.
> "we were afraid that if we GPLed Qt, someone with more development muscle would create a
> hostile fork of Qt and, in a sense, take over our only product"
>
> Doit-on comprendre qu'ils avaient peur que quelqu'un fasse mieux qu'eux et s'approprie le
> produit?
Ils avaient peur que quelqu'un s'approprie le produit oui. Je peux meme te citer un nom: RedHat.
Mais RedHat est parti pour Gtk. Harmony n'a jamais decolle. A partir de Qt2, ils n'ont pas arrete de progresser et il est devenu clair que personne ne maitriserait Qt mieux qu'eux. Donc ils sont passes a la GPL.
En revanche, je ne pense pas qu'ils aient jamais eu peur que quelqu'un fasse un meilleur Qt que le leur. Ils sont trop forts. Quand Eirik dit qu'il prend uniquement les meilleurs, il dit vrai.
Rappelons que meme sans etre GPL, Qt respectait deja les trois libertes du logiciel que garantit par la GPL. Donc la GPL, ca n'a ete que politique. Ce n'est pas l'interview (qui date d'un mois alors que Qt est en GPL depuis plus d'un an) qui y a change qqch.
Tu peux aussi utiliser un fichier pour gerer ton swap. Je crois que la page de man interessante est swapon. Et si je me souviens bien, ils disent que les performances sont pratiquement identiques a celle d'une partition swap.
J'y etais l'an dernier et j'en ai garde un super souvenir. Ca permet d'une part d'entendre parler de plein de projets, d'autre part, de discuter directement avec des auteurs de projets que vous aimez bien et de decouvrir des tas d'autres gens.
J'ai appris qqs trucs sur Hurd, j'ai decouvert Mosix, j'ai vu RasterMan (100% comme je l'imaginais) et decouvert Evas.
Il y a un "release schedule" (http://developer.kde.org/development-versions/kde-2.2.1-release-pla(...)) pour chaque release de KDE, qui specifie notamment quand la release doit etre officiellement announcee. Ceci afin:
- de permettre des tests dans la derniere semaine (on a vu des bugs decouverts et corriges le jeudi)
- donner du temps aux packageurs
- permettre aux miroirs de se mettre a jour
- ne pas mettre le ftp de KDE sur les genoux
- eviter d'avoir des gens qui se plaignent qu'il n'y a pas tous les package.
Donc ce serait bien que les moderateurs tiennent compte de ceci avant d'approuver une news (ce que font les moderateurs de slashdot).
.
.
.
Mea Culpa, il semble que d'une part le "release schedule" pour KDE 2.2.1 n'ait pas ete mis a jour, d'autre part, que la nouvelle date de release annoncee sur dot.kde.org soit du 17 septembre, ce qui rend la news valide.
Mais ca me semble louche que ca ne soit pas annonce sur dot.kde.org.
> - bricolage macroique, bof, pas tellement, en tout cas l'utilisateur de la librairie (i.e. le développeur) ne le vois pratiquement pas ;
bricolage macrotique ? Les seuls macros que le developpeur utilise dans Qt, c'est:
"slots" -> rien
"signal" -> "protected"
Q_OBJECT -> <on n'a pas besoin de le savoir>
Ca ressemble pas a un bricolage. Et tres vite, on a l'impression que les mot-cles "slots" et "signal" font partie du langage C++.
Ces mot-cles ne sont d'ailleurs utilises que dans le .h et pas dynamiquement. C'est leger et surtout extremement pratique d'avoir tout de declare dans le .h
Cet argument me parait donc encore plus contestable que les autres.
<troll-zone>
Alors que quand je touche a du code Gtk, je tremble a chaque fois que je vois une macro de cast, en imaginant tout ce qu'elle doit faire derriere. Sans compter les "return_if_fail" et autres bidouilles.
Les gens qui disent preferer Gtk parce que "Qt, c'est pas du C++!" me font doucement rigoler. Si un jour je veux absoluement faire du C, une chose est sure, je ne me tournerai pas vers Gtk car ca ne ressemble plus a du C. Ce ressemble plutot un clone hybride de C++.
Le top de VC++, c'est quand tu debuges et que tu tombes sur une ligne ou tu vois ton bug, qui sera executee dans trois instructions.
Tu corriges ton bug et tu appuies sur F10 (next). Et la, le miracle se produit devant tes yeux:
VC++ recompile automatiquement le fichier que tu viens de modifier, l'integre dans le nouvel executable, le charge en memoire, se transpose au meme endroit, de sorte que tu peux continuer a debugger tranquillement, comme si tu le code sans bug n'avait pas toujours ete la. C'est comme si tu travaillais avec un langage interprete.
Trop fort!!! Ca m'a scie. Dans 10 ans, peut-etre que gcc fera ca. Peut-etre.
Evidemment, ca ne doit pas pouvoir marcher dans tous les cas, mais pour l'instant, j'ai pas eu de problemes.
Je ne m'en suis toujours pas remis tellement c'est pratique.
> trouve au contraire que l'utilisation des GTK_WIDGET et autres macros rendent le code beaucoup plus lisibles
La je ne vois pas pourquoi ? Parce que c'est en majuscule ? En C++, tu peux aussi nommer tes classes en majuscule a ca deviendra aussi lisible!
> En GTK on sait à chaque fois exactement à quel niveau de l'héritage on se situe, et de quelle manière on utilise l'objet en question.
Je ne saisis pas comment le fait d'utiliser une macro te permet de savoir a quel niveau d'heritage tu es.
Et puis en C++, tu fais ca avec un simple cast, pas de soucis, le compilateur travaille pour toi. Pas besoin de "return_if_fail" et autres ajouts pas du tout leger de gtk.
En dehors du moc, qui est un peu surprenant au debut, je n'ai trouve aucun defaut a Qt depuis 2 ans que je l'utilise intensement.
Il me semble d'ailleurs que l'utilisation d'espaces de noms plus intensifs est prevu pour Qt3.
Et le modele memoire de Qt est vraiment tres pratique (a cote de celui de Gtk). C'est presque aussi agreable de coder en c++ avec Qt qu'en python. Alors en PyQt, je vous dis pas!!
> GNU/Linux, parce que KDE, il pourrait très bien
> marcher avec un autre noyau !
Voire avec un autres OS, donc exit GNU. Pour info, KDE fonctionne tres bien sans un seul programme Gnu, cf la page de toutes les plate-formes et compilos suppportes (page que je ne retrouve plus, mea culpa).
> 100% des newbies Windozeurs découvrant Linux vont cliquer sur "Windoze" !
Oui, ils vont faire ca au debut. Mais il ne faut pas sous-estimer l'utilisateur. Beaucoup sont curieux. Une fois que l'utilisateur sera familier avec son environnement, qu'il n'aura plus peur des popup et qu'il arrivera a placer ses fenetres correctement, il va regarder ce qu'il peut faire pour amerliorer le look'n feel. Et la, il va gouter la configurabilite de KDE.
C'est ce qui ressort de l'installation de KDE dans la ville de Largo (cf dot.kde.org). Les utilisateurs apprecient de pouvoir bidouiller leur bureau. Mais il ne faut pas les forcer tout de suite.
Donc finalement, KDE a choisi la bonne demarche, comme toujours :-))
> il est relativement rare de trouver qqn de 20-25 ans ayant competence technique associees a
> d'autres competences plus administratives et/ou relationnelles.
Competences qui s'acquierent justement en general avec l'experience. Entre un mec de 25 ans et un mec de 40 ans, s'il y a une chose dont on peut etre sur, c'est que l'un a plus d'experience que l'autre. Experience en quoi et competences precises demandent ensuite a etre approfondi, evidemment.
Si tu as 25 ans et que tu as bosse 3 ans dans ta vie, toujours dans le meme job, dans une petite boite et que t'as fait un projet logiciel libre dans ta vie, c'est redhibitoire.
Si t'as 25 ans, que t'as cree une boite qui a marche, que tu as eu plusieurs boulots, que tu as deja manage une equipe ou fait du commercial, que tu as deja bosse dans une grosse administration, que t'as deja gere 5 projets logiciel libre dont un avec succes ou il y avait une equipe, ca passera a mon avis tres bien.
Bien sur, tout ca n'est que mon avis subjectif et personnel. Mais si je devais choisir un candidat, ce qui ferait la difference, ce n'est pas l'age mais l'experience. Donc faut pas seulement etre expert Gnu/Linux/Fsf/Kde/Freebsd/Gpl/python/perl pour etre expert. Faut avoir vecu.
Gecko dans Konqueror, c'etait surtout une "preuve de concept". Comme KDE s'est fait tres critique a l'abandon de Corba, quelques developpeurs ont voulu montrer qu'il etait possible, malgre l'abandon de Corba, de faire des choses tres puissantes avec l'architecture de composants de KDE, notamment d'utiliser des programmes qui ne dependent pas de KDE.
La technologie utilisee pour encastrer Gecko eu lieu de KHtml s'appelle XPart. Elle ne depend que de DCOP et de X (et de Qt de facon sous-jacente). DCOP etant completement independant de KDE, cela veut dire que cette technologie peut permettre d'encastrer n'importe quel programme dans n'importe quel autre a condition d'avoir sous la main les bibliotheque Qt, DCOP et X (cas relativement courant sur un systeme).
Notamment, il est possible de faire un pont entre les composants KDE et Bonobo par l'intermediaire de XPart. Si quelqu'un a le courage de s'y mettre...
Qt a toujours ete Open Source avec une licence qui permettait une libre utilisation, des modifs et la redistribution de modifs sour forme de patch avec l'original.
Dire que Qt n'etait pas libre, je trouve ca un peu rapide. Qt n'etait pas GPL. Mais qui decide de ce qui est libre ? RMS ? Les trois libertes fondamentales du logiciel decrites par RMS etaient notamment respectees.
En ce qui me concerne, un logiciel peut etre libre sans etre necessairement sous GPL.
> À nouveau le troc de la commodité contre la
> liberté. C'est la grande différence avec le projet Gnome.
A mon sens, la grande difference entre KDE et Gnome, c'est que KDE ne troc pas la qualite et la facilite de developpement pour quoi que ce soit, contrairement a Gnome.
On peut d'ailleurs dire la meme chose de Linux par rapport a Hurd. Hurd ne troc pas la liberte, mais on a un truc 30% moins rapide que Linux, qui a peu de chance de decoller. Mais oui, le "message passing", c'est mieux. Mais en attendant, Linux est la, et Hurd a plus de 5 ans de retard par rapport a sa date initiale de release.
KDE, tout comme Linux, a un role d'evangelisation du logiciel libre bien plus efficace que Hurd ou Gnome, alors que ceux-ci sont "plus" dans l'esprit du libre. Mais moins bien. Alors que KDE et Linux, ils sont la et ca marche.
Ben les mecs de KDE te diront que c'est de la faute de gcc et ceux de GCC que c'est c'est celle de KDE qui est mal ecrit. :-)
La press-release precise que KDE ne compile pas avec gcc 3. gcc 3 a encore trop de bug et casse la compatilbilite binaire. Il faudra attendre KDE 3.0 (janvier 2002) pour utiliser gcc 3.0
> Mais une librairie permet de mettre en place une
> norme ou un protocole. Celui-ci valorise
> l'informatique parce qu'elle federe des acteurs
> et on peut donc (esperer) en retirer des revenus.
Donc tu passes 5 ans a developper a perte un logiciel en GPL et ensuite, grace a la place que tu as acquise sur le marche, tu commence a faire du revenu. C'est completement irrealiste! Une boite ne peut pas vivre 5 ans sans gagner de l'argent. Le probleme d'une societe, ce n'est pas d'acquerir une position de leader, c'est de gagner de l'argent. Le plus tot et le maximum, c'est toujours le mieux.
Tu parles de "normes" et de "references". M'est avis que tu es un peu trop admin system. Qt c'est une boite a outil. Tu l'utilise ou tu l'utilise pas, il n'y a pas de "normes" a mettre en place.
> La GPL a une autre utilité: Permettre de démarrer un projet à bas coût. Si ce projet
> devient mur, il faut en recolter les fruits et ceci signifie le considérer - en partie - comme
> une librairie sur laquelle d'autres batiront.
Developper un projet en GPL ou sous une licence commerciale a le meme cout.
Si Suse disparait, on aura une preuve concrete de la non rentabilite economique du logiciel libre. Ou tout au moins de certains modeles, mais pour les journalistes et les investisseurs, l'amalgame sera vite fait.
D'un cote on a des gens comme ESR qui se battent pour dire "mais si, le logiciel libre est un modele economique reel, regardez toutes ces boites qui vivent avec". Et de l'autres des gens qui sont completements indifferents a la disparation de societe basee sur du logiciel libre.
Ca veut dire que demain, si tu veux monter une boite pour vendre du service LL et que tu as besoin d'investisseurs, ils vont te dire "regardez, Suse s'est cassee la gueule, on ne peut pas faire d'argent avec le logiciel libre".
Si Suse se casse la gueule, ca veut dire aussi que beaucoup de societes qui ont investi dans Linux seront privees de support et risquent d'avoir de gros problemes avec Linux. Donc l'image du logiciel libre va etre devalorisee.
Evidemment, on peut toujours garder le point de vue du "geek": le logiciel commercial on s'en fout, ce qui compte, c'est la liberte. La liberte pour qui, pour l'elite des "geek" ou pour tout le monde. Si Marina utilise Linux, c'est mieux que si elle utilise WinXX, et ca, c'est grace a Suse, Mandrake ou autres. Donc c'est mieux qu'ils durent.
Enfin, si Suse disparait, le projet Alsa ne sera plus finance, deux developpeurs X ne seront plus payes, 5 developpeurs KDE non plus, 6 ou 7 developpeurs Kernel non plus, 1 developpeur Gnome egalement. Tu te doutes bien que ces projets vont fortement ralentir. La communaute du logiciel libre en patira!
Donc on a interet a ce que les boites qui font du logiciel libre survivent. Cela vaut pour Suse, Mandrake, MySQL, Trolltech et les autres.
Pour les accents, je ferai un effort, c'est promis. Mais ça va tellement plus vite sans.
> Et vu la complexité de ces logiciels, un marché
> s'est constitué permettant à ceux qui en ont la maîtrise de monnayer leurs compétences
Ce que tu cites, c'est une économie de services. L'utilisateur final est confronté à une complexité et il a besoin d'aide, que tu lui vends.
Ca ne marche pas pour les jeux car ceux-ci sont basés sur une économie de produit. Tu vends le produit et c'est tout. L'utilisateur n'a pas besoin de ton aide pour l'installer donc le seul bénéfice que tu fais proviens de la vente.
Affinons et disons que ça ne marche pas pour les jeux que je connais actuellement, qui sont basés fondamentalement sur un modèle de produit. Si tu trouve un nouveau concept de jeu basé sur du service, tu pourras faire probablement faire des jeux en GPL. C'est ce que veut faire la boite parisienne dont j'ai oublié le nom mais je reste sceptique. En tout cas, il va falloir de l'imagination.
Dans les cybercafes modernes où on voit des gens jouer a Quake et autres, tu vends le service de l'utilisation de l'ordinateur. Des lors, si tu leur fait économiser sur le produit (Quake, Windows, ...), ça vaut le coup. Donc peut-être ces gens-là auront interêt à financer le développement d'un jeu en GPL. Mais ca me parait très hypothétique comme modèle d'affaire.
> Il faut apporter autre chose que du logiciel: du service, de l'innovation ou des normes.
Ce que tu me dis, c'est que le modele que j'ai nomme 2 est viable. Quand tu construis du service sur du logiciel libre, tu peux gagner de l'argent et j'en suis heureux.
Mais il n'en reste pas moins que si par exemple, je porte KOffice sur MacOs et je veux le vendre, j'aurais du mal. Parce qu'une fois que j'aurais package mon CD et depense mes MF, un petit malin risque de me piquer des clients en vendant mon propre travail (le packaging, pas KOffice)!
> Un programme en LGPL definie une norme ou un
> protocole que va defendre l'equipe de
> developpement, qui permettra aux utilisateurs
> tierces parties de construire au dessus.
> Ceci permet d'obtenir des retombees sonnantes et
> trebuchantes.
Tu te place dans une optique particuliere qui est celle du developpement d'une librairie de reference. C'est le cas ou plusieurs societes ont interet a mutualiser leurs developpement en choisissant du LGPL plutot que du proprietaire.
Mais dans le cas d'un produit, si ton programme est LGPL, les gens pourront l'utiliser sans te verser un centime, meme si ils font du code proprietaire.
Si ton programme est sous GPL, ils vont devoir soit faire un programme GPL, soit t'achter une licence. C'est un encouragement a faire du GPL. Dans les deux cas (tu gagnes de l'argent ou ils font un prog GPL), la communaute du logiciel libre est gagnante. Et c'est pour ca que RMS encourage la GPL plutot que la LGPL, avec raison.
> L'exemple typique est TrollTech.
Qt est justement en GPL et non en LGPL. L'exemple typique que tu cherches, c'est Gtk. Parce que Qt est GPL ou commercial, ceux qui l'ont developpe gagnent de l'argent avec et peuvent ameliorer Qt, embaucher d'autres developpeurs a plein temps. On y gagne.
Parce que Gtk est LGPL, tout le monde peut l'utiliser pour faire du closed-source sans donner d'argent aux auteurs. Du coup, les gens ont moins de temps a y consacrer et le toolkit va moins s'ameliorer. Tu depens du bon-vouloir des utilisateurs qui peuvent se dire "tiens, si on lui filait 100 balles". Bof!
C'est vrai, j'aurais du attendre encore un peu et faire relire et tout ca, mais j'etais excite et j'avais vraiment envie de publier ca le plus vite possible.
La prochaine fois, y aura des accents c'est promis.
> Le moteur n'est pas le plus important dans un
> jeu, c'est les graphismes/sons/scénarios/...
Non, c'est un tout.
Un jeu, de nos jours, c'est un bon moteur + un bon scenario + des bons graphismes.
> Le même moteur a été utilisé avec très peu de
> modification pour un grand nombre de jeux:
Bien sur, une fois que le moteur est developpe, plus tu l'utilises, plus tu le rentabilises. Comme c'est un cout de developpement important, il vaut mieux le rentabiliser au maximum.
> Je ne suis pas sur que BioWare aurait vendu un
> exemplaire de moins de ces jeux s'ils avaient
> diffusé l'Infinity Engine en GPL
Et bien moi si.
Si ils avaient diffuse leur moteur en GPL, un concurrent aurait eu tot fait de l'utiliser pour sortir un jeu avec ses propres graphismes.
Mettons que le premier jeu ait coute en developpement 15 MF (10 developpeurs * 500 kF * 3 ans) et que le moteur represente 1/3 de ce cout. Si l'Infinity Engine est diffuse en GPL, je monte une boite et je le recupere pour faire un jeu. Je paye mes 10MF de graphistes, scenaristes et son mais j'economise 5 MF de developpement. Du coup, je peux me permettre de payer 2MF de plus pour les graphismes/sons.
A la fin, j'ai un jeu avec de meilleurs graphismes/sons que ceux qui l'ont developpe et ca m'a coute moins cher. Ca me permet de faire un benefice plus important et surtout, de reinvestir pour lancer le jeu suivant plus tot avec encore plus de mondes vue les economies que j'ai fait.
Tous les autres jeux qui ont ete sortis par Bioware auraient du faire face a une concurrence des plus rude, donc ils auraient vendu moins de boite. CQFD.
C'est ca que j'entend quand je parle de barriere d'entree negative. Le concurrent a un avantage sur toi, c'est ta propre technologie!
Quand au miracle, on release un logiciel et il est porte sur toutes les plate-formes, ca marche pas forcement. Qt est en GPL depuis un an et on voit a peine des premices de port sous windows et BeOs, mais rien sur MacOs.
[^] # Re: Ce serait de la pub
Posté par Philippe F (site web personnel) . En réponse à la dépêche Demonstration des composants KDE. Évalué à 2.
> et vice-versa.
C'est ce que croient beaucoup de gens. Ce serait un rien plus facile avec Corba des deux cotes, mais ca ne resoud pas les problemes de fond pour avoir l'interoperabilite: des api et des fonctionnalites communes. A cote de ca, Corba ou pas Corba, c'est un detail. Pour l'instant, Gnome et KDE ont des trucs similaires, mais creer un pont entre les deux releve de la gagure, meme s'ils utilisaient tous les deux Corba.
En plus, KDE utilisait mico et Gnome utilisait Orbit. Je ne sais pas pourquoi mais ca posait de problemes. Le fait que l'un soit en C et l'autre en C++ avait aussi des consequences.
Et puis qui aurait developpe ce pont ? Probablement personne! Ca ne serait qu'un "cool hack" mais pas tres util. KDE a deja tous les composants dont il a besoin. Gnome n'en a pas beaucoup, mais il a presque les meme que KDE, donc il ne va pas aller chercher ceux de KDE.
Donc choisir Corba, ca aurait ete alourdir le desktop que pour des situation hypothetiques (composnants distribues, pont vers Bonobo) qui en pratique ne sont pas utilisees.
Bon, et en prime, je te donne une info: il est tout a fait possible d'avoir un composant Gnome sous KDE et vice versa. Il faut connaitre un peu Bonobo et connaitre un peu KDE (KPart et XPart) mais techniquement, il n'y a pas de problemes. Simplement, personne n'a envie de le faire pour l'instant.
[^] # Re: Ce serait de la pub
Posté par Philippe F (site web personnel) . En réponse à la dépêche Demonstration des composants KDE. Évalué à 2.
Bon, le prochain article sera certainement une comparaison relativement detaillee de Corba et KParts.
[^] # Re: COmment vous comprenez ca ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Interview du president TrollTech. Évalué à 10.
> hostile fork of Qt and, in a sense, take over our only product"
>
> Doit-on comprendre qu'ils avaient peur que quelqu'un fasse mieux qu'eux et s'approprie le
> produit?
Ils avaient peur que quelqu'un s'approprie le produit oui. Je peux meme te citer un nom: RedHat.
Mais RedHat est parti pour Gtk. Harmony n'a jamais decolle. A partir de Qt2, ils n'ont pas arrete de progresser et il est devenu clair que personne ne maitriserait Qt mieux qu'eux. Donc ils sont passes a la GPL.
En revanche, je ne pense pas qu'ils aient jamais eu peur que quelqu'un fasse un meilleur Qt que le leur. Ils sont trop forts. Quand Eirik dit qu'il prend uniquement les meilleurs, il dit vrai.
Rappelons que meme sans etre GPL, Qt respectait deja les trois libertes du logiciel que garantit par la GPL. Donc la GPL, ca n'a ete que politique. Ce n'est pas l'interview (qui date d'un mois alors que Qt est en GPL depuis plus d'un an) qui y a change qqch.
# 2 news de suite
Posté par Philippe F (site web personnel) . En réponse à la dépêche Interview du president TrollTech. Évalué à -10.
[^] # Re: Question sur le swap
Posté par Philippe F (site web personnel) . En réponse à la dépêche Sortie du Noyau 2.4.10. Évalué à 2.
# Allez y!
Posté par Philippe F (site web personnel) . En réponse à la dépêche Prochaine FOSDEM. Évalué à 3.
J'ai appris qqs trucs sur Hurd, j'ai decouvert Mosix, j'ai vu RasterMan (100% comme je l'imaginais) et decouvert Evas.
[^] # Re: Annonce prématurée
Posté par Philippe F (site web personnel) . En réponse à la dépêche KDE 2.2.1 sort. Évalué à 6.
Il y a un "release schedule" (http://developer.kde.org/development-versions/kde-2.2.1-release-pla(...)) pour chaque release de KDE, qui specifie notamment quand la release doit etre officiellement announcee. Ceci afin:
- de permettre des tests dans la derniere semaine (on a vu des bugs decouverts et corriges le jeudi)
- donner du temps aux packageurs
- permettre aux miroirs de se mettre a jour
- ne pas mettre le ftp de KDE sur les genoux
- eviter d'avoir des gens qui se plaignent qu'il n'y a pas tous les package.
Donc ce serait bien que les moderateurs tiennent compte de ceci avant d'approuver une news (ce que font les moderateurs de slashdot).
.
.
.
Mea Culpa, il semble que d'une part le "release schedule" pour KDE 2.2.1 n'ait pas ete mis a jour, d'autre part, que la nouvelle date de release annoncee sur dot.kde.org soit du 17 septembre, ce qui rend la news valide.
Mais ca me semble louche que ca ne soit pas annonce sur dot.kde.org.
[^] # Re: Les gouts et les couleurs...
Posté par Philippe F (site web personnel) . En réponse à la dépêche Al Stevens n'aime pas QT. Évalué à 3.
bricolage macrotique ? Les seuls macros que le developpeur utilise dans Qt, c'est:
"slots" -> rien
"signal" -> "protected"
Q_OBJECT -> <on n'a pas besoin de le savoir>
Ca ressemble pas a un bricolage. Et tres vite, on a l'impression que les mot-cles "slots" et "signal" font partie du langage C++.
Ces mot-cles ne sont d'ailleurs utilises que dans le .h et pas dynamiquement. C'est leger et surtout extremement pratique d'avoir tout de declare dans le .h
Cet argument me parait donc encore plus contestable que les autres.
<troll-zone>
Alors que quand je touche a du code Gtk, je tremble a chaque fois que je vois une macro de cast, en imaginant tout ce qu'elle doit faire derriere. Sans compter les "return_if_fail" et autres bidouilles.
Les gens qui disent preferer Gtk parce que "Qt, c'est pas du C++!" me font doucement rigoler. Si un jour je veux absoluement faire du C, une chose est sure, je ne me tournerai pas vers Gtk car ca ne ressemble plus a du C. Ce ressemble plutot un clone hybride de C++.
[^] # Re: Il avait aussi critique Gcc
Posté par Philippe F (site web personnel) . En réponse à la dépêche Al Stevens n'aime pas QT. Évalué à 3.
Tu corriges ton bug et tu appuies sur F10 (next). Et la, le miracle se produit devant tes yeux:
VC++ recompile automatiquement le fichier que tu viens de modifier, l'integre dans le nouvel executable, le charge en memoire, se transpose au meme endroit, de sorte que tu peux continuer a debugger tranquillement, comme si tu le code sans bug n'avait pas toujours ete la. C'est comme si tu travaillais avec un langage interprete.
Trop fort!!! Ca m'a scie. Dans 10 ans, peut-etre que gcc fera ca. Peut-etre.
Evidemment, ca ne doit pas pouvoir marcher dans tous les cas, mais pour l'instant, j'ai pas eu de problemes.
Je ne m'en suis toujours pas remis tellement c'est pratique.
[^] # Re: Pareil
Posté par Philippe F (site web personnel) . En réponse à la dépêche Al Stevens n'aime pas QT. Évalué à 5.
La je ne vois pas pourquoi ? Parce que c'est en majuscule ? En C++, tu peux aussi nommer tes classes en majuscule a ca deviendra aussi lisible!
> En GTK on sait à chaque fois exactement à quel niveau de l'héritage on se situe, et de quelle manière on utilise l'objet en question.
Je ne saisis pas comment le fait d'utiliser une macro te permet de savoir a quel niveau d'heritage tu es.
Et puis en C++, tu fais ca avec un simple cast, pas de soucis, le compilateur travaille pour toi. Pas besoin de "return_if_fail" et autres ajouts pas du tout leger de gtk.
En dehors du moc, qui est un peu surprenant au debut, je n'ai trouve aucun defaut a Qt depuis 2 ans que je l'utilise intensement.
Il me semble d'ailleurs que l'utilisation d'espaces de noms plus intensifs est prevu pour Qt3.
Et le modele memoire de Qt est vraiment tres pratique (a cote de celui de Gtk). C'est presque aussi agreable de coder en c++ avec Qt qu'en python. Alors en PyQt, je vous dis pas!!
[^] # Re: les alternatives ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Sourceforge devient propriétaire ?. Évalué à 1.
www.berlios.de
C'est proche de chez nous donc ca rame pas comme sourceforge
[^] # Re: GNU/Linux
Posté par Philippe F (site web personnel) . En réponse à la dépêche KDE gagne le prix du meilleur projet Open Source. Évalué à 1.
> marcher avec un autre noyau !
Voire avec un autres OS, donc exit GNU. Pour info, KDE fonctionne tres bien sans un seul programme Gnu, cf la page de toutes les plate-formes et compilos suppportes (page que je ne retrouve plus, mea culpa).
<troll>
Perso, j'utilise KDE/Linux :-))
</troll>
Donc on dira jamais j'utilise Gnu/KDE !!!
[^] # Re: Amplement mérité
Posté par Philippe F (site web personnel) . En réponse à la dépêche KDE gagne le prix du meilleur projet Open Source. Évalué à 1.
Oui, ils vont faire ca au debut. Mais il ne faut pas sous-estimer l'utilisateur. Beaucoup sont curieux. Une fois que l'utilisateur sera familier avec son environnement, qu'il n'aura plus peur des popup et qu'il arrivera a placer ses fenetres correctement, il va regarder ce qu'il peut faire pour amerliorer le look'n feel. Et la, il va gouter la configurabilite de KDE.
C'est ce qui ressort de l'installation de KDE dans la ville de Largo (cf dot.kde.org). Les utilisateurs apprecient de pouvoir bidouiller leur bureau. Mais il ne faut pas les forcer tout de suite.
Donc finalement, KDE a choisi la bonne demarche, comme toujours :-))
[^] # Re: Heu, expert à 25 ans...
Posté par Philippe F (site web personnel) . En réponse à la dépêche Experts du Logiciel Libre. Évalué à 1.
> d'autres competences plus administratives et/ou relationnelles.
Competences qui s'acquierent justement en general avec l'experience. Entre un mec de 25 ans et un mec de 40 ans, s'il y a une chose dont on peut etre sur, c'est que l'un a plus d'experience que l'autre. Experience en quoi et competences precises demandent ensuite a etre approfondi, evidemment.
Si tu as 25 ans et que tu as bosse 3 ans dans ta vie, toujours dans le meme job, dans une petite boite et que t'as fait un projet logiciel libre dans ta vie, c'est redhibitoire.
Si t'as 25 ans, que t'as cree une boite qui a marche, que tu as eu plusieurs boulots, que tu as deja manage une equipe ou fait du commercial, que tu as deja bosse dans une grosse administration, que t'as deja gere 5 projets logiciel libre dont un avec succes ou il y avait une equipe, ca passera a mon avis tres bien.
Bien sur, tout ca n'est que mon avis subjectif et personnel. Mais si je devais choisir un candidat, ce qui ferait la difference, ce n'est pas l'age mais l'experience. Donc faut pas seulement etre expert Gnu/Linux/Fsf/Kde/Freebsd/Gpl/python/perl pour etre expert. Faut avoir vecu.
[^] # Re: Konqi vs Galeon
Posté par Philippe F (site web personnel) . En réponse à la dépêche Netscape meilleur navigateur pour Linux ?. Évalué à 1.
La technologie utilisee pour encastrer Gecko eu lieu de KHtml s'appelle XPart. Elle ne depend que de DCOP et de X (et de Qt de facon sous-jacente). DCOP etant completement independant de KDE, cela veut dire que cette technologie peut permettre d'encastrer n'importe quel programme dans n'importe quel autre a condition d'avoir sous la main les bibliotheque Qt, DCOP et X (cas relativement courant sur un systeme).
Notamment, il est possible de faire un pont entre les composants KDE et Bonobo par l'intermediaire de XPart. Si quelqu'un a le courage de s'y mettre...
[^] # Re: un p'tit dernier pour la route ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Essais sur les logiciels libres. Évalué à 1.
Dire que Qt n'etait pas libre, je trouve ca un peu rapide. Qt n'etait pas GPL. Mais qui decide de ce qui est libre ? RMS ? Les trois libertes fondamentales du logiciel decrites par RMS etaient notamment respectees.
En ce qui me concerne, un logiciel peut etre libre sans etre necessairement sous GPL.
> À nouveau le troc de la commodité contre la
> liberté. C'est la grande différence avec le projet Gnome.
A mon sens, la grande difference entre KDE et Gnome, c'est que KDE ne troc pas la qualite et la facilite de developpement pour quoi que ce soit, contrairement a Gnome.
On peut d'ailleurs dire la meme chose de Linux par rapport a Hurd. Hurd ne troc pas la liberte, mais on a un truc 30% moins rapide que Linux, qui a peu de chance de decoller. Mais oui, le "message passing", c'est mieux. Mais en attendant, Linux est la, et Hurd a plus de 5 ans de retard par rapport a sa date initiale de release.
KDE, tout comme Linux, a un role d'evangelisation du logiciel libre bien plus efficace que Hurd ou Gnome, alors que ceux-ci sont "plus" dans l'esprit du libre. Mais moins bien. Alors que KDE et Linux, ils sont la et ca marche.
[^] # Re: kde et gcc 3
Posté par Philippe F (site web personnel) . En réponse à la dépêche Sortie de Kde 2.2. Évalué à 1.
La press-release precise que KDE ne compile pas avec gcc 3. gcc 3 a encore trop de bug et casse la compatilbilite binaire. Il faudra attendre KDE 3.0 (janvier 2002) pour utiliser gcc 3.0
[^] # Re: recompilation
Posté par Philippe F (site web personnel) . En réponse à la dépêche Sortie de Kde 2.2. Évalué à 1.
http://kdewebcvs.nebsllc.com/cgi-bin/cvsweb.cgi/kdelibs/COMPILING?r(...)
[^] # Re: abaisser la barriere
Posté par Philippe F (site web personnel) . En réponse à la dépêche Viabilite économique de la GPL. Évalué à 1.
> norme ou un protocole. Celui-ci valorise
> l'informatique parce qu'elle federe des acteurs
> et on peut donc (esperer) en retirer des revenus.
Donc tu passes 5 ans a developper a perte un logiciel en GPL et ensuite, grace a la place que tu as acquise sur le marche, tu commence a faire du revenu. C'est completement irrealiste! Une boite ne peut pas vivre 5 ans sans gagner de l'argent. Le probleme d'une societe, ce n'est pas d'acquerir une position de leader, c'est de gagner de l'argent. Le plus tot et le maximum, c'est toujours le mieux.
Tu parles de "normes" et de "references". M'est avis que tu es un peu trop admin system. Qt c'est une boite a outil. Tu l'utilise ou tu l'utilise pas, il n'y a pas de "normes" a mettre en place.
> La GPL a une autre utilité: Permettre de démarrer un projet à bas coût. Si ce projet
> devient mur, il faut en recolter les fruits et ceci signifie le considérer - en partie - comme
> une librairie sur laquelle d'autres batiront.
Developper un projet en GPL ou sous une licence commerciale a le meme cout.
[^] # Re: Constat : soyez plus indulgent envers SuSE...
Posté par Philippe F (site web personnel) . En réponse à la dépêche Viabilite économique de la GPL. Évalué à 1.
D'un cote on a des gens comme ESR qui se battent pour dire "mais si, le logiciel libre est un modele economique reel, regardez toutes ces boites qui vivent avec". Et de l'autres des gens qui sont completements indifferents a la disparation de societe basee sur du logiciel libre.
Ca veut dire que demain, si tu veux monter une boite pour vendre du service LL et que tu as besoin d'investisseurs, ils vont te dire "regardez, Suse s'est cassee la gueule, on ne peut pas faire d'argent avec le logiciel libre".
Si Suse se casse la gueule, ca veut dire aussi que beaucoup de societes qui ont investi dans Linux seront privees de support et risquent d'avoir de gros problemes avec Linux. Donc l'image du logiciel libre va etre devalorisee.
Evidemment, on peut toujours garder le point de vue du "geek": le logiciel commercial on s'en fout, ce qui compte, c'est la liberte. La liberte pour qui, pour l'elite des "geek" ou pour tout le monde. Si Marina utilise Linux, c'est mieux que si elle utilise WinXX, et ca, c'est grace a Suse, Mandrake ou autres. Donc c'est mieux qu'ils durent.
Enfin, si Suse disparait, le projet Alsa ne sera plus finance, deux developpeurs X ne seront plus payes, 5 developpeurs KDE non plus, 6 ou 7 developpeurs Kernel non plus, 1 developpeur Gnome egalement. Tu te doutes bien que ces projets vont fortement ralentir. La communaute du logiciel libre en patira!
Donc on a interet a ce que les boites qui font du logiciel libre survivent. Cela vaut pour Suse, Mandrake, MySQL, Trolltech et les autres.
[^] # Re: Retour en arrière
Posté par Philippe F (site web personnel) . En réponse à la dépêche Viabilite économique de la GPL. Évalué à 1.
[^] # Re: Retour en arrière
Posté par Philippe F (site web personnel) . En réponse à la dépêche Viabilite économique de la GPL. Évalué à 2.
> Et vu la complexité de ces logiciels, un marché
> s'est constitué permettant à ceux qui en ont la maîtrise de monnayer leurs compétences
Ce que tu cites, c'est une économie de services. L'utilisateur final est confronté à une complexité et il a besoin d'aide, que tu lui vends.
Ca ne marche pas pour les jeux car ceux-ci sont basés sur une économie de produit. Tu vends le produit et c'est tout. L'utilisateur n'a pas besoin de ton aide pour l'installer donc le seul bénéfice que tu fais proviens de la vente.
Affinons et disons que ça ne marche pas pour les jeux que je connais actuellement, qui sont basés fondamentalement sur un modèle de produit. Si tu trouve un nouveau concept de jeu basé sur du service, tu pourras faire probablement faire des jeux en GPL. C'est ce que veut faire la boite parisienne dont j'ai oublié le nom mais je reste sceptique. En tout cas, il va falloir de l'imagination.
Dans les cybercafes modernes où on voit des gens jouer a Quake et autres, tu vends le service de l'utilisation de l'ordinateur. Des lors, si tu leur fait économiser sur le produit (Quake, Windows, ...), ça vaut le coup. Donc peut-être ces gens-là auront interêt à financer le développement d'un jeu en GPL. Mais ca me parait très hypothétique comme modèle d'affaire.
Par exemple,
[^] # Re: abaisser la barriere
Posté par Philippe F (site web personnel) . En réponse à la dépêche Viabilite économique de la GPL. Évalué à 1.
Ce que tu me dis, c'est que le modele que j'ai nomme 2 est viable. Quand tu construis du service sur du logiciel libre, tu peux gagner de l'argent et j'en suis heureux.
Mais il n'en reste pas moins que si par exemple, je porte KOffice sur MacOs et je veux le vendre, j'aurais du mal. Parce qu'une fois que j'aurais package mon CD et depense mes MF, un petit malin risque de me piquer des clients en vendant mon propre travail (le packaging, pas KOffice)!
> Un programme en LGPL definie une norme ou un
> protocole que va defendre l'equipe de
> developpement, qui permettra aux utilisateurs
> tierces parties de construire au dessus.
> Ceci permet d'obtenir des retombees sonnantes et
> trebuchantes.
Tu te place dans une optique particuliere qui est celle du developpement d'une librairie de reference. C'est le cas ou plusieurs societes ont interet a mutualiser leurs developpement en choisissant du LGPL plutot que du proprietaire.
Mais dans le cas d'un produit, si ton programme est LGPL, les gens pourront l'utiliser sans te verser un centime, meme si ils font du code proprietaire.
Si ton programme est sous GPL, ils vont devoir soit faire un programme GPL, soit t'achter une licence. C'est un encouragement a faire du GPL. Dans les deux cas (tu gagnes de l'argent ou ils font un prog GPL), la communaute du logiciel libre est gagnante. Et c'est pour ca que RMS encourage la GPL plutot que la LGPL, avec raison.
> L'exemple typique est TrollTech.
Qt est justement en GPL et non en LGPL. L'exemple typique que tu cherches, c'est Gtk. Parce que Qt est GPL ou commercial, ceux qui l'ont developpe gagnent de l'argent avec et peuvent ameliorer Qt, embaucher d'autres developpeurs a plein temps. On y gagne.
Parce que Gtk est LGPL, tout le monde peut l'utiliser pour faire du closed-source sans donner d'argent aux auteurs. Du coup, les gens ont moins de temps a y consacrer et le toolkit va moins s'ameliorer. Tu depens du bon-vouloir des utilisateurs qui peuvent se dire "tiens, si on lui filait 100 balles". Bof!
[^] # Re: « Traduction »
Posté par Philippe F (site web personnel) . En réponse à la dépêche Viabilite économique de la GPL. Évalué à 1.
C'est vrai, j'aurais du attendre encore un peu et faire relire et tout ca, mais j'etais excite et j'avais vraiment envie de publier ca le plus vite possible.
La prochaine fois, y aura des accents c'est promis.
[^] # Re: GPL et jeux
Posté par Philippe F (site web personnel) . En réponse à la dépêche Viabilite économique de la GPL. Évalué à 3.
> jeu, c'est les graphismes/sons/scénarios/...
Non, c'est un tout.
Un jeu, de nos jours, c'est un bon moteur + un bon scenario + des bons graphismes.
> Le même moteur a été utilisé avec très peu de
> modification pour un grand nombre de jeux:
Bien sur, une fois que le moteur est developpe, plus tu l'utilises, plus tu le rentabilises. Comme c'est un cout de developpement important, il vaut mieux le rentabiliser au maximum.
> Je ne suis pas sur que BioWare aurait vendu un
> exemplaire de moins de ces jeux s'ils avaient
> diffusé l'Infinity Engine en GPL
Et bien moi si.
Si ils avaient diffuse leur moteur en GPL, un concurrent aurait eu tot fait de l'utiliser pour sortir un jeu avec ses propres graphismes.
Mettons que le premier jeu ait coute en developpement 15 MF (10 developpeurs * 500 kF * 3 ans) et que le moteur represente 1/3 de ce cout. Si l'Infinity Engine est diffuse en GPL, je monte une boite et je le recupere pour faire un jeu. Je paye mes 10MF de graphistes, scenaristes et son mais j'economise 5 MF de developpement. Du coup, je peux me permettre de payer 2MF de plus pour les graphismes/sons.
A la fin, j'ai un jeu avec de meilleurs graphismes/sons que ceux qui l'ont developpe et ca m'a coute moins cher. Ca me permet de faire un benefice plus important et surtout, de reinvestir pour lancer le jeu suivant plus tot avec encore plus de mondes vue les economies que j'ai fait.
Tous les autres jeux qui ont ete sortis par Bioware auraient du faire face a une concurrence des plus rude, donc ils auraient vendu moins de boite. CQFD.
C'est ca que j'entend quand je parle de barriere d'entree negative. Le concurrent a un avantage sur toi, c'est ta propre technologie!
Quand au miracle, on release un logiciel et il est porte sur toutes les plate-formes, ca marche pas forcement. Qt est en GPL depuis un an et on voit a peine des premices de port sous windows et BeOs, mais rien sur MacOs.