Le topic de Windows 10 - Page 34

Fichier joint :



Voilà, il suffit d'installer git, gcc et make. La procédure d'installation se fait comme sous Linux, sans toucher à rien. Ca marche au poil du premier coup.
La toute première fois que Ubuntu est arrivé sous Windows, ça ne marchait pas pour plein de raisons, entre autres les liens symboliques foireux, voire inexistants.
Avec un peu de chance, plus besoin de VM


Ca devrait t'intéresser.

Le bash OK, mais gcc4ti existait pour windows, non ?

ouep, mais la dernière release n'intègre sûrement pas tout ce qu'on trouve dans le repo git (github.com/debrouxl/gcc4ti)
et ça me permet de garder mes scripts de compilation, et avoir un bash sous la main pour tout ce qui est grep, git, make, puis toutes les commandes bash en général, quoi. C'est bien plus puissant qu'un cmd, et bien plus intégré qu'un MinGW.

Ça veut dire quoi, "plus intégré" ?

Oui, bon, "assimilé" si tu préfères

Folco > OK (je parlais bien juste de l'aspect gcc4ti)

Non je ne pinaillais pas sur le mot, c'est vraiment que je ne comprends pas ce qu'il veut dire

Par exemple moi j'utilise Cygwin et OK, l'intégration pourrait être mieux (les permissions de fichiers font n'importe quoi, les liens symboliques ne sont pas des vrais raccourcis, etc. plein de détails de ce genre). Mais j'avais l'impression que pour MinGW c'était plutôt pas mal, donc j'aimerais bien savoir ce qui fait "mal intégré" et que cette solution améliore.

J'ai fait un test pour symfony avec le bash windows, ca marche bien, par contre si je met mes fichier sur la partition windows et non dans /home ou /var c'est treslent Mais c'est peut-etre un soucis de linux pour la lecture ntfs et pas specialement le bash windows.

Par contre ce serait bien qu'ils mettent a jour le kernel, 3.4 c'est un peu vieux ya des trucs ca peut etre limite (genre docker).

MinGW lui-même est très intégré à Windows (c'est du Win32/Win64 natif), mais ne fait pas tourner le code POSIX, notamment bash. Il y a des shells qui ont été portés en Win32 (et Win64?) natif, mais la compatibilité avec les scripts existants, qui attendent aussi un environnement POSIX, est un problème.

Le projet MinGW a donc inventé MSYS, une "version light" de Cygwin avec quelques bidouillages supplémentaires (en plus de ceux que Cygwin a déjà) pour l'intégration Win32/Win64, genre la traduction des chemins passés en paramètre. MSYS permet notamment de faire tourner bash et les scripts configure générés par autoconf. Et là, c'est (comme Cygwin) une implémentation de POSIX par dessus Win32/Win64, où un certain effort d'intégration a été fait, mais souvent très bidouillé. (Par exemple, si tu passes un paramètre à un programme Win32/Win64 natif qui ressemble à un chemin d'accès, il sera "converti" et donc cassé. C'est d'autant plus problématique que les programmes Windows attendent souvent des switches /x, qu'il faut écrire //x pour que ça passe.)

Là, Microsoft propose une implémentation totalement différente, POSIX à côté de Win32/Win64 plutôt que par dessus, qui a des avantages et des inconvénients différents.

Comme ça fait longtemps que je n'utilise plus Windows, et comme donc je n'ai essayé ni MSYS 2, ni la solution de Microsoft, seulement MSYS 1 et un Cygwin de la même époque, je ne peux pas dire quelle solution fonctionne mieux globalement.

Arvi89 (./998) :
J'ai fait un test pour symfony avec le bash windows, ca marche bien, par contre si je met mes fichier sur la partition windows et non dans /home ou /var c'est treslent Mais c'est peut-etre un soucis de linux pour la lecture ntfs et pas specialement le bash windows.

Le "bash Windows" n'utilise pas les pilotes NTFS pour Linux, mais des pilotes spécialisés qui passent par le noyau de Windows. Utiliser le pilote NTFS de Ubuntu devrait être théoriquement possible parce que c'est un pilote FUSE en espace utilisateur, mais tu ne pourrais pas accéder aux partitions auxquelles Windows accède aussi en même temps sans tout casser. (Pour les pilotes noyau, genre vfat (FAT32/FAT16/FAT12), c'est carrément impossible parce que la solution de Microsoft n'utilise pas le noyau Linux, il y a seulement une compatibilité en espace utilisateur, comme les couches de compatibilité Linux des *BSD.)

Zeph (./995) :
Ça veut dire quoi, "plus intégré" ?

Zeph (./997) :
Par exemple moi j'utilise Cygwin et OK, l'intégration pourrait être mieux (les permissions de fichiers font n'importe quoi, les liens symboliques ne sont pas des vrais raccourcis, etc. plein de détails de ce genre). Mais j'avais l'impression que pour MinGW c'était plutôt pas mal, donc j'aimerais bien savoir ce qui fait "mal intégré" et que cette solution améliore.

Le fait que des programmes s'appellent mingw32-xyz par exemple, ça oblige à modifier les scripts. Le fait de ne pas avoir accès à un disque par /mnt/disque/blabla, qui m'obligeait aussi à avoir des scripts spécifiques. Là, j'ai strictement rien eu à changer, et c'est bien agréable.

Folco: oui mais cet environement d'execution Linux (et pas "Bash pour Windows") est completement separe de l'enviromenemt de Windows lui meme, tu ne vois aps les taches linux depuis windows, et linux ne vois pas les taches linux, c'est plus comme si tu avait une VM que un environement a la WINE ou les applicatifs windows sont lance comme des executable Linux./.

Si tu vois les taches linux sous windows (je vois apache et php-fpm dans le task manager).

Folco (./1001) :
Le fait que des programmes s'appellent mingw32-xyz par exemple, ça oblige à modifier les scripts.

Pourquoi pas des liens symboliques ?

Arvi: Ils ont change le comportement parce que le cloisoement original empêchais ce genre de choses..

Pen^2 -> voilà, tout est parfaitement faisable, mais là j'ai rien du tout à modifier, adapter etc...

Je vois, c'est mieux intégré, quoi ! Il aurait suffit de le dire au début

si je met mes fichier sur la partition windows et non dans /home ou /var c'est tres lent Mais c'est peut-etre un soucis de linux pour la lecture ntfs et pas specialement le bash windows.

Une partie de la différence peut venir d'une certaine lenteur traditionnelle des lectures et écritures de fichiers par Windows dans le filesystem NTFS.
Il y a des années - du temps de Vista, parce que c'était un descendant de XP mais c'était avant Seven - j'avais vu passer que les nombres de performance de tests d'accès filesystem produits par un programme de benchmark type Sandra Bench étaient bien meilleurs sous Wine sous Linux que sous Windows natif, de mémoire plus de +100% meilleurs, sans que ce soit un pur effet d'affichage...
Aussi, Git fait une large utilisation des syscalls de la famille stat() sous Linux, où ils sont rapides, alors que les équivalents Windows, dont j'ai oublié le nom, sont comparativement lents, rendant Git traditionnellement comparativement lent sous Windows.
Et en voyant, en 2015-2016, les temps que les machines Windows Seven des collègues mettaient à réaliser les `npm install`, par rapport au temps que ma machine Linux de même modèle mettait, je dirais qu'une relative lenteur des accès disque NTFS persiste sur des versions contemporaines de Windows.

Par contre ce serait bien qu'ils mettent a jour le kernel, 3.4 c'est un peu vieux ya des trucs ca peut etre limite (genre docker).

Ouais, 3.4 est carrément vieux maintenant, même s'il est encore fréquent sur les Android, hélas. Je crois que j'avais vu que les efforts de Microsoft pour le subsystem Linux avaient commencé dans un projet visant à apporter une compatibilité avec Android (Project Astoria ?), c'est (en partie ?) de là que vient ce verrouillage à une version 3.4.
Maintenant qu'il y a un Docker "natif" Windows utilisant un unikernel, l'intérêt pratique d'utiliser le WSL pour tourner un Docker Linux semble moindre.
Entre autres manques, le kernel 3.4 est bien trop vieux pour avoir le syscall seccomp().

Lionel Debroux (./1008) :
Une partie de la différence peut venir d'une certaine lenteur traditionnelle des lectures et écritures de fichiers par Windows dans le filesystem NTFS.

En fait la c'est du genre 30ms pour charger la page avec une vraie vm, contre 950 pour charger dans le Winbuntu(^^) avec les fichiers sur la partie windows (mais si je met dans /home par exemple, on passe a 50 ms, donc bien mieux). Et ceux qui font du dev symfony avec Wamp n'ont pas specialement de soucis, c'est vraiment juste ce cas de figure.

Godzil (./1002) :
tu ne vois aps les taches linux depuis windows, et linux ne vois pas les taches linux

Linux ne se voit pas travailler lui même, c'est donc un fonctionnaire, CQFD

ttk

http://betanews.com/2016/11/24/microsoft-shares-windows-10-telemetry-data-with-third-parties/

EDIT : bon apparemment MS a démenti.

Pour Folco :
https://channel9.msdn.com/Events/Connect/2016/191/player

Très intéressant, merci beaucoup !

ils ont vraiment changé, je sais pas si ca tiendra dans la durée mais bon

Oué, intéressant, merci.

C'est bien ! J'aimerais Ubuntu 16.04 maintenant avec un kernel plus élevé (et même si docker est dispo pour windows, ça demande hyper-v, donc je ne peux plus utiliser virtual box), et ce sera très bien ^^
(et une vitesse plus élevée lors de l'accès aux fichier sur la partie windows)

Tu devrais leur envoyer un mot, ils sont apparemment plutôt volontaires.