Eu não faço parte da comunidade Linux, mas...

Nunca desenvolvi nada para o lado do Linux.
Pelo visto, o wrapper em Rust para drivers de dispositivo tem uma estrutura que não pode ser separada do kernel...

Acho que não se deve considerar essas pessoas e o autor deste comentário como pertencentes à mesma comunidade.

Eu também sou usuário de Rust, mas se código Rust e código C ficarem misturados, sem regras rigorosas em projetos open source sobre até que ponto o código Rust é permitido, isso me parece impossível de controlar ou, no mínimo, elevaria enormemente os custos de revisão e manutenção. Acho que a escolha mais sensata é fazer um fork sem adicionar isso.

Acho que a ideia é que, entre vários métodos de marketing, blog não é necessariamente a melhor opção; mas as alternativas sugeridas são fazer divulgação com um cartaz na frente do escritório do cliente ou discutir no X, então fica meio complicado.

Não entendo muito de kernel, mas acho que seria ótimo se fosse possível traduzir automaticamente código C para Rust. Claro, além do problema da tradução de código, também haveria a questão humana.

Eu tinha desistido de usar o Obsidian por conta da licença quando tentei usar pessoalmente na empresa, mas acho que vou voltar a usar.

Legal...

Achei que fosse uma tradução livre.

Opa, eu estava assinando a licença comercial, então isso é ótimo.

Lembro que, quando era preciso fazer backport para a versão stable ou algo assim e eu entrava em contato, ele sempre respondia bem mesmo no meio de toda aquela correria.

Conheço empresas que investiram em SEO por muito tempo para aumentar o tráfego orgânico e, com isso, gerar uma receita estável; então até entendo a ideia, mas é difícil concordar de pronto.

Não sei ao certo se o senhor tem experiência com desenvolvimento de kernel, então não sei muito bem como devo responder, mas
antes de tudo, aplicar a linguagem Rust não significa mudar o kernel para Rust. Dá para perguntar se não seria melhor separar e criar outro kernel, mas
não se trata de fazer um kernel em Rust; a ideia é criar wrappers em Rust apenas para a interface de drivers de dispositivo no kernel, para que somente os drivers de dispositivo
possam ser feitos em Rust. Portanto, seguir como um novo projeto não faz sentido.

Tem, de longe, muitos vídeos do GOTO..

É preciso abandonar um pouco a fantasia da engenharia global..

É necessária uma otimização extrema de processos, mas desenvolvimento em 3 turnos com base em um único padrão local é comum na área de games.
Um exemplo típico são os grandes estúdios chineses de jogos, que desenvolvem 24 horas por dia em 3 turnos.

Empresas de games como EA e Ubisoft, onde a engenharia global já está estabelecida há muito tempo, trabalham de acordo com seus respectivos fusos horários, então atrasos na velocidade de execução acabam sendo inevitáveis, mas operam com a sensação de que o custo de vida mais baixo + custo de mão de obra compensam isso. (Agora, com as demissões em massa, não sei em que situação estão.)

É bem irônico que a comunidade Linux, que vinha justificando um tom tóxico em nome da estabilidade do kernel, agora considere a reação de "se não gostou, faz um fork" como uma resposta razoável.

> O título deve indicar que se trata de uma crítica às regras

222

Opa, foi uma boa decisão mesmo..

Meu projetinho paralelo tem o melhor DX com solidjs >m< / felicidade

Acho que pode haver uma dificuldade em prever se o resultado do fork vai acabar sendo uma migração ou um período caótico de fragmentação.
Mesmo depois do fork, refletir as mudanças do upstream provavelmente não vai ser uma situação muito agradável.