Thomas Debesse a écrit 3649 commentaires

Par manque de temps, gépalu.

Si tu fait écrire à une IA parce que t’as pas le temps d’écrire, je ne lirai pas (car c’est le même résultat que de faire lire par une IA).

ce commentaire est sous licence cc by 4 et précédentes

Autre ingénuité : beaucoup utilisent déjà des VPNs, et il faut supposer que si la “foreign influence” est institutionnalisée, ils utilisent déjà massivement des VPNs.

Ce que les pseudo-experts de plateaux sont en train de découvrir, ce ne sont pas des influences étrangères, mais l’existence de VPNs.

ce commentaire est sous licence cc by 4 et précédentes

Oui, c’est tout à fait possible de mettre des arguments dans le shebang. Ici on pourrait faire #! /usr/bin/env -S bash -x

Personnellement j’ai fait ce genre de chose (mettre des arguments dans le shebang) dans le passé, mais maintenant j’évite quand c’est évitable. Je ne serai pas surpris si pour certains langages ce serait inévitable (par exemple pour spécifier comment le code doit être interprété avant que l’interprétation ne commence).

Utiliser des arguments dans le shebang peut avoir le mauvais effet de semer la confusion chez les éditeurs et autre logiciels qui veulent détecter le format du document (et non exécuter le code).

Dans l’exemple ci-dessus, si un logiciel cherche ^#![ ]*/usr/bin/env[ ]+bash pour détecter le langage bash pour activer la coloration syntaxique, ça ne marchera pas. Et détecter toute les variantes implique d’émuler une partie de env lui-même… je doute que tous les éditeurs soient aussi exhaustifs ! VIM a l’air de s’en sortir en tout cas.

Typiquement pour des options de bash comme -e, ça coûte rien de le mettre sur la ligne d’après si ça aide l’éditeur à correctement coloriser le code, mais ça n’est pas une question d’exécution. Le shebang est d’abord là que pour exécuter, et c’est en ça qu’il est fiable.

Je ne me suis pas exprimé sur les extensions de fichiers qui ne sont pas exécutables et qu’il faut bien reconnaître (surtout quand on pense à tous les formats qui utilise zip comme conteneur). L’extension n’est décisive pour l’exécution que sous Windows (.exe, .com, .cmd, .bat…), ailleurs on a un format standard pour dire au système quoi faire. 😎

ce commentaire est sous licence cc by 4 et précédentes

C’est toujours le cas car c’est ce qui est demandé.

$ cat script-python
#! /usr/bin/env python2
print "bonjour tout le monde"

$ ./script-python
bonjour tout le monde

$ python2 script-python
bonjour tout le monde

$ python3 script-python
  File "script-python", line 2
    print "bonjour tout le monde"
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
SyntaxError: Missing parentheses in call to 'print'. Did you mean print(...)?

$ ruby script-python
ruby: no Ruby script found in input (LoadError)

C’est le shebang qui détermine l’interpréteur, à moins que l’utilisateur ne force un autre.

Ce n’est pas qu’une affaire de script, c’est vrai aussi pour le code compilé:

$ file /usr/bin/whoami
/usr/bin/whoami: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=064a1abc92933fda978fa7d97250c1bf12c65e46, for GNU/Linux 3.2.0, stripped

$ LANG=C.UTF-8 readelf -l /usr/bin/whoami | grep 'Requesting program interpreter'
      [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]

$ /usr/bin/whoami
illwieckz

$ /lib64/ld-linux-x86-64.so.2 /usr/bin/whoami
illwieckz

$ /usr/i686-linux-gnu/lib/ld-linux.so.2 /usr/bin/whoami
/usr/bin/whoami: error while loading shared libraries: /usr/bin/whoami: wrong ELF class: ELFCLASS64

$ /usr/aarch64-linux-gnu/lib/ld-linux-aarch64.so.1 /usr/bin/whoami
/usr/bin/whoami: error while loading shared libraries: /usr/bin/whoami: cannot open shared object file: No such file or directory

Ça veut d’ailleurs dire qu’on peut techniquement passer des paramètres dans le shebang:

$ cat test
#! /usr/bin/bash -x
echo test

$ ./test
+ echo test
test

Bon, mais ne faites pas ça, la façon standard d’appeler un interpréteur c’est /usr/bin/env <interpréteur>, et rajouter des paramètres risque de casser la détection du langage par les non-interpréteurs (comme les éditeurs pour activer la bonne coloration syntaxiques).

Si vous ne renseignez pas l’interpréteur correctement les outils non-interpréteurs seront perdus car c’est ce qu’ils regardent, et le shebang est bien plus fiable que l’extension: il ne peut pas mentir. Le shebang est non-ambigu, ajouter une extension à un programme pensé pour être appelé depuis un shell, saymal:

• https://www.talisman.org/~erlkonig/documents/commandname-extensions-considered-harmful/

Ajouter une extension comme un .py c’est utile pour une bibliothèque par exemple, mais pour appeler une commande, ajouter une extension c’est très très mal. En dehors de ce genre de cas de bibliothèque, ajouter une extension à un script c’est généralement pour contourner les limitations de Windows qui ne regarde pas l’entête du fichier pour déterminer son format.

Mais là encore, derrière le gang qui salit les scripts en y ajoutant des extensions, il y a un culte du cargo entretenus par ceux qui ont imité des Windowsiens, reproduisant par mimétisme les gestes sans comprendre pourquoi ces Windowsiens faisaient ainsi, Windowsiens pour qui ces rites participent en fait à leur stratégie d’évitement et de résilience face à la souffrance que Windows leur cause.

ce commentaire est sous licence cc by 4 et précédentes

Personnellement je ne demande pas grand chose à bash, je sous-utilises ses capacités avancées en fait, mais certaines fonctionnalités sont vraiment pratiques, comme les array.

Je veux pouvoir faire ça, et itérer tout ça :

