Donc… vu que le CPU ou le firmware a des failles […], tu abandonnes toute idée de liberté ou d'indépendance numérique.
C'est surtout que je ne vois pas comment on pourrait, sur un ordinateur récent, être libre au "sens des libristes" alors qu'on ne maîtrise finalement rien de son matériel ni des firmwares qui y tournent dessus. Les failles ne font que mettre en évidence ce manque de contrôle de l'utilisateur final.
De plus, ce n'est pas vraiment un renoncement, mais une tentative de pas de côté. En effet, ce qui m'avait décidé à partir sur iPadOS (et maintenant plutôt sur macOS), c'était d'être capable de récupérer toutes mes données de mon iPhone (certaines dans un format propre à Apple), pour me redonner la liberté du choix de mon futur téléphone, que ce soit une smartphone sous Murena (/e/OS) ou un téléphone basique selon mes besoins et mes priorités.
Au final, c'est un choix que je considère de faire en fonction de mon vécu, de mes expériences, et selon des critères qui me sont propres. Mais toujours avec l'idée de ne pas réduire ma liberté en tant qu'utilisateur final, mais juste de la préserver au mieux en fonction de la situation actuelle (exportation des données en format ouvert, possibilité d'utiliser des logiciels libres sur la plateforme, possibilité à terme de repasser sur Linux).
Je comprends si tu n'approuves pas, car tu as ta propre vision des choses qui t'a fait faire d'autres choix que les miens et basés sur ton propre vécu, tes propres expériences.
L'important, c'est juste que chacun puisse être libre de faire ses choix de manière la plus éclairée possible, selon ses propres critères et sa sensibilité à différents sujets, avec tout de même l'objectif partagé par tous d'avoir le plus de liberté et de contrôle possible en tant qu'utilisateur final.
Bon, je vais m'arrêter là, car je pense qu'on a largement dévié du sujet du journal, et que je ne souhaite pas donner plus d'informations personnelles visibles à tous.
C'est vrai que les processeurs ARM n'ont pas eu de faille…
Tiens ? Ha ben si en fait.
Ah mais j'ai jamais dit le contraire!
Dès l'annonce de la faille Meltdown, on savait que le Cortex-A75 y était aussi vulnérable.
Concernant l'exemple du Cortex-A53, cela m'a paru bizarre car c'était justement un des rares cœur processeur à ne pas sensé être touché par les failles Spectre, car exécutant ses instructions dans l'ordre (In Order). Je n'ai rien trouvé qui puisse expliquer ce résultat, et savoir si il s'agit d'un faux positif ou pas.
Par contre, je suis tombé sur un papier décrivant une faille nommée SisCloak, et qui indiquerait que les Cortex-A53 sont aussi vulnérables à cause, encore une fois, de l'usage d'un mécanisme de spéculation. S'agirait-il de la faille relevé par la commande lscpu?
Toujours est-il que j'ai l'impression qu'il y a beaucoup plus de failles du côté du x86 que du côté de ARM, peut-être à cause d'une couverture sensationnaliste dans le cas du premier, c'est vrai. Il y en a eu beaucoup, la dernière faille que je peux nommer est Zenbleed qui affecte tous les processeurs Zen2 (et donc certains processeurs sortis il n'y a pas si longtemps).
Mais il n'y a pas eu que des failles matérielles! Je me souviens des vulnérabilités qui ont touché le ME d'Intel (apparemment un système MINIX 3 embarqué), et tout le bruit que cela avait fait à l'époque.
Il y a aussi eu récemment, au niveau de l'UEFI cette fois, le bootkit BlackLotus qui, d'après un article que j'avais lu à l'époque, était uniquement possible car des certificats non-signé par Microsoft devait être accepté pour permettre à des distributions GNU/Linux tierces de booter avec Secure Boot. Ça pourrait même être une des motivations de Microsoft pour pousser son co-processeur de sécurité Pluton qui est déjà décrié.
Bref, je me rends surtout compte que je n'ai aucun contrôle sur le matériel d'un futur appareil, ni sur les logiciels qui y sont embarqués et tournent en-dessous de l'OS.
C'est ce constat qui m'a entre autre fait relativisé l'importance d'avoir un système Linux installé sur mes machines (le fameux "à quoi bon"), ce critère devenant moins décisif dans le choix de mes futurs appareils.
Ainsi, mon besoin de rester dans l'écosystème Apple sans subir sa politique commerciale pour ses iPhone a pris plus d'importance, et m'a fait envisager l'acquisition d'un iPad, avant que le présent journal ne fasse plutôt pencher vers un Mac.
Quant aux restrictions par Microsoft, des solutions comme le DMA devraient in fine leur interdire d'interdire l'installation de Linux sur PC.
Honnêtement, je ne sais pas du tout si le DMA couvre le mécanisme de boot et sa sécurisation. Et même si c'était le cas, je ne suis pas sûr qu'avec tout ce que Microsoft a déjà mis en place les autorités européennes vont imposer que n'importe quel système d'exploitation puisse booter sur n'importe quel PC, et à la place juste se contenter d'un engagement de la part de Microsoft à certifier les quelques grandes distributions Linux.
Idéalement, il faudrait que ce soit un organisme indépendant qui gère l'UEFI et les autres mécanismes de boot de manière à ce que, peu importe le système qu'on veuille démarrer, la sécurité des données de l'utilisateur ne soit jamais compromise, et ce en édictant des normes et en proposant un logiciel standard.
Or là, on en prend pas le chemin, et part peut-être imposer coreboot comme standard, on aura toujours le risque d'un système se fermant de plus en plus au nom de la sécurité, et qui prétériterait les petites distributions Linux et d'autres systèmes alternatifs.
Bon, je ne remercie pas l'auteur de ce journal, car en en le lisant rapidement j'ai été pris de panique et j'ai tourné en rond pendant plus d'une heure, à réfléchir aux conséquences possibles, avec que les premiers commentaires ne me sortent de cet état de détresse en rétablissant les faits.
Du coup, j'ai d'une part "moinser" ce journal, et d'autre part, je vous partage le résultat de ma cogitation intense, avec qui-sait des éléments qui pourrait intéresser certains.
Bref, faisons dans le récit d'anticipation, en imaginant que ce système devienne obligatoire et le seul moyen de connexion possible en Europe aux services listés que j'utilise.
Commençons:
Apple AppStore
Google Play
Ah, vous voulez donc que j'arrête d'utiliser un smartphone?
Plus sérieusement, je trouverais problématique de devoir décliner son identité pour pouvoir acquérir des logiciels, alors que pour moi c'est justement important que l'utilisateur ait le droit d'utiliser son appareil comme bon lui semble (c'est pas pour rien que je suis venu à Linux).
Alors certes, on peut facilement trouver des solutions alternatives de distributions de logiciels pour les téléphones "Android-based" (je pense tout de suite à F-droid sur un système Android de base, mais surtout aux téléphones Murena qui se passent du PlayStore de Google Out-of-the-Box), et qu'avec l'application du DMA, Apple devrait autoriser le sideloading et les Stores alternatifs. Mais on est loin du confort du store configurer par défaut, et on doit faire une croix sur les logiciels dont on a payé l'utilisation.
Un autre problème serait que les tablettes, en particulier l'iPad, ne seraient du coup plus un remplacement viable d'ordinateur qui, eux, n'ont pas cette restriction aux stores pour l'installation de logiciels.
Personnellement, j'avais considéré l'iPad justement comme solution de replis, car ayant besoin de rester dans l'univers Apple, et étant pessimiste sur l'avenir de Linux sur PC à cause des manoeuvres de Microsoft et des différentes failles sur les processeurs Intel et AMD.
Mais dans l'hypothèse où la confirmation de mon identité serait requise pour utiliser cet appareil, par exemple pour vérifier que je suis majeur, je préférerais me passer de cet appareil et regarder plutôt du côté des Macs (tout en soutenant Asahi Linux).
Et ainsi passer à un téléphone basique qui me servirait juste à … téléphoner.
LinkedIn
Là, c'est typiquement le service pour lequel je serais le moins réticent à m'identifier, car c'est tout le principe de cette plateforme que les profils appartiennent bien aux personnes ou entreprises réelles auxquels ils correspondent.
À la limite, on pourrait vouloir éviter que Microsoft ait encore plus d'informations sur nous en préférant d'autres plateformes comme Xing, mais avec tout de même le risque que ces dernières devraient à leur tour nous obliger à décliner notre identité dès quelles auront atteint une taille critique.
Wikipedia
Là, par contre, ce serait le site duquel j'aurais le plus de peine à me passer.
Je comprends pourquoi il serait nécessaire de pouvoir identifier les personnes modifiant les articles (éviter les manipulations et la désinformation sur certains sujet ou certaines personnes), voire pour celles les consultant (vérification d'âge suivant les sujets), mais mettre en place un place un tel système tuerait instantanément tout l'intérêt de cette encyclopédie en ligne, qui repose sur le web collaboratif, et fermerait potentiellement des pans entier de connaissance librement accessibles à de nombreuses personnes.
Ce n'est pas la première fois que les inquiétudes autour de l'impact du DSA et du DMA sur Wikipedia sont évoquées à ce propos, ce qui a peut-être et pourrait encore impacter en retour en bien le DSA et le DMA, rendant ce récit d'anticipation… totalement fictionnel!
YouTube
Dès la mise en place de ce système de vérification d'identité obligatoire (justifiable par les restrictions d'âge), peut-être associée à une obligation d'abonnement pour continuer à y regarder des vidéos avec un bloqueur de pub activé, j'arrêterais d'y aller.
Et ce serait avec regrets, car j'apprécie réellement le travail de nombreux créateurs sur cette plateforme, que ce soit pour me divertir ou apprendre quelque chose et élargir mon horizon.
Bing
Google Search
Du coup, est-ce que DuckDuckgo, Qwant, Searx et d'autres moteurs de recherches se basant sur les deux cités précédemment devraient eux aussi vérifier l'identité de leurs utilisateurs, toujours dans l'optique de protéger les mineurs?
Et, même en supprimant tout usage des résulats de Bing et Google Search, ces moteurs ne risqueraient-ils pas à leur tour d'être obliger de vérifier l'identité de leurs utilisateurs?
Faudrait-il alors revenir aux annuaires Web pour éviter de devoir s'identifier pour trouver un site web?
Bon, j'arrête les interrogations ici, car ça commence à devenir vertigineux.
En espérant que le fruit de mes réflexions puissent déboucher sur des discussions intéressantes, j'aurai au moins le sentiment de ne pas avoir réfléchi à tout ça pour rien.
Je ne vais pas commenter les accusations qui sont décrites dans ce article, ce sera à la justice californienne de faire toute la lumière sur cette histoire et rendre un jugement.
Par contre, de mon point de vue d'amateur dans le domaine du libre, j'ai l'impression que le projet OpenELA est de plus en plus mal engagé, et que ça ne vaudrait pas la peine de soutenir ce genre projet cherchant à littéralement cloner RHEL.
Je trouve l'approche d'Alma Linux beaucoup plus sensée et sérieuse.
Au lieu de chercher à faire une copie carbone de RHEL en utilisant une faille dans le contrat de support, le projet prend acte de la décision d'IBM/Red Hat, et profite des avantages liés à leur nouveau statut de distribution compatible avec RHEL mais pas identique.
On pourrait donc imaginer qu'Alma Linux concurrencera dans un avenir proche RHEL et que, en tant que distribution contribuant directement à Fedora et CentOS Steam, elle rendra peut-être ces deux projets moins dépendants d'IBM/Red Hat.
En tout cas, j'envisage plus sereinement l'avenir des distributions GNU/Linux avec Alma Linux comme grand concurrent de RHEL pour les serveurs et stations de travail plutôt qu'avec un clone de RHEL produit par OpenELA et ses membres.
Mais il s'agit uniquement de mon avis d'utilisateur non-professionnel de distribution Linux, et qui suit un peu toute cette histoire autour de CentOS d'assez loin.
Je trouverai d'ailleurs très intéressant d'avoir l'avis de professionnels qui ont la responsabilité de choisir une distribution en remplacement de CentOS, et de voir si les éléments que j'ai évoqué jouent dans le choix de la distribution, ou bien si d'autres facteurs plus importants entre en ligne de compte.
Du coup, votre avis sur Alma Linux et ce choix de ne plus cloner RHEL?
Salut. Ce message est mon premier sur ce site que je fréquente depuis un moment, je me suis inscrit seulement maintenant pour commenter cette dépêche.
Je ne suis pas un expert dans le domaine de l'architecture de processeur et de la micro-électronique en général, donc les termes que je vais utiliser risquent de ne pas être très précis.
Si je résume, ce processeur a d'un côté une limitation du nombre d'instructions qui peuvent être implémentées à cause du nombre limité de bits disponible pour leur identifiant, et de l'autre pour chaque coeur une mémoire de 32Ko (la SPM) dans laquelle on peut manuellement stocker des données directement ou en passant par le DMA.
Du coup, pourquoi ne pas créer une sorte de "palette d'instructions", fonctionnant de la même manière que les palettes de couleurs pour les anciennes consoles de jeu vidéo, qui serait stockée dans cette mémoire de 32Ko?
L'avantage principal des palettes de couleur est justement de pouvoir les représenter de manière plus compacte dans une image, en échange d'une limitation des couleurs disponible pour l'image à celles présentes dans la palette (exemple: une palette de 256 couleurs codées en 32-bits, permettant de représenter la couleur de chaque pixel d'une image donnée avec une valeur codée sur 8 bits).
Ici, l'idée serait la même, puisque les 7 bits de l'opcode actuel ne serviraient plus à représenter directement une instruction réelle, mais serait un pointeur vers l'identifiant de cette même instruction, stocké dans la palette et codé sur un plus grand nombre de bits.
Ainsi, si ces identifiants ont par exemple une taille de 16-bits, on pourrait représenter au total plus de 32'000 instructions, mais seules 128 d'entre-elles seraient utilisables directement par chaque coeur car stockées dans cette palette d'une taille de 256 octets.
Il faudrait donc, si c'est nécessaire, pouvoir changer les valeurs dans la palette en fonction des instructions nécessaires à l'exécution des différents programmes.
Cela pourrait se faire en modifiant directement les différentes entrées de la palette.
Il serait également possible de créer plusieurs palettes (par exemple, 4 palettes de 32 instructions chacune), avec les différentes instructions qui y seraient réparties en fonction de la fréquence de leur utilisation, et ainsi remplacer complètement la palette des instructions les moins fréquentes par une autre palette.
Dans tous les cas, ce serait au compilateur de gérer en amont la création et le chargement de ces palettes. Et il faudrait une instruction spéciale permettant au coeur processeur de savoir combien de palettes existent pour pouvoir y accéder en interprétant correctement l'ancien opcode de 7 bits (premiers bits pour la palette, derniers pour l'instruction dans la palette).
Que pensez vous de cette idée? Est-ce qu'elle serait facilement implémentable?
Est-ce que le cache SPM peut utilisé comme une "palette RAM" avec 256 octets réservé d'office, ou bien faut-il créer une mémoire cache supplémentaire dédiée?
[^] # Re: Un récit d'anticipation
Posté par De_passage . En réponse au journal La carte d'identité européenne eIDAS bientôt requise pour utiliser les grandes plateformes?. Évalué à 0.
C'est surtout que je ne vois pas comment on pourrait, sur un ordinateur récent, être libre au "sens des libristes" alors qu'on ne maîtrise finalement rien de son matériel ni des firmwares qui y tournent dessus. Les failles ne font que mettre en évidence ce manque de contrôle de l'utilisateur final.
De plus, ce n'est pas vraiment un renoncement, mais une tentative de pas de côté. En effet, ce qui m'avait décidé à partir sur iPadOS (et maintenant plutôt sur macOS), c'était d'être capable de récupérer toutes mes données de mon iPhone (certaines dans un format propre à Apple), pour me redonner la liberté du choix de mon futur téléphone, que ce soit une smartphone sous Murena (/e/OS) ou un téléphone basique selon mes besoins et mes priorités.
Au final, c'est un choix que je considère de faire en fonction de mon vécu, de mes expériences, et selon des critères qui me sont propres. Mais toujours avec l'idée de ne pas réduire ma liberté en tant qu'utilisateur final, mais juste de la préserver au mieux en fonction de la situation actuelle (exportation des données en format ouvert, possibilité d'utiliser des logiciels libres sur la plateforme, possibilité à terme de repasser sur Linux).
Je comprends si tu n'approuves pas, car tu as ta propre vision des choses qui t'a fait faire d'autres choix que les miens et basés sur ton propre vécu, tes propres expériences.
L'important, c'est juste que chacun puisse être libre de faire ses choix de manière la plus éclairée possible, selon ses propres critères et sa sensibilité à différents sujets, avec tout de même l'objectif partagé par tous d'avoir le plus de liberté et de contrôle possible en tant qu'utilisateur final.
Bon, je vais m'arrêter là, car je pense qu'on a largement dévié du sujet du journal, et que je ne souhaite pas donner plus d'informations personnelles visibles à tous.
[^] # Re: Un récit d'anticipation
Posté par De_passage . En réponse au journal La carte d'identité européenne eIDAS bientôt requise pour utiliser les grandes plateformes?. Évalué à 0.
Ah mais j'ai jamais dit le contraire!
Dès l'annonce de la faille Meltdown, on savait que le Cortex-A75 y était aussi vulnérable.
Concernant l'exemple du Cortex-A53, cela m'a paru bizarre car c'était justement un des rares cœur processeur à ne pas sensé être touché par les failles Spectre, car exécutant ses instructions dans l'ordre (In Order). Je n'ai rien trouvé qui puisse expliquer ce résultat, et savoir si il s'agit d'un faux positif ou pas.
Par contre, je suis tombé sur un papier décrivant une faille nommée SisCloak, et qui indiquerait que les Cortex-A53 sont aussi vulnérables à cause, encore une fois, de l'usage d'un mécanisme de spéculation. S'agirait-il de la faille relevé par la commande lscpu?
Toujours est-il que j'ai l'impression qu'il y a beaucoup plus de failles du côté du x86 que du côté de ARM, peut-être à cause d'une couverture sensationnaliste dans le cas du premier, c'est vrai. Il y en a eu beaucoup, la dernière faille que je peux nommer est Zenbleed qui affecte tous les processeurs Zen2 (et donc certains processeurs sortis il n'y a pas si longtemps).
Mais il n'y a pas eu que des failles matérielles! Je me souviens des vulnérabilités qui ont touché le ME d'Intel (apparemment un système MINIX 3 embarqué), et tout le bruit que cela avait fait à l'époque.
Il y a aussi eu récemment, au niveau de l'UEFI cette fois, le bootkit BlackLotus qui, d'après un article que j'avais lu à l'époque, était uniquement possible car des certificats non-signé par Microsoft devait être accepté pour permettre à des distributions GNU/Linux tierces de booter avec Secure Boot. Ça pourrait même être une des motivations de Microsoft pour pousser son co-processeur de sécurité Pluton qui est déjà décrié.
Bref, je me rends surtout compte que je n'ai aucun contrôle sur le matériel d'un futur appareil, ni sur les logiciels qui y sont embarqués et tournent en-dessous de l'OS.
C'est ce constat qui m'a entre autre fait relativisé l'importance d'avoir un système Linux installé sur mes machines (le fameux "à quoi bon"), ce critère devenant moins décisif dans le choix de mes futurs appareils.
Ainsi, mon besoin de rester dans l'écosystème Apple sans subir sa politique commerciale pour ses iPhone a pris plus d'importance, et m'a fait envisager l'acquisition d'un iPad, avant que le présent journal ne fasse plutôt pencher vers un Mac.
Honnêtement, je ne sais pas du tout si le DMA couvre le mécanisme de boot et sa sécurisation. Et même si c'était le cas, je ne suis pas sûr qu'avec tout ce que Microsoft a déjà mis en place les autorités européennes vont imposer que n'importe quel système d'exploitation puisse booter sur n'importe quel PC, et à la place juste se contenter d'un engagement de la part de Microsoft à certifier les quelques grandes distributions Linux.
Idéalement, il faudrait que ce soit un organisme indépendant qui gère l'UEFI et les autres mécanismes de boot de manière à ce que, peu importe le système qu'on veuille démarrer, la sécurité des données de l'utilisateur ne soit jamais compromise, et ce en édictant des normes et en proposant un logiciel standard.
Or là, on en prend pas le chemin, et part peut-être imposer coreboot comme standard, on aura toujours le risque d'un système se fermant de plus en plus au nom de la sécurité, et qui prétériterait les petites distributions Linux et d'autres systèmes alternatifs.
Mais j'espère vraiment me tromper.
# Un récit d'anticipation
Posté par De_passage . En réponse au journal La carte d'identité européenne eIDAS bientôt requise pour utiliser les grandes plateformes?. Évalué à 1.
Bon, je ne remercie pas l'auteur de ce journal, car en en le lisant rapidement j'ai été pris de panique et j'ai tourné en rond pendant plus d'une heure, à réfléchir aux conséquences possibles, avec que les premiers commentaires ne me sortent de cet état de détresse en rétablissant les faits.
Du coup, j'ai d'une part "moinser" ce journal, et d'autre part, je vous partage le résultat de ma cogitation intense, avec qui-sait des éléments qui pourrait intéresser certains.
Bref, faisons dans le récit d'anticipation, en imaginant que ce système devienne obligatoire et le seul moyen de connexion possible en Europe aux services listés que j'utilise.
Commençons:
Ah, vous voulez donc que j'arrête d'utiliser un smartphone?
Plus sérieusement, je trouverais problématique de devoir décliner son identité pour pouvoir acquérir des logiciels, alors que pour moi c'est justement important que l'utilisateur ait le droit d'utiliser son appareil comme bon lui semble (c'est pas pour rien que je suis venu à Linux).
Alors certes, on peut facilement trouver des solutions alternatives de distributions de logiciels pour les téléphones "Android-based" (je pense tout de suite à F-droid sur un système Android de base, mais surtout aux téléphones Murena qui se passent du PlayStore de Google Out-of-the-Box), et qu'avec l'application du DMA, Apple devrait autoriser le sideloading et les Stores alternatifs. Mais on est loin du confort du store configurer par défaut, et on doit faire une croix sur les logiciels dont on a payé l'utilisation.
Un autre problème serait que les tablettes, en particulier l'iPad, ne seraient du coup plus un remplacement viable d'ordinateur qui, eux, n'ont pas cette restriction aux stores pour l'installation de logiciels.
Personnellement, j'avais considéré l'iPad justement comme solution de replis, car ayant besoin de rester dans l'univers Apple, et étant pessimiste sur l'avenir de Linux sur PC à cause des manoeuvres de Microsoft et des différentes failles sur les processeurs Intel et AMD.
Mais dans l'hypothèse où la confirmation de mon identité serait requise pour utiliser cet appareil, par exemple pour vérifier que je suis majeur, je préférerais me passer de cet appareil et regarder plutôt du côté des Macs (tout en soutenant Asahi Linux).
Et ainsi passer à un téléphone basique qui me servirait juste à … téléphoner.
Là, c'est typiquement le service pour lequel je serais le moins réticent à m'identifier, car c'est tout le principe de cette plateforme que les profils appartiennent bien aux personnes ou entreprises réelles auxquels ils correspondent.
À la limite, on pourrait vouloir éviter que Microsoft ait encore plus d'informations sur nous en préférant d'autres plateformes comme Xing, mais avec tout de même le risque que ces dernières devraient à leur tour nous obliger à décliner notre identité dès quelles auront atteint une taille critique.
Là, par contre, ce serait le site duquel j'aurais le plus de peine à me passer.
Je comprends pourquoi il serait nécessaire de pouvoir identifier les personnes modifiant les articles (éviter les manipulations et la désinformation sur certains sujet ou certaines personnes), voire pour celles les consultant (vérification d'âge suivant les sujets), mais mettre en place un place un tel système tuerait instantanément tout l'intérêt de cette encyclopédie en ligne, qui repose sur le web collaboratif, et fermerait potentiellement des pans entier de connaissance librement accessibles à de nombreuses personnes.
Ce n'est pas la première fois que les inquiétudes autour de l'impact du DSA et du DMA sur Wikipedia sont évoquées à ce propos, ce qui a peut-être et pourrait encore impacter en retour en bien le DSA et le DMA, rendant ce récit d'anticipation… totalement fictionnel!
Dès la mise en place de ce système de vérification d'identité obligatoire (justifiable par les restrictions d'âge), peut-être associée à une obligation d'abonnement pour continuer à y regarder des vidéos avec un bloqueur de pub activé, j'arrêterais d'y aller.
Et ce serait avec regrets, car j'apprécie réellement le travail de nombreux créateurs sur cette plateforme, que ce soit pour me divertir ou apprendre quelque chose et élargir mon horizon.
Du coup, est-ce que DuckDuckgo, Qwant, Searx et d'autres moteurs de recherches se basant sur les deux cités précédemment devraient eux aussi vérifier l'identité de leurs utilisateurs, toujours dans l'optique de protéger les mineurs?
Et, même en supprimant tout usage des résulats de Bing et Google Search, ces moteurs ne risqueraient-ils pas à leur tour d'être obliger de vérifier l'identité de leurs utilisateurs?
Faudrait-il alors revenir aux annuaires Web pour éviter de devoir s'identifier pour trouver un site web?
Bon, j'arrête les interrogations ici, car ça commence à devenir vertigineux.
En espérant que le fruit de mes réflexions puissent déboucher sur des discussions intéressantes, j'aurai au moins le sentiment de ne pas avoir réfléchi à tout ça pour rien.
# Heu... vive Alma Linux?
Posté par De_passage . En réponse au lien Rocky Linux backer CIQ rejects lawsuit's claims it was founded on stolen IP. Évalué à 3.
Je ne vais pas commenter les accusations qui sont décrites dans ce article, ce sera à la justice californienne de faire toute la lumière sur cette histoire et rendre un jugement.
Par contre, de mon point de vue d'amateur dans le domaine du libre, j'ai l'impression que le projet OpenELA est de plus en plus mal engagé, et que ça ne vaudrait pas la peine de soutenir ce genre projet cherchant à littéralement cloner RHEL.
Je trouve l'approche d'Alma Linux beaucoup plus sensée et sérieuse.
Au lieu de chercher à faire une copie carbone de RHEL en utilisant une faille dans le contrat de support, le projet prend acte de la décision d'IBM/Red Hat, et profite des avantages liés à leur nouveau statut de distribution compatible avec RHEL mais pas identique.
On pourrait donc imaginer qu'Alma Linux concurrencera dans un avenir proche RHEL et que, en tant que distribution contribuant directement à Fedora et CentOS Steam, elle rendra peut-être ces deux projets moins dépendants d'IBM/Red Hat.
En tout cas, j'envisage plus sereinement l'avenir des distributions GNU/Linux avec Alma Linux comme grand concurrent de RHEL pour les serveurs et stations de travail plutôt qu'avec un clone de RHEL produit par OpenELA et ses membres.
Mais il s'agit uniquement de mon avis d'utilisateur non-professionnel de distribution Linux, et qui suit un peu toute cette histoire autour de CentOS d'assez loin.
Je trouverai d'ailleurs très intéressant d'avoir l'avis de professionnels qui ont la responsabilité de choisir une distribution en remplacement de CentOS, et de voir si les éléments que j'ai évoqué jouent dans le choix de la distribution, ou bien si d'autres facteurs plus importants entre en ligne de compte.
Du coup, votre avis sur Alma Linux et ce choix de ne plus cloner RHEL?
# "Palette d'instruction": solution au nombre limité d'instructions?
Posté par De_passage . En réponse à la dépêche AltairX : le processeur du futur ?. Évalué à 3.
Salut. Ce message est mon premier sur ce site que je fréquente depuis un moment, je me suis inscrit seulement maintenant pour commenter cette dépêche.
Je ne suis pas un expert dans le domaine de l'architecture de processeur et de la micro-électronique en général, donc les termes que je vais utiliser risquent de ne pas être très précis.
Si je résume, ce processeur a d'un côté une limitation du nombre d'instructions qui peuvent être implémentées à cause du nombre limité de bits disponible pour leur identifiant, et de l'autre pour chaque coeur une mémoire de 32Ko (la SPM) dans laquelle on peut manuellement stocker des données directement ou en passant par le DMA.
Du coup, pourquoi ne pas créer une sorte de "palette d'instructions", fonctionnant de la même manière que les palettes de couleurs pour les anciennes consoles de jeu vidéo, qui serait stockée dans cette mémoire de 32Ko?
L'avantage principal des palettes de couleur est justement de pouvoir les représenter de manière plus compacte dans une image, en échange d'une limitation des couleurs disponible pour l'image à celles présentes dans la palette (exemple: une palette de 256 couleurs codées en 32-bits, permettant de représenter la couleur de chaque pixel d'une image donnée avec une valeur codée sur 8 bits).
Ici, l'idée serait la même, puisque les 7 bits de l'opcode actuel ne serviraient plus à représenter directement une instruction réelle, mais serait un pointeur vers l'identifiant de cette même instruction, stocké dans la palette et codé sur un plus grand nombre de bits.
Ainsi, si ces identifiants ont par exemple une taille de 16-bits, on pourrait représenter au total plus de 32'000 instructions, mais seules 128 d'entre-elles seraient utilisables directement par chaque coeur car stockées dans cette palette d'une taille de 256 octets.
Il faudrait donc, si c'est nécessaire, pouvoir changer les valeurs dans la palette en fonction des instructions nécessaires à l'exécution des différents programmes.
Cela pourrait se faire en modifiant directement les différentes entrées de la palette.
Il serait également possible de créer plusieurs palettes (par exemple, 4 palettes de 32 instructions chacune), avec les différentes instructions qui y seraient réparties en fonction de la fréquence de leur utilisation, et ainsi remplacer complètement la palette des instructions les moins fréquentes par une autre palette.
Dans tous les cas, ce serait au compilateur de gérer en amont la création et le chargement de ces palettes. Et il faudrait une instruction spéciale permettant au coeur processeur de savoir combien de palettes existent pour pouvoir y accéder en interprétant correctement l'ancien opcode de 7 bits (premiers bits pour la palette, derniers pour l'instruction dans la palette).
Que pensez vous de cette idée? Est-ce qu'elle serait facilement implémentable?
Est-ce que le cache SPM peut utilisé comme une "palette RAM" avec 256 octets réservé d'office, ou bien faut-il créer une mémoire cache supplémentaire dédiée?