Claude escrevendo um driver para macOS para minha obscura impressora HP feita apenas para Windows

Artigo original ↗ Discussão no Hacker News ↗

Um experimento usando o modelo de IA Claude para fazer uma impressora a laser HP que só funcionava no Windows operar no macOS provoca reflexões mais amplas sobre como modelos de linguagem grandes podem reviver hardware sem suporte, de impressoras e scanners a controles de videogame e dispositivos industriais. Comentadores compartilham inúmeros exemplos de usar IA para engenharia reversa de protocolos, adaptar drivers Linux ou Windows e criar ferramentas de nicho que jamais teriam tido tempo ou conhecimento para construir sozinhos. Outros questionam alegações de marketing de que a IA “escreveu um driver” quando, na verdade, apenas envolveu componentes Linux existentes, levantando preocupações sobre precisão, segurança, uso de energia e o que isso significa para o trabalho tradicional de programação de baixo nível.

Resultado Principal

  • A discussão trata de usar um LLM (Claude) para fazer uma impressora laser HP/Samsung apenas USB funcionar no macOS, apesar de não haver driver do fabricante.
  • A solução inicial reutilizava o componente “Unified Linux Driver” (ULD) da HP dentro do Docker, fazendo a ponte para a impressão no macOS.
  • Após críticas, o projeto foi atualizado para uma configuração “totalmente nativa do macOS”: extraindo o filtro rastertospl do driver Linux, conectando-o à pilha CUPS do macOS, além de uma pequena ponte USB.

Isso é mesmo um “driver”?

  • Alguns argumentam que isso não é um driver verdadeiro para macOS, mas sim um wrapper em contêiner ou em userland em torno de um binário Linux existente.
  • Outros contrapõem que qualquer camada de software que permita ao sistema operacional falar com o hardware qualifica como driver, mesmo que incorpore outro sistema operacional ou binário.
  • Críticos chamam o título/README de enganoso e veem isso como uma manobra de marketing; defensores dizem que a única coisa que importa é “a impressora não funcionava, agora funciona”.

LLMs como ferramentas de engenharia reversa

  • Muitos compartilham histórias parecidas de sucesso: escrever ou adaptar drivers e ferramentas para:
    • controles de videogame e botões extras, interfaces MIDI, scanners, impressoras, lâmpadas BLE, displays e-paper, controladores de carrinho de golfe, câmeras USB, impressoras de etiquetas, apps de áudio/vídeo, formatos antigos de CAD etc.
  • O padrão comum: fornecer especificações, capturas USB/Bluetooth, dumps de firmware ou trabalhos anteriores; o LLM itera através de muitas etapas tediosas.
  • A engenharia reversa é descrita repetidamente como um “ponto ideal” para LLMs: bem especificada, verificável e tediosa.

Ceticismo, risco e trade-offs

  • Surgem preocupações sobre:
    • Segurança (launchers com root, execução de código opaco, stacks em contêiner).
    • Manutenção e falta de upstream de correções geradas por IA.
    • Exagero: às vezes as soluções poderiam ser encontradas com projetos existentes ou um pouco de googling.
    • Trade-offs de energia/recursos versus simplesmente comprar uma impressora nova.
  • Outros observam que LLMs frequentemente falham ou entram em loop em casos mais difíceis; o sucesso não é garantido.

Reflexões mais amplas

  • A discussão se expande para:
    • Lock-in de fornecedores e APIs restritas de hardware (NFC, UWB, scanners, impressoras).
    • Esperança de que a IA torne ferramentas customizadas e “computação pessoal” reais novamente.
    • Preocupações com o futuro do trabalho de driver em baixo nível, mas também entusiasmo com a possibilidade de ressuscitar hardware antigo.