Pourquoi l’arrivée de systemd dans WSL est-elle si importante ?

Dans le petit monde l’IT et du Dev, il y a parfois de nouveautés qui passent inaperçues alors qu’elles sont très importantes. C’est le cas du support de systemd dans WSL.

Je suis franchement déçu que cela ne fasse pas couler plus d’encre.

Pour ceux qui ne connaitraient pas systemd, j’ai une petite analogie à vous proposer : imaginez un Windows sans gestionnaires de service, ni observateur d’évènements, et aucune capacité de choisir les applications lancées au démarrage. Cela semble un peu fou. C’est pourtant ce à quoi ressemblait WSL sans systemd (à peu de choses près).

Bien évidemment WSL incluait déjà des solutions pour pallier l’absence de systemd. Mais il y avait un très gros problème. Toutes les distributions Linux modernes reposent sur systemd. Avec le temps, nombre d’applications sont devenues dépendantes de systemd (proxy, serveurs web, bases de données, runtimes de conteneurs, firewall, serveur ssh, etc.). Nombre d’installations étaient donc impossibles. Dans le meilleur des cas, elles étaient très compliquées.

Conclusion

Le support de systemd dans WSL va simplifier énormément de choses. Il y a fort à parier que celui-ci va permettre d’introduire de nouveaux usages de Linux dans Windows.

Ajouté à cela le support de WSL2 par Windows Server 2022, j’en salive d’avance. On peut peut-être commencer à rêver d’une véritable intégration de conteneurs Linux, ou tout autre service serveur Linux, sur WSL et Windows Server.

Note : si aujourd’hui, systemd est très populaire, il faut se rappeler qu'il n'en était rien à ses débuts. Au lancement du projet, celui-ci était fortement critiqué. Nombre de développeurs lui reprochaient de ne pas respecter la philosophie Unix (en couvrant trop de besoins à la fois). Systemd était aussi critiqué pour sa complexité. Au final il s’agit de l’une de solution qui s’est le plus rapidement répandue parmi les distributions Linux. Au point d'être quasiment incontournable.

Jérémy Jeanson

Installer et utiliser facilement containerd sur Windows 11

Si vous avez déjà tenté d’utiliser containerd avec Windows 11 et WSL, vous êtes peut-être tombé sur un os. Entre l’installation du runtime, des plugins CNI, et de la CLI, il y a de quoi faire. WSL ne supportant pas systemd pour le moment, il faut en plus jouer avec genie pour obtenir une installation viable.

Bref, ce déploiement n’est pas drôle, et l’idée d’avoir à la reproduire sur plusieurs PC, ou à chaque mise à jour, n’est pas réjouissante.

Il y a pourtant une solution simple qui ne nécessite aucune connaissance technique. Une installation clé en main telle que l’on en rêve tous.

Visual Studio 2022 est-il viable pour développer en VB .net ?

Utiliser Visual Basic .net en 2022, cela semble peut-être un peu fou. Et pourtant, nous sommes encore nombreux à avoir besoin de maintenir des solutions .net écrites en VB.

Mais est-ce pour autant viable ? Les développeurs VB .net, sont-ils aussi bien lotis que les développeurs C# ?

Si vous utilisez Visual Studio 2022, je suis tenté de dire "peut-être bien que oui, peut-être bien que non".

Sur le papier, rien ne différencie l’expérience C# de l’espérance VB. Nous avons accès à la totalité de fonctionnalité d’édition, de parcours et de refactoring de code pour .net core et .net framework. Dans la pratique, il faudra distinguer deux cas de figure :

  • Les nouveaux projets.
  • Les projets migrés et/ou très anciens.

Le code mort : pas beau, pas écolo et dangereux ?

La notion de "code mort" ne vous parle peut-être pas, ou vous ne vous sentez peut-être pas concerné. Mais qui n’a jamais eu :

  • Une portion de méthode devenue inatteignable.
  • Une méthode ou une classe devenue totalement inutile.
  • Une feature désactivée via un feature flag qui ne sera plus jamais actif.
  • Une portion de code commentée.
  • Une dépendance devenue inutile.
  • Etc.

Nombre de situations peuvent nous amener à avoir du code mort ou des dépendances superflues. De premier abord, cette situation peut sembler anodine et sans conséquence grave. Au pire, il s’agirait peut-être d’un léger problème de qualité…

Au risque de passer à nouveau pour un extrémiste de la qualité, je vais présenter ici quelques problèmes découlant de la présence de code mort. Je vais enfoncer quelques portes ouvertes, énoncer quelques dangers que vous ne suspectez peut-être pas, et parler de leur impact environnemental. À une époque où l’on parle de plus en plus de sobriété numérique, j’espère que ce dernier point vous intéressera.

Pourquoi Trim(), ToLower() et ToUpper() sont-ils des signes de mauvaises pratiques ?

Quand on parle de qualité de code, chacun a ses habitudes pour identifier les problèmes. Certains lanceront systématiquement Code Analysis, NDepend, SonarQube, ou autres outils. D’autres préfèreront jeter un œil au code avant de faire quoi que ce soit.

Mais, il restera toujours quelques situations où l’œil humain sera le seul recours efficace. C’est le cas des mauvais usages des méthodes Trim(), ToLower(), et ToUpper() de String.

Ces trois petites méthodes insignifiantes sont de véritables gouffres à ressources et provoquent quantité de mauvaises pratiques.

Dit comme cela, je prends bien conscience que l’on va me prendre un fou. Il y a toujours un moment où l’on peut avoir besoin de celle-ci pour formater un contenu. Oui, c’est là leur but premier. Il y a cependant des dérives qui sont source de problèmes. Tant pour les performances, la compréhension du code, que pour la fiabilité de celui-ci. Il s’agit des conditions / tests.