Windows 10, è ora possibile eseguire i programmi Linux con interfaccia grafica

chris190 niente più "wine" su linux

A me sembra che vogliano soltanto aggiungere la possibilità di eseguire binari per Linux su Windows, non il contrario purtroppo (e mica vorrebbero, altrimenti perdono il market share di un sistema operativo tirato avanti con la ruota di ricambio)

dadadani
la struttura di un task/thread/process di windows è molto differente e più complicata di uno di linux per cui non è detto che il gioco valga la candela.

dadadani non il contrario purtroppo

Non mi pare che Apple abbia in progetto la possibilità di eseguire binari Apple su Linux o BSD - che sarebbe ancora più semplice.... non vedo perché dovrebbe farlo Microsoft

In realtà il problema è tutto lato Linux, fare GUI in Linux è un campo minato perché non esiste una UI con widget e font decenti e coerenti - il giorno che si accordano per averla, e magari la fanno disegnare da qualcuno che almeno ha finito l'asilo (dove si trova anche chi ha disegnato la UI di Windows 10...), allora forse si vedranno più applicazioni GUI Linux decenti e GPL permettendo, qualcuno vorrà portare le sue applicazioni.

Quindi a breve potrò disinstallare VcXsrv? Interessante.

dadadani ora bisogna dire che sono stati fatti dei leak, ma so se possano farci qualcosa

No bueno utilizzare codice piratato e sotto copyright per progetti OS.
Se non sbaglio il team di un noto emulatore vietò a tutti i contributori l'utilizzo del codice di un leak Nintendo per evitare problemi legali.

Se non mi ricordo già si poteva far "spawnare" una sessione grafica da WSL, ma che senso ha avere un kernel Linux che gira dentro Windows per far girare quei due programmi in croce come ssh? A sto punto Microsoft si decida a farsi una sua distro Linux, chiamarla Windows 11, e metterci il suo DE proprietario e Wine per la retrocompatibilità dei programmi Win32. Ci risparmia un botto di soldi in sviluppo

dadadani
Piuttosto che usare wine ad uno conviene vitualizzate Windows su linux per avere una compatibili decentemente con le applicazioni. Detto questo come ho detto prima le strutture dei processi thread task tra win e linux sono molto differenti per cui il costo per una azienda come ms non sarebbe indifferente sopratutto se il target fosse un buona compatibilità con il sw e non un “spera che il sw sia compatibile” di wine.

Emmeci ma che senso ha avere un kernel Linux che gira dentro Windows per far girare quei due programmi in croce come ssh

È comodo per fare alcuni test senza dover eseguire un'intera VM separatamente. Per esempio se dovete eseguire un sito che girerà su un server Apache sotto Linux, e debuggarlo in un browser Windows è molto comodo, se si vuole fare tutto in locale. Si può anche installare Apache + quello che serve anche su Windows, ma non si ha la certezza che il tutto sia esattamente uguale.

Emmeci
WSL è uno strumento pensato, in origine, per gli sviluppatori.
Il senso di WSL era, ed è, quello di permettere agli sviluppatori due cose:

• utilizzare gli strumenti di sviluppo che sono disponibili su Linux, sia se quegli strumenti non sono disponibili per Windows, sia se magari lo sviluppatore preferisce quelle versioni per qualunque ragione.
• testare applicazioni per Linux direttamente da Windows.

In origine Microsoft non aveva intenzione di supportare le applicazioni grafiche, ma hanno avuto un altissimo numero di feedback che richiedevano questa cosa ed allora hanno deciso di introdurne il supporto.

In realtà WSL non è costata poi molto, la prima versione sfruttava delle funzionalità di Windows disponibili già da (praticamente) sempre, poi nella seconda versione di WSL, hanno optato per un'altro approccio che consiste sostanzialmente in un container. Probabilmente gli costerebbe molto di più rilasciare una distro Linux e renderla "feature parity" con Windows...

leoniDAM WSL1 è/era un lavoraccio da mantenere comunque, WSL2 invece essendo sostanzialmente una macchina virtuale presumo sia molto meno impegnativo

matteocontrini WSL1 è/era un lavoraccio da mantenere comunque

E se non bastasse mancavano tante funzionalità

matteocontrini

Il sottosistema sul quale si basava WSL1 esisteva già in Windows, parte del lavoro c'èra già, il problema di WSL1 era dover tradurre le system call Linux in system call Windows.
In WSL2 non c'è più la necessità di mantenere un layer di compatibilità fra le system call dei due sistemi operativi tutte le applicazioni funzionano as is, rimane comunque la necessità di rendere quanto più trasparente possibile la VM

handymenny E se non bastasse mancavano tante funzionalità

Uno degli sviluppatori di WSL in una intervista (parliamo di quando WSL venne annunciato nel 2016 se non sbaglio) disse che nel kernel Linux c'erano circa 300 system call e loro ne avevano implementate circa 150-200

[cancellato] In realtà su Windows potevi facilmente avere dei temi già al tempo di XP. Però è una di quelle cose che 1) tende a confondere gli utenti quando passano da un PC all'altro 2) Obbligano gli sviluppatori a verificare che le applicazioni funzionino qualsiasi sia il tema.

Le liberie per la creazione di programmi desktop sono fatte apposta per rimanere consistenti con qualsiasi tema tu voglia utilizzare, se riscontri problemi è colpa di chi lo ha creato, non del sistema operativo o qt/gtk.

[cancellato] In più hai il problema di compatibilità in avanti e all'indietro e distro con versione a volte anche molto diverse delle librerie.

Finché tu usi un package manger fatto bene, le dipendenze verranno sempre risolte da quello, e inoltre su Linux sono state create le appimage che sono complete applicazioni ma con le librerie già incluse, insomma questo evento è raro che accada.

[cancellato] Non è un caso che molte applicazioni GUI per Linux in realtà sono fatte in Java dove ci pensa il JRE/JDK a fare da layer di compatibilità.

JavaFX è cross-platform come il linguaggio stesso e dire che "sono per Linux" è sbagliato, e anche se fossero consigliate per questo target, sono estremamente poche e di certo non componenti di interi ambienti grafici.

[cancellato] O ora con qualche versione di Javascript + renderer HTML per lo stesso motivo.

Le applicazioni che sono in realtà con "tecnologia web" usano ormai tutte quante alla base Electron, ed ognuna contiene di base il proprio motore e perciò il problema non si pone.

[cancellato] MS ha cercato disperatamente di frammentare anche la UI di Windows

Lo è da sempre stato, solo che qui siamo messia ancora peggio: abbiamo di popolari WPF, Qt, Windows Forms e UWP.

Le applicazioni native di "livello grosso" sono destinate a scendere, si punta ad utilizzare un qualcosa che possa essere il più portatile possibile, ad esempio Photoshop che mica rispetta il design di macOS o Windows, ma ne ha uno tutto suo.