Encerramento do serviço Typepad e orientações para transferência de domínios

• Com o encerramento do Typepad, operadores de blogs existentes precisam decidir por conta própria sobre a transferência de domínios e conteúdos enquanto o login e o acesso a arquivos estão bloqueados
• A data de encerramento do serviço é 30 de setembro de 2025; depois disso, o login nas contas não será mais oferecido
• Clientes que pagaram a taxa anual por um período posterior à data de encerramento receberam reembolso proporcional; se o reembolso não aparecer no extrato, é preciso verificar com o banco
• Todos os dados dos blogs serão excluídos, e não haverá extensão de acesso nem caminho de recuperação, exceto para consultas relacionadas a dados pessoais
• Domínios registrados no Typepad Domains serão transferidos para o Reseller Club em 27 de outubro de 2025; para conectar uma nova plataforma, é necessário remover o CNAME existente do Typepad

---

Tratamento de contas e dados após o encerramento do serviço

• A data de encerramento do serviço Typepad é 30 de setembro de 2025
• Após a data de encerramento, os usuários não poderão mais fazer login em suas contas
• Clientes que pagaram a taxa anual do serviço por um período posterior à data de encerramento receberam reembolso proporcional
  • Se o reembolso não aparecer no extrato, é preciso entrar em contato com o banco
  • Se não houver um cartão de crédito válido registrado, o reembolso pode não ter sido processado
• Após o encerramento, o acesso aos arquivos será interrompido, e nenhuma extensão separada será oferecida
• Todos os dados dos blogs serão excluídos, e consultas relacionadas a dados pessoais devem ser enviadas para [e-mail]

Transferência do Typepad Domains e conexão de um novo blog

• O Typepad Domains é um revendedor da LogicBoxes, e todos os domínios registrados no Typepad Domains serão transferidos em 27 de outubro de 2025 para o Reseller Club, outro parceiro da LogicBoxes
• Esses usuários receberão um e-mail com instruções adicionais do Reseller Club
• Não é necessário transferir o domínio da LogicBoxes para outro lugar; ele poderá continuar sendo gerenciado posteriormente pelo Reseller Club
• Para conectar o domínio a um novo serviço ou plataforma de blog, é preciso remover o registro CNAME que aponta para o Typepad e configurá-lo conforme os requisitos do novo serviço
  • Antes de 27 de outubro de 2025, faça login no Typepad Domains para configurar
  • Depois de 27 de outubro de 2025, faça login no Reseller Club para configurar
• Mesmo ao usar outro registrador que não seja o Typepad Domains, é preciso remover nesse registrador o registro CNAME que aponta para o Typepad e configurá-lo para apontar para o novo serviço ou plataforma de blog
• Leitores que procuram um blog específico devem perguntar diretamente ao blogueiro onde o blog foi republicado
• Consultas adicionais podem ser feitas por telefone ou chat da Network Solutions

[GN⁺]

Opiniões do Hacker News

• Há um patch em análise: https://inbox.sourceware.org/libc-alpha/cover.1722193092.git...
  Ele começou por causa de https://issues.redhat.com/browse/RHEL-42410, e era um problema de estabilidade da stack gráfica que, por algum motivo, era menos perceptível no RHEL 9
  Espero que pelo menos o primeiro patch, ou seja, a correção de segurança de threads do getenv, entre no glibc 2.41, e o backport também parece bastante seguro
  setenv é relativamente fácil de lidar porque o glibc já nunca libera as strings de variáveis de ambiente; o complicado é o unsetenv concorrente
  Sem uma abordagem por snapshot, getenv pode retornar um ponteiro nulo em vez de retornar o valor da variável de ambiente que está de fato definida
  Não quero colocar lock no getenv, porque getenv usado sem setenv há muito tempo é considerado async-signal-safe, e adicionar um lock tem grande chance de quebrar aplicações
  A correção do tratamento de environ é um pouco mais controversa porque é complicado evitar vazamentos de memória por causa de vfork+execve, mas essas correções adicionais são menos importantes para a estabilidade da stack gráfica

  • Fico pensando se não daria para colocar as variáveis adicionadas depois do início do processo em uma lista ligada e implementar isso atomicamente
    Quando ela ficasse longa demais, a thread que executa setenv poderia criar um novo hashmap e trocar atomicamente o ponteiro antigo pelo novo
    Bastaria usar uma flag atômica indicando se uma re-hash está em andamento, para impedir que duas threads façam re-hash ao mesmo tempo
    Nesse meio-tempo, se outra thread chamar setenv, as variáveis adicionais são anexadas à lista e processadas depois, quando houver uma chamada futura a setenv
    Se um número suficiente de threads chamar setenv rapidamente, a lista pode crescer indefinidamente, mas setenv não costuma ser chamado com frequência, então a simplicidade da troca atômica de ponteiro parece valer a pena
  • Pode ser relacionado: "Setenv Is Not Thread Safe and C Doesn't Want to Fix It" (2023) -- https://www.evanjones.ca/setenv-is-not-thread-safe.html e um comentário no HN sobre como Rust foi afetado: https://news.ycombinator.com/item?id=38342642
    Um campo minado sob os pés de décadas atrás... frustrante

