Source

Asahi Linux prend en charge les Mac M3, M3 Pro et M3 Max. Webcam, Wi-Fi, USB et décodage AV1 fonctionnent, mais pas le GPU et la mise en veille.

Le post Apple : Asahi Linux prend officiellement en charge les Mac M3, mais pas encore le GPU a été publié sur IT-Connect.

Le projet Asahi Linux vient enfin de fusionner le support des Mac M3 dans son installateur. En clair, ça veut dire que si vous avez un MacBook Air, un MacBook Pro ou un iMac équipé d'un M3, d'un M3 Pro ou d'un M3 Max, vous pouvez y installer Linux dès maintenant.

Et la liste de ce qui fonctionne est plus longue que ce que je pouvais craindre. La webcam, les micros internes, le WiFi, le Bluetooth, l'USB 3 jusqu'aux 10 Gb/s permis par la machine, et le décodage vidéo accéléré, AV1 compris.

Le Thunderbolt aussi, est même arrivé cet été. Apple avait troqué, sur les M3 Pro et M3 Max, son vieux contrôleur de ports USB contre une puce ACE3 posée sur un bus SPMI au lieu de l'I2C. Il a donc fallu reverse tout ce petit monde afin que l'USB 3 et le Thunderbolt marchent sur l'ensemble de la gamme M3.

Si vous voulez vous lancer, l'installation doit encore passer par le mode Expert de l'installeur, parce que c'est encore tout frais. Mais quand la bêta de Fedora Linux 45, sera implémentée d'ici quelques semaines, ça devrait fonctionner en install normale.

Après le gros manque, c'est la 3D. N'attendez ni performances, ni accélération 3D économe en énergie puisque tout est géré par la partie CPU du M3. Et ce n'est pas de la mauvaise volonté de la part des dev puisque le GPU du M3 s'écarte nettement de celui des M1 et M2 : ray tracing matériel, mesh shaders, et le Dynamic Caching maison d'Apple. Il y a donc énormément à refaire et même si le chantier a commencé, pour le moment, on n'a pas de date.

Les autres limites ont l'air nettement moins définitives comme pour la mise en veille qui ne fonctionne pas et le port HDMI des MacBook qui est coupé. Cela s'explique par le fait que le composant DCP qui gère ces 2 aspects là c'est pas encore piloté par Asahi, mais ça ne devrait pas tarder.

Le Mac Studio, lui, reste à la rue. Le M3 Ultra n'est pas supporté, et les M4 et M5 en sont au tout début, avec le stockage, le PCIe et le démarrage multicœur qui tournent mais pas grand-chose d'autre. Donc plus votre machine est récente, plus il va falloir être patient...

Perso, j'avais un iMac M3 et franchement, j'ai été très déçu par cette machine. Pour de la bureautique ça allait très bien, mais dès qu'on bidouille un peu fort, ça pédale dans la semoule. Je suis donc passé au Mac Studio depuis et je ne le regrette pas une seconde.

En tout cas, je sais que si je veux recycler ce "vieil" iMac M3, je peux maintenant lui installer Linux... ça vaut peut-être le coup, à condition d'assumer un desktop sans la moindre accélération 3D ^^.

Source : le billet d'annonce d'Asahi Linux et Neowin .

Source

Télécharger un fichier depuis Internet ne garantit pas à lui seul qu’il provient bien de la source attendue ni qu’il n’a pas été modifié. Sous Linux, deux mécanismes complémentaires permettent d’effectuer ces vérifications : les sommes de contrôle pour l’intégrité et les signatures GPG pour l’authenticité.

GPG (GNU Privacy Guard) utilise la cryptographie asymétrique avec une clé privée et une clé publique. Une distribution Linux, un développeur ou un projet peut ainsi signer un fichier, une archive ou un fichier de sommes de contrôle comme SHA256SUMS. L’utilisateur peut ensuite vérifier cette signature avec la clé publique correspondante.

Dans ce guide, vous allez voir comment installer GnuPG sous Linux, importer et vérifier une clé publique, contrôler la signature d’un fichier avec gpg, vérifier une signature .sig ou .asc, valider une image ISO avec SHA256SUMS et comprendre les messages comme “Good signature”.

Nous verrons également comment distinguer intégrité et authenticité, et pourquoi il est important de vérifier l’empreinte de la clé publique avant de lui faire confiance.

Guide connexe : Vérifier la somme de contrôle d’un fichier sous Linux (MD5, SHA1, SHA256)

