Ein bisschen über OSDAY oder Was Sie brauchen, um Studenten beizubringen, in russischen IT-Unternehmen zu arbeiten und dort zu bleiben

Ende Mai nahm Embox bereits traditionell am OSDay teil . Die Konferenz fand wie letztes Jahr im Hauptgebäude des RAS statt. Dieses Mal war es der Zuverlässigkeit gewidmet. Das Thema Software-Zuverlässigkeit ist alt. Es wird zum Beispiel von Frederick Brooks in seiner legendären Arbeit Mythical Man-Month beeinflusst , auf die auch auf der Konferenz selbst mehrfach Bezug genommen wurde. In dem Buch wird erwähnt, dass eines der Probleme bei der Erstellung des Betriebssystems OS / 360 das Fehlen einer ausreichenden Anzahl qualifizierter Programmierer war. Wahrscheinlich wurde aus dem gleichen Grund viel Zeit auf der Konferenz der Ausbildung im Bereich der Systemprogrammierung gewidmet. Im Allgemeinen, wer daran interessiert ist, welche meiner Meinung nach auf der Konferenz interessanten Ideen zum Ausdruck gebracht und diskutiert wurden, bitte ich um Katze.

Bei der Eröffnung der Konferenz äußerte einer ihrer Gründer, Dmitry Zavalishin dzavalishin , mehrere Punkte:

• Moderne Softwaresysteme sind so komplex, dass für jedes von ihnen Zuverlässigkeit erforderlich ist, und nicht nur für „spezielle“ wie zuvor
• Unterschiedliche Personen haben möglicherweise unterschiedliche Vorstellungen von der Zuverlässigkeit von Software. Einige Personen betrachten Zuverlässigkeit beispielsweise als Synonym für Sicherheit.
• Die Methoden zur Gewährleistung der Zuverlässigkeit können unterschiedlich sein, zumindest unter der Annahme, dass sich die Zuverlässigkeitskonzepte unterscheiden

Am ersten Tag präsentierte ISP RAS einen Bericht über die Zuverlässigkeit von Software aus akademischer Sicht. Und obwohl es eher eine Hommage an die Geschichte war, wurde daraus klar, dass das Problem alles andere als neu war und die Definitionen der Zuverlässigkeit sowie die Methoden zu ihrer Bewertung sehr unterschiedlich waren. Der Bericht war, obwohl er stark gekürzt wurde (da der Redner versuchte, ihn innerhalb von 30 Minuten zu halten), wegen seiner wissenschaftlichen Natur interessant.

Instrumentelle Methoden

Methoden zur Gewährleistung der Zuverlässigkeit des Codes können in mehrere Kategorien unterteilt werden. Ich beginne mit den Tools, für die der Moderator der Konferenz, ISP RAS, berühmt ist. Sein Mitarbeiter präsentierte einen Bericht über die Erfahrungen bei der Überprüfung von Teilen des Linux-Kernels mit dem Klever-Tool. Klever ist ein offenes Framework für die Überprüfung statischen Codes. Tatsächlich kann das Problem, das der Autor des Berichts gelöst hat, wie folgt formuliert werden. Die Überprüfung des statischen Codes ist zu kompliziert, um moderne Projekte als Ganzes zu überprüfen. Sie können jedoch versuchen, einen mehr oder weniger isolierten Teil auszuwählen, z. B. das Linux-Kernel-Subsystem oder einen separaten Treiber, und ihn nach dem Festlegen der entsprechenden Umgebung überprüfen. Dann können Sie dies iterativ mit dem gesamten Projekt versuchen.

Architektonische Methoden

Ein weiterer Ansatz zum Aufbau zuverlässigerer Systeme ist die Verwendung „architektonischer“ Techniken. Zu ihnen würde ich die Idee des dauerhaften Speichers des Phantom-Betriebssystems und der Architektur von MILS (Multiple Independent Levels of Security / Safety) einschließen .

Der Bericht über MILS befasste sich mit seinen Eigenschaften zur Verbesserung der Sicherheit kritischer Systeme und wurde Kaspersky Lab vorgelegt. Der Bericht über den Garbage Collector unter den Bedingungen eines dauerhaften Gedächtnisses wurde nicht nur vom Autor von OS Phantom, sondern auch von einem Studenten der Innopolis University vorgelegt. Natürlich ist die Idee, Verwaltungssprachen zur Erhöhung der Systemzuverlässigkeit zu verwenden, nicht neu. In dem Bericht war meiner Meinung nach die Beteiligung der Studenten an einem Open-Source-Projekt zur Erstellung von Systemsoftware wichtig.

