C'est une bonne question, en effet. Il y a déjà dans gens qui ont de grosses responsabilités dans la maintenance du noyau, et il n'y a aucun doute qu'il y a des gens assez compétents et qui seraient volontaires pour prendre la suite de Linus. Mais la question qui se posera, c'est la légitimité : comment décider du successeur, et qu'il soit reconnu comme tel par tout le monde ? Honnêtement, je ne sais pas.
Greg Kroah-Hartman est pressenti pour reprendre le flambeau. Il est l'actuel mainteneur de la branche stable de Linux.
Je ne te conseille pas d’utiliser SteamOS pour l’instant si tu veux essayer Steam sous Linux. La version publique de SteamOS est toujours la vieille version qui n’a rien à voir avec ce qu’il y a aura dans le Steam Deck. Si tu veux essayer Steam et Proton sous Linux le mieux est de prendre le paquet Steam proposé par ta distribution préférée.
En fait tu n’as pas besoin de compiler Proton toi même pour l’installer. Proton est directement intégré à la version Linux de Steam, il s’active en quelques clics dans les préférences de Steam. Proton a une forte dépendance à Steam et pour le compiler il faut vraiment être développeur et savoir ce que tu fais. Il existe aussi des versions de Wine avec les patchs de Proton disponibles pour le launcher Lutris et elles s’installent en quelques clics également (pas besoin de compiler quoi que ce soit).
Ce sont des options de configuration pas des lignes de commande :) En tout cas c’est vraiment cool de voir que Valve considère l’écosystème Linux dans sa globalité et ne se limite pas seulement au hardware du Steam Deck.
Si tout le support est déjà dans le noyau alors il faut annoncer la version du noyau minimum à utiliser, ce n’est pas compliqué et ça évite de se poser des questions du genre “est-ce que ça va marcher avec ma distrib ?” Je présume donc que s’ils ne l’ont pas fait c’est certainement parce que le support Linux n’est pas du fait du fabricant mais de la communauté. Du coup ils n’ont aucune idée du noyau à partir duquel leur hardware fonctionne.
“compatible avec des environnements Ubuntu 18.04+” Quand les constructeurs se réfèrent à la version d’une distribution particulière pour dire qu’ils supportent Linux ce n’est généralement pas bon signe. Soit ça veut dire qu’elle utilise un module kernel “out-of-tree”, soit pire qu’elle nécessite un composant logiciel en espace user et qu’ils ont donc testé uniquement sous Ubuntu.
Détrompez-moi, mais les IO ne nécessitent que peu de puissance de calcul. Hors le propre de la parallélisation des processus, c’est que plus on parallélise, plus on a besoin de ressources pour gérer la parallélisation. Ce n’est donc efficace que sur les processus lourds qui nécessitent un traitement intensif des données, non sur la gestion des IO.
Je pense que ce n’est pas tant un problème de puissance de calcul que d’ordonnancement. Il est important d’optimiser les IO pour maximiser la bande passante du périphérique sans pour autant provoquer les IO_WAIT qui vont bloquer le CPU core sur lequel tourne le process qui a fait la demande.
J’utilise aussi Fedora mais encore en mode X11. Ceci dit on ne devrait plus avoir de soucis avec Wayland et les pilotes Nvidia maintenant (avec les pilotes 470). Normalement les jeux qui nécessitent X11 passent sous Wayland car ils s’exécutent via XWayland qui ouvre une session X11 pour l’application uniquement.
On a droit a une nouvelle release stable tous les 2 mois environs et les derniers datent du mois derniers, donc normalement les 470 devraient arriver d’ici la fin juin.
Il faudra attendre les prochains pilotes de la série 470.x pour que Steamplay/Proton puisse fonctionner avec le DLSS (ils doivent arriver ce mois-ci). Il faudra aussi sélectionner la branche Proton/Experimental dans Steam si vous ne l’utilisez pas déjà, avant que ce soit déployé dans une version “stable”.
Je n’ai pas trouvé de chiffres plus récents (bientôt dans le bilan de la société Valve ?) Voici ce que donnent les calculs, avec une projection à 150 millions, sachant que les stats Steam ne semblent pas toujours très fiables sur la prise en charge des OS (un compte steam tournant avec Wine sur un OS Linux est considéré comme Windows)
Vu la variation de % on peut tout aussi bien se trouver dans la marge d’erreur de la mesure, qui rappelons le se base sur un simple sondage qui “pop” de manière aléatoire chez les utilisateurs.
Plus que Windows, c’est plutôt Steam le problème car il s’impose de façon hégémonique avec maintenant une obligation de passer par Steam pour acheter et activer un jeu..
Un comble pour quelqu’un qui dit défendre la diversité et la liberté de choix..
En quoi Steam s’impose t’il plus que Windows ?
ça fait des années que Microsoft a un quasi-monopole sur les OS, et brusquement ce serait Steam le problème ?
Quand j’ai regardé, Unreal ne proposait pas d’IDE pour créer des scènes sous Linux.
Tout comme Unity quoi.
Aujourd’hui Unreal et Unity sont disponibles sous Linux, mais pas officiellement. On peut télécharger des builds de l’éditeur Unity à partir d’un thread spécial de leur forum. De même pour Unreal, l’édieur fonctionne sous Linux, mais Epic ne propose pas de build, il faut le compiler soit-même.
Actuellement Valve parle uniquement de Unity pour la VR car c’est le seul moteur tiers qui supporte Vulkan comme API de rendu sur le bureau (en beta)… C’est prévu sur Unreal, mais ce n’est pas encore dispo.
Vulkan étant l’API privilégiée par Steam VR sur Linux.
Tu as mal compris ce que j’ai écris. Je n’ai jamais dis qu’il était obligatoire de rentrer dans la fondation Linux pour supporter l’OS (ça se saurait).
Je parlais juste du fait que MS est obligé de supporter Linux s’ils veulent que leur service Cloud prenne des parts de marché, car la plupart des clients de service cloud utilisent Linux (75% d’après la Linux Foundation).
Pour ce qui est de décider des futurs évolutions, rentrer à la fondation Linux ne leur donne aucun droit de la sorte. ça facilite juste les échanges avec les autres développeurs. En outre en rentrant à la fondation MS s’engage aussi à promouvoir Linux… Je suis curieux de voir comment ils vont faire ça, sachant qu’ils ont tout de même un sérieux conflit d’intérêt.
En entrant dans la fondation ils bénéficient de canaux de communications privilégiés avec les développeurs, notamment lors des évènements organisés par la fondation .
ça leur permet à la fois de pouvoir discuter directement avec les développeurs, mais en plus de “vendre” leurs technos à des organisations qui ne sont pas dans leur écosystème.
Dans sa quête pour le marché du cloud, Microsoft n’a pas d’autres choix que de supporter Linux, qui détient plus de 75% de part de marché sur ce segment.
La seule mesure de sécurité qu’apporte le libre c’est dans le déploiement plus rapide de correctifs.
Avec un logiciel libre on peut déployer un correctif avant même les mainteneurs du projet (c’est impossible avec un logiciel propriétaire).
C’est d’ailleurs souvent ce que font les distributions.
Le libre c’est aussi la seule solution face à obsolescence programmée. Un logiciel libre peut-être corrigé même lorsqu’il a été abandonné par ses auteurs.
Tous les logiciels comportent des bugs qui peuvent potentiellement devenir des failles (c’était le cas de ce bug sur Linux qui à l’origine n’était pas identifié comme une faille).
Personnellement je me sentirais toujours plus en sécurité sur des softs pour lesquels je sais que je peux “les réparer” en cas de besoin, plutôt que sur un soft pour lequel je serais à la merci de ses créateurs.
Je retiens l’argument de la jeunesse, mais pour le reste c’est prévu pour ne pas dépendre de la distribution. Aprés c’est aussi simple à utiliser que le système de packaging classique (il n’y a rien qui choquera l’utilisateur de Linux).
Il faut en plus savoir que les portages de jeux sous Linux utilisent la plupart du temps une version plus ancienne d’OpenGL (pour des raisons de compatibilité, notamment avec MacOSX qui reste bloqué sur 4.1).
Du coup c’est comme comparer des softs qui tourneraient en DX9 avec ceux qui tournent en DX11.
je ne vais pas ré-argumenter, mais croire que sous linux les pilotes serait plus complet parce que la philosophie est differente est completement faux.
le fait d'avoir une interface n'est pas la traduction d'une bonne qualité d'un pilote.
sous windows, les pilotes sont livré avec l'interface qui controle le materiel
Sous linux il en est parfois de meme, il suffit de voir nvidia server settings, ou HPlip
Parfois ce logiciel tier est inlus dans un composant de l'OS (pulseaudio pour les cartes sons)
Mais souvent, ca manque.
si tu prend les webcam par exemple, tu verra que meme si le pilote déclare les fonctionalités, sans logiciel tiers, tu ne pourra jamais modifier leur parametres (leds, focus, etc..)
Le pilote tout seul, ne se suffit pas a lui meme. (essaye de configurer une manette xbox sans calibration..) Il faut d'une manière ou d'une autre sur un desktop, avoir une interface pour le controler
Je ne dis pas que tous les pilotes sont plus complets sous Linux, mais simplement que c’est le but visé par les développeurs. Par conséquent chercher un pilote en dehors du kernel n’est pas la norme sous Linux, contrairement à Windows.
L’interface graphique qui permet éventuellement de configurer son matériel n’est pas lié au pilote en soit. C’est une application qui utilise l’interface du pilote. En fonction du matériel, ce type de programme peut effectivement manquer sous Linux, tout dépends de la diffusion du matériel.
Je ne me contente jamais des pilotes de base, on ne sais pas s’il sont correctement optimisés matériellement parlant. C’est a dire qu’il utilisent au mieux toutes les fonctions matérielles de la puce libérant ainsi des ressources processeur.
C’est un peu comme se contenter des pilotes par défaut sous Windows. Et que dire du matos nouveau qui sort après la publication d’une distrib, il faut qu’il puisse être supporté aussi. Non ?
Quand tu administres des PC, que tu cherche l’identification du périphérique, les IRQ utilisés ou les adresses mémoire. C’est beaucoup plus accessible sous Windows que sous Linux. Par exemple configurer un port COM sous Linux c’est nettement moins accessible que sous Windows.
ça c’est un réflexe de “windowsien”, parceque tu sais que sous Windows les pilotes de base ne permettent pas de faire fonctionner le hardware comme il faut.
Sous Linux la philosophie est différente, les pilotes livrés avec le Kernel sont sensés être le plus complet possibles. On ne devrait pas devoir installer un logiciel tier pour faire fonctionner son matériel. Si on doit encore le faire pour certaines cartes graphiques, c’est simplement parce que le constructeur ferme les spécifications de son HW.
Maintenant c’est vrai qu’il n’y a pas de GUI pour configurer les ports com sous Linux, mais c’est quand même assez simple à faire en CLI (dmesg | grep ttyS* te donne toutes les infos sur tes ports séries)… Et honnêtement à part pour développer je me demande bien qui a encore besoin de configurer un port série. Hors si tu es développeur le shell Linux ne devrait pas te faire peur, au contraire il est ton meilleur allié ;)
La gestion de la vidéo (et des pilotes en général) c’est vraiment la bête noire de Linux, parce que sinon pour tout le reste c’est un bel OS, bien passionnant…
Sinon je me demandais, pour Steam OS si certaines cartes ne sont pas encore gérées (ou certaines fonctionnalité) ça veux dire que cet OS utilise les driver non-free ou ses propres driver ? Comment ils font ?
La gestion de la vidéo et des pilotes en général n’est pas aussi mauvaise qu’on le dit.
Les pilotes OpenGL de Nvidia par exemple sont excellents, et les pilotes libres des autres constructeurs s’améliorent constamment, (l’an prochain ils devraient même dépasser ceux de MacOS X en terme de compatibilité avec la norme OpenGL).
SteamOS utilise principalement les drivers propriétaires (car ils fournissent le meilleur niveau de compatibilité la plupart du temps), sauf pour les IGP Intel qui utilisent les drivers libres MESA. Normalement toutes les cartes sont gérées, mais pour les jeux il est encore préférable de privilégier Nvidia pour ses performances, et son haut niveau de compatibilité avec les dernières normes d’OpenGL.
sauf que vu tous les logiciels riches et les jeux premium qu’ils te manquent sur linux on se demande bien à quoi va te servir une config plus puissante en fait " />
Il ne me manque absolument rien. J’ai tout ce dont j’ai besoin sous Linux… Et les jeux il y en a désormais plus que je n’ai de temps à y consacrer.
Il y a une vraie volonté de la part de Valve et des acteurs de l’industrie de faire de SteamOS/Linux une plateforme de choix pour le développement de jeux vidéos.
Valve, Epic, Unity, Crytek développent tous leur morteur et leur outils sous Linux.
Cet été le Khronos group dévoilera également la version finale de Vulkan, l’API graphique ouverte de bas niveau qui répondra à DX12 et à Metal.
Le source Engine 2.0 devrait être un des premiers moteur à le supporter.
100 commentaires
Modifié le 02/12/2025 à 14h44
Le 26/11/2021 à 15h33
Je ne te conseille pas d’utiliser SteamOS pour l’instant si tu veux essayer Steam sous Linux.
La version publique de SteamOS est toujours la vieille version qui n’a rien à voir avec ce qu’il y a aura dans le Steam Deck.
Si tu veux essayer Steam et Proton sous Linux le mieux est de prendre le paquet Steam proposé par ta distribution préférée.
Le 26/11/2021 à 12h34
En fait tu n’as pas besoin de compiler Proton toi même pour l’installer.
Proton est directement intégré à la version Linux de Steam, il s’active en quelques clics dans les préférences de Steam. Proton a une forte dépendance à Steam et pour le compiler il faut vraiment être développeur et savoir ce que tu fais. Il existe aussi des versions de Wine avec les patchs de Proton disponibles pour le launcher Lutris et elles s’installent en quelques clics également (pas besoin de compiler quoi que ce soit).
Le 26/11/2021 à 09h04
Il n’y aura pas de DLSS sur le Steam Deck car c’est une techno propriétaire de Nvidia, mais par contre on aura le FSR d’AMD :)
Le 26/11/2021 à 08h29
Pour répondre au sous-titre, DLSS avec Vulkan est déjà supporté. On peut l’activer sur No Man Sky par exemple.
Le 26/11/2021 à 08h18
Ce sont des options de configuration pas des lignes de commande :)
En tout cas c’est vraiment cool de voir que Valve considère l’écosystème Linux dans sa globalité et ne se limite pas seulement au hardware du Steam Deck.
Le 27/10/2021 à 14h43
Si tout le support est déjà dans le noyau alors il faut annoncer la version du noyau minimum à utiliser, ce n’est pas compliqué et ça évite de se poser des questions du genre “est-ce que ça va marcher avec ma distrib ?”
Je présume donc que s’ils ne l’ont pas fait c’est certainement parce que le support Linux n’est pas du fait du fabricant mais de la communauté. Du coup ils n’ont aucune idée du noyau à partir duquel leur hardware fonctionne.
Le 27/10/2021 à 10h57
“compatible avec des environnements Ubuntu 18.04+”
Quand les constructeurs se réfèrent à la version d’une distribution particulière pour dire qu’ils supportent Linux ce n’est généralement pas bon signe.
Soit ça veut dire qu’elle utilise un module kernel “out-of-tree”, soit pire qu’elle nécessite un composant logiciel en espace user et qu’ils ont donc testé uniquement sous Ubuntu.
Le 13/10/2021 à 22h22
Je pense que ce n’est pas tant un problème de puissance de calcul que d’ordonnancement. Il est important d’optimiser les IO pour maximiser la bande passante du périphérique sans pour autant provoquer les IO_WAIT qui vont bloquer le CPU core sur lequel tourne le process qui a fait la demande.
Le 13/10/2021 à 09h53
La vitesse des E/S est un domaine où Linux est déjà plus performant, je pense qu’avec ce type de driver il enfonce le clou.
Le 24/06/2021 à 12h01
J’utilise aussi Fedora mais encore en mode X11. Ceci dit on ne devrait plus avoir de soucis avec Wayland et les pilotes Nvidia maintenant (avec les pilotes 470). Normalement les jeux qui nécessitent X11 passent sous Wayland car ils s’exécutent via XWayland qui ouvre une session X11 pour l’application uniquement.
Le 23/06/2021 à 11h29
Les nouveaux pilotes beta 470 apportent justement le support de Wayland :)
Le 22/06/2021 à 07h30
Comme prévu, les pilotes 470 pour Linux débarquent aujourd’hui et avec le support de la reprojection asynchrone pour la VR en bonus :)
Le 03/06/2021 à 15h59
On a droit a une nouvelle release stable tous les 2 mois environs et les derniers datent du mois derniers, donc normalement les 470 devraient arriver d’ici la fin juin.
Le 03/06/2021 à 15h16
Il faudra attendre les prochains pilotes de la série 470.x pour que Steamplay/Proton puisse fonctionner avec le DLSS (ils doivent arriver ce mois-ci). Il faudra aussi sélectionner la branche Proton/Experimental dans Steam si vous ne l’utilisez pas déjà, avant que ce soit déployé dans une version “stable”.
Le 05/03/2017 à 12h52
Le 03/03/2017 à 12h55
Le 03/03/2017 à 11h05
Le 03/03/2017 à 09h43
La plupart des volants à retour de force sont également supportés par cette version Linux :)
Le 03/03/2017 à 09h22
Le jeu est trés fluide même sur une config modeste, donc le coût du portage ne se fait pas vraiment sentir.
C’est super d’avoir enfin un trés bon jeu de rally sous Linux :)
Le 23/02/2017 à 13h42
Le 22/02/2017 à 13h51
Il n’y a pas que le nombre de fps qui compte.
Linux a d’autres avantages, comme souvent des loadings plus rapides, ou l’absence de DRM.
Les performances seront similaires dès lors que les développeurs utiliseront des APi 3D communes comme Vulkan, ce qui va se faire petit à petit.
Le 22/02/2017 à 13h14
Le 17/02/2017 à 16h26
Le 17/02/2017 à 12h44
Le 22/11/2016 à 13h35
Un système propriétaire, avec donc un support de pilotes limité ?
Aucune chance que ce truc soit utilisé dans les IOT.
Le 19/11/2016 à 21h09
Je suis curieux de connaître les performances d’une base relationnelle SQL qui tourne sur un noyau entièrement en espace user…
Le 19/11/2016 à 21h01
Tu as mal compris ce que j’ai écris. Je n’ai jamais dis qu’il était obligatoire de rentrer dans la fondation Linux pour supporter l’OS (ça se saurait).
Je parlais juste du fait que MS est obligé de supporter Linux s’ils veulent que leur service Cloud prenne des parts de marché, car la plupart des clients de service cloud utilisent Linux (75% d’après la Linux Foundation).
Pour ce qui est de décider des futurs évolutions, rentrer à la fondation Linux ne leur donne aucun droit de la sorte. ça facilite juste les échanges avec les autres développeurs. En outre en rentrant à la fondation MS s’engage aussi à promouvoir Linux… Je suis curieux de voir comment ils vont faire ça, sachant qu’ils ont tout de même un sérieux conflit d’intérêt.
Le 17/11/2016 à 15h29
La source c’est la fondation Linux elle même:
 https://www.linuxfoundation.org/about
