La killer application è...

  • VirtualBox (50%, 1 Votes)
  • Compiz-Fusion (50%, 1 Votes)
  • Mojo setup (0%, 0 Votes)
  • È da inventare (0%, 0 Votes)
  • OpenOffice.org (0%, 0 Votes)
  • Phoronix Test Suite (0%, 0 Votes)
  • Wine (0%, 0 Votes)
  • Murrine GTK Engine (0%, 0 Votes)
  • Banshee (0%, 0 Votes)
  • Altro (magari lascia un commento) (0%, 0 Votes)

Total Voters: 2

Loading ... Loading ...

Giganti del software a confronto

April 5th, 2009 | Written by Supergiu

La storia di Unix ha qualcosa di sorprendente: Thompson e Ritchie iniziarono a svilupparlo nel 1969 nei Bell’s Lab e dopo quasi quarant’anni non si contano nemmeno più le sue varianti: System V, Xenix, BSD, Irix, SunOS, NetBSD, FreeBSD, e molti altri. Anche se alla fine tutti questi sistemi operativi discendono da appena due o tre tipi di Unix, oggi si notano ancora numerose caratteristiche in comune con l’originale di AT & T.
Soltanto negli ultimi tempi Linux si è affermato tra i sistemi operativi di fascia home computing, mentre FreeBSD ha catalizzato maggiormente l’interesse dei professionisti dell’high tech. Nonostante questo, spinto soprattutto dalla curiosità, ho provato l’ultima versione di FreeBSD (la 7.1) con i videogiochi, l’aspetto che prediligo di più di un computer. Purtroppo, i miei titoli preferiti non hanno funzionato. Ho rinunciato, per problemi vari, a giocare con Quake Wars, Quake 4 e Doom 3.
Pur senza svolgere un benchmark comparativo approfondito, ho potuto farmi una idea delle principali proprietà del sistema. Ora, non me la sento di dire se in generale FreeBSD sia migliore di Linux o viceversa, come dice Matthew D. Fuller nel suo blog: “siamo tutti d’accordo nel considerare Unix la scelta migliore, ma abbiamo idee divergenti su quale usare”. Entrambi hanno eccellenti qualità nell’ambito delle attività di Rete (networking), possono “girare” su molte architetture hardware in commercio, e vengono adoperati quando la sicurezza diventa un fattore critico per la salvaguardia delle informazioni o delle operazioni di un server. Sono pertanto la soluzione ideale per Lanparty o partite in multiplayer.
Spesso ci si riferisce con Linux solo al kernel (il nucleo, dall’inglese) del sistema operativo, mentre il nome FreeBSD viene dato all’insieme dei software che girano sul calcolatore sotto la licenza BSD. Un’altra differenza, abbastanza evidente, si riscontra nel ciclo di sviluppo: decentralizzato su Linux, centralizzato in FreeBSD. Il prodotto finale è di solito una distribuzione Linux che combina il kernel, gli strumenti di produttività, un ambiente desktop e altre applicazioni, mediante un gestore di pacchetti (deb, rpm, tar, ecc.); al contrario gli sviluppatori di FreeBSD lavorano sempre sullo stesso gruppo di programmi (base system) che consegnano aggiornato e pronto per l’installazione. Al massimo esistono delle varianti che soddisfano i gusti di determinate utenze di computer, ad esempio l’utente occasionale (casual user) di PC-BSD. Le maggiori distribuzioni Linux sono Ubuntu, OpenSUSE e Fedora. I derivati di FreeBSD più famosi sono PC-BSD, Mac OS X, m0n0wall.
BSD e GNU sono due licenze di utilizzo dei programmi, fra le tante disponibili nel panorama del software di tipo open source. Rispetto alle alternative, sono state preferite da una ampia base di sviluppatori fervidamente convinti dei vantaggi che la ridistribuzione del codice sorgente può portare alla società.

FreeBSD 7.1

FreeBSD 7.1

