Uma pesquisa no google revela esta história do slashdot produzindo este repositório github que não teve um commit desde 2016 . Existem 22.602 forks listados no github.com, mas estes serão principalmente (se não praticamente todos) simplesmente forks de desenvolvimento para torvalds/linux .
Eu li antes que o Linux se tornou bastante grosseiro. Parece-me que, pelo menos em termos de experiência do usuário, o Linux se tornou muito mais polido do que eu me lembro há mais de 10 anos (obviamente, esta não é uma avaliação precisa do kernel; só agora estou lendo K&R e nunca mergulhei em a fonte do kernel, exceto um olhar superficial que rendeu um "uau, não consigo entender uma linha disso", mas estou ciente de uma grande quantidade de desenvolvimento em relação aos recursos do linux-on-the-laptop no kernel, por exemplo) . Independentemente disso, eu sei que vi pessoas do BSD reclamando do Linux cruft. Considerando o fork neovim do vim baseado no cruft do vim, acho que esforços semelhantes seriam recompensadores para o kernel.
O que leva a essa pergunta foi este artigo sobre LWN discutindo tentativas de compilar Linux com clang. Eu li que o kernel usa muitas peculiaridades/recursos especiais específicos do gcc para otimização (embora o artigo vinculado pareça minimizá-los em comparação com minha memória), e comecei a me perguntar se alguém havia tentado refatorar/fork o kernel para fazer é mais portátil, ou pelo menos compilável fora do ambiente gnu. Eu também entendo que o próprio gcc é grosseiro, e o próprio Linus o criticou.
Eu sei que não estou sozinho em meu desgosto pessoal por RMS e GNU e interesse em Linux sem GNU; Estou ciente do Alpine Linux que dispensa ferramentas gnu, mas o kernel ainda é compilado com gcc, não é? Existem muitas referências a cadeias de ferramentas alternativas e software de usuário, mas estou especificamente me perguntando sobre o kernel e se existem forks que eliminam dependências gcc/gnu - considere isso uma questão subsidiária do título - parece-me que seria um desperdício de pedir separadamente.
Ninguém vai terminar o trabalho de sincronizar clang & Linux e depois manter isso como um fork de longo prazo . Especialmente quando há tanto interesse e vontade da linha principal. A menos que fosse uma pequena parte de um grande projeto visível, que você teria encontrado. (Como você fez...).
Android , conforme mencionado pela primeira resposta.
Algumas partes são mescladas, então talvez não seja tão ruim quanto era. Eu não estou realmente atualizado sobre isso. Mainline certamente consegue trabalho para algumas coisas relacionadas à CPU ARM, por exemplo, BIG.little. E o Android rebase repetidamente nas versões principais; O Google não vai ficar muito para trás.
Mas é um garfo de longa duração. Ele não é executado em regras "upstream primeiro". Eles estão carregando muito suporte de hardware.
IMO "Android" e "Google" são bons indicadores dos níveis de recursos que você precisa para algo que justifica ser chamado de fork do Linux.
Também kernels RHEL, que têm nomes aterrorizantes como 2.6.32-754 a partir de 2018. Não são apenas atualizações de segurança; eles incluirão suporte para algum novo hardware, enquanto ao mesmo tempo visam fornecer um comportamento mais próximo da versão básica do kernel, por exemplo, 2.6.32. Acredito que fork é uma palavra apropriada para os recursos que o RH precisa para manter isso.
Correr bem em uma ampla variedade de hardware recente é caro e, portanto, valioso. Isso é principalmente o que é o projeto do kernel Linux, e eu diria que é o fator mais importante para entender esses dois forks.
Você pode comparar o tamanho do código do vim e do Linux no openhub.net e pensar, oh, o Linux é "apenas" cerca de 20x o tamanho. No entanto, a diferença no número de commits é significativamente maior; a taxa de churn é bastante feroz.
Além disso, não é apenas que o código do kernel é mais difícil de acertar... embora seja... mas também é o suporte de hardware. Quando sua refatoração aparentemente inofensiva acaba quebrando alguns dispositivos, você precisa ter acesso a esses dispositivos específicos para depurar e corrigir o problema.
O suporte de hardware me faz pensar em https://en.wikipedia.org/wiki/Embeddable_Linux_Kernel_Subset :-P.
Neste mundo de virtualização de servidores, você também pode pensar que haveria fork(s) otimizado(s) para isso, pois eles não precisariam acompanhar tantos hardwares diferentes. Mas não consigo pensar em nenhum bom exemplo. Você pode procurar "unikernels"; parece haver vários não baseados em Linux.
linux-rt / PREEMPT_RT também vem à mente como um conjunto de patches fora da árvore. Este é um conjunto de patches que é baseado em sucessivas versões principais. 200 KB (compactados) de código especializado é um conjunto de patches respeitável. Alguns grandes pedaços dele foram mesclados, pelo menos um ponto.
O Android é uma bifurcação do Linux. De acordo com Linus. https://www.youtube.com/watch?v=duDC_u4ydVo não é muito útil, tenho certeza, você provavelmente está procurando um que seja bom para uso em desktop.