Bom, em primeiro lugar consegui meu primeiro emprego de carteira assinada, nada muito glamouroso.

Fui contratado para ser auxiliar de desossa (na área de controle de estoque) numa empresa pequena da região.

É pouco até você perceber que eles lidam em torno de 700 porcos por dia em média.

Mas num quesito geral é um emprego digno e muito mais interessante por ser bastante manual.

Particular meu, mas eu gosto de ter serviço braçal porque faz minha mente pensar ou parar de pensar um pouco.

Não que eu larguei a programação e os estudos de lado, na real meu obisidian e meu appflowy (um substituto opensource do Notion) tá mais lotado de roadmap’s de coisas aleatórias e sobre programação.

Fora também que a empresa possui banco de talentos inclusive para a área de TI então vale a pena ficar nela.

Na real, voltando para o obsidian mudei totalmente o estilo do vault para algo no estilo dump direto do meu cerebro.

.
├── Assets
│   ├── CheckList
│   │   ├── Checklist de viagem de carro.jpg
│   │   ├── Checklist de viagem.jpg
│   │   └── Kit de Primeiros Socorros.jpg
│   ├── Design
│   │   ├── Linguagem visual Dark Mode FoxBSD.png
│   │   └── Linguagem visual FoxBSD.png
│   ├── Learning
│   │   ├── Etiqueta de Roupas.jpg
│   │   └── Pendurar ou Dobrar.jpg
│   └── Specifications
│       └── OpenStep Specification.pdf
├── Learning
│   └── Investimentos
│       ├── Fundamentos de Investimentos.md
│       └── Organização Financeira.md
├── Notes
│   └── Stack de Programação.md
├── Projects
│   ├── FoxBSD
│   │   └── What IS - FoxBSD.md
│   ├── Jarvis
│   │   └── What IS - Jarvis.md
│   ├── KitsuneBot
│   │   └── What IS - KitsuneBot.md
│   └── NeoStep
│       └── What IS - NeoStep.md
└── Studying
    ├── Knowledge
    │   ├── Checklists.md
    │   └── Manuais.md
    ├── Limpeza
    │   ├── Limpeza de Roupa Branca.md
    │   └── Limpeza de Tênis Branco.md
    └── Receitas
        ├── Caldos
        │   └── Caldo de Ossos.md
        ├── Cortes
        │   └── Compras de Carnes.md
        ├── Erros e Truques de Cozinha
        │   ├── Erros e truques de Cozinha.md
        │   └── Truque da tampa - Quando usar e Quando não usar.md
        ├── Guia
        │   ├── Guia Prático dos  Pimentões.md
        │   ├── Guia Prático dos tipos de panela.md
        │   └── Guia sobre quando adicionar alimentos à água.md
        ├── Marinar
        │   ├── Formas de marinar carne bovina.md
        │   ├── Formas de marinar frango marinado.md
        │   └── Formas de temperar manteiga.md
        └── Molhos
            └── Molhos Clássicos para Massas.md

24 directories, 30 files

Agora com o tempo dá para continuar com alguns projetos e fazer uns entretenimento diferentes.

Bom, essa é uma pequena atualização do dia a dia por agora, mas tá bacana

Galera, se você tem acompanhado as notícias recentes, a situação não está nada tranquila. Resumindo: estamos indo para a merda rápido.

O Brasil decidiu que todos os sistemas operacionais e lojas de aplicativos devem implementar algum tipo de verificação de idade. Para piorar, a Califórnia seguiu a mesma linha.

Brazil Law: All OS's Have 13 Days to Add Age Verification

A new law, in Brazil, requires age verification on all Operating Systems (including Linux & Windows) by March 17th. Plus a rundown on similar laws in California, Colorado, and New York. pic.twitter.com/2Ik1hNEDf8

— The Lunduke Journal (@LundukeJournal) March 4, 2026

Segundo o Lunduke Journal , algumas empresas, como a Apple, optaram por não implementar a medida, com DHH sendo publicamente contra.

“Omarchy has no plans to do anything in response to this retarded California law.”

That is what @DHH told me when I asked him if @OmarchyLinux plans to implement age verification functionality to comply with the new California and Brazilian laws. pic.twitter.com/2bkaDwwNU0

— The Lunduke Journal (@LundukeJournal) March 4, 2026

Enquanto isso, distribuições como Fedora, Mint, Ubuntu e ElementaryOS já confirmaram que vão seguir a lei brasileira/californiana.

E para ilustrar o que isso significa na prática, o compatriota @Jocadbz escreveu o post O Grande Irmão veste roupas de babá , onde detalha o impacto dessa vigilância:

Quando um sistema operacional compartilha um “sinal criptografado”, políticos afirmam que isso é uma vitória para a privacidade, porque o aplicativo específico não vê seu documento físico. Mas, ao vincular a faixa etária verificada a um ID de hardware permanente ou a uma conta central do Google/Apple, encerramos a era do perfil “descartável”.

Cada aplicativo que você baixa – de fóruns de nicho a rastreadores de fitness – recebe o mesmo token verificado do seu sistema operacional. Sua identidade entre plataformas se torna unificada: você deixa de ser um usuário anônimo e se torna “Usuário nº 88291, homem, 24 anos, verificado via hardware”.

