Une base de registre pour Linux ?

Posté par . Modéré par jerome.
Tags :
0
30
août
2004
Linux
La centralisation des fichiers de configuration sous Linux est un vieux débat, qui est une nouvelle fois remis sur le tapis. Les spécifications d'une base de registre pour Linux viennent d'être publiées tout récemment. Des outils graphiques pour l'éditer sont également en train de voir le jour.

Le nom lui-même de "registry" est susceptible de changer. Il a été choisi pour permettre de situer le but du projet mais les auteurs sont à la recherche d'un nouveau nom, ouverts aux propositions. NdM: Voici quelques caractéristiques complémentaires issues de la page de présentation :

Registry est un système qui regroupe les informations de configuration du système en suivant des règles fixées à l'aide d'une structure clef-valeur. Il est conçu pour être léger, indépendant de toute distribution, sans dépendance logicielle et accessible dès le début de l'initialisation du système par des programmes tels que /sbin/init .

Il est prévu pour fonctionner sur tout système POSIX (Linux ou autre) et devrait être facilement portable sur des systèmes non POSIX. Les informations de configuration (clef-valeur) sont stockées dans des fichiers textes UTF-8. Registry ne nécessite pas de démon susceptible de crasher, ni de base SQL.

Registry se présente sous la forme d'une bibliothèque écrite en C et d'un programme en ligne de commande pour accéder/modifier les informations de configuration de manière automatisée. Des contributeurs ont déjà fourni de nombreux bindings pour accéder à l'API de Registry depuis des langages tels que C/C++, shell, python, ruby, java, (les bindings pour perl et d'autres sont en court de développement). De plus, tout ou parti du registre est importable/exportable sous forme de fichier XML. Enfin, il existe aussi une interface graphique en Qt.

