first of all to mention: i used ai for tests and readme and cleaning code,
link: Open

I made a programming language of my own as a fun experiment, it was just interpretted and did ast at the beggining but then i moved onto a bytecode vm and then cranelift jit, it on my benchmark performed about 100x faster then python and the language syntax is bimmodular you can write stuff like x = 8 or set x to 8 and both work it also has in built translation tool for these syntax, the releases are most prob not updated so i recommend you to build it yourself

made it with RUST.

i would appreciate if you provide feedback and if you like the project you can leave a star 😄

DISCLAIMER: Before I get anyone asking, we = me and the AI. I am not a big paragraph guy but I did my best, tried not to use AI for this post.

I was always thought to myself, "why not make a unit converter into an app?".

I have always used Google for this kind of stuff, but I wanted to make my first Rust project with AI, so I decided to make this as a starting point. Convert has 2 basic features, and a big advantage:

• Convert anything to anything, like meters to feet or centimetres to miles.
• Calculator integrated into the app, which also works with Convert, you can do for example, 2000 centimetres times 3 (which would look like inside of Convert as: 2000*3).
• It is FOSS (Free Open-Source Software).

This is a really basic app, I do not expect a lot from it and I will be honest, this was all coded with AI but I hope you all like it and I get feedback to make better projects like this is in the future. Below will be all information and a video of how this works:

We have 3 versions.

1. egui (4.5 MB) available for Windows, macOS and Linux
2. fltk (2.2 MB) available for Windows, macOS and Linux
3. win32 (0.19 MB) available for Windows only. This is heavily experimental and not intended for real use, only used for educational purposes and developer uses.

Here is a demo of our egui version:

We include 16 categories too, a calculator, live conversion, search box for filtering category list, history and favourites, number format, light / dark theme, swap and copy and our value box accepts arithmetic expressions, not just numbers.

More information to be found below.

GitHub: https://github.com/not6741lol/unit-converter

Live Demo in browser: https://not6741lol.github.io/unit-converter/

Are you wondering which framework to use for your next cross platform app? You heard of Dioxus, but haven't found a proper component library yet to build upon?

No? Anyway, look no more as Libero covers your back! Libero is a batteries included component library for Dioxus.

What it offers:

- 100+ components and hooks with a11y as a driving factor

- Cross platform (Web, Native (Blitz), Desktop (WebView), Android and iOS)

- Human and LLM friendly API and detailed docs

- 20+ pre build themes and every theme and component is overridable

- Rich developer experience with a typed SX builder and composable components

Preview it on the web and see for yourself: https://libero-ui.dev/

A few weeks ago I shared `mil_spec`, a pure-Rust replacement for Apple's Python `coremltools` front end. It let you ingest GGUF/safetensors/ONNX weights, optimize MIL graphs, and emit `.mlpackage` specs without Python or `protoc`.

That still left one closed-source black box between Rust and the silicon: Apple's `ANECompiler`. Every time a graph hit an undocumented planner limit (`error -14`), a silent CPU fallback, or a `slice_update` bug, you were stuck behind a binary you could not inspect or fix.

So I reverse-engineered the precompiled **HWX Mach-O** binary format that the Neural Engine actually executes, and built a native Rust backend and graph runtime (`mil_infer` 0.5 + `milc` 0.6) that emits those binaries directly and runs them on the chip.

Repo (MIT): https://github.com/savageAZfck/mil_spec

### What it does now

1. **Direct HWX Mach-O Emission (`crates/mil_infer/src/hwx.rs`)**

   - Emits precompiled ANE Mach-O binaries (`__FVMLIB`, `__TEXT,__text`, `__TEXT,__const`, `__KERN_0`, `LC_SYMTAB`, relocations, and `aned` command descriptors) directly from Rust.

   - Reproduces Apple's `ANECompiler` output **69/69 byte-for-byte** across the mixed-shape multi-task `conv1x1` chain corpus (including descending-size intermediate arena packing and completion descriptor offsets).

   - **0 ULP (bit-exact) hardware output parity** against `ANECompiler`-compiled binaries across 10 core operator families (`conv1x1` square/non-square/spatial, non-square `matmul`, broadcast `avw` attention matvec, small and large `n > 256` elementwise ops, `sigmoid`, `tanh`, `softmax`).

