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

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

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

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

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

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

متیو دیلون[ویرایش]

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

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

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

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

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

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

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

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

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

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

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

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

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

توکن‌های نوبت‌بندی برای جلوگیری از دسترسی همزمان از طرف دیگر پردازنده‌ها مورد استفاده قرار گرفته‌اند و چند ریسه می‌توانند به طور همزمان آنها را داشته باشند تا این اطمینان حاصل شود که در هر زمان، تنها یکی از آن ریسه‌ها می‌تواند اجرا می‌شود. برخلاف ریسه‌ای که یک mutex را در اختیار دارد، ریسه‌های مسدود شده یا به خواب رفته از دسترسی دیگر ریسه‌ها به منابع مشترک جلوگیری نمی‌کنند. در کنار دیگر چیزها، استفاده از توکن‌های نوبت‌بندی از بسیاری از موقعیت‌هایی که ممکن است باعث وقوع بن‌بست یا واژگونی اولویتی در حین استفاده از mutex ها شود، جلوگیری می‌کند و همچنین به طور قابل ملاحظه‌ای طراحی و پیاده‌سازی رویه چند مرحله‌ای را ساده‌تر می‌کند که احتیاج به این دارد که یک منبع در میان چند ریسه به اشتراک گذاشته شود.

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

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

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

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

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

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

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

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

CARP[ویرایش]

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

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

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

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

devfs[ویرایش]

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

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

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

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

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

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

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

همانند دیگر سیستم‌عامل‌های بازمتن خانواده بی‌اس‌دی، دراگون‌فلی‌بی‌اس‌دی هم تحت پروانه بی‌اس‌دی منتشر می‌شود.

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

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

  1. Matthew Dillon
  2. ISP
  3. synchronous
  4. asynchronous

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

  1. Dillon, Matthew. “Announcing DragonFly BSD!”. freebsd-current mailing list. 16 July 2003. Retrieved 2007-07-26. 
  2. Lehey, Greg. “Improving the FreeBSD SMP implementation” (pdf). USENIX, 2001. Retrieved 2012-02-22. 
  3. ۳٫۰ ۳٫۱ Kerner, Sean Michael. “New DragonFly Released For BSD Users”. InternetNews. 10 January 2006. Retrieved 2011-11-20. 
  4. ۴٫۰ ۴٫۱ ۴٫۲ ۴٫۳ ۴٫۴ Biancuzzi, Federico. “Behind DragonFly BSD”. O'Reilly Media. 8 July 2004. Retrieved 2011-11-20. 
  5. Loli-Queru, Eugenia. “Interview with Matthew Dillon of DragonFly BSD”. OSNews. 13 March 2004. Retrieved 2012-02-22. 
  6. ۶٫۰ ۶٫۱ ۶٫۲ ۶٫۳ ۶٫۴ ۶٫۵ Chisnall, David. “DragonFly BSD: UNIX for Clusters?”. InformIT. 15 June 2007. Retrieved 2011-11-22. 
  7. Hsu, Jeffery M.. “The DragonFly BSD Operating System” (pdf). Retrieved 2011-11-20. 
  8. ۸٫۰ ۸٫۱ ۸٫۲ Andrews, Jeremy. “Interview: Matthew Dillon”. KernelTrap. 6 August 2007. Archived from the original on 15 May 2011. 
  9. “DragonFly BSD MP Performance Significantly Improved”. OSNews. 16 November 2011. Retrieved 2011-11-19. 
  10. ۱۰٫۰ ۱۰٫۱ Luciani, Robert. “M:N threading in DragonflyBSD” (pdf). BSDCon, 24 May 2009. Archived from the original on 23 December 2010. 
  11. Sherrill, Justin. “Paying off already”. 11 January 2004. Retrieved 2011-11-20. 
  12. ۱۲٫۰ ۱۲٫۱ ۱۲٫۲ Vervloesem, Koen. “DragonFly BSD 2.6: towards a free clustering operating system”. LWN.net. 21 April 2010. Retrieved 2011-11-19. 
  13. Economopoulos, Aggelos. “A peek at the DragonFly Virtual Kernel”. LWN.net. 16 April 2007. Retrieved 2011-12-08. 
  14. Economopoulos, Aggelos. “A peek at the DragonFly Virtual Kernel”. LWN.net. 16 April 2007. Retrieved 2011-12-08. 
  15. “HowTo DPorts”. DragonFly BSD. Retrieved 2013-12-02. 
  16. Weinem, Mark. “Joerg Sonnenberger about pkgsrc on DragonFly BSD and his pkgsrc development projects.”. NetBSD. 2007. Retrieved 2011-11-22. 
  17. Sherrill, Justin. “Why dports?”. DragonFly BSD Digest. 30 September 2013. Retrieved 2013-12-02. 
  18. Sherrill, Justin. “Any new packages?”. users mailing list. 29 September 2013. Retrieved 2013-12-02. 
  19. Buschmann, Jonathan. “First Patch to get CARP on Dfly”. kernel mailing list. 14 March 2007. Retrieved 2011-11-20. 
  20. “CARP(4) manual page”. DragonFly On-Line Manual Pages. Retrieved 2011-11-20. 
  21. Dillon, Matthew. “Re: HAMMER filesystem update - design document”. kernel mailing list. 10 October 2007. Retrieved 2011-11-20. 
  22. Larabel, Michael. “Can DragonFlyBSD's HAMMER Compete With Btrfs, ZFS?”. Phoronix. 7 January 2011. Retrieved 2011-11-20. “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.” 
  23. ۲۳٫۰ ۲۳٫۱ Mr. “DragonFlyBSD with Matthew Dillon” (ogg). bsdtalk. 7 January 2010. Retrieved 2011-11-20. 
  24. ۲۴٫۰ ۲۴٫۱ “DragonFly BSD diary”. DragonFly BSD. 7 January 2006. Retrieved 2011-11-19.