The payer couldn't care less about how much the store pays for the transaction. He or she just wants to tap with their phone, and the default here are Visa/MC cards. In addition to the transaction price not being an argument for the payer, Wero also afaik does not have as much consumer protection as (certainly some) credit cards offer. I also bet the average person doesn't understand or care about the whole political dispute either. Again, they just want to pay easily and safely.
I don't think Wero can "win" this from just the merchants side. It's got to be better for the customer's side.
In addition, this only starts in 13 countries. There are 27 EU members. So there is a lot of big ambitions but not followed by actions. Which is what we are sadly used to.
So when I from Slovakia want to buy something in a French eshop, I'm out of luck. And when on a vacation, can't use this system either, while a French person on a vacation in Slovakia can't use it either. My guess is people will mostly continue to use credit/debit cards.
The whole SEPA area has instant SEPA payments. You can stick that into QRs or whatever. Some merchants take payments by SEPA, instant or not, but we need something else if we want to replace both online and in-person card payments throughout the whole EU, and at this point I doubt the Wero will be the replacement.
Not everyone is in eurozone, there are countries with instant QR payments that are not SEPA. It is nowdays quite common to get a QR with your invoice, online or in person, it might not be just SEPA. But for now cards are still more accepted, and work even if I leave my phone at home or it rans out of battery. Not sure how Wero or QR going to solve that, SEPA or not, but still useful for a lot of cases, online payments etc, even if it does not solve every edge case.
Every EU country even outside of Eurozone is in SEPA. But SEPA payments can have their own issues - I believe they were not free in all countries some time ago, not sure what the status is currently.
There might be other instant QR payment systems out there though - I digress but on our recent visit to China we had to use Alipay as the cards are not accepted at most places and of course it works through scanning QRs, either you scan the vendor's code or they scan yours, and then you enter or confirm the amount and that's it. But the issue I have with these systems is the same as yours - we are fully dependent on our phones with no backup.
"Hey buddy, I give you a tiny tiny discount if you pay without fraud protection..."
I mean, some places do that. But for the consumer there is no advantage. It's probably fine at cafés, restaurants and such. But why would you as a consumer want it for any more important purchase? As you mention.
Yes I think the article is vastly overstating the importance of this payment system, but do not underestimate the importance of the sentiment behind it.
The US is done as a global power, all their soft influence is gone, and the EU sees them as an adversary now.
will depend on how it's implemented, you could end up paying via a QR code, contact less NFC, a phone number, the web. I think it could open up a lot of innovation
The author cites this to justify the need for Records:
> Most Java objects set every field to be private and make all fields accessible only through accessor methods for reading and writing.
> Unfortunately, there are no language enforced conventions for defining accessors; you could give the getter for foo the name getBar, and it’ll still work fine, except for the fact that it would confuse anybody trying to access bar and not `foo'.
Scala supports pattern matching on objects implementing the `unapply` method.
Is this considered harmful? Why didn’t Java follow this route?
it's a matter of standardisation again. Java's standard is like C++; ponderous. The record pattern jep indicates in final footnotes that something like unapply may be in the works, so all hope is not lost.
The whole point of WEI is that the site can choose to block any combination of browser and OS they see fit, in a reliable way (currently, browsers can freely lie). CURL and friends will almost immediately be branded as bots and banned - that's the stated objective.
It is more severe than that. The design favors a whitelist approach: Only browsers that can get the attestation from a "trusted source" are allowed. Browsers that cannot, don't.
On linux distros, the package manager downloads different binaries based on your CPU. Skylake would be x86-64-v3, Zen 4 would be x86-64-v4, for example.
And there are different schemes for multiple architectures in the same program, like hwcaps.
The extensions can be kinda broken down into 4 levels. Basically ancient, old (SSE 4.2), reasonably new (AVX2, Haswell/Zen 1 and up), and baseline AVX512.
There is discussion of a fifth level. Someone in the Intel Clear Linux IRC said a fifth level wasn't "worth it" for Sapphire Rapids because most of the new AVX512 extensions were not autovectorized by compilers, but that a new level would be needed in the future. Perhaps they were thinking of APX, but couldn't disclose it.
Work out what it would cost to compile - say - a terabyte of C code at typical cloud spot prices.
A large VM with 128 cores can compile the 100 MB Linux kernel source tree in about 30 seconds. So… 200 MB/minute or 12 GB/hour. This would take 80 hours for a terabyte.
A 120 core AMD server is about 50c per hour on Azure (Linux spot pricing).
So… about $40 to compile an entire distro. Not exactly breaking the bank.
you'd have to separate out compiling and linking at a bare minimum to get even a semi accurate model. plus a lot of userspace is c++, which is much, much slower.
in the end it will be like any other modern hardware appliance:
the hardware is the same design for cost saving purposes, but different features are unlocked for $$$ by a software license key.
You want AVX-512? pay up and unlock feature in your CPU and you can now use the feature. This could also enable pay-as-you-go license scheme for CPUs, creating recurring revenue for Intel
from the hardware perspective - the same silicon, but different features sold separately
Yup. It's one of their theoretical advantages that's about to become a lot less theoretical. Historically it hasn't made much difference because optional instructions were hard for JIT compilers for most languages to use (in particular high level JITd languages tend not to support vector instructions very well). But a doubling of registers is the sort of extension that any kind of code can immediately profit from.
Arguably it will be only JITd languages that benefit from this for quite a while. These sorts of fundamental changes are basically a new ISA and the infrastructure isn't really geared up to make doing that easy. Everyone would have to provide two versions of every app and shared library to get the most benefit, maybe even you get combinatorial complexity if people want to upgrade the inter-library calling conventions too. For native AOT compiled code it's going to just be a mess.