vars=("un deux" blabla)
for var in "${var[@]}"
do
  echo "${var}"
done

Utiliser des hacks comme ça, ça ne marche pas:

vars='un deux blabla'
for var in ${vars}
do
  echo "${var}"
done

Et ça, c’est dégueulasse et ça invoque des bugs les soirs de pleine-lune :

vars="un deux
blabla"
cat "${vars}" | while read "${var}"
do
  echo "${var}"
done

Oui je sais on peut aussi modifier IFS, mais bref, tout ça c’est moche et ce sont des nids à problèmes.

Le code de tableau ci-dessus fonctionne sous macOS parce que c’est un exemple très limité, mais dès qu’on passe un tableau en paramètre à une fonction, tout s’écroule.

Ça, ça ne marge pas avec le bash de macOS :

func()
{
  for var in "${@}"
  do
    echo "${var}"
  done
}

vars=()

if "${something}"
then
  vars+=("blabla")
fi

func "$[vars[@]}"

Quand le tableau est vide, alors ${@} n’est pas déclarée dans la fonction, et donc le script s’interrompt à cause de la variable inconnue dès lors qu’on active set -u.

On peut contourner en faisant quelque chose comme ça :

func()
{
  if -z "${@:-}"
  then
    return
  fi

  for var in "${@}"
  do
    echo "${var}"
  done
}

vars=()

if "${something}"
then
  vars+=("blabla")
fi

func "$[vars[@]}"

Bon, j’ai écrit ce commentaire de mémoire, il y a peut-être encore de nuances obscures, et j’ai peut-être aussi fait des fautes, mais vous voyez l’idée. Il faut dégueulasser les scripts avec ce genre de contournements pour le bash de 2007 de macOS.

ce commentaire est sous licence cc by 4 et précédentes

J’ai rigolé, mais j’ai commencé à programmer en C K&R avec Lattice C (compilateur qui servira de base à Microsoft C 1), avec TED d’Information Builder comme éditeur (éditeur modal, mais au fonctionnement différent de VI) qui est bien plus ancien que edit.com, et en scriptant la compilation avec des .bat écrits pour le command.com de DOS 3.3. Ça m’amuse encore de jouer avec Lattice C de temps en temps, mais à ce niveau c’est pas de la programmation c’est du rétrogaming.

Alors que quand je me prends dans la figure un bash de 2007 et un make de 2006 sur macOS, je ne joue pas du tout, ça ne m’amuse pas du tout, et c’est une vraie souffrance.

Cette obsolescence est la raison pour laquelle on privilégie Python à Bash pour les scripts de développement du jeu Unvanquished, mais un langage de script c’est parfois plus pratique que Python, donc on en a quand même un ou deux et à chaque fois on doit dégueulasser le script avec des convolutions affreuses pour conserver la compatibilité avec le bash de 2007. Pour le coup, Apple nous empêche de bénéficier de toute avancée (fonctionnalité, correctif de bug) qui serait apparue dans bash depuis 2007… C’est du véritable sabotage pour les choses, et de la maltraitance pour les hommes.

ce commentaire est sous licence cc by 4 et précédentes

Je crois que la raison de cette obsolescence, c’est qu’ils s’interdisent tout ce qui est GPLv3.

Et de manière générale ils préfèrent quand il y n’y a pas de copyleft.

Mais ils sont bien obligés de fournir un bash et un GNU make à cause d’à quel point ça domine, mais ils fournissent un bash et un GNU make du début du siècle.

Mais rien ne devrait les empêcher de corriger le bug du tableau vide considéré comme une variable inexistante… Ça c’est, de mon expérience, le bug le plus handicapant du bash de macOS.

Un bash avec une implémentation incomplète des tableaux, c’est un bash primitif.

ce commentaire est sous licence cc by 4 et précédentes

Aucune idée, mais notre implémentation de “Pre-Compiled Header” avec CMake et le backend “GNU Make” fonctionnait partout où il y a GNU Make sauf sur le GNU Make de macOS. Le dysfonctionnement avait tout les symptômes d’un bug ou d’une déficience dans l’échappement de chaînes de caractères. Maintenant que CMake a un méchanisme intégré pour faire du PCH on l’utilise, et ça marche pour le GNU Make de macOS, je ne serai pas surpris si CMake faisait des contournements spécifiques pour macOS…

ce commentaire est sous licence cc by 4 et précédentes

Bash est devenu ipso facto grâce à l'installation de git sur windows la stack de dév. pour un devops la plus portable.

Oui, sous Windows et Linux, c’est maintenant très proche.

Mais pas sous macOS, qui a un bash de 2007, qui est très primitif, et c’est un enfer. Par exemple si ma mémoire est bonne, utiliser "${@}" dans une fonction avec set -u déclenche l’arrêt de l’exécution si la fonction est appelée sans paramètre, au lieu de retourner un tableau vide. Puisque tu parles de make, leur make est tout aussi ancien, quasiment 20 ans, et ça peut te planter un couteau dans le dos quand tu ne t’y attends pas.

La Gnu/Basherie ultime que déteste la secte concurrent de la mienne qu'est le POSIX-shismes ce sont les tableaux.

Utiliser bash dans un script bash ce n’est pas sectaire. La secte c’est de réclamer que tout programme soit polyglotte.

Ça m’est insupportable quand j’écris un programme en choisissant bash comme langage et en mettant comme shebang #! /usr/bin/env bash et quelqu’un vient et propose un pull-request sabotant tout le code, le transformant de manière très alambiqué et fragile pour le rendre polyglotte avec d’autres langages.

Il est tout autant légitime d’écrire un programme en langage bash qu’il est légitime d’écrire une programme en langage python ou ruby. Ton script est écrit en bash, pas en posix-shell. Utiliser un autre interpréteur pour l’exécuter est une faute de l’utilisateur, pas la tienne. Ton script déclare explicitement que bash doit être utilisé pour l’interpréter, tout système qui utiliserait un autre interpréteur pour un autre langage serait en faute, et le bug ne serait pas à rapporter à toi mais à celui qui a implémenté l’usage d’un autre interpréteur que bash pour bash sur son système.

