Home > GNU/Linux, Libero vs Proprietario, Riflessioni > GNU/Linux e software proprietario: una convivenza difficile

GNU/Linux e software proprietario: una convivenza difficile

La mia personale esperienza con GNU/Linux mi ha portato ad una conclusione: il software proprietario funziona male su questo sistema operativo, in particolare i driver.

Non parlo di problemi etici o filosofici – quelli sono noti – ma proprio di problemi pratici: incompatibilità, crash, lentezze, bug. I driver ATI, il plugin Flash di Adobe (ed altri esempi che analizzerò più in dettaglio in seguito) sono le croci degli utenti che passano al pinguino.

L’origine di questi problemi non è tecnica né legale e spiego subito il perché. Non c’è nulla, in un tipico sistema GNU/linux, che impedisca o ostacoli l’installazione e l’uso di software proprietario.

E’ interessante notare un particolare. Come abbiamo visto in precedenza, una delle componenti fondamentali di ogni sistema GNU/Linux è la libreria C di GNU (glibc). Ogni programma compilato per GNU/Linux fa uso di tale libreria. Quando dico “fa uso” intendo quello che, tecnicamente, è chiamato linking e che abbiamo già visto in questo post.

Se uso una libreria in un mio programma, tale programma è, dal punto di vista legale e tecnico, un “lavoro derivato“. Molti programmi, in effetti, sono composti di poche istruzioni che rendono fruibili all’utente le funzioni di una determinata libreria.

In base alla licenza GPL (la licenza con la quale è rilasciata la gran parte del software GNU/Linux) nessuno potrebbe usare una libreria sotto tale licenza all’interno di un software proprietario in quanto il lavoro risultante (programma+libreria) non potrebbe essere rilasciato sotto una licenza proprietaria.

Da ciò deriva che, siccome glibc è indispensabile per ogni programma, se fosse distribuita sotto la GPL allora nessun programma proprietario potrebbe, legalmente, essere sviluppato per GNU/Linux.

Tuttavia glibc non è rilasciata sotto GPL, ma sotto una licenza simile, la LGPL (Lesser GPL, ovvero licenza GPL “attenuata”). Questo perché, come ammesso dallo stesso Stallman, impedire l’uso di software proprietario su GNU/Linux non sarebbe una buona idea per la diffusione del sistema.

Sul sistema GNU (termine che include GNU/Linux) l’unica libreria C disponibile è quella GNU. Quindi i termini di distribuzione della nostra libreria C determinano se sia possibile o meno compilare un programma proprietario per il sistema GNU. Non ci sono ragioni etiche per permettere l’uso di applicazioni proprietarie sul sistema GNU, ma strategicamente sembra che impedirne l’uso servirebbe più a scoraggiare l’uso del sistema GNU che non a incoraggiare lo sviluppo di applicazioni libere.

da: http://www.gnu.org/gnu/thegnuproject.it.html

Lo sottolineo perché spesso si attacca Stallman e il progetto GNU dicendo che sono “talebani”, ma è un’immagine piuttosto forzata. Sulle cose importanti anche loro fanno compromessi, l’importante è che tali compromessi non compromettano (scusate il gioco di parole) l’obiettivo di conquistare maggiore libertà per gli utenti.

Fatta questa premessa necessaria, vediamo i problemi maggiori che gli utenti GNU/Linux incontrano con il software proprietario per tale sistema.

Flash: è davvero un piccolo dramma. A parte la pesantezza (comune anche alla versione per Windows), il plugin Flash per GNU/Linux sembra litigare costantemente con Firefox e lo fa crashare. Inoltre non è disponibile a 64 bit, costringendo gli utenti di tali sistemi a vari salti mortali a suon di plugin wrapper. Inoltre presenta un fastidioso bug sulle trasparenze che rende difficile la fruizione di alcuni siti che fanno uso di menu realizzati in Flash.

Uno dice: ok, li risolveranno prima o poi. Eh, il problema è: poi quando? Sono 16 mesi che uso GNU/Linux e nessuno di tali bug, piuttosto evidenti, è stato risolto. Intanto ho visto 4-5 aggiornamenti del plugin Flash, ma nessuno ha migliorato tale situazione critica, che peraltro si trascina da anni. Molti speravano nella versione 10 di Flash, ma le speranze sono state deluse. L’instabilità del nuovo plugin è drammatica, al punto che il team di Ubuntu ha dovuto ritirarla in fretta e furia dai repository “proposed”. Ok, si tratta di una versione beta, però la speranza era di vedere un pur timido miglioramento della stabilità, non un suo drammatico decremento.

