البحث في الموقع

يشير مصطلح مفتوح المصدر (open source) لأي شيء يمكن لأي شخص تعديله ومشاركته لأن تصميمه متاح للجميع. نشأ هذا المصطلح في سياق تطوير البرمجيات للدلالة على نهج خاص لإنشاء برامج للحاسوب. أما اليوم، فإن مصطلح "مفتوح المصدر" يشير لمجموعة أوسع من القيم - والّتي نسميها "الثقافة مفتوحة المصدر. تتبنى المشاريع، أو المنتجات، أو المبادرات مفتوحة المصدر مبادئ التبادل المفتوح والمشاركة التعاونية والنماذج الأولية السريعة والشفافية العالية والجدارة والتنمية الموجهة للمجتمع. ما هي البرمجية مفتوحة المصدر؟ البرمجيات مفتوحة المصدر: هي برمجيات يمكننا رؤية شيفرتها البرمجية وفحصها وتعديلها وتحسينها. "الشيفرة البرمجية" هي جزء من برمجية لا يراه معظم مستخدمي الحاسوب على الإطلاق، ويتلاعب مبرمجو الحاسوب بالشيفرة لتغيير طريقة عمل البرمجية - سواءً أكانت "برنامج" أو "تطبيق". يمكن للمبرمجين الّذين يستطيعون الوصول للشيفرة البرمجية لبرنامج الحاسوب تحسين هذا البرنامج من خلال إضافة ميزات إليه أو إصلاح الأجزاء الّتي لا تعمل دائمًا عملًا صحيحًا. ما الفرق بين البرمجيات مفتوحة المصدر والأنواع أخرى؟ هناك بعض البرمجيات الّتي لا تُملكُ شيفرتها أو يمكن التعديل عليها سوى الجهة الّتي أنشأتها سواءً أكانت ممثلة بشخص أو فريق أو مؤسسة وتحتفظ هذه الجهة بالسيطرة الحصرية عليها. ويطلق الناس على هذا النوع من البرمجيات "بالبرمجيات المحتكرة" (proprietary) أو "مغلقة المصدر" (closed source). يمكن لأصحاب البرمجيات المحتكرة وحدهم نسخ هذه البرمجيات، وفحصها وتغييرها بطريقة قانونية. ولاستخدام البرمجيات المحتكرة لابد أن يوافق مستخدمي الحاسوب (للتوقيع على الترخيص المعروض والّذي يعرض عادةً عند التشغيل للمرة الأولى للبرمجيات) والّتي تنص على أنهم لن يفعلوا أي شيء للبرمجية مخالف صراحةً لما يسمح به منشئي هذه البرمجية. ومن هذه البرمجيات نذكر Microsoft Office وAdobe Photoshop. تختلف البرمجيات مفتوحة المصدر عن نظيرتها المحتكرة. إذ يتيح منشئي البرمجيات المفتوحة المصدر عرض الشيفرة البرمجية، ونسخها، والتعلم منها، وتغييرها، ومشاركتها أيضًا. ومن هذه البرمجيات نذكر محرر النصوص ليبر أوفيس LibreOffice وبرنامج التلاعب بالصور Gimp. وكما هو الحال مع البرمجيات المحتكرة يجب على المستخدمين عند استخدامهم البرمجيات مفتوحة المصدر الموافقة على شروط الترخيص بيدَ أن هذه الشروط تختلف اختلافًا كبيرًا عن شروط البرمجيات المحتكرة. تحدّد تراخيص البرمجيات مفتوحة المصدر طريقة استخدام البرمجيات، وتعديلها، وتوزيعها. وعمومًا تَمنحُ هذه التراخيص إذنًا باستخدام البرمجيات لأي غرض يرغب به المستخدم. إلا أن البعض الأخر من التراخيص والّتي يسميها البعض "الحقوق المتروكة" تنص على وجوب عرض الشيفرة البرمجية الخاصة لكلّ نُسخة مُعدلة من هذه البرمجية علنيًا. علاوة على ذلك بعض التراخيص تُوجبُ على أي شخص يعدلّ البرمجية ويشاركها مع الآخرين أن يشارك أيضًا المصدر الأصلي للشيفرة بدون فرض رسوم الترخيص عليها. تعمدُ تراخيص البرمجيات مفتوحة المصدر على تعزيز روح التعاون والمشاركة لأنها تسمح للجميع بإجراء تعديلات على الشيفرات البرمجية، ودمج هذه التغييرات في مشاريعهم الخاصة. وهم بذلك يشجعون مبرمجي الحاسوب بالوصول إلى البرمجيات مفتوحة المصدر وعرضها وتعديلها بأي وقت يحلو لهم، طالما أنهم سمحوا للآخرين بفعل نفس الشيئ عندما يشاركون برمجياتهم. هل البرمجيات مفتوحة المصدر مهمة لمبرمجي الحاسوب فقط؟ بالتأكيد لا. بل إن التكنولوجيا مفتوحة المصدر والعقلية المنفتحة للمصادر المفتوحة عمومًا تفيد كلًا من المبرمجين وغير المبرمجين. لأن المخترعين الأوائل للإنترنت شيدوا جزءًا كبيرًا منه على تقنياتٍ مفتوحة المصدر - مثل: نظام التشغيل Linux وتطبيق خادم الوِب المحلي Apache - وبذلك أي شخص يستخدم الانترنت فهو في الحقيقة يستفيد من البرمجيات مفتوحة المصدر. عند كلّ عملية استعراض لصفحة وِب أو التحقق من البريد الإلكتروني، أو الدردشة مع الأصدقاء، أو استخدام منصات البث الموسيقي عبر الإنترنت، أو اللعب بألعاب فيديو متعددة اللاعبين فإن حاسوب المستخدم، أو هاتفه المحمول، أو طرفيات الألعاب ستتصل بشبكة عالمية من الحواسيب من خلال برمجيات مفتوحة المصدر من أجل توجيه ونقل البيانات إلى أجهزتهم "المحلية" الموجودة أمام أعينهم. عادةً ما تتواجد هذه الحواسيب الّتي تؤدي كلّ هذا العمل الهام في أماكن بعيدة عن أنظار المستخدمين أو لا يستطيعون الوصول إليها فعليًا - وهذا هو السبب في أن بعض الأشخاص يطلقون على هذه الحواسيب "بالحواسيب البعيدة". يعتمد الناس أكثر فأكثر على الحواسيب البعيدة عند أداء مهامهم بدلًا من أجهزتهم المحلية. فمثلًا، قد يستخدمون برمجيات معالجة الكلمات وإدارة البريد الإلكتروني وتحرير الصور وهي غير مثبتة على حواسيبهم الشخصية. وإنما، ببساطة يصلون لها عبر الحواسيب البعيدة من خلال متصفح الوِب أو تطبيق على الهاتف محمول. وعندما يفعلون ذلك، فهم ينخرطون في "الحوسبة عن بُعد". يطلق بعض الأشخاص على الحوسبة عن بُعد "بالحوسبة السحابية" وذلك لأنها تتضمن أنشطة (مثل: تخزين الملفات أو مشاركة الصور أو مشاهدة مقاطع الفيديو) والّتي لا تتضمن حواسيب محلية فقط وإنما شبكة عالمية من الحواسيب البعيدة أيضًا الّتي تشكل سحابة. تتوالى أهمية الحوسبة السحابية يومًا بعد يوم وخصيصًا في الحياة اليومية للأجهزة المتصلة بالإنترنت. ومن بعض تطبيقات الحوسبة السحابية المحتكرة Google Apps. أما بعض التطبيقات الأخرى مفتوحة المصدر نذكر: ownCloud وNextcloud. تعمل تطبيقات الحوسبة السحابية "على قمة" من البرمجيات الإضافية المساعدة لها لتعمل بسلاسة وكفاءة، لذلك غالبًا ما سيقول الناس أن البرمجيات الّتي تعمل "تحت" تطبيقات الحوسبة السحابية تعمل بمثابة "منصة" لتطبيقات الحوسبة السحابية، وتكون هذه المنصات إما مفتوحة المصدر أو مغلقة المصدر. فمثلًا المنصة OpenStack هي منصة مفتوحة المصدر. لماذا يفضل الناس استخدام برمجيات مفتوحة المصدر؟ يفضل الناس البرمجيات مفتوحة المصدر على حساب البرمجيات المحتكرة لعدد من الأسباب: زيادة السيطرة على البرمجية يفضل كثير من الناس البرمجيات مفتوحة المصدر لأنها تعطيهم مزيدًا من السيطرة والتحكم. إذ يمكنهم فحص الشيفرة البرمجية للتأكد من أنها ستؤدي نفس المهمة الّتي يريدونها، بل ويمكنهم حتى تغيير أي جزء منها لا يحبونه. كما يستفيد غير المبرمجين من هذه البرمجيات أيضًا، لأنهم يمكنهم استخدام هذه البرمجية لأي غرض يرغبون فيه - وبذلك لا تُفرض عليهم الطريقة الّتي يعتقد شخص ما -صاحب البرمجية مثلًا- بأنه يجب عليهم استخدام البرمجية وفقًا لها (كما يحدث في البرمجيات المحتكرة). التعلم والتدرب من هذه البرمجيات يحبُ البعض الآخر من الناس هذه البرمجيات لأنها تساعدهم ليصبحوا مبرمجين أفضل. نظرًا لأن الشيفرة البرمجية متاحة للجميع، وبذلك يمكن للطلاب دراستها بسهولة أثناء تعلمهم لإنشاء برمجية أفضل. يمكن للطلاب مشاركة عملهم مع الآخرين أيضًا، ودعوتهم للتعليق والنقد البناء، وبذلك يصقل الطلاب مهاراتهم. عندما يكتشف الأشخاص أخطاءً في الشيفرات البرمجية لبرامجهم، يمكنهم مشاركة هذه الأخطاء مع الآخرين لمساعدتهم على تجنب ارتكاب نفس هذه الأخطاء. الحماية والأمان يُفضل بعض الأشخاص هذه البرمجيات لأنهم يرونها أكثر أمانًا واستقرارًا من البرمجيات المحتكرة. نظرًا من كون الجميع يستطيع عرض وتعديل البرمجيات مفتوحة المصدر، فيمكن لأي شخص أن يكتشف خطأ غفِلَ عنه أصحاب البرمجية أنفسهم بل ويمكن أن يصحح أو يحذف هذا الخطأ. ولأن العديد من المبرمجين يمكنهم العمل على جزء معين من البرمجية بدون طلب إذن من أصحابها، فسيُسرّع ذلك من وتيرة إصلاح البرمجية وتحديثها وترقيتها أكثر من البرمجيات المحتكرة. الاستقرار والثبات يفضل العديد من المستخدمين البرمجيات مفتوحة المصدر على نظيرتها المحتكرة للمشاريع المهمة وطويلة الأمد. نظرًا لتوزيع المبرمجين الشيفرة البرمجية علنًا للبرمجيات مفتوحة المصدر، فيمكن للمستخدمين الّذين يعتمدون على هذه البرمجيات في المهام الحرجة التأكد من أن أدواتهم لن تختفي أو تتعطل إذا توقف أصحابها عن تطويرها -وذلك لأن لديها عدة مبرمجين آخرين مهتمين بها- علاوة عن ذلك، تميل البرمجيات مفتوحة المصدر للاندماج والعمل وفقًا للمعايير المفتوحة. المجتمع الداعم للبرمجية غالبًا ما تستقطب البرمجيات مفتوحة المصدر جمهورًا من المستخدمين والمطورين المحبين لها. وهذا ليس حكرًا على هذه البرمجيات بل العديد من التطبيقات الشعبية لها مجتمعات كبيرة ومواضيع يناقشونها في لقاءاتهم واجتماعاتهم. غير أن في البرمجيات مفتوحة المصدر يكون المجتمع ليس مجرد قاعدة جماهيرية تشتري (سواء عاطفيًا بالدعم أو ماليًا بسعر البرمجية) وتكوّن بذلك مجموعة مميزة من المستخدمين وحسب، وإنما مجموعة من الأشخاص الّذين ينتجون ويختبرون ويستخدمون ويروجون بل ويؤثرون تأثيرًا جوهريًا على البرمجية الّتي يحبونها. هل يعني مصطلح "مفتوح المصدر" بأنه مجاني؟ لا. هذا مفهوم خاطئ ومنتشر حول ما يعنيه مصطلح "مفتوح المصدر"، وممكن ألا يتعلق هذا المصطلح بالمال. يمكن لمبرمجي هذه البرمجيات أن يتقاضوا المال مقابل البرمجيات مفتوحة المصدر الّتي يصنعونها أو يساهمون فيها. ولكن في بعض الحالات، نظرًا لأن ترخيص المصدر المفتوح يتطلب منهم إصدار الشيفرة البرمجية علنًا عندما يبيعون هذه البرمجيات للآخرين، ولذلك يجدُ بعض المبرمجين أن فرض رسوم على المستخدمين مقابل الخدمات والدعم الفني للبرمجية (بدلًا من البرمجية بحد ذاتها) أكثر ربحًا. وبهذا تظل برمجياتهم مجانية، ويكسبون المال من مساعدة الآخرين في تثبيتها واستخدامها واستكشاف أخطائها وإصلاحها. على الرغم من كون بعض البرمجيات مفتوحة المصدر مجانية، إلا أن مهارة البرمجة واستكشاف الأخطاء وإصلاحها في البرمجيات مفتوحة المصدر يمكن أن تكون ذات قيمة كبيرة. يسعى الكثير من أرباب العمل لتوظيف مبرمجين لديهم خبرة سابقة بالعمل على برمجيات مفتوحة المصدر تحديدًا. ما هي الثقافة مفتوحة المصدر "أي أبعد من الشيفرة البرمجية"؟ إن التعامل مع جميع جوانب الحياة بثقافة مفتوحة المصدر يعني التعبير عن الرغبة في المشاركة والتعاون مع الآخرين بشفافية (ليتمكن الآخرين من المشاهدة أو حتى الانضمام أيضًا)، واحتضان الفشل كوسيلة للتطوّر، وتوقع -أو حتى تشجيع- الجميع ليشاركوا وينضموا إلى هذه الثقافة. ويعني الالتزام أيضًا بدور فعّال في تحسين العالم، وهو أمر ممكن في حال تمكن الجميع من الوصول للطريقة الّتي صُمّم بها هذا العالم. إن العالم مليء "بالشيفرات البرمجية" - المخططات والوصفات والقواعد - الّتي توجه طريقة تفكيرنا وتشكلها من أجل أن نتصرف على أساسها. نؤمن تمامًا بأن هذه الشيفرة الضمنية (مهما كان شكلها) يجب أن تكون مفتوحةً وقابلة للوصول والمشاركة من قِبل الجميع — ليتمكنوا من تغييرها للأفضل. ترجمة -وبتصرف- للمقال What is open source software?‎

