As you know, Nautilus Image Converter is a tool that can help you rotate and resize images. I also knew it when I was installing and configuring Niri, a Wayland compositor. While I was reading an Arch Linux installation guide, I found the author mentions "nautilus-image-extension". After reading its description, I thought it was interesting, and I installed it.

However, after I started using it, I found some bad things regarding its window and performance.

First, the windows are cropped somehow. I don't know whether any other user notices it, but it's obvious when I use it under Niri Wayland compositor, which makes the window look odd like image below.

Second, when I use it to process multiple images, I feel that the extension handles images slowly. I decided to find out why it processes images really slowly. After I asked AI about it, I finally knew it's mainly because it uses ImageMagick to process images; when it manipulates images, it has to open ImageMagick through a command over and over again, which makes it process multiple images pretty slowly. If you studied Operating Systems, you would know that forking a new process is expensive.

Even though I found the project on GitLab, the project seems to be unmaintained. The latest commit stays at 2022. I checked the issues, there was no more response. Even though someone said that he can help the repo author recreate the application in a issue, there is no more response either.

That's why I recreated this again. If the project is unmaintained, why don't I create my own application which aims to solve these issues?

Features

• Standalone app: It now becomes a standalone app, not binding to Nautilus File Manager anymore. However, you can still bind parent window via CLI arguments.
• Entirely in Rust: No non-rust dependencies, which keeps this app performant, low memory footprint and stable.
• Parallelism: Instead of processing images one by one, this app process images in parallel by rayon.

Limitation

• Unsupported formats: This app only supports formats supported by the image crate; formats such as HEIC are currently not supported.

Screenshots

LLM Usage Claim

Since this application is my first app created with Relm4 and gtk-rs and I wasn't really familiar with them, I used LLM to help me finish connecting events and parent window binding. Other parts of this app such as actual image manipulation logic and widgets are finished by myself. Also, I reviewed all of the code generated by AI and understand most of it except parent window binding code, which I need more time to research on it.

Repository

https://github.com/Kayxue/nautilus-image-converter-reborn-app

I've wanted to build my own video editor for years, and I finally spent my summer break making one!

It's called Zerium, a free and open-source video editor built with Rust, GPUI, and wgpu.

It's inspired by AviUtl, a popular video editor in Japan. My goal is to make something that's intuitive to use while still being powerful enough for advanced editing and motion graphics.

Some of the features:

• GPU-accelerated rendering
• Timeline editing with layers, keyframes, and curves
• Plugin support
• Cross-platform support (Windows, macOS, Linux)
• Completely free and open source

I've just released the first beta! It's still a work in progress, so any feedback is welcome!

Website: https://zerium.pages.dev
Source: https://github.com/1Step621/zerium

Hey everyone! I’m working on Dearust, an experimental, incremental Rust migration of Darling, which runs macOS software on Linux.

The motivation is to explore how much of a compatibility layer this large can move into safer Rust while preserving its existing behavior and ABI. It’s also an experiment in how far AI-assisted development can go when the results are checked against real builds, regression tests, and actual application execution.

I’m using OpenAI Codex extensively for implementation, code review, debugging, and test automation, including parallel agents where useful. That involvement is disclosed in the README and new commits. The repository includes safety notes, verification records, and documented limitations so people can inspect the evidence.

So far, the work includes Rust host utilities and runtime slices for synchronization, errno conversion, Mach locksets, process queries, guarded descriptors, and bounded pathname handling. Testing has also uncovered and fixed concrete bugs, including a null-path crash during bsdtar operations.

The latest build passes 108 Rust tests, 29 Python tests, 16 utility workloads, and 29 app checks—with one explicitly documented log normalization. Earlier testing also covered three GUI samples.

This is still experimental and very incomplete. Most runtime and framework code remains C/C++/assembly, and integration currently depends on a matching Darling build. General macOS application compatibility is still a long-term goal.

Full credit to the Darling developers and upstream contributors whose work makes this possible.

I’d welcome feedback, especially on the ABI boundaries, safety assumptions, testing approach, and migration priorities.

TLDR: built my own RSS reader, with built-in features such as YouTube in-line player, configurable keyboard shortcuts, feed display modes, filters and auto-discovery, HLS playback support, folders, webhooks (Discord, Slack and custom template with replaceable variables) and full text search. Not vibe-coded. This is a project I've been putting in a lot of time and energy over the past 6 months. Please kindly check the repo, the code, commits, PR's, CI workflows, etc, before judging.

Live demo: https://demo.wyrmrss.com/
Repo: https://github.com/kryoseu/WyrmRSS

The demo instance is mostly read-only to prevent abuse. It's also a shared instance, so it's possible everything will be marked as read already, in which case you can toggle "all posts" to see everything.

I'm a software dev with over 10 years of experience who's decided to use my skills and build something for myself after dealing with a difficult burnout phase having worked at AWS for 8 years. I have since left and am in a much better space now :)

This project is a result of that process. The backend is mostly human-coded, but leaned more on LLMs for the frontend as it's not my strongest area. I have, however, designed, reviewed to the best of my knowledge and am confident about everything I've pushed.

The logo was designed by a tattoo artist I know from Brazil. He's credited in the repo's README file.

On the Rust side:

It's a workspace split by layer: routes, api/crud handlers, database, webhook and the RSS fetcher and polling worker. Only the database crate talks to Diesel.

Postgres or sqlite is chosen by a cargo feature, so the different binaries (server and desktop app) build the same crates and only the database engine they need.

API types derive ts_rs::TS, so cargo test regenerates the frontend's types.

One WyrmError type implements actix's ResponseError, so raw database errors never reach a response.

For installation, I provide easy-to-use Docker compose and Kubernetes manifests. The mobile version can be installed as a PWA. There are also builds for Linux, Windows and MacOS.

Feedback welcome, especially on the Rust side or if you're coming from Miniflux or FreshRSS.

Thanks.

Built a desktop app for security analysts: force-directed vendor<->CVE graph, AI-powered mitigation drafting, CISA KEV flagging, persistent chat sessions. Local-first (SQLite on disk, no telemetry).

Stack: Tauri 2 (Rust shell) + Python (async MCP client) + Vanilla JS + vis-network.

Why Tauri: Native look, ~15MB binary, ~80MB RAM idle. WebView2 quirks (blob downloads) were manageable with Rust fs fallback.

Key Rust pattern: Thin IPC layer. Rust spawns Python processes for heavy lifting (LLM orchestration, NVD parsing). Chat history goes through stdin to bypass Windows 32KB CLI limit:

let mut child = Command::new(&python_path)

.arg("--chat").arg(&cve_id)

.stdin(Stdio::piped()).spawn()?;

{

let stdin = child.stdin.as_mut().unwrap();

stdin.write_all(messages.as_bytes())?;

}

let output = child.wait_with_output()?;

Would love feedback from folks who've shipped Tauri apps or Rust/Python hybrids. Where do you draw the line between keep it in Rust and delegate to Python?

Repo: https://github.com/sleepti3ht/Panopticon

Writeup: https://dev.to/sleepti3ht/building-panopticon-a-local-first-cve-intelligence-map-with-tauri-2-rust-python-4p6p

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/

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

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/

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.

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

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.

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.

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.

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!

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.

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.

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.

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 💜

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