Аркадный автомат на RISC-V: сбиваем астероиды с микроконтроллером MIK32 АМУР

Вадим Новиков решил реализовать игровую физику в условиях bare metal, используя свой предыдущий опыт на C++/SFML. В проекте использовалась плата Elbear Ace-Uno на базе микроконтроллера MIK32 АМУР, SPI OLED-дисплей SSD1306 разрешением 128×64 и джойстик HW-504 (KY-023), а также модули SPI (цифровой интерфейс передачи данных), аналого-цифровой преобразователь для калибровки и чтения положения джойстика и GPIO для вывода настройки и ввода состояния кнопки.

Код на C включал непрозрачные типы, которые позволяют реализовать подобие инкапсуляции из ООП. С ними можно объявить в заголовочном файле указатель на некую структуру, но не определять ее. А в единственной трансляции определить структуру и статические функции для взаимодействия с внутренними полями, которые недоступны извне. И поместить туда, соответственно, реализацию открытого интерфейса. Вместо использования регистров напрямую Вадим подключил библиотеку hardware abstraction layer (HAL), чтобы впоследствии было проще портировать проект на STM32 и другие микроконтроллеры.

Результатом работы стала Asteroids — реинкарнация классической игры эпохи аркадных автоматов. Корабль игрока непрерывно выпускает снаряды. После столкновений снаряда с астероидом исчезают оба объекта, при столкновении с кораблем — только астероид. Астероиды, вышедшие за нижнюю границу, возвращаются сверху экрана. Корабль же выйти за границы экрана не может.

Это лишь один из интереснейших проектов, реализованных студентами по итогам последнего потока курса YADRO по программированию микроконтроллеров на RISC-V. Интересно узнать о других проектах? Мы уже рассказали о них в статье.

GPT — мать. Отец — open-source. Хабраредактор локально пророс

Вначале представление о финальном продукте весьма расплывчато: нужен ИИ-помощник, который будет обладать полной информацией обо всех текстах в блоге YADRO и отвечать на вопросы по ним в формате чат-бота. Когда я начинал пост, в блоге было 223 статьи, что открывает большой простор для кросслинковки. Хочу, чтобы помощник подсказывал, на какие из предыдущих статей блога я могу сослаться в новой. Было бы здорово получать тематические подборки статей, что мы иногда добавляем в анонсы связанных митапов. Еще какие-нибудь сценарии я, наверно, придумаю на ходу.

Другая задача, как мне кажется, будет сложнее — аналитика в разрезе тем и других атрибутов статей, особенно качественных, а не количественных. Но не буду грустить заранее: это пет-проект, take it easy. К тому же в итоге получилось наоборот: именно в качественных, а не количественных вопросах прогресс чат-бота оказался заметнее.

Создаю новый диалог с GPT-4o и закладываю в нее требования. Нейросеть бодро предлагает несколько вариантов реализации.

GPT-4 + LangChain (или ChatGPT API с RAG). «Минусы: платно (и затраты могут вырасти при больших объемах)». Тот же минус — и в варианте «решения под ключ (SaaS-инструменты): writer.com, jasper.ai, copy.ai». А есть что-нибудь на open source?

Да, причем это был первый вариант в списке: open-source LLM + векторная база (например, LLaMA 3 + FAISS / Weaviate / Qdrant). При сравнении трех опций GPT даже подчеркнул преимущества этой: «максимальная точность, контроль, гибкость». Честно говоря, ожидал от OpenAI больше саморекламы, приятно удивлен. Давай остановимся на open source, но смогу ли я осилить это в одиночку?

«Да, ты вполне можешь создать такую систему сам, особенно если у тебя есть базовые навыки Python и немного понимания в работе с API или веб-разработке». Два года назад я прошел базовый месячный курс по Python. С веб-разработкой все точно не лучше, а с API… в общем, здесь уже только вера в себя осталась.

Редактор блога YADRO Николай Землянский создал локального ИИ-помощника, который анализирует статьи на Хабре, выделяет темы и делает подборки со ссылками. Что получилось в MVP и как будет развиваться проект — читайте в статье.

Как роботы стали частью культуры — и почему это важно сегодня

