Ubisoft se prépare à introduire de nouveaux modes de jeu classés (ranked) au sein de For Honor, son champ de bataille virtuel dans lequel on peut gaiement s’étriper à grands coups de masse d’armes. La nouvelle est à première vue plutôt bonne pour les adeptes de ce titre sorti en 2017, puisqu’elle montre que l’éditeur continue à entretenir la flamme.

Elle s’accompagne toutefois d’un changement qui risque de faire grincer quelques dents : à compter du 10 septembre, date du lancement de la saison associée à ces modes classés, le titre ne sera plus jouable sur Linux et, par extension, sur le Steam Deck de Valve (dont l’OS exploite une base Arch).

Ubisoft s’en explique de la façon suivante :

« Afin de garantir un environnement compétitif équitable, l’équipe met en place des mesures de sécurité supplémentaires pour les joueurs. Nous retirons For Honor de la plateforme Linux pour assurer un environnement plus sûr, car il nous est impossible d’y déployer une protection efficace. Par conséquent, For Honor ne sera plus jouable sur Steam Deck à partir du 10 septembre. Nous continuons d’explorer différentes pistes pour améliorer notre système anti-triche, avec la possibilité de rouvrir la plateforme ultérieurement. »

L’éditeur ne donne pas de détails techniques précis, mais il invoque donc l’objectif de lutte contre la triche pour justifier cette décision. For Honor était compatible avec Linux depuis 2023, suite à l’adaptation deux ans plus tôt par Epic de son logiciel anti-triche, Easy Anti-Cheat pour assurer le support des trois environnements courants (Windows, macOS et Linux). Sur Reddit, la communauté For Honor a accueilli la nouvelle en des termes que la décence nous interdit de reproduire.

La décision d’Ubisoft semble particulièrement à contre-courant de la tendance générale, alors que la rumeur murmure qu’EA travaille à l’adaptation de son propre anti-cheat, Javelin, pour Linux, et qu’Epic prépare l’arrivée de son propre Store sur le système d’exploitation libre.

Ubisoft se prépare à introduire de nouveaux modes de jeu classés (ranked) au sein de For Honor, son champ de bataille virtuel dans lequel on peut gaiement s’étriper à grands coups de masse d’armes. La nouvelle est à première vue plutôt bonne pour les adeptes de ce titre sorti en 2017, puisqu’elle montre que l’éditeur continue à entretenir la flamme.

Elle s’accompagne toutefois d’un changement qui risque de faire grincer quelques dents : à compter du 10 septembre, date du lancement de la saison associée à ces modes classés, le titre ne sera plus jouable sur Linux et, par extension, sur le Steam Deck de Valve (dont l’OS exploite une base Arch).

Ubisoft s’en explique de la façon suivante :

« Afin de garantir un environnement compétitif équitable, l’équipe met en place des mesures de sécurité supplémentaires pour les joueurs. Nous retirons For Honor de la plateforme Linux pour assurer un environnement plus sûr, car il nous est impossible d’y déployer une protection efficace. Par conséquent, For Honor ne sera plus jouable sur Steam Deck à partir du 10 septembre. Nous continuons d’explorer différentes pistes pour améliorer notre système anti-triche, avec la possibilité de rouvrir la plateforme ultérieurement. »

L’éditeur ne donne pas de détails techniques précis, mais il invoque donc l’objectif de lutte contre la triche pour justifier cette décision. For Honor était compatible avec Linux depuis 2023, suite à l’adaptation deux ans plus tôt par Epic de son logiciel anti-triche, Easy Anti-Cheat pour assurer le support des trois environnements courants (Windows, macOS et Linux). Sur Reddit, la communauté For Honor a accueilli la nouvelle en des termes que la décence nous interdit de reproduire.

La décision d’Ubisoft semble particulièrement à contre-courant de la tendance générale, alors que la rumeur murmure qu’EA travaille à l’adaptation de son propre anti-cheat, Javelin, pour Linux, et qu’Epic prépare l’arrivée de son propre Store sur le système d’exploitation libre.

Ça pousse plus vite ?

Vous avez toujours rêvé de vous passer de la virtualisation pour faire tourner des services complètement différents en parallèle sur une même machine ? C’est ce que propose mklinux en permettant de faire tourner des noyaux Linux en parallèle.

Le responsable de l’entreprise Multikernel Technologies, Cong Wang, a annoncé, la semaine dernière sur la mailing list du noyau Linux, la sortie de son projet mklinux v7.0-mk2 (disponible sur GitHub). Celui-ci permet d’exécuter plusieurs noyaux sur un même ordinateur, sans hyperviseur, donc sans virtualisation. Chacun d’entre eux gère réellement le matériel qu’il utilise.

« L’arborescence est basée sur la version 7.0 [du noyau Linux]. Avec CONFIG_MULTIKERNEL=n, elle se compile et se comporte exactement comme la version 7.0 », précise-t-il.

