Link alla notizia: http://news.hwupgrade.it/11715.html

Intel ha annunciato che rilascerà i driver da utilizzare su piattaforme Intel Centrino e sistema operativo Linux

Click sul link per visualizzare la notizia.

Una bella notizia per il mondo linux che così può usare al meglio i portatili centrino (come me :D ).

In versione proprietaria non serviranno a nulla...

puoi spiegarti meglio?

...Non li avevano annunciati mesi fa, questi driver?

finalmente! per la prima volta mi sento di dire: Brava intel!

il mio centrino aspetta con ansia:cool:

Secondo me dipende anche dal fatto che se tanta gente passa al pinguino e il loro hardware non è supportato a dovere finiscono per perdere clienti! ;-)
Comunque mi sembra ottimo, anche se rilasciarli "open" sarebbe meglio!
Byez!

Originariamente inviato da LASCO
puoi spiegarti meglio?

ecco cosa succede: intel se la tira ancora per qualche mese, poi forse finalmente rilascia un driver.

solo che il driver sara binario, quindi non potra essere incluso direttamente nel kernel, quindi quando un povero utente linux (che si compra un portatile intel perche adesso ha sentito che ci sono dei driver fatti da intel) si installa una distribuzione scopre che deve collegarsi a internet, pigliare un pacchetto tar.gz, scompattarlo, assicurarsi di avere tutti gli strumenti di sviluppo necessari, assicurarsi di avere gli headers del kernel installati, compilarlo, installarlo, accendere un cero alla madonna e provare a caricarlo, e se ha culo forse funziona, finche non dovra fare un upgrade al kernel, e in quel caso si ricomincia tutto daccapo.
risultato, il 100% degli utenti non esperti (e una bella fetta anche di quelli esperti) non riuscira a (o si rifiutera di) fare sta procedura, comincera a lamentarsi a destra e a sinistra che linux e' troppo difficile da usare, che non e' pronto per il desktop, ecc... tutta roba gia successa un milione di volte, e che grazie a sta stronzata succedera ancora di piu in futuro.

se invece intel rilasciasse i sorgenti completi del driver con una licenza libera, questi potrebbero essere inclusi nel kernel, e tanti saluti ai problemi: installi qualsiasi distro con qualsiasi kernel e funziona sempre senza fare niente. questo tralasciando l'enorme vantaggio della manutenzione distribuita del driver e altre cosine.

ci sono anche delle vie di mezzo a queste 2 possibilita, ad esempio intel potrebbe rilasciare un driver binario con una licenza molto permissiva quanto alla redistribuzione, forse permettendo ad alcune distro di includere il driver sui loro cd, ma questa NON E' una soluzione buona a lungo termine, anzi, sarebbe devastante se con l'andare del tempo tutti cominciassero a comportarsi cosi. speriamo non succeda.



ma perche intel non rilascia subito un driver con sorgenti liberi? la risposta che ottieni da loro e' che hanno paura di perdere la loro "proprieta intellettuale"...

non so come diavolo intel progetti i propri chip, ma sembra che qualcun altro, nonostante non abbia le straordinarie risorse economiche e progettuali di intel non abbia alcun problema a rilasciare i propri driver per wlan come software libero, ad enorme vantaggio dei propri utenti:
http://www.prism54.org/

quindi per me sono BALLE. balle corroborate dal fatto che gia in passato intel avesse rilasciato dei driver non liberi salvo poi cambiare idea (esempio, schede di rete intel etherexpress 100 pro), anche perche tutti le stavano gia usando grazie a driver liberi scritti da qualcun altro in modo indipendente.
che "proprieta intellettuale" c'era da proteggere allora?
altre aziende si comportano in modo analogamente inspiegabile, ad esempio nvidia che si rifiuta di rilasciare i sorgenti per fare andare la dannata scheda di rete del chipset nforce, cosi qualcuno ha preso e si e' arrangiato a scriverselo:
http://www.hailfinger.org/carldani/linux/patches/forcedeth/
avranno protetto bene la loro "proprieta intellettuale" in questo modo?
canon che si rifiuta di spiegare al mondo come funzionano i loro scanner, cosi ci deve pensare un russo che si costruisce uno sdoppiatore di porta parallela, si stampa il grafico di tutti segnali elettrici e poi va a interpretarli a occhio:
http://canon-fb330p.sourceforge.net/
l'unico effetto raggiunto dal negare le specifiche degli scanner ai propri utenti e' stato fare perdere un sacco di tempo ai propri clienti (tra cui io), altro che "proprieta intellettuale".
lexmark che per le stampanti z23-z33 ha prodotto solo un vergognoso driver binario. spero abbiano protetto bene la loro "proprieta intellettuale", certo che e' strano che epson non si faccia il minimo problema a rilasciare le specifiche a chiunque, cosi TUTTE le loro stampanti e scanner sono supportate da praticamente TUTTI i sistemi operativi, pur producendo stampanti ugualmente economiche, e senza avere bisogno di fare causa ai produttori di cartucce compatibili invocando leggi ridicole come il DMCA.

ora, se anche fosse vero che rilasciando driver liberi offrirebbero informazioni troppo importanti ai loro possibili concorrenti, sarebbe lecito aspettarsi che imparata la lezione intel le prossime schede le progetti in modo che poi sia possibile rilasciare driver liberi per facilitare la vita ai propri utenti, invece ci tocca sentire ste dichiarazioni:

"What I believe will happen is we will end up having a Linux compatibility driver that is not open source at first, then designing future drivers in such a way that they are open source but will not expose intellectual property,"

ci sono diverse possibilita per cercare spiegare ste dichiarazioni, ma poche sono sensate:
1) sono false, ma spero non mentano cosi spudoratamente
2) la scrittura di driver liberi non rivelerebbe in alcun modo il design dell'hardware sottostante, tanto che ne e' possibile il rilascio di una versione libera da parte di intel stessa. ma allora potrebbero fin da subito rilasciare le specifiche dell'hardware, cosa che non fanno.
3) il tizio ha sbagliato e avrebbe dovuto dire: "then designing future HARDWARE in such a way that they are open source but will not expose intellectual property", e speriamo tanto di si, ma ho l'impressione che non si fosse sbagliato in questo senso.

tirando le somme non c'e alcun motivo logico per cui intel non possa svegliarsi e supportare la comunita opensource come questa merita (perche intel di soldoni anche con linux ne fa tanti) quindi io mi trattengo bene dal dire "brava intel". intel sara brava quando fara il suo dannato lavoro e ci dara dei driver decenti o almeno la possibilita di scriverne di decenti da soli.

30 e lode!

Originariamente inviato da joe4th
30 e lode!
non tanto. ho citato erroneamente i driver prism 802.11g invece di quelli oricono per 802.11b, e vedo adesso che richiedono utilizzo di un firmware. e' tendenza sempre piu comune usare un firmware in un dispositivo hardware, molti scanner funzionano cosi, alcune schede di cattura video, tutti i modem adsl usb, e vari altri.
bisognerebbe cercare di capire se l'uso di firmware puo essere un problema o no. di sicuro lo e' quando il firmware viene rilasciato con una licenza che non ne permette la redistribuzione. se invece il firmware me lo lasciano distribuire assieme al driver, beh, non so... almeno verrebbe preservata la facilita di installazione, e credo anche l'indipendenza dal sistema operativo e dall'architettura del processore (ad esempio il firmware di uno scanner lo puoi usare sia con linux che con freebsd, e mi pare sia su i386 che su ia64/ppc.). per quanto riguarda gli altri aspetti ci si puo convivere?

X qweasdzxc:

Secondo te quindi il lavoro dei progettisti non vale nulla. Lo dici chiaramente quando pretendi che ti venga detto come funzionano le cose, dicendo continuamente che tanto non c'è nessuna proprietà intellettuale.

Mi viene sempre un gran magone quando leggo di persone divenute schiave del software libero.

Originariamente inviato da Monoaural
Secondo te quindi il lavoro dei progettisti non vale nulla. Lo dici chiaramente quando pretendi che ti venga detto come funzionano le cose, dicendo continuamente che tanto non c'è nessuna proprietà intellettuale.

Abbiamo letto lo stesso messaggio?


Mi viene sempre un gran magone quando leggo di persone divenute schiave del software libero.

