Системное программирование *

Сегодня я публикую перевод доклада «An Examination of Open System Architectures for Avionics Systems– An Update» сделанного Joyce L. Tokar, PhD, Pyrrhus Software, LLC, в марте 2017.

Признавая необходимость доступных и эффективных решений для развития систем авионики, Министерство обороны США (Department of Defense, DoD ) в указаниях по повышению эффективности военных расходов (Better Buying Power 3.0, BBP), Инструкции 5000.02 и Руководстве по оборонным закупкам (Defense Acquisition Guidebook, DAG) призывает к использованию решений на базе Систем с отрытой архитектурой (Open System Architecture, OSA ). Цели руководства и указаний - избежать привязки к одному поставщику, сделать доступными развитие возможностей и /продвижение инноваций. В настоящее время осуществляются несколько инициатив по разработке стандартов OSA для использования в системах военной авионики. В этой статье будут рассмотрены три таких направления: Управление беспилотными системами (UxS ), Архитектура сегмента управления (UCS ), инициатива Открытые системы управления полетом (Open Mission Systems, OMS ) и реализация Перспективной среды авиационных бортовых систем (FACE​) выполненная открытой группой (Open Group). Эта статья начнется с уточнения определения систем с открытой архитектурой в понимании Министерства обороны США. Далее будет краткое описание этих трех стандартов OSA, мероприятий, которые проводятся в соответствии с указаниями Министерства обороны США. Документ затем представит анализ этих OSA на основе рекомендаций Министерства обороны США. И наконец, в документе будет обобщено состояние этих OSA и даны рекомендации для дальнейшей работы.

Приветствую! 

Каждый раз, когда начинаешь решать какую-либо большую задачу, то на пути появляется множество маленьких. И найденные или не найденные решения маленьких подзадач превращаются в то, что мы в дальнейшем называем опытом. Но к сожалению, если не пользуешься чем-то постоянно, то когда-то найденные оригинальные решения со временем начинаешь забывать, а когда необходимо, начинаешь вспоминать и с удивлением, а иногда и с не пониманием долго смотришь на свои же шедевры. 

Статья рассчитана на тех кто уже знаком с Си, а все примеры ориентированы на ОС Linux. Мои познания Windows закончились на «WinXP», после которой в Windows стало уже очень много политики ("безопасности") и коммерческой составляющей, но я сейчас не об этом и надеюсь, что здесь вы найдёте для себя полезные моменты, а если я в чём-то не прав или заблуждаюсь, то поправите.

Итак, я решил попробовать писать в стиле объектно ориентированного программирования (далее ООП) на Си без плюсов. Многие скажут, что писать в стиле объектно ориентированного программирования (далее ООП) не для Си, и разные приёмы написания это - «псевдо-ООП». Но лично я считаю ООП всего лишь абстрактной парадигмой, определяющей стиль написания ПО и не более чем. А Си очень мощный и самодостаточный язык программирования.

Так сложилось, что изучать традиции ООП я начал с Delphi и Java, являющихся, как считается, на 100% объектно ориентированными языками программирования, а потому аналогия решений у меня ассоциируется именно с ними. И далее в тексте я иногда буду на них ссылаться, что надеюсь не испортит суть полного понимания.

Let's Encrypt — это центр сертификации, который предоставляет бесплатные сертификаты в полностью автоматизированном процессе. Эти сертификаты выдаются по протоколу ACME. За последние два года в Интернете широко использовалась технология Let’s Encrypt — более 50% веб-сертификатов SSL / TLS теперь выдает Let’s Encrypt.

В этом посте описывается, как выдавать сертификаты Let's Encrypt для внутренних серверов.

Domain-Driven Design — это, как правило, подход к проектированию систем программного обеспечения, который предполагает создание общего языка между экспертами домена и разработчиками системы. В число известных правил DDD входят Use a Ubiquitous Language и Make The Implicit Explicit.

