AlexTérieur a écrit 439 commentaires

PowerVR… c'est pas le truc où tout le monde a pleuré pour avoir des pilotes libres et qui en guise de respect du monde libre les développeurs ont fournis un pilote toujours plus fermé mais surtout de plus en plus daubé ?

Je viens de "ressusciter" une vieille config qui a déjà un SSD SATA pour le / (120 Go, pas plus). Pas de PCIe au-delà du x1 (en dehors du port PCIe x16 pour la carte graf' déjà occupée), donc inutile de mettre un adaptateur PCie vers NVMe (je sais même pas si c'est possible sur du x1) et donc impossible d'avoir de meilleurs débits que le SATA…
Les disques durs ont fait du progrès depuis en performance, même si j'imagine ils sont encore un peu loin de saturer le SATA… mais suffisamment pour resserrer l'écart avec les SSD SATA.
Bref, je me rappelle que j'ai pas autant gagné en passant du SSD SATA que j'ai pu en passant au SSD NVMe… d'ailleurs quand je passe de ma config "moderne" avec NVMe à "l'ancienne" en SSD SATA c'est plus que le jour et la nuit, au point de me dire que le plus grand progrès en informatique classique c'est pas des processeurs plus puissants (le Core i7 "Sandy Bridge" de la vieille config est loin d'être largué pour les tâches quotidiennes) mais le passage SSD avec le fameux port NVMe. Sans ça, pour ma part, le passage SSD me semble pas aussi pertinent qu'on pourrait le croire.
Si cela peut te bénéficier dans ta réflexion…

Apparemment c'est en cours de développement et bien avancé chez Crosoft :
https://hardwareand.co/actualites/breves/dxr-1-2-dxr-2-0-et-les-travaux-sur-les-algos-devraient-changer-l-implementation-du-lancer-de-rayons-dans-les-jeux

Je sens que le monde libre va reprendre du retard…

Bon les techniques du style "illmuination globale" SSAO etc. c'est bien la suite de ce que j'appelle la "méthode traditionnelle" j'avais mal saisi.
Mais j'ai du mal à voir pourquoi on s'est jeté sur le Ray Tracing, il n'y aurait qu'une seule voie possible selon certains…

J'avais vu il y a quelques temps une vidéo explicative d'un youtubeur français (cocorico) très convaincante sur comment on générait jusqu'à maintenant l'éclairage en mode "rastérisation" pure et que cette méthode s'appuyait sur une approximation mathématique connue (comme il y en a beaucoup en mathématique) qui évite des calculs incroyablement lourds (du genre à éviter une accumulation exponentielle de nécessité de puissance de calculs) et sans laquelle encore aujourd'hui on aurait du mal à avoir des jeux avec un éclairage "temps réel" convaincant (en dehors du nouveau et désormais sacro-saint RT). Malheureusement je n'arrive plus à remettre la main sur cette vidéo.
Il y a bien eu des progrès sur cette méthode "traditionnelle" non ?

J'ai suivi longtemps l'"aventure Wayland" et cherché les solutions pour des config "minimale" mais moderne quand même… à l'époque j'ai bidouillé sur un RPi, et la seule solution c'était Enlightenment… Ils commençaient à développer un support Wayland, et même que Samsung avait développé leur interface Android à base des bibliothèques EFL (fondement de l'environnement Enlightenment)… Aujourd'hui, le support Wayland d'Enlightenment est resté "expérimental" (sic), et au passage Samsung a abandonné Tizen…
J'avais bien entendu connaissance de "Weston" mais c'était longtemps décrit comme un projet "exemple" et pas comme un véritable DM…
Je trouve que Wayland a raté le virage des supports de type "tablettes" et autres appareils tactiles… Cela lui aurait donné une légitimité de plus pour remplacer X11…

Et ces différentes distributions possèdent suffisamment de caractéristiques spécifiques pour répondre à tous les besoins, à commencer par l’absence de fonctions IA inutiles.

Ah ouais, je ne m'attendais pas à une phrase aussi choc de leur part.

Et il y a une chose où j'ai oublié de "réagir" (et qui conforte un peu la responsabilité de AMD de cet état de fait) : VA-API, le "framework" multimédia, s'il ne vient pas de nVidia, a été développé par… Intel, principal concurrent de AMD dans le domaine des CPU. Ça ne veut rien dire comme à la fois ça pourrait dire que AMD ne se décarcasse pas non plus tant que ça côté support software. A l'époque c'était tellement le flou qu'un moment donné le VDPAU était envisagé.
Je dis ça parce qu'on a beau se féliciter de ces pilotes "définitivement" libres, je suis prêt à parier, selon l'avis des spécialistes hardware, qu'à la prochaine évolution (qui serait alors une nouvelle architecture qui ne serait plus nommée RDNA comme l'actuelle et les deux précédentes) où on risque d'avoir une nouvelle série de pilotes libres, perpétuant cette confusion dans les dénominations de pilotes, et rendant le tout encore un peu plus imbuvable…

je prends les paris… A dans 5 ans :-)

J'avais posté il y a déjà 5 ans de ça un journal-astuce qui expliquait comment installer ces fameux "ORCA" pour bénéficier de l'OpenCL (avec ROCm) sous Fedora… tout en (me) questionnant de savoir si quelqu'un pourrait expliquer pourquoi c'est si compliqué d'installer des pilotes "legacy".

J'ai enfin la réponse :-)
Cette histoire de recompilation de pilotes Windows… tu m'étonnes que cela n'a pas été distribué par toutes les distros.