Мы привыкли думать о роботах как о технологиях будущего. Но на самом деле им уже больше 2 тыс. лет — по крайней мере, как идее. Механические существа появляются еще в мифах Древней Греции: автоматоны Гефеста, живые статуи и железные помощники — первые прообразы современных роботов.

Что изменилось с тех пор? Почему человечество так настойчиво мечтало о разумных машинах? И как художники, философы, писатели и инженеры вместе формировали наш образ «искусственного человека»? Ответы на эти вопросы — в лекциях YADRO Lectorium от экспертов Сколтеха, «Иннополиса» и Музея криптографии.

«Спросите любого робототехника, как он пришел в профессию — он вспомнит не тему своего диплома, а первую игру, первый конструктор, первый мультик про роботов», — Егор Ефремов, культуролог, историк техники, исследователь в Музее криптографии.

В статье собраны лекции YADRO Lectorium — о культурной эволюции образа робота, текущем состоянии и трендах в мировой робототехнике, а также о том, как физический дизайн влияет на функциональность и взаимодействие человека с машиной.

Сервер издает повторяющиеся звуки при включении. Что не так?

Если вы специалист технической поддержки или хотите им стать — проверьте свои знания, пройдя квиз по работе с IT-инфраструктурой. Десять вопросов, 20 секунд для размышления над каждым. А в конце, если это актуально, — возможность поучаствовать в спринт-оффере и получить приглашение на работу в YADRO всего за 3 дня.

Пройти квиз до 6 июля → 

Какие задачи ждут специалиста техподдержки в YADRO? Короткий ответ: интересные и разнообразные.

А подробнее — рассказывают сами инженеры. Смотрите запись митапа (или на YouTube) для специалистов техподдержки. Вы узнаете:

→ Какие направления сервисной службы YADRO существуют.

→ Какие возможности для развития предоставляют продукты компании.

→ Как команда L1-поддержки системы хранения данных TATLIN.UNIFIED решает сложные задачи.

Control Plane и User Plane в мобильной связи: зачем нужны два типа трафика и как они работают

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

На ней держится все: авторизация пользователей, выдача IP-адресов, маршрутизация трафика, подсчет минут и гигабайт, подключение сервисов и связь между базовыми станциями и внешним интернетом. Все, что выходит за рамки простого «поймать сигнал», — уже ее зона ответственности.

Физически между базовой станцией и опорной сетью проходят два потока:

• Control Plane — управляющий трафик. Отвечает за процедуры подключения к сети, аутентификации, переключения между станциями, сессий и т. д.

• User Plane — пользовательский трафик. Это все, что идет от приложений пользователя: стриминговые сервисы, мессенджеры, браузер и так далее.

Они разделены как логически, так и физически. Такой подход нужен, чтобы обеспечивать надежность, безопасность и гибкость.

В статье Елена Степанова, ведущий инженер-программист в YADRO, объясняет, чем опорная сеть отличается от базовой станции, зачем в 5G сотни микросервисов и как устроена архитектура мобильной связи.

Можно ли развернуть кластер Kubernetes на процессоре с открытой архитектурой RISC-V?

Короткий ответ: нет.

К сожалению, на данный момент «классический» K8s неполноценно портирован на RISC-V. Один из необходимых модулей K8s — kubelet — отказался запускаться на RISC-V-машине (в роли нее — микрокомпьютер Lichee Pi 4A).

Зато облегченная версия оркестратора K3s и Docker Swarm заработали на RISC-V, но с разными компромиссами:

→ Docker Swarm проще в развертывании.

→ K3s — более гибкий в работе, так как поддерживает Kubernetes-инструменты.

В синтетических тестах (stress-ng) K3s показал лучшую производительность на матричных вычислениях — он обошел показатели Docker Swarm примерно в 16 раз. В цифрах: 2.996 bogo ops/s (K3s) против 188 bogo ops/s (Docker Swarm). Возможно, это связано с оптимизацией Kubernetes или меньшими накладными расходами: K3s потребляет меньше ресурсов на фоновые процессы, такие как управление кластером и сетью, что важно для маломощных устройств.

Интересно узнать больше? Тогда переходите по ссылке и читайте подробности экспертимента по заапуску известных оркестраторов на RISC-V.

Какую информацию содержит FRU EEPROM и как с ней работать

