What things to learn are more important for "engineers" than using VC messages and history for communicating adequately (including communicating with themselves in the future) and using VC merging, staging etc. to put source code in a good state that they intend to build, share and archive? Irreproducible or incomprehensible work is worse than nothing.
This is naive pathfinding that adopts the shortcut of perfect information.
Good looking pathfinding simulates realistic terrain ignorance (no "psychic powers"), but it is likely to be expensive enough to require other compromises (e.g. updating paths less often).
You reckon the perfect information version is cheaper than an algorithm that works only on the tiles near to the unit? But this quickly gets too complicated to discuss; there's the confusing matter of precalculation versus live updating.
The perfect information version calculates the path once on click, the local version needs to recalculate every time the unit moves (and new tiles are "seen")
Recalculating the path every game tick is too expensive. What brood war did was to just have units wait for a second when they collide with something before recalculating the path. This resulted in horrendous "traffic jams".
It's also why Brood War players got into the habit of spam-clicking, because the game would recompute paths every time you issued a command, so spam-clicking resulted in smoother movement.
With this objective lack or control, sooner or later your LLM experiments in production will drive into a wall instead of hitting a little pothole like this diagram.
And at the same time, they have time to quickly brush it off with "looks like a vendor" even though people are still investigating. Yes, we can see it's moving really fast, probably "move fast break things" been infecting Microsoft, users are leaving Microsoft behind because everything is breaking then clueless VPs blame it on moving too fast?
Serious loss of life is a plausible LLM outcome, particularly for Microsoft who does both operating systems (incidents can be much worse than the Crowdstrike bricking) and chatbot assistants that can offer lethal advice. Catastrophic property damage is hopefully more likely.
Powerful, "capable" plugins are obvious; NSA cannot stop people from writing them, and they have little reason to restrict their use.
I think what NSA is likely to keep confidential are in-house plugins that are so specialized and/or underengineered that their publication would give away confidential information: stolen and illegitimate secrets (e.g. cryptographic private keys from a game console SDK), or exploits that they intend to deny knowledge of and continue milking, or general strategies and methods (e.g. a tool to "customize" UEFI images, with the implication that they have means to install them on a victim's computer).
Generally, the nth roots of 1 form a cyclic group (with complex multiplication, i.e. rotation by multiples of 2pi/n).
One of the roots is 1, choosing either adjacent one as a privileged group generator means choosing whether to draw the same complex plane clockwise or counterclockwise.
"Losing sleep" implies an actual problem, which in turn implies that the mentioned mitigations and similar ones have not been applied (at least not properly) for dire reasons that are likely to be a more important problem than bad QoS.
"Infrastructure" implies an expectation that you deploy something external to the troubled application: there is a defective, presumably simplistic application architecture, and fixing it is not an option. This puts you in an awkward position: someone else is incompetent or unreasonable, but the responsibility for keeping their dumpster fire running falls on you.
Fair pushback — to clarify, I’m not assuming incompetence or suggesting infra should paper over bad architecture.
By “losing sleep” I really mean on-call fatigue during partial outages — the class of incidents where backoff, shedding, and breakers exist, but retry amplification, shared rate limits, or degraded dependencies still cause noisy pages and prolonged recovery.
I’m trying to understand how teams coordinate retries and backpressure across many independent clients/services when refactors aren’t immediately available, not replace good architecture or take ownership of someone else’s system.
If you’ve seen patterns that consistently avoid that on-call pain at scale, I’d genuinely love to learn from them.
Good examples should be complete music pieces and they should be commented: where is important information? How are the numbers computed? How are commands organized? What is the practical workflow for making changes?
> ÆTHRA is output-oriented: you write a script → run it → get a WAV file.
You are competing with traditional noninteractive usage of CSound. What do you think you can do better than CSound? More generally, what are the peculiar and valuable ÆTHRA features that you want to develop well?
The current language is relatively verbose and readable (more suitable for live coding than for a "music compiler"), but somewhat simplistic and ad hoc on the notation side (e.g. no separate tracks, parts etc.) and not very general on the sound synthesis and processing side (e.g. fixed waveforms and keywords for effects).
reply