Newsgroup: it.comp.os.dibattiti
Titolo: Prestazioni di Vista

 Prestazioni e Compatibilità
Attualmente la versione base di Windows Vista gira solo su processori da 
almeno 15Thz, con minimo 24GB di Ram, ma ne supporta solo 3. Inoltre Vista 
presenta un elenco di periferiche funzionanti molto ampio (nel senso che 
se le scrivi con un carattere molto ampio riempiono completamente un 
foglio A4). Il problema è che c'è un virus, il TROJAN, che ha fatto due 
figli con la moglie WORMS chiamati uno il figlio di trojan e l'altro il 
grandissimo figlio di trojan e sono molto pericolosi. 

VivaVista wrote:

beh a parte la trollata è vero che MS poteva fare di più per ottimizzare
Vista, comunque non è facile maneggiare milioni di linee di codice con
centinaia di migliaia di subroutine fortemente interdipendenti
è per questo motivo che qualche pazzo alcuni anni fa pensò l'architettura
microkernel, ma un giorno anche a Redmond capiranno che il microkernel è la
strada giusta, intanto aspettiamo fiduciosi e....non usiamo Vista :D

 la strada giusta, intanto aspettiamo fiduciosi e....non usiamo Vista :D
Puoi citarmi almeno un'implementazione di un microkernel puro
*general-purpose* di successo? (niente QNX né ectoplasmi tipo Hurd né
progetti accademici tipo Minix)
NT è un kernel ibrido con molti dei vantaggi di un microkernel. Con
Vista/Server2008, tra l'altro, la componente "micro" si è accentuata
parecchio (stack audio in userspace, gran parte del sottosistema video in
userspace, User-Mode Driver Framework, ecc.).
Siccome sei anche un sostenitore di Linux, credo saprai che si tratta di un
kernel sostanzialmente monolitico.
SALUTONI,
WindoM

 strada giusta, intanto aspettiamo fiduciosi e....non usiamo Vista :D
Questa discussione salta fuori di tanto in tanto.
Come al solito il problema e` altrove, cioe` nelle
CPU, fintanto che queste non avranno qualche cosa
per supportare un uK, non credo sia possibile
vederne uno _puro_ in giro.
bye,
-- 
piergiorgio



sei disinformato caro amico....in primo luogo non vedo perchè non si possa
citare QNX, visto che è un OS di grande successo in ambiente embedded,
militare, medico, industriale
poi c'è l'ottimo Elate della Tao Systems che è un microkernel e per di più
usa un compilatore JIT che compila sia il sistema operativo che gli
applicativi on-fly, in questo è simile a SharpOS
per quanto riguarda gli ectoplasmi, ok Hurd è fallito, ma Hurd ti ricordo
che partì col piede sbagliato e cioè basarsi su un kernel ibrido, lo stesso
kernel poi usato da XNU di Apple
Minix forse è un progetto accademico, ma suo fratello Amoeba è usato eccome
sia a livello scientifico che industriale ed è microkernel pure quello
poi c'è L4 usato come base da moltissimi progetti, ok è limitato
all'accademia ma solo perchè è usato principalmente a quel livello, in ogni
caso è usato per implementare sistemi general purpose
poi c'è NewOS che è alla base di Haiku che non è usato solo perchè lo stanno
ancora sviluppando ma di certo non si può dire che Haiku non sia un sistema
operativo general purpose
VxWorks della Wind River venduto a peso d'oro e usato commercialmente in una
marea di applicazioni, di sicuro pure nel forno a microonde di casa tua
infine MorphOS usato sui pc Pegasos ed è un sistema general purpose pure
quello
come vedi il mondo è pieno di microkernel, è solo che i tre più noti OS non
ne fanno uso....
Windows è un ibrido d'accordo ma in sostanza non risolve nessuno dei
problemi che un microkernel risolve, fare un kernel ibrido per poi
ritrovarsi ad avere gli stessi problemi di chi usa un kernel monolitico è
stupido....non è spostando in user space alcuni sottosistemi che si crea un
microkernel, il fulcro di un microkernel è senz'altro la netta separazione
dei moduli, la creazione di interfacce chiare e ben definite per comunicare
con i vari sottosistemi e l'uso dell'IPC per le comunicazioni tra
moduli....i kernel monolitici non fanno nulla del genere, mettono in user
space del codice, si ok si guadagna in termini di stabilità ma il vantaggio
finisce lì
che Linux è un monolitico lo so, questo però non vuol dire che i kernel
monolitici sono l'optimum, di certo l'essere monolitico non è una feature
di linux ma un neo, però tenendo presente che nacque nel '91 e come un OS
giocattolo non si può certo biasimare Torvalds per non aver imbroccato le
strada dei microkernel

Piergiorgio Sartor wrote:

il supporto da parte dei processori sarebbe gradito, come lo fu il supporto
al context switch in hardware e alla protezione della memoria
però già adesso si possono usare sistemi microkernel sui normali
processori...vedi QNX che gira pure sui PC, oppure MorphOS che gira sui
PowerPC o Haiku che usa il microkernel NewOS
in giro ci sono microkernel puri, il punto è che non si diffondono per lo
stesso motivo per cui Linux non si diffonde....tu puoi creare il miglior
sistema operativo del mondo ma poi se non hai vagonate di soldi per
commercializzarlo non andrai lontano, senza contare che un OS vale se hai
milioni di programmi che ci girano, infatti Linux sono molto di questo e
della mancanza di driver ovviamente
l'unico problema dei sistemi microkernel è l'eccessiva quantità di context
switch dovuta al fatto che driver, memory manager e compagnia vivono in
user mode in processi separati
però c'è da dire che i microkernel permettono di ridurre la ridondanza del
codice il che velocizza il sistema
non voglio tirarla per le lunghe, basta che scarichi QNX e lo installi su un
PC e noterai che QNX sfidando tutte le previsioni teoriche è molto più
veloce e responsivo sia di Windows che di Linux e MacOS
oppure c'è il caso di Elate della Tao Systems....lo provai anni fa perchè
l'Amiga lo vendeva come SDK per il suo nuovo AmigaOS 5....ebbene Elate
all'interno di una virtual machine, quindi non girava nativamente ma sotto
Linux, riusciva ad effettuare operazioni complesse come il ray tracing a
quasi 2 volte la velocità di Linux e Windows e questo dall'interno di una
virtual machine
questo per dire come i microkernel sono tecnologicamente migliori ma
ovviamente partire da zero nel campo dei sistemi operativi non è una cosa
fattibile e lo si vede, lo ripeto, con Linux che dal '91 ad oggi sta ancora
allo 0.7-0.8%

 finisce lì
ROTFL!! Un ottimo esempio delle chiacchiere da bar che citavi qualche giorno
fa. Ma io non ho mica capito dove hai studiato questa roba, sui bignami? Su
Wikipedia? Non è che sparando frasi a casaccio fai un discorso sensato, eh?
SALUTONI,
WindoM

 veloce e responsivo sia di Windows che di Linux e MacOS
Fa quello meglio, ma non fa tutto bene.
Potra` essere piu` "responsive" (responsivo? che parola sarebbe?),
ma ha altri grossi problemi, per esempio non regge bene nella
gestione delle risorse non pianificata.
I kernel monolitici sono piu` adatti ad applicazioni generiche.
Il problema e` che per aggirare i problemi di prestazioni
devono "tagliare" da altre parti, quindi il risultato netto
e` che un monolitico ha prestazioni _medie_ migliori.
Un uK ha dei vantaggi enormi in aree specifiche, ma non tali
da renderlo general purpose.
Questo, come detto prima, perche` l'HW e` progettato per
supportare kernel monolitici e non uK.
bye,
-- 
piergiorgio

VivaVista wrote:
:: Prestazioni e Compatibilità

Umorismo a parte, da qualche settimana sto usando Windows 2008 Server come 
Workstation.
Le prestazioni sono superiori a quelle già ottime di Windows 2003 e 
stratosferiche rispetto
a Vista. C'è da dire che comunque in Vista SP1 migliora alquanto rispetto 
alla versione originale.
Cosa "buffa": Windows 2008 riporta nelle info di versione Windows 2008 
Server Sp1....

 said:

Dipende dalla definizione di "microkernel". Se sei un purista, ovvero 
solo memoria, ipc e uno sputo d'altro, nessuno. Altrimenti si include 
osx ed nt nella categoria.
Per "di successo" comunque, qnx e` d'obbligo citarlo, perche` ha 
veramente spopolato nel suo ambito. Il problema piu` serio nei 
microkernel e` che bisogna progettarli bene, per questo motivo non 
spopolano, perche` non permette zozzate uniche e rare che si trovano in 
altri kernel.
-- 
Sensei <Sensei's e-mail is at Mac-dot-com>
Java is the most distressing thing to happen to computing since MS-DOS.
(Alan Kay)

 supportare kernel monolitici e non uK.
Se progetatto bene, il microkernel va bene anche con una cpu non 
specializzata. Ma se fai continuamente context-switch sei un kernel 
idiota.
-- 
Sensei <Sensei's e-mail is at Mac-dot-com>
Basic research is what I am doing when I don't know what I am doing.
(Wernher von Braun)

 
mmm non saprei, i sistemi operativi esistevano pure ai tempi del 4004 eppure
il 4004 non aveva le facility hardware di un Core Duo....come ho detto le
facility in questione sono il dramma di tutti i progettisti di sistemi
operativi, inutile negare che sono responsabili di un 20% dell'overhead
globale del sistema

 sensato, eh?
bene visto che sei così capace illustrami le differenze tra i vari sistemi
citati....
io con QNX ci lavoro e so di cosa parlo, mi pare che tu sai solo trollare
caro amico....
ho capito che ti sei letto il post di Torvalds di tanto tempo fa o magari
qualche articoletto su Wired dove il trombone di turno citava mirabolanti
modelli simulati che dimostrano l'inferiorità prestazionale dei microkernel
è chiaro che non sai di cosa stiamo parlando

 No, sono semplicemente piu` facili da scrivere.
Il che e` gia` un ottimo motivo (testing, anyone?)
bye,
-- 
piergiorgio

 globale del sistema
