A little about OSDAY or what you need to teach students to start working in Russian IT-companies and stay there

In late May, Embox , traditionally, took part in OSDay . The conference, like last year, was held in the main building of the Russian Academy of Sciences. This time it was dedicated to reliability. The topic of software reliability is old. It is touched upon, for example, by Frederick Brooks in his legendary work “The Mythical Man-Month” , which was referred to several times at the conference itself. The book mentions that one of the problems encountered in the process of creating the OS / 360 operating system, there was a lack of a sufficient number of qualified programmers. Probably for the same reason, a lot of time at the conference was devoted to education in the field of system programming. In general, who cares, what, in my opinion, interesting ideas were expressed and discussed at the conference, please under the cat.

Opening the conference, one of its founders, Dmitry Zavalishin dzavalishin , expressed several theses:

• Modern software systems are so complex that reliability is required for any of them, and not just for the “special ones”, as it was before.
• Perceptions about the reliability of software for different people may vary, for example, some consider reliability as a synonym for security.
• Methods to ensure reliability can be different, based on at least the fact that different ideas about reliability

On the first day, ISP RAS presented a report on software reliability from an academic point of view. And although this was more likely a tribute to history, it was clear from him that the problem was far from new, and the definitions of reliability, like the methods for its assessment, are very diverse. The report, although it was badly cut (as the speaker tried to keep within 30 minutes), was interesting with her scientific background.

Instrumental methods

Methods to ensure the reliability of the code can be divided into several categories. I will start with the tools that the host of the conference is famous for - ISP RAS. His collaborator presented a report on the experience of verifying pieces of the Linux kernel using the klever tool. Klever is an open framework for static code verification. Actually, the problem that the author of the report solved can be formulated as follows. Static code verification is too complex to check modern projects entirely, but you can try to isolate some more or less isolated part, for example, the Linux kernel subsystem or a separate driver, and, by setting the appropriate environment, verify it. Then you can try to do this iteratively with the whole project.

Architectural methods

Another approach to building more reliable systems is to use “architectural” techniques. To them, I would refer to the idea of ​​persistent OS memory Phantom and the architecture of Multiple Independent Levels of Security / MILS .

The MILS report dealt with its properties on enhancing the security of critical systems and was presented to Kaspersky Lab. The report about the garbage collector in the conditions of persistent memory was presented not only by the author of OS Phantom, but also by a student of the Innopolis University. Naturally, the idea of ​​using manage-languages ​​to increase system reliability is not new. And in the report, in my opinion, it was important to involve students in an open source project on creating system software.

Methodical approach

The most numerous in terms of the number of reports, but an underestimated approach to improving software reliability, in my opinion, is “methodical”. If you think about it, the separation of the operating system into a separate entity was aimed at improving the reliability of the software. The programmer was able to reuse system services, rather than developing them all over again.

A report on the development of critical software was presented by the Federal State Unitary Enterprise GosNIIAS. The report was devoted to the development of the standard DO-178С(CT-178S in the Russian version). As in the standard itself, the report had a lot of “tediousness”, but when you make the plane, you can't do some fabulous ideas, you need to check a bunch of times before making the slightest change. In general, measure once, cut seven times, oh, on the contrary, of course. Naturally, the report was interesting not because of its “tediousness”, but because it developed tools for automating this process, i.e. to reduce “tediousness”.

Open source

Finally, I turn to the section in which Embox spoke. Our report was called “The Organization of 3d Acceleration Support in RTOS Based on Open Source Projects”. In it, quite a large part was devoted to an explanation, and here reliability. There was even a slide like “Reliability and hardware 3d acceleration”. Reliability, of course, is not in 3d-acceleration, but in the phrase “based on open source projects”. The bottom line is that we were able to add support for the vivante gated 3d accelerator to us using open source projects. And although the Mesa project we use is strongly tied to the Linux kernel interface, adaptation requires much less effort and contains far fewer lines of code than developing from scratch.

As I have already noted, open-source is the most numerous category with which reports at the conference were somehow connected. For example, Basalt SPO presented a report on the development of the clsync file synchronization tool. I will not go into the technical details, the other is important. As indicated in the company's name, the SPO tool is shaky , and after the report several tips followed, for example, to use futex , for which the speaker suggested joining the project and improving it on his own.

The most interesting in terms of opensource, in my opinion, was the report by Positive Technologies employee Alexander Popov.

