[Discussioni] free softwrae foundation: 6 progetti

[Elena ``of Valhalla'']

On 2017-01-19 at 17:37:08 +0100, Giovanni Biscuolo wrote:
> > Non so, da un lato questo è un problema al quale sono particolarmente
> > "affezionata" e anche a me piacerebbe vederlo risolto a fondo, ma alla
> > fin fine per i problemi pratici che un utente può incontrare il fatto
> > che il computer sia libero fino al processore
> 
> plz rileggi ;-) "computer libero fino al processore": io non ho mai detto
> questo :-)
> 
> ho detto driver liberi e firmware libero per "hardware proprietario"

hai ragione, ho solo fatto un passettino in più rispetto al discorso del
bios libero, ma lo giustificavo implicitamente da:

> anche l'hardware libero è interessante ma è fuori dallo scopo di questa
> discussione (oltre che dagli interessi e dalla lista dei progetti prioritari
> di FSF)

il problema è che aspettarsi hardware che non abbia i problemi citati
sotto sul link a libreboot dal mondo del mercato di massa è un po'
un'utopia, visto che sta andando invece nella direzione diametralmente
opposta.

Invece, dal mondo dell'hardware libero c'è un minimo di speranza di
vedere rispetto per la libertà dell'utente, e processori che siano
totalmente sotto il controllo di chi possiede il dispositivo e non di
chi l'ha prodotto.

Non è necessario che sia così, solo quella che mi pare essere la
tendenza attuale del mercato, e quindi la direzione in cui ripongo più
speranze.

> 
> > è meno rilevante rispetto al
> > fatto che i programmi coi quali effettivamente lui interagisce lo siano.
> 
> tipo che quando apri un video, con il programma X, si vede a scatti perché
> il sistema non riesce a usare l'accellerazione 2D/3D: probabilmente l'utente
> pensa che è il programma X che fa schifo ma noi sappiamo che il problema è
> un altro

uhm, onestamente è un po' che non ho più di questi problemi, e sempre
usando i driver liberi per la scheda.

Effettivamente è un bel po' che non ho mai avuto computer con schede
video recenti, ma sempre o intel scarsine (ma supportate bene) o vecchie
nvidia ricevute dalla pila di scarti di familiari vari (che
probabilmente sono meglio supportate dai driver liberi).

Ben diverso il discorso su architettura ARM, dove invece quei problemi
sono all'ordine del giorno (ma farci girare GNU/Linux non è ancora
proprio una pratica comune).

> > distribuzione qualsiasi (nel mio caso, una Debian a caso :) ) e trovarsi
> > che almeno il 90% del computer funziona senza doverci fare nulla.
> ma dai: ho problemi a far funzionare tutto per bene io che sono sistemista
> da anni, figuriamoci gli utenti più inseperti :-D

Ripeto quanto detto prima, per vari motivi io sto schivando¹ da tempo due
delle grosse fonti di problemi: hardware recenti e dual boot con
windows. Per il resto, boh, ho dovuto mettermi a contribuire a Debian
perché non mi si rompeva più il sistema da solo e non mi divertivo
abbastanza a ripararlo :)

¹ il secondo caso volontariamente, per il primo è in buona parte un caso.

> > Ci sono le schede wifi, per le quali c'è da trovare il pacchetto giusto
> > dei firmware in non-free, ed è una sofferenza farlo per motivi morali,
> > ma dal punto di vista pratico son 5 minuti, e comunque gli attacchi alla
> > libertà dell'utente che possono arrivare da un firmware proprietario
> > caricato dal kernel (contrapposto a salvato sull'hardware) sono tutti
> > teorici.
> 
> Elena capisco bene le tue perplessità, è da anni che leggo e ascolto da
> diversi colleghi della comunità del software libero che "se il firmware è
> proprietario" non è un problema: io dissento :-)

sono d'accordo che sia un problema, non sono d'accordo che sia il
problema più urgente, e soprattutto non sono per niente d'accordo che 
avere il firmware proprietario salvato sull'hardware sia meno peggio
(che è la posizione della FSF).

Alla fin fine, se un produttore di hardware vuole fare cose malevole ha
mille modi di farle, un firmware visibile in fondo non è neanche il
posto migliore, visto che è leggemente più facile da beccare.  Non
potersi fidare del produttore di hardware è un problema serio, e sì,
stiamo inziando ad essere in quella situazione (al momento secondo me
solo potenzialmente, non ancora in pratica), ma avere i soli firmware
liberi non lo risolve.

> scusa se mi ripeto ma - se non l'hai già fatto - dovresti avere la pazienza
> di leggere questo:
> https://libreboot.org/faq/#intel

questo è uno dei motivi per cui sto scrivendo da un X200 e non un X220
(l'altro è che usato costa all'incirca la metà, e il budget per un
portatile_che_potrei_brikkare_orrendamente_riflashando_il_bios è quello
che è :) )

