Bellacosa Mainframe e o pc veloz mas o Windows virou ruindows

☕ Um Café no Bellacosa Mainframe

💻 O PC ficou 100.000 vezes mais poderoso. Por que ainda estamos esperando?

Temos processadores multicore, dezenas de gigabytes de RAM e SSDs que transferem gigabytes por segundo. Mesmo assim, esperamos o Explorer abrir. Talvez o problema nunca tenha sido falta de hardware.

Outro dia eu estava fazendo uma coisa absolutamente revolucionária no YouTube Studio.

Não estava renderizando um filme em 8K.

Não estava treinando uma inteligência artificial.

Não estava simulando a colisão de duas galáxias.

Eu queria alterar:

título, descrição, tags e thumbnail.

Só isso.

Então resolvi olhar quanto aquela aparentemente simples página estava consumindo no Chrome.

Quase 500 MB de memória.

Parei.

Olhei novamente.

Quinhentos megabytes.

Para quem passou boa parte da vida profissional dentro do mundo mainframe, existe uma reação quase automática:

“O que exatamente vocês estão fazendo com toda essa memória?”

E então percebi que o problema não estava apenas no navegador.

Olhei para minhas duas máquinas.

Uma roda Windows 10.

A outra, Windows 11.

Uso as duas regularmente e existe uma diferença que nenhum benchmark de processador consegue esconder:

a experiência cotidiana parece mais pesada.

Abrir o Explorer.

Copiar arquivos.

Abrir uma pasta.

Trabalhar no Word.

Editar uma planilha no Excel.

Operações que computadores fazem há décadas continuam conseguindo produzir aquela pequena pausa que faz o cérebro perguntar:

“Por que ainda não aconteceu?”

Foi então que surgiu a pergunta:

Se o computador ficou milhares de vezes mais poderoso, por que ainda estamos esperando?

---

🖥️ CAPÍTULO 1 — Quando 640 KB pareciam muito

Quem começou a trabalhar com computadores algumas décadas atrás viveu em um universo completamente diferente.

Memória era preciosa.

Disco era precioso.

CPU era preciosa.

I/O era precioso.

Cada byte tinha consequência.

Programadores discutiam estruturas de dados porque alguns kilobytes adicionais realmente importavam.

Um programa precisava caber dentro da máquina.

Hoje frequentemente fazemos o contrário.

Esperamos que a máquina seja grande o suficiente para caber dentro do programa.

Temos PCs domésticos com:

16 GB, 32 GB ou 64 GB de RAM.

Processadores com muitos núcleos.

SSDs NVMe capazes de movimentar gigabytes por segundo.

GPUs com poder computacional que teria parecido ficção científica algumas décadas atrás.

E usamos tudo isso para...

abrir uma pasta.

---

🚀 CAPÍTULO 2 — O hardware venceu. O software respondeu crescendo

Existe um fenômeno recorrente na história da computação.

Quando o hardware fica mais poderoso, inicialmente tudo fica rápido.

Depois o software percebe que existe capacidade disponível.

Surgem novas bibliotecas.

Novos frameworks.

Novas camadas.

Novos serviços.

Novos processos.

Novas integrações.

Novos recursos funcionando em segundo plano.

Até que, algum tempo depois, estamos novamente esperando.

É uma espécie de inflação computacional.

O computador ficou mais poderoso.

Mas o software aumentou sua ambição até consumir boa parte dessa vantagem.

Não necessariamente porque os desenvolvedores ficaram piores.

O software moderno também faz muito mais.

Segurança, criptografia, sincronização, colaboração, acessibilidade, internacionalização, recuperação, telemetria, nuvem e inúmeras outras funcionalidades possuem custos reais.

O problema aparece quando todas essas possibilidades entram no caminho daquilo que estou tentando fazer agora.

---

🗂️ CAPÍTULO 3 — Eu só queria abrir o Explorer

Vamos imaginar uma operação aparentemente trivial.

Você clica no Explorer.

Sua intenção é extremamente simples:

MOSTRE MEUS ARQUIVOS

Mas um sistema operacional moderno não enxerga necessariamente apenas uma pasta.

Existem thumbnails.

Arquivos recentes.

Indexação.

Pesquisa.

Integração com serviços de nuvem.

Extensões do shell.

Verificações de segurança.

Metadados.

Dispositivos externos.

Compartilhamentos de rede.

Caches.

Serviços auxiliares.

Sincronizações.

Cada componente pode individualmente possuir uma justificativa perfeitamente razoável.

O problema é a soma.

Você pediu:

DIR

A arquitetura respondeu:

AGUARDE ENQUANTO CONSULTAMOS
O ECOSSISTEMA.

---

🧠 CAPÍTULO 4 — No mainframe isso produziria uma reunião

Agora imagine uma aplicação corporativa cuja documentação dissesse:

FUNÇÃO:

Editar quatro campos.

MEMÓRIA NECESSÁRIA:

500 MB

Em muitos ambientes mainframe tradicionais alguém provavelmente perguntaria:

“Por quê?”

E essa pequena palavra muda completamente uma cultura de engenharia.

No mainframe existe uma longa tradição de observar:

