linux user group brescia

>
>
> On Fri, Apr 14, 2000 at 10:07:13AM +0200, m.capra a tin.it wrote:
> > - Linux Swap di 128MB (il mio sistema ha attualmente 96 MB in procinto di
> > aumentare a 128) sul 1° disco
> > - Linux Swap di 128MB (il mio sistema ha attualmente 96 MB in procinto di
> > aumentare a 128) sul 2° disco
> dubbioso, vedi poi.
>
> > - Linux native di 200MB per la dir. di boot sul 1° Disco
> > - Linux native di ciò che resta sul 1° Disco (magari da dividere
> > ulteriormente)
> > - Linux native di ciò che resta sul 2° Disco (magari da dividere
> > ulteriormente)
> dubbioso, vedi poi.
>
> > Fin qui potrei aver dimostrato di non aver capito nulla. Mettiamo il caso
> non e` che esista la configurazione giusta. ma per quanto mi par di
> capire tu voglia fare questo mi sembra sbagliato.
>
[...]
>
> > 2- Come conviene assegnare le directory di linux tipo /usr/ ,  /home/ ,
> > /tmp/ , nelle due parti Linux native HD1 e HD2 per ottimizzare gli accessi
> > ai dischi? (nella registrazione digitale multitraccia l'attività del disco
> > nella directory /tmp/ è piuttosto elevata tant'è che il sw che uso
> > solitamente in windows permette di impostarne due esclusivamente sue da
> > mettere preferibilmente in due HD diversi. In linux, non so come gestiranno
> > le dir di file temporanei i software che utilizzerò, ma presumo che il
> > concetto non sarà molto diverso)
> il concetto e` banale. l'hd che deve fare il recording deve trovarsi nelle
> condizioni di non dover fare altro mentre e` in azione...
> se sei in ide e` comunque ridicolo usare due hd separati, visto che
> comunque il bus viene loccato da un canale o dall'altro... a meno che

Mah, questo e' un noto baco del chipset triton (PIIX originario). Un chipset
 con un controller IDE come si deve NON dovrebbe bloccare i due canali
  a quel modo. In ogni caso tieni conto che il supporto per le modalita'
 "avanzate" di gestione disco su chipsets non Intel (e anche la gestione
 dell'UDMA e amenita' del genere) non e' disponibile sui kernels stabili.
 2.3.99-pre5 pare abbastanza robusto per l'applicazione che vuoi farci,
 pero'...
> non intendano un'altra cosa... vabbe`, che noia, non ho voglia di scrivere...
> comunque... mi sembra stupido usare /tmp parcheggiandoci file giganteschi...
> piuttosto, se guardi negli archivi della m/l del kernel vedrai che, di recente,
> un tizio ha postato dicendo di aver realizzato un filesystem stupido,
> a quale si accede in modo brutale (no gestione file, no gestione dir)...
> insomma, risultato finale, su ide il tizio sosteneva di poter fare
> multitraccia (una ventina, o giu` di li`)...
> guarda sotto la famosa pagina delle applicazioni audio se esiste gia`,
> magari, un programma che utilizzi per i fatti suoi una partizione in
> modo raw.

Concordo con Andrea: una nota pero'... a quel punto forse ti conviene accedere
 al disco in modo RAW (no cache/no delay)... questa e' una delle funzionalita'
 che nei 2.3 non sono completamente robuste (AC continua a ripetere nella
 lista dei jobs: reimplementare O_SYNC e testare il raw device access) 
 caveat emptor! [in fondo i devel ci sono per il developing, no?]
>
> > 3- Per far riconoscere a LILO che c'è un altro SO devo installare prima win
> > (quindi partizionare con fdisk ecc..), quindi installare Linux e con fdisk
> > in red hat partizionare quanto resta e assegnarlo alle varie dir? (ho già
> > fatto qualche esperimento... penso di aver combinato un gran casino!)
> no. puoi fare come vuoi.
>
cancella win :)

> > 4- Quando red-hat chiede il tipo di workstation che differenze ci sono tra
> > GNOME e KDA (se non ricordo male i nomi)?
> usa gnome.
>
Nota: gnome/kde sono piu' di semplici window managers; in effetti sono
 `desktop integrati' piuttosto completi... quale vuoi usare e' essenzialmente
 una faccenda di gusti. Io personalmente uso gnome.

Una ultima considerazione:
 il disk striping non e' particolarmente utile sotto IDE [il tuo e' un caso
 particolare ove potrebbe portare qualche vantaggio, ma non e' detto].
 In particolare sincerati che i due dischi siano collegati su canali
 diversi (i.e. siano hda e hdc e non hda e hdb)... la soluzione `ideale'
 e' sicuramente SCSI (U2 o, se hai un po' di soldi da spendere -tanti!-, U2W):
 costa di piu' e il transfer rate nominale non e' piu' alto che per EIDE
 (UDMA), ma c'e' un motivo per l'aumento di prezzo :)

Ciao,
 lg