5,625 karma · joined October 5, 2010
"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.
Not for users who've opted into two-factor authentication: https://support.apple.com/en-us/HT204915
From the page:
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.
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.
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?
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.
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.
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.
https://developer.apple.com/library/Mac/qa/qa1176/_index.htm...
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.
Anything distributed through the App Store is signed by Apple. Developer ID signed binaries can only be distributed outside of the store.
Please, state a cogent argument otherwise.
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.
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.
[1] http://www.anandtech.com/show/6406/understanding-apples-fusi...
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.)
Yep. Not dead, not by any stretch of the imagination, but certainly not as ubiquitous as other devices.
http://blog.seattlepi.com/microsoft/2010/06/02/steve-jobs-at...
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]
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.
Also, believe me, Chrome is not without its bugs or regressions. Rapid iteration means things will break more often, by its very nature. Hence my statement: you can't knock Firefox for rapid releases if you've moved to Chrome. You're in the same damn boat.
. . . you do know Chrome's at version 22 and version 24 is in dev release, right?
Knock FF for the more disruptive update process, and for breaking plugins in earlier releases, sure. But (AFAIK) the plugin interfaces have been stable for quite some time now, and Firefox 15 introduced true silent updates. They seem to have fixed the pain points in their rapid release schedule.
If you use Chrome, however, you cannot knock them for iterating more quickly; Chrome's in the same boat.
Oh man, I remember my Gentoo days, where upgrading a single package would sometimes require new base libraries which in turn required a large chunk of the system to be rebuilt… definitely don't miss that process.
At the announcement it was couched as "Exchange for the rest of us" – it was trying to outdo a competitor's product. (To say nothing for how it countered many of the features Google was trumpeting for Android…)
SJ was absolutely aware of MobileMe, and was intimately involved with many parts of the product.
And, given all of that, it still was a flop of a launch. A launch that was so bad, I'm sure it was a motivating factor in the iCloud rebranding.
And to claim the G4 Cube was a minor product is just amusing. SJ was incredibly proud of that machine when he announced it. And you know he was deeply involved in its design, from day one.
Jobs was a marvelous CEO, but Apple made many missteps – some larger than the current uproar over iOS 6 maps app – while he led the company. Without having personally knew the man, one cannot claim what SJ would have done in this situation. Plain and simple.
And SJ, while he was leading Apple, was always without fault?
If that's the case, how do you explain Ping? MobileMe? The G4 Cube?