Connexion Premium

Windows peut s’installer sur la Steam Machine, sans dual-boot pour le moment

La Steam Machine est une console de salon qui peut aussi faire office de PC de bureau. Il suffit de basculer dans le mode bureau de SteamOS pour avoir accès à une interface plus traditionnelle. Pour autant, certains utilisateurs voudront aller plus loin encore, et installer Windows. Le constructeur a mis en ligne de nouvelles ressources et pilotes.

La Steam Machine est qualifiée par Valve non pas de console, mais d’« extension du jeu sur PC ». Les constructeurs de consoles écoulent leur matériel sans aucune marge voire à perte (ce qui est de moins en moins vrai) et compensent par la vente de jeux et de services. Valve a préféré lancer un PC, un écosystème qui offre « la liberté de choisir à la fois ses jeux et son matériel ». Pour l’entreprise, cette explication est aussi un moyen de justifier l’absence de subvention sur son appareil, ce qui aurait permis d’abaisser un peu le feu de la facture.

La Steam Machine est d’ailleurs présentée comme un PC de bureau tout ce qu’il y a de plus traditionnel, en plus de ses capacités à trôner à côté de la télé pour jouer. SteamOS est basé sur Arch Linux et propose un mode bureau qui utilise un environnement de bureau KDE Plasma plus proche d’une interface classique. Il suffit de joindre au petit cube un clavier, une souris et un moniteur pour le transformer en ordinateur traditionnel.

Valve ne s’est pas arrêté à SteamOS. Il est ainsi possible de troquer le système d’exploitation maison contre Windows ; c’était déjà le cas avec le Steam Deck, ça l’est maintenant pour la Steam Machine. L’entreprise a livré les pilotes nécessaires à l’installation de l’OS de Microsoft : les drivers graphiques, Wi-Fi, Bluetooth et pour le lecteur de cartes SD sont désormais disponibles.

Malheureusement, on ne parle pas de dual-boot, où l’on pourrait choisir le système sur lequel démarrer ; ce sera soit SteamOS, soit Windows, mais pas les deux. Courage : une solution arrive. Valve promet un assistant pour le Steam Deck et la Steam Machine, qui sera fourni avec SteamOS une fois au point.

Installer Windows sur une Steam Machine (ou un Steam Deck) nécessite d’effacer toutes les données de l’appareil. Pour saisir la clé de l’OS, il faut une connexion internet et donc un branchement Ethernet pour réaliser l’opération, étant donné que le pilote Wi-Fi n’aura pas été installé.

Commentaires (21)

votre avatar
Pour saisir la clé de l’OS, il faut une connexion internet et donc un branchement Ethernet pour réaliser l’opération, étant donné que le pilote Wi-Fi n’aura pas été installé.
Halala Windows quelle galère de devoir installer les pilotes pour des choses aussi basiques que le Wi-Fi ! Et pourquoi pas les compiler aussi ? C’est pas sous Linux que ça arriverait ça tiens !

:troll: ?
votre avatar
C'est la première chose qui m'est venu à l'esprit ! :D
votre avatar
C'est plutôt à la saisie du compte Microsoft que ça va coincer.
Mais bon, si tu ne sais pas mettre les pilotes sur une clé usb, tu entres en sysprep, installe les pilotes puis reboot en mode Oobe et ça fonctionnera.
votre avatar
compte Microsoft
Connais pas :p
votre avatar
Après il y a pas mal de pilotes wifi pré-installés sur Linux et Windows mais encore faut-il ne pas choisir un obscur modèle de puce.
votre avatar
Ou un périph qui intègre elle-même les pilotes (c'est le cas de la dernière clé wifi que j'ai acheté, en la branchant, elle m'a proposé toute seule d'installer les pilotes).
votre avatar
J'ai eu la même chose avec un adaptateur USB vers Ethernet (incluant quelques ports USB supplémentaires) : tant que les pilotes n'étaient pas installés, il apparaissait comme une simple clé USB en lecture seule (ou un lecteur CD, peut-être, ça fait longtemps), sur laquelle les fichiers d'installation des pilotes Realtek USB Ethernet étaient présents. (Le lecteur correspondant disparaît une fois les pilotes installés.)
votre avatar
De mémoire, ne s'agit-il pas d'un sempiternel problème spécifique à ce système d'exploitation M$, qui écrase le secteur de démarrage sans se préoccuper de quoi que ce soit sinon lui-même ?
Rien ne serait alors bien nouveau sous le soleil.