Methodischer Ansatz

Der in Bezug auf die Anzahl der Berichte am zahlreichsten, aber meiner Meinung nach unterschätzte Ansatz zur Verbesserung der Zuverlässigkeit von Software ist meiner Meinung nach „methodisch“. Wenn Sie darüber nachdenken, zielte die Trennung des Betriebssystems als separate Einheit darauf ab, die Zuverlässigkeit der Software zu verbessern. Der Programmierer hatte die Möglichkeit, Systemdienste wiederzuverwenden und nicht erneut zu entwickeln.

Ein Bericht über die Methodik zur Entwicklung kritischer Software wurde von FSUE GosNIIAS vorgelegt. Der Bericht war der Entwicklung des Standards DO-178C (CT-178C in der russischen Version) gewidmet. Wie im Standard selbst war der Bericht sehr "langweilig", aber wenn Sie ein Flugzeug bauen, können Sie einige bezaubernde Ideen nicht loswerden. Sie müssen einige Male nachsehen, bevor Sie die geringste Änderung vornehmen. Im Allgemeinen einmal messen, siebenmal schneiden, im Gegenteil natürlich. Natürlich war der Bericht nicht wegen seiner „Langeweile“ interessant, sondern wegen der Tatsache, dass Werkzeuge entwickelt wurden, um diesen Prozess zu automatisieren, d. H. "Langeweile" zu reduzieren.

Open Source

Schließlich wende ich mich dem Abschnitt zu, in dem Embox gesprochen hat. Unser Bericht hatte den Titel „Organisation der Unterstützung für die 3D-Beschleunigung in RTOS basierend auf Open Source-Projekten“. Darin war ein ziemlich großer Teil der Erklärung und hier der Zuverlässigkeit gewidmet. Es gab sogar eine Folie wie "Zuverlässigkeit und Hardware-3D-Beschleunigung". Zuverlässigkeit liegt natürlich nicht in der 3D-Beschleunigung, sondern in der Formulierung „basierend auf Open Source-Projekten“. Das Fazit ist, dass wir mithilfe von Open-Source-Projekten Unterstützung für den geschlossenen vivante 3d-Beschleuniger hinzufügen konnten. Und obwohl das von uns verwendete Mesa- Projekt stark an die Linux-Kernel-Oberfläche gebunden ist, erfordert die Anpassung viel weniger Aufwand und enthält weitaus weniger Codezeilen als die Entwicklung von Grund auf neu.

Wie ich bereits bemerkt habe, ist Open Source die zahlreichste Kategorie, mit der die Berichte auf der Konferenz irgendwie verbunden waren. Zum Beispiel präsentierte Basalt SPO einen Bericht über die Entwicklung des Clsync-Dateisynchronisationstools. Ich werde nicht auf technische Details eingehen, eine andere Sache ist wichtig. Wie im Namen des Unternehmens angegeben, handelt es sich bei dem Tool um Open Source . Nach dem Bericht folgten einige Tipps, z. B. zur Verwendung von Futex , zu denen der Redner vorschlug, dem Projekt beizutreten und es unabhängig zu verbessern.

In Bezug auf Open Source war meiner Meinung nach der Bericht des Mitarbeiters von Positive Technologies, Alexander Popov, am interessantesten.

Der Bericht trug den Titel „Wie STACKLEAK die Sicherheit des Linux-Kernels verbessert“ und schien der STACKLEAK-Geschichte und dem, womit sie gegessen wurde, gewidmet zu sein. Die Hauptzeit des Berichts war jedoch dem Thema gewidmet, das sich in dem Satz aus der Anmerkung zum Bericht ausdrückt: „Alexander führt diese Arbeit seit einem Jahr durch. Er wird seine Erfahrungen mit der Linux-Kernel-Entwickler-Community teilen . “ Das heißt, im Laufe des Jahres werden nützliche Änderungen vorangetrieben, viele Menschen sind beteiligt, Änderungen werden unter einem Mikroskop von qualifizierten Spezialisten untersucht, die in verschiedenen Teilsystemen des Kerns arbeiten. Dies garantiert natürlich nicht die vollständige Abwesenheit von Fehlern, sondern reduziert deren Anzahl und erhöht daher die Zuverlässigkeit des Codes.

Alternativer Ansatz