جميعنا نعلم أن التعهيد الخارجي للبرمجيات هو عبارة عن كارثة منتظرة في أية لحظة. في البداية تعثر على شركة تعدك بالحصول على كل ما تتمناه في منتج واحد، خلال وقت وميزانية محددين، بأعلى جودة ممكنة، مع واجهة استخدام جذابة، وتقنية متطورة، ودعم مدى الحياة دون متاعب. تقتنع بهذه المزايا وترسل لهم الدفعة الأولى؛ وهنا تبدأ الرحلة، ففريق العمل بالكاد يفهم متطلباتك، والجودة متدنية، ومع تجاوز كل الحدود المتوقعة للزمن والميزانية؛ يبلغ مستوى الإحباط لديك عنان السماء. بل إن "أفضل" جزء من ذلك كله هو أنه لا يمكن إيقافه؛ وإلا فستذهب كل الأموال التي أنفقتها هباء وسيكون عليك البدء من الصفر. لذا ستضطر للاستمرار بالارتباط مع هذا الفريق ﻷن تكلفة "الفراق" عنهم ستكون باهظة. ولكن؛ هل هناك طريقة أفضل للتعهيد الخارجي للبرمجيات؟ نعم؛ من الممكن القيام بذلك بطريقة صحيحة وخالية من المتاعب كليًا، ولكن عليك أن تكون مستعدًا لتعديل فلسفة الإدارة الخاصة بك. المبادئ الرئيسية هنا هي كالتالي: عليك أن تصارح فريق التعهيد بهواجسك بشكل مستمر ومنفتح. عليهم أن يبوحوا لك بالمخاطر والمشكلات التي تقابلهم بشكل مستمر ومنفتح أيضًا. هذان العاملان أساسيان لنجاح التعهيد الخارجي للبرمجيات؛ ولكن للأسف غالبًا ما يتم تجاهلهما. تعلّمت هذين المبدئين من المعلم وي لياو زي، إذ قال بما يتعلق بالاستراتيجية العسكرية في الصين القديمة عام 239 ق.م: دعوني أبرهن على هذا القول من خلال طرح بعض الأمثلة العملية عن كوارث التعهيد الخارجي للبرمجيات؛ وشرح كيفية تجنّب حصولها إذا اتبعت مبادئً تبلغ من العمر 2500 عام. أطول من الوقت المتوقع؛ أكثر من الميزانية المتاحة دائمًا ما يخبرك أفراد الفريق بأن المنتج جاهز بنسبة 95%، لكن هناك مع ذلك بعض المزايا غير المنفّذة أو المعطّلة. لقد قاموا بالكثير من العمل؛ ولقد دفعتَ الكثير من المال، لكن المنتج القابل للتسويق غير جاهز بعد؛ إنه يتطلب أسبوعًا إثر أسبوع؛ وشهرًا بعد شهر، دائمًا هناك تراكم، ولا يمكننا ببساطة أن ننتهي من ذلك، لقد بدأتَ ترى المشروع في كوابيسك، ولم يعد للأدوية المهدئة تأثير مساعد، هل يبدو لك هذا كله مألوفًا؟ الحقيقة التي ستدركها لاحقًا أنه لا يهم نوع العقد الذي وقعته مع شركائك في التعهيد الخارجي، كم عدد البنود التي حددتها، وكم عدد الوعود التي أُبرمت، إنهم يرغبون بالحفاظ عليك عميلًا دائمًا؛ أو على الأقل؛ ما دام في حسابك المصرفي شيء ما لتقدمه. كلاكما ترغبان بالنجاح بالتأكيد، لكن في حين يعني نجاحك كصاحب مشروع إطلاق المنتج النهائي للمستخدم، فإنّ نجاحهم كفريق تطوير برمجي يعني الاستمرار مطوّلًا بكتابة الشيفرات البرمجية لك، وهما هدفان لا يشتركان إلا بحيز ضيق، بل حتى يمكن القول أنهما هدفان متعارضان: فنجاحك يعني فشلهم. سيُسمعك أعضاء فريق التعهيد الكثير من العبارات من قبيل: أنهم يرغبون بإتمام بناء المنتج والتعاقد معك من جديد مستقبلًا؛ وسيقولون أن دافعهم الرئيسي هو سعادتك والحصول على منتج يشير لاسمك بقوّة؛ وسيؤكدون لك أن رضا العميل مقدّم لديهم على المال. على كل حال؛ أفترض أن لديك الجرأة الكافية لتعترف بالحقيقة: كل هذا محض كذب. إن الغالبية العظمى من مشاريع التعهيد الخارجي للبرمجيات تبوء بالفشل (انظر التقرير الأخير لـ CHAOS) ولعلّ مطوري البرمجيات يدركون هذه الحقيقة بشكل أفضل منك، إذ يعيشونها يوميًا مع مئات المشاريع؛ ولن يكون مشروعك استثناء من بينها. وهكذا؛ دعنا ننسى الوعود الجميلة ونسلط الضوء على الحقائق المتعبة، أنت الآن لوحدك. إليك ما أوصي به على ضوء المبادئ المذكورة آنفًا، تأكد من فهم الفريق لنقطتين: الوقت والميزانية والمجال المحدد لعملك. عواقب تجاوزهم هذه الحدود. وهذا يتعلق بالجزء الأول من المبادئ (عليك أن تصارح فريق التعهيد باهتمامك وقلقك بشكل مستمر ومنفتح). لكن ما يحدث عادة أن فريق التعهيد يبقى جاهلًا بالعمق الحقيقي للعمل؛ ما يسمعه فقط هو عبارة تتكرر على مسامعه مع كل مشروع (بأسرع وقت ممكن). والحقيقة أن عبارة "في أسرع وقت ممكن" ليست ميقاتًا محددًا، على العكس من ذلك؛ فهي تثبط الهمم خلافًا لما تفعله المواعيد الثابتة. يجب أن يكون لدى الفريق علم بالتاريخ الدقيق الذي ترغب باستلام المنتج فيه؛ وما الذي تريد استلامه بالضبط و"لماذا"، وعندما لا تكون الأمور واضحة ودقيقة بهذا الشكل سيبدأ العمل يتجه وفق منحى لا ترغب به. أؤكد هنا على سؤال "لماذا"؛ فمعظم أصحاب المشاريع يواجهون صعوبة في الإجابة عليه. لماذا تريد أن يكون المنتج جاهزًا مع بداية حزيران القادم؟ فقط لأنك سئمت من الانتظار؟ هذه ليست إجابة سديدة، فسأمُك من الانتظار لا يهم ما دام ثمة مال في حسابك المصرفي؛ لذا سيستمر الفريق في استنزافك، ولن يحترموا الموعد الذي أعطيته لهم. عجزك عن الإجابة على هذا السؤال أو عن إيضاحه للفريق سيجعلهم يشعرون بعدم وجود أهداف واضحة تتجه لها في عملك؛ الأمر الذي سيفقدك تقديرهم لتصرفك. إليك كيف يمكن أن يكون تحديد الزمن والتكلفة بشكله الصحيح: يجب أن تكون المزايا أ،ب وج جاهزة في الأول من شهر حزيران القادم، لأننا سنبدأ حملة تسويقية في الخامس منه. وإذا لم أطرح هذه المزايا سأخسر 25 ألف دولار من تكاليف التسويق، وإذا حدث ذلك سأضطر لخفض ميزانية التطوير الشهرية للنصف. عندما يسمع فريق التعهيد الخارجي هذه الكلمات؛ ويشعرون بأهمية المهلة المحددة لهم، سيتحولون إلى شريك حقيقي بالنسبة لك؛ وستبدأ أهدافهم بالتماشي مع أهدافك، لأنهم يعرفون مغبّة تجاوز العلامات الموضحة -ماديًا وزمنيًا-، ويدركون أن المتاعب التي ستواجهها جراء ذلك ستنتقل إليهم أيضًا. توقف عن طلب إتمام المنتج خلال "أسرع وقت ممكن"، توقف عن مهاتفة الفريق مرتين يوميًا؛ والصراخ والشكوى لمدة ساعة من أدائهم الضعيف، توقف عن استخدام هذه اللهجة في رسائلك الإلكترونية، هذه الضوضاء التي تحدثها لن تساعدك في الحصول على أي شيء؛ على العكس من ذلك، فهي تعقّد المسألة؛ ﻷنك تفقد احترامهم لك شيئًا فشيئًا، وعندها سيبدؤون بمعاملتك كبقرة حلوب تدفع لهم المال -وبالإضافة إلى هذا كشخص غبيّ وعاطفي-. بدلًا عن ذلك؛ قم بواجبك ووضح المعالم الحقيقية لمشروعك، فكر بالحدود اللازمة لكل من الوقت؛ المجال؛ والميزانية. اكتب ذلك بعبارات واضحة وموجزة، وتأكد أن تكون هذه الحدود واقعية وأن تتضمن الإجابة على السؤال الأهم: لماذا؟ لماذا تريد المنتج مع بداية شهر حزيران؟ لماذا تخصص مبلغًا أقل من 50 ألف دولار؟ لماذا تريد هذه المزايا الخمس في النسخة الأولى من المنتج؟ لماذا تريد أن يكون تطبيق الويب الخاص بمنتجك جاهزًا للتعامل مع ألف زيارة في نفس الوقت؟ لماذا تريد تطبيق الموبايل في الإصدار الأول؟ أجب على هذه الأسئلة لنفسك، وتأكد من كون الإجابات واضحة ومفهومة من قبل فريق التعهيد الخارجي، لا تخفِ عنهم هذه المعلومات. المنتج غير متقن تماما لديك أحلام بالحصول على موقع إلكتروني شبيه بـ Pinterest، سريع، سهل الاستخدام والتصفح، ويجعلك فخورًا عندما تستعرضه على زملائك. لكن كل ما تراه أمامك عبارة عن موقع غير متقن نهائيًا، بطيء، مع مظهر قبيح أيضًا. تطلبُ منهم القيام بشيء لإصلاح ذلك، ولا تحصل إلا على مزيد من الوعود. يستمر المشروع في استنزاف أموالك وتتضخم الميزانية المخصصة له، لكن ذلك لا يحسّنه ولا يزيد مظهره جمالًا، بالإضافة للفرق الشاسع بينه وبين Pinterest. يتزايد الإحباط يومًا إثر يوم؛ ولا تجد سبيلًا للخروج من ذلك كله. والنصيحة الوحيدة التي تتردد في محيطك هي بإعادة تصميم الموقع من الصفر مع فريق برمجي آخر. ألا يبدو لك هذا السيناريو مألوفًا؟ أعتقد أن السبب الرئيسي للوصول إلى هذه النهاية السيئة هو الخوف من الخصام، ففي بداية المشروع تسعى للحفاظ على علاقة جيدة مع فريق التعهيد الخارجي دون الإساءة لأي شخص منهم. وتحرصُ على عدم التدخل بعملهم لما قد يحمله ذلك من إهانة، ولعلّك لا ترغب أيضًا بالتعبير عن مخاوفك حيال جودة المنتج لئلّا تثبط فريق العمل، مع أملٍ لا تفصح عنه أن يتحسن المنتج في المستقبل، لكنك في المستقبل ستشعر أنك وصلت متأخرًا للغاية. مجددًا؛ مع استحضار المبادئ القديمة للفيلسوف الصيني؛ أود أن أنصحك بوضع إجراءات روتينية للتحقق من النتائج والتعبير عما يقلقك منذ اليوم الأول للمشروع. بالنسبة لنا فيTeamed.io فإننا نسأل العملاء أن يكونوا متواجدين على منصة GitHub ليستطلعوا ما نقوم به أولًا بأول، وأن يضيفوا تعليقاتهم على أيّ مشكل يلاحظونه مُباشرة على منصة GitHub. بالإضافة إلى أننا لا نمنّي صاحب المشروع بالكثير بخصوص الجودة؛ بل ونشجعه على أن يكون متشائمًا بهذا الخصوص؛ فقد أدركنا أننا بهذه الطريقة نخفف من مخاطر حدوث "الإحباط التراكمي". حاول أن تقوم بشيء مشابه مع فريق التعهيد الخارجي؛ لا تخف من الإساءة لأحد؛ فلطفك لن يساهم بالحفاظ على المشروع؛ بل لعله أسوأ ما تسديه لنفسك. مهما بدا لك منهج النقد المتكرر مثيرًا للنزاعات فهو صحيّ بشكل أكبر من السلام الناجم عن الصمت -السلام المؤدي إلى حروب في النهاية-، حاول أن تجد صيغة مناسبة لتوصل انطباعاتك وآرائك لفريق التعهيد بشكل منتظم، كن منفتحًا على هواجسك وصارح بها الفريق بانتظام حسب الوصية الأولى، وبهذا الشكل تحافظ على استقرار المشروع وتقلل من حصول المخاطر بأكبر شكل ممكن. بالإضافة إلى ذلك فمن الجيد للغاية أن تدعو من حين لآخر مُراجعين تقنيين لتحصل على آرائهم المستقلة حول منتج قيد التطوير. لا يمكنني الاعتماد على وعودهم تتصل بهم، تضع خطة للعمل، توضّح المعالم الأساسية، تعرّف المزايا المطلوبة، تحدد الأساسيات، تتّفقان على الجودة، ومن ثم تنتهي المكالمة. بعد عدة أيام تكتشف أن ذلك كله كان مضيعة للوقت، لا يمكنهم الإيفاء بوعودهم فهناك طارئ ما يحدث دومًا ويمنعهم من ذلك، أحدهم مريض، انهار الخادوم، بعض البرمجيات لا تؤدي الوظيفة المطلوبة، أجزاء من الكود البرمجي لم تعد تعمل.. إلخ. تتصل بهم مجددًا، تعبّر عن إحباطك بلهجة اتهام، تعود لتعريف المزايا المطلوبة مجددا؛ وتوضح من جديد كل ما ذكرته في مكالمتك السابقة، وبعد عدة أيام ستعود لنقطة البداية عينها، أليس كذلك؟ ألا يبدو هذا مشابهًا لما يحدث معك؟ انطلاقًا من تجربتي؛ فإن هذه الحالة من عدم القدرة على التنبؤ وعدم المصداقية تنجم عن صاحب المشروع نفسه وليس عن فريق التعهيد الخارجي. يحدث هذا عادة عند عدم إصغائك لهم؛ أو خوفهم من إخبارك بالحقيقة -وهما وجهان لعملة واحدة ويحملان التأثير نفسه على مشروعك-. البعض يسمي هذا بـ "التطوير المدفوع بالخوف" أو "fear-driven development". الفريق خائف منك؛ وهو مضطر للكذب عليك حتى تستمر بالعمل معه -والدفع له-. بشكل عام؛ سيخبرونك بما تودّ سماعه منهم: المشروع سينتهي قريبًا، العلل البرمجية يمكن إصلاحها بسهولة، مشاكل الأداء ثانوية وبسيطة، جودة بنية المشروع ممتازة، والفريق متحمس لعمله معك. عندما تسمع أيًا من هذه العبارات عليك أن تسأل نفسك: هل يشجعهم تعاملك على قول الحقيقة؟ وهل تمتنّ لهم لمصارحتك بالأخبار الحقيقية وإن كانت سيئة؟ مع استحضارنا مجددًا للمبدئين المذكورين أعلاه، أنصحك بالتأكد من اعتماد نهج المكافئة أو العقوبة تبعًا لشفافية فريق التعهيد الخارجي بنقل الأخبار لك؛ وأن يكون ذلك مقارنة مع أهداف المشروع لا حسب مشاعرك الشخصية. لا يجب على فرق تطوير البرمجيات أن تسعى لأن يكون العميل سعيدًا على الدوام؛ على العكس، فالمشروع المرجّح للنجاح هو ذاك الذي يكون فيه العميل بمزاج سيء ويحكم عليه بالفشل. لأوضح لك الأمر: إذا كنت تَسعد لكل خبر جيدٍ يزفه لك الفريق وتكافئهم عليه، فأنت تدرّبهم على الكذب. وإذا كنت تتوقع منهم تقديم أخبار جيدة باستمرار، فأنت لا تشجعهم على نقل الحقيقة دائمًا؛ ولا على فعل ما هو لمصلحة المشروع -لا لمصلحتك الشخصية-. أنت تثنيهم بذلك عن مجادلتك، بمعنى آخر؛ أنت تغلق قناة التواصل المفترضة بينك وبينهم؛ ولا تسمح للمعلومات أن تصل منهم إليك. وبهذه الطريقة تعزل نفسك عنهم، ويبدأ الفريق بالعمل ضدّك؛ وليس معك. ما أود نصحك به عمليًا هو كالتالي: أولًا: أعلن بشكل منتظم عن أهدافك وحدود مشروعك كما ذكرنا سابقًا، تأكد من فهم الفريق لخططك العملية والسبب الكامن ورائها -كإجابة على سؤال لماذا؟-. ثانيًا: اسأل الفريق بانتظام عن المشاكل والمخاطر التي تواجههم. اسألهم عن الأسباب التي تدفعهم للاعتقاد بضرورة تعديل أهداف المشروع، أو حتى بشكل أفضل؛ اطلب منهم أن يوثقوا المخاطر ويرسلوها لك بانتظام، كافئهم على شفافيتهم ومصداقيتهم بإرسال تقارير المخاطر. جرّب هذا النهج وسوف تفاجأ بما ستحتويه قائمة المخاطر من أشياء مثيرة للاهتمام. ترجمة -وبتصرف- للمقال How to Avoid a Software Outsourcing Disaster لكاتبه Yegor Bugayenko. حقوق الصورة البارزة: Designed by Freepik.

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

