HN user
The dude abides.
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.
Apple still does this kind of crap.
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.
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.
The "pcapd capability" is iOS's remote virtual interface.
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.
It was signed with a Developer ID; thus, by definition, it could not have been distributed in the store.
Anything distributed through the App Store is signed by Apple. Developer ID signed binaries can only be distributed outside of the store.
I suggest you look at the author of the comment to which you replied, and compare his name to the author of the article…
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.
Please, state a cogent argument otherwise.
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%.
So, what exactly is untrue about what I said?
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.
[1] http://www.anandtech.com/show/6406/understanding-apples-fusi...
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.)
Steve Jobs at D8: ‘PCs are going to be like trucks’
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...
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.
And, as I said, Firefox no longer breaks plugins. Yes, they did. Yes, that was bad. They claimed, and I believe, that was necessary, but today their plugin interfaces are stable and have been stable for quite some time.
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.
If Firefox hadn't gone on a version roller coasters ride I'd still be using it. At least they pull versions that need more attention. But, FF 16!?!?! 16!!!? Huh?
. . . 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.
What, exactly, is Apple to test? They're not shipping updates to 10.5, and Chrome is Google's product to test.
Out of curiosity, what OS did you switch to that doesn't require regular, and often large, updates? I can't think of an OS I've ever used – various Linux distros, Windows, OS X, various BSDs, Solaris, and a smattering of random other unix variants – that didn't require some form of regular update that often required (or at least strongly suggested) a reboot. (Or the near equivalent of punting active users and relaunching a bunch of userland processes.)
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.
Please, quit "pulling out the dead guy card". Ask why iOS 6 Maps shipped, but quit saying SJ wouldn't have allowed it to ship. I doubt you knew Jobs and, even if you did, I doubt you have any clue what he would have done in this situation.
MobileMe was – and is, as iCloud! – a major corporate initiative. It touched almost every product Apple was working on at the time, affecting iOS, OS X and iTunes. It required significant capital investment in back-end infrastructure, and was announced by SJ himself and demoed by Shiller at the WWDC '08 keynote.
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.
I know many people who were and are on that team, and am well familiar with the described meeting. That meeting doesn't change the fact that Apple shipped MobileMe while SJ was CEO. It was a bad product that had a horrendous launch; SJ could have delayed the launch or killed the product, but didn't.
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.
If you're accusing Apple of copying iOS 5's Maps app for iOS 6's Maps app, you're accusing Apple of copying itself. Google provided the backend data and map tiles for Maps prior to iOS 6, but Apple wrote the app itself.
So… you two both personally knew SJ?
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?
If you want to get worked up over that, sure. I won't question that assertion. I'll just point out that other platforms had "app stores" before even the iOS jailbreakers.