(MOVED) Partizioni più grandi di 2TB, MBR, GPT e parted

Si illustra come effettuare una partizione più grande di 2GB su sistemi linux, fornendo anche una panoramica più generale delle problematiche associate

Questo post è stato spostato su:

http://freeehowto.wordpress.com/2010/05/19/partizioni-piu-grandi-di-2tb-mbr-gpt-e-parted/

Gestione dei profili in Gentoo Linux

Il sistema portage (il package manager di Gentoo Linux) prevede la possibilità per alcuni package di avere diverse versioni installate; le configurazioni standard però prevedono l'uso di una ed una sola delle versioni disponibili di un determinato package. La scelta di quale versione di questi package deve essere utilizzato a livello di sistema può essere effettuata mediante il comando eselect. Tale comando deve essere installato mediante il package app-admin/eselect.

I moduli gestibili da eselect si possono vedere eseguendo il comando stesso senza ulteriori parametri; un help di ogni singolo modulo è ottenibile dando eselect . Tipicamente tutti i moduli contengono gli extra comandi

• list: per vedere i possibili profili
• show: per vedere il contenuto dei profili correnti
• set : per impostare il profilo specifico, dove è il numero del profilo voluto ottenibile dal comando list

I moduli di eselect più importanti sono sicuramnte:

• profile: permette di impostare il profilo generale del sistema, ovvero tutto l'insieme dei files di configurazione di base della distribuzione. I files dei profili sono in /usr/portage/profiles
• kernel: Permette di impostare la versione dei sorgenti del kernel da utilizzare
• python: permette di selezionare la versione di python di default; bisogna infatti ricordare che il linguaggio di script python è una componente fondamentale della distribuzione

Un modulo anch'esso molto importante, anche se un po' particolare, è il modulo rc. Questo permette la gestione dei runlevel, permette di visualizzare gli script di init presenti sul sistema, vedere i runlevel esistenti, i processi dei singoli runlevel ed il loro stato 

Altro modulo di sicura importanza è il modulo news che permette la lettura delle news di gentoo che vengono tipicamente inserite durante gli aggiornamenti dei pacchetti con il portage.


Una nota particolare merita la gestione dei profili del gcc. Questa non avviene (alla data di questo post) mediante il comando eselect, ma attraverso l'apposito comando gcc-config

(MOVED) Valorizzazioni di errno

Vengono elencate e sinteticamente descritte le valorizzazioni di "errno" in un sistema Linux e con linguaggio di sviluppo C/C++

Questo post è stato spostato su:

http://freeehowto.wordpress.com/2010/05/31/valorizzazioni-di-errno-in-cc/

Uso del comando ulimit in Linux

Il comando ulimit è un comando interno della shell Bash che permette di controllare e limitare l'accesso a risorse globali di sistema da parte della shell nella quale lo si esegue e da parte dei processi derivati.

Per vedere tutti i limiti impostati si può utilizzare il comando

ulimit -a

I limiti impostabili in Linux (kernel 2.6.30) sono i seguenti:

• ulimit -c -> core file size in blocchi: limite massimo delle dimensioni del file di core (file generato dal sistema al crash di un eseguibile). Solitamente posto a 0 (nessun file di core può essere generato) può essere utile impostarlo a unlimited per in caso si voglia effettuare un debug postmortem di un'applicazione. Utile soprattutto durante la fase di sviluppo
  
• ulimit -d -> data segment size in kB: dimensione del segmento dati. Generalmente posto a unlimited; può essere utile ridurlo durante la fase di sviluppo per simulare il funzionamento di un applicazione in un ambiente con poca memoria
• ulimit -e -> scheduling priority: la priorità di base del processo (sostanzialmente il nice)
• ulimit -f -> max file size in blocchi: massima dimensione dei file scrivibili dal processo. Solitamente posto a unlimited. Se il processo tenta di scrivere un file di dimensione maggiore di quelle permesse viene terminato con un segnale del tipo SIGXFSZ.
  
• ulimit -i -> max pending signals: numero massimo di segnali in coda per il processo. Solitamente posto ad un valore di circa 30000 (2^15 - qualcosa). 
• ulimit -l -> max locked memory in kB: Generalmente impostato a qulche decina (tra 32 e 64) imposta la dimensione massima della memoria che può essere bloccata in ram (non paginabile su disco). Aumentare questo valore può rendere inefficiente la gestione della memoria da parte del S.O. tuttavia può essere necessario in particolari applicazioni real-time dove l'accesso al disco può risultare incompatibile con le necessità del real-time.
  
