Philippe F a écrit 2204 commentaires

> Par contre, des qu'il s'agit de se vendre, la il n'y a plus personne.

C'est marrant, je connais des gens qui y passent beaucoup de temps et d'energie. Une annonce dans le new york times, j'ai du rever. Ou spreadfirefox, ca n'existe pas.

> Le libre qui aurait pu (qui pourrait encore) concretiser une belle utopie

Et toi, tu fais quoi a part raler ?

Qu'est ce que je me marre. KDE a pris la decision de virer Corba en octobre 99. Il aura fallu plus de 5 ans a Gnome pour realiser que c'etait une bonne decision.

Ce qui est dommage, c'est que des mecs super comme Mickael Meeks aie passe autant de temps sur une techno qui sera jetee a la poubelle.

T'as rien compris au fonctionnement de freedesktop (qui soit dit en passant, est modele social des logiciels libres. De la a dire que tu n'as rien compris au modele social des logiciels libres, il n'y a qu'un pas que je ne franchierai pas).

freedesktop rassemble des hackers des differents desktop pour en faciliter l'interoperabilite. Freedesktop fait avant tout des standards, et propose en general une implementation de reference (DBUS).

Freedesktop emerge d'une necessite, celle de discuter interoperabilite en terrain neutre. Freedekstop n'a aucun pouvoir en dehors de celui des hackers individuels qui sont d'accord avec une proposition de freedesktop.

Pour DBUS dans KDE, l'idee semble faire son chemin mais c'est pas encore gagne. Ce qui est sur, c'est qu'il y aura un pont DBUS - DCOP de facon a conserver la compabilite.

Avec roundup, tu as un mode ou tu peux traiter les mails entrants comme des rapports de bugs. Cela dit, j'ai pas installe cette partie-la.

Quand je vois la liste des modifications, je ne vois rien qui justifie de faire un saut aussi grand. Une 1.1 aurait parfaitement suffi a mon (pas si humble) avis.

Clairement, google, yahoo et consorts en s'installant en Chine, obeissent a une necessite commerciale (grossir) qui est amorale.

Une fois que ces boites s'installent sur place, elles ont deux choix :
1. lutter de toute leur force pour le respect des droits de l'homme et s'opposer a l'autorite chinoise
=> elles vont se faire tout simplement interdire et donc echoueront a leur objectif commercial.

2. accepter les regles antidemocratiques locales en fournissant leur service.

A noter que 2. est peut-etre plus utile que 1. Que vaut-il mieux un moteur de recherche censure, mais puissant et capable de trouver des pages peut-etre difficiles a trouver ou pas de moteur de recherche du tout ?

Meme si les boites dont on parle respectent le non-respect des droits de l'homme et censurent leurs resultats, il peut y avoir d'autres moyens plus discrets de lutter. Etre un excellent moteur de recherche permettant de trouver facilement des proxy caches ou des pages de protestation sur la Chine en est un.

J'espere que vous aurez beaucoup de visiteurs !

Bon, je constate que git a evolue depuis que j'ai regarde de pres. Ca ne change rien au fond de mon argumentation, a savoir qu'il a ete developpe pour des besoins tres tres specifiques et qu'il ne peut ne pas convenir pour d'autres besoins specifiques aussi.

Il y a des gens qui se disent que si le kernel utilise un truc, c'est forcement le meilleur truc au monde. C'est a moderer fortement, les hackers du kernel n'etant pas des etres humains normaux, mais des hackers du kernel.

> Aucun des programmes que tu cites ne répondent à tous tes critères.

Ce sont des criteres en vrac. De fait, mon argumentation est justement qu'il n 'y a pas de SCM universel pour l'instant.

Dans ma boite mes deux commerciaux utilisent CVS quotidiennement sous windows grace a tortoise CVS. Ca ne serait possible ni avec arch, ni avec git, ni avec tla. Subversion serait envisageable. Malgre tous les inconvenients de CVS, c'est de loin une des meilleurs solutions par rapport a mon besoin.

J'ai oublie d'ailleurs dans mes criteres la facilite d'utilisation. CVS, un utilisateur utilise quotidiennement deux commandes : commit update. Rien qu'en voyant la page de man de git, je laisse tomber. Il va me falloir deux heures pour comprendre de quelles commandes j'ai besoin et lesquelles ne me servent a rien.

Et puis niveau stabilite, si la porcelaine evolue, ca ne convient peut-etre pas a tout le monde.

J'ai regarde le mode pack mais j'ai pas trouve de description de l'operation de packing qui est faite derriere. Je ne peux donc pas dire si c'est efficace ou pas comme methode de stockage.

A ajouter dans la liste des inconvenients : avec le salaire d'un administrateur ClearCase, tu peux embaucher trois developpeurs de plus.

