Discussione:
Linux kernel: summa di errori da non commettere?
(troppo vecchio per rispondere)
Fabio Fioretti - WindoM
2005-03-22 12:07:10 UTC
Permalink
Apro un nuovo thread in cerca di chiarimenti su quelli che, a detta di
alcuni di voi, sarebbero i peggiori errori alla base dello sviluppo di
Linux, a partire dall'architettura. Argomentiamo un po' le affermazioni
fatte nel thread "grandissima Microsoft"?

SALUTONI,

WindoM
GdG
2005-03-22 13:21:21 UTC
Permalink
Post by Fabio Fioretti - WindoM
Apro un nuovo thread in cerca di chiarimenti su quelli che, a detta di
alcuni di voi, sarebbero i peggiori errori alla base dello sviluppo di
Linux, a partire dall'architettura. Argomentiamo un po' le
affermazioni fatte nel thread "grandissima Microsoft"?
Il primo, comunque ora non più cosi evidente, la "staticità" intesa come
mancanza di innovazione. Bada bene, non in senso deleterio, ma come spirito
conservatore.
Insomma il non mettere mai in discussione le scelte architetturali di Unix.
Daniele Orlandi
2005-03-22 13:54:18 UTC
Permalink
Post by GdG
Insomma il non mettere mai in discussione le scelte architetturali di Unix.
Quali sono le scelte architetturali di Unix che andrebbero messe in
discussione?
--
Daniele Orlandi
GdG
2005-03-22 14:34:58 UTC
Permalink
Post by Daniele Orlandi
Post by GdG
Insomma il non mettere mai in discussione le scelte architetturali di Unix.
Quali sono le scelte architetturali di Unix che andrebbero messe in
discussione
Il fatto di vedere tutto l'universo come una struttura gerarchica :-)
Daniele Orlandi
2005-03-22 15:23:57 UTC
Permalink
Post by GdG
Il fatto di vedere tutto l'universo come una struttura gerarchica :-)
Non riesci a spiegarti meglio? Cosa intendi come "struttura gerarchica" e
cosa dell'universo non si dovrebbe vedere come una "struttura gerarchica" ?

Ciao.
--
Daniele Orlandi
Ottavio Campana
2005-03-22 15:43:05 UTC
Permalink
Post by Daniele Orlandi
Post by GdG
Il fatto di vedere tutto l'universo come una struttura gerarchica :-)
Non riesci a spiegarti meglio? Cosa intendi come "struttura gerarchica" e
cosa dell'universo non si dovrebbe vedere come una "struttura gerarchica" ?
il fatto che (quasi) tutto in unix e' un file e il filesystem e'
gerarchico. A me come idea piace, trovo che le unita' logiche siano una
inesauribile fonte bestemmie per esempio... :-)
Daniele Orlandi
2005-03-22 16:13:24 UTC
Permalink
Post by Ottavio Campana
il fatto che (quasi) tutto in unix e' un file e il filesystem e'
gerarchico.
Innanzitutto credo che quel quasi si sia molto ampliato (o ridimensionato?)
nel senso che ci sono ormai diverse entità che non sono rappresentate con
un file (una per tutte l'infrastruttura di rete).

In secondo luogo, il "tutto è un file" serve solo per creare una
corrispondenza tra entità più o meno astratte e un nome/oggetto con le
quali identificarle. Così facendo si può usare una interfaccia MOLTO
semplice e generica per accedere a tali entità.

Il fatto che il file venga messo in un filesystem non implica nulla sulla
"gerarchia"... potrebbero essere messi in un namespace diverso e non
cambierebbe nulla.

Per concudere... ancora non capisco quale sarebbe la "struttura gerarchica"
e come sarebbe mal utilizzata da unix.

Ciao.
--
Daniele Orlandi
Ottavio Campana
2005-03-23 07:51:57 UTC
Permalink
Post by Daniele Orlandi
Post by Ottavio Campana
il fatto che (quasi) tutto in unix e' un file e il filesystem e'
gerarchico.
Innanzitutto credo che quel quasi si sia molto ampliato (o ridimensionato?)
nel senso che ci sono ormai diverse entità che non sono rappresentate con
un file (una per tutte l'infrastruttura di rete).
In secondo luogo, il "tutto è un file" serve solo per creare una
corrispondenza tra entità più o meno astratte e un nome/oggetto con le
quali identificarle. Così facendo si può usare una interfaccia MOLTO
semplice e generica per accedere a tali entità.
oltre alle interfacce di rete e alle ipc (escluse quelle unix98) cosa
altro sotto unix non e' un file? Di prima mattina, assonnato, non mi
viene in mente altro.
Post by Daniele Orlandi
Il fatto che il file venga messo in un filesystem non implica nulla sulla
"gerarchia"... potrebbero essere messi in un namespace diverso e non
cambierebbe nulla.
la gerarchia te la ritrovi pure nella gestione dei processi, per cui
tutti i processi eccetto il kernel devono avere un processo padre.
Post by Daniele Orlandi
Per concudere... ancora non capisco quale sarebbe la "struttura gerarchica"
e come sarebbe mal utilizzata da unix.
Che ne dici di prenderti un libro e leggere? M. Bach, the design of the
unix operating system, prentice hall.
Daniele Orlandi
2005-03-23 18:37:58 UTC
Permalink
Post by Ottavio Campana
oltre alle interfacce di rete e alle ipc (escluse quelle unix98) cosa
altro sotto unix non e' un file? Di prima mattina, assonnato, non mi
viene in mente altro.
La/le CPU? La ram? Lo scheduler? A dir la verità è una domanda che non ha
neanche molto senso...

Tu hai dei devices, delle entità che devono essere accessibili in user
space, hai quindi bisogno di inventarti un'interfaccia. Puoi creare
un'interfaccia apposita e un namespace per ogni categoria di device oppure
usare un'interfaccia comune e usare il filesysten come namespace, non ci
vedo nulla di male, anzi!
Post by Ottavio Campana
la gerarchia te la ritrovi pure nella gestione dei processi, per cui
tutti i processi eccetto il kernel devono avere un processo padre.
Mi sembra la logica conseguenza del fatto che un processo è lanciato da un
altro processo, dovrebbe essere diverso?
Post by Ottavio Campana
Post by Daniele Orlandi
Per concudere... ancora non capisco quale sarebbe la "struttura
gerarchica" e come sarebbe mal utilizzata da unix.
Che ne dici di prenderti un libro e leggere? M. Bach, the design of the
unix operating system, prentice hall.
Ripeto, non riesco a capire quale sarebbe la struttura gerarchica. Il fatto
che unix usi un file system gerarchico e che i processi abbiano un padre
implica qualcosa sulla "struttura di unix" ?

Ciao.
--
Daniele Orlandi
Ottavio Campana
2005-03-24 08:04:24 UTC
Permalink
Post by Daniele Orlandi
Post by Ottavio Campana
oltre alle interfacce di rete e alle ipc (escluse quelle unix98) cosa
altro sotto unix non e' un file? Di prima mattina, assonnato, non mi
viene in mente altro.
La/le CPU? La ram? Lo scheduler? A dir la verità è una domanda che non ha
neanche molto senso...
/dev/mem che e'?
i dispositivi /dev/cpu/* cosa sono?

non credo di essere l'unico ad averli nel computer......
Post by Daniele Orlandi
Tu hai dei devices, delle entità che devono essere accessibili in user
space, hai quindi bisogno di inventarti un'interfaccia. Puoi creare
un'interfaccia apposita e un namespace per ogni categoria di device oppure
usare un'interfaccia comune e usare il filesysten come namespace, non ci
vedo nulla di male, anzi!
sia ben chiaro, nemmeno io ci vedo nulla di male. Pero' ripeto, che ne
dici di leggere qualcosa su unix, visto che unix e' nato per nascondere
le parti critiche dell'hardware come per esempio cpu e memoria? Il fatto
che ti permetta di accederci non vuol dire che sia utile e sano farlo.
Post by Daniele Orlandi
Post by Ottavio Campana
la gerarchia te la ritrovi pure nella gestione dei processi, per cui
tutti i processi eccetto il kernel devono avere un processo padre.
Mi sembra la logica conseguenza del fatto che un processo è lanciato da un
altro processo, dovrebbe essere diverso?
puo' essere diverso.
Post by Daniele Orlandi
Post by Ottavio Campana
Post by Daniele Orlandi
Per concudere... ancora non capisco quale sarebbe la "struttura
gerarchica" e come sarebbe mal utilizzata da unix.
Che ne dici di prenderti un libro e leggere? M. Bach, the design of the
unix operating system, prentice hall.
Ripeto, non riesco a capire quale sarebbe la struttura gerarchica. Il fatto
che unix usi un file system gerarchico e che i processi abbiano un padre
implica qualcosa sulla "struttura di unix" ?
e io ti ripeto, leggi un libro prima. :-)
Daniele Orlandi
2005-03-24 11:00:28 UTC
Permalink
Post by Ottavio Campana
/dev/mem che e'?
Spiegami, tu per allocare memoria in un processo fai open("/dev/mem") o
brk() ?
Succederebbe qualcosa al sistema se cancellassi /dev/mem ?
Post by Ottavio Campana
i dispositivi /dev/cpu/* cosa sono?
Discorso analogo...
Post by Ottavio Campana
sia ben chiaro, nemmeno io ci vedo nulla di male. Pero' ripeto, che ne
dici di leggere qualcosa su unix, visto che unix e' nato per nascondere
le parti critiche dell'hardware come per esempio cpu e memoria?
Ti prego di citarmi dove sarebbe scritto che unix è nato per *nascondere*
qualcosa.
Post by Ottavio Campana
Il fatto che ti permetta di accederci non vuol dire che sia utile e sano
farlo.
Dai, fai degli esempi, cosa non è sano e cosa non è utile?
/dev/mem non è utile?

Quando ho recuperato dei dati importanti dopo che un'applicazione è crashata
copiando /dev/mem in un file credo che la sua utilità l'abbia dimostrata.

/dev/mem non è "sano"?

Dipende da come lo usi, il fatto che esista non è di per sé sbagliato...

Ad ogni modo, stiamo ancora divagando dal punto importante... e io ti ci
riporto...
Post by Ottavio Campana
Post by Daniele Orlandi
Mi sembra la logica conseguenza del fatto che un processo è lanciato da
un altro processo, dovrebbe essere diverso?
puo' essere diverso.
Ad esempio?
Post by Ottavio Campana
e io ti ripeto, leggi un libro prima. :-)
Quella del "leggiti un libro" è una trovata piuttosto puerile e suppongo ti
serva per evitare di rispondere. Devo prenderla come un "non so
risponderti"?

Ciao.
--
Daniele Orlandi
Ottavio Campana
2005-03-24 11:18:51 UTC
Permalink
Post by Daniele Orlandi
Ti prego di citarmi dove sarebbe scritto che unix è nato per *nascondere*
qualcosa.
su qualsiasi libro!

se risali di qualche messaggio vedrai che ti ho citato il libro di Bach.
Lo usavano in AT&T per insegnare Unix ai programmatori. Forse loro, che
lo hanno inventato, sapevano di cosa parlavano?
Post by Daniele Orlandi
Post by Ottavio Campana
Il fatto che ti permetta di accederci non vuol dire che sia utile e sano
farlo.
Dai, fai degli esempi, cosa non è sano e cosa non è utile?
/dev/mem non è utile?
non e' sano accederci direttamente se non per operazioni straordinarie.
Per esempio i rootkit passano per /dev/mem e/o /dev/kmem.

se vuoi bypassare il sistema di gestione della memoria virtuale dovresti
fare programmi che gestiscano da soli la memoria, l'allineamento,
l'endianess e lo swap. Proprio per questo motivo unix nasconde questi
aspetti della memoria.
Post by Daniele Orlandi
Quella del "leggiti un libro" è una trovata piuttosto puerile e suppongo ti
serva per evitare di rispondere. Devo prenderla come un "non so
risponderti"?
no, in quel libro ci sono tutti gli algoritmi e le strutture dati. ci
trovi spiegata tutta la gerarchia. Che ritrovi nel filesystem e nella
gestione dei processi. Inoltre man mano che vai avanti col libro ci
trovi l'estensione al caso multiprocessore e poi al caso multicomputer e
ci trovi delle soluzioni che a suo tempo erano state realizzate per
gestire sia i filesystem di rete in modo gerarchico (nomi tipo
/../nome_server/path ) che i vari nodi.
Daniele Orlandi
2005-03-24 13:16:36 UTC
Permalink
Post by Ottavio Campana
Post by Daniele Orlandi
Ti prego di citarmi dove sarebbe scritto che unix è nato per *nascondere*
qualcosa.
su qualsiasi libro!
Puoi fare una cortesia ad un povero idiota come me e citarmi un paragrafo di
qualunque libro?
Post by Ottavio Campana
se risali di qualche messaggio vedrai che ti ho citato il libro di Bach.
Lo usavano in AT&T per insegnare Unix ai programmatori. Forse loro, che
lo hanno inventato, sapevano di cosa parlavano?
Probabilmente loro sapevano quello di cui parlavano, la questione è se lo
sai tu :)
Post by Ottavio Campana
Post by Daniele Orlandi
Post by Ottavio Campana
Il fatto che ti permetta di accederci non vuol dire che sia utile e sano
farlo.
Dai, fai degli esempi, cosa non è sano e cosa non è utile?
/dev/mem non è utile?
non e' sano accederci direttamente se non per operazioni straordinarie.
Bene, esattamente come ho detto io, non è insano a prescindere ma sono
insani certi usi, quindi ammetti che è utile?
Post by Ottavio Campana
Per esempio i rootkit passano per /dev/mem e/o /dev/kmem.
Se hai accesso a /dev/mem o /dev/kmem vuol dire che sei già root e a quel
punto che ci sia /dev/?mem o meno te ne frega poco, potresti caricare un
modulo, sostituire il kernel e una serie di altre amenità.

L'esistenza di /dev/?mem non rappresenta una vulnerabilità di sicurezza ma
solo una comodità per chi scrive rootkit... semmai potrebbe essere un po'
più sicuro un sistema che non ti permetta di accedere alla memoria,
inserire moduli, sostituire il kernel a meno di non fare il boot con certi
parametri (mi ricorda qualcosa?).
Post by Ottavio Campana
se vuoi bypassare il sistema di gestione della memoria virtuale dovresti
fare programmi che gestiscano da soli la memoria, l'allineamento,
l'endianess e lo swap
Allineamento e endianess non sono per nulla trasparenti, mai usato un hton?
Mai fatto sizeof(struct { char a; int b; }) ?
Post by Ottavio Campana
. Proprio per questo motivo unix nasconde questi
aspetti della memoria.
Tolta endianess e allineamento, l'unica cosa che eventualemnte "nasconde" è
la memoria fisica ma non lo definirei "nascondere", comunque non mi
interessa discutere su questioni di lana caprina.

Tornando alla questione iniziale, la "summa di errori da non commettere" di
unix starebbe nel fatto che fornisce /dev/?mem ?
Post by Ottavio Campana
no, in quel libro ci sono tutti gli algoritmi e le strutture dati. ci
trovi spiegata tutta la gerarchia. Che ritrovi nel filesystem e nella
gestione dei processi.
Ancora non mi hai spiegato come l'usare un filesystem organizzato
gerarchicamente e l'avere un albero dei processi possa influire su la
"gerarchia del sistema operativo" sempre che ne esista una....
Post by Ottavio Campana
Inoltre man mano che vai avanti col libro ci
trovi l'estensione al caso multiprocessore e poi al caso multicomputer e
ci trovi delle soluzioni che a suo tempo erano state realizzate per
gestire sia i filesystem di rete in modo gerarchico (nomi tipo
/../nome_server/path ) che i vari nodi.
...e da ciò ne consegue che [rimpire quì].

Ciao.
--
Daniele Orlandi
Ottavio Campana
2005-03-24 15:37:37 UTC
Permalink
Post by Daniele Orlandi
Post by Ottavio Campana
Post by Daniele Orlandi
Ti prego di citarmi dove sarebbe scritto che unix è nato per *nascondere*
qualcosa.
su qualsiasi libro!
Puoi fare una cortesia ad un povero idiota come me e citarmi un paragrafo di
qualunque libro?
paragrafi 1.1 e 1.2 del succitato libro? E' inutile che fai lo stizzito,
e' la verita'.
Post by Daniele Orlandi
Bene, esattamente come ho detto io, non è insano a prescindere ma sono
insani certi usi, quindi ammetti che è utile?
nell'ottica in cui e' nato unix no, non e' praticamente mai utile.
Leggi sotto
Post by Daniele Orlandi
Post by Ottavio Campana
Per esempio i rootkit passano per /dev/mem e/o /dev/kmem.
Se hai accesso a /dev/mem o /dev/kmem vuol dire che sei già root e a quel
punto che ci sia /dev/?mem o meno te ne frega poco, potresti caricare un
modulo, sostituire il kernel e una serie di altre amenità.
ci manca solo il discorso che in assembler si puo' fare tutto e poi hai
fatto il pieno di banalita'.
Post by Daniele Orlandi
L'esistenza di /dev/?mem non rappresenta una vulnerabilità di sicurezza ma
solo una comodità per chi scrive rootkit... semmai potrebbe essere un po'
più sicuro un sistema che non ti permetta di accedere alla memoria,
inserire moduli, sostituire il kernel a meno di non fare il boot con certi
parametri (mi ricorda qualcosa?).
stai parlando di cose che non conosci. Gli ultimi rootkit funzionano
purtroppo anche se il kernel non ha il suppoprto dei moduli.
Post by Daniele Orlandi
Post by Ottavio Campana
se vuoi bypassare il sistema di gestione della memoria virtuale dovresti
fare programmi che gestiscano da soli la memoria, l'allineamento,
l'endianess e lo swap
Allineamento e endianess non sono per nulla trasparenti, mai usato un hton?
Mai fatto sizeof(struct { char a; int b; }) ?
Post by Ottavio Campana
. Proprio per questo motivo unix nasconde questi
aspetti della memoria.
Tolta endianess e allineamento, l'unica cosa che eventualemnte "nasconde" è
la memoria fisica ma non lo definirei "nascondere", comunque non mi
interessa discutere su questioni di lana caprina.
l'esempio della hton e' completamente fuori luogo perche' serve per lo
scambio di dati binari via rete via tcp/ip il quale specifica una
particolare endianess.

Allineamento ed endianess non sono trasparenti? Dai, quanti programmi
hai scritto sotto unix in cui ti sei dovuto preoccupare di come
allineare le variabili in memoria?

Tolto l'endianess e l'allineamento rimane non solo la memoria fisica, ma
tutta la gestione dello swap. Dimmi un programma che gira in userspace
in unix che si occupa di gestire completamente il suo swap. La cosa piu'
simile che puoi trovare sono programmi come oracle o l'ultimo postsgres
che salvano i dati su partizioni raw, ma tra fare questo e gestire
completamente la memoria hai voglia.....
Post by Daniele Orlandi
Tornando alla questione iniziale, la "summa di errori da non commettere" di
unix starebbe nel fatto che fornisce /dev/?mem ?
no, sta nel fatto di pensare di usare tale device. Se accedi a /dev/mem
direttamente perdi di botto le funzionalita' del kernel e la
portabilita' su altri unix o altre piattaforme. E chi ha inventato unix
lo ha scritto proprio con l'intento di evitare di dover riscrivere il
programma per fare il porting.
Post by Daniele Orlandi
Post by Ottavio Campana
no, in quel libro ci sono tutti gli algoritmi e le strutture dati. ci
trovi spiegata tutta la gerarchia. Che ritrovi nel filesystem e nella
gestione dei processi.
Ancora non mi hai spiegato come l'usare un filesystem organizzato
gerarchicamente e l'avere un albero dei processi possa influire su la
"gerarchia del sistema operativo" sempre che ne esista una....
Post by Ottavio Campana
Inoltre man mano che vai avanti col libro ci
trovi l'estensione al caso multiprocessore e poi al caso multicomputer e
ci trovi delle soluzioni che a suo tempo erano state realizzate per
gestire sia i filesystem di rete in modo gerarchico (nomi tipo
/../nome_server/path ) che i vari nodi.
...e da ciò ne consegue che [rimpire quì].
che il sistema e' gerarchico.
Daniele Orlandi
2005-03-24 16:22:21 UTC
Permalink
Post by Ottavio Campana
paragrafi 1.1 e 1.2 del succitato libro? E' inutile che fai lo stizzito,
e' la verita'.
Ti ho chiesto gentilmente di citare, è una cortesia che potresti farmi senza
obbligarmi a comprare il libro solo per leggere un paragrafo.
Post by Ottavio Campana
Post by Daniele Orlandi
Bene, esattamente come ho detto io, non è insano a prescindere ma sono
insani certi usi, quindi ammetti che è utile?
nell'ottica in cui e' nato unix no, non e' praticamente mai utile.
Il fatto che TU non lo usi non implica che non sia MAI utile... e il fatto
che possa magari essere RARAMENTE utile non significa che DEBBA essere
tolto. No?
Post by Ottavio Campana
Post by Daniele Orlandi
Se hai accesso a /dev/mem o /dev/kmem vuol dire che sei già root e a quel
punto che ci sia /dev/?mem o meno te ne frega poco, potresti caricare un
modulo, sostituire il kernel e una serie di altre amenità.
ci manca solo il discorso che in assembler si puo' fare tutto e poi hai
fatto il pieno di banalita'.
In assembly non si può fare proprio nulla di più di quello che si può fare
in qualsiasi altro linguaggio, dal punto di vista della sicurezza.

Dove starebbe la banalità? Tu mi citi come "problema" il fatto che i rootkit
usando /dev/?mem per fare qualcosa che in usermode non si può fare. Io ti
dico che nel momento che sei root, puoi farne tante altre di cose per
otternere lo stesso scopo. Che c'entra l'assembly?
Post by Ottavio Campana
stai parlando di cose che non conosci. Gli ultimi rootkit funzionano
purtroppo anche se il kernel non ha il suppoprto dei moduli.
Ohmioddio, ho detto da qualche parte che l'uso dei moduli è l'UNICO metodo?
No, perché appunto c'è /dev/mem, puoi sostituire il kernel e non so, magari
altri. Questo OVVIAMENTE se vogliamo parlare dei rootkit abbastanza evoluti
da andare a modificare il funzionamento del kernel. Se parli dei rootkit
che cambiano qualche eseguibile qua e là, allora /dev/?mem & co, non
servono a una beata pippa.
Post by Ottavio Campana
l'esempio della hton e' completamente fuori luogo perche' serve per lo
scambio di dati binari via rete via tcp/ip il quale specifica una
particolare endianess.
Lasciando perdere la definizione di hton (che mi fa venire i brividi),
esegui un po' questo codice:

union
{
int a;
unsigned char b[4];
} a;

a.a = 123456789;
printf("%02x %02x %02x %02x\n", a.b[0], a.b[1], a.b[2], a.b[3]);

Domanda: Il risulatato dipende o meno dall'endianity del sistema?
Post by Ottavio Campana
Allineamento ed endianess non sono trasparenti? Dai, quanti programmi
hai scritto sotto unix in cui ti sei dovuto preoccupare di come
allineare le variabili in memoria?
Ne conto almeno 5 ma sicuramente ne dimentico qualcuno, ovviamente
escludendo tutto ciò che funziona in kernel mode.
Post by Ottavio Campana
Tolto l'endianess e l'allineamento rimane non solo la memoria fisica, ma
tutta la gestione dello swap. Dimmi un programma che gira in userspace
in unix che si occupa di gestire completamente il suo swap.
Non ne esistono, per il semplice fatto che i programmi in user mode usano la
"Memoria virtuale" che è un servizio offerto dal kernel.
Post by Ottavio Campana
La cosa piu'
simile che puoi trovare sono programmi come oracle o l'ultimo postsgres
che salvano i dati su partizioni raw, ma tra fare questo e gestire
completamente la memoria hai voglia.....
Cosa c'entra l'uso delle partizioni raw con la memoria virtuale?
Sai cos'è una partizione raw?
Post by Ottavio Campana
Post by Daniele Orlandi
Tornando alla questione iniziale, la "summa di errori da non commettere"
di unix starebbe nel fatto che fornisce /dev/?mem ?
no, sta nel fatto di pensare di usare tale device. Se accedi a /dev/mem
direttamente perdi di botto le funzionalita' del kernel e la
portabilita' su altri unix o altre piattaforme.
ma.... c'è qualcuno da qualche parte che ti OBBLIGA o anche solo ti INVITA
ad usare /dev/mem? La questione è diametralmente opposta... ovvero...

Dev1: "C'è qualcuno che avrà mai bisogno di leggere direttamente la memoria
fisica?"
Dev2: "Boh... magari qualche pazzo ne avrà bisogno... che ne sappiamo noi?"
Dev1: "Ci costa tanto implementare /dev/mem?"
Dev2: "Mancopucazzo"
Dev1: "Famolo!"

Io: "Dio ringrazi Dev1 e Dev2 quando mi hanno dato /dev/mem e ho potuto
recuperare dei dati dopo il crash di un'applicazione".
Post by Ottavio Campana
E chi ha inventato unix
lo ha scritto proprio con l'intento di evitare di dover riscrivere il
programma per fare il porting.
Lo ha anche scritto perché l'amministratore avesse la maggior quantità
possibile di strumenti, anche apparentemente inutili.
Post by Ottavio Campana
Post by Daniele Orlandi
...e da ciò ne consegue che [rimpire quì].
che il sistema e' gerarchico.
Ottimo, ma come si concilia con il fatto che il kernel usi delle liste?
Dovrebbe essere un "sistema gerarchico listoso"? Usa anche degli hash,
però... allora è un "sistema gerarchico listoso hascioso", non pensi?

Credi davvero che il tipo di file system che il sistema operativo usa possa
dargli una qualche connotazione di "sistema gerarchico"?

Ciao.
--
Daniele Orlandi
Lorenzo Allegrucci
2005-03-22 16:50:41 UTC
Permalink
Post by Ottavio Campana
Post by Daniele Orlandi
Post by GdG
Il fatto di vedere tutto l'universo come una struttura gerarchica :-)
Non riesci a spiegarti meglio? Cosa intendi come "struttura gerarchica" e
cosa dell'universo non si dovrebbe vedere come una "struttura
gerarchica" ?
il fatto che (quasi) tutto in unix e' un file e il filesystem e'
gerarchico.
Veramente è un pò più generale, è un grafo aciclico :)
Post by Ottavio Campana
A me come idea piace, trovo che le unita' logiche siano una
inesauribile fonte bestemmie per esempio... :-)
A me piace l'idea di "everything is _FileSystem_", union mount [1]
e altri giochetti col VFS..

[1] se e quando Al Viro deciderà.
gabriele renzi
2005-03-22 19:08:07 UTC
Permalink
Post by Lorenzo Allegrucci
Post by Ottavio Campana
Post by Daniele Orlandi
Post by GdG
Il fatto di vedere tutto l'universo come una struttura gerarchica :-)
Non riesci a spiegarti meglio? Cosa intendi come "struttura
gerarchica" e
cosa dell'universo non si dovrebbe vedere come una "struttura gerarchica" ?
il fatto che (quasi) tutto in unix e' un file e il filesystem e'
gerarchico.
Veramente è un pò più generale, è un grafo aciclico :)
Post by Ottavio Campana
A me come idea piace, trovo che le unita' logiche siano una
inesauribile fonte bestemmie per esempio... :-)
A me piace l'idea di "everything is _FileSystem_", union mount [1]
e altri giochetti col VFS..
[1] se e quando Al Viro deciderà.
cioè, come funziona plan9 ?
Lorenzo Allegrucci
2005-03-22 19:37:56 UTC
Permalink
Post by gabriele renzi
Post by Lorenzo Allegrucci
A me piace l'idea di "everything is _FileSystem_", union mount [1]
e altri giochetti col VFS..
[1] se e quando Al Viro deciderà.
cioè, come funziona plan9 ?
Esattamente, alcune cose ci sono già come i per-process namespaces.
Ottavio Campana
2005-03-23 07:45:20 UTC
Permalink
Post by Lorenzo Allegrucci
Post by Ottavio Campana
il fatto che (quasi) tutto in unix e' un file e il filesystem e'
gerarchico.
Veramente è un pò più generale, è un grafo aciclico :)
quindi un albero :-)

E non e' nemmeno vero, perche' i cicli li puoi fare con i link
simbolici, ma non e' molto sano :-)
Post by Lorenzo Allegrucci
Post by Ottavio Campana
A me come idea piace, trovo che le unita' logiche siano una
inesauribile fonte bestemmie per esempio... :-)
A me piace l'idea di "everything is _FileSystem_", union mount [1]
e altri giochetti col VFS..
[1] se e quando Al Viro deciderà.
link?
Lorenzo Allegrucci
2005-03-23 09:45:38 UTC
Permalink
Post by Ottavio Campana
Post by Lorenzo Allegrucci
Post by Ottavio Campana
il fatto che (quasi) tutto in unix e' un file e il filesystem e'
gerarchico.
Veramente è un pò più generale, è un grafo aciclico :)
quindi un albero :-)
Si ma un albero generalmente sottointende una gerarchia ben precisa, mentre
nel fs unix ci possono essere un numero arbitrario di link tra nodi
qualunque che rompono la gerarchia in senso stretto, era questo che
volevo dire.
Per cui lo vedo più come "foresta di grafi orientati aciclici" :)
Post by Ottavio Campana
E non e' nemmeno vero, perche' i cicli li puoi fare con i link
simbolici, ma non e' molto sano :-)
Infatti
Post by Ottavio Campana
Post by Lorenzo Allegrucci
A me piace l'idea di "everything is _FileSystem_", union mount [1]
e altri giochetti col VFS..
[1] se e quando Al Viro deciderà.
link?
http://www.cs.bell-labs.com/plan9dist/
http://www.cs.bell-labs.com/sys/doc/names.html

Plan9 spinge all'estremo il concetto "everything is file" e forse
va troppo in là, tuttavia l'idea è bella.
Daniele Orlandi
2005-03-23 18:33:58 UTC
Permalink
Post by Ottavio Campana
Post by Lorenzo Allegrucci
Veramente è un pò più generale, è un grafo aciclico :)
quindi un albero :-)
Grafo aciclico != Albero
--
Daniele Orlandi
Ottavio Campana
2005-03-24 08:05:11 UTC
Permalink
Post by Daniele Orlandi
Post by Ottavio Campana
Post by Lorenzo Allegrucci
Veramente è un pò più generale, è un grafo aciclico :)
quindi un albero :-)
Grafo aciclico != Albero
perche'? Il grafo minimo e' un grafo senza maglie, quindi un albero.
Daniele Orlandi
2005-03-24 11:03:40 UTC
Permalink
Post by Ottavio Campana
Post by Daniele Orlandi
Grafo aciclico != Albero
perche'? Il grafo minimo e' un grafo senza maglie, quindi un albero.
Già... e un albero senza ramificazioni è una lista, quindi un grafo è anche
una lista?
--
Daniele Orlandi
Ottavio Campana
2005-03-24 11:19:52 UTC
Permalink
Post by Daniele Orlandi
Post by Ottavio Campana
Post by Daniele Orlandi
Grafo aciclico != Albero
perche'? Il grafo minimo e' un grafo senza maglie, quindi un albero.
Già... e un albero senza ramificazioni è una lista, quindi un grafo è anche
una lista?
un grafo senza maglie e ramificazioni e' una lista.

ti sfugge la differenza tra ipotesi e tesi?
Daniele Orlandi
2005-03-24 13:19:50 UTC
Permalink
Post by Ottavio Campana
Post by Daniele Orlandi
Già... e un albero senza ramificazioni è una lista, quindi un grafo è
anche una lista?
un grafo senza maglie e ramificazioni e' una lista.
ti sfugge la differenza tra ipotesi e tesi?
Post by Daniele Orlandi
Post by Daniele Orlandi
Grafo aciclico != Albero
perche'? Il grafo minimo e' un grafo senza maglie, quindi un albero.
Già... e un albero senza ramificazioni è una lista, quindi una lista
è un grafo?
[1] Evidentemente la mia mente si rifiutava di scrivere corbellerie
--
Daniele Orlandi
Ottavio Campana
2005-03-24 14:56:40 UTC
Permalink
Post by Ottavio Campana
Già... e un albero senza ramificazioni è una lista, quindi una lista
è un grafo?
ovviamente no, ma la cosa e' diversa :-)

mi era parso che nelle ipotesi il filesystem venisse considerato minimo.
Fabio Fioretti - WindoM
2005-03-24 11:30:22 UTC
Permalink
Post by Daniele Orlandi
Post by Ottavio Campana
Post by Daniele Orlandi
Grafo aciclico != Albero
perche'? Il grafo minimo e' un grafo senza maglie, quindi un albero.
Già... e un albero senza ramificazioni è una lista, quindi un grafo è anche
una lista?
No, ma è vero il contrario: una lista che è anche un grafo (un cammino).
Comunque ha ragione Ottavio. Vedi teorema qui sotto:

Teorema di caratterizzazione degli alberi: un grafo G(V,E), con V insieme
dei nodi ed E insieme degli archi, è un albero se e solo se è connesso e
aciclico; G è connesso e aciclico se e solo se è connesso e ha |E|=|V|-1.

SALUTONI,

WindoM
Daniele Orlandi
2005-03-24 13:22:16 UTC
Permalink
Fabio Fioretti - WindoM
2005-03-24 13:34:52 UTC
Permalink
No, ma vero il contrario: una lista che anche un grafo (un cammino).
Ha ragione quando dice che l'albero è un caso particolare di grafo
aciclico
(che è un caso particolare di grafo). Il problema è che lui sostiene il
viceversa, ovvero che "Grafo aciclico == Albero".
Il problema non è un problema, perché è proprio così (supponendo che il
grafo sia connesso)! :-) Ogni grafo connesso e aciclico è un albero (senza
casi particolari).
Un albero può essere definito in due modi:
1) grafo connesso aciclico.
2) grafo connesso con n nodi ed n-1 archi.
Non lo dico io, lo dice un qualunque testo sugli algoritmi e le strutture
dati (cfr. Cormen, Leiserson, Rivest, "Introduzione agli Algoritmi", pag.
85)

SALUTONI,

WindoM
Daniele Orlandi
2005-03-24 14:19:22 UTC
Permalink
Fabio Fioretti - WindoM
2005-03-24 14:29:17 UTC
Permalink
Questo è un grafo aciclico? E' un albero?
=> B =>
A D
=> C =>
No, ma questo è orientato, io dò per scontato che si parli di grafi *non*
orientati...

SALUTONI,

WindoM
Daniele Orlandi
2005-03-24 15:05:32 UTC
Permalink
Fabio Fioretti - WindoM
2005-03-24 15:13:45 UTC
Permalink
No, ma questo orientato, io d per scontato che si parli di grafi
*non* orientati...
E perché mai?!? Un file system è un grafo orientatissimo!
Stavamo parlando di file system, no?
Si ma, non considerando i link trasversali (che costituirebbero un arco
orientato, percorribile in un solo verso), un file system gerarchico può
essere percorso indistintamente dalla radice alle foglie e dalle foglie alla
radice, quindi ogni arco può essere percorso in entrambi i sensi. In
quest'ottica, un file system è riducibile a un grafo non orientato, connesso
e aciclico, cioè a un albero.

SALUTONI,

WindoM
Daniele Orlandi
2005-03-24 15:23:06 UTC
Permalink
Fabio Fioretti - WindoM
2005-03-24 15:29:05 UTC
Permalink
Il fatto che tu stia usando i termini "radice" e "foglie" già implica un
orientamento.
Affatto, implica solo un radicamento.
Le relazioni sono "A è padre di B" che non sono per nulla
paritetiche, infatti B non è padre di A.
Ma alla relazione "A è padre di B" corrisponde la relazione duale "B è
figlio di A", che permette di risalire l'arco in verso opposto, annullando
il presunto orientamento. Per definizione, in un grafo orientato gli archi
hanno un solo verso di percorrenza; questo non è vero in un file system.

SALUTONI,

WindoM
Ottavio Campana
2005-03-24 15:40:58 UTC
Permalink
Post by Fabio Fioretti - WindoM
Ma alla relazione "A è padre di B" corrisponde la relazione duale "B è
figlio di A", che permette di risalire l'arco in verso opposto, annullando
il presunto orientamento. Per definizione, in un grafo orientato gli archi
hanno un solo verso di percorrenza; questo non è vero in un file system.
infatti puoi fare

cd ..
Daniele Orlandi
2005-03-24 15:49:46 UTC
Permalink
Fabio Fioretti - WindoM
2005-03-24 16:04:06 UTC
Permalink
Post by Fabio Fioretti - WindoM
Il fatto che tu stia usando i termini "radice" e "foglie" gi implica un
orientamento.
Affatto, implica solo un radicamento.
Implica un orientamento
Non è vero! Fissato un nodo come radice, gli ultimi nodi raggiungibili dalla
radice con un cammino sono foglie (perdonatemi la scarsa rigorosità dei
termini). Dove sta l'orientamento? E' un puro problema di radicamento,
l'orientamento è qualcosa di molto più stringente.

[CUT]
Post by Fabio Fioretti - WindoM
Per definizione, in un grafo orientato gli archi
hanno un solo verso di percorrenza; questo non vero in un file system.
La differenza è sottile ma c'è. Sempre ignorando i link, i file system
sono
fatti con DUE alberi sovrapposti, uno con la relaziona "A è padre di B" e
uno con la relazione "B è figlio di A".
E' esattamente quel che sto cercando di dirti: sono un pratica due grafi
sovrapposti, aciclici e con orientamenti esattamente opposti; dalla
sovrapposizione si ottiene a tutti gli effetti un grafo aciclico non
orientato, ovvero un albero. Il discorso che fai sulla diversità delle due
relazioni cade quando si considera che il punto centrale della questione è
la percorribilità dell'arco in un verso o nell'altro: rispetto a questa
proprietà le due relazioni "A è padre di B" e "B è figlio di A" sono duali.
Ci siamo capiti ora? :-)

SALUTONI,

WindoM
Daniele Orlandi
2005-03-24 16:43:37 UTC
Permalink
Fabio Fioretti - WindoM
2005-03-24 17:04:51 UTC
Permalink
L'orientamento sta nel fatto che esistono relazioni per le quali non vale
la
proprietà commutativa[1]. "A è padre di B" non equivale a "B è padre di
A",
quindi, un albero creato con tale relazione è orientato.
Esistono relazioni per le quali vale la proprietà commutativa, ad esempio
"A
è collegato a B", "A è fratello di B", etc...
Aridaje! :-) Non perdere di vista il fatto che la proprietà che ci interessa
è la percorribilità di ogni arco del grafo in un senso e nell'altro; in
quest'ottica:
"A è padre di B" == "A è collegato a B"
"B è figlio di A" == "B è collegato ad A"
Post by Fabio Fioretti - WindoM
E' esattamente quel che sto cercando di dirti: sono un pratica due grafi
sovrapposti, aciclici e con orientamenti esattamente opposti; dalla
sovrapposizione si ottiene a tutti gli effetti un grafo aciclico non
orientato, ovvero un albero.
A parte il fatto che non esiste una tale sovrapposizione,
Ah no? Si chiama file system gerarchico. :-)
i due alberi sono
ben distinti, anche a livello implementativo, anche esistesse farebbe
nascere delle contraddizioni, ad esempio il fatto che il grafo risultante
potrebbe non essere più un grafo acicliclo oppure...
Dell'implementazione non m'importa niente, stiamo facendo un ragionamento
concettuale. Sulla possibile introduzione di cicli sbagli, perché i due
grafi sovrapposti sono *identici* (stessi nodi e stessi archi): hanno solo
orientamento inverso.
perché c'è una
differenza, nei comandi, tra l'andare da un padre a un figlio e l'andare
da
un figlio al padre?
Differenza?
cd home
cd ..
Concettualmente non cambia niente: percorri un arco dell'albero in un verso
(da padre a figlio) o nell'altro (da figlio a padre).
Se faccio "cd .." in una directory linkata dove finisco e perché?
Abbiamo supposto l'assenza di link: cosa dovrei risponderti?

Credo di aver detto tutto quel che avevo da dire: se vuoi capire capisci,
altrimenti dimmelo che' evitiamo di continuare all'infinito. ;-P

SALUTONI,

WindoM
Daniele Orlandi
2005-03-24 17:53:12 UTC
Permalink
Fabio Fioretti - WindoM
2005-03-24 18:30:04 UTC
Permalink
Peccato che in un grafo fatto con relazioni "A è collegato a B" non puoi
scrivere un path perché non sai da che nodo partire e nel momento in cui
definisci una root hai definito anche un orientamento (mi allontano dalla
root, mi avvicino alla root). Lo so, è un ragionamento un po' circolare.
Non è circolare, è sbagliato! Radicamento e orientamento sono due concetti
ben distinti, tu li stai mescolando in un polpettone. Per capire che sono
distinti ti basti pensare che possono esistere grafi orientati ma *non*
radicati e grafi radicati ma *non* orientati. Non sono cose per cui ci si
può basare su opinioni personali, esistono definizioni rigorose in merito!
Post by Fabio Fioretti - WindoM
A parte il fatto che non esiste una tale sovrapposizione,
Ah no? Si chiama file system gerarchico. :-)
Non esiste una sovrapposizione che faccia diventare il filesystem un
albero/grafo non orientato. Continuano ad esistere padri e figli e
relazioni che vanno da uno all'altro e mai viceversa.
Aridaje! Se il file system fosse orientato non potresti risalire dal figlio
al padre, *per definizione*. Puoi vedere ogni arco del file system come un
arco doppiamente orientato (in un senso e contemporaneamente nell'altro) ma
questo lo rende chiaramente un arco *non* orientato. Se una strada è a senso
unico da destra verso sinistra e allo stesso tempo è a senso unico da
sinistra verso destra, la strada *non* è a senso unico...
Post by Fabio Fioretti - WindoM
Dell'implementazione non m'importa niente, stiamo facendo un ragionamento
concettuale.
Il fatto che l'implementazione sia diversa dal "ragionamento concettuale"
dovrebbe darti qualche indicazione sulla validità del "ragionamento
concettuale".
Affatto, spesso e volentieri l'implementazione è costretta a distaccarsi dai
concetti che vorrebbe mettere in pratica per questione prettamente tecniche.
Post by Fabio Fioretti - WindoM
Sulla possibile introduzione di cicli sbagli, perch i due
grafi sovrapposti sono *identici* (stessi nodi e stessi archi): hanno solo
orientamento inverso.
Non sono *NECESSARIAMENTE* identici, vedi i link.
Rivedi i vecchi messaggi: l'ipotesi è che non ci siano link trasversali.
Post by Fabio Fioretti - WindoM
cd home
cd ..
Perché ".." invece del nome del padre?
Post by Fabio Fioretti - WindoM
Concettualmente non cambia niente: percorri un arco dell'albero in un
verso (da padre a figlio) o nell'altro (da figlio a padre).
Concettualmente cambia molto ma forse non ti è evidente.
Al mio livello d'astrazione non cambia niente, forse sei un livello sotto?
Spiegami.
Post by Fabio Fioretti - WindoM
Se faccio "cd .." in una directory linkata dove finisco e perch?
Abbiamo supposto l'assenza di link: cosa dovrei risponderti?
Beh no, calma, abbiamo supposto l'assenza di link fino a un certo punto,
non
puoi buttarli via tout court altrimenti non sarebbe neanche nata la
questione...
No, è la premessa fondamentale, i link trasversali introducono cicli!
ma ok, facciamo pure finta che non ci siano i link... cosa
succede se cancello ".." da una directory?
Fai diventare l'arco orientato, in quanto non puoi più risalire dalla
directory attuale verso la radice.

SALUTONI,

WindoM
Daniele Orlandi
2005-03-24 20:22:47 UTC
Permalink
Fabio Fioretti - WindoM
2005-03-24 21:00:55 UTC
Permalink
Daniele Orlandi ha scritto:
[MEGA-CUT]
Caro Daniele, è inutile che io continui a scriverti le stesse cose e che tu
continui a farmi le stesse obiezioni. Le mie motivazioni le trovi nei post
precedenti e, se vuoi approfondire, nei libri dove ho studiato questa roba
(Cormen, Leiserson e Rivest su tutti).
Per il resto, su ogni argomento ognuno è libero di farsi l'idea che vuole,
giusta o sbagliata che sia.
Io preferisco attenermi alla rigorosità formale dei miei testi universitari.

SALUTONI,

WindoM
Ottavio Campana
2005-03-24 14:58:58 UTC
Permalink
No, ma � vero il contrario: una lista che � anche un grafo (un cammino).
Ha ragione quando dice che l'albero è un caso particolare di grafo aciclico
(che è un caso particolare di grafo). Il problema è che lui sostiene il
viceversa, ovvero che "Grafo aciclico == Albero".
in verita' io pensavo ad un grafo minimo. Un grafo minimo e' aciclico e
per ogni coppia di nodi c'e un solo cammino che li unisce.
Sensei
2005-03-24 14:19:21 UTC
Permalink
Post by Ottavio Campana
Post by Daniele Orlandi
Grafo aciclico != Albero
perche'? Il grafo minimo e' un grafo senza maglie, quindi un albero.
No, manca la parola ``orientato''
--
Sensei <mailto:***@tin.it> <pgp:8998A2DB>
<icqnum:241572242>
<yahoo!:sensei_sen>
<msn-id:***@hotmail.com>
Ottavio Campana
2005-03-24 15:01:46 UTC
Permalink
Post by Sensei
Post by Ottavio Campana
Post by Daniele Orlandi
Grafo aciclico != Albero
perche'? Il grafo minimo e' un grafo senza maglie, quindi un albero.
No, manca la parola ``orientato''
azz... vero... accipicchia, stavo pensado alle reti elettriche lineari,
dove la cosa e' sempre verificata, visto che non ci sono diodi.
GdG
2005-03-22 17:25:12 UTC
Permalink
Post by Daniele Orlandi
Post by GdG
Il fatto di vedere tutto l'universo come una struttura gerarchica :-)
Non riesci a spiegarti meglio? Cosa intendi come "struttura
gerarchica" e cosa dell'universo non si dovrebbe vedere come una
"struttura gerarchica" ?
Il peccato originario del "tutto come un filesystem gerarchico".
OS/400 ad esempio, nato nel 1988 (ed è architetturalmente un OS moderno) non
ha nulla di gerarchico ma è tutto lineare.
Daniele Orlandi
2005-03-22 19:38:06 UTC
Permalink
Post by GdG
Il peccato originario del "tutto come un filesystem gerarchico".
Ok, ora è diventato un filesystem gerarchico.
Post by GdG
OS/400 ad esempio, nato nel 1988 (ed è architetturalmente un OS moderno)
non ha nulla di gerarchico ma è tutto lineare.
Continuo a non capirti, sarà colpa mia, ma prova a fare degli esempi, cerca
di farmi capire qual è il tema della discussione, almeno.

Provo a speculare:

Stiamo parlando del file system, tu sostieni che il filesystem di unix (ma
allora anche quello di windows, mac, qnx, dos, romdos, e chissà quanti
altri) organizzato come albero (grafo aciclico, pardon :)) è una "scelta
architetturale da mettere in discussione". OS/400 che non possiede un
flsstm con una grrkia rappresenterebbe una soluzione nttamente mglore.

Ok?
--
Daniele Orlandi
Ottavio Campana
2005-03-23 07:49:47 UTC
Permalink
Post by GdG
Il peccato originario del "tutto come un filesystem gerarchico".
OS/400 ad esempio, nato nel 1988 (ed è architetturalmente un OS moderno) non
ha nulla di gerarchico ma è tutto lineare.
E' una questione di punti di vista. Io reputo una sciagura divina le
unita' logiche. Cazzarola se inserisco un nuovo disco in un pc non mi
devono cambiare le lettere.....

Ho visto scenette tragicomiche, tipo che installi su un pc windows e
viene visto come disco C. Poi si aggiunge un altro disco e il cable
select decide che il vecchio disco e' slave, per cui si becca la D e il
nuovo la C. Al primo avvio l'utente si accorge del cambiamento di
lettere, spegne il pc e sistema i dischi. Riavvio e inchiodamento di
windows perche' non trova il file della memoria virtuale perche'
continua a cercarlo in d. Soluzione rapida formattare e reinstallare.

Adesso dimmi, e' una cosa sana?
dmec
2005-03-23 08:00:10 UTC
Permalink
Ottavio Campana wrote: [CUT]
Post by Ottavio Campana
Post by GdG
Il peccato originario del "tutto come un filesystem gerarchico".
OS/400 ad esempio, nato nel 1988 (ed è architetturalmente un OS moderno)
non ha nulla di gerarchico ma è tutto lineare.
E' una questione di punti di vista. Io reputo una sciagura divina le
unita' logiche. Cazzarola se inserisco un nuovo disco in un pc non mi
devono cambiare le lettere.....
Ho visto scenette tragicomiche, tipo che installi su un pc windows e
viene visto come disco C. Poi si aggiunge un altro disco e il cable
select decide che il vecchio disco e' slave, per cui si becca la D e il
nuovo la C. Al primo avvio l'utente si accorge del cambiamento di
lettere, spegne il pc e sistema i dischi. Riavvio e inchiodamento di
windows perche' non trova il file della memoria virtuale perche'
continua a cercarlo in d. Soluzione rapida formattare e reinstallare.
Adesso dimmi, e' una cosa sana?
ROTFL !! il bello e' che e' tutto vero !
--
http://wiki.news.nic.it/QuotarBene
http://slax.linux-live.org
http://www.slacky.it
GdG
2005-03-23 08:30:21 UTC
Permalink
Post by Ottavio Campana
Adesso dimmi, e' una cosa sana?
No.
Vincent Vega
2005-03-23 10:06:41 UTC
Permalink
Post by Ottavio Campana
E' una questione di punti di vista. Io reputo una sciagura divina le
unita' logiche. Cazzarola se inserisco un nuovo disco in un pc non mi
devono cambiare le lettere.....
Su XP non cambiano. A meno che tu non cambi il disco di avvio, ma...
Post by Ottavio Campana
Ho visto scenette tragicomiche, tipo che installi su un pc windows e
viene visto come disco C. Poi si aggiunge un altro disco e il cable
select decide che il vecchio disco e' slave, per cui si becca la D e il
nuovo la C. Al primo avvio l'utente si accorge del cambiamento di
lettere, spegne il pc e sistema i dischi. Riavvio e inchiodamento di
windows perche' non trova il file della memoria virtuale perche'
continua a cercarlo in d. Soluzione rapida formattare e reinstallare.
Adesso dimmi, e' una cosa sana?
Infatti mi sembra strano. Non che windows si sia bloccato, ma che sia
partito fino a bloccarsi.

Una curiosità: se il primo disco si chiamava /dev/hda e se sul suo boot
record c'era il lilo/grub, cosa succede al successivo avvio se il cable
select decidesse di invertire primary master e slave?
dmec
2005-03-23 10:51:38 UTC
Permalink
Vincent Vega wrote: [CUT]
Post by Vincent Vega
Una curiosità: se il primo disco si chiamava /dev/hda e se sul suo boot
record c'era il lilo/grub, cosa succede al successivo avvio se il cable
select decidesse di invertire primary master e slave?
Ne lilo ne Grub partirebbero ........
dato appunto che risiedono sull'MBR (forse impostando il bios opportunamente
si riesce, ma poi non trovano / (la root) )
--
http://wiki.news.nic.it/QuotarBene
http://slax.linux-live.org
http://www.slacky.it
Vincent Vega
2005-03-23 12:27:53 UTC
Permalink
Post by dmec
Post by Vincent Vega
Una curiosità: se il primo disco si chiamava /dev/hda e se sul suo boot
record c'era il lilo/grub, cosa succede al successivo avvio se il cable
select decidesse di invertire primary master e slave?
Ne lilo ne Grub partirebbero ........
dato appunto che risiedono sull'MBR (forse impostando il bios opportunamente
si riesce, ma poi non trovano / (la root) )
Appunto.
Se per qualche ragione più o meno esoterica cambi il disco di avvio,
penso che qualsiasi sistema non parta. Salvo che non abbia un boot
loader opportunamente preparato e configurato sul MBR del nuovo disco di
avvio.
Raffaele Castagno
2005-03-23 12:49:50 UTC
Permalink
Post by Vincent Vega
Appunto.
Se per qualche ragione più o meno esoterica cambi il disco di avvio,
penso che qualsiasi sistema non parta. Salvo che non abbia un boot
loader opportunamente preparato e configurato sul MBR del nuovo disco di
avvio.
Sinceramente, preferisco un sistema che non parte ad uno che parte
ammuzzo... Almeno bon, so che non parte, risolvo il problema, e riavvio.
Invece con windows il sistema parte, stravolge le lettere delle unità, e
sei fregato...

Raffaele
--
Raffaele Castagno

Mail me if you want a GMAIL account.

Not only bad news: http://www.goodnewsiraq.com
Iraq Linux User Group : http://www.iraqilinux.org
Strategic Blog: http://strategic-game.blogspot.com/
Strategic Sourceforge Homepage: http://strategic.sourceforge.net/
Strategic Sourceforge Project: http://sourceforge.net/projects/strategic/

questo articolo e` stato inviato via web dal servizio gratuito
http://www.newsland.it/news segnala gli abusi ad ***@newsland.it
Vincent Vega
2005-03-23 15:18:24 UTC
Permalink
Post by Raffaele Castagno
Sinceramente, preferisco un sistema che non parte ad uno che parte
ammuzzo... Almeno bon, so che non parte, risolvo il problema, e riavvio.
Invece con windows il sistema parte, stravolge le lettere delle unità, e
sei fregato...
Devo essere sincero, non ho provato: ma non credo che NT/2000/XP rimappi
le unità.
Fra le altre cose le partizioni NTFS possono essere montate su
directory, se si vuole.
Ottavio Campana
2005-03-23 15:22:03 UTC
Permalink
Post by Vincent Vega
Post by Raffaele Castagno
Sinceramente, preferisco un sistema che non parte ad uno che parte
ammuzzo... Almeno bon, so che non parte, risolvo il problema, e riavvio.
Invece con windows il sistema parte, stravolge le lettere delle unità, e
sei fregato...
Devo essere sincero, non ho provato: ma non credo che NT/2000/XP rimappi
le unità.
Fra le altre cose le partizioni NTFS possono essere montate su
directory, se si vuole.
urca se il 2000 lo fa. Eccome....
dmec
2005-03-23 15:26:12 UTC
Permalink
Vincent Vega wrote: [CUT]
Post by Vincent Vega
Post by Raffaele Castagno
Sinceramente, preferisco un sistema che non parte ad uno che parte
ammuzzo... Almeno bon, so che non parte, risolvo il problema, e riavvio.
Invece con windows il sistema parte, stravolge le lettere delle unità, e
sei fregato...
Devo essere sincero, non ho provato: ma non credo che NT/2000/XP rimappi
le unità.
Fra le altre cose le partizioni NTFS possono essere montate su
directory, se si vuole.
Non per voler girare il coltello nella piaga, ma' windows riesce a fare cose
che "voi umani non potete nemmeno immaginare" [cit.]

Comunque quoto Castagno, meglio un sitema che non parte .......
--
http://wiki.news.nic.it/QuotarBene
http://slax.linux-live.org
http://www.slacky.it
Vincent Vega
2005-03-23 15:38:33 UTC
Permalink
Post by dmec
Non per voler girare il coltello nella piaga, ma' windows riesce a fare cose
che "voi umani non potete nemmeno immaginare" [cit.]
Battuta fuori luogo. Ho detto che si può fare in precisa risposta al
problema sollevato che non si può fare. Se "voi umani" non ve lo
immaginavate non è affar mio.
Raffaele Castagno
2005-03-24 09:54:07 UTC
Permalink
Post by Vincent Vega
Devo essere sincero, non ho provato: ma non credo che NT/2000/XP rimappi
le unità.
Fra le altre cose le partizioni NTFS possono essere montate su
directory, se si vuole.
XP non so se rimappa le unità, ma so che si prende qualche libertà sul
nome da dargli. Sotto *nix /usr/local è /usr/local indipendentemente dalla
partizione su cui si trova fisicamente, mentre con windows la cartella
\Programmi\ può essere su c/d/e/f etc etc. Allo stesso modo, su *nix /etc/
esisterà sempre, mentre con windows potrebbe non esistere c: (che è quello
che è successo a me con windowsXP, che ha deciso che il drive primario è
d:.... -_-)

Raffaele
--
Raffaele Castagno

Mail me if you want a GMAIL account.

Not only bad news: http://www.goodnewsiraq.com
Iraq Linux User Group : http://www.iraqilinux.org
Strategic Blog: http://strategic-game.blogspot.com/
Strategic Sourceforge Homepage: http://strategic.sourceforge.net/
Strategic Sourceforge Project: http://sourceforge.net/projects/strategic/

questo articolo e` stato inviato via web dal servizio gratuito
http://www.newsland.it/news segnala gli abusi ad ***@newsland.it
dmec
2005-03-23 13:08:19 UTC
Permalink
Vincent Vega wrote: [CUT]
Post by Vincent Vega
Appunto.
Se per qualche ragione più o meno esoterica cambi il disco di avvio,
penso che qualsiasi sistema non parta. Salvo che non abbia un boot
loader opportunamente preparato e configurato sul MBR del nuovo disco di
avvio.
Come descritto un po' piu su' nel trhead, con GRUB ci sono buone
possibilita' di "recuperare" il boot , il problema (mio), e' che GRUB non
lo uso e lo conosco poco, preferisco lilo .......
--
http://wiki.news.nic.it/QuotarBene
http://slax.linux-live.org
http://www.slacky.it
Ottavio Campana
2005-03-23 12:42:00 UTC
Permalink
Post by Vincent Vega
Post by Ottavio Campana
Adesso dimmi, e' una cosa sana?
Infatti mi sembra strano. Non che windows si sia bloccato, ma che sia
partito fino a bloccarsi.
no perche'? il bios cerca un master boot record avviabile su tutti i
dischi prima di piantarsi, quindi anche lilo o grub partirebbero. E poi
si pianterebbero (leggi sotto).

Anzi se ci fosse grub potresti farlo boottare quasi indolore passando
per la sua command line, cosa che in lilo non e' possibile. :-)
Post by Vincent Vega
Una curiosità: se il primo disco si chiamava /dev/hda e se sul suo boot
record c'era il lilo/grub, cosa succede al successivo avvio se il cable
select decidesse di invertire primary master e slave?
il discorso e' che ritogliendo il disco se windows ha girato le lettere
hai buone probabilita' di non ripartire piu'.

Ovvio che passando da master a slave qualsiasi sistema operativo si
pianta. Peccato che con le unita' logiche e windows la cosa risulti
spesso molto dolorosa ed irreversibile.

Dove voglio arrivare con questo discorso?

Semplice: il meccanismo di mount / umount secondo me sebbene sia piu'
vecchio e' migliore di quello delle unita' logiche. Vuoi (ti tocca)
spostare un disco? bene cambi l'fstab e sei contento. La cosa e' meno
semplice in windows.
Raffaele Castagno
2005-03-23 12:53:51 UTC
Permalink
Post by Ottavio Campana
no perche'? il bios cerca un master boot record avviabile su tutti i
dischi prima di piantarsi, quindi anche lilo o grub partirebbero. E poi
si pianterebbero (leggi sotto).
Ma non sputtanerebbero niente.
Post by Ottavio Campana
Anzi se ci fosse grub potresti farlo boottare quasi indolore passando
per la sua command line, cosa che in lilo non e' possibile. :-)
come no?
linux root=/dev/hda2 rw

non dovrebbe funzionare, così?
Post by Ottavio Campana
Semplice: il meccanismo di mount / umount secondo me sebbene sia piu'
vecchio e' migliore di quello delle unita' logiche. Vuoi (ti tocca)
spostare un disco? bene cambi l'fstab e sei contento. La cosa e' meno
semplice in windows.
Quoto in toto.

Raffaele
--
Raffaele Castagno

Mail me if you want a GMAIL account.

Not only bad news: http://www.goodnewsiraq.com
Iraq Linux User Group : http://www.iraqilinux.org
Strategic Blog: http://strategic-game.blogspot.com/
Strategic Sourceforge Homepage: http://strategic.sourceforge.net/
Strategic Sourceforge Project: http://sourceforge.net/projects/strategic/

questo articolo e` stato inviato via web dal servizio gratuito
http://www.newsland.it/news segnala gli abusi ad ***@newsland.it
Ottavio Campana
2005-03-23 13:12:04 UTC
Permalink
Post by Raffaele Castagno
Post by Ottavio Campana
no perche'? il bios cerca un master boot record avviabile su tutti i
dischi prima di piantarsi, quindi anche lilo o grub partirebbero. E poi
si pianterebbero (leggi sotto).
Ma non sputtanerebbero niente.
gia'
Post by Raffaele Castagno
Post by Ottavio Campana
Anzi se ci fosse grub potresti farlo boottare quasi indolore passando
per la sua command line, cosa che in lilo non e' possibile. :-)
come no?
linux root=/dev/hda2 rw
non dovrebbe funzionare, così?
e init che cerca di montare i pezzi dove lo metti? :-)

comunque vero passando anche init=/bin/sh dovresti comunque riuscire a
boottare e sistemare il bootloader e fstab
Raffaele Castagno
2005-03-24 09:51:07 UTC
Permalink
Post by Ottavio Campana
Post by Raffaele Castagno
Post by Ottavio Campana
Anzi se ci fosse grub potresti farlo boottare quasi indolore passando
per la sua command line, cosa che in lilo non e' possibile. :-)
come no?
linux root=/dev/hda2 rw
non dovrebbe funzionare, così?
e init che cerca di montare i pezzi dove lo metti? :-)
comunque vero passando anche init=/bin/sh dovresti comunque riuscire a
boottare e sistemare il bootloader e fstab
Eh, qualcosa del genere. L'avevo fatto tempo fa per risolvere proprio una
situazione analoga (ovvero avevo dovuto spostare un hd...).
Inutile dire che dopo aver sistemato lilo && fstab è andato di nuovo tutto
a posto! 8D

Raffaele
--
Raffaele Castagno

Mail me if you want a GMAIL account.

Not only bad news: http://www.goodnewsiraq.com
Iraq Linux User Group : http://www.iraqilinux.org
Strategic Blog: http://strategic-game.blogspot.com/
Strategic Sourceforge Homepage: http://strategic.sourceforge.net/
Strategic Sourceforge Project: http://sourceforge.net/projects/strategic/

questo articolo e` stato inviato via web dal servizio gratuito
http://www.newsland.it/news segnala gli abusi ad ***@newsland.it
Vincent Vega
2005-03-23 15:30:40 UTC
Permalink
Post by Ottavio Campana
Post by Vincent Vega
Una curiosità: se il primo disco si chiamava /dev/hda e se sul suo
boot record c'era il lilo/grub, cosa succede al successivo avvio se il
cable select decidesse di invertire primary master e slave?
il discorso e' che ritogliendo il disco se windows ha girato le lettere
hai buone probabilita' di non ripartire piu'.
Sei certo che XP/2000/NT rimappi le unità? Ti dico la verità, non ho
provato.
(anche perchè, diciamolo, si tratta di una operazione fatta a randello...)
Post by Ottavio Campana
Dove voglio arrivare con questo discorso?
Semplice: il meccanismo di mount / umount secondo me sebbene sia piu'
vecchio e' migliore di quello delle unita' logiche. Vuoi (ti tocca)
spostare un disco? bene cambi l'fstab e sei contento. La cosa e' meno
semplice in windows.
Come dicevo, volendo le partizioni NTFS possono essere montate in
directory anzichè assegnargli una unità logica.
Vide
2005-03-23 17:34:27 UTC
Permalink
Post by Vincent Vega
Come dicevo, volendo le partizioni NTFS possono essere montate in
directory
Insomma, hanno copiato quel disprezzato sistema vecchio di 30 anni :P
--
il Vide - ICQ #5301833
http://www.heavy-metal.it
Bebe, danza, sueña siente que el viento ha sido echo para ti
NP: Nulla
Ottavio Campana
2005-03-24 07:57:01 UTC
Permalink
Post by Vide
Post by Vincent Vega
Come dicevo, volendo le partizioni NTFS possono essere montate in
directory
Insomma, hanno copiato quel disprezzato sistema vecchio di 30 anni :P
Si chiama innovazione.

come lo stack tcp/ip preso dal bsd.
Fabio Fioretti - WindoM
2005-03-24 10:54:26 UTC
Permalink
Post by Ottavio Campana
Post by Vide
Post by Vincent Vega
Come dicevo, volendo le partizioni NTFS possono essere montate in
directory
Insomma, hanno copiato quel disprezzato sistema vecchio di 30 anni :P
Si chiama innovazione.
come lo stack tcp/ip preso dal bsd.
Su questo piano io andrei molto cauto, se fossi in voi: Linux, Gnome, KDE e
una buona fetta di progetti open source non sono altro che copie di copie di
copie di altri OS, interfacce grafiche, progetti... Le vere innovazioni si
contano sulle punte delle dita.
Sembra sfugga spesso l'idea che la condivisione delle conoscenze sia la
chiave per migliorare le tecnologie: nessuno scrive niente senza copiare
qualcosa che già esiste, almeno in parte. Soprattutto se quel qualcosa è
valido e può essere copiato liberamente (vedi licenza BSD). Si può non
essere d'accordo con la licenza BSD, ma non si può puntare il dito contro
chi riusa codice rispettando la licenza...

SALUTONI,

WindoM
Ottavio Campana
2005-03-24 10:53:57 UTC
Permalink
Post by Fabio Fioretti - WindoM
Post by Ottavio Campana
Post by Vide
Post by Vincent Vega
Come dicevo, volendo le partizioni NTFS possono essere montate in
directory
Insomma, hanno copiato quel disprezzato sistema vecchio di 30 anni :P
Si chiama innovazione.
come lo stack tcp/ip preso dal bsd.
Su questo piano io andrei molto cauto, se fossi in voi: Linux, Gnome, KDE e
una buona fetta di progetti open source non sono altro che copie di copie di
copie di altri OS, interfacce grafiche, progetti... Le vere innovazioni si
contano sulle punte delle dita.
mi sembra che lo stesso Linus dica che linux e' un clone di unix.
Post by Fabio Fioretti - WindoM
Sembra sfugga spesso l'idea che la condivisione delle conoscenze sia la
chiave per migliorare le tecnologie: nessuno scrive niente senza copiare
qualcosa che già esiste, almeno in parte. Soprattutto se quel qualcosa è
valido e può essere copiato liberamente (vedi licenza BSD). Si può non
essere d'accordo con la licenza BSD, ma non si può puntare il dito contro
chi riusa codice rispettando la licenza...
ok, ma non puoi sputare nel piatto dove mangi. Piu' volte M$ ha sparato
merda su unix per poi copiarlo.
Fabio Fioretti - WindoM
2005-03-24 11:22:05 UTC
Permalink
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
Sembra sfugga spesso l'idea che la condivisione delle conoscenze sia la
chiave per migliorare le tecnologie: nessuno scrive niente senza copiare
qualcosa che già esiste, almeno in parte. Soprattutto se quel qualcosa è
valido e può essere copiato liberamente (vedi licenza BSD). Si può non
essere d'accordo con la licenza BSD, ma non si può puntare il dito contro
chi riusa codice rispettando la licenza...
ok, ma non puoi sputare nel piatto dove mangi. Piu' volte M$ ha sparato
merda su unix per poi copiarlo.
A ben vedere, invece, ha attentamente evitato di sparare merda sulle cose di
UNIX che le piacevano e da cui ha liberamente ripreso ispirazione. :-) Per
il resto, chiaramente, ha manifestato dissenso (fosse anche solo per
questioni di marketing)... altrimenti Windows sarebbe un altro clone UNIX.
Andiamo, al kernel NT e a tutto lo stack applicativo che ormai ci gira sopra
(a partire dalle API) va riconosciuta una certa originalità.

SALUTONI,

WindoM
Ottavio Campana
2005-03-24 15:11:25 UTC
Permalink
Post by Fabio Fioretti - WindoM
A ben vedere, invece, ha attentamente evitato di sparare merda sulle cose di
UNIX che le piacevano e da cui ha liberamente ripreso ispirazione. :-) Per
il resto, chiaramente, ha manifestato dissenso (fosse anche solo per
questioni di marketing)... altrimenti Windows sarebbe un altro clone UNIX.
Andiamo, al kernel NT e a tutto lo stack applicativo che ormai ci gira sopra
(a partire dalle API) va riconosciuta una certa originalità.
http://www.windowsitpro.com/Articles/Print.cfm?ArticleID=4494
Fabio Fioretti - WindoM
2005-03-24 15:22:55 UTC
Permalink
Post by Ottavio Campana
http://www.windowsitpro.com/Articles/Print.cfm?ArticleID=4494
E' il solito discorso: "stand on the shoulder of giants". Niente si
costruisce dal niente, ma se ne è fatta di strada da VMS...
;-)

SALUTONI,

WindoM
Vincent Vega
2005-03-24 10:20:03 UTC
Permalink
Post by Vide
Post by Vincent Vega
Come dicevo, volendo le partizioni NTFS possono essere montate in
directory
Insomma, hanno copiato quel disprezzato sistema vecchio di 30 anni :P
O se preferisci, hanno "copiato" quello che valeva la pena di copiare e
non hanno copiato la maggioranza che non ne vale la pena. Qualunque cosa
migliora se eredita dal passato i pregi ed elimina i difetti, non
ereditando in blocco anche i difetti e poi usare la fede per convincere
se stessi e gli altri che sono pregi anche quelli <grin>
Ottavio Campana
2005-03-24 07:56:33 UTC
Permalink
Post by Vincent Vega
Sei certo che XP/2000/NT rimappi le unità? Ti dico la verità, non ho
provato.
(anche perchè, diciamolo, si tratta di una operazione fatta a randello...)
si', sono testimone del 2000. E non solo io.
Post by Vincent Vega
Post by Ottavio Campana
Dove voglio arrivare con questo discorso?
Semplice: il meccanismo di mount / umount secondo me sebbene sia piu'
vecchio e' migliore di quello delle unita' logiche. Vuoi (ti tocca)
spostare un disco? bene cambi l'fstab e sei contento. La cosa e' meno
semplice in windows.
Come dicevo, volendo le partizioni NTFS possono essere montate in
directory anzichè assegnargli una unità logica.
e come fai con le lettere? Esempio supponi di avere due dischi, C e D e
un cd che fa sotto E. Se stacchi il secondo disco da D e lo monti da
qualche parte, cosa succede alla lettera del lettore cd?

Comunque se mi dai un link al fatto che i dischi ntfs si possono
montare, leggerei volentieri.
Vincent Vega
2005-03-24 10:03:17 UTC
Permalink
Post by Ottavio Campana
Comunque se mi dai un link al fatto che i dischi ntfs si possono
montare, leggerei volentieri.
http://www.google.it/search?q=mountvol
Arcimboldo
2005-03-23 12:51:00 UTC
Permalink
Post by Vincent Vega
Una curiosità: se il primo disco si chiamava /dev/hda e se sul suo
boot record c'era il lilo/grub, cosa succede al successivo avvio se il
cable select decidesse di invertire primary master e slave?
Dipende. lilo probabilmente non parte. con grub puoi dire quale kernel
usare e dove sta. All'avvio se nell'fstab hai specificato le device
probabilmente si blocca ad un certo punto e devi modificare
/etc/fstab, mentre se hai specificato i label non se ne dovrebbe
neanche accorgere.

Con grub pero' dovresti anche poter sistemare con un piccolo hack,
"scambiando" i due dischi, e allora lo slave diventa hda.

.a.
--
Il mattino ha l'oro in bocca. Il MATTino ha l'OrO In bOcca.
i lma tt ino ha l'o roin bocc a.ilmattinohal'oroinbocca. il ma tt in
oh al' or oi nb oc ca. il matti noha l'oroinbocca. IL MATtiNO Ha l'ORO
InBOCCa. I l m a t t i n o h a l' o r o i n b o c c a . ilmattinohal'oroin
BoCcA. iLmAtTiNoHaL'oRoInBoCcA.
Ottavio Campana
2005-03-23 13:20:51 UTC
Permalink
Post by Arcimboldo
Con grub pero' dovresti anche poter sistemare con un piccolo hack,
"scambiando" i due dischi, e allora lo slave diventa hda.
si', con grub si hanno molte piu' possibilita' perche' e' molto piu'
flessibile.
Raffaele Castagno
2005-03-23 12:48:43 UTC
Permalink
Post by Ottavio Campana
E' una questione di punti di vista. Io reputo una sciagura divina le
unita' logiche. Cazzarola se inserisco un nuovo disco in un pc non mi
devono cambiare le lettere.....
Oppure quando installi programmini con setup non troppo evoluto che si
ostinano a voler installare su c:, mentre windows xp ha deciso che il
disco principale è d:... -_-

Raffaele
--
Raffaele Castagno

Mail me if you want a GMAIL account.

Not only bad news: http://www.goodnewsiraq.com
Iraq Linux User Group : http://www.iraqilinux.org
Strategic Blog: http://strategic-game.blogspot.com/
Strategic Sourceforge Homepage: http://strategic.sourceforge.net/
Strategic Sourceforge Project: http://sourceforge.net/projects/strategic/

questo articolo e` stato inviato via web dal servizio gratuito
http://www.newsland.it/news segnala gli abusi ad ***@newsland.it
Lorenzo Allegrucci
2005-03-22 16:50:02 UTC
Permalink
Post by GdG
Post by Fabio Fioretti - WindoM
Apro un nuovo thread in cerca di chiarimenti su quelli che, a detta di
alcuni di voi, sarebbero i peggiori errori alla base dello sviluppo di
Linux, a partire dall'architettura. Argomentiamo un po' le
affermazioni fatte nel thread "grandissima Microsoft"?
Il primo, comunque ora non più cosi evidente, la "staticità" intesa come
mancanza di innovazione. Bada bene, non in senso deleterio, ma come spirito
conservatore.
Insomma il non mettere mai in discussione le scelte architetturali di Unix.
Il fatto è che nel tempo si sono rivelate buone, almeno per per certi ambiti
e l'innovazione oggi si gioca in userspace, secondo me.
GdG
2005-03-22 17:27:14 UTC
Permalink
Post by Lorenzo Allegrucci
Il fatto è che nel tempo si sono rivelate buone, almeno per per certi
ambiti e l'innovazione oggi si gioca in userspace, secondo me.
Anche la propulsione con motori a ciclo Otto si è rivelata "buona".
Avere dei propulsori elettrici alimentati a celle di combustibile sarebbe
meglio.
Daniele Orlandi
2005-03-22 19:40:15 UTC
Permalink
Endymion
2005-03-24 08:19:55 UTC
Permalink
Dipende dal punto di vista. Dal punto di vista energetico,
considerando le fonti attuali, qualunque propulsione è peggio del
motore diesel. Un po' peggio il ciclo otto, MOLTO peggio, le celle a
combustibile.
Scusa, puoi quantificare? In che senso le celle a combustibile sarebbero
peggio del diesel dal punto di vista energetico?

Saluti.
Ciao.
Daniele Orlandi
2005-03-24 11:12:29 UTC
Permalink
Post by Endymion
Scusa, puoi quantificare? In che senso le celle a combustibile sarebbero
peggio del diesel dal punto di vista energetico?
Quantificare? Posso solo farlo spannometricamente... comunque considerando
che la nostra fonte di energia è il petrolio, il processo che raffina il
petrolo, lo distribuisce sotto forma di gasolio e lo utilizza in un motore
diesel è di gran lunga più efficente del processo per cui si brucia
petrolio per produrre energia elettrica con la quale si produce idrogeno
che poi si usa nell'auto.

Quantificando, significa che ci vuole più o meno il doppio di petrolio per
fare gli stessi chilometri.

Certo, se invece avessimo energia in abbondanza, chessò, dalla fusione
nucleare, allora l'idrogeno *potrebbe* diventare molto interessante, sempre
che si riesca a renderlo "gestibile"...

Ciao.
--
Daniele Orlandi
Sensei
2005-03-24 14:27:10 UTC
Permalink
Post by Daniele Orlandi
Quantificare? Posso solo farlo spannometricamente... comunque considerando
che la nostra fonte di energia Ú il petrolio, il processo che raffina il
petrolo, lo distribuisce sotto forma di gasolio e lo utilizza in un motore
diesel Ú di gran lunga più efficente del processo per cui si brucia
petrolio per produrre energia elettrica con la quale si produce idrogeno
che poi si usa nell'auto.
Non Ú proprio da quello che si produce l'idrogeno, i sottoprodotti delle
ammonie ad esempio, per idrolisi, insomma ce ne stanno.

Le celle a combustibile non inquinano nulla, ma semplicemente si sposta
il punto di inquinamento.

Quantificando, pochi punti di inquinamento sono meglio, poichÚ più
facilmente ottimizzabili, in modo da farli inquinare di meno. Le
automobili non sono tutte ottimizzabili, il parco installato Ú enorme. E
inquinano da ira-di-dio.
Post by Daniele Orlandi
Certo, se invece avessimo energia in abbondanza, chessò, dalla fusione
nucleare, allora l'idrogeno *potrebbe* diventare molto interessante, sempre
che si riesca a renderlo "gestibile"...
Naaaa, la fusione... anni e anni... meglio l'idrogeno puro, anche il
metano se bruciato bene.
--
Sensei <mailto:***@tin.it> <pgp:8998A2DB>
<icqnum:241572242>
<yahoo!:sensei_sen>
<msn-id:***@hotmail.com>
Daniele Orlandi
2005-03-24 15:11:57 UTC
Permalink
Non è proprio da quello che si produce l'idrogeno, i sottoprodotti delle
ammonie ad esempio, per idrolisi, insomma ce ne stanno.
Lo so che ci sono altri processi, ad esempio il reforming degli idrocarburi,
non conosco il processo che tu citi ma da qualche parte l'energia devi pur
mettercela... come funziona?
Le celle a combustibile non inquinano nulla, ma semplicemente si sposta
il punto di inquinamento.
Questo non lo nego ma siamo disposti a spendere il doppio di energia per
ottenere ciò?
Quantificando, pochi punti di inquinamento sono meglio, poichè più
facilmente ottimizzabili, in modo da farli inquinare di meno. Le
automobili non sono tutte ottimizzabili, il parco installato è enorme. E
inquinano da ira-di-dio.
Vero... ma io stavo parlando solo dal punto di vista energetico (era nelle
ipotesi)... per il quale confermo che un motore diesel è più efficiente.
Post by Daniele Orlandi
Certo, se invece avessimo energia in abbondanza, chessò, dalla fusione
nucleare, allora l'idrogeno *potrebbe* diventare molto interessante,
sempre che si riesca a renderlo "gestibile"...
Naaaa, la fusione... anni e anni... meglio l'idrogeno puro, anche il
metano se bruciato bene.
Cos'è, possiedi un giacimento di idrogeno elementare e non lo dici a
nessuno?

Non puoi dire meglio l'idrogeno della fusione perché stai paragonando mele
con arance.

Ciao.
--
Daniele Orlandi
Sensei
2005-03-24 16:10:22 UTC
Permalink
Post by Daniele Orlandi
Lo so che ci sono altri processi, ad esempio il reforming degli idrocarburi,
non conosco il processo che tu citi ma da qualche parte l'energia devi pur
mettercela... come funziona?
Come tutti i processi... si spende energia, la si perde e si ottengono i
prodotti... nulla Ú aggratise!
Post by Daniele Orlandi
Questo non lo nego ma siamo disposti a spendere il doppio di energia per
ottenere ciò?
Dipende, il fatto Ú che la produzione di idrogeno può (dovrà) essere un
side-effect di altri processi: insomma, perchÚ buttare l'idrogeno di scarto?
Post by Daniele Orlandi
Vero... ma io stavo parlando solo dal punto di vista energetico (era nelle
ipotesi)... per il quale confermo che un motore diesel Ú più efficiente.
Di un benzina sicuro, di una cella di combustibile no... devi contare
solo l'efficenza del motore in se stesso, non la produzione del
carburante, altrimenti anche il diesel Ú inefficiente (le pompe? il
trasposrto? la ricerca dei giacimenti? la produzione di barili? ...)
Post by Daniele Orlandi
Cos'Ú, possiedi un giacimento di idrogeno elementare e non lo dici a
nessuno?
No! Posseggo giove ed ho la tecnologia per prendere da li idrogeno e
portarlo qui... a costo nullo :)
Post by Daniele Orlandi
Non puoi dire meglio l'idrogeno della fusione perché stai paragonando mele
con arance.
Non ho detto che Ú meglio in senso assoluto, o detto che Ú meglio perchÚ
Ú anni ed anni dall'essere realizzato... Ú una tecnologia futuribile,
non attuale. Purtroppo. Meglio portare al più presto tutto sull'idrogeno
piuttosto che su idrocarburi.
--
Sensei <mailto:***@tin.it> <pgp:8998A2DB>
<icqnum:241572242>
<yahoo!:sensei_sen>
<msn-id:***@hotmail.com>
Daniele Orlandi
2005-03-24 16:55:07 UTC
Permalink
Post by Sensei
Come tutti i processi... si spende energia, la si perde e si ottengono i
prodotti... nulla è aggratise!
Certo certo, non stavo speculando che fosse un processo non
termodinamicamente valido, ti chiedevo solo come funzionasse.
Post by Sensei
Post by Daniele Orlandi
Questo non lo nego ma siamo disposti a spendere il doppio di energia per
ottenere ciò?
Dipende, il fatto è che la produzione di idrogeno può (dovrà) essere un
side-effect di altri processi: insomma, perchè buttare l'idrogeno di
scarto?
Io però ipotizzo che questo "idrogeno di scarto" non sia neanche
lontanamente abbastanza per crearci un'economia che comprenda
l'autotrazione di massa :)
Post by Sensei
Di un benzina sicuro, di una cella di combustibile no... devi contare
solo l'efficenza del motore in se stesso, non la produzione del
carburante, altrimenti anche il diesel è inefficiente (le pompe? il
trasposrto? la ricerca dei giacimenti?
Devi partire dalla fonte di energia in entrambi i casi:

Diesel:

Ricerca dei giacimenti, trivellazione, estrazione (trascurabile)
Raffinazione (poche perdite)
Trasporto (poche perdite)
Motore diesel (media efficienza)

Idrogeno

Ricerca dei giacimenti, trivellazione, estrazione (trascurabile)
Niente raffinazione
Trasporto
Conversione del petrolio in idrogeno (grosse perdite)
Trasporto dell'idrogeno (perdite per compressione e/o liquefazione)
Cella+Motore elettrico (alto rendimento)

L'anello debole è la "Conversione del petrolio in idrogeno" che fa calare
drasticamente il rendimento complessivo... quindi... per fare il solito
chilometro devi usare più petrolio...
Post by Sensei
la produzione di barili? ...)
Ehm... il barile è un'unità di misura... poi non si usa veramente per
trasportare il petrolio...

Ciao.
Post by Sensei
Post by Daniele Orlandi
Cos'è, possiedi un giacimento di idrogeno elementare e non lo dici a
nessuno?
No! Posseggo giove ed ho la tecnologia per prendere da li idrogeno e
portarlo qui... a costo nullo :)
Post by Daniele Orlandi
Non puoi dire meglio l'idrogeno della fusione perché stai paragonando
mele con arance.
Non ho detto che è meglio in senso assoluto, o detto che è meglio perchè
è anni ed anni dall'essere realizzato... è una tecnologia futuribile,
non attuale. Purtroppo. Meglio portare al più presto tutto sull'idrogeno
piuttosto che su idrocarburi.
--
Daniele Orlandi
Vegeta
2005-03-24 17:09:55 UTC
Permalink
Post by Daniele Orlandi
Idrogeno
Ricerca dei giacimenti, trivellazione, estrazione (trascurabile)
Niente raffinazione
Trasporto
*** > Conversione del petrolio in idrogeno (grosse perdite)
*** > Trasporto dell'idrogeno (perdite per compressione e/o liquefazione)
Post by Daniele Orlandi
Cella+Motore elettrico (alto rendimento)
L'anello debole è la "Conversione del petrolio in idrogeno" che fa calare
drasticamente il rendimento complessivo... quindi... per fare il solito
chilometro devi usare più petrolio...
Ci sono due errori: innanzitutto non è vero che la
conversione petrolio/idrogeno ti debba portare a
grosse perdite. Perchè? Il processo di reforming
degli idrocarburi di tipo SMR ha un rendimento
del 65%. Vero. Ma esistono allo studio tecnologie
più avanzate (SER), che promettono di portare
il rendimento a valori intorno all'80% (sostanzialmente,
eseguendo una reazione chimica di conversione
a temperature più basse e pressioni più elevate,
rimuovendo selettivamente i sottoprodotti di
reazione in modo da spostare ancora più a destra
l'equilibrio della reazione).

In secondo luogo, il trasporto di idrogeno non avverrà
per compressione o liquefazione. Non per altro, perchè
l'idrogeno può essere liquefatto solo quando al di sotto
della sua temperatura critica e questo aumenterebbe
drammaticamente il costo della rete di distribuzione.
Sono allo studio meccanismi di confinamento chimico
basati su idruro di litio: questo sale ha la capacità di
assorbire notevoli quantità di idrogeno e di rilasciarlo
spontaneamente quando posto a contatto con l'acqua.

Saluti
Vegeta
Daniele Orlandi
2005-03-24 17:35:34 UTC
Permalink
Vegeta
2005-03-24 18:57:12 UTC
Permalink
Post by Vegeta
Sono allo studio meccanismi di confinamento chimico
basati su idruro di litio: questo sale ha la capacit di
assorbire notevoli quantit di idrogeno e di rilasciarlo
spontaneamente quando posto a contatto con l'acqua.
Ottimo e quale sarebbe il rendimento ipotizzato di questo metodo?
Come si confronta con il trasporto dell'idrogeno liquido in termini di
densità?
Prova su google: Erg H2Fuel bus project.
Daniele Orlandi
2005-03-24 20:26:05 UTC
Permalink
Sensei
2005-03-24 20:01:50 UTC
Permalink
Io però ipotizzo che questo "idrogeno di scarto" non sia neanche
lontanamente abbastanza per crearci un'economia che comprenda
l'autotrazione di massa :)
Più di quanto tu creda :) Insomma, tanto per fare una analogia, le
centrali elettriche a turbina (nucleari o a combustibile fossile che
sia) riscaldano acqua. Una volta terminato si butta via l'acqua calda
(ex vapore). A qualcuno venne in mente di utilizzarla... nelle case.
Ricerca dei giacimenti, trivellazione, estrazione (trascurabile)
Raffinazione (poche perdite)
Trasporto (poche perdite)
Motore diesel (media efficienza)
Media efficienza = 15% (forse)

Tutti i processi involvono l'uso di energia, tutti. Immagina un po'
quanto Ú inefficiente una trivellazione? E la ricerca? E l'estrazione?
La raffinazione? Il trasporto lo devi fare con oleodotti, poi via terra
con barili (si usano ancora sai? il gasolio non Ú usato solo per la
combustione...) ovvero con altri motori diesel (10~15% di efficienza).
Idrogeno
Ricerca dei giacimenti, trivellazione, estrazione (trascurabile)
Non ci sono giacimenti di idrogeno :)
Niente raffinazione
Mica vero... Ú lo scarto di altri prodotti. Si farà stanne certo.
Trasporto
Si.
Conversione del petrolio in idrogeno (grosse perdite)
PerchÚ dal petrolio!? Sappi che si fa di tutto per abbandonarlo, visto
che Ú una fonte in esaurimento. Altre vie sono allo studio. Fattelo in
casa: acqua, sale, idrolisi, ottieni varecchina e idrogeno di scarto
(tanto per fare un esempio).
Trasporto dell'idrogeno (perdite per compressione e/o liquefazione)
Trascurabili.
Cella+Motore elettrico (alto rendimento)
~90% se non più.
L'anello debole Ú la "Conversione del petrolio in idrogeno" che fa calare
drasticamente il rendimento complessivo... quindi... per fare il solito
chilometro devi usare più petrolio...
No, niente petrolio!
Ehm... il barile Ú un'unità di misura... poi non si usa veramente per
trasportare il petrolio...
Si nelle grosse piattaforme di distribuzione per combustibili fossili
certo che il barile Ú inefficiente. Ma quando me lo devono consegnare in
laboratorio un paio di barili per altri usi... si usa ancora, come
l'olio Ú ancora in barili, come i lubrificanti...
--
Sensei <mailto:***@tin.it> <pgp:8998A2DB>
<icqnum:241572242>
<yahoo!:sensei_sen>
<msn-id:***@hotmail.com>
Daniele Orlandi
2005-03-24 20:46:56 UTC
Permalink
Più di quanto tu creda :)
Perché nessuno se n'è accorto? Cosa ne fanno, riempiono dirigibili e poi gli
danno fuoco? :)
Insomma, tanto per fare una analogia, le
centrali elettriche a turbina (nucleari o a combustibile fossile che
sia) riscaldano acqua. Una volta terminato si butta via l'acqua calda
(ex vapore). A qualcuno venne in mente di utilizzarla... nelle case.
Va bene ma un po' di acqua calda nelle immediate vicinanze della centrale
non è paragonabile ad un parco veicoli di decine di milioni di unità che
consuma qualche TWh ogni giorno.
Tutti i processi involvono l'uso di energia, tutti. Immagina un po'
quanto è inefficiente una trivellazione?
Inefficiente? Insomma... fai un buco e tiri fuori tonnellate di petrolio :)
E la ricerca? E l'estrazione?
Non ho dati... ma quanta energia vuoi impiegare per trovare il petrolio? Se
ti va male e non sei sulla terra ferma ti serve una nave... spero non per
troppi mesi, sennò il personale ti costerebbe più di quanto ricaveresti :)

L'estrazione? Se ci si permette di pompare acqua in un bacino su e giù solo
per compensare gli assorbimenti nella rete elettrica, vuol dire che il
lavoro di pompaggio non è così costoso, rispetto al volume :)
La raffinazione?
La raffinazione non è energeticamente così costosa anche se la sua parte ce
l'ha... alla fine devi solo scaldare il petrolio e farlo condensare nelle
torri di frazionamento... ovvio che quello che non diventa gasolio non lo
considero "buttato via"...
Il trasporto lo devi fare con oleodotti, poi via terra
con barili (si usano ancora sai?
Sarà... ma io vedo quotidianamente cisterne e petroliere ma quasi mai
montagne di barili...
il gasolio non è usato solo per la combustione...)
Per cos'altro viene usato? Pensi che questi altri usi siano percentualente
rilevanti, oltre all'autotrazione e al riscaldamento.
Non ci sono giacimenti di idrogeno :)
Di petrolio, intendevo... dopo si sarebbe capito.
Mica vero... è lo scarto di altri prodotti. Si farà stanne certo.
Ma questi milioni di tonnellate di idrogeno come prodotto di scarto io
continuo a non vederle, sai? :)
Post by Daniele Orlandi
Conversione del petrolio in idrogeno (grosse perdite)
Perchè dal petrolio!? Sappi che si fa di tutto per abbandonarlo, visto
che è una fonte in esaurimento
Se hai un'altra fonte energetica alternativa, sappi che potresti salvare
l'umanità.

Il nucleare è una fonte alternativa ma, ahinoi, non piace.
L'eolico è conventiente, assolutamente da spingere ma non potrà mai essere
alternativo al petrolio.
Il fotovoltaico per ora non conviene.

Hai la fusione nucleare economica e funzionante e non ce lo dici?
Altre vie sono allo studio. Fattelo in
casa: acqua, sale, idrolisi, ottieni varecchina e idrogeno di scarto
(tanto per fare un esempio).
Sei azionista Enel?
Post by Daniele Orlandi
Trasporto dell'idrogeno (perdite per compressione e/o liquefazione)
Trascurabili.
Trascurabili?!?!
Hai idea di quanto lavoro devi fare per raffreddarlo sotto la temperatura
critica (eh sì, perché altrimenti non diventa liquido :))
Post by Daniele Orlandi
Cella+Motore elettrico (alto rendimento)
~90% se non più.
Come sei ottimista :)
No, niente petrolio!
L'energia di punto zero?
Ma quando me lo devono consegnare in
laboratorio un paio di barili per altri usi... si usa ancora, come
l'olio è ancora in barili, come i lubrificanti...
Una quantità immensa, rispetto a quello prodotto :)
(e cosa c'entra l'olio?)

ciao,
--
Daniele Orlandi
Vegeta
2005-03-24 21:14:24 UTC
Permalink
Post by Daniele Orlandi
Più di quanto tu creda :)
Perché nessuno se n'è accorto? Cosa ne fanno, riempiono dirigibili e poi gli
danno fuoco? :)
Permettimi di fare un osservazione. Fino a
questo momento l'idrogeno non è stato spinto a
sufficienza per un semplicissimo motivo: nella
trazione degli autoveicoli, è difficilissimo
trasportarlo. E' questo il primo problema: per
liquefare l'idrogeno, devi portarlo sotto la sua
temperatura critica. Questo ha delle drammatiche
conseguenze in termini di sicurezza del veicolo,
costo del rifornimento, costo degli impianti di
distribuzione, rischio per i passeggeri del veicolo.

Adesso si parla di auto ad idrogeno perchè si
sta pensando a dei meccanismi di confinamento
chimico (appunto LiH), che non richiedendo
basse temperature (funzionano a temperatura
ambiente), eliminano i problemi suddetti.

Cio nonostante, il problema della produzione di
idrogeno, è veramente l'ultimo dei problemi.

Per esempio, esistono da decenni degli impianti
che trasformano il carbonio e acqua in metano
ed idrogeno (reazione del gas d'acqua). In pratica,
si tratta di una tecnica per ridurre l'impatto
ambientale del carbone (invece di bruciare carbone,
lo si trasforma in metano, e si separano i componenti
solforosi prima di entrare nel bruciatore; a quel
punto, metano ed idrogeno potrebbero essere
inviati ad una pila a combustibile). Il carbone costa
poco ed è ben distribuito in tutto il pianeta.

Esistono diversi modi per ottenere idrogeno come
sottoprodotto di una reazione: il problema è che
di solito non si ha alcun interesse ad ottenere
idrogeno perchè tanto le pile a combustibile
non sono diffuse.
Post by Daniele Orlandi
Se hai un'altra fonte energetica alternativa, sappi che potresti salvare
l'umanità.
Il nucleare è una fonte alternativa ma, ahinoi, non piace.
L'eolico è conventiente, assolutamente da spingere ma non potrà mai essere
alternativo al petrolio.
Il fotovoltaico per ora non conviene.
Hai la fusione nucleare economica e funzionante e non ce lo dici?
Io no, ma conosco qualcuno che qualche idea in
proposito ce l'ha....

http://www.progettomeg.it/FFredda.htm

Si noti che il fenomeno è stato già riprodotto da
decine di persone, è facile e poco costoso da
riprodurre, ed è documentato con precisione.

Sto ancora cercando di convincere i colleghi
del mio dipartimento di Fisica a costruire una
cella di Naudin.

Riguardo poi al fatto che sia fusione, si rileva
presenza di elio, neutroni, decadimento del
tungsteno (con formazione di metalli rari come
renio, osmio, itterbio ed elementi transuranici
in quantità), ed un rendimento energetico della
cella di molto superiore ad 1.

Riguardo all'autotrazione, è possibile usare
olio di canapa geneticamente modificata con
il gene del Tricoderma viridis per aumentarne
ancora di più la resa. Non si tratta di quella
cretinata dell'olio di colza (che abbiamo sentito
di recente sui giornali), ma di un carburante
ancora più efficiente che viene ottenuto trattando
l'olio di canapa (ed ottenendo glicerina come
sottoprodotto).
Post by Daniele Orlandi
Altre vie sono allo studio. Fattelo in
casa: acqua, sale, idrolisi, ottieni varecchina e idrogeno di scarto
(tanto per fare un esempio).
Sei azionista Enel?
Post by Daniele Orlandi
Trasporto dell'idrogeno (perdite per compressione e/o liquefazione)
Trascurabili.
Trascurabili?!?!
Hai idea di quanto lavoro devi fare per raffreddarlo sotto la temperatura
critica (eh sì, perché altrimenti non diventa liquido :))
Post by Daniele Orlandi
Cella+Motore elettrico (alto rendimento)
~90% se non più.
Come sei ottimista :)
No. Non è ottimista. Per le celle ad idrogeno è
proprio 90% o più.
E' possibile dimostrarlo.

Saluti
Vegeta
Vegeta
2005-03-24 16:53:34 UTC
Permalink
Anche la propulsione con motori a ciclo Otto si rivelata "buona".
Avere dei propulsori elettrici alimentati a celle di combustibile sarebbe
meglio.
Dipende dal punto di vista. Dal punto di vista energetico, considerando le
fonti attuali, qualunque propulsione è peggio del motore diesel. Un po'
peggio il ciclo otto, MOLTO peggio, le celle a combustibile.
Ciao.
Ti sbagli. MOLTO meglio le celle a combustibile.

Il vantaggio delle celle a combustibile, sta nell'eludere
il secondo principio della termodinamica.

Sappiamo dalla termodinamica che il rendimento di
una macchina di Carnot (totalmente ideale), è dato
da 1-Tl/Th dove Tl è la temperatura assoluta del
serbatoio a temperatura più bassa. Inoltre, è possibile
dimostrare che nessuna macchina termica reale
è in grado di superare il rendimento di una macchina
di Carnot che lavori alle medesime temperature.

Dalla formule, si nota che l'unico modo per avere un
rendimento del 100%, è avere un serbatoio a Tl=0,
ossia allo zero assoluto (cosa di fatto non realizzabile,
a causa del terzo principio della termodinamica).

Segue una realtà: se provate a convertire calore in
lavoro, per mezzo di una macchina termica, otterrete
solo una percentuale dell'energia che state bruciando
come lavoro meccanico. Il resto, sarà mandato al
tubo di scappamento (serbatoio a bassa temperatura),
ed anche se è ancora lì, non sapremo che farcene
(una volta che il calore viene disperso nell'atmosfera
non è più possibile riutilizzarlo).

Questa realtà fisica, che porta al concetto di entropia,
viene spesso enunciata dicendo che se nell'universo
tutti i corpi fossero alla medesima temperatura, ci
sarebbe molta energia sparsa per il mondo... ma non
sapremmo che farcene.

Attenzione però, perchè il secondo principio della
termodinamica vale solo per le conversioni calore/lavoro.
Non vale, invece, per altri tipi di conversione energetica.

Allora, supponiamo di avere 100 J immagazzinati sotto
forma di energia chimica in una certa quantità di
metano.

Se seguiamo l'approccio convenzionale, ossia bruciamo
il metano, otterremo al massimo 100 J di energia termica
(e neanche, ma supponiamo...). Di questi, solo 30-35 J
saranno convertiti in lavoro meccanico, proprio a causa
del secondo principio della termodinamica.

Se seguiamo l'approccio pila a combustibile, attraverso
l'equazione di Nerst possiamo calcolare che siamo in
grado di convertire il 90-95% dell'energia chimica
del metano (energia libera di Gibbs), in energia elettrica.

A quel punto, abbiamo 95 J di energia elettrica che
possono essere inviati ad un motore elettrico, ottenendo
95 J di energia meccanica.

Si noti dunque, che la superiorità dell'uso delle pile a
combustibile non è legata al fatto che si usi idrogeno
(come comunemente si crede negli ambiti non scientifici):
in realtà l'idrogeno in queste applicazioni fa solo da
vettore energetico e non sarebbe decisivo se non per
un particolare (e cioè che sino all'anno scorso non
avevamo pile a combustibile che usassero direttamente
idrocarburi, e quindi era necessario usare un reforming
del metano per produrre idrogeno, e poi con quello
alimentare la pila a combustibile idrogeno-ossigeno).

Il vero vantaggio dell'uso delle pile a combustibile
consiste nel fatto che non c'è nessuna conversione
calore/lavoro, e di conseguenza il secondo principio
della termodinamica viene eluso.

Vorrei inoltre osservare, per pura curiosità, che non
è vero neanche che il motore diesel sia la macchina
termodinamica con il rendimento più elevato. Il
massimo che è possibile ottenere, allo stato della
tecnica, è data dal cosiddetto ciclo Stirling o a
rigenerazione, che ha rendimenti superiori rispetto
a qualsiasi motore a scoppio.

Saluti
Vegeta
Daniele Orlandi
2005-03-24 17:25:52 UTC
Permalink
Vegeta
2005-03-24 18:44:05 UTC
Permalink
Post by Vegeta
Ti sbagli. MOLTO meglio le celle a combustibile.
Se esistesseto delle celle a combustibile alimentate a gasolio :)
Non necessariamente. Ora ti spiego perchè.
Post by Vegeta
Il vantaggio delle celle a combustibile, sta nell'eludere
il secondo principio della termodinamica.
Lo spostano semplicemente nella macchina termica che brucia petrolio per
produrre idrogeno :)
No.

Ragioniamoci su.

Intanto occorrerebbe partire dal presupposto che venga
usato metano all'inizio del ciclo (esistono giacimenti da
cui si estrae solo gas).

Ora supponi di avere 100 J di energia contenuti nel
metano (lo hai appena estratto). Il processo SMR
(che è già disponibile ed operativo) ha un rendimento
del 65%. Questo significa che alla fine
ti ritrovi con 65 J contenuti nell'idrogeno.

In realtà questo non è vero, perchè non stai tenendo
conto del principio di conservazione dell'energia.

Sostanzialmente, la quantità di energia contenuta
nell'idrogeno (prodotto finale) sarà data dalla
somma di due contributi:

a) il primo, è una frazione dell'energia che era
già contenuta nel metano;
b) il secondo, è una frazione dell'energia impiegata
nel procedimento produttivo.

Ma, tenuto conto che l'energia impiegata nel
procedimento produttivo è trascurabile rispetto
alla a), supponiamo che ci sia solo la componente
a).

Questo significa che l'idrogeno che ottieni ha un
contenuto energetico di circa 65 J. Con una
cella a combustibile, puoi bruciare questo idrogeno
ottenendo circa 60 J. E' chiaro che se tu riuscissi a
migliorare il processo, otterresti circa 80 J in idrogeno
che potresti bruciare in una pila a combustibile,
ottenendo circa 70 J di elettricità.

Diversamente, se bruciassi direttamente metano in una
macchina termica (turbina), potresti ottenere al massimo
un 30-35% di rendimento, ossia dai tuoi 100 J ottieni
35 J di energia.

E' chiaro che nel primo caso ci hai guadagnato. Il tuo
ragionamento sarebbe corretto, se l'idrogeno venisse
prodotto usando elettricità, a sua volta ottenuta in una
macchina termica. Così non è. Il metano viene ottenuto
da una reazione chimica senza fare un passaggio
energia/lavoro meccanico.
Post by Vegeta
Se seguiamo l'approccio pila a combustibile, attraverso
l'equazione di Nerst possiamo calcolare che siamo in
grado di convertire il 90-95% dell'energia chimica
del metano (energia libera di Gibbs), in energia elettrica.
Peccato che non ci sia abbastanza metano per far funzionare anche le
automobili... e che se già è difficile costruire una cella che vada a
idrogeno, è difficilissimo farne una che vada a metano senza prima un bel
reformer che ti butta via il carbonio e tanta energia, è mostruosamente
difficile farne una che vada a petrolio.
Non ho mai detto "impossibile"... ma attualmente mi sembra più vicina la
fusione nucleare che non una cella a combustibile che vada a petrolio e
abbia un rendimento del 90% :)
Infatti, io ho sempre sostenuto in passato che
la vera soluzione è la cella di Naudin che produce
energia attraverso una fusione nucleare a freddo,
la quale a sua volta serve alla produzione di
elettricità.Questa è la soluzione a più alto
rendimento per il futuro.

Ciò non toglie che la tecnica delle pile a
combustibile sia più efficiente di qualsiasi motore
a combustione interna. Nota che ho detto più
efficiente, non perfettamente efficiente.
Post by Vegeta
A quel punto, abbiamo 95 J di energia elettrica che
possono essere inviati ad un motore elettrico, ottenendo
95 J di energia meccanica.
Io VOGLIO una di queste celle a metano con rendimento del 95% perché ci
sono, vero? Non sono un prodotto teorico, vero?
Silvestroni, Fondamenti di chimica, pag. 474.
Post by Vegeta
Si noti dunque, che la superiorit dell'uso delle pile a
combustibile non legata al fatto che si usi idrogeno
in realt l'idrogeno in queste applicazioni fa solo da
vettore energetico e non sarebbe decisivo se non per
un particolare (e cio che sino all'anno scorso non
avevamo pile a combustibile che usassero direttamente
idrocarburi, e quindi era necessario usare un reforming
del metano per produrre idrogeno, e poi con quello
alimentare la pila a combustibile idrogeno-ossigeno).
Uhm... un link a queste celle a metano senza reformer?
A me risulta che esistano solo quelle a metanolo... che è un po' diverso.
http://www.energoclub.it/Fuel%20cell.htm

Notare: PAFC, SOFC, MCFC.
Post by Vegeta
Il vero vantaggio dell'uso delle pile a combustibile
consiste nel fatto che non c' nessuna conversione
calore/lavoro, e di conseguenza il secondo principio
della termodinamica viene eluso.
Già... peccato che poi, in pratica, ci vuole il doppio di petrolio per
fare
gli stessi chilometri. E' questo il nocciolo del problema.
Ma con una pila che brucia direttamente metano, o
sostanze ottenibili dal carbone a basso costo...
Post by Vegeta
Vorrei inoltre osservare, per pura curiosit, che non
vero neanche che il motore diesel sia la macchina
termodinamica con il rendimento pi elevato. Il
massimo che possibile ottenere, allo stato della
tecnica, data dal cosiddetto ciclo Stirling o a
rigenerazione, che ha rendimenti superiori rispetto
a qualsiasi motore a scoppio.
E' vero ma chiediti un po' perché i veicoli con motore Stirling sono più
una
divertente curiosità, piuttosto che la norma?
Per quanto ne so io, hanno un peso molto elevato e sono
molto complessi: sicuramente non utilizzabili nelle
autovetture.

Saluti
Vegeta
Daniele Orlandi
2005-03-24 21:14:54 UTC
Permalink
Continua a leggere su narkive:
Loading...