به دلیل اختلاف نظر ، دبیان بدون نگهدارنده سیستم باقی مانده است

Debian-with-systemd

مایکل بیبل ، که از سال 2004 در توسعه دبیان نقش داشته است و کدام است یکی از عوامل اصلی به توزیع در بخش مدیریت سیستم "systemd" ، بسته را به دبیان سپرد.

این به این دلیل بود که به عنوان نگهدارنده از بسته سیستم وضعیت تصحیح خطاهای سیستم را "احمقانه و مجنون" توصیف کرده است ، و قول می دهم که دیگر گزارش اشکال را برای توسعه دهندگان سیستم ارسال نکند.

علت این امر چیست؟

درگیری به دلیل تغییر یک تغییر قهقرا در نسخه systemd 240 بوجود آمد ، مانند هنگام پردازش قوانین موجود udev باعث تغییر رفتار شد و مشکلات کاربران دبیان هنگام تغییر منطق تغییر نام رابط های شبکه.

علیرغم استفاده از گزینه "NAME" برای اتصال نام رابط شبکه به آدرس MAC پس از انتقال در udev از systemd 240.

رابط های شبکه آداپتورهای اترنت نام آنها را از ثابت به خودکار تغییر داده است (قبلاً فقط یک بار تعویض انجام می شد و از نسخه 240 می توان از آن استفاده کرد) چندین جایگزین وجود دارد).

مایکل بیبل از توسعه دهندگان systemd خواست وقتی که اتصال نام دستی مشخص شده در پیکربندی از اولویت بیشتری برخوردار است ، به رفتار قبلی برگردند.

این در مقایسه با v239 یک عقبگرد است و من تمایل دارم آن را به نقطه عطف v241 اضافه کنم زیرا ممکن است به معنی از دست رفتن دسترسی به شبکه باشد. استدلال مایکل بیبل

اما توسعه دهندگان systemd این تغییر بازگشتی را مشکلی نمی دانند ، زیرا تغییرات ایجاد شده در systemd 240 رفتار مستند را نقض نمی کند، از ویژگی های غیر مستند udev استفاده شد که عملکرد آنها تضمین نشده بود.

دبیان

با این حال ، شواهد بعدی پیدا شد که رفتار فوق در اسناد توصیف شده است.

این چگونه است یو واتانابه پاسخ داد، اساساً گفت این چیزی نبود که تأثیر بگذارد:

چرا وقتی راننده بارگیری می شود lan0 فراخوانی می شود؟ بله ، نتیجه نهایی ens3 است ، پس امیدوارم همیشه ens3 باشد.

چی مایکل بیبل او جواب داد:

به دلیل قانون udev همیشه باید lan0 نامگذاری شود.

مشکل در حال افزایش بود

پس از آن ، توسعه دهندگان systemd پیشنهاد کردند که رفتار جدید به طور انتخابی غیرفعال شود.

در صورت ایجاد قوانین udev برای نسخه های قدیمی systemd (اگر طرح نامگذاری برای نسخه های کمتر از 240 تعریف شده باشد ، گزینه RenameOnce = yes را به طور پیش فرض تنظیم کنید ، در غیر این صورت RenameOnce = خیر).

در لیست پستی توسعه دهندگان systemd ، همچنین بحث در مورد پیشنهاد صدور ، بدون زحمت بیشتر ، رفع مشکلات systemd با رفع اشکالات جدی که در نسخه های اصلی ظاهر می شوند

لنارت پاترینگ با استناد به کمبود منابع ، این ایده را رد کرد. تیاین نظر توسط برخی از توسعه دهندگان به عنوان یک تصور غلط اساسی تلقی شد ، زیرا توجه اولویت به توسعه عملکرد به ضرر ثبات تأثیر منفی بر کاربران دارد.

در پاسخ ، لنارت وی به این واقعیت اشاره کرد که کاربران نهایی از آخرین نسخه های systemd استفاده نمی کنند ، اما از بسته های تثبیت شده توسط توزیع استفاده می کنندبه عنوان مثال ، قبل از قرار دادن اجزای سیستم بر روی RHEL ، آنها در برابر Fedora و سرویس QA بررسی می شوند.

قبل از این مایکل بیبل ، بحث و جدل این بر کاربران تأثیر می گذارد ، زیرا این امر می تواند با تنظیمات از پیش تعیین شده توسط کاربر در سیستم تضاد ایجاد کند:

برای کاربران بهتر نیست زیرا تنظیمات موجود کاربر را خراب می کند. این چیست بد

در صورت تغییر اولویت ها در توسعه و رفع اشکال از نظر لنارت ، فقط نسلی از معیارهای مختلف ظهور می کند که در آن اشکالات مرتبط با معماری عجیب ، محیط های گرافیکی غیر معمولی ، کتابخانه ها و درایورها اغلب نادیده گرفته می شوند و به جامعه منتقل می شوند .

اگر می خواهید کمی بیشتر در مورد مشکل بدانید ، می توانید پیگیری کنید در لینک زیر.


محتوای مقاله به اصول ما پیوست اخلاق تحریریه. برای گزارش یک خطا کلیک کنید اینجا.

2 نظر ، نظر خود را بگذارید

نظر خود را بگذارید

نشانی ایمیل شما منتشر نخواهد شد. بخشهای موردنیاز علامتگذاری شدهاند با *

*

*

  1. مسئول داده ها: میگل آنخل گاتون
  2. هدف از داده ها: کنترل هرزنامه ، مدیریت نظرات.
  3. مشروعیت: رضایت شما
  4. ارتباط داده ها: داده ها به اشخاص ثالث منتقل نمی شوند مگر با تعهد قانونی.
  5. ذخیره سازی داده ها: پایگاه داده به میزبانی شبکه های Occentus (EU)
  6. حقوق: در هر زمان می توانید اطلاعات خود را محدود ، بازیابی و حذف کنید.

  1.   لوئیکس dijo

    یک بار دیگر می گویم: systemd بمکد !!