CPU.

Storage.

I/O.

Throughput.

Response time.

Workload.

Prioridade.

Capacidade.

Consumo não é apenas algo que aparece no Task Manager.

Consumo faz parte da arquitetura.

Porque durante décadas cada recurso computacional teve custo suficientemente visível para obrigar organizações a prestar atenção nele.

---

⚙️ CAPÍTULO 5 — WLM: nem todo trabalho merece a mesma prioridade

Existe outra ideia extremamente interessante no mundo z/OS.

Workload Management.

O sistema não precisa simplesmente perguntar:

“Existe CPU disponível?”

Ele precisa entender que diferentes workloads possuem diferentes objetivos.

Uma transação crítica esperando resposta de um cliente não possui necessariamente a mesma importância operacional que uma atividade batch que pode esperar.

Agora imagine aplicar mentalmente essa filosofia ao desktop.

Estou usando o Explorer.

Então poderíamos imaginar:

SERVICE CLASS: INTERACTIVE

IMPORTANCE: 1

Enquanto coisas como:

INDEXAÇÃO
SINCRONIZAÇÃO
UPDATE
CACHE
TELEMETRIA
PRELOAD

poderiam conceitualmente pertencer a:

SERVICE CLASS: BACKGROUND

IMPORTANCE: 5

A regra seria maravilhosa:

Primeiro responda ao ser humano. Depois faça manutenção da máquina.

Sistemas desktop possuem mecanismos de prioridade e gerenciamento de recursos, evidentemente.

Mas do ponto de vista da experiência do usuário, nem sempre parece que essa é a regra dominante.

---

⏱️ CAPÍTULO 6 — O benchmark que realmente importa

Existe uma métrica extremamente importante que raramente aparece na caixa do computador.

Paciência humana.

Considere:

100 ms     → instantâneo

300 ms     → praticamente instantâneo

700 ms     → percebi uma pausa

1 segundo  → estou esperando

3 segundos → alguma coisa está errada?

Para um benchmark computacional, algumas centenas de milissegundos podem parecer insignificantes.

Para alguém trabalhando oito horas por dia, são fundamentais.

Porque o problema não é esperar 700 milissegundos uma vez.

É repetir pequenas esperas:

centenas de vezes durante o dia.

Abrir.

Esperar.

Salvar.

Esperar.

Trocar janela.

Esperar.

Abrir pasta.

Esperar.

A máquina continua tecnicamente rápida.

Mas o usuário começa a considerá-la lenta.

---

📄 CAPÍTULO 7 — Meu Office antigo continua trabalhando

Existe um experimento curioso na minha própria rotina.

Continuo utilizando uma versão antiga do Microsoft Office para determinadas tarefas.

Por quê?

Porque ela faz aquilo que preciso.

No Word quero:

escrever, formatar, inserir imagens, salvar e imprimir.

No Excel quero:

células, fórmulas, tabelas, gráficos e arquivos.

As versões modernas oferecem muito mais.

Colaboração.

Cloud.

Autosave.

Contas.

Templates conectados.

Serviços online.

Integrações.

Add-ins.

Assistentes.

IA.

Tudo isso pode ser extremamente útil para quem utiliza essas funcionalidades.

Mas existe uma pergunta arquitetural importante:

Se eu não estou usando determinada funcionalidade, por que ela precisa participar do caminho crítico daquilo que estou fazendo?

Esse talvez seja o verdadeiro problema.

Não é possuir funcionalidades.

É pagar continuamente pelo custo das funcionalidades que não estamos utilizando.

---

🌐 CAPÍTULO 8 — O navegador virou sistema operacional

Também precisamos reconhecer outra transformação.

O navegador deixou de ser simplesmente um programa para mostrar documentos HTML.

Ele virou uma plataforma computacional.

Uma aplicação web moderna pode possuir:

player de vídeo,

banco de dados local,

cache,

workers,

GPU acceleration,

criptografia,

comunicação permanente com servidores,

frameworks JavaScript,

árvores enormes de objetos,

notificações,

sincronização,

telemetria,

analytics.

Quando abrimos uma página moderna, muitas vezes estamos inicializando algo muito mais próximo de uma aplicação completa do que de um documento.

Isso explica parte dos 500 MB.

Mas explicar não significa necessariamente justificar cada megabyte.

---

🏗️ CAPÍTULO 9 — Construímos catedrais para vender cachorro-quente

Existe uma tentação permanente na engenharia de software.

Resolver o problema que talvez tenhamos amanhã em vez daquele que temos hoje.

Então uma pequena aplicação recebe:

framework,

container,

API gateway,

microservices,

observability,

event bus,

cache distribuído,

telemetria,

autenticação federada,

cinco bibliotecas JavaScript.

E finalmente...

um formulário com quatro campos.

A arquitetura é impressionante.

Mas o usuário queria editar o título de um vídeo.

É como construir uma catedral porque precisávamos de uma barraca para vender cachorro-quente.

A catedral pode ser maravilhosa.

Só existe uma pergunta inconveniente:

era necessária?

---

💾 CAPÍTULO 10 — Memória livre também serve para alguma coisa

Existe uma ressalva técnica importante.

