Tudo azul

Tudo começou com um suporte para o BlueSCSI que instalei no Performa 450 (já falei desse Mac aqui, quando estava tentando recuperar o conteúdo do disco rígido usando o Linux). Eu tinha encontrado o modelo pronto na internet, um arquivo 3MF disponibilizado através do site do BlueSCSI, e precisava de uma impressora para transformá-lo em objeto.

Acabei conseguindo uma Creality Ender 3 Max usada, por um preço bom, e com ela veio a primeira lição: impressora muito barata raramente chega pronta para imprimir. No transporte, a estrutura da impressora saiu toda do lugar, foi preciso afrouxar os parafusos e com um esquadro colocar tudo no lugar. Depois os fios de um dos motores foram esmigalhados também, tive que encurtar e fazer um remendo com solda.

O anúncio falava que era uma Ender 3 Neo, a etiqueta na máquina confirmava, testei todos os firmwares que a Creality oferece para a Neo, mas nada fazia ela inicializar corretamente. Toca a desmontar a impressora toda de novo para olhar a placa-mão. Versão 2.4.7, as Neo não usam essa versão. Cruzando informações de firmwares possíveis, descobri que o sensor que mede a altura da mesa não poderia ser um CR Touch, teria que ser um BL Touch – o único que se junta a esse tipo de placa-mãe. Bom, são as Max que têm essa combinação, sabe-se lá como a etiqueta e a placa-mãe se uniram. Vinte e sete firmwares depois, ela ligava e completava um ciclo de Auto Home.

Ainda assim, a extrusão não se comportava. O tubo Bowden não assentava direito, o bico estava suspeito, e por um momento a pergunta foi se valia a pena consertar. A conclusão foi que sim. Peças novas custam pouco, e em troca eu ganhava uma máquina com uma área de impressão razoável e, de quebra, um projeto para aprender junto com meu filho como aquela coisa funciona por dentro.

No AliExpress encontramos um kit para trocar tudo de uma vez só num preço que não nos assustou. Assunto resolvido.

Há algo de apropriado nisso. A primeira experiência com impressão 3D não foi apertar um botão e ver a peça sair, e sim encontrar uma máquina que não funcionava direito e descobrir por quê. É meio o equivalente, no mundo da impressão 3D, a garimpar coisas na caçamba.

O caminho até a primeira peça ficou claro depois de algumas tentativas: abrir o modelo no Cura, escolher o perfil da Ender 3 Max, fatiar, salvar o G-code no cartão SD, nivelar a mesa, acertar a altura do bico e assistir à primeira camada. Foi aí que descobrimos que o Z Offset é muito mais importante do que parece. Fizemos umas tantas tentativas até que a primeira camada ficou perfeita e já tinha a forma da peça que queríamos.

E aí veio a primeira peça pronta, colada no vidro. A dúvida seguinte foi como tirá-la de lá sem quebrar nada. A resposta foi paciência: esperar a mesa esfriar completamente e deixar o próprio vidro soltar a peça.

A impressora continua funcionando, e desde então ela não parou. Vieram alguns ganchos para organizar os cabos de áudio, que viviam embolados, e uma moldura para um interruptor num amplificador improvisado, que deixou o projeto com cara de coisa acabada em vez de gambiarra (ou, pelo menos, de gambiarra bem-vestida). Também imprimi uma manivela de rebobinar (rewind crank) para uma câmera compacta Olympus, daquelas peças pequenas que ninguém vende avulsas e que fazem toda a diferença, e algumas placas de engate rápido no padrão Arca-Swiss para o tripé. Essas foram uma surpresa: peça funcional, que aguenta peso, com encaixe preciso, saída de uma impressora que semanas antes nem extrudava direito.

Tudo isso foi impresso com o mesmo carretel de PLA azul. Não foi uma decisão estética, foi simplesmente o filamento que eu tinha ganhado meses atrás, antes de ter impressora. Que até serviu de empurrãozinho para esse projeto andar.

E o título se escreveu sozinho. Para nós, brasileiros, ‘tudo azul’ quer dizer que está tudo bem. Uma impressora que chegou meio quebrada, foi consertada aos poucos e agora produz peças úteis para a casa merece a expressão. Por enquanto está tudo azul. Literalmente.

Um banquinho e um servidor

