انجمن‌های فارسی اوبونتو
کمک و پشتیبانی => انجمن عمومی => نویسنده: mohsen-rashidi در 30 شهریور 1393، 08:57 ب‌ظ
-
امروز مقاله ایی از سایت zdnet خوندم که انتقاد های جدی از طرف توسعه دهنده های لینوکس به systemd وارد می‌کرد (http://www.zdnet.com/linus-torvalds-and-others-on-linuxs-systemd-7000033847/).
من خودم همیشه و البته با اطلاعات کم در این مورد، نگاه مثبتی به systemd داشتم تا اینکه این مقاله باعث سردرگمیم شد. از دوستان مطلع خواهش می‌کنم در این تاپیک شرکت کنن و اونچه که از خوبی ها و یا بدی های دیگه‌ی systemd می‌دونن با ما به اشتراک بذارن.
در ادامه ترجمه قسمتی از این مقاله رو قرار می‌دم:
Systemd، یک دیمونِ (دیمون، پروسه ایی است که در بک گراوند سیستم عامل اجرا می‌شود و نیازی به کاربر برای کنترل آن ندارد) مدیریت سیستم است که اختصاصا برای لینوکس توسعه داده شده است. برای سیستم هایی که از آن استفاده می‌کنند، اولین پروسه ایی است که اجرا شده و تا زمان خاموش شدن سیستم فعال است.
Systemd جایگزینی برای init است که در سال ۲۰۱۰ از طرف شرکت ردهت منتشر شد.
Systemd یک پروسه استاندارد برای کنترل کردن برنامه هایی که باید در خلال بوت شدن سیستم عامل اجرا شوند تهیه میکند. اگر چه systemd با sysv و LSB init سازگاری دارد اما به عنوان یک جایگزین بد برای init های قدیمی در نظر گرفته می‌شود.
Systemd که توسط دو کارمند ردهت لنارد پوترینگ و کِی سیورز توسعه داده شده، کاری بیشتر از استارت برنامه های اصلی انجام می‌دهد که شامل استارت logging سیستم، پشته‌ی شبکه، برنامه ریزی کارها به صورت cron-style، لاگین های کاربران و بسیاری کار های دیگر می‌شود. این ممکن است برای ما خوشایند باشد اما بعضی از توسعه دهندگان لینکس از آن متنفرند!
در سایت Boycott Systemd (http://boycottsystemd.org/)، نویسنده اینگونه به systemd می‌تازد:
«systemd بر خلاف فلسفه یونیکس عمل میکند: 'یک کار انجام بده و آن را درست انجام بده'. Systemd یک مجموعه پیچیده از دوجین بایناری ست که به شدت با آن پیوند خورده اند. مسئولیت های آن به طور فزاینده ایی از حیطه‌ی یک init system به بیرون تجاوز کرده به طوری که مدیریت قدرت، مدیریت دیوایس، mount point ها، cron، رمزگذاری دیسک، دادن سوکت به API/inetd، لاگینگ سیستم، پیکربندی شبکه، مدیریت لاگین و session ها، کاشف پارتیشن GPT، مدیریت زمان، محل و hostname و چیز های دیگر را بر عهده دارد. ساده نگهش دار، احمق! (KISS)»
(http://cdn-static.zdnet.com/i/r/story/70/00/033847/systemdcomponents-svg-620x349.png?hash=AmOyZGOxAT&upscale=1)
از آنجایی که systemd تخم مرغ خیلی از برنامه ها را در سبد یک سیستم قرار می‌دهد، هدف این انتقاد است که «صد ها سناریو وجود دارد که systemd در مواجه با یکی از آن ها می‌تواند تمام سیستم را از کار بیاندازد. به علاوه به این معنیست که بسیاری از آپدیت هایی که مربوط به کرنل نیستند اکنون احتیاج به ریبوت دارند. از ویندوز ۹ لینوکسی خودتان لذت ببرید!»
انتقاد تا به آنجا ادامه پیدا کرده است که جورنال فایل های systemd، که به صورت بایناری ذخیره می‌شوند، بالقوه فساد پذیرند. به علاوه، منتقدین متوجه شده اند که systemd با سایر اعضاء خانواده ی یونیکس ناسازگار است. آن ها همین طور بر طراحی «یکپارچه و گرایش شدید به دسکتاپ»، که آن را به یک انتخاب ضعیف برای بسیاری از موارد مورد استفاده لینوکس کرده است، ایراد می‌گیرند.
پوترینگ پاسخ این نگرانی ها را از زمان انتشار systemd بار ها داده (http://0pointer.de/blog/projects/the-biggest-myths.html) اما منتقدین همچنان دست بردار نیستند. چیزی که راجع به بحث درباره systemd عجیب است اینست که، با وجود این همه تنفر، به طور گسترده پذیرفته شده است. گنوم از ورژن ۳.۸ به بعد برای اجرا به systemd احتیاج دارد. فدورا، لینوکس جامعه کاربری ردهت، اولین توزیع مادری بود که شروع به استفاده از آن به صورت پیشفرض کرد. از آن زمان به بعد دبیان، اوپن سوزه و اوبونتو همگی systemd را پذیرفتند.
اما نظر رهبر لینوکس چیست؟ لینوس توروالدز می‌گوید:
«من در واقع هیچ نظر قطعی در مورد خود systemd ندارم. من مشکلاتی با بعضی از توسع دهندگان اصلی، که فکر می کردم درباره باگ ها و سازگاری، بیش از اندازه آسانگیر هستند، داشتم. و فکر می‌کنم بعضی از جزئیات طراحی دیوانه وار هستند (من به عنوان مثال از لاگ های بایناری بدم می‌آید)، اما اونها جزئیات هستند، نه چیز های بزرگ»
:(
-
از آن زمان به بعد دبیان، اوپن سوزه و اوبونتو همگی systemd را پذیرفتند.
ubuntu , debian, centos همه روی upstart هستن . opensuse تا حالا نداشتم خبر ندارم
-
از آن زمان به بعد دبیان، اوپن سوزه و اوبونتو همگی systemd را پذیرفتند.
ubuntu , debian, centos همه روی upstart هستن . opensuse تا حالا نداشتم خبر ندارم
توسعه upstart متوقف شده و در حال آماده‌سازی برای مهاجرت به systemd هستن.
به شخصه systemd رو ترجیح می‌دم.
-
از آن زمان به بعد دبیان، اوپن سوزه و اوبونتو همگی systemd را پذیرفتند.
ubuntu , debian, centos همه روی upstart هستن . opensuse تا حالا نداشتم خبر ندارم
توسعه upstart متوقف شده و در حال آماده‌سازی برای مهاجرت به systemd هستن.
به شخصه systemd رو ترجیح می‌دم.
می تونید دلایل این ترجیح رو بگید؟
برای مطلع شدن از مزایای systemd می‌پرسم.
-
دلیل استفاده من از systemd فنی نیست ولی برای خودم کافیه. systemd ساده، سرراست و کامله. تقریبا همه امکانات مدیریت و عیب‌یابی سطح پایین سیستم رو یک‌جا داره و رابط مدرن و منظقی‌تری داره. با systemd لازم نیست برای مدیریت سیستم چندین دستور با سینتکس‌های مختلف رو حفظ کرد (گاهی همین یک‌پارچگی از مشکلات احتمالی جلوگیری میکنه). من توی این مدتی که از systemd استفاده می‌کنم (حدود یک سال) هیچ‌گونه ناپایداری و مشکلی ندیدم و کاملا ازش راضی هستم. به‌نظر من حداقل در سطح دسکتاپ یک جایگزین عالی برای init و systemv هستش.
-
برای مثال، دو سیستم رو در اجرا و توقف دو سرویس آپاچی و مای‌سیکوئل، همچنین قرار دادن در و حذف از استارت‌آپ رو مقایسه می‌کنم:
۱. اوبونتو
آپاچی:
service apache2 start
servicde apache2 stop
update-rc.d disable apache2
update-rc.d enable apache2مای‌سیکوئل:
/etc/init.d/mysql start
/etc/init.d/mysql stop
برای افزودن و حذف استارت‌آپ باید فایل my.conf رو ویرایش کرد.
۲. آرچ لینوکس (systemd)
آپاچی:
systemctl start httpd
systemctl stop httpd
systemctl enable httpd
systemctl disable httpdمای‌سیکوئل:
systemctl start mysqld
systemctl stop mysqld
systemctl enable mysqld
systemctl disable mysqld
همین اوضاع برای مشاهده لاگ وجود داره...
-
اینو در ردهت اینجوری می نوشتیم دیگه
/etc/ini.d/httpd stop
/etc/ini.d/httpd start
chkconfig httpd on
chkconfig http off
زیاد فرقی به نظرم ندارم و من شخصا سیستم قدیمی رو ترجیح می دادم چون به نظرم منابع کمتری نیاز داشت
از طرفی وقتی شما بخواین init level ر و تغییر بدین یه چیزی مثل
systemctl set-default multi-user.targetرو باید وارد کنید اما قدیم فقط فایل /etc/inittab رو تغییر میدادیم مثلا
id;5 این عدد 5 رو به هر سطحی که مایل بودیم تغییر میدادیم
-
از آن زمان به بعد دبیان، اوپن سوزه و اوبونتو همگی systemd را پذیرفتند.
ubuntu , debian, centos همه روی upstart هستن . opensuse تا حالا نداشتم خبر ندارم
توسعه upstart متوقف شده و در حال آماده‌سازی برای مهاجرت به systemd هستن.
به شخصه systemd رو ترجیح می‌دم.
من هرچی گشتم هیچ جایی ننوشته بود که متوقف شده . اخرین اپدیتش ماله 4 سپتامبر هستش
-
http://www.crazyengineers.com/threads/ubuntu-will-switch-to-systemd-abandoning-their-own-init-system-upstart.73350
http://thevarguy.com/ubuntu/021814/canonical-gives-upstart-systemd-ubuntu-linux
http://www.phoronix.com/scan.php?page=news_item&px=MTYwNDE
http://www.admin-magazine.com/News/Ubuntu-Abandons-Upstart
-
تو هیچ جا نگفته می خواد متوقف بشه . فقط دارن سویچ میکنن رو systemd .
احتمالا فقط bug fix رو ادامه میدن که فرقی با همون متوقف شدن نداره
-
مقاله کاملا یه طرفه است. systemd چیزیه که لینوکس سال‌ها بش نیاز داشته. یه سیستم که داره userspace لینوکس رو یکپارچه میکنه. حالا که بعد از سال‌ها همچین چیزی شکل گرفته یه عده از غارشون اومدن بیرون که ای وای فلسفه یونیکس در خطر است! هزار مورد هست که نشون میده تقسیم هرقست به برنامه جدا ایده خوبی برای پیاده سازی سیستم نیست. مثلا تا قبل از systemd، مانت فایل سیستم بدون دسترسی روت و با ConsoleKit یه فاجعه کامل بود.
انتقاد تا به آنجا ادامه پیدا کرده است که جورنال فایل های systemd، که به صورت بایناری ذخیره می‌شوند، بالقوه فساد پذیر است.
ذخیره سازی باینری به دلیل سرعت بیشتر انجام میشه. کی دوست داره یه دقیقه منتظر نمایش لاگ‌ها بشه؟
به علاوه، منتقدین متوجه شده اند که systemd با سایر اعضاء خانواده ی یونیکس ناسازگار است.
به نظرم فقط پشتیبانی از API های لینوکس و ساخت یه مدیر سیستم عالی برای لینوکس از ساختن یه مدیر سیستم متوسط که قراره هم روی لینوکس و BSD کار کنه خیلی بهتره. کلا چند نفر روی دسکتاپ از BSD استفاده میکنن؟ مطمعنم صد هزار نفر هم نمیشن.
-
مقاله کاملا یه طرفه است. systemd چیزیه که لینوکس سال‌ها بش نیاز داشته. یه سیستم که داره userspace لینوکس رو یکپارچه میکنه. حالا که بعد از سال‌ها همچین چیزی شکل گرفته یه عده از غارشون اومدن بیرون که ای وای فلسفه یونیکس در خطر است! هزار مورد هست که نشون میده تقسیم هرقست به برنامه جدا ایده خوبی برای پیاده سازی سیستم نیست. مثلا تا قبل از systemd، مانت فایل سیستم بدون دسترسی روت و با ConsoleKit یه فاجعه کامل بود.
انتقاد تا به آنجا ادامه پیدا کرده است که جورنال فایل های systemd، که به صورت بایناری ذخیره می‌شوند، بالقوه فساد پذیر است.
ذخیره سازی باینری به دلیل سرعت بیشتر انجام میشه. کی دوست داره یه دقیقه منتظر نمایش لاگ‌ها بشه؟
به علاوه، منتقدین متوجه شده اند که systemd با سایر اعضاء خانواده ی یونیکس ناسازگار است.
به نظرم فقط پشتیبانی از API های لینوکس و ساخت یه مدیر سیستم عالی برای لینوکس از ساختن یه مدیر سیستم متوسط که قراره هم روی لینوکس و BSD کار کنه خیلی بهتره. کلا چند نفر روی دسکتاپ از BSD استفاده میکنن؟ مطمعنم صد هزار نفر هم نمیشن.
خیلی ممنون از پستتون اما نظرتون راجع به این قسمت چیه؟
بسیاری از آپدیت هایی که مربوط به کرنل نیستند اکنون احتیاج به ریبوت دارند. از ویندوز ۹ لینوکس خودتان لذت ببرید!»
-
انتقاد تا به آنجا ادامه پیدا کرده است که جورنال فایل های systemd، که به صورت بایناری ذخیره می‌شوند، بالقوه فساد پذیرند. به علاوه، منتقدین متوجه شده اند که systemd با سایر اعضاء خانواده ی یونیکس ناسازگار است. آن ها همین طور بر طراحی «یکپارچه و گرایش شدید به دسکتاپ»، که آن را به یک انتخاب ضعیف برای بسیاری از موارد مورد استفاده لینوکس کرده است، ایراد می‌گیرند.
به نظر شما با اینهمه دسترسی که systemd نیاز داره یعنی دقیقا به همه چیز دسترسی داره ، خیلی مناسب نیست برای در پشتی درست کردن :D به خصوص اینکه ، لاگ هاش هم باینری هستن ::) حرف اون متخصص ها درسته ، این برنامه با فلسفه یونیکس و حتی تا حدودی متن بازی در تضاده.
-
انتقاد تا به آنجا ادامه پیدا کرده است که جورنال فایل های systemd، که به صورت بایناری ذخیره می‌شوند، بالقوه فساد پذیرند. به علاوه، منتقدین متوجه شده اند که systemd با سایر اعضاء خانواده ی یونیکس ناسازگار است. آن ها همین طور بر طراحی «یکپارچه و گرایش شدید به دسکتاپ»، که آن را به یک انتخاب ضعیف برای بسیاری از موارد مورد استفاده لینوکس کرده است، ایراد می‌گیرند.
به نظر شما با اینهمه دسترسی که systemd نیاز داره یعنی دقیقا به همه چیز دسترسی داره ، خیلی مناسب نیست برای در پشتی درست کردن :D به خصوص اینکه ، لاگ هاش هم باینری هستن ::) حرف اون متخصص ها درسته ، این برنامه با فلسفه یونیکس و حتی تا حدودی متن بازی در تضاده.
خوب به جاش چی نصب کنیم؟چی پیشنهاد میکنین؟
-
من عیب یا نقصی توی service و init ندیدم.
-
خیلی ممنون از پستتون اما نظرتون راجع به این قسمت چیه؟
بسیاری از آپدیت هایی که مربوط به کرنل نیستند اکنون احتیاج به ریبوت دارند. از ویندوز ۹ لینوکس خودتان لذت ببرید!»
نظری ندارم ولی آیا تصمیم گیری این که سیستم با به روزرسانی‌ها چقدر به ریبوت نیاز پیدا کنه به عهده توزیع ها نیست؟ مثلا اگر توسعه دهنده‌های توزیع Y نخوان که سیستم کاربرهاشون با هر آپدیت نیاز به ریبوت نداشته باشه خب systemd رو آپدیت نمیکنن، نیاز چندانی هم بش نیست. اگر توزیعی بخواد همه چیز رو آپدیت کنه با آپدیت کرنل خیلی بیشتر از آپدیت systemd اجبار به ریبوت رو پیش میاره.
به نظر شما با اینهمه دسترسی که systemd نیاز داره یعنی دقیقا به همه چیز دسترسی داره ، خیلی مناسب نیست برای در پشتی درست کردن :D به خصوص اینکه ، لاگ هاش هم باینری هستن ::) حرف اون متخصص ها درسته ، این برنامه با فلسفه یونیکس و حتی تا حدودی متن بازی در تضاده.
اگر برنامه‌ای در پشتی داشته باشه تو لاگ‌ها خودش نمیاد بنویسه من در پشتی دارم یا حتی اثری از این مورد ثبت بکنه! ذخیره باینری لاگ‌ها فقط برای سرعت بیشتر ذخیره، بازیابی و جست و جوئه.
من عیب یا نقصی توی service و init ندیدم.
یکی از عیب‌های بزرگ SysVinit خطی بودنش بود، یعنی یه task رو انجام میداد، بعد سراغ بعدی میرفت. اما systemd تسک‌ها به صورت parallel انجام میده در نتیجه سرعت بوت خیلی بیشتر میشه. در ضمن init فقط یکی از سرویس‌های systemd هست. نمیشه این ها رو باهم مقایسه کرد.
-
آقا ساسان تسلیم چرا می زنی آخه ;D
-
می گویند init بوت رو کند میکند.
-
ولی آیا تصمیم گیری این که سیستم با به روزرسانی‌ها چقدر به ریبوت نیاز پیدا کنه به عهده توزیع ها نیست؟ مثلا اگر توسعه دهنده‌های توزیع Y نخوان که سیستم کاربرهاشون با هر آپدیت نیاز به ریبوت نداشته باشه خب systemd رو آپدیت نمیکنن، نیاز چندانی هم بش نیست.
وقتی یک بروزرسانی امنیتی وجود داره، بخصوص توی سرورها، بروزرسانی یک موضوع اختیاری نیست، یک موضوع اجباری هستش. حتی برای کرنل هم سعی میشه با ابزاری مثل Ksplice زمان غیرفعال بودن سرور رو تا حد ممکن پایین آورد.
ذخیره باینری لاگ‌ها فقط برای سرعت بیشتر ذخیره، بازیابی و جست و جوئه.
یکی از خوبی‌هایی که گنو-لینوکس نسبت به سیستم‌های دیگه مثل ویندوز داره اینه که حجم زیادی از اطلاعات به صورت آزاد (اینجا به صورت متنی) در دسترس هست و بدون نیاز به استفاده از برنامه دیگه‌ای میشه به اونها دسترسی پیدا کرد. برای مثال من می‌تونم فایل‌های لاگ رو جایی بذارم که کاربرهای خاصی به راحتی با FTP بتونند اونها رو دانلود کنند و مستقیم بخونند.
این تغییر باعث میشه که مقدار آزادی عمل توی این زمینه پایین بیاد. من به شخصه و به عنوان یک Server Administrator ترجیح می‌دم یک ثانیه برای دیدن یک لاگ صبر کنم و به صورت متنی باشه تا اینکه ۲۰ میلی‌ثانیه صبر کنم و اون رو به راحتی در مکان‌های دیگه نتونم استفاده کنم.
-
آقا ساسان تسلیم چرا می زنی آخه ;D
نفرمایید آقا، من ارادت دارم. ببخشید اگر لحن نوشته‌هام تند میزنه. از روی نوشته نمیشه مود رو منتقل کرد. لول.
وقتی یک بروزرسانی امنیتی وجود داره، بخصوص توی سرورها، بروزرسانی یک موضوع اختیاری نیست، یک موضوع اجباری هستش. حتی برای کرنل هم سعی میشه با ابزاری مثل Ksplice زمان غیرفعال بودن سرور رو تا حد ممکن پایین آورد.
systemd ابزاری داره که به روزرسانی بدون ریبوت رو ممکن میکنه. + (http://www.freedesktop.org/software/systemd/man/systemctl.html#daemon-reexec) حالا این که ریسک این کار برای پروسه ای که به عنوان pid 1 اجرا میشه چقدره موضوع دیگه است.
هیچ کس منکر ضعف‌های systemd نیست، اما ویژگی ها مثبتش بسیار بسیار بیشتر از ضعف‌هاشه.
یکی از خوبی‌هایی که گنو-لینوکس نسبت به سیستم‌های دیگه مثل ویندوز داره اینه که حجم زیادی از اطلاعات به صورت آزاد (اینجا به صورت متنی) در دسترس هست و بدون نیاز به استفاده از برنامه دیگه‌ای میشه به اونها دسترسی پیدا کرد. برای مثال من می‌تونم فایل‌های لاگ رو جایی بذارم که کاربرهای خاصی به راحتی با FTP بتونند اونها رو دانلود کنند و مستقیم بخونند.
با لاگ‌های Journal هم میتونی. فایل‌ها با فورمت باینری ذخیره میشن ولی متن پیام‌ها دست نخورده میمونه. با دستور strings میتونی اونها رو بخونی.
مثلا:
$ strings /mnt/arch/var/log/journal/af4967d77fba44c6b093d0e9862f6ddd/system.journal | grep messageیا این که میتونی پیام‌های journald رو به syslog بفرستی و مثل سابق استفاده کنی + (https://wiki.archlinux.org/index.php/systemd#Journald_in_conjunction_with_syslog)
-
من در مورد خوب بودن یا بد بودن systemd چیزی نگفتم چون در حال حاضر اطلاعات کافی در مورد اون ندارم، فقط دو مورد رو در جواب‌هایی که دادی اشاره کردم:
۱- نصب یک بروزرسانی امنیتی یک موضوع اختیاری نیست و اجباری هستش و نباید بگیم خوب اون رو بروزرسانی نکن. این جواب بدی هستش.
۲- مسلما می‌دونم که لاگ‌های باینری هم میشه تبدیل کرد و واضحه که کار کردن با لاگ‌های متنی ساده‌تر از لاگ‌های باینری هستش، برای همین گفتم «بدون نیاز به استفاده از برنامه دیگه‌ای». و البته این یک ترجیح شخصی هستش.
-
۱- نصب یک بروزرسانی امنیتی یک موضوع اختیاری نیست و اجباری هستش و نباید بگیم خوب اون رو بروزرسانی نکن. این جواب بدی هستش.
چیزی در مورد آپدیت‌ها امنیتی نگفتم. به نظر منم آپدیت‌های امنیتی حتما باید انجام بشن.
منظورم این بود که توزیعی مثل RHEL مشابه آرچ یا فدورا آخرین آپدیت‌های کرنل رو ارائه نمیده تا مرتب نیاز به ریبوت رو به وجود بیاره. شاید بتونن رویه مشابه‌ای رو برای systemd در پیش یگیرن. اگر مثلا نسخه بعدی systemd چندتا مشکل امنیتی رو حل کرد، فقط بیان برای این تغییرات به روزرسانی بدن و نسخه خودشون maintain کنن. اینجوری فاصله بین این دو نسخه کمتر میمونه و احتمال مشکل در اثر آپدیت بدون ریست به حداقل میرسه. البته این فقط نظر منه. شاید بشه، شاید نشه.
-
ظاهرا کار داره به انشعاب می‌کشه:
http://www.phoronix.com/scan.php?page=news_item&px=MTc5MzA (http://www.phoronix.com/scan.php?page=news_item&px=MTc5MzA)
-
اگر مثلا نسخه بعدی systemd چندتا مشکل امنیتی رو حل کرد، فقط بیان برای این تغییرات به روزرسانی بدن و نسخه خودشون maintain کنن. اینجوری فاصله بین این دو نسخه کمتر میمونه و احتمال مشکل در اثر آپدیت بدون ریست به حداقل میرسه. البته این فقط نظر منه. شاید بشه، شاید نشه.
خوب از اول می‌گفتی با Backporting تعداد بروزرسانی‌ها رو کمتر کنند :) این کاری هست که Debian نسخه Stable برای همه بسته‌ها انجام میده و کاملا شدنی هستش.
-
http://boycottsystemd.org/