Linux? - Page 204

Tu viens de démontrer en deux posts que les mecs chez MS sont des abrutis finis qui font un boulot énorme pour rien.
A moins que tu ne voies pas plus loin que le bout de ton nez.

Pour moi ils essayent juste de rester encore un peu relevant, étant donné qu'un OS n'est utile que s'il y a des applications, donc des Developers, Developers, Developers, Developers, ... qui travaillent dessus. Or toutes les autres plateformes concurrentes ont muries au-delà du nécessaire et sont suffisamment stables pour offrir une alternative viable à Windows, et même permettre de gagner sa vie sans utiliser Visual Studio. Les vieilles techniques de ventes liées restent encore d'actualité sur PC, mais aux US les ChromeOS ont fait du mal à Microsoft et impossible de concurrencer Apple ou Android en dehors de procès pour licence et copyright.

Voyez comment se passe le match Google vs. Oracle.

Folco: alors donne moi des raison valable est interessante d'executer des fichier ELF compilé pour Linux directement depuis Windows?

Sachant que 99.999% sont disponible sous forme de source, ou deja disponible sous windows en natif.

Et ne melange pas developeur et manager. Et faire un truc ne veux pas dire etre un abrutit, mais quel est le potentiel du truc? Aucun ou quasiment aucun.

Sans compter qu'il n'ont pas interet a ce que les applicatif sous cet environement soient plus performant que les natifs windows, sinon ca va la foutre sacrément mal..

Godzil (./6088) :
Lancer gedit sous windows? Il est pas deja trouvable?

nedit passe déjà avec cygwin en tout cas.

Mais sinon, la compilation de programmes linuxiens avec cygwin (ou sans doute mingw) n'est pas toujours spécialement évidente ou même possible sans modification, loin de là.

Sisi ca marche tres tres bien, j'ai été pendant plusieurs année dans une boite ou l'application principale etait un truc tournant sous Linux sur CPU ARM, et l'executable en question etait compilé (et de par les scripts de compilation) ne pouvais etre compilé que sous Windows + Cygwin. Donc si ca marche a merveille

Bof, ça me semble très différent de programmer un truc pour le compiler avec cygwin et de prendre des sources lambda et de vouloir les compiler avec cygwin. La portabilité magique, ça ne fonctionne hélas pas à tous les coups.

Perso ça m'évitera une VM pour compiler, que ce soit pour cross-compiler vers Windows ou pour utiliser plusieurs outils comme gcc4ti que je ne sais pas recompiler sous Windows, par exemple.
Question perf j'ai aucune idée de ce que ça donnera, mais question proc et mémoire utilisée y aura pas photo.

Oui, l'intérêt est clairement pour les développeurs. Peut-être que certains vivent encore dans une caverne leur empêchant de réaliser le fait, mais les applications d'aujourd'hui peuvent tourner dans des environnements hybrides Windows / Linux. Par exemple, bon nombre de bases de données hautes performances (ex: redis) tournent aujourd'hui principalement sur Linux et c'est juste super pratique pour un développeur de pouvoir faire tourner l'appli native Linux en local sur la machine sans avoir à chercher un build spécifique, à compiler, ou à installer une lourde VM dans un coin.
Le but long terme on ne le connait pas. Le but immédiat, c'est de faciliter la vie des développeurs quand c'est possible en leur permettant de tout faire tourner directement en local. Tel que c'est vendu, ce sous-système apportera des performances équivalentes à celles qu'on obtient sous Linux, ce qui sera donc aussi avantageux et extrêmement moins coûteux qu'une VM dans la plupart des cas.

./6073 > Par contre, tel que je comprends, c'est avec en bonus une gestion spécifique de tous les syscall Linux, apportant de fait la possibilité d'exécuter directement les binaires d'une distribution compatible sans recompilation. C'est ça qui est top…

pouvoir lancer des vrais scripts qui font des vraies choses est tellement utile que je vois pas comment on peut se poser la question de l'utilité

