A finales de mayo,
Embox , ya tradicionalmente, participó en
OSDay . La conferencia, como el año pasado, se celebró en el edificio principal del RAS. Esta vez se dedicó a la fiabilidad. El tema de la confiabilidad del software es antiguo. Se ve afectado, por ejemplo, por
Frederick Brooks en su legendario trabajo
"The Mythical Man-Month" , al que se hizo referencia varias veces en la conferencia misma. El libro menciona que uno de los problemas encontrados en el proceso de creación del
sistema operativo
OS / 360 fue la falta de un número suficiente de programadores calificados. Probablemente, por la misma razón, mucho tiempo en la conferencia se dedicó a la educación en el campo de la programación de sistemas. En general, a quién le interesa qué, en mi opinión, se expresaron y discutieron ideas interesantes en la conferencia, pido un gato.
Al abrir la conferencia, uno de sus fundadores, Dmitry Zavalishin
dzavalishin , expresó varios puntos:
- Los sistemas de software modernos son tan complejos que se requiere confiabilidad para cualquiera de ellos, y no solo para los "especiales", como era antes
- Diferentes personas pueden tener diferentes ideas sobre la confiabilidad del software, por ejemplo, algunas personas consideran la confiabilidad como un sinónimo de seguridad.
- Los métodos para garantizar la confiabilidad pueden ser diferentes, basados al menos en el supuesto de que los conceptos de confiabilidad difieren
El primer día, ISP RAS presentó un
informe sobre la confiabilidad del software desde un punto de vista académico. Y aunque era más probable que fuera un tributo a la historia, quedó claro que el problema estaba lejos de ser nuevo, y las definiciones de confiabilidad, así como los métodos para evaluarlo, eran muy diversos. El informe, aunque fue severamente cortado (como el orador trató de mantenerlo en 30 minutos), fue interesante por su naturaleza científica.
Métodos instrumentales
Los métodos para garantizar la fiabilidad del código se pueden dividir en varias categorías. Comenzaré con las herramientas por las que el anfitrión de la conferencia, ISP RAS, es famoso. Su empleado presentó un
informe sobre la experiencia de verificar piezas del kernel de Linux utilizando la herramienta klever.
Klever es un marco abierto para la verificación de código estático. En realidad, el problema que resolvió el autor del informe puede formularse de la siguiente manera. La verificación de código estático es demasiado complicada para verificar proyectos modernos en su conjunto, pero puede intentar seleccionar una parte más o menos aislada, por ejemplo, el subsistema del kernel de Linux o un controlador separado y, después de configurar el entorno adecuado para ello, verificarlo. Luego puede intentar hacerlo de forma iterativa con todo el proyecto.
Métodos arquitectónicos
Otro enfoque para construir sistemas más confiables es el uso de técnicas "arquitectónicas". Para ellos, incluiría la idea de la memoria persistente del
sistema operativo Phantom y la arquitectura de
MILS (múltiples niveles independientes de seguridad).
Informe sobre MILS tocó sus propiedades para mejorar la seguridad de los sistemas críticos y se presentó a Kaspersky Lab.
El informe sobre el recolector de basura en condiciones de memoria persistente fue presentado no solo por el autor de OS Phantom, sino también por un estudiante de la Universidad de Innopolis. Naturalmente, la idea de usar lenguajes de administración para aumentar la confiabilidad del sistema no es nueva. Y en el informe, en mi opinión, la participación de los estudiantes en un proyecto de código abierto para crear software de sistema fue importante.
Enfoque metódico
El enfoque más numeroso en cuanto a la cantidad de informes, pero subestimado para mejorar la confiabilidad del software, en mi opinión, es "metódico". Si lo piensa, la separación del sistema operativo como una entidad separada tenía como objetivo mejorar la confiabilidad del software. El programador tuvo la oportunidad de reutilizar los servicios del sistema y no volver a desarrollarlos.
FSUE GosNIIAS presentó
un informe sobre la metodología para desarrollar software crítico. El informe se dedicó al desarrollo del estándar
DO-178C (CT-178C en la versión rusa). Al igual que en el estándar en sí, el informe tenía mucha "tedio", pero después de todo, cuando haces un avión, no puedes deshacerte de algunas ideas encantadoras, debes revisar muchas veces antes de hacer el más mínimo cambio. En general, mida una vez, corte siete veces, oh, por el contrario, por supuesto. Naturalmente, el informe fue interesante no por su "tedio", sino por el hecho de que se desarrollaron herramientas para automatizar este proceso, es decir. para reducir el "tedio".
Código abierto
Finalmente, paso a la sección en la que habló Embox. Nuestro
informe se tituló "Organización de soporte para aceleración 3D en RTOS basado en proyectos de código abierto". En él, una parte bastante grande se dedicó a la explicación, y aquí a la fiabilidad. Incluso hubo una diapositiva como "Fiabilidad y aceleración 3d de hardware". La fiabilidad, por supuesto, no está en la aceleración 3d, sino en la frase "basada en proyectos de código abierto". La conclusión es que pudimos agregar soporte para el acelerador 3D vivante cerrado usando proyectos de código abierto. Y aunque el proyecto
Mesa que utilizamos está fuertemente vinculado a la interfaz del kernel de Linux, la adaptación requiere mucho menos esfuerzo y contiene muchas menos líneas de código que el desarrollo desde cero.
Como ya he señalado, el código abierto es la categoría más numerosa con la que los informes en la conferencia estaban de alguna manera conectados. Por ejemplo, Basalt SPO presentó un
informe sobre el desarrollo de la herramienta de sincronización de archivos clsync. No voy a entrar en detalles técnicos, otra cosa es importante. Como se indica en el nombre de la empresa, la
herramienta es de código abierto , y después del informe se siguieron algunos consejos, por ejemplo, para usar
futex , a lo que el orador sugirió unirse al proyecto y mejorarlo de forma independiente.
Lo más interesante en términos de código abierto, en mi opinión, fue el
informe del empleado de Positive Technologies Alexander Popov.
El informe se tituló "Cómo STACKLEAK mejora la seguridad del kernel de Linux" y parecía que debería haberse dedicado a la historia de STACKLEAK y con lo que se comió. Pero el tiempo principal del informe se dedicó al tema, que se expresa en la frase de la anotación al informe:
“Alexander ha estado realizando este trabajo durante un año. Él compartirá su experiencia con la comunidad de desarrollo del núcleo de Linux ". Es decir, durante el año se impulsan cambios útiles, muchas personas están involucradas, los cambios son examinados bajo un microscopio por especialistas calificados que trabajan en diferentes subsistemas del núcleo. Por supuesto, esto no garantiza la ausencia total de errores, pero reduce su número y, por lo tanto, aumenta la confiabilidad del código.
Enfoque alternativo
En la conferencia, al igual que
el año pasado , se presentó un
informe sobre QP OS. En el resumen del informe, puede ver lo siguiente: "El sistema operativo seguro QP OS es un desarrollo completamente doméstico, creado" desde cero "por el equipo de la empresa científica y técnica" Cryptosoft ". El informe también expresó el principio del desarrollo desde cero, no solo del sistema operativo, hipervisor, pila de red, sino también de todos los subsistemas y aplicaciones de usuario, así como el compilador, la máquina virtual C # y, según tengo entendido, todas las demás herramientas de desarrollo. Para mi pregunta al orador, ¿qué pasa con la confiabilidad, porque la proporción de la cantidad de errores por cada mil líneas de código no se ha cancelado? Recibí la respuesta de que la confiabilidad puede entenderse como cosas diferentes, y que se considera confiable para un sistema operativo dado si cae cada vez menos entre dos reinicios. Ya después del informe, al margen, aconsejé tomar un proyecto abierto para proporcionar un soporte más completo para la
samba . Pero recibió una respuesta de que es una posición de principios desarrollar todo independientemente, con la explicación de que tal enfoque tiene derecho a la vida. Bueno, lo llamé un enfoque alternativo.
Cabe señalar que hubo una exposición en la conferencia, y se presentó un stand en el que se podía probar el QP OS en vivo. Jugué con su editor, funcionó bastante bien. En el stand, confirmaron que ni siquiera tomaron prestado el código de las bibliotecas para trabajar con xml. Además, quizás un enfoque similar "todo desde cero" proviene del alcance en el que trabajan los desarrolladores. Esta esfera se caracteriza por su excesiva seguridad, es mejor caer que marcar en algún lugar. Es cierto que esto no justifica negarse a usar el código fuente abierto.
Tiempo real duro
En esta sección, no puedo dejar de referirme a otro informe, al menos porque el orador se refirió a mi presentación, por lo tanto, tengo derecho a hacer lo mismo. Después de mi discurso, me preguntaron si el soporte del acelerador 3D no interfiere con el suministro de características en tiempo real y, en general, ¿nuestro proyecto es un sistema operativo difícil en tiempo real? Respondí evasivamente la última pregunta, ya que el tiempo en la conferencia es limitado, y la pregunta de qué significar en tiempo real requiere una explicación bastante seria. El orador mencionado habló justo después de mí con un
informe sobre su Eremex FX-RTOS RTOS y declaró que, a diferencia de nuestro proyecto, su sistema operativo es un sistema difícil en tiempo real. Una señal de tiempo real difícil, según el orador, es la ausencia de ciclos con un número variable de iteraciones con interrupciones bloqueadas.
No me atrevo a juzgar si hay bucles potencialmente infinitos con interrupciones bloqueadas en FX-RTOS RTOS o no, ya que el código está cerrado, pero, por supuesto, estoy de acuerdo en que tales ciclos son inaceptables incluso en sistemas operativos comunes, ¡sin mencionar RTOS!
Además, durante el informe, se afirmó que los desarrolladores lograron evitar por completo las interrupciones de bloqueo (enmascaramiento), aunque solo en la corteza del brazo-m, pero aún así este es un gran logro, que, según el orador, también indica en tiempo real. Además, el altavoz se detuvo durante mucho tiempo en un dispositivo basado en FX-RTOS, que respondió a través de la interfaz UART durante varios milisegundos, lo que nuevamente indica un tiempo real difícil.
No sé cuál de nosotros tiene un enfoque alternativo al concepto de "tiempo real", simplemente expresaré mi punto de vista. Y solo responderé a la pregunta de si Embox es un sistema en tiempo real.
El concepto de tiempo real está directamente relacionado con la previsibilidad del comportamiento del sistema bajo la influencia de cualquier factor (tanto interno como externo). De esto se desprende la conexión del concepto de tiempo real con el concepto de fiabilidad. De ahí la noción de que Windows, como sistema operativo universal, no es confiable, y el sistema operativo en tiempo real (como el sistema construido sobre él) es confiable.
Los parámetros del tiempo de reacción son uno de los factores de predictibilidad más importantes, pero en los sistemas en tiempo real, no es tanto la velocidad de reacción lo que importa como la variación en el tiempo de reacción, y debe estar estrictamente limitada. Encontré una definición en la que el tiempo real suave se definía como un sistema con un pequeño valor de respuesta promedio del sistema, y difícil, con un pequeño máximo. Y dado que la velocidad de los procesadores modernos ha aumentado considerablemente, el tiempo (promedio) de ejecución ya no juega ese papel, porque para aumentar la velocidad de reacción es suficiente poner un procesador más potente. Pero no es posible deshacerse de la influencia de los algoritmos y la arquitectura, es decir, Linux con su
programador honesto , dirigido a la carga máxima de la CPU, no puede considerarse un sistema en tiempo real. Aunque estoy seguro de que el tiempo de reacción según UART se puede hacer bastante pequeño, no será estable, porque el planificador puede decidir que necesita cargar el procesador con alguna otra tarea, y el tiempo de respuesta aumentará de manera impredecible. Por lo tanto, podemos formular las siguientes características de los sistemas operativos en tiempo real: son sistemas operativos que proporcionan el mejor control para todos sus sistemas, incluidos los internos. Tomemos, por ejemplo,
ARINC-653 con su requisito en términos de un planificador con un horario estático. En estos sistemas operativos, el desarrollador tiene acceso a las tablas de planificación, que está completando en el momento del desarrollo del sistema. Es decir, el desarrollador asigna tiempo (intervalos de tiempo) en el período de planificación general para cada sección, todas las interrupciones están deshabilitadas (excepto el temporizador, por supuesto, disponible solo para el planificador), y el desarrollador debe hacer un horario tal que cada sección tenga suficiente tiempo para resolver su problema. Al mismo tiempo, el planificador no tiene derecho a cambiar de alguna manera este cronograma.
Si piensa en qué otros sistemas operativos proporcionan acceso completo o ampliado a sus "menudillos", es fácil llegar a la conclusión de que los proyectos modernos de sistemas operativos pequeños tienen un nombre orgulloso RTOS (sistema operativo en tiempo real). Dado que proporcionan este acceso, y el desarrollador ya es responsable de garantizar que el sistema final construido sobre la base de RTOS cumpla con todos los requisitos, ¡incluida la previsibilidad de la reacción ante cualquier impacto!
En cuanto a Embox, también proporcionamos mecanismos de control para todos los servicios, incluido el núcleo. Y desde este punto de vista, Embox es un sistema operativo en tiempo real. Sí, los sistemas con la arquitectura MILS se hicieron sobre la base de Embox (no lo llamo conscientemente ARINC-653, ya que ARINC-653 está determinado por el certificado para el cumplimiento del estándar), pero también puede construir otra arquitectura que garantice la suficiente previsibilidad de la reacción. Un cliente, por ejemplo, verificó el tiempo de respuesta en un osciloscopio, el tiempo era preciso para varios ciclos de procesador y estaba muy limitado. Es cierto que el sistema no estaba cargado, de las aplicaciones activas, solo el servidor estaba girando, lo que reaccionó al evento. Pero el cliente quedó muy satisfecho con el resultado. Por lo tanto, creemos que solo es posible hablar sobre el tiempo real en la aplicación del sistema en su conjunto, y el desarrollador es responsable de esto, y el sistema operativo en tiempo real solo proporciona mecanismos para lograr este tiempo muy real. Somos más precisos en nuestra clasificación y hemos escrito
"Embox: caja de herramientas esencial para el desarrollo integrado" .
Los cuadros deciden todo
La extraña frase en el título "¿Qué necesitas enseñar a los estudiantes para que inmediatamente comiencen a trabajar en las empresas de TI rusas y se queden allí?", Esta es en realidad una pregunta que surgió en un panel de discusión. Una cuarta parte de la conferencia se dedicó al problema de la formación y la educación en el campo de las TI. Al comprender la importancia y al mismo tiempo la inconsistencia del problema, los organizadores abordaron el tema de manera muy interesante. Se entregaron cuatro informes, concebidos por los organizadores, los oradores representaron enfoques competitivos. Entonces, dos informes sobre el curso con el mismo nombre "Computer Architecture and Assembly Language" en la facultad de
VMK MSU . Un informe fue hecho por
George Kuryachiy , el otro,
Vartan Padaryan . En realidad, los enfoques fueron similares, y no importa que el ensamblador MIPS haya sido estudiado en un curso y x86 en el otro. En ambos casos, los profesores buscaron desarrollar el curso en el campo práctico. Como continuación del tema sobre la importancia del componente práctico de la capacitación, se presentó un
informe de Aleksey Khoroshilov "Diseño del núcleo del sistema operativo". Este curso, podemos decir, amplía la comprensión de la arquitectura de la computadora y permite a los estudiantes profundizar en el núcleo del sistema operativo. Como resultado, en lugar de enfoques competitivos, resultó que la facultad de VMK tiene un enfoque sistemático, es decir, los cursos no compiten, sino que se complementan y se desarrollan entre sí. En realidad, debería ser así. La frase también sonaba: "Para aprender a programar, necesitas programar", que, en mi opinión, define el principio general de capacitación en TI.
Incluso en esta sección apareció romana Simakov de la compañía "rojo suave"
informe "Peculiaridades de los programadores del sistema de formación en las ciudades pequeñas." El resto de los oradores en esta sección eran de Moscú, como probablemente habrás adivinado.
El informe sobre los problemas enumerados me recordó mucho (y no solo a mí) del
informe "Errores en la supervisión estatal de la educación superior: el principal problema de la educación superior en Rusia" de la conferencia OSEDUCONF-2018 que describí en el
centroCompara:
tomado de la página con resúmenes del
informe actual
1) Al asignar fondos presupuestarios para una especialidad en una universidad, tenga en cuenta el número de graduados que trabajan en esta especialidad. Si no hay demanda de especialistas, entonces no tiene sentido financiar lugares presupuestarios. Si Los graduados trabajan, pagan impuestos, ¡pero ganan algo más! Al registrar a un empleado, un empleador podría indicar su especialidad y universidad, y ahora todo esto es muy fácil de agregar.
2) Cambiar la base comercial de la educación. Debe pagar no por la preparación, sino por su resultado. Las empresas de TI podrían solicitar capacitación especializada y pagar de acuerdo con los resultados. En términos generales, los especialistas de la compañía asisten a los exámenes, evalúan por sí mismos y "firman el certificado de aceptación" de los resultados de la capacitación.
Está tomado de mi revisión del informe sobre
HabréEn este informe, el autor describió los problemas de la ineficiencia de la educación actual. Una posible razón para esto es la burocracia. Sobre el problema de la burocratización no voy a difundir mucho. Todos los que están conectados con el proceso educativo, de una forma u otra, se enfrentan a él. El autor expresó la opinión de que el principal problema de la educación es que el proceso está controlado, no el resultado. Es decir, se imponen requisitos formales a la universidad y se verifican. El valor real de la educación es la demanda de sus graduados.
En ambos casos, la idea principal es que la universidad debe formar especialistas exitosos en su industria, y no informar sobre el número de plazas. Cuando se le dijo al autor del informe que estas ideas no eran nuevas, se ofendió y dijo que eran originales. Nadie duda de esto, pero el hecho de que ambos informes fueron presentados por ciudades pequeñas (Murom y Pereslavl-Zalessky) sugiere que los problemas con la distribución del dinero del presupuesto para educación son bastante serios, y son especialmente evidentes en las ciudades pequeñas.
En cuanto a la pregunta del título del artículo, le sugerí a su autor que no piense en lo que los programadores necesitan que se les enseñe, sino que desarrolle la industria de TI en sí. Está claro que si un especialista no encuentra una aplicación para sus conocimientos y habilidades, irá a donde estén en demanda. Es la industria la que exige los especialistas, y no las universidades ni el estado. Fui apoyado por un orador de ISP RAS, quien dijo que debería haber una "trinidad": educación, ciencia, industria. Sin ninguno de estos componentes, otras partes comienzan a ceder.
Además, me refiero a mi
artículo "Dónde conseguir un programador" en el que traté de ofrecer mi enfoque para mejorar la educación en TI.
Resumen
En resumen, quiero señalar que la conferencia es interesante principalmente por su diversidad de opiniones y, por supuesto, la calidad de los informes. , , , .
.
,
. .