Ver 10 GB ocupados no computador não significa automaticamente que 10 GB estejam sendo desperdiçados.

Sistemas operacionais modernos utilizam memória disponível como cache.

Isso é inteligente.

RAM vazia não produz trabalho.

Se o sistema puder guardar dados que provavelmente serão utilizados novamente, poderá melhorar bastante o desempenho.

Portanto:

MEMÓRIA UTILIZADA

não é igual a:

MEMÓRIA DESPERDIÇADA

Mas existe outra métrica.

Quanto recurso é realmente necessário para executar a função solicitada?

Essa pergunta continua válida.

---

🔥 CAPÍTULO 11 — CPU baixa também pode esconder um computador lento

Outro erro comum é olhar:

CPU: 7%

e concluir:

“O computador está praticamente parado.”

Talvez.

Mas experiência interativa não depende apenas da média de CPU.

Imagine dezenas de processos acordando continuamente.

Um faz I/O.

Outro verifica alguma coisa.

Outro consulta a rede.

Outro atualiza um cache.

Outro analisa um arquivo.

Outro cria uma thread.

Outro executa garbage collection.

Nenhum deles individualmente utiliza muita CPU.

Mas todos disputam pequenas parcelas de atenção do sistema.

A utilização média continua baixa.

A latência percebida pelo usuário aumenta.

É possível ter CPU sobrando e ainda possuir uma experiência ruim.

---

📦 CAPÍTULO 12 — SSDs esconderam muitos pecados

Quando utilizávamos discos mecânicos, acessar arquivos desnecessariamente era caro.

Seek time doía.

I/O aleatório doía.

Inicializações pesadas doíam.

Depois chegaram os SSDs.

E muita arquitetura ruim ficou subitamente rápida.

Excelente.

Então adicionamos mais coisas.

Mais bibliotecas.

Mais serviços.

Mais arquivos.

Mais dependências.

Mais abstrações.

Vieram os NVMe.

Novamente ganhamos uma quantidade enorme de desempenho.

E novamente começamos a consumi-la.

Até que chegamos à situação quase cômica:

um dispositivo capaz de transferir vários gigabytes por segundo pode apresentar hesitação para abrir uma pasta.

---

🦖 CAPÍTULO 13 — Talvez o mainframe tenha algo a ensinar ao desktop

Não estou dizendo que devemos transformar Windows em z/OS.

São plataformas diferentes resolvendo problemas diferentes.

Mas algumas ideias atravessam arquiteturas.

Recursos possuem custo.

Mesmo quando parecem baratos.

Workloads possuem prioridades diferentes.

O que está diante do usuário merece tratamento especial.

Capacity planning continua importante.

Ter capacidade não significa que devemos desperdiçá-la.

Response time importa.

Throughput excelente não consola alguém esperando uma janela abrir.

Observabilidade precisa responder “quem consumiu?”

Não simplesmente “quanto foi consumido”.

E talvez principalmente:

Complexidade precisa justificar sua existência.

---

🖥️ CAPÍTULO 14 — Windows 10 de um lado. Windows 11 do outro.

Tenho duas máquinas ligadas.

Uma com Windows 10.

Outra com Windows 11.

Não preciso consultar uma apresentação de marketing para perceber determinadas diferenças.

Estou trabalhando nelas.

Abro Explorer.

Copio arquivos.

Uso navegador.

Abro Word.

Trabalho no Excel.

São justamente as tarefas banais que constroem nossa percepção sobre um sistema operacional.

Uma interface pode ser mais bonita.

Pode possuir animações melhores.

Pode integrar dezenas de serviços.

Mas existe uma métrica brutalmente simples:

Quando cliquei, respondeu?

Porque a interface gráfica possui uma função fundamental.

Transformar intenção humana em ação computacional.

Quanto menor a distância perceptível entre as duas, melhor parece a máquina.

---

👴 CAPÍTULO 15 — O computador velho que parece rápido

Existe uma experiência divertida.

Pegue um computador antigo funcionando com software da própria época.

Às vezes ele parece surpreendentemente responsivo.

Obviamente não é mais poderoso.

Um smartphone atual pode possuir ordens de magnitude mais capacidade computacional.

Mas aquele sistema antigo frequentemente possui:

menos processos,

menos camadas,

menos serviços,

menos abstrações,

menos dependências.

Você clica.

Ele executa.

Isso não significa que devamos voltar ao DOS.

Significa apenas que existe algo valioso naquela relação direta entre:

INTENÇÃO
   ↓
AÇÃO

Cada camada adicionada entre as duas deveria conseguir responder:

“Qual benefício estou entregando?”

---

🚨 CAPÍTULO 16 — O verdadeiro desperdício não é RAM

Talvez este seja o ponto mais importante.

500 MB de RAM custam pouco atualmente.

Alguns ciclos adicionais de CPU custam pouco.

Um SSD NVMe consegue absorver enormes volumes de I/O.

Mas existe um recurso que continua extremamente caro.

Tempo humano.

Se uma pessoa perde apenas dois segundos repetidamente durante centenas de operações diárias, estamos consumindo justamente o recurso que não conseguimos ampliar instalando outro DIMM.

