Reprise du message précédent :
Ça me rassure, ça veut dire que c'est pas moi qui ai merdé un truc.

faites un test avec netctl, l'outil d'archlinux qui peut remplacer networkmanager,

pas d'interface graphique, ni d'icône user-friendly, c'est du 100% texte à configurer + mode console :

https://wiki.archlinux.fr/Netctl
https://wiki.archlinux.org/index.php/netctl

si le bug est toujours là alors ça doit venir du noyau linux, un bug quelque part pour certains chipsets wifi

on parle de kdesu, netctl n'y changera pas grand chose

Je pense qu'il parlait de mon autre problème de wifi lent sur le portable de madame.

T'as trop de problème j'y perd la tête

Le wifi c'est pas moi, c'est madame.

bonjour,
 
Ne m'incendiez pas, j'arrive pas à installer KDE, que ce soit sur une machine virtuelle ou sur ma machine physique. J'obtiens un écran noir.  
 
Le problème est présent depuis le passage à plasma.  
 
Par contre avec Gnome aucun problème.  
 
J'ai parcouru la doc Doc Kde , mais je ne vois pas où je me suis raté.  
 
Vu que Gnome fonctionne, je pense pouvoir exclure un problème de configuration Xorg. Mais je me trompe peut-être.

Quand tu es sur la session chargée (attends 15 secondes) devant ton écran noir, essaie "Alt + Shift +F12" pour désactiver le compositing
Regarde aussi Xorg.log et .xsession-errors.
Quels drivers video tu tuilises ?

Aussi donne plus d'informations.
"J'arrive pas a installer KDE" ca ne dit pas grand chose, surtout quand apres tu dis avoir un soucis non pas avec l'installation mais l'utilisation.

il s'est peut-être trompé dans la manière de lancer kde, le truc tout simple de startx devrait fonctionner, à condition de bien lire le wiki archlinux,

d'abord installer le paquet  "xorg-xinit" qui fournit startx,

puis créer dans son home ( dans le cas présent : /home/Hanka ) un fichier caché ".xinitrc", dans ce fichier tu mets cette ligne :

puis tu désactives le service sddm avec systemd ( systemd disable sddm.service ), et tu lances kde en tapant "startx", ça devrait se lancer, sauf bug du pilote vidéo de virtualbox ( lire le fichier log de Xorg, un cat /var/log/Xorg.0.log | grep "WW", et cat /var/log/Xorg.0.log | grep "EE" )

il faut lancer startx pas en mode root mais depuis ton compte utilisateur,

sur un vieux portable de 2003 je n'avais pas réussi à lancer plasma 5, la raison étant que plasma 5  et sddm utilisent la version 2.0 d'openGL ( via une fonction de Qt5 ), sur ce vieux portable la carte graphique ne supporte que l'openGL 1.3, les développeurs de plasma et sddm n'avaient pas pensé aux possesseurs de vieux matos, du coup je suis passé à lxqt ( et slim pour remplacer sddm ) sur ce vieux portable

bonjour, merci pour vos réponses.  
 
Je peux affirmer que Xorg fonctionne à priori correctement. Puisque actuellement par dépit, j'utilise l'envirronnement Gnome.  
 
Pour le matériel, sur ma machine virtuelle, j'utilise le driver vesa et sur la machine physique, j'ai une carte graphie Nvidia GTX 770 avec le driver propriétaire Nvidia.

