Guillaume Laurent a écrit 1148 commentaires

J'ai pas trop envie de perdre tous mes mails et autres RDV de Korganizer dès le passage à la 3.0

Où as-tu vu qu'on perdait ses mails et ses RV ? Je suis passé de la 2.2.2 à la 3.0 sans aucun problème de la sorte...

Et tu cherches quoi, défendre l'idée que quand tout le monde ment

Pas "tout le monde", juste toutes les grosses boites, en fonction du business. Je ne défends pas l'idée, je dis juste que c'est tellement normal que tout le monde s'en fout, ça fait partie du jeu. Quand MS fait une campagne pour dénigrer Unix, est-ce que tu crois vraiment que tout le monde gobe ça tout cru ? Et Sun est en train de faire pareil à propos de Linux sur mainframe.

Je ne crois pas qu'il soit utile d'en reparler :-).

pBG fait remarquer qu'ESR n'est pas très fidèle à ses principes (dans la même situation, RMS se serait barré, ESR lui, a écrit pour *justifier* le fait que VA devienne semi-propriétaire), et qu'il n'est pas forcément si "expert" que ça (ce qui n'est pas vraiment une nouvelle non plus).

On lui répond que vu qu'il bosse chez MS, il ne dit forcément que des conneries. Même si c'est une parodie, ce qui n'est pas évident à lire la plupart des posts suivants dans le thread, je ne vois pas en quoi elle infirme les remarques de pBG.

Microsoft et ses employés sont les rois de la désinformation. [...]

Et là, tu as vraiment l'impression d'être un esprit critique, et d'apporter les preuves de ce que tu avances ? MS fait de la désinformation. Oh ben ça alors, quelle surprise. Ben oui, comme tout le monde, bienvenue dans le monde réel. Ça ne veut pas dire que tous leurs employés approuvent ou pratiquent ces méthodes.

ESR est loin d'être tout blanc, il a dit et fait son lot de conneries, et il en sortira surement d'autres (d'ailleurs rien que dans cette interview y en a quelques unes).

les logiciels deviennnet si gros que les societes ne peuvent plus s'en charger de facon optimale

Non. Si tu veux un produit fini (documenté, traduit, testé, etc...), il te faut des gens payés à faire les trucs chiants qu'aucun "hacker" n'a envie de faire, des gens pour les manager, des bureaux pour les mettre, et un minimum de process (ESR le dit lui-même d'ailleurs).

Pitié, grandis un peu. On croirait une fan de Britney Spears à qui on vient de dire qu'elle ne sait pas chanter.

Ouais, et pis même que MS c'est rien que des gros méchants qui font rien qu'a m'embeter, na d'abord.

J'ai eu plus de 30 jours d'uptime sur une machine W2K que j'utilisais pour bosser (MSVC++, Outlook, IE). Aucun blue screen, pratiquement pas de crash des softs...

Mais bon, c'est pas grave hein, il est "mort né" donc tout va bien :-).

> Ca me praît assez bien vu

Sauf qu'il avait déjà prédit exactement la même chose il y a plus d'un an, en avançant même un délai de 5 à 6 mois pour la "chute" :

http://lwn.net/2000/features/ESR/(...)

And it is at that point, that the Microsoft monopoly will collapse, because they will then unbundle Windows from their machines, and offer something that's inexpensive (like, say, Linux), in an effort to get some of their margin. I believe that will happen probably within five to six month from now, and that's probably before Linux will become polished and be ready for the end user.

Non, mais le DnD et un environnement intégré, oui, ça a un rapport.

Ça aussi c'est le genre de principe qui tient pas trop le choc quand il est confronté à la réalité.

Les problèmes réels sont complexes, les besoins des utilisateurs sont complexes, et si tu te pointes en disant "bon ben finalement pour votre éditeur de texte j'ai juste fait 'cat > fichier' parce que c'est simple", ça le fait pas.

Après oui, faut pas complexifier pour rien non plus, bien sur.

Oui, ou bien l'OS peut être fiable, et le soft dessus assez bien foutu pour qu'il soit facile à parametrer.

Meuh non, comme Konqueror.

Enfin j'ai pas l'impression que les choses aient beaucoup changé de ce côté personnellement.

Euh si, un peu. Enfin quoique, les composants sont un peu une extension de ce principe. Disons plutôt que c'est la notion de "tâche à faire" qui a évoluée. Au début d'Unix, c'était "dumper un fichier", ou "splitter un fichier texte en plusieurs colonnes", etc... Maintenant c'est "gerer le mail et les news", ou "browser le web". C'est juste un cran au dessus.

Bref, tout ça pour dire qu'un frigo avec un OS dedans, c'est potentiellement une très bonne idée.

Et pour info, cette "théorie" qui n'est pas une théorie mais une option de design, n'a pas été inventé par le projet GNU mais par les concepteurs originaux d'Unix, Denis Ritchie et Ken Thompson.

Cette théorie fonctionne très bien pour nous

Non, elle fonctionne bien pour faire le puriste sur LinuxFr, mais en réalité ça fait longtemps qu'elle est dépassée. :-)

Me prévenir quand il est vide ?

Oui, ou prévenir ton supermarché pour qu'il te livre les produits qui te manquent.

Ça va, merci, je sais quand je l'ouvre et que je prends des trucs dedans, je n'ai pas besoin d'assistance pour ça.

Ah, tu fais donc partie de ces sur-êtres à qui il n'arrive jamais d'oublier de faire les courses, et qui ne se retrouvent jamais devant leur frigo en disant "merde j'ai oublié de racheter tel ou tel truc". :-) Mais pour les gars comme moi, ce genre de gadget serait très utile.

Ok, ok tu as raison, j'avoue, je n'ai fait que détourner tes propos, délirer, tout ce que tu veux.

Maintenant pour achever de démontrer ce que tu avances, je te suggère d'ajouter à Konqueror la possibilité de visualiser les .txt dans l'éditeur que l'on veut. C'est assez simple comme cas, ça ? En plus KDE fourni tout ce qu'il faut comme classes pour wrapper le lancement de process. Et une fois que tu l'aura fait, ce qui je suis sur ne te prendra que quelques heures puisque c'est si simple, propose le patch sur kfm-devel et kde-devel. Je suis sur qu'il y aura plein de personnes interessées.

L'une d'entre elles étant triviale.

Tu l'as codé souvent, pour pouvoir dire ça ?

Evidemment, si certains le programmes le font c'est bien pour se décharger de tout une tâche.

Ah, c'est sur, fork()+exec() ça reste plus simple que re-coder un éditeur de texte ou autre :-).

Pour le bénéfice, c'est simplement celui du choix.

Encore une fois : trouve moi un utilisateur non-geek qui se préoccupe de forker un programme externe plutôt que d'utiliser un composant. Trouve m'en un qui sache ce que c'est que forker un programme, et ce qu'est un composant, déjà.

Tu retournes au défaut que tu as proposé évidemment.

Et un p'tit message d'erreur, non, jamais ?

Si ça t'amuse de le faire tu peux essayer, mais sinon laisse l'utilisateur définir sa ligne de commande, ce sera bien suffisant.

Oh ben oui, c'est top user-friendly ça. Et avec un peu de chance il faudra quand même coder l'expansion de quelques token genre '%F' pour placer le nom du fichier dans certains cas, et prier pour que ça n'ouvre pas quelques trous de sécurité (y a pas mal d'exploits qui partent de ce genre de trucs).

N'importe quoi ça fait maximum une ligne, si tu as une config ça s'ajoute comme n'importe quelle autre élément de config.

Plus la ligne qui dit "l'utilisateur veut ça plutôt qu'un composant".

Et tu oublies toujours la détéction et récupération en cas de crash du truc, le cancel quand il s'agit d'un éditeur, etc...

De plus les fichiers de mode c'est passé de mode ? Tiens donc, suivant que ça t'arrange, l'utilisateur est tantot geek tantot neuneu.

Attends, on parle bien d'une appli utilisant des composants, donc un truc un tantinet moderne tout de même, sur laquelle tu voudrais absolument ajouter la possibilité pour l'utilisateur de lancer le programme de son choix à la place du composant standard. Donc soit tu es cohérent, et tu fais la config propre, soit tu es goret et tu ajoute deux options dans le fichier de conf, "spécial geek" a bricoler à la main. Pourquoi pas. :-)

