> D'ailleurs, je voudrais bien savoir si l'Aurox en question est aussi lente que la redhat 9.
Sachant que c'est la même chose, on peut affirmer que oui.
Il y a un petit problème avec le paramétrage par défaut de la vm. Bizarrement alors que redhat est assez pointu dans ce domaine il ont mis du temps pour le trouver. En effet, ça existe depuis la rh 8.0.
Voir à la fin :
--------------------------------------------------------
As a test I did:
/sbin/sysctl -w vm.bdflush="30 500 0 0 2560 15360 60 20 0"
[chrismcc@kanga chrismcc]$ uname -a ; cat /proc/sys/vm/bdflush
Linux kanga 2.4.20-18.7smp #1 SMP Thu May 29 07:49:23 EDT 2003 i686 unknown
30 500 0 0 2560 15360 60 20 0
And... tada, all was well again
--------------------------------------------------------
Tu peux ajouter cette ligne dans /etc/sysctl.conf pour que ce soit pris en charge au boot.
vm.bdflush="30 500 0 0 2560 15360 60 20 0"
Ça résoud un problème de performance dans certain cas (utilisation rsync, copy volumineuse, lecture d'un dvd,...). Mais ça va changer grand chose en utilisation desktop.
> redhat inclus la nouvelle librairie de threads soit disant en O(1)
C'est pour les serveurs qui crées plein de thread. En bureautique ça n'apporte rien. Le gros avantage de ntpl, c'est la comformité posix et une meilleur gestion des tâches, car a chaque thread correspond une entrée noyau.
> 2/ redhat fournis les binaires en i686
C'est compatibilité i386 et optimisé i686. De plus le "full" i686 c'est pour kernel, glibc, openssl et mod_ssl. Les tests montrent qu'il n'y a pas beaucoup de gain énorme si tout est compilé en "full" i686 (2 ou 3 %).
> Et ma debian (compilée tjs et encore en i386) tourne plus vite, est plus reactive
Si c'est pour les applis gnome 2.2, c'est ""normal"" s'il n'y a plus rien de gnome en cache.
Exemple :
$ strace gnome-alsamixer 2>&1 | grep ^open | wc
253
$
Quand je dis ""normal"", je veux dire que c'est lié à gnome et non à redhat.
Regarde si ta debian est aussi rapide avec gnome 2.2.
[^] # Re: Aurox Linux = redhat en mieux?
Posté par ptit_tux . En réponse à la dépêche Une "Red Hat Like" sur 6 CDs en kiosque : Aurox Linux. Évalué à 1.
Sachant que c'est la même chose, on peut affirmer que oui.
Il y a un petit problème avec le paramétrage par défaut de la vm. Bizarrement alors que redhat est assez pointu dans ce domaine il ont mis du temps pour le trouver. En effet, ça existe depuis la rh 8.0.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=89226(...)
Voir à la fin :
--------------------------------------------------------
As a test I did:
/sbin/sysctl -w vm.bdflush="30 500 0 0 2560 15360 60 20 0"
[chrismcc@kanga chrismcc]$ uname -a ; cat /proc/sys/vm/bdflush
Linux kanga 2.4.20-18.7smp #1 SMP Thu May 29 07:49:23 EDT 2003 i686 unknown
30 500 0 0 2560 15360 60 20 0
And... tada, all was well again
--------------------------------------------------------
Tu peux ajouter cette ligne dans /etc/sysctl.conf pour que ce soit pris en charge au boot.
vm.bdflush="30 500 0 0 2560 15360 60 20 0"
Ça résoud un problème de performance dans certain cas (utilisation rsync, copy volumineuse, lecture d'un dvd,...). Mais ça va changer grand chose en utilisation desktop.
> redhat inclus la nouvelle librairie de threads soit disant en O(1)
C'est pour les serveurs qui crées plein de thread. En bureautique ça n'apporte rien. Le gros avantage de ntpl, c'est la comformité posix et une meilleur gestion des tâches, car a chaque thread correspond une entrée noyau.
> 2/ redhat fournis les binaires en i686
C'est compatibilité i386 et optimisé i686. De plus le "full" i686 c'est pour kernel, glibc, openssl et mod_ssl. Les tests montrent qu'il n'y a pas beaucoup de gain énorme si tout est compilé en "full" i686 (2 ou 3 %).
> Et ma debian (compilée tjs et encore en i386) tourne plus vite, est plus reactive
Si c'est pour les applis gnome 2.2, c'est ""normal"" s'il n'y a plus rien de gnome en cache.
Exemple :
$ strace gnome-alsamixer 2>&1 | grep ^open | wc
253
$
Quand je dis ""normal"", je veux dire que c'est lié à gnome et non à redhat.
Regarde si ta debian est aussi rapide avec gnome 2.2.