fyi1183

Please point out where somebody genuinely puts an effort to found math on category theory? The standard way to do so is set theory, and the more recent hype is type theory.

Category theory in itself is pretty useless. Categories are a bit like graphs in that: they are too general.

There are serious mathematical theories using category theory as their language (mostly commutative algebra and whatever it touches) just as there are serious theories using the language of graphs, but in both cases the meat of the math is not in the underlying language.

To be fair, AMD's Linux drivers have been pretty solid for a while now. I don't have an objective comparison, but the general perception definitely has some catching up to do. For those Ryzens you'll probably need a very recent kernel, but that's to be expected with new hardware.

It can be done with essentially a recompile as long as it's all digital, but the result won't be great. If you want to use area well, get high clock rates and power efficiency, you really need to spend a significant amount of effort on physical design.

Technically speaking, you have to worry about these things on FPGAs as well.

But FPGAs and ASICs are quite different, so you'll have to adjust the design for those differences. In fact, you may have to adjust the design when switching fabs, because of process differences and resulting standard cell library differences.

Not to mention the lost opportunities for delta compression.

We generally cannot prove things about physics in a mathematical sense, but assuming that our understanding of quantum mechanics is correct, every interaction of an entangled particle causes its entanglement to "spread" to the interacting object. That's just a property of the math involved in describing quantum systems.

This means that once you have macroscopic interaction, the entanglement basically starts to spread at the speed of light, i.e. it'll quickly spread to humans.

Once you are entangled with something, you can no longer observe the effects of that entanglement (you are no longer an external observer), and it looks as if the entanglement was destroyed.

Non-determinism comes from randomness in the hash function. I don't know the details of the Python implementation, but generally you want randomness at the very least when processing potentially hostile user input. Otherwise your code is susceptible to a denial of service attack where the attacker sends data that was crafted to maximize hash collisions, to break the expected performance of hash tables.

From a theoretical angle, the only way to build hash tables with some kind of provable runtime guarantees is to include randomness.

Presumably, computers can get better at driving cars while humans cannot, so eventually computers will win this particular competition like they've won on chess, go, and tons of other things.

Honest question: does the Austrian in your example not understand the deadpan/sarcasm or is he/she merely annoyed by it? Sometime it may not be a question of understanding but just of preferred communication patterns.

But yeah, there's definitely a lot of culture and context involved.

AlphaGo also uses a tree search algorithm.

Every tree search algorithm needs a guiding heuristic, and that's what AlphaGo replaces with a neural network.

So both DeepBlue and AlphaGo are fairly described as being based on tree search.

I think it's a bit unfair to pretend that TLS replay would be the same as having a not entirely updated IPNS record. The threat models are very different.

The corresponding attack against IPNS would be if the attacker could make your perspective of the world go backwards, and that is prevented by the sequence number.

With FileCoin (the IPFS-related ICO with no implementation), the idea is that you're offering your storage space to others in exchange for a fee. So somebody could use your system to store, say, child porn.

With plain IPFS that cannot happen, because you're only downloading what you're interested in. That's what I meant when I wrote that IPFS is like Bittorrent.

You don't really upload things to IPFS, since it works like Bittorrent: you make files available by adding them, but that doesn't copy those files anywhere. They're only transferred via the network to clients that specifically request them, which makes this a non-issue.

Now FileCoin, that's a different issue...

IPNS records have an optional and user-configurable expiry time, but more importantly, they contain a sequence counter.

So unless an attacker can completely disconnect you from everybody else who's interested in a particular IPNS address (and in that case you're lost anyway), they can't hoodwink you into going back to an old version.

The HTTPS is served by the proxy, it has nothing to do with IPFS.

I assure you that it's possible. To give you a hint without giving everything away: the guess of the first person must be derived from the colour of all other person's hats.

You could think of it as a puzzle in coding theory, and it's not implausible. If you sum up the number of hats that each person sees and the number of guesses they hear, you'll note that everybody has 9 bits of information available. And they're supposed to make 9 correct guesses. It adds up.

Another hint would be to think of the case of 3 persons first. That can be done with patient case analysis, and it's likely to get you an idea for generalisation.

The best literary treatment of the general idea of attempting to preserve knowledge by creating some sort of priesthood, though not specifically for the purpose of waste warnings, is A Canticle for Leibowitz in my opinion. I highly recommend it.

Radeons compute units are in-order though, in the usual sense of the word, and I'd love to hear it if there really was an out-of-order GPU. It'd be rather surprising.

One thing that they do have to deal with data dependencies is that load (and texture fetch etc.) instructions don't block. Instead, there's a separate instruction for waiting on the result of a previous load.

Doubtful. You don't just develop a new processor over night, and if they truly had all these aces up their sleeves, they would have dropped them already in response to Zen last year.

