Nuovo SSD SATA II 2.5 pollici 192GB da Transcend

Errore di fondo!

Mah, mi chiedo se sono citrullo io...

Tutti voi dite che questi SSD hanno senso solo se utilizzati per funzioni "nobili", ossia S.O. e Pgm Applicativi, in sostanza per contesto software.

Ora dico la mia cavolata CONTRO TENDENZA.

Il software, di Base o Applicativo che sia, è di norma molto ma molto meno movimentato rispetto ai dati I/O, dati sia pur "volgari" ma indispensabili, che oltretutto costituiscono la gran maggioranza delle aree memorizzate. Il software, B. o A. che sia, viene acceduto normalmente solo per il LOAD in memoria al momento della partenza di un task di elaborazione, e se non è fatto coi piedi non viene più chiamato in causa da area disco, a meno che, casi di processi "overlay" oggi rarissimi viste le tonnellate di RAM in linea, non sia assolutamente necessario... Se mai sono alcune area dati di sistema, tipo gli assurdi registri Windows cui M$ non sa proprio rinunciare, ad essere violentemente tampinati, ma non si tratta di SW, sono dati, ragazzi miei, e se M$ o chi per lei ci tenesse un pochino all'efficienza dette aree sarebbero allocate o per lo meno allocabili in ben altro posto che su HD disco fisico di SISTEMA... (Vi siete mai chiesti perchè sugli ineffabili sistemi a finestre il software non può risiedere su area in sola lettura, cosa che eviterebbe ogni casino da VIRUS & C. ..., altro che la ridicola "sicurezza" nominale di Vista...? Stiamo scontando le inefficienze di scuola M$... povera Informatica...). Per precisazione, la rientranza eventuale del SW deve essere ottenuta da copia in memoria e non da rilettura da disco!

Ben altro discorso invece investe aree dati su disco fisico, volgari quanto si vuole, ma che di regola per loro stessa natura devono essere accedute continuamente dall'applicazione e spesso in accesso random... fate voi... e magari SULLO STESSO HD ci sono in concorrenza miriadi di altri task che impazziscono in I/O, cosa amplificata dai multicore tanto di moda la cui unica utilità pratica è quella di far girare più applicazioni contemporanee... ognuna delle qualli tanpina dati I/O, guarda caso quasi sempre sullo stesso disco fisico... e la povera testina impazzisce, magari in concomitanza con le frullate gratuite di Vista, che magari proditoriamente sta imperversando come un pazzo sullo stesso disco per defrag e prefetch predittivi assolutamente non richiesti (e assolutamente inutili su SSD), impediteglielo subito se potete...

CHE BELLO SPETTACOLO!

E ora ditemi che ho torto!

Signori miei, un sistema coi fiocchi, e non quello che voi chiamate normalmente SO, dovrebbe prevedere allocazione scelta o eligibile dall'utente per ogni file, di sitema o applicativo che sia, e dovrebbe essere bandito tutto quel software che d'ufficio piazza certi files sul solito povero esausto e a questo punto ultracagionevole Disco C (che mica ce l'ha ordinato il medico...). Ma si sa, fa figo tampinare i registri... (Ovviamente per disco C intendo il disco contenente il sistema boostrappato).

In mancanza di questa possibilità, visto il SW in circolazione, purtroppo non resterebbe che far credere al sistema che facciano parte dell'abusato Disco C anche aree diverse, guarda caso allocate o per lo meno allocabili dall'utente sui famigerati SSD, che finalmente avrebbero piena ragione di esistere per l'efficienza I/O che ne risulterebbe, malgrado il loro costo ancora elevatissimo. Un SW che inganni in tal modo il SO del caso e gli applicativi col vizietto di parm e default su C, ovviamente a corredo della fornitura di SSD, sarebbe veramente ls manna, e la cosa oltretutto è fattibilissima, basti pensare a come viene prese per il naso un SO con tecniche di virtualizzazione...

Quando metteranno in circolazione un corredo SW del genere, potrò fare un pensierino ad SSD di una certa capacità, confidando anche nella diminuizione di prezzo col tempo.

Al momento, a suffragio di quanto ho detto, vi posso raccontare che, dopo che un fulmine mi ha cinito mezza MoBo, controller sataII compresa, ho piazzato una bella controller SATAII PCI a quattro HDD, e vado come un razzo con sistema per l'occasione portato su disco IDE, si signori miei, visto che il danno alla MoBo non mi fa riconoscere i nuovi SATA in fase di Boostrap e quindi da essi non posso fare Boot. (Spero non penserete che sia così ingenuo da avere dimenticato l'F6 per driver di terze parti SATA in fase di installazione...). Assolutamente non noto differenze di prestazioni se non 29 secondi contro 27 in fase di start-up del sistema. Invece vi assicuro che viaggio come un razzo avendo distribuito oculatamente i miei files dati, in funzione degli accessi, su 4 SATAII, e nessun Raid 0 o n per intenderci. A titolo di cronoca, per farvi capire l'importanza di accessi distribuiti su HD e quindi su testine diverse, copiare un grosso file sullo stesso HD può impiegare molte decine di volte il tempo necessario per copiarlo su HD diverso, non ne parliamo se poi ci sono altri Task che impegnano lo stesso unico HD... E' la morte NERA.

