Le fait est que maintenant, on peut installer « Ubuntu » dans Windows. Et ça marche :
spacefox@DESKTOP-A12BC3D:/mnt/c/Users/SpaceFox$ uname -a
Linux DESKTOP-A12BC3D 4.4.0-43-Microsoft #1-Microsoft Wed Dec 31 14:42:53 PST 2014 x86_64 x86_64 x86_64 GNU/Linux
spacefox@DESKTOP-A12BC3D:/mnt/c/Users/SpaceFox$ cat /etc/debian_version
stretch/sid
spacefox@DESKTOP-A12BC3D:/mnt/c/Users/SpaceFox$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.3 LTS
Release: 16.04
Codename: xenialLa vraie question est : à quoi est-ce que ça peut bien servir ?
J'invoque ici votre expérience : est-ce que vous avez essayé ce système ? En quoi vous est-il utile (ou en pourquoi l'avez-vous abandonné) ?
# Et surtout ...
Posté par Colin Pitrat (site web personnel) . Évalué à 10.
Est-ce que quelqu'un a essayé sous wine ?
[^] # Re: Et surtout ...
Posté par claudex . Évalué à -3.
Wine n'implémente pas (encore ?) le sous-système Linux de Windows. Donc, ça ne marchera pas. J'imagine que c'est loin d'être une priorité pour eux.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Et surtout ...
Posté par Seb . Évalué à 10.
Bientôt, la possiblité de faire tourner une appli dans un container dans le WSL d'un wine tournant sur une VM KVM dans le WSL d'un windows virtualisé.
Cette infrastructure permettra enfin d'avoir une appli qui donne le temps qu'il fait dehors en temps réel.
[^] # Re: Et surtout ...
Posté par Kerro . Évalué à 10.
Tu oublies d'indiquer un avantage énorme : lorsque tu virtualises sur une machine 4 cœurs par exemple, tu peux allouer 4 cœur à ta machine virtuelle.
Si tu installes une seconde machine virtuelle, tu peux aussi lui allouer 4 cœurs. Déjà tu as doublé la puissance totale.
Maintenant si tu « chaînes » les containers/virtualisations/etc comme tu l'indiques, tu fais exposant 2 à chaque fois ! C'est pour ça que les datacenters virtualisent tout mais continuent à nous faire payer plein pot !!!
Et maintenant ils génèrent même leur propre électricité pour encore plus de profit ! Je suis scandalisé !!
[^] # Re: Et surtout ...
Posté par Coninox (site web personnel) . Évalué à 10.
Personnellement, j'ai tenté l'inverse : installer wine sur ubuntu dans windows. Ça marche pas :)
# Retour
Posté par Seb . Évalué à 10.
Bonjour,
J'utilse le WSL depuis sa sortie, principalement pour avoir un client ssh digne de ce nom, et avoir accès à quelques commandes, scripts, outils CLI, sur un PC pro qui devait être sous Windows.
je l'utilise avec le l'émulateur de terminal WSLTTY qui fait plutôt du bon boulot.
Globalement j'en suis plutôt content.
C'est toutefois loin d'être une solution parfaite. En particulier :
- les performances sont variables. en particulier quand on travaille sur les partitions NTFS, j'ai des commandes GIT qui mettent plusieurs dizaines de secondes à s'éxécuter. C'est frustrant.
- on est parfois surpris par des limitations du sous-système linux (pas de possibilité d'utiliser ping par exemple)
- je n'ai pas réussi à joindre un service réseau linux depuis l'environnement windows.
En résumé de mon point de vue c'est un bon remplacement à CMD, surtout depuis que l'on peut lancer des binaires windows. mais si vous devez faire plus il vaut mieux avoir une VM.
[^] # Re: Retour
Posté par Marotte ⛧ . Évalué à 7. Dernière modification le 13 septembre 2017 à 03:11.
Le client SSH est digne mais fortement limité du coup, ou je rate un truc ?
[^] # Re: Retour
Posté par Psychofox (Mastodon) . Évalué à 8.
ssh en tant que client fonctionne très bien. Par contre pour avoir WSL il faut activer le developper mode qui ajoute aussi un service SSH server broker et qui écoute sur le port 22. Du coup même si tu installes openssh-server out of the box tu n'attendras pas le openssh server du wsl mais un mini serveur ssh de microsoft (sur lequel tu dois te logger avec le compte windows et pas celui du WSL) et qui fonctionne très mal. Ce qu'il faut faire c'est soit changer le port sur lequel openssh-server écoute, soit désactiver ce ssh server broker.
Ce qui ne fonctionne pas c'est un peu tout ce qui aurait à voir avec manipuler le stack réseau du windows, changer l'adresse ip, la table de routage de la machine executant WSL ou substituer le firewall windows par iptables ou firewalld.
[^] # Re: Retour
Posté par BAud (site web personnel) . Évalué à 7.
ou utiliser LibreOffrice qui implémente le firewall mis en place dans OpenOffice lors d'HADOPI avec Albanulle.
[^] # Re: Retour
Posté par Seb . Évalué à 3.
Il n'est limité que pour l'ouverture de tunnels. Mais comme je ne les utilise pas, pas de soucis pour mon usage.
Ma remarque visait surtout putty avec lequel j'ai beaucoup de mal. Via WSL j'ai quelque chose de beaucoup plus confortable (pour mon usage toujours)
Pour les limitations réseau c'est dans le sens client windows -> appli réseau linux que ça coince.
par exemple j'ai essayé de faire tourner une appli Django dans WSL, elle démarre, mais impossible de la joindre depuis un navigateur windows.
[^] # Re: Retour
Posté par xavier Granveaux . Évalué à 3.
Je tourne avec la 1709 depuis quelques semaines, et ceci est à présent possible …
le ping aussi fonctionne …
Tout doucement, le stack devient complet, et surtout, utilisable …
Dernier gros manquement pour mon usage: Le support de FUSE depuis WSL (d'ailleurs, s'il y a des insiders qui peuvent 'plusser' la demande d'évolution, ce serait chouette).
Pour être gourmand : support, sans bidouille, des applis graphiques, ce serait pas mal non plus …
[^] # Re: Retour
Posté par xcomcmdr . Évalué à 2.
J'utilise ConEmu (https://conemu.github.io/) + Gow (https://github.com/bmatzelle/gow/wiki) + Git (https://git-scm.com/download/win) pour Windows.
L'intérêt de WSL face à ça, c'est quoi ?
Des outils CLI qui sont absent de Gow ?
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Retour
Posté par Seb . Évalué à 3.
ConEmu, j'ai essayé, j'avais eu des petits soucis avec qui m'avaient poussé à tester autre chose. Je ne me rappelle plus en détail mais je crois que c'était lié à l'usage de certaines touches dans Vim. surement pas insoluble mais vu que j'avais moins de soucis avec WSLTTY je l'ai gardé.
Gow je ne connaissais pas mais j'ai l'impression que c'est similaire à Cygwin dans l'esprit.
Je voulais abandonner cygwin parce que c'était trop lent, ça vaudrait le coup d'essayer Gow.
L'avantage que je vois à WSL c'est quand même de filer accès à APT (ou à son gestionnaire de paquet favori maintenant que d'autres dispos sont supportées), et du coup on a facilement accès a certains outils dont je doute qu'ils soient dispo dans GOW (pdf toolkit, imagemagick, …)
[^] # Re: Retour
Posté par liberforce (site web personnel) . Évalué à 7.
Une raison de pas utiliser MSYS2 à la place ?
[^] # Re: Retour
Posté par Psychofox (Mastodon) . Évalué à 3.
Hormis Gow tu compares des trucs qui n'ont rien à voir. Quand j'utilise les WSL c'est dans ConEmu par exemple. Git c'est indépendnat.
L'intérêt de Gow face à WSL, c'est quoi ? _^
Plus sérieusement WSL te permet d'exécuter des binaires sans modification ou sans recompilation depuis les sources.
Par exemple. Point qui découle de celui-ci dessus.
Et le fait d'avoir accès au gestionnaire de paquets de la distribution utilisée par WSL est un plus.
[^] # Re: Retour
Posté par mouskouyouss . Évalué à 2.
T'es sûr que le problème avec GIT n'est pas plutôt la présence d'un antivirus qui analyse tous les changements au niveau système de fichier en temps réel ?
Car si tu as un PC pro sous Windows, il y a des chances que tu aies aussi un super antivirus Pro !!
[^] # Re: Retour
Posté par freem . Évalué à 4.
Il faudrait qu'il essaies avec le git compilé pour windows. Perso aucun souci autre que l'encodage avec (le natif windows).
# Alternative à cygwin
Posté par Psychofox (Mastodon) . Évalué à 9. Dernière modification le 12 septembre 2017 à 20:47.
Je l'utilise depuis le début de l'année pour les même cas d'usages qui me faisaient à une époque utiliser cygwin mais en mieux puisqu'on profite de tout l'ecosystème ubuntu. Avoir un client ssh digne de ce nom et pas se limiter à des putty et autres clickodromes peu efficaces, git, pouvoir installer divers languages ou utilitaires bien pratiques en
2 coups de cuillères à potun simple apt install plutôt que de devoir chercher un installeur et clicker 10x.C'est moins lourd que d'utiliser une vm même si certains trucs ne marchent pas encore.
Alors bon la grosse majorité du temps je préfère booter sur linux mais comme ma machine pro est un peu limitée en mémoire (8Go) des fois je préfère rebooter sous windows plutôt que de lancer une vm quand j'ai besoin d'un windows "en local"*
[^] # Re: Alternative à cygwin
Posté par Marotte ⛧ . Évalué à 3.
Pour Skype j’utilise Sky. C’est non-libre. Je n’ai pas testé la visio. Il me manque une fonctionnalité (la modification des listes de contacts) mais ça dépanne bien.
Il se peut que ça fasse même le café !
[^] # Re: Alternative à cygwin
Posté par Psychofox (Mastodon) . Évalué à 3.
Je l'utilise également. Néanmoins je trouve qu'il n'est pas parfait:
Au niveau audio ça fonctionne mais comme j'utilise la version gratuite limitée à 2 minutes je passe par le client sur l'application sur mon téléphone android quand j'en ai réellement besoin. Jamais testé la visioconf ni le partage d'écran pour cette même raison. Et comme windows reste le bureau standard je ne peux pas vraiment justifier l'achat du client sky sans cette limitation à mon employeur. Et c'est là la plus grosse limitation.
[^] # Re: Alternative à cygwin
Posté par paulez (site web personnel) . Évalué à 1.
T'as essayé pidgin-sipe ? À priori sous Fedora le plugin est compilé de manière à avoir le support vidéo (qui ne fonctionne pas sous Ubuntu 16.04 que j'ai au boulot).
[^] # Re: Alternative à cygwin
Posté par Psychofox (Mastodon) . Évalué à 4.
J'avais testé de mémoire mais probablement avec une version qui n'était pas au point…mais sans chercher trop loin. Ce n'est pas non plus comme si j'étais payé au boulot pour faire mumuse à tester x moyens de me connecter à un truc dont on m'a déjà fourni un client officiel. Du coup si ça ne marche pas au xième essai je ne me suis pas cassé la rate. J'utilise Sky 99% du temps et si je sais que je dois faire une visioconf ou travailler en partageant un écran je passe sous windows. Ça reste des usages sporadiques.
# Testé et laissé vite tomber
Posté par damaki . Évalué à 7. Dernière modification le 12 septembre 2017 à 21:25.
J'ai testé sous Windows 10 pro, dans le désordre :
- subsystem linux
- une vm graphique sous virtualbox
- vagrant sous virtualbox
- vagrant sous hyperv
- vmware sous windows
Le pire parce que y'a des trucs qui marchent pas au pif et sont obscurs à débugger :
- subsystem Linux pour Windows
Le meilleur en version graphique :
- vmware, de très loin pour les perfs
Le meilleur équilibre prix/fonctionnalité graphique :
- virtualbox parce qu'hyperv est une purge en mode bureau graphique
Meilleures perfs en console :
- vagrant sous hyperv mais c'est pas pratique parce qu'il faut démarrer la VM avec les droits d'admin
Pour usage pro et perso, au final, j'utilise virtualbox quand j'ai besoin d'applis graphiques et vagrant avec hyperv pour le reste, parce que les perfs déboîtent et parce que tout fonctionne correctement. Le seul souci de vagrant sous Windows c'est qu'il fonctionne pas très bien avec ConEmu, la meilleure console pour Windows.
A noter que virtualbox est incompatible avec hyperv, on ne peut pas lancer les deux en même temps. Mais on peut bricoler des options de boot windows pour lancer l'un ou l'autre.
[^] # Re: Testé et laissé vite tomber
Posté par Kerro . Évalué à 5.
Tu arrives à voir une différence entre VMWare et VirtualBox dans quelles circonstances ?
[^] # Re: Testé et laissé vite tomber
Posté par damaki . Évalué à 3.
C'est lent des accès à un lecteur hébergé sur disque dur, par exemple lors d'une compilation ou d'une transpilation avec aucune autre activité sur le disque. Même en dédiant un disque à ça exclusivement, c'est lent. J'ai pas fait de bench mais ça a l'air endémique.
[^] # Re: Testé et laissé vite tomber
Posté par Cyrille Pontvieux (site web personnel, Mastodon) . Évalué à 1.
Tu peux donner tes options de boot pour passer de l'un à l'autre stp, ça m'intéresse je suis sous win 10 pro au taff et j'ai galéré à désactiver hyperv pour lancer vbox.
Du coup une solution simple m'intéresse…
# Pour compiler Haiku
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 10.
Un peu par curiosité, on a essayé de compiler Haiku sous Windows en l'utilisant. Cela pourrait permettre à des développeurs sous Windows de contribuer à Haiku (c'est une des barrière à l'entrée qu'on a identifié dans notre participation au Google Code-In, programme qui vise à faire découvrir le logiciel libre aux 13-17 ans).
Le résultat dans notre cas est que c'est très lent (plus lent qu'un virtualbox avec Linux dedans), et qu'il y a encore des problèmes de compatibilité, mais on cherche un peu les ennuis:
- Pas de support des xattrs dans le système de fichier
- Pas possible de mettre le caractère : dans un nom de fichier
- Je me souviens pas de tout, mais il y avait quelques autres subtilités
Pour le moment nous allons continuer de recommander aux utilisateurs Windows qui veulent compiler Haiku de le faire dans une machine virtuelle.
# Pour faire simple...
Posté par Nicolas F. (site web personnel) . Évalué à 6.
Ce ne serait pas plus facile d'installer directement Linux à la place de Windows ???
[^] # Re: Pour faire simple...
Posté par BAud (site web personnel) . Évalué à 5.
c'est un bug à remonter sur l'anti-virus installé : ne pas savoir installer Linux pour éradiquer le plus gros virus sur le système est clairement une fonctionnalité de base manquante.
[^] # Re: Pour faire simple...
Posté par kna . Évalué à 10.
En milieu pro, quand tu es dans un environement Windows avec ActiveDirectory, Exchange, docs MS Office, imprimantes pas supportées sous Linux, et autres applis propriétaires c'est pas évident.
Pour ma part, j'ai quand même réussi à passer sous Linux au boulot, malgré l'environnement hostile. La seule contrainte qu'on m'a imposé est qu'il soit lié à l'ActiveDirectory. Je m'en suis sorti avec :
[^] # Re: Pour faire simple...
Posté par Psychofox (Mastodon) . Évalué à 4.
C'est une question un peu stupide. Les WSL sont destinés à des gens qui ont des besoins dans les deux environnements, windows et linux. C'est essentiellement un outil de développeur.
Le vrai hic c'est que windows ne fournit pas les sources de son OS et qu'il est impossible de faire aussi bien sous linux dans le sens inverse (wine c'est pas ça non plus même si ça peut aider).
# Attention : Bashware ?
Posté par bunam . Évalué à 2.
http://www.silicon.fr/400-millions-pc-windows-menace-bashware-184043.html?inf_by=59b93455671db869498b45bf
[^] # Re: Attention : Bashware ?
Posté par freem . Évalué à 2.
A noter, l'attaque passe par des binaires PE executes via wine… ca m'intrigue, me semblait que les A/V d's scannaient les binaires?
# outils de dev
Posté par Guillaume Knispel . Évalué à 8.
Ma principale utilisation, hors tests divers et variés, est la fourniture d'outils de dev in-house développés sous GNU/Linux a un autre département du taf, avec ainsi un environnement d'exécution virtuellement identique pour ces outils sous Win ou Nux. Étant donné ce qu'ils utilisent (Python, Clang, ssh), je peux faire sans WSL (et d'ailleurs j'ai testé sans avant que WSL existe), mais c'est plus facile avec, et nécessite moins de tests de ma part.
Le seul problème notable que j'ai rencontré est la compat avec les antivirus tiers pour Windows (notamment Kaspersky nique l'accès réseau de WSL, si mes souvenirs sont bons—mais on peut désactiver juste les features réseau de Kaspersky et tout rentre dans l'ordre)
À noter aussi que l'intégration avec Win32 est moins poussée que cygwin, MS ayant privilégié la compat avec un vrai Linux. Sur certains points j'aurais préféré des compromis; par exemple une émulation des perms Posix depuis les ACL win comme cygwin & co font—plutôt que le fs complètement isolé de WSL mais implémentant parfaitement les perms Unix classiques ( hormis /mnt/x/ pour accéder aux lecteurs X:\ ). Mais c'est clair que toute solution a des avantages et des inconvénients.
À noter que j'ai trouvé la compat très bonne même en version beta. En plus l'équipe est sans doute l'une des plus accessible et réactive de MS—et aussi très compétente au vu de quelques bugs traités avec eux. Bravo à eux !
# pratique ;)
Posté par fearan . Évalué à 3.
Mon portable est venu avec windows 10; c'est un bon remplacement à cygwin.
La possibilité d'utiliser sudo aptitude install est appréciable; ça permet d'installer git ou autre utilitaires sans avoir à se farcir des sites douteux ou choisir parmi les 50 appli proposé dans le store dont la moitié est pourrie de pub, l'autre ne correspond pas, et la dernière pèse 250mo par appli ;)
Comme toujours avoir un shell familier simple est pratique. Cependant exit tout ce qui est appli graphique et ça c'est un gros moins.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: pratique ;)
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 3.
On peut pas juste lancer un XMing et le connecter avec les applications WSL? Si le réseau passe ça devrait pas poser problème, non?
[^] # Re: pratique ;)
Posté par Psychofox (Mastodon) . Évalué à 3.
J'ai testé une application graphique aujourd'hui avec VcXsrv et ça marche.
[^] # Re: pratique ;)
Posté par claudex . Évalué à 5.
D'après cet article, on peut même faire tourner i3 https://blog.jessfraz.com/post/windows-for-linux-nerds/
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: pratique ;)
Posté par pizaninja . Évalué à 2.
Installe un serveur graphique X, et tu verras que ça marche plutôt pas mal…
# une alternative viable à la VM sous Windows
Posté par Rico Belo . Évalué à 3.
J'ai expérimenté un peu toutes les solutions :
- laptop windows avec VM Linux,
- laptop Linux avec VM Windows,
- laptop Linux avec Wine/Crossover,
- laptop Windows avec cygwin.
Aucune de ces solution n'est vraiment satisfaisante :
- avec les VM tournant sur l'hôte sur le laptop, on est toujours emmerdé avec des problématiques de réseau : un coup on bridge, quand on bouge, ça marche plus on est contraint de NATter, et je parle pas de la tambouille à faire entre les interfaces ethernet ou wifi… On a aussi des problème de conformité de l'OS qui ne correspond plus à l'image "corporate" avec comme corrolaire des fonctions qui sont désactivées par GPO (genre possibilité de connecter le VPN entreprise…)
- avec cygwin/crossover, on a une compatibilité partielle avec les outils d'entreprise. Je parle évidemment du couple infernal office/outlook, de skype pour windows, et tous les One machins poussés par M$. Rien ne marche vraiment correctement et on doit dépenser une énergie considérable pour palier à ces problèmes lorsqu'on travaille avec un équipe qui n'utilise que ces outils
- enfin, la solution cygwin ne m'a jamais convaincu. Certes on a des outils GNU compilés sous Windows, mais c'est pauvre, et surtout le terminal souffre des contraintes imposées par Windows. Bref j'aime pas.
Enfin, la solution du Bash Ubuntu pour Windows comble enfin mes besoins, surtout dans sa dernière version :
- avec un serveur X tiers (en attendant que M$ intègre un serveur X natif, ce qui AMHA finira par arriver), j'ai un "vrai" environnement de travail Unix directement sous Windows. Je me suis installé un un petit fluxbox bien minimaliste avec un simple apt-get, Mon Terminator chéri et roulez !
- j'ai mon environnement de travail habituel, avec mes .rcfiles syncronisées sur mes machines avec Git, je me connecte à mes serveurs avec openssh, ma clé privée est correctement gérée par ssh-agent, les quelques outils graphiques que je peux utiliser et qui n'ont pas leur pendant dans le monde M$ sont à portée d'un apt-get…
Bref, pour mes besoin d'adminsys, c'est le combo gagnant. Et techniquemnt je trouve que M$ a été très avisé d'implémenter ça à la manière de Wine, c'est à dire en wrappant les appels systèmes de Linux vers leurs pendant win64. En fait de manière générale, je suis de plus en plus fan des évolutions des OS de Redmond ces dernièrs mois, aussi bien pour Win10 que Win 2016 et sa version Core !
# Pour Darktable
Posté par aurelienpierre . Évalué à 1. Dernière modification le 18 septembre 2017 à 18:31.
Jusqu'ici j'ai installé le sous-système Ubuntu pour Windows 10 seulement pour faire tourner Darktable sous Windows. Ça marche globalement assez bien, quelques soucis de taille de menus (le HiDPI n'est pas reconnu correctement), une réactivité que je ne saurais comparer (la machine de test n'a pas Linux), et bien sûr le profil de couleur de l'écran est complétement indéterminé (est-ce que le profil couleur Darktable s'applique par dessus, par dessous ou exclut celui de Windows ? aucun moyen de savoir).
Le seul problème est qu'il faille passer par la console et un serveur X tiers pour lancer Ubuntu, du coup pour un non-geek… voilà.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.