Ah, ho capito. Scusate la tardezza, sara` colpa dell'eccessivo consumo di sw libero.
:muro:

Originariamente inviato da qweasdzxc
ecco cosa succede: intel se la tira ancora per qualche mese, poi forse finalmente rilascia un driver.

solo che il driver sara binario, quindi non potra essere incluso direttamente nel kernel, quindi quando un povero utente linux (che si compra un portatile intel perche adesso ha sentito che ci sono dei driver fatti da intel) si installa una distribuzione scopre che deve collegarsi a internet, pigliare un pacchetto tar.gz, scompattarlo, assicurarsi di avere tutti gli strumenti di sviluppo necessari, assicurarsi di avere gli headers del kernel installati, compilarlo, installarlo, accendere un cero alla madonna e provare a caricarlo, e se ha culo forse funziona, finche non dovra fare un upgrade al kernel, e in quel caso si ricomincia tutto daccapo.
risultato, il 100% degli utenti non esperti (e una bella fetta anche di quelli esperti) non riuscira a (o si rifiutera di) fare sta procedura, comincera a lamentarsi a destra e a sinistra che linux e' troppo difficile da usare, che non e' pronto per il desktop, ecc... tutta roba gia successa un milione di volte, e che grazie a sta stronzata succedera ancora di piu in futuro.

se invece intel rilasciasse i sorgenti completi del driver con una licenza libera, questi potrebbero essere inclusi nel kernel, e tanti saluti ai problemi: installi qualsiasi distro con qualsiasi kernel e funziona sempre senza fare niente. questo tralasciando l'enorme vantaggio della manutenzione distribuita del driver e altre cosine.

ci sono anche delle vie di mezzo a queste 2 possibilita, ad esempio intel potrebbe rilasciare un driver binario con una licenza molto permissiva quanto alla redistribuzione, forse permettendo ad alcune distro di includere il driver sui loro cd, ma questa NON E' una soluzione buona a lungo termine, anzi, sarebbe devastante se con l'andare del tempo tutti cominciassero a comportarsi cosi. speriamo non succeda.



ma perche intel non rilascia subito un driver con sorgenti liberi? la risposta che ottieni da loro e' che hanno paura di perdere la loro "proprieta intellettuale"...

non so come diavolo intel progetti i propri chip, ma sembra che qualcun altro, nonostante non abbia le straordinarie risorse economiche e progettuali di intel non abbia alcun problema a rilasciare i propri driver per wlan come software libero, ad enorme vantaggio dei propri utenti:
http://www.prism54.org/

quindi per me sono BALLE. balle corroborate dal fatto che gia in passato intel avesse rilasciato dei driver non liberi salvo poi cambiare idea (esempio, schede di rete intel etherexpress 100 pro), anche perche tutti le stavano gia usando grazie a driver liberi scritti da qualcun altro in modo indipendente.
che "proprieta intellettuale" c'era da proteggere allora?
altre aziende si comportano in modo analogamente inspiegabile, ad esempio nvidia che si rifiuta di rilasciare i sorgenti per fare andare la dannata scheda di rete del chipset nforce, cosi qualcuno ha preso e si e' arrangiato a scriverselo:
http://www.hailfinger.org/carldani/linux/patches/forcedeth/
avranno protetto bene la loro "proprieta intellettuale" in questo modo?
canon che si rifiuta di spiegare al mondo come funzionano i loro scanner, cosi ci deve pensare un russo che si costruisce uno sdoppiatore di porta parallela, si stampa il grafico di tutti segnali elettrici e poi va a interpretarli a occhio:
http://canon-fb330p.sourceforge.net/
l'unico effetto raggiunto dal negare le specifiche degli scanner ai propri utenti e' stato fare perdere un sacco di tempo ai propri clienti (tra cui io), altro che "proprieta intellettuale".
lexmark che per le stampanti z23-z33 ha prodotto solo un vergognoso driver binario. spero abbiano protetto bene la loro "proprieta intellettuale", certo che e' strano che epson non si faccia il minimo problema a rilasciare le specifiche a chiunque, cosi TUTTE le loro stampanti e scanner sono supportate da praticamente TUTTI i sistemi operativi, pur producendo stampanti ugualmente economiche, e senza avere bisogno di fare causa ai produttori di cartucce compatibili invocando leggi ridicole come il DMCA.

ora, se anche fosse vero che rilasciando driver liberi offrirebbero informazioni troppo importanti ai loro possibili concorrenti, sarebbe lecito aspettarsi che imparata la lezione intel le prossime schede le progetti in modo che poi sia possibile rilasciare driver liberi per facilitare la vita ai propri utenti, invece ci tocca sentire ste dichiarazioni:

"What I believe will happen is we will end up having a Linux compatibility driver that is not open source at first, then designing future drivers in such a way that they are open source but will not expose intellectual property,"

ci sono diverse possibilita per cercare spiegare ste dichiarazioni, ma poche sono sensate:
1) sono false, ma spero non mentano cosi spudoratamente
2) la scrittura di driver liberi non rivelerebbe in alcun modo il design dell'hardware sottostante, tanto che ne e' possibile il rilascio di una versione libera da parte di intel stessa. ma allora potrebbero fin da subito rilasciare le specifiche dell'hardware, cosa che non fanno.
3) il tizio ha sbagliato e avrebbe dovuto dire: "then designing future HARDWARE in such a way that they are open source but will not expose intellectual property", e speriamo tanto di si, ma ho l'impressione che non si fosse sbagliato in questo senso.

tirando le somme non c'e alcun motivo logico per cui intel non possa svegliarsi e supportare la comunita opensource come questa merita (perche intel di soldoni anche con linux ne fa tanti) quindi io mi trattengo bene dal dire "brava intel". intel sara brava quando fara il suo dannato lavoro e ci dara dei driver decenti o almeno la possibilita di scriverne di decenti da soli.
beh, sinceramente a me basta che funzioni :O

insomma... meglio se rilasciano i sorgenti, ma non urliamo all'uomo nero tutte le volte che una casa non rilascia i sorgenti... io ho un portatile centrino e sono strafelice che mi venga fatto il driver per linux. se è libero è meglio, se invece alla intel hanno deciso di non farlo avranno avuto i loro bravi motivi (economici certo...)

lo so che per noi è meglio che sia tutto libero, open, utilizzabile da chiunque, ma se uno decide di farsi il software proprietario sembra che sia un bastardo... e che palle... :rolleyes:

PS: bruciamo la ATi e la intel uno di questi giorni, visto che rilasciano driver senza licenza GPL?
pensiamo invece cosa sarebbe adesso il panorama dei pc senza ati e intel...

ve lo dice uno che ha un athlon nel pc di casa...


altrimenti muniamoci di qualche pezzo elettronico e di un saldatore e costruiamocele noi le nostre periferiche... d'altronde se mi compro lo scanner se uso linux ci penso un po' prima di sceglierlo, quantomeno guardo se è supportato, altrimenti me le vado a cercare, non credete?
uno si progetta un hw ha tutto il diritto di metterci la licenza che vuole. meglio per noi se open, ma se non è open non mi pare il caso di condannarlo

Originariamente inviato da Monoaural
X qweasdzxc:

Secondo te quindi il lavoro dei progettisti non vale nulla.

cosa hai letto finora? topolino?

Lo dici chiaramente quando pretendi che ti venga detto come funzionano le cose
ma certo che lo pretendo... l'ho pagato l'hardware? avro anche il diritto di farlo funzionare come diavolo preferisco no?

dicendo continuamente che tanto non c'è nessuna proprietà intellettuale.

c'e chi pensa che "proprieta intellettuale" sia un ossimoro, una contraddizione in termini. non mi sento di dargli torto. ma non e' questo il punto. il punto e' che, proprieta intellettuale o meno, e' possibile progettare hardware e al tempo stesso trattare con rispetto i propri clienti.
l'unico motivo per cui molte aziende riescono ad avere successo pur non rispettando i clienti e' che i loro utenti non se ne rendono conto.
mi piacerebbe che un bel po di gente si svegliasse.
tu ad esempio potrai anche non usare mai una riga di software libero in tutta la tua vita (in realta probabilmente ne stai gia usando piu di quanto immagini), ma otterrai comunque enormi vantaggi dalla semplice esistenza del software libero per il semplice motivo che e' l'unico tipo di concorrenza possibile per certe tipologie di software commerciale, quindi qualsiasi cosa vada a scapito della diffusione del software libero e' un danno anche per te, che vedrai il tuo software commerciale costare di piu e migliorare poco nel corso del tempo.
apparecchi hardware molto diffusi che non possono essere utilizzati che con 1 sistema operativo a causa dell'ottusita del produttore danneggiano la diffusione di tutti gli altri sistemi operativi, e a lungo termine danneggiano anche gli utenti di quell'unico sistema operativo.
motivo per il quale inaspettatamente anche agli utenti windows converrebbe valutare con piu attenzione i propri acquisti (perche qua si vota coi soldi...) e firmare petizioni come questa:
http://www.petitiononline.com/xanthan/petition.html

Mi viene sempre un gran magone quando leggo di persone divenute schiave del software libero.

schiavo io? vediamo:

1) se usi software libero in qualsiasi momento puoi decidere di smettere di farlo e di usare software proprietario: i formati dei files sono aperti, non ci sono brevetti ridicoli, i driver sono portabili, le applicazioni multipiattaforma, ecc...
2) se usi software proprietario NON sei libero in qualsiasi momento di cominciare a usare software libero, perche di solito stai usando formati di files chiusi, devi lottare contro i brevetti, non ci sono driver portabili, le applicazioni girano solo dove decidono i capi, ecc...

io preferisco usare 1), e il magone viene a me quando qualcuno preferisce coscientemente usare 2) pur conoscendo tutti i vantaggi di 1) (che sono molti di piu di quelli elencati).

Originariamente inviato da qweasdzxc
ma certo che lo pretendo... l'ho pagato l'hardware? avro anche il diritto di farlo funzionare come diavolo preferisco no?

certo, infatti intel ha fatto il driver anche per linux in modo che tu possa utilizzare il suo prodotto anche sul nostro sistema preferito :)

sputaci in faccia...

lo so che per noi è meglio che sia tutto libero, open, utilizzabile da chiunque, ma se uno decide di farsi il software proprietario sembra che sia un bastardo... e che palle...

ci sono un sacco di rispettabilissime software house che producono software proprietario guadagnandoci soldoni e non mi permetterei di chiamarle bastarde. ma qui stiamo parlando di hardware. stiamo parlando di driver. stiamo parlando della scheda di rete wireless piu diffusa al mondo. e' diverso.

PS: bruciamo la ATi e la intel uno di questi giorni, visto che rilasciano driver senza licenza GPL?

per i driver meglio una licenza meno restrittiva se possibile. in ogni caso non serve bruciare ati o intel. basterebbe che nessuno comprasse hardware non dotato di specifiche.

pensiamo invece cosa sarebbe adesso il panorama dei pc senza ati e intel...

perche? ati fino alle ati radeon r200 almeno collaborava in qualche modo con il progetto dri = supporto 3d nativo in tutte le distribuzioni di xfree. mi andava benone. intel ha sicuramente contribuito in molti modi positivi a linux. questo non mi impedisce di criticare una azienda quando fa qualcosa di sbagliato no? disgraziatamente ati ha deciso di seguire nvidia con i driver proprietari, chissa, forse perche ha visto che nessuno o pochi si lamentavano del fatto che i driver non erano liberi, e allora tanto valeva smetterla di collaborare con xfree. quindi il 3d con soli driver liberi ce lo siamo giocato per i prossimi 10 anni. sta succedendo la stessa cosa con 802.11g.

altrimenti muniamoci di qualche pezzo elettronico e di un saldatore e costruiamocele noi le nostre periferiche...

nel caso di stampanti e scanner basta comprare da qualche ditta seria.

d'altronde se mi compro lo scanner se uso linux ci penso un po' prima di sceglierlo, quantomeno guardo se è supportato, altrimenti me le vado a cercare, non credete?

diciamo che va bene, questo e' comunque un problema per tutti quelli che lo scanner (o altre periferiche) ce l'hanno gia.
ma per le schede 802.11g non si puo. quelle che si trovano in giro non sono supportate o lo sono in modo indegno, e non si puo scegliere.

uno si progetta un hw ha tutto il diritto di metterci la licenza che vuole.
meglio per noi se open, ma se non è open non mi pare il caso di condannarlo
non capisco perche no. critico eccome la scelta di intel di non rilasciare le specifiche ed eventualmente driver liberi. e ne ho spiegato abbondantemente le ragioni. mica sto condannando l'intera esistenza di intel.
lo faccio qua soprattutto nella speranza che qualcuno possa capire perche non e' una cosa tanto positiva. altrimenti appena esce il driver un sacco di gente col centrino convinta di trovare un buon supporto si scarica la prima distro che trova, la installa, scopre che far funzionare la wlan e' una operazione al di fuori della loro portata di neoutenti, disinstalla la distribuzione, va a infestare i forum di mezza italia con discorsi tipo: "e' troppo difficile, non e' pronto per il desktop", torna a windows e non prova mai piu un qualsiasi sistema operativo libero.

Originariamente inviato da Leron
certo, infatti intel ha fatto il driver anche per linux in modo che tu possa utilizzare il suo prodotto anche sul nostro sistema preferito :)

sputaci in faccia...

1) ho scritto "nel modo che preferisco". non "nel sistema operativo che preferisco". e comunque esistono moltissimi esempi di hardware con un driver binario che a detta del produttore funzionano benone su linux ma a casa mia li posso usare al piu come fermacarte.
2) non ha fatto niente ancora. e' 1 anno che dicono che ce l'hanno pronto quel driver. potevano rilasciarlo mesi fa.
3) ci sputo sopra, esatto. non ho mai chiesto un driver proprietario. non mi serve. non lo voglio. fa piu male che bene. tra l'altro proprietario per proprietario puoi gia usare l'ndis wrapper coi driver per windows... l'hai gia provato?

Originariamente inviato da qweasdzxc
tra l'altro proprietario per proprietario puoi gia usare l'ndis wrapper coi driver per windows... l'hai gia provato?
non è quello che dura un mese e poi bisogna pagarlo? :confused:
altrimenti mi dareti qualche info in più? :)

cmq sono concezioni diverse. a me la scheda wireless serve per andare in wireless, se tu la vuoi usare come stampante non so cosa farci :D, e mi complimento con intel perchè lei, a differenza di altri, il driver per linux lo ha fatto :) peccato che non sia gpl, ma almeno lo ha fatto

il tuo commento è assolutamente giusto e plausibile, ma mi incazzerei prima con chi non li fa proprio i driver per linux più che con chi òi fa e non li rende pubblici :)

Hehehe...

ho taciuto fino ad ora... ma dopo aver letto tutti i post avrei qualche cosa da ridire:

Questa è un argomento sul quale ci siamo scannati poco tempo fa. Io avevo "predetto" che aumentando la richiesta per sistemi Linux, alla fine la Intel li avrebbe tirati fuori sti benedetti drivers, se non per altro, per poter vendere più schede (chip, o sistemi centrino completi) possibile.

Mi è stato fatto però notare che non è il mercato (chi acquista e chi vende) che guida le scelte commerciali (cosa vendere, come vendere, in che modo, etc etc), ma sono proprio le scelte più o meno politiche delle aziende (intel in questo caso) che guidano il mercato.

Adesso che però la Intel sta per distribuire (finalmente?) ciò che tanti utenti da tempo richiedono, ecco che si inizia a criticare...

Bò... secondo me è ipocrisia.

Chico

Originariamente inviato da Gundam766
Hehehe...


che ridere vero?


Adesso che però la Intel sta per distribuire (finalmente?) ciò che tanti utenti da tempo richiedono, ecco che si inizia a criticare...

Bò... secondo me è ipocrisia.

Chico
io (e non solo io) non ho mai chiesto driver proprietari. non sono forse libero di criticare senza che mi si dia dell'ipocrita?

Originariamente inviato da qweasdzxc
che ridere vero?


io (e non solo io) non ho mai chiesto driver proprietari. non sono forse libero di criticare senza che mi si dia dell'ipocrita?
non credo proprio sia un'offesa intenzionale ;)

quello che vuole dire probabilmente è:

critichiamo chi non fa i driver perchè non li fa, quando invece comincia a farli li critichiamo perchè non li fa open

io ringrazierei perchè li ha fatti invece...

oltretutto hanno anche detto che forse li faranno pure open....

insomma... se non per accendere flame i tuoi commenti mi paiono fuori luogo in questo thread :)

mi incazzerei per chi continua a non farli i driver per linux invece

Facile...

Intel ha fatto i driver per un sistema operativo poco usato (e non venirmi a dire che Linux è usato da più del 10% degli utenti... essendo molto ottimisti), e subito a tirare giù anatemi!

Ripeto il concetto di prima: quando Intel si accorgerà che più utenti chiederanno driver non proprietari, molto ptobabilmente li faranno. Potenza del mercato.

Io non ti dico che sei un ipocrita... ti dico solo che un atteggiamento del genere è da ipocriti.

Una critica ad una casa produttrice è una cosa (e non fiato su questo), un accanimento è unl'altra.

Chico

P.S. ad ogni modo credo che la maggioranza degli utenti che usa Linux sia abbastanza smaliziata da poter essere in grado di utilizzare tali drivers, visto che non mi pare che la compatibilità tra hadrware e linux sia ampia come quella tra hardware e Windows.

Originariamente inviato da Gundam766


Una critica ad una casa produttrice è una cosa (e non fiato su questo), un accanimento è unl'altra.


è quello che intendo

X Leron

Hai azzeccato in pieno lo spirito del mio post...

Scusate se non mi sono spiegato bene... ma dopo una settimana di lavoro non ce la faccio più e me ne vado al cinema!

Chico

P.S. buon fine settimana a tutti

Io non credo sia un accanimento quello di qweasdzxc, semplicemente tra quello che lui pensava, prima che intel rendesse nota la diffusione di driver proprietari, e quello che pensa adesso non cambia nulla.
Infine credo che si possa essere tutti daccordo sul fatto che qualora la diffusione di driver liberi non rivelasse in alcun modo il design dell'hardware sottostante, ci si dovrebbe aspettare che ciò avvenga.

Un grazie a qweasdzxc per i suoi messaggi puntuali garbati e significativi ed anche a voi altri senza i quali non potevano venire fuori gli aspetti più interessanti della questione driver centrino

Originariamente inviato da Leron
non è quello che dura un mese e poi bisogna pagarlo? :confused:
altrimenti mi dareti qualche info in più? :)


certamente, c'e anche un ndis wrapper sviluppato in modo indipendente rilasciato con licenza gpl. probabilmente e' meno compatibile, o ha piu problemi, o funziona peggio, o e' piu difficile da fare andare, o magari e' anche meglio invece, non so.
lo trovi qua:
http://ndiswrapper.sourceforge.net/
ce n'e anche uno per freebsd avevo letto tempo addietro (o forse e' lo stesso e l'han solo portato)

il problema di questi wrapper e' che alcune aziende li usano come scusa per non sviluppare driver (ne liberi ne proprietari) per linux. sta gia succedendo. ad esempio guardate questo annuncio da parte di 3com:
http://newsvac.newsforge.com/newsvac/03/12/17/1428250.shtml
praticamente il supporto a linux per le loro schede wlan consiste nella frase: "andatevi a comprare il driverloader da linuxant".
almeno questo e' il senso dell'articolo su newsforge, non riesco piu a trovare l'annuncio ufficiale, magari hanno solo sbagliato gli autori dell'articolo.

cmq sono concezioni diverse. a me la scheda wireless serve per andare in wireless, se tu la vuoi usare come stampante non so cosa farci :D

non e' che non voglio driver binari perche voglio usare la scheda di rete come una stampante. e' che se il driver lo avessero rilasciato qualche mese fa probabilmente adesso non potresti passare al kernel 2.6 perche loro non lo supportano ancora. non potresti usare sistemi operativi diversi da linux perche quel driver funziona solo con linux. se il nuovo driver ha un bug che ti da fastidio magari loro ci stanno 4 mesi a correggerlo, sempre se lo correggono. queste sono alcune delle cosine simpatiche che possono succedere, e che sono successe ripetutamente a me con l'unico driver proprietario che disgraziatamente mi capita ancora di usare.
, e mi complimento con intel perchè lei, a differenza di altri, il driver per linux lo ha fatto :) peccato che non sia gpl, ma almeno lo ha fatto

guarda, 6 mesi fa intel ha fatto annunci simili. davvero, e' un anno che dicono che il driver sta per uscire. io mi sentirei preso in giro. magari adesso esce, ma meglio frenare gli entusiasmi, per ora non c'e alcun driver. poi per quanto riguarda gli altri, solo broadcom non ha neanche un driver binario, le prism hanno un driver gpl + firmware, un'altra marca (mi sfugge il nome) ha un driver binario da compilare, e forse c'e un'altra marca ancora con un driver solo binario, ma non sono sicuro.
quindi attualmente intel e' proprio l'ultima ruota del carro per quanto riguarda i driver wlan, con speranza di diventare penultima. un driver binario sarebbe davvero il MINIMO indispensabile, e non mi sentirei di ringraziarli neanche se decidessi di usarlo, anzi resterei arrabbiato perche per 1 anno hanno preso per il culo i propri utenti.

il tuo commento è assolutamente giusto e plausibile, ma mi incazzerei prima con chi non li fa proprio i driver per linux più che con chi òi fa e non li rende pubblici :)

guarda, purtroppo dipende caso per caso.

intanto ripeto, solo intel e broadcom per quanto riguarda l'802.11g non hanno tirato fuori niente. e i chip intel stanno conoscendo una diffusione tale da rappresentare un vero problema per moltissimi utenti. tanto che aziende commerciali hanno investito denaro per offrire ai propri clienti una possibile soluzione, e addirittura dei privati si sono scritti un ndis wrapper da soli. quando si arriva a questo punto mi pare che si sia aspettato un po troppo per meritarsi un ringraziamento dopo aver cacciato fuori i driver.

poi personalmente mi capita spesso di essere danneggiato dall'esistenza di un driver binario piu che dalla sua non esistenza. uno di tanti esempi: mi sono trovato tra le mani un modem intel 56k. ci sono i driver proprietari sul loro sito. ci ho perso mezza giornata per cercare di farli andare, poi mi sono arreso (periodicamente mi capita di voler provare a fare andare qualche caccola di driver binario, i risultati sono sempre sconfortanti). in questo caso se non ci fossero stati per me sarebbe stato oggettivamente meglio, lo buttavo via subito e andavo a comprarne uno seriale. avrei perso meno tempo.

Intel ha fatto i driver per un sistema operativo poco usato (e non venirmi a dire che Linux è usato da più del 10% degli utenti... essendo molto ottimisti), e subito a tirare giù anatemi!

la vediamo diversamente allora... intel non ha ancora fatto un bel niente.
annunci analoghi a questo sono stati fatti nel marzo e nell'ottobre scorsi, anche in quei casi non si faceva menzione di alcuna data di rilascio, neanche indicativa. l'unica novita e' che hanno specificato che si trattera di un driver binario, cosa che tutti gia davano per scontata.

Ripeto il concetto di prima: quando Intel si accorgerà che più utenti chiederanno driver non proprietari, molto ptobabilmente li faranno. Potenza del mercato.

a parte che nella petizione si fa espressa richiesta delle specifiche, e' possibile che vada cosi, ma potrebbe andare andare male: i driver funzionano male, i pochi che provano linux sul centrino restano scottati e non lo usano piu, nessuno chiedera driver liberi.

Io non ti dico che sei un ipocrita... ti dico solo che un atteggiamento del genere è da ipocriti.

ma l'atteggiamento di chi? ci saranno delle persone che volevano solo un driver binario e adesso saranno contente. ci saranno altre persone invece che il driver binario non lo volevano e adesso come prima non sono contente. dove sta l'ipocrisia?

Una critica ad una casa produttrice è una cosa (e non fiato su questo), un accanimento è unl'altra.

ho 6 processori intel in casa. mai lamentato per i processori, funzionano benone. ho 4 schede di rete intel a casa. funzionano benone, mai lamentato. significa forse che devo stare zitto anche su tutto il resto? mi accanisco eccome in critiche sulla tipologia e qualita di un driver se quest'ultimo non mi soddisfa.

P.S. ad ogni modo credo che la maggioranza degli utenti che usa Linux sia abbastanza smaliziata da poter essere in grado di utilizzare tali drivers

ti assicuro che io sono smaliziato abbastanza, ma tanti, troppi driver binari sono totalmente inutilizzabili per chiunque.

Originariamente inviato da qweasdzxc
certamente, c'e anche un ndis wrapper sviluppato in modo indipendente rilasciato con licenza gpl. probabilmente e' meno compatibile, o ha piu problemi, o funziona peggio, o e' piu difficile da fare andare, o magari e' anche meglio invece, non so.
lo trovi qua:
http://ndiswrapper.sourceforge.net/
ce n'e anche uno per freebsd avevo letto tempo addietro (o forse e' lo stesso e l'han solo portato)

il problema di questi wrapper e' che alcune aziende li usano come scusa per non sviluppare driver (ne liberi ne proprietari) per linux. sta gia succedendo. ad esempio guardate questo annuncio da parte di 3com:
http://newsvac.newsforge.com/newsvac/03/12/17/1428250.shtml
praticamente il supporto a linux per le loro schede wlan consiste nella frase: "andatevi a comprare il driverloader da linuxant".
almeno questo e' il senso dell'articolo su newsforge, non riesco piu a trovare l'annuncio ufficiale, magari hanno solo sbagliato gli autori dell'articolo.

non e' che non voglio driver binari perche voglio usare la scheda di rete come una stampante. e' che se il driver lo avessero rilasciato qualche mese fa probabilmente adesso non potresti passare al kernel 2.6 perche loro non lo supportano ancora. non potresti usare sistemi operativi diversi da linux perche quel driver funziona solo con linux. se il nuovo driver ha un bug che ti da fastidio magari loro ci stanno 4 mesi a correggerlo, sempre se lo correggono. queste sono alcune delle cosine simpatiche che possono succedere, e che sono successe ripetutamente a me con l'unico driver proprietario che disgraziatamente mi capita ancora di usare.

guarda, 6 mesi fa intel ha fatto annunci simili. davvero, e' un anno che dicono che il driver sta per uscire. io mi sentirei preso in giro. magari adesso esce, ma meglio frenare gli entusiasmi, per ora non c'e alcun driver. poi per quanto riguarda gli altri, solo broadcom non ha neanche un driver binario, le prism hanno un driver gpl + firmware, un'altra marca (mi sfugge il nome) ha un driver binario da compilare, e forse c'e un'altra marca ancora con un driver solo binario, ma non sono sicuro.
quindi attualmente intel e' proprio l'ultima ruota del carro per quanto riguarda i driver wlan, con speranza di diventare penultima. un driver binario sarebbe davvero il MINIMO indispensabile, e non mi sentirei di ringraziarli neanche se decidessi di usarlo, anzi resterei arrabbiato perche per 1 anno hanno preso per il culo i propri utenti.


guarda, purtroppo dipende caso per caso.

intanto ripeto, solo intel e broadcom per quanto riguarda l'802.11g non hanno tirato fuori niente. e i chip intel stanno conoscendo una diffusione tale da rappresentare un vero problema per moltissimi utenti. tanto che aziende commerciali hanno investito denaro per offrire ai propri clienti una possibile soluzione, e addirittura dei privati si sono scritti un ndis wrapper da soli. quando si arriva a questo punto mi pare che si sia aspettato un po troppo per meritarsi un ringraziamento dopo aver cacciato fuori i driver.

poi personalmente mi capita spesso di essere danneggiato dall'esistenza di un driver binario piu che dalla sua non esistenza. uno di tanti esempi: mi sono trovato tra le mani un modem intel 56k. ci sono i driver proprietari sul loro sito. ci ho perso mezza giornata per cercare di farli andare, poi mi sono arreso (periodicamente mi capita di voler provare a fare andare qualche caccola di driver binario, i risultati sono sempre sconfortanti). in questo caso se non ci fossero stati per me sarebbe stato oggettivamente meglio, lo buttavo via subito e andavo a comprarne uno seriale. avrei perso meno tempo.
ti ringrazio per le delucidazioni :)

L'utente qweasdzxc sta facendo una fatica boia a convincervi, poverino... :)

ragazzi, dovreste sapere bene ormai su cosa si basa linux e qual'è la sua filosofia: software LIBERO!

provate a caricare il modulo ndiswrapper... e morite ve lo assicuro
sul mio centrino la tastiera si inchioda alla chiamata ioctl(), è un problema serio e dopo un giorno a fare debugging ho dovuto rinunciare perchè il problema sta nel file inf di windows che ndiswrapper usa. quindi niente wireless

provate a installare i driver delle schede ATI. Dopo due pomeriggi di bestemmie sono riuscito ad attivare il DRI, non so ancora come ci sono riuscito

Un utente newbie resterebbe fuori gioco dopo 5 minuti ed eccolo a piangere che linux è troppo difficile eccetera

Questa è una carognata bella e buona da tutti i produttori di hw che non rilasciano driver open source (o che non li rilasciano proprio): un driver closed è difficile da caricare se non è stato compilato per il kernel in uso sulla nostra macchina.
in ogni caso appena si cambia kernel tutto è da rifare, ma bisogna aspettare che il produttore esegua un upgrade del driver, non ci si può arrangiare. ci si trova invece a non poter seguire lo sviluppo di linux, rinunciando alla sua caratteristica più importante! Man mano che il kernel viene sviluppato, esso supporta nativamente nuovo hw rendendo il pc più stabile e sicuro, oltre che molto più veloce (arrivo a occupare 130mega di ram solo con KDE, due sessioni di MATLAB attive e finestre dappertutto)...
ma per ottenere questo è necessario seguire questo modus operandi, e le aziende come intel creano solo disastri con queste dichiarazioni.

anche io non voglio più nella mia macchina dei driver closed, e nessuno della comunità opensource li chiede. non credo neanche che le aziende subiscano danni nel svelare l'architettura dei propri prodotti (vedi epson, mi sembra l'abbia già citata qweasdzxc)

qweasdzxc non si è comportato in modo ipocrita, siete voi che non avete capito come funziona linux

ciao a tutti :)

P.S. col kernel 2.6.0 ho fatto finalmente funzionare la ATI9200...
col 2.6.1 il modulo fglrx non si carica più.. strano vero?

Non escono driver per Linux, e giù critiche. Escono, e peggio ancora. Fatemelo dire: siete incontentabili!

Se una casa come Intel vuol mantenere il riserbo sulla sua tecnologia, non ci vedo nulla di male: ha speso parecchio in R&D, e a questo punto vuole CONCRETIZZARE. Per lei QUESTO è il miglior modo di farlo: impedire che altre case vadano a vedere in che modo ha risolto alcuni problemi, che magari loro hanno, e via a copiare il codice. Per Intel tutto ciò ha un costo. Per gli altri no, visto che si trovano tutto a portata di mano.
Il know-how si paga, e questo è un modo per poterlo fare.

Il fatto che io compri un certo prodotto non può essere una giustificazione per obbligare una casa a fornire il supporto per il s.o. di turno che sto cercando di utilizzare: a questo punto, visto che pago, dovrei sentirmi in diritto di avere i driver anche per il più sparuto s.o. di questo mondo. Esiste. Ho comprato l'hardware. PRETENDO il supporto. Ma non mi sembra una buona motivazione, soprattutto logica. Forza BeOS, PetrOS, NewOS, QNX, e chi più ne ha più ne metta: PRETENDIAMO il supporto per tutti.

Infine, prendiamo il mondo reale: non mi sembra che tutti quelli che comprano nuovo hardware da quando è uscito Windows XP, sii mettano le mani nei capelli per il fatto che viene fornito loro un cd con i driver da installare. Nella piattaforma Windows domina il binario: metti il CD, si installano i driver, e finisce lì.
Con Linux no: appena cambia il kernel di una virgola, casca giù la madonna. E siccome gli aggiornamenti non cambiano, il popolo di Linux è grande fonte di preoccupazione per la chiesa cattolica, a causa dell'alto tasso di bestemmie che circola in quest'ambiente. ;)

A questo punto penso che il problema non stia nei driver, forniti senza sorgente, ma in Linux stesso. E credo che dovrebbero essere i suoi sviluppatori a prendere atto di questo problema, e ha definire una nuova interfaccia (API) con i driver affinché una casa possa fornire solamente i binari e:
1) si possano integrare immediatamente nel kernel, oppure
2) si installino "ala Windows". Metto il CD e fine della penitenza.

E adesso sbranatemi. :D

Scusate per gli errori grammaticali: ho poco tempo per rileggere ciò che scrivo...

Originariamente inviato da cdimauro
Non escono driver per Linux, e giù critiche. Escono, e peggio ancora. Fatemelo dire: siete incontentabili!

Se una casa come Intel vuol mantenere il riserbo sulla sua tecnologia, non ci vedo nulla di male: ha speso parecchio in R&D, e a questo punto vuole CONCRETIZZARE. Per lei QUESTO è il miglior modo di farlo: impedire che altre case vadano a vedere in che modo ha risolto alcuni problemi, che magari loro hanno, e via a copiare il codice. Per Intel tutto ciò ha un costo. Per gli altri no, visto che si trovano tutto a portata di mano.
Il know-how si paga, e questo è un modo per poterlo fare.

Il fatto che io compri un certo prodotto non può essere una giustificazione per obbligare una casa a fornire il supporto per il s.o. di turno che sto cercando di utilizzare: a questo punto, visto che pago, dovrei sentirmi in diritto di avere i driver anche per il più sparuto s.o. di questo mondo. Esiste. Ho comprato l'hardware. PRETENDO il supporto. Ma non mi sembra una buona motivazione, soprattutto logica. Forza BeOS, PetrOS, NewOS, QNX, e chi più ne ha più ne metta: PRETENDIAMO il supporto per tutti.

Infine, prendiamo il mondo reale: non mi sembra che tutti quelli che comprano nuovo hardware da quando è uscito Windows XP, sii mettano le mani nei capelli per il fatto che viene fornito loro un cd con i driver da installare. Nella piattaforma Windows domina il binario: metti il CD, si installano i driver, e finisce lì.
Con Linux no: appena cambia il kernel di una virgola, casca giù la madonna. E siccome gli aggiornamenti non cambiano, il popolo di Linux è grande fonte di preoccupazione per la chiesa cattolica, a causa dell'alto tasso di bestemmie che circola in quest'ambiente. ;)

A questo punto penso che il problema non stia nei driver, forniti senza sorgente, ma in Linux stesso. E credo che dovrebbero essere i suoi sviluppatori a prendere atto di questo problema, e ha definire una nuova interfaccia (API) con i driver affinché una casa possa fornire solamente i binari e:
1) si possano integrare immediatamente nel kernel, oppure
2) si installino "ala Windows". Metto il CD e fine della penitenza.

E adesso sbranatemi. :D
sono daccordo :)


bella quella della chiesa cattolica :D:D:D

Originariamente inviato da Leron
sono daccordo :)


Quella di supportare il minimo vitale (~= possono esistere) i driver binari e` una precisa scelta tecnica.

