PDA

View Full Version : Torvalds non ha dubbi: il kernel Linux 5.8 tra le release più grandi di sempre


Redazione di Hardware Upg
16-06-2020, 19:01
Link alla notizia: https://www.hwupgrade.it/news/sistemi-operativi/torvalds-non-ha-dubbi-il-kernel-linux-58-tra-le-release-piu-grandi-di-sempre_90130.html

Linus Torvalds ha presentato la prima release candidate del kernel Linux 5.8, la cui versione finale dovrebbe essere pronta per agosto. Si tratta di una release davvero grande, forse la più grande di sempre, con tantissimi interventi.

Click sul link per visualizzare la notizia.

Fantapollo
16-06-2020, 20:23
Linux in VM con i driver di Windows funziona meglio che con i driver nativi :D

Breaking
16-06-2020, 21:16
Linux in VM con i driver di Windows funziona meglio che con i driver nativi :D

in wsl, linux utilizza i suoi driver nativi. il problema è che viene avviato come sottosistema di un sistema portante avviato. di fatti le performance si perdono per strada. gli ultimi test di phoronix mostrano che c'è ancora un abisso nelle prestazioni di questa tecnologia, wsl non sembra raggiungere nemmeno per sogno le performance di una distro linux nativa. io personalmente non ne capisco l'utilità, ne per una gestione server e nemmeno per la programmazione.

Fantapollo
16-06-2020, 21:54
in wsl, linux utilizza i suoi driver nativi. il problema è che viene avviato come sottosistema di un sistema portante avviato. di fatti le performance si perdono per strada. gli ultimi test di phoronix mostrano che c'è ancora un abisso nelle prestazioni di questa tecnologia, wsl non sembra raggiungere nemmeno per sogno le performance di una distro linux nativa. io personalmente non ne capisco l'utilità, ne per una gestione server e nemmeno per la programmazione.

Driver nativi = driver nativi per la vm.
Ora vado a vedermi i test di Phoronix, perché io perdite di prestazioni non ne ho proprio notate

acerbo
17-06-2020, 07:40
Linux in VM con i driver di Windows funziona meglio che con i driver nativi :D

usi comunque piu' ram e piu' disco, mica gira per grazia divina una vm all'interno di un sistema operativo.
E comunque anche chissene, io winzozz devo usarlo per politiche aziendali, fosse per me sul disco rigido lascerei solo linux su installazione nativa, windows non lo vorrei vedere nemmeno in foto.

andy45
17-06-2020, 08:55
io personalmente non ne capisco l'utilità, ne per una gestione server e nemmeno per la programmazione.

Serve a semplificare la vita ai programmatori su windows, niente di più, niente di meno...e comunque non è una VM, è un compatibility layer, quindi direi che l'equivalente linux è wine.

andy45
17-06-2020, 09:10
Linux in VM con i driver di Windows funziona meglio che con i driver nativi :D

WSL non è una VM, e cmq funziona bene per fare cosa?

The_ouroboros
17-06-2020, 09:14
io personalmente non ne capisco l'utilità, ne per una gestione server e nemmeno per la programmazione.

una parola: sviluppo

mattia.l
17-06-2020, 09:32
WSL non è una VM, e cmq funziona bene per fare cosa?

WSL 2 non è una vm ora?

andy45
17-06-2020, 09:47
WSL 2 non è una vm ora?

Non è mai stato una VM, è un layer di compatibilità, in modo molto rozzo traduce a windows quello che dice un eseguibile linux...in pratica quello che fa wine su linux.