Há uns tempos ganhei um par de servidores. Dois Dell PowerEdge 1950, sendo que o melhor deles tinha dois Xeons a 3.0GHz lá dentro — hardware que já teve o seu auge, mas que hoje é essencialmente um aquecedor barulhento. É extremamente ruidoso, gasta muita energia para o que consegue processar comparado com qualquer coisa moderna, e para piorar: não tem entrada nem saída de áudio, nem dá para usar uma placa gráfica nele.

Nem sequer faz um beep. No terminal, digite: echo -e “\a” para enviar um sinal ASCII. Ou instale a ferramenta beep (sudo apt install beep no Debian ou Ubuntu). Com beep dá até para usar parâmetros como: beep -f 300 -l 200 para selecionar uma frequência de 300Hz e duração de 200 millissegundos.

A pergunta óbvia era: o que fazer com isto? Sem placa gráfica, processar vídeo ou imagem seria muito lento e gastaria muita eletricidade. A resposta menos óbvia foi: transformá-lo numa fonte de som ao vivo.

Servidores não têm placa de som, mas têm portas serial — e uma porta serial, no fundo, não passa de um pino que sobe e desce entre dois níveis de tensão a um ritmo que se controla por software. Se conseguisse controlar esse ritmo com precisão suficiente, talvez desse para o usar como uma espécie de DAC (conversor digital-analógico) muito rudimentar — de 1 bit — e ligar isso a um aparelho que amplificasse o sinal.

A vontade era que o som final não fosse somente o tom gerado pela porta serial, mas a mistura dele com o próprio ruído do servidor — as ventoinhas, o zumbido interno — como se a máquina fosse, ela própria, um instrumento ao vivo. Ventoinhas é eufemismo nesse caso, os PowerEdge tem 8 pequenas turbinas que operam em média a 4000 rpm, mas que podem chegar a 15000 rpm.

Os primeiros testes

Antes de soldar seja o que for, testei a ideia diretamente na linha TX da porta serial:

sudo stty -F /dev/ttyS0 9600 cs8 -cstopb -parenb
while true; do printf '\x55'; done | sudo tee /dev/ttyS0 >/dev/null

Com um osciloscópio no pino, apareceu uma onda quadrada de cerca de 10V pico a pico, com ciclos de 200 microssegundos — exatamente o que se esperava de um byte alternado 01010101 a 9600 baud. A prova de conceito estava feita: dava para gerar sinal com aquilo.

O circuito

O passo seguinte foi construir uma interface segura entre a porta serial e um jack de 1/4″. A ideia é simples: atenuar os ~10V da RS-232 até um nível de linha razoável, e garantir que não passa nenhuma tensão contínua perigosa para o amplificador.

DB9 TX (pino 3) ──[10k]──┬──[1uF]──── TIP do jack
│
[1k]
│
DB9 GND (pino 5) ─────────┴────────── SLEEVE do jack

Um divisor resistivo de 10k/1k baixa o sinal para cerca de 1V pico a pico, um condensador em série bloqueia qualquer deriva de tensão contínua. Devia ter usado também um transformador de isolamento de áudio 600:600Ω entre a saída e o jack para evitar os problemas de ground loop que surgem naturalmente quando se ligam dois aparelhos com ligações à terra independentes (o servidor e o amplificador), mas por enquanto ainda não senti falta dele.

O software

Gerar uma onda quadrada fixa é fácil. Gerar qualquer coisa mais interessante exige outra abordagem: modulação por densidade de pulsos (PDM). Em vez de enviar bytes fixos, um modulador sigma-delta de primeira ordem converte cada amostra de áudio (entre -1 e 1) num único bit, cuja densidade ao longo do tempo aproxima a forma de onda desejada. Empacotam-se 8 desses bits por byte, e escreve-se o resultado diretamente para o descritor de ficheiro da porta serial.

O programa (servnoise.c) acabou com quatro modos:

  • tone — um tom fixo, para verificar a fiação
  • telemetry — o tom segue, ao vivo, a temperatura e a carga do CPU
  • noise — ruído branco filtrado
  • popcorn — o modo mais elaborado, descrito a seguir

Afinar ao ouvido

A dada altura usei um afinador no smartphone para medir o zumbido real que as ventoinhas do servidor produzem: por volta dos 932Hz — que, por coincidência feliz, é praticamente um Bb5 na afinação padrão. Em vez de competir com esse zumbido, o tom gerado nos modos tone e telemetry ficou afinado a 233Hz (Bb3, duas oitavas abaixo), para se sentar por baixo do som do servidor em vez de lhe fazer frente.

