Thomas Debesse a écrit 3682 commentaires

1. où est documenté le format de [Thumbnailer Entry] ?

Aucune idée, j’ai simplement imité les fichiers que j’ai trouvé dans mon système.

J’ai l’habitude d’écrire ce genre de script et avec le temps je recopie mes copier-coller :

• https://github.com/illwieckz/crunch-thumbnailer
• https://github.com/illwieckz/darktable-thumbnailer

La première fois que j’en ai écrit un c’était il y a 11 ans…

1. pourquoi les noms des fonctions commencent-ils par un souligné ?

Pour ne pas me prendre la tête et décharger la charge mentale en étant certain que je n’entre pas en conflit avec des outils standard ou des primitives du shell comme help, test, etc. Je fais souvent comme ça pour les petits scripts où les fonctions ne sont formé que d’un seul mot. Dès que je fais des scripts un peu plus conséquent mes fonctions utilisent au mois deux mots (et dans ce cas je m’y tiens) et donc le problème ne se pose plus, par exemple dans un script plus large je nommerai la fonction printHelp.

1. c'est quoi exactement le dialecte de Lisp utilisé pour contrôler Gimp ?

Aucune idée. Il y a beaucoup de culte du cargo dans ce genre de script.

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

Lancer de telles usines cela reste cher et long.

Carrément, c’est pour ça que la Chine s’y est mis il y a 15 ans. Ce sont des chantiers similaires au nucléaire civil ou le TGV, qu’on a réussi à mener à bien par le passé.

D'où l'intérêt de le faire au niveau européen, cela ouvre des horizons et garanties plus larges et évitant les redondance.

Les projets Européens c’est à double tranchant. Faire travailleur plusieurs pays sur un même projet c’est casse-gueule. Ça marche avec l’ESA, mais on voit par exemple que dans l’armement ça fait perdre du temps à tout le monde.

L’avantage de l’informatique c’est que c’est modulaire, et faire travailler des pays différents sur un produit différent a plus de chance de succès. Un pays qui fait des CPUs, un pays qui fait des mémoires, un pays qui fait des GPUs… Ça garantie que chaque pays n’ait pas besoin de « tirer la couverture à lui » à l’intérieur même du projet et élimine les conflits afférents et permet de s’y donnant à fond, tout en garantissant une collaboration par la seule dynamique de marché : les uns achetant mutuellement aux autres les pièces qu’ils ne produisent pas eux-même.

On peut par exemple imaginer un PC 100% européen avec un CPU 100% français, de la RAM 100% italienne, un SSD 100% allemand, un GPU 100% espagnol sur une carte-mère 100% belge, par exemple. Chacun s’assure ainsi un haut niveau de souveraineté sur un produit essentiel, tout en garantissant un levier de négociation décisif sur les produits pour lesquels la souveraineté n’est pas assurée par la production intérieure.

Pour le coup comme le mentionne Aldebaran dans son commentaire plus bas, la Hollande avec ses machines de lithographie montrent l’exemple. Si plusieurs pays ont une domination sur un produit essentiel de manière à ce que cela créée un marché d’échange, cela augmente le niveau de souveraineté de chacun : par la production intérieure d’abord, et ensuite parce que cette production intérieure permet et encourage (sinon contraint) la négociation entre les parties. La garantie de la collaboration de la partie dont on dépend participe aussi à la souveraineté.

On pourrait déjà commencer à produire des carte-mères…

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

Je me rends compte que cet article de 2021 du Comptoir du Hardware sur les QNAP Zhaoxin donne un lien vers un autre article de 2020 qui partageait une information de Zhaoxin qui prévoyait de sortir des cartes graphiques dédiées en 2021. Bon ce n’est pas arrivé, mais les puces graphices Zhoxin existent bien comme puce intégrée dans les CPUs. L’article fait aussi des pronostiques sur la possible technologie graphique S3 (certains se souviendront des S3 Chromes…), en précisant que si Via a vendu S3 à HTC, Via auraient conservé une licence S3… Je creuserai tout ça, pour le moment ce n’est que du pronostic.

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