La forza sia con voi...

Errore di fondo!

Mah, mi chiedo se sono citrullo io...

Tutti voi dite che questi SSD hanno senso solo se utilizzati per funzioni "nobili", ossia S.O. e Pgm Applicativi, in sostanza per contesto software.

Ora dico la mia cavolata CONTRO TENDENZA.

Il software, di Base o Applicativo che sia, è di norma molto ma molto meno movimentato rispetto ai dati I/O, dati sia pur "volgari" ma indispensabili, che oltretutto costituiscono la gran maggioranza delle aree memorizzate. Il software, B. o A. che sia, viene acceduto normalmente solo per il LOAD in memoria al momento della partenza di un task di elaborazione, e se non è fatto coi piedi non viene più chiamato in causa da area disco, a meno che, casi di processi "overlay" oggi rarissimi viste le tonnellate di RAM in linea, non sia assolutamente necessario... Se mai sono alcune area dati di sistema, tipo gli assurdi registri Windows cui M$ non sa proprio rinunciare, ad essere violentemente tampinati, ma non si tratta di SW, sono dati, ragazzi miei, e se M$ o chi per lei ci tenesse un pochino all'efficienza dette aree sarebbero allocate o per lo meno allocabili in ben altro posto che su HD disco fisico di SISTEMA... (Vi siete mai chiesti perchè sugli ineffabili sistemi a finestre il software non può risiedere su area in sola lettura, cosa che eviterebbe ogni casino da VIRUS & C. ..., altro che la ridicola "sicurezza" nominale di Vista...? Stiamo scontando le inefficienze di scuola M$... povera Informatica...). Per precisazione, la rientranza eventuale del SW deve essere ottenuta da copia in memoria e non da rilettura da disco!

Ben altro discorso invece investe aree dati su disco fisico, volgari quanto si vuole, ma che di regola per loro stessa natura devono essere accedute continuamente dall'applicazione e spesso in accesso random... fate voi... e magari SULLO STESSO HD ci sono in concorrenza miriadi di altri task che impazziscono in I/O, cosa amplificata dai multicore tanto di moda la cui unica utilità pratica è quella di far girare più applicazioni contemporanee... ognuna delle qualli tanpina dati I/O, guarda caso quasi sempre sullo stesso disco fisico... e la povera testina impazzisce, magari in concomitanza con le frullate gratuite di Vista, che magari proditoriamente sta imperversando come un pazzo sullo stesso disco per defrag e prefetch predittivi assolutamente non richiesti (e assolutamente inutili su SSD), impediteglielo subito se potete...

CHE BELLO SPETTACOLO!

E ora ditemi che ho torto!

