در 30 نوامبر 2010، دیوید کولیر نوشت:
متوجه شدم که در busybox پیوندها به این چهار دایرکتوری تقسیم می شوند.
آیا یک قانون ساده برای تعیین اینکه کدام یک از پیوندها باید در کدام دایرکتوری قرار بگیرند وجود دارد ...
مثلا kill در /bin است و killall در /usr/bin ... من هیچ منطقی در این تقسیم نمی بینم.
احتمالاً می دانید که کن تامپسون و دنیس ریچی در سال 7 یونیکس را بر روی PDP-1969 ایجاد کردند. بنابراین، در حدود سال 1971، آنها به یک PDP-11 با یک جفت دیسک RK05 (هر کدام 1,5 مگابایت) ارتقا دادند.
هنگامی که سیستم عامل رشد کرد و دیگر بر روی دیسک اول (که ریشه FS روی آن قرار داشت) قرار نمی گرفت، بخشی را به دومی منتقل کردند، جایی که دایرکتوری های خانه در آن قرار داشتند (بنابراین، نقطه مونت /usr نامیده می شد - از کلمه کاربر). آنها همه دایرکتوری های ضروری سیستم عامل را در آنجا کپی کردند (/bin، /sbin، /lib، /tmp ...) و فایل ها را روی یک دیسک جدید قرار دادند، زیرا فضای قبلی تمام شد. سپس آنها یک دیسک سوم داشتند، آن را در پوشه /home سوار کردند و دایرکتوری های اصلی کاربران را به آنجا منتقل کردند تا سیستم عامل بتواند تمام فضای باقی مانده روی دو دیسک را بگیرد. سه مگابایت (وای!).
البته آنها باید قانونی وضع می کردند که "وقتی سیستم عامل بوت می شود، باید بتواند دیسک دوم را در /usr mount کند، بنابراین برنامه هایی مانند mount را روی دیسک دوم در /usr قرار ندهید وگرنه خواهید داشت. مشکل مرغ و تخم مرغ." ساده است. و این در یونیکس V6 35 سال پیش بود.
تقسیم /bin و /usr/bin (و همه این دایرکتوری ها) میراث آن رویدادها است، جزئیات پیاده سازی از دهه 70 که برای دهه ها توسط بوروکرات ها کپی شده است. آنها هرگز این سؤال را نپرسیدند چراآنها فقط آن را انجام دادند. این تقسیم‌بندی حتی قبل از ایجاد لینوکس به دلایل مختلف متوقف شد:
- هنگام بوت کردن، از یک initrd یا initramfs استفاده می شود که مشکلاتی مانند "ما این فایل را قبل از آن نیاز داریم" برطرف می کند. بنابراین، ما داریم قبلاً سیستم فایل موقت که برای بارگیری هر چیز دیگری استفاده می شود.
- کتابخانه های مشترک (که توسط بچه های برکلی به یونیکس اضافه شده اند) به شما اجازه نمی دهند که محتویات /lib و /usr/lib را به طور مستقل تغییر دهید. این دو قسمت باید مطابقت داشته باشند وگرنه کار نمی کنند. این اتفاق در سال 1974 رخ نداد، زیرا آنها در آن زمان به دلیل پیوندهای ثابت استقلال داشتند.
- هارد درایوهای ارزان حدود سال 100 سد 1990 مگابایتی را شکستند و تقریباً در همان زمان، نرم افزار تغییر اندازه پارتیشن ظاهر شد (partition magic 3.0 در سال 1997 منتشر شد).
البته از آنجایی که تقسیم بندی وجود دارد، برخی قوانینی را ارائه کرده اند که آن را توجیه می کند. به عنوان مثال، پارتیشن ریشه برای انواع ویژگی های عمومی سیستم عامل مورد نیاز است و شما باید فایل های محلی خود را در / usr قرار دهید. یا آنچه را که AT&T توزیع می‌کند، و در /usr آنچه را که توزیع شما، IBM AIX، یا Dec Ultrix، یا SGI Irix اضافه کرده‌اند، در /usr قرار دهید، و /usr/local حاوی فایل‌های مخصوص سیستم شما است. و سپس شخصی به این نتیجه رسید که /usr/local مکان مناسبی برای نصب نرم افزار جدید نیست، پس بیایید /opt را اضافه کنیم! تعجب نخواهم کرد اگر /opt/local نیز ظاهر شود...
البته، در طول 30 سال، به دلیل این جدایی، انواع و اقسام قوانین جالب خاص توزیع آمده و رفته است. به عنوان مثال، "/tmp هنگام راه اندازی مجدد پاک می شود، اما /usr/tmp پاک نمی شود." (و در اوبونتو اصولا /usr/tmp وجود ندارد و در جنتو /usr/tmp یک پیوند نمادین به /var/tmp است که اکنون مشمول آن قانون است و در راه اندازی مجدد پاک نمی شود. بله، این همه چیز قبل بود همچنین اتفاق می‌افتد که root FS فقط خواندنی است و پس از آن نیازی به نوشتن چیزی در /usr نیست، اما باید در /var بنویسید. در درجه اول را نمی توان نوشت مگر در /etc که گاهی اوقات سعی می شد به /var منتقل شود...)
بوروکرات‌هایی مانند بنیاد لینوکس (که سال‌ها پیش گروه استانداردهای آزاد را در طول توسعه‌اش بلعید) خوشحال هستند که این قوانین را مستند و پیچیده می‌کنند بدون اینکه هرگز تلاش کنند دلیل وجود آنها را بفهمند. چیزی که آنها متوجه نمی شوند این است که کن و دنیس فقط بخشی از سیستم عامل را به فهرست اصلی خود منتقل کردند زیرا دیسک RK05 در PDP-11 بسیار کوچک بود.
من تقریباً مطمئن هستم که busybox فقط فایل ها را به همان روشی که در گذشته انجام داده است قرار می دهد. هیچ دلیل واقعی برای انجام این کار تا کنون وجود ندارد. من شخصاً /bin، /sbin و /lib را به دایرکتوری های مشابه در /usr پیوند می دهم. از این گذشته، افرادی که با نرم افزارهای تعبیه شده کار می کنند سعی می کنند درک و ساده سازی ...
منبع: www.habr.com