Il n'empêche que certains arguments semblent valables : convivialité pour les novices, efficacité (?).
Aller plus loin
- Making Linux look harder than it is (40 clics)
Clickodrome vs. ligne de commande
7
déc.
2001
Un (long) article paru dans Newsforge relate certains avantages des GUI pour configurer son OS préféré. Gourous de la ligne de commande, princes du vi attention, le cliqueur fou est de retour ;)
Il n'empêche que certains arguments semblent valables : convivialité pour les novices, efficacité (?).
Il n'empêche que certains arguments semblent valables : convivialité pour les novices, efficacité (?).
# Fondons des LGG !
Posté par Jean-Yves B. . Évalué à -10.
Ah, on a déjà des mailing-lists, oubliez-ça.
[-1, stupide déconnade]
# vu sur la tribune
Posté par truelle . Évalué à 10.
Je ne me rappelle plus qui l'a judicieusement souligné, mais je suis tout à fait d'accord avec son argument : "le graphisme pourquoi pas, mais il faut surtout une bonne ergonomie et une aide claire pour le choix des paquetages".
L'exemple de la RedmondLinux est un bon exemple : Une installation à la Windows mais si la souris n'est pas reconnue, il vaut mieux ne pas être novice. De même si l'on souhaite regarder un DVD...
[^] # Re: vu sur la tribune
Posté par Alphonse Oncle . Évalué à 10.
[^] # Re: vu sur la tribune
Posté par Stéphane Salès . Évalué à 0.
je ne comprends pas bien ce que tu veux dire par là ... parles tu de tester de cocher une case dans le gui et de regarder le résultat dans le fichier de conf ?
car j'avoue que cela m'est arrivé notamment lors de mes premières conf de samba de tester swat, et de voir le resultat dans smb.conf, certes cela ne m' a servit que les tout premiers temps, mais à l'époque j'ai trouvé cela bien utile.
Une seule critique, souvent l'utilisation d'un gui vire les commentaires du fichier de conf .
[^] # Re: vu sur la tribune
Posté par Alphonse Oncle . Évalué à 4.
Non je parle simplement de cliquer sur des trucs au hasard en esperant que ca fasse ce que l'on souhaite. A force de tatonnement on y arrive parfois mais ca n'est pas reproductible et on n'en sait pas plus qu'au depart. C'est en gros la demarche que j'appelerais windows de base...
[^] # Re: vu sur la tribune
Posté par Stéphane Salès . Évalué à 10.
genre :
- c'est bon chef ca marche !
- ah, alors qu'est-ce qui allait pas ?
- euh ... c'est bon ca marche
:))
allez paf -1
[^] # Re: vu sur la tribune
Posté par Nicolas Dubois . Évalué à 10.
tu prends ton interface, tu tests à quoi corespond les options de ton interface graphique dans ton fichier de conf. Tu RTFM le minimum possible (parce que t'as jamais le temps). Et seulement après tu comprend réellemen tton fichier de conf...
Je sais c'est pas la meilleure facon de faire, mais pour aborder un fichier smb.conf (qui je l'avoue est pas mal commenté !!) ou pour aborder la config de ton dns, quand tu commences d'un feuille blanche c'est pas facile..
En conclusion, un peu de clickodrome pour ensuite comprendre ce qu'on fait avec vi, c'est mon compromis rapide pour configurer mon système.
# Bug de dacode ?
Posté par Anonyme . Évalué à -6.
On ne peux pas accéder à cette news depuis celle sur KDE 2.2.2 :(
</offtopic>
[^] # Re: Bug de dacode ?
Posté par Netsabes . Évalué à -3.
(perso, je viens de switcher de la news courante vers celle sur KDE puis retour ici, et aucun problème)
[^] # Re: Bug de dacode ?
Posté par Anonyme . Évalué à -4.
[^] # Re: Bug de dacode ?
Posté par Aurélien Jarno (site web personnel) . Évalué à 1.
Moi aussi, je viens rajouter mon grain de sel sur les bugs de DaCode :
La boîte autre à l'air de merder. Des fois, elle à trois jours de retard, et il faut y aller à grand coup de reload pour qu'elle soit à la bonne date
</offtopic>
# GUI + fichiers texte
Posté par Cru Kilu . Évalué à 10.
Dès que le clickodrome ne se base plus sur du ascii human-readable, c'est la me*de : par exemple, essayez de créer 200 comptes NT avec un script, (hahaha !), alors que un compte unix, vous pouvez vous y prendre de toutes les manières et ça marche !
Bon j'ai encore enfoncé une porte ouverte.
[^] # Re: GUI + fichiers texte
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 10.
[^] # GUI + fichiers texte mais didactique et pedaguogique !
Posté par GP Le (site web personnel) . Évalué à 10.
AMHA, un bon outils de conf graphique doit reposer sur des fichiers texte human readable mais surtout etre pedagogique et didactique en explicitant clairement ce qu'il fait. Comme ca, la deuxieme fois qu'il faut etendre un logical volume, on perds pas 3 minutes a arriver au bon menu, mais on tape les commandes en 30 secondes.
DISCLAIMER :
Ceci n'est pas un commentaire de propagande en faveur de AIX !
[^] # Re: GUI + fichiers texte mais didactique et pedaguogique !
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 4.
[^] # Re: GUI + fichiers texte mais didactique et pedaguogique !
Posté par dido . Évalué à -1.
[^] # Re: GUI + fichiers texte
Posté par Stephane Pion . Évalué à 10.
Stéphane
[^] # Re: GUI + fichiers texte
Posté par Benjamin Michotte . Évalué à 4.
Personnelement, je ne saurais pas configurer un sendmail ou un proftpd via un GUI. il me faut le petit vi foo.conf.
Mais c'est vrai que pour les newbies, c'est plus "rassurant" un clickodrome avec un panel pour les options qu'un : "c'est dans un fichier dans /etc"
Mais je crois que tous les dev en sont conscients et que meme si ils font des des beaux trucs en GUI, ca ne fait de toutes manières que d'ecrire dans un fichier texte...
[^] # Re: GUI + fichiers texte
Posté par Pierre Tramo (site web personnel) . Évalué à 0.
Rassure moi, tu ne parle pas du sendmail.cf mais des macros?
[^] # Re: GUI + fichiers texte
Posté par Benjamin Michotte . Évalué à -3.
note que je suis pas certain que le .m4 soit vraiment plus clair ;)
[^] # Re: GUI + fichiers texte
Posté par thomas . Évalué à 9.
je pense qu'une bonne GUI (consise, clair, convivial, qui ecrit des fichiers de conf modifiable a la main), ca serait souvent plus rapide que la ligne de commande; sauf bien sur a modifier un seul caractere/mot dans ton fichier de conf... un exemple ? je veux configurer tel ou tel client mail graphique; bah c'est plus court de repondre a "server smtp:" , "server pop", "port:", etc.... que d'aller lire le man du soft pour savoir quelle est la syntaxe du fichier de conf (c'est "password=xxx" ou "passwd=xxx" qu'il faut ecrire ??).
[^] # Re: GUI + fichiers texte
Posté par Benjamin Michotte . Évalué à 8.
Le seul truc qu'il m'arrive d'utiliser, c'est webmin, et tu ne peux faire que les trucs de bases. Une configuration poussée... laisse tomber...
essaye d'ajouter des options style
PassivePorts 2000 65000
tcpNoDelay on
SocketBindTight off
ou encore pleins d'autres pour proftpd dans webmin... bonne chance.
mais pour une config de base pour un newbie, je dis pas.... mais moi je saurais pas, c'est mon choix, et j'en suis fier ;)
[^] # Re: GUI + fichiers texte
Posté par thomas . Évalué à 5.
[^] # Re: GUI + fichiers texte
Posté par Benjamin Michotte . Évalué à -4.
[^] # Re: GUI + fichiers texte
Posté par thomas . Évalué à 8.
soit un fichier de conf a ecrire avec les informations suivantes : server smtp, server pop, nom user, passwd
==> est-il plus rapide de le faire par GUI ou ligne de commande ? meme si tu tapes tres vite :) tu ne peux pas te passer d'aller jeter un coup d'oeil vers un man ou un INSTALL quelconque pour connaitre le format de ton fichier... avec le GUI, pas la peine.
[^] # Re: GUI + fichiers texte
Posté par Benjamin Michotte . Évalué à 3.
[^] # Re: GUI + fichiers texte
Posté par thomas . Évalué à 5.
- pour configurer ton logiciel superficiellement, rapidement et agreablement : GUI
- pour apprendre quelque chose: man.
et ca ne changera jamais...
[^] # Re: GUI + fichiers texte
Posté par #3588 . Évalué à 8.
==> est-il plus rapide de le faire par GUI ou ligne de commande ? meme si tu tapes tres vite :)
Dans les fichiers de conf il y a quand meme en général des exemples, ou des commentaires très clairs qui évitent si on est pressé de regarder le man... si tu vois ça :
# POP3 format
# pop3:user:password@server
#
# Example
# pop3:bob:m$su><!@pop.coincoin.org
est-ce que la GUI est vraiment beaucoup plus rapide ? Si on ne clique pas et qu'on fait juste "tab" dans la fenetre ça doit revenir au meme.
L'inconvénient des fichiers de conf, c'est surtout quand ils sont vides, n'ont pas de commentaires, ou pas d'exemples. Là oui il faut passer par la doc, ce qui prend plus de temps. Mais parfois, c'est quand meme pas bien violent...
[^] # Re: GUI + fichiers texte
Posté par Infernal Quack (site web personnel) . Évalué à -3.
j'ai jamais tué de chat Monsieur
Peut-être pas toi mais il y une moule qu'à tuer mon chat en voulant tuer un canard sur la tribune :(
hop -1
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: GUI + fichiers texte
Posté par Benjamin Michotte . Évalué à -4.
j'ai changé ma signature juste après pour me donner bonne conscience ;)
hop, -1 (Tm)
[^] # Re: GUI + fichiers texte
Posté par Pierre Tramo (site web personnel) . Évalué à 7.
Le probleme est different alors. Sous nt, pour 200 comptes il te faut un clusters de machines donc plusieurs admins, et donc il y a une division du travail
[^] # Re: GUI + fichiers texte
Posté par jcs (site web personnel) . Évalué à 10.
De toute facon, si l'outil que l'on veut configurer est un peu gros (Apache, Bind...), impossible d'indiquer toutes les options possibles sur une GUI. L'ideal, ce serait des fichiers de config standardises (XML par exemple, pas de troll SVP) qui permette a coup de flex/bison de generer des GUI a la volee (avec explications des options et toutes autres fioritures imaginables).
[^] # Re: GUI + fichiers texte
Posté par pasBill pasGates . Évalué à -7.
T'as jamais vu la command net.exe toi...
[^] # Re: GUI + fichiers texte
Posté par Annah C. Hue (site web personnel) . Évalué à 10.
Vous avez 5 secondes.
[^] # Re: GUI + fichiers texte
Posté par pasBill pasGates . Évalué à 9.
if (InStr(name.Name,"old_")=1) then name.Rename("old_" & name.Name)
WScript.Echo name.Name & "was renamed to " & "old_" & name.Name
next
[^] # Re: GUI + fichiers texte
Posté par pasBill pasGates . Évalué à -9.
Tu remplaces "old_" dans le InStr par "a".
Et c'est du VBScript au fait.
[^] # Re: GUI + fichiers texte
Posté par pas_moi . Évalué à 1.
* 45 minutes moins le temps que WMCoinCoin t'annonce la réponse, ça fait quand même pas mal
* faut rebouter combien de fois pour que les changements aient lieu?
-1, c'est pas beau de frapper un homme à terre
[^] # Re: GUI + fichiers texte
Posté par pasBill pasGates . Évalué à -3.
Je reloade pas la page toutes les 5 secondes, il m'arrive de faire autre chose une fois de temps en temps :+)
[^] # Re: GUI + fichiers texte
Posté par Antoine Beck . Évalué à 4.
[^] # Re: GUI + fichiers texte
Posté par Annah C. Hue (site web personnel) . Évalué à 6.
perl -pi.bak -e "s/^a/old_a/" /etc/passwd
perl -pi.bak -e "s/^a/old_a/" /etc/shadow
5 secondes... pour écrire la ligne de commande.
[^] # Re: GUI + fichiers texte
Posté par pasBill pasGates . Évalué à -7.
Le tiens ne fonctionne pas correctement vu qu'entre le temps ou tu changes /etc/passwd et le temps ou tu changes /etc/shadow il y a un temps qui peut etre non negligeable selon la taille du fichier, le fait que /etc soit en NFS, etc... c'est pas atomique comme operation. Et je t'explique pas le resultat si il un probleme se pose en plein milieu du changement dans /etc/passwd. Tu te retrouves avec shadow et passwd qui ne correspondent plus.
D'autre part mon script ne demande qu'une ligne pour fonctionner sur les utilisateurs d'un domaine. Si tu es sur une machine qui utilise NIS, ben ton script il est dans les choux.
[^] # Re: GUI + fichiers texte
Posté par Guillaume Laurent (site web personnel) . Évalué à 4.
C'est assez rare comme config :-).
J'imagine que ça doit être possible, mais il faut bidouiller ferme vu que le fichier décrivant les partitions à monter (fstab, mtab, le nom change selon les Unix) est dans /etc (si il y a des exceptions je n'en connais pas).
Par ailleurs, dans un cas comme ça le plus probable est que tu sois aussi sous NIS, et donc que tu vas faire ce changement au niveau du serveur NIS lui-même, donc sur un fichier local.
Mais a part ce détail je te crois bien volontier, les possibilités de scriptage de NT sont équivalentes à celles d'Unix pour autant que je puisse en juger (de loin), elles sont justes moins connues.
[^] # Re: GUI + fichiers texte
Posté par pasBill pasGates . Évalué à -4.
Mon exemple ne demande pas qu'on soit sur le domain controller pour ca, tant que tu es logge comme administrateur du domaine sur n'importe quelle machine du reseau ca marche.
[^] # Re: GUI + fichiers texte
Posté par Annah C. Hue (site web personnel) . Évalué à 10.
Mon "script" (en fait c'était juste deux commandes qui montraient la supériorité incontestable d'UNIX...) marche parfaitement, si tu n'es pas capable de l'adapter à _tes_ besoins, tant pis.
Si tu veux un truc atomique,
cp -a /etc/passwd /etc/shadow . && perl -pi.bak -e "s/^a/old_a/" passwd && perl -pi.bak -e "s/^a/old_a/" shadow && cp -a passwd shadow /etc
Quant à NIS, il aurait été surprenant que ce script marche, vu qu'il n'a pas été prévu pour ça (En plus je préfère PAM+ldap si j'ai beaucoup d'utilisateurs sur beaucoup de machines). Et contrairement aux "solutions microsoft", mes machines marchent, avec un minimum d'administration (moint d'une heure/semaine/machine), grâce à l'automatisation rendue possible par la ligne de commandes et à la robustesse incontestable des systèmes debian.
Ton script, ça se voit, n'a pas été fait par un admin mais par un développeur. J'ai jamais vu d'admin NT faire ce genre de truc, mais peut-être que je n'ai vu que des incompétents.
[^] # Re: GUI + fichiers texte
Posté par pasBill pasGates . Évalué à 1.
Et le fait est que pour faire la meme chose sur des machines avec NIS(qui est tres repandu), ben ton script merde et il faut le changer de fond en comble, pas le mien.
D'autre part le jour ou le format de /etc/passwd ou /etc/shadow change, ton script il part a la poubelle, le mien ben je le touche pas, il passe par des fonctions qui s'occuperont de gerer le changement. Et ne me dis pas que ca risque pas d'arriver, /etc/passwd et /etc/shadow ne faisaient qu'un il y a pas si longtemps.
T'as jamais vu un admin NT faire ca ? parce que t'es tombe sur un admin qui connait pas son systeme. Ce script utilises WMI, et WMI c'est fait pour EXACTEMENT ca, administrer des parcs de machines a distance en 2 temps 3 mouvements.
C'est pas parce que tu connais des admins ignares que le systeme est a chier.
[^] # Re: GUI + fichiers texte
Posté par Nqltor 3000 . Évalué à 1.
La différence c'est que sous un système libre, tu n'es pas obligé d'accepter ces changements...
Mais maintenant il y a pire (que les shadows) : les Pluggable Authenfication Modules (PAM) qui permettent justement une abstraction entre l'authentification et les différentes logiciels nécessitant cette dernière. On peut alors avoir ses utilisateurs dans des bases radius, ldap, OTP, passwd-file, smb...
Ensuite différents programmes peuvent utiliser cette authentification : login, apache, ftp,...
Mais c'est clair que maintenant ça devient dur d'écrire un script d'une ligne qui gère tous ces formats en même temps...
[^] # Re: GUI + fichiers texte
Posté par pasBill pasGates . Évalué à -1.
Regardes tous les gens qui sont encore avec une libc5 et un kernel 2.0.36, ils peuvent courir pour utiliser les derniers softs, ils sont obliges de passer en kernel 2.2 ou plus sinon point de salut.
Meme avec un C64 t'es pas oblige d'accepter le changement, mais si tu veux les avancees amenees par ces changements ben tu dois les accepter.
[^] # Re: GUI + fichiers texte
Posté par Gaël Le Mignot . Évalué à 5.
C'est totalement faux. Même si on ne trouve plus de binaires compilés pour la libc5, la très grande majorité des programmes peuvent être compilés avec n'importe quelle libc. C'est encore un avantage de plus du libre.
Quand au noyau 2.0, si tu n'as pas besoin du support de l'USB, du DRI ou du matos plus récent, il n'y aura absolument aucun problème pour faire fonctionner ta distrib avec (même une distrib récente).
D'ailleurs le noyau 2.0 est toujours maintenu...
[^] # Re: GUI + fichiers texte
Posté par pasBill pasGates . Évalué à -6.
Va utiliser tes peripheriques USB avec un 2.0.36(merci pour l'exemple), c'est pas rare pourtant pourtant les periph USB.
En gros ca revient toujours a : si tu veux les dernieres features pas de salut faut upgrader. Si on pouvait faire la meme chose avec un 2.0.36 qu'avec un 2.4 et que les seules differences etaient les perfs/bug corriges ca se saurait je pense.
[^] # Re: GUI + fichiers texte
Posté par Gaël Le Mignot . Évalué à 6.
Est-ce que tu es conscient que la grande majorité des softs (qu'il s'agisse des serveurs comme Apache, ProFTPD, ... ou des porgrammes utilisateurs comme Gnome ou Mozilla) compilent tout aussi bien sous Linux que sous les BSD, voir même d'autres Unix. Alors les compiler avec une autre version du noyau, ça ne pose aucun problème.
Le seul cas où l'utilisation d'un noyau 2.0 peut s'avérer impossible c'est à cause du matériel (USB, AGP, mémoire > 1GB, filesystem > 4GB, SMP, ...). Et même là tu peux toujours backporter (l'AGP et l'USB ont bien été backportés du 2.4 vers le 2.2).
A part si tu changes ton matos, ou si tu veux utiliser des programmes très spécifiques, tu n'as absolument pas besoin d'upgrader quoique ce soit. C'est mieux de le faire (le noyau 2.2 est beaucoup plus efficace que le 2.0 sur pleins de points), mais tu n'es jamais obligé.
[^] # Re: GUI + fichiers texte
Posté par pasBill pasGates . Évalué à -1.
Le probleme c'est: est-ce que qqun a pris la peine de mettre les changements necessaires pour faire tourner le soft sur 2.0.36/libc5/... de la meme maniere que qqun a mis les modifs pour le faire tourner sur BSD.
Le probleme ici c'est que l'enorme majorite des gens tourne sur 2.4/2.2, quasiment plus personne ne tourne sur 2.0.36, donc le nombre de gens pour le faire baisse d'autant. Et toi petit utilisateur qui est dans son coin ben soit tu t'investis a faire ca toi meme si t'en es capable soit tu pleures et t'upgrade.
Quand a backporter des trucs dans un kernel, si l'architecture du kernel s'y prete oui c'est faisable au prix d'un effort loin d'etre negligeable, si entre temps l'architecture du kernel a change, ca peut etre tout simplement impossible, apres tout ils ont probablement change l'architecture du kernel pour une raison, qui pourrait bien etre de permettre de nouvelles choses que l'ancien kernel ne permettait pas.
[^] # Re: GUI + fichiers texte
Posté par pas_moi . Évalué à 8.
99,9% des applications Unix sont indépendantes du système (et encore plus du noyau) sur lequelle elles sont compilées. Vu que tu as l'air d'insister, tu dois avoir un exemple à nous sortir à propos d'une appli qui tourne sur noyau 2.2/2.4 mais pas sur 2.0.36...
Et alors, si quelqu'un utilise un 2.0.36, c'est qu'il l'a installé; et s'il veut installer une nouvelle appli, c'est qu'il sait le faire; et si l'appli ne tourne pas sur le 2.0.36 et ben il installe un noyau plus récent et c'est fini. S'il ne sait pas faire l'une des étapes, il demande à quelqu'un de le faire. Je ne vois pas où est le problème: si c'est du libre, il a tous les outils à sa disposition pour faire évoluer son système.
[^] # Re: GUI + fichiers texte
Posté par pasBill pasGates . Évalué à -3.
Et comme exemple:
http://www.gcom.com/home/linux/lis/kernel.html(...)
Il specifie tres clairement que les kernels 2.0.x ne sont plus maintenus et qu'il faut utiliser une vieille version. Et c'est pas un truc totalement inutile, ca permet d'avoir des streams sous Linux.
[^] # Re: GUI + fichiers texte
Posté par Gaël Le Mignot . Évalué à 1.
> Le fait est que proprio ou pas, personne t'oblige a upgrader, mais si tu veux utiliser les nouvelles features t'as pas le choix tu DOIS le faire dans les 2 cas.
Dans le proprio (MS en tout cas) on t'obluge à upgrader en faisant par exemple des formats de fichiers volontairement incompatible d'une version à l'autre.
Mais surtout on t'oblige à tout upgrader d'un coup. Sous Linux, tu peux changer ton noyau sans changer le reste (enfin, les modutils si, mais c'est logique). Tu peux avoir un XFree 4.1 sur un noyau 2.0 (sans le DRI certes), ... Et tu as la liberté de backporter, ...
[^] # Re: GUI + fichiers texte
Posté par pasBill pasGates . Évalué à -4.
Chez MS, tu me donnes des noms de formats de fichiers incompatibles entre eux ? Office ? Depuis Office 97 ils sont compatibles entre eux, ca fait plus de 4 ans et 3 versions, avant ? ben le format precedent ne permettait pas l'evolution voulue, donc on le change, ils auraient du faire quoi ? bloquer l'evolution du soft a cause du format de fichier ?
Quand a upgrader tout ou rien, ben oui c'est bien beau en theorie car tu peux theoriquement faire exactement ce que tu veux, maintenant combien de personnes profitent de cela ? combien on un 2.0.36 avec XFree 4.1 ? Alors oui pour une minorite c'est un avantage, la plupart des gens s'en balancent, resultat la minorite devrait regarder du cote de Linux/xxxBSD car elle peut pas trouver ca chez Windows, pour la majorite ben il y a pas de differences donc ca n'entre pas en jeu.
[^] # Re: GUI + fichiers texte
Posté par pas_moi . Évalué à 6.
Tout comme mon exemple ne montre pas qu'il est impossible de faire un traitement de texte sous Windows 95, ton exemple ne montre pas qu'il est impossible de de faire des streams sur un noyau 2.0.x... Tu peux toujours sortir autant de vérités que tu veux, ça ne devient jamais des arguments en ta faveur.
Les développeurs de LiS sont clairs: If you are using an older kernel you must use an older LiS version as well. Où vois-tu une obligation de mise à jour? Tant que le logiciel est libre, tu peux le télécharger, le modifier de façon à ce qu'il marche sur ton noyau préféré. Les développeurs n'ont plus envie de se casser le cul sur une architecture précise... libre à toi de prendre la relève si tu le désires.
[^] # Re: GUI + fichiers texte
Posté par pasBill pasGates . Évalué à 0.
T'as Win95 et Word 97, tu veux utiliser Word 2010 ? tu dois passer a Windows XP 2
T'as un kernel 2.0.36 et LiS 4, tu veux utiliser LiS 12 ? tu dois passer a un kernel 2.6
Les problemes sont identiques dans les 2 cas.
[^] # Re: GUI + fichiers texte
Posté par pas_moi . Évalué à 4.
Si tu n'arrives pas à comprendre ça, c'est que la société à fenêtre embauche vraiment n'importe quoi.
[^] # Re: GUI + fichiers texte
Posté par pasBill pasGates . Évalué à 0.
Modifier le code toi-meme c'est un beau choix theorique, en pratique c'est une autre histoire car tu dois en avoir les moyens(= connaitre le kernel intimement, avoir le temps, connaitres le fonctionnement des streams et savoir programmer) et il faut que ce soit faisable ce qui est pas gagne vu que les kernels 2.2/2.4 sont passablement differents des kernels 2.0 ce qui fait que faire des backport n'est pas forcement chose aisee et dans certains cas tout simplement impossible quand tu touches aux limites du vieux kernels(indice: c'est pas pour rien qu'ils ont change l'architecture du kernel).
Resultat: aucune difference entre les 2 dans la realite bien qu'en theorie ce soit different.
[^] # Re: GUI + fichiers texte
Posté par pas_moi . Évalué à 3.
Avec Word, la seule société qui puisse te proposer ce développement, c'est Microsoft; étant donné le choix disponible, je n'ose même pas imaginer le prix.
[^] # Re: GUI + fichiers texte
Posté par Laurent Laborde (site web personnel) . Évalué à 0.
> (et encore plus du noyau) sur lequelle elles sont compilées.
Et pour cause, il n'y a pas de "noyau Unix"
Par contre, les aplis Linux sont de temps en temps
dependante du noyau.
>un exemple à nous sortir à propos d'une appli qui tourne
>sur noyau 2.2/2.4 mais pas sur 2.0.36...
Prenons Gphoto (compilé sans LibUSB pour faire facile)
Il ne compile pas sur mon laptop FreeBSD, il y a fort
a parier qu'il ne compile pas non plus sur un 2.0.
(#include <sys/*.h> etc ....)
> et si l'appli ne tourne pas sur le 2.0.36 et ben
> il installe un noyau plus récent et c'est fini.
Tu as deja essayé ? :)
Cela dit, je prefere passer du 2.0 au 2.4 que de
win95 a XP.
--
Ker2x
Je troooooolll le lundiiiiii,
Je troooooolll le mardiiiiii,
...
[^] # Re: GUI + fichiers texte
Posté par pas_moi . Évalué à 3.
Des applis comme hdparm, modprobe et companie, c'est plutôt normal que ça dépende du noyau...
Pour ce qui est de Gphoto, je ne sais pas d'où vient le problème, mais une telle application doit pouvoir compiler sur n'importe quel Unix (toujours sans tenir compte de l'USB); le script configure sert à ça. Quand je vois des trucs comme povray ou OpenH323 qui tournent sur une palanquée de systèmes différents (pas forcément Unix), c'est que quand même ça doit être possible sur d'autres applications.
Enfin, je ne suis jamais passé d'un 2.0 à un 2.x à la main car c'est généralement plus simple de réinstaller un système propre. Par contre, je suis passé plusieurs fois d'un 2.2 à un 2.4 sous Potato, sans problème...
[^] # Re: GUI + fichiers texte
Posté par Anonyme . Évalué à 5.
Pas si longtemps = approximativement 3 ans ?
« T'as jamais vu un admin NT faire ca ? parce que t'es tombe sur un admin qui connait pas son systeme. Ce script utilises WMI, et WMI c'est fait pour EXACTEMENT ca, administrer des parcs de machines a distance en 2 temps 3 mouvements.
C'est pas parce que tu connais des admins ignares que le systeme est a chier. »
Allons allons, c'est une blague n'est-ce pas ? La politique de Microsoft n'est-elle pas justement de faire croire que ses SE sont facilement accessibles ?
Non parce que s'il faut avoir autant de connaissances pour faire tourner un Win X, qui est quand même réputé pour ses failles/bugs corrigés des mois après et qui n'est pas un logiciel libre (hum, c'est vrai que c'est lié), qu'un GNU/Linux, quelque part, ça fait plus très crédible, le coté « Windows est plus simple à installer et entretenir ».
Enfin la crédibilité de ce point est discutable. Mais ce qui est interessant, c'est que c'est toi qui nous donne les batons pour te battre...
[^] # Re: GUI + fichiers texte
Posté par pasBill pasGates . Évalué à -4.
Pour administrer un petit serveur dans une PME ou t'as pas d'informaticien, Windows c'est le pied car t'as l'option "tout graphique" qui est plus simple pour le non-informaticien, pour les reseaux avec des centaines de machines t'as les group policies, WMI, etc...
Selon l'usage t'as plusieurs types d'outils.
[^] # Re: GUI + fichiers texte
Posté par Anonyme . Évalué à 1.
- sans la facilité, que reste t-il ?
Pas la sécurité, pas la stabilité, pas la liberté.
Sinon, pour tes PME, tu proposes quoi d'autre que l'inféodation aux boutons à cliquer ? J'ai rien contre les boutons à cliquer, mais les utilisateurs peuvent-ils aller réellement plus loin de manière simple, en continuant à utiliser les mêmes outils ?
Y'a t-il un environnement shell type bash, zsh, facile à scripter ?
[^] # Re: GUI + fichiers texte
Posté par pasBill pasGates . Évalué à -2.
Pour les grandes boites il y a les domaines, les group policies, un nombre de softs disponibles enorme, le fait que l'OS server s'integre parfaitement avec les OS desktop alors qu'un serveur Linux ou Solaris ne le pourrait pas, le support direct MS, etc... ici la "bataille" ne se joue plus sur la facilite mais les qualites techniques et economies de cout que l'OS permet de realiser(genre helpdesk/maintenance/...)
Et pour les PME, ben vu qu'ils savent pas ecrire des scripts(c'est pas des informaticiens souvent, juste des secretaires/directeur/... qui s'occupent du petit serveur et ses 8 users une fois de temps en temps) la GUI est ce qu'il leur faut. Pour ce qui est d'ecrire des scripts, ben VBScript est la en standard, et c'est pour ca qu'il est la d'ailleurs.
[^] # Re: GUI + fichiers texte
Posté par Toufou (site web personnel) . Évalué à 1.
Parce que ça fais un moment que tu bosses aux US et que tu as oublié le potentiel délire de l'administration française (ils ont parfois énormément d'humour)... J'ai déjà rencontré le cas des 3 mamies admin, complètement dépassées. Ce n'est pas un cas isolé et je pense que ce n'est pas non plus un cas restreint au fonctionnariat (parce que des chèvres dans les grosses boites privées et à des postes importants, j'en connais aussi).
Pour administrer un petit serveur dans une PME...
De toutes manières, quand c'est du sérieux, les gens sont sous UNIX (ou plus exotique) pour la souplesse, l'intéropérabilité, la perrenité et la fiabilité. Ou alors, ils ont un gros paquets d'emmerdes quotidiens dûs aux bricolages à l'arrache pour compenser le manque d'interopérabilité et de fiabilité.
[^] # Re: GUI + fichiers texte
Posté par shbrol . Évalué à -1.
y a de forte chance que le systeme soit a chier.
[^] # Re: GUI + fichiers texte
Posté par Fabimaru (site web personnel) . Évalué à 0.
Si les utilisateurs de linux sont minoritaires, il y a de forte chance que le systeme soit a chier
pof -1
[^] # Re: GUI + fichiers texte
Posté par shbrol . Évalué à 1.
Bon evidemment, on peut supposer que WMI ne disparaitra jamais, ainsi qu VBscript. Mais affirmer cela montrerait une certaine meconnaissance des pratiques commerciales du monde informatique et d'une certaine compagnie en particulier.
[^] # Re: GUI + fichiers texte
Posté par pasBill pasGates . Évalué à -4.
[^] # Re: GUI + fichiers texte
Posté par shbrol . Évalué à 3.
( Sans mauvaise fois, je conclus que Windows XP est identique a 90% a Windows 3.1)
Et tu n'a pas répondu sur le fond: sachant qu'un changement dans /etc/passwd c'est la meme chose qu'un changement dans WMI, que devient ton script lorsque WMI changera ?
[^] # Re: GUI + fichiers texte
Posté par pasBill pasGates . Évalué à -2.
l'API Win32 ne change pas, c'est le meme depuis le debut sauf cas exceptionnel et c'est ce qui permet de faire tourner les softs Win3.11 encore aujourd'hui. Tout comme la libc ne change pas depuis le debut sauf cas exceptionnel. Si tu n'es pas d'accord, ben prouves tes dires, de mon cote c'est simple: tu ouvres MSDN d'aujourd'hui et MSDN d'il y a plusieurs annees et tu verras que les fonctions d'il y a plusieurs annees sont toujours la et fonctionnent.
Par contre de nouveaux API apparaissent, ce qui ne change rien au fonctionnement des anciens et ca rajoute des fonctionnalites
WMI ne changera pas, donc la question ne se pose pas. Le format dans lequel les comptes sont stockes peut changer lui, mais ce sera invisible pour l'utilisateur tant qu'il passe par WMI.
[^] # Re: GUI + fichiers texte
Posté par #3588 . Évalué à 5.
Ca c'est vrai. En fait c'est meme ce qui explique que sous Windows il n'y a pas d'interface graphique unifiée (contrairement à ce que prétendent beaucoup de fanatiques pro-MS). Sous Windows, on se retrouve tantot avec le style 98, tantot avec le style 3.11, sans aucune logique (boite de sélection de fichiers par exemple).
[^] # Re: GUI + fichiers texte
Posté par Manu (site web personnel) . Évalué à 1.
J'ai faux ?
[^] # Re: GUI + fichiers texte
Posté par Manu (site web personnel) . Évalué à 1.
C'était e_old_rmand que je voulais marquer.
[^] # Re: GUI + fichiers texte
Posté par Flipo . Évalué à 1.
[^] # Re: GUI + fichiers texte
Posté par Fabimaru (site web personnel) . Évalué à 5.
[^] # Re: GUI + fichiers texte
Posté par Pierre Tramo (site web personnel) . Évalué à 5.
net send * salut les moules!!
[^] # Re: GUI + fichiers texte
Posté par woof . Évalué à 1.
mais c'était à l'époque de winpopup (win* !NT && <XP)
j'ai redécouvert les joies de net.exe y'a pas longtemps :)
-1
[^] # Re: GUI + fichiers texte
Posté par VACHOR (site web personnel) . Évalué à 10.
Maintenant, pour toutes les choses un peu avancée de la configuration, les outils graphiques se révèlent en général non fiables, voir erratiques.
Donc on en revient à vi sur le fichier de conf, ou aux commandes manuelles (style "route add default gw ...")
Le clickodrome, ca peut arranger tout le monde à condition d'avoir des outils de meilleure qualité. Pour ce faire, faudrer qu'il y ait une synergie entre les développeurs de ce type d'outils. Actuellement, chacun y va de son utilitaire sans aucun souci de se fondre dans un framework d'outil de configuration...
[^] # Re: GUI + fichiers texte
Posté par mrlem (site web personnel) . Évalué à 10.
Dans la plupart des cas, les developpeurs du monde des LL sont interesses par ce que fait leur prog (de la 3D, du calcul, de la surveillance reseau, etc), et PAS par le design de clickodromes...
Qui plus est, chacun a ses petites preferences. Je ne connais pas beaucoup de monde qui soit expert en developpement d'interface a la fois pour wm, kde ET gnome.
A partir de la on a pas beaucoup de solutions :
- Les equipes de developpeurs se decident ENFIN a accorder du temps pour les Interface Homme / Machine (qui se devoue ?)
- Un environement graphique arrive a s'imposer et rend du coup un peu moins fastidieuse la creation d'une interface qui marchera chez le pingouin lambda qqsoit sont environement.
Personnellement je suis *plutot* pour la soluce 1 dans un premier temps, mais ca veut dire que certaines habitudes vont devoir changer. Il faudrait un peu arreter de devaloriser le developpement d'IHM ;) comme c'est malheureusement trop souvent le cas (IMHO une IHM *bien pensee et faite* represente un vrai travail technique ET fonctionnel).
Voila, c'etait un point de vue (incomplet). A vos Trolls, Prets ...
-- Seb
[^] # Re: GUI + fichiers texte
Posté par Aurélien Jarno (site web personnel) . Évalué à 1.
> Qui plus est, chacun a ses petites preferences. Je ne connais pas beaucoup de monde qui soit expert en developpement d'interface a la fois pour wm,
> kde ET gnome.
Je pense que dans ce cas là, le GUI peut-être fait en GTK, car pratiquement tout le monde à les libs gtk installées sur sa bécane, ce qui n'est pas le cas pour les libs kde et gnome. En tout cas, c'est la solution qui a été choisie par Mandrake (Enfin, quand je l'utilisais, depuis ça a peut-être changé)
[^] # Re: GUI + fichiers texte
Posté par mrlem (site web personnel) . Évalué à 2.
-- Seb
[^] # Re: GUI + fichiers texte
Posté par mrlem (site web personnel) . Évalué à 1.
-- Seb
[^] # Re: GUI + fichiers texte
Posté par Olivier M. . Évalué à 1.
Definition des paramêtres a configurer dans un format bien standard (XML semble pas mal pour ca), et frontends divers selon les envirronements adoptés.
Ainsi un système de configuration homogène d'un desktop à l'autre (même options partout) et au coeur d'un même desktop (tout a la même gueule).
On pourait s'inspirer de libglade par exemple.
[^] # Re: GUI + fichiers texte
Posté par kadreg . Évalué à 2.
Je sais bien que le XML est sensé être "Human Readable", mais non, c'est infame a éditer à la main. Va mettre les doigts dans la configuration d'un weblogic, on en reparlera (non, j'ai pas massacré la mise en page) :
<ApplicationManager Name="mydomain"/>
<CustomRealm
ConfigurationData="server.host=ldapserver.example.com;membership.scope.depth=1;microsoft.membership.
scope=sub;membership.filter=(|(&(memberobject=%M)(objectclass=memberof))(&(groupobject=%M)(objectcla
ss=groupmemberof)));group.dn=ou=Groups, o=ExampleMembershipDir;group.filter=(&(cn=%g)(objectclass=mgroup
));server.principal=cn=Administrator, ou=Members, o=ExampleMembershipDir;user.dn=ou=Members, o=ExampleMember
shipDir;user.filter=(&(cn=%u)(objectclass=member))"
Name="defaultLDAPRealmForMicrosoftSiteServer"
Notes="This is provided as an example. Before enabling this Realm, you must edit the configuration p
arameters as appropriate for your environment."
Password="{3DES}g3bTgZd4s8VAR38Ot5Y2OQ==" RealmClassName="weblogic.security.ldaprealmv2.LDAPRealm"/>
<Application Deployed="true" Name="DefaultWebApp" Path="./config/mydomain/applications">
<WebAppComponent Name="DefaultWebApp" Targets="myserver" URI="DefaultWebApp"/>
</Application>
[^] # Re: GUI + fichiers texte
Posté par #3588 . Évalué à 8.
Si les applis ne le font pas elles-memes, ce n'est pas trop grave puisque ça peut se faire automatiquement, ce n'est pas si cryptique que ça. Sous Emacs, ça doit meme se faire très bien (2 commandes : select all + indent region s'il y a bien un mode xml).
[^] # XML pour les fichiers conf? c'est pas la panacéee non plus
Posté par darkleon (site web personnel) . Évalué à 1.
A la limite je préfére un fichier à la Apache, ou au moins, on a pas a s'ennuyer pour savoir si on a pas oublier de fermer une balise.
Parce qu'avec le XML, selon la taille du fichier, fini l'édition facile avec "vi", ça devient de la programmation, et il faut l'outils de correction syntaxique et de validation pour vérifier la cohérence du fichier XML avant d'essayer de le soumettre à l'appli.
Si on compare un fichier de conf classique et un fichier XML on a les points suivants
- Fichier de conf découpé plus facilement en unités logiques pour du XML, les options d'une même unité sont géographiquement groupée. Contrairement ua fichier conf classique ou on peut mettre les infos n'importe où.
- Par contre, simplicité et plus grande lisibilité d'un fichier conf classique, evite de surcharger le fichier avec trop d'information parasite comme en XML (toutes les balises ouvrantes/fermantes), pas besoin d'un outils de validation.
Quand je vois que tout le monde gueule pour continuer à changer ses fichiers de conf avec "vi", et bien ne soyez pas trop pressé d'avoir un standard XML.
Parce que le XML, c'est typiquement le genre de fichier qu'on génere automatiquement pour pas oublier un détail qui foutrait en l'air la cohérence du XML.
Sans compter que pour parcourir un fichier XML pour rechercher une info, on passe par un "parser" sax ou "dom", ce qui alourdirait inutilement de petites applications par rapport à un simple lecturre ligne à ligne du fichier de conf.
Sans compter la "surcharge" en nombre de caractéres frappés, c'est pas rare d'avoir des fichiers XML qui contiennent plus de balises que d'info a exploiter par ex:
fichier conf apache classique :
# commentaire
toto=valeur1
titi=valeur2
fichier xml le plus simple possible
<?xml version="1.0" standalone="yes"?>
<!-- commentaire -->
<racinne>
<toto>valeur1</toto>
<titi>valeur2</titi>
</racinne>
Et encore je ne gére pas les attributs dans cet exemple.
L'utilisation de fichiers conf XML peut se défendre à conditin d'avoir en standard en ligne de commande les outils pour éditer et valider les XML et les API "sax" et "dom" intégrée à l'OS pour éviter d'avoir 36 libs (1 par appli) qui font la même chose sur le HD.
Autrement, c'est un peu comme écrire un programme C sans un outils de vérification de syntaxe et de l'envoyer directement à un compilateur qui part du principe que le code est déjà testé.
[^] # Re: GUI + fichiers texte
Posté par Guillaume Laurent (site web personnel) . Évalué à 6.
Sous Linux oui, sur n'importe quel autre Unix, non.
En tout cas, c'est la solution qui a été choisie par Mandrake
Ça ne veut rien dire, vu qu'ils contrôlent ce qui est installé :-). Il pourraient aussi bien faire leurs outils sous Qt, Tk ou n'importe quoi d'autre.
[^] # Re: GUI + fichiers texte
Posté par Aurélien Jarno (site web personnel) . Évalué à 10.
tar cvfj etc.tar.bz2 /etc
Sous windows, il faut récupérer les .ini un peu partout sur le disque, exporter la "base de registre" et encore après ça, on est sûr d'en avoir oublié.
Et puis pour la restauration, on peut récupérer dans /etc, juste le fichier pour l'application qui nous interesse. C'est mieux que se ballader dans le fichier de plusieurs Mo de la base de registre.
[^] # Re: GUI + fichiers texte
Posté par Brice Favre (site web personnel) . Évalué à 7.
Si je me souviens bien o'Reilly à sorti un bouquin qui justement te permettais de faire de l'administration NT via des scripts.... perl !!!
Larry Wall est partout.;)
Je ne peux t'en dire plus j'ai briévement survolé le bouquin mais le postulat m'a paru très intéressant. bon après ça partait dans les HKEY bidules chouettes et là j'ai décroché.
Je sais que ça te serviras pas forcément mais voici le lien de cette curosité :
http://www.oreilly.fr/catalogue/winuser.html(...)
# Fortune adaptée ...
Posté par François B. . Évalué à 5.
[^] # Re: Fortune adaptée ...
Posté par Egidius . Évalué à 1.
ça ne veut pas dire résoudre tous les problèmes.
Gérer les exceptions, clairement, ça oui, il faut qu'elle le fasse.
C'est difficile de develloper des ihm car il ne faut pas sacrifier la qualité de l'administration à la représentation.
Je crois qu'on est encore loin du compte quelque soit l'interface graphique.
L'investissement est énorme pour progresser
# Linux for the People (and not People for Linux)
Posté par Teenage . Évalué à 10.
De plus si Linux veux s'ouvrir au grand public il va falloir qu'il offre une installation nickel, et une interface graphique sans faute et avec les même gadgets que Microsoft.
Une secrétaire, mon grand père, une thésarde de psycho se fout complètement de savoir ce qu'est une ligne de commande, ils veulent juste faire des opérations simples avec leur machine. Après s'ils veulent plus s'investir dans le système, Linux ne leur fermera pas la porte au nez en prétextant qu'il faut "acheter un produit tiers pour scheduler des opérations", "acheter des licences pour communiquer en réseaux, ou avoir un compilateur c"...
Linux doit aller vers l'utilisateur et l'inverse suivra tout seul :-)
Et quel'on ne vienne pas me dire que l'on tape plus vite ses premières lettres sous Latex que sous Word...
[^] # Re: Linux for the People (and not People for Linux)
Posté par Anonyme . Évalué à 0.
Libre, c'est un peu plus que « gratuit », non ?
« De plus si Linux veux s'ouvrir au grand public il va falloir qu'il offre une installation nickel, et une interface graphique sans faute »
Une installation nickel .. heu, une installation qui marche ? Ben c'est pas franchement un scoop.
Une interface graphique sans faute : désolé, je ne vois pas ce que ça signifie.
« ils veulent juste faire des opérations simples avec leur machine »
Tu t'es décidé à enfoncer les portes-ouvertes ?
« Et quel'on ne vienne pas me dire que l'on tape plus vite ses premières lettres sous Latex que sous Word... »
Evidemment, LaTeX demande un apprentissage. Comme tout e qui demande apprentissage demande du temps. Donc évidemment, c'est pas aux premières lettres que ça se voit.
Après, tu parles de thésarde en psycho, je suis à peu près certain que si elle veut pouvoir faire sa thèse avec Word, elle passera à peu près autant de temps qu'elle aurait passé à apprendre LaTeX. Parce que les bibliographies, notes de bas de page, c'est pas si pratique que ça sous Word. Et pire, les fichiers Word qui font plusieurs dizaines des Mo, forcement c'est moins confortable.
Bref.
Cela dit, je pense que ce qui faut developper, c'est des frontaux pour LaTeX. Evidemment. Mais je ne pense pas que Word soit l'exemple à suivre.
Mais là encore, c'est pas un scoop.
[^] # Re: Linux for the People (and not People for Linux)
Posté par Fabimaru (site web personnel) . Évalué à 2.
heureusement que bash/cygwin me permettent de survivre au boulot
quelques language simple (et gratuis) de programation
Ben python, perl... C'est vrai que c'est pas livre de base comme sous linux (arg, vbscript qui pue !)
# Plus de simplicité !
Posté par Noe Reboul . Évalué à 1.
Ca doit faire une bonne 15aines d'années que j'utilise l'outil info et ce qui m'étonne c'est que c'est encore asser complexe : perso j'm'en tapes un peu d'avoir un GUI ou un fichier de conf a editer ce qui me saoule c'est justement de le faire. Quand je prends un telephone portable je m'amuse pas pendant 15 minutes a le configurer : je l'allume et je m'en sert. A mon avis le truc interressant c'est ca : on devrait pas avoir a passer 15 minutes a configurer tel ou tel truc, ca devrait etre transparant, automatique. tu branches, t'utilises. Toute la partie de conf ca sert a rien : c'est une perte de temps. C'est comme pour un cd-rom : tu le mets dans le lecteur tu l'utilises (pour mon lecteur de salon c'est comme ca que ca se passe pour mes CD audios ... sans parler des DVD la c'est aussi très simple avec un lecteur de salon : j'suis pas obligé de télécharger tel soft configurer tel bidule et tout et tout ...) ... tu devrais pas à avoir a taper mount et tout le tralala (alors oui je peux foutre un auto-mount mais ca réponds pas a la question ... à mon avis c'est mal pensé à la base l'automount c'est un paliatif)
'fin voilà ... plus j'utilise les ordis plus je me dis que c'est débile comme truc dans le fond ...
[^] # Re: Plus de simplicité !
Posté par Aurélien Jarno (site web personnel) . Évalué à 1.
En gros, pour configurer proftpd, apache ou sendmail, tu penses à ce que tu veux obtenir et ça se configure tout seul ! Désolé, mais on a pas encore inventé la transmission de pensée avec les ordinateurs.
</mode>
Ca peut pas se configurer totalement tout seul, il faut bien que tu dises un peu à ton PC ce que tu veux faire, il peut pas l'inventer
[^] # Re: Plus de simplicité !
Posté par Noe Reboul . Évalué à 5.
ouais
</mode>
évidement non ... mais ca sert a quoi de foutre un serveur FTP ? ce que tu veux c'est quoi ? foutre un serveur FTP à la con ou partager des documents ?
Il faut reprendre le problème à la base. Ta facon de réfléchir ne répond pas au problème. Le problème dans ce cas est : "je veux partager des documents" A ca il faut répondre quelle est la facon la plus simple de partager des documents sans etre obligé de passer 15 minutes a configurer un serveur à la con. Un ordinateur, et un système d'exploitation, devraient etre pensés dans ce sens ... moi perso je trouve ca super pas interressant de configurer un serveur FTP. Il devrai donc y avoir un système simple qui permette d'echanger des fichiers sans etre obligé de mettre en place un serveur pendant 3 heures. Sur Mac et sur Win ca existe : tu peux partager des documents en deux clics de souris ... mais meme à la limite c'est meme pas encore asser poussé comme idée : j'pense qu'il y a moyen de faire encore plus simple ...
Enfin après si toi ca te fait triper de configurer des serveurs a tout va, tant mieux ... mais AMHA c'est pas ca l'avenir de l'info ... l'avenir c'est l'ordi ou t'as rien a configurer et tout ce fait tout seul et c'est pas un truc de débile mental ... c'est grave possible.
[^] # Re: Plus de simplicité !
Posté par Prosper . Évalué à 3.
8.2 je crois (en tout cas c est deja dans cooker)
tu peux partager les repertoires de ton home
en 1 click (paratge samba et/ou nfs)
[^] # Re: Plus de simplicité !
Posté par GCN (site web personnel) . Évalué à 1.
Un exemple tout con, peu importe le logiciel que tu utilises pour ça mais... Tu as ton MUA tout joli tout beau. Tu es abonné chez Wanadoo, mais le mec qui a développé ça est un type qui habite les states et qui est abonné chez un ISP américain (normal quoi :).
Là le gars il a développé sont soft pour ne pas avoir de fichier de conf, ça sert à rien. Il t'a fournit un truc pret à l'emploi, tant pis pour toi si t'es chez Wanadoo (ça marche pas puisque le soft est "paramétré" pour l'isp américain)...
Et si tu as la chance d'être chez le même ISP que le développeur du soft, t'as du bol, tu recevras ses mails et enverra des mails sous son identité (pareil, il aura développé ça pour lui).
Et qd je parle de fichier de conf, je ne parle même pas de config en ligne de commande ou avec une GUI (c qd même le sujet de cette news).
Je prends un exemple con, mais ce que tu décris est quelquepart un peu stupide. L'exemple ici parle d'un MUA, mais on peut le transposer à une infinité de softs différents...
[^] # Re: Plus de simplicité !
Posté par Noe Reboul . Évalué à 3.
1) le telephone mobile : qu'il soit fait par n'importe quelle boite je n'ai pas besoin de 15 minutes de configuration pour m'en servir ... qu'il soit fabriqué en allemagne par un japonais ca je m'en branle total. Je le branche je m'en sert.
2) le courier papier : aucune configuration, aucun apprentissage particulier : tout marche tres simplement ... rien a branler du fait que l'adresse ai été écrite par un russe ou alors que je passe par la poste suédoise : ca fonctione et c'est ce qu'on lui demande.
La phase config d'un ordi ne devrait pas exister. Ca sert a rien. C'est comme si, quand tu achetais une bagnole, t'étais obligé de regler le carbu et tout le tralala ...
[^] # Re: Plus de simplicité !
Posté par PLuG . Évalué à 5.
Ton téléphone portable, y a un type qui s'est emmerdé a configurer la carte sim que tu as placé dedans pour qu'il marche. Il a donc fait la config pour toi (moyennant finances).
Le courier papier, c'est encore pire: il faut enseigner a chaque utilisateur comment acheter un timbre, le coller, trouver l'adresse et l'ecrire en pensant a ce qu'elle soit lisible dans le pays de destination (attention aux 1 vers les states par exemple, qui sont pris pour des 7 si pas écris juste avec un trait vertical).
Quand a la voiture, c'est comme ton téléphone, tu ne regle pas le carbu parceque quelqu'un d'autre l'a fait.
Je te propose donc une solution a TON probleme: pour ne pas t'embeter avec la config de ta machine, fait comme avec ta bagnole: prend un contrat de maintenance chez un spécialiste.
# AMHA La question n'est pas vraiment là
Posté par Le_Maudit Aime . Évalué à 10.
Et le marché en question, c'est ici le marché du travail. Dire qu'il y a eu pénurie d'informaticiens ces dernières années n'est peut être pas tout à fait vrai. Mais une chose est sûre, les entreprises ne voulaient pas payer le VRAI prix pour cela.
Donc de nombreuses personnes à priori extérieures à l'informatique (biologie, physique etc.) ont été formées sur le tas. Et pour ces personnes là, le clickodrome c'est rassurant, parce qu'elles ne comprennent pas toujours ce qu'elles font.
Comme de plus, une solution médiocre mais vite développée est mieux valorisée que le contraire, il est naturel que en plus, ces méthodes faisant flores auprès des directions, c'est normal que ces dernières aient décrétées que c'était "has been", la ligne de commande (moi sous unix je suis très "sbin" (c: )
De plus, tous les outils clickodromesques existent déjà sous unix pour administrer une bécane. C'est juste un besoin de présentation différent.
P.S : Comparez l'attrait entre la photo d'écran d'un shell et celle de l'administrateur des utilisateurs sur des transparents destinés à une direction.
P.S 2 : Quand votre directeur passe dans votre dos et que :
- vous tapez des commandes ésotériques, vous êtes un hacker chevelu dont on se débarssera quand on en aura plus besoin (vous faites tâche mon pauvre ami),
- si vous cliquez comme un fou sur quelque chose qui ressemble à un tableau de bord, alors là vous êtes un chef de projet prometteur et qui manage comme un dieu ses équipes.
[^] # Re: AMHA La question n'est pas vraiment là
Posté par Marc . Évalué à 10.
La ligne de commande c'est la base de l'automatisation de l'administration.
Configurer à coup de clic c'est le travail manuel de l'industrie du 19ème siècle. Aujourd'hui la main d'oeuvre est cher, on préfère automatiser.
le script est à l'informatique ce que l'automate programmable est à l'industrie.
Vous voulez que je fasse tout à la main, chef ?
# IMPORTANT Trollerie !!!! par Code34
Posté par Code34 (site web personnel) . Évalué à 2.
Pour une fois, je vais essayer de me montrer constructif ... Les interfaces graphiques pour faire de la configuration, ça reste encore sommaire ;) Je crois que cela ne peut convenir qu aux administrateurs windows.
Mais aucune utilisateur linux ne pourra trouver son compte entierrement avec des interfaces graphiques.
Voila les principaux inconvénients des outils graphiques :
- ils occultent tout les fichiers de configurations, la nature des modifications à l administrateur, et au besoin en crée de nouveaux fichiers de configurations [..]
- ils standardisent les configurations limitant grandement les possibilités meme des commandes, et provoquant des conflits lorsqu une configuration complexe est déjà mise en place.
Voila le processus concretement d un système qui a mon sens serait performant. Il integrerait deux modes, standard, et expert. Je décris le mode expert en allant au plus vite [..]
L administrateur face à sa belle interface graphique opère une creation, ou une modification peu importe.
Il rentre alors dans un mode édition , ou l interface désigne le fichier de conf affecté, et lui ouvre le fichier. On lui montre alors la ligne existante, et on lui propose de la remplacer par une ligne conseillée, ou de configurer lui meme sa ligne ;)
En plus de ça l application conserve les modifications, ce qui peut permettre de gerer un historique [..]
Qu en pensez vous ? La balle est dans votre camps !
[^] # Re: IMPORTANT Trollerie !!!! par Code34
Posté par lorill (site web personnel) . Évalué à 0.
tu nous le code ?
[^] # Re: IMPORTANT Trollerie !!!! par Code34
Posté par gndl (site web personnel) . Évalué à 3.
Un exemple tout simple dans cet espris là, est l'utilitaire de recherche de fichier de gnome qui permet d'éditer la ligne de commande générée grace à l'interface graphique. Ca présente 2 avantages: un aspet pédagogique pour les débutants et la possibilité pour des personnes plus confirmées d'affiner la recherche.
Ce serais interescent d'élargir ce concepte à d'autre logiciels. Par exemple les gestionnaires de fichier devraient pouvoir éditer toutes les commandes correspondante aux actions effectuées. Ils devraient d'ailleurs permetre d'effectuer tous ce qu'il est possibles d'effectuer par ligne de commande en matière de gestion de fichier (recherche, manipulation, archivage, compression, modification des attributs de façon récursive( ça Konqueror sait le faire:o)...). Ca donnerais une meilleur idée de la puissance du système au personnes qui testent Linux.
La ligne de commande est plus rapide dans certain cas et la GUI est plus rapide dans d'autres. Utilisons le meilleur des 2. Le bureau pourrait également offrir cette dualité. Ce serait puissant de pouvoir taper des commandes dans le bureau sans avoir à ouvrir le fenêtre Xterm. Le texte s'afficherait en vidéo inverse par rapport au bureau et aux applications en fond de plan avec éventuellement un effet d'ombre porté pour épater le gogo (c'est important dans un contexte de conquète du marché :o) et pour bien détacher le texte de la ligne de commande de l'application sur laquel il vient se superposer. Un raccourcis clavier permetrait de rendre provisoirement le focus à la fenêtre root pour qu'elle puisse recevoire les évenements clavier (la difficultée pour un tel programme serait de recevoire les évenements claviers destinés à la fenêtre root et je ne sais pas si on peut écrire dans le buffer vidéo de façon à ce-que le texte puisse recouvrir plusieurs fenêtres d'application).
L'interface graphique semble souvant être considérée comme un rempare à la maîtrise du systême et où les utilisateurs cliquent sans trop savoir ce qu'ils font, c'est vrais que c'est souvant le cas avec windows mais aucunes loi n'oblige à se plier à ces règles, ne soyons pas prisonnié des conceptes de p'tit mou. Notre but n'est pas de faire aussi bien que windows, notre but est de faire beaucoup mieux.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.