Practical questions, answers without makeup.

Use the Download page as the reference. It derives release state from the canonical project data; internal builds and CI artifacts are not presented as a public release.

See Roadmap. It derives the active phase from the canonical repository and shows R/V/H without turning evidence into a completion percentage.

KDE is the first reference; XFCE and Hyprland come after the shared platform stabilizes. The native desktop remains outside the critical path for the first release.

Yes. D-108 does not block other DEs or WMs, but only official profiles receive project-validated integration, configuration, and compatibility. Compatible does not mean validated.

For the future native desktop, D-019 defines Wayland-only with XWayland on demand. That is an architectural decision, not a claim that every X11 application has already been validated on Felunyx.

No. Passing V proves integration in a virtual environment; it does not prove H. Real hardware needs its own evidence for firmware, GPU, networking, storage, peripherals, and power behavior.

The default priority defined by D-064 is Felunyx → Arch → curated AUR → Flatpak → Nix. The origin remains visible and users can consciously override the choice.

No. AUR may appear in the official interface, but recipe, diff, origin, risk, and the helper in use remain exposed. The GUI does not turn a community package into an official package.

System changes pass through the shared backend with the plan and consequences visible. Felunyx must not perform silent repairs or destructive changes; snapshots are triggered according to risk.

Yes for automatic installations, as defined by D-006. The project does not turn that into a promise of universal subvolume names: exact details remain part of each phase specification.

Linux Zen is the default kernel and Linux LTS is the explicit fallback. The fallback is intended to remain visible and deliberately selectable.

Yes. Felunyx uses systemd; that is an accepted system-base decision, not a layer replaced or hidden by the interface.

The current direction in D-090 is to recommend encryption without making it mandatory. The decision is Provisional, so the FAQ does not present that detail as a final installation contract.

The current direction in D-092 is no telemetry by default. Any future diagnostic mechanism must be opt-in, inspectable, and approved separately; D-092 is still Provisional.

Not in the approved Phase 2 design. OpenSSH may be present as an installer dependency, but sshd stays disabled and the image does not generate host keys. This is a phase requirement, not a promise about a future remote-access feature.

No. The approved flow is Analysis → Proposal → Confirmation → Result. Silent repairs are forbidden; remote access must not turn on without consent either.

Not by default. The accepted policy preserves home during restoration and uses snapshots proportionally to operation risk instead of treating every package as an imminent disaster.

Yes. Contributions can be code, testing, documentation, translation, design, hardware reports, research, or bug reproduction. Canonical decisions still follow the project process, not popular vote.

R is Remote evidence, V is Virtual evidence, and H is evidence on real Hardware. Passing R does not imply V; passing V does not imply H. Roadmap shows these gates without treating them as a percentage.