Набор возможных данных, хранимых во FRU EEPROM, определяется спецификацией Intel IPMI FRU Information Storage. Вся информация разделена на пять областей, присутствие каждой из которых не обязательно и определяется информацией в общем заголовке FRU EEPROM, где размещены указатели на данные каждой из них в следующем порядке:

1. Область для внутреннего использования (Internal Use Area) — ее
содержимое не описано спецификацией. Предполагается, что эта часть EEPROM может использоваться программным обеспечением BMC или другого контроллера на плате для хранения какой-то служебной информации (например, внутренних состояний).

2. Область информации о шасси (Chassis Information Area) — здесь содержится базовая информация о «корпусе» или «шасси» устройства, описываемого этим FRU EEPROM. Основным параметром тут является «тип шасси», который представляет собой целое число, выбираемое согласно спецификации SMBIOS (см. DMTF DSP0134, Table 17). Например, значение 0x17 соответствует типу «Rack Mount Chassis». Также в этой области может содержаться информация о серийном номере шасси и его артикуле (part number).

Создатели спецификации предполагали, что эта область присутствует на главной плате всего изделия и на любых корпусированных компонентах, таких как блоки питания или дисковые накопители, но не все производители и не всегда придерживаются этого правила.

Какие еще есть области во FRU EEPROM, и как утилита frugen и библиотека libfru помогают с ними работать — читайте в статье Александра Амелькина, технического эксперта департамента разработки BIOS и BMC в компании YADRO, а также автора и мейнтейнера проекта frugen / libfru.

От механики до цифровой эпохи: шифровальная техника XX века

Музей криптографии представляет коллекцию из 39 единиц шифровальной техники, полученной по распоряжению Правительства РФ. Это рассекреченные образцы отечественных криптографических устройств, созданных с 1950–1960-х годов до начала 2000-х.

Некоторые экспонаты сохранились в рабочем состоянии — у них полностью сохранены внутренние модули. У других рассекречена только внешняя часть (корпус), а секретные модули удалены, поэтому они уже не функционируют. Несмотря на это, каждый из них — уникальное свидетельство технологической истории.

Особое внимание привлекает Kryha Liliput — шифровальное устройство в форме карманных часов, созданное в 1924 году. Более ста лет спустя оно поражает как техническим исполнением, так и эстетикой промышленного дизайна.

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

Процессор на RISC-V есть в Google Pixel 6. А когда в ноутбуках появится?

В 2024 году в продаже появились устройства с поддержкой векторного расширения RVV 1.0. RISE опубликовала гайд по оптимизации на RISC-V, провела адаптацию программных компонентов, запустила бонусную кампанию для разработчиков, портирующих на RISC-V. Canonical заявила, что с версии 25.10 ОС Ubuntu будут собирать под профиль RVA23. А Samsung продемонстрировала телевизор на RISC-V с Tizen.

Сейчас для RISC-V прорабатывают множество новых исследовательских идей и дальнейших расширений. Например, расширение формата команд до 48 и 64 бит, что в некоторых случаях поможет повысить эффективность архитектуры. За счет поддержки новых размеров констант, immediate-операндов и других нововведений в перспективе можно будет уменьшить размер кода. Развивается безопасность векторных расширений, а также расширенное профилирование для анализа сложных приложений, стеков и ПО.

Текущие наработки войдут в профиль RVA30, который, по всей видимости, станет следующим в развитии стандарта. На пути к этому большому обновлению увидит свет ABI для AOSP, а также платформы, определяющие дополнительные требования — например, в серверных сценариях.

Если выяснится, что в RVA23 не хватает каких-нибудь важных обязательных расширений, то придется выпускать новый major-профиль с ними раньше, чем хотелось бы. По пути к нему увидят свет и minor-профили: они содержат только опциональные расширения и не создают проблем с совместимостью.

На пятом митапе Российского Альянса RISC-V и YADRO эксперты в сфере RISC-V — Сергей Якушкин, Роман Хатько и Антон Афанасьев — обсудили успехи и перспективы RISC-V на рынке мобильных устройств в середине 2025 года.

Обучение модели GPT-2: часы вместо недель

Для тестирования GPU-сервера YADRO G4208P G3 в конфигурации с восемью Н100 NVL / RTX 4090 мы выбрали бенчмарк на основе реализации обучения для модели GPT-2 на 1,558 миллиарда параметров из репозитория проекта llm.c Андрея Карпаты. 