Je sais pas comment font les développeurs de bash à savoir que depuis plus de 35 ans tout leur travail est systématiquement dénigré, diffamé, et rejeté par une secte de fanatiques du script polyglotte qui ont fait de leur trouble obsessionnel compulsif à ne jamais utiliser une seule contribution des développeurs de bash un code moral absolu. T’imagines tu développe pendant 35 ans un langage pour simplifier la vie des gens et t’as des gens qui font tout pour ne jamais en profiter car ce serait péché ?

Personnellement j’aime bien écrire des scripts polyglottes pour le défi (je pourrai écrire un journal sur l’un d’eux, d’ailleurs), mais je ne vais pas me plaindre auprès d’un tiers parce qu’un script bash utilise le langage bash… Ce serait aussi stupide que se plaindre qu’un script python est écrit en python et ne fonctionne pas avec l’interpréteur ruby…

Ah, au fait, une partie de la secte soit-disant POSIX qui réclame de saboter les scripts bash est en fait la secte de fanboy macOS sous couverture qui redirige sa souffrance causée par la faillite d’Apple à fournir des outils à jour envers tout le reste du monde pour ne pas regarder en face la relation abusive dans laquelle il est enfermé, qui ne peut briser son déni d’être victime d’un abuseur qui l’enferme dans une relation amour-haine qui le détruit, et qui fait payer à tout les autres cette souffrance pour protéger son abuseur.

ce commentaire est sous licence cc by 4 et précédentes

Q Je ne suis pas graphiste ni informaticien, je cherche un logiciel pour faire des retouches photo simples
R Utilise Gimp c'est libre et c'est super bien

J'ai eu le même sentiment récemment quand j'ai tenté d'utiliser Blender.

Quand on conseille un logiciel de niveau professionnel à un débutant parce que c'est une vitrine du logiciel libre, on ne rend service ni à la personne ni à la communauté du logiciel libre; mais il n'existe pas forcément de logiciel alternatif à conseiller.

Oui, le problème c’est qu’on refile des applications métiers à des gens qui cherchent autre chose.

Comme c’est gratuit, on leur file la machine-outil, alors qu’ils ont besoin d’un tournevis.

Les applications métiers propriétaires peuvent être encore plus difficiles à utiliser mais sont très chères donc personne ne leur propose ça. C’est un peu le paradoxe, le bricoleur du dimanche va voir l’expert qui fait ça tous les jours, l’outil de l’expert est gratuit, donc il propose son outil, alors que ce n’est pas adapté au besoin.

C’est comme si le bus à accordéon était au même prix que la mobylette, et quand une maman cherche un moyen de locomotion autonome pour son ado qui va au lycée, elle demande à son cousin chauffeur de bus son avis et que le cousin chauffeur de bus lui répond quel est le meilleur modèle de bus à accordéon du moment.

L’autre problème c’est que puisque la machine outil est gratuite, pourquoi développer un tournevis? Il existe certainement des outils plus simples que GIMP, mais puisque je suis quelqu’un qui pense à très long terme, j’ai investi le temps d’apprentissage de GIMP il y a 20 ans et ça m’a économisé beaucoup de temps depuis 20 ans, et donc bah ma référence c’est GIMP. J’ai déjà vu des outils plus simples, mais puisque j’ai investi GIMP, même pas je les regarde, donc même pas je peux les conseiller, ce qui est aussi ingrat pour les développeurs qui se donnent la peine de faire des outils plus simple. Le serpent se mord la queue.

ce commentaire est sous licence cc by 4 et précédentes

C’est très suspect mais pas surprenant, certains sont à la fois très créatifs et absurdement audacieux pour obtenir des accès.

J’ai vu des gens se faire embaucher et commencer à faire des demandes aussi osées sous des motifs très divers (et toujours débiles), et ce très rapidement dès leur arrivée… Une méthode peut être de faire signer un contrat avec un prestataire pour un service qui ne requiert aucun accès et ensuite demander que soient transférés les accès au dit prestataire, ou encore quelqu’un d’autre dont le rôle est d’auditer qui a accès à quel dossier peut prétendre que pour cet audit il doit lui-même avoir accès au contenu de tous ces dossiers, etc. Ce genre de personnes ont vraiment les rôles et les fonctions qu’ils disent avoir, contrats de travail qui vont avec, etc.

Je ne crois même pas à l’incompétence ici.

ce commentaire est sous licence cc by 4 et précédentes

En parlant de tricot, il y a aussi l’étiquette couture qui recoupe une partie des articles de l’étiquette tricot, mais pas que ! 🙂

ce commentaire est sous licence cc by 4 et précédentes

Si Google est toujours celui qui décide et qui a le dernier mot si une application peut être installée, que ce soit en utilisant le Play Store ou F-Droid (par exemple), ça signifie qu’il n’y a qu’une seule place de marché et que les applications Play Store et F-Droid ne sont que des interfaces différentes utilisant elles-mêmes possiblement des interfaces différentes dans ce même marché unique contrôlé par un seul acteur.

Je ne vois pas comment on peut se défendre de position dominante dans ce cas.

C’est comme si un seul acteur avait décision et dernier mot sur la capacité d’encaisser quels produits alimentaires dans tous les distributeurs alimentaires, que ce soit chez Auchan, Carrefour, Casino, Intermarché, Super U, Monoprix, Prisunic, Mammouth (pardon je m’égare), toutes leurs franchises, et ta petite épicerie de quartier.

De plus si les distributions GMS et les AOSP ne sont plus compatibles (puisqu’une application compatible AOSP ne pourra pas être installée sur GMS), alors il sera plus difficile de se défendre de vente liée. Un client acheteur de téléphone pourra se plaindre que le système préinstallé qu’il n’a pas choisi n’est pas celui qu’il veut, et que cela entrave son activité blablabla parce qu’il est matériellement (pas au sens physique) empêché d’utiliser les logiciels pour lequel il a acheté ledit téléphone à cause des restrictions du système qui lui a été imposé par vente liée.

