Riportiamo a beneficio di tutti i clienti Aruba il loro ultimo comunicato stampa nell'attesa che finalmente la situazione di disagio rientri e tutto torni alla normalità.

Aggiornamento – Comunicato stampa

Arezzo, 29 aprile 2011

Stamane alle h. 04:30, un corto circuito avvenuto all’interno degli armadi batterie a servizio dei sistemi UPS della Server Farm aretina di Aruba ha causato un principio di incendio: è immediatamente entrato in funzione il sistema di rilevamento incendi che in sequenza spegne il condizionamento e attiva il sistema di estinzione.

Poiché il fumo sprigionato dalla combustione della plastica delle batterie ha invaso completamente i locali della struttura, il sistema ha interpretato la persistenza di fumo come una prosecuzione dell’incendio e ha tolto automaticamente l’energia elettrica.

Confermiamo che nessun danno è stato arrecato ai server e agli storage che ospitano i contenuti dei nostri clienti e alle persone presenti in azienda. Non si è verificata alcuna perdita di dati.

L’azienda ha prontamente risposto all’evento in collaborazione con i vigili del fuoco di Arezzo, che ringraziamo vivamente, ma e’ stato possibile accedere ai locali solo dopo due ore dall’estinzione dell’incendio a causa del fumo presente.

Solo a questo punto il nostro personale tecnico ha potuto attivare la prevista procedura di emergenza che ha consentito il ripristino in breve tempo dell’alimentazione di due delle tre sale server del data center: precisamente, alle h.10:30 la prima sala server è tornata attiva, la seconda è stata rimessa in funzione attorno a mezzogiorno.

Alle h.15:30 è stata ripristinata l’alimentazione completa dell’intera server farm.

Oltre cento persone hanno lavorato per ridurre al minimo il disservizio.

Allo stato attuale risultano da completare i lavori di sostituzione di tutte le batterie (oltre 1200) e di tutti gli UPS con sistemi di altra marca. Queste attività proseguiranno ininterrottamente per tutto il weekend.

I tecnici della società Eaton, fornitrice dei gruppi UPS, delle relative batterie e del servizio di manutenzione, stanno svolgendo le indagini necessarie ad individuare l’esatta causa del guasto.

Inoltre, nonostante sia consuetudine installare le batterie all’interno del data center, per evitare il ripetersi di quanto accaduto, da oggi le batterie del data center di Arezzo e di tutti gli altri data center del Gruppo Aruba saranno installate in appositi locali, esterni e separati dalla struttura principale.

I nostri clienti sono stati costantemente aggiornati sull’evoluzione della situazione attraverso il nostro sito di assistenza, la nostra pagina su Facebook e  su Twitter.

Aruba ringrazia i fornitori e i dipendenti per la loro collaborazione ed il lavoro svolto oggi; ringrazia poi in particolare i clienti per la comprensione dimostrata e le numerose testimonianze di fiducia e supporto ricevute.

    Aruba si scusa per il disagio arrecato.

Fonte: Aruba.it

Server e servizi Aruba sono fermi da alcune ore a causa di un principio di incendio presso una Server Farm del gruppo.

Oggi non si vedono milioni di siti Web in Italia. La struttura portante di una grande fetta del web italiano, la server farm aretina Aruba, è stata colpita da un incendio, iniziato nella sala UPS. Ora l’incendio che ha interrotto il servizio web di milioni di siti in Italia, è stato domato, ma su Twitter Aruba fa sapere che «stanno procedendo con la rimozione della polvere prodotta dalla combustione. A seguire verranno effettuati gli interventi di ripristino».

«A seguito del principio di incendio sulle batterie degli UPS, confermiamo che le macchine server e le sale dati non hanno subito alcun danno». Il che è la prima garanzia necessaria. In seguito Aruba ha comunicato che è in corso la rimozione della polvere prodotta dalla combustione, aspetto che anticipa la successiva fase di ripristino. Tuttavia il gruppo non intende procedere con eccessiva solerzia: «stiamo privilegiando la sicurezza delle persone: la riaccensione senza dovute verifiche, creerebbe un pericolo e causarebbe nuove ricadute».

Di recente Aruba ha completato tre nuove acquisizioni: HostingPlan.it, Consultingweb.it, e Olimont.com. Il Gruppo Aruba ad oggi conta più di un milione di domini registrati e mantenuti e oltre 1.500.00 di clienti attivi.

