Total Pageviews

Tuesday, 30 June 2026

winpodx, Embed Windows Apps into Linux Desktop.

 Tools to Embed Windows Apps into Linux Desktop.This is an open-source tool that runs Windows apps on Linux without entering the full Windows desktop. It runs a Windows system in a container in the background and uses FreeRDP to turn each Windows app into an independent native Linux window, supporting pinning to the taskbar, Alt-Tab switching, file associations, and USB devices.

 ------------------------------

Windows pod system for Linux

 
 
WinPodX

Click an app. Word opens. That's it.

Native Linux windows for every Windows app — real icons, real WM_CLASS,
pin-to-taskbar. FreeRDP RemoteApp + dockur/windows. Zero config.

# Latest stable release (default)
curl -fsSL https://raw.githubusercontent.com/kernalix7/winpodx/main/install.sh | bash

# Latest main HEAD (development; may be unstable)
curl -fsSL https://raw.githubusercontent.com/kernalix7/winpodx/main/install.sh | bash -s -- --main

# Uninstall (keeps Windows VM data; pass --purge to wipe everything)
curl -fsSL https://raw.githubusercontent.com/kernalix7/winpodx/main/uninstall.sh | bash -s -- --confirm
WinPodX in action — Windows apps as native Linux windows on KDE

Windows About / Task Manager / PowerShell each in their own Linux window, alongside the WinPodX Dashboard (live Pod / RAM / CPU gauges, workspace tiles).

Beta Latest

license python tests CI stars downloads

Works on

openSUSE Fedora Fedora Atomic Desktops Debian Ubuntu RHEL family Arch NixOS AppImage

English  ·  한국어  ·  Install  ·  Usage  ·  Features  ·  Architecture  ·  Comparison


Status: Beta

