Newsgroup: it.comp.os.dibattiti
Titolo: Reiser4 & Co


The optimist thinks this is the best of all possible worlds.
The pessimist fears it is true.      [J. Robert Oppenheimer]

 
http://www.linux.com/article.pl?sid=06/07/31/1548201
http://kerneltrap.org/node/6922
Alcuni problemi sono stati risolti, altri rimangono.
Penso che alla fine sarà incluso.



comunque spesso non c'e' nessuna ratio nel modo in cui stabiliscono che
una cosa e' stable o unstable.
Ho visto una marea di cagate, definite "stable" e vice-versa.
C'e' da aggiungere che qualcuno avra' avuto da ridire sul funzionamento a
plugin.
According to Calleja, the main explanation for Reiser4's exclusion is that
it is not yet sufficiently tested. Reiser complains that this criticism is
not only untrue, but a double-bind.
-- 
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
  printf $i }'; echo

 not only untrue, but a double-bind.
Purtroppo l'abitudine di cambiare tutto a casaccio nel kernel e` 
volontaria (infastidisce lo sviluppo di driver binari), e credo proprio 
che reiser voglia mandare a puttane queste idiozie religiose dei kernel 
developers. Guerra in arrivo? Reiser lascera` fuori dal kernel il 
proprio fs?


 proprio fs?
Veramente sarà Linus a lasciare ReiserFS fuori dal kernel...

 kernel and tell me what you think:
credo che la discussione qui vada a finire altrove e che non dovremmo
ragionare piu' sulle semplici prestazioni di reiser4. Fra l'altro nessuno
sa ancora se ZFS avra' prestazioni eccellenti o meno. Certo e', che ZFS e'
considerato un filesystem eccellente.
Ma la discussione non e' piu' nemmeno questa, ma forse la "testardaggine"
di Torvalds e altri.
Linux ha avuto una grande fortuna, e ha dimostrato di essere un grande
progetto, anche contro certe aspettative. Ma perche' continuare a
perseguire un modello ritenuto sbagliato da tanti?
In tal senso solo il kernel di HP-UX e' piu' preistorico del kernel Linux.
Perche' devo reinstallare il driver ati/nvidia ogni volta che aggiorno il
kernel (tanto per dirne una)? Perche' tutto questo non succede su sistemi
con kernel piu' moderni, come Solaris (e imagino Mac e BSD)?
Vuoi sapere perche'?
TESTARDAGGINE.
Torvalds scrisse una volta "torniamo al tempo in cui gli uomini erano
uomini e scrivevano da se i driver per le loro periferiche". Questo
purtroppo (o per fortuna) andava sicuramente a quel tempo in cui le
periferiche erano: la stampante a matrice e 4 marche diverse di schede di
rete.
Oggi purtroppo la situazione e' diversa. Le periferiche sono migliaia e di
tipi diversi e gli sviluppatori GPL non possono correre dietro a tutti i
driver. Le webcam (tanto per dirne una) funzionano solo nel 10% dei casi.
Alcune periferiche, quando usate con i driver GPL funzionano male
(sicuramente la scheda nvidia, ma anche quella ati).
Se tu avessi la possibilita' di inserire un driver binario e di farlo
ufnzionare su tutti i kernel, gli sviluppatori potrebbero impiegare il loro
tempo su cose piu' interessante che perdere tempo a
fare reverse-engineering di una webcam e i produttori, che sono gli unici
a conoscere le specifiche del loro hardware, rilascerebbero senza problemi
i driver delle loro periferiche anche per Linux.




Onestamente, se esistesse un driver per la mia webcam che funzionasse
fuori dal kernel, io me ne strafotterei di tutti questi sofismi.
Userei il driver e basta.
Ok. Purtroppo con questo monolitico del cacchio non e' possibile.
Fra l'altro mi chiedo come faranno tra un paio di anni a mantenere dentro
al kernel tutte le migliaia di driver, passati e presenti, che
esisteranno.... potranno mettere un DB relazionale dentro al kernel per
gestire un base dati di tutti i driver esistenti LOL.
Cio' ha un senso quando sei su hardware "controllato" (su
un HP-UX non installerai mai la Viedocam Live della Genius....)
In alternativa potrebbero segare tutto cio' che "vecchio"?


 gestire un base dati di tutti i driver esistenti LOL.
Che il Tanenbaum avesse previsto proprio questo, nella sua famosa
disputa con Linus? Dall'alto della mia assoluta ignoranza in materia,
non avendo conoscenze in proposito, dico questo: ma un kernel non
dovrebbe soltanto fornire un'interfaccia per i driver dei produttori?
Io immagino che la relazione tra un kernel, un driver e l'hardware
debba essere qualcosa del tipo:
hardware--->kernel---->driver---->applicazione cioè il kernel dovrebbe
essere un mondo completamente a parte, e i driver dovrebbero essere
completamente fuori da esso. Il kernel dovrebbe limitarsi a fornire
un'interfaccia ai driver per la gestione dell'hardware, ma includere
dei driver nel kernel, quindi facendoli girare in kernel space, mi pare
assurdo, anche perchè un crash del driver crasha l'intero sistema.
O no?

 essere un mondo completamente a parte, 
Cosi' e', in modo piu' o meno accentuato sul 99% dei sistemi utilizzati
oggi. Persino il bestione di AS400 e persino il denigratissimo windows
hanno dei microkernel, e solo Linux e HP-UX hanno un kernel monolitico.
C'e' da dire che qualcosa in Linux e' cambiato rispetto al passato, ma e'
sempre pochissima cosa. Senza bisogno di cambiare kernel, basta cambiare
pochissime caratteristiche nel kernel in uso e i driver non vengono
caricati piu'... devi fare il reboot con il nuovo kernel e ricompilare il
driver: un ca$ata o ca$$ata che dir si voglia.


 esisteranno....
Lo sai che questa, in ambito linux, e' LA Domanda?
Enrico
P.S. secondo me, avranno la faccia da culo di rinnegare il bellissimo
documento stable_api_nonsense.txt dicendo che fu messo li giusto per
scherzo o che lo mise qualche sovversivo che non crede all'open
source...

 i driver delle loro periferiche anche per Linux.
I driver GPL per le periferiche, se funzionano male, non è certo per
colpa degli sviluppatori GPL, o per gli sviluppatori del kernel, o per
colpa di Linus.
Del resto, i driver NVidia funzionano bene da anni. (ma dove l'hai
letto che funzionano male? Mai avuto problemi di sorta...). Così come
funzionano bene i driver delle periferiche per le quali sono
disponibili le specifiche.
La colpa è, e resta, dei produttori hardware, che non rilasciano le
specifiche dei loro prodotti. Poi, nessuno vieta loro di percorrere la
strada già battuta da tempo da NVidia ed ATI.
Raffaele

Enrico Henryx Bianchi ha scritto:

nah, c'è una cosa che si può dire di linus, _ogni tanto_ ammette di aver 
toppato (ad esempio io mi ricordo il messaggio a proposito della grafica 
nel kernel)

 
aspetta e spera. LOL.
le specifiche hardware non le rilascera' mai nessuno. PUNTO.
Partendo da questo assunto, bisogna invertire i metodi, ovvero fare si che
si possano usare driver binari con molta semplicita'.
Come si puo' fare questo? Muoversi quanto piu' possibile verso il
micro-kernel, o far si quantomeno, che il driver non debba essere
ri-compilato per ogni release di kernel ... come avviene gia' su
*TUTTI* altri sistemi. chairo no... su Solaris e' cosi' e nemmeno su
windows mi pare che si debbano reinstallare i driver dopo aver installato
un service pack...
e cmq, tra 2 anni, quando il kernel, per includere tutti i driver
esistenti, dovra' essere 100 megabyte e richiedera' 3 giorni per la
compilazione (*) dovremo ridere o piangere?
(*) avrai notato che le compilazioni "di default" di diverse ditribuzioni
tendono a includere un 70% di tutti i driver.... in alternativa potrai
spendere 3 giorni a spuntare tutti i driver che ti servono...




vedi il problema e' che non devi dire di aver sbagliato solo quando ti
viene in mente a te che hai fatto un errore.
Devi esser capace di dire che hai sbagliato anche quando e' qualcun altro
a farti rilevare i tuoi sbagli.


 spendere 3 giorni a spuntare tutti i driver che ti servono...
In alternativa puoi evitare di ricompilare il kernel, come fai con
*TUTTI* gli altri sistemi.
--
Joe

 *TUTTI* gli altri sistemi.
Se parlo ai muri ho piu' possibilita' di essere compreso. Il fatto di
avere driver che richiedono la ricompilazione in seguito alla
installazione di un nuovo kernel fa si che:
1) ti devi rompere le palle a ricompilare. Poco male... si tratta solo di
una seccatura.
2) i produttori di hardware non rilasceranno mai driver, perche' sarebbero
costretti a rilasciarli in forma sorgenti, in quanto devono essere
ricompilati. Se linux funzionasse come solaris, i produttori hardware non
sarebbero costretti a rivelare alcun sorgente. Se ancora non ci siamo
capiti, nel caso dell'hardware il problema non e' la rivelazione del
sorgente, ma il fatto che il sorgente comprende la chiave per carpire le
specifiche dell'hardware. Questo al produttore hardware non piace.
Il driver Nvidia e' una soluzione intermedia ... che richiede comunque la
compilazione.


 driver: un ca$ata o ca$$ata che dir si voglia.
Per quanto ne so, di veramente diverso, e manco tanto, e` udev al posto 
di devfs. Per il resto, tutto in kernel space compreso il superflame 
della grafica che tanto sangue fece versare nella LKML --- per chi se 
lo ricorda.


 source...
Potrebbe, non mi stupirei di certo.


 *TUTTI* gli altri sistemi.
Solo nel caso in cui non usi alcun driver al di fuori di quelli nel 
kernel forniti dalla tua distribuzione. E` alquanto limitante per un 
utente normale non credi?


 compilazione.
Ok, ma tu parlavi di ricompilare TUTTO il kernel.
Anche tu come comprendonio non sei messo benissimo, mi pare.
--
Joe

 utente normale non credi?
Limitante non direi, semmai una seccatura. Ma rispondimi tu, almeno:
perché devi ricompilare da zero TUTTO il kernel?
--
Joe

 utente normale non credi?
ma poi ... ti pare produttivo perdere il tempo a capire come far
funzionare una webcam la rotellina del mouse, quando lo stesso lavoro puo'
essere fatto in una frazione di tempo dal produttore che conosce tutte le
specifiche del suo hardware?
A quel punto auto-magicamente tutto funzionerebbe incredibilmente meglio.
Ho perso un anno per capire perche' il mio AMD64 quando lo spegnevo non si
riaccendeva piu' e bisognava staccare la spina per 5 secondi. Ieri,
finalmente ho scoperto, che compilando i moduli powernow_k8 e
cpufreq_userspace il computer, magicamente, un istante prima dello
shutdown, da una accelerata alla ventola e si spegne. In questo caso
riparte regolarmente (tutto il sistema acpi e' un casino, e non e' gestito
bene dai demoni... ma questo e' un altro discorso).
Perche' mi e' successo questo?
Perche' nella configurazione del kernel si sta cominciando a non capire
piu' niente. 
"cat /usr/src/linux/.config |grep -v "^$"|wc -l" mi dice che ci sono
1645 righe. Questo vuol dire: 1645 opzioni configurabili. Semplicemente
pazzesco pensare di poter mettere mano a 1645 queste opzioni e tra queste
riuscire a trovare quelle che ti servono veramente.
Inoltre: "cat /usr/src/linux/.config |grep -Ev "^#|^$"|wc -l" mi dice che
io sto usando solo 465 opzioni. Consideriamo anche il fatto che il 60% di
queste opzioni sono attivate per nessuna ragione e sono li' solo perche'
non le ho mai notate prima, ne viene fuori che il kernel e' un casino che
diventera' presto ingestibile.


 - il 21 di agosto avremo anche zfs.
Intendi dire ZFS su linux? Sul serio?
Ho trovato 2 notizie a ruguardo. Una dice: NO. L'altra dice NI. Ma tutto
e' possibile.
1)
Due to licensing incompatibilities, ZFS linux code needs to be written
from scratch without reference to any opensolaris source code. ...
2)
Due to licensing incompatibilities, ZFS linux code needs to be written
from scratch without reference to any opensolaris source code. ...


 from scratch without reference to any opensolaris source code. ...
sorry....
volevo incollare questoç
Q: Any thoughts on porting ZFS to Linux, AIX, or HPUX?
A: No plans of porting to AIX and HPUX. Porting to Linux is currently
being investigated.
Ad ogni modo si tratta di un documento superato, in quanto parla della
incorporazione di ZFS in Solaris 10... come sappiamo Solaris 10 e' gia'
uscito, ma zfs no.


 
compilare un kernel, o installare una distribuzione con un kernel XYZ
compilato da altri per conto tuo, equivale a dire la stessa cosa, visto che
XYZ, considerando release e sub-realease, solo per il kernel 2.6 e' un
numero sicuramente maggiore di 50 (per alcune release ho visto fino alla
sub-release r15).
Premetto che non funziona ugualmente per altri movivi (*), ma chi volesse
rilasciare il driver compilato, senza alcuna parte in forma sorgente,
dovrebbe rilasciare 50 versioni del suo driver ... senza considerare il
kernel 2.4
(*) ad ogni modo non funziona ugualmente, perche' lo stesso kernel,
compilato in modi diversi non accetta lo stesso driver. Ovvero, se sullo
stesso kernel attivo la modalita' SMP (o tantissime altre cose) il driver
non funziona. Ergo, ogni fesseria che tolgo o aggiungo, nell'80% dei casi
devo reinstallare il driver nvidia/ati.




Perche' hai appena scoperto che il tuo pc richiede il modulo powrenow_k8,
che non e' attivato nella configurazione di default?
Quindi chi vorrebbe rilasciare driver completamente binari dovrebbe
rilasciarli pensando a tutte le combinazioni per ogni kernel? +smp
+powernow +cpufreq_table -blabla .... sull stesso kernel, per ognuna di
queste opzioni che cambi, devi ricompilare il driver.
Questo e' linux.


 uscito, ma zfs no.
ZFS per Linux già esiste ma gira in userspace con FUSE proprio per i
problemi di licenza. Cerca "ZFS FUSE" con Google. Se Sun non cambia la
licenza non entrerà mai nel kernel (kernelspace, ring 0).

 Potrebbe, non mi stupirei di certo.
Ma almeno lo avete letto?
In un sistema open source si sviluppano driver open source. Lasciamo
perdere i discorsi filosofici di Stallman, ci sono valide ragioni tecniche
a favore e nessuna contro.

 grafica nel kernel)
Linus Torvalds forse, tutti gli altri non credo (basta vedere come
rispose uno dei tizi che lavorano sul kernel a Valentino Volonghi
riguardo Twisted qualche tempo fa')
Enrico



grazie.
trovato qualcosa ... e certo che quanto a caratteristiche non c'e' proprio
di che lamentarsi:  
http://www.wizy.org/wiki/ZFS_on_FUSE
 (pare che hanno
gia' preparato una ebuild per portage, ma nel mio tree non vedo ancora
niente)
resta pero' un fatto: ZFS non e' ancora su Solaris perche' non ha ancora
passato tutti gli "acceptance test". Come fa ad  essere gia' "pronto" su
Linux?
Hanno fatto il porting partendo da qualche tree unstable. Non ho altre
spiegazioni... o magari e' da considerare ancora instabile anche su linux.
E' comunque una buona notizia: mi interessa la caratteristica dello
snapshotting.


 snapshotting.
A me quella dei checksum su dati e metadati.

 tecniche a favore e nessuna contro.
Da quel che vedo provando a utilizzare driver GPL per le schede video, io
direi proprio il contrario.
Lo so che "glxgears" non e' un benchmark in grado di dare risultati validi
in termini assoluti. Se pero' usi glxgear e con la stessa configurazione
hardware e con la stessa risoluzione grafica, ottieni risultati
completamente diversi non mi pare che ci sia molto da ragione sopra.....
fra l'altro, parlando di nvidia, il driver proprietario supporta'
funzionalita' che nel driver GPL non ti immagini nemmeno (dal twinview a
tutte le miriadi di parametri che puo' accettare)
Mi sembra chiaro che provare a immaginare come funziona una cosa -
rispetto a sapere come e' fatta realmente - rende il compito piu'
difficile, il cammino piu' lungo e i risultati incerti.
Il discorso che applico alle chede grafiche vale per qualsiasi altro
hardware e non esistono ragioni tecniche a favore dello sviluppo di
driver, NON TANTO OPEN SOURCE, QUANTO REVERSE-ENGINEERED.


 driver, NON TANTO OPEN SOURCE, QUANTO REVERSE-ENGINEERED.
Beh, quelli di OpenBSD hanno scritto un driver per una wireless
_reverse-engineered_ che è meglio di quello che ha scritto Intel stessa
per Linux (sempre open source).  
http://kerneltrap.org/node/6650
Piuttosto che usare driver binari sono disposti a correre rischi di altro
tipo e devo dire che non li biasimo più di tanto..

 correggerli, non lo fanno.
La mia scheda ATI (driver binario) in gentoo supporta il flag di
compilazione 'acpi'. Pertanto immagino che dovrebbe funzionare.


 In un sistema open source si sviluppano driver open source.
Allora c'e' qualcosa che non va nel sistema
Enrico
P.S. in FreeBSD (negli altri non so, ma penso che sia lo stesso) l'API
e' stabile per tutto il ramo di sviluppo

:

Però il suo fork di Twisted da quel che so sta avendo un successone :D
Uno che introduce la mancanza di unit test in un progetto e lo forka per me è
da rispettare.
  ngw

 tipo e devo dire che non li biasimo piů di tanto..
OpenBSD č un sistema che non pretende di essere full purpose.
A FreeBSD, ad esempio, frega un ceppa di avere i sorgenti di un driver.
Peccato che FreeBSD non ha gli utenti di Linux, quindi siamo da capo.
  ngw

 da rispettare.
Io lo rispetto ignorandolo.
-- 
Valentino Volonghi aka Dialtone
Now Running MacOSX 10.4
Blog: 
http://vvolonghi.blogspot.com
New Pet: 
http://www.stiq.it

 nell'80% dei casi devo reinstallare il driver nvidia/ati.
Questo lo capisco anche se magari dire l'80% dei casi è un tantinello
esagerato. Se faccio modinfo rt2570 | grep vermagic ottengo:
vermagic:       2.6.17.7 mod_unload K7 REGPARM 4KSTACKS gcc-3.4
Quindi in pratica, oltre al numero di versione del kernel, conta il
compilatore (ovviamente), e solo alcune condizioni comprensibilmente
necessarie come le ottimizzazioni per il processore usato e l'opzione di
compilazione -regparm=3, la dimensione degli stack a 4 o 8 kb e
pochissimo altro.
Se togli o aggiungi uno degli infiniti moduli di netfilter, per dire,
non cambia nulla.
-- 
Joe
"Vado a risolvere il teorema del grande Fermat. Mi ci vorranno dagli
8 ai 17 minuti"

 
Perche' il .config "generic purpose", che viene incluso con la tua distro,
potrebbe non includere cio' che serve a te. 


 a favore e nessuna contro.
Rileggi i miei vecchi vecchi post, non parlare con me in merito, sono 
stato tacciato di windowsizzare troppo.


 tipo e devo dire che non li biasimo più di tanto..
OpenBSD e` un discorso a parte, non prenderlo come paragone.


 perché devi ricompilare da zero TUTTO il kernel?
Tutto no. Ma la seccatura rimane ed e` un errore del sistema.
Oppure mettila cosi`, che sei tanto stronzo che vuoi rompere il cazzo 
agli altri perche` non ti danno i driver sotto GPL e nel kernel tree.
A te la scelta.


 diventera' presto ingestibile.
Lo e` gia`. Morton ora e` andato da Google, e tutti gioiscono. Si 
lamentano gli sviluppatori, si lamenta Linus che non gestisce piu` in 
modo umano le patch... vedremo fino a quando uno si puo` dar le 
martellate sui piedi prima di accorgersi che gli fa male.
PS. A me google fa sempre piu` paura.


 Peccato che FreeBSD non ha gli utenti di Linux, quindi siamo da capo.
Peccato che la scusa del numero di utenti non funzioni quando a farla č
un "linuxaro". Gią me le immagino le iene, se solo qualcuno si azzarda a
dire «se Linux avesse gli utenti di Windows...»


 dire «se Linux avesse gli utenti di Windows...»
Che scusa ? Mai sentito qua sopra in tanti anni sentire un linuxaro dire che
il suo sistema ha pochi utenti, anzi, qualsiasi dato si tiri fuori è
sempre l'apoteosi della cazzata per Linux, ma la pura verità per qualunque
altro sistema, a meno che non sia sfavorevole a Linux chiaramente.
  ngw