Dit autrement:
- avec subversion/CVS, tu peux avoir un admin a temps partiel
- avec ClearCase, il te faut deux admin a temps plein

Surtout, git est optimise pour les besoins de Linus. Le fait que CVS et subversions ne conviennent pas a Linus mais conviennent a des milliers de projets Open Source devraient deja donner un indice que git n'est pas pour tout le monde.

Quelques points notables:
- git stocke les fichiers integralement. Si tu changes une ligne a fichier texte de 50000 lignes, git restocke le fichier texte. CVS et consorts stockent un diff. Donc en terme de stockage, git n'est pas efficace et ce n'est pas son but.

- git est concu pour avoir une notion de tracabilite tres profonde, sur l'integralite des sources et des changements d'un projet, le tout valide par une signature cryptographique (SHA). Il est possible en une seule operation de savoir si deux jeux de source git sont identiques ou differents.

- git est optimise pour la notion de partage et de melange d'arbres differents, qui correspondent au modele de developpement du noyau : beaucoup de developpeurs avec des branches partielles (sous-systemes, experimentales) font d'abord des modifs dans leur branche avant de faire remonter la modif vers le repository de Linus.

Bref, pas grand chose a voir avec les besoins classiques d'un SCM :
- versionnement des fichiers
- remonter dans le temps sur les versions passees
- notion de branche
- notion de marquage (tag)

Apres, on peut rajouter d'autres fonctionnalites :
- commit atomiques
- renommage
- utilisation en mode completement decentralise facon arch
- interface conviviale
- compacite du stockage
- facilite de deploiement
- portabilite
- nombre d'outils et frontend associes
- stabilite
- dispoinbilite d'un frontend sous windows

qui font qu'on aboutit a CVS, Monotone, subversion, arch, tla, bazaar, bazaar-ng, Super CVS et autres.

Je sais que dans ma boite precendent, la convivialite etait un element fondamental. Si l'outil n'etait pas convivial, les developpeurs ne l'utilisaient pas et continuaient avec leurs zip sur un serveur partage. Chaque usage a ses criteres particuliers.

Pour Linus, c'est git.

Tu te trompes en affirmant que ruby passera au premier plan, sous-entendu avant les autres langages que j'ai evoque.

Les avantages que tu cites d'ailleurs ne sont pas la pour offrir une bonne "scriptabilite" ( = capacite d'etendre et de controler une application par script ) mais un bon environnement de developpement.

KDevelop supporte deja d'autres langages que Ruby, et ruby est loin d'etre le seul langage a faire du dcop ou du soap.

Ruby va avoir une place confortable en terme d'IDE en effet, car Richard Dale, le M. Binding de KDE aime beaucoup ruby. Mais l'approche utilisee pour integrer les langages de scripts dans KDE est generique, et il y a des supporters d'autres langages dans KDE.

Tu peux lire le blog de Ian Geiser pour voir par exemple tout ce qui est fait pour le javascript avec KJSEmbed :
http://www.kdedevelopers.org/blog/2(...)

KDE 4 va etre quand meme avant tout la continuite des principes qui ont fait le succes de KDE depuis KDE 2. Tout ca pour dire qu'il y aura certainement des technos bien sympatiques, mais que ca ne va pas etre une revolution en interne. Qt4 offre de nouvelles possibilites qui seront exploites. Le fait de pouvoir casser la compabilite binaire va conduire a un nettoyage des libs internes. Mais globalement, on reste dans le meme principe.

Pour repondre a tes questions :
- du multithreading : il y a deux presentations sur les possibilites de faire des applications asynchrones et/ou multithreadees et toutes les deux ont semble-t-il bien marche. Donc il va y avoir une meilleure comprehension de ce qu'on peut faire en asynchrone. C'est pas pour ca qu'on va re-ecrire kdelib en multithreads.

- c'est quoi les _nouveaux_ standards de freedesktop ? KDE utilise deja la plupart des standards definis dans le cadre de freedesktop. Et participe a l'elaboration des futurs standards. Pas de revolution de ce cote-la, mais le travail de KDE s'inscrit dans la continuite.

- nouvelles applications : j'ai pas entendu parle de killer app. Cependant, ca fait plusieurs annees que Krita est developpe et il semble arriver a maturite. Il semble aussi qu'on se dirige vers un multi-viewer a base de KPdf. Il y a aussi la convergence de developpeurs, d'artistes et d'ergonomes dans le cadre du projet Appeal, avec notamment un nouveau bureau plus interactif.

Il semble aussi que la scriptabilite passe au premier plan dans KDE 4. Je n'y suis pas mais j'ai lu pas mal de gens discuter de facon d'introduire une interface de script generique au coeur des libs KDE, accessibles a divers langages de scripts : ruby, python et javascript au moins.

