- Modificato
IlariaBressi Ottimo! quindi niente più "wine" su linux e niente più "ubuntu" su windows!
IlariaBressi Ottimo! quindi niente più "wine" su linux e niente più "ubuntu" su windows!
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.
juststupid la struttura di un task/thread/process di windows è molto differente
Wine come ho detto originariamente esiste e si può addirittura giocare, ma la differenza con wsl è che uno è portato avanti in modo indipendente e senza la possibilità di avere sorgenti del kernel nt (ora bisogna dire che sono stati fatti dei leak, ma non so se possano farci qualcosa), mentre l'altro è supportato da Microsoft che ha molti più fondi e soprattutto ha accesso a tutto codice completamente open source, direi che c'è un po' di differenza.
[cancellato] binari Apple su Linux o BSD
Esiste un progetto attualmente in sviluppo per poter eseguire binari di xnu su Linux, con lo stesso concetto di Wine (si chiama Darling)
[cancellato] fare GUI in Linux è un campo minato perché non esiste una UI con widget e font decenti e coerenti
No, su Linux i desktop environment utilizzano alla base principalmente gtk e qt, e hanno tutti e due un tema di base che è utilizzato globalmente, puoi anche cambiarlo con quello che vuoi (una cosa che né Windows né MacOS possono fare facilmente)
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.
dadadani Esiste un progetto attualmente in sviluppo per poter eseguire binari di xnu su Linux,
Sì, ma appunto come Wine è un progetto di terze parti, non di Apple.
dadadani No, su Linux i desktop environment utilizzano alla base principalmente gtk e qt
E già quel "principalmente" è un problema e sono già almeno due.
dadadani puoi anche cambiarlo con quello che vuoi (una cosa che né Windows né MacOS possono fare facilmente)
Ed è anche quello un problema lato sviluppo.
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.
Sviluppare GUI è complesso e farle bene richiede molto tempo, con l'apporto anche di chi si occupa di grafica per tutti gli elementi necessari, e test con gli utenti per vedere se il tutto funziona fluido. Quando ti trovi a combattere con un OS dove non hai un'API e un look&feel coerente diventa un vero disastro. In più hai il problema di compatibilità in avanti e all'indietro e distro con versione a volte anche molto diverse delle librerie. 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à. O ora con qualche versione di Javascript + renderer HTML per lo stesso motivo. Ma entrambe le tecnologie rispetto a vere applicazioni native qualche limite ce l'hanno.
Questo su Windows e macOS non si verifica. MS ha cercato disperatamente di frammentare anche la UI di Windows, ma siccome Win32 era sempre lì, molti se ne sono fregati e han continuato a usare quella che assicurava la necessaria compatibilità.
Poiché molte applicazioni commerciali non ti daranno MAI i sorgenti da compilare in loco, e non sono interessate a moltiplicare all'infinito configurazioni e test, se ne stanno alla larga anche perché sanno che un mercato di utenti paganti non esiste, quello rimane su Windows e macOS.
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.
dadadani infatti utilizzo LXQt...secondo me, è il futuro.
speriamo solo che sistemino Wayland
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:
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
Si ma se ne parlerà solo con Windows 10 21H2 o successivi e Windows Server 2022, ora è solo in preview.
matteocontrini WSL1 è/era un lavoraccio da mantenere comunque
E se non bastasse mancavano tante funzionalità
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
leoniDAM Della parte di reti, che è quello che più mi interessava, non funzionava praticamente nulla. Mi riferisco a cose come ping, mtr, nmap, nginx
[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.
dadadani Le liberie per la creazione di programmi desktop sono fatte apposta per rimanere consistenti con qualsiasi tema tu voglia
Nella teoria sì. Nella pratica no. Basta poco perché una UI appaia "fuori posto". Sono già brutte le UI Qt, il resto sotto Linux è anche peggio.
dadadani insomma questo evento è raro che accada.
Sicuro? Vuol dire che devi testare e pacchettizzare l'applicazione per ogni distro - con tutte le sue varianti delle librerie. Cosa che con Windows non devi fare perché Win32 è sempre la stessa, ci pensa l'OS, non ci deve impazzire lo sviluppatore.E poiché la GPL è un campo minato, applicazioni commerciali spesso non possono dipendere da librerie che le costringerebbero a rilasciare tutto il codice sorgente. È anche per questo che molte applicazioni semplicemente non sono portate sotto Linux e non lo saranno forse mai.
dadadani perciò il problema non si pone.
Appunto. Non sono applicazioni native.
dadadani abbiamo di popolari WPF, Qt, Windows Forms e UWP.
Sinceramente, chi fa applicazioni Windows seriamente se ne frega di WPF, Qt, Windows Forms e UWP - anche perché non usa .NET. Usa Win32, fa prima e le applicazioni funzionano molto meglio.
Informativa privacy
-
Informativa cookie
-
Termini e condizioni
-
Regolamento
-
Disclaimer
-
🏳️🌈
P.I. IT16712091004 - info@fibraclick.it
♻️ Il server di questo sito è alimentato al 100% con energia rinnovabile