No final de maio, a
Embox , já tradicionalmente, participava do
OSDay . A conferência, como no ano passado, foi realizada no prédio principal da RAS. Desta vez, foi dedicado à confiabilidade. O tópico da confiabilidade do software é antigo. É afetado, por exemplo, por
Frederick Brooks em seu lendário trabalho
Mythical Man-Month , que também foi mencionado várias vezes na própria conferência. O livro menciona que um dos problemas encontrados no processo de criação do
sistema operacional
OS / 360 foi a falta de um número suficiente de programadores qualificados. Provavelmente, pela mesma razão, muito tempo na conferência foi dedicado à educação no campo da programação de sistemas. Em geral, quem está interessado no que, na minha opinião, idéias interessantes foram expressas e discutidas na conferência, peço gato.
Na abertura da conferência, um de seus fundadores, Dmitry Zavalishin
dzavalishin , expressou vários pontos:
- Os sistemas de software modernos são tão complexos que a confiabilidade é necessária para qualquer um deles, e não apenas para os "especiais", como era antes
- Pessoas diferentes podem ter idéias diferentes sobre a confiabilidade do software; por exemplo, algumas pessoas consideram a confiabilidade um sinônimo de segurança.
- Os métodos para garantir a confiabilidade podem ser diferentes, com base pelo menos na suposição de que os conceitos de confiabilidade diferem
No primeiro dia, o ISP RAS apresentou um
relatório sobre a confiabilidade do software do ponto de vista acadêmico. E, embora fosse provavelmente uma homenagem à história, ficou claro que o problema estava longe de ser novo, e as definições de confiabilidade, bem como os métodos para avaliá-lo, eram muito diversas. O relatório, embora tenha sido severamente cortado (como o orador tentou manter em 30 minutos), foi interessante por sua natureza científica.
Métodos instrumentais
Os métodos para garantir a confiabilidade do código podem ser divididos em várias categorias. Começarei com as ferramentas pelas quais o anfitrião da conferência, ISP RAS, é famoso. Seu funcionário apresentou um
relatório sobre a experiência de verificar partes do kernel Linux usando a ferramenta klever.
Klever é uma estrutura aberta para verificação de código estático. Na verdade, o problema que o autor do relatório resolveu pode ser formulado da seguinte maneira. A verificação do código estático é muito complicada para verificar projetos modernos como um todo, mas você pode tentar selecionar uma parte mais ou menos isolada, por exemplo, o subsistema do kernel Linux ou um driver separado e, após definir o ambiente apropriado, verifique-o. Em seguida, você pode tentar fazer iterativamente isso com todo o projeto.
Métodos arquitetônicos
Outra abordagem para a construção de sistemas mais confiáveis é o uso de técnicas "arquitetônicas". Para eles, incluiria a idéia de memória persistente do
sistema operacional Phantom e a arquitetura do
MILS (vários níveis independentes de segurança / segurança).
O relatório sobre o MILS tratou de suas propriedades para aprimorar a segurança de sistemas críticos e foi enviado à Kaspersky Lab.
O relatório sobre o coletor de lixo nas condições de memória persistente foi apresentado não apenas pelo autor do OS Phantom, mas também por um estudante da Universidade de Innopolis. Naturalmente, a idéia de usar idiomas de gerenciamento para aumentar a confiabilidade do sistema não é nova. E no relatório, na minha opinião, o envolvimento dos alunos em um projeto de código aberto para criar software de sistema era importante.
Abordagem metódica
A mais numerosa em termos de número de relatórios, mas subestimou a abordagem para melhorar a confiabilidade do software, na minha opinião, é "metódica". Se você pensar bem, a separação do sistema operacional como uma entidade separada teve como objetivo melhorar a confiabilidade do software. O programador teve a oportunidade de reutilizar os serviços do sistema e de não desenvolvê-los novamente.
Um relatório sobre a metodologia para o desenvolvimento de software crítico foi apresentado pelo FSUE GosNIIAS. O relatório foi dedicado ao desenvolvimento do padrão
DO-178C (CT-178C na versão russa). Como no próprio padrão, o relatório teve muita "tédio", mas quando você faz um avião, não pode fazer algumas idéias encantadoras, precisa verificar várias vezes antes de fazer a menor alteração. Em geral, meça uma vez, corte sete vezes, pelo contrário, é claro. Naturalmente, o relatório foi interessante não por sua "tediosidade", mas pelo fato de que ferramentas foram desenvolvidas para automatizar esse processo, ou seja, para reduzir a "tediosidade".
Código aberto
Finalmente, volto para a seção em que a Embox falou. Nosso
relatório foi intitulado "Organização de suporte à aceleração 3D no RTOS com base em projetos de código aberto". Nele, uma parte bastante grande foi dedicada à explicação, e aqui à confiabilidade. Houve até um slide como "Confiabilidade e aceleração 3d de hardware". A confiabilidade, é claro, não está na aceleração 3D, mas na frase “baseada em projetos de código aberto”. A conclusão é que fomos capazes de adicionar suporte ao acelerador 3d vivante fechado usando projetos de código aberto. E embora o projeto
Mesa que usamos esteja fortemente vinculado à interface do kernel Linux, a adaptação requer muito menos esforço e contém muito menos linhas de código do que o desenvolvimento do zero.
Como já observei, o código aberto é a categoria mais numerosa com a qual os relatórios da conferência estavam de alguma forma conectados. Por exemplo, o Basalt SPO apresentou um
relatório sobre o desenvolvimento da ferramenta de sincronização de arquivos clsync. Não vou entrar em detalhes técnicos, outra coisa é importante. Conforme indicado no nome da empresa, a
ferramenta é de código aberto e, após o relatório, várias dicas seguiram, por exemplo, o uso do
futex , para o qual o palestrante sugeriu ingressar no projeto e melhorá-lo de forma independente.
O mais interessante em termos de código aberto, na minha opinião, foi o
relatório do funcionário da Positive Technologies, Alexander Popov.
O relatório foi intitulado "Como o STACKLEAK melhora a segurança do kernel do Linux" e parecia que deveria ter sido dedicado à história do STACKLEAK e com o que foi consumida. Mas o tempo principal do relatório foi dedicado ao tópico, expresso na frase da anotação ao relatório:
“Alexander realiza esse trabalho há um ano. Ele compartilhará suas experiências com a comunidade de desenvolvimento de kernel do Linux .
” Ou seja, durante o ano são promovidas mudanças úteis, muitas pessoas envolvidas, mudanças são examinadas ao microscópio por especialistas qualificados que trabalham em diferentes subsistemas do núcleo. Obviamente, isso não garante a completa ausência de erros, mas reduz seu número e, portanto, aumenta a confiabilidade do código.
Abordagem alternativa
Na conferência, assim como
no ano passado , foi apresentado um
relatório sobre o QP OS. No resumo do relatório, você pode ver o seguinte: “O sistema operacional seguro QP OS é um desenvolvimento completamente doméstico, criado“ do zero ”pela equipe da empresa científica e técnica“ Cryptosoft ”. O relatório também expressou o princípio do desenvolvimento do zero, não apenas do sistema operacional, hypervisor, pilha de rede, mas também de todos os subsistemas e aplicativos de usuário, bem como do compilador, da máquina virtual C # e, no meu entender, de todas as outras ferramentas de desenvolvimento. Para minha pergunta ao orador, e quanto à confiabilidade, porque a proporção do número de erros por mil linhas de código não foi cancelada. Eu recebi a resposta de que a confiabilidade pode ser entendida como coisas diferentes e que é considerada confiável para um determinado sistema operacional se cair cada vez menos entre duas reinicializações. Já após o relatório, à margem, eu aconselhei a realização de um projeto aberto para fornecer suporte mais completo ao
samba . Mas ele recebeu uma resposta de que é uma posição baseada em princípios desenvolver tudo de forma independente, com a explicação de que tal abordagem tem direito à vida. Bem, chamei de abordagem alternativa.
Note-se que houve uma exposição na conferência e foi apresentado um estande no qual o QP OS poderia ser experimentado ao vivo. Eu brinquei com o editor deles, funcionou muito bem. No estande, eles confirmaram que nem emprestaram o código das bibliotecas para trabalhar com xml. Além disso, talvez uma abordagem semelhante “tudo do zero” venha do escopo em que os desenvolvedores trabalham. Esta esfera é caracterizada por sua segurança excessiva, é melhor cair do que marcar em algum lugar. É verdade que isso não justifica a recusa de usar o código-fonte aberto.
Tempo real difícil
Nesta seção, não posso deixar de me referir a outro relatório, pelo menos porque o orador se referiu à minha apresentação, portanto, tenho o direito de fazer o mesmo. Após minha palestra, perguntaram-me se o suporte do acelerador 3d não interfere no fornecimento de características em tempo real e, em geral, nosso projeto é um sistema operacional difícil em tempo real? Respondi evasivamente à última pergunta, já que o tempo na conferência é limitado e a questão do que quer dizer em tempo real requer uma explicação bastante séria. O palestrante mencionado falou logo após mim com um
relatório sobre o Eremex FX-RTOS RTOS e afirmou que, diferentemente do nosso projeto, o sistema operacional deles é um sistema rígido em tempo real. Um sinal de tempo real difícil, de acordo com o orador, é a ausência de ciclos com um número variável de iterações com interrupções bloqueadas.
Não me atrevo a julgar se existem loops potencialmente infinitos com interrupções bloqueadas no FX-RTOS RTOS ou não, já que o código está fechado, mas é claro que concordo que esses ciclos são inaceitáveis mesmo em sistemas operacionais comuns, sem mencionar o RTOS!
Além disso, durante o relatório, foi declarado que os desenvolvedores conseguiram evitar completamente as interrupções de bloqueio (mascaramento), embora apenas no braço córtex-m, mas ainda assim é uma grande conquista, que, segundo o orador, também indica em tempo real. Além disso, o alto-falante parou por um longo tempo em um dispositivo baseado no FX-RTOS, que respondeu por meio da interface UART por vários milissegundos, o que novamente indica um tempo real difícil.
Não sei qual de nós tem uma abordagem alternativa ao conceito de "tempo real", apenas expressarei meu ponto de vista. E apenas responderei à questão de saber se a Embox é um sistema em tempo real.
O conceito de tempo real está diretamente relacionado à previsibilidade do comportamento do sistema sob a influência de quaisquer fatores (internos e externos). A partir disso, segue a conexão do conceito de tempo real com o conceito de confiabilidade. Portanto, a noção de que o Windows, como um sistema operacional universal, não é confiável, e o sistema operacional em tempo real (como o sistema construído nele) é confiável.
Os parâmetros do tempo de reação são um dos fatores de previsibilidade mais importantes, mas em sistemas em tempo real, não é tanto a taxa de reação que é importante quanto a variação no tempo de reação, e deve ser estritamente limitado. Me deparei com uma definição em que tempo real suave era definido como um sistema com um pequeno valor médio de resposta do sistema e difícil - com um pequeno máximo. E como a velocidade dos processadores modernos aumentou bastante, o tempo (médio) de execução não desempenha mais esse papel, porque, para aumentar a velocidade de reação, basta colocar um processador mais poderoso. Mas não é possível se livrar da influência de algoritmos e arquitetura, ou seja, o Linux com seu
agendador honesto , voltado para a carga máxima da CPU, não pode ser considerado um sistema em tempo real. Embora eu tenha certeza de que o tempo de reação de acordo com o UART pode ser bastante pequeno, ele não será estável, porque o planejador pode decidir que precisa carregar o processador com alguma outra tarefa, e o tempo de resposta aumentará imprevisivelmente. Portanto, podemos formular as seguintes características dos sistemas operacionais em tempo real: são sistemas operacionais que fornecem o melhor controle para todos os seus sistemas, incluindo os internos. Tomemos, por exemplo, o
ARINC-653 com seus requisitos em termos de um planejador com um planejamento estático. Nesses sistemas operacionais, o desenvolvedor tem acesso a tabelas de planejamento, que ele está preenchendo no momento do desenvolvimento do sistema. Ou seja, o desenvolvedor aloca tempo (intervalos de tempo) no período de planejamento geral para cada seção, todas as interrupções são desativadas (exceto o cronômetro, é claro, disponível apenas para o planejador) e o desenvolvedor deve fazer um cronograma para que cada seção tenha tempo suficiente para resolver seu problema. Ao mesmo tempo, o agendador não tem o direito de alterar esse agendamento.
Se você pensar sobre o que outros sistemas operacionais fornecem acesso total ou expandido aos seus "grupos", é fácil chegar à conclusão de que projetos modernos de sistemas operacionais pequenos têm um nome de orgulho RTOS (sistema operacional em tempo real). Como eles fornecem esse acesso, o desenvolvedor já é responsável por garantir que o sistema final construído com base no RTOS atenda a todos os requisitos, incluindo a previsibilidade da reação a qualquer impacto!
Quanto à Embox, também fornecemos mecanismos de controle para todos os serviços, incluindo o kernel. E deste ponto de vista, a Embox é um sistema operacional em tempo real. Sim, os sistemas com a arquitetura MILS foram criados com base na Embox (eu não o chamo conscientemente de ARINC-653, pois o ARINC-653 é determinado pelo certificado para conformidade com o padrão), mas você também pode construir outra arquitetura que garanta previsibilidade suficiente da reação. Um cliente, por exemplo, verificou o tempo de resposta em um osciloscópio, o tempo foi preciso para vários ciclos do processador e foi muito limitado. É verdade que o sistema não estava carregado, dos aplicativos ativos, apenas o servidor estava girando, o que reagiu ao evento. Mas o cliente ficou muito satisfeito com o resultado. Portanto, acreditamos que só é possível falar em tempo real no aplicativo para o sistema como um todo, e o desenvolvedor é responsável por isso, e o sistema operacional rígido em tempo real fornece apenas mecanismos para atingir esse tempo muito real. Somos mais precisos em nossa classificação e escrevemos
»Embox - Caixa de ferramentas essencial para desenvolvimento incorporado" .
Os quadros decidem tudo
A frase estranha no título “O que você precisa ensinar aos alunos para que eles comecem imediatamente a trabalhar nas empresas de TI russas e fiquem lá” - essa é realmente uma pergunta que foi levantada em um painel de discussão. Um quarto da conferência foi dedicado ao problema de treinamento e educação no campo da TI. Compreendendo a importância e ao mesmo tempo a inconsistência do problema, os organizadores abordaram de maneira muito interessante o assunto. Foram entregues quatro relatórios, conforme concebidos pelos organizadores, os palestrantes representavam abordagens competitivas. Assim, dois relatórios sobre o curso com o mesmo nome "Arquitetura de Computadores e Linguagem Assembly" na faculdade da
VMK MSU . Um relatório foi feito por
George Kuryachiy , o outro -
Vartan Padaryan . Na verdade, as abordagens foram semelhantes e não importa que o MIPS assembler tenha sido estudado em um curso e x86 no outro. Nos dois casos, os professores procuraram desenvolver o curso no campo prático. Na continuação do tópico sobre a importância do componente prático do treinamento, foi
apresentado um
relatório de Aleksey Khoroshilov “Design do kernel do sistema operacional”. Podemos dizer que este curso expande a compreensão da arquitetura de computadores e permite que os alunos se aprofundem mais no núcleo do sistema operacional. Como resultado, em vez de abordagens concorrentes, verificou-se que o corpo docente da VMK tem uma abordagem sistemática, ou seja, os cursos não competem, mas se complementam e se desenvolvem. Na verdade, deve ser assim. A frase também soou: “Para aprender a programar, você precisa programar”, que, na minha opinião, define o princípio geral do treinamento em TI.
Mesmo nesta seção, Roman Simakov da empresa "RED SOFT" fez uma
apresentação "Características do treinamento de programadores de sistemas em pequenas cidades". O restante dos oradores desta seção era de Moscou, como você provavelmente adivinhou.
O relatório sobre os problemas listados me lembrou muito (e não apenas eu) do
relatório “Erros na supervisão estatal do ensino superior - o principal problema do ensino superior na Rússia” da conferência OSEDUCONF-2018 descrita por mim no
hubCompare:
extraído da página com resumos do
relatório atual
1) Ao alocar fundos de orçamento para uma especialidade em uma universidade, leve em consideração o número de graduados que trabalham nessa especialidade. Se os especialistas não estão sendo procurados, não faz sentido financiar orçamentos. Sim Os graduados trabalham, pagam impostos, mas ganham outra coisa! Ao registrar um funcionário, um empregador pode indicar sua especialidade e universidade, e agora tudo isso é muito fácil de agregar.
2) Mude a base comercial da educação. Você precisa pagar não pela preparação, mas pelo resultado. As empresas de TI podem solicitar treinamento especializado e pagar de acordo com os resultados. Grosso modo, os especialistas da empresa participam de exames, avaliam por si mesmos e “assinam o certificado de aceitação” dos resultados do treinamento.
Foi retirado da minha revisão do relatório sobre
HabréNeste relatório, o autor descreveu os problemas da ineficiência da educação atual. Uma possível razão para isso é a burocracia. Sobre o problema da burocratização, não vou me espalhar muito. todos os que se relacionavam com o processo educacional, de uma forma ou de outra, enfrentavam-no. O autor expressou a opinião de que o principal problema da educação é que o processo é controlado, não o resultado. Ou seja, requisitos formais são impostos à universidade e são verificados. O valor real da educação é a demanda de seus graduados.
Nos dois casos, a idéia principal é que a universidade treine especialistas bem-sucedidos em seu setor, e não informe sobre o número de vagas. Quando o autor do relatório foi informado de que essas idéias não eram novas, ele ficou ofendido e disse que eram originais. Ninguém duvida disso, mas o fato de os dois relatórios terem sido apresentados por cidades pequenas (Murom e Pereslavl-Zalessky) sugere que os problemas com a distribuição do dinheiro do orçamento para a educação são bastante graves e são especialmente evidentes nas cidades pequenas.
Quanto à pergunta do título do artigo, sugeri ao autor que não pensasse no que os programadores precisam ser ensinados, mas que desenvolvesse o próprio setor de TI. É claro que, se um especialista não encontrar aplicação para seus conhecimentos e habilidades, ele irá para onde eles serão procurados. É a indústria que forma a exigência de especialistas, e não universidades ou o estado. Fui apoiado por um palestrante do ISP RAS, que disse que deveria haver uma “trindade”: educação, ciência, indústria. Sem nenhum desses componentes, outras partes começam a ceder.
Além disso, refiro-me ao meu
artigo “Onde conseguir um programador”, no qual tentei oferecer minha abordagem para melhorar a educação em TI.
Sumário
Em resumo, quero observar que a conferência é interessante principalmente por sua diversidade de opiniões e, é claro, pela qualidade dos relatórios. , , , .
.
,
. .