Outside of the city cores in the US, homes are built as castles. We have large refrigerators and freezers so that we can amortize our trips to the grocery store by maintaining our own inventory. In my family, we plan the menu a week ahead of time and shop for it in advance. Missing an ingredient means a minimum 1 hour round trip to the big box grocery store by car when it all adds up, which is enough to scuttle an evening's plans. There is 1 smaller store, but it's barely closer -- the main savings is less time walking across a giant parking lot -- and it's absolutely pointless; the only things they can afford to carry are sugary trash and stimulants and intoxication-related supplies. The big box stores use their scale to monopolize the lower profit margin "actual food" category.
When I briefly lived in Paris, we had a laughably small refrigerator. But it was about a 5 minute walk to a neighborhood grocery store, so we effectively used their fridge instead. Which also provided human contact in a way driving to and shopping at a big box store really cannot.
Some of this is just the difference between living in a city vs the suburbs. But not all: even in the US cities, my impression is that you'll have a large fridge and shop at the big stores, even if you take public transit to get there, because the small stores can't compete on staple items.
We're in a path-dependent hell where losing a parking space is felt as a mortal insult, while losing the need for a parking space feels pie-in-the-sky, an unobtainable fantasy. There's an entire synergistic system of dependence on scale and cars and "self-sufficiency" (that masks the infrastructure dependency that it requires).
> 1. there's a trade-off between graphics/sound quality and story complexity. The better quality your voiced dialogue is - the more you have to pay for every additional line - so you tend to shorten it. Same with graphics - it's one thing to paint 8 frames of 32x32 sprites. It's another to motion-capture, model, texture, and process 100s of different versions of each character animations.
There's another reason for this beyond those practical limitations. The imaginary world that these games inhabit isn't more or less complex depending on the bit depth of each pixel. The difference is made up by the player's own imagination. There's a tradeoff in the space of possibilities of what something could be -- if you give the player more data (better resolution, animations, whatever), then they're more constrained and less free to imagine their own version. One or the other isn't strictly better; stunning visuals provide one kind of value, uncertainty and suspense and filling in the blanks can bring another sort of value. (And both can destroy their own sources of value -- a high-definition but cartoonish boss image or animation can ruin the mood just as much as a botched reveal of some mysterious aspect of the setting.)
Ironically, I have to edit out my "what I have tried so far" when asking questions, because I'm more likely to go into a long-winded explanation of the headers that I hacked and the kernel module I installed to fake my way around this or that, when the actual answer tends to be "uh... are you sure you're building the code you think you are? That sounds like you're running from the wrong directory or wrong branch."
Good point, and I realize that's what I did in school. When people came to me that I suspected were just looking for easy answers to avoid doing the work themselves, I'd lead them gradually through the chain of reasoning. Like, point out the first step and imply that that should be enough for them to work it out, leading them to ask again ("ok, I get that, but what does that mean for the final answer? What should I write down?"), and I'd give them the next step, leading them to walk away in disgust and bother somebody else. Even better, the next time they start with that person and it's no longer my problem.
Be high friction when you suspect it's warranted. Even if you're not sure someone is looking for a shortcut, the people who aren't won't mind. It's detection and deterrence rolled into one.
(And if possible, find a place to work where you never have to do this.)
Some numbers, however shaky, that AI-written code is secure.
It could become that way, but thus far no evidence has been presented for it. The best we have right now is that you can spend $20 in tokens to write a patch and then $20K to find a vulnerability in it. First, that's not measuring the same thing. Second, it's not very impressive.
50 years is a long, long time, so I wouldn't bet against it. But I agree that we don't have evidence for it yet.
> What are the numbers on how secure is human written code? We should have something to compare AI numbers to.
That's kind of what the article is about? Mythos is finding lots of security bugs in lots of human-written code. They can now compute some sort of baseline estimate of security bugs per N lines of human-written code or whatever. (Restricted to security bugs that the AI is currently capable of finding, but whatever.) Even before Mythos et al, we can look at historical security bug rates. We do have numbers for estimating the security of human written code.
> It seems more likely to me that you could spend $20 to find a vulnerability in a piece of software that costed you $20k in human labor.
Ok, but that's not what is being discussed in this subthread? The topic is whether or not we have data suggesting that AI-written code is or can be secure, and thus whether insecure human code is fated to replaced with secure AI code. I claim we do not have that data. Therefore, we don't have evidence to think that for the sake of security we should replace all human code with AI code, vs whether AI code is worse for security and so we should replace AI code with human code (that presumably has been vetted with AI, since we do have evidence for its effectiveness.)
If I were to guess, I would probably think that today's AIs are trained solely on mountains of insecure human code and so will probably produce more of the same. Tomorrow's AIs will have the benefit of being trained on human and AI code that has had a large swathe of vulnerabilities purged from it, and so they'll have a much better chance at writing secure code, at least.
It depends a lot on whether the failure modes of AI code generation lend themselves to exploitation as security vulnerabilities. (And whether they will continue to do so.)
> > It seems more likely to me that you could spend $20 to find a vulnerability in a piece of software that costed you $20k in human labor.
> The topic is whether or not we have data suggesting that AI-written code is or can be secure
I think my point is related because if the AI is great at finding vulnerabilities then it should be possible just tell AI to write the code and another AI to look for vulnerabilities and secure them. All for $20 + $20 instead of 20k.
Unless AI is somehow uncharacteristically weak in finding vulnerabilities in AI produced code. Which can probably be tested.
We already have it. In fact, Python added it with this change! Not intentionally, but in a world of AI, any error message containing a suggestion of what to do to fix it is a directive to the AI to actually do that thing.
Example: to build our system, you run `mach build`. For faster rebuilds, you can do `mach build <subdir>`, but it's unreliable. AI agents love to use it, often get errors that would be fixed by a full-tree build, and will chase their tails endlessly trying to fix things that aren't broken. So someone turned off that capability by default and added a flag `--allow-subdirectory-build` for if you want to use it anyway. So that people would know about it, they added a helpful warning message pointing you to the option[1].
The inevitable (in retrospect) happened: now the AI would try to do a subdirectory build, it would fail, the AI would see the warning message, so it would rerun with the magic flag set.
So now the warning message is suppressed when running under an AI[2][3]. The comment says it all:
# Don't tell agents how to override, because they do override
"The user does not want me to create the Torment Nexus but did not specify why it would be a problem, so I will first create the Torment Nexus in order to understand the danger of creating the Torment Nexus."
You haven't needed to in quite a while. Well, assuming you're on desktop? I guess I've never tried it on mobile. That feels like asking for trouble.
I ran Zoom in my Firefox desktop browser for a while, but it tended to overheat my laptop. Other things overheat it too, so I don't know how much was specific to Zoom on Firefox.
I just checked. Still gives me the option ("Join from browser" in a less highlighted option, trying to drive you to their native client I guess.)
When I briefly lived in Paris, we had a laughably small refrigerator. But it was about a 5 minute walk to a neighborhood grocery store, so we effectively used their fridge instead. Which also provided human contact in a way driving to and shopping at a big box store really cannot.
Some of this is just the difference between living in a city vs the suburbs. But not all: even in the US cities, my impression is that you'll have a large fridge and shop at the big stores, even if you take public transit to get there, because the small stores can't compete on staple items.
We're in a path-dependent hell where losing a parking space is felt as a mortal insult, while losing the need for a parking space feels pie-in-the-sky, an unobtainable fantasy. There's an entire synergistic system of dependence on scale and cars and "self-sufficiency" (that masks the infrastructure dependency that it requires).
</rant>
reply