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.
it's clear that the company sees Metal as the way forward for graphics and GPU compute on its platforms.
No.... an Apple only proprietary graphics API is not the way forward. Vulkan is the way forward. It will be available on Windows, Linux, smartphones, BSD, everywhere... except Apple, apparently.
Metal is about vendor lockin, but they don't have enough of the total computing market to make that work out in their favour.
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...
While HEVC is probably going to be useful in the future, since it does offer good compression and the licensing is likely to get sorted one way or another, VP9 is useful NOW. Google will send you videos in VP9 format if it can since not only is VP9 Google's format, but it gets better per-bit quality than MP4/AVC. Well given that Youtube is, by far, the big name in video hosting for the 'net, makes sense to support it. On top of that, Netflix has started making use of it as well. They are the very biggest commercial streaming service. So between the two it is a massive amount of use.
I can't see why you'd want to add HEVC, which is brand new, still having licensing issues and thus has next to zero adoption before VP9 which is already a major force. I mean shit even Edge supports VP9 these days. Safari and IE are basically the only browsers that don't these days (and IE is deprecated).
Replacing HFS with APFS brings a lot of new features similar to ZFS but it's also going towards the Android/iOS security model
Sure that's fine and all but I don't think many users will see a difference, power or otherwise. It's just more secure for those that leave the locks in place.
To me the more interesting thing is, Apple is not phasing this in as an optional FS you can install, but instead going balls-out and making conversion the default option for every install! That means millions of Mac users when the upgrade (and historically most will in a short period of time) are all going to be converting the entire filesystem out from under the installer...
Tell me developers out there that your blood does not run cold at the thought of trying something like that at that scale...
Apple does have a bit of a leg up in that a lot of developers will try installing it first and they can shake out most of the edge cases that way, but still.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
And what exactly are the advantages of Vulcan over Metal? No, really... serious question. Because just about every time I've seen an argument for Vulkan vs. Metal it's been all ideological purity, not technological superiority.
Does Vulkan have features that are missing in Metal (And Metal 2)? Is the performance better? Do they control patents that are being denied to Apple? If I don't care so much about free software, the GPL, and all that, but want to be able to use the better product, what's the BFD?
Imagine all the people...
Sell me macOS to use on the Intel box of my choice or in a VM. Thanks!
Why is all the good stuff already modded 5, when I have mod points?
And what exactly are the advantages of Vulcan over Metal? No, really... serious question.
Industry support. Vulkan will allow the same code to support every other major OS outside the Apple ecosystem, so will have 20X as many games as Metal ever will, not to mention better graphics drivers.
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.
What do you mean 'still'? Upgrading to 10.4 if you had enabled File Vault (home directory was an encrypted disk image, mounted on login) worked fine, right up until the first reboot (typically a month later) when your home directory became unreadable (eventually I discovered that this was only true for 10.4 - 10.3 could read it fine). No OS X / macOS has gone as badly since then - apparently their QA department didn't test the configuration of people upgrading from 10.3 and using one of the flagship features of 10.3.
I am TheRaven on Soylent News
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
It's just a shame that your public don't spend. If you want to actually make money as a developer, Android isn't your target.
I've filed a bug report, provided a trace, sent them mechanisms for reproducing, and pointed to the pile of Apple user forum posts of people with the same issue. No fix yet.
I am TheRaven on Soylent News
Junk mail is organised in a hierarchy. There's a top level junk mail folder where you can see all your junk mail and it has a child junk mail folder for each mail account. Seems like the best of both worlds.
All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
8. Photos library! As a technically minded user of Apple products for many years, having lived through spotty transitions between iPhoto, Aperture and Photos, I don't trust Apple to curate my photo library at all. Instagram is better.
Dumbing down iPhoto into Photos by taking out user-designed folder organization was a change that has sold millions of copies of Adobe Lightroom.
Actually, that's kind of depressing, because it means that IMO, their PMs are completely out of touch with where the major problems actually lie. The editor is really the only part of Xcode that I haven't had significant problems with. I have never once had a crash while selecting or typing. The worst bug I've found in the editor is that if you Command-/ to comment out the second line of a multiline macro, it won't let you comment out the first line. If that were the worst bug I had seen in Xcode, I would consider it one of the ten best apps on the platform. Rewriting UI code that is basically working well is a colossal waste of engineering resources that could be better spent fixing the steaming pile of hurt that lies underneath it.
It's all the other code besides the editor that basically needs to be thrown out and rewritten—the project editing, loading/saving, indexing, find-in-project, etc. all have either frequent crashes or major performance problems or both. And the "Fix Problem" part of code signing has been nightmarish for me, too, at various recent points in time. And when they replaced the simple, working concept of build platform and CPU with these crazy "schemes" a few years ago, they inflicted what is quite possibly the most unusable UI I've ever seen. It makes actions that should be simple difficult, for no obvious reason.
And the project file format and the IB file format are unholy nightmares from you-know-where for anyone who deals with version control. IB's tendency to make huge changes to files when you made zero functional changes, for example, is the sort of stupid crap that simply shouldn't be tolerated in serious software. Just looking at a nib (xib) file changes the "last saved in version" attribute, and asking it to show you a window or view as it would appear on a different device causes it to change all the numerical values for the position of every single item in every single view.
So no, hearing that they are rewriting the one piece of mostly working functionality does not make me happy. It's a bit like going to buy a used car and having the dealer say, "Well, the engine is burning oil, the brakes are metal-on-metal, and the driver's seatbelt doesn't work, but on the plus side, we were able to replace the steering wheel cover that was discolored after the last owner impaled himself on the eight-inch metal spike sticking out of the dashboard when the brakes and seatbelt failed."
Check out my sci-fi/humor trilogy at PatriotsBooks.