Questa era la mia prima installazione di FreeBSD e pertanto temevo di commettere qualche pasticcio; durante la procedura tenevo pronto sulla scrivania un computer portatile collegato al sito Internet http://www.freebsd.org, per evitare di bloccarmi in passaggi poco chiari. La grafica del programma di setup (sysinstall), realizzata con la libreria curses, mi ha lasciato perplesso fin dall’inizio. Però è andato tutto liscio sotto ogni aspetto: scelta della lingua, configurazione della tastiera, impostazione della scheda e dei servizi di rete, selezione dei pacchetti software da un elenco di categorie, e così via. Io poi avevo già creato una partizione di tipo FreeBSD con fdisk di Ubuntu, quindi credo di aver semplificato il procedimento. Sapevo infatti che il “partizionamento” faceva riferimento alle unità logiche che si usano raramente in Linux.

Inizialmente volevo svolgere un benchmark con Phoronix Test Suite, poi ho avuto un ripensamento perché non riuscivo a fare la maggior parte dei test previsti. Visto l’insuccesso, ho ripiegato su un altro metodo, forse laborioso ma efficace: l’esecuzione del timedemo in Enemy Territory. Mi serviva la registrazione (demo) di una partita, da ripetere sia su Linux che FreeBSD con alcune opzioni per il calcolo del frame rate medio di ciascun sistema. Non immaginavo che dal confronto potesse risultare una differenza di prestazioni quasi insignificante. A 800×600 pixels c’era uno scarto di appena quattro frame per secondo e raggiunta la risoluzione di 1280×1024, con un alto livello di dettaglio dell’immagine, sia Linux che FreeBSD facevano cento frame al secondo. Questi dati dovrebbero incoraggiare anche i più scettici a trasferire Enemy Territory da un sistema all’altro. Di solito su FreeBSD i videogame per Linux sono eseguiti con un emulatore (linuxator) che il giocatore, avido come è di tempi di risposta rapidi, potrebbe giudicare male; ma in questo caso non ha penalizzato l’elaborazione in modo marcato. Il computer utilizzato per la prova era il mio PC “assemblato” con la seguente componentistica, già ampiamente descritta in passato:

  • CPU Amd Athlon 64 X2 4800+
  • Mobo Gigabyte GA-M57SLI-S4
  • Kingston KVR800D2N5 DDR2 800Mhz, 1024MB * 2
  • Hard Disk Western Digital Caviar 80GB, 7200 rpm, 8MB di cache
  • Scheda video XFX Nvidia GeForce 8600 GTS, 256MB DDR2

Il software preso in esame invece era:

  • Linux Ubuntu 8.10 (x86), Xorg 1.5.2, Nvidia 180.44
  • FreeBSD 7.1 (x86), Linuxator con Linux From Scratch 6.4, Xorg 1.5, Nvidia 180.44

Spesso gli utenti tornano a usare Linux dopo un breve periodo di prova di FreeBSD. Per varie ragioni: i giochi commerciali sono una rarità, devono installare un emulatore (linuxator oppure vmware), non tutti vengono eseguiti meglio che in Linux. Ma soprattutto hanno difficoltà a trovare altri giocatori, ai quali chiedere aiuto o consigli.

Panzer sulla strada per Mosca

March 6th, 2009 | Written by Supergiu

