Cierre del servicio Typepad y guía para transferir dominios

• Con el cierre de Typepad, los operadores de blogs existentes deben resolver por su cuenta la posible transferencia de dominios y contenido, mientras el inicio de sesión y el acceso a archivos están bloqueados
• La fecha de cierre del servicio es el 30 de septiembre de 2025; después de esa fecha ya no se ofrecerá inicio de sesión a las cuentas
• A los clientes que pagaron una tarifa anual que cubría un período posterior a la fecha de cierre se les emitió un reembolso proporcional; si el reembolso no aparece en el estado de cuenta, deben confirmarlo con su banco
• Todos los datos de los blogs se eliminarán, y no se ofrecerán extensiones de acceso ni vías de recuperación, salvo consultas relacionadas con información personal
• Los dominios registrados en Typepad Domains se transferirán a Reseller Club el 27 de octubre de 2025, y para conectarlos a una nueva plataforma será necesario eliminar el CNAME existente de Typepad

---

Manejo de cuentas y datos después del cierre del servicio

• La fecha de cierre del servicio de Typepad es el 30 de septiembre de 2025
• Después de la fecha de cierre, los usuarios ya no podrán iniciar sesión en sus cuentas
• A los clientes que pagaron una tarifa anual de servicio que cubría un período posterior a la fecha de cierre se les emitirá un reembolso proporcional
  • Si el reembolso no aparece en el estado de cuenta, deben consultar con su banco
  • Si no había una tarjeta de crédito válida registrada, es posible que el reembolso no se haya procesado
• Después del cierre, se interrumpirá el acceso a los archivos y no se ofrecerá ninguna extensión por separado
• Todos los datos de los blogs se eliminarán, y las consultas relacionadas con información personal deben enviarse a [e-mail]

Transferencia de Typepad Domains y conexión de un nuevo blog

• Typepad Domains es un revendedor de LogicBoxes, y todos los dominios registrados en Typepad Domains se transferirán el 27 de octubre de 2025 a Reseller Club, otro socio de LogicBoxes
• Esos usuarios recibirán un correo electrónico adicional con instrucciones de Reseller Club
• No es necesario transferir el dominio desde LogicBoxes a otro lugar; se podrá seguir administrando a través de Reseller Club
• Para conectar un dominio a un nuevo servicio o plataforma de blogs, hay que eliminar el registro CNAME que apunta al Typepad existente y configurarlo según los requisitos del nuevo servicio
  • Antes del 27 de octubre de 2025, se configura iniciando sesión en Typepad Domains
  • Después del 27 de octubre de 2025, se configura iniciando sesión en Reseller Club
• Incluso si se usa un registrador distinto de Typepad Domains, se debe eliminar en ese registrador el registro CNAME que apunta a Typepad y configurarlo para que apunte al nuevo servicio o plataforma de blogs
• Los lectores que busquen un blog específico deben preguntar directamente al bloguero dónde se volvió a publicar el blog
• Las consultas adicionales pueden hacerse por teléfono o chat a Network Solutions

[GN⁺]

Opiniones de Hacker News

• Hay un parche en revisión: https://inbox.sourceware.org/libc-alpha/cover.1722193092.git...
  Surgió por https://issues.redhat.com/browse/RHEL-42410, y era un problema de estabilidad del stack gráfico que por alguna razón era menos visible en RHEL 9
  Espero que al menos el primer parche, es decir, la corrección de seguridad de hilos en getenv, entre en glibc 2.41, y también parece bastante seguro hacer backport
  setenv es relativamente fácil de manejar porque glibc ya nunca libera las cadenas de variables de entorno; lo complicado es unsetenv concurrente
  Sin un enfoque de snapshots, getenv puede devolver un puntero nulo en lugar de devolver el valor de una variable de entorno que realmente está configurada
  No quiero poner un bloqueo en getenv, porque getenv usado sin setenv se ha considerado async-signal-safe desde hace muchísimo tiempo, y agregarle un bloqueo probablemente rompería aplicaciones
  La corrección del manejo de environ es algo más polémica porque evitar fugas de memoria por vfork+execve es complejo, pero estas correcciones adicionales son menos importantes para la estabilidad del stack gráfico

  • Me pregunto qué tal sería poner las variables agregadas después del inicio del proceso en una lista enlazada e implementarlo de forma atómica
    Si la longitud crece demasiado, el hilo que ejecuta setenv podría crear un nuevo hashmap y reemplazar atómicamente el puntero anterior por el nuevo
    Bastaría con usar una bandera atómica que indique si actualmente se está rehasheando, para que dos hilos no hagan rehash al mismo tiempo
    Mientras tanto, si otro hilo llama a setenv, las variables adicionales se agregan a la lista y se procesan en una llamada posterior a setenv
    Si suficientes hilos llaman rápidamente a setenv, la lista podría crecer indefinidamente, pero como setenv no se llama con frecuencia, creo que la simplicidad del reemplazo atómico de punteros valdría la pena
  • Podría estar 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 y un comentario de HN sobre cómo Rust se vio afectado: https://news.ycombinator.com/item?id=38342642
    Qué frustrante que sea una mina enterrada bajo los pies desde hace décadas

