Fin du service Typepad et informations sur le transfert de domaine

 (ttimo.typepad.com)
2 points par GN⁺ 2024-11-12 | 1 commentaires | Partager sur WhatsApp
  • Avec l’arrêt de Typepad, les propriétaires de blogs existants doivent décider eux-mêmes du transfert de leur domaine et de leur contenu, alors que la connexion et l’accès aux fichiers sont bloqués
  • La date de fin du service est fixée au 30 septembre 2025, et la connexion aux comptes ne sera plus proposée après cette date
  • Pour les clients ayant payé des frais annuels couvrant une période après la fermeture, un remboursement au prorata a été émis ; si le remboursement n’apparaît pas, il faut vérifier auprès de sa banque
  • Toutes les données de blog seront supprimées et, en dehors des demandes liées aux données personnelles, aucune prolongation d’accès ni solution de récupération ne sera proposée
  • Les domaines enregistrés via Typepad Domains seront transférés le 27 octobre 2025 vers Reseller Club, et il faudra supprimer l’ancien CNAME Typepad pour les relier à une nouvelle plateforme

Traitement des comptes et des données après la fin du service

  • La date de fin du service de Typepad est le 30 septembre 2025
  • Après cette date, les utilisateurs ne pourront plus se connecter à leur compte
  • Un remboursement au prorata sera émis pour les clients ayant payé des frais de service annuels couvrant une période après la date de fermeture
    • Si le remboursement n’apparaît pas sur le relevé, il faut contacter sa banque
    • Si aucune carte de crédit valide n’était enregistrée, il est possible que le remboursement n’ait pas été traité
  • Après la fermeture, l’accès aux fichiers sera interrompu et aucune prolongation distincte ne sera proposée
  • Toutes les données de blog seront supprimées, et pour les questions liées aux données personnelles, il faut écrire à privacy@newfold.com

Transfert de Typepad Domains et connexion à un nouveau blog

  • Typepad Domains est un revendeur de LogicBoxes, et tous les domaines enregistrés via Typepad Domains seront transférés le 27 octobre 2025 vers Reseller Club, un autre partenaire LogicBoxes
  • Les utilisateurs concernés recevront un e-mail d’information complémentaire de la part de Reseller Club
  • Il n’est pas nécessaire de transférer son domaine ailleurs depuis LogicBoxes, et il pourra continuer à être géré ensuite via Reseller Club
  • Pour connecter le domaine à un nouveau service ou à une nouvelle plateforme de blog, il faut supprimer l’enregistrement CNAME pointant vers Typepad et le reconfigurer selon les exigences du nouveau service
    • Avant le 27 octobre 2025, la configuration se fait en se connectant à Typepad Domains
    • Après le 27 octobre 2025, la configuration se fait en se connectant à Reseller Club
  • Si vous utilisez un autre registrar que Typepad Domains, il faut également supprimer chez ce registrar l’enregistrement CNAME pointant vers Typepad, puis le configurer pour qu’il pointe vers le nouveau service ou la nouvelle plateforme de blog
  • Les lecteurs à la recherche d’un blog précis devront contacter directement le blogueur pour savoir où le blog a été republié
  • Pour toute question supplémentaire, il est possible de contacter Network Solutions par téléphone ou via le chat

À lire aussi

