|
Originariamente inviato da jappilas
secondo me il punto non è tanto la frase in bold, cioè il fatto in sè stesso che MS voglia fare soldi quanto il fatto che il SW da lei prodotto sia distribuito in sola forma binaria, e miri a interfacciarsi con altro SW, di cui si abbiano solo i rispettivi file binari, o di cui anche disponendo dei sorgenti, la ricompilazione non sia necessaria
questo, implica la necessità di uniformare in parte le interfacce binarie (*),le API di sistema e la configurazione di base del working environment: questo è stato anche fatto per facilitare la vita agli stessi sviluppatori interni a MS, per permettere a team diversi di lavorare su kernel, strumenti di sviluppo e applicazioni indipendentemente l' uno dall' altro e solo basandosi sulle interfaccie tra sottosistemi che uno o l' altro gruppo pubblicava
(*)AFAIK, anche se le API di alto livello e di interazione userland/ kernel sono standardizzate, la situazione è leggermente meno chiara a livello di internals del kernel: alcune strutture dati sono ancora non documentate, come ben sanno gli sviluppatori del progetto ReactOS (è da tenere presente comunque la struttura backward compatible del Windows Driver Model - WDM, tale da permettere a un driver sviluppato per Win2000 di caricarsi e funzionare immodificato su Win Server 2003, anche se non viceversa)
Una motivazione "ufficiosa" la diede, se non ricordo male, Raymond Chen su un blog, affermando grossomodo "publishing the interfaces would prevent us from changing them forever, and i mean forever": cioè documentare delle interfacce e strutture dati di basso livello, di cui potenzialmente si potrebbe compiere una modifica senza preavviso, se utile all' ottenimento di migliori prestazioni o funzionalità o sicurezza o... , equivarrebbe a scolpirle nella pietra
Ed è per ragioni simili , oltre ad altre peculiari, che nel corso degli ultimi anni sento di Linux (o meglio, dei luogotenenti di Torvalds) l' aborrire le interfacce binarie invarianti a livello di kernel (fatto salvo che da qualche tempo la kernel abi e la syscall table sembrino essersi stabilizzate, dopo un periodo in cui passare da una kernel release ad un' altra richiedeva spesso e volentieri anche la ricompilazione dell' userland... per quanto ho qualche timore che possa essere la ABI del GCC a variare con una major relase)
il problema sarebbe che fissare le ABI per i moduli del kernel, limiterebbe o bloccherebbe l' innovazione a basso livello, non potendo più contare sulla possibilità di agire sul design del kernel nel complesso, per far funzionare nuove funzionalità (ad esempio nuovi meccanismi di gestione dei processi, della memoria nuovi filesystem) che si intende aggiungere
inoltre, si teme che avere ABI invarianti possa facilitare (a parte gli utenti finali, incidentalmente) solo i produttori di HW proprietario con specifiche riservate: questi forse si sentiranno avvallati a fornire solo dei blob, e magari anche quelli che prima aprivano le specifiche, o fornivano driver aperti, seguiranno l' esempio di ati
ora, per allontanare lo spauracchio di un simile scenario, e per ribadire la propria distanza dall' atteggiamento pragmatico dei progetti open source (qualii i BSD, che accettano per esempio di includere dei frammenti binari per supportare ad, chipset wireless o schede grafiche, purchè il sistema funzioni) Linux lotta strenuamente contro le interfaccie invarianti, che possono trasformarsi in una limitazione della libertà...
Per questo direi che non sia un discorso solo finanziario... anzi è tutto incentrato sulla filosofia (prima quella generale, poi quella di design, che sulla prima si forma per realizzare l' obiettivo)
|