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.

🖥️ Screensavers que dançavam na madrugada – O Museu dos Micreiros Anos 90

 

Bellacosa Mainframe e os monitores crt problemas e solucoes screensavers

🖥️ Screensavers que dançavam na madrugada – O Museu dos Micreiros Anos 90
(Por Vagner Bellacosa ☕ — Bellacosa Mainframe / El Jefe Midnight Lunch Edition)

---

Ah, as madrugadas dos anos 1990...
O barulho do modem discando, o brilho do monitor CRT iluminando o quarto, e o som suave do cooler misturado ao zumbido do transformador.
Era a era dourada dos micreiros românticos, os guardiões do DOS, os padres do Windows 3.11 e os filósofos do Pentium 100.
E quando o cansaço batia — ou o download do ICQ demorava três horas — o PC começava a sonhar.

Nascia o espetáculo dos screensavers dançarinos, o ballet pixelado que embalava as madrugadas de quem acreditava que tecnologia também podia ser poesia.

---

🕊️ Flying Toasters – os anjos do ciberespaço

Antes do metaverso, vieram as torradeiras voadoras.
Criadas pela Berkeley Systems, no pacote lendário After Dark, eram ícones flutuando no infinito digital — asas metálicas, pão quentinho e música imaginária.
Não serviam pra nada.
Mas hipnotizavam como um mantra eletrônico.

💡 Curiosidade: o sucesso foi tão absurdo que gerou uma linha de produtos — canecas, camisetas, até adesivos de carro.
Ter o Flying Toasters era sinal de status tecnológico. Era dizer: “Meu monitor é SVGA e meu coração é ASCII.”

---

🏝️ Johnny Castaway – o náufrago do microchip

O screensaver mais filosófico da história.
Criado pela Sierra On-Line (1992), mostrava Johnny, um solitário náufrago preso em uma ilha minúscula, vivendo pequenas aventuras animadas: pescava, dormia, falava com gaivotas e tentava fugir.
Cada aparição era diferente — um pequeno episódio inédito, um slice of life do mar digital.

💾 Segredo: quem deixava o PC ligado por horas, via novas cenas escondidas — Johnny construindo jangada, recebendo visitas, ou olhando pro horizonte… esperando alguém que nunca vinha.

O Johnny não era só um protetor de tela.
Era uma metáfora da vida do programador dos anos 90.

---

🐶 Bad Dog – o mascote destruidor

Esse vinha no After Dark e era pura anarquia digital.
Um cachorro de desenho animado invadia o desktop, cavava buracos, mordia ícones e arrastava janelas como se fosse um hacker canino.
Nos escritórios, era o terror dos chefes e o deleite dos estagiários.

🐾 Fofoquice: diziam que o animador se inspirou no cachorro do vizinho — um dálmata chamado “Bingo”, que realmente roía cabos de impressora.
Ironia: o Bad Dog foi acusado de “comportamento destrutivo” por empresas de antivírus, o que o tornou ainda mais amado.

---

🌌 Starfield Simulation – o salto para o hiperespaço

Vinha de fábrica no Windows 95 e transformava o monitor num túnel de estrelas.
Simples, hipnótico e infinitamente elegante.
Era o screensaver oficial dos sonhadores espaciais e dos micreiros que juravam que um dia seriam astronautas… ou pelo menos comprariam uma Voodoo 3Dfx.

💡 Dica técnica: quanto mais rápido o seu processador, mais rápido o salto estelar.
Nos Pentium 200, parecia que o computador ia decolar de verdade.

---

🔮 Mystify / Pipes 3D – o balé geométrico

Linhas dançantes, cores mutantes e tubos 3D crescendo como se o Windows tivesse vida própria.
Era o show de luzes particular de quem deixava o PC renderizando sonhos.

Nos laboratórios de informática, o Pipes 3D era o padrão: o símbolo visual do poder — e do tédio — das máquinas modernas.
💾 O ritual era clássico:
“Sai do Word, não mexe, deixa o Pipes rodar...”
E todo mundo hipnotizado vendo aquele labirinto infinito nascer.

---

🐠 Aquarium & Planetarium – zen digital

Enquanto o caos reinava nas planilhas e nos disquetes, havia os screensavers serenos.
Peixes pixelados nadando suavemente, planetas girando em silêncio cósmico.
Eram o lo-fi beats dos anos 90 — calmaria de bits para quem passou o dia digitando comandos em CAPS LOCK.

💡 Curiosidade: alguns pacotes de Aquarium vinham com trilhas sonoras MIDI e “bolhas” em estéreo — um luxo digno de Sound Blaster 16.

---

☕ Bellacosa comenta:

Os screensavers dos anos 1990 eram mais do que proteção contra o burn-in.
Eram o espelho da nossa relação com a máquina.
Enquanto os atuais pedem login, nuvem e IA, aqueles precisavam só de uma pausa e um pouco de curiosidade.

Eles dançavam quando você descansava.
Sonhavam quando você dormia.
E, talvez sem querer, ensinaram uma geração que tecnologia pode — e deve — ter alma.

---

💡 Dica do El Jefe Midnight Lunch:

Quer reviver essa magia?

• Baixe o After Dark Revival ou o OpenSaver Project.

• Ligue seu monitor de tubo (ou um emulador CRT).

• Coloque um MIDI de Enigma ou Jean-Michel Jarre tocando ao fundo.

E quando o Johnny Castaway aparecer na tela, acene pra ele.
Porque ele ainda está lá —
esperando por nós, micreiros da madrugada.

Simuilador javascript Johnny Castaway

https://eljefemidnightlunch.blogspot.com/1991/01/johnny-castaway-uma-homenagem-ao.html

🧠☕ Bellacosa Mainframe apresenta: El Jefe e o mito do Johnny Castaway — o náufrago digital que vive em nossos corações CRT

 

Bellacosa Mainframe apresenta o mitologico Johnny Castaway

🧠☕ Bellacosa Mainframe apresenta: El Jefe e o mito do Johnny Castaway — o náufrago digital que vive em nossos corações CRT

---

Nos idos dos anos 1990, quando o som de um modem 56k ainda fazia o coração bater mais rápido e o Windows 95 era sinônimo de modernidade, surgiu uma figura solitária que povoou milhões de telas e imaginários: Johnny Castaway, o homem preso numa ilha pixelada, sobrevivendo ao tédio... e ao screensaver.

