AGHBBS Internet Jobs

AGHBBs  Photos

 
AGHBBs Announcing Service
AGHBBs Holiday Accomodation and more...
The Joint Development Program gives You the opportunity to help ensure a solid Enjoy that meets the needs of You and Your friends.

AGH PHOTOS e' il dipartimento di AGH Group MODELS, E.Book Se sei un modello professionista o vorresti semplicemente entrare a farne parte, potrai accedere al servizio.
Il tuo spazio su struttura base e' gratuito, con tecnologia flash.
Il tuo book professionale con spazio web a quotazioni di sicuro interesse, perche' sviluppati da professionisti del settore che operano in convenzione con AGHGroup Usa .
Richiedi informazioni oggi stesso, il tuo referente di zona e':
Edward edward-models@aghbbs.cjb.net

AGH GROUP Per la sezione Italiana ricerca modelli, fotografi professionisti e non, musicisti mp3, dando spazio gratuito e possibilita' di inserire una propria scheda di presentazione. Per ulteriori informazioni clicca qui: recruiting@aghbbs.cjb.net
 

---

AGHBBs Digital Web Image Dictionary
AGHBBs Digital Video Dictionary
AGHBBs Univers File Format

AGHBBS Photos Services
AGHBBs Photos Group Assurballit Gazelle Hound Express e' una BBs che opera dal 1989. Dal 1990 offre Servizi di Free Information Server su Internet con Aree tematiche in vari campi. Da oggi e' possibile ottenere informazioni nel campo della fotografia digitale e link ad Agenzie collegate oltreoceano.
Il ns. service propone articoli ed una ricerca mirata per gli Utenti registrati in AGHBBs Photograph, spedizione via mailing all'indirizzo del richiedente. In questa sessione parliamo di:

Corel PHOTO-PAINT®
Using a Clip Mask to Paint Effects in
Corel PHOTO-PAINT®
By Clifford Anderson

Our purpose here will be to introduce the Clip Mask in Corel PHOTO-PAINT®, and then move on to a technique that allows the user to paint effects found in the Effects menu onto an image. Before we begin, let’s get our workspace set up: Set Paint wells in the Status bar to the default (Paint=Black, Paper=White, Fill=Black). Open the following Docker Windows: Objects, Channels, Artistic Media and Brush Settings. Create a new canvas, white background, 500 x 400 pixels. To start, let’s do a brief run-through of what a clip mask can do for us. 1) With our new canvas, add a layer (to quickly add a layer, click the New Object button at the foot of the Objects Docker window). 2) Select the Circle Mask Tool from the Mask Flyout in the Toolbox (or, press J on the keyboard). 3) From the Tool Property Bar, choose Fixed for the mask style, Width=250, Height=250, Feather=0, Anti-alias=on. 4) Place a circle mask, centered onto the new object (the mask can be aligned perfectly by selecting the Mask Transform Tool, or M", and choosing Align from the Mask menu). 5) Select Edit, Fill and accept Black as the Fill color. Remove the mask (CTRL + SHIFT + R). 6) In the Objects Docker window, right-click the text entitled Object 1, and choose duplicate selected (CTRL + D). 7) Now, with Object 2 selected, go to Effects, Blur, Gaussian Blur. Set the Radius to 20.0 pixels. Click OK. 8) Again, from the Effects menu, go to Creative, Scatter.
Set the Horizontal and Vertical controls to 75. Commit the effect.
9) From the Objects Docker window, right-click the thumbnail image (not the text) of Object 2. Select Create Clip Mask, From Object Transparency (there are other options we will cover below). This action adds an additional thumbnail to the right of a + sign that appears to be the inverse of the object. This is the Clip Mask proper.
The black marks 0% transparency, the white, 100%.
Let’s add another level of transparency to our clip mask and witness the effect. 10) Press R on the keyboard (for the Rectangle Mask Tool). Ensure the Clip Mask is selected (the thumbnail will be bound in red). Draw a rectangle that encompasses the right-hand half of the entire canvas.

---

FAULT TOLERANCE di Riccardo Corsanici

