15 risposte a “Momenti storici: i driver ufficiali NVidia per Linux sono stati finalmente rilasciati in forma OpenSource”

1. 

   JustATiredMan

   18 Maggio 2022

   Mi pare di capire che ci sia ben poco di opensource, c’è scritto anche:
   “Note that the kernel modules built here must be used with gsp.bin firmware” In sostanza quello che c’è di open sono solo i layer per far parlare il kernel con il firmware che è il classico blob. Nouveau, potrebbe certamente beneficiarne se decidesse di far scegliere all’utente se usare il firmware binario originale di nvidia oppure no, ma nella sostanza non si otterrà molto più di quello che già ora permette il driver proprietario. Secondo me stà roba non è altro che una mossa di nvidia, per non dover dedicare e pagare risorse interne per mantenere i driver proprietari linux/bsd. In questo modo scaricano la rogna sulla comunità opensource, ci fanno bella figura, ma in realtà non danno nulla, perchè non c’è nulla da imparare su una serie di layer e api per far comunicare kernel e un binario… la vera ciccia è quel binario… è li che ci sarebbe qualcosa da imparare.

2. 

   M²

   18 Maggio 2022

   Sempre su YouTube Morrolinux precisa che hanno spostato il “blob” proprietario all’interno del firmware.
   Non cambia la sostanza di avere finalmente un supporto ufficiale, con tutti i benefici del caso

3. 

   Raoul Scarazzini

   18 Maggio 2022

   Questo è interessante e, come giustamente scrivi, assimila finalmente il driver a tanti altri che hanno la loro porzione closed all’interno del firmware. È sicuramente un passo in avanti enorme!

4. 

   JustATiredMan

   18 Maggio 2022

   io la vedo solo uno scarica barile. Non hanno bisogno di pagare qualcuno internamente, e lasciano il lavoro e i problemi, aggratis, agli altri.

5. 

   Raoul Scarazzini

   18 Maggio 2022

   Come rispondo sotto però di fatto questa mossa assimila il driver a tantissimi altri che funzionano con lo stesso principio, non è una cosa da poco, non per come erano partite le cose con NVidia…

6. 

   Raoul Scarazzini

   18 Maggio 2022

   Fosse quella la ragione lo avrebbero fatto *anni* fa

7. 

   amedeo lanza

   18 Maggio 2022

   refuso: retificando

8. 

   amedeo lanza

   18 Maggio 2022

   Significa che le schede nVidia fanno come i vecchi modem interni (economici) che caricavano il firmware dai driver ?

9. 

   JustATiredMan

   18 Maggio 2022

   Che sia una cosa che fanno tutti, ok. Purtroppo così val il mondo. In un ottica di risparmio, demandare il problema a chi lavora gratis, è sempre una buona cosa. Come è pure buono, nell’ottica di un utilizzatore finale a cui interessa solo che le cose funzionino bene.

   Nell’ottica open/free source, di chi piace studiare i sorgenti per imparare qualcosa di nuovo, magari relativamente alla gestione di hardware, non trovo ci sia nulla di particolarmente interessenta da imparare in questi sorgenti, come ovviamente in altri che rilasciano stì driver con un blob.

10. 

    JustATiredMan

    18 Maggio 2022

    mah sai… cose di questo genere hanno bisogno di maturare, magari qualche nuovo dirigente, o qualche pezzo grosso ha fatto qualche ragionamento ed è arrivato a capire che una roba rilasciata in questo modo, non mette a rischio niente di importante di nvidia dato che il blob non riesci facilmente a capire come funziona.

11. 

    JustATiredMan

    18 Maggio 2022

    Come linea di principio direi di si. La differenza stà nel fatto che i vecchi modem interni, demandavano completamente l’elaborazione del segnale alla cpu, mentre nel caso nvidia, i calcoli sono troppi. In ogni caso, c’è da supporre, e non sapendo come funziona il firmware, che ci sia una parte del lavoro svolto dal driver e quindi dalla cpu.

12. 

    Diogene di Sinope

    18 Maggio 2022

    chi sono “tanti altri” ? Intel e amd?

13. 

    Fedewiico

    22 Maggio 2022

    Ci sono due scenari da considerare: il primo è quello che scrivi tu, il secondo è quello di chi vuole che l’hardware funzioni bene, al massimo, su linux, come su windows, o mac.
    In tale situazione, auspico uno scenario:
    – driver ufficiale che fa uso del blob.
    – driver open che non lo usa (non avrebbe senso usarlo, sarebbe un doppione dell’ufficiale).
    Ciascuno è libero di scegliere quale dei due usare, immagino che l’impegno della comunity per il driver open andrà a calare, ma su questo si può fare ben poco, visto che la complessità dell’harware, specie su una scheda video, è sempre maggiore, e se si volesse fare qualcosa di serio servirebbe un hardware open, programmabile, ad esempio ipotizzo una scheda video con un FPGA a bordo al posto della GPU, però ho come la sensazione che il treno sia stato perso tempo fa, quando sono capitate due occasioni straordinarie, la prima concreta e la seconda no: parlo del processore Cell di Ps3 e del progetto Larrabee di Intel. Ho sperato di poter vedere un pc con un processore cell a bordo, la comunity linux avrebbe avuto un hardware dedicato al proprio sviluppo per creare uno scenario nuovo e unico, purtroppo non è successo, anzi, il supporto a Linux su Ps3 è stato anche deprecato a metà del ciclo vitale della console.

    https://it.wikipedia.org/wiki/Cell_(processore)
    https://it.wikipedia.org/wiki/Larrabee_(hardware)

14. 

    Fedewiico

    22 Maggio 2022

    Sinceramente ho sempre sperato che i driver dell’hardware, in generale, venissero integrati dal produttore su un firmware residente sull’hardware stesso. Il reverse engineering non porterà mai a fare meglio di chi chi progetta l’hardware e ovviamente lo conosce, è uno spreco di risorse, se perlomeno fossero pubbliche le specifiche magari sarebbe più semplice, ma comunque, fare meglio del produttore sarebbe incredibile e improbabile.

15. 

    Raoul Scarazzini

    24 Maggio 2022

    Guarda qui https://packages.debian.org/source/buster/firmware-nonfree e fatti un’idea, non sono *ovviamente* solo Intel e AMD…