Signori miei, un sistema coi fiocchi, e non quello che voi chiamate normalmente SO, dovrebbe prevedere allocazione scelta o eligibile dall'utente per ogni file, di sitema o applicativo che sia, e dovrebbe essere bandito tutto quel software che d'ufficio piazza certi files sul solito povero esausto e a questo punto ultracagionevole Disco C (che mica ce l'ha ordinato il medico...). Ma si sa, fa figo tampinare i registri... (Ovviamente per disco C intendo il disco contenente il sistema boostrappato).

In mancanza di questa possibilità, visto il SW in circolazione, purtroppo non resterebbe che far credere al sistema che facciano parte dell'abusato Disco C anche aree diverse, guarda caso allocate o per lo meno allocabili dall'utente sui famigerati SSD, che finalmente avrebbero piena ragione di esistere per l'efficienza I/O che ne risulterebbe, malgrado il loro costo ancora elevatissimo. Un SW che inganni in tal modo il SO del caso e gli applicativi col vizietto di parm e default su C, ovviamente a corredo della fornitura di SSD, sarebbe veramente ls manna, e la cosa oltretutto è fattibilissima, basti pensare a come viene prese per il naso un SO con tecniche di virtualizzazione...

Quando metteranno in circolazione un corredo SW del genere, potrò fare un pensierino ad SSD di una certa capacità, confidando anche nella diminuizione di prezzo col tempo.

Al momento, a suffragio di quanto ho detto, vi posso raccontare che, dopo che un fulmine mi ha cinito mezza MoBo, controller sataII compresa, ho piazzato una bella controller SATAII PCI a quattro HDD, e vado come un razzo con sistema per l'occasione portato su disco IDE, si signori miei, visto che il danno alla MoBo non mi fa riconoscere i nuovi SATA in fase di Boostrap e quindi da essi non posso fare Boot. (Spero non penserete che sia così ingenuo da avere dimenticato l'F6 per driver di terze parti SATA in fase di installazione...). Assolutamente non noto differenze di prestazioni se non 29 secondi contro 27 in fase di start-up del sistema. Invece vi assicuro che viaggio come un razzo avendo distribuito oculatamente i miei files dati, in funzione degli accessi, su 4 SATAII, e nessun Raid 0 o n per intenderci. A titolo di cronoca, per farvi capire l'importanza di accessi distribuiti su HD e quindi su testine diverse, copiare un grosso file sullo stesso HD può impiegare molte decine di volte il tempo necessario per copiarlo su HD diverso, non ne parliamo se poi ci sono altri Task che impegnano lo stesso unico HD... E' la morte NERA.

La forza sia con voi...

Errore di fondo!

Mah, mi chiedo se sono citrullo io...

Tutti voi dite che questi SSD hanno senso solo se utilizzati per funzioni "nobili", ossia S.O. e Pgm Applicativi, in sostanza per contesto software.

Ora dico la mia cavolata CONTRO TENDENZA.

Il software, di Base o Applicativo che sia, è di norma molto ma molto meno movimentato rispetto ai dati I/O, dati sia pur "volgari" ma indispensabili, che oltretutto costituiscono la gran maggioranza delle aree memorizzate. Il software, B. o A. che sia, viene acceduto normalmente solo per il LOAD in memoria al momento della partenza di un task di elaborazione, e se non è fatto coi piedi non viene più chiamato in causa da area disco, a meno che, casi di processi "overlay" oggi rarissimi viste le tonnellate di RAM in linea, non sia assolutamente necessario... Se mai sono alcune area dati di sistema, tipo gli assurdi registri Windows cui M$ non sa proprio rinunciare, ad essere violentemente tampinati, ma non si tratta di SW, sono dati, ragazzi miei, e se M$ o chi per lei ci tenesse un pochino all'efficienza dette aree sarebbero allocate o per lo meno allocabili in ben altro posto che su HD disco fisico di SISTEMA... (Vi siete mai chiesti perchè sugli ineffabili sistemi a finestre il software non può risiedere su area in sola lettura, cosa che eviterebbe ogni casino da VIRUS & C. ..., altro che la ridicola "sicurezza" nominale di Vista...? Stiamo scontando le inefficienze di scuola M$... povera Informatica...). Per precisazione, la rientranza eventuale del SW deve essere ottenuta da copia in memoria e non da rilettura da disco!

