فلسفة يونكس

في مقدمة كتابهم الصادر عام 1984 بعنوان "بيئة برمجة يونكس" ، يقدم كل من برايان كيرنيغان وروب بايك ، وكلاهما من مختبرات بيل ، وصفًا موجزًا ​​لتصميم يونكس وفلسفة يونكس: ^{[ 5 ]}

على الرغم من أن نظام يونكس يُقدّم عددًا من البرامج والتقنيات المبتكرة، إلا أن نجاحه لا يعتمد على برنامج واحد أو فكرة واحدة. بل يكمن سرّ فعاليته في منهجية البرمجة، أي فلسفة استخدام الحاسوب. ورغم أن هذه الفلسفة لا يُمكن تلخيصها في جملة واحدة، إلا أن جوهرها يكمن في أن قوة النظام تنبع من العلاقات بين البرامج أكثر من البرامج نفسها. فكثير من برامج يونكس تُؤدي مهامًا بسيطة عند استخدامها منفردة، ولكنها، عند دمجها مع برامج أخرى، تُصبح أدوات عامة ومفيدة.

ويكتب المؤلفون كذلك أن هدفهم من هذا الكتاب هو "توصيل فلسفة برمجة يونكس". ^{[ 5 ]}

في أكتوبر 1984، نشر برايان كيرنيغان وروب بايك ورقة بحثية بعنوان " تصميم البرامج في بيئة يونكس" . في هذه الورقة، ينتقدان تراكم خيارات وميزات البرامج الموجودة في بعض أنظمة يونكس الأحدث مثل 4.2BSD و System V ، ويشرحان فلسفة يونكس لأدوات البرمجيات، حيث تؤدي كل أداة وظيفة عامة واحدة: ^{[ 6 ]}

يستمد نظام التشغيل يونكس قوته من أسلوب تصميم برامجه الذي يُسهّل استخدامها، والأهم من ذلك، يُسهّل دمجها مع برامج أخرى. يُعرف هذا الأسلوب باستخدام أدوات البرمجيات ، ويعتمد بشكل أكبر على كيفية اندماج البرامج في بيئة البرمجة وكيفية استخدامها مع برامج أخرى، أكثر من اعتماده على تصميمها الداخلي. [...] وقد استند هذا الأسلوب إلى استخدام الأدوات : أي استخدام البرامج بشكل منفصل أو مجتمعة لإنجاز مهمة ما، بدلاً من القيام بذلك يدويًا، أو بواسطة أنظمة فرعية متجانسة مكتفية ذاتيًا، أو بواسطة برامج خاصة تُستخدم لمرة واحدة.

يقارن المؤلفون أدوات يونكس مثل cat بمجموعات البرامج الأكبر حجماً التي تستخدمها الأنظمة الأخرى. ^{[ 6 ]}

يُعد تصميم برنامج cat نموذجيًا لمعظم برامج يونكس: فهو يُنفّذ وظيفةً واحدةً بسيطةً وعامةً يُمكن استخدامها في العديد من التطبيقات المختلفة (بما في ذلك تطبيقات لم يتوقعها مُؤلّفه الأصلي). وتُستخدم أوامر أخرى لوظائف أخرى. على سبيل المثال، توجد أوامر منفصلة لمهام نظام الملفات مثل إعادة تسمية الملفات، وحذفها، ومعرفة حجمها. في المقابل، تُجمّع أنظمة أخرى هذه المهام في أمر واحد خاص بنظام الملفات، له بنية داخلية ولغة أوامر خاصة به. (يُعدّ برنامج نسخ الملفات PIP ^{[ 7 ]} الموجود في أنظمة تشغيل مثل CP/M أو RSX-11 مثالًا على ذلك). هذا النهج ليس بالضرورة أسوأ أو أفضل، ولكنه بالتأكيد يُخالف فلسفة يونكس.

قام ماكيلروي ، الذي كان آنذاك رئيس مركز أبحاث علوم الحوسبة في مختبرات بيل ومخترع أنبوب يونكس ، ^{[ 8 ]} بتلخيص فلسفة يونكس على النحو التالي: ^{[ 3 ]}

هذه هي فلسفة يونكس: اكتب برامج تؤدي وظيفة واحدة وتؤديها على أكمل وجه. اكتب برامج تعمل معًا. اكتب برامج للتعامل مع تدفقات النصوص ، لأنها واجهة عالمية.

إلى جانب هذه التصريحات، فقد أكد أيضًا على البساطة والحد الأدنى في برمجة يونكس: ^{[ 3 ]}

إن مفهوم "التعقيدات المعقدة والجميلة" يكاد يكون متناقضاً. يتنافس مبرمجو يونكس فيما بينهم على لقب "البساطة والجمال"  - وهي نقطة ضمنية في هذه القواعد، ولكن من الجدير ذكرها صراحةً.

في المقابل، انتقد ماكلروي نظام لينكس الحديث بسبب تضخم برامجه ، مشيرًا إلى أن "المعجبين المتحمسين أغرقوا لينكس بميزاته حتى وصل إلى حالة من السمنة المفرطة المحبطة ". ^{[ 9 ]} ويقارن هذا بالنهج السابق الذي تم اتباعه في مختبرات بيل عند تطوير ومراجعة نظام يونكس البحثي : ^{[ 10 ]}

كان كل شيء صغيرًا... ويحزنني حجم لينكس عندما أرى حجمه. [...] صفحة الدليل ، التي كانت في الأصل صفحة دليل ، أصبحت الآن مجلدًا صغيرًا، مع ألف خيار... كنا نجلس في غرفة يونكس ونتساءل: "ما الذي يمكننا حذفه؟ لماذا يوجد هذا الخيار؟" غالبًا ما يكون السبب وجود قصور في التصميم الأساسي  - لم تصل إلى نقطة التصميم الصحيحة. بدلًا من إضافة خيار، فكّر فيما أجبرك على إضافته.

كما ذكر ماكلروي، وهو أمر مقبول عمومًا في مجتمع يونكس، لطالما كان يُتوقع من برامج يونكس اتباع مفهوم DOTADIW، أو "افعل شيئًا واحدًا وأتقنه". توجد مصادر محدودة للاختصار DOTADIW على الإنترنت، ولكنه يُناقش باستفاضة أثناء تطوير وتغليف أنظمة التشغيل الجديدة، وخاصة في مجتمع لينكس.

استشهد باتريك فولكردينغ ، قائد مشروع Slackware Linux ، بمبدأ التصميم هذا في انتقاده لبنية systemd ، مصرحًا بأن "محاولة التحكم في الخدمات والمآخذ والأجهزة ونقاط التحميل وما إلى ذلك، كلها داخل برنامج واحد يتعارض مع مفهوم يونكس المتمثل في القيام بشيء واحد والقيام به بشكل جيد." ^{[ 11 ]}

في كتابه "فن برمجة يونكس" الذي نُشر لأول مرة عام 2003، ^{[ 12 ]} يلخص إريك إس. ريموند (المدافع عن المصادر المفتوحة والمبرمج) فلسفة يونكس بعبارة " اجعلها بسيطة، يا غبي ". ^{[ 13 ]} ويقدم سلسلة من قواعد التصميم: ^{[ 3 ]}

• بناء برامج معيارية
• اكتب برامج قابلة للقراءة
• استخدم التركيب
• فصل الآليات عن السياسة
• اكتب برامج بسيطة
• اكتب برامج صغيرة
• اكتب برامج شفافة
• اكتب برامج قوية
• اجعل البيانات معقدة عند الحاجة، وليس البرنامج.
• استند إلى المعرفة المتوقعة للمستخدمين المحتملين
• تجنب الإخراج غير الضروري
• اكتب برامج تفشل بطريقة يسهل تشخيصها
• قيمة وقت المطور مقارنة بوقت الآلة
• اكتب برامج مجردة تولد التعليمات البرمجية بدلاً من كتابة التعليمات البرمجية يدويًا
• قم بإنشاء نموذج أولي للبرنامج قبل صقله
• اكتب برامج مرنة ومفتوحة المصدر
• اجعل البرنامج والبروتوكولات قابلة للتوسيع.

في عام 1994، نشر مايك غانكارز ، العضو في مجموعة هندسة يونكس التابعة لشركة ديجيتال إكويبمنت ، كتاب " فلسفة يونكس " استناداً إلى تجربته في تطوير منفذ يونكس ( ألتريكس ) في شركة ديجيتال إكويبمنت خلال ثمانينيات القرن الماضي، بالإضافة إلى مناقشاته مع زملائه. وهو أيضاً عضو في فريق تطوير نظام إكس ويندو، ومؤلف برنامج ألتريكس ويندو مانجر (uwm).

يركز الكتاب على نقل نظام التشغيل UNIX إلى أجهزة كمبيوتر مختلفة خلال حروب Unix في الثمانينيات ويصف فلسفته القائلة بأن قابلية النقل يجب أن تكون أكثر أهمية من كفاءة استخدام واجهات غير قياسية للأجهزة المادية وأجهزة الرسومات.

المبادئ التسعة الأساسية التي يدعي أنها مهمة هي

1. الصغير جميل.
2. اجعل كل برنامج يقوم بمهمة واحدة بشكل جيد.
3. قم ببناء نموذج أولي في أسرع وقت ممكن.
4. اختر سهولة الحمل على حساب الكفاءة.
5. قم بتخزين البيانات في ملفات نصية بسيطة .
6. استغل قوة البرمجيات لصالحك.
7. استخدم البرامج النصية (shell scripts) لزيادة الكفاءة وقابلية النقل.
8. تجنب واجهات المستخدم المقيدة.
9. اجعل كل برنامج بمثابة مرشح .

يشير ريتشارد ب. غابرييل إلى أن إحدى المزايا الرئيسية لنظام يونكس تكمن في تجسيده لفلسفة تصميم أطلق عليها اسم "الأسوأ هو الأفضل"، حيث تُعدّ بساطة كلٍّ من واجهة المستخدم والتنفيذ أهم من أي سمات أخرى للنظام، بما في ذلك الصحة والاتساق والشمولية. ويجادل غابرييل بأن هذا الأسلوب التصميمي يتمتع بمزايا تطورية جوهرية، مع أنه يشكك في جودة بعض النتائج.

على سبيل المثال، في بدايات نظام يونكس، كان يُستخدم نواة متجانسة (أي أن عمليات المستخدم كانت تُنفذ جميع استدعاءات نظام النواة على مكدس المستخدم). إذا وصلت إشارة إلى عملية ما أثناء انتظارها في عملية إدخال /إخراج طويلة الأمد في النواة، كان التعامل مع الموقف غير واضح. لم يكن بالإمكان تنفيذ معالج الإشارة عندما تكون العملية في وضع النواة، مع وجود بيانات نواة حساسة على المكدس.