Chaque noyau s’exécute sur son propre matériel

Le principe est que mklinux (ou multikernel) lance un premier noyau qui gère un certain nombre de processeurs, de la mémoire et des périphériques. Ce premier noyau divise ces ressources « en instances et démarre un noyau dérivé dans chaque instance via la fonction kexec_file_load() », explique Cong Wang.

« Chaque noyau dérivé s’exécute en mode natif sur ses propres processeurs, sa propre mémoire physique et ses propres périphériques. Rien n’est émulé et rien n’est intercepté ; la seule chose partagée est ce que vous choisissez de partager », ajoute le responsable du projet.

Optimisation du traitement et de l’exposition aux risques

L’idée de multikernel est de proposer une véritable isolation au niveau du noyau « avec des performances proches de celles d’un système « bare-metal » et une allocation dynamique des ressources, sans la surcharge d’un hyperviseur », comme l’explique la FAQ du projet. Cela doit permettre une optimisation de la vitesse de traitement et de l’exposition aux risques.

La promesse de cette architecture est que le blocage d’un noyau, une faille de sécurité le touchant ou un kernel panic n’aient aucune conséquence sur les autres systèmes qui tournent en parallèle.

Le concepteur explique dans son message avoir validé par des tests : « Des instances ont été lancées, arrêtées, reconfigurées et relancées dans le cadre de longues boucles de test […] ; un plantage dans un noyau n’affecte pas les autres, et il est confirmé que chaque processeur attribué à une instance est remis en veille sur l’hôte avant d’être réutilisé ».

Et, « en comparant aux machines virtuelles, il n’y a pas de chemin de sortie de la VM, pas de deuxième niveau de tables des pages et pas de modèle de périphérique », ajoute Cong Wang.

Dans son annonce, il donne quelques comparaisons de performances. Ainsi, face à une machine virtuelle KVM, multikernel est de 1,07 fois (fork + sortie) à 2,5 fois plus rapide (changement de contexte), avec une bande passante mémoire et une latence équivalentes :

Pour l’instant, multikernel fonctionne sur architecture x86_64, même si l’annonce sous-entend que le projet ne s’y limitera pas. D’ailleurs, sur son site, l’entreprise vante déjà des solutions pour ARM ou RISC-V.

En pratique, quelles utilisations cible le projet ? Multikernel Technologies propose déjà plusieurs offres de service destinées aux entreprises visant la mise en place de clouds privés sans hyperviseur, le sandboxing d’agents IA et la mise à jour du noyau sans avoir à redémarrer la machine.

Ça pousse plus vite ?

Vous avez toujours rêvé de vous passer de la virtualisation pour faire tourner des services complètement différents en parallèle sur une même machine ? C’est ce que propose mklinux en permettant de faire tourner des noyaux Linux en parallèle.

Le responsable de l’entreprise Multikernel Technologies, Cong Wang, a annoncé, la semaine dernière sur la mailing list du noyau Linux, la sortie de son projet mklinux v7.0-mk2 (disponible sur GitHub). Celui-ci permet d’exécuter plusieurs noyaux sur un même ordinateur, sans hyperviseur, donc sans virtualisation. Chacun d’entre eux gère réellement le matériel qu’il utilise.

« L’arborescence est basée sur la version 7.0 [du noyau Linux]. Avec CONFIG_MULTIKERNEL=n, elle se compile et se comporte exactement comme la version 7.0 », précise-t-il.

Chaque noyau s’exécute sur son propre matériel

Le principe est que mklinux (ou multikernel) lance un premier noyau qui gère un certain nombre de processeurs, de la mémoire et des périphériques. Ce premier noyau divise ces ressources « en instances et démarre un noyau dérivé dans chaque instance via la fonction kexec_file_load() », explique Cong Wang.

« Chaque noyau dérivé s’exécute en mode natif sur ses propres processeurs, sa propre mémoire physique et ses propres périphériques. Rien n’est émulé et rien n’est intercepté ; la seule chose partagée est ce que vous choisissez de partager », ajoute le responsable du projet.

Optimisation du traitement et de l’exposition aux risques

L’idée de multikernel est de proposer une véritable isolation au niveau du noyau « avec des performances proches de celles d’un système « bare-metal » et une allocation dynamique des ressources, sans la surcharge d’un hyperviseur », comme l’explique la FAQ du projet. Cela doit permettre une optimisation de la vitesse de traitement et de l’exposition aux risques.

La promesse de cette architecture est que le blocage d’un noyau, une faille de sécurité le touchant ou un kernel panic n’aient aucune conséquence sur les autres systèmes qui tournent en parallèle.

Le concepteur explique dans son message avoir validé par des tests : « Des instances ont été lancées, arrêtées, reconfigurées et relancées dans le cadre de longues boucles de test […] ; un plantage dans un noyau n’affecte pas les autres, et il est confirmé que chaque processeur attribué à une instance est remis en veille sur l’hôte avant d’être réutilisé ».