Auf der Konferenz wurde wie im letzten Jahr ein Bericht über QP OS vorgestellt. In der Zusammenfassung des Berichts sehen Sie Folgendes: „Das sichere Betriebssystem QP OS ist eine vollständig inländische Entwicklung, die vom Team des wissenschaftlichen und technischen Unternehmens„ Cryptosoft “„ von Grund auf neu “erstellt wurde. In dem Bericht wurde auch das Prinzip der Entwicklung von Grund auf geäußert, nicht nur des Betriebssystems, des Hypervisors, des Netzwerkstapels, sondern auch aller Subsysteme und Benutzeranwendungen sowie des Compilers, der virtuellen C # -Maschine und, wie ich es verstehe, aller anderen Entwicklungstools. Auf meine Frage an den Sprecher, was ist mit Zuverlässigkeit, weil das Verhältnis der Anzahl der Fehler pro tausend Codezeilen nicht aufgehoben wurde. Ich habe die Antwort erhalten, dass Zuverlässigkeit als verschiedene Dinge verstanden werden kann und dass sie für ein bestimmtes Betriebssystem als zuverlässig angesehen wird, wenn sie zwischen zwei Neustarts immer weniger abfällt. Bereits nach dem Bericht am Rande habe ich empfohlen, ein offenes Projekt durchzuführen, um Samba umfassender zu unterstützen . Aber er erhielt die Antwort, dass es eine prinzipielle Position ist, alles unabhängig zu entwickeln, mit der Erklärung, dass ein solcher Ansatz das Recht auf Leben hat. Nun, ich nannte es einen alternativen Ansatz.

Es sei darauf hingewiesen, dass es auf der Konferenz eine Ausstellung gab und ein Stand präsentiert wurde, an dem das QP OS live ausprobiert werden konnte. Ich habe mit ihrem Editor herumgespielt, es hat ganz gut funktioniert. Am Stand bestätigten sie, dass sie nicht einmal den Code der Bibliotheken für die Arbeit mit XML ausgeliehen hatten. Ein ähnlicher Ansatz „alles von Grund auf neu“ ergibt sich möglicherweise aus dem Umfang, in dem Entwickler arbeiten. Diese Sphäre zeichnet sich durch ihre übermäßige Sicherheit aus, es ist besser zu fallen als irgendwo ein Lesezeichen zu setzen. Dies rechtfertigt jedoch nicht die Ablehnung der Verwendung von Open Source Code.

Harte Echtzeit

In diesem Abschnitt kann ich nur auf einen anderen Bericht verweisen, zumindest weil der Redner auf meine Präsentation verwiesen hat, daher bin ich berechtigt, dasselbe zu tun. Nach meiner Rede wurde ich gefragt, ob die Unterstützung des 3D-Beschleunigers die Bereitstellung von Echtzeitmerkmalen nicht beeinträchtigt. Ist unser Projekt im Allgemeinen ein hartes Echtzeitbetriebssystem? Ich habe die letzte Frage ausweichend beantwortet, da die Zeit auf der Konferenz begrenzt ist und die Frage, was unter Echtzeit zu verstehen ist, eine ziemlich ernsthafte Erklärung erfordert. Der erwähnte Redner sprach direkt nach mir mit einem Bericht über sein Eremex FX-RTOS RTOS und erklärte, dass sein Betriebssystem im Gegensatz zu unserem Projekt ein hartes Echtzeitsystem ist. Ein Zeichen für harte Echtzeit ist laut Sprecher das Fehlen von Zyklen mit einer variablen Anzahl von Iterationen mit blockierten Unterbrechungen.

Ich wage es nicht zu beurteilen, ob es im FX-RTOS-RTOS möglicherweise Endlosschleifen mit blockierten Interrupts gibt oder nicht, da der Code geschlossen ist, aber ich stimme natürlich zu, dass solche Zyklen selbst in normalen Betriebssystemen nicht akzeptabel sind, ganz zu schweigen von RTOS!

Darüber hinaus wurde während des Berichts festgestellt, dass es den Entwicklern gelungen ist, Blockierungs- (Maskierungs-) Interrupts vollständig zu vermeiden, allerdings nur auf Armcortex-m, aber dennoch ist dies eine großartige Leistung, die laut Sprecher auch Echtzeit anzeigt. Außerdem blieb der Lautsprecher auf einem auf FX-RTOS basierenden Gerät lange Zeit stehen, das mehrere Millisekunden lang über die UART-Schnittstelle antwortete, was wiederum auf eine harte Echtzeit hinweist.