The report was called: “How STACKLEAK improves the security of the Linux kernel” and it seemed that it should have been dedicated to the story about STACKLEAK and what it was eaten with. But the main time of the report was given to the topic, which is expressed in the phrase from the annotation to the report: “Alexander has been doing this work for a year now. He will share his experiences of interacting with the Linux kernel development community . ” That is, useful changes are pushed through the year, many people are involved, the changes are examined under a microscope by qualified specialists working in different subsystems of the core. Of course, this does not guarantee the complete absence of errors, but reduces their number, and therefore increases the reliability of the code.

Alternative approach

At the conference, like last year , a report was presented.dedicated to QP OS. In the theses of the report you can see the following: “The protected operating system QP OS is entirely domestic development, created from scratch by the team of the scientific and technical enterprise Kryptosoft.” The report also voiced the principle of developing from scratch, not only operating system, hypervisor, network stack, but also all subsystems and user applications, as well as the compiler, the C # virtual machine, and, as I understand it, all other development tools. To my question to the speaker, what about reliability? After all, nobody canceled the error rate per thousand lines of code. I received the answer that reliability can be understood as different things, and that for a given operating system it is considered reliable if it falls less and less between two restarts. Already after the report, on the sidelines,the samba . But I received the answer that this is a principled position, to develop everything independently, with an explanation that such an approach has the right to life. Well, I called it an alternative approach.

Here it should be noted that there was an exhibition at the conference, and a stand was presented at which QP OS could be tried live. I played with their editor, he worked fine. At the stand they confirmed that they did not even borrow the code of the libraries for working with xml. In addition, it is possible that a similar approach “all from scratch” comes from the scope of work in which the developers work. This sphere is characterized by its excessive security, it is better to let it fall, than somewhere there will be a tab. True, this does not justify the rejection of the use of open source.

Hard real time

In this section I cannot but refer to another report, at least because the speaker referred to my presentation, therefore I have the right to do the same. After my presentation, I was asked if the support of the 3d accelerator does not interfere with the provision of real-time characteristics, and in general, is our project an OS of hard real-time? I answered the last question evasively, since the time at the conference is limited, and the question of what is meant by real time requires quite a serious explanation. The mentioned speaker spoke immediately after me with a report.about their RTOS Eremex FX-RTOS and stated that unlike our project, their OS is a hard real-time system. A sign of hard real-time, according to the speaker, is the absence of cycles with a variable number of iterations with interrupts blocked.

I cannot judge whether there are potentially infinite loops with blocked interrupts in the FX-RTOS RTOS or not, since the code is closed, but, of course, I agree that such cycles are unacceptable even in ordinary OSs, not to mention the RTOS!

In addition, during the report it was stated that the developers managed to completely avoid blocking (masking) interrupts, though only on arm cortex-m, but still this is a great achievement, which, according to the speaker, also indicates real time. In addition, the speaker stayed long enough on a device based on FX-RTOS, which responded to the UART interface for a few milliseconds, which again indicates a hard real time.

I do not know which of us has an alternative approach to the concept of “real time”, I will simply express my point of view. And just to answer the question whether Embox is a real-time system.

The concept of real time is directly related to the predictability of the behavior of the system when exposed to any (both internal and external) factors. From this follows the connection between the concept of real time and the concept of reliability. Hence the idea that windows, as a universal OS, is unreliable, and the real-time operating system (like the system built on it) is reliable.

The temporal parameters of the reaction are one of the most important factors of predictability, but in real-time systems it is not so much the reaction rate that is important as the spread of the reaction time, and it should be strictly limited. I met the definition of where the soft real time was defined as a system with a small average response value of the system, and a hard real time with a small maximum. And since the speed of modern processors has greatly increased, the time (average) of performance no longer plays that role, because to increase the reaction rate, it is enough to install a more powerful processor. But it is impossible to get rid of the influence of algorithms and architecture, that is, Linux with its honest scheduler, aimed at maximum CPU usage, can not be considered a real-time system. Although I am sure that the reaction time for the UART can be made fairly small, but it will not be stable, because the scheduler may decide that it is necessary to load the processor with some other task, and the response time will unpredictably increase. Therefore, we can formulate the following characteristic of real-time operating systems: these are operating systems that provide better control for all of their systems, including internal ones. Take, for example, ARINC-653with its requirement in terms of a scheduler with a static schedule. In these operating systems, the planning tables are available to the developer, which he fills in at the time of developing the system. That is, the developer allocates time (time slots) in the general planning period for each section, all interruptions are disabled (except for the timer, of course, available only to the scheduler), and the developer must make such a schedule so that each section has enough time to solve its task. In this case, the scheduler has no right to somehow change this schedule.

If you think about what other operating systems provide full or extended access to their “giblets”, it is easy to come to the conclusion that modern projects of small OS do not in vain have the proud name RTOS (real-time operating system). Since they provide this access, the developer is already responsible for ensuring that the final system built on the basis of RTOS meets all requirements, including the predictability of reaction to any impact!

As for Embox, we also provide mechanisms for controlling all services, including the kernel. And from this point of view, Embox is a real-time operating system. Yes, on the basis of Embox, systems with a MILS architecture were made (deliberately not calling it ARINC-653, since ARINC-653 is determined by a certificate of compliance with the standard), but you can also build another architecture that guarantees sufficient predictability of the reaction. One customer, for example, checked the response time on an oscilloscope, the time was accurate to several processor cycles and was limited very tightly. True, the system was not loaded, from active applications only the server was spinning, which responded to the event. But the customer was very pleased with the result. Therefore, we believe that talking about real time can only be applied to the system as a whole, and the developer is responsible for this, and the hard real-time operating system only provides mechanisms for achieving this very real time. We are more careful in our classification and we have writtenEmbox - Essential toolbox for embedded development " .

Frames decide everything

The strange phrase in the title “What do we need to teach students to start working in Russian IT companies right away and stay there” is actually a question that was raised at the panel discussion. The problem of training and education in the field of IT was devoted to a quarter of the conference. Understanding the importance and at the same time inconsistency of the problem, the organizers came up with a very interesting question. Four reports were presented. According to the organizers, the speakers represented competitive approaches. Thus, two reports on the course with the same name "Computer Architecture and Assembly Language" at the faculty of the VMK of Moscow State University . One report was given by George Kuryachy , the other by Vartan Padaryan. Actually, the approaches were similar, and it does not matter that in one course the MIPS assembler was studied, and in the other course x86. In both cases, the teachers sought to develop the course in the practical field. In continuation of the topic about the importance of the practical component of the training report was presentedAlexei Khoroshilova "Designing the kernel of the operating system." This course can be said to expand the concept of computer architecture and allows students to dive deeper into the core of the operating system. As a result, instead of competing approaches, it turned out that there is a systematic approach at the Faculty of the ISC, that is, the courses do not compete, but complement and develop each other. Actually, it should be so. There was also a phrase: “To learn how to program, you need to program”, which, in my opinion, defines the general principle of education in IT.

Roman Simakov from the RED SOFT company also spoke in this section with the report “Features of training system programmers in small towns”. The other speakers in this section were from Moscow, as you probably guessed.

The report on these issues very much (and not only me) reminded me of the report “Errors in the state supervision of higher education is the main problem of higher education in Russia” from the conference OSEDUCONF-2018 I described in Habré .

Compare:
taken from the page with the abstracts of the current report.

1) When distributing budget funds for a specialty in a university, take into account the number of graduates working in this specialty. If the specialists are not in demand, then there is no point in financing the budget places. Yes. Graduates work, pay taxes, but earn something else! When registering an employee, an employer could indicate his specialty and university, and now it is all very easy to aggregate.
2) Change the commercial basis of education. You need to pay not for training, but for its result. IT companies could order training of specialists and pay according to the results. Roughly speaking, the company's specialists are present at the exams, evaluate for themselves and “sign the act of acceptance” of the training results.

It is taken from my review of the report on Habré

In this report, the author outlined the problems of the ineffectiveness of current education. A possible reason for this is bureaucratization. I will not spread much about the problem of bureaucratization, since everyone involved in the educational process somehow came across it. The author expressed the opinion that the main problem of education is that the process is controlled, and not the result. That is, the university imposes formal requirements on the process, and they are checked. The real value of education is the demand for its graduates.

In both cases, the main idea is that the university must prepare successful specialists in its field, and not to report on the number of places. When the author of the report was told that these ideas were not new, he was offended and said that they were original. No one doubts this, but the fact that both reports were submitted by small cities (Murom and Pereslavl-Zalessky) suggests that the problems with the distribution of budget money for education are serious enough, and especially manifest in small cities.

As for the question from the title of the article, I suggested to the author not to think about what programmers should be taught, but to develop the IT industry itself. It is clear that if a specialist does not find use for his knowledge and skills, he will go where they will be in demand. It is industry that forms the requirement for specialists, not universities and the state. I was supported by a speaker from ISP RAS, who said that there should be a “triunity”: education, science, industry. Other parts begin to subside without any of these components.

In addition, I refer to my article “Where to get a programmer” in which I tried to offer my approach to improving education in IT.

Results

Summing up, I want to note that the conference is interesting primarily for its diversity of opinions and, of course, the quality of reports. I did not mention the whole section on security and many other reports, not out of malice, I just said that it was of particular interest to me personally. And the official report can be read here .

Video of all reports from the conference, and not just those mentioned in the article can be viewed here . There are still many interesting things.