> J'ai pris près d'une semaine entière pour coder le système de gestion des dépendances, donc il doit être correct
Juste parce que je pense que c'est des choses comme ça qui font que les gens n'ont pas forcément confiance / ne croient pas en ton projet :
C'est pas parce que tu as mis une semaine entière que c'est bien.
Tu peux très bien faire de la merde toute ta vie, comme bien concevoir / coder en général, le temps n'a que peu d'influence et dépend aussi (beaucoup) de l'expérience acquise.
Je pense par exemple que tu minimise _beaucoup_ le problème de résolution de dépendance, qui est au contraire au coeur d'un gestionnaire de paquet
Par exemple, si tu lis http://fr.opensuse.org/Libzypp/Gestion_des_paquets il y a le passage suivant :
En mai 2007, à l'occasion de la "29th International Conference on Software Engineering" ont été publiés les résultats du solveur expérimental OPIUM ("OPtimal Package Install/Uninstall Manager"), une première implémentation dans un système linux d'un solveur SAT (Boolean satisfiability problem). Ce nouvel outil est destiné à combler les déficiences, parfois inacceptables, des solveurs de dépendances traditionnels tels que Apt[1]. Le solveur SAT, issu de la théorie de la complexité[2], travaille fondamentalement différemment de ceux-ci (voir [3] pour le fonctionnement de l'algorithme d'Apt et Aptitude). Alors qu'ils doivent gérer un compromis entre la rapidité de la résolution du problème de dépendances et la qualité de cette même solution, le solveur SAT est complet : il ne trouve pas une solution possible, mais il trouve la meilleure solution possible dans un temps très raisonnable.
Cependant, cette implémentation pour gérer un système Linux n'est pas optimisée : bien qu'il soit beaucoup plus fiable qu'Apt, OPIUM est aussi plus lent, puisque ses concepteurs se sont concentrés avant tout sur la démonstration de la qualité des solutions de l'algorithme. Prenant parti de la Hackweek de Novell en juin 2007 (semaine d'"Innovation libre" pour les employés), des résultats du solveur OPIUM ainsi que des outils serveurs debcheck/rpmcheck[4], Michael Schröder, employé à Nürnberg, démontra la faisabilité de l'implémentation d'un tel solveur dans libzypp, bien meilleur que celui alors implémenté dans libzypp. Les autres membres de l'équipe ZYpp se sont alors occupés à stabiliser et optimiser ZYpp v3 pour la sortie de la 10.3, avant de travailler sur ce nouveau solveur.
(l'emphase est de moi)
Voici les notes correspondantes :
# [1] C. Tukker, D. Shuffelton, R. Jhala, S. Lerner, OPIUM: OPtimal Package Install/Uninstall Manager, 29th International Conference on Software Engineering (ICSE'07), 2007 : http://www.cs.ucsd.edu/~lerner/papers/opium.pdf
# [2] http://en.wikipedia.org/wiki/Computational_complexity_theory
# [3] D. Burrows, Modelling and Resolving Software Dependencies, June 2005 : http://people.debian.org/~dburrows/model.pdf
# [4] F. Mancinelli, J. Boender, R. di Cosmo, J. Vouillon, Managing the Complexity of Large Free and Open Source Package-Based Software Distributions, 21st IEEE International Conference on Automated Software Engineering (ASE'06), 2006
La manière dont tu réponds montre justement que tu n'as pas ce qu'il faut pour résoudre correctement les dépendances, dans un temps correct (installer, faire des tests sur 2 - ha non, 1 - paquet ne prouve strictement rien est est vraiment un cas particulier hyper simple)
[^] # Re: dépendance
Posté par CrEv (site web personnel) . En réponse au journal Aider au développement d'un nouveau gestionnaire de paquets. Évalué à 4.
Juste parce que je pense que c'est des choses comme ça qui font que les gens n'ont pas forcément confiance / ne croient pas en ton projet :
C'est pas parce que tu as mis une semaine entière que c'est bien.
Tu peux très bien faire de la merde toute ta vie, comme bien concevoir / coder en général, le temps n'a que peu d'influence et dépend aussi (beaucoup) de l'expérience acquise.
Je pense par exemple que tu minimise _beaucoup_ le problème de résolution de dépendance, qui est au contraire au coeur d'un gestionnaire de paquet
Par exemple, si tu lis http://fr.opensuse.org/Libzypp/Gestion_des_paquets il y a le passage suivant :
En mai 2007, à l'occasion de la "29th International Conference on Software Engineering" ont été publiés les résultats du solveur expérimental OPIUM ("OPtimal Package Install/Uninstall Manager"), une première implémentation dans un système linux d'un solveur SAT (Boolean satisfiability problem). Ce nouvel outil est destiné à combler les déficiences, parfois inacceptables, des solveurs de dépendances traditionnels tels que Apt[1]. Le solveur SAT, issu de la théorie de la complexité[2], travaille fondamentalement différemment de ceux-ci (voir [3] pour le fonctionnement de l'algorithme d'Apt et Aptitude). Alors qu'ils doivent gérer un compromis entre la rapidité de la résolution du problème de dépendances et la qualité de cette même solution, le solveur SAT est complet : il ne trouve pas une solution possible, mais il trouve la meilleure solution possible dans un temps très raisonnable.
Cependant, cette implémentation pour gérer un système Linux n'est pas optimisée : bien qu'il soit beaucoup plus fiable qu'Apt, OPIUM est aussi plus lent, puisque ses concepteurs se sont concentrés avant tout sur la démonstration de la qualité des solutions de l'algorithme. Prenant parti de la Hackweek de Novell en juin 2007 (semaine d'"Innovation libre" pour les employés), des résultats du solveur OPIUM ainsi que des outils serveurs debcheck/rpmcheck[4], Michael Schröder, employé à Nürnberg, démontra la faisabilité de l'implémentation d'un tel solveur dans libzypp, bien meilleur que celui alors implémenté dans libzypp. Les autres membres de l'équipe ZYpp se sont alors occupés à stabiliser et optimiser ZYpp v3 pour la sortie de la 10.3, avant de travailler sur ce nouveau solveur.
(l'emphase est de moi)
Voici les notes correspondantes :
# [1] C. Tukker, D. Shuffelton, R. Jhala, S. Lerner, OPIUM: OPtimal Package Install/Uninstall Manager, 29th International Conference on Software Engineering (ICSE'07), 2007 : http://www.cs.ucsd.edu/~lerner/papers/opium.pdf
# [2] http://en.wikipedia.org/wiki/Computational_complexity_theory
# [3] D. Burrows, Modelling and Resolving Software Dependencies, June 2005 : http://people.debian.org/~dburrows/model.pdf
# [4] F. Mancinelli, J. Boender, R. di Cosmo, J. Vouillon, Managing the Complexity of Large Free and Open Source Package-Based Software Distributions, 21st IEEE International Conference on Automated Software Engineering (ASE'06), 2006
La manière dont tu réponds montre justement que tu n'as pas ce qu'il faut pour résoudre correctement les dépendances, dans un temps correct (installer, faire des tests sur 2 - ha non, 1 - paquet ne prouve strictement rien est est vraiment un cas particulier hyper simple)