تفاوت اصلی Debian و Ubuntu چیست؟

دلیل جدایی Debian و Ubuntu

جدایی Debian و Ubuntu در سال 2004 بر سر تقویم رخ داد، نه بر سر کد. Debian زمانی نسخه پایدار (stable) خود را منتشر می‌کند که تیم انتشار آن، آمادگی آن را تأیید کند. Ubuntu وعده داد که هر شش ماه یک‌بار در تاریخی که از پیش تعیین شده است، نسخه جدیدی منتشر کند؛ بنابراین، این توزیع یک کپی از شاخه توسعه (development branch) دبیان را برمی‌دارد، آن را فریز می‌کند، موارد معیوب را اصلاح کرده و منتشر می‌نماید.

بیست و دو سال بعد، این دو همچنان از فرمت بسته (package format) و ابزارهای مدیریت آن به‌صورت مشترک استفاده می‌کنند و بخش بزرگی از کار بسته‌بندی پشت صحنه آن‌ها، یک وظیفه واحد است که یک‌بار انجام می‌شود. آنچه آن‌ها به اشتراک نمی‌گذارند، زمان‌بندی، قرارداد پشتیبانی یا یک نظر واحد درباره محتویات نصب پیش‌فرض (default install) است. این همان تمایز مفیدی است که هنگام انتخاب سیستم‌عامل برای سرور باید در نظر بگیرید، زیرا تفاوت‌های ظاهری را از تفاوت‌هایی که ممکن است یک بعدازظهر شما را برای رفع مشکل بگیرد، جدا می‌کند.

خاستگاه Ubuntu

Ian Murdock پروژه Debian را در 16 اوت 1993 بنیان‌گذاری کرد. تا سال 2004، Debian بزرگ‌ترین توزیع تحت مدیریت داوطلبان بود، اما سرعت توسعه آن پایین بود. نسخه Debian 3.0 با نام "woody" در 19 ژوئیه 2002 منتشر شد و نسخه بعدی آن، Debian 3.1 با نام "sarge"، تا 6 ژوئن 2005 عرضه نشد. نزدیک به سه سال بین دو انتشار پایدار فاصله افتاد. در طول این وقفه، هر کسی که نرم‌افزار به‌روز روی سرور Debian می‌خواست، هیچ راهکار پشتیبانی‌شده‌ای از سوی خود Debian دریافت نمی‌کرد.

در آوریل 2004، Mark Shuttleworth حدود دوازده توسعه‌دهنده Debian را به آپارتمان خود در لندن دعوت کرد تا برای یک سیستم مبتنی بر Debian با زمان‌بندی ثابت برنامه‌ریزی کنند؛ او برای استخدام آن‌ها شرکت Canonical Ltd را تأسیس کرد. اولین نسخه، Ubuntu 4.10 با نام "Warty Warthog"، شش ماه بعد در 20 اکتبر 2004 عرضه شد. شماره نسخه نشان‌دهنده تاریخ انتشار است: 4.10 به معنای اکتبر 2004 و 26.04 به معنای آوریل 2026 است.

Ubuntu هرگز به معنای متداول کلمه، یک fork نبوده است. در یک fork، کد منبع یک‌بار کپی شده و سپس مسیر از پروژه اصلی جدا می‌شود. Ubuntu در هر چرخه، Debian را مجدداً کپی می‌کند. بسته‌ها از Debian unstable، یعنی شاخه rolling که Debian آن را sid می‌نامد، گرفته می‌شوند و این کپی در طول هفته‌های ابتدایی هر چرخه Ubuntu به‌طور خودکار به‌روزرسانی می‌شود. پس از اعمال محدودیت import، یک توسعه‌دهنده Ubuntu باید هر بسته اضافی را به‌صورت دستی منتقل کرده و آن را بر اساس قوانین محدودیت توجیه کند. درخت خانواده گسترده‌تر توزیع‌های Linux شامل forkهای واقعی بسیاری است. این مورد یکی از آن‌ها نیست. این یک downstream دائمی است.

آنچه این دو پروژه همچنان در آن اشتراک دارند

