Existe algum garfo ou refatorador de sucesso do Kernel do Linux?

Question

Uma pesquisa no google revela esta história do slashdot rendendo este repositório do github que não tem um commit desde 2016 . Existem 22.602 garfos listados no github.com , mas estes serão principalmente (se não todos) simplesmente desenvolvimento garfos para torvalds / linux .

Eu li antes que o Linux tornou-se bastante crocty. 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, essa não é uma avaliação precisa do kernel; só agora estou lendo K & R e nunca mergulhado na fonte do kernel, exceto um olhar superficial que rendeu um "whoa, eu 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 exemplo). Independentemente disso, eu sei que vi pessoas BSD reclamando sobre Linux cruft. Considerando o fork neovim do vim baseado no crush do vim, eu pensaria que esforços semelhantes seriam recompensadores pelo kernel.

O que solicita essa pergunta foi este artigo sobre o LWN discutindo tentativas de compilar o Linux com clang. Eu li que o kernel usa muitas peculiaridades especiais para o gcc para otimização (embora o artigo vinculado pareça subestimá-las em comparação com a minha memória), e comecei a me perguntar se alguém tentou refatorar o kernel para fazer é mais portátil, ou pelo menos compilável fora do ambiente do gnu. Eu também entendo que o próprio gcc é crufty, e o próprio Linus o criticou.

Eu sei que não estou sozinho em meu desagrado pessoal por RMS e GNU e interesse em Linux sem o GNU; Estou ciente do Alpine Linux que faz sem ferramentas gnu, mas o kernel ainda é compilado com o gcc, não é? Existem muitas referências a toolchains alternativos e softwares de usuários, mas estou me perguntando especificamente sobre o kernel e se existem forks que eliminam as dependências do gcc / gnu - considere esta uma questão subsidiária do título - parece-me que seria uma desperdício para perguntar separadamente.

    

Answer 1

I am specifically wondering about the kernel and whether there are forks that eliminate gcc/gnu dependencies--

Ninguém vai terminar o trabalho de sincronizar o & clang & Linux e depois manter isso como um fork de longo prazo . Especialmente quando há tal 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 ...).

consider this a subsidiary question of the title--it seems to me it would be a waste to ask it separately.

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. A linha principal certamente funciona para algumas coisas relacionadas à CPU ARM, por exemplo. Grande pequeno. E Android rebase repetidamente nas versões principais; O Google não ficará muito atrás.

Mas é um garfo de longa duração. Não é executado em regras "upstream first". Eles estão carregando muito suporte de hardware.

IMO "Android" e "Google" são bons indicadores para os níveis de recursos de que você precisa para algo que justifique ser chamado de fork do Linux.

Android has also been a problem in that devices running it ship with kernels containing large amounts (often millions of lines) of out-of-tree code. -- https://lwn.net/Articles/738225/

Também os kernels RHEL, que têm nomes aterrorizantes como 2.6.32-754 a partir de 2018. Estes não são apenas segurança atualizações; eles incluirão suporte para algum novo hardware, enquanto ao mesmo tempo objetivam fornecer um comportamento mais próximo à versão básica do kernel, por exemplo, 2.6.32. Eu acredito que fork é uma palavra apropriada para os recursos que RH requer para manter isso.

Correndo bem em uma ampla gama 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 garfos.

Você pode comparar o tamanho do código do vim e do Linux no openhub.net e pensar, oh, o Linux tem "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 é 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 no link :-P.

Nesse mundo de virtualização de servidores, você também pode pensar que haveria o (s) fork (s) otimizado (s) para isso, já que eles não precisariam manter um hardware muito diferente. Eu não consigo pensar em bons exemplos. Você poderia procurar "unikernels"; parece haver vários não baseados no Linux.

linux-rt / PREEMPT_RT também vem à mente como um conjunto de remendos fora da árvore. Este é um conjunto de patches que é rebaseado em versões principais sucessivas. 200 KB (compactado) de código especializado é um conjunto de patch respeitável. Alguns pedaços grandes foram mesclados em pelo menos um ponto.

    

Answer 2

O Android é um fork do Linux. De acordo com o linus. link não é muito útil eu tenho certeza, você provavelmente está procurando um que é bom para uso em desktop .. android não é