Debian और Ubuntu के बीच मुख्य अंतर क्या हैं?

Debian और Ubuntu अलग क्यों हुए

Debian और Ubuntu 2004 में कैलेंडर के कारण अलग हुए, न कि कोड के कारण। Debian तब एक stable release जारी करता है जब उसकी release team उसे तैयार मानती है। Ubuntu ने पहले से तय तारीख पर हर छह महीने में एक नई release का वादा किया था, इसलिए यह Debian की development branch की एक copy लेता है, उसे freeze करता है, जो खराब है उसे ठीक करता है और release कर देता है।

बाईस साल बाद भी दोनों package format और उसे manage करने वाले tools साझा करते हैं, और उनके पीछे का अधिकांश packaging कार्य एक ही बार किया गया काम है। जो वे साझा नहीं करते वह है schedule, support contract, या default install में क्या होना चाहिए इस पर एक राय। जब आप सर्वर के लिए operating system चुन रहे होते हैं, तो यह एक उपयोगी अंतर है, क्योंकि यह उन अंतरों को अलग करता है जो केवल दिखावटी हैं और उन अंतरों को जो आपका एक पूरा दोपहर बर्बाद कर सकते हैं।

Ubuntu का इतिहास

Ian Murdock ने 16 August 1993 को Debian Project की स्थापना की। 2004 तक Debian स्वयंसेवकों द्वारा संचालित सबसे बड़ा distribution था, लेकिन इसकी गति धीमी थी। Debian 3.0 "woody" को 19 July 2002 को release किया गया था, और इसका उत्तराधिकारी, Debian 3.1 "sarge", 6 June 2005 तक नहीं आया। दो stable releases के बीच लगभग तीन साल का समय बीत गया। उस अंतराल के दौरान, जो कोई भी Debian सर्वर पर नवीनतम software चाहता था, उसके पास Debian की ओर से कोई समर्थित समाधान नहीं था।

April 2004 में Mark Shuttleworth ने लगभग एक दर्जन Debian developers को London स्थित अपने फ्लैट पर आमंत्रित किया ताकि एक निश्चित समय-सारणी पर आधारित Debian-आधारित system की योजना बनाई जा सके, और उन्होंने उन्हें रोजगार देने के लिए Canonical Ltd की स्थापना की। पहला release, Ubuntu 4.10 "Warty Warthog", छह महीने बाद 20 October 2004 को आया। version संख्या release की तारीख है: 4.10 का अर्थ है October 2004, और 26.04 का अर्थ है April 2026।

Ubuntu सामान्य अर्थों में कभी भी fork नहीं रहा है। एक fork codebase की एक बार प्रतिलिपि बनाता है और फिर मूल से अलग हो जाता है। Ubuntu हर cycle में Debian की प्रतिलिपि बनाता है। Packages को Debian unstable से लिया जाता है, जिसे Debian sid कहता है, और वह प्रतिलिपि प्रत्येक Ubuntu cycle के शुरुआती हफ्तों में स्वचालित रूप से refresh होती है। Import freeze के बाद, एक Ubuntu developer को प्रत्येक अतिरिक्त package को मैन्युअल रूप से लाना पड़ता है और freeze नियमों के आधार पर उसका औचित्य सिद्ध करना पड़ता है। Linux distributions का व्यापक परिवार वृक्ष में कई वास्तविक forks मौजूद हैं। यह उनमें से एक नहीं है। यह एक स्थायी downstream है।

दोनों प्रोजेक्ट्स में अभी भी क्या साझा है

साझा हिस्सा अलग हिस्से की तुलना में काफी बड़ा है। दोनों .deb पैकेज फॉर्मेट का उपयोग करते हैं, जिसमें नीचे dpkg और ऊपर apt होता है। दोनों ही Debian Policy का पालन करते हैं कि फाइलें कहाँ रखी जाएंगी और पैकेज अपनी निर्भरता (dependencies) की घोषणा कैसे करेंगे। Ubuntu का अपना डेवलपर डॉक्यूमेंटेशन बताता है कि लगभग पाँच में से चार सोर्स पैकेज Debian से बिना किसी बदलाव के कॉपी किए जाते हैं। Debian में बग ठीक करने वाला मेंटेनर आमतौर पर बिना किसी के ध्यान दिए Ubuntu उपयोगकर्ताओं के लिए भी उसे ठीक कर रहा होता है।

