Le fil des beaux gosses linuxiens, v2 où comment installer LFS sur BTRFS en RAID10

[Laya]

Merci pour vos explications.

Mais du coup les jeux sortant sur plein de supports différents rien n'empêche vraiment les développeurs de faire des versions natives linux maintenant avec les moteurs de jeux récents gérant des API multi-supports comme Vulkan. On en voit pas mal maintenant mais il faudrait que ce soit TOUS les jeux.
Pourquoi continuer à utiliser exclusivement directX en fait ? Microsoft a sûrement des arguments sonnants et trébuchants mais l'intérêt des éditeurs est de pouvoir sortir leurs jeux partout que ce soit sur PC et consoles. Sur ces dernières Microsoft est très loin d'être leader donc les développeurs sont habitués à utiliser d'autres outils que les leurs.
Comme je disais plus tôt l'environnement logiciel linux est maintenant mûr techniquement pour le JV, c'est une question de décision éditoriale.

C'est juste une question de marché et de connaissance je pense.
Le marché Linux est encore faible, beaucoup de développeurs sont probablement plus à l'aise avec du directX, du coup ça continue comme ça.

C'est pour ça que la steam deck est l'une des avancés qui pousse le + le gaming vers linux. Au moins que ça fonctionne sous proton.

[Cwningen]

En fait pour l'émulation, j'ai l'impression que tout le monde n'est pas d'accord sur la définition. On pourrait débattre que la traduction d'API est une forme d'émulation logicielle. En tout cas wine/proton n'émule pas le matériel, on est d'accord.

Pour ce qui est des portages natifs. Les gros moteurs clé-en-main sont multi-plateformes et rendent tout ça trivial. Mais le résultat est trop souvent décevant. S'il n'y a pas de soin apporté au portage, on finit avec des versions inférieures voire buguées, et, au final, on préfère lancer la version Windows. J'ai particulièrement en tête Hollow Knight qui, à une époque, plantait dès qu'il détectait une manette, c'est très gênant pour ce genre de jeu. Le problème c'est surtout que la plupart des développeurs s'en foutent de Linux.

[Manuel]

C'est bien aussi qu'une boîte comme system76 sorte des PC avec son linux installé, après une autre comme Red Hat (bien plus grande avec IBM derrière) pourrait sortir Fedora pour le grand public par exemple et faire du marketing autour, il y a sûrement un marché important pour reprendre des PDM à windows, son quasi-monopole semble tellement acquis que peu songe à se lancer.
C'est là que ça bloque encore, plus il y aura d'utilisateurs, plus il y aura de jeux, de programmes disponibles et là les développeurs s'en ficheront sans doute moins.

[Papeyo]

Pourtant un des forces de linux c'est justement d'avoir de la variété sur les distributions et les desktop pour trouver chaussures à son pied.

En pratique, il y a peu de différences. Pour le grand public, cela se joue sur les préinstallations de logiciel ou les scripts d'installation. Cela peut s'expliquer, je pense, par le faite que faire un gestionnaire de paquets fiable et un système de base est très contraignant. Par ailleurs, il y a des standards à respecter pour ne pas trop sortir de la norme.

Si je prends ubuntu, pour installer une application via l'interface graphique c'est "gnome-software", qui est (de mémoire) préinstallé.
Sur debian, il existe : https://packages.debian.org/bullseye/gnome-software
Sur arch, il existe : https://archlinux.org/packages/extra...nome-software/
Sur redhat, il existe : https://access.redhat.com/documentat...ment-in-rhel-8

Donc au final, pour le end user, la différence principale cela va etre de l'installer voir de le configurer.

Si on regarde l'arborescence des distributions :
https://upload.wikimedia.org/wikiped...ions_Linux.svg

Il n'y a que quelques distributions "primaires".

Dans les cas de besoins spécifiques d'avoir la dernière version, généralement l'éditeur propose son propre repository.

[Mr Slurp]

Merci pour vos explications.

Mais du coup les jeux sortant sur plein de supports différents rien n'empêche vraiment les développeurs de faire des versions natives linux maintenant avec les moteurs de jeux récents gérant des API multi-supports comme Vulkan. On en voit pas mal maintenant mais il faudrait que ce soit TOUS les jeux.