A Lei 15.211 do Brasil leva isso um passo além. “Garantia razoável” é apenas um eufemismo jurídico para vigilância biométrica. Plataformas estão migrando para “Provedores de Identidade” de terceiros. Em breve, para assistir a um vídeo ou entrar em um chat, será necessário escanear o rosto ou enviar documentos nacionais. Isso cria enormes bancos de dados centralizados, vulneráveis a ataques. Estamos sendo forçados a fornecer dados biológicos para atravessar uma corda de veludo digital, tudo em nome de “proteger as crianças”.

O impacto para nós e para o FOSS

Para os usuários, isso significa mudanças profundas no dia a dia da internet. Mas existe uma alternativa que muitas vezes é ignorada: o FOSS (Free/Open Source Software), também chamado de Software Livre.

O que é FOSS?

O Software Livre é baseado em quatro liberdades essenciais:

0. Executar o software para qualquer propósito.
1. Estudar como o software funciona.
2. Redistribuir cópias do software.
3. Aperfeiçoar o software e distribuir melhorias.

Essas liberdades nos dão a base para reduzir a dependência da internet e de sistemas centralizados. Ou seja, podemos começar a nos proteger sem depender de Google, Apple ou quaisquer leis invasivas.

Como agir agora

• Se você está preocupado com privacidade, procure softwares que:

• Não dependam da internet para funcionar.

• Não sigam as leis de verificação de idade.

• Possuam instalação e distribuição offline, por meios físicos (pendrives, DVDs, etc.).

Exemplos práticos:

• Linux-Libre ou BSD – distribuições que priorizam liberdade e privacidade.

• Linux offline – muitas distros Linux podem ser configuradas para funcionar sem conexão, embora alguns pacotes adicionais precisem de internet.

Evite qualquer software que já tenha concordado com a lei de verificação de idade ou que exija autenticação online obrigatória. A ideia é recuperar autonomia digital e manter o anonimato mínimo possível.

Conclusão

O movimento de verificação de idade global é só o começo de um controle digital que afeta todos os usuários. A boa notícia é que o FOSS oferece meios concretos de resistência.

Não é sobre conspiracionismo, é sobre recuperar liberdade e autonomia. E, se você ainda não pensou nisso, o momento de agir é agora: escolha software livre, offline, e proteja sua identidade digital antes que vire um número em algum banco de dados central.

Pois é, para alguem que falou que ia demorar fazer mais posts este ano, cá estou eu de novo.

Dessa vez, em complemento o meu post anterior Um jornada de reforço, planos para 2026 onde eu prometi que o ano seria mais lento. Mostrando como estou configurando o meu obsidian para estudar.

Antes de mais nada, estudo é uma mistura de metodo e disciplina para memorizar e memorizar o entendimento da memória e os resultados de certas ações, formulas ou ocorrências.

Isso claro, na forma mais bruta do que é estudar. Então quando seu professor te criticar por memórizar a formula só diga isso:

“Se eu não memorizar, como vou entender e por consequência aprender”.

Enfim, em muitos casos, existem diversas tecnicas e formas de se aprender algo.

Meu Obsidian

Eu particularmente decidi adotar o zettelkasten que é perfeito para se combinar com o obsidian.

Mas obviamente não de forma crua como está, então eu adicionei alguns plugins como:

• Advanced Canvas
• Dataview
• Iconize
• Tag Wrangler
• Templater
• Escalidraw
• Omnisearch

Coisinhas simples que vão cobrir 80% do que você precisa estudar fora que assim você ligar conteudos de forma muito mais interessante do que antes.

E adicionei também alguns diretórios:

00 - Assets

01 - Referencias

02 - Permanentes

03 - Map of Contents

xx - Escalidraw

xx é usado para representar sem valor númerico aqui

Mas, a coisa mais importante disso tudo está sendo encontrada em Assets/_Templates

Que sim, são os templates do projeto

• Nota MOC -> Lê se Nota Mapa de Conteúdo
• Nota Permanente
• Nota Referencia

Aliás, dica importante

Dentro do seu obsidian, vá nas configurações do templater e em template folders location coloque como: 00 - Assets/_Templates

Isso evita que o mesmo sugira outras notas como seu templates de notas.

Bom, a ideia é simples:

Tudo que eu ler e for útil para algo vai virar uma Referência

Depois que a referência for feita, ela não pode mais ser editada, somente para alguma revisão ou em nova versão v2.

Lemos a refência e transformamos os insights em versões permanentes cuja ideia é ter:

• Argumento Central
• Resumo do que ocorreu
• Conexões com outras notas
• Link para as referencias originais

Pode usar o Dataview para checar se já existe algum permanente deste tipo antes de criar duplicatas

Por fim atualizamos o MOC da área correspondente listando ou linkando todos os permanentes de suas respectivas areas ou subáreas, alias adicione quantas quiser.

Se houver alguma dúvida ou questão em aberto você pode colocar em questões em aberto

Agora, o mais importante é o processo de revisão, sempre releia as permanentes antigas e atualize o MOC se surgirem novas conexões.

Templates

Nota Referencia

---
tipo: referencia
area:
fonte:
autor:
link:
created: <% tp.date.now("YYYY-MM-DD") %>
status:
tags:
  - nota-referencia
