Nuove licenze server da Microsoft: si spinge sul multi core

[Jaxoon]

Originariamente inviato da Sp4rr0W
Certo che installare S.O. microsoft su un server... bisogna essere dei folli
Qualsiasi azienda seria con sistemisti competenti usa server linux non quelle ciofeche di microsoft

...disse il saggio...

immagino che tu sia un sistemista esperto e competente che utilizzi solo Linux...

Perchè sputi sentenze così? Hai avuto modo di provare con le tue mani o ti riferisci al costo delle licenze? o cos'altro?

[cdimauro]

x grobbio Concordo: si paga in base all'uso che se ne deve fare. Un sistema a n processori non ce l'ha pinco pallino, ma un'azienda che lo usa per guadagnarci. Sviluppare un s.o. multiprocessore non è una cosa semplice: è giusto che venga pagato.

Tra l'altro la notizia di questa news mi sembra un ottimo passo di MS: va a vantaggio degli utenti, visto che ci stiamo avviando a delle soluzioni multicore per il futuro anche nei sistemi desktop...

[stefanotv]

Originariamente inviato da Sp4rr0W
Certo che installare S.O. microsoft su un server... bisogna essere dei folli
Qualsiasi azienda seria con sistemisti competenti usa server linux non quelle ciofeche di microsoft

1 - nessuno sta parlando si S.O. e neanche la news, quindi evita flame
2 - se avessi lavorato almeno per qualche giorno nell'ambito IT sapresti che esistono centinaia di applicativi che funzionano solo sotto windows e che non hanno ancora i porting per linux,
cosa fare? non utilizzare un applicativo che mi permette di risparmiare decine di migliaia di euro perche' gira su windows e secondo te non va bene?
3 - ho ciofeche con hardening adeguato con uptime superiori ad un anno......sono proprio un pazzo

[sheijtan]

Originariamente inviato da stefanotv
2 - se avessi lavorato almeno per qualche giorno nell'ambito IT sapresti che esistono centinaia di applicativi che funzionano solo sotto windows e che non hanno ancora i porting per linux,
cosa fare? non utilizzare un applicativo che mi permette di risparmiare decine di migliaia di euro perche' gira su windows e secondo te non va bene?

Il problema è tutto qui e non c'è da meravigliarsi che ci si scaldi tanto ogni volta che salta fuori il nome Microsoft:
la M$ detiene praticamente un monopolio in un settore cruciale come l' IT e devo confessarvi che 'sta cosa mi terrorizza più dell' antrace, la mucca pazza, il terrorismo islamico, le varie 'emergenze mal tempo', il taglio delle tasse, il non taglio delle tasse ecc ecc...

[stefanotv]

x sheijtan

le colpe sono in parte del monopolio microsoft, ma sono anche da attribuire alla comunita' linux,
troppe distribuzioni con compilatori, librerie, kernel ....differenti,
sviluppi un software compatibile con quale distribuzione? le uniche che hanno fatto un po' di starada in tal senso sono redhat, suse e quelle che si basavano su unitedlinux.
Altra cosa sono certificazioni e supporto,
molte grandi aziende e PA esigono software certificati e supporto,
le certificazioni ci sono parzialmente persino per applicativi diffusissimi come oracle, sap,
il supporto per un applicativo installato su una gentoo ad esempio chi lo da? la community?
vallo a spiegare al cliente che vuole un responsabile in carne ed ossa se una cosa non funziona.

Sono il primo a non essere contento della situazione,
ma allo stato attuale ci sono ancora vincoli che impediscono l'entrata di linux in tutti gli ambiti.

[xeal]

Originariamente inviato da AnonimoVeneziano
Sinceramente non capisco perchè dovrebbero girarti e soprattutto perchè dovrei "godere" nel vedere uno con una macchina + potente della mia pagare di +

Cos'è , invidia?

No. Equità. Come già altri hanno sottolineato, un sw espressamente pensato per l'elaborazione concorrente è più complesso e ha costi superiori, ed è giusto che questi costi gravino maggiormente su chi trae i maggiori vantaggi da quel sw, poichè le prestazioni saranno nettamente diverse a seconda del numero di processori presenti sulla macchina. E auesta differenza di prestazioni non è dovuta (solo) alla presenza di più processori: un qualsiasi word processor puoi farlo girare su un supercomputer con centinaia di milioni di cpu ottenendo le stesse prestazioni di un desktop, per cui è giusto che il prezzo sia identico nei due casi; ma un sw fortemente ottimizzato per il calcolo parallelo avrà un boost enorme sul server multiprocessore, quindi non è giusto proporre lo stesso prezzo nei due casi, perchè all'atto pratico in un certo senso è come paragonare due versioni diverse dello stesso sw.

Inoltre, un server potrebbe servire più utenti contemporaneamente, facendo girare più processi della stessa applicazione su ciascuna cpu, ciascuna con la sua ram eventualmente dedicata; nel caso in cui i processi da gestire fossero superiori al numero dei processori disponibili (diciamo il doppio), ciascun "sottosistema" gestirebbe più processi/utenti con le sue risorse, come se fosse una macchina distinta (il quadro si complica considerando la possibilità di gestire in modo comune lo scheduling dei processi, ma l'esempio IMHO resta valido): possiamo ancora considerarla come una singola installazione? Io credo di no: ancora una volta le prestazioni sarebero nettamente differenti, in particolare sarebbe come se il sw in questione fosse installato su più macchine "fisiche", ciascuna con una sola cpu e una parte della ram installata sul server multiprocessore. Ancora: potrebbe esserci la possibilità far migrare dei processi su più macchine, ed eseguire quindi la stessa applicazione (interamente o un insieme di suoi thread, sottoprocessi) su macchine diverse da quella sulla quale è stata installata: in questo caso come valutiamo l'installazione? Se ritieni ammissibile (non dico giusto, ma almeno non scorretto) legare il prezzo del sw al numero di macchine su cui verrà/potrà essere eseguito, anche parlando di "numero di installazioni", credo che troverai ammissibile pensare che si possa cercare un modo diverso dall'installazione "fisica" del sw su una macchina specifica (ovvero la memorizzazione dell'applicazione e delle sue impostazioni) in uno scenario come questo (più macchine possono eseguire processi di quel sw pur non possedendone una copia "indipendente" nella propria memoria di massa). Un modo possibile è quello di considerare la cpu fisica come l'elemento che individua il numero di copie "indipendenti" (nel senso di copie del sw aventi a disposizione delle risorse da non contendere ad altre copie dello stesso sw, come se fossero installate su macchine diverse) da considerare come installazioni diverse, piuttosto che il "sistema" di storage su cui è materialmente memorizzata la versione rilocabile dell'applicazione.

