jerf

"A $5/month VPS won't cut it anymore."

Are you speaking from experience, or inferring from articles like this?

I serve a static site on the lowest Linode $5/month VPS and it is grotesquely overprovisioned for that use case. It is not the case that every site is getting slammed every second by hundreds of requests per second.

Now, if you have some sort of dynamically-computed website that is generated by a slow scripting language that is poorly optimized and hits the database too many times for a single page, yeah, it doesn't take many RPS to take you out. But that isn't the only option; it's the slowest of the slow options. Realistic, there are plenty of sites that match that description, but I concatenated that many clauses on purpose. Drop any one of them and your personal site will be fine.

Yes, I don't mean to imply that this is some sort of clear majority situation or anything. I just mean that I've definitely both seen on HN and participated in real life in some conversations in which it was taken as given that we must give up one thing to get another when nobody had in fact established that we were on the Pareto frontier. Or, considered from a local point of view, whether the tradeoff really was inevitable. I have had cases where we could have had both, with no difficulty.

In this context, a capability is something that allows the code, or the transitive closure of the code that it may call, to access some particular function, to put it very briefly. So you could have a single function that, if accessed in one manner, is permitted to read from the directory /tmp/blahblah, but accessed in another manner, is permitted to read from the directory /home/zdragnar/.config/myprogram, and it is guaranteed by the language and runtime that the function will never do anything else on the file system. Or, even more importantly, it can be guaranteed that "from this code, nothing, no matter how the code is arranged, can access the file system at all".

This has massive overlap with a lot of things, like capabilities as implemented by Linux, effects systems, monadic data types as a not-really-very-good capabilities system (Haskellers have been playing with this for years and nobody really loves this approach, many practical problems beyond the scope of this message that would affect any language that tries that approach), dependently-typed programming, and so forth.

It is not a flag, though; flags can't handle that "transitive environment" aspect. It is also granular on the level of the programming language. This would allow you to do things like have your program be given access to a given part of the mobile file system using the mobile OS' permissions, but you could know beyond a shadow of a doubt that the image library you are using can not at any point access the file system, no matter what changes the author makes to it, because you can just look at the capabilities given to the image library and see that file system access is not among them. This is where real opportunity is over the next few years, in my opinion, because supply chain attacks are going to continue to get worse. A neat aspect of this approach is that it makes huge swathes of the ecosystem unattractive targets by statically ensuring that they can't sneak anything in to something that doesn't need file system or network access, so hackers won't even attack those libraries. Thus the ecosystem can concentrate on monitoring just the high-touch libraries that need to access high-risk resources.