cygwin est leeeeeeeeeeeeeeeeeeeeeeeeeeeennnnnt et bourré de merdouilles
msys ne marche pas a tous les coups (essayez de compiler kicad 4)

nuttx a toutes les peines du monde a se builder sous un win quelconque (cmd,msys,cygwin)

etc.

Lionel Debroux (./6089) :
L'intégration Ubuntu - Windows ne propose aucune interface graphique, et ça pourrait durer. Certains pensent que c'est précisément fait exprès.

(Cela dit, un serveur X tiers, ça s'ajoute rapidement, et avec la transparence réseau, ça devrait marcher sans trop de problèmes même si ce n'est pas officiellement supporté.)

squalyl (./6099) :
pouvoir lancer des vrais scripts qui font des vraies choses est tellement utile que je vois pas comment on peut se poser la question de l'utilité

cygwin est leeeeeeeeeeeeeeeeeeeeeeeeeeeennnnnt et bourré de merdouilles
msys ne marche pas a tous les coups (essayez de compiler kicad 4)

nuttx a toutes les peines du monde a se builder sous un win quelconque (cmd,msys,cygwin)
etc.

Mais GNU/Windows va venir à la rescousse gràce à MS !

ohwyeah

Au fait, il y a une date de release ?

Il semblerait que ça soit prévu pour Juillet

squalyl (./6102) :
ohwyeah

²
Je pensais que c'était juste un vague démonstrateur... !

Ok, merci Uther. J'ai vraiment mis du temps pour trouver l'info, mais d'après numerama, ça pourrait petre disponible dès maintenant pour les insiders. Par contre, je manque de détails pour savoir comment configurer mon MS Update pour recevoir ça.

Donc si quelqu'un a la solution magique pour obtenir ce fameux Bash sous Windows 10, qu'il n'hésite pas à faire signe, je lui enverrai un Mon Chéri par la poste !

Godzil -> Quelques arguments de professionnels

Ah, au fait, est-ce la mort de CMake ? Les makefiles vont être portables maintenant \o/

Attention, si tu compiles des trucs dans l'environnement Linux, ça te produira des binaires Linux hein

La façon dont c'est fait c'est que tu fais réellement tourner le userland Linux (mais seulement la ligne de commande) en parallèle du userland Windows, les deux sur le même noyau NT. Il y a des passerelles entre les deux, mais faut voir ça comme deux OS disjoints…
Sauf mention contraire, Ubuntu ne pourra pas démarrer des exécutables Windows, pas plus que Windows ne pourra démarrer des exécutables Linux

L'avantage, par contre, c'est que pour tes projets cross-platform, tu pourra compiler nativement sur les deux plateformes sur la même machine, et sans redémarrer… Tu pourras produire tes binaires et packages Linux sur Windows, en même temps que tes binaires et ton installeur Windows.

GoldenCrystal (./6107) :
Attention, si tu compiles des trucs dans l'environnement Linux, ça te produira des binaires Linux hein

Pas si tu utilises cross-MinGW.

GoldenCrystal -> moi ça me va, coder sous Windows et compiler avec les outils Linux, ça suffirait parfaitement à mes besoins.

Folco: merci mais je suis un professionnel tu sais, et cet article ne me donne aucun argument valable autre que "node.js" et heu...

Ensuite ça n'a rien de magique c'est juste un cygwin sans recompilation, ca n'a rien d'extraordinaire, ni de nouveau.

Et je maintient que je pense que c'est une grossière erreur de la part de Microsoft que de faire ca et de le mettre autant en avant.

Et je maintient qu'un environnement à la MinGW ou Cygwin est bien meilleur que le long terme que de faire un "émulateur" de syscall pour un OS etrangé, en tout cas quand 99.9999% des apps sont fournis sous forme de code source. Wine n'existe sous cette forme que parce que les apps Windows ne sont (quasi) jamais fournies avec leur code donc on ne peu que prendre le .exe et tenter de le faire marcher.