Globalement, il faudra attendre quelques mois pour comprendre tout l'impact de l'akademy 2005 mais il semble que ca soit bien parti.

Bon, on en revient a ma conviction premiere, a savoir que Linus, malgre toutes ses qualites, ne sait pas gerer un systeme de versionnage lisible et propre.

Pour comprendre ce que j'appelle lisible et propre, il suffit de regarder la facon dont fonctionne KDE ou Mozilla. Il n'y a pas 24 numero de versions, et les versions en dev s'appellent beta, alpha ou autre, les versions super stables ont un no de release unique, et les versions presque stables avant la release sont notes RC.

On peut suggerer a Linus que les versions dont les 4 chiffres sont multiples d'un meme nombre premier sont stables, celles ou la sommes des 4 chiffres est divisible par 7 sont des release candidate, et les autres sont instables. Ca me paraitrait a peu pres aussi lisible que le systeme actuel.

Je me demande si l'appellation bug n'est pas plus ancienne encore. Je me souviens d'un bugs bunny ou on voit un vilant "bug" essayer de faire exploser des bombes d'avions militaires. Il me semble du coup que c'est lie a une legende, de petits etres qui viendraient foutre la merde dans un truc cense marcher parfaitement.

Ce que confirme au moins partiellement wikipedia:
http://en.wikipedia.org/wiki/Computer_bug(...)

Je suis surpris de voir les versions RC (candidats de sortie) associes dans la nouvelle avec la notion de deverminage.

Les RC, etant des candidats finaux, ne servent pas a deboguer mais a tester que tout marche, ce qui n'est pas du dout a mon sens la meme demarche. Apres, il peut y avoir des vermines [1] dans une version, qui doivent evidemment etre corrigees mais ce sont en theorie de vermines mineures.

La phase de deverminage a lieu normalement pendant le developpement de nouvelles fonctionnalites, c'est a dire bien en amont de la phase des RC.

[1] : j'avoue que j'ai quand meme du mal a ne pas appeler ca un "bug".

<< Les fossiles de dinosaures, entre autres, contredisent ce fait puisqu'ils indiquent que la Terre est beaucoup plus vieille. >>

Ben pas vraiment. Tu peux considerer que quand Dieu a cree la terre, il y a aussi mis des fossiles qui avait l'air plus vieux que ce qu'ils sont en realite.

C'est pour ca que toute discussion avec une personne intimement convaincue du Creationnisme ou plus generalement, une discussion opposant science et religion avec un croyant fervent est la plupart du temps sterile. Le croyant va etre d'accord sur ce qui dit la science sauf quand c'est en contradiction avec sa religion. Dans ce cas, soit il croit que la science se trompe, soit il pense que Dieu a mystifie les preuves pour qu'on se trompe. Bref, la Bible a toujours raison.

La ou je pense que les argumentaires religieux sont faibles, c'est sur la Bible justement. Il y a eu de nombreuses traductions, il y a eu des pertes, des adaptations, de la censure au fil des siecles. La Bible n'est donc pas necessairement fidele a la Bible originale. Pour quelqu'un qui a une foi absolue en la Bible, cela devrait etre la premiere source de ses recherches.

C'est marrant, moi j'aurai dit que c'est parce que chaque fois qu'il y a un document halloween qui sort, c'est un beau cadeau de Noel. Microsoft reconnait a chaque fois la "menace Linux" et nous montre la credibilite et l'altruisme de son entreprise.

<< En plus, d''où viendrait la légitimité d'un État sur cette question si ce dernier ne se réclament pas de fondations transcendentales, quelle qu'elles soient ? >>

J'ai du mal à concevoir qu'on ne puisse pas trouver la réponse facilement à cette question.

Le besoin d'une entité Etat vient de l'organisation actuelle du monde qui fait que les groupes de personnes dans une région "pays" doivent s'organiser pour se donner des règles de vie commune et de cohabitation et organiser leurs relations avec d'autres Etats.

La légitimité de l'Etat vient de son mode d'élection, à savoir qu'il représente le voeu de l'ensemble des personnes qu'il gouverne.

Indépendamment de toute religion, on doit donc être capable de comprendre qu'on a besoin d'une entité qui édicte des règles et que celles-ci doivent être respectées, sans pour autant que cette entité ait une légitimité transcendatle et notamment religieuse.

Dans la vision de la loi de 1905, on définit ce qui doit être réservé à l'Etat, à savoir l'organisation de la vie sociale et publique, les religions étant libre de gérer les autres aspects (sprituels, solidarités, communautés, ...)

Les problèmes surviennent évidemment lorsque ces deux aspects se recoupent. Le premier exemple étant le voile, où l'Etat prend une décision qui touche au domaine religieux.

