The bubble is propped up by governments.
They don't need "as good as an employee but faster". They just need "faster", so they can process gathered data on an enormous scale to filter out the "potentially good" from the "not worth looking at".
Then they use employees to actually assess the "potentially good" data.
Seriously, intelligence agencies don't need "good ai", they just need "good enough ai".
And they have that already.
What the fuck is a french fry? You mean Freedom Fries?
No idea. Haven't started digging into it yet
27:1 kd would be accused of cheating in video games.
Because this stat isn't really a stat and isn't hyped or published, I'm going by DDG AI assist which suggests US k:d in Iraq is 44:1
The U.S. military suffered approximately 4,492 deaths and around 32,292 wounded during the Iraq War, while estimates suggest around 200,000 Iraqi civilians were killed. This results in a rough kill-to-death ratio of about 44:1, favoring U.S. forces, though this does not account for all combatants and the complexities of the conflict.
Considering that Ukraine isn't killing civilians... Classic AI bullshit uselessness.
If I killed 27 enemy aggressors while defending my country, I would die happy. I don't ever want to be in that position, I don't think anyone should ever be in that position. But that is an achievement, under the circumstances, to be proud of
TIDALs continued awesomeness suggests suitable alternatives.
Spotify pays Joe Rogan how much? And pays artists how little?
TIDAL does music.
I changed a few years ago, and all I miss are the integrations.
I'm lucky that I have decent speakers & dac on my desktop, and decent IEMs. So I can listen to music where I want.
But I can't buy a "tidal speaker" in the way I could buy a "Spotify speaker".
But I'm arrogantly confident enough to waste some money solving this with home assistant, some rpi/nucs, and some speakers. I feel I don't need (I actually don't want a vendor locked in) "just works" solution, and I'm happy rolling my own.
And so it begins
Yeh, either proxy editing (where it's low res versions until export).
Or you could try a more suitable intermediary codec.
I presume you are editing h.264 or something else with "temporal compression". Essentially there are a few full frames every second, and the other frames are stored as changes. Massively reduces file size, but makes random access expensive as hell.
Something like ProRes, DNxHD... I'm sure there are more. They store every frame, so decoding doesn't require loading the last full frame and applying the changes to the current frame.
You will end up with massive files (compared to h.264 etc), but they should run a lot better for editing.
And they are lossless, so you convert source footage then just work away.
Really high res projects will combine both of these. Proxy editing with intermediary codecs
I'd rather they u-turned shitty ideas than waffle-stomp them through.
How the fuck the OSA seemed to just drift through is astounding
I think it's the take(10) that makes it performant.
I guess things like any() will also short-circuit having to process the entire array through a chain of operators before acting on a subset of the final processed array.
If that makes sense....
But if you are filtering then mapping an array, an iterator won't help. You need to go through every element of the source array (to filter) then every element of the filtered array (to map) anyway. There is no opportunity to short circuit, so an iterator won't help.
Edit: and I bet there is overhead keeping iterators active/alive and context switching as each new iteration gets requested, instead of batch processing an array then moving on to the next batch process.
They are only open sourcing the spaghetti that sticks to the wall.
Carefully curated and redacted/obscured/replaced where appropriate.
Probably removing hard coded rules like "always show musk tweets" and stuff like that
What I'd recommend is setting up a few testing systems with 2-3GB of swap or more, and monitoring what happens over the course of a week or so under varying (memory) load conditions. As long as you haven't encountered severe memory starvation during that week – in which case the test will not have been very useful – you will probably end up with some number of MB of swap occupied.
And
[... On Linux Kernel > 4.0] having a swap size of a few GB keeps your options open on modern kernels.
And finally
For laptop/desktop users who want to hibernate to swap, this also needs to be taken into account – in this case your swap file should be at least your physical RAM size.
Spoiler alert: it's just yaml