Quanto è affidabile il vostro sistema?
In particolare: la vostra azienda è in grado di tollerare un’interruzione del sistema informativo?
Se le necessità operative del vostro core business sono ribadite sotto forma dei pugni del capo che battono sul vostro tavolo, allora è giunto il momento confrontarsi con una domanda fondamentale:
Sei affidabile?
Fault Tolerance ed alta affidabilità a confronto
di Riccardo Corsanici
L’affidabilità è un aspetto determinante nei sistemi informativi. Se la vostra partita a Quake si interrompe e di colpo vi ritrovate a fissare un puntatore grande come un asso di bastoni, il peggio che può capitarvi è di dover riavviare il computer ed al limite dover reinstallare qualche driver di cui un automatismo ha fatto scempio, o che si è smarrito nei tortuosi meandri del registry.
Il "danno" che ne ricavereste risulta più che trascurabile.
Immaginate ora l’impatto di un "crash" in un computer di dimensioni maggiori…
Supponete che tutti gli sportelli di check-in di un aeroporto siano collegati ad un sistema centrale contenente il database delle prenotazioni, della spedizione bagagli, dell’orario dei voli e d’altre informazioni fondamentali. Aggiungete code di passeggeri agli sportelli, operatrici sorridenti alla console ed un terribile brusio da refettorio ed otterrete un aeroporto in pieno orario "di punta".
Per completare il quadro supponete che il sistema centrale decida che è arrivato il momento di dividere un qualche valore per zero e si ritrovi con le pagine di memoria mescolate come le carte di un croupier: le console si piantano, le stampanti ammutoliscono.

Mentre il sistema esegue un accurato dump della memoria che tecnici preparatissimi studieranno per i prossimi tre mesi, il resto dell’aeroporto scopre di non poter aspettare: ci sono aerei sulle piste, nastri trasportatori che s’insinuano come serpenti fra i vari gate, orde di facchini, operatori, hostess che debbono imbrigliare il traffico umano e convogliarlo sui rispettivi airbus per affidarli alle cure di assistenti di volo e piloti che necessitano di un sistema informativo di coordinamento… Che sta ancora eseguendo il dump.
Quando, finalmente, quarantacinque minuti dopo il sistema centrale torna ad essere operativo, il danno economico causato dal blocco delle console può essere tale da richiedere le dimissioni dell’amministratore delegato. Al di fuori delle ipotesi volutamente sovradimensionate, il fattore "affidabilità" può essere trovato quasi sempre ai primi posti nella scala delle priorità di un sistema informativo aziendale di medio ed alto livello. Si tratta di un problema così sentito che sforzi notevoli in questa direzione sono stati compiuti fin dagli albori dell’informatica.
Infatti, i "maxicomputer" (sistemi incredibilmente voluminosi e per gli standard dell’epoca performanti), dovendo sopportare il carico di centinaia di utenti, sono stati da sempre progettati con l’intento di fornire ambienti affidabili. I progettisti di maxicomputer hanno lavorato davvero molto bene, al punto che, ancora oggi, parlando di "affidabilità in ambiente enterprise", viene subito alla mente l’idea del mainframe. 

Un esempio di fault tolerance:  il mainframe

Avendo considerato l’esempio di un crash si potrebbe confondere il significato di "affidabilità" con quello di "stabilità". In realtà occorre distinguere nettamente i due termini. Un sistema "stabile" dovrebbe, in condizioni di normale operatività, garantire un’erogazione "continua" del servizio senza produrre errori bloccanti; questoil ché , tradotto in termini pratici, equivale ad affermare che dovrebbe essere in grado di amministrare le risorse in modo ottimale, ad esempio rendendo disponibili per le applicazioni aree di memoria non più utilizzate e così via, ed essere in grado di rimanere attivo per lunghi periodi senza costringere gli amministratori ad eseguire periodicamente dei reboot di "assestamento".

L’affidabilità è un aspetto completamente diverso. Che cosa succede, infatti, quando eventi esterni al sistema operativo ne compromettono la stabilità? Consideriamo un caso piuttosto semplice: cosa accade n’è daella stabilità di un sistema operativo se, inciampando sul cavo, lo priviamo brutalmente dell’alimentazione?

Il livello di affidabilità di un sistema si misura quindi nella sua capacità di preservare la stabilità anche in condizioni di operatività anormali.

Nel caso del cavo potrebbe essere sufficiente dotare il computer di due alimentatori, ed assicurarsi di connetterli entrambi alla rete elettrica per considerarsi al sicuro da passi falsi e scope assassine… E se per un guasto alla centrale venisse a mancare la corrente? Un buon gruppo di continuità dovrebbe permettere l’esecuzione di uno shutdown di emergenza in modo da salvaguardare i dati. Tuttavia, se il nostro sistema dovesse restare attivo a tutti i costi, non avreste altra scelta che predisporre un generatore.

