One big thing I think is whether you want some sort of non-trivial network configuration, such as multiple external IPs via ipvlan. That's technically possible off docker, but not in a responsible way as anything in the ipvlan will be accessible to the public internet. Overall the implementations for this are very janky and occasionally enter tilted states that are close to impossible to recover from short of a restart of the docker daemon.
I think it doesn't need to be a large X% increase, just needs to hit some critical infra threshold where various services start failing and cascade. Weakest link and everything.
Teens are famously resilient to that sort of thing though. Making something illegal is just about the only thing to get a teenager to want to do something.
Yeah it's pretty common to use zip files as purely a container format, with no compression enabled. You can even construct them in such a way it's possible to memory map the contents directly out of the zip file, or read them over network via a small number of range requsts.
It's worth keeping in mind how much more fringe the web used to be. You were almost by definition a bit of a deviant if you spent significant time online in the '90s and early '00s ("nerd" was a pejorative). People who found no acceptance in the physical world many times found like minded people online, which sometimes was a good thing and sometimes unfortunate.
Skiplists are designed for fast intersection, not for single value lookup (assuming a sane design that's not based on linked lists, that's just an educational device that's never used in practice).
They are extremely good at intersections, as you can use the skip pointers in clever ways to skip ahead and eliminate whole swathes of values. You can kinda do that with b-trees[1] as well, but skip lists can beat them out in many cases.
It's highly dependent on the shape of the data though. For random numbers, it's probably an even match, but for postings lists and the like (where skiplists are often used), they perform extremely well as these often have runs of semiconsecutive values being intersected.
[1] I'll argue that if you squint a bit, a skiplist arguably is a sort of degenerate b-tree.
B(+)Trees do actually admit a fast intersection (they offer a way more powerful projected-to-shared-keyspace mutual index join, technically it's even able to do antijoin but that'll actually modify iteration more than a very genericalized inner join; basically whenever you look at a key in any one of the involved indices you project it to a shared keyspace before doing the comparison-based-search things):
You get cache locality from the upper layers, and for navigation basically `let mut head = keyspace.min(); 'outer: while(!cursors[0].finished()){ for(&mut cursor in cursors.iter_mut()) { let new_head = cursor.seek_to_target_or_next_after_if_none_match(head); if (head != new_head) {continue 'outer; }} /* passed all without seeking past target on any one */ output_fun(head, cursors.iter().map(|x| x.val())); }`. If you want you can do the inner loop's seeks concurrently, which helps if those are IO latency bound and you can afford to waste absolute IOPS on eagerly doing that. You'll want to locally compute the max() of those returned and assign that to `head`. Imagine the cursors are lambda-parametrized to feel like they operate on the projected shared keyspace.
If the keys are a bitstring prefix suited to a binary prefix trie you can actually intersect that way, it's beyond worst case optimal when multiple key columns are involved. Sadly any simple implementation strategies of those algorithms have prohibitive external-memory-machine coefficients for their nominally poly-logarithmic IOPS, due to involvement of combinatorial explosion / curse of dimensionality in search tree/trie structures. They do work though. C.f. "Tetris-LoadBalanced"/"Tetris-Reordered".
The latter even tames one index containing "all" even numbers and the other "all" odd numbers, well, matters more if you involve 3+ columns :D
I don't understand how they differ in this regard from range trees, which they essentially are, just their method of construction is different.
Things like BSP trees are very good at intersections indeed, and have been used for things since time immemorial, but I think the skiplist/tree tradeoff is not that different in this domain.
Maestro Tarjan tells us skiplists and treaps are very nearly the same thing: https://arxiv.org/abs/1806.06726. I don’t see how to transpose TFA’s extension of the former to the latter, though.
Kdenlive has some unfortunate performance regression when working with larger projects with many clips.
I managed to track down a few of them while evaluating Claude Code a while back (mostly certain actions doing O(n) scans over all clips every mouse event needing debouncing), and got it mostly back down to tolerable levels again, but have been holding onto them because unsolicited drive by AI PRs are very annoying from a code project maintenance perspective, as the changes are almost certainly poorly factored.
Was half considering creating a Kdenvibe fork, but that would also be in bad taste. So right now I don't know what to do with the diff.
I'd open a Draft PR and an Issue to explain the problems you encountered and how you've solved them for your own use cases... then leave it up to them to learn from it or close it.
I get annoyed with "drive-by PRs" only when they lack context or are clearly just a way to get some commits into a project (typos and so on), but any findings that can improve my code or its performance is welcome, in my projects at least.
This is a great comment. As someone who has been involved in managing a large (business backed) OSS project I can say that even if we preferred to have our own solutions to issues, we really valued comprehensive issues and draft PRs to reference.
Sometimes you just don't have the time to get a PR to a projects mergeable standards, but the solution as a reference can have a ton of value for those that eventually get a PR across the finish line.
I would say, though, that agentic coding seriously complicates the entire situation...
Creating the PR, doing the explanation you just did, and closing it yourself might be a good option. Then at least your code lives somewhere that someone else can reuse if desired. Ideally combined with a linked issue that you do keep open.
My suggestion is to do a “human summary” of what you asked the agent and what it found, maybe supply the code it generated, mayyybe.. but mostly recommend they not review it but instead, the reviewer give the PR to their own agent to do a reimplementation.
Since code is cheap now, why not replace reviewing with reimplementing!
You should be running your own fork before making pull requests. You don’t have to get other people to use it, you just need to get in the habit of rebasing regularly and cutting releases for yourself. Someday I hope maintainers get better visibility into downstream improvements without the politics of pull requests.
Id say ask AI to ‘describe the problem and solution from a high level. avoid code excerpts if possible.’
Submit as a bug report and mention you have an AI solution for reference if desired.
Probably the same way other models learned to surpass human ability while being bootstrapped from human-level data - using reinforcement learning.
The question is, do we have good enough feedback loops for that, and if not, are we going to find them? I would bet they will be found for a lot of use cases.
Because you ask it to improve things and so it produces slightly better than average results - the average person can find things wrong with something, and fix it as well. Then you feed that improved result back in and generate a model where the average is better.
Humans can decide to write above-average code by putting in more effort, writing comprehensive tests, iteratively refactoring, profile-informed optimization, etc.
I think you can have LLMs do that too, and then generate synthetic training data for "high-effort code".
Well state of the art LLMs sure can't consistently produce high quality code outside of small greenfield projects or tiny demos, which is a domain that was always easy even for humans as there are very few constraints to consider, and the context is very small.
Part of the problem is that better code is almost always less code. Where a skilled programmer will introduce a surgical 1-3 LOC diff, an incompetent programmer will introduce 100 LOC. So you'll almost always have a case where the bad code outnumbers the good.
Current LLMs do tend to explode complexity if left to their own devices but I don't think that's an inherent limitation. Mediocre programmers can write good code if they try hard enough and spend enough time on it.
Thats because humans have "understanding" they can use to assess quality, without understanding "trying harder" just means spending more "effort" distilling an average result, at best over a larger sample size.
reply