Chabsff

That doesn't work because it's not the ads themselves that serve the malware, but the page the ads point to. Changing that after the review is done is trivial, and asking landing pages to never change is simply unreasonable for a vast number of reasons.

It works the other way around too: We read this is a self-deprecating joke because we are anthropomorphising the author.

The reaction to this doesn't surprise me, but honestly? I think twitch did the right thing here (though probably for the wrong reasons).

Was this joke punishable? Not by itself. However, it is strongly indicative that the safety nets required for that type of content to respect the TOS are not working properly.

If you have watched any amount of this stream at all, you know that:

a) It doesn't do self-discriminating humour. b) It's funny because it's really bad at delivering joke.

For someone familiar with the content, it's a lot likelier that this was a terribly delivered offensive joke than anything else. Which means that more such content is coming, and there is no way to tell the "author" to cool it.

Put another way: If you are Carrot Top's promoter and he drops a Jimmy Carr joke in the middle of a set out of nowhere, taking a break from touring might be a good idea.

You have to put it in context. That stream is/was something very particular.

The AI is terrible at making jokes, so the stream is funny to watch because it's a non-stop torrent of repeated failed attempts at telling jokes.

"Regular" jokes are delivered in the exact same way, with the exact same result. What you are reading as intentional irony and/or sarcasm really is just you projecting your expectations.

There is no way whatsoever to distinguish a self-deprecating joke from the failed delivery of an offensive one. If anything, the latter is more likely than the former, since failed delivery is the norm. (Talking about this stream in particular, not AI-generated humor in general.)

Each Tether, on paper, represents a single US dollar locked into the crypto ecosystem.

It's kind of like a company's war chest bank account: no matter what happens, the value of the asset is worth at least that much.

But it's a little more pernicious than that. Tethers are typically emmited conveniently at times where the price of crypto is going down, propping the value up. If the current value of BTC exists because of artificial upwards pressure, it's likely that the value should settle back down to where it would have been if not for said pressure when released from it.

A tether collapse would instantly reduce the USD market cap of crypto by 80 billion, and that's without any investor behavior added on top.

On top of that, Coinbase needs a stable coin to operate at any non-trivial scale.

I'd say the impact would be severe. That is unless crypto investors just pretend nothing happened, and some other bullshit stable coin immediately takes care of the liquidity issue, which I'd call likely.

Centralized exchanges provide a lot more essential facility than fiat to bitcoin conversion. In particular, they provide acceptable transaction fees and acceptably fast transaction turnaround time.

Revolutionise what?

Sure, we can hand-wave away that it'll revolutionise *something*, but there's no direct candidate on the horizon. As of today, at best we can hope that more accurate quantum simulations could lead to some breakthrough tech, but that's a very indirect revolution at best.

With LASER, at least, there was a bunch of known use-cases that were blocked by the availability of the tech. There are no such equivalents here.

Consider that the Jeopardy stunt was basically a sales pitch saying: "If it can do that for Jeopardy, then just imagine what it can do for you!"

There is definitely an argument to be made that this was an empty promise. Not necessarily enough to call it a "scam", but vaporware...

Kinda-Sorta. It depends on what you mean by "success". IBM has been doing a commendable job at managing expectations wrt/ quantum computing. e.g. from this very article:

"The new 433 qubit 'Osprey' processor brings us a step closer to the point where quantum computers will be used to tackle previously unsolvable problems,"

So we can reliably expect them to ship what they are promissing. However, there is still a massive skew between what QC brings to the table vs what the public (and investors) are expecting from it. At the current trend, anything QC-related is effectively guaranteed to qualify as vaporwave due to the public at large being mislead on the subject for so long.

Their point is that the current decentralised Bitcoin is functionally unusable and simply not ready for mass use.

In that sense, a truly decentralized Bitcoin that people can actually make use of doesn't exist.

Learning to code is ultimately not about learning a pile of information. It's about learning how to react when faced with a wall. There is definitely something to be said in favour of presenting students with small walls to face before presenting them with large-scale and cognitively overwhelming problems.

The concern here is that most of what we've been using as "small walls to conquer" are trivially solvable without having to go through the problem solving process. But I think this is excessive hand-wringing. StackOverflow is already as disruptive as can be on that regard, but that doesn't prevent a plurality of students from going through the motions for the sake of learning the "craft".

the Brave browser could have been Chromium with uBlock Origin pre-packaged with it. That's it. That's all it ever needed to be.

Looking around the codebase, it's filled with eyebrow-raising things like direct integration with specific crypto exchanges. Heck, it still has a whole automatic affiliate fraud feature present in the code, but disabled by default.

The truth is, the mission statement is not commercially viable, because it was always trivially achievable as a non-profit project.

Maybe it's simply just not commercially viable in any way shape or form to build an ethically responsible web browser and distribute it for free.

Sounds about right. Thank you.

Early on in this debacle, I remember someone pointing out that Niemann's performance could be explained relatively easily by him having forward knowledge that Carlsen intended to use the unusual opening he went for. This would amount to cheating "in spirit", by way of having an unfair advantage over his opponent, while still being tournament legal.

Whatever happened to this version of events? It struck me as being a lot more credible than engine assistance.

Just in case you posted this as a counterpoint to what I'm saying...

This blog effectively agrees with my position: Undefined Behavior is just "Stuff the compiler is allowed to assume never happens". And C++'s set of Undefined Behaviour is a fundamental part of what makes it valuable.

The issue I have is not with them, but rather with the fact that it's too easy to become competent, if not talented, way past the point where one should take them into account without having to even know of their existence.

Strict aliasing is what prevents compilers from having to sprinkle Load-Hit-Stores all over the place. This is not a marginal performance difference, and doubly-so for CPUs with deep execution pipelines. It also has massive code-reordering implications.

