- Catch 22
- Hitchhiker's Guide to the Galaxy (series)
https://www.espressif.com/en/news/ESP32-S3-BOX-3
There's a model with a more expensive dock, or one without. The one without worked fine. But it had to be the Box 3 not Box 2. It worked pretty well and you could create custom images to indicate whether it was listening, thinking, etc.
Instructions here: https://www.home-assistant.io/voice_control/s3_box_voice_assistant/
The box isn't powerful enough to run an LLM itself. It's just good enough as an audio conduit. You can either use their cloud integration with ChatGPT, or now, Anthropic Claude. But if you had a powerful Home Assistant server, say an Nvidia Jetson or a PC with a beefy Nvidia GPU, you could run local models like Llama and have better privacy.
This is from earlier this year. I imagine they've advanced more since then.
Their LLM integration is super cool. I messed with it for a previous job. Way better than Alexa or Google Home.
One Docker env variable and one line of code. Not a heavy lift, really. And next time I shell into the container I don't need to remind everyone to activate the venv.
Creating a venv in Docker just for the hell of it is like creating a symlink to something that never changes or moves.
NEW, automated children's bicycle. Guaranteed to teach the little tyke how to ride! *
- ^Comes with training wheels, and adult monitor standing by at all times.^
I can think of only two reasons to have a venv inside a container:
-
If you're running third-party services inside a container, pinned to different Python versions.
-
If you do local development without docker and scripts that have to activate the venv from inside the script. If you move the scripts inside the container, now you don't have a venv. But then it's easy to just check an environment variable and skip, if inside Docker.
For most applications, it seems like an unnecessary extra step.
"Team-based shooter eight years in the making had just 25,000 estimated sales."
A few jobs ago, everyone hated the tech stack. The people who had come up with it had long left. I talked to everyone, then came up with a plan to transition to a modern stack. Got buy-in from management.
Half the people (and all who had said they hated the status quo) threatened to quit if we made the change.
Fortunately, it was just in time to collect the 1-year retention bonus. Life's too short. Walked away.
Let's hope no single person worked on that thing for the full 8 years under development. Would be crushed.
Installed RabbitMQ for use in Python Celery (for task queue and crontab). Was pleasantly surprised it also offered MQTT support.
Was originally planning on using a third-party, commercial combo websocket/push notification service. But between RabbitMQ/MQTT with websockets and Firebase Cloud Messaging, I'm getting all of it: queuing, MQTT pubsub, and cross-platform push, all for free. 🎉
It all runs nicely in Docker and when time to deploy and scale, trust RabbitMQ more since it has solid cluster support.
Once they get Threads support, their target audience will be the non-Twitter universe. This would make it easier for businesses, governments, journalists, and non-technical folks like influencers and celebrities to switch out. That's how you get mass adoption.
I just tried it last week. Good start. Lots of promise.