Ça soulève aussi la question de la dégradation de service : tu as un téléphone sous Android N, tu renouvelles ton équipement avec un téléphone sous Android N+1 et paf, ton activité n’est plus possible parce que tu as besoin de tel logiciel que Google ne veut pas voir.

Il n’y a pas vraiment de Embrace, puisque Google est à l’origine d’Android, mais il y a bien Extend, et Extinguish.

ce commentaire est sous licence cc by 4 et précédentes

Je pense que c’est pareil que CUDA, c’est spécifique à la version de ROCm.

Par exemple quand on installe PyTorch on précise si on veut télécharger la version pour ROCm 6.3 ou 6.4, exactement comme pour CUDA:
https://pytorch.org/get-started/locally/

D’ailleurs ta question soulève un point très important. Beaucoup disent et j’en fait partie qu’acheter une Nvidia en aveugle est moins risqué qu’une AMD en terme de « est-ce que ça marche au déballage ? », mais il ne faut pas penser que c’est magique chez Nvidia non-plus.

En gros contrairement à AMD quand on achète une carte Nvidia neuve on peut supposer que ça va marcher, par contre quand on achète une Nvidia d’occasion, il n’y a que pour OpenCL que l’on peut supposer que ça va marcher. Mais quand on veut utiliser CUDA c’est pas beaucoup moins risqué d’acheter une Nvidia d’occasion que d’acheter une AMD d’occasion pour utiliser ROCm : le véritable obstacle ne sera pas que le matériel ne soit pas dans la liste des cartes prises en charge, mais que le logiciel que vous voulez utiliser n’est pas compatible avec le pilote de votre carte, à cause de sa version ancienne.

Il reste une différence qui n’est pas du fait d’Nvidia directement mais de son écrasante domination, comme on le voit sur la page PyTorch évoquée, il y a des gens qui prennent le temps de maintenir leur bibliothèques pour les vieilles versions de CUDA, alors que cette main d’œuvre communautaire est absente pour ROCm, à cause d’un manque de masse critique je suppose. C’est ça qui fait qu’acheter du Nvidia d’occasion est quand même moins risqué qu’avec AMD, mais c’est un effet de bord.

Par exemple l’autre jour j’ai voulu utiliser un logiciel qui utilise PyTorch et qui requiert une taille de VRAM conséquence, et ça tombait bien j’avais sous la main quelques Nvidia puissantes d’ancienne génération : c’était des modèles de calcul uniquement (pas de sortie graphique), avec toute la VRAM nécessaire et la puissance nécessaire et même plusieurs puces de calcul par carte… Mais la version de CUDA était trop vieille pour PyTorch, et les anciennes versions de PyTorch que j’ai trouvé dans les archives ne fonctionnaient plus avec le logiciel que je voulais utiliser. Ce qui est complètement absurde parce que le matos était parfaitement taillé pour la tâche… Au final comme j’avais pas envie d’acquérir de nouveau matériel, j’ai fait chauffer le CPU et le calcul a duré grave plus longtemps, alors que j’aurai pu y atteler plusieurs cartes de calcul Nvidia que j’avais dans le tiroir…

ce commentaire est sous licence cc by 4 et précédentes

un compte non rémunéré par l'exposition de tes données personnelles

Les pixels et autres trucs du genre sont bloqués, ce qu’il faut faire de toute façon même quand on n’a pas facebook parce que les trackers n’ont pas besoin que les gens aient un compte facebook de toute façon.

ce commentaire est sous licence cc by 4 et précédentes

Voici à quoi ressemblent ces formulaires. Je ne suis pas allé jusqu’au bout car après ça ils précisent bien de ne pas continuer si on ne veut pas vérifier son identité, donc je me suis arrêté là.

On voit d’ailleurs que les publicités à caractère politique ne sont pas les seules publicités réglementées, il y a pour le moment 4 options de publicité réglementée :

• Enjeu social, électoral et politique
• Logement
• Emploi
• Produits et services financiers

Il est donc possible que ce formulaire soit conservé, mais que lorsque tu cocheras « Enjeu social, électoral et politique », Facebook te dira que tu ne peux pas continuer.

ce commentaire est sous licence cc by 4 et précédentes

Je pense que vous n’avez pas compris de quoi il s’agit.

Il ne s’agit pas ici de Facebook qui mettrait en avant ses opinions politiques, ils le font certainement, mais ce n’est pas le sujet.

Il s’agit ici d’un type de catégorie de publicité qu’en tant que client de Facebook tu peux utiliser.

Imagine que pendant les élections présidentielles tu publies un article sur ton blog intitulé « Jean-Luc Mélenchon a changé d’avis sur le voile » ou « Marine Le Pen a changé d’avis sur les chats » ou encore « J’épluche le programme du parti animaliste ».

Maintenant imagine que tu veuilles mettre en avant ton article sur Facebook et que tu veuille payer une publicité à Facebook. Tu crées une publication qui introduit ton article et qui contient le lien de ton article. Tu cliques sur le bouton « Booster la publication ». Facebook te redirige vers le formulaire de création de publicité, et dans ce formulaire tu as une case à cocher pour indiquer si ta publicité est à caractère social ou politique ou un truc comme ça.

Si tu coches cette case, tu dois vérifier ton identité de financeur (je crois que ça te demande ta carte d’identité), et ton nom en tant que financeur peut éventuellement être indiqué à côté de ta publication quand elle est affichée dans le fil d’actu des gens.

Ce qui se passe ici c’est que le parti LFI ne pourra pas faire une publicité pour mettre en avant son programme ou pour démonter le programme du RN, et le RN ne pourra pas faire une publicité pour mettre en avant son programme ou pour démonter le programme de LFI, et le parti animaliste ne pourra plus faire de publicité pour ses photos de chatons.