Quanto alle licenze, capisco perfettamente il tuo punto di vista da "estimatore dell'open source", però è sicuramente meglio che sopravvivano i due modelli: non essendo MAI (in nessun campo, nella vita) poter determinare/raggiungere l'ottimo "assoluto" il pluralismo è essenziale. Inoltre esistono molte licenze open source diverse, alcune delle quali tutelano in modo più o meno marcato i diritti dell'autore del sw, e se riteniamo ammissibile che l'autore di una certa applicazione possa voler limitare la tua libertà d'uso del sw, allora dobbiamo accettare che possano esistere degli strumenti "burocratici" atti a garantire questo diritto. La licenza è proprio uno strumento di questo tipo: per l'utente finale, che si limita ad utilizzare il sw, la licenza è poco più che una formalità burocratica, una formalità che però gli impedisce di redistribuire gratuitamente quella copia del sw, o di venderla ad un prezzo più basso rispetto a quello stabilito dall'autore, come se ne fosse egli stesso l'autore, facendo quindi una concorrenza spietata e sleale al vero ideatore di quel programma, cosa che in teoria si potrebbe fare acquistando non una licenza d'uso, ma una copia del sw. Se acquisto un'automobile di un certo modello e una certa macchina posso rivenderla, nessuno può impedirmelo; è vero però che le licenze su sw closed source sono in genere non trasferibili (cioè non posso rivendere un sw come se fosse di "seconda mano"), ma questo ha una sua logica: sempre nell'esempio dell'automobile, se anche dopo anni di utilizzo non subisse alcun "degrado" e fosse rivendibile come nuova, allo stesso prezzo di una "copia" nuova, ma io la rivendessi a un prezzo inferiore, o anche allo stesso prezzo, il produttore ne trarrebbe uno svantaggio (chi acquista un auto usata se ne assume i "rischi" e comunque acquista qualcosa che ha una valore sicuramente inferiore al nuovo, quindi non si pone in diretta concorrenza con il nuovo); in altri termini, una copia di qualsiasi applicazione, per quanto "usata", non si può considerare "di seconda mano" e non in competizione con una copia "nuova" nel caso venga rivenduta, pertanto la non trasferibilità delle licenze, in quest'ottica, può essere anche non condivisibile, ma sicuramente comprensibile. Per quanto riguarda la revocabilità, infine, se io vendessi delle copie della mia copia licenziata, una volta "scoperto", potrei essere suscettibile di sanzioni volte a risarcire il legittimo autore del sw (e, in quanto proprietario di quella copia e di tutte le riproduzioni, anche l'unico autorizzato a venderle), il quale autore potrebbe considerare la revoca della licenza come parte del risarcimento (dal momento in cui la revoca avesse atto io mi ritroverei ad aver pagato una certa cifra senza poter più fruire del bene per il cui sfruttamento a mio vantaggio ho pagato: sarebbe una sorta di "sequestro").


Ciao a tutti.

[ciop71]

Quanti server linux amministri? E prima quanti server windows amministravi? I giorni di fermo macchina per manutenzione software sono gli stessi? Hai rapporti con aziende che forniscono assistenza a sistemi linux 24x7x365 (no forum o community)?

[AnonimoVeneziano]

Originariamente inviato da xeal
No. Equità. Come già altri hanno sottolineato, un sw espressamente pensato per l'elaborazione concorrente è più complesso e ha costi superiori, ed è giusto che questi costi gravino maggiormente su chi trae i maggiori vantaggi da quel sw, poichè le prestazioni saranno nettamente diverse a seconda del numero di processori presenti sulla macchina. E auesta differenza di prestazioni non è dovuta (solo) alla presenza di più processori: un qualsiasi word processor puoi farlo girare su un supercomputer con centinaia di milioni di cpu ottenendo le stesse prestazioni di un desktop, per cui è giusto che il prezzo sia identico nei due casi; ma un sw fortemente ottimizzato per il calcolo parallelo avrà un boost enorme sul server multiprocessore, quindi non è giusto proporre lo stesso prezzo nei due casi, perchè all'atto pratico in un certo senso è come paragonare due versioni diverse dello stesso sw.

Inoltre, un server potrebbe servire più utenti contemporaneamente, facendo girare più processi della stessa applicazione su ciascuna cpu, ciascuna con la sua ram eventualmente dedicata; nel caso in cui i processi da gestire fossero superiori al numero dei processori disponibili (diciamo il doppio), ciascun "sottosistema" gestirebbe più processi/utenti con le sue risorse, come se fosse una macchina distinta (il quadro si complica considerando la possibilità di gestire in modo comune lo scheduling dei processi, ma l'esempio IMHO resta valido): possiamo ancora considerarla come una singola installazione? Io credo di no: ancora una volta le prestazioni sarebero nettamente differenti, in particolare sarebbe come se il sw in questione fosse installato su più macchine "fisiche", ciascuna con una sola cpu e una parte della ram installata sul server multiprocessore. Ancora: potrebbe esserci la possibilità far migrare dei processi su più macchine, ed eseguire quindi la stessa applicazione (interamente o un insieme di suoi thread, sottoprocessi) su macchine diverse da quella sulla quale è stata installata: in questo caso come valutiamo l'installazione? Se ritieni ammissibile (non dico giusto, ma almeno non scorretto) legare il prezzo del sw al numero di macchine su cui verrà/potrà essere eseguito, anche parlando di "numero di installazioni", credo che troverai ammissibile pensare che si possa cercare un modo diverso dall'installazione "fisica" del sw su una macchina specifica (ovvero la memorizzazione dell'applicazione e delle sue impostazioni) in uno scenario come questo (più macchine possono eseguire processi di quel sw pur non possedendone una copia "indipendente" nella propria memoria di massa). Un modo possibile è quello di considerare la cpu fisica come l'elemento che individua il numero di copie "indipendenti" (nel senso di copie del sw aventi a disposizione delle risorse da non contendere ad altre copie dello stesso sw, come se fossero installate su macchine diverse) da considerare come installazioni diverse, piuttosto che il "sistema" di storage su cui è materialmente memorizzata la versione rilocabile dell'applicazione.

Quanto alle licenze, capisco perfettamente il tuo punto di vista da "estimatore dell'open source", però è sicuramente meglio che sopravvivano i due modelli: non essendo MAI (in nessun campo, nella vita) poter determinare/raggiungere l'ottimo "assoluto" il pluralismo è essenziale. Inoltre esistono molte licenze open source diverse, alcune delle quali tutelano in modo più o meno marcato i diritti dell'autore del sw, e se riteniamo ammissibile che l'autore di una certa applicazione possa voler limitare la tua libertà d'uso del sw, allora dobbiamo accettare che possano esistere degli strumenti "burocratici" atti a garantire questo diritto. La licenza è proprio uno strumento di questo tipo: per l'utente finale, che si limita ad utilizzare il sw, la licenza è poco più che una formalità burocratica, una formalità che però gli impedisce di redistribuire gratuitamente quella copia del sw, o di venderla ad un prezzo più basso rispetto a quello stabilito dall'autore, come se ne fosse egli stesso l'autore, facendo quindi una concorrenza spietata e sleale al vero ideatore di quel programma, cosa che in teoria si potrebbe fare acquistando non una licenza d'uso, ma una copia del sw. Se acquisto un'automobile di un certo modello e una certa macchina posso rivenderla, nessuno può impedirmelo; è vero però che le licenze su sw closed source sono in genere non trasferibili (cioè non posso rivendere un sw come se fosse di "seconda mano"), ma questo ha una sua logica: sempre nell'esempio dell'automobile, se anche dopo anni di utilizzo non subisse alcun "degrado" e fosse rivendibile come nuova, allo stesso prezzo di una "copia" nuova, ma io la rivendessi a un prezzo inferiore, o anche allo stesso prezzo, il produttore ne trarrebbe uno svantaggio (chi acquista un auto usata se ne assume i "rischi" e comunque acquista qualcosa che ha una valore sicuramente inferiore al nuovo, quindi non si pone in diretta concorrenza con il nuovo); in altri termini, una copia di qualsiasi applicazione, per quanto "usata", non si può considerare "di seconda mano" e non in competizione con una copia "nuova" nel caso venga rivenduta, pertanto la non trasferibilità delle licenze, in quest'ottica, può essere anche non condivisibile, ma sicuramente comprensibile. Per quanto riguarda la revocabilità, infine, se io vendessi delle copie della mia copia licenziata, una volta "scoperto", potrei essere suscettibile di sanzioni volte a risarcire il legittimo autore del sw (e, in quanto proprietario di quella copia e di tutte le riproduzioni, anche l'unico autorizzato a venderle), il quale autore potrebbe considerare la revoca della licenza come parte del risarcimento (dal momento in cui la revoca avesse atto io mi ritroverei ad aver pagato una certa cifra senza poter più fruire del bene per il cui sfruttamento a mio vantaggio ho pagato: sarebbe una sorta di "sequestro").


Ciao a tutti.

Riesco a capire solo che tutta questa faccenda dipende principalmente da come l'interlocutore la pensa , è una cosa + filosofica che informatica .

Mi rendo conto che la difficoltà di programmazione di un software designato per il Multi-Threading sia maggiore , ma per quello che so riprogettare un programma che gira su max 2 processori per farlo girare su 8 non è difficile quanto riprogettare un programma che ne sfrutta al max solo uno per farlo girare su 2 .

QUello che intendo è che la difficoltà nella programmazione Multi-Threading non si basa sul numero di processori sul quale il programma viene fatto girare (per lo meno questo succede solo in minor parte) , ma sul Multi-Threading stesso, ossia nella creazione di un programma che esegua il suo lavoro sfruttando + threads anzichè uno solo . Quindi mi sembra ingiusto far pagare + volte un programma per ogni processore (ricordo che stiamo parlando di moltiplicazione del prezzo , come se uno che fa girare il programma su 2 processori pagasse 1500 € , e quello che lo fa girare su 4 lo paga 3000€ . Questa è una situazione che potrei capire se dovessero riprogettare interamente il software per farlo passare da 2 a 4 processori, ma non è esattamente quello che avviene ).

Per la storia del fatto che il server potrebbe servire + utenti quello lo può fare anche un server monoprocessore , non deve essere necessariamente multiprocessore il server per poter servire + utenti , la differenza sta solo nella velocità (e quindi qualità) del servizio in questo caso. Ogni CPU ha la sua RAM ok, e con ciò? Il sistema operativo che gira è sempre uno e l'applicazione che ci gira è sempre quella , solo che è separata in + threads anzichè uno solo .

Insomma, il senso del mio discorso è :

Non credo che le aziende produttrici di software muoiano di fame non speculando sul numero di CPU con la quale facciamo girare l'applicazione per la quale abbiamo acquistato la licenza sulla nostra macchina .

Per la questione sulle licenze software adesso sarebbe meglio lasciarla da parte


Ciao

[xeal]

x AnonimoVeneziano

Ho capito il tuo punto di vista, e si potrebbe pensare di fare una differenziazione "minima" tra licenza per macchine monoprocessore e licenza per macchine multiprocessore. Almeno questa differenziazione dovresti considerarla valida, a meno che tu non ritenga inaccettabile dover acquistare una licenza (o se preferisci una copia) del sw per ogni macchina su cui lo installi, e in questo caso non avrebbe senso discutere sul resto di questo post. In realtà non sarebbe nemmeno necessario, per gli sviluppatori, produrre due versioni, una multithreading e una no, poichè la versione multithreading verrebbe eseguita correttamente anche sulle macchine monoprocessore, ciò che cambierebbe drasticamente sarebbe la velocità di esecuzione ed è questo il nocciolo della questione: in un certo senso, è come avere una versione (multithreading) diversa da quella "base" e intrinsecamente più veloce; in realtà la versione è unica, però si comporta in maniera intrinsecamente diversa (più o meno veloce) a seconda della macchina sulla quale viene eseguita, e si tratta di una caratteristica intrinseca perchè è insita nella "natura" del programma a prescindere dalla macchina (non si tratta di un boost prestazionale legato alla pura potenza di calcolo, come si potrebbe ottenere, ad esempio, mediante un upgrade della cpu in un desktop). Per fare un paragone, il biglietto di un treno ha un prezzo differenziato a seconda della classe in cui si viaggia, però il treno è sempre quello: cambia la comodità del viaggio, ovvero la qualità del servizio fornito, che è quella che si paga. Oppure ancora: un abbonamento a una tv via satellite ha un costo diverso a seconda del numero di canali che puoi decodificare: il prezzo varia in funzione della qualità, eppure il decoder è sempre quello, e così anche la scheda. Nel caso del sw, si paga la maggiore (o minore) qualità (in termini di prestazioni) del sw stesso, la quale è funzione del numero di cpu e del grado di parallelismo raggiunto.

Poi, non è così scontato che uno stesso sw ottimizzato per il multithreading su 2 cpu possa essere facilmente ottimizzato per avere prestazioni superiori con più processori (ovvero utilizzarli tutti): in genere, maggiore è il numero di thread che si vogliono far girare contemporaneamente e più difficile potrebbe essere la determinazione delle porzioni di codice da attribuire a ciascun thread, ovvero più si cerca di parallelizzare un problema e più, in genere, risulta difficile farlo (sicuramente non lo si può fare per un editor di testo visuale, quindi un costo per le licenze legato al numero di processori per una suite di office productivity sarebbe un vero furto, si potrebbe pensare tutt'al più a una licenza multiutente vs single user), e il discorso si complica se tiriamo in ballo super computer con interconnessioni tra i cluster programmabili (scegli tu quanti e quali processori/macchine usare). In un certo senso, quindi, si potrebbe pensare di capovolgere il problema: il prezzo "vero" è quello per la licenza che contempla il numero massimo di cpu, che garantisce le prestazioni migliori (non solo per il numero di cpu, ma anche e soprattutto per le caratteristiche intrinseche all'applicazione, la quale sfrutta adeguatamente la macchina), mentre le altre si potrebbero considerare riferite a versioni "ridotte" del sw con prestazioni inferiori, per cui il costo d'acquisto è inferiore.

Quanto al numeri di utenti serviti da un server, sia esso mono/multiprocessore, la velocità del servizio può diminuire anche su una macchina multiprocessore se il numero di utenti è superiore al numero di cpu presenti. Per questo motivo parlavo di "processi indipendenti", volendo distinguere tra questo caso e quello in cui, pur essendo unica la macchina nel complesso e unico il S.O. (che poi vuol dire tutto e niente: basta che lo scheduler dei processi sia diverso per ogni cpu e di fatto quel server si comporta come n server monoprocessori, con n numero delle cpu), le cpu vengono assegnate non a thread diversi della stessa applicazione, bensì a interi task distinti dello stesso sw, e in tal caso ciascuna cpu, con le sue risorse dedicate e il proprio scheduler, si comporterebbe come una macchina a sè stante, con una propria copia del programma installata. Ora, o tu rigetti totalmente l'ipotesi di dover pagare una licenza/copia per ciascuna macchina, e in tal caso nulla da obbiettare, posso solo condividere o meno il tuo pensiero, oppure spero converrai con me che non sarebbe corretto far pagare a te, che magari hai un parco macchine "vetusto", o comunque usi 2 server monoprocessore da tempo e per le tue necessità vanno più che bene, due licenze e a me, che uso un unico server dual processor, con il doppio della ram e dello spazio su disco (o su dischi in raid), una sola licenza quando le prestazioni sono identiche nei due casi. Stesso discorso nel caso in cui sia possibile far migrare i processi (anche per intero) su più macchine: io installo il sw su una e lo utilizzo su due, come se fosse installato su entrambe. In questo caso, o mi fai pagare una licenza legata al numero di processori, che potrebbero essere l'unico elemento per individuare il numero di computer su cui l'applicazione verrà eseguita, oppure mi vendi una sola licenza e mi lasci fare ciò che più mi aggrada.

Che poi, senza tener conto del numero di cpu, le software house non morirebbero di fame, mi pare ovvio, però bisogna considerare che, in relazione ai costi di sviluppo, riducendo le "alternative" (ovvero la differenziazione delle licenze in base alla qualità ottenibile dallo stesso sw su macchine diverse) i prezzi aumenterebbero sensibilmente e i costi non sarebbero "correttamente" distribuiti tra i clienti in base ai vantaggi ottenuti, sia in termini di prestazioni pure, sia, indirettamente, in termini economici (per il vantaggio che si può avere utilizzando un certo sw per lavoro). E qui torniamo al discorso invidia vs equità: troveresti corretto dover pagare lo stesso prezzo (alto) per il tuo computer monoprocessore che pago io per il mio server a quattro vie, sapendo che io otterrò prestazioni quattro volte superiori alle tue per la natura stessa del programma, le stesse prestazioni che tu otterresti installando quell'applicazione su una macchina che però distribuisce il lavoro complessivamente su quattro computer facenti parte di un cluster?

Ovviamente potresti tranquillamente dissentire su tutto, ci mancherebbe altro, io posso solo condividere o meno il tuo pensiero, come te del resto, e non è assolutamente mia intenzione criticarlo o stare a sindacare su chi abbia ragione e chi no .

Ciao

[AnonimoVeneziano]

Originariamente inviato da xeal
x AnonimoVeneziano

Ho capito il tuo punto di vista, e si potrebbe pensare di fare una differenziazione "minima" tra licenza per macchine monoprocessore e licenza per macchine multiprocessore. Almeno questa differenziazione dovresti considerarla valida, a meno che tu non ritenga inaccettabile dover acquistare una licenza (o se preferisci una copia) del sw per ogni macchina su cui lo installi, e in questo caso non avrebbe senso discutere sul resto di questo post. In realtà non sarebbe nemmeno necessario, per gli sviluppatori, produrre due versioni, una multithreading e una no, poichè la versione multithreading verrebbe eseguita correttamente anche sulle macchine monoprocessore, ciò che cambierebbe drasticamente sarebbe la velocità di esecuzione ed è questo il nocciolo della questione: in un certo senso, è come avere una versione (multithreading) diversa da quella "base" e intrinsecamente più veloce; in realtà la versione è unica, però si comporta in maniera intrinsecamente diversa (più o meno veloce) a seconda della macchina sulla quale viene eseguita, e si tratta di una caratteristica intrinseca perchè è insita nella "natura" del programma a prescindere dalla macchina (non si tratta di un boost prestazionale legato alla pura potenza di calcolo, come si potrebbe ottenere, ad esempio, mediante un upgrade della cpu in un desktop). Per fare un paragone, il biglietto di un treno ha un prezzo differenziato a seconda della classe in cui si viaggia, però il treno è sempre quello: cambia la comodità del viaggio, ovvero la qualità del servizio fornito, che è quella che si paga. Oppure ancora: un abbonamento a una tv via satellite ha un costo diverso a seconda del numero di canali che puoi decodificare: il prezzo varia in funzione della qualità, eppure il decoder è sempre quello, e così anche la scheda. Nel caso del sw, si paga la maggiore (o minore) qualità (in termini di prestazioni) del sw stesso, la quale è funzione del numero di cpu e del grado di parallelismo raggiunto.

La cosa sinceramente la vedo da un altro punto di vista . Un software non è un treno, e non me la sento di comparare la comodità della classe di un treno o di un aereo con le prestazioni di un programma . A parte il fatto che le prestazioni del programma in se non sono dipendenti dal programma in sè, ma dai processori utilizzati , poi ovviamente il programma deve essere progettato in modo da sfruttare questa possibilità ( Multi-Threading) , ma non è il programma in sè che determina la velocità .

Poi, non è così scontato che uno stesso sw ottimizzato per il multithreading su 2 cpu possa essere facilmente ottimizzato per avere prestazioni superiori con più processori (ovvero utilizzarli tutti): in genere, maggiore è il numero di thread che si vogliono far girare contemporaneamente e più difficile potrebbe essere la determinazione delle porzioni di codice da attribuire a ciascun thread, ovvero più si cerca di parallelizzare un problema e più, in genere, risulta difficile farlo (sicuramente non lo si può fare per un editor di testo visuale, quindi un costo per le licenze legato al numero di processori per una suite di office productivity sarebbe un vero furto, si potrebbe pensare tutt'al più a una licenza multiutente vs single user), e il discorso si complica se tiriamo in ballo super computer con interconnessioni tra i cluster programmabili (scegli tu quanti e quali processori/macchine usare). In un certo senso, quindi, si potrebbe pensare di capovolgere il problema: il prezzo "vero" è quello per la licenza che contempla il numero massimo di cpu, che garantisce le prestazioni migliori (non solo per il numero di cpu, ma anche e soprattutto per le caratteristiche intrinseche all'applicazione, la quale sfrutta adeguatamente la macchina), mentre le altre si potrebbero considerare riferite a versioni "ridotte" del sw con prestazioni inferiori, per cui il costo d'acquisto è inferiore.

Mi rendo perfettamente conto che anche passare da un programma che sfrutta 2 processori a uno che ne sfrutta 8 non è una cosa immediata, ma richiede comunque del lavoro , ma non è un lavoro così duro come quello della riprogettazione di un software che da una sola ne sfrutta 2 ( come già detto sopra) , non mi sembra un lavoro così grosso da rendere necessario un sovrapprezzo , spesso si tratta solo di distribuire i vari thread su + CPU .

Quanto al numeri di utenti serviti da un server, sia esso mono/multiprocessore, la velocità del servizio può diminuire anche su una macchina multiprocessore se il numero di utenti è superiore al numero di cpu presenti. Per questo motivo parlavo di "processi indipendenti", volendo distinguere tra questo caso e quello in cui, pur essendo unica la macchina nel complesso e unico il S.O. (che poi vuol dire tutto e niente: basta che lo scheduler dei processi sia diverso per ogni cpu e di fatto quel server si comporta come n server monoprocessori, con n numero delle cpu), le cpu vengono assegnate non a thread diversi della stessa applicazione, bensì a interi task distinti dello stesso sw, e in tal caso ciascuna cpu, con le sue risorse dedicate e il proprio scheduler, si comporterebbe come una macchina a sè stante, con una propria copia del programma installata. Ora, o tu rigetti totalmente l'ipotesi di dover pagare una licenza/copia per ciascuna macchina, e in tal caso nulla da obbiettare, posso solo condividere o meno il tuo pensiero, oppure spero converrai con me che non sarebbe corretto far pagare a te, che magari hai un parco macchine "vetusto", o comunque usi 2 server monoprocessore da tempo e per le tue necessità vanno più che bene, due licenze e a me, che uso un unico server dual processor, con il doppio della ram e dello spazio su disco (o su dischi in raid), una sola licenza quando le prestazioni sono identiche nei due casi. Stesso discorso nel caso in cui sia possibile far migrare i processi (anche per intero) su più macchine: io installo il sw su una e lo utilizzo su due, come se fosse installato su entrambe. In questo caso, o mi fai pagare una licenza legata al numero di processori, che potrebbero essere l'unico elemento per individuare il numero di computer su cui l'applicazione verrà eseguita, oppure mi vendi una sola licenza e mi lasci fare ciò che più mi aggrada.

Qua si ritorna sulla questione se è da considerare una sola macchina una macchina con + processori o se è da considerare un complesso di macchine. Sarebbe un concetto da ragionare + a fondo, ma personalmente non me la sento di considerare una macchina multiprocessore un complesso di macchine , comunque credo sia una cosa soggettiva .

Che poi, senza tener conto del numero di cpu, le software house non morirebbero di fame, mi pare ovvio, però bisogna considerare che, in relazione ai costi di sviluppo, riducendo le "alternative" (ovvero la differenziazione delle licenze in base alla qualità ottenibile dallo stesso sw su macchine diverse) i prezzi aumenterebbero sensibilmente e i costi non sarebbero "correttamente" distribuiti tra i clienti in base ai vantaggi ottenuti, sia in termini di prestazioni pure, sia, indirettamente, in termini economici (per il vantaggio che si può avere utilizzando un certo sw per lavoro). E qui torniamo al discorso invidia vs equità: troveresti corretto dover pagare lo stesso prezzo (alto) per il tuo computer monoprocessore che pago io per il mio server a quattro vie, sapendo che io otterrò prestazioni quattro volte superiori alle tue per la natura stessa del programma, le stesse prestazioni che tu otterresti installando quell'applicazione su una macchina che però distribuisce il lavoro complessivamente su quattro computer facenti parte di un cluster?

Ovviamente potresti tranquillamente dissentire su tutto, ci mancherebbe altro, io posso solo condividere o meno il tuo pensiero, come te del resto, e non è assolutamente mia intenzione criticarlo o stare a sindacare su chi abbia ragione e chi no .

Ciao

Vorrei soprattutto su questa parte :

troveresti corretto dover pagare lo stesso prezzo (alto) per il tuo computer monoprocessore che pago io per il mio server a quattro vie, sapendo che io otterrò prestazioni quattro volte superiori alle tue per la natura stessa del programma, le stesse prestazioni che tu otterresti installando quell'applicazione su una macchina che però distribuisce il lavoro complessivamente su quattro computer facenti parte di un cluster?


Personalmente si , lo trovo corretto , come trovo corretto che , per esempio, un qualsiasi programma lavori + lentamente su un PC da 300 Mhz anzichè su uno da 3Ghz , questo sempre perchè considero una macchina multiprocessore come una macchina unica (questione che mi sembra il nocciolo della questione)

Ciao

[Ikitt_Claw]

Originariamente inviato da xeal
[...]In realtà non sarebbe nemmeno necessario, per gli sviluppatori, produrre due versioni, una multithreading e una no, poichè la versione multithreading verrebbe eseguita correttamente anche sulle macchine monoprocessore, ciò che cambierebbe drasticamente sarebbe la velocità di esecuzione ed è questo il nocciolo della questione: in un certo senso, è come avere una versione (multithreading) diversa da quella "base" e intrinsecamente più veloce;

Direi di no, invece. Dipende da tanti fattori: il carico del sistema, com'e` progettato il programma, il tipo di computazione che deve eseguire e via discorrendo. Per esempio, un software che fa number crunching non parallelizzabile, o che richiede molte sincronizzazioni tra thread, potrebbe non essere piu` veloce di un'applicazione monothread.
Oppure: un'applicazione che crea un numero abnorme di thread (-> piu` overhead), mettendo in crisi il sistema.
Oppure, un cluster di unita` monoprocessore che fanno girare un server con multiplexing, e un ripartitore di carico. Se la potrebbe seriamente giocare in quanto a prestazioni con un unico megaserver a 8+ vie e SW multithread, che oltretutto crea anche problemi non banali per quanto riguarda la gestione della cache e la migrazione (eventuale) dei suddetti.
(correzioni su eventuali errori/imprecisioni sono ben gradite)

Per fare un paragone, il biglietto di un treno ha un prezzo differenziato a seconda della classe in cui si viaggia, però il treno è sempre quello: cambia la comodità del viaggio, ovvero la qualità del servizio fornito, che è quella che si paga. Oppure ancora: un abbonamento a una tv via satellite ha un costo diverso a seconda del numero di canali che puoi decodificare: il prezzo varia in funzione della qualità, eppure il decoder è sempre quello, e così anche la scheda. Nel caso del sw, si paga la maggiore (o minore) qualità (in termini di prestazioni) del sw stesso, la quale è funzione del numero di cpu e del grado di parallelismo raggiunto.

Uhm, gli esempi mi paiono impropri, in virtu` del fatto che in prima o seconda classe viene erogato un servizio diverso (i sedili alla fine son diversi), cosi` come pure per i canali pay-per-view. Nel caso di un codice multithread, quello rimane sempre uguale a se stesso, indipendentemente dal numero di processori che lo eseguono...

Quanto al numeri di utenti serviti da un server, sia esso mono/multiprocessore, la velocità del servizio può diminuire anche su una macchina multiprocessore se il numero di utenti è superiore al numero di cpu presenti. Per questo motivo parlavo di "processi indipendenti", volendo distinguere tra questo caso e quello in cui, pur essendo unica la macchina nel complesso e unico il S.O. (che poi vuol dire tutto e niente: basta che lo scheduler dei processi sia diverso per ogni cpu e di fatto quel server si comporta come n server monoprocessori,

Ni, in virtu` del fatto rimane il problema dell'accesso a risorse condivise (bus di interconnessione tra periferiche, per esempio). Se si replicassero TUTTE le risorse condivise per ogni CPU... avremmo un cluster compattato in un case
Comunque: esiste un OS (general-purpose) che adotta scheduler diversi per CPU diverse?

[xeal]

Mi scuso per il ritardo nel rispondere, non ho avuto modo di farlo prima.

Originariamente inviato da AnonimoVeneziano
La cosa sinceramente la vedo da un altro punto di vista . Un software non è un treno, e non me la sento di comparare la comodità della classe di un treno o di un aereo con le prestazioni di un programma . A parte il fatto che le prestazioni del programma in se non sono dipendenti dal programma in sè, ma dai processori utilizzati , poi ovviamente il programma deve essere progettato in modo da sfruttare questa possibilità ( Multi-Threading) , ma non è il programma in sè che determina la velocità .

Personalmente si , lo trovo corretto , come trovo corretto che , per esempio, un qualsiasi programma lavori + lentamente su un PC da 300 Mhz anzichè su uno da 3Ghz , questo sempre perchè considero una macchina multiprocessore come una macchina unica (questione che mi sembra il nocciolo della questione)

Personalmente preferisco distinguere i due casi in base al diverso comportamento del sw sulle macchine: nel caso del computer monoprocessore il codice verrà eseguito sequenzialmente, anche se si tratta di un programma multhitreading - in questo caso non vi sarà sequenzialità tra i "moduli" del programma (ovvero lo switch frai thread comporterà in un certo senso l'esecuzione di parte di una funzione, poi di un'altra, quindi di nuovo la prima ecc.), ma a livello delle istruzioni di ciascun "modulo" - e pertanto la differenza di prestazioni dovuta al clock mi piace considerarla strettamente connessa alle caratteristiche della macchina, la quale verrà sfruttata nello stesso modo dal sw, per cui su questo sono perfettamente d'accordo con te. Nel caso della macchina multiprocessore, invece, preferisco pensare che l'aumento di prestazioni sia dovuto principalmente al supporto al multithreading, ovvero alla capacità del sw di comportarsi diversamente e di sfruttare adeguatamente la macchina, eseguendo i suoi moduli in parallelo, poichè un certo numero di processori non è paragonabile ad un unico processore che ha frequenza pari alla somma delle frequenze delle n cpu, per cui il sw dovrà gioco forza avere un comportamento differente.

Faccio questa distinzione perchè, ove applicabile ovviamente, preferisco attribuire al sw una "preminenza" sull'hw, poichè quest'ultimo è solo uno strumento "inerte" ed è il sw a utilizzarlo in modo più o meno efficiente; puoi avere l'hw più performante di questo mondo, ma se il sw non è in grado di sfruttarlo pienamente le prestazioni saranno comunque limitate e paragonabili a quelle di altre macchine (a parità di sw). Ovviamente si tratta di una mia opinione personale e, di conseguenza, è opinabile.

Qua si ritorna sulla questione se è da considerare una sola macchina una macchina con + processori o se è da considerare un complesso di macchine. Sarebbe un concetto da ragionare + a fondo, ma personalmente non me la sento di considerare una macchina multiprocessore un complesso di macchine , comunque credo sia una cosa soggettiva .

Dal mio punto di vista (ripeto: opinabile), questo dipende dall'applicazione, dal modo in cui vede e sfrutta le risorse della macchina: per fare un esempio banale (che avevo già fatto), un word processor (MS Word, WordPerfect, Works...), ma anche SuperPI (che fa calcolo intensivo ma non parallelo: faccio questo esempio per questi motivi, non perchè il bench in sé possa essere un termine di paragone di rilievo ), vedrà la macchina come unica in entrambi i casi, sfruttando le risorse nello stesso identico modo (sequenzialmente), per cui le eventuali differenze prestazionali sarebbero dovute alle caratteristiche intrinseche alla macchina (diverso clock del processore che esegue il task, diversa quantità e latenze della ram, ecc.). Nel caso di un'applicazione multithreading, invece, le macchine vengono viste e sfruttate in modo differente nei due casi.

[qluote]Mi rendo perfettamente conto che anche passare da un programma che sfrutta 2 processori a uno che ne sfrutta 8 non è una cosa immediata, ma richiede comunque del lavoro , ma non è un lavoro così duro come quello della riprogettazione di un software che da una sola ne sfrutta 2 ( come già detto sopra) , non mi sembra un lavoro così grosso da rendere necessario un sovrapprezzo , spesso si tratta solo di distribuire i vari thread su + CPU .
[/quote]

Dipende sempre dal problema e da quanto sia parallelizzabile: l'ottimizzazione per più processori potrebbe implicare una modifica negli algoritmi implementati per aumentare il numero dei thread eseguibili contemporaneamente; laddove invece esiste già un numero di thread "congruo" si potrebbe invece pensare di ribaltare la questione: il programma in questione è stato progettato per ottenere la massima efficienza su di un sistema con un certo numero di processori, per cui il prezzo "vero" è quello della licenza che supporta il numero massimo di cpu previsto, mentre le licenze per sistemi con meno cpu o una sola sono vendute "sottocosto" per ovvie ragioni di marketing (chi ottiene sulle proprie macchine prestazioni inferiori otterrà anche un profitto inferiore dall'uso del mio software - per il suo "comportamento" oltre che per le caratteristiche delle macchine su cui viene eseguito - e di conseguenza il costo della licenza d'uso potebbe diventare meno "appetibile"), e sempre per una questione di marketing si stabilisce il prezzo di "base" per ciascun processore/macchina/utente, in modo da semplificare la determinazione della licenza corretta (o del numero di licenze) da acquistare/vendere.

Tutto, ovviamente, IMHO.

[xeal]

Originariamente inviato da Ikitt_Claw
Direi di no, invece. Dipende da tanti fattori: il carico del sistema, com'e` progettato il programma, il tipo di computazione che deve eseguire e via discorrendo. Per esempio, un software che fa number crunching non parallelizzabile, o che richiede molte sincronizzazioni tra thread, potrebbe non essere piu` veloce di un'applicazione monothread.

Ovviamente ci sarebbero una marea di casi da considerare: io volevo semplicemente fare un discorso di carattere generale, valutando il comportamento globale di un'applicazione, che in un contesto monoprocessore per quanto multithreaded tende a comportarsi come un task monolitico, mentre in un contesto di calcolo distribuito lo stesso codice viene eseguito in modo nettamente diverso (il terzo esempio che hai fatto - server multiprocessore vs cluster di workstation monoprocessore in configurazione di load balancing - descrive perfettamente lo scenario che avevo in mente).

Oppure: un'applicazione che crea un numero abnorme di thread (-> piu` overhead), mettendo in crisi il sistema.

Anche qui dipende: un'applicazione "tradizionale" (heavyweight) potrebbe essere comunque suddivisa, per questioni di modularità, in sottoprocessi "pesanti", ad esempio, il processo principale potrebbe richiamare altre applicazioni (moduli stand-alone) in una pipe, e in tal caso il context switch è generalmente molto più pesante di quanto non lo sia il passaggio da un thread all'altro.

Uhm, gli esempi mi paiono impropri, in virtu` del fatto che in prima o seconda classe viene erogato un servizio diverso (i sedili alla fine son diversi), cosi` come pure per i canali pay-per-view. Nel caso di un codice multithread, quello rimane sempre uguale a se stesso, indipendentemente dal numero di processori che lo eseguono...

Naturalmente occorre tener conto delle differenze: io ho riportato due esempi del mondo "materiale", in cui le differenze si possono toccare con mano. Per valutare la diversità del "servizio erogato" da un sw multithreading in base al numero di cpu presenti nel sistema, ho cercato di formulare (in maniera piuttosto intuitiva e formalmente imprecisa, lo riconosco) un criterio basato sul diverso "comportamento globale" e grado di parallelismo conseguibile (criterio che ho posto alla base dei miei sproloqui).

Se non vogliamo considerare valido questo criterio, potremmo voler giudicare un sw (le sue versioni, che in base al "mio" criterio potrebbero essere anche "virtuali") in base al suo codice; in questo caso, ritengo opportuno distinguere (comincio a sospettare di avere una natura estremamente cavillosa... ) tra l'analisi dei sorgenti (escluse eventuali librerie e/o interfacce con il S.O.) e quella del codice eseguibile. La prima tipologia credo che sarebbe inconcludente o comunque poco utile, poichè sulla base degli stessi sorgenti potrei ottenere versioni dello stesso sw compatibili con piattaforme differenti che potrebbero tranquillamente avere prezzi differenti (semplicemente per la legge della domanda e dell'offerta), e su questo credo che ci sia poco da obbiettare (ogni critica/precisazione è bene accetta ). Se invece vogliamo prendere in esame le istruzioni prodotte per la stessa piattaforma (OS + ISA, a prescindere dal numero delle cpu e da altre caratteristiche), allora si dovrebbe tener conto del fatto che spesso una stessa applicazione ha sezioni di codice differenti che vengono eseguite su macchine differenti: ad esempio, un programma compilato per IA-x86 potrebbe presentare una sezione di codice ottimizzato per sfruttare le SSEII sui P4 e un'altra che si appoggia alle SSE, oppure codice generico eseguito dalla FPU, sui K7. Si potrebbe estremizzare questo tipo di considerazioni concludendo che, poichè su macchine diverse il sw esegue codice diverso (al livello delle ottimizzazioni per la microarchitettura specifica), si può considerare come la "fusione" di versioni differenti, e in effetti le sw house potrebbero produrre due versioni diverse e incompatibili, ciascuna pensata per sistemi basati sui processori di uno o dell'altro produttore, cosa che non avviene perchè implicherebbe un processo di sviluppo troppo complesso/costoso per lo stesso sw e una più difficile commercializzazione del sw stesso, oltre ad essere in contraddizione con la compatibilità prefissa con l'ISA comune. Inoltre (qui sto per tornare al "mio" criterio: lo confesso, non riesco a prescindere, devo essermi plagiato da solo ) il comportamento globale dell'applicazione sulle due macchine è identico nei due casi, per cui ha poco senso cavillare in questa direzione; ciò non di meno, la questione resta aperta perchè ha una sua logica, il criterio di valutazione basato sull'uguaglianza/diversità delle istruzioni macchina andrebbe meglio precisato.

Poi, tornando al multithreading, in teoria (ove applicabile in relazione al problema) si potrebbe pensare di realizzare (l'idea mi frulla in testa da un po', ma non ci ho mai provato, a dirla tutta non saprei dove mettere le mani o quasi ) un modello di parallelismo "dinamico", con una struttura di base per i thread e la determinazione "on the fly", basata sulle risorse disponibili (numero di cpu in primis, ma potrebbe non essere l'unico criterio), del numero di thread dello stesso "tipo" da creare e del carico di lavoro da assegnare a ciascun thread: in questo caso i sorgenti sarebbero identici, come anche il codice macchina di partenza, ma non lo sarebbe il codice eseguito, non nella sua interezza, e non lo sarebbe neanche il comportamento globale (dal punto di vista del grado di parallelismo raggiunto).

Ni, in virtu` del fatto rimane il problema dell'accesso a risorse condivise (bus di interconnessione tra periferiche, per esempio).

Vero, ma si potrebbe cavillare e forzare ulteriormente il paragone con un piccolo cluster che condivide alcune periferiche, costituito ad esempio da due piccoli compiuter molto datati e poco potenti (qui probabilmente sto forzando un po' troppo, concedimi di proporlo come un "prototipo" per uno scenario più verisimile) utilizzati come server di stampa, utilizzando ciascuno per espletare le richieste di determinati utenti (opportunamente raggruppati) - a seconda delle necessità, potrebbe non essere proprio assurdo fare una cosa del genere, magari in considerazione della memoria limitata presente sulle macchine "riciclate" allo scopo, pur essendo il compito assolto non particolarmente esoso di risorse - oppure (caso forse più realistico), le due macchine (sempre con risorse limitate) potrebbero fungere da firewall per determinati gruppi di utenti (chiaramente in un contesto aziendale con un traffico con l'esterno notevole, in relazione alle risorse di ciascun firewall, e poca "voglia" di aggiornare il parco macchine adeguandolo alle esigenze contingenti); oppure ancora, si potrebbe considerare un cluster diciamo composto da 8 workstation monoprocessore, in configurazione di load balancing, che eseguono il rendering fotorealistico di una scena complessa: i dati del modello sono memorizzati nel/negli hd di una delle macchine (i quali costituirebbero la periferica condivisa, anche se potrebbero esserci repliche parziali su ciascuna) e al termine dell'elaborazione i risultati vengono raccolti e memorizzati su una sola macchina (salvo necessità di mantenere copie replicate dei file, in relazione all'uso delle macchine). In questi casi il "bus condiviso" potrebbe essere la rete di comunicazione e l'hub fungerebbe, nell'esempio, da controller del bus, e inoltre le prestazioni/il comportamento del sistema sarebbe paragonabile a quello di una macchina multiprocessore.

Se si replicassero TUTTE le risorse condivise per ogni CPU... avremmo un cluster compattato in un case

Qui consentimi di cavillare di brutto (ma di brutto, brutto, brutto ): in un certo senso potrebbe essere una definizione valida per un computer multiprocessore ("cluster in un case"), in fondo in termini tecnici si parla in entrambi i casi di "sistema di calcolo distribuito" ("in senso stretto" nel caso dell'elaborazione concorrente su macchina multiprocessore, "lasco" su più macchine). Per quel che ci ho capito io, fin dagli albori dell'elaborazione concorrente una macchina multiprocessore si considera in un certo senso come un insieme di macchine che collaborano, condividendo risorse e dati in una struttura di interconnessione molto veloce (vantaggio del sistema distribuito stretto rispetto a quello lasco); accetto ovviamente precisazioni. Poi, volendo esagerare, si potrebbe tirare in ballo la macchina di Von Neumann per concludere che più cpu (unità di calcolo e di controllo), con la propria porzione di memoria di lavoro assegnata (anche dinamicamente, ovvero assegnata al processo in esecuzione in quel momento; condividere il resto non credo che alteri la definizione generale) integrate a formare una macchina unica nel complesso costituiscono un insieme di macchine con un alto livello di integrazione che ne aumenta la velocità e l'accesso alle risorse condivise, tanto più che la macchina di Von Neumann è il prototipo di una macchina seriale, non adatta (singolarmante) per il calcolo parallelo (quindi, cavillando, un server multiprocessore non è assimilabile a un'unica "grossa" macchina di Von Neumann) - ovviamente anche qui accetto precisazioni/correzioni/insulti vari .

Comunque: esiste un OS (general-purpose) che adotta scheduler diversi per CPU diverse?

Francamente non ne ho la più pallida idea . In teoria si potrebbe fare (con un minimo di "sezione" comune, una sorta di pre-scheduler che assegna i nuovi processi a una coda, ad esempio quella più "breve", senza più curarsi della loro "sorte"); sempre in teoria dovrebbe dare prestazioni inferiori a uno scheduler che gestisce una coda (o un insieme di code a priorità) unica, assegnando a ciascun processo la prima cpu che si libera, oppure a un sistema diciamo ibrido, con (insiemi di) code separate gestite da un modulo a sé stante più un modulo "globale" che distribuisce dinamicamente il carico, spostando i processi da una coda all'altra all'ocorrenza (mi pare di aver capito che Linux faccia qualcosa del genere).

Ciao.