Grandes modelos de linguagem, como o Claude, funcionam gerando uma palavra de cada vez. A cada nova palavra, o modelo escolhe entre uma lista de candidatas possíveis, selecionando no fim a mais coerente ou provável com base no texto anterior. Pegue a frase “O tempo hoje estava frio e…”. É muito improvável que a próxima palavra seja “açucarado”. Mas é bem provável que seja “nublado” ou “cinzento”. Na maioria dos casos, não faz muita diferença para o leitor qual dessas duas últimas palavras o modelo escolhe — o sentido da frase permanece praticamente o mesmo de qualquer forma. Em situações assim, a escolha é decidida por um número aleatório.

A marca d’água usa justamente essas escolhas de baixo impacto — que se repetem muitas vezes ao longo de um texto gerado — para deixar um padrão nas respostas do Claude. Esse padrão é imperceptível para quem lê, mas identificável por qualquer um que tenha uma chave capaz de decodificá-lo. Quando a marca d’água é usada, as escolhas continuam sendo feitas de forma aleatória, mas a origem dessa aleatoriedade muda. Em vez de recorrer a um gerador de números aleatórios qualquer para escolher a próxima palavra, o sistema usa a chave e as palavras anteriores para definir qual palavra o modelo deve escolher. Ou seja, as palavras que o Claude escolhe continuam sendo aleatórias, mas agora é possível verificar a sequência de palavras e checar se ela é compatível com as escolhas que o Claude faria caso estivesse usando aquela chave. Se for, dá para calcular a probabilidade de que o texto tenha sido gerado pelo Claude.

A solução é a mesma que o Google criou e usa desde 2024 no Gemini, chamada SynthID-Text.

Tem gente arrancando os cabelos por causa dessa mudança. Como digo há algum tempo, para mim tanto faz.

Além disso, é provável que apareçam (se já não existirem) sistemas simples que substituam algumas palavras por sinônimos, o que (em tese? Alguém me corrija se for o caso) quebraria a assinatura digital do SynthID-Text. Ainda no campo das suposições, imagino que jogar o texto em outro LLM e pedir para substituir algumas palavras e estruturas já surta efeito.

Independentemente de qualquer coisa, está na hora de quem usa IA generativa para criar texto assumir os seus BOs, né?

Acho que a primeira coisa que ocorre às pessoas quando esse assunto vem à tona é o uso da marca d’água para apontar dedos e humilhar quem os usa. É possível imaginar, porém, outros usos, como auxiliar na triagem de solicitações a órgãos públicos, que, como Ronaldo Lemos apontou em sua coluna na Folha de S.Paulo deste domingo (16), já está afogando governos e a Justiça de vários países.

• Qual a maneira de ver a previsão do tempo que consome menos memória do computador?
• Outra semana no Linux.
• ✨ Os novos planos da assinatura do Manual ✨
• Treinamento de IA da Amazon na Twitch: “Se fosse opt-in, ninguém aceitaria”.

Minhas participações no Órbita:

• O app que você usa e está ameaçando o WhatsApp! E sem internet ainda! Você trocaria?
• O que você está vendo, ouvindo, lendo, jogando, curtindo, assistindo…?

Se preferir, acompanhe o Manual pela newsletter, redes sociais e/ou notificações no celular.

O quase-fim do Mico é parte do processo de unificação/centralização dos incontáveis aplicativos e serviços Copilot.

Adicionamos uma configuração que permite que você opte por não ter o conteúdo do seu canal usado para treinar modelos de IA generativa da Amazon.

Mike Minton, Chief Product Officer da Twitch, foi ao programa oficial Patch Notes da Twitch mais tarde naquele dia. Aqui temos Mike entregando o ouro:

Existe uma resposta honesta, e acho que a maioria de vocês provavelmente consegue entender isso. Se fosse opt-in, ninguém ia aderir. Essa é a verdade.

O treinamento inclui todos os seus comentários no chat e os jogos que os streamers estão transmitindo.

Só os streamers podem desligar essa opção. Vá em Configurações, Segurança e Privacidade, e desative Treinamento para IA Generativa. Há relatos de que a opção fica se ativando sozinha repetidamente.

Minton admitiu em 2024 que a Amazon já estava treinando com streams da Twitch:

Sim, com certeza. Digo, obviamente dentro dos limites da confiança do usuário e das leis de privacidade, que variam em todo o mundo, mas claro que a gente tem um papel nisso.

“Um papel”, né.