Si SteamOS est un dérivé d'Arch Linux avec surcouche de composants privateurs, rien n'empêche donc de :

  1. Préparer le disque avec un support d'installation GNU/Linux, voire un Live CD/DVD, et redimensionner la partition préinstallée, afin d'enprévoir une nouvelle, vierge

  2. Installer le système d'exploitation problématique sur cette dernière

  3. Rétablir le secteur de démarrage qui aura été écrasé par l'OS problématique pour retrouver l'accès à l'ensemble de ceux existants



Cela nécessite une dose supplémentaire de travail : c'est tout le principe de la prison du système d'exploitation problématique.
Mais, là encore, rien de nouveau sous le soleil.
votre avatar
Les articles en anglais que j'ai lu, disent que c'est un "bug" ou un oubli dans la distrib SteamOS qui bloque ici. Windows s’accommode très bien d'un dual boot avec un secteur de démarrage géré par ce qu'on veut.
votre avatar
Oui c'est SteamOS qui ne supporte pas le dual boot
votre avatar
C'est pas parce qu'on peut qu'on doit le faire, parfois.
votre avatar
La question est, pourquoi aurais-t-on envie d'installer Windows sur cette machine ? :D

Non sans rire, c'est quand-même cool que Valve fournisse de quoi le faire, et aille même jusqu'à chercher à corriger le problème du dual boot, qui ne devrait pas être plus compliqué que refaire un grub-install après l'installation de Windows, et supporter la manette dans GRUB, A moins qu'ils ne préfèrent le faire depuis l'UEFI.
votre avatar
Jouer aux jeux avec abti-cheat (Battlefield, callof, fortnite, ....)
votre avatar
bah, il y a bien des tordus qui font tourner des applis en cobol dans des containers sur kubernetes...
votre avatar
y'a bien des gens qui font tourner du Cobol sur des systèmes critiques depuis 40 ans et plus :eeek2::reflechis:
votre avatar
Ah, mais j'ai pas de problème avec les applications retro tournant sur du matos retro, mais je ne suis pas sûr que leur place sur d'autres plateformes aient un sens. C'est un peu comme balancer une poubelle d'emballages plastiques dans le composte.
votre avatar
:cartonjaune:

le Cobol c'est un langage pour les vrais, les uptimes et les temps de réponses sont juste merveilleux.
Oui, c'est vieux, pas sexy, ça demande de se creuser la tête, mais c'est l'informatique que j'aime perso, au moins dans la démarche.

Je vois plutôt ça comme un vieux whisky de 30 d'âge ou un jambon de 48 mois qu'on voudrait servir dans un fast food.
C'est trop différent, ça ne va pas ensemble.

Je me souviens de mon prof d'info de DUT qui nous disait "ça fait 15 ans que j'entends la mort du Cobol pour dans 5-10ans, dans 20 ans, on en sera encore au même point".
C'était y'a 20 piges, le Cobol est toujours là, pour une raison simple, le service rendu par le langage est là et aujourd'hui, y'a rien qui fasse aussi bien avec les même contraintes de fonctionnement.
votre avatar
Et pourtant je HAIS ce langage ...
votre avatar
Lol un langage pour les vrais, les vrais quoi? ceux qui ont perdu tout intérêt dans les évolutions de l'informatique depuis 1985? qui se sont jurés de ne jamais commenter leur code? qui recevaient les listings de test d'intégration le matin, sur leur bureau en pile de papier continu? qui ont vu le basic et se sont dit "nah, trop moderne" ?...

Le cobol est surtout là parceque des boîtes comme IBM on fait un masterclass de vendor lock-in

Désolé, mais j'ai déjà donné, c'est un langage moche, primitif, dont la réelle raison d'être depuis 30 ans est de garder les clients captifs.

Maintenant on est avec des bombes à retardement un peu partout. Ce n'est pas whiskey qui a bien vieilli mais de la nitroglycérine qui séché et cristallisé.
votre avatar
Si on a une base de code critique qui coûtera un bras à migrer et que le matériel vintage qui l'héberge est mourant, j'imagine que c'est plus simple de le conteneuriser/virtualiser que de chercher à retrouver le matériel d'origine ou de rusher une réimplémentation plus moderne.
votre avatar
Le "matériel vintage" (le mainframe) n'est pas mourant... il est bien vivant et continue à faire tourner du code de plus de 50 ans d'âge... ce qui est peut-être mourant, c'est les finances des entreprises non-bancaires qui se sont jadis engagé dans cette voie. Faire tourner le cobol dans des containers est en outre loin d'être sans risque vu ce que cela représente comme changements, tant sur les dépendances externes que sur le dialecte Cobol lui-même.