Link alla notizia: http://www.hwfiles.it/news/la-nsa-chiese-a-linus-torvalds-di-inserire-una-backdoor-su-linux-gnu_49793.html

Nel tentativo di intercettare gli utenti e le società facenti uso di Linux, l'NSA aveva chiesto in passato anche al suo fondatore l'installazione di backdoor nel kernel del sistema operativo open-source

Click sul link per visualizzare la notizia.

Come detto, nel kernel è molto difficile inserirne perchè non passerebbero inosservati. Gli sviluppatori non sono pochi e per di più ci capiscono benissimo.
Il caso Ubuntu è diverso perchè lo spyware che hanno inserito è legato ad Unity con l'inclusione di risultati online di una ricerca effettuata dalla dash e la registrazione delle attività dell'utente da parte del sistema, i cui dati sono probabilmente utilizzati per visualizzare offerte di amazon.
In più occorre dire, per onestà, che tali strumenti possono essere disattivati dalle opzioni della privacy offerte dal sistema base, cioè senza ricorrere a software aggiuntivo.

E' più difficile su Android, ma solo e soltanto per una ragione di garanzia dei dispositivi. La pubblicità invasiva può essere facilmente rimossa utilizzando un ad blocker, ma occorrono i permessi di root che sono ottenibili sbloccando il bootloader, ma su molti devices questo comporta la perdita della garanzia.
Idem per quanto riguarda la sostituzione di una rom o del kernel.

Nei sistemi chiusi, a pagamento o meno, è molto più facile inserire codice "extra" perchè non è possibile vedere cosa c'è nel "cofano", essendo il sorgente di proprietà privata e quindi non disponibile al pubblico.

Come detto, nel kernel è molto difficile inserirne perchè non passerebbero inosservati. Gli sviluppatori non sono pochi e per di più ci capiscono benissimo.

Teoricamente è così, in pratica quanto ci vorrebbe ad inserirlo solo nel binario del kernel precompilato e distribuito con la distro?

Certo, se non lo inserisci nei sorgenti, chi si ricompila il kernel sarebbe al sicuro, ma sono ancora così tanti coloro che lo fanno?

Si potrebbe fare un controllo tramite hashcode?

Perdonami la franchezza, e come fai? Ovvio che no. Mica hai un unico sistema compilato ed unico sorgente come per esempio può essere Windows.

@nickmot
Verrebbe comunque fuori facilmente.
Dal momento che i sorgenti sono disponibili, ci vuol poco a ricompilarli nello stesso modo e notare che il risultato è differente.
E non pensare che non ci sia nessuno che lo faccia! ;)

Era proprio una domanda la mia :)

Pensavo che il kernel comunque fosse 1 solo, con 1 solo sorgente.

Purtroppo no.
Se non dico boiate anche se tu:
1) Usassi lo stesso identico sorgente di coloro che hanno creato il binario originale.
2) Usassi esattamente lo stesso compilatore e le stesse librerie.
2) Usassi esattamente gli stessi settings di compilazione (sia del compilatore sia per quanto riguarda i moduli da includere)

Otterresti un binario con un Hashcode diverso, anche se il kernel sarebbe del tutto identico.

@nickmot
Verrebbe comunque fuori facilmente.
Dal momento che i sorgenti sono disponibili, ci vuol poco a ricompilarli nello stesso modo e notare che il risultato è differente.
E non pensare che non ci sia nessuno che lo faccia! ;)
Infatti ho detto teoricamente, poi leggi sopra.
Non ho provato però, vedo quello che capita facendo un compare binario su file compilati in momenti diversi pur lasciando il resto invariato, dovrebbe essere a causa del timestamp.

bella faccia tosta da parte dell'nsa, visto che la risposta era scontata... almeno spero

@Hal2001:

se scarichi il pacchetto deb-src (con i sorgenti) e lo compili con le opzioni di default (e con il compilatore di default) ottieni esattamente lo stesso binario presente sul pacchetto deb. A quel punto puoi realmente confrontare gli hashcode dei due kernel.

... a meno che non ci sia un "timestamp" o un numero di build progressivo da qualche parte. Ma a quel punto un diff binario sarebbe sufficiente per isolare l'eventuale discrepanza. Se cambiano solo pochi byte (ad esempio un timestamp) sei a cavallo.

