Bem-vindo à documentação oficial do Universo Oxy, um ecossistema de distribuições Linux projetado para diferentes perfis de usuários, unindo o melhor da estabilidade, customização e desenvolvimento.
Este projeto é mantido em colaboração oficial entre os canais:
- 🎬 Gabriel (fprowindows): Acesse o Canal no YouTube
- 🎬 JohnzinOmochain: Acesse o Canal no YouTube
- Desenvolvedor: Johnzin (
@JohnzinOmochain) - sub desenvolvedor Gabriel Ramos Barbosa
- Foco principal: Uso normal/cotidiano e experiência de usuário de ponta.
- Base do Sistema: Utiliza a base estável modificada do projeto principal, adaptada para entregar um sistema extremamente bonito, fluido e pronto para as tarefas do dia a dia.
- Público-alvo: Usuários comuns e desenvolvedores que buscam um sistema moderno, customizado visualmente e prático para navegar, estudar e trabalhar.
O Oxyohan segue as filosofias: Ubuntu, um sistema fácil em usabilidade, desde ao iniciante ao dev sênior e "Um projeto atrasado sempre será mais otimizado, enquanto um adiantado sempre será mais crashado" - JohnzinOmochain
Navegue pelo menu lateral para acessar o guia de instalação, documentação do kernel e repositórios de pacotes de cada versão!
JohnzinOmochain: johnzincontato@gmail.com
Gabriel do Linux (@fprowindows): apeludoff120@gmail.com
OxyohanOfficial: oxys.contact.official@gmail.com
Este sistema e seu código-fonte original (scripts de otimização, ajustes de kernel e configurações) são distribuídos sob a licença GNU General Public License v3.0 (GPLv3).
Para garantir compatibilidade imediata de hardware (como placas Wi-Fi, Bluetooth e touchpads) em notebooks e MacBooks, o sistema inclui drivers e firmwares pré-compilados redistribuídos a partir dos repositórios oficiais non-free e non-free-firmware da distribuição Debian.
OxyohanOS: Ativo NeoOxys: Em breve
Esse é um software livre de código aberto que é uma central de manuntanção para esta distro Caso alguem queira aprimorar essa ferramenta, fique à vontade! Github do centralmgr
Este é um projeto independente e comunitário, e contribuições são muito bem-vindas! Se você deseja enviar melhorias, correções de bugs, scripts ou modificações para o projeto, por favor, siga as regras abaixo para o envio:
🛠️ Diretrizes para Envio de Pull Requests (PR)
Para manter a organização, estabilidade e integridade do repositório, todas as contribuições via Pull Request devem seguir estritamente as regras de estrutura e documentação abaixo.
-
Requisitos de Estrutura e Escopo
Preservação da Estrutura: A árvore e a hierarquia de pastas originais do repositório devem ser mantidas intactas.
Substituição de Pacotes e Arquivos:
Você só deve alterar ou substituir arquivos/pacotes existentes caso eles mantenham o mesmo nome exato do arquivo original. Caso seja necessário criar, mover ou renomear arquivos/pastas, você deve fornecer uma justificativa técnica clara na descrição do Pull Request. -
Identificação do Contribuidor (OBRIGATÓRIO)
Todo Pull Request deve incluir um arquivo texto de identificação na raiz do projeto (ou no diretório da alteração):
Nome do arquivo: CONTRIBUTORS.txt (ou CONTRIBUTOR.txt) Conteúdo: Nome completo do desenvolvedor, usuário do GitHub e uma breve descrição da contribuição. -
Documentação e Changelog (OBRIGATÓRIO)
Junto ao envio do Pull Request (ou dentro da pasta do pacote alterado), é obrigatório fornecer um arquivo README.md ou CHANGELOG.log contendo:
Escopo das Modificações: Relação detalhada de todos os pacotes, scripts ou configurações alterados/adicionados.
Justificativa Técnica: Explicação clara sobre o motivo da mudança, detalhando qual bug foi corrigido, qual ganho de desempenho foi obtido ou qual melhoria foi implementada.
- Alternativa de Envio via Pacote Compactado
Caso o contribuidor opte por enviar as alterações via e-mail ou canal de suporte listado na documentação do projeto:
Os arquivos devem ser empacotados mantendo a estrutura de diretórios original nos formatos .zip, .tar.gz ou .tar.xz.
O pacote deve conter o arquivo de identificação (CONTRIBUTORS.txt) e o log explicativo das alterações.
⚠️ Atenção: Pull Requests que apresentem arquivos desorganizados, alterações na estrutura de pastas sem justificativa, ou que omitam a documentação obrigatória serão recusados (closed) sem análise prévia ou integração ao branch principal.