Reprise du message précédent :
Tu veux dire que les mêmes applications sortent du son si lancées depuis un environnement XFCE mais pas depuis une session E19 ?

Le son marche parfaitement sous XFCE mais pas du tout sous E19. Pavu ne m'indique pas de problème, ni le mixer d'E19.  
 
P.S:Je fais une purge du système.

Relis ma question. Pour les mêmes applications ?

Oui, toujours sur les mêmes logiciels. De toute façon, comme je le dis, je n'ai strictement plus aucuns sons. Mon ampli me dit qu'il ne reçoit plus rien.
 
Ce qui est con, c'est que le con vient de revenir mais il y a clairement un problème (j'ai relancé le Pc plusieurs fois avant que le son fonctionne correctement) et vu qu'il était déjà revenu hier pour repartir au boot suivant, je ne me fais pas trop d'illusions.  
 
 
 

Alors IMO, XFCE doit lancer pulseaudio dans ta session utilisateur, mais E19 non.
Depuis ta session e19, lance un "ps aux | grep pulseaudio" pour voir le daemon tourne.
Par contre je comprends plus rien là, il revient il repart ? wtf ?

Je te rassure, je ne comprend pas non plus.
 
Je regarderais ton truc plus tard. mais je suis sur que le démon tournait vu que Pavu n'était pas grisé.

un test simple à faire pour savoir si le problème vient d'un mixer audio GUI "E19" qui fout le boxon en imposant ses propres réglages ( du genre mute audio, curseur de volume au minimum, mauvaise sortie son, tout ça à l'insu de l'utilisateur ) :

- installer le paquet alsa-utils qui contient entre autres des outils de diagnostic audio en ligne de commande
- fermer ta session E19 afin d'être en mode console 100%
- tu tapes "speaker-test -c 2" pour tester le son, si tu entends du son alors c'est bon, le noyau 4.0 et ALSA gèrent bien ta carte son
- lance ta session E19, retape dans une console graphique "speaker-test -c 2", si pas de son alors c'est peut-être un mixer audio propre à E19 qui met des réglages incorrects pour le son, en supprimant le fichier de config de ce mixer audio ça peut résoudre le problème ( cas vécu avec KDE ), car un nouveau fichier de config peut-être correct sera crée au prochain démarrage,

