In arrivo i driver Linux per Intel Centrino

[cdimauro]

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.

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

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.

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

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!

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

[cdimauro]

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

[ilsensine]

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

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

[ilsensine]

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.

[ilsensine]

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"

[cdimauro]

Originariamente inviato da ilsensine
Vedi le cose in bianco e nero?

Le mie pupille non disdegnano anche il colore, a volte...

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

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

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

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?

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

[ilsensine]

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

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

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.

[ilsensine]

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

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

[cdimauro]

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

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

Beh, non credere che dove abito sia tanto più distante...

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

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.