Typepad सेवा बंद होने और डोमेन ट्रांसफर की जानकारी

 (ttimo.typepad.com)
2 पॉइंट द्वारा GN⁺ 2024-11-12 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Typepad बंद होने के कारण मौजूदा ब्लॉग संचालकों को लॉगिन और फ़ाइल एक्सेस बंद होने की स्थिति में डोमेन और कंटेंट ट्रांसफर करना है या नहीं, यह खुद तय और व्यवस्थित करना होगा
  • सेवा समाप्ति की तारीख 30 सितंबर 2025 है, और इसके बाद अकाउंट लॉगिन की सुविधा अब उपलब्ध नहीं होगी
  • जिन ग्राहकों ने सेवा समाप्ति के बाद की अवधि तक वार्षिक शुल्क चुकाया था, उन्हें प्रोरेटेड रिफंड जारी किया गया है; अगर रिफंड विवरण में नहीं दिख रहा है, तो बैंक से पुष्टि करनी होगी
  • सभी ब्लॉग डेटा हटाए जाने वाले हैं, और व्यक्तिगत जानकारी से जुड़े प्रश्नों के अलावा एक्सेस बढ़ाने या रिकवरी का कोई रास्ता उपलब्ध नहीं कराया जाएगा
  • Typepad Domains में रजिस्टर्ड डोमेन 27 अक्टूबर 2025 को Reseller Club में ट्रांसफर किए जाएंगे, और नए प्लेटफ़ॉर्म से जोड़ने के लिए मौजूदा Typepad CNAME को हटाना होगा

सेवा समाप्ति के बाद अकाउंट और डेटा का प्रबंधन

  • Typepad की सेवा समाप्ति की तारीख 30 सितंबर 2025 है
  • समाप्ति की तारीख के बाद उपयोगकर्ता अपने अकाउंट में लॉगिन नहीं कर सकेंगे
  • जिन ग्राहकों ने समाप्ति की तारीख के बाद की अवधि तक वार्षिक सेवा शुल्क दिया था, उन्हें प्रोरेटेड रिफंड जारी किया गया है
    • अगर स्टेटमेंट में रिफंड दिखाई न दे, तो बैंक से संपर्क करना होगा
    • अगर वैध क्रेडिट कार्ड रजिस्टर्ड नहीं था, तो संभव है रिफंड प्रोसेस न हुआ हो
  • सेवा बंद होने के बाद फ़ाइल एक्सेस बंद हो जाएगी, और कोई अलग एक्सटेंशन भी उपलब्ध नहीं कराया जाएगा
  • सभी ब्लॉग डेटा हटाए जाने वाले हैं, और व्यक्तिगत जानकारी से जुड़े प्रश्न privacy@newfold.com पर भेजने होंगे

