I'm a huge fan of the Casio F-91W, have two of them on my desk right now. Maybe it's just me, but for this specific model I feel like it becoming bluetooth enabled breaks the spirit of the simplicity of the model.
But hey, seems like people are excited for that, happy for them! Mine will last another 10 years without it.
I own a F-91W and would instantly buy the newer upgrade (if it had vibration alarm and notification, which it doesn't unfortunately). It is more about the iconic design than simplicity.
Awesome launch and good pricing. We built an equivalent version in our org that takes HTML/JSX files and stores/serves them like an S3 bucket would. Works fabulous and we considered turning it into a SaaS product, met a real need in our org. Wishing you guys the very best of luck!!
I am currently building something similar for my company. We are enabling people to host apps with python backends as well, so that people can do more complex tweaking of data for scientific workflows. The out-of-box solutions keep users constrained to an environment that doesn't allow things like importing weird packages on the back and front end for custom apps. The security implications are challenging, but I can mostly just keep the apps hosted in a highly constrained environment.
Separately I haven't yet seen a great security governance model for LLM integrations. At an enterprise level I'd like to govern rules such that, for example, if someone gives an LLM access PII information or proprietary data, then it shouldn't have access to a slack integration or the internet. Controlling this at the employee or team level doesn't make sense, as an employee may have reason to make separate use of both. From a security perspective I want them to be able use LLMs with different types of acccess, but not necessarily the same agent at the same time. Furthermore, they could ideally chain together agents with different permissions in specific orders. For example they could have a workflow where an agent can reach out to the internet, and then have a separate one that can read/write to slack, and then have a third that can interact with PII data. If they tried to wire together agents in the opposite order, it should get denied.
We ended up splitting permissions per-tool for data and per-person for connections, for basically this reason. Every tool gets its own db role that can only see its own schema, and integration credentials live in a broker the tool's code never touches. So one tool can't read another tool's data, and nothing the model writes can leak a credential.
The ordering thing is harder and currently we don't do it. Per-tool permissions at best ban a combination, they can't say "internet then Slack is ok, the reverse isn't." DeepMind's CaMeL paper (arxiv.org/abs/2503.18813) is the best take I know on this, it tracks data flow between tool calls and enforces policy there. Still an open problem as far as I can tell.
Thanks! That's the best kind of validation. If you ever take Prized for a spin, would genuinely love to hear how it compares to what you built, especially on the data access side.
This month has mostly been personal website. Serious warning - style is an HN ripoff atm, forgive me in advance. Will change in the future to something original or minimal.
Project I've got in progress is a migration of the old DIKU mud engine from C to Rust and making a Moog Model D synth recreation in rust with a JS wrapper.
Interesting. I started a similar project with tbaMUD (continued dev of CircleMUD) to Rust in an effort to learn Rust. I'd offer to help, but am currently consumed with converting to Evennia (Python) right now.
The slime art is nice. I watched it for a long time. It's neat how you can open any frame up as an image. The controls in the description didn't work though.
