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 karteum59 (site web personnel) . En réponse à la dépêche Une base de registre pour Linux ?. É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)...