[Discussioni] Openn source - Stallman - free software

[Marco Ermini]

<quota chi="Michele Sciabarra'">
[...]
> No, Java li ha. Ma in misura molto minore. Con Perl o Python ti trovi
> che in una distro c'è un modulo che in altro non c'è, o ti trovi
> versioni di moduli con Api platealmente incompatibile. Con Java ti
> ritrovi al più metodi deprecati, o bug (ma che vengono riconosciuti come
> bug, e presto o tardi (sempre troppo tardi per quanto te ne accorgi
> sigh)) di incompatibilità che fanno funzionare p.e  funzionare, una app
> con jdk 1.3 e non funzionare con la 1.4.
</quota>

Questi però non sono strettamente problemi di compatibilità. Una app
certificata per una certa JDK funziona con quella. A me è toccato
rintracciare nei modi più disparati la versione 1.4.1_06 per Solaris Sparc
8 a 32 bit... perché la tale applicazione era certificata per quella JDK.
Spesso però sono problemi più che altro "formali" o di "responsabilità
politica" - se esci fuori dal seminato e l'app non funziona, vengono a
cercare te... altrimenti vanno a cercare il fornitore... ecc.



<quota>
> A volte sono bug del programma
> (errata interpretazione della API) a volte della nuova versione. Ma nel
> complesso Java, come Windows, cercando di mantere un "filo conduttore",
> e perché è sotto il controllo di una unica entità.
>
> Linux  (il kernel) è sotto il controllo di Torvalds, ma non ha potuto
> (per licenza) impedire che ci fossero (perché questo sono) dei fork del
> kernel fatti da RedHat Suse etc. E sono perfino più diffusi del kernel
> ufficiale di linux.
</quota>

No, contesto decisamente il fatto che RedHat o SuSE facciano dei fork: è
semplicemente falso.

Che i loro kernel siano più diffusi è ovvio: loro forniscono la distro
alla stragrande maggioranza degli utenti.

Però il discorso non è così semplice. Chi prepara la tal versione di
kernel per la tale distro è sempre qualcuno che comunque lavora
professionalmente e quotidianamente sul kernel, e non è che si inventano
chissà cosa; quello che fanno è semplicemente la stessa cosa che fanno
TUTTI gli informatici professionisti, ovvero: implementano le richieste
del marketing. (mi sento un po' Dilbert nel dire questo... però è vero
;-). Se i tuoi clienti vogliono una distro con i pthread tu rilasci un
kernel che li supporta; se hai problemi legali con l'NTFS non compili quel
tal modulo nel tuo kernel - questo però non vuol dire che RedHat o SuSE
fanno dei fork. RedHat e SuSE in ogni caso sono allineati con la versione
di Torvalds (i dipendenti RedHat la chiamano "mainstream kernel") ed
applicano delle patch alla versione prescelta; la gran parte delle volte è
un backporting alla versione stabile di una feature presente nella
versione sperimentale o in una stabile successiva a quella prescelta. E
comunque è una prassi che tende a diminuire: uno degli obiettivi di RedHat
Fedora è *deliberatamente* essere quanto più possibile aderente alla
versione mainstream del kernel.


> Mentre Sun ha potuto impedire che fosse chiamato
> "Java" la JVM alterata fatta da Microsoft. Quello che peraltro cerca di
> fare anche red hat con le varie versioni del suo sistema.

Perdono: questa affermazione non l'ho compresa.


> Ma che non si può dire in genere di "Linux" inteso come
> l'unione di tutte le versioni di tutte le distro (mentre lo si può dire
> di "Java" o di "Windows", e anche di "RedHat" (dico di quello perché
> conosco quello)).
>
> Il discorso quadra? E' un concetto anche di comunicazione verso chi, è
> il grande pubblico, si fa impressionare dal fatto che è Java 5 e non
> Java 1.5 ed è solo un rename.

Cioè, adesso il discorso si è spostato sul fatto che c'è chi identifica
"RedHat 9" con "Linux versione 9"? dico sul serio: non ho capito questo
ultimo discorso.

Il discorso precedente, sul fatto di avere delle distro "consistenti"
rispetto alle applicazioni, l'ho capito ed in parte lo condivido, anche se
con i distinguo circa le indicazioni tecniche che hai dato.


Ciao.
-- 
Marco Ermini
http://www.markoer.org
Dubium sapientiae initium. (Descartes)
root a human # mount -t life -o ro /dev/dna /genetic/research
<< This message is for the designated recipient only and may contain
privileged or confidential information. If you have received it in
error, please notify the sender immediately and delete the original.
Any other use of the email by you is prohibited. >>