No fórum de melhorias para criadores da Twitch, alguém sugeriu em maio: “Tornem todas as funcionalidades de IA opcionais e com opção desativada por padrão.” É a sugestão número um, com mais de 15 mil votos. A segunda tem cerca de 1.700.

Tudo isso é claramente ilegal na Europa sob o GDPR. Então já podem começar a enviar aqueles pedidos de direito dos titulares de dados.

Publicado originalmente no Pivot to AI em 13/8/2026.

As coisas mudam a partir de hoje, com três novos planos, totalizando quatro. É só escolher um e mandar um Pix no valor correspondente para a chave pix@manualdousuario.net:

• Continue, Manual: R$ 99/ano.
• Gosto muito de você, Manual: R$ 150/ano.
• Manual é bom demais: R$ 200/ano.
• Eu amo o Manual: R$ 390/ano.

Na mensagem do Pix, informe o seu e-mail para estabelecermos contato, por favor.

Os benefícios da assinatura não mudam de acordo com o plano, mas fazem muita diferença do lado de cá. Os novos planos são sugestões de valores para facilitar a sua vida, caso você possa e queira contribuir com mais.

(Para deixar claro: continua valendo a regra de sempre, ou seja, o envio de pelo menos R$ 99/ano já ativa a assinatura.)

A grana das assinaturas é a principal receita do Manual do Usuário. Além de permitir que eu continue escrevendo aqui tendo um teto e comida no prato, elas bancam tudo que fazemos: PC do Manual, Órbita, pagamentos ao Renan e outros colaboradores eventuais, entre outras coisas.

Ao tornar-se assinante, você recebe:

• Acesso à nossa comunidade no WhatsApp. O pessoal é bem legal, respeitoso e sempre rolam conversas engraçadas e/ou cabeçudas (no bom sentido). Ainda temos uns grupos inusitados, como o de figurinhas e de fotos de bichinhos de estimação;
• Acesso vitalício a alguns serviços do PC do Manual: Linkding, Miniflux e Readeck&nbsp e
• Acesso ao clube de descontos.

***

Também dá para assinar com periodicidade mensal, pagando no cartão de crédito ou Apple/Google Pay:

• Continue, Manual: R$ 9/mês.
• Gosto muito de você, Manual: R$ 16/mês.
• Manual é bom demais: R$ 36/mês.
• Eu amo o Manual: R$ 49/mês.

***

Se a grana estiver curta, dá para ajudar também espalhando a palavra do Manual para mais gente. Você deve ter ouvido por aí que o Google está tão chapado de IA que parou de mandar leitores aos sites, né? Aqui também está acontecendo. O boca a boca, que sempre foi importante, ficou ainda mais.

Deve ter muita gente que curtiria o Manual e não o conhece. Traga essa galera para a conversa!

O único contra é que a distribuição é desigual. Já disponível nos Pixel 6 e posteriores, “em breve” para Galaxy Z Fold 8 Ultra, Fold 8 e Flip 8, mais celulares (quais?) até o fim do ano.

A interface de usuário do Gnome Shell teve apenas refinamentos pontuais e melhorias de usabilidade na maioria dos últimos ciclos, mas, do lado do design, exploramos diversas ideias de longo prazo que gostaríamos de colocar em prática. Para algumas delas já temos planos relativamente bem definidos; outras ainda são ideias vagas, que exigem mais pesquisa e prototipagem. Como sempre, colocar esse tipo de coisa em prática depende da disponibilidade e do interesse dos desenvolvedores (e, às vezes, de financiamento).

Gosto das ideias. Nenhuma delas representa uma grande ruptura com a interface atual; várias alinham o Gnome à experiência esperada e comum em outros ambientes desktop e sistemas operacionais.

A mais avançada, que deve aparecer na próxima versão (Gnome 51), é a camada sobreposta à tela com os resultados da pesquisa (imagem), em vez desses aparecerem numa tela própria/inteira. A mudança se justifica à luz da filosofia adotada no Gnome 40: “Quando você navega pelo Gnome Shell, os elementos da interface sempre vêm de algum lugar e saem para outro lugar, de uma forma que é semântica e previsível ao longo do tempo.”

No final de julho, a minha febre de software livre atingiu temperaturas perigosas. Vi-me, mais uma vez, instalando uma distribuição Linux com o intuito de me livrar do macOS, o primeiro passo para sair do jardim murado que é o ecossistema da Apple; achava estar à porta de uma utopia digital, mais ou menos como aquele sonho do homem moderno de largar tudo e viver no mato, do que a natureza dá.