जहाँ Ubuntu किसी पैकेज में बदलाव करता है, वहाँ वर्ज़न स्ट्रिंग में यह स्पष्ट होता है। Debian का 1.2.3-4 बदलकर 1.2.3-4ubuntu1 हो जाता है, और यह सफिक्स स्थानीय बदलाव को दर्शाता है, जिसे दोनों प्रोजेक्ट्स 'डेल्टा' (delta) कहते हैं। Ubuntu अपने द्वारा छुए गए हर पैकेज के लिए पूरा डेल्टा प्रकाशित करता है और पैच को Debian के पैकेज ट्रैकिंग सिस्टम पर फॉरवर्ड करता है, ताकि Debian मेंटेनर देख सकें कि डाउनस्ट्रीम ने क्या किया है और यदि वे चाहें तो उसे अपना सकें।

क्या यह पर्याप्त है, इस पर 2005 से बहस चल रही है, और किसी एक पक्ष को चुनने के बजाय इस तर्क को स्पष्ट रूप से रखना उचित है। Debian की ओर से शिकायत इस बात की है कि प्रयास का लाभ किसे मिलता है: Canonical लोगों को डाउनस्ट्रीम काम करने के लिए भुगतान करता है, डाउनस्ट्रीम उपयोगकर्ताओं और ध्यान को इकट्ठा करता है, और किसी सुधार को वापस अपस्ट्रीम भेजना अतिरिक्त काम है जिसके लिए किसी को भुगतान नहीं किया जाता। Ubuntu की ओर से, छह महीने की समय-सीमा उस प्रोजेक्ट के लिए उपयुक्त नहीं है जिसकी कोई समय-सीमा नहीं है, इसलिए Debian का इंतजार करना हमेशा एक विकल्प नहीं होता। दोनों कथन सत्य हैं। किसी ने भी कभी भी पैकेजों के प्रवाह को नहीं रोका है।

तैयार होने पर रिलीज़, कैलेंडर की तारीख के अनुसार

Debian की रिलीज़ की तारीख एक परिणाम है, वादा नहीं। Debian 12 "bookworm" 10 June 2023 को और Debian 13 "trixie" 9 August 2025 को रिलीज़ हुआ था, जो लगभग दो साल के अंतराल पर है, लेकिन इस बात की कोई गारंटी नहीं है कि अगला अंतराल भी इतना ही होगा। वर्तमान testing branch का नाम "forky" है और इसकी कोई रिलीज़ तारीख नहीं है, क्योंकि Debian तब तक तारीख की घोषणा नहीं करता जब तक कि release-critical bug की संख्या यह न बता दे कि रिलीज़ संभव है।

Ubuntu की तारीख एक वादा है। हर छह महीने में एक रिलीज़ आती है, और हर चौथी रिलीज़, जो सम संख्या वाले वर्ष के April महीने में होती है, एक LTS (long term support) रिलीज़ होती है। Ubuntu 26.04 LTS "Resolute Raccoon" 23 April 2026 को निर्धारित समय पर रिलीज़ हुई थी। बीच की रिलीज़ interim रिलीज़ होती हैं और उनमें केवल नौ महीने के अपडेट मिलते हैं, यही कारण है कि उन्हें ऐसे सर्वर पर नहीं रखना चाहिए जिसे आप साल में दो बार rebuild नहीं करना चाहते। सर्वर पर Ubuntu LTS और interim रिलीज़ के बीच चुनाव उस नौ महीने की संख्या पर निर्भर करता है।

यह cadence आपके अपग्रेड कैलेंडर को निर्धारित करती है, और यह इस विभाजन का सबसे व्यावहारिक परिणाम है। Ubuntu LTS पर आपको वर्षों पहले पता होता है कि आपका अगला in-place अपग्रेड सम वर्ष के April में आएगा, इसलिए Ubuntu 24.04 से 26.04 का अपग्रेड 26.04 के अस्तित्व में आने से पहले ही प्लान किया जा सकता था। Debian पर आप freeze की घोषणाओं पर नज़र रखते हैं और जब रिलीज़ वास्तव में होती है, तब काम का शेड्यूल बनाते हैं।

LTS में क्या बदलाव आया