Donc oui il y a un moyen très simple de les croire, c’est de créer une publication à caractère politique et essayer de la « booster » en payant un publicité pour ça.

Ce que j’en comprends c’est que la catégorie « publicité à caractère politique » va probablement disparaître du formulaire, ce qui permettra plus de payer une publicité à caractère politique en le déclarant. Avant on pouvait déjà ne pas le déclarer mais tu pouvais le déclarer. Maintenant si tu veux vraiment faire ta publicité politique tu ne pourras pas le déclarer de toute façon, mais là c’est toi qui fraudera en décidant de faire ta pub quand même alors que tu ne peux pas le déclarer.

Donc si tu veux respecter la loi tu ne pourras pas faire de telle publicité sur Facebook tout court. Tu pourra le faire, mais c’est toi qui ne respectera pas la loi, parce que de toute façon Facebook a décidé que c’était déjà trop compliqué à gérer pour lui.

ce commentaire est sous licence cc by 4 et précédentes

En fait ce n’est pas nouveau malheureusement, y compris avec des appareils photos professionnels à plusieurs K€…

Ici un article en 2011: https://www.hdcamteam.com/2011/07/10/report-cmos-ccd-cameras-damaged-by-laser/

Ou celui-là en 2013 avec une vidéo qui marche encore, contrairement à l’article précédent : https://photofocus.com/photography/beware-lasers-can-kill-your-cameras-sensor/

Ladite vidéo est dite être plus ancienne que l’article (probablement celle mentionnée dans l’article de 2011) et a été prise avec un Canon 5D Mark II, un modèle sorti en 2008.

En effet j’ai entendu des histoire comme ça depuis ces époques-là, c’est comme ça que j’ai retrouvé ces articles, en cherchant de mémoire « laser canon camera damaged » sur DDG). J’avais souvenir d’une autre vidéo mais celle-là montre bien le problème aussi.

ce commentaire est sous licence cc by 4 et précédentes

La réalité qui fait mal c’est que si ton activité économique dépend du calcul sur GPU et que tu n’as pas des milliers de machines, il faut acheter du Nvidia.

Krita AI Diffusion est dans la même situation que Blender et d’autres logiciel de ce type : ça implémente à la fois CUDA (NVidia) et ROCm (AMD), mais indépendamment des efforts de Krita, l’écosystème CUDA est plus mature et la prise en charge matérielle est beaucoup plus large. Mais Nvidia çapucépalibre.

Beaucoup d’outils IA fonctionnent sur ROCm aussi, mais il faut aligner les planètes et sacrifier une chèvre un soir de pleine-lune. ROCm rattrape son retard mais pour choisir ROCm il faut bien savoir ce qu’on fait et acheter très précisément son matériel.

Après CUDA c’est pas la panacée non-plus, leurs pilotes sont par génération donc dès que ta carte est de la génération précédente ça commence à poser problème, mais au moins tu n’as pas de problème entre deux produits de la même génération (hors limitations matérielle comme la taille de la mémoire).

C’est beaucoup moins risqué d’acheter une carte Nvidia en aveugle pour faire du calcul.

ce commentaire est sous licence cc by 4 et précédentes

mais c'est dans le même esprit de maximiser les gains sans aucune humanité ou respect du client.

Merci de dire ça, maintenant ça me fait tilt dans ma tête. C’est vrai que je répondais surtout sur le sujet des pilotes de cartes graphiques, et donc mes expériences Intel autres ne me sont pas revenues tout de suite, et j’ai seulement parlé de pratiques anti concurrentielles autour des CPUs parce que c’est la chose la plus objectivement scandaleuse à laquelle je pensais.

Mais ce dont tu me rappelles et qui n’est pas illégal mais vraiment insupportable en parlant de « maximiser les gains sans aucune humanité ou respect du client », c’est la segmentation des produits qui va jusqu’au sabotage. Exemple de choses que j’ai vues :

• Des CPUs 64-bit qui sont vendus comme 32-bits et qu’il faut essayer pour se rendre compte qu’en fait ça marche en 64-bit. J’ai vu ça sur des cartes pour routeur type Soekris (ouh le coup de vieux) avec la gamme de CPUs Intel Atom E6xx.
• Des CPUs qui prennent en charge le PAE mais qui ne déclarent pas la prise en charge (contraignant à recourir à des hacks pour que les distributions acceptent d’installer un noyau PAE). Par exemple le Thinkpad R51 (ordinateur portable grand public) était affecté, avec son Pentium M Dothan.
• Des produits avec le même nom mais qui n’ont pas les mêmes fonctionnalités, comme le Pentium E2200 qui n’a pas de prise en charge de virtualisation mais qui vient avec une puce graphique OpenGL 2.1, ou le Pentium E2200 (même nom) qui prend en charge la virtualisation mais qui ne vient pas avec une puce graphique OpenGL 2.1.
• Les récentes déboires autour de AVX512 où les fonctionnalités sont ajoutées ou retirées selon le produit, la gamme, ou la génération… Ce tableau est éloquent : https://en.wikipedia.org/wiki/AVX-512#CPUs_with_AVX-512

Parce que oui en fait, si certains exemples précédents sont anciens, en fait Intel fait toujours ça.

Les produits Intel sont insupportables sur le marché de l’occasion, tu ne sais jamais vraiment ce que tu vas avoir comme fonctionnalité, et toute cette souffrance est l’effet de leur politique de segmentation des produits.

Alors que quand tu achètes un produit AMD d’occasion, tu sais qu’il y aura toutes les fonctionnalité de l’époque où le produit est sorti, et surtout que, contrairement à ce qui peut se passer avec Intel, tu ne vas pas avoir un produit avec moins de fonctionnalité que les produits plus anciens, ou que le produit de la gamme d’à côté, ou que le produit avec le même nom sur l’étagère d’à côté.