Ora, voi pensate che alla Adobe non sappiano che ci sono questi problemi? Certo che lo sanno, ma se ne fregano, oppure non sono in grado di risolverli.

ATI: la pessima qualità dei driver ATI proprietari è leggendaria. Gli utenti che riescono a cavare qualcosa di buono da tali driver vengono portati il trionfo sui forum e a volte in loro onore vengono organizzati riti orgiastici di vario tipo durante meeting, raduni e install fest🙂 I meno fortunati si accontentano di non usare gli effetti 3D, a meno che non incappino in una scheda supportata dai driver open: meno performanti certamente, ma anche molto meno rognosi.

La ATI ha recentemente rilasciato le specifiche di alcune schede (solo per il 2D…) e da questo lavoro sono nati i driver RadeonHD. Ma la gente vuole compiz e lì siamo in alto mare.

NVIDIA: va decisamente meglio ai possessori di schede nvidia, ma non tutto bene. Anche quelli ogni tanto svirgolano. Ad esempio non funzionavano con il kernel 2.6.25. La questione è piuttosto complessa. I driver nvidia (ma anche i driver ATI fglrx) sono composti da varie parti: un pezzo open il cui codice sorgente è disponibile (ma non è libero) che si inserisce direttamente come modulo nel kernel ed un pezzo proprietario. Aggiungiamoci il fatto che, per come è composto GNU/Linux, dobbiamo lavorare sia con il kernel che con Xorg e si capisce subito come sia complicato far funzionare bene questo ambaradan composto di programmi liberi che devono lavorare con pezzi di codice proprietario.

Modem, schede di acquisizione video, schede di rete wifi: qui il problema è leggermente differente. In alcuni casi i produttori realizzano driver proprietari e ricadiamo negli stessi problemi di ATI e Nvidia. In altri casi, invece, abbiamo driver liberi che però devono usare dei firmware proprietari che, spesso, non possono essere distribuiti liberamente (un firmware è un pezzo di codice che non gira sul processore del pc, ma su quello della periferica e quindi deve essere caricato nella memoria di quest’ultima). Questo costringe l’utente a navigare in giro alla ricerca di guide e siti dove scaricare tali firmware e a eseguire bizzarri comandi da terminale, compilazioni, ecc.

Java: questo è uno dei pochi software proprietari (mi riferisco alla Java Virtual Machine della SUN) che funziona davvero e bene, senza particolari problemi. Ma il motivo è presto detto: SUN opera principalmente nel campo Unix (produce il sistema operativo Solaris). Inoltre da tempo ha rese libere parti di java stesso, quindi siamo in una situazione molto particolare. Peraltro non è più indispensabile usare la JVM di SUN in quanto quella di Red Hat e GNU (icedtea-gcj) ha superato i test di compatibilità della stessa SUN.

Opera: il noto browser funziona abbastanza bene su GNU/Linux. Ma deve “subire” le preferenze del mercato per Firefox. Difatti non esistono plugin per Opera e quindi fa uso di quelli per Mozilla/Netscape. Il caso di Opera però è diverso, poiché parliamo di una applicazione e non di un driver.

Skype: E a smentire quanto appena detto🙂 arriva Skype. Certo, di funzionare funziona. Ma perché non supporta tutte le webcam supportate dal sistema?

Vabe’, potrei continuare con altri esempi.

Una precisazione: anche i software open source a volte danno problemi, ma è più raro. Di solito i driver liberi funzionano bene (ad esempio le schede Intel) e comunque i problemi vengono risolti con maggiore rapidità.

Detto questo, perché il software proprietario, in particolare i driver, sembra litigare con GNU/Linux? Il motivo è nel diverso modello di sviluppo. Il software libero viene aggiornato spesso, rilasciato di frequente, con piccoli o grandi cambiamenti. Quando due software vanno in conflitto è facile individuare la causa e modificare l’uno o l’altro. Se non ci pensano gli sviluppatori ci pensano le stesse distribuzioni. Debian è famosa per avere un team di patchatori che si preoccupano di fare in modo che ogni mattoncino della distribuzione non confligga con gli altri. E’ un po’ come un puzzle: a volte i pezzi non si incastrano bene, quindi è necessario usare le forbici per modificare il profilo del pezzo. E lo si può fare solo se si ha la libertà di modificare il codice sorgente.

E’ un motivo di disperazione? La comunità dovrebbe fare in modo di aiutare i produttori di software proprietario a “migliorare” le proprie creazioni?