WinPodX is in active development (v0.8.0). v0.7.0 introduced the bare-metal disguise (#246, opt-in / off by default): with pod.disguise_level balanced | max the Windows guest reads like a physical machine to VM-detection software (Nvidia GPU-passthrough "code 43", launch-gate VM checks, VM-hostile installers) — verified against al-khaser 0.82 — and the default guest username became WPX-User. v0.7.1 is a UX + integration release: discovered Windows apps now register automatic file associations so they appear in your file manager's "Open with" menu (#545, on by default, only added — never set as the default handler); the GUI gains app management — reset-to-detected, a custom-icon picker, multi-select bulk hide/remove, and a restore list for deleted apps (#530); a quick app launcher (winpodx launch, #561) gives a Start-menu-style picker bindable to a DE hotkey; winpodx gui no longer blocks the terminal (#549); winpodx doctor warns on an old FreeRDP with broken RemoteApp windows (#546); and install.sh --main is now honoured on Atomic Fedora (#548). v0.7.2 is a bug-fix release: it fixes a GUI crash on Refresh Apps (#567) and the tray Terminate Session / USB Devices submenus (#573) on KDE/Plasma, discovers apps with Chinese/Japanese/Korean names (#553), keeps the container across pod stop (no more recreate-on-update), and gives a clear error when Windows credentials are missing (#569). v0.7.3 adds reverse-open of files on the Windows VM itself — not just your shared Home, the guest C: is shared over SMB and mounted with kio-fuse so a host app opens the real guest file and edits save back (#616, KDE) — an opt-in idle auto-stop that frees the VM's RAM (#622), and a +multitouch flag for touchscreen / stylus / pen passthrough (#623); it also fixes winpodx app refresh timing out on a slow guest (#619), the Dashboard RAM / Disk gauges sticking on "n/a" (#634), and removes the USB drive-letter auto-mapper that was destabilizing installs (#613, #638). v0.7.4 lets you choose where the Windows VM lives (install.sh --storage-dir, #646) and install from a local Windows ISO to skip the download (--win-iso, #647), defaults a 24 GB+ host to 8 GB VM RAM (#630); plus fixes — opening a second document in an already-running app, Open with on stripped-PATH desktops like Deepin, a clear error on a missing RDP password (#569), the GUI Logs buttons honouring the Docker backend, the .deb pulling in podman-compose (#644), and the maintenance dialog size (#550). v0.8.0 makes app discovery Start-Menu-only by default — only the apps your Windows Start Menu actually shows, grouped into nested folder sub-groups, with a desktop.full_app_scan opt-in for the old scan-everything behaviour (#581); passes your [pod] keyboard to FreeRDP as the session layout (#660); stages --win-iso before compose-up so dockur installs from it instead of downloading (#647); self-heals the reverse-open listener; bumps bundled rdprrap to 0.3.0; and fixes several GUI crashes — the Refresh Apps SIGSEGV, an off-thread display-scale SIGABRT, the Debloat task dialog not auto-closing (#550), and a layout-recursion SIGSEGV with long / CJK app names (#553). The AppImage is Thin (~110 MB) — only FreeRDP + Python + Qt + winpodx — and uses the host's podman / docker. The CLI surface settled in 0.6.0 stands: winpodx guest (guest-side ops), winpodx install (install / disk ops), and winpodx doctor (diagnostics with --json / --quick / --fix); the post-create chain is the single winpodx provision. First install still takes ~5–10 minutes (Windows VM ISO download + Sysprep + OEM apply); winpodx pod wait-ready --logs shows live progress. Please file issues at https://github.com/kernalix7/winpodx/issues if something breaks.

No full-screen RDP. Each Windows app becomes its own Linux window with its real icon — pinnable, alt-tabbable, file-associated, both directions. Drop into a full Windows desktop only when you actually want one (winpodx app run desktop).

WinPodX runs a Windows container (via dockur/windows) in the background and presents Windows apps as native Linux applications through FreeRDP RemoteApp, while a bearer-authed HTTP agent inside the guest handles the host→guest command channel without flashing a PowerShell window. The reverse direction — Linux apps surfaced in the Windows "Open with…" menu — is handled by a host-side listener that consumes JSON requests written by per-slug Rust shims inside the guest. Near-zero external Python dependencies (stdlib only on Python 3.11+; one pure-Python tomli fallback on 3.9/3.10).

Minimum requirements

Before installing, make sure your machine actually supports virtualisation. WinPodX runs Windows in a KVM-backed container; without these three, the install will run to completion but Windows will never boot.

Requirement How to check Fix
Intel VT-x or AMD-V enabled in BIOS / UEFI lscpu | grep -i virtualization shows VT-x or AMD-V Reboot → firmware setup → enable "Intel Virtualization Technology" / "SVM Mode" / "VT-x". OFF by default on many laptops.
kvm kernel module loaded lsmod | grep kvm lists kvm_intel or kvm_amd sudo modprobe kvm_intel (Intel) or sudo modprobe kvm_amd (AMD). Auto-loads on next boot once BIOS allows it.
Your user is in the kvm group id -nG | tr ' ' '\n' | grep kvm returns kvm sudo usermod -aG kvm $USER, then log out + back in.

Hardware: x86_64 or aarch64 CPU with virtualisation extensions, 8 GB+ RAM (12 GB+ recommended), ~30 GB free disk for the Windows image. install.sh aborts with the same diagnostic if /dev/kvm is missing after the package install step — most "install ran fine but Windows never boots" bug reports trace back to one of the rows above.

Quick install

One-liner (any supported Linux distro):

curl -fsSL https://raw.githubusercontent.com/kernalix7/winpodx/main/install.sh | bash

Or via a native package manager:

# openSUSE Tumbleweed / Leap / Slowroll
sudo zypper addrepo https://download.opensuse.org/repositories/home:/Kernalix7/openSUSE_Tumbleweed/home:Kernalix7.repo
sudo zypper install winpodx

# Fedora 42 / 43 / 44 (dnf5 — Fedora 41+)
sudo dnf config-manager addrepo --from-repofile=https://download.opensuse.org/repositories/home:/Kernalix7/Fedora_43/home:Kernalix7.repo
sudo dnf install winpodx

# Debian / Ubuntu — grab the matching .deb from the latest release
sudo apt install ./winpodx_<version>_all_debian13.deb

# AlmaLinux / Rocky / RHEL 9 / 10 — grab the matching .rpm
sudo dnf install ./winpodx-<version>-0.noarch.el10.rpm

# Arch
yay -S winpodx

# Nix
nix run github:kernalix7/winpodx

# AppImage (distro-agnostic, single file)
# Download winpodx-<version>-x86_64.AppImage from the latest GitHub release
chmod +x winpodx-*-x86_64.AppImage
./winpodx-*-x86_64.AppImage setup

After a package-manager / AppImage install: run winpodx setup once to generate ~/.config/winpodx/winpodx.toml + compose.yaml. The curl one-liner does this for you (and waits ~5–10 min for the Windows first boot); package installs ship the binary only so apt install / dnf install / yay -S / first AppImage launch don't trigger a 10-minute Windows ISO download out of the blue. After setup, just launching an app (winpodx app run desktop) auto-provisions the pod the first time.

The Thin AppImage (0.6.0) bundles Python + Qt + winpodx + FreeRDP only — the container runtime lives on the host (podman ≥ 4 recommended, docker also supported) so the AppImage no longer fights a host stack you already have (#357, #363). Pre-0.6.0 fat AppImages bundled the whole podman stack and shadowed the host's. Host-side requirements left: a container runtime via your package manager, /dev/kvm, kvm group membership, and /etc/subuid / /etc/subgid for rootless Podman. winpodx setup-host fixes the kvm / subuid bits via a single pkexec prompt; winpodx doctor surfaces anything still missing.

See docs/INSTALL.md for offline / air-gapped builds, source installs, version pinning, and uninstall.

First-time setup

If you used the curl install.sh one-liner, setup already ran and the Windows VM is booting -- skip to Launch. For every other install path (package managers, AppImage, source, pip) run setup once before the first app launch:

# Auto setup -- host-detected defaults, no prompts
winpodx setup

# Interactive wizard -- pick backend, cores, RAM, edition, language, timezone, debloat preset
winpodx setup --customize

Setup writes ~/.config/winpodx/winpodx.toml + compose.yaml, registers the GUI launcher, and confirms the host has FreeRDP + Podman / Docker + KVM. If any of those are missing, the output ends with a per-distro install command (e.g. sudo apt install xfreerdp3 podman podman-compose on Debian / Ubuntu, sudo dnf install ... on Fedora) -- run it and re-run winpodx setup.

The first app launch then provisions the pod, pulls the dockur image, runs the Windows ISO download + Sysprep + OEM apply, and reaches a usable RDP session in ~5-10 min. winpodx pod wait-ready --logs tails container progress live so you can watch each phase:

winpodx app run desktop          # First launch -- ~5-10 min, subsequent launches near-instant
winpodx pod wait-ready --logs    # Optional: watch first-boot progress live

Run winpodx doctor any time afterwards to re-check host state and surface the next fix command if something drifts:

winpodx doctor                   # Read-only -- prints what would need fixing
winpodx guest apply-fixes        # Re-applies guest-side runtime fixes (RDP timeouts, NIC power-save, etc.)

Launch

winpodx app run word              # Launch Word
winpodx app run word ~/doc.docx   # Open a file
winpodx app run desktop           # Full Windows desktop
winpodx launch                    # Quick app launcher (Start-menu style picker)

Or just click an app icon in your application menu. winpodx launch opens a searchable picker of your Windows apps — bind it to a desktop-environment custom shortcut (KDE: System Settings → Shortcuts → Custom; GNOME: Settings → Keyboard → Custom Shortcuts) for a system-wide hotkey. See docs/USAGE.md for the full CLI, the Qt6 GUI, health checks, and configuration.

Key features

Bare-metal disguise (VM-detection avoidance) — new in 0.7.0 · opt-in, off by default

  • Makes the Windows guest read as a physical machine to software that refuses to run under a detected hypervisor — Nvidia GPU-passthrough "code 43", launch-gate VM checks, VM-hostile installers
  • pod.disguise_level balanced | max: balanced hides the CPUID hypervisor bit + KVM signature and mirrors the host's real SMBIOS/DMI; max ("Hardened") adds a locally-built patched-QEMU image (winpodx disguise build-image) that rewrites the ACPI / disk / sensor / USB fingerprints and drops the virtio + Red-Hat PCI tells (keeps USB3)
  • Host-derived strings stay in the local image only (never committed to git); serial / UUID / asset-tag are never read
  • al-khaser 0.82-verified — enable with winpodx config set pod.disguise_level max or the GUI Settings "Bare-metal" selector
  • Details →

Reverse-open

  • Linux apps appear in the Windows guest's right-click "Open with…" menu by default
  • Correct per-app icons in both the short menu and the long "Choose another app" dialog
  • Selecting one round-trips the file open to host xdg-open
  • Auto-discovers host-side Linux apps + their MIME associations from freedesktop standards
  • Manage via winpodx host-open CLI or the GUI Settings panel
  • Details →

Seamless app windows

  • RemoteApp (RAIL) renders each Windows app as a native Linux window — no full desktop
  • Per-app taskbar icons via WM_CLASS matching (/wm-class:<stem> + StartupWMClass)
  • Bidirectional file associations: double-click .docx in your file manager → Word opens
  • Multi-session RDP: bundled rdprrap auto-enables up to 10 independent sessions
  • Multi-monitor RAIL (0.6.0): a remote-app window keeps working input when dragged onto a second monitor — on by default (cfg.rdp.multimon, default span)
  • RAIL prerequisites set automatically during unattended install

Zero-config launch

  • First app click auto-provisions everything: config, container, desktop entries
  • Auto-discovery on first boot scans the running Windows guest and registers every installed app with its real icon (Registry App Paths, Start Menu, UWP/MSIX, Chocolatey, Scoop)
  • Manual rescan any time via winpodx app refresh or the GUI Refresh button
  • Multi-backend: Podman (default), Docker, manual RDP (the libvirt backend was dropped in 0.6.0 — stay on ≤0.5.x or use the manual backend for your own libvirt domain)

Peripherals & sharing

  • Clipboard: bidirectional copy-paste (text + images) — on by default
  • Sound: RDP audio streaming (/sound:sys:alsa) — on by default
  • Printer: Linux printers shared to Windows — on by default
  • Home directory: shared as \\tsclient\home
  • USB drives: auto-mapped to drive letters (E:, F:, …) via FileSystemWatcher; subfolders work for drives plugged in after session start; the USB desktop shortcut (\\tsclient\media) always resolves, opening an empty folder when nothing is mounted instead of erroring
  • Host USB / PCI device passthrough (0.6.0): pass real host devices into the Windows guest — winpodx device list / attach <id> / detach <id>, a GUI "Devices" tab (two-column host↔guest mover), and a system-tray USB switcher. USB hot-plugs live (cfg.pod.usb_live, default on); PCI is boot-added and needs a guest restart plus a --force / dialog confirmation

Automation & security

  • Auto suspend / resume: container pauses when idle, resumes on next launch
  • Pod auto-start on login (v0.5.9, opt-in): winpodx autostart on installs a tray autostart entry so the pod starts/resumes at login — off by default (autostart off|status, or a GUI Settings checkbox)
  • UNRESPONSIVE → recover (v0.5.5): stalled RDP guest is detected on RUNNING → UNRESPONSIVE and self-healed via in-guest TermService cycle, no pod restart needed
  • Host-adaptive Windows-on-KVM tuning profile (v0.5.5): +invtsc, platform_tick and more, gated by host capability — tuning_profile = auto|safe|off
  • Password auto-rotation: 20-char cryptographic password, 7-day cycle with atomic rollback
  • Smart DPI scaling: auto-detects from GNOME, KDE, Sway, Hyprland, Cinnamon, xrdb
  • Windows debloat: telemetry, ads, Cortana, search indexing disabled by default
  • FreeRDP extra_flags allowlist (regex-validated) as the user-input safety boundary
  • Time sync: force Windows clock resync after host sleep/wake

Operations & resilience

  • Multilingual UI (v0.5.9): tray / GUI / CLI fully translated to 7 languages (en / ko / zh / ja / de / fr / it), auto-detected from $LANG — override with winpodx language <code> or GUI Settings → "WinPodX UI language"
  • Windows disk auto-grow (v0.5.9): C: grows itself when it fills past a threshold while idle, bounded by host free space — or grow on demand (winpodx install grow-disk [SIZE], winpodx install disk-usage, GUI Tools → Grow Disk)
  • Guest sync (v0.5.9): push updated agent / urlacl / rdprrap / fixes into a running guest after a host upgrade — automatic once per pod start, or winpodx guest sync [--force]
  • Offline / air-gapped install (--source + --image-tar)
  • One-line uninstall (keeps Windows VM data unless --purge)
  • Health checks via winpodx doctor (deps / pod / RDP / agent / disk / round-trip / password age; --json for machine-readable, --quick for cheap subset, --fix for idempotent auto-remediation of common findings)
  • Redesigned Qt6 GUI (0.6.0): a left Start-menu-style navigation sidebar + a new Dashboard home with live Pod / RAM / CPU ring gauges, disk usage, an auto-recovery status card, pinned/recent workspace tiles, and a reverse-open toggle; the app launcher is now the "All apps" page, alongside Devices / Settings / Tools / Terminal / Info — plus a lighter system tray. In-house SVG icon set, responsive reflow, and a hero search that doubles as a command bar
  • Stdlib-leaning Python (no pip-deps on 3.11+; one tomli fallback on 3.9 / 3.10)

See docs/FEATURES.md for deep dives, including multi-session RDP internals, app profile schema, and the reverse-open architecture.

Documentation

Document What's inside
INSTALL.md Every install path — one-liner, package managers, AppImage, offline, Nix, source
USAGE.md CLI reference, Qt6 GUI tour, health checks, configuration file
FEATURES.md Reverse-open, multi-session RDP, peripherals, app profiles, auto-discovery
ARCHITECTURE.md How it works (diagram), tech stack, source tree, data flows
COMPARISON.md WinPodX vs winapps / LinOffice / winboat, and WinPodX vs Wine
CHANGELOG.md Full version history
CONTRIBUTING.md Development setup and workflow
SECURITY.md Security disclosure process

Supported distros

Distro Package manager Status
openSUSE Tumbleweed / Leap 15.6 / Leap 16.0 / Slowroll zypper Tested
Fedora 42 / 43 / 44 / Rawhide dnf Supported
Fedora Silverblue / Kinoite / Sericea / Bluefin / Bazzite (42 / 43 / 44) rpm-ostree (OBS, --apply-live) Supported
Debian 12 / 13, Ubuntu 24.04 / 25.04 / 25.10 / 26.04 apt Supported
AlmaLinux / Rocky / RHEL 9 / 10 dnf Supported
Arch / Manjaro pacman + yay -S winpodx Supported
NixOS (and Nix on any distro) nix flake Supported

Each tag push (v*.*.*) publishes to all channels automatically — see packaging/ for maintainer details.

Testing

# From repo root (no install needed)
export PYTHONPATH="$PWD/src"
python3 -m pytest tests/    # 1800+ tests
ruff check src/ tests/      # Lint
ruff format --check src/ tests/
from  https://github.com/kernalix7/winpodx

SSH 通过 443 端口连接 GitHub

 

GitHub 提供了两种协议供用户使用 Git 连接—— SSH 和 HTTPS。理论上我可以随意选择两者之一连接到我在 GitHub 上的代码仓库,无论是将云端的仓库 clone 到本地,还是将本地的修改 push 到云端。然而,出于一些奇奇怪怪的原因,我所在的办公网络环境禁止了 22 端口,而 22 端口正是 GitHub 提供 SSH 访问的端口号。尽管可以换用 HTTPS 协议,但无论如何将我电脑上的所有代码仓库的上游都从 git@github.com:... 修改成 https://github.com/... 仍然是一个繁重的体力活。

为了一劳永逸地解决这个问题,最理想的解决方式是让 Git 的 SSH 协议改用 22 以外的其他端口连接 GitHub。

SSH 连接失败

 我们在 clone GitHub 上的代码仓库时,可以看到 GitHub 提供了两种不同的链接(以我的 SpinalHDL 模版仓库为例):

 git clone https://github.com/zhutmost/spinalhdl-template.git # HTTPS
git clone git@github.com:zhutmost/spinalhdl-template.git # SSH

 其中第一种方式,即 HTTPS 协议,一般总能可以工作(只要能在浏览器里打开 GitHub),而后者依赖 SSH 的正常工作。因为我的网络环境阻断了 22 端口的连接,所以我测试 GitHub 的 SSH 连接时会出现以下报错:

 ❯ ssh -T git@github.com
kex_exchange_identification: Connection closed by remote host
Connection closed by xx.xx.xx.xx port 22

 而在理想情况下,上述命令应当输出:

 ❯ ssh -T git@github.com
Hi zhutmost! You've successfully authenticated, but GitHub does not provide shell access.

 

奇妙的冒名顶替

 仔细发掘 GitHub 的文档,可以发现 GitHub 在另一个域名(ssh.github.com)上提供了一个 443 端口的 SSH 服务。显然,防火墙一般不会阻拦 443 端口(只要能浏览 GitHub 网站就能连上),可以用下面的命令进行测试:

 ❯ ssh -T -p 443 git@ssh.github.com

 为了让Git也能通过上述端口用 SSH 访问 GitHub,我们为上述 SSH 连接方式设置一个别名。首先找到SSH的配置文件,它的路径一般是 ~/.ssh/config,如果这个文件不存在的话也可以创建一个。然后,在其中增加以下内容:

 Host github.com
  HostName ssh.github.com
  User git
  Port 443

 

其中,Host 是别名,HostName 是实际的域名地址,Port 是端口号。因为我希望当我在用 SSH 连接 github.com 时,实际访问的是 ssh.github.com,所以 HostHostName 分别设置成这两个域名(注意不要颠倒顺序)。

如此一来,ssh.github.com 就成为了 github.com 的“冒名顶替”者。当 Git 通过 SSH 协议试图访问 github.com 的时候,SSH 会发现它是 ssh.github.com 的别名,因此会用 443 端口实际连接到后者。这样,就绕开了本地网路环境对 22 端口的限制。

(我之所以使用上述方法,是因为我的网络情况比较复杂。建议公司的朋友在使用暗渡陈仓之策前,先和 IT 部门确认下是否合规。)

from  https://zhutmost.com/post/github-ssh-443

 

 

 

EmDash is a full-stack TypeScript CMS based on Astro

 

the spiritual successor to WordPress


A full-stack TypeScript CMS built on Astro and Cloudflare. EmDash takes the ideas that made WordPress dominant -- extensibility, admin UX, a plugin ecosystem -- and rebuilds them on serverless, type-safe foundations. Plugins run in sandboxed Worker isolates, solving the fundamental security problem with WordPress's plugin architecture.

Get Started

Important

EmDash depends on Dynamic Workers to run secure sandboxed plugins. Dynamic Workers are currently only available on paid accounts. Upgrade your account (starting at $5/mo) or comment out the worker_loaders block of your wrangler.jsonc configuration file to disable plugins.

npm create emdash@latest

Or deploy directly to your Cloudflare account:

Deploy to Cloudflare

EmDash runs on Cloudflare (D1 + R2 + Workers) or any Node.js server with SQLite. No PHP, no separate hosting tier -- just deploy your Astro site.

Templates

EmDash ships with three starter templates:

Blog

Blog template

A classic blog with sidebar widgets, search, and RSS.

  • Categories & tags
  • Full-text search
  • Comment-ready
  • RSS feed
  • Dark / light mode

Marketing

Marketing template

A conversion-focused landing page with pricing and contact form.

  • Hero with CTAs
  • Feature grid
  • Pricing cards
  • FAQ and contact form
  • Dark / light mode

Portfolio

Portfolio template

A visual portfolio for showcasing creative work.

  • Project grid
  • Tag filtering
  • Case study pages
  • RSS feed
  • Dark / light mode

Why EmDash?

WordPress was built for a different era. Running WordPress today means managing PHP alongside JavaScript, layering caches to get acceptable performance, and knowing that 96% of WordPress security vulnerabilities come from plugins. EmDash is what WordPress would look like if you started from scratch with today's tools.

Sandboxed plugins. WordPress plugins have full access to the database, filesystem, and user data. A single vulnerable plugin can compromise the entire site. EmDash plugins run in isolated Worker sandboxes via Dynamic Worker Loaders, each with a declared capability manifest. A plugin that requests read:content and email:send can do exactly that and nothing else.

from  https://github.com/emdash-cms/emdash

chinese-poetry-api

 

诗泉:高性能中国古诗词 API 服务

 
 

中国古诗词 API 服务

Docker Image Docker Image Size Go Report Card pre-commit License

基于 Go 语言的高性能中国古诗词 API 服务,支持 REST 和 GraphQL 接口,提供简体/繁体中文、爬虫练习场等功能。

在线版:https://poetry.palemoky.com

特性

  • 高性能: Go 语言编写,支持并发处理,性能优化(简繁转换 ~300ns/op)
  • 海量数据: 包含唐诗、宋词、元曲等近 40 万首诗词
  • 强大搜索: 支持全文搜索、标题/内容/作者分类搜索
  • 双语支持: 同一数据库同时存储简体和繁体中文,通过 ?lang= 参数切换
  • 多种接口: REST API 和 GraphQL 双接口支持
  • 限流保护: 内置 IP 限流,防止滥用
  • 容器化: Docker 镜像开箱即用,支持多架构(amd64/arm64)
  • 智能分类: 按朝代、作者、诗词类型自动分类

快速开始

使用 Docker(推荐)

docker run -d -p 1279:1279 palemoky/chinese-poetry-api:latest

完整配置参见 docker-compose.yml

使用 Makefile

make help          # 查看所有可用命令
make build         # 构建项目
make process-data  # 处理数据
make run-server    # 启动服务

克隆仓库

本项目使用 Git Submodules 管理诗词数据,推荐使用以下命令快速克隆:

# 完整克隆(包含 submodules)
git clone --recurse-submodules --depth=1 https://github.com/palemoky/chinese-poetry-api.git

如果已经克隆了仓库,可以单独更新 submodules:

git submodule update --init

API 使用

多语言支持

所有接口支持 lang 参数切换简繁体:

参数值 说明
zh-Hans 简体中文(默认)
zh-Hant 繁体中文

REST API

# 简体中文(默认)
curl "http://localhost:1279/api/v1/poems"

# 繁体中文
curl "http://localhost:1279/api/v1/poems?lang=zh-Hant"

# 搜索诗词
curl "http://localhost:1279/api/v1/poems/search?q=静夜思"

# 随机诗词
curl "http://localhost:1279/api/v1/poems/random"

# 随机诗词(带过滤)
curl "http://localhost:1279/api/v1/poems/random?author=李白"
curl "http://localhost:1279/api/v1/poems/random?type=五言绝句"
curl "http://localhost:1279/api/v1/poems/random?author=李白&type=五言绝句"
curl "http://localhost:1279/api/v1/poems/random?author=李白&type=五言绝句&dynasty=唐"
curl "http://localhost:1279/api/v1/poems/random?author=李白&dynasty=唐&type=五言绝句&type=七言绝句&type=五言律诗"

# 作者列表
curl "http://localhost:1279/api/v1/authors?page=1&page_size=20"

# 朝代列表
curl "http://localhost:1279/api/v1/dynasties"

GraphQL API

端点:http://localhost:1279/graphql

# 繁体中文查询
query {
  poems(lang: ZH_HANT, pageSize: 10) {
    edges {
      node {
        title
        content
        author {
          name
        }
      }
    }
    totalCount
  }
}

# 搜索诗词
query {
  searchPoems(query: "静夜思", searchType: TITLE) {
    edges {
      node {
        title
        author {
          name
        }
      }
    }
  }
}

# 统计信息
query {
  statistics {
    totalPoems
    totalAuthors
    poemsByDynasty {
      dynasty {
        name
      }
      count
    }
  }
}

搜索功能

类型 说明 示例
all 全文搜索(默认) ?q=月
title 标题搜索 ?q=静夜思&type=title
content 内容搜索 ?q=床前明月光&type=content
author 作者搜索 ?q=李白&type=author

数据集

本项目基于 chinese-poetry 数据集,包含:

from https://github.com/palemoky/chinese-poetry-api

分类 数量 分类 数量 分类 数量 分类 数量
五言绝句 18,895 七言绝句 85,032 五言律诗 71,400 七言律诗 69,028
乐府诗 9,315 五代词 543 宋词 21,369 元曲 10,905
诗经 305 楚辞 65 论语 20 四书五经 14
其他 96,232

from https://github.com/palemoky/chinese-poetry-api

Monday, 29 June 2026

搭建基于nextjs的静态博客程序ddm

首先fork此项目https://github.com/ddadaal/ddadaal.me ,我fork后,得到的项目地址是https://github.com/brightmann/ddm

访问 https://github.com/brightmann/ddm/tree/master/contents ,在此处新建源帖(即add file),我新建了源帖20260629-fh/index.md,内容为:

---
id: fh
date: 2026-06-29 14:07
title: 战马
lang: cn
tags:
  - misc1
  - misc2
  - misc3
---

此处写正文或html codes.

( 详见https://github.com/brightmann/ddm/blob/master/contents/20260629-fh/index.md?plain=1) 

注意:  index.md所在的目录的名称必须是20260629-fh这样的格式,不能是fh这样的格式,否则发帖会失败。

然后,访问vercel.com/new ,导入项目https://github.com/brightmann/ddm ,

  Build Command栏填入pnpm build

 Install Command栏填入pnpm install

然后点击底部的deploy按钮,等待部署完成。部署完成后,我得到网址https://ddm-sandy.vercel.app/  

项目地址:

 https://github.com/ddadaal/ddadaal.me 

 https://github.com/brightmann/ddm

演示博客: 

 https://ddm-sandy.vercel.app/  

 https://ddm-sandy.vercel.app/articles 支持分页

 https://ddm-sandy.vercel.app/articles/fh 能显示视频

( https://github.com/brightmann/ddm/new/master?filename=.github%2Fworkflows%2Fdeno.yml&workflow_template=ci%2Fdeno ,这个还没细究)


Linux上, 添加用户/ 删除用户的详细命令


    添加用户

useradd– d / home / sam - m sam

此命令创建了一个用户 sam,其中 -d 和 -m 选项用来为登录名 sam 产生一个主目录/home/sam ( /home 为默认的用户主目录所在的父目录,所有用户的目录都应该在此目录下)。-m 命令保证了在目录不存在时自动创建目录

    删除用户

userdel - r sam

此命令删除用户 sam 在系统文件中(主要是 /etc/passwd , /etc/shadow , /etc/group 等)的记录,同时删除用户的主目录。

关于四者的区别,一级比一级重要



①/bin ②/sbin ③/usr/bin ④/usr/sbin

/bin 一般存放对于用户和系统来说“必须”的程序(二进制文件)。

/sbin 一般存放用于系统管理的“必需”的程序(二进制文件),根用户使用。

/usr/bin 一般存放的只是对用户和系统来说“不是必需的”程序(二进制文件)。

/usr/sbin 一般存放用于系统管理的系统管理的不是必需的程序(二进制文件)。

关于 /lib 和 /usr/lib 两者的关系

/lib 和 /usr/lib 的区别类似 /bin , /sbin 与 /usr/bin , /usr/sbin 。

/lib 一般存放对于用户和系统来说“必须”的库


/usr/lib 一般存放的只是对用户和系统来说“不是必需的”库

了解SVG格式


什么是 SVG ?

它是一种图像文件格式,英文全称 Scalable Vector Graphics,意为可缩放的矢量图形。

它是基于 XML(Extensible Markup Language),由 World Wide Web Consortium(W3C)联盟进行开发的。严格来说应该是一种开放标准的矢量图形语言,可让你设计激动人心的、高分辨率的 Web 图形页面。用户可以直接用代码来描绘图像,可以用任何文字处理工具打开 SVG 图像,通过改变部分代码来使图像具有交互功能,并可以随时插入到 HTML 中通过浏览器来观看。

主流浏览器均支持 SVG。加载慢是 SVG 的一个缺点。但是 SVG 也有自身的优点,比如它实现了 DOM 接口(比 Canvas 方便),不需要安装第三方插件就可以在浏览器中使用(比 Flash 方便)。
为什么要用 SVG ?

相比于其他图像格式,SVG 格式的优势在于:

    SVG 可被非常多的工具读取和修改(比如记事本)

    SVG 与 JPEG 和 GIF 图像比起来,尺寸更小,且可压缩性更强。

    SVG 是可伸缩的

    SVG 图像可在任何的分辨率下被高质量地打印

    SVG 可在图像质量不下降的情况下被放大

    SVG 图像中的文本是可选的,同时也是可搜索的(很适合制作地图)

    SVG 可以与 JavaScript 技术一起运行

    SVG 是开放的标准

    SVG 文件是纯粹的 XML

SVG 与 Flash

与 Flash 相比,SVG 最大的优势是与其他标准(比如 XSL 和 DOM)相兼容。而 Flash 则是未开源的私有技术。
基础
一个简单的例子

<svg
  version="1.1"
  baseProfile="full"
  width="300"
  height="200"
  mlns="http://www.w3.org/2000/svg"
>
  <rect width="100%" height="100%" fill="red" />
  <circle cx="150" cy="100" r="80" fill="green" />
  <text x="150" y="125" font-size="60" text-anchor="middle" fill="white">
    SVG
  </text>
</svg>


该图绘制流程包括以下几步:

    从 SVG 根元素开始:
        应舍弃来自 (X)HTML 的 doctype 声明,因为基于 SVG 的 DTD 验证导致的问题比它能解决的问题更多。
        version和baseProfile属性是必不可少的,供其它类型的验证方式确定 SVG 版本。
        作为 XML 的一种方言,SVG 必须正确的绑定命名空间 (在 xmlns 属性中绑定)。
    绘制一个完全覆盖图像区域的矩形 ,把背景颜色设为红色。
    一个半径 80px 的绿色圆圈绘制在红色矩形的正中央 (向右偏移 150px,向下偏移 100px)。
    绘制文字“SVG”。文字被填充为白色, 通过设置居中的锚点把文字定位到期望的位置:在这种情况下,中心点应该对应于绿色圆圈的中点。还可以精细调整字体大小和垂直位置,确保最后的样式是美观的。

    想了解更多?请参考文末详细教程

现实中的使用

    直接嵌入 SVG 代码在网页中使用:

    <svg xmlns="http://www.w3.org/2000/svg" version="1.1">
      <circle
        cx="100"
        cy="50"
        r="40"
        stroke="black"
        stroke-width="2"
        fill="red"
      />
    </svg>

    可以像上述这样,直接将 svg 标签嵌入到 html 当中引入 svg 图片

        其他用 embed iframe object 标签引的入方法此处不作介绍,有兴趣自行搜索相关用法。

    用 a 标签链接到 SVG 文件

    <a href="circle1.svg">Click here to view SVG file</a>

    SVG 也可以作为本地的一种图片格式文件

    如,新建一个 demo.svg 文件,然后写入以下内容

    <?xml version="1.0" standalone="no"?>
    <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
    "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
    <svg xmlns="http://www.w3.org/2000/svg" version="1.1">
      <circle cx="100" cy="50" r="40" stroke="black"
      stroke-width="2" fill="red" />
    </svg>

    他在资源管理器中默认的显示图标像一个链接.

    双击这个文件即可调用浏览器来打开并渲染出该图。
    SVG 在网页中还可充当图标来使用

    SVG 在网页设计中的一种重要的用途就是充当图标

    可以作为图片用 css 直接引入并使用,如下示例

    #email {
      background: url(./img/email.svg) 12px 7px no-repeat;
      background-size: 20px 20px;
      // 在这设置图标大小,不设置就是svg默认的宽高
    }

    制作高质量的图片

    另外,由于其可无限缩放而保持原有质量的特点,SVG 图还常常用作网页的图片素材,以确保在网站被异常缩放后图片仍能保持高质量。

更多

SVG 是一个庞大的规范,想了解更多的绘画方法请访问-

https://developer.mozilla.org/zh-CN/docs/Web/SVG/Tutorial

 

package.json 文件详解

 此篇文章适合于对 JavaScript nodejs npm json 有一定了解,但不清楚 package.json 文件具体作用及其含义的读者
什么是 package.json 文件?

nodejs 的项目遵循模块化的架构,package.json 文件是用来描述项目的相关信息,便于 npm、yarn 等包管理工具对项目进行操作。简单的来理解,就是每个项目都可以被叫做“包”,package.json 则是用来描述包信息的一个文件,一般存在于项目的根目录下。
直接上个实例 :

package.json 文件本身是 json 文件,当然也遵循 json的语法.

    JSON语法参考链接 => https://www.runoob.com/json/json-syntax.html

// package.json 文件内容

{
  "name": "demo", // 包名,必须,字母小写,无空格,下划线、横线可选
  "version": "1.1.0", // 版本号,必须
  "author": "Viki", // 作者信息
  "description": "source code repo", // 包描述
  "main": "main.js", // 入口文件
  "license": "MIT", // 遵循的协议
  "scripts": {
    // 自定义脚本
    "start": "react-native run-android" // 脚本示例
    // ... 其他自定义脚本
  },
  "dependencies": {
    // 生产依赖(项目正式上线时所依赖的包)
    "react": "^16.13.1" // 表示兼容 react 的16.13.1版本
    // ... 其他生产依赖
  },
  "repository": {
    // 项目仓库信息
    "type": "git",
    "url": "git@github.com:abc/xyz.git"
  },
  "devDependencies": {
    // 开发依赖(开发和测试环境中依赖的包)
    "@babel/core": "~7.0.0"
    // ... 其他开发依赖
  }
  // ... 以上是常见的描述信息,还可在此添加其他自定义的描述信息
}

它有什么用?

它配置和描述了该如何与项目进行交互、运行。包管理器(npm、yarn等)也可以通过它来识别项目并分析出如何处理项目的依赖关系。当你执行npm instal或者yarn来安装依赖的时候,就是通过这个文件来识别。此外,如果你的项目需要发布到 npm 的 registry 上供别人使用,也需要通过这个文件来提供项目的信息。

    在 npm 5.x 及以上还会生成一个 package-lock.json 文件,它用来描述更加确切的版本信息。package.json 文件有缺陷,只能锁定大版本,也就是版本号的第一位,并不能锁定后面的小版本,每次 npm install 拉取的是该大版本下的最新的版本,为了稳定性考虑,我们几乎是不敢随意升级依赖包的,这将导致多出来很多工作量,测试/适配等,所以 package-lock.json 文件出来了,当你每次安装一个依赖的时候就锁定在你安装的这个版本。

自定义字段 

package.json 文件中的字段不是固定的。如果你要发布的话,那就只有 name 和 version 是必须的,其他可选,且可以根据需要自定义添加。需要的时候可被其他文件引用。如果不需要发布,则任何都是可选的,且建议将private字段设置为true并移除main入口,这样可以防止代码意外发布(示例在下方,加减分别代表增删)。

  {
+   "private": true,
-   "main": "index.js",
  }

其他字段参考: keywords、contributors、homepage、preferGlobal、style、bin、bugs、config、browser、engines、man、peerDependencies
脚本(scripts)字段 

这个字段约定了什么时候用npm start,npm run dev应该执行什么,或者说它告诉了程序员npm start运行的是什么命令。使用的时候可根据需要, 在此自定义。

例如:若一个项目的 package.json如下

{
  "name": "demo",
  "version": "1.0.0",
  "scripts": {
    "start": "cd app && react-native run-android"
  }
}

则在项目路径下运行npm run start或者yarn start时,等效于执行cd app进入 app 目录,然后执行react-native run-android


版本描述方式 

常见的版本描述方式有以下几种
具体的版本     比如1.2.2,遵循“大版本.次要版本.小版本”的格式规定,安装时只安装指定版本。
~ + 版本     比如~1.2.2,表示安装 1.2.x 的最新版本(不低于 1.2.2),但是不安装 1.3.x,也就是说安装时不改变大版本号和次要版本号。
^ + 版本     比如ˆ1.2.2,表示安装 1.x.x 的最新版本(不低于 1.2.2),但是不安装 2.x.x,也就是说安装时不改变大版本号。需要注意的是,如果大版本号为 0,则插入号的行为与波浪号相同,这是因为此时处于开发阶段,即使是次要版本号变动,也可能带来程序的不兼容。
latest     安装最新版本。
如何生成?

    手动写:
新建一个文本文件并修改文件名和后缀名为package.json

    自动生成:
通过npm init新建,前提是已经配置好了 npm 的环境.


想了解更多?
强烈推荐阅读 => package.json文件:

https://javascript.ruanyifeng.com/nodejs/packagejson.html

参考文章

 
  • package.json - npm

  • package.json 详解 - 拉勾

  • package.json 详解 - 掘金

  •  



    webpack4.x 基础

    本篇文章简要地讲解了 webpack 4.x 的入门知识,适合想了解、学习 webpack 的小白

    引文

    webpack说白了就是一个打包工具,可以预先配置好打包设定,并约定好适用于各种不同文件类型的loader,以及可能用到的插件 📥 等,然后其他的事情就交给webpack,它会将你项目中的所有 js 文件、样式 文件、图片或字体资源等等打包在一起。webpack让开发者的代码更易编写、维护的同时,也提高了生产效率。
    安装

        在开始之前,请确保安装了 Node.js 的较新版本

        全局安装

        即:webpack 命令已加入环境变量,全局下可用

        npm install -g webpack
        npm install -g webpack-cli


        本地安装

        即:仅在当前项目配置 webpack 的开发环境

        npm install --save-dev webpack
        npm install --save-dev webpack-cli

    配置 npm 脚本

    编辑项目根目录下的package.json文件。

        package.json 是 nodejs 项目的描述文件,详见npm 文档-https://docs.npmjs.com/files/package.json

    // package.json
    "scripts": {
      "webpack": "webpack --config webpack.config.js"
    }

    Webpack的配置

    可在项目根目录下建一个 webpack.config.js 文件作为 webpack 的配置文件,webpack在执行的时候会读取这个配置文件并将其作为打包的配置进行打包。 

    关于 Python



    Python 是一种面向对象、解释型、动态数据类型的高级程序设计脚本语言,同时也是一种功能强大而完善的通用型语言。

    它因为具有语法简单、易于学习、可读性强、功能强大(模块众多)、可扩展性强、开源免费、跨平台等优势而被很多程序员青睐。

    Python 简单的语法使得其代码量相对较少,能够让程序员专注于业务逻辑而不是纠结于编程语言语法本身。

    但是,Nothing is perfect ,Python 也是这样

    作为一门解释性语言,运行慢自然是 Python 的主要缺点之一,但目前计算机硬件的性能、计算速度在不断增强,这点往往不会带来大问题,大多数情况,用户往往感觉不到差异。

    其他的一些不足:不具备完整的语法检查、暴露源代码(解释性语言通病)、语法要求强制缩进等
    Python 用途广泛

    Web 开发

    如豆瓣、知乎、果壳网、Google、NASA、YouTube、Facebook 等都将 Python 作为主要开发语言

    服务端

    App 与的游戏后台等

    网络爬虫

    快速抓取互联网数据

    人工智能

    相较于其他编程语言,Python 适合人工智能领域,得益于其很多适合用来做人工智能的库,如 numpy、pybrain 和 matplotlib 等,但是计算密集型以及调用硬件底层接口的核心算法还是得靠 C/C++ 来实现

    数据分析

    在数据分析处理方面,Python 有很完备的生态环境。涉及到的分布式计算、数据可视化、数据库操作等,Python 中都有成熟的模块可以选择完成其功能。

    其他的用途

    自动化运维、系统编程、图形处理、数学处理、文本处理、数据库编程、网络编程、Web 编程、多媒体应用、黑客编程……

    Python2 与 Python3 的区别

    Python3 不兼容 Python2,为了尽可能兼容早期用 Python2 写的
    Python 程序,官方发布了 Python2.6 作为一个过度版本,其往后的版本完全支持 Python2 的同时兼容了部分 Python3 的语法。

        Python2.x 与 3.x 版本的区别 - https://www.runoob.com/python/python-2x-3x.html


    Githug小白指南

     前言

    Githug (不是 Github )是一个用 Ruby 编写的、用来练习 Git 的闯关小游戏。在闯关过程中,我们可以掌握 Git 的基本用法、加深理解,同时提高熟练度。

          
    闯关原则

    在闯关过程中,要时刻明白,我们闯关的目的是学习 git ,所以请不要为了闯关而闯关,而忽略了闯关过程中的收获。我们的重点在于学习 Git 。
    进行 Githug 前的准备
    安装 Ruby

    Ruby 是一种开源的动态编程语言。因为 Githug 是用 Ruby 写的,所以我们得先安装 Ruby (已安装则跳过此步)。Ruby 官网安装指引-https://www.ruby-lang.org/zh_cn/downloads/

        Windows 用户可直接下载安装程序进行安装 :下载 Ruby 安装程序-https://rubyinstaller.org/downloads/

    安装完后,打开命令行界面执行下列命令:

    ruby --version

    若输出有关 Ruby 的版本号,则代表安装成功。
    安装 Githug

    执行下列三行命令修改默认下载源:

    //删除默认需要翻墙才能用的国外下载源 gem sources --remove https://rubygems.org/
    //设置下载源为国内可以访问的下载源 gem sources --a https://gems.ruby-china.org/
    //查看是否安装成功 gem sources -l

    换源成功后执行下列命令安装 Githug

    gem install githug

    初始化 Githug

    首先打开一个你想要建立 githug 游戏目录的文件夹,然后在资源管理器(暂时简单理解为文件夹的页面)的地址栏(有 "C:\windows\" 这样类似文字的编辑框)输入 cmd 回车。系统会自动打开位于当前路径下的 cmd 控制台,在这个命令行界面输入 githug ,返回的预期结果如下:

    *********************************************************** * Githug *
    *********************************************************** No githug directory
    found, do you wish to create one? [yn]

    这个提示的意思是你已经进入到 Githug 的游戏界面了,但是它未检索到游戏目录,提示你是否要建立目录。此时,输入字母 y 并按回车确认,它会在该文件夹下创建名为 git_hug 的游戏文件夹,然后用如下命令行进入到 git_hug 路径下就可以进行闯关了。

    cd git_hug

    常用的命令:

            githug 或 githug play 检测当前关卡是否通过
            githug hint 显示当前关卡的提示
            githug reset 重置当前关卡
            githug levels 列出所有关卡

    注 · 在任意关卡退出后,再次进入 Githug ,闯关进度会保存
    闯关指引
    Level 1 init

    Name: init Level: 1 Difficulty: * A new directory, `git_hug` , has been
    created; initialize an empty repository in it.

    Level 2
    Level 3
    Level 4
    Level 5
    Level 6
    Level 7
    Level 8
    Level 9
    Level 10
    Level 11
    Level 12
    Level 13
    Level 14
    Level 15
    Level 16
    Level 17
    Level 18
    Level 19
    Level 20
    Level 21
    Level 22
    Level 23
    Level 24
    Level 25
    Level 26
    Level 27
    Level 28
    Level 29
    Level 30

    Git 学习资料

    参考文章


    一个django博客项目BlogViking666

     https://github.com/wsqy/BlogViking666

    ( https://github.com/brightmann/BlogViking)

    Node.js Static Server in Minutes

    require('http').createServer(function (request, response) {

        //
        // Serve files!
        //
        file.serve(request, response);

    }).listen(8080);

     把上面的代码保存为server.js ,然后运行node server.js ,就得到了一个静态文件服务器程序。

    from  https://stackoverflow.com/a/15830142

    -Node.js Static Server in Minutes

    npmx.dev

     https://npmx.dev

    静态博客程序:devdojo-static

     this tool Static can help convert your Node.js application into a static site suitable for deployment on GitHub Pages.  

    --------------------------------------- 

    npm install -g @devdojo/static
    static new devdojo-static-site
    (此命令会在当前目录下,生成devdojo-static-site 目录。
    cd devdojo-static-site
    12799@DESKTOP-B6LK9IO MINGW64 ~/devdojo-static-site (main)
    $ ls
    CNAME collections/ includes/ package.json public/
    README.md assets/ content/ layouts/ pages/ tailwind.config.js

    12799@DESKTOP-B6LK9IO MINGW64 ~/devdojo-static-site (main)
    $ npm install
    12799@DESKTOP-B6LK9IO MINGW64 ~/devdojo-static-site (main)
    $ ls
    CNAME assets/ includes/ package-lock.json public/
    README.md collections/ layouts/ package.json tailwind.config.js
    content/   node_modules/  pages/

    12799@DESKTOP-B6LK9IO MINGW64 ~/devdojo-static-site (main)
    $ static build
    (此命令会在当前目录下,生成_site目录。_site目录就是静态网站的根目录。static build
    就是生成/更新静态网站的根目录的命令)
    12799@DESKTOP-B6LK9IO MINGW64 ~/devdojo-static-site (main)
    $ ls
    CNAME content/ node_modules/ pages/
    README.md assets/ includes/ package-lock.json public/
    _site/ collections/ layouts/ package.json tailwind.config.js
    (生成了_site目录
    12799@DESKTOP-B6LK9IO MINGW64 ~/devdojo-static-site (main)
    $ ls _site
    assets/ favicon.ico index.html robots.txt

    12799@DESKTOP-B6LK9IO MINGW64 ~/devdojo-static-site (main)
    $
    新建源帖:
    12799@DESKTOP-B6LK9IO MINGW64 ~/devdojo-static-site (main)
    $ cd content

    12799@DESKTOP-B6LK9IO MINGW64 ~/devdojo-static-site/content (main)
    $ nano test.md
     12799@DESKTOP-B6LK9IO MINGW64 ~/devdojo-static-site/content (main)
    $ ls
    test.md

    12799@DESKTOP-B6LK9IO MINGW64 ~/devdojo-static-site/content (main)
    $ cat test.md
    ---
    title: 测试
    description: 这是一篇文章
    ---

    这是测试。。。


    12799@DESKTOP-B6LK9IO MINGW64 ~/devdojo-static-site/content (main)
    $ cd ..
    12799@DESKTOP-B6LK9IO MINGW64 ~/devdojo-static-site (main)
    $ static build
    项目地址:
    https://github.com/thedevdojo/static
    官网:
    https://static.devdojo.com/ 
    https://static.devdojo.com/docs/getting-started/
    (有问题) 
     

    Sunday, 28 June 2026

    OneBot的主页onebot.dev的源代码


    from  https://github.com/botuniverse/homepage


    ChatDev

    ChatDev 2.0: Dev All through LLM-powered Multi-Agent Collaboration

     

    A Zero-Code Multi-Agent Platform for Developing Everything

    English | 简体中文

    【📚 Developers | 👥 Contributors|⭐️ ChatDev 1.0 (Legacy)

    📖 Overview

    ChatDev has evolved from a specialized software development multi-agent system into a comprehensive multi-agent orchestration platform.

    • ChatDev 2.0 (DevAll) is a Zero-Code Multi-Agent Platform for "Developing Everything". It empowers users to rapidly build and execute customized multi-agent systems through simple configuration. No coding is required—users can define agents, workflows, and tasks to orchestrate complex scenarios such as data visualization, 3D generation, and deep research.
    • ChatDev 1.0 (Legacy) operates as a Virtual Software Company. It utilizes various intelligent agents (e.g., CEO, CTO, Programmer) participating in specialized functional seminars to automate the entire software development life cycle—including designing, coding, testing, and documenting. It serves as the foundational paradigm for communicative agent collaboration.

    🎉 News

    Jan 07, 2026: 🚀 We are excited to announce the official release of ChatDev 2.0 (DevAll)! This version introduces a zero-code multi-agent orchestration platform. The classic ChatDev (v1.x) has been moved to the chatdev1.0 branch for maintenance. More details about ChatDev 2.0 can be found on our official post.

    Old News

    🚀 Quick Start

    📋 Prerequisites

    • OS: macOS / Linux / WSL / Windows
    • Python: 3.12+
    • Node.js: 18+
    • Package Manager: uv

    📦 Installation

    1. Backend Dependencies (Python managed by uv):

      uv sync
    2. Frontend Dependencies (Vite + Vue 3):

      cd frontend && npm install

    🔑 Configuration

    • Environment Variables:
      cp .env.example .env
    • Model Keys: Set API_KEY and BASE_URL in .env for your LLM provider.
    • YAML placeholders: Use ${VAR}(e.g., ${API_KEY})in configuration files to reference these variables.

    ⚡️ Run the Application

    Using Makefile (Recommended)

    Start both Backend and Frontent:

    make dev

    Then access the Web Console at http://localhost:5173.

    Manual Commands

    1. Start Backend:

      # Run from the project root
      uv run python server_main.py --port 6400 --reload

      --reload watches the server's Python source folders only; agent-generated files under WareHouse/ no longer trigger restarts. Pass --reload-dir or --reload-exclude (repeatable) to customise.

    2. Start Frontend:

      cd frontend
      VITE_API_BASE_URL=http://localhost:6400 npm run dev

      Then access the Web Console at http://localhost:5173.

      💡 Tip: If the frontend fails to connect to the backend, the default port 6400 may already be occupied. Please switch both services to an available port, for example:

      • Backend: start with --port 6401
      • Frontend: set VITE_API_BASE_URL=http://localhost:6401

    Utility Commands

    • Help command:

      make help
    • Sync YAML workflows to frontend:

      make sync

      Uploads all workflow files from yaml_instance/ to the database.

    • Validate all YAML workflows:

      make validate-yamls

      Checks all YAML files for syntax and schema errors.

    🦞 Run with OpenClaw

    OpenClaw can integrate with ChatDev by invoking existing agent teams or dynamically creating new agent teams within ChatDev. To get started:

    1. Start the ChatDev 2.0 backend.

    2. Install the required skills for your OpenClaw instance:

      clawdhub install chatdev
    3. Ask your OpenClaw to create a ChatDev workflow. For example:

    • Automated information collection and content publishing

      Create a ChatDev workflow to automatically collect trending information, generate a Xiaohongshu post, and publish it.
      
    • Multi-agent geopolitical simulation

      Create a ChatDev workflow with multiple agents to simulate possible future developments of the Middle East situation.
      

    🐳 Run with Docker

    Alternatively, you can run the entire application using Docker Compose. This method simplifies dependency management and provides a consistent environment.

    1. Prerequisites:

      • Docker and Docker Compose installed.
      • Ensure you have a .env file in the project root for your API keys.
    2. Build and Run:

      # From the project root
      docker compose up --build
    3. Access:

      • Backend: http://localhost:6400
      • Frontend: http://localhost:5173

    The services will automatically restart if they crash, and local file changes will be reflected inside the containers for live development.


    💡 How to Use

    🖥️ Web Console

    The DevAll interface provides a seamless experience for both construction and execution

    • Tutorial: Comprehensive step-by-step guides and documentation integrated directly into the platform to help you get started quickly.

    • Workflow: A visual canvas to design your multi-agent systems. Configure node parameters, define context flows, and orchestrate complex agent interactions with drag-and-drop ease.

    • Launch: Initiate workflows, monitor real-time logs, inspect intermediate artifacts, and provide human-in-the-loop feedback.

    🧰 Python SDK

    For automation and batch processing, use our lightweight Python SDK to execute workflows programmatically and retrieve results directly.

    from runtime.sdk import run_workflow
    
    # Execute a workflow and get the final node message
    result = run_workflow(
        yaml_file="yaml_instance/demo.yaml",
        task_prompt="Summarize the attached document in one sentence.",
        attachments=["/path/to/document.pdf"],
        variables={"API_KEY": "sk-xxxx"} # Override .env variables if needed
    )
    
    if result.final_message:
        print(f"Output: {result.final_message.text_content()}")

    We have released the ChatDev Python SDK (PyPI package chatdev), so you can also run YAML workflow and multi-agent tasks directly in Python. For installation and version details, see PyPI: chatdev 0.1.0.


    ⚙️ For Developers

    For secondary development and extensions, please proceed with this section.

    Extend DevAll with new nodes, providers, and tools. The project is organized into a modular structure:

    • Core Systems: server/ hosts the FastAPI backend, while runtime/ manages agent abstraction and tool execution.
    • Orchestration: workflow/ handles the multi-agent logic, driven by configurations in entity/.
    • Frontend: frontend/ contains the Vue 3 Web Console.
    • Extensibility: functions/ is the place for custom Python tools.

    Relevant reference documentation:


    🌟 Featured Workflows

    We provide robust, out-of-the-box templates for common scenarios. All runnable workflow configs are located in yaml_instance/.

    • Demos: Files named demo_*.yaml showcase specific features or modules.
    • Implementations: Files named directly (e.g., ChatDev_v1.yaml) are full in-house or recreated workflows. As follows:

    📋 Workflow Collection

    Category Workflow Case
    📈 Data Visualization data_visualization_basic.yaml
    data_visualization_enhanced.yaml

    Prompt: "Create 4–6 high-quality PNG charts for my large real-estate transactions dataset."
    🛠️ 3D Generation
    (Requires Blender & blender-mcp)
    blender_3d_builder_simple.yaml
    blender_3d_builder_hub.yaml
    blender_scientific_illustration.yaml

    Prompt: "Please build a Christmas tree."
    🎮 Game Dev GameDev_v1.yaml
    ChatDev_v1.yaml

    Prompt: "Please help me design and develop a Tank Battle game."
    📚 Deep Research deep_research_v1.yaml
    Prompt: "Research about recent advances in the field of LLM-based agent RL"
    🎓 Teach Video teach_video.yaml (Please run command uv add manim before running this workflow)
    Prompt: "讲一下什么是凸优化"

    💡 Usage Guide

    For those implementations, you can use the Launch tab to execute them.

    1. Select: Choose a workflow in the Launch tab.
    2. Upload: Upload necessary files (e.g., .csv for data analysis) if required.
    3. Prompt: Enter your request (e.g., "Visualize the sales trends" or "Design a snake game").

    from  https://github.com/OpenBMB/ChatDev