[Linuxtrent] Re: Andy Tanenbaum, author of Minix, writes an open letter to Intel

  • From: "Marco Ciampa" <dmarc-noreply@xxxxxxxxxxxxx> (Redacted sender "ciampix" for DMARC)
  • To: linuxtrent@xxxxxxxxxxxxx
  • Date: Wed, 8 Nov 2017 16:01:07 +0100

On Wed, Nov 08, 2017 at 03:09:57PM +0100, Michele Bert wrote:

Mick


Il 8 novembre 2017 13:43, Marco Ciampa <dmarc-noreply@xxxxxxxxxxxxx> ha 
scritto:
On Wed, Nov 08, 2017 at 01:11:59PM +0100, Michele Bert wrote:
Il giorno 8 novembre 2017 11:57, Marco Ciampa
<dmarc-noreply@xxxxxxxxxxxxx> ha scritto:

On Tue, Nov 07, 2017 at 11:47:23PM -0700, Daniele Nicolodi wrote:
On 07/11/17 14:38, Marco Ciampa (Redacted sender ciampix for DMARC) 
wrote:
1) Ha cambiato la licenza in modo che potessero farci quello che
volevano. Ne hanno fatto quello che volevano.

Non mi pare che la GPL abbia alcuna restrizione d'uso.
Il fatto che
Intel usi MINIX piuttosto che Linux è solo una questione tecnica. Che
differenza farebbe se ci fosse un kernel Linux al suo posto?

Che dovevano pubblicare i sorgenti??? Daniele di sei dimenticato tutto?

Ma i sorgenti di MINIX non sono già pubblicati? Altrimenti non
avrebbero potuto usarli.

Perché no? BSD da questa "libertà", la GPL no. È la ragione per cui hanno
insistito tanto sul cambio di licenza...

Scusa: io per "usare" intendevo prendere così come sono, non modificare. 
Questo
avrebbero potuto farlo anche con la GPL.

Sono d'accordo. Il fatto è che è veramente difficile usare un software
così com'è senza doverci / poterci fare modifiche. Inoltre i termini
della licenza GPL dicono che _tu_ devi _necessariamente_ rendere
disponibile il codice usato. Anche ammesso e non concesso che tu non
abbia fatto alcuna modifica, dubito che tu possa cavartela con un "l'ho
scaricato da qui, prendetevelo". Se il sito dal quale hai scaricato il
codice non c'è più, che fai? Rischi di violare la licenza? Per cui è
auspicabile (per chi usa il codice) mettere la copia del codice usato su
un proprio sito pubblico cosi da poter rispettare i termini della licenza
senza dover dipendere da alcuna entità esterna e indipendente.
 

On 07/11/17 14:38, Marco Ciampa (Redacted sender ciampix for DMARC) 
wrote:
la diatriba sull'efficienza l'ha vinta nei fatti Linus tanto
tempo fa altrimenti uno di quei "meravigliosi" microkernel avrebbe preso
piede nell'informatica che conta (datacenter, cluster, supercomputers) e
non al posto del DOS o roba simile su processori ridicolmente piccoli...

Il discorso non mi convince affatto: l'informatica che conta che hai
menzionato tu è quella in cui l'efficienza non è la massima priorità,
ma arriva dopo sicurezza e stabilità.

Nei datacenter grossi, garantisco che l'efficienza ha una fetta
importante...

Quando usi gigabyte e gigaflop a profusione per l'elaborazione di
montagne di dati, non è qualche kb, o qualche migliaio di cicli di 
clock che ti fanno la differenza. 

Nei sistemi più piccoli invece lo faceva (nota il verbo al passato).

D'accordo ancora. Però la gestione energetica (efficienza energetica)
invece è qualcosa che è sempre più importante... e difatti Linux in
questo campo ha fatto passi da gigante...


e chi dice che Linux è meno sicuro e stabile?

Al contrario: io concordo che Linux è più sicuro e stabile. Non sto nemmeno
affermando che Linux sia meno efficiente. Dico solo che, con le mie 
competenze,
nei fatti menzionati non vedo evidenza che Linux sia più efficiente di
un sistema basato su microkernel, dove per "efficiente" intendo che necessiti
di meno risorse (memoria, cpu, ...).

Ma neanche io.

Ma penso il problema sia altro. Supponiamo sia più efficiente Minix: chi
è che porta i driver del megazilione di periferiche che Linux supporta,
in maniera efficiente, su Minix? Fare un sistema con 3 driver (MacOSX
insegna) in maniera efficiente è decisamente più facile che farlo anche
per tutti i driver esistenti sulla terra...


Hurd insegna: fare stare in piedi un microkernel non è una passeggiata...

Qui siamo ai confini delle mie conoscenze: ho a malapena una vaga idea
di cosa renda così complessa la gestione di un microkernel.

Anche io. E visto che Stallmann e soci ci hanno messo tanti anni per far
funzionare decentemente HURD mentre Linux era già in funzione bene o male
in un anno scarso mi domando se con lo stesso sforzo non si riesca a far
funzionare Linux anche meglio...

Il trucco sta nei dettagli: i microkernel sono più o meno efficienti A
PARITÀ DI SFORZO IMPLEMENTATIVO e non in assouto?

Questa è la vera questione secondo me...

In generale posso dire che in 20 anni di sviluppo software l'idea che mi sono
fatto è che più vuoi che una cosa sia efficiente (leggi "ottimizzata"), e più
aumenta la complessità, e con la complessità aumenta predisposizione
ad errori, e la quantità di lavoro necessario per portarlo avanti.

Concordo pienamente. In effetti lo sviluppo di Linux tende ad aumentare
l'efficienza ma senza "trucchi", e per quanto possibile Linus (senza la
x) e i suoi collaboratori tendono a cercare di mantenere una certa
"eleganza" e coerenza interna del codice; cosa che col tempo paga in
termini di semplicità di sviluppo.

Nel mercato attuale, la velocità di sviluppo di prodotti stabili, paga più
della parsimoniosità di risorse. In altre parole, sviluppare software più
efficiente costerebbe molto di più che aggiungere GByte, core, o batterie
ai dispositivi su cui gira il software.

In realtà è sempre tutto un compromesso, anche perché le risorse hw
tendono ad aumentare ma questo aumento sta rallentando man mano che si
arriva ai limiti fisici della tecnologia del silicio...

Sono convinto che se venissero provati inequivocabilmente dei vantaggi
sostanziali al passaggio all'architettura microkernel, Linus stesso
sancirebbe la deviazione di rotta del progetto Linux verso quella
tecnologia.

--


Marco Ciampa

I know a joke about UDP, but you might not get it.

------------------------

 GNU/Linux User #78271
 FSFE fellow #364

------------------------

-- 
Per iscriversi  (o disiscriversi), basta spedire un  messaggio con OGGETTO
"subscribe" (o "unsubscribe") a mailto:linuxtrent-request@xxxxxxxxxxxxx


Other related posts:

  1. Home
  2. linuxtrent
  3. Archive
  4. 11-2017