A estrutura do popcorn

O modo popcorn gera estalos curtos e irregulares — como milho a estourar — com durações e espaçamentos escolhidos aleatoriamente dentro de conjuntos fixos. Mas o que o torna interessante é a estrutura maior por cima disso: um ciclo de 255 segundos onde, entre os 2:00 e os 3:00 minutos, o padrão aperta (estalos mais curtos, mais próximos entre si), com dois pequenos “avisos” aleatórios nos primeiros dois minutos — rajadas curtas do padrão rápido, como uma prévia do que aí vem — e 15 segundos de silêncio no fim de cada ciclo, só para deixar claro a quem está a ouvir que o padrão acabou de dar a volta.

Um imprevisto no fim

Ao instalar o serviço para arrancar automaticamente no boot, apareceu um erro inesperado: “System has not been booted with systemd as init system”. Afinal este servidor onde instalei Linux MX (meu predileto) corre um SysV init tradicional — nada de systemctl por aqui. A solução foi um script de init clássico com start-stop-daemon, e agora o servnoise arranca sozinho assim que o servidor chega ao ecrã de login.

Tudo isso (systemd e init) está no Github: https://github.com/refotografia/Server-Noise-Thing

O nome

“Um banquinho e um violão” é uma frase que ficou associada ao minimalismo da Bossa Nova — bastava isso, um banquinho e um violão, para tocar.

A minha versão troca o violão por um servidor.

Livrinhos, anos depois…

Em 2021, durante o período de isolamento, comecei a experimentar suportes alternativos para impressão. Na falta de um papel que me interessasse, voltei a atenção para materiais que já tinha à mão: o cartão de uma caixa de cereais e o de uma pasta de documentos. O que me chamou a atenção foi sobretudo a textura e a resistência desses materiais, mas também a possibilidade de que suas características superficiais passassem a fazer parte da própria imagem.

As primeiras impressões revelaram imediatamente tanto as possibilidades quanto as limitações desses suportes. A tinta demorava a ser absorvida, acumulava-se na superfície e produzia uma imagem de resolução irregular, mas, ao mesmo tempo, os pretos eram profundos e a textura do cartão passava a fazer parte da imagem. O resultado estava longe de ser uma impressão convencional, mas justamente por isso pareceu-me interessante continuar experimentando.

Algumas dessas primeiras impressões ficaram guardadas desde então. Agora, alguns anos depois, voltei a elas para transformá-las em um pequeno livro.

Comecei por colar algumas dessas imagens em folhas de um bloco de aquarela. Deixei a folha um pouco mais longa para o lado esquerdo e fiz uma dobra. Assim a folha ocupa a espessura total (folha mais foto) na lombada também.

Furei as folhas com uma furadeira e uma broca para madeira e costurei com linha de costura para pesponto.

Seguindo a ideia original das impressões, encontrei uma caixa de sabão para lavar roupas que tinha a espessura perfeita para essa capa. Aproveitei um pedaço de pano marrom e fiz a lombada a olho. Podia ter ficado um bocadinho mais larga.

Com um pouco de cuidado e carinho, colei o miolo que estava pronto e seco dentro da capa. Usei mais uma folha grande do papel de aquarela para fazer uma grande luva para o miolo.

O tecido da capa não ficou super bem colado, ainda preciso aprender como fazer isso melhor. Infelizmente a cola branca se espalhou um pouquinho demais e colou um pouco mais do que a área da lombada. Ao abrir o livro pela primeira vez, aconteceram uns pequenos descolamentos que ficaram bem visíveis. Acho que vou cobrir essa área com um pedaço de papel branco (que ainda vai ajudar a deixar o livro mais durável).

Apesar desses pequenos problemas, o livrinho está pronto. E acho que isso me deixou com vontade de fazer outros, aproveitando as cópias que tenho guardadas de trabalhos diversos desses anos todos de fotografia. Tem de tudo: cópias analógicas, cópias digitais como essas, diferentes tipos de papel e processos que atravessam quase três décadas, desde os anos 1990.

Já tenho um segundo miolo pronto, com fotos dos carrinhos dos vendedores de doces que circulam pelas ruas de Paraty. Talvez esse seja o começo de uma pequena coleção de livros feitos a partir dessas cópias que foram ficando por aqui ao longo dos anos.

Um leitor de impressões digitais

Há qualquer coisa de particularmente interessante em encontrar um periférico antigo e, em vez de simplesmente tentar fazê-lo funcionar, perguntar: o que será que este objeto ainda consegue fazer?

Achei no lixo, esses dias, um pequeno leitor de impressões digitais da Microsoft. Nem sei dizer que grande utilidade prática esse objeto ainda tem hoje.

Através de buscas na internet descobri que um sensor desses utiliza os princípios da luz e da refração interna para capturar o desenho das cristas e valas do dedo. Quando o dedo toca a superfície de vidro, as áreas de contato direto (cristas) alteram o caminho da luz por reflexão frustrada, enquanto os espaços vazios (valas) refletem a luz de maneira diferente, permitindo que um sensor crie uma imagem em alto contraste. Além disso um sensor de proximidade permite ao dispositivo saber quando realizar a captura da imagem.

Liguei-o ao meu HP xw4600, que tem sido uma espécie de bancada de experiências para estas coisas, e fui ver o que o Linux tinha a dizer sobre ele. A primeira resposta veio do lsusb:

Bus 005 Device 002: ID 045e:00bd Microsoft Corp. Fingerprint Reader

O dispositivo estava vivo. O passo seguinte foi olhar com um pouco mais de atenção para o dispositivo:

lsusb -v -d 045e:00bd

O resultado mostrou um dispositivo USB 2.0 a funcionar a Full Speed, 12 Mbps. Não havia ali uma interface genérica de scanner ou de câmara que pudesse ser simplesmente aberta por um programa qualquer. A interface era:

bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol

Ou seja, o leitor não se apresentava ao computador como uma simples fonte de imagens. Havia alguma coisa entre o sensor e o sistema operativo que teria de saber falar a língua daquele aparelho.

Tenho instalado no MX Linux o libfprint, uma biblioteca open source para leitores de impressões digitais. Ao experimentar:

fprintd-list "$USER"

o sistema respondeu:

found 1 devices
Device at /net/reactivated/Fprint/Device/0
Using device /net/reactivated/Fprint/Device/0
User guilherme has no fingers enrolled for Digital Persona U.are.U 4000/4000B/4500.

O leitor Microsoft é um Digital Persona U.are.U 4000/4000B/4500.

A utilização habitual do libfprint é bastante clara: cadastrar uma impressão digital e depois utilizá-la para autenticação. Experimentei:

fprintd-enroll "$USER"

O sistema pediu um dedo. Coloquei-o sobre o leitor. E apareceu:

Enrolling right-index-finger finger.
Enroll result: enroll-stage-passed

Funcionava. Mas, naquele momento, a minha curiosidade já era outra. Se o leitor consegue capturar uma impressão digital, será que consigo simplesmente obter a imagem? Queria chegar um pouco mais perto daquilo que o aparelho efetivamente produz.

O fprintd é uma interface relativamente confortável para utilizar leitores de impressões digitais. Para este experimento, porém, era interessante descer um nível e conversar diretamente com o libfprint. Instalei os headers de desenvolvimento e comecei a consultar a API disponível no sistema. Os próprios headers instalados no sistema mostraram o caminho. O arquivo fp-image.h tinha a possibilidade de acessar diretamente um FpImage. A função que me interessava acabou sendo:

fp_device_capture_sync()

Ela permite pedir ao dispositivo uma captura e receber de volta um FpImage. Escrevi um pequeno programa em C que abre o dispositivo, espera pelo dedo, captura uma imagem e grava os dados como um arquivo PGM. O PGM é um formato extremamente simples para imagens em tons de cinza, já falamos dele aqui no blog.

O programa começou por ser executado normalmente:

./capture_fingerprint

Mas o Linux respondeu:

libusb: error [get_usbfs_fd] libusb couldn't open USB device
libusb: error [get_usbfs_fd] libusb requires write access to USB device nodes
Could not open device: USB error on device 045e:00bd : Access denied

Mais uma camada do objeto aparecia. O fprintd conseguia utilizar o leitor, mas o meu pequeno programa não tinha permissão para abrir diretamente o dispositivo USB. Para confirmar que esse era o único problema, executei:

sudo ./capture_fingerprint

E então aconteceu.

Opening fingerprint reader...
Place your finger on the reader...
Capture successful!
Image size: 384 x 290
Image data: 111360 bytes
Saved: finger_001.pgm

O arquivo finger_001.pgm tinha acabado de transformar aquilo que, alguns minutos antes, era apenas um dispositivo USB identificado como 045e:00bd numa coisa muito mais concreta: um conjunto de pixels que podia ser guardado, aberto e analisado.

Abri o arquivo no GIMP.

Depois de confirmar que a captura funcionava, fiz uma pequena alteração no programa. Em vez de sempre gravar:

finger_001.pgm

queria que cada captura tivesse a data e a hora. Passei a usar nomes como:

finger_2026-08-12_11-00-43.pgm

Assim evita que uma nova captura simplesmente destrua a anterior. E também não queria terminar com um programa que precisasse ser executado como root. A solução foi criar uma regra udev:

SUBSYSTEM=="usb", ATTR{idVendor}=="045e", ATTR{idProduct}=="00bd", MODE="0660", GROUP="plugdev"

O meu utilizador já fazia parte do grupo plugdev. Depois de recarregar as regras e voltar a ligar o leitor, o dispositivo passou a aparecer com permissões:

crw-rw---- 1 root plugdev ...

E finalmente:

./capture_fingerprint

Ainda preciso ver o que cria aquele retângulo escuro no centro da imagem, talvez o leitor já tenha passado dias melhores… O que o programa faz simplesmente é receber um FpImage fornecido pelo libfprint. O driver pode fazer algum processamento, normalização ou outra transformação antes de entregar essa imagem à aplicação, isso eu já não sei.

Bom, não se trata apenas de fazer um aparelho antigo funcionar. Trata-se de descobrir as camadas que normalmente não vemos: identificação USB, driver, biblioteca, API, permissões, imagem, formato de arquivo. Cada camada que se torna compreensível reduz um pouco a opacidade do objeto.

Uma das coisas que mais gosto nestas experiências com tecnologia descartada: muitas vezes não sabemos exatamente onde vamos chegar quando pegamos num objeto.

O programinha e a regra udev estão disponíveis aqui: https://github.com/refotografia/Microsoft-Fingerprint-Reader-Thing

Projeto Caixa Preta • Intercalando vídeos

Precisava construir um vídeo alternando entre duas gravações produzidas por percursos completamente diferentes. De um lado, uma Axis P1354 gravando diretamente em H.264, a 1280×720 e 30 fps, registando o que acontecia sobre a mesa da instalação. Do outro, o sinal de vídeo proveniente de um DVD Player, manipulado sobre essa mesma mesa, capturado por um Doctor Video e gravado em 720×480. Mais do que juntar duas resoluções diferentes, interessava-me colocar em diálogo dois pontos de vista sobre o mesmo acontecimento: um mostrando os gestos, os dispositivos e o espaço da instalação; o outro mostrando a imagem que circulava entre esses dispositivos.

O primeiro passo foi preparar os dois ficheiros, recortando apenas os trechos que seriam utilizados na montagem.

ffmpeg -ss 00:00:30 -t 120 -i axis.mkv \
-c copy axis_trim.mkv
ffmpeg -ss 00:00:55 -t 120 -i doctor.mp4 \
-c copy doctor_trim.mp4

Em seguida, normalizei os parâmetros para que ambos pudessem ser utilizados no mesmo projeto. O Doctor Video gravava em 720×480 e apresentava uma taxa de quadros algo irregular, por isso optei por convertê-lo para 30 fps e inseri-lo num quadro de 1280×720 através de um pad, preservando a resolução original da imagem em vez de a ampliar artificialmente.

ffmpeg -i doctor_trim.mp4 \
-vf "fps=30,pad=1280:720:(ow-iw)/2:(oh-ih)/2:black" \
-c:v libx264 -crf 20 -preset slow \
-c:a aac -b:a 192k \
doctor_720p30.mp4

Embora a gravação da Axis já estivesse em 1280×720 e 30 fps, também a recodifiquei para que os dois ficheiros partilhassem os mesmos parâmetros de vídeo e áudio.

ffmpeg -i axis_trim.mkv \
-vf "scale=1280:720,fps=30" \
-c:v libx264 -crf 20 -preset slow \
-c:a aac -b:a 192k \
axis_720p30.mp4

A montagem foi feita alternando segmentos de cinco segundos de cada vídeo. Em vez de criar dezenas de pequenos ficheiros intermédios, utilizei o filtro trim para selecionar cada trecho e o filtro concat para reuni-los numa única sequência.

À medida que a descrição da montagem crescia, tornou-se evidente que já não fazia sentido mantê-la diretamente na linha de comandos. Foi então que descobri a opção -filter_complex_script, que permite guardar toda a lógica do filtro num ficheiro de texto separado. O ficheiro alterna.flt passou a conter toda a sequência de cortes e concatenações.

Um pequeno trecho desse ficheiro tem este aspeto:

[0:v]trim=start=0:end=5,setpts=PTS-STARTPTS[v0];
[0:a]atrim=start=0:end=5,asetpts=PTS-STARTPTS[a0];
[1:v]trim=start=0:end=5,setpts=PTS-STARTPTS[v1];
[1:a]atrim=start=0:end=5,asetpts=PTS-STARTPTS[a1];
...
[v0][a0][v1][a1]...[v23][a23]
concat=n=24:v=1:a=1[v][a]

Com isso, a execução da montagem reduziu-se a um comando bastante simples:

ffmpeg \
-i axis_720p30.mp4 \
-i doctor_720p30.mp4 \
-filter_complex_script alterna.flt \
-map "[v]" \
-map "[a]" \
-c:v libx264 \
-crf 20 \
-c:a aac \
alternado.mp4

O resultado é um vídeo em que a imagem alterna ritmicamente entre dois fluxos distintos. A gravação da Axis documenta o que acontece sobre a mesa da instalação, enquanto o Doctor Video preserva o próprio conteúdo do circuito de vídeo manipulado durante a performance. A montagem permite que o espectador oscile continuamente entre observar o dispositivo em funcionamento e observar a imagem produzida por esse mesmo dispositivo.

Mais uma vez, chamou-me a atenção como o FFmpeg acaba por ocupar um lugar improvável no meu processo artístico. Embora seja visto sobretudo como uma ferramenta de conversão e transcodificação, revela-se igualmente útil como instrumento de montagem, experimentação e composição.

OCC • MacBook Pro

Este texto é um relato da minha semana (de 5 a 12 de Julho) participando do Old Computer Challenge 2026. O Old Computer Challenge é um evento com duração de uma semana que reúne pessoas interessadas em utilizar computadores antigos e em reduzir o consumo de tecnologia. Durante esse período, os participantes procuram usar um computador antigo — ou até mesmo considerado “antigo” para os padrões atuais — como sua máquina principal e, ao final da semana, compartilham suas experiências e reflexões sobre o desafio.

Vou usar um MacBook Pro 2009 que já faz parte do meu dia-a-dia. Achei ele ao lado de um contentor de lixo há um ano e desde então ele tem sido parte dos computadores que uso para testes e experimentos. Sua bateria ainda me permite um bom tempo de uso sem AC. Segundo o Everymac o meu MacBook Pro é assim:

O MacBook Pro “Core 2 Duo” 2,53 GHz 13″ (SD/FireWire 800 – Mid 2009) é equipado com um processador Intel Core 2 Duo (P8700) de 2,53 GHz, baseado na arquitetura Penryn de 45 nm. O processador possui dois núcleos independentes em um único chip de silício, 3 MB de cache L2 compartilhado integrado ao chip e barramento frontal (Front Side Bus) de 1066 MHz.

O computador vem com 4 GB de memória DDR3 SDRAM de 1066 MHz (PC3-8500), instalados em dois módulos de 2 GB, um disco rígido Serial ATA de 250 GB e 5400 rpm, uma unidade óptica SuperDrive 8x de dupla camada (DVD±R DL), uma GPU NVIDIA GeForce 9400M, que utiliza 256 MB de memória DDR3 compartilhada com a memória principal, câmera iSight integrada e uma tela TFT widescreen de 13,3 polegadas, com retroiluminação por LED, acabamento brilhante (glossy) e resolução nativa de 1280 × 800 pixels.

Em termos de conectividade, oferece AirPort Extreme (802.11a/b/g/n), Bluetooth 2.1 + EDR, Gigabit Ethernet, uma porta FireWire 800, duas portas USB 2.0, uma porta combinada de saída óptica digital de áudio e saída para fones de ouvido (que também pode funcionar como entrada de áudio analógica, selecionável pelo usuário, utilizando o mesmo conector empregado no iPhone), uma Mini DisplayPort, capaz de acionar um monitor externo com resolução de até 2560 × 1600 pixels, além de um leitor de cartões SD.