Il reste selon moi une contrainte majeur à sortir des jeu sur linux : 2 plateformes = 2x plus de QA pour vérifier que tout marche bien. Le coût de dire "on supporte les 2 OS" au lieu de juste dire on fait du Windows est non nul et vu que coût d'une bonne phase de QA (a chaque version release du jeu), la facture devient vite salée. De l'autre coté, tu fais ton jeu avec support windows as usual et tu laisse la charge aux joueurs d'essayer voir si ça passe sous linux+proton, sans avoir a lui apporter plus de support parce "c'est pas supporté officiellement".

[Cwningen]

après une autre comme Red Hat (bien plus grande avec IBM derrière) pourrait sortir Fedora pour le grand public par exemple

Fedora pour le grand public, ce serait Fedora Silverblue, non ? Un fonctionnement à la Android : un système de base en lecture seul mis à jour comme un seul bloc et des applications conteneurisées par dessus. Mais je sais pas si Flatpak est vraiment prêt pour les grand public. Je l'utilise peu mais les quelques fois où j'ai essayé j'ai trouvé l'accès aux fichiers confus entre ceux internes au flatpak et ceux importés par le portail. Beaucoup d'applications desktop ne sont pas conçues pour fonctionner de cette façon pour l'instant.

[Illynir]

Fedora Silverblue sera à terme la version "workstation" classique de Fedora, ils attendent juste que ça mature encore plus mais c'est le projet final. Ca fonctionne déjà pas mal du tout en réalité.

Flatpak s'améliore aussi de jour en jour et les défauts se gomment, sans compter qu'ils commencent à avoir une bibliothéque assez conséquente de logiciel maintenant.

Globalement tout le monde s'accorde plus ou moins à dire que les systêmes immutables sont l'avenir.

[moimadmax]

Comme à chaque fois que je déboule ici, j'ai un problème et je ne sais pas par quel bout le prendre.
C'est un problème de son avec une carte intel HDA (celle utilisée par le port HDMI) et pipewire, le son fait un genre de résonance sur certaines fréquences plutôt haute.
Ce PC tourne sous Ubuntu et c'est lorsqu'il a passé pipewire par défaut au lieu de pulseaudio j'ai noté le problème. Donc avec la 22.10.
Comme je n'avais déjà rien trouvé à l'époque, j'avais appliqué un tuto pour retourner sous pulsaudio et désactiver pipewire.
Mais avec la récente mise à jour en 23.04, je n'avais plus de son, réglé en faisant un revert sur le tuto (unmask pipewire) mais le son pourri est revenu.

Sur linux il y a des trucs que je comprends, mais il y a surtout la stack graphique et la stack audio ou je n'ai jamais réussi à comprendre. Du coup j'ai un peu du mal à chercher.
J'ai déjà du mal a mettre un terme sur le défaut de l'audio. J'ai envie de dire de la sibilance ...

Ce que j'ai déjà tenté:
- forcer à 44100 dans pipewire.conf. Sans réel résultat.
- https://gitlab.freedesktop.org/pipew...irtual-machine Pas mieux.
- pw-cat et aplay donnent le même son pourri. (mais si j'ai bien compris, c'est pipewire qui gère toute la pile audio, du kernel à l'application, avec des compatibilité avec les couches d'avant. donc ce résultat est logique)

EDIT : C'était le taux d'échantillonnage : https://gitlab.freedesktop.org/pipew.../-/issues/3182

[Dark Fread]

Y'a déjà quelqu'un qui a réussi à installer le driver Radeon Pro sur Ubuntu 22.04 ? (j'insiste sur le "Pro", c'est pour avoir OpenCL dans le but de participer à Folding@Home avec le GPU)

Pis bon pour être franc, même le driver proprio non-Pro n'a pas l'air de vouloir s'installer en fait. (je peux faire un topic si vous préférez, par contre je dirai plein de gros mots dedans.)

Edit : et voilà j'ai tout pété mdr

Edit 2 : le merdier ne démarre plus qu'après un passage en mode recovery

Edit 3 : et démoule 3 fps sur CS:S

Edit 4 : wow c'est réparé, j'ai installé le pilote Radeon normal et retrouvé 240 fps sur CS:S

Edit 5 : bien évidemment toujours pas d'OpenCL mais on veut peut-être pas chercher plus d'emmerdes

[rOut]

En fait pour l'émulation, j'ai l'impression que tout le monde n'est pas d'accord sur la définition. On pourrait débattre que la traduction d'API est une forme d'émulation logicielle. En tout cas wine/proton n'émule pas le matériel, on est d'accord.