E` come avere o no la MMU, un SO gira anche senza MMU, ma
averla aiuta un pochino.
All'inizio, per es. con il 68020, la MMU (esterna) costava
(in termini di prestazioni) un botto.
Con i processori moderni la cosa si e` sistemata.
Lo stesso discorso vale per il contex switch e per l'IPC.
Esistono processori che implementano in HW la cosa, con
l'intenzione precisa di migliorare le prestazione.
Un contex switch out-of-cache costa due botti, su di un
X86 moderno, avere, per es., l'irq handler _sempre_ in
cache non sarebbe gia` male.
Altro supporto sono gli shadow register, cioe` un register
file che diventa attivo sotto irq e quindi non necessita`
il context save.
Potrei andare avanti, il senso della cosa e` che i uK sono
un bel design, sicuramente da seguire, ma fino a che non
si avra` HW adatto, vanno soggetti a problemi prestazionali.
bye,
-- 
piergiorgio

 
certamente il problema prestazionali di cui parli esiste e lo riconoscono
anche i sostenitori di questo tipo di kernel, sarebbe da sciocchi non
ammettere che un microkernel mal progettato spreca cicli di clock
e forse questo è il motivo per cui sono pochi quelli di successo....direi
che Sensei in un altro post ha colto il problema e cioè i kernel monolitici
permettono di fare porcate senza risentirne, i microkernel invece se mal
progettati danno vita a dei mostri, Mach per esempio anche se per i puristi
non è nemmeno un microkernel
però è pur vero che il gap prestazionale non è incredibilmente elevato e
comunque non tale da annullare i benefici in termini di robustezza e
sicurezza complessiva del sistema

 sicurezza complessiva del sistema
Ovviamente non vi sono differenze abissali.
Paradossalmente, io sono un sostenitore dei uK, e,
sempre paradossalmente, anche Linux viaggia in
quella direzione (per es. con cose tipo "fuse").
Pero` bilanciare sicurezza (non nei confronti
degli hacker), prestazioni, flessibilita` e
generalita`, e` piu` facile con un kernel monolitico.
Per esempio, in caso di file swap (out/in), direi
che almeno i seguenti componenti sono coinvolti:
disk drive, filesystem, page swapper.
In un uK _dovrebbero_ essere tre componenti isolati
ed indipendenti. Il che consente una notevole
modularita` e flessibilita`.
In questa situazione, pero`, la comunicazione "sicura"
tra questi moduli e`, per forza di cose, un overhead
(contex switch + IPC + contex switch).
Se i moduli li mettiamo nello stesso contesto, allora
non potremmo piu` parlare (o scrivere) di uK.
Alcuni uK commerciali raggiungono prestazioni elevate
facendo pero` alcuni compromessi in queste situazioni.
Buona Pasqua & Forza Ferrari!
bye,
-- 
piergiorgio

 piu` usati in ambito mission critical?
Bella domanda...
High Performance Robust Computer Systems (Ph.D. thesis, 2002)
http://www.ece.cmu.edu/~koopman/thesis/devale.pdf
-- 
http://ppg-anfscd.blogspot.com/

 Il che e` gia` un ottimo motivo (testing, anyone?)
Ingegneristicamente parlando il kernel monolitico va evitato come la 
peste, un codice troppo grande e` sempre incontrollabile. Un kernel 
grande puo` rompere il cazzo quando succede qualcosa di brutto, e non 
vuoi che mentre giochi al solitario il tuo pc vada in kernel panic e la 
centrale elettrica si fermi (esagero, ma fa capire l'idea).
-- 
Sensei <Sensei's e-mail is at Mac-dot-com>
43rd Law of Computing: Anything that can go wr
fortune: Segmentation violation
Core dumped

 
http://www.ece.cmu.edu/~koopman/thesis/devale.pdf
Beh in quell'ambito c'e` concorrenza per fortuna. La tesi e` un po' 
vecchiotta ma interessante.
-- 
Sensei <Sensei's e-mail is at Mac-dot-com>
Three things are certain
Death, taxes, and lost data
Guess which has occurred. (Computer's Haiku)

 osx ed nt nella categoria.
Non è questione di 'puristi'. IMHO OS X e NT puoi classificarli come 
'microkernel ibridi' (dove la definizione va presa tutta insieme come 
etichetta), ma non sono classificabili come microkernel tout-court.
-- 
Although the algorithm might be expected to yield quite a random 
sequence, reasons given below show that it is not, in fact, very good 
at all. The reader need not study this algorithm in great detail except 
to observe how complicated it is; note, in particular, steps K1 and K2. 
(D. Knuth)

 peste, un codice troppo grande e` sempre incontrollabile. Un kernel 
Ma mi prendi in giro?
Ma quando mai "un codice troppo grande".
Mai sentito parlare di modularita?
Persino linux (persino!) e` fatto a comparti stagni.
Il problema e`, come scritto altrove, che, in uK, ogni
comunicazione tra moduli e` un context switch, se vuoi
mantenere l'isolamento tra le parti.
Se metti tutto nello stesso contesto, non hai switch,
ma hai di nuovo la monoliticita` e perdi un buon livello
di protezione.
QNX funziona perche` il prodotto finale e` (in genere)
un singolo applicativo sopra il uK.
Oppure un gruppo selezionato di applicativi.
Non e` che, un volta deployed, un sistema QNX consente
a cani e porci di installarci robe sopra, e` sempre
tutto sotto il controllo del "fornitore".
In generale, ripeto.
Chiaramente la flessibilita`, modularita` e la relativa
"standardizzazione" di QNX lo rendono un prodotto vincente
nello scopo delle problematiche che si prefigge di risolvere.
Ma non e` GP.
bye,
-- 
piergiorgio

 microkernel
LOL, sei una sagoma! :)
SALUTONI e Buona Pasqua a tutti,
WindoM 

 Ma non e` GP.
Ma hai letto la mia frase? Ho detto che se conti di essere un purista 
allora GP non ce ne e` manco uno, altrimenti io includo NT e OSX. Che 
sei un purista del nanokernel? :D
-- 
Sensei <Sensei's e-mail is at Mac-dot-com>
Basic research is what I am doing when I don't know what I am doing.
(Wernher von Braun)

 
confondi i casi di utilizzo con le reali capacità del sistema....QNX gira
anche su macchinari ospedalieri e lì elabora segnali provenienti dai vari
strumenti diagnostici, fa calcoli, visualizza i grafici su un display,
suona un determinato beep per dire che il paziente è morto e un altro beep
diverso dal primo per dire che sta bene....voglio dire è in grado alla pari
di un monolitico di eseguire più applicazioni in contemporanea che svolgono
compiti diversi e questo senza problemi
se ti riferisci all'ambito real-time lì il discorso è diverso....è il campo
stesso che impone al sistema un determinato numero di task e questo perchè
non è ammesso che un task richieda più di un tot di tempo per
compiersi....però QNX si comporta bene anche negli stessi ambiti occupati
dai sistemi time-sharing
un altro esempio ancora più calzante è Elate che è usato sui telefonini e lì
non si può dire che stiamo parlando di una macchina che svolge solo 2-3
funzioni, soprattutto i cellulari moderni fanno di tutto

 svolgono compiti diversi e questo senza problemi
Lo vedi che confondi la multiprogrammazione con il concetto di GP?
SALUTONI,
WindoM 

 lo shuttle fu progettato.
Cinque sistemi 4-Pi, che costituiscono i 5 nodi del sistema fault-
tolerant dello shuttle. Sono macchine Ibm s/360 compatibili. :-)
bye G.L.
-- 
Renaissance, aka Gian Luca Sole
"E' assolutamente evidente che l'arte del cinema si ispira
alla vita, mentre la vita si ispira alla TV" - Woody Allen

 
non è che confondo, ho portato degli esempi
multiprogrammazione vuol dire che è in grado di eseguire più task in
contemporanea, general purpose vuol dire che è in grado di far girare
applicazioni che svolgono mansioni completamente differenti le une dalle
altre
non so, forse ci riferiamo al concetto di GP in modi differenti, però non
vedo quali sono queste capacità "general purpose" che un monolitico ha e un
microkernel no

 altre
No. Partendo dal presupposto che una macchina di turing e' in
grado di eseguire qualunque compito, una macchina *fisica* e'
accreditata come "General Purpose" quando e' in grado di svolgere
altrettanto efficientemente compiti di nature anche completamente
differenti. NON e' lapalissianamente in discussione se sia in grado
o no di eseguire tali compiti (che' anche un processore con due
istruzioni - "add one" e "jump if zero", puo' eseguire tutti gli
algoritmi possibili), ma COME li esegue.
Nessuno ti impedisce di usare una macchina come un ibm 7090 per
compiti business, o un ibm serie 1400 per compiti di tipo scientifico,
ma il fatto e' che la macchina sara' molto meno efficiente nei compiti
per i quali non e' stata appositamente progettata e ottimizzata. Se
invece prendi un ibm s/360, che e' la prima famiglia di computer GP
di ibm... va bene un po' per tutto. :-)
Ok, qui gia' mi contesterai che si sta parlando di sistemi operativi e
non tanto di architetture, ma il discorso e' analogo: nessuno
si sogna di utilizzare linux o windows per applicazioni soft/hard
raltime, cosi' come un sistema operativo realtime mal si adatta
per utilizzo diversi dallo scopo per il quale e' stato progettato e
sviluppato.


 
ma io sono d'accordo su questo, se leggi i miei post precedenti infatti ho
riconosciuto ampiamente il gap prestazionale che è presente nelle
architetture microkernel
la mia risposta era alla tesi di fabio e cioè che un sistema microkernel, si
parlava di qnx in particolare, non è general purpose e questo concorderai
con me che è falso

 tolerant dello shuttle. Sono macchine Ibm s/360 compatibili. :-)
Hai informazioni? IBM s/360 ?! :D


 Linux/Windows/MacOS
Elenca le 'ben note porcate'.
-- 
Let us change our traditional attitude to the construction of programs. 
Instead of imagining that our main task is to instruct a computer what 
to do, let us concentrate rather on explaining to human beings what we 
want a computer to do. (Donald Knuth)

 performanti di altre è vero
Toh, una macchina di turing.
-- 
My duty as a teacher is to train, educate future programmers.
Niklaus Wirth

 Hai informazioni? IBM s/360 ?! :D
Si', nulla di strano: hanno potuto re-impiegare esperti programmatori
ibm e nasa. ;-)


 
infatti....la macchina di Turing è la macchina universale e general purpose
per eccellenza

 
la lista è troppo lunga, richiederebbe la stesura di un'enciclopedia :D
ma se fai un giro su Frsirt riesci a capire di che porcate parlo

 
ma non saranno morti di vecchiaia ? :D

 concorderai con me che è falso
Questa non è la mia tesi, la "mia" tesi (non che mi sia inventato niente) è
che non esistono sistemi microkernel puri general-purpose perché (almeno
fino ad ora) si sono rivelati troppo difficili da progettare senza
conoscerne a priori gli usi e il tipo di applicazioni che dovranno far
girare (nota che questa clausola collide col concetto di general-purpose
comunemente accettato e correttamente esposto da Renaissance, anche se
sembri non aver colto le differenze con la tua idea).
E no, QNX non è general-purpose.
SALUTONI,
WindoM 

Fabio Fioretti - WindoM wrote:

ma se QNX lo fai girare su un PC con un browser web, media player, flash
player, giochini vari, driver 3d accelerati, web server, mail reader,
ecc....
non capisco cosa intendi dire, sul serio, ma qualunque OS va progettata
tenendo in mente l'uso che andrà fatto....come dici tu allora nemmeno
Windows è general purpose perchè il suo scheduler time-sharing gli
impedisce di svolgere mansioni in sistemi real-time

 impedisce di svolgere mansioni in sistemi real-time
Ti suonerà paradossale ma i sistemi real-time sono tipicamente restrittivi
sotto svariati punti di vista (CPU scheduling, memory management, I/O) e
quelle restrizioni li rendono strutturalmente poco adatti ad eseguire
applicazioni "generiche", general-purpose appunto, non specificamente mirate
al segmento real-time
E se è vero che i sistemi general-purpose possono avvantaggiarsi
dall'integrazione di alcune caratteristiche dei real-time, tipicamente non è
vero il contrario.
Comunque il concetto di OS general-purpose non me lo sono inventato io
qualche post fa, eh, basta fare una ricerchetta. :)
SALUTONI,
WindoM 

Fabio Fioretti - WindoM wrote:

i sistemi real-time danno la possibilità allo sviluppatore di impostare
delle restrizioni di tempo nell'esecuzione dei task
è chiaro che se prendi un hardware X e ci fai un girare un processo P1 che
consuma tutte le risorse di X non puoi pretendere di far girare
contemporaneamente pure il processo P2
ciò non toglie però che basta non usare le facility offerte dallo scheduler
real-time, non impostando una deadline per l'esecuzione dei processi ed
ecco che il sistema si comporterà come un banale sistema time-sharing
piuttosto è invece complicato trasformare un sistema time-sharing in uno
real-time, per esempio nel caso di RTLinux si è dovuto modificare parecchie
parti dell'architettura di sistema

 altre
Vedi risposta di Renaissance.
SALUTONI,
WindoM 

 parecchie parti dell'architettura di sistema
IMHO, è anche perché è difficile coprire applicazioni real-time senza
scoprirsi sul fronte general-purpose. E perché, in generale, un OS
general-purpose è dannatamente più complesso di un sistema real-time.
SALUTONI,
WindoM 

 general-purpose è dannatamente più complesso di un sistema real-time.
Perche` ora si scivola sul RT non si sa --- a parte che non si 
distingue tra hard e soft real time, ma vabbe`.
Applicazioni hard real time nel mondo utente normale non ce ne sono 
molte. Mi vengono in mente acquisizioni dati come MRI, 
Elettrofisiologia, CT, musica suoni & luci, ma non sono "hard". 
L'utente medio non controlla una centrale termoelettrica :D
-- 
Sensei <Sensei's e-mail is at Mac-dot-com>
$ cd /pub
$ more beer

 Benchmark, grazie, roba multimediale possibilmente. :)
Eh appunto, sicuro che sia peggio? (o meglio) E che le statistiche 
siano poi analizzate, che con la media ci si sciacquiamo i piedi! :)
-- 
Sensei <Sensei's e-mail is at Mac-dot-com>
Basic research is what I am doing when I don't know what I am doing.
(Wernher von Braun)

 strada dei microkernel
Quella sulla natura dei kernel è una discussione simile a quella sul 
sesso degli angeli. Ma chissenefrega! Il kernel è solo il nocciolo del 
sistema, ma la maggior parte dei programmi moderni si deve appoggiare a 
strutture a livello molto più alto. E sono quelle che devono essere 
iper-ottimizzate, non certo il kernel, che ormai può contare su 
processori iperveloci.
p.bes

mmm non ti seguo
il discorso time-sharing/real-time che riguarda solo ed esclusivamente le
politiche di scheduling l'ho inserito perchè è di fatto la più grande
differenza che c'è tra i sistemi tipo Windows/Linux e QNX e soci
riguardo l'essere general purpose, QNX lo è e questo perchè fa tutto ciò che
a un OS è richiesto di fare e cioè astrarre l'hardware, multiplexarlo,
permetterne l'accesso a chi lo richiede, implementare politiche per la
gestione dei cicli CPU, della memoria, dell'IO e della comunicazione tra
processi
il discorso che facevi riguardo la valutazione delle risorse hardware
riguarda i casi d'utilizzo....anche Linux se dev'essere usato in un missile
Tomahawk bisogna che la CPU sia sufficiente potente per garantire
l'esecuzione in tempo utile di tutti i task ed è chiaro che lo swapping va
eliminato perchè come ben sai lo swapping non ha tempi certi e di fatto
sballa ogni previsione riguardo l'esecuzione dei job
un microkernel di fatto è diverso da un monolitico solo per le sue politiche
interne, per come decide di suddividere i moduli, per come decide di far
comunicare i vari sottosistemi, ma per quanto riguarda la capacità di
eseguire compiti riesce a fare nè più nè meno che ciò che fa un monolitico
per quanto riguarda QNX non è che devi disabilitare il suo scheduler o
cambiarlo, semplicemente le applicazioni decidono di non richiedere al
sistema di eseguirle in un tempo prefissato...mi spiego...se prendi QNX e
lo installi sul tuo PC noterai subito che il media player usa le capacità
dello scheduler real-time perchè ovviamente per riprodurre il suono è
necessario che i tempi siano certi ( nel caso dei sistemi come Windows il
suono non va a scatti perchè il processore è infinitamente più potente di
quanto i task necessitino ), mentre il wordprocessor non richiede al kernel
una quantità di tempo CPU obbligatoria e quindi di fatto viene schedulato
come i normali processi in un sistema time-sharing
ma tutto ciò non aggiunge o sottrae niente alle capacità del kernel, il
quale ripeto è general purpose perchè può semplicemente svolgere qualunque
compito gli venga assegnato....non è che il kernel viene modificato per
girare nel missile Cruise, poi deve subire una nuova modifica per entrare
nel microonde e un'altra modifica per essere installato su un
satellite....il sistema è sempre quello, non cambia, sono gli applicativi
che cambiano, ma questo succede pure nel mondo PC

 satellite....
Hai citato tutti casi d'uso di nicchia, tutt'altro che general-purpose. O
forse volevi dire che il kernel che gira sul cellulare è lo stesso che gira
sul supercomputer? :-O
SALUTONI,
WindoM 

 quanto i task necessitino )
Fantastico, dimostri di non conoscere affatto Windows.
Cito Mark Russinovich in merito al kernel di Windows Vista:
"When a multimedia application begins playback, the multimedia APIs it uses 
call the MMCSS service to boost the priority of the playback thread into the 
realtime range, which covers priorities 16-31, for up to 8ms of every 10ms 
interval of the time, depending on how much CPU the playback thread 
requires. Because other threads run at priorities in the dynamic priority 
range below 15, even very CPU intensive applications won’t interfere with 
the playback."
http://technet.microsoft.com/en-us/magazine/cc162494.aspx
http://blogs.technet.com/markrussinovich/archive/2007/08/27/1833290.aspx
SALUTONI,
WindoM 

 centrale termoelettrica :D
Il multimedia (anche non così) estremo si avvicina parecchio ai requisiti 
realtime, però.
SALUTONI,
WindoM 

 poi analizzate, che con la media ci si sciacquiamo i piedi! :)
No, non sono sicuro, ma è difficile fare statistiche per un eventuale
raffronto tra OS general-purpose a microkernel puro contro monolitici/ibridi
se i microkernel GP testabili non esistono. :)
Comunque ha ragione Paolo Besser quando dice che discutere di kernel 
micro/macro/nano/ibrido ha molto meno senso ora rispetto a 10-15 anni fa.
SALUTONI,
WindoM 

 sei un purista del nanokernel? :D
Non capisco la frase "io includo NT e OSX", in cosa
li includi? In uK od in GP? Od altrove?
Scherzando, pero`, il nanokernel per C64 devo
ancora averlo in giro...
GP, come scritto da qualcun'altro, e` un SO che fa
decentemente bene tutto, ma niente in maniera ottimale.
Dall'altro canto, un kernel "specifico", fa una cosa sola,
ma in maniera dannatamente perfetta (si fa per dire).
L'esempio (esempio!) RT voleva indicare proprio questo:
si puo` avere un kernel (o uK) specifico per soddisfare
questo tipo di richiesta (che Unix in generale non fa),
ma che non e` in grado di fare altro "decentemente".
I uK si prestano magistralmente alla customizzazione,
proprio per la modularita`.
Poi definire il tuo sistema e poi (dopo!) organizzare
il kernel (uK, nel caso) in maniera ottimale.
In un sistema GP, invece, il kernel deve poter funzionare
_prima_ di conoscere il sistema che avra` sopra, in
quanto questo cambia dinamicamente, in maniera, tra
l'altro, non solo imprevedibile, ma anche assolutamente
incontrollabile.
Detto altrimenti, un kernel e` GP se non deve preoccuparsi
_apriori_ di come gli applicativi interagiranno, mentre
un kernel e` "specifico" se ha (se deve avere) questa
informazione prima (o dovrebbe avere prima).
Insomma e` una questione di flessibilita` verso ottimizzazione,
non per niente si cade subito nel RT, con questi discorsi.
bye,
-- 
piergiorgio

 per eccellenza
Grazie, non lo sapevamo.
-- 
cc = callcc {|cc| cc.call cc}; cc.call cc

 ma se fai un giro su Frsirt riesci a capire di che porcate parlo
Guarda, io voglio che ne parli *tu*. Tu lo hai detto, tu motivi.
Già il fatto poi che metti sullo stesso piano tre sistemi così
pesantemente diversi (senza entrare per inciso in giudizi di merito...)


 requisiti realtime, però.
Piu` o meno. Se tu acquisisci i dati con 1ms di ritardo non e` lo 
stesso di ritardare di 1ms l'attuatore delle barre di sicurezza in una 
centrale :)
-- 
Sensei <Sensei's e-mail is at Mac-dot-com>
If you get this in less than 10 seconds, then you are a certified geek.
"FEATUR"
(License plate seen on an old Volkswagen Beetle)

 fa.
Beh Linus non la pensa cosi`, "il microkernel fa schifo". Personalmente 
mi piace moltissimo :)
-- 
Sensei <Sensei's e-mail is at Mac-dot-com>
Research (n.): a discovery already published by a chinese guy one month
               before you, copying a russian who did it in the 60s.

 non per niente si cade subito nel RT, con questi discorsi.
Come ho detto in un altro post, "general purpose" dipende dalla 
diffusione nel mercato di massa. Se QNX fosse usato come OSX (windows 
e` irraggiungibile) allora lo definiremmo GP.
Anche perche` il C64, l'Apple I e II, l'Amiga erano GP, nonstante la 
chiusura estrema dell'hw dei tempi.
-- 
Sensei <Sensei's e-mail is at Mac-dot-com>
It is a very sad thing that nowadays there is so little useless information.
(Oscar Wilde)

 WindoM
appunto, dice "to boost the priority", perchè come ben sai Windows usa uno
scheduler time-sharing priority driven, beh pure Linux del resto....vuol
dire che non tutti i task sono nati uguali e alcuni vanno eseguiti più
spesso, ma è molto diverso dal concetto di realtime dove il task chiede
all'OS: "ce la fai ad eseguirmi in 42ms?" se si bene, se no dillo che io
non parto
il media streaming in Windows è solo trattato come task a massima priorità
ma questo non ha nulla da spartire col realtime, tant'è che basta mettere
in esecuzione un numero elevato di task prioritari e la riproduzione di
filmati o musiche comincia ad andare a scatti

ok ammettiamo che hai ragione
qual'è questo concetto di OS general purpose?

 
multimedia estremo?
oh ma che scherziamo? un sistema hard real-time come QNX ha tempi certi,
misurati in microsecondi, il concetto di "estremo" invece sottintendete
un'aleatorietà che è intollerabile nel caso del realtime

 un'aleatorietà che è intollerabile nel caso del realtime
Un sintetizzatore/decoder audio e` RT-hard, se salti
un campione senti subito un "click".
Un decoder video e` RT, non hard, visto che e`
ancora lecito il frame drop/repeat.
Se hai due task, uno per l'audio e l'altro per il
video, quindi un sistema multimediale, sei subito
nel caso RT-hard, con tanto di problematiche
deadline e simili.
bye,
-- 
piergiorgio

 chiusura estrema dell'hw dei tempi.
Si, appunto perche` non e` definito prima quali
applicativi verranno fatti girare, in quale ordine...
Non e` il close-to-the-metal l'importante, ma la
predisposizione o predisponibilita` del SO.
bye,
-- 
piergiorgio

Piergiorgio Sartor wrote:

si si sono d'accordo, ma non capisco il senso dell'affermazione di fabio e
cioè "i microkernel non sono general purpose"
a me francamente sfugge la possibile motivazione

 a me francamente sfugge la possibile motivazione
Non credo lo abbia affermato come "definizione".
Semplicemente i vantaggi dei uK si sentono nelle
applicazioni specifiche, mentre per situazioni GP
si sentono di piu` gli svantaggi.
Se uK fosse la pietra filosofale dei SO (o kernel),
allora sarebbe gia` ampiamente utilizzata da tutti.
Purtroppo, tra difficolta` implementative e colli
di bottiglia, non si riesce a far fare loro tutto
quello che si vuole indiscriminatamente, ma, per
ora, solo compiti ben definiti.
bye,
-- 
piergiorgio

 :)
Chiaro che no ma, se la musica o i filmati scattano, agli utenti poi lo 
spieghi tu. :)
SALUTONI,
WindoM 

 cioè "i microkernel non sono general purpose"
Continui a generalizzare mie affermazioni molto più circostanziate.
Vedi la risposta di Piergiorgio a questo stesso tuo post.
SALUTONI,
WindoM 

 qual'è questo concetto di OS general purpose?
Dai, rileggi il thread, puoi farcela da solo. :) E' stato descritto 3 o 4 
volte, e da persone diverse.
SALUTONI,
WindoM 

 ma questo non ha nulla da spartire col realtime
E dove avrei scritto il contrario?
SALUTONI,
WindoM 

 piace moltissimo :)
Si, pure a me, e mi piace pure discuterne nonostante abbia meno senso, tiè. 
:)
SALUTONI,
WindoM 

 spieghi tu. :)
E` colpa dei comunisti :D

 Si, pure a me, e mi piace pure discuterne nonostante abbia meno senso, tiè. :)
Beh ogni tanto discutere del sesso degli angeli fa bene!
-- 
Sensei <Sensei's e-mail is at Mac-dot-com>
UNIX: The world's first computer virus.
(The UNIX Haters Handbook)

 di uK, ma di framework per uK.
Se un OS non fornisce limiti allo sviluppo di applicativi, nel senso 
descritto sopra, e` allora GP.
-- 
Sensei <Sensei's e-mail is at Mac-dot-com>
UNIX: The world's first computer virus.
(The UNIX Haters Handbook)

 e` GP, mentre QNX si.
Occazzo, bisogna dirlo alla Tektronix che mi ha piazzato Windows2000 dentro
al 5140...
Io l'avevo pure reso noto al commerciale quando venne da queste parti: mi
davano le specifiche dell'hw e gli scrivevo il driver per Linux ;-P... Ma
non volle fare carte....
-- 
                          | rombando dal loro luogo
\|/ ____ \|/   \ ||_|     | d'origine, i buchi neri 
"@'/ ,. \`@"    \|| |     | tracannavano energia e da
/_| \__/ |_\ Vax Headroom | bolle frattali nascevano
   \__U_/                 | 

ah ecco, però Fabio ha detto in post precedenti che microkernel != general
purpose o no?
comunque, sul fatto che non si riesca a far fare ai microkernel tutto ciò
che si vuole ho molti dubbi
gli ambiti più complessi sono già coperti dai microkernel, figuriamoci
l'ambito desktop dove ci sono da fare giusto 4 cose in croce
riguardo le performance, i colli di bottiglia, ecc... dipendono
esclusivamente dall'implementazione....due microkernel molto noti sono QNX
e Elate ed entrambi sorpassano i kernel monolitici in prestazioni e
velocità di risposta
il discorso dei context switch e delle penalties associate è legato
strettamente ad una visione "monolitica" dei kernel....se si vuole
implementare un microkernel tenendo in conto tutte le tipiche strategie dei
kernel monolitici si finisce col produrre un mostro e su questo sono
d'accordo con voi due, vedi Mach per esempio
se viceversa si tengono in conto le debolezze insite nell'architettura
microkernel e ci si lavora su, si ottengono ottimi risultati....come si
risolve il problema del context switch? semplice si elimina la differenza
tra modalità utente e supervisore....è l'unico modo? no, è sicuramente una
scelta al limite e molto ardita ed è stata fatta da Elate e compensata in
un modo assai elegante e cioè tutto il codice è scritto in VP, una cosa
simile a .NET, è managed ed è verificabile al momento della
traduzione....in sostanza niente puntatori vaganti, niente accessi ad aree
di memoria altrui, niente buffer overflow....
non è l'unica soluzione e QNX per esempio non l'ha mai usata, QNX usa il
solito meccanismo di protezione offerto dalla MMU, ecc....è più lento di un
monolitico? certo ma di poco e questo perchè è stato fortemente
ottimizzato, cosa possibile con i microkernel ma estremamente complessa con
i monolitici, il memory footprint è ridotto all'osso, le stesse routine non
sono ripetute milioni di volte
detto ciò è chiaro che le difficoltà implementative ci sono, è
un'architettura molto più complessa ma i vantaggi sono indubbi....riguardo
il loro utilizzo, ripeto, parlo perchè l'ho provato e ti dico che uso QNX
per gli usi più disparati non ultimo su un PC Dell, ovviamente mancano
molti software importanti ma di certo non ci sono problemi a farci girare
un word processor o un programma di disegno

 specificare a priori il massimo della memoria che si andra` ad occupare
MacOS fino al 9x ?
-- 
Ciao, Guglielmo.

 un word processor o un programma di disegno
Ancora, nessuno dice che "c'e` un problema", ma
sicuramente si fa meglio con un altro SO.
bye,
-- 
piergiorgio

 sicuramente si fa meglio con un altro SO.
ecco questo è il punto, perchè si fa meglio con un altro OS? cos'ha un
monolitico di migliore rispetto ad un OS microkernel per cui Word o
OpenOffice possono girarci meglio?
comunque per tagliare la testa al toro puoi sempre installarli QNX sul PC e
vedrai con i tuoi occhi quello di cui parlo

 Microkernel puro, includerei IPC, MMU, e altre minime parti. Se le 
Allora, IPC, dunque ogni volta che il filesystem deve
chiedere un blocco al disk driver, si deve prima entrare
in kernel space, poi uscirne, poi, alla risposta, rientrarci
e poi uscirne di nuovo (perche` FS e driver sono in user
space). In piu` il driver dovra` fara ancora una capatina
in kernel space per via degli irq del device.
Escludendo l'applicativo che accede al file, quanti contex
switch conti tu?
Quanti ne conti se fileststem e disk driver stanno tutti e
due dentro il kernel?
 > Si ma e` GP. Mi spiego: richiedere a priori ad una applicazione 
alcune > informazioni e` possibile, nulla lo vieta, e non rende meno GP 
un OS.
Come no? Dipende da cosa richiedi, ovviamente.
 > Del resto non mi ricordo bene chi, ma c'era un OS dove si poteva
 > specificare a priori il massimo della memoria che si andra` ad
 > occupare (e non parlo dei .COM del DOS). Ma la memoria mi fallisce
 > ora...
Non giriamo le cose, un conto e` che l'applicativo _possa_
dichiarare a priori qualcosa, diciamo che fa un favore al SO.
Un conto e` che debba.
Un altro conto e` che sia limitato dal kernel in questo.
Esempio, e` diverso (alla partenza):
1) poter dichiarare che servono 10MB di RAM
2) _dover_ dichiarare che servono 10MB di RAM
3) chiedere al kernel della RAM e sperare che arrivino 10MB
La cosa non e`, in generale, cosi` semplice come sembra.
Ogni soluzione ha i suoi pro ed i suoi contro.
Considera Linux. Nonostante gli sviluppatori
non siano proprio amanti del uK, si stanno
comunque muovendo in quella direzione.
L'USB e` gestito in parte in user space (libusb),
similmente il firewire (libraw1394).
Con fuse hai FS in user space.
La tendenza generale e` spostare compiti in user
space, qualora non sia proprio necessario siano
in kernel, oppure fornire agganci per componenti
in user space, come il driver generico che stanno
implementando.
Nonostante questo, altri blocchi sono inchiodati
nel kernel, perche` metterli fuori sarebbe un
suicidio prestazionale.
bye,
-- 
piergiorgio

ah mi è sovvenuto un dubbio e per questo posto di nuovo
esattamente quando parliamo di microkernel ci stiamo riferendo alla stessa
cosa? si intende che quando parlo di microkernel mi riferisco all'insieme
di codice in kernel mode e i relativi server in userspace tali da dare al
microkernel in questione le capacità tipiche di un os monolitico
insomma parlo del microkernel + networking server + filesystem server,
ecc... insomma le cose che servono affinchè il sistema abbia un minimo di
funzionalità....non mi sto riferendo al solo microkernel vero e proprio

 vedrai con i tuoi occhi quello di cui parlo
Veramente io lo ho usato e so di cosa parlo.
Del fatto che non e` GP, molto semplice.
bye,
-- 
piergiorgio

 
e in cosa non sarebbe general purpose?
non per dire ma l'unico problema che mi viene in mente è lo scheduler
real-time, problema peraltro risolto dall'utilizzo di uno scheduler APS
francamente non capisco cos'è che un monolitico dovrebbe saper fare e un
microkernel no
se si dice che QNX non è general purpose vuol dire che c'è almeno una cosa
che Windows può fare e QNX no...qual'è?

 che Windows può fare e QNX no...qual'è?
Non e` cosa, ma come!!!
E non e` "puo`"/"non puo`", ma "bene" e "male".
Ci sono situazioni, di uso comune, in cui QNX
non ha senso usare, se ti va, perche` non e`
stato progettato per quello.
bye,
-- 
piergiorgio

 non volle fare carte....
L'oscilloscopio che io ricordi fu il primissimo videogame!
-- 
Sensei <Sensei's e-mail is at Mac-dot-com>
43rd Law of Computing: Anything that can go wr
fortune: Segmentation violation
Core dumped

On 2008-03-28 11:22:52 +0100, Guglielmo 
<mmemmoTO...@tiscali.it.invalid> said:

Lo prendo per buono, prima che fosse Unix (ehem, che fosse il 10.4) OSX 
lo guardavo storto.
-- 
Sensei <Sensei's e-mail is at Mac-dot-com>
43rd Law of Computing: Anything that can go wr


 suicidio prestazionale.
Dipende, sinceramente linux non e` il non plus ultra di software, non 
lo prenderei come paragone. Ho letto il kernel di Haiku (newos) e mi 
piace molto.
Alla fine, di che prestazioni parliamo? Perche` OSX a me va bene su un 
pc di 3 anni fa, con leopard sopra. Sicuramente non gioco, forse questo 
mi da un "bias".
-- 
Sensei <Sensei's e-mail is at Mac-dot-com>
43rd Law of Computing: Anything that can go wr


 lo guardavo storto.
Ehmmm... non era ancora nemmeno X. Parlo di quello che con l'avvento di X,
venne definito Classic.  Potenza del cooperative ;)
-- 
Ciao, Guglielmo.

 mi da un "bias".
Proprio di questo.
Cioe` che tu non giochi, ma qualcun altro si.
Magari un altro ci fa musica, un altro ancora
usa blender, un terzo (o quarto) ci guarda i DVD,
e magari, a rotazione, cambiano l'attivita`
(il giocatore fa musica, il musicista passa a
blender, etc.).
Fare un uK che sopporti una cosa del genere e`
piu` _difficile_ che fare un monolitico.
Tradotto significa che avra` problemi, a scelta,
tra prestazioni, affidabilita`, etc.
D'altro canto, se devi fare solo una cosa alla
volta, magari il uK va meglio.
bye,
-- 
piergiorgio

Piergiorgio Sartor wrote:

quindi convieni che è solo questione di come determinati task possono essere
svolti dai microkernel rispetto ai monolitici
quindi è logico affermare che è falsa l'affermazione secondo cui un
microkernel non è general purpose....
del resto la storia dell'IT è piena di microkernel general purpose, basti
pensare a Mach, L4, Nucleus, Chorus, ecc...
dunque siamo d'accordo che il problema è solo nel come vengono implementate
determinate feature?
bene quindi dovrebbe essere chiaro che microkernel e general purpose non
sono termini mutuamente esclusivi

 sono termini mutuamente esclusivi
Certo che no, puoi` usare un uK in un caso GP, male, oppure
un SO GP, in applicazioni embedded, altrettanto male.
Se, pero`, hai un ampio spettro di casistiche che devi
soddisfare, hai piu` probabilita` di farlo mediamente
bene con un monolitico, che con un uK.
Se invece hai un caso specifico, magari il uK puo` essere
una scelta migliore.
E la ragione e` l'architettura, perche` se da un lato (uK)
consente una adattamento maggiore, lo fa ad un prezzo,
prestazionale o come ti pare, ma la cosa si paga.
In altri termini, there is not such a thing like a free lunch.
Persino l'uso della MMU, in un monolitico, ha un costo
prestazionale notevole.
Se ne puo` fare a meno, ma si puo` rischiare di avere
un sistema _general purpose_ senza MMU?
bye,
-- 
piergiorgio

 questo modo i VivaVista si moltiplicheranno a dismisura.
Se non erro, in vista hanno gia' eliminato il sottosistema win api16.
BTW, a mio modo di vedere, il progetto NT nasce come microkernel
ibrido + sottosistemi d'ambiente proprio per coniugare compatibilita',
prestazioni, protezione, agevole scalabilita', e a mio giudizio il
risultato e' stato raggiunto efficacemente ed elegantemente (grazie
al talento di David Cutler, che ha importato nel kernel NT molti dei
concetti di VMS).
bye G.L.
-- 
Renaissance, aka Gian Luca Sole
"E' assolutamente evidente che l'arte del cinema si ispira
alla vita, mentre la vita si ispira alla TV" - Woody Allen

 ma non saranno morti di vecchiaia ? :D
Ma nooo... s/360 sopravvive fino ai giorni nostri nei sistemi
z/series. ;-)


 questo mi da un "bias".
E' ibrido... c'e' molta roba in kernel space. :-)


 venne definito Classic.  Potenza del cooperative ;)
Si l'avevo capito. Beh, hai spiegato il mio ricordo letto chissa` dove, 
pc magazine, mc microcomputer... bho! Da qualche parte l'avevo letto :)


 volta, magari il uK va meglio.
Bho, OSX va bene per tutte queste cose, ma sui giochi non so: la 
piattaforma che uso e` PSP, e quella del mercato a parte le console, e` 
windows.


 E' ibrido... c'e' molta roba in kernel space. :-)
Eh vabbe`, io qnx non l'ho! :D


 Accade piu` facile con un kernel monolitico :)
Piu' facile, non penso, al limite uguale (stesso contesto, senza
protezione della memoria, che sia user space o kernel space).
Si ritorna a bomba: e allora, che vantaggio c'e', in termini di
protezione? :-)


 Beh per me un 10% di prestazioni in meno vale un microkernel. Insomma, 
Vale per cosa?
Se entrembi funzionano, non mi interessa di avere
l'architettura "elegante".
E poi che prospettive ci sono?
E se poi non e` il 10%, ma il 20%?
bye,
-- 
piergiorgio

 
Haiku

 Haiku
Si, ma non e` GP... :-)
Per _design_ e` un SO desktop e non sarei
sicuro sia neanche uK.
bye,
-- 
piergiorgio

 Haiku
Da una mailing list:
     * From: Stephan Assmus <superstippi@xxxxxx>
     * To: haiku-development@xxxxxxxxxxxxx
     * Date: Tue, 11 Mar 2008 09:58:06 +0100
 > I understand that Haiku has microkernel architecture and it is different
 > than a linux
Actually, it is not a micro kernel. It is a modular kernel, ie everything
except core services are add-ons. But not a micro kernel, add-ons (also all
drivers) run in the kernel address space.
ops...
bye,
-- 
piergiorgio

 
ma alla base c'è NewOS che è un microkernel
l'unico caso in cui un microkernel non è GP è quando gli mancano gli
opportuni application server
del resto se L4 viene definito "General Purpose microkernel" un motivo ci
sarà no?
del resto non c'è bisogno di smuovere Silberschatz, basta andare su
Wikipedia e c'è scritto "A basic set of servers for a general-purpose
microkernel includes file system servers, device driver servers, networking
servers, display servers"
per questo ho detto, se parliamo solo del core del microkernel allora non è
GP, perchè non può esserlo, gli mancano le gambe, le braccia, gli occhi e
tutto il resto
se parliamo di un microkernel + application server + tutto il resto come QNX
allora è GP...poi si può discutere sulle performance, l'architettura,
quanto è difficile programmare su un OS simile, ecc... ma dire che un
microkernel non è GP è assolutamente falso

 microkernel non è GP è assolutamente falso
Ancora, quando mai e` stato detto questo?
Da quale affermazione hai potuto dedurre cio`?
Il fatto e` che un uK GP NON FUNZIONA!
Nessuno ha detto che non e` possibile o che e`
mutualmente esclusivo.
Quello che ti sto (stiamo) ripetendo ad infinitum e`
che quando ti imbarchi in un uK non riesci piu` a
far bene in un largo spettro di casistiche, quindi
non si riesce ad usare BENE in un contesto GP.
E chiaro?
bye,
-- 
piergiorgio

 ma alla base c'è NewOS che è un microkernel
Dimenticavo.
Non vuol dire proprio nulla che alla base ci sia
un uK. Nel momento in cui hai la possibilita` di
scegliere dove mettere i driver e li metti in
kernel space, anche se la base e` uK, il risultato
non e` piu` uK.
E questo e` alla base di moltissimi uK commerciali,
dove viene messa a disposizione un'infratruttura uK
per costruire sopra un "middleware" kernel (SO), che,
se in user space, mantiene il uK, altrimenti lo
trasforma in qualcosa che non e` piu` uK.
bye,
-- 
piergiorgio

 
d'accordo ma non vuol dire che un microkernel non è capace di svolgere
attività general purpose
riguardo Haiku è vero quello che dici ma ti ho fatto notare che è basato su
un microkernel proprio per dimostrare che un microkernel può operare in un
ambito general purpose, sarà facile sarà difficile non c'interessa,
l'importante è che un microkernel può fungere da base per un sistema
operativo per desktop/server/consolle e quant'altro
non puoi dire che un microkernel non può fungere come kernel general
purpose....ti ripeto quest'affermazione implica che data un'attività X che
si può espletare su un OS monolitico, la stessa attività non può essere
svolta ad un microkernel....semplicemente non c'è task che un monolitico
possa svolgere e un microkernel no....
quindi l'affermazione "Il fatto e` che un uK GP NON FUNZIONA!" è
sbagliata...
ti ripeto se non riesco a convincerti io, fatti un giro su google, cerca i
paper tecnici riguardo vari microkernel e vedrai scritte cose del
tipo "Grasshopper is a general purpose microkernel"
il fatto che QNX per esempio non fosse general purpose ( cosa non vera
ovviamente ) non implica che l'intera categoria dei microkernel non può
essere general purpose
non dire che non l'hai mai detto, se tre post più indietro hai prima detto
che microkernel != general purpose, poi hai detto che si può fare ma che è
più complicato, poi hai detto che è un problema di performance...insomma
prendi una decisione

Piergiorgio Sartor wrote:

è vero che Haiku non è microkernel, almeno non nel senso pieno del termine,
ma l'unica differenza che ha rispetto ad un normale microkernel è il fatto
che i driver e gli altri server fondamentali girano in kernel space
per il resto l'architettura è quella tipica di un microkernel...del resto
Mach faceva esattamente lo stesso ed è definito microkernel, NT lo stesso è
stato definito in 10 modi diversi
comunque sia se sviluppi un OS al di sopra di un microkernel, l'unico a
girare in kernel space è proprio il microkernel, occhio che questa cosa è
stata fatta, innestando Linux su L4....
quindi dire che se un OS si basa su un microkernel ma poi non ne segue la
filosofia diventa un monolitico è errato....è un kernel ibrido, nè più nè
meno....la cosa che ci interessa però è che alla basa c'è un microkernel e
che questo microkernel permette la costruzione di un sistema general
purpose, il che vuol dire che un microkernel può svolgere attività tipiche
di un OS general purpose

 tipo "Grasshopper is a general purpose microkernel"
Tu hai mai scritto o progettato od usato
"professionalemente" un uK? In che ambito?
Quando lo avrai fatto torna qui a racconarci
come e` andata, fino a quel momento cerca di
non riportare cose che hai letto sul giornalino
del piccolo kernel hacker, per favore.
Tra l'altro, sempre a proposito di lingua,
"general purpose microkernel" e` diverso da
"microkernel general purpose".
bye,
-- 
piergiorgio

 filosofia diventa un monolitico è errato....è un kernel ibrido, nè più nè
Ma tu sai leggere?
Ho scritto che diventa mono, per caso (se lo ho
fatto, ma non mi pare, e` uno sbaglio)?
Ho scritto che NON E` PIU` MICROKERNEL!
Per far diventare un uK general purpose, bisogna
snaturarlo, Haiku, da te citato, e` la dimostrazione
pratica di cio`.
Per farlo FUNZIONARE devono mettere roba in kernel
space, affianco a quello che porta il uK.
Sai dirmi perche` fanno cosi?
Se sai la risposta, avrai anche capito che un uK
NON FUNZIONA in ambito GP.
Ma forse ci capiamo male sul termine "funzionare".
Ovviamente, funziona, nel senso che gira e fa quello
che deve fare.
Il termine lo ho inserito appositamente, in modo da
separare meglio i concetti, tra funziona bene e
funziona male.
Dove bene e male, possono essere: veloce/lento,
sicuro/insicuro, etc.
bye,
-- 
piergiorgio

 a bomba: e allora, che vantaggio c'e', in termini di protezione? :-)
se il server va a puttane, viene riavviato dal kernel, se va a puttane il 
modulo kernel space, va giù tutto
in linea di principio. ovviamente se il server è il process manager sono 
cazzi (come ho sperimentato su minix, divertente :D)

 
ecco lo vedi che dici cose contradditorie
qui dici "Per far diventare un uK general purpose, bisogna snaturarlo",
quindi trasformalo in qualcosa che non è microkernel, lo hai detto tu prima
proprio citando il caso Haiku
poi però nell'altro post dici
"> non puoi dire che un microkernel non può fungere come kernel general
Sono arcistufo di ripeterti che non e` questo il discorso."
intendendo che non hai mai detto che un microkernel non può essere general
purpose..
ma tu stesso dici ancora prima
"Il fatto e` che un uK GP NON FUNZIONA!"
scusa eh ma in italiano questo vuol dire che se fai un OS microkernel allora
non riuscirai mai ad ottenere un sistema funzionante
è italiano eh!?!
comunque te lo ripeto per l'ennesima volta, un microkernel non ha nulla per
cui non possa svolgere il ruolo di OS general purpose....
se il problema sono le performance, la difficoltà nel progettarlo,
nell'usarlo, ecc... possiamo ragionare, ma spero sia chiaro che
l'affermazione "Il fatto e` che un uK GP NON FUNZIONA!" è sballata

 modulo kernel space, va giù tutto
Non scriveva dei singoli componenti, ma del
fatto che uno puo` (o no) crashare l'altro.
In un kernel monolitico, un puntatore sbagliato
dello scheduler puo` causare un errore nel FS.
In un uK dove i componenti sono "isolati" questo
non succede.
Pero` c'e` un overhead dovuto alla comunicazione
fra i componenti.
In un kernel monolitico, il FS puo` accedere ad
un blocco sul disco tramite una semplice chiamata
a funzione. In un uK, con isolamento, e` un IPC
che entra ed esce dal kernel, tra FS e disk driver.
E costa tempo.
Se metti FS e driver nello stesso contesto, ti
ritrovi con il problema del monolitico, cioe` che
uno puo` rompere le scatole all'altro.
Allora devi scegliere: o soddisfi la modularita`
assoluta, oppure le prestazioni.
Lo stesso preciso indentico discorso si puo` fare
tra task e thread.
I task sono isolati ed indipendenti, ma si parlano
a fatica, i thread sono veloci, snelli e loquaci, ma
si possono spintonare.
bye,
-- 
piergiorgio

 è italiano eh!?!
Solo per persone intelligenti, a quanto pare.
bye,
-- 
piergiorgio

Piergiorgio Sartor wrote:

già come al solito te ne esci con affermazioni fuori luogo
insomma cos'è che hai detto fino ad ora?

 insomma cos'è che hai detto fino ad ora?
Webber, davvero, scusa se te lo dico, ma hai dei seri problemi di 
comprensione. Forse non leggi i post a cui stai rispondendo prima di 
rispondere, forse vivi in un tuo mondo ovattato in cui non riusciamo a 
penetrare ma, davvero, a discutere in questo modo ci si stufa presto.
Io credo che, rileggendo il thread, tu possa trovare tutte le argomentazioni 
su cosa sia un os general-purpose e sul perché, ad oggi, non esistano 
*microkernel puri general-purpose di successo* (che era la mia 
circostanziatissima affermazione di partenza).
Poi puoi non essere d'accordo, bene, ma non significa che tu abbia ragione.
Personalmente ti consiglio di leggere dei libri veri, invece di Wikipedia.
SALUTONI,
WindoM 

beh pensa che Silberschatz e Tanenbaum siano libri veri
piuttosto un'afferma di Piergiorgio l'ho trovata pari pari su Google, quindi
ho dei dubbi su chi legge veramente Wikipedia
comunque sia se l'affermazione è che i microkernel non possono essere
general purpose è assolutamente falsa
se l'affermazione è che microkernel general purpose non ne esistono ancora
allora è sempre falsa
se voi due siete convinti di ciò che affermate allora non avrete difficoltà
a dirmi in cosa si differenzia un OS monolitico da uno microkernel e perchè
un OS microkernel non può avere mansioni general purpose
per la cronanca un microkernel non è altro che un OS i cui componenti sono
compartimentalizzati, intercomunicanti esclusivamente attraverso IPC, tutti
i servizi che non hanno compiti di bootstrap dell'hardware e gestione
dell'IPC vengono posti fuori dal kernel e in user space
se vi è chiaro com'è fatto un microkernel sarete entrambi ben consci che è
una cazzata affermare che un microkernel non può, non è, non è stato o non
sarà mai un OS general purpose

 allora è sempre falsa
Ripeto, puoi non essere d'accordo, ma non significa che tu abbia ragione.
D'altra parte è inutile discuterne ancora se io ti spiego A e tu mi rispondi 
che K non è vero.
Sei proprio su lunghezze d'onda diverse, non riesci a rimanere in-topic.
SALUTONI,
WindoM 

 insomma cos'è che hai detto fino ad ora?
Sono e^pi [exp(4*arctan(1))] post che certo di spiegarti
'sta cosa, con frasi diverse ed esempi piu` o meno coloriti
e tu continui a rispondere sempre con: "il uK puo` essere GP".
Allora io ci vedo due casi, o tu non capisci niente,
oppure mi stai prendendo in giro.
Vista la mia infinita fiducia nelle capacita` del
mio prossimo, sono quasi convinto che tu mi stia
prendendo in giro.
Conseguentemente tendo a rispondere a tono.
Comunque sia, ci riprovo, per l'ultima volta, pero`.
Tutto il problema nasce da cosa ci si deve fare con
questo kernel.
Si puo` progettare un kernel per server, per desktop,
per sistemi embedded piu` o meno grandi.
Se si vuole un kernel che funzioni un po' dappertutto
(dappertutto e` impossibile, ovviamente) in maniera
accettabile (perfetta e` impossibile, ovviamente),
bisogna progettarlo in maniera opportuna (ovviamente).
E` altrettanto ovvio che la modularizzazione e` un
elemento fondamentale di questo design (il perche` e`
lasciato come esercizio allo studente).
D'altro canto, pero`, e` necessario cercare di fare
una cosa piu` leggera possibile, dato che non e`
accettabile (in generale, ovviamente) spendere
"troppo" tempo nel kernel. Cosa "troppo" significhi,
ovviamente, dipende da diversi fattori _imprevedibili_,
per cui questo tempo deve essere ridotto al minimo
(proprio perche` i fattori sono imprevedibili).
E questo non ha nulla a che vedere con il real-time.
La prima soluzione che viene in mente e` proprio il uK,
come sostiene il buon Tanenbaum.
Avendo quasi niente in kernel space e tutto come "server"
in user space, soddisfa egregiamente il primo requisito.
E come siamo messi con il secondo?
Maluccio, perche`, IN GENERALE, i vari moduli devono
comunicare tra di loro, e, se la granularita` e` molto
fine (come richiesto dal primo requirement), vi e` un
notevole traffico tra questi moduli.
Vi e` un terzo requisito, cioe` che il sistema, composto
da kernel ed applicativi (e SO), sia "robusto".
Questo e` una conseguenza della generalizzazione che
abbiamo posto come requisito primario.
Per fare cio` i processi devono girare _tutti_ in contesti
diversi, protetti ed isolati, di solito dalla MMU.
In pratica questi non devono neanche poter sospettare che
qualcun'altro stia usando l'HW sottostante.
E qui casca il primo asino, perche` questo requisito e
la comunicabilita` fanno a pugni.
Se hai una catena di 3 funzionalita`, fai molto prima
a chiamare 3 funzioni, una dopo l'altra, piuttosto che
entrare in kernel mode, uscirne, rientrarne, riuscirne,
rientrarne, etc.
Un esempio classico e` la relazione tra file swapper,
filesystem e disk driver.
Sono 3 moduli separati, ma il primo chiama il secondo,
che chiama il terzo (per poter, ad esempio, rimettere
una pagina in memoria).
L'overhead causato da cio` e` _inaccettabile_ per un
kernel che sia generico abbastanza da dover soddisfare,
per _esempio_, interazione utente e multimedialita` e
fare anche da server di posta.
Ovviamente, con processori a 45GHz e 256MB di cache la
cosa potrebbe non essere cosi` grave... Di sicuro, pero`,
non e` una bella situazione...
Altrettanto ovviamente, avere un supporto HW per l'IPC
(ed altro) non sarebbe male, in quanto risolverebbe la
cosa in maniera efficace, consentendo di realizzare un
uK senza costi aggiunti.
Fino qua, pero`, non abbiamo detto dove sta il vantaggio
di un kernel monolitico.
Per prima cosa, direi che anche i kernel monolitici non
esistono piu`.
Come si scriveva altrove, la tendenza e` di avere kernel
ibridi, dove si cerca di spostare in user space il piu`
possibile, dato che non ha magari senso calcolare un MD5
in kernel mode, se si puo` fare altrettanto bene ed in
maniera piu` sicura in user mode.
Il trucco qui sta proprio nel decidere il giusto compromesso
tra cosa sta in kernel mode e cosa ci sta fuori.
Avere le funzionalita` nel kernel aumenta le prestazioni ma
anche il rischio di "collisioni".
Pero`, pero`, il kernel ha un vantaggio: non risente (meglio,
non dovrebbe risentire) di quello che succede in user space.
Quindi, e` pur vero che si deve stare molto attenti a scrivere
codice kernel mode, ma e` anche vero che, una volta sistemato,
questo e` proprio "monolitico", nel senso di "pietra singola",
i.e. robusto.
In altri termini, mentre il problema IPC e` praticamente
irrisolvibile (dati i requisiti di cui sopra, ovviamente in
generale e` risolvibile), il problema dello "strengthening"
e` risolvibile. Non solo, ma e` "banalmente" risolvibile,
basta rimboccarsi le maniche ed avere una buona base di tester.
Quindi, fermo restando che la tendenza porta verso il uK,
il limite inferiore non e` un uK puro, ma una soluzione
ibrida, dove si cerca il compromesso migliore fra prestazioni
e rottura di scatole.
Come chiusura finale: non e` neanche detto che un filesystem
_debba_ stare in kernel mode, dipende dal FS.
Magari, dico magari, un FS compressed/encrypted gira molto
meglio in user mode, dato che la complessita` delle due
funzionalita` (compressione e crittograffazione) puo` forse
essere risolta meglio in user space, che nel kernel.
Ci siamo capiti?
Prima di rispondere: "un uK puo` essere GP", magari puoi
vedere se ho espresso qualche concetto in maniera poco chiara
e vediamo di trovarci in qualche punto.
bye,
-- 
piergiorgio

 modulo kernel space, va giù tutto
Mi rifaccio alla risposta di piergiorgio, aggiungendo: ok, riavvii il
server che si occupa del fs (sempre che non debba "pescare" qualcosa
dal disco, per farlo...), ma il danno e' comunque belle fatto, come
in un monolitico. A poco serve che non sia andato in panic l'intero
sistema. :-)
bye G.L.
-- 
Renaissance, aka Gian Luca Sole
"E' assolutamente evidente che l'arte del cinema si ispira
alla vita, mentre la vita si ispira alla TV" - Woody Allen

 E se poi non e` il 10%, ma il 20%?
Non importa, per me il beneficio di una architettura minimale, piu` 
controllabile e meno soggetta ad errori, travalica le prestazioni. Nota 
che io accetto benissimo un kernel ibrido alla osx.
-- 
Sensei <Sensei's e-mail is at Mac-dot-com>
Basic research is what I am doing when I don't know what I am doing.
(Wernher von Braun)

 che io accetto benissimo un kernel ibrido alla osx.
In generale, direi che non esistono neanche
piu` i kernel monolitici puri, se e` per questo.
bye,
-- 
piergiorgio

 (con tanto di analisi statistiche, a parte una stupida media intendo).
Dimenticavo.
Nessuno ha fatto cio` (in realta` non e` vero (*)), perche`
non esiste un uK GP che sia comparabile...
Cosi`, a spanne, non mi viene in mente nessun uK per un
server, per esempio.
(*) C'e` stata un versione di Linux, mach based, per
Mac, anni addietro.
A quanto pare, non era necessaria nessun misura :-) per
rendersi conto di come stanno le cose...
bye,
-- 
piergiorgio

 piu` i kernel monolitici puri, se e` per questo.
Beh questo non saprei. In senso stretto linux e` monolitico puro con 
estensioni a runtime.
-- 
Sensei <Sensei's e-mail is at Mac-dot-com>
Research (n.): a discovery already published by a chinese guy one month
               before you, copying a russian who did it in the 60s.

 rendersi conto di come stanno le cose...
Si ma mio cuggino una volta e` morto :)
-- 
Sensei <Sensei's e-mail is at Mac-dot-com>
Java is the most distressing thing to happen to computing since MS-DOS.
(Alan Kay)

 estensioni a runtime.
Non direi piu` di tanto, forse lo era in passato,
ma adesso la linea e` sempre piu` sfumata.
Che poi e` lo stesso, prendere un uK e mettere roba in
kernel space (per le prestazioni), oppure prendere un
monolitico e cavar via roba, per renderelo piu` "comodo".
bye,
-- 
piergiorgio

 piu` veloce". Stronzate, scientificamente parlando.
Fallo tu, visto che sai perfettamente cosa e come fare.
Tu dici che uK va come monolitico, benissimo allora,
dimostramelo facendo il confronto con "metodo".
Potrei benissimo dire lo stesso anche io: non esiste
nessun test che provi che vanno uguale o che un uK
sia meglio.
Siccome pero` sembrerebbe che i uK non abbiano tutto
questo successo, potrei vagamente inferire che vi sia
un qualche motivo.
Siccome tutti quelli che iniziano con uK, finiscono,
nella migliore delle ipotesi con ibridi, potrei altrettanto
inferire che la soluzione uK non funziona troppo bene.
Infine, io ci ho lavorato con uK, scrivo per esperienza,
mica per sentito dire (da tuo cuggino).
[mach su mac]
Mi pare di ricordare che si fosse parecchio discusso della
cosa, magari esistono ancora resti in giro in internet.
bye,
-- 
piergiorgio

 L'oscilloscopio che io ricordi fu il primissimo videogame!
   Già, solo che non ce l'aveva nemmeno un firmware: il primo oscilloscopio
su cui ho messo le mani era *analogico*... Che goduria !!!!
-- 
                          | fortune elettromagnetiche
\|/ ____ \|/   \ ||_|     | venivano dissipate in un
"@'/ ,. \`@"    \|| |     | attimo, sorgevano imperi
/_| \__/ |_\ Vax Headroom | d'elio e svanivano
   \__U_/                 | 

 scopio su cui ho messo le mani era *analogico*... Che goduria !!!!
Heheheeh :D
-- 
Sensei <Sensei's e-mail is at Mac-dot-com>
43rd Law of Computing: Anything that can go wr
fortune: Segmentation violation
Core dumped

 monolitico e cavar via roba, per renderelo piu` "comodo".
Beh certo, aggiungendo roba fai un uK monolitico, e togliendo fai un 
monolitico uK. Purtroppo la progettazione del uK rende piu` pulito il 
codice, cosa che ritengo fondamentale. Insomma leggendo xnu mi rendo 
conto di quanto e` "bello".
-- 
Sensei <Sensei's e-mail is at Mac-dot-com>
43rd Law of Computing: Anything that can go wr


 cosa, magari esistono ancora resti in giro in internet.
Si avoglia che se ne e` discusso, ma sempre a livello amatoriale con 
flame e cazzi mazzi. Se convinco il mio prof a darmi tempo provo a 
vedere cosa si puo` fare.
-- 
Sensei <Sensei's e-mail is at Mac-dot-com>
UNIX: The world's first computer virus.
(The UNIX Haters Handbook)

 conto di quanto e` "bello".
Indubbiamente, ma non e` un uK.
La domanda che dobbiamo chiederci e` la seguente:
come mai tutti i progetti uK degli anni '90, che miravano a
rimpiazzare totalmente il design monolitico, sono miseramente
falliti oppure sono stati ridimensionati in scopo oppure sono
stati snaturati in soluzioni ibride?
Una possibilita` e` che vi sia stato un complotto orchestrato
da Torvalds insieme con Microsoft.
Un'altra e` che abbiano cozzato contro limiti tecnici causati
dal design attuale (e degli anni '90) delle CPU, che non
digeriscono bene quel tipo di design.
Mach mi sta particolarmente a cuore perche` in quel periodo un
mio collega ci lavorava alla CMU e raccontava quanto caruccio
fosse quel design.
Purtroppo non regge bene il carico dei "server", tant'e` che
xnu ha pezzi di BSD _dentro_ il uK Mach, tale da non renderlo
piu` un uK puro, ma, come detto in precedenza, un ibrido.
Niente di male in questo, sia ben chiaro, anzi tanto di cappello,
resta pero` una dimostrazione del limite del design uK.
bye,
-- 
piergiorgio

 Insomma e` semplice dubbio scientifico: dove stanno le prove? Ok, 
Le prove stanno nel fallimento, come da altro post,
dei design uK anni '90.
Io mi ricordo quando Mach e` stato presentato, veniva
considerato la soluzione definitiva al design di un
kernel, e, devo dire, dal punto di vista progettuale e`
_il_ Design (con la "D").
Purtroppo _nessuno_ e` mai riuscito a farlo funzionare
in configurazione _pura_, hanno sempre dovuto cacciare
roba nel kernel per riuscire a tenere il passo dei
design monolitici dell'epoca.
E di benchmark c'e` ne sono stati parecchi, soprattutto
come server, non come desktop, dove si misurava il
numero di client serviti al secondo...
bye,
-- 
piergiorgio

 resta pero` una dimostrazione del limite del design uK.
   O del limite del design delle CPU, secondo me... Del resto già un ARM
potrebbe gestire meglio un uK rispetto ad un x86, almeno IMHO...
-- 
                          |
\|/ ____ \|/   \ ||_|     |   Siamo in missione 
"@'/ ,. \`@"    \|| |     |   per conto di Dio !
/_| \__/ |_\ Vax Headroom |
   \__U_/                 |         Jake Blues

 potrebbe gestire meglio un uK rispetto ad un x86, almeno IMHO...
Esatto, e` quello che vado scrivendo ogni due post.
Le attuali CPU non sono progettate per reggere un uK,
ma per far andare soluzioni piu` monolitiche.
Si puo` aggirare parzialmente il problema con le
prestazioni pure (clock, cache) o con un design
particolarmente "elastico" (ARM, magari), ma resta
il fatto che mancano dei fondamentali...
bye,
-- 
piergiorgio

 resta pero` una dimostrazione del limite del design uK.
Lo so, non e` uK puro come ho sempre scritto, ma del resto tra linux e 
xnu, xnu e` estremamente uK. E ti ripeto, a me sta benissimo: xnu e` 
minuscolo.
-- 
Sensei <Sensei's e-mail is at Mac-dot-com>
If you get this in less than 10 seconds, then you are a certified geek.
"FEATUR"
(License plate seen on an old Volkswagen Beetle)

 numero di client serviti al secondo...
Al tempo mi dirai. E scordi Amoeba. Comunque, il discorso e` che i 
kernel odierni, come ogni altro prodotto, non vengono realmente 
testati. Purtroppo.
-- 
Sensei <Sensei's e-mail is at Mac-dot-com>
The optimist proclaims that we live in the best of all possible worlds;
and the pessimist fears this is true.
(James Branch Cabell)

 scientificamente una parola una, ha solo parlato stile bar dello sport.
Ma tu non hai definito "scientificamente".
Qualunque cosa ti si dica, sia a livello pragmatico
che teorico non ti va bene.
Questo vuol dire che vai per partito preso e non
per considerazioni tecnico/scientifiche.
Ti ho chiesto di descrivermi un IPC che sia veloce,
flessibile e robusto (tutto assieme) ed hai detto
che ci penserai.
Ci hai pensato? Qual'e` la soluzione?
L'argomento che porti e` che il uK e` elegante.
Certo che e` elegante, ma, in generale, troppo
pesante per poterlo usare in un largo spettro
di casistiche.
Ovviamente, tu sei libero di preferire l'eleganza
alla funzionalita`, purtroppo, pero`, il resto del
mondo la pensa diversamente.
Cioe` che sia meglio avere qualcosa che funziona,
anche se non e` bella a vedersi, piuttosto di qualcosa
che e` un capolavoro di design, ma non porta acqua.
Soprattutto quando si deve sgomitare per farsi strada.
bye,
-- 
piergiorgio

 Purtroppo.
Ma tu che ne sai?
Ma tu sei studente o lavori?
Mai lavorato nel settore embedded, per caso?
Sono tutti che fanno test, secondo te per quale
ragione hanno rimpinzato il uK Mach con pezzi
BSD, per fare xnu?
Non avevano niente di meglio da fare, un Sabato,
ed hanno deciso di modificare in quel modo Mach?
Oppure, forse, si sono accorti che magari non era
proprio "prestante"?
Secondo il tuo metro, tutti gli sviluppatori di xnu
sono proprio degli incompetenti che non riescono a
verificare come un Mach puro sia veloce uguale ad
un Mach ibrido.
E ci mettiamo tra questi anche quelli di Haiku.
Tutti incompetenti fannulloni che non testano adeguatamente
il lavoro che fanno.
Staranno tutti ansiosamente aspettando te, immagino! :-)
Oppure e` il marketing che li costringe!
Insomma, negare ad ogni costo che uK non e` un
design attuabile sulle CPU a disposizione.
bye,
-- 
piergiorgio

Ho controllato un po' in giro e salta fuori che
gli sviluppatori di Mach, tra gli altri, hanno
fatto i benchmark.
"Microkernel modularity with integrated kernel performance".
Technical report, OSF Research Institute, Cambridge, MA.
Unfortunately, the use of IPC for almost all tasks turned out
to have serious performance impact. Benchmarks on 1997 hardware
showed that Mach 3.0-based UNIX single-server implementations
were about 50% slower than native UNIX.
Nel dettaglio, tra l'altro si spiega il perche`.
A parte il context switch puro, che non pesa piu` di tanto,
(ma pesa, comunque) il problema sta, in piccola parte, nella
rimappatura della MMU, in grossa parte nell'autenticazione del
messaggio (sicurezza).
In tutti i casi in cui gli ultimi due aspetti non siano rilevanti
(memoria non paginata, ma lineare, server ed applicativi "sicuri",
perche` il sistema e` "chiuso", esistono uK (L4) che sono _piu`_
veloci dei corrispondenti "Unix".
Come volevasi dimostrare, se si scende a compromessi, si
trovano le prestazioni, o perche` si rinuncia a qualche
"feature", oppure perche` si rinuncia al uK puro.
bye,
-- 
piergiorgio

 Soprattutto quando si deve sgomitare per farsi strada.
Preferisco l'eleganza, ed un ibrido mi da questa eleganza. Non so se tu 
abbia mai visto xnu, oppure il kernel di Haiku, o NewOS (da cui nacque 
Haiku), comparandolo al kernel linux. Ma se lo facessi, capiresti che 
uno e` brutto, gli altri sono molto belli, eleganti, e tra l'altro 
funzionali: io non mi lamento su un pc vecchio di 3 anni... e xnu non 
e` proprio il piu` veloce del pianeta. Vorra` dire qualcosa!
-- 
Sensei <Sensei's e-mail is at Mac-dot-com>
$ cd /pub
$ more beer

 design attuabile sulle CPU a disposizione.
Per dio, non nego nulla cazzo!!
Vedo di dirtelo a chiare parole.
"Chiunque dica che A e` migliore di B davanti ad una comunita` 
scientifica (che usa il cervello diciamo), ha IL DOVERE di portare 
tutti i fottutissimi dati, compresi i test per la significativita` 
statistica. Altrimenti e` solo UNA CAZZO DI OPINIONE."
Nel 1996 un uK era 10s piu` lento di un monolitico? Ok, sticazzi, non 
ho mai detto che fossero scheggie. La mia questione e`, ed ora a *12 
anni di distanza* come cazzo stiamo messi? Perche` io non mi fido delle 
statistiche di tuo cuggino, o del cuggino di Torvalds, o del cuggino di 
Gassee, io voglio i dati. E nessuno li da, pure tu sai dare solo 
opinioni, rispettabili, ma darmi dell'arrampicatore sugli specchi 
quando ti chiedo i dati, fattelo dire, non e` molto incoraggiante e 
molto "politicante". Senza offesa, se puoi.
Trattare l'informatica come ESENTE da prove scientifiche (a distanza di 
12 anni ripeto) e` da idioti, oppure da persone in malafede.
Io propendo verso la malafede di solito quando parla nVidia, o Apple, o 
chicchessia.
-- 
Sensei <Sensei's e-mail is at Mac-dot-com>
Beware of bugs in the above code; I have only proved it correct, not tried it.
(Donald Knuth)

 "feature", oppure perche` si rinuncia al uK puro.
NON HO DUBBI SUL *PASSATO*!
-- 
Sensei <Sensei's e-mail is at Mac-dot-com>
It is a very sad thing that nowadays there is so little useless information.
(Oscar Wilde)

 mia come la tua, resta solo una opinione, ovvero aria fritta.
La tua e` una opinione, io l'ho testato e provato.
bye,
-- 
piergiorgio

 NON HO DUBBI SUL *PASSATO*!
Ripeto, cercati i paper e vedrai tu stesso, io non
devo piu` dimostrarti niente.
Non hai ancora portato alcun argomento ne` tecnico,
ne` accademico per sostenere qualcosa.
L'unica cosa che ti concedo e` che a te piacciono i uK,
benissimo, niente di male in questo, solo che, gusti
tuoi a parte, non hai nessun argomento valido con
cui discutere.
bye,
-- 
piergiorgio

 user space. Chissa` perche`.
Bravo, questo e` quello che ho scritto io qualche post
addietro. Oltre a riportare cose degli altri, hai una
tua opinione _tecnica_?
Ri-ripeto, cercati i test. Sono comunque sicuro che avrai
da ridire su come sono fatti, o quando sono fatti, o su
chi li ha fatti, varie & eventuali.
Tu scrivi per partito preso, ti piace il uK, ben venga,
ma non venirmi a dire che il marketing qua, il test e`
vecchio, l'ibrido vale uguale, etc.
Sono tutte scuse patetiche per non ammettere il semplice
fatto che il design uK deve quantomento essere rivisto
per poter essere utilizzato proficuamente.
bye,
-- 
piergiorgio

 La tua e` una opinione, io l'ho testato e provato.
Che kernel hai testato, quando e come? Mi interessa seriamente.
-- 
Sensei <Sensei's e-mail is at Mac-dot-com>
There is no reason for any individual to have a computer in his home.
(Ken Olsen, President, Digital Equipment, 1977)

 said:

Vedi altro post. Inutile averne 100 di thread ;)
-- 
Sensei <Sensei's e-mail is at Mac-dot-com>
43rd Law of Computing: Anything that can go wr


 per poter essere utilizzato proficuamente.
Vedi altro post, purtroppo le mie "patetiche" argomentazioni sono 
semplici, non trovo paper che trattino queste cose. E tu non aiuti. 
Nell'altro post ho scritto l'unico paper che ho trovato su un benchmark 
di kernel.
-- 
Sensei <Sensei's e-mail is at Mac-dot-com>
If you get this in less than 10 seconds, then you are a certified geek.


 Che kernel hai testato, quando e come? Mi interessa seriamente.
Una serie di uK e nK per applicazioni embedded.
Nello specifico, il problema era trovare il kernel
che fornisse il giusto compromesso tra astrazione
ed efficacia, vista la piattaforma su cui doveva girare.
In questa situazione, paradossalmente dato che la
protezione non era una cosa fondamentale, si notava
immediatamente la differenza tra varie soluzioni.
Un po' piu` nello specifico, la differenza tra
avere un processamento video real-time oppure no.
Ora, so che non ti ho completamente risposto e so
anche che ne avrai da ridire, ma non posso darti
piu` informazioni di queste (NDA).
Puoi pero`, se vuoi, fare altre domande.
bye,
-- 
piergiorgio

 Puoi pero`, se vuoi, fare altre domande.
Beh mi inviti a nozze :D
Nei kernel che hai provato, uK e nK, quali funzioni erano incluse nel kernel?
Gia` un uK non ha quasi nulla, un nK per quanto mi riguarda rimane nel 
mio immaginario...
-- 
Sensei <Sensei's e-mail is at Mac-dot-com>
We know Linux is the best, it can do infinite loops in five seconds.
(Linus Torvalds)

 Tra l'altro Mach e` GP per design.
non ricominciano con la storia GP e non GP eh !?!

 
scusa ma un sistema operativo DEVE far andare tutti gli applicativi
possibili ed immaginabili, altrimenti che sistema operativo è?
ho letto più giù che ritiene che Linux non fosse GP fino al 1997 perchè non
aveva le applicazioni.....eh un momento ma qui parliamo di due cose
differenti
un sistema operativo non è GP solo se non dà la possibilità agli
sviluppatori di svolgere applicazioni non previste quando è stato creato
un sistema operativo non GP è un sistema che permette di svolgere solo un
set limitato di compiti, compiti peraltro che sono stati previsti in fase
di progettazione dello stesso....
un OS che fornisce gli strumenti per lanciare processi arbitrari è un OS
GP...che poi nel caso reale manchino i software è un altro paio di
maniche....

webber ha scritto:
[SNIP]
Niente da fare, eh...
Perdonami, ma: o ci sei, o ci fai.
bye G.L.
-- 
Renaissance, aka Gian Luca Sole
"E' assolutamente evidente che l'arte del cinema si ispira
alla vita, mentre la vita si ispira alla TV" - Woody Allen

 mio immaginario...
Mah, direi che nK e` semplicemente un uK in pochi byte.
Cioe` offre piu` o meno le stesse funzionalita`, ma e`
ottimizzato per le dimensioni.
Per esempio, un uK che sta completamente in cache e`
piu un nK, a mio avviso.
bye,
-- 
piergiorgio

 piu un nK, a mio avviso.
Ok.
-- 
Sensei <Sensei's e-mail is at Mac-dot-com>
Three things are certain
Death, taxes, and lost data
Guess which has occurred. (Computer's Haiku)

 rete, visto che lo stack e` in userspace.
Dipende dall'applicativo che ci gira sopra, che deve
essere progettato, se richiesto, con quella funzionalita`
in mente.
Se si parla di server, poi, c'e` il discorso sicurezza.
Comunque lo stack di rete non e` l'overhead maggiore.
Per esempio se hai un client multimediale, la cosa piu`
pesante e` il decoder audio/video, non la rete.
bye,
-- 
piergiorgio