Moi je n'ai pas vu cette attitude-la chez lui. J'ai vu qq'un qui signale un probleme grave, preuve a l'appui, et qui visiblement s'est deja fait rembarre un certain nombre de fois comme vous venez de le faire une fois de plus.
Ca entretient le climat qu'il interdit de critiquer un logiciel libre. Pour un produit aussi repandu et aussi supporte qui firefox, une telle fuite memoire est un probleme tres tres grave et plutot que de taper le messager, je trouve qu'il serai bon ton de s'inquieter.
Sinon on peut toujours rajouter un panneau sur www.mozilla.org disant "l'execution de ce logiciel est recommande pour des machines avec au moins 300 Mo de RAM en raison des importantes fuites memoires".
Ce qui m'agace particulierement, c'est que je suis sur que vous serez les premiers a raler pour une petite boulette d'un logiciel proprietaire mais que vous laissez passer ce probleme comme si ce n'etait pas important.
<< Bien sur qu'il y a des problemes, et personne ne parle ici de faire l'autruche, bien au contraire >>
Ah oui ? Et bien pour ma part, quand qq'un signale un probleme et qu'on ne s'attache a repondre que sur le ton et sur la personne qui le signale, je trouve que vous mettez nettement le probleme de cote.
Aujourd'hui, utiliser du logiciel libre sous windows demande d'avoir une machine plus puissante que pour utiliser du logiciel proprio (OpenOffice, Firefox, Thunderbird) sous windows. Pourtant, dieu sait a quel point les gens de l'open source et de free software ralent sur les besoins en memoire de windows. Mais des qu'il s'agit de balayer devant sa porte, il y a beaucoup moins de monde.
Juste pour anecdote, la fonctionnalite la plus appreciee de KDE 3.2 est la reduction de son occupation memoire (car contrairement a ce qu'en disent ses detracteurs, KDE est de moins en moins gourmand a chaque release) et l'amelioration de la rapidite de lancement de KDE et des applis KDE.
<< Il y aura toujours des fuites mémoires, malheureusement. >>
Ah ouai ? Qu'est ce qui te fait dire ca ? Si tu programmes proprement (avec des strategies d'allocation memoire, des pointeurs geres) et que tu fais tourner ton programme sous valgrind regulierement, je ne vois pas pourquoi il devrait toujours y avoir des fuites memoires. Il y a des langages ou des libs qui facilitent aussi grandement la gestion de la memoire.
Je trouve ca un rien defaitiste comme attitude et surtout pessimiste. C'est comme si tu disais << on sera toujours mauvais, on ne saura jamais programmer donc arrete de te plaindre >>.
> Tu serais surpris par l'étendu de la bêtise parmis les utilisateurs...
Moi ce qui ne me surprend malheureusement plus, c'est l'etroitesse d'esprit de certains developpeurs. Ils fonctionnent avec un scenario d'utilisation unique et souvent pas simple, et refusent de faire quoi que ce soit pour permettre a des gens utilisant les choses differemmant d'etre a l'aise.
Je trouve quand meme que l'attitude a ete ici tres reprobatrice. Comme si on n'avait pas le droit de trouver un defaut a un logiciel libre et de protester.
Une fuite memoire de cette taille, c'est un probleme tres serieux et je partage l'inquietude de la personne qui l'a signale: si plusieurs versions continuent a avoir le meme probleme sans que rien ne soit fait pour le corriger, on est en droit de se demander si les developpeurs considerent ca comme un probleme mineur ou pas.
La consommation memoire et le temps de chargement de mozilla sont aussi des preoccupations importantes je trouve. Pourtant, je l'utilise sous windows ou il parait qu'il est plus rapide que sous linux. Moi ce que je vois, c'est que ma machine le sent tout de suite si je lance thunderbird et/ou firefox. Ca prend du temps a se charger, ca prend de la memoire, etc.
Les champs d'ameliorations possibles de firefox ne manquent pas mais ce point semble quand meme avoir ete laisse de cote.
C'est possible avec une extension, mais il ne me semble pas qu'elle aie ete portee sour firefox 0.9 . Je l'utilisais sur la 0.7 .
Dans la serie des autres trucs chiants, je n'ai pas trouve comment faire en sorte que le middle-click ouvrent un tab _en arriere plan_. Pour mon utilisation personelle, c'est une regression absolument insupportable parce que je n'ouvre les tabs que en arriere-plan.
Historiquement dans le logiciel libre, on a vu des projets qui se sont scindes en un projet stable qui n'evolue plus et un projet dynamique, moins stable, qui evolue plus vite (gcc vs egcs par exemple, ou emacs vs Xemacs, ). De ce que j'en ai vu, le projet qui evolue prend a terme au moins 50% des utilisateurs, voire dans certains cas enterre l'autre projet.
> D'après les commentaires précédents, intégrer Vim dans KDE est très compliqué.
On s'est mal compris sur la signification du mot integrer.
Avoir vim pour editer ses mails dans KDE, c'est possible depuis longtemp (mikmak avait fait un patch dans ce sens). Avoir vim en style KDE, pareil, c'est possible depuis longtemp. Ca revient juste a lancer un editeur au bon moment, il n'y a pas de contraintes particulieres.
Mainenant, si on veut integrer vim dans KDevelop ou dans Kate, on doit avoir:
- la possibilite d'afficher plusieurs fenetres independantes sur le meme texte
- la possiblite de gerer plusieurs fenetres independantes avec du texte different
- la notion de focus: ce n'est pas toujours l'editeur qui controle ce qui se passe
- la notion boucle d'evenement separee: l'editeur n'etant pas le maitre, il doit se laisser controler par l'application qui l'embarque.
Ces 4 points sont _impossibles_ a realiser avec vim, et ce independamment de KDE ou de Gnome.
Pour l'instant, les gens qui parlent d'integration dans Gnome / bonobo de vim parlent en fait de modifier l'application cible pour qu'elle puisse appeler explicitement le composant vim (type le patch evolution).
Pour KDE, on a un niveau d'abstraciton qui a ma connaissance n'est pas present dans Gnome: KDE definit un composant editeur generique, avec des notions de documents, vue, curseur, undo, ... Rentrer vim la-dedans implique de s'adapter a ces contraintes. Le resultat, c'est que n'importe quelle application KDE pourra utiliser vim, sans meme le savoir. L'utilisateur aura juste a declarer le kpart vim comme son kpart editeur prefere. Ca va beaucoup plus loin que patcher evolution. Notamment, les applications comme quanta ou kdevelop n'ont meme pas besoin d'etre patchee.
Voila pourquoi on peut avoir l'impression que l'integration de vim dans KDE est plus difficile que dans Gnome. C'est simplement qu'on va plus loin.
Les 4 points cites sont les plus bloquants pour utiliser vim en tant que composant graphique. Bien sur, je ne vous surprend pas en vous disant que yzis n'a pas ces limitations.
> Vim, et les applications KDE ont des «philosophies» radicalement opposées
Oui et non. KDE, c'est ce qu'on en fait. Il y a avant-tout une grosse pression sur la facilite d'utilisation, mais il y a aussi une grosse communaute de hackers sur KDE, ce qui fait que KDE convient aussi a un hacker de fond. Il n'y a qu'a voir les possiblites de konqueror ou de dcop pour s'en convaincre.
> Les fonctionnalités que tu attend de kvim, ça ne serait pas plutôt le rôle de kwrite de te les offrir ?
De kvim, j'attend un editeur gvim avec les icones et les menus KDE. Ca, ca va on l'a fait mais ca n'a pas ete sans quelques bidouilles. Apres, l'etape importante, c'est l'integration d'un composant editeur compatible vi dans KDE. Tu serais surpris du nombre de personnes qui sont interessees par ce truc. Les demandes les plus fortes pour ce genre d'integration sont pour KDevelop et Quanta+: des logiciels de developpeurs a qui un vim ne fait pas peur. Avoir un bon Kate avec vi pour la partie editeur etait aussi un de mes reves. Malheureusement, la structure de vim ne le permet pas.
Pour en revenir a la question, pour faire un composant vi pour KDE, il parait naturel de se tourner vers le meilleur editeur vi qui soit, a savoir vim. Malheureusement, en raison d'une part de l'architecture de vim un peu trop orientee C, d'autre part de l'entetement de l'auteur a refuser tout patch, il n'est pas possible de faire de vim un composant editeur KDE proprement. Je dis ca bien que vous puissiez utiliser kvim aujourd'hui dans kdevelop mais a un prix en developpement que vous ne pouvez pas imaginer. Il y a par exemple une chance sur 5 que kvim se lance en dehors de la fenetre de kdevelop.
> Sinon, tu a fait une sacrée sélection dans les demandes de fonctionnalités
J'ai pris les fonctionnalites qui etaient significatives par rapport a ce que je demandais. Les trois fonctionnalites citees sont des fonctionnalites que nous avons demandees a Bram en exposant notre point de vue pendant une longue discussion pour aboutir au final au rejet de notre proposition. A cause de cela, et presque contre notre gre, nous avons demarre un projet d'editeur compatible vim concurrent: yzis.
Je trouve ca ironique qu'apres nous avoir envoye bouler, il figure parmi les fonctionnalites les plus demandees precisement les fonctionnalites que Bram a refuse qu'on ajoute.
Pour finir sur Yzis, je citerai la phrase de Mickael (un des initiateurs du projet): "il faut deux ans pour que Bram integre un patch de notre part dans vim. En deux ans, on a le temps de redevelopper un editeur".
Yzis presente un certains nombre d'avantages indeniables sur vim, meme s'il est encore tres jeune:
- un langage de script reconnu et massivement diffuse: lua (v5.0)
- un support de la coloration syntaxique beaucoup plus puissant et plus simple a ecrire, base en particulier sur des fichiers xml et partage avec l'editeur kate/kwrite
- une abstraction frontend / moteur vi qui permet de reutiliser le moteur yzis dans plein de circonstances
- une utilisation massive de bibliotheques deja existantes de debuggees plutot que l'utilisation de truc faits maison.
Vous allez dire que je suis mechant mais je me marre en lisant ca:
104 points: support embedding of Vim in another GUI program
Apres plus de trois ans de bataille avec le code de vim, et un certain nombre de discussion avec Bram, il est apparu que le GUI graphique ne faisait pas partie des priorites de Bram, ni meme de son champ de comprehension. Apparamment, c'est pourtant la priorite des utilisateurs. Pire, il est apparu que Bram ne comprenait pas vraiment les besoins d'un bon GUI graphique et surtout n'envisageait pas de changer une ligne de code de vim pour supporter quoi que ce soit dans ce sens. A cause de cela, kvim est bourre de hacks qui permettent vaguement de lancer kvim sans prendre 100% de cpu si il est de bonne humeur. Vous pleureriez si vous saviez comment on arrive a faire un composant vim pour KDE a partir de ca.
La derniere fois qu'on lui a demande de separer vim en un moteur vim et un gui vim pour faciliter l'integration graphique, il a dit qu'il ne toucherait pas a ces parties la et que vim resterait tel qu'il est, un editeur oriente terminal. Les changements seraient de toute maniere trop profond pour pouvoir etre realises. Je me demande si il a juste change d'avis et ne realise pas l'ampleur de la tache maintenant, ou si il s'est juste foutu de notre gueule a l'epoque.
A mon avis, vous pouvez toujours rever mais vous n'etes pas pret d'avoir un bon gui pour vim. Par bon gui, j'entends un truc qui ne soit pas equivalent a xterm + vim mais plutot un gui incrustable dans kdevelop, quanta ou kmail.
74 points : add IDE features (debugger integration, shell window)
Dites-moi, il a bien change Bram. Pareil, quand on lui a dit que separer vim en un moteur et un frontend permettrait d'integrer vim dans un IDE style KDevelop, il a dit que c'etait ce qu'il voulait (bien qu'il n'accepte aucun patch allant dans cette direction) et que vim ne devait pas devenir un IDE en soi.
62 points: support multiple top-level windows for one running Vim
La aussi, ca me fait marrer. Parmi toutes les directions qu'il ne voulait pas prendre, celle-ci semble quand meme la plus facile a ajouter au code.
Pour ce qui est de l'integration des nouvelles fonctionnalites, j'espere que Bram se comportera mieux que par le passe mais je n'y crois pas. Il ne lui a fallu << que >> deux ans pour integrer les patch de kvim dans vim. Des que tu lui demandes de changer une ligne de code, il faut compter entre 1 et 12 mois de discussions et negociations. Alors pour une nouvelle fonctionnalite, j'ose pas imaginer.
<< Si vous travaillez sur un projet libre peu connu et ayant besoin de ressources, venez inscrire ce projet à l'adresse au bas de cette annonce. Les inscriptions sont ouvertes durant tout le mois de Juin 2004. >>
Ca existe les projets libres connus et n'ayant pas besoin de resources ? Meme des projets majeurs comme KDE ou le noyau linux ont besoin de ressources alors pour les autres, j'imagine pas...
Tu as rentre 300 operations a la main dans une meme categorie, et tu veux changer de categorie 200 operations parmis ces 300. Sous vi, je te fais ca en 20 secondes. Sous grisbi, je pense qu'il faut une option filtre + une option multi-selection d'operation pour faire ca facilement.
Autre cas que j'ai eu: je veux annuler un rapprochement parce que je l'ai mal utilise. J'ai pas vu comment faire depuis grisbi. Et idem, le faire a la souris sur 400 operations, je le sens pas trop. Alors meme que ca prend 10s sous vi.
J'avais pas trouve a cette epoque l'option de redimensionnement des colonnes et j'ai renonce pour d'autres raisons.
Pour ce qui de la syntaxe du fichier xml, par exemple j'ai note que le nombre d'operations est ecrit dans le fichier alors meme que c'est un nombre qui pourrait etre calcule a la lecture du fichier. Du coup, si je rajoute une operation ou que j'en enleve une, ca craque.
Je pense qu'il y a possibilite de faire un fichier xml un tout petit moins interdependant, qui permettrait plus facilement de laisser la place a des modifs manuelles. Cela dit, en utilisant grisbi un peu plus, j'ai decouvert qu'il etait possible de faire ce que je voulais faire (changer toute une serie d'item de categorie) directement via grisbi (en effacant la categorie).
Pour ce qui est des filtres, je pense que ca peut etre sympa a inclure dans l'affichage des operations et que c'est plus facile a aprehender qu'un etat.
Un bon exemple de filtre est le filtre d'affichage des mails de Thunderbird. Il est facile a mettre en place et pas complique a utiliser.
Si un utilisateur peut en trois clics dire "affiche-moi toutes les depenses de plus de 1000 euro" parce qu'il sait qu'il veut modifier qqch dans ces depenses, c'est un atout.
Ah oui, une fonctionnalite pas trop difficile et fondamentale qui m'a
manque: la recherche d'operations.
Le mode d'emploi est tres bien fait, en francais, avec meme quelques references linguistiques.
Un probleme que j'ai avec mes comptes, c'est que je change souvent d'avis. Je decide de re-categoriser certains trucs differamment, de separer certaines depenses, de faire un virement compte a compte au lieu de marquer une depense et un revenu, etc.
C'est pour ca que j'ai eu des besoins de modifier le fichier xml. A mon avis, ce genre de problematique (les gens qui changent de methode de classement) est a prendre en compte car je ne suis certainement pas le seul.
A priori, l'utilisateur novice va commencer par utiliser les fonctionnalites de base de l'outil, puis, au fur a mesure qu'il se familiarise, modifier la facon dont il rentre ses operations pour tirer plus partie des possibliites du logiciel. Il sera donc amener a changer la facon dont il fonctionne.
Pour ce qui est du probleme du bugotron, je re-essaierai et vous tiendrait au courant. En tout cas, j'apprecie la reactivite sur linuxfr :-)
Moi j'aime bien le projet et j'utilise notamment sous windows pour gerer les comptes d'une PME (ben oui, parfois on fait au plus simple)
J'ai trouve que dans les details quand meme, il y avait des choses desagreables. Par exemple pour la version 0.4, il plantait toutes les minutes, au point que j'ai renonce a l'utiliser.
J'ai eu beau lutter, impossible de me logger sur leur systeme de gestion de bug, ce qui ne fait jamais une bonne impression.
Des petits trucs desagreable, comme le fait que les tailles des colonnes sont fixes et non redimensionnables, ou bien que les sommes ecrites ne soient pas alignees, donnant une impression de desordre.
Mais quand meme, en acceptant les limitations, c'est plutot sympatiques. Des trucs que j'aimerai voir dans le futur:
- une simplification de la syntaxe du fichier xml, pour pouvoir eventuellement le modifier a la main et eviter qu'il plante aussi souvent
- le selection d'operations pour pouvoir modifier un seul critere facilement (typiquement la categorie)
- des filtres dans l'affichage des operations
- le redimensionnement des colonnes
- dans les etats, la possibilite d'afficher mes depenses par categories.
J'espere que le projet evoluera vers qqch de bien.
Ce qu'il veut dire, c'est que ces portages auraient peu de chances de beneficier des caracteristiques qui font justement l'interet de Y par rapport a X: le rendu des widgets cote client.
Certe, dans le cas du bouton, tout est rose pour Y. Mais honnetement, est-ce que c'est les boutons a afficher qui font peiner X ? Pour toute application raisonnable, tu as besoin de faire un peu de dessin toi-meme et tout de suite, tu te retrouves dans un mode ou seul le client sait ce qu'il faut dessinner.
Sinon, on pourrait imaginer un portage de Qt ou les boutons sont dessinnes par Y et pas par Qt. A mon avis sous cette phrase simple se cachent de nombreuses difficultes techniques difficile a resoudre. Mais Qt fonctionnant sous X11, win32, framebuffer et macos X, on peut s'imaginer qu'il est relativement independant de la methode d'affichage et saura gerer cela.
> Quant au mail dont tu parles, merci de fournir un lien, car en l'état de ta
> citation, ce n'est qu'une sale rumeur mesquine.
C'etait sur la liste forum de XFree, c'est tout ce dont je me souviens.
Pour ce qui est de la rumeur mesquine, la facon dont je le presente ne laisse en effet pas de place a d'autres interpretations. De toute facon, c'est un develloppeur qui supputait qu'un autre developpeur etait plutot depressif. Rien de bien precis en effet.
Mes excuses pour ce qui est de la sous-evaluation du nombre de developeurs restes sur XFree.
J'ai du respect pour les acomplissements passes de beaucoup de contributeurs du libre (RMS, les mainteneurs X, ESR) mais ca ne m'empeche pas d'etre en desaccord avec la direction qu'ils peuvent prendre dans leurs propos.
Si tu lis les derniers progres de X sur freedesktop, tu verras qu'il existe un projet de re-ecriture de la xlib qui evite tous les aller-retours couteux qui sont le lot des applications X. Du coup, le genre de probleme dont tu te plains n'a qu'un impact tres tres limite.
Le probleme de Y, c'est qu'il n'a aucune chance face a la popularite de X. Qui veut d'un environnement graphique ou l'appliation le plus avancees, c'est ycalc ?
C'est vrai que pouvoir faire un fork est un atout, mais je suis d'accord avec le posteur original: un fork, c'est bien l'echec de qqch. Quand on en arrive au fork, c'est que les discussions n'ont pas pu aboutir, que les developpeurs ne pourront plus jamais se mettre d'accord.
Il y a eu des forks fructueux et infructueux dans le libre. Je note quand meme que sur les moyens et gros projets (gcc, emacs au moins), les forks ont ete plutot fructueux. Souvent, ces forks fructueux ou ces reecritures correspondent a une base de developpeurs plus actifs que les mainteneurs du projets officiels. Ce qui explique que ces forks soient des succes.
Je suis encore en train d'en vivre un, avec yzis (www.yzis.org) qui reecrit vim. A mon avis, dans deux ou trois ans, on sera mieux que vim.
Le pluriel est mal adapte. Il ne reste que David machin a mon avis, dont l'ego-centrisme a accelere la mise en route de X.org
De ce que j'en ai lu, je retiens un mail d'un des developpeurs de XFree qui pense que David Dawes (le nom me revient) est en depression. Ca expliquerait ce changement de licence, pour le moins incongru, << dans le but de donner plus de reconnaissance a ceux qui le merite >>.
L'interface ou le style des widgets ? Qt comme Gtk permettent d'utiliser n'importe quel style et on pourrait imaginer qu'un port de Qt sous Y se contenterait d'utiliser le style des elements Y pour s'afficher.
Cela dit, Y, ca m'a tout l'air d'etre un projet de loser. Il l'aurrait lance il y a 5 ans, je dis pas mais maintenant, c'est trop tard. Qt et Gtk sont la pour te farie oublier les petits soucis de X, qui sont a l'origine de la ceration de Y.
Et comment on fait dans le cas d'un logiciel suffisamment bien concu, pour lequel il n'y a pas de services a vendre ? Imaginons une boite qui fait des logiciels d'usage hyper repandu. Ca pourrait etre un navigateur, un client de messagerie, un logiciel d'astronomie, un editeur de texte ou autre chose. Il n'y a aucun service a vendre donc aucune facon de se faire de l'argent si on vend le logiciel sous licence libre. Le modele logiciel libre ici conduit l'auteur a se chercher un autre boulot. A cote, tu vends le meme logiciel en shareware et tu peux vivre de ton travail si ton logiciel a du succes.
Je trouve ca hypocrite de raisonner sur le cas specifique des super gros logiciels alors meme que la majorite des logiciels libres sont justement des petits logiciels pour lesquels le modele ne s'appliquerait pas. Prenons un exemple concret: GnomeMeeting est un super logiciel et j'aimerai bien que son auteur puisse passer du temps a le developper. Quel service il pourrait vendre dessus ? Il peut essayer de creer une dependance artificielle a un service global d'enregistrement des usagers sur lequel il se remunererait mais c'est vraiment creer artificiellement une depense et un besoin et c'est meme pas sur que ca marche.
Si on prend le cas de quelques developpeurs qui arrivent a vivre sponsorises sans passer par une distrib, je ne connais que les developpeurs de Quanta. Eric Laffont ne peut payer que des developpeurs de pays en developpement (pays de l'est, turquie) et encore, ceux-ci avouent qu'ils font de tres grosses concessions sur leur salaire et que ce travail ne leur assure aucune retraite ni securite sociale.
Donc arretez de vous voiler la face, le developpeur de logiciel libre qui peut vivre de son logiciel libre est un cas plus qu'exceptionnel. Ca doit representer moins d'un 10000e de la population de developpeurs.
Tout depend du nombre de dependance. Si c'est un module noyau a la nvidia, pas de probleme pour le binaire. Si c'est une appli graphique, bonjour la galere:
ldd `which konqueror` | wc -> 40 dependances, loins d'etre triviales (X, fontconfig, pthreads, librender, ....)
Le pire pour des binaires, c'est une distrib style gentoo: etant donne qu'il n'y a pas d'arret dans le temps de la distrib, tous les utilisateurs ont une gentoo differente. C'est aussi le cas si je ne m'abuse des debian instables. Tous les developpeurs n'ont pas necessairement la derniere version du logiciel X. Ou bien ils ont une version plus recente que la version qui etait la quand le logiciel est sorti.
Vraiment, en dehors des langages interpretes/byte-compiles, je pense que la distribution binaire de masse sous Linux est vouee a l'echec. Bien sur, il y a les oracles qui te certifient une version de redhat et c'est tout. Ca va pour un serveur en fait.
Je suis impressionne par le niveau de contre-mesure qu'il faut mettre dans un programme pour bien le proteger. J'avais deja reflechi naivement a quelques contre-mesures et ca rejoignais ce qui est propose. Mais c'est une chose de les imaginer, et autre chose de voir un professionnel les implementer et expliquer comment il va biaiser (2) les vilains crackers.
Si on n'est pas cracker soi-meme, c'est d'ailleurs difficile d'etre expert dans ce domaine.
Je note aussi que tout ca est tres tres windows. Je me demande quelle serait la problematique sous Linux. D'un autre cote, il est absolument infaisable aujourd'hui de distribuer un produit grand public pour Linux sous forme binaire [3], donc de la a le securiser, on y est pas encore.
(2): c'est une faute de frappe !
[3]: je sais que certains vont bondir mais c'est une realite. 5 distributions majeures, avec au moins une mise a jour de la distrib tous les ans, ca fait 10 produits binaires a packager (de facon completement differente) par an minimum. Mais c'est sans compter les gentooistes qui vont recompiler leur libc, les linux sur PPC, les distributions mineures, ... La seule facon de distribuer un produit grand public sous linux, c'est de le developper dans un langage byte-code ou interprete (python roxor!)
[^] # Re: Effacer l'URL
Posté par Philippe F (site web personnel) . En réponse à la dépêche Firefox 0.9. Évalué à 2.
[^] # Re: fuite de mémoire
Posté par Philippe F (site web personnel) . En réponse à la dépêche Firefox 0.9. Évalué à 6.
Ca entretient le climat qu'il interdit de critiquer un logiciel libre. Pour un produit aussi repandu et aussi supporte qui firefox, une telle fuite memoire est un probleme tres tres grave et plutot que de taper le messager, je trouve qu'il serai bon ton de s'inquieter.
Sinon on peut toujours rajouter un panneau sur www.mozilla.org disant "l'execution de ce logiciel est recommande pour des machines avec au moins 300 Mo de RAM en raison des importantes fuites memoires".
Ce qui m'agace particulierement, c'est que je suis sur que vous serez les premiers a raler pour une petite boulette d'un logiciel proprietaire mais que vous laissez passer ce probleme comme si ce n'etait pas important.
<< Bien sur qu'il y a des problemes, et personne ne parle ici de faire l'autruche, bien au contraire >>
Ah oui ? Et bien pour ma part, quand qq'un signale un probleme et qu'on ne s'attache a repondre que sur le ton et sur la personne qui le signale, je trouve que vous mettez nettement le probleme de cote.
Aujourd'hui, utiliser du logiciel libre sous windows demande d'avoir une machine plus puissante que pour utiliser du logiciel proprio (OpenOffice, Firefox, Thunderbird) sous windows. Pourtant, dieu sait a quel point les gens de l'open source et de free software ralent sur les besoins en memoire de windows. Mais des qu'il s'agit de balayer devant sa porte, il y a beaucoup moins de monde.
Juste pour anecdote, la fonctionnalite la plus appreciee de KDE 3.2 est la reduction de son occupation memoire (car contrairement a ce qu'en disent ses detracteurs, KDE est de moins en moins gourmand a chaque release) et l'amelioration de la rapidite de lancement de KDE et des applis KDE.
[^] # Re: fuite de mémoire
Posté par Philippe F (site web personnel) . En réponse à la dépêche Firefox 0.9. Évalué à 7.
Ah ouai ? Qu'est ce qui te fait dire ca ? Si tu programmes proprement (avec des strategies d'allocation memoire, des pointeurs geres) et que tu fais tourner ton programme sous valgrind regulierement, je ne vois pas pourquoi il devrait toujours y avoir des fuites memoires. Il y a des langages ou des libs qui facilitent aussi grandement la gestion de la memoire.
Je trouve ca un rien defaitiste comme attitude et surtout pessimiste. C'est comme si tu disais << on sera toujours mauvais, on ne saura jamais programmer donc arrete de te plaindre >>.
> Tu serais surpris par l'étendu de la bêtise parmis les utilisateurs...
Moi ce qui ne me surprend malheureusement plus, c'est l'etroitesse d'esprit de certains developpeurs. Ils fonctionnent avec un scenario d'utilisation unique et souvent pas simple, et refusent de faire quoi que ce soit pour permettre a des gens utilisant les choses differemmant d'etre a l'aise.
[^] # Re: fuite de mémoire
Posté par Philippe F (site web personnel) . En réponse à la dépêche Firefox 0.9. Évalué à 10.
Une fuite memoire de cette taille, c'est un probleme tres serieux et je partage l'inquietude de la personne qui l'a signale: si plusieurs versions continuent a avoir le meme probleme sans que rien ne soit fait pour le corriger, on est en droit de se demander si les developpeurs considerent ca comme un probleme mineur ou pas.
La consommation memoire et le temps de chargement de mozilla sont aussi des preoccupations importantes je trouve. Pourtant, je l'utilise sous windows ou il parait qu'il est plus rapide que sous linux. Moi ce que je vois, c'est que ma machine le sent tout de suite si je lance thunderbird et/ou firefox. Ca prend du temps a se charger, ca prend de la memoire, etc.
Les champs d'ameliorations possibles de firefox ne manquent pas mais ce point semble quand meme avoir ete laisse de cote.
[^] # Re: Effacer l'URL
Posté par Philippe F (site web personnel) . En réponse à la dépêche Firefox 0.9. Évalué à 3.
Dans la serie des autres trucs chiants, je n'ai pas trouve comment faire en sorte que le middle-click ouvrent un tab _en arriere plan_. Pour mon utilisation personelle, c'est une regression absolument insupportable parce que je n'ouvre les tabs que en arriere-plan.
[^] # Re: Yzis
Posté par Philippe F (site web personnel) . En réponse à la dépêche Vim 6.3 dans les bacs.. Évalué à 2.
Historiquement dans le logiciel libre, on a vu des projets qui se sont scindes en un projet stable qui n'evolue plus et un projet dynamique, moins stable, qui evolue plus vite (gcc vs egcs par exemple, ou emacs vs Xemacs, ). De ce que j'en ai vu, le projet qui evolue prend a terme au moins 50% des utilisateurs, voire dans certains cas enterre l'autre projet.
[^] # Re: Intégrer Vim dans Gnome..
Posté par Philippe F (site web personnel) . En réponse à la dépêche Vim 6.3 dans les bacs.. Évalué à 8.
On s'est mal compris sur la signification du mot integrer.
Avoir vim pour editer ses mails dans KDE, c'est possible depuis longtemp (mikmak avait fait un patch dans ce sens). Avoir vim en style KDE, pareil, c'est possible depuis longtemp. Ca revient juste a lancer un editeur au bon moment, il n'y a pas de contraintes particulieres.
Mainenant, si on veut integrer vim dans KDevelop ou dans Kate, on doit avoir:
- la possibilite d'afficher plusieurs fenetres independantes sur le meme texte
- la possiblite de gerer plusieurs fenetres independantes avec du texte different
- la notion de focus: ce n'est pas toujours l'editeur qui controle ce qui se passe
- la notion boucle d'evenement separee: l'editeur n'etant pas le maitre, il doit se laisser controler par l'application qui l'embarque.
Ces 4 points sont _impossibles_ a realiser avec vim, et ce independamment de KDE ou de Gnome.
Pour l'instant, les gens qui parlent d'integration dans Gnome / bonobo de vim parlent en fait de modifier l'application cible pour qu'elle puisse appeler explicitement le composant vim (type le patch evolution).
Pour KDE, on a un niveau d'abstraciton qui a ma connaissance n'est pas present dans Gnome: KDE definit un composant editeur generique, avec des notions de documents, vue, curseur, undo, ... Rentrer vim la-dedans implique de s'adapter a ces contraintes. Le resultat, c'est que n'importe quelle application KDE pourra utiliser vim, sans meme le savoir. L'utilisateur aura juste a declarer le kpart vim comme son kpart editeur prefere. Ca va beaucoup plus loin que patcher evolution. Notamment, les applications comme quanta ou kdevelop n'ont meme pas besoin d'etre patchee.
Voila pourquoi on peut avoir l'impression que l'integration de vim dans KDE est plus difficile que dans Gnome. C'est simplement qu'on va plus loin.
Les 4 points cites sont les plus bloquants pour utiliser vim en tant que composant graphique. Bien sur, je ne vous surprend pas en vous disant que yzis n'a pas ces limitations.
[^] # Re: Vim 7
Posté par Philippe F (site web personnel) . En réponse à la dépêche Vim 6.3 dans les bacs.. Évalué à -2.
[^] # Re: Vim 7
Posté par Philippe F (site web personnel) . En réponse à la dépêche Vim 6.3 dans les bacs.. Évalué à 9.
Oui et non. KDE, c'est ce qu'on en fait. Il y a avant-tout une grosse pression sur la facilite d'utilisation, mais il y a aussi une grosse communaute de hackers sur KDE, ce qui fait que KDE convient aussi a un hacker de fond. Il n'y a qu'a voir les possiblites de konqueror ou de dcop pour s'en convaincre.
> Les fonctionnalités que tu attend de kvim, ça ne serait pas plutôt le rôle de kwrite de te les offrir ?
De kvim, j'attend un editeur gvim avec les icones et les menus KDE. Ca, ca va on l'a fait mais ca n'a pas ete sans quelques bidouilles. Apres, l'etape importante, c'est l'integration d'un composant editeur compatible vi dans KDE. Tu serais surpris du nombre de personnes qui sont interessees par ce truc. Les demandes les plus fortes pour ce genre d'integration sont pour KDevelop et Quanta+: des logiciels de developpeurs a qui un vim ne fait pas peur. Avoir un bon Kate avec vi pour la partie editeur etait aussi un de mes reves. Malheureusement, la structure de vim ne le permet pas.
Pour en revenir a la question, pour faire un composant vi pour KDE, il parait naturel de se tourner vers le meilleur editeur vi qui soit, a savoir vim. Malheureusement, en raison d'une part de l'architecture de vim un peu trop orientee C, d'autre part de l'entetement de l'auteur a refuser tout patch, il n'est pas possible de faire de vim un composant editeur KDE proprement. Je dis ca bien que vous puissiez utiliser kvim aujourd'hui dans kdevelop mais a un prix en developpement que vous ne pouvez pas imaginer. Il y a par exemple une chance sur 5 que kvim se lance en dehors de la fenetre de kdevelop.
> Sinon, tu a fait une sacrée sélection dans les demandes de fonctionnalités
J'ai pris les fonctionnalites qui etaient significatives par rapport a ce que je demandais. Les trois fonctionnalites citees sont des fonctionnalites que nous avons demandees a Bram en exposant notre point de vue pendant une longue discussion pour aboutir au final au rejet de notre proposition. A cause de cela, et presque contre notre gre, nous avons demarre un projet d'editeur compatible vim concurrent: yzis.
Je trouve ca ironique qu'apres nous avoir envoye bouler, il figure parmi les fonctionnalites les plus demandees precisement les fonctionnalites que Bram a refuse qu'on ajoute.
Pour finir sur Yzis, je citerai la phrase de Mickael (un des initiateurs du projet): "il faut deux ans pour que Bram integre un patch de notre part dans vim. En deux ans, on a le temps de redevelopper un editeur".
Yzis presente un certains nombre d'avantages indeniables sur vim, meme s'il est encore tres jeune:
- un langage de script reconnu et massivement diffuse: lua (v5.0)
- un support de la coloration syntaxique beaucoup plus puissant et plus simple a ecrire, base en particulier sur des fichiers xml et partage avec l'editeur kate/kwrite
- une abstraction frontend / moteur vi qui permet de reutiliser le moteur yzis dans plein de circonstances
- une utilisation massive de bibliotheques deja existantes de debuggees plutot que l'utilisation de truc faits maison.
[^] # Re: Vim 7
Posté par Philippe F (site web personnel) . En réponse à la dépêche Vim 6.3 dans les bacs.. Évalué à 10.
104 points: support embedding of Vim in another GUI program
Apres plus de trois ans de bataille avec le code de vim, et un certain nombre de discussion avec Bram, il est apparu que le GUI graphique ne faisait pas partie des priorites de Bram, ni meme de son champ de comprehension. Apparamment, c'est pourtant la priorite des utilisateurs. Pire, il est apparu que Bram ne comprenait pas vraiment les besoins d'un bon GUI graphique et surtout n'envisageait pas de changer une ligne de code de vim pour supporter quoi que ce soit dans ce sens. A cause de cela, kvim est bourre de hacks qui permettent vaguement de lancer kvim sans prendre 100% de cpu si il est de bonne humeur. Vous pleureriez si vous saviez comment on arrive a faire un composant vim pour KDE a partir de ca.
La derniere fois qu'on lui a demande de separer vim en un moteur vim et un gui vim pour faciliter l'integration graphique, il a dit qu'il ne toucherait pas a ces parties la et que vim resterait tel qu'il est, un editeur oriente terminal. Les changements seraient de toute maniere trop profond pour pouvoir etre realises. Je me demande si il a juste change d'avis et ne realise pas l'ampleur de la tache maintenant, ou si il s'est juste foutu de notre gueule a l'epoque.
A mon avis, vous pouvez toujours rever mais vous n'etes pas pret d'avoir un bon gui pour vim. Par bon gui, j'entends un truc qui ne soit pas equivalent a xterm + vim mais plutot un gui incrustable dans kdevelop, quanta ou kmail.
74 points : add IDE features (debugger integration, shell window)
Dites-moi, il a bien change Bram. Pareil, quand on lui a dit que separer vim en un moteur et un frontend permettrait d'integrer vim dans un IDE style KDevelop, il a dit que c'etait ce qu'il voulait (bien qu'il n'accepte aucun patch allant dans cette direction) et que vim ne devait pas devenir un IDE en soi.
62 points: support multiple top-level windows for one running Vim
La aussi, ca me fait marrer. Parmi toutes les directions qu'il ne voulait pas prendre, celle-ci semble quand meme la plus facile a ajouter au code.
# Yzis
Posté par Philippe F (site web personnel) . En réponse à la dépêche Vim 6.3 dans les bacs.. Évalué à 9.
Pour ce qui est de l'integration des nouvelles fonctionnalites, j'espere que Bram se comportera mieux que par le passe mais je n'y crois pas. Il ne lui a fallu << que >> deux ans pour integrer les patch de kvim dans vim. Des que tu lui demandes de changer une ligne de code, il faut compter entre 1 et 12 mois de discussions et negociations. Alors pour une nouvelle fonctionnalite, j'ose pas imaginer.
# Mouarf
Posté par Philippe F (site web personnel) . En réponse à la dépêche Concours pour la promotion de projets Libres francophones.. Évalué à 4.
Ca existe les projets libres connus et n'ayant pas besoin de resources ? Meme des projets majeurs comme KDE ou le noyau linux ont besoin de ressources alors pour les autres, j'imagine pas...
[^] # Re: Tout simplement bravo !
Posté par Philippe F (site web personnel) . En réponse à la dépêche Grisbi 0.5.0 disponible. Évalué à 2.
Autre cas que j'ai eu: je veux annuler un rapprochement parce que je l'ai mal utilise. J'ai pas vu comment faire depuis grisbi. Et idem, le faire a la souris sur 400 operations, je le sens pas trop. Alors meme que ca prend 10s sous vi.
[^] # Re: Tout simplement bravo !
Posté par Philippe F (site web personnel) . En réponse à la dépêche Grisbi 0.5.0 disponible. Évalué à 3.
Pour ce qui de la syntaxe du fichier xml, par exemple j'ai note que le nombre d'operations est ecrit dans le fichier alors meme que c'est un nombre qui pourrait etre calcule a la lecture du fichier. Du coup, si je rajoute une operation ou que j'en enleve une, ca craque.
Je pense qu'il y a possibilite de faire un fichier xml un tout petit moins interdependant, qui permettrait plus facilement de laisser la place a des modifs manuelles. Cela dit, en utilisant grisbi un peu plus, j'ai decouvert qu'il etait possible de faire ce que je voulais faire (changer toute une serie d'item de categorie) directement via grisbi (en effacant la categorie).
Pour ce qui est des filtres, je pense que ca peut etre sympa a inclure dans l'affichage des operations et que c'est plus facile a aprehender qu'un etat.
Un bon exemple de filtre est le filtre d'affichage des mails de Thunderbird. Il est facile a mettre en place et pas complique a utiliser.
Si un utilisateur peut en trois clics dire "affiche-moi toutes les depenses de plus de 1000 euro" parce qu'il sait qu'il veut modifier qqch dans ces depenses, c'est un atout.
Ah oui, une fonctionnalite pas trop difficile et fondamentale qui m'a
manque: la recherche d'operations.
Le mode d'emploi est tres bien fait, en francais, avec meme quelques references linguistiques.
Un probleme que j'ai avec mes comptes, c'est que je change souvent d'avis. Je decide de re-categoriser certains trucs differamment, de separer certaines depenses, de faire un virement compte a compte au lieu de marquer une depense et un revenu, etc.
C'est pour ca que j'ai eu des besoins de modifier le fichier xml. A mon avis, ce genre de problematique (les gens qui changent de methode de classement) est a prendre en compte car je ne suis certainement pas le seul.
A priori, l'utilisateur novice va commencer par utiliser les fonctionnalites de base de l'outil, puis, au fur a mesure qu'il se familiarise, modifier la facon dont il rentre ses operations pour tirer plus partie des possibliites du logiciel. Il sera donc amener a changer la facon dont il fonctionne.
Pour ce qui est du probleme du bugotron, je re-essaierai et vous tiendrait au courant. En tout cas, j'apprecie la reactivite sur linuxfr :-)
[^] # Re: Tout simplement bravo !
Posté par Philippe F (site web personnel) . En réponse à la dépêche Grisbi 0.5.0 disponible. Évalué à 7.
J'ai trouve que dans les details quand meme, il y avait des choses desagreables. Par exemple pour la version 0.4, il plantait toutes les minutes, au point que j'ai renonce a l'utiliser.
J'ai eu beau lutter, impossible de me logger sur leur systeme de gestion de bug, ce qui ne fait jamais une bonne impression.
Des petits trucs desagreable, comme le fait que les tailles des colonnes sont fixes et non redimensionnables, ou bien que les sommes ecrites ne soient pas alignees, donnant une impression de desordre.
Mais quand meme, en acceptant les limitations, c'est plutot sympatiques. Des trucs que j'aimerai voir dans le futur:
- une simplification de la syntaxe du fichier xml, pour pouvoir eventuellement le modifier a la main et eviter qu'il plante aussi souvent
- le selection d'operations pour pouvoir modifier un seul critere facilement (typiquement la categorie)
- des filtres dans l'affichage des operations
- le redimensionnement des colonnes
- dans les etats, la possibilite d'afficher mes depenses par categories.
J'espere que le projet evoluera vers qqch de bien.
[^] # Re: Y.org
Posté par Philippe F (site web personnel) . En réponse à la dépêche XFree86 a de moins en moins la côte. Évalué à 2.
[^] # Re: Y.org
Posté par Philippe F (site web personnel) . En réponse à la dépêche XFree86 a de moins en moins la côte. Évalué à 3.
Sinon, on pourrait imaginer un portage de Qt ou les boutons sont dessinnes par Y et pas par Qt. A mon avis sous cette phrase simple se cachent de nombreuses difficultes techniques difficile a resoudre. Mais Qt fonctionnant sous X11, win32, framebuffer et macos X, on peut s'imaginer qu'il est relativement independant de la methode d'affichage et saura gerer cela.
[^] # Re: Que disent les dévloppeurs de XFree86 ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche XFree86 a de moins en moins la côte. Évalué à 1.
> citation, ce n'est qu'une sale rumeur mesquine.
C'etait sur la liste forum de XFree, c'est tout ce dont je me souviens.
Pour ce qui est de la rumeur mesquine, la facon dont je le presente ne laisse en effet pas de place a d'autres interpretations. De toute facon, c'est un develloppeur qui supputait qu'un autre developpeur etait plutot depressif. Rien de bien precis en effet.
Mes excuses pour ce qui est de la sous-evaluation du nombre de developeurs restes sur XFree.
J'ai du respect pour les acomplissements passes de beaucoup de contributeurs du libre (RMS, les mainteneurs X, ESR) mais ca ne m'empeche pas d'etre en desaccord avec la direction qu'ils peuvent prendre dans leurs propos.
[^] # Re: Y.org
Posté par Philippe F (site web personnel) . En réponse à la dépêche XFree86 a de moins en moins la côte. Évalué à 6.
Le probleme de Y, c'est qu'il n'a aucune chance face a la popularite de X. Qui veut d'un environnement graphique ou l'appliation le plus avancees, c'est ycalc ?
[^] # Re: Le libre
Posté par Philippe F (site web personnel) . En réponse à la dépêche XFree86 a de moins en moins la côte. Évalué à 6.
Il y a eu des forks fructueux et infructueux dans le libre. Je note quand meme que sur les moyens et gros projets (gcc, emacs au moins), les forks ont ete plutot fructueux. Souvent, ces forks fructueux ou ces reecritures correspondent a une base de developpeurs plus actifs que les mainteneurs du projets officiels. Ce qui explique que ces forks soient des succes.
Je suis encore en train d'en vivre un, avec yzis (www.yzis.org) qui reecrit vim. A mon avis, dans deux ou trois ans, on sera mieux que vim.
[^] # Re: Que disent les dévloppeurs de XFree86 ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche XFree86 a de moins en moins la côte. Évalué à 0.
Le pluriel est mal adapte. Il ne reste que David machin a mon avis, dont l'ego-centrisme a accelere la mise en route de X.org
De ce que j'en ai lu, je retiens un mail d'un des developpeurs de XFree qui pense que David Dawes (le nom me revient) est en depression. Ca expliquerait ce changement de licence, pour le moins incongru, << dans le but de donner plus de reconnaissance a ceux qui le merite >>.
[^] # Re: Y.org
Posté par Philippe F (site web personnel) . En réponse à la dépêche XFree86 a de moins en moins la côte. Évalué à 6.
Cela dit, Y, ca m'a tout l'air d'etre un projet de loser. Il l'aurrait lance il y a 5 ans, je dis pas mais maintenant, c'est trop tard. Qt et Gtk sont la pour te farie oublier les petits soucis de X, qui sont a l'origine de la ceration de Y.
[^] # Re: question existentiel....
Posté par Philippe F (site web personnel) . En réponse à la dépêche Linux est une "perte d'argent". Évalué à 5.
Je trouve ca hypocrite de raisonner sur le cas specifique des super gros logiciels alors meme que la majorite des logiciels libres sont justement des petits logiciels pour lesquels le modele ne s'appliquerait pas. Prenons un exemple concret: GnomeMeeting est un super logiciel et j'aimerai bien que son auteur puisse passer du temps a le developper. Quel service il pourrait vendre dessus ? Il peut essayer de creer une dependance artificielle a un service global d'enregistrement des usagers sur lequel il se remunererait mais c'est vraiment creer artificiellement une depense et un besoin et c'est meme pas sur que ca marche.
Si on prend le cas de quelques developpeurs qui arrivent a vivre sponsorises sans passer par une distrib, je ne connais que les developpeurs de Quanta. Eric Laffont ne peut payer que des developpeurs de pays en developpement (pays de l'est, turquie) et encore, ceux-ci avouent qu'ils font de tres grosses concessions sur leur salaire et que ce travail ne leur assure aucune retraite ni securite sociale.
Donc arretez de vous voiler la face, le developpeur de logiciel libre qui peut vivre de son logiciel libre est un cas plus qu'exceptionnel. Ca doit representer moins d'un 10000e de la population de developpeurs.
[^] # Re: Impressionnant
Posté par Philippe F (site web personnel) . En réponse à la dépêche Enregistrement Audio et Interview de Nicolas Brulez sur le Reverse Engeenering. Évalué à 2.
ldd `which konqueror` | wc -> 40 dependances, loins d'etre triviales (X, fontconfig, pthreads, librender, ....)
Le pire pour des binaires, c'est une distrib style gentoo: etant donne qu'il n'y a pas d'arret dans le temps de la distrib, tous les utilisateurs ont une gentoo differente. C'est aussi le cas si je ne m'abuse des debian instables. Tous les developpeurs n'ont pas necessairement la derniere version du logiciel X. Ou bien ils ont une version plus recente que la version qui etait la quand le logiciel est sorti.
Vraiment, en dehors des langages interpretes/byte-compiles, je pense que la distribution binaire de masse sous Linux est vouee a l'echec. Bien sur, il y a les oracles qui te certifient une version de redhat et c'est tout. Ca va pour un serveur en fait.
# Impressionnant
Posté par Philippe F (site web personnel) . En réponse à la dépêche Enregistrement Audio et Interview de Nicolas Brulez sur le Reverse Engeenering. Évalué à 5.
Si on n'est pas cracker soi-meme, c'est d'ailleurs difficile d'etre expert dans ce domaine.
Je note aussi que tout ca est tres tres windows. Je me demande quelle serait la problematique sous Linux. D'un autre cote, il est absolument infaisable aujourd'hui de distribuer un produit grand public pour Linux sous forme binaire [3], donc de la a le securiser, on y est pas encore.
(2): c'est une faute de frappe !
[3]: je sais que certains vont bondir mais c'est une realite. 5 distributions majeures, avec au moins une mise a jour de la distrib tous les ans, ca fait 10 produits binaires a packager (de facon completement differente) par an minimum. Mais c'est sans compter les gentooistes qui vont recompiler leur libc, les linux sur PPC, les distributions mineures, ... La seule facon de distribuer un produit grand public sous linux, c'est de le developper dans un langage byte-code ou interprete (python roxor!)