Adianto que, tal qual das outras duas vezes, o sistema do pinguim não durou muito. Alguns dias, para ser exato. Apesar do fim precoce, foi bom enquanto durou e a experiência deixou ensinamentos valiosos.

***

Meu notebook, um MacBook Air com chip M1, da própria Apple, é muito bom, mas peculiar. Ao contrário dos da AMD e Intel, esse chip não é amigável a sistemas operacionais de terceiros. Só é possível instalar outro graças à dedicação de uma galera insana que desvendou o código fechado do chip da Apple com engenharia reversa — o projeto Asahi. Fato é que funciona, com ressalvas.

A distribuição de referência do Asahi Linux é o Fedora. Há alguns meses, descobri que uma equipe do Debian, batizada Debian Bananas Team, adaptou os pacotes do Asahi para o projeto. Fui de Debian Testing com o ambiente gráfico Plasma 6.6, do KDE.

A instalação é diferente da de computadores convencionais, de outras marcas, com chips AMD ou Intel. Em vez de preparar um pen drive, é preciso rodar um script dentro do macOS. Ele faz alguma mágica para tornar o computador apto ao Linux, redimensionar a memória de armazenamento e, por fim, instalar o sistema alternativo e defini-lo como padrão.

É um pouco intimidador, em especial a parte em que o script pede para reiniciar a máquina segurando o botão de ligar para entrar no seletor do sistema operacional. Aparentemente acontece algo ruim se esse passo não for executado à perfeição. De resto, o script é muito bem escrito e senti segurança durante o processo. Correu tudo bem e, no fim, a tela de login do Debian/Plasma se revelou a mim em toda a sua glória.

***

Você se lembra daquele papo da Apple de que seus computadores com 8 GB de RAM (memória temporária) equivaliam a 16 GB de outros computadores? Detesto ser o mensageiro de más notícias, mas parece que é verdade.

Em mais de quatro anos usando este notebook no macOS, com seus parcos 8 GB de RAM, não me recordo de um aplicativo ter travado por falta de memória, mesmo em sessões exigentes, com mil aplicativos abertos ou editando vídeos.

Já nos poucos dias em que estive a bordo do Debian, a situação era recorrente, acontecia algumas vezes por dia, muito acima do ideal, que é zero.

Era abrir do LibreWolf (navegador, um derivado do Firefox) e o Thunderbird (e-mail e agenda) ao mesmo tempo que um dos dois travava. Justiça seja feita, ambos são devoradores de RAM em qualquer sistema operacional. Quando os usei no macOS, porém, nunca travaram.

Dado que memória está custando dois rins no momento (obrigado, IA), é imprescindível fazer mais com menos, e o macOS faz coisas impossíveis com o que tenho aqui.

Comentei esse episódio com o pessoal no grupo do Manual e soube que era necessário aumentar a partição swap (de troca). Acho que conseguiria fazer isso, apesar do receio de transformar o notebook em um peso de papel. Revendo os prints que tirei para ilustrar este relato, percebi em um deles que o sistema estava sem swap. Limitação do Linux em chips Apple? Algum equívoco no script de instalação (não me lembro disso nele)? Burrice do BIOS (bicho ignorante operando o sistema, euzinha)? Sei lá, só sei que isso explica muita coisa. Lição aprendida e peço desculpas pelo erro crasso no experimento.

De qualquer modo, o sufoco com os 8 GB de RAM foi a gota d’água, mas não o único motivo que me fez regressar ao macOS. Outros golpes duros que me desnortearam: o sensor de digitais que não funciona e — o pior — a incompatibilidade com o monitor externo, ligado por uma dock USB-C/Thunderbolt.

Eu uso o teclado e o trackpad do notebook e, vez ou outra, a tela dele também. À minha mesa, substituo a tela embutida pelo monitor externo, mais espaçoso e na altura dos olhos. Não estou mais na idade de abdicar da boa postura; as consequências são quase imediatas e dolorosas. Acreditei nos primeiros dias, ainda inebriado por estar vivendo o ~sonho do Linux próprio, que poderia levar uma vida na telinha do notebook, com o pescoço dobrado. Mudei de ideia dois dias e um torcicolo depois.

***

