Bien que la licence d'OpenCascade puisse être considéré comme étant open source, elle n'est pas libre (clause de publicité, obligation de remonter les patchs aux développeurs).
Raison pour laquelle, OpenCascade n'est pas distribué dans Fedora et que Debian la distribution dans non-free.
In short, Open CASCADE Technology Public License is LGPL-like with certain differences. You are permitted to use Open CASCADE Technology within commercial environments and you are obliged to acknowledge its use. You are also obliged to send your modifications of the original source code (if you have made any) to the Initial Developer (i.e. Open CASCADE S.A.S.). Complete text of the license is given below.
> Quand tu valide un site avec w3c il ne vérifie pas le CSS et HTML en même temps
Un ancien de fedora-fr avait fait le même constat, il y a quelques années, voilà sa réponse: http://xhtml-css.com
> La documentation sous forme de manuel (hors code) ne fait pas parti des bonnes pratiques de dév
Dans certains cas comme le développement d'API (bibliothèque, interface de plugins), la documentation est tout autant une bonne pratique que les tests unitaires (ou pas unitaires).
Savoir appréhender les outils de documentation en ligne (doxygen, javadoc, gtk-doc, docstrings, etc ...) doit être un pré-requis pour les développeurs.
D'autres problématiques tout aussi essentielles au métier de développeurs sont rarement ou très mal abordés: i18n (quasiment aucun cursus n'en parle), portabilité, conception/architecture, sécurité, déverminage, etc ...
Posté par GeneralZod .
En réponse au journal 8 mars.
Évalué à 4.
> puisqu'il a manifestement accepté de prendre le risque d'avoir cet enfant.
On peut en dire autant de sa partenaire
> C'est plutôt l'inverse, à lui de prouver qu'il a explicitement affirmé ne pas vouloir de cet enfant.
Si tu pars du postulat qu'il en veut bien, tu peux difficilement lui nier derrière, le droit de participer au processus d'avortement. Responsabiliser le père, ça ne se limite pas à lui rajouter des devoirs, mais également à lui donner dans une certaine mesure des droits.
On peut tout à fait protéger les droits des femmes sans pour autant nier le droit des pères comme c'est le cas actuellement.
Dans le cadre de la législation actuelle, la mère a tout les droits y compris d'extorquer une pension alimentaire alors que le père ne peut que fermer sa gueule.
Posté par GeneralZod .
En réponse au journal 8 mars.
Évalué à 5.
Forcer un homme à payer une pension alimentaire alors qu'il n'a rien demander, c'est assimilable à de l'extorsion.
Je suis tout à fait d'accord sur le fait que la décision finale appartient à la mère, mais le père a le droit de savoir et d'exprimer son point de vue.
La contrepartie du droit à l'avortement serait le droit du père à ne pas assumer un enfant sauf si il en a exprimé la volonté d'une façon ou d'une autre.
Tout à fait, le seul intérêt de Nouveau est de dépanner les utilisateurs qui n'ont pas le choix (et le gaspillage c'est mal). Soutenir Nouveau et déconseiller l'achat de cartes nVidia tant que leur politique vis à vis du libre sera en *retrait* par rapport à la concurrence, est une position tout à fait cohérente.
Mieux encore, il n'y a pas de contradiction entre les demandes des libristes et la réalité économique, puisque la libération de la documentation ou du pilote ne porte pas atteinte au business de nVidia (vendre des processeurs graphiques, pas des pilotes).
> Tu crames souvent ta CG ?
Moi non, mais j'ai déjà eu à réparer les dégâts de nVidia chez d'autres. Et ce n'est parce que tu as un cas sur cent que tu ne dois pas t'en préoccuper, surtout si tu es empaqueteur ou que tu fais du support.
> Quels batons dans les roues ? Nvidia ne les aide pas mais ne les empechent pas non plus de continuer leur projet.
Ils ne leur filent pas de la documentation, pas de matos, ni même répondent à leurs questions. La seule chose qu'ils ne font pas c'est de leur coller un procès au cul.
> Tu as un exemple de carte graphique mainstream qui as des pilotes libres plus performants ?
Suffit de comparer les ATI supporté par radeon et fglrx, mis à part quelques fonctionnalités annexes, fglrx est à la ramasse. La documentation libérée par AMD a permis de redonner une seconde jeunesse à radeon.
> Nvidia n'a pas de mal a suivre l'evolution de xorg, leurs pilotes fonctionnent bien sur le dernier serveur sorti.
Certes, si ta distribution reste bloquée sur le dernier X server supporté par nVidia, tu ne risques pas de t'en rendre compte. nVidia tiens un bon rythme mais il y a souvent un décalage de quelques mois entre la sortie du dernier Xorg et son support dans leur pilote.
Parfois, il faut même un bon vieux patch binaire pour que ça fonctionne.
> Vive la paranoia et le FUD, tu m'expliques en quoi le fait de remplacer du code de xorg par leur version rend un client qui utilise leurs cartes captif ? Tant que l'api utilisée par les programmes reste la même ca ne change rien.
Déjà, ils s'amusent à écraser la libGLX fournie par le système, ça ne facilite pas la tâche des développeurs faisant usage de la CG (par exemple, les bureaux composites), etc ...
Sans oublier, l'abandon régulier du support des anciennes cartes, ce qui fait qu'on doit maintenir en parrallèle plusieurs versions du pilotes jusqu'à ce que ça ne marche plus.
Tout est fait pour que le client soit enfermé et change régulièrement son matériel (de préférence du nVidia), que ce soit le simple particulier, le power user ou bien le développeur.
Quel est l'intérêt pour nVidia de redévelopper ce qui existe déjà dans Xorg ? techniquement, ça leur apporte que dalle aujourd'hui, juste des emmerdes.
> Je viens de relire ton post et c'est marrant parce qu'en fait en fait tout ce que tu as marque me fait penser a ce qu'on appelle du FUD.
C'est drôle, je m'étais dit exactement la même chose de ton précédent post/
Quand ta CG crame, t'es bien content de pouvoir la changer sans te poser la question de savoir si ça remarchera au démarrage.
> ca marche soit aussi bien, soit beaucoup beaucoup moins bien
Le support des GPU intel est très bon sous les Unix libres et celui des ATI s'améliore régulièrement. Quand les développeurs ont accès aux spécifications, les pilotes libres sont souvent bien meilleurs que leurs équivalents propriétaires.
Je tire mon chapeau aux développeurs de Nouveau pour leur excellent travail malgré les batons que nVidia leur mets dans les roues et le peu de soutien qu'ils reçoivent de la communauté.
> Et tout ca parce que X change d'API et rajoute des nouvelles extensions tout les 4 matins parce que les anciennes sont trop mal foutues pour evoluer proprement.
Tu suis l'évolution de Xorg à travers les newsletter des commerciaux de nVidia ou quoi ?
Si nVidia ne s'amusait pas à redévelopper les extensions standards de Xorg (ils ont leur propre GLX, leur propre gestion des écrans multiples, ils n'utilisent pas DRI, KMS, etc ...), ils auraient beaucoup moins de mal à suivre l'évolution de Xorg.
La raison pour laquelle, ils dupliquent une bonne partie de l'infrastructure de Xorg, ce n'est pas parce que Xorg c'est de la merde et blablabla, l'objectif c'est d'enfermer le client.
Va demander aux personnes qui font des paquets pour la bouse de nVidia pour savoir à quel point c'est mal foutu leur tas de merde.
Les changements d'API sont un faux problème, sinon faudra m'expliquer comment le noyau Linux arrive à maintenir autant de pilotes à jour.
Sauf à vouloir maintenir une architecture sub-optimale, avec une multitude de couches de compatibilité, il est quasiment impossible d'éviter les changements d'API dans un composant aussi complexe que X. nVidia n'a qu'à libérer son pilote ou les spécifications si ça les fait chier.
> La question qu'il faudrait se poser c'est comment ameliorer X (au niveau architecture) et comment ameliorer le process de dev (pour pas devoir tout refaire dans 2 ans parce qu'on a merde sur l'API).
T'as six ans de retard, si tu rajoutes le changement de licence de XFree86, ces questions-là sont à l'origine de Xorg. Même si il reste du travail à faire, Xorg avance et avance dans le bon sens.
Android, c'est pas la panacée non plus à différents niveaux: orientation plutôt open-source que libre (on préfére réinventer la roue que d'utiliser du GPL ou même du LGPL), Google ne collabore pas ou peu avec les projets upstreams [1], support matériel aléatoire selon le bon vouloir du fabricant et le SDK Java only ... enfin, la difficulté d'utiliser des bibliothèques natives sur Android pour porter des applications existantes.
Perso, j'espère beaucoup de MeeGo, sous l'égide de la Linux Foundation, il devrait suivre la même politique de licence que feu Moblin (pas de pilotes de merde propriétaires) avec un environnement beaucoup moins restreint qu'Android pour les développeurs.
Avec l'appui et le savoir-faire de Nokia et Intel, on devrait voir arriver des smartphones beaucoup plus sympathiques que les droids actuels.
Ce qui m'amuse un brin dans cette histoire, c'est que un, personne n'a vérifié l'information [1], et deux, tout le monde copie quasiment mot pour mot sur le voisin (avec les erreurs en plus).
+1 pour Christophe Fergeau qui fait du très bon boulot dans libgpod (et également dans GNOME).
[1] même si on ne suit pas l'avancée des divers projets, il faut deux minutes pour trouver la référence à usbmuxd (donc à Marcan etc ...) à l'aide d'un moteur de recherche.
> Espérons que ces librairies pour le moment principalement compatibles avec Fedora et Ubuntu seront bientot opérationnelles sur les autres distributions Linux.
Le commentaire original avant d'être tronqué, précisait que le support serait fournis dans la plupart des versions prochaines des distros majeures, pas seulement Ubuntu et Fedora.
Ubuntu ne prends aucune avance et ça démontre une fois de plus que Canonical/Ubuntu sont des suiveurs, pas des leaders.
Orc est tout simplement le successeur de liboil, le mainteneur s'est longuement expliqué sur les raisons de son choix sur son blog. Pour résumer, ça simplifie le boulot du mainteneur, le travail des développeurs et les perfs sont meilleures. http://www.schleef.org/blog/category/liboil/
rST est un format balisage très simple et puissant, tu peux générer de l'html, du pdf, de l'odt etc ... sans problème. Tu peux utiliser les générateur rst2XXX ou bien le très puissant sphinx qui a l'intérêt d'utiliser un moteur de templating (jinja2) pour la génération de pages web.
Pour la génération de pdf, sphinx génére du latex intermédiaire donc au niveau de la typographie, ça devrait aller bien qu'il soit possible d'utiliser le backend rst2pdf pour générer directement le pdf.
> parce qu'on a pas envie de faire un paquet de 120 Mo ?
C'est un problème de packaging, il faut taper sur le mainteneur de python-matplotlib dans ta distribution pour qu'il sépare les différents backends de matplotlib dans des sous-paquets.
De mémoire, tu n'as pas besoin de WxWidgets pour que matplotlib fonctionne par exemple.
> Ils auraient pu aussi engager suffisament de développeur pour faire évoluer GNOME Mobile comme ils veulent. (Ou forker au besoin)
Vu le nombre de contributeurs à GNOME Mobile, c'est totalement irréaliste et ça aurait pris des années pour que Nokia arrive à obtenir un minimum de contrôle sur les différents projets.
Pour Nokia, il était nettement plus simple de racheter Trolltech: le framework est maitrisé par UNE société, les compétences sont déjà rassemblés, le multiplateforme est un acquis etc ...
> Ça leur aurais même sans doute coûté moins cher que le rachat de Trolltech, + le changement complet de leurs platforme.
C'est quoi la plateforme de Nokia ? Maemo ? un OS qui n'est jamais sorti du marché de niches des tablettes internet jusqu'au N900 ? Symbian ? un OS qui n'a jamais eu un grand succès auprès des développeur à juste titre ? Windows Mobile ? etc ... Nokia supporte plusieurs plateformes, et le switch vers Qt pour Maemo ne signifie pas la remise en cause des couches basses, Nokia continue à investir dans GNOME Mobile, la première chose qu'ils ont fait après avoir racheté Trolltech, c'est d'avoir mis au placard Qtopia.
Face à la poussée de l'iPhone et d'Android, Nokia devait agir rapidement et prendre en compte le choix de supporter plusieurs plateformes (Maemo, Symbian, Windows Mobile). Si on prends la dimension temps en compte, c'était un choix très judicieux.
> Trolltech a été acquis car Qt était une meilleur alternative.
Un troll qui trolle :-]
Sans rentrer dans le débat Qt vs Gtk+ (chacun à ses qualités et défauts), Qt4 est le meilleur framework multiplateforme sur le marché (documentation, support, outillage etc ...).
Et RMS a écrit un article pour expliquer la différence entre le libre et l'open source selon l'OSI. http://www.gnu.org/philosophy/open-source-misses-the-point.f(...)
La citation en question se référe évidemment à la définition de l'OSI mais il existe des logiciels à code ouvert non englobé dans l'open source
> Et concrètement tu as un exemple de logiciel open source non libre ?
Unix, Gosling Emacs étaient à l'origine open source mais pas libres, tu as actuellement SystemC, des logiciels privateurs mettant tout ou partie de leur code en "open-source" ce n'est pas ça qui manque (wince par exemple est un parfait exemple)
Certaines licences explicitement reconnues non libres par la FSF et open source par l'OSI: APSL v1.x, NASA Open Source Agreement, Reciprocal Public License
Un logiciel open source n'est pas forcément libre, y compris si tu prends en compte les critères de l'OSI.
Un logiciel libre est par définition open source, mais l'inverse n'est pas forcément vrai.
> Le choix de Qt est surtout lié au fait que Nokia en est le propriétaire.
Certes, reste que Nokia et Intel (après le rachat d'OpenedHand) étaient des acteurs majeurs derrière GNOME Mobile. Pour Nokia, il était plus simple de racheter Trolltech pour modeler Qt selon ses besoins que GNOME Mobile.
> elle est peut-être inégale pour les outils GNOME, mais on trouve aussi de l'excellent : je pense à la doc de GStreamer.
Tout à fait d'accord pour dire que l'écosystème Gtk+ recèle de vrais joyaux dont GStreamer (et sa documentation), raisons pour laquelle Nokia et Intel ne se désengagent pas totalement de GNOME Mobile. Mais ça ne doit pas empêcher de poursuivre la réflexion pour améliorer la cohérence et le polish de la pile logicielle associée à Gtk+.
Au niveau de la documentation, GStreamer fait plutôt figure de bon élève avec un manuel de référence.
> deb c-tout-libre-ça-pue, tandis que rpm a toutes les vertus que l'on trouve pour les boîtes qui font à la foi dans le libre et le proprio^W privateur.
Dirk Hohndel a invoqué cette excuse complétement bidon pour expliquer le changement de partenaire. La vraie raison était qu'Intel n'était pas satisfait du partenariat avec Canonical pour diverses raisons.
C'est du troll, dpkg et RPM se valent plus ou moins.
Quant aux mises à jour, l'actif de Nokia avec Maemo n'est pas très glorieux, donc ça ne change pas grand chose.
Est-ce que Nokia s'est fait bouffer ? Pas du tout, les intérêts d'Intel et de Nokia dans le domaine des OS mobiles basés sur Linux convergent surtout face à l'expansion d'Android.
Les deux plateformes ont de nombreux points communs: ils sont basés sur Linux, sur la plateforme GNOME Mobile, ciblent la même catégorie d'appareils communiquants (entre le téléphone et le netbook classique) etc ...
Face à Android, se cantonner à une seul architecture serait un handicap, de plus, la très grande majorité des composants des deux plateformes sont de facto portables. Le plus gros travail consiste dans le support matériel (100% libre chez Moblin, propriétaire chez Maemo) et dans l'IHM une domaine où Moblin autant que Maemo se cherchent (et où la mutualisation des efforts ne peut que leur bénéficier).
Vis à vis du support matériel, j'espère qu'ils reprendront la politique de Moblin plutôt que celle de Maemo.
Le choix de Qt est pertinent car il permet d'abaisser le ticket d'entrée avec un framework cohérent, extrêmement bien documenté et un outllage complet, le tout sur différentes plateformes. GNOME Mobile reste un assemblage de pièces éparses, avec une documentation et un support des plateformes inégales et assez peu d'outils. Même si MeeGo partage certaines briques avec GM (Telepathy, GStreamer, D-Bus, etc ...), les deux plateformes deviennent concurrentes là où Moblin et Maemo n'étaient que des variantes.
Parce que certains composants (notamment tout ce qui est gestion d'énergie) et pilotes de Maemo sont propriétaires et que l'architecture a évolué entre les différentes générations de tablettes.
Suffisamment génant pour emmerder le portage par la communauté.
> Mais n'était-ce pas trop tard? Je vois mal Nokia refaire un virage à 180° pour revenir à GTK/Clutter...
Si GM ne revoit pas rapidement sa copie, la plateforme va perdre très rapidement de son intérêt face à MeeGo ou bien même Android qui commence à sortir du marché des smartphones.
Nokia ne reviendra certainement pas en arrière, ils investissent derrière Symbian, Qt etc ... La perte de ses deux plus gros sponsors industriels n'est pas anodine.
> GTK est toujours là... mais bon, en lisant un peu plus loin: GTK and Clutter are also included for application compatibility.
Ils continueront à travailler sur les composants communs (GStreamer, Telepathy, D-Bus, matchbox, etc ...) mais le reste sera maintenu par la communauté, du moins le temps que la nouvelle plateforme basée sur Qt rattrape son retard.
Si on y regarde de plus près, MeeGoo se place en concurrent direct de GNOME Mobile là où Maemo n'était qu'une variante (Moblin un peu moins).
D'après le site de MeeGo, le toolkit de référence sera Qt. Si ça se confirme, ce serait une sacrée claque pour GNOME Mobile après la perte de Maemo. http://meego.com/developers/getting-started
La stratégie autour de Qt associé à la force de frappe de Nokia se révèle payante:
* un framework complet de qualité, et extensivement documenté
* des outils multiplateforme + QtCreator
* des certifications
* le changement de licence
* le marketing (1 société, des partenaires)
En comparaison, la plateforme GM est composé de briques éparses inégalement documentés, le support des différentes plateformes est inégal, pas de certifications, moins d'outils que Qt. Même si un travail a été fait à ce niveau, ça ne suffit pas à abaisser la barrière d'entrée pour la majorité des développeurs.
Ça montre l'importance d'un SDK et d'une documentation bien lếché. Pour démarrer avec Qt, je télécharge un SDK avec un framework complet, une documentation complète, des outils (qmake, linguist, designer) et même un IDE moderne, le tout sur différentes plateformes. Avec GNOME Mobile, il faut récupérer les différents composants, certains n'étant pas documentés, avec peu d'outils fournis (Glade, devhelp ?), avec une portabilité variable.
Même si ça correspond aux workflow traditionnel de l'embarqué, l'évolution du marché (smartphones, netbooks, tablets, etc ...) nécessite une démocratisation des outils.
C'est l'occasion pour GNOME (Mobile) de revoir en profondeur sa stratégie pour ne pas être largué.
> Une application qui fonctionne avec qt3support est une application qui fonctionne pour Qt4 donc je maintiens que c'est rapide de porter une application vers Qt4.
Feu Trolltech déconseillait d'utiliser qt3support en production, je crois même que c'est dans la doc.
> Je suis pas super à jour mais je crois que tu as raison. Il ne semble pas y avoir de solution idéale, car je peux pas dire que j'entende que des gens satisfaits du son côté Gnome.
On est d'accord sur le fait qu'il n'y a pas de solution parfaite, mais Phonon s'est révélé être plus problématique que d'utiliser GStreamer.
> Il suffirait (dixit le concepteur) de quelques heures de travail pour en faire une implémentation indépendante.
Le problème c'est que personne ne l'a fait ou proposé, c'est peut-être par manque de confiance envers fd.o. Quant D-Bus, l'implémentation de référence libdbus n'a aucune dépendance vis à vis de GObject, il existe même des bindings C++ indépendants de GObject dbus-cxx.
> Pour moi, ca reste un DCOP amélioré.
C'est une façon de voir les choses, mais dire que DBus c'est juste une réécriture de DCOP, c'est ignorer tout le travail qui a été fait en amont.
> En tout cas, j'appelle pas ça royalement ignorer.
On va dire que je vois le verre à moitié vide et toi à moitié plein.
> Je trouve ça particulièrement ironique quand on sait à quel point KDE s'est fait craché dessus quand ils ont osé utiliser DCOP plutôt que Corba lors du passage de KDE1 à KDE2.
Et tu as tout à fait raison ! Il y a eu de magnifiques bourdes dans GNOME aussi, pas que Bonobo qui a la vie dure ! Gnome-vfs c'était pas mal non plus niveau emmerdes.
> où le feedback de KDE a été complètement ignoré, et le dev Gnome en question a choisi volontairement des choix incompatible avec l'existant chez KDE.
C'est un vrai problème principalement dû à un rapport différent vis à vis de fd.o mais de la gestion des projets lui-même. Les développeurs KDE sont plus conservateurs vis à vis de leur plateforme que ne le sont les développeurs GNOME, chaque politique a ses avantages et ses inconvénients.
C'est là où KDE gagnerait à devenir une force de proposition sur fd.o, en démarrant la discussion en amont, ça éviterait bon nombre de situations similaires qui forcément n'encouragent pas les développeurs à s'investir dans fd.o.
> Pour ce qui est de PolicyKit, l'idée par exemple est bonne et a été adoptée par KDE à la place de KDESu si j'ai bien suivi. Mais peut-on reprocher à KDE de ne pas avoir proposer KDESu à Gnome en 1999 ?
Certainement pas, l'état de l'art en 1999 ne permettait pas d'avoir une solution correcte au problème de la gestion des droits sur le desktop.
> c'est juste que certains développeurs n'ont pas compris le concept de standard et se prennent pour Microsoft.
Je ne te contredirais pas à ce sujet, ce n'est pas les connards qui manquent dans GNOME, et ce ne sont pas toujours de "bons" connards.
> il y a eu tellement de fois où les efforts de coopération ont été ignorés que bcp de developpeurs de KDE ne font pas confiance à freedesktop au dela du minimum syndical
Il faut un travail de fond des deux côtés, apprendre à faire plus confiance à fd.o pour KDE, et d'être un peu plus à l'écoute des autres pour GNOME.
Il y a eu des progrès en ce sens, ne serait-ce que le Gran Canaria Desktop Summit commun de l'année dernière mais ça ne suffit pas.
Il y a des échecs de part et d'autres, mais au final ce que je veux retenir de KDE, c'est les belles réussites : KParts (ma techno préférée dans KDE), KHTML/WebKit, Plasma, et des applis très sympathiques comme KOffice, Kile, Kate ...
Sans oublier Qt4, le meilleur framework pour faire du développement multiplateforme à l'heure actuelle.
> Parceque pulseaudio c'est un franc succes acclame de facon unanime dans la sphere linux?
Ce n'est parce qu'une distribution n'a pas su intégrer correctement PA que ça ne marche pas ailleurs. PA est intégré dans Fedora depuis Fedora 8 et a toujours fonctionné correctement.
Depuis le début, Phonon ne supporte correctement qu'un seul backend : Xine (Xine qui évolue au ralenti depuis plus de cinq ans), mais plus personne ne maintient le backend GStreamer depuis près deux ans. Certes KDE recommande Xine, mais la plupart des distributions poussent GStreamer, soit dit en passant le seul framework multimédia viable pour les distributions libres.
Enfin, PA a l'avantage d'avoir un mainteneur disponible, pour Phonon, c'est plus aléatoire, pour Decibel et Solid, les rats ont quittés le navire depuis longtemps. Faudra un jour, m'expliquer l'intérêt d'avoir une couche d'abstraction (déjà basé sur d'autres couches d'abstractions) qui ne supportent correctement qu'un backend.
> Pour le coup de DBUS j'admire ta re-ecriture de l'histoire...
J'aimerais bien entendre ta version ...
L'équipe desktop de RH travaillait déjà sur DBus début 2003, et tu pourras le vérifier sur les m-l fd.o que les discussions sur un mécanisme d'IPC neutre avait commencé autour de cette époque.
Personne ne nie l'influence de DCOP dans DBus, mais ce n'est qu'une influence parmi d'autres, DBus s'inspire tout autant d'ICE sur lequel repose DCOP. Il avait même proposé de rebaser DCOP sur DBus au lieu d'ICE.
Fd.o a été créé par Havoc Pennington courant 2000, KDE avait largement eu le temps de proposer DCOP ou autre comme mécanisme IPC mais ils ont préférés continuer dans leur coin. De plus, ils ne sont associés que *très* tardivement à la conception de D-Bus alors qu'on les y a invités à de nombreuses reprises.
Venir après pleurnicher que GNOME impose ses technos (et en plus qu'ils prennent le temps de fournir une implémentation neutre pour pas léser les autres bureaux) qui soit-disant serait une reprise des technos KDE, si ce n'est pas de la mauvaise foi ...
# OpenCascade nunca fue liberado
Posté par GeneralZod . En réponse à la dépêche Utiliser HeeksCAD, c'est déjà possible ! Un Tutoriel sur Linuxgraphic rénové. Évalué à 5.
Raison pour laquelle, OpenCascade n'est pas distribué dans Fedora et que Debian la distribution dans non-free.
http://www.opencascade.org/getocc/license/
In short, Open CASCADE Technology Public License is LGPL-like with certain differences. You are permitted to use Open CASCADE Technology within commercial environments and you are obliged to acknowledge its use. You are also obliged to send your modifications of the original source code (if you have made any) to the Initial Developer (i.e. Open CASCADE S.A.S.). Complete text of the license is given below.
[^] # Re: CSS ou xhtml?
Posté par GeneralZod . En réponse au journal Les scrollbar de couleur sous IE c'est une histoire ancienne. Évalué à 4.
Un ancien de fedora-fr avait fait le même constat, il y a quelques années, voilà sa réponse:
http://xhtml-css.com
[^] # Re: Une certif de plus mais 'libre'
Posté par GeneralZod . En réponse à la dépêche Master Ingénierie du Logiciel Libre (I2L) : déjà 4 ans ... et l'aventure continue !. Évalué à 2.
Dans certains cas comme le développement d'API (bibliothèque, interface de plugins), la documentation est tout autant une bonne pratique que les tests unitaires (ou pas unitaires).
Savoir appréhender les outils de documentation en ligne (doxygen, javadoc, gtk-doc, docstrings, etc ...) doit être un pré-requis pour les développeurs.
D'autres problématiques tout aussi essentielles au métier de développeurs sont rarement ou très mal abordés: i18n (quasiment aucun cursus n'en parle), portabilité, conception/architecture, sécurité, déverminage, etc ...
[^] # Re: Petite erreur.
Posté par GeneralZod . En réponse au journal 8 mars. Évalué à 4.
On peut en dire autant de sa partenaire
> C'est plutôt l'inverse, à lui de prouver qu'il a explicitement affirmé ne pas vouloir de cet enfant.
Si tu pars du postulat qu'il en veut bien, tu peux difficilement lui nier derrière, le droit de participer au processus d'avortement. Responsabiliser le père, ça ne se limite pas à lui rajouter des devoirs, mais également à lui donner dans une certaine mesure des droits.
On peut tout à fait protéger les droits des femmes sans pour autant nier le droit des pères comme c'est le cas actuellement.
Dans le cadre de la législation actuelle, la mère a tout les droits y compris d'extorquer une pension alimentaire alors que le père ne peut que fermer sa gueule.
[^] # Re: Petite erreur.
Posté par GeneralZod . En réponse au journal 8 mars. Évalué à 5.
Je suis tout à fait d'accord sur le fait que la décision finale appartient à la mère, mais le père a le droit de savoir et d'exprimer son point de vue.
La contrepartie du droit à l'avortement serait le droit du père à ne pas assumer un enfant sauf si il en a exprimé la volonté d'une façon ou d'une autre.
[^] # Re: On voit le bout du tunnel
Posté par GeneralZod . En réponse à la dépêche Du côté de chez Xorg. Évalué à 3.
Mieux encore, il n'y a pas de contradiction entre les demandes des libristes et la réalité économique, puisque la libération de la documentation ou du pilote ne porte pas atteinte au business de nVidia (vendre des processeurs graphiques, pas des pilotes).
[^] # Re: On voit le bout du tunnel
Posté par GeneralZod . En réponse à la dépêche Du côté de chez Xorg. Évalué à 7.
Moi non, mais j'ai déjà eu à réparer les dégâts de nVidia chez d'autres. Et ce n'est parce que tu as un cas sur cent que tu ne dois pas t'en préoccuper, surtout si tu es empaqueteur ou que tu fais du support.
> Quels batons dans les roues ? Nvidia ne les aide pas mais ne les empechent pas non plus de continuer leur projet.
Ils ne leur filent pas de la documentation, pas de matos, ni même répondent à leurs questions. La seule chose qu'ils ne font pas c'est de leur coller un procès au cul.
> Tu as un exemple de carte graphique mainstream qui as des pilotes libres plus performants ?
Suffit de comparer les ATI supporté par radeon et fglrx, mis à part quelques fonctionnalités annexes, fglrx est à la ramasse. La documentation libérée par AMD a permis de redonner une seconde jeunesse à radeon.
> Nvidia n'a pas de mal a suivre l'evolution de xorg, leurs pilotes fonctionnent bien sur le dernier serveur sorti.
Certes, si ta distribution reste bloquée sur le dernier X server supporté par nVidia, tu ne risques pas de t'en rendre compte. nVidia tiens un bon rythme mais il y a souvent un décalage de quelques mois entre la sortie du dernier Xorg et son support dans leur pilote.
Parfois, il faut même un bon vieux patch binaire pour que ça fonctionne.
> Vive la paranoia et le FUD, tu m'expliques en quoi le fait de remplacer du code de xorg par leur version rend un client qui utilise leurs cartes captif ? Tant que l'api utilisée par les programmes reste la même ca ne change rien.
Déjà, ils s'amusent à écraser la libGLX fournie par le système, ça ne facilite pas la tâche des développeurs faisant usage de la CG (par exemple, les bureaux composites), etc ...
Sans oublier, l'abandon régulier du support des anciennes cartes, ce qui fait qu'on doit maintenir en parrallèle plusieurs versions du pilotes jusqu'à ce que ça ne marche plus.
Tout est fait pour que le client soit enfermé et change régulièrement son matériel (de préférence du nVidia), que ce soit le simple particulier, le power user ou bien le développeur.
Quel est l'intérêt pour nVidia de redévelopper ce qui existe déjà dans Xorg ? techniquement, ça leur apporte que dalle aujourd'hui, juste des emmerdes.
> Je viens de relire ton post et c'est marrant parce qu'en fait en fait tout ce que tu as marque me fait penser a ce qu'on appelle du FUD.
C'est drôle, je m'étais dit exactement la même chose de ton précédent post/
[^] # Re: On voit le bout du tunnel
Posté par GeneralZod . En réponse à la dépêche Du côté de chez Xorg. Évalué à 9.
> ca marche soit aussi bien, soit beaucoup beaucoup moins bien
Le support des GPU intel est très bon sous les Unix libres et celui des ATI s'améliore régulièrement. Quand les développeurs ont accès aux spécifications, les pilotes libres sont souvent bien meilleurs que leurs équivalents propriétaires.
Je tire mon chapeau aux développeurs de Nouveau pour leur excellent travail malgré les batons que nVidia leur mets dans les roues et le peu de soutien qu'ils reçoivent de la communauté.
> Et tout ca parce que X change d'API et rajoute des nouvelles extensions tout les 4 matins parce que les anciennes sont trop mal foutues pour evoluer proprement.
Tu suis l'évolution de Xorg à travers les newsletter des commerciaux de nVidia ou quoi ?
Si nVidia ne s'amusait pas à redévelopper les extensions standards de Xorg (ils ont leur propre GLX, leur propre gestion des écrans multiples, ils n'utilisent pas DRI, KMS, etc ...), ils auraient beaucoup moins de mal à suivre l'évolution de Xorg.
La raison pour laquelle, ils dupliquent une bonne partie de l'infrastructure de Xorg, ce n'est pas parce que Xorg c'est de la merde et blablabla, l'objectif c'est d'enfermer le client.
Va demander aux personnes qui font des paquets pour la bouse de nVidia pour savoir à quel point c'est mal foutu leur tas de merde.
Les changements d'API sont un faux problème, sinon faudra m'expliquer comment le noyau Linux arrive à maintenir autant de pilotes à jour.
Sauf à vouloir maintenir une architecture sub-optimale, avec une multitude de couches de compatibilité, il est quasiment impossible d'éviter les changements d'API dans un composant aussi complexe que X. nVidia n'a qu'à libérer son pilote ou les spécifications si ça les fait chier.
> La question qu'il faudrait se poser c'est comment ameliorer X (au niveau architecture) et comment ameliorer le process de dev (pour pas devoir tout refaire dans 2 ans parce qu'on a merde sur l'API).
T'as six ans de retard, si tu rajoutes le changement de licence de XFree86, ces questions-là sont à l'origine de Xorg. Même si il reste du travail à faire, Xorg avance et avance dans le bon sens.
[^] # Re: Zaphod ? beurk
Posté par GeneralZod . En réponse à la dépêche Du côté de chez Xorg. Évalué à 4.
[^] # Re: jusqu'au jour où....
Posté par GeneralZod . En réponse au journal Ubuntu 10.4 supportera en natif l'iPhone et l'Ipod-touch. Évalué à 9.
Perso, j'espère beaucoup de MeeGo, sous l'égide de la Linux Foundation, il devrait suivre la même politique de licence que feu Moblin (pas de pilotes de merde propriétaires) avec un environnement beaucoup moins restreint qu'Android pour les développeurs.
Avec l'appui et le savoir-faire de Nokia et Intel, on devrait voir arriver des smartphones beaucoup plus sympathiques que les droids actuels.
[1] http://www.kroah.com/log/linux/android-kernel-problems.html
[^] # Re: Pardon ?
Posté par GeneralZod . En réponse au journal Ubuntu 10.4 supportera en natif l'iPhone et l'Ipod-touch. Évalué à 10.
+1 pour Christophe Fergeau qui fait du très bon boulot dans libgpod (et également dans GNOME).
[1] même si on ne suit pas l'avancée des divers projets, il faut deux minutes pour trouver la référence à usbmuxd (donc à Marcan etc ...) à l'aide d'un moteur de recherche.
> Espérons que ces librairies pour le moment principalement compatibles avec Fedora et Ubuntu seront bientot opérationnelles sur les autres distributions Linux.
Rien de bien compliqué, suffit de configurer vite fait udev, d'avoir usbmuxd, la bonne version de libgpod etc ...
http://blog.fedora-fr.org/bigorre65/post/Synchroniser-un-iPh(...)
Le commentaire original avant d'être tronqué, précisait que le support serait fournis dans la plupart des versions prochaines des distros majeures, pas seulement Ubuntu et Fedora.
Ubuntu ne prends aucune avance et ça démontre une fois de plus que Canonical/Ubuntu sont des suiveurs, pas des leaders.
[^] # Re: orc ou liboil ?
Posté par GeneralZod . En réponse à la dépêche Schrödinger 1.0.9 est sorti. Évalué à 5.
http://www.schleef.org/blog/category/liboil/
# reStructuredText
Posté par GeneralZod . En réponse au message Cherche logiciel de publication de document. Évalué à 3.
Pour la génération de pdf, sphinx génére du latex intermédiaire donc au niveau de la typographie, ça devrait aller bien qu'il soit possible d'utiliser le backend rst2pdf pour générer directement le pdf.
http://docutils.sourceforge.net/rst.html
[^] # Re: Matplotlib?
Posté par GeneralZod . En réponse au journal Pymecavideo devient multiplateforme. Évalué à 4.
C'est un problème de packaging, il faut taper sur le mainteneur de python-matplotlib dans ta distribution pour qu'il sépare les différents backends de matplotlib dans des sous-paquets.
De mémoire, tu n'as pas besoin de WxWidgets pour que matplotlib fonctionne par exemple.
[^] # Re: RPM & DEB
Posté par GeneralZod . En réponse à la dépêche Intel et Nokia annoncent la création de MeeGo. Évalué à 1.
Vu le nombre de contributeurs à GNOME Mobile, c'est totalement irréaliste et ça aurait pris des années pour que Nokia arrive à obtenir un minimum de contrôle sur les différents projets.
Pour Nokia, il était nettement plus simple de racheter Trolltech: le framework est maitrisé par UNE société, les compétences sont déjà rassemblés, le multiplateforme est un acquis etc ...
> Ça leur aurais même sans doute coûté moins cher que le rachat de Trolltech, + le changement complet de leurs platforme.
C'est quoi la plateforme de Nokia ? Maemo ? un OS qui n'est jamais sorti du marché de niches des tablettes internet jusqu'au N900 ? Symbian ? un OS qui n'a jamais eu un grand succès auprès des développeur à juste titre ? Windows Mobile ? etc ... Nokia supporte plusieurs plateformes, et le switch vers Qt pour Maemo ne signifie pas la remise en cause des couches basses, Nokia continue à investir dans GNOME Mobile, la première chose qu'ils ont fait après avoir racheté Trolltech, c'est d'avoir mis au placard Qtopia.
Face à la poussée de l'iPhone et d'Android, Nokia devait agir rapidement et prendre en compte le choix de supporter plusieurs plateformes (Maemo, Symbian, Windows Mobile). Si on prends la dimension temps en compte, c'était un choix très judicieux.
> Trolltech a été acquis car Qt était une meilleur alternative.
Un troll qui trolle :-]
Sans rentrer dans le débat Qt vs Gtk+ (chacun à ses qualités et défauts), Qt4 est le meilleur framework multiplateforme sur le marché (documentation, support, outillage etc ...).
[^] # Re: Le slogan
Posté par GeneralZod . En réponse à la dépêche Cairo-Dock 2.1.3-3 est sorti. Évalué à 2.
La citation en question se référe évidemment à la définition de l'OSI mais il existe des logiciels à code ouvert non englobé dans l'open source
> Et concrètement tu as un exemple de logiciel open source non libre ?
Unix, Gosling Emacs étaient à l'origine open source mais pas libres, tu as actuellement SystemC, des logiciels privateurs mettant tout ou partie de leur code en "open-source" ce n'est pas ça qui manque (wince par exemple est un parfait exemple)
Certaines licences explicitement reconnues non libres par la FSF et open source par l'OSI: APSL v1.x, NASA Open Source Agreement, Reciprocal Public License
[^] # Re: Le slogan
Posté par GeneralZod . En réponse à la dépêche Cairo-Dock 2.1.3-3 est sorti. Évalué à 8.
Un logiciel libre est par définition open source, mais l'inverse n'est pas forcément vrai.
[^] # Re: RPM & DEB
Posté par GeneralZod . En réponse à la dépêche Intel et Nokia annoncent la création de MeeGo. Évalué à 2.
Certes, reste que Nokia et Intel (après le rachat d'OpenedHand) étaient des acteurs majeurs derrière GNOME Mobile. Pour Nokia, il était plus simple de racheter Trolltech pour modeler Qt selon ses besoins que GNOME Mobile.
> elle est peut-être inégale pour les outils GNOME, mais on trouve aussi de l'excellent : je pense à la doc de GStreamer.
Tout à fait d'accord pour dire que l'écosystème Gtk+ recèle de vrais joyaux dont GStreamer (et sa documentation), raisons pour laquelle Nokia et Intel ne se désengagent pas totalement de GNOME Mobile. Mais ça ne doit pas empêcher de poursuivre la réflexion pour améliorer la cohérence et le polish de la pile logicielle associée à Gtk+.
Au niveau de la documentation, GStreamer fait plutôt figure de bon élève avec un manuel de référence.
> deb c-tout-libre-ça-pue, tandis que rpm a toutes les vertus que l'on trouve pour les boîtes qui font à la foi dans le libre et le proprio^W privateur.
Dirk Hohndel a invoqué cette excuse complétement bidon pour expliquer le changement de partenaire. La vraie raison était qu'Intel n'était pas satisfait du partenariat avec Canonical pour diverses raisons.
[^] # Re: RPM & DEB
Posté par GeneralZod . En réponse à la dépêche Intel et Nokia annoncent la création de MeeGo. Évalué à 9.
Quant aux mises à jour, l'actif de Nokia avec Maemo n'est pas très glorieux, donc ça ne change pas grand chose.
Est-ce que Nokia s'est fait bouffer ? Pas du tout, les intérêts d'Intel et de Nokia dans le domaine des OS mobiles basés sur Linux convergent surtout face à l'expansion d'Android.
Les deux plateformes ont de nombreux points communs: ils sont basés sur Linux, sur la plateforme GNOME Mobile, ciblent la même catégorie d'appareils communiquants (entre le téléphone et le netbook classique) etc ...
Face à Android, se cantonner à une seul architecture serait un handicap, de plus, la très grande majorité des composants des deux plateformes sont de facto portables. Le plus gros travail consiste dans le support matériel (100% libre chez Moblin, propriétaire chez Maemo) et dans l'IHM une domaine où Moblin autant que Maemo se cherchent (et où la mutualisation des efforts ne peut que leur bénéficier).
Vis à vis du support matériel, j'espère qu'ils reprendront la politique de Moblin plutôt que celle de Maemo.
Le choix de Qt est pertinent car il permet d'abaisser le ticket d'entrée avec un framework cohérent, extrêmement bien documenté et un outllage complet, le tout sur différentes plateformes. GNOME Mobile reste un assemblage de pièces éparses, avec une documentation et un support des plateformes inégales et assez peu d'outils. Même si MeeGo partage certaines briques avec GM (Telepathy, GStreamer, D-Bus, etc ...), les deux plateformes deviennent concurrentes là où Moblin et Maemo n'étaient que des variantes.
[^] # Re: Utilisateur de N900...
Posté par GeneralZod . En réponse au journal Intel et Nokia s'associe pour créer MeeGo. Évalué à 6.
Suffisamment génant pour emmerder le portage par la communauté.
[^] # Re: GNOME Mobile ?
Posté par GeneralZod . En réponse au journal Intel et Nokia s'associe pour créer MeeGo. Évalué à 4.
Si GM ne revoit pas rapidement sa copie, la plateforme va perdre très rapidement de son intérêt face à MeeGo ou bien même Android qui commence à sortir du marché des smartphones.
Nokia ne reviendra certainement pas en arrière, ils investissent derrière Symbian, Qt etc ... La perte de ses deux plus gros sponsors industriels n'est pas anodine.
> GTK est toujours là... mais bon, en lisant un peu plus loin: GTK and Clutter are also included for application compatibility.
Ils continueront à travailler sur les composants communs (GStreamer, Telepathy, D-Bus, matchbox, etc ...) mais le reste sera maintenu par la communauté, du moins le temps que la nouvelle plateforme basée sur Qt rattrape son retard.
Si on y regarde de plus près, MeeGoo se place en concurrent direct de GNOME Mobile là où Maemo n'était qu'une variante (Moblin un peu moins).
# GNOME Mobile ?
Posté par GeneralZod . En réponse au journal Intel et Nokia s'associe pour créer MeeGo. Évalué à 10.
http://meego.com/developers/getting-started
La stratégie autour de Qt associé à la force de frappe de Nokia se révèle payante:
* un framework complet de qualité, et extensivement documenté
* des outils multiplateforme + QtCreator
* des certifications
* le changement de licence
* le marketing (1 société, des partenaires)
En comparaison, la plateforme GM est composé de briques éparses inégalement documentés, le support des différentes plateformes est inégal, pas de certifications, moins d'outils que Qt. Même si un travail a été fait à ce niveau, ça ne suffit pas à abaisser la barrière d'entrée pour la majorité des développeurs.
Ça montre l'importance d'un SDK et d'une documentation bien lếché. Pour démarrer avec Qt, je télécharge un SDK avec un framework complet, une documentation complète, des outils (qmake, linguist, designer) et même un IDE moderne, le tout sur différentes plateformes. Avec GNOME Mobile, il faut récupérer les différents composants, certains n'étant pas documentés, avec peu d'outils fournis (Glade, devhelp ?), avec une portabilité variable.
Même si ça correspond aux workflow traditionnel de l'embarqué, l'évolution du marché (smartphones, netbooks, tablets, etc ...) nécessite une démocratisation des outils.
C'est l'occasion pour GNOME (Mobile) de revoir en profondeur sa stratégie pour ne pas être largué.
[^] # Re: Magazine de qualité
Posté par GeneralZod . En réponse au journal L’informatique a-t-elle un sexe ?. Évalué à 6.
[^] # Re: migration?
Posté par GeneralZod . En réponse à la dépêche Accessibilité: Oracle prend Sun mais se débarrasse de Willie Walker. Évalué à 5.
Feu Trolltech déconseillait d'utiliser qt3support en production, je crois même que c'est dans la doc.
> Je suis pas super à jour mais je crois que tu as raison. Il ne semble pas y avoir de solution idéale, car je peux pas dire que j'entende que des gens satisfaits du son côté Gnome.
On est d'accord sur le fait qu'il n'y a pas de solution parfaite, mais Phonon s'est révélé être plus problématique que d'utiliser GStreamer.
> Il suffirait (dixit le concepteur) de quelques heures de travail pour en faire une implémentation indépendante.
Le problème c'est que personne ne l'a fait ou proposé, c'est peut-être par manque de confiance envers fd.o. Quant D-Bus, l'implémentation de référence libdbus n'a aucune dépendance vis à vis de GObject, il existe même des bindings C++ indépendants de GObject dbus-cxx.
> Pour moi, ca reste un DCOP amélioré.
C'est une façon de voir les choses, mais dire que DBus c'est juste une réécriture de DCOP, c'est ignorer tout le travail qui a été fait en amont.
> En tout cas, j'appelle pas ça royalement ignorer.
On va dire que je vois le verre à moitié vide et toi à moitié plein.
> Je trouve ça particulièrement ironique quand on sait à quel point KDE s'est fait craché dessus quand ils ont osé utiliser DCOP plutôt que Corba lors du passage de KDE1 à KDE2.
Et tu as tout à fait raison ! Il y a eu de magnifiques bourdes dans GNOME aussi, pas que Bonobo qui a la vie dure ! Gnome-vfs c'était pas mal non plus niveau emmerdes.
> où le feedback de KDE a été complètement ignoré, et le dev Gnome en question a choisi volontairement des choix incompatible avec l'existant chez KDE.
C'est un vrai problème principalement dû à un rapport différent vis à vis de fd.o mais de la gestion des projets lui-même. Les développeurs KDE sont plus conservateurs vis à vis de leur plateforme que ne le sont les développeurs GNOME, chaque politique a ses avantages et ses inconvénients.
C'est là où KDE gagnerait à devenir une force de proposition sur fd.o, en démarrant la discussion en amont, ça éviterait bon nombre de situations similaires qui forcément n'encouragent pas les développeurs à s'investir dans fd.o.
> Pour ce qui est de PolicyKit, l'idée par exemple est bonne et a été adoptée par KDE à la place de KDESu si j'ai bien suivi. Mais peut-on reprocher à KDE de ne pas avoir proposer KDESu à Gnome en 1999 ?
Certainement pas, l'état de l'art en 1999 ne permettait pas d'avoir une solution correcte au problème de la gestion des droits sur le desktop.
> c'est juste que certains développeurs n'ont pas compris le concept de standard et se prennent pour Microsoft.
Je ne te contredirais pas à ce sujet, ce n'est pas les connards qui manquent dans GNOME, et ce ne sont pas toujours de "bons" connards.
> il y a eu tellement de fois où les efforts de coopération ont été ignorés que bcp de developpeurs de KDE ne font pas confiance à freedesktop au dela du minimum syndical
Il faut un travail de fond des deux côtés, apprendre à faire plus confiance à fd.o pour KDE, et d'être un peu plus à l'écoute des autres pour GNOME.
Il y a eu des progrès en ce sens, ne serait-ce que le Gran Canaria Desktop Summit commun de l'année dernière mais ça ne suffit pas.
Il y a des échecs de part et d'autres, mais au final ce que je veux retenir de KDE, c'est les belles réussites : KParts (ma techno préférée dans KDE), KHTML/WebKit, Plasma, et des applis très sympathiques comme KOffice, Kile, Kate ...
Sans oublier Qt4, le meilleur framework pour faire du développement multiplateforme à l'heure actuelle.
[^] # Re: migration?
Posté par GeneralZod . En réponse à la dépêche Accessibilité: Oracle prend Sun mais se débarrasse de Willie Walker. Évalué à 3.
Ce n'est parce qu'une distribution n'a pas su intégrer correctement PA que ça ne marche pas ailleurs. PA est intégré dans Fedora depuis Fedora 8 et a toujours fonctionné correctement.
Depuis le début, Phonon ne supporte correctement qu'un seul backend : Xine (Xine qui évolue au ralenti depuis plus de cinq ans), mais plus personne ne maintient le backend GStreamer depuis près deux ans. Certes KDE recommande Xine, mais la plupart des distributions poussent GStreamer, soit dit en passant le seul framework multimédia viable pour les distributions libres.
Enfin, PA a l'avantage d'avoir un mainteneur disponible, pour Phonon, c'est plus aléatoire, pour Decibel et Solid, les rats ont quittés le navire depuis longtemps. Faudra un jour, m'expliquer l'intérêt d'avoir une couche d'abstraction (déjà basé sur d'autres couches d'abstractions) qui ne supportent correctement qu'un backend.
> Pour le coup de DBUS j'admire ta re-ecriture de l'histoire...
J'aimerais bien entendre ta version ...
L'équipe desktop de RH travaillait déjà sur DBus début 2003, et tu pourras le vérifier sur les m-l fd.o que les discussions sur un mécanisme d'IPC neutre avait commencé autour de cette époque.
Personne ne nie l'influence de DCOP dans DBus, mais ce n'est qu'une influence parmi d'autres, DBus s'inspire tout autant d'ICE sur lequel repose DCOP. Il avait même proposé de rebaser DCOP sur DBus au lieu d'ICE.
Fd.o a été créé par Havoc Pennington courant 2000, KDE avait largement eu le temps de proposer DCOP ou autre comme mécanisme IPC mais ils ont préférés continuer dans leur coin. De plus, ils ne sont associés que *très* tardivement à la conception de D-Bus alors qu'on les y a invités à de nombreuses reprises.
Venir après pleurnicher que GNOME impose ses technos (et en plus qu'ils prennent le temps de fournir une implémentation neutre pour pas léser les autres bureaux) qui soit-disant serait une reprise des technos KDE, si ce n'est pas de la mauvaise foi ...