No mundo moderno, não existe nada pior do que ficar defasado — e pior ainda é ficar travado por causa de opinião sem embasamento. Obviamente, eu também dou opiniões, pelo menos o suficiente para produzir posts como:

• Antes de ter filhos: reflexões sobre educação e responsabilidade
• Brasil, polarização política e tribalismo

E alguns outros que ainda pretendo postar.

Uma coisa em que tenho pensado é o hype da IA e o novo modelo de desenvolvimento baseado no método Ralph Wiggum.

Para contextualizar: eu assistia a alguns vídeos no FreeTube — o melhor frontend para YouTube que conheço — quando reencontrei um vídeo sobre esse modelo de desenvolvimento. Como já havia instalado o Omarchy, do DHH, e testado o OpenCode, que possui ferramentas gratuitas, decidi experimentar o método no meu projeto de OSDev, o FKernel.

O vídeo em questão foi:

O que é o método Ralph Wiggum?

Basicamente, é assumir que LLM é uma porra e combinar força bruta, memória longa e pequenas tarefas para obter um resultado melhor. As memórias são mantidas pelo agente na forma de tarefas em JSON e de um prompt.

Depois, colocamos um loop que roda continuamente, lendo o prompt e atualizando as tarefas.

Assim, um problema longo é dividido em tarefas curtas, muito mais suportáveis de executar e revisar.

Dividir e conquistar é a meta da programação

E o que eu pretendo com isso?

O modelo do FKernel é essencialmente lindo, mas o projeto é mantido por uma pessoa só: eu.

Em geral, a programação acumula muito débito técnico quando não sabemos como chegar ao resultado. Meu processo costuma ser saber o que quero fazer em A, mas não perceber de imediato que preciso integrá-lo a B.

Por isso, reescritas e refatorações tornam-se necessárias. Até uma nova funcionalidade maior que o projeto fica mais fácil de desenvolver no longo prazo quando é dividida corretamente.

Mesmo recursos ou práticas avançadas do FKernel.

Porém é um projeto BSD-3-Clause

Sendo um projeto aberto, é normal esperar contribuições. Ainda não recebi nenhuma, mas seria bom padronizar e automatizar o processo para desenvolvedores que queiram contribuir usando modelos gratuitos.

Particularmente neste kernel eu decidi fugir um pouco do mundo Unix Total e estou usando Lua como a única linguagem de script dentro do kernel.

Vantagens e desvantagens à parte, os scripts de gerenciamento ficam no diretório /Meta e podem ser divididos em pequenas bibliotecas reutilizáveis em /Meta/Lib.

Obviamente não dependendo de LuaRocks para gerenciar libs.

Não pretendo explicar muito além de dizer que é uma prática irrecomendável, porém facilita o pipeline de qualquer pessoa que quiser contribuir.

Baixar → usar o mínimo de dependências externas → gerar o binário.

Funciona?

Não é exatamente o Claude Code, então não consegui replicar perfeitamente o comportamento esperado. Os logs também ainda não ajudam muito.

Ou seja, ainda é preciso muito trabalho para que tudo funcione da forma esperada.

Acredito que o processo e o resultado serão proveitosos no dia a dia quando a ferramenta chegar a um ponto agradável de uso.

Isso será especialmente útil em tarefas grandes e repetitivas de refatoração ou implementação.

O futuro é pica

Com tudo isso dito, espero um futuro melhor no desenvolvimento do kernel. Tarefas muito custosas podem não terminar mais rápido, mas exigem menos intervenção manual: rodou, esqueceu e deixou o agente se ajustar.

Além disso, a divisão em tarefas menores facilita o monitoramento contínuo do progresso.

O diferencial do BeOS / Haiku

O ponto central é simples: escalonar no nível da thread, com threads muito leves e políticas que favorecem responsividade em vez de throughput máximo. Isso reduz a sobrecarga de contexto ao trocar entre threads da mesma aplicação e permite uma taxa alta de comutação sem penalizar a interatividade.

Essa ênfase na responsividade ajuda a explicar decisões de projeto aparentemente simples — por exemplo, por que tratar a unidade de escalonamento como a thread em vez do processo — e prepara o terreno para entendermos o conceito que vem a seguir.

O que é Pervasive Multithread

Pervasive Multithread é um modelo composto — kernel e runtime cooperam — em que o sistema trata a concorrência como algo onipresente: o scheduler opera por thread, há prioridades finas (tipicamente 0–120) e políticas que privilegiam latência e previsibilidade sobre o rendimento bruto.

O resultado prático é que a aplicação vê threads leves com prioridades ajustáveis, e o kernel faz o mínimo necessário ao salvar/restaurar contexto, mantendo a máquina responsiva para cargas interativas.