Sim, padawan — antes do TikTok, do YouTube e até do MSN Messenger, nós tínhamos salvadores de tela com alma. E nenhum foi mais emblemático do que o “Johnny Castaway”, o protetor de tela lançado pela Sierra On-Line em 1992, dentro da linha Screen Antics.

---

🌴 A História

John Castaway era um náufrago de camisa rasgada, barba por fazer e o eterno olhar de quem já tinha aceitado o caos da vida.
Preso numa minúscula ilha com um coqueiro e uma gaivota, ele fazia de tudo para não enlouquecer: pescava, construía, sonhava, e — às vezes — enviava mensagens dentro de garrafas.
O detalhe genial: suas animações mudavam conforme o tempo. Havia dezenas de pequenas cenas, algumas raríssimas, que apareciam de forma aleatória, como um easter egg para quem deixava o computador ocioso por horas.

---

🧩 Origem e bastidores

Criado pela Dynamix, subsidiária da Sierra, o screensaver era quase um experimento artístico. Ele rodava sobre o sistema Windows 3.1, e sua lógica interna funcionava como um mini game engine — cada animação era um “evento” programado.
O design lembrava os jogos King’s Quest e Leisure Suit Larry, com aquele mesmo humor sarcástico e a estética VGA 256 cores que era pura poesia em 640x480.

Reza a lenda (e aqui entra o lado fofoquinha da Bellacosa Mainframe 🕵️‍♂️):
um dos animadores, ex-programador de Space Quest, teria usado o próprio rosto como referência para o John. E o nome “Castaway”? Veio de uma piada interna no estúdio sobre um funcionário que “sumia” da baía de Monterey nos fins de semana para surfar e não voltava na segunda.

---

💾 Impacto cultural

Johnny Castaway foi o primeiro protetor de tela com narrativa, um pequeno storytelling que rodava escondido enquanto você tomava café.

Ele virou ícone de nostalgia digital, símbolo de uma época em que o computador era quase um companheiro de jornada.
E se você perguntar a qualquer veterano da era 486DX2, ele vai sorrir e dizer: “Ah, o náufrago! Aquele que nunca foi resgatado…”

John foi o primeiro “personagem digital persistente” de muita gente. Num tempo em que não existia The Sims nem Animal Crossing, o Castaway era a nossa janela pra um mundinho animado, com humor, rotina e um toque melancólico. Ele virou assunto em fóruns, revistas de tecnologia e até em lan houses — o pessoal deixava o PC ocioso só pra ver o que ele ia aprontar.

Nos fóruns e subreddits de retrocomputing, até hoje há pedidos de remakes ou versões em HTML5. Alguns heróis anônimos já recriaram o Johnny em emuladores, outros até o portaram para Android. É o espírito da ilha sobrevivendo no tempo.

---

🔍 Curiosidades dignas de café forte:

• Ele tinha mais de 35 animações diferentes — uma mini-série escondida no seu PC.

• O programa usava o relógio do sistema, então ele vivia em “tempo real” — o pôr do sol acontecia quando era pôr do sol de verdade.

• O arquivo original tinha menos de 1 MB. Hoje, um sticker de WhatsApp ocupa mais espaço.

• Nos bastidores da Sierra, o projeto era chamado de The Deserted Developer.

• Em 2020, fãs recriaram a experiência em HTML5, batizando o site de “Johnny Recastaway”.

---

💡 Dica de El Jefe

Quer reviver a ilha? Há versões rodando via emulador de Windows 3.1 online. Procure “Johnny Castaway em DOSBox” — é pura arqueologia digital, mas vale cada frame.
E, claro, cuidado: assistir por muito tempo pode causar um súbito desejo de jogar Leisure Suit Larry e ouvir MIDI Jazz.

---

    

☕ Conclusão Bellacosa

Johnny Castaway não era apenas um protetor de tela. Era um espelho da alma do programador dos anos 90: isolado, criativo, meio perdido e sempre tentando mandar uma mensagem dentro de uma garrafa digital.

Ele é o primeiro filósofo do idle time, o estoico dos CRTs, o Sêneca da areia pixelada.
E, no fundo, cada um de nós, entre commits, deadlines e janelas travadas, é um pequeno Johnny olhando o horizonte, esperando o resgate… ou o próximo frame de animação.

---

🪶 Assinado: El Jefe do Bellacosa Mainframe – porque até um screensaver pode ensinar mais sobre a solidão humana do que muita reunião de sprint.

Simuilador javascript Johnny Castaway

https://eljefemidnightlunch.blogspot.com/1991/01/johnny-castaway-uma-homenagem-ao.html

🎞️ Hey Macaroni! — Quando o Windows dançava com a Madonna do disquete

 

Bellacosa Mainframe e o mitico screensaver hey macaroni

🎞️ Hey Macaroni! — Quando o Windows dançava com a Madonna do disquete
(Por Vagner Bellacosa ☕ – Bellacosa Mainframe / El Jefe Midnight Lunch Edition)

---

Ah… o Windows 95, o som metálico do HD acordando, a tela azul “It’s now safe to turn off your computer”, e aquele tempo mágico em que até o protetor de tela tinha alma e ritmo.
Hoje, vamos falar de um clássico obscuro e hilário do folclore digital dos anos 1990: o Hey Macaroni!, o screensaver que parecia nascido de um sonho febril entre o CD-ROM da Encarta e o VHS do “Cassino do Chacrinha”.

---

🌀 A origem: quando o PC decidiu virar dançarino

O “Hey Macaroni!” fazia parte da coleção After Dark, uma série lendária de screensavers criados pela Berkeley Systems (sim, os mesmos do Flying Toasters).
Lançado entre 1993 e 1995, o pacote trazia protetores de tela que eram verdadeiros mini desenhos animados — humor, surrealismo e uma pitada de nonsense à la MTV Liquid Television.

O Hey Macaroni! em si mostrava um personagem cartunesco de bigodinho e roupa estilo mafioso siciliano, dançando como um louco ao som de uma paródia pseudo-italiana que repetia o mantra:
🎵 “Hey Macaroni!” 🎵

Era uma explosão de cor, ritmo e bizarrice — e, para muitos, a primeira forma de animação “musical” que viram num computador.
Num tempo em que a placa de som era opcional, ouvir aquele beat digitalizado era o equivalente a ter Dolby Surround no escritório.

---

