The idea is basically GitHub Copilot or Tabnine, except instead of prompting it with code, you prompt it by playing a few notes on a MIDI piano. The model then continues what you played, entirely on-device.

The app is free if anyone wants to try it. Happy to answer questions about the model, training, Core ML, or the many things that didn't work. [simedw]

UpLink was a 491 gram payload testing the insulation properties of 3D printing filaments, while also transmitting 320x240 images over a radio link -- up from the 18x10 images last year!

This is a writeup on our engineering process, mistakes made, and learning experiences. It covers:

- Custom electronics designed in KiCad

- Firmware design

- Results from the data we received on the ground

- Image transmission

- Launch day logistics, and where things went wrong

All hardware, software, firmware, and CAD is available on GitHub: https://github.com/radeeyate/UpLink, licensed + certified as open source hardware: https://certification.oshwa.org/us002826.html

If you just want to see the images received, I put up a gallery here: https://uplink.gallery.radi8.dev/

If you have any questions, comments, or concerns, let me know. I'm happy to answer anything! [radeeyate]

https://github.com/rustsec/advisory-db/issues/3161 [abhisek]

I used AeroSpace over yabai for the tiling window manager because I didnt wanted to compromise on SIP which is a mac security feature. It is supposed to be keyboard first like omarchy to move windows organize workspaces etc The setup runs around 157mb of ram and consists of AeroSpace, Karabiner (for the super key), and five small self build swift binaries.

I am running it daily on my M1 max macbook, currently on macOS26. I havent tested it much on other macbooks or macOS versions. The install script creates a manifest file to backup what was installed before and what it installed itself, the uninstall script takes that into account to clean up the macbook to exactly the state it was in before. It needs quite some permissions for it sfunctionality which I layed our in the project readme. I wanted to be really transparent about which permissions it uses and for what reason.

I would love to get some feedback or see people trying it out and hearing your opinion. Mostly about what still doesnt feel smooth in the experience or if you find any performance issues. [paulsp]

I've been working almost exclusively with coding agents since January of this year, and over the past few months I began to feel utterly exhausted by them. They're great, but I'm finding it more and more tedious to write full sentences for every change I want. Not only that, but it seems there's a complexity limit for codebases - beyond a certain point the agent begins confusing itself.

I'd like to go back to writing code, but I don't want to go all the way back to fully manual coding. So I've come up with this interaction paradigm where you:

  1. write pseudocode in whatever way makes the most sense to you
  2. on save, the editor synchronizes your work to real source code
  3. the pseudocode is persisted alongside the generated code, making your prompt effectively a stored record of intent.

Right now it's just a proof of concept - installation instructions are here in the readme: https://github.com/danielvaughn/hz

You can also watch a video of it in action here: https://x.com/danielvaughn/status/2090456808431165715

Cheers! [danielvaughn]

I've been using it personally for the past few months, and onboarded 5,000+ sellers and done 3,000+ payouts. 74% of new sellers on my marketplace choose Zoneless over Stripe, which is really interesting. I appreciate crypto and stablecoins are a bit of a touchy subject, but for this use case of sending global payouts cheaply, it's perfect.

The project is open source with an Apache 2.0 licence, which means there's the benefit of no lock-in and no risk of your account getting flagged or shut down. It also has an almost identical API and dashboard to Stripe.

Would love to hear any feedback you may have in the comments. [tinyprojects]

Kandelo is still experimental, but it already runs a substantial range of existing software.

Do you have use cases for this?

We are trying Kandelo as a new foundation for WordPress Playground which runs server-side WordPress entirely in the browser. Kandelo also looks promising as a sandbox for running agents in the the browser and on the command line. On the side, we've been playing with porting games and desktop environments and even compiling runnable programs within Kandelo.

Yet it feels like there are many possibilities we haven't considered.

How would you like to use something like this?

Demos:

Some notes: The demos have been tested in desktop browsers. Unfortunately, YMMV on mobile today. Some of the disk images are large (~50MB) and may take a while to boot initially.

Main set, with Shell (bash, vim, nethack, and more), Nginx, PHP, WordPress, and Doom: https://kandelo.dev/20260819-demo/

LÖVE game engine: https://kandelo.dev/20260819-demo-love/

SNKRX running under LÖVE: https://kandelo.dev/20260819-demo-love/?vfs=love-snkrx-abi44...

Commander Keen running in DOSBox: https://kandelo.dev/20260819-demo-dos/?demo=keen

LXDE desktop PoC: https://kandelo.dev/20260819-demo-lxde/?demo=desktop-lxde

Background