Não existe upgrade de:

HUMAN TIME

Não podemos instalar:

+32 GB DE VIDA

É por isso que performance continua sendo experiência do usuário.

---

☕ CAPÍTULO 17 — O Mainframe Café propõe uma nova métrica

Talvez precisemos de uma nova unidade.

Vou chamá-la de:

Wasted Human Milliseconds — WHM

😂

Em vez de perguntar apenas:

CPU?
MEMÓRIA?
IOPS?
THROUGHPUT?

perguntaríamos:

QUANTOS MILISSEGUNDOS
O USUÁRIO ESPEROU
SEM NECESSIDADE?

Multiplique isso por:

mil operações,

mil usuários,

mil dias.

Subitamente aqueles insignificantes 500 milissegundos deixam de parecer insignificantes.

---

🧙 CAPÍTULO 18 — A regra Jedi do Capacity Planning

Depois de décadas trabalhando com sistemas críticos, eu resumiria a questão assim:

Capacidade disponível não é licença para desperdiçar latência.

Ter 64 GB de RAM não significa que cada aplicação ganhou autorização para consumir gigabytes.

Ter 16 núcleos não significa que dezenas de processos devam acordá-los continuamente.

Ter um NVMe de vários GB/s não significa que podemos ignorar I/O desnecessário.

E possuir uma máquina extraordinariamente poderosa não significa que o usuário deva aceitar esperar para abrir uma pasta.

Hardware abundante deveria proporcionar uma coisa maravilhosa:

simplicidade extremamente rápida.

---

☕ EPÍLOGO — Cliquei. Abra.

Talvez estejamos complicando demais.

Não quero que meu computador seja menos poderoso.

Não quero abandonar segurança.

Não quero abandonar cloud.

Não quero abandonar IA.

Não quero voltar para 1995.

Quero algo muito mais simples.

Quando eu clicar no Explorer:

abra.

Quando mandar copiar:

copie.

Quando abrir Word:

deixe-me escrever.

Quando abrir Excel:

mostre minha planilha.

Quando entrar no YouTube Studio para trocar título, descrição, tags e thumbnail:

deixe-me fazer exatamente isso.

Se eu quiser Analytics, carregue Analytics.

Se quiser comentários, carregue comentários.

Se quiser IA, carregue IA.

Se quiser edição de vídeo, carregue o editor.

Até lá:

IF FUNCTION_REQUESTED = FALSE
   DO NOT WASTE MY RESOURCES
END-IF

Talvez essa seja uma filosofia antiga.

Mas depois de observar uma página consumir centenas de megabytes para permitir que eu altere algumas linhas de texto, começo a suspeitar que algumas ideias antigas continuam bastante modernas.

Porque depois de toda a evolução dos processadores, memórias, discos, GPUs e sistemas operacionais, a melhor experiência de usuário ainda pode ser resumida em três palavras:

Cliquei. Responda. Agora.

☕ Um Café no Bellacosa Mainframe

Onde até o Windows aprende que recurso computacional também merece Capacity Planning.

Bellacosa Mainframe e as aventuras de Johnny Castaway

☀

☽







SOS

Onde está aquele navio?

Ɔ ● C ╱╲╱╲

 Ilha do Náufrago

 Amanhecer 06:00

Ciclo: 00:00 / 05:00

Um novo dia começa na pequena ilha...

Bellacosa Mainframe em uma homenagem ao johnny castaway 

☕ Um Café no Bellacosa Mainframe

Johnny Castaway: uma homenagem ao náufrago que transformou o protetor de tela em uma história viva

Durante muitos anos, quando alguém se afastava do computador, a máquina parecia adormecer.

A tela escurecia, linhas coloridas começavam a atravessar o monitor, logotipos flutuavam lentamente ou labirintos tridimensionais surgiam diante dos nossos olhos. Eram os famosos protetores de tela, programas criados originalmente para evitar que imagens estáticas permanecessem gravadas nos antigos monitores.

Mas, no começo dos anos 1990, um pequeno náufrago provou que aquele intervalo de inatividade poderia ser muito mais interessante.

Em vez de exibir apenas formas geométricas ou animações repetitivas, ele caminhava por uma ilha minúscula, pescava, dormia, tentava escapar, enfrentava situações absurdas e quase sempre perdia alguma oportunidade de ser resgatado.

Seu nome era Johnny Castaway.

O personagem tornou-se uma das figuras mais lembradas da história dos protetores de tela e um pequeno símbolo de uma época na qual cada descoberta feita no computador parecia abrir uma porta secreta.

Inspirado nessa memória, criamos um simulador animado de um náufrago em uma ilha no meio do oceano, desenvolvido em HTML, CSS, JavaScript e SVG. Ele não pretende reproduzir o programa original, mas prestar uma homenagem à sua ideia mais importante: transformar o tempo ocioso da máquina em uma pequena história acontecendo diante do usuário.

Prepare o café, ajuste a cadeira e observe o horizonte.

Talvez apareça um navio.

Talvez apareça uma sereia.

Ou talvez o nosso náufrago continue caminhando em círculos, como tantos processos esperando indefinidamente por um recurso que nunca chega.

