aerxes

We use OpenEngine to continuously penetration test our environment. It has discovered several critical vulnerabilities and we're sure that it will discover more. We're also experimenting with auto-remediation techniques & discovering what works.

The OpenEngine CLI was just updated to 1.5. It includes tools for executing graphs and loops (with your agent of choice).

Documentation is above. A quick introduction to graphs and loops is here: https://sheahawkins.substack.com/p/how-to-use-openengine-to-...

Let us know what you think. We're excited to share it!

Next items on the roadmap:

* Ability for the dispatching agent to ask clarifying questions

* Telephony kit so your agent can make outbound calls and wait on hold

* Openrouter integration for offloading llm generation

I am aiming to build this into a more fully-featured voice assistant framework. Basically I am treating "tasks" as a first-class object and oriented mostly toward building a conversational frontend for Hermes (and potentially OpenClaw).

That wasn’t the point nor even an offhand comment in their post.

C++ is fine and has a lot of libraries built up — especially around image processing. It will be quite some time before Rust replaces C++. But if I had time to learn only one sugary C, it’d be Rust.

That’s what debate’s about. I do recognize that caring about single threaded workloads and performance do contribute to snappier UI (and backwards compatibility).

The point that I’m making is that you can write multi threaded applications without dropping support for single core systems.

I’m not advocating making software multithreaded only, since obviously that doesn’t make sense.

But, in many modern languages (including c++) multi threading 1. Doesn’t significantly detract from the performance of single core systems 2. Can massively improve the performance of multi core systems, even with 2 cores or more.

For appropriate applications, the memory overhead and the cost of the bootstrapping code for instantiating a worker thread should be dwarfed by the time of actually computing the task (we’re talking about actions 100ms or longer). Not using multiple threads when you could reasonably half or quarter that time (without needing to drop support for single-core systems) is just foolish. If you’re that worried about single core performance then maintain two code paths, but at least recognize that the majority of commodity systems sold today, including the ones you listed, have multiple threads available to them to do the work that have the most painful wait times.

If we were arguing about designing vehicle safety testing suites for the worst performers (a very real problem that we have right now) we wouldn’t even be having this conversation.

Writing multithreaded applications increases the performance ceiling. If an application can’t take use of multiple threads, but is written in a multi-threaded way, there’s no harm done. It simply runs the multi threaded code in a single threaded way (think of ParArray) with a bit of overhead incurred for “becoming multithreaded”.

Reasoning out of adding multithreaded support for long running actions because “most systems can’t take use of the extra threads” is just irrational, especially since most modern commodity systems could have a linear improvement with the additional threads.

The single core systems are barely hurt by the memory overhead involved with provisioning CORE_NUM of worker threads. But the multi core systems can take massive advantages from it.

I don’t know dude, if you want to write software for the worst performers instead of commodity hardware that’s up to you

Just that single core systems are dying and probably won’t come back. Even Raspberry Pi’s are quad core now.

The data that it presents shows that >50% of PCs surveyed have 6 cores or more.

This reads as something obvious. Of course between choosing a simple solution and a complex over-architected solution, you would choose the simple one.

The key word here is “over-architected”. The author is nitpicking academic and bureaucratic architecture design that happens at large (arguably inefficient) companies. But they evolved that way to protect themselves, probably before testing was widely understood or implemented.

Regardless, it tries to make a sensationalist topic when in fact it’s trying to say “architecture is common sense” + don’t prematurely optimize.

Overall not the worst article but its incendiary nature rubs me the wrong way.

Gonna beat a dead horse here, but >50% of PCs that are surveyed by Steam have 12 threads or more.

That’s PCs that have steam installed at all.

Intel’s bare minimum current-gen i3 processor has 12 threads. That’s the absolute cheapest desktop-level processor you can get.

Your phone probably has 6 cores (though not 12 threads).

So yes, if you’re writing code for desktop hardware, it’s safe to assume you have at least 8 threads. Maybe you don’t want to consume all of them, but it’s better to let the OS handle scheduling.

https://www.techspot.com/article/2363-multi-core-cpu/

Follow-up question:

What is the model’s behavior when “idle”. Does it propogate actions independently or does it only respond to stimuli?

I’d like to really poke at this “meditation” effect.

Is LaMDA aware of passing time? Does it remember information from encounters that take place over a week or month?

This postmortem is incomplete: it fails to address the main three roots of the problem:

1. This business is too flippant with their write-able production access.

2. No user should have DROP DATABASE grants on production.

3. Clearly one of their employees was using a port forward to access production.