RUST é uma alternativa. Mas RUST é chata de programar!
E esta no hype.
Ainda precisa melhorar muito para ser gostosinha de programar!
Ela não é ruim nem nada, só chata mesmo! kkkkk
Creio eu que se ela continuar seu desenvolvimento e ela for melhor pro dev ela será perfeita pra substituir o C de vez!
Mas vamos ver
As intenções do Hector em querer adotar uma linguagem mais moderna parece uma boa medida, mas o ponto levantado pelo Hellwig é crucial; usar várias linguagens no kernel pode tornar algumas coisas instáveis.
Além disso, também é válido lembrar que o trabalho dos desenvolvedores não se resume apenas a escrever um código e compilá-lo. Eles trabalham em várias versões paralelas de kernel para garantir suporte ao maior número possível de dispositivos. Só isso já mostra o potencial de estrago de um código defeituoso.
Eis uma coisa que pouco se fala no mundo open source: muitos dos devs chave destes projetos são tudo lobo velho nesta tecnologia. Lobo velho e teimoso, ênfase no teimoso.
Ao contrário de projetos de código fechado e para interesses particulares, onde o lucro é quem manda e se não gostarem, basta pedir as contas, o mundo Open Source é muito volátil justamente por depender da comunidade. Comunidade esta que nem sempre vai estar alinhada entre si, seja na forma de operar o projeto, seja em qual filosofia de como desenvolver software escolher, seja até por motivos completamente alheios ao projeto, mas que insistem injetar no meio, vide as tretas que envolvem o Bryan Lunduke por exemplo.
E é nessas desavenças e falta de vontade de definir um meio termo que projetos Open Source tendem a ficar em risco, muitas vezes por estupidez e teimosia…
Risco de que? A sua natureza é justamente essa, não é um defeito. Quem não está satisfeito faz um fork e toca adiante.
Quando o projeto é bem mais simples, certamente é algo justo de se fazer, mas não é algo que projetos altamente complexos como um sistema operacional como o Linux tem o luxo de ter.
Ter a possibilidade de fazer uma fork sempre será bem-vinda. O problema é quando você não dispõe de braço e mentes pensantes o suficiente para tocar um projeto dessa magnitude adiante usando apenas sonhos e esperanças e pouca remuneração, muito menos fazer uma fork.
Nesse ponto em específico, muita gente vai ter o costume de balbuciar coisas como “mas não é minha culpa se esses zoomers todos são burros e não querem se especializar na minha linguagem falha, mas funcional”, mas é nesse ponto que eu não consigo evitar de concluir que ter ego é uma ■■■■■ e muito conhecimento e talento é jogado fora por causa dessas rixas.
Tem que trocar mesmo. O mundo Linux é sucessão de tecnologia e nenhuma deve ser predominante apenas porque alguns membros se acostumaram com tal linguagem. O Rust é muito eficiente e se o mundo Linux precisa de eficiência e modernidade, estão apostando na peça certa.
C não é inseguro, o problema do C nunca foi a linguagem e sim os desenvolvedores. A troca pelo Rust é algo que vem sendo forçado pelo governo dos US, não é uma escolha técnica, não existe justificativa técnica para trocar C pelo Rust. Rust não passa de uma moda e como moda logo logo vai passar.
Eu vejo gente nova tão ou mais que os mais velhos!
kkkkkkk
Mais uma vez o “Diretor da Escola” tem que intervir porque os “alunos” estão badernando.
A solução poderia ser mais forks, o que é um tiro no escuro pois vai gerar mais problemas entre apps rodando em distros diferentes. Aí serão dois tipos de kernel 
sem condições.
Uso GNU/Linux desde o começo da década de 90.
Comecei com o Slackware lá por 93/94, e desde então passei por várias distribuições: Conectiva, Red Hat, todos os Fedoras (atualmente no Fedora 40).
São 30 anos de Linux no meu currículo!
No meu dia a dia, trabalho principalmente com Bash, Git, LaTeX, LyX, C++ e Emacs. Chrome.
Essas ferramentas sempre me atenderam bem, mas recentemente tenho enfrentado alguns problemas que me fizeram refletir sobre o rumo que as coisas estão tomando.
Com a popularização de sistemas escritos em Python e, mais recentemente, em Rust, tenho notado que minhas máquinas estão travando com frequência.
Uso um notebook Dell, um computador pequeno Dell e uma workstation Precision 5820 Dell, e todos estão me dando dor de cabeça.
O Fedora 39 e 40 têm apresentado vários bugs, e o desempenho está longe do ideal.
Fiz alguns testes e os resultados foram preocupantes:
-
Python consome 4x mais memória e é 60x mais lento em comparação com as soluções que costumo usar. Para mim, é uma opção ruim para sistemas que exigem eficiência.
-
Rust, por outro lado, tem uma sintaxe que considero bastante complicada. E bota complicação nisso!
No fim das contas, ainda prefiro C/C++.
A linguagem continua evoluindo, com o comitê da ISO atualizando-a constantemente, e ela atende bem às minhas necessidades de desempenho e controle.
Por que não criar duas versões do Linux?
-
Uma focada em alta eficiência e desempenho, voltada para uso acadêmico e doméstico.
-
Outra focada em alta segurança, com milhares de subserviços e autenticações em múltiplos estágios (5, no mínimo! kkk), destinada a grandes empresas e bancos.
Reflexão sobre o passado e o futuro:
Vi as ciências da computação nascerem.
Era um campo com um futuro brilhante pela frente.
Usei varias calculadoras programáveis da HP, uma máquina prologic. Um PC XT286.
A chegada dos PCs revolucionou o uso da tecnologia, e nós, usuários, tínhamos o domínio real sobre as máquinas.
Hoje, no entanto, estamos voltando a um modelo centralizado, com centenas de servidores, dezenas de senhas e autenticações, tudo consumindo cada vez mais memória, máquinas e energia. E, paradoxalmente, os sistemas estão ficando mais lentos, menos seguros.
Vejo muitos defendendo o uso de Python porque é “mais simples para o programador”.
Mas e o usuário final?
Que se dane, né?
Afinal, ele só vai ter que lidar com um programa 4x mais pesado e 60x mais lento.
Assim, uma cultura morre.
Troca-se o domínio real do computador pelo “simples e fácil”.
Parece que quem defende esse modelo de simplismo vai vencer a batalha, mas quem perde a guerra é o futuro das ciências da computação.
Enfim, esta briga so mostra que iremos viver tempos obscuros.
Que viagem é essa? Pra quem usa Linux como daily driver há 30 anos desconhece bastante sobre. Primeiro que a notícia fala sobre o Kernel Linux. Ele é a base do SO. Pra se tornar um SO de fato, ele precisa ser preparado com vários softwares em torno dele. Recomendo dar uma olhada no Linux From Scratch pra entender de fato o que é o SO Linux.
O C/C++ não evolui de fato há algum tempo. A opção pelo Rust não foi porque o Linus Torvalds um belo dia acordou e resolveu que o C não servia mais e sim porque a linguagem carece de melhor estabilidade no que concerne a I/O, principalmente acesso à memória. E o Linus estava martelando em cima dos mantenedores do C/C++ não é de hoje pra que as coisas melhorassem.
E não é substituição do C/C++ por Python e Rust quem está causando travamentos na sua máquina e sim você escolher usar Fedora. Fedora desde sempre é a plataforma de desenvolvimento do Red Hat Enterprise Linux. A própria empresa deixa isso claro e explícito. Não é uma distro que preza por estabilidade. Se quer algo estável de fato a sua escolha é Debian. E se você preza por estabilidade e velocidade, então você pode mudar os programas que são escritos em Python por outros escritos em C/C++ ou mesmo Rust. O seu mecanismo favorito de pesquisas pode te auxiliar. Se não está na biblioteca da sua distro favorita, você pode instalar dos fontes ou certamente alguém já criou um repositório que inclua esse programa.
E essas “duas versões do Linux” já existem. Fica a critério de escolha. Na minha distro de uso (não sou daily driver), o Gentoo, você escolhe tornar ela Hardened, que é basicamente reforçar a segurança da distro contra ataques.
No mais: o seu relato é um exemplo da notícia: resistência ao novo. Conheço gente assim: é apegada às suas crias e não querem que elas vão embora. Sistemas em DOS que remetem à década de 1990, legado em COBOL (apesar que até hoje nenhuma linguagem tem competência suficiente pra substituir)… inerente a ser humano.
Não sou apegado não…
Só declarei um descontentamento baseado em dados reais;
Em 30 anos de Linux raros problemas com travamento;
Raros mesmo!
Nos últimos anos isso disparou!
Vários relatos de falhas no kernel…e subsistemas…
Só dar uma pesquisada…
E nos últimos anos vimos o retorno a métodos centralizados, aumento de custos, redução de desempenho, etc.
Um computador hoje tem milhares de vezes a velocidade de um 386 antigo, mas no uso em si, a coisa toda não tá tão diferente assim.
E você falou bobagem: “O C/C++ não evolui de fato há algum tempo.”, acompanho o ISO C++; Sai uma versão nova a cada 3 anos, dezenas e dezenas de novidades bacanas. Melhor denegrir com mentiras o trabalho dos outros para alavancar rust…
Você poderia tentar justificar o uso do Python apesar dos seus 4x consumo de memória e 60x consumo de processador;
mas deixa para lá…
Você poderia defender a verbosidade de Rust;
mas deixa para lá…
Ou então justificar a perda da qualidade do linux em sí!
mas deixa para lá…
E não, não vou mudar milhares de linhas de códigos…
Já tenho muito trabalho por fazer.
mas ai que tá, mesmo se o fork não der certo está tudo bem. o mundo open source sempre foi assim e sempre será, não é defeito.
e não pense que empresa grande não faz cagad@, por que é o que mais ocorre… dá pra escrever livros contando história de projetos fracassados das big techs.
mas mercado é assim mesmo.
Por falar nisso, encontrei um amigo uns meses atras e o cara tá trabalhando com COBOL… surgiu a oportunidade e abraçou. o foda é que têm muito sistema legado ainda usando e ainda é mais barato pagar pra fazer manutenção do que migrar…
Acho que é quase impossível escrever um SO usando Rust sem ter que usar os superpoderes da tag unsafe pra gerenciar memória do kernel, tanto com gerenciamento de lixo como quanto a tentativa de lidar com ponteiros do dispositivo referenciada na RAM.
Daí toda a vantagem do Rust cai por terra, que é a teoria de que é impossível fazer um double free ou ponteiro nulo, por exemplo.
Eu acho que reescrever o kernel é loucura demais, ainda mais com o tamanho do projeto e a complexidade de ter que anotar aonde está sendo usado a tag unsafe e aonde não está…
C89 com as gambiarras de compilador já é um inferno por si só, e é basicamente toda a base do Linux em si, com exceção dos drivers ocasionalmente escritos em C++.
De cara você já deu a justificativa porque o C/C++ não muda no que precisa (e o que levou a adotarem o Rust como segunda linguagem no Kernel): se o consórcio mudar o que precisa ser mudado na linguagem, é isso que vai acontecer. E adivinha: eles não querem milhares de desenvolvedores irados tendo que reescrever código. É mais fácil você viver tendo que criar código novo pra tapar falha que poderia ser evitada se os mantenedores do C/C++ atacassem o problema. Afinal hardware barateou. Pra que otimizar software pra consumir menos recursos se é só colocar remendo em cima de remendo, tornar o código um espaguete e se ficar lento aumenta o poder de fogo pra lidar com isso? MS é uma belo exemplo, aliás.
Novidade é diferente de atacar o problema. E isso eles não vão fazer nunca. Eles tem que acompanhar a constante evolução e novidades do mundo do hardware.
“Ah, Linux agora trava com frequência…” bom, com certeza a culpa não é do Rust. Volta aí no tempo onde o systemD não era padrão. Primeiro, vamos entender o que vinha anteriormente ao systemD: inicializadores. O seu computador vai bootar, o kernel é inicializado. Logo após são inicializados vários programas necessários pro SO funcionar. E isso é o inicializador: quem vai controlar quem entra em ação. Antes do systemD (cria da Red Hat e que foi amplamente adotado), tínhamos outros. E qual era o papel deles: eles entravam em ação, inicializava quem tinha que inicializar, saía de cena. Daí chegou o systemD. O que ele faz: inicializador, gestor de logs (ou journaling), trabalha lado a lado com o networkmanager pra gerir rede e por aí afora. Ou seja: ele não sai de cena depois de inicializar e ainda por cima faz várias coisas ao mesmo tempo. Ainda é duramente criticado justamente por isso: a quebra do conceito de modularidade. “Ah, mas por que ele se tornou padrão?” Simples: graças à Red Hat, que tem um bom tanto de contribuição no mundo open source, eles enfiaram goela abaixo que o GNOME 3 obrigatoriamente teria que usar o networkmanager, que só funciona se o systemD estiver ativo. Ou funcionava (já explico o que mudou). Daí, pra não ficar pra trás no bonde, geral que criava distro migrou pro systemD. E o systemD é conhecido por não ser a melhor coisa do mundo justamente por querer fazer várias coisas ao mesmo tempo. E como ele é um serviço pra várias coisas, se ele travar, várias coisas ao mesmo tempo ficam sem funcionar e você não pode simplesmente matar ele e reiniciar porque isso exige que você reinicie todo o SO (lembra que ele não saiu de cena e continua ativo)? Não tem como reiniciar ele parcialmente. Se você usa OpenRC (que era popular ANTES do systemD), ele fez o que tinha que fazer e já saiu de cena. O gestor de logs quebrou? Encerra o processo e reinicia ele. O serviço de rede quebrou? Mesma coisa. E por aí vai. Aliás, fica como exercício: experimente uma distro que ainda adota o openRC e veja se você vai sofrer com travamentos.
Quanto ao GNOME (explicando o que mudou): um sujeito criou um patch que elimina a dependência do systemD anos atrás. Agora você pode usar OpenRC. Único senão é que o monitoramento gráfico de rede no GNOME pode não funcionar direito se o networkmanager não estiver presente. Mas a não ser que você precise fazer algum tipo de monitoramento ativo e precise que sua rede/internet apenas funcione, isso é irrelevante.
O Kernel não vai ser reescrito em Rust. Isso está longe de ser um fato. O que vai acontecer é que o Rust vai entrar onde o C fica devendo em segurança. E é justamente no quesito memória. E o problema [do C] é justamente no unsafe: ele de fato é unsafe demais pros dias atuais.
Duvido muito que Rust substituirá C por completo. Rust entra em cena nas partes mais sensíveis do kernel, justamente nas partes em que a linguagem C é mais espinhoso de se trabalhar, até mesmo para desenvolvedores de longa data. Eu não gostaria de perder 2 horas do meu tempo analisando código C, se eu posso em 30 minutos escrever um código seguro com mesmo desempenho em Rust.