dans ma nouvelle installation de mint19 dans le gestionnaire de pilote
on ne me propose pas une mise a jour du firmware microcode du processeur
intel ,j'ai crains que dans la version 18 de mint ça me fasse le bordel
et je ne l'ai jamais installée ,mais dans la version 19 ce serait fait ?
Que veux-tu dire exactement par "déploiement par défaut" ?
Plus exactement que les distributions font maintenant état par défaut d'une fonctionnalité qui était plutôt planquée au fin fond des docs et utilisée en dernier recours pour résoudre des problèmes bien particuliers liés au CPU.
Je comprends de moins en moins où tu veux en venir. Pour moi "faire état" signifie "mentionner", alors que "déployer" signifie "installer". Du coup, faire état /par défaut/ est un concept qui m'échappe.
Cette fonctionnalité est présente dans Debian depuis plusieurs années.
Il faut quand même activer non-free et contrib, qui ne le sont pas par défaut.
Normal, les microcodes ne sont pas libres.
Le 31/12/2018 à 10:59, Eric Masson a écrit :
Pascal Hambourg <pascal@plouf.fr.eu.org> writes:
Que veux-tu dire exactement par "déploiement par défaut" ?
Plus exactement que les distributions font maintenant état par défaut
d'une fonctionnalité qui était plutôt planquée au fin fond des docs et
utilisée en dernier recours pour résoudre des problèmes bien
particuliers liés au CPU.
Je comprends de moins en moins où tu veux en venir.
Pour moi "faire état" signifie "mentionner", alors que "déployer"
signifie "installer". Du coup, faire état /par défaut/ est un concept
qui m'échappe.
Cette fonctionnalité est présente dans Debian depuis plusieurs années.
Il faut quand même activer non-free et contrib, qui ne le sont pas par
défaut.
Que veux-tu dire exactement par "déploiement par défaut" ?
Plus exactement que les distributions font maintenant état par défaut d'une fonctionnalité qui était plutôt planquée au fin fond des docs et utilisée en dernier recours pour résoudre des problèmes bien particuliers liés au CPU.
Je comprends de moins en moins où tu veux en venir. Pour moi "faire état" signifie "mentionner", alors que "déployer" signifie "installer". Du coup, faire état /par défaut/ est un concept qui m'échappe.
Cette fonctionnalité est présente dans Debian depuis plusieurs années.
Il faut quand même activer non-free et contrib, qui ne le sont pas par défaut.
Normal, les microcodes ne sont pas libres.
jp willm
Le 31/12/2018 à 15:00, Pascal Hambourg a écrit :
- les mainteneurs de la distribution fournissent un outil pour l'intégration automatique des microcodes dans l'image du noyau
Tu veux dire dans l'initrd/initramfs ?
Oui en fait :)
Pour intégrer les microcodes dans l'image du noyau, il faut précisément reconstruire cette dernière.
CQFD.
* Il va falloir que je leur pose la question.
Oui. Le seul avantage que j'y vois est que cela ne nécessite pas de prise en charge des microcodes par le générateur d'initrd.
Oui, dans ce cas on mélange free et non free, et là, on est en "politique éthique".
Mais en contrepartie cela nécessite une prise en charge par le chargeur d'amorçage, ce qui est pire à mon avis.
Je ne connais pas les raisons techniques qui te font dire cela, mais je trouve que le chargeur d'amorçage est plutôt mieux indiqué pour lancer en premier un microcode.img non-free plutôt que de l'intégrer dans un initramfs.img qui il me semble est issu du logiciel libre ou du moins open-source.
S'il y avait consensus entre les distributions sur quoi que ce soit, ça se saurait. C'est pour ça que les distributions existent, pour que chacun soit libre de faire ses propres choix.
Bien vu :-) -- jp willm http://perso.orange.fr/willms/index.html
Le 31/12/2018 à 15:00, Pascal Hambourg a écrit :
- les mainteneurs de la distribution fournissent un outil pour
l'intégration automatique des microcodes dans l'image du noyau
Tu veux dire dans l'initrd/initramfs ?
Oui en fait :)
Pour intégrer les microcodes dans
l'image du noyau, il faut précisément reconstruire cette dernière.
CQFD.
* Il va falloir que je leur pose la question.
Oui. Le seul avantage que j'y vois est que cela ne nécessite pas de
prise en charge des microcodes par le générateur d'initrd.
Oui, dans ce cas on mélange free et non free, et là, on est en
"politique éthique".
Mais en
contrepartie cela nécessite une prise en charge par le chargeur
d'amorçage, ce qui est pire à mon avis.
Je ne connais pas les raisons techniques qui te font dire cela, mais je
trouve que le chargeur d'amorçage est plutôt mieux indiqué pour lancer
en premier un microcode.img non-free plutôt que de l'intégrer dans un
initramfs.img qui il me semble est issu du logiciel libre ou du moins
open-source.
S'il y avait consensus entre les distributions sur quoi que ce soit, ça
se saurait. C'est pour ça que les distributions existent, pour que
chacun soit libre de faire ses propres choix.
- les mainteneurs de la distribution fournissent un outil pour l'intégration automatique des microcodes dans l'image du noyau
Tu veux dire dans l'initrd/initramfs ?
Oui en fait :)
Pour intégrer les microcodes dans l'image du noyau, il faut précisément reconstruire cette dernière.
CQFD.
* Il va falloir que je leur pose la question.
Oui. Le seul avantage que j'y vois est que cela ne nécessite pas de prise en charge des microcodes par le générateur d'initrd.
Oui, dans ce cas on mélange free et non free, et là, on est en "politique éthique".
Mais en contrepartie cela nécessite une prise en charge par le chargeur d'amorçage, ce qui est pire à mon avis.
Je ne connais pas les raisons techniques qui te font dire cela, mais je trouve que le chargeur d'amorçage est plutôt mieux indiqué pour lancer en premier un microcode.img non-free plutôt que de l'intégrer dans un initramfs.img qui il me semble est issu du logiciel libre ou du moins open-source.
S'il y avait consensus entre les distributions sur quoi que ce soit, ça se saurait. C'est pour ça que les distributions existent, pour que chacun soit libre de faire ses propres choix.
Bien vu :-) -- jp willm http://perso.orange.fr/willms/index.html
Eric Masson
Pascal Hambourg writes: 'Re,
Pour moi "faire état" signifie "mentionner", alors que "déployer" signifie "installer".
Vi Ok.
Du coup, faire état /par défaut/ est un concept qui m'échappe.
Une forme de publicité est maintenant faite autour de ce mécanisme (déjà implémenté depuis fort longtemps) du fait de Spectre/Meltdown, ce qui avant cela n'était clairement pas le cas.
Normal, les microcodes ne sont pas libres.
Certes, il serait peut-être bon de créer un dépôt spécifique pour les microcodes CPU dont l'activation serait proposée à l'installation, ainsi que la création d'un initrd les chargeant en fonction du CPU, les conséquences potentielles étant tout de même un peu plus graves que de ne pas disposer d'un firmware pour une carte wifi. Rien n'empêche de mettre un gros warning "Attention microcode propriétaire, caca, pas beau, utilisez une vraie architecture libre à la place, mais si vous ne pouvez vraiment pas faire autrement, activez cette fonctionnalité". -- V> il faut revenir à l'éthymologie, Ah ça. Boire ou écrire, il faut choisir. -+- MW in <http://www.le-gnu.net> : Eau de vie de plume -+-
Pascal Hambourg <pascal@plouf.fr.eu.org> writes:
'Re,
Pour moi "faire état" signifie "mentionner", alors que "déployer"
signifie "installer".
Vi Ok.
Du coup, faire état /par défaut/ est un concept qui m'échappe.
Une forme de publicité est maintenant faite autour de ce mécanisme (déjà
implémenté depuis fort longtemps) du fait de Spectre/Meltdown, ce qui
avant cela n'était clairement pas le cas.
Normal, les microcodes ne sont pas libres.
Certes, il serait peut-être bon de créer un dépôt spécifique pour les
microcodes CPU dont l'activation serait proposée à l'installation, ainsi
que la création d'un initrd les chargeant en fonction du CPU, les
conséquences potentielles étant tout de même un peu plus graves que de
ne pas disposer d'un firmware pour une carte wifi.
Rien n'empêche de mettre un gros warning "Attention microcode
propriétaire, caca, pas beau, utilisez une vraie architecture libre à la
place, mais si vous ne pouvez vraiment pas faire autrement, activez
cette fonctionnalité".
--
V> il faut revenir à l'éthymologie,
Ah ça. Boire ou écrire, il faut choisir.
-+- MW in <http://www.le-gnu.net> : Eau de vie de plume -+-
Pour moi "faire état" signifie "mentionner", alors que "déployer" signifie "installer".
Vi Ok.
Du coup, faire état /par défaut/ est un concept qui m'échappe.
Une forme de publicité est maintenant faite autour de ce mécanisme (déjà implémenté depuis fort longtemps) du fait de Spectre/Meltdown, ce qui avant cela n'était clairement pas le cas.
Normal, les microcodes ne sont pas libres.
Certes, il serait peut-être bon de créer un dépôt spécifique pour les microcodes CPU dont l'activation serait proposée à l'installation, ainsi que la création d'un initrd les chargeant en fonction du CPU, les conséquences potentielles étant tout de même un peu plus graves que de ne pas disposer d'un firmware pour une carte wifi. Rien n'empêche de mettre un gros warning "Attention microcode propriétaire, caca, pas beau, utilisez une vraie architecture libre à la place, mais si vous ne pouvez vraiment pas faire autrement, activez cette fonctionnalité". -- V> il faut revenir à l'éthymologie, Ah ça. Boire ou écrire, il faut choisir. -+- MW in <http://www.le-gnu.net> : Eau de vie de plume -+-
Pascal Hambourg
Le 31/12/2018 à 15:40, jp willm a écrit :
Je ne connais pas les raisons techniques qui te font dire cela, mais je trouve que le chargeur d'amorçage est plutôt mieux indiqué pour lancer en premier un microcode.img non-free plutôt que de l'intégrer dans un initramfs.img qui il me semble est issu du logiciel libre ou du moins open-source.
Je ne vois pas le rapport entre l'initramfs et le logiciel libre. C'est juste une archive au format cpio créée par le système et qui contient des fichiers présents sur le système. Il inclut déjà les firmwares non libres pouvant être nécessaires au montage de la racine, donc un peu plus ou un peu moins... Au moins le générateur d'initramfs a l'avantage d'être fourni par la distribution du système qui l'exécute, alors que ce n'est pas forcément vrai pour le chargeur d'amorçage dans le cas d'un multiboot.
Le 31/12/2018 à 15:40, jp willm a écrit :
Je ne connais pas les raisons techniques qui te font dire cela, mais je
trouve que le chargeur d'amorçage est plutôt mieux indiqué pour lancer
en premier un microcode.img non-free plutôt que de l'intégrer dans un
initramfs.img qui il me semble est issu du logiciel libre ou du moins
open-source.
Je ne vois pas le rapport entre l'initramfs et le logiciel libre. C'est
juste une archive au format cpio créée par le système et qui contient
des fichiers présents sur le système. Il inclut déjà les firmwares non
libres pouvant être nécessaires au montage de la racine, donc un peu
plus ou un peu moins...
Au moins le générateur d'initramfs a l'avantage d'être fourni par la
distribution du système qui l'exécute, alors que ce n'est pas forcément
vrai pour le chargeur d'amorçage dans le cas d'un multiboot.
Je ne connais pas les raisons techniques qui te font dire cela, mais je trouve que le chargeur d'amorçage est plutôt mieux indiqué pour lancer en premier un microcode.img non-free plutôt que de l'intégrer dans un initramfs.img qui il me semble est issu du logiciel libre ou du moins open-source.
Je ne vois pas le rapport entre l'initramfs et le logiciel libre. C'est juste une archive au format cpio créée par le système et qui contient des fichiers présents sur le système. Il inclut déjà les firmwares non libres pouvant être nécessaires au montage de la racine, donc un peu plus ou un peu moins... Au moins le générateur d'initramfs a l'avantage d'être fourni par la distribution du système qui l'exécute, alors que ce n'est pas forcément vrai pour le chargeur d'amorçage dans le cas d'un multiboot.
Pascal Hambourg
Le 31/12/2018 à 17:12, Eric Masson a écrit :
Une forme de publicité est maintenant faite autour de ce mécanisme (déjà implémenté depuis fort longtemps) du fait de Spectre/Meltdown
Par les distributions ? Je n'ai pas fait attention. [Debian]
Normal, les microcodes ne sont pas libres.
Certes, il serait peut-être bon de créer un dépôt spécifique pour les microcodes CPU dont l'activation serait proposée à l'installation,
Pas besoin d'un dépôt spécifique. L'utilisation de non-free est déjà proposée à l'installation. Yaka proposer d'installer les microcodes.
ainsi que la création d'un initrd les chargeant en fonction du CPU
C'est déjà géré automatiquement si les paquets contenant les microcodes sont installés.
Le 31/12/2018 à 17:12, Eric Masson a écrit :
Une forme de publicité est maintenant faite autour de ce mécanisme (déjà
implémenté depuis fort longtemps) du fait de Spectre/Meltdown
Par les distributions ? Je n'ai pas fait attention.
[Debian]
Normal, les microcodes ne sont pas libres.
Certes, il serait peut-être bon de créer un dépôt spécifique pour les
microcodes CPU dont l'activation serait proposée à l'installation,
Pas besoin d'un dépôt spécifique. L'utilisation de non-free est déjà
proposée à l'installation. Yaka proposer d'installer les microcodes.
ainsi que la création d'un initrd les chargeant en fonction du CPU
C'est déjà géré automatiquement si les paquets contenant les microcodes
sont installés.
Une forme de publicité est maintenant faite autour de ce mécanisme (déjà implémenté depuis fort longtemps) du fait de Spectre/Meltdown
Par les distributions ? Je n'ai pas fait attention. [Debian]
Normal, les microcodes ne sont pas libres.
Certes, il serait peut-être bon de créer un dépôt spécifique pour les microcodes CPU dont l'activation serait proposée à l'installation,
Pas besoin d'un dépôt spécifique. L'utilisation de non-free est déjà proposée à l'installation. Yaka proposer d'installer les microcodes.
ainsi que la création d'un initrd les chargeant en fonction du CPU
C'est déjà géré automatiquement si les paquets contenant les microcodes sont installés.
Eric Masson
Pascal Hambourg writes: 'Lut,
Par les distributions ? Je n'ai pas fait attention.
Ça a dû me sauter au visage à un moment ou l'autre, je n'en ferais pas mention autrement.
Pas besoin d'un dépôt spécifique. L'utilisation de non-free est déjà proposée à l'installation. Yaka proposer d'installer les microcodes.
Ce serait bien que ce soit une des options "conseillées", même si elle doit être accompagnée de tous les warnings considérés comme nécessaires en fonction des orientations politiques de la distribution. -- Tous cela, il faut que ça change. Je PAYE mon abonnement Internet et j'exige que mon vote et mes opinions soient pris en considération. -+- Rocou In GNU - Les payeurs ne sont pas les conseilleurs -+-
Pascal Hambourg <pascal@plouf.fr.eu.org> writes:
'Lut,
Par les distributions ? Je n'ai pas fait attention.
Ça a dû me sauter au visage à un moment ou l'autre, je n'en ferais pas
mention autrement.
Pas besoin d'un dépôt spécifique. L'utilisation de non-free est déjà
proposée à l'installation. Yaka proposer d'installer les microcodes.
Ce serait bien que ce soit une des options "conseillées", même si
elle doit être accompagnée de tous les warnings considérés comme
nécessaires en fonction des orientations politiques de la distribution.
--
Tous cela, il faut que ça change. Je PAYE mon abonnement Internet et
j'exige que mon vote et mes opinions soient pris en considération.
-+- Rocou In GNU - Les payeurs ne sont pas les conseilleurs -+-
Par les distributions ? Je n'ai pas fait attention.
Ça a dû me sauter au visage à un moment ou l'autre, je n'en ferais pas mention autrement.
Pas besoin d'un dépôt spécifique. L'utilisation de non-free est déjà proposée à l'installation. Yaka proposer d'installer les microcodes.
Ce serait bien que ce soit une des options "conseillées", même si elle doit être accompagnée de tous les warnings considérés comme nécessaires en fonction des orientations politiques de la distribution. -- Tous cela, il faut que ça change. Je PAYE mon abonnement Internet et j'exige que mon vote et mes opinions soient pris en considération. -+- Rocou In GNU - Les payeurs ne sont pas les conseilleurs -+-
jp willm
Le 31/12/2018 à 23:27, Pascal Hambourg a écrit :
Je ne vois pas le rapport entre l'initramfs et le logiciel libre. C'est juste une archive au format cpio créée par le système et qui contient des fichiers présents sur le système. Il inclut déjà les firmwares non libres pouvant être nécessaires au montage de la racine, donc un peu plus ou un peu moins...
Tu as raison et j'y ai pensé après avoir écrit.
Au moins le générateur d'initramfs a l'avantage d'être fourni par la distribution du système qui l'exécute, alors que ce n'est pas forcément vrai pour le chargeur d'amorçage dans le cas d'un multiboot.
Je ne vois pas le rapport entre l'initramfs et le logiciel libre. C'est
juste une archive au format cpio créée par le système et qui contient
des fichiers présents sur le système. Il inclut déjà les firmwares non
libres pouvant être nécessaires au montage de la racine, donc un peu
plus ou un peu moins...
Tu as raison et j'y ai pensé après avoir écrit.
Au moins le générateur d'initramfs a l'avantage d'être fourni par la
distribution du système qui l'exécute, alors que ce n'est pas forcément
vrai pour le chargeur d'amorçage dans le cas d'un multiboot.
Je ne vois pas le rapport entre l'initramfs et le logiciel libre. C'est juste une archive au format cpio créée par le système et qui contient des fichiers présents sur le système. Il inclut déjà les firmwares non libres pouvant être nécessaires au montage de la racine, donc un peu plus ou un peu moins...
Tu as raison et j'y ai pensé après avoir écrit.
Au moins le générateur d'initramfs a l'avantage d'être fourni par la distribution du système qui l'exécute, alors que ce n'est pas forcément vrai pour le chargeur d'amorçage dans le cas d'un multiboot.