هنالك العديد من البرمجيات المفيدة جدًا المطورة من فريق خادوم أوبنتو وغيرهم التي تندمج اندماجًا جيدًا مع نسخة خادوم أوبنتو، لكن ربما لا تكون معروفةً جدًا؛ سيعرض هذا الدرس بعض التطبيقات المفيدة التي تسهِّل إدارة خادوم، أو عدِّة خواديم أوبنتو. pam_motd عندما تسجل دخولك إلى خادوم أوبنتو، ربما تلاحظ "رسالة اليوم" (Message Of The Day اختصارًا MOTD)؛ تأتي هذه المعلومات وتُعرَض من حزمتين: 1. الحزمة landscape-common: توفر المكتبات الأساسية لبرمجية landscape-client، التي يمكن أن تُستخدَم لإدارة الأنظمة باستخدام تطبيق الويب Landscape؛ تتضمن هذه الحزمة الأداة ‎/usr/bin/landscape-sysinfo التي تُستخدَم لجمع المعلومات التي تُعرَض في MOTD، مثل المعالج، والذاكرة، والمساحة التخزينية للقرص الصلب ...إلخ. على سبيل المثال: System load: 0.0 Processes: 76 Usage of /: 30.2% of 3.11GB Users logged in: 1 Memory usage: 20% IP address for eth0: 10.153.107.115 Swap usage: 0% Graph this data and manage this system at https://landscape.canonical.com/ ملاحظة: يمكنك تشغيل الأمر landscape-sysinfo في أي وقت يدويًا. 2. حزمة update-notifier-common: التي توفر معلومات عن التحديثات المتوفرة للحزم، والتحققات من أنظمة الملفات (fsck)، ومتى يجب إعادة الإقلاع (مثلًا، بعد تحديث النواة). تنفِّذ pam_motd السكربتات في ‎/etc/update-motd.d في ترتيبٍ مبنيّ على الرقم الذي يسبق اسم السكربت؛ يُكتَب ناتج السكربتات إلى ‎/‎var/run/motd، بترتيبٍ رقمي، ثم تُجمَّع مع ‎/etc/motd.tail. يمكنك إضافة البيانات الديناميكية إلى رسالة اليوم؛ فمثلًا، لإضافة معلومات الطقس المحلي: أولًا، ثبِّت حزمة weather-util: sudo apt-get install weather-util تستخدم أداة الطقس بيانات METAR من National Oceanic and Atmospheric Administration and Forecast من National Weather Service؛ وللعثور على المعلومات المحلية، فستحتاج إلى رمز ICAO من أربعة محارف؛ الذي يمكن تحديده بتصفح موقع http://www.weather.gov/tg/siteloc.shtml. وعلى الرغم من أن National Weather Service هي وكالة حكومية تابعة للولايات المتحدة، لكن هنالك محطات طقس متوفرة في جميع أنحاء العالم، لكن ربما لا تتوفر معلومات الطقس لجميع المناطق خارج الولايات المتحدة. أنشِئ الملف ‎/usr/local/bin/local-weather، الذي هو سكربت شِل بسيط للحصول على الطقس لمنطقتك المحلية: #!/bin/sh # # # Prints the local weather information for the MOTD. # # # Replace KINT with your local weather station. # Local stations can be found here: http://www.weather.gov/tg/siteloc.shtml echo weather -i KINT echo اجعل السكربت قابلًا للتنفيذ: sudo chmod 755 /usr/local/bin/local-weather ثم أنشِئ وصلةً رمزيةً إلى ‎/etc/update-motd.d/98-local-weather: sudo ln -s /usr/local/bin/local-weather /etc/update-motd.d/98-local-weather في النهاية، أغلق جلستك الحالية، وأعد تشغيل الدخول لمشاهدة رسالة اليوم الجديدة. يجب أن يُرحَّب بك الآن ببعض المعلومات المفيدة؛ لكن بعض المعلومات حول الطقس المحلي قد لا تكون مفيدةً جدًا! لكن هذا المثال يشرح مرونة pam_motd. etckeeper يسمح etckeeper بتخزين محتويات ‎/etc/‎ بسهولة في مستودع نظام تحكم بالإصدارات (VCS)؛ حيث يندمج مع apt لكي يودع التغيرات الحاصلة على ‎/etc تلقائيًّا عندما تُثبَّت أو تُحدَّث الحزم. وضع ‎/etc ضمن مستودع للتحكم بالإصدارات هو أفضل ممارسة يُنصَح بها في مجال العمل، وهدف etckeeper هو جعل هذه المهمة أسهل ما يمكن. أدخِل الأمر الآتي في الطرفية لتثبيت etckeeper: sudo apt-get install etckeeper ملف الضبط الافتراضي ‎/etc/etckeeper/etckeeper.conf هو بسيط جدًا؛ الخيار الرئيسي يكون لضبط أي متحكم بالإصدارات ليُستخدَم؛ افتراضيًا، يكون etckeeper مضبوط لاستخدام Bazaar للتحكم بالإصدارات؛ ويُهيَّأ المستودع تلقائيًّا (ويُودَع فيه لأول مرة) أثناء عملية تثبيت الحزمة؛ من الممكن التراجع عن هذه الخطوة بإدخال الأمر: sudo etckeeper uninit سيودع etckeeper التغيرات غير المودعة التي حصلت على ‎/etc يوميًا افتراضيًا؛ يمكن تعطيل هذا باستخدام خيار الضبط AVOID_DAILY_AUTOCOMMITS؛ وستودع أيضًا التغيرات تلقائيًا قبل وبعد تثبيت الحزم؛ للمزيد من القدرة على التحكم بالتغيرات، من المستحسن أن تودع التغيرات يدويًا مع رسالة الإيداع كما يلي: sudo etckeeper commit "..Reason for configuration change.." يمكنك باستخدام أوامر VCS مشاهدة سجل المعلومات حول الملفات في ‎/etc: sudo bzr log /etc/passwd لشرح طريقة الاندماج مع نظام إدارة الحزم، جرِّب تثبيت الحزمة postfix: sudo apt-get install postfix بعد انتهاء التثبيت، ستودَع كل ملفات ضبط postfix إلى المستودع: Committing to: /etc/ added aliases.db modified group modified group- modified gshadow modified gshadow- modified passwd modified passwd- added postfix added resolvconf added rsyslog.d modified shadow modified shadow- added init.d/postfix added network/if-down.d/postfix added network/if-up.d/postfix added postfix/dynamicmaps.cf added postfix/main.cf added postfix/master.cf added postfix/post-install added postfix/postfix-files added postfix/postfix-script added postfix/sasl added ppp/ip-down.d added ppp/ip-down.d/postfix added ppp/ip-up.d/postfix added rc0.d/K20postfix added rc1.d/K20postfix added rc2.d/S20postfix added rc3.d/S20postfix added rc4.d/S20postfix added rc5.d/S20postfix added rc6.d/K20postfix added resolvconf/update-libc.d added resolvconf/update-libc.d/postfix added rsyslog.d/postfix.conf added ufw/applications.d/postfix Committed revision 2. وكمثال عن طريقة تتبع etckeeper للتغيرات اليدوية، أضف مضيفًا جديدًا إلى ملف ‎/etc/hosts؛ ثم استخدام bzr لمشاهدة أي ملفات قد عُدِّلَت: sudo bzr status /etc/ modified: hosts يمكنك إيداع التغيرات الآن: sudo etckeeper commit "new host" للمزيد من المعلومات حول bzr، راجع درس نظرة سريعة على Bazaar، نظام التحكم في الإصدارات على أوبنتو. Byobu أحد أكثر البرامج فائدةً لأي مدير أنظمة هو screen، حيث يسمح بتنفيذ عدِّة صدفات (shells) في طرفية واحدة؛ ولجعل بعض ميزات screen المتقدمة أكثر قربًا من المستخدم، ولتوفير بعض المعلومات المفيدة عن النظام؛ أنشِئت الحزمة byobu. عند تنفيذ byobu، سيُظهِر الضغط على زر F9 قائمةَ الضبط التي تسمح لك بما يلي: عرض قائمة المساعدة. تغيير لون خلفية Byobu. تغيير لون أمامية Byobu. تبديل ظهور شريط الإشعارات. تغيير ربط المفاتيح. تغيير سلسلة الخروج. إنشاء نوافذ جديدة. إدارة النوافذ الافتراضية. «لا يبدأ Byobu عند تسجيل الدخول (تفعيل ذاك الخيار)". ربط المفاتيح يحدد بعض الأمور مثل سلسلة الخروج (escape sequence)، وإنشاء نافذة جديدة، وتغيير النافذة ...إلخ. هنالك مجموعتا ربط للمفاتيح يمكن الاختيار بينها، واحدة باسم f-keys، والأخرى screen-escape-keys؛ إذا أردت استخدام الربط الافتراضي، فاختر none. يوفر byobu قائمةً تُظهِر إصدارة أوبنتو، ومعلومات المعالج، ومعلومات الذاكرة، والوقت والتاريخ؛ مما يجعلها تبدو كقائمة سطح مكتب. تفعيل خيار "لا يبدأ Byobu عند تسجيل الدخول" سيجعل byobu يبدأ عند فتح أي طرفية؛ التغيرات التي تحصل على byobu تكون خاصة بالمستخدم، ولن تؤثر على بقية مستخدمي النظام. أحد الميزات في byobu هو نمط scrollback، اضغط على زر F7 للدخول بوضع scrollback، الذي يسمح لك بالتنقل إلى المخرجات السابقة باستخدام أوامر شبيهة بأوامر محرر vi؛ هذه قائمة سريعة بأوامر الحركة: h: تحريك المؤشر إلى اليسار محرفًا واحدًا. j: تحريك المؤشر إلى الأسفل سطرًا واحدًا. k: تحريك المؤشر إلى الأعلى سطرًا واحدًا. l: تحريك المؤشر إلى اليمين محرفًا واحدًا. : تحريك المؤشر إلى بداية السطر الحالي. $: تحريك المؤشر إلى نهاية السطر الحالي. G: تحريك المؤشر إلى سطر محدد (افتراضيًا إلى النهاية). ?: البحث إلى الخلف. n: الانتقال إلى المطابقة التالية إما إلى الأمام أو إلى الخلف. مصادر راجع صفحة الدليل man update-motd للمزيد من الخيارات المتوفرة لحزمة update-motd. راجع موقع etckeeper لمزيدٍ من التفاصيل حول استخدامه. راجع أيضًا صفحة ويكي أوبنتو "etckeeper". لآخر الأخبار عن bzr، انظر إلى موقع bzr الرسمي. لمزيد من المعلومات حول screen، راجع موقعه الرسمي. وأيضًا صفحة ويكي أوبنتو "Screen". راجع صفحة مشروع Byobu لمزيدٍ من المعلومات. ترجمة -وبتصرف- للمقال Ubuntu Server Guide: Other Useful Applications.