Pour ce qui est des portages natifs. Les gros moteurs clé-en-main sont multi-plateformes et rendent tout ça trivial. Mais le résultat est trop souvent décevant. S'il n'y a pas de soin apporté au portage, on finit avec des versions inférieures voire buguées, et, au final, on préfère lancer la version Windows. J'ai particulièrement en tête Hollow Knight qui, à une époque, plantait dès qu'il détectait une manette, c'est très gênant pour ce genre de jeu. Le problème c'est surtout que la plupart des développeurs s'en foutent de Linux.

En fait tout est lié à la liberté offerte par Linux. C'est à la fois un avantage pour plein de choses, et en particulier pour l'utilisateur qui désire pouvoir customiser, parameter et avoir le choix de plein de distributions et logiciels différents pour faire la même chose, ou pour les développeurs qui souhaitent s'extraire des standards et peuvent proposer des changements radicaux dans la manière dont le système fonctionne, de manière plus flexible et en iterant plus rapidement.

Et en même temps c'est une faiblesse parceque pour qu'une application soit portable il faut qu'elle gère toutes les subtilités dues à cette variété. Supporter des distributions, des pilotes opengl, ou des gestionnaires de fenêtres différents avec un niveau de qualité attendu pour un jeu c'est quasiment autant de boulot que de porter le moteur de jeu sur une nouvelle plateforme. Du coup ça coûte trop cher et c'est souvent mal fait. De plus, l'évolution du système finit rapidement par casser la compatibilité binaire. Ce n'est pas forcément un problème quand tout est open source et recompilable, par les distros, mais pour les applis proprio ça l'est, et en particulier les jeux sortis il y a des années ne sont pas mis à jour.

À côté de ça, l'API Win32 est développée par une boîte qui a des contraintes commerciales fortes, et Microsoft s'est efforcé de conserver une compatibilité binaire quasi absolue. Pour les devs c'est bonnard, quasiment comme une console. Et en fait pour Linux aussi, à condition d'accepter que la plateforme de jeu c'est Win32, avec Wine comme runtime.

[Cwningen]

Les bugs dépendant des distributions sont rares quand on utilise des runtimes séparées comme avec Steam ou Flatpak. Les pilotes GPU, tu as la même variété sur Windows. Les gestionnaires de fenêtres ont peu d'influence sur les jeux qui se contente d'une surface OpenGL/Vulkan (mais plus sur les applications de bureau). Je ne pense pas que ce soit techniquement plus difficile de développer un jeu pour Linux par rapport à Windows (et on a plein de ports Windows qui sont aussi tout pétés). C'est juste que t'es pas prêt à faire les mêmes efforts pour une aussi petite part des joueurs.

[Papeyo]

Cela faisait bien longtemps que j'avais pas fait une installl (hormis raspbian, mais c'est un kit #yarienàfaire). Le but c'était de remplacer un Pi3 qui déconne sur de l'HDMI/VGA pour faire tourner rapido des applis type arduino IDE/sigrok. J'en ai profité pour tester vite fait :
- Arch, j'avoue qu'en 2023, me retrouver avec limite un rescue en guise d'installation cela m'a direct refroidit. J'ai vu après qu'il y avait des scripts d'installation. Il y a globalement un concept qui m'échappe et/ou pour lequel je ne suis pas réceptif
- Ubuntu, n'a pas pris une ride, toujours aussi bidon à installer. Par contre je n'ai pas bien compris le logiciel par défaut pour installer des softs. Arduino IDE, il me le donnait en 1.8 alors que cela fait plusieurs mois que c'est en version 2 sur les repos. Des logiciels type screen n'était pas installable par là.
- Debian, ca reste Debian avec son interface graphique d'installation à peine mieux que la version texte, mais ... c'est graphique :D Rien de bien nouveau en 20ans.

Au final, j'ai pris KDE Plasma et franchement, on n'est pas loin d'un windows like niveau interface, je suis assez épaté. C'est un peu lent à démarrer par contre.

Et en 2023, il n'y a toujours pas de script d'installation automatique des dongle USB Wifi, je trouve ça pas terrible et vraiment chiant. Il faut se taper la corvée de l'installation de A à Z à la main.

[rOut]