بخش مشترک بسیار بزرگ‌تر از بخش متفاوت است. هر دو از فرمت بسته .deb با dpkg در لایه زیرین و apt در لایه رویی استفاده می‌کنند و هر دو برای محل قرارگیری فایل‌ها و نحوه اعلام وابستگی‌ها در بسته‌ها، از سیاست‌های Debian پیروی می‌کنند. مستندات توسعه‌دهندگان خود Ubuntu، میزان هم‌پوشانی را تقریباً چهار از پنج بسته منبعی می‌داند که بدون هیچ تغییری از Debian کپی شده‌اند. نگهدارنده‌ای که یک باگ را در Debian رفع می‌کند، در واقع آن را برای کاربران Ubuntu نیز رفع کرده است، معمولاً بدون آنکه هیچ‌یک از طرفین متوجه این موضوع شوند.

در مواردی که Ubuntu بسته‌ای را تغییر می‌دهد، رشته نسخه این موضوع را نشان می‌دهد. 1.2.3-4 در Debian به 1.2.3-4ubuntu1 تبدیل می‌شود و این پسوند نشان‌دهنده تغییر محلی است که هر دو پروژه آن را delta می‌نامند. Ubuntu دلتای کامل را برای هر بسته‌ای که تغییر می‌دهد منتشر کرده و وصله‌ها را به سیستم ردیابی بسته Debian ارسال می‌کند؛ بنابراین نگهدارنده Debian می‌تواند ببیند که downstream چه کاری انجام داده و در صورت تمایل آن را دریافت کند.

اینکه آیا این کافی است یا خیر، از سال 2005 مورد بحث بوده است و بیان صریح این بحث ارزشمندتر از جانبداری است. از دیدگاه Debian، شکایت بر سر این است که تلاش‌ها کجا صرف می‌شود: Canonical به افرادی حقوق می‌دهد تا در downstream کار کنند، downstream کاربران و توجه را جذب می‌کند و ارسال مجدد اصلاحات به upstream یک کار اضافی است که کسی برای انجام آن حقوق نمی‌گیرد. از دیدگاه Ubuntu، مهلت شش‌ماهه با پروژه‌ای که هیچ مهلتی ندارد سازگار نیست، بنابراین انتظار برای Debian همیشه یک گزینه نیست. هر دو گزاره درست هستند. هیچ‌کدام هرگز مانع از جریان یافتن بسته‌ها نشده‌اند.

انتشار در زمان آمادگی، بر اساس تقویم

تاریخ انتشار Debian یک نتیجه است، نه یک وعده. نسخه Debian 12 با نام "bookworm" در 10 ژوئن 2023 و نسخه Debian 13 با نام "trixie" در 9 اوت 2025 منتشر شد؛ یعنی با فاصله‌ای تقریباً دو ساله، اما هیچ تضمینی وجود ندارد که فاصله بعدی نیز به همین اندازه باشد. شاخه testing فعلی "forky" نام دارد و هیچ تاریخ انتشاری برای آن تعیین نشده است، زیرا Debian تا زمانی که تعداد باگ‌های بحرانی (release-critical) اجازه ندهد، تاریخی اعلام نمی‌کند.

تاریخ انتشار Ubuntu یک وعده است. هر شش ماه یک نسخه منتشر می‌شود و هر چهارمین نسخه، در آوریل سال‌های زوج، یک نسخه LTS (پشتیبانی بلندمدت) است. نسخه Ubuntu 26.04 LTS با نام "Resolute Raccoon" طبق برنامه در 23 آوریل 2026 منتشر شد. نسخه‌های میان‌دوره‌ای که در این فواصل عرضه می‌شوند، تنها 9 ماه به‌روزرسانی دریافت می‌کنند؛ به همین دلیل است که نباید از آن‌ها روی سروری استفاده کرد که نمی‌خواهید سالی دو بار آن را بازسازی کنید. انتخاب بین Ubuntu LTS و نسخه‌های میان‌دوره‌ای برای سرور به همان عدد 9 ماه بستگی دارد.

این زمان‌بندی، تقویم ارتقای شما را تعیین می‌کند و این کاربردی‌ترین پیامد این تفاوت است. در Ubuntu LTS شما از سال‌ها قبل می‌دانید که ارتقای درجا (in-place) بعدی شما در آوریل یک سال زوج انجام می‌شود، بنابراین ارتقا از Ubuntu 24.04 به 26.04 را می‌توان حتی پیش از وجود نسخه 26.04 برنامه‌ریزی کرد. در Debian، شما اطلاعیه‌های freeze را دنبال می‌کنید و کار را زمانی که انتشار واقعاً رخ داد، زمان‌بندی می‌کنید.

