معایب systemd - پارسا رنجبر

انتقادات از systemd را می‌توان در چند دسته اصلی خلاصه کرد:

۱. نقض فلسفه “UNIX” (کاری را انجام بده که خوب انجام می‌دهی)

بزرگی و پیچیدگی: systemd فقط یک سیستم init ساده نیست. این یک مجموعه عظیم از بیش از ۷۰ باینری است که بسیاری از جنبه‌های سیستم را مدیریت می‌کند: لاگ‌ها (journald)، شبکه (networkd)، کاربران (logind)، دی‌ان‌اس (resolved) و غیره. منتقدان معتقدند این طراحی، برخلاف فلسفه سنتی یونیکس است که می‌گوید “هر برنامه یک کار را به خوبی انجام دهد” و برنامه‌های کوچک و مستقل با هم کار کنند.
اتکاپذیری بیش از حد: از آنجایی که این اجزا به هم وابسته هستند، یک باگ در یک بخش می‌تواند کل سیستم را تحت تاثیر قرار دهد. در سیستم‌های سنتی، اگر سرویس syslog خراب می‌شد، سیستم همچنان می‌توانست بوت شود و سرویس‌های دیگر را اجرا کند.

۲. پیچیدگی بیش از حد

پیکربندی سخت: فایل‌های واحد سرویس (service unit) systemd نسبت به اسکریپت‌های ساده Init Script در /etc/init.d/ پیچیده‌تر هستند. اگرچه قوی‌تر و یکپارچه‌ترند، اما یادگیری و دیباگ کردن آن‌ها برای کاربران تازه‌کار دشوارتر است.
لاگ‌های باینری: سرویس journald که مسئول مدیریت لاگ‌هاست، به طور پیش‌فرض لاگ‌ها را در یک فایل باینری ذخیره می‌کند. اگرچه این کار مزایایی مانند نمایه‌سازی سریع و ذخیره‌سازی ساختاریافته دارد، اما برای خواندن لاگ‌ها باید از دستور journalctl استفاده کنید. این موضوع، کار با ابزارهای سنتی و ساده مانند grep و tail روی فایل‌های متنی ساده را غیرممکن می‌سازد (مگر اینکه journald را برای ذخیره‌سازی متنی پیکربندی کنید).

۳. مسائل امنیتی و اشکالات نرم‌افزاری (Bugs)

سطح حمله وسیع: به دلیل یکپارچه بودن و دسترسی گسترده به بخش‌های مختلف هسته و سیستم، یک آسیب‌پذیری در systemd می‌تواند عواقب بسیار جدی‌تری داشته باشد.
تاریخچه باگ‌ها: systemd در گذشته باگ‌های بحرانی داشته که منجر به قفل کردن یا بوت نشدن سیستم می‌شد. این موضوع اعتماد برخی از مدیران سیستم قدیمی را که به پایدار و قابل پیش‌بینی بودن سیستم‌های مبتنی بر SysVinit عادت داشتند، سلب کرد.

۴. توسعه بسیار سریع و “تجمیع‌طلبی” (Bloat)

اضافه شدن مداوم قابلیت‌های جدید: systemd به طور فعال در حال توسعه است و قابلیت‌های جدیدی را به حوزه‌هایی اضافه می‌کند که قبلاً توسط ابزارهای مستقل دیگر پوشش داده می‌شد (مثلاً مدیریت بوت‌لودر). منتقدان این را نوعی “تجمیع‌طلبی” می‌دانند که اکوسیستم نرم‌افزارهای مستقل را تضعیف می‌کند.

۵. مسائل فنی-فلسفی

وابستگی به لینوکس: systemd به شدت به ویژگی‌های خاص لینوکس (مانند cgroups) وابسته است. این کار، پورت کردن آن به سایر سیستم‌عامل‌های شبه یونیکس (مانند FreeBSD یا OpenBSD) را بسیار دشوار یا غیرممکن می‌کند. این موضوع برای جامعه‌ای که به چندسکویی بودن و انتخاب ارزش می‌دهد، یک نقطه ضعف بزرگ محسوب می‌شود.

جمع‌بندی

systemd یک سیستم بسیار قدرتمند، کارآمد و از نظر فنی پیشرفته است که مشکلات واقعی سیستم‌های init قدیمی را حل کرده و به همین دلیل است که تقریباً بر تمام توزیع‌های اصلی لینوکس مسلط شده است.

انتقادات اصلی بیشتر حول محور فلسفه طراحی، سادگی، ماژولاریتی و آزادی انتخاب می‌چرخد تا “بد کار کردن” آن.

در نهایت، این بحث یک “ترجیح شخصی” و “فلسفی” است:

اگر شما یک سیستم‌ادمین هستید که به سادگی، شفافیت، و کنترل دقیق بر روی هر جزء سیستم اهمیت می‌دهید، ممکن است از systemd بیزار باشید و جایگزین‌هایی مانند OpenRC (مورد استفاده در Gentoo) یا S6 را ترجیح دهید.
اگر به کارایی، یکپارچگی، ویژگی‌های پیشرفته و استاندارد بودن یک سیستم مدیریت سرویس در اکوسیستم لینوکس مدرن اهمیت می‌دهید، systemd انتخاب منطقی و عملی است.