دراگون‌فلای بی‌اس‌دی

دراگون‌فلای بی‌اس‌دی (به انگلیسی: DragonFly BSD) یک سیستم‌عامل آزاد و شبه یونیکس است که از فری‌بی‌اس‌دی ۴٫۸ منشعب شده‌است. بنیان‌گذار این پروژه، متیو دیلون[و 1] است که یک توسعه‌دهندهٔ آمیگا در اواخر دههٔ ۱۹۸۰ و اوایل ۱۹۹۰ و همچنین یکی از توسعه‌دهندگان فری‌بی‌اس‌دی طی سال‌های ۱۹۹۴ تا ۲۰۰۳ بود. او کار بر روی دراگون‌فلای بی‌اس‌دی را در ژوئن ۲۰۰۳ آغاز کرد و خبر آغاز بکار این پروژه را در ۱۶ ژوئن ۲۰۰۳ در لیست پستی فری‌بی‌اس‌دی اعلام کرد. دراگون‌فلای در زبان انگلیسی به معنای سنجاقک است.

دراگون‌فلای بی‌اس‌دی
بوت لودر دراگون‌فلای بی‌اس‌دی 4.2.4
توسعه‌دهندهمتیو دیلون و دیگر مشارکت‌کنندگان
خانوادهشبه یونیکس (بی‌اس‌دی)
وضعیت توسعهدر جریان
مدل منبعنرم‌افزار آزاد
انتشار پایدار4.8.0
۲۴ مارس ۲۰۱۷ (۲۰۱۷-۰۳-24)
مخزن
مدیر بستهpkgng، DPorts
نوع هستهپیوندی
فضای کاربریبی‌اس‌دی
پروانهپروانه بی‌اس‌دی
وبگاه رسمی
وضعیت پشتیبانی
پشتیبانی جامعه کاربری

دیلون به این دلیل پروژه دراگون‌فلای بی‌اس‌دی را آغاز کرد که باور داشت روش‌ها و تکنیک‌هایی که در فری‌بی‌اس‌دی نسخه ۵[1] برای پیاده‌سازی چند پردازشی متقارن و ریسه‌بندی انتخاب شده بود، باعث می‌شد تا عملکرد سیستم ضعیف شود و نگهداری از کدهای منبع آن سخت شود. او قصد داشت این مشکلات را در فری‌بی‌اس‌دی اصلاح کند[2] اما به دلیل اختلاف نظر با دیگر توسعه‌دهندگان فری‌بی‌اس‌دی بر سر پیاده‌سازی این ایده‌ها،[3] سرانجام دسترسی کامیت کردن به صورت مستقیم در درخت کد منبع فری‌بی‌اس‌دی، از او گرفته شد. با این وجود، پروژه‌های فری‌بی‌اس‌دی و دراگون‌فلای بی‌اس‌دی هنوز هم در زمینه‌هایی از جمله رفع باگ‌های نرم‌افزاری، بروزرسانی درایورها و دیگر موارد، با هم همکاری می‌کنند و در ارتباط هستند.[4]

در حال حاضر، توسعهٔ دراگون‌فلای، که قرار بوده ادامه‌دهندهٔ راه سری ۴ فری‌بی‌اس‌دی باشد، فاصلهٔ زیادی با نسخه‌های حال حاضر فری‌بی‌اس‌دی گرفته‌است. یک پیاده‌سازی جدید از ریسه‌های کرنلی سبک وزن[و 2]، یک سامانه مدیریت بسته/درخت پورت‌های سبک‌وزن، یک سیستم پیام‌رسانی کم‌حجم، و یک فایل سیستم مدرن با امکانات زیاد به نام HAMMER، از جمله فناوری‌هایی هستند که توسط پروژهٔ دراگون‌فلای معرفی شده‌اند.[5] اهداف پروژهٔ دراگون‌فلای بی‌اس‌دی، عمدتاً با الهام‌گیری از سیستم‌عامل آمیگااواس تدوین شده‌اند.[6]

تاریخچه
متیو دیلون، بنیان‌گذار و رهبر دراگون‌فلای بی‌اس‌دی

پروژهٔ دراگون‌فلای بی‌اس‌دی، توسط متیو دیلون (زادهٔ ۱۹۶۶)، مهندس نرم‌افزار اهل ایالات متحده آمریکا بنیان نهاده شد. او در رشته‌های مهندسی الکترونیک و علوم رایانه در دانشگاه کالیفرنیا، برکلی تحصیل کرده‌است و اولین بار در همان دانشگاه در سال ۱۹۸۵ با بی‌اس‌دی آشنا شد. دیلون همچنین بخاطر نوشتن یک کامپایلر برای زبان برنامه‌نویسی سی بنام DICE، برنامه‌نویسی بر روی آمیگا، کار بر روی هستهٔ لینوکس و همچنین کشف یک باگ در پردازندهٔ مدل اوپترون شرکت AMD[7] شناخته می‌شود. او بنیان‌گذار BEST Internet بود و طی سال‌های ۱۹۹۴ تا ۱۹۹۷ در همان‌جا مشغول به‌کار بود و همچنین در پروژهٔ فری‌بی‌اس‌دی هم مشارکت می‌کرد. دیلون یک برنامهٔ خبررسان اینترنتی به نام «دیابلو» نوشته بود که برنامهٔ محبوبی در میان ارائه‌دهندگان خدمات اینترنتی[و 3] بود. دیلون در سال ۱۹۹۷، دسترسی کامیت به کد منبع فری‌بی‌اس‌دی دریافت کرد و در کنار مشارکت‌های دیگرش در این پروژه، کمک‌های زیادی به زیرسیستم حافظهٔ مجازی در این سیستم‌عامل کرد. او در سال ۲۰۰۳ پروژهٔ دراگون‌فلای بی‌اس‌دی را با انشعاب از فری‌بی‌اس‌دی بنیان نهاد.[8] علت این‌کار، کشمکش و نزاع با دیگر توسعه‌دهندگان فری‌بی‌اس‌دی بود که باعث شده بود دسترسی او به مخازن کد منبع فری‌بی‌اس‌دی قطع شود.[9] پروژهٔ دراگون فلی‌بی‌اس‌دی منجر به توسعه‌یافتن یک فایل سیستم جدید به نام HAMMER شد که دیلون این فایل سیستم را براساس ساختاردادهٔ درخت بی نوشته است. HAMMER در کنار UFS، فایل سیستم پیشفرض در سیستم‌عامل دراگون‌فلای است.[10][11]

