Microsoft conferma l'arrivo della shell Bash di Linux in Windows 10

Quindi il nocciolo di tutto è che MS vuole attirare sviluppatori sulla sua piattaforma perchè ha bisogno di tante universal app da mettere nello store..
Per l'utente normale questa cosa è del tutto irrilevante.

io per esempio ora sto provando osx perchè mi unisce pregi di windows e di linux (e ci aggiunge alcuni suoi difetti ) il supporto "nativo" di python su windows per esempio è risibile rispetto a quello che c'è per gli altri SO, senza usare tool esterni intendo. Quando scrissi la tesi di laurea, il codice funzionava bene su osX e su linux, ma alcune librerie davano problemi su windows, se si eliminassero questi problemi, probabilmente non userei più linux per sviluppare.

Poi io qualche scriptino in bash me lo sono scritto, ricordo che per fare una compattazione/copia/rinomina di lunghi elenchi di file, avevo scritto un paio di righe in bash che già conoscevo e utilizzavo linux solo per quello su un altra macchina su un hd di rete da cui poi accedevo con windows. Avere la shell mi avrebbe evitato un passaggio.

all'atto pratico non vedo molti scenari di utilizzo, é un po' come playonlinux su ubunutu appunto, se sei legato a programmi che girano nativamente solo su un OS alla fine usi quel OS e basta.
Lo sviluppatore di turno che usa windows come piattaforma per scrivere codice non ha bisogno di linux sul pc sotto windows, al limite si installa putty e si collega sul server linux altrimenti usa cygwin se ha problemi di account o di permessi sulle macchine.
Per carità é comunque una feature interessante e utile, ma per un pubblico molto molto ristretto a mio avviso.

Trovato altro blog linkato da TheVerge: http://www.hanselman.com/blog/Devel...nWindows10.aspx
Si alla fine tutto il discorso giunge al problema delle app.

Alla fine ragionandoci tutto ciò è una mossa per cercare di portare sviluppatori a sviluppare per Windows, su Windows, con tutti gli strumenti che più gli piacciono e con cui sono maggiormente famigliari.

Evidentemente non conosci bene Powershell che per certi versi è ben più potente di bash.

Powershell non "si basa su script pensati e creati da MS", anzi e possibile creare scripts e comandi utilizzando non solo tutte le API del .NET Framework, ma anche tutte le librerie di terze parti per il .NET che si trovano sul web.

Windows 10 esiste in versione server, o meglio esisterà quando verrà rilasciato Windows Server 2016



L'obiettivo sono gli sviluppatori Linux e permettere loro di utilizzare gli strumenti ai quali sono abituati anche su Windows.



Bash non è di Canonical e non è esclusiva di Ubuntu, ma Canonical ha collaborato con Microsoft per portare i binari di su Windows.



Puoi usare Powershell per fare tutte le attività di amministrazione.
L'implementazione di Bash sembra più indirizzata agli sviluppatori linux (in particolare gli sviluppatori web, come del resto il coinvolgimento di Scott Hanselman, che è uno dei capoccioni dietro Asp.NET, suggerirebbe)


Non si tratta di una versione minimale (almeno non nella versione definitiva) ma si tratta di poter avere [U]esattamente[/U] gli stessi strumenti utilizzati su Linux in Windows.
L'intento è quello di poter fornire un unico ambiente allo sviluppatore


Comunque se vorrete saperne di più ci sono in programma queste sessione in cui ne parleranno:
https://channel9.msdn.com/Events/Build/2016/P488
https://channel9.msdn.com/Events/Build/2016/C906

La prima è già online, è una sessione pre-registrata e mostra delle demo su come funziona il subsystem

cygwin è carino se non fosse che trovo l'installer bruuuuuutto come non mai o_o

non è molto comodo dover rilanciarlo per gestirne i pacchetti!

Giusto per chiarire le idee a chi non lo sapesse. Sin dai tempi di Windows NT c'era a livello di SO il supporto per un userspace POSIX (fatto male, ma c'era) solo che a quei tempi era chiamato sottosistema POSIX.
Di fatto gia con quello si potevano portare software ed utilities che giravano su Linux, ecc. ecc.
Solo che tutto il resto era differente ed era più semplice seguire l'approccio che ha prodotto cygwin e mingw
(fare girare il tutto sopra il sottosistema win32).
Il punto è che Microsoft lo aveva fatto per rendere più appetibile il suo nuovo SO ( NT in quel caso) e poi si è disinteressata della cosa.
Ora si sta ripetendo lo stesso schema in un contesto leggermente diverso, ma non credo che l'esito finale sarà tanto differente.

