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

از ویکی‌پدیا، دانشنامهٔ آزاد
پرش به: ناوبری، جستجو
دراگون‌فلای بی‌اس‌دی
DragonFly BSD Logo svg.svg
DragonFly BSD 2.10.1 boot loader screenshot.png
بوت لودر دراگون‌فلای بی‌اس‌دی ۲٫۱۰٫۱
شرکت / توسعه‌دهنده متیو دیلون و دیگر مشارکت‌کنندگان
خانواده شبه یونیکس (بی‌اس‌دی)
وضعیت توسعه در جریان
نوع منبع نرم‌افزار آزاد
تاریخ اولین انتشار ۱۲ ژوئیه ۲۰۰۴ (۲۰۰۴-07-۱۲)
آخرین نسخه پایدار 3.8.2 / ۸ اوت ۲۰۱۴؛ ۵۴ روز پیش
زبان(های) در دسترس انگلیسی
مدیر بسته پکیج سورس، DPorts
پلاتفرم x86 و x86-64
نوع هسته پیوندی
فضای کاربری بی‌اس‌دی
واسط کاربری واسط خط فرمان
پروانه پروانه بی‌اس‌دی
وب‌گاه رسمی dragonflybsd.org
وضعیت پشتیبانی پشتیبانی جامعه کاربری

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

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

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

تاریخچه[ویرایش]

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

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

ساختار سیستم[ویرایش]

هسته[ویرایش]

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

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

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

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

ریسه‌بندی[ویرایش]

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

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

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

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

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

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

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

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

هسته مجازی[ویرایش]

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

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

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

مدیر بسته[ویرایش]

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

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

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

CARP[ویرایش]

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

سیستم‌فایل HAMMER[ویرایش]

نوشتار اصلی: HAMMER

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

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

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

devfs[ویرایش]

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

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

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

توسعه و توزیع[ویرایش]

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

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

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

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

تاریخچه تغییرات بین نسخه‌ها[ویرایش]

نسخه تاریخ[۳۷] تغییرات
۳٫۸ 02014-06-04 ۴ ژوئن ۲۰۱۴
  • پیش‌فرض شدن USB4BSD در سیستم
  • آخرین نسخه ۳۲-بیتی، پشتیبانی از این سکو، از این نسخه به بعد متوقف می‌شود.
  • HAMMER2 در سیستم قرار گرفت، اما هنوز برای استفاده آماده نیست
  • جی‌سی‌سی نسخه ۴٫۷٫۳
  • بروزرسانی عمده در درایور drm/ttm/i915 متناسب با DRM نسخه ۳٫۸ لینوکس
۳٫۶ 02013-11-25 ۲۵ نوامبر ۲۰۱۳
  • رفع اشکالات SMP
  • KMS برای GPUهای Intel و AMD
  • شتاب‌دهنده سخت‌افزاری برای GPUهای اینتل تا ایوی بریج[۳۸]
۳٫۴ 02013-04-29 ۲۹ آوریل ۲۰۱۳
  • مدیر بسته جدیدی موسوم به DPORTS
  • GCC 4.7
  • بهینه‌سازی استفاده از پردازنده و کارایی tmpfs در زیر بار سنگین
۳٫۲ 02012-11-02 ۲ نوامبر ۲۰۱۲
  • هسته چندپردازنده‌ای اجباری شد
  • بهینه‌سازی کارایی در زمان‌بند.
  • USB4BSD از FreeBSD پورت شد تا پشتیبانی از USB 3.0 فراهم شود.
  • PUFFS از نت‌بی‌اس‌دی گرفته شد.
۳٫۰ 02012-02-22 ۲۲ فوریه ۲۰۱۲
  • هسته چندپردازنده‌ای هسته پیشفرض در سیستم شد
  • بهینه‌سازی در HAMMER
  • پشتیبانی از رمزنگاری سازگار با TrueCrypt
  • dm-crypt با یک کتابخانه سازگار با پروانهٔ بی‌اس‌دی جایگزین شد
  • بهبود سازگاری با استاندارد پازیکس
  • گرداننده دستگاه برای ECC memory
  • بهینه‌سازی عمده در پشته پروتکل شبکه و SMP
  • انجام بهینه‌سازی‌هایی در ACPI