Si tratta senza dubbio del più grosso black out della Rete italiana. 

Chrome OS scalpita. Manca ormai poco al debutto ufficiale del sistema operativo creato da Google e pensato per il cloud computing. La data non è ancora definita esattamente, ma la presentazione ufficiale potrebbe avvenire tra il 10 e l’11 maggio, in occasione della conferenza I/O.

Dopo aver trascorso mesi in fase di sviluppo, a quanto pare Chrome OS ha raggiunto la maturità ed è stato considerato abbastanza stabile da poter equipaggiare i computer che utilizziamo tutti i giorni, anche se ancora non è stato distribuito ai tester sparsi un po’ in tutto il mondo. Tecnicamente, Chrome OS è un sistema operativo che si poggia quasi esclusivamente su un browser e sul concetto che nel mondo odierno molte delle attività da noi svolte possono normalmente essere fatte direttamente sul Web, senza per questo richiedere computer o notebook con configurazioni hardware impegnative e costose.

Di contro, però, per poter fruire completamente delle funzioni del sistema operativo, è necessario avere una connessione ad Internet. Acer, Asus, Sony e Samsung sono le aziende che a quanto pare presenteranno i primi prodotti basati su Chrome OS. Non resta che pazientare ancora un mesetto e poi… installare il sistema operativo di Google e metterlo subito a confronto con gli altri. Secondo voi chi vincerà?

Fonte: http://www.hwjournal.net/articoli/chrome-os-quasi-pronto-lo-vedremo-a-maggio-6738

Da parecchi anni si pone l’esigenza di un sistema universale per gestire i pacchetti nelle principali distribuzioni GNU/Linux, senza che si sia mai raggiunto il minimo accenno di soluzione condivisa.

I sistemi attuali sono equivalenti, pur variando in funzionalità e utilizzo: RPM e DEB si contendono la scena come motori principali, mentre varie interfacce utente hanno il compito di nascondere all’utente tutto il lavoro sporco da essi svolto.

Ci sono stati parecchi tentativi di semplificazione, tra soluzioni precarie, tradizionaliste, rivoluzionarie, sperimentali o semplicemente insostenibili. Nomi come Autopackage, PackageKit, Klik/Glick e vari strumenti che ogni distributore è stato obbligato ad escogitare di volta in volta.

Adesso, in quella che potrebbe essere una svolta storica, finalmente sembra aprirsi uno spiraglio di luce in fondo al tunnel affettuosamente denominato “dependency hell”…

Il problema

Installare software è un compito abbastanza complesso in ogni sistema operativo. Idealmente si tratta solo di copiare qualche file, e in alcuni casi non ci si scosta troppo da questa semplice operazione; nella realtà però una gestione dei pacchetti deve tenere conto di molte esigenze:

• Installazione, rimozione e aggiornamento dei pacchetti
• Gestione di un database di pacchetti installati/installabili/aggiornabili
• Risoluzione di eventuali (inter)dipendenze e/o conflitti
• Esecuzione di script di autoconfigurazione e/o d’avvio
• Già detto “Risoluzione di eventuali (inter)dipendenze e/o conflitti”?

Tali esigenze rendono difficoltosa l’idea di affidarsi ad una semplice copia dei file da installare, specialmente se consideriamo che nei sistemi unix è tradizione suddividere e spargere il contenuto di ogni pacchetto per tutto il filesystem, in base al tipo di file: i binari vanno in /bin, /usr/bin /usr/share/bin e altro ancora, le librerie in /lib, /usr/lib, ecc, secondo un complicato sistema di precedenze e di criticità delle singole componenti.

Se consideriamo che ogni distributore si è sempre trovato a creare un’albero delle directory leggermente diverso dall’altro, un sistema di script di init leggermente diverso dall’altro, un sistema di configurazione leggermentediverso dall’altro, un naming scheme dei pacchetti leggermente diverso dall’altro, una politica di aggiornamento dei pacchetti leggermente diversa dall’altro… capirete bene come si sia arrivati alla situazione attuale, in cui praticamente non esistono due distribuzioni compatibili.

Le soluzioni tradizionali