---

O que foi Johnny Castaway?

Johnny Castaway foi um protetor de tela narrativo lançado em 1992 para computadores com Microsoft Windows. O programa foi associado à Sierra On-Line, à Dynamix e à equipe da Jeff Tunnell Productions, sendo apresentado comercialmente pela linha Screen Antics como um protetor de tela capaz de contar uma história.

A premissa era simples e brilhante.

Johnny estava preso em uma ilha extremamente pequena, acompanhado basicamente por areia, mar e um único coqueiro. Enquanto o computador permanecia sem uso, o personagem realizava diversas atividades:

• pescava;

• dormia;

• caminhava;

• fazia exercícios;

• construía objetos;

• tentava sinalizar para navios;

• enfrentava animais;

• recebia visitantes inesperados;

• elaborava planos de fuga;

• quase conseguia abandonar a ilha.

O segredo estava na variedade.

Nem todas as cenas apareciam imediatamente. Algumas eram comuns, enquanto outras eram raras. Isso fazia o usuário continuar observando o protetor de tela, curioso para descobrir algo que ainda não havia visto.

A rotina aparentemente repetitiva escondia uma história maior.

O computador deixava de apresentar uma simples animação decorativa e passava a exibir um mundo persistente.

---

Um protetor de tela que fazia as pessoas permanecerem diante da tela

Existe uma bela contradição no sucesso de Johnny Castaway.

Um protetor de tela deveria entrar em funcionamento quando o usuário se afastasse do computador. Johnny fazia exatamente o contrário: chamava a pessoa de volta.

O usuário parava de digitar, o protetor era ativado e, poucos segundos depois, alguém percebia:

— O que ele está fazendo agora?

A pessoa aproximava-se novamente da mesa para assistir à cena.

Era como deixar um aquário digital funcionando dentro do computador, mas com um personagem imprevisível, humor visual e pequenos acontecimentos narrativos.

Essa estrutura antecipou conceitos que se tornariam comuns décadas mais tarde:

• personagens virtuais vivendo continuamente;

• simulações executadas em tempo real;

• jogos ociosos;

• narrativas ambientais;

• eventos raros;

• conteúdos condicionados ao horário;

• experiências digitais persistentes;

• pequenos mundos que continuam existindo sem a intervenção direta do usuário.

Johnny Castaway não era exatamente um jogo tradicional, pois não exigia comandos constantes. Também não era apenas um vídeo, porque suas cenas podiam variar conforme o tempo e as condições do programa.

Ele habitava uma curiosa fronteira entre software utilitário, animação, brinquedo digital e narrativa interativa.

---

Quem criou Johnny Castaway?

O projeto foi desenvolvido por uma pequena equipe ligada à Jeff Tunnell Productions, criada por Jeff Tunnell, fundador original da Dynamix. O desenho do personagem é atribuído a Shawn Bird, que recebeu a missão de criar alguém castigado pelas circunstâncias, mas ainda simpático e agradável ao público. Chris Cole é citado como principal designer do projeto.

Essa combinação foi essencial.

Johnny precisava parecer abandonado, cansado e um pouco desastrado, mas nunca desagradável. O público deveria torcer por ele, rir dos seus problemas e reconhecer sua persistência.

Seu visual era limitado pela tecnologia disponível. O programa utilizava a pequena paleta gráfica comum nos computadores Windows daquela época, com animações econômicas e poucos recursos quando comparados aos sistemas atuais. Mesmo assim, o personagem transmitia personalidade.

Essa é uma lição importante de design.

Não é necessário possuir milhões de cores, processamento gráfico avançado ou inteligência artificial para criar uma figura memorável.

É necessário possuir:

• uma silhueta reconhecível;

• movimentos expressivos;

• situações compreensíveis;

• humor;

• ritmo;

• personalidade;

• pequenas surpresas.

Johnny possuía tudo isso.

---

A ilha como palco de uma história infinita

A ilha era minúscula, mas funcionava como um palco teatral.

O coqueiro era cenário, recurso, obstáculo e companheiro silencioso. O oceano representava simultaneamente liberdade e prisão. Tudo o que surgia no horizonte podia significar esperança ou mais uma piada.

Com poucos elementos, o programa criava inúmeras possibilidades.

Um peixe poderia virar alimento.

Um navio poderia representar o resgate.

Uma garrafa poderia transportar uma mensagem.

Uma jangada poderia se tornar um plano de fuga.

Uma gaivota poderia ser apenas parte da paisagem ou a responsável por mais uma tragédia cômica.

A limitação espacial favorecia a criatividade. Como acontece em uma rotina COBOL bem construída, cada recurso precisava possuir uma função clara. Não havia espaço para desperdício.

A ilha era praticamente um pequeno ambiente de produção:

• Johnny era o processo principal;

• o coqueiro era o recurso compartilhado;

• os cocos eram o estoque;

• o oceano era a rede externa;

• a fogueira era o sistema de sinalização;

• o navio era a integração aguardada;

• a sereia era um evento não documentado;

• o tubarão era um erro crítico em tempo de execução.

E o resgate?