Le deuxième exemple est dans certains cas, la religion a des domaines d'interventions qui rejoignent le domaine du social ou du public, ce qui est en désaccord avec l'Etat. Pour le croyant, on peut avoir une situation où son communauté religieuse prend des prérogatives sur des domaines réservés à l'état, qu'il va respecter car il place sa foi au dessus de l'obéissance à l'Etat.

On est alors dans une situation de conflit puisque l'Etat ne peut tolérer qu'on ne le respecte pas.

Ce type de conflit se produit plus fréquemment avec la religion musulmane parce que la cohabitation de celle-ci avec l'Etat français est toute récente. La religion catholique et la religion juive ont eu plusieurs siècles pour trouver un ajustement dans lequel Etat et religion cohabitent. Il en sera de même dans le futur pour l'Islam (en tout cas je l'espère).

Il me semble aussi que le modèle de laicité à la française est vraiment une exception culturelle dans le monde. Dans les autres pays, la religion est intégrée à l'Etat soit de façon officielle, soit de façon implicite. On a donc des problèmes uniques.

Certe, mais les prix a l'epoque n'etaient pas du tout alignes sur le couts. Un fait notoire, ce sont les communications internationales exorbitantes qui financaient le bas-cout des autres communications.

Avec un modele economique plus exigeant, les prix sont maintenant beaucoup plus alignes sur les couts. Et la verite, c'est que il y a un cout fixe eleve a maintenir une ligne telephonique en activite, independamment de son utilisation.

C'est pas pour ca que ca me fait plaisir de payer 12 euro a FT mais ca reflete une realite economique.

C'est sur, mais il faut voir que le format d'un document de traitement texte est extremement complexe. Celui de microsoft etait particulierement costaud puisqu'il stocke le document sous forme d'un document d'origine et d'un ensemble de changements (c'est a dire qu'il memorise les undo).

Et imagine la quantite d'information qu'il y a a stocker pour un paragraphe : style, police, alignement, placement dans la page, insertion d'un objet bidule, retraits, tabultions, etc etc.

A cause de cela, c'est quand meme beaucoup plus simple pour l'equipe de OpenOffice de travailler sur un filtre qui .doc vers un logiciels dont ils maitrisent les rouages que l'inverse.

Gnome ou Gtk ?

Dans le dernier Nokia, on retrouve aussi khtml qui a ete porte (sic) sous Gtk. Un couteau dans le dos de KDE de la part de Nokia !

Quelques clarifications de vocabulaire :

Qt/X11 est en triple licence :
- GPL
- licence commerciale
- QPL, qui est une licence open source non compatible avec la GPL mais compatible avec la LGPL ou la licence artistique.

Donc dans vos commentaires, il faut remplacer QPL par licence commerciale. A part ca, le contenu est bon.

<< Pour une entité commerciale qui ne souhaite pas produire du logiciel GPL, c'est tout de même un avantage incroyable que de disposer d'une base en LGPL plutôt qu'en GPL. >>

J'ai cree deux boites logicielles qui produisent des logiciels graphiques dans le domaine de la carte a puce donc je sais de quoi je parle.

Je peux te dire que LGPL ou GPL, on s'en bat les c..... . Ce qui interesse une boite commerciale comme nous :
- qualite de la documentation
- temps necessaire pour apprehender l'outil et former des nouveaux venus
- gestion de l'internationalisation
- qualite du support : quand et combien ?
- evolution de la plate-forme.
- outils annexes pour nous faciliter le travail

Dans le cas qui nous occupe, on a aussi :
- difficulte a faire un portage windows, unix ou MacOs.

Sur tous ces points, Qt enfonce Gtk parce que il y a une entite derriere dont la survie depend de la qualite de l'environnement de dev qu'elle fournit.

Le cout de la licence Qt, honnetement, c'est des cacahouetes. Si je sais que mon developpeur va gagner 3 jours de dev sur un projet de 2 ans en utilisant Qt, je me suis rembourse ma licence.

Pour moi au contraire, la LGPL est un serieux handicap. Ca veut dire qu'il est tres difficile de monter un business au dessus de Gtk en tant que produit, et que donc Gtk restera un toolkit non professionnel.

J"imagine que si ils passent chez Gnome, c'est parce qu'ils ne comprennent rien a l'objet. C'est des gens qu'on veut pas chez KDE de toute facon :-)

Plus serieusement, j'ai du mal a imaginer que quelqu'un qui a trouve ses marques dans la programmation graphique objet puisse apprecier de programmer du pseudo-objet chez Gnome. En ce qui me concerne, j'adore programmer en C quand c'est adapte. Pour une environnement graphique, le C est clairement pas adapte alors qu'un langage objet convient tres bien.

Ca craint un max. Fait le meme test sous KDE, tu verras que ca se place mieux.

Merci kwin.