mjtomlin

IreneW said:

Do that's why they removed Tiles' possibility to track positions....

Incorrect!

They removed the “Always Allow” option in the permission dialog box, but the option still exists in location settings.

randominternetperson said:

On the other: holy crap!  What kind of exploit allows a hacker to get access to Keychain data (and more) just because a user hits a web page via Safari?  Can anyone give a few sentence explanation of the exploit?  I would have thought that impossible.

Web pages contain executable code in the form of Javascript, which is executed locally in the javascript runtime engine. This is part of an open-source project, so anyone could get access to the code and find vulnerabilities. One of the most common issues/bugs is memory leaks. If someone can track down code that consistently leaks memory, they can inject code into that leak and execute it.

This is a huge reason why Apple is moving away from the Objective-C runtime and replacing it with Swift which uses more secure memory management and strict type casting.

And the Keychain data does not include passwords, which are always kept in an encrypted state.

randominternetperson said:

rogifan_new said:

Is this show considered a comedy? A little hard to tell from the trailer.

Are you kidding?  Nothing about the trailer suggests that it’s a comedy. 

It is listed as a “Comedy, Drama” on IMDB.

ElCapitan said:

Perhaps the biggest issue here is that Timmy is standing there in conferences and in front of politicians such as the EU parliament bragging over how serious Apple takes privacy, while at the same time knowing his company store their customers data with the same companies he gives flack for NOT taking privacy serious. It is, at best, hypocrisy, at worst, complete contempt of his customers. 

Haha!

You can't be serious!? You really think those same user-centric terms and services those companies offer are the same as the enterprise cloud hosting/server services? Do you really think Apple created a Google account and just started storing all their customer data on Google Drive. LOL And you make the assumption that Apple would store all their user data on a 3rd party server without encrypting it? The amount of ignorance and hate is unbelievable.

Look, I don't like Google or Amazon, or even Microsoft, and I would never trust any of my data with them, but the service they provide to Apple (and other companies) is NOT the same they would provide to you or me. And when offering that type of service you can in fact make the assumption that privacy and security is part of the deal. To think otherwise, well, is just stupid.

elijahg said:

mjtomlin said:

elijahg said:

A significant factor in the PPC > x86 switch was Rosetta. It is much easier to emulate RISC PPC with its relatively small instruction set than it is CISC x86, and now x64. PPC apps running in Rosetta weren't much slower than the native ones, but that was also partly offset by the Intel CPUs being much, much faster than PPC ones. The A-series CPUs are quick, and in a less power and thermally constrained environment no doubt even quicker - but CISC emulation on RISC architectures is excruciatingly slow, no matter how fast the native CPU. Remember Connectix's Virtual PC? That emulated an x86 machine on PPC. Installing Win98 took 3 or 4 hours even on a G5. Of course API level emulation a-la Rosetta has less overhead, but it's still slow. 

Hmm... “RISC” doesn’t mean smaller instruction set, it means that instructions are less complex and optimized to perform a  more finite task. It basically means each instruction takes less cycles than what a CISC instruction would require, which might be much more “complex” in its execution.

It would be much easier for a RISC ISA to emulate a CISC ISA, because CISC instructions can be easily broken down into smaller instructions. In fact, Intel’s CPUs have RISC cores with a CISC front end to maintain compatibility. So even Intel takes their complex instructions and reduces them to a series of simpler instructions.

It is both. https://en.wikipedia.org/wiki/Reduced_instruction_set_computer ;

But no, it is not easier for a RISC ISA to emulate a CISC ISA. There are less instructions in RISC architectures vs CISC architectures. which - as I said before, is why Rosetta wasn't that slow. CISC CPUs also have deep pipelining, making emulation even more complex. Good luck with "easily broken down" CISC instructions. They're complex and instructions interact with eachother, which is exactly why they can't be easily broken down. 

Yes Intel CPUs are RISC at the core with a CISC interpreter now, because RISC CPUs are much easier to design and optimise because they're much simpler than CISC CPUs. By your own admission, CISC is complex, and RISC is simpler. Ergo, RISC is easier to emulate.

Rosetta worked at a relatively decent speed because it did not have the overhead of translating ALL the code - The API's on both PPC and Intel were the same, so a lot of time was saved by hooking into and running native API's as it was translating the PPC code. This had nothing to do with CPU architecture (RISC or CISC).

However, translation is all about mapping... You map this one instruction to a series of instructions, or you map a series of instructions to this one instruction... the latter requires pattern matching, which is much more intensive than the former. It is much more efficient to map a single CISC instruction into multiple RISC instructions, then it would be to search for a series of RISC instructions to map to a single CISC instruction. Again, this is why Intel CPU's can have RISC cores while running CISC instructions and be as fast as they are.

Also, You're using translation to demonstrate why one direction is better, and using emulation to demonstrate why the other is worse.

Emulate and translate are not the same thing. Rosetta is not an emulator, it's a translator. It does not emulate hardware or software, it simply translates code. And when translating ANYTHING, it is much easier to break down complex into simple, because every complex task is just a series of simpler tasks.

You previously mentioned the old PPC Virtual PC... That was an emulator. It had to emulate ALL the hardware in software, then run code on that emulated hardware... that's why it was so slow. Again, that has nothing to do with CPU architecture.