Qu’est-ce qu’une signature GPG ?

Une signature GPG permet de vérifier qu’un fichier ou un message provient bien de la personne ou de l’organisation qui affirme l’avoir publié, et qu’il n’a pas été modifié depuis sa signature.

GPG (GNU Privacy Guard, ou GnuPG) repose sur la cryptographie asymétrique, avec une paire de clés :

• une clé privée, conservée secrètement par son propriétaire et utilisée pour créer la signature ;
• une clé publique, distribuée aux utilisateurs afin qu’ils puissent vérifier cette signature.

Lorsqu’un développeur ou une distribution Linux signe un fichier, GPG calcule une empreinte du contenu puis crée une signature à l’aide de la clé privée.

L’utilisateur peut ensuite vérifier cette signature avec la clé publique correspondante.

Par exemple :

gpg --verify fichier.iso.sig fichier.iso

Si la vérification réussit, GPG indique que la signature est valide et précise quelle clé a été utilisée.

Une signature GPG apporte donc deux informations importantes :

• l’intégrité : le contenu signé n’a pas été modifié depuis la création de la signature ;
• l’authenticité : la signature a été créée avec la clé privée correspondant à la clé publique utilisée pour la vérification.

Cela va plus loin qu’une simple somme de contrôle SHA256. Un hash permet de vérifier qu’un fichier correspond à une empreinte donnée, mais si un attaquant parvient à remplacer à la fois le fichier et le hash publié, cette comparaison ne suffit plus.

Avec une signature GPG, l’attaquant devrait également disposer de la clé privée du signataire pour produire une nouvelle signature valide.

Il reste toutefois une étape essentielle : s’assurer que la clé publique utilisée pour la vérification appartient réellement à l’éditeur. Pour cela, il faut notamment vérifier son empreinte (fingerprint) à partir d’une source officielle.

Les signatures GPG sont ainsi couramment utilisées pour vérifier des images ISO Linux, des archives, des paquets logiciels ou des fichiers de sommes de contrôle comme SHA256SUMS.

Installer GnuPG sous Linux

GnuPG est disponible dans les dépôts de la plupart des distributions Linux. Le paquet s’appelle généralement gnupg ou gnupg2.

Sous Debian, Ubuntu et leurs dérivées :

sudo apt update
sudo apt install gnupg

Sous Fedora :

sudo dnf install gnupg2

Sous Arch Linux et dérivées :

sudo pacman -S gnupg

Une fois l’installation terminée, vérifiez que GPG fonctionne avec :

gpg --version

La commande affiche la version installée ainsi que les principaux algorithmes pris en charge.

Vous pouvez ensuite afficher le contenu du trousseau de clés avec :

gpg --list-keys

Si aucune clé n’a encore été importée, la liste peut être vide.

Pour la vérification de signatures, il n’est pas nécessaire de créer votre propre paire de clés. Il suffit généralement d’importer la clé publique de l’éditeur ou de la distribution dont vous souhaitez vérifier les fichiers.

La prochaine étape consiste donc à récupérer puis importer cette clé publique dans GnuPG.

Importer une clé publique GPG

Pour vérifier une signature GPG, vous devez disposer de la clé publique du signataire. Cette clé permet à GnuPG de vérifier qu’une signature a bien été créée avec la clé privée correspondante.

Il existe principalement trois façons de récupérer cette clé publique.

Télécharger directement le fichier de clé publique

De nombreux projets publient leur clé sous la forme d’un fichier .asc, .gpg ou similaire.

Par exemple :

gpg --import cle-publique.asc

C’est souvent la méthode la plus simple lorsque le site officiel fournit directement la clé.

Après l’import, vérifiez sa présence avec :

gpg --list-keys

Récupérer la clé depuis un serveur de clés

Voici les étapes pour récupérer la clé publique avec cette méthode :

Si vous connaissez l’identifiant de la clé, vous pouvez la télécharger depuis un serveur de clés :

gpg --keyserver hkp://keyserver.ubuntu.com --recv-keys ID_DE_LA_CLE

Le serveur de clés à utiliser dépend du projet. Il vaut mieux utiliser celui indiqué par la documentation officielle plutôt qu’un serveur choisi au hasard.

Dans le cas d’Ubuntu, par exemple, le serveur keyserver.ubuntu.com peut être utilisé.

Si vous ne connaissez pas encore l’identifiant de la clé, tentez d’abord de vérifier la signature :