۲٫۱۰ 02011-04-26 ۲۶ آوریل ۲۰۱۱
  • قفل بزرگ در همه جا غیر از زیرسیستم حافظه مجازی برداشته شد
  • قابلیت دوگانه‌زدایی داده‌ای[و ۱۳] در HAMMER
  • GCC 4.4
  • بازنویسی سیستم پل‌زنی
  • بهینه‌سازی قابل توجه در کارایی سیستم
۲٫۸ 02010-10-30 ۳۰ اکتبر ۲۰۱۰
۲٫۶ 02010-04-06 ۶ آوریل ۲۰۱۰
  • swapcache
  • tmpfs از نت‌بی‌اس‌دی گرفته شد
  • بهینه‌سازی HAMMER و به طور کلی سیستم ورودی/خروجی
۲٫۴ 02009-09-16 ۱۶ سپتامبر ۲۰۰۹
۲٫۲ 02009-02-17 ۱۷ فوریه ۲۰۰۹
  • HAMMER برای استفاده در محیط‌های کاری آماده شد[۲۰]
  • بهینه‌سازی‌های عمده در پایداری سیستم
  • رسانه نصب جدید: LiveDVD و LiveUSB
۲٫۰ 02008-07-20 ۲۰ ژوئیه ۲۰۰۸
  • بهینه‌سازی عمده در HAMMER
۱٫۱۲ 02008-02-26 ۲۶ فوریه ۲۰۰۸
  • پشته سنسورهای سخت‌افزاری OpenBSD، از روی FreeBSD پورت شد
  • پشته بلوتوث
  • جی‌سی‌سی نسخه 4.1
  • معرفی DragonFly Mail Agent
  • پشتیبانی از پردازنده 386 قطع شد
  • پشتیبانی اولیه از x86-64 (غیرقابل استفاده)
  • پشتیبانی اولیه از HAMMER
۱٫۱۰ 02007-08-06 ۶ اوت ۲۰۰۷
۱٫۸ 02007-01-30 ۳۰ ژانویه ۲۰۰۷
  • پیاده‌سازی هسته مجازی
۱٫۶ 02006-07-24 ۲۴ ژوئیه ۲۰۰۶
  • یک تولیدکننده اعداد تصادفی جدید
  • تجدید ساختار در چارچوب IEEE 802.11
  • بهینه‌سازی‌های عمده در قفل بزرگ، کلاسترینگ و VFS فضای کاربری
  • بهینه‌سازی‌های گسترده در پایداری و کارایی سیستم[۳۹]
۱٫۴ 02006-01-07 ۷ ژانویه ۲۰۰۶
  • GCC نسخه ۳٫۴
  • استفاده از pkgsrc به صورت پیش‌فرض[۳۹]
  • Citrus از نت‌بی‌اس‌دی گرفته شد[۴۰]
۱٫۲ 02005-04-08 ۸ آوریل ۲۰۰۵
۱٫۰ 02004-07-12 ۱۲ ژوئیه ۲۰۰۴

جستارهای وابسته[ویرایش]

واژه‌نامه[ویرایش]

  1. Matthew Dillon
  2. Light Weight Kernel Threads
  3. BEST Internet
  4. ISP
  5. synchronous
  6. asynchronous
  7. task
  8. vkernel
  9. platform-dependent
  10. DPorts
  11. resident applications
  12. Joe Angrisano
  13. Data deduplication
  14. application checkpointing