Com essa definição em mente, vale contrastar como o hardware moderno tenta aumentar paralelismo com técnicas como SMT — e por que essa camada física pode confundir as decisões de escalonamento quando não é considerada explicitamente.

Por que SMT não é um “CPU” — explicação técnica

Simultaneous multithreading (SMT) cria múltiplas hardware threads dentro do mesmo núcleo físico. Essas hardware threads compartilham pipelines, unidades funcionais, níveis de cache e o mesmo domínio energético. Em particular:

• Compartilhamento de execution units: duas hardware threads podem disputar as mesmas ALUs, FPU e portas de memória.
• Contenção em caches: L1 e, em muitos designs, partes do L2/L3 são compartilhadas ou têm efeitos de conflito entre threads.
• Dependência de largura de banda e buffers internos: estruturas como reorder buffers e filas de load/store são limitadas por núcleo.

Esses recursos compartilhados significam que duas hardware threads no mesmo núcleo não oferecem isolamento equivalente ao de dois núcleos físicos. Tratar cada hardware thread como uma CPU independente ignora dependências microarquiteturais e pode degradar throughput e previsibilidade ao induzir contenção e conflitos que o sistema não prevê.

Em outras palavras: o escalonador que vê apenas “CPUs lógicas” perde contexto sobre contendas internas do núcleo — um fator crítico quando buscamos baixa latência e previsibilidade.

Onde os schedulers modernos erram

Muitos escalonadores expõem cada hardware thread lógico como uma CPU separada (p. ex. quando htop mostra “cores lógicos”). Essa abstração facilita balanceamento de carga, mas apaga a topologia real: quando cargas pesadas são espalhadas por hardware threads de um mesmo núcleo, surgem colisões internas que reduzem performance por watt e aumentam a variabilidade de latência.

O problema não é apenas teórico: medições podem mostrar degradação de throughput e latência em cenários que misturam cargas intensivas de CPU e sensíveis à latência, especialmente quando o escalonador não considera a afinidade por núcleo físico e a partição de recursos.

Por isso é importante que camadas de software acima do escalonador compreendam a topologia do processador ou que o próprio escalonador exponha políticas que evitem colocar cargas conflitantes em hardware threads do mesmo núcleo.

A proposta do FKernel: consciência de topologia

No FKernel, a responsabilidade de lidar com essa complexidade é deslocada para camadas que entendem o perfil da carga. A ideia central é uma pipeline decidida antes do despacho para hardware threads:

Green Threads → Multilevel Feedback Queue (MLFQ) → Pervasive Layer → Hardware Threads (SMT)

Detalhes práticos:

• O MLFQ organiza e amostra comportamento das green threads para estimar sua sensibilidade à latência e ao throughput.
• A Pervasive Layer usa esse perfil para decidir mapeamentos: algumas execuções ocupam uma hardware thread sozinho (para evitar contenda), outras são pareadas com cargas complementares para aproveitar vazios da unidade funcional.

Isso torna o SMT um recurso gerenciado — um “acelerador” que é usado conscientemente e não um substituto direto de um núcleo físico.

Na prática, isso permite duas estratégias opostas: isolar workloads sensíveis à latência em hardware threads próprias, ou cooperar uma workload de alta utilização com outra complementar para maximizar uso de unidades funcionais sem bloquear latência crítica.

Flag O_HPC — atalho para throughput

Para workloads puramente orientados a throughput, o desenvolvedor pode usar a flag O_HPC. Nesse modo, o caminho é encurtado: a aplicação solicita pinagem e afinidade mais agressivas (possivelmente com garantia de partição de cache L2/L3), sacrificando previsibilidade para ganhar rendimento bruto.

Em resumo, O_HPC é uma exceção explícita ao modelo orientado a latência — uma forma de o desenvolvedor indicar que prefere rendimento bruto em vez de previsibilidade quando as medições justificam essa escolha.

Conclusão

Tratar hardware threads SMT como CPUs independentes é uma simplificação que não reflete a microarquitetura moderna: ela produz contenção interna, variabilidade de latência e desperdício de recursos. O FKernel propõe empurrar a complexidade para camadas que conhecem o perfil das cargas — MLFQ e Pervasive Layer — para mapear threads de forma consciente sobre a topologia real do processador.

O ganho esperado é simples e direto: menor latência, interatividade consistente e uso mais eficiente de caches e unidades funcionais. Para cargas de throughput extremo, a flag O_HPC permite abrir mão dessa previsibilidade de propósito.

