Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Community Notes (unverified tier)

This section holds the community-notes tier of the InterGenOS wiki. The pages here are written and maintained by the wider community rather than drawn directly from the project’s source tree, build system, or maintainer documentation. They are clearly labeled as a separate, lighter-bar tier so you always know which kind of content you are reading.

This tier still goes through review. “Lighter bar” does not mean “no bar.” It means the standard of proof is different from the verified documentation, and the distinction is made explicit on every page.

Two tiers, one wiki

InterGenOS documentation comes in two tiers:

  • Verified documentation — the rest of this wiki. These pages describe what the system actually does today, checked against the source tree, the build phases, package metadata, and the shipped behavior of the current build (version 1.0-dev, build id v1.0-dev1). When a verified page makes a concrete claim, that claim is meant to be reproducible from the system itself.

  • Community notes (this tier, unverified) — tips, walkthroughs, workarounds, hardware reports, and field experience contributed by users. These pages are useful and welcome, but they are not held to the same line-by-line ground-truth standard as the verified documentation, and they may describe a setup, version, or hardware combination that differs from yours.

The reason for the split is the project’s guiding principle: a machine you understand, can modify, and can trust. Trust depends on knowing where a statement came from. Mixing maintainer-verified facts with community experience under a single label would blur that line, so the two are kept apart and clearly marked.

What “unverified” means here

A page in this tier has been reviewed for accuracy, safety, and fit with the project’s goals, but it has not necessarily been verified against the source tree the way the core documentation is. In practice:

  • The advice may be correct for the contributor’s setup and not for yours.
  • A note may lag behind the current build. InterGenOS is in active development, and package counts, defaults, and behavior drift between builds.
  • Commands, package names, and file paths in a community note should be treated as starting points to confirm, not as guaranteed-current reference. When in doubt, cross-check against the verified documentation and the system in front of you.

Security-relevant claims get extra scrutiny. Any community note that would weaken the security posture of the system, suggest disabling integrity protections, or work around a build failure by removing functionality is rejected, the same way such a change would be rejected in code.

What belongs in the community tier

Good candidates for a community note include:

  • Hardware compatibility reports and field notes (what worked, what did not, on a specific machine).
  • Step-by-step walkthroughs for tasks that sit on top of the verified documentation rather than replacing it.
  • Configuration recipes and customizations that respect the system’s defaults and security chain.
  • Troubleshooting experience and workarounds, clearly dated and scoped to a build or hardware combination.

Content that belongs in the verified documentation instead — because it describes core system behavior — includes the build pipeline, the package manager (pkm), the Forge installer, the signed Secure Boot chain, dm-verity integrity, UKI signing, and the local AI assistant. If your note is really a correction or addition to how one of those works, it should go through the standard contribution path so it can be verified.

What does not belong here

  • Anything that weakens the security posture of the system.
  • Workarounds that disable a feature or drop a dependency to dodge a build failure, instead of fixing the root cause.
  • Unverified source tarballs, missing or incorrect checksums, or instructions that fetch software from untrusted origins.
  • Internal development artifacts: host-specific paths, machine names, or credential-like strings. All contributions to the public repository are scanned by an automated public-content audit, and the same standard applies to wiki notes.

Current system at a glance

So community notes are read in the right context, here is what the project ships today (version 1.0-dev):

  • Desktop: GNOME 49 on Wayland. KDE/Plasma and switchable desktops are planned, not shipped. A community note that assumes a different desktop is describing a setup InterGenOS does not currently provide.
  • Packages: the build is organized into six tiers (toolchain, core, base, desktop, ai, extra), on the order of 850 packages as of this writing. These counts drift between builds; derive the live number from the system rather than trusting a fixed figure in a note.
  • AI: “InterGen” is a tiered, hardware-detected, offline-first local assistant built on Qwen models, with zero telemetry. “InterGen Sentinel” is a pluggable security scanner that defaults to Local-Rules plus Local-Qwen, with six opt-in cloud providers (Claude (Anthropic), Gemini (Google), Copilot (Microsoft), ChatGPT (OpenAI), Grok (xAI), DeepSeek). The cloud escalation path is called Phone-A-Friend (Frontier/Cloud Escalation) and is opt-in. A community note should never present any cloud provider as on-by-default.

How to contribute a note

Community notes follow the same project values as code contributions: research before writing, simplicity over cleverness, transparency with no hidden behavior, and only submitting what you can actually verify on your own machine. Contributions to the project are made under the GNU General Public License v3.0 or later, and code commits carry a Developer Certificate of Origin sign-off.

If you are not sure whether something belongs in the community tier or the verified documentation, open an issue and ask first.

See also