Newsgroup: it.comp.os.dibattiti
Titolo: Piccola rivoluzione in Linux passata inosservata?

http://liquidat.wordpress.com/2007/07/21/linux-kernel-2623-to-have-stable-userspace-driver-api/
Linux kernel 2.6.23 to have stable userspace driver API
July 21st, 2007 — liquidat
Linus Torvalds included patches into the mainline tree which implement a 
stable userspace driver API into the Linux kernel.
The stable driver API was already announced a year ago by Greg 
Kroah-Hartman. Now the last patches where uploaded and the API was 
included in Linus’ tree. The idea of the API is to make life easier for 
driver developers:
This interface allows the ability to write the majority of a driver in 
userspace with only a very small shell of a driver in the kernel itself. 
It uses a char device and sysfs to interact with a userspace process to 
process interrupts and control memory accesses.
Since future drivers using this API will run mainly in userspace there 
is no need to open up the source code for these parts. Also, drivers can 
be re-used even after kernel changes because the API will remain stable.
The background motivation for the inclusion of such a stable API comes 
form the embedded world: there embedded drivers are often closed source 
and just developed for a single kernel version and are not maintained 
over time. Using the new API these drivers could be used for a longer time.
And in fact such an API has already been developed by people from the 
embedded industry to make their life easier. But it was just developed 
for a single device and not as a generic interface. Such developments 
are now unnecessary.
However, DMA transfer between userspace and kernelspace is not yet 
implemented. This means essentially that drivers which involve high 
traffic are not an option yet. So graphic drivers as well as file system 
drivers and similar cannot use this API at the moment.
Some people might ask now why not simply allow closed source kernel 
drivers directly in the kernel, since they are allowed in userspace now 
anyway. But there is a huge difference between these two types of 
drivers - while userspace drivers can be controlled in a certain way and 
cannot trash the kernel kernelspace drivers could do that. A quite good 
explanation about the topic can be read at LWN.
The other way around one could ask if this will mean the end for Linux 
(for example according to the LWN article). But again, kernelspace and 
userspace is very different - an d with the new API the important part 
(the kernelaspace part) still has to be Open Source! Besides, this API 
does not introduce anything which was not possible before: as already 
mentioned such an API was already developed quite some time ago, and was 
actively used.
But I must also admit that while I see the need for such an API I still 
prefer hardware vendors who simply make the drivers Open Source and 
bring them upstream.
Thanks to German 
heise.de
 for a detailed article about the topic.

 a stable userspace driver API into the Linux kernel. [...]
Non e` passata inosservata ma soltanto inopportuna. Dal mio punto di 
vista non esulto, ma anzi dico 'cazzo vi ci sono voluti 10 anni e 
piu`?', roba da matti. Spero non esultiate per una cosa che se avesse 
fatto la MS tutti starebbero a dire 'eh ma su unix esiste da sempre!'. 
La stessa considerazione va fatta per linux se si e` del tutto onesti.
Dall'altro canto e` una notizia che non piace a RMS & scagnozzi della 
FSF. Chissa` cosa accadra`, soprattutto in previsione della guerra 
GPL3/2. Un fork del kernel per impedire anche questo? Non seguo molto 
queste facezie ideologiche, chi sa di piu` parli.
-- 
Sensei <senseiwa at Apple's mac dot com>
Beware of bugs in the above code; I have only proved it correct, not tried it.
(Donald Knuth)

 fatto la MS tutti starebbero a dire 'eh ma su unix esiste da sempre!'.
A sensei, ma come sei combinato?
Se una cosa non non si fa e' male.
Se una cosa si fa alla fine e' male lo stesso.
Basta cosi', per te il problema e' che si chiama Linux: tutto il resto 
viene dopo.
-- 
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
  printf $i }'; echo

 viene dopo.
Sensei, spiace dar ragione a Max Adamo ma stavolta ha centrato il segno, dal
discorso che hai fatto è comunque merda non importa la sostanza.

 discorso che hai fatto è comunque merda non importa la sostanza.
Io semmai avrei posto un'altra questione:
1) probabilmente tutti quelli che qui facevano notare che una benedetta
API stabile era opportuna non avevano tutti i torti. Non è che per il
fatto che Linux non la avesse fosse giusto così (e ora che ce l'ha
diventa magicamente meglio -- specie tenendo conto dei notevoli limiti,
fino a quando non ho letto quella parte stava cominciando a
materializzarsi nella mia testa la parola nvidia).
2) quando Sensei dice che non c'è da esultare, dice una cosa fastidiosa,
ma vera. Ovvero, bene che adesso ci sono arrivati, ma teniamo conto che
ci sono arrivati in ritardo. È rilevante? Non davvero, basta che ci
siano arrivati.
3) al di la dell'API stabile, trovo *molto* interessante che i driver
siano in user-space. Come dicevo in un altro thread, vedo che sempre più
spesso i kernel monolotici implementano features tipiche di microkernel
e viceversa. IMHO questa è una notizia forse ancora più interessante
(anche se confesso che è un po' che non ho kernel panic su GNU/Linux, i
problemi che riscontro sono molto più mondani).
-- 
blog:  
http://www.akropolix.net/rik0/blogs
 | Uccidete i filosofi,
site:  
http://www.akropolix.net/rik0/
      | tenetevi riso e
forum: 
http://www.akropolix.net/forum/
     | bacchette per voi.



Sensei e' tRendenzioso :)


 drivers and similar cannot use this API at the moment.
ecco... allora a cosa serve? no, dai, sinceramente, cosa dà questo in
più all'accesso a /dev/port? o a delle ioperm usate bene?

 discorso che hai fatto è comunque merda non importa la sostanza.
chiaro, lui è un idiota macaro del cazzo, che t'aspettavi? plonk a vita!

 più all'accesso a /dev/port? o a delle ioperm usate bene?
"is not yet" != "will never be".
vuoi tutto e' subito?


 vuoi tutto e' subito?
no, rimango della mia idea che nonostante l'api stabile chi non si è
sbattuto prima non si sbatterà nemmeno adesso. Perché già prima con le
adeguate syscall che non sono mai cambiate si poteva ottenere un
risultato simile.
Insomma, l'api stabile non serve a nulla se il produttore non ha voglia.

 Insomma, l'api stabile non serve a nulla se il produttore non ha voglia.
Se non cambiera' niente c'e' gia' pronta la doppia scusa: la GPL
trattiene i vendor dallo scrivere driver open; linux non ha una base
d'utenza abbastanza vasta.
--
Joe

 queste facezie ideologiche, chi sa di piu` parli.
le tue critiche avrebbero senso se tutto questo tempo fosse passato 
perchè (come dei cucù) non si erano "accorti" che potevano fare un'API 
stabile.
Invece di sta benedetta API se ne parla da anni e finora non l'avevano 
mai infilata nel kernel per una scelta tecnica ben precisa.
Quindi le tue accuse di essere stati troppo lenti decadono, perché il 
fatto non sussiste.



i server Linux vanno alla grande ... bastano quelli.
E tu sul tuo server, tra un driver pressapochizzato con la tecnica del 
reverse engineering e un driver proprietario fatto da chi il suo hardware 
lo conosce, cosa sceglieresti?


 lo conosce, cosa sceglieresti?
Scelgo il secondo.
Ma preferirei scegliere il terzo: un driver libero e non
reversengineerizzato. :-)
Comunque stavamo ragionando della situazione in cui il vendor "non ha
voglia".
--
Joe

 voglia".
ah be, anche io a volte non ho voglia di lavorare.... solo che poi non 
entrano soldi.
Lo stesso discorso vale per il vendor.


On Sun, 22 Jul 2007 11:49:13 +0200, Vide wrote:
[...]
visto che ogni tanto leggi pollycoke anche tu, mi pare di capire, ti prego
di dare un'occhiata agli straordinari commenti :D
ciao
-- 
NoWhereMan (e.v.)
-- 
http://www.nowhereland.it
-- 
http://www.flatpress.org

 più all'accesso a /dev/port? o a delle ioperm usate bene?
immagino che un crash non tiri più giù tutto. coi driver della scheda
wireless mi succedeva. 


 di dare un'occhiata agli straordinari commenti :D
eheheh :)
Letto, letto :D
-- 
Vide

 bring them upstream.
E io preferirei pane e figa per tutti.
-- 
emboliaschizoide.splinder.com

 wireless mi succedeva. 
con ioperm puoi bombare tutto quello che vuoi, se vuoi :-)
O anche se non vuoi ma non hai tutte le conoscenze. >:-O

 Lo stesso discorso vale per il vendor.
eppure max nel software non sembra essere così. Si può pure
generalizzare oltre i driver linux, purtroppo c'è tanta gente che lavora
di merda...
Sì sì, sarà il caldo a farmi vedere il bicchiedere mezzo vuoto....

 lo conosce, cosa sceglieresti?
Max, se continui su questa strada finisci che ci diventi un winfanboy.
:P


 mai infilata nel kernel per una scelta tecnica ben precisa.
E come mai ne tu ne gli altri del 'linux santo subito' non lo avete
fatto notare?
E soprattutto, non è che 'parlare' da anni di una cosa è come averla
fatta, eh.


 con ioperm puoi bombare tutto quello che vuoi, se vuoi :-)
Beh, se č per quello ce ne sono di modi per bombare un sistema.
C'era per esempio quel famoso esempio che da user-space ti saturava la
CPU senza che questo fosse rilevato dai tool appositi, con il risultato
che ti trovavi una macchina inusabile e senza capire perchč.


 che ti trovavi una macchina inusabile e senza capire perchč.
guarda, io il paper non l'ho letto, ho visto solo il riassunto su
slashdot e da quel poco che ho visto č un caso molto particolare (tra
parentesi, pure obsoleto per linux).
Perň Enrico stai uscendo dal seminato. Ripetendo la solita pappardella
accademica dici che un driver in userspace č piů sicuro, cosa che č vera
in teoria ma nel mondo pratico molto meno. E l'esempio della scheda wifi
era molto infelice.

 era molto infelice.
Scusa, ma il mio esempio va in direzione contraria: ho portato un
esempio (per quanto obsoleto su Linux) di oggetto in user-space che pure
causa danni e fastidi notevoli (tipo un DOS massiccio su un server, per
dire).
Non è che solo perchè ho espresso simpatia (teorica) per un certo design
lo devo difendere a spada tratta. La mia posizione è (come al solito)
molto pragmatica. Sono convinto che i design ibridi siano vantaggiosi. E
Linux è per inciso un design leggermente ibrido. Nulla da dire, eh.
Se devo scegliere fra un sistema non usabile e con un bel design e uno
con un design brutto ma che funziona bene, non ho dubbi.


 :P
no dai ... alcuni esempi ed esperienze con alcuni driver, sono abbastanza 
lampanti.
io credo che nessuno, ma proprio nessuno, usera' mai il driver reverse-
enginnered di nvidia.
Sempre nvidia: la scheda ethernet forcedeth alla fine e' stata sistema da 
alcuni sviluppatori che lavorano in nvidia.
Perche'? Perche' sono piu' intelligenti o perche' partono con qualche 
puntodi vantaggio?


 Linux è per inciso un design leggermente ibrido. Nulla da dire, eh.
a me la tua posizione sembra più idealistica che pragmatica. Nulla da
dire, eh.

 dire, eh.
Più pragmatico del mio? Ovvero provare per simpatia per qualcosa e poi
all'atto pratico scegliere quello che funziona? Non capisco.


 fatta, eh.
Ma infatti non è che sono andati avanti per anni a dire "si farà", anzi, 
sono andati avanti per anni a spiegare a chi insisteva che invece l'API 
non si doveva fare.
Quando poi s'è deciso che era il momento di farla, l'han fatta senza 
tanto chiasso.
Perciò qual'è il problema?

 viene dopo.
Non ho detto che E` MALE, ho detto che la cosa veramente da dire e` 
"porcaputtana e mo ve ne accorgete mortaccivostri? e non fatela passare 
per rivoluzione ma scusatevi con tutti!"
-- 
Sensei <senseiwa at Apple's mac dot com>
Beware of bugs in the above code; I have only proved it correct, not tried it.
(Donald Knuth)



Dimmi, quali scelte 'tecniche'? L'aumento di entropia del pianeta per 
la fatica ulteriore nello stabilire & mantenere delle specifiche?
Suvvia, non sono MAI esistite in realta` scelte tecniche serie, anche 
perche` loro non ne hanno cacata fuori UNA in piu` di un decennio.


 Sensei e' tRendenzioso :)
Certo! ;)
Faccio solo notare come sul serio tutti esultino per l'api stabile. Se 
la cosa fosse avvenuta al contrario, ovvero Windows diventasse con API 
stabile allora tutti a dire "eh mo esultate ma linux l'aveva dal 1903!".
E sai perche` lo dico? Perche` e` successo con gli user privileges in 
Vista "proprio come il unix dal medioevo, e vogliono farla passare per 
rivoluzione".


 July 21st, 2007 — liquidat
Una ulteriore notizia sul Kernel:
http://apcmag.com/6735/interview_con_kolivas


 
http://apcmag.com/6735/interview_con_kolivas
Stavo per postarla, dato che penso meriti un thread a parte... intervista
diciamo... scoppiettante, in cui Kon fa vedere cmq di essere una
personalità forte ed egocentrica (come altri sviluppatori del kernel), per
cui è facile capire perchè proprio uno come lui abbia lasciato. È normale
che questi tipi di personalità (di cui fa parte anche Linus, per esempio)
arrivino ad avere scontri ed attriti prima o poi. Succede da sempre,
succede anche nelle imprese tradizionali. Non ci vedo nulla di così strano
per cui che succeda anche nel mondo opensource e in quello Linux in
particolare. Anzi, aggiungo che quelli che ci trovano qualcosa di strano,
puntando il dito contro Linux, sono semplicemente in mala fede.
-- 
Vide

 quello che tu pensi che io abbia detto.
ok, non ci siamo capiti. il problema non era lo userspace, ma l'idea di
una stabilità maggiore.



No, allora non hai capito:P Con Kolivas ha lasciato perche' Linux e' una 
merda e perche' BSD, Windows a MacOSX sono eccezionali veramente.
Questo era il messaggio subliminale del post di Sensei.
Si chiama Linux? Allora e' una merda.
Funziona tutto alla perfezione, ha pure un API stabile, ma si chiama 
Linux? Niente da fare. E' una merda.
Va cosi' cosi', ogni tanti si inchioda, e' lentuccio, prende i virus e 
gli spy, costa costa uno sproposito? Si chiama Linux? No, non si chiama 
Linux. Quindi e' eccezionale.
bene o male funzionicchia, ha una cagatina che si chiama expose e nessuno 
se lo caga nemmeno di striscio. Si chiama Linux? No. Quindi e' anche 
questo eccezionale.


 Si chiama Linux? Allora e' una merda.
Hai riassunto benissimo la questione.
E ovviamente nessuno gli va a dire niente, e' normale; chissa', forse e' 
per via dello UserAgent magico che protegge dagli insulti...
Se invece qualcuno dice minimamente qualcosa di positivo su Linux, 
allora e' un fottuto fanBoy, o comunista, o illuso, o malato, etc etc  o 
anche qualcosa di peggio se si azzarda a criticare anche di striscio il 
magico e infallibile mondo della mela.
Ah, la coerenza.
-- 
BArrYZ

 puntando il dito contro Linux, sono semplicemente in mala fede.
Clap clap clap.
-- 
BArrYZ

 perche` loro non ne hanno cacata fuori UNA in piu` di un decennio.
W O W!
Ma questa e' da sign!
"perche` loro non ne hanno cacata fuori UNA in piu` di un decennio"
Sensei, sei formidabile.
-- 
BArrYZ

 magico e infallibile mondo della mela.
stai piangendo? hai 6 anni?



insomma, diciamo che non si viene fuori con post di questo genere, per 
dire agli altri: "hai 6 anni".
L'accusa rischia di ritorcersi pericolosamente su di te.




Vuoi seriamente smerdarmi? E dinne una, pendo dalle tue labbra! Manco 
linus ne ha detta una, vediamo il BarryZ cosa ci dice.


 Si chiama Linux? Allora e' una merda. [...]
No, mo dimmi **SERIAMENTE**.
Se fosse avvenuto AL CONTRARIO (windows conquista API stabili dopo 15 
anni), la comunita`, e tutti qui dentro, non avremmo detto "aho merde 
guarda che linux le ha da 15 anni"? Come e` avvenuto per la 
"rivoluzione" che gli utenti in vista hanno privilegi inferiori tra 
l'altro.
Cazzodibbudda e` stato detto per Space di Apple! E giustamente, perche` 
i desktop sono vecchi di concezione, e` solo l'implementazione piu` 
coatta.
Cosi` c'e` la *mala fede*.
Riconoscere una cosa dovuta come rivoluzione? Mai! Apple con spaces non 
ha fatto alcun cazzo di nuovo, l'ha solo reso coatto. Linux? Stessa 
cosa!
-- 
Sensei <senseiwa at Apple's mac dot com>
Beware of bugs in the above code; I have only proved it correct, not tried it.
(Donald Knuth)



Certo che vanno a scontrarsi, ma e` un male che non riescano a 
collaborare. Il lato desktop e` importante, spero vivamente che non si 
buttino a far cazzate inutili lato enterprise, o riscrivere un ennesimo 
stack USB.
Piu` gente se ne va, piu` rimangono i piu` oltranzisti, ed e` male. 
Male per me che poi magari mi ritrovo con qualcosa che non va piu` 
nella debian per qualche cazzo di motivo ideologico e devo migrar tutto 
ad un altra distribuzione (o ad un altro OS tipo solaris).
-- 
Sensei <senseiwa at Apple's mac dot com>
Beware of bugs in the above code; I have only proved it correct, not tried it.
(Donald Knuth)

 L'accusa rischia di ritorcersi pericolosamente su di te.
Non sai quanto me ne possa fregare Adamo

 vizio di icod è di partire per la tangente... :-)
Ed e` anche uno dei motivi per cui seguo questo ng, non sono poche le
volte che da un discorso interessante si e` finiti ad un altro discorso,
interessante come il primo
Enrico


chi ci sta a cambiare il nome in it.bar.os.dibattiti? :-D
PS: anche per me è un motivo di interesse e svago

 stack USB.
Dai, fondamentalmente se ne è andato perchè prima gli han detto no a una sua
idea e poi dopo l'hanno implementata un po' differentemente. È quello che
fanno i capi in tutte le imprese del mondo :D
Per le funzionalità desktop è almeno un anno (o forse più) che Linus dice
che ora vogliono concentrarsi su quelle, e IMO i frutti nell'ultimo periodo
si son visti (ad esempio il nuovo stack wifi unificato).
-- 
Vide

 cosa!
Vero, però almeno ora non si potranno più fracassare le balle su sta cosa :P
-- 
Vide

 si son visti (ad esempio il nuovo stack wifi unificato).
Non mi piace il modello di sviluppo che te devo di`? E` non concepibile 
per me che non sia stato pianificato tempo fa.
A proposito poi s'e` saputo piu` nulla delle sfuriate GPL?
-- 
Sensei <senseiwa at Apple's mac dot com>
Beware of bugs in the above code; I have only proved it correct, not tried it.
(Donald Knuth)



Speriamo che mo non saltino gli esaltati (di qualunque fazione) a 
proclamare rivoluzioni/anno_di.
Tranne me.
Questo e` l'anno di MS-DOS 6.22! :D
-- 
Sensei <senseiwa at Apple's mac dot com>
Beware of bugs in the above code; I have only proved it correct, not tried it.
(Donald Knuth)

 per me che non sia stato pianificato tempo fa.
Converrari con me che, per differenze basilari, la compatibilità binaria in
un ambiente opensource non ha lo stesso esatto peso che in un ambiente a
codice chiuso.
È sempre molto importante, non dico di no, ma in ogni caso tu (come
distributore, non tu come utente finale) hai il codice e puoi ricompilare.
-- 
Vide

 Perciò qual'è il problema?
Appunto: Linux Santo Subito. Finchè non l'hanno fatta non si doveva fare, 
appena la hanno fatta hanno fatto bene. Santi subito.
Penso che *o* non è necessaria (e non lo era allora come non lo è oggi) 
oppure lo è, per cui sarebbe stato opportuno averla.
Se però non è necessaria, è una notizia senza peso. Hanno creato una cosa 
inutile, cosa c'è da commentare?
-- 
-rik0

 inutile, cosa c'è da commentare?
Ah non so, domandalo a chi ha iniziato la polemica. Ciao.

 Ah non so, domandalo a chi ha iniziato la polemica. Ciao.
Domandalo a chi fa andare avanti una 'rivoluzione' come quella di 
Spaces... e tutti ad esultare.
-- 
Sensei <senseiwa at Apple's mac dot com>
Beware of bugs in the above code; I have only proved it correct, not tried it.
(Donald Knuth)

 distributore, non tu come utente finale) hai il codice e puoi ricompilare.
Beh il problema e` proprio l'utente finale infatti. Beh vedremo nel 
futuro come andra` a finire.
-- 
Sensei <senseiwa at Apple's mac dot com>
Beware of bugs in the above code; I have only proved it correct, not tried it.
(Donald Knuth)

 futuro come andra` a finire.
Io sinceramente sono anni che non compilo niente per il kernel, a livello di
necessità casalinghe.
-- 
Vide

 perché una cosa che prima non era necessaria non può diventarlo adesso?
Spiegami *perchè* secondo te è diventata necessaria adesso e non prima.
E da *quando* è diventata necessaria.
-- 
blog:  
http://www.akropolix.net/rik0/blogs
 | Uccidete i filosofi,
site:  
http://www.akropolix.net/rik0/
      | tenetevi riso e
forum: 
http://www.akropolix.net/forum/
     | bacchette per voi.



Finche` sul desktop avevo linux serviva ogni volta ricompilare per i 
driver nvidia. Lato server openafs e` alcune volte non funzionante con 
aggiornamenti del kernel ed e` una buona norma ricompilare sui server 
in produzione.
Se lato client non usassi nvidia ma nv allora non ci sarebbe problema 
(e se i client non fossero client afs).
-- 
Sensei <senseiwa at Apple's mac dot com>
Beware of bugs in the above code; I have only proved it correct, not tried it.
(Donald Knuth)

 CUT
Ottimo !
Quindi serviva o no ?
Ora che c'e' immagino di si, vero ?
  ngw
-- 
"ma gavte la nata." -- Jacopo Belbo
http://www.tochunky.org

 GPL3/2. Un fork del kernel per impedire anche questo? 
Mah... spero di no. 
-- 
Ciao.
Blue

 E da *quando* è diventata necessaria.
no no, sei tu che stai polemizzando su 'sto fatto, quindi sei tu che 
invece devi iniziare a spiegare *perché* secondo te non è necessaria 
nemmeno ora oppure *perché* era necessaria anche prima.

 Spaces... e tutti ad esultare.
Ancora: tutto questo clamore non lo vedo per nulla.

 nemmeno ora oppure *perché* era necessaria anche prima.
ROTFL, dai non fare il clown. Io il perchè fosse IMHO opportuno avere
un'interfaccia stabile lo ho scritto svariate volte negli archivi.
D'altra parte non ci vuole un genio a capirlo: in tutti gli ambiti di
sviluppo gli sviluppatori gradiscono avere API stabili, non vedo perchè
per il kernel dovrebbe essere diverso.
Devo spiegarti perchè noi sviluppatori amiamo le API stabili? :P


 questo cambiamento sia stato una buona o una cattiva scelta.
Il progetto non era cosi` complesso 15 anni fa, e fino a pochissimo 
tempo fa l'API stabile era un taboo, quindi... cosa e` cambiato secondo 
te? Perche` hanno cambiato idea?


 Mah... spero di no.
Vedremo! Intanto iceweasel c'e`...
-- 
Sensei <senseiwa at Apple's mac dot com>
Beware of bugs in the above code; I have only proved it correct, not tried it.
(Donald Knuth)

 te? Perche` hanno cambiato idea?
Eh questo bisognerebbe cheiederlo a loro, finché non lo dicono possiamo 
solo fare delle suppposizioni...
Tipo: se tutti i driver stanno in userspace il kernel può andare sotto 
GPLv3 senza tante complicazioni?
Oppure: hanno fatto delle valutazioni e deciso che i tempi sono maturi 
per questo passo? Chissà...
Solo che fare una polemica vuota perché "ci hanno messo troppo" mi 
sembra ridicolo...

 Devo spiegarti perchè noi sviluppatori amiamo le API stabili? :P
No devi spiegarmi perché cerchi sempre di saltare di palo in frasca.

 Ora che c'e' immagino di si, vero ?
Avere più scelta è sempre una cosa positiva, no?

 Ora che c'e' immagino di si, vero ?
Tu cosa ne dici?
Il tuo intervento è trolleggio bello e buono...

 facevano in kernelspace, quindi che c'entra?
Primo, anche ora si fanno in kernel space. Alcune cose si potranno fare
pure in user-space.


):

Ma non diciamo cazzate ! Il kernel Linux e' *evolutivo*, non si possono 
tarpare le ali degli sviluppatori con delle API stabili.


 driver nvidia.
Boh, io sul mio desktop ho sempre installato i driver pacchettizzati 
dalla distribuzione, che motivo c'č di ricompilare?
-- 
|- Massimo ;-) ---> 
http://maq.altervista.org
 <-----|(o-  POWERED |
|- BABYLON 5 -----> 
http://babylon5.altervista.org
 <|(/)_ BY LINUX|
|- STARGATE ------> 
http://sg1screw.altervista.org
 <|And the sky  |
|WHAT DO YOU WANT?> 
http://morden.deviantart.com
 <--|full of stars|

 Vedremo! Intanto iceweasel c'e`...
A dir la verità c'è sempre stato. :)


 pure in user-space.
infatti la base della discussione era che per ora non sarà granché utile 
perché manca il supporto al DMA. Diamo tempo al tempo.
E cmq anche qui sei saltato di palo in frasca.

 tarpare le ali degli sviluppatori con delle API stabili.
sempre trolleggio, al solito...

 sembra ridicolo...
Bene, quindi non hai una risposta al perche` tipo 12 mesi fa l'API 
stabile era satana ed ora invece e` una cosa buona e giusta.


 A dir la verità c'è sempre stato. :)
<FSF> Iceweasel e` FREE, l'innominabile prodotto commerciale ma 
aggratis NON e` free as in free speech quindi da cambiare per il bene 
del pianeta intero. Sono cose diverse devi comprenderlo! </FSF>


 dalla distribuzione, che motivo c'è di ricompilare?
Che non c'erano i pacchetti aggiornati tanto per far un esempio?




Che almeno ci si renda conto che e` una posizione ridicola questa. 
Prima c'era il documento 'api stabili satana' ed ora invece no, senza 
spiegazioni alcune. Era necessario 15 anni fa, la gente gli ha 
bestemmiato addosso per 15 anni ed ora fanno la grazia.


 bestemmiato addosso per 15 anni ed ora fanno la grazia.
Tanto hanno quelli che li difendono 'di default'.
Fondamentalmente qualunque cosa facciano, va bene perchè l'hanno fatta.
Mi chiedo se sia una qualche clausola nascosta della GPL. <g>
-- 
-rik0

 dalla distribuzione, che motivo c'è di ricompilare?
Dipendeva dalla distribuzione. Prima avevo slack. E nisba.
Poi deb. E anche li pare di ricordare che per un bel po' non li hanno 
fatti (o forse li facevano per il ramo 'sbagliato').
Piccoli vantaggi di usare distro mainstream. Sigh.
-- 
-rik0

 sei saltato di palo in frasca.
Rispondere a quello che scrivi ora si chiama 'saltare di palo in frasca'?
-- 
-rik0

del pianeta intero. Sono cose diverse devi comprenderlo! </FSF>
LOL! Ma non devo comprenderlo io. :)
Cmq, ripeto, Iceweasel c'è sempre stato, anche se aveva un altro nome.


 Che non c'erano i pacchetti aggiornati tanto per far un esempio?
Ah ok, mai avuto questo problema.


 intero. Sono cose diverse devi comprenderlo! </FSF>
Dipende di quale dei due iceweasel parli. Ce ne è uno fatto da gnuzilla e 
uno fatto da Debian.
Parlando di quello di debian:
In particolare sulla questione hanno ragione, IMHO, quelli di Debian.
E hanno ragione per ragioni *tecniche*. Quelli di Mozilla foundation (da 
quanto ho capito) vogliono che il loro nome e la loro icona possa essere 
usato solo per i pacchetti compilati da loro o altre faccende non 
compatibili con le linee guida di Debian.
Per cui Debian non poteva fare altrimenti, posto che Moz non aveva 
intenzione di recedere. 
Riguardo agli altri... vabbè, non ne parlo. Non vale la pena: di 
estremisti ce ne sono sempre.
-- 
-rik0

 bestemmiato addosso per 15 anni ed ora fanno la grazia.
*Dentro* il kernel la situazione è comunque esattamente la stessa, eh?
Aggiunta != cambio
-- 
Vide



'Cambio' di mentalita`.
-- 
Sensei <senseiwa at Apple's mac dot com>
Beware of bugs in the above code; I have only proved it correct, not tried it.
(Donald Knuth)

 ...'saltare di palo in frasca'?
tanto per...
OT: il tuo Pan fiorda...
-- 
Sans

 stabile era satana ed ora invece e` una cosa buona e giusta.
Non devo avere io questa risposta, sei tu che devi argomentare se vuoi 
criticare questa scelta.

 Rispondere a quello che scrivi ora si chiama 'saltare di palo in frasca'?
se cambi discorso, sì.

 bestemmiato addosso per 15 anni ed ora fanno la grazia.
che barbaaaaaa...
Sembra un discorso da pischello di terza media...
Tu invece senza argomentazione alcuna fai un processo alle intenzioni 
degli sviluppatori del kernel.
Cosa vuoi che ti dica? Vuoi un ghiacciolo come premio?
O preferisci un calippo?

 criticare questa scelta.
Manco un commento o opinione? Vabbe` scivola via.


 O preferisci un calippo?
Quello frizz, grazie.
Comunque quando si va al dunque, non dai alcun argomento.


 Manco un commento o opinione? Vabbe` scivola via.
Ma ddeché?
Ma rimbarzi.

 Comunque quando si va al dunque, non dai alcun argomento.
eh certo, secondo te il dunque è che sai leggere nel pensiero degli 
sviluppatori del kernel.
Non bere la coca cola con l'aspirina... fa male...