Paesi Bassi Io giocai a un gioco molto simile a Panzer General nel 1988. Lo trovai allegato a una rivista per il computer C64. Si chiamava “Obiettivo Mosca”. In realtà il titolo originale era “Road to Moscow”, ma a quei tempi la casa editrice Logica 2000 faceva rimuovere da esperti programmatori la protezione ai videogiochi per ridistribuirli nelle edicole con nuovi nomi e prezzi più bassi. Panzer General fu pubblicato nel 1994 da Strategic Simulations. Riscosse subito un enorme successo fra gli utenti del sistema MS-DOS; ottenne anche un Origin Awards come miglior gioco di strategia e simulazione. Si trattava, essenzialmente, di un wargame a turni con regole analoghe a quelle degli scacchi: il giocatore muoveva i propri pezzi sullo scacchiere quando gli toccava, cercando di limitare le perdite o di mettere in trappola l’avversario.
Nonostante siano passati oltre dieci anni, Panzer General secondo me esercita ancora una forte attrattiva, perciò voglio riproporlo. Certo potrebbe sembrarci banale se lo confrontiamo con i titoli recenti costruiti con la grafica 3D, la musica e gli effetti sonori innovativi permessi dalle nuove tecnologie. Comunque, ho passato ugualmente le ultime due settimane a ideare piani, spostare pedine e contenere le minacce del nemico come un vero Generale. Il gioco resta divertente, inoltre segue fedelmente alcuni avvenimenti della seconda guerra mondiale. Ripassare un po’ di storia in questo modo, non guasta: tra gli scenari previsti spiccano l’invasione della Polonia, l’operazione Barbarossa, la caduta di Berlino, la campagna d’Africa di Rommel, soprannominato la volpe del deserto.
Bisogna affrontare un altro giocatore o il computer su 38 scenari di battaglie sia storiche che immaginarie del periodo compreso fra gli anni 1939 e 1945, presi singolarmente o all’interno di una campagna di guerra (sono le due modalità di gioco). Durante una “campagna”, si assume il comando supremo delle armate tedesche, composte da unità di vario tipo: forze di terra (Heer), aeree (Luftwaffe) e navali (Kriegsmarine). In questo gioco le unità hanno nomi storici e riportano informazioni accurate; guadagnano esperienza, scontro dopo scontro diventano più forti. Ogni missione va portata a termine entro un certo numero di turni senza trascurare l’obiettivo: distruggere tutte le unità dell’avversario, oppure occupare le aree strategiche (città, aeroporti, porti). Se si raggiunge lo scopo col massimo numero di mosse, la vittoria si dice minore, altrimenti è maggiore, quindi schiacciante. C’è una disfatta quando tutte le unità vengono distrutte, oppure scade il tempo concesso per la guerra: siamo tacciati di incompetenza al comando e non c’è altra possibilità che riprendere la campagna dall’inizio. La strategia è una disciplina; qui si fanno i conti con diversi fattori importanti governati dalla IA: le condizioni meteo, la difesa eccezionale, il fuoco difensivo, l’attacco di sorpresa, i rifornimenti ai mezzi o il rinforzo delle truppe.
Il progetto Lgeneral cerca di rilanciare e aggiornare Panzer General. L’engine utilizza gli scenari 2D originali, quelli presenti sui dischi distribuiti da Stratecic Simulations. Oggi sono pure raccolti online in un archivio tar, e l’autore di Lgeneral ci tiene a precisare che il materiale ancora è sotto copyright di SSI, ma utilizzabili. Le due versioni del gioco si differenziano soltanto per poche modifiche alle regole. LGeneral non è perfetto sotto tutti i punti di vista: si può migliorarlo aggiungendo un menù per la selezione delle unità, i messaggi di aiuto o segnalazione, ad esempio quando soppraggiungono i rinforzi; bisogna correggere gli svarioni della IA, troppo evidenti nelle battaglie navali tra sommergibili; la IA del gioco schiera le unità sullo scacchiere nelle solite posizioni prevedibili. Non resta altro da fare che provare personalmente LGeneral, per di più senza troppo impegno, dato che non serve cercare un emulatore e configurarlo.

  • Grafica: 6
  • Suono: 5
  • Gioco: 7.5
  • Sistema:7
  • Globale
    • 6.375

Linux e il 3D Benchmarking

February 23rd, 2009 | Written by Supergiu

L’analisi delle prestazioni di un elaboratore consiste nel misurare le capacità di calcolo con un insieme di programmi (carico di lavoro, detto workload) particolari. “Nella maggior parte dei casi le prestazioni sono l’attributo più importante nell’orientare la scelta fra diversi elaboratori disponibili” (Patterson e Hennessy, Struttura e progetto dei calcolatori, pag. 37). Certamente la misura da sola non suggerisce alcuna indicazione utile all’acquirente. Occorre ripeterla fra varie macchine, cioè svolgere un confronto e poi riferire i risultanti. Studiando questi dati, nel corso degli anni, i progettisti hanno perfezionato gli elementi del personal computer che davano maggiori prestazioni in certe aree piuttosto che in altre. L’acceleratore grafico (GPU) ha sostituito la CPU nei calcoli geometrici e si è specializzato sul rendering delle scene 3D. La tecnologia SLI (o l’alternativa Crossfire), di recente invenzione, promette di raddoppiare o triplicare (quasi), a seconda del numero di GPU messe in parallelo, le prestazioni dell’elaboratore con le applicazioni 3D che sono prevalentemente giochi basati su OpenGL o DirectX. Gli ingegneri hanno aggiunto poi alla GPU le istruzioni macchina per risolvere complicate formule di matematica e fisica, mi riferisco all’engine CUDA di nVidia. Una valutazione accurata sull’efficienza del sistema hardware e software viene svolta con un gruppo di benchmark. Si tratta spesso di programmi individuati fra quelli che l’utente utilizza abitualmente (Phoronix Test Suite), oppure sono applicazioni specifiche che esaminano determinate componenti (CPU2006, RAMSpeed, ecc). Oggi la grafica 3D richiede più potenza e memoria di qualsiasi altro programma per PC. Quando usiamo i videogiochi come carico di lavoro sul nostro banco di prova, otteniamo una previsione molto attendibile delle prestazioni del calcolatore. Il metodo è semplice. Possiamo valutare l’affidabilità del nostro computer partendo dai seguenti giochi: Quake III, Unreal Tournament 4, Doom 3, Enemy Territory, Quake Wars, Savage 2, Nexuiz, perché li troviamo a pagamento, gratuitamente o come demo nel World Wide Web e con uno sforzo minimo riusciamo a installarli in Linux.