+++

Rileggendo piu` l'intero thread che il tuo intervento, aggiungo

Sulle motivazioni di questa scelta tecnica si e` dibattuto a tal punto che i morti si accatastavano su due strati; di fronte alla devastante potenza delle argomentazioni contrarie piu` comuni ("non e` come windows") parecchi hanno perso la forza di combattere, e cosi`, come in molti altri casi la discussione si e` arenata.

Viva il dialogo e il dibattito.

[edit] "combattere" nel senso di discutere, continuando con la metafora. Puntualizzo perche` non si sa` mai, visti i trascorsi...[/edit[

azz... e per la prima volta la vedo come cdimauro!

:) Chico

P.S. quella della chisa cattolica è una perla che mi venderò al più presto!

dato che Intel è una Spa ovvio che se come è probabile Microzoz gli offre soldi per "segare le gambe a Linux" attua una certa politica, anche perchè a Intel non interessa che gli utenti usino più Linux o windows a loro basta vendere l'hardware.

Innanzitutto vorrei premettere che son un utilizzatore "accanito" di windows sia per ragioni di pigrizia mentale che lavorative (nella società dove presto assistenza ci sono oltre 1000 pc e hanno tutti windows).
Fatta questa dovuta premessa, vorrei dire che io sono d'accordissimo con il discorso fatto da qweasdzxc.
Io penso che non sia corretto che delle società come la Intel (ma ce ne stanno tantissme altre) precludano ai propri clienti la possibilità di utilizzare un qualsiasi componente regolarmente acquistato su piattaforme diverse da windows, indipendentemente dal fatto che queste rappresentino anche solo l'1% di tutto il parco PC del mondo !!! Qualcuno potrebbe asserire che rendere libero il codice sorgente dei driver potrebbe danneggiare le stesse società, ma io invece penso proprio che sarebbe un arricchimento non indifferente. Infatti pensate alle migliaia di persone che ogni giorno per diletto scrivono dei driver per rendere compatibili delle periferiche per il mondo linux. Tutte queste migliaia di persone potrebbero dare una mano concreta a queste immense società sviluppando di volta in volta versioni dei driver sempre + stabili ed efficienti dei loro prodotti senza chiedere un $ o € per questo aiuto.
Molti si lamentano del fatto che Linux sia difficile da usare soprattutto per la mancanza dei driver. Ora non tutti sono in grado di scriverseli da soli e quindi è logico che molti abbandonino l'idea di provare un SO alternativo a windows.
In fondo è sempre meglio avere un'alternativa (+ o - valida) che essere costretti ad accettare passivamente quello che il mercato ci propina...

Originariamente inviato da canislupus
Innanzitutto vorrei premettere che son un utilizzatore "accanito" di windows sia per ragioni di pigrizia mentale che lavorative (nella società dove presto assistenza ci sono oltre 1000 pc e hanno tutti windows).
Fatta questa dovuta premessa, vorrei dire che io sono d'accordissimo con il discorso fatto da qweasdzxc.
Io penso che non sia corretto che delle società come la Intel (ma ce ne stanno tantissme altre) precludano ai propri clienti la possibilità di utilizzare un qualsiasi componente regolarmente acquistato su piattaforme diverse da windows, indipendentemente dal fatto che queste rappresentino anche solo l'1% di tutto il parco PC del mondo !!! Qualcuno potrebbe asserire che rendere libero il codice sorgente dei driver potrebbe danneggiare le stesse società, ma io invece penso proprio che sarebbe un arricchimento non indifferente. Infatti pensate alle migliaia di persone che ogni giorno per diletto scrivono dei driver per rendere compatibili delle periferiche per il mondo linux. Tutte queste migliaia di persone potrebbero dare una mano concreta a queste immense società sviluppando di volta in volta versioni dei driver sempre + stabili ed efficienti dei loro prodotti senza chiedere un $ o € per questo aiuto.
Molti si lamentano del fatto che Linux sia difficile da usare soprattutto per la mancanza dei driver. Ora non tutti sono in grado di scriverseli da soli e quindi è logico che molti abbandonino l'idea di provare un SO alternativo a windows.
In fondo è sempre meglio avere un'alternativa (+ o - valida) che essere costretti ad accettare passivamente quello che il mercato ci propina...
mi pare che non abbia precluso niente, tan'è vero che la news parla proprio del fatto che intel lo ha fatto il driver per linux

Originariamente inviato da cdimauro
Non escono driver per Linux, e giù critiche. Escono, e peggio ancora. Fatemelo dire: siete incontentabili!
No, siamo "diversi" ;)


Se una casa come Intel vuol mantenere il riserbo sulla sua tecnologia, non ci vedo nulla di male: ha speso parecchio in R&D, e a questo punto vuole CONCRETIZZARE. Per lei QUESTO è il miglior modo di farlo: impedire che altre case vadano a vedere in che modo ha risolto alcuni problemi, che magari loro hanno, e via a copiare il codice. Per Intel tutto ciò ha un costo. Per gli altri no, visto che si trovano tutto a portata di mano.
Il know-how si paga, e questo è un modo per poterlo fare.
Guarda, nessuna migliore risposta di quella che ho scritta in signature (scritta da un tizio che di driver, datasheet e nda ne ha visti parecchi).


E credo che dovrebbero essere i suoi sviluppatori a prendere atto di questo problema, e ha definire una nuova interfaccia (API) con i driver affinché una casa possa fornire solamente i binari
Questa tua semplice osservazione nasconde problemi molto più profondi, che sono stati discussi - seriamente e senza prese di posizione talebane - dagli sviluppatori del kernel.
Il riassunto del discorso è: non esiste e non può esistere una ABI stabile del kernel! Non è mai esistita e mai esisterà! Non perché i "cattivoni" si divertono di tanto in tanto a cambiare i prototipi delle funzioni in modo da rendere inutilizzabili i driver closed, ma perché linux è...fatto così. Non voglio addentrarmi in cose difficili da spiegare in poche parole, ma ti basti sapere che lo _stesso_ kernel (stessa identica versione) può essere compilato (ottimizzandolo per i vari sistemi) in mille modi diversi che lo rendono assolutamente incompatibile dal punto di vista binario! L'esempio più banale da illustrare è un kernel con supporto UP e uno SMP: solo sotto windows i driver sono indipendenti da questo "piccolo" fattore...

Originariamente inviato da Leron
mi pare che non abbia precluso niente, tan'è vero che la news parla proprio del fatto che intel lo ha fatto il driver per linux

Leron, non so piu in che lingua scriverlo. leggi bene la news. NON C'E ANCORA ALCUN DRIVER. SONO 12 MESI CHE FANNO ANNUNCI COME QUESTO. hanno preso per il culo un sacco di gente per 12 mesi.
inoltre anche rilasciando un driver binario (che ancora non si vede) PRECLUDONO qualcosa eccome, non rilasciando LE SPECIFICHE. non un driver libero, ma le specifiche. non ci sono. non le danno. guardate cosa chiede la petizione firmata da migliaia di persone. epson non ha MAI scritto UN solo driver per le sue stampanti per sistemi non windows, eppure TUTTE le sue stampanti sono supportate da TUTTI i sistemi operativi.
NESSUNO pretende che intel scriva driver per pippo-os, per pluto-os, e chi piu ne ha piu ne metta. TUTTI (anche gli utenti windows) dovrebbero pretendere che intel PERMETTA a chi vuole usare pluto-os o pippo-os di scriversi da solo un driver se ne e' capace.
perche un giorno potrebbe capitare agli utenti windows di dover per forza usare pluto-os o pippo-os. perche se pluto-os o pippo-os sono tecnicamente validi possono cosi diffondersi e fare concorrenza a windows e ne guadagniamo TUTTI QUANTI, e sfido chiunque a metterlo in dubbio. perche cosi quando esce un nuovo windows con nuovo modello di driver incompatibile col precedente e il produttore si rifiuta di supportare la vecchia scheda allora qualcun altro lo puo fare se lo vuole e ne e' capace.
ma il bello e' che PER LORO STESSA AMMISSIONE e' possibile scrivere un driver opensource senza che ne vengano danneggiati, e potrebbero farlo loro stessi. e allora perche non rilasciare subito le specifiche che qualcun altro intanto magari si arrangia? e' una presa in giro bella e buona.

Originariamente inviato da qweasdzxc
NESSUNO pretende che intel scriva driver per pippo-os, per pluto-os, e chi piu ne ha piu ne metta. TUTTI (anche gli utenti windows) dovrebbero pretendere che intel PERMETTA a chi vuole usare pluto-os o pippo-os di scriversi da solo un driver se ne e' capace.

Intel ha in effetti sempre ampiamente documentato i propri dispositivi, e non si è neanche tirata indietro quando c'era da scrivere (o da finanziare(*) ) qualcosa per Linux.
Credo che per il Centrino ci sia il "solito" problema: hanno integrato tecnologia di "terze parti", e queste "terze parti" non gradiscono il rilascio di driver liberi o datasheet.
Prendo atto che fino ad oggi hanno venduto almeno un Centrino in meno (quello che mia moglie non si è comprata, avendo preferito un più "documentato" Athlon Mobile).
Queste persone vanno prese per il portafogli, non c'è altra maniera.



(*) La Intel ha finanziato e continua a finanziare la Tungsten Graphics per la scrittura di driver liberi DRI per le schede video integrate nei loro chipset.

Originariamente inviato da cdimauro
Non escono driver per Linux, e giù critiche. Escono, e peggio ancora. Fatemelo dire: siete incontentabili!

peccato che:
1)chi chiedeva espressamente driver liberi e/o specifiche non era contento prima e non e' contento adesso. non mi pare si tratti di persone incontentabili. io sono tra questi.
2)chi chiedeva driver closed e non riteneva eccessivo un anno di attesa non era contento prima e continua a non essere contento adesso perche i driver non ci sono, ma se saltano fuori magari sono contenti e allora di sicuro non sono incontentabili
3)chi chiedeva driver closed e riteneva eccessivo un anno di attesa non era contento prima e continuera a non essere contento anche quando rilasceranno i driver perche ha aspettato troppo
4)per finire i pochi che chiedevano driver closed prima ma poi si sono accorti che era una vaccata e hanno cambiato idea si prendono le bastonate che si meritano da te. ma sono pochini per generalizzare e definire incontentabili anche tutti gli altri utenti di sistemi operativi liberi.

Se una casa come Intel vuol mantenere il riserbo sulla sua tecnologia, non ci vedo nulla di male: ha speso parecchio in R&D, e a questo punto vuole CONCRETIZZARE. Per lei QUESTO è il miglior modo di farlo: impedire che altre case vadano a vedere in che modo ha risolto alcuni problemi, che magari loro hanno, e via a copiare il codice.

la notizia non linka all'intervista vera rilasciata circa una settimana fa, nella quale sono trapelate le informazioni riguardanti lo sviluppo dei driver per centrino.
un pezzo dell'intervista lo puoi trovare qui:
http://news.com.com/2100-7344-5145073.html

ma in particolare ti quoto un pezzo, che avevo gia quotato qualche messaggio fa ma che sembra nessuno abbia letto:

"What I believe will happen is we will end up having a Linux compatibility driver that is not open source at first, then designing future drivers in such a way that they are open source but will not expose intellectual property,"

tradotto: sto tizio dice che e' possibilissimo per intel creare un driver opensource senza esporre la loro "proprieta intellettuale".

e allora a che gioco stanno giocando?

Per Intel tutto ciò ha un costo. Per gli altri no, visto che si trovano tutto a portata di mano.

vorrei sapere come facevano pero i produttori di schede 802.11b a campare. molte erano dotate di driver completamente liberi. eppure tutti quelli che le hanno prodotte e scritto i driver hanno MOLTI meno soldi di intel e reparti di R&D MOLTO meno grandi.

Il fatto che io compri un certo prodotto non può essere una giustificazione per obbligare una casa a fornire il supporto per il s.o. di turno che sto cercando di utilizzare: a questo punto, visto che pago, dovrei sentirmi in diritto di avere i driver anche per il più sparuto s.o. di questo mondo. Esiste. Ho comprato l'hardware. PRETENDO il supporto. Ma non mi sembra una buona motivazione, soprattutto logica. Forza BeOS, PetrOS, NewOS, QNX, e chi più ne ha più ne metta: PRETENDIAMO il supporto per tutti.

no, PRETENDO i datasheet. non capisco perche no. non volete spendere soldi per sviluppare un driver per qualcuno? date a quel qualcuno la possibilita di arrangiarsi.

Infine, prendiamo il mondo reale: non mi sembra che tutti quelli che comprano nuovo hardware da quando è uscito Windows XP, sii mettano le mani nei capelli per il fatto che viene fornito loro un cd con i driver da installare. Nella piattaforma Windows domina il binario: metti il CD, si installano i driver, e finisce lì.

e nella piattaforma unix domina il sorgente. il produttore dell'hardware manda delle patch a chi di dovere, e finisce la. poi sul sito possono mettere anche altra roba, ma da quello non si prescinde. il bello e' che per l'hardware tipicamente da server dove linux ha una quota consistente di mercato sta cosa non e' per niente insolita, guarda chi e' che spesso mette le mani sui driver direttamente presenti nel kernel:

/usr/src/linux# grep @3ware.com -R *
drivers/scsi/3w-xxxx.c: Written By: Adam Radford <linux AT 3ware.com>
drivers/scsi/3w-xxxx.c: Modifications By: Joel Jacobson <linux AT 3ware.com>
drivers/scsi/3w-xxxx.c: Brad Strand <linux AT 3ware.com>
drivers/scsi/3w-xxxx.c: linux AT 3ware.com
drivers/scsi/3w-xxxx.h: Written By: Adam Radford <linux AT 3ware.com>
drivers/scsi/3w-xxxx.h: Modifications By: Joel Jacobson <linux AT 3ware.com>
drivers/scsi/3w-xxxx.h: Brad Strand <linux AT 3ware.com>

