Diritto alla privacy

Quindi, di punto in bianco, a causa del gran casino che l’NSA spia tutti e tutto (i loro tentacoli raggiungono il 75% dei connessi), Groklaw ha deciso di chiudere.

Mi dispiace, ma forse è la scelta sbagliata per i motivi giusti. O la scelta giusta per il motivo sbagliato. O è sbagliato tutto.

Che ci sia un braccio di ferro in corso tra diritto all’informazione e diritto a far tacere l’informazione è pure triste. Però che quache paladino del software libero decida di andare in pensione adesso, mi sembra sbagliato. Certo PJ lavorava parecchio attraverso le mail. Ma non è che adesso è spiata più di prima: è cambiata la consapevolezza e forse con questa consapevolezza non riesce a fare più serenamente il suo lavoro. Ma non è un problema logistico, è un problema di emozioni. È chi prende decisioni importanti solo in base alle proprie emozioni può alla lunga pentirsi.

Che poi, un sottotesto che se tutti usassimo software libero saremmo meno spiati, spiace (e son tre!) ma non ci sta per niente. Se l’NSA può spiarci non è perché usiamo Windows anziché Linux (teorie cospirative a parte): ma perché usiamo l’email e la maggior parte dei server di posta lì fuori girano su software libero.

Un gran bel paradosso.

-quack

Pubblicato mercoledì 21 agosto 2013 alle 8:12 PM - 16 commenti so far
Archiviato in: Privacy, Linux

Upside down

Il mio geek preferito, Stallman, disse:

If the DRM is implemented in the operating system, this could result in distribution of works that can't be played at all on a free operating system such as GNU/Linux.'

Oggi giorno, nei paesi dove Netflix è disponibile, questo dovrebbe risultare palesemente falso. Netflix è disponibile su Windows e OSX perché MS non ha intenzione di rilasciare Silverlight – dichiarato ufficialmente moribondo – per Linux.

Netflix ha pure chiaramente detto che, se l’HTML5 supportasse il DRM, non avrebbero problemi a far girare la loro app in HTML5. Questo significa che se il DRM fosse parte dello standard, ci sarebbero più contenuti disponibili per Linux.

Al contrario: oggi siccome l’unica via per il DRM è il software propretario è possibile distribuire contenuti che non possono essere riprodotti su sistemi “liberi”; che è appunto il contrario di quello che Stallman dice.

Vista l’evidente falsità logica di quello che dice, rimane la domanda sul perché. Solo talebanesimo?

-quack

Pubblicato venerdì 3 maggio 2013 alle 12:16 AM - 10 commenti so far
Archiviato in: DRM, Linux

Understanding Linux

Ieri sera tardi, anche se non tardissimo, dopo l’ennesima lotta con Xen e il boot di Nexenta (la variante Solaris che ho deciso di utilizzare per ZFS), sono arrivato ad una conclusione, volendo persino banale, magari opinabile, ma che non mi pare di aver letto finora altrove.

L’episodio scatenante è stato questo: volevo utilizzare un metodo diverso per fare il boot della macchina virtuale su cui gira Nexenta (non per pura voglia di perdere tempo) utilizzando l’utility pygrub e rincuorato dal fatto che ci fosse una soluzione di backup migliore (pv-grub) a sostegno della riuscita dell’esperimento. Alla terza difficoltà, armato di bibbia, ho cercato di usare Pv-Grub ma non riuscivo a trovare “l’eseguibile” che pure è parte del pacchetto Xen standard. Ravanando su Google si scopre che siccome Debian “non compila XYZ in quanto ha dipendenze esterne” allora il pacchetto in questione manca. Ovviamente è possibile generarlo se ci si vuole avventurare nei percorsi compilativi.