Parce qu’avec AMD tout n’est pas rose (l’exemple du pilote ROCm qui n’est pas universel), mais contrairement à Intel, AMD ne retire pas dans sa génération suivante une fonctionnalité matérielle de la génération précédente, sur des trucs aussi fondamentaux que le PAE, la visualisation, ou des extensions de calcul qui requièrent une recompilation du logiciel si elles sont manquantes.

Cette façon de segmenter le marché est d’ailleurs en train de piquer très fortement avec la fin de Windows 11 et l’omniprésence d’Intel : Windows 11 dit requérir TPM et un processeur double cœur, mais tu tombes fréquemment sur des machines qui ont toutes les fonctionnalité requises (y compris la bonne version de TPM), avec un processeur double cœur comme demandé, mais en fait non, on découvre au dernier moment qu’Intel avait décidé de segmenter ses produits en activant ou désactivant ci ou ça selon le produit et certains ordinateurs sont désormais compatibles Windows 11 et d’autres ne le sont pas, en pure conséquence de ces désactivations arbitraires de je ne sais quoi au moment de la mise sur le marché il y a quelques années.

Intel en occasion c’est une roulette russe, tu ne peux jamais supposer « c’est de telle année, donc ça a au moins telle fonctionnalité ». C’est insupportable.

ce commentaire est sous licence cc by 4 et précédentes

Ah oui c’est vrai ! J’ai ajouté ce paragraphe en dernier juste avant de soumettre à la modération, j’ai été moins vigilant. 😀

ce commentaire est sous licence cc by 4 et précédentes

La commande pour Vulkan est vulkaninfo --summary (ou vulkaninfo si tu veux beaucoup de lignes).
Le pilote Vulkan de base est RADV. Par exemple de mon côté j’ai :

$ vulkaninfo --summary
==========
VULKANINFO
==========

Vulkan Instance Version: 1.3.275


Instance Extensions: count = 24
-------------------------------
VK_EXT_acquire_drm_display             : extension revision 1
VK_EXT_acquire_xlib_display            : extension revision 1
VK_EXT_debug_report                    : extension revision 10
VK_EXT_debug_utils                     : extension revision 2
VK_EXT_direct_mode_display             : extension revision 1
VK_EXT_display_surface_counter         : extension revision 1
VK_EXT_headless_surface                : extension revision 1
VK_EXT_surface_maintenance1            : extension revision 1
VK_EXT_swapchain_colorspace            : extension revision 4
VK_KHR_device_group_creation           : extension revision 1
VK_KHR_display                         : extension revision 23
VK_KHR_external_fence_capabilities     : extension revision 1
VK_KHR_external_memory_capabilities    : extension revision 1
VK_KHR_external_semaphore_capabilities : extension revision 1
VK_KHR_get_display_properties2         : extension revision 1
VK_KHR_get_physical_device_properties2 : extension revision 2
VK_KHR_get_surface_capabilities2       : extension revision 1
VK_KHR_portability_enumeration         : extension revision 1
VK_KHR_surface                         : extension revision 25
VK_KHR_surface_protected_capabilities  : extension revision 1
VK_KHR_wayland_surface                 : extension revision 6
VK_KHR_xcb_surface                     : extension revision 6
VK_KHR_xlib_surface                    : extension revision 6
VK_LUNARG_direct_driver_loading        : extension revision 1

Instance Layers: count = 6
--------------------------
VK_LAYER_INTEL_nullhw             INTEL NULL HW                         1.1.73   version 1
VK_LAYER_MANGOHUD_overlay_x86_64  Vulkan Hud Overlay                    1.3.0    version 1
VK_LAYER_MESA_device_select       Linux device selection layer          1.3.211  version 1
VK_LAYER_MESA_overlay             Mesa Overlay layer                    1.3.211  version 1
VK_LAYER_RENDERDOC_Capture        Debugging capture layer for RenderDoc 1.3.131  version 27
VK_LAYER_VKBASALT_post_processing a post processing layer               1.3.223  version 1

Devices:
========
GPU0:
    apiVersion         = 1.3.289
    driverVersion      = 24.2.8
    vendorID           = 0x1002
    deviceID           = 0x7480
    deviceType         = PHYSICAL_DEVICE_TYPE_DISCRETE_GPU
    deviceName         = AMD Radeon PRO W7600 (RADV NAVI33)
    driverID           = DRIVER_ID_MESA_RADV
    driverName         = radv
    driverInfo         = Mesa 24.2.8-1ubuntu1~24.04.1
    conformanceVersion = 1.3.0.0
    deviceUUID         = 00000000-8300-0000-0000-000000000000
    driverUUID         = 414d442d-4d45-5341-2d44-525600000000

GPU1:
    apiVersion         = 1.3.289
    driverVersion      = 0.0.1
    vendorID           = 0x10005
    deviceID           = 0x0000
    deviceType         = PHYSICAL_DEVICE_TYPE_CPU
    deviceName         = llvmpipe (LLVM 19.1.1, 256 bits)
    driverID           = DRIVER_ID_MESA_LLVMPIPE
    driverName         = llvmpipe
    driverInfo         = Mesa 24.2.8-1ubuntu1~24.04.1 (LLVM 19.1.1)
    conformanceVersion = 1.3.1.1
    deviceUUID         = 6d657361-3234-2e32-2e38-2d3175627500
    driverUUID         = 6c6c766d-7069-7065-5555-494400000000

Comme pour moi ça peut éventuellement lister une seconde « GPU » (llvmpipe) qui est en fait une implémentation CPU de secours s’il n’y a pas de GPU prenant en charge Vulkan (les deux s’affichent quand même).

Il n’y a pas de raison que ta distribution n’installe pas le pilote RADV, il est fourni en standard depuis très longtemps maintenant. Il est possible que la commande vulkaninfo ne soit pas installée, mais le pilote devrait déjà être là.

