Windows 10 va permettre d'acc=c3=a9der aux fichiers Linux
18 réponses
Pierre www.aribaut.com
Encore un pas de Microsoft vers l'univers Linux :
https://www.zdnet.fr/actualites/windows-10-bientot-l-acces-aux-fichiers-linux-a-partir-de-l-explorateur-de-fichiers-39880815.htm
"Microsoft vient d’annoncer une évolution très attendue pour faciliter
l’accès aux fichiers stockés par certains OS Linux. La prochaine mise à
jour Windows 10 (build 1903) permettra d’accéder, déplacer et copier
depuis l’Explorateur des fichiers stockés dans un sous-système Windows
pour Linux (WSL). Cette solution est une couche de compatibilité qui
permet à Windows 10 d'exécuter nativement des distributions GNU/Linux
(Ubuntu, openSUSE, Debian, Fedora, Kali Linux…) comme s’il s’agissait
d’applications Windows Store. “Par le passé, la création et la
modification de fichiers Linux à partir de Windows entraînait la perte
de fichiers ou la corruption de données”, explique Microsoft dans son
billet de blog."
--
http://zetrader.info ou http://zetrader.fr
http://aribaut.com ou http://pierre.aribaut.com - http://zeforums.com
ce que je lis surtout: "des fichiers stockés dans un sous-système Windows pour Linux (WSL)" ca ne parle absolument pas de lire des partitions au format ext2/3/4
A mon avis c'est l'équivalent Microsoft de faire: :~# ls -la /var/lib/lxc/104/rootfs/var/spool/mail/schaefer -rw-rw---- 1 schaefer mail 0 Sep 16 2006 /var/lib/lxc/104/rootfs/var/spool/mail/schaefer En effet, avec des conteneurs lxc natifs Linux, par exemple, on n'a pas besoin de stocker une image du fs (comme on le ferait avec kvm, xen, VirtualBox ou VMware), mais on monte simplement un répertoire du fs du host comme / de la VM Bon, dans mon cas, j'ai mis ça sur un fs séparé avec LVM: /dev/vg1/lxc-104 545862120 486551972 33079532 94% /var/lib/lxc/104 mais rien d'obligatoire. Ca isole juste un peu mieux et ça évite de la concurrence entre host et conteneurs question place disque, avec le coût d'un gaspillage [1]. Reste à savoir comment Microsoft implémente les fonctions POSIX comme le rename atomique, le verrouillage opportuniste, l'effacement de fichiers ouverts, etc, avec son fs. A voir ça a l'air assez coûteux: le lancement de processus et pas mal d'opérations fs usuelles du monde POSIX sont très, très lentes sous Microsoft. Une possibilité est que Microsoft est entrain de réécrire les couches basses de son OS (de mémoire elles avaient été écrites par DEC et pas tellement touchées ces dernières décennies) pour être plus efficace en environnement standard et qu'à terme, c'est l'environnement non standard Microsoft Win32 qui deviendra enfin l'alien dans cet écosystème, en `mode émulation', et Linux qui sera natif. [1] je n'utilise pas le partage d'espace libre de LV, qui je crois existe depuis quelques versions de LVM
In fr.comp.os.linux.configuration Th.A.C <aenleverraivac@free.fr.invalid> wrote:
ce que je lis surtout:
"des fichiers stockés dans un sous-système Windows pour Linux (WSL)"
ca ne parle absolument pas de lire des partitions au format ext2/3/4
A mon avis c'est l'équivalent Microsoft de faire:
root@virtual:~# ls -la /var/lib/lxc/104/rootfs/var/spool/mail/schaefer
-rw-rw---- 1 schaefer mail 0 Sep 16 2006 /var/lib/lxc/104/rootfs/var/spool/mail/schaefer
En effet, avec des conteneurs lxc natifs Linux, par exemple, on n'a pas
besoin de stocker une image du fs (comme on le ferait avec kvm, xen,
VirtualBox ou VMware), mais on monte simplement un répertoire du fs du host
comme / de la VM
Bon, dans mon cas, j'ai mis ça sur un fs séparé avec LVM:
mais rien d'obligatoire. Ca isole juste un peu mieux et ça évite
de la concurrence entre host et conteneurs question place disque,
avec le coût d'un gaspillage [1].
Reste à savoir comment Microsoft implémente les fonctions POSIX comme
le rename atomique, le verrouillage opportuniste, l'effacement de
fichiers ouverts, etc, avec son fs. A voir ça a l'air assez
coûteux: le lancement de processus et pas mal d'opérations fs
usuelles du monde POSIX sont très, très lentes sous Microsoft.
Une possibilité est que Microsoft est entrain de réécrire les
couches basses de son OS (de mémoire elles avaient été
écrites par DEC et pas tellement touchées ces dernières
décennies) pour être plus efficace en environnement
standard et qu'à terme, c'est l'environnement non standard
Microsoft Win32 qui deviendra enfin l'alien dans cet écosystème, en
`mode émulation', et Linux qui sera natif.
[1] je n'utilise pas le partage d'espace libre de LV, qui je
crois existe depuis quelques versions de LVM
ce que je lis surtout: "des fichiers stockés dans un sous-système Windows pour Linux (WSL)" ca ne parle absolument pas de lire des partitions au format ext2/3/4
A mon avis c'est l'équivalent Microsoft de faire: :~# ls -la /var/lib/lxc/104/rootfs/var/spool/mail/schaefer -rw-rw---- 1 schaefer mail 0 Sep 16 2006 /var/lib/lxc/104/rootfs/var/spool/mail/schaefer En effet, avec des conteneurs lxc natifs Linux, par exemple, on n'a pas besoin de stocker une image du fs (comme on le ferait avec kvm, xen, VirtualBox ou VMware), mais on monte simplement un répertoire du fs du host comme / de la VM Bon, dans mon cas, j'ai mis ça sur un fs séparé avec LVM: /dev/vg1/lxc-104 545862120 486551972 33079532 94% /var/lib/lxc/104 mais rien d'obligatoire. Ca isole juste un peu mieux et ça évite de la concurrence entre host et conteneurs question place disque, avec le coût d'un gaspillage [1]. Reste à savoir comment Microsoft implémente les fonctions POSIX comme le rename atomique, le verrouillage opportuniste, l'effacement de fichiers ouverts, etc, avec son fs. A voir ça a l'air assez coûteux: le lancement de processus et pas mal d'opérations fs usuelles du monde POSIX sont très, très lentes sous Microsoft. Une possibilité est que Microsoft est entrain de réécrire les couches basses de son OS (de mémoire elles avaient été écrites par DEC et pas tellement touchées ces dernières décennies) pour être plus efficace en environnement standard et qu'à terme, c'est l'environnement non standard Microsoft Win32 qui deviendra enfin l'alien dans cet écosystème, en `mode émulation', et Linux qui sera natif. [1] je n'utilise pas le partage d'espace libre de LV, qui je crois existe depuis quelques versions de LVM
pehache
Le 21/02/2019 à 04:01, Marc SCHAEFER a écrit :
In fr.comp.os.linux.configuration pehache wrote:
Oui, bon, ce n'est pas forcément une bonne chose de tourner du Linux dans du Microsoft;
WSL ce n'est pas "faire tourner du Linux dans du Microsoft"
Je précise: Exécuter des applications Linux dans des conteneurs, applications qui quand elles font des appels systèmes, l'appel aboutit non pas dans un kernel linux, mais dans une couche d'émulation Microsoft, qui aboutit à exécuter du code Microsoft Win32
Oui. Mais les confusions sont tellement grandes dans ce domaine qu'il est préférable d'être précis.
(ou autre nom pour cette API antique).
20 ans et des poussières ce n'est pas grand-chose pour une API système.
Des idées de troyens multiplateformes me viennent à l'esprit ...
Ca fait peur...
Notons que je me rappelle il y a quelques années que des machines Linux avaient été piratées par des keyloggers Microsoft qui ensuite avaient utilisé ssh pour exécuter un troyen; je n'ai plus la référence. J'avais pris l'habitude, dans les cas rares où je devais lancer un shell Linux depuis Microsoft, d'utiliser un One Time Password.
Oui donc WSL ou pas ça ne change rien. -- "...sois ouvert aux idées des autres pour peu qu'elles aillent dans le même sens que les tiennes.", ST sur fr.bio.medecine
Le 21/02/2019 à 04:01, Marc SCHAEFER a écrit :
In fr.comp.os.linux.configuration pehache <pehache.7@gmail.com> wrote:
Oui, bon, ce n'est pas forcément une bonne chose de tourner du
Linux dans du Microsoft;
WSL ce n'est pas "faire tourner du Linux dans du Microsoft"
Je précise:
Exécuter des applications Linux dans des conteneurs, applications
qui quand elles font des appels systèmes, l'appel aboutit non
pas dans un kernel linux, mais dans une couche d'émulation
Microsoft, qui aboutit à exécuter du code Microsoft
Win32
Oui. Mais les confusions sont tellement grandes dans ce domaine qu'il
est préférable d'être précis.
(ou autre nom pour cette API antique).
20 ans et des poussières ce n'est pas grand-chose pour une API système.
Des idées de troyens multiplateformes me viennent à l'esprit ...
Ca fait peur...
Notons que je me rappelle il y a quelques années que des machines
Linux avaient été piratées par des keyloggers Microsoft qui
ensuite avaient utilisé ssh pour exécuter un troyen; je n'ai
plus la référence.
J'avais pris l'habitude, dans les cas rares où je devais
lancer un shell Linux depuis Microsoft, d'utiliser un
One Time Password.
Oui donc WSL ou pas ça ne change rien.
--
"...sois ouvert aux idées des autres pour peu qu'elles aillent dans le
même sens que les tiennes.", ST sur fr.bio.medecine
Oui, bon, ce n'est pas forcément une bonne chose de tourner du Linux dans du Microsoft;
WSL ce n'est pas "faire tourner du Linux dans du Microsoft"
Je précise: Exécuter des applications Linux dans des conteneurs, applications qui quand elles font des appels systèmes, l'appel aboutit non pas dans un kernel linux, mais dans une couche d'émulation Microsoft, qui aboutit à exécuter du code Microsoft Win32
Oui. Mais les confusions sont tellement grandes dans ce domaine qu'il est préférable d'être précis.
(ou autre nom pour cette API antique).
20 ans et des poussières ce n'est pas grand-chose pour une API système.
Des idées de troyens multiplateformes me viennent à l'esprit ...
Ca fait peur...
Notons que je me rappelle il y a quelques années que des machines Linux avaient été piratées par des keyloggers Microsoft qui ensuite avaient utilisé ssh pour exécuter un troyen; je n'ai plus la référence. J'avais pris l'habitude, dans les cas rares où je devais lancer un shell Linux depuis Microsoft, d'utiliser un One Time Password.
Oui donc WSL ou pas ça ne change rien. -- "...sois ouvert aux idées des autres pour peu qu'elles aillent dans le même sens que les tiennes.", ST sur fr.bio.medecine
pehache
Le 21/02/2019 à 04:13, Marc SCHAEFER a écrit :
Reste à savoir comment Microsoft implémente les fonctions POSIX comme le rename atomique, le verrouillage opportuniste, l'effacement de fichiers ouverts, etc, avec son fs. A voir ça a l'air assez coûteux: le lancement de processus et pas mal d'opérations fs usuelles du monde POSIX sont très, très lentes sous Microsoft.
L'objectif de WSL n'est pas forcément la performance. Il y aura toujours des cas où ce sera plus efficace de tourner en natif Linux. Je suppose qu'on peut dire la même chose pour Wine : c'est pratique, mais ça ne remplace pas Windows pour toutes les situations.
Une possibilité est que Microsoft est entrain de réécrire les couches basses de son OS (de mémoire elles avaient été écrites par DEC
Vieille rumeur... Un des (ou le, je ne sais plus) architectes de NT avait auparavant travaillé sur VMS chez DEC. Il a probablement repris des idées de VMS, mais ce n'est pas DEC qui a écrit NT.
et pas tellement touchées ces dernières décennies) pour être plus efficace en environnement standard et qu'à terme, c'est l'environnement non standard Microsoft Win32 qui deviendra enfin l'alien dans cet écosystème, en `mode émulation', et Linux qui sera natif.
Je ne vois pas ce que l'environnement POSIX a de plus standard que n'importe quel autre. Ceci dit win32 n'est déjà plus si central que ça dans Windows. Depuis W8 les applications ne sont plus forcément basées dessus (bon, ça n'a pas été un grand succès, en pratique 99% de l'écosystème logiciel reste du pur win32), et dans une (plus ou moins) prochaine itération de Windows il deviendra un composant détachable (projet Windows Core). Néanmoins le noyau ne m'a pas l'air de spécialement se rapprocher de posix. fu2 fcold -- "...sois ouvert aux idées des autres pour peu qu'elles aillent dans le même sens que les tiennes.", ST sur fr.bio.medecine
Le 21/02/2019 à 04:13, Marc SCHAEFER a écrit :
Reste à savoir comment Microsoft implémente les fonctions POSIX comme
le rename atomique, le verrouillage opportuniste, l'effacement de
fichiers ouverts, etc, avec son fs. A voir ça a l'air assez
coûteux: le lancement de processus et pas mal d'opérations fs
usuelles du monde POSIX sont très, très lentes sous Microsoft.
L'objectif de WSL n'est pas forcément la performance. Il y aura toujours
des cas où ce sera plus efficace de tourner en natif Linux. Je suppose
qu'on peut dire la même chose pour Wine : c'est pratique, mais ça ne
remplace pas Windows pour toutes les situations.
Une possibilité est que Microsoft est entrain de réécrire les
couches basses de son OS (de mémoire elles avaient été
écrites par DEC
Vieille rumeur... Un des (ou le, je ne sais plus) architectes de NT
avait auparavant travaillé sur VMS chez DEC. Il a probablement repris
des idées de VMS, mais ce n'est pas DEC qui a écrit NT.
et pas tellement touchées ces dernières
décennies) pour être plus efficace en environnement
standard et qu'à terme, c'est l'environnement non standard
Microsoft Win32 qui deviendra enfin l'alien dans cet écosystème, en
`mode émulation', et Linux qui sera natif.
Je ne vois pas ce que l'environnement POSIX a de plus standard que
n'importe quel autre.
Ceci dit win32 n'est déjà plus si central que ça dans Windows. Depuis W8
les applications ne sont plus forcément basées dessus (bon, ça n'a pas
été un grand succès, en pratique 99% de l'écosystème logiciel reste du
pur win32), et dans une (plus ou moins) prochaine itération de Windows
il deviendra un composant détachable (projet Windows Core). Néanmoins le
noyau ne m'a pas l'air de spécialement se rapprocher de posix.
fu2 fcold
--
"...sois ouvert aux idées des autres pour peu qu'elles aillent dans le
même sens que les tiennes.", ST sur fr.bio.medecine
Reste à savoir comment Microsoft implémente les fonctions POSIX comme le rename atomique, le verrouillage opportuniste, l'effacement de fichiers ouverts, etc, avec son fs. A voir ça a l'air assez coûteux: le lancement de processus et pas mal d'opérations fs usuelles du monde POSIX sont très, très lentes sous Microsoft.
L'objectif de WSL n'est pas forcément la performance. Il y aura toujours des cas où ce sera plus efficace de tourner en natif Linux. Je suppose qu'on peut dire la même chose pour Wine : c'est pratique, mais ça ne remplace pas Windows pour toutes les situations.
Une possibilité est que Microsoft est entrain de réécrire les couches basses de son OS (de mémoire elles avaient été écrites par DEC
Vieille rumeur... Un des (ou le, je ne sais plus) architectes de NT avait auparavant travaillé sur VMS chez DEC. Il a probablement repris des idées de VMS, mais ce n'est pas DEC qui a écrit NT.
et pas tellement touchées ces dernières décennies) pour être plus efficace en environnement standard et qu'à terme, c'est l'environnement non standard Microsoft Win32 qui deviendra enfin l'alien dans cet écosystème, en `mode émulation', et Linux qui sera natif.
Je ne vois pas ce que l'environnement POSIX a de plus standard que n'importe quel autre. Ceci dit win32 n'est déjà plus si central que ça dans Windows. Depuis W8 les applications ne sont plus forcément basées dessus (bon, ça n'a pas été un grand succès, en pratique 99% de l'écosystème logiciel reste du pur win32), et dans une (plus ou moins) prochaine itération de Windows il deviendra un composant détachable (projet Windows Core). Néanmoins le noyau ne m'a pas l'air de spécialement se rapprocher de posix. fu2 fcold -- "...sois ouvert aux idées des autres pour peu qu'elles aillent dans le même sens que les tiennes.", ST sur fr.bio.medecine
zeLittle
Bon, maintenant que je suis "réveillé: J'ai l'impression qu'il ont juste injecté cygwin dans leur PowerShell (un méta terminal pouvant lancer des lignes de commandes DOS ou Bash). Pour ce qui est des applications Windows depuis Linux, Wine le fait déjà plutôt bien dans l'autre sens (il permet aussi de lancer des applications Windows, et de lancer aussi des fichiers *.vbs - les scripts qui sont les successeurs des fichiers *.pif - originellement dévolues aux tâches administration Windows, mais qui peuvent être lancés sous Wine pour faire de l'administration sous un Linux-desktop).
Bon, maintenant que je suis "réveillé:
J'ai l'impression qu'il ont juste injecté cygwin dans leur PowerShell (un
méta terminal pouvant lancer des lignes de commandes DOS ou Bash).
Pour ce qui est des applications Windows depuis Linux, Wine le fait déjà
plutôt bien dans l'autre sens (il permet aussi de lancer des applications
Windows, et de lancer aussi des fichiers *.vbs - les scripts qui sont les
successeurs des fichiers *.pif - originellement dévolues aux tâches
administration Windows, mais qui peuvent être lancés sous Wine pour faire de
l'administration sous un Linux-desktop).
Bon, maintenant que je suis "réveillé: J'ai l'impression qu'il ont juste injecté cygwin dans leur PowerShell (un méta terminal pouvant lancer des lignes de commandes DOS ou Bash). Pour ce qui est des applications Windows depuis Linux, Wine le fait déjà plutôt bien dans l'autre sens (il permet aussi de lancer des applications Windows, et de lancer aussi des fichiers *.vbs - les scripts qui sont les successeurs des fichiers *.pif - originellement dévolues aux tâches administration Windows, mais qui peuvent être lancés sous Wine pour faire de l'administration sous un Linux-desktop).
Th.A.C
Le 22/02/2019 à 10:17, zeLittle a écrit :
Bon, maintenant que je suis "réveillé:
presque ;-)
.. scripts qui sont les successeurs des fichiers *.pif - originellement dévolues aux tâches administration Windows...
*.paf??? plus sérieusement: *.bat *.cmd les *.pif c'est pour la compatibilité des applications msdos. bon fin, de la transgression, on reparle juste de linux?
Le 22/02/2019 à 10:17, zeLittle a écrit :
Bon, maintenant que je suis "réveillé:
presque ;-)
..
scripts qui sont les successeurs des fichiers *.pif - originellement
dévolues aux tâches administration Windows...
*.paf???
plus sérieusement: *.bat *.cmd
les *.pif c'est pour la compatibilité des applications msdos.
bon fin, de la transgression, on reparle juste de linux?
.. scripts qui sont les successeurs des fichiers *.pif - originellement dévolues aux tâches administration Windows...
*.paf??? plus sérieusement: *.bat *.cmd les *.pif c'est pour la compatibilité des applications msdos. bon fin, de la transgression, on reparle juste de linux?
pehache
Le 22/02/2019 à 10:17, zeLittle a écrit :
Bon, maintenant que je suis "réveillé: J'ai l'impression qu'il ont juste injecté cygwin dans leur PowerShell
Non -- "...sois ouvert aux idées des autres pour peu qu'elles aillent dans le même sens que les tiennes.", ST sur fr.bio.medecine
Le 22/02/2019 à 10:17, zeLittle a écrit :
Bon, maintenant que je suis "réveillé:
J'ai l'impression qu'il ont juste injecté cygwin dans leur PowerShell
Non
--
"...sois ouvert aux idées des autres pour peu qu'elles aillent dans le
même sens que les tiennes.", ST sur fr.bio.medecine
Bon, maintenant que je suis "réveillé: J'ai l'impression qu'il ont juste injecté cygwin dans leur PowerShell
Non -- "...sois ouvert aux idées des autres pour peu qu'elles aillent dans le même sens que les tiennes.", ST sur fr.bio.medecine
Christophe PEREZ
Le Fri, 22 Feb 2019 14:45:13 +0100, Th.A.C a écrit :
bon fin, de la transgression, on reparle juste de linux?
Ouais cool. Je me demande même quel zèbre a encore pu amener ce sujet HS sur ce groupe ! Encore une fois il prouve qu'il n'a rien compris à ce qu'est Linux.
Le Fri, 22 Feb 2019 14:45:13 +0100, Th.A.C a écrit :
bon fin, de la transgression, on reparle juste de linux?
Ouais cool.
Je me demande même quel zèbre a encore pu amener ce sujet HS sur ce
groupe !
Encore une fois il prouve qu'il n'a rien compris à ce qu'est Linux.
Le Fri, 22 Feb 2019 14:45:13 +0100, Th.A.C a écrit :
bon fin, de la transgression, on reparle juste de linux?
Ouais cool. Je me demande même quel zèbre a encore pu amener ce sujet HS sur ce groupe ! Encore une fois il prouve qu'il n'a rien compris à ce qu'est Linux.
Eric Belhomme
On Wed, 20 Feb 2019 15:36:18 +0100, denis.paris wrote:
Sinon, ce qui serait plus utile à mon avis que de vouloir singer linux,
WSL est à Windows ce que Wine est à Linux, en beaucoup mieux abouti. WSL a révolutionné ma façon de travailler : étant obligé d'avoir mon laptop pro sous Windows, grâce à WSL fini les jonglages bancals avec une VM linux sur le laptop. Avant de critiquer WSL, essayez-le : j'ai une *vraie* Debian qui tourne par dessus W10 !
c'est un redirecteur efficace pour NFS et un support "ext" pour les fichiers locaux.
Il est vrai qu'une vraie couche NFS3 voire NFS4 ne serait pas du luxe, je ne comprends pas pourquoi ça n'a jamais été /correctement/ fait. Le support ext dans Windows est déjà beaucoup plus explicable : pas d'intérêt business pour une telle feature -- Rico
On Wed, 20 Feb 2019 15:36:18 +0100, denis.paris wrote:
Sinon, ce qui serait plus utile à mon avis que de vouloir singer linux,
WSL est à Windows ce que Wine est à Linux, en beaucoup mieux abouti. WSL
a révolutionné ma façon de travailler : étant obligé d'avoir mon laptop
pro sous Windows, grâce à WSL fini les jonglages bancals avec une VM
linux sur le laptop.
Avant de critiquer WSL, essayez-le : j'ai une *vraie* Debian qui tourne
par dessus W10 !
c'est un redirecteur efficace pour NFS et un support "ext" pour les
fichiers locaux.
Il est vrai qu'une vraie couche NFS3 voire NFS4 ne serait pas du luxe, je
ne comprends pas pourquoi ça n'a jamais été /correctement/ fait. Le
support ext dans Windows est déjà beaucoup plus explicable : pas
d'intérêt business pour une telle feature
On Wed, 20 Feb 2019 15:36:18 +0100, denis.paris wrote:
Sinon, ce qui serait plus utile à mon avis que de vouloir singer linux,
WSL est à Windows ce que Wine est à Linux, en beaucoup mieux abouti. WSL a révolutionné ma façon de travailler : étant obligé d'avoir mon laptop pro sous Windows, grâce à WSL fini les jonglages bancals avec une VM linux sur le laptop. Avant de critiquer WSL, essayez-le : j'ai une *vraie* Debian qui tourne par dessus W10 !
c'est un redirecteur efficace pour NFS et un support "ext" pour les fichiers locaux.
Il est vrai qu'une vraie couche NFS3 voire NFS4 ne serait pas du luxe, je ne comprends pas pourquoi ça n'a jamais été /correctement/ fait. Le support ext dans Windows est déjà beaucoup plus explicable : pas d'intérêt business pour une telle feature -- Rico
