techtrenches.substack.com
Sanitize your inputs.
We've used AI to generate code at my company with only limited success.
I might want to give that a try. There are already many static and dynamic code analysis tools out there. I'd like to know how this one is different aside from having the AI moniker attached to it.
Our senior software engineers are quite experienced. Most of them are in their 40s and 50s and quite a lot of them came from the gaming industry. Their management reports that they find about twice as many bugs through manual code review than via static code analysis and QA testing. But then again our software needs are weird. We do embedded systems extensively. But then we also have supercomputers. Very little of our software is meant to run on a consumer PC.
www.investors.com
). The company is providing strict guidelines how to use AI and has setup internal platforms to avoid leaking any proprietary software to external models. AI generated software must stay below a certain percentage of the total lines and so on. All quite encouraging.
Yes, often a big misunderstanding of the original "run fast and break things" which was about small changes easily backed out or fixed and deployed to a few instances at first.
That's been happening in the gaming space since the early noughties, once the Xbox came out with an ethernet port and the expectation that you'd be persistently online, the game devs quickly brought them in-line with PC titles and were chucking half-finished crap out of the door with release day patches.
Well I do remember once arguing with Nintendo about a clipping bug on the N64, apparently there was one area that if you ran at the wall something like 30 plus times you could drive out of the world. Should that have been fixed before shipping - my view was that it wasn't a stop bug as no one in right mind would do that. (It was by the way a terrible game, god knows why anyone would ever have bought it, the producer had a cut out on his desk that showed it as "No 1 Game of the Year" - the context of the article that he didn't cut out was that it was the No 1 WORSE title of the year. It was a contractable obligation that we had a game with its title approved by Nintendo by a certain date. As ever the mighty dollar - or actually francs was the "quality" bar.)
On MacOS the ps -l command is showing me 34.6 GB vsize on a newly opened Calculator app after a few calculations. It's showing a resident set size of about 112 MB. The "resident set" is the set of virtual memory pages that are actually resident in RAM, generally corresponding to the minimum amount of memory for code and data needed to run the program at that given second.
Yes, this. As I mentioned up-thread, the programs we run on our supercomputers run for up to two weeks and simply can't leak because even small leaks add up rapidly. It's a paradox that our programmers working on some of the most powerful computers available have to be just as resource-conscious as someone programming an embedded system. One of our systems has a RAM capacity of 4 petabytes, and that's not even within the ballpark of what's running at, say, the Dept. of Energy sites today.
Indeed. The first computer I did engineering on was an IBM System 370 with a whopping 8 megabytes of RAM. We spent a day in meetings trying to justify to management an upgrade to 12 megabytes. We eventually upgraded to a System 3084 and finally a System 3090 with a whopping 6 CPUs and 32 megabytes per CPU. That was luxury.
Have you considered writing in a memory safe language such as Logo or Python?