gpg --keyid-format long --verify SHA256SUMS.gpg SHA256SUMS

GPG peut alors afficher :

gpg: Signature faite le jeu. 27 août 2026 22:43:09 UTC
gpg:  avec la clef RSA 843938DF228D22F7B3742BC0D94AA3F0EFE21092
gpg: Impossible de vérifier la signature : Pas de clef publique

La ligne using RSA key indique l’identifiant de la clé manquante. Vous pouvez ensuite la récupérer :

gpg --keyserver hkp://keyserver.ubuntu.com \
    --recv-keys 843938DF228D22F7B3742BC0D94AA3F0EFE21092

Une fois la clé importée, vérifiez son empreinte :

gpg --fingerprint 843938DF228D22F7B3742BC0D94AA3F0EFE21092

Suivre la méthode indiquée par le projet

Certains projets ne passent pas par un serveur de clés et fournissent leurs propres instructions : téléchargement direct d’une clé, paquet contenant le trousseau de clés, dépôt officiel, ou autre mécanisme.

Dans ce cas, suivez de préférence la méthode publiée par l’éditeur ou la distribution. C’est la meilleure façon d’éviter d’importer une clé non officielle ou périmée.

Quelle que soit la méthode utilisée, ne faites pas confiance à la clé uniquement parce qu’elle a été importée avec succès. Vérifiez ensuite son empreinte numérique avec :

gpg --fingerprint ID_DE_LA_CLE

Puis comparez-la avec celle publiée sur une source officielle.

Vérifier l’empreinte d’une clé publique

Avant d’utiliser une clé publique GPG pour vérifier une signature, il est important de contrôler son empreinte numérique, appelée fingerprint.

Cette empreinte est un identifiant unique associé à la clé. Elle permet de vérifier que la clé importée est bien celle publiée par l’éditeur, la distribution Linux ou le développeur concerné.

Pour afficher l’empreinte d’une clé :

gpg --fingerprint <ID_DE_LA_CLE>

Vous pouvez aussi afficher les empreintes de toutes les clés présentes dans votre trousseau :

gpg --fingerprint

GPG affiche alors une longue suite de caractères hexadécimaux, par exemple :

0123 4567 89AB CDEF 0123  4567 89AB CDEF 0123 4567

Comparez cette valeur avec l’empreinte publiée sur une source officielle : site du projet, documentation de la distribution, page de téléchargement ou autre canal de confiance.

Les deux empreintes doivent correspondre exactement.

Cette vérification est importante, car télécharger une clé depuis un serveur de clés ne suffit pas à prouver qu’elle appartient réellement à la personne ou au projet attendu. Un serveur de clés permet surtout de distribuer les clés, pas d’en garantir l’identité.

Une fois l’empreinte vérifiée, vous pouvez utiliser cette clé publique pour contrôler les signatures GPG des fichiers téléchargés.

Par exemple, pour afficher également l’identifiant court et l’empreinte dans un format plus lisible pour les scripts :

gpg --with-colons --fingerprint <ID_DE_LA_CLE>

Si l’empreinte ne correspond pas à celle publiée officiellement, n’utilisez pas la clé et récupérez-la à nouveau depuis une source fiable.

Vérifier la signature GPG d’un fichier

Une fois la clé publique du signataire importée et son empreinte vérifiée, vous pouvez utiliser GnuPG pour contrôler la signature d’un fichier.

Le cas le plus courant est celui d’une signature détachée, fournie dans un fichier séparé comme .sig, .asc ou .gpg.

Par exemple, si vous disposez de :

fichier.iso
fichier.iso.sig

utilisez :

gpg --verify fichier.iso.sig fichier.iso

GPG vérifie alors que la signature correspond bien au contenu du fichier et qu’elle a été créée avec la clé privée associée à la clé publique présente dans votre trousseau.

Si la vérification réussit, vous obtenez un message du type :

gpg: Good signature from "Nom du signataire"

Cela signifie que le fichier n’a pas été modifié depuis sa signature.

Attention toutefois : un message Good signature confirme que la signature est techniquement valide, mais il faut encore s’assurer que la clé utilisée appartient bien à la personne ou au projet attendu. C’est pourquoi la vérification préalable de l’empreinte de la clé publique reste indispensable.

Si le fichier a été modifié ou si la signature ne correspond pas, GPG affiche au contraire un message comme :

gpg: BAD signature from "Nom du signataire"

Dans ce cas, n’utilisez pas le fichier avant d’avoir vérifié son origine ou effectué un nouveau téléchargement.