biometallo
17-06-2020, 10:15
Preciso subito che sono il più ignorante in materia qui dentro però ad una ricerca veloce leggo che:
WSL 2: come cambierà con il rilascio di Windows 10 20H1 (https://www.ilsoftware.it/articoli.asp?tag=WSL-2-come-cambiera-con-il-rilascio-di-Windows-10-20H1_20544)


Con l'avvento di Windows 10 20H1, come abbiamo anticipato nell'articolo Microsoft presenta WSL 2: il kernel Linux va su Windows all'interno di una mini macchina virtuale, i tecnici Microsoft introdurranno un'importante novità: anziché usare un livello di compatibilità per convertire le chiamate dirette al kernel Linux in chiamate Windows, WSL 2 offrirà un sistema isolato mediante hypervisor Hyper-V.
Linux sarà di fatto virtualizzato in WSL 2 e utilizzerà un disco virtuale basato su file system ext4 impiegando il protocollo 9p per le interazioni con Windows.

Fantapollo
17-06-2020, 10:17
Con l'avvento di Windows 10 20H1, come abbiamo anticipato nell'articolo Microsoft presenta WSL 2: il kernel Linux va su Windows all'interno di una mini macchina virtuale, i tecnici Microsoft introdurranno un'importante novità: anziché usare un livello di compatibilità per convertire le chiamate dirette al kernel Linux in chiamate Windows, WSL 2 offrirà un sistema isolato mediante hypervisor Hyper-V.
Linux sarà di fatto virtualizzato in WSL 2 e utilizzerà un disco virtuale basato su file system ext4 impiegando il protocollo 9p per le interazioni con Windows.

Esattamente :D

Unrealizer
17-06-2020, 10:23
in wsl, linux utilizza i suoi driver nativi. il problema è che viene avviato come sottosistema di un sistema portante avviato. di fatti le performance si perdono per strada. gli ultimi test di phoronix mostrano che c'è ancora un abisso nelle prestazioni di questa tecnologia, wsl non sembra raggiungere nemmeno per sogno le performance di una distro linux nativa. io personalmente non ne capisco l'utilità, ne per una gestione server e nemmeno per la programmazione.

Serve a semplificare la vita ai programmatori su windows, niente di più, niente di meno...e comunque non è una VM, è un compatibility layer, quindi direi che l'equivalente linux è wine.

WSL non è una VM, e cmq funziona bene per fare cosa?

Non è mai stato una VM, è un layer di compatibilità, in modo molto rozzo traduce a windows quello che dice un eseguibile linux...in pratica quello che fa wine su linux.

Questo è WSL 1, mentre WSL 2 è una micro-VM (per la precisione è un container "Krypton" - i vari tipi di container su Windows hanno nomi di gas nobili e in ordine di "isolamento" sono Helium, Argon, Krypton e Xenon, link (https://twitter.com/h0x0d/status/870136610167201792/photo/1))

andy45
17-06-2020, 10:23
Preciso subito che sono il più ignorante in materia qui dentro però ad una ricerca veloce leggo che:
WSL 2: come cambierà con il rilascio di Windows 10 20H1 (https://www.ilsoftware.it/articoli.asp?tag=WSL-2-come-cambiera-con-il-rilascio-di-Windows-10-20H1_20544)


Con l'avvento di Windows 10 20H1, come abbiamo anticipato nell'articolo Microsoft presenta WSL 2: il kernel Linux va su Windows all'interno di una mini macchina virtuale, i tecnici Microsoft introdurranno un'importante novità: anziché usare un livello di compatibilità per convertire le chiamate dirette al kernel Linux in chiamate Windows, WSL 2 offrirà un sistema isolato mediante hypervisor Hyper-V.
Linux sarà di fatto virtualizzato in WSL 2 e utilizzerà un disco virtuale basato su file system ext4 impiegando il protocollo 9p per le interazioni con Windows.

Hai ragione, chiedo scusa per la mia ignoranza, ma a questo punto a che serve? WSL è un layer di compatibilità, che teoricamente dovrebbe essere migliore di una VM...dovrebbe anche garantire prestazioni superiori, almeno in teoria...a che pro farlo diventare una banale virtual machine?

Fantapollo
17-06-2020, 10:29
Hai ragione, chiedo scusa per la mia ignoranza, ma a questo punto a che serve? WSL è un layer di compatibilità, che teoricamente dovrebbe essere migliore di una VM...dovrebbe anche garantire prestazioni superiori, almeno in teoria...a che pro farlo diventare una banale virtual machine?

Perché è una VM ultraottimizzata per garantire un'esperienza d'uso superiore a Linux Nativo. :cool:

Unrealizer
17-06-2020, 10:30
Hai ragione, chiedo scusa per la mia ignoranza, ma a questo punto a che serve? WSL è un layer di compatibilità, che teoricamente dovrebbe essere migliore di una VM...dovrebbe anche garantire prestazioni superiori, almeno in teoria...a che pro farlo diventare una banale virtual machine?

Compatibilità soprattutto, si sono accorti che per avere un sistema usabile non bastava implementare le stesse syscall ma doveva comportarsi alla stessa maniera del vero Linux "bug per bug" (ovvero in ogni minimo dettaglio, anche quelli inaspettati/non previsti).
Era anche un lavoro immane supportare TUTTE le syscall, praticamente stavano riscrivendo un intero mezzo kernel, con una superficie di attacco immensa (lxss.sys era circa 700 KB al lancio) e andavano troppo lenti nello sviluppo

In questo modo usano il vero kernel per avere la compatibilità massima possibile, semplificando parecchio lo sviluppo.

Le performance sono abbastanza simili all'hardware in realtà, l'enorme collo di bottiglia lo vedi quando accedi al filesystem Windows, quello è LEEEEEEENTO dato che avviene tramite plan9, mentre se resti all'interno del filesystem del container è praticamente come usare Docker su Linux (tralaltro adesso Docker Desktop può usare WSL2 come backend invece di tirare su una VM, e quindi adesso si può usare anche su Windows Home)

andy45
17-06-2020, 10:48
Perché è una VM ultraottimizzata per garantire un'esperienza d'uso superiore a Linux Nativo. :cool:

Linux nativo è un'altra cosa, lascia stare :).

andy45
17-06-2020, 10:49
Compatibilità soprattutto, si sono accorti che per avere un sistema usabile non bastava implementare le stesse syscall ma doveva comportarsi alla stessa maniera del vero Linux "bug per bug" (ovvero in ogni minimo dettaglio, anche quelli inaspettati/non previsti).
Era anche un lavoro immane supportare TUTTE le syscall, praticamente stavano riscrivendo un intero mezzo kernel, con una superficie di attacco immensa (lxss.sys era circa 700 KB al lancio) e andavano troppo lenti nello sviluppo

Ok, quindi visto che il gioco non valeva la candela meglio passare alla virtualizzazione.

The_ouroboros
17-06-2020, 10:54
Ok, quindi visto che il gioco non valeva la candela meglio passare alla virtualizzazione.

o... per esempio... passare ad un *nix :)

Unrealizer
17-06-2020, 11:18
Ok, quindi visto che il gioco non valeva la candela meglio passare alla virtualizzazione.

Fondamentalmente si :D

o... per esempio... passare ad un *nix :)

Per certe cose si (es. in questo momento io sto usando Kubuntu perché è la cosa più adatta al lavoro che sto facendo), però avere effettivamente entrambi gli OS a portata di mano ha il suo perché

E puoi anche avere più istanze di più distro (+ i container Docker), che è un discreto valore aggiunto in certi casi :D

Ad esempio, ultimamente ho lavorato un po' per hobby al porting di un framework per app cross platform (MvvmCross (https://github.com/mvvmcross/mvvmcross)) su Gtk 3, il problema però è che praticamente nessuna delle altre piattaforme supportate è usabile su Linux (a parte Tizen, ma debuggare in remoto sul 55" è un tantino scomodo), quindi poter lavorare su Windows e Visual Studio per testare il comportamento dei vari componenti su Android/UWP/WPF e Gtk (sia su Windows che su Linux) dalla stessa macchina ha la sua comodità :D

EDIT: in più è possibile usare KVM (https://boxofcables.dev/accelerated-kvm-guests-on-wsl-2/) per virtualizzare pure macOS :D

OUTATIME
17-06-2020, 21:57
E puoi anche avere più istanze di più distro (+ i container Docker), che è un discreto valore aggiunto in certi casi :D
Io ad esempio ho smesso di usare Openmediavault quando hanno iniziato ad implementare i docker. Personalmente non li sopporto.

Unrealizer
17-06-2020, 22:58
Io ad esempio ho smesso di usare Openmediavault quando hanno iniziato ad implementare i docker. Personalmente non li sopporto.

Perché mai? Sono comodissimi

ase
18-06-2020, 07:03
beh tanto alcuni maligni dicono che il prossimo Windows (windows 15, 20 o come lo chiameranno) sarà solo un DE di Linux. :D :D :D

Magari! :D

OUTATIME
18-06-2020, 07:18
Perché mai? Sono comodissimi
Si, indubbiamente il concetto di separare le applicazioni in contenitori è una bella pensata. Ma su OMV mi sembra che tutto il progetto di muovere i moduli su docker sia ancora un po' acerbo. OMV nasceva come soluzione pronto uso adatta anche ai newbie, proprio per il lavoro di porting che facevano gli sviluppatori. Se mi devo sbattere ad usare docker, a questo punto passo ad una Debian ufficiale e uso tutto in ambiente standard (che è quello che ho fatto). Comunque si va troppo OT, era solo per dire che IMHO docker non è la soluzione per tutto.

andy45
18-06-2020, 08:07
Per certe cose si (es. in questo momento io sto usando Kubuntu perché è la cosa più adatta al lavoro che sto facendo), però avere effettivamente entrambi gli OS a portata di mano ha il suo perché

E puoi anche avere più istanze di più distro (+ i container Docker), che è un discreto valore aggiunto in certi casi :D

A me sembra solo una gran confusione...e lo dico anche per l'accoppiata linux+wine, se mi servono applicazioni windows su linux vuol dire che ho sbagliato a scegliere sistema operativo.

The_ouroboros
18-06-2020, 08:30
che poi i container sono una tecnologia per server, non desktop :oink:

Unrealizer
18-06-2020, 10:08
beh tanto alcuni maligni dicono che il prossimo Windows (windows 15, 20 o come lo chiameranno) sarà solo un DE di Linux. :D :D :D

Magari! :D

Ne dubito fortemente

Si, indubbiamente il concetto di separare le applicazioni in contenitori è una bella pensata. Ma su OMV mi sembra che tutto il progetto di muovere i moduli su docker sia ancora un po' acerbo. OMV nasceva come soluzione pronto uso adatta anche ai newbie, proprio per il lavoro di porting che facevano gli sviluppatori. Se mi devo sbattere ad usare docker, a questo punto passo ad una Debian ufficiale e uso tutto in ambiente standard (che è quello che ho fatto). Comunque si va troppo OT, era solo per dire che IMHO docker non è la soluzione per tutto.

Ah ok, tutto chiaro adesso :D

PS: nickname fantastico :D

A me sembra solo una gran confusione...e lo dico anche per l'accoppiata linux+wine, se mi servono applicazioni windows su linux vuol dire che ho sbagliato a scegliere sistema operativo.

Mah secondo me è utile invece, sia per quello che dicevo poco fa del toolkit che sto scrivendo (valido il comportamento della versione WPF e sviluppo la mia versione Gtk su Windows e Linux dalla stessa macchina, in maniera quasi trasparente e senza VM classiche), sia per molti altri scenari.

Un altro esempio è poter lavorare contemporaneamente alla parte server di un'applicazione, che gira su Linux e a un client nativo + la possibilità di usare tool come Adobe Xd per vedere come fare la UI

che poi i container sono una tecnologia per server, non desktop :oink:

Sono comodi anche quando ti serve avere una versione locale del backend :D

Windows comunque sta spingendo parecchio per i container su desktop, sono già usati in maniera trasparente da un po': le app dallo Store, sia UWP che Desktop Bridge sono dentro container Helium, Edge (entrambi) e Chromium usano container Argon, Application Guard su Edge, Windows Sandbox e WSL2 usano container Krypton e la stessa cosa viene usata per le applicazioni classiche su Windows 10X ("VAIL")

andy45
18-06-2020, 11:18
Mah secondo me è utile invece, sia per quello che dicevo poco fa del toolkit che sto scrivendo (valido il comportamento della versione WPF e sviluppo la mia versione Gtk su Windows e Linux dalla stessa macchina, in maniera quasi trasparente e senza VM classiche), sia per molti altri scenari.

Un altro esempio è poter lavorare contemporaneamente alla parte server di un'applicazione, che gira su Linux e a un client nativo + la possibilità di usare tool come Adobe Xd per vedere come fare la UI

Giustamente il tuo punto di vista è quello di uno sviluppatore, dove ti fa comodo avere più cose possibili sotto mano, dal mio punto di vista, quello dell'analista numerico, vedo queste cose come uno spreco di risorse e una possibile fonte di instabilità...giustamente paese che vai usanza che trovi :).

The_ouroboros
18-06-2020, 11:23
Giustamente il tuo punto di vista è quello di uno sviluppatore, dove ti fa comodo avere più cose possibili sotto mano, dal mio punto di vista, quello dell'analista numerico, vedo queste cose come uno spreco di risorse e una possibile fonte di instabilità...giustamente paese che vai usanza che trovi :).

instabilità? Container sono fatti apposta per essere isolati cosi se qualcosa si rompe non tempe tutto il resto :)

andy45
18-06-2020, 11:31
instabilità? Container sono fatti apposta per essere isolati cosi se qualcosa si rompe non tempe tutto il resto :)

Stavo pensando a wine su linux a dire la verità...non considerando minimamente windows per lavorare mi riesce difficile pensare a uno scenario al contrario :D.

The_ouroboros
18-06-2020, 11:41
Stavo pensando a wine su linux a dire la verità...non considerando minimamente windows per lavorare mi riesce difficile pensare a uno scenario al contrario :D.

legit

Unrealizer
18-06-2020, 13:03
Giustamente il tuo punto di vista è quello di uno sviluppatore, dove ti fa comodo avere più cose possibili sotto mano, dal mio punto di vista, quello dell'analista numerico, vedo queste cose come uno spreco di risorse e una possibile fonte di instabilità...giustamente paese che vai usanza che trovi :).

Wine però è tutt'altra cosa, i container (sia Docker che WSL) servono proprio a isolare come dice Ouroboros :D

Ad esempio, su Windows ho 3 istanze WSL2 con Ubuntu 20.04 separate, una per il lavoro quotidiano, una per il lavoro freelance e una su cui sperimentare

Se rompo l'ambiente di una le altre si salvano (e posso comunque ripristinare uno snapshot).

Sia su Linux che Windows poi con Docker ho container diversi per i database dei vari servizi, e non devo nemmeno installare i tool di sviluppo per lavorare: ho dei container apposta, il che mi aiuta anche ad avere un ambiente riproducibile, così non devo impazzire/perdere una giornata nel caso cambiassi macchina o formattassi: clono il repo e faccio "docker-compose up". Le nuove feature di Visual Studio Code per lavorare direttamente con WSL o i container Docker sono una manna dal cielo, non devo nemmeno preoccuparmi di nulla, una volta configurato fa tutto lui (e la configurazione è la stessa per tutti).

Anche a casa, ho un raspberry con un controller Unifi (per il wifi), Pihole e un paio di altri servizi privati (bot telegram per gestire varie cose) ognuno nel proprio container, con delle cartelle montate per lo storage dei dati e della configurazione, a loro volta montate tramite SMB dal microserver che fa da NAS: se mi morisse il raspberry o si corrompesse l'SD non devo fare altro che prendere una micro SD nuova, flashare l'immagine che ho già pronta e ripartire: l'immagine rimonterebbe i volumi del microserver, tirerebbe giù le immagini docker e farebbe ripartire tutto come se non fosse successo nulla (in più c'è un altro raspberry pronto a partire manualmente con un comando nel caso servisse)

