De nouvelles distributions Linux à télécharger sur le Windows Store
Ce n’est pas demain la veille que l’on trouvera des distributions Linux sur le Mac App Store. Au contraire d’Apple, Microsoft a décidé d’ouvrir franchement les portes de son Windows Store, non seulement en accueillant iTunes mais en permettant à qui le souhaite de télécharger des distributions Ubuntu, Fedora et OpenSUSE directement depuis sa propre boutique.
Ce n’est pas une première pour Microsoft. En juillet dernier, Microsoft et Canonical avaient proposé le bash de Linux ainsi que les composants nécessaires pour exploiter les outils en ligne de commande. Il est depuis possible de faire fonctionner certaines interfaces graphiques de Linux — comme Ubuntu — en natif sur Windows 10 (lire : Windows 10 affiche les interfaces graphiques de Linux).
Les trois distributions seront donc proposées directement sur le Windows Store (il faudra toutefois activer le mode Developer sur le PC). Pas besoin d’installer de machine virtuelle puisque tout fonctionne sous Windows 10 directement.
C'est ÉNORME, encore un gros point en faveur de w10.
En quoi c'est énorme ? Il y a assez peu de différences entre Ubuntu, Fedora, et OpenSUSE, et elles sont particulièrement peu visibles pour quelqu'un qui n'utilise pas quotidiennement un système d'exploitation GNU/Linux en étant un utilisateur avancé ou une utilisatrice avancée (à l'exception du nom du gestionnaire de paquets). À titre personnel, j'utilise Debian et Trisquel (qui se base sur Ubuntu qui est basé sur Debian), et je ne ressens pas l'envie d'utiliser Fedora ou OpenSUSE. De plus, il y avait déjà la virtualisation.
Pauvre Tux :'(
Pourquoi ? Cela facilitera une potentielle transition sur un OS 100% libre (comme Trisquel GNU/Linux) ou au moins en grande partie (comme Ubuntu ou Fedora).
@RyDroid
Parce que la couche WSL est proprio, parce que c'est DinoSoft qui se sert du libre pour asseoir sa pdm et renforcer ses manques technologiques, et parce que il n'y a pas de potentielle transition, les utilisateurs resteront sous Windows...
Euh je ne comprends pas
C'est de la virtualisation Linux dans Windows 10 ?
Une sorte de parallels ou fusion intégré ?
@deltiox :
https://blogs.msdn.microsoft.com/wsl/
Mieux qu'une machine virtuelle, un compatibility layer integré (sur Mac, on avait l'habitude, à une époque...)
La dernière fois que j'ai testé, il y avait encore plein de petites choses qui clochaient, le plus embêtant étant le GUI. Mais ça semble avancer. Et le truc est assez génial, s'il finit par bien marcher.
WSL a déjà sa page Wiki, assez bien tenue, qui donne un bon aperçu :
https://en.m.wikipedia.org/wiki/Windows_Subsystem_for_Linux
J'aimerais juste savoir dans quelle direction ira Ubuntu, parce que pour 17.04, ce n'est pas encore évident pour la suite du GUI.
macOS commence à rester sérieusement à la traîne, conceptuellement. Dommage.
Mac OS X est a la traîne dans quel sens ?
Pas vraiment besoin de «subsystem» pseudo compatible linux... Ca marche deja depuis la v 10.0 de mac OS X.
J'ai testé windows 10 et faire tourner des scripts bash reste encore un doux rêve (pas mal d'incompatibilités...)
Windows va dans le bon sens pour son Shell. Mais je ne voit pas de quel retard tu parles pour Mac OS X...
OS X est obliger de lancer Linux en machine virtuel que w10 le fait directement dans l'os avec cette maj qui permet de les télécharger directement sur le store donc pour le retard de OS X ça devient évident
Mais est ce que ça marchera bien ?
C'est du natif donc il n'y a pas de raison
@ Ghaleon111 : « C'est du natif donc il n'y a pas de raison »
Ce n’est pas un noyau Linux tournant dans Windows, c’est une couche de compatibilité développée par Microsoft (en gros, un truc qui, vis-à-vis des logiciels pour Linux, simule la présence du noyau).
Donc si, il y a bel et bien des raisons pour lesquelles il peut y avoir quelques soucis, comme toujours dans ce genre de cas. C’est parfaitement normal vu l’approche utilisée.
@ Ghaleon111 : « OS X est obliger de lancer Linux en machine virtuel que w10 le fait directement dans l'os »
Certes, mais il convient de se demander pour quelle raison on voudrait utiliser ces distributions « Linux » (entre guillemets juste parce que dans ce cadre elles ne sont plus des distributions Linux à proprement parler) dans Windows. C’est pour utiliser des logiciels précis dont on a besoin. Microsoft, dans sa communication sur ce sujet, a jusque là présenté la chose comme étant surtout à destination des développeurs (notamment les développeurs web).
Or ce que faisait remarquer Un Type Vrai, c’est que la plupart de ces logiciels, on peut les faire tourner nativement sur Mac OS (en dehors du cas relativement rare du logiciel pour Linux distribué uniquement sous forme compilée), et ce depuis longtemps (Mac OS X étant là, avec sa couche Unix, depuis plus de 15 ans — même s’il a fallu quelques années pour qu’une compatibilité « facile » avec les trucs venus de Linux se mette bien en place).
De ce point de vue, on a donc plutôt affaire à Windows qui rattrape son retard (dans ce domaine) qu’à un grand bond en avant qui laisserait Mac OS loin derrière.
Note que je ne cherche pas à minimiser l’intérêt de cette fonction pour les utilisateurs de Windows auxquels elle servira, ni l’élégance de son implémentation. Je souligne juste, comme Un Type Vrai, que ça ne fournit pas à Windows un attrait inédit et irrésistible par rapport à Mac OS, où on a un service similaire (dans sa finalité et non son implémentation) depuis longtemps.
L’intérêt est de justement pouvoir utiliser linux sans virtualisation donc carrément l'os (ce que ne permet pas osx sans virtualisation) meilleurs performances et beaucoup plus pratique sans rien a régler, ce n'est pas que d'utiliser des logiciels linux spécifiques donc c'est un gros attrait pour qui aime le pingouin et qui en a besoin donc W10 a bien une grosse avance
@ Ghaleon111 : « L’intérêt est de justement pouvoir utiliser linux sans virtualisation donc carrément l'os (ce que ne permet pas osx sans virtualisation) »
Mais justement, ce que je disais, c’est que ça, ça ne présente pas d’intérêt particulier. Ce sont les logiciels qui tournent dessus qui intéressent l’utilisateur, pas l’OS lui-même (surtout quand il est noyé au sein d’un autre OS).
« donc c'est un gros attrait pour qui aime le pingouin et qui en a besoin donc W10 a bien une grosse avance »
Tu l’as dit : ça peut faire rêver « ceux qui aiment le pingouin » (mais pas au point d’assumer de passer réellement sur un tel OS, apparemment). Mais ceux, sans doute plus nombreux, qui sont surtout intéressés par ce que ce pingouin fait tourner comme logiciels, ne sont pas dérangés par la perspective d'utiliser les dits logiciels sans avoir à se frapper l’intégralité du machin.
Je n’espère toutefois pas avoir la moindre chance de te convaincre de la réalité de ce que je t’explique là. :-)
Je comprend ce que tu dis, c'est juste que je fais partie de ceux qui aiment utiliser aussi Linux avec tout les avantages qu'il offre et sans avoir besoin de bidouille pour installer des logiciels linux ;)
@ Ghaleon111 : « Je comprend ce que tu dis, c'est juste que je fais partie de ceux qui aiment utiliser aussi Linux avec tout les avantages qu'il offre »
Je vois ça, mais là avec cette approche, tu n’utilises pas vraiment Linux et tu perds une partie de ses avantages.
Ce système est vraiment fait pour les gens dont l’intérêt est plus pour les logiciels qui tournent sur Linux que pour les OS à base Linux eux-mêmes. Dans son dernier commentaire, byte_order a fourni une parfaite illustration de ce à quoi sert WSL.
Maintenant, si je te dis que w10s pourra aussi lancer ces linux ;)
@Ghaleon111
Heu, tu es au courant que macOS est déjà un système UNIX et que les trucs comme Bash font déjà partie de l'OS ? Quel serait l'intérêt d'avoir Linux en natif dans macOS ? Si tu arrives à l'expliquer, je suis preneur.
Déjà dit, pouvoir utiliser ubuntu ou d'autres distrib sans machine virtuelle ce que osx ne pourra pas faire contrairement a w10
OSX et macOS pourrait le faire. Windows 10 ne gère toujours pas la couche graphique, c'est donc loin de remplacer la virtualisation pour un certain nombre d'usages.
Bien sûr qu'il gère la couche graphique dans le cas présent de Ubuntu, fedora et open suse
Il y'a d'ailleurs déjà moyen d'avoir l'interface graphique d'ubuntu mais il faut de la bidouille
@Un Type Vrai
Ghaleon111 —> What the man said...
J'ajoute seulement qu'il n'y a rien de « pseudo » dans WSL, faut vraiment déposer vos oeillères au vestiaire, pas plus que le Linux compatibility layer directement dans le kernel de FreeBSD n'est une émulation.
En fait, c'est à la capacité de FreeBSD de faire tourner nativement des binaires Linux 64-bits qu'il faudra mesurer WSL.
Si WSL arrive à faire à peu près aussi bien, il sera prêt pour le prime time.
Le "pseudo" vient directement de leur explication dans le lien donné dans l'article...
Ce n'est pas un noyau linux et ça ne marche pas comme un noyaux linux.
PS : Pour les oeillère, j'ai testé moi...
@occam
Merci
@ occam : « Mieux qu'une machine virtuelle, un compatibility layer integré (sur Mac, on avait l'habitude, à une époque...) »
L’habitude d’une couche de compatibilité Linux ?
@BeePotato
«L’habitude d’une couche de compatibilité Linux ? »
Très malin. Vous savez exactement de quoi je parle. Yellow Box API dans feu Rhapsody.
@ occam : « Vous savez exactement de quoi je parle. Yellow Box API dans feu Rhapsody. »
Non, je n’en savais en fait rien du tout.
Et je comprends mieux pourquoi. D’une part, ça faisait référence à un truc dont on ne peut pas dire qu’« on en avait l’habitude sur Mac », puisque ça n’a été présent que dans un OS qui n’a jamais été distribué avec les Mac (une seule version en a été commercialisée, brièvement et juste pour usage serveur).
D’autre part, c’est quelque chose qui n’a que bien peu de rapport avec ce que présente l’article, puisque l’article parle d’une couche de compatibilité binaire permettant de faire tourner directement les logiciels compilés pour Linux, alors que les API Yellow Box n’étaient qu’une couche de compatibilité au niveau des sources pour les application OpenStep, nécessitant de les recompiler pour les faire tourner sur Rhapsody.
Il aurait été vraiment difficile de deviner cette réference, donc.
Franchement, j’imaginais que ça faisait plutôt référence à l’environnement Classic, qui reposait, lui, sur le même principe utilisé pour WSL.
@BeePotato
Il faut d'urgence que tu te renseignes sur Carbon, qui a permis de commencer à adapter des applications sur Mac OS 9 en prévision de la migration majeure vers Mac OS X. Ce même Carbon a survécu à plusieurs versions de Mac OS X. Quant à Cocoa, son histoire est interessante aussi, en surcouche de Carbon pendant un temps, les additions n'étant pas en surcouche, avant l'élimination progressive de Carbon sous Cocoa.
Les deux API ont coexisté quelque temps sans que l'une repose encore sur l'autre.
Classic était une sorte de machine virtuelle avec un embryon d'hyperviseur, un OS 9 quasi-complet tournait dedans.
@ fte : « Il faut d'urgence que tu te renseignes sur Carbon »
Et pourquoi faudrait-il que je me renseigne sur Carbon, que je connais déjà très bien et que j’ai utilisé ?
Merci d’éviter de considérer que je ne sais pas de quoi je parle, ça nous fera gagner du temps. :-)
Temps qui pourrait être utilisé, par exemple, pour m’expliquer ce que cette allusion à Carbon vient faire au milieu de cette conversation, alors que ce framework n’a rien à voir avec ce sujet.
Pour Classic, je maintiens ce que je dis quant au fait que c’était ce qui aurait le plus collé à la (très) vague remarque d’occam.
@BeePotato
Pas besoin de grimper sur ton cheval.
J'ai du mal interpréter ton propos, ou peut-être que ton propos était mal formulé.
Parce que ce que fait Microsoft avec sa compatibilité Linux en développement, si si, on en a très très l'habitude sur macOS. Enfin, Mac OS à l'époque. Car on en a eu plein sous tout un tas de formes, binaires, APIs, hyperviseurs, architectures hybrides y compris au runtime, etc, tout ce qui était raisonnablement possible dans ce domaine a été fait et exploité sur Mac OS.
C'est le macOS actuel qui est surprenant en réalité. Pas d'émulation, pas d'API multiples... Bon, Swift et ObjC. Je ne suis pas sûr que ça entre dans la même catégorie.
@ fte : Il ne s’agit pas de faire du cheval. :-)
Mais si, comme je l’ai suggéré, tu te forçais à imaginer que ton interlocuteur sait peut-être bien de quoi il parle, ça te permettrait parfois de remettre en question ton interprétation de ses propos. Ou même, dans le cas présent, ta compréhension du sujet de la conversation — parce qu’avec Carbon, tu es vraiment à côté.
« Parce que ce que fait Microsoft avec sa compatibilité Linux en développement, si si, on en a très très l'habitude sur macOS. »
Pas tellement, non, mis à part avec Classic. Mais Classic était dès ses débuts annoncé comme une solution temporaire.
« Car on en a eu plein sous tout un tas de formes, binaires, APIs, hyperviseurs, architectures hybrides y compris au runtime, etc, tout ce qui était raisonnablement possible dans ce domaine a été fait et exploité sur Mac OS. »
Le seul truc comparable à ce que fait Microsoft ici vis-à-vis de Linux, c’était Classic.
Les API assurant une compatibilité partielle avec l’ancien (Carbon et Cocoa, donc), c’était déjà très différent (et une approche beaucoup classique), puisque nécessitant une recompilation après une adaptation du code.
Le reste a encore moins de rapport avec ce qu’est WSL.
En revanche, il est vrai qu’on a l’habitude de voir Apple utiliser des solutions diverses et variées pour assurer une compatibilité des anciens logiciels Mac OS lors de gros changements normalement destructeurs de compatibilité. La plus intéressante, de mon point de vue, était l’émulateur 68040 pour les PowerMac et son Mixed Mode Manager.
« C'est le macOS actuel qui est surprenant en réalité. Pas d'émulation, pas d'API multiples... »
Ça s’appelle une période de stabilité. Oui, on peut trouver ça surprenant de la part d’Apple. :-)
En revanche, d’habitude les utilisateurs ne s’en plaignent pas trop.
« Bon, Swift et ObjC. Je ne suis pas sûr que ça entre dans la même catégorie. »
Pas vraiment la même catégorie, en effet.
@BeePotato
"tu te forçais à imaginer que ton interlocuteur sait peut-être bien de quoi il parle, ça te permettrait parfois"
Tu as de l'expérience. Tu navigues sur internet depuis longtemps à ce que je comprend.
Tu sais donc qu'il est totalement déraisonnable de penser avoir affaire à quelqu'un de compétent. Une bourde par an, je survivrais. :p
Quant à être à côté, tombons d'accord que nous ne sommes pas d'accord. C'est la même chose, avec des solutions techniques un peu différentes mais pas tant que ça. En tout cas l'objectif est très similaire : permettre l'exécution d'applications en provenance d'autres OS, par une couche de compatibilité. Classic de ce point de vue est la solution la plus divergente dans la mesure où il ne s'agissait pas d'une couche de compatibilité mais d'une VM quasi-complète. Carbon permettait même d'utiliser le code fragment manager et ses XCOFF au lieu de Mach-O.
Quoiqu'il en soit, Microsoft propose quelque chose de vraiment pas innovant, mais on s'en fout, parce que c'est absolument génial de disposer de cette couche de compatibilité. En tout cas je m'en réjouis, ça tombe à pic puisque mon bureau sera dépourvu de Mac d'ici deux semaines, pour la première fois depuis 30 ans.
Et dire que w10s que tu déteste pourra aussi lancer ces distrib ^^
Non, il ne pourra très certainement pas.
En l'état actuel, le developer mode n'est pas supporté sur Windows 10S, mode nécessaire pour la compatibilité Linux.
Ce n'est apparemment pas confirmé (ou infirmé) par Microsoft yet.
Hyper-V n'est pas non plus disponible. C'est la même logique.
Edit : j'ai même un lien tiens, vu que tu ne sembles pas te donner la peine de te renseigner par toi-même. http://www.financialexpress.com/industry/technology/microsoft-launches-windows-10s-how-is-it-different-from-windows-10-operating-system/651990/
Ah dommage, les futurs produits w10 arm seront plus intéressent alors
@ fte : « Tu sais donc qu'il est totalement déraisonnable de penser avoir affaire à quelqu'un de compétent. »
Non. Ce que je sais, c’est que je vois beaucoup trop de réactions qui reposent sur l’a priori que l’interlocuteur est forcément incompétent.
Beaucoup trop de réactions aussi qui se reposent sur une lecture incomplète de ce à quoi on réagit. Par exemple ici, dans mon dernier commentaire, se glissait un « peut-être » qui avait toute son importance, parce que par la magie de ce petit mot je ne te demandais pas de penser avoir affaire à quelqu’un de compétent, mais juste de te forcer à te dire que ce n’est pas forcément quelqu’un d’incompétent — ce qui n’est pas du tout la même chose.
Il s’agit juste de conserver une part raisonnable de doute, pour tenter d’interpréter les propos d’autrui selon deux hypothèses (compétence et incompétence) au lieu de juste foncer sur celle qui t’arrange. ;-)
« Quant à être à côté, tombons d'accord que nous ne sommes pas d’accord. »
Ça, c’est fait depuis longtemps. Je n’ai ensutie fait que t’expliquer en quoi tu te trompais.
« C'est la même chose, avec des solutions techniques un peu différentes mais pas tant que ça. »
Non, ce sont deux choses bien différentes.
Dans un cas (WSL), il s’agit de faire tourner directement des applications compilées pour un autre OS. Rien d’autre à faire pour l’utilisateur que de les installer.
Dans l’autre cas (Carbon et Cocoa), il s’agit de faciliter la vie des développeurs en simplifiant au maximum le portage de leurs applications venues d’ailleurs — mais qui reste un portage, notamment avec un étape obligatoire de recompilation. Ça ne concerne pas directement l’utilisateur final.
« Classic de ce point de vue est la solution la plus divergente dans la mesure où il ne s'agissait pas d'une couche de compatibilité mais d'une VM quasi-complète. »
Le « quasi » est le mot que tu as choisi pour ignorer la couche de compatibilité binaire qui fait que Classic est ce qui se rapproche le plus, dans tout ce qui a été cité, de WSL ? :-P
C’est bel et bien, pour reprendre des termes similaires aux tiens, la solution la moins divergente (sans que ce soit, bien sûr, strictement la même chose).
« Quoiqu'il en soit, Microsoft propose quelque chose de vraiment pas innovant, mais on s'en fout »
En effet, on s’en fout tellement que personne n’a même évoqué cet aspect jusque là.
Parce que bien que ce ne soit pas innovant d’un point de vue technique, c’est en revanche assez innovant d’un point de vue commercial.
« En tout cas je m'en réjouis, ça tombe à pic puisque mon bureau sera dépourvu de Mac d'ici deux semaines, pour la première fois depuis 30 ans. »
Bon courage ! :-)
Dans mon cas, la perspective de pouvoir faire tourner des logiciels pour Linux sur un Windows serait loin de compenser l’absence de Mac.
100% sérieux hein ? Rien ne te déride. OK.
Parlant de parti pris, et si tu oubliais cette idée que quelqu'un a raison et l'autre tord ? Et si tu oubliais aussi de supposer que j'ignore intentionnellement des choses en les cachant sous des mots clé de DRH ? J'ai commis l'erreur de supposer que tu n'étais pas méga-familier avec Carbon, soit, my bad, tu choisis d'interpréter ça comme une supposition d'incompétence (le cheval - pardon, 100% sérieux), ce qui est un brin un procès d'intention, mais ce n'est pas mon problème. Je ne sais pas si tu es énervé, mais tu n'es pas en reste pour supposer, corriger, faire la leçon.
Nous avons deux points de vue différents. C'est tout.
@ fte : « 100% sérieux hein ? Rien ne te déride. OK. »
J’ai pourtant mis quelques smileys par-ci, par-là. ;-)
« Parlant de parti pris, et si tu oubliais cette idée que quelqu'un a raison et l'autre tord ? »
Ce n’est pas un parti-pris, c’est juste une constatation, et qui valable uniquement pour ce cas précis, dans cette partie de notre échange de commentaires.
« Et si tu oubliais aussi de supposer que j'ignore intentionnellement des choses en les cachant sous des mots clé de DRH ? »
Gné ?
« J'ai commis l'erreur de supposer que tu n'étais pas méga-familier avec Carbon »
Plus encore que « pasa méga-familier », c’était « pas au courant du tout » que ta formulation m’a laissé supposer.
« tu choisis d'interpréter ça comme une supposition d’incompétence »
Ben c’est bien ce que c’était : une supposition d’incompétence sur ce sujet précis — tu viens d’ailleurs de dire que c’était bien ça.
Je n’ai pas écrit que tu me soupçonnais d’être totalement incompétent surtout. J’ai juste suggéré que tu aurais pu envisager l’hypothèse que je savais de quoi je parlais lorsque je m’exprimais sur le sujet (relis la façon dont j’ai formulé ça, tu verras).
C’est uniquement toi qui transformes ça en procès d’intention à bien plus grande portée.
« mais tu n'es pas en reste pour supposer, corriger, faire la leçon. »
Supposer, j’essaye de me forcer à ne pas trop le faire, justement pour éviter de participer à ce que je dénonçais dans mon commentaire précédent.
Corriger et faire la leçon, oui, je le fais sans retenue quand j’ai l’impression de m’adresser à quelqu’un qui en vaut le coup (c’est-à-dire quelqu’un qui sera satisfait qu’on lui ait permis d’apprendre quelque chose en lui faisant remarquer une erreur).
« Nous avons deux points de vue différents. C'est tout. »
Deux points de vue, dont l’un est erroné (en tout cas, à en juger par la présentation qui en a été faite ici). C’est tout. ;-)
Alors je suppose que ça ne vaut pas la peine de confronter des points de vue, puisque tu as juste et que j'ai faux. Ce que j'en pense n'a pas d'intérêt pour toi.
Carbon EST TOUJOURS une API native de macOS au même titre que Cocoa, même si laissée de côté aujourd'hui. Pas une sur-couche ou une sous-couche.
https://en.wikipedia.org/wiki/Architecture_of_macOS
Le but de Carbon était de proposer une API C et C++ pour les développeurs à côté de Cocoa l'API Objective-C héritée d'OpenStep. Carbon lui provient de Coplan.
Occam parle lui de Rapsody qui était très différent de Mac OS X.
Contrairement à ce qu'on croit généralement, il n'y a pas de continuité entre eux deux. Une confusion a volontairement été entretenue à l'époque par Jobs pour enfumer les développeurs issus de NeXT par l'introduction de Mac OS X Server 1.0, en fait une variante de Rapsody et pas le nouvel Mac OS X.
https://en.wikipedia.org/wiki/Rhapsody_(operating_system)
"Carbon EST TOUJOURS une API native de macOS"
Euh.
C'est du "bricolage" parce que DinoSoft est incapable de fournir ses propres solutions performantes, stables, "désirables" pour du dev web/serveur et qu'il ne veut pas laisser un peu d'air aux systèmes et entreprises alternatives (règles des 3 E).
Et dire que Balmer était en guerre contre Linux
Oui. Mais cette guerre est perdue.
C'est mieux en sourcant :
https://web.archive.org/web/20011211130654/http://www.suntimes.com/output/tech/cst-fin-micro01.html
http://www.zdnet.fr/actualites/steve-ballmer-ex-microsoft-linux-n-est-plus-un-cancer-39833942.htm
Question pourra t on en profiter sur le mac via Windows 10 ?
C'est vraiment de la branlette pour geeks.
Il n'y a rien que Linux puisse faire et dont Windows est incapable.
Donc utiliser Linux sur Windows, c'est vraiment, vraiment, de la branlette pour geeks.
En dual boot comme système alternatif je dis pas, mais émulé ......
D'une part, c'est pas de l'émulation, mais bien une couche user compatible Linux mais tournant sur un noyau non Linux.
D'autre part, dans l'univers des developpeurs, oh que si y'a plein de trucs que Windows n'est pas capable de faire facilement. Le scripting d'Unix est nettement plus puissant et répandu que celui, ajouté que trop tardivement, de Windows, par exemple, et les préhistoriques .bat font mal aux yeux...
Et devoir rebooter pour pouvoir en profiter plutôt que d'ouvrir une fenêtre, c'est pas franchement le même coût ni le même confort (copier coller de l'un à l'autre, communication entre un client Windows et un service sous Linux - ou l'inverse, bien que plus rare - sur la même machine *en même* temps sans devoir lâcher des méga voir des giga de mémoire pour une VM...
Exemple vécu récent lors d'une démo :
- ordinateur portable sous W10
- une application cliente compilée natif pour W10
- une base mongodb + web service en nginx + uwsgi + python flask + tâches lourdes en process compilés, le tout sous une WSL Debian
= démo facile, avec une pile techno identique à celle qui est déployée côté serveur, mais sans besoin d'accès à un serveur distant ni de VM Linux mangeuse de ressource du faiblard ordinateur portable, et donc des performances (mongodb et tâches lourdes) nettement plus correctes, donc effet whaou meilleur, sans changer de matos...
@byte_order
« Exemple vécu récent lors d'une démo :
- ordinateur portable sous W10
- une application cliente compilée natif pour W10
- une base mongodb + web service en nginx + uwsgi + python flask + tâches lourdes en process compilés, le tout sous une WSL Debian »
Superbe exemple.
C'est exactement le type de truc qui fait l'intérêt de WSL.
Et c'est exactement le genre de truc qu'il suffit d'expérimenter une fois en live pour ne plus jamais, jamais avoir le malheur de lancer une phrase du genre « Il n'y a rien que Linux puisse faire et dont Windows est incapable ». Mais bon, il faut d'abord apprendre la leçon de choses pour pouvoir sortir de son ornière.
Pages