Edit: I haven't gone through all the code, but they might do something like this: https://arxiv.org/abs/2211.17192 where a draft model is used and the output distribution is tweaked on rejection, resulting in the exact same distribution as the main model.

As far as I know, this is not used in practice. Currently popular implementations always match the main model output, and the draft model only affects the speed.

The draft model quickly generates draft-token 1.

The main model then starts working on two tokens in parallel. It calculates token 1 based on the context, and token 2 based on the context + draft-token 1.

Once the two tokens have been generated, you can check whether the draft-token 1 from the draft model matches token 1 from the main model.

If they match, you have just calculated two tokens in the time it takes to generate one, because the calculation was done in parallel. If they do not match, delete token 2 and generate it again. Since you have already generated the correct token 1 with the big model, you can use the context + token 1 (from the main model). This takes more time, but the result is always the same.

The draft model essentially predicts the next token quickly, enabling you to start generating the subsequent token in parallel. If the guess is right, the second generated token is correct. If it is wrong, the second generated token is also potentially wrong, so it must be generated again using the correct prior token obtained through the big model.

A poor draft model will simply slow down the process without affecting the output.

If you decide to swerve, the additional weight at the front will help you to initiate the turn, and good systems will then reduce the braking force at the right moment to give you the most traction when cornering.

It corrects spelling errors and improves awkward wording. You can then go and choose alternative sentences or words. Just don't expect any sort of deeper intelligence.

If an end-to-end model is used and there is no second, more traditional safety self-driving stack, like the one Mercedes will use in their upcoming Level 2++ driving assistant, then the model can be manipulated essentially without limit. Even a more traditional stack can be vulnerable if not carefully designed. It is realistic to imagine that one printed page stuck on a lamppost could cause the car to reliably crash.

You don't, but as far as I know, Flatpak or Snap are the only practical, low-effort ways to do it on standard distros. There's nothing stopping flatpak-like security from being combined with traditional package management and shared libraries. Perhaps we will see this in the future, but I don't see much activity in this area at the moment.

I hope that Flatpak and similar technologies are adopted more widely on desktop computers. With such security technology existing, giving every application full access to the system is no longer appropriate.

Before the change, date rape drugs would have fallen under a minimum of three years because of a separate clause.

Classifying them as weapons would also affect crimes other than rape.

Additionally, if legal substances can be used as date rape drugs, classifying them as weapons would give the police more authority to act in certain situations.

I think the statistic said that around 10% of users receive at least one "unable to decrypt" message on any given day. That's a lot. Perhaps not for devs who are accustomed to technical frustrations, but for non-technical people, that's far too frequent. Other messaging systems worked much better.

> There still can be technical corner cases in the interaction of clients

> a talk for details: https://www.youtube.com/watch?v=ZUSucR2axWI

You linked to a German political talk show. If you wanted to show me the talk in which the guy listed reasons such as "network requests can fail and our retry logic is so buggy that it often breaks" and "the application regularly corrupts its internal state, so we have to recover from that, which is not always easily possible", let's just say I wasn't that impressed.

> well, even if this was true, they still were brave enough to try and eventually pull it off eventually. Perhaps complain to the competent people who haven't even tried.

It isn't a problem that the Matrix team are not federated networking experts. At the time, they had already received millions in investment. That's not FAANG money, but it's still enough to contract the right people to help design everything properly.

I'm not mad at them. Matrix was a bold effort that clearly succeeded in its aims. I'm just disappointed that it was so unreliable for such a long time, and still is to some extent.

It frequently occurred on the "happy path": on a single server that they control, between identical official clients, in the simplest of situations. There really is no excuse.

I'm not saying that building a federated chat network with working encryption is easy. On the contrary, it is very hard. I'm sure the designers had the best intentions, but they simply lacked the competence to overcome such a challenge and ensure the protocol was mostly functional right from the outset.

Matrix seems to have a lot of these structural flaws. Even the encryption praised in the Reddit post has had problems for years where messages don't decrypt. These issues are patched slowly over time, but you shouldn't need to show me a graph demonstrating how you have slowly decreased the decryption issues. There shouldn't be any to begin with! If there are, the protocol is fundamentally broken.

They are slowly improving everything, with the emphasis on "slowly". It will take years until everything is properly implemented. To answer the question of whether the future of the protocol is promising, I would say yes. This is in no small part because there are currently no real alternatives in this area. If you want an open system, this is the best option.

Let's hope Rebble doesn't get steamrollered. They did good work when the original company failed its users.

I think Valve said something about working with anti-cheat developers to find a solution for the Steam Deck, but nothing happened. Perhaps they will do something this time.

With a TEE, you could scan the system or even completely isolate your game, preventing even the OS from manipulating it. As a last resort, you could simply blacklist the machine if cheats are detected.

There would probably still be some cheaters, but the numbers would be so low as to not be a problem.