Why not both? LLMs are hilarious when they aren't trying to be funny. They are pretty bad at jokes normally, but when LLMs hallucinate more than normal it has the right amount of absurdity to be funny.
Another great feature of Tcl for writing servers it that you can reload the code while it is running and keep all the state and connections open. Code up/bootstrap your server while it is running the whole time. Sure this is a security nightmare, but it is fun to code.
I have half a MUD that uses TTS and speech-to-text as the interface with LLMs generating the content and a database keeping the context. It works surprisingly well.
If you had a little more software in your car it could automatically remediate the issue and you'd be on your way with no repairman involved or at least tell the repairman exactly what to fix. Maybe you could fix it with the step-by-step workflow on your console.
Indeed. When I took my car in last winter because the light had come on for no apparent reason, as the car was running fine, they charged me $140 to take it out on the road to try to find the reason. No reason was found. Two weeks later, the light came on again (towards the end of 2022). The car was and is running fine. The light will remain on until July when I take it in for a scheduled oil change.
Sounds like it was an intermittent fault? If so, those are notoriously hard for any mechanic to diagnose. Cars _usually_ store code history but it's up to the manufacturer and often the data they provide to the mechanic with a scan tool is misleading or an outright pack of lies.
But the mechanics using their professional grade code reader and related equipment couldn't figure out what's causing it. At least I'm comfortable with "unknown" after that's their diagnosis; I don't think that would be the case if I did it and got that result.
Ansible Kernel calls ansible-playbook on a specially constructed playbook. Ansible Kernel constructs a playbook with a two tasks in it: 1. wait for the kernel and 2. include tasks from a file that does not exist yet. When you enter a #task cell we write that included file and then tell the wait task to proceed. The included file contains the #task cell contents, a wait task, and another include task. This continues until you stop the kernel, the playbook dies on an error, or you enter a #play cell. On a #play cell ansible kernel throws away the old playbook and make a new one with the new arguments. The exported playbook just contains the content on the page (without the wait/include tasks) and should work with ansible-playbook normally.
reply