O sistema em si, o Debian Testing, funciona bem. LibreWolf e Thunderbird têm seus problemas (de interface, de padronização; principalmente o Thunderbird), mas dão conta do recado. Outros aplicativos que uso no dia a dia, como editor de texto simples (KWrite), gerenciador de senhas (KeePassXC) e visualizador de imagens para edições básicas (Gwenview), achei ótimos. Já os conhecia de outros carnavais e continuam tão bons quanto me lembrava. Tudo que uso em linha de comando no terminal do macOS está disponível no Linux.

Ao contrário da última tentativa, não fiz a insanidade de começar com o Debian “pelado” (instalação mínima) e ir instalando os pacotes um a um. Fui com o pacote padrão que, não sei se isso vale para tudo ou é algo do Debian para computadores da Apple, veio bem enxuto, com poucos aplicativos pré-instalados.

Mesmo a arquitetura diferente (arm64), incompatível com aplicativos compilados para a dominante (amd64), não chegou a ser problema. O único contratempo que notei foi com o Thunderbird, que não tinha a versão normal disponível para arm64 nos repositórios do Debian nem no Flathub, um popular repositório de aplicativos em um formato agnóstico, que funciona em qualquer distribuição Linux. Tive que me contentar com a ESR, de suporte estendido, que só recebe novidades uma vez por ano.

O poder do notebook fez uma diferença notável em comparação à tentativa anterior de usar Linux no dia a dia, conduzida em um computadorzinho fraco que, depois, virou meu servidor doméstico. (Ironicamente, rodando um Debian 12 “headless” e dando conta do recado com folga.) A rolagem das janelas, por exemplo, que no computador fraco era irregular, funcionou suave. O trackpad da Apple, tido como o melhor da indústria, também funciona bem, embora alguns comportamentos sejam melhores no macOS. O clique sem apertá-lo nem sempre funciona no Plasma; se você fizer um “micro-movimento” e mover o mouse durante a execução do clique, o sistema reconhece o movimento e o clique falha. O macOS prevê e corrige esse equívoco. Parece bobagem, mas acontece muito e a somatória de ocorrências que frustra.

O KDE Connect supriu parte dos recursos de Continuidade que a famosa integração entre os dispositivos Apple entrega. Com o iPhone, ele é bastante limitado e só funciona com o aplicativo aberto no celular. É recomendável usá-lo com um celular Android, o que seria demais para mim. (Não o Android, mas mudar dois sistemas ao mesmo tempo.)

Um recurso do Dolphin (gerenciador de arquivos) muito maneiro é abrir o terminal no diretório exibido no rodapé da janela. Basta apertar a tecla F4. Quando voltei ao macOS, procurei por algo similar. Existe um atalho no teclado configurável que faz quase isso: ele abre uma janela do terminal no diretório/pasta que está selecionado no Finder, não no que está aberto. É diferente o bastante para ser meio inútil. Talvez exista um atalho ou Apple Script para fazer do jeito do Dolphin.

Uma velha contenda que tenho com outros sistemas que não o macOS manifestou-se outra vez: os atalhos no teclado. A experiência adquirida na semana anterior a bordo do Linux me salvou de uma agonia desmedida, a de não conseguir digitar reticências (…) nem travessões (—). Bastou ativar a tecla de Composição. Pena que ainda não consigo fazer as aspas bonitinhas com ela. Não sei se sou eu ou o KDE Plasma.

Gastei um bom tempo no editor de atalhos das configurações do Plasma, adequando-os às minhas manias, tentando não alterar muitos deles. Estava disposto a aprender — ou a familiarizar-me com — o “jeito Linux” de usar computadores. E com bastante paciência, o que acho que faltou nas outras tentativas.

Era esperado (e de fato foi) que eu ficasse mais lento para fazer as coisas que faço na minha rotina. Fui do jeito lento mesmo, dando voltas enormes que no macOS, para mim, faço sem pensar, esperançoso de que o tempo e a prática me dariam a desenvoltura que exibo no macOS. Não deu tempo, mas tudo bem.

***

Antes de me sentar para escrever este relato, reli os dois anteriores e me surpreendi ao notar que concluí ambos com mensagens similares. Em dezembro de 2012 (!), após uma semana no Ubuntu 12.10, escrevi:

Daria para viver com o Ubuntu? Sim. Muita gente consegue, aliás, embora a maioria dos que entrevistei trabalhe com informática e, portanto, talvez não se enquadre no perfil do “usuário leigo”, o escopo desse experimento — com exceção da parte do XAMPP, todas as demais atividades que fiz foram bem… convencionais. Há dificuldades, algumas ainda casca grossa que te levarão a pesquisas tediosas no Google e comandos ininteligíveis no terminal, mas a situação já é bem melhor que algum tempo atrás.

