Philippe F a écrit 2225 commentaires

Et en plus, ils ont choisi une licence qui favorise le développement proprio !

Moi, ce qui m'inquiète pour Gnome, c'est Gtk.


Parce que Gtk a beau être plus ou moins libre (la LGPL, ça vaut quand même pas une bonne GPL), RedHat (principal contributeur de Gtk) pourrait bien l'orienter principalement vers l'embarqué. Voire même l'orienter exclusivement vers l'embarqué.


En plus, autant pour Qt, on a la FreeQt Foundation ( http://www.kde.org/community/whatiskde/kdefreeqtfoundation.p(...) ) qui garantit que Qt sera toujours GPL si Nokia abandonne le projet, autant pour Gtk, on a pas du tout ce type de garantie. Si Redhat décide un jour d'arrêter son investissement dans Gtk, la bibliothèque va sérieusement se retrouver au ralenti.

Euh, ce que tu dis tends plutôt à prouver qu'ils ne savaient pas ce qu'il faisaient, non ? Sinon, ils n'auraient pas laisser cette image 3 jours de suite. Et ils ne t'auraient pas accusé d'avoir piraté leur site web.

J'aurai au moins mentionné dans l'image qu'elle est utilisée illégalement par le site en question. Ca fait toujours plus réagir quand tous les utilisateurs voient qu'on fait quelque chose d'illégal.

Moi je pense plutôt que c'est la faute à Martine Aubry avec les 35 heures, et surtout à Linux qu'un tout pourrite.

Kate permet d'utiliser quelques commandes vim, mais pas tant que ça. Et tout les scripts ne sont pas supportés.

Vim a encore de longues années devant lui !

Unladen Swallow qui est d'ailleurs au point mort depuis plusieurs mois. Les seuls contributeurs encore actifs sont un stagiaire et un mec extérieur à google, visiblement bénévole...

Après avoir essayé mercurial puis git, je trouve mercurial mieux. Même si il y a qqes fonctionnalités qu'on ne retrouve pas dans mercurial par rapport à git, je trouve le projet beaucoup plus simple d'approche :
- les commandes ont des noms relativement intuitifs
- il y a moins de commandes
- la doc et le tutorial sont très bien foutus
- ca marche nickel sous windows, alors que j'ai eu des problèmes avec git
- au niveau GUI, ceux que j'ai eu l'occasion d'utiliser pour git me donnait l'impression d'être dans les années 80. Alors que avec TortoiseHg ou hgtk, j'ai plus l'impression d'être au 21e siècle.

A mon sens, git, même s'il est très puissant souffre d'un côté hardcore developer qu'on ne retrouve pas sous mercurial. Et ça s'en ressent, dans les doc, dans le tutoriaux, dans les GUI, dans les messages d'erreurs, dans l'aide des commandes, etc.

git a quand même été développé par un mec qui gérait des milliers de patch avec l'email comme seul outil.

Il est d'ailleurs significatif que des gens qui apprécient git se permettent de t'expliquer que tu as tort de ne pas utiliser la ligne de commande.

Sinon, hg, c'est quand même un caractère de moins à taper que git, faut surtout pas l'oublier.

Skype optimise à mort et fait du PC à PC si les deux PC sont sur le même réseau. Et si jamais ton PC est sur une IP publique, il servira même de relai à d'autres PC skype et donc la comme ne passera pas par les serveurs skype. D'un point de vue architecture, ils assurent !

Mon Dell XPS M1330 (pas sous ubuntu, certe) se porte comme un charme. Pourtant je l'ouvre et le ferme plusieurs fois par jour :
- ouverture/fermeture sur le quai de la gare en attendant mon train
- ouverture/fermeture dans le train pendant les 15 minutes de trajet
- ouverture/fermeture dans le RER pendant 5 minutes (pour finir de taper mes documents)
- utilisation au boulot avec branchage de prise USB, RJ75, VGA
- départ du boulot ou j'arrache toutes les prises comme un sauvage
- ouverture/fermeture sur le quai de la gare en attendant mon train
- ouverture/fermeture dans le train pendant les 15 minutes de trajet
- pafois rebranchage à la maison

Malgré toutes ces ouvertures / fermetures et branchage / débranchage intempestifs, il tourne toujours aussi bien. Meme pas encore vu de fragilité sur les divers connecteurs.

Comme quoi, parfois, le matos resiste.

L'article semble surtout dire que les failles seraient plus facilement exploitables par la disponibilité du code source, ce qui me semble assez cohérent. De fait, entre trouver une faille dans un logiciel dont on a le code et dans un dont on ne l'a pas, il semble évident que ce sera plus facile dans le premier cas.

J'ai souvenir d'un concours d'il y a une dizaine d'année sur slashdot pour craquer un site web commerçant. Le gagnant avait fait une analyse très poussée du code pour trouver au moins 3 vecteurs d'attaques. Deux s'étaient révélés inexploitables mais le 3e avait fini par lui donné l'accès root.

L'exploit n'aurait pas été possible dans ce cas sans les sources. Ou aurait pris beaucoup beaucoup plus de temps.

Surtout que le support de différents popen sous Windows a longtemps été moisi, mais uniquement dans certains cas.

au moins, avec subprocess, tu as une interface stable, qui couvre tous les besoins d'utilisation.

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...

Tout ceci n'est qu'une hypothèse.

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.

Bah, google fait pas de dev en France. C'est probablement logique de mettre un bon marketeux à la tête de ce service.

Utilises un goto !


--> []

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.

Ca m'intéresse un packageur PyQt / Mac pour PyTiCroque : http://www.freehackers.org/PyTiCroque

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 !

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.

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)

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.

J'espère que la situation s'est améliorée...

« 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.

En fait, t'es même pas un troll !

Maintenant que nous somme plus ou moins d'accord, il reste plus quà nous serrer la main respectueusement en souhaitant bon vent...