Однако некоторые понятия в DDD не имеют четкого определения и являются достаточно неявными. Каждый понимает по-своему, что такое домен, поддомен, пространство задач и пространство решений. В этой статье я постараюсь сформулировать рабочие определения этих понятий и разъяснить их.

Данная статья подготовлена в результате длительной беседы на github с участием многих представителей сообщества DDD. Спасибо всем участникам этого диалога за сотрудничество.

Во всём мире найдётся немного компаний, разрабатывающих свою ОС с нуля (то есть не просто вариант Linux). Поэтому у каждой из них есть что рассказать: там занимаются задачами, с которыми обычный прикладной разработчик не сталкивается. Слушать их рассказы можно и из теоретического интереса («а как у вас всё внутри устроено?»), и из практического: «а как писать приложения под вашу ОС и что это мне даст?»

В России такой компанией стала «Лаборатория Касперского», где работают над безопасной системой KasperskyOS. Своим опытом команда делится на онлайн-конференции KasperskyOS Night, в предыдущий раз она проходила зимой, а 7-8 июля грядёт летняя версия. Поэтому в этом тексте «два в одном»: сначала видеозаписи зимних выступлений, а затем полная программа нового мероприятия.

Некоторое время назад довелось мне по проектной необходимости поиграть в отладочную плату Teensy 4.1. Что это за зверь – можно посмотреть на сайте разработчика Teensy​ 4.1 (pjrc.com). Вообще, штука знатная. Там стоит контроллер MIMXRT1062DVJ6A фирмы NXP. Ядро – Cortex M7. Тактовая частота – до 600 МГц! Впечатляет? Но самое главное – там имеется два контроллера EHCI, реализующих порты USB 2.0 HS. На этой плате один контроллер подключён к разъёму Micro USB, а второй – к разъёму USB Host. Есть там ещё и порт Ethernet, но с ним я пока не возился. Ну, и масса других замечательных штук.

К сожалению, рекомендуемая среда разработки Arduino весьма спартанская, а библиотека же вообще напоминает Авгиевы конюшни. Сама по себе она рабочая. Прикладной программист будет рад воспользоваться ею. Но доработать её – тот ещё процесс. Плюс её делает, по сути, один разработчик, а не огромное сообщество (как, например, ESP8266 или ESP32). Поэтому функционал не богат, а самостоятельная доработка затруднена.

Но мой неугомонный начальник задал простой и естественный вопрос: «А что мешает пользоваться штатной средой разработки от NXP – MCUXpresso?» Дело в том, что там имеется огромный набор готовых библиотек для нужного нам контроллера. Лично я уже работал с этой средой для нашего сервиса All-Hardware. Впечатления были самые приятные, я ими делился вот в этой статье. Попробовав, я понял, что он, как всегда, прав. И возникла идея коротенько, статьи на четыре-пять, зафиксировать результаты экспериментов. Поэтому приступаем. Сегодня мы просто возьмём готовый пример от MCUXpresso, запустим его в Teensy и убедимся, что всё работает.

Вот что приходит мне на ум, когда я думаю о D: быстрый, выразительный, легкий и... драйвовый? Именно так, я вожу машину вместе с D.

Вот мой почтенный автомобиль Holden VZ Ute. С завода он поставлялся с убогой четырехступенчатой автоматической коробкой передач. За 18 месяцев владения автомобилем я сломал четыре коробки передач. В то время я не мог позволить себе новый автомобиль, поэтому мне пришлось творчески подойти к делу. Я купил железобетонную, дуракоустойчивую шестиступенчатую автоматическую коробку передач от другого автомобиля. Но на этом я уперся в тупик. Чтобы заставить ее работать, мне пришлось собрать собственную печатную плату, систему управления и прошивку для управления соленоидами, гидравликой и сцеплениями внутри коробки передач, обработки команд водителя, принятия решений о переключении передач и взаимодействия с автомобилем, притворяясь четырехступенчатым автоматом.

Команда Rust рада сообщить о выпуске новой версии — 1.53.0. Rust — это язык программирования, позволяющий каждому создавать надёжное и эффективное программное обеспечение.

