In article <sp258j$9go$1@dont-email.me>, Wade Garrett <Wade@cooler.net> wrote:
Better/easier to FileVault the new machine before or after transferring
data to it via Migration Assistant?
before will be much quicker since there's less to encrypt.
Better/easier to FileVault the new machine before or after transferring
data to it via Migration Assistant?
On 11 Dec 2021 at 13:41:19 GMT, nospam <nospam@nospam.invalid> wrote:
In article <sp258j$9go$1@dont-email.me>, Wade Garrett <Wade@cooler.net>
wrote:
Better/easier to FileVault the new machine before or after transferring
data to it via Migration Assistant?
before will be much quicker since there's less to encrypt.
Why filevault it in the first place?
Got a new Mac coming to replace my current one which has FileVault
turned on.
Better/easier to FileVault the new machine before or after transferring
data to it via Migration Assistant?
On 2021-12-11 09:04, TimS wrote:
On 11 Dec 2021 at 13:41:19 GMT, nospam <nospam@nospam.invalid> wrote:
In article <sp258j$9go$1@dont-email.me>, Wade Garrett <Wade@cooler.net>
wrote:
Better/easier to FileVault the new machine before or after transferring >>>> data to it via Migration Assistant?
before will be much quicker since there's less to encrypt.
Why filevault it in the first place?
Why _not_ filevault? It has a negligible effect on speed
and means you can dispose of the drive at end of life with no action
other than destroying the key.
Got a new Mac coming to replace my current one which has FileVault
turned on.
Better/easier to FileVault the new machine before or after transferring
data to it via Migration Assistant?
In message <Qu3tJ.45437$xe2.42948@fx16.iad> Alan Browne <bitbucket@blackhole.com> wrote:
On 2021-12-11 09:04, TimS wrote:
On 11 Dec 2021 at 13:41:19 GMT, nospam <nospam@nospam.invalid> wrote:
In article <sp258j$9go$1@dont-email.me>, Wade Garrett <Wade@cooler.net> >>>> wrote:
Better/easier to FileVault the new machine before or after transferring >>>>> data to it via Migration Assistant?
before will be much quicker since there's less to encrypt.
Why filevault it in the first place?
Why _not_ filevault? It has a negligible effect on speed
Zero effect on speed with any T2 machine or M1 machine.
On 2021-12-11 12:13, Lewis wrote:
In message <Qu3tJ.45437$xe2.42948@fx16.iad> Alan Browne <bitbucket@blackhole.com> wrote:
On 2021-12-11 09:04, TimS wrote:
On 11 Dec 2021 at 13:41:19 GMT, nospam <nospam@nospam.invalid> wrote:
In article <sp258j$9go$1@dont-email.me>, Wade Garrett <Wade@cooler.net> >>>>> wrote:
Better/easier to FileVault the new machine before or after transferring >>>>>> data to it via Migration Assistant?
before will be much quicker since there's less to encrypt.
Why filevault it in the first place?
Why _not_ filevault? It has a negligible effect on speed
Zero effect on speed with any T2 machine or M1 machine.
I'll test that next week with an external SSD.
In message <fF5tJ.23213$Pl1.18313@fx23.iad> Alan Browne <bitbucket@blackhole.com> wrote:
On 2021-12-11 12:13, Lewis wrote:
In message <Qu3tJ.45437$xe2.42948@fx16.iad> Alan Browne <bitbucket@blackhole.com> wrote:
On 2021-12-11 09:04, TimS wrote:
On 11 Dec 2021 at 13:41:19 GMT, nospam <nospam@nospam.invalid> wrote: >>>>>
In article <sp258j$9go$1@dont-email.me>, Wade Garrett <Wade@cooler.net> >>>>>> wrote:
Better/easier to FileVault the new machine before or after transferring >>>>>>> data to it via Migration Assistant?
before will be much quicker since there's less to encrypt.
Why filevault it in the first place?
Why _not_ filevault? It has a negligible effect on speed
Zero effect on speed with any T2 machine or M1 machine.
I'll test that next week with an external SSD.
Enabling file vault on external drives will still be slow. The instant process on the T2 and M1 machines applies to the internal boot drive.
On 11 Dec 2021 at 13:41:19 GMT, nospam <nospam@nospam.invalid> wrote:
In article <sp258j$9go$1@dont-email.me>, Wade Garrett <Wade@cooler.net>
wrote:
Better/easier to FileVault the new machine before or after transferring
data to it via Migration Assistant?
before will be much quicker since there's less to encrypt.
Why filevault it in the first place?
On 2021-12-11 14:49, Lewis wrote:
In message <fF5tJ.23213$Pl1.18313@fx23.iad> Alan Browne <bitbucket@blackhole.com> wrote:
On 2021-12-11 12:13, Lewis wrote:
In message <Qu3tJ.45437$xe2.42948@fx16.iad> Alan Browne <bitbucket@blackhole.com> wrote:
On 2021-12-11 09:04, TimS wrote:
On 11 Dec 2021 at 13:41:19 GMT, nospam <nospam@nospam.invalid> wrote: >>>>>>
In article <sp258j$9go$1@dont-email.me>, Wade Garrett <Wade@cooler.net> >>>>>>> wrote:
Better/easier to FileVault the new machine before or after transferring
data to it via Migration Assistant?
before will be much quicker since there's less to encrypt.
Why filevault it in the first place?
Why _not_ filevault? It has a negligible effect on speed
Zero effect on speed with any T2 machine or M1 machine.
I'll test that next week with an external SSD.
Enabling file vault on external drives will still be slow. The instant
process on the T2 and M1 machines applies to the internal boot drive.
If that's the case then it's pretty much un-testable for speed even if I start up that system with FV off:
"If FileVault isn’t enabled on a Mac with the T2 chip during the initial Setup Assistant process, the volume is still encrypted, but the volume
key is protected only by the hardware UID in the Secure Enclave. If
FileVault is enabled later — a process that is immediate since the data
was already encrypted — an anti-replay mechanism prevents the old key (based on hardware UID only) from being used to decrypt the volume. The volume is then protected by a combination of the user password with the hardware UID as previously described."
https://www.apple.com/mideast/mac/docs/Apple_T2_Security_Chip_Overview.pdf
I'll still do an external volume test - should still outpace the i7 iMac
on difference.
Got a new Mac coming to replace my current one which has FileVault turned on.
Better/easier to FileVault the new machine before or after transferring
data to it via Migration Assistant?
On 2021-12-11 12:23:45 +0000, Wade Garrett said:
Got a new Mac coming to replace my current one which has FileVault turned on.
Better/easier to FileVault the new machine before or after transferring
data to it via Migration Assistant?
Migration Assistant is always best used when you are going through the initial computer setting up process. Trying to do it afterwards can
cause issues with user ID conflicts.
In message <ed8tJ.22496$a24.15681@fx13.iad> Alan Browne <bitbucket@blackhole.com> wrote:
https://www.apple.com/mideast/mac/docs/Apple_T2_Security_Chip_Overview.pdf
Yes, I didn't recall the exact details because I just turn FileVault on
for all my machines.
I'll still do an external volume test - should still outpace the i7 iMac
on difference.
I would think so, I think the FileVault encryption is handled by the
neural engine.
In article <sp258j$9go$1@dont-email.me>, Wade Garrett <Wade@cooler.net> wrote:
Better/easier to FileVault the new machine before or after transferring data to it via Migration Assistant?
before will be much quicker since there's less to encrypt.
nospam <nospam@nospam.invalid> wrote:
In article <sp258j$9go$1@dont-email.me>, Wade Garrett <Wade@cooler.net>
wrote:
Better/easier to FileVault the new machine before or after transferring
data to it via Migration Assistant?
before will be much quicker since there's less to encrypt.
Ditto.
It's also good to test the drive out before dumping your datas into
it.
Got a new Mac coming to replace my current one which has FileVault
turned on.
Better/easier to FileVault the new machine before or after transferring
data to it via Migration Assistant?
Another reason to do it while migrating is an issue called Data
Remanence. When an unencrypted file is encrypted it is not re-written
in place on SSD drives but written somewhere else and then the original
is deleted. But when it's deleted it is not erased (destroyed). So
until something overwrites those sectors (blocks on an SSD), the
information is recoverable.
Those blocks will get clobbered at some point, to be sure. This is not acceptable for very secure requirements.
I've been searching through Apple docs and so far have found no mention
of this issue, so either it is handled and not mentioned, or it depends
on the blocks eventually being over-written. Apple are pretty
transparent with how they handle security and this I've yet to find.
Hope for the best. Plan for the worst. Encrypt on migration. Or fill
the rest of the drive with gibberish files and erase them after conversion.
Better: encrypt on migration.
(Ironically on spinning disk storage, write over in place is very
feasible; whereas on SSD it would be a desirable exception to wear
leveling strategies, but the logic of the storage device won't permit it).
In article <5JOtJ.122411$SW5.45782@fx45.iad>, Alan Browne <bitbucket@blackhole.com> wrote:
Another reason to do it while migrating is an issue called Data
Remanence. When an unencrypted file is encrypted it is not re-written
in place on SSD drives but written somewhere else and then the original
is deleted. But when it's deleted it is not erased (destroyed). So
until something overwrites those sectors (blocks on an SSD), the
information is recoverable.
only with substantial effort and expense.
Those blocks will get clobbered at some point, to be sure. This is not
acceptable for very secure requirements.
I've been searching through Apple docs and so far have found no mention
of this issue, so either it is handled and not mentioned, or it depends
on the blocks eventually being over-written. Apple are pretty
transparent with how they handle security and this I've yet to find.
that's a function of the ssd, not anything apple does.
it's also not possible to directly access the spare blocks, other than
via a forensic lab, i.e., substantial effort and expense.
Hope for the best. Plan for the worst. Encrypt on migration. Or fill
the rest of the drive with gibberish files and erase them after conversion.
filling the drive is unnecessary wear on an ssd and unless you're a
high profile target, overkill.
Better: encrypt on migration.
yep.
(Ironically on spinning disk storage, write over in place is very
feasible; whereas on SSD it would be a desirable exception to wear
leveling strategies, but the logic of the storage device won't permit it).
hard drives remap bad blocks and their contents remain.
On 2021-12-13 17:17, nospam wrote:
In article <5JOtJ.122411$SW5....@fx45.iad>, Alan Browne <bitb...@blackhole.com> wrote:
Another reason to do it while migrating is an issue called Data
Remanence. When an unencrypted file is encrypted it is not re-written
in place on SSD drives but written somewhere else and then the original
is deleted. But when it's deleted it is not erased (destroyed). So
until something overwrites those sectors (blocks on an SSD), the
information is recoverable.
only with substantial effort and expense.
Those blocks will get clobbered at some point, to be sure. This is not
acceptable for very secure requirements.
I've been searching through Apple docs and so far have found no mention
of this issue, so either it is handled and not mentioned, or it depends
on the blocks eventually being over-written. Apple are pretty
transparent with how they handle security and this I've yet to find.
that's a function of the ssd, not anything apple does.Apple are mute on the issue.
it's also not possible to directly access the spare blocks, other thanDue to TRIM perhaps, yes.
via a forensic lab, i.e., substantial effort and expense.
Hope for the best. Plan for the worst. Encrypt on migration. Or fill
the rest of the drive with gibberish files and erase them after conversion.
filling the drive is unnecessary wear on an ssd and unless you're a1 overwrite. The method is for the paranoid and won't affect the long
high profile target, overkill.
term by any serious amount.
Better: encrypt on migration.
yep.
(Ironically on spinning disk storage, write over in place is very
feasible; whereas on SSD it would be a desirable exception to wear
leveling strategies, but the logic of the storage device won't permit it).
hard drives remap bad blocks and their contents remain.Hardly relevant as bad blocks don't come into being very often ...
--
"...there are many humorous things in this world; among them the white
man's notion that he is less savage than the other savages."
-Samuel Clemens
Those blocks will get clobbered at some point, to be sure. This is not
acceptable for very secure requirements.
I've been searching through Apple docs and so far have found no mention
of this issue, so either it is handled and not mentioned, or it depends
on the blocks eventually being over-written. Apple are pretty
transparent with how they handle security and this I've yet to find.
that's a function of the ssd, not anything apple does.
Apple are mute on the issue.
it's also not possible to directly access the spare blocks, other than
via a forensic lab, i.e., substantial effort and expense.
Due to TRIM perhaps, yes.
Hope for the best. Plan for the worst. Encrypt on migration. Or fill
the rest of the drive with gibberish files and erase them after conversion.
filling the drive is unnecessary wear on an ssd and unless you're a
high profile target, overkill.
1 overwrite. The method is for the paranoid and won't affect the long
term by any serious amount.
(Ironically on spinning disk storage, write over in place is very
feasible; whereas on SSD it would be a desirable exception to wear
leveling strategies, but the logic of the storage device won't permit it).
hard drives remap bad blocks and their contents remain.
Hardly relevant as bad blocks don't come into being very often ...
On 2021-12-11 07:23, Wade Garrett wrote:
Got a new Mac coming to replace my current one which has FileVault
turned on.
Better/easier to FileVault the new machine before or after transferring
data to it via Migration Assistant?
Another reason to do it while migrating is an issue called Data
Remanence. When an unencrypted file is encrypted
In article <5JOtJ.122411$SW5.45782@fx45.iad>, Alan Browne <bitbucket@blackhole.com> wrote:
Another reason to do it while migrating is an issue called Data
Remanence. When an unencrypted file is encrypted it is not re-written
in place on SSD drives but written somewhere else and then the original
is deleted. But when it's deleted it is not erased (destroyed). So
until something overwrites those sectors (blocks on an SSD), the
information is recoverable.
only with substantial effort and expense.
Better: encrypt on migration.
yep.
In message <131220211717401043%nospam@nospam.invalid> nospam <nospam@nospam.invalid> wrote:
In article <5JOtJ.122411$SW5.45782@fx45.iad>, Alan Browne
<bitbucket@blackhole.com> wrote:
Another reason to do it while migrating is an issue called Data
Remanence. When an unencrypted file is encrypted it is not re-written
in place on SSD drives but written somewhere else and then the original
is deleted. But when it's deleted it is not erased (destroyed). So
until something overwrites those sectors (blocks on an SSD), the
information is recoverable.
only with substantial effort and expense.
It also really is not. The idea you can reassemble a file by gathering
random cells on an SSD is pretty much the definition of impossible.
Better: encrypt on migration.
yep.
Not on a recent Mac, it makes absolutely no difference.
On 12/11/21 9:04 AM, TimS wrote:
Why filevault it in the first place?
S.E.C.U.R.I.T.Y.
For your reference, records indicate that
Wade Garrett <Wade@cooler.net> wrote:
On 12/11/21 9:04 AM, TimS wrote:
Why filevault it in the first place?
S.E.C.U.R.I.T.Y.
OK, but be honest with yourself about your threat profile. Apple’s tools are fine if you only thoughtlessly play in the Apple ecosystem. Once you start using other technology, interoperable solutions are more useful.
It has never made sense for me to use Migration Assistant. Any data that
is important to me is not exclusively on my Mac (nor do I have just one
Mac). I have backups, and I’m better served by testing them with the new machine than just importing all the cruft that built up on my old machine.
Likewise, FileVault only serves to protect the Mac, not the data. I
always use it on laptops, due to their risk of being lost “in the wild”. But otherwise, data security is bigger than the Mac, and if you don’t
have a process in place that respects that, you’re quite likely to have your security compromised by some other lower-hanging fruit.
On 2021-12-13 21:36, Lewis wrote:
In message <131220211717401043%nospam@nospam.invalid> nospam <nospam@nospam.invalid> wrote:
In article <5JOtJ.122411$SW5.45782@fx45.iad>, Alan Browne
<bitbucket@blackhole.com> wrote:
Another reason to do it while migrating is an issue called Data
Remanence. When an unencrypted file is encrypted it is not re-written >>>> in place on SSD drives but written somewhere else and then the original >>>> is deleted. But when it's deleted it is not erased (destroyed). So
until something overwrites those sectors (blocks on an SSD), the
information is recoverable.
only with substantial effort and expense.
It also really is not. The idea you can reassemble a file by gathering
random cells on an SSD is pretty much the definition of impossible.
Better: encrypt on migration.
yep.
Not on a recent Mac, it makes absolutely no difference.
For a "drive recovery" (Drive removed from computer) that is correct.
But, if your laptop is stolen[1] and booted into Recovery Mode and
Target Disk Mode is used on the attack-Mac, then it would be as
transparent as a window without Filevault requiring the password...
The performance cost of Filevault on a T2/Mx Mac is negligible
and only carries the cost of a safe place for the password.
For your reference, records indicate that
Wade Garrett <Wade@cooler.net> wrote:
On 12/11/21 9:04 AM, TimS wrote:
Why filevault it in the first place?
S.E.C.U.R.I.T.Y.
OK, but be honest with yourself about your threat profile. Apple’s tools are fine if you only thoughtlessly play in the Apple ecosystem. Once you start using other technology, interoperable solutions are more useful.
It has never made sense for me to use Migration Assistant.
Any data that is important to me is not exclusively on my Mac (nor do
I have just one Mac). I have backups, and I’m better served by
testing them with the new machine than just importing all the cruft
that built up on my old machine.
Likewise, FileVault only serves to protect the Mac, not the data.
always use it on laptops, due to their risk of being lost “in the wild”. But otherwise, data security is bigger than the Mac, and if you don’t
have a process in place that respects that, you’re quite likely to have your security compromised by some other lower-hanging fruit.
In message <OYouJ.64137$zF3.3269@fx03.iad> Alan Browne <bitbucket@blackhole.com> wrote:
The performance cost of Filevault on a T2/Mx Mac is negligible
You keep repeating this mistake. It is *zero* performance cost.
and only carries the cost of a safe place for the password.
And you can use your account password as the key. I=Of course, have a
decent password on *ALL* accounts, but only a fool would not do that
anyway.
In message <nz7uJ.45660$xe2.1578@fx16.iad> Alan Browne <bitbucket@blackhole.com> wrote:
On 2021-12-13 21:36, Lewis wrote:
In message <131220211717401043%nospam@nospam.invalid> nospam <nospam@nospam.invalid> wrote:
In article <5JOtJ.122411$SW5.45782@fx45.iad>, Alan Browne
<bitbucket@blackhole.com> wrote:
Another reason to do it while migrating is an issue called Data
Remanence. When an unencrypted file is encrypted it is not re-written >>>>> in place on SSD drives but written somewhere else and then the original >>>>> is deleted. But when it's deleted it is not erased (destroyed). So >>>>> until something overwrites those sectors (blocks on an SSD), the
information is recoverable.
only with substantial effort and expense.
It also really is not. The idea you can reassemble a file by gathering
random cells on an SSD is pretty much the definition of impossible.
Better: encrypt on migration.
yep.
Not on a recent Mac, it makes absolutely no difference. [AAA] <---
For a "drive recovery" (Drive removed from computer) that is correct.
But, if your laptop is stolen[1] and booted into Recovery Mode and
Target Disk Mode is used on the attack-Mac, then it would be as
transparent as a window without Filevault requiring the password...
Which has noting to do with the time it takes to encrypt (none) or the so-called "data remembrance" bullshit above that you wrongly
interjected into this conversation without knowing what you are talking about.
There is NO REASON to not encrypt your drive on a modern Mac, it
literally costs noting at all, do difference in speed, no impact on the
data safety, nothing at all. It does not matter if you do it before or
On 2021-12-15 15:40, Lewis wrote:
In message <OYouJ.64137$zF3.3269@fx03.iad> Alan Browne <bitbucket@blackhole.com> wrote:
The performance cost of Filevault on a T2/Mx Mac is negligible
You keep repeating this mistake. It is *zero* performance cost.
Look up "negligible" and stop with the trifling answers.
On 2021-12-15 15:29, Lewis wrote:
In message <nz7uJ.45660$xe2.1578@fx16.iad> Alan Browne <bitbucket@blackhole.com> wrote:
On 2021-12-13 21:36, Lewis wrote:
In message <131220211717401043%nospam@nospam.invalid> nospam <nospam@nospam.invalid> wrote:
In article <5JOtJ.122411$SW5.45782@fx45.iad>, Alan Browne
<bitbucket@blackhole.com> wrote:
Another reason to do it while migrating is an issue called Data
Remanence. When an unencrypted file is encrypted it is not re-written >>>>>> in place on SSD drives but written somewhere else and then the original >>>>>> is deleted. But when it's deleted it is not erased (destroyed). So >>>>>> until something overwrites those sectors (blocks on an SSD), the
information is recoverable.
only with substantial effort and expense.
It also really is not. The idea you can reassemble a file by gathering >>>> random cells on an SSD is pretty much the definition of impossible.
Better: encrypt on migration.
yep.
Not on a recent Mac, it makes absolutely no difference. [AAA] <---
For a "drive recovery" (Drive removed from computer) that is correct.
But, if your laptop is stolen[1] and booted into Recovery Mode and
Target Disk Mode is used on the attack-Mac, then it would be as
transparent as a window without Filevault requiring the password...
Which has noting to do with the time it takes to encrypt (none) or the
so-called "data remembrance" bullshit above that you wrongly
interjected into this conversation without knowing what you are talking
about.
It is an issue with spinning mass. I had forgotten all the lovely
things that SSD/TRIM do. Big deal. Sorted out. Move on. That's what newsgroups are about.
There is NO REASON to not encrypt your drive on a modern Mac, it
Above: I said "Better: encrypt on migration."
Nospam said "yep"
Why, when I first replied to the fellow I said: "Filevault on and
Encrypt on migration. Negligible performance hit.".
You really need to cool yer jets before you hit the keyboard.
In message <MAsuJ.122613$aF1.119314@fx98.iad> Alan Browne <bitbucket@blackhole.com> wrote:
On 2021-12-15 15:40, Lewis wrote:
In message <OYouJ.64137$zF3.3269@fx03.iad> Alan Browne <bitbucket@blackhole.com> wrote:
The performance cost of Filevault on a T2/Mx Mac is negligible
You keep repeating this mistake. It is *zero* performance cost.
Look up "negligible" and stop with the trifling answers.
I know perfectly well what it mans, and it is not applicable here.
Negligible means there is a difference that *in your opinion) doesn’t matter, That is not the case, as there is NO difference.
Stop repeating the same error over and over, you are misleading people
and you are completely 100% wrong.
On 2021-12-15 22:48, Lewis wrote:
In message <MAsuJ.122613$aF1.119314@fx98.iad> Alan Browne <bitbucket@blackhole.com> wrote:
On 2021-12-15 15:40, Lewis wrote:
In message <OYouJ.64137$zF3.3269@fx03.iad> Alan Browne <bitbucket@blackhole.com> wrote:
The performance cost of Filevault on a T2/Mx Mac is negligible
You keep repeating this mistake. It is *zero* performance cost.
Look up "negligible" and stop with the trifling answers.
I know perfectly well what it mans, and it is not applicable here.
Negligible means there is a difference that *in your opinion) doesn’t
matter, That is not the case, as there is NO difference.
Stop repeating the same error over and over, you are misleading people
and you are completely 100% wrong.
No inline conversion can be 0 time. Very fast though.
In message <aAJuJ.155127$831.108568@fx40.iad> Alan Browne <bitbucket@blackhole.com> wrote:
On 2021-12-15 22:48, Lewis wrote:
In message <MAsuJ.122613$aF1.119314@fx98.iad> Alan Browne <bitbucket@blackhole.com> wrote:
On 2021-12-15 15:40, Lewis wrote:
In message <OYouJ.64137$zF3.3269@fx03.iad> Alan Browne <bitbucket@blackhole.com> wrote:
The performance cost of Filevault on a T2/Mx Mac is negligible
You keep repeating this mistake. It is *zero* performance cost.
Look up "negligible" and stop with the trifling answers.
I know perfectly well what it mans, and it is not applicable here.
Negligible means there is a difference that *in your opinion) doesn’t
matter, That is not the case, as there is NO difference.
Stop repeating the same error over and over, you are misleading people
and you are completely 100% wrong.
No inline conversion can be 0 time. Very fast though.
There is no "inline conversion". Stop making up things. If you do not understand what is happening, you can look it up instead of opining
nonsense.
In message <spd4qp$g7n$1@dont-email.me> Doc O'Leary <droleary@2017usenet1.subsume.com> wrote:
OK, but be honest with yourself about your threat profile. Apple’s tools are fine if you only thoughtlessly play in the Apple ecosystem. Once you start using other technology, interoperable solutions are more useful.
there's a meaningless paragraph.
It has never made sense for me to use Migration Assistant.
That seems like a PEBKAC problem to me, but you be you.
Any data that is important to me is not exclusively on my Mac (nor do
I have just one Mac). I have backups, and I’m better served by
testing them with the new machine than just importing all the cruft
that built up on my old machine.
Ah, the legendary 'cruft' bullshit. Spoken like a Windows user.
When I migrated my data to this new MBA I ended up with an exact copy of
what was on my other computer at the time, INCLUDING all the shell tools
I had installed, scripts I had written, preferences and nearly all
settings. It was then the task of a few minutes to delete things I did
not need to have on the laptop.
And yes, Migration Assistant is a perfectly good way to test your backups since the simplest way to migrate is to boot off your time machine
volume and migrate from it.
Likewise, FileVault only serves to protect the Mac, not the data.
What the fuck are you talking about? It protects *EVERYTHING* on the computer.
A lesser computer's inability to protect your data has nothing
whatsoever to do with macOS or FileVault.
For your reference, records indicate that
Lewis <g.kreme@kreme.dont-email.me> wrote:
In message <spd4qp$g7n$1@dont-email.me> Doc O'Leary <droleary@2017usenet1.subsume.com> wrote:
OK, but be honest with yourself about your threat profile. Apple’s tools
are fine if you only thoughtlessly play in the Apple ecosystem. Once you >> > start using other technology, interoperable solutions are more useful.
there's a meaningless paragraph.
Sorry to hear about your lack of technical know-how.
It has never made sense for me to use Migration Assistant.
That seems like a PEBKAC problem to me, but you be you.
Sorry to hear you have difficulty with perspective-taking.
Any data that is important to me is not exclusively on my Mac (nor do
I have just one Mac). I have backups, and I’m better served by
testing them with the new machine than just importing all the cruft
that built up on my old machine.
Ah, the legendary 'cruft' bullshit. Spoken like a Windows user.
Are you just here to troll, or what? I’ve been using Macs since the 80s.
All sorts of software comes and goes over decades of use, and I don’t need things like preference files, caches
around for no reason. I much prefer to curate my systems, and for me that means being able to start from scratch on a new setup without having to
rely on proprietary tools to carry everything forward. Again, sorry you
have trouble understanding things like that.
And yes, Migration Assistant is a perfectly good way to test your backups
since the simplest way to migrate is to boot off your time machine
volume and migrate from it.
Again, Apple-only solutions like Time Machine don’t work for those of us who *do* indeed need to venture outside the walled garden.
Likewise, FileVault only serves to protect the Mac, not the data.
What the fuck are you talking about? It protects *EVERYTHING* on the
computer.
Your words make me doubt that I can explain anything in a simple enough
manner for you to understand. Encryption simply is not the beginning
and end of data security.
A lesser computer's inability to protect your data has nothing
whatsoever to do with macOS or FileVault.
Very bad information indeed.
On 2021-12-16 16:58, Lewis wrote:
In message <aAJuJ.155127$831.108568@fx40.iad> Alan Browne <bitbucket@blackhole.com> wrote:
On 2021-12-15 22:48, Lewis wrote:
In message <MAsuJ.122613$aF1.119314@fx98.iad> Alan Browne <bitbucket@blackhole.com> wrote:
On 2021-12-15 15:40, Lewis wrote:
In message <OYouJ.64137$zF3.3269@fx03.iad> Alan Browne <bitbucket@blackhole.com> wrote:
The performance cost of Filevault on a T2/Mx Mac is negligible
You keep repeating this mistake. It is *zero* performance cost.
Look up "negligible" and stop with the trifling answers.
I know perfectly well what it mans, and it is not applicable here.
Negligible means there is a difference that *in your opinion) doesn’t >>>> matter, That is not the case, as there is NO difference.
Stop repeating the same error over and over, you are misleading people >>>> and you are completely 100% wrong.
No inline conversion can be 0 time. Very fast though.
There is no "inline conversion". Stop making up things. If you do not
understand what is happening, you can look it up instead of opining
nonsense.
Oh dear Lewis, you need to stop flinging stones.
Yes, I am in error for the case of a T2 or Mx processor
But of course it is inline conversion as it happens directly between the
CPU and the storage device: CPU ----> T2 ----> Storage.
In message <K4PuJ.40982$bo.22915@fx18.iad> Alan Browne <bitbucket@blackhole.com> wrote:
But of course it is inline conversion as it happens directly between the
CPU and the storage device: CPU ----> T2 ----> Storage.
No, because that is how data is ALWAYS routed on modern macs, so there is no "difference".
In message <K4PuJ.40982$bo.22915@fx18.iad> Alan Browne <bitbucket@blackhole.com> wrote:
On 2021-12-16 16:58, Lewis wrote:
In message <aAJuJ.155127$831.108568@fx40.iad> Alan Browne <bitbucket@blackhole.com> wrote:
On 2021-12-15 22:48, Lewis wrote:
In message <MAsuJ.122613$aF1.119314@fx98.iad> Alan Browne <bitbucket@blackhole.com> wrote:
On 2021-12-15 15:40, Lewis wrote:
In message <OYouJ.64137$zF3.3269@fx03.iad> Alan Browne <bitbucket@blackhole.com> wrote:
The performance cost of Filevault on a T2/Mx Mac is negligible
You keep repeating this mistake. It is *zero* performance cost.
Look up "negligible" and stop with the trifling answers.
I know perfectly well what it mans, and it is not applicable here.
Negligible means there is a difference that *in your opinion) doesn’t >>>>> matter, That is not the case, as there is NO difference.
Stop repeating the same error over and over, you are misleading people >>>>> and you are completely 100% wrong.
No inline conversion can be 0 time. Very fast though.
There is no "inline conversion". Stop making up things. If you do not
understand what is happening, you can look it up instead of opining
nonsense.
Oh dear Lewis, you need to stop flinging stones.
Yes, I am in error for the case of a T2 or Mx processor
Not just once, but over and over and over again.
But of course it is inline conversion as it happens directly between the
CPU and the storage device: CPU ----> T2 ----> Storage.
No, because that is how data is ALWAYS routed on modern macs, so there is no "difference".
Got a new Mac coming to replace my current one which has FileVault
turned on.
Better/easier to FileVault the new machine before or after transferring
data to it via Migration Assistant?
In message <spgpbl$qmq$1@dont-email.me> Doc O'Leary <droleary@2017usenet1.subsume.com> wrote:
For your reference, records indicate that
Lewis <g.kreme@kreme.dont-email.me> wrote:
In message <spd4qp$g7n$1@dont-email.me> Doc O'Leary <droleary@2017usenet1.subsume.com> wrote:
OK, but be honest with yourself about your threat profile. Apple’s toolsthere's a meaningless paragraph.
are fine if you only thoughtlessly play in the Apple ecosystem. Once you
start using other technology, interoperable solutions are more useful. >>
Sorry to hear about your lack of technical know-how.
You spout meaningless buzzword bingo nonsense it doesn't make it
"technical".
So, you have no fucking clue what migration assisstant does. Good to
know.
Again, Apple-only solutions like Time Machine don’t work for those of us who *do* indeed need to venture outside the walled garden.
Utter bullshit. I manage a group of FreeBSD servers and that does not
stop me at all from using my mac and my Mac's software.
What the fuck are you talking about? It protects *EVERYTHING* on the
computer.
Your words make me doubt that I can explain anything in a simple enough
Your words are idiocy. FileVault absolutely does protect the data. Your inability articulate coherent thoughts is a you problem.
manner for you to understand. Encryption simply is not the beginning
and end of data security.
No one claimed it was.
Why don't you try actually forming complete thoughts instead of vague nonsense that makes you feel like you know what you are talking about,
even a little bit.
For your reference, records indicate that
Lewis <g.kreme@kreme.dont-email.me> wrote:
In message <spgpbl$qmq$1@dont-email.me> Doc O'Leary <droleary@2017usenet1.subsume.com> wrote:
For your reference, records indicate that
Lewis <g.kreme@kreme.dont-email.me> wrote:
In message <spd4qp$g7n$1@dont-email.me> Doc O'Leary <droleary@2017usenet1.subsume.com> wrote:
OK, but be honest with yourself about your threat profile. Apple’s toolsthere's a meaningless paragraph.
are fine if you only thoughtlessly play in the Apple ecosystem. Once you
start using other technology, interoperable solutions are more useful. >> >>
Sorry to hear about your lack of technical know-how.
You spout meaningless buzzword bingo nonsense it doesn't make it
"technical".
What buzzwords am I using?
I'm sorry, I mistook you for being literate.
For your reference, records indicate that
Lewis <g.kreme@kreme.dont-email.me> wrote:
I'm sorry, I mistook you for being literate.
I’ve given you every opportunity to act more civil, and you have refused.
So trolling all the way into my killfile it is. Wait, is this you:
g.kreme@gmail.com
For your reference, records indicate that
Lewis <g.k...@kreme.dont-email.me> wrote:
I'm sorry, I mistook you for being literate.I’ve given you every opportunity to act more civil, and you have refused. So trolling all the way into my killfile it is. Wait, is this you:
g.k...@gmail.com
? I guess you’ve demonstrated your inability to act like an adult to me
in the past. Just the 35th entry, too, so you’ve intentionally been a
jerk for quite a while, haven’t you? That’s sad for you; I hope you find the help you need. Not sure when you nym-shifted (BTW, Usenet hasn’t be
a ripe target for spammers in 5+ years), but your new one is now resting comfortably next to the old one.
Shame on me for feeding the troll, though. I apologize to the group for thinking “Lewis” was worth engaging with.
--
"Also . . . I can kill you with my brain."
River Tam, Trash, Firefly
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 293 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 240:13:16 |
| Calls: | 6,624 |
| Files: | 12,173 |
| Messages: | 5,320,076 |