tu utilises virtualbox comme machine virtuelle ( plus simple d'usage ), ou qemu ( un peu plus délicat à configurer ) ?

lire le wiki archlinux concernant virtualbox pour voir si tout a bien été configuré,

quand tu as l'écran noir essaie de basculer sur une console ( une combinaison de touches ctrl + alt + F2 ), tu te connectes et tu tapes les commandes que j'ai indiqué pour voir le contenu de Xorg.0.log

en fait j'utilise virtualbox quand je suis sur mon pc Windows. C'est sur cette machine virtuelle que je fais mes tests avant d'installer le pc Linux.

J'essaierai la commande que tu m'indiques au prochain démarrage de mon pc Linux.

merci pour l'aide.

Edit: en suivant un poste sur un forum anglo saxon, j'ai installé le meta package plasma-workspace. En suivant la doc, j'avais juste installé le programme plasme et sddm.  Il m'a ajouté quelques programmes et maintenant, ça fonctionne. Je ferai la même chose sur ma machine physique et je noterai les programmes qu'il ajoute pour comprendre.

Bon, c'est pas vraiment une question sur Arch mais plutôt sur Firefox, mais ça m'arrive en étant sous Arch alors bon...
 
J'ai essayé, sur Firefox 48 et 49, d'activer Electrosysis en le forçant dans about:config ; ça a fonctionné, seulement j'observe un bug assez gênant : très souvent, le fait de changer d'onglet n'actualise pas le titre de la fenêtre de Firefox, qui reste avec le titre de l'ancien onglet.
 
Est-ce que certains ont essayé Electrolysis et ont constaté ce phénomène ?

des infos sur cette fonctionnalité, peut-être pas encore arrivée à maturité, d'où les bugs :
 
https://wiki.mozilla.org/Electrolysis
 
faut vérifier que les extensions que tu utilises sont compatibles avec e10s, on peut le voir dans about:support à la ligne "Fenêtres multi-processus"

Ayant une connexion moisie à l'autre bout du monde (équivalent à 1méga en download donc téléchargement max à 100 - 120 ko/s), il y aurait-il un moyen de partager les paquets issus de dépôts Arch. Le but n'étant pas de faire un miroir comme je l'avais déjà fait sur une autre distrib (debian et ubuntu) avec apt-mirror il me semble mais qu'une machine principale télécharge les paquets et les partages pour les autres machines. Ca évite de télécharger deux fois le même paquet.
J'avais fait un truc crado sous Ubuntu avec un partage nfs et des liens symboliques mais bon pas l'idéal lorsqu'un laptop quittait le réseau. Si certains ont des pistes je serais preneur.

Edit : Trouvé => http://xyne.archlinux.ca/projects/pacserve/
https://github.com/rakoo/paclan

en quoi ça va résoudre ton problème de lenteur de téléchargement si l'autre PC qui fait office de serveur utilise la même connexion internet ultra lente ?

Le premier PC fait office de téléchargement initial. Les deux PC sont sur le même réseau. La priorité se fait sur le réseau local après le téléchargement du premier PC puis si nécessaire (paquet non présent sur le PC 1), le PC2 télécharge les paquets manquants.
Le problème c'est que je n'ai pas que 1 ou 2 mais plusieurs donc là ça devient intéressant ce genre de système

Autant juste foutre le répertoire de cache de pacman sur un montage réseau et les deux peuvent bosser dans leur coin et récupérer juste ce qui leur manque (pas en même temps par contre)

Oui c'est la bidouille que je faisais avec mes liens symboliques sur Ubuntu.  
Là pacserver semble plus adapté franchement.
Il est où l'index des paquets présents dans /var/cache/pacman/pkg/
 
Au passage je suis passé à Plasma 5.7.5, c'est pas mal du tout et consomme autant que mate + compiz

Il me semble qu'il n'y en pas

Hum, ça me paraît bizarre.
Si on prend deux machines après avoir fait un pacman -sc sur les deux. On installe un paquet, on copie le paquet téléchargé sur l'autre machine, l'autre machine retelecharge le paquet donc il y a bien un truc qui référence les paquets

Si tu copies le paquet sur ton autre machine au bon endroit, il ne devrait pas telecharger ce paquet avec pacman -Su.

Je vais restester alors, merci

Bien sur cela n'est vrai que si les 2 machines sont sur la meme Arch (x86 vs amd64), et les memes depots (stable vs testing), etc.

C'est le cas, je fais que des configs homogènes ;-)

Pas forcément
Mais ça doit marcher dans tous les cas, quitte à re-DL la différence.

bug posté dans le topic kde/plasma, mais je le poste aussi ici au cas où le problème serait lié qu'à archlinux :

j'ai remarqué un nouveau bug avec la version 5.8 de plasma : l'arrêt est beaucoup plus lent quand on se déconnecte de plasma, il y a plusieurs secondes où il ne se passe rien ( le bureau reste affiché avec aucun sablier, comme si on n'avait pas cliqué sur l'icône "shutdown" ), il y a une sorte de latence de quelques secondes avant que plasma ne se décide à s'arrêter,

avec la version précédente de plasma l'arrêt était beaucoup plus rapide, j'ai l'impression que c'est lié au nouveau thème "encore plus flat design" de l'écran de déconnexion ( le truc tout bleu et plat au niveau des icônes "reboot", "shutdown", "disconnect" ), quand je clique dessus pour arrêter plasma j'ai l'impression que le clic n'est pas pris en compte car il n'y aucun sablier au niveau du curseur de souris, en fait le clic est bien pris en compte mais comme il n'y a pas d'indices, de sablier alors ça entraine de la confusion, des doutes

Perso, ça a pas fait long feu chez moi KDE plasma, une impression de lenteur et c'est pas ultra stable quand la charge du système est à 100%
Reparti sous xfce mais c'est moins ergonomique que mate sur lequel je vais revenir je sens

Salut
 
Heureux utilisateur d'arch depuis 6 mois, il n'y a qu'un truc qui m'embête : les MàJs.
J'adore être en rolling release et avoir les dernières versions des softs (c'est une libération après des années passées sous debian   ). Par contre, j'oublie souvent de lancer pacman pour faire les MàJs. Du coup, quand j'y pense, j'ai énormément de MàJ d'un coup ; c'est souvent assez long et embêtant si j'ai besoin d'utiliser pacman pour autre chose pendant ce temps.
 
