> Qt4 a cassé la compatibilité source avec Qt3 mais ce n'est pas une rupture totale
Tu as des pans entiers de Qt4 qui n'ont pas d'équivalents dans Qt3 ou qui ont été complétement réécrits. Le portage de Qt3 vers Qt4 n'a rien de trivial, il a fallu rajouter un module de compatibilité qt3support pour faciliter le portage.
En comparaison, Qt3 apportait par rapport à Qt2 un meilleur support de l'unicode, de l'i18n et un peu de toilettage pour virer les modules dépréciés.
Je t'accorde que la tournure peut prêter à confusion, les principes de bases de Qt n'ont pas variés (QObject, le système signal-slots, etc ...) mais on ne passe pas de Qt3 à Qt4 comme ça.
> c'est donc un choix responsable de KDE d'avoir refondu les fondations et non quelque chose qui aurait été imposé par les changements de Qt.
C'était le seul choix sensé surtout ! Là où le passage de Qt2 -> Qt3 ne demandait finalement que quelques petites retouches, Qt4 imposait de réécrire une bonne partie de KDE4 et de s'appuyer sur la rustine qt3support. C'était soit casser la compatibilité, soit construire un monstre de frankenstein.
> KDE a choisi d'abstraire totalement la couche son de façon à pouvoir gérer facilement plusieurs démons sonores au choix. Cela a donné phonon.
Le reméde s'est révélé être pire que le mal qu'il était sensé combattre. Parce que le support des différents moteurs multimédias dans Phonon est une catastrophe, de fait, KDE ne maintient que le backend Xine, le backend GStreamer et Quicktime à l'origine maintenu par Nokia n'évolue plus du tout. http://www.mail-archive.com/fedora-devel-list@redhat.com/msg(...) http://www.mail-archive.com/fedora-devel-list@redhat.com/msg(...)
Parmi les différentes couches d'abstraction développés pour KDE4, Phonon fait figure de bon élèves pour dire le peu d'activité autour de Solid ou Decibel.
> Note au passage que les gens de gstreamer n'ayant pas à coeur de conserver la compatiblité binaire entre des releases, phonon est nécessaire même pour l'intégration de gstreamer dans KDE
Tu m'expliqueras comment GNOME fait alors ...
GStreamer 0.10.x est apparu fin 2005 et pas de changement majeur à l'horizon, la suite a donné raison aux développeurs de GStreamer. Entre temps, à l'exception du sous-ensemble figé dans Qt, l'API de Phonon a plus souvent changé que celle de GStreamer.
> Owen Taylor a commencé à pousser un protocole de communication de bureau commun à KDE et à Gnome, inspiré de DCOP
L'idée est de concevoir un mécanisme d'IPC desktop-agnostic, DBus est plus bas niveau que DCOP. DCOP n'était pas utilisable dans un contexte autre que KDE. DBus a été une remise à plat en prenant compte de l'existant (ICE, Corba, SOAP, etc ...) et en tenant compte des échecs passés comme Bonobo. DBus n'est pas qu'une simple copie améliorée de DCOP.
> La grande force de DBUS, c'est de ne pas apparaitre comme une techno KDE mais une techno neutre, poussée par Red Hat.
J'admire comment les KDE-istes s'approprient DBus alors qu'ils l'ont royalement ignorés pendant plusieurs années.
Les développeurs GNOME ont au moins le mérite de reconnaitre quand ils ont foirés et d'essayer de proposer des solutions neutres.
> Encore une affirmation tout à fait erronée. Abonne toi à la liste xdg et tu verras que les développeurs KDE sont tout autant présent que les développeurs Gnome, et que l'interopérabilité est un souci présent des deux côtés.
J'ai dit qu'ils étaient rares, pas absents et FreeDesktop ne se limite pas à XDG. Et il est encore plus rare qu'ils soient force de proposition.
Dans l'exemple DBus, KDE a été invité à participer à sa conception mais ils ne l'ont pas fait, ils se sont juste contenté de le reprendre quand ils ont vu que c'était une meilleure alternative que DCOP.
> On peut seulement regretter que une partie des développeurs Gnome voient l'interopérabilité comme « je pousse une techno Gnome sur xdg en la déclarant un standard ».
Quand il existe une problématique autour de l'interopérabilité, la première réaction du développeur KDE c'est de chercher si une solution "standard" existe sinon redévelopper une solution KDE-only sans se soucier des autres. Le développeur GNOME ira d'abord démarrer une discussion sur FreeDesktop *puis* commencera à développer une solution neutre (et une surcouche pour l'intégrer à GNOME) ==> DBus, libcanberra, xdg, PackageKit, ConsoleKit, PolicyKit sont nés comme ça.
FreeDesktop a été créé comme un espace de discussion entre les implémenteurs de bureaux, force est de constater que le réflexe, "je rencontre une problématique, j'en discute sur FreeDesktop avant de commencer quelque chose" n'existe pas chez les développeurs KDE.
Ça ne veut pas dire que les développeurs KDE s'en branlent de l'interopérabilité mais qu'ils devraient être plus proactifs sur FreeDesktop.
Le « je pousse une techno Gnome sur xdg en la déclarant un standard » n'est qu'un fantasme des KDE-istes, la plupart du temps, la discussion/conception sur la techno se fait en amont sur FreeDesktop et non pas à posteriori. Après faut pas venir se plaindre que les méchants développeurs GNOME imposent leurs technos si personne de chez KDE ne daigne participer en amont.
> T'es sur de toi là? Je crois que gstreamer et pulseaudio sont bien plus que des couches d'abstraction
Par nature, un serveur son est une couche d'abstraction, quant à GStreamer, de par son architecture, il peut être appelé à l'être (GStreamer ne réinvente pas la roue sur les autres OS non plus, il fait appel aux APIs natives).
> Ensuite D-Bus, HAL, DeviceKit viennent de freedesktop. C'est mal de les utiliser?
Tu peux également rajouter GStreamer, Telepathy, PolicyKit, ConsoleKit dans la liste. Est-ce mal de les utiliser ? absolument pas !
Je répondais à un commentaire prétendant que les développeurs GNOME n'ont rien branlés ces dernières années alors que la plupart de ses technologies ont été initiés ou maintenu au sein de la communauté GNOME. C'est pas un mystère que les développeurs KDE se font rares sur FreeDesktop.
Contrairement à Qt3, Qt4 a été une rupture totale par rapport à son prédécesseur, KDE n'a eu d'autres choix que de revoir les fondations. Pendant longtemps, le boulot de KDE a été de réécrire ce qui existait déjà.
GNOME n'a pas été obligé de se réinventer, la plupart des changements se sont fait sous le capot. GNOME3 sera dans la continuité de son prédécesseur, la différence, c'est qu'on ne se souciera plus de la compatibilité descendante. La plupart des nouveaux composants de GNOME3 tournent sans problèmes sur GNOME2.
> Et networkmanager est indépendant de l'os, que je sache. Gnome à été le premier à bénéficier d'une interface graphique certes.
NM est maintenu par un seul type employé par Red Hat, le service a été conçu pour être desktop-agnostic mais il repose sur la GLib.
> Bravo: c'est exactement ça. kde est un projet d'environnement de bureau, pas un os complet
Dans la pratique, les couches d'abstractions posent plus de problèmes qu'elles n'en règlent, Solid est en train de couler et n'a jamais tenu ses promesses de multiplateformes, les backends de Phonon ne sont pas égaux surtout depuis que Nokia ne s'investit plus dedans (le backend GStreamer est complétement moisi par exemple).
Ironiquement, ces couches d'asbtractions ont été développés pour éviter de se retrouver dans la même situation qu'avec arts (qui n'était plus maintenu pendant des années) et au final, à l'exception de Phonon qui vivote tant bien que mal, elles sont toutes quasiment abandonnées que ce soit Decibel ou Solid.
Reste que KDE4 a de beaux succès à son actif comme Plasma.
Pas à ma connaissance, il a quitté Sun quelques temps après le rachat de MySQL. Il était lead developer Postgres pour Sun, maintenant, il dirige sa propre société.
C'est quoi les dépendances farfelues de virt-manager ?
Parce qu'à part libvirt et les bindings python, le reste des dépendances n'a rien d'extravagant même pour une Debian stable. http://virt-manager.et.redhat.com/download.html
Si tu prends en compte les dix points listés par Josh Berkus, tu verras que libvirt et les projets associés n'en respectent pas un seul.
La principale utilité des triggers et des procédures stockées, c'est de faire de la validation de données pour garantir que ta base ne puisse pas se retrouver dans un état incohérent. Ce n'est plus à la partie applicative d'appliquer les contraintes d'intégrité mais ça relève directement du SGBD. Ça permet de faire des trucs un peu plus chiadés que les contraintes SQL de bases.
===> ça évite de se retrouver avec une base incohérente à cause d'un bogue dans le client ou d'un crétin qui a fait une requête foireuse.
Les autres utilisations couvrent l'encapsulation de la logique métier donc moins de traitements à faire côté client, améliorer les performances en réduisant les échanges, néanmoins ça a un coût côté serveur. Mais également logguer, faire de la réplication, gérer plus finement les accès.
Postgres a un support très complet des triggers et procédures stockés que l'on peut écrire en PL/pgSQL (un langage de programmation inspiré du PL/SQL d'Oracle) ou en Python, Perl, etc ...
MySQL a un support assez récent et relativement pauvre comparé à Postgres, mais suffisant pour la plupart des cas d'utilisations.
Pour de l'optimisation pure, tu as d'autres leviers à ta disposition à commencer par une bonne conception et l'implantation. Et ne jamais oublier que tout se paie avec un SGBD !
> c'est une technologie venue et poussée par Kde (DCOP).
N'importe quoi. Pour ta gouverne, DBus s'est inspiré entre autre de DCOP mais également d'ICE sur lequel reposait déjà DCOP.
DBus a été écrit et conçu from scratch, en se basant sur l'expérience acquise avec Corba et selon un cahier des charges bien défini et ce sans le concours des développeurs KDE comme tu le prétends. DBus est plus bas niveau que DCOP (il avait été proposé de remplacer ICE par DBus un moment dans DCOP), mais également neutre (contrairement à DCOP).
> Je crois tout aussi bien que Phonon et Solid sont fouareux comme exemples car ce sont des couches d'abstraction pour porter Kde sur d'autres systèmes ce que GNOME n'a pas décidé de faire.
Phonon est une couche d'abstraction multimédia, mais c'est également le cas de GStreamer ou PA ... Quant à Solid, le projet bat de l'aile depuis un moment, seul le backend Linux est fonctionnel. Celui-ci repose principalement sur D-Bus, HAL, DeviceKit, NM, Bluez ...
Quel est l'intérêt d'avoir un bureau KDE sous Windows ? Ralentir encore plus ta machine ? L'objectif c'est de permettre de faire tourner les applications KDE, et même dans ce domaine, l'avance de KDE est bien maigre malgré un portage de Qt4 bien meilleur !
C'est bien joli de faire des couches d'abstraction reposant elle-même sur des couches d'abstraction mais les fonctionnalités sous-jacentes vont pas se coder toutes seules. Parce que sans GStreamer, PA, NM, DeviceKit, Telepathy, Bluez etc ... que deviennent les couches d'abstraction de KDE ? de belles coquilles vides.
> Google genere des revenus importants, la Mofo en profite, mais generer des revenus par ses produits ? Je n'ai vu ca nulle part.
Google émunère un service rendu : le choix de Google comme moteur de recherche par défaut dans Firefox, et proportionnellement à chaque clic sur une publicité apparaissant sur les pages générées par les recherches. Google ne joue pas aux mécénes avec la MoFo. L'accord a été renouvelé et court jusqu'à 2011 et certains moteurs de recherche sont prêts à prendre le relai (y compris Microsoft).
Selon toi, les publicitaires ne générent pas de revenus mais profite des revenus des industriels ?
> Comme pour la MoFo et Google ?
L'accord avec Google représente environ 85% des revenus de la MoFo. Certes, il y a une dépendance financière vis à vis de Google, mais elle est à tempérer à plusieurs titres, d'autres sont prêts à prendre le relai, l'accord est également profitable à Google. Ça signifie également que la MoFo est capable de générer 15% à 20 % de ses revenus actuels sans l'apport de Google.
Ça paraît peu mais c'est oublier la manne financière que représente l'accord avec Google, du jour au lendemain, la MoFo a vu ses revenus augmenter de façon exponentielle.
Est-ce que la MoFo peut vivre sans Google ? la MoFo l'a fait pendant près de dix ans, la perte des revenus provenant de Google ralentirait très certainement son activité pendant un moment mais sans plus.
> c'est écrit où dans la loi que chaque fichier source doit contenir une en-tête avec la licence ?
L'insertion d'un entête rappelant la licence et le copyright pour chaque fichier est une pratique vivement recommandée. C'est pas comme si il n'y avait pas eu de précédents judiciaires dont le célèbre USL vs BSDi.
> Ce que j'avais compris, mais c'est peut-être faux, c'est que la licence c'est le contrat que tu passes avec la personne qui te le distribue. Donc sous cette hypothèse, autoriser la redistribution sous une autre licence, c'est autoriser à changer la licence du code.
Le distributeur est lié par le contrat original, il ne peut redistribuer que selon les termes de la licence originale. Si la GPL impose que le distributeur redistribue le code selon les mêmes termes, ce n'est pas pour faire joli, c'est pour éviter les "intermédiaires" qui pourraient restreindre les droits sur le code. Tu ne peux rien rajouter/supprimer à la GPL sans l'accord de l'auteur.
Par exemple, avec la licence BSD, un intermédiaire pourrait très bien fermer le code parce que la BSD l'autorise, néanmoins, rien ne t'interdit de récupérer le même code sous la licence originale puisque la BSD n'implique pas la cession des droits d'auteurs.
En revanche, si il y a eu cession totale ou partielle des droits, c'est discutable.
Tu dois toujours tenir compte du contrat original, de la modalité d'acquisition (directe, indirecte), et de qui détient les droits d'auteurs.
> ils vont utiliser koffice, donc je pense pas que nokia se fiche tant que ça de nokia....
Nokia est un vendeur de téléphones, il en a rien à foutre du desktop (GNOME ou KDE). Par le passé, Nokia a payé des personnes pour travailler sur différents composants de GNOME Mobile (directement ou sous-traités), Nokia ne paie personne pour bosser sur KDE.
Nokia avait besoin d'un lecteur de documents sur ses smartphones, la solution la plus rapide était de réutiliser du code provenant de KOffice (ils allaient pas tout redévelopper ou pire porter OOo sur N900)
> quand je regarde le progrès fait de kde 4.0 à kde 4.4 et ce qu'il a été fait sur gnome durant la même période, oui gnome s'est endormie
La plupart des nouvelles technologies de KDE4 existent déjà dans GNOME2 (DBus, Phonon --> GStreamer/PulseAudio, Decibel ---> Telepathy, Solid ---> DeviceKit/NM/Gnome Power Manager, etc ...)
Du côté de GNOME, ça a tout autant bouger que chez KDE, la différence, c'est que les changements ont été fait dans la continuité (pas de rupture comme avec Qt4). Pour l'IHM, ça arrive (Mutter, GNOME-shell, Zeitgeist, etc ...) et c'est même déjà utilisable sous GNOME2.
----------------
Et puis contrairement à KDE, GNOME n'a pas de problèmes majeurs d'ergonomie (options à foison, onglets un peu partout, des thèmes criards, inflation de fonctionnalités aka syndrome d'emacs etc ...) ;-)
> Il a aussi été proposé de demander un soutien de la fondation Mozilla. Ou bien lever des fonds publics ?
Je remarque que dès qu'un projet libre majeur nécessite un financement, on se tourne automatiquement vers la MoFo. La MoFo génére des revenus relativement importants et se montre déjà très généreuse vis à vis du libre, ils emploient des développeurs, financent des projets tiers (GNOME, Theora, etc ...), des événements, lobbying etc ... Mais la MoFo n'a pas pour finalité de devenir la vache à lait du libre (et surtout ne le peut pas !). Sans oublier qu'il est particulièrement malsain de dépendre d'un unique sponsor comme le confirme le cas d'Orca.
Il est plus pertinent d'aller taper à la porte des distributions desktop commerciales pour qui l'accessibilité est stratégique pour leur business. À vot' bon coeur (ironie inside), Red Hat, Novell, Mandriva, Canonical etc ....
+1, Python se prête très bien à ce genre d'exercice, et s'interface très bien avec du code natif si nécessaire mais seul le profilage pourra le confirmer ou non.
Il n'est pas rare de niveler une application : C pour les parties dont les performances sont critiques, Python pour le reste. Sans compter qu'on peut prototyper rapidement les parties critiques en Python pour valider son cahier des charges. Best of both worlds !
Les licences ne devraient pas poser d'obstacles, pense à rajouter un fichier LICENSE dans le répertoire dédié à la documentation et les entêtes sur les fichiers sources.
La décision de partager un même dépôt ou non, dépendra principalement de ton workflow, si avoir des historiques distincts présentent un intérêt ou non, etc ...
Tu peux très bien distribuer ton application et la documentation sous deux licences différentes si les deux projets sont bien distincts. C'est le cas pour la plupart des projets GNU (GPLv2 + GFDL pour la documentation)
À priori, c'est le cas de Nagios, la documentation vit dans un répertoire distinct et n'est pas généré à partir des commentaires. En attendant de réécrire la documentation, tu peux très distribuer la documentation sous une licence différente (même si il y a compatibilité) de l'application.
Pour la distribution, ça ne pose pas de problème, le code étant sous AGPLv3+ et la documentation en GPLv2, même si pour des raisons pratiques, tu préfereras sans doute les distribuer séparément.
En revanche, il n'est explicitement mention nulle part de la licence sous laquelle la documentation est distribué Nagios (pas de headers dans les sources, pas de fichier LICENSE, etc ...). Même si il est probable qu'elle soit distribué sous licence GPLv2 only, je te recommande de demander une permission écrite de la société éditrice de Nagios pour éviter tout conflit potentiel à l'avenir.
Auprès des autorités de certifications, pour verisign/GeoTrust/Thawte c'est par là : https://www.verisign.com/support/roots.html
Ils sont également fournis avec la plupart des navigateurs, pour Firefox, c'est dans une base sqlite3 chiffré cert8.db. Tu peux manipuler la base avec les nss-tools ou les bindings python pour nss.
> du coup, je demandais juste si ma technique (tel que décrite plus haut) est valable et suffisante
Si tu as déjà le certificat racine, pourquoi coder à la main une fonction qui existe déjà ? À moins d'être un spécialiste de la sécurité, je ne me risquerais pas à un tel exercice à ta place.
Si tu lis la doc de ssl.get_server_certificate, tu verras que tu peux fournir une liste contenant les certificats racines, la fonction se chargera de valider (ou non) ton certificat.
Avant d'accuser PA, aller plutôt remercier les bras cassés qui ont empaqueté PA dans Ubuntu comme des sagouins.
Parce que c'est quasiment les seuls a avoir eu autant de problèmes, souvent des problèmes d'intégration qui auraient pu être facilement évités si les bras cassés en question avaient pris la peine de se renseigner auprès d'upstream.
> Ce qui est navrant, c'est que de belles innovations soient critiquées uniquement car elles sont faites sur Ubuntu par des utilisateurs d'Ubuntu.
Le mainteneur de quickly, Rick Spencer travaille pour Canonical, d'ailleurs le copyright de quickly est assigné à Canonical. Même si quickly est réutilisable autre part, ça reste un projet très ubuntu-centric, fortement couplé à bazaar et Launchpad. À l'heure actuelle, quickly n'est pas architecturé pour être utilisable dans un autre contexte, pas de support de plugins, rien que l'intégration d'un autre VCS demanderait de réécrire une bonne partie de quickly.
Un des problèmes récurrents pour les packagers sont les applications exclusivement développés *pour* Ubuntu. Ça va du projet aux dépendances farfelues, du projet sans VCS, sans tarball juste des deb ("parce qu'il n'y a que des fichiers python", super pratique pour les autres !), au projet qui te dit carrément merde (chez XBMC, c'est limite un préalable à toute contribution)
Au bout d'un moment, il est normal que ça agace beaucoup de personnes.
Reste que quickly part d'une bonne idée : un générateur de templates d'applications desktop comme on peut en retrouver pour les applications web, avec une couche d'abstraction pour faciliter les choses pour les non programmeurs. Je le verrais bien en remplaçant de RAD type Visual Basic, et il couvrerait un réel besoin.
Une application sympathique développé par Jono Bacon à l'aide quickly : https://wiki.ubuntu.com/Lernid
Le résultat est appréciable quand on sait que quickly n'existe que depuis près de 6 mois.
En revanche, ne te contente pas de l'antique version 1.0, la 2.0 est beaucoup plus robuste et offre des bindings Python beaucoup plus agréables d'utilisation.
Un truc marrant serait de faire un plugin GStreamer pour faire le traitement d'image, ça dépoterait pas mal niveau performances.
> J'essais de me mettre a C++/Qt, mais c'est pas facile
Qt te mâche pas mal de choses, suffisamment pour ne pas regretter Java (voire pour l'enterrer joyeusement dans mon cas). Python et Ruby étant des langages dynamiques, ils ont des facilités qui les rendent attractifs pour faire du prototypage, de l'administration système, les cas où les performances ne sont pas critiques.
Si tu n'es pas à l'aise avec C++, commence ton application en Python/Ruby avec les bindings Qt, tu pourras toujours la réécrire en C++/Qt plus tard si nécessaire. Par ailleurs, PyQt est un excellent moyen pour se familiariser rapidement avec Qt.
http://dev.mysql.com/downloads/gui-tools/5.0.html
La suite des "GUI Tools" est remplacé par le très bon MySQL Workbench, la 5.2 (actuellement en béta) est à parité de fonctions avec les GUI Tools [1], plus les fonctionnalités de conception hérités de DB Designer. Et le remplacement était prévu bien avant le rachat par Oracle.
Pour ton application de monitoring, c'est selon tes connaissances et le niveau de contrôle que tu souhaite avoir. Je pense que le choix Python/MySQLdb est pertinent dans ton cas.
> Pourquoi ? Car le profiling est infernal sous Django et les core devs ne veulent pas ajouter de Pooleur de connexion pour les bases de données
As-tu envisagé de tout simplement changer d'ORM ? par exemple, SQLAlchemy (d'ailleurs, on peut utiliser les piscines de connexions de SQLA avec les connexions DB-API classiques). Tu as également le très bon Storm qui certes ne supporte pas le pooling mais qui est très efficace.
Sinon, tu peux utiliser un framework python plus flexible comme Turbogears ou bien Pylons.
[1] à l'exception de la boite à outil de migration, certaines fonctionnalités devraient arriver après la 5.2
> However, our policy remains the same: we won't try to hinder their efforts, but we have no plans to help them.
Mis à part leur coller un procès aux culs, je ne vois pas comment nVidia pourrait mettre plus de bâtons dans les roues des développeurs de nouveau, pas de spécifications, pas d'échanges, pas de code.
Reste que j'admire l'habileté et la technique des communiquants de nVidia : un peu de pommade ("incredible job") pour faire passer l'essentiel ("we have no plans to help them") et l'appât ("we won't try to hinder their efforts") pour que les fanboys ne se sentent pas en porte à faux pour défendre leur marque.
[^] # Re: migration?
Posté par GeneralZod . En réponse à la dépêche Accessibilité: Oracle prend Sun mais se débarrasse de Willie Walker. Évalué à 0.
Tu as des pans entiers de Qt4 qui n'ont pas d'équivalents dans Qt3 ou qui ont été complétement réécrits. Le portage de Qt3 vers Qt4 n'a rien de trivial, il a fallu rajouter un module de compatibilité qt3support pour faciliter le portage.
En comparaison, Qt3 apportait par rapport à Qt2 un meilleur support de l'unicode, de l'i18n et un peu de toilettage pour virer les modules dépréciés.
Je t'accorde que la tournure peut prêter à confusion, les principes de bases de Qt n'ont pas variés (QObject, le système signal-slots, etc ...) mais on ne passe pas de Qt3 à Qt4 comme ça.
> c'est donc un choix responsable de KDE d'avoir refondu les fondations et non quelque chose qui aurait été imposé par les changements de Qt.
C'était le seul choix sensé surtout ! Là où le passage de Qt2 -> Qt3 ne demandait finalement que quelques petites retouches, Qt4 imposait de réécrire une bonne partie de KDE4 et de s'appuyer sur la rustine qt3support. C'était soit casser la compatibilité, soit construire un monstre de frankenstein.
> KDE a choisi d'abstraire totalement la couche son de façon à pouvoir gérer facilement plusieurs démons sonores au choix. Cela a donné phonon.
Le reméde s'est révélé être pire que le mal qu'il était sensé combattre. Parce que le support des différents moteurs multimédias dans Phonon est une catastrophe, de fait, KDE ne maintient que le backend Xine, le backend GStreamer et Quicktime à l'origine maintenu par Nokia n'évolue plus du tout.
http://www.mail-archive.com/fedora-devel-list@redhat.com/msg(...)
http://www.mail-archive.com/fedora-devel-list@redhat.com/msg(...)
Parmi les différentes couches d'abstraction développés pour KDE4, Phonon fait figure de bon élèves pour dire le peu d'activité autour de Solid ou Decibel.
> Note au passage que les gens de gstreamer n'ayant pas à coeur de conserver la compatiblité binaire entre des releases, phonon est nécessaire même pour l'intégration de gstreamer dans KDE
Tu m'expliqueras comment GNOME fait alors ...
GStreamer 0.10.x est apparu fin 2005 et pas de changement majeur à l'horizon, la suite a donné raison aux développeurs de GStreamer. Entre temps, à l'exception du sous-ensemble figé dans Qt, l'API de Phonon a plus souvent changé que celle de GStreamer.
> Owen Taylor a commencé à pousser un protocole de communication de bureau commun à KDE et à Gnome, inspiré de DCOP
L'idée est de concevoir un mécanisme d'IPC desktop-agnostic, DBus est plus bas niveau que DCOP. DCOP n'était pas utilisable dans un contexte autre que KDE. DBus a été une remise à plat en prenant compte de l'existant (ICE, Corba, SOAP, etc ...) et en tenant compte des échecs passés comme Bonobo. DBus n'est pas qu'une simple copie améliorée de DCOP.
> La grande force de DBUS, c'est de ne pas apparaitre comme une techno KDE mais une techno neutre, poussée par Red Hat.
J'admire comment les KDE-istes s'approprient DBus alors qu'ils l'ont royalement ignorés pendant plusieurs années.
Les développeurs GNOME ont au moins le mérite de reconnaitre quand ils ont foirés et d'essayer de proposer des solutions neutres.
> Encore une affirmation tout à fait erronée. Abonne toi à la liste xdg et tu verras que les développeurs KDE sont tout autant présent que les développeurs Gnome, et que l'interopérabilité est un souci présent des deux côtés.
J'ai dit qu'ils étaient rares, pas absents et FreeDesktop ne se limite pas à XDG. Et il est encore plus rare qu'ils soient force de proposition.
Dans l'exemple DBus, KDE a été invité à participer à sa conception mais ils ne l'ont pas fait, ils se sont juste contenté de le reprendre quand ils ont vu que c'était une meilleure alternative que DCOP.
> On peut seulement regretter que une partie des développeurs Gnome voient l'interopérabilité comme « je pousse une techno Gnome sur xdg en la déclarant un standard ».
Quand il existe une problématique autour de l'interopérabilité, la première réaction du développeur KDE c'est de chercher si une solution "standard" existe sinon redévelopper une solution KDE-only sans se soucier des autres. Le développeur GNOME ira d'abord démarrer une discussion sur FreeDesktop *puis* commencera à développer une solution neutre (et une surcouche pour l'intégrer à GNOME) ==> DBus, libcanberra, xdg, PackageKit, ConsoleKit, PolicyKit sont nés comme ça.
FreeDesktop a été créé comme un espace de discussion entre les implémenteurs de bureaux, force est de constater que le réflexe, "je rencontre une problématique, j'en discute sur FreeDesktop avant de commencer quelque chose" n'existe pas chez les développeurs KDE.
Ça ne veut pas dire que les développeurs KDE s'en branlent de l'interopérabilité mais qu'ils devraient être plus proactifs sur FreeDesktop.
Le « je pousse une techno Gnome sur xdg en la déclarant un standard » n'est qu'un fantasme des KDE-istes, la plupart du temps, la discussion/conception sur la techno se fait en amont sur FreeDesktop et non pas à posteriori. Après faut pas venir se plaindre que les méchants développeurs GNOME imposent leurs technos si personne de chez KDE ne daigne participer en amont.
[^] # Re: Et le bouton 'bloquer' c'est fait pour quoi ?
Posté par GeneralZod . En réponse au journal Vous avez un compte gmail ? Dites adieu à votre vie privée grâce à Buzz. Évalué à 7.
[^] # 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.
Par nature, un serveur son est une couche d'abstraction, quant à GStreamer, de par son architecture, il peut être appelé à l'être (GStreamer ne réinvente pas la roue sur les autres OS non plus, il fait appel aux APIs natives).
> Ensuite D-Bus, HAL, DeviceKit viennent de freedesktop. C'est mal de les utiliser?
Tu peux également rajouter GStreamer, Telepathy, PolicyKit, ConsoleKit dans la liste. Est-ce mal de les utiliser ? absolument pas !
Je répondais à un commentaire prétendant que les développeurs GNOME n'ont rien branlés ces dernières années alors que la plupart de ses technologies ont été initiés ou maintenu au sein de la communauté GNOME. C'est pas un mystère que les développeurs KDE se font rares sur FreeDesktop.
Contrairement à Qt3, Qt4 a été une rupture totale par rapport à son prédécesseur, KDE n'a eu d'autres choix que de revoir les fondations. Pendant longtemps, le boulot de KDE a été de réécrire ce qui existait déjà.
GNOME n'a pas été obligé de se réinventer, la plupart des changements se sont fait sous le capot. GNOME3 sera dans la continuité de son prédécesseur, la différence, c'est qu'on ne se souciera plus de la compatibilité descendante. La plupart des nouveaux composants de GNOME3 tournent sans problèmes sur GNOME2.
> Et networkmanager est indépendant de l'os, que je sache. Gnome à été le premier à bénéficier d'une interface graphique certes.
NM est maintenu par un seul type employé par Red Hat, le service a été conçu pour être desktop-agnostic mais il repose sur la GLib.
> Bravo: c'est exactement ça. kde est un projet d'environnement de bureau, pas un os complet
Dans la pratique, les couches d'abstractions posent plus de problèmes qu'elles n'en règlent, Solid est en train de couler et n'a jamais tenu ses promesses de multiplateformes, les backends de Phonon ne sont pas égaux surtout depuis que Nokia ne s'investit plus dedans (le backend GStreamer est complétement moisi par exemple).
Ironiquement, ces couches d'asbtractions ont été développés pour éviter de se retrouver dans la même situation qu'avec arts (qui n'était plus maintenu pendant des années) et au final, à l'exception de Phonon qui vivote tant bien que mal, elles sont toutes quasiment abandonnées que ce soit Decibel ou Solid.
Reste que KDE4 a de beaux succès à son actif comme Plasma.
[^] # Re: Sun
Posté par GeneralZod . En réponse à la dépêche Comment détruire votre communauté. Évalué à 2.
[^] # Re: Si quelqu'un a le temps :
Posté par GeneralZod . En réponse à la dépêche Comment détruire votre communauté. Évalué à 2.
Parce qu'à part libvirt et les bindings python, le reste des dépendances n'a rien d'extravagant même pour une Debian stable.
http://virt-manager.et.redhat.com/download.html
Si tu prends en compte les dix points listés par Josh Berkus, tu verras que libvirt et les projets associés n'en respectent pas un seul.
# Intégrité de l'information
Posté par GeneralZod . En réponse au message Procédure stockées. Évalué à 3.
===> ça évite de se retrouver avec une base incohérente à cause d'un bogue dans le client ou d'un crétin qui a fait une requête foireuse.
Les autres utilisations couvrent l'encapsulation de la logique métier donc moins de traitements à faire côté client, améliorer les performances en réduisant les échanges, néanmoins ça a un coût côté serveur. Mais également logguer, faire de la réplication, gérer plus finement les accès.
Postgres a un support très complet des triggers et procédures stockés que l'on peut écrire en PL/pgSQL (un langage de programmation inspiré du PL/SQL d'Oracle) ou en Python, Perl, etc ...
MySQL a un support assez récent et relativement pauvre comparé à Postgres, mais suffisant pour la plupart des cas d'utilisations.
Pour de l'optimisation pure, tu as d'autres leviers à ta disposition à commencer par une bonne conception et l'implantation. Et ne jamais oublier que tout se paie avec un SGBD !
[^] # Re: Mozilla n'est pas la vache à lait des logiciels libres
Posté par GeneralZod . En réponse à la dépêche Accessibilité: Oracle prend Sun mais se débarrasse de Willie Walker. Évalué à 2.
[^] # Re: migration?
Posté par GeneralZod . En réponse à la dépêche Accessibilité: Oracle prend Sun mais se débarrasse de Willie Walker. Évalué à 2.
N'importe quoi. Pour ta gouverne, DBus s'est inspiré entre autre de DCOP mais également d'ICE sur lequel reposait déjà DCOP.
DBus a été écrit et conçu from scratch, en se basant sur l'expérience acquise avec Corba et selon un cahier des charges bien défini et ce sans le concours des développeurs KDE comme tu le prétends. DBus est plus bas niveau que DCOP (il avait été proposé de remplacer ICE par DBus un moment dans DCOP), mais également neutre (contrairement à DCOP).
> Je crois tout aussi bien que Phonon et Solid sont fouareux comme exemples car ce sont des couches d'abstraction pour porter Kde sur d'autres systèmes ce que GNOME n'a pas décidé de faire.
Phonon est une couche d'abstraction multimédia, mais c'est également le cas de GStreamer ou PA ... Quant à Solid, le projet bat de l'aile depuis un moment, seul le backend Linux est fonctionnel. Celui-ci repose principalement sur D-Bus, HAL, DeviceKit, NM, Bluez ...
Quel est l'intérêt d'avoir un bureau KDE sous Windows ? Ralentir encore plus ta machine ? L'objectif c'est de permettre de faire tourner les applications KDE, et même dans ce domaine, l'avance de KDE est bien maigre malgré un portage de Qt4 bien meilleur !
C'est bien joli de faire des couches d'abstraction reposant elle-même sur des couches d'abstraction mais les fonctionnalités sous-jacentes vont pas se coder toutes seules. Parce que sans GStreamer, PA, NM, DeviceKit, Telepathy, Bluez etc ... que deviennent les couches d'abstraction de KDE ? de belles coquilles vides.
[^] # Re: Mozilla n'est pas la vache à lait des logiciels libres
Posté par GeneralZod . En réponse à la dépêche Accessibilité: Oracle prend Sun mais se débarrasse de Willie Walker. Évalué à 7.
Google émunère un service rendu : le choix de Google comme moteur de recherche par défaut dans Firefox, et proportionnellement à chaque clic sur une publicité apparaissant sur les pages générées par les recherches. Google ne joue pas aux mécénes avec la MoFo. L'accord a été renouvelé et court jusqu'à 2011 et certains moteurs de recherche sont prêts à prendre le relai (y compris Microsoft).
Selon toi, les publicitaires ne générent pas de revenus mais profite des revenus des industriels ?
> Comme pour la MoFo et Google ?
L'accord avec Google représente environ 85% des revenus de la MoFo. Certes, il y a une dépendance financière vis à vis de Google, mais elle est à tempérer à plusieurs titres, d'autres sont prêts à prendre le relai, l'accord est également profitable à Google. Ça signifie également que la MoFo est capable de générer 15% à 20 % de ses revenus actuels sans l'apport de Google.
Ça paraît peu mais c'est oublier la manne financière que représente l'accord avec Google, du jour au lendemain, la MoFo a vu ses revenus augmenter de façon exponentielle.
Est-ce que la MoFo peut vivre sans Google ? la MoFo l'a fait pendant près de dix ans, la perte des revenus provenant de Google ralentirait très certainement son activité pendant un moment mais sans plus.
[^] # Re: Probleme de licence
Posté par GeneralZod . En réponse au journal AGPL et GPLv2. Évalué à 2.
L'insertion d'un entête rappelant la licence et le copyright pour chaque fichier est une pratique vivement recommandée. C'est pas comme si il n'y avait pas eu de précédents judiciaires dont le célèbre USL vs BSDi.
> Ce que j'avais compris, mais c'est peut-être faux, c'est que la licence c'est le contrat que tu passes avec la personne qui te le distribue. Donc sous cette hypothèse, autoriser la redistribution sous une autre licence, c'est autoriser à changer la licence du code.
Le distributeur est lié par le contrat original, il ne peut redistribuer que selon les termes de la licence originale. Si la GPL impose que le distributeur redistribue le code selon les mêmes termes, ce n'est pas pour faire joli, c'est pour éviter les "intermédiaires" qui pourraient restreindre les droits sur le code. Tu ne peux rien rajouter/supprimer à la GPL sans l'accord de l'auteur.
Par exemple, avec la licence BSD, un intermédiaire pourrait très bien fermer le code parce que la BSD l'autorise, néanmoins, rien ne t'interdit de récupérer le même code sous la licence originale puisque la BSD n'implique pas la cession des droits d'auteurs.
En revanche, si il y a eu cession totale ou partielle des droits, c'est discutable.
Tu dois toujours tenir compte du contrat original, de la modalité d'acquisition (directe, indirecte), et de qui détient les droits d'auteurs.
[^] # Re: migration?
Posté par GeneralZod . En réponse à la dépêche Accessibilité: Oracle prend Sun mais se débarrasse de Willie Walker. Évalué à 4.
Nokia est un vendeur de téléphones, il en a rien à foutre du desktop (GNOME ou KDE). Par le passé, Nokia a payé des personnes pour travailler sur différents composants de GNOME Mobile (directement ou sous-traités), Nokia ne paie personne pour bosser sur KDE.
Nokia avait besoin d'un lecteur de documents sur ses smartphones, la solution la plus rapide était de réutiliser du code provenant de KOffice (ils allaient pas tout redévelopper ou pire porter OOo sur N900)
> quand je regarde le progrès fait de kde 4.0 à kde 4.4 et ce qu'il a été fait sur gnome durant la même période, oui gnome s'est endormie
La plupart des nouvelles technologies de KDE4 existent déjà dans GNOME2 (DBus, Phonon --> GStreamer/PulseAudio, Decibel ---> Telepathy, Solid ---> DeviceKit/NM/Gnome Power Manager, etc ...)
Du côté de GNOME, ça a tout autant bouger que chez KDE, la différence, c'est que les changements ont été fait dans la continuité (pas de rupture comme avec Qt4). Pour l'IHM, ça arrive (Mutter, GNOME-shell, Zeitgeist, etc ...) et c'est même déjà utilisable sous GNOME2.
----------------
Et puis contrairement à KDE, GNOME n'a pas de problèmes majeurs d'ergonomie (options à foison, onglets un peu partout, des thèmes criards, inflation de fonctionnalités aka syndrome d'emacs etc ...) ;-)
[^] # Re: migration?
Posté par GeneralZod . En réponse à la dépêche Accessibilité: Oracle prend Sun mais se débarrasse de Willie Walker. Évalué à 4.
> la communauté est très active
Parce que la communauté GNOME est très endormie ?
> nokia est dernière Qt et pousse à fond
Nokia a fait un boulot formidable pour promouvoir Qt, mais en dehors de ça, Nokia se fiche royalement de KDE.
> je crois que kde est beaucoup plus organisé que gnome
infondé
# Mozilla n'est pas la vache à lait des logiciels libres
Posté par GeneralZod . En réponse à la dépêche Accessibilité: Oracle prend Sun mais se débarrasse de Willie Walker. Évalué à 9.
Je remarque que dès qu'un projet libre majeur nécessite un financement, on se tourne automatiquement vers la MoFo. La MoFo génére des revenus relativement importants et se montre déjà très généreuse vis à vis du libre, ils emploient des développeurs, financent des projets tiers (GNOME, Theora, etc ...), des événements, lobbying etc ... Mais la MoFo n'a pas pour finalité de devenir la vache à lait du libre (et surtout ne le peut pas !). Sans oublier qu'il est particulièrement malsain de dépendre d'un unique sponsor comme le confirme le cas d'Orca.
Il est plus pertinent d'aller taper à la porte des distributions desktop commerciales pour qui l'accessibilité est stratégique pour leur business. À vot' bon coeur (ironie inside), Red Hat, Novell, Mandriva, Canonical etc ....
[^] # Re: Désolé pour le journal, je voulais écrire dans le forum....
Posté par GeneralZod . En réponse au journal AGPL et GPLv2. Évalué à 3.
Il n'est pas rare de niveler une application : C pour les parties dont les performances sont critiques, Python pour le reste. Sans compter qu'on peut prototyper rapidement les parties critiques en Python pour valider son cahier des charges. Best of both worlds !
[^] # Re: Le problème n'est pas là
Posté par GeneralZod . En réponse au journal AGPL et GPLv2. Évalué à 2.
La décision de partager un même dépôt ou non, dépendra principalement de ton workflow, si avoir des historiques distincts présentent un intérêt ou non, etc ...
# Le problème n'est pas là
Posté par GeneralZod . En réponse au journal AGPL et GPLv2. Évalué à 2.
À priori, c'est le cas de Nagios, la documentation vit dans un répertoire distinct et n'est pas généré à partir des commentaires. En attendant de réécrire la documentation, tu peux très distribuer la documentation sous une licence différente (même si il y a compatibilité) de l'application.
Pour la distribution, ça ne pose pas de problème, le code étant sous AGPLv3+ et la documentation en GPLv2, même si pour des raisons pratiques, tu préfereras sans doute les distribuer séparément.
En revanche, il n'est explicitement mention nulle part de la licence sous laquelle la documentation est distribué Nagios (pas de headers dans les sources, pas de fichier LICENSE, etc ...). Même si il est probable qu'elle soit distribué sous licence GPLv2 only, je te recommande de demander une permission écrite de la société éditrice de Nagios pour éviter tout conflit potentiel à l'avenir.
[^] # Re: FreeWIFI : sécurité ?
Posté par GeneralZod . En réponse au journal [ubuntu inside] Quickly superbe ... et annonce : freetp et autowifi. Évalué à 2.
[^] # Re: FreeWIFI : sécurité ?
Posté par GeneralZod . En réponse au journal [ubuntu inside] Quickly superbe ... et annonce : freetp et autowifi. Évalué à 2.
https://www.verisign.com/support/roots.html
Ils sont également fournis avec la plupart des navigateurs, pour Firefox, c'est dans une base sqlite3 chiffré cert8.db. Tu peux manipuler la base avec les nss-tools ou les bindings python pour nss.
> du coup, je demandais juste si ma technique (tel que décrite plus haut) est valable et suffisante
Si tu as déjà le certificat racine, pourquoi coder à la main une fonction qui existe déjà ? À moins d'être un spécialiste de la sécurité, je ne me risquerais pas à un tel exercice à ta place.
[^] # Re: FreeWIFI : sécurité ?
Posté par GeneralZod . En réponse au journal [ubuntu inside] Quickly superbe ... et annonce : freetp et autowifi. Évalué à 2.
[^] # Re: Centré, c'est le mot !
Posté par GeneralZod . En réponse au journal [ubuntu inside] Quickly superbe ... et annonce : freetp et autowifi. Évalué à 2.
Parce que c'est quasiment les seuls a avoir eu autant de problèmes, souvent des problèmes d'intégration qui auraient pu être facilement évités si les bras cassés en question avaient pris la peine de se renseigner auprès d'upstream.
http://0pointer.de/blog/projects/pa-in-ubuntu.html
[^] # Re: Centré, c'est le mot !
Posté par GeneralZod . En réponse au journal [ubuntu inside] Quickly superbe ... et annonce : freetp et autowifi. Évalué à 8.
Le mainteneur de quickly, Rick Spencer travaille pour Canonical, d'ailleurs le copyright de quickly est assigné à Canonical. Même si quickly est réutilisable autre part, ça reste un projet très ubuntu-centric, fortement couplé à bazaar et Launchpad. À l'heure actuelle, quickly n'est pas architecturé pour être utilisable dans un autre contexte, pas de support de plugins, rien que l'intégration d'un autre VCS demanderait de réécrire une bonne partie de quickly.
Un des problèmes récurrents pour les packagers sont les applications exclusivement développés *pour* Ubuntu. Ça va du projet aux dépendances farfelues, du projet sans VCS, sans tarball juste des deb ("parce qu'il n'y a que des fichiers python", super pratique pour les autres !), au projet qui te dit carrément merde (chez XBMC, c'est limite un préalable à toute contribution)
Au bout d'un moment, il est normal que ça agace beaucoup de personnes.
Reste que quickly part d'une bonne idée : un générateur de templates d'applications desktop comme on peut en retrouver pour les applications web, avec une couche d'abstraction pour faciliter les choses pour les non programmeurs. Je le verrais bien en remplaçant de RAD type Visual Basic, et il couvrerait un réel besoin.
Une application sympathique développé par Jono Bacon à l'aide quickly :
https://wiki.ubuntu.com/Lernid
Le résultat est appréciable quand on sait que quickly n'existe que depuis près de 6 mois.
# OpenCV (adieu PIL)
Posté par GeneralZod . En réponse au message Traitement python sur fichiers (images) issues d'un programme externe en continu. Évalué à 3.
http://opencv.willowgarage.com/documentation/python/reading_(...)
En revanche, ne te contente pas de l'antique version 1.0, la 2.0 est beaucoup plus robuste et offre des bindings Python beaucoup plus agréables d'utilisation.
Un truc marrant serait de faire un plugin GStreamer pour faire le traitement d'image, ça dépoterait pas mal niveau performances.
[^] # Re: MySQL Workbench
Posté par GeneralZod . En réponse au message Création d'une GUI pour monitorer MySQL, Que choisir ?. Évalué à 3.
Euh, justement si, une capture d'écran pour te prouver (v5.2.15 béta).
http://img716.imageshack.us/img716/7029/capturemysqlworkbenc(...)
> J'essais de me mettre a C++/Qt, mais c'est pas facile
Qt te mâche pas mal de choses, suffisamment pour ne pas regretter Java (voire pour l'enterrer joyeusement dans mon cas). Python et Ruby étant des langages dynamiques, ils ont des facilités qui les rendent attractifs pour faire du prototypage, de l'administration système, les cas où les performances ne sont pas critiques.
Si tu n'es pas à l'aise avec C++, commence ton application en Python/Ruby avec les bindings Qt, tu pourras toujours la réécrire en C++/Qt plus tard si nécessaire. Par ailleurs, PyQt est un excellent moyen pour se familiariser rapidement avec Qt.
# MySQL Workbench
Posté par GeneralZod . En réponse au message Création d'une GUI pour monitorer MySQL, Que choisir ?. Évalué à 3.
La suite des "GUI Tools" est remplacé par le très bon MySQL Workbench, la 5.2 (actuellement en béta) est à parité de fonctions avec les GUI Tools [1], plus les fonctionnalités de conception hérités de DB Designer. Et le remplacement était prévu bien avant le rachat par Oracle.
Pour ton application de monitoring, c'est selon tes connaissances et le niveau de contrôle que tu souhaite avoir. Je pense que le choix Python/MySQLdb est pertinent dans ton cas.
> Pourquoi ? Car le profiling est infernal sous Django et les core devs ne veulent pas ajouter de Pooleur de connexion pour les bases de données
As-tu envisagé de tout simplement changer d'ORM ? par exemple, SQLAlchemy (d'ailleurs, on peut utiliser les piscines de connexions de SQLA avec les connexions DB-API classiques). Tu as également le très bon Storm qui certes ne supporte pas le pooling mais qui est très efficace.
Sinon, tu peux utiliser un framework python plus flexible comme Turbogears ou bien Pylons.
[1] à l'exception de la boite à outil de migration, certaines fonctionnalités devraient arriver après la 5.2
[^] # Re: Question bête :
Posté par GeneralZod . En réponse au journal Flash pas OpenSource à cause d'H264. Évalué à 10.
Mis à part leur coller un procès aux culs, je ne vois pas comment nVidia pourrait mettre plus de bâtons dans les roues des développeurs de nouveau, pas de spécifications, pas d'échanges, pas de code.
Reste que j'admire l'habileté et la technique des communiquants de nVidia : un peu de pommade ("incredible job") pour faire passer l'essentiel ("we have no plans to help them") et l'appât ("we won't try to hinder their efforts") pour que les fanboys ne se sentent pas en porte à faux pour défendre leur marque.