Vérifier une signature détachée .sig ou .asc

Lorsque la signature est intégrée directement dans un fichier signé, GPG peut parfois déterminer automatiquement le contenu à vérifier, mais pour les téléchargements logiciels et images ISO, la signature détachée reste le cas le plus fréquent.

Une signature détachée est stockée dans un fichier séparé du fichier d’origine. Elle porte souvent l’extension .sig, .asc ou parfois .gpg.

Par exemple :

logiciel.tar.xz
logiciel.tar.xz.asc

ou :

image.iso
image.iso.sig

Pour vérifier une signature détachée, utilisez :

gpg --verify fichier.sig fichier

Par exemple :

gpg --verify logiciel.tar.xz.asc logiciel.tar.xz

ou :

gpg --verify image.iso.sig image.iso

GPG contrôle alors deux éléments :

• que la signature correspond bien au fichier ;
• que cette signature a été créée avec une clé privée correspondant à une clé publique présente dans votre trousseau.

Si la signature est valide, GPG affiche un message comme :

gpg: Good signature from "Nom du signataire"

Si le fichier a été modifié ou si la signature ne correspond pas :

gpg: BAD signature from "Nom du signataire"

L’extension .asc indique généralement une signature encodée en ASCII, tandis qu’un fichier .sig peut contenir une signature binaire. Dans les deux cas, la commande gpg --verify fonctionne de la même manière.

Il est également fréquent que la signature porte simplement le même nom que le fichier d’origine avec une extension supplémentaire. Cela facilite l’identification du fichier à vérifier.

Enfin, même avec une Good signature, vérifiez toujours que l’empreinte de la clé publique correspond bien à celle publiée par l’éditeur. Une signature valide n’est utile que si vous faites confiance à la bonne clé.

Vérifier une image ISO Linux avec SHA256SUMS et GPG

Certaines distributions Linux publient plusieurs fichiers permettant de vérifier leurs images ISO :

• l’image ISO elle-même ;
• un fichier de sommes de contrôle, par exemple SHA256SUMS ;
• une signature GPG de ce fichier, par exemple SHA256SUMS.gpg ou SHA256SUMS.sign.

La vérification se fait alors en deux étapes.

Commencez par vérifier la signature du fichier SHA256SUMS :

gpg --verify SHA256SUMS.gpg SHA256SUMS

Si la signature est valide, GPG indique qu’elle a été créée avec une clé connue de votre trousseau.

Vous pouvez ensuite vérifier l’image ISO avec :

sha256sum -c SHA256SUMS

Si l’empreinte correspond :

ubuntu.iso: OK

Cette procédure apporte deux niveaux de vérification :

• GPG permet de vérifier que le fichier SHA256SUMS a bien été signé avec la clé privée correspondant à la clé publique importée ;
• SHA256 permet de vérifier que l’image ISO correspond exactement à l’empreinte contenue dans SHA256SUMS.

Il faut toutefois avoir vérifié au préalable que l’empreinte de la clé publique GPG correspond bien à celle publiée par la distribution Linux.

Le flux complet est donc :

Cette méthode est plus robuste qu’une simple comparaison du hash affiché sur une page web, car elle ajoute une vérification cryptographique de l’origine du fichier contenant les sommes de contrôle.

La procédure exacte peut varier selon la distribution. Certaines utilisent SHA256SUMS.gpg, d’autres .sig, .sign ou .asc, mais le principe reste le même.

Vérifier manuellement la signature d’un dépôt APT avec GPG

APT vérifie normalement automatiquement les dépôts configurés avec apt update, en contrôlant la signature du fichier Release ou InRelease. Il est néanmoins possible de reproduire cette vérification manuellement avec GPG, ce qui peut être utile pour comprendre la chaîne de confiance d’un dépôt.

Commencez par récupérer les métadonnées du dépôt, par exemple :

wget https://exemple.org/dists/stable/Release
wget https://exemple.org/dists/stable/Release.gpg

Vous devez ensuite disposer de la clé publique utilisée pour signer le dépôt. Importez-la dans votre trousseau GPG, par exemple :

gpg --import depot-public-key.asc

Vérifiez ensuite son empreinte :

gpg --fingerprint ID_DE_LA_CLE

Comparez cette empreinte avec celle publiée sur le site officiel du dépôt.

Une fois la clé validée, vérifiez la signature du fichier Release :

gpg --verify Release.gpg Release

