Une des nombreuses réserves que j'éprouve face à ce projet, c'est l'unification de la syntaxe. C'est peut-être idiot, mais j'ai eu du mal à comprendre la syntaxe de sudoers, exposée dans les pages de man comme "Extended Backus-Naur Form". Ouais, bah je préfère nettement la "simple smb.conf-xorg.conf form", moi. Alors si le concepteur est un fan de Backus, je vais devoir me refaire des pages de man tordues pour pouvoir éditer mes fichiers à la main. Et en plus, dans tous les fichiers ce sera cette syntaxe abhorrée que je retrouverais. Auuuuuugh !
Ensuite, le débat mode texte contre clickodrome. Je suis un linuxien fraichement émoulu, je n'ai quitté le giron de Windows que depuis un an. Et LA tare de Windows, c'est que dès que le graphique ne marche plus, ça devient l'enfer. Si le mode "Sans échec" ne boote plus, c'est généralement l'hallali, parce qu'on a quasiment plus rien pour examiner le disque dur ni le soigner. Alors je préfère nettement avoir des outils dédiés au mode texte, que des clickodromes "user-friendly" pleins de jolis effets ou de clippy survoltés :) Donc leur système a intérêt à être très abordable en mode texte. Je détesterais avoir à rechercher un fichier de conf super important dans le répertoire .kde par exemple. Alors si leur registry ressemble à ça, non merci.
En tant qu'ex-windowsien, je suis sensé être le plus géné par le système etc. Et pourtant, c'est l'une des choses que j'apprécie le plus sous Linux ! Le nombre de fois ou une expérience à mal tournée et ou j'ai pu localiser le fichier fautif, puis le corriger, même à partir d'un CD bootable ! J'ai déjà soulevé le problème de l'aspect du répertoire du registry... Est-ce que les noms seront humainement reconnaissables, ou bien seront-ils optimisés pour l'application chargée du registre ? Le fait est que la plupart du temps, quand on doit vraiment modifier un fichier de conf, c'est qu'on est dans une situation peu enviable. Alors rajouter une surcouche pour rendre plus confortable leur édition dans les situations normales, c'est inutile. Franchement, je n'ai pas besoin d'un "regedit" pour modifier les paramètres de K3B !
Et le problème des dossiers cachés dans le $HOME ne justifie pas ce massacre. A la limite, pourquoi ne pas ajouter une variable $CONFIG qui éviterait les astuces comme le répertoire "domus" plus haut ? Au lieu de s'acharner sur le $HOME, les programmes écriraient paisiblement dans un répertoire spécifique.
# Mouais...
Posté par JaguarWan . En réponse à la dépêche Une base de registre pour Linux ?. É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.