🍝 Curiosidades que só um Bellacosa lembraria

• 💾 O Hey Macaroni! vinha em disquete, depois em CD-ROM. Instalava junto com o After Dark 3.0 — e roubava a cena de todos os outros protetores, incluindo o clássico Flying Toasters.

• 🎨 O personagem foi desenhado por Jack Eastman, animador que trabalhava com o software Director, precursor do Flash.

• 🕺 Alguns diziam que era uma sátira à música “Macarena”, mas na verdade ele é anterior à febre do grupo Los del Río. Ou seja: o Hey Macaroni dançava antes da Macarena existir.

• 🎬 Em fóruns antigos, fãs descobriram um easter egg: se você deixasse o screensaver por mais de 20 minutos, o Macaroni começava a improvisar passos novos e girar o prato de espaguete em loop infinito.

---

💾 O impacto cultural

Nos escritórios e lan houses da época, o Hey Macaroni era sinal de status:
se o seu computador tinha placa de som Sound Blaster e conseguia rodar o Hey Macaroni! com áudio sincronizado, você era o sysadmin do pedaço.

Ele virou meme antes do termo existir — o tipo de animação que colegas chamavam pra ver:
“Olha aqui, o cara dançando dentro do PC! Esse é o futuro!”

Era a época em que os protetores de tela eram a alma da máquina — os screensavers eram como os papéis de parede da geração Y2K: uma forma de mostrar personalidade digital.

---

🧠 Fofoquices de bastidor

• 👀 Reza a lenda que o criador se inspirou num tio italiano que servia num restaurante em San Francisco e dançava com pratos de macarrão para entreter clientes.

• 📼 O som “Hey Macaroni!” foi gravado por um estagiário da Berkeley Systems que, segundo entrevistas, nunca mais quis ouvir essa frase na vida.

• 💡 O código do protetor era tão “artesanal” que travava em certas versões do Windows NT — e alguns o consideram o primeiro crash divertido da história.

---

☕ Bellacosa comenta:

O “Hey Macaroni!” é a prova de que a informática dos anos 1990 era lúdica, ingênua e viva.
Os PCs não eram apenas ferramentas — eram brinquedos caros que faziam barulho, piscavam e dançavam com você.

Hoje o protetor de tela é só um recurso para economizar energia; antes, era uma galeria digital de humor surreal.
E enquanto os toasters voavam e o Macaroni dançava, nós aprendíamos — sem perceber — que o computador podia ser divertido.

---

💡 Dica do El Jefe Midnight Lunch:

Quer reviver esse momento?

• Baixe o After Dark Screensaver Collection (Windows 3.1/95) e rode num emulador.

• Coloque um MIDI italiano de fundo, abra um copo de Yakult gelado e sinta o espírito do ciberespaço 1994.

• E lembre-se: se o computador começar a dançar sozinho…
  não é vírus.
  É só o Macaroni te chamando pra festa.

Para ir mais longe

https://eljefemidnightlunch.blogspot.com/2020/11/bellacosa-mainframe-apresenta-el-jefe-e.html

https://eljefemidnightlunch.blogspot.com/2015/12/os-primeiros-screen-saver-nossos.html

https://eljefemidnightlunch.blogspot.com/2014/11/saco-de-gatos-um-manifesto-de-papelao.html

https://eljefemidnightlunch.blogspot.com/2022/08/screensavers-que-dancavam-na-madrugada.html

💾 Capítulo 3 — Boot inicial: o mundo além da escola

Bellacosa Mainframe um eterno isekai

 

📚 SÉRIE “Sempre um Isekai”

Por Bellacosa Mainframe
(Memórias de um garoto que aprendeu a trocar de mundo sem sair da sala de aula)

💾 Capítulo 3 — Boot inicial: o mundo além da escola

O fim do colegial chegou rápido — como o ponto final de um livro que a gente queria que tivesse mais capítulos.
Mas o próximo volume já estava sendo escrito: o mundo do trabalho.

Com o diploma técnico em mãos e a curiosidade de quem sempre foi estrangeiro de si mesmo, entrei no universo do Processamento de Dados — ainda não se falava em “TI”.
Era um tempo em que o computador ocupava salas inteiras, e a palavra “mainframe” soava como magia industrial.
Aquele mundo lógico e silencioso me acolheu como nenhum outro.
Ali, finalmente, eu não era o aluno novo — eu era o programador que aprendia a dialogar com máquinas, e cada compile successful era uma nova forma de pertencer.

Percebi que, afinal, viver em trânsito não era desvantagem — era um sistema operacional de alma.
Ser o “novo” sempre me ensinou a observar, adaptar e reconstruir — exatamente o que um bom analista faz.
Minha vida inteira foi um boot contínuo: cada cidade, uma reinicialização; cada escola, uma nova rotina; cada linha de código, uma lembrança em hexadecimal.

Trabalhando como office-boy foi conquistando meu espaço, crescendo, fiz a faculdade, pós-graduação e mestrado, cresci academicamente, mas não abandonei os meus, protegi o quanto pode e ajudei a todos a trilharem o bom caminho. Não imagina que seria apenas o começo e que este isekai iria ainda mais longe, desta vez atravessando o oceano, mas isso já é outra história.

E talvez seja isso o que nos torna humanos no mundo das máquinas: a capacidade de recomeçar sem perder a memória.

---

☕ Epílogo — O Isekai Real

No fim das contas, percebo que nunca precisei ser transplantado para outro mundo.
Meu isekai sempre foi aqui mesmo — entre escolas, cidades e sistemas que me forjaram.
E, como todo bom personagem de jornada, aprendi que mudar é só outra forma de continuar.

---

Série “Sempre um Isekai”
Um relato sobre educação, adaptação e vocação — onde cada reboot é também um renascimento.
Assinado: Bellacosa Mainframe

 

Bellacosa Mainframe e a auditoria em computadores

☕ Um Café no Bellacosa Mainframe

🧙‍♂️ LLOYD DE SALOUM E A DUNGEON DA MICROINFORMÁTICA — QUANDO O PC VIROU BUSINESS COMPUTER

COBOL, mainframe, PCs, Winchester, Lotus 1-2-3, antivírus, backup, auditoria, Shadow IT, ITAM, CMDB, Cloud e IA — e o dia em que Lloyd descobriu que o aplicativo secreto do Financeiro era mais perigoso que um demônio ancestral.

---