Os computadores do meu dia-a-dia são todos bem rodados, o mais velho é de 2008, o mais moderno de 2015, ou seja, todos tem pelo menos 10 anos de idade.

Sempre achei curioso como a nossa percepção do tempo muda quando convivemos com computadores antigos. Como passo boa parte do tempo mexendo em Macs dos anos 1980 e 1990, este MacBook Pro de 2009 nunca me pareceu um computador velho.

Na minha cabeça, ele ainda é “o Mac moderno”, afinal não é bege. E ainda por cima, é o que e ligo para acessar a internet, recuperar discos rígidos de máquinas mais antigas ou simplesmente fazer tarefas do dia a dia sem pensar muito. Mas, olhando para a data de fabricação, percebo que ele já está beirando os vinte anos de idade. Para muita gente, ele já é um computador clássico por direito. Acho interessante essa mudança de perspectiva.

Da mesma forma que, há alguns anos, um Macintosh Plus ou um Power Macintosh pareciam antigos enquanto este MacBook representava o presente, hoje ele também faz parte da história da computação. E, talvez justamente por continuar sendo tão útil, seja fácil esquecer o quanto o tempo passou.

Talvez a tarefa mais importante desse Mac essa semana será com a implementação de câmaras de segurança num instalação artística que estou preparando para a Exposição do Mestrado de Media Arts, meu trabalho de conclusão de curso. Recentemente publiquei a foto acima num post sobre meus primeiros testes com essas câmaras: https://refotografia.blog/2026/06/11/projeto-caixa-preta-testes-de-camaras/

Para testar a gravação de vídeo da câmera Axis 210, foi primeiro necessário identificar o seu endereço IP na rede local com a ferramenta arp-scan. Em seguida, a interface web da própria câmera permitiu localizar o endereço RTSP correspondente ao fluxo de vídeo MPEG-4 disponibilizado pelo equipamento. Com essa informação, foi utilizado o FFmpeg para capturar o stream e gravá-lo diretamente em um arquivo MP4. O comando empregue especifica o URL RTSP como fonte de entrada e usa a opção -c copy para copiar o fluxo sem recodificação. Esse procedimento confirmou a possibilidade de registrar localmente, em formato MP4, o vídeo transmitido pela câmera através da rede.

Também é significativo que, mais uma vez, a mediação entre um dispositivo antigo e os usos contemporâneos tenha passado pelo FFmpeg. Em vez de depender do software original do fabricante ou de interfaces gráficas recentes, foi essa ferramenta de linha de comando que permitiu traduzir um fluxo de vídeo de uma câmera já datada para um formato legível e utilizável no contexto atual. Há algo de recorrente nisso: o FFmpeg surge como uma espécie de camada intermediária entre temporalidades técnicas distintas, capaz de acolher protocolos, codecs e formatos obsoletos e reinscrevê-los em infraestruturas presentes – e sempre através de computadores antigos, onde ele brilha ainda mais, por permitir operações super complexas em processadores datados.

E ainda, se o FFmpeg funcionou como mediador entre um hardware envelhecido e formatos contemporâneos, usei o ChatGPT para passar pela opacidade da documentação direto para a construção de um caminho possível de uso, sem erros de digitação na linha de comando.

A obra em montagem no Gnration, na tarde de 10 de julho de 2026. A sinopse que entreguei ficou assim: “A obra propõe uma escultura construída a partir de televisores CRT e outros dispositivos descartados, organizados como um sistema aberto de imagens, sons e circuitos expostos. Sem as carcaças originais, tubos, placas e cabos permanecem visíveis, permitindo que interferências eletromagnéticas e falhas componham continuamente o comportamento audiovisual da instalação. O público é convidado a trazer dispositivos que pretende descartar. A partir de referências ao unblackboxing e à performance experimental, a obra transforma o gesto técnico em ação performativa: desmontar, soldar, conectar e reutilizar componentes eletrônicos resgatados dos dispositivos oferecidos pelo público torna-se parte central da experiência. Osciladores, protoboards e sinais eletrônicos alimentam televisores e altifalantes, criando uma situação em que entrada, processamento e saída permanecem transparentes. Entre laboratório e escultura, a obra investiga a relação contemporânea com a tecnologia, o descarte e o desejo contraditório de abrir aquilo que nossa própria cultura insiste em fechar.”