ساختار سیستم

هسته

هستهٔ دراگون‌فلای یک هستهٔ پیوندی است که هم ویژگی‌های هستهٔ یکپارچه و هم ویژگی‌های ریزهسته را باهم دارد. برای مثال، هستهٔ دراگون‌فلای مجهز به قابلیت ارسال پیغام است که در ریزهسته‌ها پیدا می‌شود؛ این قابلیت اجازه می‌دهد تا قسمت‌های بیشتری از سیستم‌عامل بتواند از حافظهٔ محافظت‌شده بهره‌مند گردد، به‌طوری‌که همچنان در انجام برخی از کارهای حیاتی، سرعتی برابر با سرعت هسته‌های یکپارچه را داشته باشد. زیرسیستم پیام‌رسانی دراگون‌فلای بی‌اس‌دی، مشابه دیگر زیرسیستم‌های پیام‌رسانی — که در برخی ریزهسته‌ها از جمله گنو ماخ یافت می‌شوند — طراحی شده‌است؛ با این حال، طراحی زیرسیستم پیام‌رسانی دراگون‌فلای از پیچیدگی کمتری برخوردار است. این زیرسیستم، هم می‌تواند به صورت همگام[و 4] و هم به صورت ناهمگام[و 5] عمل کند و تلاش می‌کند تا از این توانایی به نحوی استفاده کند که در هر موقعیتی، بهترین کارایی ممکن حاصل شود.[12]

بر طبق گفتهٔ توسعه‌دهندهٔ دراگون‌فلای بی‌اس‌دی، متیو دیلون، پیشرفت‌هایی هم در آماده‌سازی قابلیت پیام‌رسانی هم برای دستگاه‌های ورودی/خروجی و هم برای فایل سیستم مجازی حاصل شده‌است که برآورده شدن باقی اهداف پروژه را تسهیل می‌کند. زیرساخت جدید، این امکان را فراهم می‌کند تا بتوان بسیاری از بخش‌های هسته را به فضای کاربری منتقل کرد. در فضای کاربری، می‌توان این بخش‌ها را راحت‌تر اشکال‌زدایی کرد، چرا که برنامه‌ها در فضای کاربری، کوچکتر و منزوی‌تر هستند؛ برخلاف برنامه‌های موجود در هسته که معمولاً برنامه‌ها بخش‌های کوچکی از یک قطعه کد بزرگتر به حساب می‌آیند و مدیریت آن‌ها سخت‌تر است. علاوه بر آن، منتقل کردن کدهای هسته به بخش فضای کاربری، باعث پایدارتر شدن و مستحکم‌تر شدن سیستم می‌شود، به عنوان مثال، اگر یکی از گرداننده‌های دستگاه دچار اشکال شود، تنها همان بخش تحت تأثیر قرار خواهد گرفت و در کار کل هسته اختلال ایجاد نخواهد کرد.[13]

فراخوان‌های سیستمی به دو بخش فضای کاربری و فضای هسته تقسیم شده‌اند و در پیام‌ها کپسوله‌سازی می‌شوند. این کار باعث می‌شود تا با منتقل کردن برخی از فرخوان‌های سیستمی استاندارد، به یک لایهٔ سازگاری که در فضای کاربری قرار دارد، پیچیدگی و حجم هستهٔ سیستم‌عامل کمتر شود. علاوه بر آن، این کار حفظ سازگاری بین نسخه‌های پسین و پیشین دراگون‌فلای را هم راحت‌تر می‌کند. کدهای مربوط به سازگاری با لینوکس و دیگر سیستم‌عامل‌های شبه یونیکس هم به بیرون از هسته منتقل شده‌اند.[6]

دراگون‌فلای بی‌اس‌دی هم همانند جد خود فری‌بی‌اس‌دی، از قابلیت زندان‌ها پشتیبانی می‌کند که مدل پیشرفته‌تری از chroot است. به کمک زندان‌ها، می‌توان چند سیستم‌عامل مهمان را به صورت هم‌زمان بر روی دراگون‌فلای اجرا کرد، به‌طوری‌که هستهٔ سیستم میزبان، بین همهٔ آن‌ها به اشتراک گذاشته می‌شود. اما زندان‌ها را نمی‌توان به معنای واقعی کلمه، یک راه حل مجازی‌سازی به حساب آورد، چرا که سیستم‌عامل‌های مهمان تنها می‌توانند مشابه سیستم میزبان، دراگون‌فلای بی‌اس‌دی، باشند.[6]

ریسه‌بندی

