" Combined with this only happening in a corner case (stale sessions) and the difficulty of reproducing the issue, it took us over a week to discover and confirm the root cause"
I don't know about others, but sessions that are idle > 1h are definitely not a corner case for me.
I use Claude code for personal work and most of the time, I'm making it do a task which could say take ~10 to 15mins. Note that I spend a lot of time back and forth with the model planning this task first before I ask it to execute it.
Once the execution starts, I usually step away for a coffee break (or) switch to Codex to work on some other project - follow similar planning and execution with it.
There are very high chances that it takes me > 1h to come back to Claude.
I was going over some of the code in the core folder for concurrency, threading and compression, what surprised me is that there’s absolutely no comments whatsoever. Agree that unless there’s excellent documentation, open source maintenance might be challenging.
Having said that, this definitely does look to be an impressive feat of engineering!
This looks very impressive!
As another commenter echoed, the code base is ~5million lines of C++ code, but almost no comments at all. Unless the documentation is excellent, maintenance/open source work is going to be difficult.
While transforming the plan into vectors is interesting, I wish they'd gone into more detail about how the ML model prunes and filters the best plan. It is also not clear what attributes of a plan the corresponding vector encodes.
I do not know much about Databloom, but it looks like this "Learning-Based Query Optimizer" is built for specific use-cases in a Data engineering/analytics setting(like K-means as cited in the article). It might not be a replacement for optimizers in traditional Databases.
I've noticed the same behavior with the recommendation engine from Reddit and Instagram as well. While they don't totally block providing feedback on recommended posts that I'm actually not interested in, the UI flow to submit the feedback is difficult/confusing enough that I've just stopped doing it altogether.
Could this be because retraining whatever model that they've built is difficult/expensive with new feedback?
You're right, A hash function doesn't map to multiple values.
Bloom filters and other probabilistic set membership DS's like Cuckoo filters instead use multiple hash functions to map one input to multiple output values. [1]
The number of hash functions to use depends on the expected false positive probability rate, number of bits in the filter and the number of elements which will be inserted
I still haven't gotten my hands on the Beta yet, so I'm not sure how it's going to be deployed;
But does anyone know if Copilot is going to be accessible through some online IDE (or) is it going to be through an extension for VS Code/other editors?
If it's the latter, I hope the extension doesn't eat up all my CPU!
Agreed. This feel more like an involuntary social experiment and it just uses up the Kernel maintainers bandwidth.
Reviewing code is difficult, even more so when the committer is set out to introduce bad code in the first place.
Here's a clarification from the Researchers over at UMN[1].
They claim that none of the Bogus patches were merged to the Stable code line :
>Once any maintainer of the community responds to the email,indicating “looks good”,we immediately point out the introduced bug and request them to not go ahead to apply the patch. At the same time, we point out the correct fixing of the bug and provide our proper patch. In all the three cases, maintainers explicitly acknowledged and confirmed to not move forward with the incorrect patches. This way, we ensure that the incorrect patches will not be adopted or committed into the Git tree of Linux.
I haven't been able to find out what the 3 patches which the reference are, but the discussions on Greg's UMN Revert patch [2] does indicate that some of the fixes have indeed been merged to Stable and are actually Bogus.