Fin mai,
Embox , déjà traditionnellement, a participé à
OSDay . La conférence, comme l'année dernière, s'est tenue dans le bâtiment principal du RAS. Cette fois, il était dédié à la fiabilité. Le sujet de la fiabilité des logiciels est ancien. Il est affecté, par exemple, par
Frederick Brooks dans son œuvre légendaire
«Le mois de l'homme mythique» , qui a été mentionnée plusieurs fois dans la conférence elle-même. Le livre mentionne que l'un des problèmes rencontrés dans le processus de création du
système d' exploitation
OS / 360 était le manque d'un nombre suffisant de programmeurs qualifiés. Probablement, pour la même raison, beaucoup de temps à la conférence a été consacré à l'éducation dans le domaine de la programmation système. En général, qui s'intéresse à ce qui, à mon avis, des idées intéressantes ont été exprimées et discutées lors de la conférence, je demande chat.
En ouvrant la conférence, l'un de ses fondateurs, Dmitry Zavalishin
dzavalishin , a exprimé plusieurs points:
- Les systèmes logiciels modernes sont si complexes que la fiabilité est requise pour chacun d'entre eux, et pas seulement pour les «spéciaux», comme c'était le cas auparavant
- Différentes personnes peuvent avoir des idées différentes sur la fiabilité des logiciels, par exemple, certaines personnes considèrent la fiabilité comme synonyme de sécurité.
- Les méthodes permettant de garantir la fiabilité peuvent être différentes, du moins en supposant que les concepts de fiabilité diffèrent
Le premier jour, l'ISP RAS a présenté un
rapport sur la fiabilité des logiciels d'un point de vue académique. Et bien qu'il s'agisse plus probablement d'un hommage à l'histoire, il est clair que le problème est loin d'être nouveau et que les définitions de la fiabilité, ainsi que les méthodes d'évaluation, sont très diverses. Le rapport, bien qu'il ait été sévèrement coupé (comme l'orateur a essayé de le garder dans les 30 minutes), était intéressant pour sa nature scientifique.
Méthodes instrumentales
Les méthodes permettant de garantir la fiabilité du code peuvent être divisées en plusieurs catégories. Je vais commencer par les outils pour lesquels l'hôte de la conférence, ISP RAS, est célèbre. Son employé a présenté un
rapport sur l'expérience de vérification de morceaux du noyau Linux à l'aide de l'outil klever.
Klever est un framework ouvert pour la vérification de code statique. En fait, le problème résolu par l'auteur du rapport peut être formulé comme suit. La vérification du code statique est trop compliquée pour vérifier les projets modernes dans leur ensemble, mais vous pouvez essayer d'isoler une partie plus ou moins isolée, par exemple, le sous-système du noyau Linux ou un pilote distinct, et, après avoir défini l'environnement approprié pour cela, vérifiez-le. Ensuite, vous pouvez essayer de le faire de manière itérative avec l'ensemble du projet.
Méthodes architecturales
Une autre approche pour construire des systèmes plus fiables est l'utilisation de techniques «architecturales». Pour eux, j'inclurais l'idée d'une mémoire persistante du
système d'exploitation Phantom et de l'architecture de
MILS (Multiple Independent Levels of Security / Safety).
Le rapport sur MILS traitait de ses propriétés pour améliorer la sécurité des systèmes critiques et a été soumis à Kaspersky Lab.
Le rapport sur le ramasse-miettes dans des conditions de mémoire persistante a été présenté non seulement par l'auteur d'OS Phantom, mais aussi par un étudiant de l'Université Innopolis. Naturellement, l'idée d'utiliser des langages de gestion pour augmenter la fiabilité du système n'est pas nouvelle. Et dans le rapport, à mon avis, l'implication des étudiants dans un projet open source pour créer un logiciel système était importante.
Approche méthodique
L'approche la plus nombreuse en termes de nombre de rapports, mais sous-estimée pour améliorer la fiabilité des logiciels, est à mon avis «méthodique». Si vous y réfléchissez, la séparation du système d'exploitation en tant qu'entité distincte visait à améliorer la fiabilité du logiciel. Le programmeur a eu l'occasion de réutiliser les services du système, et non de les développer à nouveau.
Un rapport sur la méthodologie de développement de logiciels critiques a été présenté par FSUE GosNIIAS. Le rapport était consacré à l'élaboration de la norme
DO-178C (CT-178C dans la version russe). Comme dans la norme elle-même, le rapport était très «fastidieux», mais après tout, lorsque vous faites un avion, vous ne pouvez pas vous débarrasser de certaines idées enchanteresses, vous devez vérifier plusieurs fois avant de faire le moindre changement. En général, mesurez une fois, coupez sept fois, au contraire, bien sûr. Naturellement, le rapport était intéressant non pas pour sa «fastidieuse», mais pour le fait que des outils ont été développés pour automatiser ce processus, c'est-à-dire pour réduire «l'ennui».
Open source
Enfin, je passe à la section dans laquelle Embox a parlé. Notre
rapport était intitulé «Organisation du support de l'accélération 3D dans RTOS basé sur des projets open source». Dans ce document, une partie assez importante était consacrée à l'explication, et ici à la fiabilité. Il y avait même une diapositive comme «Fiabilité et accélération 3D matérielle». La fiabilité, bien sûr, n'est pas dans l'accélération 3D, mais dans la phrase «basée sur des projets open source». L'essentiel, c'est que nous avons pu ajouter la prise en charge de l'accélérateur fermé vivante 3d à l'aide de projets open source. Et bien que le projet
Mesa que nous utilisons soit fortement lié à l'interface du noyau Linux, l'adaptation nécessite beaucoup moins d'efforts et contient beaucoup moins de lignes de code que le développement à partir de zéro.
Comme je l'ai déjà noté, l'open source est la catégorie la plus nombreuse avec laquelle les rapports de la conférence étaient en quelque sorte liés. Par exemple, Basalt SPO a présenté un
rapport sur le développement de l'outil de synchronisation de fichiers clsync. Je n'entrerai pas dans les détails techniques, une autre chose est importante. Comme indiqué au nom de l'entreprise, l'
outil est open source , et après le rapport, quelques conseils ont suivi, par exemple, pour utiliser
futex , auquel l'orateur a suggéré de rejoindre le projet et de l'améliorer de manière indépendante.
Le plus intéressant en termes d'open source, à mon avis, était le
rapport de Alexander Popov, employé de Positive Technologies.
Le rapport était intitulé «Comment STACKLEAK améliore la sécurité du noyau Linux» et il semblait qu'il aurait dû être consacré à l'histoire de STACKLEAK et à ce avec quoi il a été mangé. Mais le temps principal du rapport était consacré au sujet, qui est exprimé dans la phrase de l'annotation au rapport:
«Alexander mène ce travail depuis un an. Il partagera ses expériences avec la communauté de développement du noyau Linux .
» Autrement dit, au cours de l'année, des changements utiles sont poussés, de nombreuses personnes sont impliquées, les changements sont examinés au microscope par des spécialistes qualifiés travaillant dans différents sous-systèmes du noyau. Bien sûr, cela ne garantit pas l'absence totale d'erreurs, mais réduit leur nombre, et donc augmente la fiabilité du code.
Approche alternative
Lors de la conférence, tout comme
l'année dernière , un
rapport sur QP OS a été présenté. Dans le résumé du rapport, vous pouvez voir ce qui suit: «Le système d'exploitation sécurisé QP OS est un développement entièrement national, créé« à partir de zéro »par l'équipe de l'entreprise scientifique et technique« Cryptosoft ». Le rapport a également exprimé le principe du développement à partir de zéro, non seulement du système d'exploitation, de l'hyperviseur, de la pile réseau, mais aussi de tous les sous-systèmes et applications utilisateur, ainsi que le compilateur, la machine virtuelle C # et, si je comprends bien, tous les autres outils de développement. À ma question à l'orateur, qu'en est-il de la fiabilité, car le rapport du nombre d'erreurs pour mille lignes de code n'a pas été annulé. J'ai obtenu la réponse que la fiabilité peut être comprise comme différentes choses, et qu'elle est considérée comme fiable pour un système d'exploitation donné si elle tombe de moins en moins entre deux redémarrages. Déjà après le rapport, en marge, j'ai conseillé de prendre un projet ouvert pour fournir un support plus complet pour la
samba . Mais il a reçu une réponse selon laquelle c'est une position de principe de tout développer de manière indépendante, avec l'explication qu'une telle approche a droit à la vie. Eh bien, je l'ai appelé une approche alternative.
Il convient de noter qu'il y avait une exposition lors de la conférence, et un stand a été présenté au cours duquel le QP OS pourrait être testé en direct. J'ai joué avec leur éditeur, ça a plutôt bien fonctionné. Sur le stand, ils ont confirmé qu'ils n'avaient même pas emprunté le code des bibliothèques pour travailler avec xml. De plus, peut-être une approche similaire «tout à partir de zéro» vient de la portée dans laquelle les développeurs travaillent. Cette sphère se caractérise par sa sécurité excessive, il vaut mieux tomber que de marquer quelque part. Certes, cela ne justifie pas de refuser d'utiliser le code open source.
Difficile en temps réel
Dans cette section, je ne peux que faire référence à un autre rapport, du moins parce que l'orateur a fait référence à ma présentation, j'ai donc le droit de faire de même. Après mon discours, on m'a demandé si le support de l'accélérateur 3D n'interfère pas avec la fourniture de caractéristiques en temps réel, et en général, notre projet est-il un OS dur en temps réel? J'ai répondu évasivement à la dernière question, car le temps de la conférence est limité, et la question de savoir ce que l'on entend par temps réel nécessite une explication assez sérieuse. L'orateur mentionné a parlé juste après moi avec un
rapport sur son Eremex FX-RTOS RTOS et a déclaré que, contrairement à notre projet, leur système d'exploitation est un système difficile en temps réel. Un signe de temps réel difficile, selon l'orateur, est l'absence de cycles avec un nombre variable d'itérations avec des interruptions bloquées.
Je n'ose pas juger s'il existe des boucles potentiellement infinies avec des interruptions bloquées dans le FX-RTOS RTOS ou non, car le code est fermé, mais, bien sûr, je conviens que de tels cycles sont inacceptables même dans les systèmes d'exploitation ordinaires, sans parler de RTOS!
En outre, lors du rapport, il a été déclaré que les développeurs avaient réussi à éviter complètement les interruptions bloquantes (masquantes), mais uniquement sur le bras cortex-m, mais il s'agit tout de même d'une grande réussite qui, selon l'orateur, indique également en temps réel. En outre, le haut-parleur s'est arrêté pendant longtemps sur un appareil basé sur FX-RTOS, qui a répondu via l'interface UART pendant plusieurs millisecondes, ce qui indique à nouveau un temps réel difficile.
Je ne sais pas lequel de nous a une approche alternative au concept de «temps réel», je vais simplement exprimer mon point de vue. Et je répondrai simplement à la question de savoir si Embox est un système en temps réel.
Le concept de temps réel est directement lié à la prévisibilité du comportement du système sous l'influence de tous les facteurs (internes et externes). Il s'ensuit la connexion du concept de temps réel avec le concept de fiabilité. D'où l'idée que Windows, en tant que système d'exploitation universel, n'est pas fiable et que le système d'exploitation en temps réel (comme le système qui en est issu) est fiable.
Les paramètres du temps de réaction sont l'un des facteurs de prévisibilité les plus importants, mais dans les systèmes en temps réel, ce n'est pas tant la vitesse de réaction qui est importante que la variation du temps de réaction, et elle doit être strictement limitée. Je suis tombé sur une définition où le temps réel doux était défini comme un système avec une petite valeur de réponse moyenne du système, et difficile - avec un petit maximum. Et comme la vitesse des processeurs modernes a fortement augmenté, le temps (moyen) d'exécution ne joue plus ce rôle, car pour augmenter la vitesse de réaction il suffit de mettre un processeur plus puissant. Mais il n'est pas possible de se débarrasser de l'influence des algorithmes et de l'architecture, c'est-à-dire que Linux avec son
ordonnanceur honnête , visant à une charge CPU maximale, ne peut pas être considéré comme un système en temps réel. Bien que je suis sûr que le temps de réaction selon UART peut être assez petit, il ne sera pas stable, car le planificateur peut décider qu'il doit charger le processeur avec une autre tâche, et le temps de réponse augmentera de manière imprévisible. Par conséquent, nous pouvons formuler la caractéristique suivante des systèmes d'exploitation en temps réel: ce sont des systèmes d'exploitation qui fournissent le meilleur contrôle pour tous leurs systèmes, y compris les systèmes internes. Prenons, par exemple,
ARINC-653 avec son exigence en termes de planificateur avec un calendrier statique. Dans ces systèmes d'exploitation, le développeur a accès aux tables de planification, qu'il remplit au moment du développement du système. C'est-à-dire que le développeur alloue du temps (plages horaires) dans la période de planification générale pour chaque section, toutes les interruptions sont désactivées (à l'exception du minuteur, bien sûr, uniquement disponible pour le planificateur), et le développeur doit prévoir un tel calendrier que chaque section dispose de suffisamment de temps pour résoudre son problème. Dans le même temps, le planificateur n'a pas le droit de modifier en quelque sorte ce calendrier.
Si vous pensez à quels autres systèmes d'exploitation offrent un accès complet ou étendu à vos «abats», il est facile de conclure que les projets modernes de petits systèmes d'exploitation portent le nom de RTOS (système d'exploitation en temps réel). Puisqu'ils fournissent cet accès, et le développeur est déjà responsable de s'assurer que le système final construit sur la base de RTOS répond à toutes les exigences, y compris la prévisibilité de la réaction à tout impact!
Quant à Embox, nous fournissons également des mécanismes de contrôle pour tous les services, y compris le noyau. Et de ce point de vue, Embox est un système d'exploitation en temps réel. Oui, les systèmes avec l'architecture MILS ont été fabriqués sur la base d'Embox (je ne l'appelle pas consciemment ARINC-653, car ARINC-653 est déterminé par le certificat de conformité à la norme), mais vous pouvez également construire une autre architecture qui garantirait une prévisibilité suffisante de la réaction. Un client, par exemple, a vérifié le temps de réponse sur un oscilloscope, le temps était précis pour plusieurs cycles de processeur et était très étroitement limité. Certes, le système n'était pas chargé, des applications actives, seul le serveur tournait, ce qui a réagi à l'événement. Mais le client était très satisfait du résultat. Par conséquent, nous pensons qu'il est uniquement possible de parler de temps réel dans l'application au système dans son ensemble, et le développeur est responsable de cela, et le système d'exploitation en temps réel dur ne fournit que des mécanismes pour atteindre ce temps très réel. Nous sommes plus précis dans notre classement et nous avons écrit
»Embox - Boîte à outils essentielle pour le développement embarqué" .
Les cadres décident de tout
L'expression étrange du titre «De quoi avez-vous besoin pour enseigner aux étudiants afin qu'ils commencent immédiatement à travailler dans des sociétés informatiques russes et y restent» - c'est en fait une question qui a été soulevée lors d'une table ronde. Un quart de la conférence a été consacrée au problème de la formation et de l'éducation dans le domaine des TI. Comprenant l'importance et en même temps l'incohérence du problème, les organisateurs ont abordé la question de manière très intéressante. Quatre rapports ont été livrés, tels que conçus par les organisateurs, les intervenants représentaient des approches compétitives. Donc, deux reportages sur le cours du même nom "Architecture informatique et langage d'assemblage" à la faculté du
VMK MSU . Un rapport a été fait par
George Kuryachiy , l'autre -
Vartan Padaryan . En fait, les approches étaient similaires et peu importe que l'assembleur MIPS ait été étudié dans un cours et x86 dans l'autre. Dans les deux cas, les enseignants ont cherché à développer le cours dans le domaine pratique. Dans la continuité du sujet sur l'importance de la composante pratique de la formation, un
rapport d' Aleksey Khoroshilov «Conception du noyau du système d'exploitation» a été présenté. Ce cours, nous pouvons dire, élargit la compréhension de l'architecture informatique et permet aux étudiants de plonger plus profondément dans le cœur du système d'exploitation. En conséquence, au lieu d'approches concurrentes, il s'est avéré que la faculté du VMK a une approche systématique, c'est-à-dire que les cours ne se font pas concurrence, mais se complètent et se développent mutuellement. En fait, il devrait en être ainsi. La phrase sonnait également: «Pour apprendre à programmer, il faut programmer», ce qui, à mon avis, définit le principe général de la formation en informatique.
Même dans cette section, Roman Simakov de la société «RED SOFT» a fait une
présentation «Caractéristiques de la formation des programmeurs système dans les petites villes». Les autres orateurs de cette section venaient de Moscou, comme vous l'avez probablement deviné.
Le rapport sur les problèmes énumérés m'a beaucoup rappelé (et pas seulement moi) le
rapport «Erreurs dans la supervision publique de l'enseignement supérieur - le principal problème de l'enseignement supérieur en Russie» de la conférence OSEDUCONF-2018 que j'ai décrit sur le
hubComparez:
extrait de la page avec les résumés du
rapport actuel
1) Lorsque vous allouez des fonds budgétaires pour une spécialité dans une université, tenez compte du nombre de diplômés travaillant dans cette spécialité. Si les spécialistes ne sont pas en demande, cela n'a aucun sens de financer des places budgétaires. Oui Les diplômés travaillent, paient des impôts, mais gagnent autre chose! Lors de l'inscription d'un employé, un employeur peut indiquer sa spécialité et son université, et maintenant tout cela est très facile à agréger.
2) Changer la base commerciale de l'éducation. Vous devez payer non pas pour la préparation, mais pour son résultat. Les sociétés informatiques pourraient commander une formation spécialisée et payer en fonction des résultats. En gros, les spécialistes de l'entreprise assistent aux examens, évaluent par eux-mêmes et «signent le certificat d'acceptation» des résultats de la formation.
Il est tiré de mon examen du rapport sur
HabréDans ce rapport, l'auteur a souligné les problèmes de l'inefficacité de l'éducation actuelle. Une raison possible à cela est la bureaucratie. Concernant le problème de la bureaucratisation, je ne me répandrai pas beaucoup. tous ceux qui sont liés au processus éducatif, d'une manière ou d'une autre, y sont confrontés. L'auteur a exprimé l'avis que le principal problème de l'éducation est que le processus est contrôlé et non le résultat. Autrement dit, des exigences formelles sont imposées à l'université et elles sont vérifiées. La valeur réelle de l'éducation est la demande de ses diplômés.
Dans les deux cas, l'idée principale est que l'université devrait former des spécialistes performants dans son industrie et ne pas rendre compte du nombre de places. Lorsque l'auteur du rapport a appris que ces idées n'étaient pas nouvelles, il a été offensé et a déclaré qu'elles étaient originales. Personne n'en doute, mais le fait que les deux rapports ont été présentés par de petites villes (Murom et Pereslavl-Zalessky) suggère que les problèmes de répartition des crédits budgétaires pour l'éducation sont assez graves et sont particulièrement évidents dans les petites villes.
Quant à la question du titre de l'article, j'ai suggéré à son auteur de ne pas penser à ce que les programmeurs doivent apprendre, mais de développer l'industrie informatique elle-même. Il est clair que si un spécialiste ne trouve pas d'application pour ses connaissances et ses compétences, il ira là où elles seront demandées. C'est l'industrie qui fait le besoin de spécialistes, et non les universités ou l'État. J'ai été soutenu par un intervenant de l'ISP RAS, qui a dit qu'il devrait y avoir une «trinité»: l'éducation, la science, l'industrie. Sans aucun de ces composants, d'autres parties commencent à s'affaisser.
De plus, je me réfère à mon
article «Où trouver un programmeur» dans lequel j'ai essayé de proposer mon approche pour améliorer l'enseignement en informatique.
Résumé
Pour résumer, je tiens à noter que la conférence est intéressante principalement pour sa diversité d'opinions et, bien sûr, la qualité des rapports. , , , .
.
,
. .