Passare si o no a Vista? opinioni da chi lo ha provato risp

[sirus]

Originariamente inviato da ghiltanas

siccome ho 2 pc collegati in rete mediante un router e voglio condividere la cartella pubblica e scambiarmi file, il tipo di rete la devo mettere privata o lascio pubblica?

Privata.
Con rete Pubblica si intende una connessione ad un hot-spot pubblico.

[ghiltanas]

Originariamente inviato da sirus

Privata.
Con rete Pubblica si intende una connessione ad un hot-spot pubblico.

grazie siccome nn ero sicuro sul discorso della visibilità e della condivisione..ora in pratica i 2 pc sono visibili tra loro e si possono scambiare file però solo all'interno della rete domestica, cioè il router collega i 2 pc tra loro e sempre attraverso esso ciascun pc va su internet? (lo chiedo per un disc di sicurezza, voglio essere sicuro che la cartella pubblica per es nn sia visibile anche su internet ma solo dall'altro pc della rete pivata)

[giannola]

Originariamente inviato da Dott.Wisem

Si, ma questo non è un forum di appassionati di Logica Matematica...Peccato che tu abbia 'perfettamente' ignorato/frainteso il senso del mio post precedente Certo, come no. Forse tu non ti rendi conto che i programmi li scrivono esseri umani, non automi...Secondo me non hai capito bene il senso della frase che ho scritto nel mio post precedente. Rileggila con attenzione, togliendoti per un attimo dalla testa i tuoi cari teoremi, ma usa semplicemente il tuo cervello. L'esempio della calcolatrice, in particolare, non c'entra una mazza con quanto detto da me nel mio post precedente...

io il senso della tua frase l'ho capito benissimo.
Ma è un problema di concetti: se uno ha chiaro un concetto attraverso una generalizzazione allora lo può applicare dovunque, altrimenti userà un approccio del tipo caso per caso con grande perdita di tempo.

I teoremi non vanno tolti dalla testa, altrimenti anzichè scrivere un programma scriverei solo delle linee di codice.

L'esempio della calcolatrice c'entra benissimo, soprattutto per chiederti di dirmi che cos'è un bug.

Originariamente inviato da innominato5090

appunto: più il codice è grande, ovvero più varabili prendi in considerazione, più ci saranno possibilità di errori.

Qua non si tratta di errori, perchè un programmatore bravo non consegna un programma con un errore, si tratta dei teoremi di cui ho parlato.
Il programmatore dovrebbe fare in modo che le infinite variabili che possono essere date in pasto al programma non creino un comportamento scorretto di questo.

Originariamente inviato da II ARROWS

A parte che io non ho mai visto una calcolatrice che mi permette di mettere come numero una lettera... A parte la funzione HEX ma sono sempre numeri.

Grazie tante, è perchè il suo realizzatore ha voluto prevedere che si potessero inserire solo numeri e non lettere, ovviamente la limitazione dei valori in entrata non può essere utilizzata per qualunque programma.

[sirus]

Originariamente inviato da ghiltanas

grazie siccome nn ero sicuro sul discorso della visibilità e della condivisione..ora in pratica i 2 pc sono visibili tra loro e si possono scambiare file però solo all'interno della rete domestica, cioè il router collega i 2 pc tra loro e sempre attraverso esso ciascun pc va su internet? (lo chiedo per un disc di sicurezza, voglio essere sicuro che la cartella pubblica per es nn sia visibile anche su internet ma solo dall'altro pc della rete pivata)

Alla rete domestica che utilizza il router è stato associato un profilo Privato che permette di scambiare i file sulla tua rete e non all'esterno.

[ghiltanas]

Originariamente inviato da sirus

Alla rete domestica che utilizza il router è stato associato un profilo Privato che permette di scambiare i file sulla tua rete e non all'esterno.

grazie mille . un' altra cosa: c'è un modo per dare permanentemente i permessi di amministratore a un'applicazione? ad esempio sennò con firefox se lo apro normalmente mi viene bloccato download manager (per fare un esempio)

