[AcLab] "ehi capo, passiamo al software libero?"

[Shark]

On Mon, Oct 29, 2012 at 08:41:18PM +0100, al3xu5 / dotcommon wrote:
> > Solo alcuni appunti. Non e` vero che un software "chiuso" sia
> > intrinsecamente insicuro. Sto lavorando anche su questo fronte in
> > universita` (e fuori) e  non per forza e` cosi`.
> > O meglio, e` intrinsecamente insicuro, ma ci sono metodi (e altri che
> > stiamo sviluppando) per fare in modo che un software insicuro (o
> > "untrusted" nella letteratura) non sia in grado di rubare le
> > informazioni che gli vengono passate.
> 
> so che ci sono diversi metodi per verificare cosa fa davvero un software...
> ma il problema è che il 99,9999% dei comuni utilizzatori di software
> proprietario non ha i mezzi e gli strumenti per fare verifiche di questo
> genere, sempre ammesso che si pongano anche solo vagamente questo genere di
> problematica...

Questo e` vero, pero` si stanno facendo (e anche io ora ne sono dentro)
ricerche per riuscire ad isolare i componenti "untrusted" e limitare le
cose che possono fare in maniera trasparente all'utente.

> > E non solo: una volta aggiunta una nuova feature bisogna tenerci dietro.
> > Ad esempio, ipotizziamo di avere il software open X, a cui ci fai una
> > modifica tu perche` ti serve in azienda. Quando esce una nuova versione
> > di X a cui sono stati sistemati dei bug dovrai perdere altro tempo (a
> > volte meno a volte anche di piu`) per mettere la tua feature anche in
> > questa nuova versione! E cosi` via per il resto del tuo tempo :-).
> 
> non è detto: basta che non ti tieni la modifica per te e mandi la patch alla
> community perché sia integrata nel ramo di sviluppo (anche questa è una cosa
> abbastanza normale, anche se la modifica la fa un singolo utente e,
> soprattutto, quando le modifiche le fanno aziende o enti)

Non sempre e` una cosa facile inserire una modifica nel ramo di
sviluppo, anzi, a volte puo` richiedere molti mesi di lavoro oppure
potrebbe non venire mai accettata.

> > Attenzione, non sto dicendo "software chiuso e` bello" e "software open
> > e` brutto" o viceversa, sto solo cercando di riportare che in entrambi i
> > lati ci sono dei pregi e dei difetti, e a volte personalmente preferisco
> > uno o l'altro.
> 
> capisco e in astratto concordo
> ma sono rari i casi, nella mia esperienza, in cui un software proprietario
> -fatta tutta l'analisi del caso- risulta preferibile a uno open/libero, quasi
> sempre poi si tratta di casi in cui i "limiti" del software open/libero
> derivano dalla presenza di vincoli (principalmente brevetti e/o formati chiusi)
> che ne hanno ostacolato lo sviluppo (per esempio i software CAD)

Adesso non me ne vengono in mente molti di esempi, ma posso farti un
esempio che mi e` capitato ad un amico proprio poco tempo fa.
Essendo anche lui un apprezzatore del software libero aveva sistemato un
server con rsync per sincronizzare vari computer con un server centrale.

Dopo aver fatto un po` di prove e aver valutato i costi ha visto che gli
conveniva su tutti i fronti (tranne quello dell'etica e se volete della
sicurezza) usare (e pagare) DropBox. Tutte quelle cose che fa con
DropBox non poteva farle con nessun software libero "out of the box", e
(riprendendo il discorso della produttivita`) non aveva tempo da perdere
in questo genere di cose perche` aveva appunto del lavoro da fare.

La scelta puo` essere discutibile, ma quando me l'ha detta non ho potuto
fare altro che approvarla.

Salot