Je te repond ce qui a joue un role pour beaucoup des premiers utilisateurs a l'epoque, j'aurai du rajouter apt-get aussi dedans.
Et c'est bien ce qu'il te reproche : Tu confonds le format de paquet deb et apt-get. Essai d'installer tes paquets avec dkpg, juste pour voir, tu vas voir ce qu'est "deb".
Stallman and the FSF, like his Cretaceous ancestors 65 million years ago, isn’t evolved enough to see that his reign is about to come to an end. The Open world needs interoperability, not shut itself off from other standards just because they originate from proprietary sources.
Tu devrais vraiment jeter un oeil à la doc de Burrows en toute priorité avant de continuer à coder, parce que ton algo est très similaire (sinon similaire) à apt au niveau du design général. Et si ton algo est complet, il sera exponentiellement lent avec la taille des dépôts puisque tu n'implémentes aucune stratégie heuristique.
Et puis, 2.5s pour résoudre des dépendances est toujours trop long.
Pour illustrer mon propos, j'ai mesuré les temps mis par apt et pacman pour installer vim sur le même ordinateur, apt prends environ 10s et pacman 2s, et je les trouve toujours trop lents.
~2.5s pour me calculer un dist-upgrade (sur un laptop vieux de 3 ans avec un DD 5400tpm), pas l'install d'un paquet unique.
C'est vraiment de l'enculage de mouche que tu nous fais.
En l'occurence, avec un solveur sat, le "bottleneck" n'est pas la résolution des dépendances ni la lecture des métadonnées mais le téléchargement et l'installation des paquets.
D'autre part, ces 2.0 - 2.5 secondes ne sont pas linéairement dédiées à la résolution :
Pour finir, je ne vois strictement pas l'intérêt de créer une solution pour un scénario viable dans 10 ou 20 ans alors que tu ne connais strictement rien aux conditions du futur environment (capacité de bande passante, performance disque dur et CPU, calcul quantique ?).
Quitte à créer un solution, autant qu'elle réponde à un besoin d'aujourd'hui, ou elle aura toute les chance d'être obsolète avant même d'être utile.
<i>Pour le solveur SAT, rien que le fait qu'on doive lire tous les paquets est lourds. Il y a peut-être moyen de l'éviter, mais le but est de construire un problème à base de clauses, une ou plusieurs clauses par paquets. Oui, ce sont des clauses simples (comme dit dans la page Zypp, ça doit faire quelques mois que je lis presque tous les jours ce wiki et la doc Doxygen de libzypp), mais il y en a beaucoup.</i>
A te lire, j'ai vraiment l'impression qu'on parle de 2 choses totalement différentes et que tu n'a pas saisi comment le solver d'openSUSE fonctionne. Tu devrais aussi lire la doc de Daniel Burrows et celle du projet EDOS, ainsi que jeter un oeil au fonctionnement du SatSolver ZYpp en utilisation réelle.
Pour mémoire, voici le fonctionnement basic de ZYpp :
1/ teléchargement des métadonnées depuis les dépôts
2/ transformation des métadonnées en fichiers binaires .solv, qui contiennent les règles de dépendances de chacun des paquets
3/ calcul des dépendances
4/ application du résultat
L'étape 1/ est "bottleneck", elle ne dépend pas du solveur, mais du format des md-data et de la qualité de la connexion aux dépôts.
L'étape 2/ utilise une "dictionary approach" pour stocker les dépendances sous la forme d'un nombre 32bits unique, permettant une comparaison très rapide de 2 chaines de "charactères", principe de base du solveur SAT, un espace disque moindre, puisqu'un nombre est plus petit qu'une chaine de charactère (j'ai 4.7 Mo, 4.5 Mo, 3.6 Mo, 406 Ko pour les 4 plus gros dépôts activés qui représentent à eux seul un peu plus de 16'000 paquets, 1.4 Mo pour ma base RPM locale .solv, et mes 14 autres ne font que quelques Ko) et la representation mémoire ne prend pas plus de place sur un système 64bits où un pointer est 2x la taille d'un nombre 32bits (cf. doc SatSolver).
Un refresh forcé de ces fichiers me prends ~9 secondes, mais est surévalué puisque le dépôt principal, qui ne change jamais, est recré (5 sec est plus realiste pour une utilisation standard.. et encore).
L'étape 3/ me calcul les dépendances (par exemple un dist-upgrade me propose une solution en ~2.5 secondes), enfin l'étape 4/ valide les changements et télécharge les paquets proposés.
Au final, le calcul des dépendances est extrêmement rapide malgré le fait qu'un grand nombre de paquets sont pris en compte en mémoire (~2.5 secondes pour +16'000 paquets). J'ai l'impression que le problème que tu essaies de résoudre n'existe tout simplement pas avec un solver sat couplé avec une approche metadonnés-binaire telle qu'implémentée par ZYpp. De plus, la résolution est complète.
[...] montre comment les branches permettent de facilement se tirer du problème dans devoir sortir une artillerie telle que SAT.
Il est complet à tous points... Il est extrêmement rapide : il ne fait jouer que les paquets nécessaires. ... Il est incroyablement simple
Ces phrases m'ont un peu surpris. Ton solveur fait peut être ~250 lignes, mais comme ça a déjà été remarqué plus haut, le problème de gestion des dépendances est NP-complet et ton solveur.. loin d'être "complet".
D'autre part, le solveur implémenté dans ZYpp est basé sur le solveur open-source MiniSAT (http://minisat.se/ ) qui fait dans les 600 lignes. Pas mal pour un solveur complet qui s'affranchit de l'exponentialité des solutions possible avec le nombre de paquets disponibles.
Enfin, tu sous entends que le solveur d'openSUSE nécessite de chargé la base de données en mémoire avant de pouvoir effectuer les calculs de dépendances et que ceci ralenti considérablement sa vitesse.
Ce n'est pas exactement vrai, puisque en pratique on voit que l'utilisation d'une BDD binaire (que tu sembles aussi utiliser) est foudroyant à l'exécution. Il ne faut que quelques millisecondes pour lire la base de données entière et ce n'est en tout cas pas un "bottleneck".
Using a data dictionary approach to store and retrieve package and dependency information. A new solv format was created, which stores a repository as a string dictionary, a relation dictionary and then all package dependencies. Reading and merging multiple solv repositories takes just some milliseconds.
Là où les choses peuvent être améliorées est la vitesse de création des équivalents binaires des méta-données des dépôts, par exemple, en les générant à la volée directement sur le serveur, et pas après téléchargement des md-data par le client.
A noter aussi que Apt, Yum et URPMI sont incomplets et utilisent plutôt des méthodes heuristiques. A ma connaissance, le seul PM non expérimental qui utilise un algo "avancé" de type SAT et est possiblement complet est Smart.
Sinon, j'aime bien tes journaux/concepts, y'a de bonne idées mais je pense qu'un peu plus de modestie serait un plus concernant ta crédibilité.
L'article de Daniel Burrows sur Apt est très instructif puisqu'il représente grosso modo ce que font la majorité des gestionnaires de paquets. L'article "EDOS" présente le problème vu sous un angle SAT.
C'est en tout cas mon cas. J'ai une mémoire plutôt "visuelle", et je suis relativement incapable de retenir une suite de nombre si il n'y a pas un lien logique entre eux.
Pour le code de ma carte bancaire, je connais le nombre de chiffres et quel chiffre sont utilisés. Je ne retiens pas l'ordre de ceux-ci, ni leur occurence. C'est le "chemin" que je tape sur le clavier numérique du bancomat qui me permet d'entrer le code correct.
Parce que là, tu va switcher ta carte pour la soirée, et juste plugger le casque sur ta carte met 3 secondes...
Concrètement, à quoi sert de switcher d'une carte son à une autre ?
La librairie de gestion de dépendance (sat-solver) est déjà portée, mais zypp en lui-même non, en partie parce que Fedora utilise RPM 4.7 et que openSUSE est toujours en cours de migration vers la version upstream.
Pas sûr que ce soit prêt avant la deadline prévue pour la prochaine suse, vu que le mainteneur est actuellement en vacances :]
Bah, l'essentiel de l'argumentation de Carmack est la taille du marché Linux, qui ne justifie pas un portage couteux. Après, la référence est juste est sans doute pour les libristes qui refusent de toucher de près ou de loin à des drivers proprio. Vu la tournure, m'est d'avis qu'il en connait un ou deux..
Pour le reste, idTech 4 devrait passer en GPL en 2010, y'aura déjà de quoi faire pour modder quelques jeux libres bien sympa :)
Le buisiness model derrière QuakeLive est la pub en ligne. Mais celui-ci s'est montré moins efficace que prévu, si bien que Carmak pense à ouvrir des serveurs privés payants (optionnels, donc).
la solution utilisée jusqu'ici par OpenSuSE pour éviter les [[guerres de religion]] Gnome/KDE était qu'il n'y avait PAS de choix par défaut.
Le problème est que cette "non-selection" ne résoud absoluement rien, alors qu'elle apporte une difficulté supplémentaire pour le newbie.
Les 2 bureaux étant mis au même niveau, alors que l'un est plus utilisé dans la communauté (les sondages annuels montrent un ration de 30/70 % en faveur de KDE). Aussi, des choix par défaut sont effectués à peu près partout, sauf à ce niveau (FireFox par défaut sous Gnome et KDE, ext3 vs reiuserfs, etc.). Cet "avantage" donné à Gnome résulte sur.. un désavantage à KDE, qui est ressenti comme un "citoyen de seconde zone" par certains.
[^] # Re: Pour blender
Posté par Spyhawk . En réponse au journal La souris pour Emacs. Évalué à 10.
[^] # Re: Aussi à propos de Ubuntu
Posté par Spyhawk . En réponse à la dépêche Vidéo : Mark Shuttleworth et Linux : Ergonomie et cadence. Évalué à 3.
Et c'est bien ce qu'il te reproche : Tu confonds le format de paquet deb et apt-get. Essai d'installer tes paquets avec dkpg, juste pour voir, tu vas voir ce qu'est "deb".
# Licence
Posté par Spyhawk . En réponse au journal Auxrames : Outil de gestion d'équipe. Évalué à 5.
[^] # Re: citation
Posté par Spyhawk . En réponse au journal La guerre des trolls aura bien lieu. Évalué à 5.
Stallman and the FSF, like his Cretaceous ancestors 65 million years ago, isn’t evolved enough to see that his reign is about to come to an end. The Open world needs interoperability, not shut itself off from other standards just because they originate from proprietary sources.
[^] # Re: Farce ?
Posté par Spyhawk . En réponse au journal pourquoi je quitte linux ubuntu. Évalué à 9.
/me --> []
[^] # Re: Bravo
Posté par Spyhawk . En réponse au journal Résolution des dépendances par système de branches. Évalué à 2.
[^] # Re: SAT, une artillerie lourde ?
Posté par Spyhawk . En réponse au journal Résolution des dépendances par système de branches. Évalué à 2.
Pour illustrer mon propos, j'ai mesuré les temps mis par apt et pacman pour installer vim sur le même ordinateur, apt prends environ 10s et pacman 2s, et je les trouve toujours trop lents.
~2.5s pour me calculer un dist-upgrade (sur un laptop vieux de 3 ans avec un DD 5400tpm), pas l'install d'un paquet unique.
[^] # Re: SAT, une artillerie lourde ?
Posté par Spyhawk . En réponse au journal Résolution des dépendances par système de branches. Évalué à 5.
En l'occurence, avec un solveur sat, le "bottleneck" n'est pas la résolution des dépendances ni la lecture des métadonnées mais le téléchargement et l'installation des paquets.
D'autre part, ces 2.0 - 2.5 secondes ne sont pas linéairement dédiées à la résolution :
zypper dup
Loading repository data... -> 1 sec
Reading installed packages... -> 1 sec
Computing distribution upgrade... -> 0.5 sec
Pour finir, je ne vois strictement pas l'intérêt de créer une solution pour un scénario viable dans 10 ou 20 ans alors que tu ne connais strictement rien aux conditions du futur environment (capacité de bande passante, performance disque dur et CPU, calcul quantique ?).
Quitte à créer un solution, autant qu'elle réponde à un besoin d'aujourd'hui, ou elle aura toute les chance d'être obsolète avant même d'être utile.
[^] # Re: SAT, une artillerie lourde ?
Posté par Spyhawk . En réponse au journal Résolution des dépendances par système de branches. Évalué à 5.
A te lire, j'ai vraiment l'impression qu'on parle de 2 choses totalement différentes et que tu n'a pas saisi comment le solver d'openSUSE fonctionne. Tu devrais aussi lire la doc de Daniel Burrows et celle du projet EDOS, ainsi que jeter un oeil au fonctionnement du SatSolver ZYpp en utilisation réelle.
Pour mémoire, voici le fonctionnement basic de ZYpp :
1/ teléchargement des métadonnées depuis les dépôts
2/ transformation des métadonnées en fichiers binaires .solv, qui contiennent les règles de dépendances de chacun des paquets
3/ calcul des dépendances
4/ application du résultat
L'étape 1/ est "bottleneck", elle ne dépend pas du solveur, mais du format des md-data et de la qualité de la connexion aux dépôts.
L'étape 2/ utilise une "dictionary approach" pour stocker les dépendances sous la forme d'un nombre 32bits unique, permettant une comparaison très rapide de 2 chaines de "charactères", principe de base du solveur SAT, un espace disque moindre, puisqu'un nombre est plus petit qu'une chaine de charactère (j'ai 4.7 Mo, 4.5 Mo, 3.6 Mo, 406 Ko pour les 4 plus gros dépôts activés qui représentent à eux seul un peu plus de 16'000 paquets, 1.4 Mo pour ma base RPM locale .solv, et mes 14 autres ne font que quelques Ko) et la representation mémoire ne prend pas plus de place sur un système 64bits où un pointer est 2x la taille d'un nombre 32bits (cf. doc SatSolver).
Un refresh forcé de ces fichiers me prends ~9 secondes, mais est surévalué puisque le dépôt principal, qui ne change jamais, est recré (5 sec est plus realiste pour une utilisation standard.. et encore).
L'étape 3/ me calcul les dépendances (par exemple un dist-upgrade me propose une solution en ~2.5 secondes), enfin l'étape 4/ valide les changements et télécharge les paquets proposés.
Au final, le calcul des dépendances est extrêmement rapide malgré le fait qu'un grand nombre de paquets sont pris en compte en mémoire (~2.5 secondes pour +16'000 paquets). J'ai l'impression que le problème que tu essaies de résoudre n'existe tout simplement pas avec un solver sat couplé avec une approche metadonnés-binaire telle qu'implémentée par ZYpp. De plus, la résolution est complète.
[^] # Re: SAT, une artillerie lourde ?
Posté par Spyhawk . En réponse au journal Résolution des dépendances par système de branches. Évalué à 2.
# SAT, une artillerie lourde ?
Posté par Spyhawk . En réponse au journal Résolution des dépendances par système de branches. Évalué à 7.
Il est complet à tous points... Il est extrêmement rapide : il ne fait jouer que les paquets nécessaires. ... Il est incroyablement simple
Ces phrases m'ont un peu surpris. Ton solveur fait peut être ~250 lignes, mais comme ça a déjà été remarqué plus haut, le problème de gestion des dépendances est NP-complet et ton solveur.. loin d'être "complet".
D'autre part, le solveur implémenté dans ZYpp est basé sur le solveur open-source MiniSAT (http://minisat.se/ ) qui fait dans les 600 lignes. Pas mal pour un solveur complet qui s'affranchit de l'exponentialité des solutions possible avec le nombre de paquets disponibles.
Enfin, tu sous entends que le solveur d'openSUSE nécessite de chargé la base de données en mémoire avant de pouvoir effectuer les calculs de dépendances et que ceci ralenti considérablement sa vitesse.
Ce n'est pas exactement vrai, puisque en pratique on voit que l'utilisation d'une BDD binaire (que tu sembles aussi utiliser) est foudroyant à l'exécution. Il ne faut que quelques millisecondes pour lire la base de données entière et ce n'est en tout cas pas un "bottleneck".
Using a data dictionary approach to store and retrieve package and dependency information. A new solv format was created, which stores a repository as a string dictionary, a relation dictionary and then all package dependencies. Reading and merging multiple solv repositories takes just some milliseconds.
Là où les choses peuvent être améliorées est la vitesse de création des équivalents binaires des méta-données des dépôts, par exemple, en les générant à la volée directement sur le serveur, et pas après téléchargement des md-data par le client.
A noter aussi que Apt, Yum et URPMI sont incomplets et utilisent plutôt des méthodes heuristiques. A ma connaissance, le seul PM non expérimental qui utilise un algo "avancé" de type SAT et est possiblement complet est Smart.
Sinon, j'aime bien tes journaux/concepts, y'a de bonne idées mais je pense qu'un peu plus de modestie serait un plus concernant ta crédibilité.
http://en.wikipedia.org/wiki/ZYpp
[^] # Re: Dépendances inverse
Posté par Spyhawk . En réponse au journal Résolution des dépendances par système de branches. Évalué à 3.
L'article de Daniel Burrows sur Apt est très instructif puisqu'il représente grosso modo ce que font la majorité des gestionnaires de paquets. L'article "EDOS" présente le problème vu sous un angle SAT.
[^] # Re: 1er commentaire sur +linux
Posté par Spyhawk . En réponse à la dépêche Nouvelle version 2.6.31 du noyau Linux. Évalué à 10.
[^] # Re: sauf que
Posté par Spyhawk . En réponse au journal Carte pour mot de passe. Évalué à 2.
Pour le code de ma carte bancaire, je connais le nombre de chiffres et quel chiffre sont utilisés. Je ne retiens pas l'ordre de ceux-ci, ni leur occurence. C'est le "chemin" que je tape sur le clavier numérique du bancomat qui me permet d'entrer le code correct.
[^] # Re: Phonon était pas prêt
Posté par Spyhawk . En réponse au journal Qt/Phonon bientôt mort et remplacé. Évalué à 3.
Parce que là, tu va switcher ta carte pour la soirée, et juste plugger le casque sur ta carte met 3 secondes...
Concrètement, à quoi sert de switcher d'une carte son à une autre ?
[^] # Re: Phonon était pas prêt
Posté par Spyhawk . En réponse au journal Qt/Phonon bientôt mort et remplacé. Évalué à 3.
[^] # Re: moinssage
Posté par Spyhawk . En réponse au journal Skype pour Linux 2.1 Béta vient de sortir. Évalué à 5.
Bienvenue sur LinuxFr ! :]
[^] # Re: Merci !
Posté par Spyhawk . En réponse au journal Yum vs Apt. Évalué à 2.
Pas sûr que ce soit prêt avant la deadline prévue pour la prochaine suse, vu que le mainteneur est actuellement en vacances :]
[^] # Re: hu ?
Posté par Spyhawk . En réponse au journal Le WPA en déroute(ur). Évalué à 10.
-->[¨]
[^] # Re: touours pareil....
Posté par Spyhawk . En réponse à la dépêche Mandriva Linux 2010.0 disponible en version Bêta. Évalué à 1.
[^] # Re: logique !
Posté par Spyhawk . En réponse au journal Le portage du moteur id Tech 5 (Rage et Doom 4) sous Linux est peu probable. Évalué à 10.
Pour le reste, idTech 4 devrait passer en GPL en 2010, y'aura déjà de quoi faire pour modder quelques jeux libres bien sympa :)
# Forums!
Posté par Spyhawk . En réponse au message Un script pour uploader des videos sur Youtube?. Évalué à 5.
[^] # Re: Un résumé
Posté par Spyhawk . En réponse au journal KDE par défaut sous OpenSUSE. Évalué à 2.
http://arstechnica.com/open-source/news/2009/08/opensuse-com(...)
[^] # Re: Buisness model
Posté par Spyhawk . En réponse à la dépêche Quake live enfin dispo sous GNU/Linux !. Évalué à 2.
Voir : http://nofrag.com/2009/aou/17/32131/
[^] # Re: Précisions
Posté par Spyhawk . En réponse au journal KDE par défaut sous OpenSUSE. Évalué à 5.
Le problème est que cette "non-selection" ne résoud absoluement rien, alors qu'elle apporte une difficulté supplémentaire pour le newbie.
Les 2 bureaux étant mis au même niveau, alors que l'un est plus utilisé dans la communauté (les sondages annuels montrent un ration de 30/70 % en faveur de KDE). Aussi, des choix par défaut sont effectués à peu près partout, sauf à ce niveau (FireFox par défaut sous Gnome et KDE, ext3 vs reiuserfs, etc.). Cet "avantage" donné à Gnome résulte sur.. un désavantage à KDE, qui est ressenti comme un "citoyen de seconde zone" par certains.