On ne peut pas tout faire, et pas tout d’un coup, mais si déjà on avait une usine de RAM en France et une usine de CPUs en Italie, ou l’inverse, ça irait déjà mieux… Et avoir une usine en France ne signifie pas se limiter au marché français, on vend bien du champagne jusqu’au bout du monde…

Ça fait déjà 5 ans que QNAP a introduit du Zhaoxin dans certains de ses NAS (ils ont aussi du AMD, du Intel et du ARM). On peut imaginer vendre des puces française dans des tas de produits sans même commencer à concurrencer le marché du PC traditionnel.

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

Et les DLSS 12 ou 22 seront toujours moins efficaces que ce que fait Apple (et bien d'autres avant) en réduisant la consommation, la complexité des puces et la bande passante mémoire en utilisant les technos PowerVR, un truc européen (anglais, comme ARM)

L’efficacité d’Apple tient essentiellement dans le fait que tout est très intégré et soudé, un peu comme dans une PlayStation ou une Xbox. Ça fait du matériel jetable irréparable, mais les raccourcis pris apportent parfois des gains significatifs comme la bande passante, et aussi comme pour les consoles le logiciel peut faire des suppositions très osées, et possiblement déléguer des tâches au CPU pour suppléer le GPU car la mémoire est partagée.

Mais même dans un Apple, l’architecture PowerVR souffre de ses limitations. Ça reste une architecture tiled renderer comme dans la plupart de nos téléphones et les machins-pi même quand ce sont d’autres marques (par exemple Broadcom a une architecture en tiled renderer, aussi). Cela signifie que même les dernières versions d’OpenGL 4.6 (pourtant l’ancienne techno avant Vulkan) ne peuvent pas être implémentées sans émuler certaines fonctionnalités (en particulier l’extension ARB_texture_barrier d’OpenGL 4.5), et cette émulation requiert d’aller contre l’architecture qui est physiquement incompatible et de perdre les gains apportés par le design. Apple ne s’embête même pas à le faire et se limite à OpenGL 4.1, et ils l’ont déprécié OpenGL de toute façon, c’est pratique. 😁️

On retrouve les mêmes limitations qu’AGX d’Apple dans les MTT S80 de Moore Threads, car tous deux basés sur PowerVR: pas de ARB_texture_barrier commen mentionné, mais aussi des triangles qui ne sont tout simplement pas dessinés (AGX, MTT, PVR). Ce dernier bug est très certainement matériel, dans le design PowerVR lui-même. Le bug se reproduit quelque soit le pilote (asahi, mtgpu et pvr sous Linux par exemple), quelque soit le système d’exploitation (Linux, macOS, je n’ai pas encore testé Windows) et quelque soit l’architecture hôte (x86, arm64, riscv64).

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

De nouveaux venus (Moore Threads, Lisuan Technology)

Il faut aussi compter Zhaoxin pour les graphismes intégrés. Les processeurs Zhaoxin intègrent une puce graphique du même nom. Je ne sais pas quelle est la technologie derrière. Le CPU est un descendant du Via lui-même descendant du Cyrix, je ne serai donc pas surpris si la partie graphique descend de S3 à cause du lien historique entre Via et S3, mais la partie S3 de Via avait été revendue à HTC il y a déjà 15 ans en 2011… Je n’ai donc aucune idée pour le moment. Je possède un KX6000 (un KX-U6780A exactement) et le pilote graphique pour Linux est buggé, GNOME fonctionne mais Unvanquished met les pieds dans un bug du pilote. Je ne l’ai pas testé sous Windows (parce que Windows c’est pénible 😅️). Le pilote zhaoxin est propriétaire, je n’ai pas fait plus de recherches sur le pilote. Je devrais recevoir un KX7000 cette année, avec un pilote plus à jour.

Les Moore Threads, comme les Apple AGX, sont des dérivés de PowerVR et en partagent même certains bugs. Le pilote mtgpu est aussi propriétaire, mais j’y trouve plein de traces de Mesa dedans (ce qui est possible légalement car Mesa est principalement sous licence permissive MIT). Je possède une MTT S80.

Selon Wikipédia, Lisuan Tech aurait été fondé en 2021 par trois anciens employés de S3 Graphics, donc là on retrouvera peut-être un héritage de S3, du moins dans le savoir-faire, puisque je ne sais pas s’ils ont des liens avec HTC.

Je parlerai un peu du MTT S80 dans la dépêche en préparation pour la sortie d’Unvanquished 0.56, mais je prévois dans les prochains mois de développer une série de publications sur le développement informatique chinois (CPUs Zhaoxin, GPUs MTT, etc.). L’avantage de ces technologies chinoises c’est qu’elles sont pensées pour s’intégrer directement avec les technologies existantes (notamment le fait que Zhaoxin soit du x86). Là où la France commence péniblement à envisager du Linux pour ses administrations pour gagner un peu de souveraineté côté logiciel, la Chine fait déjà dans le dur et a déjà ses CPUs et ses GPUS… Et alors que le monde est en pénurie de RAM et de SSD, leurs usines (CXMT et JHICC pour la RAM, YMTC pour les SSD) dont ils ont lancés la construction il y a 15 ans entrent désormais en production (voir la vidéo de Gamers Nexus sur le sujet)…

Le problème c’est que pour la France, passer d’une dépendance américaine à une dépendance chinoise, c’est toujours une dépendance. Donc ces produits peuvent être bienvenus en terme de mise en concurrence, mais ce n’est pas une aubaine en terme de souveraineté, que ce soit de l’américain ou du chinois, c’est kif-kif on reste entièrement dépendant de puissance étrangères avec un risque aussi grand de sanction ou de backdoor. Acheter du américain souverain ou du chinois souverain ne fait pas de nous des souverains, tout comme imiter un modèle ne fais pas de nous des modèles mais des suiveurs. Mais si déjà on était des suiveurs, nous ne sommes que des consommateurs…

Enfin bref, je m’égare, mais si tout se passe bien je devrais entamer une série sur ces technologies dans l’année, du point de vue linuxien. D’ailleurs je serai très intéressé de mettre la main sur une carte Lisuan Tech donc si des gens ont des relations en Chine ça m’intéresse.

À propos de relations en Chine, indépendamment de ces GPUs chinois, et en fait plus difficile à trouver que ces GPUs chinois, je cherche à mettre la main sur la carte mère MS-BA17 (part number 109-S05040-00D). C’est un produit américain vendu exclusivement sur le marché intérieur Chinois, ce commentaire sera peut-être le tout premier commentaire à référencer ces références sur le web occidental (et à remonter dans vos recherches), trois ans après la mise sur le marché du produit en question. Rien que pour le fun, vous pouvez essayer de rechercher cela sur les moteurs de recherche occidentaux type Google, DuckDuckGo, Yahoo, Bing ou QWant, vous ne recevrez aucune réponse (vérifiez). Il existe un troisième nom qui a traversé le grand pare-feu mais je le tais pour l’exercice. Je peux fournir des photos pour prouver que le produit existe avec ces références. 😜️

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

Qu'en est il avec les GPU AMD ?

Bonjour, les GPU AMD prennent en charge OpenGL 4.6. Tu peux regarder sur mesamatrix:

• https://mesamatrix.net/

Dans la rubrique “OpenGL”, tu peux cliquer sur “Drivers details” pour dérouler le tableau détaillé.

Toutes les cartes AMD GCN et RDNA prennent en charge OpenGL 4.6, et il me semble aussi que les plus anciennes TeraScale 2 et TeraScale 3 prennent aussi en charge OpenGL 4.6 (TeraScale 2 c’est l’année 2009).

quid des GPU intégrés, peuvent-ils le faire (je n'en doute pas, mais lesquels)

Tous les GPUs intégrés AMD (appelés APUs) proposent exactement les mêmes fonctionnalités que leurs homologues de bureau sur carte. La différence est le nombre de transistors et d’unités de calcul implémentées. C’est similaire à ce qui se passe du côté des CPUs, tu peux avoir un petit CPU Ryzen avec 6 cœurs ou un gros CPU ThreadRipper avec 64 cœurs, et tu peux avoir une petite puce ou une grosse puce graphique. Ce qui change est donc le nombre d’unités de calcul, la fréquence (et donc la consommation électrique), le type de mémoire vive et comment la mémoire est connectée (essentiellement une affaire de fréquence et de bande passante), le nombre de lignes PCI express (là encore de la bande passante) mais en terme de fonctionnalités c’est pareil. Pour une même génération, la différence entre une puce intégrée et une grosse carte graphique de chez AMD est uniquement la performance.

AMD a abandonné sa gamme mobile Imageon en 2009 en la revendant à Qualcomm dont le nom de la puce adreno et un anagramme de radeon en clin d’œil à leur origin… Donc depuis 2009 il n’y a plus de puce basse consommation AMD qui diffère techniquement des puces AMD haute performance.

Ces puces mobiles devenues “adreno” qui sont similaires à ta puce Mali (et qu’on retrouve aussi dans des SoC ARM) ne sont plus produites par AMD depuis 17 ans. Les puces adreno ont des limitations similaires aux puces Mali, mais ce ne sont pas des puces AMD. Tu peux prendre une puce AMD les yeux fermés et tu auras OpenGL 4.6.

mon "pc" actuel avec un rk3588 (Arm Mali) implémente la dernière version de Vulkan, mais OpenGL n'est qu'en version 3.1 parce que les fonctionnalités d'OpenGL 4.3, ou plus, ne sont pas fondues dans le silicone (c'est ce que je comprends).

Il est possible (je n’ai pas vérifié) que des fonctionnalités soient implémentable mais pas encore implémentées. Pour des raisons pragmatiques et pratiques, Mesa se focalise d’abord sur « le minimum vital » pour que la puce graphique soit utilisable, notamment par les environnements de bureau. Ça veut dire OpenGL 2.1 dès que possible et OpenGL 3.1 aussi vite. OpenGL 3.1 c’est la version de base de l’OpenGL actuel, en quelque sorte toutes les versions supplémentaires ne sont que des collections d’extensions par dessus. OpenGL 2.1 peut être vue comme une version immature mais très proche d’OpenGL 3.1, donc il est peu coûteux d’adapter un logiciel 3.1 pour 2.1. Mesa vise donc ces objectifs en premier. C’est ce qui permet aux distributions de fournir un bureau moderne fonctionnel. Il y a aussi OpenGL ES, mais tu vois l’idée, le but c’est de faire marcher les gestionnaires de connexion et environnements de bureau standards. Une fois que OpenGL 3.1 est implémenté on peut considérer que « le boulot est fait ».

Il est donc tout à fait possible que le Mali rk3588 soit capable de bien plus qu’OpenGL 3.1 mais que Mesa n’ai pas encore implémenté plus. Là encore si on regarde la page mesamatrix dans la colonne panfrost, on voit qu’une seule extension de OpenGL 3.2 est manquante (les geometry shaders), mais que toutes les extensions de 3.3 sont déjà implémentées. Donc dans l’hypothèse où les geometry shaders seraient implémentables, les jour où ils le sont Mesa passera directement de GL 3.1 à GL 3.3.

Comme je le disais, OpenGL 3.1+ sont surtout des extensions, une version n’est déclarée comme prise en charge que lorsque toutes les extensions de cette version sont prises en charge, mais la prise en charge de chaque extension est déclarée indépendamment. Il peut donc être possible de faire tourner un logiciel GL 4.3 sur un pilote qui n’annonce que 3.1 si en fait les seules extensions requises par le logiciel sont déjà implémentées. On peut voir encore sur mesamatrix que le pilote panfrost implémente déjà des extensions de GL 4.6. Donc si Blender ne tourne pas c’est que soi :

• Blender ne s’embête pas à regarder la prise en charge extension par extension, ou que
• Blender requiert une extension qui n’est pas implémentée, comme les geometry shaders

La seconde hypothèse est tout de même la plus probable.

Aussi les puces Mali comme la majorité des puces implémentées sur les SoC ARM sont des puces mobiles avec certaines limitations matérielles. Pour reprendre l’exemple des geometry shaders qui limitent ta puce graphique à GL 3.1, il est possible que:

• la puce soit capable de geometry shaders mais que Mesa ne l’implémente pas encore, ou que
• Mesa puisse émuler les geometry shaders au prix d’une performance moindre, ou que
• il soit techniquement impossible d’implémenter les geometry shaders

Il y a des chances que la situation soit la seconde hypothèse. Si je ne me trompe pas les geometry shaders sont aussi optionnels dans Vulkan.

Je ne sais pas ce qui bloque exactement dans Blender, mais c’est probablement un truc du genre.

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

Ça m’a motivé à ré-investiguer le problème, et voici donc gimp-thumbnailer:

• https://github.com/illwieckz/gimp-thumbnailer

Il sera toujours à jours des format XCF vu qu’il utilise GIMP directement pour produire la miniature.

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

Bonjour Jehan, on parle bien du fait que lorsque tu ouvres un dossier dans un explorateur de fichier comme nautilus, thunar ou dolphin, l’explorateur de fichier puisse appeler GIMP sans interface pour générer les miniatures des fichiers du dossiers. Est-ce que GIMP propose une telle interface ?

Cette interface en ligne de commande n’a pas besoin d’être standardisée, on peut écrire un script autour comme j’ai fait avec Darktable.

De mon côté j’utilise mon propre fork de gnome-xcf-thumbnailer avec des patchs perso:

• https://gitlab.gnome.org/illwieckz/gnome-xcf-thumbnailer

Mais ce projet ne fait pas partie de GIMP, donc quand GIMP fait évoluer le format (et c’est très bien et j’ai même des suggestions à apporter), bah gnome-xcf-thumbnailer ne suit pas et ne peut pas générer des miniatures pour les nouvelles itérations du format.

Mon besoin est de pouvoir utiliser un outil genre gimp-cli qui prendrait en entrée un fichier xcf et qui donnerait en sortie un png, compilé depuis la même base de code de GIMP (avec des ifdef par exemple), est-ce que ça existe ? Ça serait peut-être atrocement lent, mais ça marcherait. On pourrait même chaîner gnome-xcf-thumbnailer et n’appeler ce gimp-cli que quand le premier échoue.

Peut-être que tout est déjà là. Je sais qu’il existe gimp-console, peut-être qu’on peut le scripter pour faire ça.

Je n’ai pas du tout besoin que GIMP génère des vignettes et implémente la spécification "Thumbnail Managing Standard" de Freedesktop.

J’ai besoin que GIMP propose un outil en ligne de commande qui propose cette interface: command -s SIZE INFILE OUTFILE.

J’attends de mon explorateur de fichier (pas GIMP) d’implémenter la spécification "Thumbnail Managing Standard" de Freedesktop, et puisse appeler GIMP avec l’interface précitée. 🙂️

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

Ce serait déjà un mieux que la situation actuelle, mais ça ne change pas le fond de la question.

J’ai comme l’impression que si on appliquait une telle mesure en France, nous devrions revenir au fax, tellement nous sommes dépendants des produits étrangers…

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

Personnellement je pense que pour ce genre de fichier spécifique, c’est à l’éditeur de fournir un outil en ligne de commande qui prend en entrée un fichier et qui sort une image, afin d’être intégré au système de vignette.

Par exemple pour les fichiers raw j’ai scripté darktable-cli:

• https://github.com/illwieckz/darktable-thumbnailer

C’est atrocement lent mais au moins j’ai la garantie que la vignette correspond exactement à ce que Darktable va me présenter.

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

Est-ce que pour commencer nous avons un seul routeur français ?

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

Chuck Norris n’est pas mort, il a raccompagné la mort chez elle. 😆️

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

Ça dépend du système d’exploitation s’il implémente la copie reflink quand il accède au système de fichier en direct, ou bien s’il utilise la copie côté serveur si sur un disque réseau.

Et le principe d’avoir le service bees qui tourne c’est d’attraper tout le reste qui ne serait pas déjà dédupliqué au moment de la copie.

Par exemple si tu as plusieurs utilisateurs qui reçoivent le même PDF par mail et que chacun le télécharge, bees s’en chargera.

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

En faisant la déduplication au niveau système de fichier t’as pas besoin d’avoir une image en commun. Tu peux dédupliquer des machines virtuelles, des dumps de disques de machines physiques, et si ton hôte est sur le même système de fichier, tu peux dédupliquer les machines virtuelles avec les fichiers de l’hyperviseur !

J’ai pas vérifié, mais il n’y a pas de raison que ça ne déduplique pas aussi des images docker avec le reste. De toute façon j’utilise aussi btrfs en backend docker car c’est requis pour faire tourner Darling dans docker.

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

Oui RADV a été initié par David Airlie avec l’aide de Bas Nieuwenhuizen :

Plusieurs mois avant même la publication officielle de la spécification Vulkan, AMD avait annoncé qu'ils lanceraient dans un premier temps un pilote Linux Vulkan à code source fermé, qui serait ensuite ouvert. Plus de six mois se sont écoulés depuis la sortie de Vulkan 1.0, mais ce pilote Linux Vulkan n'a toujours pas été libéré, et AMD n'a pas non plus indiqué quand cette mise à disposition du code pourrait effectivement avoir lieu.

En l'absence de pilote Radeon Vulkan open source, David Airlie et Bas Nieuwenhuizen ont entrepris de développer leur propre pilote Radeon Vulkan « communautaire », au moins à titre de solution provisoire et éventuellement pour faire pression sur AMD afin qu'ils publient leur pilote Vulkan officiel. Bas Nieuwenhuizen est un contributeur indépendant, tandis que David Airlie est le responsable du sous-système DRM et un développeur chez Red Hat qui participe depuis longtemps aux efforts de développement de pilotes Linux AMD/ATI open source.
-- https://www.phoronix.com/review/radeon-vulkan-radv (30/08/2016)

Au final, la « pression » c’est qu’AMD a carrément lâché son propre pilote (mais l’avaient quand même libéré depuis longtemps)

Bien qu'AMD ait annoncé son intention de mettre en open source son pilote Vulkan, qui fait actuellement partie d'AMDGPU-PRO, plusieurs mois plus tard, cela n'a toujours pas été fait et aucune information n'a été communiquée quant à la date à laquelle cette mise en open source pourrait avoir lieu. En attendant, David Airlie, de Red Hat, a commencé à travailler sur « RADV », un pilote Radeon Vulkan non officiel. […]
Ce projet en est à ses tout débuts et pourrait facilement être abandonné si AMD tient effectivement sa promesse de rendre son pilote Vulkan pour Linux open source?
-- https://www.phoronix.com/news/RADV-Radeon-Vulkan-Driver (26/08/2016)

L’histoire a montré que c’est AMDGPU-PRO qui a été abandonné en faveur de RADV, et pas l’inverse. 🙂️

J'attendais qu'un pilote open source fasse son apparition quand je me suis rendu compte que je ferais mieux de le développer moi-même. Après en avoir discuté avec Bas, nous avons décidé de voir jusqu'où nous pouvions aller.
-- https://airlied.livejournal.com/81460.html (20/07/2016)

Cela me fait remarquer que RADV aura dix ans cet été (déjà !), et me rappelle que RADV était initialement inspiré de anv, le pilote Vulkan pour Intel de chez Mesa (développé par Intel). Donc AMD vient de basculer sur un pilote qui a historiquement un héritage technique Intel:

Le code s'inspire largement du pilote Intel anv, avec le système winsys porté depuis le pilote Gallium, et la majeure partie de la configuration des états provient de là.

-- https://airlied.livejournal.com/81460.html (20/07/2016)

Croustillant. 😄️

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

Il y a quelques mois j’ai lancé bees sur un volume de 30To. Je n’avais pas fait de déduplication dessus depuis 5 ans (avec un autre outil, je ne sais plus lequel). J’ai lancé la déduplication parce qu’il ne restait que 1To de libre… Ça a tourné quelques jours, et ça m’a libéré 5To. De quoi voir venir pour plusieurs mois ou peut-être années.

Et maintenant que bees a tout exploré je le laisse tourner en tâche de fond et il se fait oublier,

Sachant que j’optimise les systèmes pour faire du reflink le plus possible: alias cp qui active le reflink, options samba pour cumuler le sever-side copy et le reflink, etc. Évidemment on ne peut pas tout faire au moment de l’écriture, un exemple sont les dépôts Git: lors d’un checkout les fichiers sont décompressés, et si Git déduplique sa base de donnée, tout fichier restauré lors d’un checkout est « nouveau », et si en plus tu faits des instantanés réguliers du systèmes de fichier, ces copies prennent potentiellement autant de place qu’il y a eu de checkout et d’instantanés…

Bees déduplique aussi les snapshots.

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

Pour ce qui est de la déduplication je vois mal comment ce serait utilisable en pratique

• https://github.com/Zygo/bees

C’est un service, il explore ton système de fichier et déduplique, il conserve un cache pour savoir où il en est.

La première exécution peut prendre beaucoup de temps puisqu’il va tout lire et tout dédupliquer, mais ensuite, bah il ne traite que ce qui est nouveau/a changé.

Je parle bien de reflink. Le hardlink est tout le contraire du copy on write, puisque l’écriture modifie le fichier lié, au lieu de copier pour délier avant d’écrire.

Bees fait la déduplication à l’intérieur des fichiers, c’est pour ça que ça va même dédupliquer tes images disques. Genre t’as une machine virtuelle Debian ? Tu dump dans un fichier avec dd une clé USB Debian ? Il va te dédupliquer les block d’octets du binaire bash.

C’est d’ailleurs pourquoi je ne compresse plus les fichier image que je sauvegarde. J’active la compression au niveau de btrfs et je stocke mes images décompressées. Bees + btrfs vont compresser et dédupliquer au niveau système de fichier.

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

Exactement, avant que je convertisse les serveurs à btrfs, quand un utilisateur supprimait son fichier par erreur, il devait me faire une demande de restauration depuis la sauvegarde.

Après que j’ai fait la conversion à btrfs, ils ont eu un disque réseau spécial où chaque dossier de travail auquel ils ont accès ont commencé à produire des instantanés nommés par date. Chaque instantané est alors réalisé toutes les heures alors que la sauvegarde chaque nuit. Fichier supprimé ? Écrasé ? Corrompu ? L’utilisateur peut le récupérer de lui-même et avec une version qui a moins d’une heure.

En plus la magie c’est que puisque le disque de “machine à remonter le temps” utilise la même infrastructure de partage, bah il n’y a rien à implémenter côté gestion des droits. Les gens voient les instantanés de fichiers qui ont leur permission.

Je fait du btrfs depuis au moins 10 ans maintenant, c’est magique.

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

Dans l’écosystème Power, ceux qui rechercheraient un desktop ou serveur Power (pas un laptop), il y a les Talos de Raptor:

https://www.raptorcs.com/

Leurs Talos II ne sont pas obsolète, DDR4, PCIe4, ça fait largement l’affaire.

Bon par contre les prix sont chers, mais pas déconnant si on compare à des config Xeon ou ThreadRipper de chez Intel ou AMD.

Le souci c’est que quand Xeon et ThreadRipper étaient encore à la DDR4 et au PCIe4 ils jouaient dans la même cour, mais ce n’est plus vrai. Bon, en ce moment le prix absurde de la DDR5 leur donnerait presque un avantage.

J’ai entendu dire que les Power les plus récents n’étaient plus aussi ouverts et que ça explique pourquoi Raptor ne propose pas plus récents en terme de technologie. En effet le but de Talos est de proposer des systèmes ouverts, sans blob pour le CPU et tout.

On verra comment ça vieillira dans le future et/ou si la situation de Power se débloque, mais encore aujourd’hui les Talos de chez Raptor semblent encore largement au niveau pour qui a l’argent.

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

C’est bien mais ce serait mieux que les systèmes de fichier qui gagnent en performance soient les systèmes avec copie-à-l’écriture (Copy on Write).

Les systèmes de fichier comme ext4 avec leur systèmes d’inode prédéterminé au formatage comme dans les années 80 et sans copie à l’écriture ne sont plus sérieux que dans des cas très spécifiques et qui deviennent désormais très rares.

Dès qu’un active la copie à l’écriture (Btrfs, ZFS…) on peut :

• faire un instantané du volume que l’on va sauvegarder, et continuer à modifier le système de fichier d’origine alors que la sauvegarde est en cours,
• faire des instantanés régulièrement pour une restauration facile ou simplement une consultation sans même avoir à utiliser la sauvegarde,
• démarrer sur un instantané créé avant une mise à jour,
• dédupliquer les fichiers en général,
• dédupliquer les images disques (de machine virtuelle ou non), ça c’est vraiment un truc de fou, tu as 5 machines virtuelles Debian? Tu peux les dédupliquer, elles ne prendront pas 5 fois la place sur le disque…
• etc.

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

Bien vu ! En effet un « LLM d’inférence » ne veut rien dire, on dit bien un « moteur d’inférence ». =)

