Perguntas práticas, respostas sem maquiagem.

Use a página Download como referência. Ela deriva o estado de release do projeto canônico; builds internas e artefatos de CI não são apresentados como release pública.

Veja o Roadmap. Ele deriva a fase ativa do repositório canônico e mostra R/V/H sem transformar evidência em porcentagem de conclusão.

KDE é a primeira referência; XFCE e Hyprland vêm depois que a plataforma compartilhada estabilizar. O desktop nativo continua fora do caminho crítico da primeira versão.

Pode. A D-108 não bloqueia outros DEs/WMs, mas só os perfis oficiais recebem integração, configuração e compatibilidade validadas pelo projeto. Compatível não significa validado.

Para o desktop nativo futuro, D-019 define Wayland-only com XWayland sob demanda. Isso é uma decisão de arquitetura, não uma alegação de que todo aplicativo X11 já foi validado no Felunyx.

Não. Passar V prova integração em ambiente virtual; não prova H. Hardware real precisa de evidência própria para firmware, GPU, rede, armazenamento, periféricos e energia.

A prioridade padrão definida em D-064 é Felunyx → Arch → AUR curado → Flatpak → Nix. A origem continua visível e o usuário pode fazer override consciente.

Não. AUR pode aparecer na interface oficial, mas receita, diff, origem, risco e helper usado continuam expostos. A GUI não transforma pacote comunitário em pacote oficial.

Mudanças de sistema passam pelo backend compartilhado com plano e consequências visíveis. O Felunyx não deve fazer reparos ou mudanças destrutivas silenciosas; snapshots são acionados conforme risco.

Sim nas instalações automáticas, conforme D-006. O projeto não transforma isso em promessa de nomes universais de subvolumes: detalhes exatos continuam pertencendo às especificações de cada fase.

Linux Zen é o kernel padrão e Linux LTS é o fallback explícito. A intenção é que o fallback continue visível e deliberadamente selecionável.

Sim. Felunyx usa systemd; isso é uma decisão aceita da base do sistema, não uma camada substituída ou escondida pela interface.

A direção atual de D-090 é recomendar criptografia sem torná-la obrigatória. A decisão é Provisional, então o FAQ não trata esse detalhe como contrato final de instalação.

A direção atual de D-092 é não ter telemetria por padrão. Qualquer mecanismo futuro de diagnóstico precisa ser opt-in, inspecionável e aprovado separadamente; D-092 ainda é Provisional.

Não no design aprovado da Fase 2. OpenSSH pode estar presente por dependência do instalador, mas sshd fica desabilitado e a imagem não gera host keys. Isso é requisito da fase, não uma promessa sobre um recurso remoto futuro.

Não. O fluxo aprovado é Análise → Proposta → Confirmação → Resultado. Reparos silenciosos são proibidos; acesso remoto também não deve ligar sem consentimento.

Não por padrão. A política aceita preserva a home durante restauração e usa snapshots de forma proporcional ao risco da operação, em vez de tratar todo pacote como desastre iminente.

Sim. Contribuições podem ser código, testes, documentação, tradução, design, relatórios de hardware, pesquisa ou reprodução de bugs. As decisões canônicas continuam seguindo o processo do projeto, não votação popular.

R é evidência Remote, V é evidência Virtual e H é evidência em Hardware real. Passar R não implica V; passar V não implica H. O Roadmap mostra esses gates sem tratá-los como porcentagem.