Torvalds: 'Linux non è stato un fallimento su desktop. Lavorerò per conquistare il mercato'

[adapter]

Originariamente inviato da pabloski

Magari piazziamo un singolo sistema operativo, dai mainframe ai tostapane. Poi piazziamo un solo modello di auto, tanto le varianti creano solo confusione. E potrei continuare all'infinito.

Scelta e' evoluzione. E' il meccanismo grazie al quale siamo usciti dalle caverne. L'appiattimento non ha mai portato a nulla di buono.

E comunque non vedo il problema nell'avere questo o quel DE. E non capisco cosa intendi per incompatibilita' con le applicazioni, dato che posso far girare applicazioni KDE sotto Gnome, Xfce, i3, senza problemi.

Quoto!
Infatti le possibilità di scegliere diversi DE dovrebbero essere un punto di forza non certo uno svantaggio.
D'altronde, con windows 8 abbiamo assistito a una marea di commenti tipo: "ma perché non hanno messo la possibilità di scegliere con quale desktop avviare la macchina?"
Chi non voleva le piastrelle (tutti) avrebbe potuto scegliere un diverso DE.
Chi non vuole la attuale fui di windows 10, invece di installarsi il tool che elimina piastrelle, tile etc etc potrebbe scegliere un diverso DE prima del login.
Proprio quello che volendo è possibile fare, in modo intelligente direi, con Linux.

[PaulGuru]

Originariamente inviato da adapter

Quoto!
Infatti le possibilità di scegliere diversi DE dovrebbero essere un punto di forza non certo uno svantaggio.
D'altronde, con windows 8 abbiamo assistito a una marea di commenti tipo: "ma perché non hanno messo la possibilità di scegliere con quale desktop avviare la macchina?"
Chi non voleva le piastrelle (tutti) avrebbe potuto scegliere un diverso DE.
Chi non vuole la attuale fui di windows 10, invece di installarsi il tool che elimina piastrelle, tile etc etc potrebbe scegliere un diverso DE prima del login.
Proprio quello che volendo è possibile fare, in modo intelligente direi, con Linux.

Non se lo scopo è l'unificazione delle piattaforme

[andy45]

Originariamente inviato da PaulGuru

Non se lo scopo è l'unificazione delle piattaforme

Unificare le piattaforme non vuol dire necessariamente avere una sola interfaccia grafica, posso benissimo avere interfacce grafiche diverse su tablet, telefoni e computer, ma rendere il "cuore" dell'applicazione compatibile con tutti...le universal app di windows 10 alla fine sono così, l'interfaccia grafica su pc, tablet e telefoni non è necessariamente la stessa, sta allo sviluppatore farla, magari su pc e tablet è uguale, ma per gli schermi più piccoli dei telefoni non è detto sia la stessa, come non è detto che la universal app sia davvero universale, sta allo sviluppatore decidere se deve esserlo...l'applicazione di facebook per esempio è disponibile solo per pc e tablet, ma per i telefoni c'è ancora quella fatta dalla microsoft.
Unificare non vuol dire appiattire...che poi con windows 8 ci abbiano provato è un altro discorso, ma si è visto come ha risposto il mercato.

[pabloski]

Originariamente inviato da PaulGuru

Esattamente.

Quindi non dovrei installare Solidworks su Windows perche' richiede un gazillione di librerie non presenti nel sistema?

Se ti serve un'applicazione usi quell'applicazione. Se hai un'alternativa usi quella. Ma non venirmi a dire che ci sono incompatibilita'.

Fermo restando che moltissime applicazioni hanno il numero minore possibile di dipendenze verso un DE specifico. Al massimo avrai applicazioni GTK e QT, ma parliamo di 40-50 MB di dipendenze al massimo.

[cdimauro]

QT non occupa certo 40-50MB. Magari!

[cdimauro]

Originariamente inviato da Bellaz89

Apparte che supportare un SO non esclude gli altri.(E che portare i propri devices su architetture non X86 quasi sempre significa implicitamente supportare linux)

La convenienza si presenta solo se i guadagni derivanti dall' ampliamento del mercato coprono le spese d'investimento. E questo con Linux, anche solo nelle aziende legate alla LF, si ha per numerosissime classi di dispositivi. Il resto sono chiacchere.

L'alternativa e' lasciare che i competitors prosperino nei mercati in cui ti ritiri.

Questo è il motivo per cui vengono rilasciati driver in generale, e quindi non soltanto open.

A me(e al resto della comunita' linux) se danno delle specifiche esaustive dei loro nuovi chip e un driver general purpose va piu' che bene. Se vogliono tenere un driver closed per soddisfare le esigenze di qualche particolare cliente che lo facciano. Cosi' a naso NVIDIA ha paura che Intel e AMD, producendo driver open di qualita' di volta in volta maggiore, le rubino parte del mercato degli acceleratori grafici ad alte prestazioni per Linux, di cui e' il maggiore fornitore.

Che è quello che dicevo prima: vuole tenersi stretta le sue IP per non avvantaggiare la concorrenza. Scelta perfettamente legittima e sensata, considerato il portfolio di nVidia.

Poi non mi pare che abbia rilasciato la documentazione delle sue GPU. Sarebbe stato un evento storico, data la generale ritrosia dell'azienda, e riportato dai siti di informazione tecnologica.

Se ti riferisci al driver di VideoCore IV e' stato aperto piu' di due anni fa...

(https://en.wikipedia.org/wiki/VideoCore#Linux_support)

OK. Ma ci sono altri produttori di hardware che continuano a non rilasciare i sorgenti dei propri driver.

Peggio che peggio: un eventuale virus potrebbe infilare codice malevolo nel device. Questo codice potrebbe poi essere scaricato in ram ed eseguito all' avvio del computer dalla cpu prima del sistema operativo. Per farla breve questi casi sono un incubo per la sicurezza.

Anche il BIOS/UEFI è aggiornabile.

Dall' enciclopedia Treccani, voce 'mano' 1.i
(http://www.treccani.it/vocabolario/mano/)

Quindi 'far man bassa' e' equivalente a rubare. Io mi sono limitato al suo significato corrente che dal contesto mi pareva piu' appropriato.

Avevo già scritto agli inizi "mettere le mani", a cui di recente è seguito "far man bassa" in cui l'accezione saccheggiare si sposa perfettamente con la situazione. Il concetto è quello appropriarsi di qualcosa. Che prima era solo mio. Che non significa necessariamente rubare (difatti nelle accezioni viene riportata ANCHE, e non conseguentemente, la possibilità di essere inteso come tale).

Rubare continua a non essere un termine adatto, perché di un software ti fai una copia, ma non porti via l'originale, che rimane nella disponibilità del proprietario.

Falso. Per dimostrarmi il contrario dovresti postarmi una serie di sentenze giudiziarie (che e' l'unico mezzo che puo' costringere un'azienda a fare qualcosa) che obbligano l'azienda X a rilasciare il proprio codice, precedentemente closed-source, sotto GPL. Dubito che riuscirai a trovare qualcosa, perche' dal punto di vista giuridico non sta in piedi. Altrimenti parliamo di aria fritta.

Quindi posso usare codice GPL e rilasciare soltanto i binari?

Se rilasciare o meno la parte sviluppata closed source come open e' sempre e' solo una decisione dell' azienda. Ovviamente se un'azienda non vuole rilasciare niente deve togliere le parti GPL.

Appunto. Mentre con altre licenze questo non succede, proprio perché NON sono virali!

Nello stesso contesto, prova a sostituire codice GPL con BSD: sei costretto sì o no a rilasciare anche il resto del TUO codice, se rilasci soltanto i binari?

Il nocciolo della questione sta tutto qui, ed è questo il motivo per cui le licenze vengono classificate come virali o non.

Se l'ufficio licenze di Microsoft fa degli errori nel licensing non e' certo colpa della GPL.

Inoltre se tu avessi letto il link a pie' di pagina della fonte che tu stesso hai postato troveresti il rimando alla posizione ufficiale di Microsoft (https://blogs.technet.microsoft.com/...onent-drivers/)

La quale afferma:

Quindi, la posizione ufficiale di Microsoft afferma che non e' stata obbligata a fare un bel nulla e che ha scelto di usare la GPL solo per convenienza.

Questa è la posizione ufficiale di Microsoft DOPO che è successo il fatto descritto nel link che avevo riportato prima.

Nell'altro link che trovi alla fine di quel che hai riportato adesso, è la stessa Microsoft ad aver ammesso di aver rilasciato del codice non compatibile con la licenza GPL:

The driver had both open-source components which were under GPL, and statically linked to several binary parts. The GPL does not permit mixing of closed and open source parts, so this was an obvious violation of the license.


Ed è per questo motivo, quindi DOPO che erano stati rilasciati i binari e che gli era stato fatto notare tutto ciò, che Microsoft ha rilasciato anche il resto con licenza GPL.

La voce di wiki la pensa diversamente sul kernel Linux
https://it.wikipedia.org/wiki/La_cattedrale_e_il_bazaar

Conosco questa storia, ma nel kernel non ci finiscono tutte le patch. C'è anche lì un direttorio di alcuni elementi che vagliano le patch e decidono cosa entrerà nel kernel e cosa no.

[biometallo]

Originariamente inviato da Bellaz89

Se ti riferisci al driver di VideoCore IV e' stato aperto piu' di due anni fa...

(https://en.wikipedia.org/wiki/VideoCore#Linux_support)

Originariamente inviato da cdimauro

OK. Ma ci sono altri produttori di hardware che continuano a non rilasciare i sorgenti dei propri driver.

Mi permettono solo una piccola nota su questo punto, molti hanno criticato la scelta della Raspberry Pi foundation di continuare ad usare tale GPU anche sul secondo e terzo Raspberry Pi, in quanto ritenuta obsoleta, però mi pare che nessuno abbia tenuto conto che dal loro punto di vista è stata una scelta obbligata in quanto tra le alternative l'unica Open. (credo di aver letto la cosa, sul sito ufficiale all'uscita del Raspberry Pi 2)

Avevo poi già fatto notare che il mondo ARM è talmente aperto all'Open Source che lo stesso Linus di cui si parla di questa news aveva augurato a tutti i produttori di chip ARM di schiattare in modo dolorosissimo?

[cdimauro]

Originariamente inviato da biometallo

Mi permettono solo una piccola nota su questo punto, molti hanno criticato la scelta della Raspberry Pi foundation di continuare ad usare tale GPU anche sul secondo e terzo Raspberry Pi, in quanto ritenuta obsoleta, però mi pare che nessuno abbia tenuto conto che dal loro punto di vista è stata una scelta obbligata in quanto tra le alternative l'unica Open. (credo di aver letto la cosa, sul sito ufficiale all'uscita del Raspberry Pi 2)

Quando è uscito il primo Raspberry, però, i driver non erano affatto open. E non c'era nemmeno documentazione sul chipset.

Secondo il link riportato da Bellaz89, lo sono soltanto da un paio d'anni.

Avevo poi già fatto notare che il mondo ARM è talmente aperto all'Open Source che lo stesso Linus di cui si parla di questa news aveva augurato a tutti i produttori di chip ARM di schiattare in modo dolorosissimo?

Ne abbiamo già parlato anche qui, e ho riportato alcuni link in proposito.

[biometallo]

Originariamente inviato da cdimauro

Quando è uscito il primo Raspberry, però, i driver non erano affatto open. E non c'era nemmeno documentazione sul chipset.

Vero, anche se mi viene da ipotizzare ci fosse già stato qualche accordo a monte, tra l'altro ricordo anche vagamente un discorso sul fatto che la documentazione rilasciata non fosse quella specifica per il modello presente nel raspberry pi, ma che con un po' di lavoro è stata velocemente adattata. (dato però la mia ignoranza in materia chiedo venia se ho scritto una castroneria)

[andy45]

Originariamente inviato da cdimauro

Conosco questa storia, ma nel kernel non ci finiscono tutte le patch. C'è anche lì un direttorio di alcuni elementi che vagliano le patch e decidono cosa entrerà nel kernel e cosa no.

Parlo da ignorante in materia, però mi sembra una cosa ovvia che qualcuno decida cosa inserire e cosa no, se arrivano 10 patch che risolvono tutte lo stesso problema si sceglie la "migliore" e si va avanti...così come se ne arriva una sola, se la patch in questione risolve un problema, ma inserendola ne escono fuori altri 10 è una patch che non ha senso mettere su, un supervisore sta in qualsiasi progetto, non vedo perchè non debba stare anche nello sviluppo del kernel linux.

[zappy]

Originariamente inviato da adapter

Beh ma per vecchio parlo comunque di un core duo due.
Una via di mezzo come mate, personalmente va più che bene.

se xfce fosse una schifezza rispetto a mate, il tuo discorso filerebbe.
ma è esteticamente e funzionalmente molto simile, solo più veloce e leggero.

[zappy]

Originariamente inviato da PaulGuru

Si la puoi scegliere ma questo ti LIMITA dal punto di vista della compatibilità con gli applicativi !

non c'è praticamente nessun applicativo a cui sia interessato che non sia multipiattaforma.
sono anni che ormai mi sono orientato all'imparare ad usare roba OS-indipendent

[cdimauro]

Originariamente inviato da biometallo

Vero, anche se mi viene da ipotizzare ci fosse già stato qualche accordo a monte, tra l'altro ricordo anche vagamente un discorso sul fatto che la documentazione rilasciata non fosse quella specifica per il modello presente nel raspberry pi, ma che con un po' di lavoro è stata velocemente adattata. (dato però la mia ignoranza in materia chiedo venia se ho scritto una castroneria)

Francamente non ho proprio idea di quale fosse la situazione.

Originariamente inviato da andy45

Parlo da ignorante in materia, però mi sembra una cosa ovvia che qualcuno decida cosa inserire e cosa no, se arrivano 10 patch che risolvono tutte lo stesso problema si sceglie la "migliore" e si va avanti...così come se ne arriva una sola, se la patch in questione risolve un problema, ma inserendola ne escono fuori altri 10 è una patch che non ha senso mettere su, un supervisore sta in qualsiasi progetto, non vedo perchè non debba stare anche nello sviluppo del kernel linux.

Infatti le patch vengono vagliate per questo motivo. Ma in realtà non è che chiunque, anche un pinco pallino, si metta a scrivere patch, e poi i mantainer si passano il tempo a qual è la più interessante per risolvere un determinato problema o implementare una funzionalità.

Linux ha un suo nucleo ben consolidato di sviluppatori che lavorano in determinati settori. Con ovviamente contributi esterni (pochi), oltre a un certo ricambio (come capita in qualunque azienda: c'è gente che viene e va). Faccio presente che nel nucleo di sopra la maggior parte degli sviluppatori proviene da aziende. Questo per dire che i contributi realmente esterni (appassionati, ad esempio) sono decisamente pochi (ogni anno c'è una classifica che viene pubblicata, da cui si vede che l'apporto è irrisorio).

[pabloski]

Originariamente inviato da cdimauro

QT non occupa certo 40-50MB. Magari!

L'intero framework ovviamente no. Quel numero e' la media delle dipendenze qt che un'applicazione normale si porta dietro.

Da quando hanno modularizzato, la situazione e' migliorata notevolmente.

[cdimauro]

Originariamente inviato da pabloski

L'intero framework ovviamente no. Quel numero e' la media delle dipendenze qt che un'applicazione normale si porta dietro.

Da quando hanno modularizzato, la situazione e' migliorata notevolmente.

Quindi il mattone rimane per gli sviluppatori.

Originariamente inviato da Bellaz89

C'è da dire che la situazione di NVIDIA e' ancora di transizione. Il riassetto delle modalità di rilascio del software può impiegare anche anni. Però hanno affermato che supporteranno il progetto e questo fa ben sperare https://nouveau.freedesktop.org/wiki/FAQ/#index7h3

Letto. Finora non hanno rilasciato nulla che già non si sapesse.

In ogni caso NVIDIA dovrà farsi i suoi conti in tasca. Se perdere alcuni suoi clienti (molti, tra cui me) e tenersi strette le sue IP oppure allinearsi all'offerta dei concorrenti e tenere un'atteggiamento piu' open.

Dubito che aprirà il suo scrigno. Infatti finora è rimasta ferma addirittura al solo 2D.

Non conosco il livello di protezione di BIOS/UEFI. Non mi stupirebbe se ci fossero grandi problemi aperti anche in questo frangente, soprattutto alla luce della diffusione dell' IOT.

Il BIOS/UEFI lo aggiorni solo se hai abilitato l'opzione apposita (al suo interno) e con un tool della casa madre (o direttamente dal suo interno). Inoltre ci sarà sicuramente qualche checksum o firma per assicurarsi che non sia stato modificato.

Non so come funziona con l'IoT, ma credo che in quest'ultimo caso sia molto più semplice, per ovvi motivi.

A me sembra che 'appropriarsi di' sia un termine più vicino a rubare che a saccheggiare ma vabbè. Continua a rimanere il fatto che scrive codice GPL(me compreso) non 'saccheggia' niente a nessuno.

non è questo il punto. rileggi insieme le parti che mi hai quotato separatamente:

Che è una risposta all'affermazione che hai fatto che ha fatto partire la discussione sulle licenze:

Che è falso visto che la GPL non attenta o pretende di fare un bel nulla. Un'azienda anche se viola la GPL, di proposito o meno, non può essere costretta da nessuno, non da un giudice ne tantomeno dallo sviluppatore danneggiato, ad aprire la sua parte di codice closed.

Vedi sopra. Si tratta solo di rispettare le licenze. Se non ti sta bene scegli altro visto che un'azienda ne ha sempre la possibilità. Anche io vorrei gratis i sorgenti di LabView e Matlab, ma non dico che la loro licenza è il male assoluto se non me lo permette.

Rimetto tutto assieme, perché la problematica riguarda per l'appunto la licenza. E' vero che nessuno ti costringe a rilasciare il tuo codice, ma questo accade soltanto se decidi (a seguito di un'eventuale causa) di non usare più i pezzi di codice coperti da GPL.

Mettiamoci nel caso di uno sviluppatore che non voglia reinventarsi la ruota, ma che vuol usare un pezzo di codice già esistente per risolvere una certa problematica. Allora capita che:

- se è coperto da GPL (caso semplice: lo usa di sua volontà e in piena consapevolezza) e allora deve rilasciare anche il resto del suo codice come licenza;

- se è coperto da una licenza come la BSD, ad esempio, non è costretto a rilasciare il resto del suo codice.

Nel primo caso la licenza viene definita virale, nel secondo no.

Ribadisco: siamo nell'ipotesi che uno sviluppatore voglia USARE (e, dunque, mantenere) un pezzo di codice già esistente.

Infatti ho parlato nel mio post precedente di errori nel licensing da parte di microsoft (che quindi non sono imputabili alla GPL in se).

Beh, è proprio Microsoft che in quella pagina parla proprio di violazione della GPL. Che poi è quello che è avvenuto.

In ogni caso aprire la parte closed è stata solo una scelta di microsoft. Se non voleva aprire i suoi moduli poteva ritirare la distribuzione del pacchetto in toto oppure riscrivere un modulo completamente closed. Però probabilmente, visto che voleva avere il suo codice nel ramo principale del kernel ha deciso piuttosto di aprite i suoi moduli e licenziarli GPL. Ma come si legge dalle fonti non è stata costretta da nessuno e anzi la faccenda si è risolta molto pacatamente.

Certamente, perché alla fine le è convenuto così.

Inoltre dubito fortemente che la questione sarebbe andata in tribunale visto che il problema riguarda solo codice suo(doveva citare se stessa in giudizio ?!). Molto più probabilmente l'unico risultato sarebbe stata la rimozione del codice mal licenziato dal ramo principale del kernel.

Nel momento in cui è stata sollevata la violazione della GPL, se Microsoft non si fosse decisa a rilasciare la parte closed, allora chiunque, anche tu, avrebbe potuto pretendere il rispetto della licenza GPL.

Però questo non significa avere uno sviluppo a cattedrale (che vuol dire sviluppo in-house). Lo sviluppo rimane comunque collaborativo e le mailing lists dove vengono prese le decisioni sono pubbliche.

Cambia qualcosa con lo sviluppo collaborativo fra i vari team e le mailing list (interne) di aziende che sviluppano propri s.o.?

Originariamente inviato da Bellaz89

Opinione mia. Il problema è che VideoCore è una GPU (ovviamente) integrata nel SoC Broadcom, e che quindi non può essere scelta indipendentemente dal resto del sistema. Quindi se Broadcom decide di usare questa GPU nei suoi chip ci puoi fare poco. Probabilmente la RasPi foundation ha voluto continuare a servirsi di chip Broadcom per una questione di compatibilità e riutilizzo del know-how acquisito nella prima piattaforma.

Esattamente. Infatti ha potenziato il lato CPU, ma ha mantenuto la GPU in modo da ridurre le problematiche dovute all'utilizzo di un SoC diverso.

EDIT OFF TOPIC: amici miei mi hanno dato questo link https://github.com/christinaa/LLVM-VideoCore4 al repo di un backend di LLVM per la vpu del chip broadcom in questione, il quale e' apparso da circa 24 ore. In soldoni e' il codice per costruire un compilatore in grado di produrre un firmware per il chip broadcom che ancora era chiuso. Questo fa si che in futuro Raspberry potrebbe diventare un chip 100% open source firmware compresi.

Ho letto il readme, ma non mi pare che arrivi da Broadcom. Anche nelle liste dei contributori e dei proprietari, non c'è nessuno che ci lavori.

[pabloski]

Originariamente inviato da cdimauro

Quindi il mattone rimane per gli sviluppatori.

Assolutamente. Considera che contiene esempi, tutorial, contenuti multimediali, ecc...

L'installer pero' consente di scegliere quali componenti installare, il che ha ridotto il tempo necessario al download.

Ma del resto .NET quanto pesa? Non mi pare sia un peso piuma.

[cdimauro]

Originariamente inviato da pabloski

Assolutamente. Considera che contiene esempi, tutorial, contenuti multimediali, ecc...

L'installer pero' consente di scegliere quali componenti installare, il che ha ridotto il tempo necessario al download.

Ma del resto .NET quanto pesa? Non mi pare sia un peso piuma.

Non lo so, però l'ultima volta che ho provato Qt un po' di anni fa le sole DLL erano più mezzo GB.

Originariamente inviato da Bellaz89

NVIDIA non sbandiera tantissimo il suo supporto al progetto. Ma qualcosa ha fatto:

Supporto a Tegra K1

http://www.phoronix.com/scan.php?pag...ouveau-Comment


Tanto che l' 'acido' Linus si è pure complimentato
https://plus.google.com/+LinusTorval...ts/TQDXxxr6ixm

Ha rilasciato un po di documentazione su Maxwell, Kepler e Fermi

http://www.phoronix.com/scan.php?pag...ocs-Tex-Header

NVIDIA inoltre lo scorso Ottobre al LinuxCon ha affermato che ci saranno novità sul fronte open source drivers

http://www.phoronix.com/scan.php?pag...-LinuxCon-Euro

(questi probabilmente non sono gli unici articoli a riguardo. Non mi andava di scartabellare tutto Phoronix.com)

Certo, sicuramente NVIDIA non è il contributor più celere e affidabile che si sia mai visto. Però la situazione è enormemente meglio di quella pre-2013 e il trend deciso da NVIDIA stessa è quello di una maggiore apertura.

Ho letto tutti i link, e al momento s'è focalizzata sul DRM (per ovvi motivi ) e il formato delle texture. Non è molto, ma specialmente quest'ultimo è un buon passo avanti.

Neanche io ne so tantissimo. Leggo però ogni tanto di problematiche relative alla sicurezza hardware.

E' software, e si può pure aggiornare, per cui è normale che ci possano essere problemi di sicurezza.

La licenza GPL parla di distribuzione. Se smetti di distribuire il pacchetto incriminato il fatto non sussiste più (e mi pare che questa sia stata la mossa iniziale di Microsoft, fatta probabilmente in via precauzionale) e questo anche senza rilasciare la parte closed.

Sì, volevo soltanto dire che se Microsoft non avesse rilasciato nulla dopo che è venuta fuori quella storia, avrebbe potuto essere trascinata in tribunale.

Ovviamente visto che le interessava migliorare il supporto al suo hypervisor su Linux, ha preferito rilasciare tutto.

Cambia principalmente per due cose IMHO.

La prima è che lo sviluppo è guidato dalle esigenze commerciali di una particolare azienda. Tale esigenza a volte può prevalere sul puro aspetto tecnico dei problemi da affrontare.

Questo è sicuramente vero.

La seconda è che agli utenti finali generalmente il prodotto viene presentato alla fine così com'è senza avere un feedback continuato durante lo sviluppo.

Beh, questo capita anche coi s.o. chiusi/a pagamento. Windows 10 è ampiamente e proficuamente basato su proprio sull'enorme feedback degli utenti (insider, in particolare).

Sisi. Tutto questo è stato frutto di reverse engineering abbastanza violento da parte dei 'patiti del firmware aperto' precedentemente citati. Broadcom non ci incastra niente. In questo caso avere un firmware open potrebbe essere utile a raspberry PI per permettere l'etherboot o il boot via usb senza passare dall'SD.

Si saranno fatti un gran mazzo per arrivare a quel punto. Ma visto quant'è diffuso il Raspberry, direi che il gioco ne è valsa la candela.