Ubuntu 6.06 LTS "Dapper Drake" को 1 June 2006 को release किया गया था, और यह पहला LTS था। इससे पहले, Ubuntu एक तेजी से बदलने वाला system था जो साल में दो बार खुद को replace कर लेता था, जिस पर कोई भी व्यवसाय production server नहीं बनाता। LTS ने एक महत्वपूर्ण काम किया: इसने support की समाप्ति तिथि को भविष्य में काफी आगे तय कर दिया, ताकि उसके आधार पर एक योजना बनाई जा सके। यही वह बदलाव है जिसने Ubuntu को default server distribution बनाया, और छह महीने की cadence इसे गति प्रदान करती है, क्योंकि प्रत्येक LTS को उन interim releases में पहले से परखे गए कार्यों से तैयार किया जाता है।

Debian ने दूसरी दिशा से उसी मुकाम को हासिल किया। इसका stable release पहले से ही धीमी गति से चलता था, और Debian LTS project ने Debian की अपनी security team के पीछे हटने के बाद प्रत्येक release के supported life को बढ़ा दिया।

आपको कौन सपोर्ट देता है और कितने समय के लिए

[
  {
    "label": "Debian stable",
    "support_duration": 3
  },
  {
    "label": "Debian LTS",
    "support_duration": 5
  },
  {
    "label": "Debian ELTS, paid",
    "support_duration": 10
  },
  {
    "label": "Ubuntu LTS",
    "support_duration": 5
  },
  {
    "label": "Ubuntu Pro ESM",
    "support_duration": 10
  },
  {
    "label": "Ubuntu Pro plus Legacy",
    "support_duration": 15
  }
]

Debian की अपनी सुरक्षा टीम एक स्टेबल रिलीज़ को 3 वर्षों तक कवर करती है। उसके बाद Debian LTS टीम, जिसे Debian अपनी आधिकारिक सुरक्षा और रिलीज़ टीमों के बजाय स्वयंसेवकों और कंपनियों का एक समूह बताती है, इसे 5 वर्षों तक ले जाती है। यह हस्तांतरण वर्तमान तिथियों में स्पष्ट है: bookworm 11 June 2026 को LTS में प्रवेश कर गया और 30 June 2028 तक कवर किया गया है, और bullseye अपनी LTS अवधि के अंत तक 31 August 2026 को पहुँचता है। उस बिंदु के बाद Freexian Extended LTS, या ELTS को 10 वर्षों तक बेचता है, और यह केवल उन पैकेजों के सबसेट के लिए है जिनका उपयोग उनके भुगतान करने वाले ग्राहक वास्तव में करते हैं।

एक Ubuntu LTS को Canonical से 5 वर्षों का मानक सुरक्षा रखरखाव मिलता है। एक Ubuntu Pro सब्सक्रिप्शन इसे ESM (expanded security maintenance) के माध्यम से 10 वर्षों तक बढ़ा देता है, जो main और universe दोनों पर लागू होता है, और Legacy ऐड-ऑन इसे 15 तक ले जाता है। August 2026 तक Ubuntu Pro व्यक्तिगत उपयोग के लिए पाँच मशीनों तक मुफ्त है, इसलिए एक सिंगल VPS पर दस साल का आंकड़ा बिना किसी खरीद आदेश के वास्तविक है। Pro में livepatch सर्विस भी शामिल है, जो हर kernel सुरक्षा अपडेट के लिए रीबूट किए बिना VPS पर live kernel patching का समर्थित तरीका है।

उन संख्याओं के पीछे की संरचना संख्याओं से अधिक मायने रखती है। Ubuntu के साथ आप उसी कंपनी से सपोर्ट खरीदते हैं जो डिस्ट्रीब्यूशन बनाती है। Debian के साथ ऐसी कोई कंपनी मौजूद नहीं है, इसलिए सशुल्क सपोर्ट Freexian जैसी किसी तीसरी पार्टी से, आपके होस्टिंग प्रदाता से, या आपकी अपनी टीम से आता है।

Init systems, और वह मतदान जिसने बहस समाप्त की