Aller plus loin

  • # Tentative de record ?

    Posté par . Évalué à 6.

    La news sur les pilotes de webcam a sans doute aiguisé les appétits...

    Alors, les paris sont ouverts sur le nombre de commentaires à venir. Moi, je pars sur un minimum de 250.

    Bon, je lance la discussion : quel est l'intérêt d'une base de registres part rapport à des fichiers de config bien rangés ? Je pense qu'il vaudrait mieux revoir l'organisation de ces derniers.

    Parce que c'est vrai que j'en ai marre d'avoir 200 dossiers cachés dans mon répertoire home. J'aimerais plutôt un ".config" avec tout dedans.
    • [^] # Re: Tentative de record ?

      Posté par . Évalué à 4.

      C'est a peu près ca qu'ils veulent faire...
      Je n'ai pas encore regardé le projet...mais avoir un tool graphique qui récapitule clairement, fichier par fichier, l'ensemble des fichiers config me semble une idée excellente et surtout indispensable pour la clarification...
      Moi-meme, je ne sais plus ou il faut aller pour modifier telle ou telle "option" pour tel ou tel "appli"...ca devenait quand meme, il faut l'avouer, le bordel..
      • [^] # Re: Tentative de record ?

        Posté par (page perso) . Évalué à 9.

        "Je n'ai pas encore regardé le projet...mais avoir un tool graphique qui récapitule clairement, fichier par fichier, l'ensemble des fichiers config me semble une idée excellente et surtout indispensable pour la clarification..."

        Wai, exactement ce que l'on trouve sous Suse dans Yast. Chaque fichier de config est commenté. Franchement, cet outils est bien pensé et permet de rapidement prendre en main la distribution.

        http://l3lx202.univ-lille3.fr/~bellegarde/yast_config.png(...)
      • [^] # Re: Tentative de record ?

        Posté par (page perso) . Évalué à 10.

        Je vous offre la discussion qui a eu lieu sur freedesktop sur le sujet :
        http://freedesktop.org/pipermail/xdg/2004-April/003720.html(...)

        En gros, le mec s'est fait allume. En theorie, ca a l'air pas mal et ca repond a un besoin, au moins du point de vue utilisateur. Maintenant, quand on laisse parler les gens qui se sont reellement penches sur le sujet, comme ceux qui s'occupent de gconf, linux registry ne repond pas un certain nombre de problematiques pourtant importantes dans une gestion de configuration globale.
        • [^] # Re: Tentative de record ?

          Posté par . Évalué à -1.

          > En gros, le mec s'est fait allume.

          Linux registry s'est aussi fait "explosé" sur Fedora.
          Je ne sais plus pourquoi car ça ne me passionne pas beaucoup.
    • [^] # Re: Tentative de record ?

      Posté par (page perso) . Évalué à -2.

      Parce que c'est vrai que j'en ai marre d'avoir 200 dossiers cachés dans mon répertoire home. J'aimerais plutôt un ".config" avec tout dedans.

      Mais s'ils sont cachés, il ne te gênes pas ! ;-)

      L'idée de tout avoir dans un seul fichier ne me tente pas vraiment. Quel serait les conséquences si lors de l'install d'une application, celle ci foire et foute en l'air le fichier de config ? La configuration de toutes les autres applis sera elle aussi à refaire ?
      • [^] # Re: Tentative de record ?

        Posté par (page perso) . Évalué à 3.

        Je déclare cette branche du troll close tant que tu n'as pas été lire les liens :)

        Il n'est aucunement prévu d'utiliser un seul fichier.

        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: Tentative de record ?

          Posté par (page perso) . Évalué à -2.

          Effectivement ! La prochaine fois, je lirais mieux :-(

          Inutilisez moi, et m'en vais me flagellez, ou plutôt apprendre à lire :-(
          • [^] # Re: Tentative de record ?

            Posté par . Évalué à -6.

            "Inutilisez moi, et m'en vais me flagellez, ou plutôt apprendre à lire :-( "

            Et apprendre à écrire ?? :-))
        • [^] # Re: Tentative de record ?

          Posté par . Évalué à 4.

          toi tu iras mieux lire le fil, notre ami Xavier repondais à Dring dring qui lui même stipulait:

          j'en ai marre d'avoir 200 dossiers cachés dans mon répertoire home. J'aimerais plutôt un ".config" avec tout dedans

          effectivement vu sous cette angle :), ce que je trouve étrange c'est que beaucoup de personne ce sont focalisé sur:Xavier répond à la nouvelle, ben non Xavier repondais à dring dring.

          voila voila, je n'aime pas les injustices
          • [^] # Re: Tentative de record ?

            Posté par . Évalué à 2.

            et bien sans vouloir être méchant, dans la phrase : 'en ai marre d'avoir 200 dossiers cachés dans mon répertoire home. J'aimerais plutôt un ".config" avec tout dedans, on comprends que .config est un dossier, et non un fichier.

            je n'aime pas les fausses réparations d'injustice :)
            • [^] # Re: Tentative de record ?

              Posté par (page perso) . Évalué à -1.

              <mode capillotraction>
              correction, on comprends que .config est un dossier et a fortiori un fichier car un dossier est un type particulier de fichier.
              
              man bash /CONDITIONAL EXPRESSIONS
              -d file
                         True if file exists and is a directory.
              
              </mode capillotraction>
              
              • [^] # Re: Tentative de record ?

                Posté par . Évalué à 3.

                Oui mais d'apres ce que j'ai compris de Reiser4, tout fichier est un dossier. Ce que ca va commencer a etre compliquer pour la pauvre Mme Michu si on lui dit que un fichier est un dossier mais qu'un dossier est un fichier ...
                • [^] # Re: Tentative de record ?

                  Posté par (page perso) . Évalué à 3.

                  ouais mais par contre c'est super cool le fichier/dossier :)

                  J'y avais déjà pensé a cause d'un bug de xffm (dans une redhat pas toute neuve) quand on fait un drag&drop sur un fichier (par samba, au moins, pour le reste je me rappel pas) il se met a considérer le fichier comme son dossier parents...

                  Au début ça fait bizarre, mais ça m'a donné des idées bizarres aussi: imaginez un fichier xml, qu'on pourrait lire et modifier comme un répertoire avec des sous repertoires (vision assez courante du fichier xml comme un arbre...) que l'on pourrait triter avec des mkdir, etc. (ça demanderais sans doute une petite evoultion de ces outils pour pouvoir rajouter des attributs supplémentaires à un répertoire), ou encore des ACLs sous forme d'un sous repertoire à chaque fichier...

                  Bref tout ce qui peut se représenter par un arbre aurait ainsi un interface quasi universelle, et qui plus est simple :)...
                  • [^] # Re: Tentative de record ?

                    Posté par . Évalué à 1.

                    On pourrait aussi imaginer une utilisation plus universelle (comprendre pas seulement pour le XML), où un fichier serait un dossier dans lequel on pourrait avoir un fichier qui correspond au contenu, un autre pour différents attributs, un autre pour les acls, un autre pour l'icone du fichier, éventuellement d'autres pour garder un historique du fichier, etc...

                    On peut prendre l'exemple des application sous MacOS X (mais je crois que c'est un concept Next) où une application est un dossier dans lequel on a :
                    - l'executable
                    - les traductions dans différentes langues
                    - les icones
                    - etc ...


                    Etienne
                    • [^] # Re: Tentative de record ?

                      Posté par . Évalué à 1.

                      C'est aussi le principe des "exécutables" java : un fichier (en fait un zip) contient le descriptif de l'application (dans META-INF), les librairies nécessaires, les classes de l'application, et les ressources (icônes, images, sons, traductions, ...).
                    • [^] # Re: Tentative de record ?

                      Posté par . Évalué à 1.

                      Sous Linux on a Zero-Install fourni par Rox -> http://zero-install.sourceforge.net/(...)

                      Ça semble correspondre, à peu près, à ton point de vue.
              • [^] # Re: Tentative de record ?

                Posté par . Évalué à 1.

                <mode capillotraction strength="maxi">
                    directory = répertoire
                    folder = dossier
                </mode capillotraction>

                Ça n'est pas rigoureusement la même chose :)
                • [^] # Re: Tentative de record ?

                  Posté par . Évalué à 2.

                  ou plutot:
                  directory = annuaire (oui, oui, le D de LDAP ou de MS AD, c'est ca :)) )
                  • [^] # Re: Tentative de record ?

                    Posté par . Évalué à 3.

                    Un repertoire (ex: telephonique), c'est rien de plus qu'un annuaire (ex: telephonique) dans lequel tu n'as que tes contacts au lieu d'avoir ceux de la ville entiere.
      • [^] # Re: Tentative de record ?

        Posté par . Évalué à 3.

        Ben si, parce que des fois j'ai besoin d'aller dans les fichiers cachés. Alors, dans mon clickodrome favori, j'ai activé l'option "Voir les fichiers/dossiers cachés", et du coup j'ai 200 fichiers dans mon répertoire home.

        D'ailleurs, si il n'y a plus qu'un répertoire comme point d'entrée au système de configuration, il n'est même plus nécessaire de le cacher, bien au contraire.

        Par contre, je trouve l'interview rebutante et soporifique. Après avoir suivi l' "invitation" de InfernalQuark à consulter les liens, je me permet de conseiller plutôt la présentation OOo.

        Et je rajouterais l'information suivante : le système se décompose en 3 répertoires principaux (extrait de la présentation) :

        The system/* tree is stored under /etc/registry/
        The user:$USER/* tree is stored under ~$USER/.registry/
        The user/* tree is a shortcut to current user's tree

        On notera donc qu'il s'agit de répertoires qui contiennent des fichiers, qui eux-même respectent une arborescence qui est définie par la norme, et qui prévoit déjà d'intégrer les grands classiques : fstab, etc...

        Enfin, puisqu'il (l'auteur du projet) est en recherche de nom, je propose d'ouvrir le débat avec CEFICS pour "Central[ized] FIle-based Configuration System", ou CEFIX pour faire plus court.
        • [^] # Re: Tentative de record ?

          Posté par (page perso) . Évalué à 2.

          Après avoir suivi l' "invitation" de InfernalQuark à consulter les liens, je me permet de conseiller plutôt la présentation OOo.

          Tu voulais pas non plus un bon à découper ? :)
          J'irais bien voir le document OOo mais je suis au taff et je peux pas installer OOo :(

          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: Tentative de record ?

          Posté par (page perso) . Évalué à 1.

          J'ai une super idée pou toi : tu crée un lien symbolique appelé "config" dans ton $HOME qui pointe vers "."

          Tu désactives l'option "afficher les fichiers cachés" dans $HOME et tu l'actives dans $HOME/config

          Voilà, tu as résolu ton problème !
          • [^] # Re: Tentative de record ?

            Posté par (page perso) . Évalué à 10.

            Attention au rm * dans la Home directory ;-)
            D'expérience, vaut mieux ne pas laisser trainer des fichiers dans un répertoire d'accueil :-(
            • [^] # Re: Tentative de record ?

              Posté par . Évalué à 0.

              Je t'aurai bien plussé !!!
              Effectivement rescement j'ai voulu supprimer un fichier .tar.gz et son dossier decompressé alors j'ai tout simplement tappé le nom du dossier et rajouté * pour que ca supprime l'archive en mm temps...

              exemple :

              # rm appli * -rf

              Effectivement j'ai mis un espace en trop...
              Et vu que j'etais dans /home/max/ ...

              Si ceux qui ont suffisament d'XP peuvent plusser le commentaire auquel je repond, je les remerci par avance :)

              Mici bien :)
              • [^] # Re: Tentative de record ?

                Posté par (page perso) . Évalué à 2.

                #rm -rf machin *
                zsh: sure you want to delete all the files in /home/max ? [yn]

                (au début ca saoule, mais suffit d'une fois...)
              • [^] # Re: Tentative de record ?

                Posté par . Évalué à 2.

                depuis, des que j'utilise * je met un -i au lieu de -f. En particulier les rm *~ que je fais assez regulierement, j'ai toujours trop peur de faire une bourde.
          • [^] # Re: Tentative de record ?

            Posté par (page perso) . Évalué à 3.

            Chez moi, le /home est en fait /domus et chaque utilisateur à un dossier "travail", un dossier "media" et un dossier "public_html" qui sont senser regrouper les docs, les images/musique/videos et sa page web.

            ça permet ne pas utiliser directement le $HOME, mais toujours $HOME/<un dossier>

            ls $HOME est en fait le .config
          • [^] # Re: Tentative de record ?

            Posté par . Évalué à 1.

            Pas con, je m'en veux de ne pas y avoir pensé !

            Merci !
        • [^] # Un nom pour ce projet

          Posté par (page perso) . Évalué à 0.

          Salut,

          Moi je propose "Slash etc", ou alors "/etc" comme nom.
          Le jeu de mots en français c'est pas génial (CEFIX). Avec "Slash etc" il y a une référence.
          Le cahier des charges me semble légèrement sorti par quelqu'un
          de chez bilou: portable vers les systèmes non conformes POSIX, nombreuses références à l'infâme système Micro$oftien de la
          base de registre. C'est louche tout ça...
          Si un jour je développe du libre, il se pourrait bien que je rende mon programme UNIX-dependant ou même GNU-dependant,
          exprès évidemment.

          :O)
    • [^] # Re: Tentative de record ?

      Posté par (page perso) . Évalué à 10.

      Suit les liens au lieu de dire des sottises.

      Il n'est nulle part indiqué que la conf sera centralisée dans un fichier. Ils parlent même de plusieurs petits fichiers rangés dans une arborescence (voir même un fichier par clé ce qui peut être pratique pour le packaging).

      Le but est surtout d'avoir une syntaxe commune pour toutes les configurations et une API unique pour y accéder.

      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: Tentative de record ?

        Posté par (page perso) . Évalué à 2.

        C'est ce genre de détail qu'il aurait était pertinent de préciser dans la news, plus que de savoir qu'il existe un "binding" java ou python ou ...

        Donc merci de la précision pour ceux qui ne se donnent pas le temps de suivre les liens :)
        • [^] # Re: Tentative de record ?

          Posté par (page perso) . Évalué à 7.

          Les informations de configuration (clef-valeur) sont stockées dans des fichiers textes UTF-8

          Il suffit de savoir lire /o\

          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: Tentative de record ?

            Posté par (page perso) . Évalué à 3.

            Oui, mais ce n'était pas aussi clair que ta précision. "Des fichiers" ca peut être 2 comme 500. Et le matin je n'ai pas forcément l'esprit assez vif pour mettre en relief suffisament cette courte description du fonctionnement - point qu'il m'aurait semblé important de développer, c'est le plus intéressant! Et ça aurait empêché de trop comparer cela à la base de registre de ms-windows. Voilà ce que j'en dis.

            ps : au passage, il y a une coquille dans la nouvelle : "les information de configuration", j'aurais mis un "s" à "information". Et celle là aussi "d'un bibliothèque". Mais si ça se trouve, c'est que je ne sais pas lire!
        • [^] # Re: Tentative de record ?

          Posté par . Évalué à 3.

          Y'a ca dans la news pour ceux qui lisent jusqu'au bout:
          Les informations de configuration (clef-valeur) sont stockées dans des fichiers textes UTF-8
      • [^] # Re: Tentative de record ?

        Posté par (page perso) . Évalué à 2.

        Le risque est de finir par une base de registres monstrueuse à la façon Microsoft.
        • [^] # Re: Tentative de record ?

          Posté par . Évalué à 4.

          avec un système de fichier bien adapté (reiserfs ?) ça peut résister à la montée en volume.
        • [^] # Re: Tentative de record ?

          Posté par . Évalué à 2.

          Je préfère quand même: (exemple fictif montrant comment je verrais/aimerais voir un des fichier de config)
          
          [config application=truc]
           [history]
            [length]50[/length]
           [/history]
          [/config]
          
          que:
          
          %f$50ùi
          
          Tant que c'est lisible pour un humain et bien organisé (arborescent), plus y a de texte, mieux c'est.
          
          ps: comment on fait pour écrire de l'XML dans un commentaire?
          
    • [^] # Re: Tentative de record ?

      Posté par (page perso) . Évalué à 8.

      J'aimerais plutôt un ".config" avec tout dedans.

      Certaines applications, comme openbox ont leur config dans ~/.config/
      Ça suit les recommandations de freedesktop: http://www.freedesktop.org/standards/basedir-spec/(...)
    • [^] # Re: Tentative de record ?

      Posté par . Évalué à 3.

      >J'aimerais plutôt un ".config" avec tout dedans.
      Moi perso, je prefererais un dossier ~/.config qui contient tout les autres .truc ...

      C' est quand même mieux qu' une grosse usine .config qui à tout dedans non ?
      • [^] # Re: Tentative de record ?

        Posté par . Évalué à 2.

        Oui moi je suis entierement d'accord cela éviterai d'avoir tout plein de fichiers inutils sur la racine du répertoire.

        Genre chez Mozilla ils commencent à le faire car maintenant au lieu d'avoir un .mozilla et un .firefox on trouve les conf de firefox dans le .mozilla

        Ben maintenant il ne reste plus q'u'à ajouter .config devant et c le pied.

        [debut troll]
        Perso la base de registre c bien si ça ne devient pas une MERDE comme celle de Windows....
        [fin troll]
      • [^] # Re: Tentative de record ?

        Posté par . Évalué à 2.

        C'est ce que je voulais dire. Evidemment, un énorme fichier texte serait plus une source d'emmerde qu'autre chose.
        • [^] # Re: Tentative de record ?

          Posté par . Évalué à 1.

          On est d' accord ;-)

          Dans le meme registre, y a t' il un moyen de configurer konqueror pour
          lui dire de ne pas afficher certains fichiers/dossiers ?

          Un genre de .cvsignore
          Je veux cacher /etc /usr /var /tmp /boot /bin /sbin...

          Je voudrais configurer ça pour ma
          copine, les dossiers systèmes lui font peur et ne lui servent à rien ;-)

          Cette fonctionnalité serait egalement très utile pour virer visuellement les
          .mozilla et autres qui genent car même si on peut le faire en cachant les
          fichiers cachés, il est parfois utile de voir les nouveaux, c'est à dire ceux
          qu' on à pas mis dans le ".cvsignore" ...
    • [^] # Re: Tentative de record ?

      Posté par . Évalué à 2.

      Même avis !

      Moi je verrais surtout un « etc » ou « .etc » dans le home des utilisateurs, histoire de conserver le terme consacré.

      Manque de chance, il y a quelque temps déjà, un grand sondage avait été organisé juste avant de redéfinir le FHS. J'ai voulu soumettre l'idée mais j'étais indisponible à ce moment, et je n'ai pas trouvé le temps de le faire avant la clôture ...
  • # Avec les mêmes défauts que sous Windows ?

    Posté par (page perso) . Évalué à 9.

    Lorsque Microsoft a mis en place la base de registre sur MS Windows, il y a eu beaucoup de critiques. Par exemple, le fait qu'il suffit qu'un seul fichier soit corrompu (l'un de ceux de la base de registre) pour que le système ne puisse plus du tout redémarrer.
    Alors je me demande : quel gain cela pourrait apporter à GNU/Linux de mettre en place une telle structure ?
    • [^] # Re: Avec les mêmes défauts que sous Windows ?

      Posté par . Évalué à 0.

      une facilité dans la programmation de logiciels ?
      • [^] # Re: Avec les mêmes défauts que sous Windows ?

        Posté par . Évalué à 1.

        C'est ca le pb ! et surtout ATTENTION -> Please DO NOT TROLL

        genre Registre Zin vs Futur registre Nix...

        Donc il faut voir le projet pour determiner comment l'architecture de ce/ces fichiers de config vont etre mis en place...et justement, nous avons le plus bel exemple de la base de registre win a ne pas suivre...
      • [^] # Re: Avec les mêmes défauts que sous Windows ?

        Posté par (page perso) . Évalué à 3.

        Alors oui mais peut-être que non.

        Prenons par exemple Charles Bronson, développeur qui fait du libre, il a déjà réalisé Justicier 4 Linux, et pour quelques Linux de plus, ainsi que Les douze Linux. Chaque logiciel créé un répertoire .quelquechose dans lequel il entrepose les fichiers de config propres au logiciel.

        Bon, il constate que registry ca à l'air bien, stable, plus facile et tout... Donc il décide de migrer sa config sous registry. Oui mais bon, au début, il serait plus judicieux de gérer les deux types de gestion de conf, registry et fichiers cachés à l'ancienne parce que tous les utilisateurs ne vont pas migrer comme ca du jour au lendemain vers registry, et puis plein de choses comme ca...

        Ce système, tout bien qu'il soit, arrive un peu à la bourre à mon humble avis parce que ca implique des changements en profondeur pour pas mal de softs... [troll] Je vois mal sendmail passer sous registry.[/troll]

        c'est surement plus facile de créer un nouveau logiciel en donnant comme prérequis d'avoir registry d'installé mais c'est d'autant plus difficile de migrer la tétrachiée de logiciels existant.
        • [^] # Re: Avec les mêmes défauts que sous Windows ?

          Posté par . Évalué à 5.

          J'ai tendance a penser que les deux systemes cohabitent tres bien. Soit le fichier de conf est dans l'arborescence des fichiers de conf "registry", et il se doit d'etre compatible. Il peut dans ce cas etre edite par les outils compatible avec "registry".
          Soit il se trouve ailleurs (n'importe ou dans /etc par exemple) et il est utilisable par l'appli en question, mais uniquement par cette appli.

          Donc les softs passeraient en douceur chacun a leur tour, et l'utilisateur n'y verrait rien. Quand Toufou (un post un peu plus bas) parle de "quelle horreur" et dit "je n'utiliserais pas ça chez moi", il pourra decider de ne pas installer les outils d'edition de la config. Il ne pourra jamais empecher un logiciel d'utiliser un fichier de configuration quelle que soit sa syntaxe, compatible ou non avec le standard. En l'occurence, il n'a pas refuse d'utiliser init parce que le fichier /etc/inittab a une syntax qui ne lui plait pas )

          Le bonjour chez vous,
          Yves
          • [^] # Re: Avec les mêmes défauts que sous Windows ?

            Posté par . Évalué à 2.

            A mon avis ça va être quelque peu le bazard pour arriver à trouver le bon fichier après. Déjà qu'actuellement, je ne sais pas trop si tel fichier est dans un sous dossier ou à la racine de /etc, alors si en plus il faut aller chercher dans deux dossiers différents, ça va pas être la joie...
          • [^] # Re: Avec les mêmes défauts que sous Windows ?

            Posté par (page perso) . Évalué à -1.

            Il ne pourra jamais empecher un logiciel d'utiliser un fichier de configuration quelle que soit sa syntaxe
            Beh il suffit de ne pas utiliser le logiciel ... Je n'aime pas les init system V, les machins de gestion de dépendances de packages => j'utilise la Slack. Si la Slack perd son côté simpliste je passerai à une distro plus "primitive".
            Je ne me fais pas de soucis quand à la disponibilité de softs n'utilisant pas cette techno à sauce 'base de registre' : tout centraliser c'est peut-être une bonne idée à la base mais ça tend forcément sur le hyper complexe et lourdingue (pour garder le truc cohérent) donc impossible à maîtriser pour le programmeur feignasse (un peu comme autoconf : combien de projets ont un autoconf nickel ?) qui utilisera le bon vieux fichier de conf à la rcfile.
            A mon avis ce machin ne sera intéressant que pour les projets énormes (comme sous windows) où on pourra y dédier des codeurs, mais pour les projets de moindre envergure, je parie que ce ne sera que très peu utilisé à cause de la difficulté d'apprentissage et du peu de respect des specs dus à cette difficulté.
      • [^] # Re: Avec les mêmes défauts que sous Windows ?

        Posté par . Évalué à 3.

        L'introduction d'une base de registre va necessairement rentrer en concurrence avec le bon vieux parsing de /etc/ et donc avec Posix, je doute fort que la facilité de programmation soit un critere, faire un open file et un coup de parsing sur un fichier plat (ou XML) n'a jamais tué personne.

        Et quand bien meme, il ne faut pas oublier que la base de registre sera affreusement normalisée (je sens XML venir a plein nez avec des DTD a la mort moi le noeud et je n'aime pas ca du tout), et exit la simplification de la programmation.

        Coté securité l'acces en base de registre demandera des nouveaux droits (qd au chroot qu'est ce qui se passe dans ce cas ? Comment le faire avec une base de registre???) et des ACLs bien complexes qui finiront tres rapidement a introduire des failles inherentes a cette structure sans parler des chaines de dependances qui viendront prendre le dessus et les conflits dans les choix des paths sur des projets ... la base de registre aura pas mal de chances d'etre franchement indigeste.

        Et puis, loader une base (en plus des problemes de corruption) c'est loader des tas de trucs dans la RAM qui ne servent a rien ou qui risque d'etre utilisés pour loader des choses ... bref c'est indesirable pour un systeme efficace et securisé.
        • [^] # Re: Avec les mêmes défauts que sous Windows ?

          Posté par . Évalué à 3.


          Coté securité l'acces en base de registre demandera des nouveaux droits

          A priori, ce n'est qu'une lib qui parse des fichiers, donc les droits se gèrent au niveau du filesystem

          (qd au chroot qu'est ce qui se passe dans ce cas ? Comment le faire avec une base de registre???)

          Dans ce cas de 2 choses l'une, soit ton application est prévue pour le chroot et lit sa conf avant de chrooter et il n'y a pas de problème, soit elle n'est pas prévue pour et il faut déplacer le répertoire contenant les fichiers de la configuration du soft dans le chroot

          et des ACLs bien complexes qui finiront tres rapidement a introduire des failles inherentes a cette structure
          Les droits sont gérés très simplement au niveau du filesystem, ca ne change rien par rapport à l'analyse d'un fichier de config, sauf que l'on passe par une bibliothèque au lieu de faire l'analyse sois-même


          sans parler des chaines de dependances qui viendront prendre le dessus et les conflits dans les choix des paths sur des projets ... la base de registre aura pas mal de chances d'etre franchement indigeste.

          Le problème est le même quand au choix d'un emplacement de fichier de configuration.


          Et puis, loader une base (en plus des problemes de corruption) c'est loader des tas de trucs dans la RAM qui ne servent a rien ou qui risque d'etre utilisés pour loader des choses

          Tu ne load pas toute la base, si tu demande le contenu de toto.titi.tata, tu ne charge et ne lit que le fichier toto/titi/tata


          En bref, le seul changement par rapport à un fichier de config par application c'est que l'on utilise une même bibliothèque et que les fichiers de config sont tous au même endroit.

          Etienne
    • [^] # Re: Avec les mêmes défauts que sous Windows ?

      Posté par (page perso) . Évalué à 10.

      Pour éviter la problématique M$, il semble qu'on s'oriente vers une structure de fichiers texte. En fait, cela ressemble fortement à la base ODM de IBM/AIX qui permet avec des notions objet de représenter tout le système. La base ODM s'exporte au format texte et se recrée facilement à partir de la sauvegarde texte mais travaille sur des fichiers bianires.
      Un outil d'administration devient facile à écrire car l'administratin des logiciels répond aux mêmes canevas. On peut aussi facilement se mettre dans le moule pour les procédures d'installation/administration pour ne pas dérouter l'administrateur.
      • [^] # Re: Avec les mêmes défauts que sous Windows ?

        Posté par (page perso) . Évalué à 1.

        clair avec l'outil smit en ligne de commande qui permet d'editer et modifier les différents fichiers de config du système, et qui permet de visualiser la commande lancée.

        voilà de bonnes bases de réflexions
    • [^] # Re: Avec les mêmes défauts que sous Windows ?

      Posté par . Évalué à 10.

      L'implémentation sous linux est différente. Notamment :
      - les fichiers contenant le registre sont lisibles et éditables à la main ( genre avec ton rescue CD et vi ).
      - il n'y a pas un seul gros fichier contenant toute la base de registre.

      Ce projet est plutot est un effort d'uniformisation des fichiers de conf et des api pour les lire/editer qu'une copie de la base de registre windows.
      • [^] # Re: Avec les mêmes défauts que sous Windows ?

        Posté par . Évalué à 9.

        Ce projet me semble extrêmement intéressant ! Cela fait des années que je râle après les fichiers de config qui se baladent partout, qui ont chacun une syntaxe différente, ...
        Et je ne parle même pas du passage d'une distrib à une autre !

        J'aime le principe du fichier texte, lisible, facile à modifier, et qui ne sera pas corrompu par les autres applications, mais par contre, il est clairement temps d'uniformiser le bazar !

        A intégrer d'urgence dans les spécifications LSB à mon avis, si ce n'est pas déjà fait / prévu !!!

        PS : Pour ceux qui ne connaissent pas LSB == Linux Standard Base (http://www.linuxbase.org/(...) ), des spécifications visant à une standardisation des base de toutes les plateformes linux, dans le but d'améliorer la compatibilité, de simplifier l'administration, ...

        Pour plus d'infos, RDV sur http://en.wikipedia.org/wiki/Linux_Standard_Base(...) ou le site officiel.

        Merci d'éviter les trolls sur LSB / RPM / etc... pliz !
      • [^] # Re: Avec les mêmes défauts que sous Windows ?

        Posté par (page perso) . Évalué à 4.

        Cela existe deja, ca s'appelle /etc/sysconfig sous mdk, fedora, ...

        Il suffit d'unifier le tout entre les distribs et de recuperer le code de YaST pour créer une API d'acces a ces fichiers.
        • [^] # Re: Avec les mêmes défauts que sous Windows ?

          Posté par . Évalué à 4.

          Tu l'as dit, il s'agit d'unifier le tout entre les distribs ! D'où l'intérêt ! CQFD !
          • [^] # Re: Avec les mêmes défauts que sous Windows ?

            Posté par (page perso) . Évalué à 2.

            Oui, mais l'interet c'est d'utiliser ce qui existe deja et qui marche(/etc/sysconfig) et de normalisé son fonctionnement, pas de tout reprendre de zero.

            J'aime beaucoup ce quand a fait Suse par exemple.
            • [^] # Re: Avec les mêmes défauts que sous Windows ?

              Posté par . Évalué à 2.

              D'accord avec toi si l'existant est nickel (je ne sais pas, donc je ne m'avance pas...). N'ayant pas lu les liens, je ne sais pas si cette possibilité à été envisagée, voire si ce n'est pas plus ou moins ce qu'ils font ?

              Suse : je ne sais pas ce qu'ils en ont fait, je n'ai pas eu l'occasion d'en utiliser depuis longtemps... J'avais beaucoup aimé effectivement les outils d'admin quand j'en avait acheté une il y'a... si longtemps ! (une 5.3 je crois).
          • [^] # Re: Avec les mêmes défauts que sous Windows ?

            Posté par . Évalué à 1.

            > Tu l'as dit, il s'agit d'unifier le tout entre les distribs ! D'où l'intérêt ! CQFD !

            Pourquoi ?
            • [^] # Re: Avec les mêmes défauts que sous Windows ?

              Posté par . Évalué à 3.

              Peut-être pour rendre humain la tâche d'administrer des réseaux hétérogènes ?
              Pour ne pas devoir tout réapprendre pour chaque nouvelle distrib ?
              Pour ne pas devoir systématiquement avoir 40 pages de docs par format de fichier et d'être obligé de consulter les formats à chaque modif ou presque pour ne pas foirer le système ?
              Parceque c'est plus propre ?
              Entre autres...
              • [^] # Re: Avec les mêmes défauts que sous Windows ?

                Posté par . Évalué à 3.

                Sauf que les 40 pages de doc ne décrivent pas luniquement le format du fichier mais la signification de ce que tu mets dans le fichier. Et ça quelquesoit la forme du fichier (standard trucmuche ou pas) il faudra bien l'écrire et le lire...
              • [^] # Re: Avec les mêmes défauts que sous Windows ?

                Posté par . Évalué à -3.

                Je reformule

                > Peut-être pour rendre humain la tâche d'administrer des réseaux hétérogènes ?
                Quel intérêts d'avoir des réseaux hétérogènes si tout est unifié ?

                > Pour ne pas devoir tout réapprendre pour chaque nouvelle distrib ?
                Quel intérêts d'avoir des distribs différentes si tout est unifié ?

                > Parceque c'est plus propre ?

                C'est clair que mettre des fichiers XML à la place d'un simple fichier de type .ini (samba par exemple) c'est plus propre ... :)
                • [^] # Re: Avec les mêmes défauts que sous Windows ?

                  Posté par . Évalué à 6.

                  >Quel intérêts d'avoir des réseaux hétérogènes si tout est unifié ?

                  Parceque pour toi, si la configuration / administration est unifiée, tout est unifié ?
                  Il n'y a pas de plateformes différentes ? La compatibilité binaire existe entre tous les sytèmes ? Il n'y a aucun logiciel qui ne soit supporté que par certaines plateformes, donc qui oblige une entreprise à posséder cette plateforme, mais qui ne lui convient pas pour d'autres usages ?

                  >Quel intérêts d'avoir des distribs différentes si tout est unifié ?
                  Même réponse.
                  + Toutes les distribs packagent-elles les mêmes softs ? Ont-elles le même but ? (desktop, serveur, rescue, livecd, ...) ? Et j'en passe, je n'ai pas envie de m'étendre sur le sujet... Enfin, l'uniformité de configuration n'implique pas une similitude pour le reste...

                  > C'est clair que mettre des fichiers XML à la place d'un simple fichier de type .ini (samba par exemple) c'est plus propre ... :)

                  Je n'ai pas lu les docs sur le site, mais rien que d'après les commentaires, il ne semble pas que quiconque ait évoqué le XML ?!!!
                  Des fichiers textes avec des ensembles clé=valeur, si ce n'est pas ce que tu appelles des fichiers .ini ?!
                  • [^] # Re: Avec les mêmes défauts que sous Windows ?

                    Posté par . Évalué à 1.

                    > Parceque pour toi, si la configuration / administration est unifiée, tout est unifié ?

                    Besoin différent == souvent façon de faire différent.

                    >Il n'y a pas de plateformes différentes ?
                    Si, samba sous Red Hat se configure de la même façon que samba sous Debian ...

                    > La compatibilité binaire existe entre tous les sytèmes ?
                    Je vois pas l'utilité. J'ai les sources ...
                    Cela ne fait ch*** que les utilisateurs de logiciel propriétaire.

                    >Toutes les distribs packagent-elles les mêmes softs ? Ont-elles le même but ?

                    C'est exactement ce que je suis en train de dire.
                    Il existe des façons de faire différentes pour des besoin différents.

                    A noter qu'il y a finalement peu de différence pour la majorité des logiciels entre par example une RedHat et une Debian.
                    • [^] # Re: Avec les mêmes défauts que sous Windows ?

                      Posté par . Évalué à 6.

                      >Besoin différent == souvent façon de faire différent.
                      >Si, samba sous Red Hat se configure de la même façon que samba sous Debian ...

                      Je ne dis pas. Besoin différents = applis différentes, algos différents,languages différents...
                      Donc paramètres différents.
                      Soit.
                      Mais pourquoi donc ne serait-il pas possible que ces différents paramètres soient exprimés de la même manière ???

                      Pourquoi parle-tu la même langue que moi ? Nous n'avons pas les mêmes besoins, ni visiblement les mêmes algorithmes (;)). Et pourtant, nous avons besoin de nous comprendre, de nous "interfacer", d'être un minimum compatibles, interopérables. Nous parlons donc la même langue.
                      Rien n'empêche une discussion entre un ornithologue et un informaticien. Chacun utilisera dans ce cas un sous-ensemble commun du langage. Ils ont un vocabulaire très différents, mais dans une même langue. Ils se comprennent.

                      C'est sûr, tu vas me dire, il y'a d'autres langues. Et c'est tant mieux, pour des raisons culturelles, ou autres. Mais il en résulte quand même de nombreuses incompréhensions, des incompatibilités (pas seulement d'humeur), des traductions aberrantes, ...

                      Je ne suis pas pour une uniformisation de tout (une seule appli pour faire ceci, une seule pour faire cela, une seule langue, ...). Chacun est libre de choisir l'outil qui lui convient le mieux pour réaliser ce qu'il veut.

                      Mais pour moi, la configuration (du moins le mode de stockage de la configuration) devient quelque chose d'annexe, de plus en plus caché. Ce n'est plus un outil, c'est une sous-couche. Et la notion de préférences devient alors moins importante. Pourquoi vouloir avoir un format particulier, spécifique, pour des fichiers que de toutes façons presque personne ne modifiera plus ? (je m'avance un peu, mais c'est bien à ça que tend l'informatique... d'ici quelques années, les systèmes pourraient même presque entièrement s'auto-administrer...). Alors pourquoi refuser de permettre à ces futurs systèmes d'avoir des bases fiables, communes, standards sur lesquels ils pourront travailler proprement, rapidement, de manière souple et performante ?!

                      En informatique, la notion de standard est fondamentale, et malheureusement souvent trop tardive... Te rappelles-tu les menus de paramètrage des cartes sons et vidéos dans les jeux sous DOS, autrefois ? 200 cartes sons, 200 modes de configurations différents. Et souvent des heures pour que ça marche.
                      Idem pour les cartes vidéos. Alors on a inventé VESA. VESA ne permet pas tout. Il ne permet pas d'exploiter les spécificités de telle ou telle carte. Mais un logiciel gérant VESA pourra tourner sur 99,99% des cartes du marché, avec un seul pilote !!!

                      Une autre analogie peut-être plus intéressante. Je pense que tu es capable de voir des différence entre mozilla, konqueror, netscape, ie...
                      Pourtant, ils utilisent tous les mêmes "fichiers de configuration d'affichage" !
                      Et les dysfonctionnements constatés de l'un à l'autre sont dûs au fait qu'ils ne respectent pas entièrement ces standards, que certains ont voulu imposer leurs propres "fichiers de configuration" !
                      Et avec le même FORMAT de fichiers, n'y a-t-il pas des différences entre http://www.kernel.org(...) et http://http://www.oiseau-libre.net/Animaux/Animaux%20sauvages/Putoi(...) (site choisi au hasard, je n'ai pas d'actions, j'ai juste cherché un sujet un rien différent, pour essayer de faire taire ce vilain différend...)

                      Un même format, un contenu différent, un outil différent, et tout le monde se comprend ! (-ra si on tient compte du non respect actuel des standards...)

                      Je vais m'arrêter là, j'ai mal aux doigts...
                      • [^] # Re: Avec les mêmes défauts que sous Windows ?

                        Posté par . Évalué à 1.

                        n'y a-t-il pas des différences entre http://www.kernel.org(...(...)) et http://http://www.oiseau-libre.net/Animaux/Animaux%20sauvages/Putoi(...)) (site choisi au hasard

                        C'est koi ce lien en http://http(...) qui renvoie toujours au même endroit, quoi qu'on y mette après ?
                        Ce qui me surprend le plus, c'est que j'utilise FireBird, donc ce n'est pas un bug^H^H^Hune fonctionnalité du navigateur : ils sont vraiment acheté ce nom de domaine ?

                        Il faut porter plainte auprès de Verisign !
                      • [^] # Re: Avec les mêmes défauts que sous Windows ?

                        Posté par (page perso) . Évalué à 0.

                        Mais pourquoi donc ne serait-il pas possible que ces différents paramètres soient exprimés de la même manière ???
                        Tout bêtement parce qu'il n'existe pas de méthode universelle pour représenter une problématique : le fichier a plat ne convient pas pour une config arbo et qu'une représentation en arbo c'est lourd et ça ne convient pas pour tout non plus.
                        En gros, le problème c'est qu'un format unique de configuration va imposer des contraintes à tous les logiciels qui vont l'utiliser.
                        o Soit ces contraintes sont fortes et ça ne conviens pas a tous les softs :
                        - soit le programmeur n'utilise pas le systeme trop lourdingue pour son cas a lui (genre une structure plate pour une config qui se prete bien a l'arbo)
                        - soit il feinte et la config sera imbitable alors qu'un autre format l'aurait rendue très claire.
                        o Soit le format est tres souple et dans ce cas, il n'amènera rien car ce sera le bordel comme avant (à mon avis ce sera le scénario qui amènera les gens a ne pas se servir de ce machin).

                        Bref, des recommendations (genre LSB) sont nettement plus appropriées qu'une librairie de plus de parsing de fichier conf. M'enfin, les gars sont libres de coder ce qu'ils veulent hein :)
              • [^] # Re: Avec les mêmes défauts que sous Windows ?

                Posté par . Évalué à 0.

                > Peut-être pour rendre humain la tâche d'administrer des réseaux hétérogènes ?

                Je suis un humain, mon travail l'est aussi. Si tu crées un tel système, tu auras dans quelques temps des 'linux boites à clic' style M$win et 2 ans après tu verras sortir 'd'école d'ingénieur' ou de fac des adminsys qui ne sauront que ... cliquer !
                Si de tels softs/projets voyaient réellement le jour... n'importe qui pourait se dire adminsys ?! Trop facile *n?x ! ya ka cliker ! Les scripts shell ?? kezako ? la crontab ?? koikeucé ? compiler un noyau ?? un noixkoi ?

                > Pour ne pas devoir tout réapprendre pour chaque nouvelle distrib ?

                C'est ce qu'on apelle un métier ! Il faut savoir rester 'up2date' en informatique. Si tu ne réapprends pas à chaque nouvelle distrib/version/soft, tu n'avanceras jamais !

                > Pour ne pas devoir systématiquement avoir 40 pages de docs par format de
                > fichier et d'être obligé de consulter les formats à chaque modif ou presque
                > pour ne pas foirer le système ?

                Les 40 pages de doc au format texte c'est BIEN, au moins quand tu fais un grep dessus, tu n'as pas 42 milles balises xml/html... à lire en trop
                Si tu ne relis jamais la doc, tu découvriras avec horreur (au moins 1 semaine trop tard) que ce que tu as fait est catastrophique pour la boite... et pourtant, ton chef/collègue avait gentillement fait une note dans la documentation apellée "Procédure de je sais pas quoi"... oups, pas lu la doc ?!!

                > Parceque c'est plus propre ?

                Je peux me tromper mais à mon gout, c'est déjà 'propre' quand c'est fait correctement !

                > Entre autres...
                c'est toi qui vois.

                Cdlt,
                • [^] # Re: Avec les mêmes défauts que sous Windows ?

                  Posté par . Évalué à 10.

                  Ok, on y va calmement...

                  Le métier n'est pas de connaître le format des fichiers, c'est de savoir comme fonctionne une bécane, comment configurer des protocoles, des logiciels pour qu'ils fonctionnent et répondent à un besoin.

                  Ce qui importe, c'est le FOND, pas la forme. Plus la forme est simplifiée, plus on peut se concentrer sur le fond...
                  AIX s'administre à la souris. ENTIEREMENT, si on le veut. Et pourtant, on ne s'improvise pas administrateur AIX.

                  Et puis, quand bien même ? N'importe qui est capable d'administrer un système (on en est loin, je le rappelle) ? Qu'importe. Il faut EVOLUER. Les métiers changent, surtout dans l'informatique ! Au fur et à mesure que les tâches se simplifient, que la technique avance, les métiers se transforment. Connais tu beaucoup de pupitreurs ? Pourtant, ils étaient des milliers il n'y a pas si longtemps ! Il y'a 20 ans, personne n'aurait imaginé que n'importe quel péquin pourrait en 3 clics configurer un partage sur un réseau local d'un accès internet haut-débit. Pourtant, c'est le cas. Même Luce et Henri en sont capables !

                  Avant, on développait en assembleur. Maintenant, n'importe qui peut faire une petite appli en 3 clics de souris. Et alors ? N'importe qui est-il capable pour autant d'écrire un ERP ?

                  Rester à jour, ok. C'est à dire suivre les NOUVELLES technologies, pas se faire ch... à apprendre 247 façons de faire la même chose (ancienne en plus, hein !) sur 247 systèmes différents !!!

                  Je connais l'importance de la doc. Et encore une fois, ce qui importe dans la doc, c'est le FOND, pas la forme. Si les 40 pages décrivant le fond et la forme se résument en 20 pages sur le fond, la forme étand standardisée, universelle, combien de temps de gagné ? (à l'écriture du soft, de la doc, à la lecture de la doc, la configuration du soft...)

                  ET POUR LA DERNIERE FOIS DANS CE THREAD, J'ESPERE : IL N'A JAMAIS ETE QUESTION D'XML !!! On parle de texte brut, sous la forme clé=valeur, de fichiers ini, pour être clair.

                  D'ailleurs, si ta doc est dans un format donné, c'est que tu es censé avoir l'outil pour la consulter, mais bon... (et la plupart des softs ont une option "rechercher", qui peut éventuellement remplacer un grep...)

                  Allez, pour finir [mode humour]Un chef, non seulement ça n'envoie pas de doc, mais si ça en reçoit, ça ne la lit pas... Et si jamais dans un excès de bonne volonté, ça la lit... ça ne la comprend pas[/mode humour].

                  PS : Désolé d'avoir mis des "pseudo-balises". C'est presque du xml, ça. Je vais me flageller avec des ronces et des orties.

                  Bon, un peu confus tout ça, mais bon, j'espère que ça reste à peu près compréhensible...
                  • [^] # Re: Avec les mêmes défauts que sous Windows ?

                    Posté par . Évalué à -2.

                    > Ok, on y va calmement...

                    Désolé, si je me suis emporté, mais la je suis rentré de vacance depuis peu, et ca me fais ch... de devoir aider tous ces utilisateurs qui ne comprennent rien à rien (et qui ne font pas l'effort de comprendre)

                    > Le métier n'est pas de connaître le format des fichiers, c'est de savoir comme
                    > fonctionne une bécane, comment configurer des protocoles, des logiciels pour
                    > qu'ils fonctionnent et répondent à un besoin.

                    d'accord à 100%

                    > Ce qui importe, c'est le FOND, pas la forme. Plus la forme est simplifiée, plus on
                    > peut se concentrer sur le fond...
                    > AIX s'administre à la souris. ENTIEREMENT, si on le veut. Et pourtant, on ne
                    > s'improvise pas administrateur AIX.

                    toujours d'accord à 100% (vive smitty meme si des fois, ca va plus vite d'éditer les fichier à la main; HACMP rox !)

                    > Et puis, quand bien même ? N'importe qui est capable d'administrer un système
                    > (on en est loin, je le rappelle) ? Qu'importe. Il faut EVOLUER. Les métiers
                    > changent, surtout dans l'informatique ! Au fur et à mesure que les tâches se
                    > simplifient, que la technique avance, les métiers se transforment. Connais tu
                    > beaucoup de pupitreurs ? Pourtant, ils étaient des milliers il n'y a pas si
                    > longtemps ! Il y'a 20 ans, personne n'aurait imaginé que n'importe quel péquin
                    > pourrait en 3 clics configurer un partage sur un réseau local d'un accès internet
                    > haut-débit. Pourtant, c'est le cas. Même Luce et Henri en sont capables !

                    petit bémol (d'ou mon coup de gueule), meme si Luce et Henri sont capable de configurer un réseau, je ne les vois pas remonter une machine dans l'urgence avec /bin/sh et vi comme seul ami... Les outils pour aider à la configuration, c'est bien. En abuser ca craint ! La force d' *n?x réside justement dans le fait (selon moi) que pour faire fonctionner le systeme/soft, il faut le comprendre (en partie).
                    D'ou l'avantage de la doc et de la lire !

                    > ...

                    > Rester à jour, ok. C'est à dire suivre les NOUVELLES technologies, pas se faire
                    > ch... à apprendre 247 façons de faire la même chose (ancienne en plus, hein !)
                    > sur 247 systèmes différents !!!

                    et quand tu dois maintenir un oracle 7 sur un 'vieil' AIX 4.2.1 ... tu es bien content de connaitre les 'anciens' trucs.

                    >...

                    > D'ailleurs, si ta doc est dans un format donné, c'est que tu es censé avoir l'outil
                    > pour la consulter, mais bon... (et la plupart des softs ont une option
                    > "rechercher", qui peut éventuellement remplacer un grep...)

                    quand tu n'as que /bin/sh et vi qui daignent fonctionner, il vaut mieux que ca soit au format texte... ou avec des outils 'vraiement simplistes' odmget odmchange... c'est pas super :(

                    > Allez, pour finir [mode humour]Un chef, non seulement ça n'envoie pas de doc,
                    > mais si ça en reçoit, ça ne la lit pas... Et si jamais dans un excès de bonne
                    > volonté, ça la lit... ça ne la comprend pas[/mode humour].

                    mon chef ne doit pas avoir d'humour...

                    Pour résumer ma pensée, je suis contre la création de tels outils sous Linux car ils simplifient trop la vie du n00b ! :( désolé ! mais pour moi, si un jour Linux doit etre 'user friendly', c'est parce que l'utilisateur sera devenu 'Linux friend' et non pas parce que Linux se sera rabaissé à la non connaissance de l'utilisateur. Utilisateur qui sous pretexte qu'il a réussit à mettre en place son systeme/soft tout seul , pense à tord qu'il connait tout sur tout et que si sa plante, c'est parce Linux sa sux :(

                    Cdlt,
                    • [^] # Re: Avec les mêmes défauts que sous Windows ?

                      Posté par . Évalué à 4.

                      >petit bémol (d'ou mon coup de gueule), meme si Luce et Henri sont >capable de configurer un réseau, je ne les vois pas remonter une >machine dans l'urgence avec /bin/sh et vi comme seul ami... Les >outils pour aider à la configuration, c'est bien. En abuser ca craint !

                      D'accord avec ça. Mais... C'est quand même un cas extrême, qui dans un système propre et fiable ne devrait pour ainsi dire jamais arriver. Tu connais beaucoupe de *simples* utilisateurs de linux, qui travaillent sous un compte non-root qui se retrouvent dans cette situation ?
                      Si oui, alors linux a encore du chemin a faire sur le plan de la fiabilité...

                      >La force >d' *n?x réside justement dans le fait (selon moi) que >pour faire fonctionner le systeme/soft, il faut le comprendre (en >partie).
                      >D'ou l'avantage de la doc et de la lire !

                      Bof... Pour moi, la force d'un*x réside dans sa robustesse, sa fiabilité, ses performances, son respect des standards, ...
                      Si on veut que linux soit "prêt pour le desktop" (c'est pas le moment de lancer des trolls, hein !), il faut qu'on puisse l'utiliser "normalement" sans justement savoir comment il fonctionne. C'est comme ça que l'informatique est devenue grand public...

                      Je parle du cas Luce et Henri, pas de l'administration de serveurs en entreprise.

                      >quand tu n'as que /bin/sh et vi qui daignent fonctionner, il vaut >mieux que ca soit au format texte... ou avec des outils 'vraiement >simplistes' odmget odmchange... c'est pas super :(

                      Toujours pareil, on parle de cas extrêmes, réservés aux bidouilleurs, ou aux machines à utilisation avancée (serveurs, ...). Pas au PC de monsieur tout le monde. Normalement.

                      ET ENCORE ET TOUJOURS (SNIF, J'ESPERAIS NE PLUS AVOIR A LE DIRE), LE SYSTEME PROPOSE EST ENTIEREMENT BASE SUR DES FICHIERS TEXTES ! ROGNTUDJU ! DANS QUELLE LANGUE FAUT-IL LE DIRE ?! Le passage où xml est cité est pour faire de l'import-export. Ce qui est très judicieux, puisque l'aspect hiérarchique d'xml permet de récupérer la structure hiérarchique des répertoires contenant ces fichiers textes (type .ini, je le répète pour ceux qui n'écoutent pas au fond près du radiateur).

                      >et quand tu dois maintenir un oracle 7 sur un 'vieil' AIX 4.2.1 ... tu >es bien content de connaitre les 'anciens' trucs.

                      Je me plaçait dans le contexte de l'évolution future de l'informatique... C'est sûr que pour ce qui est ancien, il faudra continuer à le faire vivre tel quel jusqu'à ce que l'on en ait plus l'usage...
                      Si on arrive à standardiser les configurations, dans 10 ans, lors des évolutions logicielles, on évitera justement ce genre de problèmes, puisque toutes les applications se configurerons toujours de la même manière...

                      >Pour résumer ma pensée, je suis contre la création de tels outils >sous Linux car ils simplifient trop la vie du n00b ! :( désolé ! mais >pour moi, si un jour Linux doit etre 'user friendly', c'est parce que >l'utilisateur sera devenu 'Linux friend' et non pas parce que Linux >se sera rabaissé à la non connaissance de l'utilisateur. Utilisateur >qui sous pretexte qu'il a réussit à mettre en place son >systeme/soft tout seul , pense à tord qu'il connait tout sur tout et >que si sa plante, c'est parce Linux sa sux :(

                      C'est un avis personnel. Et discutable. Tout d'abord, cela simplifie aussi la vie de l'administrateur système expérimenté. Et si tu pense que Linuxcébienparcekecécompliké, c'est ton opinion, pas la mienne. Comme je l'ai dis, pour moi, Linux (devrais-je dire GNU/Linux ? ;)), c'est bien parceque c'est puissant, robuste, fiable, rapide, et plein d'autres qualificatifs... Et puis aussi, parceque c'est libre, "accessoirement".
                      Et si c'est simple à configurer, tant mieux. Cela facilitera le déploiement, l'augmentation de parts de marché, l'installation chez M. ToutLeMonde, ou chez ses voisins, Luce et Henri...

                      Je crois que tu confond complexité et puissance / robustesse / fiabilité. On peut faire simple et fiable et robuste et ...

                      Un utilisateur qui à réussi à mettre en place son système / soft tout seul ? GENIAL ! 2 heures de moins à passer à l'aider à le faire ! 2 heures que l'on pourra consacrer au développement de nouvelles applications, ou à tout autre activité ! Et si en croyant tout connaître , il a configuré n'importe comment, mais que les fichiers de config sont simples et claires, tu mettras d'autant moins de temps à trouver l'erreur et lui corriger son problème... Ceci étant dit, en entreprise, je ne pense pas que le monsieur devrait avoir accès aux fichiers de conf... Par contre, pouvoir propager toute une partie de la conf sur l'ensemble du parc (même avec des distribs différentes !) par un export-import de fichier, ça... Quel admin n'en rêve pas ?!

                      Enfin, dans un système censé être fiable, si ça plante, oui, sa "sux". Sinon, ça t'avertit que tu n'as pas configuré correctement...

                      Bonne journée.
                      • [^] # Re: Avec les mêmes défauts que sous Windows ?

                        Posté par . Évalué à 1.

                        ATTENTION... chipotage !
                        je m'enfonce quelque fois dans ma conn... mais c'est pour soulever des points qui me parraissent importants.

                        > D'accord avec ça. Mais... C'est quand même un cas extrême, qui dans un système
                        > propre et fiable ne devrait pour ainsi dire jamais arriver. Tu connais beaucoupe > de *simples* utilisateurs de linux, qui travaillent sous un compte non-root qui se
                        > retrouvent dans cette situation ?
                        > Si oui, alors linux a encore du chemin a faire sur le plan de la fiabilité...

                        Actuellement non, je ne connait pas beaucoup d'utilisateur dans ce cas. Mais selon tes écris, tu serais pour le Linux grand public... Plus il y aura d'utilisateurs dans ce cas, plus il y a de chance que cela arrive (je ne dis pas beaucoup de chance, mais la probabilité augmentera - certes, plus le système sera fiable mieux cela sera)

                        > Bof... Pour moi, la force d'un*x réside dans sa robustesse, sa fiabilité, ses
                        > performances, son respect des standards, ...

                        d'accord mais ...

                        > Si on veut que linux soit "prêt pour le desktop" (c'est pas le moment de lancer
                        > des trolls, hein !), il faut qu'on puisse l'utiliser "normalement" sans justement
                        > savoir comment il fonctionne. C'est comme ça que l'informatique est devenue
                        > grand public...

                        L'informatique n'est pas devenue grand public (quel pourcentage de personne sur terre a un acces à un pc ? )... c'est - malheureusement - W$ qu'il l'est devenu chez ceux qui ont un accés à un ordinateur.

                        > Si on arrive à standardiser les configurations, dans 10 ans, lors des évolutions
                        > logicielles, on évitera justement ce genre de problèmes, puisque toutes les
                        > applications se configurerons toujours de la même manière...

                        entièrement d'accord

                        > Et si c'est simple à configurer, tant mieux. Cela facilitera le déploiement,
                        > l'augmentation de parts de marché, l'installation chez M. ToutLeMonde, ou chez
                        > ses voisins, Luce et Henri...

                        encore un bémol...

                        <ma vie>
                        support utilisateur lambda : le réseau ne marche plus sur mon poste....
                        un collègue : c'est normal, vous venez de passer en dhcp il faut modifier vos paramètres réseau comme décrit dans la note...
                        lambda : ok ok, le dhcp, je connais...
                        2h plus tard 30 supports : plus de réseau sur le site xxx à 300km de nos bureaux !
                        kezako ?!? Lambda qui connait tout grace à sa boite à clic avait installé sur son poste un serveur dhcp :(
                        lambda était admin sur son poste W$ :( et il l'est toujours :(
                        </ma vie>

                        si c'est trop simple, grace aux outils de configuration (synaptic, yum, apt, up2date, yast...) il est possible d'installer ce que l'on veux sur le systeme. D'accord il faut etre root. Mais TOUS les utilisateurs lambda sont root ! Ils ont tous le password root ! c'est eux qui l'ont rentré lors de l'install :(
                        Linux4desktop OUI mais une version de Linux spécifique, où les utilisateur ne pourraient que difficilement installer des composantes requierant des connaissances spécifiques !

                        > Je crois que tu confond complexité et puissance / robustesse / fiabilité. On peut
                        > faire simple et fiable et robuste et ...

                        je ne confonds pas ;) le seul soucis et que Linux EST fiable/puissant/robuste ET complexe, il faut prendre le système dans son ensemble.

                        > ...
                        > Et si en croyant tout connaître , il a configuré n'importe comment, mais
                        > que les fichiers de config sont simples et claires, tu mettras d'autant moins de
                        > temps à trouver l'erreur et lui corriger son problème...

                        D'accord mais ... comment fait l'utilisateur lorsqu'il est SEUL face au problème ? Quand il n'a pas l'habitude de comprendre les fichiers de conf, lire la doc parce que justement, il n'en a plus besoin ?
                        Je suis pour un Linux plus simple à configurer mais il est NECESSAIRE selon moi de toujours comprendre et lire la doc avant/après avoir installé/configuré un soft.

                        > Ceci étant dit, en
                        > entreprise, je ne pense pas que le monsieur devrait avoir accès aux fichiers de
                        > conf... Par contre, pouvoir propager toute une partie de la conf sur l'ensemble
                        > du parc (même avec des distribs différentes !) par un export-import de fichier,
                        > ça... Quel admin n'en rêve pas ?!

                        Travaillant sur un réseau hétérogéne de sereurs Unix, j'en reve moi aussi ! Mais si un tel outil existait déjà, je ne passerais plus la majeure partie de mon temps à améliorer le système, à faire des scripts pour unifier nos actions sur les serveurs. Je serais réduis à lire des remontées d'erreur et à remplacer des disques/migrer des machines.... pas très réjouissant :(

                        Bonne journée à toi (et a vous tous)
                        • [^] # Re: Avec les mêmes défauts que sous Windows ?

                          Posté par . Évalué à 3.

                          Bon, allez, juste deux trois points puis on va en rester là (en fait, je pense qu'au fond on doit être à peu près d'accord...)

                          - le problème principal que tu évoques (et c'en est un), c'est que l'utilisateur lambda est souvent administrateur. Ca, c'est un problème, et ça le restera tant qu'on y fera rien. Après, le format des fichiers de conf, du moment qu'il les bidouille alors qu'il ne devrait pas... (D'ailleurs, mais je ne veux pas relancer, il est plus facile pour lui de planter la bécane en essayant d'éditer un fichier avec un formatage complexe comme un fstab par exemple, une erreur de colonne va plus vite qu'un fstype=ext3 remplacé par fstype=/dev/hdxx).
                          Bref, la gestion des droits, surtout en entreprise, c'est vraiment un problème, quelque soit le système de configuration / administration sous-jacent.
                          Pour l'utilisateur lambda chez lui, si tu prends le cas d'une mandrake par exemple, par défaut, on ne peut pas se connecter en root (en mode graphique, hein, utilisateur lambda). Ca limite déjà les risques. Certes, ça n'empêche pas le su, mais... En même temps, on ne pourra jamais protéger totalement l'utilisateur contre lui-même. Tout ce qu'on peut faire, c'est le prévenir, l'avertir en long en large et en travers. On ne pourra jamais l'empêcher de faire dd if=/dev/null of=/dev/hdxx en root...

                          - Je suis POUR la doc. A fond. Des kilomètres. Mais encore une fois, une doc de conf serait tellement plus efficace si elle décrivait seulement les paramètres, les options, et pas des formats de fichiers... Toujours la distinction entre le fond et la forme. La doc est totalement indispensable !

                          - Pour la remontée d'erreurs / changement de disques... Je ne sais pas. De toutes façons, nos métiers vont évoluer. On trouvera bien autre chose à faire... Au pire, on passera nos journées à venir troller sur linuxfr ;)
                          Mais c'est vrai, si l'informatique évolue "dans le bon sens", fiabilité, robustesse, elle pourrait presque finir par tuer l'informaticien... Une informatique autonome, qui se répare toute seule, ... C'est des projets vieux comme le monde (enfin presque), et qui est remise au goût du jour. L'informatique sans informaticiens. Enfin, il restera toujours du boulot dans le domaine applicatif, les nouvelles plateformes, et tout ce qu'on imagine pas mais qui sera là dans quelques années... C'est difficile de prédire l'avenir dans le domaine informatique, alors, y'a qu'a attendre de voir (ou agir si on a des idées !). Et puis, entre l'idée de mettre en place une conf uniforme et la suppression des admins, y'a encore du chemin à faire ! Une petite 20aine d'années au moins sans doute...
                          Et puis après, on ira s'occuper de nos patates ou de nos tomates en attendant le crash disque, et puis on ira tranquillement le changer avant de ramasser les salades :)
                      • [^] # Re: Avec les mêmes défauts que sous Windows ?

                        Posté par (page perso) . Évalué à 1.

                        " Par contre, pouvoir propager toute une partie de la conf sur l'ensemble du parc (même avec des distribs différentes !"

                        Ca, ca se developpe en bash. Mais si tu veux creer un projet de ce genre, pkoi pas, tu commences a par definir le format de tes fichiers de conf, tu fais un script qui parse le tout et qui te crée la conf pour chaque distrib, un coup de scp/rsync et c'est partie.
                        • [^] # Re: Avec les mêmes défauts que sous Windows ?

                          Posté par . Évalué à 2.

                          C'est sûr. Tout se développe.
                          Mais quand je veux faire une adition, plutôt que d'écrire un programme en assembleur, je cliques sur l'icône "Calculatrice". C'est con, hein ?

                          (Oui, enfin, pour l'adition, j'peux même me débrouiller de tête).

                          Là, on te propose du clé en main, universel.

                          #! /bin/bash
                          DISTRIB=uname -jesaispasquoi | grep toto | awk xxx | sed zzz | ...
                          case $DISTRIB:
                          Mandrake))
                          cat /etc/machin/truc/bidule | grep toto |... > ftemp1
                          cat /etc/machin2/truc/biduleX | ... > ftemp2
                          cat ftemp1 ftemp2 > MonJoliFichierExport.txt
                          ;;
                          Redhat))
                          blabla
                          blabla
                          ;;
                          ..
                          ..
                          Unenouvelledistribquejeconnaispasencore))
                          Euh ?? Ben je fais quoi ??
                          ;;
                          esac

                          -- Total : 2450 lignes. Peu fiable (est-ce que le script prend en compte toutes les syntaxes possibles de chaque fichier, ou a la moindre modif, perd-il les pédales ?). Inmaintenable. Gros boulot en cas de changement de format d'un fichier par exemple...

                          vs

                          # config -export bidule > MonJoliFichierExport.txt

                          -- Total : 0 lignes. Maintenable. Jamais de changements de format de fichier.

                          Choisis ton camp.

                          PS : Oui, je sais, j'ai mélangé la syntaxe de tous les shells existants...
                          • [^] # Re: Avec les mêmes défauts que sous Windows ?

                            Posté par (page perso) . Évalué à 1.

                            "Là, on te propose du clé en main, universel."

                            Si GNU/Linux avait été ca, j'aurais pas continué l'informatique et j'aurais arreter mes études ;)

                            Sous Suse:

                            linux:/home/gnumdk # ifup dsl0
                            dsl0
                            interface dsl0 is up

                            linux:/home/gnumdk #config -export dsl0 > MonJoliFichierExport.txt

                            Sous Debian:

                            cerelaserv:/home/bellegarde# config -import dsl0 < MonJoliFichierExport.txt

                            cerelaserv:/home/bellegarde# ifup dsl0
                            Ignoring unknown interface dsl0=dsl0.

                            et oui, les distributions sont toutes tres differentes dans leur fonctionnement et vouloir tout uniformiser est utopique.

                            Si tu veux un parc homogene, t'install une seul distribution ou tu en payes les conséquences. Passe a FreeBSD sinon :p
                            • [^] # Re: Avec les mêmes défauts que sous Windows ?

                              Posté par . Évalué à 2.

                              Les différences de config hard sont déjà un problème pour l'administration d'un parc.
                              De même, les différences de notation pour un même périphérique d'un système à l'autre en est un.
                              A quoi bon en rajouter un avec des fichiers de config différents, en termes de FORME, encore une fois...

                              On peut éventuellement imaginer un fichier de config générique, et un fichier spécifique à chaque machine...

                              Fich 1:
                              commande_xxx=yyy %INTERFACE%

                              Fich 2:
                              INTERFACE=dsl0

                              Ou encore un système de filtres en import/export, pour gérer cela de manière automatique, en identifiant tout ce qui est dépendant de la machine ?

                              Enfin, là, je balance ça au pif, sans réfléchir.

                              Et je pense que le but d'un projet tel que celui là est d'essayer de réfléchir au meilleur moyen de gérer tout ça de manière cohérente...

                              Alors, réfléchissons, ensemble, objectivement, et pourquoi pas, pondons un standard (même si ce n'est pas celui que propose ce projet, si tu considères qu'il essaye d'imposer, peut-être sans qu'il y'ait eu une vraie réflexion de l'ensemble de la communauté) ?
                              • [^] # Re: Avec les mêmes défauts que sous Windows ?

                                Posté par (page perso) . Évalué à 2.

                                Le probleme, c'est que la facon dont une Suse et une Mandrake gere la connection ADSL est aussi differente que celle dont windows et GNU/Linux gerent l'installation de logiciel.

                                Sous Suse, ils utilisent smpppd et pas sous Mandrake. Difficile de gerer en commun la conf de deux distribs quand elles n'utilisent pas les memes outils.
                                • [^] # Re: Avec les mêmes défauts que sous Windows ?

                                  Posté par . Évalué à 2.

                                  Oui et non.

                                  D'abord, il n'a jamais été question à la base d'essayer de configurer plusieurs applis différentes avec le même fichier. Et là, tu me parles d'applis différentes.

                                  Ensuite, il y'a des paramètres communs, non ? Une connexion ADSL, c'est : un périphérique, un numéro à appeler (? j'en sais rien, j'aurais l'ADSL dans 10 ans :-(), un identifiant, un mot de passe, puis (automatiquement ou non) une adresse IP, un nom de domaine, des serveurs de nom, ... Ca, c'est commun à toute connexion ADSL. Et à toute connexion réseau, quasiment, d'ailleurs.
                                  Alors :
                                  .../net/connectionxxx.txt
                                  device=
                                  dial-number=
                                  user=
                                  password=
                                  ip=
                                  domain=
                                  dns=
                                  ...

                                  Après, la manière dont le système traite ces paramètres, ce n'est pas un problème !

                                  Enfin, comme je l'ai dit, il faudrait "simplement" se mettre dans la mesure du possible "tous ensemble" et de faire une "tempête de cerveaux", afin de voir comment on pourrait essayer d'améliorer le bouzin, et de simplifier la vie de tous les jours de l'admin système comme de Luce et Henri, tout en conservant toute la souplesse et les possibilités actuelles...

                                  Et surtout, il ne faut pas partir avec des à priori négatifs en ne cherchant que ce qui posera problème ! Trouvons des solutions !
          • [^] # Re: Avec les mêmes défauts que sous Windows ?

            Posté par . Évalué à 2.

            > il s'agit d'unifier

            Je ne sais pas si c'est ce que tu veux dire, mais /etc/sysconfig n'est pas du tout fait pour unifier les distributions.
            C'est une initiative de Red Hat copié par les autres et c'est tout. Si ça donne l'impression d'unifier, c'est le hazard.
            btw, /etc/sysconfig n'a pas pour objectif de remplacer /etc/httpd/conf/httpd.conf par exemple. Ce n'est absolument pas son rôle. Je ne vais pas redire ici à quoi sert /etc/sysconfig car j'en ai "un peu marre" de le faire.

            NB : /etc/sysconfig n'est pas une norme et ne le sera pas.
            • [^] # Re: Avec les mêmes défauts que sous Windows ?

              Posté par (page perso) . Évalué à 2.

              Je parle de la conf de la distrib comme tu pourras le voir plus loin.

              La seul unification a faire serait d'utiliser la syntaxe de Suse et de faire une lib commune a toutes les distribs afin d'avoir un gconf like comme dans YaST.
              • [^] # Re: Avec les mêmes défauts que sous Windows ?

                Posté par . Évalué à 1.

                > Je parle de la conf de la distrib comme tu pourras le voir plus loin.

                Ça tombe bien :-) Il y a quoi dans /etc/sysconfig ?

                > La seul unification a faire serait d'utiliser la syntaxe de Suse

                La seul solution est d'avoir un standard.
                La partie technique est anecdotique.
                Or, comment avoir un standard qui marche dans ce domaine qui bouge beaucoup ?
                Mandrake a ajouter zeroconf, Fedora ajoute NetworkManager, Mandrake utiliser lilo, Fedora a les profiles réseau, actuellement certains utilisent plus ou moins udev, il y a devlabel, hwconf, etc...

                Sur le papier c'est "mignon" d'avoir une format unique de stockage mais ça n'avance à rien actuellement. Si une distribution utilise udev et pas l'autre, ou NetworkManager, etc...
                Je peux prendre la conf de mon compte d'evolution sous SuSE et la mettre sous Fedora. Ça marche (pour evolution)
                Par contre, c'est le niveau 0 pour l'intéropérabilité de la conf des distributions.
                Ça ne va pas changer tant que c'est un moyen pour une distribution de se distinguer, d'avancer plus vite que les autres, etc...

                Analogie :
                Fedora => Balsa
                Suse => Evolution

                Balsa et Evolution stockent la conf dans gconf mais c'est totalement incompatible. La conf Evolution est pour Evolution et la conf Balsa est pour Balsa.
      • [^] # Re: Avec les mêmes défauts que sous Windows ?

        Posté par . Évalué à 4.

        Accessoirement Windows non plus n'utilise pas un seul gros fichiers.
        Il utilise un fichier par ruche pour la partie local machine, puis 1 fichier pour la ruche de chaque utilisateur.
    • [^] # Re: Avec les mêmes défauts que sous Windows ?

      Posté par (page perso) . Évalué à 2.

      Surtout que les 2 principaux problèmes qui sont reprochés aux fichiers de configuration peuvent être résolus sans passer par une base de registre :

      ook into /etc/fstab file. Now look into /etc/modules.conf, /etc/passwd, /etc/ssh/sshd_config, /etc/httpd/conf/httpd.conf. I see here two terrible problems:


      http://registry.sourceforge.net/#needs(...)


      1. Il n'y a pas de format de fichier commun

      2. Les fichiers peuvent être situés à différents endroits selon les distributions.



      Il y a un manque de standardisation, c'est certain, mais qu'est-ce qui empêche de défnir un format/une syntaxe commune et une politique de "rangement" tout en conservant les fichiers de configuration ? Rien à mon avis.

      Pensez à l'environnement avant d'imprimer ce commentaire - Please consider the environment before printing this comment

      • [^] # Re: Avec les mêmes défauts que sous Windows ?

        Posté par (page perso) . Évalué à 1.

        Le truc bien c'est de fournir une api "centralisée" pour gerer tout ça et permettre à quelques noobs de se dépatouiller plus facilement.

        J'ai toujours les pétoches de parler de /etc/network/interfaces à un gus ( heureusement, il y a gnome-system-tools ). N'empêche que le gus va par faire un cat /proc/net/dev pour savoir s'il y a bien son interface ...

        mes 2centimes.
        • [^] # Re: Avec les mêmes défauts que sous Windows ?

          Posté par (page perso) . Évalué à 1.

          "Le truc bien c'est de fournir une api "centralisée" pour gerer tout ça et permettre à quelques noobs de se dépatouiller plus facilement."

          Gruik? En quoi une API centralisée va aider le debutant? Tu veux le faire coder en python? :)

          Apres, je pense que cela existe deja dans chez Mandrake & co. Mais tu le vois pas, et l'api est propre à la distrib.

          Mais ce truc, c'est un tueur de distribution en puissance, parce que si tout se configure de la meme facon sur chaque distrib, ou est l'interet d'avoir plusieurs distrib?

          En meme temps, on est pas obligé d'utiliser 50 distribs! Linux n'est pas un OS, une distribution GNU/Linux est un OS donc à chaque OS de choisir la facon dont il se configure :)

          Donc la question est plus à quand "Regedit GNU/Linux"? :)
          • [^] # le Registre n'est pas la distro !

            Posté par (page perso) . Évalué à 2.

            Je m'exprime mal par centralisé, je veux plutôt dire uniformisé, aux moins dans l'accès.

            effectivement, l'API ne vas pas aider le noobs, mais parcontre, si Gnome, KDE, etc. fournissent un seul utilitaire permettant d'éditer le maximum de config, ça aiderai le noobs.

            vi et emacs ne sont pas accessible au noobs ! ( aucun des deux n'enregistre au Ctrl + S ).

            Ce n'est pas un tueur de distribution, les distributions ne vivent pas grâce aux foutoir dans etc, ce n'est pas l'arborescence d'etc qui m'a fait choisir debian[déconne], c'est parce que je suis un esprit supérieur :P[/déconne]

            LR ne va pas changer le contrat social de debian, ni les bogues de Mandrake et encore moins la lenteur de la compilation d'une gentoo sur PII 350 ... :)
  • # N'importe

    Posté par (page perso) . Évalué à -10.

    Nawak !
  • # ?? Pourquoi changer ??

    Posté par . Évalué à 6.

    L'organisation en fichier de configuration est simple et clair ....
    L'utilisation d'un registre simplifierait quoi ? Pas la vie de l'utilisateur, je ne pense pas.
    Un avantage des fichiers de configuration est les commentaires ....
    La possibilité de changer de configuration sans perdre l'ancienne ('#') ...

    Si le projet aboutis, j'espère que le registre de Linux sera plus lisible et moins bordelique que celui des systèmes Windows. Mais surtout qu'il n'handicapera l'utilisateur dans la modification de sa configuration Logicielle.
    L'organisation du registre doit être vraiment bien faite pour qu'il soit efficace. Et doit pouvoir être suffisamment réfléchie pour permettre des évolutions futures.

    Je ne vois pas trop l'intérêt d'utiliser un registre. Pour moi l'utilisation de fichiers de configuration est un gros avantage de Linux sur Windows du coté de sa paramétrisation.
    • [^] # Re: ?? Pourquoi changer ??

      Posté par . Évalué à 5.

      Lis un peu le descriptif du projet : il n'a pas les inconvénients du registre windows ( le nom du projet est sans doute maladroit d'ailleurs ). Le principe est plutot de garder l'avantage du systeme linux en comblant ses faiblesses : son manque d'homogéneité.
      • [^] # Re: ?? Pourquoi changer ??

        Posté par (page perso) . Évalué à 5.

        >le nom du projet est sans doute maladroit d'ailleurs

        C'est vrai pourquoi registre ? Ça n'a finalement rien à voir et ça évoque forcement de mauvais souvenirs.
        • [^] # Re: ?? Pourquoi changer ??

          Posté par . Évalué à 4.

          un coup d'oeil à la news...

          "Le nom lui-même de "registry" est susceptible de changer. Il a été choisi pour permettre de situer le but du projet mais les auteurs sont à la recherche d'un nouveau nom, ouverts aux propositions."
      • [^] # Re: ?? Pourquoi changer ??

        Posté par . Évalué à 3.

        > le nom du projet est sans doute maladroit d'ailleurs

        Un peu comme est maladroite l'interface du gconf-editor, trop proche de regedit pour que les ex-windowsiens n'associent pas gconf à LA base de registres.
  • # SUIVEZ LES LIENS NON D'UNE PIPE !!!

    Posté par (page perso) . Évalué à 8.

    Au lieu de troller comme des gorets, allez lire l'interview et vous comprendrez que ça n'a rien à voir avec la base de registre de Windows. Le nom est pourri et l'auteur le sait mais l'idée est excellente.

    Je rappelle que c'est la journée du CAPS LOCK alors BONNE FETE A MON VOISIN DU DESSUS http://www.zedeathtouch.net/zdt/numero_8/page_4_syspage_1.htm(...) /o\

    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

    • [^] # S/NON/NOM/

      Posté par (page perso) . Évalué à 1.

      PARDON :)

      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: SUIVEZ LES LIENS NON D'UNE PIPE !!!

      Posté par . Évalué à -4.

      OK Pourquoi JE PEUX PAS plusser ( ou moinsser) aux commentaires qui ont -10 (ou +10). C'est n'importe quoi.

      On ne vote qu'une fois à un commentaire c'est bien mais ça a toujours été nul le système de vote de DLFP
      • [^] # Re: SUIVEZ LES LIENS NON D'UNE PIPE !!!

        Posté par . Évalué à -2.

        moué

        Je suis un kadreg en puissance !

        gloire à kadreg
      • [^] # Re: SUIVEZ LES LIENS NON D'UNE PIPE !!!

        Posté par . Évalué à 1.

        Pour éviter les débordements, on ne peut pas noter un commentaire dont la note a atteint -10 ou 20.
        • [^] # Re: SUIVEZ LES LIENS NON D'UNE PIPE !!!

          Posté par . Évalué à 1.

          J'ai fait une erreur : On ne peut pas intéressanter (+) un commentaire à 20 et désintéressenter (-) un commentaire à -10. Il vaudrait d'ailleurs mieux bloquer tout court les votes en atteignant ces valeurs pour éviter les effets de yoyo qui modifient les XPs-qui-n'existent-plus.
  • # Ca existe déjà...

    Posté par . Évalué à 4.

    Il y a déjà GConf pour ça?! Bon ok, c'est que pour les programmes gnome mais je pense que ça peut être facilement adaptable à tous les programmes. Et puis, sinon, je trouve l'idée plutôt bonne (si la réalisation est meilleure que la base de registre de Windows), ça permettrait de se débarasser de tous les fichiers du répertoire /etc et d'unifier les fichiers de configuration entre les différentes distributions.
    • [^] # Re: Ca existe déjà...

      Posté par . Évalué à 4.

      Gconf est (plutôt) bien pour Gnome mais a aussi des inconvénients pour l'utilisation pour tout le système :
      - utilisation d'un démon (gconfd) qui devrait être lancé très tot
      - fichier xml : ce n'est pas très lisible pour un humain donc pas facilement modifiable en cas d'urgence (boot de secours avec seulement sh et vi)
      • [^] # Re: Ca existe déjà...

        Posté par (page perso) . Évalué à 3.

        > - fichier xml : ce n'est pas très lisible pour un humain donc pas facilement
        > modifiable en cas d'urgence (boot de secours avec seulement sh et vi)

        L'interface dispo pour l'humain est soit graphique soit en texte XML d'après ce que j'ai compris des liens. Ça ne change rien de ce coté là
        • [^] # Re: Ca existe déjà...

          Posté par . Évalué à 1.

          J'ai pas trouver le man qui explique les options du fichiers.
          Le probleme c'est qu'on sait pas a quoi correspondent les options.
      • [^] # Re: Ca existe déjà...

        Posté par . Évalué à 3.

        utilisation d'un démon (gconfd) qui devrait être lancé très tot

        Le problème de n'avoir pas de démon c'est pour gérer les modifications. Si une appli modifie quelque chose (genre le proxy http) les autres ne sont pas informées. Il faut forcer les applis qui tournent à recharger leur config.

        fichier xml : ce n'est pas très lisible pour un humain

        Mais c'est bien pratique pour stocker des configs complexes. Avec un système clé - valeur on ne va pas très loin. Et pour ce qui est des réparations d'urgence, rien n'empèche de créer un outil de config en Ncurses. De nombreuses distributions proposent des outils graphiques qui peuvent aussi tourner en mode texte (Anaconda, si je ne m'abuse). L'avantage d'xml c'est que c'est lisible facilement par une machine (sans problèmes de big/little endian) et que ça reste compréhensible par un humain. C'est un compromis.
        • [^] # Re: Ca existe déjà...

          Posté par (page perso) . Évalué à 2.

          Je crois que le fait de vouloir utiliser un fichier par couple clé/valeur c'est de pouvoir utiliser FAM en guise de démon pour prévenir les applications.

          Après je ne sais pas si c'est bien ou pas. Je n'y ai pas réfléchi et je ne connais pas l'existant (gconfd, ksysoca,..)

          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: Ca existe déjà...

          Posté par (page perso) . Évalué à 4.

          > Mais c'est bien pratique pour stocker des configs complexes.

          Et t'as des exemples de config sufisamment complexes pour qu'elles ne puissent pas etre stockes sous forme de cle/valeur + section. Pour info, toutes les applis KDE utilisent ce systeme, ainsi que toutes les applications windows (la base de registre n'est qu'une suite de sections avec des cles et des valeurs). Si ca suffit a toutes ces applications, je pense que c'est suffisant.

          Le xml, c'est bien mais faut pas en abuser.
          • [^] # Re: Ca existe déjà...

            Posté par (page perso) . Évalué à 2.

            > Le xml, c'est bien mais faut pas en abuser
            J'ai l'impression que le XML c'est parfait pour les "donnees" elles memes, genre le format d'OpenOffice, SVG ect... mais pas pour les fichiers de conf.

            > Et t'as des exemples de config sufisamment complexes pour qu'elles
            > ne puissent pas etre stockes sous forme de cle/valeur + section ?
            Je suis pas un specialiste des fichiers de conf, mais il y en a qui contiennent des if else par exemple, pourrait on reproduire cela sous forme de cle/valeur ?
            • [^] # Re: Ca existe déjà...

              Posté par . Évalué à 3.

              Je suis pas un specialiste des fichiers de conf, mais il y en a qui contiennent des if else par exemple, pourrait on reproduire cela sous forme de cle/valeur ?
              ====
              Si ton fichier de '''configuration''' a besoin d'être http://fr.wikipedia.org/wiki/Turing-complet(...) , il y a de bonne chanches que quelquechose cloche dans le design de ton logiciel (n'est-ce pas sendmail, emacs et autres ? ;-).
              • [^] # Re: Ca existe déjà...

                Posté par . Évalué à 3.

                Bon Dieux !

                if else ne suffit pas à être turing complet.

                Si on parle d'alternative de configurations, (équivalent d'un if else) bon nombre de logiciels en ont besoin dans leur fichier de conf et le minimum vital est donc de supporter ca.

                Le système m'a l'air correct pour les besoin basique, du style mémorisation des préférence d'une appli graphique, mais il ne tiendra pas le coup pour des configurations de serveurs ou de logiciels de bases, qui on besoin d'énorme souplesse hétérogène dans les spécificités de leur config selon le type du programme (structuration, alternatives, reglage de comportement dynamique selon les entrées, etc...). Le problème c'est hormis pour de la reprise sur crash une fois tous les 20 ans, il n'y a pas besoin de trifouiller à la main ou depuis une appli tierce les preferences d'une appli graphique.

                Dès lors l'interet s'effondre vraiment à mon gout.

                Et puis pour que ca marche, il faudrait que tous les developpeurs se mettent massivement à l'utiliser, chose qui n'arrivera pas, alors bonne idée ou pas ca risque bien de faire un flop.
    • [^] # Re: Ca existe déjà...

      Posté par (page perso) . Évalué à 9.

      > Il y a déjà GConf pour ça?

      http://freshmeat.net/projects/registry/(...) :


      GConf problem is not exactly his XML backend. Most critical are:

      - It is a daemon, so if it dies you loose your configurations.
      - It is completelly dependent on high-level Gnome libs (look here) which makes it not usable for early boot stage programs.
      - GConf was not designed for security
    • [^] # Re: Ca existe déjà...

      Posté par . Évalué à 2.

      Je ne crois pas que GConf soit réservé aux programmes Gnome. Déjà, il n'utilise rien de spécifique à gnome (du moins pour la partie daemon) et il est prévu d'ajouter le support d-bus (http://www.gnome.org/projects/gconf/plans.html(...)) ce qui permettrait une intégration avec d'autres environnement comme KDE
      • [^] # Re: Ca existe déjà...

        Posté par . Évalué à 1.

        Mais KDE a aussi sa propre "base de registre" (KConfigXT). Registry est plus bas-niveau et n'a pas pour but de les remplacer, mais d'être un back-end pour ces derniers.
  • # Et /etc, et /etc/sysconfig ?

    Posté par (page perso) . Évalué à -8.

    Je trouve le système actuel largement satisfaisant mais probablement améliorable. Je ne vois pas pourquoi regrouper une config dans une base unique. Le système /etc est pratique car ouvert : une config->Un fichier texte, bien souvent très documementé. Pour le système, /etc/sysconfig, qui lui mériterait d'être standardisé.
    Pour les configs perso, un .xxx dans son $HOME.

    Ce qui me fait peur avec une registry unique, c'est justement qu'elle est unique. Si elle est corrompue, tout est corrompu et c'est la merde. Alors q'un simple fichier texte, on s'en sort... Les types qui ont inventé ça n'ont jamais utilisé Windows ?
    • [^] # Re: Et /etc, et /etc/sysconfig ?

      Posté par (page perso) . Évalué à 9.

      Les types qui ont inventé ça n'ont jamais utilisé Windows

      Peut-être mais au moins ils savent lire.

      (Je sens que je vais me faire tuer ;)

      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: Et /etc, et /etc/sysconfig ?

      Posté par (page perso) . Évalué à 5.

      Même réponse qu'aux autres : va lire les liens ! (Je sais de quoi je parle, moi aussi, je me suis planté...).

      Ce n'est pas un fichier unique qu'ils ont prévu de faire, mais plutôt une hiérarchie et une syntaxe bien défini. Mais tout cela sera toujours dans plusieurs fichier texte, voire plus qu'avant. Un des exemple donné concerne la carte vidéo : on aura plus besoin d'aller chercher quel carte est sur le système dans la ligne tant du fichier XF86Config, mais dans le fichier XFree/Device/Videocard0/Driver.

      On garde ainsi la sécurité de fichiers de conf éclatés (tout ne peut pas être corrompus d'un coup) et de fichier de conf en texte, donc éditable à la main en cas de besoin, mais on gagne en homogénéité, ce qui permettra de plus facilement intégrer des applications différentes.
    • [^] # Re: Et /etc, et /etc/sysconfig ?

      Posté par . Évalué à 2.

      On en remet une couche, mais ça serait gentil de lire un peu plus attentivement la news, les liens qui vont avec et les différents commentaires qui ont déjà tordu le coup à ce troll poilu:

      - il n'a jamais été question de stocker tout dans un seul fichier, bien au contraire. Pas de risque de tout corrompre justement.
      - tout est stocké dans de nombreux fichiers TEXTE éditables à la main s'il le faut.
      - ça défini une syntaxe unique pour toutes les applications et un emplacement des fichiers de conf indépendant de la distrib. Le terme base est également mal choisi. Aucune base de données là dedans, ça utilise le système de fichier. Une sorte de /etc bien hierarchisé et utilisant une même syntaxe partout quoi.

      Donc RIEN à voir avec l'immonde base de registre de Windows.
    • [^] # Re: Et /etc, et /etc/sysconfig ?

      Posté par . Évalué à 4.

      le liens sur l'interviex est tres bon. Il est dit deux choses interessantes a mon avis:
      1) il n'y a pas qu'un seul fichier comme ds Windows mais plusieurs
      2) les fichiers auraient le même format
      3) les fichiers restent editables a la main

      Je trouve le point 2) tres bien tu prends par exemple aujoud'hui fstab et XF86Config-4 il ils ont des syntaxes radicalement différentes

      donc il y a encore les avantages qu'il y a aujodu'hui cités au dessus mais tout en apportant des amélioratins vraiment intéressantes

      Mais le nom est trompeur ( comme dit ds l'interview)
      • [^] # Re: Et /etc, et /etc/sysconfig ?

        Posté par . Évalué à 4.

        Moi ça ne me choque pas que fstab et XF86Config-4 n'est pas la même syntaxe.
        La richesse de Linux vient de sa grande diversité, vouloir imposer une syntaxe commune aux fichiers de conf me semble plus être la création d'un carcan qu'autre chose.
        La syntaxe permettra-t'elle de couvrir les besoins de toutes les applis, permettra-t'elle de créer des fichiers de conf plus lisibles que les actuels j'en doute. Un fstab est très lisible, un XF86Config-4 également, pourquoi changer?
        • [^] # Re: Et /etc, et /etc/sysconfig ?

          Posté par (page perso) . Évalué à 2.

          Moi ca me gene. Je ne vois pas l'interet d'apprendre une syntaxe par application. A chaque fois que je modifie lilo.conf, j'ai besoin de la page de man. Puis apres c'est ddclient, puis encore une autre pour apache et encore une autre. Heureusement qu'elles se ressemblent deja beaucoup. Seules quelques rares applications tres evoluees ont besoin d'une syntaxe tres specifique (genre mon filtrage du mail avec plein de criteres differents et plein d'actions possibles).
    • [^] # Re: Et /etc, et /etc/sysconfig ?

      Posté par (page perso) . Évalué à 3.

      Bon alors je me réponds à moi-même. Les docs, j'ai lu, merci. Vous n'avez pas compris le sens de mon message. Pour moi malgré la présence de plusieurs fichiers ça reste une repository unique, de même structure...

      De plus, contrairement à ce qu'on me dit, oui c'est codé en conformité (API) Posix, mais il est bien indiqué Registry for LINUX ! Si je prends Apache, je mets sa config dans cette base hiérarchisée. Il faut que le module de conf Apache puisse relire cette config. Idem pour Samba, Sendmail, le DNS, etc, etc. Vous croyez que les mainteneurs /développeurs vont recoder leur module pour ça ? A la rigueur ils vont proposer (ou quelqu'un autre) une moulinette registre->fichier de conf, et on retombera dans les mêmes travers.

      En tout cas ça ne se fera pas en un jour. L'autre problème, c'est que les Linuxiens vont s'habituer à cette base hiérarchisée, et quand il faudra reconfigurer, hmmm, Samba sur un True64 sans cette base, bah il faudra replonger dans les docs.

      J'espère avoir été plus clair.
      • [^] # Re: Et /etc, et /etc/sysconfig ?

        Posté par . Évalué à 3.

        Si je prends Apache, je mets sa config dans cette base hiérarchisée. Il faut que le module de conf Apache puisse relire cette config.

        Les deux systemes peuvent cohabiter sans probleme. Libre aux developpeurs de rendre leurs fichiers de conf compatible avec "registry" ou non.
        Et il va bien y avoir des gens qui vont faire des patchs pour ca, non ? Ne jamais negliger les perfectionnistes qui savent programmer :)

        quand il faudra reconfigurer, hmmm, Samba sur un True64 sans cette base

        Ou porter la bibliotheque sur Tru64 afin de pouvoir lire ce fichier de conf, ce qui est peut-etre plus simple. Et porter cette bibliotheque sur d'autres systemes n'implique pas forcement de rendre tout le systeme conforme a la "registry". Du coup, pour apache sur Tru64, apres, comme la bibliotheque sera deja portee, aucun pb :)

        Le bonjour chez vous,
        Yves
  • # Quelle horreur

    Posté par (page perso) . Évalué à -7.

    Quelle horreur, mais pouquoi pas : tout ce que j'espère c'est que je n'ai pas ça dans ma distro préférée.... On a vu la merde infernale que ça pouvait donner sous ms-windows : trop lourd, trop complexe pour etre humainement compréhensible, trop fragile : la moitié des applications font des redondances d'information dans la base de registres à cause de ces caractéristiques (sans compter celles qui utilisent encore leur .ini). Du coup, elle s'en rend inutile.

    Bref, pourquoi pas s'il y en a qui aiment, mais je n'utiliserais pas ça chez moi.
    • [^] # Re: Quelle horreur

      Posté par (page perso) . Évalué à 4.

      Tsss, ne jamais dire Fontaine, je ne boirai pas de ton eau :-)
      L'exemple IBM/AIX montre que quasiment tous les admins AIX passent par SMIT.
      A la lecture du projet, c'est vraiment calqué dessus. Si l'outil de manipulation peut aussi tourner en mode texte, ça sera parfait :-)
      • [^] # Re: Quelle horreur

        Posté par (page perso) . Évalué à 2.

        lit le sxi ou la doc, tu verra que tu peut exporter, importer, "set" et "get" via la ligne de commande

        rg set system/sw/XFree/Screen/Display/Modes 1280x1024

        au lieu de
        emacs -nw /etc/X11/XF86Config-4
        ....
        ( ou pire : dpkg-reconfigure xserver-xfree86 !! )
      • [^] # Re: Quelle horreur

        Posté par . Évalué à 1.

        Oui , mais smit n'est qu'une interface qui lance des commandes systemes comme adduser,... et recupère les infos de la même facons sans ecrire directement dans les fichiers de config mais en utilisant les commandes du systemes prévu pour cela.

        Pour prendre exemple, si tu ajoute un champs dans un fichier de config, tu dois juste modifier ton programme mais pas le programme de config externe (qui ne t'appartient pas) qui va ecrire dans ton fichier de config.

        C'est juste un avis parmi tant d'autres.
        En même temps, ca simplifie et on a pas de Xconfig,Xconfigurator,KdeConfig,Swat,smb4K qui font la même chose.
        Ce serait bien qu'il y ait qu'une application mais qui marche avec plug-in (j'install Samba, j'ai le plug-in samba pour "registry" et un menu en plus dans l'outils comme centre de controle Mdk et le drake-wizard mais en plus puissant).
      • [^] # Re: Quelle horreur

        Posté par (page perso) . Évalué à 1.

        Beh disons que jusqu'ici, les admins que je connais qui utilisent les outils de config fournis par le distributeur sont incapables de s'en sortir sans, tellement ils ont perdu l'habitude de se débrouiller par eux mêmes. Le temps et la fénéantise aidant, ils en viennent même à oublier les concepts de base de leur config. Alors ok, c'est chiant les fichier textes mais au moins tu es obligé de savoir ce que tu dois faire.
        Pour moi, LE problème d'un outil de ce type (outre la question qu'on peut se poser sur son utilité, cf la base de registres de windows dont j'aimerais savoir ce qu'elle a apporté a windows hormis une dimension shamanique dans la configuration) est la transformation des fichiers de config qui tendent à devenir humainement incompréhensibles. En soit, ce n'est pas génant tant que le programme de gestion du machin ne perd pas les pédales (hohoho) ou tant qu'il est utilisable en mode dégradé (re-hohoho).
        Ce que mon expérience (faible, certes) met en évidence c'est : quand ça part en sucette, le seul moyen simple de récupérer c'est "format / reinstall", ce qui n'est pas le cas des bon gros fichiers textes.
  • # mais encore...

    Posté par . Évalué à 7.

    L'avantage n'est pas forcement a court terme. En effet, comme un application est de toute facon linke avec libregistry, ca faciliterait enormement la gestion de parc. Un mix de rendez et registry avec un backend LDAP/SQL/XML-RPC (non je deconne :p), offrirait une reelle alternative a windows dans la gestion de parc de workstations.
  • # linuxfr est à la bourre pour ce troll là ;)

    Posté par . Évalué à 6.

    Y a eu des débats au sujet de ce linux registry sur la mailing list de freedesktop.org y a qques mois, voir http://freedesktop.org/pipermail/xdg/2004-April/003753.html(...) et le thread qui s'ensuit par exemple.
    En gros, linux registry n'est pas approprié pour être utilisé tel quel dans un desktop environment, et en ce qui concerne tous les démons systèmes, il apporte si peu d'avantages (voire même aucun) que c'est pas super intéressant de se prendre la tête à migrer tous les fichiers de config de tous les démons (apache, postfix, ...) vers ce système...
    En bref, y a guère que l'auteur de ce linux registry et qques autres personnes qui sont convaincues que c'est un projet intéressant pour le monde du libre.

    A mes yeux, avoir un gconf qui utiliserait par exemple dbus pour la communication entre le démon et les applis et serait utilisé par toutes les applis "desktop" (ie adopté par kde, rox, ...) est autrement plus intéressant
  • # Et defaults sous GNUstep...

    Posté par . Évalué à 9.

    Y'a un truc sous GNUstep qui s'appelle defaults et qui fait ça, et très bien...

    Dans defaults, chaque application a un domaine dans lequel elle peut écrire des couples clef/valeur et il y a un domaine global pour l'ensemble des applications...

    Deplus un programme en ligne de commande, qui s'appelle (très original) defaults permet de lire, écrire dans les fichiers.

    Pourquoi réinventer la poudre...
  • # Maj

    Posté par (page perso) . Évalué à 4.

    Hmm, sympa ce truc quand même.
    Un des inconvénients que je vois, c'est que ça va être la folie dans les distributions en développement (unstable, cooker, rawhide) quand il va falloir mettre à jour ce package...
    J'espère que ce sera pris avec autant de précautions qu'une upgrade de la glibc, parce que si y'a un problème dans le futur-ex-registry, ça va être la fête dans le système...
    • [^] # Re: Maj

      Posté par . Évalué à 1.

      dans ce cas là, je ne voit pas trop le probléme.
      Ajout de la librairie libregistry.so (ou autre nom) puis installation de kmail (par exemple) qui va checker si il y a des clé dans la registry et s'il n'y en a pas, recuperer dans le $HOME.kde/application/.kmail pour les importer dans la registry.

      D'ailleurs, pour kde, il y a plein de fichier de config partout et on y perd vite son latin (selon l'application).

      Ensuite, tu aura les applications qui vont utiliser la registry et les autres qui vont continuer à travailler comme avant avec leurs fichiers de config.
      • [^] # Re: Maj

        Posté par (page perso) . Évalué à 2.

        Mais ça pourrait être plus complexe :
        Kmail fait un appel à libregistry qui lui retourne une valeur erronée,genre, pas dans le bon encodage, ou je sais pas trop quoi. Les possibilités de bugs sont infinies :)

        Toutes les applis sur le système peuvent ouvrir un fichier texte en lecture, y'aura pas de bugs à priori (sauf si bug dans la libc, quoique j'y connais pas grand chose). Avec une couche entre les deux, couche qui n'est pas forcément très simple, on ajoute un niveau pratique d'abstraction, mais on ajoute aussi des bugs potentiels.

        Bon, c'est pas la mort hein, faut pas que la peur du bug empêche d'avancer, mais il faut juste prendre ses précautions et faire attention quand on travaille sur du potientiellement instable.
        • [^] # Re: Maj

          Posté par . Évalué à 1.

          Si tu as un bug dans libc, aucun programme qui est lié à libc (fonction read/write/fgets/fputs) ne marchera. Donc ton programme plantera quand même.

          Au niveau des précautions, c'est pareil pour toutes les librairies et c'est justement parce qu'on est sur un OS libres avec les sources que tu peux detecter plus facilement et rapidement les erreurs.

          bon, ben --->[]
    • [^] # Re: Maj

      Posté par . Évalué à 4.

      Un des inconvénients que je vois, c'est que ça va être la folie dans les distributions en développement

      C'est surtout l'utilisation du système par les distributions qui va poser problème, je pense. Aujourd'hui chacune fait un peu ce qu'elle veut avec es fichiers de conf, les répertoires d'installation (/opt), etc. Qu'est ce qui va les empêcher de continuer avec ce système ? Si RH met la config apache dans "software/server/httpd", Suse dans "software/apache" et MDK dans "software/services/webserver" on est dans la même merde qu'aujourd'hui.

      Il me semble que Registry prend le problème à l'envers. Pour proposer un interface commune de configuration il faudrait déjà un accord de principe entre les principales distributions sur ce point. Mais créer un nouvel outil dans son coin et penser que tout le monde va l'adopter me parait utopique.
  • # Clé/valeur ?

    Posté par (page perso) . Évalué à 4.

    Ça m'étonnerait que tous les logiciels puissent se contenter d'un système à base de clé/valeur pour leur conf.

    Apparement ils proposent une espèce d'arborescence pour les noms de clé, mais ça reste assez limité non ?
    • [^] # Re: Clé/valeur ?

      Posté par (page perso) . Évalué à 2.

      Clairement, pour apache, ce sera dur
      • [^] # Re: Clé/valeur ?

        Posté par (page perso) . Évalué à 1.

        non , au contraire ! expliques-toi !

        Apache utilise une config clé-valeur ( contrairement à emacs, fvwm, etc )
        • [^] # Re: Clé/valeur ?

          Posté par (page perso) . Évalué à 2.

          Je me permets de répondre.

          Bien sûr, apache utilise une configuration clé/valeur, mais avec différents niveaux d'imbrication, et des clauses conditionnelles.

          Je ne sais pas si LR supporte ce genre de choses de manière simple.
          • [^] # Re: Clé/valeur ?

            Posté par (page perso) . Évalué à 1.

            effectivement, j'avait oublié les conditions, mais justement, il n'y a pas de "dépendances" des valeurs ( ça devient compliqué ! ) ?
          • [^] # Re: Clé/valeur ?

            Posté par (page perso) . Évalué à 2.

            Je ne peux pas te plusser, mais c'est effectivement ce que je voulais dire.
          • [^] # Re: Clé/valeur ?

            Posté par . Évalué à 1.

            Je me plante peut être mais on pourrait pas simuler les conditions par :

            Cond1.valeur = bidou
            NonCond1.valeur = toubidou ?
            éventuellement par une arborescence ?
            • [^] # Re: Clé/valeur ?

              Posté par (page perso) . Évalué à 1.

              Ou bien un yesno à la racine d'un dossier et les options enfants ne seront pas interprêter si c'est no

              m'enfin, c'est pas une condition, c'est pas dynamique.
    • [^] # Re: Clé/valeur ?

      Posté par . Évalué à 1.

      Cela est limite, mais en theorie, la grande majorite de ce qui necessite un outil de configuration peut se contenter d'un systeme clef=valeur. Le fait de rajouter une arborescence clarifie l'ensemble et facilite sa lecture.

      Et il y aura forcement des cas ou cela ne suffira pas. Des cas ou il faudra faire un truc a part. Qui connait des cas de ce genre ?

      Le bonjour chez vous,
      Yves
      • [^] # Re: Clé/valeur ?

        Posté par . Évalué à 1.

        la grande majorite de ce qui necessite un outil de configuration peut se contenter d'un systeme clef=valeur

        Un outil de configuration utilisé par la moitié des applications ne sert à rien.
        Il faut qu'il soit utilisable et utilisé par toutes les applications, même les plus complexes.

        Le fait de rajouter une arborescence clarifie l'ensemble et facilite sa lecture.

        Ouet, t'as dejà utilisé regedit sous Windows, y'a de l'arborescence mais j'ai jamais rien vu de moins clair.
        Clairement, l'arobrescence n'ajoute pas de clareté mais des possibilités quand aux infos sauvées. Par exemple, on pourra sauver les informations de plusieurs compte mail en créant une arborescence par compte, c'est tout.

        Pour que ce soit claire, chaque application devra posséder une sous arborescence à son nom, et utiliser des clefs avec des noms très explicites.
        • [^] # Re: Clé/valeur ?

          Posté par . Évalué à 2.

          > utiliser des clefs avec des noms très explicites
          Plus simple à dire qu'à faire. Le nerf de la guerre sous Unix, ça reste quand même la documentation. C'est d'ailleurs aussi un des plus gros problèmes de Windows : 95% des clés ne sont pas documentées, pire : le système ne permet même pas d'insérer des bouts de commentaires histoire d'avoir un apperçu des l'effets de bord possibles (le petit détail qui tue et qui fait passer les gens pour des idiots).

          Même si beaucoup d'admin/utilisateur, provenant d'horizon clickodromesque, trouvent que ça ressemble à de la bidouille, le fait que les fichiers de configurations soient commentés pour la plupart des outils (apache, samba, etc ...) est appréciable : on n'a pas à se farcir une documentation de 500pages indigestes, mal traduites, non à jour, qui se perd facilement, qu'on installe jamais ou qui n'est plus accessible (qui est le gros nul qui vient de toucher à la configuration de la passerelle ?).

          Se retrouver avec des clés du genre "DaPlugin="<insert x86 binary code here>" (je caricature là, quoique pour sendmail ...) et privé du moindre commentaire (et en privilégiant la loie de Murphy : toutes fonctionnalités nécessaires à la résolution d'un problème ne sont pas documentées), on se retrouvera au final dans le même cas que Windows (avec une architecture plus robuste, cela va de soit).

          Je crains que ce système, du fait qu'il sera centralisé, tende les programmeurs à écrire encore moins de doc qu'actuellement.

          Je serais plutôt enclin à respecter une arborescence standardisée, c'est vrai qu'avoir 150 fichiers .* dans mon répertoire personnel, ça fait plutôt style neuneu, 2 ans, ne connait pas encore la commande mkdir (ou me rappelle le répertoire C:\windows). Et accessoirement, ça s'implémente avec un moindre mal.
          • [^] # Re: Clé/valeur ?

            Posté par (page perso) . Évalué à 4.

            Je crains que ce système, du fait qu'il sera centralisé, tende les programmeurs à écrire encore moins de doc qu'actuellement.

            Et si les choses devenaient plus simple pour les distributions, grâce à la standardisation (plus besoin d'un deb ou d'un rpm par distrib) ? le rôle de celles-ci pourrait être de mieux vérifier la cohérence des outils proposés ainsi que de vérifier la qualité de la documentation et de la localisation, non, quitte à relancer les programmeurs ?
    • [^] # Re: Clé/valeur ?

      Posté par . Évalué à 1.

      Ça dépend de ce que "valeur" peut contenir...

      Si valeur peut contenir des listes, tout devrait être à peu près possible...
  • # Moi je trouve que c'est une bonne idée

    Posté par . Évalué à 5.

    tous ceux qui disent qu'une configuration à base de fichiers est tiptop... et bien c'est que c'est des nerds qui passent leur vie à les manipuler ces fichiers et donc forcement ils arrivent à savoir où ils sont tous, dans lequel il faut modifier tel ou tel parametre pour avoir tel effet...
    mais ce systeme est aberrant pour un utilisateur lambda, et les outils de configurations sont trop differents d'une distrib à une autre ( j'ai une debian, et mes potes sont plutot mandrake/fedora, du coup, je peut pas les aider quand ils ont une couille parceque ... )
    de plus linux manque enormement d'homogénéite et d'outils de ce types qui peuvent simplifier le developpement, la configuration, et surtout les outils qui permettent une configuration simple et efficace, sans forcement avoir à lire 36000 howtos ( c'est marrant au début, mais apres c'est chiant, et alors on nous dis tout le temps RTFM, mouais :\ )
    bref, une idée à creuser je trouve ! ( ça en est à quel stade ? j'ai pas trouvé sur le site ... )
    • [^] # Re: Moi je trouve que c'est une bonne idée

      Posté par (page perso) . Évalué à 1.

      tous ceux qui disent qu'une configuration à base de fichiers est tiptop...

      ...mais ce systeme est aberrant pour un utilisateur lambda, et les outils de configurations sont trop differents d'une distrib à une autre

      Le but de ce projet est justement de conserver la possibilité de changer la configuration à la main en éditant des fichiers mais en ayant une homogénité du format, des API d'accès et des outils pouvant permettre l'accès à cette configuration.

      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: Moi je trouve que c'est une bonne idée

      Posté par . Évalué à 0.

      Je le pense aussi.

      J'ai longtemps pensé le contraire en fait, en voyant les m... qu'engendrait un windoze tout cassé (au point que le 1er truc que je faisais après une install était de sauvegarder user.dat et system.dat).

      Mais le pb est là :
      - avoir un "vrai" panneau de config universel (graphique ou toute autre nouvelle idée) sera une illusion tant que le système actuel perdurera. Ou plutôt même s'il existait il impliquerait énormément de code superflu et autant de bogues potentiels (un parser pour chaque type de fichier de config... Sans parler de la gestion d'erreurs, etc...)
      - le "code bloat" pris par les parsers en questions existe déjà... dans tous les logiciels ! Si une registry existait ça ferait autant de lignes de codes qu'on pourrait balancer à la poubelle pour rendre les softs plus légers & plus fiables.
      - rester avec le système actuel ("moi je fait tout à la main avec vi") est bien dans l'esprit des geeks mais je constate qu'après plus de 10 ans d'existence et des efforts considérables de la part des mandrake & co Linux est toujours perçu comme difficile d'accès...

      Reste à voir comment ils l'implémentent. Pour ma part je préfèrerais un format binaire "natif" (ça évite de parser du texte à chaque fois et ça économise donc du CPU) avec un truc "standard" comme par ex BerkeleyDB, qui disposent tout de même de fonctionnalités de dump/recovery. Après, libre aux geeks d'implémenter une forme de "panneau de config" sous forme de fichiers textes et de parsers si ils veulent. L'important est de séparer la récupération de la config par les applis de la saisie des infos de config (panneau de config ou fichiers textes) pour que le système soit adaptable aux besoins de l'utilisateurs (et AHMA BerkeleyDB me semble être un bon choix pour une "couche d'abstraction").

      De tt façons il me semble que certains y ont déjà pensés depuis longtemps, même si l'implémentation différait (genre Ximian qui voulait mettre les fichiers de config en xml si je ne m'abuse)...
      • [^] # Re: Moi je trouve que c'est une bonne idée

        Posté par (page perso) . Évalué à 9.

        je préfèrerais un format binaire "natif" (ça évite de parser du texte à chaque fois et ça économise donc du CPU)

        Je ne pense pas que les optimisations de CPU sur ce genre de truc soit primordial. Ca doit à peine se ressentir.

        Quand au format binaire, beurk !
        Si tu as un problème un jour pour le récupérer en mode failsafe tu auras du mal alors qu'avec un fichier texte et vim tu pourras facilement récupérer le système. Utiliser un format binaire c'est retomber dans les erreurs de Microsoft.

        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: Moi je trouve que c'est une bonne idée

          Posté par . Évalué à 0.

          Complétement d'accord!

          De plus quel est la valeur ajoutée de l'éditeur de cette base de registre qui n'en est pas une? Il permettra d'éditer la valeur d'une clé mais dans une belle interface graphique? Ca apporte quoi par rapport à l'utilisation d'un éditeur de texte?

          Moi ce que j'attends d'une éventuelle interface graphique d'édition de conf c'est un peu plus: quelle gère les conflits d'options, les gourances de syntaxe, etc... Et ça ça restera dépendant de l'appli donc il y aura bien du code spécifique à l'appli à écrire, non?
          • [^] # Re: Moi je trouve que c'est une bonne idée

            Posté par (page perso) . Évalué à 2.

            Non pas si à chaque fichier de conf on joint un fichier spécifiant le format de celui-ci comme pour gconf ou KConfigXT.

            Ceci permet de spécifier le format de chaque clé et d'ajouter un libellé spécifiant à quoi sert la clé.

            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: Moi je trouve que c'est une bonne idée

              Posté par . Évalué à -1.

              Certe mais ça ne permet pas de gérer des conflits d'options du genre si tel option toto = x alors option tata ne peut prendre que a ou b comme valeur.
      • [^] # Re: Moi je trouve que c'est une bonne idée

        Posté par . Évalué à 6.

        Oh !
        Bon, ayant deja utilise des formats binaires et l'ayant regrette, je me dois de reagir.

        un parser pour chaque type de fichier de config

        Libconf: http://www.libconf.net/(...)
        Ceci dit, ce genre de projets est tres bien, mais est un gros hack pour une mauvaise conception a la base. La registry permet d'ameliorer la conception du systeme de config et rend theoriquement libconf inutile.

        un format binaire "natif" (ça évite de parser du texte à chaque fois et ça économise donc du CPU)

        Ca oblige a parser du binaire. A tenir compte du big/little endian.
        En cas de deterioration des outils de lecture (comme BerkeleyDB dont tu parles plus loin) suite a un bug, c'est beaucoup plus complique a remettre en place que du texte.
        Si l'on veut passer un fichier d'une machine a l'autre pour eviter de recopier une config qui marche, en modifiant une ou deux petites choses, on est oblige d'utiliser l'editeur de conf. L'editeur vi (ou emacs) ne suffit pas.

        Concernant le CPU, tu economises quelques dizaines de millisecondes a chaque lancement du programme. Ca doit te faire gagner grand maximum une 10aine de secondes dans une journee. Wow ! Ce n'est pas comme si on avait une boucle qui itere des milliers de fois sur ce genre de choses !

        Concernant le CPU encore, il ne faut pas oublier la conversion binaire->texte qui coute du CPU, alors que lire du texte en natif, ca aide ! Par exemple, un nom d'utilisateur, c'est du texte, pas du binaire. Un nom de fichier, c'est du texte aussi. Et pour les nombres, entre une conversion little/big endian et une conversion texte->binaire, gagne-t-on tant que ca ? Que faire si le format du nombre passe de 16 bits a 32 bits parce que cela a mal ete pense au debut ? Ca me rappelle les ordis de 640 ko et Bill Gates qui a dit (en 1981) que ca devrait suffire a tout le monde! (*)

        avec un truc "standard" comme par ex BerkeleyDB, qui disposent tout de même de fonctionnalités de dump/recovery

        Compatif de "standards" :)
        berkeleyDB vs fichier texte : il faut un editeur specifique pour une base BerkeleyDB, contre n'importe quel editeur de texte pour un fichier texte.
        Outils de dump/recovery. Ils existent aussi pour les fichiers texte. Mon prefere s'appelle "cp" meme s'il m'arrive parfois d'utiliser "mv" :)

        L'important est de séparer la récupération de la config par les applis de la saisie des infos de config

        Ca, c'est le plus important !

        BerkeleyDB me semble être un bon choix pour une "couche d'abstraction"

        Je prefere glibc qui implement des fonctions de lecture de fichiers texte (fgets, fputs) comme couche d'abstraction, mais c'est mon avis :)

        Le bonjour chez vous,
        Yves

        (*) y'en a un autre qui a dit que GNU/Linux ne tournerait jamais sur autre chose que sur un PC 80386. S'appelait Linus Torvalds, le bougre :)
        • [^] # Re: Moi je trouve que c'est une bonne idée

          Posté par . Évalué à 1.

          Oh !
          Bon, ayant deja utilise des formats binaires et l'ayant regrette, je me dois de reagir.


          Je n'ai pas dit que le stockage binaire était la solution parfaite ou universelle. Simplement si une "couche d'abstraction" était proposée pour distinguer "l'inferface utilisateur" et "l'interface programme" pour la config, chacun pourrait choisir s'il préfère maintenir des fichiers textes (convertis / "compilés" ensuite vers la base de registres qui ne serait qu'un cache) ou un éditeur distinct qui utiliserait directement la lib (dans mon exemple berkeley DB) pour écrire dedans.

          Il me semble que KDE utilise déjà un schéma similaire (même si le format binaire n'est qu'un cache sur des fichiers txt), et que e17 adopte aussi la même approche (avec edb)...

          En tout cas en ce qui me concerne j'aurais vite fait mon choix, car j'estime que le problème du stockage / récupération de paires "clé = valeur" est résolu depuis longtemps, de manière efficace par les SGBD, et que par conséquent ce n'est pas au programmeur de refaire ce boulot en moins bien.

          Ca oblige a parser du binaire. A tenir compte du big/little endian

          ?!?
          Mais non, on ne parse rien ! Pour le programmeur tout doit être transparent (avec une lib dédiée).

          Tout ce que le programmeur voit, c'est qu'il peut insérer / lire (rapidement puisque c'est indexé) des paires clé = valeur, sans rien avoir à parcourir puisque c'est la DB qui le fait pour lui... Par contre avec des fichiers txt c'est le programme lui-même qui doit faire tout le boulot (=> code bloat, sauf peut-être s'il utilise un truc comme gconf (que je ne connais pas donc je ne jugerai pas)). La chaîne "ma_cle = 120" prend 12 octets sans signification pour la machine alors qu'un stockage binaire {clé = "ma_clé", valeur = 120} est moins gourmand et surtout beaucoup plus vite retrouvé et "compris"...

          Par exemple, un nom d'utilisateur, c'est du texte, pas du binaire

          Bien sûr, mais tu fais une distinction superflue entre texte et binaire. Un fichier "binaire" (i.e. non 100 % ASCII) peut très bien contenir des chaînes de caractères ASCII (pour les clés comme pour les valeurs) et sans conversion aucune. Pour l'endianness, on stocke les données comme on veut (et dans tous les cas au pire ça prend moins de cycles de convertir l'endianness que de convertir un nombre de l'ASCII vers le binaire !)

          il faut un editeur specifique pour une base BerkeleyDB

          Rien n'empêche d'imaginer des convertisseurs ASCII<->DB pour les durs de durs qui veulent absolument utiliser vi ! Par contre on n'est plus _obligé_ de se taper la conf au format texte

          Outils de dump/recovery. Ils existent aussi pour les fichiers texte. Mon prefere s'appelle "cp"...

          OK. Mais normalement le problème de l'intégrité dans les bases de données est résolu depuis longtemps aussi (regardes combien de données critiques sont stockées (en binaires) par les SGBD). Si la base supporte les transactions normalement ça ne devrait pas poser problème ! D'autre part pour l'utilisateur lambda un fichier texte "corrompu" sera au moins aussi difficile à restaurer, à moins qu'il n'ait le courage de se replonger dans la doc...

          Concernant le CPU, tu economises quelques dizaines de millisecondes a chaque lancement du programme. Ca doit te faire gagner grand maximum une 10aine de secondes dans une journee. Wow ! Ce n'est pas comme si on avait une boucle qui itere des milliers de fois sur ce genre de choses !

          Nan, bien sûr, mais j'ai surtout voulu insister non pas sur le CPU mais sur le code bloat vu qu'actuellement une quantité non négligeables de code est écrit juste pour parser la conf. Effectivement je ne sais pas trop comment ça se passe avec gconf ou libconf, et si l'un de ces systèmes était adopté de manière universelle le pb serait résolu puisqu'il suffirait que le "backend" soit suffisamment modulaire pour qu'on puisse au choix utiliser du txt ou du binaire...

          Je prefere glibc qui implement des fonctions de lecture de fichiers texte (fgets, fputs) comme couche d'abstraction, mais c'est mon avis :)

          Je préfère une espèce de "libconf universelle" qui serait utilisée par tous et serait suffisamment modulaire pour ne pas contraindre le programmeur et l'utilisateur à un schéma particulier ! fgets/fputs ce n'est pas une couche d'abstraction puisque l'appli dicte encore _comment_ enregistrer ses données (ce qu'on voulait justement abstraire).
        • [^] # Re: Moi je trouve que c'est une bonne idée

          Posté par (page perso) . Évalué à 3.

          "Libconf: http://www.libconf.net/(...(...))
          Ceci dit, ce genre de projets est tres bien, mais est un gros hack pour une mauvaise conception a la base. La registry permet d'ameliorer la conception du systeme de config et rend theoriquement libconf inutile."

          Non, c'est un hack immonde si les fichiers de conf sont mal branlés... comme sous mandrake :/

          Un petit exemple, Suse a deja "un editeur de fichier de conf" à la regedit. Ca marche tres bien, mais un fichier de conf Suse, ca a une autre gueule que sous Mdk par exemple:

          ## Path: Hardware/Hotplug
          ## Description: Common hotplug options
          ## Type: list(default,off,verbose)
          ## Default: default
          ## ServiceRestart:
          #####################################################################

          ## Type: list(syslog,file,console,auto)
          ## Default: syslog
          ## ServiceRestart:
          #
          # The (debug) output and error messges of all hotplug scripts are written to
          # syslog by default and will be lost if no syslogd is running. Therefore you
          # may change that setting. You may choose one of these:
          # syslog all messages go to syslog (default)
          # file all messages will be written to /var/run/hotplug
          # console all messages will be written to /dev/console
          # auto use syslog if syslogd is running and file if not
          # Any other value is interpreted as syslog.
          #
          HOTPLUG_SYSLOG=syslog

          ## Type: string
          ## Default: ""
          ## ServiceRestart:
          #
          # If there are some types of events you don't want to be handled add it here.
          # Multiple types have to be seperated by whitespace.
          #
          HOTPLUG_SKIP_EVENTS=""

          ## Type: yesno
          ## Default: no
          ## ServiceRestart:
          #
          # Sometimes there are multiple modules that match a device, but mostly we need
          # only one of them. Therefore we stop module loading after the first module of
          # the list was succesfully loaded. If you want hotplug to always load all
          # modules it gets then set this variable to 'yes'.
          #
          HOTPLUG_LOAD_MULTIPLE_MODULES=no


          Voila, c'est propre, pas besoin de remettre en question tout le systeme de conf actuel!

          Apres, vouloir uniformiser le format des fichiers de conf des logiciels me parait idiot voir meme impossible. La suse a bien un fichier de conf comme celui ci dessus pour Postfix mais y'a un script qui build le fichier de conf Posftix a partir de celui ci. Meme sous windows, il y'a beaucoup de soft(meme des softs microsoft) qui n'utilisent pas regedit car cela ne repond pas a leur besoin.
      • [^] # Re: Moi je trouve que c'est une bonne idée

        Posté par . Évalué à 2.

        rester avec le système actuel ("moi je fait tout à la main avec vi") est bien dans l'esprit des geeks mais je constate qu'après plus de 10 ans d'existence et des efforts considérables de la part des mandrake & co Linux est toujours perçu comme difficile d'accès...

        Pour moi l'intérêt de centraliser n'apporte rien à la facilité de configuration des logiciels. Il suffit de faire un bête rapprochement avec la base de registre windows pour se rendre compte que ce n'est pas du tout user-friendly.

        L'intérêt comme tu l'as dit réside dans la facilité de développement des logiciels, et dans la centralisation. Mais bon la mode concernant les fichiers de configuration est plutôt de passer à un format xml (type apache ou jabber), qui paraissent tout de même plus souples.

        Quant au binaire ca a été dit : ca me parait hors de question.

        --
        Thomas
        • [^] # Re: Moi je trouve que c'est une bonne idée

          Posté par . Évalué à 1.

          Le fait qu'une application ait ses propres fichiers texte de configuration est un énorme avantage.

          Si je prends FVWM comme exemple. Le fichier de configuration peut faire plus de 600 lignes. L'avantage de FVWM est qu'on peut coder des fonctions avec des mots-clés de BASH, for if else... je vais énormément me faire chier à parcourir mes scripts, la base de données pour changer des paramètres. Il peut même y avoir un risque de redondance ou de complexité : ma variable est-t-elle dans mon fichier script ou dans le registre ?

          Avec FVWM je suis trop habitué à décentrailiser ma configuration pour qu'elle soit plus claire et plus facile à modifier. Si j'enlève un décor de fenêtre il me suffit de supprimer le fichier correspondant.
          • [^] # config clé-valeur et scripts de démarrage.

            Posté par (page perso) . Évalué à 2.

            C'est comme .emacs ou .emacs.elc ou .vimrc etc. , je ne croit pas que ce soit des conf clé-valeur alors que c'est ce dont il s'agit ici.
            Attention, je pense pas non plus que LR veut remplacer tout les config. il tend simplement à uniformiser ce qui est uniformisable.

            Je vous conseille de lire la discussion sur FD.org, elle est drôlement interressante. Ce n'est pas tant que cela un troll.

            Avec Gconf, si tu édite manuellement un fichier, ce n'est pas pris en compte ! ( faut utiliser gconf-editor ).
      • [^] # Re: Moi je trouve que c'est une bonne idée

        Posté par . Évalué à 3.

        - avoir un "vrai" panneau de config universel (graphique ou toute autre nouvelle idée) sera une illusion tant que le système actuel perdurera. Ou plutôt même s'il existait il impliquerait énormément de code superflu et autant de bogues potentiels (un parser pour chaque type de fichier de config... Sans parler de la gestion d'erreurs, etc...)

        Ca n'existe pas déjà tout ça ? Il me semble qu'il y a déjà des outils graphiques, créés par Mandrake, KDE, et sûrement bien d'autres, qui vont modifier les fichiers de configs (en texte eux).

        Vu le nombre, il y a certainement redondance de code. Mais on pourrait imaginer un truc sur le même mode que sane, c'est à dire des modules adapté aux différents formats (et j'ose espérer que plusieurs projets partagent une même syntaxe) comme les drivers sane, et différents outils pour faire ces configurations, depuis (au choix) KDE, Gnome, un webadmin, en mode texte.

        Pour l'emplacement des fichiers de configuration, il me semble qu'ils ont déjà tous un emplacement sandard, et que c'est une erreur de la part des distributions de les avoir parfois mis ailleurs.
  • # reinventé la roue ?

    Posté par . Évalué à -1.

    gconf existe déjà, propose a peu près la même chose, son démon permet d'avertir les logiciels des changements, et j'ai lue ici que dbus pourrait bientot être supporté.
    Concernant ses fichiers XML, ce n'est qu'un backend, on peux très bien stocker la config dans une base de données ou tout ce que vous voulez...
    ou carrement pourquoi pas le système de fichiers de config classique ?
    Gconf n'est qu'un intermédiaire entre les données et les programmes.
  • # Perte de temps ?

    Posté par . Évalué à 0.

    La configuration, ce n'est pas encore tip-top, mais ça marche! Et même plutôt bien.

    Et effectivement, comme lu dans un post précédent, si la registry est foirée, ben le système est quasi mort.

    Et quid de la compatibilité avec les Unixs ? Un bon système, c'est un fichier dans un format parsable facilement, avec génération des fichiers "ancien format" dans /etc, nan ? (idée implémentée sur Aix, de mémoire)

    /etc/lilo.conf.reg => moulinette genre XSLT => /etc/lilo.conf
    ...
    • [^] # Re: Perte de temps ?

      Posté par . Évalué à 1.

      Et quid de la compatibilité avec les Unixs ?

      Bah suffit de porter les outils sur les autres Unices. Ca ne force en aucun cas a changer les fichiers de conf natifs a ces autres unices. Ca permet juste de lire les fichiers de conf respectant le format de "registry".
  • # Les inodes ?

    Posté par (page perso) . Évalué à 4.

    Je trouve ça très bien comme projet si il est adopté par suffisament de projets.

    Mais je me pose une question : si pour chaque clé est utilisé un fichier physique, est-ce qu'on risque pas de perdre un petit paquet d'inode ? (excepté ReseirFS). Et pour les perf ?
    Dans les commentaires de l'interview la question est posée mais il n'y a pas de réponses à ce problème hormis "on vera plus tard".

    NB pour ceux qui disent GConf c'est pareil : GConf dépend de 15 lib dont libglib; alors ca serait assez génant d'avoir besoin de libglib pour qu'init puisse lancer le reste de la distrib. (cf le 1er lien de la news, chapitre 11)
  • # Avec M4

    Posté par . Évalué à -1.

    Mais non, c'est pas si dur.
    moi je verrais bien une base de registre dont le source serait dans un fichier unique compilée avec M4 comme pour sendmail ce qui est compatible avec toutes distributions.

    du genre /etc/system/main.mc

    Mais chiffrée avec openssl et certifiable via CA.
    Dont le fichier de source serait detruit a la compil pour la securitée.

    Et accessible via un daemon au boot, et une interroperabilité possible LDAP.

    Bon faut aussi un bon systeme de sauvegarde a clés partagée.

    Et je pense qu' avec de bons outils sous X l'utilisateur lambda sera
    content.
  • # Différence avec le registre de m$

    Posté par . Évalué à 1.

    Il faut pas comparer ce "Linux Registry" avec la base de registre de ms.
    En effet, la base de ms est conçue pour faciliter la création de sharewares notamment. son stockage binaire, sa centralisation, son fouilli immonde... facilitent le stockage d'une clé "cachée" qui identifie par ex la date d'install d'un shareware...
    La base proposée par ce projet serait en format texte (=> on pourrait faire un diff pour contrôler), plusieurs fichiers séparés, et semble-t-il enregistrement des dates des modifs... Que demande le peuple ? :)
  • # Bof !

    Posté par . Évalué à 1.

    Small is beautiful !
  • # et gconf ?

    Posté par . Évalué à 2.

    très bien cela, mais malheureusement je sens le double emploi avec GConf

    (rappelons que GConf n'est pas gravé ds le marbre mais peut être amélioré hein)
    que le démon gconf ne plante plus à chaque phase de la lune et que de toute façon il est relancé dés qu'un programme en a besoin si jamais)
    que l'architecture client-serveur de gconf permet d'isoler totalement le client du fonctionnement interne de gconf et permettre une gestion réseau de postes (moA admin changer config de tout plein de poste via UNE interface de gestion réseaux de postes) )

    et puis, rien n'empcherait de reprendre le concept de schema, de backend xml etc et d'adapter améliorer Gconf

    enfin, seuls les développeurs peuvent vraiment juger le meilleur choix, on verra.
  • # Format de stockage

    Posté par (page perso) . Évalué à 3.

    L'idée me plaît, mais un GROS problème est l'utilisation du format clé=valeur. Si c'est simple à comprendre et à parser, ça manque singulièrement de puissance. Pour certains logiciels qui utilisent des fichiers de conf en XML, comment fait-on ?
    • [^] # Re: Format de stockage

      Posté par . Évalué à 2.

      XML ne peut représenter que des structures en arbres je pense, comme clef=valeur si on utilise des noms de clefs composites comme c'est le cas ici.

      Par exemple <toto><tata clef1="valeur" clef2="plop" /><titi clef="val" /></toto> donnera:
      toto.tata.clef1=valeur
      toto.tata.clef2=plop
      toto.titi.clef=val
  • # Mouais...

    Posté par . Évalué à 3.

    Une des nombreuses réserves que j'éprouve face à ce projet, c'est l'unification de la syntaxe. C'est peut-être idiot, mais j'ai eu du mal à comprendre la syntaxe de sudoers, exposée dans les pages de man comme "Extended Backus-Naur Form". Ouais, bah je préfère nettement la "simple smb.conf-xorg.conf form", moi. Alors si le concepteur est un fan de Backus, je vais devoir me refaire des pages de man tordues pour pouvoir éditer mes fichiers à la main. Et en plus, dans tous les fichiers ce sera cette syntaxe abhorrée que je retrouverais. Auuuuuugh !

    Ensuite, le débat mode texte contre clickodrome. Je suis un linuxien fraichement émoulu, je n'ai quitté le giron de Windows que depuis un an. Et LA tare de Windows, c'est que dès que le graphique ne marche plus, ça devient l'enfer. Si le mode "Sans échec" ne boote plus, c'est généralement l'hallali, parce qu'on a quasiment plus rien pour examiner le disque dur ni le soigner. Alors je préfère nettement avoir des outils dédiés au mode texte, que des clickodromes "user-friendly" pleins de jolis effets ou de clippy survoltés :) Donc leur système a intérêt à être très abordable en mode texte. Je détesterais avoir à rechercher un fichier de conf super important dans le répertoire .kde par exemple. Alors si leur registry ressemble à ça, non merci.

    En tant qu'ex-windowsien, je suis sensé être le plus géné par le système etc. Et pourtant, c'est l'une des choses que j'apprécie le plus sous Linux ! Le nombre de fois ou une expérience à mal tournée et ou j'ai pu localiser le fichier fautif, puis le corriger, même à partir d'un CD bootable ! J'ai déjà soulevé le problème de l'aspect du répertoire du registry... Est-ce que les noms seront humainement reconnaissables, ou bien seront-ils optimisés pour l'application chargée du registre ? Le fait est que la plupart du temps, quand on doit vraiment modifier un fichier de conf, c'est qu'on est dans une situation peu enviable. Alors rajouter une surcouche pour rendre plus confortable leur édition dans les situations normales, c'est inutile. Franchement, je n'ai pas besoin d'un "regedit" pour modifier les paramètres de K3B !

    Et le problème des dossiers cachés dans le $HOME ne justifie pas ce massacre. A la limite, pourquoi ne pas ajouter une variable $CONFIG qui éviterait les astuces comme le répertoire "domus" plus haut ? Au lieu de s'acharner sur le $HOME, les programmes écriraient paisiblement dans un répertoire spécifique.
  • # Pour être concret

    Posté par (page perso) . Évalué à 1.

    J'aimerais savoir ce que vous reprochez concrétement à la base de registre windows...

    Bon je sens que ça va partir en troll mais essayez d'être un peu plus constructifs que "c'est le bordel".

    Pour vous donner des pistes, y à un truc que je reproche, c'est les cochonneries en de clés en hexa.
    Quoi d'autre?
    • [^] # Re: Pour être concret

      Posté par (page perso) . Évalué à 2.

      Aucun reproche particulier pour la partie "clef hexa"... Parfois on a besoin de stocker une conf binaire, ca peut alors être utile, et j'aime assez la façon dont ils gèrent l'affichage / saisie / stockage en .reg (justement la forme "hexa")

      Par contre le reproche principal est de mettre tout dans un fichier
      (2 maintenant : un par utilisateur, un pour le système)
      ce qui provoque un crash général en cas de corruption de ce fichier.

      Mais ce reproche tient uniquement par le fait que la sauvegarde du registre (à chaque boot par exemple, ou tous les jours,) avec conservation de X sauvergardes n'est pas installée en standard dans Windows ...

      Donc ce reproche ne tient pas, parce que oui, un doze ça se "tune" aussi (comme un nunux...)

      donc il ne reste pas grand chose comme inconvénient, d'autant que l'API disponible pour y accéder est assez correcte.

      ...
      • [^] # Re: Pour être concret

        Posté par (page perso) . Évalué à 1.

        Hum mon reproche pour la partie hexa parlait bien de clé et pas de valeurs.
        Il est normal de stocker des valeurs en hexa, mais stocker un chemin vers un programme sous une clé hexa de 16 caractéres je capte pas trop.

        Tout mettre dans un ficher, certes c'est mal mais il y à un certain nombre de fichiers sur chaque OS qui s'ils disparaissent ou sont corrompus sement la grouille...

        Il me semble que maintenant sous XP, (voire 2000), il y à une sauvegarde propre à chaque modif de la BDR par un soft (install/desinstall), donc en cs de crash on récupére depuis la derniére install, on perd son fond d'ecran et son affichage preféré pour tel dossier mais c'est pas trés trés grave.

        /me attend toujours le deferlement du troll, surement aprés la fin de la sieste?
      • [^] # Re: Pour être concret

        Posté par . Évalué à 2.

        Comme dit plus haut, je trouve aussi qu'un inconvénient supplémentaire de la base de registre à la Win est l'absence de documentation des clefs, et l'impossibilité de rajouter des commentaires. On a l'impression que ça a été créé pour être obscur.
    • [^] # Re: Pour être concret

      Posté par (page perso) . Évalué à 2.

      - Tout dans un (ou 2) fichiers ce qui si il est corrompu casse tout le système.

      - regedit permet de changer les valeurs mais rien n'est explicité nul part contrairement à gconf-editor ou kconfeditor (qui peut lire la conf KDE ou gconf)

      - Format de fichier binaire donc non éditable à la main en cas de crash

      - Plein de trucs sont uniquement accessibles via regedit et non documentés

      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: Pour être concret

      Posté par (page perso) . Évalué à 1.

      J'aimerais savoir ce que vous reprochez concrétement à la base de registre windows...

      Le fait qu'elle soit stoquee dans un seul fichier, implique que si ce fichier est corrompu, ca risque de mal se passer, comme cela a deja ete dit.

      Mais il y a autre chose qui m'embete, c'est que tout utilisateur peut modifier n'importe quelle clef de la base de registre, sans avoir a etre administrateur. Enfin c'est ce qui m'avait semblé, cela a peut etre changé depuis.

      Et c'est normal, les droits d'acces sont au niveau des fichiers. Sur un systeme unix par exemple, tu peux mettre les droits que tu veux sur chaque fichier de /etc. C'est beaucoup plus difficile de faire ca sur un seul fichier.
      • [^] # Re: Pour être concret

        Posté par . Évalué à 2.

        Mais il y a autre chose qui m'embete, c'est que tout utilisateur peut modifier n'importe quelle clef de la base de registre, sans avoir a etre administrateur. Enfin c'est ce qui m'avait semblé, cela a peut etre changé depuis.

        Sous 9x/Me ça doit être comme ça. Par contre sous NT/XP, chaque dossier de la base de registre a ses propres permissions, exactement comme un fichier.

        Et par défaut un utilisateur qui n'a pas les droits d'admin n'a pas accès aux clefs sensibles.

        (bon, après un utilisateur qui n'a pas les droits d'admin, c'est pas si facile que ça à trouver...)
      • [^] # Re: Pour être concret

        Posté par (page perso) . Évalué à 2.

        tout utilisateur peut modifier n'importe quelle clef de la base de registre
        Tu te trompes. Si ton utilisateur normal n'est pas admin de la machine (si c'est valable sous Unix, ça l'est aussi sous Windows), tu n'as pas accès aux clefs systèmes. La base de registre à un système de droit (enfin, dans mes vagues souvenirs, rah du temps de ma certification d'admin NT4 :) ) comme le système de fichier. D'ailleurs il faut utiliser "regedt32" (l'éditeur à la sale gueule) pour bien gérer ces droits.
    • [^] # Re: Pour être concret

      Posté par . Évalué à 1.

      Quand ton serveur *nix à des problémes, avec une simple connection ADSL, un terminal et un éditeur de texte, tu peut faire des miracles....

      Sous Windows, si ta base de registre à des problémes, il faut se déplacer, constater les dégats, et réinstaller..

      Si cette fameuse "base de registre" sous *nix garde son attrait de maintenance à distance, pourquoi pas..
      • [^] # Re: Pour être concret

        Posté par (page perso) . Évalué à 3.

        Quand ton serveur Windows à des problémes, avec une simple connection ADSL, tu peut faire des miracles....

        Bon, si t'arrives a te depatouiller de ta base de registre moisie mais l'admin a distance sous windows, ca existe aussi :) Le regedit s'execute en local mais recupere les infos sur la machine distante.
        • [^] # Re: Pour être concret

          Posté par . Évalué à 3.

          Je rajouterais que quand ton serveur à des problèmes, Windows ou Un*x, de toutes façons, tu n'as pas forcément encore une "simple" connection ADSL qui fonctionne... Surtout pour des problèmes de conf réseau...
          • [^] # Re: Pour être concret

            Posté par . Évalué à 1.

            Pour ma part, dans 80% des cas, plus rien ne marche sur les station Windows. J'ai déjà tester regedit en réseau. Pas évident quand même !

            il est quand même plus facile de modifier un fichier de conf, avec une bonne doc ou un man, plutôt qu'une base de registre avec des cléfs obscurs. Voir de repartir d'un fichier d'exemple, et tout refaire.

            Souvent, dans la base de registre, l'application en cause c'est loger partout, voir dans les bases de registres utilisateurs, et il faut refaire les profils ! Donc tout reparametrer.

            Certains se plaignent de nombreux fichier caché sous unix, mais il suffit de simplement supprimer le fautif pour que sa remarche.
    • [^] # Re: Pour être concret

      Posté par . Évalué à 2.

      C'est le bordel.

      On ne peut pas dire que ce que je viens de dire est faux. Ce n'est pas non plus non constructif, puisque c'est un fait, personne ne peut le nier.

      Maintenant, il y a ceux qui aiment le bordel et ceux qui n'aiment pas.
  • # ln (-s ?) /etc /config :)

    Posté par . Évalué à 1.

    avec normalisation du contenu et de la sous-arborescence en plus ?!

    C'est un peu tiré par les cheuveux, mais c'est presque ça (avec en plus un $HOME/etc oups, $HOME/.config :) )
  • # pour le fun

    Posté par . Évalué à 5.

    pour le fun je vais vous parler d'un serveur de mail proprio, critical path, qui tourne sous solaris, linux, w32...

    et bien, on a droit a une sorte de base de registres sous *nix

    les clefs sont dans les repertoires dans /etc avec une arborescence qui correspond a leur nom, dans un fichier .data

    genre un fichier

    /etc/nplex/smtp/settings/.data

    dans lequel on a une clef MaxConnection=512

    encore plus fort. Si par exemple on veut autoriser nombre de stations a etre relayees, on va creer des repertoires du nom des reseaux du genre

    /etc/nplex/smtp/settings/allowrelayin/192.168.100.0-255.255.255.0/

    bref, comme quoi quand on veut faire n'importe quoi on peut :)
  • # Vaderetro

    Posté par . Évalué à -5.

    Qu'il y ai une uniformisation des fichiers de conf pourquoi pas avec une API pour y accéder plus facilement oui.

    Mais mon dieu pourquoi tout mettre dans un seul fichier texte, non mais quelle horreur !!! que l'on garde une arborescence de fichiers !!!

    Faut qu'en meme pas que l'on recupere les défauts de conception de Windows !!!

    J'avoue ne pas avoir tout lu avant de poster... mais ca me semble quand meme une grosse connerie...

    ---
    Ben
    • [^] # Re: Vaderetro

      Posté par (page perso) . Évalué à 4.

      J'avoue ne pas avoir tout lu avant de poster... mais ca me semble quand meme une grosse connerie...

      Oui tu n'as pas lu c'est pour ça que tu viens de dire une grosse connerie :)

      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

  • # Mes 2centimes d'euros

    Posté par . Évalué à -2.

    Aprés Win 3.11, W95/98 et maintenant XP (pour des raisons historiques ou professionelles).
    Ayant démarré dans les monde des UNIX/Linux avec une RH 5.2 sur mon pc perso, je viens de passer 3ans sous HP-UX au boulot, et 6mois sous AIX.

    Une base de registre, dans l'absolut me parait être une bonne idée pour simplifier un certain nombre de tache de gestions. Ou plutôt l'idée de centraliser/uniformiser un certains nombre de paramètres/infos de configuration me semble bonne.

    Néanmoins, entre un HPUX ou un Linux utilisant des fichiers de config même si ils sont trés dispersés parfois et pas forcément rangés à la même place suivant les OS/Distribs... ben je trouve tout de même ça mieux qu'une base de registre style ODM d'AIX qui est sensée simplifier la vie mais qui fini par ressembler à un vrai gruière plus du tout synchrone avec l'état/la réalité du système car il n'a pas vu/pas supporté un changement (pourtant réalisé avec les outils livrés dans l'OS pour une tache courante telle que de l'ajout de disques dans LVM).

    Pas la peine "d'essayer de casser" un ODM en allant trifouiller dedans, ça se casse tout seul rien qu'en utilisant les commandes standard fournies avec l'OS (vécu).
    Il en est de même pour Win je ne vous apprend rien.

    Alors même si celà part d'un bon sentiment. Une base de registre sous Linux ne me semble pas une grande avancée mais plutôt le début d'une période noire (si celà se concrétise) pour nombre d'admin sys et le début d'un nouvel eldorado pour les SSII qui vont pouvoir "vendre" de l'admin sys à tour de bras.....

    Il ne me parait pas immaginable de laisser à des développeurs le soin d'aller modifier une base de registre "commune à tout le système" lors de l'install d'une application utilisateur.
    Non pas que TOUS les dev codent comme des gorets mais bien car il suffit d'un seul goret croyant savoir coder proprement pour en 2s casser suffisament un serveur qui nécessitera au moins 1j de travail pour le remettre en service car celui-ci ne saura même plus où sont les devices disk sur lequel le système tourne (cas rencontré sous AIX).

    Le système de fichiers de conf n'est peut-être pas idéal en l'état, peut-être faut-il le "normaliser", mais celà doit rester "chacun chez soi" et ne pas permettre à l'install d'une appli de mettre en rideau le système d'un serveur car il y a eu unepetiteerreurdecodage qui est aller modifier/supprimer des entrés purement système.
    Idem pour l'appli A qui va casser l'appli B.

    Alors SVP, avant d'imposer "une super idée géniale qui va tout révolutionner" j'espère que ceux (là haut tout là haut ;o) qui en ont la possibilité, y réfléchiront à 2 fois avant de prendre _LA_ bonne décision.

    C'était les 2centimes d'un admin UNIX qui fait bcps d'admin disque/SAN et qui trouve qu'un LVM HPUX avec sa table kernel, son fichier LVMTAB plus quelques fichiers spéciaux par LV/VG c'est tout de même bcps mieux qu'un ODM qui croit voir des disk (même pas des PV, juste de bêtes disques SCSI) là où il n'y en a pas..... :'(
    • [^] # Re: Mes 2centimes d'euros

      Posté par . Évalué à 4.

      RTFM !!!

      As-tu lu l'article ? les liens ? les commentaires ?!

      Pour la xxxème fois, il ne s'agit en aucun cas d'une "base de registre" type win, odm, ...
      Il s'agit, comme tu le suggères si bien, d'une normalisation des fichiers de conf...

      M'en vais me saoûler la gueule, moi, y'en a marre de répéter les mêmes choses, tiens... ---- hips --->[]
  • # c'est idiot mais ...

    Posté par . Évalué à 2.

    euuuh ,j'ai lu la présentation ooo

    y'a un truc qui m'échappe :

    le fhs défini déjà quelques fichiers de configs standard mais on est loin du compte.
    la syntaxe des fichiers de config est actuellement laissée au libre choix du programmeur.
    la situation des fichiers de config par user est laissé totalement au hasard et il n'y a pas de norme ni de rfc ni de ...

    donc questions idiotes

    pourquoi depuis 1970 qu'existent les unix et unix like personne n'a voulu se mettre autour d'une table et choisir une norme ? Quand il s'agit de mettre les machine en réseau (partage), ça se fait. alors pourquoi quand c'est nous qui sommes la cible du partage c'est le bordel ?

    Pourquoi avec xml, n'y a t il eu aucune tentative (bien diffusée sur le net au moins) aucune proposition de feuille de style pour les fichiers de config ?

    Pourquoi le fhs ne spécifie-t-il pas tout simplement un sous-rép dans $HOME/$USER (je sais pas moi , .config :-) ) qui contiendrai le bordel des sous rép plutôt que directement posés dedans. ça serait pas beaucoup mais déjà un progrès.

    merci de m'avoir lu jusqu'au bout

    alain
    • [^] # Re: c'est idiot mais ...

      Posté par . Évalué à 3.

      je pense que c'est parce que les differents format de fichier de config sont plus ou moins pratique selon ce que tu souhaite faire.

      Le XML n'est pas encore accepté par tous, il est plus dur de parser un fichier xml qu'un simple fichier de config et surtout c'est plus lent.

      Et le .config est déjà une recommendation de freedekstop, reste plus que les différents programmes l'adoptent.
      • [^] # Re: c'est idiot mais ...

        Posté par (page perso) . Évalué à 2.

        J'ai quand meme du mal a saisir l'interet du .config :)

        avant:

        cd ~
        ls -a
        plein de reps/fichiers


        avec .config:

        cd ~
        cd .config
        ls -a
        plein de reps/fichiers

        Donc, a part que tu vas dans un sous rep, je vois pas. A moins ce qu'il y'ait des gens ici qui mettent leur zik dans des reps cachés?
        • [^] # Re: c'est idiot mais ...

          Posté par . Évalué à 2.

          Ben, quand j'utilise Rox, bien sur par défaut je vois pas les fichiers cachés, mais quand je fais du gftp, j'ai de base tous les fichiers et repertoires cachés dans l'arborescence.

          Et puis j'essaye d'avoir la racine de mon compte organisée et hiérarchisée. Merci à toutes mes applis d'y foutre leur bordel :)
          Par exemple, mozilla : j'ai (j'avais) un rep caché pour la config de phoenix, un pour mozilla, un pour thunderbird. je savais plus trop où regarder quand je cherchais quelques choses...
          • [^] # Re: c'est idiot mais ...

            Posté par (page perso) . Évalué à 2.

            "mais quand je fais du gftp, j'ai de base tous les fichiers et repertoires cachés dans l'arborescence. "

            Problème de configuration de gftp, si tu veux pas les voir, ben tu le dis a gftp :p

            "Par exemple, mozilla : j'ai (j'avais) un rep caché pour la config de phoenix, un pour mozilla, un pour thunderbird. je savais plus trop où regarder quand je cherchais quelques choses... "

            Mauvais exemple, que ca soit dans ~ ou dans ~/.config, ca changera rien, t'auras tjs 3 rep mozilla et tu seras pas lequel est le bon, le probleme est un probleme de mozilla.
      • [^] # Re: c'est idiot mais ...

        Posté par . Évalué à 1.

        J'intéressantises !

        En plus, fatalitas, si tu veux faire du XML, c'est une dépendance supplémentaire, à moins que tu ne réimplémentes un parser dans ta librairie, ce qui serait un peu dommage.

        Ou alors, tu fais un parser simplifié, qui ne supporte pas toutes les fonctionnalités XML, et dans ce cas, ben autant simplifier le format. Et tu en arrives... à un fichier plat.

        Et comme tu veux quand même un système arborescent, tu t'appuies sur le FileSystem en faisant des sous-répertoires.

        Et paf : ça donne regi^H^H^H^H Elektra.
  • # Va y'avoir du boulot

    Posté par . Évalué à 3.

    Je parle pas du code à mettre à jour, mais plutôt des pages de man / info.
    Personnelement, la syntaxe unique, je m'en fou. Par contre, comme a chaque fois, ca va etre le bordel pour les cas particulier.
    Sinon, de nombreux point sont criticable:
    2.1 -> Avantage, on risque pas de les confondres.
    2.2 -> La difference preserve des virus et autres cochoneries. La non uniformité est la meilleur protection contre ces sales betes.
    A system administrator must know all these formats. -> Il suffit de savoir lire un man
    High-level system administration GUIs -> Beaucoup trop lente pour administrer une machine. Mon vi marchera sur toute machine sur laquel je peux avoir un shell en local ou remote.
    It is designed to be easy to administrate with regular command line tools like cat, vi, cp, ls, -> l'exemple du XF86Config le contredit. Avec vi, j'ouvre 1 seul fichier qui contient toutes la config, avec le registre faut ouvrir plusieurs fichiers. Sinon, y'a aussi un outil puissant grep.

    L'arborecence avec repertoire, ça me fait penser à /dev ou /proc où c'est encore plus dur de s'y retrouver que dans /etc.

    L'autres truc à ne pas oublié, c'est que dans Logiciels Libre, il y a libre, ce qui signifie que chacun est libre de choisir ce qu'il fait.

    Personnelement, je n'appracie pas trop les machins centralises, car on n'est jamais à l'abris d'un effet de bord.
  • # Espoire -- update le projet s'appelle Elektra maintenant

    Posté par . Évalué à 0.

    J'espère sincèrement que l'histoire va réussir à convaincre tous les septiques (apparemment il y en a beaucoup).

    Il était temps qu'on repousse un peu les limites de l'interopabilité des unix; et cela sans passer par ces vilains hacks des distributions.

    On sent aussi depuis un certains temps la volonté de rendre gnu/linux un peu plus convivial, un peu plus "hot plug" avec l'apparition, notemment de HAL, D-BUS, etc.

    Maintenant, prenons un exemple de ce que permettra registry. Le fichiers /etc/networking/interfaces sera remplacé par la hiérarchie "/sys/networking/interfaces/*" (nom approximatif, voir le sxi). De ce fait, l'applet netmon-status ne devra plus se configurer manuellement (ou du moins pas de la même façons). Le même raisonement se vera appliquer à guessnet, ifplugd. Tous les fichiers de configurations disctincts se veront remplacé par l'arborescence /sys/networking dont l'administration est possible avec un simple regedit.

    À terme:
    - moins de dépendances vis-à-vis de bibliothèque : gconf, orbit, etc. registry Elektra est une bibliothèque bas niveau avec la libc pour unique dépendance;
    - des scripts de démarages mieux écrits : tous les "source; /etc/defaults/daemon.conf" pourront être remplacés par `kdb get value_name`;
    - une interopabilité aux travers des différentes couches du systèmes (de /sbin/init à une application desktop)
    - une configurations centralisée et facilement administrable.
  • # Despotisme même pas éclairé

    Posté par . Évalué à 2.

    Ah y est, j'ai fini de lire leur doc et les autres commentaires.

    A lire leur document, on a l'impression qu'ils ont découvert la lune.

    Y'a rien de transcendant , un systeme de clé-valeur dans une structure arborée (ou grappulaire) + une lib pour aller les lire.

    Pour nous convaincre, ils prennent deux pov exemples triviaux. Un inventaire des fichiers de conf plus gourmand comme ceux d'apache, de mysql, de proftpd etc aurait été plus profitable.

    Les fichiers de conf sont hétérogènes mais ils ont tous une grammaire qui facilite leur lecture, permet de commenter de règles et qui est adaptée au logiciel qu'il y a derrière.

    Les fichiers qui pourrait facilement rentrer dans Elektra sont déja quasiment tous au même format, càd des sections plus clé valeur.

    La diversité, c'est aussi la liberté. Elektra no passaran.
  • # config complexes

    Posté par . Évalué à 1.

    Pour ceux qui disent que l'on ne peut pas faire des configurations complexes avec ce système parcequ'il utilise clef=valeur, rien n'interdit d'enrichir le système :
    par exemple, on peut avoir une arborescence de répertoires et des fichiers textes qui contiennent la configuration proprement dite (avec des commentaires qui peuvent être affichés dans le GUI (menu contextuel ou autre)) :

    system
    |_mail
    |_server
    | |_pop
    | |_smtp
    | |_exim
    | | |_version3
    | | | | #COMMENTAIRE BLABLA...
    | | | |_autostart=no #COMMENTAIRE....
    | | |_version4
    | | |_autostart=yes
    | | |_if(autostart==yes)
    | | | |_startbefore=httpd #httpd est le sous répertoire permettant contenant l'arborescence des serveurs web
    | | | |_startbefore=truc
    | | | |_startafter=network
    | | |_...
    | | |_...........
    | | |_if (trucchose == titi OR (!machin AND trucmuche < 10)
    | | | |_....
    | | |_else
    | | |_if ....

    | |_postfix
    |_...

    user
    |_toto
    | |__ ...
    |_titi
    |_....
    |_...
    |_...

    Pour aller plus vite, le système peut créer des caches des fichiers textes et en cas de problème, il peut aller automatiquement relire les fichiers pour recréer le cache. On peut aussi faire en sorte qu'en cas de fonctionnement dégradé (en dernier ressort), le système ignore le cache et ne fonctionne qu'avec les fichiers textes. Quand on fait une modification avec un éditeur de texte, soit on peut utiliser système de type FAM pour recréer le cache automatiquement, ou si c'est problématique, on peut aussi imaginer que l'utilisateur lance une commande pour relancer la création du cache (ou si la commande n'est pas disponible pour une raison X ou Y, on peut supprimer le fichier de cache pour forcer la relecture des fichiers textes), on peut ausi utiliser un outil générique en mode texte ou graphique pour modifier les fichiers.
    Pour pallier les gros soucis (du genre : on a modifié un fichier de conf (mais mal modifié) et on sait plus comment revenir en arrière, pour cela il suffit de créer une arborescence parallèle utilisée pour garder les fichiers de configurations "non modifiés", c'est à dire contenant les fichiers de b=conf de base installés lors de l'installation du logiciel ou du système ou de la mise-à-jour).

    PS. Pour ceux qui n'aiment pas le GUI à la regedit (j'en fais parti), on peut avoir le même type de GUI, mais au niveau du dernier répertoire avant les clef=valeur, on pourrait par exemple ajouter la possibilité de faire clic-droit sur le dernier répertoire et préciser qu'on veut ouvrir le fichier de configuration dans un éditeur de texte.

    Pour les startbefore et startafter, cf principe de démarrage gentoo.
    • [^] # Re: config complexes

      Posté par . Évalué à 1.

      J'avais cru comprendre que Elektra n'avait pas besoin de démon pour fonctionner. Alors, le système de cache, il est géré comment ?
      • [^] # Re: config complexes

        Posté par . Évalué à 1.

        pas la peine de démon pour ça.
        Pour la création du cache, s'il n'existe pas, la bibliothèque lors d'une lecture le recréé, c'est tout.
        En cas de pb de cache (corrompu), il y a des erreurs donc la bibliothèque le sait au moment d'une lecture de la base et peut simplement le recréer.
  • # et la place disque ?

    Posté par . Évalué à 1.

    Sur le principe de l'unification des fichiers de configuration (et des accès par les applis), l'idée est bonne - mais d'autres l'ont déjà eue.

    Par contre il reste un problème de taille...

    Si j'ai bien compris le système proposé par Elektra, l'implémentation pratique des paires clef-valeur, utilise le système de fichiers, avec un fichier pour chaque paire.
    Or, la configuration d'un sytème Linux, ça représente des milliers (voire des dizaines de milliers pour des serveurs) de paires clef-valeur. Si on utilise ça avec ext2 ou ext3 (4 Ko minimum par fichier), la place disque gaspillée est énorme. Ca n'est éventuellement acceptable qu'avec Reiserfs.

    Je m'étonne que personne n'ait soulevé cette objection dans le débat en anglais, ou alors je ne l'ai pas vu.
    • [^] # Re: et la place disque ?

      Posté par . Évalué à 1.

      > 4 Ko minimum par fichier

      Non. C'est 4 Ko maxi et 1 Ko mini.

      > Ca n'est éventuellement acceptable qu'avec Reiserfs

      Reiserfs est rarement utilisé avec l'option "tail" car beaucoup plus lent que "notail" (équivalent à ext3).

      Puis fesont quelque calcule.
      1 DD = 80 Go.
      0,1 % DD = 800 Mo
      1k / (value/key) => 800 000 valeurs.
      4k / (value/key) => 200 000 valeurs.

      PS : Ça m'étonnerait fort qu'il y est un fichier par paire clée/valeur.
      • [^] # Re: et la place disque ?

        Posté par . Évalué à 1.

        Avant de parler de limitation en nombre d'inode pour ext3, sachez qu'un disque de 80 Go (bas de gamme) avec ext3 (dans sa configuration par défaut) aura près de 10 millions d'inode !

        Si c'est pas assez, on peut monter à 80 millions. Ce qui est aussi la limite de reiserfs.
    • [^] # Re: et la place disque ?

      Posté par . Évalué à 1.

      Avec Elektra, il est possible d'aller jusqu'à un fichier par paire, mais tu peux - et je pense que ce sera généralement le cas - mettre plusieurs paires par fichier.
  • # gnome systeme tools

    Posté par (page perso) . Évalué à 1.

    Quand même, c'est gavant de devoir choisir la distribution que l'on a dans les gnome-system-tools, OK, il pourrait faire de la detection auto, quoi que ce ne soit pas fiable, mais une certaine uniformisation serait bien.

    Et je crois pas que ça plairait que tout le monde s'aligne sur Debian ou Suse ou RH ou Mdk ...
  • # Un fichier de config unique non un outil unique bof

    Posté par . Évalué à -2.

    Une des qualité que j'apprécie surtout sous Linux et sous Unix en général ce sont les fichiers de config simple et lisibles. Une enorme ficher contenant toute la config serait illisible de par sa taille et je parle meme pas d'un fichier binaire.
    Un outils unique pour toute la config serait pas mal, encore que vu la quantite de parametre et d'applis il deviendait vite un vrai fouillis.
    Bref je trouve que au niveau config, il serait idiot d'essayer d'imiter Windows avec son imbitable base de registre

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.