ashdnazg

It's not really comparable. When decompiling you only care about a one time result. Code quality doesn't matter much. Stability doesn't matter much. Only whether the result is accurate. Once you have the matching decompiled code, all tools used until that point will be usually thrown away.

Normal development isn't so lucky, you do care about code quality. So you have to review the code the agents write and handle the testing yourself. The agents will not do what you want, they'll do what they think you want, and you're the only person who knows what you think.

I've been decompiling DOS games recently with help from the $20 subscription. The one compiled by the Watcom compiler took like two weeks, with 2/141 functions still not matching. The one compiled by Microsoft C reached a match in two days more or less.

I think this points in two directions - first that $200 is really unnecessary for this domain.

Second, that with more experience we might be able to write a non-AI matching decompiler and then naming and simplifying could be done by people/AI. While I appreciate the hobby part of it, I think automated tools are the way to really make it reach everything with far less dependency on pockets. The benefit to preservation would be incredible.

Our university was far less careful, and just ran our submissions in the same network as everything else albeit on a user with barely any permissions.

Once when the automatic tests crashed my submission, I simply used `system` to dump the testing input into my home dir. I forgot, however, to setup the permissions, so I couldn't really access it! A couple more resubmissions with extra chmods, messing up a different thing every time and I managed to reproduce my bug, fix it, resubmit and purge all (or most) evidence.

Maybe just speed? TFA said that many agents failed because they were thinking too much and doing too little.

Maybe Optane was just a few years too early. There's finally a demand for a middle ground between RAM and SSD.

I worked on a transpiler from Nand2tetris assembly to WebAssembly, and had some really annoying memory corruption bug that I just couldn't solve.

That is, until I checked the program I used for testing (which I didn't write), and found the following code:

  dealloc(this)
  return this->field

With the original allocator, this worked fine, since the deallocation didn't touch the memory.

My allocator, however, overwrote the field during the deallocation with bookkeeping stuff, which meant the returned value was not what the programmer intended and after a short while the program crashed.

Unlike TFA, I had the luxury of just fixing the test program.

Kind of depends on the definition of no one.

If the company puts an artificial proof of work demanding a rack of the latest data center GPUs, that should be illegal.

If the binary has the same hardware requirements that the company used when the service was up, I see it as totally fair.

The key is communication. If the company says the binary has a certain min. requirement, then the vast majority of people will accept that.

Of course there'll be idiots, but I doubt you'll see a stronger backlash than to a company shutting down the servers without any solution, like they can do now.

> But the server binary doesn't start unless you have 190GiB of RAM and 38 available CPUs.

As far as I understand that situation is accepted by the initiative. The requirement is not that it works on any specific hardware or software stack, just that it can theoretically work.

> a binary that can be used to create cheats against the next version of the product

Anti-cheat solutions aren't required to be released, and if there are bugs in the server, they might even be found and patched by the community.