We added a strip of reflective tape which confuses its navigation sensor, we never expected it to run its sweeper motor at 10% power and push a pile of debris over the strip. Our bad.
Basically a 1992 rogue-lite where each room is a different solitaire game. eg: front parlor == clock solitaire, first bedroom == regular solitaire, upstairs is blocked by freecell, etc...
It's a fairly rich concept, you have a ton of different gameplay bound together by a very loose plot/quest mechanisms (eg: blue key == blue door ; boss == win 2 games of solitaire).
Definitely worth sharing if you've got some solitaire fans in your life!
"Open Source Muti-Machine": The heavy, ultra-stiff mass of the cast iron dampens vibrations and forces the cutting tool to move in a perfectly straight, micron-accurate line dictated by the factory-bored cylinders.
Ask an AI about it, but conceptually it's an amazing concept. There are probably billions of "nearly micron-accurate" machines, and if you're 1000% repeatable 90° then the world is (eventually) your oyster.
Apologies if this is somewhere else, but "price per acre" as a sorting mechanism would be really helpful. In the Dallas area, there's a few like $350k/0.2 acres (eg: a typical house on a lot).
Price per acre could suss out whether it's developed or in demand vs more rural (less price per acre).
Other than that, bravo! Great idea, well implemented!
The only proper answer is retroactive bans (a-la competitive doping: "retrospective testing").
Cheaters (athletes) are always incentivized to cheat in "new and exciting ways" today. It's impossible to defend against all possible new forms of cheating, but they instead keep blood samples for up to ten years so that "when they figure out what to test for", they can retroactively penalize participants.
Same with online cheating, save high fidelity recordings and be able to replay. As detection catches up to exploitation, you ban hammer the prior exploiters.
Both of y'all need to look in to look up "cooking oil sprayers", basically simple pumps. https://a.co/d/03MxaoKg
I have ones for cooking oil, olive oil, chili oil, and sesame oil... the chili and sesame in easy-to-use, flavorant amounts are great to dash into vegetables or a salad or whatever, and having it atomized instead of drizzled makes it so much better and more convenient!
Everything the post mentions is 100% true and well-reasoned, especially with the inclusion of pledge/chroot/etc. for dropping privileges.
There's two diametrically opposed deployment mechanisms:
1) stack towers of glop on top of each other until you're running a simple `echo "hello world"` on top of a docker container inside a vm in a proxmox server as part of a k8s cluster under a hypervisor running on remote compute...
2) just run `bash -c 'echo "hello world"'` and front it with CGI (stateless, single binary, yada yada yada...)
Take a peek at https://github.com/Domain/bash.cgi ... not that i'm suggesting that 'bash over busybox using cgi-bin' is the "proper architecture", it's more trying to illustrate that the amount of code that holds you back from being nearly truly "frameworkless" is tiny and easy to reason about.
For some of the internal tooling I'm doing for work, I've been tending towards:
some-cmd [--json|--markdown] ...yet-more-args...
When you use the process and shell environment itself as a repl, you start trending towards `[--cgi-bin]` would "just" be another output type, and the ability (nay: foresight!) to ensure that your commands are independent, reproducible, and only depend on their input arguments leads you directly towards being runnable in both "hostile" (ie: firecracker vm / lambda-style) or very "comfortable" environments (ie: shell, debuggers, unit/integration tests).
Mirrors my experience, and it's funny you mention busybox: I just discovered busybox's ability to serve via `busybox httpd -p 9000 -h . -f -v` with a `cgi-bin` folder dropped in the current directory.
I already write Python services using Bottle that function both as a standalone server and as a CGI script, and I've been updating them to work with busybox's more constrained CGI environment (basically being able to handle the lack of .htaccess rewrite rules).
I definitely see a chance for simple deployment tools to make a resurgence as we create more one-off/disposable/personal software, and the low system requirements for something like busybox + lua stack are extremely minimal, which fits well with the current DDR4-is-good-enough zeitgeist. I'm running them on an old Raspberry Pi 2B and it's plenty performant for the ~10 people that access it regularly.
Event driven, fast, all the networking basics in place including http, mustache templates and encryption, light and small executable, very nice for embedded applications, signals and fd handling built-in, very easy to use…
Have used it very successfully for million-dollar projects, including some scientific applications running on limited-resource systems (512 megs of RAM) ..
Was very, very easy to add C functions to interface with the web front-end, libffi is great for this purpose, but its also very easy to extend as a standard, well-written Lua/C application ..
This is exactly the sort of thing I'm really interested in. I'm particularly excited about various takes on Lua+batteries, have looked into designing my own (C wrapper with bindings to networking, JSON, templating, and DB libraries), but found Redbean to be almost ideal so never got past overall design to dig into code.
Turbo looks fantastic, though! It's precisely the niche I was looking to have filled, so I'll build a prototype or two in it to see what I think. Very much appreciate the pointer!
You’re welcome - we share interests, I too am interested in the Lua+batteries approach to life - I’ve used Lua very successfully in many commercial projects, so I’m quite convinced of its power in spite of the warts and thorns that many newbies in the ways of Lua tend to whine about.
TurboLua is particularly great because it really integrates about all of the I/O mechanisms you could want in a network-centric application, plus it has a pretty nice runtime loop which is easy to hook into and coordinate properly with signal handlers and fd sets and things. Can’t beat it as a very quick way to do embedded stuff too - very easy to do gpio, signal handling, etc.
Good luck, if you have time to share your thoughts after an initial first-pass, I’d be happy to hear your perspective ..
PS I do seem to remember it was either disavowed or inexact. Notwithstanding, it is a bit like Twain or Einstein, they get stuck with things that they could reasonably indeed have said.-
Fantastic, thanks. I love Lua and especially the mindset that goes along with it. Will definitely check this out. Combining it with Datastar could be brilliant - I wonder if TurboLua supports SSE streaming.
This is the first I am hearing about turbo lua, very cool! I was aware of openresty but I still resorted to flask for quick endpoints or concepts. This changes things for me.
"""POSIXLY_CORRECT (originally proposed as POSIX_ME_HARDER) is a historical environment variable used in GNU utilities to force strict compliance with the POSIX standard."""
"Intelligence per second" is a striking phrase! I'll be turning it around my head at a moderate IPS until I hopefully make something of it.
But you're right in sense: moderate intelligence at superhuman rates (and presuming moderate energy usage) is very compelling compared to an intelligence that takes 1000 years to return "42"
I look at it this way. A year ago is a long time in AI terms, but not that long. Those models were already decent for the tasks we're using SOTA models for today.
So imagine taking a year-old SOTA model and running it at 100 tokens per second on an edge device. That's enough to feed a screen's worth of content through it and power decent multilingual message suggestions on IM.
Imagine running it at 1000 tps. That's enough to reparse that screen mid-keystroke, and give you semantic autocomplete in text. Or fully general "the phone has a good idea of what you're attempting to do" context at all times.
There's many, many new classes of features that will open up if decent enough models can be run on edge devices at 100+ "intelligence per second".
Or vice versa... 1000tps == 1tps via solar power + a capacitor (or whatever).
I'm poking (lightly) at the locallama game, have a fancy MBP5 with gobs of ram (so I can demo/trial locally) and have been semi-waffling between whether to chase a mini or studio for local "always on" type stuff.
My outcome was "CapEx v. OpEx", and dropping another $5k for an aluminum cube buys a lot of OpEx (eg: just trickle-drip HF/OpenAI credits to a raspberry pi or VPS orchestrator rather than trying to do the inference locally), ie: $5/mo inference for 1000 months.
HOWEVER, there's definitely a role for that 1-10 TPS type "ambient inference" that I wouldn't mind sustaining on any sort of always-on / local / private compute. My main email address is still on ...@yahoo.com and their spam filtering has gone to absolute shit.
Being able to have the always-on mini (local, trusted, no private data leaves my control) poke at the IMAP/email and thresh it into SPAM/HAM/Personal/Political ... random spot check, I'm getting ~5 emails per hour, and that's completely tractable for staged low-med-high processing. (Subject + rules.py? Subject + Body + LocalSlowTPS? Subject + Body + LocalDeepTPS? Subject + Body + RemoteLLM?)
Even if you did 10000tps of "jev" that's an incredible value... not quite "Literal AI Packet Router", but as you're dancing aroud saying... "Speed is a Weapon"
Look into "OODA Loop" => """The OODA loop is a four-step decision-making model—Observe, Orient, Decide, Act—created by U.S. Air Force Colonel John Boyd to help leaders make fast and accurate choices in chaotic situations. // The main goal is to cycle through the loop faster than an opponent or changing environment. By operating inside another person's loop, you create confusion and outpace their ability to respond. While initially designed for aerial combat, it is now widely used in business, sports, and crisis management."""
reply