Care to explain why you think it's infeasible? Then one could provide targeted counter-optimism ;)
I don't see what's infeasible about it. It doesn't seem too different from .po files (gettext catalogs) meshed with hooks for post-processing as would see in e.g. a handlebars, both of which have individually found great adoption.
It's the same story with these people running 12 parallel agents that automatically implement issues managed in Linear by an AI product team that has conducted automated market and user research.
Instead of making things, people are making things that appear busy making things. And as you point out, "but to what end?" is a really important question, often unanswered.
"It's the future, you're going to be left behind", is a common cry. The trouble is, I'm not sure I've seen anything compelling come back from that direction yet, so I'm not sure I've really been left behind at all. I'm quite happy standing where I am.
And the moment I do see something compelling come from that direction, I'll be sure to catch up, using the energy I haven't spent beating down the brush. In the meantime, I'll keep an eye on the other directions too.
Yeah I'm not sure I understand what the goal here is. Ship of Harkinian is a rewrite not just a decompilation. As a human reverse engineer I've gotten a lot of false positives.This seems like one of those areas where hallucinations could be really insidious and hard to identify, especially for a non-expert. I've found MCP to be helpful with a lot of drudgery, but I think you would have to review the llm output, do extensive debugging/dynamic analysis, triage all potential false positives, before attempting to embark on a rewrite based on decompiled assembly... I think OoT took a team of experts collectively thousands of person-hours to fully document, it seems a bit too hopeful to want that and a rewrite just from being pushy to an agent...
Step 1: Decompile into C that can be recompiled into a working ROM. In theory, it could be compiled into the same ROM that we started with. Consistent ROM hash is the main success criteria for the OoT decompilation project. Have it grind until it succeeds.
Step 2: Integrate libultraship. Launching the game natively is the next criteria. Then ideally we could do differential testing on a frame by frame basis comparing emulated vs native.
Step 3: Semantic documentation of source. If it gets this far, I will be very impressed.
This is absolutely an experiment. It's a hard problem with low stakes. There a lot to learn from it.
Not yet. But what's the actual goal here? It's not to have a native Wave Race 64. It's to improve my intuition around what sort of tasks can be worked on 24/7 without supervision.
I have a hypothesis that I can verify the result against the original ROM. With that as the goal, I believe the agent can continue to grind on the problem until it passes that verification. I've seen it in that of other areas, but this is something larger and more tedious and I wanted to see how far it could go.
SeaweedFS's new `weed mini` command[0] does a great job at that. Previously our most flakey tests in CI were due to MinIO sometimes not starting up properly, but with `weed mini` that was completely resolved.
I can also highly recommend SeaweedFS for development purposes, where you want to test general behaviour when using S3-compatible storage. That's what I mainly used MinIO before, and SeaweedFS, especially with their new `weed mini` command that runs all the services together in one process is a great replacement for local development and CI purposes.
Ironically rustfs.com is currently failing to load on Firefox, with 'Uncaught TypeError: can't access property "enable", s is null'. They shoulda used a statically checked language for their website...
It seems like the issue may be that I have WebGL disabled. The console includes messages like "Failed to create WebGL context: WebGL creation failed:
* AllowWebgl2:false restricts context creation on this system."
Oh is it the website that's failing? I kind of assumed it was the web UI for the software. Workarounds sort of kind of make sense there.. Maybe.. But the website. That's bad.
> The raison d’être of SEC is to protect regular mom-and-pop investors
That's not the sole reason. They (should) also enforce a fair even playing field by preventing market manipulation (e.g. how Elon was tweeting about stock prices) and a few other things to "facilitate efficient markets and the formation of capital".
> Why should SEC rules apply?
Because private companies still fall under the jurisdiction of the SEC? See e.g. Theranos.
> On what legal basis can you force a private company to divulge its financial details?
On the to-be-created legal basis that aims to prevent bubble formation and the resulting fallout to the wider society?
> Would you be happy if you, as an individual, have to divulge your account statements if your own net wealth reaches one million?
Sure, why not? It's not a totally unheard of idea. In Norway everyones salary can be looked up.
The Darren Shan novels also have a lot of interesting vampire world-building, with in parts a similar dillema of vampires losing their dominant position in the food chain due to humans advancing technology, and different sects in the vampire society having different approaches of how to tackle it.
Anecdotally I've heard from my biochem circle of friends, that many institutions (at least in Germany) are still quite particular when it comes to lab notebooks. Especially ones that strongly monetize on patents, e.g. Frauenhofer. They usually also provide electronic lab notebooks which can either be used directly or into which you have to store copies of the original physical lab notebook.
I suspect that this may be due to different copyright mechanisms in different jurisdictions. e.g. in Germany employees have stronger protections that may allow them to still patent stuff developed in their free time, so companies might want to have a stronger papertrail to prove that outcomes tie back to something done during working hours.
As I understand it, Germany requires inventors to be paid royalties, so this may be a matter of ensuring that the actual inventors have been identified.
The corner radius discussed in the article is utopian and also only works in street layouts that prioritize car driveability over everything else.
A "properly rounded corner" at an intersection as alluded in the article is one that's great for cars (as they don't have to slow down much or have a tight turn. However, they are awful as pedestrian crossings if you want to do a double crossing, as you have to traverse additional distance. They are also much more space-inefficient, which isn't viable in a densely built urban environment.
I don't see what's infeasible about it. It doesn't seem too different from .po files (gettext catalogs) meshed with hooks for post-processing as would see in e.g. a handlebars, both of which have individually found great adoption.