ouais, enfin dans un des sous répertoires de /etc en général, et ce n'est pas toujours si simple à trouver si on ne connait pas le nom du fichier à l'avance.
ou alors dans un .xxxx du répertoire home
ou alors dans une clé de gconf (ben oui, on a beau critiquer la base de registre c'est un concept pas idiot).
ou alors dans un /usr/kde/version/..... planqué quelque part
Ben en fait, si c'est une config système editable en texte c'est dans /etc, si c'est une config perso c'est dans $HOME/.xxx
Après c'est vrai que les environnements graphiques monstres, à mon avis vaut mieux pas toucher à la config en direct même si je le regrette.
L'idée du .conf dans le $HOME est pas mal, mais à mon avis c'est un peu plus compliqué à mettre en oeuvre vu qu'il faut demander à chaque appli de modifier son comportement par defaut.
Question: existe-t-il une option dans les installeurs rpm/apt/yast pour pouvoir préciser lors d'un déploiement d'appli que les fichiers de conf seront à tel ou tel endroit?
Je ne vois pas en quoi la gestion des paquets est mauvaise sous GNU/Linux.
Ben, comment je fais quand j'ai cassé ma base rpm et que les rpm me sortent un "Seg fault" ?
Bien sûr il aurait fallu faire des sauvegardes, bien sûr le système rpm n'est pas le meilleur, etc...
Mais bon, un système qui permet de se passer d'une base de données "fermée" enfin pas trop ouverte, je pense que çà peut être bien.
En poussant, le raisonnement, tu pourrais dire que les ceintures de sécurité ne servent à rien, pas plus que les feux de circulation: il suffit de bien conduire et bien faire attention
Et question noyau, on pourrait appliquer le même raisonnement au scheduler: à quoi il sert celui-là? les applications, si elles sont bien écrites devraient "passer la main" sans qu'on soit obliger de leur retirer la cpu... Tiens çà me rappelle un "os"...
Moi je pense que le noyau est le garant de ce qu'il exécute. Par conséquent, ce type de développement n'est pour moi pas "une sécurité supplémentaire" mais une fonctionnalité indispensable au bon fonctionnement du noyau.
[^] # Re: Une fois de plus, les votes
Posté par helf (site web personnel) . En réponse à la dépêche GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution. Évalué à 2.
Fichiers cachés : les fichiers de configuration.
1) pb le .bashrc c'est de la conf ou de l'exec? Les .xxxx ne sont pas que du stockage de config. Donc ce n'est pas homogène.
2) quand j'ai trop de fichiers dans un repertoire, je cree des sous repertoires. Donc quand j'ai trop de .xxxx, je crée des repertoires ad'hoc.
Finalement, pourquoi ne pas créer un .conf , un .rc, un .data, un .desktops ?
[^] # Re: Une fois de plus, les votes
Posté par helf (site web personnel) . En réponse à la dépêche GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution. Évalué à 2.
ouais, enfin dans un des sous répertoires de /etc en général, et ce n'est pas toujours si simple à trouver si on ne connait pas le nom du fichier à l'avance.
ou alors dans un .xxxx du répertoire home
ou alors dans une clé de gconf (ben oui, on a beau critiquer la base de registre c'est un concept pas idiot).
ou alors dans un /usr/kde/version/..... planqué quelque part
Ben en fait, si c'est une config système editable en texte c'est dans /etc, si c'est une config perso c'est dans $HOME/.xxx
Après c'est vrai que les environnements graphiques monstres, à mon avis vaut mieux pas toucher à la config en direct même si je le regrette.
L'idée du .conf dans le $HOME est pas mal, mais à mon avis c'est un peu plus compliqué à mettre en oeuvre vu qu'il faut demander à chaque appli de modifier son comportement par defaut.
Question: existe-t-il une option dans les installeurs rpm/apt/yast pour pouvoir préciser lors d'un déploiement d'appli que les fichiers de conf seront à tel ou tel endroit?
[^] # Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par helf (site web personnel) . En réponse à la dépêche GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution. Évalué à 1.
Ben, comment je fais quand j'ai cassé ma base rpm et que les rpm me sortent un "Seg fault" ?
Bien sûr il aurait fallu faire des sauvegardes, bien sûr le système rpm n'est pas le meilleur, etc...
Mais bon, un système qui permet de se passer d'une base de données "fermée" enfin pas trop ouverte, je pense que çà peut être bien.
[^] # Re: Rappels aux développeurs...
Posté par helf (site web personnel) . En réponse à la dépêche Exec Shield: protection contre les débordements de tampons. Évalué à 5.
Et question noyau, on pourrait appliquer le même raisonnement au scheduler: à quoi il sert celui-là? les applications, si elles sont bien écrites devraient "passer la main" sans qu'on soit obliger de leur retirer la cpu... Tiens çà me rappelle un "os"...
Moi je pense que le noyau est le garant de ce qu'il exécute. Par conséquent, ce type de développement n'est pour moi pas "une sécurité supplémentaire" mais une fonctionnalité indispensable au bon fonctionnement du noyau.