https://www.priv.gc.ca/en/opc-actions-and-decisions/investig...
Non consensual adult content, at that.
Truly makes me wonder if xAI/Cursor will honour the spirit of enterprise agreements around data retention.
HN user
[ my public key: https://keybase.io/lattwood; my proof: https://keybase.io/lattwood/sigs/hYhjZ1j1Gynwc-DB-wujRRNiLDrqbTIsGrdqqLM8w1U ]
https://www.priv.gc.ca/en/opc-actions-and-decisions/investig...
Non consensual adult content, at that.
Truly makes me wonder if xAI/Cursor will honour the spirit of enterprise agreements around data retention.
Do children that are the product of sexual assault count?
This is really poor form given that Anthropic is going around getting all kinds of public goodwill for finding CVEs in other people’s products.
Fixed: HTTP request smuggling attack vector
Fixed: missing bounds check in maliciously-crafted Blob deserialization
Fixed: integer overflow in IPC advanced serialization mode with malicious input
Where are the CVEs, Jarred?
Any plans to issue a CVE for this HTTP request smuggling attack vector fixed in the latest bun release?
Wow, I was spoiled building firmware for my ARM boards then (building, not developing).
Marvell has a source available DDR driver that actually takes care of training on a few of their platforms! https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell
8 lets me refresh weekly and have a fixed day of the week to check whether there was some API 429 timeout
There’s your answer.
6 days means on a long enough enough timeframe the load will end up evenly distributed across a week.
8 days would result in things getting hammered on specific days of the week.
At this point I’m not convinced that Gemini 3 Pro was post-trained on data Google had permission to use, going by the myriad of issues on the Gemini CLI tracker around Google AI/Google One/Google Cloud/Google Workspaces.
https://github.com/google-gemini/gemini-cli/issues/12121
It is far too easy to accidentally end up under the wrong privacy agreement, to the point of where some workplaces are banning use of the Gemini CLI!
I think OP is wrong in their hypothesis based on the logs they share and the root cause AWS support provided them.
I think the promotion fails to happen and then an external watchdog notices that it didn’t, and kills everything ASAP as it’s a cluster state mismatch.
The message about the storage subsystem going away is after the other Postgres process was kill -9’d.
How would you propose we address the therapist shortage then?
If the universe is closed and knowable, free will can't exist. Fortunately, Heisenberg left the door open.
unironically, this is such an elegant way to express ray marching
https://github.com/cedardb/DOOMQL/blob/f14b5ef9ef0b23045376b...
The hygroscopic nature of hydraulic fluid is there for the same reason it is in car brake fluid-
it's better to evenly distribute water throughout the fluid, than to have it accumulate in a low point
the log stays on kafka for replay until your per log retention settings delete it
This makes me really wonder about the relationship between Open WebUI & Ollama
OFS was a drop in replacement for EFS and tbh it's insanely good value for the problem space.
I think it's disingenuous to suggest they're putting themselves at a disadvantage with an RTX 3090, especially in a comparison to an inferior product that isn't even shipping yet.
RTX 3090: 24GB RAM, 936.2GB/s bandwidth
Tenstorrent p150a: 32GB RAM, 512GB/s bandwidth
an extra 8GB of ram isn't worth nearly halving memory bandwidth.
At the beginning of my career, I merely found it funny.
Now I find it relatable.
(don't install a signal handler in Python for SIGSEGV, especially if it's being triggered by C you're calling)
more surprising is there's no way for them to delete it from the flatpak registry
"first gen" Model 3s didn't have an emergency rear door release for when the electrical one failed. they've since added that to more recent generations.
but- a car company that doesn't see the need to have emergency rear door releases has systemic issues. someone, anyone involved in approving that design could have said "no. i will not sign off on this", but they didn't.
it makes me wonder what other corners they cut, and whether those cut corners could kill a driver or passenger- because they're not going to cut corners on anything that would be immediately apparent in daily use: it would be detrimental to sales.
I recently explained my personal beliefs around how you square free-will and determinism (and subsequently consciousness) to GPT-4 and it told me this was the more formal name for it.
I posited that if you can observe and reconstruct the entire state of a complex system then you can predict future states- score one for determinism and no free will. But, we know there exists places that we cannot directly observe or perceive, aka quantum uncertainty, represented by σxσp ≥ ℏ/2 [1].
So based completely in theory, I figure the only way we square FW & determinism, is that free will exists somewhere/in a form we cannot directly observe, and it manifests as tiny influences that add up, in the complex system that is a brain.
This is the way more speculative part and it's more fun than anything to think about- it doesn't change the way I live my life buuuut-
Folded brains dramatically increase the influence a given region in space-time can have, simply due to the increased number of neurons. So our brains double as an antenna for some unseen influence that manifests through quantum uncertainty.
So when I explained this to ChatGPT it told me that OORT was very similar to this, but even the mechanism they use for it seems to be a stretch for me.
edit: But I do think that in order for neural networks to become anything other than outwardly really really good approximations of human minds, there needs to be a way to introduce a small amount of genuine randomness into their calculations, without utterly breaking them. I could see early attempts at doing this causing a form of LLM schizophrenia because the neural network wasn't resilient enough to the induced error.
[1] the standard deviation of position σx and the standard deviation of momentum σp is greater than or equal to half the reduced planck's constant
I had to solve a similar problem in Go once, partially to scratch an itch and partially to speed things up.
The S3 AWS SDK has support for doing chunked/parallel downloads if you can supply an io.WriterAt [1] implementation.
type WriterAt interface {
WriteAt(p []byte, off int64) (n int, err error)
}
The AWS SDK comes with an implementation that has a Bytes() method to return the contents, so you can download faster but you can't stream the results.I created a WriteAtReader that implements io.WriterAt and io.Reader. You can read up to the first byte that hasn't been written to the internal buffers. If there's nothing new to read but there's still pending writes, calls to Read will block and immediately return after the next WriteTo call. As bytes are read through Read, the WriterAtReader frees the memory associated with them.
It provides the benefits/immediate results you get with a streaming implementation and the performance of parallel download streams (at the cost of increased memory usage at the outset).
The first "chunk" can be a little slow, but because the second chunk is almost ready to be read by the time the first is done? zoom zoom.
Reminds me of a bug I fixed in yamux, simply because of how long I've had to deal with it. Bug existed for as long as yamux did. (yamux is used by hashicorp for stream muxing everywhere in their products.)
If yamux's keepalive fails/times out, and you're calling Read on a demuxed stream, it blocks forever.
:mind-blown:
i knew about "preconditioning" for SSDs when it comes to benchmarking, etc. didn't realize this was the why.
thanks!
It’s been my experience that async Python frameworks tend to turn IO bound problems into CPU bound problems with a high enough request rate, because due to their nature they act as unbounded queues.
This ends up made worse if you’re using sync routes.
If you’re constrained on a resource such as a database connection pool, your framework will continue to pull http requests off the wire that a sane client will cancel and retry due to timeouts because it takes too long to get a connection out of the pool. Since there isn’t a straightforward way to cancel the execution of a route handler in every Python http framework I’ve seen exhibit this problem, the problem quickly snowballs.
This is an issue with fastapi, too- https://github.com/tiangolo/fastapi/issues/5759
It’ll probably end up similar to Lotus damage, almost an instant write-off.
Configure them to power on automatically after a power loss event and just toggle the power source.
It’s a traumatic birth for sure- but I think in the long run Hashicorp took the right approach. There’s already more FTE commitments from the community than Hashicorp actually had working on it.
I wonder how long until Hashicorp starts to use OpenTF as the upstream for TFE
There’s also the pop on gear shifts, due to killing the spark on gear shifts for a faster shift. The alternative is that awful dreadful rev-hang in standard transmission cars.