You're right: Yosemite is 10.10. Got me codenames mixed up there - I'll go fix it, ta! EDIT: No, t'was Apple wot got its codenames mixed up. The developer documentation clearly says 'OS X 10.11 Yosemite' in it. Exonerated! (But I'll still go fix, 'cos it's a mistake regardless of who is responsible.)
Yeah no kidding... and yet they made fun of Vista for being confusing Anyway I'm not really against the idea of APFS being only supported on 10.11 or newer. Seems to me that Apple wants to get rid of their old Core2 users (but is struggling to do so), and this filesystem gets them very slightly closer to doing that. I don't really care either way - MacOS is becoming less and less interesting every year since Lion.
Yes, but will it be case-sensitive? Compared to NTFS, ZFS and Ext4, Apple is truly playing catch-up at this point. Took them bloody long enough.
This is a company that insisted everyone call the 3rd gen iPad 'The New iPad', even after the 4th gen launched...
Uh... if anything needs to catch up, that would be NTFS. NTFS still requires to be defragmented, there are a good chunk of special characters that can't be used in filenames, it overall isn't as fast as alternative filesystems, it doesn't use checksums, it doesn't offer snapshots, I'm not aware if it supports journaling, and so on. Maybe some of that isn't true anymore and I just haven't been aware. Since they keep using the same name for over a decade, it's hard to keep track of what OS supports which features.
Defragmentation I'll give you. But NTFS offers volume shadow copy (copy-on-write), has always offered journaling, encryption, compression, etc.: https://en.wikipedia.org/wiki/NTFS Many of the limitations assigned to NTFS are often limitations of Windows, such as case-sensitivity. This becomes clear when new subsystems (like the new Linux subsystem in Win10) do not have such limitations. Of course, ZFS is far ahead of NTFS and Ext4, with self-healing capabilities and everything. It's what I use for my *BSD systems when possible, because it only makes sense.
The shadow copy, to my knowledge, needs to be explicitly specified per-file. Other filesystems such as btrfs just do it automatically using un-allocated disk space (without actually taking up disk space). Seems I was mistaken about journaling, but I wasn't too sure if I was right about that anyway. NTFS to my knowledge has always supported encryption, which is great. But... the compatibility of that encryption breaks between different versions of Windows. That is really inconvenient to, for example, encrypt a file using Windows 7 on an external HDD, and then try to de-crypt it on an XP machine. Compression is one of the only significant advantages of NTFS. Though, it hasn't always been perfect. I've had corruption issues thanks to NTFS compression in the past, though it is rare and I still use it. Agreed, though I think btrfs will soon surpass ZFS. However, ZFS is a much more practical "general purpose" filesystem; btrfs is a bit too complex (and therefore slow) for the average user. Another thing I forgot to mention - symlinks and hardlinks. I'm well aware Windows supports them now, but I don't think all versions of NTFS supports it, there is no user-friendly way to work with them, and there are limitations to links on NTFS. Symlinks are one of my favorite filesystem tools, and Windows makes it such a burden.
To be honest, I only use NTFS compression (since I started with Win2k), never bothering with shadow volume copies or encryption. Coming from FAT32 NTFS was a very nice jump ahead ZFS is pretty much at the point where one could begin to call it 'mature', I guess. btrfs is still in the 'could nuke your data if it has an off-day' stage, last I read up on it I use ZFS with my FreeNAS-based fileserver at any rate. No disagreement there. I regularly work with BSDs, Linuxes and similar, and it's so nice to just 'ln -s' (or equivalent) glue a file or folder structure together. Maybe that the new Linux subsystem will improve matters there, though. NTFS is quite capable, it's always been Windows holding it back.
