在五月底，
Embox已经按照
惯例参加了
OSDay 。 与去年一样，会议在RAS主楼举行。 这次，它致力于可靠性。 软件可靠性的主题是古老的。 例如，
弗雷德里克·布鲁克斯 （
Frederick Brooks）在他的传奇作品《
神话人月》 （
Mythical Man-Month）中就受到了影响，会议本身也多次提及该作品。 该书提到在创建
OS / 360操作系统的过程中遇到的问题之一是缺少足够数量的合格程序员。 出于同样的原因，可能在会议上有很多时间专门用于系统编程领域的教育。 总的来说，我对会议上表达和讨论的有趣观点感兴趣的人，我要求猫。
会议开幕时，其创始人之一Dmitry
Zavalishin dzavalishin表达了以下几点：
- 现代软件系统是如此复杂，以至于它们中的任何一个都需要可靠性，而不仅仅是以前的“特殊软件”
- 不同的人可能对软件可靠性有不同的想法，例如，有些人认为可靠性是安全性的代名词。
- 至少基于可靠性概念不同的假设，确保可靠性的方法可以有所不同
在第一天，ISP RAS从学术角度提出了有关软件可靠性的
报告 。 尽管它更可能是对历史的致敬，但从中可以清楚地看出问题远非新问题，可靠性的定义以及评估方法也多种多样。 该报告虽然被严格削减（因为发言人试图保持在30分钟之内），但它的科学性却很有趣。
仪器方法
确保代码可靠性的方法可以分为几类。 我将从会议主持人ISP RAS闻名的工具开始。 他的员工介绍了有关使用klever工具验证Linux内核的经验的
报告 。
Klever是用于静态代码验证的开放框架。 实际上，报告作者解决的问题可以表述如下。 静态代码验证太复杂，无法整体检查现代项目，但是您可以尝试选择一些或多或少的隔离部分，例如Linux内核子系统或单独的驱动程序，并在为其设置适当的环境后进行验证。 然后，您可以尝试对整个项目进行迭代处理。
建筑方法
构建更可靠的系统的另一种方法是使用“建筑”技术。 对他们来说，我将包括
Phantom OS的持久内存和
MILS （安全性/安全性的多个独立级别）的体系结构的想法。
关于MILS
的报告涉及其属性，以增强关键系统的安全性，并已提交给卡巴斯基实验室。 关于持久存储条件下的垃圾收集器
的报告不仅由OS Phantom的作者提出，而且由Innopolis大学的一名学生提出。 自然，使用管理语言来提高系统可靠性的想法并不新鲜。 在我看来，在报告中，学生参与一个开源项目以创建系统软件非常重要。
有条不紊的方法
我认为，就报告数量而言，数量最多但被低估的提高软件可靠性的方法是“方法上的”。 如果您考虑一下，将操作系统作为一个单独的实体进行分离的目的在于提高软件的可靠性。 程序员有机会重用系统服务，而不必再次开发它们。
FSUE GosNIIAS提交了有关开发关键软件的方法
的报告 。 该报告致力于标准
DO-178C （俄语版本的CT-178C）的开发。 与标准本身一样，该报告具有很多“乏味”，但毕竟，当您制造飞机时，您无法摆脱一些迷人的想法，因此需要进行大量检查，然后才能进行最细微的更改。 通常，测量一次，切七次，哦，当然，相反。 自然，该报告不是因为它的“乏味”而有趣，而是因为开发了使该过程自动化的工具，即 减少“乏味”。
开源的
最后，我转到Embox发言的部分。 我们的
报告的标题是“基于开放源代码项目的RTOS 3d加速支持组织”。 其中，很大一部分用于解释，在这里是可靠性。 甚至还有一张幻灯片，如“可靠性和硬件3d加速”。 可靠性当然不是3d加速，而是“基于开源项目”一词。 最重要的是，我们能够使用开源项目添加对封闭式vivante 3d加速器的支持。 而且，尽管我们使用的
Mesa项目与Linux内核接口紧密相关，但与从头开始开发相比，适应所需的工作量少得多，所包含的代码行也少得多。
正如我已经指出的，开源是会议报告以某种方式联系在一起的最多类别。 例如，玄武岩SPO提交了有关clsync文件同步工具开发的
报告 。 我不会讨论技术细节，另一件事很重要。 正如公司的名称所示，该
工具是开源的 ，并且在报告之后有一些技巧，例如，使用
futex ，发言人建议加入
futex并独立进行改进。
我认为，在开源方面最有趣的是Positive Technologies员工Alexander Popov的
报告 。
该报告的标题为“ STACKLEAK如何提高Linux内核安全性”，似乎它应该专门研究STACKLEAK的故事以及它的用途。 但是，报告的主要时间专门用于该主题，在注释和报告的短语中表示：
“亚历山大从事这项工作已经一年了。 他将与Linux内核开发社区分享他的经验 。
” 也就是说，在这一年中，推动了有益的变化，涉及到许多人，并且由在原子核不同子系统工作的合格专家在显微镜下检查了变化。 当然，这不能保证完全没有错误，但是可以减少错误的数量，因此可以提高代码的可靠性。
替代方法
在会议上，就像
去年一样，
提出了有关QP OS的报告。 在该报告的摘要中，您可以看到以下内容：“安全操作系统QP OS是完全由国内开发的，由科技企业“ Cryptosoft”的团队从头开始创建。 该报告还提出了从头开始的开发原则，不仅包括操作系统，系统管理程序，网络堆栈，还包括所有子系统和用户应用程序以及编译器，C＃虚拟机以及据我所知的所有其他开发工具。 我想向发言者提问，可靠性又如何呢，因为每千行代码的错误数比率尚未取消。 我得到的答案是，可靠性可以理解为不同的事物，并且如果给定的操作系统在两次重新启动之间下降的次数越来越少，则认为该可靠性是可靠的。 在报告发布后，我建议在场外进行一个开放项目，为
samba提供更完整的支持。 但是他得到了一个答案，那就是独立发展一切都是原则上的立场，并解释说这种方法具有生命权。 好吧，我称它为替代方法。
应当指出的是，会议上有一个展览，并展示了一个可以现场试用QP OS的展台。 我和他们的编辑一起玩，效果很好。 在展位上，他们确认他们甚至没有借用库的代码来使用xml。 另外，也许“从头开始”的类似方法来自开发人员的工作范围。 这个领域的特点是过分的安全性，掉下来比在某个地方添加书签要好。 没错，这并不能证明拒绝使用开源代码。
硬实时
在本节中，我不得不提及另一份报告，至少是因为发言人提到了我的演讲，因此我有权这样做。 演讲结束后，有人问我3d加速器的支持是否不会干扰提供实时特性，总的来说，我们的项目是否是硬实时操作系统？ 由于会议时间有限，我回避地回答了最后一个问题，而实时意味着什么需要一个相当认真的解释。 提到的发言者在我之后就他的Eremex FX-RTOS RTOS的
报告发表了讲话，并说与我们的项目不同，他们的OS是一个硬实时系统。 演讲者认为，实时性不强的迹象是缺少循环，且迭代次数不固定且中断受阻。
由于代码已关闭，因此我不敢判断FX-RTOS RTOS中是否存在带有阻塞中断的潜在无限循环，但是，我当然同意，即使在普通OS中，这样的循环也是不可接受的，更不用说RTOS了！
此外，在报告中，据称开发人员设法完全避免阻塞（屏蔽）中断，尽管仅在arm cortex-m上有效，但这仍然是一项了不起的成就，据发言人说，这也表明了实时性。 此外，扬声器在基于FX-RTOS的设备上停止了很长时间，该设备通过UART接口应答了几毫秒，这再次表明了实时性。
我不知道我们中的哪个人对“实时”的概念有另一种方法，我只是表达自己的观点。 我将回答Embox是否是实时系统的问题。
实时的概念与在任何（内部和外部）因素的影响下系统行为的可预测性直接相关。 由此将实时概念与可靠性概念联系起来。 因此，windows作为通用操作系统是不可靠的，并且实时操作系统（如基于其构建的系统）是可靠的。
反应时间参数是最重要的可预测性因素之一，但在实时系统中，反应速度的变化并不重要，而是反应速率重要，因此应严格限制。 我遇到了一个定义，其中软实时被定义为一个系统的平均响应值较小，而硬系统的最大值则较小。 而且由于现代处理器的速度已大大提高，执行时间（平均时间）不再扮演这个角色，因为要提高响应速度，就足以放置功能更强大的处理器。 但是不可能摆脱算法和体系结构的影响，也就是说，以其
诚实的调度程序为目标的最大CPU负载的Linux不能被视为实时系统。 尽管我可以确定UART的响应时间可以做得很小，但它不是稳定的，因为调度程序可能会决定需要向处理器加载其他任务，并且响应时间会意外地增加。 因此，我们可以制定以下实时操作系统的特征：这些操作系统可以为所有系统（包括内部系统）提供最佳控制。 以
ARINC-653为例，它对带有静态调度程序的调度程序有要求。 在这些操作系统中，开发人员可以访问计划表，在系统开发时需要填写这些表。 也就是说，开发人员在总体规划期间为每个部分分配时间（时隙），所有中断均被禁用（计时器除外，当然，仅对调度程序可用），并且开发人员必须制定一个时间表，以使每个部分都有足够的时间来解决其问题。 同时，计划程序无权以某种方式更改此计划。
如果您考虑使用其他什么操作系统来提供对“内脏对象”的完全或扩展访问，则很容易得出结论，小型OS的现代项目有一个引以为傲的名称RTOS（实时操作系统）。 由于他们提供了这种访问权限，因此开发人员已经负责确保基于RTOS构建的最终系统满足所有要求，包括对任何影响的可预测性！
至于Embox，我们还为所有服务（包括内核）提供控制机制。 从这个角度来看，Embox是一个实时操作系统。 是的，具有MILS架构的系统是基于Embox制作的（我不自觉地将其称为ARINC-653，因为ARINC-653由符合标准的证书确定），但是您还可以构建另一种架构，以保证反应具有足够的可预测性。 例如，一位客户在示波器上检查了响应时间，该时间精确到几个处理器周期，并且受到非常严格的限制。 没错，在活动应用程序中，没有加载系统，只有服务器在旋转，这对事件做出了反应。 但是客户对此结果感到非常满意。 因此，我们认为，只有在整个系统的应用程序中谈论实时性，开发人员才能对此负责，而硬实时操作系统仅提供实现这种实时性的机制。 我们的分类更加准确，我们编写了
»Embox-嵌入式开发必不可少的工具箱“ 。
干部决定一切
标题中有一个奇怪的短语：“您需要教给学生什么，以便他们立即开始在俄罗斯IT公司工作并留在那里” –这实际上是在小组讨论中提出的一个问题。 会议的四分之一专门讨论了IT领域的培训和教育问题。 在认识到问题的重要性以及矛盾之处的同时，组织者非常有意思地解决了这个问题。 根据组织者的设想，发表了四份报告，发言人代表了竞争的方式。 因此，
VMK MSU教职员工以同一个名称“计算机体系结构和汇编语言”发布了两份课程报告。 一份报告是
乔治·库里亚奇 （
George Kuryachiy ）提出的，另一份报告是
Vartan Padaryan 。 实际上，这些方法是相似的，在一个课程中研究MIPS汇编程序而在另一课程中研究x86无关紧要。 在这两种情况下，教师都试图在实际领域中发展课程。 在继续讨论培训的实际组成部分的重要性这一主题时
， Aleksey Khoroshilov
发表了
一份报告 “设计操作系统的内核”。 我们可以说，本课程扩大了对计算机体系结构的理解，使学生可以更深入地研究操作系统的核心。 结果，不是竞争方法，而是VMK的教师采用了系统的方法，即课程不竞争，而是相互补充和发展。 实际上，应该是这样。 这句话还听起来像是：“要学习编程，您需要编程”，在我看来，它定义了IT培训的一般原则。
即使在本节中，“ RED SOFT”公司的Roman Simakov也做了“小城镇系统程序员培训的特点”的
演讲 。 正如您可能猜到的，本节中的其他发言人来自莫斯科。
关于所列问题的报告使我（不仅是我）非常想起（我不仅如此），我在
枢纽上描述的OSEDUCONF-2018会议上的
报告 “国家高等教育监督中的错误-俄罗斯高等教育的主要问题”
比较：
摘自带有当前
报告摘要的页面
1）在大学中为某专业分配预算资金时，请考虑从事该专业的毕业生人数。 如果对专家的需求不大，那么为预算额度提供资金是没有意义的。 是的 毕业生可以工作，缴税，但还能赚其他钱！ 在注册员工时，雇主可以表明他的专业和大学，现在所有这些都非常容易汇总。
2）改变教育的商业基础。 您无需为准备工作而付费，而是为结果付费。 IT公司可以订购专家培训，并根据结果付费。 粗略地说，公司的专家参加考试，自己评估并“签署”培训结果的接受证书。
摘自我对
哈布雷的报告的评论
在这份报告中，作者概述了当前教育效率低下的问题。 可能的原因是官僚主义。 关于官僚主义的问题，我不会传播太多。 与教育过程相关的每个人都以一种或另一种方式面对它。 作者认为教育的主要问题是过程是受控的，而不是结果。 也就是说，对大学施加了正式要求，并对其进行了验证。 教育的真正价值在于对毕业生的需求。
在这两种情况下，主要思想是大学应培训其行业中成功的专家，而不是报告名额。 当报告的作者被告知这些想法不是新想法时，他被冒犯了，并说它们是原始的。 谁都对此表示怀疑，但两个报告都是由小城市（穆隆和佩雷斯拉夫尔-扎列斯基）提出的，这表明教育预算资金分配的问题相当严重，在小城市尤为明显。
至于文章标题中的问题，我建议作者不要考虑需要教给程序员什么，而应该发展IT业本身。 显然，如果专家找不到适合他的知识和技能的应用程序，他会去他们所需要的地方。 对专家形成需求的是行业，而不是大学或国家。 我得到了ISP RAS的一位发言者的支持，他说应该有一个“三位一体”：教育，科学，工业。 没有这些组件中的任何一个，其他部分就会开始下垂。
另外，我引用了我的
文章 “从哪里可以找到程序员”，在
那篇文章中我试图提供改善IT教育的方法。
总结
总结一下，我想指出的是，这次会议之所以有趣，主要是因为它的观点多种多样，当然还有报告的质量。
我没有提到整个安全性部分，也没有提到其他许多报告，尽管如此，我只是谈到了个人觉得特别有趣的部分。官方报告可以在这里阅读。可以在此处查看会议所有报告的视频，而不仅仅是文章中提到的那些视频。仍然有很多有趣的事情。