C'est on ne peut plus vrai que les assistants graphiques masquent beaucoup le fonctionnement et empèchent la compréhension des problèmes.
De plus ils ont de fait des fonctionnalités limitées : ils ne permettent de faire que ce qu'ils permettent de faire, et non ce que permettent les logiciels sous-jacents. Parfois l'intégration est complète, mais pas toujours. Par exemple essayez de faire une configuration réseau à base de proxy arp pour qu'une machine derrière une autre soit vue comme appartenant totalement au réseau local de l'autre, et tout ça avec au pif des assistants réseaux mandrake, redhat, windows...
Si en utilisant l'interface graphique la chose ne fonctionne pas, on a beaucoup moins de recours pour essayer de l'arranger, pour savoir d'où vient le problème, etc... Pour reprendre l'exemple de la configuration réseau, vous entrez les bonnes valeurs où il faut, vous faites "ok" et ça ne marche pas, et c'est dû à un truc tordu, un matériel bizarre, un bug étrange ou je ne sais quoi, et bien l'interface est démunie et ne permet pas d'arranger la situation, moralité vous êtes bien emmerdés...
Je ne dis pas, loin de là, que les assistants graphiques sont une mauvaise chose, c'est faux, ils sont une bonne chose, l'utilisateur ne veut pas forcément apprendre le fonctionnement de tel logiciel, lire des pages man et faire des tests à tout bout de champ pour configurer des trucs simples. Mais l'intérêt d'avoir des scripts clairs, documentés, compréhensibles et modifiables à la main est aussi on ne peut plus évident : c'est de très loin ce qu'on fait actuellement de mieux pour résoudre un problème que l'interface graphique ne sait pas gérer, ou pour faire des choses peu communes, voire des bidouilles...
A quand un *vrai* mélange des deux ?
En fait j'ai déjà pensé à essayer de faire des interfaces graphiques de config pour la slack, qui laissent les fichiers de conf aussi propres, compréhensibles et documentés qu'actuellement, mais permettent de les modifier/créer de façon plus "user-freindly", mais pas le temps :(
[^] # Re: Hommage
Posté par Yth (Mastodon) . En réponse à la dépêche La slackware 10 est sortie. Évalué à 8.
De plus ils ont de fait des fonctionnalités limitées : ils ne permettent de faire que ce qu'ils permettent de faire, et non ce que permettent les logiciels sous-jacents. Parfois l'intégration est complète, mais pas toujours. Par exemple essayez de faire une configuration réseau à base de proxy arp pour qu'une machine derrière une autre soit vue comme appartenant totalement au réseau local de l'autre, et tout ça avec au pif des assistants réseaux mandrake, redhat, windows...
Si en utilisant l'interface graphique la chose ne fonctionne pas, on a beaucoup moins de recours pour essayer de l'arranger, pour savoir d'où vient le problème, etc... Pour reprendre l'exemple de la configuration réseau, vous entrez les bonnes valeurs où il faut, vous faites "ok" et ça ne marche pas, et c'est dû à un truc tordu, un matériel bizarre, un bug étrange ou je ne sais quoi, et bien l'interface est démunie et ne permet pas d'arranger la situation, moralité vous êtes bien emmerdés...
Je ne dis pas, loin de là, que les assistants graphiques sont une mauvaise chose, c'est faux, ils sont une bonne chose, l'utilisateur ne veut pas forcément apprendre le fonctionnement de tel logiciel, lire des pages man et faire des tests à tout bout de champ pour configurer des trucs simples. Mais l'intérêt d'avoir des scripts clairs, documentés, compréhensibles et modifiables à la main est aussi on ne peut plus évident : c'est de très loin ce qu'on fait actuellement de mieux pour résoudre un problème que l'interface graphique ne sait pas gérer, ou pour faire des choses peu communes, voire des bidouilles...
A quand un *vrai* mélange des deux ?
En fait j'ai déjà pensé à essayer de faire des interfaces graphiques de config pour la slack, qui laissent les fichiers de conf aussi propres, compréhensibles et documentés qu'actuellement, mais permettent de les modifier/créer de façon plus "user-freindly", mais pas le temps :(
Yth.