Reclaim unused disk space with a single command:
Compress-DistroNexusInstance -Name "Ubuntu-24.04"
Use -WhatIf for a dry-run estimate before committing. The cmdlet runs fstrim inside the instance, then invokes Optimize-VHD (Hyper-V) or diskpart as a fallback.
Manage Docker Desktop's WSL backend integration directly from PowerShell:
Get-DistroNexusDockerIntegration
Enable-DistroNexusDockerIntegration -Name "Ubuntu-24.04"
Disable-DistroNexusDockerIntegration -Name "Ubuntu-24.04"
Schedule automated backups via Windows Task Scheduler:
New-DistroNexusBackupSchedule -Name "Ubuntu-24.04" -Frequency "Daily" -RetentionCount 7
Invoke-DistroNexusBackup -Name "Ubuntu-24.04"
Organise instances with tags:
Set-DistroNexusInstanceTag -Name "Ubuntu-24.04" -Tags "dev", "python"
Get-DistroNexusInstanceTag -Name "Ubuntu-24.04"
See what's listening inside your WSL instances at a glance:
Get-DistroNexusPortMapping -Name "Ubuntu-24.04"
.tar archives..wslconfig editor (E-02): read and write WSL global settings with safety guards.DistroNexusErrorCode enum across all exceptions.Get v2.2.0 from the GitHub Releases page.
See the full v2.2.0 Release Notes for a complete change breakdown.
]]>The client UI now supports advanced template options beyond single-select dropdowns. Templates can now define MultiSelect (rendered as CheckBoxes) and Text (rendered as TextBoxes) options. Built-in templates like database-local-stack and infra-cli-toolbox now use MultiSelect for component selection, while dotnet-dev and go-dev use Text for specific version inputs.
We fixed a bug where the C# client and PowerShell backend used different default paths for downloaded packages. Both now default to %APPDATA%\DistroNexus\packages. The C# client now strictly relies on the PowerShell module to evaluate the IsCached state, preventing UI desynchronization.
We've introduced a new PowerShell cmdlet, New-DistroNexusReleaseEvidenceBundle, which automatically gathers test results, lint reports, and regression diffs into a standardized JSON artifact. This ensures that all future releases have deterministic, auditable artifacts.
To maintain the quality of our built-in templates, we've added Test-DistroNexusTemplateMetadata. This linter validates templates.json against a strict schema, outputting detailed JSON reports that are now integrated into the release evidence bundle.
Invoke-DistroNexusTemplateAutomation now generates historical regression diffs, allowing developers to track changes in template execution behavior over time. We've also hardened the resolution and ordering of regression baselines to prevent false positives during automated testing.
We've reorganized our project tracking files chronologically to improve auditability and historical context. Additionally, we've formalized the release sign-off process with new handoff templates and reference indexes.
You can download the latest version from our GitHub Releases page.
For a complete list of changes, please refer to the CHANGELOG.md.
Thank you for using DistroNexus!
]]>b8e988a fix(powershell): normalize package cache path and filename resolution50ea375 feat(download): add byte-level progress, speed metrics, and tests75b087f feat(ui): improve download display and same-file package grouping5e41c1b test(ui-automation): add package manager download flow coverage5595eff docs(specs): add template-manager wizard improvement requirements0c427d1 feat(wizard): support template-first startup and options step5ee1078 fix(core): harden template execution and package install flows8a02ca4 fix(ui): correct template apply log levels and toggle styling2563edd test(ui): add screenshot regression verification baselines193ae8a chore(docs): sync planning records and skill template07fe349 docs(specs): add quality remediation requirements and checklistsa5648dc feat(ci): align test scopes and add wsl validation laned2388a7 docs(remediation): sync checklists and evidence tracking77aeee4 docs(testing): align README and localization verificationThis release is recommended for all v2.0.x users.
Download packages from GitHub Releases.
DistroNexus now automatically fetches the latest distribution list from Microsoft's official WSL repository during the build process. This ensures that new releases always ship with the most up-to-date list of available Linux distributions.
You can update via the in-app updater or download the latest installer from our GitHub Releases page.
]]>main branch instead of the correct master branch. This ensures reliable catalog updates for all users.This is a recommended update for all v2.0.x users to ensure continued access to distribution updates. You can update via the in-app updater or download the installer from GitHub Releases.
]]>| Dimension | Data |
|---|---|
| Duration | 25 days (16 active dev days) |
| Git Commits | 207 |
| File Changes | 1,686 changes, +134,965 / -40,042 lines |
| Source Code | ~26,900 lines (C# / XAML / PowerShell) |
| Test Code | ~3,065 lines (xUnit + Pester) |
| Documentation | 100 Markdown files, ~20,384 lines |
| Releases | v1.0.1 → v1.0.2 → v2.0.1 (including a full stack rewrite) |
| Templates | 15 built-in, 5 categories |
| PowerShell Cmdlets | 15 automation commands |
AI delivered: complete Go/Fyne desktop app, GitHub Actions CI/CD, bilingual README and release notes, Docusaurus i18n website.
The complete rewrite from Go/Fyne to .NET 10/WPF was a human decision, AI execution. The core skeleton — PowerShell module → .NET solution → Core → WPF — was completed in a single day.
| Phase | AI Responsibility | Human Responsibility |
|---|---|---|
| Requirements | Analyze needs, evaluate tech options | Set direction |
| Architecture | Design MVVM/DI, startup optimization | Approve |
| Implementation | All source code (C#/XAML/PS/Shell) | Code review |
| Testing | Unit/integration/automation suites | Acceptance testing |
| Documentation | 100 Markdown docs, bilingual | Content review |
| CI/CD | GitHub Actions, build scripts | Trigger releases |
| Website | Docusaurus site + content | Domain/deploy config |
| Refactoring | Go→.NET full stack migration | Approve decision |
| Performance | Startup 3–5s→100ms | Validate |
| Release | Packaging, notes, CHANGELOG | Final approval |
The most distinctive pattern. AI produces docs before code at every phase:
Requirements → Task breakdown → Implementation → Test docs → Acceptance checklist → Archive
The project mandates a planning triad (task_plan.md, findings.md, progress.md) before any complex task. 45 archived documents prove rigorous lifecycle management.
.github/copilot-instructions.md acts as an "alignment protocol" between human and AI — defining language rules, naming conventions, coding patterns, and planning requirements. It evolved through multiple iterations, reflecting how humans optimize the collaboration interface.
| Dimension | v1.0 | v2.0 |
|---|---|---|
| Language | Go | C# (.NET 10) |
| UI | Fyne (cross-platform) | WPF (Windows native) |
| Architecture | Monolithic scripts | MVVM + DI + layered |
| Backend | Standalone scripts | PowerShell module (15 Cmdlets) |
| Testing | None | xUnit + Moq + Pester |
| Build | Manual | CI/CD automated |
Git logs reveal classic AI debugging patterns: 6 consecutive CI fix commits in 90 minutes, multi-document diagnostic trails for startup freeze issues, cross-XAML/C# resource reference consistency repairs.
25 days to complete what would traditionally take months — including a full tech stack rewrite. 50,000+ lines of total output. Human effort focused on direction, confirmation, and acceptance.
Documentation volume (20,384 lines) approaches source code volume (26,918 lines). Not over-documentation — each AI session needs high-quality context to restore state and maintain consistency.
The instruction file's iterations (simplify → add planning rules → documentation norms) show how humans gradually optimize alignment with AI.
Despite AI completing nearly all execution: project direction, stack migration strategy, release cadence, quality thresholds, and promotion strategy were all human decisions.
"AI completed nearly the entire end-to-end workflow of this project — from requirements research, development, and testing to release delivery, including this release notes document. With AI handling almost all execution work, I was finally able to invest time in the output I have wanted to create for a long time."
This analysis was generated by AI based on 207 Git commits and 100 project documents.
]]>The template system is now a core capability in DistroNexus v2:
Instead of repeating setup steps on every machine, you can apply a reusable template workflow and keep team environments aligned from day one.
To make onboarding and maintenance easier, the website now includes a dedicated Template System docs module.
At a high level, the template system combines three parts:
config/templates.json) that defines template metadata and categoriesconfig/templates/) that execute setup steps inside target instancesThis design keeps template behavior transparent, extensible, and easier to validate across machines.
All complete template documents are available from the module page:
The module includes links to:
If you are starting from scratch, open the module page first and follow the documents in order.
]]>DistroNexus 2.0.1 is the first v2 release, moving from the v1.x line (latest: v1.0.2) to a fully modernized .NET 10 + WPF architecture.
v2.0.1 includes unified logging across desktop and PowerShell workflows to make troubleshooting faster and more predictable.
Logs are written under %APPDATA%\DistroNexus\logs and can be used to trace installation, lifecycle operations, package/catalog updates, and template execution.
The diagnostics pipeline is designed to improve issue reproducibility for both local debugging and support scenarios.
v2.0.1 provides bilingual (English and Simplified Chinese) support in both the WPF desktop client and project documentation. Core UI surfaces, release communication, and key operational references are maintained in both languages to improve accessibility for global and Chinese-speaking users. The content and localization structure is aligned across locales to reduce drift and keep update paths predictable.
The PowerShell module provides a stable, scriptable automation surface for DistroNexus operations. It supports both interactive administration and repeatable workflows for team provisioning, CI validation, and local environment bootstrap. With a consistent cmdlet contract, users can manage lifecycle, package/cache, catalog, and template automation tasks through one unified interface.
Get-DistroNexusInstance: List registered WSL instances and runtime state.Start-DistroNexusInstance: Start a specified WSL instance.Stop-DistroNexusInstance: Stop (terminate) a running WSL instance.Move-DistroNexusInstance: Move an instance to a new disk/path.Rename-DistroNexusInstance: Rename a registered instance.Remove-DistroNexusInstance: Unregister an instance and optionally remove files.Install-DistroNexusInstance: Install a new WSL instance from catalog/package sources.Set-DistroNexusCredential: Set/reset default user credentials for an instance.Get-DistroNexusPackage: List available/cached distro packages.Save-DistroNexusPackage: Download and cache distro packages locally.Remove-DistroNexusPackage: Remove cached package files.Update-DistroNexusCatalog: Refresh distro catalog metadata from source.Get-DistroNexusTemplate: Query available templates (with filters).Apply-DistroNexusTemplate: Apply a template to a target instance.Invoke-DistroNexusTemplateAutomation: Execute template automation validation workflows.The template system delivers reusable environment bootstrap flows for common development scenarios. It combines declarative metadata with script-based execution so teams can apply consistent setup standards across machines. With parameterized options and automation validation support, templates help reduce onboarding time and configuration drift.
config/templates.jsonconfig/templates/dotnet-dev (.NET Development)nodejs-dev (Node.js Development)python-dev (Python Development)docker-dev (Docker Development)fullstack-dev (Fullstack Development)dotnet-multi-sdk-dev (.NET Multi-SDK Development)nodejs-multi-version-dev (Node.js Multi-Version Development)python-multi-version-dev (Python Multi-Version Development)rust-dev (Rust Development)go-dev (Go Development)java-jvm-dev (Java/JVM Development)container-runtime-dev (Container Runtime Development)kubernetes-local-dev (Kubernetes Local Development)database-local-stack (Database Local Stack)ai-ml-gpu-dev (AI/ML GPU Development)catalog.json%APPDATA%\DistroNexus\settings.json2.0.1DistroNexus-2.0.1-Setup.exeDownload DistroNexus-v2.0.1-Release.zip:
DistroNexus.Desktop.exeDownload DistroNexus-v2.0.1-Release-selfcontained.zip:
DistroNexus.Desktop.exe%APPDATA%\DistroNexus\settings.jsoncatalog.json + %APPDATA% settings)Acknowledgment: AI completed nearly the entire end-to-end workflow of this project—from requirements research, development, and testing to release delivery, including this release notes document. With AI handling almost all execution work, I was finally able to invest time in the output I have wanted to create for a long time.
Thank you for using DistroNexus!
]]>Advanced Instance Management:
Package Manager:
Robust Logging:
logs/ directory with automatic rotation.Redesigned UI/UX:
Ubuntu-Work and Ubuntu-Personal), or keep different versions side-by-side.scripts/, handling the core logic for downloading and installing distros.config/settings.json.