Si tout est correct, GPG affiche notamment :

gpg: Good signature from "Nom du dépôt"

Certains dépôts utilisent plutôt un fichier InRelease, qui contient directement les métadonnées et leur signature OpenPGP. Dans ce cas :

gpg --verify InRelease

APT effectue normalement cette vérification automatiquement. Pour les dépôts tiers modernes, il est recommandé d’associer explicitement leur clé avec Signed-By et de placer les clés gérées localement dans /etc/apt/keyrings/, plutôt que d’utiliser apt-key, désormais déprécié.

Par exemple :

deb [signed-by=/etc/apt/keyrings/exemple.gpg] https://exemple.org/debian stable main

Ainsi, APT n’accepte ce dépôt que si ses métadonnées sont signées avec une clé présente dans le trousseau indiqué.

Que signifient « Good signature » et les avertissements GPG ?

Lors d’une vérification avec gpg --verify, GnuPG affiche plusieurs messages qui permettent de savoir si la signature est valide et si la clé utilisée est considérée comme fiable.

Le message le plus important est :

gpg: Good signature from "Nom du signataire"

Cela signifie que la signature correspond bien au fichier vérifié et qu’elle a été créée avec la clé privée associée à la clé publique présente dans votre trousseau.

En revanche, cela ne signifie pas automatiquement que vous pouvez faire confiance à cette clé.

GPG peut par exemple afficher :

gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.

Ce message signifie que la signature est techniquement correcte, mais que GPG ne peut pas garantir que la clé publique appartient réellement à la personne ou au projet indiqué.

C’est pourquoi il faut vérifier l’empreinte de la clé publique auprès d’une source officielle.

À l’inverse, si GPG affiche :

gpg: BAD signature from "Nom du signataire"

la signature ne correspond pas au fichier. Celui-ci a pu être modifié, corrompu ou ne pas correspondre à la signature téléchargée.

Vous pouvez aussi rencontrer un message du type :

gpg: Can't check signature: No public key

Dans ce cas, la signature est présente, mais la clé publique nécessaire à sa vérification n’a pas encore été importée.

Enfin, GPG affiche généralement l’identifiant ou l’empreinte de la clé utilisée. Vérifiez cette valeur avec :

gpg --fingerprint ID_DE_LA_CLE

En résumé :

Une Good signature est donc nécessaire, mais elle doit être associée à une clé publique dont l’empreinte a été vérifiée auprès d’une source de confiance.

Supprimer ou gérer les clés du trousseau GPG

Au fil du temps, votre trousseau GPG peut contenir plusieurs clés publiques importées pour vérifier des signatures. Vous pouvez les afficher, exporter ou supprimer selon vos besoins.

Pour lister les clés publiques présentes dans le trousseau :

gpg --list-keys

Pour afficher également leur empreinte :

gpg --fingerprint

Si vous souhaitez obtenir plus de détails sur une clé précise :

gpg --list-keys ID_DE_LA_CLE

Pour supprimer une clé publique devenue inutile :

gpg --delete-key ID_DE_LA_CLE

GPG vous demande une confirmation avant de retirer la clé du trousseau.

Si vous gérez aussi vos propres clés privées, leur suppression doit être effectuée séparément :

gpg --delete-secret-key ID_DE_LA_CLE

Attention : supprimer une clé privée peut vous empêcher de déchiffrer d’anciens fichiers ou de créer de nouvelles signatures avec cette identité. Sauvegardez-la avant toute suppression si elle vous appartient encore.

Vous pouvez également exporter une clé publique afin de la sauvegarder ou de la transférer vers une autre machine :

gpg --export --armor ID_DE_LA_CLE > cle-publique.asc

Pour une clé privée :

gpg --export-secret-keys --armor ID_DE_LA_CLE > cle-privee.asc

Conservez évidemment les exports de clés privées dans un emplacement sécurisé.

Enfin, si vous avez importé plusieurs clés portant des noms similaires, utilisez toujours leur empreinte complète pour les identifier sans ambiguïté avant de les supprimer ou de les exporter.

Intégrité et authenticité : quelle différence ?

Lorsqu’on vérifie un fichier téléchargé, il faut distinguer deux notions : l’intégrité et l’authenticité.

L’intégrité consiste à vérifier que le fichier n’a pas été modifié ou corrompu. Pour cela, on utilise généralement une somme de contrôle comme SHA256.

Par exemple :

sha256sum -c SHA256SUMS

Si le résultat affiche :