Se você curte esse tipo de discussão ou quer acompanhar o desenvolvimento do FKernel, deixe um comentário, compartilhe como seu sistema lida com SMT ou sugira cargas de trabalho para testarmos. Medições práticas mostrarão o impacto real, e pretendo publicar os resultados em posts futuros.

A princípio isso não parece possível. Se um loop executa uma ação N vezes, o tempo total deveria ser basicamente o custo dessa ação multiplicado por N. Só que na prática, quando compilamos com -O3, o resultado é bem diferente: o mesmo loop roda mais rápido, mesmo fazendo o mesmo trabalho.

E a culpa (ou o mérito) é de um pequeno trecho de código que se tornou quase uma lenda na história da otimização em C:

register int *to, *from;
register int count = (n + 7) / 8;

switch (n % 8) {
case 0: do { *to = *from++;
case 7:      *to = *from++;
case 6:      *to = *from++;
case 5:      *to = *from++;
case 4:      *to = *from++;
case 3:      *to = *from++;
case 2:      *to = *from++;
case 1:      *to = *from++;
        } while (--count > 0);
}

Este pequeno frame é o Duff Device criado por Tom Duff em 1983.

O que é o desenrolamento de loops?

Loop Unrolling (ou desenrolamento de loop) é uma técnica de otimização onde o compilador duplica o corpo do loop várias vezes para reduzir o custo do controle de iteração.

Em vez de checar a condição e incrementar o contador a cada passo, ele faz operações por iterações, diminuindo o número total de saltos no código.

for (int i = 0; i < n; ++i){
    copia[i] = origem[i];
}

se transforma em algo conceitualmente similar:

for (int i = 0; i < n; i += 4) {
    copia[i] = origem[i];
    copia[i+1] = origem[i+1];
    copia[i+2] = origem[i+2];
    copia[i+3] = origem[i+3];
}

Menos branches, mais instruções seguidas, mais chance de o processador aproveitar o pipeline e executar tudo de forma quase branchless, parecido com o que o SIMD faz.

O Duff Device foi a primeira vez que alguém usou essa ideia manualmente, antes de os compiladores modernos fazerem isso sozinhos.

É uma daquelas otimizações que parecem mágica até você perceber que o compilador só está tentando evitar o que humanos mais odeiam: repetições desnecessárias.

Por que isso funciona em C?

A lógica do Duff Device não é muito diferente de acessar vários elementos de um array de uma vez. Se copia e origem têm o mesmo tamanho, você consegue fazer a mesma operação em uma única iteração, processando múltiplas posições do vetor ao mesmo tempo. Isso reduz o overhead de controle do loop e deixa o processador mais livre para executar instruções em sequência, aumentando a eficiência geral.

O do-while sozinho é simples, executa a iteração uma vez e faz o teste da condição garantindo pelo menos uma execução.

O switch é um salto condicional que usa jump-table para ter tempo de execução O(1).

No truque do Duff’s device, os breaks são removidos de propósito e o switch é combinado com o do-while.

Isso cria efeitos simultâneos:

1. O switch escolhe em qual ponto do loop começar
2. O do-while continua repetindo o bloco inteiro várias vezes até completar todas as iterações.

Na prática, isso significa que você começa no case certo (alinhando as iterações que sobraram) e depois “cai” pelos demais cases sem saltos adicionais, repetindo tudo até terminar.

Cada execução do-while processa vários elementos do array, e o switch inicial só garante que você comece na posição correta.

Conclusão

Pode ser uma técnica útil em alguns casos, mas não na maioria.

É feio, parece gambiarra e compiladores modernos já conseguem realizar desenrolamento de loops automaticamente com opções como -O3 ou -funroll-loops.

Porém, se você estiver estudando programação, otimização de código-fonte ou algoritmos, vale a pena conhecer a técnica.

Um dos meus hobbies atuais é ler posts antigos, como os do blog AkitaOnRails. Um deles é Design Patterns representam defeitos nas linguagens.

Primeiramente, este é um bom post, muito bem embasado de acordo com o blog post Universe of Discourse

Um dos pontos que me incomodou foi a mistura entre design de software, arquitetura de software e ergonomia da linguagem.

Mas primeiramente vamos ver o que me incomodou em ambos os blog posts.

Na última vez que escrevi sobre design patterns, foi para apontar que embora o movimento tenha sido inspirado pelo trabalho de “linguagem de pattern” de Christopher Alexander, não é parecido com nada que Alexander tenha sugerido, e que de fato o que Alexander sugeriu é mais interessante e provavelmente teria sido mais útil para programadores do que o movimento de design pattern escolheu seguir.

