mapcn recently crossed 12,000 GitHub stars! Kinda insane.

It's becoming the go to map library for shadcn projects and agents, and the traffic has been over the top.

More exciting things on the way. Thank you, everyone!

Most anime ships an English subtitle track that translates the Japanese script, which does not match the English dub performance. DubTitlerr watches a media library, transcribes the dub audio per episode with faster-whisper, corrects proper nouns against a wiki-verified per-show glossary, repairs low-confidence lines with an LLM anchored on the subtitles already in the file, drops Whisper's hallucinations over music and silence, merges the translated signs and song lyrics into the same track, and muxes the result back with the file's own fonts as a default subtitle track. It also refreshes Plex per episode.

Why it might interest you technically:

- Idempotent by design. A version-stamped `.dubtitles.done` sidecar per episode means safe re-runs and crash recovery, and no stage reads the pipeline's own previous output as input.

- Repair talks to any OpenAI-compatible endpoint: llama.cpp or Ollama on your own hardware, or a hosted API. With a local model, the only outside calls are the show-wiki lookups for names.

- 0.3.0 added a real control plane: accounts with admin and user roles using scrypt hashes and server-side sessions, a first-run setup wizard, nine settings categories with value provenance, atomic `settings.json` / `secrets.json` writes with backups, named LLM connections with write-only keys and SSRF protection, a request queue with priority and a Runs page, Sonarr and Radarr webhooks with path mapping, and audit logging naming the acting principal.

- Human review is part of the design. A repair can pass every mechanical guard and still change the meaning of a line, so accepted repairs are queued for review with audio playback, and a verdict applies to that line across the whole show.

Requirements: NVIDIA GPU with CUDA for transcription (6 GB is enough for the default model at int8; CPU works but is far slower), Docker with the NVIDIA runtime, and a repair endpoint: a small GGUF model server or a hosted API key. Image is `ghcr.io/xenarathon/dubtitlerr:v0.3.0`, also `:latest`.

State: beta, validated end to end on One Pace (the show I built it for), Sword Art Online and Digimon, machine transcription needs the review pass, and it is not SDH. Contributions welcome, especially glossary coverage for shows beyond those three.

Testing on more than one show paid off, because each one found a different kind of problem. My Digimon release carries the official subtitles for the English dub as image subtitles, so I OCR'd them into an answer key: across episodes 1 to 27, about 91% of DubTitlerr's words matched it (88 to 94% per episode). Most of the misses were character names, like Etemon coming out as "Edamon" or Gennai heard as "Jedi", which is exactly the list the per-show glossary exists to fix. Sword Art Online found bugs One Pace never could. One Pace has a hand-curated glossary, so nobody noticed that the automatic glossary miner had never worked: it passed ffprobe a flag ffprobe does not have and got back nothing, on every file. Fixing that exposed a timeout that could kill a whole run, and fixing that exposed the miner reading the signs-and-songs track as if it were dialogue.

GPL-3.0.

---

This is 100% vibe-coded slop. I wrote it with Claude driving. But I didn't just say "make the thing with no mistakes." The whole project has specs, epics and stories, adversarial reviews (had other models try to break it), and real test coverage. I've been project managing it like an actual engineering effort, not a prompt-and-pray. I'm sharing it because it fills a gap I couldn't find a solution for, and I thought it might be a useful accessibility tool for people who want dub-matched subtitles without waiting for an official SDH release. This isn't meant to replace human-transcribed SDH subtitle tracks. Those are always going to be better. It's for when they don't exist.

This is SOMA, an open source desktop app for doing CAD together with a coding agent. You use the agent you already have, like Claude Code, Codex or OpenCode. It runs in a normal terminal inside the app.

The agent writes the model as CadQuery code. SOMA builds it on every save and shows it in 3D. If something is off, you click on a part, measure it or draw on the 3D view and send that to the agent. The agent can also check its own work. It can build, measure, check for collisions and render images from the command line.

Some details for the curious. The app is Electron and TypeScript, the modeling side is Python. The geometry is done by OpenCascade and the FEM by CalculiX, so the hard math comes from proven projects. A model is just a folder with code and a Git history, you can open it without SOMA.

It's GPL and my first open source project. Builds for Windows, Mac and Linux, but I've mainly tested on Windows. Already over 100 stars on GitHub :)

GitHub: https://github.com/Kai-Jungsthoefel/SOMA

Feedback and issues are very welcome.