Pour moi la raison est surtout de la flemme, comme ça ils n'ont pas besoin de maintenir une seule ligne de code, au moins au niveau outils, et le fait qu'il n'y ai directement aucune passerelle pour le mode graphique (qu'il soit en mode framebuffer ou en mode x11) montre que ce truc ne les intéressent pas vraiment et qu'on cherchent juste à attrister du chaland qui aura une bonne couche de poudre sur les yeux.

Techniquement c'est amusant, pragmatiquement ca ne sert absolument à rien.

Bah, idéalement, ça sert à ne plus jamais avoir à porter nos logiciels pour Windows, ils marcheraient automatiquement en "compatibilité Linux". Mais reste à voir s'il y a une solution convenable pour tout ce qui est graphique. Il faudrait au minimum que ça interopère correctement avec VcXsrv. Sinon, l'utilité est limitée aux développeurs. Mais c'est certainement fait exprès, un peu comme sous OS X où X11 est aussi un citoyen de deuxième classe parce qu'ils veulent pousser à utiliser leurs interfaces graphiques propriétaires.

Kevin Kofler (./6111) :
Mais c'est certainement fait exprès, un peu comme sous OS X où X11 est aussi un citoyen de deuxième classe parce qu'ils veulent pousser à utiliser leurs interfaces graphiques propriétaires.

Non, c'est parce que personne ne s'en sert.

Bah il faut bien dire que ça n'a jamais été mis en valeur par Apple... je ne sais pas si c'est toujours le cas, mais X n'était pas installé par défaut lors des versions au moins jusqu'à X.4, et a surtout servi un temps pour permettre à X de s'enrichir d'applications quand le système tout nouveau n'en avait pas beaucoup (je pense par exemple à NeoOffice, Gimp...) et que l'exécution de Classic était une solution à éviter.
En plus, les applis X étaient (sont ?) exécutées dans un environnement différent, cet environnement étant plein écran (aux antipodes de la pensée de MacOS).
Et c'est bien un choix d'Apple dès le début d'avoir voulu écarter X au profit d'autre chose.

Kevin Kofler (./6111) :
Bah, idéalement, ça sert à ne plus jamais avoir à porter nos logiciels pour Windows, ils marcheraient automatiquement en "compatibilité Linux".

C'est exactement pas fait pour ça.

Mais reste à voir s'il y a une solution convenable pour tout ce qui est graphique.

C'est exactement pas fait pour ça non plus.

Sinon, l'utilité est limitée aux développeurs.

C'est exactement fait pour ça. Pour activer la fonctionnalité, il faudra explicitement passer Windows en mode développeur, et on peut espérer que cela reste impossible sur les versions serveur de Windows.

Mais c'est certainement fait exprès, […] parce qu'ils veulent pousser à utiliser leurs interfaces graphiques propriétaires.

C'est fait exprès parce que le seul truc qui manque sous Windows quand tu es dev, c'est un bon support de certains outils en ligne de commande originaires de Linux. Soit parce que les devs ne savent pas coder (ex: NPM), soit parce que maintenir un portage est compliqué et n'a que peu d'intérêt pour les développeurs du projet (ex: Redis).

Nil (./6113) :
Bah il faut bien dire que ça n'a jamais été mis en valeur par Apple... je ne sais pas si c'est toujours le cas, mais X n'était pas installé par défaut lors des versions au moins jusqu'à X.4, et a surtout servi un temps pour permettre à X de s'enrichir d'applications quand le système tout nouveau n'en avait pas beaucoup (je pense par exemple à NeoOffice, Gimp...) et que l'exécution de Classic était une solution à éviter.
En plus, les applis X étaient (sont ?) exécutées dans un environnement différent, cet environnement étant plein écran (aux antipodes de la pensée de MacOS).Et c'est bien un choix d'Apple dès le début d'avoir voulu écarter X au profit d'autre chose.