Les bugs dépendant des distributions sont rares quand on utilise des runtimes séparées comme avec Steam ou Flatpak. Les pilotes GPU, tu as la même variété sur Windows. Les gestionnaires de fenêtres ont peu d'influence sur les jeux qui se contente d'une surface OpenGL/Vulkan (mais plus sur les applications de bureau). Je ne pense pas que ce soit techniquement plus difficile de développer un jeu pour Linux par rapport à Windows (et on a plein de ports Windows qui sont aussi tout pétés). C'est juste que t'es pas prêt à faire les mêmes efforts pour une aussi petite part des joueurs.

Bah y'a qu'à voir le nombre de jeux développés en Linux natif, avec une bonne qualité à la sortie, et qui ne se lancent tout simplement plus de nos jours. J'en ai quelques uns pour ma part.

- - - Mise à jour - - -

La solution habituelle, que font Steam, historiquement à base de LD_LIBRARY_PATH (comme GOG aussi), ou plus moderne à base de conteneurs comme le fait Flatpak, c'est vraiment la solution du pauvre. En gros tu snapshot ton système à une version donnée, avec toutes les dépendances, pour t'assurer que ça continue de marcher pareil à l'avenir. En espérant que le noyau et les drivers ne pètent pas la comptabilité binaire parce que ça tu peux pas les foutre dans le snapshot.

Coup de bol, le noyau Linux est fait par des gens serieux, qui prennent soin de la compat binaire user-space (mais ça arrive de péter par moment quand même, mais rare). Coup de pas de bol, les pilotes c'est moins le cas.

Dans tous les cas c'est vraiment une solution pourrie, ça prend une place folle, tu perds toute possibilité de gérer des updates de sécurité correctement, et puis c'est juste pas le boulot des devs de jeux de faire ça, donc ça suppose l'existence de distributeurs intermédiaire, Steam, Flatpak, etc... Et ça dépend aussi de la qualité du boulot qu'ils font. Au final même avec des snapshots comme ça, ça continue de péter régulièrement (j'ai arrêté de compter le nombre d'applis installées avec Flatpak qui ne marchent plus après des updates du runtime), parce qu'on a quand même envie d'éviter le 1 appli - 1 snapshot complet.

A coté de ça, t'as Win32 avec quasi 100% de compat binaire, mais une API hyper figée et contrôlée par un seul intervenant.

[Illynir]

Sauf les trucs en 16 Bits, comme les vieux jeux et de vieilles apps.

Ironiquement la compatibilité est bien meilleur sur Linux pour eux que sur Windows.

[rOut]

C'est à dire ? Via dosbox ? C'est pas tellement différent de Wine, hormis que pour le coup le hardware est émulé.

[Illynir]

Non non, je parle des applications et jeux 16 bits, juste après MS-DOS justement.

Et même en 32 bits, pas mal d'applications et jeux merdouillent sur Windows 10/11 maintenant. Surtout des vieux jeux qui tournent sans probléme avec wine.

[rOut]

Oui c'est toujours possible, mais au moins l'API reste stable et c'est un problème de changement dans le comportement du runtime, pas à cause d'une lib manquante ou d'une fonction qui a disparue / a changé de signature. Ça reste un problème et surtout si le nouveau comportement devient nécessaire à certaines applications, auquel cas même wine va devoir faire le choix du nouveau ou de l'ancien. L'avantage c'est que si le problème est connu, ça peut être soit corrigé comme un bug, soit rendu configurable s'il y a une réelle incompatibilité.

[Cwningen]

J'ai pas dis que Linux était bon, j'ai dis que c'était pas pire que Windows. Le problème des dépendances, ça fait des décennies qu'on cherche la solution et qu'on a rien trouvé de parfait. Ton application Windows elle ne dépend pas que de Win32. Qu'est-ce qu'on fait pour les autres dépendances ? Souvent on les inclut dans le dossier d'installation, ou on utilise des installateurs de runtime (VC, .Net, DirectX, ...). On peut faire la même chose sur Linux, ça marche aussi bien (ou aussi mal).

[rOut]

Sauf que windows propose de base un runtime "standard" beaucoup plus complet que Linux, donc il y a généralement moins besoin d'inclure des dépendances supplémentaires. Ensuite, les dépendances supplémentaires utilisent aussi directement l'API Win32, qui est stable, et beaucoup plus vaste que l'équivalent "standard" Linux qui serait peut être la libc / X11 / GL / Vulkan.