Risponderei di no ad entrambe le domande. Questa situazione, che sembra essere svantaggiosa, in realtà negli ultimi tempi si sta rivelando positiva. Poiché GNU/Linux si diffonde, e poiché i driver proprietari sembrano funzionare poco, diverse case produttrici si sono convertite, volenti o nolenti, al software libero.

Nell’ultimo anno e mezzo VIA, ATI e Atheros hanno aperto le porte all’open source. Quest’ultima ha addirittura assunto l’autore del driver open delle sue schede. Intel, che pure fa da sempre driver open, ha ulteriormente intensificato gli sforzi, rilasciando le specifiche delle sue schede video e creando nuovi driver liberi (sia pure con firmware proprietario) per le sue schede wifi.

Netgear ha deciso di creare un firmware per i suoi router che possa essere pienamente disponibile alle modifiche della comunità.

Dell ha creato versioni customizzate di Ubuntu che girano meglio sull’hardware da essa utilizzato.

Asus produce motherboard che montano una distribuzione GNU/Linux.

Adobe ha in parte aperto le specifiche di Flash.

Foxconn è stata costretta a correggere le sue motherboard.

Nokia sta per rendere open il sistema Symbian.

Eccetera…

Manca ancora un grande nome: Nvidia.

Recentemente gli sviluppatori del kernel Linux hanno lanciato un appello ai produttori: realizzate driver aperti o almeno dateci la possibilità di farlo. Il motivo è semplice: solo così funzioneranno davvero bene.