WarDuck
18-06-2020, 14:05
[..]

Windows comunque sta spingendo parecchio per i container su desktop, sono già usati in maniera trasparente da un po': le app dallo Store, sia UWP che Desktop Bridge sono dentro container Helium, Edge (entrambi) e Chromium usano container Argon, Application Guard su Edge, Windows Sandbox e WSL2 usano container Krypton e la stessa cosa viene usata per le applicazioni classiche su Windows 10X ("VAIL")

Dalla figura che hai linkato, sinceramente sono un po' preoccupato della piega che ha preso Windows.

Mi sembra che la complessità del sistema (che già è complesso di suo) stia aumentando a dismisura. Speriamo bene.

Dal mio punto di vista è chiaro che la virtualizzazione a container sia il presente ma soprattutto il futuro degli OS.

Fossi un ricercatore MS proverei a proporre un nuovo kernel che usi questo paradigma sin dalle sua fondamenta. Di fatto tutti pian piano stanno applicando patch a kernel esistenti per supportare sempre più isolamento. Considerare questa cosa sin dall'inizio invece secondo me darebbe garanzie superiori, specialmente dal punto di vista della sicurezza.

Unrealizer
18-06-2020, 15:50
Dalla figura che hai linkato, sinceramente sono un po' preoccupato della piega che ha preso Windows.