Typepad Domains ट्रांसफर और नए ब्लॉग से कनेक्शन

  • Typepad Domains, LogicBoxes का एक reseller है, और Typepad Domains में रजिस्टर्ड सभी डोमेन 27 अक्टूबर 2025 को LogicBoxes के दूसरे पार्टनर Reseller Club में ट्रांसफर कर दिए जाएंगे
  • संबंधित उपयोगकर्ताओं को Reseller Club से आगे की जानकारी वाला ईमेल मिलेगा
  • LogicBoxes से डोमेन को कहीं और ट्रांसफर करने की ज़रूरत नहीं है; इसके बाद भी Reseller Club के ज़रिए उन्हें मैनेज किया जा सकेगा
  • अगर डोमेन को किसी नई ब्लॉग सेवा या प्लेटफ़ॉर्म से जोड़ना है, तो मौजूदा Typepad की ओर इशारा करने वाला CNAME record हटाना होगा और नई सेवा की आवश्यकताओं के अनुसार सेट करना होगा
    • 27 अक्टूबर 2025 से पहले Typepad Domains में लॉगिन करके सेटिंग बदलें
    • 27 अक्टूबर 2025 के बाद Reseller Club में लॉगिन करके सेटिंग बदलें
  • अगर Typepad Domains के बजाय कोई दूसरा registrar इस्तेमाल कर रहे हैं, तब भी उसी registrar में Typepad की ओर इशारा करने वाला CNAME record हटाकर उसे नई ब्लॉग सेवा या प्लेटफ़ॉर्म की ओर सेट करना होगा
  • किसी खास ब्लॉग को ढूंढने वाले पाठकों को यह जानने के लिए कि ब्लॉग दोबारा कहाँ प्रकाशित हुआ है, संबंधित ब्लॉगर से सीधे संपर्क करना होगा
  • अतिरिक्त प्रश्न Network Solutions के फोन या चैट के जरिए पूछे जा सकते हैं

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-11-12
Hacker News की राय

  • एक patch समीक्षा में है: https://inbox.sourceware.org/libc-alpha/cover.1722193092.git...
    यह https://issues.redhat.com/browse/RHEL-42410 की वजह से शुरू हुआ था, और RHEL 9 में किसी वजह से कम दिखाई देने वाली graphics stack stability की समस्या थी
    कम-से-कम पहला patch, यानी getenv thread-safety fix, glibc 2.41 में जाने की उम्मीद है, और backport भी काफ़ी सुरक्षित लग रहा है
    setenv को संभालना अपेक्षाकृत आसान है, क्योंकि glibc पहले से ही environment variable strings को कभी free नहीं करता; मुश्किल हिस्सा concurrent unsetenv है
    snapshot approach के बिना, getenv असल में set की गई environment variable value लौटाने के बजाय null pointer लौटा सकता है
    getenv में lock लगाना नहीं चाहता, क्योंकि setenv के बिना इस्तेमाल होने वाला getenv बहुत लंबे समय से async-signal-safe माना जाता रहा है, और lock जोड़ने से applications टूटने की संभावना काफ़ी है
    environ handling को ठीक करना vfork+execve की वजह से memory leak से बचने के लिए जटिल है, इसलिए यह थोड़ा ज़्यादा विवादित है, लेकिन ये अतिरिक्त fixes graphics stack stability के लिए कम अहम हैं

    • सोच रहा हूँ कि process शुरू होने के बाद जोड़े गए variables को linked list में डालकर atomic तरीके से implement किया जाए तो कैसा रहेगा
      अगर length बहुत बढ़ जाए, तो setenv चलाने वाला thread नया hashmap बना सकता है, और पुराने pointer को नए pointer से atomically replace कर सकता है
      दो threads एक साथ rehash न करें, इसके लिए current rehash चल रहा है या नहीं यह बताने वाला atomic flag इस्तेमाल किया जा सकता है
      इस बीच अगर कोई दूसरा thread setenv call करे, तो अतिरिक्त variables list में जुड़ जाएँगे, और बाद में setenv call होने पर process हो जाएँगे
      अगर काफ़ी सारे threads तेज़ी से setenv call करें तो list अनंत तक बढ़ सकती है, लेकिन setenv अक्सर call नहीं होता, इसलिए pointer atomic replacement की simplicity valuable लगती है
    • संबंधित हो सकता है: "Setenv Is Not Thread Safe and C Doesn't Want to Fix It" (2023) -- https://www.evanjones.ca/setenv-is-not-thread-safe.html और Rust पर इसका क्या असर पड़ा, इस पर HN comment: https://news.ycombinator.com/item?id=38342642
      दशकों पुरानी पैरों तले बिछी बारूदी सुरंग जैसी चीज़ है, निराशाजनक

  • आजकल Linux पर Steam इतनी अच्छी तरह चलती है, इसके लिए सच में आभारी हूँ
    हमारे लिए इस हकीकत को बनाने में पर्दे के पीछे जो मेहनत लगती है, उसे मैं हल्के में नहीं लेता

    • उम्मीद है जल्द ही फिर से SteamOS की official release आएगी
      मैं उसी के आधार पर gaming tower बनाना चाहता हूँ
      Bazzite से compromise कर सकता हूँ, लेकिन सच कहूँ तो SteamOS ही चाहता हूँ

  • लगता है boot के समय सभी environment variables पढ़ लेना और setenv का कभी इस्तेमाल न करना best practice नहीं है क्या
    setenv का एकमात्र meaningful use नया process launch करते समय है, और उस मामले में भी current environ को clone करके नया environ बनाना और नई values update करना ज़्यादा सही लगता है
    getenv/setenv को inter-process communication messaging mechanism की तरह इस्तेमाल करना, Linux में ऐतिहासिक रूप से thread-safe न होने की समस्या के अलावा hidden memory leak की संभावना जैसे कई और मुद्दों को न्योता देता है
    लेख में जब macOS को thread-safe कहा गया है, तो लगता है ऐसी बातों को ignore किया गया है

    • नहीं। आप ऐसी library जो getenv() call करती है इस्तेमाल कर सकते हैं
      Java बताए गए तरीके से करता है, लेकिन getenv() चाहने वाली library का इस्तेमाल करने वाले JNI code में फिर भी समस्या आती है

  • असली सवाल यह है: क्या सच में ऐसा कोई case है जहाँ एक thread में setenv call किया जाए, और आप चाहते हों कि वह बदलाव पहले से मौजूद दूसरे threads पर भी लागू हो?
    फिर भी GLIBC dangerous functions को काफ़ी अच्छे से document करता है, इसलिए खुद locking या copying जोड़ना संभव है

    • दिलचस्प idea है
      ऐसे programs ज़रूर होंगे जो उम्मीद करते हैं कि setenv environ array को बदलता है, और शायद वे इसे posix_spawn/execve को pass होने वाले opaque pointer की तरह ही treat नहीं करते
      per-thread setenv करने के लिए per-thread environ variable भी चाहिए होगा
      लेकिन यह POSIX से ठीक से मेल नहीं खाता, क्योंकि environ header में declared नहीं होता और programmer को source में खुद extern char **environ; declaration लिखना होता है
      यह declaration environ के thread-local variable होने के साथ compatible नहीं है
    • अगर third-party dependency library getenv/setenv इस्तेमाल करती है, तो आप खुद locking या copying नहीं जोड़ सकते
      लेख में भी Steam client की ongoing problem के रूप में इसी हिस्से को cover किया गया है
    • वास्तव में plugin में environment variable set करता हूँ, और पहले से शुरू हो चुके worker threads बाद में वह value पढ़ते हैं
      मेरे case में worker threads सभी run queue में सो रहे होते हैं इसलिए समस्या नहीं बनती, लेकिन तकनीकी रूप से यह वही situation है जहाँ एक thread में environment variable set करके पहले से चल रहे दूसरे thread में उसे पढ़ना चाहता हूँ
    • Glibc, thread-safe putenv()/setenv()/unsetenv()/getenv() वाले Illumos को reference के रूप में देख सकता है
    • inter-process communication के लिए कहीं बेहतर तरीके बहुत हैं, इसलिए ऐसे hacky और risky getenv/setenv setup की ज़रूरत पड़नी नहीं चाहिए
      पता नहीं किस threading library में shared memory या message passing नहीं है
      शायद यह मुख्यतः ऐसी situation में होता है जहाँ main process HTTPS_PROXY जैसे variables बदलता है, और दूसरे thread में TCP socket खोलने से पहले उस variable को check करने वाली library चलती है

  • संदर्भ के लिए, Mac पर मेमोरी leak कराने का फैसला असल में करीब 26 साल पहले FreeBSD तक जाता है: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=5604
    OSX ने इसे विरासत में लिया, और Windows का setenv भी लाइसेंस की वजह से BSD lineage का हो सकता है, इसमें हैरानी नहीं
    26 साल पहले भी पता था कि यह API टूटा हुआ है, लेकिन buggy programs को और ज्यादा तोड़ देने वाली inertia की वजह से इसे ठीक नहीं किया गया
    अपने ही process के environment variables बदलने की जरूरत शायद ही पड़नी चाहिए
    child process के लिए सही exec function इस्तेमाल कर सकते हैं, और बाकी मामलों में global variable बदलकर यह उम्मीद करने के बजाय कि दूर पड़ा code उसे फिर से पढ़ेगा और सही तरह handle करेगा, साफ़ API call करनी चाहिए

    • “इसे ठीक नहीं किया जा सकता” वाली बात से मैं सिर्फ आंशिक रूप से सहमत हूं
      मौजूदा API के हिसाब से यह सही है, लेकिन API में बहुत छोटा सा बदलाव करने पर यह संभव हो जाता है
      getenv() return करने से पहले value को strdup() कर दे, और programmer इस्तेमाल के बाद memory free करे, इतना काफी है
      अगर लगे कि value बदल सकती है, तो programmer को getenv() फिर से call करना होगा, लेकिन यह एक reasonable trade-off लगता है
      यह बदलाव पुराने programs में हर बार getenv() call के बाद free() न करने पर memory leak कराएगा, लेकिन मौजूदा version भी memory leak करता है, इसलिए यह कोई निर्णायक समस्या नहीं लगती
      bonus के तौर पर नया version strdup() को mutex से wrap कर सकता है और setenv() side पर भी वैसा ही करके इसे thread-safe बना सकता है

  • सहकर्मी ने setenv को “सबसे खराब Linux API” कहा, लेकिन क्या setenv सचमुच Linux API है?
    इसे Linux ने define नहीं किया, यह POSIX में है, और Linux kernel ने भी इसे implement नहीं किया; यह पूरा user space में है

    • अगर आप Linux के लिए application software बना रहे हैं और बाकी supported platforms Windows और macOS हैं, तो हां
      लगता है मूल लेखक और उनके सहकर्मी Valve में Steam support करते हैं, इसलिए संदर्भ यही है
      उस सहकर्मी ने इसे सबसे खराब इसलिए नहीं कहा कि POSIX spec ऐसी है
      POSIX सिर्फ इतना कहता है कि इस function का thread-safe होना जरूरी नहीं है; वह इसे thread-safe बनाने से रोकता नहीं
      समस्या glibc के concrete implementation में है, जो वह C library है जिसे Valve द्वारा Steam support की जाने वाली सभी Linux distributions इस्तेमाल करती हैं, और वे distributions सब “Linux” के तहत grouped हैं
    • सख्ती से कहें तो यह GNU libc constraint है
      अगर libc चाहे तो इसे thread-safe बना सकती है
      Go जैसी languages इस capability को internally implement करती हैं, इसलिए उन पर यह constraint नहीं है
      POSIX document खुद भी इस limitation को ध्यान में रखता है: “The setenv() function need not be thread-safe.”

  • Linux पर nethack और chess खेलते हुए बड़ा होने के नाते, Steam का अस्तित्व ही मेरे लिए हैरानी की बात है
    लेकिन Steam client सच में अजीब है
    कई महीनों तक ठीक चलता है, फिर अचानक games start नहीं होते या कुछ और काम नहीं करता, और फिर सब files delete करने या reinstall जैसे अजीब काम करने पड़ते हैं ताकि फिर चले
    इसका कोई logic नहीं बनता, और Steam client सड़ता हुआ लगता है

    • Steam सबसे खराब software में से एक है, और इतनी बड़ी company के लिए honestly शर्मनाक स्तर का है
      यह अलग-अलग design principles का मिला-जुला खिचड़ी है, और नए features बस बिल्कुल अलग UI और UX के साथ ऊपर से जोड़ दिए जाते हैं
      client का ज्यादातर हिस्सा webview है, जो slow और bugs से भरा है, और internally बहुत पुराने और unsafe Chromium version का इस्तेमाल करता है
      launcher अब भी 32-bit program है
      हालांकि दुख की बात यह है कि दूसरे launchers इससे भी खराब हैं
    • मेरे अनुभव में ये सारी समस्याएं Windows वाले Steam पर भी लागू होती हैं
      उल्टा, जब से सिर्फ Linux इस्तेमाल करने लगा हूं, तब से ऐसे मामले कम झेलने पड़े हैं

  • Steam client और Linux programming, दोनों की झलक देने वाली वाकई दिलचस्प सामग्री है
    समझता हूं कि हर release के लिए detailed release notes लिखना मुश्किल है, लेकिन यह काम जानने के बाद “कई आम crashes ठीक किए” कहना जबरदस्त understatement है

  • “अगर glibc में इस समस्या को हल किया जा सकता है, तो functionality में trade-off की जरूरत पड़ सकती है, या यह ‘असंभव’ POSIX spec से थोड़ा हटने वाला opt-in mechanism हो सकता है। अगर कोई reasonable proposal दे सके, तो long term में इसे आगे बढ़ाया जा सकता है” वाला हिस्सा — सच में उम्मीद है कि वे ऐसा करें

  • सच में जानना चाहता हूं कि setenv(3) इतना ज्यादा क्यों इस्तेमाल होता है
    मेरे दिमाग में इसका मुख्य use case exec(3) जैसी चीज call करने से पहले environment variables set करना है, लेकिन यहां मामला वैसा नहीं लगता
    लेख में कहा गया है कि child processes start करते समय वे exevpe इस्तेमाल करते हैं, तो setenv(3) का इस्तेमाल किस चीज़ के लिए बचता है, यह उत्सुकता है

    • nm -D से setenv/unsetenv/putenv के इस्तेमाल की जांच की जा सकती है, और मेरे ~/.cargo/bin/* को मोटे तौर पर देखने पर भी ऐसे बहुत सारे programs दिखते हैं जो इन्हें इस्तेमाल करते हैं
      हो सकता है वे single-threaded हों, लेकिन कौन guarantee दे सकता है कि आगे भी हमेशा ऐसे ही रहेंगे
      सोचने पर, symbol list से pthread_create भी detect किया जा सकता है
      ऐसे symbols से call tree तक trace करने वाला static binary analysis तरीका भी हो तो दिलचस्प होगा
      हालांकि **environ इस्तेमाल हो रहा है या नहीं, यह जांचने का कोई तरीका नहीं दिखता। compiler इसे किसी भी चीज़ में बदल सकता है