From Apple's own two-factor account support documentation:
"While [Apple Support] can answer your questions about the account recovery process, we can't verify your identity or expedite the process in any way."
Even if you manage to confuse a support agent, they cannot do anything to speed account recovery or be socially engineered into account compromise.
Do I still need to remember any security questions?
No. With two-factor authentication, you don't need to choose or remember any security questions. Your identity is verified exclusively using your password and verification codes sent to your devices and trusted phone numbers. When you enroll in two-factor authentication, we will keep your old security questions on file for two weeks in case you need to return your account to its previous security settings. After that, they will be deleted.
> Some parts of the filesystem become off limits, even as root. But installers have access!
Point of clarification: only Apple-signed installers can modify system paths. (c.f. https://support.apple.com/en-us/HT204899) All other installers are subject to SIP restrictions.
And Apple only added a few simple steps for people eager to tinker: reboot and disable SIP. Or reboot into the installer for the other OS with which you prefer to tinker. Or create a VM with an experimental OS. Frankly, most of those steps existed before SIP.
Most users shouldn't care or notice, and will benefit from increased protection. People who want to tinker will (and can and should!) tinker.
> Apple can [sic] starts using the new Trusted Computing[4] features on new CPUs (such as SGX[5]), good luck regaining control.
It seems the apocalypse came to pass a while back, with the Secure Enclave in Apple's A7 processors.
> Of course, they know how to disable the restrictions or install a jailbreak, so these problems don't apply to the technological priesthood - it's normal people that have to live with the restrictions.
Here's the funny thing: normal people benefit from those restrictions. Without them, their devices – the ones you insist they should own – would quickly become someone else's: the attacker's. It would be awesome if people started thinking about long-term consequences.
Honest question: do you hate root? Should all processes run with equal privileges? Does the kernel have an evil and undesired permissions level?
I'm idly curious: what were your "symlink issues with /usr/bin/"? As with other unices, /usr is system-owned and anything not under the /usr/local hierarchy may be modified or destroyed during OS upgrades.
Very few people should ever need to disable SIP – and that includes almost all developers! Are you building/running unsigned kexts? No? Then you almost certainly don't need to disable SIP.
Most instructions that no longer work with SIP enabled should be modified so they don't conflict with SIP. As a bonus: changes resulting from those instructions are far more likely to be preserved across OS X upgrades.
If you're looking to hide your activity from malware, you should be incredibly excited by SIP. With SIP enabled, you have more protection from malware introspecting other processes or monitoring activity on the system. Hell, if you're a researcher building tools to detect and analyze OS X malware, you'd likely benefit from SIP by opting-in your tools to SIP's restrictions. (Tangential example: Chrome is taking this step; Canary is currently SIP restricted.)
Malware can only introspect SIP-protected activity by employing kernel exploits. If malware can compromise the kernel, it's game over. You're not going to hide anything, ever.
If anything, it sounds like you want SIP's purview expanded to encompass more of OS X.
Improved privacy is one benefit https provides. There are two other benefits worth considering: authentication and integrity. Without https, there is no way trust a site's identity, and no guarantees the data you're receiving was not modified in transit.
Don't forget to weigh those other two factors when judging https adoption. Your goals are understandable and worthwhile. They're also still achievable with appropriate client management software.
Consider this: in a world without https, your children could visit a valid, approved domain and be served malicious or undesirable content because someone modified the content in flight or intercepted the connection. There is literally no way for you to have any guarantee what's served to your children.
In a world with https (and appropriate client management software), you can be confident they really are only receiving approved content because the connection is authenticated and traffic cannot be modified in flight. (And your children are less easily tracked by unknown 3rd parties, to boot.)
Authentication and integrity are often forgotten when discussing https, which is unfortunate because those are two incredibly important benefits that further motivate widespread https deployment.
OS 5 added a remote virtual interface (RVI) facility that lets
you use OS X packet trace programs to capture traces from an
iOS device. The basic strategy is:
1. Connect your iOS device to your Mac via USB.
2. Set up an RVI for that device. This creates a virtual
network interface on your Mac that represents the iOS device's
networking stack.
3. Run your OS X packet trace program, and point it at the RVI
created in the previous step.
If you don't pair the iOS device with the Mac, the technique won't work.
If I'm arguing a straw man, you're arguing a red herring. There is no "RDF" at play here. Form absolutely does impact function. In fact, form distinctly defines function.
So… you'd rather carry around a briefcase with an attached external handset as a cellphone, rather than a somewhat modern cellphone? What about carrying around a laptop with a tethered cellphone vs. a smartphone? If you prefer the latter options, as many do, then I really do believe that's a solid signal that form is function.
It doesn't just look thinner. It is thinner. Yes, there is a hump around the base's hinge, but it is still significantly, noticeably thinner – per the article, the machine's volume was reduced by 40%.
Potentially nothing, but it is all anecdotal. Where's the widespread or researched evidence of HFS (especially in its HFS+ or HFSX variants) being a slow and easily corruptible file system?
It's not like HFS is a rare and infrequently used file system – it's the primary filesystem for all Macs since System 3, for many iPods, and for all iOS devices.
The scaling limits present in HFS+ will rarely be hit by most users and, while not as resilient as more modern FSs, there are no inherent fatal design flaws with HFS that I'm aware of. Perhaps you've pushed HFS+ beyond its limits, or have usage patterns that trigger a rare fatal bug, but just claiming that something is true is not very productive either.
The whole "it's not a cache" thing is a canard. Doing it right means doing it much like swap: you may have dupes in certain cases. Going beyond that actually hurts performance.
It's fundamentally not a cache. If it were a cache, Fusion Drive would not increase the total storage space. Anandtech[1] seems to confirm this, noting that Fusion Drive creates a 4GB write buffer on the SSD and all read operations will influence a pinning algorithm which will move, not cache, frequently accessed files from the HDD onto the SSD.
ReadyBoost is exactly a cache, as is ZFS's ARC and L2ARC.
Now then, regarding the statement you question… yes, it is incorrect. ReadyBoost and L2ARC are pre-existing examples of "hybrid models of blending SSD and mechanical disks" that "integrate with the OS" and do so quite intelligently. You are correct to call out that statement. But it really does appear that Fusion Drive is not a cache, but a true unioning of SSDs and HDDs managed by the OS to ensure hot files are on the SSD whenever possible.
On a typical HHD, under typical circumstances, all writes go to the SSD, and are copied to the HDD later on. So far so good; Apple's solution will do the same thing. And stuff being read gets copied to the SSD in both cases. Also great.
That's an assumption we've yet to see confirmed, and I suspect is incorrect. I doubt every single file that's read will migrate to the SDD. Rather, I expect only files frequently read will migrate to the SDD. Effectively, the SDD will largely be a write cache (but likely only for files written atomically) and a read cache for frequently accessed files.
That behavior would largely sidestep your concerns.
(And, actually, files that are readily streamed, like videos, aren't necessarily files you'd want to store on the SDD. Those can often – though, yes, not always – be read quite quickly from the HDD. Unless you're dealing with truly huge files, or actively editing a video, you don't need SDD throughput.)
Actually pbiggar is correct – the going market rate for employees (or, at least, engineers) in an acquihire is usually around $1-2MM/employee. E.g. a small startup with 4 engineers would be acquihired for $4-8MM. Thus, if this were a full acquihire and Color has 20 engineers, I'd expect the acquisition price should have been around $20-40MM, not $2-5MM.
In an acquihire like this, the acquisition price and each employee's final compensation and options grant from Apple are entirely unrelated. diego has an excellent post in this thread covering that in more detail. [1]
And that failure comes from incredible mismanagement. Blowing tens of millions on office space, parties, and trips to Vegas and NYC, all while building a talented engineering and design team that was then given no focused direction and subsequently laid off is what led to Hipstamatic's downfall.
Given the revenue mentioned in the article, it's obvious that many were willing to justify paying $1.99 for Hipstamatic, and then more for additional filters. Frankly, it's rather nice to see a company better value their work and become a strong success. I hope that happens more often.
Based on what I read in that article, I consider their failure to be that they neglected a successful, revenue generating product and instead joined the race for the bottom. $10MM/yr is fantastic revenue stream, and they were willing to throw it away on a whim… yes, a $1B acquisition is cooler than $10MM in yearly revenue, but $1B acqs are incredibly rare and at least Hipstamatic can claim they made money, a goal that Instagram can't claim to have reached. And making money doesn't rule out a fantastically large acquisition; just look at Yammer.
Hipstamatic could have intelligently reinvested their revenue in enhancements to Hipstamatic, built out other products and services alongside the cash cow, and might have scored their $1B++ exit later. And even if that acq never came, at least they'd still have a successful business doing tens of millions in revenue.
"While [Apple Support] can answer your questions about the account recovery process, we can't verify your identity or expedite the process in any way."
Even if you manage to confuse a support agent, they cannot do anything to speed account recovery or be socially engineered into account compromise.
https://support.apple.com/en-us/HT204921