Ogni distributore ha dunque sviluppato un sistema di gestione dei pacchetti, magari storicamente legato al nome della distribuzione o dell’azienda sviluppatrice, magari con corredo di spunti per garantire anni di ferocissime, intense e inutili dispute su quale sia il migliore, più tecnologicamente avanzato, veloce, affidabile, sicuro, eccetera.

Ciascuno di noi ha le sue preferenze, che – come tutte le religioni – non è il caso di mettere in dubbio, possiamo però ostentatamente ignorare i gestori di pacchetti più casalinghi o legati a distribuzioni minori ed evidenziare i due principali sistemi, gli unici contemplati dalla idealmente importante quanto in pratica inutile Linux StandardBase: RPM e DEB. Il primo viene da Red Hat ed è adottato da distribuzioni quali Fedora, openSUSE, Mandriva/Magiea e altre; il secondo da Debian ed è adottato da Debian stessa e dalle innumerevoli distribuzioni derivate, tra cui Ubuntu.

Anche annullando il motivo d’esistere di ogni buon troll e ponendo che RPM e DEB siano equivalenti (grosso modo lo sono), per tutta la serie di motivi elencati più su, ugualmente non esistono due distribuzioni che usano lo stesso gestore esatto, in quanto molto raramente un pacchetto rpm per openSUSE potrà essere installato su Fedora, o allo stesso modo un deb di Debian su Ubuntu. Dunque due principali tecnologie, usate per creare decine di implementazioni leggermente incompatibili, quel che basta a non permettere l’uso di uno stesso pacchetto su più di una distribuzione. Ma non è questo il punto.

Per rendere meno anale la gestione dei pacchetti da parte dei semplici utenti che vogliono semplicemente installare Firefox, fregandosene bellamente di librerie e dipendenze, sono stati escogitati varie interfacce ad RPM e DEB. Da APT a Synaptic, da YAST a YUM alle decine di altre utilità create con questo scopo. Un primo tentativo sensato di unificare tutte queste piccole divergenze sotto un ombrello che garantisse delle API un’esperienza d’uso uguali e coerenti, a prescindere dal funzionamento reale del motore, è stato PackageKit, tuttora non del tutto implementato.

Le soluzioni sperimentali

Oltre a questo, molto oltre  a questo, c’è sempre stato un impulso al rinnovamento, da parte di utenti e sviluppatori insoddisfatti da alcuni aspetti della gestione dei pacchetti in GNU/Linux, principalmente dalla intensa frammentarietà che porta alla compatibilità suddetta. Sono dunque nati diversi sistemi alternativi, ma semprecomplementari, per gestire pacchetti in maniera più omogenea e pratica per tutte le distribuzioni o quasi.

Uno degli esempi più riusciti, ma sempre largamente fallimentare, è/era Autopackage, un gestore che offre un leggero strato di compatibilità con il gestore della distribuzione, e ponendosi come gestore ulteriore, da usare per quei pochi progetti che nel tempo hanno fornito versioni autopackage dei loro software. Non è mai stato nemmeno ufficiosamente supportato da alcun distributore, che io sappia.

Se Autopackage è stato largamente ignorato, pur essendo forse il migliore esempio, potete immaginare gli altri. Un progetto che ho seguito con molta attenzione è stato Klik, che a differenza di Autopackage e dei sistemi tradizionali, si rifà al concetto di app bundle tipico di Mac OS e implementa un paradigma di 1 file = 1 app, nell specifico si tratta di una immagine in cramfs contenente un piccolo albero di directory con tutte le librerie e i binari dell’applicazione, che in quel modo non vengono sparsi per il filesystem ma rimangono appunto contenute nel file.  In maniera simile funziona(va) anche Glick e così pure un progetto italianissimo: SpatialBundle di Luca Cappelletti.

LA soluzione?

Tutte queste soluzioni sono sempre state caratterizzate dall’assoluta mancanza di coordinazione tra i distributori: quelle tradizionali per motivi che a mio avviso, ripetuto in varie occasioni, possono solo essere visti come la mancanza di prospettiva di chi imbriglia soluzioni aperte in strategie chiuse; quelle sperimentali perché semplicemente non interessavano davvero a nessuno.

