O motivo de o SPARC4 do professor estar lento era o xroach lotando embaixo do xterm

• Um responsável pelo suporte de TI do departamento de Ciência da Computação foi ao escritório após a reclamação do professor sobre a queda de desempenho do Sparc4 e encontrou um xroach escondido atrás da janela
• Ao minimizar uma janela, a parte de baixo da tela parecia um retângulo preto, e dentro dele as baratas se moviam muito lentamente
• O movimento estava em cerca de 0,5 fps, e havia tantas baratas do xroach embaixo do xterm que tudo parecia uma única massa preta
• O ponto central do problema não era tanto o hardware em si, mas o fato de que o xroach continuava sendo exibido em um lugar que o usuário não via
• Em ambientes antigos de desktop X11, até programas de brincadeira podem parecer problemas reais de desempenho, então é importante verificar janelas ocultas e estados em segundo plano

---

Sintomas observados no escritório do professor

• Paco Hope, quando trabalhava como responsável pelo suporte de TI do departamento de Ciência da Computação, foi chamado ao escritório porque o professor reclamou que o Sparc4 estava lento
• A primeira coisa que ele fez foi minimizar uma janela, e embaixo apareceu um inesperado retângulo preto
  • Dentro da área preta, as baratas do xroach se moviam aos poucos
  • O movimento era tão lento que parecia estar em cerca de 0,5 fps

xroach acumulado embaixo do xterm

• Havia tanto xroach espalhado embaixo do xterm que, em vez de baratas individuais, parecia quase um retângulo preto de cor sólida
• Até minimizar a janela, o professor não conseguia ver o que havia embaixo dela, e a reclamação de lentidão começou a fazer sentido ao verificar esse estado oculto da tela

Breve lembrança e reação

• Essa história é uma breve lembrança publicada por Paco Hope no Mastodon em 25 de julho de 2023
• A postagem mostrava 202 boosts e 389 favorites, recebendo empatia de usuários que se lembram de ambientes antigos de desktop e programas de brincadeira

[GN⁺]

Opiniões do Hacker News

• Quando eu trabalhava no suporte técnico de um hospital local, uma enfermeira ligou dizendo que havia na tela “uma janela que parecia previsão do tempo” e que o mouse entrava por baixo dela, então ela não conseguia fechá-la
  Fiquei curioso, pedi que não mexesse no computador e, depois de uns 10 minutos até chegar lá, ela disse: “fechou sozinha um minuto atrás. Ficou aberta por 30 minutos”
  Pela disposição da mesa e pela descrição da janela, apertei o botão do monitor, e apareceu o menu OSD do monitor, acionado por engano pela quina do teclado, mostrando o brilho em 100% com um ícone de sol. Era claro que o mouse passava por baixo dele
  Caminhei mais 10 minutos de volta e fiquei esperando a próxima ligação

  • Depois de trabalhar com suporte técnico em hospital, não tenho certeza se, naquele ambiente, TI agrega tanto valor quanto imagina
    Enfermeiros estão ocupados salvando vidas e cuidando de pessoas no pior dia delas, e ainda precisam lidar com estações de trabalho mal implementadas e mal mantidas. Quando pedem ajuda, às vezes aparecem as mesmas pessoas que criaram o problema e ainda as tratam com superioridade
    Enfermeiros não são burros nem preguiçosos; são pessoas que têm coisas mais importantes a fazer do que gastar tempo com probleminhas de TI
    Os equipamentos importantes para o atendimento de fato geralmente eram gerenciados por especialistas dedicados, e o computador do aparelho de MRI podia nem estar vinculado ao Active Directory nem estar na rede. O problema era repassado para a GE, não para quem conserta impressoras
  • Uma vez recebi um chamado de suporte técnico dizendo “a tela fica toda distorcida, acho que pegou vírus”. Era a época em que o filme The Net ainda estava nos cinemas
    Quando cheguei, havia um boombox com dois alto-falantes grandes em cima do monitor CRT; ao tirá-lo de lá, o problema se resolveu como mágica
  • Parece uma versão mais avançada da história dos anos 90 do “porta-copos 4x que quebrou”
    Na verdade, a enfermeira até descreveu o que estava acontecendo com bastante precisão