Если вы установили предыдущую версию Rust средствами rustup, то для обновления до версии 1.53.0 вам достаточно выполнить следующую команду:

rustup update stable

Если у вас ещё не установлен rustup, вы можете установить его с соответствующей страницы нашего веб-сайта, а также посмотреть подробные примечания к выпуску на GitHub.

Что было стабилизировано в 1.53.0

Этот выпуск содержит несколько новых возможностей языка и ещё больше — стандартной библиотеки, включая долгожданную реализацию IntoIterator для массивов. Смотрите подробные примечания к выпуску, чтобы узнать о других изменениях, не представленных в данном анонсе.

Не так давно в качестве хобби решил погрузиться в изучение embedded разработки на Rust и через какое-то время мне захотелось сделать себе логгер, который бы просто писал логи через UART, но который бы при этом не знал какая конкретно реализация используется. И вот тут я быстро осознал, именно в этом конкретном случае я не могу полагаться на статический полиморфизм и мономорфизацию, ведь компилятор не знает сколько нужно памяти выделять под конкретную реализацию. Фактически это означает, что нам нужно как-то уметь сохранять типы, размер которых неизвестен на этапе компиляции, и такой способностью обладает тип Box и для решения этой проблемы как раз и возникла идея написать свой аналог типа Box, но который сохраняет обьект не в куче, а в предоставленном пользователем буфере.

Фото с сайта linkerd.io

Пару лет назад ребята из Kinvolk сравнили производительность Linkerd и Istio и узнали, что Linkerd значительно быстрее и меньше Istio везде, кроме одной области. Linkerd использовала больше процессорных ресурсов в плоскости данных (data plane). Недавно мы повторили эти эксперименты с последними версиями обеих service mesh. Как показывают результаты, Linkerd не только по-прежнему заметно быстрее Istio, но и использует на порядок меньше ресурсов памяти и процессора в плоскости данных (data plane). Причем это происходит, даже если число запросов в секунду в три с лишним раза больше, чем в бенчмарке Kinvolk. Вы легко можете это повторить.

А теперь подробности.

Мы рады объявить третью редакцию языка Rust — Rust 2021, которая выйдет в октябре. Rust 2021 содержит несколько небольших изменений, которые, тем не менее, значительно улучшат удобство использования Rust.

Что такое Редакция?

Релиз Rust 1.0 установил "стабильность без застоя" как основное правило Rust. Начиная с релиза 1.0, это правило звучало так: выпустив функцию в стабильной версии, мы обязуемся поддерживать её во всех будущих выпусках.

Однако есть случаи, когда возможность вносить небольшие изменения в язык бывает полезной — даже если у них нет обратной совместимости. Самый очевидный пример — введение нового ключевого слова, которое делает недействительными переменные с тем же именем. Например, в первой версии Rust не было ключевых слов async и await. Внезапное изменение этих слов на ключевые слова в более поздних версиях привело бы к тому, что, например код let async = 1; перестал работать.

Редакции — механизм, который мы используем для решения этой проблемы. Когда мы хотим выпустить функцию без обратной совместимости, мы делаем её частью новой редакции Rust. Редакции опциональны и должны прописываться явно, поэтому существующие пакеты не видят эти изменения, пока явно не перейдут на новую версию. Это означает, что даже последняя версия Rust по-прежнему не будет рассматривать async как ключевое слово, если не будет выбрана версия 2018 или более поздняя. Этот выбор делается для каждого пакета как части Cargo.toml. Новые пакеты, созданные cargo new, всегда настроены на использование последней стабильной редакции.

Привет, Хабр!

Поговорим о драйверах сетевых устройств Linux, механизме NAPI и его изменениях в ядре 5.12.

Мне показалось интересным поделиться с сообществом информацией о внутреннем устройстве техники Apple, так как статей на эту тему крайне мало. Начать я решил с iPhone. Поэтому предлагаю вам вместе со мной попробовать разобраться в работе этого загадочного девайса.