Clickodrome vs. ligne de commande

Posté par  (site Web personnel) . Modéré par Amaury.
Étiquettes :
0
7
déc.
2001
Presse
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é (?).

Aller plus loin

  • # Fondons des LGG !

    Posté par  . Évalué à -10.

    Bon, puisque les fans de CLI vont se faire virer des LUGs pour cause d'inutilité, je propose la fondation de Linux Gurus Groups un peu partout en France et ailleurs ...
    Ah, on a déjà des mailing-lists, oubliez-ça.

    [-1, stupide déconnade]
  • # vu sur la tribune

    Posté par  . Évalué à 10.

    Ce sujet a fait l'objet d'une sérieuse discussion hier sur la tribune. Si si, c'est vrai!
    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  . Évalué à 10.

      La config graphique (base sur des fichiers de conf texte pour etre tranquille) c'est bien mais il ne faut pas que ce soit le pretexte pour faire des trucs au hasard systematiquement. Il faut que ce soit bien clair pour comprendre ce que l'on fait et pas juste du tatonnement/clic au hasard comme on le retrouve trop souvent.
      • [^] # Re: vu sur la tribune

        Posté par  . Évalué à 0.

        "il ne faut pas que ce soit le pretexte pour faire des trucs au hasard systematiquement"
        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  . Évalué à 4.

          "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 ?"

          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  . Évalué à 10.

            oki d'accord
            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  . Évalué à 10.

        la config graphique m'a toujours servie à comprendre "comment marche" le fichier de conf....

        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  . Évalué à -6.

    <Offtopic content="bug de dacode ?">
    On ne peux pas accéder à cette news depuis celle sur KDE 2.2.2 :(
    </offtopic>
    • [^] # Re: Bug de dacode ?

      Posté par  . Évalué à -3.

      Quelle est l'url dans le lien depuis la news sur KDE 2.2 ?
      (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  . Évalué à -4.

        Fausse alerte, c'était le cache de la page KDE 2.2.2 qui était pas à jour et qui n'affichait pas le lien...
    • [^] # Re: Bug de dacode ?

      Posté par  (site Web personnel) . Évalué à 1.

      <Offtopic content="bug de dacode ?">

      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  . Évalué à 10.

    Le clickodrome, c'est un plus si en dessous il y a des fichiers de config en ascii. On peut alors configurer indifférement par GUI, par script ou à coup de vi selon les goûts.

    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  (site Web personnel) . Évalué à 10.

      Tout à fait d'accord avec toi. Je pense que quand on sait ce que l'interface graphique fait, c'est mieux. En clair, il vaut mieux savoir comment configurer son système à la mano et après, pourquoi pas, utiliser des interfaces graphiques. D'ailleurs, lorsque j'étais formateur Oracle (pas de rires, svp), un gentil étudiant (client) faisait toutes les manips par l'Enterprise manager, du coup, là où les exos prenaient dix minutes, lui les torchaient en 5 sans avoir compris ce qu'il avait fait. Il a fallu que je lui explique qu'avant d'utiliser aveuglément ces outils, il valait mieux connaître un minimum sur l'architecture et sur les commandes SQL de création de base etc... Ceci dit, c'est parfois sympa d'avoir des outils de conf graphique.
      • [^] # GUI + fichiers texte mais didactique et pedaguogique !

        Posté par  (site Web personnel) . Évalué à 10.

        C'est en ca, que j'aime bien 'smitty' l'outils d'administration de AIX. C'est l'un des rares que je connais (avec linuxconf) qui te permet d'acceder a la sequence des commandes qu'il a passe. C'est comme ca que j'ai appris AIX.
        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

      Posté par  . Évalué à 10.

      Exact. Quelques fois, la configuration d'un composant peut être assez ardue. Un "clickodrome" peut alors être d'une aide précieuse. Mais dès que l'on commence à maitriser la conf du composant, je trouve que l'efficacité passe par la ligne de commande. Un pt'it coup de vim est quand même plus rapide qu'une avalanche de clicks.

      Stéphane
    • [^] # Re: GUI + fichiers texte

      Posté par  . Évalué à 4.

      je suis tout à fait d'accord avec toi.
      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  (site Web personnel) . Évalué à 0.

        > je ne saurais pas configurer un sendmail ou un proftpd via un GUI.

        Rassure moi, tu ne parle pas du sendmail.cf mais des macros?
        • [^] # Re: GUI + fichiers texte

          Posté par  . Évalué à -3.

          ben justement, la première fois que j'ai configuré sendmail, j'avais pas (l|v)u le sendmail.m4 et je me suis tapé la config dans le .cf ....

          note que je suis pas certain que le .m4 soit vraiment plus clair ;)
      • [^] # Re: GUI + fichiers texte

        Posté par  . Évalué à 9.

        tu ne saurais pas utiliser un GUI pour configurer sendmail ? meme si cet outil est un bon outil ? tu n'as pas de souris ou quoi ?

        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  . Évalué à 8.

          il faudrait déjà un trèèèèèès bon outil, à la limite, fait par ceux qui font le logiciel, pour que _TOUTES_ les possibilités soient présentes dans cette GUI.

          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  . Évalué à 5.

            c'est clair. je partage tout a fait ton avis. rien ne remplacera l'exhaustivite d'une config manuelle. mais toujours en reprenant mon example, la configuration de ton compte mail chez ton provider, c'est comme meme plus facile/rapide par un GUI.
            • [^] # Re: GUI + fichiers texte

              Posté par  . Évalué à -4.

              ben meme dans ce cas-la, je vais encore dire non... mon mail passe par sendmail, procmail, fetchmail et mutt... donc, rien de franchement graphique ;)
              • [^] # Re: GUI + fichiers texte

                Posté par  . Évalué à 8.

                compare ce qui est comparable:
                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  . Évalué à 3.

                  la, je dis pas le contraire... mais est-ce que tu apprends quelque chose en cliquant ? et en lisant le man ?
                  • [^] # Re: GUI + fichiers texte

                    Posté par  . Évalué à 5.

                    non, tu n'apprends rien.
                    - 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  . É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 :)


                  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  (site Web personnel) . Évalué à -3.

                Mais pourquoi as tu fais un jcoincoin en swing alors ??? :)

                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  . Évalué à -4.

                  si si, c'est moi qui l'ai tué...

                  j'ai changé ma signature juste après pour me donner bonne conscience ;)

                  hop, -1 (Tm)
    • [^] # Re: GUI + fichiers texte

      Posté par  (site Web personnel) . Évalué à 7.

      > 200 comptes NT

      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  (site Web personnel) . Évalué à 10.

      Le clickodrome, c'est un plus si en dessous il y a des fichiers de config en ascii
      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  . Évalué à -7.

      Creer 200 comptes NT avec un script ?

      T'as jamais vu la command net.exe toi...
      • [^] # Re: GUI + fichiers texte

        Posté par  (site Web personnel) . Évalué à 10.

        Maintenant je veux que tous les comptes qui commencent par "a"XXX soient renommés en "old_a"XXX.

        Vous avez 5 secondes.
        • [^] # Re: GUI + fichiers texte

          Posté par  . Évalué à 9.

          for each name in GetObject("winmgmts:").ExecQuery("Select * from Win32_UserAccount")
          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  . Évalué à -9.

            Tiens en passant j'ai fait une erreur :+)

            Tu remplaces "old_" dans le InStr par "a".

            Et c'est du VBScript au fait.
            • [^] # Re: GUI + fichiers texte

              Posté par  . Évalué à 1.

              * il faut quoi comme shell pour exécuter du VBScript?

              * 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  . Évalué à -3.

                Il faut Win2000 ou XP et rien d'autre

                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  . Évalué à 4.

                  Il aura fallut attendre les version les + graphiques des os de M$ pour avoir la possibilité de scripter l'administration réseau ?
          • [^] # Re: GUI + fichiers texte

            Posté par  (site Web personnel) . Évalué à 6.

            Quand on dit que windows est convivial, je dis qu'il y a 6 lettres de trop.

            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  . Évalué à -7.

              Oui et il y en a un des deux qui marche tout le temps et pas l'autre.

              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  (site Web personnel) . Évalué à 4.

                > le fait que /etc soit en NFS

                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  . Évalué à -4.

                  Ben tu es donc oblige de te logger sur le serveur NIS pour faire le changement, t'as donc le choix entre faire ca manuellement ou mettre la procedure de login dans le script ce qui est un risque enorme de securite(que ce soit en mettant le password ou en utilisant .rhosts).

                  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  (site Web personnel) . Évalué à 10.

                /etc en NFS ? Ne viens jamais administrer mes machines, JAMAIS.

                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  . Évalué à 1.

                  Ton script ne marche pas parfaitement vu que si une merde arrive pendant que tu updates /etc/passwd ton /etc/shadow n'est plus vailde. Ta deuxieme version est effectivement bien mieux.

                  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  . Évalué à 1.

                    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.

                    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  . Évalué à -1.

                      C'est vrai t'es pas oblige, tout comme personne t'obliges a passer de NT 4 a Win2000, mais quand tu vois que tel soft ne fonctionne plus sans les shadow passwords, que tel soft veut PAM, etc... ben tu n'as plus vraiment le choix sauf si tu n'upgrades plus et que tu n'installes aucun nouveau soft.

                      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  . Évalué à 5.

                        > 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.

                        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  . Évalué à -6.

                          Oui, tu prends donc les dernieres sources du soft, et tu te rends compte qu'il utilise des features non-presentes dans ton kernel 2.0.36 et dans la libc5 car le dev lui il utilise un kernel 2.4, la derniere libc et il est sympa il s'arrange pour que ca tourne quand meme sur les 2.2 mais il s'est dit qu'il fallait mettre une barre quelque part donc pas de support pour 2.0.36 et autres vieilleries.

                          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  . Évalué à 6.

                            > Oui, tu prends donc les dernieres sources du soft, et tu te rends compte qu'il utilise des features non-presentes dans ton kernel 2.0.36 et dans la libc5

                            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  . Évalué à -1.

                              Ben que ca compile sous 5 Unix differents ca veut rien dire car le probleme n'est pas la.
                              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  . Évalué à 8.

                                Haaa, on retrouve le pasBill de l'ancien temps: celui qui a toujours raison, même quand il débite les pires conneries...

                                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  . Évalué à -3.

                                  Oui il doit installer un nouveau kernel, donc il upgrade !!! 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.

                                  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  . Évalué à 1.

                                    Le 2.0 n'est plus maintenu ? Ah bon ? Faut peut-être vérifier avant de sortir des mensonges... Va voir sur ftp://ftp.kernel.org/pub/linux/kernel/v2.0/testing/(...) et tu verras un 2.0.40pre3 datant du 26 novembre 2001.

                                    > 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  . Évalué à -4.

                                      Je parles de LiS qui n'est plus maintenu pour les kernels 2.0.x, pas du kernel en lui meme, faut peut-etre lire la page avant de me sauter au cou.

                                      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  . Évalué à 6.

                                    C'est bien, tu as sorti ton exemple... A mon tour: le dernier Microsoft Word (je ne connais pas son petit nom) comporte sur sa boite le petit logo «compatible Windows» alors que sur les spec il est précisé que ça ne marche pas sur Windows 95!!

                                    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  . Évalué à 0.

                                      C'est 2 problemes identiques.

                                      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  . Évalué à 4.

                                        Mais t'es vraiment borné... Avec Word tu n'as pas le choix, tu dois mettre ton système à jour. Mais avec LiS tu as le choix soit de mettre ton système/noyau à jour, soit de modifier le code pour que ça marche sur ton système. Je ne sais pas comment te le dire pour que tu comprennes que c'est la différence majeur entre le libre et le proprio.

                                        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  . Évalué à 0.

                                          Non je suis pas borne, je suis un developpeur et je fais la difference entre la theorie et la pratique quand il s'agit de developpement.

                                          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  . Évalué à 3.

                                            Dans la réalité, tu peux payer n'importe quelle société qui l'acceptera pour développer n'importe quel logiciel libre sur le système que tu choisis. Je ne dis pas que tu trouveras forcément une société pour le faire, mais c'est possible. Et c'est peut-être de la théorie pour toi qui bosse chez Microsoft, mais c'est une réalité dans la boite où je suis (par ex: j'ai fait des modifs dans OpenLDAP de façon à faire une passerelle Win2k/Netscape pour une grosse entité nationale).

                                            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  (site Web personnel) . Évalué à 0.

                                  > 99,9% des applications Unix sont indépendantes du système
                                  > (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  . Évalué à 3.

                                    Par contre, les aplis Linux sont de temps en temps dependante du noyau.



                                    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  (site Web personnel) . Évalué à 5.

                    « /etc/passwd et /etc/shadow ne faisaient qu'un il y a pas si longtemps. »

                    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  . Évalué à -4.

                      Ben voyons, tu connais beaucoup de grand-meres qui gerent des parcs de 200 machines ou plus et qui font ce genre d'operations ? moi pas en tout cas. Pour administrer des parcs de machines faut un minimum de connaissances, chez Unix ca s'appelle perl, sh, vi etc... chez Windows ca s'appelle VBScript, WMI etc...

                      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  (site Web personnel) . Évalué à 1.

                        Donc tu acceptes le fait que l'argument de la facilité de windows ne tiens pas pour les grandes boites :
                        - 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  . Évalué à -2.

                          Quand tu geres un parc de 200 machines le cote "GUI facile" n'entre plus en compte car tu files pas un boulot comme ca a un non-informaticien et une GUI permet pas de gerer totalement 200 machines(d'ou le besoin de l'informaticien...).
                          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  (site Web personnel) . Évalué à 1.

                        Ben voyons, tu connais beaucoup de grand-meres qui gerent des parcs de 200 machines ou plus et qui font ce genre d'operations ?
                        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  . Évalué à -1.

                    Si la majorite des admins d'un systeme sont ignares, il
                    y a de forte chance que le systeme soit a chier.
                    • [^] # Re: GUI + fichiers texte

                      Posté par  (site Web personnel) . Évalué à 0.

                      Si la majorite des admins d'un systeme sont ignares, il y a de forte chance que le systeme soit a chier
                      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  . Évalué à 1.

                    Le jour ou le format de /etc/passwd change.... Oui d'accord mais que se passera t'il le jours ou WMI change ? (c'est une proposition strictement equivalente). Ben a ce moment la super commande en VBscript est inutilisable.

                    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  . Évalué à -4.

                      Les API ne changent pas contrairement au format des donnees, c'est pour ca que >90% des softs Windows 3.1 tournent encore sur Windows XP. Donc la meconnaissance des pratiques commerciales du monde informatique est plutot de ton cote, ou on peut appeler ca de la mauvaise foi aussi, au choix.
                      • [^] # Re: GUI + fichiers texte

                        Posté par  . Évalué à 3.

                        C'est beau comme un discour marketing. Les API des fichiers textes de /etc ne changent pas non plus : ouvrir fichier avec un editeur, modifier fichier, enregistrer fichier.

                        ( 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  . Évalué à -2.

                          C'est pas un discours marketing c'est la realite.

                          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  . Évalué à 5.

                            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.

                            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  (site Web personnel) . Évalué à 1.

            Je voudrais pas faire chier (et je ne connais pas VBscript) mais j'ai l'impression que si j'ai un compte e_armand je vais me retrouver avec un compte e_oldarmand.

            J'ai faux ?
          • [^] # Re: GUI + fichiers texte

            Posté par  . Évalué à 1.

            Euh, ton script, la : il vaut vraiment la peine de debourser 1500 balles ? Avec Windows tu peux TOUT faire sauf ce que tu peux faire avec Linux et en plus c'est payant. Dire qu'il y a des tares qui deboursent 1500 balles pour faire du VBScript, je reve !
            • [^] # Re: GUI + fichiers texte

              Posté par  (site Web personnel) . Évalué à 5.

              Si tu n'aimes pas le vbscript, tu peux faire du python (qui supporte bien les objets COM), qui est a mon gout infiniment meilleur que vbscript (sauf qu'il n'est pas installe de base)
      • [^] # Re: GUI + fichiers texte

        Posté par  (site Web personnel) . Évalué à 5.

        net? Celle qui permet de faire ch*er tous les utilisateurs du reseau avec un

        net send * salut les moules!!
        • [^] # Re: GUI + fichiers texte

          Posté par  . Évalué à 1.

          mon admin s'en souvient encore ;)
          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  (site Web personnel) . Évalué à 10.

      Le clickodrome c'est *super* pour les gens qui débutent sous Linux, et c'est carrément indispensable dans ce cadre là.
      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  (site Web personnel) . Évalué à 10.

        ... Ce qui a mon avis repose l'eternelle question de la multiplicite des window managers. En effet, si on veut faire des clickodrome efficaces et ergonomiques, ne serait-ce que pour gnome ou kde (ou encore windowmaker), ca prend qd meme un temps non-negligeable.

        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  (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  (site Web personnel) . Évalué à 2.

            Oui, cela dit un utilisateur lambda comprendra mal pourquoi il a des qui ont differents styles : en toute honnetete c'est laid d'avoir du gtk avec du kde et du WINGs... Ca fait un peu patchwork...

            -- Seb
            • [^] # Re: GUI + fichiers texte

              Posté par  (site Web personnel) . Évalué à 1.

              [...] pourquoi il a des fenetres qui ont [...]

              -- Seb
            • [^] # Re: GUI + fichiers texte

              Posté par  . Évalué à 1.

              La solution, a mon humble avis, se rapproche fort d'une solution proposée plus haut.
              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  . Évalué à 2.

                Definition des paramêtres a configurer dans un format bien standard (XML semble pas mal pour ca)

                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=(|(&amp;(memberobject=%M)(objectclass=memberof))(&amp;(groupobject=%M)(objectcla
                ss=groupmemberof)));group.dn=ou=Groups, o=ExampleMembershipDir;group.filter=(&amp;(cn=%g)(objectclass=mgroup
                ));server.principal=cn=Administrator, ou=Members, o=ExampleMembershipDir;user.dn=ou=Members, o=ExampleMember
                shipDir;user.filter=(&amp;(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  . Évalué à 8.

                  Tu n'as pas massacré la mise en page, mais ce qu'il faudrait c'est un viewer qui réindente et colorise correctement. Après cette opération ça doit redevenir lisible, et sauvegarder avec cette indentation là ne doit pas poser de probème.

                  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  (site Web personnel) . Évalué à 1.

                    Bof, un fichier XML peut vite devenir un trés trés gros bordel, même avec une indentation automatique et colorée.

                    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  (site Web personnel) . Évalué à 6.

            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

            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  (site Web personnel) . Évalué à 10.

      Un autre avantage de garder des fichiers textes dans /etc, c'est pour la sauvegarde :

      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  (site Web personnel) . Évalué à 7.

      par exemple, essayez de créer 200 comptes NT avec un script

      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  . Évalué à 5.

    Voici la fortune qui était présente quand j'ai lu la nouvelle :
    «Dès que je clique sur "mount", il ne fait rien et le cdrom
    reste "unmount".
    Quel est le pb ?»
    -+- Popol in Guide du linuxien pervers : "De l'avantage des interfaces..." -+-
    Bon, d'accord, il ne s'agit pas d'un cas de configuration du système, mais les GUI ne sont pas toujours au point ...
    • [^] # Re: Fortune adaptée ...

      Posté par  . Évalué à 1.

      Ce qu'on demande à une GUI, c'est d'être clair.
      ç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  . Évalué à 10.

    Je me fous complètement que l'interface soit texte ou graphique. Ce qui m'intéresse c'est qu'elle soit ergonomique et puissante... Là chaques écoles à son point fort. Ce qui manque à Windows est un bon shell, un bon jeu de commandes, et quelques language simple (et gratuis) de programation. Peut importe que la config soit une base de données de fichiers, des fichiers textes ou gravée dans la pierre, du moement que l'on à des outils puissants.

    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  (site Web personnel) . Évalué à 0.

      « Je me fous complètement que l'interface soit texte ou graphique. Ce qui m'intéresse c'est qu'elle soit ergonomique et puissante... Là chaques écoles à son point fort. Ce qui manque à Windows est un bon shell, un bon jeu de commandes, et quelques language simple (et gratuis) de programation. Peut importe que la config soit une base de données de fichiers, des fichiers textes ou gravée dans la pierre, du moement que l'on à des outils puissants. »

      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  (site Web personnel) . Évalué à 2.

      Ce qui manque à Windows est un bon shell
      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  . Évalué à 1.

    Mouais ... bon a mon avis je vais me faire traiter de tous les noms mais je pense perso que le problème n'est pas là.

    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  (site Web personnel) . Évalué à 1.

      <mode humour="on">
      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  . Évalué à 5.

        <mode crétin="on">
        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  . Évalué à 3.

          le fonction de partage au click marchera dans la
          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  (site Web personnel) . Évalué à 1.

      Comment cela serait-il possible autrement?

      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  . Évalué à 3.

        ben a ton exemple tout con je te propose deux exemples encores plus con :

        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  . Évalué à 5.

          Je trouve que ta reflexion est biaisée:

          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  . Évalué à 10.

    C'est quand même le marché qui guide la conception des systèmes d'exploitation qu'on le veuille ou non.
    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  . Évalué à 10.

      Tu peux lui dire ça ton chef:

      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  (site Web personnel) . Évalué à 2.

    hello ;)

    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  (site Web personnel) . Évalué à 0.

      y'a de l'idée.
      tu nous le code ?
    • [^] # Re: IMPORTANT Trollerie !!!! par Code34

      Posté par  (site Web personnel) . Évalué à 3.

      Ouais, elle est pas mal t'on idée. elle rejoint un-peu des principes de fonctionnement de certains logiciel évoqués plus haut.
      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 à ceux qui les ont postés. Nous n’en sommes pas responsables.