[Discussioni] [Thomas Lord] [Gnu-arch-users] the way forward

[Simo Sorce]

On Sat, 2005-09-17 at 12:13 +0200, Andrea Russo wrote:
> Simo Sorce <simo a softwarelibero.it> writes:

> > In alcuni casi Tom Lord evidenzia possibili pericoli, che sono anche
> > condivisibili, ma la sua paranoia lo porta a considerare le pratiche
> > attuali come ad un piano elaborato di controllo sociale, cinismo, e
> > malafede che secondo me non esistono perché in realtà si tratta quasi
> > sempre di semplice stupidità/incapacità (Rasoio di Ockham).
> 
> spesso dove c'e' ignoranza, c'e' qualcuno che ci marcia sopra.

Questo non vuol dire che ci sia dietro un "piano per conquistare il
mondo".

> > Mi riferisco
> > alla supposta bassa qualità del software libero e di come le
> > distribuzioni GNU/Linux vogliano mantenere questa supposta bassa
> > qualità. Non credo assolutamente che le distribuzioni puntino alla bassa
> > qualità, nè che il codice sia di bassa qualità.
> 
> dipende da cosa intendi per qualita'. GNU Arch e' certo un ottimo
> esempio di KISS e di "do more with less". Si puo' dire lostesso di svn
> per esempio? Le intricate dipendenze tra componenti software e la
> complessita' di alcuni progetti sono davvero necessarie? O ci sono
> pratiche di ingegneria che permettono di ridurre questi problemi?

L'unico modo per non avere dipendenze è riscrivere sempre tutto da zero
o integrare le librerie di altri direttamente nel proprio sorgente.
La prima opzione cozza contro il riuso dei componenti e anche contro la
qualità. Integrare librerie di altri porta a un gran dispendio di
energie per continuare a fare il merge dalla versione ufficiale, con
tutto quel che ne consegue.
La logica KISS presuppone l'esistenza di tanti altri piccoli componenti
da cui dipendere in modo da non re-implementare sempre tutto in effetti.

In ogni caso le risposte alle domande sono (imho):
- Si, progetti complessi esistono e non è possibile semplificarli senza
perdere considerevolmente in funzionalità e finire a produrre un
giocattolo inutile (vedi il kernel per esempio), e le dipendenze sono
necessarie se vuoi riutilizzare codice ottimo sviluppato da altri
apposta per essere riusato (librerie).
- Il metodo per risolvere i problemi si chiama standardizzazione, ovvero
avere interfacce stabili e chiare in modo che le dipendenze siano facili
da rispettare e possono esserlo da più componenti in modo di avere anche
pluralità di scelta, per la complessità mi sa che c'è poco da fare.

> > Spala merda su RHN di cui si può benissimo fare a meno usando altri
> > mille tool liberi e/o distribuzioni libere 100% compatibili (CentOS,
> > White Box, ecc..), parla di lock-in obbligato dalle patch, fatto che
> > cozza frontalmente con il plot della standardizzazione per gli ISV
> > proprietari che notoriamente richiedono piattaforme software stabili
> 
> qui sono poco informato in effetti. MI dici che succede col mio
> contratto di assistenza di Red Hat se comincio ad aggiornare con patch
> di altre distro e ad aggiungere repository non ufficiali?

Che succede con la garanzia della tua utilitaria se cambi carburatore,
marmitte, modifichi la carrozzeria, i fari, ecc... ?

Se hai bisogno di un ambiente personalizzato non prendi un contratto di
assistenza RedHat, non ti ci obbliga nessuno. Se invece valuti
l'assistenza come necessaria ti scegli la distribuzione che ti offre i
componenti che ti servono.

Anche io quando offro assistenza su certe macchine indico cosa può o non
può fare il mio cliente. Se gli sta bene concludiamo il contratto se no
no.

> > In due parole mi sembra che lui sia molto, troppo al di fuori del
> > settore per fare la critica che fa.
> 
> a me sembra uno sviluppatore di altissima qualita' con eseprienza
> pluriennale.

appunto, fa lo sviluppatore, non il manager, il consulente o il
sistemista. Ha un punto di vista limitato, che non tiene conto di
esigenze che con l'ingegneria del software hanno poco a che fare, ma di
cui non si può fare a meno nel mondo reale.

> > La "colpa" è sempre tua anche se l'insegnante è pessimo, perché non te
> > ne sai accorgere e/o non lo cambi.
> 
> non sono d'accordo, gli insegnanti mediocri, a mio avviso, fanno cosi'
> tanti danni che istituirei un fondo per mandarli in pensione
> prematuramente piuttosto che permettergli di far perdere tempo e
> opportunita' ai loro studenti.

io manderei in pensione anche molti studenti per quanto sono mediocri
:-P

> > È uno dei punti cruciali, il lock-in, in questo paper. Tu ti senti
> > bloccato quando usi una distribuzione? Finora hai avuto veri grossi
> > problemi a passare da una distribuzione all'altra?
> > Io mai. Certo se non conosci per niente lo strumento che hai in mano
> > puoi anche rimanere dipendente, ma la colpa è tua non certo di
> > fantomatici bastoni tra le ruote che le distribuzioni metterebbero.
> 
> Non si tratta di non riuscire a cambiare distribuzione. Sono ben altri
> i lock-in di cui parla Tom Lord.

Se intendi i lock-in dovuti a software proprietario allora om Lord non
dice nulla di nuovo e non può certo dare colpa alle distribuzioni per il
fatto che gli utenti scelgano software proprietario. Cosa dovrebbero
fare le distribuzioni? Impedire ai propri clienti di scegliere il
software come meglio credono?

Hai mai provato a metterti nei loro panni?

Simo.

-- 
AsSoLi - Associazione Software Libero
email: info a softwarelibero.it
website: http://www.softwarelibero.it