> Mais egalement, il télécharge plusieurs paquets en même temps
> contrairement à urpmi puis les isntalles lorsque tout les téléchargements
> sont erminés.Le temps d'upgrade est donc moins long.
Dans la mesure ou la plupart du temps, ce qui limite, c'est ton debit en download, c'est pas le fait d'avoir X download en même temps qui vont changer grand chose. Prendre un miroir plus rapide et plus proche est en général une solution plus acceptable que de bourriner le même serveur pour prendre 3 fois plus de bande passante que ce qu'il veut donner.
Ensuite, concernant l'installation et le download alterné, ça existe aussi sur urpmi et smart. C'est l'option --stepped pour smart, et ça évite de remplir le /var betement ( déja que smart garde les index décompressés sur le disque pour gagner du temps, si en plus, il remplit /var et fout en l'air le serveur ). Quand à urpmi, c'est l'option --split-length 0.
Enfin, j'aimerais bien avoir des chiffres, parce que aprés avoir mesuré le temps d'installation en cooker entre urpmi et smart d'une paire de paquets, fait 2 /3 fois de suite dans le désordre, j'ai vu que smart est souvent et systématiquement 1 à 5 secondes plus long, sur une 10 à 30 secondes d'installation. Et ceci même avec psyco et le cache qu'il utilise, alors que rien de spécial n'existe de ce coté au niveau de urpmi et perl.
1 à 5 secondes, c' est d'une part négligeable, mais surtout, ça me fait douter de l'idée que smart serait plus rapide que urpmi sur une même machine.
Et pourtant, smart aussi m'avais l'air plus rapide, mais les chiffres m'ont prouvés le contraire.
La rapidité, ça me semble surtout être, comme pour le boot d'xp, une question d'ui, ( et souvent d'auto suggestion, genre http://greenfly.org/mes.html(...) ).
# Euh, des chiffres, ça serait plus utile je croit...
Posté par Misc (site web personnel) . En réponse au journal smart. Évalué à 1.
> contrairement à urpmi puis les isntalles lorsque tout les téléchargements
> sont erminés.Le temps d'upgrade est donc moins long.
Dans la mesure ou la plupart du temps, ce qui limite, c'est ton debit en download, c'est pas le fait d'avoir X download en même temps qui vont changer grand chose. Prendre un miroir plus rapide et plus proche est en général une solution plus acceptable que de bourriner le même serveur pour prendre 3 fois plus de bande passante que ce qu'il veut donner.
Ensuite, concernant l'installation et le download alterné, ça existe aussi sur urpmi et smart. C'est l'option --stepped pour smart, et ça évite de remplir le /var betement ( déja que smart garde les index décompressés sur le disque pour gagner du temps, si en plus, il remplit /var et fout en l'air le serveur ). Quand à urpmi, c'est l'option --split-length 0.
Enfin, j'aimerais bien avoir des chiffres, parce que aprés avoir mesuré le temps d'installation en cooker entre urpmi et smart d'une paire de paquets, fait 2 /3 fois de suite dans le désordre, j'ai vu que smart est souvent et systématiquement 1 à 5 secondes plus long, sur une 10 à 30 secondes d'installation. Et ceci même avec psyco et le cache qu'il utilise, alors que rien de spécial n'existe de ce coté au niveau de urpmi et perl.
1 à 5 secondes, c' est d'une part négligeable, mais surtout, ça me fait douter de l'idée que smart serait plus rapide que urpmi sur une même machine.
Et pourtant, smart aussi m'avais l'air plus rapide, mais les chiffres m'ont prouvés le contraire.
La rapidité, ça me semble surtout être, comme pour le boot d'xp, une question d'ui, ( et souvent d'auto suggestion, genre http://greenfly.org/mes.html(...) ).