Uma das coisas que eu apontei foi essencialmente o que Norvig disse: que muitos patterns não estão realmente endereçando problemas recorrentes de design em programas orientados a objetos. Eles estão, na realidade, endereçando deficiências em linguagens de programação orientadas a objetos e que em linguagens melhores, esses problemas simplemente não aparecem ou são resolvidos de maneira tão fácil e trivial que a solução não requer um pattern. Em linguagem assembly, “chamada de sub-rotina” pode ser um pattern; em C, a solução é escrever result = function(args …), que é simples demais para se qualificar como pattern. Em uma linguagem como Lisp ou Haskell ou mesmo Perl, com um bom tipo de lista e poderosas primitivas para operar em valores de listas, o pattern “Iterator” (iterador) é aliviado em um grande degrau ou tido como invisível. Henry G. Baker pegou esse ponto em seu artigo Iterators: Sinais de Fraqueza em Linguagens Orientadas a Objetos.

Recebi muitas mensagens sobre isso, e curiosamente, alguns chegaram à mesma conclusão da mesma forma: eles disseram que embora eu estivesse certo sobre Iterator, era um exemplo pobre porque era um pattern muito simples, mas que era impossível imaginar um pattern mais complexo como Model-View-Controller ser absorvido e se tornar invisível dessa maneira.

Obviamente, como um post antigo não vou dar muito trelo ainda mas, veja.

O motivo de conseguirmos enxergar um iterator

for (auto mp : m_children){
    // Do anything
}

O incômodo

Sendo absorvido por uma linguagem, mas nunca um MVC é simplesmente uma diferença de escopo.

Uma coisa é você aprimorar a ergonomia da linguagem facilitando um método de escrita em detrimento de outro.

Outra coisa é pegar o modelamento da arquitetura e fazer uma linguagem com isso.

Imagine que, no léxico de uma linguagem, print pertença a uma view, os parâmetros sejam models e as funções sejam controllers.

Simplesmente estúpido ao máximo.

E qual o problema original…

Esse é um problema do nome pattern: mesmo design pattern ainda é pouco descritivo.

Eu estou falando do design da linguagem para aumentar a produtividade do programador?

Ou estou falando do design na arquitetura para melhorar legibilidade e manutenção do código ao todo?

O Model-View-Controller deveria se enquadrar em design pattern então? SIM!!!

E Iteradores? SIM!!!

E Orientação a Objetos? SIM!!!

Novamente, é um problema de nomeação e domínio. Se tudo é um design pattern, fica difícil criar uma categorização mais aprofundada.

O mesmo ocorre quando comparamos software monolítico e microsserviços.

Aqui temos dois padrões de arquitetura de software que de alguma forma também um padrão de design.

Podemos dizer que uma linguagem pode absorver uma arquitetura de software?

Uma solução

Podemos adjetivar o design pattern para seu domínio.

• Ergonic design pattern para quando falamos de um padrão de arquitetura que pode ser absorvido pela linguagem.

Sendo um exemplo o Iterator, Goto, Function.

• Architecture design pattern para quando falamos de um padrão de arquitetura que não pode ser absorvido pela linguagem, mas pelo software em geral.

Sendo exemplos: Model-View-Controler, JSP Model1, Model-View-Adapter, Model-View-Presenter

• Implementation design pattern para quando falamos de um padrão de arquitetura que não pode ser absorvido pela linguagem, nem pelo software em geral mas colocado para facilitar a implementação.

Sendo exemplos: Strategy Pattern, Observer pattern, Servant pattern, Command pattern, Chain of responsibility pattern.

Conclusão

No geral, o termo Design Pattern é genérico demais para ser útil no debate técnico.

Agrupar desde ergonomia da linguagem até arquitetura distribuída sob o mesmo nome é um desserviço.

A proposta de Adjetivar os patterns conforme seu domínio deve trazer clareza e distinguir melhor o que é arquitetural e o que é uma boa prática de implementação.

Talvez ao reclassificar os padrões com base não apenas naquilo que elas resolvem mas também no lugar onde operam.

Dentro da matemática temos os Sets, equivalente a conjuntos na teoria de conjuntos.

Também é um tipo de Python que você pode fazer para comprimir uma lista.

# Exemplo em Python
my_list = [1,1,1,1,1,2,2,2,2,2,2,3,3,3,3,3,3,]
print(set(my_list))
# {1, 2, 3}

O que são Disjoint-Sets

E dentro dessa teoria, temos conjuntos disjuntos quando não tem elementos em comum entre eles.

Em SQL, ao fazer joins entre tabelas, podemos pensar em sets: um inner join retorna elementos comuns, e se duas tabelas forem disjuntas (não têm elementos em comum) o join retorna vazio.

Disjoint-Sets trabalham com a mesma ideia de verificar se conjuntos têm ou não interseção.