• Em 1989, fui o único responsável pelo departamento de TI em um lugar onde ex-economistas acadêmicos faziam modelagem econométrica em um Digital VAX 11/750
  Esse minicomputador rodava o VMS, um sistema operacional multiusuário, e todos os usuários tinham privilégios de administrador. Cada um achava que, se elevasse ao máximo a prioridade de seus processos, o modelo rodaria mais rápido, mas isso atrapalhava os processos em tempo real necessários para a operação do computador e produzia o efeito oposto
  Depois que encontrei a causa, retirei os privilégios e reiniciei o sistema, tudo voltou ao normal, e ainda me agradeceram por deixar o sistema mais rápido

  • Havia um sistema administrado por alunos, e eu era um deles. Costumávamos pregar peças uns nos outros; em uma workstation DEC com pouca memória, um deles estava rodando emacs
    Outra pessoa criou um programa que fazia fork de si mesmo 1000 vezes, baixava o valor de nice para 19, então executava sleep(0) e encerrava. Se recebesse qualquer tempinho de CPU, terminava imediatamente, mas enquanto o emacs estivesse rodando ele não conseguia essa chance. Enquanto isso, a carga mostrada pelo xload virava um quadrado completamente preto
    A pessoa que usava emacs executou como root ps -ef | grep procname | xargs kill, mas para processar o kill era preciso tempo de CPU, o que levava mais tempo que sleep(0), então não teve muito efeito
    Na segunda pegadinha, o nome do processo foi definido como ema, e com isso todas as instâncias do emacs também foram mortas
    Na terceira, o nome do processo foi et, mas por acaso ele também bateu com /etc/initd, e a máquina reiniciou de repente
  • Em 1993, a disciplina introdutória de ciência da computação para calouros era dada em Scheme, e os trabalhos tinham que ser desenvolvidos e testados em uma máquina Digital compartilhada rodando Ultrix
    O interpretador Scheme demorava para iniciar, especialmente quando mais de 20 pessoas estavam logadas. O monitor ensinou a suspender o interpretador com ctrl-z, editar com vi e depois voltar com fg
    O problema é que não foi metade, mas 2/3 da turma que esquecia o fg e, depois de editar, abria mais uma instância de Scheme. Lembro que, na noite de entrega do trabalho, no laboratório de terminais, o sistema simplesmente se arrastava
    Depois aprendi a procurar colegas com duas ou mais instâncias de Scheme rodando e lembrá-los do fg; e as “soluções” do problema das 8 rainhas com recursão infinita também não ajudavam em nada na carga. A verdadeira lição foi, mais tarde, não fazer login na noite de entrega dos trabalhos de CS 401
  • Em 1991, usei a internet pela primeira vez na universidade por meio desse tipo de equipamento. Encontrei uma vulnerabilidade legal que permitia transmitir mensagens anonimamente para qualquer pessoa, e assustei muita gente
    Como os terminais compartilhados ficavam todos na mesma sala, era divertido ver em tempo real o efeito do que eu fazia
  • Um bom exemplo do princípio econômico da tragédia dos comuns: https://en.m.wikipedia.org/wiki/Tragedy_of_the_commons
  • Isso me lembra uma história que ouvi de alguém com quem trabalhei
    Em um ambiente em que as pessoas faziam fila, alguém perguntou se seu problema poderia ser atendido antes dos outros. Ou seja, pediu para ser colocado no início da fila
    Ele respondeu “claro!”, e, quando a pessoa se surpreendeu, acrescentou: “mas você sabe que vou fazer a mesma coisa por qualquer outra pessoa que fizer o mesmo pedido, certo?”
    No fim, a pessoa decidiu continuar esperando no seu lugar

