> Tout cela est ridicule, la CLI et les interfaces graphiques sont juste plus ou moins pratiquent pour certaines tâches.
Je ne crois pas avoir dit le contraire, par contre d'autres s'échinent à prétendre qu'il faudrait forcer les utilisateurs à la CLI.
> Sous zsh (peut être bash aussi maintenant) :
grep "search string" **/*
1/ ça rate inévitablement si tu as plus de 32k fichiers
2/ ça du grep binaire, ça ne trouvera pas le contenu de tags ou de fichiers zip comme un outil dédié à l'indexation le ferait
Il existe des outils d'indexation en CLI, c'est juste que grep n'est pas bon. Par contre, ça sort des outils standards, et il faut les installer séparément, reproche qui n'était fait qu'aux GUI mais qui est tout aussi applicables à la CLI.
j'ai rencontré le problème sous debian, les autorisations X ne sont pas transmises, plusieurs solutions :
- installer "sux", et l'utiliser à la place de "su"
- dans un term non root, faire "xhost +local:" (éventuels problèmes de sécurité)
- <autre moyen de transmettre les autorisations de façon plus fine> (mais je ne connais pas assez xauth/xhost)
Oh le vote ça veut pas dire grand chose, il suffit que quelqu'un plusse pour qu'un paquet suivent.
L'autre il est pas bien fut'fut' à venir placer *sa* debian comme centre du monde, mais toi tu fais dans l'excès inverse, ça fait juste anti-debian primaire et sur le coup on dirait juste 2 gens qui se lancent des cailloux sans rire.
> Ça en fait des pièges tout ça pour l'utilisateur qui eut remplacer un mot par un autre dans le document qu'il vient de taper.
C'est exactement ce que j'appelais du pinaillage, il y a un paquet de règles qui ne sont pas "logiques" quand on n'est pas familier de cet outil, on en énonce plusieurs, et ils viennent trompetter "ah non on est pas obligé d'utiliser le slash, tu as fait une imprécision sur un malheureux détail parmi une quantité de détails donc obligatoirement c'est moi qui ai raison".
Je vais recopier un message que j'ai posté plus haut
"
Ce qu'il y a de bien avec les interfaces graphiques ordinaires, c'est qu'elle est presque introspective et auto-documentée (pas forcément besoin d'ouvrir une deuxième fenêtre pour le manuel, car les composants contiennent un label souvent explicite, et au pire contiennent une infobulle plus longue). Et la quantité d'interactions possibles relativement limitée (une case c'est "coché/pas coché" contrairement à une entrée texte alors que c'est "-f fichier" ou "-file fichier" ou "--file fichier" ou "--file=fichier" ou juste "fichier" pour une ligne de commande ?) rend aussi l'interface plus facile.
"
OK, un nourrisson ne saurait pas utiliser un GUI de recherche/remplace, mais
1/ comme, je l'ai dit dans mon message collé, les interactions possibles étant limitées et quasi auto-documentées, il est plus facile d'appréhender une nouvelle interface qui sera composée d'éléments similaires/familiers aux autres interfaces
2/ certains composants de GUI ressemblent furieusement à de vrais formulaires papiers, objets qui sont familiers à pas mal de gens, du coup l'analogie avec le réel est bien présente
Heureusement que dans OOo (et MSO également), on peut se contenter de taper le titre, et cliquer sur "titre" pour que la fonte, le gras, etc. se mettent automatiquement...
> 3/ il faut apprendre à connaitre la GUI
Sauf que le GUI est, comme déjà dit, souvent bien plus intuitif, du coup le 3 va être très rapide (alors que sed il faudra passer un moment à jongler entre le man et un shell pour tester si on a bien compris)
> Quand aux caractères que tu cherches ou que tu veux remplacer, c'est juste du bon sens.
Non, c'est juste un défaut de la ligne de commande : utiliser 2 objets de la même nature (les caractères) pour séparer les options, et pour le contenu des options elle-mêmes.
Avec un GUI, tu as 2 champs textes bien séparés sémantiquement.
Et bien non, tu ne peux pas mettre ce que tu veux, tu ne peux pas mettre d'antislash (et pas mal d'autres caractères), d'ailleurs, tant qu'on y est, il faut rajouter la règle que le caractère choisi ne peut pas apparaître dans l'expression à rechercher ou remplacer.
Si tu veux faire du traitement de masse (rechercher/remplacer dans beaucoup de fichiers), il y a des outils plus adaptés que le notepad, et cela restera bien plus simple à utiliser que sh+sed+man+aspirine pour qui n'est ni familier avec le shell ni avec le GUI de rechercher/remplacer.
> … ou les touches du clavier : m. a. n.
Ce qu'il y a de bien avec les interfaces graphiques ordinaires, c'est qu'elle est presque introspective et auto-documentée (pas forcément besoin d'ouvrir une deuxième fenêtre pour le manuel, car les composants contiennent un label souvent explicite, et au pire contiennent une infobulle plus longue). Et la quantité d'interactions possibles relativement limitée (une case c'est "coché/pas coché" contrairement à une entrée texte alors que c'est "-f fichier" ou "-file fichier" ou "--file fichier" ou "--file=fichier" ou juste "fichier" pour une ligne de commande ?) rend aussi l'interface plus facile.
Pas vraiment, tout ce qu'on voit c'est une attaque sans aucune finesse. Alors, c'est facile une fois qu'on t'a rappelé à l'ordre de prétendre "c'était du 42e degré".
Alors que le desktop linux continue de faire des progrès (même si on est loin du compte), il est visiblement de plus en plus "in" de prôner activement et contre toute logique un retour en arrière vers une utilisation exclusive de la ligne de commande, en se montrant toujours plus méprisant envers les utilisateurs d'interface (quelques exemples ici-même : https://linuxfr.org/forums/41/27029.html "le mode graphique c'est pour les lusers", https://linuxfr.org/comments/1026065.html#1026065 "latex c'est plus facile qu'ooo").
Dans la portion même que tu cites de ton article :
"
I will admit NT made my life easier in some respects. I found myself doing less remembering (names of utilities, command arguments, syntax) and more recognizing (solution components associated with check boxes, radio buttons, and pull-downs)
"
L'informatique n'est pas un but mais un outil pour beaucoup de gens. Si la ligne de commande permet de faire énormément, là où la plupart des gens n'auraient besoin de ne faire qu'une tâche particulière et fréquemment, alors un outil simplifié et adapté, qui leur permet de gagner du temps, et d'éviter de s'emmerder avec quelque chose de compliqué, serait certainement mieux pour eux, dans ces cas-là.
Et ce n'est pas une question de complot mondial qui vise à réduire la taille du cerveau des prochaines générations d'humains comme certains ici veulent le faire croire, mais une simple question de bon sens.
Et avec latex, il faut juste apprendre un langage absolument imbittable pour un non-informaticien, utiliser une interface graphique pas la plus adaptée (éditeur de texte VS éditeur de documents), etc.
Je te plains, tu dois vraiment être fatigué à la fin de la journée à avoir piqué une crise à chaque fois que tu as vu le mot "debian". Tu devrais essayer certains médicaments, ton entourage t'en serait certainement reconnaissant (parce que les gens irascibles dans ton genre sont fatigants pour les autres aussi).
Pour UrbanTerror, il n'est pas clair s'il a ou pas violation de la GPL, il utilise la version standalone de Quake 3, qui est sous GPL.
Sinon, il y a aussi War§ow [http://www.warsow.net/], FPS très rapide, où les trickjumps ont la partie belle, dont le moteur est libre, mais pas les données.
Ainsi que WoP [http://worldofpadman.com/], anciennement un mod Quake 3, à l'ambiance cartoon (je n'ai aucune idée sur la licence des données, le moteur est libre).
[^] # Re: The Elements Of Style: UNIX As Literature
Posté par Octabrain . En réponse au journal Au secours! Mark Shuttleworth veut simplifier les logiciels !. Évalué à 0.
Je ne crois pas avoir dit le contraire, par contre d'autres s'échinent à prétendre qu'il faudrait forcer les utilisateurs à la CLI.
[^] # Re: The Elements Of Style: UNIX As Literature
Posté par Octabrain . En réponse au journal Au secours! Mark Shuttleworth veut simplifier les logiciels !. Évalué à 1.
grep "search string" **/*
1/ ça rate inévitablement si tu as plus de 32k fichiers
2/ ça du grep binaire, ça ne trouvera pas le contenu de tags ou de fichiers zip comme un outil dédié à l'indexation le ferait
Il existe des outils d'indexation en CLI, c'est juste que grep n'est pas bon. Par contre, ça sort des outils standards, et il faut les installer séparément, reproche qui n'était fait qu'aux GUI mais qui est tout aussi applicables à la CLI.
# debian ?
Posté par Octabrain . En réponse au message Lancer une appli depuis un terminal après être passé en root. Évalué à 4.
- installer "sux", et l'utiliser à la place de "su"
- dans un term non root, faire "xhost +local:" (éventuels problèmes de sécurité)
- <autre moyen de transmettre les autorisations de façon plus fine> (mais je ne connais pas assez xauth/xhost)
[^] # Re: Le quatrième plus gros contributeur au noyau Linux?
Posté par Octabrain . En réponse à la dépêche Oracle achète Sun. Évalué à 1.
L'autre il est pas bien fut'fut' à venir placer *sa* debian comme centre du monde, mais toi tu fais dans l'excès inverse, ça fait juste anti-debian primaire et sur le coup on dirait juste 2 gens qui se lancent des cailloux sans rire.
# Submergé...
Posté par Octabrain . En réponse au journal Comment je passe de Debian à Mandriva.... Évalué à 10.
[^] # Re: heu ...
Posté par Octabrain . En réponse au journal Logiciels Libres & Developpement durable. Évalué à 1.
[^] # Re: The Elements Of Style: UNIX As Literature
Posté par Octabrain . En réponse au journal Au secours! Mark Shuttleworth veut simplifier les logiciels !. Évalué à 0.
[^] # Re: The Elements Of Style: UNIX As Literature
Posté par Octabrain . En réponse au journal Au secours! Mark Shuttleworth veut simplifier les logiciels !. Évalué à 1.
C'est exactement ce que j'appelais du pinaillage, il y a un paquet de règles qui ne sont pas "logiques" quand on n'est pas familier de cet outil, on en énonce plusieurs, et ils viennent trompetter "ah non on est pas obligé d'utiliser le slash, tu as fait une imprécision sur un malheureux détail parmi une quantité de détails donc obligatoirement c'est moi qui ai raison".
[^] # Re: The Elements Of Style: UNIX As Literature
Posté par Octabrain . En réponse au journal Au secours! Mark Shuttleworth veut simplifier les logiciels !. Évalué à 0.
"
Ce qu'il y a de bien avec les interfaces graphiques ordinaires, c'est qu'elle est presque introspective et auto-documentée (pas forcément besoin d'ouvrir une deuxième fenêtre pour le manuel, car les composants contiennent un label souvent explicite, et au pire contiennent une infobulle plus longue). Et la quantité d'interactions possibles relativement limitée (une case c'est "coché/pas coché" contrairement à une entrée texte alors que c'est "-f fichier" ou "-file fichier" ou "--file fichier" ou "--file=fichier" ou juste "fichier" pour une ligne de commande ?) rend aussi l'interface plus facile.
"
OK, un nourrisson ne saurait pas utiliser un GUI de recherche/remplace, mais
1/ comme, je l'ai dit dans mon message collé, les interactions possibles étant limitées et quasi auto-documentées, il est plus facile d'appréhender une nouvelle interface qui sera composée d'éléments similaires/familiers aux autres interfaces
2/ certains composants de GUI ressemblent furieusement à de vrais formulaires papiers, objets qui sont familiers à pas mal de gens, du coup l'analogie avec le réel est bien présente
[^] # Re: The Elements Of Style: UNIX As Literature
Posté par Octabrain . En réponse au journal Au secours! Mark Shuttleworth veut simplifier les logiciels !. Évalué à 3.
[^] # Re: The Elements Of Style: UNIX As Literature
Posté par Octabrain . En réponse au journal Au secours! Mark Shuttleworth veut simplifier les logiciels !. Évalué à 0.
Sauf que le GUI est, comme déjà dit, souvent bien plus intuitif, du coup le 3 va être très rapide (alors que sed il faudra passer un moment à jongler entre le man et un shell pour tester si on a bien compris)
[^] # Re: The Elements Of Style: UNIX As Literature
Posté par Octabrain . En réponse au journal Au secours! Mark Shuttleworth veut simplifier les logiciels !. Évalué à 2.
Non, c'est juste un défaut de la ligne de commande : utiliser 2 objets de la même nature (les caractères) pour séparer les options, et pour le contenu des options elle-mêmes.
Avec un GUI, tu as 2 champs textes bien séparés sémantiquement.
[^] # Re: The Elements Of Style: UNIX As Literature
Posté par Octabrain . En réponse au journal Au secours! Mark Shuttleworth veut simplifier les logiciels !. Évalué à -1.
[^] # Re: The Elements Of Style: UNIX As Literature
Posté par Octabrain . En réponse au journal Au secours! Mark Shuttleworth veut simplifier les logiciels !. Évalué à -1.
[^] # Re: The Elements Of Style: UNIX As Literature
Posté par Octabrain . En réponse au journal Au secours! Mark Shuttleworth veut simplifier les logiciels !. Évalué à -4.
[^] # Re: The Elements Of Style: UNIX As Literature
Posté par Octabrain . En réponse au journal Au secours! Mark Shuttleworth veut simplifier les logiciels !. Évalué à 6.
Ce qu'il y a de bien avec les interfaces graphiques ordinaires, c'est qu'elle est presque introspective et auto-documentée (pas forcément besoin d'ouvrir une deuxième fenêtre pour le manuel, car les composants contiennent un label souvent explicite, et au pire contiennent une infobulle plus longue). Et la quantité d'interactions possibles relativement limitée (une case c'est "coché/pas coché" contrairement à une entrée texte alors que c'est "-f fichier" ou "-file fichier" ou "--file fichier" ou "--file=fichier" ou juste "fichier" pour une ligne de commande ?) rend aussi l'interface plus facile.
[^] # Re: Le quatrième plus gros contributeur au noyau Linux?
Posté par Octabrain . En réponse à la dépêche Oracle achète Sun. Évalué à 3.
[^] # Re: The Elements Of Style: UNIX As Literature
Posté par Octabrain . En réponse au journal Au secours! Mark Shuttleworth veut simplifier les logiciels !. Évalué à 2.
Dans la portion même que tu cites de ton article :
"
I will admit NT made my life easier in some respects. I found myself doing less remembering (names of utilities, command arguments, syntax) and more recognizing (solution components associated with check boxes, radio buttons, and pull-downs)
"
L'informatique n'est pas un but mais un outil pour beaucoup de gens. Si la ligne de commande permet de faire énormément, là où la plupart des gens n'auraient besoin de ne faire qu'une tâche particulière et fréquemment, alors un outil simplifié et adapté, qui leur permet de gagner du temps, et d'éviter de s'emmerder avec quelque chose de compliqué, serait certainement mieux pour eux, dans ces cas-là.
Et ce n'est pas une question de complot mondial qui vise à réduire la taille du cerveau des prochaines générations d'humains comme certains ici veulent le faire croire, mais une simple question de bon sens.
[^] # Re: Récupération automatique de document...
Posté par Octabrain . En réponse au message Sauvegarde automatique openoffice GROSSE BLAGUE. Évalué à 1.
# "keygen music", la partie visible de l'iceberg
Posté par Octabrain . En réponse au journal Encyclopédie de la ligne de commande et musique de keygens.. Évalué à 4.
[^] # Re: Récupération automatique de document...
Posté par Octabrain . En réponse au message Sauvegarde automatique openoffice GROSSE BLAGUE. Évalué à -1.
[^] # Re: Le quatrième plus gros contributeur au noyau Linux?
Posté par Octabrain . En réponse à la dépêche Oracle achète Sun. Évalué à 2.
[^] # Re: Le quatrième plus gros contributeur au noyau Linux?
Posté par Octabrain . En réponse à la dépêche Oracle achète Sun. Évalué à 2.
# chage(1)
Posté par Octabrain . En réponse au message debian+ forcer les users à changer leur mot de passe. Évalué à 2.
[^] # Re: Mes deux centimes
Posté par Octabrain . En réponse à la dépêche Nexuiz 2.5 est arrivé !. Évalué à 1.
Sinon, il y a aussi War§ow [http://www.warsow.net/], FPS très rapide, où les trickjumps ont la partie belle, dont le moteur est libre, mais pas les données.
Ainsi que WoP [http://worldofpadman.com/], anciennement un mod Quake 3, à l'ambiance cartoon (je n'ai aucune idée sur la licence des données, le moteur est libre).