🎬 PRÓLOGO — LLOYD ENCONTROU UM PC DEBAIXO DA MESA

— Lloyd-sama, temos um problema.

Lloyd de Saloum levantou os olhos.

Aquilo normalmente significava uma excelente oportunidade para aprender alguma magia nova.

— Um demônio?

— Não.

— Uma maldição?

— Também não.

— Um artefato mágico proibido?

— Pior. Encontramos um computador no Financeiro que ninguém da Informática sabia que existia.

Os olhos de Lloyd brilharam.

— Interessante!

O pobre auditor percebeu imediatamente que havia cometido um erro.

Poucos minutos depois, Lloyd estava ajoelhado diante da máquina.

Na tela:

C:\>

No disco rígido havia planilhas, documentos, programas em dBASE, arquivos de clientes, backups de backups, executáveis de procedência desconhecida e um diretório chamado:

C:\NOVO\FINAL\BACKUP\VELHO

— Fascinante!

— Lloyd-sama, isso não deveria estar aqui.

— Por quê?

Essa pergunta aparentemente inocente nos leva a uma das transformações mais importantes da história da informática corporativa.

Durante décadas, empresas construíram regras rigorosas para controlar computadores centrais, aplicações COBOL, arquivos, bancos de dados, usuários, backups e mudanças.

Então chegaram os microcomputadores.

E milhares de usuários descobriram que podiam fazer muita coisa sem pedir autorização ao velho CPD.

Nascia uma revolução.

E, junto com ela, uma enorme dungeon chamada:

AUDITORIA DE MICROINFORMÁTICA.

---

🏰 CAPÍTULO 1 — QUANDO O COMPUTADOR MORAVA NO CASTELO

Para entender a auditoria de microinformática, nosso jovem programador COBOL precisa voltar algumas décadas.

Em uma empresa tradicional, o processamento de dados era altamente centralizado.

Podíamos ter algo parecido com:

                    ┌─────────────────┐
                    │    MAINFRAME    │
                    │                 │
                    │ COBOL           │
                    │ CICS            │
                    │ IMS             │
                    │ DB2             │
                    │ VSAM            │
                    └────────┬────────┘
                             │
                 ┌───────────┴───────────┐
                 │                       │
             TERMINAL                TERMINAL
                 │                       │
              Usuário                 Usuário

O terminal normalmente não era um computador independente como conhecemos hoje.

Ele era uma janela para o sistema central.

O processamento estava no mainframe.

Os programas estavam sob controle da área de tecnologia.

Os dados estavam em datasets, bancos ou arquivos administrados.

Havia procedimentos para produção.

Havia operadores.

Havia controle de acesso.

Havia backup.

Havia processos de mudança.

Mesmo que tudo isso não fosse perfeito, existia uma importante característica:

centralização.

Se Lloyd perguntasse:

— Onde está a folha de pagamento?

Provavelmente alguém poderia responder:

— Na aplicação XPTO, executada no mainframe, usando estes programas COBOL, estes arquivos e este banco de dados.

Isso é governança.

Então alguém colocou um computador sobre uma mesa.

---

🖥️ CAPÍTULO 2 — O PC ESCAPOU DO CPD

O Personal Computer mudou completamente a relação entre usuário e tecnologia.

Agora um departamento podia ter poder computacional próprio.

Financeiro podia criar planilhas.

Engenharia podia comprar aplicativos.

Recursos Humanos podia montar uma pequena base de dados.

Vendas podia desenvolver um sistema departamental.

O computador deixou de ser somente uma janela para o grande computador central.

Ele próprio processava informações.

Imagine:

                 MAINFRAME
                     │
            Sistemas Corporativos
                     │
        ─────────────┼─────────────
                     │
                    LAN
                     │
        ┌────────────┼────────────┐
        │            │            │
    Financeiro     Vendas     Engenharia
        │            │            │
       PC           PC           PC
        │            │            │
     Lotus        dBASE      Aplicativo

Parece maravilhoso.

E realmente foi uma revolução de produtividade.

Mas existe uma pergunta:

quem controla tudo isso?

O programador COBOL acostumado ao mainframe talvez estranhasse.

No ambiente centralizado, para colocar uma aplicação importante em produção, normalmente existiam processos.

No PC departamental alguém poderia simplesmente criar:

C:\CONTAS\FATURA.DBF

E, seis meses depois, aquele arquivo estar participando do fechamento financeiro da empresa.

Sem que ninguém tivesse percebido quando uma experiência virou aplicação crítica.

Essa transformação é fundamental para entender todo o nosso tema.

O PC estava deixando de ser apenas Personal Computer.

Estava virando:

Business Computer.

BC.

Computador de negócios.

---

🧙 CAPÍTULO 3 — LLOYD DESCOBRE QUE A MAGIA FUNCIONA SEM AUTORIZAÇÃO

Lloyd provavelmente adoraria microcomputadores.

Porque eles representavam liberdade.

Você podia experimentar.

Instalar.

Programar.

Criar.

Testar.

Automatizar.

O problema empresarial aparece quando confundimos:

liberdade para experimentar

com:

liberdade para criar processos corporativos sem governança.

Imagine João, funcionário do Financeiro.

Todo mês ele recebe um arquivo e leva oito horas para produzir determinado relatório.

João aprende dBASE.

Cria uma pequena aplicação.

Agora leva vinte minutos.

Fantástico!

Depois outras pessoas começam a usar.

Dois anos depois:

Programa do João
       ↓
Relatório financeiro
       ↓
Fechamento mensal
       ↓
Diretoria
       ↓
Decisão empresarial

Parabéns.

João acabou de criar um sistema crítico.

Só existe um pequeno problema.

Ninguém sabe disso.

---

👻 CAPÍTULO 4 — O ANCESTRAL DO SHADOW IT

Hoje usamos a expressão Shadow IT para tecnologia utilizada fora da governança ou visibilidade formal da organização.

Mas Shadow IT não nasceu com Cloud.

Muito antes de alguém criar uma máquina virtual escondida na AWS, havia aplicações escondidas em PCs.

Podia ser:

Lotus 1-2-3
Excel
Access
dBASE
FoxPro
Clipper
Macros
scripts
executáveis locais

O usuário não estava necessariamente tentando sabotar a empresa.

Na maioria dos casos queria resolver um problema.

Essa distinção é importante.

Shadow IT frequentemente nasce de uma combinação de:

necessidade urgente
        +
tecnologia acessível
        +
processo corporativo lento
        =
solução paralela

O auditor inteligente não deveria simplesmente perguntar:

— Quem foi o irresponsável que fez isso?

Deveria perguntar:

— Por que a organização precisou disso?

Porque uma aplicação clandestina também pode ser sintoma de outro problema.

Talvez o departamento de TI demore oito meses para atender uma necessidade que o negócio precisa resolver em oito dias.

---

💰 CAPÍTULO 5 — AUDITORIA NÃO É CAÇA ÀS BRUXAS

Existe uma visão pobre de auditoria:

encontrar alguém fazendo algo errado.

Uma boa auditoria é muito mais interessante.

Ela procura compreender:

PROCESSO
   ↓
RISCO
   ↓
CONTROLE
   ↓
EVIDÊNCIA
   ↓
EXCEÇÃO
   ↓
IMPACTO
   ↓
AÇÃO

Suponha que encontramos dez computadores com determinado software instalado.

O auditor não deveria imediatamente gritar:

— IRREGULARIDADE!

Primeiro precisamos entender.

As dez licenças existem?

São necessárias?

São utilizadas?

Existem vinte licenças compradas e apenas dez usadas?

Outro departamento pretende comprar cinco?

Perceba a mudança.

A auditoria pode descobrir economia.

Departamento A:

20 licenças compradas
10 utilizadas
10 ociosas

Departamento B:

10 utilizadas
precisa de mais 5

Sem inventário, B compra cinco novas licenças.

Com governança, talvez seja possível reaproveitar licenças disponíveis, dependendo das condições contratuais do produto.

Auditoria também é otimização de recursos.

---

📦 CAPÍTULO 6 — O SOFTWARE QUE NINGUÉM USAVA

Outra preocupação clássica era encontrar software instalado e não utilizado.

Isso parece pequeno até multiplicarmos pelo tamanho da empresa.

Imagine 3.000 computadores.

Agora imagine software pago instalado em centenas deles sem necessidade.

Dinheiro parado.

O mesmo vale para hardware.

Uma área pode possuir computadores subutilizados enquanto outra solicita equipamentos novos.

Daí a necessidade de conhecer:

• localização;

• departamento;

• usuário responsável;

• fabricante;

• modelo;

• configuração;

• número de série;

• software instalado;

• situação operacional;

• manutenção;

• movimentações.

Hoje chamamos grande parte desse universo de IT Asset Management — ITAM.

Para software existe Software Asset Management — SAM.

O velho inventário da microinformática evoluiu.

Mas a pergunta continua:

O que possuímos, onde está, quem usa, quanto custa e ainda precisamos disso?

---

🗃️ CAPÍTULO 7 — O CADASTRO DIZ 327, MAS LLOYD CONTOU 319

Aqui entramos no coração da auditoria.

Imagine o cadastro:

MICROCOMPUTADORES: 327

Lloyd percorre a empresa e encontra:

MICROCOMPUTADORES: 319

Faltam oito.

Isso não significa automaticamente fraude.

Podem estar:

• em manutenção;

• transferidos;

• emprestados;

• armazenados;

• descartados;

• substituídos;

• roubados;

• simplesmente cadastrados incorretamente.

Mas existe uma diferença.

E diferenças precisam ser explicadas.

É por isso que o texto original insiste tanto em:

bater cadastro de hardware e software com o existente.

Hoje chamaríamos isso de reconciliação.

O que nossa base acredita existir precisa ser comparado ao que realmente existe.

Esse princípio aparece em CMDBs modernas.

---

🧠 CAPÍTULO 8 — A EMPRESA TEM CÓDIGO, MAS PERDEU A MEMÓRIA

Agora chegamos a uma das questões mais profundas:

Como preservar a memória da empresa diante do turnover?

Voltemos ao João.

João criou uma aplicação.

Durante quinze anos recebeu solicitações:

— João, cliente XPTO precisa de tratamento diferente.

João altera.

Depois:

— João, quando o produto for 37, calcule assim.

João altera.

Depois:

— João, operações realizadas depois das 17h precisam entrar no próximo ciclo.

João altera.

Quinze anos depois existe isto:

IF CLIENTE = 'XPTO'
   ...
END-IF

A empresa possui o código.

Mas por que XPTO é diferente?

João sabe.

O programa não.

Então João se aposenta.

💀

Essa situação não é exclusividade da microinformática.

Programador COBOL conhece perfeitamente esse fenômeno.

Podemos possuir o fonte de um programa de 1989 e ainda assim não possuir todo o conhecimento necessário para compreender por que ele foi construído daquela maneira.

Existe diferença entre:

CÓDIGO

e:

CONHECIMENTO

Código registra o que acontece.

Documentação, histórico, requisitos, tickets e conhecimento humano ajudam a explicar por que acontece.

---

📝 CAPÍTULO 9 — DOCUMENTAÇÃO NÃO É DECORAÇÃO

Por isso “documentação inexistente” aparece como risco.

Imagine encontrar:

CALCULA.EXE

Perguntas:

Quem desenvolveu?

Qual linguagem?

Onde está o fonte?

Qual versão está em produção?

Quais arquivos utiliza?

Quem pode alterar?

Existe procedimento de instalação?

Como recuperar?

Qual é a regra de negócio?

Quem é responsável?

Sem respostas, temos uma espécie de artefato mágico.

Funciona.

Ninguém sabe exatamente como.

Lloyd adoraria.

O auditor teria pesadelos.

---

💾 CAPÍTULO 10 — WINCHESTER NÃO É ARQUIVO MORTO

Para os Padawans que nasceram na era do SSD: “Winchester” tornou-se uma forma popular de chamar o disco rígido.

E havia um problema.

O usuário descobria espaço em disco e começava a guardar tudo.

Logo apareciam estruturas dignas de arqueologia:

C:\
 ├── TESTE
 ├── TESTE2
 ├── TESTEVELHO
 ├── BACKUP
 ├── BACKUP2
 ├── NOVO
 ├── NOVO2
 ├── FINAL
 └── FINAL_AGORA_VAI

Parece antigo?

Abra uma pasta corporativa moderna.

Talvez encontre:

Contrato_Final.docx
Contrato_Final2.docx
Contrato_Final_Novo.docx
Contrato_Final_Revisado.docx
Contrato_Final_Revisado_FINAL.docx
Contrato_Final_Revisado_FINAL_v3.docx