Ben altro discorso invece investe aree dati su disco fisico, volgari quanto si vuole, ma che di regola per loro stessa natura devono essere accedute continuamente dall'applicazione e spesso in accesso random... fate voi... e magari SULLO STESSO HD ci sono in concorrenza miriadi di altri task che impazziscono in I/O, cosa amplificata dai multicore tanto di moda la cui unica utilità pratica è quella di far girare più applicazioni contemporanee... ognuna delle qualli tanpina dati I/O, guarda caso quasi sempre sullo stesso disco fisico... e la povera testina impazzisce, magari in concomitanza con le frullate gratuite di Vista, che magari proditoriamente sta imperversando come un pazzo sullo stesso disco per defrag e prefetch predittivi assolutamente non richiesti (e assolutamente inutili su SSD), impediteglielo subito se potete...

CHE BELLO SPETTACOLO!

E ora ditemi che ho torto!

Signori miei, un sistema coi fiocchi, e non quello che voi chiamate normalmente SO, dovrebbe prevedere allocazione scelta o eligibile dall'utente per ogni file, di sitema o applicativo che sia, e dovrebbe essere bandito tutto quel software che d'ufficio piazza certi files sul solito povero esausto e a questo punto ultracagionevole Disco C (che mica ce l'ha ordinato il medico...). Ma si sa, fa figo tampinare i registri... (Ovviamente per disco C intendo il disco contenente il sistema boostrappato).

In mancanza di questa possibilità, visto il SW in circolazione, purtroppo non resterebbe che far credere al sistema che facciano parte dell'abusato Disco C anche aree diverse, guarda caso allocate o per lo meno allocabili dall'utente sui famigerati SSD, che finalmente avrebbero piena ragione di esistere per l'efficienza I/O che ne risulterebbe, malgrado il loro costo ancora elevatissimo. Un SW che inganni in tal modo il SO del caso e gli applicativi col vizietto di parm e default su C, ovviamente a corredo della fornitura di SSD, sarebbe veramente ls manna, e la cosa oltretutto è fattibilissima, basti pensare a come viene prese per il naso un SO con tecniche di virtualizzazione...

Quando metteranno in circolazione un corredo SW del genere, potrò fare un pensierino ad SSD di una certa capacità, confidando anche nella diminuizione di prezzo col tempo.

Al momento, a suffragio di quanto ho detto, vi posso raccontare che, dopo che un fulmine mi ha cinito mezza MoBo, controller sataII compresa, ho piazzato una bella controller SATAII PCI a quattro HDD, e vado come un razzo con sistema per l'occasione portato su disco IDE, si signori miei, visto che il danno alla MoBo non mi fa riconoscere i nuovi SATA in fase di Boostrap e quindi da essi non posso fare Boot. (Spero non penserete che sia così ingenuo da avere dimenticato l'F6 per driver di terze parti SATA in fase di installazione...). Assolutamente non noto differenze di prestazioni se non 29 secondi contro 27 in fase di start-up del sistema. Invece vi assicuro che viaggio come un razzo avendo distribuito oculatamente i miei files dati, in funzione degli accessi, su 4 SATAII, e nessun Raid 0 o n per intenderci. A titolo di cronoca, per farvi capire l'importanza di accessi distribuiti su HD e quindi su testine diverse, copiare un grosso file sullo stesso HD può impiegare molte decine di volte il tempo necessario per copiarlo su HD diverso, non ne parliamo se poi ci sono altri Task che impegnano lo stesso unico HD... E' la morte NERA.

La forza sia con voi...

Errore di fondo!

Mah, mi chiedo se sono citrullo io...

Tutti voi dite che questi SSD hanno senso solo se utilizzati per funzioni "nobili", ossia S.O. e Pgm Applicativi, in sostanza per contesto software.

Ora dico la mia cavolata CONTRO TENDENZA.

Il software, di Base o Applicativo che sia, è di norma molto ma molto meno movimentato rispetto ai dati I/O, dati sia pur "volgari" ma indispensabili, che oltretutto costituiscono la gran maggioranza delle aree memorizzate. Il software, B. o A. che sia, viene acceduto normalmente solo per il LOAD in memoria al momento della partenza di un task di elaborazione, e se non è fatto coi piedi non viene più chiamato in causa da area disco, a meno che, casi di processi "overlay" oggi rarissimi viste le tonnellate di RAM in linea, non sia assolutamente necessario... Se mai sono alcune area dati di sistema, tipo gli assurdi registri Windows cui M$ non sa proprio rinunciare, ad essere violentemente tampinati, ma non si tratta di SW, sono dati, ragazzi miei, e se M$ o chi per lei ci tenesse un pochino all'efficienza dette aree sarebbero allocate o per lo meno allocabili in ben altro posto che su HD disco fisico di SISTEMA... (Vi siete mai chiesti perchè sugli ineffabili sistemi a finestre il software non può risiedere su area in sola lettura, cosa che eviterebbe ogni casino da VIRUS & C. ..., altro che la ridicola "sicurezza" nominale di Vista...? Stiamo scontando le inefficienze di scuola M$... povera Informatica...). Per precisazione, la rientranza eventuale del SW deve essere ottenuta da copia in memoria e non da rilettura da disco!

