Certains se réjouissent, moi, ça me laisse dubitatif.
Quid des serveur web vérolé par windows ?
Quid des application compilés dans ce bash windows puis qui sont
déposé dans les dépot ?
Ce que microsoft à fait, c'est un genre de Wine mais version Line ?
Une cheval de troie vers linux ?
Merci de vos lumières.
PS : Je plonk prouti-prouta, il en a peut être abordé le sujet, mais
comme toujours, ça pue.
--
« le politiquement correct ne proclame pas la tolérance ; il ne fait qu'organiser la haine. » (Jacques Barzun)
C'est une doctrine obligatoire, qui n'est en réalité que l'expression la plus autoritaire du conformisme
La démonstration n'explique pas pourquoi Microsoft engage cette démarche (en tout cas, je ne l'ai pas entendu, mais ma compréhension de l'anglais oral est très faible).
Ajourd'hui, avec un écosystème hardware fonctionnant majoritairement en environnement [U]nix, microsoft a bien senti le vent tourner du coté développement. De moins en moins de développeurs utilisent aujourd'hui la plate forme Windows pour coder de l'Android ou du iOs. Ce changement de politique de microsoft est purement dans l'espoir de garder les développeurs sur la plate forme windows en leur fournissant tous les outils qu'ils utilisent tous les jours.
Le 15/04/2016 18:21, Dominique MICOLLET a écrit :
La démonstration n'explique pas pourquoi Microsoft engage cette démarche (en
tout cas, je ne l'ai pas entendu, mais ma compréhension de l'anglais oral
est très faible).
Ajourd'hui, avec un écosystème hardware fonctionnant majoritairement en
environnement [U]nix, microsoft a bien senti le vent tourner du coté
développement. De moins en moins de développeurs utilisent aujourd'hui
la plate forme Windows pour coder de l'Android ou du iOs.
Ce changement de politique de microsoft est purement dans l'espoir de
garder les développeurs sur la plate forme windows en leur fournissant
tous les outils qu'ils utilisent tous les jours.
La démonstration n'explique pas pourquoi Microsoft engage cette démarche (en tout cas, je ne l'ai pas entendu, mais ma compréhension de l'anglais oral est très faible).
Ajourd'hui, avec un écosystème hardware fonctionnant majoritairement en environnement [U]nix, microsoft a bien senti le vent tourner du coté développement. De moins en moins de développeurs utilisent aujourd'hui la plate forme Windows pour coder de l'Android ou du iOs. Ce changement de politique de microsoft est purement dans l'espoir de garder les développeurs sur la plate forme windows en leur fournissant tous les outils qu'ils utilisent tous les jours.
Kevin Denis
Le 15-04-2016, La Norme Française c'est pas le FN a écrit :
Certains se réjouissent, moi, ça me laisse dubitatif. Quid des serveur web vérolé par windows ?
gné? Les serveurs webs pourris, c'est quand même majoritairement du LAMP.
Quid des application compilés dans ce bash windows puis qui sont déposé dans les dépot ?
gné (bis). bash c'est un langage de script, qu'est ce que ça veut dire compilé dans ce bash windows?
Ce que microsoft à fait, c'est un genre de Wine mais version Line ?
Oui, exactement. Ca trappe les syscalls, et ça émule côté windows. C'est exatcement comme wine. Tu prends un ELF standard, il y a un subsystem linux, et hop, ça s'exécute.
Une cheval de troie vers linux ?
Windows va exécuter nativement du binaire linux et tu parles d'un cheval de troie *vers* linux?
J'ai l'impression d'avoir marché dedans. -- Kevin
Le 15-04-2016, La Norme Française c'est pas le FN <On@sen.fout> a écrit :
Certains se réjouissent, moi, ça me laisse dubitatif.
Quid des serveur web vérolé par windows ?
gné? Les serveurs webs pourris, c'est quand même majoritairement du
LAMP.
Quid des application compilés dans ce bash windows puis qui sont
déposé dans les dépot ?
gné (bis). bash c'est un langage de script, qu'est ce que ça veut dire
compilé dans ce bash windows?
Ce que microsoft à fait, c'est un genre de Wine mais version Line ?
Oui, exactement. Ca trappe les syscalls, et ça émule côté windows.
C'est exatcement comme wine. Tu prends un ELF standard, il y a un
subsystem linux, et hop, ça s'exécute.
Une cheval de troie vers linux ?
Windows va exécuter nativement du binaire linux et tu parles d'un cheval
de troie *vers* linux?
Le 15-04-2016, La Norme Française c'est pas le FN a écrit :
Certains se réjouissent, moi, ça me laisse dubitatif. Quid des serveur web vérolé par windows ?
gné? Les serveurs webs pourris, c'est quand même majoritairement du LAMP.
Quid des application compilés dans ce bash windows puis qui sont déposé dans les dépot ?
gné (bis). bash c'est un langage de script, qu'est ce que ça veut dire compilé dans ce bash windows?
Ce que microsoft à fait, c'est un genre de Wine mais version Line ?
Oui, exactement. Ca trappe les syscalls, et ça émule côté windows. C'est exatcement comme wine. Tu prends un ELF standard, il y a un subsystem linux, et hop, ça s'exécute.
Une cheval de troie vers linux ?
Windows va exécuter nativement du binaire linux et tu parles d'un cheval de troie *vers* linux?
J'ai l'impression d'avoir marché dedans. -- Kevin
pehache
Le 16/04/2016 15:15, Dominique MICOLLET a écrit :
Bonjour,
pehache wrote:
Le 15/04/2016 18:21, Dominique MICOLLET a écrit :
à terme, Windows 10 intégrera nativement les appels systèmes Unix.
Il faut s'entendre sur ce qu'on appelle "nativement".
Effectivement. Cette nouvelle m'a amené a me réintéresser à user mode linux. Et je me pose une question : quand un programme appelle un open(), qui prend cet appel en charge : - le noyau uml, en court-circuitant le noyau "booté" ; - le noyau "booté", auquel cas le noyau uml ne ferait que sous-traiter l'appel ?
Je suppute la seconde solution qui me semble plus fiable. Si c'est bien le cas, alors il faut que Windows supporte nativement les appels sytèmes d'unix pour que le noyau uml puisse les utiliser.
Ca marche vraiment avec un noyau Linux en user mode, leur truc ? Si oui ce n'est l'équivalent de Wine comme on a pu le lire (Wine ne lance pas un noyau NT en user mode à ma connaissance).
-- "les supports évoluant tellement vite, je ne sais pas ce que c'est qu'une "carte SD"" (FLC)
Le 16/04/2016 15:15, Dominique MICOLLET a écrit :
Bonjour,
pehache wrote:
Le 15/04/2016 18:21, Dominique MICOLLET a écrit :
à terme, Windows 10 intégrera nativement les appels systèmes Unix.
Il faut s'entendre sur ce qu'on appelle "nativement".
Effectivement.
Cette nouvelle m'a amené a me réintéresser à user mode linux.
Et je me pose une question : quand un programme appelle un open(), qui prend
cet appel en charge :
- le noyau uml, en court-circuitant le noyau "booté" ;
- le noyau "booté", auquel cas le noyau uml ne ferait que sous-traiter
l'appel ?
Je suppute la seconde solution qui me semble plus fiable.
Si c'est bien le cas, alors il faut que Windows supporte nativement les
appels sytèmes d'unix pour que le noyau uml puisse les utiliser.
Ca marche vraiment avec un noyau Linux en user mode, leur truc ? Si oui
ce n'est l'équivalent de Wine comme on a pu le lire (Wine ne lance pas
un noyau NT en user mode à ma connaissance).
--
"les supports évoluant tellement vite, je ne sais
pas ce que c'est qu'une "carte SD"" (FLC)
à terme, Windows 10 intégrera nativement les appels systèmes Unix.
Il faut s'entendre sur ce qu'on appelle "nativement".
Effectivement. Cette nouvelle m'a amené a me réintéresser à user mode linux. Et je me pose une question : quand un programme appelle un open(), qui prend cet appel en charge : - le noyau uml, en court-circuitant le noyau "booté" ; - le noyau "booté", auquel cas le noyau uml ne ferait que sous-traiter l'appel ?
Je suppute la seconde solution qui me semble plus fiable. Si c'est bien le cas, alors il faut que Windows supporte nativement les appels sytèmes d'unix pour que le noyau uml puisse les utiliser.
Ca marche vraiment avec un noyau Linux en user mode, leur truc ? Si oui ce n'est l'équivalent de Wine comme on a pu le lire (Wine ne lance pas un noyau NT en user mode à ma connaissance).
-- "les supports évoluant tellement vite, je ne sais pas ce que c'est qu'une "carte SD"" (FLC)
Toxico Nimbus
Le 26-04-2016, pehache a écrit :
Le 16/04/2016 15:15, Dominique MICOLLET a écrit :
Bonjour,
pehache wrote:
Le 15/04/2016 18:21, Dominique MICOLLET a écrit :
à terme, Windows 10 intégrera nativement les appels systèmes Unix.
Il faut s'entendre sur ce qu'on appelle "nativement".
Effectivement. Cette nouvelle m'a amené a me réintéresser à user mode linux. Et je me pose une question : quand un programme appelle un open(), qui prend cet appel en charge : - le noyau uml, en court-circuitant le noyau "booté" ; - le noyau "booté", auquel cas le noyau uml ne ferait que sous-traiter l'appel ?
Je suppute la seconde solution qui me semble plus fiable. Si c'est bien le cas, alors il faut que Windows supporte nativement les appels sytèmes d'unix pour que le noyau uml puisse les utiliser.
Ca marche vraiment avec un noyau Linux en user mode, leur truc ? Si oui ce n'est l'équivalent de Wine comme on a pu le lire (Wine ne lance pas un noyau NT en user mode à ma connaissance).
Non, ça transforme juste les appels noyau Linux. Deux systèmes de fichiers permettent l'émulation de l'environnement fichier Linux (avec les /proc et compagnie) et l'interopération avec Windows. Le tout permet d'exécuter des elf64 nativement. Il y a tout de même un "contexte d'émulation" commun à toutes les applis émulées qui est généré à l'ouverture du bash, mais qui n'a rien à voir avec une VM.
Le 26-04-2016, pehache <pehache.7@gmail.com> a écrit :
Le 16/04/2016 15:15, Dominique MICOLLET a écrit :
Bonjour,
pehache wrote:
Le 15/04/2016 18:21, Dominique MICOLLET a écrit :
à terme, Windows 10 intégrera nativement les appels systèmes Unix.
Il faut s'entendre sur ce qu'on appelle "nativement".
Effectivement.
Cette nouvelle m'a amené a me réintéresser à user mode linux.
Et je me pose une question : quand un programme appelle un open(), qui prend
cet appel en charge :
- le noyau uml, en court-circuitant le noyau "booté" ;
- le noyau "booté", auquel cas le noyau uml ne ferait que sous-traiter
l'appel ?
Je suppute la seconde solution qui me semble plus fiable.
Si c'est bien le cas, alors il faut que Windows supporte nativement les
appels sytèmes d'unix pour que le noyau uml puisse les utiliser.
Ca marche vraiment avec un noyau Linux en user mode, leur truc ? Si oui
ce n'est l'équivalent de Wine comme on a pu le lire (Wine ne lance pas
un noyau NT en user mode à ma connaissance).
Non, ça transforme juste les appels noyau Linux. Deux systèmes de fichiers
permettent l'émulation de l'environnement fichier Linux (avec les /proc et
compagnie) et l'interopération avec Windows. Le tout permet d'exécuter des
elf64 nativement. Il y a tout de même un "contexte d'émulation" commun à
toutes les applis émulées qui est généré à l'ouverture du bash, mais qui
n'a rien à voir avec une VM.
à terme, Windows 10 intégrera nativement les appels systèmes Unix.
Il faut s'entendre sur ce qu'on appelle "nativement".
Effectivement. Cette nouvelle m'a amené a me réintéresser à user mode linux. Et je me pose une question : quand un programme appelle un open(), qui prend cet appel en charge : - le noyau uml, en court-circuitant le noyau "booté" ; - le noyau "booté", auquel cas le noyau uml ne ferait que sous-traiter l'appel ?
Je suppute la seconde solution qui me semble plus fiable. Si c'est bien le cas, alors il faut que Windows supporte nativement les appels sytèmes d'unix pour que le noyau uml puisse les utiliser.
Ca marche vraiment avec un noyau Linux en user mode, leur truc ? Si oui ce n'est l'équivalent de Wine comme on a pu le lire (Wine ne lance pas un noyau NT en user mode à ma connaissance).
Non, ça transforme juste les appels noyau Linux. Deux systèmes de fichiers permettent l'émulation de l'environnement fichier Linux (avec les /proc et compagnie) et l'interopération avec Windows. Le tout permet d'exécuter des elf64 nativement. Il y a tout de même un "contexte d'émulation" commun à toutes les applis émulées qui est généré à l'ouverture du bash, mais qui n'a rien à voir avec une VM.
