Alors qu'un logiciel de gestion des logiciels traditionnel fonctionne la plupart du temps en relation avec une BDD, que presque tout se passe dans les requêtes SQL et dans les jointures des tables ( j'exagère, je n'ai aucune idée de la façon dont fonctionne RPMDrake ) , ici, SteckDenis nous propose une vision fondamentalement beaucoup plus réfléchie.
Comme tu dis, tu n'a aucune idée de la manière dont ça fonctione et ça ce voit... ;-)
Des gestionnaire de paquets qui utilise SQLlite out une autre base de données SQL, il y en a pas de masses.
La majoritée du temps c'est un format interne tout simplement parce que la gestions de dépendances qui est l'opération la plus complexe qu'ils aient à réaliser ne ce fait pas à coup de jointure mais plutot à coup de solveur SAT pour les plus bourrins.
En constatant _ et c'est une réalité _ la lourdeur de réaction du fonctionnement direct au dessus d'un SQLite ou autre, il nous propose de ( je traduis pour ceux qui n'auraient pas pigé ) _ Charger en mémoire vive ( RAM ) beaucoup plus rapide pour la manipulation de grandes quantités de données , [...]
L'utilisation de la RAM, c'est beaucoup, beaucoup plus rapide que les utilisations par table SQL et fichiers XML.
Même s'il n'y a pas de SQL ou autre dans les gestionnaire de paquets, ce que tu dis reste faux. On est ici sur des données qui font quelques dizaine de Mo, et même en imaginant une base de donnée très lourde qui à un surcout de 50% ça reste sans problème chargeable en mémoire. Je serais surpris que n'importe quelle base de donnée ne charge pas une telle base en mémoire éventuellement de manière indirecte par un mmap.
L'utilisation de la RAM, c'est beaucoup, beaucoup plus rapide que les utilisations par table SQL et fichiers XML.
Deux chose qui n'on absolument rien à voir : le chargement en RAM c'est juste l'endroit ou tes données sont stockée, l'utilisation de SQL ou d'XML c'est la mnière dont tu les stocke à cet endroit. Tu peut stocker du SQL ou du XML en RAM sans problème. (heureusement d'ailleur...)
Et pour ce qui est du surcout éventuel du SQL, il faut bien voir que les bases de données sont optimisées avec éventuellement des index pour accélérer au maximum toutes es opérations de recherche, donc le surcout, il n'éxiste pas vraiment, bien au contraire.
C'est quelques centièmes à quelques dixièmes de secondes en C pour lire un fichier d'1 Mo par exemple . Je suppose qu'en C++, ça va être un peu plus lent, mais c'est rien comparé à la lecture de la même quantité de données dans une table SQL !
C'est un peut hors sujet, mais que tu le fasse en C ou en C++ ça prend le même temps... la meilleur manière de charger ton fichier en mémoire c'est de faire un mmap...
Une table SQL mapper c'est en général juste un mmap pour la charger en mémoire, enfin pas tout à fat charger, juste mapper et elle est chargée à la demande. La strucuture est dans le fichier mapper pas besoin de la reconstruire. Si tu as rééllement besoin de relire tout le fichier explicitement plutot que par un mappage c'est que tu est obliger de reconstruire la structure et donc c'est bien plus lent. Donc soit c'est égalitée, soit c'est SQL qui gagne...
A la suite de ce chargement, le logiciel ( SETUP ) va pouvoir réaliser tous les traitements algorithmiques que vous voulez.
C'est la que le SQL perd car la gestion des dépendances est un problème qui n'est pas adapté à SQL et c'est pour cela que à peu près aucun gestionnaire de paquetages ne l'utilise donc pas d'avantage à logram sur cet aspect.
Pour les algos utilisés, Logram en utilise des plus simples que apt par exemple, car celui-ci utilise un solveur SAT, mais c'est aussi la faiblesse de logram car il ne peut pas gérer tous les cas. Cela à déjà été évoquer dans un des journaux précédents, c'est un choix qu'il à fait.
Il est évident que ce genre de travail aura des répercussions sur tous les gestionnaires de paquets du monde . Et ça, c'est bien. ( surtout si c'est libre ).
C'est cette phrase qui m'a décidé à répondre. Je crois que pour l'instant en tout cas, non logram n'aura que très peu d'impact sur les autre logiciels de gestions de paquet. Ce n'est pas méchant mais réaliste. Setup à des objectifs différents c'est tout.
D'un point de vue fonctionalitées, il n'apporte rien par rapport aux autres, c'est même le contraire.
Son seul avantage c'est la rapiditée (qui demande à être confirmée sur dans les mêmes conditions que pour les autres) et les dev des autres gestionnaires de paquets sont déjà au courrant qu'ils ont des problèmes à ce niveau là, et il y a déjà des personnes qui bosse dessus.
Steckdenis, franchement, continue, ça fait plaisir de voir des gens qui se défoncent , surtout ici .
Là par contre je suis tout à fait d'accord. Il faut pas prendre mon commentaire comme une critique de Logram ou de setup, mais juste une reponse au comentaire du dessus.
Même si je ne voit pas l'utilitée de tes projets pour moi, je suis pas du genre à dire ça sert à rien il y a déjà tout ce qu'il faut. Code ce qui te fait plaisir, moi ça me fait plaisir de voir des gens coder ce qu'il aiment. Et c'est pas par ce que pour l'instant je ne voit rien qui m'intéresse personnellement que je n'y trouverais rien à l'avenir.
Et surtout, continue de nous tenir informer, j'aime bien ce genre de journaux au milieu de tout ceux qui parlent de politique ou autre.
[^] # Re: pas d'accord
Posté par beagf . En réponse au journal Sortie de Setup 0.1-alpha0. Évalué à 10.
Comme tu dis, tu n'a aucune idée de la manière dont ça fonctione et ça ce voit... ;-)
Des gestionnaire de paquets qui utilise SQLlite out une autre base de données SQL, il y en a pas de masses.
La majoritée du temps c'est un format interne tout simplement parce que la gestions de dépendances qui est l'opération la plus complexe qu'ils aient à réaliser ne ce fait pas à coup de jointure mais plutot à coup de solveur SAT pour les plus bourrins.
En constatant _ et c'est une réalité _ la lourdeur de réaction du fonctionnement direct au dessus d'un SQLite ou autre, il nous propose de ( je traduis pour ceux qui n'auraient pas pigé ) _ Charger en mémoire vive ( RAM ) beaucoup plus rapide pour la manipulation de grandes quantités de données , [...]
L'utilisation de la RAM, c'est beaucoup, beaucoup plus rapide que les utilisations par table SQL et fichiers XML.
Même s'il n'y a pas de SQL ou autre dans les gestionnaire de paquets, ce que tu dis reste faux. On est ici sur des données qui font quelques dizaine de Mo, et même en imaginant une base de donnée très lourde qui à un surcout de 50% ça reste sans problème chargeable en mémoire. Je serais surpris que n'importe quelle base de donnée ne charge pas une telle base en mémoire éventuellement de manière indirecte par un mmap.
L'utilisation de la RAM, c'est beaucoup, beaucoup plus rapide que les utilisations par table SQL et fichiers XML.
Deux chose qui n'on absolument rien à voir : le chargement en RAM c'est juste l'endroit ou tes données sont stockée, l'utilisation de SQL ou d'XML c'est la mnière dont tu les stocke à cet endroit. Tu peut stocker du SQL ou du XML en RAM sans problème. (heureusement d'ailleur...)
Et pour ce qui est du surcout éventuel du SQL, il faut bien voir que les bases de données sont optimisées avec éventuellement des index pour accélérer au maximum toutes es opérations de recherche, donc le surcout, il n'éxiste pas vraiment, bien au contraire.
C'est quelques centièmes à quelques dixièmes de secondes en C pour lire un fichier d'1 Mo par exemple . Je suppose qu'en C++, ça va être un peu plus lent, mais c'est rien comparé à la lecture de la même quantité de données dans une table SQL !
C'est un peut hors sujet, mais que tu le fasse en C ou en C++ ça prend le même temps... la meilleur manière de charger ton fichier en mémoire c'est de faire un mmap...
Une table SQL mapper c'est en général juste un mmap pour la charger en mémoire, enfin pas tout à fat charger, juste mapper et elle est chargée à la demande. La strucuture est dans le fichier mapper pas besoin de la reconstruire. Si tu as rééllement besoin de relire tout le fichier explicitement plutot que par un mappage c'est que tu est obliger de reconstruire la structure et donc c'est bien plus lent. Donc soit c'est égalitée, soit c'est SQL qui gagne...
A la suite de ce chargement, le logiciel ( SETUP ) va pouvoir réaliser tous les traitements algorithmiques que vous voulez.
C'est la que le SQL perd car la gestion des dépendances est un problème qui n'est pas adapté à SQL et c'est pour cela que à peu près aucun gestionnaire de paquetages ne l'utilise donc pas d'avantage à logram sur cet aspect.
Pour les algos utilisés, Logram en utilise des plus simples que apt par exemple, car celui-ci utilise un solveur SAT, mais c'est aussi la faiblesse de logram car il ne peut pas gérer tous les cas. Cela à déjà été évoquer dans un des journaux précédents, c'est un choix qu'il à fait.
Il est évident que ce genre de travail aura des répercussions sur tous les gestionnaires de paquets du monde . Et ça, c'est bien. ( surtout si c'est libre ).
C'est cette phrase qui m'a décidé à répondre. Je crois que pour l'instant en tout cas, non logram n'aura que très peu d'impact sur les autre logiciels de gestions de paquet. Ce n'est pas méchant mais réaliste. Setup à des objectifs différents c'est tout.
D'un point de vue fonctionalitées, il n'apporte rien par rapport aux autres, c'est même le contraire.
Son seul avantage c'est la rapiditée (qui demande à être confirmée sur dans les mêmes conditions que pour les autres) et les dev des autres gestionnaires de paquets sont déjà au courrant qu'ils ont des problèmes à ce niveau là, et il y a déjà des personnes qui bosse dessus.
Steckdenis, franchement, continue, ça fait plaisir de voir des gens qui se défoncent , surtout ici .
Là par contre je suis tout à fait d'accord. Il faut pas prendre mon commentaire comme une critique de Logram ou de setup, mais juste une reponse au comentaire du dessus.
Même si je ne voit pas l'utilitée de tes projets pour moi, je suis pas du genre à dire ça sert à rien il y a déjà tout ce qu'il faut. Code ce qui te fait plaisir, moi ça me fait plaisir de voir des gens coder ce qu'il aiment. Et c'est pas par ce que pour l'instant je ne voit rien qui m'intéresse personnellement que je n'y trouverais rien à l'avenir.
Et surtout, continue de nous tenir informer, j'aime bien ce genre de journaux au milieu de tout ceux qui parlent de politique ou autre.