Voici une nouvelle version de Myostoox, un lecteur multimédia gratuit, open-source, conçu principalement pour Debian XFCE Trixie et Lubuntu (26.04 LTS) (mais pas que...), utilisant Python, GTK3 et GStreamer.

L'idée de départ était de créer un lecteur audio simple et complet… puis c'est aussi devenu un lecteur vidéo...

Cette application gère désormais :

• Musique locale et CD audio
• Radio Internet
• Lecture vidéo
• Listes de lecture M3U / M3U8 / IPTV
• Lecture de DVD et de Blu-ray (expérimental)
• Égaliseur, réglages de tonalité et de tempo
• Paroles LRC
• Analyseur de spectre
• Mini-lecteur (audio), Nano-lecteur (audio), effets de transparence, mode sans bordures et mode plein écran
• Notifications de bureau
• Intégration MPRIS2
• Formats : .aac, .ac3, .aif, .aiff, .avi, .dts, .flac, .m4a, .mkv, .mp3, .mp4, .mpeg, .mpg, .oga, .ogg, .opus, .wav, .webm, .wma, .wv ...
• Monobloc pour l'instant... (myostoox.py + translations.json + logo.png).
• Inspirations (fonctionnalités et visuels) : AIMP, Winamp, Audacious, DeaDBeeF, VLC, mpv, SMPlayer…

Un paquet Debian est disponible pour une installation facile, et le code source est disponible sur GitHub :

https://github.com/MilOvni/Myostoox

Installation du paquet téléchargé au terminal (dans le répertoire du fichier) :

sudo apt install ./myostoox_1.3-1_all.deb
# ou
sudo dpkg -i myostoox_1.3-1_all.deb

Je partage ceci ici principalement pour obtenir des retours d'autres utilisateurs Linux (appréciations, injures (ou peut-être pas...), signalements de bugs, propositions d'améliorations, etc.). Je suis particulièrement intéressé par son comportement sur des distributions et environnements de bureau autres que Debian/XFCE et Lubuntu/LXQt.

Bref, merci d'y jeter un oeil (et pourquoi pas une oreille)...

Mise à jour 17/10/2026 - Myostoox 1.3-1 :

Spectre :

• Styles : Barres (défaut), Oscilloscope, Pixel (audio / radio / flux / CD-DVD audio uniquement)
• Traductions des panneaux « Couleur » / « Couleur des barres » (boutons inclus)

Apparence :