• De verdad agradezco que Steam funcione tan bien hoy en Linux
  No doy por sentado el trabajo que se hace detrás de escena para hacer realidad eso por nosotros

  • Ojalá pronto vuelvan a sacar un lanzamiento oficial de SteamOS
    Quiero armar una torre gamer basada en eso
    Podría conformarme con Bazzite, pero sinceramente quiero hacerlo con SteamOS

• Me parece que la buena práctica es leer todas las variables de entorno al iniciar y no usar nunca setenv
  El único lugar donde setenv tiene sentido es al lanzar un proceso nuevo, e incluso en ese caso parece más correcto crear un nuevo environ duplicando el environ actual y actualizando los nuevos valores
  Usar getenv/setenv como si fuera un mecanismo de mensajería de comunicación entre procesos trae varios problemas, además del hecho de que históricamente no ha sido thread-safe en Linux, como posibles fugas de memoria ocultas
  El artículo parece ignorar esto cuando dice que en macOS sí es thread-safe

  • No. Puedes terminar usando una biblioteca que llama a getenv()
    Java lo hace de la forma que mencionas, pero el código JNI que usa una biblioteca que quiere getenv() sigue teniendo problemas

• La verdadera pregunta es esta: ¿hay algún caso en el que realmente quieras llamar a setenv en un hilo y que ese cambio se aplique también a otros hilos ya existentes?
  Aun así, GLIBC documenta bastante bien las funciones peligrosas, así que es posible agregar bloqueos o copias por cuenta propia

  • Es una idea interesante
    Seguramente hay programas que esperan que setenv modifique el arreglo environ, y es probable que no lo traten solo como un puntero opaco que se pasa a posix_spawn/execve
    Para tener setenv por hilo también haría falta una variable environ por hilo
    Pero eso no encaja bien con POSIX, porque environ no está declarado en un header y se supone que el programador escriba directamente extern char **environ; en el código fuente
    Esa declaración no es compatible con el caso en que environ sea una variable local al hilo
  • Si una biblioteca de terceros de la que dependes usa getenv/setenv, no puedes agregar tus propios bloqueos ni copias
    El artículo también trata este punto como parte de los problemas persistentes del cliente de Steam
  • En la práctica, configuro variables de entorno en plugins y hago que hilos trabajadores ya iniciados lean esos valores más tarde
    En mi caso no causa problemas porque todos los hilos trabajadores están dormidos en la cola de ejecución, pero técnicamente es una situación en la que quiero establecer una variable de entorno en un hilo y leerla desde otro hilo que ya está en ejecución
  • Glibc podría tomar como referencia a Illumos, que tiene putenv()/setenv()/unsetenv()/getenv() thread-safe
  • Hay muchas formas mucho mejores para la comunicación entre procesos, así que no debería hacer falta una configuración tan hacky y peligrosa con getenv/setenv
    No sé qué biblioteca de threading no tendría memoria compartida o paso de mensajes
    Supongo que suele surgir en situaciones como que el proceso principal cambia una variable como HTTPS_PROXY y otros hilos ejecutan una biblioteca que revisa esa variable antes de abrir un socket TCP