Mudamos de storage.

O ser humano permaneceu compatível com versões anteriores.

Essa é a verdadeira retrocompatibilidade.

---

🧹 CAPÍTULO 11 — FRAGMENTAÇÃO, DEFRAG E ARQUEOLOGIA DOS DISCOS

O texto original também menciona arquivos fragmentados.

Nos discos magnéticos, um arquivo podia acabar armazenado em partes espalhadas pelo disco.

Simplificando:

Arquivo A:

[10][11][12] ........ [58] .... [97]

Um disco mecânico possui partes móveis.

O cabeçote precisa acessar diferentes posições.

Quanto mais espalhados os dados, potencialmente maior o trabalho necessário para determinadas operações.

Daí a popularização de ferramentas de desfragmentação.

Quem viveu DOS e Windows antigos provavelmente lembra de utilitários como DEFRAG, além de ferramentas de diagnóstico e manutenção de disco.

Mas atenção:

não devemos transportar automaticamente essa prática para SSDs modernos.

SSDs funcionam de maneira diferente, não possuem cabeçote mecânico e utilizam mecanismos como wear leveling e TRIM.

Aqui existe uma lição fantástica para auditoria:

o princípio pode sobreviver mesmo quando o controle técnico fica obsoleto.

O princípio era:

manter armazenamento saudável, organizado e adequadamente administrado.

A implementação mudou.

---

🦠 CAPÍTULO 12 — O DEMÔNIO VIAJAVA DE DISQUETE

Outra preocupação era antivírus.

Durante a era da microinformática, disquetes eram excelentes meios de transporte para dados.

E para vírus.

Um disquete passava por:

PC A
 ↓
PC B
 ↓
PC C
 ↓
casa
 ↓
PC D
 ↓
empresa

O malware ganhava transporte gratuito.

Com o tempo vieram vírus de arquivos, boot sector, macrovírus e inúmeras outras famílias.

Hoje a pergunta:

“Existe antivírus?”

é insuficiente.

Em um ambiente moderno poderíamos investigar:

EDR/XDR
patch management
hardening
MFA
least privilege
application control
telemetria
SIEM
resposta a incidentes
gestão de vulnerabilidades

A pergunta fundamental permanece:

Conseguimos prevenir, detectar, investigar e responder a comportamento malicioso no endpoint?

---

🔐 CAPÍTULO 13 — O PC DESCOBRIU QUE PRECISAVA DE RACF

Aqui temos um choque cultural delicioso para quem conhece mainframe.

O mainframe corporativo já possuía uma longa tradição de controles de acesso.

No mundo IBM Z podemos pensar em mecanismos como RACF e outros componentes de segurança.

Mas muitos PCs antigos foram concebidos originalmente para um contexto bastante diferente.

O usuário ligava a máquina e encontrava:

C:\>

Não existia necessariamente aquele mesmo modelo corporativo robusto de identidade, autorização e auditoria.

Quando o PC começou a processar informações importantes, surgiu uma pergunta inevitável:

Como transportar os conceitos de segurança existentes nos ambientes corporativos para a microinformática?

Não significava instalar RACF em DOS.

Significava transportar princípios.

MAINFRAME                  ENDPOINT

Identidade       →         Conta do usuário
Autorização      →         Permissões
Dataset          →         Arquivo/pasta
Auditoria        →         Logs
Backup           →         Backup endpoint
Change control   →         Gestão de software
Inventário       →         Asset Management

A tecnologia muda.

O objetivo do controle permanece.

---

🌐 CAPÍTULO 14 — MICRO E MAINFRAME SE ENCONTRAM

Outro item importantíssimo era a ligação micro/mainframe.

Primeiro o PC podia funcionar quase como terminal.

Depois começaram transferências de arquivos.

Depois vieram redes, client/server, aplicações gráficas e integrações cada vez mais sofisticadas.

Hoje podemos ter:

Notebook
   ↓
Browser
   ↓
Aplicação Web
   ↓
API Gateway
   ↓
API
   ↓
z/OS Connect
   ↓
CICS
   ↓
COBOL
   ↓
Db2

O usuário talvez nem saiba que existe COBOL.

Ele aperta:

CONFIRMAR PAGAMENTO

e, alguns milissegundos depois, uma transação pode estar chegando a uma aplicação no mainframe.

A velha pergunta:

“Como o micro se conecta ao mainframe?”

evoluiu para:

“Como endpoints, canais digitais, aplicações distribuídas, APIs, cloud e parceiros acessam os serviços corporativos?”

É a mesma árvore genealógica.

---

💽 CAPÍTULO 15 — BACKUP NÃO É COPIAR PARA BACKUP2

Lloyd encontra uma pasta:

C:\BACKUP

— Excelente! Há backup!

Não necessariamente.

Talvez ela esteja no mesmo disco.

Se o disco morrer:

ORIGINAL  → morreu
BACKUP    → morreu junto

Um verdadeiro backup exige planejamento.

O documento original já perguntava:

• periodicidade;

• responsável;

• local de guarda;

• como recuperar.

A última questão vale ouro:

como recuperar?

Backup que nunca foi testado é uma promessa.

Em ambientes modernos adicionamos conceitos como:

RPO — Recovery Point Objective

Quanto dado podemos tolerar perder?

RTO — Recovery Time Objective

Quanto tempo podemos tolerar ficar sem o serviço?

Além disso:

• retenção;

• cópias off-site;

• criptografia;

• imutabilidade;

• testes de restauração;

• proteção contra ransomware;

• estratégia 3-2-1 quando apropriada.

A evolução conceitual é interessante:

BACKUP
   ↓
RECOVERY
   ↓
DISASTER RECOVERY
   ↓
BUSINESS CONTINUITY
   ↓
CYBER RESILIENCE

Não queremos simplesmente possuir cópias.

Queremos conseguir continuar ou recuperar o negócio.

---

⚡ CAPÍTULO 16 — CONFIG.SYS E AUTOEXEC.BAT: NÃO MEXA NO GRIMÓRIO

Quem viveu DOS provavelmente sorriu ao encontrar:

CONFIG.SYS
AUTOEXEC.BAT

Esses arquivos participavam da configuração do ambiente.

Alterações podiam carregar drivers, modificar memória, definir variáveis, caminhos e executar comandos durante a inicialização.