(I should make it clear that the image parsing libraries can be passed a file; what I am saying is that they can't spontaneously originate arbitrary file system access in a system like this. Really what they would get is probably a "stream" and they would be forbidden from poking into the stream to see what it is made of, at which point, if some other code handed it a file presumably it meant to do that, but it does not give the image library any ability to do anything else with the filesystem.)

Moreover, if such a benefit was available, that would tend to have people squeeze down those dependencies as much as possible too, e.g., the aforementioned image library. You don't need file system access to parse images, that's just some convenience functions easily worked around that are provided because why not? The number of things that truly need direct high-risk access can actually be surprisingly small, and often, the application can also easily scope the permissions down quite tightly so the HTTP request library is limited in what it can hit, etc.

We actually have some semi-decent stabs at capabilities at the OS level; we can quibble with them but they are there. But inside an OS process, broadly speaking, anything can do anything in the vast majority of programming languages. The only way to be sure that the string concatenation function doesn't start crawling your file system looking for crypto keys is to examine the code, most languages have no ability to tell it that it can't. There are exceptions, like the aforementioned Haskell, that have at least some ability to do this, but this is an HN post, not a complete guide to a major topic. Really this is more about loading the reader up with keywords they can hit Google or an AI with.

The term is overloaded, too; Pony has something it calls "capabilities" but it really resembles more a sort of response to Rust's borrow checker, and if there is a way to lift it into this style of capabilities coherently it isn't clear to me. And even if you did, the entire rest of the ecosystem wouldn't support it, which is one of the reasons why this has to be a new language. You can't bodge this on to the side of an existing language.

(Plus, IMHO, there are some other ideas this may shake loose. Programming languages seem to be in a rut right now. My crack in my previous message about sum types and such isn't really about those things but the way almost every language going by is just a respelling of previous languages, churning over some other iteration of "The Perfect 2015 Language" that is already covered by any number of existing projects. I don't know that there's a lot of room there anymore. We need something big. Once you try something big the design will inevitably lead to other interesting things nobody else is trying either. Capabilities is one distinct possibility... like I said, if you dig in to the history you will discover there are entire huge segments of the capabilities space that haven't even been tried. If nothing else, if you are a PL nerd, I guarantee it'll be fun to explore those spaces that almost nobody has covered. No criticism intended to those who have, who have done a good job. It just hasn't been enough people and enough exploration to truly map the space.)

A language that revives capabilities, brings them up-to-date, and works in the modern environment is my #1 request from the programming language community right now. I don't need another language with sum types and higher-order functions and a functional focus. I need a language with capabilities. That language may have the other goodies as well, sure, no problem, but we all need capabilities.

I've done some stabby stabs at a design for it, using an AI as the rubber duck. My initial research indicates that the field of "static language that natively supports capabilities" is surprisingly uncovered and there may be a rich field there. E, the closest match, was tied at the hip to Java, which has some advantages but also comes with disadvantages for languages that are trying to do something as exotic as this. Other existing work was on dynamic languages, and hardly rose to the level of "practical for any use" let alone something that could solve our supply chain issues.

My issue is primarily that the reward for successfully designing a language and creating a community around it is that you're in charge of a language community... and, uh, my personality is not suited for that, that sounds more like something I'd pay to avoid then something I'd spend months and years of hard work to attain.

(My advice to anyone doing this is to spend some time with the AI researchers to find the existing work on the topic, not to just sit down and sketch out your initial ideas and run with them. Learn from the past. Expect this to be weeks and probably months of just thinking and noodling before you get to a design. Also, don't try to hook deeply to an existing language, as tempting as it is. This is way too large an impedance mismatch with existing languages. Any external code has to be treated like a nuclear bomb anyhow.)

"What a serious security model for a meatbag agent looks like?"

Yes, I think that's very related. Humans can be punished for their crimes but they can also experience benefits that have no applicability to an LLM, so for a first approximation we can cancel those. It is very similar to trying to secure a human.

We have more experience with that, but even then it's a hard problem too.

What would a serious security model for an agent even look like?

I'm sure I've already got a dozen people reaching for the reply button, but slow down there, cowboy. I don't think it's even remotely as easy to define as people think. We have a reasonable concept of how to lock them down really tightly, no question, and I expect that most of the answers in the "leap to mind" category match that.

But let's say we'd like them to continue functioning the way they do today. I want my agent to be able to hit the web. I want my agent to be able to read out of its assigned directory sometimes. I want it to be able to hit external resources through MCP servers that have no pragmatic way to know what's going on. And probably most importantly of all, I want my AI to be able to grab from three distinct sources, each of which may be nominally safe on its own, and combine things in a way that may make each of those nominally safe things become unsafe. For example, any ability to read a local file and make a remote request becomes a potential exfiltration mechanism, especially when you remember all the sidechannel ways communication can occur.

I agree that shifting everything on to the user is essentially non-functional. But whereas I feel like I have a reasonable answer to a lot of other security-related problems, it isn't even clear to me what the definition of a secure agent is.

There's an effect I need to put a name on someday, where you can get 10 people in a room to agree to a certain series of words, and they will all leave the meeting thinking they agree, but in fact there is no agreement at all because they all have a different definition of the words that were used. In this case, everyone here is going to go "Oh, yes, certainly, AI agents should be secured." But if you sit down with 10 of us to really do the work of defining exactly what that is, you're going to get 10 different answers. There will be overlap, certainly, but when you get down to the nitty-gritty questions like "OK, the user has explicitly asked the agent to do X by accessing Y and the agent has done so and determined that they need to do Z, which the user clicked "allow all" for, and now the agent has decided that it wants to do T, is T fully covered under that "allow all" or not?" you're not going to get anything like universal agreement across the huge range of Xs, Ys, Zs and Ts that could happen and are relevant... and that's still just one question! It's not the totality of what constitutes a "secure agent".

Defining what a "secure agent" even is is really hard because when it comes to agents, the things that fill in the variables are as arbitrarily complicated as human actions. I haven't fully worked this out but it might be reasonable to say that "agent security" is in reality Turing complete, what with the way they so often throw out fully-fledged programs that you have to approve or reject permissions for.

This is a really important concept for developers.

One aspect for developers that I see quite often is the assertion that "We can't have X without giving up more Y", most commonly "we can't have more security without giving up on user experience". With the Pareto idea in mind, we can see that that statement is true, if and only if you are in fact on the Pareto frontier of security and user experience already.

However, many times these confident pronouncements are being made when the system under question is quite evidently not on the Pareto frontier in the first place and indeed you can get more of one without giving up the other.

Making it more tricky is that in business, you can never discard "money" as a dimension, so unless you're taking "money" as one of the dimensions in the original comparison you want to do, it sneaks its way in. Or, a composite time/money, or "cost to business", or some other similar concept, time & money aren't orthogonal and don't need to be treated as two separate dimensions in general, though you can if you want. Which puts you into the 3D case, and as the page says, that grows the frontier quite a lot, which is good in some ways and bad in others. Nevertheless, in my opinion it is still often the case that even in that space we are often making "tradeoffs" without checking that we're on the Pareto frontier in the first place.

I think you misunderstand. The idea is not that one feeds a cryptographic text to LLMs and they crack it. The idea is that one feeds a cryptographic algorithm to an LLM and they break it somehow. Bear in mind that cryptographers consider a "break" anything that reduces the strength of an algorithm, but that doesn't mean that it is practical to use the given "break" to obtain even one plaintext, let alone obtain them all.

Rovo has my favorite example of AI misfeature. Just checked, it's still there in Cloud Confluence. In Edit mode for a page, you can select a range of text and a menu will pop up, with Ask Rovo being a drop down on it. There's a few good options... Improve Formatting, translation options, Make Shorter...

... but it also has Make Longer. Yes, a built-in feature to type some text in, and the use the mighty power of AI to bloat it.

Naturally, you can repeat this process several times on the same text, for your own little personal demonstration of what model collapse looks like in real time.

Ah, my favorite exception to fraud: Puffery. https://en.wikipedia.org/wiki/Puffery

If everyone knows it's a lie... well then I guess it's not a lie anymore, is it?

I kind of understand why the law takes this position. If you really think about it's hard to imagine how to truly fix this. But it still feels pretty dirty.

I think you really want to look at this in terms of the fact that it was already getting difficult to convince companies to hire junior engineers. They already don't want to pay for the inevitable several months of training before they're working at full speed. They want someone to be productive for the money now. And senior engineers are probably more productive per $ than juniors, even if the seniors are getting paid more. It doesn't help that a lot of people in our industry like to switch jobs every two years (which is, of course, further not helped by the reluctance of companies to give raises rather than hire new), which means there's a good chance they'll do nothing but pay their training only for some other company to harness the benefits. And companies, especially publicly traded companies, want decisions to benefit the company in the next quarter, and while that may not be immediately on everyone's mind during the hiring discussion it does trickle down.

But the junior will do at least some real work that hopefully benefits the company while they are there. There is at least something on the "benefit" side of the cost/benefit balance to entice them.

The problem that AI creates is that it tends to eliminate even that benefit. The task I would assign to the junior as their first task, which I expect to take them some weeks on as they not only do the nominal task but acquire all the surrounding skills and knowledge to finish it, is now a prompt and the senior engineer intermittently checking in on the AI's completion of it. It's hard to justify hiring the junior and paying them for six months if the senior can do the task(s) they'll finish before they jet off to their next job in a fraction of a day or two.

I have written this from a point of view that is foreign to me to explain the problem from their point of view. I do not accept this formulation wholesale, though there are substantial kernels of truth in it that anyone who wants to convince a real person that they are wrong about this assessment will have to deal with. I'm a very long term oriented person and still believe that raising up talent within your organization is extremely important. After all, in the end, what even is your organization except the talent you have within it and the system you've built for it to operate? Unless you think you can operate without any people at all, people are a vital part of your organization and you'd better be growing the best people you can or you can expect to get beat in the long term by an organization that did invest.

But when I look out at the world, what I see operating in most people and companies is much closer to the point of view I described first. That "beat in the long term", however long it may be, is certainly longer than one quarter or even one fiscal year.

Memory isn't what I meant by the partitioning; I meant the entire context of the memory.

But to your implied point about getting an advertisement into a memory file... that makes it even more amusing to hack Google's own AI to put Time's ads into it. I think that's probably an easier problem for Google to solve, too, though. The small size and the way that a memory is going be a stereotypical summary makes it easier to filter out the ads Google doesn't want...

... but it'll cost them. That's an AI-complete problem and they're going to have to run LLMs over the memories to filter them, at their expense.

The most obvious fix to me is to have an LLM try to pre-filter out the ads from Time's content before feeding that as pristine content to the "core" AI so it won't be corrupted by the advertisement, but the LLM doing the filtering has to be at least as smart as the one using the content and/or the one inserting the ads. (A dumber one can filter the obvious stuff, but then the obvious next step in the arms race is for Time to tell their AI to be more clever about it, and a smarter AI will dominate the dumb cheap AIs here.) This is going to be an expensive setup. And there will be semantic loss in any such filter, too.

Oh wow, thank you for that chart. That is fantastic. The premium is huge. And for good reasons.

The best way for a politician to lie is to convince someone else of the truth of the lie and then put that someone in front of the cameras. That way, there's no hint of body language or anything else that indicates it's a lie. Both the denotation of the lie and the human context of the lie will be in harmony.

This sort of reminds me of that. LLMs are by their nature credulous. They can be trained to not give in easily to some things, like the capital of the US, but in general they constitutionally have a tendency to believe what they read. What they read is basically their universe. There's only so much room and so much training data to really strongly pin raw facts in their weights. The only way they can not believe some marginal fact presented to them in their input is to possibly have read something that contradicts it in the same session... and the vast, vast majority of the world is those marginal facts, not really objective things like capital names.

So if you can work a confident statement in to an LLM's input about some semi-relevant topic, it's truth to the LLM. And, being truth, the LLM will then happily and confidently elaborate on it quite a bit.

Of course, if it's irrelevant to the current query, it probably won't have much effect. Ads have always been a game of numbers, anyhow. Even a query about a science topic has some probability of eventually turning to a question about banking in the same session. It's probably a good idea to rather strictly partition your conversations to stick to a single topic, not to defend against this but just to maximize the effectiveness of what is in the context window by keeping it focused, but I have to imagine there's plenty of people out there who reuse conversations all the time and end up with single conversations covering a huge array of topics.

The good news, and the bad news, all at once, is that Google isn't going to take this one sitting down. If they're going to replace the search engine box with an LLM, well, they're using the same LLMs we're all using, if not in fact a bit cheaper one for the work they do, and by golly, that bot should be serving up Google's ads, not Time's ads! Who do these uppity content creators think they are, anyhow?! So there is definitely going to be work done in the field of ad-blocking content served to LLMs.

I mostly use languages where the feature doesn't even exist. We don't generally miss it.

I also blocked a proposed mandatory dependabot at work a few months back because I didn't like the way it created a pipeline for any hacker to push a hacked dependency straight into someone's codebase. I'm lifting my objection now that dependabot is defaulting to a 3-day cooldown, though the code bases I'm managing I'm setting to 7 days. (Not to be behind everyone else; I'd be fine if everyone joined me at 7 days. I don't really accept the freeloading objection, there's plenty of entities scanning things now no matter what cooldown you set. I just think 3 is a little tight to expect the full discovery and remediation to take place.)

So, whatever sort of "but it's really hard! I bet you don't do it yourself" implications you may be trying to draw fall very flat. Or whatever you may have been trying to imply about trusting this step but not trusting others... no, I do defense in depth. Giving up on defense in depth because one step isn't enough... well, I think I've probably played the "you won't get very far in engineering" card enough, but hey, here's one last time.

IPOs experiencing significant drops after their IPO is not a crazy theory, it's pretty much the norm: https://potomacwealthmanagementllc.com/2026/03/04/underperfo...

Not guaranteed, but the norm.

I've never tried to buy PUTs on a big IPO but I wouldn't be surprised that there's a premium on them, if options trading is even available.

Lock in isn't about physical versus digital. This came up a couple of days ago: https://news.ycombinator.com/item?id=49138750

Disks can be locked in and digital can be completely free.

You will also not get very far in engineering if you have a production incident, someone proposes a thing that will mitigate it partially but significantly, and you insist that we can't deploy that mitigation because we need to do the multi-year project that will actually fix it instead. Even if we still need that project, we also need that mitigation.

Sure, solve the problem of "auditing and trusting codebases". Go for it. Shouldn't take you until, oh, let me be generous and give you until next Monday. No sweat.

I hate that it's hidden too. There's no reason for it to be hidden and arguably some reason for it not to be hidden.

I did discover one reason for it not to be just "env" though, which surprised me, which is that "source env" will yield "bash: source: /usr/bin/env: cannot execute binary file". I did not expect the source command to use the $PATH to resolve the filename. Probably some minor security issues that can result from that out there in the world. Arguably anyone loading it should use "source ./.env" or equivalent, with full path.

It's documented in the bash manual, of course. But it is rather complicated as to when it will and will not use $PATH.

I don't think you're quite getting it. I'm saying, don't get in the box.

"But the bait looks so nice!"

Yes. Yes it does.

Yes, you may have to sacrifice and not get some things you want in the moment. Our capitalistic overlords have demonstrated that they will absolutely abuse you to the maximum extent you permit. If you are willing to give everything to play GTA 6, then they will take it.

The compensation is that there is already more than you could possibly do available in spaces where they are not locking you in a box, or you can break out of the box with minimal moral quandaries and technical difficulties.

This isn't really news. Control your desires or they will control you is not new wisdom. Though the modern ability to exploit other's inability to control their desires certainly does have some new twists on it.

"Each man's master is the person who has the authority over what the man wishes or does not wish, so as to secure it, or take it away. Whoever, therefore, wants to be free, let him neither wish for anything, nor avoid anything, that is under the control of others; or else he is necessarily a slave." - The Encheridion Of Epictetus, second century AD

https://en.wikisource.org/wiki/Page%3ADiscourses_of_Epictetu...

Nobody is claiming this is a complete solution to security. I would call this "necessary but not sufficient". You won't get far as an engineer if you refuse to implement "necessary but not sufficient" changes because the change doesn't in and of itself one-shot the entire problem.

You don't get in the locked box in the first place. That's the whole point.

A day may come where it is the only option. In which case, personally, I will still advocate for not getting in the box. If they're going to hold "music" and "movies" hostage tell them to go fuck themselves. It's your money they're using to lock you in. And the day that I have nothing left that can play MP3 files is too far in the future to be sure about anyhow.

If you're really concerned that that is a likely future, you need to be joining with me now, not trying to discourage me about the hopelessness of the task. The only reason it's hopeless is your apparent willingness to pay other people to lock you in. If you don't accept that bargain, you won't be locked in.

Further helping is that these closed ecosystems tend to collapse anyhow. If you're locked in, why spend money on giving you good content? Even if they are appealing today, they won't be tomorrow.

General principle: It is way easier to avoid lock in by not being locked in in the first place then to extricate yourself later. It's easy for me not to be locked in to a streaming video service because I had a DVD collection that predates them, and I maintained it instead of being on a streaming service, so I've got a personal collection. It's easy for me not to be locked in to a streaming music service because I have a CD collection started decades before they came into existence, ripped digitally, and I've got music I own already.

There's more entertainment of every kind, including video games that don't lock you down, then you could consume in a lifetime anyhow. If you limit yourself to just what doesn't lock you in, yeah, you may not be playing GTA VI, but it's not like you'll lack for good games.

On the one hand, buying a subscription service for $20/month does give you instant, temporary access to a lot of things... on the other, consistently putting that money into media acquisition over the same period of time will build up quite a collection in a few years. Remember that you don't just have to buy blockbusters... you can raid garage sales, you can buy used, you can pick up surprisingly cheap collections like [1], you can hit the Salvation Army... what you find may be haphazard but you can bootstrap a collection cheaply, and may find some surprising stuff on the way.

[1]: https://www.amazon.com/dp/B006LOC01G - but look at the used prices, not the new. There's a lot of things like this on Amazon where someone thinks they can get a lot of money for it "new" where the used market reflects the more accurate market reality.

"And vital for retaining and enhancing usable range of motion (not static stretching, still, but dynamic stretching / mobility under tension)."

I'm doing it for knee pain. It's possible it's a placebo because there is a slight strength training component to the whole thing (it's several exercises), although the knee pain has persisted through a lot of strengthening of my leg in general. This falls under "don't care" as the program as a whole works and I'm not worried enough about the details to try to optimize it. All the stretches fall under "dynamic stretching under tension" so maybe it's not something covered by the study you reference last.

