Kernel 2.6.38 já tem direção
Enviado por Pablo Hess (pabloΘhess·net·br):
Ao final desse período, cessam-se as inclusões significativas de código no Linux, e qualquer coisa realmente nova só terá chance de entrar no kernel a partir da versão seguinte (2.6.39, no caso).
A “janela” do kernel 2.6.38 já fechou, e ofereço no blog do IBM developerWorks um panorama do que está por vir nessa próxima versão.
Para os ansiosos: ainda não entrou o suporte a Xen dom0, mas já entrou o “patch-maravilha” que melhora radicalmente o comportamento gráfico do sistema por meio da criação automática de cgroups por tty. Ah, e o novo mecanismo de RCU para caminhos de diretório tornou o VFS do Linux ainda mais rápido do que já era, surpreendendo inclusive muitos desenvolvedores.” [referência: ]
@brlinuxblog
Feed RSS
Cara, uma coisa que eu não entendi foram as críticas sobre o “patch maravilha”.
O pessoal reclama que esse patch ajuda somente os desenvolvedores do Kernel. Mas não atrapalha os outros usuários, ou atrapalha?
E um outro cara deu outra solução que supostamente atinge o mesmo resultado do patch maravilha. Mas não é melhor já deixar a solução embutida no Kernel? E outra, se é possível atingir esses resultados, de uma forma ou de outra, por que não vem já no padrão das distribuições? Existe alguma contra indicação?
Agradeceria se alguém que entendesse melhor essa parte pudesse esclarecer isso.
@Felipe
A questão do “patch maravilha” versus “solução alternativa” é justamente o conflito entre soluções no espaço do kernel e soluções no espaço do usuário.
Eu sou mais favorável, neste caso, à solução alternativa. Imagine que você compre suporte de um fornecedor “enterprise”. Você tem suporte ao kernel empacotado pelo fornecedor, mas qualquer alteração a ele viola os termos do contrato de suporte.
Agora digamos que o “patch maravilha” não seja benéfico ao seu uso do sistema. O que voc6e faz? Recompila o kernel? Não pode.
Felizmente, os desenvolvedores lembraram de incluir uma entrada pra isso no /proc (não lembro o nome agora), e é possível desativar o recurso com o sistema em funcionamento e sem recompilar o kernel.
O resultado final, na minha opinião, é um kernel mais “bloated”, que se encarrega de assuntos desnecessários — justamente porque existem soluções igualmente eficazes em espaço de usuário.
O argumento pró-kernel entre os desenvolvedores, na LKML, foi que é melhor embutir isso no kernel porque os usuários não vão conseguir “mexer e estragar”. Já o outro lado afirmou que os usuários também não mexem em várias partes das configurações em espaço de usuário, então esse argumento seria inválido.
Entendeu melhor?
7.600 propostas de patches em duas semanas!!! Não é pouca coisa não.
Phes – entendi. Valeu a explicação.
Agora eu não entendi por que a solução alternativa já não vem por padrão nas distribuições.
@Felipe
Em primeiro lugar porque tudo isso ainda é muito recente. Não deu tempo de todo mundo verificar o funcionamento dessa solução. O resultado é que ela está longe de ser “mainstream”.
Em segundo lugar, a solução alternativa requer a ativação do recurso de Cgroups (Control groups), que “custam” um pouco de CPU. Não sei se as distribuições ativam os Cgroups por padrão. Até agora os Cgroups não eram muito usados — o próprio Linus disse que sempre responde “N” nas opções do Cgroups na configuração do kernel pra máquina dele — justamente porque não ofereciam nenhuma vantagem imediata. Eles são somente uma infraestrutura, e é preciso saber usá-los pra gerar algo útil.
@Phess – valeu…