Hardly any new features...
Hardly any new features...
That's an odd brag. I might be from a bygone era but it used to be the case that filesystems were particularly conservative and rollouts equally so. Getting one deployed in "record time" is hardly difficult because everyone else is so conservative it can take tens of years in some cases.
Look at Microsoft's ReFS, available in Server 2012, 2012 R2, Windows 8.1, Server 2016 and Windows 10 and has had eight public versions. Yet even after all of that it isn't the default partition type for Windows installations, and Microsoft only recommends it in specific circumstances[0].
So congrats to Apple's record time but I like my filesystems like I like my Toyota, reliable.
[0] https://docs.microsoft.com/en-us/windows-server/storage/refs...
ReFS is a pure storage-style File System, and it's been full of headaches since release for those trying to use it as such. Comparing it to APFS isn't really reasonable as they're meaning to accomplish two different goals both systems. (Keep in mind, some of the bugs that ReFS had included silent corruption on files over 2 TB, which is kind of important for even the upper-end of the small business spectrum when it comes to data. [1] Even with that many technical previews and idling in beta for many iterations, they missed a pretty big show-stopper for ReFS, which has no built in volume repair since it's not supposed to break. (To clarify, there is Integrity Streams, but it's more that if you still see corruption with Integrity Streams running, MS has no more tools in its kit to assist)
I get what you're saying, you don't want to watch a FileSystem do the 200 meter, you wanna see it's averages across several marathons, and I agree. However, what is important to take from such an install base is that so far the reports have been embarrassing implementations of stuff around the filesystem, not the filesystem itself not doing what it should. The fact that users aren't howling about data silently corrupting or extreme system slowdowns is a fairly good portend thus far, Apple's sloppiness on the surrounding code not-withstanding. APFS being stable doesn't excuse the rest of Apple's mistakes, but I would say separate the two; it's pretty clear APFS was a pretty important project for them, and it's clear where their attention was.
[1] - https://blogs.technet.microsoft.com/filecab/2017/01/30/windo...
Not sure if you're deliberately joking or not, but the quality of software in Toyota cars is hilariously awful.
There was a stunning writeup by one of the people who got source code to investigate the unintended acceleration issue a few years back. [1]
IIRC, as part of the cruise control, if they decided the car was going too slow it'd be given a command to accelerate. There was a second process which checked the speed, and once the car was going fast enough, it'd kill the accelerate process. Except the check/kill process would regularly crash, so the car would be told to accelerate and then nothing would be there to tell it to stop. Don't worry though, there's a software watchdog process to catch this! Except the watchdog ran under the same process manager as the check/stop script, so when the stop script crashed it'd take the watchdog process down too - and this was only the top of the iceburg when it came to problems.
tldr: software quality in Toyota's was abysmal and there's little reason to believe it's gotten fundamentally better.
[1] https://users.ece.cmu.edu/~koopman/pubs/koopman14_toyota_ua_...
[1.5] Actual Talk: https://betterembsw.blogspot.co.uk/2014/09/a-case-study-of-t...
Computer Engineer: If cars advanced as fast as computers, they'd go mach 1 and get thousands of miles to the gallon by now!
Car Engineer: If cars progressed like computers they'd inexplicably die on you and you'd have to uninstall and reinstall your tires to get it to drive again
Point missed entirely.
The "hard part" they've managed is getting it right (with few/no incidents) in record time, not just getting it out on record time.
Hope it’s as reliable as the acceleration is “unintended”… http://www.safetyresearch.net/Library/BarrSlides_FINAL_SCRUB...
That is an interesting recall. I was thinking about it today as my girlfriend is getting one replaced on her car right now. She commented on the incompetence of repair people these days and how they didn't even know if the repair was going to take one day or a week.
With the death toll from the airbags at only 22 globally so far [1] and maybe a few hundred injuries [2] and a total number of recall repairs at 65-70 million [3], you can bet the number bad repairs are going to cause more deaths than if they had not done the recall. Plus the cost of the recall in the billions of dollars that could have done a lot more good. I guess the lawyers are coming out alright though.
[1]http://www.thedrive.com/sheetmetal/18154/death-toll-continue...
[2]https://consumerist.com/2015/04/27/takata-airbag-defect-now-...
APFS is copy-on-write, so when you duplicate a folder, it happens instantly regardless of how big it is because it doesn't have to make a copy until you start modifying the files. Moreover, because of COW, duplicate folders don't take up any extra hard-drive space. I literally just duplicated a 100 gigabyte folder to test, it completed instantly and I'm not using any more drive space than I was before. It will only start using drive space if i start modifying the files.
APFS is seriously cool (there are many other features besides this). It's not revolutionary (ZFS and Btrfs did all this before), but it's miles past HFS+. Apple has needed a new filesystem for more than a decade, and I'm glad it has finally happened, even if the OS update that brought it sucks pretty badly.
Sparse files are hopelessly broken, prompting Docker for Mac to roll back to qcow2 when using APFS[0] (HFS+ sparse files are fine).
[0]: https://docs.docker.com/docker-for-mac/release-notes/#docker...
EDIT: reference