• ulimit -m -> max memory size in kB: quantità massima di memoria fisica utilizzabile da un processo. Generalmente impostata a unlimited può essere utilile limitarla per alcuni processi che devono funzionare in modo non assistito (batch) e che debbono avere ridotti impatti sul sistema complessivo.
• ulimit -n -> max open file: numero massimo di file aperti contemporaneamente.
• ulimit -p -> pipe size in unità di 512 byte: dimensione della pipe.
• ulimit -q -> max POSIX message queue size in byte: dimensione massima della ram utilizzata dalle message queue POSIX. Generalmente impostata a 800 kB può essere necessario aumentarla per processi che impiegano massicciamente questi elementi del sistema. Se si eccede il limite la richiesta di creazione della coda mq_open fallisce con errore ENOMEM
• ulimit -r -> real-time priority
• ulimit -s -> max stack size in kB: dimensione massima dello stack. Generalmente impostata a 8MB
• ulimit -t -> max cpu time in secondi: massimo tempo di cpu utilizzabile dal processo, utilizzato il quale il processo viene terminato con un segnale del tipo SIGXCPU. Generalmente impostato a unlimited può essere ridotto se si vuole che un processo possa utilizzare la cpu per un periodo massimo di tempo
• ulimit -u -> max user process: numero massiomo di processi che un singolo utente può avere attivi contemporaneamente. Contrariamente agli altri valori gestibili con ulimit questo limite non agisce a livello di permesso ma di utente. Una chiamata a fork dopo aver raggiunto questo limite genera un errore del tipo EAGAIN
• ulimit -v -> max virtual memory in kB: quantità massima di memoria virtuale utilizzabile dal processo. Generalmente posta a unlimited. Se si eccede il limite un'uteriore richiesta di allocazione di memoria fallisce con ENOMEM
• ulimit -x -> max file locks

Sono impostabili due tipi di limiti:

• I limiti Hard sono impostabili esclusivamente da un utente con i privilegi di root e si impostano aggiungendo il flag -H alla linea di comando (e.g. ulimit -Hl per impostare la massima quantità di memoria bloccabile in ram; ulimit -Ha per visualizzarli tutti)
• I limiti Soft, impostabili con i comandi visti sopra possono esere modificati da qualsiasi utente per i propri processi nei limiti imposti dai parametri Hard.

Posix Message Queue Vs. IPC SYSV messages

Esistono tre modi principali in Linux per scambiare dei messaggi tra due distinti processi.

1. Usare dei socket IP, ma non è argomento di questo post
2. Le POSIX message queues 
3. Le Message queues System V interproces comunication system 

Entrambi i sistemi presi in considerazione da questo post permettono lo scambio di messaggi tra diversi processi attraverso strutture implementate a livello di kernel (per le MQ POSIX a aprtire dalla versione 2.6.6), ma presentano anche sostanziali differenze.

Le MQ POSIX nascono in tempi più recenti, sono considerate più attuali, sono meglio mantenute dagli sviluppatori del kernel, offrono maggiore portabilità verso altri sistemi Unix e non. Al contrario le SYSV IPC sono più datate, poco o niente mantenute (alcuni dicono a rischio scomparsa) e di difficile o nulla portabilità.

Le MQ POSIX presentano un ottima integrazione nei file system linux. Vengono identificate attraverso un nomefile (qualche cosa del tipo /nomecoda); possono essere visualizzate e manipolate attraverso un file system standar (previamente montato con il comando mount -t mqueue none /nome_nelladirectory); possono essere configurate attraverso il file system standard di linux /proc/sys/fs/mqueue. Inoltre sotto Linux un message queue descriptor è a tutti gli effetti un file descriptor e dunque monitorabile con funzioni quali select o poll. Le MQ SYSV seguono regole poco conformi agli standard Linux. Vengono identificate attraverso un id numerico; vengono visualizzate e manipolate attraverso specifici comandi (ipcs, ipcrm); il descriptor ottenuto non è un file descriptor e dunque va manipolato con le funzioni specifice; alcuni parametri di configurazione possono essere manipolati dal file system /proc/sys/kernel.

A livello prestazionale POSIX e SYSV sembrano equivalersi, è oportuno tenere presente che sempre più le API SYSV sono e saranno implementate come layer aggiuntivo sulle API POSIX e dunque con prestazioni certamente non migliori di queste ultime. Le MQ POSIX nascono pensando al real-time e sono quindi meglio strutturate per compiti di questo tipo.