• Mode Sans lecteur : masque le panneau de contrôle, garde la playlist sans en-têtes
• Option Maximiser (plein écran playlist, fenêtre en arrière-plan)
• Menu Apparence aussi dans le menu contextuel de la playlist
• Retrait de « Toujours au premier plan » du sous-menu Plan de la fenêtre (afin d'éviter certains problèmes...)

Ajouts au Menu contextuel de la playlist :

• En tête : Ajouter des fichiers / Ajouter un dossier
• Radios, Égaliseur, Pitch/Tempo, Spectre (styles inclus)
• Supprimer / Vider juste au-dessus de Quitter
• Quitter l’application

Raccourcis salvateurs... :

• Alt+Q : quitter
• Ctrl+Alt+X : quitter et réinitialiser
• Ctrl+P : menu contextuel playlist

Modicications esthetiques :

• Ajustements de la lisibilité de certains thèmes...

Correctifs Nano-lecteur :

• Retour fiable au mode normal (playlist et métadonnées restaurées)
• Indépendance mini / nano clarifiée
• Infobulle mise à jour sur le morceau en cours (elle apparaît au survol du lecteur et de sa playlist)

Divers :

• Traductions complétées
• Paquet Debian 1.3-1

Corrections de quelques bugs divers.

Tide’s main goal is to keep music’s RAM use low while gaming. I’m the maintainer of this open-source Windows YouTube Music player, which uses a Rust backend and Slint UI with native audio helpers instead of an embedded browser. It includes playlists, song radio, a draggable queue and a mini player. Total memory varies, particularly while resolving tracks; the demo’s comparison is one measured example. The repository includes the source, demo and screenshots. It’s an early preview: the installer is still unpublished pending setup checks, and account connection uses a manually loaded Chrome companion. YouTube integration is unofficial. Development uses AI assistance. I’d welcome feedback on the code, UI and setup flow.

I built Talk DAT! at Knight AI+AV. The application source is Apache-2.0 licensed, and it is a free dictation tool for Windows and Apple-silicon Mac.

The repository includes the desktop app, build information, and local-versus-provider setup. Local speech and writing options can work offline after model downloads and configuration. Optional cloud routes use your own key and that provider can charge separately. Brand assets and bundled model licenses are separate from the application-code license.

Source: https://github.com/KNIGHT-AI-AV/talkdat

Release downloads: https://github.com/KNIGHT-AI-AV/talk-dat-releases/releases

If you inspect the project, feedback on setup clarity and the dictation-to-output flow would be useful.

Screenshots show the Windows interface in v0.4.172-beta. Current downloads are on the website.

I read with KOReader on a jailbroken Kindle, and getting books onto it always meant turning on the PC to open calibre, or plugging in a cable.

So I made KoSend, a small Android app that acts as the calibre side of KOReader's wireless connection. You queue books on the phone, tap Connect in KOReader, and they arrive.

How it works:

- Add books to a queue, or share them to KoSend from any app (browser downloads, file manager, Telegram…)

- Turn on the server in the app

- In KOReader: tap the top of the screen, wrench tab, Calibre, Connect

- KOReader discovers the phone on the network and receives the queue one book at a time

There's nothing to install on the reader: no plugin, no SSH, no web browser. KoSend implements the part of calibre's wireless device protocol that KOReader's client uses (discovery, handshake, book transfer). Books get proper calibre metadata (title, author from the EPUB), so they also show up in KOReader's calibre search.

It isn't a calibre replacement: no library, no metadata editing, no conversion. It only delivers files.

- Open source, GPL-3.0

- No accounts, no internet; everything stays on your local network

- EPUB, PDF, MOBI and the other formats KOReader opens

Tested on a Kindle Basic (5.18.1) with KOReader 2026.07.1 and on Android 16 smartphone.

Looking for testers on Kindle, Kobo, PocketBook and other KOReader devices.

KOReader's calibre client is the same on every platform, so in theory KoSend should work there too, but I only own a Kindle. If you try it, please let me know in the comments or in a GitHub issue whether it worked, with your device and KOReader version.

GitHub: https://github.com/FedericoDiTosto/KoSend

APK release: https://github.com/FedericoDiTosto/KoSend/releases/latest

Hi everyone!

I’m the developer behind Treeporter, an open-source tool that lets you send files and folders directly to GitHub from any device.

I’m looking to improve Treeporter and would appreciate your feedback!

I’ve created a short feedback form where you can share your experience, report issues, or suggest new features.

📝 Share your feedback here: https://chatform.in/f/treeporter-user-feedback-0cef1b

Every response helps me identify what works, what needs improvement, and what features would be useful for the community.

Thanks for supporting independent development!

GitHub: https://github.com/Wiyotl/Treeporter-main

Getting users is one of the hardest parts of building a SaaS. You can spend months building something great, but if people don't know it exists, it doesn't matter how good it is. After getting 80 users for my own product, I wanted to make it easier for other founders to figure out how to reach their audience. That's why I'm building Falbor, an open-source project that helps SaaS founders discover competitors, find marketing opportunities, and figure out where to promote their products. The goal is to help founders understand their market and find relevant places where they can reach potential users, instead of blindly promoting their product everywhere. Falbor is open source, so anyone can explore the code, contribute ideas, or help build it. I'd love to have other developers join me in making it better.
GitHub: https://github.com/falbor-devs/falbor
I'd love to hear your thoughts and suggestions! 👋

I made Algorithm Visualizer: write an algorithm, step through it one statement at a time, and watch your arrays, maps, trees and graphs change as it runs.

While a normal debugger works well, it lacks the ability to show data structure in a visual and easy to understand way. This is focus mostly on helping debugging leetcode style questions or self-contained segment of code.

It works with JavaScript, TypeScript, Python, Ruby, PHP, Lua, Java, Kotlin, Swift, C#, Go, C and C++. Each variable can be drawn as boxes, a memory diagram, a grid, a binary heap or a node-and-edge graph, picked automatically from the shape of the data (linked lists, trees, adjacency lists…).

Some point worth noting:

• No server at all. It's one self-contained.
• Python, Ruby and PHP run as real WebAssembly runtimes (Pyodide, ruby.wasm, php-wasm), loaded from a CDN the first time you use them.
• Java, Kotlin, Swift, C#, Go, C and C++ run in interpreters written in JS for this project. They aim to behave like the real thing in the places you'd notice: integer overflow, HashMap iteration order, Go slices sharing a backing array, C++ vectors reallocating. C is memory-checked, so instead of silently corrupting memory you get "use after free" or "out of bounds" with an explanation.
• Every run is recorded up front in a Web Worker (killed after 3 s, so an infinite loop can't freeze the tab). That's why stepping backwards is as instant as stepping forwards.
• Share links contain the code itself, deflated into the URL hash, so nothing gets uploaded and a static site can open any link. There's an <iframe> embed too.
• React + CodeMirror 6, with dagre for graph layout.

Code: https://github.com/Spuntagano/algorithm-visualizer

I'd love feedback, especially on algorithms or data shapes that don't draw the way you'd expect or any other bugs you may encounter. Also feel free to comment if you have any feature you'd like to see implemented.

Ai disclosure: Total vibeslop

I tried a bunch of planners over the last few months — Super Productivity, Vikunja, Planify, TickTick and a few other open-source ones.

Some of them were genuinely good, but I kept running into the same problem: they were great at helping me plan tomorrow, but not so great at helping me understand what actually happened yesterday.

Once I finished a task, it was basically gone. I wanted to know things like: did that 2-hour task actually take 2 hours? What kept getting pushed? Was I really being consistent, or did it just feel that way?

So I ended up building Personal Planner.

The basic idea is pretty simple: plan your day, do the work, then actually look back at it.

It has:

• an hour-by-hour Day view with timers, so planned and actual time sit next to each other
• daily and weekly reviews where you can look back at what happened
• a year-long consistency heatmap and streaks
• Experiments for trying something for a few weeks and seeing whether it actually worked
• an Inbox for ideas you want to schedule later

I also really didn't want another subscription just to plan my own day, so the app is completely free with no locked features.

It's local-first too. Everything works offline, and sync is optional. If you do enable it, each device still works from its own local database and Supabase is just the sync layer on top. Your synced data stays in your own Supabase project.

It runs on Linux, Android, Windows and macOS.

A couple of honest limitations: the Windows and macOS builds are currently unsigned, and I don't own a Mac, so the macOS build has only been tested through GitHub Actions.

Download:
https://github.com/Karthikshabari/PersonalPlanner/releases

Source:
https://github.com/Karthikshabari/PersonalPlanner

It's my first Flutter app, so if you try it, I'd genuinely appreciate feedback, thank you trying it out

Hey everyone!

I wanted to share **AegisVault**, an open-source, zero-trust cryptographic workstation I built in Python for cold storage, air-gapped operations, and quantum-resistant communications.

### 🛡️ Why I built this:

I was tired of seeing "cloud password managers" get breached and wanted a truly local, sovereign offline workstation that doesn't rely on third-party servers or telemetry.

### 🚀 Key Features:

- **Zero-Trust Cold Storage:** AES-256-GCM authenticated encryption + scrypt (BIP-38) memory-hard KDF with optional machine-level hardware binding.

- **⚛️ Post-Quantum Hybrid KEM:** Ephemeral key exchange combining classical X25519 ECDH with lattice-based Ring-LWE (NIST FIPS 203 ML-KEM q=3329 parameters).

- **📲 Optical Air-Gap & LSB Steganography:** QR transceiver for completely offline machines + high-speed lossless LSB pixel embedding (<10ms).

- **🧩 Shamir's Secret Sharing (K-of-N):** Threshold secret recovery over GF(257).

- **💀 Dead-Man's Switch & Panic Hotkey:** Global OS-level Ctrl+Shift+L instant RAM scrubber and automated DoD 5220.22-M zeroization.

- **🛡️ 6-Vector FIPS 140-3 POST:** Deterministic NIST Known-Answer Tests and AST zero-trust scanner on boot.

Everything is 100% open-source under the MIT license:

🔗 **GitHub:** https://github.com/yiitpepek/AegisVault

I would love to hear your feedback, architectural critique, or feature suggestions!

I'm a personal trainer and gym manager who's become increasingly frustrated with the state of fitness and coaching software. Expensive subscriptions, half-baked applications, unnecessary cloud dependencies and questionable data privacy practices.

So I started building True Grit, a premium, entirely offline workout tracking and coaching application written in Flutter.

It's a massive undertaking, nowhere near finished, and probably more feature-packed than most people will ever need. But what I've built so far works incredibly well, and I've put an enormous amount of time and effort into getting it where it is today.

Some of its current functionality and ongoing development:

• Workout tracking: The centrepiece of the application. Fast, intuitive logging with an overview mode displaying individual exercises in dedicated containers, alongside a guided, full-screen experience that takes you through your workout in sequence.
• Media library and editing: A functional photo library and non-destructive editor using custom multi-stage shaders, with an interface inspired by premium photography applications. Performance optimisation is still ongoing, with video support planned.
• Social exports: The goal is to produce beautiful, customisable workout summaries, progress photographs and comparison exports, complete with personal branding and optional overlays of linked training or client metrics. Parts of this are still in development.
• Advanced analytics: Ambitious progression and comparison functionality, eventually allowing different training and performance metrics to be overlaid on the same graphs to explore relationships between them.
• Bespoke training decay modelling: Inspired by Banister's impulse-response model, incorporating three separate streams of training data to help estimate training adaptations and recovery.
• Custom interface: A bespoke calendar, dialogs, navigation and components built around the Liquid Glass widgets package for Flutter.
• Cross-platform architecture: Built in Flutter, with plans for a dedicated desktop coaching interface offering a more spacious experience for client management and programme creation.
• Much more to this too but i'd be here all day...

And perhaps the most important part? Everything is entirely local.

No mandatory accounts. No subscriptions. No cloud dependency. No vendor lock-in.

Your database, photographs and training history belong to you. Back them up wherever you want, migrate between devices and continue training regardless of your internet connection.

The longer-term vision is to allow coaches to create programmes and distribute them to clients through portable packages, with clients returning their completed training data just as easily.

I want the software to support the relationship between coaches and athletes, not replace it or make either party dependent on an expensive third-party platform.

But here's my dilemma.

I originally intended to sell True Grit. However, seeing the extraordinary pace of AI-assisted development, reverse engineering and feature-by-feature software reimplementation has made me reconsider the future of proprietary software.

I'm now seriously considering releasing True Grit completely free, publishing its source code and inviting community contributions.

Not because I think the work I've put into it is worthless, but because I genuinely believe the project could become something much more meaningful if other people were able to contribute to its development.

I'd love to see developers, coaches, athletes and researchers collectively improve it. Perhaps even establish open standards for exchanging training data that other applications could eventually adopt.

My biggest reservation is commercial exploitation.

I have absolutely no interest in companies taking the code, repackaging it and charging people for software intended to be freely accessible.

I want independent personal trainers, gyms and athletes to use it without restrictions, including coaches who earn their living training clients. What I don't want is another software company turning it into an expensive subscription service.

That makes licensing complicated, potentially requiring a source-available licence rather than a traditional open-source one.

And I appreciate that restricting commercial use could discourage some contributors, which is part of why I'm looking for advice.

There's also a more personal reason I'm considering this.

I'm completely new to Reddit, so apologies if this isn't quite the right place for this discussion!

Throughout my life, I've frequently chosen open-source software over proprietary alternatives. I've benefited enormously from the work of developers who've dedicated their time and expertise to creating incredible tools that anyone can use.

I've always had a tremendous amount of respect for that.

In many ways, I feel like this could finally be my opportunity to give something back to a community that's given me so much.

I'm under no illusion that I've built something perfect. I'm sure there are developers, designers and researchers far more knowledgeable than me in their respective fields who could take parts of what I've created and improve them considerably.

Honestly, that excites me.

Ultimately, my motivation is simple.

I believe independent coaches and athletes deserve better.

Personal trainers should be spending more time on gym floors, interacting with clients and actually coaching, rather than being held hostage by expensive platforms and unreliable cloud infrastructure.

And nobody should have to surrender their personal information just to track their workouts.

I'd be far prouder to see True Grit become a respected, freely accessible platform that genuinely helps people, and perhaps even influences how other fitness applications are developed, than to make money selling another fitness subscription.

Even if it never achieves that kind of recognition, knowing I've contributed something useful would mean a great deal to me.

So I'd genuinely appreciate some honest perspectives, particularly from developers, open-source maintainers and personal trainers.

Would you open a project like this to community development, keep it proprietary or take a different approach entirely?

And how would you handle licensing if allowing professional use and community contributions, while preventing commercial repackaging, was one of your fundamental goals?

It's an enormous vision, I know. But I genuinely believe the community deserves better.

And I'd love to help make that happen.

I kept running out of disk space and found 6 Flutter versions, 3 Android NDKs, 4 Node versions and a 13 GB emulator I hadn't started in a year. Version managers are great at installing things, but nothing told me which ones my projects still needed.

So I built Stackyard, a desktop app for Windows and macOS:

• Every toolchain in one window: Flutter, Node.js, the Android SDK, Java, Python, .NET, Gradle and Xcode simulators, plus the frameworks your projects use (React, Next.js, Vue and more)
• Knows which project uses what: it reads .nvmrc, package.json, .fvmrc, build.gradle, local.properties, .python-version, global.json and more, so every installed version shows the projects that need it and the unused ones stand out
• Problems come with a fix button: a project pinning a version you don't have, a broken JAVA_HOME, dead or duplicate PATH entries, a Java too new for your Gradle
• Installs any version of Node, Python, Java, Go, Rust, Flutter and more, straight from the publisher and checked against their hash
• Cleans up old projects: node_modules, build, .dart_tool and Pods in projects you haven't touched in months, which come back on the next build
• Emulators and simulators: every Android emulator and iOS simulator with its size and last start, plus Xcode's simulator runtimes (often 8 GB each)

It shows every step before running it, removes to the Trash by default, and never edits your projects. No account, no telemetry. MIT licensed.

GitHub: https://github.com/AqibJavedZeepalm/stackyard
Download: https://aqibjaved.dev/apps/stackyard/

Feedback is very welcome. If it's useful, a star on GitHub helps others find it.

f your Go debugging loop is: send the request in Postman, switch to the IDE, hope the breakpoint hits, open pprof in a third window, tail logs in a fourth — adOmnia puts that loop in one app.

Recognized HTTP routes link to their handlers. "Debug Request" attaches Delve, pauses in the handler, and shows frames, variables and goroutines next to the API response. With capture on, the SQL and Kafka messages the request produced come along for the ride.

Go side: gopls, test explorer + coverage, Delve (conditional breakpoints, goroutine inspection), pprof, execution traces, architecture/impact views. Around it: an API client (REST/gRPC/SOAP/WebSocket), database tools (Postgres/MySQL/Mongo/Redis/SQLite), broker and log viewers.

Local-first, no account, no telemetry, MIT, built with Go + Wails. Runs on Windows/macOS/Linux.

Releases: https://github.com/Andrea-Cavallo/adOmnia/releases/latest

I'm building my own programming language and compiler: Raz.

It translates Raz code into C++, with the goal of turning .raz programs into native executables. The project is a work in progress, and I'd love to hear your feedback.

https://github.com/marboris/razlang

I'm building my own programming language and compiler: Raz.

It translates Raz code into C++, with the goal of turning .raz programs into native executables. The project is a work in progress, and I'd love to hear your feedback.

https://github.com/marboris/razlang

I’m collecting language models running locally on unusual hardware. The list includes retro computers, game consoles and microcontrollers.

A few examples:

• Commodore 64 with a 2 MB RAM expansion, running a tiny 260K parameter story model.
• A 66 MHz 486 running that same model under DOS.
• Nintendo Wii running a 15M parameter model with int8 weights.
• Ports for PSP, ESP32 and Raspberry Pi Pico boards.

Each entry includes hardware requirements, the model checkpoint, reported speed where available, and links to the original project or writeup. Emulator demos and remote clients have separate sections.

I maintain the collection. All credit for making these ports work goes to their original authors.

https://github.com/emrehangorgec/awesome-llm-on-anything

Know another documented port that belongs here? I’d appreciate a link. Corrections to the existing entries are welcome too.

Hello all,

I’ve built a music aware desktop turntable for Linux, with everything designed in Blender.

The record spins with your music, the tonearm follows the track’s progress, and album artwork appears on the sleeve and record. You can control playback and volume directly from the turntable.

It follows your music player rather than playing music itself, including compatible browsers too. Available controls and artwork depend on what the player provides through MPRIS.

Regarding Performance, Talis reuses the static background and updates only the parts that change. Continuous redraws stop when there’s nothing animating, and “Pause when hidden” reduces rendering work if the DE supports it. Scenes are rendered in blender upto 4K.

I am working of few more features and additions too.

Get it here: Github or buymeacoffee (If you wanna support)

Thank you ;)

Hey everyone!

For the past 6 months, I've been building Trigora, a high-performance durable execution platform for long-running AI agents and programs.

It's powered by Transparent Continuation Checkpointing (TCC), an execution architecture I've been developing to eliminate history replay during recovery.

It started with a simple question: Why should a program have to repeat work it's already done just to recover from a crash?

Many existing systems recover by replaying what happened before the failure. That works, but it can become increasingly expensive as programs run longer.

I wanted to take a different approach. Instead of replaying the past, TCC saves the information needed to pick up where the program left off. If something crashes, a fresh worker can restore that saved state and continue without replaying the execution history.

Some highlights:

• ⚡ Ultra-fast recovery: I've measured recovery as fast as 0.06 ms at the engine level.
• 🔄 No history replay: Recovery restores committed state directly.
• 🦀 Rust/WASM engine: The core is written in Rust, with native and WebAssembly support.
• 🛠️ Built-in developer tooling: Benchmark execution, verify durability, and simulate failures with fault injection.
• 💻 Multiple languages: TypeScript, Python, and Rust SDKs, with more languages planned.
• ☁️ Cloud + local development: CLI, local runtime, and managed Cloud platform.

It's designed for programs that need to survive failures, wait for external events, run AI agents, or execute for hours or days.

I've recently launched the platform, and I'm now trying to get it into the hands of developers who might actually find it useful.

There's also a technical report covering the architecture, benchmarks, and limitations if anyone wants to dig deeper.

I'd genuinely appreciate feedback, particularly from anyone who's worked with durable workflows, background jobs, or AI agents.

GitHub: https://github.com/trigora-dev/trigora

Website: https://trigora.dev

Would you find something like this useful in your projects? And what would make you hesitant to adopt it?

I’ve been using physical pocket calculators since the mid-1980s, and I’ve always loved the speed, tactile feedback, and direct control of hardware key layouts. The main motivation behind ViCalc was to bring that exact same speed and workflow efficiency to a modern PC keyboard—allowing you to touch-type mathematics seamlessly without taking your hands off the keys to click UI buttons.

Rather than just imitating a physical handheld calculator, ViCalc is built to optimize desktop mathematical workflows and complex calculation tracking.

🧮 Key Features & Workflow Design

• Direct Keyboard Mapping: All functions and operations are directly mapped to your PC keyboard, eliminating the need to click through UI buttons with a mouse (though mouse/touch interaction is fully supported if preferred!).
• Full & Exportable Calculation History: The entire step-by-step history is logged automatically as you work. This makes it effortless to review your process or copy-paste the entire multi-step calculation directly into research notes, LaTeX documents, or technical reports.
• Flexible & Adaptable GUI:
  • Minimalist View: Hide virtual keys entirely—ideal once you learn the shortcut mappings by heart.
  • Custom Views: Toggle between a standard numpad, a compact left-side layout, or a full scientific keyboard layout.
  • Expandable History Pane: Easily track, review, and manage long sequence calculations.

🛠️ Modes & Technical Details

• Scientific & Complex Modes: Full suite of trigonometric, scientific functions, and complex arithmetic support.
• Programmer Mode (Base-N): Bitwise operations and conversions across Hex, Dec, Oct, and Bin.
• Language: Python 3
• License: Open Source (MIT License)

🔗 Links & Downloads

• GitHub Repository: github.com/Kudaschov/ViCalc
• Windows Installer: ViCalcSetup.exe
• Homepage: kudaschov.de/en/vicalc-4

I’d love to hear your thoughts, feedback, or any feature requests from the community! How do you currently handle rapid calculations and history logging on desktop?

Hi everyone,

I started working on this project out of pure frustration with how we connect software today. We often hear that systems are "integrated," but in practice, it’s mostly superficial—endless boilerplate code, messy spaghetti architectures, and rigid connections. Even AI agents or cross-platform services struggle behind the scenes because the underlying infrastructure wasn't designed for seamless interaction.

Instead of writing custom glue code over and over, I tried stepping back to build a lightweight, config-driven core (WOS) that acts as an adapter layer. The goal is to let services and software talk through a single unified protocol without hardcoding.

I've opened the source code and documentation on GitHub because I believe fundamental architecture grows best when refined by the community:

Repository & Architecture Docs: https://github.com/Auto55597/wos

Since I'm building this from my own perspective, I'd really love to validate my assumptions with experienced system engineers here:

1. Is this integration friction something you actually deal with in production, or am I overcomplicating a solved problem?
2. Looking at this core concept, where do you see potential bottlenecks or flaws in the architecture?

Thanks for any feedback or critiques!