Oggi però Frafra ha segnalato una notizia che non esito a definire storica. Sviluppatori di Red Hat, Fedora, Debian, Ubuntu, openSUSE, Mandriva e Mageia si sono incontrati per discutere le caratteristiche di un nuovo gestore di pacchetti universale. Al momento si chiamerebbe AppStream e sarebbe basato sull’interessante progetto Bretzn, presentato dal team di KDE, per quanto riguarda le funzionalità multipiattaforma e multiarchitettura, e idealmente su Ubuntu Software Center per quanto riguarda l’interfaccia utente. Funzionalità molto interessanti, quali la possibilità da parte degli utenti di attribuire e condividere votazioni o commenti ai pacchetti sarebbe prevista tramite Open Collaboration Services.

La parte più interessante è che l’intero progetto non sarà un sistema per distribuire i tanto temuti et famigerati Universal Binaries From Hell, ma si limiterà a fornire metadati, che saranno interpretati da cliente per scaricare i bit necessari. Questo significa che il sistema di installazione dei pacchetti rimarrà di tipo tradizionale, e che dunque le parti che verranno innovate saranno solo quelle che permetteranno di avere un installer universale per tutte le distribuzioni.

Nessuna rivoluzione, ok, ma una benvenuta evoluzione all’insegna della razionalità.

Fonte: http://pollycoke.org/2011/01/25/un-gestore-di-pacchetti-universale-per-linux/

Togliamoci subito dalle palle la questione più idiota. Android è Linux. Diffidate da chi vi dice altrimenti, prima di tutto perché dice il falso, e poi perché vi porta a discutere su una questione inesistente, sostanzialmente rubandovi del tempo che nessuno vi restituirà mai più. Visto che io ci sono cascato all’epoca, vi risparmio la pena e argomento con alcune precisazioni. Android è basato sul kernel Linux: come potete vedere nella schermata qui a fianco, sul mio Nexus One gira Android 2.3.3 Gingerbread, basato su kernel Linux 2.6.35-e-rotti.

Differente discorso, completamente slegato, è se Android sia GNU/Linux. In questo caso dobbiamo prima metterci d’accordo su cosa significhi GNU/Linux e perché, ma ad ogni modo direi che no, Android non è GNU. Il sistema è open source e contiene parti GPL, ma che io sappia non derivano dal progetto GNU, del resto tutte le distribuzioni Linux hanno in fin dei conti ben poco di quel che si definisce strettamente GNU.

Ovviamente dire che Android è Linux non significa che Android è Ubuntu o Fedora o SUSE ecc… A parte il kernel Linux, tutto il grosso delle API per le applicazioni è fornito da Dalvik, una versione modificata di Java creata da Google. Così come non ci sogneremmo di installare Tux Racer su un orologio Linux o qualsiasi dispositivo Linux embedded, le applicazioni scritte per GNU/X11/GTK|Qt/Linux non girano su Android e viceversa, that simple.

In realtà la questione è vissuta male da chi tira in ballo politica, religione e lo stravagante timore che Google si appropri di Linux in qualche modo, se ci pensate sono un po’ le stesse strane paranoie spesso sollevate riguardo a Ubuntu… Ora, se c’è un dibattito in cui non voglio minimamente mettere piede è quello religioso/politico, a me basta sapere che il codice sorgente di Android è aperto e regolarmente rilasciato ad ogni nuova versione e che tale codice, basato sul kernel Linux, pilota il mio smartphone e quello di un numero sempre crescente di utenti, che possono avere un’alternativa aperta ad iOS e altri sistemi proprietari.

Fonte: http://pollycoke.org/2011/03/15/android-visto-da-un-pinguino-curioso/

Ecco un’alternativa all’Android Market, si chiama YAAM, shop di natura open-source che favorisce molto gli sviluppatori di applicazioni. YAAM, è l’acronimo di “Yet Another Android Market“, in italiano: “ancora un altro Android Market”. Con questo lo sviluppatore sostiene che le alternative all’Android Market ci sono. Essendo un progetto open-source YAAM rende disponibile ad ogni utente il codice sorgente su Pixello Studio. 

Lo shop di applicazioni è già da diversi mesi on-line ma di recente ha ricevuto un nuovo aggiornamento che ne ha migliorato le funzionalità. Attualmente gli iscritti al market sono 23.000 mila e 400 le applicazioni disponibili. Tra le feature più rilevanti di YAAM ricordiamo:

• Nessun limite per la descrizione delle applicazioni
• Possibilità di inserire sino a 6 schermate a corredo della descrizione
• Possibilità di inserire la descrizione in formato HTML
• Il ricavato della vendita di applicazioni sarà devoluto interamente allo sviluppatore (eccettuati i costi relativi alla transazione di PayPal) e non come accade con l’Android Market che trattiene circa il 40% del ricavato.

Il market ovviamente non è reperibile nell’Android Market, ma deve essere scaricato da questo sito e può essere installato abilitando la funzione dello smartphone che permette l’installazione di applicazioni non ufficiali.

Fonte

In informatica la concorrenza è una caratteristica dei sistemi nei quali può verificarsi che un insieme di processi computazionali sia in esecuzione nello stesso istante. Tale sistema viene appunto chiamato sistema a concorrenza o sistema concorrente. L'esecuzione parallela può condurre a interazione tra processi quando viene coinvolta una risorsa condivisa.

Un'importante classe di sistemi informatici nei quali gli aspetti di concorrenza sono fondamentali è quella dei sistemi operativi.

Il problema dei filosofi affamati, un classico problema inerente concorrenza e condivisione di risorse

Il concetto di concorrenza è contrapposto a quello di sequenzialità. In un sistema sequenziale i processi vengono eseguiti uno per volta e non si verifica alcuna forma di interazione tra essi durante l'esecuzione.

Introduzione

Si può parlare di concorrenza nel caso di:

• parallelismo reale di esecuzione (nel caso di sistemi multiprocessore dove si possono eseguire parallelamente un numero di processi pari al numero di processori)

• parallelismo virtuale di esecuzione (come nel caso del pipelining).

Dato che in un sistema concorrente la varietà di interazioni che si possono verificare tra processi in esecuzione è notevole, sono state elaborate delle teorie in merito alla gestione delle problematiche connesse alla concorrenza. Sulla base di queste teorie sono state sviluppate sia delle tecniche di programmazione sia dei linguaggi che integrano nativamente primitive per la corretta gestione della concorrenza.

Problematiche

La concorrenza può portare ad una serie di problematiche legate all'utilizzo di una stessa risorsa condivisa da parte di più processi. Un determinato susseguirsi di eventi può causare condizioni critiche. La programmazione concorrente sfrutta alcuni principi per fronteggiare e risolvere questo tipo di problematiche.