Et, « en comparant aux machines virtuelles, il n’y a pas de chemin de sortie de la VM, pas de deuxième niveau de tables des pages et pas de modèle de périphérique », ajoute Cong Wang.

Dans son annonce, il donne quelques comparaisons de performances. Ainsi, face à une machine virtuelle KVM, multikernel est de 1,07 fois (fork + sortie) à 2,5 fois plus rapide (changement de contexte), avec une bande passante mémoire et une latence équivalentes :

Pour l’instant, multikernel fonctionne sur architecture x86_64, même si l’annonce sous-entend que le projet ne s’y limitera pas. D’ailleurs, sur son site, l’entreprise vante déjà des solutions pour ARM ou RISC-V.

En pratique, quelles utilisations cible le projet ? Multikernel Technologies propose déjà plusieurs offres de service destinées aux entreprises visant la mise en place de clouds privés sans hyperviseur, le sandboxing d’agents IA et la mise à jour du noyau sans avoir à redémarrer la machine.

Comme toujours avec les versions LTS (Long Term Support) d’Ubuntu, la première mouture « .1 » est attendue. Ubuntu 26.04.1 vient ainsi d’être mise à disposition, simplifiant dans un premier temps les nouvelles installations du système.

Cette version ne comprend aucune nouveauté. Elle est là pour reprendre l’ensemble des correctifs (bugs généraux et sécurité) sortis depuis la publication d’Ubuntu 26.04 en avril dernier. Les images ISO proposées permettent l’installation d’un système à jour, avec moins de téléchargements lors de la première session. Pour les utilisateurs existants d’Ubuntu 26.04, il n’y a rien à faire.

• Ubuntu 26.04 LTS est disponible en version finale, avec cinq ans de mises à jour

Ces versions « .1 » sont cependant importantes pour la mouture LTS précédente. Canonical applique la même stratégie depuis longtemps : une LTS ne peut être mise à jour vers la suivante qu’une fois la version « .1 » de celle-ci disponible, qui débloque alors un chemin de migration. Un choix qui répond à des critères de fiabilité, ces versions permettant de gommer les erreurs de jeunesse. Un comportement déroutant de prime abord, car il s’écoule plusieurs mois entre l’arrivée d’une nouvelle LTS et la disponibilité de son chemin de migration.

Une partie des utilisateurs d’Ubuntu 24.04 attend donc la 26.04.1, mais il faudra être encore un peu patient. Oliver Reiche, développeur chez Canonical, a indiqué que même si la 26.04.1 était effectivement disponible, le chemin de migration avait du retard. Il faudra attendre quelques semaines de plus, la faute à des « régressions dans une version récente de rust-coreutils ».

Quand le chemin de migration sera disponible, le système signalera cette possibilité. Comme le rappelle OMGUbuntu, il est toujours possible de forcer le passage avec la commande « sudo do-release-upgrade -d », mais la procédure n’est pas recommandée pour des questions de fiabilité.

Comme toujours avec les versions LTS (Long Term Support) d’Ubuntu, la première mouture « .1 » est attendue. Ubuntu 26.04.1 vient ainsi d’être mise à disposition, simplifiant dans un premier temps les nouvelles installations du système.

Cette version ne comprend aucune nouveauté. Elle est là pour reprendre l’ensemble des correctifs (bugs généraux et sécurité) sortis depuis la publication d’Ubuntu 26.04 en avril dernier. Les images ISO proposées permettent l’installation d’un système à jour, avec moins de téléchargements lors de la première session. Pour les utilisateurs existants d’Ubuntu 26.04, il n’y a rien à faire.

• Ubuntu 26.04 LTS est disponible en version finale, avec cinq ans de mises à jour

Ces versions « .1 » sont cependant importantes pour la mouture LTS précédente. Canonical applique la même stratégie depuis longtemps : une LTS ne peut être mise à jour vers la suivante qu’une fois la version « .1 » de celle-ci disponible, qui débloque alors un chemin de migration. Un choix qui répond à des critères de fiabilité, ces versions permettant de gommer les erreurs de jeunesse. Un comportement déroutant de prime abord, car il s’écoule plusieurs mois entre l’arrivée d’une nouvelle LTS et la disponibilité de son chemin de migration.

Une partie des utilisateurs d’Ubuntu 24.04 attend donc la 26.04.1, mais il faudra être encore un peu patient. Oliver Reiche, développeur chez Canonical, a indiqué que même si la 26.04.1 était effectivement disponible, le chemin de migration avait du retard. Il faudra attendre quelques semaines de plus, la faute à des « régressions dans une version récente de rust-coreutils ».

Quand le chemin de migration sera disponible, le système signalera cette possibilité. Comme le rappelle OMGUbuntu, il est toujours possible de forcer le passage avec la commande « sudo do-release-upgrade -d », mais la procédure n’est pas recommandée pour des questions de fiabilité.