Une liste d'outils pour que Windows ressemble davantage à Linux
Depuis que je passé à Windows 10 avec WSL J'ai pensé que je ferais une liste de logiciels que je devais utiliser pour rapprocher Windows de mon flux de travail Linux habituel. Disons clairement que l'interface utilisateur de Windows craint, elle est bloquée dans le90s et tout est censé être cliqué et déplacé avec le pointeur de votre souris. je ne sais pas si c'est un culture chose (les développeurs Windows doivent beaucoup aimer la souris), ou pour démographique cible ("cliquez sur cette chose!" est facile à expliquer), ou à cause de bonnes pratiques de sécurité (si nous donnons trop de contrôle à l'utilisateur, le malware l'exploitera) ou simplement le Shell Windows étant constitué d'un tas de dette technologique qui rend plus difficile l'ajout de fonctionnalités pour les utilisateurs avancés. Le fait est que les choses simples sous Linux nécessitent des solutions alambiquées sous Windows.
Sous Linux, chaque gestionnaire de Windows a une forme de bureau virtuel, Windows a créé des bureaux virtuels assez récemment avec W10. Le fait est qu'au moment d'écrire ces lignes, vous ne pouvez parcourir que de gauche à droite avec des raccourcis clavier, et il n'y a pas de raccourcis clavier pour accéder au bureau X. Il y a ceci bibliothèque vd mais je n'ai pas trouvé de logiciel qui l'utilise, à la place seulement AHK[1] scripts avec des implémentations médiocres comme "boucler jusqu'à ce que nous soyons au bon VD".
Le manque de raccourcis appropriés pour les bureaux virtuels intégrés à Windows m'a obligé à utiliser des logiciels tiers, dont il existe de nombreux, j'ai choisi dexpot car il fait toutes les choses dont j'aurais besoin et plus (je serais heureux avec justego to X etmove window to X raccourcis). Le seul problème était que dexpot n'est pas capable de lier des clés déjà liées... AHK est en quelque sorte capable de remplacer les clés utilisées par d'autres applications, alors que dexpot ne le fait pas, je suppose que c'est parce qu'il repose sur une API Windows différente (ou [dll]). La solution de contournement consiste à remapper les raccourcis que je voulais (par ex.Win+1 ) avec un raccourci gratuit qui peut être défini sur dexpot (par ex.Win+Shift+F1)
Powertoys permet de mapper les touches et les raccourcis, de sorte que je puisse mapper CapsLock->LeftControl et RightControl->LeftControl. Et des raccourcis commeWin+hjkl aux flèches. DommageWin+l est un raccourci par défaut de Windows pour verrouiller l'écran et ne peut pas être remappé... une clé de registre remplace les raccourcis et corrige cela... jusqu'à ce que vous mettiez à jour Windows... vous devez donc appliquer le correctif à chaque démarrage !
Le lanceur d'applications fourni par powertoys est plutôt fonctionnel, n'utilise pas beaucoup plus de mémoire que KRunner et est rapide et réactif. La seule plainte est que de temps en temps il perd le focus, mais c'est très probablement un problème avec le contrôle malade (comme dans le cas pervers) de la fenêtre qui est censée être focalisée à un moment donné.
Je suis passé de Sway à KDE sous Linux, donc je n'étais pas vraiment un amoureux des fenêtres en mosaïque. Powertoys a FancyZones qui est une légère amélioration par rapport aux fenêtres de base Snaps que cette fenêtre offre, car elle vous donne lacunes et mises en page. Pourtant, il manque encore la chose la plus importante qui rend le carrelage utile, c'est-à-dire règles à appliquer aux fenêtres correspondantes, mais cela nécessiterait également la prise en charge des bureaux virtuels... et nous avons déjà mentionné leur état actuel. En comparaison, KWin vous permet de faire correspondre des fenêtres avec des définitions très complexes. FancyZones contourne le problème des règles en préservant les positions des fenêtres d'une session à l'autre, mais je n'ai pas étudié dans quelle mesure cela fonctionne avec différents bureaux virtuels.
Les fenêtres ne peuvent être déplacées qu'à partir de la barre de titre, et un utilitaire doit être utilisé pour les déplacer avec une combinaison de raccourcis.
Avec KDE, vous disposez de widgets plasma pour afficher les informations système, bien que les widgets plasma aient tendance à consommer beaucoup de mémoire, je ne les ai donc pas beaucoup utilisés. Avec Windows, il n'y a pas d'utilitaire intégré pour cela, après avoir essayé quelques utilitaires sur lesquels je me suis installé Moniteur de trafic qui donne le réseau, le processeur, la mémoire, et tout récemment ont été ajoutés GPU et temps. Le résultat est un joli rectangle discret affiché dans la barre des tâches :
Le point bonus pour Windows est que mon UPS est reconnu et affiché dans la zone de la barre d'état système, il n'a donc pas besoin de configuration supplémentaire, alors que sous Linux NOIX il y a problèmes de pilotes.
Beaucoup n'aimaient pas systemd quand il est arrivé dans le noyau Linux..Avec Windows, j'ai plutôt commencé à le manquer..Services Windows n'est pas vraiment quelque chose d'orienté vers les utilisateurs comme systemd. Windows a le Planificateur de tâches faire face à des choses qui ressemblentone-shotfichiers unitaires, mais encore une fois son interface (ou son absence) est épouvantable. Heureusement pour nous, nous n'avons pas vraiment besoin de démons personnalisés dans Windows, car la plupart des applications Windows que nous utilisons sont censées ne exécuter au démarrage sorte de logique, et n'ont pas besoin de configurations plus avancées. En fait, à part la litière d'outils ( soupir ) pour que Windows fonctionne comme un environnement moderne, alors seules les autres applications Windows natives utilisées sont le navigateur ( firefox ) car l'accélération GPU du navigateur est mauvaise dans WSL (enfin même sur Linux natif...) et le lecteur vidéo ( monospace )..et des jeux bien sûr...
je n'aime pas chocolaté comme cela nécessite des privilèges d'administrateur, je recherche toujours d'abord les packages scoop car ceux-ci sont installés dans le dossier utilisateur, ce qui est plus pratique et plus cohérent, et simplifie les sauvegardes.
J'ai été amené à passer à Windows depuis la récente WSLg mettre à jour. Ce qui nécessitait des pilotes mesa compilés avec led3d12 prise en charge du backend pouropengl . Windows fournit une couche ubuntu d'aperçu communautaire, mais j'ai opté pour arc linux puisqu'il existait déjà un package AUR pour mesa avec d3d12 . Étant donné que WSL ne prend actuellement pas en charge systemd, j'ai fini par utiliser superviseur pour gérer quelques services. Pour s'assurer que le superviseur est actif, il y a une vérification dans le profil du shell pour un fichier de verrouillage qui doit être créé surtmpfs si le superviseur a déjà été démarré.
WSL prend en charge uniquementext4 systèmes de fichiers, pour utiliser d'autres systèmes de fichiers, vous devez monter la partition (ou le disque) directement à l'intérieur de la VM WSL. Cependant, ils doivent être montés manuellement en tant qu'administrateurdes fenêtres. Pour automatiser cela, nous pouvons utiliser le planificateur de tâches qui permet de contourner l'invite UAC en exécutant des tâches avec le plus grand privilège . Nous pouvons exécuter un wsl--mount pour monter nos disques/partitions souhaités, puis exécutez monter le système de fichiers à partir de Linux. Parce que mon/home/ réside dans une monturebtrfs système de fichiers, je dois le monter automatiquement, nous utilisons donc/etc/fstab pour mapper notre partition (enLABEL ) à/home . Parce que nous utilisons nix avecnix-env nous devons lier le montage de notre magasin nix à/nix à chaque démarrage de wsl, et parce que/tmp n'est pas allumétmpfs nous devons créer une monture superposée qui montetmpfs sur l'existant/tmp répertoire, pour conserver les fichiers importants, en particulier les fichiers X11, nécessaires pour communiquer avec le serveur X.
Ces montages sont exécutés avec un script, qui doit être exécuté après nous avons monté le disque sous Linux. Nous avons besoin d'une tâche qui s'exécute une fois la tâche de montage terminée, et comme WSL utilise différentes machines virtuelles pour différents utilisateurs Windows, le script doit être exécuté NON avec les privilèges les plus élevés (sinon, il serait monté sur la machine virtuelle administrateur).
Pour garantir que WSLg fonctionne, nous devons nous assurer que le XDG DURÉE DIR est défini, car il est différent et situé (par défaut) à/mnt/wlsg/runtime-dir . Voici à quoi ressemblent les fenêtres sous wayland, vous pouvez voir que puisque les décorations de fenêtre wayland peuvent être dessinées par le compositeur ou l'application, elles conservent la configuration de votre thème GTK/QT, vous vous retrouvez donc avec une fenêtre de thème Linux natif. à l'intérieur d'un shell Windows... ce qui est un peu déroutant au début.
Sous Linux, j'utilisais minou , car il s'agissait de l'un des émulateurs de terminaux les plus récents avec accélération GPU[2]et un mode démon quelque peu stable qui permet plusieurs fenêtres avec la même instance. Cependant, sur Windows, j'ai essayé quelques terminaux basés sur Windows comme Windows Terminal, Fluent Terminal, wsltty, conemu, mais finalement je suis passé à wezterm . Bien qu'il s'agisse d'un terminal plus récent, il possède toutes les fonctionnalités que vous attendez d'un émulateur de terminal :
onglets et volets, de sorte que vous n'avez pas besoin de tmux
un multiplexage (mode sans tête à distance), tel que vous n'avez pas besoin de tmux
mode de copie de texte avec les raccourcis clavier vi, de sorte que vous n'avez pas besoin de tmux
sélection rapide, un mode indice pour sélectionner rapidement des objets de texte à partir du défilement arrière
commandes par défaut pour les nouveaux onglets
Très bonne personnalisation des key-maps, à part le fait que vous ne pouvez pas utiliser Maj gauche/droite/Ctrl/Alt comme différents modificateurs.
Avec Windows, j'ai également modifié un peu mon flux de travail de telle sorte que je n'ai pas besoin d'un terminal avec un mode démon prenant en charge plusieurs fenêtres distinctes, en utilisant un terminal déroulant. Pour faire wezterm menu déroulant après avoir essayé de nombreux scripts AHK déroulants, j'ai finalement trouvé une cela a assez bien fonctionné. Une meilleure alternative serait cependant Windows-terminal-quake, mais j'ai eu des problèmes avec les bureaux virtuels gérés par dexpot, alors que mitty-quake-console semble être compatible avec les bureaux virtuels de dexpot. Très probablement, lorsque l'expérience des bureaux virtuels Windows intégrés s'améliorera, je passerai à Windows-terminal-quake. WezTerm est également multiplateforme, ce qui signifie que je peux continuer à l'utiliser avec une installation Linux native. Ce fut une découverte vraiment chanceuse pour ce commutateur Windows + WSL, car Kitty ne prend pas encore en charge Windows, et les autres alternatives de terminaux ont eu des inconvénients assez importants qui Je ne pouvais pas me réconcilier avec.
| [1] | Touche de raccourci automatique |
| [2] | pourquoi encore ai-je besoin d'une accélération GPU dans le terminal? |