Ich weiß nicht, wer von uns einen alternativen Ansatz zum Konzept der "Echtzeit" hat, ich werde nur meinen Standpunkt zum Ausdruck bringen. Und ich beantworte nur die Frage, ob Embox ein Echtzeitsystem ist.

Das Konzept der Echtzeit steht in direktem Zusammenhang mit der Vorhersagbarkeit des Verhaltens des Systems unter dem Einfluss von (sowohl internen als auch externen) Faktoren. Daraus folgt die Verbindung des Echtzeitbegriffs mit dem Zuverlässigkeitsbegriff. Daher ist die Vorstellung, dass Windows als universelles Betriebssystem unzuverlässig ist und das Echtzeitbetriebssystem (wie das darauf aufgebaute System) zuverlässig ist.

Die Reaktionszeitparameter sind einer der wichtigsten Vorhersagbarkeitsfaktoren, aber in Echtzeitsystemen ist weniger die Reaktionsgeschwindigkeit als vielmehr die Variation der Reaktionszeit wichtig und sollte streng begrenzt werden. Ich bin auf eine Definition gestoßen, bei der weiche Echtzeit als ein System mit einem kleinen durchschnittlichen Antwortwert des Systems und hart definiert wurde - mit einem kleinen Maximum. Und da die Geschwindigkeit moderner Prozessoren stark zugenommen hat, spielt die Ausführungszeit (Durchschnitt) diese Rolle nicht mehr, da es ausreicht, einen leistungsstärkeren Prozessor einzusetzen, um die Reaktionsgeschwindigkeit zu erhöhen. Es ist jedoch nicht möglich, den Einfluss von Algorithmen und Architekturen zu beseitigen , dh Linux mit seinem ehrlichen Scheduler , der auf maximale CPU-Auslastung abzielt, kann nicht als Echtzeitsystem betrachtet werden. Obwohl ich sicher bin, dass die Reaktionszeit gemäß UART recht klein gemacht werden kann, wird sie nicht stabil sein, da der Scheduler möglicherweise entscheidet, dass er den Prozessor mit einer anderen Aufgabe laden muss, und die Antwortzeit sich unvorhersehbar erhöht. Daher können wir die folgenden Merkmale von Echtzeitbetriebssystemen formulieren: Dies sind Betriebssysteme, die die beste Steuerung für alle ihre Systeme bieten, einschließlich der internen. Nehmen wir zum Beispiel ARINC-653 mit seiner Anforderung in Bezug auf einen Scheduler mit einem statischen Zeitplan. In diesen Betriebssystemen hat der Entwickler Zugriff auf Planungstabellen, die er zum Zeitpunkt der Systementwicklung ausfüllt. Das heißt, der Entwickler weist jedem Abschnitt im allgemeinen Planungszeitraum Zeit (Zeitfenster) zu, alle Interrupts sind deaktiviert (mit Ausnahme des Timers, der natürlich nur dem Planer zur Verfügung steht), und der Entwickler muss einen solchen Zeitplan erstellen, dass jeder Abschnitt genügend Zeit hat, um sein Problem zu lösen. Gleichzeitig hat der Planer kein Recht, diesen Zeitplan irgendwie zu ändern.

Wenn Sie darüber nachdenken, welche anderen Betriebssysteme einen vollständigen oder erweiterten Zugriff auf Ihre „Innereien“ bieten, können Sie leicht zu dem Schluss kommen, dass moderne Projekte kleiner Betriebssysteme den stolzen Namen RTOS (Echtzeitbetriebssystem) haben. Da sie diesen Zugriff bieten und der Entwickler bereits dafür verantwortlich ist, dass das auf RTOS basierende endgültige System alle Anforderungen erfüllt, einschließlich der Vorhersehbarkeit der Reaktion auf Auswirkungen!

In Bezug auf Embox bieten wir auch Kontrollmechanismen für alle Dienste, einschließlich des Kernels. Unter diesem Gesichtspunkt ist Embox ein Echtzeitbetriebssystem. Ja, Systeme mit der MILS-Architektur wurden auf der Basis von Embox erstellt (ich nenne es nicht bewusst ARINC-653, da ARINC-653 durch das Zertifikat für die Einhaltung des Standards bestimmt wird), aber Sie können auch eine andere Architektur erstellen, die eine ausreichende Vorhersagbarkeit der Reaktion garantiert. Ein Kunde überprüfte beispielsweise die Reaktionszeit auf einem Oszilloskop, die Zeit war auf mehrere Prozessorzyklen genau und sehr eng begrenzt. Richtig, das System wurde nicht geladen, von den aktiven Anwendungen drehte sich nur der Server, der auf das Ereignis reagierte. Der Kunde war jedoch sehr zufrieden mit dem Ergebnis. Wir glauben daher, dass es nur möglich ist, über Echtzeit in der Anwendung auf das gesamte System zu sprechen, und der Entwickler ist dafür verantwortlich, und das harte Echtzeitbetriebssystem bietet nur Mechanismen, um diese sehr Echtzeit zu erreichen. Wir sind genauer in unserer Klassifizierung und haben »Embox - Essential Toolbox for Embedded Development" geschrieben .

Kader entscheiden alles

Der seltsame Satz im Titel „Was brauchen Sie, um Studenten zu unterrichten, damit sie sofort in russischen IT-Unternehmen arbeiten und dort bleiben“ - das ist eigentlich eine Frage, die in einer Podiumsdiskussion aufgeworfen wurde. Ein Viertel der Konferenz war dem Problem der Aus- und Weiterbildung im Bereich IT gewidmet. Die Organisatoren verstanden die Bedeutung und gleichzeitig die Inkonsistenz des Problems und gingen das Thema sehr interessant an. Es wurden vier Berichte geliefert, die von den Organisatoren konzipiert wurden. Die Redner repräsentierten wettbewerbsorientierte Ansätze. Also zwei Berichte über den gleichnamigen Kurs "Computerarchitektur und Assemblersprache" an der Fakultät der VMK MSU . Ein Bericht wurde von George Kuryachiy gemacht , der andere - Vartan Padaryan . Tatsächlich waren die Ansätze ähnlich, und es spielt keine Rolle, dass der MIPS-Assembler in einem Kurs und der x86 in dem anderen Kurs untersucht wurden. In beiden Fällen versuchten die Lehrer, den Kurs im praktischen Bereich weiterzuentwickeln. In Fortsetzung des Themas über die Bedeutung der praktischen Komponente des Trainings wurde ein Bericht von Aleksey Khoroshilov „Entwerfen des Kernels des Betriebssystems“ vorgestellt. Wir können sagen, dass dieser Kurs das Verständnis der Computerarchitektur erweitert und es den Studenten ermöglicht, tiefer in den Kern des Betriebssystems einzutauchen. Infolgedessen stellte sich heraus, dass die Fakultät des VMK anstelle konkurrierender Ansätze einen systematischen Ansatz verfolgt, dh die Kurse konkurrieren nicht, sondern ergänzen und entwickeln sich gegenseitig. Eigentlich sollte es so sein. Der Satz klang auch so: „Um das Programmieren zu lernen, muss man programmieren“, was meiner Meinung nach das allgemeine Prinzip der IT-Ausbildung definiert.

Auch in diesem Bereich hielt Roman Simakov von der Firma „RED SOFT“ eine Präsentation „Merkmale der Ausbildung von Systemprogrammierern in Kleinstädten“. Der Rest der Redner in diesem Abschnitt stammte aus Moskau, wie Sie wahrscheinlich vermutet haben.

Der Bericht über die aufgeführten Probleme erinnerte mich sehr (und nicht nur mich) an den Bericht „Fehler in der staatlichen Aufsicht über die Hochschulbildung - das Hauptproblem der Hochschulbildung in Russland“ aus der von mir am Hub beschriebenen OSEDUCONF-2018-Konferenz

Vergleichen Sie:
entnommen aus der Seite mit Abstracts des aktuellen Berichts

1) Berücksichtigen Sie bei der Zuweisung von Haushaltsmitteln für ein Fachgebiet an einer Universität die Anzahl der Absolventen, die in diesem Fachgebiet arbeiten. Wenn Spezialisten nicht gefragt sind, macht es keinen Sinn, Budgetplätze zu finanzieren. Ja Absolventen arbeiten, zahlen Steuern, verdienen aber etwas anderes! Bei der Registrierung eines Arbeitnehmers könnte ein Arbeitgeber sein Fachgebiet und seine Universität angeben, und jetzt ist dies alles sehr einfach zu aggregieren.
2) Ändern Sie die kommerzielle Basis der Bildung. Sie müssen nicht für die Vorbereitung bezahlen, sondern für das Ergebnis. IT-Unternehmen könnten Fachschulungen bestellen und entsprechend den Ergebnissen bezahlen. , « » .

. . , .. , , . , , , . , . .

, , . , , , , . , , ( -), , , .

, , , IT-. , , , . , . , , “”: , , . .

“ ” IT.

Zusammenfassung

, , , , . , , , . .

, . .