सबसे बड़ा तकनीकी अंतर init system था, जो kernel द्वारा शुरू की जाने वाली पहली प्रक्रिया है और उसके बाद की हर service का supervisor है। 26 October 2006 को release हुआ Ubuntu 6.10 "Edgy Eft", Upstart के साथ आया, जिसे Canonical में लिखा गया था। जब तक यह बहस चली, Debian वर्षों तक sysvinit पर ही टिका रहा। Debian की Technical Committee ने 11 February 2014 को समाप्त हुए एक मतदान के साथ इसे सुलझाया, जिसमें chair के निर्णायक मत द्वारा Debian 8 के लिए systemd के पक्ष में निर्णय लिया गया।

Ubuntu ने कुछ ही दिनों के भीतर इसका अनुसरण किया। Shuttleworth की इस निर्णय के बारे में पोस्ट, जिसका शीर्षक "Losing graciously" था, ने इसका कारण स्पष्ट रूप से बताया: Ubuntu मूल रूप से Debian परिवार का एक सदस्य है, इसलिए वह इस परिणाम को अपनाएगा। Ubuntu 15.04 ने 23 April 2015 को default रूप से systemd के साथ release किया, और Debian 8 "jessie" ने तीन दिन बाद 26 April 2015 को ऐसा ही किया।

यही एकरूपता कारण है कि अधिकांश service tutorials बिना किसी बदलाव के दोनों के बीच काम करते हैं। Unit files, systemctl और journalctl दोनों पर एक समान व्यवहार करते हैं। Debian 13 में systemd 257 और Ubuntu 26.04 LTS में systemd 259 आता है, इसलिए उनके बीच का अंतर केवल version number है, design नहीं।

Snap, और वह हिस्सा जो port नहीं होता

Ubuntu 16.04 LTS ने 2016 में snap packages पेश किए थे, और 18.04 पहला ऐसा release था जिसने कुछ default applications को snaps के रूप में deliver किया। एक snap एक self-contained bundle है जो अपनी dependencies की अपनी copy साथ रखता है, ताकि एक upstream project हर supported Ubuntu release पर एक साथ नया version push कर सके, बजाय इसके कि archive के अपडेट होने का इंतज़ार किया जाए।

किसी अन्य प्रमुख distribution द्वारा snaps को default के रूप में न अपनाने का कारण इसका format नहीं है। snapd client केवल एक store से बात करता है, जिसे Canonical संचालित करता है, और उस store का server side open source नहीं है। इसलिए, जो distribution snaps को अपनाता है, वह अपने software distribution का एक हिस्सा किसी अन्य vendor को सौंप देता है। Debian ने ऐसा नहीं किया, और यह default रूप से snapd install नहीं करता है।

यहीं पर upstream निर्देश चुपचाप काम करना बंद कर देते हैं। Certbot इसका सबसे स्पष्ट उदाहरण है: इसका अपना documentation snap से install करने की सलाह देता है और चेतावनी देता है कि distribution packages "LTS-style distributions पर जल्दी ही पुराने हो जाते हैं"। Ubuntu पर उस page का पालन करें और यह काम करता है। एक stock Debian server पर इसका पालन करें और पहले ही step में इसे चलाने के लिए कुछ नहीं मिलता। हमारा अपना Ubuntu 24.04 पर Nginx के लिए Certbot guide इसी कारण से distribution package का उपयोग करता है।

Kernels, firmware और non-free का प्रश्न

Debian का Social Contract और DFSG (Debian free software guidelines) यह निर्धारित करते हैं कि main में क्या शामिल हो सकता है। बाकी सब कुछ contrib और non-free में जाता है। Debian के अधिकांश इतिहास में, इसमें वे binary firmware blobs शामिल थे जिनकी सामान्य network और storage hardware को काम करने के लिए आवश्यकता होती है। 2022 में एक General Resolution के बाद, Debian 12 ने एक अलग non-free-firmware archive क्षेत्र जोड़ा, और आधिकारिक installer images में तब से वह firmware शामिल है।

Ubuntu ने पहले दिन से ही इसके विपरीत निर्णय लिया। इसका archive main और restricted में विभाजित है, जिसे Canonical support करता है और जिसमें proprietary drivers शामिल हैं, साथ ही universe और multiverse, जो community-maintained हैं। VPS पर इसका प्रभाव कम होता है, क्योंकि virtual hardware को लगभग किसी firmware की आवश्यकता नहीं होती। Dedicated hardware पर, यह उस network card के बीच का अंतर है जो काम करता है और जो नहीं करता।

