Pengumuman penghentian layanan Typepad dan pemindahan domain

• Karena Typepad dihentikan, operator blog lama harus mengurus sendiri apakah akan memindahkan domain dan konten dalam kondisi login dan akses file telah diblokir
• Tanggal penghentian layanan adalah 30 September 2025, dan setelah itu login akun tidak lagi disediakan
• Pelanggan yang telah membayar biaya tahunan hingga melewati tanggal penghentian telah menerima pengembalian dana prorata, dan jika rincian pengembalian dana tidak terlihat, perlu memeriksa ke bank
• Semua data blog akan dihapus, dan selain pertanyaan terkait informasi pribadi, tidak tersedia perpanjangan akses atau jalur pemulihan
• Domain terdaftar Typepad Domains akan dipindahkan ke Reseller Club pada 27 Oktober 2025, dan untuk menghubungkannya ke platform baru, CNAME Typepad yang lama perlu dihapus

---

Penanganan akun dan data setelah penghentian layanan

• Tanggal penghentian layanan Typepad adalah 30 September 2025
• Setelah tanggal penghentian, pengguna tidak lagi dapat login ke akun
• Pelanggan yang telah membayar biaya layanan tahunan hingga periode setelah tanggal penghentian akan menerima pengembalian dana prorata
  • Jika pengembalian dana tidak terlihat di laporan transaksi, harus menghubungi bank
  • Jika tidak ada kartu kredit valid yang terdaftar, pengembalian dana mungkin belum diproses
• Setelah penghentian, akses file akan dihentikan, dan perpanjangan terpisah juga tidak disediakan
• Semua data blog akan dihapus, dan pertanyaan terkait informasi pribadi harus ditujukan ke [e-mail]

Pemindahan Typepad Domains dan penghubungan blog baru

• Typepad Domains adalah reseller LogicBoxes, dan semua domain yang terdaftar di Typepad Domains akan dipindahkan pada 27 Oktober 2025 ke Reseller Club, partner LogicBoxes lainnya
• Pengguna terkait akan menerima email panduan tambahan dari Reseller Club
• Tidak perlu memindahkan domain dari LogicBoxes ke tempat lain, dan setelah itu domain dapat terus dikelola melalui Reseller Club
• Untuk menghubungkan domain ke layanan atau platform blog baru, record CNAME yang mengarah ke Typepad lama harus dihapus dan dikonfigurasi sesuai persyaratan layanan baru
  • Sebelum 27 Oktober 2025, login ke Typepad Domains untuk mengaturnya
  • Setelah 27 Oktober 2025, login ke Reseller Club untuk mengaturnya
• Jika menggunakan registrar lain selain Typepad Domains, pengguna juga harus menghapus record CNAME yang mengarah ke Typepad di registrar tersebut dan mengaturnya agar mengarah ke layanan atau platform blog baru
• Pembaca yang mencari blog tertentu harus menghubungi blogger tersebut secara langsung untuk mengetahui di mana blog itu diterbitkan ulang
• Pertanyaan tambahan dapat diajukan melalui telepon atau chat di Network Solutions

[GN⁺]

Pendapat Hacker News

