No dia 23 de Fevereiro de 2026 , o time da linguagem Nim anunciou o lançamento da versão 2.2.8, o quarto patch release para a versão 2.2 adicionando 89 commits trazendo correções de bugs (o total de 39 correções) e melhorias. A correção mais importante foi a parte de código multi-threaded pesado que torna o alocador mais estável, mas ainda querem trabalhar para ter o -d:userMalloc.
D-Bus é um sistema de comunicação de inter-processo (em inglês = inter-process communication ou IPC) que é utilizado como uma das dependências do systemd para ativação de serviços. Não somente pelo systemd, porém o D-Bus é utilizado por vários outros serviços como durante durante o processo de instalação gerando um número de identificação para a máquina através do D-Bus machine id. Máquinas virtuais também dependem o D-Bus machine id ainda mais em casos de geração de templates que podem precisar de um novo D-Bus machine ID para garantir que recursos do sistema do hypervisor sejam instruídos para o guest correto. O comando dbus-uuidgen --get é utilizado verificar o id das máquinas enquanto que o comando bus-uuidgen --ensure é utilizado para validação sendo o dbus-uuidgen --ensure=/etc/machine-id é utilizado para gerar novo id após remover o link simbólico /etc/machine-id tendo origem em /var/lib/dbus/machine-id (fica aí essa dica para a LPIC1).
Ferramentas do D-Bus
O Varlink também é um sistema de comunicação de inter-processo porém, sendo um protocolo que visa tornar os serviços acessíveis tanto para humanos quanto para máquinas do jeito mais fácil possível fazendo uso de arquivos de texto para descrever interface com todos os tipos de dados, metodo e etc.; não faz uso de números mágicos ou valores sem nomes, é fácil de debugar com qualquer ferramenta.
"Eu não sou um grande fã do D-Bus, mas eu sou um grande fã de mensagens" ... "logs binários não é uma coisa ruim desde que você tem as ferramentas para separá-las, mas gosta de mensagens".
Mas o motivo que o Varlink está sendo adotado no systemd no lugar do D-Bus não está relacionado a coisas como logs serem ou não binários e sim por questões de limitações sendo uma delas só estar disponível após o processo de boot, demora na implementação de novos recursos, complexidade, o fato de utilizar somente serialização, não podendo ser utilizado em muitos serviços básicos, performance baixa dentre outros problemas. Todos os detalhes podem ser conferidos na apresentação do Lennart no FOSDEM deste ano:
Hack no emulador PCSX2 melhora profundidade na resolução dos jogos da SNK.
Recentemente foi publicado que uma nova hack foi adicionado à ultima versão do emuladorPCSX2 que soluciona um problema gráfico 3D em 99% dos jogos da SNK. Essa hack permite que o limite de profundidade seja de 24 bits permitindo jogar em telas de alta resolução sem bugs nos cenários. A noticia pode ser lida no próprio site do projeto clicando aqui e um vídeo pode ser conferido abaixo:
Você não leu errado, algo que parecia tecnicamente impossível foi feito. Um desenvolvedor conhecido como XL2 postou um vídeo demonstrando uma solução para rodar raytracing nos jogos do Sega Saturn. Isso sim é o que chamamos de tirar leite de pedra quando um desenvolvedor talento resolve extrair o real potencial do hardware.
XL2 é conhecido por já ter feito um "port impossível" do primeiro Unreal da Epic Games, mas parcial, e a demo pode ser baixada clicando aqui. Neste vídeo em seu canal, XL2 descreve como a técnica é realizada:
"Aqui está um teste de raytracing em um quarto pequeno. A função é bem pequena e poderia ser otimizada mais adiante: Eu simplesmente testo todas as vértices utilizando o BSP. A fonte de luz é, para o teste, simplesmente a posição da ultima fonte ativa dinâmica de luz (então praticamente o ponto de impacto da dispersion pistol). Raytracing não afeta entidades ainda, mas essa parte deve ser super fácil (um simples raio para testar se eles são afetados ou não).
O comodo que você vê não tem luz estática, mas o raytracing pode ser usado para adição de luzes dinâmicas no topo das fontes de luz estáticas. Eu só atualizo um quarto das vértices por quadro. Quando um vértice falha no teste, eu escureço suavemente de volta para 0. Quando ele passa, fica totalmente brilhante imediatamente. Não faço nenhum teste sofisticado agora para a luz (como usar a normal da superfície ou a distância da luz), assim ele poderia parecer melhor com um pouco mais de matemática. Agora, para luzes indiretas: eu mantenho um PVS por face de qual rosto afeta quais outros rostos. Só preciso encontrar uma maneira de integrá-lo a uma velocidade razoável no Saturn."
Essa é na verdade somente uma prova de conceito para explorar o real potencial do console; isso sim é o que chamamos de tirar leite de pedra. Bom, posto este artigo já estou expandindo o canal e blog para a parte técnica dos consoles e a pedido de um dos inscritos do canal, ainda debaterei sobre o Sega Saturn.
Em 2024, Ray Gardner com contribuição de Oliver K. Webb disponibilizaram o wak, uma implementação POSIX compacta da linguagem de programação awk para o toybox ou para poder também ser utilizado como standalone. O professor Nelson H. F. Beebe da Universidade de Utah também está envolvido em seu desenvolvimento dando conselhos relacionados a melhorias do programa e do uso do makefile.
O wak é mantido sob a clausula zero BSD (BSD0) para manter dentro dos padrões de licença do toybox porém, como os arquivos do diretório test pertencem ao gawk 5.3.1, então estes arquivos são mantidos sob a GPL2. O código é escrito em C99 (exceto o recurso anonymous unions) tanto no GCC quanto no Clang mas também é possível compilar o wak com TinyCC. Report de bugs são sempre bem vindos.
A IMPORTÂNCIA DE AWK
Ao longo do tempo, awk foi perdendo espaço para outras linguagens como Python e Perl, porém a especificação POSIX e especificalmente a Single UNIX Specification (SUS) determinam que todo sistema operacional que declaram ser um Unix (ou totalmente POSIX) deva disponibilizar uma versão de awk compatível com a POSIX para assim ser oficialmente Unix legítimo e certificado. Essa exigência está relacionada a awk fazer parte do conjunto de comandos necessários para tornar scripts portáveis entre outros Unix.
Além do mais, awk é uma das dependências para se compilar o kernel Linux pois é utilizado por vários build scripts e configurações. Enquanto compiladores e outras ferramentas são responsáveis por gerar os binários, awk e outros comandos são responsáveis pela parte de scripts que tratarão de informações como saber os ranges de memória, preempção do kernel e muito mais.
" Estou imaginando que dd, expr, tr, awk, sh, bc, bison, flex, make, ar, e gzip são necessários para construir o kernel..."
E continuamos em seu roadmap a série de comandos necessários para construir um ambiente mínimo de uma distribuição capas de bootar o sistema executando init scripts e outros shell scripts e oferecer uma sessão do shell.
A intenção é oferecer ferramentas necessárias para o Android ser capaz de compilar o kernel Linux e suas próprias ferramentas.
Linguagem Go utilizada para rodar Diablo no Dreamcast
O Gerente de engenharia de software da Red Hat, Panagiotis Georgiadis escreveu eu seu perfil no X:
"Eu tornei possível escrever código golang para o Sega Dreamcast. Sim, o console de 1999. Sim, Go de verdade com gorotines e channels. Aqui está uma intro de Diablo rodando no hardware real."
Panagiotis descreve que Golang para Dreamcast fornece as mesmas características (garbage collection, goroutines, channels e as funções do core runtime) mas que substituiu o runtime padrão do Go por um uma implementação mínima (o libgodc) projetada especificamente para o Dreamcast de acordo com as especiações: e sem sistema operacional¹.
Limitações
Panagiotis disponibilizou uma documentação sobre as limitações da biblioteca libgodc que é essencial entender para escrever programas Go para Dreamcast.
Algumas de suas limitações estão relacionadas no total de memória RAM (apenas 16MB de RAM sendo distribuídos para o KOS, seus drivers e malloc; GC; pilhas; seu código. Ele não possui memória virtual, não possui swap, e não possui segunda chance e caso ocorra de ultrapassar esse limite, o jogo crasha), o processador ser single-core SH-4 operando a 200MHz; os tempos de pausa que o garbage collection podem levar cada frame leve 16.6ms ou até causar stutter; pilhas fixas a 64k; sem Parallelismo (M:1); é Cooperative e não preemptive; alguns recursos não implementados ou algumas implementações limitadas. Há mias detalhes sobre limitações que podem ser lidos aqui, mas apesar destas diferenças, podemos escrever código go normal, as rotinas go funcionam, channels, mapas, slices, interfaces funcionam.
O Go runtime para Dreamcast depende do gccgo e do KOS (KallistiOS).
O Go para Dreamcast está disponível sob a clausula 3 BSD porém, algumas partes estão sob outras licenças como o brkout (que é um port Go do jogo original desenvolvido por Jim Ursetto) que está sob GPLv2.
Eu como um apaixonado por Dreamcast fico muito feliz de ver a galera de Linux envolvida com o console.
Em minha palestra A evolução do Linuxeu conto a origem do X11 no Linux que foi uma coisa muito interessante já que foi esse servidor gráfico que deu origem ao primeiro protocolo de redes no Linux. Em Outubro de 2021 eu escrevi o artigo O fim da estrada para o x11 descrevendo o estado atual o X11, o seu destino e seu eminente fim.
Com o tempo surgiu um "salvador da pátria" (assim como foi o Rocky Linux...) anunciando um fork chamado XLibre e como sempre, a galera movida a paixões por software livre comprou a briga sem saber quase nada do assunto. Parece que o desenvolvedor vem fazendo algum progresso, o que me leva a perguntar por que não havia feito isso antes das distribuições fazerem adotação em massa do Wayland...
E agora, entre essa "guerra" Wayland X XLibre, surge o Phoenix. Phoenix é um novo servidor gráfico X projetado do zero (e não um fork do Xorg) escrito na linguagem Zig e projetado para ser uma alternativa moderna ao Xorg. O Phoenix ainda não está pronto e até o momento o Zig X Server renderiza somente algumas aplicações simples.
A equipe visa ter um servidor gráfico com foco em simplicidade, segurança, melhorias tanto para tecnologias modernas quanto para parte gráfica, compatibilidade com o Wayland e estender o protocolo X11. Existem diferenças fundamentais de implementação entre o X11 e o Phoenix. O Phoenix está sob GPLv3 (não sei o que passa na cabeça da galera) e a galera vem trabalhando neste servidor gráfico desde Julho. É esperar para ver se o projeto vinagrá.
No dia 31 de Outubro foi anunciado o lançamento da versão 2.2.6 da linguagem Nim depois de seis meses do lançamento da versão 2.2.4. Essa versão contem 141 commits trazendo 53 correções de bugs e melhorias. Uma dessas melhorias está no desempenho que já era bom, agora o compilador é esperto para produzir uma operação para retorno de obj.field que anteriormente ele fazia uma cópia. O async do Nim está mais estável por ter sido reeescrito.
No dia 14 de Outubro foi lançada a versão 0.8.13 do terminal de comandos toybox.
NOVOS COMANDOS
Foram adicionados os comandos nologin e hd. O comando hd inicialmente não possui opções, apenas saída o tradicional de 16 bytes por linha hex+ascii. Essa nova versão trás também a substituição do antigo kconfig/*.c plumbing (que data da época do kernel 2.6) por um novo scripts/kconfig.c que entre outras coisas, permite construir no MacOS sem a necessidade de homebrew e adiciona suporte trap e alias ao toysh.
Comandos hd e nologin no toybox 0.8.13
NOVOS RECURSOS AOS COMANDOS
O comando chmod recebeu as opção -cv; o comando kill com a opção -l pode gerar uma lista de múltiplos sinais; o comando taskset recebeu a opção -a como um alias para a opção --all e utilizar essa opção sem argumentos exibe o mask atual; o comando dd recebeu as opções oflag=append, oflag=direct, conv=nocreat e iflags=direct; os comandos xargs e pgrep receberam a opção -a; o comando lspci agora suporta offsets de de registradores maiores; o comando log recebeu a opção -b; e o lsusb recebeu a opção -t.
COMANDOS E RECURSOS PENDETES
Além do novo comando hd, agora o diretório pendente recebeu o novo comando hexdump; adição do ip6gre ao ip; adição de dhcp -u para utilizar UDP ao invés de broadcast replies.
CORREÇÕES DE BUGS E LIMPEZAS
O comando tar -T /dev/null cria um arquivo vazio além de uma correção de incompatibilidade com o SELinux; o test -nt -ot trata um arquivo existente como novo ao invés de arquivo inexistente; ps -o psr= $$ não exibe maos saídas com linhas em branco; o comando pgrep recebeu duas correções sendo a primeira para não tratar argumentos desconhecidos como filtros de processo e a segunda para não permitir que a opção -f não conflite com a nova opção -a já mencionada; o comando lspci -xxxx exibe corretamente offsets de registradores grandes; o as buscas do comando modinfo agora incluem um leading NUL para evitar falsos positivos; o crontab recebeu uma correção para reter o proprietário original. Também houveram correções de bugs nos comandos dentro do diretório pendente.
Ocorreram limpezas nos comandos hexdump, kill, lsusb, xzcat e killall5 que não mais depende do comando kill.
.png "D-Bus será substituído no systemd")