Insomma forse non tutti i mali vengono per nuocere.

  1. 25 agosto 2008 alle 18:49

    Davvero NVIDIA non supporta il kernel 2.6.25?
    Io su Debian ho installato i driver proprietari (scaricati dal sito sono proprietari no?) applicando una patch (per farla funzionare col kernel che ho). Però voglio dire, c’era la patch😀

    Bell’articolo, bravo😉

  2. 25 agosto 2008 alle 18:57

    Della serie se non si capiscono gli aspetti “filosofici” dell’open, almeno si capiscano quelli pratici🙂

    Posso portare una mia piccolissima esperienza, ho un asus con ubuntu tutto perfetto tranne la webcam, dava l’immagine capovolta, ed essendo un notebook non potevo girare la web.

    C’è un utente di ubuntu che aveva lo stesso problema, ma aveva conoscenze che io non ho ed è riuscito, lavorando sul driver open, a fare le opportune modifiche.

    Quando è open se non c’è lo sviluppatore ci può essere sempre qualcuno che può contribuire.

  3. 25 agosto 2008 alle 21:05

    @markon: sì ma appunto, non si compilavano. Poi tra patch e correzioni della stessa nvidia hanno funzionato. Però se fossero stati open, il problema non si sarebbe neppure posto.

    @tiziano: ottimo esempio. Io ho risolto tempo fa sul forum di ubuntu un problema simile con un driver per una scheda di rete, ovviamente libero. Una piccolissima modifica, seguendo il post di un blog, è stata sufficiente.

  4. 25 agosto 2008 alle 21:14

    Ciao, ti seguo da un pò, stai facendo un ottimo lavoro per chi, come me, sta cercando di entrare nel mondo di Ubuntu.

    Purtroppo ora ho problemi sul mio pc con Ubuntu 8.4, infatti una volta installato non ne vuol sapere di partire.

    Comunque, quello che volevo dire è che tempo fa, ai tempi della 7.10, ero riuscito con immensa fatica ad installare i driver ATI 8.8 sulla mia scheda.

    Da due giorni ci sto riprovando. Ma niente, anche seguendo la stessa identica guida.

    Ormai ci ho rinunciato, credo che aspetterò ottobre per la 8.10, mi sembra la conclusione migliore per il mio pc e la mia sanità mentale xD.

    Comunque sei fortissimo, continua così…

    Mirtrim

  5. 25 agosto 2008 alle 21:29

    @mirtrim: grazie per i complimenti. Ti consiglio di cercare aiuto sul forum di ubuntu per il tuo problema, comunque se mi dai qualche info in più posso darti una mano anche io.

  6. Slackeruser
    25 agosto 2008 alle 23:48

    Per flash c’è gnash pure 64bit http://it.wikipedia.org/wiki/Gnash
    tie “__”

  7. gnulinuxarea
    26 agosto 2008 alle 1:07

    ottimo articolo🙂

    la citazione di Stallman poi sembra risolvere un mio problema di coscienza recente

  8. gnulinuxarea
    26 agosto 2008 alle 1:14

    azz il primo link è cannato di brutto… eccolo (giusto per la cronaca)

    http://gnulinuxarea.wordpress.com/2008/08/23/goodbye-ubuntu/

  9. telperion
    26 agosto 2008 alle 11:28

    Quello che non si compila nei driver Nvidia, con nuove versioni di kernel o xorg, in realtà è solo l’interfaccia del driver binario al kernel, quel pezzo è fornito in codice sorgente che chiunque può patchare per risolvere il problema.
    Se vedi i pacchetti src di debian e ubuntu (quelli che si compilano con module-assistant) sono zeppi di patch del distibutore.
    Il pezzo “chiuso” è il driver binario vero e proprio, quindi non si può intervenire per difetti o malfunzionamenti del driver, non certo perchè “non si compila”.
    Nello stesso periodo (kernel 2.6.25) sicoome era cambiata sostanzialmente la struttura del kernel nemmeno il driver di virtualbox-ose si compilava, cosa risolta da una versione successiva come nel caso di nvidia.
    NOn vedo differenze sostanziali, la storia della compilazione mi sembra “tirata per i capelli”.
    Diversa la possibilità di intervenire sul driver medesimo per aumentare prestazioni, ma parliamoci chiaro in quanti sarebbero in grado di metterci le mani?
    Xorg è un catorcio il cui sviluppo va a rilento, Mesa ha tempi “biblici” di sviluppo, non vedo grandi orizzonti.
    Giustamente citi Intel come riferimento, bisogna dire però che i driver Intel di Xorg li sviluppa … Intel.
    Se aspetti “la comunità” temo che stai fresco …
    Senza polemica, solo per avere un quadro più preciso.

  10. UTL
    26 agosto 2008 alle 11:31

    io per nvidia aggiungerei:
    se avete una sk grafica vecchia, ma degna di essere usata (vedi gf 2, gf4mx ecc) potete pure ficcarla in un cassetto, chiuderlo a chiave e mangiare la chiave, non sperate di riuscire a farla andare…

  11. punkadiddle
    26 agosto 2008 alle 17:23

    bell’articolo, mi è piaciuto

    continua così..

  12. 26 agosto 2008 alle 20:05

    Le cose non sono semplici ok, ti do ragiona ma… raccontata come hai fatto tu sembra un pò una tragedia😀

  13. 27 agosto 2008 alle 1:32

    @telperion: sì, è vero quel che dici sul driver nvidia, ma come sai quel pezzo di driver non è sotto gpl e non è parte del kernel. In effetti sono stato impreciso nel definirlo “open”. Se lo fosse allora il problema non si sarebbe posto. Anche se il codice è disponibile, la licenza non lo rende libero, quindi il problema è sempre lo stesso, anche se siamo di fronte a un driver proprietario con parte del codice sorgente disponibile.
    Riguardo le modifiche ai driver, non importa “quanti” sarebbero in grado: ne basta anche uno solo… se si hanno le specifiche non è poi così difficile.
    Quanto a Xorg e Mesa i tuoi sono giudizi gratuiti. Xorg va così a rilento che ha già il multitouch ben prima di Windows, per non parlare di cose come xgl e aiglx che permettono di avere un’interfaccia 3d da molto prima di Windows Vista e con risultati molto superiori. Meno male che è lento sennò a quest’ora eravamo già ai livelli delle interfacce di Minority report.

  14. 27 agosto 2008 alle 1:39

    @gnulinuxarea: Ehi, un attimo. Io non ho scritto che Stallman vede di buon occhio l’uso di sw proprietario su GNU/Linux, ma solo che considera controproducente impedirlo tramite il cambiamento della licenza di glibc🙂

  15. aleida
    6 settembre 2008 alle 1:34

    Ho seguito con molto interesse sia l’articolo che i commenti.
    Straordinario il confronto-dibattito fra Telperion e Guiodic.
    Grandi entrambi!!
    Competenti, seri, bravi anche nello scrivere (che non è poca roba!).
    S’imparano un mucchio di cose da dibattiti come questo. E soprattutto li si legge con vero piacere.

  16. 23 ottobre 2008 alle 18:12

    bravo, hai espresso esattamente quello che penso su Stallman, on buona pace di chi lo chiama ‘talebano’. E con molto garbo. ciao

  17. 21 giugno 2009 alle 13:22

    Ma chi ha fatto quel video su Youtube??? è Fantastico!!!

  1. 26 agosto 2008 alle 2:53

Lascia un commento

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...

%d blogger cliccano Mi Piace per questo: