Smart TVs entram na rota da raspagem de IA, e Linux revê fork + exec

Tem dispositivo em casa que parece só tela. Também é computador, rede, app store e SDK de terceiros rodando quieto no canto. A história de hoje começa nesse caminho pouco visível: tráfego de raspagem saindo com cara de acesso residencial comum.

Smart TVs podem entrar na economia de proxies para raspagem de IA

A Include Security publicou, em junho de 2026, uma pesquisa sobre o SDK da Bright Data e o uso de apps de consumidor, incluindo apps móveis e de Smart TV, como parte da oferta de proxies residenciais. A Bright Data documenta publicamente um produto de proxy residencial com mais de 400 milhões de IPs residenciais.

O ponto incômodo é bem concreto. Quando um serviço de raspagem quer parecer menos com datacenter e mais com acesso humano comum, tráfego saindo de IP residencial tem valor. Se esse caminho passa por SDK dentro de aplicativo, a discussão deixa de ser só “privacidade” e entra em arquitetura de rede, cadeia de fornecimento de app e visibilidade operacional.

A pesquisa descreve uma separação entre plano de controle e plano de dados. Em termos menos bonitos: uma parte cuida de configuração, telemetria e coordenação; outra carrega o tráfego de par a par. Segundo os pesquisadores, isso pode criar pontos cegos, especialmente no iOS, quando a conexão de dados usa NWConnection com requiredInterface e passa por caminhos que ferramentas baseadas em CFNetwork ou URLSession nem sempre enxergam bem.

Smart TV encaixa bem aqui porque costuma ficar ligada, tem banda, recebe app de loja própria e raramente é tratada como máquina que merece inspeção. Muita gente olha notebook, celular corporativo, servidor e roteador. A televisão fica ali, quieta, com um controle remoto que nunca pediu para participar de uma economia de proxy.

O limite também importa. A pesquisa fala de SDK, consentimento e visibilidade em apps; não prova uma invasão universal de TVs. Proxies residenciais comerciais podem ser legais. A pergunta prática é quem está autorizado a rotear tráfego por dentro da sua rede, como esse consentimento aparece, e que tipo de inventário você tem sobre apps instalados em dispositivos que não parecem computador.

Para defesa, começa pelo básico: inventário de apps em frota gerenciada, revisão de SDK em binários quando isso fizer sentido, política de DNS e SNI no roteador ou gateway, e algum nível de visibilidade para dispositivos que normalmente ficam fora do radar. Em casa, dá para revisar apps instalados, bloquear o que não usa e olhar logs do roteador quando ele permite. Em empresa, TV de sala de reunião também é endpoint. Meio sem graça, mas é.

Fontes: Include Security e Bright Data Docs.

Linux discute spawn templates para acelerar ferramentas repetidas

No Linux, outro assunto bem Unix voltou a aparecer: criar processos. Li Chen publicou, em 28 de maio, uma série de 13 patches RFC para o kernel Linux propondo spawn templates, uma ideia para acelerar partidas repetidas do mesmo executável. A análise da LWN, publicada em 5 de junho, coloca a proposta no lugar certo: interessante, mas ainda longe de virar API final.

O motivo passa pelo básico. Em sistemas Unix, é comum um processo fazer fork() para criar uma cópia de si mesmo e depois chamar exec() para trocar essa cópia pelo programa que realmente vai rodar. Esse desenho é elegante e antigo. Também pode cobrar custo quando um runtime dispara muitas ferramentas pequenas o tempo todo.

O próprio RFC cita esse tipo de carga: agentes e runtimes chamando rg, git, sed, awk, python, node e wrappers de shell em sequência. Build systems, shells e ferramentas de automação têm a mesma cara. Se cada passo precisa iniciar outro binário, a fronteira entre processo, arquivo executável e ambiente vira parte do desempenho percebido pelo usuário.

A proposta expunha chamadas como spawn_template_create() e spawn_template_spawn(), para reutilizar parte do preparo de executáveis repetidos. A reação dos mantenedores foi cuidadosa. Pelas fontes, há resistência a transformar detalhe de cache ou template na API pública. Christian Brauner e outros revisores apontaram para algo mais genérico, possivelmente perto de um construtor de spawn com pidfd ou ideias do pidfs.

A LWN diz que a série atual não deve ser aceita como está, e os ganhos de benchmark citados são modestos. A conversa ainda vale porque mostra onde a dor está aparecendo: ferramentas modernas, inclusive agentes, voltaram a fazer o sistema operacional sentir cada programa pequeno que elas chamam.

Se isso um dia virar uma primitiva mais limpa, talvez shells, CLIs, builds e agentes ganhem uma partida de processo menos cara. Por enquanto, é discussão de kernel, API e manutenção. A parte boa de acompanhar RFC é essa: a gente vê a peça antes de ela ganhar pintura de release note.

Fontes: LWN e Patchew / LKML.

Destaques rápidos

• Guix mostrou que uma derivação pode atravessar para o mundo Nix. Farid Zakaria publicou em 5 de junho um experimento em que uma derivação do Guix é construída pelo Nix, usando /gnu/store como store e uma ferramenta chamada guix-transfer para traduzir o grafo. O detalhe técnico: Nix e Guix têm linguagens e comunidades diferentes, mas ambos descem para receitas de build de baixo nível. A ressalva pesa: reconstruir parte do bootstrap pode levar horas e até exigir mexer em filtro de syscall do Nix. Fontes: Farid Zakaria e Nix Reference Manual.

• Zeroserve transforma configuração de servidor em programa eBPF em userspace. O anúncio de 6 de junho descreve um servidor HTTPS em Rust que serve um site inteiro de um tarball, indexa faixas de bytes em vez de desempacotar tudo, usa io_uring, fala em HTTP/2 e TLS 1.3, e permite hot reload com SIGHUP. A parte diferente é usar eBPF em userspace como camada de comportamento para rota, autenticação, rate limit, reescrita e proxy reverso. Os benchmarks são do autor, com limites como design single-threaded e casos em que NGINX ainda pode vencer. Fonte: su3.io.

• Treehouse dá um número estável para cada Git worktree. O projeto é pequeno, mas resolve uma irritação real: duas branches do mesmo projeto brigando por PORT, banco local, Redis ou porta publicada no Docker. O CLI em Go guarda um número em metadados locais do Git, expõe comandos como treehouse init, treehouse current, treehouse offset e treehouse run, e injeta WORKTREE_NUMBER sem colocar configuração gerada no repositório. Ainda é v0.1.0 e tem adoção pública pequena; como padrão mental para ambiente local paralelo, é bem aproveitável. Fonte: GitHub / stemps/treehouse.

Agentes ajudam mais quando a mudança continua pequena o suficiente para ler

Eli Bendersky publicou em 6 de junho um relato sobre começar projetos com agentes de LLM. O projeto concreto era watgo, uma implementação em Go e WebAssembly construída com ajuda significativa de agentes. O texto é útil justamente porque não cai nem no oba-oba, nem no “desliga tudo e volta para 1998”.

A recomendação dele é prática: escrever notas de design que entram no repositório, pedir changelists pequenas e lógicas, acompanhar diff local enquanto o agente trabalha, revisar antes de commitar manualmente, criar testes cedo e evitar código que você não entende. Go aparece como parte do relato porque a legibilidade ajuda quando o trabalho humano vira ler mais do que digitar.

O Treehouse conversa com isso por um motivo simples. Trabalho com agente costuma multiplicar tentativas: uma branch para experimento, outra para correção, outra para refatoração pequena. Se cada worktree tem ambiente previsível e cada mudança cabe na cabeça de alguém, o agente fica mais parecido com uma ferramenta de execução e menos com uma caixa que cospe arquitetura no seu colo.

O próprio Eli separa protótipo descartável de projeto que você pretende manter. Em protótipo, dá para deixar a máquina correr mais solta. Em código que vai ficar, o limite continua humano: você precisa conseguir ler, testar, explicar, desfazer e ensinar o próximo dev a mexer. O teclado pode acelerar. A responsabilidade pelo diff não foi embora.

Fonte: Eli Bendersky.

Nota: gerado por IA (The Paper LLM), com fontes originais listadas por bloco.