• Sou muito grato por Steam rodar tão bem no Linux hoje em dia
  Não tomo como garantido o esforço que acontece nos bastidores para tornar essa realidade possível para nós

  • Espero que lancem logo uma versão oficial do SteamOS de novo
    Quero montar uma torre gamer com base nele
    Poderia me contentar com o Bazzite, mas, sinceramente, quero usar o SteamOS

• Acho que a boa prática não seria ler todas as variáveis de ambiente na inicialização e nunca usar setenv?
  O único lugar em que setenv faz sentido é ao iniciar um novo processo; mesmo nesse caso, parece mais correto criar um novo environ copiando o environ atual e atualizando os novos valores
  Usar getenv/setenv como se fosse um mecanismo de mensagens de comunicação entre processos é uma abordagem que traz vários problemas, além do fato de historicamente não ter sido thread-safe no Linux, como possíveis vazamentos de memória ocultos
  O texto parece ignorar isso quando diz que no macOS é thread-safe

  • Não. Você pode acabar usando uma biblioteca que chama getenv()
    Java faz do jeito que você mencionou, mas código JNI que usa uma biblioteca que quer getenv() ainda enfrenta problemas

• A pergunta real é: existe algum caso em que você chama setenv em uma thread e realmente quer que essa mudança se aplique a outras threads já existentes?
  Ainda assim, a GLIBC documenta bem as funções perigosas, então é possível adicionar locks ou cópias por conta própria

  • Ideia interessante
    Certamente há programas que esperam que setenv altere o array environ, e é bem possível que não o tratem apenas como um ponteiro opaco passado a posix_spawn/execve
    Para ter setenv por thread, também seria necessária uma variável environ por thread
    Mas isso não combina bem com POSIX, porque environ não é declarado em um header; o programador deve escrever manualmente a declaração extern char **environ; no código-fonte
    Essa declaração não é compatível com environ sendo uma variável thread-local
  • Se uma biblioteca de dependência de terceiros usa getenv/setenv, você não consegue adicionar locks ou cópias por conta própria
    O texto também trata disso como um problema recorrente do cliente Steam
  • Na prática, eu defino variáveis de ambiente em um plugin e faço com que threads worker já iniciadas leiam esses valores depois
    No meu caso, as threads worker ficam todas dormindo na fila de execução, então isso não causa problema, mas tecnicamente é uma situação em que uma thread define uma variável de ambiente e outras threads já em execução querem lê-la
  • A Glibc poderia se inspirar no Illumos, que tem putenv()/setenv()/unsetenv()/getenv() thread-safe
  • Há muitos métodos muito melhores para comunicação entre processos, então não há necessidade de uma configuração getenv/setenv tão hacky e perigosa
    Não sei que biblioteca de threading não teria memória compartilhada ou passagem de mensagens
    Imagino que isso aconteça principalmente em situações como o processo principal alterar variáveis como HTTPS_PROXY e, em outra thread, uma biblioteca verificar essa variável antes de abrir um socket TCP

• Como referência, a decisão de vazar memória no Mac na verdade remonta ao FreeBSD de cerca de 26 anos atrás: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=5604
  O OSX herdou isso, e não seria surpreendente se o setenv do Windows também fosse da linhagem BSD por causa da licença
  Mesmo 26 anos atrás já se sabia que essa API estava quebrada, mas ela não foi corrigida por inércia, para não quebrar ainda mais programas com bugs
  Quase nunca deveria ser necessário alterar as variáveis de ambiente do próprio processo
  Para subprocessos, basta usar a função exec adequada; fora isso, em vez de alterar uma variável global e torcer para que um código distante a releia e a trate corretamente, deve-se chamar uma API explícita

  • Concordo apenas em parte com a sensação de que “não dá para corrigir”
    Com a API atual, é verdade, mas uma mudança muito pequena na API tornaria isso possível
    Bastaria fazer strdup() do valor antes de getenv() retorná-lo e fazer o programador liberar a memória depois do uso
    Se achar que o valor pode mudar, o programador teria que chamar getenv() de novo, mas parece uma concessão razoável
    Essa alteração vazaria memória toda vez que um programa antigo não chamasse free() depois de chamar getenv(), mas a versão atual também vaza memória, então não parece ser um problema decisivo
    De quebra, a nova versão poderia envolver o strdup() com um mutex e tratar setenv() de forma parecida para torná-la thread-safe

