Requisiti di sistema di Windows 10 per sistemi desktop e mobile

[frankie]

Praticamente windows 10 ha meno requisiti di Vista...

[Unrealizer]

Originariamente inviato da frankie

Praticamente windows 10 ha meno requisiti di Vista...

Anche 8.1 Update li aveva più bassi di Vista

[cdimauro]

Originariamente inviato da bobafetthotmail

Il problema dei clover trail sono i driver per la grafica PowerVR che non è opensource nè ottenibile se non sei un OEM perchè ad Imagination Technologies sono dei vigliacchi. Il resto del SoC è supportato dal kernel (perchè Intel ha aggiunto il supporto), ma senza la GPU in un tablet ci fai poco.

Stesso problema della GMA500/GMA600 e della GMA3600 sugli Atom Cedar Trail (driver scarsi o assenti, specialmente 64 bit), sempre Imagination Technologies che sono dei vigliacchi.

E il motivo per cui li tratto in malo modo non è tanto il mancato supporto per Linux che vabbè, ma che per i Cedar Trail non hanno fatto i driver neanche per windows a 64 bit nonostante vari Atom di quella serie potessero montare 4 GB di ram e tutti supportassero i sistemi operativi a 64 bit.

La politica di certe aziende può piacere o meno, ma non mi pare corretto etichettarla come "vigliacca".

Il supporto che chiedi non è gratis, ma richiede risorse da investire, ed è l'azienda che deve ovviamente tirare fuori il vil denaro. Ciò avviene se ritiene che possa ricavarne un profitto, com'è giusto e ovvio che sia.

Evidentemente Imagination non ritiene profittevole lo sviluppo di driver, a 32 o 64 bit che siano, per Linux. Né tanto meno è tenuta a rilasciarne i sorgenti nel caso in cui abbia deciso di fornire i binari.

Tra l'altro non è la prima e nemmeno l'ultima azienda che si comporta così. Mi pare che il blasonato Raspberry Pi abbia un SoC di cui l'azienda, Broadcom, rilasci soltanto i binari per il s.o. che ci gira sopra: Linux. Con tutte le problematiche del caso.

D'altra parte il problema è anche di Linux, che non offre un'adeguata stabilità in termini di API/ABI/driver model, al contrario di quello che offrono altri s.o., anche open source. Basti vedere il lavoro che deve fare nVidia per mettere a disposizione un blob che funzioni con diverse versioni / configurazioni di Linux...

[bobafetthotmail]

Originariamente inviato da cdimauro

Evidentemente Imagination non ritiene profittevole lo sviluppo di driver, a 32 o 64 bit che siano, per Linux.

Ti ripeto l'ultima frase del mio post visto che chiaramente non l'hai letta:

"E il motivo per cui li tratto in malo modo non è tanto il mancato supporto per Linux che vabbè, ma che per i Cedar Trail non hanno fatto i driver neanche per windows a 64 bit nonostante vari Atom di quella serie potessero montare 4 GB di ram e tutti supportassero i sistemi operativi a 64 bit."

Ora, loro sono chiaramente liberi di fare quello che vogliono, ma non rilasciare driver a 64 bit quando hai già i driver a 32 è oggettivamente da vigliacchi e non ho pietà perchè non posso averne. Non sto parlando di Linux, ma di Windows.

Cribbio Intel ha anche cercato di rilasciare i driver proprietari per linux a 32 bit estraendoli dagli SDK di IT (sonocompilati per funzionare solo ed esclusivamente con i kernel ed i backend alle versioni in cui il driver è stato rilasciato, ovviamente, quindi sono completamente inutili da anni).
https://downloadcenter.intel.com/download/21938

Mi pare che il blasonato Raspberry Pi abbia un SoC di cui l'azienda, Broadcom, rilasci soltanto i binari per il s.o. che ci gira sopra: Linux.

Ma magari. Veramente, magari. Non sono "per Linux", sono solo "per un OS linux col kernel alla versione che diciamo noi e che usa i backend che usano le distro maggiori ma alla versione che diciamo noi" (come i driver Nvidia del resto, se kernel, Mesa e Xorg non hanno la versione giusta è instabile o non va), quindi la roba custom come ad esempio Android per quanto linux come kernel è brutalmente tagliata fuori e per farlo andare bisogna fare quintali di hackeraggio creativo e aggiungere dei layer di compatibilità o lasciarla in software rendering (che su un Raspberry va che è una bellezza come puoi immaginare).

Le uniche immagini e video di Android che gira su Raspberry non in software rendering prova ad indovinare chi le ha fatte? la Broadcom, probabilmente per sfottere visto che poi il supporto non è mai arrivato.

D'altra parte il problema è anche di Linux, che non offre un'adeguata stabilità in termini di API/ABI/driver model, al contrario di quello che offrono altri s.o., anche open source.

Quali altri OS opensource offrono una adeguata stabilità?
I kernel tipo BSD sono a sviluppo molto più lento per altre ragioni.

Il driver model di linux è molto semplice, Opensource o GTFO http://www.linuxfoundation.org/colla...icedrivermodel

Quindi esaminiamo le due scelte possibili

1. lo fai opensource e allora te lo integrano nel kernel e distribuiscono automaticamente, mantengono tutto aggiornato e funzionante quando il kernel cambia, sistemano bug e incompatibilità che tu non avresti tempo di gestire, fanno funzionare tutto anche su altre architetture se necessario, e tutto aggratis se l'hardware è abbastanza popolare. Certo il driver lo devi scrivere tu e devi fornire documentazione decente, ma il resto lo fanno altri (comunque generalmente le aziende che ci tengono hanno qualche sviluppatore che tien dietro alla cosa).

2. se decidi di non farlo opensource son cavoli tuoi far funzionare tutto e non importa a nessuno che su Windows, OSX e ChessòOS è l'OS che si fa carico di avere una piattaforma stabile per i tuoi driver, Linux =! Windows e si dovrebbe già capire dal nome. Sei solo e nessuno ascolta le tue lamentele.

Questo approccio permette un livello di stabilità e di facilità di utilizzo (cosiddetta "it just works") che Windows non si sogna neanche la notte se parliamo di far funzionare hardware gestito da driver opensource, anche se è roba preistorica o solo vecchia di 3 anni e chi fa i driver non ha alcuna voglia di farli per la nuova versione di Windows o aggiornarli per funzionare lo stesso dopo l'ennesima patch di Windows (e non c'è modo di farli andare in modalità di compatibilità).
E tutta questa stabilità e facilità di utilizzo estrema per l'utente finale avvengono mentre il kernel evolve con una rapidità mai vista in Windows dove il kernel è grosso modo lo stesso da 10 anni, come anche il file system.
Casi esemplificativi:
Driver video VIA. Molti vanno solo su XP, e anche lì devi avere culo.
Chiavette wifi di sottomarche. I loro driver fanno generalmente schifo e spesso è necessario cercare i driver per il chip utilizzato da altre fonti, per Windows. Per linux basta che il chip sia supportato dai driver open e va tutto come andrebbe coi migliori driver disponibili, sbattimento 0.
Stampanti e scanner, tastiere gaming, mouse gaming, controller e altri dispositivi di input particolari. Su linux una volta che vanno grazie ad un driver open andranno per sempre (finchè non si rompono o diventano effettivamente obsolete o così rare e di nicchia che nessuno aggiorna più il driver).

Se chi sviluppa i driver non segue il driver model di linux facendo blob proprietari senza rilasciare documentazione alcuna poi non deve frignare che fa fatica a tenere le cose aggiornate e le cose non vanno e ancora lamentarsi che i loro driver rendono linux instabile e che linux fa schifo perchè non è windows.

Ha voluto la bicicletta? Ora pedala.
Non gli piace? Non è costretto da nessuno a fare driver per linux. Può dire che non lo supporta e lavarsene le mani.
Ma dopo chi glie lo dà un sistema da mettere dentro ai sistemi embedded che tengono su il mondo civilizzato? Se lo vuole fare lui? Vuole metterci Windos CE o 10 che poi quando ha il monopolio fa pagare 50 euro di licenza a caso?
E i supercomputer o i nodi di calcolo distribuito? Ci mettiamo Windows su tutti? Poi chi li sente quelli che devono ottimizzare il sistema e si scontrano con il fatto che Windows è closed source e non c'è modo di ottenere modifiche custom ai file di sistema?
Oh, è un caso di botte piena e moglie ubriaca, ma colpa di linux non è.
I patti sono sempre stati chiari, opensource o GTFO. Chi fa la scelta del blob proprietario si assume le responsabilità del caso, e tutti i problemi di compatibilità del suo codice con il mondo linux diventano automaticamente responsabilità sua, non di linux.

AMD sta recentemente passando ad una strategia furba che tiene conto di queste cose per il suo driver video su linux.
http://www.phoronix.com/scan.php?pag...t_kernel&num=1
Il driver opensource e il driver proprietario condividono le stesse infrastrutture a livello di kernel, quindi il blob proprietario è una specia di addon ad un driver principalmente opensource più che un driver aggiuntivo.

In questo modo sprecherebbe molte meno risorse per tenere sempre tutto aggiornato come fa Nvidia, visto che il blob proprietario fa solo alcune cose e non si interfaccia direttamente con il kernel (e credo neanche con i backend di linux).

[cdimauro]

Originariamente inviato da bobafetthotmail

Ti ripeto l'ultima frase del mio post visto che chiaramente non l'hai letta:

"E il motivo per cui li tratto in malo modo non è tanto il mancato supporto per Linux che vabbè, ma che per i Cedar Trail non hanno fatto i driver neanche per windows a 64 bit nonostante vari Atom di quella serie potessero montare 4 GB di ram e tutti supportassero i sistemi operativi a 64 bit."

L'avevo già letta.

Ora, loro sono chiaramente liberi di fare quello che vogliono, ma non rilasciare driver a 64 bit quando hai già i driver a 32 è oggettivamente da vigliacchi e non ho pietà perchè non posso averne. Non sto parlando di Linux, ma di Windows.

Non bisogna avere pietà, infatti, ma le risorse per realizzare i driver a 64-bit. Anche se fosse per Windows.

Cribbio Intel ha anche cercato di rilasciare i driver proprietari per linux a 32 bit estraendoli dagli SDK di IT (sonocompilati per funzionare solo ed esclusivamente con i kernel ed i backend alle versioni in cui il driver è stato rilasciato, ovviamente, quindi sono completamente inutili da anni).
https://downloadcenter.intel.com/download/21938

Evidentemente era Intel ad avere interesse a supportare anche Linux.

