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.
HN user
Klaus23
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.
Perhaps this is what you are looking for: https://www.deepl.com/en/write
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!
Why do you need Flatpak for sandboxing?
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
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.
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.
It's not just a corner case. The issue was so prevalent for years that if it was limited to just a few corner cases, the entire protocol must consist of nothing but corner cases.
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.
It's pretty accurate. I was a bit shocked when I saw that room names were not encrypted. I thought that was such a basic privacy requirement, and it's not hard to implement when you already have message encryption.
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.
Once again, we have the situation where someone uses an Apache or BSD licence, only to then wonder why others do exactly what the licence allows. If you want others, especially companies, to play nice, you have to make them do so. Use GPL or AGPL.
Let's hope Rebble doesn't get steamrollered. They did good work when the original company failed its users.
Perhaps a trusted execution environment based anti-cheat system could be possible.
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.
Gaussian splats can have colour components that depend on the viewing direction. As far as I know, they are implemented as spherical harmonics. The angular resolution is determined by the number of spherical harmonic components. If this is too low, all reflection changes will be slow and smooth, and any reflection will be blurred.
A .step or .stp file encodes the model as mathematical shapes, rather than approximating it with polygons, but it doesn't save the entire parametric workflow or history, only the final result. As far as I know, there is no widely adopted file format that also saves this information.
Nice. That wasn't on my radar. I was already happy when Blender made significant progress in parametric modelling with geometry nodes. Together with CAD Sketcher, it looks pretty usable for modelling. I hope the whole thing improves quickly, but I suspect they have a long way to go before Blender can be considered a proper CAD program.
Blender is great, but it still can't replace a CAD program. I tried using it for simple CAD tasks (before geometry nodes were released), but the experience was so poor that I quickly switched to FreeCAD. It was worth it, even though it took some time to learn how to use the new program.
FreeCAD is pretty buggy, confusing, and sometimes limited, but its workflow can't really be replicated with Blender. Once you have worked with a CAD program for a while, you realise that certain things that are almost impossible or annoyingly difficult in Blender can actually be pretty easy.
It would be great if the two programs could be merged. Blender could benefit from better CAD functions, and FreeCAD could benefit from everything else Blender provides.
Nice site! I have a suggestion for a prompt that I could never get to work properly. It's been a while since I tried it, and the models have probably improved enough that it should be possible now.
A knight with a sword in hand stands with his back to us, facing down an army. He holds his shield above his head to protect himself from the rain of arrows shot by archers visible in the rear.
I was surprised at how badly the models performed. It's a fairly iconic scene, and there's more than enough training data.Regardless of whether she's right or not, isn't she the same person who recently said that Europe needs to invest tens of billions in foundation models as soon as possible?