Newsgroup: it.comp.macintosh
Titolo: La fretta di Apple

Hanno rilasciato Big Sur con l'evidente fretta di sdoganare i nuovi M1.
Ho avuto modo di provare un nuovo macbook pro m1 ed effettivamente offre 
ottime prestazioni, anche se si trattava della versione più economica.
Lo stesso non si può dire dell'uso su un relativamente recente imac 27" 
con fusion drive, anche se ben dotato di cpu e ram. Sembra infatti che 
big sur non vada molto d'accordo con i fusion, mentre si trova 
completamente a suo agio su dischi ssd.
Ieri è già stato rilasciato il primo aggiornamento (oltre 3gb) che ho 
installato senza problemi nel mio hackintosh, ma che il mio amico con il 
27" + fusion drive non ha ancora ricevuto. Speriamo sistemi un po' le 
faccende, visto che l'utilizzo di un imac con i7 4.2ghz e oltre 40gb di 
ram è - di fatto - imbarazzante...
 
 
 
 
 
-- 
__________________________________________
 
Merely Job: 
http://www.sergiotressino.it/
 
Leisure: 
http://trextrips.altervista.org/
 
__________________________________________

 
 
Io con 27” late 2015 (32GB RAM + fusion drive) ho notato:
 
1. Molto più lento di Catalina in partenza: dal login all’unanimità passa
un secolo. Prima no. 
 
2. Frequenti crash di safari. 
 
In compenso con Catalogna avevo fatto il record del mondo di kernel
panic!!!!
Quindi nel complesso non rimpiango il vecchio macOS, e spero che alcuni
aspetti vengano smussati al primo update. 
A proposito: ma di che aggiornamento parli??
Non lo vede il Mac né ho trovato indicazioni su siti specializzati. Non è
che hai scaricato la beta?
 
-- 
P@olo

 
 
No, non ho scaricato nessuna beta. Sulle info campeggia un normalissimo 
"macOS Big Sur versione 11.1", mentre prima - se non ricordo male - era 
11.0.1


 11.0.1
 
Boh, mi risulta che la 11.1 sia in versione release candidate distribuita
solo agli sviluppatori. 
 
 
 
-- 
P@olo

 
 
Ed hai pure ragione! Mi sono accorto di essermi registrato come 
sviluppatore con questo hackintosh (ne ho più d'uno) molto tempo fa. Me 
l'ero scordato ed avendolo ricevuto come aggiornamento automatico, 
pensavo fosse rilasciato. Invece mi è bastato fare un rapido 
controllo... porta pazienza :-)
https://app.box.com/s/unxhez26os3wyf157nmvcd2nn1tdzm3u
 


 11.0.1
Il primo sistema per passare al nuovo macOS, è il 1x.x.3
Per anni ho rispettato questa filosofia, e non mi ha mai tradito. Ora mi
tengo duro Mojave, fin quando posso.
 
-- 
Per rispondere, togliere -NOSPAM- dall'indirizzo.

 
 
Direi che, per chi ha un computer con cui ci deve lavorare, è una saggia 
scelta. Ma io uso l'hackintosh solo per sperimentare ed eventualmente 
per assemblarne qualcuno agli amici, per cui anche se ci sono 
"malfunzionamenti giovanili" non mi sento per nulla preoccupato. Ad ogni 
modo, stranamente, spesso va meglio il mio hackintosh rispetto ai reali 
mac (imac, macbook, mac pro) che vedo usare a conoscenti ed amici, ai 
quali mi capita di dover metter mano per risolvergli i non pochi 
problemi che un apple "non dovrebbe avere"...


 reali mac
In effetti questo è piuttosto strano e non dovrebbe essere così. Ma c'è
anche il "fattore umano", ovvero chi utilizza il computer. Per mia
esperienza ho diverso hardware Apple e anche un hackintosh, sul quale ho
sicuramente più problemi che sui vari Apple. Non che questi ne siano
esenti, sopratutto se come ho fatto io, gli installi degli OS non più
supportati per quell'hardware. Ma non ho mai visto i casini che altri
riescono ad avere su dei Mac originali. E si tratta tutta di gente che
dice di usare quelle poche cose, e non aver toccato niente di "strano".
 
 
-- 
Per contattarmi, togliere -NOSPAM- dall'indirizzo.
To contact me, remove -NOSPAM- from address.

 
 
Eh, ma quando c'è qualcosa che non va in un computer (non importa se pc 
o mac) l'utente non ha mai "fatto niente" :-D
E' sempre colpa di qualcos'altro, di forze oscure o energie astrali. Ma, 
come si dice da sempre, i maggiori problemi di un computer sono spesso 
posizionati tra il monitor e la sedia ;-)


 ram è - di fatto - imbarazzante...
 
 
"La fretta di Apple" anche tu non è che scherzi eh ?!
 
:D
 
 
-- 
Sent from Win10

 
 
Mi ci vedo "costretto" mio malgrado... il mio si potrebbe definire quasi 
un servizio pubblico, rivolto ad amici e vecchi clienti :-D


 Ora mi tengo duro Mojave, fin quando posso.
 
Saggia decisione: la stessa mia.
 
Questo mi fa credere di non essere l'unico a pensare che ci sia qualcosa
di fortemente sbagliato in un sistema operativo che ha bisogno di oltre
12GB di file di installazione e oltre 3GB di file di aggiornamento...
 
-- 
Jey
-- 
Non prendere la vita troppo sul serio... non ne uscirai mai vivo
http://www.joram.it/servizi/consulente.htm
 

 bisogno di oltre 12GB
