Bonjour,
je souhaite installer une distrib linux sur mon pc (amd64) cependant,
j'hesites toujours entre plusieurs distrib...
je veux faire bien sur des choses standart, mater films, musique etc...
et aussi du developpement, et du bricolage un peu. Alors si vos
experiences pouvaient m'etre utilse :p
j'hésite entre :
*aurox (testé vite fait,pas mal d'outils de dev, mais gestions des
paquets :s)
*kubuntu (pas testé)
*suse (j'avais testé la 8.2 et pas mal aimé, je sais pas ce que vaut la 10)
sinon debian? :s
Merci de votre attention et de vos réponses.
++
Ps: je suis qu'en Wifi
(damned, http://www.giromini.org/usenet-fr/repondre.html est down ?)
Bonne journée a tous!
A toi aussi !
cmoa
Fabien LE LEZ wrote in message :
Y a-t-il un réel intérêt à passer en 64 bits (au lieu de 32) quand on n'a pas plus de 4 Go de RAM ?
Oui. Au choix, on peut citer la possibilité de lire plus facilement des fichiers de plus de quelques Go, ou la vitesse de certaines opérations cryptographiques. Le genre de choses dont un utilisateur moyen n'a que faire.
Pour un débutant je pense qu'il vaut mieux commencer avec une version 32bits. Déjà que certains baissent les bras dès le premier problème de driver, alors se lancer dans des installations en chroot et autre joyeuseté pour gagner 3% de perfs dans quelques applications...
Fabien LE LEZ wrote in message
<ao24925e1q254ibv0nctfo5bgrgbbbr7m2@4ax.com>:
Y a-t-il un réel intérêt à passer en 64 bits (au lieu de 32) quand on
n'a pas plus de 4 Go de RAM ?
Oui. Au choix, on peut citer la possibilité de lire plus facilement des
fichiers de plus de quelques Go, ou la vitesse de certaines opérations
cryptographiques.
Le genre de choses dont un utilisateur moyen n'a que faire.
Pour un débutant je pense qu'il vaut mieux commencer avec une version
32bits.
Déjà que certains baissent les bras dès le premier problème de driver,
alors se lancer dans des installations en chroot et autre joyeuseté pour
gagner 3% de perfs dans quelques applications...
Y a-t-il un réel intérêt à passer en 64 bits (au lieu de 32) quand on n'a pas plus de 4 Go de RAM ?
Oui. Au choix, on peut citer la possibilité de lire plus facilement des fichiers de plus de quelques Go, ou la vitesse de certaines opérations cryptographiques. Le genre de choses dont un utilisateur moyen n'a que faire.
Pour un débutant je pense qu'il vaut mieux commencer avec une version 32bits. Déjà que certains baissent les bras dès le premier problème de driver, alors se lancer dans des installations en chroot et autre joyeuseté pour gagner 3% de perfs dans quelques applications...
Nicolas George
cmoa wrote in message <e6u8jb$jh6$:
Le genre de choses dont un utilisateur moyen n'a que faire.
L'utilisateur moyen, il ne devrait même pas se demander si sa machine est 32 ou 64 bits. Il prend le moins cher qui répond à ses besoins et c'est tout.
gagner 3% de perfs dans quelques applications...
Pour ta gouverne, ce que j'évoquais, c'est plutôt un _rapport_ de 3 à 10 que 3 à 10%.
cmoa wrote in message <e6u8jb$jh6$1@nntp.aioe.org>:
Le genre de choses dont un utilisateur moyen n'a que faire.
L'utilisateur moyen, il ne devrait même pas se demander si sa machine est 32
ou 64 bits. Il prend le moins cher qui répond à ses besoins et c'est tout.
gagner 3% de perfs dans quelques applications...
Pour ta gouverne, ce que j'évoquais, c'est plutôt un _rapport_ de 3 à 10 que
3 à 10%.
Le genre de choses dont un utilisateur moyen n'a que faire.
L'utilisateur moyen, il ne devrait même pas se demander si sa machine est 32 ou 64 bits. Il prend le moins cher qui répond à ses besoins et c'est tout.
gagner 3% de perfs dans quelques applications...
Pour ta gouverne, ce que j'évoquais, c'est plutôt un _rapport_ de 3 à 10 que 3 à 10%.
Fabien LE LEZ
On Fri, 16 Jun 2006 12:51:10 +0000 (UTC), Nicolas George <nicolas$:
L'utilisateur moyen, il ne devrait même pas se demander si sa machine est 32 ou 64 bits. Il prend le moins cher qui répond à ses besoins et c'est tout.
Un PC typique aujourd'hui n'est ni 32 bits, ni 64 bits. Il sait gérer les deux modes.
Pour ta gouverne, ce que j'évoquais, c'est plutôt un _rapport_ de 3 à 10
Si les processus en question ont une occupation CPU importante, alors effectivement ça vaut le coup.
S'il s'agit d'optimiser un processus qui occupe 1 seconde de temps processeur par jour, ben... bof.
L'optimisation en matière de machines, c'est comme l'optimisation en programmation : on utilise la méthode la plus simple possible, et si, à l'usage, on s'aperçoit que c'est trop lent, on cherche les goulots d'étranglement et on les optimise.
On Fri, 16 Jun 2006 12:51:10 +0000 (UTC), Nicolas George
<nicolas$george@salle-s.org>:
L'utilisateur moyen, il ne devrait même pas se demander si sa machine est 32
ou 64 bits. Il prend le moins cher qui répond à ses besoins et c'est tout.
Un PC typique aujourd'hui n'est ni 32 bits, ni 64 bits. Il sait gérer
les deux modes.
Pour ta gouverne, ce que j'évoquais, c'est plutôt un _rapport_ de 3 à 10
Si les processus en question ont une occupation CPU importante, alors
effectivement ça vaut le coup.
S'il s'agit d'optimiser un processus qui occupe 1 seconde de temps
processeur par jour, ben... bof.
L'optimisation en matière de machines, c'est comme l'optimisation en
programmation : on utilise la méthode la plus simple possible, et si,
à l'usage, on s'aperçoit que c'est trop lent, on cherche les goulots
d'étranglement et on les optimise.
On Fri, 16 Jun 2006 12:51:10 +0000 (UTC), Nicolas George <nicolas$:
L'utilisateur moyen, il ne devrait même pas se demander si sa machine est 32 ou 64 bits. Il prend le moins cher qui répond à ses besoins et c'est tout.
Un PC typique aujourd'hui n'est ni 32 bits, ni 64 bits. Il sait gérer les deux modes.
Pour ta gouverne, ce que j'évoquais, c'est plutôt un _rapport_ de 3 à 10
Si les processus en question ont une occupation CPU importante, alors effectivement ça vaut le coup.
S'il s'agit d'optimiser un processus qui occupe 1 seconde de temps processeur par jour, ben... bof.
L'optimisation en matière de machines, c'est comme l'optimisation en programmation : on utilise la méthode la plus simple possible, et si, à l'usage, on s'aperçoit que c'est trop lent, on cherche les goulots d'étranglement et on les optimise.
Nicolas George
Fabien LE LEZ wrote in message :
Si les processus en question ont une occupation CPU importante, alors effectivement ça vaut le coup.
S'il s'agit d'optimiser un processus qui occupe 1 seconde de temps processeur par jour, ben... bof.
Ça dépend évidemment de l'utilisation, mais avec l'augmentation des débits réseau et disque, la vitesse de la crypto devient de plus en plus critique. Une machine actuelle peut traiter environ 50-100 Mo par seconde de données chiffrées sur des algorithmes solides. C'est proche des débits de disques, surtout si on a du RAID, et pas si loin des débits réseau les plus rapides.
Fabien LE LEZ wrote in message
<1fc592ht1ro79nahin87rr3mrm11m94q4j@4ax.com>:
Si les processus en question ont une occupation CPU importante, alors
effectivement ça vaut le coup.
S'il s'agit d'optimiser un processus qui occupe 1 seconde de temps
processeur par jour, ben... bof.
Ça dépend évidemment de l'utilisation, mais avec l'augmentation des débits
réseau et disque, la vitesse de la crypto devient de plus en plus critique.
Une machine actuelle peut traiter environ 50-100 Mo par seconde de données
chiffrées sur des algorithmes solides. C'est proche des débits de disques,
surtout si on a du RAID, et pas si loin des débits réseau les plus rapides.
Si les processus en question ont une occupation CPU importante, alors effectivement ça vaut le coup.
S'il s'agit d'optimiser un processus qui occupe 1 seconde de temps processeur par jour, ben... bof.
Ça dépend évidemment de l'utilisation, mais avec l'augmentation des débits réseau et disque, la vitesse de la crypto devient de plus en plus critique. Une machine actuelle peut traiter environ 50-100 Mo par seconde de données chiffrées sur des algorithmes solides. C'est proche des débits de disques, surtout si on a du RAID, et pas si loin des débits réseau les plus rapides.
Mihamina Rakotomandimby
On Fri, 16 Jun 2006 11:17:47 +0200, Matthieu Moy wrote:
(damned, http://www.giromini.org/usenet-fr/repondre.html est down ?)
Oui, ce fut un sujet de discussion sur un groupe, le domaine n'a pas été renouvellé.
On Fri, 16 Jun 2006 11:17:47 +0200, Matthieu Moy wrote:
(damned, http://www.giromini.org/usenet-fr/repondre.html est down ?)
Oui, ce fut un sujet de discussion sur un groupe, le domaine n'a pas été
renouvellé.
On Fri, 16 Jun 2006 11:17:47 +0200, Matthieu Moy wrote:
(damned, http://www.giromini.org/usenet-fr/repondre.html est down ?)
Oui, ce fut un sujet de discussion sur un groupe, le domaine n'a pas été renouvellé.
Arol
"Fabien LE LEZ" a écrit dans le message de news:
L'optimisation en matière de machines, c'est comme l'optimisation en programmation : on utilise la méthode la plus simple possible, et si, à l'usage, on s'aperçoit que c'est trop lent, on cherche les goulots d'étranglement et on les optimise.
Tout à fait, ça s'appelle "profiler" le code. Avec la dernière version de visual studio de microsoft, il y a un outil qui analyse le comportement du code lors d'un usage normal du programme. Ce profiler sort les portions de code les plus gourmands en cpu/ram etc... On peut ainsi optimiser "à la main" ces portions de code pour améliorer les performances.
Existe-t-il un outil équivalent sous linux pour du c/c++ ?
"Fabien LE LEZ" a écrit dans le message de news:
L'optimisation en matière de machines, c'est comme l'optimisation en
programmation : on utilise la méthode la plus simple possible, et si,
à l'usage, on s'aperçoit que c'est trop lent, on cherche les goulots
d'étranglement et on les optimise.
Tout à fait, ça s'appelle "profiler" le code.
Avec la dernière version de visual studio de microsoft, il y a un outil qui
analyse le comportement du code lors d'un usage normal du programme.
Ce profiler sort les portions de code les plus gourmands en cpu/ram etc...
On peut ainsi optimiser "à la main" ces portions de code pour améliorer les
performances.
Existe-t-il un outil équivalent sous linux pour du c/c++ ?
L'optimisation en matière de machines, c'est comme l'optimisation en programmation : on utilise la méthode la plus simple possible, et si, à l'usage, on s'aperçoit que c'est trop lent, on cherche les goulots d'étranglement et on les optimise.
Tout à fait, ça s'appelle "profiler" le code. Avec la dernière version de visual studio de microsoft, il y a un outil qui analyse le comportement du code lors d'un usage normal du programme. Ce profiler sort les portions de code les plus gourmands en cpu/ram etc... On peut ainsi optimiser "à la main" ces portions de code pour améliorer les performances.
Existe-t-il un outil équivalent sous linux pour du c/c++ ?
Nicolas George
"Arol" wrote in message <4492b80a$0$5712$:
Avec la dernière version de visual studio de microsoft, il y a un outil qui analyse le comportement du code lors d'un usage normal du programme. Ce profiler sort les portions de code les plus gourmands en cpu/ram etc... On peut ainsi optimiser "à la main" ces portions de code pour améliorer les performances.
Existe-t-il un outil équivalent sous linux pour du c/c++ ?
Oui, évidemment. Le plus commun s'appelle gprof, et existe depuis des années.
"Arol" wrote in message <4492b80a$0$5712$626a54ce@news.free.fr>:
Avec la dernière version de visual studio de microsoft, il y a un outil qui
analyse le comportement du code lors d'un usage normal du programme.
Ce profiler sort les portions de code les plus gourmands en cpu/ram etc...
On peut ainsi optimiser "à la main" ces portions de code pour améliorer les
performances.
Existe-t-il un outil équivalent sous linux pour du c/c++ ?
Oui, évidemment. Le plus commun s'appelle gprof, et existe depuis des
années.
Avec la dernière version de visual studio de microsoft, il y a un outil qui analyse le comportement du code lors d'un usage normal du programme. Ce profiler sort les portions de code les plus gourmands en cpu/ram etc... On peut ainsi optimiser "à la main" ces portions de code pour améliorer les performances.
Existe-t-il un outil équivalent sous linux pour du c/c++ ?
Oui, évidemment. Le plus commun s'appelle gprof, et existe depuis des années.
Arol
"Nicolas George" a écrit dans le message de news:
Existe-t-il un outil équivalent sous linux pour du c/c++ ?
Oui, évidemment. Le plus commun s'appelle gprof, et existe depuis des années.
Merci pour l'info. En général pour ce genre d'outils, certains promettent monts et merveilles pour un résultat plutôt médiocre. Les tester tous pour dénicher les meilleurs et moins pratique que demander aux utilisateurs.
"Nicolas George" a écrit dans le message de news:
Existe-t-il un outil équivalent sous linux pour du c/c++ ?
Oui, évidemment. Le plus commun s'appelle gprof, et existe depuis des
années.
Merci pour l'info.
En général pour ce genre d'outils, certains promettent monts et merveilles
pour un résultat plutôt médiocre.
Les tester tous pour dénicher les meilleurs et moins pratique que demander
aux utilisateurs.
Existe-t-il un outil équivalent sous linux pour du c/c++ ?
Oui, évidemment. Le plus commun s'appelle gprof, et existe depuis des années.
Merci pour l'info. En général pour ce genre d'outils, certains promettent monts et merveilles pour un résultat plutôt médiocre. Les tester tous pour dénicher les meilleurs et moins pratique que demander aux utilisateurs.
Jolitorax
Fabien LE LEZ nous narrait:
Y a-t-il un réel intérêt à passer en 64 bits (au lieu de 32) quand on n'a pas plus de 4 Go de RAM ?
Non, enfin pas à mon niveau. Ce qui ne m'empêche pas d'être en 64 bits pour voir comment ça tourne et comment ça évolue.
C'est juste que ça m'intéresse un peu
-- Jean Louis Mas
Fabien LE LEZ nous narrait:
Y a-t-il un réel intérêt à passer en 64 bits (au lieu de 32) quand on
n'a pas plus de 4 Go de RAM ?
Non, enfin pas à mon niveau. Ce qui ne m'empêche pas d'être en 64 bits
pour voir comment ça tourne et comment ça évolue.