> che spiega che in buona sostanza in tutti i sistemi (in questo caso Intel)
> c'è un *sistema parallelo* abbastanza performante e con accesso alla scheda
> di rete: «this hardware and its proprietary firmware can access and control
> everything that is in RAM and even everything that is shown on the screen»

e questo non è un problema di firmware: per quell'hardware non c'è nulla
che venga visto dall'utente come firmware che possa essere liberato, è
un problema di hardware obbligatoriamente presente e non controllabile
in nessun modo dall'utente

se anche rilasciassero i sorgenti di un qualche firmware per ME (o
l'equivalente AMD) non cambierebbe nulla, visto che comunque le macchine
accettano solo firmware firmato dai produttori.

> > per una versione spesso obsoleta di un kernel forkato (quello di
> > Android) e praticamente inusabili con qualunque altro sistema.
> > Per non parlare dei driver per video accelerato, che sono in condizioni
> > pietose come erano su PC svariati anni fa.
> 
> i problemi derivanti dai driver proprietari (tecnicamente LKM) sono spiegati
> bene da queste due frasi:
> «LKMs effectively become part of the running kernel, so can corrupt kernel
> data structures and produce bugs that may not be able to be investigated if
> the module is indeed proprietary»
> «Linux does not provide a stable API or ABI for kernel modules»(per cui per
> chi deve distribuire moduli proprietari è un incubo)
> 
> gli utenti non lo sanno, ma la causa del 99% dei loro problemi di
> compatibilità hardware è questa
> 
> [...]

Però sui sistemi PC mi risulta che per la stragrande maggioranza
dell'hardware ormai i driver liberi ci siano e funzionino. Poi per
alcune schede video ci sono ancora anche i driver proprietari, che a
volte funzionano meglio e a volte peggio (ma io continuo a non usarli).

Quelli per mobile, esclusa l'accelerazione video, invece spesso non sono
neanche proprietari, il problema è solo prettamente pratico di prendere
dei driver fatti per girare con una sola versione del kernel android e
sviluppati in fretta e furia (con le conseguenti scorciatoie e
quant'altro) e trasformarli in driver usabili con il kernel mainline,
cosa che è di poco meno laboriosa di un reverse engeneering (basta
vedere il lavoraccio che si stan facendo quelli della comunità sunxi_

.. _sunxi: http://linux-sunxi.org/Linux_mainlining_effort

> > Potrebbe funzionare qualcosa a livello legislativo, ma solo se riguarda
> > una fetta davvero *consistente* di mercato, quindi di sicuro non
> > basterebbe l'Italia da sola, ma almeno l'EU (o gli USA, che però vedo
> > ancora meno propensi a fare richieste del genere).
> mai dire mai, magari una roba del genere arriverà dalla Cina B-)
> ROTFL

potrebbe in effetti arrivare dalla Cina, anche se in quel caso mi
aspetto che la cosa riguardi solo l'hardware prodotto da ditte estere o
qualcosa del genere.

Dopodiché, io non trattengo il respiro nell'attesa, ma se arriva ben
venga!

> > però effettivamente per quelle si sono concentrate su comunicazione
> > audio e video, mentre a quanto mi risulta matrix.org è solo testo,
> > giusto?
> 
> no, matrix.org (il protocollo) è basato su HTTP e WebRTC per cui c'è dentro
> anche audio/video

uops, mi correggo.

> ho fatto qualche esperimento via riot.im e l'audio ha funzionato che è una
> meraviglia, anche su Android (la gestione delle chiavi per la e2e encryption
> ancora è troppo macchinosa però)

io invece giusto in questi giorni mi sto concentrando di più su xmpp,
che ha la fama di essere vecchio, ma se si aggiornano i server ha delle
feature che secondo me sono alla pari con lo stato dell'arte, ed è
difficile trovare un sistema che le abbia tutte come lui.

(nel mio caso con enfasi sulla comunicazione via testo, visto che
personalmente odio le telefonate e ancora di più le videochiamate, ma ho
visto anche delle cose belline per audiovideo tramite jitsi-meet.)

-- 
Elena ``of Valhalla''
-------------- parte successiva --------------
Un allegato non testuale è stato rimosso....
Nome:        signature.asc
Tipo:        application/pgp-signature
Dimensione:  488 bytes
Descrizione: non disponibile
URL:         <http://lists.softwarelibero.it/pipermail/discussioni/attachments/20170119/51a059de/attachment.sig>