1/ Evidemment, il y a quelques subtiles différences, ca me parait logique et très sain, sinon windows Me s'appellerait windows 98 troisième édition. Ils ne sont pas parfaits ces softs, et leurs appellations en terme de versionning sont très contestables, ceux qui nous lisent le savent bien.
Ces petites différences qui font perdre du temps sont les résidus inhérents à tout logiciel qui monte en version : quelques trucs changent, il y a des ajouts de fonctionnalités, des bugfix, et de nouveaux bugs qui apparaissent. C'est beau de rêver que tout cela soit transparent pour l'utilisateur mais selon moi très utopique, sur des logiciels de cette taille/importance.
pour windows 98 et Me, ainsi que win2k et XP, je comprends ta frustration quand tu as découvert ces différences, mais avoue quand meme que ca ne représente que bien peu de choses par rapport à l'intégralité des systèmes (surtout quand ces "différences" peuvent être estompées, comme ton exemple d'XP). Un peu de tolérance quand même... non ? Surtout que ca donne du boulot aux hotliners ces petites choses !
2/ Mouarf... ok :)
3/ "Les softs proprios sans saveur", c'est une référence à ce qui se passe dans l'autre monde (abordé en 1/), personnellement je trouve que pour prétendre savoir configurer décemment un programme il faut savoir faire plus que cliquer sur des cases à cocher. En clair, ne pas faire croire aux gens qu'ils pourront faire en deux clics la meme chose que ce qui se fait en une vingtaine de lignes de conf écrites à la mimine, point. Ils doivent être bien conscients qu'ils sont limitésassistés.
Pour reprendre ton exemple : Le fichier de configuration d'apache est le point névralgique de l'application : il me parait évident que celui qui trifouille dedans en shell doit savoir impérativement ce qu'il fait. Sachant que les cliquodromes n'ont pas la même facilité que le cerveau humain pour savoir où modifier/ajouter/supprimer des directives dans les fichiers de conf (et je vois mal cela changer), leurs auteurs choisissent un postulat de départ (soit le cliquodrome éditera un fichier à part qui sera incorporé au fichier principal, soit le cliquodrome gèrera des directives délimitées par des marqueurs spécifiques, le cas que tu cites en exemple). Si tu es à la fois un power user qui édite le fichier à la mimine et quelqu'un qui apprécie le confort d'une interface pour changer des trucs "simples", il faut apprendre par coeur la manière dont ton interface modifiera le fichier pour que cela n'interfère pas avec tes power manips, ou alors bricoler ton propre cliquodrome qui marchera exactement comme tu veux... ou alors te résoudre à ne plus utiliser de cliquodrome dès lors que tu trifouilles à la main.
Le choix, quoi... Tu veux le beurre, l'argent du beurre, la petite monnaie et le popotin de la crémière ? Fort bien, écris donc ce cliquodrome parfait qui déchiffre impeccablement la syntaxe du fichier de conf apache avec toutes ses possibilités / complexités (bonne chance hein). C'est pas impossible mais c'est une énorme masse de taf. Sinon, faut accepter les imperfections d'une interface sensée apporter du confort, au détriment de la souplesse et de la fiabilité.
Je ne te taxe pas d'appel au troll, simplement, as tu déjà réalisé de telles interfaces ? Les contraintes à gérer sont sans doute plus importantes que tu ne l'imagines, une gestion parfaite du fichier de conf "sans le rendre illisible", pour reprendre ton expression, ca nécessiterait une analyse syntaxique du fichier au moins aussi poussée que celle d'apache lui-meme, et le boulot devient rapidement immense.
4/ Je comprends même pas quel rapport ça a avec ce que je raconte : il te sert à quoi ton Vi quand ce que tu écris amoureusement dans ton /etc/fstab est détruit par le cliquodrome qui réécrit le fichier ?
Cf 3/ : soit tu Vi, soit tu cliquodromises, soit tu cliquodromises puis tu Vi. Le comportement du cliquodrome comporte toujours une incertitude dont l'utilisateur doit être conscient. Si des gens croient qu'on fait la meme chose en deux clics qu'en 20 lignes de conf, ils se plantent et je ne les plains pas quand les misères que tu racontes leur arrivent.
ils apprécieraient sans doute aussi d'avoir un environnement semblable partout,
vi c'est pas semblable partout ??? Si tu veux parler de la syntaxe des fichiers de conf et pas de l'éditeur, ce que tu dis ici rentre en contradiction avec ce que tu dis en 3/ ... ?
et un comportement prévisible de l'utilitaire de config par rapport aux fichiers...
Bah il est prévisible qu'il bousille tout, particulièrement ce qui a été modifié à la mimine, car il n'embarque pas un analyseur syntaxique 4 fois plus poussé que celui de l'application elle-meme et ne peut donc gérer intelligemment toutes les subtilités de la syntaxe de la dite conf. Il se borne à gérer celles qui correspondent à un modèle que le programmeur de l'outil a daigné coder, et c'est déjà bcp de taf tout ca.
5/ Mon cerveau, il est fatigué, ne t'en déplaise, de me fader des incohérences complètement gratuites, des fichiers de conf mal faits, etc.
Des exemples ? (gare au(x) troll(s))
Franchement, ça me rappelle les programmeurs C qui expliquent que l'absence de garbage collector est un avantage car... ça te permet d'être plus rigoureux dans ta gestion mémoire. L'immobilisme n'est pas une solution. Ou alors, tu devrais probablement éditer tes fichiers avec ed :-)
Un autre débat, chouette :) Bien tenté, mais je ne suis pas extrêmiste (en tout cas surement pas à ce point là) et j'apprécie le confort d'un garbage collector quand je code. Cependant, à ma connaissance, on a pas encore trouvé le moyen de marier le confort d'un GC et un contrôle fin de la mémoire dans un souci d'optimisation/performance... Et c'est donc de deux maux qu'il faut choisir le moindre, le choix étant au final laissé à l'expert qui est seul capable de s'en passer (du GC).
[^] # Re: \o/
Posté par Cali_Mero . En réponse à la dépêche YaST en GPL. Évalué à 0.
1/ Evidemment, il y a quelques subtiles différences, ca me parait logique et très sain, sinon windows Me s'appellerait windows 98 troisième édition. Ils ne sont pas parfaits ces softs, et leurs appellations en terme de versionning sont très contestables, ceux qui nous lisent le savent bien.
Ces petites différences qui font perdre du temps sont les résidus inhérents à tout logiciel qui monte en version : quelques trucs changent, il y a des ajouts de fonctionnalités, des bugfix, et de nouveaux bugs qui apparaissent. C'est beau de rêver que tout cela soit transparent pour l'utilisateur mais selon moi très utopique, sur des logiciels de cette taille/importance.
pour windows 98 et Me, ainsi que win2k et XP, je comprends ta frustration quand tu as découvert ces différences, mais avoue quand meme que ca ne représente que bien peu de choses par rapport à l'intégralité des systèmes (surtout quand ces "différences" peuvent être estompées, comme ton exemple d'XP). Un peu de tolérance quand même... non ? Surtout que ca donne du boulot aux hotliners ces petites choses !
2/ Mouarf... ok :)
3/ "Les softs proprios sans saveur", c'est une référence à ce qui se passe dans l'autre monde (abordé en 1/), personnellement je trouve que pour prétendre savoir configurer décemment un programme il faut savoir faire plus que cliquer sur des cases à cocher. En clair, ne pas faire croire aux gens qu'ils pourront faire en deux clics la meme chose que ce qui se fait en une vingtaine de lignes de conf écrites à la mimine, point. Ils doivent être bien conscients qu'ils sont limitésassistés.
Pour reprendre ton exemple : Le fichier de configuration d'apache est le point névralgique de l'application : il me parait évident que celui qui trifouille dedans en shell doit savoir impérativement ce qu'il fait. Sachant que les cliquodromes n'ont pas la même facilité que le cerveau humain pour savoir où modifier/ajouter/supprimer des directives dans les fichiers de conf (et je vois mal cela changer), leurs auteurs choisissent un postulat de départ (soit le cliquodrome éditera un fichier à part qui sera incorporé au fichier principal, soit le cliquodrome gèrera des directives délimitées par des marqueurs spécifiques, le cas que tu cites en exemple). Si tu es à la fois un power user qui édite le fichier à la mimine et quelqu'un qui apprécie le confort d'une interface pour changer des trucs "simples", il faut apprendre par coeur la manière dont ton interface modifiera le fichier pour que cela n'interfère pas avec tes power manips, ou alors bricoler ton propre cliquodrome qui marchera exactement comme tu veux... ou alors te résoudre à ne plus utiliser de cliquodrome dès lors que tu trifouilles à la main.
Le choix, quoi... Tu veux le beurre, l'argent du beurre, la petite monnaie et le popotin de la crémière ? Fort bien, écris donc ce cliquodrome parfait qui déchiffre impeccablement la syntaxe du fichier de conf apache avec toutes ses possibilités / complexités (bonne chance hein). C'est pas impossible mais c'est une énorme masse de taf. Sinon, faut accepter les imperfections d'une interface sensée apporter du confort, au détriment de la souplesse et de la fiabilité.
Je ne te taxe pas d'appel au troll, simplement, as tu déjà réalisé de telles interfaces ? Les contraintes à gérer sont sans doute plus importantes que tu ne l'imagines, une gestion parfaite du fichier de conf "sans le rendre illisible", pour reprendre ton expression, ca nécessiterait une analyse syntaxique du fichier au moins aussi poussée que celle d'apache lui-meme, et le boulot devient rapidement immense.
4/ Je comprends même pas quel rapport ça a avec ce que je raconte : il te sert à quoi ton Vi quand ce que tu écris amoureusement dans ton /etc/fstab est détruit par le cliquodrome qui réécrit le fichier ?
Cf 3/ : soit tu Vi, soit tu cliquodromises, soit tu cliquodromises puis tu Vi. Le comportement du cliquodrome comporte toujours une incertitude dont l'utilisateur doit être conscient. Si des gens croient qu'on fait la meme chose en deux clics qu'en 20 lignes de conf, ils se plantent et je ne les plains pas quand les misères que tu racontes leur arrivent.
ils apprécieraient sans doute aussi d'avoir un environnement semblable partout,
vi c'est pas semblable partout ??? Si tu veux parler de la syntaxe des fichiers de conf et pas de l'éditeur, ce que tu dis ici rentre en contradiction avec ce que tu dis en 3/ ... ?
et un comportement prévisible de l'utilitaire de config par rapport aux fichiers...
Bah il est prévisible qu'il bousille tout, particulièrement ce qui a été modifié à la mimine, car il n'embarque pas un analyseur syntaxique 4 fois plus poussé que celui de l'application elle-meme et ne peut donc gérer intelligemment toutes les subtilités de la syntaxe de la dite conf. Il se borne à gérer celles qui correspondent à un modèle que le programmeur de l'outil a daigné coder, et c'est déjà bcp de taf tout ca.
5/ Mon cerveau, il est fatigué, ne t'en déplaise, de me fader des incohérences complètement gratuites, des fichiers de conf mal faits, etc.
Des exemples ? (gare au(x) troll(s))
Franchement, ça me rappelle les programmeurs C qui expliquent que l'absence de garbage collector est un avantage car... ça te permet d'être plus rigoureux dans ta gestion mémoire. L'immobilisme n'est pas une solution. Ou alors, tu devrais probablement éditer tes fichiers avec ed :-)
Un autre débat, chouette :) Bien tenté, mais je ne suis pas extrêmiste (en tout cas surement pas à ce point là) et j'apprécie le confort d'un garbage collector quand je code. Cependant, à ma connaissance, on a pas encore trouvé le moyen de marier le confort d'un GC et un contrôle fin de la mémoire dans un souci d'optimisation/performance... Et c'est donc de deux maux qu'il faut choisir le moindre, le choix étant au final laissé à l'expert qui est seul capable de s'en passer (du GC).