Onze horas sobre o Atlântico ELEVEN HOURS OVER THE ATLANTIC SEAT 24B WATCHES A FILM AGAIN SEAT 24C REVIEWS FOUR SERVERS GEO ADDS 703 MS TO EVERY KEY MOVE THE WORK NOT THE KEYSTROKES

Onze horas, de Nova York para algum lugar a leste. As luzes da cabine ficam âmbar. A poltrona 24B liga a tela do encosto da frente, percorre um catálogo de quatrocentos títulos e escolhe um filme que já viu três vezes. Isso não é uma crítica. É a coisa mais sensata que se pode fazer com onze horas dentro de um tubo de alumínio pressurizado, e quase todos nós já fizemos.

A poltrona 24C tira o celular do bolso.

As duas poltronas estão no mesmo Wi-Fi. As duas estão à mesma distância do chão. Quando as rodas tocarem a pista, uma terá assistido a um filme cujas falas já sabe de cor, e a outra terá mesclado três branches, resolvido uma suíte de testes que falhava e reiniciado um job travado numa máquina a seis mil quilômetros dali.

O interessante não é que isso seja possível. É por que é possível — e por que a abordagem óbvia, aquela que quase todo mundo tenta uma vez e abandona em algum ponto sobre a Groenlândia, simplesmente não funciona.

Há duas coisas radicalmente diferentes que uma companhia aérea pode querer dizer com "Wi-Fi", e qual delas está parafusada à sua fuselagem em particular decide tudo o que vem depois.

O arranjo antigo é um satélite geoestacionário, estacionado a 35.786 km. Essa altitude não é uma escolha de projeto que alguém tenha feito pensando em você; é a distância exata em que uma órbita leva vinte e quatro horas, de modo que o satélite parece pendurado, imóvel. A consequência é uma aritmética contra a qual nenhum orçamento de engenharia consegue argumentar: subir e descer, duas vezes, dá 477 ms de ida e volta só para a luz, antes que um único roteador entre na história.

O arranjo novo é uma constelação em órbita terrestre baixa a cerca de 550 km — umas sessenta e cinco vezes mais perto, e 7,3 ms de propagação na ida e volta.

As medições feitas no ar batem com a física. A análise dos testes de velocidade em voo da Ookla no 1º trimestre de 2025 encontrou uma mediana de ida e volta de 44 ms na Starlink contra 703–757 ms na Hughes, na Intelsat e na Viasat — uma diferença de cerca de dezesseis vezes. Outra equipe, que instrumentou aparelhos reais em 25 voos de 7 companhias aéreas para o ACM IMC 2025, mediu o mesmo formato de forma independente: abaixo de 40 ms em LEO, acima de 550 ms em GEO.

Para uma travessia oceânica de longo curso, o número honesto é um pouco pior que a manchete. A mesma pesquisa mediu uma mediana de 62 ms sobre o Pacífico, variando entre 19 e 86 ms. É esse o número para guardar na cabeça. Continua excelente. Mas não é 44.

É aqui que um texto no blog de um produto deveria dizer que o futuro chegou.

Ele não chegou por igual, e a aeronave em que chegou por último é a sua.

Os aviões de corredor único são reequipados primeiro — são muitos, giram rápido em solo e voam trechos domésticos curtos, em que ninguém está tentando fazer onze horas de coisa alguma. Os de fuselagem larga, que de fato cruzam oceanos, são os últimos da fila. Em meados de 2026, a United tinha mais de 400 aeronaves com Starlink e esperava chegar perto de mil até o fim do ano — mas apenas cerca de sessenta delas eram de fuselagem larga, seu primeiro voo transatlântico de fuselagem larga com Starlink (Newark–Heathrow) só aconteceu em junho de 2026, e a frota completa de fuselagem larga só tem prazo para meados de 2027. A Virgin Atlantic já havia concluído seus doze A350 — cerca de 28% da frota de fuselagem larga —, com os 787 programados ao longo do segundo semestre de 2026 e os A330neo entrando em 2027.

Ou seja: se você está lendo isto num voo intercontinental em 2026, as probabilidades ainda estão contra você. É provável que esteja no link de 700 ms, não no de 62 ms.

O que torna o resto deste texto mais útil, e não menos.

Um filme e uma shell falham em direções opostas, e o Wi-Fi de bordo é exatamente a rede errada para um dos dois.

Um filme é um problema de banda que não liga para latência. Ele armazena em buffer. Se o primeiro quadro chegar 700 ms atrasado, ninguém percebe, porque nada na experiência depende de o filme reagir a você. Dê play, espere, assista. A ida e volta acontece uma vez só.

Uma shell interativa é a imagem espelhada. Quase não precisa de banda — uma sessão de terminal se mede em kilobits, não em megabits —, mas paga a ida e volta a cada tecla que você espera ver ecoada de volta. A 700 ms, isso não é uma conexão lenta. É uma conversa com dois terços de segundo de pausa depois de cada caractere.

É aqui que as pessoas erram. Elas veem "50 Mbps" no portal de bordo, concluem que a conexão está boa, abrem um terminal e descobrem que "boa" não tem nada a ver com o caso. A moeda aqui não é a banda. São as idas e voltas.