Le 17/11/2016 à 15h28
En entrant dans la fondation ils bénéficient de canaux de communications privilégiés avec les développeurs, notamment lors des évènements organisés par la fondation .
ça leur permet à la fois de pouvoir discuter directement avec les développeurs, mais en plus de “vendre” leurs technos à des organisations qui ne sont pas dans leur écosystème.
Le 17/11/2016 à 14h50
Cette nouvelle n’est pas surprenante…
Dans sa quête pour le marché du cloud, Microsoft n’a pas d’autres choix que de supporter Linux, qui détient plus de 75% de part de marché sur ce segment.
Le 10/11/2016 à 15h38
Bof, ce que propose Molotov (bouquet de chaines avec le replay), la box VF le fait déjà.
Le 02/11/2016 à 14h52
Non ce n’est pas propre à VS, GCC permet le même type d’optimisation via l’option -fprofile-generate.
Le 23/10/2016 à 18h58
La seule mesure de sécurité qu’apporte le libre c’est dans le déploiement plus rapide de correctifs.
Avec un logiciel libre on peut déployer un correctif avant même les mainteneurs du projet (c’est impossible avec un logiciel propriétaire).
C’est d’ailleurs souvent ce que font les distributions.
Le libre c’est aussi la seule solution face à obsolescence programmée. Un logiciel libre peut-être corrigé même lorsqu’il a été abandonné par ses auteurs.
Tous les logiciels comportent des bugs qui peuvent potentiellement devenir des failles (c’était le cas de ce bug sur Linux qui à l’origine n’était pas identifié comme une faille).
Personnellement je me sentirais toujours plus en sécurité sur des softs pour lesquels je sais que je peux “les réparer” en cas de besoin, plutôt que sur un soft pour lequel je serais à la merci de ses créateurs.
Le 25/07/2016 à 09h05
Je retiens l’argument de la jeunesse, mais pour le reste c’est prévu pour ne pas dépendre de la distribution. Aprés c’est aussi simple à utiliser que le système de packaging classique (il n’y a rien qui choquera l’utilisateur de Linux).
Le 25/07/2016 à 08h42
Flatpack est aussi conçu pour de na pas être dépendant de la distribution (au même titre qu’appimage).
“Flatpak was built to be distribution agnostic and allow deployment on any Linux operating system out there.”
Le 25/07/2016 à 07h57
Quitte à nous servir une web-app, ils pourraient utiliser un système de packaging un peu plus universel (appimage ou flatpack) comme le fait Molotov.
Le 19/02/2016 à 15h48
Vivement que le pilote Vulkan rejoigne la branche courante, et qu’il soit déployé un peu partout !
Le 17/02/2016 à 07h50
Un petit schéma pour savoir à qui ça s’adresse:
http://www.phoronix.net/image.php?id=vulkan_10&image=vulkan_go_4_med
Le 16/02/2016 à 15h52
Le 10/02/2016 à 07h35
Pour connaitre la version d’OpenGL supportée, il suffit de lancer la commande suivante:
glxinfo | grep -i opengl
Je parie sur de l’openGL 2.1 ou 3.1
Le 24/11/2015 à 12h15
Il faut en plus savoir que les portages de jeux sous Linux utilisent la plupart du temps une version plus ancienne d’OpenGL (pour des raisons de compatibilité, notamment avec MacOSX qui reste bloqué sur 4.1).
Du coup c’est comme comparer des softs qui tourneraient en DX9 avec ceux qui tournent en DX11.
Le 24/11/2015 à 07h39
Il y a eu des patchs pour ça il me semble.
Je n’ai plus ce problème par exemple sous Fedora.
Le 23/11/2015 à 20h54
Le 23/11/2015 à 17h38
Le 23/11/2015 à 16h22
Qu’est-ce que tu entends par fonctions de base ?
Quelle est la GUI qui te manque ?
Le 23/11/2015 à 16h05
Le 22/07/2015 à 21h27
Le 22/07/2015 à 20h56
Le 29/06/2015 à 08h05
Il y a une vraie volonté de la part de Valve et des acteurs de l’industrie de faire de SteamOS/Linux une plateforme de choix pour le développement de jeux vidéos.
Valve, Epic, Unity, Crytek développent tous leur morteur et leur outils sous Linux.
Cet été le Khronos group dévoilera également la version finale de Vulkan, l’API graphique ouverte de bas niveau qui répondra à DX12 et à Metal.
Le source Engine 2.0 devrait être un des premiers moteur à le supporter.