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
- Les spécifications du projet sur Sourceforge (52 clics)
- Interview d'Avi Alkalay, membre du "Linux Registry Project" (20 clics)
- Un éditeur de base de registre Linux (94 clics)
- Une présentation du projet au format OOo (14 clics)
# Tentative de record ?
Posté par Dring . Évalué à 6.
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 Dafatfab . Évalué à 4.
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 gnumdk (site web personnel) . Évalué à 9.
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 Philippe F (site web personnel) . Évalué à 10.
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 007 . Évalué à -1.
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 Xavier Teyssier (site web personnel) . Évalué à -2.
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 Infernal Quack (site web personnel) . Évalué à 3.
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 Xavier Teyssier (site web personnel) . Évalué à -2.
Inutilisez moi, et m'en vais me flagellez, ou plutôt apprendre à lire :-(
[^] # Re: Tentative de record ?
Posté par Pierre . Évalué à -6.
Et apprendre à écrire ?? :-))
[^] # Re: Tentative de record ?
Posté par Anonyme . Évalué à 4.
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 Nap . Évalué à 2.
je n'aime pas les fausses réparations d'injustice :)
[^] # Re: Tentative de record ?
Posté par foulmetal canette (site web personnel) . É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 Toto . Évalué à 3.
[^] # Re: Tentative de record ?
Posté par Temsa (site web personnel) . Évalué à 3.
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 Étienne . Évalué à 1.
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 Dring . Évalué à 1.
[^] # Re: Tentative de record ?
Posté par Anonyme . Évalué à 1.
Ça semble correspondre, à peu près, à ton point de vue.
[^] # Re: Tentative de record ?
Posté par gnujsa . Évalué à 1.
directory = répertoire
folder = dossier
</mode capillotraction>
Ça n'est pas rigoureusement la même chose :)
[^] # Re: Tentative de record ?
Posté par fat_cartman . Évalué à 2.
directory = annuaire (oui, oui, le D de LDAP ou de MS AD, c'est ca :)) )
[^] # Re: Tentative de record ?
Posté par Erwan . Évalué à 3.
[^] # Re: Tentative de record ?
Posté par Dring . Évalué à 3.
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 Infernal Quack (site web personnel) . Évalué à 2.
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 yoho (site web personnel) . Évalué à 1.
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 Jean-Max Reymond (site web personnel) . Évalué à 10.
D'expérience, vaut mieux ne pas laisser trainer des fichiers dans un répertoire d'accueil :-(
[^] # Re: Tentative de record ?
Posté par Mr_max . Évalué à 0.
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 Tof . Évalué à 2.
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 Erwan . Évalué à 2.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Tentative de record ?
Posté par Dring . Évalué à 1.
Merci !
[^] # Un nom pour ce projet
Posté par zaurus (site web personnel) . Évalué à 0.
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 Infernal Quack (site web personnel) . Évalué à 10.
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 B r u n o (site web personnel) . Évalué à 2.
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 Infernal Quack (site web personnel) . Évalué à 7.
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 B r u n o (site web personnel) . Évalué à 3.
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 a_jr . Évalué à 3.
Les informations de configuration (clef-valeur) sont stockées dans des fichiers textes UTF-8
[^] # Re: Tentative de record ?
Posté par Pierre Jarillon (site web personnel) . Évalué à 2.
[^] # Re: Tentative de record ?
Posté par Nap . Évalué à 4.
[^] # Re: Tentative de record ?
Posté par Remi Bonnet . Évalué à 2.
[^] # Re: Tentative de record ?
Posté par Pierre Tramo (site web personnel) . Évalué à 8.
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 Nap . Évalué à 3.
[^] # Re: Tentative de record ?
Posté par petit_bibi . Évalué à 3.
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 fdp3 . Évalué à 2.
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 Dring . Évalué à 2.
[^] # Re: Tentative de record ?
Posté par petit_bibi . Évalué à 1.
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 Prosper . Évalué à 2.
[^] # Re: Tentative de record ?
Posté par Obsidian . Évalué à 2.
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 Xavier Teyssier (site web personnel) . Évalué à 9.
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 Jean-Philippe . Évalué à 0.
[^] # Re: Avec les mêmes défauts que sous Windows ?
Posté par Dafatfab . Évalué à 1.
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 Babelouest (site web personnel) . Évalué à 3.
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 a_jr . Évalué à 5.
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 demik . Évalué à 2.
[^] # Re: Avec les mêmes défauts que sous Windows ?
Posté par a_jr . Évalué à 1.
Avec un peu de chance, par contre, des GUi sympathiques implementeront des fonctions de recherche ?
[^] # Re: Avec les mêmes défauts que sous Windows ?
Posté par Erwan . Évalué à 2.
[^] # Re: Avec les mêmes défauts que sous Windows ?
Posté par Toufou (site web personnel) . Évalué à -1.
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 Olivier . Évalué à 3.
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 Étienne . É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 Jean-Max Reymond (site web personnel) . Évalué à 10.
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 arkos (site web personnel) . Évalué à 1.
voilà de bonnes bases de réflexions
[^] # Re: Avec les mêmes défauts que sous Windows ?
Posté par snt . Évalué à 10.
- 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 Christophe Chailloleau-Leclerc . Évalué à 9.
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 gnumdk (site web personnel) . Évalué à 4.
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 Christophe Chailloleau-Leclerc . Évalué à 4.
[^] # Re: Avec les mêmes défauts que sous Windows ?
Posté par gnumdk (site web personnel) . Évalué à 2.
J'aime beaucoup ce quand a fait Suse par exemple.
[^] # Re: Avec les mêmes défauts que sous Windows ?
Posté par Christophe Chailloleau-Leclerc . Évalué à 2.
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 DiZ . Évalué à 1.
Pourquoi ?
[^] # Re: Avec les mêmes défauts que sous Windows ?
Posté par Christophe Chailloleau-Leclerc . Évalué à 3.
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 gpe . Évalué à 3.
[^] # Re: Avec les mêmes défauts que sous Windows ?
Posté par DiZ . Évalué à -3.
> 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 Christophe Chailloleau-Leclerc . Évalué à 6.
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 DiZ . Évalué à 1.
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 Christophe Chailloleau-Leclerc . Évalué à 6. Dernière modification le 24 août 2019 à 14:35.
>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://www.oiseau-libre.net/Animaux/Animaux%20sauvages/Putois.html (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…) (NdM: lien corrigé)
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 Jimmy . Évalué à 1. Dernière modification le 24 août 2019 à 14:36.
C'est koi ce lien en
http://httpqui 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 Guillaume Knispel . Évalué à 2.
Je me demande toujours pourquoi...
Il faudrait coder un verificateur d'url sous moz / firetruc, qui vire les http doublons, parce que la c'est clair que ca craint.
[^] # Re: Avec les mêmes défauts que sous Windows ?
Posté par Christophe Chailloleau-Leclerc . Évalué à 2.
[^] # Re: Avec les mêmes défauts que sous Windows ?
Posté par Toufou (site web personnel) . Évalué à 0.
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 fouyaya . Évalué à 0.
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 Christophe Chailloleau-Leclerc . Évalué à 10.
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 fouyaya . Évalué à -2.
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 Christophe Chailloleau-Leclerc . Évalué à 4.
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 fouyaya . Évalué à 1.
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 Christophe Chailloleau-Leclerc . Évalué à 3.
- 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 gnumdk (site web personnel) . Évalué à 1.
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 Christophe Chailloleau-Leclerc . Évalué à 2.
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.
-- 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
-- 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 gnumdk (site web personnel) . Évalué à 1.
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 Christophe Chailloleau-Leclerc . Évalué à 2.
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 gnumdk (site web personnel) . Évalué à 2.
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 Christophe Chailloleau-Leclerc . Évalué à 2.
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 007 . Évalué à 2.
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 gnumdk (site web personnel) . Évalué à 2.
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 007 . Évalué à 1.
Ç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 Sayena Yefka . Évalué à 4.
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 Sayena Yefka . Évalué à -2.
[^] # Re: Avec les mêmes défauts que sous Windows ?
Posté par ced . Évalué à -5.
[^] # Re: Avec les mêmes défauts que sous Windows ?
Posté par Robert Palmer (site web personnel) . Évalué à 2.
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
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Avec les mêmes défauts que sous Windows ?
Posté par gnumdk (site web personnel) . Évalué à 1.
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"? :)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: le Registre n'est pas la distro !
Posté par gnumdk (site web personnel) . Évalué à 3.
"si Gnome, KDE, etc. fournissent un seul utilitaire permettant d'éditer le maximum de config, ça aiderai le noobs."
Ca existe deja, ca s'appelle Kconfigeditor et ca permet d'editer les deux :)
http://extragear.kde.org/apps/kconfigeditor/kconfigeditor3.png(...)
# N'importe
Posté par Jerome Alet (site web personnel) . Évalué à -10.
# ?? Pourquoi changer ??
Posté par Julien Hamard . Évalué à 6.
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 snt . Évalué à 5.
[^] # Re: ?? Pourquoi changer ??
Posté par Joris Dedieu (site web personnel) . Évalué à 5.
C'est vrai pourquoi registre ? Ça n'a finalement rien à voir et ça évoque forcement de mauvais souvenirs.
[^] # Re: ?? Pourquoi changer ??
Posté par Geo Vah . Évalué à 4.
"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 tgl . Évalué à 3.
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 Infernal Quack (site web personnel) . Évalué à 8.
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 Infernal Quack (site web personnel) . Évalué à 1.
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: SUIVEZ LES LIENS NON D'UNE PIPE !!!
Posté par python . Évalué à -4.
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 python . Évalué à -2.
Je suis un kadreg en puissance !
gloire à kadreg
[^] # Re: SUIVEZ LES LIENS NON D'UNE PIPE !!!
Posté par Arachne . Évalué à 1.
[^] # Re: SUIVEZ LES LIENS NON D'UNE PIPE !!!
Posté par Arachne . Évalué à 1.
# Ca existe déjà...
Posté par Simon TRENY . Évalué à 4.
[^] # Re: Ca existe déjà...
Posté par ruz revr . Évalué à 4.
- 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 Éric (site web personnel) . Évalué à 3.
> 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 Tutur . Évalué à 1.
Le probleme c'est qu'on sait pas a quoi correspondent les options.
[^] # Re: Ca existe déjà...
Posté par Croconux . Évalué à 3.
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 Infernal Quack (site web personnel) . Évalué à 2.
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 Philippe F (site web personnel) . Évalué à 4.
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 tanguy_k (site web personnel) . Évalué à 2.
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 jmfayard . Évalué à 3.
====
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 Guillaume Knispel . Évalué à 3.
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 Troy McClure (site web personnel) . Évalué à 9.
http://freshmeat.net/projects/registry/(...) :
[^] # Re: Ca existe déjà...
Posté par Laurent Go . Évalué à 2.
[^] # Re: Ca existe déjà...
Posté par Narishma Jahar . Évalué à 1.
# Et /etc, et /etc/sysconfig ?
Posté par Sébastien Rohaut . Évalué à -8.
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 Infernal Quack (site web personnel) . Évalué à 9.
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 Xavier Teyssier (site web personnel) . Évalué à 5.
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 ndesmoul . Évalué à 2.
- 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 alexs8z . Évalué à 4.
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 gpe . Évalué à 4.
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 Philippe F (site web personnel) . Évalué à 2.
[^] # Re: Et /etc, et /etc/sysconfig ?
Posté par gnumdk (site web personnel) . Évalué à 1.
[^] # Re: Et /etc, et /etc/sysconfig ?
Posté par Sébastien Rohaut . Évalué à 3.
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 a_jr . Évalué à 3.
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 Toufou (site web personnel) . Évalué à -7.
Bref, pourquoi pas s'il y en a qui aiment, mais je n'utiliserais pas ça chez moi.
[^] # Re: Quelle horreur
Posté par Jean-Max Reymond (site web personnel) . Évalué à 4.
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 :-)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Quelle horreur
Posté par Gilles Crebassa . Évalué à 1.
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 Toufou (site web personnel) . Évalué à 1.
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 nullisimo . Évalué à 7.
# linuxfr est à la bourre pour ce troll là ;)
Posté par Christophe Fergeau . Évalué à 6.
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
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
# Et defaults sous GNUstep...
Posté par nicolassanchez . Évalué à 9.
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...
[^] # Re: Et defaults sous GNUstep...
Posté par L Guillaume . Évalué à 1.
# Maj
Posté par Aurélien Bompard (site web personnel) . Évalué à 4.
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 Gilles Crebassa . Évalué à 1.
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 Aurélien Bompard (site web personnel) . Évalué à 2.
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 Gilles Crebassa . Évalué à 1.
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 Croconux . Évalué à 4.
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 Wawet76 (site web personnel) . Évalué à 4.
Apparement ils proposent une espèce d'arborescence pour les noms de clé, mais ça reste assez limité non ?
[^] # Re: Clé/valeur ?
Posté par yoho (site web personnel) . Évalué à 2.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Clé/valeur ?
Posté par Amand Tihon (site web personnel) . Évalué à 2.
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.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Clé/valeur ?
Posté par yoho (site web personnel) . Évalué à 2.
[^] # Re: Clé/valeur ?
Posté par Thomas Douillard . Évalué à 1.
Cond1.valeur = bidou
NonCond1.valeur = toubidou ?
éventuellement par une arborescence ?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Clé/valeur ?
Posté par a_jr . Évalué à 1.
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 nicolassanchez . Évalué à 1.
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 tpierron . Évalué à 2.
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 Bruce Le Nain (site web personnel) . Évalué à 4.
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 nicolassanchez . Évalué à 1.
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 Seneque Xavier . Évalué à 5.
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 Infernal Quack (site web personnel) . Évalué à 1.
...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 karteum59 . Évalué à 0.
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 Infernal Quack (site web personnel) . Évalué à 9.
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 gpe . Évalué à 0.
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 Infernal Quack (site web personnel) . Évalué à 2.
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 gpe . Évalué à -1.
[^] # Re: Moi je trouve que c'est une bonne idée
Posté par a_jr . Évalué à 6.
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 karteum59 . Évalué à 1.
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 gnumdk (site web personnel) . Évalué à 3.
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 _alex . Évalué à 2.
cf http://www.sme-fr.homelinux.net/templates.php(...)
Les fichiers /etc/* sont généré à partir de templates. Il y a peut être quelques choses à en tirer.
[^] # Re: Moi je trouve que c'est une bonne idée
Posté par Thomas Hervé . Évalué à 2.
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 python . Évalué à 1.
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.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Moi je trouve que c'est une bonne idée
Posté par Jllc . Évalué à 3.
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 Lithium . Évalué à -1.
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.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
# Perte de temps ?
Posté par Arnaud . Évalué à 0.
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 a_jr . Évalué à 1.
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 _alex . Évalué à 4.
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 . Évalué à -1.
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 . Évalué à 1.
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 . Évalué à 1.
# et gconf ?
Posté par - - . Évalué à 2.
(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 (site web personnel) . Évalué à 3.
[^] # Re: Format de stockage
Posté par daggett . Évalué à 2.
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 JaguarWan . Évalué à 3.
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 (site web personnel) . Évalué à 1.
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 Benjamin (site web personnel) . Évalué à 2.
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 Ulysse (site web personnel) . Évalué à 1.
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 Matthieu . Évalué à 2.
[^] # Re: Pour être concret
Posté par Infernal Quack (site web personnel) . Évalué à 2.
- 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 chl (site web personnel) . Évalué à 1.
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 Vlobulle . Évalué à 2.
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 Fabimaru (site web personnel) . Évalué à 2.
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 lcpt . Évalué à 1.
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 gnumdk (site web personnel) . Évalué à 3.
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 Christophe Chailloleau-Leclerc . Évalué à 3.
[^] # Re: Pour être concret
Posté par lcpt . Évalué à 1.
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 kd . Évalué à 2.
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 Eric Lacroix . Évalué à 1.
C'est un peu tiré par les cheuveux, mais c'est presque ça (avec en plus un $HOME/etc oups, $HOME/.config :) )
[^] # Re: ln (-s ?) /etc /config :)
Posté par Eric Lacroix . Évalué à 0.
# pour le fun
Posté par farib . Évalué à 5.
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 . Évalué à -5.
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 Infernal Quack (site web personnel) . Évalué à 4.
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 Nicolas "Chewibaka" CHEVE . Évalué à -2.
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 Christophe Chailloleau-Leclerc . Évalué à 4.
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 --->[]
[^] # Re: Mes 2centimes d'euros
Posté par Bruce Le Nain (site web personnel) . Évalué à 1.
# c'est idiot mais ...
Posté par acabiran . Évalué à 2.
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 Staz . Évalué à 3.
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 gnumdk (site web personnel) . Évalué à 2.
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 Gart Algar . Évalué à 2.
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 gnumdk (site web personnel) . Évalué à 2.
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 Dring . Évalué à 1.
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 Tutur . Évalué à 3.
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 benja . Évalué à 0.
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 . Évalué à 2.
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 . Évalué à 1.
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 Dring . Évalué à 1.
[^] # Re: config complexes
Posté par Thierry GRAUSS . Évalué à 1.
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 g_allegre . Évalué à 1.
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 007 . Évalué à 1.
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 007 . Évalué à 1.
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 Dring . Évalué à 1.
# Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
# Un fichier de config unique non un outil unique bof
Posté par Hodj . Évalué à -2.
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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.