/usr/src/linux# grep @adaptec.com -R *
CREDITS:E: achim_leubner AT adaptec.com
drivers/scsi/dpt/dpti_ioctl.h: email : deanna_bonds AT adaptec.com
drivers/scsi/ips.c:/* ipslinux AT adaptec.com */
drivers/scsi/ips.h:/* ipslinux AT adaptec.com */
drivers/scsi/dpt_i2o.c: email : deanna_bonds AT adaptec.com
drivers/scsi/Kconfig: ipslinux AT adaptec.com.
drivers/scsi/dpti.h: email : deanna_bonds AT adaptec.com
drivers/scsi/gdth.c: * <achim_leubner AT adaptec.com> *
drivers/scsi/gdth.c: * Johannes Dinner <johannes_dinner AT adaptec.com> *
drivers/scsi/gdth.h: * <achim_leubner AT adaptec.com>
drivers/scsi/aacraid/sa.c: * Copyright (c) 2000 Adaptec, Inc. (aacraid AT adaptec.com)


Con Linux no: appena cambia il kernel di una virgola, casca giù la madonna. E siccome gli aggiornamenti non cambiano, il popolo di Linux è grande fonte di preoccupazione per la chiesa cattolica, a causa dell'alto tasso di bestemmie che circola in quest'ambiente. ;)

ti assicuro che a casa mia di kernel ne girano tanti ma le uniche bestemmie arrivano puntualmente quando c'e di mezzo un driver binario. e' praticamente matematico. e anche con questo problema di mezzo bestemmio molto ma molto meno da quando non uso windows, anzi e' proprio uno dei motivi per cui ho smesso.

A questo punto penso che il problema non stia nei driver, forniti senza sorgente, ma in Linux stesso. E credo che dovrebbero essere i suoi sviluppatori a prendere atto di questo problema, e ha definire una nuova interfaccia (API) con i driver affinché una casa possa fornire solamente i binari e:
1) si possano integrare immediatamente nel kernel, oppure
2) si installino "ala Windows". Metto il CD e fine della penitenza.

il problema non sta tanto nel codice linux, ma sta nel modo in cui viene sviluppato, profondamente diverso dalla "norma", e che volenti o nolenti stride fortemente con il concetto stesso di driver binario, non c'e niente da fare (e io sono dichiaratamente tra i volenti, ma non importa in questo caso). il punto e' che linux ESISTE grazie a questo modello di sviluppo. l'equazione e': niente modello di sviluppo aperto => niente linux => niente concorrente numero 1 per windows (perche tutti quelli commerciali sono stati spazzati via per loro demerito o altro).
mi rivolgo agli utenti windows: se volete un concorrente per microsoft (pensateci, l'unico sistema per evitare altri anni e anni di minestre riscaldate travestite da sistemi operativi tipo winme...) servono driver liberi. la volete o no la concorrenza? o vi comoda solo per i processori e le schede video?

Originariamente inviato da ilsensine
Credo che per il Centrino ci sia il "solito" problema: hanno integrato tecnologia di "terze parti", e queste "terze parti" non gradiscono il rilascio di driver liberi o datasheet.

correva voce che alcune schede wireless, specie le piu recenti, non fossero dotate di driver liberi perche questo avrebbe permesso di usarle fuori specifica con una potenza emessa superiore alla norma di legge, in quanto alcune parti adibite a questo controllo erano assenti o implementate nel software anziche nell'hardware. temevo ci fosse anche questo a contribuire all'assenza di datasheet o driver liberi. forse i problemi potrebbero essere superati con la via di mezzo driver libero + firmware binario, e forse a questo si riferiva il tizio intervistato. questo pero non giustificherebbe tutti questi mesi di attesa con la scritta "driver in fase di sviluppo" sul sito. che intel abbia cacciato e cacci soldi in vari altri progetti non lo metto in dubbio, ma sta storia del centrino ha cominciato a pesare un bel po e piu passa il tempo e piu assume l'aspetto di una farsa...

qweasdzxc ...

la mia ammirazione per te è grande :)

qweasdzxc sono sempre + d'accordo con te.
Francamente non capisco come si possa dire che il rilascio di un driver binario per linux sia la stessa cosa che il rilascio delle specifiche o del codice sorgente.

Originariamente inviato da canislupus
qweasdzxc sono sempre + d'accordo con te.
Francamente non capisco come si possa dire che il rilascio di un driver binario per linux sia la stessa cosa che il rilascio delle specifiche o del codice sorgente.
chi l'ha detto questo?

io sarei ovviamente più contento che i driver fossero open :cool:

però prendo atto che se li fanno closed, almeno li fanno, meglio che una scarpata nelle gengive no?

Rispondo un po' a tutti. A questo punto è evidente che il problema nasce soltanto per Linux, per via della filosofia di sviluppo che sta alla sua base. Se non è possibile definire un'interfaccia unica/univoca, allora è meglio darci un taglio, anche se nutro forti dubbi in proposito.
I dubbi sono dovuti al fatto che, comunque, non mi sembra impossibile definire un'interfaccia consolidata per l'integrazione e/o utilizzo SOLAMENTE PER I DRIVER. Il kernel non è fatto soltamente di supporto ai driver: tutto il resto lo si può scrivere come meglio aggrada agli sviluppatori, lasciandoli liberi di dare sfogo alle proprie idee.
D'altra parte questi problemi mi sembra che li abbia soltanto Linux e i suoi derivati: per tutti gli altri s.o. il problema non si pone. Ne cito soltanto uno, anche se adesso è defunto: BeOS. Microkernel POSIX-compliant e supporto SMP nativo. Ma ha i driver binari.
Non diciamo che è impossibile farlo: diciamo piuttosto che "il fork() è il cancro dell'open source" (c) mio. ;)
Mi spiace, ma sono sempre più convinto di ciò, e quest'ultima discussione rappresenta la conclusione dei dubbi che ho avuto in proposito. Non è possibile che dei programmatori non si possano mettere d'accordo per il bene di un s.o. e della sua collettività. E' troppo facile parlare di libertà, ma a questo punto penso che sia mal distribuita, e ve lo dice uno che sulla libertà assoluta ha costruito la sua utopia del sistema sociale.
In conclusione: se Linux non vuol definire un'interfaccia comune per i driver, per una scelta dei suoi sviluppatori, allora si dimostri un po' di maturità e la si smetta di piagnucolare perché gli altri hanno scelto di non aderire a questa "visione del mondo". Si tratta di scelte da ambo le parti: ampiamente criticabili e giustificabili, ma per entrambe le parti. La libertà esiste anche in questo no? ;)

P.S. Anche la battuta sulla chiesa cattolica è (c) mio. ;)

Originariamente inviato da cdimauro
I dubbi sono dovuti al fatto che, comunque, non mi sembra impossibile definire un'interfaccia consolidata per l'integrazione e/o utilizzo SOLAMENTE PER I DRIVER
Qual è la differenza tra un driver e il resto del kernel?


D'altra parte questi problemi mi sembra che li abbia soltanto Linux e i suoi derivati: per tutti gli altri s.o. il problema non si pone. Ne cito soltanto uno, anche se adesso è defunto: BeOS. Microkernel POSIX-compliant e supporto SMP nativo. Ma ha i driver binari.
Cioè si porta dietro l'overhead per sistemi smp anche quando non è necessario? Ben contento che linux sia diverso, scusa ;)

Non diciamo che è impossibile farlo: diciamo piuttosto che "il fork() è il cancro dell'open source" (c) mio. ;)
Sul for( ;; ) fork(); non ti rispondo in quanto abbiamo idee diverse e non voglio ripetermi ogni volta, però ti faccio notare l'esempio che ho riportato prima, dove parlavo dello _stesso kernel_ (solo compilato differentemente).

Non è possibile che dei programmatori non si possano mettere d'accordo per il bene di un s.o. e della sua collettività. E' troppo facile parlare di libertà, ma a questo punto penso che sia mal distribuita, e ve lo dice uno che sulla libertà assoluta ha costruito la sua utopia del sistema sociale.
Non è solo questione di libertà. Io (e non solo io) sono ben contento che certe cose funzionino così, anche se ciò mi costringe a stare un pò attento quando entro in un negozio di informatica (alla fine della storia, chi ci rimette non sono io).

In conclusione: se Linux non vuol definire un'interfaccia comune per i driver, per una scelta dei suoi sviluppatori, allora si dimostri un po' di maturità e la si smetta di piagnucolare perché gli altri hanno scelto di non aderire a questa "visione del mondo". Si tratta di scelte da ambo le parti: ampiamente criticabili e giustificabili, ma per entrambe le parti. La libertà esiste anche in questo no? ;)
Basta che non ci si arroghi il diritto di dire "questo prodotto ha supporto per linux". E' chiaro che per parlare di "supporto" occorre ben più che un driver proprietario, scritto solo per paura di perdere qualche quota di mercato.
Tralascio il fatto che sapere come funziona la ferraglia che mi vendono potrebbe essere mio diritto.

nb l'interfaccia per i driver _esiste_, a livello di codice sorgente.

Il kernel non è fatto soltamente di supporto ai driver: tutto il resto lo si può scrivere come meglio aggrada agli sviluppatori, lasciandoli liberi di dare sfogo alle proprie idee.
D'altra parte questi problemi mi sembra che li abbia soltanto Linux e i suoi derivati:

linux attualmente e per alcuni sorprendentemente non ha derivati. bsd4.4lite ha avuto diversi derivati tra cui i famosi free/net/openbsd. poi ci sono diversi altri sistemi liberi ma molto meno diffusi e comunque non derivati da linux. il motivo per cui non ci sono decine di fork (bisognerebbe vedere bene la definizione di fork, puo esserci ambiguita) di linux non e' ben noto, c'e chi tende ad attribuirne il merito alla licenza adottata, chi alle decisioni e/o alla personalita di torvalds, chi ad altro o a un insieme di fattori.

per tutti gli altri s.o. il problema non si pone. Ne cito soltanto uno, anche se adesso è defunto: BeOS. Microkernel POSIX-compliant e supporto SMP nativo. Ma ha i driver binari.

il fatto che sia defunto (non proprio ma vabbe) non e' secondario. e nonostante avesse una interfaccia stabile per i driver (ed essendo closed source non poteva che averla cosi). tralasciando una interessante ma troppo lunga analisi dei potenziali motivi per cui beos non ha avuto successo, vorrei solo far notare che intel non avrebbe di sicuro sviluppato driver centrino per beos (non aiutando quindi una diffusione di beos sui notebook), ma che il rilascio delle specifiche e/o di un driver libero per un altro sistema operativo che in molti vorrebbero vedere avrebbe fornito la possibilita a chi lo volesse di scriversi un driver, anche per un sistema operativo closed source dotato di interfacce stabili per i driver ma ignorato dai piu. specifiche e/o driver liberi sono un vantaggio per tutti, non solo per chi usa sistemi operativi opensource.

Non diciamo che è impossibile farlo: diciamo piuttosto che "il fork() è il cancro dell'open source" (c) mio. ;)

ma: niente fork => niente opensource.
che abbia degli aspetti negativi ok, che sia un difetto in generale, no, anzi e' uno dei principali pregi.

Mi spiace, ma sono sempre più convinto di ciò, e quest'ultima discussione rappresenta la conclusione dei dubbi che ho avuto in proposito. Non è possibile che dei programmatori non si possano mettere d'accordo per il bene di un s.o. e della sua collettività.

e' esattamente il contrario. moltissimi programmatori si sono messi daccordo nel supportare il meno possibile i driver binari proprio per il bene del sistema operativo e della sua collettivita. lo ripeto, lo scarso supporto ai moduli binari non e' un difetto di programmazione o una mancata intesa in fase di sviluppo. e' una cosa VOLUTA, e sulla quale si e' trovata una intesa. dopo tutte le discussioni l'opinione piu diffusa e' quella che i driver binari siano ammessi, ma non incentivati. c'e anche chi pensa che i driver binari non dovrebbero essere nemmeno permessi.

E' troppo facile parlare di libertà,

ma il difficile e' ottenerla/mantenerla. ci stiamo provando.

Originariamente inviato da ilsensine
Qual è la differenza tra un driver e il resto del kernel?
I driver dovrebbero stare al livello immediatamente sottostante il kernel, e quest'ultimo dovrebbe servire esclusivamente come gestore della/e CPU, della memoria, e delle risorse hardware (ossia: interfacciarsi con le periferiche tramite i driver).
Cioè si porta dietro l'overhead per sistemi smp anche quando non è necessario? Ben contento che linux sia diverso, scusa
L'hai mai provato? Non so se il supporto SMP sia incluso anche sei sistemi a singolo processore, ma di una cosa posso assicurarti: BeOS è sempre stato velocissimo in tutto quello che ho fatto. Tante altre persone possono riportare la stessa cosa.
Sul for( ;; ) fork(); non ti rispondo in quanto abbiamo idee diverse e non voglio ripetermi ogni volta,
Lo so. ;)
però ti faccio notare l'esempio che ho riportato prima, dove parlavo dello _stesso kernel_ (solo compilato differentemente).
L'ho notato, eccome, e a mio avviso è un'aggravante.
Non è solo questione di libertà. Io (e non solo io) sono ben contento che certe cose funzionino così, anche se ciò mi costringe a stare un pò attento quando entro in un negozio di informatica (alla fine della storia, chi ci rimette non sono io).
Benissimo. C'è tanta gente, però, che svuole trasformare questa libertà in obbligo per tutti gli altri: condivi anche tu questa prospettiva?
Basta che non ci si arroghi il diritto di dire "questo prodotto ha supporto per linux". E' chiaro che per parlare di "supporto" occorre ben più che un driver proprietario, scritto solo per paura di perdere qualche quota di mercato.
D'accordo.
Tralascio il fatto che sapere come funziona la ferraglia che mi vendono potrebbe essere mio diritto.
Non esageriamo: non riusciamo a sapere neppure come sono fatte le cose che fagocitiamo quotidianamente. Pensa alla Coca-Cola: alla Pepsi pagherebbero oro per essere a conoscenza di quella formuletta che da più di cent'anni delizia il nostro palato. ;)
Oppure immagina quanto sarebbe felice Bin Laden se la costruzione di bombe atomiche fosse cosa di pubblico dominio... :D
Insomma, è un principio che non vedo bene in senso assoluto.
nb l'interfaccia per i driver _esiste_, a livello di codice sorgente.
Figuriamoci cosa accadrebbe se mancasse pure quella! ;)

Originariamente inviato da qweasdzxc
linux attualmente e per alcuni sorprendentemente non ha derivati. bsd4.4lite ha avuto diversi derivati tra cui i famosi free/net/openbsd. poi ci sono diversi altri sistemi liberi ma molto meno diffusi e comunque non derivati da linux. il motivo per cui non ci sono decine di fork (bisognerebbe vedere bene la definizione di fork, puo esserci ambiguita)
Per me fork() = creazione di un altro progetto derivante dalla scissione di un altro esiste.
di linux non e' ben noto, c'e chi tende ad attribuirne il merito alla licenza adottata, chi alle decisioni e/o alla personalita di torvalds, chi ad altro o a un insieme di fattori.
Ma non esistono decine di kernel sviluppati da persone diverse?
il fatto che sia defunto (non proprio ma vabbe) non e' secondario.
In questo contesto è assolutamente secondario, visto che è stato tirato in ballo per dimostrare un concetto ben preciso.
e nonostante avesse una interfaccia stabile per i driver (ed essendo closed source non poteva che averla cosi).
Il s.o. era closed source, ma buona parte dei driver erano open source. Be Inc. ne sviluppò ben pochi, purtroppo (era una società molto piccola), per cui ha fatto affidamento sulle persone più volenterose, che generalmente rilasciavano i sorgenti, e sulle società che supportavano questo s.o. (ma che rilasciavano per lo più i binari).
tralasciando una interessante ma troppo lunga analisi dei potenziali motivi per cui beos non ha avuto successo,
Vedi sopra: non ce n'è bisogno. La storia di Be non ha nulla a che vedere con questa discussione.
vorrei solo far notare che intel non avrebbe di sicuro sviluppato driver centrino per beos (non aiutando quindi una diffusione di beos sui notebook),
Se BeOS fosse rimasto in vista, probabilmente sì, invece. BeOS era abbastanza diffuso e stava iniziando a prendere piede. E comunque sarebbero bastati dei driver binari...
ma che il rilascio delle specifiche e/o di un driver libero per un altro sistema operativo che in molti vorrebbero vedere avrebbe fornito la possibilita a chi lo volesse di scriversi un driver, anche per un sistema operativo closed source dotato di interfacce stabili per i driver ma ignorato dai piu.
Indubbiamente. Ma non per questo una società dev'essere forzata a fare cose che non vuole: se fra i suoi interessi non c'è quello di pubblicare informazioni tecniche sui suoi prodotti, ha tutto il diritto di farlo. Perderà parte della clientela, e ne è cosciente. Punto.
specifiche e/o driver liberi sono un vantaggio per tutti, non solo per chi usa sistemi operativi opensource.
Lo so bene, ma la libertà di scelta deve valere per entrambe le parti. Il resto lo farà il mercato, apprezzando o meno una linea piuttosto che un'altra.
ma: niente fork => niente opensource.
che abbia degli aspetti negativi ok, che sia un difetto in generale, no, anzi e' uno dei principali pregi.
I pregi li vedo con prodotti come OpenOffice: UN pacchetto applicativo ben curato. I difetti li vedo nella mancanza di modello di architettura software solida, dal punto di vista dell'ingegneria del software, e questo dei driver ne è un esempio concreto.
e' esattamente il contrario. moltissimi programmatori si sono messi daccordo nel supportare il meno possibile i driver binari proprio per il bene del sistema operativo e della sua collettivita. lo ripeto, lo scarso supporto ai moduli binari non e' un difetto di programmazione o una mancata intesa in fase di sviluppo. e' una cosa VOLUTA, e sulla quale si e' trovata una intesa. dopo tutte le discussioni l'opinione piu diffusa e' quella che i driver binari siano ammessi, ma non incentivati. c'e anche chi pensa che i driver binari non dovrebbero essere nemmeno permessi.
Per quanto mi riguarda, finora ho considerato l'informatica un mezzo per risolvere dei problemi, non per introdurne altri.
Diciamoci la verità: l'accordo di non supportare i driver binari è dovuto soltanto alla mancanza di accordo relativo alla definizione di un'interfaccia solida e funzionale per il loro supporto. In questo penso che la politica adottata sia perfettamente aderente alla filosofia Unix: quella dello struzzo. Nascondiamo pure la testa sotto la sabbia, in caso di problemi, e speriamo che tutto fili liscio.
Non vedo, insomma, la volontà di mettersi attorno a un tavolo e aprire una sessione di studi e confronti per portare alla definizione di uno standard formale per risolvere dei problemi, come questo dei driver. Le società e gli enti serii che hanno interesse a risolvere alcuni problemi adottano questa politica: è grazie a ciò se oggi possiamo usufruire di standard ben definiti (ad esempio il JPEG). E' chiaro che ci saranno delle divergenze di opinioni, ma i meccanismi che portano alle decisioni finali sono ben definiti e soprattutto funzionali. Tant'è che, appunto, ci ritrovamo con diversi standard.
Al contrario, nell'ambiente Linux noto che alla minima incomprensione o diversità di veduta, si arriva alla classica fork() che genera un ulteriore progetto. Oppure, le diversità sono talmente elevate che è preferibile lasciare tutto com'è. Insomma, non lo vedo un come un segno di maturità, anzi.
Per quanto mi riguarda, gli unici problemi intrattabili/non computabili li ho trovato negli studi e nei teoremi di Turing e Goedel, e in generale nei padri che hanno fondato la teoria della computabilità: tutto il resto ricade nel dominio nel computabile, e quindi trattabile informaticamente parlando. Eccenzion fatta per chi non vuole, ovviamente.
ma il difficile e' ottenerla/mantenerla. ci stiamo provando.
Non alle spese di quella degli altri, però: libertà non significa pretendere che tutti conservino la medesima visione e siano obbligati a seguirne i dettami. In questo caso, però, penso che sia più una questione di maturità: accettare il fatto che le proprie scelte hanno delle conseguenze che non possono e non debbono essere fatte ricadere anche sugli altri.

Originariamente inviato da ilsensine
No, siamo "diversi" ;)
Allora mi scuserai se, nel caso in cui dovessimo incontrarci, passerò tutto il tempo con le spalle ben incollate al muro... :D
Guarda, nessuna migliore risposta di quella che ho scritta in signature (scritta da un tizio che di driver, datasheet e nda ne ha visti parecchi).
E' UN'esperienza personale. Con ciò non si può mica generalizzare il concetto.

Originariamente inviato da qweasdzxc
"What I believe will happen is we will end up having a Linux compatibility driver that is not open source at first, then designing future drivers in such a way that they are open source but will not expose intellectual property,"

tradotto: sto tizio dice che e' possibilissimo per intel creare un driver opensource senza esporre la loro "proprieta intellettuale".

e allora a che gioco stanno giocando?
Se lo traduci bene vedrai che il senso del discorso è ben diverso da quello che hai riportato. In particolare te ne puoi rendere conto dal "then" in poi. Mi sembra molto chiaro che non ci siano alcun gioco "sporco" al momento.
vorrei sapere come facevano pero i produttori di schede 802.11b a campare. molte erano dotate di driver completamente liberi. eppure tutti quelli che le hanno prodotte e scritto i driver hanno MOLTI meno soldi di intel e reparti di R&D MOLTO meno grandi.
Le motivazioni le potrà fornire soltanto Intel: certamente non posso farlo io.
Un esempio forse più chiaro del motivo per cui alcune società preferiscano lo sviluppo di driver closed source lo trovi con le schede video. Pensa a quanto sarebbe stata facile la vita per Ati scrivere driver le proprie schede basandosi sui sorgenti sviluppati da nVidia. E' molto comodo andare a vedere come gli altri hanno risolto alcuni problemi. Immagina quanto sarebbe comodo, e soprattutto redditizio, per società come XGI (Volari) e VIA/S3 (Deltachrome) poter avere fra le mani i sorgenti dei driver dei concorrenti. Mi sembra abbastanza chiaro il concetto...
no, PRETENDO i datasheet. non capisco perche no. non volete spendere soldi per sviluppare un driver per qualcuno? date a quel qualcuno la possibilita di arrangiarsi.
Devi capire che pretendere è una parola un po' troppo grossa. Se dovessimo usare le stesse misure, Intel potrebbe pretendere la riscrittura di Linux per avere un'interfaccia con i driver solida e omogenea.
e nella piattaforma unix domina il sorgente.
Nella piattaforma Linux, prego.
il produttore dell'hardware manda delle patch a chi di dovere, e finisce la. poi sul sito possono mettere anche altra roba, ma da quello non si prescinde. il bello e' che per l'hardware tipicamente da server dove linux ha una quota consistente di mercato sta cosa non e' per niente insolita, guarda chi e' che spesso mette le mani sui driver direttamente presenti nel kernel:
OK. E' bello e ne prendo atto. Ma una rondine non fa primavera: avranno avuto il loro interesse nel farlo...
ti assicuro che a casa mia di kernel ne girano tanti ma le uniche bestemmie arrivano puntualmente quando c'e di mezzo un driver binario. e' praticamente matematico.
Ecco, vedi: il cardinal Ratzinger in questo momento si starà rigirando sul letto a causa degli incubi... ;)
e anche con questo problema di mezzo bestemmio molto ma molto meno da quando non uso windows, anzi e' proprio uno dei motivi per cui ho smesso.
Sarà, ma a me è capitato l'esatto contrario: con Windows mi sono sempre trovato benissimo, specialmente dal lato driver.
mi rivolgo agli utenti windows: se volete un concorrente per microsoft (pensateci, l'unico sistema per evitare altri anni e anni di minestre riscaldate travestite da sistemi operativi tipo winme...) servono driver liberi. la volete o no la concorrenza? o vi comoda solo per i processori e le schede video?
Mi spiace, ma non colgo il sillogismo che porta a questa conclusione: concorrenza e driver liberi non sono uno la conseguenza logica dell'altro. Fino a prova contraria è soltanto Linux che ha un bisogno (disperato?) di driver liberi: tutti gli altri fin'ora hanno dimostrato di saperne fare benissimo a meno. E non sto parlando soltanto di Windows, anzi!

Allora, cerco di rispondere solo all'essenziale altrimenti arriviamo a papiri interminabili a forza di contro-quotare
Originariamente inviato da cdimauro
I driver dovrebbero stare al livello immediatamente sottostante il kernel, e quest'ultimo dovrebbe servire esclusivamente come gestore della/e CPU, della memoria, e delle risorse hardware (ossia: interfacciarsi con le periferiche tramite i driver).
Questo discorso può andare per architetture basate sui microkernel (che, al di là della pulizia progettuale, sono _meno_ efficienti dei kernel classici).
Per il resto, i driver devono gestire irq e altre risorse come il resto del kernel. La parte dipendente dall'hw (come vengono fisicamente impostati gli irq, come scrivere nello spazio di i/o o accedere alle tabelle pci, come utilizzare la mmu...) è indipendente dal driver, e rappresenta solo una piccola parte del kernel. Molte funzionalità però _influiscono_ sul driver: basti pensare alle diverse strategie di lock (su linux sono 4: smp , preempt, smp+preempt, up -- l'interfaccia con il driver è la stessa, cambia _cosa_ viene compilato!)



però ti faccio notare l'esempio che ho riportato prima, dove parlavo dello _stesso kernel_ (solo compilato differentemente).
L'ho notato, eccome, e a mio avviso è un'aggravante.

Aggravante?? Sono _sicuro_ che se tu avessi sotto windows un _decimo_ della flessibilità offerta dal kernel linux, staresti giorni interi a sperimentare tutte le possibilità


Pensa alla Coca-Cola: alla Pepsi pagherebbero oro per essere a conoscenza di quella formuletta che da più di cent'anni delizia il nostro palato. ;)
Non sto parlando di come è fatta la ferraglia, ma di quale diavolo di valore devo scrivere in quale cavolo di registro per abilitare ad es. l'uscita tv di una scheda video(*)


Oppure immagina quanto sarebbe felice Bin Laden se la costruzione di bombe atomiche fosse cosa di pubblico dominio... :D

_E'_ di dominio pubblico, ma per realizzare quello che serve occorrono impianti "leggermente" sofisticati ;)


E' UN'esperienza personale. Con ciò non si può mica generalizzare il concetto.
Ti assicuro che non viene da una persona qualunque ;) (a volte penso che non si tratti nemmeno di un essere umano :D )





(*) Informazione negata ad uno sviluppatore dalla ATI

Originariamente inviato da cdimauro
Fino a prova contraria è soltanto Linux che ha un bisogno (disperato?) di driver liberi: tutti gli altri fin'ora hanno dimostrato di saperne fare benissimo a meno. E non sto parlando soltanto di Windows, anzi!
A volte ho l'impressione che non afferri bene un punto.
Linux è, al momento, l'unica alternativa seria a windows (a parte architetture diverse da x86, dove ci sono ancora prodotti notevoli). E' considerato una "grave minaccia", per loro stessa ammissione, e sai anche che non risparmiano colpi bassi (anche al limite - e forse oltre - della legalità) per contrastarlo e screditarlo.
Secondo te, linux come diavolo ha fatto a conqistare questa posizione, apparentemente in una condizione di disperata inferiorità (di mercato, di supporto, di utenze, di tutto...)? Merito della società X che rilascia driver prorietari, o è un effetto di cose che ai tuoi occhi risultano solo "difetti architetturali e scelte discutibili" (quali gli n^n fork, disponibilità dei sorgenti per ogni angolo del kernel, interfaccia/api del kernel in perenne evoluzione ma rigidamente standard in user space)?
Concedici almeno il beneficio del dubbio ;)

Diciamoci la verità
ci ho provato con tutto il cuore, ma non hai capito niente, o piu probabilmente non hai voluto capire niente.
la tua verita e' che:
-di fronte alle scelte delle multinazionali bisogna inchinarsi e stare zitti
-la possibilita di fork e' un male
-ci sono decine di kernel incompatibili l'uno con l'altro
-linux si comporta da struzzo
-nessuno si siede ad un tavolo a discutere dei problemi
-e' pure immaturo
-solo su linux domina il sorgente
-l'hardware tipicamente da server e' piu spesso supportato come dio comanda solo per caso
-ecc...

ora io ho usato per 7 anni windows e software commerciale. solo da 2 uso solo software liberi, ma ho visto e letto molto, e ho avuto modo di pensare e di farmi un'opinione, e per quanto mi riguarda sono sicuro che hai torto.
tu invece per quanti anni hai usato software proprietario e per quanti anni invece hai usato software libero (e non intendo solo installare 1/2 programmi su windows)? su quali basi ti sei fatto queste opinioni?

Originariamente inviato da ilsensine
Questo discorso può andare per architetture basate sui microkernel
Veramente in tutta la letteratura classica si è sempre fatto riferimento a questo modello in senso universale, non con espresso riferimento a un sistema microkernel. Tant'è che lo troviamo utilizzato anche in numerosi testi che descrivono s.o. Unix-like, quando ancora non esistevano neppure i microkernel.
(che, al di là della pulizia progettuale, sono _meno_ efficienti dei kernel classici).
Bisogna vedere in quali ambiti applicativi: ho potuto provare QNX (poco, sfortunatamente) e BeOS (moltissimo), e mi sembra che fossero tutto fuorché inefficienti...
Per il resto, i driver devono gestire irq e altre risorse come il resto del kernel. La parte dipendente dall'hw (come vengono fisicamente impostati gli irq, come scrivere nello spazio di i/o o accedere alle tabelle pci, come utilizzare la mmu...) è indipendente dal driver, e rappresenta solo una piccola parte del kernel.
D'accordissimo: questo rispecchia il funzionamento dei moderni s.o., siano essi microkernel o no.
Molte funzionalità però _influiscono_ sul driver: basti pensare alle diverse strategie di lock (su linux sono 4: smp , preempt, smp+preempt, up -- l'interfaccia con il driver è la stessa, cambia _cosa_ viene compilato!)
Beh, non mi sembra la fine del mondo, dal punto di vista del supporto: realizzare 4 driver binari a seconda della modalità adottata, può essere seccante, ma è fattile: non siamo mica parlando di centinaia di diverse possibilità!
Una soluzione più elegante potrebbe essere quella di utilizzare un puntatore alla funzione da chiamare (fra le quattro): leggermente meno efficiente (ma si tratta solamente di un'ulteriore chiamata), ma che permetterebbe di avere una sola versione dei driver da utilizzare.
Insomma, se si vuole, si trovano delle soluzioni a questi problemi.
Aggravante?? Sono _sicuro_ che se tu avessi sotto windows un _decimo_ della flessibilità offerta dal kernel linux, staresti giorni interi a sperimentare tutte le possibilità
Guarda, prima ancora che Linux nascesse, con AmigaOS potevo cambiare QUALUNQUE modulo/funzione del s.o. (compresi scheduler dei task, routine di allocazione della memoria, dispatcher dei messaggi di sistemi, ecc. ecc. ecc.) IN TEMPO REALE (durante l'esecuzione): più flessibilità di questa non credo di averne vista in giro (non c'era bisogno neppure di ricompilare nulla), ma personalmente non l'ho mai sfruttata (al contrario di tanti altri che si sono sbizarriti).
Eppure AmigaOS offriva un'interfaccia solida e funzionale ai driver, che nella stragrande maggioranza erano presenti in forma binaria...
Non sto parlando di come è fatta la ferraglia, ma di quale diavolo di valore devo scrivere in quale cavolo di registro per abilitare ad es. l'uscita tv di una scheda video(*)
Capisco benissimo cosa vuoi dire: senza queste informazioni non si può far nulla. Un programmatore si trova chiaramente spiazzato, pur con tutta la buona volontà e intelligenza di questo mondo.
Il problema è che non sempre, per una compagnia, è conveniente rilasciare informazioni sul proprio hardware: vedi esempio delle schede video. Mi sembra abbastanza eloquonte. O ci sono altre soluzioni che permettano di salvare "capre e cavoli"?
_E'_ di dominio pubblico, ma per realizzare quello che serve occorrono impianti "leggermente" sofisticati
Se fosse realmente di dominio pubblico Pakistan e India possederebbero armi atomiche da un bel pezzo. Come pure la Libia, Iraq, Iran e la Corea del Nord, per citare altre nazioni che non hanno mai nascosto interesse in tale direzione.
Gli impianti, per quanto sofisticati, si possono sempre comprare. Per il know-how il discorso è più difficile. Infatti, non è un semplice caso il fatto che le nazioni che hanno ottenuto l'atomica hanno al loro servizio eminenti scienzati che sono riusciti nell'imprese. D'altra parte paesi come Pakistan e India sono messi nella stessa condizioni economiche e tecnologiche di tanti altri paesi, ma alla fine ci sono arrivati. Anzi, paesi come Libia, Iraq e Iraq, con l'enorme potere dato dal possedere enormi risorse petrolifere, sarebbero dovuti arrivarci per primi...
Ti assicuro che non viene da una persona qualunque (a volte penso che non si tratti nemmeno di un essere umano)
D'accordo. Conoscendoti, non esprimeresti pareri così sbilanciati verso un'altra persona. Ma assodato ciò, non si può generalizzare l'esperienza che ha avuto questo grand'uomo all'intero campo. D'altra parte, le innovazioni tecnologiche si susseguono in continuazione: non ci troviamo sempre di fronte a scopiazzature o all'utilizzo di tecnologie di terze parti. Nel caso delle innovazioni, chi acquisisce un certo know-how è chiaro che ha tutto l'interesse a tenerselo stretto. E con innovazione non intendo soltanto un prodotto del tutto nuovo, ma anche una nuova soluzione a un problema già esistente.
A volte ho l'impressione che non afferri bene un punto.
Io, invece, ho l'impressione di non sapermi spiegare. Comunque, chiarirò meglio dopo cosa intendo.
Linux è, al momento, l'unica alternativa seria a windows (a parte architetture diverse da x86, dove ci sono ancora prodotti notevoli). E' considerato una "grave minaccia", per loro stessa ammissione, e sai anche che non risparmiano colpi bassi (anche al limite - e forse oltre - della legalità) per contrastarlo e screditarlo.
D'accordo su tutta la linea.
Secondo te, linux come diavolo ha fatto a conqistare questa posizione, apparentemente in una condizione di disperata inferiorità (di mercato, di supporto, di utenze, di tutto...)? Merito della società X che rilascia driver prorietari, o è un effetto di cose che ai tuoi occhi risultano solo "difetti architetturali e scelte discutibili" (quali gli n^n fork, disponibilità dei sorgenti per ogni angolo del kernel, interfaccia/api del kernel in perenne evoluzione ma rigidamente standard in user space)?
Concedici almeno il beneficio del dubbio ;)
Te lo levo subito il dubbio: indubbiamente (!) la maggior parte del merito va alla disponibilità delle persone che si sono spese lavorandoci, a pari merito con la filosofia di lasciare libero il sorgente e pretendere che gli altri facciano lo stesso; in minor parte grazie alle società che hanno rilasciato driver proprietari: comunque non hanno lasciato col culo per terra i propri clienti.
Quanto agli altri problemi sollevati, rispondo velocemente, perché preferisco parlarne meglio dopo: non critico i fork di per sé, ma l'uso che se ne fa; la disponibilità dei sorgenti è una grande cosa, ma non dev'essere l'unica strada IMPOSTA; l'interfaccia del kernel si può evolvere quanto vuole, ma è necessario definire delle linee guida ben precise per risolvere alcuni problemi (driver); l'interfaccia user space standard è condizione necessaria per la sopravvivenza di un s.o., e qui nessuno la sta mettendo in discussione (per me è un concetto ovvio/assodato).

Adesso chiariamo il nocciolo della questione (rispondendo anche al messaggio di ginojap), di cui accennavo sopra, così evitiamo problemi di incomprensione (almeno spero :)). Quello sui driver è un discorso che necessita di essere diviso in tre parti: quello prettamente tecnico, quello etico, e quello sul monopolio/diffusione di un s.o. (può sembrare simile al secondo, ma mi spiegherò meglio dopo).

1. Lato tecnico. Linux per sua natura e SCELTA richiede l'utilizzo di driver liberi (con sorgenti). Io ho obiettato che è un caso anomalo, in quanto fior di s.o. utilizzano da sempre driver binari, per cui quella di Linux è una limitazione bella e buona (mia conclusione). Esempio portato: BeOS, ma potevo anche scegliere Solaris, NeXTStep, QNX, Mac OS X, AmigaOS, ecc.

2. Lato etico. La scelta di tante compagnie di non voler rilasciare specifiche e/o driver liberi viene presa di mira e perseguitata dalla comunità Linux. Io ho obiettato che: a) come la comunità Linux ha deciso di scegliere liberamente questa soluzione, la stessa cosa hanno il diritto di fare queste società, e per questo non meriterebbero alcuna critica (d'altra parte se Linux non avesse questa limitazione, i driver binari rilasciati rappresenterebbero la soluzione, almeno parziale, ai problemi della comunità); b) alcune società hanno l'esigenza di farlo, per tutelare strettamente i loro interessi (l'ultimo esempio sulle schede video, ripeto, dovrebbe essere fin troppo chiaro. Se non lo è, smentitemi).

3. Lato monopolio/diffusione del s.o. E' chiaro che MS ha tutto l'interesse a impedire il supporto al suo concorrente più temibile, per cui la mancanza di driver è un grande alleato, che finora ha appagato le mire di zio Bill e soci. Ma tutto questo perché deve ricadere sulle spalle delle società che commercializzano dei prodotti? MS non produce hardware (per lo meno, lo fa, ma in settori molto ristretti e in cui la concorrenza è agguerrita). E' vero che può fare pressioni su chi lo produce, ma mi sembra che sono tante le società che supportano Linux, anche il rilascio dei soli driver binari vuol dire remare contro il grande monopolista. Il punto focale, però, è il seguente: per quale motivo le società dovrebbero essere obbligate a seguire le scelte fatte da un gruppo d'individui? Perché il concetto di libertà di scelta deve valere in una sola direzione e criticato in caso contrario?

Ok, spero che sia tutto chiaro. Nei miei messaggi ho cercato di dividere sempre discussioni e motivazioni, ma evidentemente non bastava. Adesso vogliamo continuare seriamente questa discussione secondo queste linee, oppure debbo vedere nuovamente delle risposte che cercano sempre di riportare in un unico, grande, calderone i termini della questione? Perché non trovo bello parlare di capre e sentirsi rispondere sui cavoli (parlando in generis).
Cerchiamo di tenere ben presente di cosa stiamo parlando e orientiamo le nostre argomentazioni in maniera mirata, senza uscire dal seminato. Ogni discussione merita una risposta a sé, sebbene l'origine sia la medesima.

Originariamente inviato da qweasdzxc
ci ho provato con tutto il cuore, ma non hai capito niente, o piu probabilmente non hai voluto capire niente.
E' la stessa cosa che mi chiedo anch'io. Spero che il messaggio di cui sopra possa servire a rimettere a posto il binario della discussione.
la tua verita e' che:
-di fronte alle scelte delle multinazionali bisogna inchinarsi e stare zitti
Questo è quel che pensi TU, non io. Non ho mai detto una cosa del genere, il mio discorso era ben diverso, e non è carino vederlo manipolato e artefatto a proprio uso e consumo. Io non ho fatto la stessa cosa con le idee espresse nei tuoi messaggi. Lo stesso ragionamento vale per tutte le frasi sotto.
-la possibilita di fork e' un male
Mai detto. Ho sempre critica l'uso che se fa.
-ci sono decine di kernel incompatibili l'uno con l'altro
Mai detto. Ho soltanto detto che esistono decine di kernel. Se poi ti riferisci al discorso affrontato con ilsensine, il problema riguardava ben altro.
-linux si comporta da struzzo
La comunità, non Linux. Il comportamento "da struzzo" è una metafora che viene utilizza molto spesso quando si studiano i s.o. (Unix-like) per indicare i casi in cui questi ultimi, dato un certo problema, preferiscono non pensare di fornire una soluzione, ma sperare che non si verifichino mai.
-nessuno si siede ad un tavolo a discutere dei problemi
O se lo fanno, preferiscono non arrivare a una conclusione, giusto per completare il quadro. Mentre, stranamente, le organizzazioni serie hanno portato e portano a definire standard che poi vengono utilizzati da tutti, con ovvi benefici per l'intera collettività.
-e' pure immaturo
In questo contesto mi riferivo alla comunità, non al s.o. in sé. E comunque per certi versi Linux non lo è, e avendo letto i miei precedenti messaggi dovresti sapere come la penso.
-solo su linux domina il sorgente
E' l'unico s.o. che ha posto alla sua base questo concetto, almeno finora. Comunque, non capisco perché hai tirato in ballo questa frase: cosa ci sarebbe di offensivo/ingiusto/sbagliato in quel che t'ho scritto in precedenza?
-l'hardware tipicamente da server e' piu spesso supportato come dio comanda solo per caso
Questa l'hai aggiunta di proposito: non abbiamo mai parlato di ciò in questo thread. Dove vuoi arrivare?
-ecc...
Piuttosto che elencare queste cose, potevi anche abbassarti a rispondere alle questioni aperte nei miei messaggi, e a cui hai preferito non rispondere. Anzi, rispondere parlando di tutt'altra cosa. Tattica dello struzzo? ;)
ora io ho usato per 7 anni windows e software commerciale. solo da 2 uso solo software liberi, ma ho visto e letto molto, e ho avuto modo di pensare e di farmi un'opinione, e per quanto mi riguarda sono sicuro che hai torto.
Sembra che tutto ciò rientri esclusivamente nel tuo dominio: non hai mai pensato che anche chi ti sta di fronte potrebbe aver avuto esperienze altrettanto arricchenti, se non maggiori? Risparmiami di elencare quel che ho fatto nel campo dell'informatica da quasi 22 anni a questa parte.
Dici che ho sicuramente torto? Ebbene, aspetto che lo dimostri, rispondendo (e argomentando) ai messaggi che t'ho scritto in precedenza. A parole siamo tutti bravi, ma a me interessano soltanto i fatti.
tu invece per quanti anni hai usato software proprietario e per quanti anni invece hai usato software libero (e non intendo solo installare 1/2 programmi su windows)? su quali basi ti sei fatto queste opinioni?
Prima mi devi spiegare cosa c'entra tutto ciò col discorso di cui sopra. Mi spieghi la connessione logica fra il discorso sui driver, che tra l'altro sta all'origine di questo thread, e l'esperienza derivante dall'uso del software, sia esso libero o chiuso? IMHO non c'entrano nulla l'uno con l'altro (tra l'altro stiamo parlando di "utilizzo" di software, non di programmazione).
Dal canto mio non ho difficoltà a dirti che ho utilizzato Linux, e in quest'ambito: OpenOffice (ma ho provato anche StarOffice), Opera, Mozilla, GhostScript, NcFtp, e chissà quanti altri programmi che non mi vengono in mente in questo momento, a partire dalla metà '90 (1994 forse, ma non ricordo bene). Per HP-UX, per diletto, con un mio collega abbiamo scritto e rilasciato i sorgenti (eresia! ;)) di alcuni comandi per agevolare lo scambio di dati con i PC: all'università (CT) era l'epoca delle prime connessioni a internet (1992-93), e l'FTP dominava; poco dopo arrivò Mosaic, a inaugurare un'altra era.
Vogliamo continuare a tergiversare su cose inutili, come l'esperienza personale di utilizzo di software, o possiamo tornare all'oggetto della discussione? Le basi ognuno se l'è fatte in base alle esperienze che ha avuto. Punto. Quel che conta sono le argomentazioni portate a sostegno di una tesi. Punto.

x ginojap: ho già parlato abbastanza e mi fermo soltanto sulla questione del reverse engineering. Mi sembra che questa forma di analisi del prodotto altri, per poi copiarlo, sia abbastanza diffusa anche nell'ambito software (e hardware). Certamente può essere più difficile farlo, ma se ti fermi a riflettere sul tempo che intercorre fra il rilascio di un'applicazione/gioco e quello del suo crack, mi sembra che non siamo messi tanto male... ;)

Questo è quel che pensi TU, non io. Non ho mai detto una cosa del genere, il mio discorso era ben diverso.

provo ad aggiustare la mira allora:
-di fronte alle scelte delle multinazionali NON bisogna inchinarsi e stare zitti ma bisogna far sentire la propria voce quando lo si ritiene necessario. solo che le specifiche delle schede a te non servono e quindi per quanto ti riguarda fanno bene a non rilasciarle.

il discorso si riduce a questo quindi: io sono convinto che hai torto, e che avere specifiche e/o driver liberi e' un vantaggio anche per te, anche se non ci programmerai mai un driver da solo o non ne userai mai uno libero. tu sei convinto che io ho torto, e che mi dovrei accontentare di driver binari.


non è carino vederlo manipolato e artefatto a proprio uso e consumo. Io non ho fatto la stessa cosa con le idee espresse nei tuoi messaggi.

a parte che io non credevo di avere manipolato un bel niente, neanche vedere una propria risposta completamente ignorata e' carino. continua a non andarmi giu questa:

io:"e' esattamente il contrario. moltissimi programmatori si sono messi daccordo nel supportare il meno possibile i driver binari proprio per il bene del sistema operativo e della sua collettivita. "

tu:"Diciamoci la verità: l'accordo di non supportare i driver binari è dovuto soltanto alla mancanza di accordo relativo alla definizione di un'interfaccia solida e funzionale per il loro supporto."

dove l'hai letta sta verita?
proviamo con la logica: torvalds e' contrario, molti i suoi interventi al riguardo. per quanto riguarda gli altri: o una persona pensa che e' meglio avere un'interfaccia per i driver solida, o pensa che sia meglio NON avere un'interfaccia per i driver solida. se un numero sufficiente di persone pensa che sia meglio avere un'interfaccia solida, c'e il fork. se sono troppo pochi a desiderare una interfaccia solida, niente fork. il fatto che non ci sia una versione di linux con migliore supporto ai driver binari e' di per se una prova indiziaria che non la si considerava una cosa buona.

ti diro di piu: mi e' stato detto che nel kernel 2.6 i driver binari sono prestazionalmente un po piu penalizzati di quelli liberi rispetto al 2.4, e questo esclusicamente per scelta politica. (e mi pare di trovarne conferma qua: http://www.kniggit.net/wwol26.html
"Another security-related change is that binary modules (for example, drivers shipped by a hardware manufacturer) can no longer "overload" system calls with their own and can no longer see and modify the system call table. This significantly restricts the amount of access that non-open source modules can do in the kernel and possibly closes some legal loopholes around the GPL.")
ti pare una modifica apportata in assenza di una precisa volonta comune di supportare il meno possibile i driver binari?

Mai detto. Ho sempre criticato l'uso che se fa.

"il fork() è il cancro dell'open source"

poi hai corretto il tiro, e hai sostenuto che l'uso che si fa del fork e' sbagliato. ma perche? in quali casi sarebbe stato meglio non effettuare il fork? hai degli esempi in cui puoi dimostrare che se non ci fosse stato il fork di un progetto l'originale sarebbe stato migliore? di sicuro non linux, visto che non ne esistono fork indipendenti. ma anche nel caso di altri progetti... di esempi di fork positivo ce ne sono a bizzeffe. gcc ha subito un fork nel tempo, si chiamava egcs o una cosa del genere. non mi ricordo perche, forse una minoranza non condivideva alcune scelte e pensava di poter fare meglio. e ha fatto meglio, perche da una certa versione in avanti egcs ha cambiato nome ed e' diventato il nuovo gcc, perche era meglio. senza fork gcc sarebbe migliorato allo stesso modo o meno? le glibc hanno subito un fork allo scopo di seguire meglio gli sviluppi del kernel mi pare, o forse perche lo sviluppo stagnava un po, non lo so. dopo qualche anno e' saltato fuori che le glibc originali si erano sviluppate di piu, ed erano meglio, e le vecchie libc5 sono state abbandonate. hai le prove che si sarebbero sviluppate piu velocemente le glibc se non ci fosse stato quel progetto concorrente? parliamo di qualche fork recente? un tizio voleva rendere multithreaded mplayer, dopo innumerevoli discussioni sulla mailing list in cui non c'era accordo tra le sue idee e quelle di altri ha creato un fork chiamato mplayerxp. causa difficolta tecniche o mancanza di tempo o altri sviluppatori ha avuto vita breve, credo non sia piu attivamente sviluppato. questo fork quanto ha danneggiato mplayer? molto poco, probabilmente sarebbe stato piu dannoso perdere ulteriore tempo sulle mailing list. ci sono dozzine di esempi, cinepaint e' un fork di gimp, ma e' stato sviluppato su misura da aziende cinematografiche per il fotoritocco frame by frame dei loro film. lo sviluppo di gimp e' stato rallentato da questo? non direi, se non fosse stato possibile il fork adesso non sarebbe disponibile in modo libero uno strumento (molto settoriale, certo) come cinepaint. dove sta lo svantaggio qua?

Mai detto. Ho soltanto detto che esistono decine di kernel.

le definizioni di kernel "distinti" sono tante e variegate, ma non ne vedo nessuna che giustifichi una simile affermazione:
esistono milioni di kernel, uno per ogni macchina che lo fa girare. ma non e' questo che intendevi.
esistono 4 kernel, quelli ancora mantenuti, 2.0, 2.2, 2.4, 2.6, ma non e' questo che intendevi.
esistono 2 kernel, quello stabile e quello di sviluppo, ma non e' quello che intendevi.
esistono non ho idea di quante migliaia di copie dei sorgenti che uno sviluppatore prende abitualmente dal repository cvs/bitkeeper o quello che e', ne modifica qualche riga, e poi ne fa il commit. ognuno di quei kernel leggermente patchati e' diverso da un altro. ma non e' questo che intendevi.
esistono 11 (o piu, non ricordo) kernel, uno per ogni architettura hardware, ma non e' quello che intendevi.
esistono decine di distribuzioni che applicano patch al kernel, quindi hanno effettivamente dei kernel diversi le une dalle altre. ma viene mantenuta la compatibilita binaria, e anche i kernel sono generalmente sostituibili l'uno con l'altro, quindi non penso sia questo che intendevi.
esistono decine di collezioni di patch che vari sviluppatori usano e testano personalmente, con alcune funzionalita aggiunte o driver piu aggiornati o altri, ma sono solo collezioni di patch da applicare al kernel originale, spesso in previsione di una potenziale inclusione nel kernel.
esistono decine di progetti (user mode linux, kernel mode linux, openmosix, selinux, uclinux, ecc...) che prendono i sorgenti del kernel, li modificano sostanzialmente per ottenere il loro scopo, ma tipicamente non vengono offerti come progetti indipendenti. alla fine offrono sempre la patch per ottenere il loro progetto a partire dal kernel originale. di piu, quando esce un nuovo kernel ritoccano la patch in modo che si applichi al nuovo kernel. di piu, succede spesso che una patch separata venga in seguito integrata totalmente o parzialmente nel kernel, successo nel 2.6 con user mode linux, selinux, uclinux.
quali sono queste decine di kernel esistenti? ne esiste solo 1.

La comunità, non Linux. Il comportamento "da struzzo" è una metafora che viene utilizza molto spesso quando si studiano i s.o. (Unix-like) per indicare i casi in cui questi ultimi, dato un certo problema, preferiscono non pensare di fornire una soluzione, ma sperare che non si verifichino mai. O se lo fanno, preferiscono non arrivare a una conclusione, giusto per completare il quadro.

indipendentemente dal fatto che io possa condividere o meno questa analisi non corroborata dagli esempi e dai fatti che tu chiedi a me, non si applica al problema dei driver binari su linux, per il quale una decina di anni di discussioni o quasi convergono sempre allo stesso risultato: non si fornisce alcun tipo di supporto a chi vuole scriverli.

Mentre, stranamente, le organizzazioni serie hanno portato e portano a definire standard che poi vengono utilizzati da tutti, con ovvi benefici per l'intera collettività.

ovvi un corno. ma intanto distinguiamo tra consorzi pubbliche e aziende private. poi distinguiamo tra standard fatti bene e standard nati male. poi distinguiamo tra standard adottati e non adottati. e infine distinguiamo tra standard che hanno aiutato la collettivita, e standard che l'hanno danneggiata. probabilmente in ciascuna di queste 2*2*2*2=16 categorie non ben separate le une dalle altre ci troviamo esempi illustri. quindi quando parliamo di standard, andiamo caso per caso. in questo caso una interfaccia stabile per i driver binari aiuterebbe lo sviluppo di linux? chi linux lo fa pensa di no. tendo a crederci.

E' l'unico s.o. che ha posto alla sua base questo concetto, almeno finora.

sbagliato. prendiamo in esame i sistemi operativi VIVI. c'e windows. e ci sono gli unix. linux e' opensource. i *bsd sono opensource. perfino grossi pezzi di macosx sono opensource, oltre al sistema base che e' libero usano gcc, apache, samba, mi pare anche cups ma non sono sicuro, rendezvous, il motore html del browser safari e chissa che altro, non ho mai usato un mac.
altri? solaris lo metto tra i moribondi (e usa gnome di default) assieme a aix/hpux/irix e a os2 (e molti di quei produttori adesso vendono piu linux che i loro sistemi), mi vergogno quasi a citare unixware, zeta e' uno dei 2-3 tentativi di resurrezione di beos, qnix e' di niiiiiiicchia, togli via i vari aros, reactos ecc... che tanto sono opensource, cosa resta? skyos? non vedo sistemi operativi di successo che non siano fortemente legati all'opensource, o completamente opensource, a parte windows. ancora convinto che linux sia l'eccezione che conferma la regola?

Sembra che tutto ciò rientri esclusivamente nel tuo dominio: non hai mai pensato che anche chi ti sta di fronte potrebbe aver avuto esperienze altrettanto arricchenti, se non maggiori?

guarda che e' esattamente quello che voglio cercare di capire.

Dici che ho sicuramente torto? Ebbene, aspetto che lo dimostri, rispondendo (e argomentando) ai messaggi che t'ho scritto in precedenza. A parole siamo tutti bravi, ma a me interessano soltanto i fatti.

ho argomentato sulla storia delle decine di kernel, sul fork canceroso, sulla questione di linux come unico sistema operativo opensource. ma so gia come andra a finire, saltera fuori che nextstep non era opensource, quindi linux e' un caso anomalo.

Prima mi devi spiegare cosa c'entra tutto ciò col discorso di cui sopra. Mi spieghi la connessione logica fra il discorso sui driver, che tra l'altro sta all'origine di questo thread, e l'esperienza derivante dall'uso del software, sia esso libero o chiuso? IMHO non c'entrano nulla l'uno con l'altro (tra l'altro stiamo parlando di "utilizzo" di software, non di programmazione).

semplice, se usi sufficientemente a lungo software libero, o per lo meno in un certo modo, ti accorgi di come si muovono le cose dietro. l'atteggiamento "il fork e' male, linux e' troppo diviso, ecc..." lo si riscontra in modo pressoche costante tra gli utenti windows che ne hanno sentito parlare abbastanza e che lo hanno provato un pochino, ma che li si sono fermati, quindi gli esempi e i paragoni usati nella discussione saranno appropriati. tutt'altro tipo di discussione ne nasce con un utente bsd ad esempio.

Dal canto mio non ho difficoltà a dirti che ho utilizzato Linux, e in quest'ambito: OpenOffice (ma ho provato anche StarOffice), Opera, Mozilla, GhostScript, NcFtp, e chissà quanti altri programmi che non mi vengono in mente in questo momento, a partire dalla metà '90 (1994 forse, ma non ricordo bene). Per HP-UX, per diletto, con un mio collega abbiamo scritto e rilasciato i sorgenti (eresia! ;)) di alcuni comandi per agevolare lo scambio di dati con i PC: all'università (CT) era l'epoca delle prime connessioni a internet (1992-93), e l'FTP dominava; poco dopo arrivò Mosaic, a inaugurare un'altra era.
Vogliamo continuare a tergiversare su cose inutili, come l'esperienza personale di utilizzo di software, o possiamo tornare all'oggetto della discussione?

ma la discussione e' proprio questa. hai usato linux nell'ambito dei programmi x, y, z? bene ma poi? segui o hai seguito la linux kernel mailing list o altri posti? saro strano io, ma non capisco come tu possa pensare che sull'interfaccia dei driver ci fosse disaccordo, quando probabilmente e' piu facile trovare discussioni sull'opportunita di non permettere del tutto driver proprietari. anche recentemente, quando alcuni hanno messo in dubbio la legalita del driver binario per la scheda di rete wireless usata su un router linksys l'ultimo dei pensieri e' stato definire una interfaccia stabile per i driver, anzi.

Le basi ognuno se l'è fatte in base alle esperienze che ha avuto. Punto. Quel che conta sono le argomentazioni portate a sostegno di una tesi.

non e' vero. conta anche come le opinioni vengono formate, come minimo perche si fa prima a dimostrare che sono sbagliate nel caso partano dai presupporti sbagliati. cosa hai visto/letto/sentito per decidere che il fork e' normalmente usato male? hai visto le statistiche di sourceforge o di freshmeat? se e' davvero usato male perche il software opensource aumenta di diffusione invece di diminuire?

se ti fermi a riflettere sul tempo che intercorre fra il rilascio di un'applicazione/gioco e quello del suo crack, mi sembra che non siamo messi tanto male...

anche se possibile tecnicamente lo hanno reso illegale. una volta non era illegale. adesso ci sono leggi che lo vietano. secondo le tendenze attuali il software assurdamente e' l'unico tipo di bene che gode SIA della protezione del copyright, SIA della protezione dei brevetti (un libro non lo puoi brevettare, e una macchina non la puoi pubblicare) piu ovviamente del segreto industriale, e poi di una serie di nuove leggi tipo dmca. inoltre mentre la tendenza del software e' quello di divenire obsoleto in tempi sempre piu brevi, e comunque minuscoli rispetto a beni tradizionali, la durata della protezione sui brevetti e sul copyright continua a salire. e nuove leggi che aumentano continuamente la protezione vengono inventate e approvate in continuazione. e' un bene questo per la collettivita?

Originariamente inviato da cdimauro
Bisogna vedere in quali ambiti applicativi: ho potuto provare QNX (poco, sfortunatamente) e BeOS (moltissimo), e mi sembra che fossero tutto fuorché inefficienti...
Vedi le cose in bianco e nero? ;)
Non necessariamente devono essere inefficienti; anzi, qnx è architettato per avere latenze bassissime. Solo, utilizzando una struttura a microkernel si rinuncia a un pò di efficienza.
Nota che questo non è a priori un male (in fondo, anche scrivendo in c invece di assembler si rinuncia...a un pò di efficienza :D )


Beh, non mi sembra la fine del mondo, dal punto di vista del supporto: realizzare 4 driver binari a seconda della modalità adottata, può essere seccante, ma è fattile: non siamo mica parlando di centinaia di diverse possibilità!
Era solo un esempio; vuoi atri casi?
Ok:
Supporto memoria 1GB/4GB/64GB: altre 3 possibilità, ecco che 4*3=12
Varianti che influenzano driver specifici:
Per i driver isa, supporto isapnp (può essere presente o meno) e/o pnpbios: 12*4=48
Varianti che influenzano architetture specifiche:
Su amd64, supporto o meno per l'iommu: 4*2=8
...e tralascio i driver di rete, dove la crescita è "esplosiva" ;)


Una soluzione più elegante potrebbe essere quella di utilizzare un puntatore alla funzione da chiamare (fra le quattro): leggermente meno efficiente (ma si tratta solamente di un'ulteriore chiamata), ma che permetterebbe di avere una sola versione dei driver da utilizzare.
Insomma, se si vuole, si trovano delle soluzioni a questi problemi.

E' quello che fanno i produttori "intelligenti" di driver closed, come nvidia. Nessuna necessità di accroccare il kernel per i loro comodi, se ne sono già occupati loro (al prezzo di una minore efficienza).
Nota che quelle che tu chiami "funzioni", non sono in realtà sempre tali: possono essere dei define no-op, dei define particolari, o delle funzioni vere e proprie -- dipende dal tipo di compilazione, architettura ecc.
Ovviamente non puoi definire un "puntatore a un define" :D
Riguardo la semplice "ulteriore chiamata", la tlb ringrazia sentitamente ;)


Se fosse realmente di dominio pubblico Pakistan e India possederebbero armi atomiche da un bel pezzo.
Infatti ce l'hanno da un bel pezzo :D
Gli altri paesi che citi ci hanno provato, ma l'embargo internazionale (che misteriosamente non è valso per Pak e India) lo ha impedito (alcuni ci sono andati molto vicini però).


la disponibilità dei sorgenti è una grande cosa, ma non dev'essere l'unica strada IMPOSTA
In user space le api sono ferree; il kernel non è user space, non è posix, non è nient'altro che il kernel che vogliamo.


l'interfaccia del kernel si può evolvere quanto vuole, ma è necessario definire delle linee guida ben precise per risolvere alcuni problemi (driver)
Come detto, esiste a livello di CODICE SORGENTE.
La vuoi anche a livello di compatibilità binaria? Se ne è discusso, e non è stato trovato un motivo sufficiente per giustificarla (fare contenta nvidia _non_ è un motivo sufficiente)


per quale motivo le società dovrebbero essere obbligate a seguire le scelte fatte da un gruppo d'individui?
Perché siamo un gruppo di matti, che hanno stabilito delle regole matte, ma che hanno dato risultati impensabili.
Chiunque è libero di "accodarsi" se lo ritiene economicamente vantaggioso, ma non possono obbligarci a cambiare le regole che ci hanno portato al successo di oggi.

Perché il concetto di libertà di scelta deve valere in una sola direzione e criticato in caso contrario?
Linus ha detto: "posso non condividere quello che fai con il mio kernel, ma non farò nulla per impedirti di farlo".
Sono liberi di rilasciare driver closed; sono libero di dire "no grazie".

E' chiaro che siamo su posizioni culturalmente (e tecnicamente) inconciliabili ;)

Originariamente inviato da qweasdzxc
provo ad aggiustare la mira allora:
-di fronte alle scelte delle multinazionali NON bisogna inchinarsi e stare zitti ma bisogna far sentire la propria voce quando lo si ritiene necessario.
OK, ma bada bene: esistono anche tante piccole società che sviluppano prodotti, non soltanto le multinazionali. E per loro arrivare già a vendere un prodotto equivale a sopravvivere in questo mercato...
solo che le specifiche delle schede a te non servono e quindi per quanto ti riguarda fanno bene a non rilasciarle.
Scusa, ma a questo punto te lo posso dire: ma ci sei o ci fai? Mi fai vedere in base a quale mie argomentazioni sei arrivato a queste conclusioni? Non posso credere ai miei occhi, e a questo punto ho fatto bene a parlare di manipolazione delle mie parole. :rolleyes:
il discorso si riduce a questo quindi: io sono convinto che hai torto, e che avere specifiche e/o driver liberi e' un vantaggio anche per te, anche se non ci programmerai mai un driver da solo o non ne userai mai uno libero. tu sei convinto che io ho torto, e che mi dovrei accontentare di driver binari.
Mi spiace, ma non hai capito niente di tutto ciò che ho detto. E ho detto abbastanza. Mi sto stancando di ripetere sempre le stesse cose. Vuoi che ti faccia un copia & incolla di tutto ciò che ho scritto in merito e aggiungo un commentino finale, o ti può bastare andare a rileggere le risposte che ho dato anche a ilsensine?
a parte che io non credevo di avere manipolato un bel niente,
Forse non te ne rendi conto, ma è quel che stai facendo. Vedi sopra. Mi spiace, ma è proprio così, e sappi che la cosa non mi fa piacere.
neanche vedere una propria risposta completamente ignorata e' carino. continua a non andarmi giu questa:

io:"e' esattamente il contrario. moltissimi programmatori si sono messi daccordo nel supportare il meno possibile i driver binari proprio per il bene del sistema operativo e della sua collettivita. "

tu:"Diciamoci la verità: l'accordo di non supportare i driver binari è dovuto soltanto alla mancanza di accordo relativo alla definizione di un'interfaccia solida e funzionale per il loro supporto."

dove l'hai letta sta verita?
Questa, assieme ad altre parti dei miei messaggi che ho scritto, dovrebbe bastare per parlare di risposta al tuo assunto. La verità, e lo ripeto per l'n-esima volta, è che la soluzione adottata per un problema è di continuare a lasciare stare le cose come stanno: quindi una non-soluzione. E' meglio non perdere tempo nella definizione di un'interfaccia solida e funzionale: lasciamo tutto come sta e obblighiamo gli altri a seguire i nostri dettami. In estrema sintesi: i dettagli a sostegno di quest'idea che mi sono fatto li trovi negli altri messaggi che ho scritto.
E ripeto un paio di concetti:
1) l'informatica dovrebbe risolvere iproblemi, non introdurne altri.
2) la definizione di un'interfaccia standard per i driver binari non è annoverata fra i problemi informaticamente intrattabili che si studiano nella teoria della computazione. Tradotto: una soluzione a questo problema si può benissimo trovare, se si vuole...
proviamo con la logica: torvalds e' contrario, molti i suoi interventi al riguardo.
Ah, ecco abbiamo capito: MS ha Bill Gates e Linux ha Torvarlds a dettar legge.
per quanto riguarda gli altri:
Che a questo punto possiamo anche classificare anche persone meno importanti...
o una persona pensa che e' meglio avere un'interfaccia per i driver solida, o pensa che sia meglio NON avere un'interfaccia per i driver solida. se un numero sufficiente di persone pensa che sia meglio avere un'interfaccia solida, c'e il fork. se sono troppo pochi a desiderare una interfaccia solida, niente fork. il fatto che non ci sia una versione di linux con migliore supporto ai driver binari e' di per se una prova indiziaria che non la si considerava una cosa buona.
Un processo basato su sole prove indiziarie non arriverà mai a una sentenza, giuridicamente parlando.
Comunque, per tornare in tema, queste sono le conclusioni a cui sono arrivati loro, ma perché gli fa comodo continuare a non risolvere un problema rognoso come questo. Ripeto: tantissimi altri s.o. si basano su driver binari, e non stiamo parlando di giocattoli.
Si parla tanto di portare gente verso Linux, ma quest'ultimo non fa nulla per aiutare questo passaggio...
ti diro di piu: mi e' stato detto che nel kernel 2.6 i driver binari sono prestazionalmente un po piu penalizzati di quelli liberi rispetto al 2.4, e questo esclusicamente per scelta politica. (e mi pare di trovarne conferma qua: http://www.kniggit.net/wwol26.html
OK, è ovvio che le prestazioni saranno inferiori, ma di quanto? Del 30%? Del 50%? O più realisticamente di qualche punto percentuale? E per risparmiare qualche ciclo di clock bisogna per forza continuare su questa direzione? Mah, c'è poco da dire...
"Another security-related change is that binary modules (for example, drivers shipped by a hardware manufacturer) can no longer "overload" system calls with their own and can no longer see and modify the system call table. This significantly restricts the amount of access that non-open source modules can do in the kernel and possibly closes some legal loopholes around the GPL.")
ti pare una modifica apportata in assenza di una precisa volonta comune di supportare il meno possibile i driver binari?
No. Ma con ciò vuoi dirmi che non è possibile trovare soluzioni a questo problema? Io penso proprio di sì, invece.
"il fork() è il cancro dell'open source"

poi hai corretto il tiro, e hai sostenuto che l'uso che si fa del fork e' sbagliato.
Guarda che era una battuta in base al contesto della situazione: ho già parlato di forking dei progetti in altre situazioni, e dovresti aver letto ciò che penso. E' ovvio che non penso che sia una cosa sbagliata in senso assoluto, ma l'uso che spesso se ne fa...
ma perche? in quali casi sarebbe stato meglio non effettuare il fork? hai degli esempi in cui puoi dimostrare che se non ci fosse stato il fork di un progetto l'originale sarebbe stato migliore? di sicuro non linux, visto che non ne esistono fork indipendenti. ma anche nel caso di altri progetti... di esempi di fork positivo ce ne sono a bizzeffe.[...]
Prova a contare quanti browser esistono in circolazione. Prova a contare quante interfacce grafiche. Quanti sistemi per l'installazione delle applicazioni. Ecc.
Anziché concentrarsi sullo sviluppo di linee guida del s.o., si procede su una moltitudine di progetti che hanno gli stessi obiettivi.
Se si vuol far progedire un s.o., bisogna definere dei layer, e quindi delle API/Interfacce, che permettano di omogenizzare la visione del sistema da parte delle applicazioni. Esempio: devo scrivere un'applicazione grafica: quale GUI dovrei scegliere? X? Gnome? KDE? O passare in rassegna tutte le altre GUI esistenti?
Capisco che ci sono delle persone che hanno visioni diverse, ma da un sereno confronto dovrebbe nascere UNA linea guida, che comunque non deve assolutamente restare la stessa: si può migliorare col passare del tempo. Ma almeno il sistema ha già una base solida su cui contare.
Io ho seguito l'Amiga per parecchi anni, e debbo dire che la ricchezza dell'AmigaOS stava proprio nelle numerose API che coprivano le esigenze della applicazioni, e che col tempo si sono evolute (non divise) per fornire un servizio sempre migliore. Basta guardare le differenza fra le varie versioni 1.x, 2.x e 3.x del s.o. per rendersi conto che i cambiamenti apportati sono stati notevoli, ma tutto rimanendo nelle linee guide originariamente tracciate.
Poi c'è chi s'è divertito ad aggiungere delle funzionalità al s.o., come degli oggetti graficamente più ricchi, dei file requester estremamente più funzionali, ecc., ma tutto rimanendo nell'ambito della compatibilità.
le definizioni di kernel "distinti" sono tante e variegate, ma non ne vedo nessuna che giustifichi una simile affermazione[...]quali sono queste decine di kernel esistenti? ne esiste solo 1.
Senti, non sono stato io a dire che esistono numerosi kernel che hanno preso strade diverse da quella originale, anche se spesso si incrociano. A questo punto fate una cosa: mettetivi d'accordo su quale sia la verità e comunicatecelo... :rolleyes:
indipendentemente dal fatto che io possa condividere o meno questa analisi non corroborata dagli esempi e dai fatti che tu chiedi a me, non si applica al problema dei driver binari su linux, per il quale una decina di anni di discussioni o quasi convergono sempre allo stesso risultato: non si fornisce alcun tipo di supporto a chi vuole scriverli.
Basta, ne abbiamo parlato già abbastanza: non sono assolutamente d'accordo, ho già scritto le mie motivazioni, e tutto il resto del mondo continua a utilizzare un'interfaccia ben definita con i driver binari. I problemi sono i vostri. Non li volete risolvere? Teneteveli.
ovvi un corno.
Per me JPEG, MPEG, che sono le cose a me più vicine in questo momento, non sono "un corno", ma realtà esistenti e di cui TUTTI usufruiscono pienamente, anche tu.
ma intanto distinguiamo tra consorzi pubbliche e aziende private.
E perchè?
poi distinguiamo tra standard fatti bene e standard nati male.
Tipo?
poi distinguiamo tra standard adottati e non adottati.
OK. Mica tutti gli standard vanno adottati: per il collegamento di rete via cavo Ethernet non è l'unica soluzione, ma è quella che si imposta. Ma ne esistono decine e decine. Quanto meno, però, uno standard viene adottato: meglio del nulla... ;)
e infine distinguiamo tra standard che hanno aiutato la collettivita, e standard che l'hanno danneggiata.
Tipo?
probabilmente in ciascuna di queste 2*2*2*2=16 categorie non ben separate le une dalle altre ci troviamo esempi illustri.
Nessuno lo nega.
quindi quando parliamo di standard, andiamo caso per caso. in questo caso una interfaccia stabile per i driver binari aiuterebbe lo sviluppo di linux? chi linux lo fa pensa di no. tendo a crederci.
OK, allora diamoci un taglio. Ripeto: tutto il resto del mondo la pensa diversa, e le cose vanno bene così. Continuate con la vostra strada, se siete convinti che sia la migliore, ma almeno evitate di tediarci con le vostre recriminazioni...
sbagliato. prendiamo in esame i sistemi operativi VIVI.
Certo, è meglio escludere anche quelli "morti" per convenienza personale. Ma che ragionamenti sono, scusa? Un s.o., anche "morto", rappresenta comunque un prodotto ben definito? In base a quale ragionamento dovremmeo farlo fuori?
c'e windows. e ci sono gli unix. linux e' opensource. i *bsd sono opensource.
OK per BSD.
perfino grossi pezzi di macosx sono opensource,oltre al sistema base che e' libero usano gcc, apache, samba, mi pare anche cups ma non sono sicuro, rendezvous, il motore html del browser safari e chissa che altro, non ho mai usato un mac.
Per forza che sono open source: sono stati presi dall'open source, per cui è ovvio che seguando questa strada! Tra l'altro Darwin non è stato nemmeno rilasciato subito, ma dopo un po'.
Visto che hai tirato in ballo OS X, perché non parliamo di tutto il resto, che viene gelosamente custodito da Apple? Parliamo di Quarz, ad esempio? Che mi dici? Se l'open source è così bello, perché non vengono rilasciati i sorgenti? Sentiamo cos'hai da dire su questo punto...
altri? solaris lo metto tra i moribondi
Certo, è moribondo, quindi dev'essere escluso. Evviva la logica. :rolleyes:
(e usa gnome di default)
Ma per il resto: "sotto il vestito, niente"... ;)
assieme a aix/hpux/irix e a os2 (e molti di quei produttori adesso vendono piu linux che i loro sistemi),
Certo: è un buon motivo per tenere in considerazione... :rolleyes:
mi vergogno quasi a citare unixware, zeta e' uno dei 2-3 tentativi di resurrezione di beos
E speriamo che si sbrighino...
, qnix e' di niiiiiiicchia,
Certo, certo: anche questo è un buon motivo per toglierlo di mezzo...
togli via i vari aros, reactos ecc... che tanto sono opensource, cosa resta? skyos? non vedo sistemi operativi di successo che non siano fortemente legati all'opensource, o completamente opensource, a parte windows. ancora convinto che linux sia l'eccezione che conferma la regola?
Purtroppo sì, perché non mi limito a fare fuori un s.o. soltanto perché non è "di successo". Io li considero tutti, dal primo all'ultimo, perché se sono stati creati a qualcosa saranno pur serviti. Anche il Geos per il Commodore 64...
guarda che e' esattamente quello che voglio cercare di capire.
Questi sono problemi tuoi. Io capisco i tuoi discorsi, ma evidentemente non vale il viceversa (vedi inizio del messaggio).
ho argomentato sulla storia delle decine di kernel,
Idem.
sul fork canceroso,
Idem.
sulla questione di linux come unico sistema operativo opensource.
In buona sostanza, lo è.
ma so gia come andra a finire, saltera fuori che nextstep non era opensource, quindi linux e' un caso anomalo.
Vero, l'avevo dimenticato.
Adesso torniamo coi piedi per terra. Dai tuoi ragionamenti deduco che tu abbia in qualche modo dedotto (!) che penso che l'open source non sia una bella cosa. Adesso ti chiedo: in base a cosa sei arrivato a questa conclusione?
semplice, se usi sufficientemente a lungo software libero, o per lo meno in un certo modo, ti accorgi di come si muovono le cose dietro.
Hai proprio ragione: per parlare di calcio per forza di cose bisogna essere dei calciatori, meglio se professionisti, a questo punto.
Sai una cosa? Sono contento di non essere Totti! :D
l'atteggiamento "il fork e' male,
Arridaje! (giusto per restare in tema ;))
linux e' troppo diviso, ecc..."
Lo è.
lo si riscontra in modo pressoche costante tra gli utenti windows che ne hanno sentito parlare abbastanza e che lo hanno provato un pochino, ma che li si sono fermati, quindi gli esempi e i paragoni usati nella discussione saranno appropriati. tutt'altro tipo di discussione ne nasce con un utente bsd ad esempio.
Ciò non toglie che si può benissimo parlare di un argomento come quello dei driver senza per questo essere degli sviluppatori del kernel, ed è questo il nocciolo della questione. Perché non dovrebbe essere possibile farlo? Perché manca esperienza diretta? Lasciamo perdere...
ma la discussione e' proprio questa. hai usato linux nell'ambito dei programmi x, y, z? bene ma poi? segui o hai seguito la linux kernel mailing list o altri posti? saro strano io, ma non capisco come tu possa pensare che sull'interfaccia dei driver ci fosse disaccordo,
Te l'ho già spiegato e i miei polpastrelli cominciano a ribellarsi, a forza di ripetere sempre le stesse cose...
quando probabilmente e' piu facile trovare discussioni sull'opportunita di non permettere del tutto driver proprietari.
Già: c'è la possibilità di far felice qualcuno che potrebbe accontentarsi, ma siccome i guru hanno deciso che è una cosa brutta, togliemo anche questa possibilità. Bella scelta, non c'è che dire. Ma l'obiettivo finale qual è, quello di far uscire tutti gli utenti Linux dalla stessa fabbrica di pensiero?
anche recentemente, quando alcuni hanno messo in dubbio la legalita del driver binario per la scheda di rete wireless usata su un router linksys l'ultimo dei pensieri e' stato definire una interfaccia stabile per i driver, anzi.
Dovrebbero cominciare a farlo seriamente, invece. Comunque, è fiato sprecato, mi pare...
non e' vero. conta anche come le opinioni vengono formate, come minimo perche si fa prima a dimostrare che sono sbagliate nel caso partano dai presupporti sbagliati.
Ma vogliamo continuare a prenderci in giro? Se i presupposti sono sbagliati, basterà dimostrarlo. E questo a prescindere dal background culturale che uno si porta dietro.
Se dico che l'uomo è prigioniero del suo destino e il libero arbitrio cozza contro l'onniscienza di un ipotetico dio, lo potrò pur fare, anche se non ho mai toccato un libro di filosofia e teologia. Ho le argomentazioni per poterlo fare e sostenere la mia tesi, anche se di fronte a me c'è il cardinale Ratzinger, custode della dottrina della chiesa...
E' chiaro il concetto?
cosa hai visto/letto/sentito per decidere che il fork e' normalmente usato male?
Vedi sopra.
hai visto le statistiche di sourceforge o di freshmeat? se e' davvero usato male perche il software opensource aumenta di diffusione invece di diminuire?
Infatti, il software open source aumenta, ma un s.o. facile da usare come Windows o OS X stenta a decollare. Te lo sei mai chiesto perché? La comunità open source è enorme, rispetto alla gente che viene profumatamente pagata Gates e da Jobs per sviluppare le loro creature. La differenza, però è evidente, tanto più se prendiamo OS X: le risorse (umane) di Apple sono nettamente inferiori rispetto a quelle di MS, ma ha sviluppato la migliore interfaccia grafica PER UN SISTEMA UNIX-LIKE. Una cosa che gli utenti Linux possono solamente sognarsi. E i suoi sviluppatori pure, visto che sono così impegnati con le "n" GUI disponibili per questo sistema.
Che dire: divertitevi a sperimentare le vostre idee... A noi il piacere di godere dei risultati concreti... ;)
anche se possibile tecnicamente lo hanno reso illegale. una volta non era illegale. adesso ci sono leggi che lo vietano.
Stai parlando come se lo stesso valesse per tutto il mondo: diciamo che negli USA la situazione è quella. Per fortuna fuori non è così...
secondo le tendenze attuali il software assurdamente e' l'unico tipo di bene che gode SIA della protezione del copyright, SIA della protezione dei brevetti (un libro non lo puoi brevettare, e una macchina non la puoi pubblicare) piu ovviamente del segreto industriale, e poi di una serie di nuove leggi tipo dmca.
Sempre negli USA però. Non generalizzare...
inoltre mentre la tendenza del software e' quello di divenire obsoleto in tempi sempre piu brevi, e comunque minuscoli rispetto a beni tradizionali, la durata della protezione sui brevetti e sul copyright continua a salire. e nuove leggi che aumentano continuamente la protezione vengono inventate e approvate in continuazione. e' un bene questo per la collettivita?
Non amo i brevetti, e l'ho già scritto diverse volte. Ma non vivo negli Stati Uniti, e per fortuna in questo paese non siamo ridotti come loro...
Resta il fatto che il reverse engineering sarà pure vietato negli USA, ma comunque viene ugualmente praticato, e non solo in ambito informatico (macchine? Dispositivi elettronici?. Ecc.).

x ilsensine: per il messaggio precedente ho perso troppo tempo e debbo tornare a studiare. Avrò modo di risponderti stasera o domattina, se ne vale la pena. Purtroppo, come hai giustamente affermato, abbiano delle nette divergenze d'opinione...
D'altra parte, siamo "diversi", no? ;)

Buona giornata a tutti... :)

Originariamente inviato da cdimauro
D'altra parte, siamo "diversi", no? ;)

Anche tu??
Devo camminare pure io con le spalle al muro? :D

Originariamente inviato da qweasdzxc
il fatto che non ci sia una versione di linux con migliore supporto ai driver binari e' di per se una prova indiziaria che non la si considerava una cosa buona.

Qualcosa del genere è possibile, basta disabilitare il controllo del kernel sulla versione dei simboli.
E' poco nota in quanto nessuno è così pazzo o incosciente da farlo.

Originariamente inviato da cdimauro
Se si vuol far progedire un s.o., bisogna definere dei layer, e quindi delle API/Interfacce, che permettano di omogenizzare la visione del sistema da parte delle applicazioni. Esempio: devo scrivere un'applicazione grafica: quale GUI dovrei scegliere? X? Gnome?
KDE? O passare in rassegna tutte le altre GUI esistenti?
Dammi retta, non portare il discorso in questa direzione, potresti venire a conoscenza di cosette "interessanti" ;)

Originariamente inviato da ilsensine
Vedi le cose in bianco e nero? ;)
Le mie pupille non disdegnano anche il colore, a volte... :p
Non necessariamente devono essere inefficienti; anzi, qnx è architettato per avere latenze bassissime. Solo, utilizzando una struttura a microkernel si rinuncia a un pò di efficienza.
Nota che questo non è a priori un male (in fondo, anche scrivendo in c invece di assembler si rinuncia...a un pò di efficienza :D )
D'accordo (comunque si parla di linguaggio assembly: assembler è l'assemblatore :)). Bisogna vedere quanto si perde. Non penso che si parli di numeri rilevanti... D'altra parte le applicazioni non si mettono a giocare chiamando le API del kernel a josa, no? ;)
Era solo un esempio; vuoi atri casi?
Anche il mio era solo un esempio... ;)
Ok:
Supporto memoria 1GB/4GB/64GB: altre 3 possibilità, ecco che 4*3=12
Ovviamente deduco che stiamo parlando di piattaforma x86. Non pensavo che Linux offrisse supporto addirittura alla PAE per i 36 bit d'indirizzamento della memoria: è un meccanismo un po' contorto... :)
Anche la presenza di una modalità a 1GB vs 4GB mi sorprende: come mai questa scelta, invece di utilizzare soltanto la seconda? Giusto per curiosità, non per altro...
Varianti che influenzano driver specifici:
Per i driver isa, supporto isapnp (può essere presente o meno) e/o pnpbios: 12*4=48
Ma dai, anche per l'ISA c'è bisogno di modalità specifiche?
Varianti che influenzano architetture specifiche:
Su amd64, supporto o meno per l'iommu: 4*2=8
...e tralascio i driver di rete, dove la crescita è "esplosiva" ;)
OK, abbiamo capito: esistono diverse modalità di cui tenere conto... in ambito Linux! Mi spieghi come mai gli altri s.o. riescono a supportare diverse architetture e periferiche con un solo kernel e con un'interfaccia unica per i driver binari?
E' quello che fanno i produttori "intelligenti" di driver closed, come nvidia. Nessuna necessità di accroccare il kernel per i loro comodi, se ne sono già occupati loro (al prezzo di una minore efficienza).
Nota che quelle che tu chiami "funzioni", non sono in realtà sempre tali: possono essere dei define no-op, dei define particolari, o delle funzioni vere e proprie -- dipende dal tipo di compilazione, architettura ecc.
Ovviamente non puoi definire un "puntatore a un define" :D
Lo so. Poi io odio i define...
Veramente quando ho proposto quella soluzione, pensavo ad altro. Generalmente i driver fanno uso dello spazio supervisore e hanno un riferimento ad aree di memoria di sistema comuni, da cui attingere a dati ed eventualmente a codice (sto parlando in generis, non di Linux perché non ne conosco il funzionamento fino a questo punto).
Ecco, pensavo che il kernel, alla partenza, immagazzinasse in un variabile di tipo di puntatore a funzione l'indirizzo della sua routine da utilizzare per assolvere ad un particolare compito. Non è, quindi, il driver che si dovrebbe occupare di gestire tutte le modalità al suo interno (come accade con i driver nVidia), ma il kernel avrebbe già provvededuto a impostare l'indirizzo della giusta routine: per i driver l'unico sforzo sarebbe quello di chiamarla... ;)
Spero di essere stato chiaro.
Riguardo la semplice "ulteriore chiamata", la tlb ringrazia sentitamente ;)
La TLB non deve fare nessuno sforzo addizionale: il codice della routine da chiamare comunque dev'essere presente in memoria, e non saranno 4 o 8 byte in più nello struttura dati di sistema a fare la differenza. L'unico a dover "soffrire" sarà il processore, che dovrà effettuare un load per conoscere l'indirizzo da chiamare: una grande sofferenza, non c'è che dire...
Infatti ce l'hanno da un bel pezzo :D
Saranno un paio d'anni più o meno che ce l'hanno: da quando sono state rilevate delle "strane" esplosioni dai satelliti americani, a conferma della buona :rolleyes: riuscita degli esperimenti. A cui sono seguite le dichiarazioni ufficiali dei due paesi...
Gli altri paesi che citi ci hanno provato, ma l'embargo internazionale (che misteriosamente non è valso per Pak e India) lo ha impedito
Infatti, la cosa strana è che il Pakistan è da sempre stato considerato uno stato pericoloso, per cui gli USA & co. avevano tutto l'interesse a impedire che arrivassero ad armarsi fino al nucleare... Mah.
(alcuni ci sono andati molto vicini però).
E altri lo faranno. La libia ha dichiarato di recente di possedere soluzioni nucleari. E l'abbiamo a 60KM di distanza... :(
In user space le api sono ferree; il kernel non è user space, non è posix, non è nient'altro che il kernel che vogliamo.
E' ovvio che in user space fossero ferree: ci mancherebbe! :) Quel che mi preoccupa, poi, non è tanto la struttura/interfaccia del kernel in sé, quanto quella che deve avere coi driver...
Come detto, esiste a livello di CODICE SORGENTE.
La vuoi anche a livello di compatibilità binaria? Se ne è discusso, e non è stato trovato un motivo sufficiente per giustificarla (fare contenta nvidia _non_ è un motivo sufficiente)
OK. Il discorso qui si è arenato, ormai. Ho detto chiaramente come la penso: tutti gli altri s.o., che girano anche su architetture e hardware diversi, non hanno di questi problemi e offrono un'interfaccia unica a livello di driver. Linux non è così, e a questo punto penso che non lo sarà mai: se siete contenti così, buon per voi.
Perché siamo un gruppo di matti, che hanno stabilito delle regole matte, ma che hanno dato risultati impensabili.
Chiunque è libero di "accodarsi" se lo ritiene economicamente vantaggioso, ma non possono obbligarci a cambiare le regole che ci hanno portato al successo di oggi.
Benissimo. Ne prendo atto: siamo gente libere. Ma allo stesso modo, non potete lamentarvi se non ricevete adeguato supporto o addirittura pretenderlo, perché siete gli unici a percorrere questa bizzarra strada...
Linus ha detto: "posso non condividere quello che fai con il mio kernel, ma non farò nulla per impedirti di farlo".
Sono liberi di rilasciare driver closed; sono libero di dire "no grazie".
Non c'è problema, ma:
1) se c'è qualcuno nella vostra comunità che si accontenterebbe, non obbligatelo a seguire i dettami per una lotta a oltranza nei confronti dei driver binari decisa dai "guru"
2) assumetevi le responsabilità delle vostre scelte e non scaricatele sulle spalle di chi ha deciso di non seguire la vostra strada, qualunque sia il motivo.

Anche tu??
Devo camminare pure io con le spalle al muro? :D
Coi tempi che corrono, non si sa mai: potresti trovare una "sorpresa"... ;)

Qualcosa del genere è possibile, basta disabilitare il controllo del kernel sulla versione dei simboli.
E' poco nota in quanto nessuno è così pazzo o incosciente da farlo.
Eccomi! Spiega, spiega: cos'è questa cosa così interessante? :D

Dammi retta, non portare il discorso in questa direzione, potresti venire a conoscenza di cosette "interessanti" ;)
Ma guarda che a me può soltanto fare piacere se hanno deciso finalmente di rilasciare un'API comune per le applicazioni grafiche. L'ho detto altre volte: non sono pro Windows / anti Linux, ecc. A me interessa disquisire del tecnico, a prescindere da ogni legame con ciò che sto utilizzando attualmente.
Poi questa sarà una delle poche volte in cui arricchisco il mio bagaglio culturale grazie al forum...

Originariamente inviato da cdimauro
Ovviamente deduco che stiamo parlando di piattaforma x86. Non pensavo che Linux offrisse supporto addirittura alla PAE per i 36 bit d'indirizzamento della memoria: è un meccanismo un po' contorto... :)
Ogni architettura ha le sue bizzarrie. Non so se altri processori hanno una modalità highmem (alcune sì mi sembra); ma ad es. posso usare NUMA per gestire la memoria non contigua degli ARM, usare l'iommu sull'amd64 per i dispositivi pci che non possono gestire lo spazio dma a 64 bit, più varie ed eventuali per SPARC, MAC ecc.

Anche la presenza di una modalità a 1GB vs 4GB mi sorprende: come mai questa scelta, invece di utilizzare soltanto la seconda? Giusto per curiosità, non per altro...
Il kernel ha a disposizione 1GB di indirizzi virtuali (3GB sono riservati per lo user space). Su questi indirizzi, per motivi ovvi di efficienza, può mappare direttamente fino a quasi 1GB di RAM (896 MB per la precisione). Per accedere all'altra RAM, deve effettuare un mapping apposito. E' semplice da fare, ma ha un overhead sulle tabelle di paginazione. Io ho in ufficio un PC con 1GB di RAM, e per evitare di usare la modalità 4GB per una manciata di memoria in più, ho modificato la separazione spaziale dando al kernel 1.5GB di indirizzi virtuali. Quindi il mio kernel è "l'ennesima versione" incompatibile con i driver proprietari, pur non avendo in effetti toccato i sorgenti (tranne che un unico #define :D )
HIGHMEM64GB è una variante sostanzialmente diversa, dove viene fatto uso della PAE.


Ma dai, anche per l'ISA c'è bisogno di modalità specifiche?

No non è necessario, ma se si vuole si possono usare dei supporti che aiutano l'autorilevamento e gestione delle risorse per i dispositivi isapnp.


Lo so. Poi io odio i define...
Dipende. Scrivere una funzione per delle fesserie (ad es. gli spinlock) che richiedono poche righe di assembly ad esempio è assurdo. Lo stesso vale per alcune funzioni inline, corte ma di uso frequente.


La TLB non deve fare nessuno sforzo addizionale
Quando chiami una funzione, non sfrutti la pre-esecuzione delle istruzioni successive.


E altri lo faranno. La libia ha dichiarato di recente di possedere soluzioni nucleari. E l'abbiamo a 60KM di distanza... :(
Sì e Lampedusa ancora ha nelle orecchie il fischio di quel famoso missile... :D

Non c'è problema, ma:
1) se c'è qualcuno nella vostra comunità che si accontenterebbe, non obbligatelo a seguire i dettami per una lotta a oltranza nei confronti dei driver binari decisa dai "guru"
Puoi indicare una regola per stabilire "cosa può essere closed e cosa libero"? Perché questo discorso si può estendere alle altre parti del kernel, fino ad averlo tutto closed source...perché i driver del Centrino sì, e ad es. l'acpi no?

2) assumetevi le responsabilità delle vostre scelte e non scaricatele sulle spalle di chi ha deciso di non seguire la vostra strada, qualunque sia il motivo.

Noi ci assumiamo la responsabilità delle nostre scelte, loro si assumeranno la responbilità delle loro.
Devo confessarti che mi viene un sadico ghigno quando dico "no grazie" a quei fornitori che non hanno supporto per linux :cool:


Ma guarda che a me può soltanto fare piacere se hanno deciso finalmente di rilasciare un'API comune per le applicazioni grafiche.
Non c'è una vera e propria API comune (o meglio, c'è ma nessun pazzo la usa). Però....
....magari ne riparleremo quando ho un pò più di tempo.

Eccomi! Spiega, spiega: cos'è questa cosa così interessante? :D

Il nome dei simboli del kernel (e dei moduli) è composto dal nome C "semplice", più un suffisso che dipende dalla versione ("nome") del kernel, e da alcuni parametri (tipo smp o altro). Questo impedisce il caricamento di un modulo precompilato per una versione diversa del kernel.
Questo suffisso si può evitare all'atto della configurazione del kernel, e pregare che i moduli compilati per altri kernel/configurazioni funzionino ugualmente. Normalmente il risultato è un bel kernel oops :cool:

Originariamente inviato da ilsensine
Dipende. Scrivere una funzione per delle fesserie (ad es. gli spinlock) che richiedono poche righe di assembly ad esempio è assurdo. Lo stesso vale per alcune funzioni inline, corte ma di uso frequente.
Già. Il fatto è che a me proprio non piace il C come linguaggio, ma purtroppo sono costretto a lavorarci spesso. E ogni volta che debbo usare una #define per definire costanti o macro mi sento male... :cry:
Quando chiami una funzione, non sfrutti la pre-esecuzione delle istruzioni successive.
Sì, certamente c'è una leggera perdita prestazionale: il caso peggiore è dato dal fatto che la call sia la prima istruzione del lotto da eseguire nel ciclo corrente; quando, però, è l'ultima istruzione del lotto, non v'è alcuna perdita.
Comunque, se pensiamo a quante chiamate indirette sono presenti nel codice, specialmente se si fa uso di classi, queste pochissime occasioni in cui sarebbe necessario utilizzarle nei driver sarebbe statisticamente irrilevante...
Sì e Lampedusa ancora ha nelle orecchie il fischio di quel famoso missile... :D
Beh, non credere che dove abito sia tanto più distante... :eek:
Puoi indicare una regola per stabilire "cosa può essere closed e cosa libero"? Perché questo discorso si può estendere alle altre parti del kernel, fino ad averlo tutto closed source...perché i driver del Centrino sì, e ad es. l'acpi no?
E' chiaro che non esiste nessuna regola, a parte il buon senso: bastarebbe dare la possibilità, a chi lo vorrebbe, di poter utilizzare i driver binari, senza precluderlo a priori. Tutto ciò con la consapevolezza che potrebbero sorgere eventuali problemi, da imputare esclusivamente a tale scelta "non ortodossa" nei confronti della linea di pensiero degli sviluppatori.
Noi ci assumiamo la responsabilità delle nostre scelte, loro si assumeranno la responbilità delle loro.
Devo confessarti che mi viene un sadico ghigno quando dico "no grazie" a quei fornitori che non hanno supporto per linux :cool:
Appunto. Come dicevo prima, la differenza la farà il mercato... ;)
Non c'è una vera e propria API comune (o meglio, c'è ma nessun pazzo la usa). Però....
....magari ne riparleremo quando ho un pò più di tempo.
Non c'è problema: ti ringrazio, comunque, per le informazioni che m'hai fornito finora...

A buon rendere. :)