bella faccia tosta da parte dell'nsa, visto che la risposta era scontata... almeno spero

Spero che la risposta sia stata la stessa data a Nvidia (quella nella foto). :Prrr:

Spero che la risposta sia stata la stessa data a Nvidia (quella nella foto). :Prrr:

ma quello nela foto piccola sarebbe l'europarlamentare? ... andiamo bene

al Parlmanento Europeo

non serve chiedere a torvalds, basta pagare un'azienda che obbliga a usare driver closed... tipo nvidia. Ora tutti capiranno la battaglia contro i driver closed su linux

Però scusa un secondo, se il kernel lo distribuisse qualcuno di fidato si potrebbe poi fare l'hash su tutti i kernel.

Mi spiego meglio: se linux foundation o chi altri distribuisce il kernel con un determinato hash poi si potrebbero verificare tutte le distro.
No vero? Perché il kernel potrebbe essere ricompilato da chi ha rilasciato la distro.Infatti i kernel vengono regolarmente ricompilati da fondazioni/società che rilasciano le distribuzioni.
Le patch di Redhat sono un esempio eclatante (e storico, negli anni hanno contribuito in modo sostanziale a migliorare il kernel stesso) di questo processo.
Ma non solo, il kernel è solo una parte del sistema, eventuali backdoors potrebbero essere inserite in qualche modulo lasciando il kernel del tutto intonso.

Il problema però è un altro e imho non è prettamente di natura tecnica, ricompilare un kernel è possibilissimo e fino a una decina di anni fa era la prassi, oggi è una cosa di nicchia estrema che la gran parte dei sistemisti non sa fare, per quanto possa sembrare assurdo questa è la realtà.
A prescindere poi dalla capacità individuale dei tecnici in molti casi non è proprio possibile farlo per poter garantire la riproducibilità dei sistemi, oppure per aderenza a determinate specifiche.

Un esempio banale, prendete una RedHat e ci installate Oracle Enterprise, pagate i vostri 50k euro tra licenza e supporto, personalizzate il kernel e al primo problema e invio dei dettagli vi ritrovate il ticket chiuso come non valido perchè l'OS non rispetta le specifiche, non mi sembra molto vantaggioso...

Quello che voglio dire è che sulla carta tutto si può fare, nella realtà però ci sono dei vincoli da rispettare che spesso sono bloccanti.

ma quello nela foto piccola sarebbe l'europarlamentare? ... andiamo bene
No, è Linus quando, in un'aula universitaria piena, manda a quel paese nvidia.

Ho la vaga sensazione che la risposta di Linus Torvalds sia stata: "Andatevene a quel paese" o una cosa del genere :D

mi ricordo che quando parlai di implicazioni della NSA con backdoor nel kernel linux tutti subito a dire "eh te lo ha detto tuo cuggggino :asd:" "si come no" etc. dove siete? siete ancora così convinti che sia impossibile? (no perchè a questo punto è probabile)

E sono convinto che sia ancora (praticamente) impossibile. La tua tesi qual' è?

anch'io, nella mia ignoranza, sono convinto che sia una cosa poco probabile :)

Vi ripeto, su Linux esistono tutti gli strumenti e le procedure affichè una cosa del genere non accada ma...

http://it.wikinews.org/wiki/Scoperta_prevedibilit%C3%A0_nel_generatore_di_numeri_casuali_della_versione_Debian_di_OpenSSL

Vi ricordate questo?
Fu il mantainer del del pacchetto a commentare le righe di codice incriminate, seppur fuorviato da tool di analisi del codice automatici e questo bug è rimasto in giro per ben 2 anni.

Quindi è possibile farlo, e l'unico punto dove lo vedo fattibile è in fase di distribuzione del binario (come per OpenSSL), i controlli funzionano, ma possono essere tardivi o qualcosa potrebbe sempre sfuggire.

Posto che tutto è possibile in campi come questo, penso sia veramente improbabile che un inserimento di una backdoor nel kernel (a qualunque stadio nello sviluppo) possa rimanere nascosto, sia che si tratti di sorgente, sia che si tratti di un binario distribuito, perchè:

1) Ovviamente dipende dalla distribuzione, ma il modello di sviluppo orizzontale e molto spesso volontario di alcune delle più importanti (eg Debian) fa si che difficilmente si possa inserire codice malevolo anche a livello binario.

2) Alla fine, chi sviluppa codice sul kernel si trova, bene o male a utilizzare il lavoro altrui (chi sviluppa il kernel usa solitamente una distro, chi sviluppa patch per una distro si trova a leggere il codice del kernel ufficiale). Fatto sta che un controllo incrociato così forte rende veramente difficile i tentativi di corruzione. ( e un numero cospicuo di questa gente rifiuterebbe anche mazzette milionarie piuttosto che infilare codice della NSA nel kernel).


A me invece pare possibilissimo inserire un piccolo bug ad arte. Prima che venga scoperto possono passare mesi. Anche perchè altrimenti non esisterebbero mai bug di nessun tipo e invece esistono e a volte vengono scoperti dopo anni.

Poi una volta che il bug è stato scoperto basta dire che ci si è sbagliati, il bug è involontario ed è tutto a posto.

Basta qualcosa di estremamente sottile, un più anzichè un meno in una complessa formula di crittografia tanto per indebolire l'algoritmo.

D'altra parte si vociferava di spyware inseriti in ubuntu, quindi....

"Vociferava" ?, no è assolutamente certo:

http://www.lffl.org/2013/10/ubuntu-lens-shopping-privacy-big-brother-award-austria.html

Posto che tutto è possibile in campi come questo, penso sia veramente improbabile che un inserimento di una backdoor nel kernel (a qualunque stadio nello sviluppo) possa rimanere nascosto, sia che si tratti di sorgente, sia che si tratti di un binario distribuito, perchè:

1) Ovviamente dipende dalla distribuzione, ma il modello di sviluppo orizzontale e molto spesso volontario di alcune delle più importanti (eg Debian) fa si che difficilmente si possa inserire codice malevolo anche a livello binario.

2) Alla fine, chi sviluppa codice sul kernel si trova, bene o male a utilizzare il lavoro altrui (chi sviluppa il kernel usa solitamente una distro, chi sviluppa patch per una distro si trova a leggere il codice del kernel ufficiale). Fatto sta che un controllo incrociato così forte rende veramente difficile i tentativi di corruzione. ( e un numero cospicuo di questa gente rifiuterebbe anche mazzette milionarie piuttosto che infilare codice della NSA nel kernel).

Poi come ho detto, tutto è possibile ed è sempre bene stare in guardia, però arrivare a ricompilare il kernel o fare hashing sullo stesso per questioni di sicurezza mi pare un po paranoico se il modello di sviluppo del software che si utilizza è convincente.

Tipo?

Si può ricavare benissimo il comportamento e scoprire falle/backdoor BENISSIMO senza avere accesso ai sorgenti.

E' più difficile certo, ma non impossibile come qualcuno vuole far credere.

Dopodiché non l'ha prescritto il dottore che le backdoor debbano stare per forza dentro il kernel...

Linux e l'open source ci hanno forse salvato da quanto hanno fatto NSA, Google e co.? No.

Ad oggi chi ha accesso alle versioni custom Android delle singole case, tipo Samsung?

è disattivabile ed è un sistema di ricerca online..senza nulla togliere alla
gravità della cosa, penso che uno spyware sia una cosa un pò diversa :)

:O E invece lo è eccome:

http://refugeeks.com/ubuntu-spyware-is-it-true/

Se poi sia pericoloso o no, è da decidere: Io, sto con Stallman :D

ripeto per la terza volta: tutto è possibile, la sicurezza al 100% non esiste, ma mentre su certi sistemi si può 'al limite' ricorrere ad espedienti per inserire vulnerabilità che forse funzionano e non vengono trovate dalla comunità, in altri possono essere comodamente implementati interi moduli di controllo\spionaggio\raccolta dati dalla casa produttrice facendo in modo che siano pure difficilmente rilevabili dagli utenti.

Questa è la mia opinione. Poi boh, la finisco qui. L'ultima cosa che voglio è far partire un flame.

(cmq, il mio discorso è incentrato su linux ma sarebbe più corretto parlare di software che hanno un certo modello di sviluppo. Per esempio mi fido molto di più di (Net/Open/Free)BSD che di android).