از آنجایی که پشتیبانی از چندین معماری پردازنده، باعث می‌شود تا پشتیبانی کردن از چند پردازشی متقارن هم پیچیده‌تر شود،[3] پروژه دراگون‌فلای بی‌اس‌دی، پشتیبانی از سکوهای سخت‌افزاری خود را محدود به تنها سکوی x86-64 کرده‌است.[14] دراگون‌فلی در ابتدا از سکوی x86 هم پشتیبانی می‌کرد، با این حال در نسخهٔ ۴٫۰ پشتیبانی از سکو قطع شد. و در نسخه ۴.۰، به‌طور کلی پشتیبانی از 32-bit را متوقف کرد، دراگون‌فلای بی‌اس‌دی از نسخهٔ ۱٫۱۰ به بعد، از ریسه‌بندی فضای کاربری به صورت ۱:۱ پشتیبانی می‌کند (یک ریسه در هسته، به ازای هر ریسه در فضای کاربری)[15] که در مقایسه با مدل N:M راه‌حلی نسبتاً آسان محسوب می‌شود و پیاده‌سازی و نگهداری از آن هم راحت‌تر است.[6] همچنین، دراگون‌فلای پشتیبانی از چندریسگی را از فری‌بی‌اس‌دی به ارث برده است و از این قابلیت پشتیبانی می‌کند.[16]

در دراگون‌فلای بی‌اس‌دی، هر یک از پردازنده‌ها، زمان‌بند LWKT مخصوص به خودش را دارد. ریسه‌ها به محض ایجاد شدن، به یک پردازندهٔ خاص اختصاص می‌یابند و هرگز به‌طور قبضه‌کردنی بین پردازنده‌ها تعویض نمی‌شوند؛ تنها راه منتقل کردن یک ریسه از یک پردازنده به پردازنده دیگر، ردوبدل شدن یک پیغام وقفه بین-پردازنده‌ای یا IPI بین پردازنده‌های درگیر است که این پیغام‌ها، به صورت ناهمگام ارسال می‌شوند.[12] یکی از مزایای این نوع زیرسیستم ریسه‌بندی بخش‌بخش شده، این است که در سیستم‌هایی که دارای چندین پردازنده هستند، حافظه‌های نهان موجود بر روی پردازنده‌ها، دارای اطلاعات تکراری و زائد نخواهند بود که این باعث می‌شود هر پردازنده، بتواند از حافظهٔ نهان خود برای ذخیره کردن اطلاعاتی که قرار است بر روی آن کار کند، استفاده کند و به این ترتیب کارایی سیستم بالاتر رود.[6]

از زیرسیستم LWKT به منظور تقسیم کردن کارها در بین چند ریسهٔ هسته، بهره گرفته شده‌است (به عنوان مثال، در کدهای مربوط به بخش شبکه، یک ریسه به ازای هر پروتکل در هر پردازنده وجود دارد)، این کار باعث می‌شود تا رقابت برای بدست آوردن منابع سیستمی کمتر شود، چرا که دیگر نیاز نیست تا برخی از منابع سیستم در بین تسک‌های[و 6] هسته به اشتراک گذاشته شود.[3]

حفاظت از منابع اشتراکی

به منظور اینکه سیستم‌عامل بر روی رایانه‌هایی که دارای چندین پردازنده هستند، به صورت ایمن اجرا شود، دسترسی به منابع مشترک (همانند فایل‌ها و ساختمان داده‌ها) باید به صورت نوبتی باشد تا فرایندها یا ریسه‌ها سعی نکنند یک منبع مشترک را به صورت هم‌زمان تغییر داده و دستکاری کنند. به منظور اینکه چندین ریسهٔ مختلف نتوانند به صورت هم‌زمان یک منبع مشترک را تغییر داده یا مورد دسترسی قرار دهند، دراگون‌فلای از نواحی بحرانی و همین‌طور از توکن‌های نوبت‌بندی استفاده می‌کند. در حالیکه هم لینوکس و هم فری‌بی‌اس‌دی ۵، به منظور بدست آوردن کارایی بالا در سیستم‌های چندپردازنده‌ای، از مدل‌های جامع و دقیق مبتنی بر mutex برای کنترل دسترسی به منابع اشتراکی استفاده می‌کنند، دراگون‌فلای بی‌اس‌دی این‌گونه نیست.[3] تا همین اواخر، دراگون‌فلای بی‌اس‌دی از splها هم استفاده می‌کرد، اما اکنون آن‌ها با نواحی بحرانی جایگزین شده‌اند.

بیشتر بخش‌های اصلی سیستم، از جمله زیرسیستم LWKT، زیرسیستم پیام‌رسانی IPI و تخصیص‌دهندهٔ حافظهٔ هستهٔ جدید، به صورت قفل‌نشدنی هستند؛ به این معنی که آن‌ها از mutexها استفاده نمی‌کنند و هر یک از فرایندها هم بر روی یک پردازنده اجرا می‌شود. برای هر پردازنده، ناحیه‌ای بحرانی وجود دارد که از آن برای حفاظت در برابر وقفه‌های محلی استفاده می‌شود؛ این کار تضمین می‌کند ریسه‌ای که هم‌اکنون در حال اجراست، قبضه نخواهد شد.[15]

برای جلوگیری از وقوع دسترسی هم‌زمان از طرف دیگر پردازنده‌ها، از توکن‌های نوبت‌بندی استفاده شده‌است و چند ریسه می‌توانند به‌طور هم‌زمان این توکن‌ها را در اختیار داشته باشند تا این اطمینان حاصل شود که در هر زمان، تنها یکی از آن ریسه‌ها می‌تواند اجرا می‌شود. ریسه‌های مسدودشده یا به‌خواب‌رفته، از دسترسی دیگر ریسه‌ها به منابع مشترک جلوگیری نمی‌کنند که این برخلاف حالتی است که از mutex‌ها برای کنترل دسترسی به منابع مشترک استفاده می‌شود. در کنار دیگر چیزها، استفاده از توکن‌های نوبت‌بندی از بسیاری از موقعیت‌هایی که ممکن است باعث وقوع بن‌بست یا واژگونی اولویتی در حین استفاده از mutexها شود، جلوگیری می‌کند و همچنین به‌طور قابل ملاحظه‌ای طراحی و پیاده‌سازی رویهٔ چند مرحله‌ای را ساده‌تر می‌کند که احتیاج به این دارد که یک منبع در میان چند ریسه به اشتراک گذاشته شود. زیرسیستم توکن نوبت‌بندی، در حال حاضر بسیار شبیه به ویژگی Read-copy-update در لینوکس شده‌است. اما برخلاف پیاده‌سازی فعلی RCU در لینوکس، این بخش در دراگون‌فلای طوری پیاده‌سازی شده که تنها پردازنده‌هایی که بر روی توکن یکسانی در رقابت هستند، تحت تأثیر قرار می‌گیرند، نه کل پردازنده‌های موجود در سیستم.[17]

دراگون‌فلای از یک تخصیص‌دهنده پاره‌ای استفاده می‌کند که برای اختصاص دادن حافظه به برنامه‌ها، نه نیاز به استفاده از mutexها و نه نیاز به انجام عملیاتی از نوع مسدودشدنی دارد.[18] این تخصیص‌دهنده، برای استفاده در فضای کاربری، به کتابخانه استاندارد سی هم پورت شده و جای پیاده‌سازی malloc فری‌بی‌اس‌دی را گرفته‌است.[19]

هسته مجازی

از نسخهٔ ۱٫۸ به بعد، دراگون‌فلای بی‌اس‌دی یک راهکار مجازی‌سازی مشابه UML[20] را معرفی کرده که به کمک آن می‌توان یک هستهٔ دیگر که از هستهٔ اصلی سیستم‌عامل مستقل است را در داخل فضای کاربری اجرا کرد. این هستهٔ مجازی[و 7]، در یک محیط کاملاً مجزا و قرنطینه اجرا می‌شود و رابط‌های شبکه و رابط‌های ذخیره‌سازی آن هم به صورت شبیه‌سازی‌شده هستند. این قابلیت، خوشه‌بندی و آزمایش کردن زیرسیستم‌های مختلف هسته را ساده‌تر می‌کند.[6][13]

هستهٔ مجازی دو تفاوت عمده با هستهٔ اصلی سیستم‌عامل دارد. یکی اینکه این هستهٔ مجازی، بسیاری از روتین‌ها و قابلیت‌های مدیریت سطح پایین سخت‌افزار را ندارد و همچنین تا جایی که امکان دارد از توابع موجود در کتابخانه استاندارد سی، در عوض پیاده‌سازی‌های موجود در هسته، استفاده می‌کند. از آنجایی که هم هستهٔ مجازی و هم هستهٔ واقعی از روی کد منبع یکسانی کامپایل می‌شوند، رویه‌های وابسته به پلتفرم[و 8] و پیاده‌سازی‌های مجدد توابع کتابخانه استاندارد سی به‌طور کاملاً مستقل در درخت کدهای منبع نگهداری می‌شوند.[4]

سکویی که هستهٔ مجازی بر روی آن اجرا می‌شود، در اصل یک لایهٔ انتزاعی سطح بالا است که هستهٔ اصلی آن را فراهم کرده. این لایهٔ انتزاعی شامل یک زمان‌سنج مبتنی بر kqueue، یک کنسول (که در اصل همان ترمینالی است که هستهٔ مجازی از طریق آن اجرا شده)، ایمیج هارددیسک (یک فایل که با آن مثل دیسک سخت رفتار می‌شود) و یک رابط اترنت، که تمامی بسته‌های دریافتی را به رابط tap سیستم میزبان تونل می‌زند.[21]

مدیر بسته

در دراگون‌فلای بی‌اس‌دی، می‌توان از طریق pkgng، نرم‌افزارهای جانبی را به صورت بسته‌های باینری از قبل کامپایل شده نصب کرد یا اینکه از طریق یک مجموعه پورت‌های مختص خود دراگون‌فلای که دی‌پورتز[و 9] نام دارد، اقدام به نصب برنامه‌های جانبی کرد.[22]

دراگون‌فلای بی‌اس‌دی در اوایل از پورت‌های فری‌بی‌اس‌دی به‌عنوان مدیر بستهٔ اصلی خود استفاده می‌کرد. اما از نسخهٔ ۱٫۴ به بعد، توسعه‌دهندگان، پکیج سورس را به‌عنوان مدیر بستهٔ رسمی برگزیدند. به این ترتیب، توسعه‌دهندگان دراگون‌فلای بی‌اس‌دی مجبور نبودند وقت زیادی را برای نگه‌داری کردن از تعداد زیادی برنامه جانبی صرف کنند، در حالی که هنوز هم به برنامه‌های بروز دسترسی داشتند. همچنین این کار به توسعه‌دهندگان پکیج سورس هم این امکان را می‌داد تا مطمئن شوند که سامانهٔ مدیریت بسته آن‌ها قابل حمل و سازگارپذیر است.[2][23]

سازگار نگه‌داشتن دراگون‌فلای بی‌اس‌دی با پکیج‌سورس، نیازمند تلاش‌ها و زحمات بیشتری شده بود که در ابتدا پیش‌بینی نشده بود؛ بنابراین، پروژهٔ دراگون‌فلای مکانیزم جدیدی به نام DPorts را معرفی کرد که در اصل یک پوسته برای پورت‌های فری‌بی‌اس‌دی است.[24][25]

CARP

پیاده‌سازی اولیه از پروتکل آدرس اضافه مشترک یا همان CARP در مارس ۲۰۰۷ به اتمام رسید.[26] در سال ۲۰۱۱ هم پشتیبانی از این پروتکل به دراگون‌فلای بی‌اس‌دی اضافه شد.[27]

فایل سیستم HAMMER
نوشتار اصلی: HAMMER