LOL
Hanno fatto un host per User Mode Linux: la pseudo virtualizzazione che si usava una decina di anni fa
Cioe' oggi che si usano i containers e Docker questi ti tirano fuori UML!

Non e' una virtual machine nel senso che e' una paravirt: non c'e' completa astrazione dell'HW ma e' un processo che gira sotto windows e espone uno pseudo kernel - API all'host Unix. ...sempre alla maniera di 10 anni fa eh, non e' che e' isolato proprio bene... Il che vuol dire che si potrebbe scrivere un bel troiano in *nix per far disastri sotto win, giusto ce ne fosse bisogno :P

Quindi potenzialmente potete fare girare tutti i tool che girano sotto ubuntu (non vedo perche' non un'altra distro a parte la decenza )

Che comunque e' una cagata perche' sempre virtualizzazione e'! Non state usando i tools unix sotto windows, state facendo girare una macchina virtuale per i fatti suoi. I due tipi nel demo fanno i fenomeni dopo aver montato il filesystem win su linux e.... TaDa!
Funziona il completamento automatico!
Posso compilare un sorgente!

Ma andate a cagare... Posso farlo anche in questo momento montando quel fs su qualunque distro linux, anche da virtualbox che sicuramente ha piu' accelerazioni hardware e tools di quell'accrocchio che avran fatto basato su roba di 15 anni fa...

E io che pensavo che avessero integrato i base tools sotto windows in un modo "piu' nativo" rispetto al vecchio CGWIN che e' cento volte piu' avanti di questa boiata.

Gia'... Potete far girare una macchina virtuale ubuntu in paravirtualizzazione sotto windows, che culo... Molto meglio usare direttamente linux, montare il filesystem e poi USARE VERAMENTE i binari win con Wine che e' un'implementazione completa delle api win sotto un OS diverso.

Non vedo quale sia il problema: non è stato certamente chiesto nulla di virtualizzato, ma un substrato che consenta l'esecuzione di comuni comandi Linux. Tanto basta per far contenti gli sviluppatori che si trovano a loro agio con certi strumenti che sono comunemente usati su Linux.

E' da anni che sviluppo software in Python, sostanzialmente solo su Windows, ma che funziona su Linux (e sono abbastanza sicuro che giri anche su OS X).

Non è un problema di Python, ma di codice scritto bene, usando le sue API per gestirgli gestire le differenze fra i diversi s.o., o per scrivere codice che ne tenga conto.

Detto in altri termini, i problemi sono di chi ha sviluppato quelle librerie.

bash va bene finché si tratta di qualche riga di codice, ma quando cominci a usarlo per strutturare qualcosa di più complesso è molto meglio affidarsi a linguaggi che si prestano meglio, e che consentono di agevolare anche future manutenzioni.

Per questo motivo Python ha preso piede anche per chi di professione fa il sysadmin e si trova a dover scriver script: Python for Unix and Linux System Administration

Preferisco mingw e installarmi solo ciò che mi serve (SE mi serve mingw: finora ne faccio uso soltanto a lavoro, nelle macchine di produzione che usano Windows per alcuni progetti).

Cygwin è un mammuth che è meglio scomodare soltanto quando non c'è altra soluzione possibile.

Il subsystem POSIX serviva a Microsoft software per certificare che NT soddisfaceva alcuni requisiti per far girare software POSIX-compliant, e il problema più grosso (oltre al fatto che è rimasto fermo a una vecchia versione di POSIX) era/è (perché con Vista è tornato, dopo essere stato dismesso con XP) rappresentato dal fatto che fosse disponibile soltanto con le versioni professionali di Windows (non ricordo se fosse necessaria la Enterprise o la Ultimate; non mi pare che la versione Professional ne consentisse l'installazione).

Questo strumento, invece, sembra disponibile e funzionare con qualunque versione di Windows.