Ce post serait plus lisible si tu mettais "X11" et "OS X", parce que là, tu as deux "X".

Nil (./6113) :
Bah il faut bien dire que ça n'a jamais été mis en valeur par Apple...

mais d'un autre côté, pourquoi cela aurait-il été mis en valeur par Apple ? ça ne leur apportait rien de particulier.

Et c'est bien un choix d'Apple dès le début d'avoir voulu écarter X au profit d'autre chose.

Ce n'est pas spécialement contre X, plutôt qu'ils n'avaient aucune raison de le choisir.

GoldenCrystal (./6114) :
C'est fait exprès parce que le seul truc qui manque sous Windows quand tu es dev, c'est un bon support de certains outils en ligne de commande originaires de Linux. Soit parce que les des ne savent pas coder (ex: NPM), soit parce que maintenir un portage est compliqué et n'a que peu d'intérêt pour les développeurs du projet (ex: Redis).

Ce n'est pas pour rien que le premier exemple est bash. Pas un jeu, pas Gimp ou une autre appli graphique.

GoldenCrystal (./6114) :

Kevin Kofler (./6111) :
Bah, idéalement, ça sert à ne plus jamais avoir à porter nos logiciels pour Windows, ils marcheraient automatiquement en "compatibilité Linux".

C'est exactement pas fait pour ça.

Mais reste à voir s'il y a une solution convenable pour tout ce qui est graphique.

C'est exactement pas fait pour ça non plus.

Et c'est bien dommage, mais il y a évidemment des raisons commerciales pour une vision aussi bornée.

Sinon, l'utilité est limitée aux développeurs.

C'est exactement fait pour ça. Pour activer la fonctionnalité, il faudra explicitement passer Windows en mode développeur, et on peut espérer que cela reste impossible sur les versions serveur de Windows.

Pourtant, les versions serveur seraient celles où la compatibilité avec les logiciels GNU/Linux serait la plus intéressante.

Mais c'est certainement fait exprès, […] parce qu'ils veulent pousser à utiliser leurs interfaces graphiques propriétaires.

C'est fait exprès parce que le seul truc qui manque sous Windows quand tu es dev, c'est un bon support de certains outils en ligne de commande originaires de Linux. Soit parce que les devs ne savent pas coder (ex: NPM), soit parce que maintenir un portage est compliqué et n'a que peu d'intérêt pour les développeurs du projet (ex: Redis).

Une API graphique portable manque aussi! X11 permet de viser X11 natif, Mir, Wayland, OS X et même Windows, mais ce dernier fait tout pour que ça ne devienne pas un choix mainstream.

Kevin Kofler (./6118) :
X11 permet de viser X11 natif, Mir, Weyland, OS X et même Windows

Sur OS X, qu'une appli utilise X11 est une raison suffisante pour la mettre à la poubelle

Kevin Kofler (./6118) :

GoldenCrystal (./6114) :
Kevin Kofler (./6111) :
Bah, idéalement, ça sert à ne plus jamais avoir à porter nos logiciels pour Windows, ils marcheraient automatiquement en "compatibilité Linux".C'est exactement pas fait pour ça.Mais reste à voir s'il y a une solution convenable pour tout ce qui est graphique.C'est exactement pas fait pour ça non plus.

Et c'est bien dommage, mais il y a évidemment des raisons commerciales pour une vision aussi bornée.

C'est pas uniquement une histoire de commerce... C'est comme si tu disais, "j'ai installé une debian, je comprends pas pourquoi ils font tout un foin pour aptitude/apt-get alors qu'alien permettrait d'utiliser les paquets de redhat...". Dans ce cas autant ne rien faire, mais si tu dois promouvoir une solution, faut commencer par la tienne, à moins que tu sois intimement convaincu que c'est de la merde (et là encore, autant ne rien faire)