Era perfeitamente possível alguém “otimizar” a máquina e quebrar alguma coisa.

Isso nos leva a outro conceito moderno:

Configuration Management.

Configuração também é ativo.

Hoje não estamos preocupados com AUTOEXEC.BAT da mesma maneira.

Estamos preocupados com:

políticas
registry
GPO
MDM
containers
YAML
Terraform
Ansible
Kubernetes manifests
cloud configuration

Novamente:

o arquivo mudou.

O problema continuou.

---

📚 CAPÍTULO 17 — O CATÁLOGO DE SOFTWARE

O documento propõe manter um catálogo de software.

Excelente ideia.

Imagine três departamentos.

Todos precisam resolver o mesmo problema.

Cada um contrata um fornecedor diferente.

Resultado:

Área A → Sistema X
Área B → Sistema Y
Área C → Sistema Z

Agora temos três contratos, três tecnologias, três equipes, três processos de suporte e três integrações.

Talvez exista justificativa.

Mas talvez ninguém soubesse que uma solução já existia.

Um catálogo corporativo ajuda a responder:

Já temos alguma coisa que faz isso?

Esse conceito evoluiu para catálogos de aplicações, portfolios de aplicações e ferramentas de Application Portfolio Management.

---

🧪 CAPÍTULO 18 — COMO LLOYD FARIA UMA AUDITORIA

Vamos transformar tudo em um pequeno laboratório.

Etapa 1 — Conheça a história

Pergunte:

Quando começou a microinformática?

Por quê?

Quem decidiu?

Havia estratégia?

Compra ou aluguel?

Existia padronização?

Etapa 2 — Conheça as políticas

Descubra quais normas deveriam ser cumpridas.

Sem critério não existe avaliação consistente.

Etapa 3 — Obtenha o inventário

Precisamos saber o que a organização acredita possuir.

Etapa 4 — Vá a campo

Agora verificamos o que realmente existe.

Etapa 5 — Compare

REGISTRO
   versus
REALIDADE

Etapa 6 — Teste controles

Não pergunte somente:

— Existe backup?

Peça evidência.

Não pergunte somente:

— Existe antivírus?

Verifique.

Não pergunte somente:

— Existe documentação?

Leia.

Etapa 7 — Investigue diferenças

Toda divergência precisa de contexto.

Etapa 8 — Avalie risco

Uma diferença cadastral em um PC isolado não possui necessariamente o mesmo impacto que uma aplicação não documentada processando milhões em operações financeiras.

Etapa 9 — Recomende ações

A recomendação deve atacar causa e risco, não apenas o sintoma.

---

🕵️ CAPÍTULO 19 — O AUDITOR QUE PROCURA CAUSA, NÃO CULPADO

Imagine encontrar um PC sem proteção adequada.

Auditoria superficial:

“Usuário em desacordo com a norma.”

Auditoria investigativa:

Por que isso aconteceu?

Descobrimos que o agente deveria ser instalado automaticamente.

Por que não foi?

A máquina estava fora do inventário.

Por quê?

Foi transferida entre departamentos sem atualização cadastral.

Agora temos uma cadeia:

Transferência inadequada
        ↓
Inventário incorreto
        ↓
Gestão não identifica endpoint
        ↓
Controle não é aplicado
        ↓
Endpoint fica desprotegido

O computador sem proteção era apenas o último sintoma.

A verdadeira descoberta está no processo quebrado.

Isso é muito mais valioso.

---

☁️ CAPÍTULO 20 — O PC VIROU CLOUD

Agora chegamos à ironia histórica.

Décadas atrás:

“O departamento comprou um PC sem informar o CPD.”

Depois:

“Instalaram um software sem informar TI.”

Depois:

“Colocaram um servidor Linux embaixo da mesa.”

Depois:

“Criaram uma VM.”

Depois:

“Contrataram SaaS no cartão corporativo.”

Depois:

“Criaram recursos na Cloud.”

Agora:

“Colaram dados corporativos numa IA generativa.”

Percebeu?

O objeto mudou.

O padrão permanece:

TECNOLOGIA FICA MAIS ACESSÍVEL
             ↓
USUÁRIO GANHA AUTONOMIA
             ↓
INOVAÇÃO ACELERA
             ↓
GOVERNANÇA PERDE VISIBILIDADE
             ↓
RISCO APARECE
             ↓
NOVOS CONTROLES SÃO CRIADOS

É praticamente um ciclo histórico da tecnologia empresarial.

---

🤖 CAPÍTULO 21 — SHADOW AI: O NOVO LOTUS 1-2-3 CLANDESTINO

E chegamos a 2026.

Um funcionário descobre uma ferramenta de IA.

Começa usando para corrigir textos.

Depois resume documentos.

Depois analisa contratos.

Depois envia código.

Depois envia dados de clientes.

Depois constrói um agente.

Em algum momento a experiência pessoal pode virar processo empresarial.

A auditoria moderna deveria perguntar:

Qual ferramenta?
Quem autorizou?
Qual contrato?
Qual modelo?
Quais dados entram?
Onde são processados?
Existe retenção?
Existe logging?
Existe DLP?
Quem revisa as respostas?
Há integração com sistemas?
Quais permissões o agente possui?
Existe supervisão humana?
Como desligamos isso?

Compare com a auditoria antiga:

Qual software?
Quem comprou?
Onde está instalado?
Quem utiliza?
Quais arquivos acessa?
Existe documentação?
Existe backup?
Quem é responsável?

Lloyd provavelmente sorriria.

— É o mesmo feitiço!

Exatamente.

---

🧠 CAPÍTULO 22 — DO PERSONAL COMPUTER AO PERSONAL AGENT

Existe ainda uma evolução curiosa.

O PC democratizou processamento.

A Web democratizou publicação.

Cloud democratizou infraestrutura.

SaaS democratizou software corporativo.

Low-code democratizou desenvolvimento.

IA generativa democratizou parte da produção intelectual e automação.

Agentes começam a democratizar execução autônoma de tarefas.

Portanto a pergunta histórica da auditoria fica ainda mais importante:

Quanto de liberdade podemos oferecer sem perder governança, segurança e responsabilidade?

Não existe resposta simples.

Bloquear tudo destrói produtividade.

Liberar tudo cria riscos.

A solução normalmente está entre os extremos:

AUTONOMIA
    +
GUARDRAILS
    +
