A la manière d’un bon artisan, chaque développeur et développeuse se crée au fil des années des habitudes et préférences vis-à-vis de ses outils de travail.
Comme beaucoup à OCTO, je travaille sur un Macbook Pro depuis plusieurs années. La flexibilité du système, l’implémentation native du Bash, sa certification POSIX, sa simplicité et sa stabilité à toute épreuve ne m'ont pas donné envie d’opter pour une machine sous Linux ou Windows jusque là.
Cependant, il est important pour un développeur d’être averti des nouvelles options qui s’offrent à lui au fil des évolutions techniques et des choix proposés par les grands noms de l’informatique. Et Microsoft en fait partie.
Windows 10 peut-il offrir un environnement de travail comparable à celui que j’ai sur mon Mac ?
La sortie de la génération de Macbook Pro mi 2016 déçoit :
Après 500 jours sans mise à jour hardware, quid des nouveautés ? Malheureusement, pas grand chose, hormis de notables régressions :
De plus, la machine semble présenter des problèmes structurels.
Côté software, Apple n’a quasiment pas fait évoluer son système depuis plusieurs années, pourtant celui-ci a ses défauts, notamment côté fiabilité, comme nous l’a prouvé l’update d’Avril 2018 en occasionnant des pannes.
Pour expliquer cette baisse d’intérêt d’Apple pour le Mac, il faut garder en tête que celui-ci ne représente que 10% du marché d’Apple, contre 75% pour l’univers iOS (iPhone/iPad).
Depuis 2016, Apple donne donc priorité aux équipes iOS, quitte à élaguer l’équipe Mac de ses développeurs, phénomène très bien expliqué dans cet article.
C’est ce constat qui m’a donné envie de regarder un peu ce qui se passait dans le monde Microsoft, son concurrent historique.
Et il s’en passe des choses chez Microsoft depuis 2016 !
Fin 2017, quelques semaines après la sortie du dernier Macbook Pro, Microsoft renforce une fonctionnalité présente dans Windows 10 depuis 2016 : le WSL (Windows Linux Subsystem).
Késako ? Il est désormais possible sous Windows 10 de monter une couche de compatibilité Linux.
En d’autres mots : du Bash sur Windows, sans virtualisation ni dual-boot.
Comme l'a été la sortie de l’éditeur de texte Visual Studio Code, la mise en open source du framework web .Net et le rachat de GitHub en 2018, cette fonctionnalité est une nouvelle ouverture de Microsoft à l’open source et au monde Linux depuis l’arrivée de Satya Nadella aux commandes de Microsoft en 2014.
Alors, est-ce que la solution proposée par Microsoft peut vraiment séduire un développeur sur macOS comme moi ? Nous allons voir !
C’est parti pour du sous-système Linux sur Windows !
La machine utilisée pour ce test est une tour PC (i5 4970k, 8 go Ram avec un SSD). Une version récente de Windows 10 y est installée (Avril 2018).
On va donc tenter de reproduire un environnement semblable à ce que j’ai sur mon Mac :
Rspec, Capybara pour les tests unitaires côté Rails
Il existe une solution via l’interface graphique pour installer le sous-système, mais Microsoft propose depuis peu une ligne de commande pour activer la fonctionnalité en PowerShell (l’invite de commande de Windows) :
Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux
Une fois la commande réalisée, rendez-vous dans le Microsoft Store.
On va utiliser ce store pour installer une distribution Linux soutenue par Microsoft !
A ce jour, Microsoft propose 5 distributions Linux :
On va jouer la sécurité en prenant Ubuntu 16, première distribution supporter par le WSL de Microsoft.
L’application est PEGI 3. Ne laissez pas votre enfant en bas âge installer le sous-système Linux tout seul ! #tousresponsables
Voilà, le sous-système est créé.
Pour le terminal, j’ai choisi le logiciel Hyper, un terminal basé sur Electron (NodeJs). Il jouit d’une excellente réputation sur Windows, et est facile à paramétrer. Pour lancer Bash par défaut sur Hyper, il suffit de modifier le fichier de configuration hyper.js et d’y ajouter cette ligne :
On ouvre Hyper et hop ! Bash is in da place !
On se retrouve avec toutes les commandes d’Ubuntu.
Commence alors l’installation de tous les outils nécessaires à mes projets web via apt-get :
Git, Node, Ruby, RVM.
J’installe un projet Ruby On Rails sur la machine et, après quelques minutes, j’obtiens le graal du développeur Rails : un Bundle install qui passe.
J’ai déjà eu des soucis à l’installation de certaines Gem Ruby sur MacOS (coucou LibV8 et Nokogiri). Ces mêmes problèmes sont rares sur Linux. Sur ce sous-système, c’est comme sur un “vrai” Linux. Donc pas de souci particulier !
J’ouvre facilement le projet avec Atom sur Windows 10, alors que le projet a été cloné avec Git du côté Linux (WSL). L’arborescence de fichiers est parfaitement partagée entre les deux systèmes :
Je configure mes bases de données de tests, je souffre alors de quelques freezes du WSL qui m’obligent à quitter Hyper de force (ça tourne mal).
Nous allons lancer une partie des tests unitaires présents sur le projet Rails pour vérifier le niveau de performance.Avant d’analyser les résultats, il faut savoir que la machine PC possède un processeur comparable au i7 4870HQ de mon Macbook Pro Retina de 2015.
Sa puissance brute est quasiment identique mais le PC ne possède pas la fonctionnalité d’hyper Threading de l’i7 du Macbook.
Pour que le test soit équitable, je vais forcer le Macbook à 1 thread, pareil sur le PC. Les deux machines sont équipés d’un SSD haut de gamme, celui du Mac est cependant plus performant.
Lançons les tests !
Et là… c’est la douche froide
La différence de performance est anormalement colossale :
Le Macbook a réalisé le jeu de test en 31 secondes, contre 138 pour le PC.
Des soucis de performance sur WSL ?
Pas tout à fait, la lecture de fichiers dans le sous dossier /mnt/… est lente car ce sont ces sous-dossiers qui sont lus à la fois par le WSL et le système de fichiers de Windows.
Malheureusement, cette même double-gestion cause des baisses de performance non-négligeables.
La lenteur de la gestion de fichier sur le WSL serait dûe à la protection en temps réel offerte par Windows Defender (activé par défaut).
Lors de notre séance de tests sous Rspec-Rails, très gourmande en requête I/O sur le SSD, nous voyons même le processus Anti-malware de Windows Defender “chiper” la première place devant Ruby !
Supprimons cette protection dans les paramètres de Windows Defender :
Je vous déconseille cependant de désactiver cette fonctionnalité, particulièrement efficace pour protéger votre machine de logiciels malveillants.
Revenons à nos moutons numériques et relançons les tests :
Enfin, les performances sont comparables à celles de mon Macbook Pro (en jaune dans le graphique), les quelques secondes perdues peuvent s’expliquer par un SSD plus performant sur la machine d’Apple :
Ce que je retiens de cette expérience, c’est que Microsoft prend la bonne voie. Cette solution semble promise à un avenir radieux !
Lors de mes essais, seuls deux points faibles sont venus atténuer mon enthousiasme :
Premièrement, en choisissant le WSL, on accepte de “jongler” entre deux mondes : celui du terminal Linux et l’interface graphique de Windows.
Il faut le reconnaître, Microsoft a fait un travail remarquable. L’installation est facile et la configuration d’un Bash digne de ce nom est très rapide. Mais je ne peux qu’imaginer les problèmes de configuration que cela doit impliquer sur des stacks plus complexes qu’une simple application Rails.
Deuxièmement, les freezes pardi !
En quelques jours, j’ai eu plus de freezes de mon terminal que pendant plusieurs années sur mon Mac. La solution est très jeune (2016) et s’améliore à chaque mise à jour, mais sa stabilité n’est pas encore au niveau de ses ambitions.
Cependant le WSL reste pour moi une bonne surprise.
Il y a quelques années, coder sur Windows pour un développeur habitué à Linux ou Mac revenait à se résoudre à utiliser des outils comme Cygwin/Babun, solution loin d’être sexy. De plus, coder sur Windows c’était apprendre une gestion différente des variables d’environnements, de gestion de droit, etc….
Aujourd’hui, Microsoft offre une solution beaucoup moins contraignante qu’un environnement Windows, sans l’installation parfois chaotique d’une machine Linux. En 10 minutes, on peut avoir accès à un (vrai) Bash Linux et y installer ses outils préférés facilement.