Mi sembra che la complessità del sistema (che già è complesso di suo) stia aumentando a dismisura. Speriamo bene.

Dal mio punto di vista è chiaro che la virtualizzazione a container sia il presente ma soprattutto il futuro degli OS.

Fossi un ricercatore MS proverei a proporre un nuovo kernel che usi questo paradigma sin dalle sua fondamenta. Di fatto tutti pian piano stanno applicando patch a kernel esistenti per supportare sempre più isolamento. Considerare questa cosa sin dall'inizio invece secondo me darebbe garanzie superiori, specialmente dal punto di vista della sicurezza.

Un nuovo kernel porterebbe più problemi che altro, anzi credo che il kernel sia quello più pronto a questa transizione, è la parte sopra a non vivere bene la cosa :D

IMHO è anche per questo che esiste(rà) 10X: le applicazioni moderne (UWP), che sanno usare il sistema di permessi, hanno un'identità e sono dentro container di default vengono installate "direttamente" (comunque dentro container Helium), tutto il resto va in VAIL, che praticamente è una Windows Sandbox persistente più integrata con il resto della shell.

WarDuck
18-06-2020, 16:11
Un nuovo kernel porterebbe più problemi che altro,


Intendo più che altro dal punto di vista di ricerca, è chiaro che la produzione è altra cosa.