En plus de ça, tu te fais aussi très vite incendier dès que tu bundles des librairies dans ton application, parce que "c'est mal". Et effectivement c'est mal, et d'autant plus parce que les libraries en question vont dépendre d'autre libs fournies par le système dont l'API est instable, et rapidement casser la compatibilité. C'est le cas de plein de libs de sécurité ou de multimedia, mais aussi ce qui est complètement dingue, de la glibc qui s'assied sur l'ABI quand ça lui chante. Sans parler que la glibc n'est pas la seule libc disponible.

- - - Mise à jour - - -

Et même la Xlib, on peut se poser la question de savoir combien de temps ça va tenir. Un de ces jours Wayland va prendre le dessus (ha ha), et X11 sera déprécié. Combien de temps avant que les distros décident de ne plus packager les libs en question? Comme je le disais ça fait partie de la force de Linux, avec la possibilité de dégager le legacy au bout d'un moment, mais c'est aussi une faiblesse pour la rétrocompatibilité sur le long terme.

[Cwningen]

Je rappelle que la question à l'origine c'est "pourquoi malgré tous ces moteurs de jeux multi-plateformes on n'a pas plus de portages natifs ?". Je suis pas sûr que les problèmes de compatibilité future soient ce qui effraie les développeurs (au contraire certains aiment te revendre le même jeu régulièrement).

En plus de ça, tu te fais aussi très vite incendier dès que tu bundles des librairies dans ton application, parce que "c'est mal". Et effectivement c'est mal, et d'autant plus parce que les libraries en question vont dépendre d'autre libs fournies par le système dont l'API est instable, et rapidement casser la compatibilité. C'est le cas de plein de libs de sécurité ou de multimedia, mais aussi ce qui est complètement dingue, de la glibc qui s'assied sur l'ABI quand ça lui chante. Sans parler que la glibc n'est pas la seule libc disponible.

C'est mal pour les logiciels libres parce qu'on peut faire mieux. Mais pour les logiciels propriétaires il y a une autre solution ? On le tolère bien sur Windows, les problèmes de sécurité sont les mêmes. Pour les runtimes C/C++, dans mon C:\Windows\System32 j'ai msvcp60.dll, msvcp100.dll, msvcp110.dll, msvcp120.dll et msvcp140.dll. Tu gardes toutes les versions dont tu as besoin.

[rOut]

Je rappelle que la question à l'origine c'est "pourquoi malgré tous ces moteurs de jeux multi-plateformes on n'a pas plus de portages natifs ?". Je suis pas sûr que les problèmes de compatibilité future soient ce qui effraie les développeurs (au contraire certains aiment te revendre le même jeu régulièrement).

En fait je ne pense pas que les devs soient réllement le soucis, en général ils sont de bonne volonté et c'est plutôt une question de fric et de producteurs qui optimisent leurs coûts. Mais même en imaginant juste le support Linux day 1 et sans se préoccuper de la compat future, je pense sincèrement qu'un bon support sur toutes les distros populaires (et je suis gentil je vais ignorer toutes les petites distros et les exotiques) demande plus de temps et d'effort que pour supporter la version de Windows du moment. Ne serait-ce que pour bien faire il faut dupliquer la QA sur autant de setups que de distros. Tu ajoutes une dimension à ton espace de QA, ce qui n'est quand même pas rien.

Je parlais de WM en particulier, et dire qu'il suffit d'ouvrir une fenêtre et basta c'est ignorer tout un tas de soucis qui existent pour de vrai, pour des scénarios complètement valables (alt-tab, minimization, gestion du fullscreen etc...).

C'est mal pour les logiciels libres parce qu'on peut faire mieux. Mais pour les logiciels propriétaires il y a une autre solution ? On le tolère bien sur Windows, les problèmes de sécurité sont les mêmes. Pour les runtimes C/C++, dans mon C:\Windows\System32 j'ai msvcp60.dll, msvcp100.dll, msvcp110.dll, msvcp120.dll et msvcp140.dll. Tu gardes toutes les versions dont tu as besoin.