• Um colega chamou setenv de “a pior API do Linux”, mas setenv é mesmo uma API do Linux?
  Ela não foi definida pelo Linux, está no POSIX, e também não é implementada pelo kernel Linux; fica inteiramente no espaço de usuário

  • Se você está criando software aplicativo para Linux e as outras plataformas suportadas são Windows e macOS, então sim
    Pelo visto, o autor original e o colega trabalham na Valve dando suporte ao Steam, então esse é o contexto
    O motivo pelo qual esse colega a chamou de pior não é a especificação POSIX
    O POSIX apenas diz que essa função não precisa ser thread-safe; ele não impede que ela seja tornada thread-safe
    O problema é a implementação específica da glibc, a biblioteca C usada em todas as distribuições Linux às quais a Valve dá suporte no Steam, e essas distribuições acabam todas agrupadas como “Linux”
  • Estritamente falando, é uma limitação da GNU libc
    Se a libc quiser, ela pode torná-la thread-safe
    Linguagens como Go implementam esse recurso internamente e não têm essa limitação
    A própria documentação POSIX também leva essa limitação em conta: “The setenv() function need not be thread-safe.”

• Para quem cresceu jogando nethack e xadrez no Linux, a existência do Steam em si é surpreendente
  Mas o cliente Steam é realmente estranho
  Ele funciona bem por meses e então, de repente, os jogos não iniciam ou alguma coisa para de funcionar, e é preciso fazer coisas esquisitas como apagar todos os arquivos ou reinstalar para voltar a funcionar
  Não faz sentido, e dá a sensação de que o cliente Steam está apodrecendo

  • O Steam é um dos piores softwares que existem e, para uma empresa tão grande, sinceramente chega a ser vergonhoso
    É uma mistura confusa de princípios de design diferentes, e novos recursos simplesmente são encaixados com uma UI e uma UX completamente diferentes
    A maior parte do cliente é um webview, lento e cheio de bugs, usando internamente uma versão muito antiga e insegura do Chromium
    O launcher ainda é um programa de 32 bits
    O triste é que os outros launchers são ainda piores
  • Pela minha experiência, todos esses problemas também se aplicam ao Steam no Windows
    Na verdade, depois que passei a usar só Linux, tenho enfrentado menos esse tipo de coisa

• É um conteúdo realmente interessante, que permite espiar tanto o cliente Steam quanto a programação em Linux
  Entendo que seja difícil escrever notas de lançamento detalhadas a cada release, mas, sabendo desse tipo de trabalho, a expressão “várias correções de crashes comuns” é uma enorme minimização

• Eu realmente espero que levem adiante aquela parte: “se pudermos resolver esse problema na glibc, talvez seja necessário algum compromisso funcional, ou talvez seja um mecanismo opt-in que se afaste um pouco da especificação POSIX ‘impossível’. Se alguém conseguir propor uma alternativa razoável, poderemos impulsioná-la no longo prazo”

• Tenho muita curiosidade sobre por que usam tanto setenv(3)
  O principal uso que me vem à cabeça é definir variáveis de ambiente antes de chamar algo como exec(3), mas aqui não parece ser esse o caso
  O texto diz que, ao iniciar subprocessos, usam execvpe, então fico curioso sobre o que sobra para usar setenv(3)

  • Dá para verificar o uso de setenv/unsetenv/putenv com nm -D, e, mesmo dando uma olhada por alto em ~/.cargo/bin/*, há programas demais usando essas coisas
    Talvez sejam single-threaded, mas quem pode garantir que continuarão assim no futuro?
    Pensando bem, também daria para detectar pthread_create pela lista de símbolos
    Seria interessante se houvesse também algum método de análise estática de binários que rastreasse a partir desses símbolos até a árvore de chamadas
    Mas não vejo como verificar o uso de **environ. O compilador pode transformar isso em qualquer coisa