E na mais recente, em janeiro de 2024 com o Debian 12:

Sim, daria para usar Linux no computador como único sistema operacional sem (muito) perrengue. Algumas tarefas são mais intuitivas e/ou funcionam melhor aqui, outras não, mas boa parte dos desconfortos e estranhezas desta semana decorreram do computador fraco que usei ou da minha falta de familiaridade com o sistema.

Sim, daria para viver com Linux no computador. Para mim, porém, essa vida continua sendo uma utopia, um desejo irracional pautado na emoção, porque para o meu perfil de uso, nível de conhecimento e familiaridade, o macOS é mais negócio — com ou sem Liquid Glass, uma mudança que causou um desgosto enorme por aqui.

O futuro segue sendo uma incógnita. Ou não.

***

Para abrir espaço ao Debian, tive que formatar o macOS e deixá-lo com o mínimo de espaço recomendado pelo Bananas Team. Preparei-me bastante, num nível quase paranoico, a fim de preservar meus arquivos e configurações. Correu tudo bem. Esta talvez tenha sido a maior lição que levo comigo: a de que, na prática, é fácil pisar fora do jardim murado da Apple, que existe uma porta de saída, mesmo que lá fora não seja tão agradável.

Ao analisar o processo, o magistrado ressaltou que o suporte técnico do WhatsApp informou que os metadados de “modificação” e “último acesso” não provam que o usuário visualizou o arquivo.

Apesar do precedente (correto, na minha humilde opinião), é boa prática de higiene digital sair de grupos do WhatsApp muito ativos que você não acompanha e/ou (no mínimo) desativar o download automático de mídias.

Mais que com o aplicativo do Windows, surpreendi-me em saber que o Tempo.app do macOS gasta ~230 MB e que isso é considerado pouco. (Uso-o bastante e nunca me ocorreu verificar esse dado.) Em distribuições Linux, o cenário não é muito melhor.

Há indícios da justificativa desse tanto de memória: as animações bonitinhas do clima no fundo do aplicativo do macOS, os locais extras na barra lateral e os múltiplos dados para além da previsão da temperatura (precipitação, índice UV, qualidade do ar), tudo exibido em um leiaute agradável.

O do Windows 11 é mais inchado por ser, na realidade, um site empacotado e sites empacotados costumam ser mais pesados mesmo. Também pela presença de anúncios e, imagino, todo o aparato de rastreamento e vigilância que costuma estar atrelado à publicado digital.

Peguei-me pensando: qual a maneira mais eficiente, do ponto de vista computacional, de saber a previsão do tempo?

Minha primeira ideia foi recorrer aos buscadores web. Todos, como Google, Bing e DuckDuckGo, exibem a previsão se você pesquisar por “previsão do tempo”. Testei com esses três:

• DuckDuckGo: ~190 MB.
• Google: 323 MB.
• Bing: 311 MB.

O DDG é o mais eficiente, mas apenas o Bing entrega resultados detalhados equivalentes ao dos aplicativos nativos.

Um detalhe relevante é que o meu navegador tem extensões de bloqueio de anúncios e rastreadores, o que diminui a necessidade de memória. Ainda assim o consumo é alto, e poderia ser maior porque analisei apenas o processo da aba, e não o do navegador em si (Safari, no exemplo), que no aplicativo do Windows 11 entra na conta.

Lembrei-me, então, de um serviço que devolve a previsão do tempo pelo terminal, o wttr.in. O único requisito é ter o curl instalado no sistema. Aí, basta digitar isto:

curl wttr.in/Curitiba

Se tirar a cidade, a requisição tenta adivinhar a sua localização pelo endereço IP. O terminal do macOS, ao ser aberto consome ~60 MB de RAM e permanece assim após um pequeno pico que adiciona 10 MB durante a consulta ao wttr.in. Dos dados que o wttr.in devolve, só senti falta da umidade relativa do ar:

(Dá para recuperar a umidade do ar com um parâmetro na URL de consulta, assim: curl "wttr.in/?format=%h". Seria legal se fizesse parte da saída padrão, porém.)

Isso importa? Idealmente, não. Memória existe para ser usada, afinal. O caso do Windows 11 é um ponto fora da curva e, com sorte, algo que a Microsoft em algum momento resolverá, se as promessas feitas em março, de que o Windows ficará mais leve e com menos anúncios, se cumprirem.

Dito tudo isso, esta breve investigação foi realizada apenas para fins de entretenimento.