L'utilisateur normal étant défini parce qu'il utilise

Non, il est défini par ce qu'il veut faire. C'est à dire pas bricoler des fichiers de confs et s'emmerder avec des considérations "fork()+exec() c'est mieux qu'un composant" auquel il ne comprend rien de toute façon.

Dès qu'on a des critères c'est normal de vouloir choisir un wm plutot qu'un autre.

Non, ça n'est pas "normal" de vouloir choisir son WM. C'est comme si tu me disais qu'il est "normal" de vouloir bricoler sa voiture ou sa chaine Hi-Fi. 99% des gens s'en foutent complètement, ils veulent juste conduire ou écouter de la musique.


Rien ne permet de l'affirmer

Ça fait plus de 10 ans que je fréquente Unix, et je crois que je peux tout à fait t'affirmer que la profusion de toolkits graphiques, de window managers, et au final la non-spécification de l'environnement (aussi bien l'API système, avant POSIX, que l'API graphique "haut niveau") est très largement responsable de l'echec d'Unix (et maintenant de Linux) sur le desktop.

C'est satisfaisant pour le développeur, pas trop pour l'utilisateur.

Windows satisfait beaucoup plus d'utilisateurs que Linux, pour le cas où tu ne l'aurais pas remarqué.

A moins que tu ne crois sérieusement qu'ils sont tous victimes de la propagande du grand méchant Microsoft, auquel cas autant arrêter là la discussion.

J'ai parlé de la même appli (ou ensemble d'applications).