I wanted an authentic OS-level foundation for running systems software in the browser and started this as a vibe-coded exploration. I figured it would end up being too slow and that we would have to offer many different ways to compromise default POSIX behavior to get anything usable. But after weeks of fighting agents, insisting on genuine POSIX compatibility as the default, I was surprised at how well the system worked without those compromises.

Nginx, PHP, Python, Ruby, Redis, and even MariaDB were able to be built using the SDK with minimal hacks.

Then we started porting games, having fun, and playing to see how far we could push it.

Notes on architecture:

There is a central, single-worker kernel, aiming to provide all supportable POSIX syscalls. Each process is a dedicated worker with independent memory. Each process thread is a dedicated worker that shares memory with threads from the same process. Syscalls are done with the process SharedArrayBuffer and the Atomics API. fork() is supported. The system is centered around virtual file system (VFS) images, and the VFS can contain lazy references to programs that may or may not be used. Vim is such a reference in the shell demo.

On GitHub: https://github.com/Automattic/kandelo [brandonpayton]

Demo: https://www.youtube.com/watch?v=VdpHehY64ls

We built Vendo because every SaaS eventually faces the same problem: every customer needs something slightly different. One wants a new report and another needs a workflow that only makes sense for their team. These requests either sit on the roadmap, become one-off engineering work, or force the customer into spreadsheets and external tools. We wanted the user to be able to create the missing feature themselves, without leaving the product.

Here is how it works:

- npx vendo init reads the product's API surface, theme, routes, and more. These are used so that the apps Vendo creates (1) look on-brand and native and (2) have the ability to read data and perform actions directly through the company's API

- When a user asks for a feature, we have a custom Vendo harness that writes a React component with a bunch of Vendo add-ons and guardrails (ex. ability to make calls to the host API + our component library). Every save is compiled, type-checked, run against real API responses, and rendered before the user sees it. We just released a benchmark and write-up here with more info for anyone interested: https://vendo.run/blog/generating-product-ui-measured

- We use QuickJS to make sure that anything the agent creates is sandboxed and can't mess with the company's site. Vendo compiles the component and runs it with Preact inside a QuickJS VM with no access to the DOM, network, or clock. The VM returns a UI tree, which the host renders using the product’s registered components. When the user clicks something, QuickJS emits a tool call; the host executes it through Vendo’s guard and passes the result back into the same VM, preserving the screen’s local state.

There's a lot of generative UI right now: streaming developer-written components into a chat (Vercel AI SDK, CopilotKit, Thesys), or rendering your app inside someone else's assistant (OpenAI Apps SDK, MCP Apps). We differ on two things. Vendo lives in your product and acts through your API as the signed-in user, so what it makes is durable: real apps users keep, pin, and run on triggers while they're away, and not components that are merely confined to a chat. Plus, it's not capped at putting together a bunch of prebuilt components: the agent can build arbitrary apps, from a quick dashboard out of your own components to real custom code running in a sandbox, and either way data only ever comes from tool calls to your API.

Here are some things customers are using Vendo for today:

- Letting their users create custom dashboards and reports. These are mainly UI-based and focused on letting the user see the exact graphs and metrics they care about

- Letting their customers create recurring automations. A big thing as well that has been used for these automations is the fact that we connect to external connections, so users have been automating many of their inter-tool workflows (ex. an automation that sends a slack alert based off of something in the product)

- B2B customers letting their customers customize the product with specific business logic. Often this is simple things like an extra field on a form, or an extra permission, but it is hard for a business to keep up with them otherwise.

- Creating and sharing custom dashboards/apps across an organization. Since the apps Vendo creates are durable, they can be shared, reused, and forked (which can’t be done with many of the other in-chat generative UI solutions)

We've spent a lot of time thinking about how AI and agents will change the way people consume software. We think the answer is personal(ized) software: you see the UI you need to see, you tell an agent exactly what you need, and the product molds to how you work.

The key insights that have enabled the product to work are:

- A rule in code always beats a rule in a prompt.

- Invent as little syntax as possible. Generation got faster and more reliable when the output looked like what models already know (JSX-shaped markup) instead of a clever custom format.

- Deterministic beats model wherever you can get away with it. Theme extraction is pure static analysis, and a remix starts as a copy of your component, no model call.

Vendo is completely open-source (Apache-2.0) and can be self-hosted, so feel free to check out all the source code here: https://github.com/runvendo/vendo.

Would love you to try it out and give us your feedback: https://docs.vendo.run/. Or if you’re a company looking to embed Vendo in your product feel free to book a call here: https://cal.com/team/vendo/intro-call [yousefh409]