Ma magari. Veramente, magari. Non sono "per Linux", sono solo "per un OS linux col kernel alla versione che diciamo noi e che usa i backend che usano le distro maggiori ma alla versione che diciamo noi" (come i driver Nvidia del resto, se kernel, Mesa e Xorg non hanno la versione giusta è instabile o non va), quindi la roba custom come ad esempio Android per quanto linux come kernel è brutalmente tagliata fuori e per farlo andare bisogna fare quintali di hackeraggio creativo e aggiungere dei layer di compatibilità

Chiaro. Ma chi ha interesse a utilizzare qualcosa di diverso? Una distro Linux, alla fine, il Raspberry ce l'ha già.

o lasciarla in software rendering (che su un Raspberry va che è una bellezza come puoi immaginare).

So bene come funziona, visto che sto lavorando a una soluzione simile per AROS (sperando che funzioni), che non ha nemmeno quel supporto (può contare soltanto sulla modalità video impostata da GRUB, quando la scheda video non è supportata; e purtroppo capita spesso).

Ci sono s.o. open source che sono messi molto peggio rispetto a Linux.

Le uniche immagini e video di Android che gira su Raspberry non in software rendering prova ad indovinare chi le ha fatte? la Broadcom, probabilmente per sfottere visto che poi il supporto non è mai arrivato.

Non penso che una multinazionale si diverta a dilapidare risorse per sfottere i suoi stessi clienti. Avranno avuto dei problemi.

Quali altri OS opensource offrono una adeguata stabilità?

Haiku, AROS, ... ReactOS ( ).

I kernel tipo BSD sono a sviluppo molto più lento per altre ragioni.

Che abbiano meno sviluppatori è ovvio, ma questo non significa che non possano decidere di stravolgere il driver model a ogni nuova idea.

Hai delle informazioni diverse su quali sarebbero le "altre ragioni"?

Il driver model di linux è molto semplice, Opensource o GTFO http://www.linuxfoundation.org/colla...icedrivermodel

Quindi esaminiamo le due scelte possibili

1. lo fai opensource e allora te lo integrano nel kernel e distribuiscono automaticamente, mantengono tutto aggiornato e funzionante quando il kernel cambia, sistemano bug e incompatibilità che tu non avresti tempo di gestire, fanno funzionare tutto anche su altre architetture se necessario, e tutto aggratis se l'hardware è abbastanza popolare. Certo il driver lo devi scrivere tu e devi fornire documentazione decente, ma il resto lo fanno altri (comunque generalmente le aziende che ci tengono hanno qualche sviluppatore che tien dietro alla cosa).

Quindi:
- non è gratis;
- devi per forza rilasciare delle TUE proprietà intellettuali e/o codice.

Soluzione che, quindi, può non essere desiderabile o addirittura possibile (se fai uso di prodotti di terze parti).

2. se decidi di non farlo opensource son cavoli tuoi far funzionare tutto e non importa a nessuno che su Windows, OSX e ChessòOS è l'OS che si fa carico di avere una piattaforma stabile per i tuoi driver, Linux =! Windows e si dovrebbe già capire dal nome.

Non dovrebbe essere Is Not Unix?

Sei solo e nessuno ascolta le tue lamentele.

E quindi fai quello che ti pare e fornisci il supporto che ti pare. Se poi sono i clienti a lamentarsi, puoi evitare di ascoltarli perché hanno scelto il s.o. sbagliato.

Questo approccio permette un livello di stabilità e di facilità di utilizzo (cosiddetta "it just works") che Windows non si sogna neanche la notte se parliamo di far funzionare hardware gestito da driver opensource,

Come Noveau o i driver open source per le schede video AMD?

anche se è roba preistorica o solo vecchia di 3 anni

Beh, mi pare che pure Linux tagli il supporto all'hardware più vecchio. Ad esempio l'80386 non è più supportato, come pure le schede 3DFX. Tanto per fare un paio di nomi blasonati.

e chi fa i driver non ha alcuna voglia di farli per la nuova versione di Windows o aggiornarli per funzionare lo stesso dopo l'ennesima patch di Windows (e non c'è modo di farli andare in modalità di compatibilità).

Questi si chiamano bug, non cambio di API/ABI/Driver model.

E tutta questa stabilità e facilità di utilizzo estrema per l'utente finale avvengono mentre il kernel evolve con una rapidità mai vista in Windows dove il kernel è grosso modo lo stesso da 10 anni, come anche il file system.

Il che non è necessariamente un male. Anzi. Il kernel di Windows è molto stabile, e NTFS è un eccellente filesystem.

Casi esemplificativi:
Driver video VIA. Molti vanno solo su XP, e anche lì devi avere culo.

Esiste ancora Via?

Chiavette wifi di sottomarche. I loro driver fanno generalmente schifo e spesso è necessario cercare i driver per il chip utilizzato da altre fonti, per Windows. Per linux basta che il chip sia supportato dai driver open e va tutto come andrebbe coi migliori driver disponibili, sbattimento 0.
Stampanti e scanner, tastiere gaming, mouse gaming, controller e altri dispositivi di input particolari. Su linux una volta che vanno grazie ad un driver open andranno per sempre (finchè non si rompono o diventano effettivamente obsolete o così rare e di nicchia che nessuno aggiorna più il driver).

Tutto ciò si potrebbe tranquillamente applicare a Windows, se ci fosse qualcuno che sviluppasse i driver, siano essi open o closed. Con l'indiscutibile vantaggio che Windows offre agli sviluppatori una maggior stabilità di API/ABI/Driver model...

Se chi sviluppa i driver non segue il driver model di linux facendo blob proprietari senza rilasciare documentazione alcuna poi non deve frignare che fa fatica a tenere le cose aggiornate e le cose non vanno e ancora lamentarsi che i loro driver rendono linux instabile e che linux fa schifo perchè non è windows.

Ha voluto la bicicletta? Ora pedala.
Non gli piace? Non è costretto da nessuno a fare driver per linux. Può dire che non lo supporta e lavarsene le mani.

Ma infatti è quel che personalmente farei. Non ha senso sputare sangue su una piattaforma così instabile.

Ma dopo chi glie lo dà un sistema da mettere dentro ai sistemi embedded che tengono su il mondo civilizzato? Se lo vuole fare lui? Vuole metterci Windos CE o 10 che poi quando ha il monopolio fa pagare 50 euro di licenza a caso?

Se proprio non piace Windows, andrebbe bene NetBSD? Vedi la PSP di Sony, per esempio. Per lo meno è commercial-friendly (niente licenze virali) ed è di gran lunga più stabile a livello di API/ABI/Driver model.

Rimanendo sul closed, è interessante anche QNX per applicazioni mission-critical. Sul versante open, ma con tutela delle proprie IP, ci sarebbe pure FreeRTOS.

E i supercomputer o i nodi di calcolo distribuito? Ci mettiamo Windows su tutti? Poi chi li sente quelli che devono ottimizzare il sistema e si scontrano con il fatto che Windows è closed source e non c'è modo di ottenere modifiche custom ai file di sistema?

Veramente il sorgente di Windows è possibile ottenerlo, con particolari accordi con Microsoft.

E i file di sistema si possono pure sostituire.

Oh, è un caso di botte piena e moglie ubriaca, ma colpa di linux non è.

Ma nemmeno di chi vorrebbe tenersi strettamente in casa IP e/o codice, visto che hanno un certo valore.

I patti sono sempre stati chiari, opensource o GTFO. Chi fa la scelta del blob proprietario si assume le responsabilità del caso, e tutti i problemi di compatibilità del suo codice con il mondo linux diventano automaticamente responsabilità sua, non di linux.

Assolutamente d'accordo. Per questo personalmente non vi spenderei un solo centesimo e preferirei adottare qualche altra piattaforma che tuteli meglio quanto detto sopra.

AMD sta recentemente passando ad una strategia furba che tiene conto di queste cose per il suo driver video su linux.
http://www.phoronix.com/scan.php?pag...t_kernel&num=1
Il driver opensource e il driver proprietario condividono le stesse infrastrutture a livello di kernel, quindi il blob proprietario è una specia di addon ad un driver principalmente opensource più che un driver aggiuntivo.

In questo modo sprecherebbe molte meno risorse per tenere sempre tutto aggiornato come fa Nvidia, visto che il blob proprietario fa solo alcune cose e non si interfaccia direttamente con il kernel (e credo neanche con i backend di linux).

Che richiede tanto lavoro. Ma chiedere che la piattaforma Linux rimanga stabile a livello di API/ABI/Driver model sarebbe troppo? Il che non vuol dire evitare di fare cambiamenti radicali, ma... ogni tot di anni. Così gli sviluppatori posso gestire molto meglio il supporto al s.o., senza dover rilasciare per forza prodotti che siano legati a specifiche distro e/o versioni del kernel (come capita anche con alcuni prodotti della mia azienda, che non ha certo risorse illimitate).

[randorama]

premetto che non voglio trollare, giuro.

ho in cantina un rottamaccio messo insieme con gli scarti.
è un sempron 3000 con 2 giga di ram (3 dimm rigorosamente spaiate) e una nvidia 6600.
ce la faccio a installarcelo ? (anche se la cpu supporta i 64 bit mi contenterei della versione a 32).

[Unrealizer]

Originariamente inviato da randorama

premetto che non voglio trollare, giuro.

ho in cantina un rottamaccio messo insieme con gli scarti.
è un sempron 3000 con 2 giga di ram (3 dimm rigorosamente spaiate) e una nvidia 6600.
ce la faccio a installarcelo ? (anche se la cpu supporta i 64 bit mi contenterei della versione a 32).

se la CPU supporta SSE3 ce la dovrebbe fare

[bobafetthotmail]

Originariamente inviato da cdimauro

Non bisogna avere pietà, infatti, ma le risorse per realizzare i driver a 64-bit. Anche se fosse per Windows.

Mi sembrava che se hai i driver a 32 bit fare la versione a 64 bit non costituisse uno sforzo faraonico.

Cioè, i driver a 32 bit di solito girano anche senza modifiche in windows a 64 bit....

Chiaro. Ma chi ha interesse a utilizzare qualcosa di diverso? Una distro Linux, alla fine, il Raspberry ce l'ha già.

Ma chi lo sa? è una dev board. Se la blocchi ad un kernel, ad un mesa ed and un xorg specifici fai scelte a priori.

Non penso che una multinazionale si diverta a dilapidare risorse per sfottere i suoi stessi clienti. Avranno avuto dei problemi.

O avranno ricevuto ordine di non farlo dal management, anche le compagnie cambiano idea. Comunque ero sarcastico.

Haiku, AROS, ... ReactOS ( ).

Wow. Mi chiedo perchè linux sia così gettonato con delle così valide alternative.

No seriamente, ReactOS? Roba basata su BeOS?