Esse parecia estar permanentemente aguardando aprovação em alguma fila remota.

---

Por que Johnny Castaway se tornou inesquecível?

Johnny Castaway tornou-se memorável porque possuía algo raro: continuidade percebida.

Mesmo quando o usuário não observava o programa, existia a sensação de que alguma coisa poderia ter acontecido.

Talvez Johnny tivesse recebido uma visita.

Talvez tivesse construído uma jangada.

Talvez um navio tivesse passado.

Talvez uma cena rara tivesse sido exibida justamente enquanto ninguém estava olhando.

Essa possibilidade transformava o programa em uma espécie de mistério.

Também existiam situações especiais vinculadas a datas comemorativas. Em determinados períodos, elementos relacionados ao Natal, Halloween, Ano-Novo e outras celebrações podiam aparecer na ilha. O programa utilizava a data configurada no computador para apresentar algumas dessas variações.

Hoje isso parece simples.

Naquela época, porém, era surpreendente perceber que um programa aparentemente pequeno conhecia o calendário e modificava seu comportamento.

Era quase como se Johnny soubesse que o mundo fora da ilha continuava avançando.

---

Dos monitores CRT ao navegador moderno

Os antigos protetores de tela tinham uma função técnica real.

Nos monitores de tubo, também conhecidos como CRT, a exibição prolongada de uma imagem estática poderia causar retenção ou desgaste desigual do material fosforescente da tela. O protetor substituía a imagem parada por elementos em movimento.

Com o avanço dos monitores, essa função perdeu grande parte da importância prática.

Mesmo assim, os protetores de tela permaneceram durante muito tempo porque já haviam conquistado outra função: personalizar o computador.

Eles permitiam que cada máquina tivesse personalidade.

Em escritórios, escolas e residências, era possível encontrar:

• relógios;

• aquários;

• paisagens;

• labirintos;

• tubos coloridos;

• textos giratórios;

• logotipos;

• animações;

• personagens.

Johnny Castaway foi além porque transformou personalização em narrativa.

Nosso simulador leva essa ideia para o navegador moderno.

Em vez de depender de um executável antigo, de componentes de 16 bits ou de uma versão específica do Windows, ele utiliza tecnologias abertas da web:

• HTML para a estrutura;

• CSS para o cenário e as animações;

• JavaScript para controlar o tempo e os acontecimentos;

• SVG para representar elementos gráficos vetoriais;

• Web Audio API para produzir o som ambiente opcional.

Tudo acontece diretamente na página do Blogspot.

---

Como funciona o simulador do náufrago?

O simulador foi planejado como uma animação contínua com duração de cinco minutos.

Durante esse período, um dia inteiro é representado de forma acelerada. O tempo avança desde o amanhecer até a madrugada e, ao atingir o final do ciclo, a história recomeça automaticamente.

O visitante pode acompanhar:

• o nascer do sol;

• o avanço da manhã;

• a iluminação do meio-dia;

• o entardecer;

• o pôr do sol;

• o surgimento da lua;

• o aparecimento das estrelas;

• a chegada da madrugada.

O relógio exibido no painel não representa a hora real do visitante. Ele mostra o horário fictício da ilha, sincronizado com a posição do sol e com a progressão da narrativa.

O náufrago

O personagem caminha entre diferentes regiões da ilha.

Seus braços e pernas possuem movimentos independentes, criando a impressão de caminhada. Em determinados momentos ele para, observa o horizonte, descansa, pensa ou acena.

Balões de pensamento ajudam a criar uma personalidade para o personagem, sem depender de narração sonora.

As gaivotas

As gaivotas atravessam o céu em velocidades e alturas diferentes.

Suas asas são animadas separadamente, impedindo que pareçam simples imagens deslizando pela tela. Os trajetos não são idênticos, o que torna o ambiente mais vivo.

Os peixes

Em momentos específicos, peixes saltam para fora do oceano.

A trajetória combina movimento horizontal, deslocamento vertical, rotação e desaparecimento. Pequenos respingos completam a cena quando eles retornam à água.

O coqueiro

O coqueiro balança continuamente, simulando o vento do oceano.

A copa e o tronco possuem movimentos relacionados, mas não completamente idênticos. Durante uma rajada mais intensa, a velocidade da animação aumenta temporariamente.

A fogueira

Quando a noite se aproxima, a fogueira é acesa.

As chamas são formadas por camadas animadas com tamanhos e velocidades diferentes. A fumaça sobe, cresce e desaparece gradualmente.

A sereia

Em determinado momento do ciclo, uma figura misteriosa surge no oceano.

A sereia aparece lentamente, flutua entre as ondas, acena para o náufrago e depois mergulha novamente.

É uma referência direta ao espírito das cenas inesperadas que tornaram Johnny Castaway tão especial.

O náufrago finalmente encontra alguém.

Naturalmente, a conversa não resolve o problema.

Em uma ilha inspirada em sistemas corporativos, até criaturas mitológicas parecem evitar abrir uma solicitação formal de resgate.

---

Uma homenagem, não uma reprodução

Este simulador é uma criação independente e não utiliza os arquivos, códigos, imagens ou animações originais de Johnny Castaway.