در کنار سیستم فایل یونیکس، که در اکثر سیستم‌عاملهای بی‌اس‌دی فایل سیستم پیشفرض است، دراگون‌فلای بی‌اس‌دی فایل سیستم جدیدی به نام HAMMER را معرفی کرده‌است. فایل سیستم HAMMER که اختصاصاً برای دراگون‌فلای توسعه داده شده، فایل سیستمی مشابه ZFS با امکانات بالا و در عین حال با طراحی بهتر است.[6][13][28]

HAMMER از تاریخچهٔ فایل سیستم قابل تنظیم‌شدن، تصویر لحظه‌ای، چک‌سام، جلوگیری از ذخیره‌شدن اطلاعات دوگانه و تکراری و دیگر قابلیت‌های معمول در فایل سیستم‌هایی از این قبیل پشتیبانی می‌کند.[20] این فایل سیستم به عنوان یکی از قابلیت‌های جالب توجه دراگون‌فلای در نظر گرفته می‌شود.[29]

نسل جدید این فایل سیستم موسوم به ،HAMMER2 توسط متیو دیلون در حال توسعه داده شدن است.[30] فایل سیستم HAMMER2 در نسخه ۳٫۸ دراگون‌فلای در نصب پیشفرض قرار گرفت، اما هنوز قابل استفاده نیست و توسعهٔ آن هنوز هم ادامه دارد.[31]

devfs

در سال ۲۰۰۷ پروژهٔ دراگون‌فلای بی‌اس‌دی از یک فایل سیستم دستگاهی جدید بهره‌مند گشت که گره‌های دستگاهی را به صورت پویا حذف و اضافه می‌کند و دسترسی به دستگاه‌ها را با استفاده از مسیرهای ارتباطی میسر می‌سازد. همچنین، این فایل سیستم، می‌تواند درایورها را با استفاده از شماره سریال آن‌ها شناسایی کند و دیگر به یک فایل سیستم از قبل پر شده در مسیر ‎/dev احتیاج ندارد. این سیستم devfs در پروژهٔ تابستان کد گوگل طراحی شده‌است.[32]

تصاویر لحظه‌ای از برنامه‌های کاربردی

دراگون‌فلای بی‌اس‌دی از قابلیتی مشابه قابلیت برنامه‌های مقیم[و 10] در سیستم‌عامل آمیگا پشتیبانی می‌کند. به موجب این قابلیت، وقتی که یک برنامهٔ بزرگ که به صورت دینامیک لینک شده، در حافظه اصلی سیستم بارگذاری می‌شود، یک تصویر لحظه‌ای از فضای حافظه مجازی آن برنامه، برای استفاده در آینده، تهیه می‌شود. به این ترتیب، اگر در آینده نیاز به اجرای مجدد آن برنامه بود، برنامه مورد نظر با سرعتی بسیار بیشتر از حد معمول خود اجرا خواهد شد. این قابلیت، جایگزین prelink شده‌است که در گذشته‌استفاده می‌شد و از آن بسیار مؤثرتر است. برنامه‌های بزرگ که دارای کتابخانه‌های اشتراکی زیادی هستند، بیشترین فایده را از این قابلیت خواهند برد.[33]

توسعه و توزیع

دراگون‌فلای بی‌اس‌دی حدود ۵۰ توسعه‌دهنده دارد.[34] همانند فری‌بی‌اس‌دی و اوپن‌بی‌اس‌دی، توسعه‌دهندگان دراگون‌فلای بی‌اس‌دی هم به آهستگی مشغول جایگزین کردن کدهای خود از شیوهٔ K&R با معادل مدرن‌تر ANSI هستند. همانند دیگر سیستم‌عامل‌ها، قابلیت حفاظت در برابر حملات تخریب پشته به صورت پیشفرض در کامپایلر فعال است. قابل ذکر است که از تاریخ ۲۳ ژوئیهٔ ۲۰۰۵ به بعد، هستهٔ سیستم دیگر به صورت پیشفرض با خاموش بودن این قابلیت کامپایل می‌شود.[33]

از آنجایی که دراگون‌فلای بی‌اس‌دی از فری‌بی‌اس‌دی مشتق شده‌است، به راحتی و با اجرای چند دستور ساده می‌توان اقدام به کامپایل مجدد کل سیستم‌عامل از روی کدهای منبع کرد. توسعه‌دهندگان دراگون‌فلای بی‌اس‌دی، از برنامهٔ گیت برای نگهداری، اعمال تغییرات و کنترل کدهای منبع خود استفاده می‌کنند. برخلاف فری‌بی‌اس‌دی، توسعه‌دهندگان دراگون‌فلای بی‌اس‌دی، به سبب کوچکتر بودن تیم توسعه‌دهندگان، هر دو شاخهٔ پایدار و ناپایدار کدهای منبع را در یک درخت نگه می‌دارند.[3]

سیستم‌عامل دراگون‌فلای بی‌اس‌دی به صورت دیسک زنده و USB زنده ارائه می‌شود. این دیسک‌ها را می‌توان به صورت رایگان، به همراه کدهای منبع، از وب‌گاه رسمی این سیستم‌عامل دریافت کرد. تعدادی از شرکت‌های تجاری هم این دیسک‌ها را به‌فروش می‌رسانند.[35] بدون اینکه نیازی به نصب سیستم‌عامل باشد، می‌توان کل سیستم‌عامل را با تمام قابلیت‌های آن از روی همین رسانه‌ها راه‌اندازی کرد.[20][32] همچنین تمامی اجزای X11 هم در این دیسک گنجانده شده‌است. این دیسک شامل تمام اجزای پایه‌ای سیستم‌عامل و همین‌طور صفحات راهنما است؛ اما ممکن است در آینده کدهای منبع سیستم‌عامل و همچنین تعدادی نرم‌افزار مفید دیگر هم در آن گنجانده شود. مزیت این کار این است که تنها با داشتن یک CD، هم می‌توان سیستم‌عامل را بر روی هارد دیسک نصب کرد، هم می‌توان بدون نیاز به نصب سیستم‌عامل، از ابزارها و قابلیت‌های آن برای اهداف گوناگونی مانند تعمیر یک سیستم‌عامل آسیب دیده و ... استفاده کرد و هم می‌توان سیستم‌عامل را بدون نیاز به نصب آن، آزمایش کرد.

لوگوی سیستم‌عامل دراگون‌فلای بی‌اس‌دی، یک آسیابک است که توسط جو انگریزانو[و 11] ترسیم شده‌است.[36] همانند دیگر سیستم‌عامل‌های متن‌باز خانوادهٔ بی‌اس‌دی، دراگون‌فلای هم تحت اجازه‌نامهٔ بی‌اس‌دی عرضه می‌شود. دیلون نقش این پروانه را «به‌طور باورنکردنی مهم» خوانده است.[13] چرخهٔ انتشار دراگون‌فلای، معمولاً هر شش ماه بوده و دو نسخه از این سیستم در سال عرضه می‌شود.[4] این سیستم‌عامل از یک نصاب به نام BSD Installer استفاده می‌کند که از یک واسط متنی برخوردار است و به FreeSBIE و pfSense هم پورت شده‌است.[4]

تاریخچه تغییرات بین نسخه‌ها
نسخه تاریخ[37] تغییرات
4.2 ۰۲۰۱۵−۰۶−۲۹ ۲۹ ژوئن ۲۰۱۵
  • GCC نسخه 5.1.1
  • بهبود پشتیبانی از i915 و Radeon
  • بهبود پشتیبانی از صدا
  • بهبود پشتیبانی از کنترلر حافظه و سنسورها دما
  • Path MTU Discovery به‌طور پیشفرض فعال شد
  • پشتیبانی از اس‌سی‌تی‌پی حذف شد
  • Sendmail با DragonFly Mail Agent جایگزین شد
  • صفحات راهنمای GNU Info حذف شدند
۴٫۰ ۰۲۰۱۴−۱۱−۲۵ ۲۵ نوامبر ۲۰۱۴
  • پشتیبانی تا سقف ۲۵۶ پردازنده
  • متوقف شدن پشتیبانی از معماری 32-بیت
  • بهبود پشتیبانی از i915
  • پشتیبانی از Rust و FreePascal
  • بهبود وایرلس
  • GCC 4.7.4
  • قابلیت امنیتی Procctl در هسته
  • PF چندریسه‌ای قفل‌نشدنی
۳٫۸ ۰۲۰۱۴−۰۶−۰۴ ۴ ژوئن ۲۰۱۴
  • پیش‌فرض شدن USB4BSD در سیستم
  • آخرین نسخه ۳۲-بیتی، پشتیبانی از این سکو، از این نسخه به بعد متوقف می‌شود.
  • HAMMER2 در سیستم قرار گرفت، اما هنوز برای استفاده آماده نیست
  • جی‌سی‌سی نسخه ۴٫۷٫۳
  • بروزرسانی عمده در درایور drm/ttm/i915 متناسب با DRM نسخه ۳٫۸ لینوکس
۳٫۶ ۰۲۰۱۳−۱۱−۲۵ ۲۵ نوامبر ۲۰۱۳
  • رفع اشکالات SMP
  • KMS برای GPUهای Intel و AMD
  • شتاب‌دهنده سخت‌افزاری برای GPUهای اینتل تا ایوی بریج[38]
۳٫۴ ۰۲۰۱۳−۰۴−۲۹ ۲۹ آوریل ۲۰۱۳
  • مدیر بسته جدیدی موسوم به DPORTS
  • GCC 4.7
  • بهینه‌سازی استفاده از پردازنده و کارایی tmpfs در زیر بار سنگین
۳٫۲ ۰۲۰۱۲−۱۱−۰۲ ۲ نوامبر ۲۰۱۲
  • هسته چندپردازنده‌ای اجباری شد
  • بهینه‌سازی کارایی در زمان‌بند.
  • USB4BSD از FreeBSD پورت شد تا پشتیبانی از USB 3.0 فراهم شود.
  • PUFFS از نت‌بی‌اس‌دی گرفته شد.
۳٫۰ ۰۲۰۱۲−۰۲−۲۲ ۲۲ فوریه ۲۰۱۲
  • هسته چندپردازنده‌ای هسته پیشفرض در سیستم شد
  • بهینه‌سازی در HAMMER
  • پشتیبانی از رمزنگاری سازگار با TrueCrypt
  • dm-crypt با یک کتابخانه سازگار با پروانهٔ بی‌اس‌دی جایگزین شد
  • بهبود سازگاری با استاندارد پازیکس
  • گرداننده دستگاه برای ECC memory
  • بهینه‌سازی عمده در پشته پروتکل شبکه و SMP
  • انجام بهینه‌سازی‌هایی در ACPI
۲٫۱۰ ۰۲۰۱۱−۰۴−۲۶ ۲۶ آوریل ۲۰۱۱
  • قفل بزرگ در همه جا غیر از زیرسیستم حافظه مجازی برداشته شد
  • قابلیت دوگانه‌زدایی داده‌ای[و 12] در HAMMER
  • GCC 4.4
  • بازنویسی سیستم پل‌زنی
  • بهینه‌سازی قابل توجه در کارایی سیستم
۲٫۸ ۰۲۰۱۰−۱۰−۳۰ ۳۰ اکتبر ۲۰۱۰
  • پشته Wi-Fi از FreeBSD گرفته شد
  • مدیریت توده‌ای منطقی
  • dm-crypt
  • یک زمان‌بندی دیسک جدید
  • کاهش استفاده از قفل بزرگ