ubuntu.iso: OK

cela signifie que le fichier correspond bien à l’empreinte enregistrée dans SHA256SUMS.

Mais cette vérification ne prouve pas que le fichier SHA256SUMS lui-même provient bien de l’éditeur officiel.

C’est là qu’intervient l’authenticité.

Une signature GPG permet de vérifier que le fichier de sommes de contrôle, ou le fichier lui-même, a été signé avec la clé privée correspondant à une clé publique connue.

Par exemple :

gpg --verify SHA256SUMS.gpg SHA256SUMS

Si la signature est valide et que vous avez vérifié l’empreinte de la clé publique auprès d’une source officielle, vous pouvez alors avoir davantage confiance dans l’origine du fichier.

On peut résumer ainsi :

Pour une image ISO Linux, la méthode la plus complète consiste donc à :

• vérifier l’empreinte de la clé publique GPG ;
• vérifier la signature GPG du fichier SHA256SUMS ;
• vérifier ensuite l’image ISO avec sha256sum -c.

Ainsi, SHA256 vérifie le contenu, tandis que GPG permet de vérifier l’origine de la référence utilisée pour ce contrôle.

Ressources utiles et articles liés

• Qu’est-ce qu’une somme de contrôle (checksum) et à quoi cela sert ?
• Vérifier la somme de contrôle d’un fichier sous Windows 11/10 (MD5, SHA1, SHA256)
• Vérifier la somme de contrôle d’un fichier sous Linux (MD5, SHA1, SHA256)
• 10 meilleurs logiciels pour calculer le hash d’un fichier sous Windows
• hashcat : cracker des hashs, empreintes MD5, SHA1, SHA256
• Certificats électroniques et signatures numériques : fonctionnement et sécurité
• Signature numérique des fichiers sur Windows et sécurité
• Le chiffrement (cryptage) des données : comment ça marche et pourquoi l’utiliser
• Résoudre CMOS checksum error au démarrage du PC

L’article Vérifier la signature GPG d’un fichier sous Linux : gpg, clés publiques et empreintes est apparu en premier sur malekal.com.

Trois actualités à retenir cette semaine dans le cyberespace : une cyberattaque qui prive de télésurveillance les nouveaux pacemakers d'un géant de la santé, l'infrastructure de Linux à bout de souffle face aux scrapers IA, et des sessions Claude piratées qui alimentent un marché parallèle.

Trois actualités à retenir cette semaine dans le cyberespace : une cyberattaque qui prive de télésurveillance les nouveaux pacemakers d'un géant de la santé, l'infrastructure de Linux à bout de souffle face aux scrapers IA, et des sessions Claude piratées qui alimentent un marché parallèle.

Source

Source

Linux, une série de correctifs apporte un premier support USB 4 et Thunderbolt aux puces M1, M2 et M3 d'Apple.

Cet article Linux et les processeurs Apple, l’USB4 et le Thunderbolt arrivent sur les puces M1, M2 et M3 a été publié en premier par GinjFo.

Source

De nouveaux correctifs Linux détaillent la gestion CPPC des futurs Ryzen Zen 6. AMD utilise trois valeurs de fréquence de référence, 5025, 3524 et 2399 MHz.

Cet article Zen 6 : Linux révèle l’écart de performances entre les trois types de cœurs d’AMD a été publié en premier par GinjFo.

Une série de 19 patchs apporte l'USB4 et le Thunderbolt aux Mac M1, M2 et M3 sous Linux. Mais les écrans externes et les boîtiers PCIe devront encore patienter.

Le post Le Thunderbolt arrive sur les Mac sous Linux, mais pas pour tous les modèles a été publié sur IT-Connect.

Source

De nouveaux correctifs Linux apportent des réglages EPP spécifiques aux futurs Ryzen Zen 6. Ils confirment l'exploitation de trois types de cœurs.

Cet article Zen 6 : AMD confirme trois types de cœurs a été publié en premier par GinjFo.

Les développeurs Debian ont voté : l'IA générative n'est ni interdite ni recommandée, mais celui qui soumet une contribution en assume toute la responsabilité.

Le post Debian autorise officiellement l’IA générative, mais le contributeur reste responsable a été publié sur IT-Connect.

Source

Source

Git.kernel.org, la plateforme qui héberge le code source de Linux, est sous pression. En cause : les scrapers qui aspirent en masse le contenu des sites pour nourrir des IA. Le problème n'est pas tant leur présence que leur façon d'avaler ce contenu.