OBSERVABILIDADE
    +
RESPONSABILIDADE

---

🧙‍♂️ CAPÍTULO 23 — O QUE UM PROGRAMADOR COBOL TEM A VER COM ISSO?

Tudo.

Você talvez pense:

“Bellacosa, eu só quero programar COBOL.”

Então guarde esta lição.

Um programa não existe isoladamente.

Seu COBOL participa de um ecossistema:

Usuário
 ↓
Canal
 ↓
Aplicação
 ↓
API / MQ / CICS
 ↓
COBOL
 ↓
Db2 / IMS / VSAM
 ↓
Batch
 ↓
Outros sistemas

Cada seta possui:

• identidade;

• autorização;

• configuração;

• logs;

• documentação;

• dependências;

• recuperação;

• responsáveis.

Um excelente programador não conhece somente sintaxe.

Ele começa a entender o sistema ao redor do programa.

---

🏺 CAPÍTULO 24 — SEU PROGRAMA COBOL É UM ARTEFATO HISTÓRICO

Imagine abrir um programa:

       IF WS-CUSTOMER-CODE = 317
           PERFORM SPECIAL-PROCESSING
       END-IF.

Não remova imediatamente.

Pergunte:

Por quê?

Talvez exista uma regra contratual de 1997.

Talvez o cliente nem exista mais.

Talvez seja código morto.

Talvez seja absolutamente crítico.

O auditor e o mantenedor de legado compartilham uma virtude:

desconfiança metodológica.

Não significa suspeitar das pessoas.

Significa não confundir aparência com evidência.

O código compila?

Ótimo.

Mas está correto?

Tem teste?

Tem documentação?

Quem depende dele?

Qual impacto de uma alteração?

Essa mentalidade transforma um digitador de COBOL em engenheiro de sistemas.

---

🕒 CAPÍTULO 25 — O EASTER EGG DAS 03:17

Lloyd encontra uma documentação antiga:

“Não executar antes das 03:17.”

— Por quê?

Silêncio.

Ninguém sabe.

O programador original se aposentou.

O analista que conhecia o processo saiu.

O documento não explica.

Lloyd, naturalmente, executa às 03:16.

A dungeon inteira começa a tremer.

😂

Esse é o easter egg, mas também contém uma lição séria.

Uma organização pode preservar:

O QUE FAZER

e perder:

POR QUE FAZER

Esse segundo conhecimento é frequentemente muito mais difícil de reconstruir.

Por isso bons comentários, documentação, versionamento, tickets, decisões arquiteturais e transferência de conhecimento são tão importantes.

---

🗺️ CAPÍTULO 26 — A EVOLUÇÃO COMPLETA DA DUNGEON

Podemos finalmente montar nosso mapa:

MAINFRAME CENTRALIZADO
        ↓
MICROCOMPUTADOR
        ↓
REDES LOCAIS
        ↓
CLIENT/SERVER
        ↓
INTERNET
        ↓
WEB
        ↓
VIRTUALIZAÇÃO
        ↓
CLOUD
        ↓
SAAS
        ↓
LOW-CODE
        ↓
GENERATIVE AI
        ↓
AI AGENTS

A cada camada, a tecnologia fica mais acessível.

E surge novamente a pergunta:

Quem governa?

---

☕ EPÍLOGO — LLOYD FINALMENTE ENTENDEU O VERDADEIRO FEITIÇO

Depois de examinar computadores, discos, aplicativos, números de série, backups, documentação e cadastros, Lloyd chegou a uma conclusão.

A auditoria de microinformática nunca foi realmente sobre contar computadores.

Também não era sobre procurar arquivos pessoais no Winchester.

Nem sobre descobrir quem havia instalado três processadores de texto diferentes.

Era sobre uma coisa muito maior:

descobrir se a empresa continuava conhecendo e controlando a tecnologia da qual havia passado a depender.

Nos tempos do mainframe, boa parte desse universo estava centralizada.

O PC distribuiu poder computacional.

A rede conectou esse poder.

A Internet expandiu as fronteiras.

Cloud distribuiu infraestrutura.

SaaS distribuiu aplicações.

Low-code distribuiu desenvolvimento.

IA distribuiu capacidade cognitiva.

Agentes começam a distribuir capacidade de ação.

E toda vez que distribuímos poder tecnológico, precisamos redistribuir também:

RESPONSABILIDADE
CONTROLE
CONHECIMENTO
SEGURANÇA
OBSERVABILIDADE

Caso contrário teremos sistemas funcionando perfeitamente...

...que ninguém sabe que existem.

Lloyd fechou o velho computador.

— Então encontramos o demônio?

O auditor balançou a cabeça.

— Não exatamente.

— Encontramos uma aplicação crítica sem documentação?

— Sim.

— Sem responsável?

— Sim.

— Sem backup testado?

— Sim.

— Fora do inventário?

— Sim.

— E ninguém sabe quem criou?

— Exatamente.

Lloyd sorriu.

— Excelente! Quero ver o código!

O auditor começou a suar.

Na tela apareceu:

C:\SISTEMA> DIR

CLIENTES.DBF
FATURA.DBF
CALCULA.EXE
README.TXT

Lloyd abriu o README.

Havia apenas uma frase:

“NÃO APAGAR. É IMPORTANTE.”

Nenhuma assinatura.

Nenhuma documentação.

Nenhum responsável.

Nenhuma explicação.

Lloyd ficou maravilhado.

O auditor pediu café.

E em algum lugar do castelo, provavelmente às 03:17, um velho batch COBOL terminou com:

CC 0000

sem jamais imaginar que, décadas depois, continuávamos tentando resolver exatamente o mesmo problema.

Porque computadores mudam.

Linguagens mudam.

Storage muda.

Redes mudam.

Cloud muda.

IA muda.

Mas existe uma constante assustadoramente retrocompatível:

Toda tecnologia que começa como experiência pode acabar virando infraestrutura crítica antes que alguém perceba.

E talvez essa seja a verdadeira magia que Lloyd de Saloum precisava aprender.

Não a magia de criar sistemas.

Mas a magia muito mais difícil de saber quais sistemas existem, por que existem, quem responde por eles e o que acontecerá quando alguma coisa der errado.

☕ Bem-vindo ao Bellacosa Mainframe.

Onde até um PC esquecido debaixo de uma mesa pode esconder uma dungeon inteira de governança corporativa.