การยุติบริการ Typepad และคำแนะนำการย้ายโดเมน

 (ttimo.typepad.com)
2 คะแนน โดย GN⁺ 2024-11-12 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เนื่องจาก Typepad ยุติบริการ เจ้าของบล็อกเดิมจึงต้องจัดการตัดสินใจเรื่องการย้ายโดเมนและคอนเทนต์ด้วยตนเอง ในสภาพที่ ไม่สามารถเข้าสู่ระบบและเข้าถึงไฟล์ได้
  • วันยุติบริการคือ 30 กันยายน 2025 และหลังจากนั้นจะไม่เปิดให้เข้าสู่ระบบบัญชีอีกต่อไป
  • ลูกค้าที่ชำระค่าบริการรายปีล่วงเลยไปถึงช่วงหลังวันยุติบริการ จะได้รับ เงินคืนตามสัดส่วน และหากไม่เห็นรายการคืนเงินต้องตรวจสอบกับธนาคาร
  • ข้อมูลบล็อกทั้งหมดจะถูกลบ และนอกจากคำถามเกี่ยวกับข้อมูลส่วนบุคคลแล้ว จะไม่มีการขยายเวลาการเข้าถึงหรือช่องทางกู้คืนให้
  • โดเมนที่จดทะเบียนผ่าน Typepad Domains จะถูก ย้ายไปยัง Reseller Club ในวันที่ 27 ตุลาคม 2025 และหากต้องการเชื่อมต่อกับแพลตฟอร์มใหม่ จำเป็นต้องลบ CNAME เดิมของ Typepad ก่อน

การจัดการบัญชีและข้อมูลหลังยุติบริการ

  • วันยุติบริการ ของ Typepad คือ 30 กันยายน 2025
  • หลังวันยุติบริการ ผู้ใช้จะ ไม่สามารถเข้าสู่ระบบ บัญชีได้อีก
  • ลูกค้าที่ชำระค่าบริการรายปีครอบคลุมไปถึงช่วงหลังวันยุติบริการ จะได้รับเงินคืนตามสัดส่วน
    • หากไม่เห็นรายการคืนเงินในใบแจ้งยอด ต้องติดต่อธนาคาร
    • หากไม่มีบัตรเครดิตที่ยังใช้งานได้ลงทะเบียนไว้ อาจยังไม่ได้รับการดำเนินการคืนเงิน
  • หลังการยุติบริการ การเข้าถึงไฟล์จะถูกปิด และไม่มีการให้ ขยายเวลา เพิ่มเติม
  • ข้อมูลบล็อกทั้งหมดมีกำหนดถูกลบ และคำถามเกี่ยวกับข้อมูลส่วนบุคคลต้องติดต่อ privacy@newfold.com

