[tutto]

Allora in pratica dovrei trasferire il datadir del MySQL e cioè /var/lib/mysql (dove si depositano i database) nella directory dove è impostata la quota e cioè /home

No, non devi spostare tutto il percorso, ma solo i singoli database.
Esempio: datadir = /var/lib/mysql; crei un utente MySQL pippo cui associ un database pluto. Ti ritroverai in /var/lib/mysql una directory pluto che contiene i files del database.
Chiudi MySQL, sposti la sola cartella pluto dove vuoi e la colleghi alla posizione originale con un link simbolico, poi riavvii MySQL.

Cosa che ho puntualmente fatto lunedì, e per il momento nessun inconveniente sul PC "vecchio"

Io non conosco quota quanto a configurazione. La mia idea era: posto che tu possa forzare a livello di OS una quota per un utente in un determinato file system, trasferisci al suo interno il database.
Il rischio è che il sistema operativo non realizzi la quota perché vede i files di proprietà dell'owner di MySQL e non dell'utente. Del resto utenze MySQL e Linux sono diverse anche se omonime. Quindi, se il problema è lì, devi fare qualcosa di più drastico: creare file system separati per ciascun utente, trasferire ogni DB in ogni file system come ho detto prima, e lasciare che sia lo spazio fisico il vero limite (a questo punto le quote sono implicite nel limite fisico del FS e quota manco serve).

Salve a tutti,

sto installando il nuovo PC, ISO "fresche di giornata"; ho messo in una partizione la versione amd64 ed in un'altra quella i386, ma mi è successa una cosa strana: in entrambi i casi, facendo tutto come al solito, includendo quindi il profilo desktop nelle scelte dell'installer, Debian ha sì installato il server X (che funziona) ma non Gnome e GDM (che pure sono nel corredo del primo DVD che ho usato tutte e due le volte), come se avesse autonomamente deciso che il PC non deve avere X avviato allo startup.
Non è un problema insormontabile visto che posso tranquillamente aggiungere il tutto a posteriori, ma vorrei capire su quali basi può aver preso una simile decisione. Ogni suggerimento è bene accetto.

Ti dirò: ieri ho provato più volte a fare l'installazione col RAID configurato; spesso si impallava nei punti più strani, ma dopo un accurato redesign delle partizioni alla fine ero riuscito a farlo partire. Solo che, al primo shutdown, mi dava errore a smontare due devices (quelli associati a swap ed a /home), ed al riavvio chiaramente partiva la ricostruzione del RAID.
Scommetto che mi sfugge qualcosa e che tutto l'ambaradan può e deve funzionare; purtroppo non ho più tempo da dedicare agli esperimenti, quindi nell'immediato ho preferito rinunciare e configurare il tutto alla vecchia maniera. Ora ho quindi più spazio a disposizione, ma meno garantito

Un modo c'è. Non so se lo trovi semplice, e nemmeno se sia il solo, ma dovrebbe funzionare.
Sul tuo MySQL avrai dei parametri (es. datadir) che impostano il path in cui collocare i database. Questo percorso è comune a tutti, quindi non dovresti potervi mettere limiti individuali, ma potresti aggirare l'ostacolo in questo modo.
Diciamo che hai l'utenza MySQL pippo a cui conferire il database pluto. Crei su MySQL utenza e database con i dovuti privilegi, poi lo fermi. Sposti la cartella del database in un file system con la quota per pippo attiva, crei un link simbolico per la posizione originale, infine riavvii MySQL. Così facendo il vincolo sugli spazi è "governato" dal sistema operativo.
Attenzione: il ragionamento fila se il database è MyISAM oppure InnoDB ma col parametro innodb_file_per_table attivo; diversamente MySQL collocherebbe i dati in spazi comuni, o comunque fuori dal tuo controllo.
Ricorda anche di eliminare il database test e tutti quelli che dovessero essere accessibili senza restrizioni, o gli utenti potrebbero scrivere anche lì, aggirando le soglie.

Sul vecchio PC ho una Nvidia 7600GS AGP (credo marca PNY); sul nuovo ho richiesto una 9600GT PCI-Express (marca Asus). Sto ancora completando le installazioni quindi non sono arrivato ancora ad installarne i drivers, ma non mi aspetto (e non mi auguro ) di avere problemi.