[Dott.Wisem]

Originariamente inviato da giannola

io il senso della tua frase l'ho capito benissimo.
Ma è un problema di concetti: se uno ha chiaro un concetto attraverso una generalizzazione allora lo può applicare dovunque, altrimenti userà un approccio del tipo caso per caso con grande perdita di tempo.

I teoremi non vanno tolti dalla testa, altrimenti anzichè scrivere un programma scriverei solo delle linee di codice.

L'esempio della calcolatrice c'entra benissimo, soprattutto per chiederti di dirmi che cos'è un bug.

Se l'esempio della calcolatrice c'entra qualcosa, allora probabilmente saresti un cattivo insegnante, poiché non sei riuscito, né prima, né ora, a spiegare il nesso (che tuttora ignoro) fra quell'esempio e la mia frase.

Qua non si tratta di errori, perchè un programmatore bravo non consegna un programma con un errore, si tratta dei teoremi di cui ho parlato.

Continui a non capire e continui ad accennare ai tuoi teoremi, lasciando poi le cose in sospeso... Se devi esprimere un concetto articolato, allora và fino in fondo, altrimenti non puoi pretendere che gli altri ti diano ragione 'a fiducia'. L'utente innominato5090 ha detto una cosa perfettamente condivisibile. Se un programmatore scrive 10000 linee di codice, relativamente ad una certa applicazione, ci sarà certamente una probabilità maggiore che in tale codice vi siano dei bug, rispetto allo scrivere un'applicazione da 100 linee di codice, ti pare? Se poi non sei d'accordo, allora chiudiamola qua che è meglio...

Il programmatore dovrebbe fare in modo che le infinite variabili che possono essere date in pasto al programma non creino un comportamento scorretto di questo.