• Ada patch yang sedang ditinjau: https://inbox.sourceware.org/libc-alpha/cover.1722193092.git...
  Ini berawal karena https://issues.redhat.com/browse/RHEL-42410, dan merupakan masalah stabilitas stack grafis yang entah kenapa kurang terlihat di RHEL 9
  Setidaknya patch pertama, yaitu perbaikan thread-safety getenv, diharapkan masuk ke glibc 2.41, dan backport-nya juga tampaknya cukup aman
  setenv relatif mudah ditangani karena glibc memang tidak pernah membebaskan string environment variable, sedangkan yang sulit adalah unsetenv yang berjalan bersamaan
  Tanpa pendekatan snapshot, getenv bisa mengembalikan pointer null alih-alih nilai environment variable yang sebenarnya disetel
  Saya tidak ingin menaruh lock di getenv, karena getenv yang dipakai tanpa setenv sudah sejak sangat lama dianggap async-signal-safe, dan menambahkan lock berisiko merusak aplikasi
  Perbaikan penanganan environ agak lebih kontroversial karena menghindari memory leak menjadi rumit akibat vfork+execve, tetapi perbaikan tambahan ini tidak terlalu penting bagi stabilitas stack grafis

  • Saya terpikir bagaimana jika variabel yang ditambahkan setelah proses mulai dimasukkan ke linked list dan diimplementasikan secara atomik
    Jika panjangnya menjadi terlalu besar, thread yang menjalankan setenv dapat membuat hashmap baru, lalu mengganti pointer lama dengan pointer baru secara atomik
    Cukup gunakan flag atomik yang menunjukkan apakah rehash sedang berlangsung agar dua thread tidak melakukan rehash bersamaan
    Sementara itu, jika thread lain memanggil setenv, variabel tambahan ditempelkan ke list, lalu diproses pada pemanggilan setenv berikutnya
    Jika cukup banyak thread memanggil setenv dengan cepat, list bisa tumbuh tanpa batas, tetapi setenv tidak sering dipanggil, jadi kesederhanaan penggantian pointer secara atomik tampaknya sepadan
  • Mungkin terkait: "Setenv Is Not Thread Safe and C Doesn't Want to Fix It" (2023) -- https://www.evanjones.ca/setenv-is-not-thread-safe.html dan komentar HN tentang bagaimana Rust terdampak: https://news.ycombinator.com/item?id=38342642
    Ranjau yang sudah puluhan tahun ada di bawah kaki kita, sungguh membuat frustrasi

• Saya benar-benar bersyukur Steam bisa berjalan sebaik ini di Linux sekarang
  Saya tidak menganggap remeh kerja keras di balik layar untuk mewujudkan kenyataan itu bagi kita

  • Saya berharap mereka segera merilis kembali rilis resmi SteamOS
    Saya ingin membangun gaming tower berbasis itu
    Bisa saja berkompromi dengan Bazzite, tetapi jujur saya ingin memakai SteamOS

• Saya rasa praktik terbaiknya adalah membaca semua environment variable saat boot dan tidak pernah memakai setenv
  Satu-satunya tempat setenv bermakna adalah saat menjalankan proses baru, dan bahkan dalam kasus itu pun tampaknya lebih tepat membuat environ baru hasil salinan environ saat ini lalu memperbarui nilai baru di sana
  Menggunakan getenv/setenv seperti mekanisme messaging komunikasi antarproses adalah cara yang mengundang berbagai masalah, termasuk kemungkinan memory leak tersembunyi, selain masalah historis bahwa itu tidak thread-safe di Linux
  Artikel itu tampaknya mengabaikan bagian ini ketika mengatakan bahwa di macOS hal tersebut thread-safe

  • Tidak. Anda bisa saja memakai library yang memanggil getenv()
    Java melakukan seperti yang Anda katakan, tetapi masalah tetap muncul pada kode JNI yang memakai library yang menginginkan getenv()

• Pertanyaan sebenarnya adalah ini: adakah kasus ketika seseorang memanggil setenv di satu thread, lalu benar-benar ingin perubahan itu berlaku juga pada thread lain yang sudah ada?
  Meski begitu, GLIBC mendokumentasikan fungsi-fungsi berbahaya dengan cukup baik, sehingga menambahkan lock atau penyalinan sendiri masih memungkinkan

  • Ide yang menarik
    Saya yakin ada program yang mengharapkan setenv mengubah array environ, dan kemungkinan tidak memperlakukannya hanya sebagai pointer buram yang diteruskan ke posix_spawn/execve
    Untuk setenv per-thread, diperlukan juga variabel environ per-thread
    Namun ini kurang cocok dengan POSIX, karena environ tidak dideklarasikan di header dan programmer diharuskan menulis sendiri deklarasi extern char **environ; di source
    Deklarasi ini tidak kompatibel jika environ adalah variabel thread-local
  • Jika library dependensi pihak ketiga memakai getenv/setenv, Anda tidak bisa menambahkan lock atau penyalinan sendiri
    Artikel itu juga membahas bagian ini sebagai masalah yang terus terjadi pada klien Steam
  • Dalam praktiknya, plugin menetapkan environment variable, lalu worker thread yang sudah berjalan membacanya kemudian
    Dalam kasus saya, semua worker thread sedang tidur di run queue sehingga tidak menjadi masalah, tetapi secara teknis ini adalah situasi ketika satu thread menetapkan environment variable dan thread lain yang sudah berjalan ingin membacanya
  • Glibc bisa merujuk pada Illumos yang memiliki putenv()/setenv()/unsetenv()/getenv() yang thread-safe
  • Ada banyak cara yang jauh lebih baik untuk komunikasi antarproses, jadi konfigurasi getenv/setenv yang hacky dan berbahaya seperti ini seharusnya tidak diperlukan
    Saya tidak tahu library threading macam apa yang tidak punya shared memory atau message passing
    Mungkin ini lebih sering terjadi dalam situasi ketika proses utama mengubah variabel seperti HTTPS_PROXY, lalu thread lain menjalankan library yang memeriksa variabel itu sebelum membuka socket TCP

• Sebagai catatan, keputusan untuk membiarkan kebocoran memori di Mac sebenarnya dapat ditelusuri hingga FreeBSD sekitar 26 tahun lalu: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=5604
  OSX mewarisinya, dan tidak mengherankan jika setenv di Windows juga kemungkinan berasal dari garis keturunan BSD karena alasan lisensi
  Bahkan 26 tahun lalu pun sudah diketahui bahwa API ini rusak, tetapi tidak diperbaiki karena inersia yang akan membuat program-program yang sudah bug semakin rusak
  Hampir tidak semestinya ada kebutuhan untuk mengubah variabel lingkungan proses sendiri
  Untuk subproses, gunakan fungsi exec yang sesuai; selain itu, daripada mengubah variabel global lalu berharap kode yang jauh membacanya ulang dan menanganinya dengan benar, sebaiknya panggil API yang eksplisit

  • Saya hanya sebagian setuju dengan nuansa “tidak bisa diperbaiki”
    Dengan API saat ini memang benar, tetapi dengan perubahan API yang sangat kecil hal itu menjadi mungkin
    Cukup lakukan strdup() pada nilai sebelum getenv() mengembalikannya, lalu biarkan pemrogram membebaskan memorinya setelah digunakan
    Jika pemrogram menganggap nilainya bisa berubah, ia harus memanggil getenv() lagi, tetapi ini tampak seperti kompromi yang masuk akal
    Perubahan ini akan membuat program lama membocorkan memori setiap kali tidak melakukan free() setelah memanggil getenv(), tetapi versi saat ini juga membocorkan memori, jadi tampaknya bukan masalah yang menentukan
    Sebagai bonus, versi baru bisa dibuat thread-safe dengan membungkus strdup() menggunakan mutex dan menangani sisi setenv() dengan cara serupa

