jeudi 02 juillet
Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Liens connexes

Dépêche modérée par

Dépêche éditée par

: Une base de registre pour Linux ?

Posté par effco (). Modéré le 30 août 2004.
0
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.

> Lire la suite (228 commentaires, moyenne: 2,2).   [dépêche : 1288 caractères]

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.

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

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

Tentative de record ?

Posté par Dring FirebirdVsMySql () le 30/08/2004 à 08:02. (lien). É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.

--
Non, rien.

Avec les mêmes défauts que sous Windows ?

Posté par Xavier Teyssier (Jabber id, page perso, ) le 30/08/2004 à 08:03. (lien). É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 ?

[+] N'importe

Posté par Jerome Alet (page perso, ) le 30/08/2004 à 08:09. (lien). Évalué à -10.

Nawak !

?? Pourquoi changer ??

Posté par Julien Hamard () le 30/08/2004 à 08:12. (lien). É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.

SUIVEZ LES LIENS NON D'UNE PIPE !!!

Posté par Infernal Quack (Jabber id, page perso, ) le 30/08/2004 à 08:14. (lien). É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\

Ca existe déjà...

Posté par Simon TRENY () le 30/08/2004 à 08:17. (lien). É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.

[+] Et /etc, et /etc/sysconfig ?

Posté par Sébastien Rohaut (page perso, ) le 30/08/2004 à 08:21. (lien). É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 ?

[+] Quelle horreur

Posté par Toufou (page perso, ) le 30/08/2004 à 08:33. (lien). É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.

mais encore...

Posté par nullisimo () le 30/08/2004 à 08:36. (lien). É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 Christophe Fergeau () le 30/08/2004 à 08:40. (lien). É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 nicolassanchez () le 30/08/2004 à 08:40. (lien). É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 Aurélien Bompard (Jabber id, page perso, ) le 30/08/2004 à 08:52. (lien). É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...

Clé/valeur ?

Posté par Wawet76 (page perso, ) le 30/08/2004 à 08:52. (lien). É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 ?

Moi je trouve que c'est une bonne idée

Posté par Seneque Xavier (page perso, ) le 30/08/2004 à 08:58. (lien). É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 ... )

[+] reinventé la roue ?

Posté par Lithium () le 30/08/2004 à 09:41. (lien). É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 Arnaud (page perso, ) le 30/08/2004 à 09:42. (lien). É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
...

Les inodes ?

Posté par _alex () le 30/08/2004 à 09:53. (lien). É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 Dalton joe (page perso, ) le 30/08/2004 à 10:08. (lien). É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 Pinaraf (Jabber id, ) le 30/08/2004 à 10:20. (lien). É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 Sharpshooter () le 30/08/2004 à 10:56. (lien). Évalué à 1.

Small is beautiful !

et gconf ?

Posté par - - () le 30/08/2004 à 11:38. (lien). É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 Olivier Serve (Jabber id, page perso, ) le 30/08/2004 à 12:37. (lien). É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 ?

Mouais...

Posté par JaguarWan () le 30/08/2004 à 13:28. (lien). É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 Ulysse (page perso, ) le 30/08/2004 à 13:32. (lien). É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?

ln (-s ?) /etc /config :)

Posté par Eric Lacroix () le 30/08/2004 à 14:30. (lien). É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 farib () le 30/08/2004 à 14:38. (lien). É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 bpl () le 30/08/2004 à 15:38. (lien). É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

[+] Mes 2centimes d'euros

Posté par Nicolas "Chewibaka" CHEVE () le 30/08/2004 à 18:01. (lien). É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..... :'(

c'est idiot mais ...

Posté par acabiran () le 30/08/2004 à 18:41. (lien). É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

Va y'avoir du boulot

Posté par Tutur () le 30/08/2004 à 21:54. (lien). É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.

--
\_°< C01N C01N ! >°_/

Espoire -- update le projet s'appelle Elektra maintenant

Posté par benja () le 31/08/2004 à 14:46. (lien). É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 Bungee Tux () le 01/09/2004 à 05:20. (lien). É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 Thierry GRAUSS (page perso, ) le 01/09/2004 à 12:27. (lien). É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.

et la place disque ?

Posté par g_allegre () le 02/09/2004 à 15:17. (lien). É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.

gnome systeme tools

Posté par Étienne Bersac (Jabber id, page perso, ) le 03/09/2004 à 09:41. (lien). É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 ...

--
E Ultreïa !

[+] Un fichier de config unique non un outil unique bof

Posté par Jean-Georges Pinna () le 04/09/2004 à 05:56. (lien). É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

Revenir en haut de page

Run by Team LinuxFr.org

Cette page a été générée par Templeet en 0.6037s (dont 0.0374 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !