انگیزه اصلی نوشتن من، ادعای مشهوریه که در مورد systemd میشه اونم این که
systemd بده چون با فلسفه یونیکس سازگار نیست. گاهی هم این موضوع به
صورتهای دیگهای بیان میشه مثل این که systemd بزرگه یا این که تو هر
موضوعی دخالت کرده و ... که همه تقریبا دارن یک چیز رو بیان میکنن. اما
حداقل یک عده، تصور درستی از چیزی که بیان میکنند ندارند. برای همین بد
ندیدم چیزهایی رو بگم که لااقل اگه کسی مخالف هم هست، بهتر مخالف باشه! ولی
قبل از شروع یه خلاصهای از کلیات چیزی که میخوام میگذارم که از قضاوت عجولانه شاید تا حدی جلوگیری
کنه. البته بسته به شرایط شاید صحبتها گستردهتر هم شد. اما اساس حرفهای
من:
۱. «فلسفه یونیکس» چیز خوبیه؟
۲. اصلا چی هست؟ و گفتن این که برنامهای رعایتش میکنه یا نه راحته؟
۳. آیا systemd خلاف این فلسفه ست؟ و اگه هست، چیز بدیه؟ یا اگه نیست چرا نیست؟
مورد ۳ میتونه خلاصه یا مفصل باشه؛ ببینیم اوضاع چطور پیش میره! شاید یکمی بیشتر پروژه systemd رو باز کردیم و در موردش نوشتم.
یه چیزی هم بگم همین الان! من سعی میکنم چیزهایی که میگم غلط نباشه، ولی خب حالشم ندارم براشون سند و منبع بیارم. بررسی صحتشون در صورت تمایل با خواننده. اما اگه کسی خواست ازم ایراد بگیره، حتما باید مستند باشه وگرنه راستش رو بخواین لزوما حالشم ندارم هر ادعایی رو بخوام برم بررسی کنم ببینم درسته یا نه D: مخصوصا که من یه نفرم و شما احتمالا چندتا!
پس من بدون سند حرف میزنم، کسی خواست رو حرفم حرف بزنه سند بیاره ؛) به نظر خودم که عادلانهست!
یک سری هستند که تعصب خاصی روی چیزهایی مثل «فلسفه یونیکس» دارند انگار که قطعا این چیز خوبیه و هر چیزی باهاش ناسازگار باشه چیز بدیه. اما این که این مسئله خوبه یا نه، مثل خیلی مسائل دیگه تو این رشته، قطعی و بدیهی نیست. و شخصا عادت ندارم این جور چیزها رو همینطوری بپذیرم. یا باید بشه درست بودن چیزی رو اثبات کرد، یا این که باید توجیهات و مزایا معایب رو شنید و براساس اون تصمیم گیری کرد. مثلا، برنامهنویسی شیءگرا بهترین روش برنامهنویسیه؟ آدمهای بزرگی در موردش نوشتند، ولی عدهای هم هستند که مخالفن و میگن نه مثلا برنامهنویسی تابعی بهتره و شیء گرا چیز بدیه! یا در مورد روشهای برنامهنویسی مثل آبشاری و چابک و همچنین روشهای مختلف چابک. اینها هیچ کدوم «آیه» نیستند و چه بسا بعدا کسایی بیان و راههای متفاوتی رو به عنوان گزینه برتر معرفی کنند. شخصا، هیچ کدوم از این دست مسائل رو به صورت خشک و بدون تحلیل نمیپذیرم و برای تفکر خودم هم احترام قائلم! صرف این که فلان آدم شناخته شده گفته باشه چیزی خوبه به نظر من اون رو به یک حقیقت جامع و غیر قابل انکار تبدیل نمیکنه! مگر این که کسی بتونه اون رو به صورت منطقی و غیرقابل بحث اثبات کنه. آیا طراحی نرمافزار طبق «فلسفه یونیکس» واقعا خوبه؟ به نظر میاد جاهایی خوب بوده اما معنیش این نیست که لزوما همهجا خوبه یا اصلا راه بهتری براش وجود نداره. به نظرم این جور جاها باید بحث بشه که مثلا به فلان دلایل این کار خوب یا بده که احتمالا خیلی جاها در نهایت باید بین چند چیز سبک سنگین کرد؛ نه این که به صرف استناد به یک جمله حکم صادر کنیم.
فلسفه یونیکس
فلسفه یونیکس چیه؟ تو ویکیپدیا که خیلی چیزا نوشته ولی قسمتی که اکثرا روش
نظر دارن اینه: «برنامهای بنویسید که یک کار رو به خوبی انجام بده».
تو
نگاه اول ممکنه جمله به نظر ساده بیاد، اما ۲ قسمت داره که باعث میشه خیلی
هم این جمله ساده نباشه: ۱. «یک کار» و ۲. «به خوبی». اینها چیزایی هست
که باعث میشه این معیار خیلی هم واضح و شفاف نباشه و جای بحث پیش بیاد. نه
«یک کار» لزوما تعریف مشخصی داره و نه «به خوبی» انجام دادن یک کار. و نه
لزوما شما میتونید هر دو رو با هم داشته باشیم. همونطور که خیلی اصول دیگه که مطرح میشن تو حرف راحت اما تو عمل اما و اگرهای زیادی پیدا میکنند.
خوبه یک مثال بزنم. بیاین ترکیب tar و یک فرمان فشردهسازی مثل gzip/xz/... رو مقایسه کنیم با برنامه zip/unzip.
۱. دستور tar فقط کارش مدیریت بایگانیهای tarه چه ساختن چه بیرون کشیدن فایلها از اونها
یکی دیگه از خصوصیاتی که تو فلسفه یونیکس گفته میشه بحث ترکیب ابزارها هست. tar و gzip خب با هم به صورت ترکیبی هم استفاده میشند و شما امکان ترکیب با برنامههای دیگه هم دارید مثل bzip2 و xz که خب انعطافپذیری رو نشون میده. البته دستور tar خودش گزینه میگیره برای ترکیبش با برنامههای فشردهسازی که شاید خودش یه جور نقض فلسفه یونیکس هم محسوب بشه!
از اون طرف zip/unzip کار فشردهسازی و غیرفشردهسازی رو جداگانه انجام میدند. اما دستور zip خودش هم با بایگانی چندین فایل سر و کار داره و هم با فشردهسازی اونها.اما! با این که tar خوبه،gzip هم خوبه، ترکیب اونها برای کار «فشردهسازی چندین فایل» لزوما ترکیب خوبی نیست. چرا؟ برای مثال، شما برای استخراج یک فایل از آرشیو tar.gz مجبورین کل فایل رو غیرفشرده کنید تا بعد بتونید از آرشیو tar یک فایل رو بکشید بیرون. اما توی zip شما میتونید چنین کاری بکنید. به نظر میرسه اینجا ابزاری که کار ترکیبی رو کرده در نهایت بهتر اون کار رو انجام داده.آیا نمیشد tar و gzip هم چنین امکانی بدند؟ چرا احتمالا میشه، ولی اونجاست که مثلا برنامه tar دیگه فقط به فکر کار خودش نیست و عملا باید چیزهایی فراتر رو در نظر بگیره و احتمالا برخی از مزایای جدا بودن و کوچک بودن رو از دست میده. هر چند... همین الان هم با داشتن گزینههای مربوط به فشردهسازی میشه گفت خیلی هم مستقل نیست.
به هر حال، شاید اینجا «یک کار» بهتره هم شامل کد کردن و هم بایگانی چندین فایل باشه تا این که بایگانی «یک کار» باشه و کدکردن هم «یک کار» جدا.
در نهایت، خود یونیکس هم بعضا فلسفهش رو رعایت نکرده! یکی همین که هستههای اولیه و حتی هستههای به روز یونیکسهایی مثل solaris و bsdها از نوع یکپارچه هستند.
یک مثال شاخص هم، تابع شاخص `ioctl`ه که عملا همه کار میکنه... یا لااقل میتونه بکنه. :)
خب، تا اینجا اول گفتم که «فلسفه یونیکس» لزوما چیز خوبی نیست، یا لزوما بهترین چیز نیست، یا اصلا شاید بسته به شرایط خوب باشه یا نباشه!
دوم هم گفتم که اصلا تعریف خیلی دقیق و مشخصی هم نداره و بستگی به تفسیر ما میتونه معنی متفاوتی بده. مهمترین نقاط ابهام هم یکی انجام «یک کار» بوده و یکی هم این که اون کار «به خوبی» انجام بشه. این که به چی میگم «یک کار» و هم این که معیار خوبی انجام کار چیه خودشون ابهام دارند.
سوم هم یک مثال زدم که نشون بدم که ممکنه ترکیب دو برنامه که دو کار کوچیک رو انجام میدند برای انجام یک کار بزرگتر، ممکنه نتونه اون کار بزرگتر رو به خوبی انجام بده. در نتیجه یا تعریف «کار»مون درست نیست،َ یا هم باید بگیم بعضی جاها فلسفه یونیکس باعث میشه نتونیم یه کار نسبتا پیچیده رو خوب انجام بدیم!یه نکته دیگه هم اضافه کنم. فلسفه یونیکس داره در مورد «یک برنامه» صحبت میکنه که حالا بخوایم عمومیترش کنیم میشه یک ماژول. هیچ وقت این فلسفه در مورد یک پروژه صحبت نمیکنه، چون یک پروژه خیلی معنی فنی خاصی هم نداره. وگرنه یک پروژه هست به اسم «پروژه گنو»، که رسما هدفش تولید یک سیستمعامل کامل بود: از هسته گرفته تا پوسته و کامپایلر و ... .تازه یکی از اجزای این پروژه، پروژه coreutilsه. این پروژه هم شامل بالای ۱۰۰ تا فایل اجرایی مختلفه: از cp و ls گرفته تا sleep و uname و ...
کسی نمیاد بگه پروژه گنو فلسفه یونیکس رو نقض میکنه یا مثلا coreutils این فلسفه رو نقض میکنه. چون اینها پروژه هستند و یک «برنامه» نیستند. و درست هم هست. حتی اگه تمام برنامهها پیشوند gnu یا coreutils داشتند باز هم همین بود.
پس خوبه حواسمون به تفاوت «پروژه» و «برنامه» باشه. این اولین چیزیه که توی بررسی systemd باید حواسمون باشه؛ چون systemd هم اسم یک پروژهست و هم اسم یک برنامه. متاسفانه، بخش قابل توجهی از افراد به این تفاوت دقت نمیکنند که باعث میشه نتیجهگیریهایی بکنند که از اساس اشکال داره.آخر این قسمت، یک سوال هم مطرح کنم: آیا Sys V init با فلسفه یونیکس سازگار بود که اینقدر طرفدار داشت وقتی systemd مطرح شد؟! آیا یک کاری رو به خوبی انجام میداد؟من فقط میگم دقت کنید که تا جایی که من میبینم حتی خیلی توزیعهای مخالف استفاده از systemd هم دیگه از Sys V init استفاده نمیکنند!
خب، من فکر میکنم احتمالا کارش رو خوب انجام نمیداده که جایگزین شده. در نتیجه خودش هم با فلسفه یونیکس سازگار نبوده. اما کسی گریبان پاره نمیکرد که چرا Sys V init بده و اوایل مخالفین systemd دوست داشتند برگردن به اون. :)
و البته دیدم یک عده هم تفسیر خودشون رو از «فلسفه یونیکس» دارند و صرفا هر تغییر نسبت به یونیکس سابق رو تعبیر میکنند به نقض فلسفه یونیکس! و این افراد بیشتر مقاومت در برابر تغییر دارند تا نگرانی در مورد فلسفه یونیکس :)
systemd
خب systemd چیه؟ این کلمه به ۲تا مفهوم متفاوت میتونه اشاره کنه، در نتیجه
وقتی کسی میخواد در موردش صحبت کنه باید بدونه و مشخص کنه که داره در
مورد کدومش صحبت میکنه و این ۲تا رو قاطی نکنه!
"systemd is a suite of basic building blocks for a Linux system."
به
صورت کلی، systemd یک «مجموعه نرمافزاری پایهای برای یک سیستم لینوکس»ه.
و ما داریم در مورد یک «پروژه» نرمافزاری صحبت میکنیم نه یک «برنامه».
اما، اسم شاخصترین برنامه این مجموعه هم systemd هست! کار «برنامه systemd» چیه؟ طبق تعریف خودشون، «مدیریت سیستم و سرویسها».
که البته خیلی قسمت «مدیریت سیستم»ش گویا نیست به نظرم و میشه منظورش رو از
کارهایی که میکنه تشخیص داد.
حالا وقتی در مورد «پروژه systemd» صحبت
میکنیم، آیا صحبت از این که این پروژه به خاطر پوشش موارد خیلی متنوع با
فلسفه یونیکس در تناقضه، درسته؟ «به هیچ عنوان». اصلا چنین صحبتی معنا
نداره؛ چون فلسفه یونیکس اصلا و به درستی در مورد پروژهها یا مجموعههای
نرمافزاری صحبتی نمیکنه. یک پروژه رو میشه به چند پروژه شکست بدون این که شما هیچ تغییری توی کدهای اجرایی ایجاد کنی. پس پروژه اصالت خاصی نداره.
به جز «برنامه systemd» برنامههای مختلفی توی این مجموعه وجود داره مثل مدیریت: لاگها، نشست کاربران، اتصالات شبکه، ساناد یا DNS، راهاندازی سیستم (بوت)، زمان سیستم، همگامسازی زمان با NTP، فایلهای موقت و دستگاههای متصل به سیستم.
هر کدوم از اینها، در قالب برنامههای جداگانه هستند و در نتیجه، صرف ورود مجموعه systemd به این زمینهها تناقضی با «فلسفه یونیکس» نداره. برخلاف چیزی که خیلیا ادعا میکنن. اما خب، میشه تک تک این برنامهها رو جداگانه از این نظر بررسی کرد. همونطور که هستند کسانی که با اطلاع، در این موارد هم انتقاد میکنند. اما متاسفانه، دور رو برمون کمتر این مدل صحبتها رو میبینیم.البته ممکنه یکی با استدلال بگه به صورت کلی توی کل این پروژه، رویکرد متفاوتی نسبت به «فلسفه یونیکس» پیش گرفته شده و از این نظر بگه این پروژه با اون فلسفه سازگار نیست؛ اما من تا الان چنین چیزی رو ندیدم و خیلی افراد واقعا نه شناخت کافی نسبت به systemd دارند و نه حتی خود فلسفه یونیکس!
حالا «برنامه systemd» چی؟ این برنامه مطابق با فلسفه یونیکس هست یا اون رو نقض میکنه؟
جواب
این سوال سخته و من جوابی که بتونه همه رو قانع کنه به ذهنم نمیرسه.
همونطور که اوایل گفتم، «فلسفه یونیکس» یک سنجه دقیق نیست که بگذاریم و
راحت بگیم این برنامه کاملا سازگاره و این برنامه هم متناقض. یک سری
برنامهها ممکنه به اندازه کافی به یکی از این دو سمت نزدیک باشند که بشه
نسبتا راحت در موردشون نظر داد. اما یک سری برنامهها هم ممکنه بیفتند توی
طیفی بین این ۲ سمت که دلیلش هم قبلا گفتم: کلماتی مثل «یک کار» و انجام آن «به خوبی» کلماتی
نیستند که تعریف دقیق و روشنی داشته باشند. در نتیجه، هر کس بسته به
معیارها و تعریف خودش ممکنه قضاوت متفاوتی داشته باشه؛ و من هم قصد ندارم
برای دیگران در موردش قضاوتی بکنم. اما صرفا سعی میکنم تا حدی توصیف کنم
برخی خصوصیات systemd رو و نظرم رو هم بگم.
برنامه systemd کارش مدیریت
سیستم و سرویسهای سیستمه. این برنامه به جز journald، که اونم میتونه
صرفا کارش ارسال لاگها به syslog باشه، تا جایی که من میدونم به هیچکدوم از برنامههای مجموعه پروژه systemd وابستگی نداره. شاید بشه گفت مهمترین
کار این برنامه، مدیریت و اجرای سرویسهای سیستم یا کاربره. حالا من اینجا
بیشتر حالتی که systemd به عنوان اولین پردازه سیستم با PIDه شماره یک کار
میکنه صحبت میکنم.
اما، systemd کاری فراتر از اجرا و اتمام سرویسها
انجام میده. توی systemd شما با «واحدها» یا unitها سر و کار دارین. اما
این unitها صرفا سرویسها نیستند، بلکه میتونن نماینده دستگاهها، نقاط
سوار شدن (mount pointها)، سوکتها، زمانسنجها و چند مدل واحد دیگه باشند. حالا اینجا جاییه که واقعا میتونه سوال برانگیز باشه. چون عملا systemd بخشی از کاری رو که قبلا سرویسهایی مثل crond، atd و inetd انجام میدادند رو هم انجام میده و خودش رو درگیر دستگاههای سختافزاری و مدیریت فایلسیستمها هم کرده. و این موارد مواردی هستند که میتونن به درستی مطرح بشند از این نظر که سازگاری با فلسفه یونیکس وجود داره یا نه (و نه تیترهای زردی مثل این که systemd بوت لودر هم هست...).
اینجا هم، کار systemd مدیریت سرویسهاست. اما عملا چیزهایی مثل cron و inetd هم به نحوی توی مدیریت سرویسها دخالت دارند چون هر کدوم میتونند از نظر مفهومی یک یا چند سرویس رو هم اجرا کنند. حالا آیا بهتر نیست اینها هم مثل بقیه سرویسها خود systemd مدیریت کنه؟ میتونه باشه. در واقع، میشه به نحو دیگهای هم رفتار systemd رو توصیف کرد. systemd اومده یک انتزاع سطح بالاتر به نام واحد یا unit ساخته، که شما میتونید از همین مفهوم و به صورت یکپارچه برای مدیریت سیستم استفاده کنید. میشه این رو تا حدی با مفهوم «فایل» توی یونیکس مقایسه کرد. یکی از خصوصیات یونیکس این بوده که خیلی چیزها توی یونیکس فایل هستند: فایلهای دیسک، سوکتها، دستگاههای سختافزاری، و ... . و این مسئله به شما قدرت میده که بتونید با مجموعهای از چیزهای متفاوت رفتار مشابهی داشته باشید و این اتفاق خوبیه. «به نظر من»، کاری که systemd در مورد یک سری مفاهیم انجام داده هم مشابه همین مثاله. این که شما میتونید به جز سرویسها، مفاهیم دیگهای رو هم در قالب واحدها توصیف کنید به شما قدرت بیشتری توی مدیریت سیستم میده. این یعنی که شما میتونید از مسائلی مثل وابستگی بین واحدها و غیره برای چیزهای گستردهتری استفاده کنید و به صورت یکپارچهتری سیستم رو مدیریت کنید. از دید من، این چیز خوبیه و میشه اینها رو در قالب انجام یک کار به خوبی دید، اما درک میکنم که ممکنه کسی مخالف باشه و از نظر من اشکالی هم نداره.
آیا کارش رو خوب انجام میده؟ البته که قطعا مثل تقریبا هر برنامه دیگهای این برنامه هم ایرادات خودش رو داره، اما باز به نظر من در مجموع کارش خوبه، مخصوصا نسبت به سیستمهایی که جایگزینشون کرد.
یک مثال دیگه هم البته، اینه که systemd سازگاری بسیار خوبی با مدل SysV init داشت و از سرویسهای اون پشتیبانی میکرد. حالا کسی ممکنه این رو هم ایراد بدونه که چرا همچین ویژگی هم به systemd اضافه شده و اون رو «پیچیده» کرده! اما از اون طرف همین ویژگی انتقال به systemd رو بسیار آسانتر و کم ریسک تر کرده بود. از نظر من، این ویژگی چیز خوبیه، اما از دید یک نفر میتونه به پچیده شدن و دور شدن از «تمرکز روی یک کار» تعبیر بشه. و خب من نمیتونم بگم که نظر من درستتره!
با توجه به این که معمولا وقتی صحبت از استفاده یا عدم استفاده از systemd میشه اصولا منظور همین استفاده اون به عنوان init سیستمه، من روی برنامههای دیگه این پروژه دیگه صحبتی نمیکنم، به جز یک صحبت مختصر که در مورد journald خواهم کرد. و حتی فدورا، که ظاهرا اولین توزیعی بود که به systemd مهاجرت کرد، عجلهای توی استفاده از برنامههای دیگه نداشت و نداره و لزوما هم استفاده نخواهد کرد.
journald
به عنوان آخرین صحبت قبل از خلاصه نهایی، یه نیم نگاهی هم به journald داشته باشیم بد نیست چون بخشی از انتقادات هم متوجه این سرویسه.اول که همونطور که گفته شد، شما مجبور نیستین از journald برای مدیریت رخدادنماها (logها) استفاده کنید و میتونه صرفا اونها رو ارسال کنه برای syslog و خودش چیزی نگه نداره.
دوم این که از نظر من این برنامه صرفا یک کار انجام میده و اون هم مدیریت رخدادنماهاست و فکر نمیکنم از این نظر خیلی اختلاف نظری توش وجود داشته باشه. اما جایی که بیشتر روش صحبت هست، نحوه ذخیرهسازی رخدادنماهاست، چون journald اونها رو به
صورت دودویی ذخیره میکنه و نه متنی. بعضی از اساس با این قضیه مخالفن و
برای مثال میگن باعث میشه شما نتونید لاگهای ذخیرهشده رو با ابزارهای
معمول (مثلا grep) بررسی کنی. یا دلایل دیگه. و بعضی هم میگن این هم با
فلسفه یونیکس ناسازگاره.
حقیقتا یک سری از دلایل رو خیلی صحبتی نمیشه
روش کرد. مثلا من میتونم بگم شخصا موافق نیستم ولی فکر نمیکنم خیلی قابل
بحث باشه. از نظر من این که شما میتونید با journalctl لاگها رو در قالب متنی دریافت کنید و پردازش دلخواه خودتون رو روش انجام بدید (به جز این که
خود journalctl هم قابلیتهایی داره برای انتخاب رخدادنماهایی که دنبالش
هستیم). و از نظر من دودویی بودن لزوما چیز بدی نیست همونطور که خیلی
برنامهها چنین کاری میکنند.
در مورد فلسفه یونیکس هم، طبق چیزی که من
توی ویکیپدیا میبینم توی بعضی روایتها گفتند که دادهها رو متنی نگه
دارین ولی توی بعضی روایتهای دیگه هم بیشتر تاکید روی ورودی و خروجی
برنامههاست که متنی باشه و تو بعضی روایتها هم اصلا صحبتی از این قضیه
نشده! در نتیجه، به نظرم اصلا این که این جزء فلسفه یونیکس هست یا نه خودش جای
بحث داره. و دوم هم، به فرض هم اگر باشه شخصا موافقش نیستم، و البته ما با
برنامههای زیادی سر و کار داریم که چنین کاری نمیکنن! مثلا بسیاری از
پایگاههای داده اون رو در قالب دودویی ذخیره میکنند. یا مثلا شما تصویر
رو در قالب متنی ذخیره نمیکنید... (البته قالب xpm هم قالب بامزهایه :)
). جدای از این که «متن» هم دیگه لزوما فقط متن ASCII نیست. و حتی توی
ارتباط برنامهها میبینیم که زمانی بخشی از ارتباطات دودویی بود؛ بعدا ارتباطات متنی مثل xml و json مد شد، و بعد دوباره قالبها و ارتباطاتی باینری مثل protocol buffers باب شد در بخشی از ارتباطات.
در مجموع، هر کس هر طور مایله! اما به نظر شخصی من این اصل خیلی بیش از بخشهای دیگه جای بحث و اما و اگر داره؛ و شخصا هم اعتقادی ندارم که همه جا قالب متنی رویکرد مناسبی باشه، مخصوصا برای نگهداری وضعیت داخلی یک برنامه. به هر حال اختلاف نظر همیشه هست... .
خلاصه
- فلسفه یونیکس لزوما و همهجا خوب نیست
- فلسفه یونیکس یک معیار کیفی و قابل تفسیره، و سازگاری با اون لزوما صفر و یک نیست. و ممکنه برآورده کردن معیارهای مختلف اون به صورت همزمان ممکن نباشه
- لزوما هر چی در یونیکس بوده کاملا مطابق با فلسفه یونیکس نیست
- فلسفه یونیکس در مورد «برنامه»ها صحبت میکنه و نه «پروژه»ها یا مجموعه برنامهها
- سیستم SysV init لزوما مطابق با این فلسفه نیست
- «پروژه systemd» شامل مجموعهای از ابزارها یا برنامههاست که زمینههای مختلفی رو پوشش میدن (بوت، مدیریت لاگ، ترجمه فایل fstab، مدیریت شبکه، ترجمه dns، مدیریت سیستم و سرویسها و ...)
- گسترده بودن محدوده پروژه systemd تناقضی با فلسفه یونیکس ندارد (چون یک برنامه نیست)
- «برنامه systemd» وظایف مختلفی رو زیر چتر مدیریت سیستم و سرویسها انجام میده که قبلا توسط چندین برنامه انجام میشده (مثل init، cron، inetd، اسکریپتهای مدیریتی و ...)
- با این وجود، لزوما «برنامه systemd» در تناقض با فلسفه یونیکس نیست، چون میتوان گفت تمامی این کارها در راستای انجام کار اصلی آن به خوبی ست.
- میزان رعایت فلسفه یونیکس در «برنامه systemd» بستگی به تفسیر شما متفاوت است.
- با نگاه سختگیرانه، بسیاری از برنامههای مرسوم ممکن است سازگار با فلسفه یونیکس محسوب نشوند. این معیار، به تنهایی برای قضاوت کافی نیست
- برای برخی، فلسفه یونیکس صرفا بهانه برای مقاومت در برابر تغییر است، و ممکن است حتی خود فلسفه را هم دقیق ندانند.
در پایان، هدف، ارائه تصویری دقیقتر از systemd برای دوستانی بود که کمتر از نزدیک به آن نگاه کرده بودند. مخصوصا که حجم نسبتا زیادی مطالب نه چندان دقیق در مورد این برنامه وجود دارند که خواسته یا ناخواسته منتشر کننده ترس، ابهام و شک[۱] در مورد این مجموعه نرمافزار هستند. تا جایی که حتی برخی تصور میکنند بوت با systemd میتواند کندتر از بوت با sysv init باشد در صورتی که حداقل از نظر منطقی چنین نباید باشد!
[1] https://en.wikipedia.org/wiki/Fear,_uncertainty,_and_doubt
هیچ نظری موجود نیست:
ارسال یک نظر