• Isso me fez lembrar dos tempos dourados de estudante de antigamente
  No meu caso, foi no começo dos anos 2000, e como os computadores dos laboratórios da universidade não eram muito potentes, as pessoas costumavam trabalhar no console Linux, sem abrir uma sessão X pesada
  Por volta de 2001, lendo a página de manual console_ioctl(4), descobri que ela era cheia de possibilidades para pegadinhas. Criei pequenos programas para manipular a fonte do console e virar todos os caracteres de cabeça para baixo, trocar maiúsculas por minúsculas, piscar padrões nos LEDs do teclado ou mudar a paleta para fazer a tela escurecer até ficar preta e depois voltar
  Acrescentei a isso um componente de servidor, deixava rodando em um terminal aparentemente normal, esperava a vítima aparecer e então, de outra máquina na mesma sala, ativava os efeitos remotamente e observava a reação. Felizmente, logo percebi que programar em si era mais divertido do que ver as pessoas entrarem em pânico, e parei com a segunda parte
  Outra pegadinha era digitar manualmente, no prompt de login do getty, algo que parecesse a saída de um login root bem-sucedido. Incluía até o motd, imitava as quebras de linha com tabs e espaços, sem jamais apertar RET, e terminava com [root@mailhost root]#
  Algumas pessoas, por curiosidade, digitavam whoami e ficavam confusas ao ver aparecer um prompt de senha; outras recuavam assustadas, sem tocar em nada, e mandavam e-mail para o administrador do sistema de outro terminal

  • Eu bem que gostaria que tivéssemos tido sistemas Linux. Fizemos coisas parecidas em uma rede Windows
    Desde que o usuário estivesse logado, dava para executar praticamente qualquer programa com os privilégios dele usando o Agendador de Tarefas e, combinado com o Active Directory, também era possível obter informações do usuário. Sabíamos quem estava onde e abríamos o iexplorer em um site específico, ou exibíamos um documento Word inofensivo, coisas assim. O caso mais malicioso foi um script em lote de logout automático
    Depois, as pessoas descobriram como era feito e tentaram imitar a execução remota, mas acabavam executando com os próprios privilégios, não com os do usuário alvo, então, quando o administrador de TI aparecia, ficava muito óbvio quem tinha executado
    Eu parei com as pegadinhas e, no fim, passei por TI e virei engenheiro de software de profissão. Às vezes me pergunto o que teria acontecido se eu tivesse levado uma punição disciplinar naquela época
  • Parece realmente divertido. É um jeito de perceber que programar é muito divertido e impactante quando você participa diretamente do resultado

• Havia mais de 80 programadores em um mainframe IBM 370, e o VM/370 criava uma máquina virtual para cada programador. Eu era um dos dois programadores de sistema com privilégios de “superusuário”
  Dentro da máquina virtual, normalmente rodávamos CMS, mas também dava para executar outras coisas, e algumas máquinas rodavam MVS
  Para enviar um comando à própria máquina virtual, colocava-se antes do comando um caractere especial cujo padrão era #. Por exemplo, #cp ... era um comando enviado à máquina virtual, e esse prefixo mágico podia ser alterado para qualquer caractere desejado
  Um dia, entediado, fiquei curioso para saber se seria possível rodar VM de novo dentro de uma máquina virtual. Inicializei VM no “segundo nível”, mudei o caractere de prefixo para ! e, dentro dela, consegui criar novas máquinas virtuais
  De novo, inicializei VM em uma máquina virtual de “terceiro nível” e mudei o prefixo para @. No fim, cheguei a 8 níveis de aninhamento e confirmei que VM podia rodar VM, que por sua vez podia rodar VM, e assim por diante
  Na hora de encerrar e sair dos níveis aninhados, digitei por hábito #cp shutdown, mas isso desligou o VM real da máquina real. Em pânico, corri para a sala de máquinas e apertei o botão de iniciar no console
  É claro que ficou registro no log do sistema, e o outro programador de sistema veio até minha sala e disse: “não faça isso de novo”. Eram tempos divertidos

  • Criei isto para abusar de execução aninhada do qemu da mesma forma: http://git.annexia.org/?p=supernested.git;a=summary
  • Não entendi. Eu achava que # era o prefixo da VM de nível 1, não do sistema operacional de nível 0, ou seja, do host
    Se # enviava comandos ao nível 0, fico curioso para saber qual era o prefixo do nível 1
  • Parece com a gente trabalhando no Solaris estando acostumados ao Linux. Um processo travou e, com preguiça de procurar o PID, simplesmente chamamos killall procname. A máquina morreu imediatamente
    Só quando o administrador do sistema apareceu aprendemos que, no Solaris, killall faz outra coisa, e nos disseram para nunca mais usá-lo