anzi credo che il kernel sia quello più pronto a questa transizione, è la parte sopra a non vivere bene la cosa :D

IMHO è anche per questo che esiste(rà) 10X: le applicazioni moderne (UWP), che sanno usare il sistema di permessi, hanno un'identità e sono dentro container di default vengono installate "direttamente" (comunque dentro container Helium), tutto il resto va in VAIL, che praticamente è una Windows Sandbox persistente più integrata con il resto della shell.

Quello che dici è vero, tant'è che MS ha tirato fuori un nuovo modello di sviluppo delle applicazioni. Tecnicamente però, alcune di quelle novità si sarebbero potute applicare anche in modo retro-compatibile ad applicazioni Win32, nel caso dei permessi individuando ad esempio i gruppi di syscall usati per realizzare una certa funzionalità e intercettando a run-time i tentativi di accesso. Di fatto estendere quello che già oggi fa UAC con permessi più granulari.

Comunque l'ecosistema Windows di oggi è molto più complesso anche solo di qualche anno fa.

Unrealizer
18-06-2020, 19:07
Intendo più che altro dal punto di vista di ricerca, è chiaro che la produzione è altra cosa.



Quello che dici è vero, tant'è che MS ha tirato fuori un nuovo modello di sviluppo delle applicazioni. Tecnicamente però, alcune di quelle novità si sarebbero potute applicare anche in modo retro-compatibile ad applicazioni Win32, nel caso dei permessi individuando ad esempio i gruppi di syscall usati per realizzare una certa funzionalità e intercettando a run-time i tentativi di accesso. Di fatto estendere quello che già oggi fa UAC con permessi più granulari.

Comunque l'ecosistema Windows di oggi è molto più complesso anche solo di qualche anno fa.

Immagino che avranno vari kernel di ricerca internamente per queste cose, alla fine il primo WSL era nato da un progetto vicino a Midori (Drawbridge)

Alcune di quelle cose effettivamente sono usate anche in app win32 (tipo tutta la parte di identità e isolamento "leggero"), però immagino che fosse un enorme lavoro da fare in un layer rischioso da toccare così tanto a causa della retrocompatibilità. Così su due piedi IMHO ha senso che abbiano investito direttamente sul nuovo modello invece di forzarlo nel vecchio.

IMHO è stato meglio, immagina cosa sarebbe successo se qualunque applicazione avesse iniziato a spammarti di richieste di autorizzazione al primo riavvio dopo l'update a 10, dato che tutte le cose che fino a 30 minuti prima potevano fare tranquillamente adesso richiedono un OK dall'utente :D

Anzi non devi immaginarlo: basta pensare a cosa è successo con UAC ai tempi di Vista o pochi mesi fa con Catalina :sofico: