Stiamo esagerando? [Archivio] - Hardware Upgrade Forum

Morpheus_/_Neo

27-07-2006, 10:33

Non è violando la gpl che si può ottenere la "convivenza". Come i produttori di sw proprietario sono ben attenti acché le _loro_ licenze siano rispettate, devono essere anche ligi nel rispettare quelle degli _altri_. Anche se non piacciono.

Sapete come funzionano i driver proprietari per alcuni winmodem Intel e VIA? Ve lo dico io.
Visto che i winmodem sono delle rozze schede audio, hanno realizzato dei driver liberi, gpl, integrati perfettamente con il layer ALSA, per poter gestire i loro modem come schede audio. I driver sono stati accettati nel kernel ufficiale.

I driver proprietari che fanno sì che le schede si comportino come "modem", non sono altro che dei banali demoni userspace (dei tranquillissimi programmi, insomma), che utilizzano il device alsa relativo ai loro modem per dialogare con l'hw, e creano degli pseudoterminal per emulare la presenza fisica di un modem. A questo pseudoterminal pppd può benissimo attaccarsi, come con qualsiasi altro modem.
I demoni sono closed source, e possono benissimo esserlo.

Risultato: kernel "pulito", GPL rispettata, utenti contenti (possono cambiare kernel a loro piacimento, senza il patema "oddio questo $RANDOMCLOSEDSOURCEDRIVER chissà se continuerà a funzionare), e i venditori hanno risparmiato un mucchio di $$$ per seguire l'evoluzione del kernel.

E' _così_ che si fa, se proprio non si può fare a meno di trapiantare del codice closed source.

scusa ilsensine, vorrei chiederti una cosa... quando affermi che un demone closedsource usa, per dialogare con l'hw, un device alsa relativo al modem in questione, non mi e' ben chiaro il funzionamento della cosa... cioe', se stiamo parlando di driver, se il device alsa riesce a dialogare col modem, a cosa serve allora il driver proprietario? scusa, mi spiegheresti meglio come funziona la cosa? mi disp, sono abbastanza ignorante in materia, spero non sia un disturbo...

M_/_N

javaboy

27-07-2006, 10:35

In tutta sincerità, (la tua è una posizione rispettabile), non credo allora che linux sia il s/o più adatto a te.
Forse ti troveresti meglio con i sistemi *BSD, che hanno licenze meno restrittive.

Le licenze BSD come ben sai si prestano a ben altre maialate vedi Cedega.
Quale sarebbe la soluzione? Utilizzare dei driver video fatti in casa con prestazioni ridicole? Rimanere senza accelerazione 3d?Costringere la ATI a realizzare dei driver open source?

ilsensine

27-07-2006, 10:37

scusa ilsensine, vorrei chiederti una cosa... quando affermi che un demone closedsource usa, per dialogare con l'hw, un device alsa relativo al modem in questione, non mi e' ben chiaro il funzionamento della cosa... cioe', se stiamo parlando di driver, se il device alsa riesce a dialogare col modem, a cosa serve allora il driver proprietario? scusa, mi spiegheresti meglio come funziona la cosa? mi disp, sono abbastanza ignorante in materia, spero non sia un disturbo...

Come detti, i winmodem sono solo delle schede audio. Tutta la modulazione del segnale viene fatta in software.

Morpheus_/_Neo

27-07-2006, 10:38

ilsensine

27-07-2006, 10:39

Quale sarebbe la soluzione? Utilizzare dei driver video fatti in casa con prestazioni ridicole? Rimanere senza accelerazione 3d?Costringere la ATI a realizzare dei driver open source?
No; Costringere ATI a rilasciare le specifiche, oppure a fare le cose "come si deve": piccolo driver libero che dialoga con l'hw in maniera minimale (DMA, gestione IRQ, destione della condivisione del device tra più client ecc) e spostare tutta la loro preziosissima blobbagine in userspace.

Morpheus_/_Neo

27-07-2006, 10:40

Come detti, i winmodem sono solo delle schede audio. Tutta la modulazione del segnale viene fatta in software.

cioe' (scusa, ma come ho detto sono molto ignorante in materia) io uso i driver alsa per interfacciarmi al modem come fosse una scheda audio (visto che di fatto e' semplicemente una scheda audio) e poi il driver/demone proprietario si appoggia ad alsa per fare il suo lavoro... ho capito bene?

grazie della pazienza

M_/_N

ilsensine

27-07-2006, 10:40

per quanto riguarda la questione sollevata dal topic, sono d'accordo che la cosa possa sembrare rigida, ma do ragione a ilsensine per quanto riguarda il rispetto delle licenze. Inoltre, correggetemi se sbaglio, ma un driver e' preposto alla comunicazione diretta con l'hw e quindi svolge un ruolo importantissimo per quel che riguarda la stabilita' e la sicurezza del s.o. Detto questo, avere driver a sorgenti aperti diventa quasi un must... o mi sbaglio? vorrei il tuo parere ilsensine :-)

La sicurezza e stabilità è solo una delle motivazioni, ma ce ne sono anche altre. Vedi quanto dice Greg KH nel mio primo link.

Il concetto del "basta che funziona" non si applica a linux. Se "basta che funziona", passiamo tutti a Windows e buonanotte :)

Morpheus_/_Neo

27-07-2006, 10:42

No; Costringere ATI a rilasciare le specifiche, oppure a fare le cose "come si deve": piccolo driver libero che dialoga con l'hw in maniera minimale (DMA, gestione IRQ, destione della condivisione del device tra più client ecc) e spostare tutta la loro preziosissima blobbagine in userspace.

perfettamente d'accordo! semplice, pulito e fa contente entrambe le parti

M_/_N

ilsensine

27-07-2006, 10:43

cioe' (scusa, ma come ho detto sono molto ignorante in materia) io uso i driver alsa per interfacciarmi al modem come fosse una scheda audio (visto che di fatto e' semplicemente una scheda audio) e poi il driver/demone proprietario si appoggia ad alsa per fare il suo lavoro... ho capito bene?

Esattamente.

Il driver deve fare il minimo indispensabile (nel caso dei winmodem, si ha la fortuna di poter contare sul layer ALSA che gratuitamente fa anche cose aggiuntive oltre il "minimo"). Il resto si può fare in userspace.

Non è una soluzione che _a me_ personalmente piace; ma almeno non viola nessuna licenza. E' un compromesso, dove il produttore dell'hw riconosce il diritto dei kernel developer ad imporre la loro licenza, e i kernel developer riconoscono al produttore hw il diritto a non divulgare certo codice se non vuole (o, più spesso, se non può).

Morpheus_/_Neo

27-07-2006, 10:45

La sicurezza e stabilità è solo una delle motivazioni, ma ce ne sono anche altre. Vedi quanto dice Greg KH nel mio primo link.

Il concetto del "basta che funziona" non si applica a linux. Se "basta che funziona", passiamo tutti a Windows e buonanotte :)

no no, mi tengo bene alla larga dal "basta che funzioni"! se scelgo linux, oltre alle altre motivazioni, e' anche perche' volgio un sistema che funzioni bene e che sia sempre sotto controllo. Cmq personalmente ritengo che anche sotto win i driver dovrebbero essere open... ma questa e' fantascenza quindi lasciamo perdere

ilsensine

27-07-2006, 10:46

Le licenze BSD come ben sai si prestano a ben altre maialate vedi Cedega.
Vogliamo parlare del kernel di OSX?

Un pò mi confondi. La GPL ti va bene se impedisce queste orrificienze, ma non ti va più bene se, attraverso gli stessi strumenti garantisce i diritti di chi non vuole che il proprio codice faccia la fine del kernel di OSX.

Morpheus_/_Neo

27-07-2006, 10:48

Esattamente.

Il driver deve fare il minimo indispensabile (nel caso dei winmodem, si ha la fortuna di poter contare sul layer ALSA che gratuitamente fa anche cose aggiuntive oltre il "minimo"). Il resto si può fare in userspace.

Non è una soluzione che _a me_ personalmente piace; ma almeno non viola nessuna licenza. E' un compromesso, dove il produttore dell'hw riconosce il diritto dei kernel developer ad imporre la loro licenza, e i kernel developer riconoscono al produttore hw il diritto a non divulgare certo codice se non vuole (o, più spesso, se non può).

grazie mille per la pazienza :-)

ilsensine

27-07-2006, 10:48

no no, mi tengo bene alla larga dal "basta che funzioni"! se scelgo linux, oltre alle altre motivazioni, e' anche perche' volgio un sistema che funzioni bene e che sia sempre sotto controllo. Cmq personalmente ritengo che anche sotto win i driver dovrebbero essere open... ma questa e' fantascenza quindi lasciamo perdere
Questa tua osservazione mi consente di tirare una freccia importantissima in favore dei driver liberi.

Q: Come fanno le schede 3dfx a funzionare ancora sotto XP, se la 3dfx è fallita?
A: Perché i driver erano open source. Qualcuno in giro nel mondo si è preso l'onere di aggiornarli per XP.

Morpheus_/_Neo

27-07-2006, 10:50

ilsensine

27-07-2006, 10:54

ok... chi ha la pazienza di spiegare che fine ha fatto il kernel osx?
Era stato "aperto" da Apple, con licenza BSD.

Ora che Apple è passata a x86, e non vuole che l'utente utilizzi il "loro" s/o per girare su hw qualsiasi che non sia quello fornito da loro, esiste una sola soluzione: togliere all'utente i diritti garantiti da un software libero. Niente più sorgenti. Kernel closed source.
E chi fino a ieri ha contribuito con proprio codice al kernel libero di OSX? Si attacca.
BSD license, berk.

Altro esempio (di portata minore) che può essere portato, è XFree86.

Morpheus_/_Neo

27-07-2006, 10:58

grazie mille... non so a cosa ti riferisci parlando di xfree, devo studare ancora molto, ma tranquillo, non ti chiedero' di spiegarmelo, altrimenti passiamo la giornata a fare lezione di storia... quello che vorrei chiederti e', essendo stato il kernel osx open quando usavano ppc, cosa impediva un porting per architettura x86?

ilsensine

27-07-2006, 11:04

quello che vorrei chiederti e', essendo stato il kernel osx open quando usavano ppc, cosa impediva un porting per architettura x86?
Bella domanda. Non saprei esattamente. Ipotizzo:
- il kernel non era tutto open source
- le applicazioni erano tutte per PPC; portare il kernel per x86, senza il "resto" del s/o (che non è composto solo da un kernel), e senza applicazioni, non aveva senso.

Morpheus_/_Neo

27-07-2006, 11:07

capito.

ti ringrazio molto per la disponibilita'

M_/_N

javaboy

27-07-2006, 11:12

Vogliamo parlare del kernel di OSX?

Un pò mi confondi. La GPL ti va bene se impedisce queste orrificienze, ma non ti va più bene se, attraverso gli stessi strumenti garantisce i diritti di chi non vuole che il proprio codice faccia la fine del kernel di OSX.

Penso che i produttori di hardware che hanno investito fior di miliardi in sviluppo abbiano tutto il diritto a non rilasciare alcuna specifica.
Inserire un modulo binario nel kernel non nuoce a nessuno.
Penso che le ragioni di questo impedimento siano di carattere filosofico /giuridico più che tecnico.

Rischio di andare off topic, ho iniziato questa discussione non perchè sia interessato al problema dei driver ati in particolare ma perchè sempre di più mi sta dando fastidio l'integralismo della free software foundation.

ilsensine

27-07-2006, 11:15

Penso che i produttori di hardware che hanno investito fior di miliardi in sviluppo abbiano tutto il diritto a non rilasciare alcuna specifica.
A quanto pare non sai la storia del driver R200, o dei driver per i chipset wireless Broadcomm e Texas Instrumens.

Inserire un modulo binario nel kernel non nuoce a nessuno.
Sì, noce. Da un punto di vista legale, da un punto di vista tecnico, e - consentimi - anche da un punto di vista etico.

Mighty83

27-07-2006, 11:31

A quanto pare non sai la storia del driver R200, o dei driver per i chipset wireless Broadcomm e Texas Instrumens.

Infatti sarei curioso di sapere la storia... Se hai voglia ti ascolto più che volentieri :stordita:

Ilbaama

27-07-2006, 11:35

O magari qualche link :sbav:

ilsensine

27-07-2006, 11:49

Infatti sarei curioso di sapere la storia... Se hai voglia ti ascolto più che volentieri :stordita:
- R200
Fino all'R128, la ATI si era dimostrata sempre "linux friendly". Poi le cose sono cambiate. Non è stato mai chiaro il motivo del cambiamento; personalmente ritengo che il fallimento della 3dfx potesse entrarci qualcosa (prima del fallimento, la 3dfx aveva in corso con nvidia alcuni strani contenziosi legali, legati - guarda un pò - al solito problema dei brevetti).
Quindi ATI aveva deciso: no specs, no free drivers.
Poi arrivò qualcosa che ATI non aveva previsto.
Una grossa azienda, che nulla ha a che fare con l'informatica, contattò la Tungsten Graphics (la ditta che produce driver DRI liveri; tra i suoi clienti annovera anche Intel) chiedendo la realizzazione di driver liberi per l'R200. Non è mai stato divilgato il motivo; questa azienda non pubblicizzò la cosa, semplicemente voleva un driver libero, il frglx non andava bene. I motivi erano affari loro.
Fatto sta che, ora che una grossa azienda stava spargendo l'odore dei soldi, "miracolosamente" quelle specifiche che fino a un giorno prima non potevano essere divulgate, pena la nuclearizzazione di ATI (da parte di chi? Dei concorrenti? :rolleyes: ), arrivarono alla Tungsten Graphics.
In pochi mesi il driver fu pronto, e supportava bene quelle schede.
Tracce di violazione della IP di ATI non se ne sono viste.

- Driver wireless
I driver Broadcomm e TI sono frutto di reverse engeenering. Ora abbiamo dei driver perfettamente funzionanti, sappiamo tutto su come si usano queste schede, e non sembra che nessun competitor abbia tratto vantaggio da questa cosa o che siano saltate fuori novità tecniche sconvolgenti.

Quindi, per rispondere a Javaboy: la IP da proteggere non sta in come un hardware si usa, ma in come è fatto.

Per ultimo, quoto Jeff Jarzik (una mia vecchia signature):
When I am forced to sign NDAs to get hardware specs, the hardware IP "revealed" is inevitably something that some other company has done before, and done better. NDAs and closed specs are IMO only used by vendors to save face, when their hardware design is stupid, and their errata innumerable.

eclissi83

27-07-2006, 12:23

avere moduli closed nel kernel e' il Male(TM).
Ogni volta che cambi qualcosa nel kernel, devi ricompilare il driver. E' tecnicamente assurdo! inoltre io sono d'accordo sul fatto che i produttori abbiano dei vincoli, ma spostare tante cose da kernel space a user space sarebbe mooooooooooooooolto meglio. pure se fossero closed (cosa che cmq non accetterei ben volentieri).
io sviluppo una distro per PowerPC: i driver open ati (fino al chip r300) funzionano cosi' cosi' ma almeno ci sono; i driver closed ati e nvidia _non_ esistono per gnu/linux ppc. questo e' il risultato del software closed. che bello, eh? se invece facessero dei driver come quelli del alcatel manta usb, ovvero supporto kernel space e loader del firmware (closed) in user space, _tutti_ potrebbero usare il loro hardware, e potrebbero farlo meglio. Infatti, se crasha il loader del firmware per qualche motivo non si rischia il panico della macchina, cosa che invece puo' accadere con i moduli che si interfacciano al kernel.

fatti i tuoi conti.

Mighty83

27-07-2006, 13:05

- R200
Fino all'R128, la ATI si era dimostrata sempre "linux friendly". Poi le cose sono cambiate. Non è stato mai chiaro il motivo del cambiamento; personalmente ritengo che il fallimento della 3dfx potesse entrarci qualcosa (prima del fallimento, la 3dfx aveva in corso con nvidia alcuni strani contenziosi legali, legati - guarda un pò - al solito problema dei brevetti).
Quindi ATI aveva deciso: no specs, no free drivers.
Poi arrivò qualcosa che ATI non aveva previsto.
Una grossa azienda, che nulla ha a che fare con l'informatica, contattò la Tungsten Graphics (la ditta che produce driver DRI liveri; tra i suoi clienti annovera anche Intel) chiedendo la realizzazione di driver liberi per l'R200. Non è mai stato divilgato il motivo; questa azienda non pubblicizzò la cosa, semplicemente voleva un driver libero, il frglx non andava bene. I motivi erano affari loro.
Fatto sta che, ora che una grossa azienda stava spargendo l'odore dei soldi, "miracolosamente" quelle specifiche che fino a un giorno prima non potevano essere divulgate, pena la nuclearizzazione di ATI (da parte di chi? Dei concorrenti? :rolleyes: ), arrivarono alla Tungsten Graphics.
In pochi mesi il driver fu pronto, e supportava bene quelle schede.
Tracce di violazione della IP di ATI non se ne sono viste.

- Driver wireless
I driver Broadcomm e TI sono frutto di reverse engeenering. Ora abbiamo dei driver perfettamente funzionanti, sappiamo tutto su come si usano queste schede, e non sembra che nessun competitor abbia tratto vantaggio da questa cosa o che siano saltate fuori novità tecniche sconvolgenti.

Quindi, per rispondere a Javaboy: la IP da proteggere non sta in come un hardware si usa, ma in come è fatto.

Per ultimo, quoto Jeff Jarzik (una mia vecchia signature):

Grazie mille! Puntuale e preciso come al solito! ;)

Ma ti volevo chiedere ancora... Nvidia com'è messa in questo campo? Cioè fornisce specifiche e quindi driver open? Dato che continuo a leggere che le sue schede son quelle maggiormente supportate da linux...

javaboy

27-07-2006, 13:14

dobro

27-07-2006, 13:26

Non ci sono ragioni tecniche, c'è solo fanatismo.

Decisioni come queste derivano dal fatto che Stallman considera il software proprietario un male da estirpare a ogni costo.

:rolleyes:

Fil9998

27-07-2006, 13:44

ma pare brutto includere i driver propietari nelle varie distro e lasciare l'opzione all'utente (ovviamente con relativi avvisi) se installarli/attivarli o meno ???

eclissi83

27-07-2006, 13:50

La ati e la nvida hanno assolutamente il diritto di fare driver chiusi se ritengono che sia più conveniente farlo.
Vietare l'inclusione di un modulo chiuso nel kernel è una mancanza di libertà.

Non ci sono ragioni tecniche, c'è solo fanatismo.

Decisioni come queste derivano dal fatto che Stallman considera il software proprietario un male da estirpare a ogni costo.
hai il diritto di pensarla come vuoi, ma sembra i post di ilsensine (e forse pure il mio) ti abbiano risposto gia' su questo punto. nessuno vieta all'utente finale di metterli, ben conscio (perche' ti viene detto quando carichi il relativo modulo) di infrangere la GPL. chi distribuisce software GPL invece deve attenersi alla licenza, che non permette di inserire codice chiuso in un codice GPL. Non c'e' molto da obiettare a cio'.

poi puoi continuare a pensare che stallman sia un fanatico (e sicuramente lo e' nei modi) ma quello che dice e' _assolutamente_ giusto.

passa a software con licenza bsd se quella e' la liberta' che cerchi.

ilsensine

27-07-2006, 14:10

Ma ti volevo chiedere ancora... Nvidia com'è messa in questo campo? Cioè fornisce specifiche e quindi driver open? Dato che continuo a leggere che le sue schede son quelle maggiormente supportate da linux...
Il driver nv è open source, ma è solo per il 2d.

Il driver 3d che producono è il miglior driver proprietario in assoluto. Non rilasciano alcuna specifica in questo campo.

ilsensine

27-07-2006, 14:12

La ati e la nvida hanno assolutamente il diritto di fare driver chiusi se ritengono che sia più conveniente farlo.
Vietare l'inclusione di un modulo chiuso nel kernel è una mancanza di libertà.

Non ci sono ragioni tecniche, c'è solo fanatismo.
Ok prendo atto che non hai letto nulla di quello che ho scritto, né l link che ho postato prima.
Oppure hai letto, ma non hai voluto capire.

Decisioni come queste derivano dal fatto che Stallman considera il software proprietario un male da estirpare a ogni costo.
Doh guarda, fino a non molto tempo fa i kernel developer utilizzavano uno strumento closed source per gestire i sorgenti del kernel.
E' bene che rivedi la tua lista di fanatici.

eclissi83

27-07-2006, 14:16

Doh guarda, fino a non molto tempo fa i kernel developer utilizzavano uno strumento closed source per gestire i sorgenti del kernel.

e bitkeeper non solo era closed source, ma la licenza e' talmente restrittiva che se si voleva sviluppare un software analogo a bitkeeper non poteva essere rilasciato con nessuna delle licenze aperte.

NLDoMy

27-07-2006, 14:59

When I am forced to sign NDAs to get hardware specs, the hardware IP "revealed" is inevitably something that some other company has done before, and done better. NDAs and closed specs are IMO only used by vendors to save face, when their hardware design is stupid, and their errata innumerable.

dovrebbe essere messa come popup quando qualcuno apre il forum di linux e os alternativi :D fa sentire bene :D

LukeHack

27-07-2006, 15:17

ilsensine

27-07-2006, 16:01

vietare l'inclusione di un modulo del kernel è cosa buona e giusta :read:
Di per se caricare un modulo in ring0 non è vietato, ci mancherebbe.
Ciò che viola la GPL è quando il modulo in questione si mette a usare le funzioni interne del kernel per i suoi comodi (cosa che tutti i moduli proprietari ovviamente fanno).

javaboy

27-07-2006, 16:35

Ok prendo atto che non hai letto nulla di quello che ho scritto, né l link che ho postato prima.
Oppure hai letto, ma non hai voluto capire.

Doh guarda, fino a non molto tempo fa i kernel developer utilizzavano uno strumento closed source per gestire i sorgenti del kernel.
E' bene che rivedi la tua lista di fanatici.
Dovrò includere qualcuno di questo forum.
Non ho mai parlato dei kernel developer, che mi sembra abbiano sempre tenuto posizioni meno estremiste della FSF.

Lukather

27-07-2006, 17:11

Ma veramente il primo link che ha postato ilsensine rimanda proprio a un articolo di un kernel developer.

Comunque come dici tu ATI e Nvidia sono padronissime di fare driver closed come la FSF è padronissima, visto che è scritto a chiare lettere nella GPL (che non è una serie di leggine a caso ma un contratto di licenza come tutti gli altri), di non mettere nel kernel i suddetti driver closed.

ilsensine

27-07-2006, 17:33

Dovrò includere qualcuno di questo forum.
<sic>

Non ho mai parlato dei kernel developer, che mi sembra abbiano sempre tenuto posizioni meno estremiste della FSF.
Stallman è un fanatico, non utilizzerebbe mai un programma closed source, ma in questo particolare caso, di _principio_ ha ragione. E lo confermano anche i kernel developer, ecco da dove sono saltati fuori. Ora mi dici che questi non sono estremisti, anche se in questo particolare caso la pensano come Stallman. Vabbè...

Altra lettura per te:
http://www.kroah.com/log/linux/cp210x-take2.html?seemore=y
Forse la SiLabs merita più del sottoscritto di essere aggiunto all'elenco dei "fanatici" :)

ilsensine

27-07-2006, 17:36

Comunque come dici tu ATI e Nvidia sono padronissime di fare driver closed
ATI e NVidia sono padronissime di andare al diavolo. _Nessuno_ li obbliga a fornire driver per linux, ma "evidentemente" lo fanno perché...
Lascio il resto all'immaginazione (e alla storia del driver R200, per chi l'ha letta).

Il fatto che i loro driver sono "tollerati" dai kernel developer è null'altro che una cortesia. Ma si stanno piano piano scocciando.

ilsensine

27-07-2006, 17:41

<...>
Tra l'altro -- lungi da me il generalizzare, ma personalmente mi è capitato questo:
http://www.hwupgrade.it/forum/showthread.php?t=989040

Grazie che uno diventa fanatico, quando ti accorgi di aver messo una simile schifezza su un sistema di produzione.

Lukather

27-07-2006, 17:50

Cobra78

27-07-2006, 19:42

Tra l'altro -- lungi da me il generalizzare, ma personalmente mi è capitato questo:
http://www.hwupgrade.it/forum/showthread.php?t=989040

Grazie che uno diventa fanatico, quando ti accorgi di aver messo una simile schifezza su un sistema di produzione.

Sinceramente: il caso che ti è capitato è agghiacciante, non si discute, ma non è che epr forza tutti i driver closed sono delle schifezze (oddio quelli ATI si, ma tralasciamo), così come non è detto che i driver open siano per forza perfetti.

Posto che la mia posizione non è rilevante vista la mia poca esperienza in campo linux, la mia non conoscenza della programmazione e il mio utilizzo unicamente desktop, allora ti chiedo: secondo te cosa dovrebbero fare le case produttrici di hardware? pito questo aseptto del tuo (vostro?) pensiero.

E ancora: ok, i kernel developer si rompono dei driver closed, non li rendono più utilizzabili, e poi che si fa? Non si usa più linux in rpesenza di hardware di un certo tipo?

javaboy

27-07-2006, 21:08

ATI e NVidia sono padronissime di andare al diavolo. _Nessuno_ li obbliga a fornire driver per linux, ma "evidentemente" lo fanno perché...
Lascio il resto all'immaginazione (e alla storia del driver R200, per chi l'ha letta).

Il fatto che i loro driver sono "tollerati" dai kernel developer è null'altro che una cortesia. Ma si stanno piano piano scocciando.
Capisco bene che i kernel developer non amino i driver closed, anche io preferirei che i driver fossero il più possibile open.
Però come dici tu stesso i kernel developer "tollerano" tali driver, la FSF non tollera un bel niente, questo atteggiamento secondo me non fa bene a linux.

Tutto il mio discorso era incentrato su questo, non ho mai preteso di sostenere la bontà dei driver closed rispetto a quelli open, non ho mai detto di esser contento dei driver closed, ho solo affermato che talvolta sarebbe bene venire incontro alle esigenze altrui.

Si stanno pian piano scocciando? Non mi sembra che siano in condizione di imporre niente.

eclissi83

27-07-2006, 21:34

Capisco bene che i kernel developer non amino i driver closed, anche io preferirei che i driver fossero il più possibile open.

beh e ci mancherebbe :)

Però come dici tu stesso i kernel developer "tollerano" tali driver, la FSF non tollera un bel niente, questo atteggiamento secondo me non fa bene a linux.
Tutto il mio discorso era incentrato su questo, non ho mai preteso di sostenere la bontà dei driver closed rispetto a quelli open, non ho mai detto di esser contento dei driver closed, ho solo affermato che talvolta sarebbe bene venire incontro alle esigenze altrui.

ma si puo' anche trovare il compromesso. ti ho fatto vari post fa l'esempio dei driver del modem alcatel speedtouch usb: interfaccia al kernel libera e poi loader esterno in userspace. ai produttori di hw va "meglio" fare ste porcate creando un driver che si interfaccia in toto al kernel, per la famosa security through obscurity (che tanto non funziona).

Si stanno pian piano scocciando? Non mi sembra che siano in condizione di imporre niente.
ripeto che potrebbero trovare un accordo. ricorda che se tu oggi tolleri che i driver closed siano "parte" del kernel, domani tollererai altro. bisogna trovare una soluzione alternativa.

k0nt3

27-07-2006, 23:07

Si stanno pian piano scocciando? Non mi sembra che siano in condizione di imporre niente.
come no? il kernel l'hanno scritto loro e gli hanno appiccicato su una bella GPL -> possono imporre tale condizione, è nel loro pieno diritto.

ps. ilsensine ma quante ne sai :D :sofico:

Cobra78

28-07-2006, 01:17

come no? il kernel l'hanno scritto loro e gli hanno appiccicato su una bella GPL -> possono imporre tale condizione, è nel loro pieno diritto.

ps. ilsensine ma quante ne sai :D :sofico:

Relativo.......se un adato hardware non c'è verso di farlo andare perchè ai kernel developer non sta bene che abbia solo driver closed, beh allora questo diventa un freno alla diffusione....

Finchè si tratta di schede grafichè 3d ci si arrangia in qualche modo, alla peggio si fa ciao ciao a linux per Desktop, se il problema sorge con hardware che si usa in ambito server la faccenda si complica...

LukeHack

28-07-2006, 01:28

Di per se caricare un modulo in ring0 non è vietato, ci mancherebbe.
Ciò che viola la GPL è quando il modulo in questione si mette a usare le funzioni interne del kernel per i suoi comodi (cosa che tutti i moduli proprietari ovviamente fanno).
certo intendevo moduli CLOSED in ring0 che invocano funzioni del kernel (GPL)

Tony Lio

28-07-2006, 08:43

Costringere la ATI a realizzare dei driver open source?
Esatto, ed aggiungi anche NVIDIA ^_

k0nt3

28-07-2006, 11:05

Relativo.......se un adato hardware non c'è verso di farlo andare perchè ai kernel developer non sta bene che abbia solo driver closed, beh allora questo diventa un freno alla diffusione....
prima di tutto non è che ai kernel developer non sta bene perchè si sono svegliati male questa mattina.. loro hanno adottato una licenza (la GPL) e hanno tutto il diritto di farla rispettare. se a te non va bene hai tutto il diritto cambiare sistema operativo e usare BSD che non pone nessun "freno" (abbastanza discutibile) alla sua diffusione.

Finchè si tratta di schede grafichè 3d ci si arrangia in qualche modo, alla peggio si fa ciao ciao a linux per Desktop, se il problema sorge con hardware che si usa in ambito server la faccenda si complica...
quando ci sono degli interessi commerciali in mezzo vedi come si svegliano a distribuire specifiche a destra e a sinistra o a trovare compromessi che accontentano tutti. infatti nei server linux non ha mai avuto alcun problema, anche perchè viene usato da aziende piuttosto grosse e potenti. la cosa è destinata a diventare così anche per il desktop se queste aziende cominciano a usare linux anche per i loro client.. speriamo

Cobra78

28-07-2006, 13:04

se a te non va bene hai tutto il diritto cambiare sistema operativo e usare BSD che non pone nessun "freno" (abbastanza discutibile) alla sua diffusione.

Innanzitutto fammi il favore di moderare i toni, non ho scritto che non mi sta bene, ho premesso che sono niubbo e ho posto delle domande attendendo delle risposte, se poi hai tanta voglia di cacciare gli impuri usufruitori di driver binari è un problema tuo non mio.

Si preme tanto sulla maggiore diffusione di Linux, non è con questo atteggiamento spocchioso che la si favorisce.

Non perdere tempo a rispondermi, tanto non intendo leggere oltre questa discussione visti i toni a cui state arrivando.

k0nt3

28-07-2006, 13:12

Innanzitutto fammi il favore di moderare i toni, non ho scritto che non mi sta bene, ho premesso che sono niubbo e ho posto delle domande attendendo delle risposte, se poi hai tanta voglia di cacciare gli impuri usufruitori di driver binari è un problema tuo non mio.

Si preme tanto sulla maggiore diffusione di Linux, non è con questo atteggiamento spocchioso che la si favorisce.

Non perdere tempo a rispondermi, tanto non intendo leggere oltre questa discussione visti i toni a cui state arrivando.
scusa se i toni ti sono sembrati troppo duri :) non era mia intenzione e ho sbagliato... quello che volevo dire è che non è un problema mio e nemmeno tuo. è ai kernel developer che spetta difendere la loro licenza, qui non si tratta di "cacciare gli impuri usufruitori di driver binari", ma di far rispettare una licenza. le soluzioni e i compromessi ci sono come ha fatto notare ilsensine.
se poi segui anche i link che ha postato vedi che l'inclusione di parti closed source nel kernel non è tanto una bella cosa.
:mano:

Cobra78

28-07-2006, 13:29

eclissi83

28-07-2006, 13:55

Ok va bene, malinteso chiarito ;)

Comuqneu sia chiaro: sul fatto che le licenze vadano rispettate non mi permetto di discutere, il dubbio che mi sorge è che se i Kernel Developer non hanno ancora fatto questa "azione di forza" per far cambiare strada alle compagnie, forse non è realmente così conveniente.
credo che non si debba fare un'azione di forza. credo che i kernel developer debbano iniziare a dialogare con le case produttrici di hardware spingendoli verso soluzioni maggiormente compatibili con la GPL.

ciau

Mezzelfo

28-07-2006, 14:08

javaboy sei libero di criticare la Free Software Foundation ma probabilmente non sai nemmeno cosa sia, come sia nata e quali sono i suoi obiettivi.

Dal sito della FsF (http://www.fsf.org)
"The Free Software Foundation (FSF), established in 1985, is dedicated to promoting computer users' rights to use, study, copy, modify, and redistribute computer programs. The FSF promotes the development and use of free software, particularly the GNU operating system, used widely in its GNU/Linux variant."

Ho messo in evidanza i 2 punti fondamentali che un modulo closed non rispetta. Non rispetta il tuo diritto di studiare come funziona e di modificarlo anche se può essere usato e distribuito.
Ora visto che la parte filosifica ed etica non sembra interessarti minimamente e quindi non sei chiaramente un sostenitore del Free Software (dove: "free'' as in "free speech", not as in "free beer".) tu sei libero come chiunque altro di usare, studiare, copiare, modificare e ridistribuire software open source.

La Free Software Foundation e la Licenza GNU sono state fondamentali per lo sviluppo e la diffusione del software open source. Pensi che se la GNU fosse stata diversa oggi Linux e il Software Open source sarebbero a questi livelli?

Le aziende, come ad esempio IBM, invece di investire nello sviluppo di codice aperto di cui tutti avrebbero goduto i benefici, avrebbero fatto sviluppare i moduli proprietari che gli interessavano e basta. Il Kernel Linux esisterebbe come è ora?

La licenza GNU garantisce le 4 libertà fondamentali del Free Software:
* The freedom to run the program, for any purpose (freedom 0).
* The freedom to study how the program works, and adapt it to your needs (freedom 1). Access to the source code is a precondition for this.
* The freedom to redistribute copies so you can help your neighbor (freedom 2).
* The freedom to improve the program, and release your improvements to the public, so that the whole community benefits (freedom 3). Access to the source code is a precondition for this.

L'unica ""restrizione"" è che ti dice che anche TU devi garantire queste stesse libertà agli altri quando realizzi altro software o lo distribuisci. Se pensi che questo sia così fanatico, che sia così fanatico se ti dico "guarda, ho costruito una tagliaerbe, prendila pure se ti serve, puoi usarla per fare quello che vuoi, puoi capire come funziona smontadola e guardandoci dentro; ah, puoi anche migliorarla se vuoi e ne puoi costruire una uguale, basta che poi la presti anche agli altri che te la chiedono e gli permetti, proprio come ho fatto io con te, di fare le stesse cose, cioè usarla come vogliono, di vedere come è fatta, di costruirne altre e di modificarle e di prestarla ad altri ancora" allora io sono Futtutissimo Fanatico e ne vado fiero. :O

superbubba

28-07-2006, 14:34

Anche se già linkato all'inizio del thread, vorrei riproporre (in italiano) il post di Arjan van de Ven (http://www.ussg.iu.edu/hypermail/linux/kernel/0512.0/0972.html), Linux in un mondo di binari.

Cosa succederebbe.. se gli sviluppatori del kernel un giorno decidessero di accettare i moduli binari e farli diventare essenziali per il progresso di Linux?
.. un ipotetico scenario da giorno del giudizio, by Arjan van de Ven.

Ia prima cosa da puntualizzare è che lo scenario è improbabile, ma in un modo o nell’altro tutti gli assunti che seguiranno possono essere veri.

Il 6 Dicembre 2005 gli sviluppatori del kernel decidono in massa sulla legalità e preferibilità dei moduli binari nel kernel. In un primo momento il processo di sviluppo del kernel non cambia molto tranne una manciata di simboli in più e la rimozione di EXPORT_symbol_gpl.

Nelle 3 settimane successive le distribuzioni Red Hat Enterprise Linux, SuSE Sles cominciano ad includere una grande verietà di moduli binari sui loro cd di installazione. Debian ci rinuncia per seguire i propri principi, come fanno altre distribuzioni (Fedora Core, Open Suse..)

Le distribuzioni enterprise includono non solo i driver Ati e Nvidia ma anche i driver OEM per il raid, moduli per wireless, winmodem, windsl e TCP-offloading. Comunque, a differenza dei driver Nvidia e Ati, la maggior parte dei vendor che usano driver binari non forniscono i loro diver di uno “strato collante” in forma sorgente ma binario puro.

Acuni hardware vendor che sono stati in passato favorevoli all’open source, vedendo i loro competitor rilasciare solo driver binari, sentono pressioni all’interno per passare ad una struttura closed, riendendosi conto che spesso non hanno potuto implementare alcune features in open source per mantenere all’interno alcune Proprietà Intellettuali. Come risultato c’è la percezione che i competitor binari abbiano un vantaggio in partenza, o quanto meno il pensiero che si potrebbe avere più possibilità nel binario a spingere su tutte le caratteristiche dell’hw senza avere problemi di IP.

1 Febbraio 2006 la maggior parte dei produttori oltre ai driver open ha un piano di lavoro per rilasciare i propri driver binari. Alcuni non sviluppano più i driver open perchè non hanno risorse per fare entrambi.

1 Marzo. Le nuove linee di server di fascia alta sono equipaggiate da storage e network hardware di nuova generazione. Naturalmente sono disponibili i driver binari per le 2 ultime distribuzioni di RHEL e SLES, già integrati nelle versioni di febbraio delle suddette distribuzioni.
Un solo vendor produce anche .o insieme al binario. Due produttori di schede di rete riducono al minimo il supporto per i driver open su nuove periferiche, tutti gli altri li eliminano.
Per l’hardware consumer non cambia nulla; molti chipset si standardizzando su AHCI per SATA e ereditano le feature di networking chipset dalla linea server.

1 Aprile. Un paio di chipset sono aggiornati per includere una nuova ed eccitante feature audio per abilitare la visione avanzata di DVD. Sfortunatamente ciò devia dallo standard per le interfacce audio i810. Uno dei due produttori rilascia ul driver binario per linux, l’altro non considera il s.o. rilevante per il mercato desktop e non ha mai pensato di supportarlo.

1 Maggio. La maggior parte dell’hardware sui server richiede almeno 2 o 3 moduli binari per essere operativo.Mentre alcuni di questi sono disponibili nella forma “blob+glue”, la maggior parte sono solo binari per RHEL3, RHEL4 e SLES9 e alcuni solo per la nuova SLES10.
I sistemisti Linux hanno la possibilità di scegliere tra 4 kernel diversi per i loro server, ma nessuna speranza di usarne uno vanilla da kernel.org. Gli utenti Ubuntu sono attivi e lavorano duro per far funzionare alcuni driver sulla loro distribuzione. Grazie al loro successo circa il 50% dei server riesce a lavorare anche con un kernel Ubuntu.

1 Giugno - Flame aguerrito, il quarto con questo oggetto da gennaio, sulla mailing-list del kernel linux. Utenti e sviluppatori chiedono di adottare l’ABI (Application Binary Interface) usata in RHEL o SLES. L’analisi mostra come ciò non sia possibile e il thread diventa una discussione sul designa di una nuova ABI o la revisione di quella esistente. Molti sviluppatori sentono che la corrente struttura non è all’altezza e che nuove API/ABI più stabili sarebbero la strada più semplice. Altri ribattono che non solo sarebbe una perdita di tempo ma sarebbe anche necessario un freeze per supportare RHEL5. Gli amministratori sui server di produzione usano RHEL o SLES, o cloni come CENTOS che usano kernel binary compatibili.

1 Luglio. E’ diventata un impresa usare linux sui normali pc senza driver binari. Mentre un anno prima agli utenti servivano solo per l’accelerazione 3D, ora anche il 2D non va senza moduli binari, stesso dicasi per il networking (cable o wireless) e suono. Per metà delle macchine il supporto alle periferiche non c’è e il 20% usa ndiswrapper come “translation layer” per suono e networking. Debian ha perso la maggior parte degli utenti, perchè quasi impossibile da usare su tutte le macchine, così come Ubuntu e le distrubuzioni Ubuntu-like.
Debian-legal e gli altri progetti simili sono impossibili da leggere per chi non fosse interessato a flame continui. Ormai gli ultimi vendor che mantenevano una versione opensource dei driver non lo fanno più.

14 Luglio. Linus annuncia la stabilità della dell’ ABI nel kernel 2.7 e annuncia il fork alla versione 2.8 dovve si svilupperà un ABI differente. In pratica, solo le persone che resteranno con le loro vecchie macchine potranno aiutare nello sviluppo.

21 Agosto. Viene scoperto un baco nella serie 2.6 che evidenzia un errore di design in una funzionalità chiave delle API di sysfs. Fixarlo significa rompere l’ABI dei moduli e il che coinvolgerebbe il funzionamento tutti i moduli binari esistenti, ma non fixarlo significherebbe lasciare una vulnerabilità per scalare privilegi di root. Una fix veloce è disponibile come opzione CONFIG_, ma chi ha bisogno di driver binari non ha altra chance che lasciare i sistemi vulnerabili.
E’ subito flame in ikml, Linus avrebbe sbagliato a “freezare” l’ABI, piuttosto si sarebbe dovuto crearne una nuova destinata al freeze?! Lo sviluppo del 2.7 si ferma ed è proposta una patch per avere di nuovo l’ ABI del 2.6, annullando i progressi in VM e le patches realtime di Ingo Molnar.

26 Agosto. Viene reso noto su bugtraq un exploit per il baco, usato in uno svariato numero di rootkit. Uno script php lo usa per raggiungere i privilegi di root! Gli utenti fanno pressioni perchè i moduli vengano riscritti per il nuovo ABI, alcuni lo faranno nelle prossime 3 settimane. Altri, specie nel mercato consumer, dicono che i driver in questione sono per hardware non più in vendita quindi non si curano di rilasciare nuovi driver binari.

Questo scenario può sembrare improbabile. E per fortuna il presupposto (l’evento del 6 Dicembre) è improbabile.

Comunque, e sfortunantamente, alcuni di questi “salti” non sono affatto improbabili. Potrebbero accadere tranquillamente, come i flame sulla discontinuità API/ABI. Pensiamo poi all’effetto ndiswrapper con fornitori che dicono “supportiamo linux, il ndiswrapper può usare il nostro driver di windows”. Spero che ciò non accada. Alcune di queste speranze sono speranze vane, ma credo che il vantaggio della liberà alla fine è forte abbastanza da soverchiare le opinioni di chi non è daccordo.

ilsensine

28-07-2006, 14:37

Capisco bene che i kernel developer non amino i driver closed, anche io preferirei che i driver fossero il più possibile open.
Però come dici tu stesso i kernel developer "tollerano" tali driver, la FSF non tollera un bel niente, questo atteggiamento secondo me non fa bene a linux.
La fsf c'entra con linux meno di quanto pensi, puoi stare tranquillo.

Si stanno pian piano scocciando? Non mi sembra che siano in condizione di imporre niente.
Sono nelle condizioni di imporre la GPL nello stesso modo in cui la Microsoft impone la sua EULA.

A me non piace la EULA Microsoft, ma non per questo vado a dire cose simili. Semplicemente, la rispetto e uso altro software.

ilsensine

28-07-2006, 14:45

Posto che la mia posizione non è rilevante vista la mia poca esperienza in campo linux, la mia non conoscenza della programmazione e il mio utilizzo unicamente desktop, allora ti chiedo: secondo te cosa dovrebbero fare le case produttrici di hardware? pito questo aseptto del tuo (vostro?) pensiero.
Ne riparliamo l'anno prossimo, quando succederà un certo casino.
Per adesso non voglio affrontare questo argomento.

E ancora: ok, i kernel developer si rompono dei driver closed, non li rendono più utilizzabili, e poi che si fa? Non si usa più linux in rpesenza di hardware di un certo tipo?
Tu (e Javaboy) potete stare tranquilli, i kernel developer non faranno nulla per impedire il funzionamento ai driver closed source che esistono adesso.

k0nt3

28-07-2006, 14:57

Ne riparliamo l'anno prossimo, quando succederà un certo casino.
Per adesso non voglio affrontare questo argomento.

:mbe: casino? non puoi lasciarci con il fiato sospeso fino all'anno prossimo :eek: ! alludi al fatto che nel futuro al posto del bios ci sarà EFI e quindi i drivers non dipenderanno dalla piattaforma?

ps. però voglio un EFI opensource :asd:

javaboy

28-07-2006, 15:02

eclissi83

28-07-2006, 15:11

Però non permetteresti di montare sul tagliaerbe un pezzo indispensabile solo perchè questo a sua volta non può essere smontato.
Questo secondo me non conviene a nessuno.
perche' non conviene?

LukeHack

28-07-2006, 15:15

perche' non conviene?
esatto, perchè non conviene? calcola che a parte i driver nvidia, tutto il resto O funziona su codice open, OPPURE funziona MALE (vedi ati)..

ilsensine

28-07-2006, 15:16

:mbe: casino? non puoi lasciarci con il fiato sospeso fino all'anno prossimo :eek: ! alludi al fatto che nel futuro al posto del bios ci sarà EFI e quindi i drivers non dipenderanno dalla piattaforma?

ps. però voglio un EFI opensource :asd:
E' bello vedere come la gente vive nel mondo dei sogni :asd:

Ne riparliamo tra un pò di mesi, ora è prematuro.

javaboy

28-07-2006, 15:17

perche' non conviene?
Devo dedurre che tu i driver nvidia non li usi.

javaboy

28-07-2006, 15:20

Perchè non vietare anche gli eseguibili closed source a questo punto?

LukeHack

28-07-2006, 15:21

Devo dedurre che tu i driver nvidia non li usi.
infatti sono un' eccezione xchè in effetti sono gli unici driver closed che funzionano BENE (13200 fps con la mia vga al glxgears)..

LukeHack

28-07-2006, 15:22

Perchè non vietare anche gli eseguibili closed source a questo punto?
xche non VIOLANO LA GPL, non andando ad attaccarsi al kernel ;)

javaboy

28-07-2006, 15:27

xche non VIOLANO LA GPL, non andando ad attaccarsi al kernel ;)
Si infatti sto proponendo una modifica alla gpl.

eclissi83

28-07-2006, 15:27

Devo dedurre che tu i driver nvidia non li usi.
dici bene, non li uso... e fino a qualche mese fa (prima che si rompesse, dopo 7 anni di onorato servizio) avevo una tnt2. ora ho una ati prestata da un amico, ma a parte un primo periodo, non ho usato i driver nvidia, cosi' come ora non uso i driver ati.

ilsensine

28-07-2006, 15:45

Si infatti sto proponendo una modifica alla gpl.
Non c'entra la gpl qui.

I kernel developer hanno messo nero su bianco che il semplice utilizzo delle syscall di linux non è sufficiente affinché un programma possa essere considerato opera derivata dal kernel linux. Le syscall possono essere utilizzate da chiunque.

Cobra78

28-07-2006, 15:46

Tu (e Javaboy) potete stare tranquilli, i kernel developer non faranno nulla per impedire il funzionamento ai driver closed source che esistono adesso.

Chiaramente non hai capito buona aprte di quello che ho scritto se mi accosti a Javaboy come idee, meglio che chiuda qui il discorso va, come ho detto in qeusto topic si sta passando il segno quanto ad atteggiamenti.

Lasciamo perdere che è meglio...

@LukeHack

Semplicemente ha detto mi ha risposto una cosa che non c'entra una beneamata fava con quello che ho chiesto, ma frutto di una secondo me colpevole maleinterpretazione

Ho scritto che volgio suare i driver closed a tutti i costi? No..

Ho fatto domande aspettandomi risposte (e questo l'avevo già detto a K0nt3), invece di spiegarmi dove stia il problema, cosa io abbia detto di sbalgiato, ha scritto qualcosa che suona molto come "tranquilli bimbi che io giochino tanto non vi viene tolto, non sforzatevi a capire".

LukeHack

28-07-2006, 15:48

Chiaramente non hai capito buona aprte di quello che hos cirtto se mi accosti a Javaboy come idee, meglioc he chiuda qui il discorso va, come ho detto inq eusto topic si sta passando il segno quanto ad atteggiamenti.
a me sembra che ilsensine non ti abbia attaccato (neanche a javaboy) :mbe:

ilsensine

28-07-2006, 15:52

a me sembra che ilsensine non ti abbia attaccato (neanche a javaboy) :mbe:
Infatti; volevo solo rispondere alla domanda. Non è possibile che i "kernel developer si rompano dei driver closed" e da un giorno all'altro li proibiscano.
Stanno solo mettendo sempre più paletti a ciò che i driver closed (futuri) non possono assolutamente toccare.

Cobra78

28-07-2006, 15:55

Infatti; volevo solo rispondere alla domanda. Non è possibile che i "kernel developer si rompano dei driver closed" e da un giorno all'altro li proibiscano.
Stanno solo mettendo sempre più paletti a ciò che i driver closed (futuri) non possono assolutamente toccare.

E dirlo così subito costava tanto?

Una risposta chaira, non ho pretese assurde, poi sarò anche io paranoico a volte...

k0nt3

28-07-2006, 17:12

E' bello vedere come la gente vive nel mondo dei sogni :asd:

Ne riparliamo tra un pò di mesi, ora è prematuro.
:asd: maledizione lo volevo sapere... ma google lo sa?

eliano

28-07-2006, 18:47

Ho letto con attenzione tutto il thread e mi sono fatto un'idea che vorrei condividere con voi.
La questione se si debba tollerare o meno un driver closed è una questione di momento, facilmente comprensibile se stratifichiamo un attimo il ragionamento. Quali sono gli obbiettivi di linux:
1) offrire un sistema funzionante, utilizzabile dal numero più elevato possibile di persone
2) Offrire la possibilità di personalizzare il sistema suddetto modificando i sorgenti e ricompilando i moduli, per poi magari mettere queste modifiche a disposizione della comunità
Tenendo i punti in quest'ordine si può capire la tolleranza iniziale nei confronti del closed perché ha un preciso scopo: offrire qualcosa di funzionante, magari prestazionalmente scarso, ma funzionante.
Nel mentre si può studiare l'HW e magari il produttore potrebbe cambiare idea e valutare che ha solo da guadagnare nel rilasciare i sorgenti (o magari sono passati 6(!) mesi e l'HW di una scheda video non è più così rivoluzionario da meritare protezione sulle specifiche di funzionamento).
Questo lascia spazio al lavoro certosino dei reverse engineer che studiano il funzionamento del driver e cercano di riprodurne le funzioni.
Appena disponibile qualcosa su cui lavorare, giustamente, tolleranza 0: non c'è più bisogno che vi incomodiate a fornire il vostro preziosissimo driver, da ora in poi ce lo facciamo da soli, perché la GPL...
Questo significa che spesso la FSF chiude un occhio, ma solo perché gli utenti linux non debbano soffrire particolari limitazioni, non perché alcune sue parti credano meno al principio del Free Software.
Quanto sopra, ovviamente, IMHO.

ilsensine

28-07-2006, 18:55

Tenendo i punti in quest'ordine si può capire la tolleranza iniziale nei confronti del closed perché ha un preciso scopo: offrire qualcosa di funzionante, magari prestazionalmente scarso, ma funzionante.
No, non è questo lo scopo.

Ho letto un thread, in passato, sempre di Greg KH, dove negava a un produttore di driver closed l'utilizzo di una funzionalità del kernel marcata come "disponibile solo per i driver GPL". Gli sviluppatori non pensano che sia meglio "un driver proprietario che nessun driver". Anzi, pensano il contrario.

I driver sono tollerati (in determinati casi) in quanto si vuole lasciare all'utente la libertà di utilizzarli o meno, a seconda del proprio giudizio.

Per la cronaca, Greg KH offrì a quel tizio, che voleva fare il driver proprietario, il suo personale e pieno supporto di come realizzare lo stesso driver completamente in userspace (pur mantenendolo proprietario). Greg spesso sembra estremista (e per quel che riguarda il kernel lo è, e io sono d'accordo con lui), ma di fronte a una persona simile possiamo solo toglierci il cappello.

Scoperchiatore

28-07-2006, 21:42

No, non è questo lo scopo.

Ho letto un thread, in passato, sempre di Greg KH, dove negava a un produttore di driver closed l'utilizzo di una funzionalità del kernel marcata come "disponibile solo per i driver GPL". Gli sviluppatori non pensano che sia meglio "un driver proprietario che nessun driver". Anzi, pensano il contrario.

I driver sono tollerati (in determinati casi) in quanto si vuole lasciare all'utente la libertà di utilizzarli o meno, a seconda del proprio giudizio.

Per la cronaca, Greg KH offrì a quel tizio, che voleva fare il driver proprietario, il suo personale e pieno supporto di come realizzare lo stesso driver completamente in userspace (pur mantenendolo proprietario). Greg spesso sembra estremista (e per quel che riguarda il kernel lo è, e io sono d'accordo con lui), ma di fronte a una persona simile possiamo solo toglierci il cappello.

Ma lo fanno a tempo perso, oppure percepiscono una qualche forma di introito?

Comunque, sono d'accordo con la linea di pensiero "se non mi dici le specifiche, è perchè probabilmente fa schifo, e tu lo sai".

stefanoxjx

28-07-2006, 21:47

Interessante questa discussione, mi iscrivo, ma solo per seguirla in modo passivo.
Ciao a tutti.

P.S. Però, @ilsensine, potresti anche anticiparci qualcosina sui casini che verranno avanti l'anno prossimo.
Solo un pochino pochino pochino così :sofico:

eliano

28-07-2006, 22:02

No, non è questo lo scopo.

Ho letto un thread, in passato, sempre di Greg KH, dove negava a un produttore di driver closed l'utilizzo di una funzionalità del kernel marcata come "disponibile solo per i driver GPL". Gli sviluppatori non pensano che sia meglio "un driver proprietario che nessun driver". Anzi, pensano il contrario.

I driver sono tollerati (in determinati casi) in quanto si vuole lasciare all'utente la libertà di utilizzarli o meno, a seconda del proprio giudizio.

Per la cronaca, Greg KH offrì a quel tizio, che voleva fare il driver proprietario, il suo personale e pieno supporto di come realizzare lo stesso driver completamente in userspace (pur mantenendolo proprietario). Greg spesso sembra estremista (e per quel che riguarda il kernel lo è, e io sono d'accordo con lui), ma di fronte a una persona simile possiamo solo toglierci il cappello.

Adesso sono più chiare le sottili differenze, non solo ideologiche.
Questo toglie qualunque attenuante a chicchessia, se una società decide di non rilasciare un driver open, lo fa solo per miopia, mentre si potrebbe risparmiare molto lavoro inutile da ambo le parti, a beneficio degli utenti finali e, se vogliamo anche dei bilanci aziendali.

Nescio

30-07-2006, 22:46

idt_winchip

01-08-2006, 10:23

chiudere il progetto koroora per una simile cosa per il mio modesto parere è da integralisti open source.
In fondo praticamente tutti abbiamo dei driver closed per il reparto video..mah..

ercoppa

01-08-2006, 10:37

ma quindi andrebbe chiusa anche il progetto italiano di RR4? anche quello integra driver closed o no?

dsfjhsdfgjafaef

01-08-2006, 10:48

Penso che ilsensine si riferisca al TCPA......vero? :rolleyes:

khelidan1980

01-08-2006, 15:04

chiudere il progetto koroora per una simile cosa per il mio modesto parere è da integralisti open source.
In fondo praticamente tutti abbiamo dei driver closed per il reparto video..mah..

Forse non hai letto il 3d,ma la questione è,che per ora vengono tollerati driver closed a patto che non vengano distribuiti insieme al kernel,che vengano installati poi dall'utente,quella distro viola,se mi permettete,la gpl ad un livello piu alto,se tu vuoi distribuire una distro con kernel linux con dei driver proprietari semplicemente non puoi perchè il kernel è sotto licenza gpl,ma ovviamente distrubuire qualla live senza i driver 3d non avrebbe senso.....

Aslo

02-08-2006, 02:08

Ho letto tutto il thread, e mi sento di dire la mia. Scusate fin da subito se vi sbatto in faccia la mia spudorata e pragmatica opinione di utente linux che vuole un sistema funzionante.
In questo momento, vi scrivo dal live cd di kororaa, con driver fglrx, e devo dire che è un'ottima live distro (quando funziona, sul mio laptop non riconosce la scheda, ma vabbe...).

Dal punto di vista di utente, a me non me ne frega un fico secco se i driver sono closed o open source, basta che funzionino. Violano la GPL? Probabilmente è la GPL che è troppo restrittiva, e giustamente gli sviluppatori del kernel chiudono un occhio, pur storcendo il naso in quanto preferirebbero dei driver liberi (GPL).

Dal punto di vista di sostenitore del software libero, quale sono, anche se non fanatico in nessun modo, quando posso scegliere tra due alternative equivalenti, una libera e l'altra no, scelgo la prima. Tuttavia, se l'unica alternativa è closed source, la uso lo stesso, e non provo disgusto.

Nessuno al mondo, in questo momento, è in grado di costringere ATI o nVidia a rilasciare driver open source, non lo faranno e basta.
Loro sviluppano i driver per linux solo per stare in pari con la concorrenza. Se in seguito ad una presa di posizione degli sviluppatori del kernel, fossero costrette a scegliere tra rilasciare driver GPL oppure non rilasciarli affatto, sceglierebbero quest'ultima opportunità ad occhi chiusi.

Giusto perché non mi si venga a dire che non ho letto i messaggi precedenti, vediamo un po' di "smontare" l'ipotesi di un driver in userspace. Già ora i driver video sono in parte nel kernel e parte in user space (modulo xorg, librerie OpenGL, pannello di controllo), ma evidentemente anche quel minimo indispensabile che sta dentro al modulo kernel non sono disposti a esporlo.
Se invece fosse possibile spostare ancora parte del codice dal modulo kernel alle componenti user space, probabilmente ciò andrebbe a scapito delle prestazioni, che in questo caso sono tutto.

Il giorno che linux su desktop dovesse avere rilevanti quote di mercato, sicuramente sarà possibile costringere ATI e nVidia a rilasciare driver open source, ma quel giorno è lontano.

Gica78R

02-08-2006, 02:15

Nessuno al mondo, in questo momento, è in grado di costringere ATI o nVidia a rilasciare driver open source, non lo faranno e basta.

Beh, e allora perché qualcuno dovrebbe costringere gli sviluppatori del kernel a cambiare i termini della licenza adottata? Ognuno fa quel che vuole con la sua proprietà intellettuale, no? :)

k0nt3

02-08-2006, 11:10

Se invece fosse possibile spostare ancora parte del codice dal modulo kernel alle componenti user space, probabilmente ciò andrebbe a scapito delle prestazioni, che in questo caso sono tutto.

è tutto da dimostrare quanto si perde in prestazioni, inoltre se è possibile farlo DEVONO farlo per non andare in contrasto con la GPL

ps. le prestazioni sono tutto? nonostante i drivers fglrx siano nel kernel hanno prestazioni scandalose

pps. nessuno pretende drivers opensource da ati e nvidia, ma mi pare che ilsensine ha già spiegato benissimo quali possono essere i compromessi

ilsensine

02-08-2006, 11:41

Solo alcune precisazioni...
Dal punto di vista di utente, a me non me ne frega un fico secco se i driver sono closed o open source, basta che funzionino.
A te può non fregare nulla, ma agli sviluppatori del kernel (coloro che detengono il copyright sul loro codice) interessa eccome se il codice viene utilizzato da altri in difformità della licenza che _loro_ stessi hanno voluto scegliere.
Immagina se quelli di Wine decidessero di distribuire una dll copiata para para da windows...bombardamento a tappeto...

Violano la GPL? Probabilmente è la GPL che è troppo restrittiva
Per me è estremamente restrittiva la EULA Microsoft. Cosa faccio quindi?

e giustamente gli sviluppatori del kernel chiudono un occhio, pur storcendo il naso in quanto preferirebbero dei driver liberi (GPL).
Chiudono un occhio solo in certi casi (e sempre meno).

Dal punto di vista di sostenitore del software libero, quale sono, anche se non fanatico in nessun modo, quando posso scegliere tra due alternative equivalenti, una libera e l'altra no, scelgo la prima. Tuttavia, se l'unica alternativa è closed source, la uso lo stesso, e non provo disgusto.
Il punto su cui stiamo discutendo è diverso: la "unica soluzione alternativa" sta usando, di fatto in maniera illegale, un altro software (il kernel).
I software proprietari sono i benvenuti, se rispettano i copyright delle altre persone (nella _stessa_ maniera con cui rispettano i copyright di altri moduli proprietari che il loro software eventualmente usa...dove sta la differenza?). Poi ognuno è libero di usarli o meno, come preferisce.

Giusto perché non mi si venga a dire che non ho letto i messaggi precedenti, vediamo un po' di "smontare" l'ipotesi di un driver in userspace. Già ora i driver video sono in parte nel kernel e parte in user space (modulo xorg, librerie OpenGL, pannello di controllo), ma evidentemente anche quel minimo indispensabile che sta dentro al modulo kernel non sono disposti a esporlo.
Se invece fosse possibile spostare ancora parte del codice dal modulo kernel alle componenti user space, probabilmente ciò andrebbe a scapito delle prestazioni, che in questo caso sono tutto.
Sei ancora un pò lontano dallo smontare l'ipotesi di driver in user space. Prima dovresti capire quando è possibile, quando non è possibile, oppure quando e come si deve ricorrere a soluzioni miste. Solo allora puoi fare il punto della situazione.

Il giorno che linux su desktop dovesse avere rilevanti quote di mercato, sicuramente sarà possibile costringere ATI e nVidia a rilasciare driver open source, ma quel giorno è lontano.
mmm non credo che le quote di mercato di linux abbiano qualche rilevanza sulle posizioni di ATI e nvidia...

Aslo

02-08-2006, 17:49

Solo alcune precisazioni...

A te può non fregare nulla, ma agli sviluppatori del kernel (coloro che detengono il copyright sul loro codice) interessa eccome se il codice viene utilizzato da altri in difformità della licenza che _loro_ stessi hanno voluto scegliere.
Immagina se quelli di Wine decidessero di distribuire una dll copiata para para da windows...bombardamento a tappeto...

In realtà me ne frega eccome, da un punto di vista globale ... ma come utente, no. ;)

Per me è estremamente restrittiva la EULA Microsoft. Cosa faccio quindi?

Anche secondo me e troppo restrittiva, alla faccia! Il "cavillo" della GPL è nulla in confronto!
Ma, appunto, secondo me è un cavillo, non una cosa di fondamentale importanza per la sopravvivenza di linux e del software libero.

I software proprietari sono i benvenuti, se rispettano i copyright delle altre persone (nella _stessa_ maniera con cui rispettano i copyright di altri moduli proprietari che il loro software eventualmente usa...dove sta la differenza?). Poi ognuno è libero di usarli o meno, come preferisce.

Si, ma certe volte la ragione e il buon senso devono prevalere, noi siamo esseri umani, non computer!
E non dirmi che, se il buon senso prevalesse, ati e nvidia rilascerebbero driver open source, ti dico già che sono perfettamente d'accordo, ma loro no :boh:

Sei ancora un pò lontano dallo smontare l'ipotesi di driver in user space. Prima dovresti capire quando è possibile, quando non è possibile, oppure quando e come si deve ricorrere a soluzioni miste. Solo allora puoi fare il punto della situazione.

Per farlo avrei bisogno dei sorgenti dei loro driver ... :D

mmm non credo che le quote di mercato di linux abbiano qualche rilevanza sulle posizioni di ATI e nvidia...
Appunto, non ne hanno, adesso.
In un (molto) ipotetico futuro in cui il 30% degli utenti usa linux per desktop, vedi che le cose cambiano ...
In quel momento, gli sviluppatori del kernel potranno far rispettare pienamente la GPL ai produttori di hardware, obbigandoli a rilasciarli sotto GPL, o almeno a rendere pubbliche le specifiche (nel caso non sia possibile implementarli in user space, ovviamente).

@k0nt3: infatti, ho appositamente comprato un notebook con scheda nvidia perché i driver sono più performanti sotto linux ;)

k0nt3

02-08-2006, 19:55

@Aslo
non stiamo chiedendo ad ati e nvidia di farci vedere come hanno implementato il loro driver.. ma di lasciare le parti chiuse in userspace in modo che la licenza del kernel non sia violata. tutto qua

quando hai detto che avevi letto tutto il thread.. hai letto anche la parte sulle possibili evoluzioni nel caso i kernel developers accettassero moduli chiusi nel kernel? :read:

Aslo

03-08-2006, 00:34

@Aslo
non stiamo chiedendo ad ati e nvidia di farci vedere come hanno implementato il loro driver.. ma di lasciare le parti chiuse in userspace in modo che la licenza del kernel non sia violata. tutto qua

E' una richiesta che è necessaria solo per il rispetto della GPL, ma tecnicamente è (probabilmente) la soluzione migliore.
In altre situazioni, potreste dirmi che avere del codice proprietario che gira in ring0 è un pericolo per la sicurezza e la stabilità, ma qui stiamo parlando di computer desktop, e di utenti che vogliono performance. Chi predilige la sicurezza e la stabilità, e non ha necessità del 3D, può benissimo usare il driver "vesa".
Naturalmente, ammetto di non essere sicuro che sia necessario implementare il driver nel kernel, ma se cosi non fosse, cosa costerebbe ad ati e nvidia farlo in userspace? perché non lo fanno? gli è stato proposto e hanno rifiutato (non è una domanda retorica)?

quando hai detto che avevi letto tutto il thread.. hai letto anche la parte sulle possibili evoluzioni nel caso i kernel developers accettassero moduli chiusi nel kernel? :read:
Si, l'ho letto. Non è poi uno scenario così catastrofico, già con windows questo succede ... ma noi non vogliamo che linux finisca come windows, vero? Perfetto, allora lasciamo le cose come stanno (niente ABI), ma lasciamo liberi i produttori di sviluppare driver closed source, anche all'interno del kernel. Questo scenario è diverso da quello descritto, se non ho letto male.

stefanoxjx

03-08-2006, 09:14

Si, l'ho letto. Non è poi uno scenario così catastrofico, già con windows questo succede ... ma noi non vogliamo che linux finisca come windows, vero? Perfetto, allora lasciamo le cose come stanno (niente ABI), ma lasciamo liberi i produttori di sviluppare driver closed source, anche all'interno del kernel. Questo scenario è diverso da quello descritto, se non ho letto male.

Bisogna anche dire che se è vero che l'instabilità di windows nasce dalla non perfetta compatibilità dei drivers dei produttori, non vorrei che poi alla fine a forza di driver closed linux diventi una videata blu :read:

ilsensine

03-08-2006, 09:16

Ma, appunto, secondo me è un cavillo, non una cosa di fondamentale importanza per la sopravvivenza di linux e del software libero.
Alla faccia del cavillo! E' la _vita_ del software GPL.
Ti sei mai chiesto come mai i software con licenza GPL hanno un parco sviluppatori più ampio del software con licenza BSD? Quel "cavillo", come lo chiami tu, è la garanzia estrema per gli sviluppatori che il loro codice e il loro lavoro non possa essere "utilizzato a sbafo" da qualcun altro.

Per farlo avrei bisogno dei sorgenti dei loro driver ... :D
Non necessariamente; dovresti sapere cosa può fare un modulo in kernel space che non può fare un modulo in user space. Il resto sono scelte di design.

Appunto, non ne hanno, adesso.
In un (molto) ipotetico futuro in cui il 30% degli utenti usa linux per desktop, vedi che le cose cambiano ...
In quel momento, gli sviluppatori del kernel potranno far rispettare pienamente la GPL ai produttori di hardware, obbigandoli a rilasciarli sotto GPL, o almeno a rendere pubbliche le specifiche (nel caso non sia possibile implementarli in user space, ovviamente).
Sarei felice di venire smentito (wow il 30% :D ), ma non credo affatto che andrebbe così.

ilsensine

03-08-2006, 09:18

@Aslo
non stiamo chiedendo ad ati e nvidia di farci vedere come hanno implementato il loro driver.. ma di lasciare le parti chiuse in userspace in modo che la licenza del kernel non sia violata. tutto qua
Giusto per buttare un pò di benzina sul fuoco...questo sarebbe sufficiente a risolvere definitivamente ogni problema con la GPL. ,ma sicuramente non farebbe contenti i "talebani" come me ;)
Comunque in questo scenario nessuno potrebbe più accusare ATI e nvidia di violare alcunché.

ilsensine

03-08-2006, 09:23

Bisogna anche dire che se è vero che l'instabilità di windows nasce dalla non perfetta compatibilità dei drivers dei produttori, non vorrei che poi alla fine a forza di driver closed linux diventi una videata blu :read:
Rincalco la dose, quotando ancora Greg KH:

The Linux USB code has been rewritten at least three times. We've done this over time in order to handle things that we didn't originally need to handle, like high speed devices, and just because we learned the problems of our first design, and to fix bugs and security issues. Each time we made changes in our api, we updated all of the kernel drivers that used the apis, so nothing would break. And we deleted the old functions as they were no longer needed, and did things wrong. Because of this, Linux now has the fastest USB bus speeds when you test out all of the different operating systems. We max out the hardware as fast as it can go, and you can do this from simple userspace programs, no fancy kernel driver work is needed.

Now Windows has also rewritten their USB stack at least 3 times, with Vista, it might be 4 times, I haven't taken a look at it yet. But each time they did a rework, and added new functions and fixed up older ones, they had to keep the old api functions around, as they have taken the stance that they can not break backward compatibility due to their stable API viewpoint. They also don't have access to the code in all of the different drivers, so they can't fix them up. So now the Windows core has all 3 sets of API functions in it, as they can't delete things. That means they maintain the old functions, and have to keep them in memory all the time, and it takes up engineering time to handle all of this extra complexity. That's their business decision to do this, and that's fine, but with Linux, we didn't make that decision, and it helps us remain a lot smaller, more stable, and more secure.

k0nt3

03-08-2006, 11:47

In altre situazioni, potreste dirmi che avere del codice proprietario che gira in ring0 è un pericolo per la sicurezza e la stabilità, ma qui stiamo parlando di computer desktop, e di utenti che vogliono performance. Chi predilige la sicurezza e la stabilità, e non ha necessità del 3D, può benissimo usare il driver "vesa".

ma allora windows non ha insegnato niente? :rolleyes:

Naturalmente, ammetto di non essere sicuro che sia necessario implementare il driver nel kernel, ma se cosi non fosse, cosa costerebbe ad ati e nvidia farlo in userspace? perché non lo fanno? gli è stato proposto e hanno rifiutato (non è una domanda retorica)?

ati perchè sta usando l'80% delle sue risorse a scrivere i drivers per Vista.. nVidia credo stia facendo lo stesso visto che pare davvero molto complesso scrivere drivers video per vista :mbe:

Si, l'ho letto. Non è poi uno scenario così catastrofico, già con windows questo succede ... ma noi non vogliamo che linux finisca come windows, vero? Perfetto, allora lasciamo le cose come stanno (niente ABI), ma lasciamo liberi i produttori di sviluppare driver closed source, anche all'interno del kernel. Questo scenario è diverso da quello descritto, se non ho letto male.
questo per me è catastrifico! comunque è lo scenario che è descritto..
Giusto per buttare un pò di benzina sul fuoco...questo sarebbe sufficiente a risolvere definitivamente ogni problema con la GPL. ,ma sicuramente non farebbe contenti i "talebani" come me
sti talebani :doh: :D

ps. non hai risposto a [Mighty].. intendevi davvero TCPA? no perchè io non lo consideravo nemmeno.. sul mio pc non entra nessuna schifezza anche a costo di rimanere isolato dal resto del mondo :sofico:

ilsensine

03-08-2006, 12:52

Al Azif

03-08-2006, 14:36

Magari è un pochettino fuori tema: http://news.com.com/Novell+bans+proprietary+Linux+modules/2100-7344_3-6100659.html

Aslo

04-08-2006, 00:27

Hehe, lo sapevo che scatenavo il finimondo ... :D

Vediamo un po' di fare chiarezza sulla mia visione delle cose.

SITUAZIONE OTTIMALE: Tutti i driver open source.
SITUAZIONE INTERMEDIA 1: Driver in parte closed, in parte open, con codice nel kernel
viola la GPL, fa contenti gli utenti che vogliono driver performanti (@ilsensine, dopo ti rispondo ;))
SITUAZIONE INTERMEDIA 2: Driver in parte closed, in parte open, con codice in userspace
Non viola la GPL, i driver POTREBBERO (ok cosi?) essere più lenti.
SITUAZIONE PESSIMA: Driver completamente closed, ABI stabile come in windows.
Grossi problemi di manutenzione del software, e di sicurezza.

Le uniche due soluzioni praticabili sono quelle intermedie, e al momento i produttori hanno scelto per la prima, in nome delle performance, o per motivi tecnici che non conosciamo, ma non credo per una volonta diretta di violare la GPL.
Tra l'altro, la soluzione in userspace farebbe scontenti i produttori, scontenti gli utenti (se è vero che vanno peggio, da verificare), scontenti i "talebani", quindi non vedo il vantaggio ;)

Vediamo di rispondere ad alcune delle osservazioni che mi sono state fatte:
1) "non è un cavillo, è il fondamento del software libero": Forse non mi sono espresso chiaramente. Tra la GPL e la BSD esistono vie di mezzo, leggi LGPL, e certo il codice sotto LGPL non può essere usato a sbafo! Solo che è consentito l'uso delle API anche a programmi non GPL.
Poi, che Stallam la faccia e poi la rinneghi consigliando a tutti di non usarla ... :doh:
Comunque, secondo me la situazione attuale è il meglio che si può sperare, al momento: GPL (non LGPL), driver nel kernel proprietari (violano la GPL), sviluppatori del kernel che (per ora) chiudono un occhio.
Infatti, se il kernel fosse sotto LGPL, nessuno potrebbe opporsi alla situazione attuale. Se gli svluppatori decidessero di prendere una posizione decisa, rischierebbero di ritrovarsi senza driver da parte di ati e nvidia, scontentando gli utenti finali. Tuttavia, un giorno potranno forse cambiare condotta e "costringere" i produttori a rilasciare le specifiche, o direttamente i sorgenti dei driver.

2) Codice in ring0 più performante? Non necessariamente, dipende da quello che deve fare: se deve accedere all'hardware, deve necessariamente fare una richiesta al kernel, che la esegue (a ring0). In questo caso, C'E' un overhead dovuto al cambio di contesto, per quanto piccolo. Se il numero di chiamate è elevato, il codice può essere rallentato ... ok, forse mi sto spingendo troppo in cose che non conosco bene :mc:
Forse è possibile accedere al'hw direttamene in userspace, facendo prima una richiesta al kernel? chiedo lumi :stordita: Comunque è vero, non conosco bene la situazione, ma ati e nvidia la conoscono, e se inizialmente hanno scelto così ci sarà un motivo! O hanno motivo per violare deliberatamente la GPL?

@ilsensine: Si dai, dicci cosa intentevi dire, intendevi il TCPA?
@k0nt3: saremo isolati dal mondo almeno in due ;)

Aslo

04-08-2006, 00:29

Magari è un pochettino fuori tema: http://news.com.com/Novell+bans+proprietary+Linux+modules/2100-7344_3-6100659.html
Ma come, proprio novell che ha dato visibilità al desktop Xgl??? :boh:
Vabbe, staremo a vedere cosa succede ...

Tony Lio

04-08-2006, 08:23

La free software foundation ha richiesto la sospensione del progetto Kororaa (una distro live che include di default xgl) perchè include i driver video binari ati ed nvidia che VIOLANO la licenza gpl.
Secondo la licenza GPL i moduli binari non possono in alcun modo essere inclusi nel kernel.

Penso che questa decisione vada oltre i confini della follia.
Hanno fatto bene, nessuno ti vieta di usarli, ma il kernel è e deve rimanere 100% free!!!

ilsensine

04-08-2006, 09:47

Vediamo di rispondere ad alcune delle osservazioni che mi sono state fatte:
1) "non è un cavillo, è il fondamento del software libero": Forse non mi sono espresso chiaramente. Tra la GPL e la BSD esistono vie di mezzo, leggi LGPL, e certo il codice sotto LGPL non può essere usato a sbafo! Solo che è consentito l'uso delle API anche a programmi non GPL.
Allora per il _tuo_ codice scegli la LGPL, sei libero di farlo. Gli altri però hanno il diritto di scegliere anche la GPL, per il loro codice. E' il _loro_ codice, dannazione!
(e comunque anche la LGPL fornisce agli sviluppatori le stesse garanzie della GPL; cambiano solo le condizioni d'uso con le opere derivate).

Poi, che Stallam la faccia e poi la rinneghi consigliando a tutti di non usarla ... :doh:
Le libc (prodotte dalla stessa fsf!) sono LGPL.
Se rendessero le libc GPL, renderebbero nella pratica _impossibile_ l'esecuzione di qualsiasi programma proprietario. Eppure non lo fanno.

2) Codice in ring0 più performante? Non necessariamente, dipende da quello che deve fare: se deve accedere all'hardware, deve necessariamente fare una richiesta al kernel, che la esegue (a ring0).
No,no e no! Non è vero!.

Gica78R

04-08-2006, 10:27

http://punto-informatico.it/p.aspx?id=1598963&r=PI

Aslo

05-08-2006, 17:20

Le libc (prodotte dalla stessa fsf!) sono LGPL.
Se rendessero le libc GPL, renderebbero nella pratica _impossibile_ l'esecuzione di qualsiasi programma proprietario. Eppure non lo fanno.

http://www.gnu.org/licenses/why-not-lgpl.html
Posto il link in questione, per il beneficio di chi non conoscesse la vicenda.

2) Codice in ring0 più performante? Non necessariamente, dipende da quello che deve fare: se deve accedere all'hardware, deve necessariamente fare una richiesta al kernel, che la esegue (a ring0).

No,no e no! Non è vero!.
Ok, ho già ammesso la mia mezza ignoranza in merito, ora mi vado a documentare sul serio, sulle API del kernel, sull'accesso diretto all'hardware con linux, sull'implementazione di driver in userspace. Certo che un piccolo aiutino (anche un link a un documento che prova cio che dici) non guasterebbe ...

Aslo

05-08-2006, 20:34

Ok, ho già ammesso la mia mezza ignoranza in merito, ora mi vado a documentare sul serio, sulle API del kernel, sull'accesso diretto all'hardware con linux, sull'implementazione di driver in userspace. Certo che un piccolo aiutino (anche un link a un documento che prova cio che dici) non guasterebbe ...
Ho dato una leggera occhiata in giro, e effettivamente, è possibile accedere direttamente all'hardware da userspace (come d'altraparte sospettavo già nel mio penultimo post).
Ci sono però ancora dei problemi irrisolti, come per esempio la temporizzazione e la gestione degli IRQ (o sono stati risolti? le informazioni che ho trovato sono del 2004).

Insomma, linux nonostante tutto è ancora un kernel monilitico, non un microkernel. Qualcuno, probabilmente, vuole che resti cosi.

Artemisyu

06-08-2006, 03:05

Insomma, linux nonostante tutto è ancora un kernel monilitico, non un microkernel. Qualcuno, probabilmente, vuole che resti cosi.

E menomale, aggiungerei.
Ci sono grandi detrattori nel mondo del concetto di microkernel. e hanno le loro ottime ragioni.
Il microkernel è il tipico oggetto che teoricamente ha le potenzialità di essere la panacea di tutti i mali, ma che all'atto pratico non funziona neanche per sbaglio.

Infatti i microkernel esistenti sono o fortemente ibridi, o se microkernel puri, come Mach, sono delle porcherie pesanti e ingestibili che è dura fare di peggio con altre architetture.

ekerazha

06-08-2006, 11:13

k0nt3

06-08-2006, 11:27

E menomale, aggiungerei.
Ci sono grandi detrattori nel mondo del concetto di microkernel. e hanno le loro ottime ragioni.
Il microkernel è il tipico oggetto che teoricamente ha le potenzialità di essere la panacea di tutti i mali, ma che all'atto pratico non funziona neanche per sbaglio.

Infatti i microkernel esistenti sono o fortemente ibridi, o se microkernel puri, come Mach, sono delle porcherie pesanti e ingestibili che è dura fare di peggio con altre architetture.
i microkernel ibridi non li definirei nemmeno microkernel, IMHO è solo un nome che fa cool ma poco di concreto.. per il fatto del kernel di linux senza dubbio all'epoca è stata la scelta migliore, infatti non sarebbe arrivato a questo punto con un microkernel che è molto più difficile da implementare, inoltre con il fatto che il kernel è modulare alcuni vantaggi a livello di manutenzione tipici dei microkernel si sono comunque ottenuti.
comunque ora i microkernel stanno iniziando a dimostrare le loro potenzialità.. ci vorranno ancora anni, ma i risultati sono incoraggianti (come questo (http://l4ka.org/projects/pistachio/) )

k0nt3

06-08-2006, 11:28

MrAsd

06-08-2006, 11:32

Concordo sul fatto che la GNU/GPL v2 sia una licenza ben poco costruttiva (speriamo per la v3).

La V3 e' piu' restrittiva della v2 :doh:

ekerazha

06-08-2006, 11:38

la V2 non ha niente che non va (parlo per gli scopi degli sviluppatori del kernel), è la V3 che crea problemi :)
Non è questione di cose che non vanno, è questione di licenza poco costruttiva ed il fondamentalismo francamente ridicolo della GNU/GPL è sotto agli occhi di tutti nonchè oggetto di questa discussione... che poi agli sviluppatori del kernel Linux possa andare bene così non lo metto in dubbio ed è per questo che per quanto mi riguarda Linux è sparito da tutte le mie macchine ;)

ekerazha

06-08-2006, 11:39

La V3 e' piu' restrittiva della v2 :doh:
Almeno la v3 esibisce una certa apertura rispetto alle altre licenze opensource... e questa è una delle cose più importanti.

k0nt3

06-08-2006, 12:01

Non è questione di cose che non vanno, è questione di licenza poco costruttiva ed il fondamentalismo francamente ridicolo della GNU/GPL è sotto agli occhi di tutti nonchè oggetto di questa discussione... che poi agli sviluppatori del kernel Linux possa andare bene così non lo metto in dubbio ed è per questo che per quanto mi riguarda Linux è sparito da tutte le mie macchine ;)
manca solo IMHO davanti.. non puoi dire che è ridicolo, la V2 non è fondamentalista e lo dimostra il fatto che ai kernel developer va bene e loro non sono fondamentalisti. se poi te vuoi qualcos'altro nessuno te lo vieta, ma non puoi pretendere che tutti la pensino come te

ekerazha

06-08-2006, 13:15

manca solo IMHO davanti.. non puoi dire che è ridicolo, la V2 non è fondamentalista e lo dimostra il fatto che ai kernel developer va bene e loro non sono fondamentalisti. se poi te vuoi qualcos'altro nessuno te lo vieta, ma non puoi pretendere che tutti la pensino come te
Possibile... ora però dammi la definizione di una licenza opensource che per restare "fedele ai propri principi" rimane chiusa rispetto ad altre licenze opensource (ad esempio) anche quando questo va contro gli interessi della comunità. Io chiamo questa una licenza opensource non costruttiva... poi quello che va bene agli sviluppatori del kernel Linux è una loro scelta... più o meno opinabile e più o meno fondamentalista.

ilsensine

21-08-2006, 09:18

http://www.gnu.org/licenses/why-not-lgpl.html
Posto il link in questione, per il beneficio di chi non conoscesse la vicenda.
Guarda i fatti, oltre le parole.
Le librerie gpl pure sono la grande minoranza.

Ok, ho già ammesso la mia mezza ignoranza in merito, ora mi vado a documentare sul serio, sulle API del kernel, sull'accesso diretto all'hardware con linux, sull'implementazione di driver in userspace. Certo che un piccolo aiutino (anche un link a un documento che prova cio che dici) non guasterebbe ...
Non c'è un link preciso, ma puoi dare una occhiata a quello che fa X: confronta quanto riportato in /proc/`pidof X`/maps con quanto riportato da lspci -v. Viene usato il device generico /dev/mem per accedere alla iomem della scheda video.
Quello che assolutamente non si può fare in userspace è intercettare un irq. Non senza un piccolo aiuto da parte di un driver.

eclissi83

21-08-2006, 16:28

Concordo sul fatto che la GNU/GPL v2 sia una licenza ben poco costruttiva (speriamo per la v3). La BSD come ha fatto notare qualcuno si presta ad altre cose poco carine... imho la licenza opensource attualmente più costruttiva è probabilmente la CDDL (quella di OpenSolaris ;) ).
Da quello che ho capito la CDDL rende possibile il miscuglio tra software con licenze aperte/libere con quelle commerciali, ovvero si puo' integrare opensolaris con altro software scritto da se' (o da altri che usano questa licenza) e farne un prodotto commerciale.
A me sembra molto simile alla licenza BSD che permette addirittura di chiudere totalmente il codice (evviva la liberta').
Non mi pare che la GPL vieti la vendita dei software distribuiti sotto questa licenza; inoltre la GPL e' una garanzia per gli sviluppatori che sono sicuri di non trovare il proprio codice in software commerciali, cosi' come e' accaduto, per esempio, con lo stack TCP di freebsd che e' in Windows 2000 (o XP non ricordo bene).

ekerazha

21-08-2006, 16:53

Da quello che ho capito la CDDL rende possibile il miscuglio tra software con licenze aperte/libere con quelle commerciali, ovvero si puo' integrare opensolaris con altro software scritto da se' (o da altri che usano questa licenza) e farne un prodotto commerciale.
A me sembra molto simile alla licenza BSD che permette addirittura di chiudere totalmente il codice (evviva la liberta').
Non mi pare che la GPL vieti la vendita dei software distribuiti sotto questa licenza; inoltre la GPL e' una garanzia per gli sviluppatori che sono sicuri di non trovare il proprio codice in software commerciali, cosi' come e' accaduto, per esempio, con lo stack TCP di freebsd che e' in Windows 2000 (o XP non ricordo bene).
Il fatto è che se prendi un software CDDL e ne modifichi i file, devi rilasciare i file modificati sotto CDDL. In questo modo se qualcuno facesse anche un software commerciale utilizzando sia codice proprietario che CDDL, le modifiche ed i miglioramenti eventualmente apportati al codice CDDL originario dovrebbero essere restituiti alla comunità... in questo modo la comunità ne trae comunque vantaggio. La GPL invece è molto più restrittiva (e tra l'altro restrittiva non solo rispetto alle licenze proprietarie, ma anche rispetto ad altre licenze opensource) e non permetterebbe questa miscela... in questo modo si precludono al progetto potenziali fonti di crescita (es. qualcuno vuole fare un software utilizzando sia codice CDDL ma mantenendo alcune parti proprietarie... come già detto il codice proprietario rimane tranquillamente privato se è questo che desidera, ma eventuali miglioramenti apportati al codice CDDL vengono restituiti alla comunità). La CDDL è una licenza più elastica, che offre più costruttive possibilità di crescita e maggiore libertà rispetto alla GPL. Nessun problema di ritrovare il mio codice in prodotti commerciali quando le migliorie eventualmente apportate ritornano comunque al mittente e restano libere ;)

eclissi83

21-08-2006, 17:49

Il fatto è che se prendi un software CDDL e ne modifichi i file, devi rilasciare i file modificati sotto CDDL. In questo modo se qualcuno facesse anche un software commerciale utilizzando sia codice proprietario che CDDL, le modifiche ed i miglioramenti eventualmente apportati al codice CDDL originario dovrebbero essere restituiti alla comunità... in questo modo la comunità ne trae comunque vantaggio. La GPL invece è molto più restrittiva (e tra l'altro restrittiva non solo rispetto alle licenze proprietarie, ma anche rispetto ad altre licenze opensource) e non permetterebbe questa miscela... in questo modo si precludono al progetto potenziali fonti di crescita (es. qualcuno vuole fare un software utilizzando sia codice CDDL ma mantenendo alcune parti proprietarie... come già detto il codice proprietario rimane tranquillamente privato se è questo che desidera, ma eventuali miglioramenti apportati al codice CDDL vengono restituiti alla comunità). La CDDL è una licenza più elastica, che offre più costruttive possibilità di crescita e maggiore libertà rispetto alla GPL. Nessun problema di ritrovare il mio codice in prodotti commerciali quando le migliorie eventualmente apportate ritornano comunque al mittente e restano libere ;)

da quello che dici la CDDL e' virale come la GPL, permettendo l'inclusione di software closed. se pero' creo un mio prodotto commerciale e prendo un software rilasciato in CDDL a cui aggiungo una parte closed senza modificare nulla del codice originario io alla comunita' non do' niente.
cosa acccade se io prendo lo stack tcp di opensolaris e lo metto senza effettuare modifiche nel mio SO closed? dovrei rilasciare quella porzione di codice come CDDL oppure posso inserirlo tranquillamente nel mio codice?
a me questa non sembra crescita.

ilsensine

21-08-2006, 17:53

da quello che dici la CDDL e' virale come la GPL, permettendo l'inclusione di software closed. se pero' creo un mio prodotto commerciale e prendo un software rilasciato in CDDL a cui aggiungo una parte closed senza modificare nulla del codice originario io alla comunita' non do' niente.
cosa acccade se io prendo lo stack tcp di opensolaris e lo metto senza effettuare modifiche nel mio SO closed? dovrei rilasciare quella porzione di codice come CDDL oppure posso inserirlo tranquillamente nel mio codice?
a me questa non sembra crescita.
E' simile alla LGPL, nulla di nuovo.
Non è compatibile con la GPL per altri motivi (da vedere se sarà compatibile con la GPLv3):
http://www.fsf.org/licensing/licenses/index_html#GPLIncompatibleLicenses

k0nt3

21-08-2006, 17:59

ma con una CDDL non si rischia lo scenario catastrofico di qualche pagina fa con l'inclusione di moduli proprietari nel kernel ecc... ?

ilsensine

21-08-2006, 18:03

Sì

ekerazha

21-08-2006, 18:11

da quello che dici la CDDL e' virale come la GPL, permettendo l'inclusione di software closed.
Proprio per questo non è "virale" quanto la GPL, poichè permette di essere utilizzata in armonia con altre licenze.

Certo... un po' di "viralità" rimane a tutela della licenza stessa, altrimenti se si potesse modificare la licenza a proprio piacimento, essa diventerebbe facilmente aggirabile. Al limite si potrebbe calare ulteriormente il tasso di "viralità" modificando le clausole esistenti in modo simile a quanto presente nella APL (Apache Public License), ovvero:

You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License.

In questo modo non restringerei la ridistribuzione alla sola CDDL, ma a licenze che contengano almeno le condizioni presenti nella CDDL ;) Direi che più di così non si potrebbe fare... magari potremmo suggerire a Sun la modifica :D

se pero' creo un mio prodotto commerciale e prendo un software rilasciato in CDDL a cui aggiungo una parte closed senza modificare nulla del codice originario io alla comunita' non do' niente.
cosa acccade se io prendo lo stack tcp di opensolaris e lo metto senza effettuare modifiche nel mio SO closed? dovrei rilasciare quella porzione di codice come CDDL oppure posso inserirlo tranquillamente nel mio codice?
a me questa non sembra crescita.

Vero... però oltre a non dare niente alla comunità non le toglieresti nemmeno niente. E' una possibilità più che accettabile se teniamo conto delle restanti potenzialità. La comunità ha solo da guadagnarci.

ekerazha

21-08-2006, 18:13

E' simile alla LGPL, nulla di nuovo.

Non conosco il tuo concetto di simile, ma a me sembrano abbastanza diverse... a cominciare dal fatto che la LGPL tratta di linking statico o dinamico alle librerie mentre la CDDL è una licenza file-based.

ilsensine

21-08-2006, 18:23

Non conosco il tuo concetto di simile, ma a me sembrano abbastanza diverse...
Intendevo: simile per ciò che riguarda la tolleranza con moduli con altre licenze
a cominciare dal fatto che la LGPL tratta di linking statico o dinamico alle librerie mentre la CDDL è una licenza file-based.
No.
La LGPL parla di librerie, regolandone non solo il linking nelle varie forme, ma anche la distribuzione del codice sorgente, ecc.

ekerazha

21-08-2006, 18:25

ma con una CDDL non si rischia lo scenario catastrofico di qualche pagina fa con l'inclusione di moduli proprietari nel kernel ecc... ?
L'importante è utilizzare sapientemente la libertà che viene concessa. Se non si è in grado di utilizzarla sapientemente allora forse limitare la libertà può risultare anche un bene in certi casi ;) In ogni caso la libertà di ciascuno non va ad intaccare quella altrui... quindi se qualcuno volesse rilasciare un kernel CDDL con annessi driver proprietari è una sua libera scelta, come qualcun'altro potrebbe fare la libera scelta di non farlo... come qualcun'altro potrebbe fare la libera scelta di includere driver opensource (con licenza opensource costruttiva chiaramente) non CDDL ;)

k0nt3

21-08-2006, 18:29

L'importante è utilizzare sapientemente la libertà che viene concessa. Se non si è in grado di utilizzarla sapientemente allora forse limitare la libertà può risultare anche un bene in certi casi ;) In ogni caso la libertà di ciascuno non va ad intaccare quella altrui... quindi se qualcuno volesse rilasciare un kernel CDDL con annessi driver proprietari è una sua libera scelta, come qualcun'altro potrebbe fare la libera scelta di non farlo... come qualcun'altro potrebbe fare la libera scelta di includere driver opensource (con licenza opensource costruttiva chiaramente) non CDDL ;)
c'è qualcuno che garantisce che tutti quelli che vogliono prendere il tuo codice rilasciato sotto CDDL per farne una versione propria abbiano buon senso? :confused:

ekerazha

21-08-2006, 18:30

Intendevo: simile per ciò che riguarda la tolleranza con moduli con altre licenze

Essendo strettamente file-based la CDDL si spinge oltre a quanto non faccia la LGPL.

No.
La LGPL parla di librerie, regolandone non solo il linking nelle varie forme, ma anche la distribuzione del codice sorgente, ecc.
Proprio per questo ho detto "a cominciare", è banale che regoli anche altre cose... ma come già detto rimane ben distinta da una licenza strettamete file-based come la CDDL.

ekerazha

21-08-2006, 18:33

c'è qualcuno che garantisce che tutti quelli che vogliono prendere il tuo codice rilasciato sotto CDDL per farne una versione propria abbiano buon senso? :confused:
Come già detto la libertà altrui non influisce sulla propria in questo caso... lui può prendere il mio codice e friggerlo nella cipolla :D io posso rimanere con il mio codice. Non è che il mio va buttato via e si tiene quello fritto ;) Si crea un fork, come può accadere in molte licenze opensource.

k0nt3

21-08-2006, 18:38

Come già detto la libertà altrui non influisce sulla propria in questo caso... lui può prendere il mio codice e friggerlo nella cipolla :D io posso rimanere con il mio codice. Non è che il mio va buttato via e si tiene quello fritto ;) Si crea un fork, come può accadere in molte licenze opensource.
secondo me non hai letto bene lo scenario di cui si parlava addietro in questo thread... :confused:
quella non è libertà.. si chiama babele ;)

http://www.hwupgrade.it/forum/showpost.php?p=13251680&postcount=61

ekerazha

21-08-2006, 18:46

secondo me non hai letto bene lo scenario di cui si parlava addietro in questo thread... :confused:
quella non è libertà.. si chiama babele ;)

http://www.hwupgrade.it/forum/showpost.php?p=13251680&postcount=61
Si chiama libertà di scelta. Ben più grave la situazione di una licenza che limita gravemente ed in modo scarsamente giustificabile la libertà ;)

k0nt3

21-08-2006, 18:51

Si chiama libertà di scelta. Ben più grave la situazione di una licenza che limita gravemente ed in modo scarsamente giustificabile la libertà ;)
comincio a pensare che il tuo modello di libertà è l'anarchia

ekerazha

21-08-2006, 18:57

comincio a pensare che il tuo modello di libertà è l'anarchia
E' ben differente... anarchia è assenza di regole, qui le regole ci sono e ad esempio possono chiamarsi CDDL.

Inoltre il link che hai postato sopra presenta uno scenario catastrofista non molto ponderato e che è possibile interrompere prima che inizi, ovvero "i mantainer non accettano i moduli binari", ovvero libertà di scelta.

Poi potremmo discutere ore sul perchè con Linux i driver siano dentro al kernel... la risposta potrebbe essere che c'è a chi piace la monoliticità, ma questa è un'altra storia.

k0nt3

21-08-2006, 19:10

E' ben differente... anarchia è assenza di regole, qui le regole ci sono e ad esempio possono chiamarsi CDDL.
l'assenza di regole viene quando ognuno fa quel che gli pare

Inoltre il link che hai postato sopra presenta uno scenario catastrofista non molto ponderato e che è possibile interrompere prima che inizi, ovvero "i mantainer non accettano i moduli binari", ovvero libertà di scelta.
c'è scritto che è catastrofista, però è possibile. con la CDDL i mantainer non sono tutelati dall'inclusione di moduli proprietari nel kernel e non possono vietarlo

Poi potremmo discutere ore sul perchè con Linux i driver siano dentro al kernel... la risposta potrebbe essere che c'è a chi piace la monoliticità, ma questa è un'altra storia.
monoliticità modulare :read:

ekerazha

21-08-2006, 19:31

l'assenza di regole viene quando ognuno fa quel che gli pare
Infatti qui ognuno non fa quel che gli pare, qui si rispetta una licenza (es. la CDDL) e meglio se una licenza costruttiva ;)

c'è scritto che è catastrofista, però è possibile. con la CDDL i mantainer non sono tutelati dall'inclusione di moduli proprietari nel kernel e non possono vietarlo

Ma che stai dicendo? :rolleyes: I mantainer possono decidere benissimo cosa includere e cosa non includere, hanno la libertà di fare quello che meglio credono. Al limite qualcuno potrebbe creare un progetto parallelo... come potrei creare anche un progetto parallelo a Linux se volessi ;)

monoliticità modulare :read:
Tra modulare o che "può caricare moduli" c'è una bella differenza ;)

k0nt3

21-08-2006, 19:35

Ma che stai dicendo? :rolleyes: I mantainer possono decidere benissimo cosa includere e cosa non includere, hanno la libertà di fare quello che meglio credono. Al limite qualcuno potrebbe creare un progetto parallelo... come potrei creare anche un progetto parallelo a Linux se volessi ;)

con linux puoi creare un progetto parallelo ma non ci puoi mettere dentro moduli proprietari. è appunto questo il nocciolo del discorso

Tra modulare o che "può caricare moduli" c'è una bella differenza ;)
man insmod

ekerazha

21-08-2006, 19:40

con linux puoi creare un progetto parallelo ma non ci puoi mettere dentro moduli proprietari. è appunto questo il nocciolo del discorso

Il nocciolo del discorso in realtà è un po' più a monte. Il problema dei driver proprietari presentato in quello scenario riguardava principalmente la difficoltà di gestione di varie interfacce dal momento che i driver proprietari non sono modificabili se non da chi li produce (per adattarli eventualmente a modifiche apportate ad interfacce). Se creassi un progetto parallelo a Linux potrei comunque modificare queste interfacce rispetto a quelle presenti nel "Linux ufficiale" quindi la conseguenza sarebbe la medesima.

man insmod

Ripeto: tra modulare o che "può caricare moduli" c'è una bella differenza

;)

sirus

21-08-2006, 19:44

IMHO è giusto che tutte le distribuzioni rispettino le licenze (altrimenti perché scrivere delle licenze?) quindi IMHO quanto è stato proposto dalla FSF è corretto (anche se non era suo compito ma era compito dei kernel developer). :)
La possibilità di installare driver in formato binario deve essere lasciata al solo utente. Questo mal si coniuga con il progetto Koroora che avendo come peculiarità di base XGL - che richiede i driver con supporto 3D che esistono solo in "formato" chiuso - non può rispettare la GPL e quindi deve chiudere i battenti.

Non prendetemi per fondamentalista perché molti sanno come la penso riguardo il free software e l'open source quindi ritengo di poter essere l'ultimo tacciabile con un "titolo" simile. :p

PS: mi pare che la GPL3 sia addirittura più restrittiva da questo punto di vista imponendo l'impossibilità di abbinare free software e closed software se non erro (ma potrei sbagliarmi), in questo caso non sono affatto d'accordo perché si toglierebbero le ali ad ottimi progetti come XGL che deve fino a prova contraria ringraziare l'esistenza dei driver closed con supporto 3D.

Concordo con tutti quelli che dicono che ci sono molte vie per evitare questo problema (inserendo un modulo open nel kernel ed interfacciandosi con quello dallo user space) tuttavia nessuno può obbligare nessun produttore a percorrere questa strada e pensare di "chiuderasi" verso alcuni produttori in particolare vorrebbe dire la fine dell'espansione. :)

k0nt3

21-08-2006, 20:25

Il nocciolo del discorso in realtà è un po' più a monte. Il problema dei driver proprietari presentato in quello scenario riguardava principalmente la difficoltà di gestione di varie interfacce dal momento che i driver proprietari non sono modificabili se non da chi li produce (per adattarli eventualmente a modifiche apportate ad interfacce). Se creassi un progetto parallelo a Linux potrei comunque modificare queste interfacce rispetto a quelle presenti nel "Linux ufficiale" quindi la conseguenza sarebbe la medesima.
no hai frainteso nocciolo del discorso.. il problema sono i moduli proprietari e mi sembra spiegato molto bene da tutti i link linkati da ilsensine dall'inizio del thread

Ripeto: tra modulare o che "può caricare moduli" c'è una bella differenza

;)
la differenza ci sarà tra microkernel e può caricare moduli, ma linux è modulare.

ekerazha

21-08-2006, 20:38

no hai frainteso nocciolo del discorso.. il problema sono i moduli proprietari e mi sembra spiegato molto bene da tutti i link linkati da ilsensine dall'inizio del thread

No... non sono i moduli proprietari in sè il problema, bensì quello che potrebbero comportare (ma come già detto è una questione di scelta), come si evince chiaramente dal post che tu stesso hai linkato (ed in particolare viene del tutto esplicitato nel punto del "21 agosto").

la differenza ci sarà tra microkernel e può caricare moduli, ma linux è modulare.
Linux può caricare moduli ;) Visto che hai tirato fuori i microkernel, un microkernel/nanokernel è sicuramente più vicino all'ideale di modularità rispetto ad un kernel monolitico come Linux (che carica moduli), questo è poco ma sicuro.

k0nt3

21-08-2006, 20:55

No... non sono i moduli proprietari in sè il problema, bensì quello che potrebbero comportare (ma come già detto è una questione di scelta), come si evince chiaramente dal post che tu stesso hai linkato (ed in particolare viene del tutto esplicitato nel punto del "21 agosto").

appunto il 21 agosto è il problema! leggi qua http://www.hwupgrade.it/forum/showpost.php?p=13310476&postcount=101 e capirai la differenza tra drivers open e closed

Linux può caricare moduli ;) Visto che hai tirato fuori i microkernel, un microkernel/nanokernel è sicuramente più vicino all'ideale di modularità rispetto ad un kernel monolitico come Linux (che carica moduli), questo è poco ma sicuro.
se guardi il codice di linux capisci che è modulare. se poi non è un microkernel è un altro discorso

ekerazha

21-08-2006, 22:22

appunto il 21 agosto è il problema! leggi qua http://www.hwupgrade.it/forum/showpost.php?p=13310476&postcount=101 e capirai la differenza tra drivers open e closed

Appunto... ma il problema come già detto non sono i driver "closed" in sè ;) è un problema di eventuale manutenzione/modifica delle interfacce quando si ha a che fare con driver closed. Ma come già detto il "problema" delle interfacce potresti avercelo comunque in un eventuale fork di Linux che ne modificasse il funzionamento (tanto quanto potresti avercelo con un fork di un kernel CDDL... ed era proprio questa la tua obiezione... ma come spiegato puoi arrivare in ogni caso alle medesime conseguenze ;) ).

se guardi il codice di linux capisci che è modulare. se poi non è un microkernel è un altro discorso
Lo conosco discretamente il codice di Linux e mi sembra una modularità da quattro soldi. Un kernel monolitico non può essere completamente modulare per definizione... il fatto che possa caricare moduli non lo rende in sè sufficientemente modulare e degno di tale appellativo.

k0nt3

21-08-2006, 22:39