• Como referencia, la decisión de hacer que en Mac se fugue memoria en realidad se remonta a FreeBSD hace unos 26 años: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=5604
  OSX heredó esto, y no sería sorprendente que el setenv de Windows también venga del linaje BSD por temas de licencia.
  Hace 26 años ya se sabía que esta API estaba rota, pero no se corrigió por la inercia de no romper todavía más los programas con bugs.
  Casi nunca debería ser necesario cambiar las variables de entorno del propio proceso.
  Para procesos hijo, basta con usar la función exec adecuada; para lo demás, en vez de cambiar una variable global y esperar que código lejano la vuelva a leer y la maneje correctamente, habría que llamar a una API explícita.

  • Estoy de acuerdo solo en parte con la sensación de que “no se puede arreglar”.
    Con la API actual, sí; pero con un cambio muy pequeño en la API se vuelve posible.
    Bastaría con que getenv() haga strdup() del valor antes de devolverlo, y que el programador libere la memoria después de usarla.
    Si cree que el valor puede cambiar, el programador tendría que volver a llamar a getenv(), pero parece un compromiso razonable.
    Este cambio haría que los programas antiguos filtren memoria cada vez que no llamen a free() después de getenv(), pero como la versión actual también filtra memoria, no parece ser un problema decisivo.
    Como extra, la nueva versión podría envolver strdup() con un mutex y hacer algo similar del lado de setenv(), para volverla segura para hilos.

• Un colega llamó a setenv “la peor API de Linux”, pero ¿setenv es realmente una API de Linux?
  No la definió Linux, está en POSIX, y tampoco la implementa el kernel de Linux: todo está en espacio de usuario.

  • Si estás haciendo software de aplicación para Linux y las otras plataformas soportadas son Windows y macOS, entonces sí.
    Parece que el autor original y su colega dan soporte a Steam en Valve, así que ese es el contexto.
    La razón por la que ese colega la llamó la peor no es la especificación POSIX.
    POSIX solo dice que esta función no necesita ser segura para hilos; no impide hacerla segura para hilos.
    El problema es la implementación concreta de glibc, la biblioteca C que se usa en todas las distribuciones Linux que Valve soporta para Steam, y como todas esas distribuciones se agrupan bajo “Linux”.
  • Estrictamente hablando, es una restricción de GNU libc.
    Si libc quisiera, podría hacerla segura para hilos.
    Lenguajes como Go implementan esta funcionalidad internamente y no tienen esa restricción.
    La propia documentación de POSIX también contempla esta limitación: “The setenv() function need not be thread-safe.”

• Como alguien que creció jugando nethack y ajedrez en Linux, la existencia misma de Steam me sorprende.
  Pero el cliente de Steam sí que es rarísimo.
  Funciona bien durante meses y de pronto un juego no arranca o algo deja de funcionar, y hay que hacer cosas raras como borrar todos los archivos o reinstalar para que vuelva a andar.
  No tiene sentido; se siente como si el cliente de Steam se estuviera pudriendo.

  • Steam es uno de los peores software que hay y, para una empresa tan grande, francamente da vergüenza.
    Es una mezcolanza de principios de diseño distintos, y las funciones nuevas simplemente se pegan encima con una UI y UX completamente diferentes.
    La mayor parte del cliente son webviews, lentas y llenas de bugs, y por dentro usa una versión muy vieja e insegura de Chromium.
    El launcher todavía es un programa de 32 bits.
    Lo triste es que los otros launchers son todavía peores.
  • En mi experiencia, todos esos problemas también aplican a Steam en Windows.
    De hecho, desde que uso solo Linux, me pasan menos esas cosas.

• Es un contenido realmente interesante que permite asomarse tanto al cliente de Steam como a la programación en Linux.
  Entiendo que sea difícil escribir notas de lanzamiento detalladas en cada release, pero después de enterarse de este tipo de trabajo, la frase “varias correcciones de fallos comunes” suena como una enorme subestimación.

• Ojalá de verdad hagan lo que dice la parte de “si se puede resolver este problema en glibc, quizá haga falta algún compromiso funcional, o un mecanismo opt-in que se aparte un poco de la especificación POSIX ‘imposible’. Si alguien puede proponer una alternativa razonable, se puede impulsar a largo plazo”.

• Me da mucha curiosidad por qué se usa tanto setenv(3).
  El uso principal que se me ocurre es establecer variables de entorno antes de llamar a algo como exec(3), pero no parece ser el caso aquí.
  El artículo dice que al lanzar procesos hijo usan exevpe, así que me pregunto qué otros usos quedan para setenv(3).

  • Con nm -D se puede revisar si se usa setenv/unsetenv/putenv, y aun mirando por encima mi ~/.cargo/bin/*, hay demasiados programas que los usan.
    Tal vez sean de un solo hilo, pero ¿quién puede garantizar que siempre seguirá siendo así?
    Pensándolo bien, con la lista de símbolos también se podría detectar pthread_create.
    Sería interesante que existiera alguna forma de análisis estático de binarios que rastreara desde estos símbolos hasta el árbol de llamadas.
    Eso sí, no veo forma de comprobar si se usa **environ; el compilador puede convertir esto en cualquier cosa.