Mega Man X Regenesis é um novo fan game desenvolvido por Justin Ross (aka: mmxregenesis) com a grande ajuda de um grupo de talentosos artistas e lançado no dia 17 de Agosto (trabalho que levou dois anos). O jogo foi desenvolvido em Godot adicionado melhorias e modernizações gráficas, efeitos de iluminação, trilhas sonoras originais (o total de 25), reformulações de fases, fases externas e contando com oito chefes principais.
A TRAMA
O jogo se passa em uma linha do tempo alternativa seguindo eventos do Mega Man X onde Sigma venceu, X foi derrotado e a humanidade está a beira da extinção. Bem quando toda esperança parece perdida, Dr. Cain revela sua ultima contingencia, o Project Regenesis. Dada uma ultima chance para reescrever a história, X deve se levantar mais uma vez e lutar para salvar o que restou da humanidade.
COMPATIBILIDADE E RECURSOS
Mega Man X Regenesis é compatível com Linux, Windows, MacOSX, Android(que não deixa de ser Linux porém, com diferente user-space que não contem programas sob licença GPL) e esperam em breve estar disponível para Steamdeck. Vale a ressalva de suporte total a joystick. Além de uma história autoral, os oitos chefões são novos, novas armas, upgrades de armadura.
O FreeBSD 16 ainda não foi lançado (previsto para Dezembro de 2027), mas vários sites como FOSS Force, FOSSLinux, Slashdot e Phoronix veem publicando desde o dia 14 de Julho que o FreeBSD 16 conta com um dos seus principais destaques, ter removido completamente todo código fonte que seja regido sob a licença GPL da base do sistema operacional. No dia 21 de Fevereiro foi aberto o ticket D55424 intitulado "Retire dialog" que descreve:
"Esse é o ultimo restante de software GPL na base do sistema. O instalador fez transição para o bsddialog quatro anos atrás e o ultimo consumidor de dialog restante, o dpv, foi desligado mais de dois anos atrás. Aposentem o dpv, libdpv, libfigpar (utilizado apenas pelo dpv), e o próprio dialog."
"Com o diff e cdialog do GNU removidos, isso agora é apenas uma casca vazia."
Com esse commit, foi concluída a remoção completa da subtree do GNU da arvore de código fonte do FreeBSD (inclusive até das notas do arquivo README) tendo todos eles entrado para obsoletefiles.inc.
bsddialog
A equipe do FreeBSD vem fazendo este pesado trabalho ao longo de um bom tempo. Duas soluções que o FreeBSD adotou eu já apresentei aqui no meu blog, sendo elas o comando bc de autoria de Gavin Howard e que é utilizado também no Android como dependencia para compilar seu kernel (e que já reportei um bug) e o pacote libarchive que contem comandos como tar, minitar, cpio e unzip.
Migrar para alternativas sob outras licenças open-source ou remover todo código sob alguma GPL se tornou um processo natural, coisa tal que já foi feito no próprio Android há muito tempo. Nas notas de rodapé do about do toybox é descrito:
"Desde que o Android não era "GNU/Linux" de jeito nenhum, nós precisávamos limpar todos os vestígios de software gnu de sua compilação para obter um sistema auto-suficiente limpo."
Como mostro no artigo É possível que um dia Linux saia da GPL? a popularidade da GPL vem caindo cada vez mais desde de 2007 tanto para novos projetos quanto para projetos já consolidados que migraram para outras licenças. No próprio Android explicitamente se desencoraja o uso das licenças GPL e LGPL em seus produtos e gradativamente reimplementaram componentes (como sua pilha bluetooth) que estavam sob tais licenças por outros sob licença Apache (sim para quem não acreditam, o Android é uma distribuição Linux open-source). O Android ainda carrega a política de não conter nada sob GPL em seu user space; apenas em seu kernel space utiliza GPL já que que se trata do kernel linux vanilla onde não removem e nem modificam nada do kernel, apenas adicionando o que necessitam.
Já a Apple congelou o Xcode nas últimas versões do GPLv2 (GCC 4.2.1 com binutils 2.17) por mais de 5 anos enquanto patrocinava o desenvolvimento de novos projetos (clang/llvm/lld) para substituí-los, implementou um novo servidor SMB do zero para substituir o Samba, substituiu o bash pelo zsh e assim fez com toda a sua pilha de programas da base do MacOS X.
Existem até projetos que mesmo que continuem utilizando GPL em seus projetos, acabam deixando notas autorizando o uso e a promessa de não processar os usuários. Veja como exemplo a FAQ da dietlibc:
"Q: GPL é ruim! Agora eu não posso compilar meus programas BSD com a diet libc!
A: Errado. você pode compilá-los e utilizá-los. Você só não pode redistribuir os binários. Dito isso: Eu não vou processar ninguém por distribuir binários de programas BSD linkados à dietlibc, contanto que o código fonte esteja disponível em algum lugar público."
A própria Linux Foundation fundou a SPDX (System Package Data EXchange: ISO/IEC 5962:2021) para que, de forma simples de explicar, proteger legalmente os projetos evitando que eles tenham conflitos entre as licenças open-source. O toybox por exemplo, sendo regido sob a clausula zero BSD (0BSD) possui um identificador da SPDX que te direciona ao site oficial BSD Zero Clause License | Software Package Data Exchange (SPDX).
Ainda é possível utilizar software licenciado sob GPL no FreeBSD através de instalação separada (o que é algo que ocorre também no Android).
Como eu já disse no passado:
Nem todas as ferramentas que utilizamos nas distribuições Linux são do projeto GNU como alegam. A maioria são do próprio Linux* ou de outros Unix.
As ferramentas do GNU são substituíveis.
Nem toda ferramenta que o projeto GNU alega ser deles é deles de fato.
A maioria do código das ferramentas do projeto GNU é desenvolvido por outros projetos (incluindo o próprio Linux) e outras empresas, menos pelo próprio projeto GNU (foram quando não dão créditos as pessoas).
*Pois é, mentiram para você esse tempo todo alegando que Linux é somente o kernel do sistema operacional.
minibase: Um conjunto de pequenas ferramentas para userspace do Linux
Eu já apresentei vários pacotes com conjuntos de ferramentas diferentes disponíveis para Linux como o embutils de autoria do Felix Von Leitner que desenvolveu a dietlibc e que traz implementações de comandos como os do coreutils, o 9base que se trata de um port do user space do sistema operacional plan9 para os Unix, o sbase que é uma coleção de ferramentas do Unix que são facilmente portáveis para outros Unix, o ubaseque é uma coleção de ferramentas similares ao util-linux porém visando ser menor, o rustcoreutils ou uutils que é uma versão de coreutils escrito na linguagem Rust por um ex desenvolvedor do Debian, o moreutils que é coleção de ferramentas para Unix que ninguém havia pensado em desenvolver (mas que no final das contas eu também não as entendi muito bem) e o vcoreutils que é uma implementação do coreutils escrito na linguagem V além de outras ferramentas como o Busybox e o toybox que englobam vários comandos em um único binário e implementações do coreutils em outras linguagens como o nim coreutils e o golang coreutils.
Vejam quantas opções de pacotes existem para Linux além de outros que não possuem relação com o coreutils e possuem funções centralizadas como shadow-utils para criação de usuários de senhas, o procps para gerenciamentos de processos, ip-utils para troubleshooting com comandos como ping, o iproute2 e o net-tools para gerenciamento de redes e muitos mais. Linux não é limitado a ferramentas do GNU como a maioria de nós usuários de Linux costumamos propagar aos quatro ventos. Uma frase dita por Rob Landely que eu a adaptei e costumo adotar com frequência é que:
"Tudo no Linux é uma questão de alternativas e escolhas. Se você não quiser utilizar o SSH, você pode utilizar o Dropbear. Se não quiser utilizar o Apache, você pode utilizar o NginX e assim por diante".
O mesmo vale para shell, comandos, bibliotecas, compiladores, interfaces gráfica e tudo o que gira em torno o sistema operacional. É isso o que eu chamo de os vários sabores de Linux que não se trata apenas da próxima distribuição que você pretende adotar e sim de qualquer coisa que você queira utilizar no Linux. E como tudo é uma questão de escolha, o ucraniano Alex Suykov desenvolveu suas próprias ferramentas e as disponibilizou livremente sob o nome de minibase. Alex também é o autor do sninit que abordei também no artigo daemons, daemons e mais daemons init, um pequeno e estático init system para Linux.
Comandos do minibase
O minibase serve como base de comandos para userspace do Linux para ser utilizado para bootar o sistema operacional, carregar módulos, montar partições, estabelecer conexão e fornecer serviços básicos ao ponto de poder carregar interfaces gráfica com o X ou o Wayland, permitir download de pacotes e muito mais.
Os executáveis do minibase podem ser construídos com qualquer toolchain que constrói o kernel e são linkados estaticamente (ou seja, não necessitam de dependências externas). Seus binários são muito pequenos tendo entre 10KiB a no máximo 25KiB que o tornam confiáveis e fáceis de debugar. Está disponível sob a licença GPLv3 (há ressalvas feitas no próprio README) para as arquiteturas x86_64 arm, aarch64, rv64, mips, mips64 e i386.
O minibase ainda não é declarado como versão 1.0, há muito trabalho a ser feito e o autor pede para não enviarem patches ou commits. Caso queiram reportar bugs ou sugeris novas ideias, enviem solicitações.
Muito além do GNU: Os vários sabores de bibliotecas C
Alguns dias atrás me deparei com o link do site osdev.org sobre implementações de biblioteca C; trata-se de um artigo bem interessante mas muito curto. Como eu já fiz vídeos e artigos relacionados ao tema para a minha série Muito além do GNU(lembrem-se que tudo no Linux é uma questão de escolha. Escolha diz mais respeito a liberdade do que uma ideologia ou uma simples licença), eu resolvi então explorar este texto fazendo minhas observações sobre cada uma delas acrescentando mais informação e adicionando outras.
As bibliotecas C mais populares são a glibc, uclibc, musl e dietlibc; mas há um mundo muito mais vasto e amplo do que você pode imaginar e aqui vou eu abordar muitas outras. No total, até o momento eu cataloguei por volta de 18 diferentes implementações de biblioteca C.
Eu não pretendo seguir na mesma ordem que está descrita no artigo e sim na minha própria ordem; basicamente, a ordem que eu conheci ou de forma que eu considero mais coerente de explicar.
De autoria de Roland McGrath e graças aos esforços de vários projetos e empresas que a mantem para que possam utilizá-la no Linux, é uma biblioteca absolutamente completa e possui suporte a quase todas as arquiteturas. Uma observação muito interessante feita no site:
"Ela não é escrita com nada além do Linux em mente, tornando-a um port difícil."
Sim, apesar de a glibc ser uma biblioteca do projeto GNU, tecnicamente a glibc é uma biblioteca do Linux. Isso ocorreu porque no inicio dos anos 90 os desenvolvedores de Linux perceberam que glibc carecia de muitos recursos necessários para Linux e assim eles criaram um fork da versão 1.x que foi nomeada simplesmente libc e que conhecemos como libc4 que foi a ultima com suporte ao padrão a.out, a libc5 (/lib/libc.so.5 a primeira a ter suporte ao padrão ELF no lugar do a.out. Há algumas fontes que afiram que havia código da bibliotecas C do 4.4BSD, mas o link do projeto gnu não está mais disponível) e libc6 (/lib/libc.so.6) e foram o padrão nas distribuições Linux durante um bom tempo. A glibc 2.0 surgiu da libc6 e com o tempo, por uma questão de padronização, as distribuições voltaram a utilizar a glibc. Mais informações da libc5 e libc6 podem ser lidos clicando aqui. Já para saber mais sobre libc4, libc5 e libc6 consulte a manpage (man 7 libc).
Houve também a Eglibc que foi uma variante da glibc fortemente focada em embarcados e com uma série opções e de suporte a arquiteturas que a glibc não possuía (especialmente PowerPC). A Eglibc foi a biblioteca padrão do Debian 5 e possuía suporte de um consorcio. O código da Eglibc foi fundido ao código da glibc na versão 2.20.
No final das contas a GlibC se beneficiou muito do Linux assim como quase todas as ferramentas do projeto GNU. É difícil prever a linha do tempo das ferramentas GNU sem o Linux.
Uma das grandes desvantagens da glibc podemos mencionar é o fato de gerar binários muito grandes. no artigo Analisando 6 diferentes implementações do comando sed eu descrevo uma curiosidade relatada por Rob Landley que, um simples código "hello World" linkado estaticamente à glibc, gera um binário de 400k... Não é a toa que os desenvolvedores de embarcados se declaram inimigos mortais da glibc.
E a outra desvantagem é estar sob a licença GPL que está em decadência desde 2007por ser uma licença muito restritiva (até hoje não entendo o conceito de liberdade em algo tão restritivo. Algo totalmente incoerente).A criação da GPLv3 foi uma corda no pescoço da licença e já houveram planos no passado para migra a glibc para a terceira versão. Ainda bem que isso não ocorreu pois geraria um grande colapso nos projetos.
uClibc (pronuncia-se yew-see-lib-see) é uma biblioteca para Linux em embarcados no projeto µClinux. Bem menor do que a glibc porém com suporte a quase todas as suas aplicações e quase todas as arquiteturas (alpha, amd64, ARM, Blackfin, cris, h8300, hppa, i386, i960, ia64, m68k, mips/mipsel, PowerPC, SH, SPARC e v850).
Foi escrita do zero por Erik Andersen, ex mantenedor do Busybox (que passou a bola para Rob Landley, autor do terminal de comandos toybox), iniciando em 1999 tendo apenas algumas partes de código derivados da glibc como pthreads (threads do Linux, o mesmo recurso que querem fazer uso dentro do sistema operacional RTOS X5) e o suporte a números randomicos.
O uClibc foi descontinuada por volta de 2012 e criaram um fork chamado uClibc-ng. Aé aonde se sabe, existem poucos mantenedores da uClibc-ng, ou talvez somente um, sob o argumento que é a única que possui suporte a algumas plataformas de hardware antigos.
Musl já apareceu várias vezes tanto aqui no blog quanto no canal. É construída sobre a API do Linux e a API POSIX e tem como princípios a simplicidade, eficiência de recursos, atenção em correções, segurança sob exaustão de recurso, fácil deploy e suporte de primeira classe para textos UTF-8/multilingual. A musl permite gerar binários menores (mesmo linkados estaticamente) e rápidos. Rich Felker criou o conceito Quality Safe Code; o que leva a biblioteca a ser correta no quesito conformidade e segurança.
Com o fim da uClibc e depois de ter péssima experiência com programas linkados a outras bibliotecas (seja de forma dinâmica ou estática) que apresentaram falhas, Rich Felker desenvolveu a musl como uma alternativa a glibc e a Uclibc para oferecer melhor experiência no uso de aplicações linkadas estaticamente (tanto no conceito de segurança quanto eficiência) em embarcados, servidores de desktops.
Inicialmente esteve sob a licença GPL porém, depois de conversa com Rob Landley (autor do toybox) passou a disponibilizar a musl sob a licença MIT. Hoje a musl é utilizada como padrão nas distribuições Alpine Linux que é inclusive utilizada nas imagens Docker; Adelie Linux que é baseada no Gentoo Linux e eu pretendo fazer um vídeo de Os vários Sabores de Linux; Void Linux que foi criada para implementar os gerenciador de pacotes xbps (haja coragem); Alpaquita Linux criada pela empresa Bell soft para a execução de aplicações Java; Glaucus Linux que, diferente da distribuição Alpine Linux, faz uso do toybox como userspace ao invés do busybox (tive a honra de receber seu autor no meu canal) e há planos para a sua adoção no Debian e no Android.
Possui em torno de 1200 funções além de todo um conjunto de funções matemática e de printf, porém ainda faltam system calls para serem implementadas. Natanael Copa, autor da distribuição Alpine Linux descreve em sua palestra o que é necessário para substituir a glibc pela musl. Foi a primeira biblioteca a adotar mutexes safe que o pessoal considera incrível, condvars e a primeira a ter working thread cancellation sem race conditions (todos recursos que foram ignorados por outras implementações).
De autoria do alemão Felix von Leitner, foi criada com foco em otimização de tamanho dos binários assim como a musl e cumpre muito bem esse papel. Eu mesmo já fiz analises tanto no canal quanto aqui no blog compilando o embutils, o minised e o init systemrunit e os resultados de sua otimização de binários são surpreendentes. Há um vídeo no meu canal onde relato a sua história e recursos interessantes.
skalibs é um pacote que centraliza bibliotecas C pequenas e seguras utilizadas para a construção de todos programas da skarnet.org. A ideia é não ter que baixar e compilar bibliotecas grandes e se preocupar com problemas de portabilidade. skalibs está sob a licença ISC e pode ser baixada através do comando
Newlib é uma biblioteca fortemente focada em embarcado. Alias, essa é uma das bibliotecas mais amada pelos desenvolvedores de embarcados. É utilizado até mesmo pelos amantes de Dreamcast (e eu não gosto, né). Ela conglomera várias partes de biblioteca sob licenças open-source. e em seu site oficial só é disponibilizada na forma de código fonte.
Possui suporte a mais ou menos 400 funções e requer threading. Nesse embalo surge a Relibc.
relibc é uma biblioteca C POSIX escrita em Rust. De origem do sistema operacional redoxOS e possui port para Linux. Foi desenvolvida para ser uma alternativa a newlib (por isso coloquei nessa ordem) no RedoxOS e também possuir suporte a system calls do Linux (se system calls Linux tem muito bem) por meio do sc crate.
Bionic é a principal biblioteca do Android; foi construída com porões de bibliotecas do NetBSD, do OpenBSD, porções de bibliotecas de FreeBSD e partes próprias. Está sob a licença BSD para evitar os conflitos que vem ocorrendo com a GPL; existe até uma política do Android de não haver programas sob GPL no user space do Android.
Possui suporte a arquiteturas ARM e depois foi estendida a x86 além de suporte a interfaces do kernel Linux. existem algumas limitações como não possuir suporte a locales (até aonde me lembro, a musl também não possui quando tentei compilar o htop que descobri isso), a libthread_db ou libm e possui sua propria implementação pthreads baseada nos futexes do Linux. Existe um relato do Rob Landley que para poder executar o X11 no Android, seria necessário reescrever várias parte do X11 para ser compatível com a Bionic.
olibc (Another C Library optimized for Embedded Linux) derivada da bionic, o objetivo da olibc é fundir as melhorias feitas por várias empresas de SoC como a Qualcomm, Texas Instruments, Linaro, etc. A olibc pode se beneficiar de recursos do ARMv7 como NEON, Thumb-2, VFPv3/VFPv4 e as ultimas otimizações de recentes versões dos compiladores.
PDCLib (ou The Public Domain C Library) visa fornecer uma implementação completa do padrão C99 (nada mais, nada menos do que definido no ISO/IEC 9899. Nem mesmo outras extensões como POSIX) sob a licença CC0 ("No rights reserved").
Foi desenvolvida originalmente por Martin “Solar” Baute em 2002 e depois de 10 anos, Erin Shepherd assumiu o desenvolvimento até 2018 que implementou muitos recursos significativos (o currículo da Erin é incrível). Em 2018, Martin retornou ao desenvolvimento da PDClib.
Não confunda PDCLIB (The Public Domain C Library visto anteriormente) com a PDPCLIB (Public Domain Project C Library. Um P a mais e pode confundir dois projetos). Essa biblioteca faz parte do projeto PDOS (Public Domain Operating System) que se trata (digamos) de um clone antigo MSDOS. (mas com suporte tanto a 32 bits do Windows e do MSDOS. Há uma de suas distribuições com suporte a API MVS API em AMODE de 24, 31, 32 e 64 bit).
A PDPCLIB é biblioteca do PDOS que visa ser uma biblioteca C que visa junto ao GCCMVS (um port do GCC para mainframes da IBM) produzir binários sem restrições devido a sua licença (domínio público). A PDPCLIB segue os padrões da ISO/IEC 9899:1990 (aka ANSI X3.159-1989 aka C90 aka C89) e funciona não somente no MSDOS, no Win32 e no PDOS/386 mas também no OS/2, MVS (mainframe), CMS, VSE e AmigaOS.
Escrita em C++, mlibc tem como foco ser totalmente portável e na modularidade. mlibc possui uma variedade de recursos POSIX/Linux/ANSI e é capaz de executar vários programas como Weston, GCC, LLVM, Bash, GTK2/3 e muitos outros mas sem perder o foco na portabilidade (assumindo poucas systemcalls do sistema operacional hospedeiro). Está sob a licença MIT.
Como o próprio nome já menciona, é focada em ser escrita totalmente na implementação do padrão C11 (ISO/IEC 9899:2011) e nada mais. Está sob a licença unlicense (public domain), teve seu inicio em 2014 porém seu desenvolvimento anda bem parado. Seu antigo site (http://libc11.org/) está fora do ar, mas existem alguns repositórios git que podem ser encontrados.
Na computação, klibc é um subconjunto minimalista da biblioteca C padrão desenvolvida por H. Peter Anvin. Ele foi desenvolvido principalmente para ser usado durante o processo de inicialização do Linux e faz parte do espaço inicial do usuário, ou seja, componentes usados durante a inicialização do kernel, mas que não são executados no modo kernel.
Essa é uma biblioteca do kernel Linux. Foi adicionada ao kernel 5.0 no commit 66b6f755ad45como umabiblioteca mínima que fornece emulação de baixo nível quando o Linux for inicializado somente para executar um único e minúsculo programa.
Foi criado por Paul McKenney ao trabalhar para reduzir o tamanho do initrd (que é de 40MB) e do initramfs (que é 10MB) gerados pelo comando mkinitramfs e pelo dracut onde a maioria das coisas eram inúteis. Assim, eliminando o que não era necessário para o dash (e a maioria eram coisas relacionadas a biblioteca), Paul conseguiu reduzir para ~2MB.
Neatlibc foi desenvolvida pelo iraniano Ali Gholami Rudi para focar principalmente em bootstrapping de seu compilador neatcc. a neatlibc possui suporte as arquiteturas x86, x86_64, ARM de 32 bits; há muitas funções que não são implementadas na neatlibc mas a maioria dos programas desenvolvidos por Ali (http://litcave.rudi.ir/) podem ser compilados com o neatcc e linkados a neatlibc.
Escrita do zero para o sistema operacional Sortix OS, foi implementada grandes partes do padrão POSIX que permite ter suporte a ~70 partes de software de terceiros.
Libslack é uma pequena biblioteca de utilidades gerais que foi projetada com uma coleção de módulos e várias funcionalidades para torar a programação no UNIX/C um pouco mais fácil. A principio foi implementada para ser parte do programa daemon embora alguns códigos datam de antes do do daemon. A libslack possui vários recursos que podem ser conferidos clicando aqui. Está sob a licença GPLv3 e disponível para Linux, Solaris/OpenSolaris,OpenBSD, FreeBSD, NetBSD, MacOSX/macOS, kFreeBSD e GNU/Hurd.
MyOS libc
E por ultimo temos a myOS libc que resumidamente seria você mesmo desenvolver sua própria biblioteca C. A ideia é servir como uma das soluções mais óbvias implementando os recursos personalizados que precisa a seu kernel e ao resto do sistema operacional sem camadas de portabilidade. Outra parte interessante seria a melhor integração com funcionalidades do seu hardware.
O artigo não inclui o link para o desenvolvimento da biblioteca, então eu resolvi adicionar por conta própria.
PuzzleFS é um novo sistema de arquivos projetado especificamente para o emprego de containers. De autoria do engenheiro de software romeno Ariel Miculas que trabalhar na Cisco, se inspirou no filesystem de Wedson Almeida Filesystem, o puzzlefsfoi projetado para solucionar problemas de limitações existentes no formato OCIv1 como tamanho dos arquivos seja com ou sem compressão junto com o fs-verity para garantir a integridade. Para isso, Ariel Miculas utilizou o design do OCIv2 que soluciona muitas das falhas da versão anterior e que podem ser lidas aqui.
O principal foco do projeto é reduzir a duplicação, o que até então não há nada de novidade como pode ser Llido aqui no blog sobre deduplicação). O que pode ser o diferencial é a técnica utilizada no puzzlefs que no caso é o algoritmo FastCDC.
O puzzlefs foi desenvolvido na linguagem Rust para fazer uso de segurança de memória (o que na verdade também é possível com outras linguagens né, mas está valendo).
E por ultimo, o puzzlefs compartilha o mesmo código entre user space e kernel space. Atualmente só é possível o puzzlefs através do FUSE (userspace filesystem).
É incrível como funciona o emocional do pessoal apaixonado por software livre. Se não estão decretando empresas como inimigas mortais, ou abominando o systemd ou criticando o btrfs, eles estão exaltando o projeto gnu como único e absoluto, o ZFS como sistema de arquivos indestrutível e insuperável, acreditando que o FreeBSD é superior a qualquer outro sistema operacional (eu já recebi vídeo assim hein, UFRS) e agora a bola da vez é dizer que a linguagem Rust irá substituir a linguagem C. E o argumento por traz de tudo isso é que a linguagem Rust trabalha melhor com gerenciamento de memória e... só... OK, está certo que isso não é pouca coisa; Em Setembro de 2024 foi publicado que o fato de o Google ter feito a transição do código do Android para Rust fez suas vulnerabilidades em memória caírem de 76% para 24% porém, por outro lado, portar o yash para rust não apresentou ganho nenhum.
Os desenvolvedores do kernel queriam adicionar suporte a linguagem Rust no kernel e, apesar de Linus ter sido resistente quanto a ideia e até mesmo ameaçar os desenvolvedores que fizessem isso, o kernel passou a ter suporte a Rust como segunda linguagem... O motivo é até simples, para atrair novos desenvolvedores para o kernel Linux (logo para essa geração que o forte deles não é estudar...).
O Zabbix Agent2 passou a ser escrito na linguagem Go. O motivo explicado pela comunidade é que fica melhor para integrar seus plugins e de forma mais modular mas vale a ressalva que partes do código do Zabbix Agent2 ainda é escrito em C. E assim vemos vários projetos fazendo adoção da linguagem Rust.
O que eu me pergunto é, será que estamos no caminho certo? Será que isso não acabará solucionando um problema e causando vários outros ainda mais graves? Essas são as perguntas que devemos (ou ao menos deveríamos) nos fazer antes de começar o trabalho.
E no meio de toda essa euforia, de muita gente que não entende de nada sobre linguagem de programação e outros tantos que também não leem nada sobre o assunto, vamos tratar de um assunto que quase ninguém prestou a atenção e que na verdade é o tema principal deste artigo.
O QUE NÃO TE CONTAM SOBRE A LINGUAGEM RUST
Ao meu ver Rust solucionará certos problemas, mas outros não (muito menos solucionará todos como andam fantasiando). O problema é que todo mundo focou somente no prós da linguagem e esqueceram dos contras. É questão de saber quando, aonde e a que custo adotá-la.
Um ótimo exemplo disso, o projeto Warp (um terminal escrito em Rust disponível para MacOS mas com planos para ser portado para Linux e Windows) que apresentou o tamanho da dificuldade de implementar UI (User Interface = Interface de Usuário) ou GUI (Grafical User Interface) utilizando a linguagem Rust:
O segundo exemplo apresentando pelo projeto Warp foi utilizando o Timer da 7GUI e a dificuldade que é enfrentada para conseguir algo tão simples com Rust.
A equipe desenhou um mapa explicando como todo o projeto ficaria e que essa abordagem de árvore não mapeia claramente para Rust. Uma série de erros iriam acontecer e tornariam o trabalho mais difícil para projetar um único componente e adicionar uma simples função em sua estrutura.
Um outro bom exemplo de dificuldade GUI em Rust é o emulador Obliteration que a equipe do projeto reescreveu o seu núcleo de emulação em Rust enquanto que a interface gráfica é desenvolvida em C++ (utilizando o framework QT).
O código e razoavelmente mais legível (mais do que a versão em Rust)
Muito menos LOC mesmo com mais recursos adicionados (comparado com a versão Rust)
O código foi escrito um montante de tempo razoável (muito menos do que a versão Rust, novamente a reescrita em si levou em torno de um mês, mas a velocidade que recursos mais novos foram adicionados é algo entre 4 a 8 vezes mais rápido do que o tempo que leva para implementa-los em Rust, provavelmente por conta que eu me aborreço com Rust mesmo depois de um ano de uso, mas quem sabe...)
menos uso de recursos do sistema (1/3 do que a versão em Rus utiliza)
Executável muito menor (200 a 300 KB. Comparado a versão em Rust que é de 3 MB)*.
Pode ser construído utilizando toolchain existente no Glaucus porque Nim transpila para C; assim, tornando o uso de toolchain otimizada pelo Glaucus (diferente de Rust que é muito difícil de fazer bootstrap**, e não funciona tudo tão bem assim com musl compartilhada...)
Um pouco mais rápida (em analise, é por volta de 6 - 20% mais rápido no geral. Provavelmente porque eu odeio Rust mesmo depois de um ano utilizando, mas novamente eu estou escrevendo em Nim em apenas um mês ou dois...)
*Eu como administrador de sistemas utilizando programas escritos na linguagem Rust, sim eu constatei que executáveis em Rust são maiores e conseguiram apresentar problemas e menor desempenho. No artigo uutils: Um coreutils escrito na linguagem Rust eu acabei fazendo a observação que o uutils, com apenas 87 comandos e sendo linkado dinamicamente, ocupa mais de 12MB enquanto que o toybox 0.8.9 consegue ser 17 vezes menor ocupando apenas 724KB mesmo contendo 233 comandos (é mais de duas vezes e meia a quantidade de comandos do uutils) e ainda sendo linkado estaticamente (o que, pela lógica, o tornaria maior e foi ao contrário). Veja o resultado na imagem abaixo
Ainda podemos ressalta o PX5 RTOS, um sistema operacional Real Time que é novo, moderno e que vai atender as necessidades atuais do mercado. O PX5 é quase totalmente (99%) escrito em C. O motivo é que C o torna altamente portável para qualquer arquitetura de processador e por conta disso, o PX5 possui suporte a maioria das arquiteturas de embarcados MCU e MPU populares incluindo as famílias de arquiteturas ARM's Cortex-M, Cortex-R, Cortex-A e RISC-V.
E aqui vai a minha pergunta, porque ninguém pensou em adotar a linguagem Nim como segunda linguagem no kernel ao invés de Rust? Drivers, sistemas operacionais (existe até mesmo um kernel escrito na linguagem Nim, o NimKernel e que ainda pretendem trabalhar em um Nim OS no futuro), embarcados e até Internet of Things (IoT) podem ser escritos em Nim. Nim possui a característica de memory safety ativa por padrão, faz o gerenciamento de memória através do suporte a diferentes tipos de garbage collectors com diferentes aplicações em mente além de lhe permitir trabalhar com gerenciamento de memória manualmente. Vocês puderam ver o projeto Glaucus se tornar muito mais eficiente com Nim do que com Rust. Por que ninguém pensou ou sugeriu isso?
Gerenciamento de memória na linguagem C?
O que todos hoje temem a respeito de gerenciamento de memória em linguagens de programação como C e C++ na verdade é uma característica das duas linguagem e não uma falha; elas permitem que os programas tenham acesso direto a memória. O problema é que essa característica pode levar a certos desastres permitindo que programas que não foram atribuídos para esse uso acessarem memória. Já linguagens que recorrem ao recurso memory safe fazem isso ao custo de não permitir que programas acessem detalhes de baixo nível da memória que em alguns casos são necessário e também degrada o desempenho dos programas.
Recentemente que foi adotado C11 no Linux. O que me leva a questionar se estamos no caminho correto. O que seria mais vantajoso? Reescrever códigos de uma linguagem para outra ou escrever patches usufruindo dos reais recursos da linguagem?
Pode ser que de repente alguém ou um grupo de pesquisadores desenvolvam algoritmos ou simplesmente façam uso de algoritmos já existentes e solucionem esse "problema". Veja como exemplo a biblioteca Newlib; um desenvolvedor da empresa ARM desenvolveu um patch que melhora o desempenho da biblioteca baseando-se no algorítimo Horspool da universidade de Helsinki (o berço do Linux ;). Parte do algoritmo pode ser conferido na imagem abaixo; são algoritmos assim que acabam surgindo até de forma inesperada.
Mais exemplos de algoritmos que solucionaram problemas e que quase ninguém imaginava que um dia seriam capazes, não nos faltam como é o caso do Btrfs pois sistemas de arquivos CopyonWrite são incompatíveis com Btree (o ZFS é incompatível com Btree; o HAMMER em sua primeira versão era Btree e não possuía suporte a CopyonWrite mas em sua segunda versão se tornou CopyonWrite e automaticamente não possui mais suporte a Btree; o Ext4 é Btree e também não possui suporte a CopyonWrite; o NTFS é Btree e faz uso shadow por conta desta incompatibilidade). Mas o que tornou o Btrfs Btree e CopyonWrite? Os algorítimos escritos por Ohad Rodeh da IBM de Haifa que permitiu que essa fosse uma das características do Btrfs e hoje herdado pelo BcacheFS.
Outro exemplo é o algoritmo malloc (abreviação de memory allocator). O artigo da Etalabs chamado O que é Overcommit? E por que ele é ruim? descreve que "existem mal entendimentos a respeito de gerenciamento de memória no Linux que acabam levando a muitos programas ruins falhar em lidar de forma robusta com condições de pouca memória. Grande parte dessa falha de gerenciamento de memória na linguagem C está relacionada a forma como os programas são escritos (vale lembrar que bibliotecas como dietlibc e musl possuem recursos para auxiliar desenvolvedores a escrever códigos melhores. Na bibliotec musl surgiu o conceito de Quality Safe Code e a própria musl possui recursos de debug).
Comparação de desempenho entre glibc e musl sem malloc
Comparação de desempenho entre glibc, musl e malloc-ng
Comparação de desempenho entre glibc, musl, malloc-ng e musl+mimalloc
Todos os detalhes sobre o desempenho do algoritmo malloc podem ser conferido no linkedin do Emerson Gomes. Vale acrescentar que no elinux de 2022 descreve que Rust no kernel é um problema difícil de solucionar pois, programas escritos em Rust normalmente não lidam com falhas de alocação de memória (estranho a maior propaganda da linguagem Rust ser segurança de memória e não tratar do ponto de alocação de memória) e sofre também com muitos recursos que ainda são INSTÁVEIS.
E o terceiro exemplo é o novo recurso _FORTIFY_SOURCE que foi adicionado no GCC e no LLVM/Clang. Esse recurso é uma macro de pré-processamento que garante um nível extra de segurança para as linguagens C e C++ detectando erros durante o processo de compilação e de execução já que, como descrito no link da Red Hat, programas escritos na linguagem C rotineiramente sofrem com problemas de gerenciamento de memória. O _FORTIFY_SOURCE detecta mais buffer overflows e bugs que mitigam problemas de segurança na aplicações em tempo de execução. Além do mais, existe Garbage Collector para as linguagens C e C++ desenvolvido por Hans-J. Boehm. Ou SEJA! sim, existe o recurso de segurança de memória para a linguagem C ;)
Garbage Collector para as linguagens C e C++ de autoria de Boehm-Demers-Weiser
Pode ser que a versão C25 ou C26 surja com as exatas características da linguagem Rust que todos enaltecendo. Eu acredito que Rust irá substituir C? Não! Eu acredito que cada linguagem será adotada em campos que cada uma possui melhor atuação.
Diziam que o o kernel monolítico era obsoleto e que o microkernel iria substituí-lo; já se passaram quase 40 anos e ainda nada. Diziam que php estava morrendo, diziam até que php estava sendo substituído por Java (uma linguagem que não tem nada a ver com a outra), contudo php está bem forte no mercado e Java declinando.
O que temos que entender é que em cada linguagem existem suas vantagens e desvantagens. Cabe a nós saber quando desfrutar de cada uma nos momentos exatos.
.png)
.png)
%20-%20Redimensionada%20(60%25).png){kind=tracking}
.png){kind=link}