Aujourd'hui j'ai toujours ma vieille mais vaillante RX580, et les versions suivantes de Fedora je n'ai pas cherché à savoir comment pouvoir utiliser les ORCA avec ROCm, j'ai abandonné l'idée d'utiliser OpenCL ; aujourd'hui encore, les applis supportant OpenCL se font rares, par contre le CUDA pullule, même dans l'univers de l'Open Source… On peut blâmer nVidia (même s'ils ne font que de profiter d'une situation) mais AMD est sûrement responsable du manque de support OpenCL en ne faisant pas d'effort…

J'ai traduit la page signalée plus bas.
Apparemment la date est celle-ci : "Dernière mise à jour 2017/1/4"

Je ne promeuts rien, c'est le cadet de mes soucis.

En attendant, il y a zéro traqueurs certifiés y compris par Google Play…

Et en attendant (bis), il y a pleins d'applis chinoises similaires bourrées (et mises en avant) de traqueurs qui n'attendent qu'à être installée…

Gratuit, sans pub et sans traqueur suspect :
https://play.google.com/store/apps/details?id=infinitegra.app.usbcamera&hl=fr

Mais pas Open Source. A voir si le développeur pourrait le faire basculer un jour ou l'autre en sources ouvertes : https://infinitegra.co.jp/en/androidapp1/

Alors je me réponds à moi-même.
Car il y a d'autres problèmes que je n'ai pas évoqué.
Il y a aussi les logiciels qui doivent accéder à des parties spécifiques de ton /home/, sauf si tu t'amuses à copier les fichiers concernés dans la config de l'appli dans $HOME/.var/app/… donc à au moins chaque mise à jour, tu dois reconfigurer lesdit logiciels…

Haha, j'aime bien ta petite série :)
On en revient toujours au même point : est-ce vraiment une bonne idée l'"empaquetage" (façon flatpak ou autre) sous Linux…
Sachant que je suis sous Fedora…
Je suis vachement alléché par l'offre logiciels sous Gnome Software sans passer par les fameux RPM… mais quand tu vois qu'un logiciel qui fait "3 fois rien" mais qui te permet certaines choses, donc tu te dis qu'il pèsera rien même sous flatpak, et que plus loin on te met "nécessite 465 Mo d'espace supplémentaire"… tu te poses sincèrement des questions. Pas seulement consommation mémoire stockage, mais aussi, est-ce avec tout cet espace nécessaire aussi sécurisé que dit… Bah… le doute est permis.

Le youtubeur guitariste Florent Garcia l'a testé :
https://youtu.be/RCnSIm55xuE

https://invidious.drgns.space/watch?v=8rsX7LVVFa8

Je n'arrive pas à comprendre l'engouement, surtout dans le milieu d'informatique, de personnes qui entrent volontairement des données privées sur un site pour, je cite plus ou moins, "vérifier qu'ils ne sont pas piratés"… un peu comme il y a eu une tendance à une époque très récente qui était de "vérifier la solidité de son password" et qui derrière alimente une base de données qui va très certainement permettre des algorithmes brute force de faire des attaques… Je suis surpris qu'on n'y fasse toujours pas attention.

Je ne suis pas spécialiste sur le sujet mais cela ressemble à la problématique que doit répondre les systèmes de container comme Podman… qui à la différence de Docker ne nécessite pas lancer les images en mode root.

A voir.

…Mais je suis plutôt Peugeot.
Bon blague à part, merci pour cette rétrospective. Perso, je suis fédoriste convaincu depuis la version 21 si je ne me trompe pas.
Et j'aime le rappeler (car je connais l'environnement Linux depuis bien avant) : c'est la distribution sur laquelle j'ai constaté le moins de soucis. Normal que j'y suis resté, surtout que j'ai vieilli.

Après la période "je suis manipulé par un pervers narcissique", plus récemment "on m'a diagnostiqué comme étant HPI", voici venu "je suis diagnostiqué autiste"…
Et hop, un pic de plus dans les statistiques (ça rime en plus).

Sauf que tu n'arrive pas à comprendre ce qu'on te dis… tu joues les connaisseurs. La solution de François est la meilleure dans de nombreux cas, sauf que tu mélanges beaucoup de choses… comme je l'ai dit plus haut, il est normal de pouvoir "casser" les protections root d'une machine qu'on a accès physiquement… ça cela est un comportement normal (comme tu le dis). Mais qu'on puisse devenir root au cours de l'initialisation d'un système aussi facilement… Pour moi cela n'est plus normal.

Sauf que je parlais des systèmes comme Debian/Ubuntu… qui utilisent si je ne me trompe pas également grub2.
Il me semble que tu ne connais pas assez bien les systèmes comme Fedora/Red Hat, qui utilisent un init particulier.

Et pourquoi la précision sur le fait des systèmes "Red-Hat" ? Cela veut dire que sous les systèmes de base Debian/Ubuntu ce n'est pas aussi évident/c'est différent.

Et bien je trouve que la faille est là. Bien sûr qu'en étant "administrateur" tu fais ce que tu veux. C'est juste que je trouve que c'est une faille "simple" à mes yeux.
Et je trouve l'article de linuxtricks.fr trop précis, c'est-à-dire que ce n'est que pour les système "Red-Hat", pour qu'on ne se pose pas de question.

Sauf que non, tu n'as pas forcément besoin d'un accès physique, il y a des offres de serveurs dédiées qui te permettent de contrôler le démarrage…
Elle est là la question. Le problème du chroot ne se pose pas, puisque c'est le but. Sauf que là ce n'est pas du chroot.

C'est le plus sûr !!

-->[]