In any case, Strict Aliasing is not a flippant rule that compilers like to apply. It's a formal component of the ISO standard that C++ is.

You can chose to make a deal with a compiler (via a flag) to compile otherwise non-compliant code in a consistent way, but that does not change the fact that the code is non-compliant.

That's not even particularly good advice, which just goes to show how subtle the pitfalls are. The rule really should be "If it is at all possible to delete instances from a pointer to the base class, then you need a virtual destructor". The overhead of adding a virtual destructor to a base class with no other virtual functions is far from negligible in many cases, so the distinction is meaningful (though modern guidance tends discourage non-polymorphic inheritance in the first place anyways).

The same thing goes for the good-old "Do not use raw pointers." The rule is actually: "Do not use raw pointers with implicit ownership semantics attached to them."

C++ without strict aliasing is not C++ anymore. Furthermore, that was just an example. There are other such concepts, such as the illegality of accessing memory as anything else than raw bytes or the type of the object that resides there (which also applies to union fields). Another one would be the fact that signed integer overflow is UB.

C++ is so tightly bound to memory layouts that once you start getting a solid mental model of what's going on, it's really easy to come up with legitimately neat and creative ideas that work very well and fast on a test bench environment without any complaint from modern compilers, but are fundamentally broken. I feel we do not do a good job at equipping up-and-coming programmers so that they can benefit from that mental model without writing code that only works out of sheer luck.

In the extreme, you can write code that does stuff like dynamically retype an object by swapping out its vtable when vtables are not even thing as far as the language is concerned. It's astounding what it sometimes feels like you are capable of doing in C++.

And this half of my main beef with the language. To be clear, I absolutely agree that this aspect of it is wonderful, but it is a double-edged sword, and the edge pointing at the programmer's face is very sharp.

The second half of that beef is that most C++ learning journeys bring the learner up to the point of creativity without addressing concepts like Strict Aliasing which are not useful until you start getting "creative". That's big a problem because code containing strict aliasing violations (and/or any of a myriad of other UB) is often fundamentally broken while giving the illusion of behaving as intended.

Two things are wrong here:

1) The reason it can't be done with EVE is not because EVE is not on the blockchain. It just happens to not be possible because the devs didn't make it so. They could have, but they chose not to.

2) Something being on the blockchain does not make it automatically permission-less. It depends on how the smart contracts involved are coded.

I think point 2) is something that a lot of people don't realise wrt/ NFTs. The NFTs are transferable without the author being involved because the Smart Contract that drives them has a function (aka an API endpoint) that provides that feature. It is not a property of the blockchain itself. It is a property of an arbitrary piece of code that happens to reside on the blockchain. A property that any web service is capable of providing without the blockchain having to be involved.

Sure, but my point is that the lack of blockchain technology is not what's preventing most games from featuring this, it's only the developer's willingness to do so.

Thank you for the verbose answer, though I disagree with most points.

1) "having everything trading for essentially real money doesn't change that underlying level of engagement." It has been long established that this is absolutely the case. A classic example of this would be Diablo 3's RMAH effectively destroying the game by having the entire economy be driven by real-world profit-seeking grind

2) I consider this to be very misleading. All of these intra-game features are not made available by the blockchain itself, but by the details of the various Smart Contracts involved. In that sense, the set of instructions available to would-be developers to interact with a game is going to be limited by the operations (and the various rules governing them) that are present in the smart contracts. If a game features permission-less development like this, it's because its developers have decided to make the requisite operations available and documented. This is no different than a regular documented public API.

3) I see nothing preventing this from being done without the blockchain.

4) This is the one potentially interesting wrinkle, but I find it to have marginal interest at best. Assets are inherently immortal unless explicit steps are taken by developers to prevent them to be. What is actually at play here is Immortal Entity Ownership, aka Immortal Scarcity. That's very interesting from a revenue-making potential, but not really much more than that.

5) That does not make the game itself better though.

This is not inherently made possible by the blockchain itself though.

The mechanisms to transfer a Kitty to the HyperDragons lie within the CryptoKitty Smart Contract. This is not particularly different than a regular API, where the available operations have been chosen, specified, and made available to the public at large by the developers.

The only real difference with a public-facing documented traditional API is that said API will outlive the original product. But that doesn't make CryptoKitties a better game, since Cripto Kitties won't be a thing anymore when that comes into play.

You cannot have a conversation about "crypto games" without addressing how crypto makes the game better. For the sake of this conversation, it doesn't particularly matter how fun CryptoKitties is. What matters is how does the blockchain integration make the game better than it would otherwise have been.

From my point of view so far, even the best crypto game out there would have been better if it wasn't for the crypto aspect of it.

If this ecosystem is to provide value beyond the potential for making money, then what is it? It's hard to be excited about something that only has downsides.

If CO2 reduction was the only goal, then yes, that would be a very steep number. That's obviously not the case though.

Hard disagree as far as the portions of it that are part of the user-facing public interface are concerned.

But granted, as a general rule you are correct. I was referring specifically to API interfaces.

In strongly-typed programming languages, which includes Typescript, figuring out the types *of the interface* is not something that's done after the fact. `@types/*` is an exceptional project meant to back-port JS libraries to TypeScript, but that's the exception, not the rule.

If you write a library in TypeScript, determining what types are present as part of the interface is one of the very first thing that should be done.

The general idea is that for something to have monetary value, it has to be scarce. Why would you ever trade a loaf of bread for something that you have an infinite supply of in the first place?

Cryptocurrencies are fundamentally a means of creating a decentralised digital scarce resource, and the Bitcoin blockchain is a rough proof of concept that it is theoretically achievable, albeit using a spectacularly inefficient method.

Artificial digital scarcity is the whole point.