Em realidade, este é uma das melhores estruturas de dados para otimizar algoritmos em grafos.

Dentro dele suportamos duas operações:

• Union: Mesclando dois conjuntos em um único conjunto.
• Find : Encontrando um representante de um conjunto disjunto.

Exemplo de uso em grafos

Imagine a situação de uma rede social com diversas pessoas e você tem as seguintes tarefas a serem executadas:

• Adicione uma nova relação de amizade, ou seja, uma pessoa x se torna amiga de y adicionando um novo elemento a um conjunto.

• Descobrir se o indivíduo x é amigo do indivíduo y (amigo direto ou indireto)

Exemplo

Exemplo tirado do Geeks For Geeks

Recebemos 10 indivíduos, digamos, a,b,c,d,e,f,g,h,i,j

A seguir estão as relações a serem adicionadas:

a <-> b
b <-> d
c <-> f
c <-> i
j <-> e
g <-> j

Dadas perguntas como se a é amigo de d ou não.

Basicamente, precisamos criar os seguintes 4 grupos e manter uma conexão rapidamente acessível entre os itens do grupo:

G1 = {a, b, d}
G2 = {c, f, i}
G3 = {e, g, j}
G4 = {h}

Caso fomos implementar o UnionFind

class UnionFind
  def initialize(size)
    # Inicializa cada elemento como seu próprio representante (pai)
    @parent = Array.new(size) { |i| i }
    # Rank ajuda a manter as árvores balanceadas
    @rank = Array.new(size, 0)
  end

  def find(i)
    # Aplica compressão de caminho
    if @parent[i] != i
      @parent[i] = find(@parent[i])
    end
    @parent[i]
  end

  def unite(i, j)
    irep = find(i)
    jrep = find(j)

    return if irep == jrep

    # União por rank
    if @rank[irep] < @rank[jrep]
      @parent[irep] = jrep
    elsif @rank[irep] > @rank[jrep]
      @parent[jrep] = irep
    else
      @parent[jrep] = irep
      @rank[irep] += 1
    end
  end
end

names = %w[a b c d e f g h i j]
name_to_index = names.each_with_index.to_h

uf = UnionFind.new(names.size)

relations = [["a", "b"], ["b", "d"], ["c", "f"], ["c", "i"], ["j", "e"], ["g", "j"]]
relations.each do |x, y|
  uf.unite(name_to_index[x], name_to_index[y])
end

x, y = "a", "d"
if uf.find(name_to_index[x]) == uf.find(name_to_index[y])
  puts "#{x} e #{y} são amigos (diretos ou indiretos)"
else
  puts "#{x} e #{y} não são amigos"
end

Onde usar o Disjoint-Set

Disjoint-Set é útil para a maioria dos problemas não triviais da computação muito provavelmente um problema em baixo nível pode ser resolvido com ele.

Exemplos de Alto Nível

Qualquer grande E-Commerce, empresa, sistema que for mexer com grafos pode usar o Disjoint-Set para otimizar em algumas especifidades.

Grafos

• Podemos usar o Disjoint-Set no Algoritmo de Kruskal para encontrar uma árvore geradora mínima.

• Podemos usar o Disjoint-Set para detectar Cíclos em grafos não direcionados.

• Podemos usar o Disjoint-Set para a identificação de componentes conectados.

Simulação

• Controle de conjuntos de objetos que se fundem e se dividem dinamicamente.

• Simulação de percolação ou clusters.

Exemplos de Baixo Nível

Qualquer coisa mais escondida sendo dentro de linguagens de programação, sistemas operacionais, bibliotecas … etc.

Problemas de Equivalência

• Manter classes de equivalência.

• Agrupamento por atributos compartilhados.

E no geral?

Se tiver muito no seu código questões do tipo “X e Y são relacionados?” em um conjunto dinâmico de relações, então Disjoint-Set é a escolha mais eficiente.

Conclusão

A estrutura Disjoint-Set (Union-Find) resolve com eficiência problemas baseados em conectividade dinâmica.

Com Union e Find, é possível gerenciar grupos, detectar relações e otimizar algoritmos em grafos com complexidade quase constante.

Se o problema envolve:

• Particionar elementos
• Verificar conexões
• Unir componentes rapidamente

Então Union-Find é a estrutura certa.

Simples, rápida e usada desde sistemas reais até algoritmos clássicos.

Isso é invariável em todo o mundo da programação.

No mundo do SaaS, sendo um desenvolvedor solo, você não deve confiar apenas em si mesmo.

Adicione Testes, testes, mais testes, enfie testes em tudo que puder e use softwares maduros.