Kernels भी इसी आधार पर अलग होते हैं। अगस्त 2026 तक, Ubuntu 26.04 LTS में Linux 7.0 और Debian 13 में Linux 6.12 शामिल है। Ubuntu अपने hardware enablement stacks के माध्यम से एक ही LTS के भीतर kernel को आगे बढ़ाता है, जबकि Debian एक stable release के पूरे जीवनकाल में एक ही kernel series रखता है और backports के माध्यम से नए संस्करण प्रदान करता है। नए का अर्थ है हाल के virtio devices और filesystems के लिए बेहतर support। पुराने का अर्थ है कि जनवरी में आपने जो व्यवहार test किया था, वही आपको दिसंबर में भी मिलेगा।

दूसरे के निर्देशों का पालन करने पर क्या खराब होता है

ज्यादातर समय, एक के लिए लिखा गया गाइड दूसरे पर भी काम करता है। विफलताएं कुछ ज्ञात स्थानों पर केंद्रित होती हैं।

• थर्ड-पार्टी apt रिपॉजिटरी प्रत्येक डिस्ट्रीब्यूशन और कोडनेम के लिए अलग से प्रकाशित की जाती हैं। एक वेंडर जो noble और jammy को सपोर्ट करता है, वह trixie के लिए कुछ भी प्रकाशित नहीं कर सकता है, और यह विफलता नीतिगत निर्णय के बजाय नेटवर्क फॉल्ट जैसी दिखती है।
• Launchpad PPA केवल विशिष्ट Ubuntu सीरीज के लिए बिल्ड होते हैं। Debian में एक PPA जोड़ने से Ubuntu के लाइब्रेरी वर्ज़न से लिंक बाइनरी फाइलें आती हैं, जो या तो संयोग से काम करती हैं या आपके सिस्टम पर Ubuntu के रनटाइम का एक बड़ा हिस्सा खींच लाती हैं।
• जो कुछ भी snapd, Ubuntu Pro सब्सक्रिप्शन, या Canonical के livepatch को मानकर चलता है, उसका Debian में कोई समकक्ष चरण नहीं होता है, इसलिए गाइड के उन हिस्सों को अनुकूलित करने के बजाय बदलना पड़ता है।
• डिफ़ॉल्ट इमेज इस बात में भिन्न होती हैं कि आप किस यूजर के रूप में लॉग इन करते हैं। Ubuntu इमेज आमतौर पर आपको sudo के साथ एक ubuntu यूजर देती हैं और कोई root पासवर्ड नहीं होता, Debian इमेज आमतौर पर आपको एक debian यूजर देती हैं, और प्रोवाइडर इमेज अलग-अलग होती हैं। SSH के बारे में कुछ भी बदलने से पहले अपना यूजर चेक करें।

जब किसी रिपॉजिटरी में आपके रिलीज के लिए कोई सूट नहीं होता है, तो apt इसके बारे में स्पष्ट होता है:

E: The repository 'https://download.example.com/linux/debian forky Release' does not have a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.

उस संदेश का मतलब है कि वेंडर ने आपके कोडनेम के लिए कभी पैकेज प्रकाशित नहीं किए। मिरर खराब नहीं है और दोबारा प्रयास करने से यह ठीक नहीं होगा। या तो वेंडर आपके रिलीज को सपोर्ट करता है या नहीं करता है।

तो आपको कौन सा चलाना चाहिए?

Ubuntu LTS तब चुनें जब आप अपग्रेड की ऐसी तारीख चाहते हैं जिसे आप वर्षों पहले कैलेंडर में मार्क कर सकें, और एक ऐसा वेंडर चाहते हैं जिससे आप सपोर्ट खरीद सकें। Debian stable तब चुनें जब आप एक छोटा डिफ़ॉल्ट इंस्टॉलेशन चाहते हैं जिसमें किसी एक कंपनी का नियंत्रण न हो, और एक ऐसा बेस जो इतना धीरे बदलता हो कि वह स्थिर रहे।