Immagino che molto sia dovuto al doppio codice i386/ARM. Sarebbe
interessante mettere su un Mac M1 un disco con BigSur installato su un
Mac Intel (o viceversa), per vedere se funziona normalmente (questo
confermerebbe la mia teoria).
Ho visto altri software, che con "l'ottimizzazione" per Apple Silicon
sono diventati grossi quasi il doppio della versione precedente. Spero
che a breve escano dei tool per "ripulire" le architetture inutili, come
c'erano ai tempi del passaggio da PPC ad Intel. Ho installato BigSur in
una VM con Fusion 11.5.7 (anche se non ufficialmente supportato), e mi
trovo con disco virtuale che anche una volta compattato supera i 25GB!


 
 
Io ho delle vm con Catalina che ho creato con lo storage minimo suggerito a
vmware: 40GB. 
Ho provato a fare l’upgrade a Big Sur: oggi l’OS occupa circa 15GB. Anche
mettendo l’installer su altra partizione, lo spazio libero non è
sufficiente per l’installazione. 
Ho provato ad ampliare il disco (fino a 65GB, o 60 non ricordo). A quel
punto l’upgrade va in porto, ma poi mi trovi con un disco molto più grande
la cui occupazione a regime è simile a quella di Catalina.
Quei 25GB in più non servono a nulla e fusion non me lo fa togliere
 
 
-- 
P@olo


è fuori per tutti
 

 Quei 25GB in più non servono a nulla e fusion non me lo fa togliere
C'è una procedura con dei comandi da Terminale, prima all'interno della
VM, e poi dall'host. Per quanto ho potuto verificare, funziona da
SnowLeopard a BigSur. Da usare con cognizione di causa, non assumo
responsabilità per eventuali problemi.
 
Nel sistema guest:
 
cat /dev/zero > wipefile; rm wipefile
 
Nel sistema host (dopo aver spento la VM):
 
/Applications/VMware\ Fusion.app/Contents/Library/vmware-vdiskmanager -k
<Pathname to the Virtual Hard Disk>



Ho provato. 
Ho ampliato il disco dalla consolle di fusion (40->60). 
Ho avviato la macchina e aumentato la partizione Gino ad occupare tutto lo
spazio disponibile. 
Poi ho riavviato e fatto l’operazione inversa: ridotta la partizione e poi
avviati i 2 comandi che hai scritto. 
Il file vmdk si riduce, ma la consolle di vmware continua a vedere il disco
virtuale da 60
 
-- 
P@olo

 Ho ampliato il disco dalla consolle di fusion (40->60). 
Non ci siamo capiti: il comando serve per ridurre le dimensioni
effettive del file vmdk che si gonfia con l'uso entro i limiti
impostati. Quello a cui ti riferisci tu, credo che sia proprio
l'impostazione dei limiti.
L'azione dei due comandi che ti ho scritto la puoi vedere dal sistema
host (con il finder o da terminale) o dal pannello "Generale" della
console (Mela-I).
Tra l'altro i comandi funzionano anche con guest Linux.


 > cat /dev/zero > wipefile; rm wipefile
Prima di spegnere la VM, accertati che il comando sia terminato: lo vedi
sia dal fatto che hai la CLI a disposizione per impartire nuovi comandi
sia dal fatto che venga cancellato il file wipefile che si crea nel
percorso in cui sei quando lanci il comando. Se per caso il file
wipefile non si cancella (e sei sicuro che il comando sia terminato),
eliminalo manualmente prima di spegnere la VM.


 
 
Ok quindi tu dici che io dovrei aumentare il disco a 60 da vmware. Fare
tutto quello che serve e poi tramite i comandi riduco l’occupazione reale
del vmdk pur lasciando che fusion veda la vm con uno storage da 60. 
Ho capito bene?
Se è così a livello di OS posso fare in modo di mantenere la partizione da
40 in modo che gli altri 20 in realtà non vengano mai usati
 
-- 
P@olo

 40 in modo che gli altri 20 in realtà non vengano mai usati
Ci ho giocato un po' oggi... sembra che non ci sia modo di ridurre il
limite di un disco virtuale.
Pertanto credo che l'unico modo sia creare un secondo disco vuoto da
40GB con VMware, formattarlo da BigSur guest e copiare tutto contenuto
dal disco di 60 a quello di 40 con CarbonCopyCloner (o simili). Poi
spegni la VM, abiliti il disco da 40 per il boot e rimuovi il disco da
60 (tutto da console VMware). In passato l'ho già fatto con altre VM
(create virtualizzando alcune macchine reali). Ma non so quanto valga la
pena nel tuo caso, in quanto applicando i comandi che ti ho scritto, le
VM occupano grossomodo lo stesso spazio sul disco host (in base ai dati
effettivamente contenuti), ma con il disco limitato a 40GB potresti
arrivare a riempirlo durante qualche operazione ed avere problemi di
disco esaurito... a quel punto dovresti tornare ad estenderlo con VMware
e saresti d'accapo.
Diciamo che se hai problemi di spazio sul disco dell'host, ti conviene
tenere controllata la dimensione della VM quando la usi, e sopratutto se
ci movimenti grosse quantità di file, e se si gonfia troppo, applicare i
comandi che ti ho scritto. Un paio di GB si gonfi in fretta, e non è il
caso di perderci tempo; se comincia a gonfiarsi di 5-10GB, la
ridimensioni.



Ho seguito le tue indicazioni: sembra abbia funzionato piuttosto bene. 
Grazie
 
-- 
P@olo