Aros sembra carino.

Che abbiano meno sviluppatori è ovvio, ma questo non significa che non possano decidere di stravolgere il driver model a ogni nuova idea.
Hai delle informazioni diverse su quali sarebbero le "altre ragioni"?

Che sono ancorati a filosofie ancora più radicali di Linux, la filosofia Unix principalmente.
Ad esempio FreBSD continua a gestire i sottosistemi video come anche Linux faceva eoni fa, perchè più aderente alla filosofia Unix.
Solo ora si sono svegliati e hanno capito che se non lo fanno gli ridono in faccia tutti e stanno modernizzando.

Quindi:
- non è gratis;
- devi per forza rilasciare delle TUE proprietà intellettuali e/o codice.

-Costa meno sul lungo periodo, eccheccavolo vuoi che ti scrivano loro il driver?
-ci sono prove che farlo mandi in rovina la ditta? O che non ci sono altri modi per proteggere gli IT della ditta? No perchè a parte Intel che è in semi-monopolio da sempre sono in tanti a rilasciare driver open e non è ancora fallito nessuno per averlo fatto.

Il firmware del dispositivo (se non è flashato nella scheda ma viene caricato dal driver) te lo lasciano tenere closed source comunque (è evidente che ci infileranno le loro IT più importanti invece che lasciarle nel driver).
Vale per tutte le GPU, le schedine wifi, e varia altra roba assortita.

Comunque, da un punto di vista puramente ideale, se tutti facessero driver opensource sarebbe molto facile vedere chi copia chi, e la licenza GPL non è acqua, ha valore legale.

Soluzione che, quindi, può non essere desiderabile o addirittura possibile (se fai uso di prodotti di terze parti).

Questo è un problema della ditta, linux non si impone su nessuno, è la ditta che nella sua piena facoltà di decidere sceglie di fare una cosa poco pratica.
Problema di management, non di Linux.

E quindi fai quello che ti pare e fornisci il supporto che ti pare. Se poi sono i clienti a lamentarsi, puoi evitare di ascoltarli perché hanno scelto il s.o. sbagliato.

Questo vale a prescindere dall'OS, non vedo come sia rilevante. Trattare male i clienti senza una buona ragione non è una buona idea comunque.
Anche Intel, che non è certo in una condizione precaria si è affrettata ad urlare ai 4 venti che i suoi nuovi Atom con GPU PowerVR non saranno supportati da linux nè da sistemi operativi a 64 bit.
Non vogliono ripetere l'errore del 2012 dove non hanno detto nulla assumendo che tutti ci avrebbero messo Win a 32 bit e basta, e poi si sono trovati nei forum e al supporto tecnico uragani di flame da utenti Windows e Linux incavolati come delle puzzole.
Ci sono ancora thread dell'epoca pieni di flame verso Intel in giro, tanto per dire la reazione.

Veramente il sorgente di Windows è possibile ottenerlo, con particolari accordi con Microsoft.
E i file di sistema si possono pure sostituire.

Ma non mi dire. La scelta di usare solo linux e unix allora deve essere solo ideologica quindi. http://www.zdnet.com/article/linux-d...-never-before/

Come Noveau o i driver open source per le schede video AMD?

Sì esatto.

Noveau è nato nel 2007 (credo) e oggi, 7 anni dopo e rotti, supporta tutte le schede Nvidia ad un livello sufficiente a gestire una interfaccia grafica normale e quasi tutte se parliamo di avere accelerazione hardware (se la scheda in sè è capace di farlo, beninteso). Le schede NVIDIA nuove vengono supportate nel giro di 6 mesi dal rilascio, che non è affatto male.
Tutto questo a botte di reverse-engineering e colpi di fortuna, NVIDIA non ha mosso un dito fino all'anno scorso, anche allora non ha rilasciato niente di particolarmente interessante.
E non si sono ancora fermati.
Non so se noti ma questo è un esempio dove stanno lavorando a gratis da 7+ anni facendo gli interessi di NVIDIA senza chiedere nulla, perchè il prodotto è popolare.

I driver opensource per AMD vanno benone, meglio dei proprietari fino alle schede nuove (il supporto opensource arriva con un certo ritardo per via del fatto che le distro generalmente non aggiornano i kernel ogni 2 mesi).
Per le schede più vecchie delle ultime 3-4 generazioni sono anche gli unici disponibili, e la stessa AMD (che paga comunque parte dello sviluppo dei driver open) dice di usare i dirver opensource.

Beh, mi pare che pure Linux tagli il supporto all'hardware più vecchio. Ad esempio l'80386 non è più supportato, come pure le schede 3DFX. Tanto per fare un paio di nomi blasonati.

Ed è giusto che avvenga, non si può tenere tutto. Converrai che togliere il supporto ad un processore di 27 anni e ad un gruppo di GPU che avevano dai 10 ai 15 anni quando hanno tolto il supporto (quasi 5 anni fa direi) non è paragonabile a togliere il supporto a prodotti di 3 o 7 anni per la sola ragione che tira il culo ricompilare un sorgente.

Questi si chiamano bug, non cambio di API/ABI/Driver model.

La differenza sostanziale tra i due è che nel primo caso c'è della documentazione e assistenza da terzi se il driver è open, nel secondo caso mah (sì o no, dipende dal bug e da cosa non va nel tuo programma) e son fatti tuoi e solo tuoi. Ma penso che tu lo sappia già.

Il che non è necessariamente un male. Anzi. Il kernel di Windows è molto stabile, e NTFS è un eccellente filesystem.

Sì il kernel sì, i driver no, quindi la macchina o il dispositivo in genere è più instabile per colpa dei driver.

Tutto ciò si potrebbe tranquillamente applicare a Windows, se ci fosse qualcuno che sviluppasse i driver, siano essi open o closed.

Vero, ma stranamente non lo fa nessuno (o quasi) su windows.
Sarà che avere questa variabilità costringe le compagnie a fare i driver opensource per evitare gli sbattimenti? Io propendo per il sì.

Ma chiedere che la piattaforma Linux rimanga stabile a livello di API/ABI/Driver model sarebbe troppo?

Ho il forte sospetto che se fosse stabile non ci sarebbe nessun incentivo plausibile a fare driver opensource, tutti pubblicherebbero dei bei blob proprietari dal loro bel sito e sarebbe uguale a Windows. Quindi si perde una delle feature del sistema linux (l'hardware con driver opensource "funziona da solo" e il FORTE controllo sulla qualità e compatibilità dei driver) e si abbandona di fatto l'assunto principale del mondo Linux (Opensource o GTFO).

[the fear90]

Nei miei sistemi da quando ho scoperto linux installo sempre 2 sistemi in dual boot: Linux per l'utilizzo principale e windows per l'utilizzo di programmi CAD o altre evenienze qualora si rendano necessarie.

Trovo che non sia giusto mettersi d'accordo con i produttori per impedire agli utenti di poter installare linux, su molti portatili e netbook è di fatto impossibile o comunque molto più complicato del normale poterci mettere dei sistemi operativi come linux mint (sul mio netbook sarebbe perfetto ma purtroppo non c'è stato verso di potercelo mettere ).

[randorama]

Originariamente inviato da Unrealizer

se la CPU supporta SSE3 ce la dovrebbe fare

le supporta si....
io ci provo... e magari sboroneggio e provo direttamente la 64 bit

[Unrealizer]

Originariamente inviato da randorama

le supporta si....
io ci provo... e magari sboroneggio e provo direttamente la 64 bit

io proverei direttamente quella

[cdimauro]

Originariamente inviato da bobafetthotmail

Mi sembrava che se hai i driver a 32 bit fare la versione a 64 bit non costituisse uno sforzo faraonico.

Le modalità a 32 e 64 bit sono diverse. Può essere che avendo un driver a 32-bit si possa compilare a 64-bit e funzioni, ma non è affatto la regola.

Inoltre dopo aver scritto il driver lo si deve validare, eseguire gli integration test su un certo parco hardware, impacchettare (crea l'installer; anch'esso da validare, ovviamente), richiedere la certificazione Microsoft (solo per Windows, ovviamente), e infine pubblicarlo (inserirlo nel sito web e nei prodotti che ne fanno uso).

Tutto ciò ovviamente ha costi che l'azienda deve sostenere, e non sono pochi, specialmente se di mezzo del personale qualificato che viene profumatamente pagato (oltre agli sviluppatori ci sono responsabili del prodotto, dei difetti che lo riguardo, quelli che scrivono documentazione & release note, e uno stuolo di manager che si può soltanto immaginare).

Lo sviluppo del codice è soltanto l'inizio di un lungo e costoso processo.

Cioè, i driver a 32 bit di solito girano anche senza modifiche in windows a 64 bit....

