In arrivo i driver Linux per Intel Centrino

[qweasdzxc]

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?

[qweasdzxc]

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...

[abe.flagg]

qweasdzxc ...

la mia ammirazione per te è grande

[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.

[Leron]

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

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

[cdimauro]

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.

[ilsensine]

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.

[qweasdzxc]

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.

[cdimauro]

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...
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!

[cdimauro]

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.

[cdimauro]

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...

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.

[cdimauro]

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!

[ilsensine]

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!)

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...

_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 )





(*) Informazione negata ad uno sviluppatore dalla ATI

[ilsensine]

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

[qweasdzxc]

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?

[cdimauro]

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.

[cdimauro]

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.

[cdimauro]

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...

[qweasdzxc]

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?

[ilsensine]

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 )

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"
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
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