Linux non è una piattaforma su cui far girare le applicazioni. Le applicazioni ci sono, non sono poche ma non sono neanche tante abbastanza per farne una piattaforma, ma questo non basta. Linux è una scatola di montaggio per piattaforme più o meno incomplete: a Debian manca questo, ad OpenSuse manca quest’altro, ecc. In Linux non esiste l’equivalente di “eseguibile” in quanto un “eseguibile” si presume abbia dipendenze binarie molto forti. Mentre in una piattaforma il contratto binario è basato su regole molto rigide, in Linux tutto è basato più o meno sui sorgenti. Chi gestisce il repository poi fa un lavoro più o meno buono di impacchettamento di sorgenti in bit ridistribuibili ma la varietà di scelta è tale che il lavoro dell’impacchettatore tende ad essere sempre sotto la sufficienza. Ad esempio nei vari kernel aggiornati di Ubuntu non è attivo il flag “CONFIG_XEN_PCIDEV_BACKEND=m” che non ha nessun effetto collaterale aggiuntivo (tolto qualche piccolo KB di occupazione di memoria) ma che porta a richiedere una ricompilazione ad hoc per chi come me ne ha bisogno.

È ovviamente possibile generare ottime piattaforme usando Linux come è il caso di Android (parlo ovviamente della piattaforma, non di tutto il resto che può avere qualità opinabili). Però nell’accezione generale d’uso la cosa è molto meno che ottimale in quanto un protocollo basato su codice sorgente è molto meno efficace di un protocollo binario: per lo meno è necessario un passo in più e purtroppo la compilazione è un processo meno deterministico di quanto si possa pensare.

-quack

Pubblicato lunedì 21 novembre 2011 alle 6:55 PM - 54 commenti so far
Archiviato in: Linux

Dio Xen

Per non essere blasfemo, userò la parola dio con la minuscola, intesa come divinità generica.

Cos’hanno in comune dio e Xen?

  • entrambe sono entità astratte, non si possono toccare, comprare o scaricare
  • non si può provare che esistano, l’esistenza è un dogma
  • la loro opera è descritta molto vagamente nelle scritture (nel caso di Xen in forma di Wikipedia)
  • la loro opera si manifesta in miracoli chiaramente non riproducibili (es.: VGA passthrough di Xen)
  • i loro profeti tendono ad apparire e scomparire in aloni di mistero (chi sarà mai il “cittadino di Singapore signor Teo En Ming”?)

Sinceramente un’entità software più sfuggente di Xen 4.1 non l’ho mai vista. Pare che dovesse apparire in Fedora 15 ma la venuta è stata rimandata a Fedora 16 (in alpha). Le uniche poche distro che sembrano includere (chissà quale versione) sono Qubes, RedHat e Suse. Le uniche guide step-by-step sono troppo dettagliate e includono sempre una

C’è qualche ‘sacerdote’ in ascolto che mi possa guidare al miracolo non riproducibile di cui sopra?

-quack

Pubblicato martedì 20 settembre 2011 alle 7:10 PM - 10 commenti so far
Archiviato in: Linux

Unix permissions vs. ACLs

La nuova implementazione del server è in dirittura di arrivo, mentre scelgo l’OS su cui installare i dati in formato ZFS. Sto provando FreeNAS 8 RC5 che mi piace abbastanza e mi son imbattuto con un problema alquanto classico.

Ci sono quattro utenti: Tizio, Caio, Sempronio e Ugo. L’obiettivo è di dare accesso totale a Tizio e Caio, in lettura a Sempronio e nessun accesso a Ugo (che ha accesso ad altri file). Di solito quando si confronta l’implementazione delle policy di accesso viene spesso fuori il luogo comune che le ACL sono più flessibili del necessario, che possono introdurre bachi se usate male, ecc. mentre i permessi Unix sono semplici e difficili da sbagliare.

Nel mio caso però non sono riuscito a trovare una soluzione soddisfacente al problema. Sono troppo Windows Oriented o le policy di accesso Unix tradizionali sono così limitate? Attendo illuminazione…

Pubblicato lunedì 25 aprile 2011 alle 7:14 PM - 28 commenti so far
Archiviato in: Windows, Linux