SE gira (perché non è affatto detto che lo sia), probabilmente sarà dovuto a un qualche sistema di tunnelling 32<->64 bit (tipo WoW64, o l'equivalente layer che usano Linux, OS X, ecc.). Ma non è sicuro, per l'appunto.

Ma chi lo sa? è una dev board. Se la blocchi ad un kernel, ad un mesa ed and un xorg specifici fai scelte a priori.

Proprio perché è una dev board va bene così. Ed è per quello che il Raspberry è nato: mettere a disposizione della massa una minuscola ed economicissima piattaforma di sviluppo "pronta all'uso".

E' il volerci fare altro che snatura questo prodotto. Ma a questo punto se ci sono rogne, se le accolla chi ha deciso di usarlo diversamente.

D'altra parte non è né più né meno di ciò che succede con tantissime altre dev board: ambienti pronto all'uso... per quello che sono stati pensati di fare. Ed è così che dovrebbero essere usate.

O avranno ricevuto ordine di non farlo dal management, anche le compagnie cambiano idea.

Certamente, anche perché qualunque cosa si faccia in un'azienda ha un costo. Se le condizioni del mercato mutano e qualche progetto non è più conveniente, beh, lo si cassa.

Comunque ero sarcastico.

Scusami, non avevo colto.

Wow. Mi chiedo perchè linux sia così gettonato con delle così valide alternative.

No seriamente, ReactOS? Roba basata su BeOS?

Aros sembra carino.

Linux è gettonato perché rappresenta il sistema alternativo "mainstream". Gli altri s.o. che ho citato rappresentano progetti molto di nicchia (anche se ReactOS ha un certo potenziale, per ovvie ragioni) che sono realizzati e utilizzati da appassionati.

Personalmente seguo AROS perché, oltre al fatto che è una riscrittura del s.o. che ho amato e usato per tanto tempo (quello degli Amiga), si distacca all'appiattimento generale della scena dei s.o. verso soluzioni POSIX-compliant. Aria nuova, insomma. Ed è talmente piccolo che consente di potere sperimentare nuove idee senza avere a che fare con milioni di righe di codice.

Ma qui ricadiamo nell'ambito di passioni & hobby.

Che sono ancorati a filosofie ancora più radicali di Linux, la filosofia Unix principalmente.
Ad esempio FreBSD continua a gestire i sottosistemi video come anche Linux faceva eoni fa, perchè più aderente alla filosofia Unix.
Solo ora si sono svegliati e hanno capito che se non lo fanno gli ridono in faccia tutti e stanno modernizzando.

Senz'altro. Però garantisco una certa stabilità a livello di API/ABI/Driver model. Anche quando dovessero decidere di passare a qualche soluzione innovativa, ci sarà un percorso di sperimentazione che porterà poi a un sistema stabile da questo punto di vista.

Con ciò non voglio difenderli e contrapporli a Linux: a me non attirano in generale tutti i s.o. POSIX (Unix)-like. Ma da sviluppatore amo la stabilità che... mi aspetto da un sistema per poterci lavorare senza continui grattacapi; e questo prescinde dalle piattaforme.

-Costa meno sul lungo periodo,

Come fai a dirlo? Hai degli studi in proposito?

Poi non consideri che l'apertura del codice avvantaggerebbe la concorrenza...

eccheccavolo vuoi che ti scrivano loro il driver?

Perché no? Lo fanno già per molte periferiche. Ed è quello che fanno gli altri s.o. alternativi.

-ci sono prove che farlo mandi in rovina la ditta?

Vedi sopra: la concorrenza si troverebbe la pappa pronta. Ed è il motivo per cui nVidia non s'è mai sognata di rilasciare i sorgenti dei suoi driver, come già discusso.

O che non ci sono altri modi per proteggere gli IT della ditta?

Rilasciare i sorgenti vuol dire gettare via l'IP dell'azienda, perché gli altri si fionderebbero come pescecani.

Chiudendo il codice ciò è molto più difficile, anche se purtroppo è ancora possibile il reverse engineering.Ma quest'ultimo è un problema che verrà risolto in futuro, fortunatamente, e allora le aziende preferiranno optare maggiormente per tenersi in casa tutto, come trade secret, piuttosto che affrontare gli onerosi costi dei brevetti (che attualmente significa rilasciare alla concorrenza informazioni preziose, che possono comunque utilizzare).

No perchè a parte Intel che è in semi-monopolio da sempre sono in tanti a rilasciare driver open e non è ancora fallito nessuno per averlo fatto.

Bisogna vedere di che periferiche parliamo. Delle GPU ho parlato sopra sopra, ma in ambito wireless non sono tutti che rilasciano i sorgenti perché un buon driver che consuma poco (magari perché implementa un certo algoritmo efficiente) può fare la differenza con la concorrenza, per fare un altro esempio diverso.

Il firmware del dispositivo (se non è flashato nella scheda ma viene caricato dal driver) te lo lasciano tenere closed source comunque (è evidente che ci infileranno le loro IT più importanti invece che lasciarle nel driver).
Vale per tutte le GPU, le schedine wifi, e varia altra roba assortita.

Il firmware da solo non basta, perché non puoi infilarci tutte le IP. Pensa al compilatore HLSL che viene usato per gli shader delle GPU, ad esempio: non va nel firmware, ma nei driver, e non mi pare che nVidia l'abbia rilasciato, visto che non avvantaggerebbe la concorrenza.

Comunque, da un punto di vista puramente ideale, se tutti facessero driver opensource sarebbe molto facile vedere chi copia chi, e la licenza GPL non è acqua, ha valore legale.

Certamente, ma questa sarebbe un altro tipo di tutela. La GPL non tutela un'azienda dal fatto che la concorrenza avrebbe la pappa pronta che ha richiesto investimenti da parte della prima. In buona sostanza, la prima avrebbe lavorato anche per le altre.

Questo è un problema della ditta, linux non si impone su nessuno, è la ditta che nella sua piena facoltà di decidere sceglie di fare una cosa poco pratica.
Problema di management, non di Linux.

Ma anche no, perché se ho realizzato un prodotto che fa uso di terze parti mi trovo vincolato e non posso rilasciare tutto ciò che riguarda il mio prodotto per farlo girare su Linux. Non è questione di management, quindi.

Tolto questo caso (che non è affatto raro in ambito IT), sì, è una questione di management, e come ho già detto preferirei non investire in una piattaforma che non mi offre determinate garanzie di stabilità e la cui tendenza è quella di obbligarmi al rilascio delle MIE IP e/o del MIO codice, che mi sono costate parecchie risorse.

Questo vale a prescindere dall'OS, non vedo come sia rilevante. Trattare male i clienti senza una buona ragione non è una buona idea comunque.

Non è trattare male i clienti. Con altri s.o. fornisco i binari per le poche versioni del s.o. presenti, e... sono in grado di soddisfare le esigenze di centinaia di milioni di clienti.

Con Linux, che è forkato in un migliaio di distro e con numerose versioni di API, ABI, e driver model, non posso fornire lo stesso servizio e sono costretto a fare delle scelte, che mi vincolano a fissare dei paletti. Per cui posso raggiungere soltanto una parte dei clienti; gli altri, come già detto, hanno sbagliato s.o. se vogliono utilizzare i miei prodotti. E parliamo comunque di un mercato, quello "desktop" di Linux, che non arriva nemmeno al 2%...

Anche Intel, che non è certo in una condizione precaria si è affrettata ad urlare ai 4 venti che i suoi nuovi Atom con GPU PowerVR non saranno supportati da linux nè da sistemi operativi a 64 bit.
Non vogliono ripetere l'errore del 2012 dove non hanno detto nulla assumendo che tutti ci avrebbero messo Win a 32 bit e basta, e poi si sono trovati nei forum e al supporto tecnico uragani di flame da utenti Windows e Linux incavolati come delle puzzole.
Ci sono ancora thread dell'epoca pieni di flame verso Intel in giro, tanto per dire la reazione.

Ma questo è successo per quanto detto sopra: perché gli utenti in questione hanno sbagliato a usare s.o.. Se Intel ha rilasciato i propri prodotti per determinate piattaforme, una volta che tu, consumatore, decidi di uscire fuori dal seminato, son problemi tuoi.

E' un po' come la questione dell'opensource vs GTFO: se non ti piace quanto offerto dall'azienda... GTFO.

Ma non mi dire. La scelta di usare solo linux e unix allora deve essere solo ideologica quindi. http://www.zdnet.com/article/linux-d...-never-before/

Questo mi sembra sia tutt'altra cosa rispetto a quanto stavamo discutendo prima.

Certamente Windows HPC non ha avuto successo. Problemi di Microsoft.

Sì esatto.

Noveau è nato nel 2007 (credo) e oggi, 7 anni dopo e rotti, supporta tutte le schede Nvidia ad un livello sufficiente a gestire una interfaccia grafica normale e quasi tutte se parliamo di avere accelerazione hardware (se la scheda in sè è capace di farlo, beninteso). Le schede NVIDIA nuove vengono supportate nel giro di 6 mesi dal rilascio, che non è affatto male.
Tutto questo a botte di reverse-engineering e colpi di fortuna, NVIDIA non ha mosso un dito fino all'anno scorso, anche allora non ha rilasciato niente di particolarmente interessante.
E non si sono ancora fermati.
Non so se noti ma questo è un esempio dove stanno lavorando a gratis da 7+ anni facendo gli interessi di NVIDIA senza chiedere nulla, perchè il prodotto è popolare.

Ma allora, scusami, perché non possono fare lo stesso anche con tutti gli altri prodotti? Problema risolto...

I driver opensource per AMD vanno benone, meglio dei proprietari fino alle schede nuove (il supporto opensource arriva con un certo ritardo per via del fatto che le distro generalmente non aggiornano i kernel ogni 2 mesi).
Per le schede più vecchie delle ultime 3-4 generazioni sono anche gli unici disponibili, e la stessa AMD (che paga comunque parte dello sviluppo dei driver open) dice di usare i dirver opensource.

Mi pare strano che la situazione si sia addirittura ribaltata. Fino a qualche anno fa i driver open source delle GPU AMD facevano pietà. Comunque non informandomi più da tempo non posso aggiungere altro; se avrò tempo, mi documenterò.

Ed è giusto che avvenga, non si può tenere tutto. Converrai che togliere il supporto ad un processore di 27 anni e ad un gruppo di GPU che avevano dai 10 ai 15 anni quando hanno tolto il supporto (quasi 5 anni fa direi) non è paragonabile a togliere il supporto a prodotti di 3 o 7 anni per la sola ragione che tira il culo ricompilare un sorgente.

Per la GPU posso concordare, ma togliere un centinaio di righe di codice (perché a tanto ammontava) il supporto all'80386 mi pare esagerato. I brevetti di questo processore sono scaduti da un pezzo, ed è possibile sintetizzare un core compatibile per sistemi embedded, dove Linux è molto diffuso.

La differenza sostanziale tra i due è che nel primo caso c'è della documentazione e assistenza da terzi se il driver è open, nel secondo caso mah (sì o no, dipende dal bug e da cosa non va nel tuo programma) e son fatti tuoi e solo tuoi. Ma penso che tu lo sappia già.

Ma anche no: nessuno ti garantisce assistenza per i driver open source. Un'azienda invece segue il proprio prodotto e fornisce dei driver aggiornati. Idem per Windows.

Sì il kernel sì, i driver no, quindi la macchina o il dispositivo in genere è più instabile per colpa dei driver.

Questo è un problema comune a tutti i s.o..

Vero, ma stranamente non lo fa nessuno (o quasi) su windows.

Lazy coders.

Sarà che avere questa variabilità costringe le compagnie a fare i driver opensource per evitare gli sbattimenti? Io propendo per il sì.

A giudicare dai binary blob che circolano, io propendo per il no.

Ho il forte sospetto che se fosse stabile non ci sarebbe nessun incentivo plausibile a fare driver opensource, tutti pubblicherebbero dei bei blob proprietari dal loro bel sito e sarebbe uguale a Windows. Quindi si perde una delle feature del sistema linux (l'hardware con driver opensource "funziona da solo" e il FORTE controllo sulla qualità e compatibilità dei driver) e si abbandona di fatto l'assunto principale del mondo Linux (Opensource o GTFO).

Quella non è una feature, ma una politica liberticida da parte di Linux e in generale del mondo "free software", che sostanzialmente obbliga aziende e in generale sviluppatori a rilasciare le proprie IP e/o codice.

E tutto ciò non è affatto una garanzia né di qualità né di servizio. Se dovessi rilasciare come open source i miei driver, chi garantisce me, azienda, che il mio prodotto verrà mantenuto costantemente? Chi farà fronte ai bug in tempi rapidi? Nessuno. Non c'è nessun contratto che l'azienda possa stipulare con qualcuno e che le fornisca queste garanzie.

Un esempio è la famigerata glibc. Tempo fa c'era un problema con le architetture ARM. Il mantainer di questa libreria odia gli ARM, e s'è fottuto altamente (uso questo termine un po' scurrile che qualifica in che modo ha risposto il personaggio in questione). Risultato: glibc è stata forkata, con dispendio di tempo e risorse.

Il mondo open source è pieno di primedonne, e questi problemi non sono affatto rari. Un'azienda non può avere a che fare con questi mocciosi viziati, perché deve servire i propri clienti.

Per cui il tuo assunto che open source -> cosa buona e giusta & miglior supporto è ben lungi dall'essere vero.

A parte questo, se API/ABI/Driver model fossero stabili è vero che molte aziende potrebbero rilasciare binary blob. Ma questo NON implica che la qualità sarebbe inferiore. Tutt'altro. Immagina i driver di nVidia che funzionerebbero su tanteeee distro e versioni di kernel, eliminando alla radice il principale problema che lo affligge. Idem per Broadcom e il suo SoC su Raspberry. E così via.

OK, devo scappare e non ho nemmeno tempo di rileggere. Sorry.

Originariamente inviato da the fear90

Nei miei sistemi da quando ho scoperto linux installo sempre 2 sistemi in dual boot: Linux per l'utilizzo principale e windows per l'utilizzo di programmi CAD o altre evenienze qualora si rendano necessarie.

Trovo che non sia giusto mettersi d'accordo con i produttori per impedire agli utenti di poter installare linux, su molti portatili e netbook è di fatto impossibile o comunque molto più complicato del normale poterci mettere dei sistemi operativi come linux mint (sul mio netbook sarebbe perfetto ma purtroppo non c'è stato verso di potercelo mettere ).

Se hai letto la notizia, non è affatto questo il caso. E basta coi complottismi, per favore.

Originariamente inviato da Unrealizer

io proverei direttamente quella

Assolutamente.

[Eress]

Originariamente inviato da Simonex84

quindi niente UEFI niente Windows 10, vorrà dire che il fisso morirà con Windows 7

Anche per me così, W7 in dual boot con 8.1 e fine. Sinceramente non sentirò la mancanza di 10.

[bobafetthotmail]

Originariamente inviato da cdimauro

Inoltre dopo aver scritto il driver lo si deve ....... e infine pubblicarlo (inserirlo nel sito web e nei prodotti che ne fanno uso).

A questo ci pensa Intel. IT fornisce solo un SDK visto che permette ad Intel di produrre la sua GPU ad Intel su licenza.

D'altra parte non è né più né meno di ciò che succede con tantissime altre dev board: ambienti pronto all'uso... per quello che sono stati pensati di fare. Ed è così che dovrebbero essere usate.

Un conto sono le dev board per sviluppare prodotti commerciali dove ti danno il SoC che poi ordinerai a pacchi e usi il loro SDK merdacchioso basato su un linux in palese violazione della GPL e pieno di blob proprietari sia come driver che come software che ci gira sopra per fare un prodotto embedded scrauso o un dispositivo mobile, un conto sono queste dev board ad utilizzo più generale.

Come fai a dirlo? Hai degli studi in proposito?

Questo è il repository del driver radeon (opensource di AMD) http://cgit.freedesktop.org/xorg/dri...ideo-ati/refs/

Dalla lista dei commit vedi i nomi.
Alex Deucher, Christian König, Michel Dänzer, Tom Stellard e Tim Writer sono pagati da AMD, gli altri no. http://www.phoronix.com/scan.php?pag...item&px=OTYzOA

Io vedo una valanga di commit fatti da gente che non c'entra nulla con AMD.

Se dovevano pagarla loro tutta quella gente vai tranquillo che gli costava di più.
Ma non credere che siano tuti volontari non pagati e fanatici dell'opensource. Molti di quelli (come quelli che sono poi stati assunti da AMD come spiegato nell'articolo linkato) lavorano per altre compagnie che hanno interesse ad avere la tal feature o vogliono poter fare la tal cosa col driver. Ad esempio Danzer viene da VMWare, e prima lavorava al driver radeon per conto di VMWare appunto.

Qui parlano dei developer delle GPU intel pagati da Intel http://www.phoronix.com/scan.php?pag...tem&px=MTI5MTI

Poi non consideri che l'apertura del codice avvantaggerebbe la concorrenza...

Partiamo col dire che nessuno gli chiede di mettere open il driver di Windows.
Primo perchè Linux non è Windows, quindi un driver open ma fatto per Windows ha una utilità limitata.
Il resto dipende da quanto è legato all'hardware, al firmware e all'OS, cioè se per copiarti la cosa X devono riscrivere tutto il loro driver o riprogettare mezzo chip fisico (facendo cose che solo tu hai licenza per fare) o su un altro OS non gira perchè in questo driver ti interfacci con dei sottosistemi troppo diversi da quelli dell'altro OS (vedi il caso delle GPU più sotto), allora nessuno muore dalla voglia di rubarti cose.

Esempio pratico: AMD ha messo open la documentazione e parte del codice di controllo per i suoi acceleratori VCE di codifica multimediale. Ora, ok, sono open, ma le licenze per produrre il circuito hardware mica tanto.

In genere i driver open per linux non assomigliano un granchè alla controparte Windows, in quanto sono riscritti usando codice ed implementazioni open proprio per evitare di buttare IP fondamentali per sopravvivere nel mondo Windows al vento.

Perché no? Lo fanno già per molte periferiche. Ed è quello che fanno gli altri s.o. alternativi.

Se rilasci documentazione decente se ne può parlare, senza documentazione dovresti produrre hardware VERAMENTE interessante, tipo NVIDIA, sennò ti ridono in faccia e basta.

Vedi sopra: la concorrenza si troverebbe la pappa pronta. Ed è il motivo per cui nVidia non s'è mai sognata di rilasciare i sorgenti dei suoi driver, come già discusso.

AMD rilascia documentazione da tempo e ultimamente è sempre più impegnata sul fronte open, mentre NVIDIA continua tranquillissima a farsi i fatti suoi e implementare giochini proprietari e via discorrendo.
Non mi pare che NVIDIA stia copiando AMD.

Chiudendo il codice ciò è molto più difficile, anche se purtroppo è ancora possibile il reverse engineering.

Anche lo spionaggio industriale eh. Sony docet. Se vi ciulano i sorgenti o un OEM che usa un vostro SDK decide di infrangere la licenza (metti caso che è più grosso di voi) siete nella merda più completa.

Bisogna vedere di che periferiche parliamo. Delle GPU ho parlato sopra sopra, ma in ambito wireless non sono tutti che rilasciano i sorgenti perché un buon driver che consuma poco (magari perché implementa un certo algoritmo efficiente) può fare la differenza con la concorrenza, per fare un altro esempio diverso.

Atheros, broadcom, marvell, intel... e altri fanno driver linux opensource per il wifi ed ethernet (e per altri prodotti, specialmente Marvell con alcuni dei suoi SoC), nessuna di esse è fallita o piange miseria a quanto ne so.
https://en.wikipedia.org/wiki/Compar...drivers#Status

Pensa al compilatore HLSL che viene usato per gli shader delle GPU, ad esempio: non va nel firmware, ma nei driver, e non mi pare che nVidia l'abbia rilasciato, visto che non avvantaggerebbe la concorrenza.

Ritorniamo a quello che ho detto sopra, Linux non è windows.
Non ha senso rilasciare il compilatore HLSL visto che è quello delle DirectX di Windows, Linux usa GLSL di OpenGL che tanto per cambiare è opensource e ci lavorano sia developer di AMD che di Intel (visto che stranamente fa comodo ad entrambi)

Ma anche no, perché se ho realizzato un prodotto che fa uso di terze parti mi trovo vincolato e non posso rilasciare tutto ciò che riguarda il mio prodotto per farlo girare su Linux. Non è questione di management, quindi.

E chi ha preso la decisione di chiedere le licenze a terze parti e sborsato i soldi? I developer? Nain. Chi scrive codice è una pezza da piedi, il lavoro di concetto lo fanno I manager. Quindi è questione di management.

E parliamo comunque di un mercato, quello "desktop" di Linux, che non arriva nemmeno al 2%...

Secondo te quelli che ho menzionato sopra fanno i driver per Linux desktop? Per permettere ai bimbetti di fare i nerd col MacBook dualboot con Linux?

Linux domina in ambito embedded e server, è lì che c'è il grano vero. Si sta espandendo anche nel campo enterprise, per quanto magari non in Italia.

LSI (produce schede RAID serie) ha driver opensource, Areca, Adaptec, marvell, Intel, eccetera.

E' un po' come la questione dell'opensource vs GTFO: se non ti piace quanto offerto dall'azienda... GTFO.

Sì. La differenza è che così facendo linux si ammanta dello stendardo della libertà e guadagna prestigio, mentre l'azienda viene vista come vigliacca o peggio quindi perde prestigio.

è una questione di principi lol. Linux ha questi principi e li segue, un'azienda segue solo il vil denaro.

Questo mi sembra sia tutt'altra cosa rispetto a quanto stavamo discutendo prima.
Certamente Windows HPC non ha avuto successo. Problemi di Microsoft.

Io ho parlato del fatto che in ambito performance e calcoli linux è favorito pesantemente, tu hai cercato di difendere windows dicendo che MS permette di fare cose (non so quali sacrifici umani bisogna fare per ottenere quello che dici tu), io ho portato prove che nonostante gli sforzi di MS, linux stravince.
Non è normale che in un ambito dove le prestazioni siano tutto la schiacciante maggioranza faccia scelte ideologiche.
Linux deve dargli qualcosa che MS non gli da.

Ma allora, scusami, perché non possono fare lo stesso anche con tutti gli altri prodotti? Problema risolto...

Certo, aspettare 10 anni dal lancio dei propri primi prodotti per avere il supporto a livello quasi gaming (forse) mentre la maggioranza della community ti odia pesantemente perchè ti sei comportato al contrario dei principi fondamentali su cui si basa Linux, il fondatore del sistema operativo ti ha mandato letteralmente affanculo con tanto di dito medio davanti alle telecamere (facendoti perdere un ingente contratto con il governo cinese, ovviamente andato ad AMD), e tutti hanno comprato hardware della concorrenza per 10 anni.
Una strategia di mercato vincente, geniale.

Per la GPU posso concordare, ma togliere un centinaio di righe di codice (perché a tanto ammontava) il supporto all'80386 mi pare esagerato.

Continui a pensare come se fosse Windows. None, questo è linux. Ricordi quando hai ripetuto più volte "API/ABI/driver model non stabili"?
I codice nel kernel che non viene mantenuto diventa inutile molto rapidamente.
Essendo quello un processore con FORTI, IMMENSE limitazioni (dovute principalmente al fatto che ha 27 anni e la tecnologia si è evoluta parecchio in quasi 20 anni di crescita geometrica), i mantainer si erano rotti i cosiddetti di sistemare il codice quando ottimizzavano altre cose più importanti per processori moderni.

Ingo Molnar (red hat, pagato) : "has plagued us with extra work whenever we wanted to change SMP primitives, for years"

Linus torvalds: "good riddance"

I brevetti di questo processore sono scaduti da un pezzo, ed è possibile sintetizzare un core compatibile per sistemi embedded, dove Linux è molto diffuso.

Devi essere all'oscuro del movimento dell'Open Hardware. Se per qualche arcana ragione tutti i vari ARM, MIPS dichiarati open non bastano, si chiede a quelli, altro che riesumare un processore morto da 20 anni. https://en.wikipedia.org/wiki/Open-source_hardware

La prossima volta che hai bisogno di roba di terze parti fai un giro sui loro siti che magari porti a casa roba interessante aggratis.

Ma anche no: nessuno ti garantisce assistenza per i driver open source.

Gli sviluppatori/manutentori del kernel fanno anche assistenza a quelli che compilano il kernel direttamente (server di calcolo o supercomputer in genere, più i manutentori delle varie distro) mentre se hai installato una distro particolare, sono i manutentori della distro che hai installato a doverti fare assistenza per il kernel della loro distro.
Red Hat e SUSE (non openSUSE) ad esempio offrono il servizio a pagamento per aziende.
Red Hat ad esempio ha sviluppatori ovunque. Qualsiasi cosa abbia una rilevanza con linux almeno uno sviluppatore RedHat lo trovi che sta facendo gli interessi della sua ditta.

Inoltre, essendo open-source, tu ditta di medie-grandi dimensioni puoi anche assoldare developer (magari gente già attiva nell'ambito, come ha fatto AMD sopra) per andare a sistemare il problema per te e contribuire alla community passando la patch upstream.

E ti costa relativamente poco. Paghi quattro gatti per qualche mese e fine.
I contratti di supporto gestiti da terzi costano un fottio e ovviamente paghi anche se non ci sono problemi.

Un'azienda invece segue il proprio prodotto e fornisce dei driver aggiornati.

Se ha le risorse monetarie per farlo, se gli tira il culo farlo, se non viene distrutta da un cataclisma o fallisce o viene comprata, se non cambia idea, o mille altre ragioni per cui alla fine capita che il cliente si attacca al puffo.

Questo è un problema comune a tutti i s.o..

In Linux e freeBSD non tanto, visto che uno dei motivi per cui sono opensource è proprio evitare questa situazione.

E tutto ciò non è affatto una garanzia né di qualità né di servizio.

Eppure tante aziende mica da poco l'hanno fatto. Avranno fatto i loro calcoli e hanno visto che probabilmente gli conveniva.
Magari è ora di parlarne anche coi tuoi di capi.

Se smettono di trattare Linux come se fosse "Windows con API/ABI/driver model instabili" e seguono le regole magari ci rimettono meno a supportarlo, forse ci guadagnano anche.

Tempo fa c'era un problema con le architetture ARM. Il mantainer di questa libreria odia gli ARM, e s'è fottuto altamente (uso questo termine un po' scurrile che qualifica in che modo ha risposto il personaggio in questione). Risultato: glibc è stata forkata, con dispendio di tempo e risorse.

L'unico fork di glibc che ricordo è questo, non è esattamente uguale a come lo descrivi. Forse se chiarisci meglio la situazione ci capiamo meglio.
vedi qui
https://lwn.net/Articles/488847/

Comunque, questo è un'altro esempio dove l'opensource salva il didietro mentre il closed no.
E mica cazzi o ideologie. Questo è cash risparmiato, non blablabla hippie da convention.

Mettiamo caso che fosse closed e per i vari motivi validi citati da te nei tuoi post rispondesse picche (nota che non sono sarcastico, sono motivi validi).
Che si faceva?
L'unica strada era migrare un fottio di codice ad usare un'altra libreria. Bello, deve essere facile, costare poco e richiedere poco tempo.

Con un fork di emergenza gestito da mantainer del kernel e delle distro maggiori (glibc era sviluppato da 4 gatti quindi non è che fosse sto gran peso) sono riusciti a tirare avanti finchè il tizio non si è ripigliato, ma in caso non si ripigliasse quella diventava di fatto il rimpiazzo di glibc.

Comunque non è che fosse tutta sta gran difficoltà, in quanto se vedi glibc è stata sviluppata da un tizio solo più qualche cosina minore da altri per tipo 10 anni.

Per inciso, abbiamo anche un ulteriore caso di "community in azione". Una azienda che si era rotta le palle della situazione ha pagato UN singolo developer per sistemare le cose una volta per tutte (quello che è rimasto per 10 anni di cui sopra), e nel giro di qualche anno il problema si è risolto.

Il mondo open source è pieno di primedonne, e questi problemi non sono affatto rari. Un'azienda non può avere a che fare con questi mocciosi viziati, perché deve servire i propri clienti.

Ma infatti, il mondo closed è pieno di esempi di serietà, integrità e professionalità come Adobe che decide che Flash su Android non lo sviluppa più fregandosene di tutti quelli che ci contavano per i loro giochini, contenuti e pubblicità.

Di compagnie che si interessano tantissimo dei ticket che apri per i loro software che la tua azienda paga uno strafottio, così tanto che il problema viene sistemato quando gli tira a loro o forse mai, e se a te serviva son cavoli tuoi.
Se sei Microsoft, Google, Apple o IBM vai lì è li bombardi, ma una azienda media si attacca.

O dei vari produttori di SoC con SDK merdacchiosi che ti limitano ad una versione tagliatissima e totalmente delirante del firmware basato su Linux, con vari bug bonus da aggirare a botte di script.
(Ciao realtek!!)

Mentre nel frattempo coi SoC opensource (vedi Kirkwood della Marvell) basta che mi connetto con la UART, flasho un u-boot decente, e poi BUM, carico Debian o Arch (un pò più complesso in realtà, ma si fa in un'oretta tranquillamente seguendo tutorial da internet). Mica Raspbian o dei minchiosissimi firmware da SDK medio, Debian ARM o ALARM (Arch per ARM).
Un NAS Zyxel del menga da 70 euro che fa girare OpenMediaVault, con accesso a TUTTI i pacchetti di Debian armel.

Per cui il tuo assunto che open source -> cosa buona e giusta & miglior supporto è ben lungi dall'essere vero.

Scusa un attimo è meglio fare un fork se qualcuno si inpunta e pagare UN singolo developer per sistemare il casino o migrare ad una libreria diversa (se esiste)? o creare una nuova libreria?

Se quel tipo che si impuntava lavorava con del codice closed voi che facevate? Vi attaccavate al puffo tutti senza se e senza ma.

Con il codice open se della gente fa cazzate gli forki il progetto e procedi nella direzione che ti serve. Ti costa un pò di più, ma non ti schianti brutalmente.

Questo è un'altro effetto dell'opensource, molto ma molto gradito specialmente a ditte di una certa dimensione e ai governi che usano sistemi open.
Non sono solo i manutentori ad avere il controllo sul codice, ma anche le aziende interessate, e non esiste che perchè l'azienda X dice che non gli va di continuare a supportare/aggiornare un prodotto allora le altre si attaccano al puffo.

[Unrealizer]

Originariamente inviato da Eress

Anche per me così, W7 in dual boot con 8.1 e fine. Sinceramente non sentirò la mancanza di 10.

rileggi, il requisito di UEFI è solo per i nuovi PC e c'è da 8.0, i "vecchi" pc con BIOS possono comunque installarlo

[cdimauro]

Rieccomi. Ho avuto un po' di impegni ultimamente, per cui rispondo soltanto adesso che sono un po' più libero. Per cui scusami per il ritardo.

Originariamente inviato da bobafetthotmail

A questo ci pensa Intel. IT fornisce solo un SDK visto che permette ad Intel di produrre la sua GPU ad Intel su licenza.

OK, ma il punto era che produrre driver richiede parecchie risorse per un'azienda. Soprattutto non basta una banale ricompilata di un driver a 32 bit per ottenerne uno a 64-bit.

Un conto sono le dev board per sviluppare prodotti commerciali dove ti danno il SoC che poi ordinerai a pacchi e usi il loro SDK merdacchioso basato su un linux in palese violazione della GPL e pieno di blob proprietari sia come driver che come software che ci gira sopra per fare un prodotto embedded scrauso o un dispositivo mobile, un conto sono queste dev board ad utilizzo più generale.

Certamente, ma sempre dev board rimangono. Raspberry per cosa è nato? Per mettere a disposizione un computerino economico per poterci fare qualche progettino di elettronica e imparare Python.
Il suo ecosistema va bene per questo scopo? Direi che va benissimo.
Si sente l'esigenza di mettere altro? No, a meno che non si voglia andare oltre il motivo per cui è nato.
Si può andare oltre? Certamente, ma è un hack e allora poi non puoi bestemmiare se hai dei problemi.

A me sembra tutto chiaro, no?

Questo è il repository del driver radeon (opensource di AMD) http://cgit.freedesktop.org/xorg/dri...ideo-ati/refs/

Dalla lista dei commit vedi i nomi.
Alex Deucher, Christian König, Michel Dänzer, Tom Stellard e Tim Writer sono pagati da AMD, gli altri no. http://www.phoronix.com/scan.php?pag...item&px=OTYzOA

Io vedo una valanga di commit fatti da gente che non c'entra nulla con AMD.

Se dovevano pagarla loro tutta quella gente vai tranquillo che gli costava di più.
Ma non credere che siano tuti volontari non pagati e fanatici dell'opensource. Molti di quelli (come quelli che sono poi stati assunti da AMD come spiegato nell'articolo linkato) lavorano per altre compagnie che hanno interesse ad avere la tal feature o vogliono poter fare la tal cosa col driver. Ad esempio Danzer viene da VMWare, e prima lavorava al driver radeon per conto di VMWare appunto.

Sì, ma come dici tu stesso, è gente che aveva propri interessi. Dubito che tutte quelle patch siano funzionali a far lavorare i driver per l'utente finale.

Qui parlano dei developer delle GPU intel pagati da Intel http://www.phoronix.com/scan.php?pag...tem&px=MTI5MTI

Appunto: pagati da Intel per sviluppare i driver e ciò che serve per supportare le sue GPU. Ne ho pure uno davanti a me, a 5 metri di distanza.

Qui dove sarebbe il risparmio, visto che è gente pagata da Intel?

Partiamo col dire che nessuno gli chiede di mettere open il driver di Windows.
Primo perchè Linux non è Windows, quindi un driver open ma fatto per Windows ha una utilità limitata.
Il resto dipende da quanto è legato all'hardware, al firmware e all'OS, cioè se per copiarti la cosa X devono riscrivere tutto il loro driver o riprogettare mezzo chip fisico (facendo cose che solo tu hai licenza per fare) o su un altro OS non gira perchè in questo driver ti interfacci con dei sottosistemi troppo diversi da quelli dell'altro OS (vedi il caso delle GPU più sotto), allora nessuno muore dalla voglia di rubarti cose.

Esempio pratico: AMD ha messo open la documentazione e parte del codice di controllo per i suoi acceleratori VCE di codifica multimediale. Ora, ok, sono open, ma le licenze per produrre il circuito hardware mica tanto.

In genere i driver open per linux non assomigliano un granchè alla controparte Windows, in quanto sono riscritti usando codice ed implementazioni open proprio per evitare di buttare IP fondamentali per sopravvivere nel mondo Windows al vento.

Sì, ma i registri dell'hardware della GPU si programmano allo stesso modo, qualunque sia il s.o. sottostante. Idem per la generazione di codice per gli shader.

Il grosso del lavoro dei driver non è certamente per interfacciarsi col s.o., ma con la normale operatività.

Ecco perché ci sono aziende che non voglio aprire il proprio codice, a prescindere dal s.o.: perché svelerebbero IP che avvantaggerebbero la concorrenza.

Se rilasci documentazione decente se ne può parlare, senza documentazione dovresti produrre hardware VERAMENTE interessante, tipo NVIDIA, sennò ti ridono in faccia e basta.

Mi pare che anche le GPU di Imagination, Qualcomm, Broadcom siano interessanti, e con un bacino di utenza di gran lunga più elevato rispetto a quelle di nVidia, eppure non mi pare di aver visto progetti come Noveau.

AMD rilascia documentazione da tempo e ultimamente è sempre più impegnata sul fronte open, mentre NVIDIA continua tranquillissima a farsi i fatti suoi e implementare giochini proprietari e via discorrendo.
Non mi pare che NVIDIA stia copiando AMD.

Mai detto questo, quanto piuttosto il contrario: se nVidia rilasciasse i sorgenti (o anche la sola documentazione) delle sue schede video, sarebbe certamente AMD a trarne vantaggio (ma non solo: farebbe comodo a tutti i produttori di GPU!) per realizzare i suoi driver e le future GPU.

Anche lo spionaggio industriale eh. Sony docet. Se vi ciulano i sorgenti o un OEM che usa un vostro SDK decide di infrangere la licenza (metti caso che è più grosso di voi) siete nella merda più completa.

Certamente, ma son casi decisamente limitati. Roba che non si vede tutti i giorni.

Mentre rilasciando tutto la concorrenza farebbe festa tutti i giorni. Aggratis.

Atheros, broadcom, marvell, intel... e altri fanno driver linux opensource per il wifi ed ethernet (e per altri prodotti, specialmente Marvell con alcuni dei suoi SoC), nessuna di esse è fallita o piange miseria a quanto ne so.
https://en.wikipedia.org/wiki/Compar...drivers#Status

A giudicare dalla colonna "Non-free firmware required" e da quella "Development" (dove si legge tante volte "Reverse engineered") mi sembra che la maggior parte ragionino come ho detto finora.

Ritorniamo a quello che ho detto sopra, Linux non è windows.
Non ha senso rilasciare il compilatore HLSL visto che è quello delle DirectX di Windows, Linux usa GLSL di OpenGL che tanto per cambiare è opensource e ci lavorano sia developer di AMD che di Intel (visto che stranamente fa comodo ad entrambi)

Per Linux c'è pure Wine, per cui anche HLSL è interessante.

Comunque Intel e AMD lavorano ai rispettivi compilatori GLSL, ma il punto è che quello di nVidia rimane ben nascosto nei meandri del suo driver, proprio per quanto detto sopra.

E chi ha preso la decisione di chiedere le licenze a terze parti e sborsato i soldi? I developer? Nain. Chi scrive codice è una pezza da piedi, il lavoro di concetto lo fanno I manager. Quindi è questione di management.

Assolutamente no. Se devo realizzare un prodotto, si analizzano i requisiti e si allocano le risorse per il progetto. Risorse = anche proprietà di terze parti che consentono di abbattere i costi e/o il time-to-market. Io, azienda, è a questo che devo pensare, e non posso ogni volta farmi tutto in casa da sola reinventandomi le ruote.

Se, per esempio, mi serve un codec video e non ne ho uno a disposizione, lo richiedo a un'azienda che me lo licenzia a un certo prezzo, e ci risparmio parecchi soldini.

Secondo te, soltanto perché un driver (o codice, in generale) potrebbe andare a finire su Linux, dovrei riscrivermelo tutto per metterne a disposizione i sorgenti? E' pura follia.

Secondo te quelli che ho menzionato sopra fanno i driver per Linux desktop? Per permettere ai bimbetti di fare i nerd col MacBook dualboot con Linux?

Linux domina in ambito embedded e server, è lì che c'è il grano vero. Si sta espandendo anche nel campo enterprise, per quanto magari non in Italia.

LSI (produce schede RAID serie) ha driver opensource, Areca, Adaptec, marvell, Intel, eccetera.

Allora il problema nemmeno si pone, visto che nVidia opera in altri settori (e nei server nemmeno è necessaria una GPU come quella che produce). Dunque perché gli utenti Linux, Torvalds in primis, si lagnano? Perché sono bimbetti nerd, come dici tu?

A parte questo, nel mondo embedded operano diverse realtà che non rilasciano le loro IP, ma soltanto binari. Nvidia-docet. Bimbetti nerd anche questi?

Sì. La differenza è che così facendo linux si ammanta dello stendardo della libertà e guadagna prestigio, mentre l'azienda viene vista come vigliacca o peggio quindi perde prestigio.

è una questione di principi lol. Linux ha questi principi e li segue, un'azienda segue solo il vil denaro.

ROFL E che dovrebbe fare un'azienda? La carità? Far soldi è il suo obiettivo primario.

Riguardo a Linux, a me non frega della sua filosofia, ma certamente il suo NON è uno stendardo di libertà, quanto una politica liberticida, visto che pretende di imporre ad altri di rilasciare il PROPRIO codice.

Se qualcuno vuol rilasciare il proprio codice, è liberissimo di farlo. Se gli sviluppatori Linux vogliono rilasciare i LORO sorgenti, sono liberi di farlo.

Ma licenze come la GPL sono liberticide. E tale è il comportamento degli sviluppatori di Linux che pretenderebbero dagli altri il rilascio dei sorgenti, ivi incluse le politiche di instabilità di API/ABI.

Non che è si può ribaltare il significato della parola libertà a proprio uso e consumo. Vigliacco è, semmai, che pretende di scambiare "liberticida" e "libertà". Io sono per la seconda, e non per la prima.

Io ho parlato del fatto che in ambito performance e calcoli linux è favorito pesantemente, tu hai cercato di difendere windows dicendo che MS permette di fare cose (non so quali sacrifici umani bisogna fare per ottenere quello che dici tu), io ho portato prove che nonostante gli sforzi di MS, linux stravince.
Non è normale che in un ambito dove le prestazioni siano tutto la schiacciante maggioranza faccia scelte ideologiche.
Linux deve dargli qualcosa che MS non gli da.

Non vedo dove starebbe la mia difesa di Windows. Potresti quotarmi e dimostrarlo, cortesemente?

Io avevo scritto questo: "Veramente il sorgente di Windows è possibile ottenerlo, con particolari accordi con Microsoft.
E i file di sistema si possono pure sostituire."

in risposta alla tua precedente affermazione: "Poi chi li sente quelli che devono ottimizzare il sistema e si scontrano con il fatto che Windows è closed source e non c'è modo di ottenere modifiche custom ai file di sistema?"

E tu dopo hai risposto con questo: "La scelta di usare solo linux e unix allora deve essere solo ideologica quindi."

Sì, si parlava di HPC, ma tu hai scritto una cosa che non è vera riguardo a sorgenti e possibili modifiche. E io a quello ho risposto.

Nulla da dire sulle scelte di usare Linux in ambito HPC, ma il punto a cui avevo risposto non è questo.

Certo, aspettare 10 anni dal lancio dei propri primi prodotti per avere il supporto a livello quasi gaming (forse) mentre la maggioranza della community ti odia pesantemente perchè ti sei comportato al contrario dei principi fondamentali su cui si basa Linux, il fondatore del sistema operativo ti ha mandato letteralmente affanculo con tanto di dito medio davanti alle telecamere (facendoti perdere un ingente contratto con il governo cinese, ovviamente andato ad AMD), e tutti hanno comprato hardware della concorrenza per 10 anni.
Una strategia di mercato vincente, geniale.

Fammi capire: nVidia è odiata da tutti in ambito Linux, ma ci scrivono aggratis i driver open source. Mentre tutti gli altri produttori di hardware che si comportano allo stesso modo non sono cacati nemmeno di striscio.

Per caso fra i "principi fondamentali di Linux" ci sono anche incoerenza e masochismo autolesionista?

Continui a pensare come se fosse Windows. None, questo è linux. Ricordi quando hai ripetuto più volte "API/ABI/driver model non stabili"?
I codice nel kernel che non viene mantenuto diventa inutile molto rapidamente.
Essendo quello un processore con FORTI, IMMENSE limitazioni (dovute principalmente al fatto che ha 27 anni e la tecnologia si è evoluta parecchio in quasi 20 anni di crescita geometrica), i mantainer si erano rotti i cosiddetti di sistemare il codice quando ottimizzavano altre cose più importanti per processori moderni.

Ingo Molnar (red hat, pagato) : "has plagued us with extra work whenever we wanted to change SMP primitives, for years"

Linus torvalds: "good riddance"

Tutto questo casino per sole 100 righe di codice? Mah. Rimango perplesso.

Comunque non è questione di 386 che è rimasto indietro. Un conto è QUELLA micro-architettura, e un conto è l'ISA (l'architettura). Infatti è possibile costruire processori che adottino quell'architettura, ma con una micro-architettura nuova pacca che è tecnologicamente al passo coi tempi (es: Out-of-Order, superscalare, branch predictor, ecc. ecc. ecc.).

Devi essere all'oscuro del movimento dell'Open Hardware. Se per qualche arcana ragione tutti i vari ARM, MIPS dichiarati open non bastano, si chiede a quelli, altro che riesumare un processore morto da 20 anni. https://en.wikipedia.org/wiki/Open-source_hardware

La prossima volta che hai bisogno di roba di terze parti fai un giro sui loro siti che magari porti a casa roba interessante aggratis.

Tipo questa: http://opencores.org/project,zet86 ?

Gli sviluppatori/manutentori del kernel fanno anche assistenza a quelli che compilano il kernel direttamente (server di calcolo o supercomputer in genere, più i manutentori delle varie distro) mentre se hai installato una distro particolare, sono i manutentori della distro che hai installato a doverti fare assistenza per il kernel della loro distro.
Red Hat e SUSE (non openSUSE) ad esempio offrono il servizio a pagamento per aziende.
Red Hat ad esempio ha sviluppatori ovunque. Qualsiasi cosa abbia una rilevanza con linux almeno uno sviluppatore RedHat lo trovi che sta facendo gli interessi della sua ditta.

Inoltre, essendo open-source, tu ditta di medie-grandi dimensioni puoi anche assoldare developer (magari gente già attiva nell'ambito, come ha fatto AMD sopra) per andare a sistemare il problema per te e contribuire alla community passando la patch upstream.

E ti costa relativamente poco. Paghi quattro gatti per qualche mese e fine.
I contratti di supporto gestiti da terzi costano un fottio e ovviamente paghi anche se non ci sono problemi.

Ah, quindi alla fine devi pagare se vuoi avere assistenza. Chi l'avrebbe mai detto.

Se ha le risorse monetarie per farlo, se gli tira il culo farlo, se non viene distrutta da un cataclisma o fallisce o viene comprata, se non cambia idea, o mille altre ragioni per cui alla fine capita che il cliente si attacca al puffo.

Mi sembra che, come descritto anche da te, i soldi li deve cacciar fuori lo stesso.

In Linux e freeBSD non tanto, visto che uno dei motivi per cui sono opensource è proprio evitare questa situazione.

Non vedo come, onestamente.

Eppure tante aziende mica da poco l'hanno fatto. Avranno fatto i loro calcoli e hanno visto che probabilmente gli conveniva.
Magari è ora di parlarne anche coi tuoi di capi.

Se smettono di trattare Linux come se fosse "Windows con API/ABI/driver model instabili" e seguono le regole magari ci rimettono meno a supportarlo, forse ci guadagnano anche.

Guarda che la mia azienda è il maggior contribuire di Linux, ed è quella che rilascia i driver open source per le sue GPU da quando AMD nemmeno si sognava di farlo.

So benissimo com'è la situazione, sebbene NON condivida quest'approccio per tutte le ragioni che ho ampiamente esposto.

Altre aziende i loro calcoli se li fanno lo stesso, e decidono di rilasciare soltanto i binari.

Cosa che, in ogni caso, fa anche la mia azienda in alcuni casi. Sì, anche per Linux, e supportando ben precise versioni del kernel.

Il motivo è sempre il solito: dipende tutto da cosa si vuole ottenere, dai costi, e da cosa si vuol rilasciare.

L'unico fork di glibc che ricordo è questo, non è esattamente uguale a come lo descrivi. Forse se chiarisci meglio la situazione ci capiamo meglio.
vedi qui
https://lwn.net/Articles/488847/

Ecco qui: http://linux.slashdot.org/story/09/0...libc-to-eglibc

a causa di questa primadonna: https://sourceware.org/bugzilla/show_bug.cgi?id=5070#c5

Comunque, questo è un'altro esempio dove l'opensource salva il didietro mentre il closed no.
E mica cazzi o ideologie. Questo è cash risparmiato, non blablabla hippie da convention.

Questi sono soldi buttati, visto che i fork non sono aggratis. E tutto per colpa di una prima donna.

Mettiamo caso che fosse closed e per i vari motivi validi citati da te nei tuoi post rispondesse picche (nota che non sono sarcastico, sono motivi validi).
Che si faceva?
L'unica strada era migrare un fottio di codice ad usare un'altra libreria. Bello, deve essere facile, costare poco e richiedere poco tempo.

Con un fork di emergenza gestito da mantainer del kernel e delle distro maggiori (glibc era sviluppato da 4 gatti quindi non è che fosse sto gran peso) sono riusciti a tirare avanti finchè il tizio non si è ripigliato, ma in caso non si ripigliasse quella diventava di fatto il rimpiazzo di glibc.

Comunque non è che fosse tutta sta gran difficoltà, in quanto se vedi glibc è stata sviluppata da un tizio solo più qualche cosina minore da altri per tipo 10 anni.

Per inciso, abbiamo anche un ulteriore caso di "community in azione". Una azienda che si era rotta le palle della situazione ha pagato UN singolo developer per sistemare le cose una volta per tutte (quello che è rimasto per 10 anni di cui sopra), e nel giro di qualche anno il problema si è risolto.

Sì, un'azienda ha dovuto tirare fuori soldi soltanto perché quella primadonna aveva la luna di traverso.

Ma infatti, il mondo closed è pieno di esempi di serietà, integrità e professionalità come Adobe che decide che Flash su Android non lo sviluppa più fregandosene di tutti quelli che ci contavano per i loro giochini, contenuti e pubblicità.

Considerata l'enorme frammentazione di Android, che ha superato di gran lunga quella di Linux, direi che è stata anche costretta.

Di compagnie che si interessano tantissimo dei ticket che apri per i loro software che la tua azienda paga uno strafottio, così tanto che il problema viene sistemato quando gli tira a loro o forse mai, e se a te serviva son cavoli tuoi.
Se sei Microsoft, Google, Apple o IBM vai lì è li bombardi, ma una azienda media si attacca.

A cosa? Se paghi hai un servizio. E non hai a che fare con primedonne che mandano a monte il tuo lavoro.

O dei vari produttori di SoC con SDK merdacchiosi che ti limitano ad una versione tagliatissima e totalmente delirante del firmware basato su Linux, con vari bug bonus da aggirare a botte di script.
(Ciao realtek!!)

Mentre nel frattempo coi SoC opensource (vedi Kirkwood della Marvell) basta che mi connetto con la UART, flasho un u-boot decente, e poi BUM, carico Debian o Arch (un pò più complesso in realtà, ma si fa in un'oretta tranquillamente seguendo tutorial da internet). Mica Raspbian o dei minchiosissimi firmware da SDK medio, Debian ARM o ALARM (Arch per ARM).
Un NAS Zyxel del menga da 70 euro che fa girare OpenMediaVault, con accesso a TUTTI i pacchetti di Debian armel.

Non succedere questo casino se Linux, come tutti gli altri s.o. da quando sono nati, mettesse a disposizione API e ABI stabili.

E' Linux il problema, se non fosse chiaro. Gli altri s.o., anche open source, non sono nelle stesse condizioni.

Scusa un attimo è meglio fare un fork se qualcuno si inpunta e pagare UN singolo developer per sistemare il casino o migrare ad una libreria diversa (se esiste)? o creare una nuova libreria?

Se quel tipo che si impuntava lavorava con del codice closed voi che facevate? Vi attaccavate al puffo tutti senza se e senza ma.

Con il codice open se della gente fa cazzate gli forki il progetto e procedi nella direzione che ti serve. Ti costa un pò di più, ma non ti schianti brutalmente.

Ma non avevi detto che il modello Linux era più conveniente? Lo vedi che alla fine, devi pur sempre cacciare fuori i soldini, e pure di più?

Questo è un'altro effetto dell'opensource, molto ma molto gradito specialmente a ditte di una certa dimensione e ai governi che usano sistemi open.
Non sono solo i manutentori ad avere il controllo sul codice, ma anche le aziende interessate, e non esiste che perchè l'azienda X dice che non gli va di continuare a supportare/aggiornare un prodotto allora le altre si attaccano al puffo.

Dipende tutto dagli interessi che hanno. Se gli interessa investono. Altrimenti, come dici tu, si attaccano tutti al puffo, e il cerino resta in mano ai legionari del software diversamente libero, che si dovranno smazzare il tutto.

P.S. Non ho tempo di correggere eventuali errori, mi spiace.

[Pier2204]

@bobafetthotmail @Cdmauro

Scrivete papiri

Riassumendo: Windows 10 si può installare su qualunque PC che ha i requisiti riportati nella news che sono veramente minimi, segno che il lavoro di ottimizzazione è stato fatto bene, senza preoccupazioni, portatili con UEFI hanno nel 99% dei casi il secure boot disattivabile quindi ci si può installare anche Linux. Che se non sbaglio tutte le distro sono ormai compatibili con UEFI, di sicuro lo sono Ubuntu, opensuse, e fedora.

Scusate, ma non è che MS può preoccuparsi se il produttore di un hardware vecchio non rilascia più il driver di un qualcosa che non commercializza da anni...che poi da quello che ho capito tutto ciò che funziona sotto Windows 8.1 funziona anche sul 10. La questione driver mi sembra che sia l'ultimo dei problemi di Windows. O mi sbaglio?

[Pier2204]

Comunque nel link qui sotto hanno messo Windows 8.1 in un telefono/tablet/pc da sette pollici
Ha il modulo telefonico e ha 8.1 phone

Inutile dire che sono di Hong Kong..

http://www.windowsteca.net/2015/04/r...a-da-4000-mah/

[cdimauro]

Originariamente inviato da Pier2204

@bobafetthotmail @Cdmauro

Scrivete papiri

Mi spiace, avevo parecchie cose da dire, e il commento s'è allungato troppo.

Riassumendo: Windows 10 si può installare su qualunque PC che ha i requisiti riportati nella news che sono veramente minimi, segno che il lavoro di ottimizzazione è stato fatto bene, senza preoccupazioni, portatili con UEFI hanno nel 99% dei casi il secure boot disattivabile quindi ci si può installare anche Linux. Che se non sbaglio tutte le distro sono ormai compatibili con UEFI, di sicuro lo sono Ubuntu, opensuse, e fedora.

Anche se non fossero compatibili UEFI + secure boot, non è un problema di Microsoft ma degli OEM. I fanatici sono pregati di rivolgersi a questi ultimi se hanno problemi con le loro distro.

Scusate, ma non è che MS può preoccuparsi se il produttore di un hardware vecchio non rilascia più il driver di un qualcosa che non commercializza da anni...che poi da quello che ho capito tutto ciò che funziona sotto Windows 8.1 funziona anche sul 10.

Dovrebbe esser così.

La questione driver mi sembra che sia l'ultimo dei problemi di Windows. O mi sbaglio?

Non credo.