Tutti che pensano al software...ma all'hardware chi ci pensa? :rolleyes:

Le versioni android su cui girano versioni custom le considero alla stessa stregua dei prodotti closed (e per l'appunto il loro modello di sviluppo non è assolutamente orizzontale e android stesso è rigettato dalla FSF et similia; alla luce dei fatti chiamali stupidi, e pensare quanta gente li ha presi per il culo per aver tenuto a cuore questo genere di problemi in tempi non sospetti).Verissimo, così come la FSF praticamente rigetta praticamente ogni distribuzione GNU/Linux tranne una manciata (sconosciute ai più), la stessa Debian non è più ritenuta da tempo una distribuzione pienamente aderente ai principi della FSF.

Vi ripeto, su Linux esistono tutti gli strumenti e le procedure affichè una cosa del genere non accada ma...

http://it.wikinews.org/wiki/Scoperta_prevedibilit%C3%A0_nel_generatore_di_numeri_casuali_della_versione_Debian_di_OpenSSL

Vi ricordate questo?
Fu il mantainer del del pacchetto a commentare le righe di codice incriminate, seppur fuorviato da tool di analisi del codice automatici e questo bug è rimasto in giro per ben 2 anni.

Quindi è possibile farlo, e l'unico punto dove lo vedo fattibile è in fase di distribuzione del binario (come per OpenSSL), i controlli funzionano, ma possono essere tardivi o qualcosa potrebbe sempre sfuggire.

a quei tempi usavo debian, ricordo molto bene, un manteiner cancellò due righe di codice rendendo vulnerabili tutte le chiavi SSH e per due anni nessuno se n'è accorto nonostante fosse un problema colossale

la NSA potrebbe corrompere un manteiner per inserire volutamente un errore del genere e non è affatto detto che verrebbe scoperto subito

mi sembra che alcuni danno troppo per scontato che siccome il codice è disponibile allora c'è sempre qualcun'altro che lo controlla il che è una falsa sicurezza, puoi essere sicuro al 100% solo se leggi il codice e lo compili altrimenti è solo una questione di fiducia in persone che spesso sono dei volontari sconociuti

Per aggiungere uno spyware / malware nel Kernel di Linux io vedo 3 vie:


Contribuire al Kernel con un bug che non viene notato, ma che in realtà NON è un bug, ma... qualcos'altro (per esempio sotto, sotto fa un bel buffer overflow che permette di chiamare il VERO codice. Il C è insicuro by design basta una printf() su una stringa non tappata per fare le peggio cose!)
Un driver proprietario, che essendo Linux monolitico è un pezzo di Kernel a tutti gli effetti, e credo (di questo non so sicuro) che possa sbordare allegramente sul kernel stesso sovrascrivendo funzioni a destra e a manca
Questo che è il più cattivo di tutti e, se ricordo bene, è una storiella / confessione di Kernigan e/o Ritchie: scrivere un compilatore C che quando vede certe istruzioni le compila in modo "malevolo" (l'esempio era l'istruzione "login" della bash che invia una mail ai due furbacchioni con un utente e password e poi fa il login come se nulla fosse :p ) a quel punto che fai? Direte ebbene GCC è open source quindi li sgamo subito... ma che accade se compilo il "vero" GCC con il GCC degli inferi? E poi ricompilo il GCC "vero" con se stesso? Tu crederai di chiamare "login" ed anche un debugger crederà di farlo... strace NON ti mostrerà la verità, perché quella E` LA VERITA`! Per quello che ne sappiamo noi GCC potrebbe essere vulnerabile a questa c@zzata dalla versione 1.0, e poco importa se ora siamo alla versione 4... fu sempre compilato inizialmente con la versione Infernale e quindi... altro che NSA!
Kernighan & Ritchie ci spiano e ridono del nostro codice m€rdoso... dagli anni '60 :cry:

E sono convinto che sia ancora (praticamente) impossibile. La tua tesi qual' è?

ah certo perchè la tua convinzione è una tesi... :asd: Ho parlato di probabilità, supposizioni, ma mi sembra che anche tu non possa non possa fare altrimenti pur essendo il tutto "praticamente impossibile"

http://punto-informatico.it/3937484/PI/News/backdoor-linux-si-nasconde.aspx

Vi serve o un correttore di bozze o qualcuno che sappia scrivere un pochino meglio...

Linus torvalds ha scritto solo il kernel cioè solo 1% del sistema operativo gnu/linux non capisco perché viene chiamato il padre di gnu/linux ; allora e padre anche di android dato che usa lo stesso kernel linux.. no?
E grazie al progetto gnu che esiste il sistema operativo gnu/linux attualmente il 30% dell sistema ... al massimo il padre di gnu/linux e richard stallman senza di lui non esisterebbe nessuna distro gnu/linux , come ubuntu fedora redhat debian ecc...

Sei partito anche tu da una cellula....

E' una lunga querelle è Linux o Gnu/Linux?

Bisogna essere onesti GNU era un insieme di comandi raffazzonati alla bell'e meglio senza runtime su cui girare: bisognava scrivere il kernel... e lì si sono arenati non perchè non lo sapevano fare, ma si sono incasinati con la "bellezza": monolitico, ibrido, micro? HURD? Non HURD? Zuccabù o non zuccabubù?

Poi arriva sto giovanotto (Linus Torwarld) e durante le Feste di Natale scrive un'opera titanica, un kernel: lo scrive male, malissimo monolitico, senza error checking e solo per 8086 (NON portabile) e "ruba" quei 4 comandi per fare una shell per il suo sistema operativo giocattolo ;)

Immaginatevi lo scazzo dei professoroni quando vedono che quel kernel funzionicchia ed esegue il loro GNU... HURD? Ehh arriva l'anno prossimo (lo diceva anche Linus nel famoso post "This is Linux").

Ora, passati 30 anni, il ragazzotto è diventato un vecchiaccio i professori sono vecchiaccissimi HURD deve uscire l'anno prossimo (ma se tutti gli anni dicono l'anno prossimo :confused: ), anche IBM, HP, Microsoft, (sì Hotmail gira su Linux non su Windows) Sun / Oracle e Google si son rassegnati ad usare quel SO che si chiama Linux... va su tutto dai Megaserver con architettura Power passando per i PC X86 fino ai Telefonini ARM... ne hanno riscritto il 90% certo, ma il concetto rimane: se Linus non lo avesse fatto NON sarebbe mai esistito, se NON c'era GNU?
Il ragazzetto di cui sopra avrebbe usato altro o si sarebbe scritto tutto quanto :Prrr:

Quindi è LINUX!

P.S. Ma l'anno prossimo HURD esce davvero?

Snip

Quindi è LINUX!

P.S. Ma l'anno prossimo HURD esce davvero?Dimentichi di citare il resto dell'immenso lavoro del progetto GNU, il GCC (senza il quale l'opera si Linus non esisterebbe), o tutte le GNU utils senza le quali il kernel sarebbe unicamente un esercizio di sviluppo...
Hai citato giusto l'unico progetto fallimentare del progetto GNU, un po' fazioso, non credi?

Senza contare l'indispensabile apporto culturale, etico e metodologico di Stallman e della FSF, senza il quale il concetto stesso di software libero non esisterebbe.
Ricordiamoci che "open source" non è altro che un brand creato a tavolino da 4 giornalisti perché "free" suonava male alle aziende...

Senza contare la GPL, non fosse per RMS ora saremmo invischiati nei copyright molto peggio di come siamo ora.

Insomma diamo a Cesare quel che è di Cesare...

Da notare che sulla carta HURD è meglio del Kernel Linux 1000 volte meglio!

E' un microkernel e la maggior parte di ciò che in Linux è nel Kernel gira in userspace (filestem, autorizzazione utenti, network, ...), però ed è un grosso ENORME però è, praticamente, solo sulla carta... ormai sono passati 20 anni, meglio Linux che non è "bello" da guardare però funzionichhia, no?

Belin sto difendendo Linux :p

Lo stesso ragionamento di Stallman lo stanno facendo i ragazzi che stanno cercando di riscrivere Be OS (Haiku): non ci sono scadenze, Haiku sarà pronto, quando sarà pronto! ... quindi Haiku è alla III alpha dopo 12 anni... non raggiungerà mai la beta e MAI la produzione di sto passo... anche perché i developer stanno iniziando ad abbandonarlo. Haiku è, purtroppo, morto!

Linus ha rilasciato 2 alpha, 1 beta e ha dichiarato il prodotto "pronto per la produzione", non era vero? Certo che no... avrà distrutto pure qualche HDD poi IBM, Sun, Oracle, Intel... ci hanno messo mano e lo hanno aggiustato.

Stallman, benché possa aver ragione a volte esagera non c'è nulla di male se NVIDIA vuole scrivere un driver per Linux e non vuole rilasciare i sorgenti... se il driver va come su Windows per l'utente finale che differenza, fa? Vi sentite in colpa perché il Kernel è sporco? Un'azienda ha diritto anche di difendere la sua IP, dai...

Stallman, benché possa aver ragione a volte esagera non c'è nulla di male se NVIDIA vuole scrivere un driver per Linux e non vuole rilasciare i sorgenti... se il driver va come su Windows per l'utente finale che differenza, fa? Vi sentite in colpa perché il Kernel è sporco? Un'azienda ha diritto anche di difendere la sua IP, dai...E' proprio qui il punto, RMS contesta il concetto stesso di proprietà intellettuale, quantomeno applicato a un software (a tal proposito la sua biografia spiega piuttosto bene i tre ambiti in cui secondo lui si applica questo concetto).

Più in generale quello che tu hai evidenziato ("per l'utente finale che differenza, fa?") è un fattore storico che differenzia il movimento del software libero derivato da RMS e dalla prima generazione di veri hacker dalla generazione successiva nata in seno all'opera di Torvalds (o per la quale l'opera di Linus ha rappresentato un punto focale).

Mentre i primi si concentravano molto più sugli aspetti etici e sui principi fondamentali fregandosene dell'aspetto utilitaristico (un software non rispetta i principi che ritengo giusti? Non lo uso, anche se fosse il software più avanzato, utile e meglio scritto del pianeta), i secondi invece sono sempre stati più legati a questi ultimi e più propensi a compromessi rischiosi.

E' un problema che imho si pone anche oggi, e in modo ancora più grave con i servizi dei cosiddetti "big data" o con i servizi pseudo-free (social networking e similari), parafrasando il motto della FSF verrebbe da definirli “free” as in “free beer”, not as in “free speech”.. :rolleyes:
Passare sopra agli evidenti problemi di privacy, proprietà dei dati, licenze, copyright solo perchè "è utile" è un fatto grave, ancora più grave il fatto che questa cosa passi inosservata sotto gli occhi del 99,9999% degli utenti che usano questi servizi.
Non è un caso che gran parte dell'opera della FSF (e del movimento del software libero in generale) è appunto informativo, per permettere agli utenti di capire meglio le conseguenze di un determinato comportamento, poi se uno ne è cosciente e decide lo stesso di seguire quella strada è libero di farlo. :O

OK questa è quasi "politica", dai!

Io sono un programmatore professionista su Linux (ebbene sì :p ) e certo uso i prodotti GNU compilo con GCC e quindi linko tutta la libc e son grato che lorsignori abbiano voluto regalarmela, MA io con il software ci mangio, mi spiace, ma non ve lo regalo... capisco, quindi, nel mio piccolo il ragionamento di Nvidia! Perché devo dare gratis la mia proprietà intellettuale? Se voglio farlo son libero, certo, ma se non voglio? Sono malvagio? Pazienza :Prrr:

Anche Linus comunque tanto amichevole con il software proprietario non è! Ricordate questa immagine?

http://www.tuxjournal.net/wp-content/uploads/2013/09/linus-eff-you.png

... pensate che NVIDIA che, in un modo o nell'altro GRATIS (con birra o senza) stava fornendo i driver facendosi un mazzo incredibile fosse contenta del ditino? (Si ho letto ha patchato roba Open Source fatta da altri e quindi? E' male? Perchè? A me pare irreprensibile... cosa cambia? Non ti do il mio IP, ma ti do un suggerimento? Fantastico!)

Tu hai mai provato a scrivere un driver per Linux?

Io (insieme ad un mio collega) sì ed è stata un'esperenzia traumatica... meno male che il produttore impietosito ci ha praticamente dettato il codice! E' pure un device relativamente semplice: una sorta di memoria condivisa che permette di comunicare in modo veloce tra il sistema Linux e il sottosistema VxWorks (sì 2 PC insieme nello stesso chassis :Prrr: ), dal punto di vista di Linux apparirà con un pseudo-file in /dev...

Poi passati 2 anni abbiamo cambiato hardware (ma non quella schedina) e siamo passati da White Box 4 a Cent OS 5.4... il driver non andava più e ci può stare (saremo passati da kernel 2.4 a 2.6), ma perchè anche dopo la ricompilazione continua a non andare? Perchè una callback del kernel prendeva 2 parametri e ora ne prende 3? E perché il III parametro DEVE essere sempre NULL? Perchè questa altra, invece, ha perso un parametro? Non serviva ad una fava? ... ma non era NULL quello...
Son necessarie ste modifiche o son "gratuite" (non come la birra, ma nel senso che non servono ad un c*zzo :D)?

Come mai non va ancora? Abbiamo chiamato il produttore, ah l'inizializzazione è cambiata? E perchè? ... ah certo e lui come fa a saperlo? Forse Linus lo sa... mah secondo me no...

Ciò che voglio dire è che il modello è caotico, non documentato e cambia di continuo: credi di imparare qualcosa e loro cambiano tutto! Perchè NVIDIA, AMD o Intel devono sbattesi così tanto e avere quei bei ringraziamenti?
Perchè quando alla fine il mio driver compila e va come un'ape leggo in syslog "Proprietary driver (C) XXX IRQ F1CA taints the kernel", perchè? Poveri noi altro che il kernel... siamo noi che siamo "tainted" qualunque cosa significhi :cry:
(certo che è proprietario manco è mio, è del cliente!)

Scommetto che scrivere driver per Windows è molto più facile, tutto si può dire di M$, ma loro la documentazione la scrivono...

Concordo invece che Facebook sia un po' sospetto mettere tutta la propria vita privata alla "berlina", impersonare altri (ci sono un sacco di siti finti di star o di finti ragazzi che in realtà son vecchi pedofili che li usano per adescare minorenni): non mi piace e NON lo uso...

Google, invece, non so perché, ma mi ispira più fiducia...

OK questa è quasi "politica", dai!
SNIPDiscussione molto interessante anche se credo che stiamo andando un po' OT (il che mi sta benissimo eh :) ).

E' politica, anche senza quasi, tant'è vero che i principi della GPL e del software libero sono stati estesi a tanti altri ambiti che magari all'inzio erano correlati con l'attività informatica ma ora non lo sono più.
In questo io non ci vedo nulla di male, quella di RMS però è una lotta imperniata su principi di libertà, non una lotta contro il profitto a prescindere, tant'è che nella GPL è scritto chiaro e tondo che il profitto è assolutamente previsto anche in questo modello di distribuzione anche se limitato all'ambito del servizio, non il prodotto (software):(…) you have the freedom to distribute copies of free software (and charge for this service if you wish) (…).

Si può obbiettare che questa lotta per la libertà stride con la "libertà di vendere il proprio prodotto", qualcuno potrebbe a sua volta ribattere che un atteggiamento avverso al software libero limiterebbe la libertà di modificarlo e distribuirlo a sua volta e così via...
Il dato di fatto è che un modello basato su quello del software libero ha prodotto innovazione a carriolate senza applicare copyright restrittivi, il modello basato su software proprietario ha generato più lotte a suon di copyright per difendere il profitto che per incentivare l'innovazione.
Questo è un dato di fatto, strumenti come brevetti o restrizioni legate alla difesa della proprietà intellettuale sono state usate più per limitare la concorrenza che per innovare, la storia degli ultimi anni lo insegna così come lo insegnava anche ai tempi delle stampanti Xerox dentro al MIT di RMS ;)

Riguardo ad AMD, Nvidia, Intel e soci io non starei a strapparmi le vesti per un semplice dito medio o una dichiarazione forte (si sa che Linus è una persona dal carattere piuttosto curioso :asd: ), se hanno contribuito allo sviluppo di qualche progetto Open non l'hanno certo fatto per perderci, non so dire di preciso dove abbiano recuperato gli investimenti, però sono confidente sul fatto che l'abbiano fatto, in caso contrario avrebbero già smesso.