linuxmirrors-awesome

LinuxMirrors Authoritative Guide

Quick Start

First determine whether the question is "understanding the project" or "executing a change." Introductions, capabilities, compatibility, latest changes, and source verification stay in this skill; system software source changes or Docker changes only get task routing, and production commands are not assembled directly.

Can be used directly:

• "Introduce LinuxMirrors and explain how it differs from an ordinary list of mirror sites."
• "Verify which systems LinuxMirrors currently supports, citing the official website and source code."
• "Compare the main script and the Lite script, and tell me which one to choose."

When to use

Use when the user wants to understand LinuxMirrors, verify the latest project facts, compare scripts, or determine the task path. If the user asks to actually change system sources, install Docker, or modify the Registry, only complete source verification and routing, and do not execute changes within this skill.

Intended users

• Beginners: first read the project positioning and the three task paths.
• Operations staff: focus on freshness, compatibility, security, and routing materials.
• Skill/documentation maintainers: use the source index and quality checklist to verify facts and citations.

Workflow

Step 1: Identify intent

Distinguish between project introduction, latest information, system source change, Docker installation, Registry Mirror, or source code analysis.

Step 2: Check timeliness

Record the access date; for dynamic facts, verify at least two types of sources: the official website and GitHub/current source code.

Step 3: Locate materials

According toauthoritative sourcesread the official website, documentation, repository, changelog, and security announcements.

Step 4: Cross-verify

Usefreshness rulesto handle differences between the official website, README, and source code; do not fill in from memory.

Step 5: Organize the answer

Give the conclusion first, then the applicable conditions, evidence links, risks, and next-step task routing.

Step 6: Self-check the output

Executequality checklist, ensuring that documentation descriptions are not mistakenly written as already-executed results.

Capability boundaries and unsuitable scenarios

✅ Good at handling

1. Explain LinuxMirrors' project positioning, two types of scripts, open-source license, and typical users.
2. Verify supported systems, parameters, main script/Lite differences, and latest commits based on the official website and source code.
3. Determine whether a need should enter the system software source, Docker CE software source, or Registry Mirror process.

⚠️ Requires conditions

1. "Does it support my machine" requires the distribution, version, architecture, and network region.
2. "What has changed in the latest version" requires access to the official website or GitHub, and the verification time must be noted.
3. "Which mirror is fastest" requires the user's location and actual testing; only selection principles can be given, and speed test rankings must not be fabricated.

❌ Out of scope (give alternatives)

1. Directly modify /etc or run a remote source-change script → transfer to the dedicated system source-change process and perform pre-checks and backups first.
2. Installing Docker, disabling the firewall, or restarting production services → switch to the Docker-specific workflow and require change authorization.
3. Guaranteeing permanent availability of a third-party mirror site → provide verification commands, official source fallback, and troubleshooting paths.

Resource Routing

• Project positioning and capabilities: readProject Overview。
• Supported systems and versions: readCompatibility。
• Official website, source code, and changelog: readAuthoritative SourcesandFreshness Rules。
• Task routing: readDecision Routing。
• Security and privacy: readSecurity Boundaries。
• Information conflicts and access failures: readResource Troubleshooting。
• Pre-delivery review: readQuality Checklist。
• End-to-end usage: read on demand examples/ the ten scenarios in .

Security and Privacy

This skill does not collect, store, or transmit user data. When accessing external resources, only read public pages; do not request passwords, Tokens, or private keys. Do not execute curl | bash, process substitution, software source modification, Docker installation, or service restart in introductory answers.

Rules

1. Do not fabricate in uncertain areas; if it cannot be found, mark it as unknown and as an item to be verified.
2. For dynamic facts, cite at least two types of evidence from the official website and the current source code/GitHub.
3. Do not execute system changes, and do not write suggested commands as already executed results.
4. Split multiple tasks in the order of project understanding, system base sources, Docker CE, and Registry.

When information is insufficient

First give a safe-assumption version, then list the missing information:

First answer according to "only perform resource verification, do not execute changes." To determine actual usability, please supplement: 1) distribution and version; 2) CPU architecture; 3) network region; 4) whether the target is the system software source, Docker CE software source, or Registry Mirror.

Verification Checklist

• Are dynamic facts annotated with the verification date and source?
• Do the parameters come from the current --help, the source code parsing branch, or advanced usage on the official website?
• Are the system software source, Docker CE software source, and Registry Mirror distinguished?
• Are "suggested execution" and "already executed" clearly separated?
• Is a fallback path provided via GitHub, local source code, or official sources when the official website is inaccessible?

Gotchas

1. Do not treat LinuxMirrors as a mirror site; it is a project for switching sources and for Docker installation/source-switching scripts.
2. Do not use old parameters from the README to override the current script --help; verify the source code first.
3. Do not interpret Lite as a complete equivalent of the full script; it streamlines functionality and interaction.
4. Do not promise that a certain mirror site is "the fastest"; availability is affected by region, carrier, and synchronization status.
5. Do not conflate the Docker CE package repository with the Docker Hub Registry Mirror.
6. When the official website is unreachable, do not stop at "please provide more information"; first give a provisional conclusion with a timestamp based on the local source code and list the items to be verified.

FAQ

Q1: Is LinuxMirrors a mirror site? No. It provides scripts that automatically identify the system and generate or modify software source configurations, and also provides Docker installation and source-switching scripts.

Q2: Why is it necessary to visit the official website? Supported versions, mirror addresses, and parameters may change; the official website and current source code are the authoritative entry points for dynamic facts.

Q3: What should be done if the official website conflicts with the source code? Prioritize the current source code behavior, note the commit number, and explain the official website differences; do not choose silently.

Q4: Main script or Lite? Choose the main script when full interaction, more systems, and advanced parameters are needed; consider Lite only when explicitly accepting reduced capabilities.

Q5: Can you change the source for me directly? This skill only provides introductions and routing. Actual changes must first collect system information, backups, and rollback conditions.

Q6: Can you recommend the fastest mirror? Principles for compatibility and regional selection can be provided, but they cannot replace connectivity and latency tests on the target host.