في نهاية شهر مايو ،
شاركت Embox ، بالفعل ، في
OSDay . عقد المؤتمر ، مثل العام الماضي ، في المبنى الرئيسي ل RAS. هذه المرة كانت مخصصة للموثوقية. موضوع موثوقية البرامج قديم. يتأثر ، على سبيل المثال ، من قبل
فريدريك بروكس في عمله الأسطوري
Mythical Man-Month ، والذي تمت الإشارة إليه أيضًا عدة مرات في المؤتمر نفسه. يذكر الكتاب أن إحدى المشكلات التي تمت مواجهتها في عملية إنشاء
نظام التشغيل OS / 360 كانت عدم وجود عدد كاف من المبرمجين المؤهلين. ربما ، لنفس السبب ، تم تخصيص الكثير من الوقت في المؤتمر للتعليم في مجال برمجة النظام. بشكل عام ، من يهمه الأمر ، في رأيي ، التعبير عن أفكار مثيرة للاهتمام ومناقشتها في المؤتمر ، أطلب القط.
في افتتاح المؤتمر ، عبر أحد مؤسسيها ، دميتري
زافاليشين دزافاليشين ، عن عدة نقاط:
- أنظمة البرمجيات الحديثة معقدة للغاية لدرجة أن الموثوقية مطلوبة لأي منها ، وليس فقط لـ "الأنظمة الخاصة" ، كما كان من قبل
- قد يكون لدى الأشخاص المختلفين أفكار مختلفة حول موثوقية البرامج ، على سبيل المثال ، يعتبر بعض الأشخاص أن الموثوقية مرادف للأمان.
- يمكن أن تختلف طرق ضمان الموثوقية ، بناءً على الأقل على افتراض أن مفاهيم الموثوقية تختلف
في اليوم الأول ، قدم ISP RAS
تقريرًا عن موثوقية البرامج من وجهة نظر أكاديمية. وعلى الرغم من أنه كان على الأرجح تكريمًا للتاريخ ، إلا أنه كان واضحًا منها أن المشكلة لم تكن جديدة ، وأن تعريفات الموثوقية ، بالإضافة إلى طرق تقييمها ، كانت شديدة التنوع. التقرير ، على الرغم من قطعه بشدة (كما حاول المتحدث الاحتفاظ به في غضون 30 دقيقة) ، كان مثيرًا للاهتمام لطبيعته العلمية.
طرق مفيدة
يمكن تقسيم طرق ضمان موثوقية الكود إلى عدة فئات. سأبدأ بالأدوات التي اشتهر بها مضيف المؤتمر ، ISP RAS. قدم موظفه
تقريرًا عن تجربة التحقق من قطع نواة Linux باستخدام أداة klever.
Klever هو إطار عمل مفتوح للتحقق من التعليمات البرمجية الثابتة. في الواقع ، يمكن صياغة المشكلة التي حلها كاتب التقرير على النحو التالي. إن التحقق من التعليمات البرمجية الثابتة معقد للغاية بحيث لا يمكن التحقق من المشاريع الحديثة ككل ، ولكن يمكنك محاولة عزل بعض الأجزاء المعزولة أكثر أو أقل ، على سبيل المثال ، نظام Linux kernel الفرعي أو برنامج تشغيل منفصل ، وبعد تحديد البيئة المناسبة لذلك ، تحقق من ذلك. ثم يمكنك القيام بذلك بشكل متكرر مع المشروع بأكمله.
الأساليب المعمارية
نهج آخر لبناء أنظمة أكثر موثوقية هو استخدام التقنيات "المعمارية". بالنسبة إليهم ، أود أن أدرج فكرة الذاكرة الثابتة
لنظام Phantom OS وبنية
MILS (مستويات مستقلة متعددة من الأمن / السلامة).
تناول تقرير MILS خصائصه لتعزيز أمن الأنظمة الحيوية وتم تقديمه إلى Kaspersky Lab.
تم تقديم التقرير حول جامع القمامة في ظروف الذاكرة المستمرة ليس فقط من قبل مؤلف OS Phantom ، ولكن أيضًا من قبل طالب في جامعة Innopolis. وبطبيعة الحال ، فإن فكرة استخدام لغات الإدارة لزيادة موثوقية النظام ليست جديدة. وفي التقرير ، في رأيي ، كان من المهم إشراك الطلاب في مشروع مفتوح المصدر لإنشاء برمجيات النظام.
نهج منهجي
الأكثر عددًا من حيث عدد التقارير ، ولكن النهج الذي يتم التقليل منه لتحسين موثوقية البرامج ، في رأيي ، هو "منهجي". إذا كنت تفكر في ذلك ، فإن فصل نظام التشغيل ككيان منفصل كان يهدف إلى تحسين موثوقية البرنامج. حصل المبرمج على فرصة لإعادة استخدام خدمات النظام ، وليس لتطويرها مرة أخرى.
قدم FSUE GosNIIAS
تقريرًا حول منهجية تطوير البرامج الحرجة. تم
تخصيص التقرير لتطوير معيار
DO-178C (CT-178C في النسخة الروسية). كما هو الحال في المعيار نفسه ، كان التقرير يحتوي على الكثير من "الملل" ، ولكن بعد كل شيء ، عندما تصنع طائرة ، لا يمكنك التخلص من بعض الأفكار الساحرة ، تحتاج إلى التحقق من مجموعة من المرات قبل إجراء أدنى تغيير. بشكل عام ، قم بقياس مرة واحدة ، قطع سبع مرات ، أوه ، على العكس بالطبع. بطبيعة الحال ، لم يكن التقرير مثيرًا للاهتمام بسبب "شدته" ، ولكن لحقيقة أن الأدوات تم تطويرها لأتمتة هذه العملية ، أي للحد من "الملل".
المصدر المفتوح
أخيرًا ، أنتقل إلى القسم الذي تحدث فيه Embox. كان
تقريرنا بعنوان "تنظيم دعم التسارع ثلاثي الأبعاد في نظام RTOS على أساس مشاريع مفتوحة المصدر". في ذلك ، تم تخصيص جزء كبير إلى حد ما للتفسير ، وهنا الموثوقية. بل كان هناك شريحة مثل "الموثوقية والتسارع ثلاثي الأبعاد للأجهزة". الموثوقية ، بالطبع ، ليست في التسارع ثلاثي الأبعاد ، ولكن في عبارة "على أساس مشاريع مفتوحة المصدر". خلاصة القول هي أننا تمكنا من إضافة دعم لمسرع vivante ثلاثي الأبعاد مغلق باستخدام مشاريع مفتوحة المصدر. وعلى الرغم من أن مشروع
Mesa الذي نستخدمه مرتبط بقوة بواجهة Linux kernel ، إلا أن التكيف يتطلب جهدًا أقل بكثير ويحتوي على عدد أقل بكثير من أسطر التعليمات البرمجية من التطوير من البداية.
كما أشرت من قبل ، المصدر المفتوح هو أكثر الفئات التي تم ربط التقارير في المؤتمر بها بطريقة أو بأخرى. على سبيل المثال ، قدمت Basalt SPO
تقريرًا حول تطوير أداة مزامنة ملف clsync. لن أخوض في التفاصيل الفنية ، شيء آخر مهم. كما هو موضح في اسم الشركة ، فإن
الأداة مفتوحة المصدر ، وبعد التقرير اتبعت بعض النصائح ، على سبيل المثال ، لاستخدام
futex ، الذي اقترح عليه المتحدث الانضمام إلى المشروع وتحسينه بشكل مستقل.
الأكثر إثارة للاهتمام من حيث المصدر المفتوح ، في رأيي ، كان
تقرير موظف التقنيات الإيجابية الكسندر بوبوف.
كان التقرير بعنوان "كيف تعمل STACKLEAK على تحسين أمان Linux Kernel" وبدا أنه كان يجب أن يكون مخصصًا لقصة STACKLEAK وما تم تناوله به. ولكن تم تخصيص الوقت الرئيسي للتقرير للموضوع ، والذي تم التعبير عنه في العبارة من التعليق التوضيحي للتقرير:
“ألكسندر يقوم بهذا العمل لمدة عام. وسيتبادل خبراته مع مجتمع تطوير نواة لينكس " . أي أنه خلال العام يتم دفع التغييرات المفيدة ، ويشارك العديد من الأشخاص ، ويتم فحص التغييرات تحت المجهر من قبل متخصصين مؤهلين يعملون في أنظمة فرعية مختلفة من النواة. بالطبع ، هذا لا يضمن الغياب التام للأخطاء ، ولكنه يقلل من عددها ، وبالتالي يزيد من موثوقية الشفرة.
نهج بديل
في المؤتمر ، مثل
العام الماضي ، تم تقديم
تقرير عن نظام QP OS. في ملخص التقرير يمكنك أن ترى ما يلي: "نظام التشغيل الآمن QP OS هو تطوير محلي بالكامل ، تم إنشاؤه" من الصفر "من قبل فريق المؤسسة العلمية والتقنية" Cryptosoft ". كما عبر التقرير عن مبدأ التطوير من الصفر ، ليس فقط من نظام التشغيل ، والمراقب الافتراضي ، ومكدس الشبكة ، ولكن أيضًا من جميع الأنظمة الفرعية وتطبيقات المستخدم ، بالإضافة إلى المترجم ، C # الآلة الافتراضية ، وكما أفهمها ، جميع أدوات التطوير الأخرى. بالنسبة لسؤالي إلى المتحدث ، ماذا عن الموثوقية ، لأن نسبة عدد الأخطاء لكل ألف سطر من التعليمات البرمجية لم يتم إلغاؤها. حصلت على إجابة مفادها أن الموثوقية يمكن فهمها على أنها أشياء مختلفة ، وأنها تعتبر موثوقة لنظام تشغيل معين إذا كانت أقل وأقل بين عمليتي إعادة تشغيل. بالفعل بعد التقرير ، على الهامش ، نصحت بأخذ مشروع مفتوح لتقديم دعم أكثر اكتمالاً
للسامبا . لكنه تلقى إجابة بأنه موقف مبدئي لتطوير كل شيء بشكل مستقل ، مع توضيح أن مثل هذا النهج له الحق في الحياة. حسنًا ، وصفته بأنه نهج بديل.
وتجدر الإشارة إلى أنه كان هناك معرض في المؤتمر ، وتم تقديم جناح يمكن فيه تجربة نظام QP OS مباشرة. لقد لعبت مع محررهم ، لقد نجحت بشكل جيد. في المنصة ، أكدوا أنهم لم يقترضوا حتى رمز المكتبات للعمل مع XML. بالإضافة إلى ذلك ، ربما يأتي نهج مماثل "كل شيء من الصفر" من النطاق الذي يعمل فيه المطورون. يتميز هذا المجال بأمنه المفرط ، فمن الأفضل السقوط من وضع إشارة مرجعية في مكان ما. صحيح ، هذا لا يبرر رفض استخدام رمز مفتوح المصدر.
الوقت الحقيقي الصعب
في هذا القسم ، لا يسعني إلا أن أشير إلى تقرير آخر ، على الأقل لأن المتحدث أشار إلى عرضي ، وبالتالي يحق لي أن أفعل الشيء نفسه. بعد خطابي ، سُئلت عما إذا كان دعم المسرِّع ثلاثي الأبعاد لا يتداخل مع توفير خصائص الوقت الفعلي ، وبشكل عام ، هل مشروعنا نظام تشغيل صعب في الوقت الفعلي؟ لقد أجبت بشكل نهائي على السؤال الأخير ، لأن الوقت في المؤتمر محدود ، والسؤال عما يعنيه الوقت الحقيقي يتطلب تفسيراً جاداً إلى حد ما. تحدث المتحدث المذكور بعدي مباشرة مع
تقرير عن Eremex FX-RTOS RTOS وذكر أنه على عكس مشروعنا ، فإن نظام التشغيل الخاص بهم هو نظام في الوقت الحقيقي الصعب. علامة على الوقت الحقيقي الصعب ، وفقًا للمتكلم ، هو عدم وجود دورات مع عدد متغير من التكرارات مع الانقطاعات المحظورة.
لا أجرؤ على الحكم على ما إذا كانت هناك حلقات لانهائية محتملة مع مقاطعات محظورة في FX-RTOS RTOS أم لا ، نظرًا لأن الرمز مغلق ، ولكن بالطبع أوافق على أن هذه الدورات غير مقبولة حتى في أنظمة التشغيل العادية ، ناهيك عن RTOS!
بالإضافة إلى ذلك ، خلال التقرير ، ذكر أن المطورين تمكنوا من تجنب حجب المقاطعات (الإخفاء) تمامًا ، على الرغم من ذلك فقط على ذراع القشرة m ، ولكن لا يزال هذا إنجازًا كبيرًا ، والذي يشير أيضًا ، وفقًا للمتحدث ، إلى الوقت الفعلي. بالإضافة إلى ذلك ، توقف مكبر الصوت لفترة طويلة على جهاز يعتمد على FX-RTOS ، والذي أجاب عبر واجهة UART لعدة مللي ثانية ، مما يشير مرة أخرى إلى صعوبة الوقت الحقيقي.
لا أعرف من منا لديه نهج بديل لمفهوم "الوقت الحقيقي" ، سأعبر فقط عن وجهة نظري. وسأجيب فقط على سؤال ما إذا كان Embox هو نظام في الوقت الفعلي.
يرتبط مفهوم الوقت الحقيقي مباشرة بإمكانية التنبؤ بسلوك النظام تحت تأثير أي عوامل (داخلية وخارجية). من هذا ، يتبع اتصال مفهوم الوقت الحقيقي مع مفهوم الموثوقية. ومن ثم فإن فكرة أن النوافذ ، كنظام تشغيل عالمي ، غير موثوق بها ، وأن نظام التشغيل في الوقت الفعلي (مثل النظام الذي بني عليه) موثوق به.
تعد معلمات وقت التفاعل واحدة من أهم عوامل التنبؤ ، ولكن في أنظمة الوقت الفعلي ، ليس معدل التفاعل مهمًا مثل التغير في وقت التفاعل ، ويجب أن يكون محدودًا بشكل صارم. لقد صادفت تعريفًا حيث تم تعريف الوقت الفعلي اللين على أنه نظام ذو متوسط قيمة استجابة صغيرة للنظام ، وصعب - بحد أقصى صغير. وبما أن سرعة المعالجات الحديثة قد زادت بشكل كبير ، لم يعد وقت (متوسط) التنفيذ يلعب هذا الدور ، لأنه لزيادة سرعة رد الفعل يكفي لوضع معالج أكثر قوة. ولكن ليس من الممكن التخلص من تأثير الخوارزميات والهندسة المعمارية ، أي أن لينكس
بجدولة نزيهة ، تهدف إلى أقصى حمل لوحدة المعالجة المركزية ، لا يمكن اعتباره نظامًا في الوقت الفعلي. على الرغم من أنني متأكد من أن وقت رد الفعل وفقًا لـ UART يمكن أن يكون صغيرًا جدًا ، إلا أنه لن يكون مستقرًا ، لأن المجدول قد يقرر أنه يحتاج إلى تحميل المعالج ببعض المهام الأخرى ، وسيزيد وقت الاستجابة بشكل غير متوقع. لذلك ، يمكننا صياغة الخاصية التالية لأنظمة التشغيل في الوقت الفعلي: هذه أنظمة تشغيل توفر أفضل تحكم لجميع أنظمتها ، بما في ذلك الأنظمة الداخلية. خذ على سبيل المثال
ARINC-653 مع متطلباته من حيث جدولة مع جدول ثابت. في أنظمة التشغيل هذه ، يمكن للمطور الوصول إلى جداول التخطيط ، التي يملؤها في وقت تطوير النظام. أي أن المطور يخصص الوقت (الفواصل الزمنية) في فترة التخطيط العامة لكل قسم ، ويتم تعطيل جميع المقاطعات (باستثناء المؤقت ، بالطبع ، متاح فقط للجدولة) ، ويجب على المطور وضع جدول زمني كهذا بحيث يكون لكل قسم الوقت الكافي لحل مشكلته. في الوقت نفسه ، ليس من حق المجدول تغيير هذا الجدول بطريقة أو بأخرى.
إذا فكرت في أنظمة التشغيل الأخرى التي توفر وصولاً كاملاً أو موسعًا إلى "giblets" ، فمن السهل الوصول إلى استنتاج مفاده أن المشاريع الحديثة لأنظمة التشغيل الصغيرة لها اسم فخور RTOS (نظام التشغيل في الوقت الفعلي). نظرًا لأنها توفر هذا الوصول ، والمطور مسؤول بالفعل عن ضمان أن النظام النهائي الذي تم بناؤه على أساس RTOS يلبي جميع المتطلبات ، بما في ذلك إمكانية التنبؤ برد الفعل تجاه أي تأثير!
أما بالنسبة لـ Embox ، فنحن نقدم أيضًا آليات التحكم لجميع الخدمات ، بما في ذلك النواة. ومن وجهة النظر هذه ، Embox هو نظام تشغيل في الوقت الفعلي. نعم ، تم إنشاء الأنظمة ذات بنية MILS على أساس Embox (لا أسميها بوعي ARINC-653 ، حيث يتم تحديد ARINC-653 بواسطة الشهادة للامتثال للمعيار) ، ولكن يمكنك أيضًا بناء بنية أخرى تضمن إمكانية التنبؤ الكافية للتفاعل. قام أحد العملاء ، على سبيل المثال ، بفحص وقت الاستجابة على مرسمة الذبذبات ، وكان الوقت دقيقًا لعدة دورات للمعالج وكان محدودًا للغاية. صحيح ، لم يتم تحميل النظام ، من التطبيقات النشطة ، فقط الخادم كان يدور ، والذي تفاعل مع الحدث. لكن العميل كان مسرورًا جدًا بالنتيجة. لذلك ، نعتقد أنه من الممكن فقط التحدث عن الوقت الحقيقي في التطبيق على النظام ككل ، والمطور هو المسؤول عن ذلك ، ونظام التشغيل في الوقت الحقيقي الصعب يوفر فقط آليات لتحقيق هذا الوقت الحقيقي. نحن أكثر دقة في تصنيفنا وقد كتبنا
»Embox - صندوق الأدوات الأساسي للتطوير المضمن" .
الكوادر تقرر كل شيء
العبارة الغريبة في العنوان "ماذا تحتاج لتعليم الطلاب حتى يبدأوا العمل على الفور في شركات تكنولوجيا المعلومات الروسية ويبقون هناك" - هذا في الواقع سؤال أثير في حلقة نقاش. خُصص ربع المؤتمر لمشكلة التدريب والتعليم في مجال تكنولوجيا المعلومات. من خلال فهم أهمية المشكلة وعدم تناسقها ، تعامل المنظمون مع المشكلة بشكل مثير للاهتمام. تم تسليم أربعة تقارير ، كما تصورها المنظمون ، مثل المتحدثون مناهج تنافسية. لذلك ، هناك تقريران عن الدورة التدريبية يحملان نفس الاسم "هندسة الكمبيوتر ولغة التجميع" في كلية
VMK MSU . أحد التقارير قدمه
جورج كورياتشي ، الآخر -
فارتان باداريان . في الواقع ، كانت النهج متشابهة ، ولا يهم أن المجمع MIPS تمت دراسته في دورة واحدة ، و x86 في الآخر. في كلتا الحالتين ، سعى المعلمون إلى تطوير الدورة في المجال العملي. استمرارًا للموضوع حول أهمية المكون العملي للتدريب ، تم تقديم
تقرير من قبل أليكسي خوروشيلوف "تصميم نواة نظام التشغيل". يمكننا أن نقول أن هذه الدورة توسع من فهم بنية الكمبيوتر وتسمح للطلاب بالتعمق في جوهر نظام التشغيل. ونتيجة لذلك ، بدلاً من المناهج المتنافسة ، اتضح أن كلية VMK لديها نهج منظم ، أي أن الدورات لا تتنافس ، ولكنها تكمل وتطور بعضها البعض. في الواقع ، يجب أن يكون الأمر كذلك. كما بدت العبارة أيضًا: "لتعلم البرمجة ، تحتاج إلى البرمجة" ، التي تحدد في رأيي المبدأ العام للتدريب على تكنولوجيا المعلومات.
حتى في هذا القسم ، قدم رومان سيماكوف من شركة "RED SOFT"
عرضًا تقديميًا "ميزات تدريب مبرمجي النظام في المدن الصغيرة". كان بقية المتحدثين في هذا القسم من موسكو ، كما خمنت على الأرجح.
ذكرني التقرير عن المشاكل المذكورة كثيرًا (وليس أنا فقط)
بتقرير "أخطاء في إشراف الدولة على التعليم العالي - المشكلة الرئيسية للتعليم العالي في روسيا" من مؤتمر OSEDUCONF-2018 الذي وصفته في
المركزقارن:
مأخوذة من الصفحة مع ملخصات
التقرير الحالي
1) عند تخصيص أموال الميزانية للتخصص في إحدى الجامعات ، ضع في الاعتبار عدد الخريجين العاملين في هذا التخصص. إذا لم يكن المتخصصون في الطلب ، فلا معنى لتمويل أماكن الميزانية. نعم يعمل الخريجون ويدفعون الضرائب ولكن يكسبون شيئًا آخر! عند تسجيل موظف ، يمكن لصاحب العمل أن يشير إلى تخصصه وجامعته ، والآن أصبح من السهل تجميع كل هذا.
2) تغيير الأساس التجاري للتعليم. تحتاج إلى الدفع ليس للتحضير ، ولكن لنتيجة ذلك. يمكن لشركات تكنولوجيا المعلومات طلب تدريب متخصص والدفع وفقًا للنتائج. على وجه التقريب ، يحضر المتخصصون في الشركة الاختبارات والتقييم لأنفسهم و "يوقعون على شهادة القبول" لنتائج التدريب.
مأخوذ من
مراجعتي لتقرير
حبريفي هذا التقرير ، أوجز المؤلف مشاكل عدم كفاءة التعليم الحالي. والسبب المحتمل لذلك هو البيروقراطية. حول مشكلة البيروقراطية لن أنشر الكثير. كل من مرتبط بالعملية التعليمية بطريقة أو بأخرى واجهها. وأعرب المؤلف عن رأي مفاده أن المشكلة الرئيسية للتعليم هي أن العملية هي التي تسيطر عليها ، وليس النتيجة. أي ، تفرض متطلبات رسمية على الجامعة ، ويتم التحقق منها. القيمة الحقيقية للتعليم هي الطلب على خريجيها.
في كلتا الحالتين ، الفكرة الرئيسية هي أنه يجب على الجامعة تدريب المتخصصين الناجحين في صناعتها ، وعدم الإبلاغ عن عدد الأماكن. عندما قيل لمؤلف التقرير أن هذه الأفكار ليست جديدة ، فقد أساء إليه وقال إنها أصلية. لا أحد يشك في ذلك ، ولكن حقيقة أن كلا التقريرين تم تقديمهما من قبل مدن صغيرة (موروم وبيريسلافل زاليسكي) تشير إلى أن مشاكل توزيع أموال الميزانية للتعليم خطيرة للغاية ، وهي واضحة بشكل خاص في المدن الصغيرة.
بالنسبة للسؤال من عنوان المقال ، اقترحت على مؤلفه ألا يفكر في ما يحتاج المبرمجون إلى تدريسه ، ولكن لتطوير صناعة تكنولوجيا المعلومات نفسها. من الواضح أنه إذا لم يجد المتخصص طلبًا لمعرفته ومهاراته ، فسيذهب إلى حيث سيكونون في الطلب. إنها الصناعة التي تشكل متطلبات المتخصصين ، وليس الجامعات أو الدولة. لقد دعمني متحدث من ISP RAS ، قال إنه يجب أن يكون هناك "ثالوث": التعليم والعلوم والصناعة. بدون أي من هذه المكونات ، تبدأ الأجزاء الأخرى في الترهل.
بالإضافة إلى ذلك ، أشير إلى مقالتي "من أين أحصل على مبرمج" والتي حاولت فيها تقديم منهجي لتحسين التعليم في مجال تكنولوجيا المعلومات.
الملخص
باختصار ، أود أن أشير إلى أن المؤتمر مثير للاهتمام في المقام الأول لتنوع آرائه ، وبطبيعة الحال ، جودة التقارير.
لم أذكر القسم الكامل حول الأمن والعديد من التقارير الأخرى ، ليس على الرغم من ذلك ، لقد تحدثت للتو عما كان مثيرًا للاهتمام بشكل خاص لي شخصيًا. ويمكن قراءة التقرير الرسمي هنا .يمكن مشاهدة فيديو لجميع التقارير من المؤتمر ، وليس فقط تلك المذكورة في المقالة هنا . لا يزال هناك الكثير من الأشياء المثيرة للاهتمام.