Per contro essendo ancora relativamente recenti le MQ POSIX non godono ancora della diffusione della quale godono le SYSV IPC, ad esmpio le POSIX MQ non sono ancora gesstite da linguaggi quali il php

Il costrutto "union" in C#

Il linguaggio C ci fornisce il comodo costrutto union utile per esempio per convertire variabili o strutture di tipo diverso ma di eguale dimensione.

In C# il costrutto union non esiste, esistono al suo posto le classi StructLayoutAttribute e FieldOffsetAttribute entrambe appartenneti al namespace System.Runtime.InteropServices. La StructLayoutAttribute può essere applicata a dei costrutti di tipo class o struct mentre la FieldOffsetAttribute viene applicata ai membri della classe o struttura.

Supponendo di voler convertire un Int16 (intero a 16 bit) in due byte (8 bit) e viceversa possiamo utilizzare il seguente costrutto:

    [StructLayout(LayoutKind.Explicit, Size = 2)]
    struct U16B
    {
        [FieldOffset(0)]
        public byte B1;
        [FieldOffset(1)]
        public byte B2;
        [FieldOffset(0)]
        public Int16 I16;
    }

Questo crea una struttura con i cambi I16 e B1, B2 che condividono gli stessi 2 byte di memoria in maniera del tutto analoga alle union del C.

Anche l'uso è del tutto analogo.

Per convertire l'intero nei due byte che lo compongono si usa il seguente codice:

Int16 a = 12345;

byte[] b = new byte[2];

U16B u = new U16B();

u.I16 = a;

b[1] = u.B2;
b[0] = u.B1;

La documentazione di riferimento si può trovare qui:

• StructLayoutAttribute 
• FieldOffsetAttribute
  

Scrivere file binari e di testo in c#

Per scrivere un file binario seguire il seguente esempio:

FileStream fs = File.Create("C:\\Users\\pippo\\test.dat");

    BinaryWriter bw = new BinaryWriter(fs);

        bw.Write(variabileDaScrivere);

    bw.Close();

fs.Close();

Pe scrivere un file di testo seguire il seguente esempio:

TextWriter tw = new StreamWriter("C:\\Users\\pippo\\test.txt");
    tw.WriteLine("Testo da scrivere...");
tw.Close();

Qui si può trovare la documentazione di riferimento:

• FileStream 
• BinaryWriter 
• TextWriter
  

(MOVED) Impostazione di un controllo di una finestra da un thread separato in C#

Si descrive come agire su un controllo del .NET Framework da un thread diverso da quello del controllo stesso utilizzando il linguaggio C#

Questo post è stato spostato all'URL

http://freeehowto.wordpress.com/2010/07/13/impostazione-di-un-controllo-di-una-finestra-da-un-thread-separato-in-c/

(MOVED) Creazione di thread in C#

Si illustra come creare un thread in C#

Questo post è stato spostato su:


http://freeehowto.wordpress.com/2010/07/13/creazione-di-thread-in-c/

Trovare l'handle della finestra in applicazioni WPF

Con l'introduzione del .net framework 3.5 e delle applicazioni basate su WPF (Windows Presentation Foundation Classes) Microsoft ha rivoluzionato massicciamente il concetto di finestra. Uno dei parametri che ne ha fatto le spese è il concetto di handle della finestra.

Nelle applicazioni di tipo "Windows Form" (.NET 2.0) ottenere il valore dell'handle di una finestra era alquanto semplice in quanto era sufficente leggere la proprietà hWnd della nostra finestra:

Int i = Window1.hWnd;

Più difficile recuperare il valore in una applicazione WPF dove la proprietà .hWnd non esiste più.
Ci viene in aiuto la classe WindowInteropHelper appartenente al namespace System.Windows.Interop. Adeguata documentazione si può reperire all'URL

http://msdn.microsoft.com/it-it/library/system.windows.interop.windowinterophelper.aspx 

L'uso è molto semplice. E' sufficente creare un'istanza della classe passando come parametro del costruttore la finestra di nostro interesse (oggetto di tipo System.Windows.Window). L'handle che ci interessa è una proprietà dell'oggetto così ottenuto.

WindowInteropHelper wih = new WindowInteropHelper(Application.Current.MainWindow);
Int hWnd = wih.Handle;