A voler essere precisi, ad un programma non si danno in input delle 'variabili', ma dei 'valori'.
E poi, non spieghi come possa fare un programmatore ad accertarsi che le infinite combinazioni di valori che puoi dare in input ad un programma non comportino in nessun caso un comportamento scorretto dello stesso. La risposta, ovviamente, è che non si può fare (a meno che il dominio dell'input del programma non sia finito e ragionevolmente piccolo, in modo tale da poter fare un controllo esaustivo).

Comunque, il programmatore può essere bravo quanto vuole, ma è un essere umano, ergo, commetterà sempre errori. Piuttosto, il programmatore bravo, cerca di programmare usando delle tecniche che gli consentano di 'anticipare' il verificarsi di certi errori e gestire l'evento inatteso in qualche modo, usando ad esempio i blocchi try...catch (gestione delle eccezioni) di C++/Java e tanti altri linguaggi, oppure gestendo le pre-condizioni e le post-condizioni, in modo da facilitare enormemente il debug dei programmi, come si fa, ad esempio, in Eiffel (utilizzando il paradigma 'Design By Contract'): in pratica, il codice di una funzione controlla dapprima che l'input soddisfi le pre-condizioni. In caso positivo, esegue il codice interno della funzione e alla fine, prima che la funzione restituisca il risultato, vengono controllate le post-condizioni (verificando che siano soddisfatte delle proprietà). Un buon design consiste nello scrivere le pre e post condizioni delle funzioni, prima ancora di implementare le stesse.
Tutte queste tecniche, non servono certo a garantirti che un codice sia 100% error-free, ma quantomeno consentono di intercettare (ed eventualmente gestire) l'errore prima che questo possa portare a dei risultati catastrofici e, contemporaneamente, consentono di avere una rapida individuazione (e quindi una rapida correzione da parte del team di sviluppo) del problema.

[sirus]

Originariamente inviato da Dott.Wisem

...
oppure gestendo le pre-condizioni e le post-condizioni, in modo da facilitare enormemente il debug dei programmi, come si fa, ad esempio, in Eiffel (utilizzando il paradigma 'Design By Contract'): in pratica, il codice di una funzione controlla dapprima che l'input soddisfi le pre-condizioni. In caso positivo, esegue il codice interno della funzione e alla fine, prima che la funzione restituisca il risultato, vengono controllate le post-condizioni (verificando che siano soddisfatte delle proprietà). Un buon design consiste nello scrivere le pre e post condizioni delle funzioni, prima ancora di implementare le stesse.
...

Ci hanno fatto un bel mazzo nel corso di Ingegneria del Software con il "design by contract"; noi abbiamo usato JML e Java.
Ci sono comunque dei notevoli svantaggi anche con questo approccio, generalmente si tende a scrivere metodi completi ossia che gestiscano qualsiasi caso in ingresso e non è quindi sempre possibile scrivere delle post-condizioni verificabili automaticamente da una macchina (e qui ci giochiamo l'utilità del DBC).
Inoltre l'utilizzo di un linguaggio formale per definire pre-condizioni e post-condizioni è un bene per lo sviluppo in team ma in generale il suo utilizzo occupa un tempo molto simile a quello utile per scrivere direttamente il codice e testarlo in modalità whitebox con JUnit o sistemi simili, il DBC è un overhead molto grande.

[ghiltanas]

ho un problema col portatile: ha su vista home premium a 32 bit, lo accendo e mi dice che c'èuna nuova versione di avast..la scarico e poi mi dice che è necessario riavviare il pc, lo riavvio e dopo il caricamento di windows con la barra orizzontale mi si visualizza solo la freccetta del mouse e schermo nero, ora ho provato ad avviarlo in modalità provvisoria e ho fatto un ripristino però è già un pò che è in fase di "inizialiazzazione"..qualcuno ha idea del perchè si comporta cosi e come posso risolvere?

[sirus]

La butto li... potrebbe essere la nuova versione di Avast il problema.

[ghiltanas]

è quella porca miseria, ho fatto il ripristino e tutto ok se nn che appena avvio mi viene visualizzato il mess di avast di riavviare, lo faccio e ora risono da capo . Ora faccio il ripristino di nuovo, disinstallo avast e mette antivir tanto sul portatile ho vista 32 bit, però strano perchè sul fisso l'aggiornamento nn mi ha dato problemi (però qui ho vista 64 bit )

[giannola]

Originariamente inviato da Dott.Wisem

Se l'esempio della calcolatrice c'entra qualcosa, allora probabilmente saresti un cattivo insegnante, poiché non sei riuscito, né prima, né ora, a spiegare il nesso (che tuttora ignoro) fra quell'esempio e la mia frase.Continui a non capire e continui ad accennare ai tuoi teoremi, lasciando poi le cose in sospeso... Se devi esprimere un concetto articolato, allora và fino in fondo, altrimenti non puoi pretendere che gli altri ti diano ragione 'a fiducia'. L'utente innominato5090 ha detto una cosa perfettamente condivisibile. Se un programmatore scrive 10000 linee di codice, relativamente ad una certa applicazione, ci sarà certamente una probabilità maggiore che in tale codice vi siano dei bug, rispetto allo scrivere un'applicazione da 100 linee di codice, ti pare? Se poi non sei d'accordo, allora chiudiamola qua che è meglio...A voler essere precisi, ad un programma non si danno in input delle 'variabili', ma dei 'valori'.
E poi, non spieghi come possa fare un programmatore ad accertarsi che le infinite combinazioni di valori che puoi dare in input ad un programma non comportino in nessun caso un comportamento scorretto dello stesso. La risposta, ovviamente, è che non si può fare (a meno che il dominio dell'input del programma non sia finito e ragionevolmente piccolo, in modo tale da poter fare un controllo esaustivo).

Comunque, il programmatore può essere bravo quanto vuole, ma è un essere umano, ergo, commetterà sempre errori. Piuttosto, il programmatore bravo, cerca di programmare usando delle tecniche che gli consentano di 'anticipare' il verificarsi di certi errori e gestire l'evento inatteso in qualche modo, usando ad esempio i blocchi try...catch (gestione delle eccezioni) di C++/Java e tanti altri linguaggi, oppure gestendo le pre-condizioni e le post-condizioni, in modo da facilitare enormemente il debug dei programmi, come si fa, ad esempio, in Eiffel (utilizzando il paradigma 'Design By Contract'): in pratica, il codice di una funzione controlla dapprima che l'input soddisfi le pre-condizioni. In caso positivo, esegue il codice interno della funzione e alla fine, prima che la funzione restituisca il risultato, vengono controllate le post-condizioni (verificando che siano soddisfatte delle proprietà). Un buon design consiste nello scrivere le pre e post condizioni delle funzioni, prima ancora di implementare le stesse.
Tutte queste tecniche, non servono certo a garantirti che un codice sia 100% error-free, ma quantomeno consentono di intercettare (ed eventualmente gestire) l'errore prima che questo possa portare a dei risultati catastrofici e, contemporaneamente, consentono di avere una rapida individuazione (e quindi una rapida correzione da parte del team di sviluppo) del problema.

e allora vuol dire che sono un cattivo insegnante

Quello che intendevo dire è che è ininfluente che un programma sia fatto da 1 linea di codice o 100mila.

Quello che è importante sapere è che nel momento in cui un programma si trova ad elaborare valori in ingresso (giusta la tua correzione) allora è certo che presenterà dei bug qualunque sia la bravura o l'ingegno del programmatore.

Poi sapere con quale probabilità si verificherà un bug a seconda del numero di linee è un effetto secondario.

Inoltre mi preme riaffermare il concetto che il programmatore in questo non c'entra nulla, non è colpa sua se si verificano i bug, può solo correggerli, sarà sempre così.

Anche nella verifica di precondizioni, adottando qualunque tecnica try...catch, ci saranno sempre infiniti valori che possono mandare a puxxane il proprio programma, è una questione di tempo: qualcuno ricorda gli insiemi ricorsivamente enumerabili ?

Le nostre divergenze stanno tutte lì tu parti da un errore umano (che non esiste), io invece parto dal ragionamento scientifico che (grazie ai teoremi) permette di spiegare che nessuno protrà mai creare un programma che sia esente da bachi e non perchè umano, limitato e può sbagliare, ma semplicemente perchè è impossibile.

[Dott.Wisem]

Originariamente inviato da sirus

Ci hanno fatto un bel mazzo nel corso di Ingegneria del Software con il "design by contract"; noi abbiamo usato JML e Java.
Ci sono comunque dei notevoli svantaggi anche con questo approccio, generalmente si tende a scrivere metodi completi ossia che gestiscano qualsiasi caso in ingresso e non è quindi sempre possibile scrivere delle post-condizioni verificabili automaticamente da una macchina (e qui ci giochiamo l'utilità del DBC).
Inoltre l'utilizzo di un linguaggio formale per definire pre-condizioni e post-condizioni è un bene per lo sviluppo in team ma in generale il suo utilizzo occupa un tempo molto simile a quello utile per scrivere direttamente il codice e testarlo in modalità whitebox con JUnit o sistemi simili, il DBC è un overhead molto grande.

La scrittura di pre e post-condizioni fa sicuramente perdere del tempo, poiché si tratta di una fase impegnatva, a cavallo fra progettazione e implementazione. Tuttavia, se ben eseguita, tale fase porta alla realizzazione di codice in cui l'origine di un errore è individuabile molto più facilmente (da cui, un grande risparmio sui tempi di manutenzione).
E' un compromesso: maggiore impegno nello sviluppo, per risparmiare grandi fatiche e mal di testa in fase di manutenzione. Peccato che Eiffel sia uno dei pochissimi linguaggi che supportano nativamente questo paradigma (in realtà sono state sviluppate delle estensioni DBC per gran parte dei linguaggi principali, fra cui C++ e Java, ma finché non diventeranno uno standard, non credo saranno usatissime).

[sirus]

Originariamente inviato da Dott.Wisem

...ma finché non diventeranno uno standard, non credo saranno usatissime).

Il problema è che alle volte le espressioni logiche (perché di logica si tratta) utili a valutare le pre-condizioni e le post-condizioni non sono scrivibili senza l'uso di metodi di supporto (che vanno scritti appositamente per il controllo e che potrebbero a loro volta causare errori). Di fatto alcune espressioni sono o troppo complesse da scrivere oppure non sono valutabili.

[Dott.Wisem]

Originariamente inviato da giannola

Quello che intendevo dire è che è ininfluente che un programma sia fatto da 1 linea di codice o 100mila.

Mah... Se fai queste uscite, poi devi anche spiegarne per bene i motivi, altrimenti sembra che tu abbia detto una cosa insensata.

Quello che è importante sapere è che nel momento in cui un programma si trova ad elaborare valori in ingresso (giusta la tua correzione) allora è certo che presenterà dei bug qualunque sia la bravura o l'ingegno del programmatore.

Non è affatto vero, perché come ho già detto, se tutte le combinazioni di input sono in numero finito e ragionevolmente basso, è realistico pensare ad un controllo esaustivo su tutti gli input (e la correttezza dei relativi ouput) del programma.

Poi sapere con quale probabilità si verificherà un bug a seconda del numero di linee è un effetto secondario.

Secondario di che?

Inoltre mi preme riaffermare il concetto che il programmatore in questo non c'entra nulla, non è colpa sua se si verificano i bug, può solo correggerli, sarà sempre così.

Magari se ha bevuto un fiasco di vino, prima di mettersi davanti al pc, oppure se è incompetente di suo, forse qualche colpa ce l'avrà anche lui...

Anche nella verifica di precondizioni, adottando qualunque tecnica try...catch, ci saranno sempre infiniti valori che possono mandare a puxxane il proprio programma, è una questione di tempo: qualcuno ricorda gli insiemi ricorsivamente enumerabili ?

Normalmente, un blocco try...catch è in grado di intercettare qualunque tipo di eccezione. Se poi nel codice ci sono errori concettuali, allora è un altro discorso, ma torniamo sempre al solito fattore 'uomo'. E poi io non ho detto che il try...catch serve ad assicurare la correttezza, ma è uno strumento per poter scovare più facilmente l'errore (o per evitare che il programma si inceppi, lasciando ad esempio un archivio in stato di incoerenza, in seguito ad un errore).

Le nostre divergenze stanno tutte lì tu parti da un errore umano (che non esiste)

L'errore umano non esiste?? Ma che dici...

, io invece parto dal ragionamento scientifico che (grazie ai teoremi) permette di spiegare che nessuno protrà mai creare un programma che sia esente da bachi e non perchè umano, limitato e può sbagliare, ma semplicemente perchè è impossibile.

Ti faccio notare che il fatto che non esista e mai potrà esistere una macchina in grado di determinare la correttezza di ogni algoritmo, non implica automaticamente che ogni algoritmo che scrivo sarà sicuramente sbagliato o conterrà errori... Quindi ti invito a riformulare meglio quanto da te detto circa l'impossibilità di creare un algoritmo esente da bug, che non abbia a che fare con l'umanità del programmatore (se ci riesci)...

[sirus]

Dopo aver usato Windows XP sul MacBook ho deciso di re-installare Windows Vista ora che ho 2 GB di RAM. Il salto prestazionale è impressionante se con 1 GB di RAM il sistema mi sembrava più veloce di Windows XP, con 2 GB di RAM la differenza è abissale.
Purtroppo non posso utilizzare la versione x86-64 perché EFI di Apple è a 32 bit quindi non permette il boot di sistemi completamente 64 bit come Windows Vista x86-64.

Ho avuto il piacere di notare una cosa rispetto agli altri PC su cui ho provato/usato Windows Vista, l'hard disk sembra non essere neppure in funzione, quindi ho il Seagate che monta il PC è silenziosissimo oppure i 2 GB di RAM sono veramente un toccasana... in questo momento con il solo Internet Explorer aperto sono ad 839 MB di RAM utilizzata (224 MB sono completamente dedicati alla scheda video), la cache in memoria è di 1181 MB lo swap invece non è utilizzato, la somma dell'occupazione dei 2 core ballonzola tra 0% e 5%.
Ho notato solo ora che il kernel di Windows Vista occupa meno spazio in memoria rispetto a quello di Windows XP, immagino dipenda dal mancato caricamente dei driver video (ed altri driver) in user-space.

Che dire, se con 1 GB di RAM pensavo che Windows Vista fosse ottimo, con 2 GB di RAM sinceramente non capisco come si possa restare ancora con Windows XP.

[Dott.Wisem]

Originariamente inviato da sirus

Dopo aver usato Windows XP sul MacBook ho deciso di re-installare Windows Vista ora che ho 2 GB di RAM. Il salto prestazionale è impressionante se con 1 GB di RAM il sistema mi sembrava più veloce di Windows XP, con 2 GB di RAM la differenza è abissale.

Sul MacBook, ogni volta che ho installato Windows XP con BootCamp ho sempre notato degli strani rallentamenti, audio che scattava, ecc.. Almeno fino al mese scorso era così, ora non so se i driver del BootCamp siano migliorati.
E' possibile che Vista ti dia l'impressione di essere più veloce perché magari possiede dei driver di default maggiormente compatibili con l'hardware montato nei MacBook. Aero lo riesci ad attivare sul MacBook?

Comunque, su ogni macchina in cui ho dovuto disinstallare Vista per installare XP non c'era proprio storia... XP sembrava un missile rispetto a Vista, soprattutto da 1GB in giù. Anche il boot in XP è più rapido (a sistema pulito, ovviamente). Io parlo di installazioni di XP e Vista fatte da zero, non i ripristini dei notebook, che incorporano tonnellate di tool mangia-ram, spesso inutili (Vista già ci mette molto di suo, comunque, anche escludendo i tool dei produttori di notebook... Vedi Windows Sidebar, Windows Defender, ecc.).

Purtroppo non posso utilizzare la versione x86-64 perché EFI di Apple è a 32 bit quindi non permette il boot di sistemi completamente 64 bit come Windows Vista x86-64.

Significa che Leopard a 64bit non potrà essere installato su tali computer?

Ho avuto il piacere di notare una cosa rispetto agli altri PC su cui ho provato/usato Windows Vista, l'hard disk sembra non essere neppure in funzione, quindi ho il Seagate che monta il PC è silenziosissimo oppure i 2 GB di RAM sono veramente un toccasana... [...]

E ti credo che non senti l'hd!! Quello montato nei MacBook è il più silenzioso che mi sia mai capitato di sentire! Del resto non hanno neanche una lucetta che ti indica l'attività dell'hd...

Ho notato solo ora che il kernel di Windows Vista occupa meno spazio in memoria rispetto a quello di Windows XP, immagino dipenda dal mancato caricamente dei driver video (ed altri driver) in user-space.

Per quanto riguarda l'occupazione di memoria del kernel di Windows, forse dipende dalla quantità di ram installata nel sistema. Sul mio notebook con Vista, dotato di 2GB di ram, il kernel occupa 134MB. Sul fisso con XP, dotato di 1GB di ram, occupa 47MB. Devo verificare su un sistema di 1GB basato su Vista quanto occupa il kernel. Comunque, in teoria, il kernel di Vista potrebbe occupare qualcosa in meno per via di alcuni driver in user-space. Ma dobbiamo anche considerare che, escludendo il discorso driver, il kernel di Vista dovrebbe essere più corposo a causa di alcune variazioni negli algoritmi di scheduling, di gestione della memoria e per degli schemi di protezione più sofisticati.

Che dire, se con 1 GB di RAM pensavo che Windows Vista fosse ottimo, con 2 GB di RAM sinceramente non capisco come si possa restare ancora con Windows XP.

Ho una macchina che 3 anni fa era una bestiolina. Ora sembra quasi un oggetto primitivo rispetto al progresso dell'hardware, ma al momento non ho intenzione di cambiarla, perché fa il suo dovere, mi funziona tutto alla grande e non ho esigenze particolarmente sofisticate. Di Aero ne posso fare tranquillamente a meno. Il computer è sufficientemente protetto, grazie a firewall software, antivirus e router ben configurato. Immondizia non ne scarico e non installo nulla di cui non abbia fiducia. Nel caso mi venisse voglia, posso sempre testare qualcosa di poco fidato dentro una macchina virtuale. Ogni tanto voglio avere la possibilità di fare qualche bel videogioco, anche di qualche anno fa, senza farmi venire mal di testa stando dietro ad UAC e virtualizzazione delle directory (se il gioco è programmato bene, la mia fida Radeon 9800Pro riesce ancora a dare grandi soddisfazioni). Essendo il sistema un po' datato, quei 5-6 FPS in più che mi garantisce XP, a volte possono fare la differenza. Perché mai dovrei spendere dei soldi per passare a Vista? Sarei obbligato a comprare più ram, una chiavetta USB per il ReadyBoost (visto che l'hard disk che rulla mi dà troppo fastidio, non tanto per il rumore, ma per il fatto che mi mantiene alte le temperature dell'hd, cosa che d'estate è molto rischiosa), dovrei fare un backup dei dati e formattare (e non ne ho la minima voglia), nonché avere delle performance inferiori nell'encoding audio/video, nei videogiochi, ed altre applicazioni. Allora dimmi: ma chi me lo fa fare?

[sirus]

Originariamente inviato da Dott.Wisem

Sul MacBook, ogni volta che ho installato Windows XP con BootCamp ho sempre notato degli strani rallentamenti, audio che scattava, ecc.. Almeno fino al mese scorso era così, ora non so se i driver del BootCamp siano migliorati.
E' possibile che Vista ti dia l'impressione di essere più veloce perché magari possiede dei driver di default maggiormente compatibili con l'hardware montato nei MacBook. Aero lo riesci ad attivare sul MacBook?

Con l'ultima release dei driver, quelli contenuti nel pacchetto Boot Camp 1.3 e cose sono migliorate su Windows XP, il sistema era a livelli più che buoni.
NB: i driver vengono forniti dal produttore dell'hardware, non è Apple a scriverli.
Aero si attiva in automatico e lo fa ampiamente considerando che la scheda video lato desktop si prende ben oltre 3 punti (il minimo per attivare Aero è 2 punti con supporto DirectX 9.0), quello che penalizza il punteggio totale (3.1) è il gaming.

Originariamente inviato da Dott.Wisem

Comunque, su ogni macchina in cui ho dovuto disinstallare Vista per installare XP non c'era proprio storia... XP sembrava un missile rispetto a Vista, soprattutto da 1GB in giù. Anche il boot in XP è più rapido (a sistema pulito, ovviamente). Io parlo di installazioni di XP e Vista fatte da zero, non i ripristini dei notebook, che incorporano tonnellate di tool mangia-ram, spesso inutili (Vista già ci mette molto di suo, comunque, anche escludendo i tool dei produttori di notebook... Vedi Windows Sidebar, Windows Defender, ecc.).

L'unica cosa che ho disabilitato è stato Windows Defender ed ho impostato Superfetch in modalità Automatic (Start delayed). Se con 1 GB c'era paragone in termini di velocità, con 2 GB non c'è assolutamente storia.

Originariamente inviato da Dott.Wisem

Significa che Leopard a 64bit non potrà essere installato su tali computer?

Si che si potrà, il sistema della Apple è ibrido ossia dispone di parti a 32 bit e 64 bit. Il boot sarà sicuramente a 32 bit e quindi non ci saranno problemi. Intel ha rilasciato le specifiche di UEFI 2.0, che è la versione 64 bit di EFI 1.1 disponibile per i sistemi Apple, già da tempo; tuttavia Apple non ne ha fatto uso.

Originariamente inviato da Dott.Wisem

E ti credo che non senti l'hd!! Quello montato nei MacBook è il più silenzioso che mi sia mai capitato di sentire!

Concordo, il Fujitsu di mia sorella è un catorcio in confronto.

Originariamente inviato da Dott.Wisem

Del resto non hanno neanche una lucetta che ti indica l'attività dell'hd...Per quanto riguarda l'occupazione di memoria del kernel di Windows, forse dipende dalla quantità di ram installata nel sistema. Sul mio notebook con Vista, dotato di 2GB di ram, il kernel occupa 134MB. Sul fisso con XP, dotato di 1GB di ram, occupa 47MB. Devo verificare su un sistema di 1GB basato su Vista, il kernel quanto occupa.
Comunque, in teoria, il kernel di Vista potrebbe occupare qualcosa in meno per via di alcuni driver in user-space. Ma dobbiamo anche considerare che, escludendo il discorso driver, il kernel di Vista dovrebbe essere più corposo a causa di alcune variazioni negli algoritmi di scheduling, di gestione della memoria e per degli schemi di protezione più sofisticati.

Credo dipenda più che altro dai driver. Gli unici driver rimasti in kernel-space (sto parlando di quello sul quale l'utente può agire) sono quelli delle schede audio, sono quelli che pesano maggiormente.
Sul PC con Windows XP che scheda video hai? Se è ATI ho NVIDIA ed hai installato i driver che forniscono loro mi sembra strana quella dimensione del kernel, non è che hai guardato solo la RAM paginata?

[Dott.Wisem]

Originariamente inviato da sirus

[...]Sul PC con Windows XP che scheda video hai? Se è ATI ho NVIDIA ed hai installato i driver che forniscono loro mi sembra strana quella dimensione del kernel, non è che hai guardato solo la RAM paginata?

No no, ho guardato la ram totale occupata dal kernel, data dalla somma fra memoria di paging e non di paging. La scheda video, come già detto, è una 9800Pro. I driver sono gli Omega, che sono dei Catalyst con pannello di controllo classico (invece di quel pachiderma del Catalyst Control Center) e qualche ottimizzazione relativamente alla qualità visiva (generalmente gli Omega sono impostati di default per darti un po' di qualità in più, a scapito di qualche frame). Comunque il Catalyst Control Center è un'applicazione user-mode (scritta in NET 2.0), quindi non c'entra nulla.
Ho provato anche su altre macchine XP dotate di 512MB o meno, e l'occupazione di memoria totale del kernel scende fino a 16MB...

[sirus]

Originariamente inviato da Dott.Wisem

No no, ho guardato la ram totale occupata dal kernel, data dalla somma fra memoria di paging e non di paging. La scheda video, come già detto, è una 9800Pro. I driver sono gli Omega, che sono dei Catalyst con pannello di controllo classico (invece di quel pachiderma del Catalyst Control Center) e qualche ottimizzazione relativamente alla qualità visiva (generalmente gli Omega sono impostati di default per darti un po' di qualità in più, a scapito di qualche frame). Comunque il Catalyst Control Center è un'applicazione user-mode (scritta in NET 2.0), quindi non c'entra nulla.
Ho provato anche su altre macchine XP dotate di 512MB o meno, e l'occupazione di memoria totale del kernel scende fino a 16MB...

Non pensavo dipendesse dalla memoria RAM.

[II ARROWS]

Driver Bootcamp?
Mi spieghereste che significa? Cioè, per far girare XP o Vista su un Mac che devo fare su Bootcamp?