การย้าย Typepad Domains และการเชื่อมต่อบล็อกใหม่

  • Typepad Domains เป็นตัวแทนจำหน่ายของ LogicBoxes และโดเมนทั้งหมดที่จดทะเบียนกับ Typepad Domains จะถูกย้ายไปยัง Reseller Club ซึ่งเป็นพาร์ตเนอร์ LogicBoxes อีกรายในวันที่ 27 ตุลาคม 2025
  • ผู้ใช้ที่เกี่ยวข้องจะได้รับอีเมลคำแนะนำเพิ่มเติมจาก Reseller Club
  • ไม่จำเป็นต้องย้ายโดเมนออกจาก LogicBoxes ไปที่อื่น และหลังจากนั้นยังสามารถจัดการต่อผ่าน Reseller Club ได้
  • หากต้องการเชื่อมต่อโดเมนกับบริการหรือแพลตฟอร์มบล็อกใหม่ ต้องลบ ระเบียน CNAME ที่ชี้ไปยัง Typepad เดิม และตั้งค่าให้ตรงตามข้อกำหนดของบริการใหม่
    • ก่อนวันที่ 27 ตุลาคม 2025 ให้เข้าสู่ระบบ Typepad Domains เพื่อตั้งค่า
    • หลังวันที่ 27 ตุลาคม 2025 ให้เข้าสู่ระบบ Reseller Club เพื่อตั้งค่า
  • หากใช้ผู้รับจดทะเบียนรายอื่นที่ไม่ใช่ Typepad Domains ก็ต้องลบระเบียน CNAME ที่ชี้ไปยัง Typepad ออกจากผู้รับจดทะเบียนนั้น และตั้งค่าให้ชี้ไปยังบริการหรือแพลตฟอร์มบล็อกใหม่
  • ผู้อ่านที่กำลังมองหาบล็อกใดบล็อกหนึ่ง ต้อง ติดต่อบล็อกเกอร์โดยตรง เพื่อสอบถามว่ามีการเผยแพร่บล็อกนั้นใหม่ไว้ที่ใด
  • หากมีคำถามเพิ่มเติม สามารถติดต่อทางโทรศัพท์หรือแชตของ Network Solutions ได้

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-11-12
ความคิดเห็นจาก 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 เพราะ getenv ที่ใช้โดยไม่มี setenv ถูกมองว่าเป็น async-signal-safe มานานมากแล้ว และการใส่ล็อกอาจทำให้แอปพลิเคชันพังได้มาก
    การแก้การจัดการ environ ยังเป็นประเด็นถกเถียงมากกว่า เพราะ vfork+execve ทำให้การหลีกเลี่ยง memory leak ซับซ้อน แต่การแก้เพิ่มเติมเหล่านี้สำคัญต่อเสถียรภาพของกราฟิกสแต็กน้อยกว่า

    • ผมคิดว่าน่าจะใส่ตัวแปรที่เพิ่มหลังจากเริ่มโปรเซสไว้ใน linked list แล้วทำให้เป็นแบบอะตอมิกได้ไหม
      ถ้าความยาวเริ่มมากเกินไป เธรดที่เรียก setenv ก็สร้างแฮชแมปใหม่ แล้วสลับพอยน์เตอร์เก่าเป็นพอยน์เตอร์ใหม่แบบอะตอมิกได้
      ใช้ atomic flag ที่บอกว่ากำลัง rehash อยู่หรือไม่ เพื่อไม่ให้สองเธรด rehash พร้อมกันก็พอ
      ระหว่างนั้นถ้าเธรดอื่นเรียก setenv ตัวแปรที่เพิ่มมาก็จะถูกต่อท้ายในลิสต์ และจะถูกจัดการเมื่อมีการเรียก setenv ครั้งถัดไป
      ถ้ามีเธรดจำนวนมากพอเรียก setenv อย่างรวดเร็ว ลิสต์อาจโตไม่สิ้นสุดได้ แต่ setenv ไม่ได้ถูกเรียกบ่อยนัก ดังนั้นความเรียบง่ายของ การสลับพอยน์เตอร์แบบอะตอมิก น่าจะคุ้มค่า
    • อาจเกี่ยวข้อง: "Setenv Is Not Thread Safe and C Doesn't Want to Fix It" (2023) -- https://www.evanjones.ca/setenv-is-not-thread-safe.html และคอมเมนต์ HN เกี่ยวกับผลกระทบต่อ Rust: https://news.ycombinator.com/item?id=38342642
      กับดักใต้เท้าที่มีมาหลายสิบปีแบบนี้ น่าหงุดหงิดจริง ๆ

  • ทุกวันนี้ Steam บน Linux ทำงานได้ดีขนาดนี้ รู้สึกขอบคุณจริง ๆ
    ไม่ได้มองว่าความพยายามเบื้องหลังที่ทำให้สิ่งนี้เกิดขึ้นเพื่อพวกเราเป็นเรื่องที่ควรได้มาอยู่แล้ว

    • หวังว่าจะออก SteamOS รุ่นเสถียรอย่างเป็นทางการ อีกครั้งเร็ว ๆ นี้
      อยากสร้างเกมมิงทาวเวอร์บนฐานนั้น
      อาจยอมใช้ Bazzite แทนได้ แต่พูดตรง ๆ คืออยากใช้ SteamOS

  • ผมคิดว่าการอ่านตัวแปรสภาพแวดล้อมทั้งหมดตอนบูต และ ไม่ใช้ setenv เลย น่าจะเป็นแนวทางปฏิบัติที่ดีไม่ใช่หรือ
    ที่เดียวที่ setenv มีความหมายจริง ๆ คือเวลาสร้างโปรเซสใหม่ และแม้ในกรณีนั้น ก็ดูเหมือนควรสร้าง environ ใหม่ที่คัดลอก environ ปัจจุบัน แล้วอัปเดตค่าใหม่ลงไปมากกว่า
    การใช้ getenv/setenv เหมือนเป็นกลไกส่งข้อความสื่อสารระหว่างโปรเซส เป็นวิธีที่ก่อให้เกิดปัญหาหลายอย่าง เช่นโอกาส memory leak ที่ซ่อนอยู่ นอกเหนือจากปัญหาที่ใน Linux เดิมไม่ thread-safe อยู่แล้ว
    บทความดูเหมือนจะมองข้ามประเด็นพวกนี้ตอนบอกว่า macOS thread-safe

    • ไม่ใช่หรอก คุณอาจต้องใช้ ไลบรารีที่เรียก getenv()
      Java ทำตามวิธีที่พูดมา แต่ในโค้ด JNI ที่ใช้ไลบรารีซึ่งต้องการ getenv() ก็ยังเกิดปัญหาได้อยู่ดี

  • คำถามจริง ๆ คือ: มีกรณีที่เราต้องการให้การเรียก setenv ในเธรดหนึ่ง แล้วการเปลี่ยนแปลงนั้นมีผลกับเธรดอื่นที่มีอยู่แล้วจริง ๆ ไหม
    ถึงอย่างนั้น GLIBC ก็จัดทำเอกสารของฟังก์ชันอันตรายไว้ค่อนข้างดี ดังนั้นการเพิ่ม ล็อกหรือการคัดลอก เองก็ทำได้

    • เป็นไอเดียที่น่าสนใจ
      น่าจะมีโปรแกรมที่คาดหวังว่า setenv จะเปลี่ยนอาร์เรย์ environ แน่นอน และมีความเป็นไปได้ว่าจะไม่ได้มองมันเป็นแค่พอยน์เตอร์ทึบที่ส่งให้ posix_spawn/execve เท่านั้น
      ถ้าจะทำ setenv แยกตามเธรด ก็ต้องมี ตัวแปร environ แยกตามเธรด ด้วย
      แต่มันไม่ค่อยเข้ากับ POSIX เพราะ environ ไม่ได้ถูกประกาศไว้ในเฮดเดอร์ และโปรแกรมเมอร์ต้องเขียนประกาศ extern char **environ; เองในซอร์ส
      การประกาศนี้ไม่เข้ากันกับกรณีที่ environ เป็นตัวแปร thread-local
    • ถ้าไลบรารี dependency ของบุคคลที่สามใช้ getenv/setenv คุณก็เพิ่มล็อกหรือการคัดลอกเองไม่ได้
      ในบทความก็พูดถึงประเด็นนี้ในฐานะปัญหาต่อเนื่องของไคลเอนต์ Steam
    • ในทางปฏิบัติ มีการตั้งค่าตัวแปรสภาพแวดล้อมในปลั๊กอิน แล้วให้เธรด worker ที่เริ่มไปแล้วมาอ่านค่านั้นในภายหลัง
      กรณีของผม เธรด worker ทั้งหมดหลับอยู่ในคิวรัน จึงไม่เป็นปัญหา แต่ในเชิงเทคนิคก็คือสถานการณ์ที่ตั้งค่าตัวแปรสภาพแวดล้อมในเธรดหนึ่ง แล้วอยากให้อีกเธรดที่กำลังรันอยู่มาอ่าน
    • Glibc สามารถอ้างอิง Illumos ซึ่งมี putenv()/setenv()/unsetenv()/getenv() ที่ thread-safe ได้
    • สำหรับการสื่อสารระหว่างโปรเซส มีวิธีที่ดีกว่านี้มากมาย จึงไม่น่ามีความจำเป็นต้องใช้โครงสร้าง getenv/setenv ที่แฮ็กและอันตรายแบบนี้
      ไม่แน่ใจว่าไลบรารีเธรดแบบไหนถึงไม่มี shared memory หรือการส่งข้อความ
      คงมักเกิดในสถานการณ์ทำนองที่โปรเซสหลักเปลี่ยนตัวแปรอย่าง HTTPS_PROXY แล้วในเธรดอื่นรันไลบรารีที่ตรวจตัวแปรนั้นก่อนเปิด TCP socket

  • สำหรับข้อมูลอ้างอิง การตัดสินใจให้ Mac ทำให้เกิด memory leak นั้นจริง ๆ แล้วย้อนกลับไปได้ถึง FreeBSD เมื่อประมาณ 26 ปีก่อน: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=5604
    OSX รับช่วงสิ่งนี้มา และก็ไม่น่าแปลกใจหาก setenv ของ Windows จะอยู่ในสายตระกูล BSD ด้วยเหตุผลด้านไลเซนส์
    แม้เมื่อ 26 ปีก่อนก็รู้กันแล้วว่า API นี้พัง แต่ไม่ได้แก้เพราะแรงเฉื่อยที่ว่าการแก้จะทำให้โปรแกรมที่มีบั๊กพังหนักขึ้น
    โดยทั่วไปแทบไม่ควรมีความจำเป็นต้องเปลี่ยน environment variables ของ process ตัวเอง
    สำหรับ subprocess ก็ใช้ฟังก์ชัน exec ที่เหมาะสมได้ ส่วนกรณีอื่นควรเรียก API ที่ชัดเจน แทนที่จะเปลี่ยน global variable แล้วหวังว่าโค้ดที่อยู่ไกลออกไปจะอ่านซ้ำและจัดการได้ถูกต้อง

    • เห็นด้วยเพียงบางส่วนกับความรู้สึกที่ว่า “แก้ไม่ได้”
      ถ้าใช้ API ปัจจุบันก็ใช่ แต่ถ้าเปลี่ยน API เพียงเล็กน้อยก็ทำได้
      ให้ getenv() ทำ strdup() ค่าก่อนคืนค่า แล้วให้โปรแกรมเมอร์ปล่อยหน่วยความจำหลังใช้งานก็พอ
      ถ้าคิดว่าค่าอาจเปลี่ยนได้ โปรแกรมเมอร์ก็ต้องเรียก getenv() ใหม่ แต่ดูเป็นการประนีประนอมที่สมเหตุสมผล
      การเปลี่ยนนี้จะทำให้โปรแกรมเก่า leak memory ทุกครั้งที่ไม่เรียก free() หลังเรียก getenv() แต่เวอร์ชันปัจจุบันก็ leak memory อยู่แล้ว จึงดูไม่ใช่ปัญหาชี้ขาด
      แถมเวอร์ชันใหม่ยังทำให้ thread-safe ได้ด้วย โดยครอบ strdup() ด้วย mutex และจัดการฝั่ง setenv() ในลักษณะคล้ายกัน

  • มีคนบอกว่าเพื่อนร่วมงานเรียก setenv ว่า “Linux API ที่แย่ที่สุด” แต่ setenv เป็น Linux API จริงหรือ?
    มันไม่ได้ถูกนิยามโดย Linux แต่อยู่ใน POSIX และก็ไม่ได้ถูก implement โดย Linux kernel ทุกอย่างอยู่ใน user space

    • ถ้ากำลังทำ application software สำหรับ Linux และแพลตฟอร์มอื่นที่รองรับคือ Windows กับ macOS ก็ถือว่าใช่
      ดูเหมือนผู้เขียนต้นฉบับและเพื่อนร่วมงานจะทำงานที่ Valve เพื่อ support Steam ดังนั้นบริบทจึงเป็นแบบนั้น
      เหตุผลที่เพื่อนร่วมงานคนนั้นเรียกว่าแย่ที่สุดไม่ได้มาจากข้อกำหนด POSIX
      POSIX แค่บอกว่าฟังก์ชันนี้ไม่จำเป็นต้อง thread-safe ไม่ได้ห้ามทำให้ thread-safe
      ปัญหาคือ implementation เฉพาะของ glibc ซึ่งเป็น C library ที่ใช้ในทุก Linux distribution ที่ Valve support สำหรับ Steam และ distribution เหล่านั้นถูกเหมารวมเรียกว่า “Linux”
    • พูดอย่างเคร่งครัดคือเป็น ข้อจำกัดของ GNU libc
      ถ้า libc ต้องการ ก็สามารถทำให้ thread-safe ได้
      ภาษาอย่าง Go implement ความสามารถนี้ภายในเอง จึงไม่มีข้อจำกัดแบบนี้
      เอกสาร POSIX เองก็พิจารณาข้อจำกัดนี้ไว้: “The setenv() function need not be thread-safe.”

  • ในฐานะคนที่โตมากับการเล่น nethack และหมากรุกบน Linux การมีอยู่ของ Steam เอง ก็น่าประหลาดใจแล้ว
    แต่ Steam client นั้นแปลกจริง ๆ
    ใช้งานได้ดีอยู่หลายเดือน แล้วจู่ ๆ เกมก็เปิดไม่ติดหรือบางอย่างไม่ทำงาน ต้องทำเรื่องประหลาดอย่างลบไฟล์ทั้งหมดหรือติดตั้งใหม่จึงกลับมาใช้ได้
    มันไม่สมเหตุสมผล และรู้สึกเหมือน Steam client กำลังผุพังลงเรื่อย ๆ

    • Steam เป็นหนึ่งในซอฟต์แวร์ที่แย่ที่สุด และพูดตรง ๆ ว่าน่าอายสำหรับบริษัทใหญ่ขนาดนี้
      มันเป็นของผสมปะปนของหลักการออกแบบที่ต่างกัน และฟีเจอร์ใหม่ ๆ ก็แค่ถูกแปะเพิ่มเข้ามาด้วย UI และ UX ที่ต่างไปโดยสิ้นเชิง
      client ส่วนใหญ่เป็น webview ซึ่งช้าและมีบั๊กมาก อีกทั้งภายในยังใช้ Chromium เวอร์ชันที่เก่ามากและไม่ปลอดภัย
      launcher ก็ยังเป็นโปรแกรม 32-bit อยู่
      แต่สิ่งที่น่าเศร้าคือ launcher อื่น ๆ แย่กว่านี้อีก
    • จากประสบการณ์ของฉัน ปัญหาแบบนั้นเกิดกับ Steam บน Windows ทั้งหมดเช่นกัน
      กลับกัน หลังจากใช้แต่ Linux ฉันเจอเรื่องพวกนั้นน้อยลงด้วยซ้ำ

  • เป็นเนื้อหาที่น่าสนใจมาก เพราะทำให้เห็นทั้ง Steam client และการเขียนโปรแกรมบน Linux
    เข้าใจว่าเป็นเรื่องยากที่จะเขียน release notes อย่างละเอียดในทุก release แต่พอรู้ว่ามีงานแบบนี้อยู่เบื้องหลัง คำว่า “แก้ crash ทั่วไปหลายรายการ” จึงเป็นการ พูดน้อยเกินจริง อย่างมาก

  • ส่วนที่ว่า “หากแก้ปัญหานี้ใน glibc ได้ อาจต้องมีการประนีประนอมด้านฟังก์ชัน หรืออาจเป็นกลไก opt-in ที่เบี่ยงออกจากข้อกำหนด POSIX ที่ ‘เป็นไปไม่ได้’ เล็กน้อย หากเสนอแนวทางที่สมเหตุสมผลได้ ก็อาจผลักดันระยะยาวได้” นั้น อยากให้ทำแบบนั้นจริง ๆ

  • สงสัยจริง ๆ ว่าทำไมถึงใช้ setenv(3) กันมากขนาดนั้น
    การใช้งานหลักที่นึกออกคือการตั้ง environment variable ก่อนเรียกอะไรอย่าง exec(3) แต่ในกรณีนี้ดูเหมือนไม่ใช่แบบนั้น
    ในบทความบอกว่าเวลาเปิด subprocess ใช้ execvpe จึงสงสัยว่ายังเหลือกรณีไหนที่ต้องใช้ setenv(3) อีก

    • สามารถใช้ nm -D ตรวจว่ามีการใช้ setenv/unsetenv/putenv ได้ และแค่ดู ~/.cargo/bin/* ของฉันแบบคร่าว ๆ ก็มีโปรแกรมที่ใช้สิ่งเหล่านี้มากเกินไปแล้ว
      อาจเป็นแบบ single-threaded ก็ได้ แต่ใครจะรับประกันได้ว่าจะเป็นแบบนั้นต่อไปเสมอ
      คิดดูแล้วอาจตรวจจับ pthread_create จากรายการ symbol ได้ด้วย
      ถ้ามีวิธี static binary analysis ที่ตามจาก symbol เหล่านี้ไปถึง call tree ได้ก็น่าสนใจ
      แต่ดูไม่เห็นวิธีตรวจว่ามีการใช้ **environ หรือไม่ compiler อาจเปลี่ยนสิ่งนี้เป็นอะไรก็ได้