---

# <% tp.system.prompt() %>

## Resumo bruto

-

## Pontos Importantes

-

## Ideias Provocadas

-

## Possíveis Permanentes

-

Yeah, bem simples para um template, o uso do <%tp.system.prompt%> permite que você crie um titulo baseado diretamente no prompt que o usuário colocar e dentro de uma referencia onde podemos ter diversas referencias para um único permanente.

Além disso, dentro do template temos diversas própriedades como:

area-> Categoria do conteúdo

fonte/autor/link -> informações da fonte original

resumo bruto -> sintese direta da fonte

pontos importantes -> destaque de ideias que podem se tornar permanentes

ideias provocadas -> insights iniciais que surgem ao ler a fonte

Possiveis Permanentes -> conceitos que poderão virar nota consolidada.

Nota Permanente

---
tipo: permanente
area:
status: rascunho
origin:
created: <% tp.date.now("YYYY-MM-DD") %>
updated:
conexões:
referencias:
tags:
  - nota-permanente
---

# #Title

Explique a ideia com suas palavras.
Seja específico
Evite copiar a fonte.

---

## Argumento Central

---

Diferente da nota referencias, aqui pegamos o titulo literal do arquivo usado #Title para gerar o título do modelo permanente.

Junto com algums campos como:

area -> precisa ser a mesma da referência relacionada

origin -> referência de origem

argumento central -> explicação própria do conceito

conexões -> links para outras permanentes relacionadas

referencia -> cite refências usados

status -> pode ser rascunho, ativo e reevisado

Permanentes são a base do conhecimento consolidado, revisável e linkado pelo MOC

Nota MOC

---
tags:
tipo: moc
area:
status: ativo
created: <% tp.date.now("YYYY-MM-DD") %>
---

# #Title

## Escopo

Descreva claramente o que este Map of Content cobre.

---

## Conceitos Fundamentais

```dataview
table area, status
from "02 - Permanentes"
where area = this.area
```dataview
---
## Subáreas

- ***

## Referências Base

```dataview
table fonte, autor
from "01 - Referencias"
where area = this.area
```dataview
---

## Questões em aberto

-