Ele foi desenvolvido como uma homenagem conceitual ao personagem e à geração de usuários que conheceu os primeiros computadores pessoais, os monitores CRT, o Windows 3.x, os disquetes e os protetores de tela narrativos.

O objetivo não é substituir ou reconstruir fielmente o programa original.

A proposta é recuperar sua atmosfera:

• a ilha minúscula;

• o personagem solitário;

• o humor visual;

• os pequenos acontecimentos;

• o tempo passando;

• a curiosidade de esperar pela próxima cena.

Johnny Castaway pertence a uma época específica da informática, mas sua principal ideia continua atual.

Um programa pode ser útil e, ao mesmo tempo, possuir personalidade.

Uma animação pode ser simples e, ainda assim, construir uma história.

Uma tela aparentemente ociosa pode esconder um pequeno universo.

---

O que o simulador ensina sobre HTML, CSS e JavaScript?

Além da homenagem histórica, o projeto funciona como demonstração prática de desenvolvimento web.

HTML: a estrutura da ilha

O HTML organiza os elementos do cenário:

• céu;

• oceano;

• ilha;

• personagem;

• coqueiro;

• peixes;

• aves;

• sereia;

• painel;

• botões;

• legendas.

Cada objeto possui uma classe própria, facilitando sua identificação e manipulação.

CSS: movimento e aparência

O CSS cria praticamente toda a apresentação visual.

Gradientes formam o céu, o mar, a areia e a iluminação. Bordas arredondadas, transformações e sombras produzem os personagens e objetos.

As animações usam @keyframes para controlar:

• voo;

• balanço;

• caminhada;

• rotação;

• ondas;

• fumaça;

• fogo;

• saltos;

• aparecimentos;

• desaparecimentos.

Isso reduz a dependência de arquivos externos e melhora a autonomia do simulador.

JavaScript: o relógio da história

O JavaScript funciona como o diretor da peça.

Ele calcula quantos segundos passaram desde o início do ciclo, atualiza o relógio, modifica as cores do céu, movimenta o sol e dispara acontecimentos nos momentos programados.

A cada quadro, o navegador calcula a posição correta dos elementos por meio de requestAnimationFrame.

Quando o contador alcança 300 segundos, o ciclo retorna ao início.

O resultado é uma pequena máquina de estados narrativa.

Não existe apenas uma animação contínua. Existem acontecimentos ordenados dentro de uma linha temporal.

---

Por que o simulador é adequado para Blogspot?

O projeto foi construído em um único bloco de HTML, CSS e JavaScript.

Isso facilita sua inclusão em uma postagem ou página do Blogger, desde que o tema e o editor permitam a execução de scripts personalizados.

Entre suas principais características estão:

• ausência de bibliotecas externas;

• ausência de imagens hospedadas em outros servidores;

• gráficos vetoriais e elementos desenhados com CSS;

• adaptação para telas menores;

• controles para pausar e reiniciar;

• som ambiente opcional;

• reinício automático;

• carregamento independente;

• funcionamento direto no navegador.

A ausência de bibliotecas adicionais reduz requisições de rede e evita dependências que poderiam deixar de funcionar futuramente.

Entretanto, animações complexas exigem processamento. Em aparelhos antigos ou páginas que já possuam muitos scripts, é recomendável testar o desempenho e evitar inserir diversos simuladores simultaneamente.

---

Johnny Castaway e a arqueologia digital

Preservar programas antigos é uma forma de preservar cultura.

Aplicativos aparentemente pequenos ajudam a contar a história de como as pessoas utilizavam os computadores, quais limitações existiam e como os desenvolvedores transformavam poucos recursos em experiências memoráveis.

Johnny Castaway representa:

• a popularização do Windows;

• a cultura dos disquetes;

• a era dos monitores de tubo;

• o crescimento do software doméstico;

• a personalização dos computadores;

• o humor nas interfaces;

• o nascimento de pequenas narrativas digitais persistentes.

O programa original foi distribuído em disquete e dependia de tecnologias antigas do Windows. Como vários componentes pertenciam ao universo de software de 16 bits, sua execução direta em sistemas modernos pode exigir ambientes compatíveis, máquinas virtuais, emulação ou adaptações desenvolvidas pela comunidade.

Isso demonstra a importância da preservação.

Um livro antigo continua legível enquanto o idioma puder ser compreendido. Um software antigo depende de uma cadeia inteira:

• formato do arquivo;

• sistema operacional;

• bibliotecas;

• processador;

• dispositivo gráfico;

• instalador;

• suporte de execução.

Quando um elo desaparece, a obra corre o risco de se tornar inacessível.

Por isso, recriações, documentação, vídeos, capturas de tela, emuladores e artigos históricos desempenham um papel importante na memória da computação.

---

O verdadeiro significado da ilha

Johnny Castaway também funciona como uma pequena metáfora da vida digital.

O personagem está preso em um ambiente limitado, executando rotinas, aguardando uma oportunidade de mudança e tentando aprender com cada fracasso.

De certa maneira, todos nós já estivemos naquela ilha.

A ilha pode ser:

• um projeto que nunca termina;

• um sistema legado sem documentação;