توفر معظم الأنظمة الشبيهة بيونكس آلية مركزية لإيجاد وتثبيت البرمجيات. تُوزَع البرمجيات عادة في شكل حزم، مُخزنة في مستودعات. التعامل مع الحزم يُعرَف بإدارة الحزم. توفر الحزم المكونات الأساسية لنظام التشغيل، مع المكتبات المشتركة، التطبيقات، الخدمات والوثائق. يقوم نظام إدارة الحزم بأكثر من تثبيت البرمجيات لمرة واحدة. فهو يوفر أيضًا أدوات لترقية الحزم المثبتة حاليًا. تُساعد مستودعات الحزم على التأكد من أن الشيفرة فُحِصَت للاستخدام على نظامك، وأن المطورين والمشرفين وافقوا على نُسخ البرمجيات المُثبتة. عند ضبط الخواديم أو بيئات التطوير، غالبًا ما يكون النظر لما وراء المستودعات الرسمية ضروريًا. فقد تكون الحزم في الإصدار المُستقر من التوزيعة قديمة، خصوصًا عندما تكون البرمجيات المعنية سريعة التغيُر. وبالرغم من هذا، فإن إدارة الحزم هي مهارة حيوية لمدراء الأنظمة والمطورين، ووفرة البرمجيات المُحزّمة للتوزيعات الرئيسية هي مورد هائل. اُعد هذا الدّليل ليكون مرجعًا سريعًا لأساسيات إيجاد، تثبيت وترقية الحزم على مجموعة متنوعة من التوزيعات، وينبغي أن يساعدك على ترجمة هذه المعرفة بين الأنظمة. أنظمة إدارة الحزم: لمحة موجزة معظم أنظمة الحزم تُبنَى من مجموعات من ملفات الحزم. ملف الحزمة هو أرشيف يحتوي على ملفات ثُنائية مُترجمة ومصادر أخرى تُشكل البرنامج، مع سكربتات التثبيت. تحتوي الحزم أيضًا على بيانات وصفية قيّمة، تتضمن اعتمادياتها وقائمة من الحزم الأخرى المطلوبة لتثبيتها وتشغيلها. على الرغم من تشابه وظائف وفوائد تنسيقات وأدوات التحزيم إلى حد بعيد، إلا أنها تختلف باختلاف المنصات: نظام التشغيل التنسيق الأدوات Debian .deb apt, apt-cache, apt-get, dpkg Ubuntu .deb apt, apt-cache, apt-get, dpkg CentOS .rpm yum Fedora .rpm dnf FreeBSD Ports, .txz make, pkg تنسيق الحزم في دبيان والأنظمة المبنية عليها مثل أوبنتو، لينكس منت وراسبيان يكون كملف .deb. تُوفر أداة الحزم المُتقدمة APT أوامر لمعظم العمليات الشائعة: البحث بالمستودعات، تثبيت مجموعات من الحزم واعتمادياتها وإدارة الترقيات. تعمل أوامر APT كواجهة أمامية للأداة منخفضة المستوى dpkg، والتي تقوم بتثبيت ملفات .deb الفردية على النظام محليًا، وأحيانًا تُستدعى مباشرةً. تَستخدم CentOS، فيدورا والتوّزيعات الأخرى في عائلة Red Hat ملفات بتنسيق RPM. يُستخدم yum في CentOS للتفاعل مع ملفات الحزم الفردية والمستودعات. في النُسخ الحديثة من فيدورا حل dnf محل yum، وهو مُشتق حديث يحتفظ بمعظم خصائص واجهة yum النصية. يُدار نظام الحزم الثنائية في FreeBSD بالأمر pkg. ويوفر FreeBSD كذلك ما يُطلق عليه اسم Ports Collection، وهو هيكل مُجلدات محلية وأدوات تسمح للمُستَخدِم بجلب، تجميع وتثبيت الحزم مباشرة من المصدر باستخدام ملفاتMakefile. استخدام pkg مُريح غالبًا، ولكن أحيانًا لا تتوافر حزم مُترجمة مسبقًا، أو قد تُريد تغيير الخيارات بوقت الترجمة. تحديث قوائم الحزم تحتفظ معظم الأنظمة بقاعدة بيانات محلية للحزم المتوافرة بالمستودعات البعيدة. من الأفضل تحديث قاعدة البيانات قبل ترقية الحزم. وكاستثناء جزئي لهذا النمط، سيتحقق yum و dnf من وجود تحديثات قبل القيام ببعض العمليات، لكن يمكنك سؤالها عن توافر التحديثات بأي وقت. النظام الأمر Debian / Ubuntu sudo apt-get update CentOS yum check-update Fedora dnf check-update FreeBSD Packages sudo pkg update FreeBSD Ports sudo portsnap fetch update ترقية الحزم المثبتة التأكد من حداثة البرمجيات المُثبتة على النظام ستكون مهمة ضخمة بدون نظام حزم. ستضطر أن تتتبع تغييرات المنبع والتنبيهات الأمنية لمئات من الحزم المختلفة. على الرغم من أن مدير الحزم لن يحل كل مشكلة ستقابلها عند ترقية البرمجيات، إلا أنه يُمَكِنُك من صيانة معظم مكونات النظام بأوامر قليلة. ترقية الـ port المُثبتة على FreeBSD يمكن أن تُؤدي إلى إدخال أعطال أو تتطلب خطوات ضبط يدوية. من الأفضل أن تقرأ usr/ports/UPDATING/ قبل الترقية باستخدام portmaster. النظام الأمر ملاحظات Debian / Ubuntu sudo apt-get upgrade يُرقي الحزم الجديدة فقط، إن كان بالإمكان. sudo apt-get dist-upgrade قد يُضيف أو يحذف حزم لتلبية الاعتماديات الجديدة. CentOS sudo yum update Fedora sudo dnf upgrade FreeBSD Packages sudo pkg upgrade FreeBSD Ports less /usr/ports/UPDATING يُستخدم الأمر less لعرض ملاحظات التحديث للمنافذ. استخدم مفاتيح الأسهم للانتقال، اضغط q للخروج. cd /usr/ports/ports-mgmt/portmaster && sudo make install && sudo portmaster -a يُثبت portmaster ويستخدمه لتحديث المنافذ المُثبتة. إيجاد حزمة توفر معظم التوزيعات واجهة رسومية لمجموعات الحزم. هذه طريقة جيدة للتصفح بالفئة واكتشاف برمجيات جديدة. على الرغم من أنه غالبًا تكون الطريقة الأسرع والأكثر كفاءة لإيجاد حزمة هي البحث باستخدام أدوات سطر الأوامر. النظام الأوامر ملاحظات Debian / Ubuntu apt-cache search search_string CentOS yum search search_string yum search all search_string يبحث بجميع الحقول، من ضمنها الوصف. Fedora dnf search search_string dnf search all search_string يبحث بجميع الحقول، من ضمنها الوصف. FreeBSD Packages pkg search search_string يبحث بالاسم. pkg search -f search_string يبحث بالاسم، ويُعيد وصف كامل. pkg search -D search_string يبحث بالوصف. FreeBSD Ports cd /usr/ports && make search name=package يبحث بالاسم. cd /usr/ports && make search key=search_string يبحث في الأسماء، الأوصاف والاعتماديات. عرض معلومات عن حزمة محددة من المفيد قراءة أوصاف تفصيلية عن الحزم التي قررت تثبيتها. إلى جانب نص قابل للقراءة، يتضمن غالبًا بيانات وصفية مثل أرقام النُسخ وقائمة من اعتماديات الحزم. النظام الأمر ملاحظات Debian / Ubuntu apt-cache show package يعرض المعلومات المُخزنة محليًا عن الحزمة package. dpkg -s package يعرض حالة التثبيت الحالية للحزمة package. CentOS yum info package yum deplist package يسرد اعتماديات الحزمة package. Fedora dnf info package dnf repoquery –requires package يسرد اعتماديات الحزمة package. FreeBSD Packages pkg info package يعرض معلومات عن الحزمة المُثبتة package. FreeBSD Ports cd /usr/ports/category/port && cat pkg-descr تثبيت حزمة من المستودعات بمجرد معرفة اسم الحزمة، يمكن تثبيت الحزمة واعتمادياتها بأمر واحد. عمومًا، يمكنك طلب تثبيت حزم عديدة ببساطة عن طريق ذكرها جميعًا. النظام الأمر ملاحظات Debian / Ubuntu sudo apt-get install package sudo apt-get install package1 package2 … يُثبت كل الحزم المذكورة package1 package2 … sudo apt-get install -y package يُجيب بنعم عندما يطلب apt الاستمرار. CentOS sudo yum install package sudo yum install package1 package2 … يُثبت كل الحزم المذكورة package1 package2 … sudo yum install -y package يُجيب بنعم عندما يطلب yum الاستمرار. Fedora sudo dnf install package sudo dnf install package1 package2 … يُثبت كل الحزم المذكورة package1 package2 … sudo dnf install -y package يُجيب بنعم عندما يطلب dnf الاستمرار. FreeBSD Packages sudo pkg install package sudo pkg install package1 package2 … يُثبت كل الحزم المذكورة package1 package2 … FreeBSD Ports cd /usr/ports/category/port && sudo make install يبني ويُثبت منفذ من المصدر. تثبيت حزمة من نظام الملفات المحلي أحيانًا، بالرغم من عدم تحزيم البرمجيات رسميًا لنظام معين، سيوفر المطور أو البائع ملفات الحزم للتحميل. يمكنك الحصول عليهم عبر المتصفح، أو من خلال curl على سطر الأوامر. بمجرد وجود الحزمة على النظام، يمكن عادة تثبيتها بأمر واحد. يتعامل dpkg مع ملفات الحزم الفردية على الأنظمة الدبيانية. إذا كان هناك اعتماديات ناقصة لحزمة، فيمكن استخدام gdebi لجلب هذه الاعتماديات من المستودعات الرسمية. يُستخدم yum و dnf على أنظمة فيدورا و CentOS لتثبيت ملفات الحزم الفردية، ومُعالجة الاعتماديات المطلوبة أيضًا. النظام الأمر ملاحظات Debian / Ubuntu sudo dpkg -i package.deb sudo apt-get install -y gdebi && sudo gdebi package.deb يُثبت ويستخدم gdebi لتثبيت الحزمة package.deb ويَحصُل على أي اعتماديات ناقصة. CentOS sudo yum install package.rpm Fedora sudo dnf install package.rpm FreeBSD Packages sudo pkg add package.txz sudo pkg add -f package.txz يُثبت الحزمة package حتى وإن كانت مُثبتة. إزالة حزمة واحدة أو أكثر بما أن مدير الحزم يعرف الملفات التي تأتي مع حزمة مُعينة، فيمكن إزالة هذه الملفات بشكل نظيف من النظام إذا لم يعد هناك حاجة لهذه الحزمة. النظام الأمر ملاحظات Debian / Ubuntu sudo apt-get remove package sudo apt-get autoremove يُزيل الحزم غير الضرورية. CentOS sudo yum remove package Fedora sudo dnf erase package FreeBSD Packages sudo pkg delete package sudo pkg autoremove يُزيل الحزم غير الضرورية. FreeBSD Ports sudo pkg delete package cd /usr/ports/path_to_port && make deinstall يلغي تثبيت منفذ مُثبت. الحصول على المساعدة بالإضافة إلى التوثيقات المتوافرة على الشبكة، ضع في اعتبارك أن صفحات دليل يونكس (يُشار إليها بصفحات الدليل) متوافرة لمعظم الأوامر من الصدفة. استخدم man لقراءة صفحة page على النّحو التّالي: $ man page يمكنك الانتقال بمفاتيح الأسهم في man. اضغط / للبحث عن نص في الصفحة، و q للخروج. النظام الأمر ملاحظات Debian / Ubuntu man apt-get تحديث قاعدة البيانات المحلية والتعامل مع الحزم. man apt-cache الاستعلام في قاعدة بيانات الحزم المحلية. man dpkg التعامل مع ملفات الحزم الفردية والاستعلام عن الحزم المُثبتة. CentOS man yum Fedora man dnf FreeBSD Packages man pkg التعامل مع الحزم الثنائية المُترجمة مُسبقًا. FreeBSD Ports man ports التعامل مع مجموعات المنافذ. خاتمة ولمزيد من القراءة عرضنا العمليات الأساسية التي يمكن استخدامها كمرجع بين الأنظمة، لكننا لم نتطرّق سوى إلى أساسيات الأمر. للحصول على مزيد من التفاصيل لنظام معين، راجع المصادر التالية: يُغطي هذا الدليل إدارة حزم دبيان وأوبنتو بالتفصيل. هناك دليل CentOS الرسمي لإدارة البرمجيات باستخدام yum. هناك صفحة wiki فيدورا عن dnf، ودليل dnf الرسمي. يُغطي هذا الدليل إدارة حزم FreeBSD باستخدام pkg. يحتوي دفتر FreeBSD على قسم لاستخدام مجموعات المنافذ. ترجمة -وبتصرّف- للمقال Package Management Basics: apt, yum, dnf, pkg لصاحبه Brennen Bearnes.