• Nos anos 80, quando eu era estudante na universidade, tive acesso a um VAX 11/750 — mais exatamente, um clone Systime 8750 — para fazer trabalhos de programação.
  Os terminais dos alunos ficavam em metade de uma sala grande, e a outra metade era usada pela equipe de TI da universidade. Quando não havia terminais livres do lado dos administradores de TI, um ou dois funcionários às vezes usavam os terminais dos alunos logo do outro lado das divisórias.
  Um dia, esperando um projeto em COBOL compilar, fiquei entediado demais e comecei a me perguntar se conseguiria capturar o nome de usuário e a senha do administrador do sistema. Escrevi um script que imitava perfeitamente o prompt de login na CLI, incluindo o bipe e a mensagem.
  O script limpava a tela e esperava a entrada do nome de usuário e da senha; quando eles eram digitados, enviava tudo para mim por e-mail, mostrava um erro de nome de usuário/senha e então fazia logout, passando para o processo de login real.
  Depois de testar em alguns colegas que não perceberam nada e fazer algumas brincadeiras anônimas, decidi tentar de verdade com os administradores do sistema. Fiz login nos dois terminais que a equipe de TI costumava usar e deixei o script rodando; quando voltei algumas horas depois, para minha surpresa e com certa apreensão, eu tinha obtido a senha de login SYSTEM.
  Durante mais ou menos um mês tive controle total daquela máquina e, sempre que a senha do SYSTEM mudava, às vezes rodava o script de novo. Não contei a ninguém e, no último dia antes de me formar, fiz login por precaução e apaguei o script. Na época, as leis contra acesso não autorizado a computadores estavam ficando mais rígidas no Reino Unido.
  Passei muito tempo com os enormes manuais daquela máquina, explorando e aprendendo VMS, mas ninguém percebeu.

  • Foi por causa desse tipo de spoofing de login que, a partir do Windows NT, o usuário precisava primeiro pressionar Ctrl+Alt+Del para entrar em um contexto seguro.
    https://en.wikipedia.org/wiki/Control-Alt-Delete
  • Isso também parece uma espécie de rito de passagem. Fiz a mesma coisa no VAX da escola, mas no dia seguinte entreguei ao administrador do sistema todas as senhas que tinha coletado e confessei tudo. Havia até algumas contas com privilégios de SYSTEM.
    Eles me deram meu primeiro emprego :-) Também deixei previamente uma ou duas contas pouco conhecidas com as permissões necessárias, para que eu pudesse recuperar os privilégios de SYSTEM caso eles fossem removidos da conta “oficial”.
    Eram tempos divertidos, e ingênuos também. Não usei os privilégios para causar caos.
  • Excelente. Lembro que, durante uma prova de álgebra, escrevi um programa em BASIC na Ti-83 para imitar o procedimento de limpeza de memória que o professor executava manualmente enquanto circulava pela sala.
    Hoje não é lá uma grande surpresa eu ganhar a vida programando.
  • Acho curioso como usar um programa substituto de login parece ser algo bastante comum entre futuros hackers.
    O meu era em Visual Basic 5 para o Windows da escola, provavelmente numa rede Novell. Era muito fácil alterar o win.ini para que ele fosse executado antes da tela de login real.
    Ele salvava o nome de usuário e a senha em uma unidade de rede compartilhada ou em um arquivo local, mostrava “erro de senha” e então saía para o prompt de login verdadeiro.
    No fim, o problema surgiu quando um “amigo” usou a mesma técnica para copiar arquivos das contas de rede das pessoas para a própria conta. Imagino que o sistema tenha avisado o administrador da rede quando ele estourou a cota. Uma inspeção superficial revelou que ele tinha copiado até arquivos de dissertação de professores, e isso era um grande tabu.
    Graças a esse incidente, acabei conseguindo meu primeiro emprego relacionado a computadores, como suporte técnico júnior/administrador de rede.
  • Lembro que, por volta de 1985, na CMU, um aluno fez algo assim e se meteu em grande encrenca.

• Em 1988, no ensino médio, um amigo e eu descobrimos uma vulnerabilidade no NetWare implantado em 30 IBM PS/2 Model 30-286 do novo laboratório de informática, que permitia inserir um programa na sequência de boot de rede do autoexec.
  Antes disso, eu tinha mexido nos registradores VGA, que eram novidade na época, e descoberto como alternar do modo texto 80x25 para o modo gráfico 320x200 com 256 cores sem piscadas nem corrupção visual. Isso era possível porque ambos os modos tinham taxa de atualização de 70 Hz.
  Meu amigo criou um TSR que pré-carregava uma imagem digital de um rosto de palhaço em A000:0000 e, depois de cerca de 4 minutos, mostrava o rosto do palhaço por alguns frames antes de voltar imediatamente para a tela em que o usuário estava trabalhando.
  Fomos descobertos porque, do canto da sala, não conseguimos segurar o riso ao ver os alunos com expressões confusas e assustadas. Especialmente quando um aluno chamou o professor e o fez ficar olhando para a tela por mais de 3 minutos; no exato momento em que o professor se virou para ir embora, o rosto do palhaço piscou na tela. O timing foi perfeito.
  O nome do meu amigo era Brian, e ele foi uma das pessoas mais inteligentes que já conheci. Dez anos depois, criamos o mobygames.com.

  • A minha pegadinha era emitir sons de pássaros de vez em quando. Normalmente cantava a cada poucos minutos, e eu misturava vários números aleatórios para soar diferente a cada vez.
    A frequência do som mudava o tempo todo, de modo que não havia uma nota fixa nem por um instante. Na época, os alto-falantes normalmente só faziam bipes, e eu costumava deixar isso ligado em máquinas que não estavam sendo usadas.