si tu utilises pulseaudio pour gérer le son ( que perso j'aime pas ) alors c'est peut-être lui le coupable s'il y a des bugs, moi j'utilise que du 100% alsa pour gérer le son, ça réduit les risques de problèmes liés à une surcouche boguée,

tu peux aussi lancer "alsamixer" qui montrera de manière semi-graphique dans une console les entrées/sorties audio de chaque carte son avec un curseur de volume et l'indication si un "mute" audio est activé ou pas,

la consultation des fichiers log ( journalctl en mode root pour avoir le maximum d'infos, dmesg, pulseaudio ) doit permettre d'en savoir plus si un crash d'un élément s'est produit durant une session E19, si un message d'erreur a été émis dans les logs, si un démon a été stoppé subitement

Et s'assurer que c'est pas un device alsa quii bloque tout, tu as bien pulseaudio-alsa ?

 
J'arrive un peu tard ; j'ai désinstallé la version des dépôts officiels et installé p7zip920 de AUR. Retour à l'interface habituelle et pas de problèmes à noter.

merci de l'info je vais voir ça  

Sinon si t'es sous PA, tu utilises pavucontrol pour voir si du son arrive sur pulse.. ca permet de voir rapidement d'ou vient le soucis.

Salut,
je change de carte mere Vendredi et passe de BIOS a UEFI, y'a-t-il quelque chose de particulier a faire? ou Grub2 fonctionnera tout seul avec UEFI?
(Je suis deja en partitions GPT si ca avoir)
 
Merci!

j'y connais pas grand chose en uefi, partitions GPT car j'ai pas de carte mère qui gère ça
 
quand je lis le tutoriel grub/uefi d'archlinux ça me fait toujours peur car ils sous-entendent que l'implémentation d'uefi peut varier selon les cartes mères :
 
https://wiki.archlinux.fr/GRUB#Syst.C3.A8mes_UEFI
https://wiki.archlinux.org/index.php/GRUB#UEFI_systems
 
je pense que l'idéal serait de se faire la main sur une machine virtuelle qui émulerait le concept UEFI, avec virtualbox il y a une option UEFI quand on crée une machine virtuelle mais j'ai pas eu l'occasion de creuser la chose, mon raisonnement étant que si on arrive à maîtriser la chose sur une machine virtuelle alors on saura faire la même chose avec du vrai matos physique ( c'est comme ça d'ailleurs que j'ai appris à installer du linux, partitionner, je m’entraîne à blanc sur une machine virtuelle )

Je l'ai deja fait avec mes 2 autres PCs qui sont sous UEFI, mais je l'ai fait directement pas en transition depuis BIOS, et puis c'etait il y a un an alors je ne me souviens plus trop si fallait faire quelque chose de special

Je ne suis pas fan des machines virtuelles dans ce cas-la, car comme il y a toujours quelque chose qui cloche devoir reparer un VM avant de le faire sur la vraie... ca me parait une perte de temps.

On dirait que j'ai besoin d'une partition supplementaire pour UEFI ;/

Si tu veux pas te prendre la tête dans ce cas, ta carte mère doit avoir une option d'émulation de BIOS. Il me semble qu'il faut installer une version spécifique UEFI pour GRUB 2, si tu veux être compatible UEFI, enfin je dis ça de tête, car je suis sous Syslinux avec une "vieille" carte mère sans UEFI.  

La partition supplémentaire c'est pour le démarrage rapide du bios si je me souviens bien. C'est pas obligatoire.

 
Grub ou UEFI moi ca m'est egal... je vais regarder s'il y a cette option
Perd-on quelque chose en l'activant?
 

Ah si c'est le cas tant mieux, mais ce n'est pas ce que j'ai compris du wiki.
Au cas ou tu as raison je vais eviter de la creer avant de changer de carte mere..
 
Merci

La partition supplémentaire ? Tu parles de l'ESP ?
Non c'est juste là où sont stockés les loaders efi.
Et le chemin de cette partition est mémorisé dans ton bios/efi.

Je viens de vérifier, il semble que ce soit obligatoire. C'est 256Mo recommandé, en FAT32.

Au pire utilise l'émulation bios, pas sûr que tu y perdes quoi que ce soit.

J'ai ces 3 options d'apres le manuel:

J'imagine qu'en mettant Legacy ca devrait tourner en mode bios alors, ca serait pratique

oui il doit probablement y avoir un mode de compatibilité dans ton bios pour que ça marche comme le ferait un bios conventionnel, une option "legacy bios" pour le boot,

sur une gigabyte de 2013 d'un pote le bios était conçu pour switcher automatiquement en mode legacy s'il n'y a aucun périphérique/OS compatible UEFI, et on pouvait forcer le mode UEFI ou le mode legacy si la detection auto ne marchait pas

ici la méthode sur un bios asus uefi :

http://fr.tinypic.com/view.php?pic [...] UtGG_amUW0

Ca serait parfait, merci!

Je me suis fait une petite vm pour tester quelques tiling window manager.  
 
J'en ai profité pour le faire en UEFI, si ça intéresse quelqu'un :
 
http://webm.land/media/JEr4.webm

 
J'en ai profité pour tester une migration d'une installation vers du UEFI. Pour les gens que ça intéressent, je peux préparer un tutoriel mais je garantie rien que ça soit complètement opérationnel

Bon bah finalement c'etait en legacy tout seul donc pas de soucis

reste à voir combien de temps le mode "legacy" sera disponible sur les cartes mères, le risque c'est qu'à moyen terme on ait que des cartes mères qui ne fonctionnent qu'en mode "100% UEFI" sans rétrocompatibilité avec le mode MBR,

d'où ma suggestion de s’entraîner dans une machine virtuelle qui émule à 100% le concept UEFI, car à la base une machine virtuelle émule un PC complet, si ce "fake" PC intègre un UEFI avec son interface utilisateur alors c'est du caviar pour s’entraîner afin de reproduire tous les scénarios d'installation d'OS sur du UEFI, le secure boot et compagnie, le mode GPT, la partition ESP, tous ces nouveaux termes qui font peur à ceux qui n'ont connu que le MBR ( et ils sont nombreux ),

comme ça le jour où on aura une nouvelle carte mère "UEFI only" alors ça ne sera pas la panique, on saura comment procéder

Tu sauras proceder, sauf si ca aura encore changer

ou bien que l'UEFI aura fait un flop et qu'un successeur le détrône d'ici 5~10 ans, une nouvelle norme qui sera moins complexe, approuvée par Linus Torvald et qui respectera la rétro-compatibilité

Free bios.

On est vraiment loin de passer en Full UEFI, ça n'arrangerai vraiment personne quand même, ce genre de transition est très longue.

ceci dit les gens et les entreprises achètent surtout des PC préfabriqués ( Lenovo et compagnie ) avec OS "UEFI ready" déjà installé dessus, des PC portables, des tablettes,

les OS qui ne connaissent que le MBR ( ms-dos, windows XP ) sont en fin de vie ou déjà morts,

cette manière chez le grand public de consommer l'informatique "sans mettre les mains dans le cambouis" fait que la disparition de la rétro-compatibilité MBR pourrait se faire dans l'indifférence générale

les seules victimes seront probablement des gens comme nous qui font tout à la main en montant leur PC de A à Z pièce par pièce ( le genre de public qui achète encore des cartes mères ), et les techniciens en entreprise gérant du vieux matos qui ne se seront pas formés sur le concept UEFI

Apparemment, il n'est même plus nécessaire de générer un fstab. Je viens de me rendre compte que le fstab généré par genfstab est complètement vide.    
 

Et pourtant :

 
The Discoverable Partitions Specification

 
Tu l'as surtout généré au mauvais endroit (voir ~4m40 de ta vidéo).    
Je crois que tu as un fichier /fstab.    

Effectivement ! C'est moche !  
 

https://wiki.archlinux.org/index.ph [...] e_an_fstab

microsoft va donc imiter archlinux en adoptant le principe de la "rolling release" à partir de windows 10 :

http://www.itespresso.fr/microsoft [...] 95490.html

les prochaines versions de windows n'auront donc plus de numéro et les nouveautés/modifications seront intégrées dans les mises à jour disponibles sur internet,

et à priori l'utilisateur ne payera qu'une seule fois la licence, les mises à jours seront valables durant toute la durée de vie du PC, j'imagine néanmoins qu'il y aura toujours un système qui va lier la licence de l'OS au matériel ( numéro de série du disque dur, modèle de carte mère ),

prochaine étape : en finir avec les setup.exe vérolés/douteux afin d'inciter les utilisateurs à utiliser des dépôts sécurisés pour l'installation des programmes sous forme de paquets avec un gestionnaire d'installation à la pacman, car c'est toujours le talon d'Achille de windows cette trop grande facilité d'installer des applications en téléchargeant un setup.exe sur un site douteux

à voire aussi si les autres distributions linux comme ubuntu vont passer en mode rolling release par défaut

Ce serait justement dans les cartons, du côté de Redmond, ça : dans les préversions de Windows 10, il était justement possible d'utiliser un gestionnaire de paquets via PowerShell.

Je sais pas si oneget gère la notion de dépendances, c'est plus un store non ?

 
pour la convivialité il faudrait une interface graphique, un peu comme chez ubuntu, avec classement par catégorie de logiciels, un moteur de recherche,  
 
ce serait un grand progrès chez microsoft s'ils arrivent à convertir leurs utilisateurs et les éditeurs à utiliser un système de dépôt sécurisé, avec des certificats de sécurité pour être sûr que celui qui dépose le paquet n'a pas de mauvaises intentions,
 
et pour les logiciels exotiques et les éditeurs moins fiables il faudrait foutre tout ça dans un dépôt de type AUR,
 
s'il y a un suivi de dépendances, un système pour ne pas écraser des fichiers appartenant à d'autres paquets ça va renforcer considérablement la stabilité de l'OS,  
 
restera encore le problème de la base de registre, un gros bazar au fil du temps, un concept qui n'existe pas sous linux où l'on utilise que des fichiers de configuration par application

le bug de la calculatrice de KDE ( kcalc ) est résolu grâce à la mise à jour du paquet qt5 en version 5.4.1-8 :
 
https://bugs.archlinux.org/task/44676

Comme, par exemple, le... Windows Store (qui servira aussi à installer des logiciels Windows "classiques" dans Windows 10) ?
 

Pour ça, faudra faire marcher le bouche-à-oreille et que tout le monde dise que les logiciels normaux devraient être installés de préférence par le Store.
 

Avantages et inconvénients !
L'avantage du Registre (MS ne l'appelle plus "base de" depuis Windows 98 ) est de réunir tout ce que contenaient les divers fichiers .ini à un seul endroit, pour rappel. Même si ces derniers existent toujours et que certains petits logiciels gratuits les utilisent encore.
L'inconvénient, c'est que ça en fait un colosse aux pieds d'argile, surtout à cause de cette structure arborescente.

attention pour ceux qui utilisent KDE, à cause de l'hybridation "KDE4/applications KF5" j'ai découvert que le programme "kdesu" permettant de lancer des applications GUI en mode root ne marche plus ( le programme kdesu n'existe plus dans /usr/bin, même si on a installé le paquet kdesu   )
 
la solution constitue à installer le paquet "kde-cli-tools" :
 
https://bbs.archlinux.org/viewtopic.php?id=196227
 
il n'y a eu aucune news ou message d'information de la part de pacman vis à vis de ce problème