Mas, ao mesmo tempo não deixe seu software parado no tempo.

As duas grandes divisões

Dentro do mundo de software existem duas grandes divisões frontend e backend

E uma parte menor que é DevOps.

Este post, em específico, é sobre frontend e backend.

Assuma que que DevOps você pode contratar outros SaaS em vez de implementar você mesmo.

Frontend

Para o Frontend precisamos atingir o máximo de plataformas sozinho com uma interface moderna possa atingir:

• Desktop
• Web
• Mobile

Além disso, é preferencial que seguirmos técnicas de design como:

• Offline-First
• Mobile-First

Com isso, temos uma base boa para ter um software que não fica irritante com o tempo.

No geral, use Flutter para evitar ter que lidar com diversas plataformas manualmente.

Backend

Para começar, precisamos entender do que é importante no backend de um SaaS.

Nada mais importante do que usar um framework maduro.

E no caso, pessoalmente falando, o melhor que temos é o Ruby On Rails e veja que podemos migrar de Ruby para JRuby garantindo que a aplicação pode escalar se e somente se for necessário.

Adote testes como dogma literalmente, teste tudo, se tiver erro gere um teste, se tiver um bug teste, se tiver uma vulnerabilidade teste também.

Coloque:

• Rack Attack
• Brakeman
• Capybara
• Bullet
• Rack Mini Profiler

Veja que a ideia principal é que as libs do rails são maduras e testadas facilmente acopladas e no geral é muito melhor do que depender de si mesmo que só na cabeça vai querer inventar procedimentos de segurança que vai fazer pagar fortunas em indenizações.

Vide Noticia sobre o Saphoos.

DevOps

Dentro de seu Software as Service.

Você quer evitar ao máximo problemas de responsabilidade fiscal.

Então a coisa mais inteligente a se fazer é se mover de capex (investimento na própria infra) para opex (contrato de serviços externos).

Use serviços como paper-trail, use a amazon-web-service …

O software continua sendo sua responsabilidade mas, problemas internos de servidores gerenciados por provedores não recaem diretamente sobre você, reduzindo riscos e permitindo focar no desenvolvimento.

Contrate Hackers Ético e faça testes de segurança, corrija brechas periodicamente.

Conclusão

No geral, a combinação ideal seria usar um backend em rails e um frontend em flutter.

Para ter diversas plataformas e um backend sólido, caso precise de algo customizado, use um microsserviço da forma que achar melhor contanto que haja contratos fortes e testes.

Jamais esqueça os testes.

Para uso desktop em código x86_64.

E lendo sobre algumas linguagens como Rust, C, C++, Zig …

Decidi fazer uma combinação de:

• Linguagens de Programação:
  • C
  • C++
• Linguagem de montagem:
  • Nasm

Obviamente alguns podem estranhar já que eu propositalmente ignorei Rust, e aquelas que são considerados “memory-safe”.

Por que não usar linguagens memory-safe?

Pro Tip: Não existe linguagem memory-safe em baixo nível. Para programar um kernel ou similar, você vai depender do unsafe então nem tenta.

Se for para ter que lidar com sintaxes estranhas para programar um kernel, eu prefiro seguir no bom e velho C/C++.

Também não quero fazer um overflow de logs de um compilador super-nanny para chegar a um subset daquilo que eu queria no meu código.

E por que C++?

Muito tempo atrás Linus Torvalds havia tentado escrever um kernel com a versão de sua época.

C++ leads to really, really bad design choices. You invariably start using the STL, boost, and other total and utter crap…

Ok, podemos concordar em algumas partes mas, isso não seria inevitavelmente ruim.

Sim, C++ tem um monte de coisa, mas fugiria do ponto principal que é C++ dá contratos que structs sozinhas dificilmente conseguem.

Pegue um exemplo do SerenityOS

static ErrorOr<NonnullOwnPtr<KBuffer>> try_create_with_size(StringView name,
size_t size,
Memory::Region::Access access = Memory::Region::Access::ReadWrite,
AllocationStrategy strategy = AllocationStrategy::Reserve){
  auto rounded_size = TRY(Memory::page_round_up(size));
  auto region = TRY(MM.allocate_kernel_region(rounded_size, name, access, strategy));
  return TRY(adopt_nonnull_own_or_enomem(new (nothrow) KBuffer { size, move(region) }));
}

Consegue entender o que esse código faz? Todo esse contrato engloba em poucas linhas

Essa função try_create_with_size serve para criar um buffer de memória no kernel de um tamanho específico e lidar com possíveis erros de forma segura.

Para termos o equivalente exato em C garantindo a mesma segurança seria necessária escrever dessa forma.