En quelque sorte Vulkan fait double emploi avec OpenGL dans le sens que ça a la même fonction : être utilisé par des applications pour afficher des choses à l’écran. Mais ça ne fait pas double emploi dans le sens que certaines applications utilisent OpenGL, et d’autres applications utilisent Vulkan, donc il faut avoir les deux, ce n’est pas interchangeable pour l’utilisateur.

Pour info, la commande standard pour vérifier OpenGL est glxinfo -B sous X11 (-B pour brief, entrer seulement glxinfo pour avoir la sortie bavarde), et eglinfo -B sous Wayland (eglinfo pour la sortie bavarde). Ici ta commande inxi râle un peu parce que tu es sous Wayland mais tu n’as que glxinfo d’installé et pas eglinfo. Comme mentionné tu peux entrer inxi --recommends pour en savoir plus sur les outils utilisables par inxi.

Par exemple:

$ glxinfo -B
name of display: :1
display: :1  screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: AMD (0x1002)
    Device: AMD Radeon PRO W7600 (radeonsi, navi33, LLVM 19.1.1, DRM 3.63, 6.8.0-63-generic) (0x7480)
    Version: 24.2.8
    Accelerated: yes
    Video memory: 8192MB
    Unified memory: no
    Preferred profile: core (0x1)
    Max core profile version: 4.6
    Max compat profile version: 4.6
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.2
Memory info (GL_ATI_meminfo):
    VBO free memory - total: 3476 MB, largest block: 3476 MB
    VBO free aux. memory - total: 115256 MB, largest block: 115256 MB
    Texture free memory - total: 3476 MB, largest block: 3476 MB
    Texture free aux. memory - total: 115256 MB, largest block: 115256 MB
    Renderbuffer free memory - total: 3476 MB, largest block: 3476 MB
    Renderbuffer free aux. memory - total: 115256 MB, largest block: 115256 MB
Memory info (GL_NVX_gpu_memory_info):
    Dedicated video memory: 8192 MB
    Total available memory: 136967 MB
    Currently available dedicated video memory: 3476 MB
OpenGL vendor string: AMD
OpenGL renderer string: AMD Radeon PRO W7600 (radeonsi, navi33, LLVM 19.1.1, DRM 3.63, 6.8.0-63-generic)
OpenGL core profile version string: 4.6 (Core Profile) Mesa 24.2.8-1ubuntu1~24.04.1
OpenGL core profile shading language version string: 4.60
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

OpenGL version string: 4.6 (Compatibility Profile) Mesa 24.2.8-1ubuntu1~24.04.1
OpenGL shading language version string: 4.60
OpenGL context flags: (none)
OpenGL profile mask: compatibility profile

OpenGL ES profile version string: OpenGL ES 3.2 Mesa 24.2.8-1ubuntu1~24.04.1
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20

Et pour OpenCL la commande est clinfo -l (ou clinfo quand on aime scroller), commande qui n’est généralement pas installée par défaut. Le pilote rusticl n’est pas toujours installé par défaut, sur Ubuntu par exemple c’est le paquet mesa-opencl-icd, et comme il est encore expérimental il faut généralement mettre une variable d’environnement explicite pour l’activer.

Par exemple de mon côté sur Ubuntu 24.04, avec à la fois ROCm et RustiCL :

$ RUSTICL_ENABLE=radeonsi clinfo -l
Platform #0: AMD Accelerated Parallel Processing
 `-- Device #0: gfx1102
Platform #1: rusticl
 `-- Device #0: AMD Radeon PRO W7600 (radeonsi, navi33, LLVM 19.1.1, DRM 3.63, 6.8.0-63-generic)

Pour résumer il est probable que ta distribution installe par défaut RadeonSI pour OpenGL, RadeonSI pour VA-API, ainsi que RADV pour Vulkan, et propose dans ses dépôts RustiCL RadeonSI pour OpenCL. Les noms de paquets contiennent généralement le nom mesa et l’API (par exemple vulkan) sans préciser plus car ils fournissent aussi les pilotes des autres fabricants. Par exemple sur Ubuntu : libegl-mesa0 libglx-mesa0 libglapi-mesa mesa-vulkan-drivers mesa-va-drivers mesa-opencl-icd.

Il est assez rare que ROCm soit fournit dans les dépôts, et pour GIM c’est pas la peine d’y penser.

Normalement ta distribution te fourni déjà les pilotes OpenGL et Vulkan sans que tu ne fasses rien (ce serait grave si ce n’était pas vrai).

J’ai envie de dire que si tu ne sais pas ce que tu as, c’est que tu n’as pas besoin de ce que tu n’as pas. 😉️

ce commentaire est sous licence cc by 4 et précédentes

Pour illustrer la dépêche je me suis amusé à coller sur une pile de cartes graphiques un autocollant LinuxFr récupéré sur le stand au dernier salon OSXP, et pour le fun je n’ai mis que des cartes graphiques pro mais qui ont toutes une histoire rigolote dans le sens où… il y a systématiquement un piège. 🤫

La Radeon PRO W7600 noire, c’est une RDNA 3 (donc très récente), que j’ai acheté exprès en gamme « PRO » pour être certain d’avoir ROCm (pour le calcul HIP). Mais je n’avais pas besoin d’un monstre, et je voulais une simple-slot, donc j’ai pris celle-là, une petite pro, mais une pro quand même. Je m’étais dit (à tort) que la gamme « PRO » allait me garantir la prise en charge. En fait non, ROCm n’est officiellement pas pris en charge sur cette carte, jugée trop bas de gamme j’imagine. Le pilote est quand même actif, mais Blender Cycle ne produit rien de correct et Darktable se vraque dès que j’active OpenCL avec ROCm. Bon, j’ai un ThreadRipper à côté donc c’est pas très grave, mais ça rappelle que pour le calcul HIP, il faut vraiment bien sélectionner son matériel. 🧐️