Intel's process advantage is shrinking. They're struggling like everybody else because the physics is getting harder and harder. Apart from the fact that it would have been nice to get easy process shrinking forever, this is good news for almost everybody: it means competition for them is getting tougher.

You don't actually have an argument though. Why is the CPU wrong? Because you say so? And btw, you're wrong about this not affecting ARM or AMD. It affects everyone with speculative execution (we're only talking about Spectre variant 1 here - if you're confused about that, please go back to my first comment in this thread).

Look: When other side channel leaks were found, e.g. people recovering RSA or AES keys from plain cache timing without speculative execution, maybe there were people similarly arguing that it's the CPU's fault. They lost that fight, too. Today, the uncontested consensus is that cache timing leaks are the code's fault, for good reason.

Because what are you going to do, stop building caches? Obviously not, they exist for very good reasons. The same is true for speculative execution. What do you expect CPU people to do? Rip that out entirely? Be real. (Please, seriously think about that: what is it that you actually want CPU people to do? Don't just handwave!)

This kind of discussion is why Linus Torvalds regularly flames security people.

You could ask the same question about any class of security bug, so unsurprisingly I'd answer more or less in the same way.

For example, if you're paranoid, make your compiler be conservative, in the same way that you might address buffer overflows by using a language/compiler that inserts bounds checks everywhere.

If you're less paranoid and/or more worried about performance, invest in static analysis tools or languages with augmented type systems. After all, you only have to worry about Spectre variant 1 when handling attacker-controlled data. Tracking type info like this is already done by existing static analysis tools.

Finally, if you're not handling attacker-controlled data at all - which is the case for a lot of performance-sensitive code - you really don't want to (and don't have to) do anything about Spectre variant 1.

By the way, this is really the big difference between the two Spectre variants, and why it's a shame that they fall under the same name. Variant 2 affects all code with indirect jumps/calls, even code that doesn't ever touch attacker-controlled data. That's a huge difference between the variants.

Anyway, the bottom line is that you shouldn't punish the performance of all code over a class of security bugs that a lot of code isn't affected by. Buffer overflows haven't stopped us and shouldn't stop us from writing performance sensitive but security uncritical code in unsafe languages either.

I'm not a CPU architect, and I'd agree with you that Spectre variant 2 should be fixed by CPU designs, simply because software is helpless against it. Luckily, fixing it shouldn't be too expensive, it just requires tagging the BTB with the trust zone.

But Spectre variant 1 is really a consequence of the CPU working correctly. For a large number of branches, perhaps most, we want loads to proceed during speculative execution. This is because the code accesess the same or closely related data on both sides of the branch, so priming the caches during speculation is very valuable even when the branch is mispredicted.

I remember reading a study of different binary search implementations which is probably the clearest example of this: when the data is laid out in a heap layout (with child nodes next to each other in an array) the branchy variant of the code performs better than the branchless variant due to this cache priming effect.

What CPU designers could and should probably help with is providing instructions to cheaply mark the (comparatively few!) cases where this speculative execution behaviour leaks secret information.

Not sure what "you" you're talking about. I'm telling you the truth about my Steam use, so your comment feels pretty weird.

It's true though that the availability of games is much less on Linux.

Funny, I do all three of these on Linux.

That sounds wrong.

First of all, backwards compatible changes in libraries don't need application updates, by definition.

Second, if your library changes are backwards compatible, you can maintain separate release cycles - this is the normal way of doing things, actually.

Third, microservices simply don't allow backwards incompatible changes. This is a big hint that perhaps your libraries shouldn't do backwards incompatible changes either, as a matter of policy, even though doing them is theoretically possible.

Perhaps you meant deployment instead of releases, and were assuming static linking?

If you really meant for the 10x to only be an example, you should have clearly stated that.

The 10x thing is a common misconception generated by the fact that 10 is a nice round number that works well for this type of just-so story.

The Wikipedia article on reserve requirements has a handy table by country, from which you can see that the required ratio is actually less than 10 in most of the developed world.

In fact, several countries have no reserve requirements at all! Following your logic, those countries should be even more volatile than whatever is going on in crypto currency land. I think we can safely conclude your logic is flawed.

Mind you, I still think the whole tether business is extremely fishy. I'm just annoyed by the spread of monetary just-so stories that pretend to apply to the real world. Reserve requirements are a red herring in modern monetary systems, because central banks will always guarantee liquidity by acting as a lender of last resort.

It would be better for the salt to be private (and revealed at the same time as the name), otherwise a miner could still try to guess at the name being reserved. Having a public salt only eliminates the possibility of precomputing many hashes, i.e. rainbow tables.

What's also pretty clear is that nuclear weapons had nothing to do with ending WW2 in Europe.

To put it mildly, that seems pretty unlikely given the ridiculous amount of know-how and capital investment required for chip manufacturing.

Legal tender has a specific legal meaning. I can assure you that the USD is not legal tender almost everywhere in the world.