۲٫۶ ۰۲۰۱۰−۰۴−۰۶ ۶ آوریل ۲۰۱۰
  • swapcache
  • tmpfs از نت‌بی‌اس‌دی گرفته شد
  • بهینه‌سازی HAMMER و به‌طور کلی سیستم ورودی/خروجی
۲٫۴ ۰۲۰۰۹−۰۹−۱۶ ۱۶ سپتامبر ۲۰۰۹
  • devfs
  • درایور AHCI جدید
  • بهینه‌سازی‌هایی در سیستم فایل شبکه‌ای
  • پشتیبانی کامل از x86-64
۲٫۲ ۰۲۰۰۹−۰۲−۱۷ ۱۷ فوریه ۲۰۰۹
  • HAMMER برای استفاده در محیط‌های کاری آماده شد[20]
  • بهینه‌سازی‌های عمده در پایداری سیستم
  • رسانه نصب جدید: LiveDVD و LiveUSB
۲٫۰ ۰۲۰۰۸−۰۷−۲۰ ۲۰ ژوئیه ۲۰۰۸
  • بهینه‌سازی عمده در HAMMER
۱٫۱۲ ۰۲۰۰۸−۰۲−۲۶ ۲۶ فوریه ۲۰۰۸
  • پشته سنسورهای سخت‌افزاری OpenBSD، از روی FreeBSD پورت شد
  • پشته بلوتوث
  • جی‌سی‌سی نسخه 4.1
  • معرفی DragonFly Mail Agent
  • پشتیبانی از پردازنده 386 قطع شد
  • پشتیبانی اولیه از x86-64 (غیرقابل استفاده)
  • پشتیبانی اولیه از HAMMER
۱٫۱۰ ۰۲۰۰۷−۰۸−۰۶ ۶ اوت ۲۰۰۷
  • سیستم ریسه‌بندی در فضای کاربری
  • پشتیبانی از رابط پیشرفته کنترلر میزبان
  • پشتیبانی از جی‌پی‌تی
۱٫۸ ۰۲۰۰۷−۰۱−۳۰ ۳۰ ژانویه ۲۰۰۷
  • پیاده‌سازی هسته مجازی
۱٫۶ ۰۲۰۰۶−۰۷−۲۴ ۲۴ ژوئیه ۲۰۰۶
  • یک تولیدکننده اعداد تصادفی جدید
  • تجدید ساختار در چارچوب IEEE 802.11
  • بهینه‌سازی‌های عمده در قفل بزرگ، کلاسترینگ و VFS فضای کاربری
  • بهینه‌سازی‌های گسترده در پایداری و کارایی سیستم[39]
۱٫۴ ۰۲۰۰۶−۰۱−۰۷ ۷ ژانویه ۲۰۰۶
  • GCC نسخه ۳٫۴
  • استفاده از pkgsrc به صورت پیش‌فرض[39]
  • Citrus از نت‌بی‌اس‌دی گرفته شد[40]
۱٫۲ ۰۲۰۰۵−۰۴−۰۸ ۸ آوریل ۲۰۰۵
  • TCP SACK
  • بهبود کارایی TCP
  • ALTQ و PF
  • مخزن‌گاه محلی ریسه
  • کنسول در IEEE 1394
  • بازنویسی Namecache
  • پشتیبانی از X11
  • پشتیبانی از pkgsrc
۱٫۰ ۰۲۰۰۴−۰۷−۱۲ ۱۲ ژوئیه ۲۰۰۴

جستارهای وابسته

واژه‌نامه
  1. Matthew Dillon
  2. Light Weight Kernel Threads
  3. ISP
  4. synchronous
  5. asynchronous
  6. task
  7. vkernel
  8. platform-dependent
  9. DPorts
  10. resident applications
  11. Joe Angrisano
  12. Data deduplication
  13. application checkpointing

