Hacker News Reader

Comment by pflats | Hacker News Reader

Initially, I was thinking the same thing. Given how fast the average Apple consumer updates to major iOS releases, I imagine that rolling it out over a point release is actually part of the plan.

Presumably, if something does go wrong on the individual level, the support burden on the genius bars will be lower (since major iOS releases have traditionally come alongside hardware releases), and if a major bug is found, the number of devices affected will also likely be smaller.

It stills feels wrong on a gut level, and semver folks might not be happy with it, but it seems to make some real sense.

edit: Also, if it went out with 11.0, coordinating all the bug fixes for a 11.0.1 would almost definitely take longer than whatever will be in 10.3.1 release, letting any APFS issues get tweaked faster.

View on HN

Additionally, it may be a way of hedging their bets. If it all goes smoothly, great. However, if it turned into a big flaming dumpster fire, an iOS point release has a lot less to lose than a major release (and the associated new hardware that comes with one).

"iOS Update Causes Widespread Outages" plays a lot differently with the average person on the street (who already distrusts software updates in general) than "New iPhone Fundamentally Flawed". Feel free to craft your own hyperbolic headlines, but hopefully you get the idea.

If there is any way to link software issues with an iPhone launch, media outlets will do it to grab views from people considering a purchase (i.e., damage to the product launch). The same isn't true of an update; it damages the perception of the ecosystem, but most people don't even know what a software ecosystem is.

Of course they know... They always get buggy upgrade on games and ironically, thanks to them, people are more or less used to buggy upgrades and may not freak out in those events.

> It stills feels wrong on a gut level, and semver folks might not be happy with it, but it seems to make some real sense.

If you maintain the public API, it's perfectly valid to radically change the implementation details in a point release.

If you're not going to respect the encapsulation of that kind of working knowledge behind an API, then you might as well just demand the very release of everything should be a Major version release.

> It stills feels wrong on a gut level, and semver folks might not be happy with it, but it seems to make some real sense.

Wouldn't this be valid semver if the APIs or general functionality hasn't changed? Or isn't expected to?

I'm far from an expert on file systems or semantic versioning, but the one thing I've heard is that APFS changes the way filenames are written to and read from disk. HFS+ (the old file system Apple OSes used) would automatically normalize file names so you couldn't have two files with names that look the same to a user but are represented with different byte sequences. APFS does not do this on the file-system level. (I heard thirdhand that some APIs might still do the normalization, but I don't have any links or details on that and don't want to spread bad info.)

http://mjtsai.com/blog/2017/03/24/apfss-bag-of-bytes-filenam...

Rolling it out first on iOS at all doesn't seem like the right approach.

If I were somehow in charge of it, I imagine I'd want to do it like: 1) ship it as officially supported on the Mac, but off by default. 2) a year or two later, ship it as officially supported on the Mac, on by default, but still allow HFS+ as an option. 3) A year or two after that, if all has gone well, then introduce it into iOS (where presumably it's not reasonable to make it optional).

It's really weird to me that Apple is rolling it out to hundreds of millions of devices all at once, when it's not even a bootable filesystem on any of their platforms yet. Seems like the kind of thing where you'd want to take a more gradual approach.

I get that HFS+ is super old and I see why Apple wants to switch to APFS. But I don't get why they're in such a hurry.

Here's hoping their approach works well, in any case!

The iOS filesystem environment is WAY more controlled than OS X. Updating OS X first would be fewer machines but is the much more difficult task. This would also be one hell of a production test. They obviously think they're ready.

>If I were somehow in charge of it, I imagine I'd want to do it like: 1) ship it as officially supported on the Mac, but off by default. 2) a year or two later, ship it as officially supported on the Mac, on by default, but still allow HFS+ as an option. 3) A year or two after that, if all has gone well, then introduce it into iOS (where presumably it's not reasonable to make it optional

The plan doesn't make much sense. For one, the Mac has way more edge cases than iOS (in that people do more, and in more low- and -high level ways) with the filesystem, including running all kinds of unix userlands, exchanging files with other filesystems, etc. In iOS all fs APIs and access are tightly controlled, and there's no mounting of disks, no touching outside the sandbox, no disk management apps, etc.

So iOS is a much better target for first launch than OS X.

Second, with this plan it would take 3-5 years to ever arrive. Why so late? Apple has been developing it for a while, and probably have thousands of tests it has to pass. And they have been running it on 1 million or more devs on the 10.3 beta program on actual devices for feedback for 2 months.

3-5 years seems to be pretty typical for a filesystem to go from merely available to being battle tested enough to use without thinking about it. Bugs could destroy people's data (and the cloud won't necessarily help if the bugs corrupt data rather than erase it). What's the hurry?

>Bugs could destroy people's data (and the cloud won't necessarily help if the bugs corrupt data rather than erase it).

There's no reason to expect bugs if you have a comprehensive test suite and extensive internal and beta testing (like with a million of registered iOS developers running it for months).

Doubly so if you control most of the APIs and interactions with the OS tightly in your platform (as iOS does).