Tutti questi accorgimenti "alzerebbero" il livello di affidabilità del vostro sistema, ma sareste ancora lontani da un livello "accettabile". Vi sono, infatti, innumerevoli punti di guasto che non vengono gestiti e potrebbero causare un’interruzione del servizio: schede di rete, processori, memorie, dischi... ed in pratica, ogni componente del vostro sistema potrebbe guastarsi, ed il solo modo per preservarne la stabilità è di ridondare tutti i possibili punti di guasto: , usando un il mainframe ((Figura 1).

L’affidabilità in ambiente mainframe è garantita dalla ridondanza assoluta di tutti i punti di guasto, ed è una formula che funziona egregiamente, come potranno confermare numerose aziende che tuttora si affidano a questa piattaforma.

C’è naturalmente un aspetto meno gradevole, in un panorama altrimenti roseo: il prezzo. L’investimento necessario per dotare la propria azienda di un mainframe è infatti piuttosto ingente e non si prefigura assolutamente come una spesa alla portata di tutti. Per contro nelle circostanze in cui la spesa non costituisce un problema, il mainframe è il massimo rappresentante di quei sistemi definiti fault tolerance, ovvero in grado di offrire una certa "resistenza" ai guasti. Non ci si lasci ingannare dall’idea che l’architettura mainframe sia un retaggio di un’era informatica comparabile all’età del bronzo: nel corso degli anni quest’ambiente ha saputo mantenersi "al passo", introducendo il supporto per nuovi protocolli (come ad esempio il TCP/IP) o rimovendo del tutto funzionalità obsolete ed addirittura proponendosi come piattaforma orientata alla struttura client-server, normalmente egemonia esclusiva dei "mini" computer.

L’IBM ha recentemente messo a listino mainframe con sistema operativo basato su Linux… E questo è un segno tangente della "modernità" di questi sistemi (Figura 2).

Vi sono altri aspetti, oltre a quello economico, che devono essere posti sul piatto della bilancia: il primo è strettamente pratico: acquistare un mainframe significa scegliere di dipendere da un fornitore unico per l’assistenza tecnica, la manutenzione, la formazione, le componenti di ricambio ed in genere per tutti i servizi correlati alla gestione di un sistema di grandi dimensioni. Magari quest’ipotesi potrebbe apparire allettante: avere un solo interlocutore invece di tanti fornitori diversi… d'altronde significa anche accettare un rapporto di dipendenza nei confronti del proprio fornitore, soluzione che a volte potrebbe non essere ideale.
Inoltre (caso Linux a parte), i mainframe hanno solitamente un sistema operativo scritto appositamente per l’hardware da gestire, e quindi drasticamente proprietario: questo potrebbe significare dover sviluppare autonomamente il software di cui si ha bisogno (applicazioni gestionali, interfacce verso database etcc.) oppure dover nuovamente dipendere dal medesimo fornitore, sottolineando ancor più il rapporto di dipendenza.

Limiti dell’architettura fault tolerance

In che termini viene gestita la ridondanza? Come può il semplice fatto di avere tre punti distinti di alimentazione invece che uno solo rendere il sistema più affidabile?

Perché si possa trarre un vantaggio reale dalla ridondanza dei dispositivi, è necessario che sia il sistema operativo stesso a gestirla: esso dovrà avere assoluto controllo su tutte le componenti, ed essere in grado di isolare quelle guaste per "rimpiazzarle" dinamicamente con quelle di "riserva".

In un sistema multiprocessore, deve essere possibile "spegnere" una CPU guasta senza disturbare l’elaborazione nel suo insieme, e quest’azione deve essere compiuta dal sistema operativo, senza richiesta di interazione con l’amministratore.
E questo, in effetti, è proprio quello che succede.
Utilizzando SNMP od altri protocolli analoghi, il sistema operativo è in grado non solo di diagnosticare un malfunzionamento ed isolare il dispositivo, ma può anche allertare direttamente il personale di competenza presso l’assistenza tecnica. Così potreste veder arrivare un tecnico con una scheda sotto il braccio che viene a sostituire una componente senza che nessuno sapesse neanche del guasto.

Cosa accadrebbe quindi se il "fault" avvenisse a livello di sistema operativo? Siamo arrivati a considerare l’unico evento che un sistema fault tolerance, per definizione, non è in grado di gestire: un crash a livello di sistema rimane un crash, e la continuità del servizio viene compromessa.
Deve essere detto per completezza che un blocco totale è un evento estremamente raro nella storia di un sistema fault tolerance, perché la stabilità è una prerogativa del sistema operativo, e la maggior parte dei motivi "esterni" di instabilità viene gestita efficacemente.

Un esempio di alta affidabilità:  il cluster

Lo scopo di un’architettura fault tolerance è quella di "tollerare" il guasto: di subirlo e preservare comunque l’agibilità del sistema. In un mainframe non vi è (virtualmente) interruzione del servizio: . Uuna componente si rompe e viene esclusa. Le necessarie operazioni di recovery vengono eseguite e l’utente avverte solo un "rallentamento" del sistema.
Il concetto di "alta affidabilità" si adatta invece a soluzioni che partono dal presupposto esattamente contrario: come ridurre al minimo indispensabile l’interruzione del servizio in caso di "fault" del sistema operativo.
Confrontando le caratteristiche principali delle due tecnologie: il rapporto fra prezzo e prestazioni svolge sicuramente a favore degli ambienti in alta affidabilità, e dopo tutto lo scopo di queste architetture è proprio fornire sistemi affidabili a fronte di investimenti ragionevoli. Ci sono comunque da considerare anche le necessità operative, che in un panorama fault tolerance vengono senza dubbio privilegiate.

Nelle architetture denominate "HA" (ovvero High Availability: alta affidabilità) la "gestione" dei guasti è posta all’esterno del sistema operativo, che può quindi essere considerato alla stregua degli altri punti di guasto, e conseguentemente può essere ridondato.

È bene chiarire la diversità concettuale posta alla base dei due ambienti: i sistemi fault tolerance tendono ad essere centralizzati, e sono dei maxicomputer gestiti da un sistema operativo.

Nell’architettura HA non si fa riferimento ad un computer, ma ad un sistema distribuito in grado di gestire una serie di problematiche hardware e software e garantire un buon livello di affidabilità. Parliamo quindi non di un sistema unico, ma di due o più computer concorrenti. In quest’ottica la gestione dei punti di guasto viene necessariamente decentralizzata:

Ridondanza sui dischi
I dispositivi per la memorizzazione dei dati "sensibili", quindi di database ed applicazioni vitali, vengono posti "esternamente" ai sistemi coinvolti, in genere su uno o più disk array ai quali i computer concorrenti sono connessi tramite cavi SCSI o fibre ottiche.
La ridondanza è realizzata applicando un appropriato livello RAID che garantisca le gestione di errori hardware a livello di array, e quindi senza coinvolgere nessuno dei sistemi operativi coinvolti.
Ridondanza sul sistema operativo
Ogni computer è gestito singolarmente dal sistema operativo locale. Di questi, uno sarà probabilmente il sistema di "esercizio" e gli altri di "ridondanza". Ancora una volta la gestione di questo punto di guasto è esterna rispetto al sistema operativo: se il nodo principale subisce un guasto irreversibile, uno degli altri sistemi lo rimpiazzerà.
Ridondanza sugli altri dispositivi
Ogni computer coinvolto è un sistema indipendente a tutti gli effetti, di conseguenza vi sarà un numero di schede di rete, CPU, controller, etc. direttamente proporzionale al numero dei sistemi coinvolti.
Malgrado le varie implementazioni di HA differiscano in modo anche sostanziale le une dalle altre, il concetto di disk array esterni e condivisi rimane il cuore dell’architettura, in quanto elimina il problema della duplicazione dei dati.
Supponendo di voler fare a meno di un disk array, è possibile mettere due sistemi in rete e configurarli in modo che uno sia il nodo di "esercizio" e l’altro di "standby". A questo punto un problema da risolvere sarebbe quello di mantenere allineati i sistemi di modo che lo "standby" presenti una situazione quanto più vicina possibile al nodo di esercizio.

Se il sistema fa uso di un database occorrerà ideare un meccanismo di propagazione delle transazioni in tempo reale. Un semplice export del nodo di esercizio ed import su quello di standby creerebbe un disallineamento di ventiquattro ore fra i sistemi ed a questo punto tanto varrebbe mantenere un solo computer con un accurato piano di backup.