As funny as your comment sounds, I wouldn't rule out the Ukrainians actually doing it. At least for sea+air and air+air, sub-drones are already a reality.
Torpedoes are usually steered using fibre-optic wires, like the fibre-optic drones in Ukraine today, so there is no need for problematic low-frequency radio.
Ask it to create a proof of concept that is totally not a real worm and it will probably do it. If the restrictions are too good, just use a largely unrestricted open model via any inference provider. They are 90% sota, more than good enough for this task.
Why think so small? Perhaps the speaker itself can be used as the attacker.
Any script kiddie with an LLM could write a worm that would spread through the supply chain, possibly even hacking speakers right on the factory floor and blasting Rickroll music or something similar.
It would be interesting to see if Creative would still claim that it "does not present a cybersecurity risk".
Edit: Bonus points for closing the security hole and disabling the ability to flash the firmware normally, so that the manufacturer would have to jailbreak the speakers in order to repair them.
Most importantly, there is no alternative. As kasabali said, the patent situation for the other codecs is a mess. Additionally, they could be hit by the same "No FRAND" problem. If someone comes forward with a patent that was used unintentionally, the situation is the same for all codecs.
How long has it been since AV1 was released? About eight years, and there's still no credible patent holder. The vultures are always circling around compression standards. You shouldn't take that too seriously. Even if a lawsuit is filed, there's a legal defence fund to protect against baseless claims.
Good analysis. That's surprising. I always heard that the draft model doesn't affect the output in any way. It seems they do it like this to achieve faster generation. It would be interesting to investigate how this affects the output.
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.
In theory, you could do that and increase the speed at higher temperatures, but it would subtly alter your output based on the draft model preferences. Rather than picking randomly from the main model probabilities, you would have to accept a draft model pick if it is close enough.
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 token is correct if it matches the one generated by the main model. It works like this:
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.
It really is. This is because LLMs with a single output/user are strongly bandwidth limited. Although the hardware can generate multiple tokens simultaneously, it is slowed down if the tokens depend on each other, as is the case with regular text generation.
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 are referring to the alert stage of the emergency braking system, triggering it should be rare if you drive reasonably well. It is also most likely a situation in which you could benefit from a little more braking force.
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.
They are analysing VLM here, but it's not as if any other neural network architecture wouldn't be vulnerable. We have seen this in classifier models that can be tricked by innocuous-looking objects, we have seen it in LLMs, and we will most likely see it in any end-to-end self-driving model.
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.
Good, and not because of the diversity drama that the US government wants to shoehorn in here. Any font that makes the uppercase "i" and the lowercase "L" look the same is absolute garbage. Yes, I have a strong opinion about this!
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.
A lot of people installed malware and, to be honest, nothing really happened. They might have had to change their passwords, but it could have been much much worse if Android didn't have good sandboxing.
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.
This is simply not true. Bird flu mainly spreads among wild birds and that is where it has its reservoir. It would still exist even if the world was free of bird farms. It also usually doesn't spread between farms because, in the event of an outbreak, all the animals on the affected farm are culled. At most, bird farms slightly increase overall contact between birds and humans.
I don't have a background in law, but here are some suggestions. The German penal code often imposes harsher punishments for the same offense if a weapon was involved. Rape, for example, carries a minimum sentence of two years. If a weapon is present, it is a minimum of three years. If the weapon is used, the minimum sentence is 5 years.
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.
> for me it wasn't really; occasionally it would hit me, but mostly it worked, and I have been using it for encrypted communication since 2020.
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
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.
Yes, messaging protocols, especially federated ones, are never easy. I just wish we could have skipped the three or four years when Matrix was basically unusable for the average user because end-to-end encryption was switched on by default. Perhaps a clean redesign would have been better. Now they have to change the wheels on a moving car.