Mouai, il reve bien le pere Perens. C'est genial de baser ca sur du debian, sauf que les gros marches sont ajourd'hui negocie par des partnaires commerciaux type Suse, RedHat ou Mandrake et donc ca certification ne vaut rien.
Plutot que de l'appeler hypocritement UserLinux, il ferait mieux de l'appeler par ce qu'elle est, debian.
En tant qu'employeur et en tant qu'employe, je ne crois pas du tout a ce contrat. Il ne laisse rien a l'employeur. En gros, l'employe possede tous les droits sur son travail et l'employeur n'a qu'a ramasser les miettes laissees par la GPL. C'est plus de l'emploi, c'est du mecenat. Je ne vois plus trop l'interet dans ce cas-la de payer un employe si de toute facon, il ferait un travail sous GPL.
Ce contrat me semble completement deconnecte de la logique commerciale et s'apparente plus a de la branlette intellectuelle libriste si vous m'excuser les mots.
Le choix logique pour une entreprise qui veut publier du logiciel libre, c'est de s'assigner a elle-meme le copyright mais de publier en GPL. Comme ca, si elle veut reintegrer par exemple du code qu'elle a developpe avec un logiciel proprietaire (ca arrive souvent), elle peut le faire sans etre obligee de negocier avec son propre employe.
C'est comme ca que fonctionnait cygwin (gcc sous windows produit du code GPL, vous devez raquer 10000$ pour avoir une version qui vous autorise a faire de close source, ou meme du LGPL, du BSD ou du MPL). C'est aussi le modele de Trolltech qui a besoin de garder le copyright sur Qt pour pouvoir en faire une version windows non GPL et gagner des sous. Redhat fonctionne aussi un peu comme ca, bref les exemples sont legions.
Un contrat qui m'aurait paru beaucoup plus utile et realiste aurait ete un contrat qui autorise l'employe a consacrer une part de son temps a developper du logiciel libre ou qui dit qu'il donne son copyright a la boite qui l'emploie si le code qu'il produit est publie entre autres sous une licence libre.
C'est pas la premiere fois que RMS fait chier son monde (il y avait eu aussil 'histoire avec un developpeur gcc). Comme beaucoup de personnes ayant lance un gros projet, il admet mal que des personnes puissent participer a son projet sans etre de son avis. Apres, il faut voir ce qui est "son" projet. En fait, on retrouve les memes luttes de pouvoir, souvent pathetiques dans toutes les petites associations.
En tout cas, je doute que la FSF ait un comportement democratique. Je me rappelle aussi d'un journaliste signalant qu'il avait de nombreuses fois demande les statuts et les comptes de la FSF et qu'il s'etait fait jete a chaque fois.
Il y a deux cas predominants ou je vois l'utilite d'une fenetre transparente:
- le dialogue de recherche: combien de fois un dialogue de recherche obscurcit-il le mot qu'il vient de trouver ?
- des applications qu'on a envie de garder sticky, comme un joueur de musique, ou un truc style gkrellm.
Sinon, le transparence des menus, je trouve que ca nuit carrement a la lisibilite. La transparence des xterm est sympa si ils sont franchement obscurcit (ou eclairci), pour qu'on puisse toujours lire derriere.
Bref, encore une techno a utiliser avec des pincettes, que tout le monde va utiliser a tort et a travers.
C'est la qu'on voit poindre l'interet d'une distrib comme gentoo. Il est plus facile de melanger des paquets gentoo instables avec une gentoo stable, puisque le paquet est compile.
Sachant que gentoo fait aussi tout pour faciliter la co-existence de plusieurs versions d'un meme soft en parallele, on peut s'amuser a faire des config un peu originales.
Genre chez moi, tout est stable sauf les trucs que je veux tester en avance de phase, genre KDE, XFree ou certains soft (bogofilter).
Novell a toujours ete tres bon en fourniture de gros services d'enterprises. Le probleme aujourd'hui, c'est que les gens veulent des solutions plus homogenes et que linux a le vent en poupe.
Avec ce rachat, ils se preparent a fournir un systeme complet pret a etre deploye en entreprise, qui va du desktop aux gros serveurs en passant par les petits serveurs.
Le terme de meta-paquet semble en effet plus approprie.
KDE s'est pose de nombreuse fois la question de diviser plus ses paquets facon Gnome, et a chaque fois rejete l'idee. Les arguments qui prevalent:
- avoir beaucoup de petits paquets rend la distribution de l'environnemnt complet plus penible, puisqu'il faut aller chercher manuellement 94 paquets.
- aujourd'hui, la bande passante est relativement bon marche, donc telecharger moins de paquets ne va pas faire une grosse difference. Dans la pratique, il est de plus tres probable que l'utilisateur selectif telecharge tous les paquets et ne les selectionne qu'au moment de la compilation/installation (ce qu'il peut faire de toute facon avec KDE)
- les dependances sont beaucoup beaucoup plus simples a gerer de cette facon. C'est une critique que Gnome endure depuis longtemps. Meme un developpeur moyen avait du mal a compiler Gnome avant Garnome.
- la compilation de l'ensemble est nettement simplifiee puisqu'on repose sur le classique (make -f makefile.dist; configure; make; make install). N'importe qui prenant un peu de temps peut compiler KDE a la main. On a vu des traducteurs inexperimentes le faire.
- on pourrait penser que KDE oblige a compiler tout un meta-paquet mais ce n'est pas le cas. D'une part, il existe une variable d'environnement ou une option du configure (peu documentee, certe) qui desactive la compilation de paquets designes, d'autre part, apres l'etape du configure, on peut simplement aller dans le repertoire de son choix et restreindre sa compilation/installation a ce repertoire. Donc, dans le cas d'une compilation/installation a la main, KDE offre le meme niveau de granularite que Gnome. Seule la version packagee differe.
- la fabrication des paquets pour rpm et deb pour un projet aussi gros et complexe que KDE ou Gnome est en general tres complexe. La simplification qu'apporte les meta-paquets devrait faciliter le travail de packageur (sauf si c'est un masochiste et qu'il recree a la main la granularite)
- la gestion des dependances entres petits paquets est aussi tres chiante a gerer pour les developpeurs.
La seule chose qu'on a donc pas avec ce systeme de packaging, c'est le choix pour les utilisateurs finaux de distributions packagees de choisir finement la liste des logiciels installes par les rpm (genre je veux kmail mais pas knode), choix legitime qui peut quand meme faire sourire certains( "putain, j'ai gagne 0.0000013 go (1.3 ko) de binaire sur mon disque de 30 Go, ca se fete!" )
Ah si, un autre truc chiant avec le systeme de KDE, c'est que c'est difficile de distribuer une application hors du framework du KDE. Genre je fais evoluer ktrucmuche qui fait partie de KDE, c'est pas facile de faire une release independante. Cela dit, ca se fait quand meme et il y a un outil dans KDE pour extraire des applictions.
> J'apporte ces précisions avant tout parce que vous ne pouvez vous
> empêcher quelque soit le prétexte de dénigrer Gnome :-)
Je ne m'en cache pas. Cela dit, j'essaie de le faire a chaque fois en tout honnetete, avec des arguments objectifs, en presentant une perspective historique, et en reconnaissant les faiblesses de KDE et les atouts de Gnome.
Je felicite d'ailleur l'auteur pour cet excellent outil.
Mais quand meme, je ne peux m'empecher de rappeler que la principale raison de l'existence de garnome, c'est la complexite du build de Gnome. 94 package a compiler si je me souviens, c'est pas rien.
A cote, KDE frise le 20 paquets, on est plus tranquille. Sans etre un dieu de KDE, il etait deja possible de compiler KDE a la main et de l'installer chez soi, il suffit de faire 10 fois (make -f makefile.dist; configure --enable-prefix ~/kde-experimental; make; make install).
Mais avec konstruct, meme les moules peuvent y arriver.
Mandrake en avait deja pris le chemin, Red hat fait un grand pas en avant (ce qui me rappelle cette citation, autrefois dediee a windows: Redhat xXX, on etait au bord du gouffre. Redhat YYYY, on a fait un grand pas en avant). Reste plus que Suse.
Il faut pas se leurrer, ces versions de maintenances coutent hyper cher aux distrib, sans leur rapporter un sou. En ces temps de fermete financiere, le coup etait previsible.
D'un autre cote, si c'est accompagne d'une livraison totale des outils de packaging, de sorte que la communaute (car c'est bien d'elle qu'il s'agit, les entreprises auront toujours leur mise a jour) puisse se faire ses versions de maintenance, ca parait pas trop malhonnete.
Je prefere quand meme le modele mandrake, ou a partir d'un systeme d'abonnement au club, tu repasses utilisateur avec des prerogatives.
Bien sur que j'ai essaye g++, je compile mon projet en meme temps sous linux, sous windows et sous cygwin. Si on fait la comparaison, j'ai pas eu de problemes de stack sous g++, p'tet qu'il gere ca differamment.
Sous cygwin, gcc et g++, c'est gentil mais c'est hyper lent. Multiplie environ par 10 le temps de compilation d'un projet. Probleme bien connu de cygwin, peut-etre a cause de la simulation des droits posix sur un systeme de fichier win32.
Meme en comparant ce qui parait comparable (linux/gcc et windows/visual), visual compile nettement plus vite, de l'ordre de x2 ou x3 (template ou pas template). Et je n'ai pas utilise des headers precompiles.
Sinon, c'est vrai que Visual est plutot pourri dans sa gestion des template. Cote compilateur lui-meme, ca a pas l'air trop genant dans mon projet modeste, mais il ne faut surtout pas oublier d'installer les service pack.
Oui mais non: je compile un projet boost.python en debug (donc pas d'optimisation) de 50 lignes et la compilation du fameux fichier .cpp prend au bas mot une minute. Et ca bouffe enormement en memoire. Sous Visual, j'ai du augmenter comme un malade la taille de la pile du compilateur.
Finalement, je crois que je prefere des macros bien crades que des template. D'une part, c'est beaucoup plus portable. D'autre part, tu as beaucoup moins d'emmerdes de compilation. Surtout qu'une erreur de template te crache un lignes de 1000 caracteres minimum. Ca aide pas beaucoup pour s'y retrouver.
C'est marque ou que pour etre un Unix, il fallait un noyau monolithique ? C'est juste les habitudes du domaine. Pour moi unix, c'est vraiment l'organisation des services, l'api posix, le "tout est un fichier" et autres.
Tout a fait. Plus tu as une version recente de KDE, mieux c'est mais il existe bon nombre de bugs qui ont ete corriges mais non ferme. C'est de ceux-la qu'on voudrait se debarasser.
Le control center de KDE est en effet assez charge mais il faut souligner que de gros efforts ont ete faits pour le simplifier (sans retirer de fonctionnalites, contrairement a Gnome). La fonction recherche est egalement bien pratique. Pour les prochaines version, Aaron Seigo songeait a poser un systeme de lien permettant de sauter facilement d'une section du control center a une autre qui traite un sujet similaire.
Pour ma part, je trouve qu'editer une base de registre pour configurer une application est d'une part hors du cadre de l'objectif de convivialite d'un desktop comme Gnome ou KDE (en un mot: debile), d'autre part un peu trop proche philosophiquement d'un autre OS que j'execre. Sans parler du fait que c'est du deni d'information, puisque l'utilisateur standard qui se base sur la boite de configuration pour confrigurer son application n'aura pas acces a toutes les options, qu'il soit neuneu ou hacker. Seul ceux qui auront lu les sources ou tripatouilles les fichiers de config sauront que d'autres options existe. C'est beaucoup moins propre comme approche.
> certains projets Gnome (Anjuta) intègraient déjà leurs propres boîtes de sélection
Ca, c'est un probleme recurrent de Gnome: le toolkit Gtk/Gnome est en retard par rapport a la convivialite que certaines applications souhaitent donner a leur utilisateurs.
Du coup, beaucoup d'applications reecrivent elle-meme des fonctionnalites qui n'ont rien de specifiques a l'application, mais qui different d'applications en application. D'ou un manque de coherence assez difficile a supporter quand on est habitue a KDE (critique que les habitues de Gnome comprennent mal en general)
Le cas de la boite de selection de fichier n'est pas unique, j'en avais note d'autre dans gtk/gnome 1 . Par exemple, la choix des boutons des barres d'outils etait fait manuellement par quelques applications mais pas toutes, et pas toujours de la meme facon.
Je dois dire que KDE souffre peu de ce probleme, mais a le probleme inverse: un ensemble de librairie tres fonctionnel et complet, mais parfois un peu indigeste a utiliser. Du coup on a des applications trop ultra-fonctionnelles :-)
Putty est indispensable sous windows. Ainsi que tightvnc pour se connecter sur sa machine a la maison.
Si vous avez un mechant proxy, rappelons que http tunnel marche aussi sous windows.
Dans la serie des autres outils indispensables pour survivre en developpant sous windows:
- gimp
- cygwin
- source navigator
- tortoise cvs
- vim (non, pas emacs)
- ghostview (ou n'importe quoi pour visualiser des postscript)
Avec tout ca, on arrive a se faire un poste de travail potable. Le truc qu i me manque le plus, ca reste quand meme les bureaux virtuels.
> oui mais selon le hardware, il peut avoir des parties de code differentes activée.
Je ne vois pas bien en quoi ca peut influencer le benchmark. Puisqu'il a utilise une seule machine, tu peux dire qu'il benchmark une configuration particuliere de linux, en effet. Et il compare tous les OS sur cette configuration particuliere.
[^] # Re: Bruce Perens propose UserLinux
Posté par Philippe F (site web personnel) . En réponse à la dépêche Bruce Perens propose UserLinux. Évalué à -2.
Plutot que de l'appeler hypocritement UserLinux, il ferait mieux de l'appeler par ce qu'elle est, debian.
[^] # Re: Contrat de travail et Logiciel Libre
Posté par Philippe F (site web personnel) . En réponse à la dépêche Contrat de travail et Logiciel Libre. Évalué à 3.
Ce contrat me semble completement deconnecte de la logique commerciale et s'apparente plus a de la branlette intellectuelle libriste si vous m'excuser les mots.
Le choix logique pour une entreprise qui veut publier du logiciel libre, c'est de s'assigner a elle-meme le copyright mais de publier en GPL. Comme ca, si elle veut reintegrer par exemple du code qu'elle a developpe avec un logiciel proprietaire (ca arrive souvent), elle peut le faire sans etre obligee de negocier avec son propre employe.
C'est comme ca que fonctionnait cygwin (gcc sous windows produit du code GPL, vous devez raquer 10000$ pour avoir une version qui vous autorise a faire de close source, ou meme du LGPL, du BSD ou du MPL). C'est aussi le modele de Trolltech qui a besoin de garder le copyright sur Qt pour pouvoir en faire une version windows non GPL et gagner des sous. Redhat fonctionne aussi un peu comme ca, bref les exemples sont legions.
Un contrat qui m'aurait paru beaucoup plus utile et realiste aurait ete un contrat qui autorise l'employe a consacrer une part de son temps a developper du logiciel libre ou qui dit qu'il donne son copyright a la boite qui l'emploie si le code qu'il produit est publie entre autres sous une licence libre.
# Re: Conférences accessibilité
Posté par Philippe F (site web personnel) . En réponse à la dépêche Conférences accessibilité. Évalué à 3.
http://accessibility.kde.org/(...)
Du cote des mal-voyants, citons un konqueror parlant, une loupe, des styles optimises (couleur a fort contraste, gros caracteres)
Des solutions pour les personnes ayant du mal a cliquer la souris (typiquement, le carpal tunnel)
# Re: Un mainteneur HURD poussé dehors par Stallman pour avoir critiqué une licence GNU
Posté par Philippe F (site web personnel) . En réponse à la dépêche Un mainteneur HURD poussé dehors par Stallman pour avoir critiqué une licence GNU. Évalué à 10.
En tout cas, je doute que la FSF ait un comportement democratique. Je me rappelle aussi d'un journaliste signalant qu'il avait de nombreuses fois demande les statuts et les comptes de la FSF et qu'il s'etait fait jete a chaque fois.
# Re: Un nouveau serveur X avec la transparence !
Posté par Philippe F (site web personnel) . En réponse à la dépêche Un nouveau serveur X avec la transparence !. Évalué à 10.
- le dialogue de recherche: combien de fois un dialogue de recherche obscurcit-il le mot qu'il vient de trouver ?
- des applications qu'on a envie de garder sticky, comme un joueur de musique, ou un truc style gkrellm.
Sinon, le transparence des menus, je trouve que ca nuit carrement a la lisibilite. La transparence des xterm est sympa si ils sont franchement obscurcit (ou eclairci), pour qu'on puisse toujours lire derriere.
Bref, encore une techno a utiliser avec des pincettes, que tout le monde va utiliser a tort et a travers.
[^] # Re: ...et vous, vous auriez pris quoi ?
Posté par Philippe F (site web personnel) . En réponse au sondage ...et vous, vous auriez pris quoi ?. Évalué à 2.
[^] # Re: Fedora Core 1 [Cambridge] est disponible
Posté par Philippe F (site web personnel) . En réponse à la dépêche Fedora Core 1 [Yarrow] est disponible. Évalué à 4.
Sachant que gentoo fait aussi tout pour faciliter la co-existence de plusieurs versions d'un meme soft en parallele, on peut s'amuser a faire des config un peu originales.
Genre chez moi, tout est stable sauf les trucs que je veux tester en avance de phase, genre KDE, XFree ou certains soft (bogofilter).
[^] # Re: Pipe -> erreur ?
Posté par Philippe F (site web personnel) . En réponse au message [Terminal] Du bon ordre des redirections. Évalué à 1.
[^] # Re: SuSE Linux racheté par Novell
Posté par Philippe F (site web personnel) . En réponse à la dépêche SuSE Linux racheté par Novell. Évalué à 4.
Novell a toujours ete tres bon en fourniture de gros services d'enterprises. Le probleme aujourd'hui, c'est que les gens veulent des solutions plus homogenes et que linux a le vent en poupe.
Avec ce rachat, ils se preparent a fournir un systeme complet pret a etre deploye en entreprise, qui va du desktop aux gros serveurs en passant par les petits serveurs.
En tout cas, chapeau.
[^] # Re: Konstruct, essayer KDEdans votre répertoire
Posté par Philippe F (site web personnel) . En réponse à la dépêche Konstruct, essayez KDE dans votre répertoire. Évalué à 2.
KDE s'est pose de nombreuse fois la question de diviser plus ses paquets facon Gnome, et a chaque fois rejete l'idee. Les arguments qui prevalent:
- avoir beaucoup de petits paquets rend la distribution de l'environnemnt complet plus penible, puisqu'il faut aller chercher manuellement 94 paquets.
- aujourd'hui, la bande passante est relativement bon marche, donc telecharger moins de paquets ne va pas faire une grosse difference. Dans la pratique, il est de plus tres probable que l'utilisateur selectif telecharge tous les paquets et ne les selectionne qu'au moment de la compilation/installation (ce qu'il peut faire de toute facon avec KDE)
- les dependances sont beaucoup beaucoup plus simples a gerer de cette facon. C'est une critique que Gnome endure depuis longtemps. Meme un developpeur moyen avait du mal a compiler Gnome avant Garnome.
- la compilation de l'ensemble est nettement simplifiee puisqu'on repose sur le classique (make -f makefile.dist; configure; make; make install). N'importe qui prenant un peu de temps peut compiler KDE a la main. On a vu des traducteurs inexperimentes le faire.
- on pourrait penser que KDE oblige a compiler tout un meta-paquet mais ce n'est pas le cas. D'une part, il existe une variable d'environnement ou une option du configure (peu documentee, certe) qui desactive la compilation de paquets designes, d'autre part, apres l'etape du configure, on peut simplement aller dans le repertoire de son choix et restreindre sa compilation/installation a ce repertoire. Donc, dans le cas d'une compilation/installation a la main, KDE offre le meme niveau de granularite que Gnome. Seule la version packagee differe.
- la fabrication des paquets pour rpm et deb pour un projet aussi gros et complexe que KDE ou Gnome est en general tres complexe. La simplification qu'apporte les meta-paquets devrait faciliter le travail de packageur (sauf si c'est un masochiste et qu'il recree a la main la granularite)
- la gestion des dependances entres petits paquets est aussi tres chiante a gerer pour les developpeurs.
La seule chose qu'on a donc pas avec ce systeme de packaging, c'est le choix pour les utilisateurs finaux de distributions packagees de choisir finement la liste des logiciels installes par les rpm (genre je veux kmail mais pas knode), choix legitime qui peut quand meme faire sourire certains( "putain, j'ai gagne 0.0000013 go (1.3 ko) de binaire sur mon disque de 30 Go, ca se fete!" )
Ah si, un autre truc chiant avec le systeme de KDE, c'est que c'est difficile de distribuer une application hors du framework du KDE. Genre je fais evoluer ktrucmuche qui fait partie de KDE, c'est pas facile de faire une release independante. Cela dit, ca se fait quand meme et il y a un outil dans KDE pour extraire des applictions.
> J'apporte ces précisions avant tout parce que vous ne pouvez vous
> empêcher quelque soit le prétexte de dénigrer Gnome :-)
Je ne m'en cache pas. Cela dit, j'essaie de le faire a chaque fois en tout honnetete, avec des arguments objectifs, en presentant une perspective historique, et en reconnaissant les faiblesses de KDE et les atouts de Gnome.
[^] # Re: Konstruct, essayer KDEdans votre répertoire
Posté par Philippe F (site web personnel) . En réponse à la dépêche Konstruct, essayez KDE dans votre répertoire. Évalué à 2.
Je felicite d'ailleur l'auteur pour cet excellent outil.
Mais quand meme, je ne peux m'empecher de rappeler que la principale raison de l'existence de garnome, c'est la complexite du build de Gnome. 94 package a compiler si je me souviens, c'est pas rien.
A cote, KDE frise le 20 paquets, on est plus tranquille. Sans etre un dieu de KDE, il etait deja possible de compiler KDE a la main et de l'installer chez soi, il suffit de faire 10 fois (make -f makefile.dist; configure --enable-prefix ~/kde-experimental; make; make install).
Mais avec konstruct, meme les moules peuvent y arriver.
[^] # Re: Red Hat arrête le support gratuit
Posté par Philippe F (site web personnel) . En réponse à la dépêche Red Hat arrête le support gratuit. Évalué à 2.
Mandrake en avait deja pris le chemin, Red hat fait un grand pas en avant (ce qui me rappelle cette citation, autrefois dediee a windows: Redhat xXX, on etait au bord du gouffre. Redhat YYYY, on a fait un grand pas en avant). Reste plus que Suse.
Il faut pas se leurrer, ces versions de maintenances coutent hyper cher aux distrib, sans leur rapporter un sou. En ces temps de fermete financiere, le coup etait previsible.
D'un autre cote, si c'est accompagne d'une livraison totale des outils de packaging, de sorte que la communaute (car c'est bien d'elle qu'il s'agit, les entreprises auront toujours leur mise a jour) puisse se faire ses versions de maintenance, ca parait pas trop malhonnete.
Je prefere quand meme le modele mandrake, ou a partir d'un systeme d'abonnement au club, tu repasses utilisateur avec des prerogatives.
[^] # Re: SCO enfonce le clou.
Posté par Philippe F (site web personnel) . En réponse à la dépêche SCO enfonce le clou.. Évalué à 10.
Ok, je sors.
[^] # Re: Le futur de GCC se dévoile !
Posté par Philippe F (site web personnel) . En réponse à la dépêche Le futur de GCC se dévoile !. Évalué à 6.
Sous cygwin, gcc et g++, c'est gentil mais c'est hyper lent. Multiplie environ par 10 le temps de compilation d'un projet. Probleme bien connu de cygwin, peut-etre a cause de la simulation des droits posix sur un systeme de fichier win32.
Meme en comparant ce qui parait comparable (linux/gcc et windows/visual), visual compile nettement plus vite, de l'ordre de x2 ou x3 (template ou pas template). Et je n'ai pas utilise des headers precompiles.
Sinon, c'est vrai que Visual est plutot pourri dans sa gestion des template. Cote compilateur lui-meme, ca a pas l'air trop genant dans mon projet modeste, mais il ne faut surtout pas oublier d'installer les service pack.
[^] # Re: Le futur de GCC se dévoile !
Posté par Philippe F (site web personnel) . En réponse à la dépêche Le futur de GCC se dévoile !. Évalué à 2.
Finalement, je crois que je prefere des macros bien crades que des template. D'une part, c'est beaucoup plus portable. D'autre part, tu as beaucoup moins d'emmerdes de compilation. Surtout qu'une erreur de template te crache un lignes de 1000 caracteres minimum. Ca aide pas beaucoup pour s'y retrouver.
[^] # Re: erreur sur le wiki:
Posté par Philippe F (site web personnel) . En réponse à la dépêche Rencontre technique sur Mac OS X. Évalué à 7.
[^] # Re: KDE : On ferme ! (les bugs)
Posté par Philippe F (site web personnel) . En réponse à la dépêche KDE : On ferme ! (les bugs). Évalué à 1.
[^] # Re: KDE : On ferme ! (les bugs)
Posté par Philippe F (site web personnel) . En réponse à la dépêche KDE : On ferme ! (les bugs). Évalué à 3.
Pour ma part, je trouve qu'editer une base de registre pour configurer une application est d'une part hors du cadre de l'objectif de convivialite d'un desktop comme Gnome ou KDE (en un mot: debile), d'autre part un peu trop proche philosophiquement d'un autre OS que j'execre. Sans parler du fait que c'est du deni d'information, puisque l'utilisateur standard qui se base sur la boite de configuration pour confrigurer son application n'aura pas acces a toutes les options, qu'il soit neuneu ou hacker. Seul ceux qui auront lu les sources ou tripatouilles les fichiers de config sauront que d'autres options existe. C'est beaucoup moins propre comme approche.
[^] # Re: KDE : On ferme ! (les bugs)
Posté par Philippe F (site web personnel) . En réponse à la dépêche KDE : On ferme ! (les bugs). Évalué à 5.
Ca, c'est un probleme recurrent de Gnome: le toolkit Gtk/Gnome est en retard par rapport a la convivialite que certaines applications souhaitent donner a leur utilisateurs.
Du coup, beaucoup d'applications reecrivent elle-meme des fonctionnalites qui n'ont rien de specifiques a l'application, mais qui different d'applications en application. D'ou un manque de coherence assez difficile a supporter quand on est habitue a KDE (critique que les habitues de Gnome comprennent mal en general)
Le cas de la boite de selection de fichier n'est pas unique, j'en avais note d'autre dans gtk/gnome 1 . Par exemple, la choix des boutons des barres d'outils etait fait manuellement par quelques applications mais pas toutes, et pas toujours de la meme facon.
Je dois dire que KDE souffre peu de ce probleme, mais a le probleme inverse: un ensemble de librairie tres fonctionnel et complet, mais parfois un peu indigeste a utiliser. Du coup on a des applications trop ultra-fonctionnelles :-)
# Re: Chercher un mot
Posté par Philippe F (site web personnel) . En réponse au message [Éditeur/Vim] Chercher un mot. Évalué à 1.
En gros, mon curseur est sur un mot, je tape ma commande magique et je vois apparaitre en bas: s/mon mot/
Maintenant que j'y songe, ca doit pas etre dur a faire sous forme de macro.
[^] # Re: GetFree : script d'installation automatique de logiciels libres sur Windows
Posté par Philippe F (site web personnel) . En réponse à la dépêche GetFree : script d'installation automatique de logiciels libres sur Windows. Évalué à 3.
Si vous avez un mechant proxy, rappelons que http tunnel marche aussi sous windows.
Dans la serie des autres outils indispensables pour survivre en developpant sous windows:
- gimp
- cygwin
- source navigator
- tortoise cvs
- vim (non, pas emacs)
- ghostview (ou n'importe quoi pour visualiser des postscript)
Avec tout ca, on arrive a se faire un poste de travail potable. Le truc qu i me manque le plus, ca reste quand meme les bureaux virtuels.
[^] # Re: emacs 21
Posté par Philippe F (site web personnel) . En réponse au message [Éditeur/Emacs] Ouvrir les fichiers compressés. Évalué à 1.
Vim est chiant aussi a configurer, mais le pseudo langage de configuration est quand meme plus facile a aprrehender que le lisp.
# Re: OpenOffice.org sur France Info
Posté par Philippe F (site web personnel) . En réponse à la dépêche OpenOffice.org sur France Info. Évalué à 2.
Le message qui reste apres avoir lu l'article, c'est "pas mal mais mieux vaut voir ailleur".
# Re: Ma boite a un site web :
Posté par Philippe F (site web personnel) . En réponse au sondage Ma boite a un site web :. Évalué à 1.
[^] # Re: Comparatif des performances *BSD et Linux
Posté par Philippe F (site web personnel) . En réponse à la dépêche Comparatif des performances *BSD et Linux. Évalué à 3.
Je ne vois pas bien en quoi ca peut influencer le benchmark. Puisqu'il a utilise une seule machine, tu peux dire qu'il benchmark une configuration particuliere de linux, en effet. Et il compare tous les OS sur cette configuration particuliere.