SIA (Self-Improving AI) is a framework that orchestrates a three-agent loop (meta-agent, target agent, feedback/improvement agent) to iteratively improve an AI system's performance on a benchmark task. In production, it runs as a CLI tool (`sia run`) that sets up a virtual environment, loads task files, and executes generations: the meta-agent reads `task.md` and generates `target_agent.py`, the target agent executes the task and logs results, and the feedback agent reviews the execution and rewrites the target agent for the next generation. A FastAPI web dashboard auto-launches to visualize per-generation accuracy, agent code, trajectories, and improvement plans. The architecture is a CLI-driven monolith with a plugin system for agent backends (Claude, OpenHands, PydanticAI), JSON-based provider/profile configuration, and Docker sandboxing for secure target-agent execution. It relies on external LLM APIs (Anthropic, OpenAI, Gemini, Nebius, OpenRouter, Together) and optionally on Modal/SandboxFusion for the RL-based weights mode. The repository also bundles four benchmark tasks (GPQA, lawbench, longcot-chess, spaceship-titanic) with public/private data splits and evaluators, giving it a hybrid character that includes data/research components. However, its primary function is as an application for running and visualizing self-improvement experiments.
This repository is a curated collection of Markdown files providing detailed, step-by-step instructions for configuring privacy and security settings across a wide range of software, operating systems, and online services. It covers desktop and mobile browsers (Brave, Firefox, Chrome, Edge, Vivaldi), operating systems (Windows 10/11, Android versions, macOS Sequoia), messaging apps (Signal, WhatsApp, Telegram), social media (Facebook, Instagram, Reddit, Twitter), and many other tools. The content is organized alphabetically, with each file containing screenshots (referenced but not included in the repo), notes, and tips. There is no executable code or build system; the repository is purely documentation. It serves as a reference guide for users seeking to minimize data collection and tracking. The project is actively maintained, with frequent updates tracking changes in the latest versions of the covered software.
ClassiCube is a Minecraft Classic-compatible multiplayer game client and launcher written in C. It implements a full voxel game engine: block world storage and rendering, player physics and collision, entity models, inventory, chat, texture packs, lighting (classic heightmap and fancy flood-fill), block physics (liquids, falling blocks, TNT), particles, and the Classic/CPE network protocol. A separate launcher subsystem fetches server lists, handles updates, downloads texture packs, and starts the game. The codebase is organized around an IGameComponent lifecycle (Init/Free/Reset/OnNewMap), a typed event system, and platform abstraction layers (Window_, Platform_, Graphics_, Audio_) that share the same API across dozens of desktop, mobile, web, and console targets ranging from modern Windows/Linux to PS1, Dreamcast, N64, and Amiga.
Kvantum is an SVG-based Qt style theme engine, primarily targeted at KDE and LXQt desktop environments. It replaces the default Qt widget styling with highly configurable SVG-based rendering, driven by theme configuration files (.kvconfig) and SVG element definitions. The system consists of a Qt style plugin (Kvantum) that intercepts widget painting, a GUI manager (kvantummanager) for installing/selecting/theming per-application, and a preview application (kvantumpreview) that displays all widget types to test themes. The architecture is monolithic but modular: the style plugin contains separate rendering, animation, blur, window dragger, shortcut handler, and event filtering subsystems. Key entry points are the style plugin (KvantumPlugin), the manager CLI/GUI, and the preview app. External dependencies include Qt (6/5/4 with separate code paths), QSvgRenderer, X11 (optional for blur and window drag via XAtom), and KDE Frameworks (optional for KWindowEffects). The codebase demonstrates high craftsmanship in several isolated components (ThemeConfig, BlurHelper, WindowManager, Animation framework, ShortcutHandler, symbolicIconEngine) but suffers from triple code duplication across Qt4/Qt5/unified directories and app-specific hacks that increase maintenance burden.
Witsy is a feature-rich desktop AI assistant built with Electron and Vue 3. It operates as a Bring-Your-Own-Keys (BYOK) client, aggregating dozens of LLM providers (OpenAI, Anthropic, Google, Ollama, etc.) into a unified chat, agent, and automation platform. The architecture follows a standard Electron main/renderer process split, communicating via IPC, with a Vue 3 frontend and a Node.js backend. Beyond basic chat, Witsy provides a sophisticated agent system supporting multi-step workflows, A2A communication, scheduling, and webhooks. It includes a full RAG pipeline (document ingestion, chunking, embedding, vector search), a plugin system for tools (MCP, code execution, web browsing, image generation), and extensive voice capabilities (STT/TTS with multiple providers). Data is persisted locally as JSON files within workspaces, with a vector database for semantic memory and document retrieval. A key differentiator is its automation layer, which can control the desktop (text selection, pasting, app detection) via platform-specific automators (macOS, Windows, nut-js). It exposes a local HTTP API and a CLI for external integration. The MCP (Model Context Protocol) client allows it to connect to a vast ecosystem of third-party tools. While primarily an application, it contains significant data engineering components (RAG pipeline, memory manager, deep research orchestrator) that are tightly integrated into the app's workflow. The codebase is well-structured with a strong emphasis on testing, though its massive feature surface and reliance on external APIs introduce inherent complexity and maintenance challenges.
µStreamer is a lightweight, high-performance MJPEG-over-HTTP streaming server built in C for V4L2 video devices, primarily targeting Raspberry Pi-based PiKVM systems. In production, it captures raw video from a V4L2 device (e.g., HDMI capture via TC358743), optionally validates and filters frames, encodes them into JPEG (CPU-optimized via libjpeg, hardware pass-through, or V4L2 M2M encoders for H.264), and serves them over HTTP using a custom event-driven server. It also exposes frames via POSIX shared memory sinks for external consumers like the Janus WebRTC plugin and a Python extension. The architecture is a monolithic C application with multiple binaries (ustreamer, ustreamer-dump, ustreamer-v4p) and a separate Janus plugin, sharing a common library of utilities (threading, logging, frame handling, IPC). Key entry points are the main loop in src/ustreamer/main.c, the HTTP server in src/ustreamer/http/server.c, and the capture/encode pipeline in src/ustreamer/stream.c. External dependencies include libevent (HTTP), libjpeg-turbo (JPEG encoding), libv4l2 (capture), libgpiod (GPIO), and optionally janus-gateway (WebRTC). The repository is production-grade with Docker packaging, systemd support, and extensive CLI options, but shows signs of code duplication (library copies in janus/ and python/ subdirectories) and macro-heavy patterns that increase complexity.
Hermes Desktop is a native macOS desktop application that serves as a companion for the Hermes AI agent framework. It provides a rich GUI for managing remote Hermes instances over SSH or local connections, including session browsing (chat transcripts), a full terminal emulator (via the vendored SwiftTerm library), Kanban board management, cron job scheduling, file editing, skill browsing, usage analytics, and workflow presets. The architecture is a monolithic SwiftUI + AppKit app with a service layer that communicates with the remote host by generating and executing Python scripts over SSH, parsing JSON responses. The app is designed to be a direct client without any intermediate backend, treating the remote Hermes host as the sole source of truth. It includes a custom design system (HermesUI), localization support (en, zh-Hans, ru), and comprehensive test coverage. While the codebase is well-structured and demonstrates strong SwiftUI and macOS development practices, it has some monolithic views and relies on fragile embedded Python scripts for remote operations.
Steam Economy Enhancer is a single-file userscript (~4,500 lines) that runs via Violentmonkey on Steam Community pages. It detects whether the current URL is an inventory, market, market-listing, or trade-offer page and initializes a matching enhancement module. On the inventory it injects bulk-sell/card-sell/crate-sell buttons, duplicate detection, gem conversion, booster pack unpacking, per-item price labels, and quick-sell panels populated from Steam's order book. On the market it identifies overpriced/underpriced listings against a price heuristic, supports mass removal and auto-relisting, adds client-side search/sort/select-all controls, and aggregates total listing values. On trade offers it renders per-party item counts and price summaries. All server actions are executed through Steam's internal AJAX endpoints using the user's own session cookie. Under the hood, the script is organized as an IIFE with region annotations. Every external call flows through a hand-built serialized request queue with adaptive rate limiting (300ms baseline, 1s for market endpoints, 5s after errors) and a circuit breaker that halts after repeated HTTP 400/401/403/404/405/429 responses. Long-running operations (selling, relisting, grinding, pricing) are run through async.queue pipelines with concurrency 1, jittered delays, and 30-45s backoff retries. A rolling session cache built on localforage keeps price histories and order books across tab restarts while rotating through six bounded IndexedDB buckets to prevent unbounded growth. The fee engine precisely mirrors Steam's market fee math, including the December 2025 rule changes for 11 currencies that switched from floor to round and introduced a $0.01 minimum per fee. The code is heavily coupled to Steam's page globals (g_rgAssets, g_ActiveInventory, g_rgWalletInfo) and DOM structure, so the script cannot run outside steamcommunity.com. However, several embedded patterns are self-contained and instructive: the request queue, the rolling session cache, the fee calculation engine, and the pure-function price heuristic. Maintenance is healthy: the code incorporates December 2025 Steam rule changes, uses modern library versions, and CI runs ESLint on every push. There are no unit tests—the only automated check is linting.
onedark.nvim is a Neovim 0.9+ colorscheme plugin implementing the Atom One Dark and One Light themes with Lua and TreeSitter support. The codebase provides 8 theme styles (dark, darker, cool, deep, warm, warmer, light), comprehensive TreeSitter highlight definitions (modern @-prefixed captures), LSP semantic token integration, and support for over 24 plugins (nvim-cmp, telescope, lualine, indent-blankline, etc.). It includes a robust test suite with automated highlight group verification and manual visual testing files. The architecture is modular: palette.lua defines raw color values per style, colors.lua selects and merges with user overrides, highlights.lua maps groups to colors with configurable code styles (italic, bold), and init.lua handles setup/loading/toggling. The utility module provides reusable color blending functions. The repository is actively maintained with frequent releases, detailed changelogs, and responsive issue triage. While primarily a Neovim plugin, its color handling and test patterns could inspire similar theme implementations.
Chai-1 is a molecular structure prediction tool that takes FASTA sequences (proteins, DNA, RNA, ligands, glycans) and predicts 3D structures using a diffusion model. It is packaged as a Python library with a CLI (`chai-lab fold`) and a Python API (`chai_lab.chai1.run_inference`). The pipeline ingests sequences, optionally generates MSAs via ColabFold server, loads templates from RCSB, computes ESM embeddings, applies user-defined restraints (contacts, pockets, covalent bonds), tokenizes all atoms, generates a rich set of features, collates them into batches, and runs a TorchScript diffusion model to produce multiple structure samples. Outputs are ranked by confidence metrics (pTM, ipTM, pLDDT, clash score) and saved as CIF files. The codebase is well-structured with clean abstractions (feature generators, data contexts, collation), strong typing (jaxtyping, beartype), and CI quality gates. It is a hybrid of a production-grade inference tool and research code, with some copied components (rigid transformations from AlphaFold, ColabFold MSA server) and a monolithic inference entry point. The repository is actively maintained with recent commits, PyPI releases, and comprehensive examples.
LosslessSwitcher is a macOS menu bar application that automatically adjusts the audio output device's sample rate and bit depth to match the lossless track currently playing in Apple Music. It works by reading system logs (OSLog) from Music.app and CoreAudio subsystems to detect the current track's sample rate, then uses CoreAudio APIs via the SimplyCoreAudio library to switch the output device's format. The app is not sandboxed because it requires access to system logs and the ability to modify audio device properties. It is built with SwiftUI and uses Combine for event-driven updates. The architecture includes a SwiftUI app entry point (QualityApp.swift), a legacy NSApplicationDelegate for menu bar management and permissions checking, an Observable class (MenuBarController) that owns the OutputDevices and MediaRemoteController, and parser utilities for extracting sample rate and bit depth from console entries. A user can also configure a custom script to run when the sample rate changes. The code demonstrates modern Swift patterns but is tightly coupled to macOS-specific frameworks and the Apple Music ecosystem.
This repository is a comprehensive collection of indicators of compromise (IOCs) published by ESET Research, covering a wide range of malware families, APT campaigns, and cyber threats. It is organized into per-campaign directories, each typically containing a README.adoc with contextual documentation and tables of IOCs, hash lists (MD5, SHA1, SHA256), and often detection rules in YARA, Sigma, or Snort formats, as well as MISP events for structured threat intelligence sharing. The data is derived from ESET's own investigations and is intended for use by security analysts, threat hunters, and automated detection systems. The repository's architecture is a flat monorepo with no application code; it is purely a data publication. Key entry points include the README.adoc files that serve as human-readable indexes, and machine-readable artifacts such as YARA rules, Sigma rules, Snort rules, and MISP JSON exports. The repository also includes a few standalone Python scripts for malware analysis (e.g., Turla Carbon tool, SparroWocky extractor) and a Volatility 2 plugin for Linux/Rakos detection, though these are tightly coupled to specific investigations and may require legacy dependencies. External dependencies are minimal: the Python scripts require Python 2 or 3 with specific libraries (e.g., pycrypto for carbon_tool.py), and the Volatility 2 plugin requires the Volatility 2 framework. The core data (IOCs, rules, MISP events) is self-contained and can be used immediately upon cloning. The repository is licensed under BSD 2-Clause, allowing broad reuse. Overall, this is a valuable resource for threat intelligence, with well-structured and consistently formatted data. However, some IOCs may be stale, and the supporting tools are not actively maintained. The detection rules are static snapshots and may require tuning for modern environments. Despite these limitations, the repository demonstrates high craftsmanship in data organization and provides reusable components for detection engineering and threat research.
This repository contains the complete design files, firmware, and assembly instructions for the Redox ergonomic split mechanical keyboard. It is not a software application in the traditional sense but rather an open-source hardware project delivering PCB Gerber/KiCad files, 3D-printable case STLs, precompiled QMK firmware hex files, and detailed build guides for both wired (Rev1.0) and wireless (Rev1.0W, Rev2.0WHS) variants. The code aspect consists of firmware configuration and custom KiCad footprints for keyboard components. The repository serves as a distribution hub for makers to manufacture their own Redox keyboard, with instructions for flashing via avrdude, ST-Link/Docker, and supports multiple firmware ecosystems (QMK, ZMK, KMK). The primary value is in the hardware design and documentation, not in runtime software.
This repository is a Home Assistant custom component (`custom_components/alexa_media`) that provides deep integration with Amazon Alexa/Echo devices. It operates by interfacing with Amazon's unofficial internal API through the `alexapy` library, enabling control over media playback, volume, DND, alarms, lights, and sensors, as well as sending TTS notifications. It supports multiple Amazon accounts, OAuth/TOTP authentication, and HTTP/2 push for real-time state updates. Architecturally, it follows Home Assistant's integration patterns rigorously. It implements a multi-step Config Flow for authentication, a `DataUpdateCoordinator` subclass with debouncing for efficient polling, and an HTTP/2 push client for low-latency updates. It exposes 7+ entity platforms (media_player, sensor, switch, light, etc.) and 7 custom services. The codebase is well-structured with clear separation of concerns, including dedicated modules for entity capability detection (`alexa_entity.py`), shared state management (`amazon_kids.py`), and safe diagnostics (`diagnostics.py`). The project is actively maintained with a robust CI/CD pipeline, extensive test coverage, and a large translation set. However, it carries a high technical drift risk due to its fundamental reliance on a reverse-engineered, frequently changing Amazon API. The codebase also shows signs of an ongoing architectural migration from legacy `hass.data` storage to a typed `runtime_data` pattern, and its loose tooling configuration (mypy ignore_errors, broad exception handling) suggests areas where engineering rigor could be improved. Despite these risks, several of its internal patterns (debouncing coordinator, login error decorator, TTL cache) are well-crafted and potentially reusable in other API-dependent integrations.
redis-plus-plus is a production-grade C++ Redis client library built on hiredis, providing synchronous, asynchronous (libuv), and experimental coroutine (C++20) APIs. It covers the full Redis command surface including strings, hashes, lists, sets, sorted sets, streams, geospatial, hyperloglog, pub/sub, scripting, transactions, pipelines, and server commands. The architecture separates low-level connection management (connection pools, shard pools for clusters, sentinel discovery) from high-level facade classes (Redis, RedisCluster, AsyncRedis, AsyncRedisCluster, QueuedRedis for pipelined/transactional usage). Key entry points include the main sync header `redis++.h`, async header `async_redis++.h`, and coroutine header `co_redis++.h`. Data flows involve constructing Redis commands via `CmdArgs` and `cmd_formatter.h`, sending them through `Connection` objects (optionally pooled), and parsing replies with `reply.h`. The library depends on hiredis for raw Redis protocol, libuv for async I/O, and optionally Boost or OpenSSL for advanced features. It includes a comprehensive test suite covering all commands, multi-threading, cluster, sentinel, and distributed locking patterns (Redlock).
FireRedASR is an open-source industrial-grade automatic speech recognition (ASR) system supporting Mandarin, Chinese dialects, and English. It provides two model variants: FireRedASR-AED (Attention-based Encoder-Decoder with Conformer encoder and Transformer decoder) and FireRedASR-LLM (Encoder-Adapter-LLM framework leveraging Qwen2-7B). The codebase includes a CLI tool (`speech2text.py`), a Python API (`FireRedAsr`), feature extraction (fbank with CMVN), tokenization (mixed Chinese/English SentencePiece), and utilities for WER computation. It also includes a complete Triton Inference Server deployment with TensorRT-LLM acceleration for the AED model, with Docker support and benchmarking scripts. The architecture is modular: data preprocessing, model definitions, tokenizers, and inference orchestration are cleanly separated, though the model components are tightly coupled to the specific architectures. The repository is actively maintained with recent commits and demonstrates strong engineering craftsmanship in both the core ASR implementation and the production-grade deployment stack.
This repository is a comprehensive, hands-on tutorial series for learning wgpu, the Rust implementation of the WebGPU graphics API. It systematically builds up from rendering a window through advanced topics such as compute shaders, instancing, lighting (Blinn-Phong, normal mapping), HDR rendering with tonemapping, mipmap generation, and post-processing. Each tutorial is a standalone, runnable Rust crate under `code/beginner/` or `code/intermediate/`, while `code/showcase/` contains more elaborate examples including a Pong game, text rendering, mouse picking, and procedural terrain generation. The code is structured as a Cargo workspace, with a shared `framework` crate that provides reusable components like a `RenderPipelineBuilder`, camera/uniform bindings, and async resource loading that works both natively and via WebAssembly. The accompanying documentation site is built with VuePress and includes live embedded WebAssembly demos, migration guides for wgpu version updates, and detailed explanations of shader code and GPU concepts. While the tutorials intentionally duplicate boilerplate for pedagogical clarity, the repository demonstrates solid engineering practices in GPU programming, cross-platform support (native + WASM), and progressive complexity. Some `wip-terrain` content is unfinished, and a few showcase demos are marked as broken, but the core tutorials are well-maintained and current with wgpu 30.0.
This repository is a documentation generation system used by Le Wagon to produce platform-specific setup guides for their Data Science & AI Bootcamp. It is a Ruby CLI tool that reads YAML build specs, combines reusable markdown partials (both local and remote), and outputs fully-formed setup instructions for macOS, Windows, Linux, and virtual machines in English and Spanish. The core architecture uses a Liquid templating engine, a partial cache for performance, and a clear separation between build definitions and localized output. The CI pipeline automatically rebuilds guides on push and commits any changes. While the repo does not contain any application or research code, its Ruby build system – particularly the remote partial fetcher with locale fallback and the centralized constants configuration – demonstrates clean, reusable patterns for any project that needs to generate multilanguage, platform-targeted documentation from composable snippets.
This repository is a comprehensive Unity Editor extension framework that enhances the inspector, hierarchy, project, toolbar, and scene view windows through custom attributes, drawers, and serialization types. It provides a modular, settings-driven system where features like custom property drawers (regular and toolbox), conditional visibility, decorators, reorderable lists, inline editors, and reference pickers are toggled via a ScriptableObject asset. The architecture is IMGUI-based and overwrites the default custom editor for all UnityEngine.Objects, meaning it cannot easily coexist with other inspector plugins. The codebase demonstrates high craftsmanship in its drawer hierarchy, value extraction and comparison helpers, caching mechanisms, and scoped state management patterns. However, it relies heavily on reflection to access Unity internal APIs and uses numerous version-specific conditionals, which introduces maintenance risk with Unity updates. The included examples and tests provide a solid demonstration of the framework's capabilities.
This repository is the official development repository for samtools, a suite of command-line tools for interacting with high-throughput sequencing data in the SAM, BAM, and CRAM formats. It is a monolithic C application tightly integrated with the htslib library for file I/O, compression, and indexing. The primary entry point is `bamtk.c`, which dispatches to dozens of subcommands including `view`, `sort`, `index`, `mpileup`, `markdup`, `stats`, `consensus`, `merge`, `split`, `fastq`, and `tview`. The codebase handles format conversion, sorting, indexing, duplicate marking, variant calling support, consensus generation, and quality control statistics, making it a critical dependency in virtually every bioinformatics pipeline dealing with aligned reads. The architecture is a classic monolithic C tool with subcommand dispatch. Data flows through htslib-based iterators, with records being filtered, transformed, and aggregated. The codebase contains several well-crafted, reusable C components that demonstrate non-obvious skill, such as a macro-based generic splay tree sort (`splaysort.h`), an LZ4-compressed ring-buffer temp file API (`tmp_file.c`), a hash-based BED interval index (`bedidx.c`), and an order-agnostic checksum module for pipeline validation (`bam_checksum.c`). These components are isolated, self-contained, and could be extracted for use in other projects with minimal modification. The project is actively maintained with frequent commits, extensive CI across Linux, macOS, Windows, and various BSDs, and active issue triage. However, the codebase carries significant technical debt. It relies on an autotools build system, contains vendored LZ4 code, includes legacy subcommands (`rmdup`, `targetcut`, `phase`), and has several monolithic source files (e.g., `stats.c` at ~6000 lines). Testing practices include directly `#include`-ing production `.c` files, which couples tests to implementation details. The technical drift is rated as medium due to these accumulated legacy patterns, though the core functionality is kept well-aligned with the latest htslib releases.