int try_create_with_size(const char* name,
                         size_t size,
                         MemoryAccess access,
                         AllocationStrategy strategy,
                         KBuffer** out_buffer) {
    if (!out_buffer) return -1;

    size_t rounded_size;
    int rc = page_round_up(size, &rounded_size);
    if (rc != 0) return rc;

    MemoryRegion* region;
    rc = allocate_kernel_region(rounded_size, name, access, strategy, &region);
    if (rc != 0) return rc;

    KBuffer* buffer = malloc(sizeof(KBuffer));
    if (!buffer) {
        free(region->addr);
        free(region);
        return -ENOMEM;
    }

    buffer->size = size;
    buffer->region = region;
    *out_buffer = buffer;

    return 0; // sucesso
}

Ok, tivemos uma disparidade no tamanho, mas isso não significa nada no geral.

Meu ponto defendido é que precisamos fazer muito mais código, que vai ser muito mais performático mas que vai resultar em um resultado muito menos seguro, e muito menos reusável no geral.

Não ironicamente, muitos empresas incluindo a própria Apple usam o C++ em seus kernels.

Mas não precisa ser o c++ inteiro e sim um subset chamado embedded c++.

Implementação do IOKit

/*
 * Copyright (c) 1998-2000 Apple Computer, Inc. All rights reserved.
 *
 * @APPLE_OSREFERENCE_LICENSE_HEADER_START@
 *
 * This file contains Original Code and/or Modifications of Original Code
 * as defined in and that are subject to the Apple Public Source License
 * Version 2.0 (the 'License'). You may not use this file except in
 * compliance with the License. The rights granted to you under the License
 * may not be used to create, or enable the creation or redistribution of,
 * unlawful or unlicensed copies of an Apple operating system, or to
 * circumvent, violate, or enable the circumvention or violation of, any
 * terms of an Apple operating system software license agreement.
 *
 * Please obtain a copy of the License at
 * http://www.opensource.apple.com/apsl/ and read it before using this file.
 *
 * The Original Code and all software distributed under the License are
 * distributed on an 'AS IS' basis, WITHOUT WARRANTY OF ANY KIND, EITHER
 * EXPRESS OR IMPLIED, AND APPLE HEREBY DISCLAIMS ALL SUCH WARRANTIES,
 * INCLUDING WITHOUT LIMITATION, ANY WARRANTIES OF MERCHANTABILITY,
 * FITNESS FOR A PARTICULAR PURPOSE, QUIET ENJOYMENT OR NON-INFRINGEMENT.
 * Please see the License for the specific language governing rights and
 * limitations under the License.
 *
 * @APPLE_OSREFERENCE_LICENSE_HEADER_END@
 */

#ifndef _IOKIT_IONVRAMCONTROLLER_H
#define _IOKIT_IONVRAMCONTROLLER_H

#include <IOKit/IOService.h>

class IONVRAMController : public IOService
{
	OSDeclareAbstractStructors(IONVRAMController);

public:
	virtual void registerService(IOOptionBits options = 0) APPLE_KEXT_OVERRIDE;

	virtual void sync(void);
	virtual IOReturn select(uint32_t bank);
	virtual IOReturn eraseBank(void);

	virtual IOReturn read(IOByteCount offset, UInt8 *buffer,
	    IOByteCount length) = 0;
	virtual IOReturn write(IOByteCount offset, UInt8 *buffer,
	    IOByteCount length) = 0;
};

#endif /* !_IOKIT_IONVRAMCONTROLLER_H */

Quem diria.

Se fossemos falar do C++ antes da versão 17, eu até concordaria mas após a versão 17 muita coisa mudou.

E veja que o IOKit é implementado na forma Embedded C++.

Mas, e como em tudo há um mas, há em real,o ponto da STL que invariavelmente você vai acabar usando ou não.

Realmente preciso do STL?

No fringir dos ovos há um outro superset de C++ chamado c++ ortodoxo jamais o use, sério.

Uma das soluções que o FKernel e o SerenityOS fazem é criar sua própria STL.

O SerenityOS com sua Abstraction Kit. E o FKernel com seu LibFK.

Usar uma STL não é de todo mal, há diversos efeitos, como otimização em cascata.

Genericos e todo resto.

E no fim?

No fim, depende de você.

Se você está desenvolvendo um app para desktop.

Eu sugeriria:

• D
• Go
• Zig
• Rust

Para baixo nível certamente eu sugeriria:

• B
• C,
• C++
• D
• Rust
• Zig

Mas em kernel estou muito mais satisfeito com minha escolha do que usar C puro.

