Slashdot Mirror
The Behind-the-Scenes Changes Found In MacOS High Sierra (arstechnica.com)
Apple officially announced macOS High Sierra at WWDC 2017 earlier this month. While the new OS doesn't feature a ton of user-visible improvements and is ultimately shaping up to be a low-key release, it does feature several behind-the-scenes changes that could help make it the most stable macOS update in years. Andrew Cunningham from Ars Technica has "browsed the dev docs and talked with Apple to get some more details of the update's foundational changes." Here are some excerpts from three key areas of the report: APFS
Like iOS 10.3, High Sierra will convert your boot drive to APFS when you first install it -- this will be true for all Macs that run High Sierra, regardless of whether they're equipped with an SSD, a spinning HDD, or a Fusion Drive setup. In the current beta installer, you're given an option to uncheck the APFS box (checked by default) before you start the install process, though that doesn't necessarily guarantee that it will survive in the final version. It's also not clear at this point if there are edge cases -- third-party SSDs, for instance -- that won't automatically be converted. But assuming that most people stick with the defaults and that most people don't crack their Macs open, most Mac users who do the upgrade are going to get the new filesystem.
HEVC and HEIF
All High Sierra Macs will pick up support for HEVC, but only very recent models will support any kind of hardware acceleration. This is important because playing HEVC streams, especially at high resolutions and bitrates, is a pretty hardware-intensive operation. HEVC playback can consume most of a CPU's processor cycles, and especially on slower dual-core laptop processors, smooth playback may be impossible altogether. Dedicated HEVC encode and decode blocks in CPUs and GPUs can handle the heavy lifting more efficiently, freeing up your CPU and greatly reducing power consumption, but HEVC's newness means that dedicated hardware isn't especially prevalent yet.
Metal 2
While both macOS and iOS still nominally support open, third-party APIs like OpenGL and OpenCL, it's clear that the company sees Metal as the way forward for graphics and GPU compute on its platforms. Apple's OpenGL support in macOS and iOS hasn't changed at all in years, and there are absolutely no signs that Apple plans to support Vulkan. But the API will enable some improvements for end users, too. People with newer GPUs should expect to benefit from some performance improvements, not just in games but in macOS itself; Apple says the entire WindowServer is now using Metal, which should improve the fluidity and consistency of transitions and animations within macOS; this can be a problem on Macs when you're pushing multiple monitors or using higher Retina scaling modes on, especially if you're using integrated graphics. Metal 2 is also the go-to API for supporting VR on macOS, something Apple is pushing in a big way with its newer iMacs and its native support for external Thunderbolt 3 GPU enclosures. Apple says that every device that supports Metal should support at least some of Metal 2's new features, but the implication there is that some older GPUs won't be able to do everything the newer ones can do.
Like iOS 10.3, High Sierra will convert your boot drive to APFS when you first install it -- this will be true for all Macs that run High Sierra, regardless of whether they're equipped with an SSD, a spinning HDD, or a Fusion Drive setup. In the current beta installer, you're given an option to uncheck the APFS box (checked by default) before you start the install process, though that doesn't necessarily guarantee that it will survive in the final version. It's also not clear at this point if there are edge cases -- third-party SSDs, for instance -- that won't automatically be converted. But assuming that most people stick with the defaults and that most people don't crack their Macs open, most Mac users who do the upgrade are going to get the new filesystem.
HEVC and HEIF
All High Sierra Macs will pick up support for HEVC, but only very recent models will support any kind of hardware acceleration. This is important because playing HEVC streams, especially at high resolutions and bitrates, is a pretty hardware-intensive operation. HEVC playback can consume most of a CPU's processor cycles, and especially on slower dual-core laptop processors, smooth playback may be impossible altogether. Dedicated HEVC encode and decode blocks in CPUs and GPUs can handle the heavy lifting more efficiently, freeing up your CPU and greatly reducing power consumption, but HEVC's newness means that dedicated hardware isn't especially prevalent yet.
Metal 2
While both macOS and iOS still nominally support open, third-party APIs like OpenGL and OpenCL, it's clear that the company sees Metal as the way forward for graphics and GPU compute on its platforms. Apple's OpenGL support in macOS and iOS hasn't changed at all in years, and there are absolutely no signs that Apple plans to support Vulkan. But the API will enable some improvements for end users, too. People with newer GPUs should expect to benefit from some performance improvements, not just in games but in macOS itself; Apple says the entire WindowServer is now using Metal, which should improve the fluidity and consistency of transitions and animations within macOS; this can be a problem on Macs when you're pushing multiple monitors or using higher Retina scaling modes on, especially if you're using integrated graphics. Metal 2 is also the go-to API for supporting VR on macOS, something Apple is pushing in a big way with its newer iMacs and its native support for external Thunderbolt 3 GPU enclosures. Apple says that every device that supports Metal should support at least some of Metal 2's new features, but the implication there is that some older GPUs won't be able to do everything the newer ones can do.
Replacing HFS with APFS brings a lot of new features similar to ZFS but it's also going towards the Android/iOS security model where the system and user data are separated and the system read-only without a root user anymore.
Although it will probably be trivial to break out, we're moving more towards commercial ecosystems that no longer will support tinkering with the OS.
Custom electronics and digital signage for your business: www.evcircuits.com
The main problem with HEVC is the patent licensing. In order to use HEVC you need to get 3 different patent licenses from 3 different patent pools (MPEG LA, HEVC Advance, and Velos Media).
There are some companies with HEVC patents, like Technicolor, which aren't in any patent pool so you also need to get a patent license from them. Technicolor says they have done this "to enable direct licensing" of their HEVC patents. Sounds convenient.
The patent licensing situation has reduced the x265 developers to begging the patent pools for better licensing terms. I recognise the x265 team is trying to make a buck but I think they'd be better off focusing on building an AV1 implementation than throwing their lot in with HEVC. HEVC's licensing is just not web friendly.
Luckily, the HEIF image format is content format agnostic (presentation and slides). In principle you could use HEIF with VP9 or with AV1. Apple may never support VP9 but I don't think they can avoid adding support for AV1 in future. AV1 will have too many advantages over HEVC (better performance, royalty-free licensing) to ignore.
I'll say, as a game developer that has written a) OpenGL, b) Metal, and c) Vulkan renderers, I have no problems with Metal.
A year since "release" and Vulkan is still half baked - we're up to sub point release FIFTY ONE. Sit down and write the basic Vulkan code required to just cope with the swapchain and get back to me. In 2 weeks. It will make you self harm.
Metal is actually quite nice. They've hit a nice level of exposing power vs not making you have to fuck with every bloody register setting in the driver. The main problem is the Obj-C interface. Doing profiling and seeing how much time is eaten by obj_msgsend() will make you sad for a "high performance" API. But taking some time and making C++ shadow classes for some of this mitigates it.
It's now a year since Google featured Vulkan at IO and the Android situation is the typical cluster fuck. We've done the work, but have no intention of shipping until Qualcomm (Adreno) and the Mali people make drivers that aren't hot garbage.
Not an apple fanboy by any stretch (Want me to rant about xCode? Got a free week?) but uninformed people should stop constantly pushing for Vulkan without appreciating what a mess it is - especially on mobile. It will probably get there -- enough people are invested to make it happen. But it's not there yet.
We're only a 15 months past initial release, and the extension fiasco that is OpenGL is starting in Vulkan...
Sounds like you have bad RAM or a bad hard drive. I mean sure, buggy HFS+ implementations (e.g. in the early days of Linux on PowerPC Macs) can result in some of the most spectacular corruption I've ever seen, but Apple's implementation is *amazingly* solid. In two decades of running multiple Macs, I've only seen corruption that didn't get auto-repaired a few times, and every instance has either involved faulty hardware or a sparsebundle served over AFP (Time Machine to an ABS).
No, the big benefit of a modern filesystem is not reliability so much as the ability to take snapshots and back up those snapshots without worrying about files changing while you're backing them up. This might even be enough to make Time Machine and iCloud reliable without bizarre surprises. For example, a few years ago, a friend of mine lost his entire iPhoto library because he kept iPhoto running all the time; iPhoto keeps its library open, and Apple foolishly made the iPhoto library an opaque bundle, so when iPhoto kept the library open, it prevented not only the library metadata, but also the photos themselves from getting backed up. Supposedly that got fixed a long time ago, but I still have a fair amount of distrust towards Time Machine as a result of that incident, and the whole reason behind not backing up open files was that you couldn't reliably snapshot the bundle at a given moment in time; that epic failure would never have happened if Time Machine had been built on top of proper snapshots to begin with.
Databases have the same problem. You can safely back up a MySQL database (with InnoDB, anyway), but to do so, you have to snapshot the entire database, including its journal, all at once, not copy it a file at a time. And so on. There are entire classes of problems that go away when you have proper volume-level snapshotting capabilities. That's why not switching to ZFS was, IMO, the single dumbest mistake that Apple's senior management made in the past twenty years, and possibly in its entire history. Now that we're getting APFS (a decade later), maybe we'll finally get the robust backups that we should have had back in Snow Leopard.
Don't get me started on Xcode, though. Its problems, IMO, have less to do with a lack of QA and more to do with Xcode being what happens when you take a 16-year-old piece of software (ProjectBuilder) and combine it with a 10-year-old piece of software (Interface Builder) and then continue developing the resulting software for another nine years. It started out too complex, and when they had the chance to fix that in 2003, instead of actually simplifying the fundamental architecture, they gave it a re-skin and hid a bunch of the functionality. And then they added IB to the mix and then they started piling on all the code signing stuff and tried to cram installer package support into it and... well, the result is that "Xcode : an IDE :: iTunes : a music player", and the result is unsatisfactory for precisely the same reasons. But I digress.
Check out my sci-fi/humor trilogy at PatriotsBooks.
Yes and no. Those ._foobar files don't appear on HFS+ either, they're only there for things like NFS or SMB shares or FAT filesystems that don't have the ability to store some of the metadata that Mac apps expect to work. The VFS layer transparently maps the metadata to and from these dot files when using a filesystem without the relevant metadata support. There are basically three solutions to this problem: silently lose the extra metadata (probably a bad idea), report an error to the program (which probably doesn't have handling for it) or store it somewhere else (which is ugly, but at least something that you can hide in the GUI). The ideal solution is for every (local and network) filesystem to support storing arbitrary metadata, but I don't know how we get from here to there.
I am TheRaven on Soylent News