Appunto... ma il problema come già detto non sono i driver "closed" in sè ;) è un problema di eventuale manutenzione/modifica delle interfacce quando si ha a che fare con driver closed. Ma come già detto il "problema" delle interfacce potresti avercelo comunque in un eventuale fork di Linux che ne modificasse il funzionamento (tanto quanto potresti avercelo con un fork di un kernel CDDL... ed era proprio questa la tua obiezione... ma come spiegato puoi arrivare in ogni caso alle medesime conseguenze ;) ).
mmm http://www.hwupgrade.it/forum/showpost.php?p=13310476&postcount=101 cosa non ti è chiaro? hanno riscritto 3 volte daccapo lo stack usb e non hanno avuto nessun problema. perchè? semplice è tutto open source e basta una ricompilata

Lo conosco discretamente il codice di Linux e mi sembra una modularità da quattro soldi. Un kernel monolitico non può essere completamente modulare per definizione... il fatto che possa caricare moduli non lo rende in sè sufficientemente modulare e degno di tale appellativo.
sei tu che stabilisci se è degno di essere chiamato modulare o no?

ekerazha

21-08-2006, 23:33

mmm http://www.hwupgrade.it/forum/showpost.php?p=13310476&postcount=101 cosa non ti è chiaro? hanno riscritto 3 volte daccapo lo stack usb e non hanno avuto nessun problema. perchè? semplice è tutto open source e basta una ricompilata

Mi è chiaro tutto... tu piuttosto, perchè ti ostini a non capire che è un problema di manutenzione delle interfacce e non un problema insito nei driver proprietari? Eppure mi sembra abbastanza autoesplicativo:

Each time we made changes in our api, we updated all of the kernel drivers that used the apis, so nothing would break.

Basterebbe che il produttore del driver closed fosse solerte negli aggiornamenti del driver nel caso venissero modificate le interfacce. In ogni caso come ho già spiegato le stesse conseguenze puoi averle anche senza la questione dei driver proprietari ;)

sei tu che stabilisci se è degno di essere chiamato modulare o no?
Chiaramente è una mia opinione... ti dico solo che se fosse realmente modulare non ci sarebbero le complicazioni di cui stiamo discutendo sulla compatibilità tra driver e kernel ;)

k0nt3

22-08-2006, 00:01

Mi è chiaro tutto... tu piuttosto, perchè ti ostini a non capire che è un problema di manutenzione delle interfacce e non un problema insito nei driver proprietari? Eppure mi sembra abbastanza autoesplicativo:

appunto è abbastanza autoesplicativo.. non capisco perchè non ti entra nella zucca. perciò vediamo di chiarire in breve:
se rilasciassero linux con licenza CDDL i produttori di hardware tempesterebbero il kernel di moduli proprietari e ovviamente le distro si adeguerebbero (tranne alcune) per creare meno problemi all'utente finale. poi arriva il 21 agosto e cambiare il design di sysfs significherebbe rompere la compatibilità con tutti questi drivers, per aspettare versioni corrette di tutti questi drivers bisogna aspettare mesi (magari qualche driver non verrà mai patchato rendendolo inutilizzabile) e poi bisogna anche diffondere queste patch perchè la vulnerabilità è rischiosa... il risultato non mi sembra così bello.
al contrario se ci fossero solo drivers open source si potrebbe cambiare tranquillamente tutte le interfaccie che si vogliono, modificare i drivers in maniera adeguata e ricompilare. è quello che è sempre stato fatto su linux e a giudicare dallo stack usb sembra che produca ottimi risultati

Basterebbe che il produttore del driver closed fosse solerte negli aggiornamenti del driver nel caso venissero modificate le interfacce. In ogni caso come ho già spiegato le stesse conseguenze puoi averle anche senza la questione dei driver proprietari ;)

:confused:

Chiaramente è una mia opinione... ti dico solo che se fosse realmente modulare non ci sarebbero le complicazioni di cui stiamo discutendo sulla compatibilità tra driver e kernel ;)
se fosse un microkernel vorrai dire

ps. il 21 agosto era ieri :asd:

ekerazha

22-08-2006, 00:24

appunto è abbastanza autoesplicativo.. non capisco perchè non ti entra nella zucca. perciò vediamo di chiarire in breve:
se rilasciassero linux con licenza CDDL i produttori di hardware tempesterebbero il kernel di moduli proprietari e ovviamente le distro si adeguerebbero (tranne alcune) per creare meno problemi all'utente finale. poi arriva il 21 agosto e cambiare il design di sysfs significherebbe rompere la compatibilità con tutti questi drivers, per aspettare versioni corrette di tutti questi drivers bisogna aspettare mesi (magari qualche driver non verrà mai patchato rendendolo inutilizzabile) e poi bisogna anche diffondere queste patch perchè la vulnerabilità è rischiosa... il risultato non mi sembra così bello.
al contrario se ci fossero solo drivers open source si potrebbe cambiare tranquillamente tutte le interfaccie che si vogliono, modificare i drivers in maniera adeguata e ricompilare. è quello che è sempre stato fatto su linux e a giudicare dallo stack usb sembra che produca ottimi risultati

Forse spiegandotelo schematicamente ti risulterà di più semplice comprensione:
#1: se Linux fosse CDDL i mantainer del kernel avrebbero libertà di scelta.
#2: se Linux fosse CDDL qualcuno potrebbe fare una distribuzione con un kernel che integri driver proprietari e che magari si discosta da quello ufficiale, tanto quanto con la GPL attuale qualcuno può fare una distribuzione con un kernel "Linux" modificato rispetto a quello ufficiale.
#3: il fatto che un produttore non sia solerte negli aggiornamenti non è un problema strettamente intrinseco ai driver closed source, poichè come già detto potrebbero esserci produttori che ti sfornano subito il driver aggiornato ;)
#4: devi guardare in faccia la realtà e capire che molti produttori non rilasceranno mai driver open, che a volte alcuni driver open non sono all'altezza di quelli proprietari (vedi driver nVidia) o non esistono proprio... e alla fine chi ci rimette non è il produttore bensì l'utente finale.
#5: nessuno mette in dubbio che se fosse tutto open sarebbe più semplice, ma come già spiegato devi guardare in faccia la realtà ed inoltre questo ha ben poco a che fare (nonostante tu stia tentando di far passare il messaggio contrario) con licenze come la CDDL che al contrario della GPL lascia libertà e non controproducenti restrizioni.

Ora è più chiaro?

:confused:

:read:

se fosse un microkernel vorrai dire
Come già detto un microkernel è per definizione sicuramente più modulare ;)

k0nt3

22-08-2006, 00:40

Forse spiegandotelo schematicamente ti risulterà di più semplice comprensione:
per semplificare la comprensione tu avresti bisogno di un teatrino con le marionette :asd:

#1: se Linux fosse CDDL i mantainer del kernel avrebbero libertà di scelta.

hanno già libertà di scelta. non sono costretti a tenere la gpl eppure la tengono

#2: se Linux fosse CDDL qualcuno potrebbe fare una distribuzione con un kernel che integri driver proprietari e che magari si discosta da quello ufficiale, tanto quanto con la GPL attuale qualcuno può fare una distribuzione con un kernel "Linux" modificato rispetto a quello ufficiale.

sarà modificato quanto vuoi ma al contrario di linux-CDDL linux-GPL NON potrà contenere drivers closed source (anche perchè è l'argomento di questo thread)

#3: il fatto che un produttore non sia solerte negli aggiornamenti non è un problema strettamente intrinseco ai driver closed source, poichè come già detto potrebbero esserci produttori che ti sfornano subito il driver aggiornato ;)

voglio vedere come escono in fretta i drivers di 3dfx :asd: e se c'è una vulnerabilità pericolosa? pazienza.. qualche pc non verrà mai patchato

ps. 3dfx è solo un esempio.. ci sono anche produttori ancora attivi che sono restii a rilasciare aggiornamenti dei drivers. oppure nel futuro ci possono essere altri 3dfx

#4: devi guardare in faccia la realtà e capire che molti produttori non rilasceranno mai driver open, che a volte alcuni driver open non sono all'altezza di quelli proprietari (vedi driver nVidia) o non esistono proprio... e alla fine chi ci rimette non è il produttore bensì l'utente finale.

se rilasciassero le specifiche comincierebbero a combattere ad armi meno impari. e ti credo i drivers di nVidia sono meglio.. solo loro sanno com'è fatta sta benedetta scheda. poi il driver di ATI è l'unico che mi causa dei crash saltuariamente facendomi pensare per qualche secondo di essere su windows.. per fortuna si riavvia solo X perchè linux è un grosso pezzo di pietra monolitico (mentre su windows sarebbe schermata blu).
inoltre altra lettura per te http://www.hwupgrade.it/forum/showthread.php?t=989040

#5: nessuno mette in dubbio che se fosse tutto open sarebbe più semplice, ma come già spiegato devi guardare in faccia la realtà ed inoltre questo ha ben poco a che fare (nonostante tu stia tentando di far passare il messaggio contrario) con licenze come la CDDL che al contrario della GPL lascia libertà e non controproducenti restrizioni.

:confused: non capisco cosa significhi... eppure mi sembra chiaro che se linux venisse rilasciato sotto CDDL sarebbe un disastro

Ora è più chiaro?

:read:

Come già detto un microkernel è per definizione sicuramente più modulare ;)
ah adesso correggi il tiro! sei passato da "linux non è degno di chiamarsi modulare" a "è meno modulare" :rolleyes: dai la prossima è quella buona

eclissi83

22-08-2006, 01:00

Forse spiegandotelo schematicamente ti risulterà di più semplice comprensione:
#1: se Linux fosse CDDL i mantainer del kernel avrebbero libertà di scelta.

credo che la liberta' di scelta l'abbiano applicata quando hanno deciso per la GPL

#4: devi guardare in faccia la realtà e capire che molti produttori non rilasceranno mai driver open, che a volte alcuni driver open non sono all'altezza di quelli proprietari (vedi driver nVidia) o non esistono proprio... e alla fine chi ci rimette non è il produttore bensì l'utente finale.

guarda che l'utente ci rimette anche coi driver closed... pensa a chi come me ha gnu/linux su powerpc: non ho i driver ati e nemmeno quelli nvidia. toh, che bello il mondo dei driver closed. l'universo non e' fatto di soli x86 e l'unica via per avere un sistema operativo realmente multipiattaforma e' il software aperto.

ekerazha

22-08-2006, 01:09

per semplificare la comprensione tu avresti bisogno di un teatrino con le marionette :asd:

Argomentazioni intelligenti come sempre ;)

hanno già libertà di scelta. non sono costretti a tenere la gpl eppure la tengono

Sicuramente... diciamo che scelgono di privarsi della libertà (e soprattutto di privare gli altri della libertà). Scelta rispettabile ma che non condivido :)

sarà modificato quanto vuoi ma al contrario di linux-CDDL linux-GPL NON potrà contenere drivers closed source (anche perchè è l'argomento di questo thread)

E quindi? :rolleyes: Come già ampiamente spiegato le controindicazioni alla presenza di driver closed source sono potenzialmente già riscontrabili anche in "Linux-GPL", indipendentemente dalla presenza di driver proprietari.

voglio vedere come escono in fretta i drivers di 3dfx :asd: e se c'è una vulnerabilità pericolosa? pazienza.. qualche pc non verrà mai patchato

Da quando 3dfx rilascia driver proprietari per Linux? :asd:

ps. 3dfx è solo un esempio.. ci sono anche produttori ancora attivi che sono restii a rilasciare aggiornamenti dei drivers. oppure nel futuro ci possono essere altri 3dfx

Ah ecco mi sembrava strano :Prrr: forse sono restii perchè il rilascio di nuovi driver non è così urgente (nessuna "vulnerabilità pericolosa"). Nel caso di "altri 3dfx" se ci saranno driver open source migliori non penso che la gente continuerà ad utilizzare quelli proprietari discontinuati. La gente cerca sempre la migliore alternativa... per questo la stragrande maggioranza utilizza i driver nVidia proprietari ;)

se rilasciassero le specifiche comincierebbero a combattere ad armi meno impari. e ti credo i drivers di nVidia sono meglio.. solo loro sanno com'è fatta sta benedetta scheda. poi il driver di ATI è l'unico che mi causa dei crash saltuariamente facendomi pensare per qualche secondo di essere su windows.. per fortuna si riavvia solo X perchè linux è un grosso pezzo di pietra monolitico (mentre su windows sarebbe schermata blu).
inoltre altra lettura per te http://www.hwupgrade.it/forum/showthread.php?t=989040

Per essere davvero pari chi vuole a tutti i costi driver open source dovrebbe anche prodursi la periferica ;) Periferica sua, scelte sue, driver suoi... prendere o lasciare. Nel caso tu lasciassi divertiti con l'accelerazione 3D offerta dal driver "nv" ;) Inoltre penso tu abbia qualche nozione sbagliata riguardo al design del software, poichè è esattamente il contrario: è proprio modularizzando i componenti che puoi fare in modo che l'errore in uno specifico componente non coinvolga l'intero sistema ;)

:confused: non capisco cosa significhi... eppure mi sembra chiaro che se linux venisse rilasciato sotto CDDL sarebbe un disastro

Ed è in questo che sbagli profondamente... e posso dimostrartelo tranquillamente citando OpenSolaris: non vedo alcun disastro (anzi vedo un kernel nettamente superiore a Linux... ma questa è chiaramente una mia opinione personale).

ah adesso correggi il tiro! sei passato da "linux non è degno di chiamarsi modulare" a "è meno modulare" :rolleyes: dai la prossima è quella buona
Si chiama capacità di associazione delle idee: Linux è troppo poco modulare quindi non è degno di tale appellativo (imho).

;)

ekerazha

22-08-2006, 01:10

credo che la liberta' di scelta l'abbiano applicata quando hanno deciso per la GPL

Vedi post sopra.

guarda che l'utente ci rimette anche coi driver closed... pensa a chi come me ha gnu/linux su powerpc: non ho i driver ati e nemmeno quelli nvidia. toh, che bello il mondo dei driver closed. l'universo non e' fatto di soli x86 e l'unica via per avere un sistema operativo realmente multipiattaforma e' il software aperto.
Questo è un tuo problema... potevi informarti ed avresti scoperto che non esistono driver proprietari ATI/nVidia per PowerPC, quindi dovrai ripiegare su quelli open :)

ekerazha

22-08-2006, 01:16

Da quando 3dfx rilascia driver proprietari per Linux? :asd:

Cercando in giro sembra che 3dfx avesse iniziato un qualche port per piattaforma Linux ma nulla di ufficialmente supportato o considerato stabile.

ilsensine

22-08-2006, 09:32

Essendo strettamente file-based la CDDL si spinge oltre a quanto non faccia la LGPL.
La LGPL è molto completa, è benissimo applicabile file-based. Un esempio? libavcodec.

ilsensine

22-08-2006, 09:33

l'universo non e' fatto di soli x86
Sante parole

ekerazha

22-08-2006, 09:38

La LGPL è molto completa, è benissimo applicabile file-based. Un esempio? libavcodec.
No.
Non è realmente file-based... esempio banale:

Il programma A il cui sorgente è il file a.file (e che utilizza una licenza non compatibile con LGPL) esegue il linking statico al programma B il cui sorgente è il file b.file e che utilizza la licenza LGPL. I sorgenti risiedono su due file diversi, ma il programma non è in regola perchè viene utilizzato il linking statico.

;)

ilsensine

22-08-2006, 09:44

Il programma A il cui sorgente è il file a.file esegue il linking statico al programma B il cui sorgente è il file b.file e che utilizza la licenza LGPL. I sorgenti risiedono su due file diversi, ma il programma non è in regola perchè viene utilizzato il linking statico.

Ok non conosci la LGPL.

ekerazha

22-08-2006, 09:45

Ok non conosci la LGPL.
Se tra noi due c'è qualcuno che non conosce la LGPL quella persona non sono di certo io, come ti ho appena dimostrato.

ilsensine

22-08-2006, 09:47

Se tra noi due c'è qualcuno che non conosce la LGPL quella persona non sono di certo io, come ti ho appena dimostrato.
Nel Preamble:
For example, if you distribute copies of the library, whether gratis or for a fee, you must give the recipients all the rights that we gave you. You must make sure that they, too, receive or can get the source code. If you link other code with the library, you must provide complete object files to the recipients, so that they can relink them with the library after making changes to the library and recompiling it. And you must show them these terms so they know their rights.
tradotto poi in "legalese" in "TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION", 6-a.

ekerazha

22-08-2006, 09:52

Nel Preamble:

tradotto poi in "legalese" in "TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION", 6-a.
E allora? Leggi bene i punti 5 e 6 ed in particolare il 6b.

Alcune "citazioni":

However, linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a "work that uses the library". The executable is therefore covered by this License. Section 6 states terms for distribution of such executables.

b) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (1) uses at run time a copy of the library already present on the user's computer system, rather than copying library functions into the executable, and (2) will operate properly with a modified version of the library, if the user installs one, as long as the modified version is interface-compatible with the version that the work was made with.

;)

ekerazha

22-08-2006, 10:09

Ah... piccola precisazione (prima che inizino a sorgere dubbi):

Also, you must do one of these things:

* a) Accompany the work with the complete corresponding machine-readable source code for the Library including whatever changes were used in the work (which must be distributed under Sections 1 and 2 above); and, if the work is an executable linked with the Library, with the complete machine-readable "work that uses the Library", as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library. (It is understood that the user who changes the contents of definitions files in the Library will not necessarily be able to recompile the application to use the modified definitions.)

Siccome la licenza parla di "una di queste cose", si potrebbe pensare di seguire il punto 6a anzichè il punto 6b, tuttavia if the work is an executable linked with the Library, with the complete machine-readable "work that uses the Library", as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library quindi appare evidente che in molti casi la cosa non sia fattibile (es. nel caso di software closed source).

:)

ilsensine

22-08-2006, 10:10

E allora? Leggi bene i punti 5 e 6 ed in particolare il 6b.
La sez. 6 afferma che:
Also, you must do one of these things:
Quindi, se scegli 6-a, pui ignorare 6.b.

Alcune "citazioni":

However, linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a "work that uses the library". The executable is therefore covered by this License. Section 6 states terms for distribution of such executables.

"covered by this License" nel senso pratico che si ha l'obbligo di seguire la sezione 6. Nella quale si sancisce che l'utente ha sempre il diritto di modificare la libreria utilizzata da un programma. In 6-a, e nel preamble, si chiarisce come questo debba avvenire: deve poter essere disponibile _almeno_ l'object code esterno alla libreria (il 6-a parla di object code and/or source code), in modo che l'utente abbia la facoltà di modificare la libreria a piacimento e effettuare un relink. Questo requisito non esiste nella CDDL, e puoi giudicarlo restrittivo come ti piace (conosco almeno un caso in cui si è scelto di alleggerire tale requisito, aggiungendo alla LGPL una postilla per evitare l'obbligo della fornitura dell'object code).
Nota infine che qui si parla di 'linking a "work that uses the Library"'. Non si parla solo di "static linking".

ilsensine

22-08-2006, 10:11

Ah... piccola precisazione (prima che inizino a sorgere dubbi):

Siccome la licenza parla di "una di queste cose", si potrebbe pensare di seguire il punto 6a anzichè il punto 6b, tuttavia if the work is an executable linked with the Library, with the complete machine-readable "work that uses the Library" quindi appare evidente che in molti casi la cosa non sia fattibile (es. nel caso di software closed source).

:)
Machine-readable code = object code ;)

k0nt3

22-08-2006, 10:14

lasciatelo dire.. sei proprio LOLLOSO :D
Argomentazioni intelligenti come sempre ;)

Sicuramente... diciamo che scelgono di privarsi della libertà (e soprattutto di privare gli altri della libertà). Scelta rispettabile ma che non condivido :)

hai un concetto strano di libertà.. lascia gli altri liberi di avere altri concetti :asd:

E quindi? :rolleyes: Come già ampiamente spiegato le controindicazioni alla presenza di driver closed source sono potenzialmente già riscontrabili anche in "Linux-GPL", indipendentemente dalla presenza di driver proprietari.

veramente non hai dimostrato un bel niente. anzi è stato dimostrato il contrario

Da quando 3dfx rilascia driver proprietari per Linux? :asd:

fai finta di non capire? beh allora ti propongo un altro esempio... il sidewinder! MS ha cessato il supporto per tale dispositivo. e chissà quanti altri dispositivi sono in questa condizione. comunque io non parlavo di linux, ma di un ipotetico SO con licenza aperta a moduli proprietari.

Ah ecco mi sembrava strano :Prrr: forse sono restii perchè il rilascio di nuovi driver non è così urgente (nessuna "vulnerabilità pericolosa"). Nel caso di "altri 3dfx" se ci saranno driver open source migliori non penso che la gente continuerà ad utilizzare quelli proprietari discontinuati. La gente cerca sempre la migliore alternativa... per questo la stragrande maggioranza utilizza i driver nVidia proprietari ;)

vedi sopra :read: anche se fossero aggiornamenti urgenti per il sidewinder non verrebbero rilasciati (ne tantomeno per le schede 3dfx.. per fortuna lì c'è una comunità di pazzi maniaci che sviluppa drivers non ufficiali)

Per essere davvero pari chi vuole a tutti i costi driver open source dovrebbe anche prodursi la periferica ;) Periferica sua, scelte sue, driver suoi... prendere o lasciare. Nel caso tu lasciassi divertiti con l'accelerazione 3D offerta dal driver "nv" ;) Inoltre penso tu abbia qualche nozione sbagliata riguardo al design del software, poichè è esattamente il contrario: è proprio modularizzando i componenti che puoi fare in modo che l'errore in uno specifico componente non coinvolga l'intero sistema ;)

stai delirando... hardware open? e con che soldi lo mettono in produzione? c'è un costo leggermente maggiore rispetto al software open :muro:

ps. mi pare che tu non hai afferrato l'ironia sul grosso pezzo di pietra monolitico

Ed è in questo che sbagli profondamente... e posso dimostrartelo tranquillamente citando OpenSolaris: non vedo alcun disastro (anzi vedo un kernel nettamente superiore a Linux... ma questa è chiaramente una mia opinione personale).

tu invece sbagli profondamente in tutto. OpenSolaris non è vittima di nessun disastro perchè non ha attorno a se gli interessi economici che ha linux oggi

Si chiama capacità di associazione delle idee: Linux è troppo poco modulare quindi non è degno di tale appellativo (imho).

;)
ah adesso è troppo poco modulare... dai spara la prossima :asd:

ekerazha

22-08-2006, 10:23

La sez. 6 afferma che:

Quindi, se scegli 6-a, pui ignorare 6.b.

"covered by this License" nel senso pratico che si ha l'obbligo di seguire la sezione 6. Nella quale si sancisce che l'utente ha sempre il diritto di modificare la libreria utilizzata da un programma. In 6-a, e nel preamble, si chiarisce come questo debba avvenire: deve poter essere disponibile _almeno_ l'object code esterno alla libreria (il 6-a parla di object code and/or source code), in modo che l'utente abbia la facoltà di modificare la libreria a piacimento e effettuare un relink.
Nota infine che qui si parla di 'linking a "work that uses the Library"'. Non si parla solo di "static linking".

[...]

Machine-readable code = object code

Vedi che ti avevo anticipato ;)

Premesso (come già detto) che un produttore di software closed source potrebbe non ritenere opportuna nemmeno l'inclusione dell'object code (anche per motivi logistici es. il software viene distribuito su un supporto e non c'è abbastanza spazio per contenere anche tutto l'object code), come ti avevo detto si sta disquisendo di linking, statico o non statico (nessuno ha mai detto che si parla solo di linking statico, anzi ho citato esplicitamente anche il linking dinamico ad esempio). Quindi (come già detto) la licenza LGPL non è una licenza strettamente file-based come la CDDL, per la quale questo genere di "disquisizioni" non esisterebbe.

Questo requisito non esiste nella CDDL, e puoi giudicarlo restrittivo come ti piace (conosco almeno un caso in cui si è scelto di alleggerire tale requisito, aggiungendo alla LGPL una postilla per evitare l'obbligo della fornitura dell'object code).

Applicando correttamente la licenza direi che è molto restrittivo ;)

ilsensine

22-08-2006, 10:33

Vedi che ti avevo anticipato ;)

Premesso (come già detto) che un produttore di software closed source potrebbe non ritenere opportuna nemmeno l'inclusione dell'object code (anche per motivi logistici es. il software viene distribuito su un supporto e non c'è abbastanza spazio per contenere anche tutto l'object code)

Non a caso, ti dicevo, alcuni "rilassano" quella clausola della LGPL (ho trovato anche un'altro caso, poco fa).

ekerazha

22-08-2006, 10:38

hai un concetto strano di libertà.. lascia gli altri liberi di avere altri concetti :asd:

Puoi avere tutti gli astrusi concetti che preferisci :asd:

veramente non hai dimostrato un bel niente. anzi è stato dimostrato il contrario

L'ho dimostrato argomentandolo ampiamente, l'unica cosa che dovresti fare è leggere quello che ho scritto.

fai finta di non capire? beh allora ti propongo un altro esempio... il sidewinder! MS ha cessato il supporto per tale dispositivo. e chissà quanti altri dispositivi sono in questa condizione. comunque io non parlavo di linux, ma di un ipotetico SO con licenza aperta a moduli proprietari.

E allora? Vorrà dire che se qualcuno è interessato svilupperà un driver opportuno (magari open). Non vedo quale sia il problema.

vedi sopra :read: anche se fossero aggiornamenti urgenti per il sidewinder non verrebbero rilasciati (ne tantomeno per le schede 3dfx.. per fortuna lì c'è una comunità di pazzi maniaci che sviluppa drivers non ufficiali)

Infatti un driver discontinuato non dovrebbe mai essere preso in larga considerazione... la situazione cambia per i prodotti non discontinuati.

Comunque tutto ciò è partito da una comparazione tra GPL e CDDL... mi auguro tu ti renda conto che tutti questi discorsi c'entrano ben poco (perchè come già detto anche con un software GPL potrei creare un fork e modificare le interfacce), inoltre con la CDDL non solo avrei la libertà di includere software proprietario, ma anche software opensource che magari è però incompatibile con la GPL ;)

stai delirando... hardware open? e con che soldi lo mettono in produzione? c'è un costo leggermente maggiore rispetto al software open :muro:

Questo è un tuo problema. Se vuoi fare le cose a modo tuo devi essere in grado di farle fino in fondo.

ps. mi pare che tu non hai afferrato l'ironia sul grosso pezzo di pietra monolitico

L'ironia tragica è che Windows teoricamente sarebbe più modulare di Linux (a cominciare dal fatto che è un "kernel ibrido"). Quando si parla di Windows ci sono spesso in mezzo delle tragedie purtroppo.

tu invece sbagli profondamente in tutto. OpenSolaris non è vittima di nessun disastro perchè non ha attorno a se gli interessi economici che ha linux oggi

Forse non gli stessi ma direi più che sufficienti se calcoli che Solaris è un sistema operativo largamente utilizzato e dunque l'alternativa OpenSolaris è alquanto appetibile e che per Solaris/OpenSolaris esistono benissimo driver binari (quelli nVidia ad esempio) ma nessuno si sogna di includerli nel kernel di OpenSolaris (per molti motivi credo, oltre a quelli dei quali abbiamo parlato... volendo possiamo parlare anche di questi comunque).

ah adesso è troppo poco modulare... dai spara la prossima :asd:
... eppure credevo che la capacità di associazione delle idee fosse comune al genere umano.

Ciao Alien! ;)

ekerazha

22-08-2006, 10:40

Non a caso, ti dicevo, alcuni "rilassano" quella clausola della LGPL (ho trovato anche un'altro caso, poco fa).
Comprensibile :) Quindi alla fine, spero sarai d'accordo con me sul fatto che la LGPL non è proprio una licenza file-based come la CDDL.

ekerazha

22-08-2006, 10:49

Tendo inoltre a sottolineare che mentre la LGPL "parla di librerie" la CDDL è applicabile in contesti molto più generali.

k0nt3

22-08-2006, 10:56

Puoi avere tutti gli astrusi concetti che preferisci :asd:

L'ho dimostrato argomentandolo ampiamente, l'unica cosa che dovresti fare è leggere quello che ho scritto.

io ho già letto tutto. sei tu che mi hai costretto a ripostare gli stessi link che aveva postato ilsensine

E allora? Vorrà dire che se qualcuno è interessato svilupperà un driver opportuno (magari open). Non vedo quale sia il problema.

vuoi sapere il problema? le specifiche non ci sono mai o sono insufficienti

Infatti un driver discontinuato non dovrebbe mai essere preso in larga considerazione... la situazione cambia per i prodotti non discontinuati.

meglio un driver discontinuato o nessun driver?

Comunque tutto ciò è partito da una comparazione tra GPL e CDDL... mi auguro tu ti renda conto che tutti questi discorsi c'entrano ben poco (perchè come già detto anche con un software GPL potrei creare un fork e modificare le interfacce), inoltre con la CDDL non solo avrei la libertà di includere software proprietario, ma anche software opensource che magari è però incompatibile con la GPL ;)

c'entra eccome! con la GPL puoi fare tutti i fork che vuoi senza rompere la compatibilità con i drivers!!! per favore prima di rispondere di nuovo leggi 30 volte questo post

Questo è un tuo problema. Se vuoi fare le cose a modo tuo devi essere in grado di farle fino in fondo.

guarda che sei tu che hai tirato in ballo questo discorso incredibile. è semplicemente assurdo pensare a hardware open. magari il tappetino del mouse :asd:

L'ironia tragica è che Windows teoricamente sarebbe più modulare di Linux (a cominciare dal fatto che è un "kernel ibrido"). Quando si parla di Windows ci sono spesso in mezzo delle tragedie purtroppo.

windows non è affatto più modulare di linux. la dicitura "kernel ibrido" (o addirittura "microkernel modificato" come risulta da alcuni documenti su MSDN) la ritengo di scarsa rilevanza pratica. come dimostrato dal mio esempio

Forse non gli stessi ma direi più che sufficienti se calcoli che Solaris è un sistema operativo largamente utilizzato e dunque l'alternativa OpenSolaris è alquanto appetibile e che per Solaris/OpenSolaris esistono benissimo driver binari (quelli nVidia ad esempio) ma nessuno si sogna di includerli nel kernel di OpenSolaris (per molti motivi credo, oltre a quelli dei quali abbiamo parlato... volendo possiamo parlare anche di questi comunque).

e il fatto che ora nessuno si sogna di includere questi moduli nel kernel significa che nessuno se lo sognerà mai?

... eppure credevo che la capacità di associazione delle idee fosse comune al genere umano.

Ciao Alien! ;)
mi dispiace ma microkernel => modulare, ma non viceversa ;)
eppure io credevo che la logica fosse comune al genere umano

ekerazha

22-08-2006, 11:15

io ho già letto tutto. sei tu che mi hai costretto a ripostare gli stessi link che aveva postato ilsensine

Si ma devi leggere le mie risposte ;)

vuoi sapere il problema? le specifiche non ci sono mai o sono insufficienti

Come già detto questo è un tuo problema. Quando l'hai comprato non c'era scritto da nessuna parte che fosse Linux compatibile... se poi lo era tanto meglio.

meglio un driver discontinuato o nessun driver?

Meglio un driver discontinuato solo fino a quando gli svantaggi non superavo i vantaggi.

c'entra eccome! con la GPL puoi fare tutti i fork che vuoi senza rompere la compatibilità con i drivers!!! per favore prima di rispondere di nuovo leggi 30 volte questo post

Certo, ma volendo puoi romperla. Anche con la CDDL nessuno ti constringe ad inserire driver proprietari, ma volendo puoi farlo e potenzialmente rompere la compatibilità. Come vedi le conseguenze possono essere proprio le medesime. Eppure non mi sembra difficile da capire.

guarda che sei tu che hai tirato in ballo questo discorso incredibile. è semplicemente assurdo pensare a hardware open. magari il tappetino del mouse :asd:

Lo so che è assurdo... proprio come è assurdo pensare che un produttore di hardware faccia quello che vuoi tu... se lui vuole driver closed resta con i driver closed, è più che legittimo.

windows non è affatto più modulare di linux. la dicitura "kernel ibrido" (o addirittura "microkernel modificato" come risulta da alcuni documenti su MSDN) la ritengo di scarsa rilevanza pratica. come dimostrato dal mio esempio

L'esempio sarebbe quello dei BSOD? :asd: La tua rilevanza francamente non è importante, se a livello di codice è un "microkernel modificato" non sarà del tutto modulare ma tecnicamente dovrebbe essere sicuramente più modulare di un kernel monolitico (anche se "carica moduli"). Che poi non sia stato implementato a regola d'arte può essere vero, ma questo non c'entra con la struttura del codice originario.

e il fatto che ora nessuno si sogna di includere questi moduli nel kernel significa che nessuno se lo sognerà mai?

Fa parte della categoria dei sogni... proprio come potrei dirti che Linus Torvalds può sognarsi di includere nel kernel Linux ufficiale del codice che gli invia tutto quello che tu digiti sulla tastiera ;)

mi dispiace ma microkernel => modulare, ma non viceversa ;)
eppure io credevo che la logica fosse comune al genere umano
La logica è comune... però non i concetti errati ;)

k0nt3

22-08-2006, 11:36

Si ma devi leggere le mie risposte ;)
fatto. è troppo chiedere altrettanto?

Come già detto questo è un tuo problema. Quando l'hai comprato non c'era scritto da nessuna parte che fosse Linux compatibile... se poi lo era tanto meglio.
cosa c'entra linux. stai sviando il discorso.. io ho detto che non sempre è possibile avere un driver open (che sopperisce a mancanze dei driver closed) perchè le specifiche non ci sono quasi mai.

Meglio un driver discontinuato solo fino a quando gli svantaggi non superavo i vantaggi.

certo meglio un soprammobile che un joystick con drivers non aggiornati

Certo, ma volendo puoi romperla. Anche con la CDDL nessuno ti constringe ad inserire driver proprietari, ma volendo puoi farlo e potenzialmente rompere la compatibilità. Come vedi le conseguenze possono essere proprio le medesime. Eppure non mi sembra difficile da capire.

sospetto che lo stai facendo apposta per prendermi in giro... voglio continuare a credere che tu sei un individuo intelligente. se tutti i drivers sono open puoi cambiare le interfaccie e i drivers in modo da non rompere un bel niente. altrimenti non è possibile

Lo so che è assurdo... proprio come è assurdo pensare che un produttore di hardware faccia quello che vuoi tu... se lui vuole driver closed resta con i driver closed, è più che legittimo.

no! esiste la legge. la licenza va rispettata

L'esempio sarebbe quello dei BSOD? :asd: La tua rilevanza francamente non è importante, se a livello di codice è un "microkernel modificato" non sarà del tutto modulare ma tecnicamente dovrebbe essere sicuramente più modulare di un kernel monolitico (anche se "carica moduli"). Che poi non sia stato implementato a regola d'arte può essere vero, ma questo non c'entra con la struttura del codice originario.

io guardo i fatti

Fa parte della categoria dei sogni... proprio come potrei dirti che Linus Torvalds può sognarsi di includere nel kernel Linux ufficiale del codice che gli invia tutto quello che tu digiti sulla tastiera ;)

si ma lo scoprirei. comunque se non accadrà mai che moduli proprietari finiscono nel kernel di opensolaris... perchè non vietarlo in modo da essere tutelati?

La logica è comune... però non i concetti errati ;)
no è proprio la parte logica che non capisci

MrAsd

22-08-2006, 11:41

Incomincio ad avere un senso di deja-vu... :asd:

ekerazha

22-08-2006, 12:06

fatto. è troppo chiedere altrettanto?

Io leggo ma continuo a trovare scritte sempre le stesse cose (sbagliate) e che non tengono conto delle mie risposte.

cosa c'entra linux. stai sviando il discorso.. io ho detto che non sempre è possibile avere un driver open (che sopperisce a mancanze dei driver closed) perchè le specifiche non ci sono quasi mai.

Eh... e io ti ho risposto che questo è un tuo problema. Quando acquisti una periferica le specifiche di compatibilità sono dichiarate: non puoi lamentarti perchè non ci sono i driver o le specifiche, prodotto suo scelte sue, prodotto tuo scelte tue (Linux è l'esempio di un sistema operativo).

certo meglio un soprammobile che un joystick con drivers non aggiornati

Se i driver non aggiornati comportano gravi falle di sicurezza direi proprio di si.

sospetto che lo stai facendo apposta per prendermi in giro... voglio continuare a credere che tu sei un individuo intelligente. se tutti i drivers sono open puoi cambiare le interfaccie e i drivers in modo da non rompere un bel niente. altrimenti non è possibile

Certo... proprio come in un progetto CDDL non sono costretto ad inserire driver proprietari. La tua obiezione è "potrei inserirli" la mia risposta è "potrei rompere la compatibilità anche in altro modo, indipendentemente dai driver proprietari". Come vedi ogni tua possibile obiezione è coperta dalla mia risposta.

no! esiste la legge. la licenza va rispettata

Che c'entra? Certo che va rispettata. Come vanno rispettate le scelte del produttore... lui non potrà includere i suoi driver nel kernel GPL ma può benissimo mantenere closed source i suoi driver: come già detto è una scelta legittima.

io guardo i fatti

Li guardi in modo parziale e non globale.

si ma lo scoprirei. comunque se non accadrà mai che moduli proprietari finiscono nel kernel di opensolaris... perchè non vietarlo in modo da essere tutelati?

Come scopriresti se driver proprietari venissero inseriti in OpenSolaris.
Non è vietato per una grande serie di motivi (e non è vietato tanto quanto non è vietato che Linus Torvalds si faccia inviare i tuoi dati personali), in primo luogo viene lasciata la libertà (mentre la GPL limita la libertà), in secondo luogo tra i vari motivi potrei dirti che Sun un domani (è una ipotesi) potrebbe inserire driver proprietari in Solaris (bada bene: Solaris non OpenSolaris... premesso che Solaris utilizza la stessa codebase di OpenSolaris) ed in questo modo potrebbe farlo e la cosa non creerebbe mai nessun problema perchè Solaris è un prodotto di Sun e quindi in caso di problemi provvederebbe lei stessa a modificare sia kernel che driver e rilasciare gli eventuali aggiornamenti.

;)

no è proprio la parte logica che non capisci
Chi tra noi due non capisce le cose penso sia più che evidente ;)

DanieleC88

22-08-2006, 12:13

La ati e la nvida hanno assolutamente il diritto di fare driver chiusi se ritengono che sia più conveniente farlo.
Vietare l'inclusione di un modulo chiuso nel kernel è una mancanza di libertà.
Il kernel Linux è coperto dalla GPL e questa prevede - che ti piaccia o meno - che il lavoro derivante debba essere altrettanto GPL. Non è obbligare ATI o NVIDIA a fare driver open. Se vogliono fare driver per Linux, sanno che sono queste le condizioni. Ma possono benissimo non farli se non vogliono. ;)
Si stanno pian piano scocciando? Non mi sembra che siano in condizione di imporre niente.
Come no? Hanno legalmente ragione. E poi, se Linux è da quasi quindici anni sotto GPL non è per puro caso; anzi, non possono mica cambiare la loro licenza solo per venire incontro a quelli che non la apprezzano. Nemmeno NVIDIA e ATI devono essere in condizione di imporre un bel niente ai kernel developers.

ciao ;)

k0nt3

22-08-2006, 12:20

Io leggo ma continuo a trovare scritte sempre le stesse cose (sbagliate) e che non tengono conto delle mie risposte.
certo che ripeto sempre le stesse cose! non le capisci :muro:

Eh... e io ti ho risposto che questo è un tuo problema. Quando acquisti una periferica le specifiche di compatibilità sono dichiarate: non puoi lamentarti perchè non ci sono i driver o le specifiche, prodotto suo scelte sue, prodotto tuo scelte tue (Linux è l'esempio di un sistema operativo).
se hai finito di sviare il discorso ti faccio il riassunto...
tutto è partito da: "se la casa produttrice dell'hardware non supporta più il prodotto come si fa a aggiornare il driver?", tu hai risposto "semplice! qualcuno farà dei drivers opensource!", allora "ma come si fa a fare i drivers di una scatola nera senza uno straccio di specifica?" e poi tu hai cominciato a deviare il discorso dicendo che sull'etichetta ci deve essere scritto linux-compatible.

Se i driver non aggiornati comportano gravi falle di sicurezza direi proprio di si.

vallo a spiegare al 99% della popolazione che non sa cosa voglia dire "falla di sicurezza" e nemmeno "driver", però sa che senza collegare il joystick al PC non funziona un granchè come soprammobile..

Certo... proprio come in un progetto CDDL non sono costretto ad inserire driver proprietari. La tua obiezione è "potrei inserirli" la mia risposta è "potrei rompere la compatibilità anche in altro modo, indipendentemente dai driver proprietari". Come vedi ogni tua possibile obiezione è coperta dalla mia risposta.

certo! tutti noi possiamo costruire un codice rotto! è facile basta chiamare un metodo che non esiste in una libreria... ma c'è qualcuno così imbecille? la tua risposta non copre un bel niente! ripeto per l'ultima volta:
se i driver sono open puoi modificare l'interfaccia e i drivers in modo da non rompere niente, altrimenti NO

Che c'entra? Certo che va rispettata. Come vanno rispettate le scelte del produttore... lui non potrà includere i suoi driver nel kernel GPL ma può benissimo mantenere closed source i suoi driver: come già detto è una scelta legittima.

se le scelte dei produttori sono contro la licenza non va tanto bene. si chiude un occhio fino a un certo punto

Li guardi in modo parziale e non globale.

allora dammi i fatti dell'altra parte

Come scopriresti se driver proprietari venissero inseriti in OpenSolaris.
Non è vietato per una grande serie di motivi (e non è vietato tanto quanto non è vietato che Linus Torvalds si faccia inviare i tuoi dati personali), in primo luogo viene lasciata la libertà (mentre la GPL limita la libertà), in secondo luogo tra i vari motivi potrei dirti che Sun un domani (è una ipotesi) potrebbe inserire driver proprietari in Solaris (bada bene: Solaris non OpenSolaris... premesso che Solaris utilizza la stessa codebase di OpenSolaris) ed in questo modo potrebbe farlo e la cosa non creerebbe mai nessun problema perchè Solaris è un prodotto di Sun e quindi in caso di problemi provvederebbe lei stessa a modificare sia kernel che driver e rilasciare gli eventuali aggiornamenti.

bella schifezza.. se SUN sta pensando di mettere moduli proprietari in solaris significa che vuole nasconderli. chissà che roba c'è dentro (TCPA?)

il problema c'è se terzi decidono di fare moduli proprietari per solaris... e possono farlo! a quel punto la situazione sarebbe come nello scenario catastrofico

;)

Chi tra noi due non capisce le cose penso sia più che evidente ;)
certo che è evidente! se vuoi facciamo un sondaggio

DanieleC88

22-08-2006, 12:22

Che c'entra? Certo che va rispettata. Come vanno rispettate le scelte del produttore... lui non potrà includere i suoi driver nel kernel GPL ma può benissimo mantenere closed source i suoi driver: come già detto è una scelta legittima.
Si, è normalissimo che il produttore faccia le sue scelte, e queste, per carità, vanno rispettate se giuste. Ma se scende a compromessi illegali che violano le licenze utilizzate, permetti almeno che si contesti la decisione.

ilsensine

22-08-2006, 12:38

Comprensibile :) Quindi alla fine, spero sarai d'accordo con me sul fatto che la LGPL non è proprio una licenza file-based come la CDDL.
Su questo non sono d'accordo; la lgpl è applicabile tranquillamente ai file. Puoi semmai addurre che gli obblighi sul linking statico complicano inutilmente la vita; nel tempo anche quelli della fsf se ne sono (in parte) resi conto, tant'è che le libstdc++ non sono distribuite sotto lgpl, ma sotto gpl+una autorizzazione speciale di "non viralità" (le stdc++ fanno pesante uso dei template, che vengono compilati e linkati per forza direttamente nel programma).
Comunque nella stragrande maggioranza dei casi, le librerie lgpl non ha senso linkarle staticamente a un programma.

ilsensine

22-08-2006, 12:41

guarda che sei tu che hai tirato in ballo questo discorso incredibile. è semplicemente assurdo pensare a hardware open. magari il tappetino del mouse :asd:
http://www.opencores.org/
Un sito di cui si parla troppo poco purtroppo...

k0nt3

22-08-2006, 12:50

http://www.opencores.org/
Un sito di cui si parla troppo poco purtroppo...
ci avevo pensato anche io.. ma i costi per produrre hardware mi sembrano troppo elevati.. al massimo si può condividere il codice verilog ( :) ) o vhdl ( :muro: )
tu dici che un giorno ci sarà anche hardware open?

ekerazha

22-08-2006, 12:53

certo che ripeto sempre le stesse cose! non le capisci :muro:

Come già detto, chi tra noi due non capisce le cose è più che evidente... e sono così sereno nel fare questa affermazione che non faccio deliberatamente nomi ;)

se hai finito di sviare il discorso ti faccio il riassunto...
tutto è partito da: "se la casa produttrice dell'hardware non supporta più il prodotto come si fa a aggiornare il driver?", tu hai risposto "semplice! qualcuno farà dei drivers opensource!", allora "ma come si fa a fare i drivers di una scatola nera senza uno straccio di specifica?" e poi tu hai cominciato a deviare il discorso dicendo che sull'etichetta ci deve essere scritto linux-compatible.

:asd: Questo è un "bel" patchwork del discorso... in realtà il discorso è partito ben più a monte con la tua obiezione che "nei kernel CDDL includono driver proprietari e questo è dannoso", obiezione alla quale ho già risposto numerose volte ma tu ti ostini a non capire.

In ogni caso rispondo (nuovamente) anche al tuo patchwork:

allora "ma come si fa a fare i drivers di una scatola nera senza uno straccio di specifica?" e poi tu hai cominciato a deviare il discorso dicendo che sull'etichetta ci deve essere scritto linux-compatible.

Esattamente... se non ci sono le specifiche e non sei in grado di fare senza semplicemente non li fai. Quando qualcuno comperava quella periferica doveva essere consapevole che non c'erano driver per quel sistema operativo (in quanto non riportato nelle specifiche del prodotto). Quindi concludendo (come già detto) è un suo problema.

vallo a spiegare al 99% della popolazione che non sa cosa voglia dire "falla di sicurezza" e nemmeno "driver", però sa che senza collegare il joystick al PC non funziona un granchè come soprammobile..

Innanzitutto dubito che il 99% della popolazione utilizzi sistemi operativi opensource ;) In secondo luogo se la gente non sa le cose è solo un suo problema, come chi ha appena preso un PC con Windows non sa cosa sono i virus e se li prende, non sa cosa sono gli spyware e se li prende, non sa installare un sistema operativo, non sa come si fanno le cose e non le fa ecc. ecc. ecc. c'est la vie ;)

certo! tutti noi possiamo costruire un codice rotto! è facile basta chiamare un metodo che non esiste in una libreria... ma c'è qualcuno così imbecille? la tua risposta non copre un bel niente! ripeto per l'ultima volta:
se i driver sono open puoi modificare l'interfaccia e i drivers in modo da non rompere niente, altrimenti NO

Stai davvero cadendo in basso. Chi ha detto che si costruisca codice "rotto"? Potrei semplicemente modificare le interfacce (creando interfacce diverse e ben funzionanti). E per giunta (come ampiamente illustrato... ormai sono stufo di dire sempre le stesse cose) continui a ripetere concetti errati.

se le scelte dei produttori sono contro la licenza non va tanto bene. si chiude un occhio fino a un certo punto

Infatti nessun produttore viola la licenza ;) Si parlava di Kororaa, mica è fatto da nVidia :asd:

allora dammi i fatti dell'altra parte

I fatti sono che il kernel Windows NT (per citarne uno... potrei dire Mach) è un "microkernel modificato" quindi è sicuramente più modulare di un kernel monolitico (anche se è in grando di "caricare moduli" poichè questa banale funzione non lo rende di certo strutturalmente modulare).

bella schifezza.. se SUN sta pensando di mettere moduli proprietari in solaris significa che vuole nasconderli. chissà che roba c'è dentro (TCPA?)

La cosa mi interessa relativamente... io utilizzo OpenSolaris non Solaris, in ogni caso Solaris è nei fatti il sistema più stabile al mondo (quasi tutti i sistemi con uptime maggiori, anche di alcuni anni, utilizzano Solaris) ed inoltre è utilizzato per i server ad elevata sicurezza in molti governi del mondo, quindi così tanto schifo non deve fare ;) Se vuoi possiamo parlarne tranquillamente (magari in un altro thread).

il problema c'è se terzi decidono di fare moduli proprietari per solaris... e possono farlo! a quel punto la situazione sarebbe come nello scenario catastrofico

Bisogna vedere se Sun decide di inserirli, io non ne sarei così sicuro... in ogni caso fa sempre parte di quel lato di incertezza che coinvolge qualsiasi cosa (vedi Linus Torvalds che spia i tuoi dati personali) e in ogni caso Solaris != OpenSolaris (visto che sei bravo in logica :asd: ).

certo che è evidente! se vuoi facciamo un sondaggio
Anche le capre sanno dire "si" o "no", però chiunque voglia intervenire nella discussione può farlo e sarò libero di appoggiarlo se la pensa come me o di smentirlo punto su punto come sto facendo con te in questo momento.

Edit: gulp... errore ti battitura avevo scritto "te" al posto di "me" :D
Edit 2: rileggendo il mio post ho trovato una frase che potrebbe risultare un po' ambigua... quando ho citato Mach ho detto che il kernel NT è un "microkernel modificato" ed ovviamente mi riferivo proprio a NT, Mach è un microkernel "classico" ;)

ekerazha

22-08-2006, 12:53

Si, è normalissimo che il produttore faccia le sue scelte, e queste, per carità, vanno rispettate se giuste. Ma se scende a compromessi illegali che violano le licenze utilizzate, permetti almeno che si contesti la decisione.
Infatti nessuno dei produttori viola licenze ;)

ekerazha

22-08-2006, 13:00

Su questo non sono d'accordo; la lgpl è applicabile tranquillamente ai file. Puoi semmai addurre che gli obblighi sul linking statico complicano inutilmente la vita; nel tempo anche quelli della fsf se ne sono (in parte) resi conto, tant'è che le libstdc++ non sono distribuite sotto lgpl, ma sotto gpl+una autorizzazione speciale di "non viralità" (le stdc++ fanno pesante uso dei template, che vengono compilati e linkati per forza direttamente nel programma).
Comunque nella stragrande maggioranza dei casi, le librerie lgpl non ha senso linkarle staticamente a un programma.
Credo tu non abbia capito cosa intendo (e cosa intendono anche nelle FAQ ufficiali sulla CDDL: http://www.opensolaris.org/os/about/faq/licensing_faq/#CDDL-combo ) per "file-based". Per file-based è inteso che la licenza viene applicata ai singoli file e poi è finita lì, quindi è consentito mischiare file CDDL e file di altre licenze (se non proibito dalle "altre licenze") perchè la "giurisdizione" della CDDL è limitata al solo file licenziato e non ha importanza se altri file utilizzano altre licenze perchè sono appunto file diversi. Per questo la CDDL è file based. La GPL non è strettamente file based perchè è vero che si può applicare ai file, ma è altrettanto vero che tira in ballo altre cose come il tipo di linking ecc. quindi non è propriamente file-based. Spero di aver chiarito una volta per tutte.

:)

k0nt3

22-08-2006, 13:44

Come già detto, chi tra noi due non capisce le cose è più che evidente... e sono così sereno nel fare questa affermazione che non faccio deliberatamente nomi ;)
:rotfl:

:asd: Questo è un "bel" patchwork del discorso... in realtà il discorso è partito ben più a monte con la tua obiezione che "nei kernel CDDL includono driver proprietari e questo è dannoso", obiezione alla quale ho già risposto numerose volte ma tu ti ostini a non capire.
:confused: puoi spiegarmi dove ho patchato il discorso?

In ogni caso rispondo (nuovamente) anche al tuo patchwork:

allora "ma come si fa a fare i drivers di una scatola nera senza uno straccio di specifica?" e poi tu hai cominciato a deviare il discorso dicendo che sull'etichetta ci deve essere scritto linux-compatible.

Esattamente... se non ci sono le specifiche e non sei in grado di fare senza semplicemente non li fai. Quando qualcuno comperava quella periferica doveva essere consapevole che non c'erano driver per quel sistema operativo (in quanto non riportato nelle specifiche del prodotto). Quindi concludendo (come già detto) è un suo problema.

vedo che continui a far finta di non capire... ti faccio l'esempio con i personaggi della disney non si sa mai :asd:
allora c'è topolino che va da pippo e compra una scheda 3dfx e un joystick sidewinder. come sistema operativo usa un linux-CDDL (ipotetico e casuale) e sia 3dfx che MS hanno dei drivers proprietari per tali dispositivi. poi 3dfx viene comprata da nVidia e MS decide che il sidewinder non merita più di essere supportato, ma allo stesso tempo nessuno dei due rilascia le specifiche ne continua lo sviluppo dei drivers (figuriamoci se zio paperone fa una cosa simile).
poi arriva il 21 agosto e a topolinia fa molto caldo. si scopre una grossissima falla nel kernel di linux-CDDL e fixarla significa rompere la compatibilità con i drivers di cui sopra. topolino allora va da minnie e la uccide per sfogare la rabbia. intanto a topolinia regna il panico: gente che si butta dalle finestre, banda bassotti che scorrazza per le vie del centro ecc..

di chi è il problema?

Innanzitutto dubito che il 99% della popolazione utilizzi sistemi operativi opensource ;) In secondo luogo se la gente non sa le cose è solo un suo problema, come chi ha appena preso un PC con Windows non sa cosa sono i virus e se li prende, non sa cosa sono gli spyware e se li prende, non sa installare un sistema operativo, non sa come si fanno le cose e non le fa ecc. ecc. ecc. c'est la vie ;)

che rilevanza ha nel discorso che 99% della popolazione non usa un SO open?

Stai davvero cadendo in basso. Chi ha detto che si costruisca codice "rotto"? Potrei semplicemente modificare le interfacce (creando interfacce diverse e ben funzionanti). E per giunta (come ampiamente illustrato... ormai sono stufo di dire sempre le stesse cose) continui a ripetere concetti errati.

l'hai appena ripetuto! se cambi le interfaccie devi cambiare i drivers altrimenti fai codice rotto di proposito

Infatti nessun produttore viola la licenza ;) Si parlava di Kororaa, mica è fatto da nVidia :asd:

infatti nVidia ha fatto un modulo per il kernel di linux.. ma mica intendeva inserirlo nel kernel eh! l'hanno fatto solo per allenarsi

I fatti sono che il kernel Windows NT (per citarne uno... potrei dire Mach) è un "microkernel modificato" quindi è sicuramente più modulare di un kernel monolitico (anche se è in grando di "caricare moduli" poichè questa banale funzione non lo rende di certo strutturalmente modulare).

puoi spiegarmi esattamente dove windows sarebbe più modulare di linux (ammesso che la modularità si possa quantificare)? di fatto il kernel di windows mi sembra fatto di granito.. basta guardare che quando inserisci un cd nel lettore si blocca tutto.

ps. ancora non hai parlato di fatti

La cosa mi interessa relativamente... io utilizzo OpenSolaris non Solaris, in ogni caso Solaris è nei fatti il sistema più stabile al mondo (quasi tutti i sistemi con uptime maggiori, anche di alcuni anni, utilizzano Solaris) ed inoltre è utilizzato per i server ad elevata sicurezza in molti governi del mondo, quindi così tanto schifo non deve fare ;) Se vuoi possiamo parlarne tranquillamente (magari in un altro thread).

frasi assolute come "è il sistema più stabile del mondo" sono sempre false. ma ti pagano per dire ste fesserie?

Bisogna vedere se Sun decide di inserirli, io non ne sarei così sicuro... in ogni caso fa sempre parte di quel lato di incertezza che coinvolge qualsiasi cosa (vedi Linus Torvalds che spia i tuoi dati personali) e in ogni caso Solaris != OpenSolaris (visto che sei bravo in logica :asd: ).

allora:
1) quando ho detto solaris=opensolaris?
2) se linus mette codice maligno in linux rischia che lo linciamo appena lo scopriamo (e lo scopriamo tranquillo) e quindi non mi sembra il caso che lo fa
3) SUN non deve decidere niente! se i produttori di hardware fanno moduli proprietari e gli utenti vogliono quei moduli è costretta. altrimenti ci sarebbe un fork e sarebbe la stessa cosa comunque

Anche le capre sanno dire "si" o "no", però chiunque voglia intervenire nella discussione può farlo e sarò libero di appoggiarlo se la pensa come me o di smentirlo punto su punto come sto facendo con te in questo momento.

smentire chi? ancora non ho visto uno straccio di argomentazione seria

Edit: gulp... errore ti battitura avevo scritto "te" al posto di "me" :D
e perchè hai corretto? :asd:

Edit 2: rileggendo il mio post ho trovato una frase che potrebbe risultare un po' ambigua... quando ho citato Mach ho detto che il kernel NT è un "microkernel modificato" ed ovviamente mi riferivo proprio a NT, Mach è un microkernel "classico" ;)
infatti forse volevi dire XNU

ekerazha

22-08-2006, 14:25

:confused: puoi spiegarmi dove ho patchato il discorso?

Ho detto "patchwork", non sai cos'è un patchwork? :D http://www.dianehome.com/images/autumn_quilted_patchwork_pillow_c.jpg :D

vedo che continui a far finta di non capire... ti faccio l'esempio con i personaggi della disney non si sa mai :asd:
allora c'è topolino che va da pippo e compra una scheda 3dfx e un joystick sidewinder. come sistema operativo usa un linux-CDDL (ipotetico e casuale) e sia 3dfx che MS hanno dei drivers proprietari per tali dispositivi. poi 3dfx viene comprata da nVidia e MS decide che il sidewinder non merita più di essere supportato, ma allo stesso tempo nessuno dei due rilascia le specifiche ne continua lo sviluppo dei drivers (figuriamoci se zio paperone fa una cosa simile).
poi arriva il 21 agosto e a topolinia fa molto caldo. si scopre una grossissima falla nel kernel di linux-CDDL e fixarla significa rompere la compatibilità con i drivers di cui sopra. topolino allora va da minnie e la uccide per sfogare la rabbia. intanto a topolinia regna il panico: gente che si butta dalle finestre, banda bassotti che scorrazza per le vie del centro ecc..

di chi è il problema?

Allora... speriamo sia la volta buona :D

Corre il 21 agosto ed in quel di Topolinia il nostro eroe Topolino pensa "accidenti, nella città di Bugs Bunny usano linux-CDDL e ci hanno inserito molte cose utili, però sono stati furbi e hanno evitato di inserire driver proprietari di terze parti perchè nella loro libertà hanno utilizzato il buon senso". Però in quel di Topolinia il "mezzo danno" era fatto, quindi non restava che applicare il nuovo fix (causa forza maggiore) e mettere nel cassetto la Voodoo ed il Sidewinder. Però poi pensa "anche se i driver non fossero stati inclusi nel kernel, non essendoci alternative migliori avrei installato comunque i driver obsoleti ed ora avrei comunque gli stessi problemi, dunque alla fine non è cambiato poi molto...". Nel frattempo Archimede Pitagorico crea comunque un fork di Linux-CDDL in cui si ripromette di non inserire mai driver proprietari ed anche un fork di Linux-GPL che utilizzerà per fare vari esperimenti.

Meglio ora?

che rilevanza ha nel discorso che 99% della popolazione non usa un SO open?

Non si sta parlando di sistemi operativi e driver open/close source? Sei tu che hai tirato fuori la storia del 99% della popolazione in questo discorso.

l'hai appena ripetuto! se cambi le interfaccie devi cambiare i drivers altrimenti fai codice rotto di proposito

:asd: Io sviluppo il sistema operativo ed ho apportato delle modifiche all'interfaccia perchè l'ho migliorata, ora tu ovviamente dovresti adeguarti a tale modifiche... il codice è perfettamente corretto e funzionante tant'è che una volta che ti sarai adeguato funzionerà alla perfezione.

infatti nVidia ha fatto un modulo per il kernel di linux.. ma mica intendeva inserirlo nel kernel eh! l'hanno fatto solo per allenarsi

Ma che ragionamenti fai? :asd: L'hanno fatto per rendere disponibile agli utenti Linux ecc. l'accelerazione 3D (ad esempio) sotto Linux, ma nessuno alla nVidia ha mai chiesto di includerlo direttamente nel kernel. Si scaricano, si installano e funzionano... that's all folks ;)

puoi spiegarmi esattamente dove windows sarebbe più modulare di linux (ammesso che la modularità si possa quantificare)? di fatto il kernel di windows mi sembra fatto di granito.. basta guardare che quando inserisci un cd nel lettore si blocca tutto.

ps. ancora non hai parlato di fatti

Se avessi a disposizione il kernel di Windows potrei scendere nei dettagli, il massimo che si può fare è appurare che è un "microkernel modificato" vedendo come vengono gestite alcune cose ed in base alle dichiarazioni Microsoft. Puoi contestare tranquillamente (se ne sei in grado) che Windows NT non abbia nulla a che fare con i microkernel e francamente la cosa mi interesserebbe ben poco dato che non mi interessa proprio difendere Windows. Dico solo che, premettendo che Windows sia un "microkernel" modificato, il linea di principio come ogni buon microkernel è sicuramente più modulare di un kernel monolitico come Linux che di modulare ha ben poco e personalmente non ritengo degno di tale appellativo.

Bisogna tagliartele giù a fette le cose... ora ti è più chiaro?

frasi assolute come "è il sistema più stabile del mondo" sono sempre false. ma ti pagano per dire ste fesserie?

Non sono frasi inventate, sono dati di fatto: http://en.uptime-project.net :read: leggi leggi

allora:
1) quando ho detto solaris=opensolaris?
2) se linus mette codice maligno in linux rischia che lo linciamo appena lo scopriamo (e lo scopriamo tranquillo) e quindi non mi sembra il caso che lo fa
3) SUN non deve decidere niente! se i produttori di hardware fanno moduli proprietari e gli utenti vogliono quei moduli è costretta. altrimenti ci sarebbe un fork e sarebbe la stessa cosa comunque

1) Devi averlo detto? Era una precisazione... da quello che stavi dicendo sembrava stessi per imboccare questa strada sbagliata e quindi mi sono premunito (prevenire è meglio che curare :D ).
2) Tanto quanto si potrebbero linciare i mantainer di OpenSolaris ;)
3) Ah ecco... vedi che la precisazione sarebbe servita, come si fa a fare un fork di SUN Solaris che è un prodotto proprietario? :asd: Se intendevi "OpenSolaris" (che non è di SUN ma della comunità opensource di OpenSolaris) si farà tanto quanto si fa in Linux, ovvero non si includono. Tant'è che i driver nVidia che funzionano su OpenSolaris non sono stati inclusi ;) Parla la realtà dei fatti.

smentire chi? ancora non ho visto uno straccio di argomentazione seria

Le argomentazioni serie ci sono, se tu non le vedi è uno dei tuoi numerosi problemi che pian piano stanno emergendo ;)

e perchè hai corretto? :asd:

infatti forse volevi dire XNU
No no... volevo dire proprio Mach (che è un microkernel).

;)

k0nt3

22-08-2006, 14:47

Ho detto "patchwork", non sai cos'è un patchwork? :D http://www.dianehome.com/images/autumn_quilted_patchwork_pillow_c.jpg :D
allora dove ho patchworkato il discorso?

Allora... speriamo sia la volta buona :D

Corre il 21 agosto ed in quel di Topolinia il nostro eroe Topolino pensa "accidenti, nella città di Bugs Bunny usano linux-CDDL e ci hanno inserito molte cose utili, però sono stati furbi e hanno evitato di inserire driver proprietari di terze parti perchè nella loro libertà hanno utilizzato il buon senso". Però in quel di Topolinia il "mezzo danno" era fatto, quindi non restava che applicare il nuovo fix (causa forza maggiore) e mettere nel cassetto la Voodoo ed il Sidewinder. Però poi pensa "anche se i driver non fossero stati inclusi nel kernel, non essendoci alternative migliori avrei installato comunque i driver obsoleti ed ora avrei comunque gli stessi problemi, dunque alla fine non è cambiato poi molto...". Nel frattempo Archimede Pitagorico crea comunque un fork di Linux-CDDL in cui si ripromette di non inserire mai driver proprietari ed anche un fork di Linux-GPL che utilizzerà per fare vari esperimenti.

Meglio ora?

il discorso non ha nemmeno un filo logico.. cosa vuol dire rilasciare il sorgente sotto CDDL e poi ripromettersi di non inserire mai drivers proprietari? ha senso?
poi vabbè ti devo spiegare anche questo :rolleyes: se i drivers fossero stati opensource quando avrebbero fixato il kernel avrebbero fixato anche i drivers eliminando il problema di incompatibilità.

Non si sta parlando di sistemi operativi e driver open/close source? Sei tu che hai tirato fuori la storia del 99% della popolazione in questo discorso.

hai decontestualizzato il 99%. io ho detto che il 99% delle persone non è esperta di informatica e quindi userebbero il loro hardware anche se ci sono falle grosse nel driver.

:asd: Io sviluppo il sistema operativo ed ho apportato delle modifiche all'interfaccia perchè l'ho migliorata, ora tu ovviamente dovresti adeguarti a tale modifiche... il codice è perfettamente corretto e funzionante tant'è che una volta che ti sarai adeguato funzionerà alla perfezione.

appunto! se fossero opensource i drivers potresti adeguarli immediatamente. mentre quelli closed devi aspettare che li adeguano se hanno tempo e voglia.
quante volte l'avrò ripetuto?

Ma che ragionamenti fai? :asd: L'hanno fatto per rendere disponibile agli utenti Linux ecc. l'accelerazione 3D (ad esempio) sotto Linux, ma nessuno alla nVidia ha mai chiesto di includerlo direttamente nel kernel. Si scaricano, si installano e funzionano... that's all folks ;)

correggo: li si scaricano, li si installano e li si inseriscono nel kernel. hai ragione che è colpa di kooroa che distribuisce la distro con il kernel tainted, ma è colpa di ati e nVidia se i loro drivers violano la gpl.

Se avessi a disposizione il kernel di Windows potrei scendere nei dettagli, il massimo che si può fare è appurare che è un "microkernel modificato" vedendo come vengono gestite alcune cose ed in base alle dichiarazioni Microsoft. Puoi contestare tranquillamente (se ne sei in grado) che Windows NT non abbia nulla a che fare con i microkernel e francamente la cosa mi interesserebbe ben poco dato che non mi interessa proprio difendere Windows. Dico solo che, premettendo che Windows sia un "microkernel" modificato, il linea di principio come ogni buon microkernel è sicuramente più modulare di un kernel monolitico come Linux che di modulare ha ben poco e personalmente non ritengo degno di tale appellativo.

tu continui a sostenere che modulare => microkernel... non ci siamo proprio. poi ti ho già detto che ai fatti il kernel di windows non si comporta molto bene nonostante è un "microkernel modificato" (oddio.. spero che i veri microkernel non si rivoltino nella tomba :asd: )

Bisogna tagliartele giù a fette le cose... ora ti è più chiaro?

continua a tagliare fette e a mettertele sugli occhi che vai bene

Non sono frasi inventate, sono dati di fatto: http://en.uptime-project.net :read: leggi leggi

da uno che vive di benchmark mi dovevo aspettare una risposta simile.. purtroppo i bench non sono dimostrazioni (come le statistiche d'altra parte). questo perchè i bench si basano su fatti empirici mentre le dimostrazioni su fatti oggettivi

1) Devi averlo detto? Era una precisazione... da quello che stavi dicendo sembrava stessi per imboccare questa strada sbagliata e quindi mi sono premunito (prevenire è meglio che curare :D ).
da adesso comincierò a contestare anche cose che non dici

2) Tanto quanto si potrebbero linciare i mantainer di OpenSolaris ;)

non c'entrano niente loro! se la licenza lo permette qualc'unaltro potrebbe inserire moduli closed nel kernel

3) Ah ecco... vedi che la precisazione sarebbe servita, come si fa a fare un fork di SUN Solaris che è un prodotto proprietario? :asd: Se intendevi "OpenSolaris" (che non è di SUN ma della comunità opensource di OpenSolaris) si farà tanto quanto si fa in Linux, ovvero non si includono. Tant'è che i driver nVidia che funzionano su OpenSolaris non sono stati inclusi ;) Parla la realtà dei fatti.

si intendevo opensolaris
ripeto... se non si introducono... perchè permetterlo?

Le argomentazioni serie ci sono, se tu non le vedi è uno dei tuoi numerosi problemi che pian piano stanno emergendo ;)

decisamente stanno emergendo alcuni problemi... più che altro di natura psicologica. fatti curare eh :D

No no... volevo dire proprio Mach (che è un microkernel).

;)
no perchè XNU è il kernel di macosX ed è un kernel ibrido (per favore chiamali così che microkernel modificato mi fa venire i brividi)

javaboy

22-08-2006, 14:49

:rotfl:

:confused: puoi spiegarmi dove ho patchato il discorso?

vedo che continui a far finta di non capire... ti faccio l'esempio con i personaggi della disney non si sa mai :asd:
allora c'è topolino che va da pippo e compra una scheda 3dfx e un joystick sidewinder. come sistema operativo usa un linux-CDDL (ipotetico e casuale) e sia 3dfx che MS hanno dei drivers proprietari per tali dispositivi. poi 3dfx viene comprata da nVidia e MS decide che il sidewinder non merita più di essere supportato, ma allo stesso tempo nessuno dei due rilascia le specifiche ne continua lo sviluppo dei drivers (figuriamoci se zio paperone fa una cosa simile).
poi arriva il 21 agosto e a topolinia fa molto caldo. si scopre una grossissima falla nel kernel di linux-CDDL e fixarla significa rompere la compatibilità con i drivers di cui sopra. topolino allora va da minnie e la uccide per sfogare la rabbia. intanto a topolinia regna il panico: gente che si butta dalle finestre, banda bassotti che scorrazza per le vie del centro ecc..

di chi è il problema?

Fondamentalmente la colpa è della totale mancaza di progettazione del kernel di linux. Ogni modifica al sistema fa saltare tutto.

k0nt3

22-08-2006, 14:52

Fondamentalmente la colpa è della totale mancaza di progettazione del kernel di linux. Ogni modifica al sistema fa saltare tutto.
il codice è gestito in maniera modulare. se poi bisogna ricompilarlo è un altro discorso (ecco perchè i compilatori sono incrementali), ma non salta un bel niente.
ci sono pregi e difetti per ogni architettura

ilsensine

22-08-2006, 14:59

ci avevo pensato anche io.. ma i costi per produrre hardware mi sembrano troppo elevati.. al massimo si può condividere il codice verilog ( :) ) o vhdl ( :muro: )
Che io sappia, ci sono in giro schede di rete che montano un sintetizzato di opencores, per fare un esempio. Non escludo che ci sia altro hw in giro, soprattutto in campo embedded, proveniente da opencores.
Inoltre una fpga, anche se costosa, non ha prezzi insormontabili per chi è appassionato. Avessi qualche lustro in meno, mi piacerebbe passarci un pò di tempo.

ekerazha

22-08-2006, 15:32

allora dove ho patchworkato il discorso?
Era "patchworkato" perchè prendi i discorsi "a pezzi" omettendo parti non trascurabili.

il discorso non ha nemmeno un filo logico.. cosa vuol dire rilasciare il sorgente sotto CDDL e poi ripromettersi di non inserire mai drivers proprietari? ha senso?
poi vabbè ti devo spiegare anche questo :rolleyes: se i drivers fossero stati opensource quando avrebbero fixato il kernel avrebbero fixato anche i drivers eliminando il problema di incompatibilità.

Vuol dire quello che c'è scritto... se la CDDL mi offre un ventaglio di possibilità non sono costretto ad utilizzarle tutte, posso scegliere a mia discrezione utilizzando il buon senso. Ritengo inoltre che tu a me abbia ben poco da poter spiegare, ma questo è un altro discorso... certo, se i driver fossero stati opensource sarebbe stato tutto più semplice, però non lo so, quindi è inutile continuare a trastullarsi, accetta i fatti.

hai decontestualizzato il 99%. io ho detto che il 99% delle persone non è esperta di informatica e quindi userebbero il loro hardware anche se ci sono falle grosse nel driver.

Quindi hai detto una cosa ben poco rilevante. Siccome stiamo parlando di interfacce in sistemi operativi opensource ti ho fatto presente che se il 99% delle persone non è esperta di informatica è un fattore di scarso rilievo in questo caso dato che ben poche persone tra questo 99% utilizzerebbero attualmente un sistema operativo opensource.

appunto! se fossero opensource i drivers potresti adeguarli immediatamente. mentre quelli closed devi aspettare che li adeguano se hanno tempo e voglia.
quante volte l'avrò ripetuto?

Sulla prima frase siamo d'accordo... ti dico solo che potrebbe benissimo esserci un produttore che esegue solertemente gli adattamenti, quindi il problema non è intrinseco al fatto che siano driver "closed" source, bensì all'eventuale "pigrizia" di determinate aziende.

correggo: li si scaricano, li si installano e li si inseriscono nel kernel. hai ragione che è colpa di kooroa che distribuisce la distro con il kernel tainted, ma è colpa di ati e nVidia se i loro drivers violano la gpl.

"Installare" contempla chiaramente "l'inserirli nel kernel", che comunque non è sempre vero perchè ad esempio in distribuzioni come Ubuntu entra in gioco il "restricted-modules" comunque va be'.

In ogni caso continui a fare ragionamenti che non stanno ne' in cielo ne' in terra :asd: Secondo te nVidia e ATI sarebbero *obbligati* a fare driver GPL? :asd: Cos'è la GPL dio in terra? nVidia e ATI licenziano i loro driver come meglio credono e ne' nVidia ne' ATI violano la GPL. Gli utenti scaricano i relativi driver (che non sono giustamente inclusi nel kernel) e li utilizzano. Nemmeno questo mi sembra difficile da capire.

tu continui a sostenere che modulare => microkernel... non ci siamo proprio. poi ti ho già detto che ai fatti il kernel di windows non si comporta molto bene nonostante è un "microkernel modificato" (oddio.. spero che i veri microkernel non si rivoltino nella tomba :asd: )

Premettendo che stai utilizzando "=>" a sproposito (forse sarebbero più adatti operatori relativi all'insiemistica ;) ), quello che tu hai detto è assolutamente irrilevante. Ovvero stai tentando di sostenere che Linux è modulare dicendo che che il kernel NT che dovrebbe essere un "microkernel modificato" crasha quando va in crash un driver. Non per nulla si chiama "modificato" e questo è uno dei casi che lo evidenziano, ma a livello strutturale un microkernel è per definizione più vicino al concetto di modularità di quanto non lo possa essere un kernel monolitico e Mach (del quale disponiamo dei sorgenti) ne è un esempio evidente. Un microkernel sarà sempre più vicino all'ideale di modularità di quanto non lo possa essere un kernel monolitico.

continua a tagliare fette e a mettertele sugli occhi che vai bene

Bravo... le argomentazioni come questa sono sempre state il tuo forte :D

da uno che vive di benchmark mi dovevo aspettare una risposta simile.. purtroppo i bench non sono dimostrazioni (come le statistiche d'altra parte). questo perchè i bench si basano su fatti empirici mentre le dimostrazioni su fatti oggettivi

Direi che l'uptime di un server è tutt'altro che empirico... ed indicativo è il fatto che siano quasi tutti sistemi Solaris ad occupare i primi posti... ti sei chiesto perchè non ci sono server Linux? ;)

da adesso comincierò a contestare anche cose che non dici

:confused: Comunque vedo che hai corretto il tiro (in effetti l'avevi sparata davvero grossa): leggi poco sotto "si intendevo opensolaris".

non c'entrano niente loro! se la licenza lo permette qualc'unaltro potrebbe inserire moduli closed nel kernel

Guarda che la modifica deve essere accolta dai mantainer ;) Mi sembra tu abbia un po' di confusione...

si intendevo opensolaris
ripeto... se non si introducono... perchè permetterlo?

Perchè proibirlo significherebbe proibire anche cose più che legittime e senza rischi (es. impedire a Sun di inserire propri driver e software proprietari nel kernel di Solaris... od impedire anche ad altri di farlo nei loro software, perdendo potenzialità di traino per il progetto opensource).

decisamente stanno emergendo alcuni problemi... più che altro di natura psicologica. fatti curare eh :D

Le tue argomentazioni sono davvero terminate :asd: (a dire il vero sono terminate già da parecchio).

no perchè XNU è il kernel di macosX ed è un kernel ibrido (per favore chiamali così che microkernel modificato mi fa venire i brividi)
E allora? Io intendevo proprio Mach che è un microkernel "classico" ;) Decidi tu quello che devo dire io? :asd: Sarei messo davvero male.

DanieleC88

22-08-2006, 15:36

Infatti nessuno dei produttori viola licenze ;)
Sembrerebbe di si, a vedere dalla licenza GPL. Non sono certo un esperto di licenze e di legalese vario, ma se la GPL prevede che il lavoro derivato dall'originale debba essere GPL, allora i driver closed violano questa clausola.

ilsensine

22-08-2006, 15:36

decisamente stanno emergendo alcuni problemi... più che altro di natura psicologica. fatti curare eh :D

Le tue argomentazioni sono davvero terminate :asd: (a dire il vero sono terminate già da parecchio).

(solo due esempi...)

Si può anche discutere animatamente senza punzecchiarsi, ok? :)

ekerazha

22-08-2006, 15:38

Sembrerebbe di si, a vedere dalla licenza GPL. Non sono certo un esperto di licenze e di legalese vario, ma se la GPL prevede che il lavoro derivato dall'originale debba essere GPL, allora i driver closed violano questa clausola.
E cosa sarebbe stato derivato? ;)

k0nt3

22-08-2006, 15:50

E cosa sarebbe stato derivato? ;)
non puoi inserire moduli closed nel kernel di linux punto e basta. è contro la legge

ps. non pernsare che non ti rispondo :asd:

ilsensine

22-08-2006, 15:51

E cosa sarebbe stato derivato? ;)
I driver nvidia fanno uso di funzionalità del kernel rilasciate sotto gpl (ad esempio, layer di gestione della memoria, dello spazio PCI, controller AGP, IRQ, ecc.). In teoria non potrebbero.

ekerazha

22-08-2006, 15:57

non puoi inserire moduli closed nel kernel di linux punto e basta. è contro la legge

ps. non pernsare che non ti rispondo :asd:
Errato.
Non puoi "distribuirli" ma puoi inserirli tranquillamente sul tuo sistema.

k0nt3

22-08-2006, 16:01

Era "patchworkato" perchè prendi i discorsi "a pezzi" omettendo parti non trascurabili.
mbè? quali sono le parti non trascurabili? ho fatto un riassunto e non mi pare di avere omesso qualcosa di importante

Vuol dire quello che c'è scritto... se la CDDL mi offre un ventaglio di possibilità non sono costretto ad utilizzarle tutte, posso scegliere a mia discrezione utilizzando il buon senso. Ritengo inoltre che tu a me abbia ben poco da poter spiegare, ma questo è un altro discorso... certo, se i driver fossero stati opensource sarebbe stato tutto più semplice, però non lo so, quindi è inutile continuare a trastullarsi, accetta i fatti.
ancora non capisci che qualcunaltro può inserire moduli proprietari nel tuo codice? non devi essere per forza tu. il buon senso è una cosa molto soggettiva. comunque vedo che inizi a riconoscere che i drivers opensource hanno i loro vantaggi non indifferenti

Quindi hai detto una cosa ben poco rilevante. Siccome stiamo parlando di interfacce in sistemi operativi opensource ti ho fatto presente che se il 99% delle persone non è esperta di informatica è un fattore di scarso rilievo in questo caso dato che ben poche persone tra questo 99% utilizzerebbero attualmente un sistema operativo opensource.

non ho capito qual'è la correlazione tra "esperti di informatica" e "utilizza un SO open source" :confused:

Sulla prima frase siamo d'accordo... ti dico solo che potrebbe benissimo esserci un produttore che esegue solertemente gli adattamenti, quindi il problema non è intrinseco al fatto che siano driver "closed" source, bensì all'eventuale "pigrizia" di determinate aziende.

non si sviluppa un sistema operativo pensando che "potrebbe" andare bene

"Installare" contempla chiaramente "l'inserirli nel kernel", che comunque non è sempre vero perchè ad esempio in distribuzioni come Ubuntu entra in gioco il "restricted-modules" comunque va be'.

inserire moduli closed nel kernel di linux significa violare la GPL

In ogni caso continui a fare ragionamenti che non stanno ne' in cielo ne' in terra :asd: Secondo te nVidia e ATI sarebbero *obbligati* a fare driver GPL? :asd: Cos'è la GPL dio in terra? nVidia e ATI licenziano i loro driver come meglio credono e ne' nVidia ne' ATI violano la GPL. Gli utenti scaricano i relativi driver (che non sono giustamente inclusi nel kernel) e li utilizzano. Nemmeno questo mi sembra difficile da capire.

esatto! sarebbero obbligati a fare drivers opensource! come al solito non leggi mai il thread... è stato anche spiegato da ilsensine come fare e cioè mettendo in userspace tutta la brodaglia closed source.

Premettendo che stai utilizzando "=>" a sproposito (forse sarebbero più adatti operatori relativi all'insiemistica ;) ), quello che tu hai detto è assolutamente irrilevante. Ovvero stai tentando di sostenere che Linux è modulare dicendo che che il kernel NT che dovrebbe essere un "microkernel modificato" crasha quando va in crash un driver. Non per nulla si chiama "modificato" e questo è uno dei casi che lo evidenziano, ma a livello strutturale un microkernel è per definizione più vicino al concetto di modularità di quanto non lo possa essere un kernel monolitico e Mach (del quale disponiamo dei sorgenti) ne è un esempio evidente. Un microkernel sarà sempre più vicino all'ideale di modularità di quanto non lo possa essere un kernel monolitico.

premettendo che => vuol dire implica e lo uso quando voglio (se pensi a sproposito avvalli la tesi che non te ne intendi di logica).
ti ripeto per l'ultima volta che modulare non significa necessariamente microkernel e che monolitico e modulare non sono esclusivi. cioè se è monolitico può benissimo essere anche modulare

Bravo... le argomentazioni come questa sono sempre state il tuo forte :D

non è che tu sei da meno eh! ma non facciamoci bannare ;)

Direi che l'uptime di un server è tutt'altro che empirico... ed indicativo è il fatto che siano quasi tutti sistemi Solaris ad occupare i primi posti... ti sei chiesto perchè non ci sono server Linux? ;)

a me sembra un insieme di dati empirici! mi sbaglio? :confused:

:confused: Comunque vedo che hai corretto il tiro (in effetti l'avevi sparata davvero grossa): leggi poco sotto "si intendevo opensolaris".

si può sbagliare! sei tu che non lo ammetterai mai

Guarda che la modifica deve essere accolta dai mantainer ;) Mi sembra tu abbia un po' di confusione...

se è sotto CDDL se c'è un fork la accoglieranno i nuovi manteiner. oppure i driver proprietari li installerà l'utente

Perchè proibirlo significherebbe proibire anche cose più che legittime e senza rischi (es. impedire a Sun di inserire propri driver e software proprietari nel kernel di Solaris... od impedire anche ad altri di farlo nei loro software, perdendo potenzialità di traino per il progetto opensource).

non vedo queste potenzialità di traino.. ad esempio?

Le tue argomentazioni sono davvero terminate :asd: (a dire il vero sono terminate già da parecchio).

e le tue quali sono?

E allora? Io intendevo proprio Mach che è un microkernel "classico" ;) Decidi tu quello che devo dire io? :asd: Sarei messo davvero male.
intendi quel che vuoi.. ma quale sistema operativo usa mach ora?

ekerazha

22-08-2006, 16:01

I driver nvidia fanno uso di funzionalità del kernel rilasciate sotto gpl (ad esempio, layer di gestione della memoria, dello spazio PCI, controller AGP, IRQ, ecc.). In teoria non potrebbero.
Sempre errato.

1) Non possono distribuirlo ma nulla vieta di farlo sul tuo computer.

2) Il fatto che usi determinate funzionalità (es. chiamate a determinate funzioni) non significa che includa codice GPL. Tra l'altro se non sbaglio l'hai detto proprio tu stesso in qualche post addietro che le "chiamate" sono ammesse ;)

N.B. x il punto #1: non possono distribuire il kernel con già dentro il modulo nVidia

ilsensine

22-08-2006, 16:21

Sempre errato.

1) Non possono distribuirlo ma nulla vieta di farlo sul tuo computer.
Non potrebbero distribuirlo, ma lo distribuiscono eccome.
(non importa se esterno al kernel)

2) Il fatto che usi determinate funzionalità (es. chiamate a determinate funzioni) non significa che includa codice GPL.
Utilizza del codice gpl, senza il quale non potrebbe fare nulla. Tanto basta.

Tra l'altro se non sbaglio l'hai detto proprio tu stesso in qualche post addietro che le "chiamate" sono ammesse ;)
Parlavo delle syscall

ekerazha

22-08-2006, 16:35

Non potrebbero distribuirlo, ma lo distribuiscono eccome.
(non importa se esterno al kernel)

Loro distribuiscono i driver coperti dalla loro licenza proprietaria e possono farlo tranquillamente. Quello che non potrebbero fare è distribuire i driver proprietari insieme al kernel ed infatti non lo fanno. Quindi è tutto in regola, ti consiglio una riletta della GPL.

Utilizza del codice gpl, senza il quale non potrebbe fare nulla. Tanto basta.

Parlavo delle syscall

Lo utilizza (volendo) ma non è distribuito insieme ad esso quindi è tutto legittimo. Tecnicamente se volessi potrei fare un sistema operativo mio che per le chiamate utilizza gli stessi nomi di funzione del kernel Linux ;) Mi auguro tu non stia tentando di sostenere che il banale nome di una funzione è coperto da licenza ;) altrimenti credo dovremmo distruggere la stragrande maggioranza del software esistente (open e proprietario).

ekerazha

22-08-2006, 16:36

mbè? quali sono le parti non trascurabili? ho fatto un riassunto e non mi pare di avere omesso qualcosa di importante

Sei partito da metà strada tralasciando le premesse a monte. Ad esempio nel tuo discorso che avevo quotato, il fatto che la tua obiezione iniziale fosse quella che "nei kernel CDDL includono driver proprietari e questo è dannoso".

;)

ancora non capisci che qualcunaltro può inserire moduli proprietari nel tuo codice? non devi essere per forza tu. il buon senso è una cosa molto soggettiva. comunque vedo che inizi a riconoscere che i drivers opensource hanno i loro vantaggi non indifferenti

Può farlo ma in un altro progetto (e allora affari suoi), perchè nel mio progetto il mantainer sono io e decido io cosa includere o no. Se hai problemi sul fatto che si possa creare il fork di un progetto, come già detto si può farlo anche con la GPL nonchè con la stragrande maggioranza delle licenze opensource. Mi tocca ripeterti sempre le stesse cose.

non ho capito qual'è la correlazione tra "esperti di informatica" e "utilizza un SO open source" :confused:

Nessuna in particolare... è una semplice questione matematica. Fra quel 99% guarda la percentuale di persone che utilizza un sistema operativo opensource.
Mi sembra alla portata di tutti che il sistema operativo oggi più diffuso sia Windows, tantopiù se andiamo a contemplare i soli principianti.

non si sviluppa un sistema operativo pensando che "potrebbe" andare bene

Infatti non "potrebbe", ci "va" quando il produttore dei driver si adatterà alle specifiche. Secondo te i sistemi operativi nascono già includendo tutti i driver esistenti? :asd:

inserire moduli closed nel kernel di linux significa violare la GPL

Sbagliato... distribuirli nel kernel Linux significa violarla. E' evidente che tu non conosca bene la GPL.

esatto! sarebbero obbligati a fare drivers opensource! come al solito non leggi mai il thread... è stato anche spiegato da ilsensine come fare e cioè mettendo in userspace tutta la brodaglia closed source.

Nessuno è obbligato a fare nulla :asd: fossi in te comincerei a contemplare la possibilità che se tiri troppo la corda inizino a "fregarsene ampiamente" dato che la fetta di mercato da soddisfare è abbastanza piccola ;) Prodotto loro, driver loro, scelte loro.

premettendo che => vuol dire implica e lo uso quando voglio (se pensi a sproposito avvalli la tesi che non te ne intendi di logica).
ti ripeto per l'ultima volta che modulare non significa necessariamente microkernel e che monolitico e modulare non sono esclusivi. cioè se è monolitico può benissimo essere anche modulare

(Bastava chiarire... sinceramente ero terrorizzato dal fatto che potesse essere una sorta di "uguale o maggiore", da te posso aspettarmi questo ed altro) Ti ripeto per l'ennesima volta che la modularità offerta da un kernel monolitico (anche se può caricare moduli) è davvero poca per poterlo eventualmente definire "modulare" (imho), mentre un microkernel è sempre e sicuramente più degno di tale appellativo.

a me sembra un insieme di dati empirici! mi sbaglio? :confused:

Si ti sbagli perchè è l'uptime effettivo di alcuni server realmente utilizzati e funzionanti.

se è sotto CDDL se c'è un fork la accoglieranno i nuovi manteiner. oppure i driver proprietari li installerà l'utente

:confused: E allora? Liberi di farlo... è il bello dell'opensource. Tu guarda il progetto originale che è quello di maggior spicco (con i mantainer del progetto originale).

non vedo queste potenzialità di traino.. ad esempio?

Ad esempio Sun sviluppando il kernel SunOS per includerlo nei propri prodotti commerciali (Solaris ad esempio), sviluppa un kernel che è anche rilasciato opensource alla comunità (nel progetto OpenSolaris) e del quale tutti possono usufruire, quindi Sun in questo caso fa da traino al progetto inserendo funzionalità sempre più avanzate.

e le tue quali sono?

Quelle che senza successo sto cercando di spiegarti da pagine.

intendi quel che vuoi.. ma quale sistema operativo usa mach ora?
In parte anche OS X, ma che c'entra chi lo usa? :confused:
E' un kernel, funziona e ci sono persone che lo utilizzano... e resta il fatto che sia un microkernel, indipendentemente da chi lo usa.

ekerazha

22-08-2006, 16:42

Quindi è tutto in regola, ti consiglio una riletta della GPL.
@ilsensine: tra l'altro il titoletto stesso della GPL mi sembra abbastanza autoesplicativo "TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION". Copia, distribuzione e modifica. Stop.

ilsensine

22-08-2006, 17:18

ti consiglio una riletta della GPL.
Perché non la consigli anche a questi (http://www.fsf.org/licensing/licenses/gpl-faq.html) signori? :rolleyes:

Q: If I add a module to a GPL-covered program, do I have to use the GPL as the license for my module?
A: The GPL says that the whole combined program has to be released under the GPL. So your module has to be available for use under the GPL.
But you can give additional permission for the use of your code. You can, if you wish, release your program under a license which is more lax than the GPL but compatible with the GPL. The license list page gives a partial list of GPL-compatible licenses.

Q: If a library is released under the GPL (not the LGPL), does that mean that any program which uses it has to be under the GPL?
A: Yes, because the program as it is actually run includes the library.

ekerazha

22-08-2006, 17:33

Perché non la consigli anche a questi (http://www.fsf.org/licensing/licenses/gpl-faq.html) signori? :rolleyes:
Più che altro consiglio a te di leggere meglio ;)

Si parla sempre di casi nei quali la libreria viene distribuita con il programma, se non viene distribuita assieme il problema non sussiste, come si può appurare leggendo la GPL: http://www.gnu.org/licenses/gpl.html

b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.

Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program.

10. If you wish to incorporate parts of the Program into other free programs whose distribution conditions are different, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally.

Devo aggiungere altro? ;)

ilsensine

22-08-2006, 17:38

Più che altro consiglio a te di leggere meglio ;)

Ok proprio non vuoi capire...

Potrei portarti l'esempio della Trolltech, ma a che serve...a tuo dire, non potrebbero fare una lira...

ekerazha

22-08-2006, 17:39

Il punto definitivo è che come già detto potrei tecnicamente fare un sistema operativo mio che per le chiamate utilizza gli stessi nomi di funzione del kernel Linux (riscrivendo codice equivalente un po' "a la WINE"). ;)

ekerazha

22-08-2006, 17:40

Potrei portarti l'esempio della Trolltech, ma a che serve...
Porta quello che vuoi ;) Io sono qui...

ilsensine

22-08-2006, 17:42

Porta quello che vuoi ;) Io sono qui...
No grazie, mi hai convinto. Ora, convinci anche tutti quelli che vendono software proprietario che usa le Qt, comprando regolare licenza commerciale dalla Trolltech, che stanno buttando i soldi.

ekerazha

22-08-2006, 17:50

No grazie, mi hai convinto. Ora, convinci anche tutti quelli che vendono software proprietario che usa le Qt, comprando regolare licenza commerciale dalla Trolltech, che stanno buttando i soldi.
Infatti sei nuovamente in errore.
Perchè per l'uso con software commerciale le QT non vengono licenziate con la GPL bensì con la licenza commerciale ( http://www.trolltech.com/products/qt/licenses/licensing/qtlicensing ). Mai sentito parlare di dual-licensing e simili? ;)

ilsensine

22-08-2006, 17:58

Infatti sei nuovamente in errore.
Perchè per l'uso con software commerciale le QT non vengono licenziate con la GPL bensì con la licenza commerciale
e come mai non posso vendere un software commerciale che fa uso delle Qt GPL?
Mica vado a distribuire le Qt. Distribuisco solo il mio software.

ekerazha

22-08-2006, 18:00

e come mai non posso vendere un software commerciale che fa uso delle Qt GPL?
Mica vado a distribuire le Qt. Distribuisco solo il mio software.
Perchè te lo impedisce la clausola del "Trolltech's Dual Licensing Model", di certo non la GPL (nel quale caso il problema si pone solo se tu vai a distribuire il tuo software *insieme* alla "libreria" GPL).

ilsensine

22-08-2006, 18:08

Perchè te lo impedisce la clausola del "Trolltech's Dual Licensing Model", di certo non la GPL (nel quale caso il problema si pone solo se tu vai a distribuire il tuo software *insieme* alla "libreria" GPL).
Ma che stai dicendo scusa...
se prendo i sorgenti GPL delle Qt, devo obbedire solo alla GPL. E' scritto chiaramente nelle faq:

http://www.trolltech.com/developer/downloads/qt/faq

(elenco sintetico di obblighi...)
This is because the Open Source versions of our software are governed by the terms of the GNU GPL license. Using the Open Source Edition means you agree that the source of the software you write also will be published according to this license.

Quindi, non perché lo dice la Trolltech. Ma perché lo dice la GPL.

ilsensine

22-08-2006, 18:10

(nel quale caso il problema si pone solo se tu vai a distribuire il tuo software *insieme* alla "libreria" GPL).
Cioè fammi capire...

Distribuisco le Qt GPL: ok, posso farlo.
Distribuisco il mio programma proprietario, senza le Qt GPL incluse: ok, posso farlo
Distribuisco il mio programma con le Qt GPL: Non posso farlo!?

Ti rendi conto in che paradosso ti sei cacciato?

ekerazha

22-08-2006, 18:15

Ma che stai dicendo scusa...
se prendo i sorgenti GPL delle Qt, devo obbedire solo alla GPL. E' scritto chiaramente nelle faq:

http://www.trolltech.com/developer/downloads/qt/faq

Quindi, non perché lo dice la Trolltech. Ma perché lo dice la GPL.
No.
Perchè sei precedentemente soggetto proprio al "Trolltech's Dual Licensing Model" ( http://www.trolltech.com/products/qt/licenses/licensing/opensource ) ed è anche scritto in grassetto nella pagina relativa alla "Open Source Edition":

The Qt Open Source Edition is offered to the Open Source community under Trolltech's Dual Licensing Model. The Open Source Edition is freely available for the development of Open Source software governed by the GNU General Public License (GPL). The Qt Commercial Editions must be used for proprietary, commercial development.

Questo ti dà "diritto di accedere" successivamente alla "Open Source Edition" (in licenza GPL o QPL). N.B. La QPL è ormai obsoleta ed il suo utilizzo porrebbe evidenti problemi.

;)

ekerazha

22-08-2006, 18:16

Cioè fammi capire...

Distribuisco le Qt GPL: ok, posso farlo.
Distribuisco il mio programma proprietario, senza le Qt GPL incluse: ok, posso farlo
Distribuisco il mio programma con le Qt GPL: Non posso farlo!?

Ti rendi conto in che paradosso ti sei cacciato?
Se ci togli "Qt", a livello generale è proprio così (non lo dico io, lo dice la GPL).

Se invece prendiamo alla lettera le tue affermazioni, allora no perchè come già detto sei precedentemente soggetto al "Trolltech's Dual Licensing Model".

ilsensine

22-08-2006, 18:27

Se ci togli "Qt", a livello generale è proprio così (non lo dico io, lo dice la GPL).

Se invece prendiamo alla lettera le tue affermazioni, allora no perchè come già detto sei precedentemente soggetto al "Trolltech's Dual Licensing Model".
Ok neanche il "This is because the Open Source versions of our software are governed by the terms of the GNU GPL license" ti è entrato nelle orecchie.

La Trolltech ha scelto questa forma di Dual Licensing proprio perché la GPL impedisce la vendita di software proprietario che è una "opera derivata" di un software GPL. Non il contrario.

Altrimenti, anche la CDDL o la BSD o la LGPL andavano benissimo.

ekerazha

22-08-2006, 18:30

Ok neanche il "This is because the Open Source versions of our software are governed by the terms of the GNU GPL license" ti è entrato nelle orecchie.
Certo che è governato dalla GPL, ma per accedere alle Qt governate dalla GPL sei prima soggetto al "Trolltech's Dual Licensing Model"".

The Qt Open Source Edition is offered to the Open Source community under Trolltech's Dual Licensing Model. The Open Source Edition is freely available for the development of Open Source software governed by the GNU General Public License (GPL). The Qt Commercial Editions must be used for proprietary, commercial development.

Se non ti va bene scrivi alla FSF e alla Trolltech, le licenze sono loro non mie ;)

ilsensine

22-08-2006, 18:35

Certo che è governato dalla GPL, ma per accedere alle Qt governate dalla GPL sei prima soggetto al "Trolltech's Dual Licensing Model"".
Allora le Qt non potrebbero essere GPL, in quanto conterrebbero ulteriori restrizioni non previste nella GPL.
Sai bene che non posso fare un software, distribuirlo come GPL, con la clausola aggiuntiva di non poterlo vendere a terzi e farci soldi, ad esempio.
Non solo non sarebbe GPL, ma non rientrerebbe proprio nella definizione di "software libero".

The Qt Open Source Edition is offered to the Open Source community under Trolltech's Dual Licensing Model. The Open Source Edition is freely available for the development of Open Source software governed by the GNU General Public License (GPL). The Qt Commercial Editions must be used for proprietary, commercial development.

Queste quattro righe sono solo un chiarimento; per te sarebbero una particolareggiata "licenza" che scavalca la GPL?
Complimenti per la fantasia!

ekerazha

22-08-2006, 18:37

La Trolltech ha scelto questa forma di Dual Licensing proprio perché la GPL impedisce la vendita di software proprietario che è una "opera derivata" di un software GPL. Non il contrario.

Altrimenti, anche la CDDL o la BSD o la LGPL andavano benissimo.
La CDDL o la BSD proprio no altrimenti ne avrebbe impedito l'utilitzzo da parte dei progetti opensource GPL (dato che sono licenze GPL-incompatible) che sono la maggioranza. Per quanto riguarda la LGPL evidentemente avranno avuto altre ragioni... e questo non invalida per nulla quello che sto dicendo, ovvero che sei innanzitutto soggetto al "Trolltech's Dual Licensing Model", come riportato anche sul sito Trolltech.

Inolte tornando al discorso dei driver nVidia, se leggi il comunicato di Kororaa dice che l'obiezione della FSF è stata quella che i driver proprietari nVidia fossero distribuiti insieme al kernel Linux e non che i driver nVidia fossero in sè fuori regola: tant'è che nVidia continua a distribuire senza nessunissimo problema i propri driver (a differenza di Kororaa che ha dovuto chiuedere baracca).

;)

ekerazha

22-08-2006, 18:40

Allora le Qt non potrebbero essere GPL, in quanto conterrebbero ulteriori restrizioni non previste nella GPL.
Sai bene che non posso fare un software, distribuirlo come GPL, con la clausola aggiuntiva di non poterlo vendere a terzi e farci soldi, ad esempio.
Non solo non sarebbe GPL, ma non rientrerebbe proprio nella definizione di "software libero".

Queste quattro righe sono solo un chiarimento; per te sarebbero una particolareggiata "licenza" che scavalca la GPL?
Complimenti per la fantasia!
Infatti non aggiungono nessuna clausola alla GPL e non scavalcano la GPL. Dicono solo *a priori* che alla Open Source Edition rilasciata sotto GPL puoi accedere solo se rilascerai il tuo software sotto GPL e non sarà proprietario e/o commerciale.

ilsensine

22-08-2006, 18:49

La CDDL o la BSD proprio no altrimenti ne avrebbe impedito l'utilitzzo da parte dei progetti opensource GPL (dato che sono licenze GPL-incompatible)
Ma che vai dicendo...
http://www.fsf.org/licensing/licenses/gpl-faq.html#GPLIncompatibleLibs
http://www.fsf.org/licensing/licenses/gpl-faq.html#FSWithNFLibs

ilsensine

22-08-2006, 18:50

Infatti non aggiungono nessuna clausola alla GPL e non scavalcano la GPL. Dicono solo *a priori* che alla Open Source Edition rilasciata sotto GPL puoi accedere solo se rilascerai il tuo software sotto GPL e non sarà proprietario e/o commerciale.
Hai detto niente...

ekerazha

22-08-2006, 18:54

Ma che vai dicendo...
http://www.fsf.org/licensing/licenses/gpl-faq.html#GPLIncompatibleLibs
http://www.fsf.org/licensing/licenses/gpl-faq.html#FSWithNFLibs
:confused: Questi due paragrafi c'entrano ben poco con quello di cui stiamo parlando...

Edit: ... e per quel poco che c'entrano mi danno ragione ;)

ekerazha

22-08-2006, 18:56

Hai detto niente...
Che ti devo dire... eppure sembrerebbe proprio così dal sito della Trolltech ;)

eclissi83

22-08-2006, 19:14

LukeHack

22-08-2006, 19:24

ekerhaza, sei duro a capire :sofico:

ekerazha

22-08-2006, 19:24

ekerazha, ma non capisci o fai finta di non capire? ogni limite ha la sua pazienza! (cit.)
guarda che se le Qt fossero rilasciate esclusivamente in GPL, tu non potresti rilasciare NESSUN software proprietario/commerciale basato su quelle librerie... ovvero se il tuo software proprietario/commerciale si appoggia alle librerie Qt (sempre ipotizzando che siano esclusivamente in GPL), esso viola la licenza.
E il punto non e' nella distribuzione o meno delle librerie, ma ESCLUSIVAMENTE nel loro utilizzo.
Per ovviare a questa cosa (e per farci soldi, che non fanno male), la trolltech permette di usare le Qt per software proprietario/commerciale se acquisti la versione NON-GPL delle librerie e nel tuo software DEVI dire che le librerie sono rilasciate sotto la licenza Qt.
Proprio oggi mi doveva capitare il gruppetto di fanboy della GPL (che però non conoscono la licenza) :rolleyes:

La questione l'ho già spiegata ampiamente citando tutte le fonti del caso (GPL inclusa e sito della Trolltech incluso), quindi per rispondere alle tue obiezioni ti invito a rileggere il thread.

Per uccidere rapidamente lo strascico delle obiezioni basta inoltre ricordare (ritornando tra l'altro "on-topic") che nVidia distribuisce tranquillamente i suoi driver e la FSF ne è perfettamente a conoscenza. Quindi mi sembra evidente una oggettiva lacuna nella tua (nelle vostre) tesi.

;)

k0nt3

22-08-2006, 20:09

sono tornato! avevo di meglio da fare prima... :D è inutile che continui... l'ultimo post non sarà una bugia in questo thread
Sei partito da metà strada tralasciando le premesse a monte. Ad esempio nel tuo discorso che avevo quotato, il fatto che la tua obiezione iniziale fosse quella che "nei kernel CDDL includono driver proprietari e questo è dannoso".
allora adesso parto dall'inizio
tutto è partito da: "nei kernel CDDL includono driver proprietari e questo è dannoso" e tu hai detto "perchè dovrebbe essere dannoso?" allora io "e se la casa produttrice dell'hardware non supporta più il prodotto come si fa a aggiornare il driver?", tu hai risposto "semplice! qualcuno farà dei drivers opensource!", allora "ma come si fa a fare i drivers di una scatola nera senza uno straccio di specifica?" e poi tu hai cominciato a deviare il discorso dicendo che sull'etichetta ci deve essere scritto linux-compatible.
va meglio?

Può farlo ma in un altro progetto (e allora affari suoi), perchè nel mio progetto il mantainer sono io e decido io cosa includere o no. Se hai problemi sul fatto che si possa creare il fork di un progetto, come già detto si può farlo anche con la GPL nonchè con la stragrande maggioranza delle licenze opensource. Mi tocca ripeterti sempre le stesse cose.

perchè nVidia e ATI mica hanno forkato linux! semplicemente fanno i loro drivers e la gente li installa. bene questo è dannoso. con la GPL il problema non sussiste in quanto tutto il codice sarebbe comunque opensource e quindi anche cambiando le interfaccie basta adattare i drivers di conseguenza.

Nessuna in particolare... è una semplice questione matematica. Fra quel 99% guarda la percentuale di persone che utilizza un sistema operativo opensource.
Mi sembra alla portata di tutti che il sistema operativo oggi più diffuso sia Windows, tantopiù se andiamo a contemplare i soli principianti.

prima di tutto si chiama statistica quella.. e poi quello che hai detto è ampiamente discutibile, ma non qui prima che cominci a sparare a caso

EDIT: correggo.. è vero che windows è il SO più diffuso, ma tutti i discorsi che abbiamo fatto sono indipendenti dalla diffusione del SO in oggetto. sorry se non ho risposto subito bene

Infatti non "potrebbe", ci "va" quando il produttore dei driver si adatterà alle specifiche. Secondo te i sistemi operativi nascono già includendo tutti i driver esistenti? :asd:

l'hai detto te che "potrebbe":
Originariamente inviato da ekerazha
Sulla prima frase siamo d'accordo... ti dico solo che potrebbe benissimo esserci un produttore che esegue solertemente gli adattamenti, quindi il problema non è intrinseco al fatto che siano driver "closed" source, bensì all'eventuale "pigrizia" di determinate aziende.

Sbagliato... distribuirli nel kernel Linux significa violarla. E' evidente che tu non conosca bene la GPL.

perchè tu la conosci?

Nessuno è obbligato a fare nulla :asd: fossi in te comincerei a contemplare la possibilità che se tiri troppo la corda inizino a "fregarsene ampiamente" dato che la fetta di mercato da soddisfare è abbastanza piccola ;) Prodotto loro, driver loro, scelte loro.

non è questione di corda, ma di legalità. poi possono benissimo continuare a fare i loro driver, i compromessi esistono. te l'ho già spiegato come: in userspace

(Bastava chiarire... sinceramente ero terrorizzato dal fatto che potesse essere una sorta di "uguale o maggiore", da te posso aspettarmi questo ed altro) Ti ripeto per l'ennesima volta che la modularità offerta da un kernel monolitico (anche se può caricare moduli) è davvero poca per poterlo eventualmente definire "modulare" (imho), mentre un microkernel è sempre e sicuramente più degno di tale appellativo.

prima di tutto maggiore o uguale sarebbe >= e non => che è universalmente riconosciuto come implica. poi non si può quantificare la modularità, o è modulare o non lo è. infine ti ripeto che un kernel monolitico può benissimo essere modulare perchè una cosa non esclude l'altra.

Si ti sbagli perchè è l'uptime effettivo di alcuni server realmente utilizzati e funzionanti.

allora non mi sbaglio! ho detto che sono dati empirici e infatti lo sono.. non capisco perchè scrivi che sbaglio

:confused: E allora? Liberi di farlo... è il bello dell'opensource. Tu guarda il progetto originale che è quello di maggior spicco (con i mantainer del progetto originale).

hai tralasciato (ma io credo involontariamente) il caso in cui gil utenti installano i drivers proprietari che terzi distribuiscono. un pò come succede con nVidia e ATI

Ad esempio Sun sviluppando il kernel SunOS per includerlo nei propri prodotti commerciali (Solaris ad esempio), sviluppa un kernel che è anche rilasciato opensource alla comunità (nel progetto OpenSolaris) e del quale tutti possono usufruire, quindi Sun in questo caso fa da traino al progetto inserendo funzionalità sempre più avanzate.

da quel che ho capito la realtà è che SUN vuole sfruttare l'opensource perchè ha visto che funziona. quando gli gira prende opensolaris, ci sbatte dentro le sue schifezze proprietarie e ti fa pagare solaris come se fosse oro. in realtà il grosso del lavoro l'ha fatto l'opensource :rolleyes:

Quelle che senza successo sto cercando di spiegarti da pagine.

non hai successo perchè le tue argomentazioni non convincono nessuno

In parte anche OS X, ma che c'entra chi lo usa? :confused:
E' un kernel, funziona e ci sono persone che lo utilizzano... e resta il fatto che sia un microkernel, indipendentemente da chi lo usa.
OS X non usa mach! è come dire che usa BSD (monolitico per eccellenza). è vero che deriva da mach, ma non è mach. e nessun sistema operativo diffuso usa mach come kernel

EDIT: ho editato la risposta su windows ;)

ekerazha

22-08-2006, 21:04

sono tornato! avevo di meglio da fare prima... :D è inutile che continui... l'ultimo post non sarà una bugia in questo thread Allora perchè rispondi? :asd:

allora adesso parto dall'inizio
tutto è partito da: "nei kernel CDDL includono driver proprietari e questo è dannoso" e tu hai detto "perchè dovrebbe essere dannoso?" allora io "e se la casa produttrice dell'hardware non supporta più il prodotto come si fa a aggiornare il driver?", tu hai risposto "semplice! qualcuno farà dei drivers opensource!", allora "ma come si fa a fare i drivers di una scatola nera senza uno straccio di specifica?" e poi tu hai cominciato a deviare il discorso dicendo che sull'etichetta ci deve essere scritto linux-compatible.
va meglio?

Un nuovo patchwork... ormai non mi serve più scrivere nuove risposte, posso pure incollare le precedenti dato che ti ostini sempre sulle stesse fesserie... ordunque:

"Allora... speriamo sia la volta buona

Corre il 21 agosto ed in quel di Topolinia il nostro eroe Topolino pensa "accidenti, nella città di Bugs Bunny usano linux-CDDL e ci hanno inserito molte cose utili, però sono stati furbi e hanno evitato di inserire driver proprietari di terze parti perchè nella loro libertà hanno utilizzato il buon senso". Però in quel di Topolinia il "mezzo danno" era fatto, quindi non restava che applicare il nuovo fix (causa forza maggiore) e mettere nel cassetto la Voodoo ed il Sidewinder. Però poi pensa "anche se i driver non fossero stati inclusi nel kernel, non essendoci alternative migliori avrei installato comunque i driver obsoleti ed ora avrei comunque gli stessi problemi, dunque alla fine non è cambiato poi molto...". Nel frattempo Archimede Pitagorico crea comunque un fork di Linux-CDDL in cui si ripromette di non inserire mai driver proprietari ed anche un fork di Linux-GPL che utilizzerà per fare vari esperimenti."

Edit: Inoltre... i driver opensource li fai con gli strumenti che hai a disposizione e se ne sei in grado, altrimenti non li fai. Semplice.

perchè nVidia e ATI mica hanno forkato linux! semplicemente fanno i loro drivers e la gente li installa. bene questo è dannoso. con la GPL il problema non sussiste in quanto tutto il codice sarebbe comunque opensource e quindi anche cambiando le interfaccie basta adattare i drivers di conseguenza.

Perchè sarebbe dannoso? L'utente ottiene il suo scopo ed è contento. Per il resto copio sempre una cosa già detta:

ti dico solo che potrebbe benissimo esserci un produttore che esegue solertemente gli adattamenti, quindi il problema non è intrinseco al fatto che siano driver "closed" source, bensì all'eventuale "pigrizia" di determinate aziende.

Sul fatto che "sarebbe più comodo" se fossero opensource non c'è dubbio comunque, ma non lo sono e non puoi farci proprio nulla ;) Questi sono i fatti.

prima di tutto si chiama statistica quella.. e poi quello che hai detto è ampiamente discutibile, ma non qui prima che cominci a sparare a caso

EDIT: correggo.. è vero che windows è il SO più diffuso, ma tutti i discorsi che abbiamo fatto sono indipendenti dalla diffusione del SO in oggetto. sorry se non ho risposto subito bene

Diamine avrei voluto leggere la fandonia originaria :D Sono arrivato troppo tardi :doh:

Certo che sono indipendenti... era soltanto per sottolineare l'inettitudine del tuo discorso sul "99%".

l'hai detto te che "potrebbe":
Originariamente inviato da ekerazha
Sulla prima frase siamo d'accordo... ti dico solo che potrebbe benissimo esserci un produttore che esegue solertemente gli adattamenti, quindi il problema non è intrinseco al fatto che siano driver "closed" source, bensì all'eventuale "pigrizia" di determinate aziende.

E lo ribadisco infatti... se leggi bene il "potrebbe" è riferito alla solerzia dell'azienda nell'adattare driver, *non* al fatto che "potrebbe" funzionare l'interfaccia del sistema operativo ;)

perchè tu la conosci?

Abbastanza bene. E l'ho ampiamente dimostrato citandone anche numerosi estratti quando si è reso necessario all'interno della discussione.

non è questione di corda, ma di legalità. poi possono benissimo continuare a fare i loro driver, i compromessi esistono. te l'ho già spiegato come: in userspace

Infatti sono perfettamente legali. Detto questo... faranno i loro driver come meglio credono (ovviamente restando nella legalità), se non ti va bene vaglielo a riferire (ammesso che a loro interessi la tua opinione).

prima di tutto maggiore o uguale sarebbe >= e non => che è universalmente riconosciuto come implica.

Uh uh... è una convenzione dei maggiori linguaggi di programmazione non mi sembra una regola (parlo del maggiore o uguale). Comunque lo so benissimo... solo che da te mi sarei aspettato questo ed altro considerando le tesi astruse che stai seminando un po' ovunque :D In ogni caso sono dettagli irrilevanti quindi direi che si può finirla qui.

poi non si può quantificare la modularità, o è modulare o non lo è. infine ti ripeto che un kernel monolitico può benissimo essere modulare perchè una cosa non esclude l'altra.
:asd: Eccola una bella tesi astrusa... sarebbe come dire "non si può quantificare il livello di OOP o un programma è OOP o non lo è" (OOP è solo un esempio... non c'entra col discorso, è solo per rendere l'idea). Purtroppo le cose non sono quasi mai bianche o nere... ed esistono programmi più o meno modulari, modulari in alcune parti ed in altre no ed un kernel monolitico non potrà mai essere davvero modulare per definizione (anche se un accenno di modularità può avercelo, ma imho non sufficiente), come già detto.

allora non mi sbaglio! ho detto che sono dati empirici e infatti lo sono.. non capisco perchè scrivi che sbaglio

Non è empirico perchè non è basato su nessuna particolare osservazione dei fatti... viene banalmente riportato che tali server sono up da tot tempo, è un dato oggettivo e del tutto realistico, non un dato "da laboratorio" come speri di farlo passare. Poi condiscici sopra la retorica che vuoi, i fatti sono questi. Inoltre ti ridomando... mai chiesto perchè ai primi posti figura quasi sempre Solaris? Forse gode di una certa stabilità che dici? ;)

hai tralasciato (ma io credo involontariamente) il caso in cui gil utenti installano i drivers proprietari che terzi distribuiscono. un pò come succede con nVidia e ATI

:confused: E allora? :rolleyes:

da quel che ho capito la realtà è che SUN vuole sfruttare l'opensource perchè ha visto che funziona. quando gli gira prende opensolaris, ci sbatte dentro le sue schifezze proprietarie e ti fa pagare solaris come se fosse oro. in realtà il grosso del lavoro l'ha fatto l'opensource :rolleyes:

Va bene... con questo confermi definitivamente di non avere capito nulla di OpenSolaris. Solaris è un sistema operativo sviluppato da Sun a partire dagli anni '80 ed ora (da poco più di un anno) il suo kernel è stato reso opensource. Quasi tutto il codice del quale è composto OpenSolaris è ancora quello sviluppato da Sun, difficile capire come il grosso del lavoro possa averlo fatto "l'opensource" in un anno :rolleyes: :rolleyes:

non hai successo perchè le tue argomentazioni non convincono nessuno

Quando si ha a che fare con fanboy testardi purtroppo finisce spesso così.

OS X non usa mach! è come dire che usa BSD (monolitico per eccellenza). è vero che deriva da mach, ma non è mach. e nessun sistema operativo diffuso usa mach come kernel

Infatti ho scritto "in parte": leggi con più attenzione per cortesia.
In ogni caso, cosa c'entra questo con il discorso che stiamo trattando? Nulla.

EDIT: ho editato la risposta su windows ;)
Bravo ;)

Edit: piccola aggiuntina... e correzione di un quote

k0nt3

22-08-2006, 21:42

Un nuovo patchwork... ormai non mi serve più scrivere nuove risposte, posso pure incollare le precedenti dato che ti ostini sempre sulle stesse fesserie... ordunque:

"Allora... speriamo sia la volta buona

Corre il 21 agosto ed in quel di Topolinia il nostro eroe Topolino pensa "accidenti, nella città di Bugs Bunny usano linux-CDDL e ci hanno inserito molte cose utili, però sono stati furbi e hanno evitato di inserire driver proprietari di terze parti perchè nella loro libertà hanno utilizzato il buon senso". Però in quel di Topolinia il "mezzo danno" era fatto, quindi non restava che applicare il nuovo fix (causa forza maggiore) e mettere nel cassetto la Voodoo ed il Sidewinder. Però poi pensa "anche se i driver non fossero stati inclusi nel kernel, non essendoci alternative migliori avrei installato comunque i driver obsoleti ed ora avrei comunque gli stessi problemi, dunque alla fine non è cambiato poi molto...". Nel frattempo Archimede Pitagorico crea comunque un fork di Linux-CDDL in cui si ripromette di non inserire mai driver proprietari ed anche un fork di Linux-GPL che utilizzerà per fare vari esperimenti."

Edit: Inoltre... i driver opensource li fai con gli strumenti che hai a disposizione e se ne sei in grado, altrimenti non li fai. Semplice.

abbiamo già constatato che questo discorso è assolutamente insensato.
se non metterai mai drivers chiusi nel kernel cosa lo permetti a fare? in questo modo permetti agli altri di farlo e anche se tu hai buon senso te la mettono nel :ciapet:
poi se i produttori di hardware fossero obbligati a fare drivers opensource non ci sarebbe nessun problema di compatibilità anche dopo la patch.

Perchè sarebbe dannoso? L'utente ottiene il suo scopo ed è contento. Per il resto copio sempre una cosa già detta:

ti dico solo che potrebbe benissimo esserci un produttore che esegue solertemente gli adattamenti, quindi il problema non è intrinseco al fatto che siano driver "closed" source, bensì all'eventuale "pigrizia" di determinate aziende.

perchè è dannoso è spiegato nelle prime pagine.. proprio quello scenario catastrofico. e il problema sono proprio i drivers proprietari

Sul fatto che "sarebbe più comodo" se fossero opensource non c'è dubbio comunque, ma non lo sono e non puoi farci proprio nulla ;) Questi sono i fatti.

io no ma i kernel developer sì. il kernel è loro non dei produttori di hardware

Diamine avrei voluto leggere la fandonia originaria :D Sono arrivato troppo tardi :doh:

Certo che sono indipendenti... era soltanto per sottolineare l'inettitudine del tuo discorso sul "99%".

continui a mettere in altri contesti il mio 99%? io ho detto che i drivers closed source causano problemi nel caso bisogna fixare parti vitali del kernel, allora si può o rompere la compatibilità con i drivers o non fixare il kernel. il 99% se ne sbatte di fixare il kernel e usa i drivers che funzionano

E lo ribadisco infatti... se leggi bene il "potrebbe" è riferito alla solerzia dell'azienda nell'adattare driver, *non* al fatto che "potrebbe" funzionare l'interfaccia del sistema operativo ;)

io non metto in dubbio che le interfaccie funzionino! il problema è che quel "potrebbero adattare i drivers" non è una garanzia sufficiente per un sistema operativo che vuole essere solido

Abbastanza bene. E l'ho ampiamente dimostrato citandone anche numerosi estratti quando si è reso necessario all'interno della discussione.

sei ancora convinto di conoscere la GPL meglio di ilsensine? :rotfl: ne deve passare di acqua sotto i ponti..

Uh uh... è una convenzione dei maggiori linguaggi di programmazione non mi sembra una regola (parlo del maggiore o uguale). Comunque lo so benissimo... solo che da te mi sarei aspettato questo ed altro considerando le tesi astruse che stai seminando un po' ovunque :D In ogni caso sono dettagli irrilevanti quindi direi che si può finirla qui.

è una convenzione dei maggiori linguaggi? beh allora ce ne sarà anche qualcuno che usa => se me lo trovi mi fai un favore, ma per piacere... si usa >= perchè è proprio come si legge e cioè "maggiore o uguale" (nota: prima maggiore e poi uguale)
=> vuol dire da sempre implica

:asd: Eccola una bella tesi astrusa... sarebbe come dire "non si può quantificare il livello di OOP o un programma è OOP o non lo è" (OOP è solo un esempio... non c'entra col discorso, è solo per rendere l'idea). Purtroppo le cose non sono quasi mai bianche o nere... ed esistono programmi più o meno modulari, modulari in alcune parti ed in altre no ed un kernel monolitico non potrà mai essere davvero modulare per definizione (anche se un accenno di modularità può avercelo, ma imho non sufficiente), come già detto.

quando le cose richiedono risposte che sono o sì o no direi che o sono bianche o sono nere. ad esempio:
sei algerino? NO
sei femmina? NO
linux è modulare? SI
beos è modulare? SI
il kernel di linux è un microkernel? NO
e così via

Non è empirico perchè non è basato su nessuna particolare osservazione dei fatti... viene banalmente riportato che tali server sono up da tot tempo, è un dato oggettivo e del tutto realistico, non un dato "da laboratorio" come speri di farlo passare. Poi condiscici sopra la retorica che vuoi, i fatti sono questi. Inoltre ti ridomando... mai chiesto perchè ai primi posti figura quasi sempre Solaris? Forse gode di una certa stabilità che dici? ;)

sai cosa vuol dire empirico? ti consiglio di andartelo a vedere

hai tralasciato (ma io credo involontariamente) il caso in cui gil utenti installano i drivers proprietari che terzi distribuiscono. un pò come succede con nVidia e ATI

:confused: E allora? :rolleyes:

e allora rispondi

Va bene... con questo confermi definitivamente di non avere capito nulla di OpenSolaris. Solaris è un sistema operativo sviluppato da Sun a partire dagli anni '80 ed ora (da poco più di un anno) il suo kernel è stato reso opensource. Quasi tutto il codice del quale è composto OpenSolaris è ancora quello sviluppato da Sun, difficile capire come il grosso del lavoro possa averlo fatto "l'opensource" in un anno :rolleyes: :rolleyes:

no infatti aspettano più di un anno...

Quando si ha a che fare con fanboy testardi purtroppo finisce spesso così.

non dirlo a me :asd: ho a che fare con un fanboy di solaris

Infatti ho scritto "in parte": leggi con più attenzione per cortesia.
In ogni caso, cosa c'entra questo con il discorso che stiamo trattando? Nulla.

avevo detto che d'ora in poi ti avrei contestato anche quello che non dici.. l'hai fatto anche te daltronde :asd: comunque è chiaro che volevi dire XNU e tutti quelli che leggeranno lo capiranno... hai citato il kernel di linux, il kernel di windows... mancava solo MacOS ;)

Bravo ;)

grazie

ekerazha

22-08-2006, 22:18

abbiamo già constatato che questo discorso è assolutamente insensato.
se non metterai mai drivers chiusi nel kernel cosa lo permetti a fare? in questo modo permetti agli altri di farlo e anche se tu hai buon senso te la mettono nel :ciapet:
poi se i produttori di hardware fossero obbligati a fare drivers opensource non ci sarebbe nessun problema di compatibilità anche dopo la patch.

In realtà abbiamo constatato che continui a fare le stesse identiche obiezioni e a me tocca dare sempre le stesse identiche risposte.
Allora... come già detto mille volte... la licenza non permette esplicitamente di "inserire driver chiusi nel kernel", la licenza permette a livello generale una molteplicità di cose (la maggior parte delle quali costruttive, come già spiegato) e questa è una delle tante cose. In questo modo chiunque può inserire quello che ritiene opportuno (a norma di licenza) eventualmente nel proprio progetto (crendo un fork... cosa come già detto possibile con la grande maggioranza delle licenze opensource) infatti se io sono il mantainer di un progetto (magari un progetto di spicco) e una cosa non la voglio includere, allora non la includo, quindi nei :ciapet: non mette nessuno un bel niente ;)

Se i produttori di hardware fossero obbligati a fare driver opensource sarebbe diverso, probabilmente molti non li farebbero nemmeno e se mia nonna avesse le ruote stai pur certo che sarebbe una cariola! ;)

perchè è dannoso è spiegato nelle prime pagine.. proprio quello scenario catastrofico. e il problema sono proprio i drivers proprietari

L'alternativa è il non avere alcun driver (premettendo che il produttore può non voler realizzare driver opensource e/o non volerti dare le specifiche), quindi fra il non avere un driver ed il doverlo eventualmente togliere causa forza maggiore il risultato è comunque che non ce l'hai... quindi non vedo questi grandi problemi e differenze.

io no ma i kernel developer sì. il kernel è loro non dei produttori di hardware

Allora che i driver se li facciano loro (magari senza le specifiche) ;)

continui a mettere in altri contesti il mio 99%? io ho detto che i drivers closed source causano problemi nel caso bisogna fixare parti vitali del kernel, allora si può o rompere la compatibilità con i drivers o non fixare il kernel. il 99% se ne sbatte di fixare il kernel e usa i drivers che funzionano

No. Tu hai detto
"vallo a spiegare al 99% della popolazione che non sa cosa voglia dire "falla di sicurezza" e nemmeno "driver"
non che "se ne sbatte di fixare il kernel", almeno cerca di essere coerente con te stesso.

Causa forza maggiore il driver problematico lo rimuovi e attendi un aggiornamento da parte del produttore, che magari sarà anche solerte... o magari no e allora sarà come non avercelo il driver (come detto poco sopra).

Comunque se preferiscono rimanere insicuri è un problema loro, potrebbe anche esserci chi preferisce tirare martellate al computer.

io non metto in dubbio che le interfaccie funzionino! il problema è che quel "potrebbero adattare i drivers" non è una garanzia sufficiente per un sistema operativo che vuole essere solido

Io non ci vedo particolari controindicazioni, come già spiegato sopra... comunque se per qualcuno è un problema che venga impedito l'utilizzo di driver proprietari... invece a tutt'oggi nVidia (ed altri) è libera di distribuire il proprio driver.

sei ancora convinto di conoscere la GPL meglio di ilsensine? :rotfl: ne deve passare di acqua sotto i ponti..

Non mi sembra ci sia voluto molto per smentirlo punto su punto (citando tra l'altro la stessa GPL). Sicuramente qualcuno la conoscerà meglio di me (ci mancherebbe altro), ma altrettanto sicuramente questa persona non mi sembra proprio "ilsensine" (con tutto il rispetto).

è una convenzione dei maggiori linguaggi? beh allora ce ne sarà anche qualcuno che usa => se me lo trovi mi fai un favore, ma per piacere... si usa >= perchè è proprio come si legge e cioè "maggiore o uguale" (nota: prima maggiore e poi uguale)
=> vuol dire da sempre implica

Se vuoi posso stendertene uno io al volo che lo utilizza ;) Come già detto è una convenzione "non scritta", è normale che i maggiori linguaggi utilizzino quella "convenzione" dato che si parla solitamente di "maggiore o uguale" e non di "uguale o maggiore". "Implica" è una freccia... ora il carattere "uguale" con di fianco il carattere "maggiore" sicuramente assomiglia ad una freccia, ma come già detto questo non ha nulla a che fare con il nostro discorso.

quando le cose richiedono risposte che sono o sì o no direi che o sono bianche o sono nere. ad esempio:
sei algerino? NO
sei femmina? NO
linux è modulare? SI
beos è modulare? SI
il kernel di linux è un microkernel? NO
e così via

Infatti pensare che si possa rispondere alla domanda "è modulare?" con un "sì" o con un "no" è davvero riduttivo ed infantile, la questione è decisamente più articolata.

sai cosa vuol dire empirico? ti consiglio di andartelo a vedere

Cadi male perchè prima di risponderti me ne sono accertato (chiaramente lo sapevo già, ma è stato giusto per eliminare ogni possibile dubbio) guardando sul dizionario :sofico: Secondo me faresti meglio a fare lo stesso.

e allora rispondi

C'è qualcosa a cui rispondere? :confused: :rolleyes:

no infatti aspettano più di un anno...

Quindi il kernel attuale si è fatto da solo visto che non l'ha fatto la "comunità opensource"? ;)

non dirlo a me :asd: ho a che fare con un fanboy di solaris

Uh... anche in questo caso cadi davvero male dato che sui miei PC ho installati ed utilizzo indifferentemente Windows, Linux, OpenSolaris ed OpenBSD ;)

avevo detto che d'ora in poi ti avrei contestato anche quello che non dici.. l'hai fatto anche te daltronde :asd: comunque è chiaro che volevi dire XNU e tutti quelli che leggeranno lo capiranno... hai citato il kernel di linux, il kernel di windows... mancava solo MacOS ;)

Eh già... tu si che sei forte! :asd: Volevo dire proprio "Mach" ed infatti ho detto "Mach", vuoi saperlo tu cosa volevo dire io? :asd: Sei incredibile... comunque va be', se ti fa piacere diciamo che ho detto quello che preferisci :sofico: ahah

k0nt3

22-08-2006, 22:41

In realtà abbiamo constatato che continui a fare le stesse identiche obiezioni e a me tocca dare sempre le stesse identiche risposte.
Allora... come già detto mille volte... la licenza non permette esplicitamente di "inserire driver chiusi nel kernel", la licenza permette a livello generale una molteplicità di cose (la maggior parte delle quali costruttive, come già spiegato) e questa è una delle tante cose. In questo modo chiunque può inserire quello che ritiene opportuno (a norma di licenza) eventualmente nel proprio progetto (crendo un fork... cosa come già detto possibile con la grande maggioranza delle licenze opensource) infatti se io sono il mantainer di un progetto (magari un progetto di spicco) e una cosa non la voglio includere, allora non la includo, quindi nei :ciapet: non mette nessuno un bel niente ;)

non è colpa mia se non la vuoi capire! non c'è bisogno nessun fork.. non mi sembra che ci sia stato un fork di linux perchè ati e nvidia distribuiscono drivers proprietari. il fatto è che permettere ai produttori di distribuire drivers proprietari è dannoso per i motivi già citati mille volte. i manteiner c'entrano ben poco

Se i produttori di hardware fossero obbligati a fare driver opensource sarebbe diverso, probabilmente molti non li farebbero nemmeno e se mia nonna avesse le ruote stai pur certo che sarebbe una cariola! ;)

L'alternativa è il non avere alcun driver (premettendo che il produttore può non voler realizzare driver opensource e/o non volerti dare le specifiche), quindi fra il non avere un driver ed il doverlo eventualmente togliere causa forza maggiore il risultato è comunque che non ce l'hai... quindi non vedo questi grandi problemi e differenze.

ancora fai finta di non capire? la brodaglia closed source la metti fuori dal kernel e cioè in userspace. perchè in questo modo rispetti la licenza e tutti sono contenti.

Allora che i driver se li facciano loro (magari senza le specifiche) ;)

è quello che hanno sempre fatto con enorme fatica, ma purtroppo con risultati magri (che comunque sono sensazionali per la complessità della faccenda)

No. Tu hai detto
"vallo a spiegare al 99% della popolazione che non sa cosa voglia dire "falla di sicurezza" e nemmeno "driver"
non che "se ne sbatte di fixare il kernel", almeno cerca di essere coerente con te stesso.

è assolutamente coerente con tutto quello che ho detto prima. cioè che la gente preferisce un driver che funziona anche se c'è una falla. questo perchè non sa cosa sia una falla

Causa forza maggiore il driver problematico lo rimuovi e attendi un aggiornamento da parte del produttore, che magari sarà anche solerte... o magari no e allora sarà come non avercelo il driver (come detto poco sopra).

ripeto: magari sì magari no non è una garanzia per un sistema operativo che vuole essere solido

Io non ci vedo particolari controindicazioni, come già spiegato sopra... comunque se per qualcuno è un problema che venga impedito l'utilizzo di driver proprietari... invece a tutt'oggi nVidia (ed altri) è libera di distribuire il proprio driver.

sono gentili i kernel developer, ma solo a patto che non diventi la regola

Non mi sembra ci sia voluto molto per smentirlo punto su punto (citando tra l'altro la stessa GPL). Sicuramente qualcuno la conoscerà meglio di me (ci mancherebbe altro), ma altrettanto sicuramente questa persona non mi sembra proprio "ilsensine" (con tutto il rispetto).

a me sembra solo che si sia annoiato di risponderti

Infatti pensare che si possa rispondere alla domanda "è modulare?" con un "sì" o con un "no" è davvero riduttivo ed infantile, la questione è decisamente più articolata.

e come si articola?

Cadi male perchè prima di risponderti me ne sono accertato (chiaramente lo sapevo già, ma è stato giusto per eliminare ogni possibile dubbio) guardando sul dizionario :sofico: Secondo me faresti meglio a fare lo stesso.

empirico vuol dire che è dettato dall'esperienza, e i meri numeri che hai linkato sull'uptime dei server non sono altro che dati sperimentali.
in contrapposizione a questo modo di pensare c'è il ragionamento... cioè questo sistema operativo è più stabile di questo per questo motivo e quest'altro. altrimenti stiamo parlando di aria

C'è qualcosa a cui rispondere? :confused: :rolleyes:

si! continui a parlare del fatto che i manteiner non accetterebbero mai i drivers closed perchè hanno buon senso, ma tralasci che non c'è bisogno che lo fanno. in linux mica li hanno accettati i manteiner del kernel, eppure li si installano per ovvi motivi. da qui la mia obiezione sul fatto che avevi tralasciato la seconda parte della mia frase

Quindi il kernel attuale si è fatto da solo visto che non l'ha fatto la "comunità opensource"? ;)

no, ma da adesso SUN ha un sacco di lavoratori a gratis :read: è possibile che bsd non ha insegnato niente?

il resto non lo quoto solo perchè non c'entra molto

ekerazha

22-08-2006, 23:13

non è colpa mia se non la vuoi capire! non c'è bisogno nessun fork.. non mi sembra che ci sia stato un fork di linux perchè ati e nvidia distribuiscono drivers proprietari. il fatto è che permettere ai produttori di distribuire drivers proprietari è dannoso per i motivi già citati mille volte. i manteiner c'entrano ben poco

:asd: Ancora...
Se vuoi includerli nel kernel potrebbe servire proprio un fork se il mantainer non accetta la modifica (ammesso che la licenza ne permetta l'inclusione). ATI e nVidia distribuiscono tranquillamente driver proprietari proprio perchè li distribuiscono autonomamente... non sono inclusi nel kernel perchè non possono includerli. Il fatto che sia dannoso, come già spiegato mille volte è una mezza bufala ;)

ancora fai finta di non capire? la brodaglia closed source la metti fuori dal kernel e cioè in userspace. perchè in questo modo rispetti la licenza e tutti sono contenti.

La licenza la rispetti anche distribuendo i driver a parte come stanno facendo tranquillamente ATI e nVidia. Se tu vuoi suddividerli tra kernel ed userspace come già detto puoi proporglielo (ammesso che a loro interessi :asd: ).

è quello che hanno sempre fatto con enorme fatica, ma purtroppo con risultati magri (che comunque sono sensazionali per la complessità della faccenda)

Bravi... così si fa.

è assolutamente coerente con tutto quello che ho detto prima. cioè che la gente preferisce un driver che funziona anche se c'è una falla. questo perchè non sa cosa sia una falla

E allora come già detto è un problema loro (anche se solitamente chi cerca un'alternativa alla massa che usa Windows un po' di chiarezza ce l'ha).
C'è anche gente che non sa cosa sia un virus e poi viene infettata... c'est la vie.

ripeto: magari sì magari no non è una garanzia per un sistema operativo che vuole essere solido

Ripeto: se vuoi la solidità causa forza maggiore il driver problematico lo rimuovi e attendi un aggiornamento da parte del produttore, che magari sarà anche solerte... o magari no e allora sarà come non avercelo il driver (come detto poco sopra).

sono gentili i kernel developer, ma solo a patto che non diventi la regola

E' già la regola, ATI e nVidia continuano e continuano senza problemi perchè sono nella legalità, se non lo fossero non potrebbero farlo.
Se i kernel developer avessero qualcosa in contrario (come mi sembra abbia qualcosa in contrario tu con tutte le astruse tesi che mi stai portando) o riscontrassero una violazione, allora potrebbero intervenire... ma non intervengono perchè non c'è nulla su cui intervenire e magari perchè non condividono nemmeno le tue tesi sulla "dannosità" dei driver proprietari ;)

a me sembra solo che si sia annoiato di risponderti

Credimi, anche io sono parecchio annoiato nel rispondere sia a te che a lui, mi aiuta il fatto che la realtà delle cose sta dalla mia (o comunque ci sta in larga parte).

;)

e come si articola?

Come l'ho già articolato decine di volte... devo davvero ripetere tutto? :doh:

empirico vuol dire che è dettato dall'esperienza, e i meri numeri che hai linkato sull'uptime dei server non sono altro che dati sperimentali.
in contrapposizione a questo modo di pensare c'è il ragionamento... cioè questo sistema operativo è più stabile di questo per questo motivo e quest'altro. altrimenti stiamo parlando di aria

Scusa, ma da quando l'esperienza si basa solo su dati sperimentali? :rolleyes: Qui non c'è alcun esperimento, ci sono solo server con elevati uptime, quindi server molto stabili e non sono server "sperimentali" bensì server utilizzati nella quotidianità. Viene semplicemente riportato il loro tempo di uptime quindi come già detto nessun "esperimento". Io ti porto rilievi oggettivi dettati dalla realtà dei fatti... tra noi due l'unico mercante di aria mi sembra sia tu ;) Ora ti ridomando... secondo te perchè tra i server con i maggiori uptime ci sono quasi sempre server Solaris e non Linux? Medita.

si! continui a parlare del fatto che i manteiner non accetterebbero mai i drivers closed perchè hanno buon senso, ma tralasci che non c'è bisogno che lo fanno. in linux mica li hanno accettati i manteiner del kernel, eppure li si installano per ovvi motivi. da qui la mia obiezione sul fatto che avevi tralasciato la seconda parte della mia frase

Come non c'è bisogno? Hai decisamente parecchia confusione... inoltre non mi risulta che il kernel Linux includa driver proprietari :rolleyes: Mi sembra l'ennesima conferma che tu non sappia di cosa stai parlando.

no, ma da adesso SUN ha un sacco di lavoratori a gratis :read: è possibile che bsd non ha insegnato niente?

Proprio un sacco... vatti a vedere il changelog di OpenSolaris, quasi tutte le modifiche sono state apportate da dipendenti Sun ;) Gli sviluppatori Linux non lavorano gratis? Certo... ma poi ottengono in cambio il kernel Linux migliorato. Stessa cosa per OpenSolaris... con la differenza che oltre alla comunità ci lavora anche Sun e fa da grande traino allo sviluppo.

il resto non lo quoto solo perchè non c'entra molto
Fai come meglio credi ;)

k0nt3

22-08-2006, 23:33

:asd: Ancora...
Se vuoi includerli nel kernel potrebbe servire proprio un fork se il mantainer non accetta la modifica (ammesso che la licenza ne permetta l'inclusione). ATI e nVidia distribuiscono tranquillamente driver proprietari proprio perchè li distribuiscono autonomamente... non sono inclusi nel kernel perchè non possono includerli. Il fatto che sia dannoso, come già spiegato mille volte è una mezza bufala ;)

non serve un fork succederebbe quello che già succede su linux per nVidia e ATI e che succede su windows da sempre. cioè i driver vengono distribuiti dai produttori e non dai manteiner del kernel
sei duro eh!

La licenza la rispetti anche distribuendo i driver a parte come stanno facendo tranquillamente ATI e nVidia. Se tu vuoi suddividerli tra kernel ed userspace come già detto puoi proporglielo (ammesso che a loro interessi :asd: ).

allora perchè esiste questo thread? hai letto il primo post? l'inclusione di moduli closed source nel kernel è contro la licenza del kernel stesso punto e basta. e non dire che è solo il distribuire la distro con i driver dentro che è il problema... ATI e nVidia "distribuiscono" il loro modulo del kernel e di certo non per farci la marmellata

E allora come già detto è un problema loro (anche se solitamente chi cerca un'alternativa alla massa che usa Windows un po' di chiarezza ce l'ha).
C'è anche gente che non sa cosa sia un virus e poi viene infettata... c'est la vie.

continui a dire che è un problema loro? ma se prima i drivers c'erano e poi non ci sono più? es. i soliti 3dfx e sidewinder ma chissà quanti altri ancora

Ripeto: se vuoi la solidità causa forza maggiore il driver problematico lo rimuovi e attendi un aggiornamento da parte del produttore, che magari sarà anche solerte... o magari no e allora sarà come non avercelo il driver (come detto poco sopra).

bella solidità! allora fai una cosa... per avere un sistema solido al massimo installa solo i driver che permettono al sistema di avviarsi.. poi non importa se non puoi farci niente con il pc

E' già la regola, ATI e nVidia continuano e continuano senza problemi perchè sono nella legalità, se non lo fossero non potrebbero farlo.
Se i kernel developer avessero qualcosa in contrario (come mi sembra abbia qualcosa in contrario tu con tutte le astruse tesi che mi stai portando) o riscontrassero una violazione, allora potrebbero intervenire... ma non intervengono perchè non c'è nulla su cui intervenire e magari perchè non condividono nemmeno le tue tesi sulla "dannosità" dei driver proprietari ;)

staremo a vedere cosa succederà.. di certo non può continuare così

Come l'ho già articolato decine di volte... devo davvero ripetere tutto? :doh:

dove hai articolato il discorso? voglio sapere quali sono i punti che rendono linux meno modulare di altri kernel. puoi anche quotarti (sempre che trovi qualcosa da quotarti)

Scusa, ma da quando l'esperienza si basa solo su dati sperimentali? :rolleyes: Qui non c'è alcun esperimento, ci sono solo server con elevati uptime, quindi server molto stabili e non sono server "sperimentali" bensì server utilizzati nella quotidianità. Viene semplicemente riportato il loro tempo di uptime quindi come già detto nessun "esperimento". Io ti porto rilievi oggettivi dettati dalla realtà dei fatti... tra noi due l'unico mercante di aria mi sembra sia tu ;) Ora ti ridomando... secondo te perchè tra i server con i maggiori uptime ci sono quasi sempre server Solaris e non Linux? Medita.

prendere un server e vedere quanto tempo dura acceso si chiama "esperimento". comunque credo sia inutile parlare con uno a cui mancano i concetti basilari. io non so perchè tra i server con maggiore uptime ci sono quelli solaris (probabilmente non sono elencati tutti i server del mondo e probabilmente molti server linux potrebbero avere tempi di uptime molto competitivi con quelli solaris) e per questo non sostengo che linux sia migliore di solaris. al contrario tu pur non sapendo perchè in quella graduatoria i sistemi solaris primeggiano sostieni che solaris è più sicuro e stabile di linux. mi sembra campato in aria.

Come non c'è bisogno? Hai decisamente parecchia confusione... inoltre non mi risulta che il kernel Linux includa driver proprietari :rolleyes: Mi sembra l'ennesima conferma che tu non sappia di cosa stai parlando.

fai finta di non capire anche qui? parlavo dei driver ati e nVidia che gli utenti includono successivamente

Proprio un sacco... vatti a vedere il changelog di OpenSolaris, quasi tutte le modifiche sono state apportate da dipendenti Sun ;) Gli sviluppatori Linux non lavorano gratis? Certo... ma poi ottengono in cambio il kernel Linux migliorato. Stessa cosa per OpenSolaris... con la differenza che oltre alla comunità ci lavora anche Sun e fa da grande traino allo sviluppo.

anche linux ha molte aziende che ne trainano lo sviluppo (novell, trolltech, redhat, ibm, google (vedi SOC) e tante altre). solo che in linux i progressi sono di tutti e rimarranno per sempre di tutti

ekerazha

23-08-2006, 00:10

non serve un fork succederebbe quello che già succede su linux per nVidia e ATI e che succede su windows da sempre. cioè i driver vengono distribuiti dai produttori e non dai manteiner del kernel
sei duro eh!

In Linux i driver proprietari di nVidia ed ATI non sono integrati nel kernel originale ma vengono distribuiti autonomamente dai produttori (è eventualmente l'utente che decide di installarli a parte). Certo... più o meno come accade per Windows. I mantainer come già detto decidono cosa includere nel kernel ufficiale, cosa viene rilasciato autonomamente non è di loro competenza (fino a quando questo non viola la licenza... cosa che non accade come già spiegato, perchè altrimenti nVidia e ATI non potrebbero fare quello che invece fanno più che tranquillamente).
Ciao morbido! :asd:

allora perchè esiste questo thread? hai letto il primo post? l'inclusione di moduli closed source nel kernel è contro la licenza del kernel stesso punto e basta. e non dire che è solo il distribuire la distro con i driver dentro che è il problema... ATI e nVidia "distribuiscono" il loro modulo del kernel e di certo non per farci la marmellata

Invece è proprio quello (vedi che lo sai da solo ;) ).
Non è l'inclusione in sè contro la licenza, bensì l'aver distribuito il kernel con incluso codice proprietario (cosa che faceva appunto Kororaa... ovvero un CD con dentro il kernel con i moduli proprietari). Questa è la grande differenza e questo è il perchè Kororaa ha dovuto chiudere baracca mentre nVidia ed ATI (ad esempio) non fanno nulla di illegittimo. ATI e nVidia distribuiscono i loro driver in modo che l'utente possa in un secondo momento installarli ed utilizzarlo e non sono come già detto inclusi nel kernel "originale".

continui a dire che è un problema loro? ma se prima i drivers c'erano e poi non ci sono più? es. i soliti 3dfx e sidewinder ma chissà quanti altri ancora

Come già detto, se c'erano e non ci sono più li lasci se non causano problemi di forza maggiore, se invece causano problemi li togli e sarebbe come se non ci fossero (ovvero come se non fossero mai stati inclusi). Quindi come vedi alla fine è abbastanza irrilevante.

;)

bella solidità! allora fai una cosa... per avere un sistema solido al massimo installa solo i driver che permettono al sistema di avviarsi.. poi non importa se non puoi farci niente con il pc

Se una periferica è obsoleta puoi anche cambiarla... il mondo dell'informatica è in continua evoluzione.

staremo a vedere cosa succederà.. di certo non può continuare così

Staremo a vedere :asd:

dove hai articolato il discorso? voglio sapere quali sono i punti che rendono linux meno modulare di altri kernel. puoi anche quotarti (sempre che trovi qualcosa da quotarti)

Un quote fra tanti (se vuoi ce ne sono anche altri):

Se avessi a disposizione il kernel di Windows potrei scendere nei dettagli, il massimo che si può fare è appurare che è un "microkernel modificato" vedendo come vengono gestite alcune cose ed in base alle dichiarazioni Microsoft. Puoi contestare tranquillamente (se ne sei in grado) che Windows NT non abbia nulla a che fare con i microkernel e francamente la cosa mi interesserebbe ben poco dato che non mi interessa proprio difendere Windows. Dico solo che, premettendo che Windows sia un "microkernel" modificato, il linea di principio come ogni buon microkernel è sicuramente più modulare di un kernel monolitico come Linux che di modulare ha ben poco e personalmente non ritengo degno di tale appellativo.

Quindi Linux è meno modulare proprio in quanto kernel monolitico.

prendere un server e vedere quanto tempo dura acceso si chiama "esperimento". comunque credo sia inutile parlare con uno a cui mancano i concetti basilari. io non so perchè tra i server con maggiore uptime ci sono quelli solaris (probabilmente non sono elencati tutti i server del mondo e probabilmente molti server linux potrebbero avere tempi di uptime molto competitivi con quelli solaris) e per questo non sostengo che linux sia migliore di solaris. al contrario tu pur non sapendo perchè in quella graduatoria i sistemi solaris primeggiano sostieni che solaris è più sicuro e stabile di linux. mi sembra campato in aria.

Infatti nessuno trascorre i pomeriggi davanti al server... è semplicemente una rapida constatazione della realtà. Come già detto... se a qualcuno tra noi due mancano i concetti basilari, ma davvero basilari e lo sta ampiamente dimostrando (ad esempio non sapendo come funziona il mantaining dei kernel o da chi vengono sviluppati... e continuando a perseverare nell'errore) sei proprio tu ;) ). Forse non saranno elencati tutti i server del mondo, ma mi sembra più che indicativo... potrebbero mancare server Linux ma anche Solaris (o sei come il nano che tutte le schede dubbie o disperse sono sue? ;) Spero di no). Se i server Solaris primeggiano mi sembra un'evidenza oggettiva che siano davvero stabili.

;)

fai finta di non capire anche qui? parlavo dei driver ati e nVidia che gli utenti includono successivamente

Uh... forse finalmente hai capito che i driver proprietari non sono inclusi nel kernel "ufficiale" ma possono essere installati in un secondo tempo dagli utenti. Spero sia la volta buona...

anche linux ha molte aziende che ne trainano lo sviluppo (novell, trolltech, redhat, ibm, google (vedi SOC) e tante altre). solo che in linux i progressi sono di tutti e rimarranno per sempre di tutti
Anche con OpenSolaris sono di tutti e rimarranno per sempre di tutti :rolleyes: Il codice è disponibile...

ekerazha

23-08-2006, 00:51

Comunque konte... così sembra la storia infinita, credo che difficilmente di questo passo cambierai la tua posizione (come io difficilmente cambierò la mia), quindi se vuoi si potrebbe concludere con un post di ognuno in cui - senza citare l'altro - si espongono tutte le proprie ragioni... e poi chiudiamo la cosa. Fammi sapere perchè questa discussione sta iniziando a diventare abbastanza stressante ed inoltre gli esami di settembre mi aspettano al varco e dovrei anche studiare :D

Carciofone

23-08-2006, 07:01

Azz ragazzi, premettendo che non sono un esperto di questioni legali legate alle licenze, ma che per motivi di lavoro mi ci dovrò cimentare nel prox futuro, noto con (dis)piacere che l'"utente" ekerazha" si comporta nel medesimo modo polemico e a volte (spesso) offensivo in molti 3d a cui prende parte. Ma che cosa fa, il polemista di professione? Non mi riferisco alle cose dette, di cui, soprattutto in questo caso, non sono in grado di valutare l'attendibilità, ma esclusivamente al modo in cui viene condotta la discussione.
Ciao

ilsensine

23-08-2006, 09:25

Edit: ... e per quel poco che c'entrano mi danno ragione ;)
Non ho altri motivi per perdere ulteriore tempo qui.
Chiunque può leggere quello che hai scritto, confrontarlo con il link che ho postato, leggere la tua reazione e dedurre quindi il tuo modo di ragionare.

eclissi83

23-08-2006, 09:33

Proprio oggi mi doveva capitare il gruppetto di fanboy della GPL (che però non conoscono la licenza) :rolleyes:

La questione l'ho già spiegata ampiamente citando tutte le fonti del caso (GPL inclusa e sito della Trolltech incluso), quindi per rispondere alle tue obiezioni ti invito a rileggere il thread.

Per uccidere rapidamente lo strascico delle obiezioni basta inoltre ricordare (ritornando tra l'altro "on-topic") che nVidia distribuisce tranquillamente i suoi driver e la FSF ne è perfettamente a conoscenza. Quindi mi sembra evidente una oggettiva lacuna nella tua (nelle vostre) tesi.

;)
doh, visto che sei tanto sicuro di cio' che dici, prova a scrivere un software che si basa sulle gtk2 e chiudilo (ovviamente devi rilasciarlo, se lo tieni per te non ha senso). vedi che succede...
ad ogni modo, il tuo modo di rispondere e' quantomeno irritante soprattutto quando ti poni verso gli altri in modo arrogante e presuntuoso da signor "sotuttoioevoinonsapeteniente".
io non rispondero' piu' ad un tuo reply, mi ricordi molto un altro utente di questo forum con un atteggiamento simile...

ekerazha

23-08-2006, 10:14

Non ho altri motivi per perdere ulteriore tempo qui.
Chiunque può leggere quello che hai scritto, confrontarlo con il link che ho postato, leggere la tua reazione e dedurre quindi il tuo modo di ragionare.
Concordo... e aggiungo "appurare la realtà dei fatti" (ovvero ATI ed nVidia distribuiscono i loro driver senza alcun problema). E magari leggere la GPL. E magari anche i tuoi evidenti errori concettuali sulla questione della CDDL e del "file-based" ;)

ekerazha

23-08-2006, 10:16

ekerazha

23-08-2006, 10:19

doh, visto che sei tanto sicuro di cio' che dici, prova a scrivere un software che si basa sulle gtk2 e chiudilo (ovviamente devi rilasciarlo, se lo tieni per te non ha senso). vedi che succede...
ad ogni modo, il tuo modo di rispondere e' quantomeno irritante soprattutto quando ti poni verso gli altri in modo arrogante e presuntuoso da signor "sotuttoioevoinonsapeteniente".
io non rispondero' piu' ad un tuo reply, mi ricordi molto un altro utente di questo forum con un atteggiamento simile...
Quando vuoi.
Io rispondo con estrema pacatezza e portando prove tangibili (es. citando la GPL) a sostegno delle mie tesi... se poi mi si vede "arrogante" e "presuntuoso" per il semplice motivo che ho ragione (e questo indubbiamente indispone di volta in volta chi ha torto), purtroppo posso farci ben poco :)

k0nt3

23-08-2006, 10:48

In Linux i driver proprietari di nVidia ed ATI non sono integrati nel kernel originale ma vengono distribuiti autonomamente dai produttori (è eventualmente l'utente che decide di installarli a parte). Certo... più o meno come accade per Windows. I mantainer come già detto decidono cosa includere nel kernel ufficiale, cosa viene rilasciato autonomamente non è di loro competenza (fino a quando questo non viola la licenza... cosa che non accade come già spiegato, perchè altrimenti nVidia e ATI non potrebbero fare quello che invece fanno più che tranquillamente).
Ciao morbido! :asd:

adesso hai rotto! è quello che ho sempre detto per favore non obbligarmi a bestemmiare :muro: i drivers nVidia e ATI li distribuiscono i produttori! non devono avere il consenso dei manteiner... perciò il disastro che succede se i produttori fanno un sacco di moduli proprietari succede anche se i manteiner non lo vogliono (questo nel caso della CDDL perchè la GPL tutela i manteiner). e finiscila di fare il finto tonto

Invece è proprio quello (vedi che lo sai da solo ;) ).
Non è l'inclusione in sè contro la licenza, bensì l'aver distribuito il kernel con incluso codice proprietario (cosa che faceva appunto Kororaa... ovvero un CD con dentro il kernel con i moduli proprietari). Questa è la grande differenza e questo è il perchè Kororaa ha dovuto chiudere baracca mentre nVidia ed ATI (ad esempio) non fanno nulla di illegittimo. ATI e nVidia distribuiscono i loro driver in modo che l'utente possa in un secondo momento installarli ed utilizzarlo e non sono come già detto inclusi nel kernel "originale".

infatti mi chiedevo a cosa servisse la FSF.. forse non fanno altro che chiedere pareri a te per capire come funziona la GPL che hanno scritto loro

Come già detto, se c'erano e non ci sono più li lasci se non causano problemi di forza maggiore, se invece causano problemi li togli e sarebbe come se non ci fossero (ovvero come se non fossero mai stati inclusi). Quindi come vedi alla fine è abbastanza irrilevante.

irrilevante??!! avere una periferica sopra il comodino lo chiami irrilevante?? :muro:

Se una periferica è obsoleta puoi anche cambiarla... il mondo dell'informatica è in continua evoluzione.

il mondo dell'informatica è in continua evoluzione ma non tutti sono obbligati a fare upgrade ogni 2 mesi... comunque questo non c'entra nulla con il nostro discorso che non dipende dall'evoluzione dell'informatica

Un quote fra tanti (se vuoi ce ne sono anche altri):

Se avessi a disposizione il kernel di Windows potrei scendere nei dettagli, il massimo che si può fare è appurare che è un "microkernel modificato" vedendo come vengono gestite alcune cose ed in base alle dichiarazioni Microsoft. Puoi contestare tranquillamente (se ne sei in grado) che Windows NT non abbia nulla a che fare con i microkernel e francamente la cosa mi interesserebbe ben poco dato che non mi interessa proprio difendere Windows. Dico solo che, premettendo che Windows sia un "microkernel" modificato, il linea di principio come ogni buon microkernel è sicuramente più modulare di un kernel monolitico come Linux che di modulare ha ben poco e personalmente non ritengo degno di tale appellativo.

Quindi Linux è meno modulare proprio in quanto kernel monolitico.

ti avevo chiesto di articolare il discorso e non l'hai fatto. continui a sostenere che siccome uno è un "microkernel modificato" (definizione inventata da MS per rendere il nome del kernel più fico) allora è più modulare. sei capace di articolare un discorso? spiegami perchè linux è meno modulare con i fatti e non con l'aria

Infatti nessuno trascorre i pomeriggi davanti al server... è semplicemente una rapida constatazione della realtà. Come già detto... se a qualcuno tra noi due mancano i concetti basilari, ma davvero basilari e lo sta ampiamente dimostrando (ad esempio non sapendo come funziona il mantaining dei kernel o da chi vengono sviluppati... e continuando a perseverare nell'errore) sei proprio tu ;) ). Forse non saranno elencati tutti i server del mondo, ma mi sembra più che indicativo... potrebbero mancare server Linux ma anche Solaris (o sei come il nano che tutte le schede dubbie o disperse sono sue? ;) Spero di no). Se i server Solaris primeggiano mi sembra un'evidenza oggettiva che siano davvero stabili.

ah finalmente hai capito cosa significa empirico e almeno quello non lo contesti... ti ho già detto che se vuoi parlare di fatti oggettivi (cioè ragionamenti sull'architettura dei due sistemi operativi allo scopo di capire perchè uno dovrebbe essere più sicuro e stabile del'altro) ne possiamo parlare... se continui a postare elenchi di numeri non aspettarti un discorso costruttivo

Uh... forse finalmente hai capito che i driver proprietari non sono inclusi nel kernel "ufficiale" ma possono essere installati in un secondo tempo dagli utenti. Spero sia la volta buona...

io l'ho sempre saputo e infatti non ho mai detto il contrario. non mettermi in bocca cose che non dico

Anche con OpenSolaris sono di tutti e rimarranno per sempre di tutti :rolleyes: Il codice è disponibile...
giusto! però poi il codice se lo pappa SUN come se lo sono pappati da bsd a suo tempo (ma non era SUN)

k0nt3

23-08-2006, 10:49

ekerazha

23-08-2006, 11:32

io non chiudo un bel niente.. finchè spari stronx@te continuo a risponderti
Ahah... va bene... questo therad potrebbe diventare moooolto lungo allora.

ekerazha

23-08-2006, 11:33

adesso hai rotto! è quello che ho sempre detto per favore non obbligarmi a bestemmiare :muro: i drivers nVidia e ATI li distribuiscono i produttori! non devono avere il consenso dei manteiner... perciò il disastro che succede se i produttori fanno un sacco di moduli proprietari succede anche se i manteiner non lo vogliono (questo nel caso della CDDL perchè la GPL tutela i manteiner). e finiscila di fare il finto tonto

:asd: :asd: :asd: Va bene... allora ti cito una tua risposta dopo che vanamente ho sempre tentato di fartelo capire:

abbiamo già constatato che questo discorso è assolutamente insensato.
se non metterai mai drivers chiusi nel kernel cosa lo permetti a fare? in questo modo permetti agli altri di farlo e anche se tu hai buon senso te la mettono nel :ciapet:
poi se i produttori di hardware fossero obbligati a fare drivers opensource non ci sarebbe nessun problema di compatibilità anche dopo la patch.

Qui sostieni che qualcuno può inserire driver proprietari nel kernel senza il consenso del mantainer.

Allora siccome mi sono rotto di essere preso per i fondelli, cercherò di ricapitolare il tutto in maniera schematica e speriamo che sia la volta buona:

Caso GPL:
#1 Non si possono distribuire driver proprietari inseriti all'interno del kernel GPL.
#2 Si possono distribuire driver proprietari a parte, come fanno senza alcun problema ATI e nVidia.
#3 Tizio (ad esempio) crea un fork del progetto perchè vuole apportare miglioramenti alle interfacce e rompe la compatibilità con il kernel GPL "ufficiale".
#4 L'utente finale si installa il kernel ufficiale e poi si installa i driver proprietari per i fatti suoi oppure si installa il kernel forkato... è una sua scelta ed è felice e contento.

Caso CDDL:
#1 Si possono distribuire driver proprietari inseriti all'interno del kernel CDDL, ma è una scelta dei mantainer del kernel.
#2 Tizio vede che i mantainer del kernel ufficiale *non* vogliono inserire driver proprietari all'interno del kernel [è una legittima scelta... anche se sto notando che a te piace scegliere per gli altri... vedi cosa del kernel Mach] e crea un fork del progetto dove fa quello che meglio crede... a questo punto col suo progetto sono fatti suoi.
#3 L'utente finale sceglie se installare il kernel CDDL "ufficiale" e poi installarsi i driver proprietari oppure se installare il kernel forkato... è una sua scelta ed è felice e contento.

E' chiaro ora? Speriamo.

infatti mi chiedevo a cosa servisse la FSF.. forse non fanno altro che chiedere pareri a te per capire come funziona la GPL che hanno scritto loro

Ripeto (dato che il tuo livello di polemica infantile non merita una nuova risposta): Non è l'inclusione in sè contro la licenza, bensì l'aver distribuito il kernel con incluso codice proprietario (cosa che faceva appunto Kororaa... ovvero un CD con dentro il kernel con i moduli proprietari). Questa è la grande differenza e questo è il perchè Kororaa ha dovuto chiudere baracca mentre nVidia ed ATI (ad esempio) non fanno nulla di illegittimo. ATI e nVidia distribuiscono i loro driver in modo che l'utente possa in un secondo momento installarli ed utilizzarlo e non sono come già detto inclusi nel kernel "originale".

Ora devi ancora spiegarmi come mai nVidia ed ATI rilasciano tranquillamente i loro driver proprietari "se non possono" e "se è dannoso", dato che ne sono a conoscenza sia la FSF che i mantainer del kernel ;)

irrilevante??!! avere una periferica sopra il comodino lo chiami irrilevante?? :muro:

Non hai capito il contesto, ripeto: Come già detto, se c'erano e non ci sono più li lasci se non causano problemi di forza maggiore, se invece causano problemi li togli e sarebbe come se non ci fossero (ovvero come se non fossero mai stati inclusi). Quindi come vedi alla fine è abbastanza irrilevante.

Irrilevante la differenza fra le due situazioni rilevate, non "che la periferica stia sul comodino". In ogni caso se è obsoleta direi che può starci tranquillamente, ma questo è un altro discorso.

il mondo dell'informatica è in continua evoluzione ma non tutti sono obbligati a fare upgrade ogni 2 mesi... comunque questo non c'entra nulla con il nostro discorso che non dipende dall'evoluzione dell'informatica

Citami qualche azienda che rilasciava driver proprietari per Linux e che poi è fallita e non ha più rilasciato driver, con successivo enorme scontento di tutti gli utenti e loro grave danno economico (es. era una periferica di ultimo grido appena acqusitata) facciamo nell'ultimo anno quindi essendo "ogni 2 mesi" me ne aspetto circa 6.

:asd:

ti avevo chiesto di articolare il discorso e non l'hai fatto. continui a sostenere che siccome uno è un "microkernel modificato" (definizione inventata da MS per rendere il nome del kernel più fico) allora è più modulare. sei capace di articolare un discorso? spiegami perchè linux è meno modulare con i fatti e non con l'aria

Come già detto il fatto che sia un kernel monolitico (se sai cosa significa) lo rende gran poco modulare e questo è un assioma. Poi volendo posso anche scendere un po' nei dettagli (es. quasi tutto il codice per la gestione di determinate cose, come il filesystem, la memoria centrale, gli interrupt ecc. vengono gestiti in kernel mode), mentre dall'altra parte le tue argomentazioni si articolano sul fatto che "Windows crasha e Linux no" :rolleyes:

ah finalmente hai capito cosa significa empirico e almeno quello non lo contesti... ti ho già detto che se vuoi parlare di fatti oggettivi (cioè ragionamenti sull'architettura dei due sistemi operativi allo scopo di capire perchè uno dovrebbe essere più sicuro e stabile del'altro) ne possiamo parlare... se continui a postare elenchi di numeri non aspettarti un discorso costruttivo

Che sia più stabile è un'evidenza oggettiva e direi non contestabile (ne hai la prova nei fatti). I motivi potrebbe essere i più disparati, probabilmente una maggiore cura nello sviluppo di un gran numero di componenti su centinaia di migliaia di righe di codice... o credi che ci sia la funzione "stabilizzaCodice(1)"?

giusto! però poi il codice se lo pappa SUN come se lo sono pappati da bsd a suo tempo (ma non era SUN)
Può papparsi quello che vuole... a me OpenSolaris rimane ;) e chissà... magari un giorno potrò sviluppare anch'io un sistema operativo basato su OpenSolaris e venderlo :asd: In questo modo i miei sforzi potrebbero anche risultare redditizzi (visto che bisogna tirare avanti la baracca).
Edit: Ah... e risottolineo che ogni eventuale miglioramento apportato da Sun è costretta (per la CDDL) a restituirlo nel progetto opensource ;)

;)

k0nt3

23-08-2006, 11:57

:asd: :asd: :asd: Va bene... allora ti cito una tua risposta dopo che vanamente ho sempre tentato di fartelo capire:
non dire stupidate

abbiamo già constatato che questo discorso è assolutamente insensato.
se non metterai mai drivers chiusi nel kernel cosa lo permetti a fare? in questo modo permetti agli altri di farlo e anche se tu hai buon senso te la mettono nel :ciapet:
poi se i produttori di hardware fossero obbligati a fare drivers opensource non ci sarebbe nessun problema di compatibilità anche dopo la patch.

Qui sostieni che qualcuno può inserire driver proprietari nel kernel senza il consenso del mantainer.

esatto! i produttori di hardware fanno i moduli e gli utenti li installano. ho per caso detto che sono i manteiner a inserire i moduli closed source? questo l'hai inventato te :rolleyes:

Caso GPL:
#1 Non si possono distribuire driver proprietari inseriti all'interno del kernel GPL.
sbagliato! non si possono distribuire moduli proprietari punto e basta

#2 Si possono distribuire driver proprietari a parte, come fanno senza alcun problema ATI e nVidia.

il fatto che si chiude un occhio non vuol dire che il problema non c'è

#3 Tizio (ad esempio) crea un fork del progetto perchè vuole apportare miglioramenti alle interfacce e rompe la compatibilità con il kernel GPL "ufficiale".

tizio è un imbecille perchè crea del codice rotto di proposito.. se cambia le interfaccie deve cambiare anche i drivers perchè sono TUTTI opensource e può farlo.

#4 L'utente finale si installa il kernel ufficiale e poi si installa i driver proprietari per i fatti suoi oppure si installa il kernel forkato... è una sua scelta ed è felice e contento.

il kernel forkato è solo prodotto della tua fantasia

Caso CDDL:
#1 Si possono distribuire driver proprietari inseriti all'interno del kernel CDDL, ma è una scelta dei mantainer del kernel.

NO! è una scelta dei produttori di hardware come ho già spiegato e come anche tu hai convenuto poco fa

#2 Tizio vede che i mantainer del kernel ufficiale *non* vogliono inserire driver proprietari all'interno del kernel [è una legittima scelta... anche se sto notando che a te piace scegliere per gli altri... vedi cosa del kernel Mach] e crea un fork del progetto dove fa quello che meglio crede... a questo punto col suo progetto sono fatti suoi.

non c'è bisogno che forka il kernel. distribuisce i drivers come si fa con windows e come fanno ati e nVidia per linux. e poi sono io che non la voglio capire? :confused:

#3 L'utente finale sceglie se installare il kernel CDDL "ufficiale" e poi installarsi i driver proprietari oppure se installare il kernel forkato... è una sua scelta ed è felice e contento.

E' chiaro ora? Speriamo.

ancora una volta hai introdotto un fantomatico kernel forkato che è frutto della tua fantasia

Ripeto (dato che il tuo livello di polemica infantile non merita una nuova risposta): Non è l'inclusione in sè contro la licenza, bensì l'aver distribuito il kernel con incluso codice proprietario (cosa che faceva appunto Kororaa... ovvero un CD con dentro il kernel con i moduli proprietari). Questa è la grande differenza e questo è il perchè Kororaa ha dovuto chiudere baracca mentre nVidia ed ATI (ad esempio) non fanno nulla di illegittimo. ATI e nVidia distribuiscono i loro driver in modo che l'utente possa in un secondo momento installarli ed utilizzarlo e non sono come già detto inclusi nel kernel "originale".

non possono chiudere con ATI e nVidia perchè rappresentano il 99% del mercato delle schede video. semplicemente chiudono un occhio e cercano il dialogo.
ripeto: distribuire moduli closed source per linux è contro la licenza

Ora devi ancora spiegarmi come mai nVidia ed ATI rilasciano tranquillamente i loro driver proprietari "se non possono" e "se è dannoso", dato che ne sono a conoscenza sia la FSF che i mantainer del kernel ;)

vedi sopra

Non hai capito il contesto, ripeto: Come già detto, se c'erano e non ci sono più li lasci se non causano problemi di forza maggiore, se invece causano problemi li togli e sarebbe come se non ci fossero (ovvero come se non fossero mai stati inclusi). Quindi come vedi alla fine è abbastanza irrilevante.

non è irrilevante! se fossero opensource i drivers il problema non sussiste. su linux è così! ti ripeto.. dovrebbero mettere la brodaglia closed in userspace e risolvono tutti i problemi (compreso questo)

Irrilevante la differenza fra le due situazioni rilevate, non "che la periferica stia sul comodino". In ogni caso se è obsoleta direi che può starci tranquillamente, ma questo è un altro discorso.

chi ha detto che è obsoleta! la voodoo5 non era obsoleta quando è cessato il supporto. e poi il nostro discorso è indipendente dall'obsolescenza dell'oggetto in questione, parte più a monte.

Citami qualche azienda che rilasciava driver proprietari per Linux e che poi è fallita e non ha più rilasciato driver, con successivo enorme scontento di tutti gli utenti e loro grave danno economico (es. era una periferica di ultimo grido appena acqusitata) facciamo nell'ultimo anno quindi essendo "ogni 2 mesi" me ne aspetto circa 6.

il fatto che fino ad oggi non ci sono state non ci dice niente riguardo al futuro.

Come già detto il fatto che sia un kernel monolitico (se sai cosa significa) lo rende gran poco modulare e questo è un assioma. Poi volendo posso anche scendere un po' nei dettagli (es. quasi tutto il codice per la gestione di determinate cose, come il filesystem, la memoria centrale, gli interrupt ecc. vengono gestiti in kernel mode), mentre dall'altra parte le tue argomentazioni si articolano sul fatto che "Windows crasha e Linux no" :rolleyes:

sarà un assioma per te, ma per il resto del mondo non lo è affatto. comunque voglio darti un input: http://fuse.sourceforge.net/
se vuoi altre argomentazioni che testimoniano che windows non ha un kernel così superiore a linux nota che quando lo installi devi riavviare come minimo 10 volte.

Che sia più stabile è un'evidenza oggettiva e direi non contestabile (ne hai la prova nei fatti). I motivi potrebbe essere i più disparati, probabilmente una maggiore cura nello sviluppo di un gran numero di componenti su centinaia di migliaia di righe di codice... o credi che ci sia la funzione "stabilizzaCodice(1)"?

potresti parlare della superiorità dell'architettura di solaris ad esempio.. è quello che conta quando si parla di stabilità e sicurezza.
i tuoi dati non li leggo nemmeno perchè l'uptime di un server dipende per il 90% dalle competenze dell'amministratore e non dal SO installato (certo a meno che non si tratti di windows :asd: )

Può papparsi quello che vuole... a me OpenSolaris rimane ;) e chissà... magari un giorno potrò sviluppare anch'io un sistema operativo basato su OpenSolaris e venderlo :asd: In questo modo i miei sforzi potrebbero anche risultare redditizzi (visto che bisogna tirare avanti la baracca).
Edit: Ah... e risottolineo che ogni eventuale miglioramento apportato da Sun è costretta (per la CDDL) a restituirlo nel progetto opensource ;)

e se i miglioramenti sono closed source? cosa se ne fa la comunità di OpenSolaris di un sacco di righe in binario? bel miglioramento