وقتی صحبت از توزیع‌های لینوکس (Linux Distros) می‌شود، قدیمی بودن بسته‌های نرم‌افزاری دبیان (Debian) معمولاً به عنوان نقطه‌ضعف آن در مقایسه با رقبا مطرح می‌شود. اما یک کاربر که دبیان را برای سرور خانگی خود انتخاب کرده، دقیقاً همین نسخه‌های چندساله را دلیل اصلی این انتخاب می‌داند. او دبیان را به صورت نصب مستقیم روی سخت‌افزار (Bare-Metal) روی یک لپ‌تاپ تجاری قدیمی اجرا می‌کند و بیش از ۲۰ سرویس و استک (Stack) روی آن دارد؛ به گفته او، دبیان کم‌دغدغه‌ترین بخش این هوم‌لب (Homelab) است.
معنای واقعی «قدیمی» در دبیان استیبل
شماره نسخه یک چیز می‌گوید و گزارش وصله‌ها چیز دیگری. نویسنده دبیان ۱۲.۱۵ بوک‌ورم (Debian 12.15 Bookworm) را روی یک لپ‌تاپ تجاری ۸ ساله اجرا می‌کند که آن را به سرور خانگی تبدیل کرده است. در زمان نگارش، کرنل (Kernel) شاخه ۶.۱ در بالادست (Upstream) به نسخه ۶.۱.۱۸۹ رسیده بود، اما نسخه او ۶.۱.۱۸۷-۱ بود؛ همچنین شاخه پایدار بالادست روی ۷.۲.۹ قرار داشت، در حالی که او همچنان از ۶.۱ استفاده می‌کرد. این موضوع نه تصادفی است و نه نشانه سهل‌انگاری؛ بلکه شیوه کار دبیان استیبل (Debian Stable) در عمل است.
در مدل توقف یا فریز (Freeze Model) دبیان، هنگام انتشار یک نسخه، نسخه بسته‌ها قفل می‌شود و برای رفع مشکلات آینده معمولاً شماره نسخه بالا نمی‌رود؛ در عوض، وصله‌ها به همان نسخه پایه بازگردانی (Backport) می‌شوند. بنابراین شماره نسخه، نسخه پایه را نشان می‌دهد، نه تعداد وصله‌های اعمال‌شده.
نمونه روشن این رفتار، OpenSSH است. دبیان بوک‌ورم در اوایل ۲۰۲۳ منتشر شد و OpenSSH در آن زمان نسخه 9.2p1 بود. نویسنده دبیان را در سال ۲۰۲۵ نصب کرد و بسته OpenSSH همچنان 9.2p1 است، هرچند بالادست اکنون به 10.6 رسیده است. با این حال، این بسته بدون وصله نمانده؛ همان نسخه پایه با ده‌ها به‌روزرسانی روی آن بازبینی شده و در مورد او از deb12u1 به deb12u10 رسیده است. این بازگردانی‌ها آسیب‌پذیری‌هایی مانند regreSSHion (CVE-2024-6387)، Terrapin (CVE-2023-48795) و سه CVE دیگر را برطرف کرده‌اند.
این رفتار فقط به OpenSSH محدود نیست. برای نمونه، Git در دبیان نسخه 2.39.5 و در بالادست نسخه 2.56.0 است. اما این مدل محدودیت هم دارد. برخی نرم‌افزارها یا بیش از حد قدیمی‌اند یا تغییراتشان آن‌قدر زیاد است که بازگردانی و نگهداری آنها در پایه استیبل دشوار می‌شود. ابزار خود دبیان به نام check-support-status چند بسته مانند webkit2gtk را علامت‌گذاری کرد که در بوک‌ورم نگهداری و بازگردانی نمی‌شوند.
نویسنده هنگام نوشتن مقاله، صدها به‌روزرسانی معوق داشت؛ اما این به معنای کوتاهی دبیان نیست، بلکه خودش از به‌روزرسانی‌ها عقب مانده بود. یک فرمان ساده full-upgrade همه را انجام داد.
دبیان استیبل چه چیزی به هوم‌لب او داد
به گفته نویسنده، هر لایه‌ای بالاتر از دبیان برایش خراب شده، اما خود دبیان نه. او بیش از ۲۰ استک روی این ماشین اجرا می‌کند که بیشترشان با Portainer مستقر شده‌اند و چند مورد مستقیماً روی میزبان (Host) اجرا می‌شوند. او معتقد است خودمیزبانی (Self-Hosting) دو بخش دارد: استقرار کانتینر (Container) و نگهداری آن.
در یک سال گذشته، بیشتر این استک‌ها در نقطه‌ای خراب شده‌اند و او آنها را تعمیر کرده است، اما همه این مشکلات در لایه‌های بالای سیستم‌عامل رخ داده‌اند، نه در خود دبیان. او ادعا نمی‌کند دبیان خراب‌نشدنی است، اما در تجربه او تقریباً همه عیب‌یابی‌ها در لایه کانتینر انجام شده است.
در زمان بررسی، حدود ۲۲۸ به‌روزرسانی معوق وجود داشت که قدیمی‌ترین آنها چند ماه قدمت داشت، اما هیچ مشکلی ایجاد نکرده بودند. آخرین مشکلاتی که او به یاد می‌آورد عبارت بودند از خرابی به‌روزرسانی خودکار Watchtower، یتیم شدن یک والیوم (Volume) در به‌روزرسانی Portainer، بازنویسی فایل resolv.conf توسط NetBird و جدا شدن AdGuard Home از بریج (Bridge) خود. همه این موارد بدون دست زدن فنی به خود دبیان تشخیص داده و رفع شدند.
برای مثال، Watchtower هنگام به‌روزرسانی کانتینرهای Immich و Nextcloud هیچ ارتباطی با دبیان نداشت. درباره NetBird هم ممکن است ارتباطی با میزبان وجود داشته باشد، چون هنگام تغییر فایل‌ها، عملیات apt و git موقتاً مختل شد؛ اما NetBird یک بسته شخص ثالث از مخزن خودش است و مسئول تغییر resolver است، نه دبیان. نکته اصلی این است که همه آن بیش از ۲۰ استک حتی پس از به‌روزرسانی ۲۲۸ بسته، نصب کرنل جدید و ریبوت، دوباره آنلاین شدند.
جایی که نرم‌افزار قدیمی آزار می‌دهد
به گفته نویسنده، نرم‌افزار قدیمی مشکل اصلی نبود؛ عادت‌های خودش مشکل بود. او هزینه سنگینی بابت قدیمی بودن بسته‌ها نپرداخت و ماشینش به خاطر یک بسته باستانی از کار نیفتاد. یک هزینه کوچک اما بر عهده خودش بود: اجازه داد ۲۲۸ به‌روزرسانی روی هم انبار شود. دو دلیل داشت: نخست اینکه به دنبال آن به‌روزرسانی‌ها نرفت و دوم اینکه هرگز unattended-upgrades را نصب نکرد. سیستم عادی کار می‌کرد و توجهی طلب نمی‌کرد؛ به همین دلیل او بررسی آن را متوقف کرده بود.
بسته‌های پشتیبانی‌نشده می‌توانند سیستم را در معرض خطر قرار دهند. اگر دبیان دیگر نتواند نرم‌افزاری را نگهداری کند، مسئولیت حذف، جایگزینی یا پذیرش ریسک آن بر عهده کاربر است. برای نمونه، همان ابزار check-support-status چند بسته را به عنوان پایان پشتیبانی علامت زد، مانند libmfx1 (۲۰۲۴-۱۱-۲۱) و libmbedcrypto7 (۲۰۲۶-۰۶-۱۲). این به معنای آن نیست که چون دبیان پشتیبانی آنها را پایان داده، آن کتابخانه‌ها ذاتاً آسیب‌پذیر شده‌اند. ابزار فقط آن دو مورد پایان‌یافته را علامت زده بود و بقیه کارها مانند بررسی تغییرات (Changelog) و تصمیم‌گیری بر عهده خود کاربر است. مدل فریز یک مزیت عالی برای دبیان است، اما وعده نگهداری بی‌پایان نمی‌دهد.
سرور او یک نصب مینیمال و بدون رابط گرافیکی (Headless) نیست. چون لپ‌تاپ صفحه‌نمایش سالمی دارد، او دسکتاپ کامل XFCE را روی آن نصب کرده است. بسته‌هایی که به صورت دستی نصب شده‌اند، مانند task-desktop، task-xfce-desktop، task-laptop و task-ssh-server، انتخاب خود او هستند، نه دبیان. بهترین عادت این است که بسته‌های خارجی را هرچه سریع‌تر به‌روز نگه دارد و بگذارد دبیان استیبل کاری را انجام دهد که در آن بهترین است.
بخش خسته‌کننده یک انتخاب است
هرچند دبیان ۱۳ تریکسی (Debian 13 Trixie) از قبل در دسترس است، نویسنده برنامه فوری برای ارتقا ندارد، چون می‌داند بوک‌ورم تا اواسط ۲۰۲۸ تحت پشتیبانی بلندمدت (LTS) است. به نظر او، سن نرم‌افزاری دبیان قابل قبول است، چون اجازه می‌دهد خودش تصمیم بگیرد کدام بخش هوم‌لب را متحرک نگه دارد و کدام بخش را ثابت. تغییرات کندتر زندگی را آسان‌تر می‌کند و او می‌تواند روی لایه کانتینر هوم‌لب تمرکز کند. او می‌خواهد بیش از ۲۰ استک، بخش جذاب ماجرا باشند، نه سیستم‌عامل زیرین.