Typepadサービス終了とドメイン移管の案内
(ttimo.typepad.com)- Typepadの終了により、既存のブログ運営者はログインとファイルへのアクセスができない状態で、ドメインやコンテンツの移行要否を自ら整理する必要があります
- サービス終了日は2025年9月30日で、それ以降はアカウントへのログインは提供されません
- 終了日以降の期間まで年額料金を支払った顧客には比例配分による返金が行われており、返金明細が見当たらない場合は銀行への確認が必要です
- すべてのブログデータは削除される予定で、個人情報関連の問い合わせ以外に、アクセス延長や復旧の手段は提供されません
- Typepad Domainsで登録されたドメインは2025年10月27日にReseller Clubへ移管され、新しいプラットフォームに接続するには既存のTypepad向けCNAMEを削除する必要があります
サービス終了後のアカウントとデータの取り扱い
- Typepadのサービス終了日は2025年9月30日です
- 終了日以降、ユーザーはアカウントにログインできなくなります
- 終了日以降の期間まで年額サービス料金を支払った顧客には、比例配分による返金が行われます
- 明細書に返金が表示されない場合は、銀行に問い合わせる必要があります
- 有効なクレジットカードが登録されていない場合、返金処理が行われていない可能性があります
- 終了後はファイルへのアクセスが停止され、別途延長も提供されません
- すべてのブログデータは削除される予定で、個人情報関連の問い合わせはprivacy@newfold.com宛てに行う必要があります
Typepad Domainsの移管と新しいブログへの接続
- Typepad DomainsはLogicBoxesのリセラーであり、Typepad Domainsに登録されているすべてのドメインは、2025年10月27日に別のLogicBoxesパートナーであるReseller Clubへ移管されます
- 対象ユーザーにはReseller Clubから追加案内のメールが届きます
- LogicBoxesからドメインを別の場所へ移管する必要はなく、その後もReseller Clubを通じて継続管理できます
- 新しいブログサービスやプラットフォームにドメインを接続するには、既存のTypepadを指すCNAMEレコードを削除し、新サービスの要件に合わせて設定する必要があります
- 2025年10月27日より前は、Typepad Domainsにログインして設定します
- 2025年10月27日以降は、Reseller Clubにログインして設定します
- Typepad Domains以外のレジストラを利用している場合も、そのレジストラでTypepadを指すCNAMEレコードを削除し、新しいブログサービスやプラットフォームを指すように設定する必要があります
- 特定のブログを探している読者は、そのブログがどこで再公開されたかを当該ブロガーに直接問い合わせる必要があります
- 追加の問い合わせは、Network Solutionsの電話またはチャットで行えます
1件のコメント
Hacker Newsの意見
レビュー中のパッチがある: https://inbox.sourceware.org/libc-alpha/cover.1722193092.git...
https://issues.redhat.com/browse/RHEL-42410 がきっかけで始まったもので、RHEL 9では何らかの理由で目立ちにくかったグラフィックスタックの安定性問題だった
少なくとも最初のパッチ、つまり getenv のスレッド安全性修正は glibc 2.41 に入ることを期待しており、バックポートもかなり安全そうだ
setenv は、glibc がすでに環境変数文字列を決して解放しないため比較的扱いやすく、難しいのは同時実行される unsetenv だ
スナップショット方式なしでは、getenv が実際に設定されている環境変数の値を返す代わりにヌルポインタを返してしまう可能性がある
getenv にロックを入れたくはない。setenv なしで使う getenv は、あまりにも昔から非同期シグナル安全（async-signal-safe）と見なされてきたし、ロックを入れるとアプリケーションが壊れる可能性が大きい
environ 処理の修正は vfork+execve のためにメモリリークを避けるのが複雑で、もう少し議論の余地があるが、これらの追加修正はグラフィックスタックの安定性にはそれほど重要ではない
長さが伸びすぎたら、setenv を実行するスレッドが新しいハッシュマップを作り、古いポインタを新しいポインタへアトミックに置き換えられる
2つのスレッドが同時に再ハッシュしないよう、現在再ハッシュ中かどうかを示すアトミックフラグを使えばよい
その間に別のスレッドが setenv を呼んだ場合、追加変数はリストに付け加えられ、後で setenv 呼び出しがあれば処理される
十分に多くのスレッドが高速に setenv を呼び出すとリストが無限に伸びる可能性はあるが、setenv は頻繁に呼ばれるものではないので、ポインタのアトミック置換の単純さには価値がありそうだ
数十年ものの足元の地雷とは、もどかしい
最近の Linux で Steam がここまでうまく動くのは本当にありがたい
その現実を実現するために裏で注がれている労力を、当然のものとは思っていない
それをベースにゲーミングタワーを作りたい
Bazzite で妥協することもできるだろうけど、正直 SteamOS にしたい
起動時にすべての環境変数を読み取り、setenv を絶対に使わないことがベストプラクティスなのではと思う
setenv が意味を持つ唯一の場所は新しいプロセスを起動するときだが、その場合でも現在の environ を複製した新しい environ を作り、新しい値を更新するのが正しそうだ
getenv/setenv をプロセス間通信のメッセージング機構のように使うのは、Linux で歴史的にスレッド安全でなかった問題に加え、隠れたメモリリークの可能性など、いろいろな問題を招くやり方だ
記事で macOS ではスレッド安全だと言うとき、このあたりを無視しているように見える
Java は述べたような方式を取るが、getenv() を欲しがるライブラリを使う JNI コードでは、なお問題が起きる
本当の質問はこれだ。あるスレッドで
setenvを呼び、その変更がすでに存在する別のスレッドにも適用されることを、本当に望むケースはあるのか？とはいえ GLIBC は危険な関数をかなりきちんと文書化しているので、自分でロックやコピーを追加することは可能だ
setenv が environ 配列を変更すると期待しているプログラムは確実にありそうだし、posix_spawn/execve に渡す不透明ポインタとしてだけ扱うとは限らない
スレッド別 setenv をするには、スレッド別の environ 変数も必要になる
ただし POSIX とは相性が悪い。environ はヘッダで宣言されておらず、プログラマがソースに
extern char **environ;宣言を自分で書くことになっているためだこの宣言は、environ がスレッドローカル変数である場合と互換性がない
記事でも Steam クライアントで続いている問題としてこの点を扱っている
私の場合、ワーカースレッドはすべて実行キューで眠っているので問題にはならないが、技術的には、あるスレッドで環境変数を設定し、すでに実行中の別スレッドで読みたい状況だ
どのスレッディングライブラリに共有メモリやメッセージパッシングがないというのか分からない
おそらく、メインプロセスが HTTPS_PROXY のような変数を変更し、別スレッドでは TCP ソケットを開く前にその変数を確認するライブラリを実行する、といった状況で主に起きるのだろう
ちなみに、Macでメモリをリークさせるという決定は、実は約26年前のFreeBSDにまでさかのぼる: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=5604
OSXがそれを受け継いでおり、Windowsのsetenvもライセンスの関係でBSD系譜である可能性が高くても驚きではない
26年前にもこのAPIが壊れていることは分かっていたが、バグのあるプログラムをさらに壊してしまう惰性のために修正しなかった
自分のプロセスの環境変数を変更する必要は、ほとんどないはずだ
子プロセスには適切なexec関数を使えばよく、それ以外ではグローバル変数を変更して遠く離れたコードが再読み込みして正しく処理してくれることを期待するのではなく、明確なAPIを呼び出すべきだ
現在のAPIではその通りだが、APIをほんの少し変えれば可能になる
getenv()が返す前に値を
strdup()し、プログラマーが使用後にメモリを解放するようにすればよい値が変わる可能性があると考えるなら、プログラマーはgetenv()を再度呼び出す必要があるが、合理的な妥協に見える
この変更は、古いプログラムがgetenv()呼び出し後に
free()しないたびにメモリをリークさせることになるが、現行バージョンもメモリをリークするので、決定的な問題ではないように思うおまけに新バージョンでは
strdup()をミューテックスで囲み、setenv()側も同様に処理することでスレッドセーフにできる同僚がsetenvを「最悪のLinux API」と呼んだそうだが、setenvは本当にLinux APIなのか？
Linuxが定義したものでもなくPOSIXにあり、Linuxカーネルが実装したものでもなく、すべてユーザー空間にある
原文の著者と同僚はValveでSteamをサポートしているようなので、そういう文脈だ
その同僚が最悪と呼んだ理由はPOSIX仕様のせいではない
POSIXはこの関数がスレッドセーフである必要はないと言っているだけで、スレッドセーフにすることを妨げてはいない
問題は、ValveがSteamをサポートするすべてのLinuxディストリビューションで使っているCライブラリであるglibcの具体的な実装であり、それらのディストリビューションがすべて「Linux」としてまとめられるためだ
libcが望むならスレッドセーフにできる
Goのような言語はこの機能を内部的に実装しているため、この制約がない
POSIX文書自体もこの制限を考慮している: “The setenv() function need not be thread-safe.”
Linuxでnethackとチェスを遊びながら育った身としては、Steamの存在自体が驚きだ
しかしSteamクライアントは本当に奇妙だ
数カ月はうまく動いていたのに、突然ゲームが起動しなくなったり何かが動かなくなったりして、全ファイルを削除したり再インストールしたりといった奇妙なことをしないと再び動作しない
筋が通っておらず、Steamクライアントが腐っていくように感じる
異なる設計原則が混ざり合った寄せ集めで、新機能はまったく別のUIとUXで継ぎ足されるだけだ
クライアントの大部分はWebViewだが、遅くてバグが多く、内部では非常に古く安全でないChromiumバージョンを使っている
ランチャーはいまだに32ビットプログラムだ
ただし、他のランチャーがさらにひどいのが悲しいところだ
むしろLinuxだけを使うようになってからは、そういうことを経験する頻度は減っている
SteamクライアントとLinuxプログラミングの両方を垣間見られる、本当に興味深い内容だ
毎リリースで詳細なリリースノートを書くのが難しいのは理解できるが、こうした作業を知ると「複数の一般的なクラッシュを修正」という表現は、とてつもない控えめな表現だ
「glibcでこの問題を解決できるなら、機能上の妥協が必要になるかもしれず、『不可能な』POSIX仕様から少し外れるオプトインの仕組みになるかもしれない。合理的な案を提案できるなら、長期的に進められる」という部分は、本当にそうしてほしい
なぜそんなに**setenv(3)**を多用するのか、本当に気になる
思い浮かぶ主な用途はexec(3)のようなものを呼び出す前に環境変数を設定することだが、ここではそういう場合ではないようだ
記事では子プロセスを起動するときにexevpeを使うとあるので、setenv(3)を使う場面として何が残るのか気になる
nm -Dでsetenv/unsetenv/putenvの使用有無を確認でき、私の~/.cargo/bin/*をざっと見ても、それらを使うプログラムが多すぎるシングルスレッドかもしれないが、今後もずっとそうだと誰が保証できるだろうか
考えてみると、シンボル一覧からpthread_createも検出できそうだ
こうしたシンボルから呼び出しツリーまで追跡する静的バイナリ解析手法もあれば面白そうだ
ただし
**environの使用有無を確認する方法は見当たらない。コンパイラはこれは何にでも置き換えられる