Eu acabei quebrando o dataview no exemplo acima para garantir que ficasse tudo em um único codeblock, assim caso copiem diretamente basta trocar ```dataview pela sua versão sem dataview usando regex.

A nota MOC tem como objetivo principal agir como indice e dar umma visão geral da área de estudo, aqui também usamos #Title para gerar o título do modelo.

Conceitualmente a tarefa do moc é puxar diretamente do dataview lista de todos os permanentes relacionados a mesma área e organalizos - los em relação a área e a subárea presente em clusters ou topicos.

Ainda há o questões em aberto sobre duvidas em geral de acordo com o temas que você pode realizar, literalmente um TODO do que falta estudar, e acredito há muito do que quero estudar

Fluxo e isso é importante

1. Encontrei algo novo: Crio Referencia
2. Processo a informação: transformo em Permanente com minhas palavras, citando origem
3. Organizo no MOC: Atualizo Conceitos Fundamentais, Subáreas e Questões em aberto.
4. Prático: Esse é o mais importante, tudo que existe é uma prática e não adianta nada se você não práticar.
5. Revisar periodicamente: mantenha permanentes e MOC atualizado adicionando novas conexões

Bem este é o meu Obsidian de Estudo, chamado carinhosamente de Mind Order, espero que tenham gostado fui.

Cá estamos nos em feveireiro e eu realmente não consigo acreditar que faz pouco mais de 6 anos que me tornei alguém ativo na WWW.

Não que eu seja famoso, ativo no sentido de estar presente em diversas plataformas online, mantendo esse blog, conversando no discord, perdendo tempo no vaporhole (que é uma rede social brasileira estilo tilde.club, algo como um pc Unix compartilhado entre diversas pessoas via SSH), perdendo tempo vendo vídeos no Youtube, perdendo tempo no X, perdendo tempo no Instagram.

Enfim, nada de muito revolucionário até ai.

Mas sinceramente desde a criação do ChatGPT, ClaudeAI, Gemini, Grok, DeepSeek e outros modelos. Eu sinto que venho cada vez menos programando ou exercitando meu intelecto como programador.

Não é como se eu cogitasse parar de usar, o chatGPT conversa muito bem comigo e eu obrigo ele a comunicar da forma que eu comunico melhor

Estilo e Tom básico: Franco Caracteristicas:

• Acolhedor: Menos
• Entusiasmado: Mais
• Lista e Cabeçalhos: Mais
• Emoji: Mias Instrução personalizada: Seja sarcastico mas mantendo a educação, discorde argumentando e questione minha lógica sempre que possível.

Não tenha floreios e aja com um homem adulto de 18 anos podendo explicitamente conversar sem preocupações como uma pessoa adulta faria com outra pessoa adulta.

Memória: O usuário prefere que eu nunca refaça as respostas que ele já escreveu e quer que isso seja respeitado permanentemente.

Então a ideia para esse ano é focar em reestudar algoritmos, estuturas de dados e ferramentas.

A segunda parte é começar com alguns projetos avulsos de prática.

Para quem não sabe “Yet Another Recretional Programming Session - Tsoding”

Provavelmente esse ano vai ser lento, mas os próximos posts vou tentar focar em coisas out-of-the-box que vocês pouco ouvem falar como por exemplo: Programação Dinâmica e Programação Matemática fora algumas coisas de arquitetura e alguns padrões que acho que poucos ouvem falar.

A terceira parte é começar na criação de conteúdo.

A quarta parte e a mais importante é começar a sair do conforto e começar a fazer mais atividades físicas.

23 anos é muito tempo para ser feliz, hora de virar adulto.

Enfim, um bom ano novo para todos

Jujutsu Kaisen é uma série shounen onde acompanhamos a história de Yuji Itadori que tem como principal objetivo consumir e eliminar todos os dedos de Sukuna.

Para isso, ele tem que lidar com maldições, feiticeiros e usuários de maldições usando como poder a “Energia Amaldiçoada” e as “Técnicas Amaldiçoadas”.

Dentre as “Técnicas Amaldiçoadas” existem alguns tipos:

As que todos conseguem usar como o:

• “domínio simples”,
• “black flash”,
• “punho divergente”
• … entre outras

As que surgem de forma inata com seu feiticeiro:

• “Boogie Woggie”
• “Santuário”
• “Copy”
• “Manipulação de maldições”

As técnicas que são passadas geneticamente entre clãs:

• “Seis Olhos”
• “Ilimitado”
• “Dez Sombras”

E essas técnicas atuam de diversas maneiras em conceitos da realidade.

Então temos dois tipos de disputas em JJK, disputa de quantidade de energia e disputa entre conceitos.

Porque isso quebra o metódo normal de powerscalling

Vou começar pelo Mugen, a técnica “neutra” do Ilimitado de Satoru Gojo.

O conceito dela é desacelerar infinitamente o golpe realizado adversário usando o paradoxo de Zenão.

PS: Assuma velocidade constante para cada participante, o passo da tartaruga deve equivaler ao passo de Aquiles, nem um passo a mais nem um passo a menos. Ou seja um movimento uniforme.

Se Aquiles der uma vantagem inicial à tartaruga, quando ele chegar onde ela estava, ela terá avançado um pouco mais. Ao chegar nessa nova posição, ela terá avançado ainda mais. Esse ciclo se repete ao infinito, sugerindo que Aquiles nunca a ultrapassará, pois sempre haverá uma distância a percorrer.

E isso é um problema para o mundo de powerscalling porque, se formos considerar apenas os feitos, nada vai sair da escala cidade.

Mas, como todos os poderes interferem na realidade, o nível deveria ser conceitual para cima.

Outro exemplo seria o Star Rage da Yuki que aplica uma massa virtual para cima dos golpes da mesma chegando ao ponto de colapsar em um buraco negro.

O fato dos feitos em jujutsu não ultrapassar nível cidade tem um proposito, por mais que os feiticeiros lutem entre si carregando conceitos, eles precisam do planeta para viver então nada vai fugir desse ponto.

E daí surge as “expansões de dominio”

Onde se cria um espaço metafísico a.k.a uma barreira em que você embute a máxima expressão da sua técnica e aplica um efeito garantido no seu usuário.

Por mais que não pareça, isso é extremamente importante no universo de Jujutsu junto com a Cortina já que a população geral não faz ideia do Jujutsu.

E mesmo a luta dos mais fortes ou o arco de Shibuya tiveram efeitos politicamente desagradaveis pelo ocorrido.

Então, podemos dizer que o efeito máximo das técnicas está em eliminar o conceito oponente e esse é seu máximo.

E quanto a quantidade de energia amaldiçoada?

Esse é outro ponto da disputa entre conceitos que eu comentei. Para uma técnica amaldiçoada fazer efeito ela precisa de determinada quantidade de energia amaldiçoada.

E dependendo do personagem e da quantidade que ele possue ela pode ter comportamentos díferentes como o Hakari e sua energia bruta, o Kashimo com sua energia eletrica …

Isso também garante que o conceito A seja mais forte que o conceito adversário.

Tanto que o Roxo 200% de Gojo na luta dos mais fortes não teve relevância pois perdeu potência indo de uma cidade a outra ficando com uma liberação de energia mais fraca que a própria liberação do Sukuna.

Então o problema é

Em JJK você nunca vai ver estragos ou feitos maior que em nível cidade porque os personagens vivem em uma “terra” e são “humanos” o suficiente para necessidades biológicas humanas.

Além de ter o problema dos cívis que não são correlacionados ao mundo e obviamente a necessidade do mundo.

Fora isso, temos diversos conceitos sendo mostrados como o buraco negro da Yuki Tsukumo.

Ou o teste dos mais fortes, Mahoraga.

No mundo moderno, não existe nada pior do que se defasar e pior ainda ficar travado por causa de opinião sem embasamento, obviamente eu dou opinião, pelo menos o suficiente para produzir os posts como:

• Como criar filhos
• Brasil, a grande várzea

E alguns outros que ainda pretendo postar.

Porém, entretanto, todavia uma coisa que tenho pensado é no hype das AI e no novo modelo de desenvolvimento baseado em Ralph Willgum

Para contextualizar, eu estava em um dia normal assistindo alguns vídeos no Freetube (o melhor frontend para youtuber que eu conheço) e encontrei ou melhor reencontrei um vídeo falando deste modelo de desenvolvimento e como já tinha instalado o Omarchy do DHH e testado o OpenCode que possui ferramentas gratuitas decidi testar no meu projeto de osdev, o FKernel.

Em questão o vídeo que eu assisti foi

O que é o metodo Ralph Wiggum

Basicamente é assumir que LLM é uma porra e usar força bruta + memória longa + pequenas tarefas para conseguir um resultado melhor, ambas as memórias são mantidas no sistema operacional do agente na forma de tasks em json e um prompt.

Após isso colocamos um for-loop que deve infinitamente rodar lendo o prompt e atualizando as tasks.

Para tarefas longas, tudo vira tarefas curtas que são infinitamente mais supportaveis de se fazer me um problema longo.

Dividir e conquistar é a meta da programação

E o que eu pretendo com isso?

O FKernel em seu modelo é essencialmente lindo, mas, é mantido por uma pessoa só “eu”.

E o geral a programação tende a ter muito débito técnico quando não se sabe como atingir o que quer e meu processo de desenvolvimento é saber o que quero fazer em A mas não saber que preciso integrar a B.

Então é necessário fazer uma reescrita ou uma refatoração, mesmo uma nova feature que seja maior que o projeto fica mais fácil de desenvolve - lo a longo prazo.

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

Porém é um projeto BSD-3-Clause

Sendo um projeto aberto é normal se esperar contribuições, eu mesmo não tive, porém seria bom normalizar o processo para ficar automático para todos os desenvolvedores que quiserem contribuir usando obviamente 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 a parte qualquer script de gerenciamento é normalizado em scripts no diretório /Meta e podemos dividir em pequenas libs em /Meta/Lib reusáveis.

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 > Ter o mínimo de dependencia externa > Gerar o binário

Funciona?

Não é exatamente o claude-code então não consegui replicar perfeitamente o comportamento esperado, fora que os logs em si não contribuem muito ainda.

Ou seja precisa de muito trabalho para ser 100% funcional da forma esperada, tirando isso.

Acredito que o progresso e o resultado em si devam ser proveitosos no dia a dia quando estiver num ponto agradavel de uso.

Bom em especial quando eu tiver grandes e chatas tasks de refatoração em especifico ou de implementação.

O futuro é pica

Com tudo isso dito, a única coisa que posso aguardar é um melhor futuro no desenvolvimento do meu kernel já que agora tarefas incrivelmente custosas em tempo pode ser executada não em menos tempo, mas em menos iteração manual. Rodou esqueceu e ele que se ajuste.

Fora na subdivisão em tarefas menoras e o monitoramente continuo de como continuar a progressão

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 mostram degradações em throughput e latência em cenários de mistura de cargas CPU-bound e latência-sensível quando o escalonador não considera afinidade por núcleo físico e 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 workloads para testarmos — medições práticas vão mostrar o impacto real, e eu pretendo publicar resultados em posts futuros.

Dentre eles temos o beOS e seu sucessor HaikuOS.

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.

E porque 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).

Agora, dentro de truque do Duff-Device: ele remove os breaks de propósito e coloca o switch dentro do 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 seu compilador quando passa as flags -O3 ou -funroll-loops já adiciona os Duff-Devices automaticamente.

Porém se você estiver estudando programação ou pelo menos otimização de código fonte, complexidade de algoritmos vale a pena dar uama revisada.

Um dos meus hobbies, atualmente está sendo ler posts antigos, como os do blog AkitaOnRails. E em um de seus posts entitulados [ Design Patterns representam defeitos nas linguagens ]

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

Mas, um dos pontos que me incomodou foi a mistura de Design do Software com Arquitetura de Software e a 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 incomodo

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 dentro do lex de uma linguagem, você tem print que pertence a um view e os parametros seriam models com funções sendo controllers.

Simplesmente estúpido ao máximo.

E qual o problema original…

Esse é um pequeno problema de usar o nome pattern, sendo mais especifico design pattern é muito 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!!!

Isso porque novamente é um problema de nomeação e domínio. Se está tudo em um design pattern então fica dificil fazer uma categorização mais aprofundada.

O mesmo serve quando colocamos software monolitico contra 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.

Agrupando tudo desde ergonomia da linguagem até arquitetura distribuida sob o mesmo nome vira um deserviç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 especifico é 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”.

Porque 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 porque 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.

Ocorrendo no inferno moderno a.k.a X, resolvi vir para cá reclamar para um cacete.

Já aviso que vai ter muita generalização aqui, é muito mais fácil juntar tudo do que contar parte por parte separado.

A grande burrada

Politicamente o mundo está um inferno real, não falo de alguns ou outros países mas, de todo mundo globalizado.

Eu já havia detectado alguns traços de que o mundo estava se tornando niilista. Mas, isso está pior do que poderia estar e dessa vez eu atribuo a culpa a amathia.

Segundo Sócrates, Amathia (a ignorância) é o único mal.

E não, não estou chamando nenhum espectro de ignorante em si. Mas, a população que está ocupando os espectros estão em condição de fanatismo.

O que são esquerda e direita?

Antes de tudo é bom contextualizar um pouco sobre.

Durante a revolução francesa (1789 - 1799) a população precisou de juntar na Convenção nacional.

Os que apoiavam o rei se sentaram a direita do presidente da assembleia, aqueles que defendiam mudanças radicais e nova ordem se sentavam a esquerda.

Não inesperado, muita coisa mudou daquele tempo para cá. Mas uma caracteristica da revolução se manteve:

• Direita continua sendo sobre manter o status quo, a preservação das tradições e da ordem social existente.
• Esquerda continua sendo aqueles que lutam pelas mudanças sociais, economicas e/ou politicas.

Até aqui, como pudemos ver nada de amoral/imoral ou moral em um lado e outro.

Capitalismo/Comunismo nem deveriam entrar aqui porque seria anacrônico.

O fanatismo

O ponto é, o certo seriam ambos os lados serem educados uns com outros, nem estou falando de respeito.

Porém educação. Mas, ambos os lados políticos no mundo inteiro parece que viraram o cú para lua esperando cair uma chuva de pica.

Eles parecem que querem ser os donos da moral.

Ou seja, demonizaram o seu espectro oposto porque segundo eles é o time que mais mata.

Primeiramente é um absurdo usar mortes de pessoas como argumento moral sobre politica.

Se alguém foi assassinado, o assassino é um doente que nem em sociedade deveria estar.

Sem meias palavras até aqui.

O problema é que hoje em dia estamos olhando o espectro politico da coisa, chorando quando é o nosso, rindo quando é do outro.

Ok! No cú dos outros pimenta é refresco, mas, já pararam para olhar fora do ponto de vista político? não consegue neh?

É trabalho! CARALHO

Só porque um personagem político de direita se junta a de esquerda para entregar um projeto ou fazer uma votação na câmara não significa que ele trocou de lado político.

Pode parecer raro mas existe uma coisa chamado convergência de ideias.

Dois lados opostos podem concordar em algo, não sempre.

Mas, podem concordar.

Como por exemplo, na PEC da blindagem.

A maioria dos de esquerda e direita votando a favor quando deveriam votar contra.

E ninguém liga para nada

E tu que vai se fuder, principalmente quando tem eleição.

Candidato do partido A é de esquerda Candidato do partido B é de direita Candidato do partido C é de esquerda Candidato do partido D é de direita

Ai fica definido que os partidos A e D são os que seriam mais votados porém você é a favor do partido C ou B.

Em vez de votar no partido que concorda com suas ideias vai votar no A ou no D na tentativa de evitar que o partido oposto ganhe.

Virou rinha de galo nesse caralho?

Hoje em dia a gente chama direita tem diversos Sub-rótulos Ideológicos:

• Agrarismo
• Anarquismo
• Democracia cristã
• Comunismo
• Conservadorismo
• Ambientalismo
• Fascismo
• Feminismo
• Política verde
• Hindutva
• Islamismo
• Liberalismo
• Libertarismo
• Monarquismo
• Nacionalismo
• Populismo
• Progressismo
• Radicalismo clássico
• Republicanismo
• Social democracia
• Socialismo
• Sincretismo
• Terceira Via

E isso quando a gente não olha para as propostas individuais.

O desespero

Enfim, não tenho nenhuma intenção ou motivo para tentar te convencer de algo.

Provavelmente esse post vai ser esquecido e jogado em um canto mofado.

Também não estou defendendo nenhum lado politico.

Mas quero manter um pouco de lúcidez enquanto vejo esse titanic desabando, por favor tragam a banda.

Enfim, para mim e para o resto do mundo só basta aguardar o terceiro colapso social.

Colapso Social?

Ok, antes de terminar esse post vou mostrar um pouco das minhas previsões para o futuro próximo.

Antes o disclaimer

Toda previsão é um chute, a única forma de acertar 100% é prever depois do ocorrido.

E outra, não existe previsão de profécia, é chute. Se alguém fala que uma profecia está ocorrendo, ela está errada até se concretizar.

Enfim, da mesma forma que na economia, eu acredito que exista uma correção na própria globalização. Que por algum acaso começou com a revolução industrial.

As guerras mundiais 1ª e 2ª são uma forma de correção que é engatilhado pelo próprio tribalismo.

Veja que tribalismo não é algo anormal em animais sociais.

E se resume praticamente no nós contra eles.

O mundo em si parece novamente estar se dividindo em blocos economicos, e se divergindo cada vez mais. Espero que o próximo colapso não seja outra guerra mundial.

Mas, é mais provável, que ocorra um evento universo 25 não ironicamente no ocidente estamos na fase final da utópia dos ratos.

Então, ou entramos em extinção silenciosa, ou entramos em guerra.

O futuro é medonho.

Enfim, espero que tenha gostado deste post, muito obrigado.

Inicialmente, eu gostaria de dizer que isso é um post de opinião e que qualquer decisão tomada é exclusivamente baseada na sua decisão como pai. Ou seja, leia isso com uma quantidade saudável de sal.

Seres Humanos no Geral não são racionais

Todo esse post no geral vem com essa máxima.

Isso não é uma negação da racionalidade e sim que a maioria das decisões tomadas também são instintos, que de mesma forma são condicionados.

Isso é uma parte importante a se dizer porque, coisas como confiança, hierarquia e … são formados de duas formas.

Confiança

Durante a formação da capacidade racional e com a capacidade racional.

Normalmente, a confiança nos pais é formada antes da capacidade de racionalização e a confiança nos amigos é formada após a formação da racionalização.

Isso nos diz que de alguma forma, na maioria das vezes a confiança nos pais vai ser mais forte.

Até que essa confiança seja quebrada de alguma forma.

Após isso, qualquer confiança formada seria a segunda forma de confiança com racionalização.

A diferença entre ambos é o nível de confiança, um é a confiança incondicional enquanto o outro é a confiança com cautela.

Hierarquia

O mais importante de se tornar pai, é se tornar o topo da hierarquia.

Na visão de que você vai guiar uma versão menor de si mesmo a conseguir sobreviver nesse mundo.

Isso também significa que todos os problemas vão em sua direção, os seus ou o de seu filho.

E como já dito previamente, muitas das coisas da paternidade são desenvolvidos na primeira infância, isso também diz sobre a hierarquia.

A quem os problemas devem ir quando aparecerem.

E é uma discussão muito importante a se resolver.

Muitas vezes, mesmo na primeira infância essa hierarquia vai ser desafiada.

O pai pode dizer não, enquanto a cria vai na mãe fazer a mesma pergunta para ver se a resposta é diferente.

Esse tipo de coisa mostra ao filho, quem tem a resposta mais mansa e a quem ele deve ir para ter o que quer.

Como isso se relaciona a educação

Escapando um pouco da discussão qual a melhor.

Opinião pessoal: Prefiro a tradicional

Todas se relacionam com o nível de autoridade que o pai tem em relação a seu filho.

Na tradicional, o pai assume papel mais autoritário em relação ao filho.

Na positiva, o pai assume um papel mais manipulativo em relação ao filho.

Dando uma dualidade de opções e pedindo pro filho escolher qual lhe agrada melhor.

Exemplo Você prefere guardar os brinquedos e tomar banho ou tomar banho e ir dormir?

Já a permissiva é um nome mais bonito para indulgente.

No geral, a educação permissiva parte da premissa que você vai dar total autonomia para um incapaz se virar, acatando todas as ordens e regras dele.

Porque eu prefiro a educação tradicional

No simples e no grosso, porque é mais simples.

Só que não posso afirmar que é exatamente a educação tradicional também.

É a educação tradicional quando aplicada a alguém que tem 10 anos ou mais. Menos que isso, a abordagem tem que ser mudada.

E o que mudamos?

1º Frustre muito a criança

É meio cruel mas, com isso vem a oportunidade de trabalhar a educação e o controle emocional.

Garanto que vai poupar grana quando o salário chegar e você precisar ir com ela no supermercado.

Opcional: Você não tem a necessidade real de fazer isso, se quiser manter a criança em casa. Este tipo de aprendizado a vida vai ensinar de qualquer forma.

2. Nada de telas até 8/10 anos

Esse entra em contato direto com o 1º.

Muitos dos problemas da paternidade moderno é calar a frustração com as telas em vídeos que são muito mais informativos do que os programas de antigamente.

Fluxos mais rápidos, dialogos complexos e informação audiovisual muito mais animada.

Ao tirar a tela, você volta com o dobro da frustração inicial e isso vai acarretar numa série de problemas como o próprio imediatismo.

3º Celulares são importantes, compre um para seu filho

Não tem como fugir disso, celulares ainda são importantes e seu filho desde pequeno tem que saber usar um.

Mas você como pai se esquece de uma coisa, você não precisa entregar um smartphone.

Um bom e velho dumbphone com tecla e de preferência sem jogos ou outros distrativos é uma recomendação muito melhor do que um Samsung Galaxy S24, Google Z-Fold, Iphone … etc.

A menor idade já passou, o que fazer durante a pré-adolecência/adolecência

Comece respirando fundo, essa é a melhor/pior idade para você e para seu filho, sem sombras de dúvidas.

Então, vamos começar com o liberar algumas coisas.

Primeiro, liberar seu filho para ter um celular decente é um bom começo mas, não faça isso por fazer ou para comemorar algo.

Faça na forma de uma recompensa por ele resolver um problema que você não pediu mas, mesmo assim ele decidiu ajudar.

Não significa dar o top tier, nem um pro, nem mesmo algo caro.

Talvez 1 ou 2 gerações anteriores de preferência.

Além disso, siga uma progressão na lista de coisas a se fazer dentro de casa.

Como por exemplo, ajudar a limpar e tudo mais. Não tudo de uma vez, uma responsabilidade por vez.

E outra, acompanhar seu filho com o family link é crucial.

E apesar da maioria das críticas que o app tem. É super necessário, que você acompanhe o que seu filho faz online.

Apesar de que, tudo vai depender da sua capacidade como pai não ser super-protetor.

Você como pai que já conhece o mundo e sabe quão pobre ele é, deve deixar seu filho rolar um pouquinho no barro, se sujar bastante e tentar se lavar.

Este é a verdadeira paternidade, criar seu filho para que no momento de dificuldade ele ter certeza que pode procura - lo.

Assim dito, o ponto mais importante é você como pai deve enforçar algumas coisas:

• Leitura
• Esportes
• Artes Marciais
• Hobbies

Religião é meio complicado, apesar de ser cristão e católico eu não acredito em batizar meu filho até pelo menos ele por conta própria decidir seguir minha fé ou não.

Não significa não leva - lo a igreja mas, respeitar a decisão de fé do mesmo. Se, e somente se ele decidir que quer seguir minha fé ai sim, eu acredito que o batismo deve ser feito.

E antes de qualquer dúvida razoável, eu já afirmo de primeira.

O Batismo é o sacramento mais importante da igreja cristã. Valendo para os ortodoxos, protestantes ou os católicos em geral.

Seria muito desrespeitoso da minha parte, colocar meu filho a ser batizado sem sua escolha. Para definir sua fé antes que de sua própria vontade, ele também a expresse.

Escolaridade

Não tem muito o que fazer aqui, a educação é a parte mais importante do desenvolvimento de uma criança e adolescente.

O problema é quando correlacionamos a educação a uma motivação extrinseca e logo ela perde o sentido.

Seria interessante pelo menos no mínimo, você como pai, mostrar os pontos mais interessantes da educação.

Para ele se tornar um nerd clássico, um verdadeiro nérdico.

Não vou falar que é porque a educação é importante, principalmente não no Brasil.

Mas, ela é um recurso de conhecimento que abre portas.

Qualquer desejo que um pessoa tenha, pode ser resolvido com o conhecimento, que vai ser adquirido com a educação.

Seja formal, seja autodidata.

E tem mais, por mais que a educação formal no Brasil seja sucateada, ela ainda te dá uma coisa que nenhuma outra te dá.

Um papel dizendo aprovado.

Esse papel reduz a dificuldade de ganhar um emprego com salário razoável, então vale a pena tentar.

Responsabilidade

Como neste ponto, já estamos falando de adolescentes. podemos dizer que a partir daqui, seu filho já pode começar a ser responsabilizado pelos atos sociais ou pela bagunça feita.

Faça um tipo de sistema penal mais leve com possíveis consequências em atos não desejáveis.

A ideia é não ser duro mas ser justo como na vida real.

Além disso, ensinar o que “direito ao contrário” e o “direito a defesa” aparece aqui.

Interessante seria “simular um julgamento”.

Conclusão

Esses são alguns dos meus pensamentos sobre filhos, e como criar eles, coisas a mais, coisas a menos, é sempre importante ter esse tipo de coisa em mente.

Obviamente cada criação é única. E a que você vai oferecer depende exatamente daquilo que você quer passar.

Bibliografia

• Rápido e Devagar: Duas formas de Pensar
• Teoria do Apego
• Disciplina Sem Drama

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}$$ é um grafo que leva de a para b.

Historicamente, foi Leonhard Euler, mesmo criador da identidade de Euler.

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

Publicou em 1736 um artigo sobre o problema das sete pontes de Königsberg.

E este foi considerado o ponto de partida da teoria dos grafos.

Onde grafos são usados?

Dentro da computação em todo lugar diretamente ou indiretamente.

• Redes Neurais
• Estrutura de árvores
• Rede de computadores
• Computação Gráfica
• Redes Sociais

Se precisa de coordenação provavelmente vai ter um grafo incluso.

Fica ainda mais interessante porque Linguagens Formais e Automatos.

Fundamental para a construções de linguagens (programação, regular, marcação).

Também usa grafos como estrutura de representação para automatos e diagramas de transição

Algoritmos de Busca

Como um grafo é formado por relações, contendo ou não um direcionamento.

É necessário sob algum critério percorrer esse grafo.

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

Qual critério?

Normalmente ou estamos trabalhando com grafos esparsos ou grafos densos.

Sendo grafos esparsos aqueles que tem poucas arestas em relação ao número de vértices.

E grafos densos aqueles que tem muitas arestas.

Essa caracteristica influência diretamente a escolha do algoritmo de busca 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 primeiros 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.

• Ótimo em arestas unitárias vai encontrar o caminho mais curto em termo de números de passos.

• Complexidade:

• Vai ter o tempo de percorrer $$O(V + E)$$ ou seja o tempo para percorrer todos os vertices e arestas.

• 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 a fila e 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

• Completo? Em grafos finitos mas, não garante o caminho mais curto em grafos não ponderados.

• Ó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 em recursão pode estourar a pilha em grafos muito profundos, prefira uma versão iterativa.

Lógica passo a passo

1. Marca 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 mesma complexidade assintótica $$ O(V+E)$$ mas, se aplicam a cenários distintos.

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

Ademas, espero que tenham gostado do post e valeu

Este é um pequeno blog feito para distribuir conteúdo nérdico. Através da Grande Rede Mundial de computadores.

Quem sou eu?

Meu nome é Arthur tenho no momento da criação deste post 23 anos.

Sou um estudante de Ciências da Computação na Universidade Federal de Lavras.

Tenho curiosidade em diversos assuntos, então você provavelmente vai me ver falando de assuntos:

• Otaku
• Geek
• Nerd
• Gamer

Sobre:

• Eletrônica
• Economia
• Politica

… e por ai vai.

Enfim, bem vindos a este novo começo.