Voire, vu que le recyclage de metal doit passer par une chauffe à très haute température, ils en ont rien à foutre des dechets résiduels en plastiques. Il seront juste brulés plutot que triés...
Les jugements à l'emporte pièce et à deux balles, je trouve ça insupportable.
> parce qu'avec le modèle proprio, ton mediainfo, il sera pas sorti de ton garage.
Qu'est ce que tu en sais ? Tu supposes que parce que son logiciel est libre, il a tout d'un coup été téléchargé par des dizaines de milliers d'utilisateurs et que aujourd'hui, c'est grâce à ça qu'il peut en vivre.
Moi j'imagine plutôt que Zenitram est un spécialiste des logiciels vidéo, qu'il avait déjà un solide carnet d'adresse et de clients potentiels, une bonne connaissance du marché et que quand il a lancé son soft, il avait déjà des acheteurs. Et que l'aspect logiciel libre n'a peut-être pas du tout pesé dans la décision de ses clients.
De ce point de vue là, choisir de rendre libre une partie de son logiciel n'etait pas une obligation mais réellement un engagement en faveur du logiciel libre.
Mais en l'absence d'information, tu présupposes que le libre est le grand Zorro qui a sorti Zenitram de sa misère. Mais bien sur !
> tu n'est clairement pas un libriste activiste
Parce qu'il est capable de voir les défauts de theora au lieu de l'encenser sans le connaître, il n'est pas un activiste de logiciel libre ? C'est vraiment des jugements pathétiques.
Ca me fait penser à l'époque ou Gnome encensait Corba et ORBIT, l'implémentation de Corba utilisé pour l'occasion. A l'époque KDE ayant soumis l'idée que Corba était une grosse bouse pour les besoins du desktop, on a porté sur eux le même type de jugement que celui que tu portes sur Zenitram.
Faire du logiciel libre ne veut pas dire embrasser aveuglément toutes les technos libres sans voir leurs avantages et leurs défauts. 10 ans après, plus personne chez les développeurs de Gnome n'oserait encore dire que Corba était une bonne idée.
> tu n'es peut être même pas un libriste par conviction
Zenitram [1] a expliqué qu'il a implémenté la partie Vorbis et Ogg uniquement parce que des barbus le lui demandaient. Moi je trouve que ça ressemble bien plus à un libriste de conviction.
> Parce qu'avec le modèle proprio, tu pourrais pas utiliser toutes les libs que tu utilises
Par curiosité, je suis allé voir les dépendances de MediaInfoLib et les licences associées :
- Zlib.lib: BSD
- Id3Lib.lib: LGPL
- Zenlib.lib: BSD
- Ebml.lib: LGPL
- Matroska.lib: LGPL
- WxBase.lib (part of wxWidgets project): LGPL
- Flac.lib (Flac and Flac++): BSD
Donc visiblement, il pourrait tout à fait développer MediaInfo en tant que logiciel proprio, toutes les licences le permettent.
C'était donc encore une affirmation à deux balles. Et c'est bien par choix et non par obligation que Zenitram en a fait un logiciel ouvert (en grande partie si j'ai bien saisi).
> Parce qu'avec le modèle proprio, tu n'aurais pas eu cette "libre diffusion" qui a assuré une partie du "se faire connaitre"
Ou à l'inverse, parce que sans la partie proprio Zenitram ne pourrait pas en vivre et le monde du logiciel libre n'aurait jamais un logiciel de la qualité de MediaInfo.
> Parce qu'avec le modèle proprio, tu n'aurais pas eu les entreprises qui l'utilisent parce que c'est gratuit et qui te demande de développer un truc en plus.
Encore une affirmation à deux balles. Il aurait pu aussi en faire un freeware permettant aux entreprises de l'utiliser et avoir quand même une très bonne notoriété. Il y a des milliers de logiciels qui vivent sur ce modèle économique. Et peut-être gagnerait-il bien plus d'argent avec les licences qu'il n'en gagne aujourd'hui à faire du dev "à la demande".
Les gens comme toi me fatiguent. Tu donnes des leçons, tu portes des jugements négatifs sur les gens sans même te renseigner sur les choses qui sont facilement vérifiables.
Honnêtement, je pense que le mouvement du logiciel libre gagnerait à avoir moins de donneurs de leçons comme toi, et plus de gens comme Zenitram.
Voilà.
[1]: "Si vous ne prenez pas un Zenitram, vous risquez de vous prendre une gamelle !"
Il y a que moi qui pense à cette pub à chaque fois que je vois son nom ?
« tout ce qui est utile en ce bas monde a été découvert et travaillé sans les dollars comme perspective »
Tu trouves pas ça un peu gros comme Troll ? Donc il n'y aurait aucune invention utile qui n'aurait jamais été faite pour de l'argent ? Toutes les inventions ont été faites de façon altruistes ?
Ou bien alors tu dois avoir une vision sacrément réductrice du mot utile.
Je pense en tout cas à l'anecdote du standard auto-commuté, inventé par un entrepreneur des pompes funèbres, qui en avait marre que son concurrent paye les demoiselles du téléphone pour qu'elles refilent systématiquement l'adresse du concurrent plutôt que la sienne.
Selon ta théorie, je n'arrive pas à choisir dans le cas de cette anecdote entre l'altruisme de ce croque-mort qui voulait que les client puissent avoir le choix de leur livreur de cercueil ou l'inutilité supposée de l'invention du standard de téléphone auto-commuté.
En tout cas, je partage complètement la vision de Zenitram. Faire des choses sans motivation financière, c'est bien, mais la motivation financière est une mesure intéressante du potentiel d'un projet quelconque.
A moins d'être rentier, il y a toujours un jour où tu devras faire un choix entre une activité qui rapporte pour te payer tes factures, ou faire du logiciel libre en altruiste.
Ca m'épate toujours ce principe des langage auto-hébergés. J'aimerai bien comprendre comment ca se décline en pratique.
J'imagine que tu compile le compilateur ou un sous-ensemble du compilateur avec gcc. Ca veut donc dire que tu maintiens un sous-ensemble du compilateur compilable en C. Ensuite, tu as ton compilateur, et hop, tu recompile la dernière version du compilateur ?
En tout cas, ça veut bien dire que le compilateur principal soit ne peut pas tirer partie des dernières fonctionnalités du langage, soit possède deux modes, un mode ou est il compilable avec une version précédente ou une version de bootstrap, et un mode ou il se compile lui-même ?
C'est pas contraignant de maintenir ce double-mode ?
Je réponds à la question : envie d'un Twitter rien qu'à vous ?
Non, vraiment je n'en ai pas envie. Je peine toujours à saisir comment écrire des messages de moins de 144 caractères et savoir en permanence ce que pensent 50 personnes de ce qu'ils font en ce moment est intéressant.
Je ne saisis pas non plus comment on peut suivre ce qui se passe sur Twitter et faire une autre activité en même temps. Perso, j'ai besoin de me concentrer pour bosser, et parler ou lire des conversations à tout va, ça nuit grandement à mon travail.
Je dois être soit trop vieux, soit trop cons, soit les deux en même temps. Ou bien juste autiste.
L'autre proposition qui a il me semble été acceptée est d'avoir toujours maintenant une implémentation en pur python de tous les modules C de la stdlib python.
Cela permettra à toutes les implémentations de python d'utiliser la stdlib. C'est un autre aspect qui fait que les implémentations de python alternatives restaient à la ramasse.
Si aujourd'hui, il est difficile de concevoir que les implémentations alternatives de Python deviennent aussi populaire que CPython, on peut en tout cas dire que GvR s'en donne les moyens.
Cela dit, ça résoudra pas la situation des numpy, PyQt et autres modules python en C.
Je fais souvent des softs PyQt pour windows, c'est assez facile. Py2exe ou pyinstaller marchent très bien. Et c'est trivial à packager par la suite avec InnoSetup.
J'aurai pas le temps de m'en occuper pour pymecavideo, mais tu peux t'inspirer de ce que j'ai fait sur d'autres softs.
Il faut regarder les fichiers make-exe.py et pyticroque-inno.in.iss
Je fonctionne avec un script python qui me fait à coup de ligne de commande :
- packaging en .exe
- packaging du .exe en installeur
- packaging du .exe en zip
- packaging des sources en zip
- upload de l'installeur, du zip et des sources
Je recommande fortement, ca permet de faire des release super vite.
Si t'as des questions, hésite pas à me contacter (phil at freehackers dot org)
J'étais tout réjoui de savoir que je pouvais scripter OO en python.
Jusqu'à ce que j'essaye.
De tête, si je me souviens bien :
- on peut utiliser uniquement la version de python livrée dans le repertoire d'OO. Pas de py2exe, pas de python standard
- par défaut, OO n'est pas scriptable en python. Il faut lancer un OO en mode serveur et à ce moment, on peut ouvrir d'autres OO qui serviront de client
- la façon de distribuer des scripts Python pour OO et de les lancer me semble hyper compliqué pour un utilisateur.
Du coup, j'ai regardé si je pouvais scripter Excel en python. En 10 minutes, j'ai réussi à faire ce que je voulais.
« Venir après pleurnicher que GNOME impose ses technos »
Je tiens à préciser que DBUS ne rentre pas pour moi dans la liste des technos imposées ou standardisée en force par Gnome.
Au contraire, c'est plutôt un modèle de comment il faut faire. Il y avait un besoin pour un outil, pour lequel DCOP avait des principes intéressants mais ne répondait pas à l'ensemble du besoin. Havoc avait donc un objectif clair, et a écouté très attentivement le feedback de KDE, les a intégré au processus (même si on peut regretter qu'ils n'aient pas été plus présent, comme tu le soulignes ils ont quand même participé).
Au final, la transition DCOP -> DBUS a pu se faire en douceur pour KDE, et KDE a pu profiter des avantages de DBUS par rapport à DCOP.
Ce processus de standardisation inter-desktop s'est produit plusieurs fois avec succès, avec par exemple les fichiers .desktop (format proposé par KDE), les notifications (spec conjointe KDE / Gnome basée sur XEmbed), les extensions du protocole X, les formats des thèmes. On trouve moins d'exemples récents cependant, probablement parce que les parties qui restent à faire collaborer sont autrement plus complexes.
Quand je parlais de technos Gnome qui veulent passer en force sur xdg, je pensais à des cas où la consultation de KDE n'a pas eu lieu, ou à des cas où elle a eu lieu mais les retours ont été ignorés.
« 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. »
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.
Apres, vouloir s'affranchir de qt3support est a priori une bonne idée mais pas du tout nécessaire.
« Parce que le support des différents moteurs multimédias dans Phonon est une catastrophe »
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.
« DCOP n'était pas utilisable dans un contexte autre que KDE. »
Tout à fait faux. Il y avait une dépendance à Qt du à l'utilisation de containers Qt. Il suffirait (dixit le concepteur) de quelques heures de travail pour en faire une implémentation indépendante. Ceci n'est pas différente de la situation actuelle ou l'implémentation de DBUS dépend si je m'abuse de gobject.
Il restait à DCOP la dépendance a libice qui est beaucoup moins pratique mais DCOP était tout à fait utilisable en dehors de KDE, et je crois même qu'il a été utilisé de façon très mineure sans KDE.
Mais on peut pas en même temps reprocher à KDE de réécrire des composants et lui reprocher d'utiliser un composant existant, à savoir libice.
« 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. »
Je serai curieux de savoir ce que DBUS empreinte a bonobo ou Corba. De ce que j'en sais, rien du tout. Pour moi, ca reste un DCOP amélioré.
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.
« J'admire comment les KDE-istes s'approprient DBus alors qu'ils l'ont royalement ignorés pendant plusieurs années. »
De mon point de vue, ils l'ont regardé avec scepticisme, puis curiosité, puis l'ont adapté au vu des apports majeurs en terme d'interopérabilité (alors que fondamentalement, DBUS apporte peu à KDE en comparaison de DCOP). En tout cas, j'appelle pas ça royalement ignorer.
« 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 »
Il semble que nous ayons tous les deux exemples concrets où la discussion n'a pas eu lieu et où des comportements anti-coopération ont eu lieu à la place, que ce soit pour des technos proposés par KDE ou par Gnome.
Notamment, on a vu des exemples récents de technos discutés sur freedesktop, 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.
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 ?
« 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. »
On doit pas avoir la même définition de « la plupart du temps ». Je dirai pour ma part que une fois sur deux, des développeurs provenant de Gnome tentent d'imposer des technos sur xdg sans tenir compte de l'existant de KDE ou bien encore des besoins de KDE pour permettre une adoption partagé.
Les exemples que tu as cité sont plutôt des réussites, mais n'effacent pas les autres tentatives d'abus de standardisation. Cela dit, ce n'est pas un choix politique de Gnome, c'est juste que certains développeurs n'ont pas compris le concept de standard et se prennent pour Microsoft.
« Ç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. »
Je suis d'accord mais en même temps, 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 (en encore).
Je sens le besoin d'apporter quelques commentaires :
« Contrairement à Qt3, Qt4 a été une rupture totale par rapport à son prédécesseur »
Alors, il faut pas exagérer. Qt4 a cassé la compatibilité source avec Qt3 mais ce n'est pas une rupture totale. On retrouve les mêmes concepts, il y a des pans entiers de la lib qui n'ont pas bougé.
Un portage Qt3 vers Qt4 d'une application moyenne totalement Qt prends quelques semaines.
« KDE n'a eu d'autres choix que de revoir les fondations »
Ca, c'est complètement faux. KDE avait différents choix possibles.
Lors de la dernière transition incompatible Qt2 vers Qt3, KDE a fait le choix de se contenter d'adapter KDE aux nouveaux concepts de Qt 3 de sorte que la sortie de KDE 3.0 n'a guère été plus difficile que la sortie d'une version 2.x .
La question s'est posée lors du passage à Qt 4 de reprendre la même stratégie et de faire une transition rapide et en douceur.
Après moultes discussions sur la mailing list, la conclusion a été que la base de code actuelle datant des années 2000 (première version de KDE 2), ce serait une bonne idée de profiter de la rupture de source de Qt pour retravailler le coeur de KDE et se donner la possibliité de faire des changements incompatibles.
Contrairement à ce que tu affirmes, 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.
A partir de là, KDE a pris quelques décisions importantes :
- le choix du demon pour le son arts s'est révélé mauvais. Pour ne plus reproduire ce schéma de dépendance, 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. 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 (ou bien il faut garder la même version de gstreamer sur tout le cycle KDE 4. Bof).
- en même temps, c'est la période ou Owen Taylor a commencé à pousser un protocole de communication de bureau commun à KDE et à Gnome, inspiré de DCOP. KDE a fait le choix de se séparer de DBUS et de passer à DCOP pour soutenir l'interopérabilité.
- le mainteneur de kicker a estimé que la quantité de travail pour le porter sur Qt4 et KDE4 serait supérieure à ce qu'il faudrait pour le réécrire. Qui plus est une réécriture permettrait de corriger pas mal de bugs, problèmes de conception et ouvrirait la voie pour des innovations. Cela a donné Plasma. Fondamentalement, plasma aurait pu être introduit au dessus de KDE3 / Qt3 en dépréciant progressivement kicker et autres.
- KWIN n'a presque pas bougé, le mainteneur en a juste profité pour tirer partie des derniers progrès de Xorg pour rajouter des fonctionnalités populaires (transparence, 3D, ...)
- akonadi était déjà en gestation face à la complexité de maintenir des informations de contact à travers plusieurs applications (KMail, Konteact, Konverstation, ....)
- kio n'a pas bougé, kconfig non plus, kpart non plus, toutes ces technos qui tournent depuis 10 ans chez KDE restent de bonne facture.
Au final, la transition a été longue et douloureuse, mais pour permettre un futur plus tranquille.
Un mot sur DBUS vs DCOP. Contrairement à ce qui a été dit plus haut, DBUS est bien une adaptation plus de DCOP. On y retrouve tous les concepts de DCOP. Les changements ont été de se passer de ICE (la couche d'échange utilisée par DCOP) pour une couche plus bas niveau. Le noyau ayant évolué depuis le temps ou DCOP a été conçu, une intégration plus basse a pu être possible.
Je salue la réussite du plan de communication de Gnome, qui a réussi à mettre à la poubelle tout ce qu'était bonobo en arrivant à faire croire aujourd'hui qu'il s'agissait d'une transition.
La grande force de DBUS, c'est de ne pas apparaitre comme une techno KDE mais une techno neutre, poussée par Red Hat. Ca et une conception légèrement plus moderne ont permis son adaption par Gnome.
Je salue l'ouverture de KDE qui a accepté, au nom de l'interopérabilité, de renoncer à une techno qu'il avait développé lui-même (basée sur ICE comme le rappelle fort justement mon contradicteur) pour adopter une réécriture du même concpet par Gnome.
Je salue l'ouverture de Gnome qui a accepté une techno KDE maquillée sous une rééecriture. Je me rappellerai d'ailleurs toujours ce mail sur kde-core-devel de Owen : «if you think it's hard to convince KDE to adopt DBUS, think how hard it is for me to convince Gnome to adopt it ».
« C'est pas un mystère que les développeurs KDE se font rares sur FreeDesktop. »
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.
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 ».
Notamment, on a vu plusieurs fois le scenario suivant se répéter :
- une techno existe chez KDE pour gérer une problématique (les thèmes, les notifications, etc)
- un développeur chez Gnome décide de répondre à la même problématique pour le bureau Gnome
- il développe sa techno sans regarder ce qui a été fait chez KDE
- il ignore les suggestions et remarques des développeurs de KDE qui proposent de rendre le système interopérable avec l'existant, ou bien adapté aux besoins de KDE
- après quelques années, il trouve que son truc est bien et le déclare comme un standard sur xdg
- il joue les vierge offusquées quand KDE expose les raisons pour lesquelles ledit standard ne pourra pas être adopté par KDE, raisons qui ont été exposés avant même que le développement dudit bousin aie commencé, et raisons qui ont été royalement ignorées.
Ce scenario s'est reproduit plusieurs fois, au point que freedesktop-xdg a failli être dissous. Je t'invite à lire les messages de cette liste d'il y a un an ou deux pour voir la chose en réel.
Heureusement, freedesktop a plus de succès à son actif que d'échec mais la technique « je déclare ma techno proprio comme un standard et KDE est un gros con parce qu'il l'utilise pas », ca énerve.
Je suis triste de constater d'ailleurs que dans l'esprit des gens, c'est KDE le mauvais joueur.
C'est quand même un peu facile de mettre tout sur le dos de Microsoft. Genre sans Microsoft, la norme aurait été pondue en deux mois et de façon impeccable.
On pourrait tout aussi bien dire que c'est la faute de Red Hat et Sun et KDE, qui n'ont pas employé assez de monde pour se concentrer uniquement sur ce sujet stratégique qu'est ODF et que à cause de ça, ca avance lentement. Et ça se tient tout à fait, si chacune des boites du libre avait dépéché 30 mecs qui avaient passé plusieurs années à plancher et sur ODF, et sur la norme Ms, ODF 1.2 serait sorti bien plus vite.
D'ailleurs, je soupçonne aussi que l'obésité est responsable de ce retard: en effet, l'obésité entraîne une baisse de fertilité, ce qui diminue la population, donc le nombre d'informaticiens et au passage, le nombre d'informaticiens capable d'intervenir sur la norme ODF.
Sus au hamburger, comme ça, on aura ODF 1.3 bien plus rapidement !
Trêve de plaisanterie, je rejoins PBPG, t'es pas crédible à raconter que tout est la faute de MS.
C'est bien plus crédible de souligner la difficulté de faire une norme interopérable, sur des sujets aussi complexe que ce que vise ODF, et qu'il a fallu aussi tenir compte du feedback de ODF 1.1 qui montre des interprétations divergentes, et que les gens ont aussi été occupé à sortir des nouvelles versions de leurs logiciels (OpenOffice, KOffice en tout cas).
Bref, moins de mauvaise foi, plus d'infos, ça fait toujours du bien.
J'aime bien aussi, je m'en suis servi pour debugger un peu des services XMLRPC .
C'est aussi pratique pour savoir si il y a du monde qui "téléphone à la maison".
Par contre, pour une utilisation rapide, impossible pour moi de comprendre quoi que ce soit aux filtres et surlignement. Je m'en suis sorti sans mais ça a pas l'air trivial.
Je suis d'accord. Je trouve ça notamment bizarre que il soit possible d'utiliser le mode raster en passant un argument en ligne de commande, mais que pour l'utiliser par défaut, il faille recompiler Qt.
D'autant plus qu'il me semble que Qt a maintenant un petit fichier de config dans le répertoire utilisateur.
« Il y a juste des probabilités importante qu'un logiciel libre soit plus "propre" qu'un logiciel propriétaire qui est souvent écrit vite dans le but d'être rentable le plus rapidement possible. »
C'est vraiment de la généralisation à deux balles.
Ce n'est pas parce qu' un logiciel est propriétaire qu'il a des deadline absolues.
Ce n'est pas non plus parce qu'un logiciel est propriétaire que le département responsable de la qualité du code n'intervient pas pour protester.
Ce n'est pas parce qu'un logiciel est libre et a du temps pour sortir ses versions qu'il n'est pas écrit par un pauvre étudiant qui débute en programmation et te fous plein de bugs partout.
Ce n'est pas parce qu'un logiciel est libre qu'un contributeur bénévole a du temps pour corriger tous les bugs identifiés.
Au final, je pense que les probabilités d'avoir du bon code dans un logiciel sont équivalentes en libre comme en proprio. La seule différence, c'est que sur du proprio, tu ne peux en général pas le vérifier.
J'ai vu pour ma part autant de bouses en logiciel libre qu'en logiciel proprio.
Moi je fais aussi des fichiers de config en python, mais j'évite d'y mettre des structures complexes comme des classes. Mes fichiers de config python ne contiennent que des listes, de chaînes de caractères, des dictionnaires et des nombres. Pour les parser, j'utilise safe_eval : http://code.activestate.com/recipes/496746/
Pour moi les avantages sont les suivantes :
- je garde la distinction entre fichier de config contenant des données et fichier exécutable
- le format est super facile à faire évoluer
- c'est très facile à modifier même quand on est pas développeur.
Cher Fabien, je pense que tu es profondément naïf sur la réalité du fonctionnement du business des jeux video.
Le modèle que tu décris a vraiment très très peu de chance de rentabiliser un jeu video. Une chance infime. Qq'un qui a investi énormément de son temps à développer un jeu video de bonne qualité ne va pas prendre le risque de tout perdre pour la beauté des remerciements sur linuxfr.
[^] # Re: Avant après
Posté par Philippe F (site web personnel) . En réponse au journal Journal inutile : Python c'est complêtement pourri, j'ai un exemple. Évalué à 2.
au moins, avec subprocess, tu as une interface stable, qui couvre tous les besoins d'utilisation.
[^] # Re: Lames recyclables?
Posté par Philippe F (site web personnel) . En réponse au journal Des rasoirs de sûreté. Évalué à 1.
Tout ceci n'est qu'une hypothèse.
[^] # Re: Les partenaires...
Posté par Philippe F (site web personnel) . En réponse à la dépêche WebM : un format libre et ouvert pour HTML5. Évalué à 10.
> parce qu'avec le modèle proprio, ton mediainfo, il sera pas sorti de ton garage.
Qu'est ce que tu en sais ? Tu supposes que parce que son logiciel est libre, il a tout d'un coup été téléchargé par des dizaines de milliers d'utilisateurs et que aujourd'hui, c'est grâce à ça qu'il peut en vivre.
Moi j'imagine plutôt que Zenitram est un spécialiste des logiciels vidéo, qu'il avait déjà un solide carnet d'adresse et de clients potentiels, une bonne connaissance du marché et que quand il a lancé son soft, il avait déjà des acheteurs. Et que l'aspect logiciel libre n'a peut-être pas du tout pesé dans la décision de ses clients.
De ce point de vue là, choisir de rendre libre une partie de son logiciel n'etait pas une obligation mais réellement un engagement en faveur du logiciel libre.
Mais en l'absence d'information, tu présupposes que le libre est le grand Zorro qui a sorti Zenitram de sa misère. Mais bien sur !
> tu n'est clairement pas un libriste activiste
Parce qu'il est capable de voir les défauts de theora au lieu de l'encenser sans le connaître, il n'est pas un activiste de logiciel libre ? C'est vraiment des jugements pathétiques.
Ca me fait penser à l'époque ou Gnome encensait Corba et ORBIT, l'implémentation de Corba utilisé pour l'occasion. A l'époque KDE ayant soumis l'idée que Corba était une grosse bouse pour les besoins du desktop, on a porté sur eux le même type de jugement que celui que tu portes sur Zenitram.
Faire du logiciel libre ne veut pas dire embrasser aveuglément toutes les technos libres sans voir leurs avantages et leurs défauts. 10 ans après, plus personne chez les développeurs de Gnome n'oserait encore dire que Corba était une bonne idée.
> tu n'es peut être même pas un libriste par conviction
Zenitram [1] a expliqué qu'il a implémenté la partie Vorbis et Ogg uniquement parce que des barbus le lui demandaient. Moi je trouve que ça ressemble bien plus à un libriste de conviction.
> Parce qu'avec le modèle proprio, tu pourrais pas utiliser toutes les libs que tu utilises
Par curiosité, je suis allé voir les dépendances de MediaInfoLib et les licences associées :
- Zlib.lib: BSD
- Id3Lib.lib: LGPL
- Zenlib.lib: BSD
- Ebml.lib: LGPL
- Matroska.lib: LGPL
- WxBase.lib (part of wxWidgets project): LGPL
- Flac.lib (Flac and Flac++): BSD
Donc visiblement, il pourrait tout à fait développer MediaInfo en tant que logiciel proprio, toutes les licences le permettent.
C'était donc encore une affirmation à deux balles. Et c'est bien par choix et non par obligation que Zenitram en a fait un logiciel ouvert (en grande partie si j'ai bien saisi).
> Parce qu'avec le modèle proprio, tu n'aurais pas eu cette "libre diffusion" qui a assuré une partie du "se faire connaitre"
Ou à l'inverse, parce que sans la partie proprio Zenitram ne pourrait pas en vivre et le monde du logiciel libre n'aurait jamais un logiciel de la qualité de MediaInfo.
> Parce qu'avec le modèle proprio, tu n'aurais pas eu les entreprises qui l'utilisent parce que c'est gratuit et qui te demande de développer un truc en plus.
Encore une affirmation à deux balles. Il aurait pu aussi en faire un freeware permettant aux entreprises de l'utiliser et avoir quand même une très bonne notoriété. Il y a des milliers de logiciels qui vivent sur ce modèle économique. Et peut-être gagnerait-il bien plus d'argent avec les licences qu'il n'en gagne aujourd'hui à faire du dev "à la demande".
Les gens comme toi me fatiguent. Tu donnes des leçons, tu portes des jugements négatifs sur les gens sans même te renseigner sur les choses qui sont facilement vérifiables.
Honnêtement, je pense que le mouvement du logiciel libre gagnerait à avoir moins de donneurs de leçons comme toi, et plus de gens comme Zenitram.
Voilà.
[1]: "Si vous ne prenez pas un Zenitram, vous risquez de vous prendre une gamelle !"
Il y a que moi qui pense à cette pub à chaque fois que je vois son nom ?
[^] # Re: WebM est sacrément bien parti...
Posté par Philippe F (site web personnel) . En réponse au journal VP8 libéré, WebM est né. Évalué à 2.
Tu trouves pas ça un peu gros comme Troll ? Donc il n'y aurait aucune invention utile qui n'aurait jamais été faite pour de l'argent ? Toutes les inventions ont été faites de façon altruistes ?
Ou bien alors tu dois avoir une vision sacrément réductrice du mot utile.
Je pense en tout cas à l'anecdote du standard auto-commuté, inventé par un entrepreneur des pompes funèbres, qui en avait marre que son concurrent paye les demoiselles du téléphone pour qu'elles refilent systématiquement l'adresse du concurrent plutôt que la sienne.
Selon ta théorie, je n'arrive pas à choisir dans le cas de cette anecdote entre l'altruisme de ce croque-mort qui voulait que les client puissent avoir le choix de leur livreur de cercueil ou l'inutilité supposée de l'invention du standard de téléphone auto-commuté.
En tout cas, je partage complètement la vision de Zenitram. Faire des choses sans motivation financière, c'est bien, mais la motivation financière est une mesure intéressante du potentiel d'un projet quelconque.
A moins d'être rentier, il y a toujours un jour où tu devras faire un choix entre une activité qui rapporte pour te payer tes factures, ou faire du logiciel libre en altruiste.
[^] # Re: Mouais
Posté par Philippe F (site web personnel) . En réponse au journal Et le gagnant est....... Évalué à 1.
[^] # Re: While.... mais pas de Do.... While
Posté par Philippe F (site web personnel) . En réponse à la dépêche Le langage ooc auto-hébergé - les nouveautés de rock 0.9.0. Évalué à 2.
--> []
# Langage auto-hébergé
Posté par Philippe F (site web personnel) . En réponse à la dépêche Le langage ooc auto-hébergé - les nouveautés de rock 0.9.0. Évalué à 1.
J'imagine que tu compile le compilateur ou un sous-ensemble du compilateur avec gcc. Ca veut donc dire que tu maintiens un sous-ensemble du compilateur compilable en C. Ensuite, tu as ton compilateur, et hop, tu recompile la dernière version du compilateur ?
En tout cas, ça veut bien dire que le compilateur principal soit ne peut pas tirer partie des dernières fonctionnalités du langage, soit possède deux modes, un mode ou est il compilable avec une version précédente ou une version de bootstrap, et un mode ou il se compile lui-même ?
C'est pas contraignant de maintenir ce double-mode ?
# NON
Posté par Philippe F (site web personnel) . En réponse à la dépêche Microblogging : envie d'un Twitter rien qu'à vous ?. Évalué à 6.
Non, vraiment je n'en ai pas envie. Je peine toujours à saisir comment écrire des messages de moins de 144 caractères et savoir en permanence ce que pensent 50 personnes de ce qu'ils font en ce moment est intéressant.
Je ne saisis pas non plus comment on peut suivre ce qui se passe sur Twitter et faire une autre activité en même temps. Perso, j'ai besoin de me concentrer pour bosser, et parler ou lire des conversations à tout va, ça nuit grandement à mon travail.
Je dois être soit trop vieux, soit trop cons, soit les deux en même temps. Ou bien juste autiste.
[^] # Re: Vitesse
Posté par Philippe F (site web personnel) . En réponse à la dépêche Actualités Python : PyPy 1.2, distutils2, vidéos de Pycon 2010, Python 2.7. Évalué à 2.
Cela permettra à toutes les implémentations de python d'utiliser la stdlib. C'est un autre aspect qui fait que les implémentations de python alternatives restaient à la ramasse.
Si aujourd'hui, il est difficile de concevoir que les implémentations alternatives de Python deviennent aussi populaire que CPython, on peut en tout cas dire que GvR s'en donne les moyens.
Cela dit, ça résoudra pas la situation des numpy, PyQt et autres modules python en C.
[^] # Re: Premier Appel
Posté par Philippe F (site web personnel) . En réponse au journal Pymecavideo devient multiplateforme. Évalué à 2.
Si t'es motivé, je suis preneur. C'est p'tet moins gratifiant que pour un jeu éducatif, mais contribuer au libre, c'est toujours contribuer !
# Trucs pour la version Windows
Posté par Philippe F (site web personnel) . En réponse au journal Pymecavideo devient multiplateforme. Évalué à 6.
J'aurai pas le temps de m'en occuper pour pymecavideo, mais tu peux t'inspirer de ce que j'ai fait sur d'autres softs.
Par exemple :
http://labs.freehackers.org/projects/pyticroque/repository/s(...)
Il faut regarder les fichiers make-exe.py et pyticroque-inno.in.iss
Je fonctionne avec un script python qui me fait à coup de ligne de commande :
- packaging en .exe
- packaging du .exe en installeur
- packaging du .exe en zip
- packaging des sources en zip
- upload de l'installeur, du zip et des sources
Je recommande fortement, ca permet de faire des release super vite.
Si t'as des questions, hésite pas à me contacter (phil at freehackers dot org)
# Scripter OpenOffice en python : bof !
Posté par Philippe F (site web personnel) . En réponse à la dépêche OpenOffice.org 3.2 est disponible. Évalué à 2.
Jusqu'à ce que j'essaye.
De tête, si je me souviens bien :
- on peut utiliser uniquement la version de python livrée dans le repertoire d'OO. Pas de py2exe, pas de python standard
- par défaut, OO n'est pas scriptable en python. Il faut lancer un OO en mode serveur et à ce moment, on peut ouvrir d'autres OO qui serviront de client
- la façon de distribuer des scripts Python pour OO et de les lancer me semble hyper compliqué pour un utilisateur.
Du coup, j'ai regardé si je pouvais scripter Excel en python. En 10 minutes, j'ai réussi à faire ce que je voulais.
J'espère que la situation s'est améliorée...
[^] # Re: migration?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Accessibilité: Oracle prend Sun mais se débarrasse de Willie Walker. Évalué à 3.
Je tiens à préciser que DBUS ne rentre pas pour moi dans la liste des technos imposées ou standardisée en force par Gnome.
Au contraire, c'est plutôt un modèle de comment il faut faire. Il y avait un besoin pour un outil, pour lequel DCOP avait des principes intéressants mais ne répondait pas à l'ensemble du besoin. Havoc avait donc un objectif clair, et a écouté très attentivement le feedback de KDE, les a intégré au processus (même si on peut regretter qu'ils n'aient pas été plus présent, comme tu le soulignes ils ont quand même participé).
Au final, la transition DCOP -> DBUS a pu se faire en douceur pour KDE, et KDE a pu profiter des avantages de DBUS par rapport à DCOP.
Ce processus de standardisation inter-desktop s'est produit plusieurs fois avec succès, avec par exemple les fichiers .desktop (format proposé par KDE), les notifications (spec conjointe KDE / Gnome basée sur XEmbed), les extensions du protocole X, les formats des thèmes. On trouve moins d'exemples récents cependant, probablement parce que les parties qui restent à faire collaborer sont autrement plus complexes.
Quand je parlais de technos Gnome qui veulent passer en force sur xdg, je pensais à des cas où la consultation de KDE n'a pas eu lieu, ou à des cas où elle a eu lieu mais les retours ont été ignorés.
[^] # Re: migration?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Accessibilité: Oracle prend Sun mais se débarrasse de Willie Walker. Évalué à 3.
Maintenant que nous somme plus ou moins d'accord, il reste plus quà nous serrer la main respectueusement en souhaitant bon vent...
[^] # Re: migration?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Accessibilité: Oracle prend Sun mais se débarrasse de Willie Walker. Évalué à 5.
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.
Apres, vouloir s'affranchir de qt3support est a priori une bonne idée mais pas du tout nécessaire.
« Parce que le support des différents moteurs multimédias dans Phonon est une catastrophe »
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.
« DCOP n'était pas utilisable dans un contexte autre que KDE. »
Tout à fait faux. Il y avait une dépendance à Qt du à l'utilisation de containers Qt. Il suffirait (dixit le concepteur) de quelques heures de travail pour en faire une implémentation indépendante. Ceci n'est pas différente de la situation actuelle ou l'implémentation de DBUS dépend si je m'abuse de gobject.
Il restait à DCOP la dépendance a libice qui est beaucoup moins pratique mais DCOP était tout à fait utilisable en dehors de KDE, et je crois même qu'il a été utilisé de façon très mineure sans KDE.
Mais on peut pas en même temps reprocher à KDE de réécrire des composants et lui reprocher d'utiliser un composant existant, à savoir libice.
« 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. »
Je serai curieux de savoir ce que DBUS empreinte a bonobo ou Corba. De ce que j'en sais, rien du tout. Pour moi, ca reste un DCOP amélioré.
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.
« J'admire comment les KDE-istes s'approprient DBus alors qu'ils l'ont royalement ignorés pendant plusieurs années. »
De mon point de vue, ils l'ont regardé avec scepticisme, puis curiosité, puis l'ont adapté au vu des apports majeurs en terme d'interopérabilité (alors que fondamentalement, DBUS apporte peu à KDE en comparaison de DCOP). En tout cas, j'appelle pas ça royalement ignorer.
« 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 »
Il semble que nous ayons tous les deux exemples concrets où la discussion n'a pas eu lieu et où des comportements anti-coopération ont eu lieu à la place, que ce soit pour des technos proposés par KDE ou par Gnome.
Notamment, on a vu des exemples récents de technos discutés sur freedesktop, 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.
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 ?
« 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. »
On doit pas avoir la même définition de « la plupart du temps ». Je dirai pour ma part que une fois sur deux, des développeurs provenant de Gnome tentent d'imposer des technos sur xdg sans tenir compte de l'existant de KDE ou bien encore des besoins de KDE pour permettre une adoption partagé.
Les exemples que tu as cité sont plutôt des réussites, mais n'effacent pas les autres tentatives d'abus de standardisation. Cela dit, ce n'est pas un choix politique de Gnome, c'est juste que certains développeurs n'ont pas compris le concept de standard et se prennent pour Microsoft.
« Ç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. »
Je suis d'accord mais en même temps, 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 (en encore).
[^] # Re: migration?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Accessibilité: Oracle prend Sun mais se débarrasse de Willie Walker. Évalué à 9.
« Contrairement à Qt3, Qt4 a été une rupture totale par rapport à son prédécesseur »
Alors, il faut pas exagérer. Qt4 a cassé la compatibilité source avec Qt3 mais ce n'est pas une rupture totale. On retrouve les mêmes concepts, il y a des pans entiers de la lib qui n'ont pas bougé.
Un portage Qt3 vers Qt4 d'une application moyenne totalement Qt prends quelques semaines.
« KDE n'a eu d'autres choix que de revoir les fondations »
Ca, c'est complètement faux. KDE avait différents choix possibles.
Lors de la dernière transition incompatible Qt2 vers Qt3, KDE a fait le choix de se contenter d'adapter KDE aux nouveaux concepts de Qt 3 de sorte que la sortie de KDE 3.0 n'a guère été plus difficile que la sortie d'une version 2.x .
La question s'est posée lors du passage à Qt 4 de reprendre la même stratégie et de faire une transition rapide et en douceur.
Après moultes discussions sur la mailing list, la conclusion a été que la base de code actuelle datant des années 2000 (première version de KDE 2), ce serait une bonne idée de profiter de la rupture de source de Qt pour retravailler le coeur de KDE et se donner la possibliité de faire des changements incompatibles.
Contrairement à ce que tu affirmes, 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.
A partir de là, KDE a pris quelques décisions importantes :
- le choix du demon pour le son arts s'est révélé mauvais. Pour ne plus reproduire ce schéma de dépendance, 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. 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 (ou bien il faut garder la même version de gstreamer sur tout le cycle KDE 4. Bof).
- en même temps, c'est la période ou Owen Taylor a commencé à pousser un protocole de communication de bureau commun à KDE et à Gnome, inspiré de DCOP. KDE a fait le choix de se séparer de DBUS et de passer à DCOP pour soutenir l'interopérabilité.
- le mainteneur de kicker a estimé que la quantité de travail pour le porter sur Qt4 et KDE4 serait supérieure à ce qu'il faudrait pour le réécrire. Qui plus est une réécriture permettrait de corriger pas mal de bugs, problèmes de conception et ouvrirait la voie pour des innovations. Cela a donné Plasma. Fondamentalement, plasma aurait pu être introduit au dessus de KDE3 / Qt3 en dépréciant progressivement kicker et autres.
- KWIN n'a presque pas bougé, le mainteneur en a juste profité pour tirer partie des derniers progrès de Xorg pour rajouter des fonctionnalités populaires (transparence, 3D, ...)
- akonadi était déjà en gestation face à la complexité de maintenir des informations de contact à travers plusieurs applications (KMail, Konteact, Konverstation, ....)
- kio n'a pas bougé, kconfig non plus, kpart non plus, toutes ces technos qui tournent depuis 10 ans chez KDE restent de bonne facture.
Au final, la transition a été longue et douloureuse, mais pour permettre un futur plus tranquille.
Un mot sur DBUS vs DCOP. Contrairement à ce qui a été dit plus haut, DBUS est bien une adaptation plus de DCOP. On y retrouve tous les concepts de DCOP. Les changements ont été de se passer de ICE (la couche d'échange utilisée par DCOP) pour une couche plus bas niveau. Le noyau ayant évolué depuis le temps ou DCOP a été conçu, une intégration plus basse a pu être possible.
Je salue la réussite du plan de communication de Gnome, qui a réussi à mettre à la poubelle tout ce qu'était bonobo en arrivant à faire croire aujourd'hui qu'il s'agissait d'une transition.
La grande force de DBUS, c'est de ne pas apparaitre comme une techno KDE mais une techno neutre, poussée par Red Hat. Ca et une conception légèrement plus moderne ont permis son adaption par Gnome.
Je salue l'ouverture de KDE qui a accepté, au nom de l'interopérabilité, de renoncer à une techno qu'il avait développé lui-même (basée sur ICE comme le rappelle fort justement mon contradicteur) pour adopter une réécriture du même concpet par Gnome.
Je salue l'ouverture de Gnome qui a accepté une techno KDE maquillée sous une rééecriture. Je me rappellerai d'ailleurs toujours ce mail sur kde-core-devel de Owen : «if you think it's hard to convince KDE to adopt DBUS, think how hard it is for me to convince Gnome to adopt it ».
« C'est pas un mystère que les développeurs KDE se font rares sur FreeDesktop. »
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.
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 ».
Notamment, on a vu plusieurs fois le scenario suivant se répéter :
- une techno existe chez KDE pour gérer une problématique (les thèmes, les notifications, etc)
- un développeur chez Gnome décide de répondre à la même problématique pour le bureau Gnome
- il développe sa techno sans regarder ce qui a été fait chez KDE
- il ignore les suggestions et remarques des développeurs de KDE qui proposent de rendre le système interopérable avec l'existant, ou bien adapté aux besoins de KDE
- après quelques années, il trouve que son truc est bien et le déclare comme un standard sur xdg
- il joue les vierge offusquées quand KDE expose les raisons pour lesquelles ledit standard ne pourra pas être adopté par KDE, raisons qui ont été exposés avant même que le développement dudit bousin aie commencé, et raisons qui ont été royalement ignorées.
Ce scenario s'est reproduit plusieurs fois, au point que freedesktop-xdg a failli être dissous. Je t'invite à lire les messages de cette liste d'il y a un an ou deux pour voir la chose en réel.
Heureusement, freedesktop a plus de succès à son actif que d'échec mais la technique « je déclare ma techno proprio comme un standard et KDE est un gros con parce qu'il l'utilise pas », ca énerve.
Je suis triste de constater d'ailleurs que dans l'esprit des gens, c'est KDE le mauvais joueur.
[^] # Re: Hahaha
Posté par Philippe F (site web personnel) . En réponse au journal ODF 1.2 part 1 pret pour les revisions. Évalué à 4.
On pourrait tout aussi bien dire que c'est la faute de Red Hat et Sun et KDE, qui n'ont pas employé assez de monde pour se concentrer uniquement sur ce sujet stratégique qu'est ODF et que à cause de ça, ca avance lentement. Et ça se tient tout à fait, si chacune des boites du libre avait dépéché 30 mecs qui avaient passé plusieurs années à plancher et sur ODF, et sur la norme Ms, ODF 1.2 serait sorti bien plus vite.
D'ailleurs, je soupçonne aussi que l'obésité est responsable de ce retard: en effet, l'obésité entraîne une baisse de fertilité, ce qui diminue la population, donc le nombre d'informaticiens et au passage, le nombre d'informaticiens capable d'intervenir sur la norme ODF.
Sus au hamburger, comme ça, on aura ODF 1.3 bien plus rapidement !
Trêve de plaisanterie, je rejoins PBPG, t'es pas crédible à raconter que tout est la faute de MS.
C'est bien plus crédible de souligner la difficulté de faire une norme interopérable, sur des sujets aussi complexe que ce que vise ODF, et qu'il a fallu aussi tenir compte du feedback de ODF 1.1 qui montre des interprétations divergentes, et que les gens ont aussi été occupé à sortir des nouvelles versions de leurs logiciels (OpenOffice, KOffice en tout cas).
Bref, moins de mauvaise foi, plus d'infos, ça fait toujours du bien.
[^] # Re: Alternatives ?
Posté par Philippe F (site web personnel) . En réponse au journal WireShark la capture réseau. Évalué à 2.
C'est aussi pratique pour savoir si il y a du monde qui "téléphone à la maison".
Par contre, pour une utilisation rapide, impossible pour moi de comprendre quoi que ce soit aux filtres et surlignement. Je m'en suis sorti sans mais ça a pas l'air trivial.
[^] # Re: Fichier de config
Posté par Philippe F (site web personnel) . En réponse au journal En finir avec la lourdeur de KDE. Évalué à 3.
D'autant plus qu'il me semble que Qt a maintenant un petit fichier de config dans le répertoire utilisateur.
[^] # Re: Diantre
Posté par Philippe F (site web personnel) . En réponse à la dépêche Jabber.org se tourne vers un serveur propriétaire. Évalué à 5.
C'est vraiment de la généralisation à deux balles.
Ce n'est pas parce qu' un logiciel est propriétaire qu'il a des deadline absolues.
Ce n'est pas non plus parce qu'un logiciel est propriétaire que le département responsable de la qualité du code n'intervient pas pour protester.
Ce n'est pas parce qu'un logiciel est libre et a du temps pour sortir ses versions qu'il n'est pas écrit par un pauvre étudiant qui débute en programmation et te fous plein de bugs partout.
Ce n'est pas parce qu'un logiciel est libre qu'un contributeur bénévole a du temps pour corriger tous les bugs identifiés.
Au final, je pense que les probabilités d'avoir du bon code dans un logiciel sont équivalentes en libre comme en proprio. La seule différence, c'est que sur du proprio, tu ne peux en général pas le vérifier.
J'ai vu pour ma part autant de bouses en logiciel libre qu'en logiciel proprio.
[^] # Re: Désinscriptions
Posté par Philippe F (site web personnel) . En réponse au journal Web 2.0 Suicide Machine. Évalué à 4.
Les scripts qu'ils ont mis en place vont supprimer une par une toutes ces informations avant de fermer ton compte.
[^] # Re: Code source
Posté par Philippe F (site web personnel) . En réponse au journal Web 2.0 Suicide Machine. Évalué à 6.
Améliorable ne veut pas dire qu'elle sera améliorée. Combien de logiciels libres pourrissent avec un seul unique contributeur dans son coin ?
[^] # Re: Vachement gore
Posté par Philippe F (site web personnel) . En réponse au journal Nagios va-t-il quitter le C pour le Python?. Évalué à 3.
http://code.activestate.com/recipes/364469/
[^] # Re: Vachement gore
Posté par Philippe F (site web personnel) . En réponse au journal Nagios va-t-il quitter le C pour le Python?. Évalué à 3.
http://code.activestate.com/recipes/496746/
Pour moi les avantages sont les suivantes :
- je garde la distinction entre fichier de config contenant des données et fichier exécutable
- le format est super facile à faire évoluer
- c'est très facile à modifier même quand on est pas développeur.
[^] # Re: gratte-gratte ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Machinarium, un nouveau jeu pour Linux. Évalué à 2.
Le modèle que tu décris a vraiment très très peu de chance de rentabiliser un jeu video. Une chance infime. Qq'un qui a investi énormément de son temps à développer un jeu video de bonne qualité ne va pas prendre le risque de tout perdre pour la beauté des remerciements sur linuxfr.