• Rekannya menyebut setenv sebagai “API Linux terburuk”, tetapi apakah setenv benar-benar API Linux?
  Itu bukan didefinisikan oleh Linux, ada di POSIX, dan juga bukan diimplementasikan oleh kernel Linux; semuanya berada di user space

  • Jika Anda membuat perangkat lunak aplikasi untuk Linux, sementara platform lain yang didukung adalah Windows dan macOS, maka benar
    Penulis asli dan rekannya tampaknya mendukung Steam di Valve, jadi konteksnya seperti itu
    Alasan rekan itu menyebutnya terburuk bukan karena spesifikasi POSIX
    POSIX hanya mengatakan fungsi ini tidak harus thread-safe, bukan melarangnya dibuat thread-safe
    Masalahnya adalah implementasi konkret glibc, pustaka C yang dipakai di semua distribusi Linux yang didukung Valve untuk Steam, dan semua distribusi itu dikelompokkan sebagai “Linux”
  • Secara ketat, ini adalah batasan GNU libc
    Jika libc mau, ia bisa membuatnya thread-safe
    Bahasa seperti Go mengimplementasikan fungsi ini secara internal sehingga tidak memiliki batasan seperti ini
    Dokumen POSIX sendiri juga mempertimbangkan keterbatasan ini: “The setenv() function need not be thread-safe.”

• Sebagai orang yang tumbuh dengan bermain nethack dan catur di Linux, keberadaan Steam itu sendiri terasa mengejutkan
  Namun klien Steam memang benar-benar aneh
  Selama berbulan-bulan berjalan baik, lalu tiba-tiba game tidak bisa dimulai atau ada sesuatu yang tidak berfungsi, dan harus melakukan hal-hal aneh seperti menghapus semua file atau menginstal ulang agar kembali berjalan
  Itu tidak masuk akal, dan klien Steam terasa seperti sedang membusuk

  • Steam adalah salah satu perangkat lunak terburuk, dan untuk perusahaan sebesar itu, jujur saja, tingkatnya memalukan
    Ini campuran berantakan dari prinsip desain yang saling berbeda, dan fitur baru hanya ditempelkan dengan UI dan UX yang sama sekali berbeda
    Sebagian besar kliennya adalah webview, lambat dan banyak bug, serta secara internal memakai versi Chromium yang sangat tua dan tidak aman
    Launchernya pun masih program 32-bit
    Namun yang menyedihkan adalah launcher lain bahkan lebih buruk
  • Dalam pengalaman saya, semua masalah seperti itu juga berlaku pada Steam di Windows
    Justru sejak saya hanya memakai Linux, saya lebih jarang mengalaminya

• Ini benar-benar konten menarik yang memberi gambaran tentang klien Steam sekaligus pemrograman Linux
  Saya paham sulit menulis catatan rilis yang detail setiap rilis, tetapi setelah mengetahui pekerjaan seperti ini, ungkapan “memperbaiki beberapa crash umum” adalah pernyataan yang sangat meremehkan

• Bagian yang mengatakan “jika masalah ini bisa diselesaikan di glibc, mungkin diperlukan kompromi fungsional, atau bisa berupa mekanisme opt-in yang sedikit menyimpang dari spesifikasi POSIX yang ‘mustahil’. Jika dapat mengusulkan solusi yang masuk akal, itu bisa didorong dalam jangka panjang” benar-benar saya harap terjadi

• Saya benar-benar penasaran mengapa setenv(3) begitu banyak dipakai
  Kegunaan utama yang terpikir adalah mengatur variabel lingkungan sebelum memanggil sesuatu seperti exec(3), tetapi tampaknya bukan kasus seperti itu di sini
  Tulisan itu mengatakan mereka memakai exevpe saat meluncurkan subproses, jadi saya penasaran penggunaan setenv(3) apa lagi yang tersisa

  • Dengan nm -D, kita bisa memeriksa penggunaan setenv/unsetenv/putenv, dan sekilas melihat ~/.cargo/bin/* milik saya saja, terlalu banyak program yang memakai hal-hal itu
    Mungkin saja single-threaded, tetapi siapa yang bisa menjamin akan selalu begitu ke depannya
    Kalau dipikir-pikir, pthread_create juga bisa dideteksi dari daftar simbol
    Akan menarik jika ada metode analisis biner statis yang dapat melacak dari simbol-simbol seperti ini hingga ke call tree
    Namun saya tidak melihat cara untuk memeriksa penggunaan **environ. Kompiler bisa mengubah ini menjadi apa saja