Oui, c'est versionné, une mise à jour de sécu sur msvcp60.dll est toujours possible et s'appliquera à toutes les applis qui l'utilisent, et le système garde et propose les vieilles versions de toutes les DLLs Microsoft. Ce que ne fait aucune distribution Linux à ce jour à ce que je sache, il y a quelques rare cas ou les vieilles versions trainent encore mais c'est en général le temps de mettre à jour tel ou tel package avec une update de ses dépendances, puis la vieille lib est dégagée, et tant pis pour toutes les applis tierces qui auraient voulu l'utiliser. T'as une et une seule version de la libc, et si ton appli marche plus avec t'as plus que tes yeux pour pleurer (tu peux tenter de recompiler la vieille libc mais c'est là aussi rapidement la galère).

[Cwningen]

Au final, personne n'est assez motivé pour faire le boulot parce que ça ne vaut pas le coup. Pour les distributions, c'est normal. La plupart existe pour distribuer du logiciel libre, donc pas besoin de plusieurs libc, donc pas de raison de faire des efforts. Ce serait plutôt aux distributeurs de logiciel propriétaires de les faire. Donc Valve surtout. Et ils proposent justement une (des?) runtime. Je sais pas ce que ça vaut pour la sécurité, mais c'est censé être stable.

[rOut]

Il y a aussi un problème dans la gestion de version des dépendances. Même si tu peux avoir libfoo.so.1 et libfoo.so.2, sous Linux la résolution de symbole se fait globalement et l'une des deux sera privilégiée. Et si dans le tas tu as des libs qui voulaient l'autre faut prier pour que ça marche (il y a normalement un versionnage fait au niveau des symboles mais c'est rarement utilisé).

Ce n'est pas le cas sous Windows, et même si tu peux toujours finir par avoir des incompatibilités en cas d'utilisation de state global, ou de partage de structures avec une ABI incompatible, tu peux plus facilement avoir des composants qui utilisent msvcr60.dll et d'autres msvcr70.dll sans que ça explose.

Sinon oui, Valve propose un runtime, mais ça sous entend que tu dois acheter tes jeux chez Valve pour en profiter. Et ils étaient emmerdés pendant longtemps parce que c'est la galère à maintenir, et que le LD_LIBRARY_PATH (utilisé avec le runtime d'origine "scout" basée sur ubuntu 12.04) c'est vraiment juste un hack qui ne permet pas bien de gérer les updates. Maintenant ils gèrent ça avec des conteneurs et ils ont commencé à avoir plusieurs mises à jour ("soldier" basée debian 10, et maintenant sniper sur debian 11) du runtime dans sa globalité, tout en conservant les anciennes pour les vieux jeux, mais c'est basé sur debian donc le gros du boulot est fait en amont et pas par Valve, et ça reste des snapshots uniques avec une version donnée de chaque lib.

[Manuel]

J'ai enfin réussi à lancer des jeux windows sous Pop OS avec lutris et steam.
Sauf que j'arrive pas à trouver où mettre mes sauvegardes pour mes jeux gog avec lutris... Je récupère bien les fichiers mais aucune idée où les mettre, il y a bien un sous-répertoire games\gog dans le dossier personnel avec quelques répertoires de jeux lancés mais pas moyen d'avoir les sauvegardes des parties windows malgré la présence des fichiers.
Je pige pas.

[Cwningen]

Wine utilise des "préfixes" dans lesquels il stock ses fichiers. Par défaut c'est ~/.wine mais lutris en crée sûrement un par jeu ailleurs. Une fois que tu as trouvé le préfixe, le sous-dossier drive_c aura la même organisation des fichiers que le C: de Windows.

[Manuel]

J'ai trouvé pour un, je cherche encore pour l'autre jeu...

[Illynir]

Regarde sur PCgamingWiki, tu as tous les chemins d'accés au sauvegarde sur tous les jeux.

[Nilsou]