La FirePro S7510 noire et blanche est le seul modèle publiquement pris en charge par l’ancien pilote GIM de virtualization GPU. Elle existe en simple GPU ou en double GPUs (deux puces graphiques sur la carte, comme s’il y avait deux cartes dans le PC), celle-ci est la simple GPU. En fait à l’époque AMD avait 3 modèles de cartes virtualisables je crois, mais la S7150 (simple ou double GPU) était la seule publiquement disponible, et le pilote GIM public ne prenait que celle-ci en charge. J’imagine que les autres modèles étaient réservés à certains marchés (type serveur de jeu Google Stadia) et que les clients avaient accès à un pilote non public. Évidemment le pilote GIM pour cette carte date d’il y a 6 ou 8 ans… 🙃️

La Radeon PRO V320 bleue est une carte conçue pour le poste de développement Google Stadia (chez le développeur), donc pas la supposée carte virtualisable sus-mentionnée. Elle n’est pas sensée être sur le marché, donc si par chance les pilotes graphiques (OpenGL et Vulkan) fonctionnent, ce n’est pas la peine d’aller chercher du support chez AMD pour autre chose (ROCm ou autre). 😅️

Et la dernière avec le ventilateur rouge, c’est une FirePro S10000, c’est une carte double GPUs de génération GCN1 et pour le coup c’est une très haut de gamme. Mais puisqu’elle est de génération GCN1 c’est donc une carte qui n’a aucun pilote de calcul propriétaire qui (même obsolète) fonctionnerait encore aujourd’hui avec le pilote amdgpu sur un noyau actuel. Il faut revenir à fglrx et un noyau et une distribution qui date de Mathusalem pour ça. 😭️ Avec le pilote libre Linux amdgpu, Mesa RustiCL est son seul espoir de faire du calcul aujourd’hui sur une distribution récente. 🤪️

Donc il y a marqué « PRO » partout sur toutes ces cartes, mais en fait c’est insuffisant pour toutes de ces cartes : elles sont ou bien trop petites, ou trop vieilles, ou trop confidentielles… Bon c’est vrai que j’ai fait exprès de les rassembler pour la photo. 😏️

Si vous avez d’autres besoins qui ne peuvent être satisfait ni par OpenGL, ni par Vulkan, ni par VA-API, ni par l’OpenCL de RustiCL… (en gros, ROCm ou GIM), sélectionnez vos cartes vraiment très soigneusement. 👀️

Mais si comme 99% des gens tout ce que vous faites c’est du rendu (vidéo, jeu…), n’importe quelle carte AMD fonctionne du tonnerre même en la choisissant les yeux fermés, et ce même avec des cartes très confidentielle : par exemple les pilotes Linux et Mesa prennent même en charge la puce graphique de la PlayStation 5, cette puce s’étant retrouvée sur la carte de minage BC-250 🫣️ (et j’ai vérifié [1],[2] 😎️).

ce commentaire est sous licence cc by 4 et précédentes

Trouvées en me relisant après publication…

Ici :

- le pilote RADV fournit par votre distribution
+ le pilote RADV fourni par votre distribution

Et là:

- PAL et ORCA était des portages du pilote OpenCL
+ PAL et ORCA étaient des portages du pilote OpenCL

ce commentaire est sous licence cc by 4 et précédentes

Aujourd’hui Intel est devenu un concurrent plus sérieux, non-seulement leurs puces intégrées ont des performances correctes, mais ils produisent aussi désormais des cartes graphiques (au format carte, donc). Je range leurs pilotes dans la même case qu’AMD en terme d’intégration et de fonctionnalité. Comme on dit, ça marche au déballage. Je ne sais pas trop qui est le plus collaboratif entre AMD et Intel.

J’ai basculé de Nvidia à ATI en janvier 2008 en achetant une HD 2600 PRO AGP [preuve], c’était juste après le rachat d’ATI par AMD et le début de la publication des spécifications des cartes ATI et le début de l’aventure RadeonHD. Cet achat a été un acte politique. J’avais racheté cette carte à un camarade de promo qui avait fait une erreur d’achat (j’imagine qu’il avait confondu AGP/PCIe). Depuis j’achète systématiquement du AMD neuf pour la carte graphique de ma station de travail.

Je n’aime pas beaucoup Intel pour leurs pratiques anti-concurrentielles, donc j’achète mes CPUs neufs chez AMD, et je n’aime pas Nvidia pour sa politique de fermeture, donc j’achète mes GPUs neufs chez AMD.

La dernière fois que j’ai donné de l’argent à Nvidia c’était pour une Geforce 4 PCI et une Geforce 6600 AGP. C’était pour faire un triple écran, mais Nvidia l’a cassé quelques semaines plus tard en séparant le pilote en deux pour chacune des cartes, et les pilotes étaient incompatibles, c’était soit la Geforce 4, soit la Geforce 6600.

J’évite Nvidia autant que je peux. Parfois mes ordis portables ont du Nvidia mais c’est parce que j’achète systématiquement des Thinkpads d’occasion et que donc ça reflète l’état du marché d’il y a quelques années, et je ne me permet ces cartes Nvidia que parce que c’est d’occasion. Et c’est un enfer. Je rencontre les mêmes problèmes que je rencontrais dans les années 2000, ça donne une sensation très bizarre. L’expérience Nvidia c’est comme si tu vivais encore à l’époque de MSN, de Windows XP, des forfaits téléphone 2h et 30 SMS à 30€/mois et d’Alizée qui tourne en boucle à la radio, mais avec des performances graphiques actuelles. En 2021 je racontais que j’avais dû modifier le fichier xorg.conf pour faire marcher une Nvidia comme si on était encore au début des années 2000, mais après 2020. Nvidia c’est l’expérience des années 2000 mais en plus rapide. Le futur avec Nova et NVK devrait changer la donne, heureusement, il est plus que temps…

ce commentaire est sous licence cc by 4 et précédentes