Não que eu não use C obviamente, por baixo dos panos da LibFK eu implementei uma LibC bem simples com funções que eu teria que usar dentro do FKernel para algumas funções da LibFK.

Mas enfim, se uma linguagem que você prefere usar por algum motivo de design ou simplesmente por ser a que você sabe, simplesmente use.

Desde que não seja usar algo interpretado para fazer baixo nível, tá valendo tudo.

Grafos são um ramo da matemática que estuda relações entre objetos pertencentes a um determinado conjunto.

Você pode pensar, por exemplo, que $${a, b}$$ representa uma relação que leva de a para b.

Historicamente, Leonhard Euler, também responsável pela identidade de Euler,

$$E^{i\pi} + 1 = 0$$

publicou, em 1736, um artigo sobre o problema das sete pontes de Königsberg. Esse trabalho é considerado o ponto de partida da teoria dos grafos.

Onde grafos são usados?

Na computação, grafos aparecem direta ou indiretamente em muitos lugares:

• redes neurais;
• estruturas de árvores;
• redes de computadores;
• computação gráfica;
• redes sociais.

Se um problema exige representar conexões, provavelmente um grafo será útil.

Isso fica ainda mais interessante em linguagens formais e autômatos, áreas fundamentais para a construção de linguagens de programação e marcação. Elas também usam grafos para representar autômatos e diagramas de transição.

Algoritmos de busca em grafos

Como um grafo é formado por relações, direcionadas ou não, precisamos definir um critério para percorrê-lo.

E para isso temos um problema essencial que precisa ser resolvido.

Qual critério?

Normalmente ou estamos trabalhando com grafos esparsos ou grafos densos.

Grafos esparsos têm poucas arestas em relação ao número de vértices.

Grafos densos, por sua vez, têm muitas arestas.

Essa característica influencia diretamente a escolha da representação e do algoritmo mais eficiente.

Os dois algoritmos mais clássicos para essa busca são:

• BFS (Breadth-First Search): busca em largura;
• DFS (Depth-First Search): busca em profundidade.

Algoritmos

Busca em Largura (BFS)

O algoritmo de busca em largura explora nível por nível.

Ou seja se pensarmos em uma árvore.

Ele verificaria primeiro os vizinhos da raiz.

Depois os vizinhos dos vizinhos da raiz e por assim vai.

Para fazer isso a gente utiliza uma estrutura de dados fila/queue.

Propriedades da busca em largura

• Se existir uma solução, este algoritmo consegue encontrar.

• Em grafos não ponderados, encontra o caminho com o menor número de arestas.

• Complexidade:

• Tempo: $$O(V + E)$$, pois percorre os vértices e as arestas alcançáveis.

• Espaço: $$O(V)$$ porque precisa armazenar a fila e o conjunto de visitados.

Lógica passo a passo

1. Colocamos um nó na fila, e marcamos como visitado.
2. Enquanto a fila não estiver vazia:

• Retiramos o primeiro elemento.
• Visitamos todos os vizinhos não visitados do nó.
• Adicionamos esses vizinhos à fila e os marcamos como visitados.

Busca em Profundidade

A busca em profundidade em comparação explora todo um ramo do grafo até o fim antes de voltar e explorar outros ramos.

Ao contrário da busca em largura, aqui usamos pilha/stack (Last In, First Out).

Propriedades da busca em profundidade

• Em grafos finitos, consegue percorrer todos os vértices alcançáveis, mas não garante o caminho mais curto.

• Ótimo? Não, não é adequado quando você precisa do menor número de arestas.

• Complexidade:

  • Tempo: $$O(V + E)$$
  • Espaço: $$O(V)$$

• Risco prático: a versão recursiva pode estourar a pilha em grafos muito profundos; nesses casos, prefira uma versão iterativa.

Lógica passo a passo

1. Marque o nó inicial como visitado e entre nele.
2. Para cada vizinho não visitado, repita o processo.
3. Quando o nó não tem vizinhos não visitados, realize um backtrack.
4. Continue até visitar todos os nós alcançáveis.

Conclusão

Não existe um algoritmo universalmente “melhor”: tudo depende do objetivo.

BFS (Busca em Largura):

• Garante o menor caminho em grafos não ponderados.

• Mais indicado quando o problema exige a solução mais curta.

DFS (Busca em Profundidade):

• Útil para exploração completa, detecção de ciclos, ordenação topológica e backtracking.

• Mais indicado quando queremos percorrer toda a estrutura ou analisar propriedades do grafo.

Ambos têm a mesma complexidade assintótica, $$O(V+E)$$, mas aplicam-se a cenários distintos.

E devem ser tratados com cautela para não escolher a pior opção por puro achismo.

Espero que tenham gostado do post. Valeu!