منابع
  1. Lehey, Greg (2001). "Improving the FreeBSD SMP implementation" (PDF). USENIX. Archived from the original (PDF) on 5 June 2014. Retrieved 22 February 2012.
  2. Kerner, Sean Michael (10 January 2006). "New DragonFly Released For BSD Users". InternetNews. Archived from the original on 5 June 2014. Retrieved 20 November 2011.
  3. Biancuzzi, Federico (8 July 2004). "Behind DragonFly BSD". O'Reilly Media. Archived from the original on 5 June 2014. Retrieved 20 November 2011.
  4. Economopoulos, Aggelos (16 April 2007). "A peek at the DragonFly Virtual Kernel". LWN.net. Archived from the original on 5 June 2014. Retrieved 8 December 2011.
  5. Loli-Queru, Eugenia (13 March 2004). "Interview with Matthew Dillon of DragonFly BSD". OSNews. Archived from the original on 5 June 2014. Retrieved 22 February 2012.
  6. Chisnall, David (15 June 2007). "DragonFly BSD: UNIX for Clusters?". InformIT. Archived from the original on 5 June 2014. Retrieved 22 November 2011.
  7. Morgan, Timothy Prickett (7 March 2012). "DragonFly BSD developer stung by Opteron bug". The Register. Archived from the original on 5 June 2014. Retrieved 31 May 2014.
  8. Dillon, Matthew (16 July 2003). "Announcing DragonFly BSD!". freebsd-current mailing list. Archived from the original on 5 June 2014. Retrieved 26 July 2007.
  9. "FreeBSD Core Developer Thrown Out". Slashdot. 03 February 2003. Archived from the original on 5 ژوئن 2014. Retrieved 03 June 2014. Check date values in: |تاریخ بازدید=, |تاریخ= (help)
  10. "Matt Dillon IRC interview". SlashNet. Archived from the original on 5 June 2014. Retrieved 31 May 2014.
  11. Andrews, Jeremy (2 January 2002). "Interview: Matthew Dillon". KernelTrap. Archived from the original on ۱۵ مه ۲۰۱۱. Retrieved 03 June 2014. Check date values in: |تاریخ بازدید= (help)
  12. Hsu, Jeffery M. "The DragonFly BSD Operating System" (PDF). Archived from the original (PDF) on 8 August 2017. Retrieved 20 November 2011.
  13. Andrews, Jeremy (6 August 2007). "Interview: Matthew Dillon". KernelTrap. Archived from the original on 15 May 2011. Retrieved 11 March 2014.
  14. "DragonFly BSD MP Performance Significantly Improved". OSNews. 16 November 2011. Archived from the original on 5 June 2014. Retrieved 19 November 2011.
  15. Luciani, Robert (24 May 2009). "Threading in DragonFly BSD" (PDF). BSDCon. Archived from the original (PDF) on 23 December 2010. Retrieved 11 March 2014.
  16. Sherrill, Justin (11 January 2004). "Paying off already". Archived from the original on 5 June 2014. Retrieved 20 November 2011.
  17. Pistritto, Joe; Dillon, Matthew; Sherrill, Justin C.; et al. (24 April 2004). "Serializing token". kernel mailing list. Archived from the original on 5 February 2017. Retrieved 20 March 2012.
  18. Bonwick, Jeff; Adams, Jonathan (3 January 2002). "Magazines and Vmem: Extending the Slab Allocator to Many CPUs and Arbitrary Resources". USENIX. Archived from the original on 5 ژوئن 2014. Retrieved 20 November 2011. Check date values in: |year= / |date= mismatch (help)
  19. Dillon, Matthew (23 April 2009). "New libc malloc committed". kernel mailing list. Archived from the original on 5 June 2014. Retrieved 8 August 2011.
  20. Vervloesem, Koen (21 April 2010). "DragonFly BSD 2.6: towards a free clustering operating system". LWN.net. Archived from the original on 5 June 2014. Retrieved 19 November 2011.
  21. Economopoulos, Aggelos (16 April 2007). "A peek at the DragonFly Virtual Kernel". LWN.net. Archived from the original on 5 June 2014. Retrieved 8 December 2011.
  22. "HowTo DPorts". DragonFly BSD. Archived from the original on 5 June 2014. Retrieved 2 December 2013.
  23. Weinem, Mark (2007). "10 years of pkgsrc". NetBSD. Archived from the original on 5 June 2014. Retrieved 22 November 2011. |فصل= ignored (help)
  24. Sherrill, Justin (30 September 2013). "Why dports?". DragonFly BSD Digest. Archived from the original on 5 June 2014. Retrieved 2 December 2013.
  25. Sherrill, Justin (29 September 2013). "Any new packages?". users mailing list. Archived from the original on 5 June 2014. Retrieved 2 December 2013.
  26. Buschmann, Jonathan (14 March 2007). "First Patch to get CARP on Dfly". kernel mailing list. Archived from the original on 5 June 2014. Retrieved 20 November 2011.
  27. "CARP(4) manual page". DragonFly On-Line Manual Pages. Archived from the original on 5 June 2014. Retrieved 20 November 2011.
  28. Dillon, Matthew (10 October 2007). "Re: HAMMER filesystem update - design document". kernel mailing list. Archived from the original on 5 June 2014. Retrieved 20 November 2011.
  29. Larabel, Michael (7 January 2011). "Can DragonFlyBSD's HAMMER Compete With Btrfs, ZFS?". Phoronix. Archived from the original on 5 June 2014. Retrieved 20 November 2011. HAMMER does appear to be a very interesting BSD file-system. It is though not quite as fast as the ZFS file-system on BSD, but this is also an original file-system to the DragonFlyBSD project rather than being a port from OpenSolaris. Not only is HAMMER generally faster than the common UFS file-system, but it also has a much greater feature-set.
  30. Dillon, Matthew (8 February 2012). "DESIGN document for HAMMER2 (08-Feb-2012 update)". users. Archived from the original on 5 June 2014. Retrieved 22 February 2012.
  31. "DragonFly Release 3.8". The DragonFly BSD Project. Archived from the original on 5 ژوئن 2014. Retrieved 03 June 2014. Check date values in: |تاریخ بازدید= (help)
  32. Mr (7 January 2010). "DragonFlyBSD with Matthew Dillon". bsdtalk. Archived from the original on 25 April 2012. Retrieved 20 November 2011.
  33. "DragonFly BSD diary". DragonFly BSD. 7 January 2006. Archived from the original on 5 June 2014. Retrieved 19 November 2011.
  34. "team". The DragonFly BSD Project. 18 May 2014. Archived from the original on 18 November 2018. Retrieved 31 May 2014.
  35. "Commercial DragonFly vendors". The DragonFly BSD Project. 5 January 2014. Archived from the original on 5 June 2014. Retrieved 31 May 2014.
  36. "Images". The DragonFly BSD Project. 14 December 2010. Archived from the original on 5 June 2014. Retrieved 31 May 2014.
  37. "DragonFly: Releases". DragonFly BSD. Archived from the original on 5 June 2014. Retrieved 22 November 2011.
  38. Tigeot, François (31 July 2007). "KMS + i915 support now in -master". users mailing list. Archived from the original on 5 June 2014. Retrieved 2 December 2013.
  39. Kerner, Sean Michael (25 July 2006). "DragonFly BSD 1.6 Cuts the Cord". InternetNews. Archived from the original on 5 June 2014. Retrieved 20 November 2011.
  40. Townsend, Trent (18 January 2006). "A Quick Review of DragonFly BSD 1.4". OSNews. Archived from the original on 5 June 2014. Retrieved 16 November 2011.

پیوند به بیرون
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.