منابع[ویرایش]

  1. Lehey, Greg. “Improving the FreeBSD SMP implementation” (PDF). USENIX, 2001. Archived from the original on 05 June 2014. Retrieved 22 February 2012. 
  2. ۲٫۰ ۲٫۱ Kerner, Sean Michael. “New DragonFly Released For BSD Users”. InternetNews. 10 January 2006. Archived from the original on 05 June 2014. Retrieved 20 November 2011. 
  3. ۳٫۰ ۳٫۱ ۳٫۲ ۳٫۳ ۳٫۴ ۳٫۵ Biancuzzi, Federico. “Behind DragonFly BSD”. O'Reilly Media. 8 July 2004. Archived from the original on 05 June 2014. Retrieved 20 November 2011. 
  4. ۴٫۰ ۴٫۱ ۴٫۲ ۴٫۳ Economopoulos, Aggelos. “A peek at the DragonFly Virtual Kernel”. LWN.net. 16 April 2007. Archived from the original on 05 June 2014. Retrieved 8 December 2011. 
  5. Loli-Queru, Eugenia. “Interview with Matthew Dillon of DragonFly BSD”. OSNews. 13 March 2004. Archived from the original on 05 June 2014. Retrieved 22 February 2012. 
  6. ۶٫۰ ۶٫۱ ۶٫۲ ۶٫۳ ۶٫۴ ۶٫۵ ۶٫۶ Chisnall, David. “DragonFly BSD: UNIX for Clusters?”. InformIT. 15 June 2007. Archived from the original on 05 June 2014. Retrieved 22 November 2011. 
  7. Morgan, Timothy Prickett. “DragonFly BSD developer stung by Opteron bug”. The Register, 7 March 2012. Archived from the original on 05 June 2014. Retrieved 31 May 2014. 
  8. Dillon, Matthew. “Announcing DragonFly BSD!”. freebsd-current mailing list. 16 July 2003. Archived from the original on 05 June 2014. Retrieved 26 July 2007. 
  9. “FreeBSD Core Developer Thrown Out”. Slashdot, 03 February 2003. Archived from the original on 05 June 2014. Retrieved 03 June 2014. 
  10. “Matt Dillon IRC interview”. SlashNet. Archived from the original on 05 June 2014. Retrieved 31 May 2014. 
  11. Andrews, Jeremy. “Interview: Matthew Dillon”. KernelTrap, 2 January 2002. Archived from the original on 15 May 2011. Retrieved 03 June 2014. 
  12. ۱۲٫۰ ۱۲٫۱ Hsu, Jeffery M.. “The DragonFly BSD Operating System” (PDF). Archived from the original on 05 June 2014. Retrieved 20 November 2011. 
  13. ۱۳٫۰ ۱۳٫۱ ۱۳٫۲ ۱۳٫۳ Andrews, Jeremy. “Interview: Matthew Dillon”. KernelTrap. 6 August 2007. Archived from the original on 15 May 2011. 
  14. “DragonFly BSD MP Performance Significantly Improved”. OSNews. 16 November 2011. Archived from the original on 05 June 2014. Retrieved 19 November 2011. 
  15. ۱۵٫۰ ۱۵٫۱ Luciani, Robert. “Threading in DragonFly BSD” (PDF). BSDCon, 24 May 2009. Archived from the original on 23 December 2010. 
  16. Sherrill, Justin. “Paying off already”. 11 January 2004. Archived from the original on 05 June 2014. Retrieved 20 November 2011. 
  17. Pistritto, Joe, Matthew Dillon, Justin C. Sherrill et al. “Serializing token”. kernel mailing list. 24 April 2004. Archived from the original on 05 June 2014. Retrieved 20 March 2012. 
  18. Bonwick, Jeff and Jonathan Adams. “Magazines and Vmem: Extending the Slab Allocator to Many CPUs and Arbitrary Resources”. USENIX, 3 January 2002. Archived from the original on 05 June 2014. Retrieved 20 November 2011. 
  19. Dillon, Matthew. “New libc malloc committed”. kernel mailing list. 23 April 2009. Archived from the original on 05 June 2014. Retrieved 8 August 2011. 
  20. ۲۰٫۰ ۲۰٫۱ ۲۰٫۲ ۲۰٫۳ Vervloesem, Koen. “DragonFly BSD 2.6: towards a free clustering operating system”. LWN.net. 21 April 2010. Archived from the original on 05 June 2014. Retrieved 19 November 2011. 
  21. Economopoulos, Aggelos. “A peek at the DragonFly Virtual Kernel”. LWN.net. 16 April 2007. Archived from the original on 05 June 2014. Retrieved 8 December 2011. 
  22. “HowTo DPorts”. DragonFly BSD. Archived from the original on 05 June 2014. Retrieved 2 December 2013. 
  23. Weinem, Mark. “Joerg Sonnenberger about pkgsrc on DragonFly BSD and his pkgsrc development projects.”. NetBSD. 2007. Archived from the original on 05 June 2014. Retrieved 22 November 2011. 
  24. Sherrill, Justin. “Why dports?”. DragonFly BSD Digest. 30 September 2013. Archived from the original on 05 June 2014. Retrieved 2 December 2013. 
  25. Sherrill, Justin. “Any new packages?”. users mailing list. 29 September 2013. Archived from the original on 05 June 2014. Retrieved 2 December 2013. 
  26. Buschmann, Jonathan. “First Patch to get CARP on Dfly”. kernel mailing list. 14 March 2007. Archived from the original on 05 June 2014. Retrieved 20 November 2011. 
  27. “CARP(4) manual page”. DragonFly On-Line Manual Pages. Archived from the original on 05 June 2014. Retrieved 20 November 2011. 
  28. Dillon, Matthew. “Re: HAMMER filesystem update - design document”. kernel mailing list. 10 October 2007. Archived from the original on 05 June 2014. Retrieved 20 November 2011. 
  29. Larabel, Michael. “Can DragonFlyBSD's HAMMER Compete With Btrfs, ZFS?”. Phoronix. 7 January 2011. Archived from the original on 05 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. “DESIGN document for HAMMER2 (08-Feb-2012 update)”. users. 8 February 2012. Archived from the original on 05 June 2014. Retrieved 22 February 2012. 
  31. “DragonFly Release 3.8”. The DragonFly BSD Project. Archived from the original on 05 June 2014. Retrieved 03 June 2014. 
  32. ۳۲٫۰ ۳۲٫۱ Mr. “DragonFlyBSD with Matthew Dillon” (OGG). bsdtalk. 7 January 2010. Archived from the original on 05 June 2014. Retrieved 20 November 2011. 
  33. ۳۳٫۰ ۳۳٫۱ “DragonFly BSD diary”. DragonFly BSD. 7 January 2006. Archived from the original on 05 June 2014. Retrieved 19 November 2011. 
  34. “team”. The DragonFly BSD Project, 18 May 2014. Archived from the original on 05 June 2014. Retrieved 31 May 2014. 
  35. “Commercial DragonFly vendors”. The DragonFly BSD Project, 5 January 2014. Archived from the original on 05 June 2014. Retrieved 31 May 2014. 
  36. “Images”. The DragonFly BSD Project, 14 December 2010. Archived from the original on 05 June 2014. Retrieved 31 May 2014. 
  37. “DragonFly: Releases”. DragonFly BSD. Archived from the original on 05 June 2014. Retrieved 22 November 2011. 
  38. Tigeot, Francois. “KMS + i915 support now in -master”. users mailing list. 31 July 2007. Archived from the original on 05 June 2014. Retrieved 2 December 2013. 
  39. ۳۹٫۰ ۳۹٫۱ Kerner, Sean Michael. “DragonFly BSD 1.6 Cuts the Cord”. InternetNews. 25 July 2006. Archived from the original on 05 June 2014. Retrieved 20 November 2011. 
  40. Townsend, Trent. “A Quick Review of DragonFly BSD 1.4”. OSNews. 18 January 2006. Archived from the original on 05 June 2014. Retrieved 16 November 2011. 

پیوند به بیرون[ویرایش]