Ben cela doit faire longtemps que l'auteur de cette partie n'a pas touché un mac car MacOS X peut être décrit de la manière d'une mdk
Personnellement, j'ai "touché" MacOS X il n'y a pas si longtemps et je t'avouerai que je n'ai pas été franchement plus bluffé par la configuration graphique du système que tu ne l'as été par Mandrake...
En y réfléchissant un peu d'ailleurs, je me rends compte que ces stratégies de configuration interface / console ont chacunes leurs avantages et leurs inconvénients mais que l'interface avoue toujours bien vite ses limites...
Que ce soit sous Linux, AIX, True64, Mac OS ou même Windows ont atteint toujours les limites des interfaces et ont fini par mettre les mains "dans les fichiers de configuration" soit parce qu'il est nécessaire d'automatiser certains paramétrages soit parce que ton besoin n'est pas prévu par les zoulies interfaces.
Et à partir de ce moment les problèmes commencent car le côté propriétaire (dans le sens "propre à") et sa base de configuration spécifique se désynchronise peu à peu du standard de configuration que tu as modifié soit par méconnaissance des outils permettant d'assurer cette cohérence soit par abscence d'outils appropriés...
A titre d'exemple, lorsque tu ne parviens pas à une configuration satisfaisante avec les outils graphiques :
° sous AIX, entre smit, VSM, WebSM et la ligne de commande, le gestionnaire d'objets (ODM) et la configuration standard sont facilement incohérentes si on n'y prend garde. Mais ce système reste sans doute pour moi le plus abouti en matière d'interfaces (commandes UNIX étendues, smit fourni les commandes exécutées en ligne si besoin, ensemble des tâches d'administration couvertes, documentation...) même s'il reste très propriétaire et fermé
° sous True64 (Compaq), les interfaces sont beaucoup plus pauvres, en dtksh (ksh93 + "built-in" Motif), partiellement cryptées et impossibilité de fait de savoir ce qui se fait derrière. En plus, ce système est en fin de vie, le support est peu réactif, encore des bugs critiques en V5.1 côté noyau et sa réintégration dans HP/UX fait craindre le pire (AMHA, HP/UX = le pire des Unix, cauchemar de développeur). Seul la gestion des IO est particulièrement performante.
° sous Mac OS, les interfaces sont indéniablement belles mais que dire d'un Unix-like sans superutilisateur "connectable" de base ? En outre les outils de repartitionnement et de déplacement des données sont minimalistes / insuffisants. Exemple: le "disque" système devient à l'étroit, et si je déplaçais les MAJ téléchargées sur une autre partition... Soit mais aucune procédure ne le permet et le faire en glisser-déposer + alias permet juste une chose : rendre foireuses les MAJ ultérieures => retour en arrière et procédure de scan/nettoyage du disque obligatoire. C'est sans doute un problème de maturité mais les principes Mac ne trouvent pas encore tous leurs correspondances côté "Unix".
° sous Windows, tout est interface et pourtant une console existe seulement il est difficile voire impossible 1. de faire coïncider la paramétrage interactif (base de registre + IHM) et des commandes en lignes (commande + fichier de conf) 2. de satisfaire un besoin "évolué" d'administration sans éditer cette fameuse base de registre. Il est d'ailleurs amusant de constater que cette base n'offre ni interface évoluée de consultation/modification ni documentation adaptée alors que cela reste le "rendez-vous de l'administrateur". En outre, la documentation est très disparate et globalement je la qualifierai de pauvre car mal structurée
° sous Linux, je devrai sans doute y refaire un tour mais c'est cette disparité des interfaces qui m'a fait abandonner des distributions comme RedHat, SuSE ou Mandrake car il est bien suffisant de devoir connaitre la configuration "standard" d'un *nix sans avoir en plus à connaitre la sauce propriétaire (toujours dans le sens "propre à") de l'éditeur... et dès que ça ne fonctionne pas de manière satisfaisante, c'est pourtant ce qu'il faut faire (configuration X, réseau, ...)
En résumé, je reproche surtout aux interfaces de configuration,
1. de masquer les paramétrages réalisés effectivement
2; d'être spartiates en comparaison de fichiers de configuration standard et souvent mal documentées
< avis personnel HS >
A mon sens, il y a déjà tant de domaines où la tâche/l'information est pré-digérée que notre activité consiste juste à une attention passive qui interdit toute stimulation et endort notre sens critique.
Doit-on en plus favoriser une informatique vue juste comme un outil qui finira par décourager même les plus curieux ou trouver un équilibre entre flemmardise et passion ?
Linux propose aujourd'hui encore un moyen de remplir une tâche (= outil final) comme une opportunité de s'ouvrir à d'autres domaines (= source de curiosité). Gageons que la logique "one clic" n'aille pas au delà du strict nécessaire : permettre la mise en route d'un système opérationnel minimaliste mais pas plus si affinités ;o))
< / avis personnel HS >
# Interfaces vs Console
Posté par Quzqo . En réponse au journal Sentiments mitigés après une installation de la mdk 9.2. Évalué à 3.
Personnellement, j'ai "touché" MacOS X il n'y a pas si longtemps et je t'avouerai que je n'ai pas été franchement plus bluffé par la configuration graphique du système que tu ne l'as été par Mandrake...
En y réfléchissant un peu d'ailleurs, je me rends compte que ces stratégies de configuration interface / console ont chacunes leurs avantages et leurs inconvénients mais que l'interface avoue toujours bien vite ses limites...
Que ce soit sous Linux, AIX, True64, Mac OS ou même Windows ont atteint toujours les limites des interfaces et ont fini par mettre les mains "dans les fichiers de configuration" soit parce qu'il est nécessaire d'automatiser certains paramétrages soit parce que ton besoin n'est pas prévu par les zoulies interfaces.
Et à partir de ce moment les problèmes commencent car le côté propriétaire (dans le sens "propre à") et sa base de configuration spécifique se désynchronise peu à peu du standard de configuration que tu as modifié soit par méconnaissance des outils permettant d'assurer cette cohérence soit par abscence d'outils appropriés...
A titre d'exemple, lorsque tu ne parviens pas à une configuration satisfaisante avec les outils graphiques :
° sous AIX, entre smit, VSM, WebSM et la ligne de commande, le gestionnaire d'objets (ODM) et la configuration standard sont facilement incohérentes si on n'y prend garde. Mais ce système reste sans doute pour moi le plus abouti en matière d'interfaces (commandes UNIX étendues, smit fourni les commandes exécutées en ligne si besoin, ensemble des tâches d'administration couvertes, documentation...) même s'il reste très propriétaire et fermé
° sous True64 (Compaq), les interfaces sont beaucoup plus pauvres, en dtksh (ksh93 + "built-in" Motif), partiellement cryptées et impossibilité de fait de savoir ce qui se fait derrière. En plus, ce système est en fin de vie, le support est peu réactif, encore des bugs critiques en V5.1 côté noyau et sa réintégration dans HP/UX fait craindre le pire (AMHA, HP/UX = le pire des Unix, cauchemar de développeur). Seul la gestion des IO est particulièrement performante.
° sous Mac OS, les interfaces sont indéniablement belles mais que dire d'un Unix-like sans superutilisateur "connectable" de base ? En outre les outils de repartitionnement et de déplacement des données sont minimalistes / insuffisants. Exemple: le "disque" système devient à l'étroit, et si je déplaçais les MAJ téléchargées sur une autre partition... Soit mais aucune procédure ne le permet et le faire en glisser-déposer + alias permet juste une chose : rendre foireuses les MAJ ultérieures => retour en arrière et procédure de scan/nettoyage du disque obligatoire. C'est sans doute un problème de maturité mais les principes Mac ne trouvent pas encore tous leurs correspondances côté "Unix".
° sous Windows, tout est interface et pourtant une console existe seulement il est difficile voire impossible 1. de faire coïncider la paramétrage interactif (base de registre + IHM) et des commandes en lignes (commande + fichier de conf) 2. de satisfaire un besoin "évolué" d'administration sans éditer cette fameuse base de registre. Il est d'ailleurs amusant de constater que cette base n'offre ni interface évoluée de consultation/modification ni documentation adaptée alors que cela reste le "rendez-vous de l'administrateur". En outre, la documentation est très disparate et globalement je la qualifierai de pauvre car mal structurée
° sous Linux, je devrai sans doute y refaire un tour mais c'est cette disparité des interfaces qui m'a fait abandonner des distributions comme RedHat, SuSE ou Mandrake car il est bien suffisant de devoir connaitre la configuration "standard" d'un *nix sans avoir en plus à connaitre la sauce propriétaire (toujours dans le sens "propre à") de l'éditeur... et dès que ça ne fonctionne pas de manière satisfaisante, c'est pourtant ce qu'il faut faire (configuration X, réseau, ...)
En résumé, je reproche surtout aux interfaces de configuration,
1. de masquer les paramétrages réalisés effectivement
2; d'être spartiates en comparaison de fichiers de configuration standard et souvent mal documentées
< avis personnel HS >
A mon sens, il y a déjà tant de domaines où la tâche/l'information est pré-digérée que notre activité consiste juste à une attention passive qui interdit toute stimulation et endort notre sens critique.
Doit-on en plus favoriser une informatique vue juste comme un outil qui finira par décourager même les plus curieux ou trouver un équilibre entre flemmardise et passion ?
Linux propose aujourd'hui encore un moyen de remplir une tâche (= outil final) comme une opportunité de s'ouvrir à d'autres domaines (= source de curiosité). Gageons que la logique "one clic" n'aille pas au delà du strict nécessaire : permettre la mise en route d'un système opérationnel minimaliste mais pas plus si affinités ;o))
< / avis personnel HS >