Interestingly, after writing this (some years ago) I spoke to some of the original authors. They had never used Smalltalk. So I suppose they invented this stuff independently
Well, I say "more or less" :). But the fact that there is a single global database doesn't mean that you can read every key or value (but generally, yes, you can _read_ everything). I mention in passing prolog-style permission systems for evaluating perms.
But anyway, specific trades are rarely private to one part of the bank for many reasons. For example regulatory: these days you have to notify the regulator about every trade.
Mostly is no rule, adding a cache can just save you from having to buy a bigger database instance in many cases.
The most common first thing to cache is getting the current user, because this ends up being a very hot path for most stateless systems. Because you need to get the current user for almost every request, it's quite easy for getting the current user to be 50% of database load: first you get the user, then you do the thing. tada, user lookup is now half your app by volume
Once someone decides they want to use redis as something other than a cache, you sort of do have 2 cache technologies anyway. You can't use a redis instance that is configured for caching for any other purpose (caching instance must have eviction, non-caching instance must not have eviction). You need a second redis with a different configuration.
Honestly designing your app to have a "memcache-friedly cache layout" is the same thing as designing it to have a redis-friendly cache layout. The pattern for this kind of application cache is identical: "get, and if not there, calculate and set".
Yes I switched from claude code to opencode with deepseek recently.
It is basically indistinguishable from sonnet. At this point my own prompts, AGENTS.md, background docs and so on matter a great deal more than the differences between models.
And deepseek v4 flash (the sonnet comparable) costs 3% of what sonnet does.
It often is illegal to pay them. They are often on sanctions lists, or indeed in embargoed countries. And it's just generally not allowed to pay unidentifiable parties for basic anti-money laundering reasons. And a lot of countries are bringing in new legislation to make paying illegal, starting with public sector organisations. I'm sure that will only expand.
Frankly, you pay a ransom at your peril. If it turns out it was North Korea you may well go to jail for it.
As best I can see, bookstack has not experienced much in the way of concrete issues with Github. And there there are no concrete benefits from migrating to Codeberg. It is his project, his perogative, completely. But the major disbenefit of being on some other forge is that people are less likely to find the software and so less likely to adopt it.
I use Bookstack for a family wiki. I probably would not have gone with it if it had not be hosted on Github as the visible activity on Github makes it clear that it's a project with momentum (18k stars, lot's of activity) etc.
I can't help but feel that moving will make the project less successful than otherwise...
"56k" meant 7 kilobytes per second as a theoretical max.
So 4.4 was ok. Everything with networks is done as bits, I think honestly for marketing reasons now
Interesting process. I wonder if he considered doing this with Anki. That would have given him a good SRS algo for free and Anki cards are also HTML+CSS+JS. I probably wouldn't try to put LLM calls onto my cards though
> The only oversight I think in the proposal is staggered distributions so that projects declare a UUID and the distribution queue progressively makes it available rather than all or nothing
That is indeed an oversight - I wish I had thought of that idea!
I have heard of more than a few horror stories including filesystems lost and force pushes done.
These tools have only been in use for a short time and the current harnesses/system prompts are quite limited. Claude code is mostly limited to your codebase where you have version control. Excel is different.
I foresee that once people hand over more power to full agents there will be some nasty surprises. Im sure there will eventually be demand for some kind of limits
I got 8/9. Been away 2 years. The ones I rarely used or which don't have obvious "tells" that are hardest. For me, Jubilee is the most obvious - very distinctive sound.
Yes, I of course link to this post, which I think is great. But I think actually it understates the case. All three parts of the trifecta (untrusted content, private data and external comms) are not necessary. Really, the key problem is just untrusted content in the context window. Access to private data and the ability to communicate externally are just modalities in which damage can occur.
For example: imagine having just untrusted content and private data (2/3 parts of the trifecta). The untrusted content can use a "Disregard that!" attack to cause the LLM to falsely modify the private data. So I think the whole "trifecta" is not necessary and the key thing is that you simply can't have untrusted stuff in your context window at any point.
I agree and one of the things that makes it harder to handle "disregard that!" is that many models for LLM deployment involve positioning the agent centrally and giving it admin superpowers.
I mention in the footnotes that I think that it makes more sense for the end-user of the LLM to be the one running it. That meshes with RBAC better (the user's LLM session only has the perms the user is actually entitled to) and doesn't devolve into praying the LLM says on-task.