• No início dos anos 90, eu era calouro de graduação em Ciência da Computação em uma universidade estadual. O laboratório de informática era cheio de Sun SPARCstation IPC rodando SunOS, e havia um sistema básico de e-mail que o pessoal do departamento usava para se comunicar.
  Quem entendia mais de tecnologia já explorava a Usenet, mas, para a maioria, o e-mail era todo o mundo digital.
  Um dia, meus amigos e eu resolvemos fazer uma brincadeira e nos inspiramos no famoso comando fortune, que imprime aforismos aleatórios. Criamos um script de shell simples que escolhia uma linha aleatória de um arquivo de texto com frases engraçadas e absurdas que tínhamos escrito e a enviava por e-mail para um usuário aleatório do departamento de Ciência da Computação; então registramos isso como uma tarefa cron para mandar uma por hora.
  No começo, era uma brincadeira inofensiva. As pessoas achavam as mensagens divertidas e as compartilhavam no laboratório. A origem das mensagens virou assunto no departamento, mas ninguém sabia de onde vinham, e nós nos divertíamos vendo colegas e professores tentando adivinhar quem era o remetente misterioso.
  Mas a coisa cresceu quando o reitor recebeu uma mensagem especialmente absurda: “Por que cientistas da computação confundem Natal com Halloween? Porque Oct 31 == Dec 25”. Ele não entendeu a piada e achou que fosse uma mensagem cifrada ou uma possível ameaça.
  A equipe de TI do campus foi chamada para investigar, e houve uma confusão de uma semana tentando rastrear a origem dos e-mails. Meus amigos e eu observávamos ansiosos, com medo de sermos descobertos e expulsos.
  No fim, depois de alguns dias sem dormir direito, decidimos nos entregar. Fomos até o reitor e confessamos; depois de um longo silêncio, ele começou a rir. No fim das contas, um dos professores de Ciência da Computação havia explicado a piada a ele, e ele estava esperando para ver quando nós apareceríamos.
  Ele levou a brincadeira numa boa e achou nossa iniciativa criativa, mas nos alertou sobre as consequências não intencionais desse tipo de pegadinha.
  Olhando para trás, foi uma brincadeira divertida e memorável, e nos deu uma lição valiosa sobre ética no uso da tecnologia. É uma história que conto com frequência hoje aos meus alunos de Ciência da Computação quando ensino a importância do comportamento ético no mundo digital.

• Certa vez tive de ver o que havia de errado com o PC do chefe do departamento de Matemática, que estava se comportando de forma estranha.
  Descobri que ele tinha deixado o Prime95 usando todos os ciclos ociosos de um dos núcleos de um Core 2 Duo por 10 anos, e a máquina só inicializava depois de esfriar até a temperatura ambiente.

  • Demorei demais para lembrar que o Prime95 tem utilidade além de teste de estresse.
  • Ciclos não usados são ciclos desperdiçados /s

• Foi uma pegadinha que um amigo fez com outro amigo na pós-graduação.
  Enquanto a vítima tinha deixado o terminal por alguns instantes ainda logada, quem fez a brincadeira adicionou echo sleep -1 >> .login ao arquivo .login.
  Só alguns dias depois, quando já havia mais de 20 instruções sleep anexadas, ficou claro que havia algo excepcionalmente errado no login daquele aluno. A cada dia, o tempo entre o login inicial e chegar a um terminal ativo ficava cada vez mais lento; a vítima foi ficando cada vez mais irritada, e, quando finalmente ficou insuportável, a pegadinha foi descoberta.

  • Vim aqui para relembrar a mesma pegadinha :)
    Depois de um tempo, concluí que adicionar 1 segundo a cada login era sutil demais.
    echo "echo sleep 1 >> ~/.login" >> ~/.login

• É engraçado como muitas dessas histórias antigas acabam se resumindo a “não foi por maldade, era para ser engraçado, mas eu não imaginava que fosse se multiplicar tanto nem consumir tantos recursos”.
  O Morris worm também foi parecido. Dá para discutir, mas pode ser visto como tendo sido projetado como malware; ao menos pelo que se conta, a intenção não era que ficasse tão sério.