• Corse critiche (Race Conditions)
  In alcuni sistemi può accadere che i processi in esecuzione condividano una risorsa comune di qualsiasi natura (sia essa un'area di memoria condivisa o una periferica). In particolare se si verifica che il risultato finale dell'esecuzione di più processi dipende dall'ordine in cui essi vengono eseguiti, questa è una condizione di corsa critica (race condition). Il risultato dell'esecuzione nel caso di corse critiche è assolutamente impredicibile.

Il problema delle "corse critiche" può essere evitato impedendo che più di un processo per volta acceda a risorse condivise. Con la mutua esclusione si evita che più processi che contendono una risorsa riescano ad accedervi contemporaneamente.

• Stallo (Deadlock)
  Quando ad un processo viene garantito l'accesso esclusivo (ad esempio tramite una mutua esclusione) ad una risorsa, possono crearsi situazioni di stallo. Formalmente un insieme di processi è in stallo (deadlock) quando ogni processo dell'insieme attende un evento che può avvenire soltanto tramite un altro processo dell'insieme. Essendo tutti i processi in attesa, nessuno potrà mai creare l'evento di sblocco protraendo l'attesa all'infinito. Le tecniche per individuare situazioni di stallo prevedono l'analisi di grafi delle risorse allocate oppure mediante la creazione di cosiddette "matrici di allocazione". La risoluzione degli stalli può essere affrontata in vari modi. Concettualmente si possono suddividere in:
  • Risoluzione mediante prerilascio: viene scelto un processo che detiene una risorsa dall'insieme dei processi in stallo e viene tolto l'accesso esclusivo (prerilascio o preemption) ad una risorsa condivisa (causa di stallo). L'operazione è talvolta difficile, talvolta impossibile e dipende dal tipo di risorsa che il processo stava bloccando.
  • Risoluzione mediante punto di controllo: vengono creati dei registri (checkpoint) che descrivono lo stato di utilizzo delle risorse condivise. Quando viene rilevato uno stallo si effettua un "ritorno" (rollback to checkpoint) alle condizioni precedenti. Anche questa tecnica è di difficile o addirittura impossibile realizzazione poiché il ritorno potrebbe causare perdita o inconsistenza di dati.
  • Risoluzione mediante eliminazione: viene scelto un processo e viene terminato. Questa tecnica è anch'essa molto complessa e richiede di fare stime e assunzioni sul tipo di processo da eliminare. Inoltre non è garantita l'uscita dalla condizione di stallo per cui potrebbe essere necessario terminare altri processi, situazione che complica ulteriormente la problematica.

È anche possibile effettuare delle stime sulle risorse che verranno impegnate da un processo. Grazie a tali stime, esistono sistemi in cui invece di risolvere le situazioni di stallo risulta più semplice evitarle a priori.

Tutte le tecniche prevedono la costruzione di matrici che tengono traccia dell'utilizzo delle risorse (matrici di traiettoria di risorse) o si basano su algoritmi noti come l'algoritmo del banchiere.

• Starvation
  Letteralmente inedia, è un problema in stretta relazione con lo stallo. Quando le politiche di assegnazione delle risorse condivise favoriscono un processo rispetto ad un altro, il processo a cui vengono assegnate in minor misura soffre di starvation. Esso è infatti bloccato e non può proseguire sebbene non si trovi in una condizione di stallo. Nei sistemi in cui si accede a risorse condivise è sempre necessario stabilire una politica per le priorità e l'ordine con cui esse vengono ripartite. Sebbene queste politiche possano risultare quanto più eque, esse possono portare a condizioni di starvation.

Comunicazione InterProcesso

Nell'ambito della programmazione concorrente la comunicazione interprocesso (IPC o InterProcess Communication) è di fondamentale importanza per gestire correttamente possibili situazioni di accesso a risorse condivise. I sistemi concorrenti mettono a disposizione delle primitive di comunicazione che permettono di alternarsi (escludendosi a vicenda) nell'accesso ad una risorsa condivisa oltre a primitive di sincronizzazione che permettono di intervenire sulla sequenza secondo la quale avverranno determinati eventi. Ogni sistema concorrente implementa e mette a disposizione le proprie primitive, ma nonostante ciò i sistemi si rifanno ad una base teorica comune. Per questo è possibile creare una panoramica d'insieme.

Le più comuni vie di comunicazioni interprocessuali sono:

• Mutex: variabili binarie che permettono di gestire l'accesso ad una risorsa condivisa mediante accesso esclusivo di uno dei contendenti. Le operazioni di blocco (in termini semplicistici richiesta di accesso alla risorsa condivisa) e sblocco (rilascio della risorsa) sono atomiche.

• Semafori n-ari: variabili n-arie che possono essere incrementate e decrementate. Il processo che decrementa il semaforo si bloccherà appena raggiunto lo zero della variabile. Un processo che incrementa il semaforo invece risveglia tutti i processi che si erano bloccati in fase di decremento. Questa è una delle primitive base che consentono la sincronizzazione. Le operazioni di incremento, decremento e controllo del semaforo sono atomiche.

• Variabili di tipo condizione: conosciute anche come Condition Variables, sono variabili con associate due primitive: wait (aspetta) e signal (segnala, risveglia). Una procedura che richiama la primitiva wait si pone in attesa indefinita, una procedura che richiama la primitiva signal ne risveglia una in attesa su wait. Anche in questo caso le operazioni sono atomiche.

• Scambio di messaggi: due procedure, send (invia) e receive (ricevi), permettono a due processi di scambiarsi messaggi. Lo scambio di messaggi è solitamente usato in sistemi paralleli.

• Barriere: talvolta le applicazioni sono divise in fasi con la regola che nessun processo può proseguire se prima tutti i suoi simili non sono pronti a farlo. Le barriere implementano questo concetto: un processo che ha terminato la sua fase chiama una primitiva barrier e si blocca. Quando tutti i processi coinvolti hanno terminato il loro stadio di esecuzione invocando anch'essi la primitiva barrier, il sistema li sblocca tutti permettendo di passare ad uno stadio successivo.

Il concetto di atomicità nei sistemi concorrenti ha due fondamentali caratteristiche:

• La sua esecuzione non può essere prelazionata: il blocco e lo sblocco di un mutex non possono essere interrotti durante la loro esecuzione.
• La sua esecuzione è unica: non può avvenire che contemporaneamente due processi riescano a bloccare lo stesso mutex. Nei sistemi uniprocessore questa affermazione è una conseguenza della precedente poiché il concetto di "contemporaneità" è solo virtuale.

È evidente che tutte le primitive di comunicazione e sincronizzazione intraprocesso debbano rispettare questa condizione di atomicità.

Problemi classici

Esiste una serie di problemi classici nella programmazione concorrente. Essi vengono utilizzati per dimostrare l'efficienza di determinate teorie od algoritmi e forniscono una base comune per potere effettuare dei paragoni. Tra quelli più famosi si elencano:

• Produttore e Consumatore: anche conosciuto come problema del buffer a capienza limitata (bounded buffer problem). Un insieme di processi detti produttori producono dati per inserirli in un buffer di dimensioni finite mentre un altro insieme, i consumatori, estrae dati da questo buffer rappresentante la risorsa condivisa. Una programmazione concorrente ideale prevede un accesso esclusivo al buffer e arbitra correttamente il comportamento dei produttori quando il buffer è pieno e dei consumatori quando il buffer è vuoto.

• Lettori e scrittori: modella l'accesso a basi di dati. Su una base di dati agiscono scrittori, che ne modificano il contenuto, e lettori che ne recuperano il contenuto. Una corretta programmazione concorrente prevede l'accesso di un solo scrittore in fase di modifica (e di nessun lettore onde evitare inconsistenza) mentre l'accesso di tanti lettori è possibile a patto che non ci siano scrittori attivi contemporaneamente.

• Filosofi a cena: formulato da Edsger Dijkstra come dining philosophers problem. Alcuni filosofi (5 nel testo originale) sono seduti a tavola di fronte al loro piatto ed a due forchette (condivise con i loro vicini). I filosofi alternano momenti durante i quali meditare e momenti durante i quali mangiare. Per mangiare devono prendere le due forchette accanto al loro piatto e mangiare mentre durante la meditazione devono tenere le forchette sul tavolo. Risulta evidente che il numero di forchette impedisce a tutti i filosofi di mangiare contemporaneamente quindi una corretta programmazione concorrente deve essere in grado di far mangiare alternativamente tutti i filosofi evitando che qualcuno in particolare soffra la fame ed evitando che si verifichino stalli in fase di "acquisizione delle forchette".

• Barbiere che dorme: un barbiere possiede un negozio con una sola sedia da lavoro e un certo numero limitato di posti per attendere. Se non ci sono clienti il barbiere dorme. All'arrivo del primo cliente il barbiere si sveglia ed inizia a servirlo. Se dovessero sopraggiungere clienti durante il periodo di attività del barbiere, essi si mettono in attesa sui posti disponibili. Al termine dei posti di attesa, un ulteriore cliente viene scartato. Questa problematica è molto vicina al sistema di funzionamento degli helpdesk informatizzati dove l'operatore serve, uno per volta, tutti i clienti in coda oppure attende, senza effettuare alcuna operazione in particolare, l'arrivo di nuove chiamate. Una corretta programmazione concorrente deve far "dormire" il barbiere in assenza di clienti, attivare il barbiere sul primo cliente al suo arrivo e mettere in coda tutti i successivi clienti tenendoli inattivi.

  
  Fonte: http://it.wikipedia.org/wiki/Programmazione_concorrente

Installare Java sull'ultima versione di Ubuntu e' un'operazione  davvero semplice.

Java rappresenta ovviamente una componente fondamentale da installare su ogni sistema operativo ed anche Ubuntu necessita delle librerie necessarie per il corretto funzionamento di applet e programmi che vedono sfruttare le pontezialità del linguaggio di Oracle.

Per installare questo indispensabile componente, i passi da seguire sono i seguenti:

sudo add-apt-repository "deb http://archive.canonical.com/ natty partner"

sudo apt-get update

sudo apt-get install sun-java6-jre sun-java6-jdk sun-java6-plugin sun-java6-fonts

Finito!

Per controllare la versione di java installata è possibile lanciare il seguente comando:

java -version

Subversion (noto anche come svn, che è il nome del suo client a riga di comando) è un sistema di controllo versione progettato da CollabNet Inc. con lo scopo di essere il naturale successore di CVS, oramai considerato superato.

Caratteristiche

La versione 1.0 di Subversion (rilasciata il 23 febbraio 2004) offre le seguenti caratteristiche:

Comprende gran parte delle caratteristiche di CVS.

Le directory, i cambi di nome, e i metadati dei file sono sotto controllo versione.

Le commit sono vere transazioni atomiche. Una commit interrotta non lascia il repository in uno stato di incoerenza

Come server centralizzato si può usare il server Web Apache, tramite il protocollo WebDAV/DeltaV, oppure un server indipendente che usa un protocollo personalizzato basato su TCP/IP.

Il branching e il tagging sono operazioni veloci, che richiedono un tempo indipendente dalla dimensione dei dati.

Il progetto è nativamente client/server, ed è basato su una libreria stratificata.

Il protocollo client/server invia solo le differenze in entrambe le direzioni, e quindi i costi di comunicazione sono proporzionali alla dimensione delle modifiche, non alla dimensione dei dati.

I file binari sono gestiti efficientemente.

L'output dei comandi è analizzabile da un programma esterno, e viene fornito un log opzionale in XML.

La licenza è Open Source, simile a quella di Apache.

La versione 1.1 ha aggiunto le seguenti caratteristiche, fra le altre:

I messaggi dei programmi sono internazionalizzati.

I link simbolici sono sotto controllo versione.

Viene supportato un nuovo formato opzionale del repository, FSFS, che non fa uso di un gestore di database, ma memorizza le revisioni direttamente nel file system.

La versione 1.2 (rilasciata nel maggio 2005) ha aggiunto le seguenti caratteristiche:

Lock dei file per i file inconciliabili

Completo autoversionamento WebDAV

 Software correlato

I Client

Kdesvn è un client GUI per Linux (link).

RapidSVN è un client GUI per Microsoft Windows o Linux, scritto in C++ usando il framework wxWidgets (link).

eSvn è un client basato su Qt (link).

JSVN è un client basato su Java Swing (link).

TortoiseSVN è un'estensione della shell di Microsoft Windows (link).

svnX è un client GUI per Mac OS X (link).

AnkhSVN è addin per Microsoft Visual Studio .NET. Permette di eseguire le più comuni operazioni di Subversion direttamente dall'interno dell'IDE VS.NET.

Versions è un nuovo client per Mac OS X, dotato di un'interfaccia coerente con il Sistema Operativo Apple (link).

Le alternative

Ci sono molti altri sistemi di controllo versione, alcuni dei quali mirano a soddisfare gli stessi obiettivi di Subversion. Oltre al già citato CVS, che è il predecessore di Subversion, meritano una citazione anche git, creato da Linus Torvalds, e Mercurial (link), scelto da Google per affiancare SVN in Google Code.

 Altri progetti interessanti

Il progetto open source Trac integra Subversion, un issue tracker, e la funzionalità Wiki in una sola interfaccia-utente basata su Web.

Il progetto open source Subclipse integra Subversion in Eclipse.

Il progetto open source SVK è un sistema di controllo versione decentralizzato scritto in Perl, che permette di operare senza connessione a Internet e fornisce algoritmi avanzati per la riconciliazione (merging).

Il progetto open source JavaSVN è una libreria per client di Subversion scritta interamente in Java.

Fonte: http://it.wikipedia.org/wiki/Subversion

Oramai non c’è utente che non conosca Angry Birds e sono sempre meno coloro che non riescono a fare a meno dell’Angry Birds mania passando ore ed ora a superare ogni livello proposto dal team di Rovio, migliorando il proprio score. Dopo essere esploso sui device Android e successivamente anche su quelli Apple, ora Angry Birds è disponibile gratuitamente anche per PC.

Non avrete sicuramente la possibilità di giocare in modalità touch-screen ma la sensibilità, la precisione e soprattutto il divertimento sono assicurati al cento per cento. Una nota positiva anche per gli utenti Linux è che il gioco è perfettamente integrabile in Wine e potrete trascorrere il vostro tempo libero con gli uccellini arrabbiati per recuperare le uova sparse nei vari mondi.

Naturalmente gli utenti Windows (solo Windows 7) non avranno problemi ad installare Angry Birds in quanto basterà scaricare il gioco e doppio cliccare sul file .exe per iniziare il processo di installazio. Buon divertimento!

Download Angry Birds per PC

Fonte: http://www.chimerarevo.com/2011/04/22/angry-birds-arriva-anche-sui-pc-ed-e-gratis-funziona-anche-su-linux/