Which is why the rest of iOS has no bugs?

This statement makes me wonder, have you written any software before?

>Which is why the rest of iOS has no bugs?

It has no show stopper bugs, and is used by close to a billion everyday just fine.

And the "rest of the iOS" (kernel, userland, etc) is orders of magnitude more LOC than the filesystem. And with all kind of interactions between components, not just a constrained API that all sandboxed apps use, as is the case with an FS. It has way bigger test surface and (presumably) way smaller test suites than an FS would.

What's the reason to assume an FS which is under production for 2 years now at least (it didn't appear magically formed a day before last WWDC) will have not just some obscure or infrequent bugs, but data killing bugs?

(And why they'd be more than with the frequent new features and changes that Apple made/retrofitted to HFS over the years? Because they've started from scratch?)

Because software has bugs, filesystem software has data corruption bugs, and two years of development with only a couple of months of serious real-world testing is tiny for something like that.

What other filesystems have gone from zero to being the only supported option on their platform in such a short time? ZFS took almost five years. HFS+ was supported in parallel with HFS for a long time.

"And why they'd be more than with the frequent new features and changes that Apple made/retrofitted to HFS over the years? Because they've started from scratch?"

Once again I have to wonder: have you written software before? Of course a brand new from-scratch effort will be buggier than something with a long history.

>Once again I have to wonder: have you written software before?

Yes, for several decades -- though not filesystems.

And I trivially know that software can always have bugs. I also know software has to ship at some point, and that is a different point than the "we're 100% sure it has 0 bugs" point -- which is not possible anyway.

I also don't believe in some cargo cult "optimal necessary period of testing" to make sure a given piece of software has or doesn't have bugs.

I also know that it's perfectly possible to have 10x the testing in 1/10 the time other teams/companies might take for their tests -- (e.g. by having far heavier test suites, more intelligent tests, better fuzzing, more systems to test on in your labs, more QA engineers thrown at the problem, or even formally proving your software's behavior) .

Finally, I can make ad hominem arguments too: have you wrote and deployed any filesystems before? If the domain experts designing AFS are confident to put it in use why we should trust you? Because of your scientific observations of checking how long other companies took to deploy their new filesystems and extrapolating some BS "optimal deployment time" from that?

In any case, maybe visit back this thread in 1 month? If the sky hasn't fallen for iOS 10.3 users (except, at worse, for some edge cases affecting tiny minorities/uncommon setups), maybe you'll be ready for your serving of crow?

I knew this argument would be made.

Why should you believe me instead of the people writing APFS? You shouldn't. I'm stating my opinion on the matter. I'm allowed to disagree with them, and you're allowed to disagree with me, but "Apple thinks it's OK" is not going to convince me. If it was, then I wouldn't have formed a contrary opinion in the first place, since it's so obvious.

Further, we don't even know if the experts are confident. It's entirely possible this decision was made above them and forced on them. It's also entirely possible it wasn't, we just don't know.

In any case, if everything goes smoothly (and I hope it will), that doesn't disprove me. It could mean that you're right, or it could mean that I'm right and they got lucky. It could also mean that some people are losing data, but not visibly enough and not in large enough number to make the news.

You say "except, at worse, for some edge cases affecting tiny minorities/uncommon setups" as if that would justify Apple's approach. That's exactly the kind of thing I'm worried about here. I have no doubt it'll work for the common case. 99.9% of users will not suffer any problems. But I don't see why pushing APFS now as opposed to in a few years is worth the risk of that 0.1%.

>In any case, if everything goes smoothly (and I hope it will), that doesn't disprove me.

Doesn't that make your case an empty statement that basically amounts to "you can never be too careful" (and which is always right, no matter the outcome)?

>But I don't see why pushing APFS now as opposed to in a few years is worth the risk of that 0.1%.

Because it improves lots of things with the 99.9% -- SSD utilization, better Time Machine, etc.

iOS has always used case-sensitive HFS, while macs usually need case-insensitive HFS. Since it looks like APFS will drop support for the case-insensitive file system mode, it makes sense to do the forced upgrade on the system that already uses a case-sensitive file system (= iOS).

Plus, it's more straightforward recovering from a broken FS upgrade on iOS since many customers will have iCloud backups enabled, or at least their data stored on iCloud drive, while a mac filled to the brim with all sorts of strange applications and files spread all over the filesystem, likely never been backed up properly, is a tougher call.

I don't have a source, and too tired to look it up. But I thought I saw someone back away who found some tucked away support in APFS for case insensitive file support on macOS.

Maybe misremembering. But someone had hacked it to run as a boot drive, and in doing so, found the setting.

The problem with supporting APFS and HFS+ at the same time is that FileVault and Time Machine need to be very different on APFS.

FileVault can take advantage of the transparent encryption feature of APFS and TimeMachine can simply backup a snapshot of the file system.

I don't know if Apple (who likes to drop things) will support both concepts.

Also the reason why I assume that APFS will be coming to macOS in the next major release and not in a point release.

What do they care about macOS? I need to see desktops revealed soon.

Reply on news.ycombinator.com