APFS doesn’t “prefer” anything - it it will not change the bytes passed to NFC or NFD. The bytes passed for creation are stored as is ( HFS will store the NFD form on disk if you pass the NFC form to it). However APFS is normalization insensitive (if you create a NFC name on disk , you won’t be able to create the NFD version and you will be able to the name by both the NFC and NFD variants) just as HFS is - they both use different mechanisms to achieve normalization insensitivity.
USB4 is essentially a branding strategy around the USB C connector which with tunneling various standards (USB 3.2 , thunderbolt ) and speeds. Some are required and some are optional to get branded as USB4.
>It was a GC via marriage though, rules ma be different for employer sponsored GCs
Rules are indeed different for Employment based green cards. Marriage based green cards don't have a limit while the number of employment based Green cards that can be given out in a year is fixed ( in total and within that there is a 7% cap on how much each individual country can receive)
People stuck this way from India & China aren't even able to file for GC's. You can only file for a GC if your country's date is "current" (which is not the case for marriage based GC)
Their only legal basis to stay in the US is the H1-B which they can keep on renewing because they have an approved I-140. In my current situation, i have an approved immigrant petition and i will have to continue to get H1-Bs approved
till i get current (which current projections are about 40-50
years). I've been in the US for a decade and it will be many many decades before i can remove the dependence on the H1.
The math is simple - there are about 400K Indians with approved immigrant petitions. And across 2 categories the maximum number of green cards that Indians can receive in a year is about ~6K. Each petition is roughly 2 green cards
So if an Indian gets an immigrant visa approved today in 2020 , they're looking at wait of 800/6 (133) years even be able to file for a green card.
Space shared APFS volumes inside a container give you the “table partitioning” you want. You can even set them up to have different case sensitivity options. All your dev work in a case sensitive volume for instance and Adobe software on a case insensitive volume on the same space shared container.
Well, APFS is much better suited to this kind of workflow. Create a space shared logical volume inside your container and turn spotlight off on that particular volume (and if you’d like, make that volume case sensitive ). There’s no need to separate that out on a diskimage
There’s some interesting pricing games being played by Apple. For all new models, The 256GB price is the same, the 128GB and 32GB have been eliminated and in their place a single 64GB model in between ( 700 ) the price of the 32 ( 649 ) and the 64 (749 ). Personally the 128 GB was the sweet spot - 32/64 are too little and 256 is too much
The "chilling series of messages" takes you to a link which details how File sharing through iTunes on Windows specifically was affected and that a similar file transfer product on Windows iMazing was able to fix to fix it by simply normalizing before transferring.
( The "bag of bytes" response from Apple asks developers to do exactly that btw )
That begs the question that why iTunes itself ( on Windows ) wasn't able to do the same thing as iMazing ?
Anyway that's moot now - As mentioned earlier in this thread iOS 10.3.3 and iOS 11 are changing behaviour w.r.t. this.
>from APFS-normalization-preserving to APFS-native-normalization.
The developer documentation at [1]
seems to suggest that "native" normalization is normalization preserving as well and that native normalization is based on storing the hash of the normalized name instead of storing the normalized name itself.
"
and preserves both case and normalization of the filename on disk in all variants.
"
and
"
APFS preserves the normalization of the filename and uses hashes of the normalized form of the filename to provide normalization insensitivity, whereas HFS+ stores the normalized form of the filename on disk to provide normalization insensitivity.
"
edit - Even the linked blog post says the same thing
"
macOS 10.13 will also support case-sensitive APFS, which will use native normalization. This is new in the developer beta. The filenames are still stored in the same way as prior APFS (not normalized like with HFS+), but APFS now uses normalization-insensitive hashes ...
"
>how this unicode normalization messes up filenames and cause duplicates and stale copies when roundtripping
Being normalization preserving should fix that, right ?
>Imagine any non-English speaking person entering a non-ascii name for their document
You mean there are people in Europe, China, Japan, India running into widespread problems when they create filenames in their own language in iOS 10.3+ ?
That's only true of GPL'ed components shipped as part of Mac OS X/ OS X / macOS. A vast majority isn't - some are BSD and most are Apple originated software under an Apple Open Source License (APSL)
If you closely enough at the spec, it is unclear if this actually a violation.
Also, according to the developer, this same behavior was present from 10.3 to 10.9 ( Apple was certified to be compliant from 10.5 onwards which tells you that this isn't non conformant) and OS X did not even ship with a poll(2) implementation before 10.3 .
From the 2nd edition of "The Design and Implementation of the FreeBSD Operating System"
ZFS, Pg 549
"
However it is not designed for or well suited to run on resource constrained systems using 32 bit CPUs with less than
8 Gbyte of memory and one small nearly full disk, which is typical of many embedded systems
"
>and this adds to the overall support overhead of all operating systems that want to be compatible with Apple devices.
What operating systems describe tremselves as being "compatible with Apple devices"
> Since the older versions of macOS (OSX) don't support APFS, only HFS+, this means Apple and others will also have to continue supporting HFS+.
Who else actually "supports" HFS+ ? Sure there are linux "ports" based on the spec but nobody claims them as being "supported".
Apple would have had to continue supporting HFS+ whether they chose to implement ZFS, btrfs or HAMMER.
>It just seems wasteful of everyone's time to me.
I don't know how Apple writing their own filesystem is wasteful of anybody else's time ( except possibly Apple's and/or Disk utility software for vendors for OS X)
>There's standard, normalized ways immigrants have come to the US for a long time now
Just out of curiosity, what are the "standard, normalized ways " that people immigrate to the US ? If i were to go to the American Embassy in New Delhi and apply for immigration and i don't have close, immediate family in the United States i don't see a way other than becoming a Fiance of a US citizen
You can put a different SIM in it. The device (in this case the iPad) itself isn't locked to a carrier. The Apple SIM was only an additional convenience in that you didn't even have to put in a new SIM in it (i.e. the same SIM could be used on multiple carriers) to change carriers.
However, that's currently effectively limited to 3 carriers now (2 US and 1 UK) with AT&T effectively making it non - reprogrammable SIM if activated on AT&T).