Reprise du message précédent :
Tes problemes peuvent etre dus a un CPU qui aurait mal vieilli (RARE!). Il existe des logiciels pour tester cela  (souvent utilises pour verifier la stabilite d'un overclock) : regarde cpuburn et les topics sur l'overclocking, ca pourrait donner des résultats.

Il existe un outil sous Linux équivalent ? Je n'ai pas de Windows installé sur mon poste, donc pour CPU Burn (que je connais), dur dur.

CPUBurn existe sous linux !
http://linux.softpedia.com/get/Sys [...] 1407.shtml

http://users.bigpond.net.au/CPUburn/

Sinon CPUStressMT existe sous Linux et est très bien pour stresser de l'Intel  

Merci à vous deux Je regarde ça dès ce soir.
 
Sinon, pour ceux qui se poseraient la question de l'intérêt d'un SSD : avant, quand je lançais un transfert de mon disque dur externe USB sur mon disque interne (ou l'inverse), je ne pouvais presque plus rien lancer tellement le disque était occupé. Là je suis en train de rapatrier ma discothèque de mon externe vers l'interne. Le transfert est bridé par l'externe, 40 Mo/s. Mon système continue à être complètement réactif, à froid, FireFox ,'a mis que 2 secondes pour s'ouvrir, sans que le transfert flanche. Je crois que c'est là que je me suis rendu compte de la puissance du SSD (ça et tout le reste bien sur ).
 
Sinon, depuis que j'ai supprimé mon profil, tout se passe bien. Je dirais même, tout se passe nickel. En fait, je suis en train de me poser des question sur l'assistant de crétaion de user de Arch... Voila ce qu'il s'est passé, et les résultats au fur et à mesure. J'ai installé ma distrib, puis j'ai fait un adduser (et non pas un useradd). Mon profil a donc été initialisé par l'assistant propre à Arch. Au milieu de l'aprem, j'avais mon problème avec les applications GTK et tout ça. J'ai créé un user depuis KUser : aucun problème connecté sous cet utilisateur test. J'ai donc consenti, non sans peine, à crasher mon profil. Pour cela, j'ai renommé mon dossier profil, puis j'ai recréé un dossier vierge, dans lequel j'ai juste placé les répertoire .mozilla et .mozilla_ref pour l'histoire de FireFox en RAM. Le reste s'est reconstitué en automatique au boot suivant, puis j'ai complètement reconfiguré mon environnement. Et depuis, je touche du bois, mais plus de problème du tout. Aussi surprenant que cela puisse paraitre.
 
Je vais quand même me pencher sur les outils de stress pour m'assurer que mo, matériel se porte bien, mais je commence de plus en plus à me demander si le fautif n'est pas tout simplement l'assistant de création de user d'Arch. Vous trouvez ça cohérent ou complètement loufoque ?

AMHA adduser se contente d'appeler useradd, c'est juste un front-end.

Justement, c'est là que mon raisonnement m'a mené : je pense que adduser initialise des fichiers dans le profil de l'utilisateur, et que ça peut foutre la merde dans certains cas. Je n'ai pas de certitude bien sur, mais voila, cela ne me semble pas idiot même si peu probable ça mérite vérification, d'autant plus que je n'ai pas supprimé mon user, j'ai juste "effacé" le contenu de son home.
 
Je vais faire un test avec plusieurs utilisateur pour en avoir le coeur net.

Regarde plutôt le code pour en avoir le cœur net, c'est un simple script bash.

Résultat des tests :
- useradd créé l'utilisateur et son groupe privé correspondant, l'y inscrit, ne l'inscrit à rien d'autre, mais ne créé pas le répertoire correspondant n'apparait pas dans /home
- adduser créé l'utilisateur, l'inscrit à des groupes en fonction de ce que l'on a renseigné, créé son dossier dans /home et y place les fichier .bash_profile, .bashrc, .xinitrc et .xsession
 
Donc même si adduser se sert de useradd, il va plus loin. J'ai regardé dans chacun des fichiers créés, il n'y a pas grand chose, mais ce n'est pas vide non plus. De ce que j'ai vu, je reconnais que je ne vois pas trop ce qui pourrait faire couiller un environnement complet comme dans mon cas cet après-midi, mais je ne suis pas expert, et pour le moment, les choses semblent rester stables.

Concernat les outils de stress, il y a... stress Dispo dans community. Le seul truc qui m'embête, c'est qu'il semble aussi stresser le HD, et dans le cas de mon SSD, j'aimerais bien ne pas le pourrir, surtout avec des I/O en rafale, des écritures dans tous les sens et tout ça, surtout tant que je n'ai pas la certitude que le TRIM est focntionnel sous le noyau de Arch, histoire de conserver des perfs qui roxent le plus longtemps possible. Je vais voir si il y a moyen de mettre de côté le stress HD avec cet outil, mais dans le mêle temps, j'ai peur que ça biaise les résultats, genre si c'est mon chipset qui est à la ramasse et qui déonne parfois, j'aimerais le mettre également en évidence. Je me renseigne là dessus.

Putain mais les segfault sous FireFox, ça va finir par me faire complètement péter les plombs... Pourtant, comparé à hier où tout mon environnement partait en couille, là tout fonctionne bien si on exclu FireFox. Et Flash est même pas installé, je préfère pas imaginer avec...

comprend pas y roule au poil mon firefox, c est mon emesene qui déconne un peu par contre

 
Tu as tenté avec la beta de firefox 3.5?

Et tu as fait ton cpuburn ? Parce que j'ai jamais de soucis, ni rencontre quelqu'un ayant autant de segfault avec firefox. Moi il segfault jamais.
 
Quelles extensions ? Il chauffe pas ton CPU ? Ta carte mere ? Je commence a poser des questions ailleurs, c'est peu probable je sais mais c'est tellement etrange !

j'ai une question con: comment on lance ssh?
 
je l'ai installé mais je trouve pas comment le lancer xD
 
edit: j'ai trouvé: /etc/rc.d/sshd start

Bon, CpuBurn tourne depuis 2 heures, mon processeur plafonne à 72°, l'ordi est stable à crever. Je vais plutôt me tourner du côté des outils de stress globaux plutôt que uniquement CPU. J'ai vu que CpuBurn pouvait générer des I/O par exemple pour le MMX ou ces choses là, je vais voir.

Toujours à la recherche de ce qui peut faire merder ma machine, et surtout pour essayer de mettre en évidence un problème hard que je pourrais faire passer sous garantie, voici ce qu'il s'est passé ce matin, à l'instant.
 
Je lance Konqueror pour venir butiner sur HFR, j'ai un MP, je souhaite y répondre. Donc je clique Répondre, puis lorsque je clique dans le textarea, Konqueror se ferme. Pas inquiété plus que ça, je relance Konqueror, refait la même opération, même résultat. Du coup je relance Konqueror, mais depuis une console cette fois. Là encore, lorsque je clique dans le textarea, Konqueror se viande, avec un message relatif à aspell  :

Du coup, j'ai réinstallé aspell et aspell-fr, relancé Konqueror : plus aucun problème, la preuve je vous répond. J'ai donc l'impression que parfois, j'ai des fichiers qui se corrompent. Pas très encourageant... Mais comment mettre la chose en évidence et isoler la pièce qui pose problème pour réclamer l'application de la garantie ? Mon SSD ne semble pas en cause car j'avais déjà des problèmes identiques avant d'avoir le SSD. Je penche plus pour une merde avec le contrôleur sur la CM ou quelque chose du genre, mais je n'obtiendrai jamais gain de cause si je suis pas en mesure de mettre le problème clairement en évidence.
Vous avez une idée ? Sachant qu'avec un test de stress, j'aimerais bien ne pas saloper mon SSD.

 
Tu as fait tourner Memtest combien de temps avant d'éliminer un problème de ram ?

9 ou 10 heures, ça me semblait suffisamment significatif (17 pass complètes, j'ai arrêté dans la 18ème).

Ext4 ?

 
Il a aussi ce genre de problème sous Windows  

Ah ok, j'ai lu en diagonale.

Le truc c'est que sous Windows, ça ne semblait commencer à couiller qu'après l'installation du framework .NET 3.5. Le truc zarb quoi.

Et sinon, oui, ext4.

Salut,
 
Je suis passé sous Arch Linux ce ween end, un de plus    
Pour l'instant pas de problème majeur, j'ai réussi à retrouver l'environnement que j'avais auparavant.
Par contre, petite question concernant la gestion de mes 4 gigas de RAM.
 
Actuellement, un free donne ça :

 
Donc mes 4 gigas ne sont pas reconnus totalement.
J'ai déjà connu ça sous Debian, suffisait d'installer un kernel-bigmem.
Qu'en est-il sous Arch Linux ?

Ca aurait pas été plus judicieux d'installer une x86_64 vu ta RAM ?

Ouais, non c'est juste que sous 32 Bits (Et sous Debian), avec un kernel adapté mes 4 gigas étaient correctement détectés, j'imagine que sous Arch Linux c'est également possible non ? (Activation de HIGHMEM dans le kernel peut-être ?)
J'ai de mauvais souvenir de lib chiantes à installer et à faire fonctionner correctement sous 64 Bits.

Ce n'est plus le cas, je suis moi même sous 64 bits. Et comme le dit souvent Dek, le maître de Arch sur HFR, AMD64 est l'avenir maintenant que tous les processeurs le supportent. Enfin, 32 tourne bien aussi hein

Ok, merci pour l'info.
Je vais chopper la version 64.
En tout cas, Arch Linux roxxx, pas déçu d'avoir basculé  

Oula, c'est me faire trop d'honneur, j'ai encore beaucoup à apprendre  

Pop pop pop, prend les compliments là où ils sont, c'est rare

Salut,
 
 
Je ne sais si c'est içi que je dois poser ma question mais j'ai un problème de son avec Amarok2.
Le son fonctionne correctement sous Firefox, etc. par contre pas moyen d'avoir du son sous Amarok2.
Dans les paramètres systèmes, j'ai xine en Backend et le test des sons fonctionne bien.
Quelqu'un sait d'où ça pourrait venir ?

J'ai joué un peu avec les scripts de démarrage d'Arch (en m'aidant un peu de Tweaking for a faster boot time - Arck Wiki) et j'ai réussi à passer d'environ 27 secondes de boot à environ 17 secondes. S'il y en a que ça intéresse je veux bien essayer de résumer ce que j'ai fais et partager les fichiers en question (/etc/rc.sysinit principalement).

Je suis preneur, pourquoi pas. Mon boot est déjà à 10 secondes à partir de GRUB jusqu'à KDM, merci le SSD, mais si je peux encore améliorer la chose, c'est cool

a force d'optimiser, on va peter le continum espace temps, et la machine aura fini de booter avant qu'on appuie sur le bouton

pareil le résumé m interesse
j avais trouvé un truc sur le forum arch us qui premet de speeder à mort le démarrage du pc en passant un truc en parametre du kernel, mais ca m a pas fait gagner grand chose j ai donc laissé tomber
 

Dans la série des tweak du boot, je viens d'essayer ça
http://bbs.archlinux.org/viewtopic.php?id=72156
 
Si j'ai bien compris, on va essayer de lancer Xorg assez tot dans la séquence de boot, et le reste continue à se charger en arrière plan.
Visiblement ça marche pas avec toutes les cartes graphiques, mais chez moi le résultat est impressionnant. Avant je devais compter ~50s pour arriver à gdm, puis encore 40-50 secondes pour charger entièrement gnome (j'ai un environnement assez lourd).
 
En couplant le lien ci-dessus avec readahead (qui va précharger tous les fichiers)
http://quasiyodel.wordpress.com/20 [...] archlinux/
je constate que xorg se lance au bout de 13 secondes, et le bureau gnome est entièrement chargé 45 secondes après le grub

OK. Alors le principe de base c'est de paralléliser les taches afin d'optimiser l'utilisation des ressources (notamment disque dur). Par exemple bloquer le système pour changer l'heure alors que ça ne demande ni CPU ni DD c'est un peu dommage.
 
Sur le même principe la vérification et le montage de tous les systèmes de fichiers n'ont pas besoin de bloquer le reste, seul la racine est indispensable (enfin ça dépend du partitionnement bien sûr, si /var est séparé il faut le monter aussi par exemple). Pour cela j'ai appliqué un truc tout simple qui est de mettre des ensembles de commandes en arrière plan et non seulement une commande à la fois. En effet il faut vérifier les systèmes de fichiers avant de les monter, mais on veut que le tout soit en arrière plan, donc on regroupe les deux commandes entre parenthèses et on met le & après. Ce qui donne:

Je suis en train de réfléchir à remplacer la variable DAEMONS du rc.conf pour appliquer ce même principe de séquentialité parallèle.
 
J'ai mis le chargement des modules en arrière-plan, ça ne m'a pas posé de problème mais je ne sais pas si ce serait le cas pour tout le monde.
 
Pour les fichiers c'est par là: mon rc.sysinit et mes bootchart.png. Je vous conseille d'utiliser diff (kdiff3 est excellent) pour voir ce que j'ai changé et appliquer seulement ce qui vous intéresse à votre fichier (en effet certaines choses ne sont peut-être pas souhaitables pour votre configuration), vous remarquerez que je n'ai pas supprimé grand chose, je me suis contenté de commenter. Évidemment un petit backup du fichier d'origine est conseillé.

j'ai un soucis
 
Je suis passé sous gnome et j'ai un problème de caractère quand je monte mon DD externe FAT32. Les àéèû, etc ne sont pas supportés.
Quand je monte le DD à la main avec l'option iocharset=utf8 ça fonctionne mais j'aimerai que celà soit automatique (comme sous KDE). Comment faire ?

Hop corrigé
Un coup de gconf-editor (en user) -> system -> storage -> vfat
Editer la ligne et ajouter "iocharset=utf8" sans les "" et roule ma poule

Me reste plus qu'à trouver où sauvegarder l'option ondemand pour le cpu car celui ci revient en performance à chaque reboot

Et rehop
 
Un coup de:
 

 
Dans rc.local
Si quelqu'un a une méthode plus propre, je suis preneur

/etc/conf.d/cpufreq
 
Puis rajoute cpufreq dans les DAEMONS du rc.conf