Ask yourself the question "which of those things prevents me from going to jail for hosting CSAM" and the answer becomes pretty obvious.

I fear you are mentally modeling law enforcement as rational people who will just accept any explanation you make, and that model does not correspond to reality.

The other thing you may not realize is that the bad guys aren't just isolated guys in their basement who occasionally poke their heads out and maybe compromise a site every so often. There is a pipeline that operates with commercial efficiency, in all senses of the term, including that they are getting paid. I've seen it more directly with link forwarders; there are people actively and constantly seeking out new link forwarders and exploiting them to send spam. I've seen people put them up as a "hobby learning" project and within single-digit hours they're being used in spamming campaigns. You couldn't have escaped this pipeline's notice no matter what you did but with it being on HN you're certainly going to end up on their radar. By this time tomorrow, best case, maybe in a week, if you look at what is actually being stored on your site you better bring the eyebleach.

I've been using a prompt that comes from the opposite direction for non-programming stuff: "Assume the user is an expert in all fields; while this is clearly logically untrue on a literal level, the user prefers to see a field's technical terminology and then ask the AI about terms the user does not understand rather than get an inaccurate statement about some issue."

Whether you have to reassure the LLM that this is obviously untrue, I don't know, but they do have a knowledge baseline to know it's not true and I have a sneaking suspicion it would be less effective without that.