1 commentaires

 
GN⁺ 2024-11-12
Avis Hacker News

  • Il y a un patch en cours d’examen : https://inbox.sourceware.org/libc-alpha/cover.1722193092.git...
    Cela a commencé à cause de https://issues.redhat.com/browse/RHEL-42410 et il s’agissait d’un problème de stabilité de la pile graphique qui, pour une raison ou une autre, était moins visible sur RHEL 9
    J’espère au moins que le premier patch, c’est-à-dire la correction de la sûreté des threads de getenv, entrera dans glibc 2.41, et un backport semblerait aussi assez sûr
    setenv est relativement plus facile à traiter, car glibc ne libère déjà jamais les chaînes des variables d’environnement, et le point délicat est unsetenv en concurrence
    Sans approche par snapshot, getenv peut renvoyer un pointeur nul au lieu de renvoyer la valeur réellement définie d’une variable d’environnement
    Je ne veux pas mettre de verrou dans getenv, car getenv utilisé sans setenv est considéré comme async-signal-safe depuis bien trop longtemps, et ajouter un verrou risquerait de casser des applications
    La correction du traitement de environ est plus controversée parce qu’il est compliqué d’éviter les fuites mémoire à cause de vfork+execve, mais ces corrections supplémentaires sont moins importantes pour la stabilité de la pile graphique

    • Je me demande s’il ne vaudrait pas mieux mettre les variables ajoutées après le démarrage du processus dans une liste chaînée et l’implémenter de façon atomique
      Si la longueur devient trop grande, le thread qui exécute setenv pourrait construire une nouvelle table de hachage, puis remplacer atomiquement l’ancien pointeur par le nouveau
      Il suffirait d’utiliser un drapeau atomique indiquant si un réhachage est en cours, afin d’éviter que deux threads ne réhachent en même temps
      Si, entre-temps, un autre thread appelle setenv, les variables ajoutées seraient attachées à la liste et traitées lors d’un appel ultérieur à setenv
      Si suffisamment de threads appellent rapidement setenv, la liste pourrait grossir indéfiniment, mais comme setenv n’est pas appelé souvent, la simplicité du remplacement atomique de pointeur semble valoir le coup
    • Peut-être lié : "Setenv Is Not Thread Safe and C Doesn't Want to Fix It" (2023) -- https://www.evanjones.ca/setenv-is-not-thread-safe.html et un commentaire HN sur la manière dont Rust a été affecté : https://news.ycombinator.com/item?id=38342642
      Une mine antipersonnel vieille de plusieurs décennies… c’est frustrant

  • Je suis vraiment reconnaissant que Steam fonctionne aussi bien sur Linux aujourd’hui
    Je ne considère pas comme acquise toute l’énorme quantité de travail en coulisses qu’il a fallu pour rendre ça possible

    • J’aimerais qu’ils republient bientôt une version finale de SteamOS
      J’aimerais construire une tour gaming sur cette base
      Je pourrais me contenter de Bazzite, mais honnêtement, je préférerais SteamOS

  • J’ai l’impression que la bonne pratique, c’est de lire toutes les variables d’environnement au démarrage et de ne jamais utiliser setenv
    Le seul endroit où setenv a vraiment du sens, c’est au lancement d’un nouveau processus, et même dans ce cas il semblerait plus juste de créer un nouveau environ en copiant le environ courant puis d’y mettre à jour les nouvelles valeurs
    Utiliser getenv/setenv comme mécanisme de messagerie inter-processus entraîne toutes sortes de problèmes, notamment la non-sûreté historique vis-à-vis des threads sur Linux, ainsi que des risques cachés de fuite mémoire
    L’article semble ignorer ces aspects quand il dit que c’est thread-safe sur macOS

    • Non. On peut se retrouver à utiliser une bibliothèque qui appelle getenv()
      Java fonctionne comme vous l’avez décrit, mais dans du code JNI qui utilise une bibliothèque voulant appeler getenv(), le problème subsiste

  • La vraie question est celle-ci : existe-t-il vraiment un cas où l’on appelle setenv dans un thread et où l’on veut que ce changement s’applique aussi à d’autres threads déjà existants ?
    Cela dit, GLIBC documente assez bien les fonctions dangereuses, donc il est possible d’ajouter soi-même un verrouillage ou une copie

    • C’est une idée intéressante
      Il y a sûrement des programmes qui s’attendent à ce que setenv modifie le tableau environ, et pas seulement à ce qu’il soit traité comme un pointeur opaque passé à posix_spawn/execve
      Pour avoir un setenv par thread, il faudrait aussi une variable environ par thread
      Mais cela s’accorde mal avec POSIX, car environ n’est pas déclaré dans les en-têtes et les programmeurs sont censés écrire eux-mêmes extern char **environ; dans le code source
      Cette déclaration n’est pas compatible avec un environ thread-local
    • Si des bibliothèques tierces dont on dépend utilisent getenv/setenv, on ne peut pas ajouter soi-même de verrouillage ou de copie
      L’article en parle aussi à propos des problèmes persistants du client Steam
    • En pratique, dans un plugin, je définis une variable d’environnement, puis des threads de travail déjà démarrés lisent cette valeur plus tard
      Dans mon cas, les threads de travail dorment tous dans la file d’exécution, donc ce n’est pas un problème, mais techniquement c’est bien une situation où l’on veut définir une variable d’environnement dans un thread puis la lire dans un autre thread déjà en cours d’exécution
    • Glibc pourrait s’inspirer d’Illumos, qui dispose de putenv()/setenv()/unsetenv()/getenv() thread-safe
    • Il existe de bien meilleures façons de faire de la communication inter-processus, donc ce genre de configuration getenv/setenv bricolée et risquée ne devrait pas être nécessaire
      Je ne vois pas quelle bibliothèque de threading n’aurait ni mémoire partagée ni passage de messages
      J’imagine que cela se produit surtout dans des situations où le processus principal modifie une variable comme HTTPS_PROXY, puis dans d’autres threads on exécute une bibliothèque qui vérifie cette variable avant d’ouvrir une socket TCP

  • À titre indicatif, la décision de laisser fuir la mémoire sur Mac remonte en fait à environ 26 ans, jusqu’à FreeBSD : https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=5604
    OSX en a hérité, et il ne serait pas surprenant que le setenv de Windows soit aussi de lignée BSD pour des raisons de licence
    On savait déjà il y a 26 ans que cette API était cassée, mais on ne l’a pas corrigée par inertie, pour éviter de casser davantage des programmes bogués
    Il devrait être très rare d’avoir besoin de modifier les variables d’environnement de son propre processus
    Pour les processus fils, il suffit d’utiliser une fonction exec appropriée, et dans les autres cas il vaudrait mieux appeler une API explicite plutôt que de modifier une variable globale en espérant qu’un code éloigné la relise et la traite correctement

    • Je ne suis que partiellement d’accord avec l’idée que « ce n’est pas corrigeable »
      C’est vrai avec l’API actuelle, mais cela devient possible avec un tout petit changement d’API
      Il suffirait que getenv() fasse un strdup() de la valeur avant de la renvoyer, puis que le programmeur libère la mémoire après usage
      Si l’on considère que la valeur peut changer, le programmeur doit rappeler getenv(), mais cela semble un compromis raisonnable
      Ce changement provoquerait des fuites mémoire dans les anciens programmes chaque fois qu’ils n’appellent pas free() après getenv(), mais comme la version actuelle fuit déjà la mémoire, cela ne semble pas être un problème décisif
      En prime, la nouvelle version pourrait devenir thread-safe en entourant strdup() d’un mutex et en traitant setenv() de façon similaire

  • Un collègue l’aurait qualifiée de « pire API Linux », mais setenv est-elle vraiment une API Linux ?
    Elle n’a pas été définie par Linux, elle fait partie de POSIX, et elle n’est pas implémentée par le noyau Linux : tout cela relève entièrement de l’espace utilisateur

    • Si l’on développe un logiciel applicatif pour Linux, avec Windows et macOS comme autres plateformes prises en charge, alors oui
      L’auteur original et son collègue semblent travailler chez Valve pour le support de Steam, c’est donc ce contexte
      Si ce collègue la qualifie de pire, ce n’est pas à cause de la spécification POSIX
      POSIX dit seulement que cette fonction n’a pas besoin d’être thread-safe, pas qu’il est interdit de la rendre thread-safe
      Le problème, c’est l’implémentation concrète de glibc, la bibliothèque C utilisée sur toutes les distributions Linux prises en charge par Valve pour Steam, et comme ces distributions sont toutes regroupées sous l’étiquette « Linux », cela explique l’expression
    • À strictement parler, c’est une contrainte de GNU libc
      Si elle le voulait, la libc pourrait la rendre thread-safe
      Des langages comme Go implémentent cette fonctionnalité en interne et n’ont donc pas cette contrainte
      La documentation POSIX elle-même tient compte de cette limite : « The setenv() function need not be thread-safe. »

  • Ayant grandi sous Linux avec nethack et les échecs, l’existence même de Steam me surprend
    Mais le client Steam est vraiment étrange
    Pendant des mois, tout fonctionne bien, puis soudain un jeu ne se lance plus ou quelque chose casse, et il faut refaire des manipulations absurdes comme supprimer tous les fichiers ou réinstaller pour que ça remarche
    Cela n’a aucun sens, et on a l’impression que le client Steam se dégrade

    • Steam fait partie des pires logiciels qui existent, et pour une entreprise de cette taille, c’est franchement honteux
      C’est un assemblage hétéroclite de principes de conception différents, et les nouvelles fonctionnalités sont simplement ajoutées avec une UI et une UX complètement différentes
      La majeure partie du client est une webview, lente et boguée, qui utilise en interne une version de Chromium très ancienne et peu sûre
      Le lanceur est encore un programme 32 bits
      Ce qui est triste, c’est que les autres lanceurs sont encore pires
    • D’après mon expérience, tous ces problèmes existent aussi sur Steam pour Windows
      Au contraire, depuis que je n’utilise plus que Linux, je les rencontre moins souvent

  • C’est un contenu vraiment intéressant, qui donne un aperçu à la fois du client Steam et de la programmation Linux
    Je comprends qu’il soit difficile d’écrire des notes de version détaillées à chaque publication, mais quand on connaît ce type de travail, l’expression « plusieurs corrections de crashs courants » ressemble à un énorme euphémisme

  • Le passage disant que « si glibc peut résoudre ce problème, il faudra peut-être un compromis fonctionnel, et peut-être un mécanisme opt-in qui s’écarte légèrement d’une spécification POSIX “impossible”. Si quelqu’un peut proposer une solution raisonnable, on pourra l’envisager sur le long terme » donne vraiment envie que cela se fasse

  • Je me demande vraiment pourquoi ils utilisent autant setenv(3)
    Le principal usage qui me vient à l’esprit est de définir des variables d’environnement avant d’appeler quelque chose comme exec(3), mais ici cela ne semble pas être le cas
    L’article dit qu’ils utilisent exevpe au moment de lancer des processus fils, donc je me demande à quoi il reste encore setenv(3)

    • On peut vérifier l’usage de setenv/unsetenv/putenv avec nm -D, et même en regardant rapidement mon ~/.cargo/bin/*, il y a beaucoup trop de programmes qui utilisent ces fonctions
      Ils sont peut-être monothreadés, mais qui peut garantir qu’ils le resteront toujours
      En y réfléchissant, on pourrait aussi détecter pthread_create dans la liste des symboles
      Ce serait intéressant d’avoir aussi une méthode d’analyse statique de binaires capable de remonter jusqu’à l’arbre d’appels depuis ces symboles
      En revanche, je ne vois pas comment vérifier l’usage de **environ. Le compilateur peut transformer cela en à peu près n’importe quoi.