تغییرات LTS

نسخه Ubuntu 6.06 LTS با نام "Dapper Drake" در تاریخ 1 June 2006 منتشر شد و نخستین نسخه LTS بود. پیش از آن، Ubuntu سیستمی با تغییرات سریع بود که هر سال دو بار جایگزین می‌شد؛ رویکردی که برای ساخت یک سرور عملیاتی در محیط‌های تجاری مناسب نبود. LTS یک کار مهم انجام داد: تاریخ پایان پشتیبانی را برای آینده تعیین کرد، آن‌قدر دور که بتوان بر اساس آن برنامه‌ریزی کرد. این همان تغییری بود که Ubuntu را به توزیع پیش‌فرض سرور تبدیل کرد. چرخه شش‌ماهه انتشار نیز سوخت این مدل است، زیرا هر نسخه LTS از دستاوردهایی تشکیل شده که پیش‌تر در نسخه‌های میانی (interim) آزموده و تثبیت شده‌اند.

Debian از مسیری متفاوت به همین نقطه رسید. نسخه stable این توزیع از قبل هم با سرعت کمی منتشر می‌شد و پروژه Debian LTS عمر پشتیبانی هر نسخه را پس از کناره‌گیری تیم امنیتی اصلی Debian، افزایش داد.

چه کسی از شما پشتیبانی می‌کند و تا چه مدت

[
  {
    "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 ژوئن 2026 وارد فاز LTS شد و تا 30 ژوئن 2028 تحت پوشش است، و bullseye در 31 اوت 2026 به پایان دوره LTS خود می‌رسد. پس از آن نقطه، Freexian سرویس Extended LTS یا ELTS را تا 10 سال ارائه می‌دهد، که تنها شامل زیرمجموعه‌ای از بسته‌هاست که مشتریانِ پرداختیِ آن‌ها واقعاً استفاده می‌کنند.

یک نسخه Ubuntu LTS به مدت 5 سال از نگهداری امنیتی استاندارد توسط Canonical بهره‌مند می‌شود. اشتراک Ubuntu Pro این مدت را از طریق ESM (نگهداری امنیتی گسترش‌یافته) برای هر دو مخزن main و universe به 10 سال افزایش می‌دهد و افزودنی Legacy آن را به 15 می‌رساند. از اوت 2026، Ubuntu Pro برای استفاده شخصی تا سقف پنج دستگاه رایگان است، بنابراین روی یک VPS تکی، عدد ده سال بدون نیاز به سفارش خرید، واقعی است. Pro همچنین سرویس livepatch را ارائه می‌دهد که مسیر پشتیبانی‌شده برای وصله زنده هسته روی یک VPS بدون نیاز به reboot برای هر به‌روزرسانی امنیتی هسته است.

ساختارِ پشتِ این اعداد، از خودِ اعداد اهمیت بیشتری دارد. در Ubuntu، شما پشتیبانی را از همان شرکتی می‌خرید که توزیع را می‌سازد. در Debian چنین شرکتی وجود ندارد، بنابراین پشتیبانی پولی از طریق شخص ثالث مانند Freexian، از طریق ارائه‌دهنده میزبانی شما، یا توسط تیم خودتان تأمین می‌شود.

سیستم‌های init و رأی‌گیری که به بحث پایان داد

تندترین اختلاف فنی بر سر سیستم init بود؛ اولین فرآیندی که هسته (kernel) اجرا می‌کند و ناظر بر تمام سرویس‌های پس از خود است. توزیع Ubuntu 6.10 با نام "Edgy Eft" که در 26 اکتبر 2006 منتشر شد، از Upstart استفاده می‌کرد که در Canonical نوشته شده بود. Debian سال‌ها در حالی که این بحث ادامه داشت، بر سر sysvinit باقی ماند. کمیته فنی Debian این موضوع را با رأی‌گیری که در 11 فوریه 2014 به پایان رسید، حل‌وفصل کرد؛ تصمیمی که با رأی قاطع رئیس کمیته به نفع systemd برای Debian 8 اتخاذ شد.

Ubuntu ظرف چند روز از این تصمیم پیروی کرد. پست Shuttleworth درباره این تصمیم با عنوان "شکست با وقار"، دلیل آن را به‌صراحت بیان کرد: Ubuntu در اصل عضوی از خانواده Debian است، بنابراین باید نتیجه را بپذیرد. Ubuntu 15.04 در 23 آوریل 2015 به‌طور پیش‌فرض با systemd عرضه شد و Debian 8 با نام "jessie" سه روز بعد در 26 آوریل 2015 همین کار را انجام داد.

این همگرایی دلیلی است که اکثر آموزش‌های سرویس‌ها بدون نیاز به ویرایش، بین این دو توزیع قابل استفاده هستند. فایل‌های unit، systemctl و journalctl در هر دو به یک شکل عمل می‌کنند. Debian 13 با systemd 257 و Ubuntu 26.04 LTS با systemd 259 عرضه می‌شوند، بنابراین آنچه آن‌ها را از هم متمایز می‌کند، شماره نسخه است، نه طراحی.

Snap و بخشی که پورت نمی‌شود

اوبونتو 16.04 LTS در سال 2016 بسته‌های snap را معرفی کرد و 18.04 اولین نسخه‌ای بود که برخی برنامه‌های پیش‌فرض را به صورت snap ارائه داد. یک snap بسته‌ای خودکفا است که کپی وابستگی‌های خود را به همراه دارد؛ بنابراین یک پروژه بالادستی (upstream) می‌تواند نسخه جدید را به جای انتظار برای به‌روزرسانی مخازن توزیع، همزمان برای تمام نسخه‌های پشتیبانی‌شده اوبونتو منتشر کند.

دلیل اینکه هیچ توزیع بزرگ دیگری snap را به عنوان پیش‌فرض نپذیرفت، فرمت آن نیست. کلاینت snapd با یک فروشگاه واحد که توسط Canonical اداره می‌شود ارتباط برقرار می‌کند و سمت سرور آن فروشگاه متن‌باز نیست. بنابراین، توزیعی که snap را می‌پذیرد، بخشی از مدیریت توزیع نرم‌افزار خود را به فروشنده‌ای دیگر واگذار می‌کند. دبیان این کار را نکرد و snapd را به صورت پیش‌فرض نصب نمی‌کند.

این همان جایی است که دستورالعمل‌های بالادستی بی‌سروصدا از کار می‌افتند. Certbot واضح‌ترین مثال است: مستندات خودِ آن توصیه می‌کند که از طریق snap نصب شود و هشدار می‌دهد که بسته‌های توزیع «معمولاً در توزیع‌های سبک LTS به‌سرعت قدیمی می‌شوند». اگر آن صفحه را در اوبونتو دنبال کنید، کار می‌کند. اما اگر آن را در یک سرور دبیان خام دنبال کنید، اولین مرحله هیچ ابزاری برای اجرا ندارد. راهنمای Certbot برای Nginx در اوبونتو 24.04 ما به همین دلیل از بسته توزیع استفاده می‌کند.

کرنل‌ها، فریم‌ور و مسئله نرم‌افزارهای غیرآزاد

قرارداد اجتماعی دبیان و DFSG (دستورالعمل‌های نرم‌افزار آزاد دبیان) تعیین می‌کنند که چه چیزی می‌تواند وارد بخش main شود. هر چیز دیگری به بخش‌های contrib و non-free می‌رود؛ در بیشتر طول عمر دبیان، این شامل فایل‌های باینری فریم‌ور (blobs) بود که سخت‌افزارهای معمولی شبکه و ذخیره‌سازی پیش از شروع به کار به آن‌ها نیاز دارند. پس از یک قطعنامه عمومی در سال 2022، دبیان 12 یک بخش جداگانه به نام non-free-firmware اضافه کرد و ایمیج‌های رسمی نصب‌کننده از آن زمان این فریم‌ورها را به همراه دارند.

اوبونتو از همان ابتدا تصمیم متفاوتی گرفت. آرشیو این توزیع به بخش‌های main و restricted تقسیم می‌شود که توسط Canonical پشتیبانی شده و شامل درایورهای اختصاصی است، به علاوه بخش‌های universe و multiverse که توسط جامعه کاربری نگهداری می‌شوند. روی یک VPS، تأثیر این موضوع ناچیز است، زیرا سخت‌افزار مجازی تقریباً به هیچ فریم‌وری نیاز ندارد. اما روی سخت‌افزار اختصاصی (dedicated)، این تفاوت بین کارت شبکه‌ای است که بالا می‌آید و کارتی که کار نمی‌کند.

کرنل‌ها نیز در همین راستا از هم متمایز می‌شوند. تا اوت 2026، اوبونتو 26.04 LTS با کرنل Linux 7.0 و دبیان 13 با Linux 6.12 عرضه می‌شوند. اوبونتو همچنین کرنل را در طول چرخه حیات یک نسخه LTS از طریق پشته‌های فعال‌سازی سخت‌افزار (HWE) به‌روزرسانی می‌کند، در حالی که دبیان یک سری کرنل را برای تمام طول عمر نسخه stable ثابت نگه می‌دارد و نسخه‌های جدیدتر را از طریق backports ارائه می‌دهد. جدیدتر بودن به معنای پشتیبانی بهتر از دستگاه‌های virtio اخیر و سیستم‌های فایل جدید است. قدیمی‌تر بودن به معنای آن است که رفتاری که در ژانویه تست کرده‌اید، در دسامبر نیز همان باقی می‌ماند.

چه چیزی هنگام پیروی از دستورالعمل‌های مربوط به توزیع دیگر از کار می‌افتد

در بیشتر مواقع، راهنمایی که برای یکی نوشته شده است روی دیگری نیز کار می‌کند. خرابی‌ها معمولاً در چند نقطه مشخص متمرکز هستند.

• مخازن apt شخص ثالث برای هر توزیع و هر نام رمز (codename) منتشر می‌شوند. فروشنده‌ای که از noble و jammy پشتیبانی می‌کند، ممکن است هیچ بسته‌ای برای trixie منتشر نکند و این خطا در ظاهر شبیه به یک مشکل شبکه به نظر برسد، در حالی که در واقع یک تصمیم سیاستی است.
• مخازن PPA در Launchpad فقط برای سری‌های خاصی از Ubuntu ساخته می‌شوند. افزودن یکی از آن‌ها به Debian باعث می‌شود باینری‌هایی که با نسخه‌های کتابخانه‌ای Ubuntu لینک شده‌اند فراخوانی شوند؛ این کار یا از روی شانس کار می‌کند یا بخش بزرگی از runtime سیستم Ubuntu را به سیستم شما وارد می‌کند.
• هر چیزی که فرض را بر وجود snapd، اشتراک Ubuntu Pro یا livepatch شرکت Canonical بگذارد، معادل مستقیمی در Debian ندارد؛ بنابراین آن بخش‌های راهنما باید جایگزین شوند، نه اینکه صرفاً تطبیق داده شوند.
• تصاویر پیش‌فرض از نظر کاربری که با آن وارد می‌شوید متفاوت هستند. تصاویر Ubuntu معمولاً یک کاربر ubuntu با دسترسی sudo و بدون رمز عبور root به شما می‌دهند، تصاویر Debian معمولاً یک کاربر debian ارائه می‌دهند و تصاویر ارائه‌دهندگان مختلف نیز متفاوت است. پیش از هر تغییری در SSH، وضعیت سیستم خود را بررسی کنید.

هنگامی که یک مخزن برای نسخه (suite) شما وجود ندارد، 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.

این پیام بدین معناست که فروشنده هرگز بسته‌هایی برای نام رمز سیستم شما منتشر نکرده است. آینه (mirror) خراب نیست و تلاش مجدد مشکل را حل نخواهد کرد. یا فروشنده از نسخه شما پشتیبانی می‌کند یا خیر.

پس کدام‌یک را باید اجرا کنید؟

زمانی که به تاریخی برای ارتقا نیاز دارید که بتوانید از سال‌ها قبل در تقویم خود ثبت کنید و به دنبال فروشنده‌ای هستید که بتوانید از او پشتیبانی بخرید، Ubuntu LTS را انتخاب کنید. زمانی که به یک نصب پیش‌فرض سبک‌تر نیاز دارید که هیچ شرکت واحدی در مسیر آن قرار نداشته باشد و به دنبال پایه‌ای هستید که آن‌قدر کند تغییر کند که خسته‌کننده باشد، Debian stable را انتخاب کنید.

همه چیزهای دیگر قابل انتقال هستند. هر دو از apt استفاده می‌کنند، هر دو از Debian Policy پیروی می‌کنند و هر دو برنامه‌های یکسانی را از فرمت بسته یکسانی اجرا می‌کنند؛ بنابراین مهارت‌های شما همراهتان منتقل می‌شوند. اگر از Red Hat یا Fedora می‌آیید، معادل‌های دستورات dnf و apt ترجمه را در هر دو جهت پوشش می‌دهند. و اگر در حال مقایسه این دو با سایر ایمیج‌های موجود در زمان deploy هستید، راهنمای ما برای انتخاب سیستم‌عامل برای VPS آن‌ها را در کنار بقیه لیست قرار می‌دهد.

FAQ

آیا Ubuntu یک انشعاب (fork) از Debian است؟

خیر. یک انشعاب، کد منبع را یک‌بار کپی کرده و از آن پس به‌طور مستقل نگهداری می‌کند. Ubuntu در ابتدای هر چرخهٔ 6 ماهه، بسته‌ها را مجدداً از شاخهٔ Debian unstable وارد می‌کند و مستندات توسعه‌دهندگان Ubuntu نشان می‌دهد که حدود 4 از 5 بستهٔ منبع، بدون هیچ تغییری کپی شده‌اند. Ubuntu یک پروژهٔ پایین‌دستی (downstream) دائمی از Debian است؛ به همین دلیل دانش بسته‌بندی Debian بدون تغییر به Ubuntu منتقل می‌شود و اصلاحاتی که در Debian انجام می‌گیرد، معمولاً بدون نیاز به کار اضافی به دست کاربران Ubuntu می‌رسد.

آیا آموزش‌های Ubuntu روی Debian کار می‌کنند؟

معمولاً بله، و موارد استثنا قابل پیش‌بینی هستند. هر دو از apt و systemd استفاده می‌کنند و هر دو از سیاست‌های Debian پیروی می‌کنند، بنابراین مدیریت بسته‌ها و سرویس‌ها یکسان است. آنچه باعث بروز مشکل می‌شود، هر چیزی است که به زیرساخت‌های Canonical وابسته باشد: مراحل نصب مبتنی بر snap، مخازن PPA در Launchpad، دستورات Ubuntu Pro و مخازن apt شخص ثالث که فقط برای نام‌های رمز (codename) خاص Ubuntu منتشر می‌شوند. وقتی یک مخزن برای نسخهٔ شما suite ندارد، apt گزارش می‌دهد که "does not have a Release file"؛ این یعنی فروشنده هرگز بسته‌ای برای نام رمز سیستم شما نساخته است.

به‌روزرسانی‌های امنیتی Debian و Ubuntu چقدر دوام دارند؟

یک نسخهٔ Ubuntu LTS به مدت 5 سال از نگهداری امنیتی استاندارد توسط Canonical برخوردار است، با اشتراک Ubuntu Pro به 10 سال می‌رسد و با افزودنی Legacy تا 15 سال قابل افزایش است. یک نسخهٔ Debian stable به مدت 3 سال توسط تیم امنیتی Debian و در مجموع 5 سال با احتساب دورهٔ LTS پس از آن پشتیبانی می‌شود. سرویس پولی Extended LTS شرکت Freexian تا 10 سال را پوشش می‌دهد، اما فقط برای بسته‌هایی که مشتریان درخواست کنند.

برای سرور، Debian بهتر است یا Ubuntu؟

هیچ‌کدام به‌طور کلی بر دیگری برتری ندارد و تفاوت اصلی در زمان‌بندی و پشتیبانی است. Ubuntu LTS برای سروری مناسب است که تاریخ ارتقای آن باید قابل پیش‌بینی باشد و نیاز به خرید پشتیبانی از یک فروشندهٔ واحد وجود داشته باشد. Debian stable برای سروری مناسب است که در آن نصب پیش‌فرض سبک‌تر و نرخ تغییرات کمتر، ارزشمندتر از یک تقویم ثابت باشد. هر دو سیستم، نرم‌افزارهای یکسانی را با فرمت بستهٔ مشابه اجرا می‌کنند، بنابراین انتخاب شما محدودیتی در آنچه می‌توانید میزبانی کنید، ایجاد نخواهد کرد.