[MASOCH-L] Kernel.org - Manutenção - Alterado para Masoch-L

Lista lista.gter at gmail.com
Tue Sep 20 14:46:01 BRT 2011


Em 20 de setembro de 2011 09:35, Henrique de Moraes Holschuh
<henrique.holschuh at ima.sp.gov.br> escreveu:
> On 19-09-2011 21:18, Lista wrote:
>>
>> eu para ser sincero, nunca recompilei um kernel da distro, sempre
>> baixo eles do kernel.org, então acredito que seguindo a minha
>> filosofia, existe varias pessoas que acessa o site para baixar o
>> kernel mais atual, ao invês de baixar dos respositórios da distro.
>> por isso disse que é um site de muita utilidade. Isso é questão de
>> gosto.
>
> O uso de kernels mainline por usuários finais não é muito recomendado,
> as distros melhores (RHEL, SuSE, Debian, Ubuntu) fazem um trabalho
> pesado de estabilização que não existe na mainline, _exceto_ nos kernel
> longterm bem mantidos, que não são todos.

Até concordo com você, porém ja tive alguns problemas com o debian
cujo qual tive que compilar um kernel sem baixar dos repositorios do
mesmo, e então por isso tenho um  certo costume em baixar um kernel
mainline(entendo que seja os kernel stable do kernel.org), devido a
atualizações de drivers e tals.

>
> O kernel.org é o HUB de desenvolvimento do kernel e de algumas
> aplicações.  Sua indisponibilidade reduziu em muito o passo de
> desenvolvimento do v3.1, a taxa de entrada de patches caiu estrondosamente.
>
> Só para deixar claro: hera.k.o, que é o master de replicação, *foi*
> invadida.  O que não é de espantar, já que é o equipamento em que se faz
> logon via ssh para fazer push, etc.   Eu não tenho certeza se zeus1 ou
> zeus2 (que tem vários TB de mirror de distribuição, etc) foram
> invadidas, mas como estão fora até no DNS, eu suponho que sim.
>
> Agora, só porque hera.k.o é master de replicação em k.o, não significa
> que é a cópia "master" dos repositórios git da maior parte dos
> desenvolvedores.  Na maioria das vezes, todo mundo trabalha com um
> repositório git local, e um repositório git é realmente 100% equivalente
> a outro, a diferença de quem é "master" é só no workflow... então é
> absurdamente trivial verificar se um repositório foi modificado: você
> simplesmente apaga todos os hooks, e compara todas as pontas de ramo
> (heads).
>
> O que dá trabalho é ter certeza que não foi modificado DURANTE o tempo
> em que ninguém estava prestando muita atenção: tem muito desenvolvedor
> que é realmente meia-boca em matéria de atenção a quesitos de segurança
> e ainda por cima tem o hábito DETESTÁVEL de basear seus patches em algum
> commit aleatório da mainline (coisa que atrai a ira de Linus quase que
> uma vez a cada 3 meses).  Felizmente, é 100% rastreável, só dá trabalho:
> na prática, não dá para modificar um repositório git sem deixar um
> rastro imenso já que altera *todos* os commit-id daquele ponto em
> diante, então você verifica todos os merges um a um para ter certeza que
> não tem commits estranhos neles, e faz um diff entre a sua versão de
> desenvolvimento e o que está na mainline.

Teria alguma documentação de como proceder com essa situação, para
analisar se os pacotes baixados foram ou não afetados?


More information about the masoch-l mailing list