I don't trust contactless EMV cards' security, both with the ability to protect my cash and the ability of people to track my presence from afar with specialty readers. I do like chip cards over the magnetic stripe.
The protocol has a few issues, but is not too bad. The physical security is potentially an issue, but all newer cards here support it so you can carry the card in a wallet that blocks the signal if you're paranoid and if you don't then not using it doesn't prevent anyone from scanning the card in your pocket. It's more secure against some threat models than using a chip and PIN, because now you're not entering anything into the merchant's terminal. Your card and the bank are communicating via the EMV protocol, and it's up to the protocol's security to worry about it.
From the perspective of liability, it's better because the burden of proof is 100% with the card issuer for contactless payments. If you contest a charge then they are required to reverse it immediately.
And certainly, securing a phone with a fingerprint, giving my fingerprints to Apple/Google, and having a phone capable of running malware (as opposed to being a phone) all seem stupid.
Not sure about Google, but the Apple implementation runs the EMV protocol and the fingerprint comparison in the Secure Element. This is a small ARM core with some private memory (which isn't addressable by the rest of the system) running a tiny microkernel OS and a small set of security services. When you put your fingerprint on the scanner, it's sent to the SE, which then simply returns true or false to the OS querying if things should be unlocked. If the payment application is running then all the code running on the application core on iOS is doing is telling the code on the SE to run an EMV transaction. The code on the SE will then run the entire EMV transaction, using keys that are not accessible to iOS or any software running on top of iOS.
To say nothing of making part of my day an unpaid minimum wage worker at a self-service checkout, as opposed to doing anything else, e.g. reading
There is *no* mechanical or electrical way to replicate this without using biological means, and precise replication is not even remotely possible.
Since it's coming up on its hundredth anniversary of publication, I'd draw your attention to the Church-Turing thesis. Any computational device can simulate any other, it's just a question of performance. With current computers, we could simulate a human brain if we had a sufficiently accurate scan, though I'd be very surprised if you could run it at even 0.01% of the original speed.
That said, I don't disagree with your core point that acquiring the accurate scan is well beyond current technology.
Enabling the card reader is a single button press on most tills, and is now the default here on more modern ones, with the cashier having to press a 'cash payment' button if you want to take it. Tapping the card on the contactless reader means moving your hand less far towards the person than if you were handing them cash, because the reader is right next to you, and then it takes about a second to validate and you're done. If it's taking more than a second, that implies that the store is still using a modem to dial up. The long delays that we used to have that mostly went away 10-15 years ago were caused by the terminal having to dial a phone line to handle the authentication. If it's over £30, you need to put the card in and enter the PIN, but that only adds another 3-4 seconds (typical PINs are 4 digits, and take less than a second per digit to type, inserting the card maybe takes another second).
There was an article about this on Slashdot a few years ago. It's not so clear cut. If you handle cash, there are a bunch of extra costs. You must store it securely, you must transport it securely to the bank, you must pay higher insurance premiums for cash on the premises, you must balance all of your tills, and so on. When the study was done, these costs are lower than the card surcharge for companies with a very low turnover, but I think the break-even point was around $100K, at which point taking cards became cheaper.
The store will not keep the credit card number, so unless I have a store card, they will not be able to link sales to me
Note that they are not allowed to store the card number, but they are allowed to store a cryptographic hash of the card number and they are allowed to store the last few digits. A typical card number is about 53 bits, so storing a 256-bit hash means that the probability of a collision is so close to zero that they have an effectively unique identifier. Oh, and I think that they're also allowed to store the name on the card.
I'm not sure where either you or the grandparent live, but in the UK you can at least avoid the interacting with a human step in most banks. You grab an envelope from a stand, fill in your account details on the back, put the cheques inside, and then drop it in a post box in the bank and they'll process it that day.
Apparently a bunch of US banks now provide a phone app that lets you take a photograph of a cheque to process it. This leads to some slightly surreal experiences where the fastest way for one person to hand money to another is to write a cheque, have the other photograph it, and then rip it up.
Let me guess, you live in the USA, which got the old and crappy contactless terminals that other countries had discarded and then connected them to an archaic banking network that was quickly overwhelmed. In the UK and everywhere I've been in Europe, you put the card on the reader, a second later it beeps, and you're done. It takes less time than handing over cash, so even if there's no change and the cashier puts it in the till instantly, it's still faster.
I can just wave my phone? Do I have to flip it open, or can I leave it shut? And how do I pay to refill the phone with the phone?
Not sure about Sweden, but in the UK most places now do contactless EMV transactions with either a phone or a card. If you use a card, you just put it on the terminal and about a second later it beeps and it's done. If you use a phone, it's the same thing but you have to touch the fingerprint sensor as well (for Apple Pay, I've never seen anyone use Google Pay). I prefer to have a separate physical token that doesn't have the ability to run malware, so I don't use the phone, but with the card it takes less time than for cash:
Both need me to get my wallet out of my pocket.
Both need me to get something out of my wallet.
Only cash requires me to get out a quantity that differs depending on my final amount (so I can't get it out until that's calculated).
Both require me to hand something over, but in the case of the card I just tap it on the reader for a second, for cash I hand it across the counter or feed it into a machine.
Only cash requires someone to calculate change and give it to me.
My local convenience has self-service checkouts and it takes their UI a couple of seconds to step through the payment screen. I pop my card on the card reader before I tap the last step of the UI and it's done by the time I reach over to pick it up again.
The US government accepts US dollars and only US dollars in payment for taxes. Last year, the Federal government received $2.3 trillion in income taxes. Assuming that the economy stays broadly the same size, that means this year people in the US will require around $2.3 trillion to be able to pay their taxes. That's what backs the US Dollar. The amount of tax that's paid reflects the health of the economy, so indirectly the US Dollar is backed by the health of the US economy.
It's important to differentiate the form of coinage from the backing medium. Coinage often has little or no intrinsic value. This is especially true of paper promissory notes, which cost a tiny fraction of their face value to produce and have few other possible uses (uncomfortable toilet paper, really tacky wallpaper, or a convenient object for arranging your cocaine in lines). Currencies are typically backed by some promise from an organisation to exchange them for something else. For example, the one Pound Sterling could originally be redeemed for one pound of sterling silver. Most modern currencies are established by fiat: a law requires that they can be used to settle any debt, including taxes, so their value is based on the number of people who have debts that can be settled by the currency.
A crypto currency simply provides an implementation mechanism that allows you to maintain a ledger recording transactions without a single central point of failure. This would address the concerns in TFA, where people are worried that if, for example, the Russians invaded they'd be able to shut down all commerce in a region by flipping a few config options in a computer.
Most crypto currencies have difficulties replacing real-world currency uses because they are entirely decoupled from any store of value in the real world. Ideally (gross oversimplifications follow), the monetary supply should reflect the economy. When more value is created in the economy, more money should be created to represent it. When value is removed from the economy, the money supply should contract by a corresponding amount. The money supply should expand slightly faster than the economy so that holding money is discouraged as a means of holding value (you want people to invest in things that improve productivity, not keep piles of cash under their bed).
I expect the 64-128MB of eDDR as a L4 cache will have more of an impact. For FPGA place and route, we've found that the desktop versions with this are about 50% faster than anything else on the market (performance is dominated by the sequential bits of the algorithm and the working set doesn't fit in cache).
Meltdown allows you to use timing attacks to snoop data across a system call. This is because Intel used an optimisation where they treated system calls as branches, whereas on AMD chips they resulted in a pipeline stall. The Spectre vulnerabilities work at the same hardware privilege level, though not necessarily at the same software privilege level (for example, you can read past a bounds check in a NaCl or JavaScript sandbox and read memory outside of the sandbox, which gives you the memory disclosure vulnerability that you need to launch a code reuse attack).
The defence against Meltdown is to unmap kernel memory when in userspace. This means that the CPU would have to speculate past the CR3 update (switch page tables to the userspace mappings) to be vulnerable. Current CPUs don't do that, because it's really hard to do: You need to be able to invalidate TLB fills, because the page tables that you've installed might be wrong. TLB fills as a result of normal speculative execution are fine, because the TLB is always an arbitrary subset of the contents of the page tables, so you don't need to invalidate them. Sometimes this can even give a big performance boost. Apple found a few years ago that they were getting a big speedup because a mispredicted branch was prefetching some data into the cache that they were using later. The mispredicted branch was much cheaper than stalling for the cache fill. In hindsight, I should have realised that Spectre-like attacks were possible when I learned about this.
The defence against the Spectre variant 1 attack is to add a data dependency where previously there was a control dependency. For example, if you have some code that looks roughly like this pseudocode:
if (bounds_check(address, offset)) { load(address + offset); }
Where the select becomes a conditional move instruction (or some equivalent arithmetic operation). This transformation means that the load now has a data dependency on the result of the bounds check and so won't be dispatched until the bounds check has been calculated. This, in turn, means that there won't be any observable side effects of the load if the branch would not be taken because the instructions inside the conditional will be canceled as soon as the branch is determined to be not taken. This probably has a small performance overhead, because it will introduce pipeline bubbles. I'd be surprised if it were more than 5% though.
Variant 2 involves poisoning the branch target buffer so that at a specific point in execution the CPU will predict a jump to attacker-controlled code. You can then put timing sensitive instructions at that point and probe register values. The mitigation for this is called a retpoline, where you perform an indirect branch using a return instruction, which then uses the return buffer for prediction and so will predict the address after the last call. This basically forces a branch mispredict, but to a location that isn't controlled by the attacker.
Some of the proposed hardware fixes involve not sharing branch predictor state across security contexts. This is not ideal, because often that sharing is beneficial. For example, if you an Android app, it's forked from a zyogte process that sets up the VM and pre-loads a bunch of classes. All apps will have the same core system code in the same addresses and can benefit from sharing branch predictor state. Similarly, if you run a server in a pre-fork model.
Maybe where you are. In the UK, they've basically gone away entirely. The variable rate is about 1.5-2% and no one wants to give you a fixed-rate deal anywhere near that, and no one would be crazy enough to take a fixed-rate mortgage at the 4-5% that the banks might be willing to offer over a 20-30-year period when the variable rate is so low. The ones advertised as 'fixed rate' are actually fixed for 2-5 years and then transition to variable (base rate + some percentage) at the end of the fixed-term period.
Moore's Law gets you better performance because more transistors give you better performance. In particular, Dennard Scaling meant that the smaller transistors used less power so you could have more specialised pipelines, more complex specialised instructions, and so on. Unfortunately, Dennard Scaling ran out about a decade ago, so although Moore's Law has given us more transistors, the number that you can power at any given time has stayed almost constant.
I generally trust corporations to run a cost-benefit analysis before deciding on any course of action. If the cost of getting caught with the data is 1,000 times the financial benefit from retaining the data and the probability of getting caught is 1%, most companies won't keep it. If you double the fines and double the probability of audit every time that a company gets caught, then eventually the converge at making it too expensive for a company to keep.
You don't even need that. Just one disgruntled former employee with a grudge who's willing to be a whistleblower so that they can watch Facebook pay a billion dollar fine.
Exactly. Railways were invented[1] in the UK, yet today we have one of the worst rail systems in Western Europe. Of the original 'four great inventions', China was famous for not really doing anything with gunpowder other than making fireworks (Chinese science was severely hampered by failing to invent glass, which is a prerequisite for a lot of chemistry and therefore metallurgy).
[1] Somewhat debatable, depending on what you regard as the original railway, but mostly true.
However, unless Apple's rumored new chip suddenly kicks the crap out of an equivalent-gen Intel chip (without turning a MacBook Pro into a room-heater **), this rumor is likely just that - a rumor.
Everyone in this discussion seems to be conflating CPU chip and CPU core. It's entirely possible, given Apple's relationship with Intel (and Intel's attempts to move into the SoC market) that Apple would ship an Apple-designed SoC that incorporated an Intel CPU core with a load of other Apple-designed cores (GPU, Secure Element, other accelerators).
PowerPC code often used Apple's C extensions for vector intrinsics. They provided some shims implementing most of the PowerPC builtins in terms of SSE, but some weren't available. It also didn't help that Apple's vector extensions and GCC's used different syntax for describing vectors, so porting was quite painful. These days, it's comparatively easy to write vectorised code that will take advantage of both SSE and NEON, though don't expect it to have the same performance characteristics on both (or in different Intel or ARM microarchitectures, for that matter).
There are a few other issues. It's not just Bootcamp, it's also WINE. A lot of the 'Mac' games are actually Windows games with a bundled version of WINE. Note that this is WINE, not WineLib. The WINE team now actively discourages use of WineLib because you get odd issues from programs that expect COFF linkage behaviour instead of ELF, for example, and porting is a lot easier if you ship WINE's PE/COFF loader rather than relying on the host platform's ELF loader.
ARM has limited virtualization support - or usefulness for that matter
I'd disagree with the first part of this. ARM's hardware virtualisation acceleration is on a par with Intel's. I'd agree with the latter part though. The common use of virtualisation on macOS is to run Windows in a VM. Unless Qualcomm's ARM Windows platform becomes a lot more popular, I don't imagine there being much call to run ARM Windows on Macs.
Apple loses the economies of scale that Intel enjoys, eating into cost savings
That one depends a lot on how much they can share designs with the iPhone / iPad. If the Mac chips are just a higher core count and clock rate than the iPad versions, then they may get some of this back. Mac, plus iPhone, plus iPad sales add up to about 50% of the total number of PC sales, so they're only a factor of two off.
All existing MacOS apps and games, gone (without either substantial developer support for rebuilds or else subpar emulation, which is not a UX Apple is likely to support)
Note that Apple has done this before. In both the PowerPC and Intel switch, they shipped emulators that allowed you to run existing code. Modern emulators are now pretty good at adjusting call frames so that you can call from emulated code into native code. If you keep the same structure layouts in your legacy and emulated platform then you can share pointers between them. Most Mac apps spend a huge proportion of their total CPU time in Apple-provided system libraries, which is a big part of why Rosetta was so fast in the PowerPC to Intel switch: most existing code (including all of the standard UI drawing, text rendering and layout, and so on) code ran as native x86 code, so the emulator only had to be fast enough that the rest didn't become a bottleneck. OF course, it helped that the laptop Intel cores were about twice the speed of the Freescale ones that they replaced (and had more cores).
At the end of the day, it's really just trading one master (Intel) for another (ARM)
Again, not quite so clear cut. One of the big reasons for the Intel switch was their relationship with Intel versus IBM / Freescale. Apple was the sole customer for both IBM and Freescale in the relevant markets, which meant that they were paying a huge proportion of the total R&D, yet someone else was in control. When they switched to Intel, they were the single largest customer, but were only about 20% of the total.
I suspect that, given the massive growth of cloud stuff, that at least one of Google, Amazon, or Microsoft (possibly all three) is now a larger customer than Apple, which means that Apple is no longer able to demand exactly what they want. There's some evidence for this: Apple customers keep complaining about not being able to buy MBPs with 32GB of RAM, Apple says they'll ship them as soon as Intel produces a CPU that can handle 32GB of LPDDR4, Intel still isn't producing laptop chips that support LPDDR4.
Their relationship with ARM would, again, be very different. Apple is an ARM Architecture Licensee, which means that they are allowed to (and do) design their own ARM-compatible cores in house and ship them as long as they pass the conformance tests. There are also over half a dozen other ARM Architecture Licensees (you can find an abridged list of these in the ARM ARM if you look at the hardware register value that provides the vendor ID, though some companies - including Apple - request not
That's part of the reason I've always avoided the Bay Area. My commute is a 10-minute bike ride. Pretty much anywhere else I want to go on a regular basis is the same distance. The jobs I've been offered in the Bay Area would have involved spending at least 40 minutes each day in a car, probably closer to an hour and even more if I wanted to go anywhere other than home or work. That's too much of a quality of life hit for me to want to take.
Mortgages can go up if interest rates go up (unless you manage to find the rare fixed-term mortgage that remains fixed term for the duration of the loan - around here the longest fixed term mortgage is 5 years and it's at almost double the interest rate of a 2-year fixed-term mortgage). At least here, the difference is that the amount that rents can go up by during a tenancy is limited by law (with some quite wooly terminology) and there's an appeals mechanism if it your landlords puts it up too much (mine went up by about 3% each year when I was renting here, and when we moved out the property was advertised with rent 10% higher than we'd been paying, which creates a somewhat perverse incentive for landlords to have a high tenant turnover).
Typically renting costs $x per month, and buying costs $(x + y) per month.
No, typically renting costs $(x + y + z + w) per month, where x is the cost of mortgage interest, y is the cost of maintenance, z is the cost of administrative overheads of renting (overhead for periods when it's empty, cost of a letting agency and so on), and z is the landlord's profit. Buying costs $a up front (for the deposit) and then $(x + y - v) per month, where v is the appreciation on the house.
Your calculation is whether, if you have $a, you can invest it to make more than $(z + w + v). An abundance or rental properties in an area means one of three things:
Other people have done the calculation, decided that it's a good investment, and bought houses to rent.
The property market is so depressed that people are hanging onto houses and renting them out rather than selling them.
Lots of other people have done the calculation incorrectly.
Now, it's never entirely safe to discount option 3, because lots of people are bad at maths (though they tend not to be the ones that accumulate enough money to buy multiple properties). Option 2 is fairly easy to check, go to a site like RightMove and see how long properties in your area are typically on the market before they're sold.
Note that I've oversimplified slightly. The x isn't really a common factor that can be removed when comparing the renting and buying cases, because buy-to-let mortgages tend to have higher interest rates. Landlords sometimes include v in their cost of renting - in a few places rent is dirt cheap because the appreciation is so high that people are buying properties just to sell them in a few years and only bother having tenants because unoccupied houses are more likely to be vandalised (and may incur other tax liabilities, require the owner to pay to keep utilities connected, and so on).
I bought a house before I moved here and, including maintenance and mortgage payments, I was paying about a third less than I had been paying renting somewhere cheap (below market rate - the landlady was retired and living in a different city and hadn't put up the rent for years) and less nice than the place that I bought. When I moved here, I rented out my house to a friend, so charged him below market value to have someone I trusted there (and didn't subsequently put the rent up at all). Even though it's relatively old and so has quite high maintenance costs, I made at least a small profit renting it out every year, until I sold it and used the capital to buy somewhere here.
It "fixes" your housing costs in time - rents go up, mortgages don't, bar property taxes.
Only if you have a mortgage with a fixed interest rate for the entire mortgage duration, which I haven't seen anyone offer since before the crash (banks will offer these when interest rates are high, but when they're very low they want to be able to put the rate up when the base rate goes up).
That depends a lot on the property market. Around here, a rented property rarely stays on the market for more than a week, irrespective of quality. Most landlords use the same small set of incompetent letting agencies. If you're unhappy, you move out and they get a new tenant in within a couple of weeks. Oh, and they can legally put the rent up more in between tenants than with a sitting tenant, so they may end up making more if you leave.
Slashdot Mirror
I don't trust contactless EMV cards' security, both with the ability to protect my cash and the ability of people to track my presence from afar with specialty readers. I do like chip cards over the magnetic stripe.
The protocol has a few issues, but is not too bad. The physical security is potentially an issue, but all newer cards here support it so you can carry the card in a wallet that blocks the signal if you're paranoid and if you don't then not using it doesn't prevent anyone from scanning the card in your pocket. It's more secure against some threat models than using a chip and PIN, because now you're not entering anything into the merchant's terminal. Your card and the bank are communicating via the EMV protocol, and it's up to the protocol's security to worry about it.
From the perspective of liability, it's better because the burden of proof is 100% with the card issuer for contactless payments. If you contest a charge then they are required to reverse it immediately.
And certainly, securing a phone with a fingerprint, giving my fingerprints to Apple/Google, and having a phone capable of running malware (as opposed to being a phone) all seem stupid.
Not sure about Google, but the Apple implementation runs the EMV protocol and the fingerprint comparison in the Secure Element. This is a small ARM core with some private memory (which isn't addressable by the rest of the system) running a tiny microkernel OS and a small set of security services. When you put your fingerprint on the scanner, it's sent to the SE, which then simply returns true or false to the OS querying if things should be unlocked. If the payment application is running then all the code running on the application core on iOS is doing is telling the code on the SE to run an EMV transaction. The code on the SE will then run the entire EMV transaction, using keys that are not accessible to iOS or any software running on top of iOS.
To say nothing of making part of my day an unpaid minimum wage worker at a self-service checkout, as opposed to doing anything else, e.g. reading
I've no idea what this means.
There is *no* mechanical or electrical way to replicate this without using biological means, and precise replication is not even remotely possible.
Since it's coming up on its hundredth anniversary of publication, I'd draw your attention to the Church-Turing thesis. Any computational device can simulate any other, it's just a question of performance. With current computers, we could simulate a human brain if we had a sufficiently accurate scan, though I'd be very surprised if you could run it at even 0.01% of the original speed.
That said, I don't disagree with your core point that acquiring the accurate scan is well beyond current technology.
Enabling the card reader is a single button press on most tills, and is now the default here on more modern ones, with the cashier having to press a 'cash payment' button if you want to take it. Tapping the card on the contactless reader means moving your hand less far towards the person than if you were handing them cash, because the reader is right next to you, and then it takes about a second to validate and you're done. If it's taking more than a second, that implies that the store is still using a modem to dial up. The long delays that we used to have that mostly went away 10-15 years ago were caused by the terminal having to dial a phone line to handle the authentication. If it's over £30, you need to put the card in and enter the PIN, but that only adds another 3-4 seconds (typical PINs are 4 digits, and take less than a second per digit to type, inserting the card maybe takes another second).
There was an article about this on Slashdot a few years ago. It's not so clear cut. If you handle cash, there are a bunch of extra costs. You must store it securely, you must transport it securely to the bank, you must pay higher insurance premiums for cash on the premises, you must balance all of your tills, and so on. When the study was done, these costs are lower than the card surcharge for companies with a very low turnover, but I think the break-even point was around $100K, at which point taking cards became cheaper.
The store will not keep the credit card number, so unless I have a store card, they will not be able to link sales to me
Note that they are not allowed to store the card number, but they are allowed to store a cryptographic hash of the card number and they are allowed to store the last few digits. A typical card number is about 53 bits, so storing a 256-bit hash means that the probability of a collision is so close to zero that they have an effectively unique identifier. Oh, and I think that they're also allowed to store the name on the card.
I'm not sure where either you or the grandparent live, but in the UK you can at least avoid the interacting with a human step in most banks. You grab an envelope from a stand, fill in your account details on the back, put the cheques inside, and then drop it in a post box in the bank and they'll process it that day.
Apparently a bunch of US banks now provide a phone app that lets you take a photograph of a cheque to process it. This leads to some slightly surreal experiences where the fastest way for one person to hand money to another is to write a cheque, have the other photograph it, and then rip it up.
Let me guess, you live in the USA, which got the old and crappy contactless terminals that other countries had discarded and then connected them to an archaic banking network that was quickly overwhelmed. In the UK and everywhere I've been in Europe, you put the card on the reader, a second later it beeps, and you're done. It takes less time than handing over cash, so even if there's no change and the cashier puts it in the till instantly, it's still faster.
I can just wave my phone? Do I have to flip it open, or can I leave it shut? And how do I pay to refill the phone with the phone?
Not sure about Sweden, but in the UK most places now do contactless EMV transactions with either a phone or a card. If you use a card, you just put it on the terminal and about a second later it beeps and it's done. If you use a phone, it's the same thing but you have to touch the fingerprint sensor as well (for Apple Pay, I've never seen anyone use Google Pay). I prefer to have a separate physical token that doesn't have the ability to run malware, so I don't use the phone, but with the card it takes less time than for cash:
My local convenience has self-service checkouts and it takes their UI a couple of seconds to step through the payment screen. I pop my card on the card reader before I tap the last step of the UI and it's done by the time I reach over to pick it up again.
The US government accepts US dollars and only US dollars in payment for taxes. Last year, the Federal government received $2.3 trillion in income taxes. Assuming that the economy stays broadly the same size, that means this year people in the US will require around $2.3 trillion to be able to pay their taxes. That's what backs the US Dollar. The amount of tax that's paid reflects the health of the economy, so indirectly the US Dollar is backed by the health of the US economy.
It's important to differentiate the form of coinage from the backing medium. Coinage often has little or no intrinsic value. This is especially true of paper promissory notes, which cost a tiny fraction of their face value to produce and have few other possible uses (uncomfortable toilet paper, really tacky wallpaper, or a convenient object for arranging your cocaine in lines). Currencies are typically backed by some promise from an organisation to exchange them for something else. For example, the one Pound Sterling could originally be redeemed for one pound of sterling silver. Most modern currencies are established by fiat: a law requires that they can be used to settle any debt, including taxes, so their value is based on the number of people who have debts that can be settled by the currency.
A crypto currency simply provides an implementation mechanism that allows you to maintain a ledger recording transactions without a single central point of failure. This would address the concerns in TFA, where people are worried that if, for example, the Russians invaded they'd be able to shut down all commerce in a region by flipping a few config options in a computer.
Most crypto currencies have difficulties replacing real-world currency uses because they are entirely decoupled from any store of value in the real world. Ideally (gross oversimplifications follow), the monetary supply should reflect the economy. When more value is created in the economy, more money should be created to represent it. When value is removed from the economy, the money supply should contract by a corresponding amount. The money supply should expand slightly faster than the economy so that holding money is discouraged as a means of holding value (you want people to invest in things that improve productivity, not keep piles of cash under their bed).
I expect the 64-128MB of eDDR as a L4 cache will have more of an impact. For FPGA place and route, we've found that the desktop versions with this are about 50% faster than anything else on the market (performance is dominated by the sequential bits of the algorithm and the working set doesn't fit in cache).
Meltdown allows you to use timing attacks to snoop data across a system call. This is because Intel used an optimisation where they treated system calls as branches, whereas on AMD chips they resulted in a pipeline stall. The Spectre vulnerabilities work at the same hardware privilege level, though not necessarily at the same software privilege level (for example, you can read past a bounds check in a NaCl or JavaScript sandbox and read memory outside of the sandbox, which gives you the memory disclosure vulnerability that you need to launch a code reuse attack).
The defence against Meltdown is to unmap kernel memory when in userspace. This means that the CPU would have to speculate past the CR3 update (switch page tables to the userspace mappings) to be vulnerable. Current CPUs don't do that, because it's really hard to do: You need to be able to invalidate TLB fills, because the page tables that you've installed might be wrong. TLB fills as a result of normal speculative execution are fine, because the TLB is always an arbitrary subset of the contents of the page tables, so you don't need to invalidate them. Sometimes this can even give a big performance boost. Apple found a few years ago that they were getting a big speedup because a mispredicted branch was prefetching some data into the cache that they were using later. The mispredicted branch was much cheaper than stalling for the cache fill. In hindsight, I should have realised that Spectre-like attacks were possible when I learned about this.
The defence against the Spectre variant 1 attack is to add a data dependency where previously there was a control dependency. For example, if you have some code that looks roughly like this pseudocode:
You turn it into something like:
Where the select becomes a conditional move instruction (or some equivalent arithmetic operation). This transformation means that the load now has a data dependency on the result of the bounds check and so won't be dispatched until the bounds check has been calculated. This, in turn, means that there won't be any observable side effects of the load if the branch would not be taken because the instructions inside the conditional will be canceled as soon as the branch is determined to be not taken. This probably has a small performance overhead, because it will introduce pipeline bubbles. I'd be surprised if it were more than 5% though.
Variant 2 involves poisoning the branch target buffer so that at a specific point in execution the CPU will predict a jump to attacker-controlled code. You can then put timing sensitive instructions at that point and probe register values. The mitigation for this is called a retpoline, where you perform an indirect branch using a return instruction, which then uses the return buffer for prediction and so will predict the address after the last call. This basically forces a branch mispredict, but to a location that isn't controlled by the attacker.
Some of the proposed hardware fixes involve not sharing branch predictor state across security contexts. This is not ideal, because often that sharing is beneficial. For example, if you an Android app, it's forked from a zyogte process that sets up the VM and pre-loads a bunch of classes. All apps will have the same core system code in the same addresses and can benefit from sharing branch predictor state. Similarly, if you run a server in a pre-fork model.
Maybe where you are. In the UK, they've basically gone away entirely. The variable rate is about 1.5-2% and no one wants to give you a fixed-rate deal anywhere near that, and no one would be crazy enough to take a fixed-rate mortgage at the 4-5% that the banks might be willing to offer over a 20-30-year period when the variable rate is so low. The ones advertised as 'fixed rate' are actually fixed for 2-5 years and then transition to variable (base rate + some percentage) at the end of the fixed-term period.
Moore's Law gets you better performance because more transistors give you better performance. In particular, Dennard Scaling meant that the smaller transistors used less power so you could have more specialised pipelines, more complex specialised instructions, and so on. Unfortunately, Dennard Scaling ran out about a decade ago, so although Moore's Law has given us more transistors, the number that you can power at any given time has stayed almost constant.
You trust them?
I generally trust corporations to run a cost-benefit analysis before deciding on any course of action. If the cost of getting caught with the data is 1,000 times the financial benefit from retaining the data and the probability of getting caught is 1%, most companies won't keep it. If you double the fines and double the probability of audit every time that a company gets caught, then eventually the converge at making it too expensive for a company to keep.
You don't even need that. Just one disgruntled former employee with a grudge who's willing to be a whistleblower so that they can watch Facebook pay a billion dollar fine.
[1] Somewhat debatable, depending on what you regard as the original railway, but mostly true.
However, unless Apple's rumored new chip suddenly kicks the crap out of an equivalent-gen Intel chip (without turning a MacBook Pro into a room-heater **), this rumor is likely just that - a rumor.
Everyone in this discussion seems to be conflating CPU chip and CPU core. It's entirely possible, given Apple's relationship with Intel (and Intel's attempts to move into the SoC market) that Apple would ship an Apple-designed SoC that incorporated an Intel CPU core with a load of other Apple-designed cores (GPU, Secure Element, other accelerators).
PowerPC code often used Apple's C extensions for vector intrinsics. They provided some shims implementing most of the PowerPC builtins in terms of SSE, but some weren't available. It also didn't help that Apple's vector extensions and GCC's used different syntax for describing vectors, so porting was quite painful. These days, it's comparatively easy to write vectorised code that will take advantage of both SSE and NEON, though don't expect it to have the same performance characteristics on both (or in different Intel or ARM microarchitectures, for that matter).
There are a few other issues. It's not just Bootcamp, it's also WINE. A lot of the 'Mac' games are actually Windows games with a bundled version of WINE. Note that this is WINE, not WineLib. The WINE team now actively discourages use of WineLib because you get odd issues from programs that expect COFF linkage behaviour instead of ELF, for example, and porting is a lot easier if you ship WINE's PE/COFF loader rather than relying on the host platform's ELF loader.
ARM has limited virtualization support - or usefulness for that matter
I'd disagree with the first part of this. ARM's hardware virtualisation acceleration is on a par with Intel's. I'd agree with the latter part though. The common use of virtualisation on macOS is to run Windows in a VM. Unless Qualcomm's ARM Windows platform becomes a lot more popular, I don't imagine there being much call to run ARM Windows on Macs.
Apple loses the economies of scale that Intel enjoys, eating into cost savings
That one depends a lot on how much they can share designs with the iPhone / iPad. If the Mac chips are just a higher core count and clock rate than the iPad versions, then they may get some of this back. Mac, plus iPhone, plus iPad sales add up to about 50% of the total number of PC sales, so they're only a factor of two off.
All existing MacOS apps and games, gone (without either substantial developer support for rebuilds or else subpar emulation, which is not a UX Apple is likely to support)
Note that Apple has done this before. In both the PowerPC and Intel switch, they shipped emulators that allowed you to run existing code. Modern emulators are now pretty good at adjusting call frames so that you can call from emulated code into native code. If you keep the same structure layouts in your legacy and emulated platform then you can share pointers between them. Most Mac apps spend a huge proportion of their total CPU time in Apple-provided system libraries, which is a big part of why Rosetta was so fast in the PowerPC to Intel switch: most existing code (including all of the standard UI drawing, text rendering and layout, and so on) code ran as native x86 code, so the emulator only had to be fast enough that the rest didn't become a bottleneck. OF course, it helped that the laptop Intel cores were about twice the speed of the Freescale ones that they replaced (and had more cores).
At the end of the day, it's really just trading one master (Intel) for another (ARM)
Again, not quite so clear cut. One of the big reasons for the Intel switch was their relationship with Intel versus IBM / Freescale. Apple was the sole customer for both IBM and Freescale in the relevant markets, which meant that they were paying a huge proportion of the total R&D, yet someone else was in control. When they switched to Intel, they were the single largest customer, but were only about 20% of the total.
I suspect that, given the massive growth of cloud stuff, that at least one of Google, Amazon, or Microsoft (possibly all three) is now a larger customer than Apple, which means that Apple is no longer able to demand exactly what they want. There's some evidence for this: Apple customers keep complaining about not being able to buy MBPs with 32GB of RAM, Apple says they'll ship them as soon as Intel produces a CPU that can handle 32GB of LPDDR4, Intel still isn't producing laptop chips that support LPDDR4.
Their relationship with ARM would, again, be very different. Apple is an ARM Architecture Licensee, which means that they are allowed to (and do) design their own ARM-compatible cores in house and ship them as long as they pass the conformance tests. There are also over half a dozen other ARM Architecture Licensees (you can find an abridged list of these in the ARM ARM if you look at the hardware register value that provides the vendor ID, though some companies - including Apple - request not
That's part of the reason I've always avoided the Bay Area. My commute is a 10-minute bike ride. Pretty much anywhere else I want to go on a regular basis is the same distance. The jobs I've been offered in the Bay Area would have involved spending at least 40 minutes each day in a car, probably closer to an hour and even more if I wanted to go anywhere other than home or work. That's too much of a quality of life hit for me to want to take.
Mortgages can go up if interest rates go up (unless you manage to find the rare fixed-term mortgage that remains fixed term for the duration of the loan - around here the longest fixed term mortgage is 5 years and it's at almost double the interest rate of a 2-year fixed-term mortgage). At least here, the difference is that the amount that rents can go up by during a tenancy is limited by law (with some quite wooly terminology) and there's an appeals mechanism if it your landlords puts it up too much (mine went up by about 3% each year when I was renting here, and when we moved out the property was advertised with rent 10% higher than we'd been paying, which creates a somewhat perverse incentive for landlords to have a high tenant turnover).
Typically renting costs $x per month, and buying costs $(x + y) per month.
No, typically renting costs $(x + y + z + w) per month, where x is the cost of mortgage interest, y is the cost of maintenance, z is the cost of administrative overheads of renting (overhead for periods when it's empty, cost of a letting agency and so on), and z is the landlord's profit. Buying costs $a up front (for the deposit) and then $(x + y - v) per month, where v is the appreciation on the house.
Your calculation is whether, if you have $a, you can invest it to make more than $(z + w + v). An abundance or rental properties in an area means one of three things:
Now, it's never entirely safe to discount option 3, because lots of people are bad at maths (though they tend not to be the ones that accumulate enough money to buy multiple properties). Option 2 is fairly easy to check, go to a site like RightMove and see how long properties in your area are typically on the market before they're sold.
Note that I've oversimplified slightly. The x isn't really a common factor that can be removed when comparing the renting and buying cases, because buy-to-let mortgages tend to have higher interest rates. Landlords sometimes include v in their cost of renting - in a few places rent is dirt cheap because the appreciation is so high that people are buying properties just to sell them in a few years and only bother having tenants because unoccupied houses are more likely to be vandalised (and may incur other tax liabilities, require the owner to pay to keep utilities connected, and so on).
I bought a house before I moved here and, including maintenance and mortgage payments, I was paying about a third less than I had been paying renting somewhere cheap (below market rate - the landlady was retired and living in a different city and hadn't put up the rent for years) and less nice than the place that I bought. When I moved here, I rented out my house to a friend, so charged him below market value to have someone I trusted there (and didn't subsequently put the rent up at all). Even though it's relatively old and so has quite high maintenance costs, I made at least a small profit renting it out every year, until I sold it and used the capital to buy somewhere here.
It "fixes" your housing costs in time - rents go up, mortgages don't, bar property taxes.
Only if you have a mortgage with a fixed interest rate for the entire mortgage duration, which I haven't seen anyone offer since before the crash (banks will offer these when interest rates are high, but when they're very low they want to be able to put the rate up when the base rate goes up).
That depends a lot on the property market. Around here, a rented property rarely stays on the market for more than a week, irrespective of quality. Most landlords use the same small set of incompetent letting agencies. If you're unhappy, you move out and they get a new tenant in within a couple of weeks. Oh, and they can legally put the rent up more in between tenants than with a sitting tenant, so they may end up making more if you leave.