2. **Whole-Graph MIL Compiler & Layout Scheduler (`crates/mil_infer/src/graph.rs`)**

   - Takes a logical MIL DAG and schedules it across emitted HWX programs (`compile_graph`).

   - **Physical layout currency tracking:** ANE operations disagree on tensor layout (`64B`-strided channel planes `[1,C,1,1]` vs. contiguous vectors `[1,1,1,D]` vs. packed 4-D cache frames `[1,T,1,D]`). The compiler tracks every tensor's physical currency, routes strided projections through `conv1x1` (`32..=4096`) to avoid unnecessary copies, and inserts hardware repack kernels only when a producer and consumer genuinely differ.

   - **Compile-time dequantization folding:** Unpacks multi-blob `weight.bin` offsets (`0xdeadbeef` headers), `constexpr_blockwise_shift_scale` (`int8`, `Q8_0` blockwise, `Q4_0` nibble blockwise with offset), and `constexpr_lut_to_dense` (`palette4`) directly into the 16-lane interleaved `__KERN_0` stream.

   - **Graph fusion:** Fuses single-use `k`-deep `conv1x1` chains and `conv + activation/silu` patterns into single multi-task HWX programs.

3. **Zero-Copy `IOSurface` Runtime & MRU Paging (`crates/mil_infer/src/espresso.rs`)**

   - Loads bare `.hwx`/`.macho` files directly through `_ANEClient` as precompiled models (`kANEFModelPreCompiled` + `kANEFPerformanceStatsMask` so `aned`'s `_ANEMachoPatcher` deploys the relocations).

   - **Zero-copy chaining (`SharedSurface`):** Allocates runtime-owned `IOSurface` buffers once per tensor edge and adopts them across producer outputs and consumer inputs with zero CPU copies between ops.

   - **In-place KV cache without `state<>` ops:** Aliases output ports onto input `IOSurface`s (`alias_out_to_in`) and updates rows on-device via outer-product scatter (`emit_outer_t` + `emit_add4d`).

   - **Belady-optimal MRU residency:** `aned` caps the number of simultaneously loaded program handles (~85). Because `SharedSurface` decouples tensor memory (including KV caches) from program lifetime, `GraphRuntime` unloads programs via `unloadModel` and evicts MRU-first on cyclic DAG loops so multi-layer models don't thrash.

### Reproducible Hardware Verification

In `crates/mil_infer/examples/graph_probe.rs`, a complete **2-layer autoregressive Transformer LLM** (token embedding, RMSNorm, Q/K/V projections, RoPE half-rotation + sin/cos tables, on-device KV cache append, causal masking, softmax, attention*V, output projection, SwiGLU FFN, final RMSNorm, and a `Q8_0` quantized vocabulary head) compiles from MIL text into self-emitted HWX binaries, runs token-by-token on the ANE, and verifies `reset_state()`:

```bash

cargo run --release -p mil_infer --example graph_probe

# graph: 73 nodes (68 prog, 5 host), 14 externals

# generated tokens: hw=[7, 165, 45, 153, 146] ref=[7, 165, 45, 153, 146]

# GRAPH-LAYER mismatches: 0

cargo test -p mil_infer --lib -- --test-threads=1

# 30 passed (byte-identity corpus + 10-family 0-ULP hardware parity + Q8/Q4/palette4 dequant + graph fusion)

```

### Crates (all MIT / Apache-2.0)

- `mil_spec` (IR + protobuf writer): https://crates.io/crates/mil_spec

- `mil_infer` (HWX emitter + graph compiler + Espresso/e5rt runtime): https://crates.io/crates/mil_infer

- `mil_convert` (GGUF / safetensors / LoRA / surgery): https://crates.io/crates/mil_convert

- `mil_onnx` (ONNX + classical ML): https://crates.io/crates/mil_onnx

- `mil_passes` (optimizer): https://crates.io/crates/mil_passes

- `mil_lint` (static ANE placement analyzer): https://crates.io/crates/mil_lint

- `mil_compile` (CoreML compiler driver): https://crates.io/crates/mil_compile

- `mil_verify` (spec diff + golden conformance battery): https://crates.io/crates/mil_verify

- `mil_machines` (DFA / state machines on ANE): https://crates.io/crates/mil_machines

- `milc` (CLI): https://crates.io/crates/milc

Happy to answer questions on the HWX Mach-O layout, how `_ANEMachoPatcher` handles relocations, the `64B` channel stride vs. contiguous layout rules on the ANE.

Hi r/madeinrust! I'd like to share Rooste SSH, an MIT-licensed SSH client for Linux and Windows, with experimental macOS builds. Rooste is Estonian for rust.

For years my SSH setup was PuTTY plus a separate FileZilla SFTP program plus a pile of tunnels I'd set up by hand. PuTTY is rock solid and I have a lot of respect for it, but I wanted everything in one window: tabs and split panes, files next to the terminal, saved tunnels that start with the session. I also wanted a modern interface that looks and works the same on Linux and Windows. I couldn't find a free, open-source app that did all of that, so I started building one.

What it does:

• Tabs, split panes, and a session manager with folders and tags
• SFTP panel next to the terminal (drag and drop, folder downloads)
• Local, remote and SOCKS forwarding, ProxyJump, agent and X11 forwarding
• Built-in key generator and SSH agent; reads OpenSSH and .ppk keys; passwords in the system keyring
• Session recording in asciinema format, and Rhai scripts for automating logins
• Telnet, raw TCP and serial too; imports ~/.ssh/config

Install: MSI, deb, rpm, Flatpak, AppImage, or cargo install rooste-ssh.

I designed and directed the project, and much of the code was written with an AI coding assistant, with CI, tests and fuzzing as the safety net. I'm saying this upfront, and I'd especially welcome reviews from people who know the ecosystem.

Feedback, bug reports and contributors are very welcome.

GitHub: https://github.com/rooste-ssh/rooste-ssh

I've been working on CarryFS, a fairly simple filesystem for everyday use, mainly for sharing external drives between macOS, Linux, and Windows.

I wanted to write as much of it in Rust as possible. Building native filesystem drivers for all three platforms would take a lot more time, using the different languages and last but not least cost money for driver signing. And I didn't want that, I just wanted to work with my usb drives at home.

I went with a shared Rust core and thin adapters using FUSE on Linux, macFUSE on macOS, and WinFsp on Windows. Almost all the filesystem logic lives in Rust.

Since CarryFS is intentionally simple, exFAT is probably its closest competitor. The main differences are that CarryFS also has copy-on-write, checksums, and scrubbing.

What I didn't expect was the performance. Despite running through FUSE, CarryFS turned out to be much faster than exFAT in quite a few of my benchmarks, especially with small files and metadata operations. Sequential reads and writes were mostly limited by hardware I/O throughput, so there wasn't much difference there.

The chart shows the results across all three OSes.

It's still in public beta and have some rough edges(specially in UX) but I'd be interested in early feedback, especially from anyone who's worked on filesystems.

GitHub: https://github.com/carry-fs/carryfs

I built a small GUI app for Linux desktop that shows your system specs (sane, no information overload) using GPUI (through gpui-kit 0.7.1).

I originally built it for ShopnoOS, a Debian-based distro I work on at my work. We needed a simple system specs viewer for our users. The tools I tried were either too detailed (hardinfo2), had a dated UI (CPU-X), or felt more like a task manager (Mission Center). So, I started working on it and thought I’d share. This one just shows basic information.

The data layer has no UI dependencies. A single SystemSnapshot::collect() reads /proc, /sys, lspci, and nvidia-smi, and each collector falls back to Unknown if its source is missing. Tests run against fixture machines (SYSINFO_SYS_ROOT plus stub binaries on PATH), so cargo test needs no display. CI runs build and test on every push.

It is AI assisted, yes. I tested on bunch of systems and VMs. Detection may miss on hardware I don’t own, so reports of wrong or missing values are the feedback I seek most.

Repo: https://github.com/fa-saikat/sysinfo-viewer
Linux only, .deb on the releases page.

Start of the story

I have been trying to solve this kind of bug: input is validated multiple times, which causes performance issue, or never validated, which causes security vulnerability. The solution is to let Rust's type system to enforce the correctness. Therefore I wrote wakuwaku-proof.

This kind of bug often appears in Web application. So I decided why not build a web framework based on it. Thus, wakuwaku.

The home page is https://www.wakuwaku.rs/en.

The web development ecosystem for Rust is highly fragmented. We have sqlx, tokio, lapin, iggy, axum, actix and too many good libraries. But to make the web develop simple and stupid, we need something that brings all of them together, like what Spring to Java. Wakuwaku does this by providing a unified proof framework that use Rust's type system to ensure the components are fit well.

Details

• Advantage: Good for medium (~100 events/s, peak) to large (~100k event/s, peak) scale web application. All-in-one. Can reduce the debug difficulty for vibe coders.
• Disadvantage: Too much work Overkill for small projects. Shortage of maintainer (only 2 people). Need some intelligence to understand what's going on.

AI Usage: - Most (>80%) of the code are hand-written. - Abstraction are designed by experienced human web developer, not AI. - Almost all test code are written by AI. - Almost all documents are written by AI. - I don't use any AI to write this post.

Project progress: rc2 (2026/10/14). Trying to migrate production code from wakuwaku 0.3 to wakuwaku 1.0 to find bugs and design flaw.

What I'm doing now

• Find mismatch between my idea and AI written documentation.
• Further test the framework on production code to ensure it's robust.
• Build template repository for it.
• Test on AI agents to find where the AI agents struggle using this framework, then write skills.

A while ago, I posted something about MotionGfx, a backend agnostic motion graphics crate written in Rust. And in that post I hinted something about an editor. Well this is it, I'm introducing Moxie, an editor built in Bevy, powered by MotionGfx! Moxie is right now in its very early phase, so not every feature is implemented yet, so expect workflow hiccups, and things not working! I'm still working on the export feature (along with many core features), so you can't directly export your animations yet!

As you may have noticed in the screenshot, Moxie is not like any of the other editors you see out there! We are integrating the command based technology that MotionGfx (and Manim/Motion Canvas) is based on into the editor. This result in a really compact timeline (vertically), easy edits (LEGO like drag & drop), and most importantly of all, propagative actions everywhere! This means your edits from the first action can and will affect the animations down the line! Ofc this is a deterministic effect, so you can reason about the change pretty easily.

In the MotionGfx's website: https://motiongfx.voxell.dev (sign up to our email list/newsletter here), I do explain about some of the concepts I mentioned above if you're familiar with command based animation workflows (like delta changes, propagative timing, action relationships, scripting, etc.).

If you're wondering will there be plugin support, yes it is planned. And yes, we will also support scripting directly in the editor in the near future!

I built Fastmash, a Rust command-line tool for statistics on delimited text and quoted CSV. It implements GNU datamash's command language and adds named CSV reports, weighted means, highest or lowest complete records, text-table health checks and ranked comparisons between datasets.

A grouped summary is:

fastmash -s -g 1 count 2 median 3 < data.tsv

The numerical foundation uses software 80-bit arithmetic through rustc_apfloat, certified fast paths for log and exp, and an astro-float fallback. Built-in locale rules keep results independent of the host's installed locale files. The same Fastmash version, input and explicit settings give the same output and exit status on supported machines.

The chart shows selected Linux 0.1.0 measurements against GNU datamash 1.9. RefGene quartiles took 26.6 ms versus 112.8 ms on the Intel laptop, with matching output. The full benchmark page includes slower jobs, including the disk-spill test. These are Linux measurements.

Version 0.2.0 supports Linux x86-64, Windows through WSL2 and Apple Silicon macOS 15+. MIT or Apache-2.0.

Installation and examples: https://fastmash.io/

Source: https://github.com/pederbe/fastmash

Benchmarks: https://fastmash.io/benchmarks/

I'd like people to try a command they actually use. Please share your command and experience here or at https://github.com/pederbe/fastmash/discussions/48. A slower job or unexpected output is especially useful.

I have always thought doing demos of my projects were difficult and they never turned out how I wanted. Trying to record and manually interact with the app in a way that was meaningful was impossible without breaking out the video editing software, giving it several tries, or compromising on the quality.

These frustrations led me to build matinee. You define how the scene is composed, automate keyboard inputs and mouse clicks, and record it into a GIF by defining it in a TOML. It isn't repeatable byte-for-byte on successive runs, but that is by design. While I was designing it I prioritized preserving the clocks and values in the app faithfully over deterministic outputs.

Matinee creates it's own isolation to preserve your privacy and to keep personal data out of your recordings. It is not a sandbox and has not been built to contain an app trying to escape. Don't use it to demo code you don't trust.

I believe what makes it truly powerful is it can run headless to generate your output. This means matinee can be used in CI to record and update demos in READMEs.

One day when I get ambitious I'll build a Windows and macOS port.

The attached GIF is matinee recording a nested instance of matinee recording another project of mine. The box moving around is the camera, what the GIF will look like, for the inner matinee recording.

TL;DR I created a ui framework that works for any backend renderer and released on crates.io/crates/fynix, you can find the source at github.com/voxell-tech/fynix ! Right now, we have an official support for using Fynix with Bevy using `bevy_ui` & `bevy_ui_widgets`!

I'm using Fynix right now for my motiongfx editor, moxie: github.com/voxell-tech/moxie

Fynix is a backend agnostic reactive view tree, styled the way Typst styles a document with set and show rules.

Features

• Views, rules and transitions never name an engine.
• A view asks for the token traits it reads, so it works under any theme that implements them.
• Set and show rules restyle every view of a kind within a scope, as in Typst.
• State rules hold while a node is hovered, pressed, entering, leaving, or in any state of your own.
• Props bound to the world are read again only when their source changes.
• Views can animate their changes, and animate in and out of the tree.
• #![no_std], with alloc only.

The fynix README walks through each of these with examples.

This is my first project in rust. The plan is to add hybrid a* pathfinding and run it on an rc car with a lidar sensor on it, but for now it's just a simulation and the SLAM.

Supports many RSS providers, very configurable, available on Linux, macOS, Windows, NetBSD.

https://terminaltrove.com/eilmeldung/

https://github.com/christo-auer/eilmeldung

AI Usage Disclaimer: This project was made using various LLM tools. If you are not ok with this, don't use it.

So I have used JetBrains DataGrip for ages. It is an awesome piece of software. That said, I don't really need all its features, and recently its memory usage of more than 1GB was really bothering me.

So I decided to build a TUI application that would have all the features that I use from DataGrip, but using less than 40mb of RAM.

It has a query editor with autocomplete and database schema introspection. You can export the results in CSV, TSV, JSON, and SQL formats. It connects to postgres, mysql and sqlite. But since I am using SQLx, it should be easy to support some other databases.

It also has an optional chat feature, where you can connect your own LLM provider and ask it to build the queries for you.

It uses Vim-like keybinds, and it ships with some different themes. But you can configure the keybinds and themes if you want.

I have been using it for my work for the last 6 months, and generally it works pretty well. I cancelled the DataGrip subscriptions because I don't need it anymore.

I made this application for personal usage. But, I decided to share here in case anyone might need a similar tool. MIT license, feel free to fork and do whatever you want with it.

Big thanks for all the crate authors that made this project possible. But, special thanks for the authors of SQLx, Ratatui and EdTUI.

This crate adds a single attribute - #[hotreload] - that can be applied to any function. After performing one-time configuration of Cargo.toml, all annotated functions become hot-reloadable - you can modify them, run cargo build and then your application will use updated version of your function without restarting.

Works on Linux, macOS and Windows.

Crate link: https://crates.io/crates/hotcode
Source: https://github.com/alordash/hotcode

The only supported path to Apple's Neural Engine has been coremltools, a Python package that serializes your graph and hands it to an opaque planner that won't even confirm which execution unit your ops landed on. I wanted a native toolchain for the silicon already in my machine, so I wrote one. Ten crates, MIT, on crates.io.

**The pipeline:** safetensors -> MIL (my IR: ops, stateful graphs, weight blobs, hand-written protobuf wire encoder, no protoc) -> optimization passes -> placement lint -> .mlpackage emission -> compiled .mlmodelc. From there, two execution paths: in-process `MLModel` prediction via `objc2`, or the direct path that skips CoreML's authoring stack entirely and drives the ANE's own runtime (`aned`/Espresso) over recovered `e5rt_*` FFI bindings.

**What's interesting technically:**

- The MIL IR is text-diffable, so compiler output diffs like code.

- The direct path chains 36 layer shards + 4 vocab-sliced heads of a Qwen3-4B into a single ANE stream: zero-copy ping-pong hidden buffers, 72 resident KV cache buffers, shared rope/mask inputs. ~9 tok/s after warm-up on a laptop.

- Conformance harness compares my decode against `MLModel` output on fixed prompts. After fixing a subtlety (CoreML `MLMultiArray` head outputs are strided, vocab stride 32, logical index = flat/32), the token sequences are identical across all 36 layers.

- Non-neural bonus: `mil_machines` compiles Aho-Corasick automata into stateful MIL programs, so even my output firewall runs on the ANE.

**Honest limitations:**

- It rides private frameworks (`ANECompiler`, `e5rt`), so ABI drift across macOS releases is real; I built `haruspex-macho` (Mach-O/dyld-cache introspection + disasm) specifically to re-map symbols when Apple moves them.

- Final codegen is still Apple's `aned`; my toolchain is the front two-thirds (IR, passes, emission, direct runtime path). I haven't reimplemented their silicon backend, yet.

- Apple Silicon only, macOS only, and this is weeks old. The conformance is on fixed prompts; broader coverage is the next milestone.

Repo: https://github.com/savageAZfck/mil_spec

Crates: https://crates.io/users/savageAZfck (mil_spec, mil_convert, mil_passes, mil_lint, mil_compile, mil_infer, mil_verify, mil_machines, mil_onnx, milc)

Happy to answer questions about the e5rt recovery, the MIL serialization, or what the planner actually rejects.

Hey everyone, I recently released gtm, a soon to be cliamp alternative but with a better TUI, background playback and way smaller binary size and resource footprint.

Its also meant to offer cool integrations with other TUI apps like reactive themeing inside of nvim based on the current playing track.

It has two binaries, gtm (the client) and gtmd which is the daemon. This allows multiple clients to control playback meaning that you don’t have to leave your editor (for example if you’re using nvim) to control playback.

Looking for help with docs improvements, more providers and cross platform testing.

I hope you enjoy 💜

Hey everyone! I'm working on Vix, a voxel-based game written in Rust. The core idea is a mix between Minecraft and Factorio, with a strong emphasis on engineering, programming, mysticism, and research.

Why it's interesting:

In-game Zig programming – write and run Zig code directly on in-game computers

Unique painting system – create fully custom paintings you can place in the world

Microblocks on phones – detailed voxel system with stairs, slabs, and complex shapes available on Android, which is unique for mobile voxel games

Planned features:

Robots - similar to Autonauts, programmable and automatable

Automation and factories - conveyor systems, mechanical devices, production chains

Mysticism - a mysterious layer on top of the tech progression

Download: https://livedox.itch.io/vix (Windows, Linux, Android)

Looking forward to your questions in the comments!

TL;DR: We are open sourcing ManimGX, a blazingly fast Rust + wgpu animation engine with a Manim compatible API. Install with pip install manimgx.

Hi everyone, after ~7-8 months of work, we are finally launching ManimGX, our from scratch Manim reimplementation in Rust + wgpu.

The GitHub repository: https://github.com/academa-labs/manimgx

For anyone unfamiliar with Manim, it's the Python animation tool originally created by Grant Sanderson for his 3Blue1Brown videos. ManimGX is a from scratch implementation targeting ManimCE's API, with a Rust renderer built on wgpu. You can install it with pip install manimgx.

The motivation is the same as before: waiting for renders makes polishing an animation a slow process. We wanted to make that loop faster while keeping the familiar Python API.

A few details about the implementation that might interest people here:

• Rust + wgpu for rendering, with PyO3 + maturin for Python bindings and packaging.
• The same renderer runs in the browser through WebAssembly and WebGPU, with Python running through Pyodide.
• Typst for text and math, with mitex translating LaTeX input.
• Geometry passes from Python to Rust as packed arrays and is reused across frames.
• Native video export uses x264 directly, without an FFmpeg subprocess.

It only requires Python 3.13+. Fonts, typesetting, and video encoding are included, so there is no separate FFmpeg or LaTeX installation either.

Most ManimCE code runs after changing the import from manim to manimgx, with differences documented in the migration guide. The documentation includes a gallery of examples with their Python source: https://manimgx.academa.ai

Credit to Grant Sanderson, the Manim Community contributors, whose work this builds on. Happy to answer questions about the implementation. We'd especially appreciate feedback from people working with Rust graphics or WebAssembly, and from anyone trying it with their existing Manim scenes.

Hey everyone!

I've been working on Tincan, an open-source P2P voice and text chat app built with Rust and Ratatui. I recently shipped another release, so I thought I'd share it here.

The idea is pretty simple: open your terminal, create a room, share an invite code, and start talking. No accounts, no sign-ups, and no port forwarding.

A few things under the hood:

• iroh + QUIC for encrypted P2P connections
• Opus + RNNoise for voice and noise suppression
• Ratatui for the terminal interface
• Voice activity indicators, channels, audio controls, and connection status directly in the TUI
• Prebuilt binaries for macOS, Linux, and Windows

Getting real-time voice chat to work smoothly in a terminal has been one of the more interesting challenges, especially handling audio devices, network interruptions, and multiple peers.

There's still a lot to improve, but it's been a really fun Rust project to work on.

Would love to hear what you think, especially from anyone who's worked with Rust networking or audio.

GitHub: https://github.com/bilalyazicioglu/tincan-cli

Website: https://tincan.rs

https://github.com/caneroglu/Geri
I have an OpenWrt router and a few small boards on my desk. I wanted them to send data to one place and take commands back, without writing a dashboard for every new thing I connected.

That turned into Géri. A device describes what it measures and which commands it understands, and the hub builds a UI from that description. Unsent records stay in an outbox when the connection drops.

The GIF is a small demo using curl as a pretend device. On the left it sends records; on the right you can watch the hub's log. Sending the same record again returns duplicate, and skipping a sequence number returns gap.

The self-hosted hub is one binary with a SQLite file. I use Géri daily with my router, where the client uses around 4.6 MB.

It's written in Rust, with several no_std components. The MCU side still needs work — I wanted it to fit on a Blue Pill too, but it doesn't yet :) Also it would be great to add some documentation, i know.

Made it for my own setup, figured I'd share in case someone else finds it useful.

I’ve been building Sping, a network diagnostics CLI in Rust.
The original idea was pretty simple: when ping starts timing out, I usually end up opening more terminals to check the gateway, another Internet target, packet loss, latency, etc.
Sping tries to correlate that first layer automatically: target + gateway + WAN reachability, together with RTT, jitter, loss, trends and network context.

It doesn’t shell out to the system ping command.
Linux/macOS use native ICMP sockets, while Windows uses IcmpSendEcho/Icmp6SendEcho2 through FFI.
The latest release also added proper IPv6 link-local zones, fixed multi-target context handling and an interesting ICMPv6 cross-talk issue on macOS.
It currently runs on Linux, macOS and Windows and is MIT licensed.
cargo install sping
https://github.com/LambdaBytes/sping
Feedback on the Rust/system-level parts is especially welcome.