Confermati i piani di Valve su Steam per Linux

Mi sembra una scusa. Non dico da parte tua, ma molti utenti Linux integralisti effettivamente ragionano cosi`. Quando diverso tempo fa ho provato a chiedere informazioni per utility su overclock e similia per questo OS, mi e` stato risposto similmente "su Linux non si fa overlock".

Personalmente se avessi un supporto [U]completo[/U] alle periferiche ed i componenti hardware che ho (che non sia solo "basta che funzioni". Non basta), oltre ad esserci giochi e software come su Windows, passerei a Linux in pianta stabile anche io. Gia` praticamente la totalita` del software che uso e` free ed open source. Purtroppo c'e` sempre qualche problema che mi impedisce la transizione, e molto spesso e` lo stesso anche per gli sviluppatori (non e` solo una questione di market share).

@s12a

volevo dire una cosa molto semplice: chi vorrebbe produrre giochi per linux, farebbe bene a lasciar stare; soldi e tanto tempo risparmiato:

1: chi usa linux non bada ai giochi. chiedi che mestiere o tipi di studio fa la sua utenza.
2: per sviluppare giochi e applicazioni su linux, c'è bisogno di un sistema "omogeneo", impossibile su linux per sua stessa natura.

su linux scordati un supporto completo hardware e software.
seguo la sua evoluzione da 10 anni, e potrei disegnarti la strada dei suoi prossimi 10 anni.

queste cose che stiamo dicendo adesso, sono state ampiamente dibattute e approfondite molti anni fa, e dopo molti anni, siamo ancora qui a parlare delle stesse cose.

windows è il s.o. meno "omogeneo" di tutti ma i giochi li sviluppano, non è quello il problema

Hanno cominciato a sviluppare giochi per Windows quanod Microsoft ha rilasciato delle DirectX decenti... e ora si sviluppa in DirectX, non per Windows... tant'è che la maggior parte degli engine è portabilissimo tra piattaforme anche diverse come Windows in DX11, Xbox360 che ha un sovrainsieme delle DX9 e PS3 che è OpenGL...

Hardware --> Drivers --> SO --> Librerie (DX, OpenGL, ecc..) --> Engine --> Gioco... l'engine vede solo le librerie, quello sotto è trasparente. Se l'engine supporta diverse librerie, il gioco può essere portato ovunque senza cambiare una virgola, al di là di qualche ottimizzazione.

non ti far ingannare dalle novità architetturali introdotte da una release all'altra o magari dalle differenze funzionali tra versioni diverse di una stessa release, quel che conta sono le API e ABI (soprattutto le interfacce binarie), e da quel lato, windows è notevolmente omogeneo...
se io sviluppo in funzione di una certa API, a meno di casi particolari (utilizzo di interfacce non documentate kernel mode, driver, o accesso diretto all' hw da userland) posso sostanzialmente coprire con una sola code base tutte le versioni di windows a partire da quella su cui quell' API è stata introdotta - e trattarle come un unico target (certo un' applicazione che faccia uso di DirectWrite o un driver WDDM non funzionerà su win2k, ma un' applicazione win32 scritta ai tempi di win98 funzionerà senza problemi anche sotto 7)

certo, allo stato attuale dovrò distribuire e supportare versioni del mio programma, a 32 e a 64 bit, magari con o senza supporto per api introdotte da vista in poi come appunto DirectWrite per il rendering del testo..
ma anche in questo modo sono 4 versioni in tutto, confrontate con le
2 (32/64 bit ) x <distribuzioni supportate> x <release della distribuzione rientranti nel lifetime del mio prodotto>
che dovrei avere su linux ...

in linux l'unica differenza è che le librerie grafiche sono OpenGL e non directx

per distribuire il software bastano un .deb ed un .rpm e sono coperte tutte le distribuzioni (come fanno tutte le aziende che supportano linux)

certo c'è la questione 32/64 bit ma non mi pare che il client steam sia a 64 bit... e comunque il problema c'è anche in windows

windows è il sistema che mantiene compatibilità anche con programmi di millemila anni fa.

su slackware 10 avevo aggiornato perl a current: da perl ufficiale 10 a current 10 di slacky, il 70% dei prog che richiedevano quelle librerie non andavano più.
una notte insonne per ricompilare tutti i programmi linkandoli alle nuove librerie.

c'è poca gazzosa da produrre a parole: linux in queste condizioni, non è un sistema dove puoi far girare dei giochi.
a meno che, da produttore di giochi, non supporti solo una distro di uso comune come ubuntu, opensuse o altro.
dopo questo, poi c'è la questione del preistorico xorg e dei driver nvidia che non sono estremamente prestanti, ... per non parlare di quelli ATI ww

p.s. come tutti i giorni, sto leggendo e scrivento dalla mia bellissima deepin

Ma evitiamo di dire castronerie. Prova ad argomentare la tua affermazione quantomeno.

Bisogna capire cosa intendete voi per omogeneo... una tipica installazione windows comprende "pezzi" provenienti dalle parti più disparate

hai letto il post precedente?
direi di no, perchè io facevo riferimento alla compatibilità all' indietro e in avanti da una versione all' altra del sistema, e in pratica al mantenimento anche delle API cosiddette deprecate (su windows una api deprecata è una api il cui uso è scoraggiato in nuove applicazioni ma il cui supporto è mantenuto, di modo che le applicazioni che ne fanno uso possano continuare a funzionare, e dove questo non sussista, si definisce e si indica chiaramente un periodo di mantenimento di modo che gli sviluppatori possano regolarsi di conseguenza - su linux una api deprecata è una api che oltre ad essere scoraggiata perchè obsoleta, non sicura, ecc, non è più supportata di punto in bianco, con le applicazioni che ne facevano uso che cessano di funzionare a seguito dell' aggiornamento della libreria che la esportava (o del kernel stesso, nel caso di driver/moduli) e gli sviluppatori costretti a riscriverle in funzione della nuova api... per di più spesso senza preavviso e in tempi brevi a seconda di come "gira" agli sviluppatori delle librerie stesse, e senza tempi di mantenimento, a volte intenzionalmente proprio per forzare i consumatori delle api a inseguire, affinchè l' ecosistema sw non dia un' impressione di staticità, come se quello fosse il problema maggiore, e non l' usabilità / funzionalità del sistema...) che solo apparentemente possono rappresentare un problema secondario, in realtà fondamentale nel quadro di un supporto continuativo a una piattaforma informatica...

deb ed rpm sono solo formati di pacchetti contenenti i file da installare e metadati descriventi le dipendenze, coprono sì tutte le distribuzioni ma solo per quanto riguarda il deployment del software - in che modo ne faciliterebbero, unificandolo, il processo di creazione?