Quake Wars

Quake Wars si adatta bene all’analisi delle prestazioni. Il suo motore grafico è derivato da Doom 3 e incorpora la tecnologia denominata MegaTexture che migliora indubbiamente l’aspetto del gioco negli spazi aperti della mappa. Possiamo adoperare, per il nostro scopo, la versione di prova oppure quella commerciale. Prima dobbiamo scegliere la mappa, quindi registrare una partita da Internet e poi ripetere la registrazione con una opzione determinata. Al termine dell’operazione, il motore grafico calcola il frame rate dividendo il numero totale di immagini che compongono l’animazione con il tempo, espresso in secondi, impiegato dalla macchina fisica per visualizzarle. Il risultato esprime l’effettiva prestazione della scheda grafica e del sottosistema hardware/software. Il valore suggerisce anche a quale risoluzione video possiamo giocare senza perdere troppa qualità nell’immagine.

Scarica uno dei pacchetti messi a disposizione per Linux

Quake Wars demo v2.0
– Contiene la mappa Valley
Quake Wars 1.5 Full – Richiede il DVD

Per registrare una partita, collegati a un server e premi il tasto F12. Troverai il file della registrazione nella directory:
$HOME/.etqw/base/demos

Dalla console del gioco esegui i seguenti comandi in successione:

com_unlock_FPS 1
com_unlock_timingMethod 0
com_showFPS 1
timeNetDemo FILENAME.ndm
condump FILENAME.log

Puoi mettere questi comandi, preceduti dalla parola chiave seta, in un file di testo chiamato NOMEFILE.cfg:

seta com_unlock_FPS 1
seta com_unlock_timingMethod 0
seta com_showFPS 1
timeNetDemo FILENAME.ndm (* questo senza seta *)

Poi dalla console devi soltanto invocarlo con:
exec NOMEFILE.cfg

Non dimenticare la riga di comando di Unix che abilita la console (se disabilitata):

etqw +set com_AllowConsole 1

Ho messo a confronto il PC Frag Storm con il portatile Asus A6Tc. I risultati sono raccolti in diversi istogrammi. Tra i due computer c’è una marcata differenza di prestazioni alle alte risoluzioni: da 1280×1024 pixels in su, per intenderci. Lo scarto si riduce ad appena venti FPS usando la configurazione di 800×600 pixels con bassa qualità della immagine. Da questa analisi, mi aspettavo un rendimento maggiore dal PC Fragstorm perché montava delle componenti più moderne e potenti. Ma non posso nemmeno lamentarmi ora che raggiungo le risoluzioni elevate mantenendo un frame rate decente: il minimo di quaranta FPS è pur sempre garantito a 1680×1050 pixels, a questo livello ricordo che la resa del portatile era pressoché nulla. Non ho preso in considerazione l’overclocking, col quale avrei potuto guadagnare prestazioni leggermente superiori, credo.

PowerMizer per la GeForce 8600 GTS

PC Fragstorm

  • CPU Amd Athlon 64 X2, 2.5GHz
  • 2 GB DDR2, 800MHz
  • GeForce 8600 GTS, GPU Clock=675Mhz, Memoria DDR3 da 1008Mhz

Asus A6Tc

  • CPU Amd Turion 64 X2, 1.60Ghz
  • 1 GB DDR2, 533Mhz
  • GeForce 7300 Go, GPU Clock=325MHz