Эта модель была представлена OpenAI в блоге Better Language Models and Their Implications в феврале 2019 года. Тогда для ее обучения требовались команда инженеров и десятки топовых V100, а процесс длился неделями.

Сейчас, шесть лет спустя, достаточно одного сервера с восемью картами H100, а обучение занимает 1–1,6 суток. Все это благодаря развитию GPU, современным библиотекам, таким как CUDA и cuDNN, а также открытым датасетам типа FineWeb-Edu. 

Андрей Карпаты показывает, что это возможно даже без фреймворков вроде PyTorch или TensorFlow. Все обучение реализовано примерно в 5 тысячах строк на C и CUDA. 

Мы проверили, как справляются серверы YADRO c обучением GPT-2 на 1,6 миллиарда параметров. Обучение на конфигурации G4208P с восемью H100 NVL заняло 38 часов, или примерно 1.6 суток. На графике ниже показываем соотношение времени исполнения 50 шагов обучения на конфигурации G4208P с RTX 4090 по сравнению с конфигурацией на Н100 NVL: 

Артём Маклаев с командой, которая занимается оценкой производительности серверных платформ для ИИ-задач в YADRO, поделился в статье результатами десятка тестов GPU-сервера с 8x Н100 NVL / RTX 4090: от инференса моделей распознавания речи до обучения LLM.

Осваиваем азы компьютерного зрения с библиотекой Pillow на одноплатном компьютере Lichee Pi 4A

Наш первый шаг — загрузить изображение, определить его цветовую модель и получить информацию о размере и границах.

from PIL import Image
from PIL import ImageFilter
img = Image.open(“flower.jpg”)
print(img.size, img.format, img.mode)

Эта базовая информация пригодится для дальнейшей работы с изображением.

Меняем цвет пикселя

К отдельным пикселям можно обращаться с помощью метода load() из библиотеки Pillow. Так мы сможем изменять цветовые значения точечно, а это основа для различных операций по обработке изображений.

Открываем white.jpg с помощью Pillow:

from PIL import Image
img = Image.open("white.jpg")
obj = img.load()

Выбираем пиксель с координатами (25, 45) и меняем его цвет:

obj[25, 45] = (0, 0, 0)  # Новый цвет: черный (RGB: 0, 0, 0)

Сохраняем отредактированное изображение:

img.save("image3.jpg")

Визуально проверяем, что цвет пикселя изменился. 

Метод load() позволяет напрямую работать с массивом пикселей изображения: читать, модифицировать и анализировать отдельные элементы, не копируя данные в отдельные структуры. Это особенно важно для задач, которые требуют высокую производительность при обработке больших изображений.

Почему был выбран Lichee Pi 4A, как создать виртуальное окружение Python, установить подходящую среду разработки и научиться базовым приемам работы с изображениями — читайте в подробном туториале.

Как не потерять важные проверки в долгих тестах: soft-assert на практике

В длительных системных тестах, особенно для систем хранения данных, важна не только проверка, но и устойчивость самого теста. Обычные assert в Python останавливают выполнение при первой ошибке, что неприемлемо для многокомпонентных и продолжительных тестов, где важно собрать максимум информации о сбоях.

Решение — использовать soft-assert, которые не прерывают выполнение. В команде мы используем Pytest плагин pytest-check, которая позволяет писать soft-assert через контекстный менеджер with check. Это дает возможность:

• продолжить тест даже при частичных ошибках,

• собрать диагностику по множеству компонентов (например, контроллеры, кэши, пулы),

• минимизировать потери времени при дорогостоящих прогонах.

Пример soft-assert с pytest-check:

from pytest_check import check


def object_stack():
    pool_stack = ExitStack()
    yield pool_stack
    for host in hosts:
        with check:
             result = None
             try:
                PoolsService.get_pools_info(host)
             except HostUnavailableException as err:
                result = err
             assert not issubclass(type(result), HostUnavailableException), f'Failed to get pool: {result}'

Soft-assert полезен, когда нужно получить статус всех компонентов, несмотря на сбои отдельных, одна ошибка не делает тест недействительным и тест длится часами и его повтор — затратен.

