A lot of money laundering involves traceable transactions, no? The point isn't to hide the transaction but rather have a plausible explanation for it that's difficult or impossible to verify. I'd think a larger issue would be that you can't plausibly charge very much per swipe. I'm betting there's much easier ways to launder cash these days with so many digital goods and services with basically arbitrary profit margins than brick-and-mortar storefronts can provide.
Granted, there are benefits to laundering money with literal cash, but you still want some legitimate money trail even if you don't actually hand over the claimed goods or services—enough at least to cover the actual expenses of the business, i'd presume.
I believe this to be a cultural difference as well as an economic one.
The marginal cost of open source software is $0. But if you license an ARM core, you're paying money for it (like Apple is doing for the M-series processors). ARM has to make money somehow for the development of it's core.
Open source software reduced risk -- though it took a while. And the reduction of risk was valued by most companies who wrote software, or relied upon it for it's profit stream. Major software corporations at the time (IBM, Microsoft) only increased the risk in the 1980/90's, because they were mostly rent seeking.
Most problems were seen over and over and over again, hence they could be solved with software. And when the Microsoft failed to solve them, the open source community did.
In hardware there's only a handful of companies, and open sourcing anything might lead to a competitive disadvantage. So whatever tooling AMD has, they're not going to share with Intel.
Also when you're paying ARM for a license, you're getting a good core, and a lot of good support.
Arguably yes, in a commercial sense. To give the fusion folks some credit, they haven't been promising that commercial products are "just around the corner" for the last 30 years the way QC people have, and the quacks (cold fusion) were excised from the field for making those false promises. I do think that if your field as a whole continually makes huge promises and never delivers, it should probably tarnish that field's reputation.
However, if you're thinking about research grants, no. That's the point of research grants.
How does that work? I'm not familiar with Ray, but I'm assuming you might be referring to actors [1]? Isn't that basically the same idea as multiprocessing's Managers [2], which also allow client processes to manipulate a remote object through message-passing? (See also DCOM.)
According to the docs, those shared memory objects have significant limitations: they are immutable and only support numpy arrays (or must be deserialized).
Although its great the library helps with multicore Python, the existence of such package shouldnt be an excuse not to improve the state of things in std python
Yup, I remember watching a video about how the RAM bus is the bottleneck when running Super Mario 64 on the N64. The original implementation used trig lookup tables, but the person optimized it by instead using Taylor series (I think) and some negation / shifting.
Also enjoy his discovery that, while the game got flak online for years due to the release build have files that were not optimized, it turns out most of the optimizations that were done were actually for the worse due the low instruction cache/ram (I forget the exact details.) Things like unrolling loops just increased the code size and required more slow code paging.
