HN user

vvhn

307 karma
Posts1
Comments135
View on HN

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

The iPhones 8 9 years ago

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 ?

1 https://developer.apple.com/library/content/documentation/Fi...

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 .

APFS in Detail 10 years ago

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 "

APFS in Detail 10 years ago

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)

Also: https://xkcd.com/927/

The standard is the interface ( POSIX / SUS ) and unless APFS breaks that how is this applicable ?

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

( http://newdelhi.usembassy.gov/immigrant_visas.html )

Wikipedia also fails to provide anything other than family based immigration.

( http://en.wikipedia.org/wiki/History_of_laws_concerning_immi... )

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).

Contrary to speculation ( there are whole articles which "explain" the secure enclave to be ARM trustzone) secure enclave is documented ( only very recently) to be a _seperate_ chip inside the A7 chip running it's own L4 based microkernel. (From https://www.apple.com/privacy/docs/iOS_Security_Guide_Sept_2...)

" The Secure Enclave is a coprocessor fabricated in the Apple A7 or later A-series processor. It utilizes its own secure boot and personalized software update separate from the application processor. It provides all cryptographic operations for Data Protection key management and maintains the integrity of Data Protection even if the kernel has 
 been compromised.

The Secure Enclave uses encrypted memory and includes a hardware random number generator. Its microkernel is based on the L4 family, with modifications by Apple. Communication between the Secure Enclave and the application processor is isolated 
 to an interrupt-driven mailbox and shared memory data buffers. "

You're right about this being a iOS 8 bug, i haven't tried your keyboard yet but have swype installed and it frequently fails to show up in things ( mainly spotlight for me )

They work in the US ( and perhaps some other "first world" countries ) but in places like India, data for even big cities is practically non existent while Google Maps has everything ( and up to date ).

And here comes the problem: SCTP is not used, even for projects where those features are needed.

sctp's achilles heel is its inability to work with NAT. It was designed to not work with NAT. NAT has since become widespread especially for connecting homes and sctp ended up not being so.

(Nexus vs. iPhone, etc).

To be completely accurate - Nexus phones are an exception. Even the manufacturer of Nexus phones sells their non Google branded Nexus equivalent models at significantly higher cost. There is nothing else in the market priced like a Nexus phone (probably because no one can sell these devices at cost because they don't have the cushion of massive ad revenues).