lgcosta
cc67531602
O problema da primeira serie era a sensacao de 'quadro a quadro': a captura era a saida de um script despejada em blocos. Agora cada video e uma sessao shell de verdade. - record.py: abre um pty, faz SSH no firewall e digita os comandos tecla a tecla (~34 c/s, com jitter). O tty remoto ecoa, o kernel responde ao vivo; a captura e asciicast v2 com timestamps. 'bash --noediting' evita que o editor de linha redesenhe o comando e o tty o repita (a linha aparecia duplicada). - record.py --pace: segura a tela enquanto a voz fala - cada batida dura o trecho de audio que a acompanha, de modo que uma unica captura serve as duas versoes de idioma. - record.py --ensure-pf: garante pf.ko carregado antes de gravar. Sem isso uma fase que roda 'rmmod' (ativacao) pode derrubar o /dev/pf de outra gravacao concorrentes - foi exatamente o que quebrou a fase de roteamento na primeira tentativa. - make_audio.py: geracao da narracao pelo MiniMax TTS, uma voz feminina por idioma (English_ConfidentWoman / Portuguese_ConfidentWoman), um arquivo por segmento. A API devolve o audio em hexadecimal, nao base64. - render_video.py: reproduz a captura por um emulador de terminal e escreve os frames direto no ffmpeg como RGB bruto (um PNG por frame era uma ordem de grandeza mais lento). Desenha o diagrama de rede do lab por cima do terminal nas fases de roteamento e balanceamento, destacando o caminho em discussao, e queima a legenda da narracao. - assemble.py: mixa os segmentos de audio na linha do tempo. - join.py: emenda as fases com crossfade sobre um cartao de capitulo e sincroniza o audio na mesma linha do tempo. - build-all.sh: roda o pipeline inteiro. Arte de fundo e audio vem do MiniMax; a geracao de video do MiniMax nao esta habilitada nesta conta (erro 2068 em todos os modelos), entao as transicoes sao renderizadas localmente com ffmpeg. 16 videos: 7 fases + filme completo, em ingles e portugues, com legenda queimada.
Documentação PF-on-Linux (português)
English documentation: docs/en/README.md.
Este é o conjunto de documentação de usuário do port do PF do OpenBSD 8.0
para o Linux 7.3.4 — o engine PF de verdade (pf.c, pf_norm.c,
pf_table.c, pf_lb.c, …) rodando como módulo out-of-tree pf.ko,
controlado pelo pfctl real do OpenBSD pela ABI ioctl de /dev/pf.
Índice
| Documento | Conteúdo |
|---|---|
| guide.md | Arquitetura em uma página: componentes, caminho de dados, plano de controle, milestones |
| install.md | Receita de aplicação/build/instalação (kernel, módulo, ferramentas) |
| build.md | Pipeline de build em detalhe: fetch → vendorize → kernel → módulo → pfctl |
| vm-lab.md | Bancada de validação em libvirt: topologia, recriar/rodar, o que cada gate prova |
| feature-matrix.md | Status por feature: VERIFIED-in-VM / COMPILES-untested / PENDING-Mx |
| pf-guide.md | Uso diário: o que funciona hoje em /etc/pf.conf, o que evitar até M3/M4 |
| patches.md | Patches de core do Linux (hoje vazio) + regras e template para futuros 000N-*.patch |
| caveats.md | Divergências conhecidas de comportamento e limitações atuais |
Fontes de verdade
A documentação descreve o código como ele existe na árvore. Em caso de dúvida, as referências autoritativas são:
docs/superpowers/specs/2026-11-11-pf-linux-port-design.md— designdocs/superpowers/plans/2026-11-11-pf-linux-port.md— plano de milestones (tarefas T1–T19)docs/porting-notes.md— log de staging + registro de desvios da camada de compat (M1)
Vocabulário de status usado em todos os documentos:
- VERIFIED-in-VM — exercitado de ponta a ponta na bancada libvirt (ver vm-lab.md).
- COMPILES-untested — o código compila no
pf.ko, mas nenhum gate provou o comportamento ainda. - PENDING-Mx — entra (ou entra por completo) no milestone Mx; o comportamento observável hoje está documentado.