Il y a aussi un problème dans la gestion de version des dépendances. Même si tu peux avoir libfoo.so.1 et libfoo.so.2, sous Linux la résolution de symbole se fait globalement et l'une des deux sera privilégiée. Et si dans le tas tu as des libs qui voulaient l'autre faut prier pour que ça marche (il y a normalement un versionnage fait au niveau des symboles mais c'est rarement utilisé).

Je ne comprends pas vraiment le problème en fait. Tu peux, il me semble, lier ton soft à une version précise d'une bibliothèque non ? Que la résolution du nom se fasse globalement ou non n'a alors aucun impact. Et idem, les bibliothèques en questions d'une version spécifiques dépendent d'autres librairies de versions bien précises.

J'ai l'impression que tout le bordel vient du fait que pas mal de programmeurs (de librairies également) ne s’embêtent pas et écrivent juste une dépendance sur la version en cours de la librairie. Mais n'est-ce pas de toute façon une très mauvaise pratique ?

En fait, pour résoudre proprement le problème il suffirait d'interdire l'usage des noms génériques pour les appels de librairies, pour obliger à la définition de la version précises.

Après je pense qu'il y a un truc que je ne comprends pas car pour moi tout ça est bien géré par APT et consort qui permet de définir des dépendances précises, j'ai jamais trop compris pourquoi Flatpack et autre Snap ont voulu faire leur sauce par dessus.

En plus de ça, tu te fais aussi très vite incendier dès que tu bundles des librairies dans ton application, parce que "c'est mal". Et effectivement c'est mal, et d'autant plus parce que les libraries en question vont dépendre d'autre libs fournies par le système dont l'API est instable, et rapidement casser la compatibilité.

Bof, je pense que pour tout plein de librairie c'est tout à fait faisable d'inclure les trucs en statique sans tout casser (surtout si elle même dépendent d'une version précise de librairies externes)...
Évidemment, pour les plus grosses c'est compliqués, mais c'est pas comme si la libc était un truc instable dans le temps ...

[Manuel]

Regarde sur PCgamingWiki, tu as tous les chemins d'accés au sauvegarde sur tous les jeux.

J'ai trouvé grâce à ce site pour un jeu sous Heroic mais ça n'indique pas le chemin pour celui dont j'ai besoin qui tourne sur lutris.
D'ailleurs je n'arrive pas à trouver où ce dernier met les sauvegardes malgré des recherches...

[rOut]

Je ne comprends pas vraiment le problème en fait. Tu peux, il me semble, lier ton soft à une version précise d'une bibliothèque non ? Que la résolution du nom se fasse globalement ou non n'a alors aucun impact. Et idem, les bibliothèques en questions d'une version spécifiques dépendent d'autres librairies de versions bien précises.

Non, tu peux avoir à la fois libSDL.so.2.3 et libSDL.so.2.4 chargées mais le symbole SDL_Init sera résolu vers l'une des deux et toujours la même quel que soit le code qui l'appelle. Sous Windows le code linké avec SDL2.3.dll va appeler SDL_Init de cette version, et le code linké avec l'autre version va bien appeler l'autre version.

Ca arrive plus souvent qu'on ne pense et en particulier dans les gros jeux avec une tripotée de middleware. Genre souvent plusieurs versions de xinput.dll sont chargées et utilisées à la fois.

J'ai l'impression que tout le bordel vient du fait que pas mal de programmeurs (de librairies également) ne s’embêtent pas et écrivent juste une dépendance sur la version en cours de la librairie. Mais n'est-ce pas de toute façon une très mauvaise pratique ?

En fait, pour résoudre proprement le problème il suffirait d'interdire l'usage des noms génériques pour les appels de librairies, pour obliger à la définition de la version précises.

Oui c'est une mauvaise pratique mais 99% du dev de jeux vidéos (et en général d'ailleurs) est basé sur des mauvaises pratiques. En particulier pour des contraintes de temps, d'argent et de flemme.

Après je pense qu'il y a un truc que je ne comprends pas car pour moi tout ça est bien géré par APT et consort qui permet de définir des dépendances précises, j'ai jamais trop compris pourquoi Flatpack et autre Snap ont voulu faire leur sauce par dessus.

Le bleeding edge.

Bof, je pense que pour tout plein de librairie c'est tout à fait faisable d'inclure les trucs en statique sans tout casser (surtout si elle même dépendent d'une version précise de librairies externes)...

Non, pour tout un tas de trucs ça ne marche pas. Ça marche en gros seulement pour les libs utilitaire et les scripts en ligne de commande. Tu veux faire des fenêtres, du multimédia, du son ou des graphismes, link dynamique obligatoire.

Évidemment, pour les plus grosses c'est compliqués, mais c'est pas comme si la libc était un truc instable dans le temps ...

Justement c'est bien le problème, elle pète régulièrement. Sans parler des différents libc alternatives qu'une distro peut décider d'utiliser ou encore des features optionnelles activés ou non à la compile (il y en a sans doute).

Le truc le plus stable actuellement ça doit être les trucs indispensables mais plus vraiment maintenus, genre la xlib.