बाकी सब कुछ समान है। दोनों apt का उपयोग करते हैं, दोनों Debian Policy का पालन करते हैं, और दोनों एक ही पैकेज फॉर्मेट से एक ही एप्लिकेशन चलाते हैं, इसलिए आपके कौशल दोनों जगह काम आएंगे। यदि आप Red Hat या Fedora से आ रहे हैं, तो dnf और apt कमांड के समकक्ष दोनों दिशाओं में अनुवाद प्रदान करते हैं। और यदि आप डिप्लॉयमेंट के समय उपलब्ध अन्य इमेज के मुकाबले इनका मूल्यांकन कर रहे हैं, तो VPS के लिए ऑपरेटिंग सिस्टम चुनने की हमारी गाइड में इन्हें बाकी सूची के साथ रखा गया है।

FAQ

क्या Ubuntu, Debian का एक fork है?

नहीं। एक fork कोडबेस की एक बार कॉपी बनाता है और उसके बाद उसे अलग से मेंटेन करता है। Ubuntu हर छह महीने के चक्र की शुरुआत में Debian unstable से कोड फिर से import करता है, और Ubuntu के डेवलपर डॉक्यूमेंटेशन के अनुसार, बिना किसी बदलाव के कॉपी किए गए सोर्स पैकेज का हिस्सा लगभग पाँच में से चार है। Ubuntu, Debian का एक स्थायी downstream है, यही कारण है कि Debian पैकेजिंग का ज्ञान Ubuntu पर बिना किसी बदलाव के काम करता है, और Debian में किया गया सुधार आमतौर पर बिना किसी अतिरिक्त मेहनत के Ubuntu उपयोगकर्ताओं तक पहुँच जाता है।

क्या Ubuntu के ट्यूटोरियल Debian पर काम करते हैं?

आमतौर पर हाँ, और अपवादों का अनुमान लगाया जा सकता है। दोनों apt का उपयोग करते हैं, दोनों systemd का उपयोग करते हैं, और दोनों Debian Policy का पालन करते हैं, इसलिए पैकेज मैनेजमेंट और सर्विस मैनेजमेंट समान हैं। जो चीजें काम नहीं करतीं, वे Canonical के इंफ्रास्ट्रक्चर से जुड़ी होती हैं: snap-आधारित इंस्टॉलेशन स्टेप्स, Launchpad PPA, Ubuntu Pro कमांड्स, और वे थर्ड-पार्टी apt रिपॉजिटरी जो केवल Ubuntu कोडनेम के लिए पब्लिश की जाती हैं। जब किसी रिपॉजिटरी में आपके रिलीज़ के लिए कोई suite नहीं होता, तो apt रिपोर्ट करता है कि इसमें "Release file" नहीं है, जिसका अर्थ है कि वेंडर ने आपके कोडनेम के लिए बिल्ड नहीं किया है।

Debian और Ubuntu के सुरक्षा अपडेट कब तक चलते हैं?

एक Ubuntu LTS को Canonical से 5 वर्षों का मानक सुरक्षा मेंटेनेंस मिलता है, Ubuntu Pro सब्सक्रिप्शन के साथ 10 वर्ष, और Legacy ऐड-ऑन के साथ 15 वर्षों तक मिलता है। एक Debian stable रिलीज़ को Debian की सुरक्षा टीम से 3 वर्ष और उसके बाद आने वाली LTS अवधि को मिलाकर कुल 5 वर्ष मिलते हैं। Freexian का पेड Extended LTS 10 वर्षों तक चलता है, लेकिन केवल उन पैकेजों के लिए जिनका अनुरोध उसके ग्राहक करते हैं।

सर्वर के लिए कौन सा बेहतर है, Debian या Ubuntu?

सामान्य तौर पर कोई भी बेहतर नहीं है, और इनका वास्तविक अंतर शेड्यूल और सपोर्ट के बारे में है। Ubuntu LTS उन सर्वर के लिए उपयुक्त है जहाँ अपग्रेड की तारीख का पूर्वानुमान लगाना आवश्यक है और जहाँ सपोर्ट एक ही वेंडर से खरीदा जाना चाहिए। Debian stable उन सर्वर के लिए उपयुक्त है जहाँ छोटा डिफ़ॉल्ट इंस्टॉलेशन और बदलाव की धीमी गति, एक निश्चित कैलेंडर से अधिक महत्वपूर्ण है। वे एक ही पैकेज फॉर्मेट से एक ही सॉफ्टवेयर चलाते हैं, इसलिए चुनाव इस बात को सीमित नहीं करता कि आप क्या होस्ट कर सकते हैं।