barbegal

Not comparable to a real battery any time soon based on the paper https://pubs.rsc.org/en/content/articlelanding/2025/cc/d4cc0...

> The perovskite betavoltaic cell achieved impressive parameters, including a short-circuit current density of 15.01 nA cm−2, an open-circuit voltage of 2.75 mV, and an energy conversion efficiency of 1.83%, all of which represent significant improvements over previous works.

Only 1 of the four turbines has been able to operate for 6 years without pulling it out the water. The other 3 have needed costly maintenance https://www.waterpowermagazine.com/news/sae-secures-loan-for...

It's a nice idea but costly compared to solar even in places like Scotland.

In each loop prepending a single character could take O(m) (moving all m characters one to the right) so combined O(nm) where n is the number of padding characters and m is the total number of characters in the string.

I think the text is wrong, it's diffing two frames and the areas that are the same are where the scorebaord is as this doesn't change between frames but everything else does.

Of course it's not worse, these numbers have huge error bars. Statistically the two statistics are not significantly different. But trying to explain that to most people with no knowledge of statistics is tough.

$313 thousand not million which seems reasonable enough.

I guess the probability of impact won't reach the >50% level until a few months before impact due to variations in earth's orbit and by that point the ability to do anything about it is limited.

There's far too many variables in skin for any non invasive techniques to work reliably in measuring blood glucose levels. The patches work fine and are highly accurate. The real next innovation is implanting devices inside the skin but the miniaturisation of the energy source to do this isn't quite there yet.

Neither of those languages gives you portable SIMD. Rust is rapidly becoming the language of choice for high performance code.

You need to be far more specific than x86, x86 is just the instruction set, the actual architecture can vary massively with the same instruction set.

In general though there is no penalty for interleaved operations.

These days CPUs are so complex and have so many interdependencies that the best way to simulate them is simply to run them!

In most real code the high throughput of these sorts of operations means that something else is the limiting factor. And if multiplier throughput is limiting performance then you should be using SIMD or a GPU.

If you take these corporations to court these arguments don't stand up. In your oil example, if you had a warranty claim due to say a broken suspension component then the type of engine oil used wouldn't be relevant. It just allows them to try to weasel their way out of claims.

But these solutions require two chips, one for bluetooth and one for wifi where the ESP32 does it all in one.

An interesting use for satellite in future will be accurate estimation of solar power output in the very near future e.g. in the next hour period such that grid operators can adjust storage and demand to get a balanced grid. At the moment we can't do these predictions as we don't know where solar panels are in relation to any passing clouds.

It is optimal for expected returns yes.

It would have been a better demo if reduced to more manageable numbers e.g. a deck of 2 black and 2 red cards.

Turn 1 r = b so no bet

Turn 2 bet 1/3 on whichever card wasn't revealed in turn 1.

Turn 3 either you were wrong on turn 2 and you now have 2/3 of your stake but you know the colour of the next two cards so you can double your stake each time to end up with 4/3 after turn 3 or you were right and you have 4/3 of your stake but have one of each red or black left so you don't bet this turn.

Turn 4 you know the colour of the final card so you double your money to 8/3 of your original stake.

And then the exercise to the reader is to prove optimality (which is fairly straightforward but I don't believe there is a short proof)

Stack too small - there's no proof the 8k allocated is too small, is it really exploitable?

Non async functions - pretty common problem but difficult to actually exploit. Every developer who has worked with signal handlers has probably made this mistake at some point because the issues it causes are extremely difficult to reproduce (some incredibly unlucky timing is required)

Arp leaking addresses - Not really a Mullvad issue and only exploitable on the local network

Deanonymization attacks - these work against all VPNs and you can always anonymize traffic more but it has a cost to do this.

Sideloading - Yeah this is probably the worst one but is not exploitable on it's own.

2^(12*4) is 281,474,976,710,656 possible 12 character strings so seriously impressive that it can look through that many in an hour.

Which is why the UK is putting in subsea cables between Scotland and England despite the added cost.

With this sort of tech it only achieves good usability if it is accurate a high percentage of the time. Anything less than 90% accuracy on a whole trip and I likely won't trust it. So that means getting to >99% accurate on each underground train stop. I'm still not sure if this tech reaches that sort of threshold or if this is one of those things that looks like a good idea on paper but falls apart in real world use cases.

The main problem is various vents along the side of the hull. Typically these are placed closer to the centreline of the vessel such that they can't be flooded at extreme heel angles. On luxury vessels they are placed out of sight of guests and in this case along the hull. Hatches into the water tight compartments were close to the centreline but in this case flooding would have occurred rapidly through the various ventilation systems instead.

The boat builder will blame the crew for not closing these but I doubt there was any procedure to actually close them. The engine needs to run to generate power and the engine needs fresh air and an exhaust.

Does anyone know why Mistral use a 17 bit (131k) vocabulary? I'm sure it's more efficient at encoding text but each token doesn't fit into a 16 bit register which must make it more inefficient computationally?

This is why I don't like semantic versioning. Semantic versioning only covers the "public API" but even the smallest "patch" change can result in a change in behaviour which has a big impact on the users.

Could I ask you to clarify why avoiding safemode is so important? In a non satellite system safemode means everything is driven to a safe state which is fine during testing in the lab.

Also do you not run these tests in an even more simulated environment where there is only the flight computer and no real hardware at all?

Battery life is based on playing a 720p video file so most of the expended power will be in the video decoder and screen not the actual CPU. It's also dependent on the battery size in the laptop being tested so pretty much impossible to compare on any like for like basis.

No studies at all, all the claims are anecdotal at best.

If you look at the actual study the effect size is very slight https://www.researchgate.net/profile/Isabel-Gauthier/publica...

The correlation may be just above what the author thinks is significant but eyeballing the data I would say the effect size is simply too small for there to be any meaningful conclusion taken from it.

Pulse width modulation works just as well if the pulse width is short compared to the overall cooking time. And not having an inverter makes it more efficient. Unfortunately lots of cheap microwaves have a pulse width which is more than 10 seconds, presumably to help lifetime reliability, but means that for cooking times less than a couple of minutes it doesn't work well.

Great toy but it's a bit misleading not to touch on the query planner. All real SQL implementations will plan how to most efficiently run a query so the order of operations can be wildly different to expected based on the data and indexes available. This kind of tutorial makes it look like joins are very inefficient whereas a real database may make them highly efficient for a given query.

I think they have linked to the wrong paper. This paper https://cseweb.ucsd.edu/~schulman/docs/oakland24-phyobfuscat... more closely matches the article and it explains that the obfuscation is possible due to the TI CC2640 having a variable frequency synthesiser which has 16 bits of resolution. It's a clever technique but I'm not sure it is easily implemented on other chipsets. And this is only valid against one fingerprinting methodology: carrier frequency offset (CFO), there are other fingerprinting techniques which are more difficult to defend against.