Que le support final soit un fichier texte n'a rien à voir avec la résilience, l'important c'est comment ce fichier est manipulé.
Je suis bien d'accord, c'est juste que parfois utiliser une base de données (relationnelle ou pas) qui fait ce genre de travail, et même si c'est pas très compliqué en soi, c'est plus simple que de le refaire soi-même
Berkeley DB, c'est ce qui manipule le fichier /etc/passwd des UNIX-like. Le fichier reste un fichier texte, mais c'est une base de données.
Les bases de données, à l'origine, c'était des dossiers avec des fichiers, mais c'était inefficace, à l'époque les systèmes de fichiers étaient moins bien faits que de nos jours, et avec des contraintes différentes. Donc ils ont fini par tout coller dans un fichier, géré par un seul logiciel en daemon (SGBD), et de fil en aiguille ça a fini par faire des SGBDR, puis le relationnel a fini par péter, et on est (re?)passé au NoSQL (Not only SQL) comme si c'était une nouveauté, alors qu'en fait c'est juste comme ça qu'on faisait avant...
Il ne faut pas oublier que les systèmes de fichier sont des bases de données. En fonction des réglages, ils sont plus efficaces pour des entrées de tailles variables, et la doc (pour les régler) n'est pas forcément simple à trouver, c'est vrai, mais je pense que dans pas mal de situations ils sont plus efficaces que des logiciels userland (déjà, eux sont potentiellement intégrés au noyau, rien que ça... sans parler du fait qu'ils soient administrables avec des outils classiques).
ceci dit, ce n'est pas forcément parce qu'un programme propose des fonctionnalités que tu n'utilises pas, qu'il y a plus de bugs dans celles que tu utilises, ça dépend de beaucoup de facteurs: comment les fonctionnalités interagissent entre elles, combien elles sont testées, etc.
Non, mais plus il y a de fonctionnalités, plus la complexité est élevée, et plus le risque de bugs non-triviaux est élevé. Et cela inclue les effets de bords des fonctionnalités non utilisées sur celles qui le sont.
Ce n'est pas pour rien que KISS est très plébiscité (parfois trop d'ailleurs) dans le libre.
j'ai utilisé sqlite c'est pour écrire un petit moteur de forum (où pour le coup c'est bien pratique).
C'est le genre de choses pour lesquelles un SGBDR est conçu, et malgré mon désamour du SQL je suis bien content de le trouver dans ces moments la.
En fait, dès lors qu'il y a de nombreuses relations entres les objets à manipuler, les SGBDR sont très, très utiles. Malgré que je trouve le SQL absolument horrible.
Après, je ne vais pas te défendre le cas particulier de firefox
Je n'ai pris que le seul exemple qui reste sur mon système, en même temps. C'était juste histoire de prouver que ce n'est pas parce que l'on utilise des logiciels bien fichus (j'ai tendance à penser que sqlite l'est) que l'on produit un logiciel lui-même bien foutu.
Ceci dit, je suis persuadé que c'est loin d'être limité à Firefox. Par exemple, je ne serai pas surpris que Gnome ou KDE stockent leurs configuration dans des fichiers sqlite. Un peu comme... regedit (sauf qu'il reste a prouver que regedit soit un SGBDR, hein).
Si j'avais la motivation je pourrais faire une analyse des logiciels avec une dépendance directe à sqlite présents dans le dépôt Debian, mais j'ai choisi la facilité: quand j'installe un logiciel, je regarde de quoi il dépend, et s'il m'ajoute plus de 5 lib, je cherche une alternative (parfois il n'y en a pas, mais c'est quand même relativement rare).
Je regarde aussi si les dépendances me semblent pertinentes, par rapport au job du soft. Ces vérifications nécessitent une chose par contre: garder tout le temps un système relativement simple. Ma Debian n'a du coup rien à voir avec une Debian par défaut...
[^] # Re: Fossil
Posté par freem . En réponse au journal Le danger github. Évalué à 3.
Berkeley DB, c'est ce qui manipule le fichier /etc/passwd des UNIX-like. Le fichier reste un fichier texte, mais c'est une base de données.
Les bases de données, à l'origine, c'était des dossiers avec des fichiers, mais c'était inefficace, à l'époque les systèmes de fichiers étaient moins bien faits que de nos jours, et avec des contraintes différentes. Donc ils ont fini par tout coller dans un fichier, géré par un seul logiciel en daemon (SGBD), et de fil en aiguille ça a fini par faire des SGBDR, puis le relationnel a fini par péter, et on est (re?)passé au NoSQL (Not only SQL) comme si c'était une nouveauté, alors qu'en fait c'est juste comme ça qu'on faisait avant...
Il ne faut pas oublier que les systèmes de fichier sont des bases de données. En fonction des réglages, ils sont plus efficaces pour des entrées de tailles variables, et la doc (pour les régler) n'est pas forcément simple à trouver, c'est vrai, mais je pense que dans pas mal de situations ils sont plus efficaces que des logiciels userland (déjà, eux sont potentiellement intégrés au noyau, rien que ça... sans parler du fait qu'ils soient administrables avec des outils classiques).
Non, mais plus il y a de fonctionnalités, plus la complexité est élevée, et plus le risque de bugs non-triviaux est élevé. Et cela inclue les effets de bords des fonctionnalités non utilisées sur celles qui le sont.
Ce n'est pas pour rien que KISS est très plébiscité (parfois trop d'ailleurs) dans le libre.
C'est le genre de choses pour lesquelles un SGBDR est conçu, et malgré mon désamour du SQL je suis bien content de le trouver dans ces moments la.
En fait, dès lors qu'il y a de nombreuses relations entres les objets à manipuler, les SGBDR sont très, très utiles. Malgré que je trouve le SQL absolument horrible.
Je n'ai pris que le seul exemple qui reste sur mon système, en même temps. C'était juste histoire de prouver que ce n'est pas parce que l'on utilise des logiciels bien fichus (j'ai tendance à penser que sqlite l'est) que l'on produit un logiciel lui-même bien foutu.
Ceci dit, je suis persuadé que c'est loin d'être limité à Firefox. Par exemple, je ne serai pas surpris que Gnome ou KDE stockent leurs configuration dans des fichiers sqlite. Un peu comme... regedit (sauf qu'il reste a prouver que regedit soit un SGBDR, hein).
Si j'avais la motivation je pourrais faire une analyse des logiciels avec une dépendance directe à sqlite présents dans le dépôt Debian, mais j'ai choisi la facilité: quand j'installe un logiciel, je regarde de quoi il dépend, et s'il m'ajoute plus de 5 lib, je cherche une alternative (parfois il n'y en a pas, mais c'est quand même relativement rare).
Je regarde aussi si les dépendances me semblent pertinentes, par rapport au job du soft. Ces vérifications nécessitent une chose par contre: garder tout le temps un système relativement simple. Ma Debian n'a du coup rien à voir avec une Debian par défaut...