Lo spero anch'io

Quindi da quanto anche tu mi dici, ormai in generale sia ATI che Gforce non dovrebbero dare problemi.

Io sapevo che ATI era problematica sul 3D, mentre Nvidia non ha problemi se usato con i propri drivers. Forse oggi ATI ha ripianato il gap, meglio fare un controllo in più che rischiare una spesa a vuoto, soprattutto se intendi prendere un preassemblato e non farlo fare su misura.

Casualmente io vado a ritirare il mio nuovo proprio domattina
Personalmente ho optato per un quad core Q8200, perché in più sedi e da colleghi più esperti mi è stato assicurato che sotto Linux non vi sono problemi, arguisco a maggior ragione usando la versione amd64 come conto di fare. Nel tuo caso, la scelta a parità grossomodo di prezzo è fra un quad core ad una certa frequenza ed un dual core ad una più elevata, quindi suppongo che l'una o l'altra opzione convengano in funzione di quanto multitasking sei abituato a lavorare. Ma in prospettiva direi che sia meglio optare per un quad, benché presumo non convenga puntare sui top di gamma che, ancor oggi, costano davvero molto.
Circa la scheda video, ho sempre usato Nvidia e mai avuto problemi. Punto. Non saprei dirti con ATI ma certo una volta era ben diverso per la scheda canadese col pinguino, del che la Rete è satura di documentazione. Ho letto anch'io di rogne con Nvidia nel recente passato, ma erano localizzate ai chipset dei notebook, vulnerabili a livello hardware più che software; se vi sono novità negative, non ne sono granché informato.

En passant, non faccio nomi perché sarebbe pubblicità, ma la catena presso cui mi sono rivolto contempla anche assemblaggi per macchine destinate a Linux, con verifica del funzionamento sotto una distro di riferimento (credo uno dei tanti "dialetti" di Ubuntu), il che incrementa le probabilità di riuscito acquisto. Prendendo visione del loro sito potrai intuire se effettivamente ATI o Nvidia sono supportati ed in che misura.

Credo vada presa con le molle:

L'intuizione che stabilità e sicurezza aumentino andando dalla distribuzione instabile a quella stabile è errata. Infatti, se si verificano delle falle di sicurezza in qualche software, esse sono coperte quasi immediatamente in stable e unstable, mentre testing deve aspettare. Inoltre se qualche programma che è filtrato in testing viene a manifestare dei bachi, si determina spesso una situazione, a causa delle intricate dipendenze, tale che i bachi in testing resteranno finchè non verrà introdotta da unstable la nuova versione corretta.

può essere vero come logica di base, ma statisticamente quanti saranno i programmi un cui bug emerge solo in testing, rispetto a quelli che in toto compongono la unstable? Dovremmo ritenere che è peggio avere cento programmi certamente difettosi su ventimila, o quindicimila programmi potenzialmente difettosi su ventimila? Mi sembra di leggere una variante del paradosso dei due orologi

Ho dato un occhiata in rete e mi son fatto l'idea che delle tre testing è la meno stable delle tre.

 
E da che si desumerebbe questa conclusione? A logica ciò che è in testing è già passato in unstable, quindi come può essere più "sperimentale"?

Ma come passi a jigdo i valori per il proxy?
Esistono almeno due modi: come ti ho detto io prima o trasponendo gli stessi valori nel file di configurazione .jigdo-lite della directory da cui lo lanci.

Ma qui leggo:

Codice:

Errore analizzando l'URL del proxy http://:8080/: Nome dell'host non valido.

quindi, o jigdo non riceve i parametri correttamente, o il proxy non funziona come ti aspetti che debba fare. Quel che leggo sopra mi fa propendere per la prima ipotesi.

Io uso regolarmente jigdo passando questi parametri:

Codice:

wgetOpts='--passive-ftp --dot-style=mega --continue --timeout=30 -e http_proxy=$PROXYPATH --proxy-user=$PROXYNAME --proxy-passwd=$PROXYPWD'

valorizzando opportunamente le variabili. Non so però come li passi tu al tuo.