Si un modéro peut corriger:

- Par exemple dans le domaine de l’IA, le LLM (large langage model) d’inférence llama.cpp peut utiliser Vulkan
+ Par exemple dans le domaine de l’IA, le moteur d’inférence de LLM (large langage model) llama.cpp peut utiliser Vulkan

J’ai remarqué que beaucoup disent simplement « moteur d’inférence LLM » mais l’absence de préposition semble être un anglicisme. D’autres préfèrent la préposition « pour » en disant « moteur d’inférence pour LLM ».

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

Il me semble que tu peux faire ça avec OpenMP et le compilateur Clang d’AMD.

En gros il suffirait d’ajouter des #pragma omp à ton code et d’utiliser -fopenmp --offload-arch=<l’architecture AMD> à la ligne de commande clang, ou quelque chose comme ça.

Mais ça c’est une fonctionnalité de ROCm, et le sujet de la dépêche c’est RADV et donc en partie Vulkan compute. Et Vulkan compute c’est pas aussi intégré. En gros l’état des choses c’est que pour le codeur Vulkan compute c’est plus compliqué, mais pour l’utilisateur c’est mieux parce que ça marche partout.

Alors que les trucs à la ROCm, bah ça marche surtout sur la machine du développeur en mode chezmoiçamarche™. CUDA a en partie le même problème, mais son écrasante domination et la maturité du bousin, contrairement à ROCm, fait que ça marche quand même mieux chez les autres.

Typiquement pour Whisper, j’ai arrêté d’utiliser ROCm, ça marchait sur une carte et demi. Et en plus ça mettait des plombes rien qu’à démarrer le python… Alors qu’avec whisper.cpp en Vulkan sur RADV, ça marche partout. Pour l’utilisateur c’est royal.

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

Pour le coup c’est pas grâce à l’IA : celui qui n’écrit pas une seule ligne de code n’écrit aucun bug, il ne fait jamais d’erreur et c’est donc le meilleur développeur. CQFD.

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

Cette liste dit qu’elle n’est pas à jour et que c’est celle-ci qui l’est :

• https://stopkillinggames.wiki.gg/wiki/Dead_game_list

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