A falha é mais específica do que "parece lento", e a pesquisa é excepcionalmente clara sobre onde a dor recai.

Num estudo controlado com 31 participantes comparando 20 ms com 200 ms de latência de entrada de ponta a ponta, a digitação corrida quase não mudou: 290,9 ms por caractere contra 302,7, uma diferença que os autores não puderam chamar de significativa. As taxas de erro foram idênticas.

Mas a tarefa de correção — reposicionar o cursor com as setas e consertar o texto, aquilo que você de fato faz num editor — foi de 38,9 segundos para 46,5 segundos, cerca de 20% mais lenta, com um tamanho de efeito muito grande (p < 0,001, d = 1,673). Os autores explicam o mecanismo sem rodeios: durante a navegação, você precisa ficar esperando a tela, porque onde o cursor parou determina o que você faz em seguida.

A carga subjetiva piorou mesmo onde a velocidade não piorou. Na tarefa de digitação, em que o desempenho ficou estatisticamente igual, a frustração relatada ainda assim subiu de 20,9 para 31,3.

Traduza isso para um terminal e você tem o nome exato do que desmorona lá em cima: não é digitar um comando. É navegar no vim, é o autocompletar com Tab, é rolar a saída no less e é o ritmo de cutucar-e-olhar de um REPL. Cada um deles é um laço em que a próxima coisa que você faz depende do que acabou de voltar.

Assim que você aceita que as idas e voltas são o recurso escasso, a solução deixa de ser "arrumar um avião mais rápido" e vira uma questão de arquitetura: faça menos idas e voltas, e faça cada uma carregar mais.

Existe uma ferramenta conhecida que ataca isso de frente. O Mosh prevê o que as suas teclas vão fazer e as ecoa localmente antes de o servidor confirmar. O efeito medido é dramático: num link com cerca de meio segundo de ida e volta, a resposta mediana por tecla caiu de 503 ms para menos de 5 ms. Num trajeto transoceânico do MIT até Singapura, de 273 ms para menos de 5 ms.

Mas leia as letras miúdas, porque é nelas que está tudo. O Mosh prevê cerca de 70% das teclas. Os aproximadamente 30% que ele não consegue prever são, nas palavras dos próprios autores, principalmente navegação — e, para essas, o perfil de latência volta a ser o do SSH puro. Ou seja: a interação que a latência alta castiga com mais força é exatamente aquela que o eco local não consegue salvar.

Então a previsão ajuda, mas não salva. O que salva de verdade é se recusar a estar dentro do laço com essa frequência.

Pare de digitar dentro da latência. Coloque o trabalho demorado na outra ponta e vá conferir de tempos em tempos. Um build, uma suíte de testes, uma migração, um agente de programação — nada disso precisa de você presente na ida e volta. Precisa de você no começo e na hora da decisão. Tudo o que fica entre uma coisa e outra é problema da máquina, e a máquina está em terra, com uma boa conexão.

É também por isso que o paralelismo ganha da interatividade lá em cima. Não dá para digitar rápido através de 700 ms. Mas dá, e muito bem, para supervisionar quatro servidores ao mesmo tempo, porque supervisão não é limitada pela latência — é limitada pela atenção, e você tem onze horas de atenção e mais nada em que gastá-la.

Na prática, num celular, num link ruim:

Nada disso foi inventado para aviões. É simplesmente a cara que o trabalho remoto sobre um link hostil sempre teve, e um avião é apenas um link hostil incomumente honesto.

Duas coisas que não conseguimos verificar e não vamos fingir que verificamos:

Se a rede da sua companhia aérea vai deixar o SSH sair. Não encontramos nenhuma evidência pública confiável sobre bloqueio de portas, política de VPN ou tempos limite de inatividade entre os provedores de Wi-Fi de bordo — e encontramos muita afirmação confiante de fórum que não sobrevive a uma checagem. Varia por companhia, por provedor e por aeronave. Teste num voo curto antes de planejar um voo longo em cima disso.

Como a cabine realmente gasta o tempo dela. As estatísticas de entretenimento de bordo mais citadas acabam remontando a tabelas de preços de publicidade sem nenhuma metodologia, e nós as descartamos. A melhor evidência de pesquisa que encontramos — Inmarsat/Censuswide, 11.231 passageiros em dez países, ainda que aplicada lá em 2022 e perguntando sobre intenção em vez de medir tempo — coloca o entretenimento bem à frente do trabalho: 41% queriam assistir a filmes baixados e 35% queriam streaming, contra 26% que queriam trabalhar.

Então trate a poltrona 24B como um personagem, não como uma estatística. A questão nunca foi que assistir a um filme seja errado. É que a alternativa deixou de ser indisponível.

O filme termina onde terminou nas três vezes anteriores. Começa a descida. A poltrona 24B teve um voo perfeitamente bom e vai pousar descansada, o que já vale alguma coisa.

A poltrona 24C pousa com o trabalho feito — porque o trabalho nunca esteve na poltrona. Esteve o tempo todo numa máquina em terra, e o celular nunca passou de uma janela para ela.

Onze horas é muito tempo para se passar a 700 ms. E é pouquíssimo tempo para se passar supervisionando quatro servidores que não estão nem aí para o satélite.