This has ended up in some of the most interesting incidental knowledge exploration I've ever done. A recent example is that I was asking about some stretches and it started talking about how useful they are for the sarcomeres, which I had not heard of. Now I have.

I'm not saying this is better, just that it is different. I think there's a time and a place for both approaches.

The problem with ? is that it is not handling the error. It gives you a one-character mechanism for not handling the error. This is a regression from Go, from the point of view of Go's design philosophy, not an advantage. It's one of the major things that has killed error handling proposals... anything that makes "if err != nil { return err }" easier is a bad thing.

The minimal error handling code in Go is really:

    if err != nil {
        return fmt.Errorf("can't do thing thing I'm trying to do: %w", err)
    }

That is actually the code we want to be made easier.

"if err != nil { return err }" in my code is actually a specific claim that for error-handling purposes this function is conceptually part of the function that is calling it and it has just been factored out for other reasons.

I share the general community's dislike for the way Java did it, but I do agree that it may be an overgeneralization to then conclude the entire idea is bad.

Still, to really make it work nicely is non-trivial in the presence of things like closures and I couldn't tell you right now how to fix it.

Thank you.

While that particular API might be nice, and people and companies should probably push back against the obfuscation, in the end it doesn't really matter. When I hand off between different models I already have the first model prepare a markdown file for the second rather than just importing the entire original thread wholesale, because that's expensive anyhow, and also rather unfocused. They can't get their models to stop generating that sort of checkpoint because that's a fundamental operation necessary for all the harnesses to work anyhow.

The fundamental technology of LLMs and arguably AI in general strongly cuts against that sort of lockin. Handoff is a fundamental capability. There's no option to encrypt the docs or write it in some dialect only one model understands because humans need to understand it to, which stops that whole line dead in its tracks for at least the forseeable future. An AI can already today pick up such pieces, how much more easily will they do it tomorrow?

If they want to lock me in, they're going to need to provide a feature that I need so badly I can't switch and nobody else has. It is hard to see what that would be, other than being a generally better model.