Ben altro discorso invece investe aree dati su disco fisico, volgari quanto si vuole, ma che di regola per loro stessa natura devono essere accedute continuamente dall'applicazione e spesso in accesso random... fate voi... e magari SULLO STESSO HD ci sono in concorrenza miriadi di altri task che impazziscono in I/O, cosa amplificata dai multicore tanto di moda la cui unica utilità pratica è quella di far girare più applicazioni contemporanee... ognuna delle qualli tanpina dati I/O, guarda caso quasi sempre sullo stesso disco fisico... e la povera testina impazzisce, magari in concomitanza con le frullate gratuite di Vista, che magari proditoriamente sta imperversando come un pazzo sullo stesso disco per defrag e prefetch predittivi assolutamente non richiesti (e assolutamente inutili su SSD), impediteglielo subito se potete...

CHE BELLO SPETTACOLO!

E ora ditemi che ho torto!

Signori miei, un sistema coi fiocchi, e non quello che voi chiamate normalmente SO, dovrebbe prevedere allocazione scelta o eligibile dall'utente per ogni file, di sitema o applicativo che sia, e dovrebbe essere bandito tutto quel software che d'ufficio piazza certi files sul solito povero esausto e a questo punto ultracagionevole Disco C (che mica ce l'ha ordinato il medico...). Ma si sa, fa figo tampinare i registri... (Ovviamente per disco C intendo il disco contenente il sistema boostrappato).

In mancanza di questa possibilità, visto il SW in circolazione, purtroppo non resterebbe che far credere al sistema che facciano parte dell'abusato Disco C anche aree diverse, guarda caso allocate o per lo meno allocabili dall'utente sui famigerati SSD, che finalmente avrebbero piena ragione di esistere per l'efficienza I/O che ne risulterebbe, malgrado il loro costo ancora elevatissimo. Un SW che inganni in tal modo il SO del caso e gli applicativi col vizietto di parm e default su C, ovviamente a corredo della fornitura di SSD, sarebbe veramente ls manna, e la cosa oltretutto è fattibilissima, basti pensare a come viene prese per il naso un SO con tecniche di virtualizzazione...

Quando metteranno in circolazione un corredo SW del genere, potrò fare un pensierino ad SSD di una certa capacità, confidando anche nella diminuizione di prezzo col tempo.

Al momento, a suffragio di quanto ho detto, vi posso raccontare che, dopo che un fulmine mi ha cinito mezza MoBo, controller sataII compresa, ho piazzato una bella controller SATAII PCI a quattro HDD, e vado come un razzo con sistema per l'occasione portato su disco IDE, si signori miei, visto che il danno alla MoBo non mi fa riconoscere i nuovi SATA in fase di Boostrap e quindi da essi non posso fare Boot. (Spero non penserete che sia così ingenuo da avere dimenticato l'F6 per driver di terze parti SATA in fase di installazione...). Assolutamente non noto differenze di prestazioni se non 29 secondi contro 27 in fase di start-up del sistema. Invece vi assicuro che viaggio come un razzo avendo distribuito oculatamente i miei files dati, in funzione degli accessi, su 4 SATAII, e nessun Raid 0 o n per intenderci. A titolo di cronoca, per farvi capire l'importanza di accessi distribuiti su HD e quindi su testine diverse, copiare un grosso file sullo stesso HD può impiegare molte decine di volte il tempo necessario per copiarlo su HD diverso, non ne parliamo se poi ci sono altri Task che impegnano lo stesso unico HD... E' la morte NERA.

La forza sia con voi...