Du coup, j'hésite à mettre pacman en tâche cron. À quel point est-ce une mauvaise idée ?

plutôt que cron essaie de créer un service systemd basé sur les timers, service qui fera un pacman -Syu à intervalle régulier,
 
https://wiki.archlinux.org/index.php/Systemd/Timers
 
mais c'est pas une bonne idée car tu risques de louper les messages de warning/info de pacman, parfois dans ce message d'info de pacman il y a une manœuvre à faire pour que la mise à jour se passe bien,
 
bref le système de mise à jour de pacman n'est pas vraiment conçu pour être automatisé, c'est pas du windows update, ça oblige l'administrateur à le lancer manuellement et à surveiller la sortie de la console en cas de problème ou de manoeuvre manuelle à faire, tu as aussi le fichier log de pacman que tu peux lire si tu as oublié de surveiller la sortie console de pacman,
 
une alternative c'est d'utiliser le calendrier de thunderbird pour mettre un rappel type "pensez à faire un pacman -Syu" qui se répétera toutes les semaines,
 
ou de créer un programme vraiment conçu pour surveiller la sortie de pacman ( les éventuelles infos, "pacnew" files crées, les warnings ) et le programme avertira ensuite l'administrateur qu'il y a eu un souci durant la mise à jour, ou integrer cette fonctionnalité "mise à jour auto" dans pacman, dans le fichier de configuration de pacman afin que tout soit bien sécurisé/blindé

+ Les paquets de remplacement, les nouveaux groupes, faut faire des choix.
C'est quoi qui est long ? Le D/L ou le désarchivage/trigger ?

ah oui c'est vrai il y a aussi le fait qu'un pacman -Syu risque de poser des questions quand un paquet est en conflit ou doit être remplacé par un nouveau paquet

si on veut vraiment un truc auto "sécurisé" il faut intégrer cette fonctionnalité à l'intérieur même de pacman, avec des réponses par défaut aux questions, ou une réponse adaptée au contexte,

car souvent quand pacman pose des questions "voulez-vous remplacer le paquet (O/N) ?" ça donne l'impression qu'on peut choisir la réponse mais en fait il n'y a qu'une seule réponse valable ( la mauvaise réponse risquant d'empêcher la mise à jour )

Ouais c'est bien ce que je pensais, c'est difficilement automatisable

@make install : c'est surtout le DL des paquets qui est long avec pacman. Avec yaourt pour l'AUR, c'est surtout l'étape « compressing package » qui est longue, mais c'est une autre histoire  

À tout hasard, pacman n'aurait pas une option pour télécharger les mises à jours mais sans les appliquer ?
Ça permettrait d'automatiser le téléchargement, sans tous les problèmes créés par l'application de la MàJ. Et quand je pense à lancer une update, il pioche directement dans les paquets déjà DL, ce qui diminuerait le temps d'update…  

EDIT: en cherchant un peu sur la doc je suis tombé sur ça : https://wiki.archlinux.org/index.ph [...] _to_system . Il y a peut-être moyen de faire ce que je décris  

il faut utiliser le commutateur -w :
 

 
genre pacman -Syuw ?

J'étais en train de lire la man page, je viens de tomber dessus en effet  
Je vais faire quelques tests, ça me parait faisable    
 
Merci en tout cas

Du coup je vais faire tourner ce script en tâche cron timer systemd :

Je vais le tester pendant quelques semaines, histoire de voir si ça fonctionne correctement ou si ça plante misérablement (ce qui n'est pas impossible )
Et aussi (évidemment) pour voir si pacman me donne l'impression d'aller plus rapidement durant les MàJs  

 
 
Change la methode de compression dans /etc/makepkg.conf, ca ira mieux.
Je suis en .tar.gz pour cette raison, mais j'aurais pu prendre .tar tout court...

Voilà, ma question était pas innocente, j'allais proposer -w pour ce cas
Donc un truc safe (mais que je ferais quand même pas car merci les grosses pertes de débits quand le cron se lance... ) c'est de planifier des:

Comme ça il va DL à l'avance les paquets par défaut, mais dans ton Syu interactif tu pourrais éventuellement être amené à en DL d'autres dans de rares cas.

 
Je vient d'activer les threads pour xz, ça devrait déjà augmenter un peu la vitesse de compression, je verrai après si c'est encore trop long
 

 
C'est ce que j'ai fait du coup
par contre,

est un peu plus propre    
 
Au final, j'ai un timer qui lance le DL 15 minutes après le boot, et puis toutes les semaines après

Sauf si tu sauves tes paquets aur dans ton cache (ce que je fais) xz n'a pas vraiment d'intérêt.
C'est pratique pour telecharger mais localement..