Однако soft-assert не заменяет критические проверки — в местах, где сбой должен останавливать выполнение, следует использовать assert.

О том, как устроен процесс проверки надежности СХД TATLIN.UNIFIED, рассказала Наталья Грязнова, ведущий инженер по разработке ПО в YADRO. В тексте она делится подходами, которые позволяют комплексно проверять работу систем в разных условиях — от сверхнагрузок до нестабильной среды.

Как подход Docs-as-a-code применили в создании документации для TestY TMS

Команда разработки системы управления тестами TestY объединилась с командой технических писателей, чтобы создать удобную документацию.

Для ведения документации выбрали подход Docs-as-a-code. Документация хранится вместе с кодом приложения. Для написания и сборки использовали более-менее классическое сочетание: rST-формат в связке со Sphinx. 

Инженеры уверены, что такой вариант предоставляет большую гибкость, чем стандартный MD. К тому же,  rST в связке со Sphinx — стандарт документации для open source-проектов.

Разработчики поддерживают документацию в актуальном состоянии, поэтому рассчитывают, что в дальнейшем любое изменение текущей функциональности, как и разработка новой, будет сопровождаться обновлением документации. Это будет одним из Definition of Done для реализации фич.

Помимо документации в релизе 2.1 появилась темная тема и другие обновления интерфейса. Читайте о них в статье →

ping: permission denied (are you root?)

Знакомы ли с этим сообщением об ошибке? И знаете ли, как ее исправить?

Этот запрет на отправку ICMP-пакетов внутри контейнера можно получить при выполнении, например, такой задачи.

Задача: Организовать k8s-кластеры в ручном режиме с помощью kubeadm и kubectl на базе cri-o (1.28+) и использовать Calico как CNI-плагин.

Кластер доступен для взаимодействия через kubectl, команда возвращает корректную информацию о кластере. Есть возможность сделать ping 8.8.8.8 с образом busybox.

Если вы опытный DevOps и знаете, как решается эта «детская проблема» при работе с оркестратором, регистрируйтесь на спринт-оффер для девопсов. Сможете буквально играючи получить новую работу за 3 дня.

Если вы только начали изучать Kubernetes, читайте статью с подробным разбором этой ошибки → 

Тайм-менеджмент — это не про управление временем, а про управление силами

Часто мы думаем, что эффективность зависит от грамотного распределения времени. Но даже при четком плане и полном календаре можно чувствовать усталость и неудовлетворенность. Все потому, что в основе продуктивности — не количество часов, а то, сколько сил мы можем вложить в задачи.

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

Планируйте по энергии, а не по времени. Спрашивайте: «Сколько сил потребует эта задача?», а не «Сколько времени она займет?».

Оставляйте паузы на восстановление. После эмоционально или интеллектуально тяжелых задач — делайте перерывы.

Попробуйте в течение двух недель вести простой дневник состояния. Записывайте туда:

• что делали,

• сколько времени ушло,

• как чувствовали себя после — энергично, нейтрально или вымотано. Это поможет выявить личные ресурсоемкие зоны.

Закладывайте запас времени. Добавляйте 15–30 минут к каждой задаче. Особенно важно для новых или сложных задач.

Планируйте перерывы осознанно. Обед и отдых — полноценные пункты в расписании. При необходимости — дайте им «рабочие» названия.

Рефлексируйте ежедневно. Удалось — зафиксируйте. Не получилось — сделайте выводы и двигайтесь дальше.

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

В статье Валерия Зелёная, старший менеджер по развитию образовательных программ в YADRO и автор Telegram-канала о ментальном здоровье, разбирает, почему мы на самом деле устаем и как почувствовать себя лучше.

Data-класс вашей ошибки: как относиться к ошибкам как программист

Ошибки можно рассматривать как задачи, которые возникли в ходе решения другой таски. Только, как правило, с экстремально короткими сроками выполнения и большим потоком информации. И входишь ты в этот поток не с самым высоким уровнем мотивации и возможным давлением.

Чтобы убрать эмоции из анализа ошибки и подойти к ней с «трезвой» головой, можно разложить ее как код. Вот, например, какой data-класс можно выделить у ошибки:

class Error {
  // что нужно было сделать
  var task
  // что пошло не так
  var errorDetails
  //какие возможные последствия уже есть или последуют и кто может пострадать
  var effect
  //причины ошибки
  var reasons
  //плюшки от решения сложившейся ситуации
  var benefits
  //выводы
  var experience
 //список улучшений, которые можно сделать, чтобы минимизировать повторение ошибки
  var actionItems
 }

А теперь — реализация.

Пример: Вы неверно оценили сроки выполнения целого скоупа задач, входящих в MVP для приложения Сообщения — ошиблись на целых два релиза. Никто не пострадал, но ситуация по многим аспектам неприятная.

Как бы выглядела реализация интерфейса для данного случая:

class BadEstimationForMVPMessaging {
  
  var task = эстимация MVP для приложения Сообщения. Необходимо оценить все задачи, распределить по спринтам и релизам, учесть загрузку команды и выдать предполагаемую дату релиза
  
  var errorDetails = ошибка в эстимации на два релиза (два месяца разработки команды из трех человек)
  
  var  effects = listOf(
  - релиз переносился два раза
  - демотивация команды
  - вопросы с продуктовой стороны
  )
  
  var reasons = listOf(
  - часть задач были сильно недооценены
  - не учтены зависимости, которые, конечно, вылезли только в конце
  - не заложен запас по времени
  )
  
  var  benefits = listOf(
  - хороший пример, который можно разобрать
  - прокачан навык работы с ожиданиями
  - ощутили дух стартапа с командой, решая внезапные блокеры перед релизом, и радовались запуску приложения
  )

  var experience = listOf( 
  - детальнее искать зависимости на этапе подготовки к эстимации
  - закладывать запас по времени в 2-3 релиза
  - на задачи с неизвестными апишками и стеком увеличивать коэффициент Пи*
  )
  
  var actionItems = listOf(
  - составить чек-лист для подготовки к запуску новых приложений, на который можно ориентироваться всем командам
  - обсудить с командой процесс выявления зависимостей
  )
 
}

Смотреть на ошибки так гораздо эффективнее. Вы выносите из них уроки, а не просто посыпаете голову пеплом. Попробуйте!

А больше лайфхаков по построению здоровой культуры ошибок в жизни и на работе читайте в подробной статье от Марии Киселевой, тимлида команды разработки мобильных приложений для KvadraOS в YADRO → 

Как защитить данные без полных бэкапов: разбираем косвенную адресацию в СХД

Мгновенный снимок (снапшот) — это компактная с точки зрения дискового пространства копия данных, созданная в определенный момент времени. Снапшот способен моментально зафиксировать состояние тома, в отличие от резервной копии, создание которой при большом объеме данных может занять длительное время и требовать остановки записи для сохранения консистентности. Снапшот же не создает независимую копию данных, а лишь обеспечивает возможность обратиться к данным тома на момент создания снапшота.

В TATLIN.UNIFIED снапшоты создаются путем копирования карты блоков данных оригинального тома. Сами данные не копируются, поэтому снапшоты создаются очень быстро и не занимают дополнительного места в области данных.

Со временем в родительском томе заполняются новые блоки данных. Некоторые данные у родительского тома и снапшота начинают различаться, но данные, на которые уже ссылается снапшот, не перезаписываются и не освобождаются. Оригинальный физический блок данных считается занятым до тех пор, пока снапшот, который на него ссылается, не будет удален. После удаления снапшота блоки данных, которые он не разделял с другими ресурсами, освобождаются и могут быть использованы для последующих операций записи. Такой вариант реализации снапшотов называют Redirect-On-Write (RoW).

В своей статье Алексей Шушарин, главный эксперт по разработке ПО в департаменте СХД YADRO, подробно рассказал о снапшотах, клонах и всех процессах, связанных с косвенной адресацией. А также о том, как грамотно вписать эту функциональность в стек хранилища.

Три дня, чтобы начать поддерживать инфраструктуру для базовых станций GSM/LTE

Это baseband-модуль (BBU) базовой станции, которую разработала команда Телеком в YADRO, и мы ищем DevOps-инженеров, которые к ней присоединятся. Таким специалистам нужно будет поддерживать процессы разработки (на С/С++, Go, Node.JS), развивать CI/CD и улучшать качество внутренних сервисов.