• uma fila de incidentes;

• uma compilação esperando espaço;

• uma reunião que poderia ser um e-mail;

• uma migração adiada;

• uma integração que depende de outro departamento;

• um chamado que permanece “em análise”.

Johnny continua tentando.

Ele pesca novamente.

Reconstrói a jangada.

Acende a fogueira.

Observa o horizonte.

Talvez seja essa persistência que tenha tornado o personagem tão querido.

Seu humor não nasce apenas das coisas que dão errado, mas da certeza de que ele tentará outra vez.

---

Curiosidades sobre Johnny Castaway

1. Era chamado de protetor de tela narrativo

O grande diferencial comercial de Johnny era apresentar uma história em desenvolvimento, em vez de apenas repetir um padrão visual.

2. Algumas cenas eram raras

O usuário poderia assistir ao programa várias vezes antes de encontrar determinadas situações, aumentando a curiosidade.

3. O calendário influenciava a ilha

Datas comemorativas podiam modificar detalhes do cenário e criar pequenas surpresas sazonais.

4. A paleta gráfica era limitada

As limitações visuais ajudaram a construir o estilo imediatamente reconhecível do personagem.

5. A ilha parecia continuar existindo

Mesmo sem uma simulação contínua como as atuais, a distribuição das cenas produzia a sensação de persistência.

6. Johnny quase conseguia escapar

Grande parte do humor vinha das oportunidades de resgate destruídas por acidentes, decisões ruins ou puro azar.

7. O programa continua recebendo homenagens

Projetos comunitários, arquivos históricos e recriações modernas demonstram que o personagem ainda desperta interesse décadas depois de seu lançamento.

---

Perguntas frequentes sobre Johnny Castaway e o simulador

O que é Johnny Castaway?

Johnny Castaway é um clássico protetor de tela narrativo lançado no início dos anos 1990. Ele acompanha a rotina de um náufrago preso em uma pequena ilha.

Johnny Castaway era um jogo?

Não exatamente. O usuário não controlava constantemente o personagem. O programa funcionava como protetor de tela e apresentava cenas animadas de forma automática.

Em que ano Johnny Castaway foi lançado?

O lançamento original ocorreu em 1992, no contexto dos computadores que utilizavam Microsoft Windows.

Quem desenvolveu Johnny Castaway?

O projeto foi desenvolvido por uma equipe ligada à Jeff Tunnell Productions, Dynamix e Sierra On-Line, com participação de profissionais como Jeff Tunnell, Chris Cole e Shawn Bird.

O simulador deste artigo é o programa original?

Não. É uma criação independente feita em HTML, CSS, JavaScript e SVG, inspirada no conceito de um náufrago vivendo pequenas aventuras em uma ilha.

Quanto tempo dura a animação?

O ciclo completo dura cinco minutos, equivalentes a 300 segundos.

A animação reinicia automaticamente?

Sim. Depois de completar os cinco minutos, a história retorna ao amanhecer e começa novamente.

O simulador utiliza imagens externas?

Não. Os elementos visuais são produzidos com SVG, formas CSS, gradientes e caracteres gráficos.

O som começa automaticamente?

Não. O visitante precisa ativá-lo pelo botão, pois os navegadores modernos normalmente bloqueiam reprodução automática de áudio sem interação do usuário.

O simulador funciona em celular?

O layout é responsivo, mas a experiência pode variar conforme o tamanho da tela, o navegador e a capacidade de processamento do aparelho.

Posso pausar a história?

Sim. O painel apresenta controles para pausar, continuar e reiniciar o ciclo.

A sereia aparece sempre?

Ela está programada para aparecer em um momento específico dos cinco minutos. É necessário acompanhar o ciclo ou esperar sua chegada.

---

Conclusão: há sempre alguma coisa acontecendo na ilha

Johnny Castaway mostrou que um protetor de tela poderia possuir humor, narrativa, continuidade e personalidade.

Ele surgiu em uma época de computadores muito mais limitados, mas conseguiu fazer algo que ainda desafia diversos sistemas modernos: criar uma experiência pela qual as pessoas desenvolvem carinho.

Nosso simulador procura recuperar um pouco dessa sensação.

O cenário muda.

O sol atravessa o céu.

As gaivotas voam.

Os peixes saltam.

O coqueiro enfrenta o vento.

A fogueira ilumina a noite.

Uma sereia aparece por alguns instantes.

E o náufrago continua observando o horizonte.

Talvez ele esteja esperando um navio.

Talvez esteja esperando uma atualização do sistema.

Ou talvez tenha percebido que, depois de tanto tempo, aquela ilha deixou de ser apenas uma prisão e se transformou em sua casa.

No final dos cinco minutos, tudo recomeça.

O sol nasce novamente.

O oceano continua em movimento.

E Johnny — ou o nosso pequeno herdeiro espiritual — levanta-se para tentar mais uma vez.

SYSTEM MESSAGE: RESCUE JOB SUBMITTED.

STATUS: WAITING FOR EXTERNAL RESOURCE.

ESTIMATED COMPLETION: UNKNOWN.

Enquanto isso, aceite mais um café.

A ilha continuará aqui.