Par "ensemble d'applications" tu veux dire une suite office, avec un tableur et un traitement de texte par exemple ? :-)

Je ne comprend pas ton argument. Tu dis que pour l'utilisateur, "fork()+exec()" ou des composants c'est pareil. C'est faux, pour la bonne raison que les composants permettent plus de choses que fork()+exec().

Si tout ce que tu dis c'est que dans les cas ou fork()+exec() marche, alors utiliser des composants est identique du point de vue de l'utilisateur, c'est faux aussi. Tu as une interface beaucoup plus cohérente avec des composants, et c'est plus rapide.

Il reste encore pleins de cas ou un fork()+exec() est utile, ou même nécéssaire (le front-end au graveur de CD par ex.), mais globalement un framework de composants comme KPart apporte un énorme plus.

Pour dire qu'on préfère son propre viewer html (ne nécessitant pas de retour) plutot que le composant, il suffit d'un fork comme tu l'as dit, et d'une variable dans un fichier de conf ou dans l'environnement.

Et donc juste pour faire plaisir à quelques geeks, il faudrait coder 2 façons de visualiser de l'html, plus toute la config qui va avec, etc... ? Et tu penses vraiment que c'est "simple" ? Et quel va être le bénéfice, ça ne va même pas être plus rapide, fork()+exec() est plus lent d'un simple dlopen(). C'est vraiment du bloat totalement gratuit.

Par ailleurs, les composants n'empèchent pas le choix, il peut y avoir plusieurs composants disponible pour une même fonction, et que l'environnement te laisse choisir celui que tu veux utiliser par défaut.

Pour un mail (je reprends l'exemple de mutt) il va certainement chercher $EDITOR, et ajoute le nom de son fichier temporaire. Pas compliqué.

Qu'est-ce que tu fais si $EDITOR pointe vers un truc inexistant ? Si il se plante ? Et regarde le cas "simple" d'Emacs qui a un mode par type de fichier. Pour faire du mail, idéalement tu veux indented-text, auto-fill, et filladapt (et j'oublie font-lock). vi lui est complètement différent. Comment tu fais pour lui dire de passer au bon mode ? Et si l'utilisateur décide de ne pas envoyer le mail, et quitte brutalement l'éditeur, comme tu fais pour reconnaitre ça ?

et que ce sera à lui de fournir ces infos, dans un fichier de conf, dans un tab de conf, n'importe où, peu importe.

Sauf que tu dois te frapper le codage du parsing de la config, plus l'éditeur de préférences parce que de nos jours éditer des fichiers de conf à la main c'est un peu passé de mode.

Le framework unifie mais restreint. C'est une solution.

Oui, et elle recouvre 99% des besoins des utilisateurs normaux.

C'est du même niveau que quand les pro-Windows expliquent qu'un utilisateur normal n'a pas à choisir son wm.

Et ils ont tout à fait raison. Enfin non, c'est pas qu'il n'a pas à le faire, c'est qu'il s'en fout complètement.

Si les logiciels libres s'étaient basés sur ton utilisateur dit "normal", le bureau serait un clone de celui de Windows, il n'y aurait aucune variété, aucune adaptation possible à l'utilisateur.

Et peut-être qu'on aurait un peu plus d'applis correctes.

Par ailleurs, Windows est tout à fait customisable, c'est comme Linux faut juste savoir comment faire. J'ai des copains qui connaissent bien Windows et ce qu'ils me montrent est tout aussi "impressionnant" que ce qu'ont voit sous Linux.

Mais il n'y a que sur ces cas là que je regrette l'inexistence de l'alternative

Ben ça existe toujours, et quelques fois même on s'en sert.

Par contre avec ou sans composants, aucune différence de son coté, c'est du coté du développement de l'application qu'ils apportent beaucoup.

Va faire du couper/coller entre un tableur et un traitement de texte sans composants, pour voir.

Non, ça n'est pas plus simple, même dans les cas que tu cites (cf. mon autre réponse).

Et même si ça l'était, avoir 2 solutions complètement différentes, une pour un problème général et l'autre pour un cas particulier du même problème, complique inutilement les choses.

une autre solution aussi simple existe

Plus simple, vraiment ? Il faut
- trouver où se trouve le programme (si il est installé, ce qui n'est pas forcément garanti)
- connaitre les options qu'il accepte en ligne de commande (qui ne sont pas forcément les mêmes selon les versions)
- savoir comment lui passer les données (fichier temporaire, stdin...) et sous quel format
- savoir quoi faire en cas d'erreur du programme (crash, etc...), et comment detecter ces erreurs

et chacun de ses paramètres est complètement différent d'un programme à l'autre. Un framework de composant unifie tout ça.

l'utilisateur peut préférer cette autre solution

Trouve-moi un utilisateur "normal" (ie pas un geek) qui se préoccupe de se genre de détail, et on en reparle.

Oui, les deux solutions peuvent co-exister, il reste bien quelques fois où un simple fork() fait l'affaire, mais bon... au final pas tant que ça.