Узнать, как стать DevOps-инженером в YADRO → 

DevOps-специалистов разного уровня — от junior до senior — мы ждем по двум направлениям.

Infrastructure

Задача DevOps-инженера здесь — поддерживать бесперебойную работу инфраструктуры для разработки в телекоме. А это более 600 виртуальных машин, 20 информационных систем и десятков внутренних сервисов. Эта работа не просто про администрирование серверов, но и про автоматизацию работы и масштабирование инфраструктуры.

CI/CD

Специалисты по этому направлению организуют разработку и выпуск программно-аппаратных решений в сфере телекоммуникаций — с использованием Gitlab CI. Ежедневно они востребованы у более тысячи разработчиков и тестировщиков телекома. Цель DevOps-команды — сделать удобным процесс доставки изменений от разработчиков до продукта, а также постоянно улучшать и оптимизировать существующие решения, внедрять Observability для текущих продуктов, создавать новые инструменты.

Условия быстрого оффера

Подайте заявку на лендинге до 8 июня. Далее с вами свяжется рекрутер, чтобы обсудить общие вопросы и назначить интервью. После вы пройдете техническое интервью и интервью с менеджером, а в случае успеха получите оффер в компанию. Весь процесс займет 3 дня.

Больше про спринт-оффер и описания требований к специалистам — по ссылке.

Генерация последовательностей случайных чисел с помощью DRAM — возможно ли это? Проверим с помощью RISC-V

На основе DRAM мы создали модель одноканального источника шума, который возвращает один случайный бит за один условный такт. Память разбита на два региона, которые не пересекаются. Первый отвечает за инициализацию одноканального сигнатурного анализатора (ОСА), который инициализирует второй подобный анализатор. Затем мы сможем взять другой регион памяти и заново инициализировать первый ОСА, что абсолютно случайным образом изменит выход второго ОСА. Такая схема позволит не перезагружать память после каждой генерации числовой последовательности — ведь в реальных проектах это, как правило, невозможно. 

Далее мы направляем данные из DRAM PUF в два подмодуля — постобработки, а также тестирования, анализа и оценки качества данных. Первый частично запускается на «железе», второй — на собранных данных на машине хоста.

Для постобработки мы протестировали шесть комбинаций. Последняя нам кажется наиболее перспективной:

• сырые данные,

• чистый корректор фон Неймана,

• одноканальный сигнатурный анализатор,

• чистый корректор фон Неймана + одноканальный сигнатурный анализатор,

• одноканальный сигнатурный анализатор + чистый корректор фон Неймана,

• многоканальный сигнатурный анализатор (МСА).

Зимняя школа RISC-V дала начало множеству интересных проектов. В отдельной статье мы рассказали об одном из них, где команда из БГУИР проверила гипотезу о наличии PUF в динамической памяти и создала модель одноканального источника шума. А затем реализовала постобработку и тестирование, измерила производительность генератора и оптимизировала код.

Isar и еще 8 систем сборки для создания дистрибутива на Linux

Isar — система сборки, представляющая собой набор скриптов для создания пакетов и дистрибутивов на базе Debian с возможностью настройки. Организация проекта Isar похожа на Yocto Project, для сборки используется Bitbake.

Перед сборкой можно настроить параметры файловой системы, ядра, модификации списка пакетов (добавление и удаление пакетов, в том числе и собственных, изменение существующих пакетов). Систему сборки разрабатывает компания ilbers GmbH.

Архитектура системы

Так как Isar основан на Bitbake, архитектура решения состоит лишь в нескольких слоях для Bitbake, реализующих сборку и установку пакетов в соответствии с конфигурацией сборки. В основе всех этих слоев и рецептов лежат утилиты Debian Build Toolchain, которые ответственны за непосредственную сборку пакетов, разрешение зависимостей и т.д.

Особенности решения

• Аналогично Yocto требует усилий на начальных этапах для освоения инструмента.

• Поддерживает загрузку готовых пакетов из репозиториев Debian.

• Подходит для embedded-дистрибутивов, где необходимо сочетание Debian-экосистемы и глубокой конфигурации.

О других embedded- и desktop-решениях решениях рассказали студенты и преподаватели СПБГЭТУ «ЛЭТИ» в обзоре систем для создания Linux-дистрибутивов.