На примерах попробую показать, почему enum в Rust это несколько больше, чем обычно принято считать. Рассмотрю расширенное использование enum в типовых ситуациях. Сразу забегая вперед скажу, что в рамках статьи я не затрагиваю паттерны и мэтчинг.
Первое, что приходит в голову, когда речь заходит об enum, — это идея: «А давайте заменим все константы на enum». :) Желание логичное, давайте на него посмотрим...
При разработке драйверов GPIO для нашей операционной системы реального времени "Нейтрино" исторически имеется одна неприятность — отсутствие общего дизайна для таких драйверов. Причин для этого несколько: они считались и считаются тривиальными, разрабатывают их разные организации и разработчики. Из-за этого каждый инженер нередко писал реализацию «под себя»: кто-то в виде сервиса, кто-то даже в виде статической библиотеки. Такой подход, хоть и кажется удобным на первых этапах, со временем приводит к фрагментации кода, усложнению поддержки и невозможности систематизировать накопленный опыт. Чтобы избежать этих проблем в будущем мы решили перейти на унифицированную подсистему управления GPIO устройствами и выработать подход, который будет считаться best practices в нашей ОС.
Доводилось ли вам раскупоривать системник с Linux, который не грузится ни в какую – даже после того, как вы убедились в корректности настроек BIOS и в том, что никаких серьёзных аппаратных ошибок в машине нет?
Если да – то вам просто необходимо изучить chroot. Он станет для вас настоящей палочкой-выручалочкой.
Например, мне пару недель назад удалось таким методом восстановить устройство Nanopore GridION, после того, как мне совершенно не помог официальный метод переустановки через .iso-файл образа. Поэтому я решил задокументировать проделанные шаги.
Этот метод я нащупал только после того, как Linux более десяти лет был моей рабочей лошадкой (спасибо, Мэтт !). Поэтому у меня есть основания полагать, что этот метод очень полезен и заслуживает вашего внимания. Надеюсь, этим постом мне удастся помочь тем, кому не доставало такого рассказа.
За всю свою работу инженером-программистом в области разработки встраиваемых систем, а это более 15 лет, мне ни разу не приходила в голову идея спросить у своего руководителя о том, что мне нужно сделать для того, чтобы перейти с одной категории на другую. Всё что я делал, это решал поставленные перед мной задачи разного характера. Интерес был именно в решении задач, а не в получении категорий. Категории как-то сами по себе назначались…
А как собственно они назначаются? По каким критериям? Что ожидается от инженера-программиста на каждом этапе его становления — от джуна до сеньора? Тема весьма дискуссионная, и не тривиальная. В этой статье не будет количественных критериев, но мы постараемся описать все этапы становления инженера-программиста, как некий ориентир для подрастающего поколения специалистов.
Однажды на работе техлид порекомендовал мне проштудировать книгу Understanding the Linux Kernel Бове и Чезати. В ней рассмотрена версия Linux 2.6, сильно не дотягивающая до более современной версии 6.0. Но в ней явно ещё много ценной информации. Книга толстая, поэтому на её изучение мне потребовалось немало времени. Занимаясь по ней, я решил настроить такую среду разработки, в которой я мог бы просматривать и изменять новейшую версию ядра Linux — чтобы было ещё интереснее.
Есть и другие статьи, в которых рассказано, как собрать ядро Linux. Но в этой статье я немного иначе организую и подаю информацию.
Ну блин короче :-)
Знаете ли вы, куда уходит время и ресурсы при сборке проектов на Java? Сейчас покажем и расскажем, как сберечь время, нервы и кофе.
Мы ускорили javac вдвое и теперь можно экономить на сборке.
ГОСТ Р 56939-2024 описывает общие требования к процессам разработки безопасного ПО – от образования, до технической поддержки, от статического, до динамического анализа, однако особое внимание уделяется определению поверхности атаки, то есть поиску множества потенциально уязвимых функций и модулей ПО, занимающихся обработкой пользовательских данных или чувствительной информации, а также интерфейсов, через которые эти данные поступают.
Обычно поверхность атаки определяют экспертным методом, однако тут же возникает вопрос полноты этого метода: что если эксперт пропустил действительно важные функции, участвующие в обработке данных, поскольку ПО имеет распределенную архитектуру, за потоком данных которой очень сложно следить извне, или выбрал такие функции для фаззинга, которые даже не задействованы при обработке пользовательских данных? Какие тогда функции выбирать?
Эта статья — не о вечной молодости и не про биохакинг. Это — живая техническая ретроспектива о том, почему некоторые программисты становятся сильнее с возрастом, а не наоборот. Как меняется восприятие кода после 40? Почему опытный разработчик способен «разруливать» архитектурные адские кухни там, где молодёжь сгорает на ревью? И при чём тут ассемблер, собаки и JavaScript? Ответы — внутри.
Команда Rust рада сообщить о новой версии языка — 1.86.0. Rust — это язык программирования, позволяющий каждому создавать надёжное и эффективное программное обеспечение.
Если у вас есть предыдущая версия Rust, установленная через rustup, то для обновления до версии 1.86.0 вам достаточно выполнить команду:
$ rustup update stableЕсли у вас ещё не установлен rustup, вы можете установить его с соответствующей страницы нашего веб-сайта, а также посмотреть подробные примечания к выпуску на GitHub.
Если вы хотите помочь нам протестировать будущие выпуски, вы можете использовать канал beta (rustup default beta) или nightly (rustup default nightly). Пожалуйста, сообщайте обо всех встреченных вами ошибках.
В первой части статьи мы рассмотрели общую семантику применения функции в различных языках программирования и реализацию императивного вызова функции в машинном коде в стековом и бесстековом вариантах. Теперь мы рассмотрим теорию и практику реализации императивного вызова функции в модели продолжений (continuations): что такое продолжения, зачем нужны явные и неявные продолжения, как при помощи продолжений реализовать различные используемые в языках программирования управляющие конструкции.
Для многих людей, занимающихся программированием, вызов функции воспринимается практически как синоним передачи управления с сохранением адреса возврата и выделением фрейма памяти в стеке. Это однако, не всегда верно и в практическом, и в теоретическом отношении. О семантике и прагматике вызова функций мы и поговорим в этой статье.
Насколько я понимаю в Гугле 200M+ строчек кода написано на Borgcfg/GCL. Нечто похожее но может быть в меньших масштабах происходит в любой крупной компании. На самом деле эта проблема была решена 40 лет назад Unix хакерами из Bell Labs. Давайте посмотрим как ее можно решить используя только стандартные инструменты Unix.
Сергей Каличев, старший разработчик, Angie Software
Однажды, давным-давно, я наткнулся на одну хорошую статью по разработке переносимого кода и решил её перевести. Когда же это было... ё-моё, в 2008 году, 17 лет назад! Обалдеть, как время летит. Статья называлась "Fighting the Lemmings", автор Martin Husemann. Выложил перевод на LOR. С тех пор много воды утекло и, когда я попытался поискать статью в Интернете, то обнаружил, что ни оригинальной статьи, ни перевода, найти практически невозможно. Перевод ещё сохранился в глубоких закромах OpenNet, а оригинал только в архиве Интернета. Ссылки на PDF-ки тоже протухли и больше не работают. Обидно, это ведь такая нетленка для системщиков. Понятно, что переносимость уже сто раз пережёвана в других статьях и книгах, но тут всё было сконцентрировано и написано доходчиво. При этом актуальность до сих пор не потеряна. Ну а что, собственно, кардинально поменялось в разработке переносимого кода на C с тех пор? Если не обращать внимание на упоминания некоторых архитектур и ОС, которые сейчас, да и во времена перевода, звучат, как придания старины глубокой, то в остальном, обо всех особенностях разработки переносимого кода, описанных в статье, надо помнить и сегодня. Выкладываю текст, как он есть, без каких-либо современных правок.
Для тех, кому удобнее читать в PDF, вот ссылки:
А теперь сама статья.
Мир программирования «многоэтажный»: пока одни разработчики делают приложение для какой-то ОС, другие делают саму эту ОС. Пока одни используют в работе компилятор, другие работают над новой версией этого компилятора.
Мы уже много лет проводим конференции по разработке на самых разных языках, от JS до C++. Но теперь «спускаемся ниже», и в эту субботу впервые проведём конференцию по системному программированию sysconf. Она пройдёт в Москве, но можно участвовать и онлайн.
Продюсером конференции (главным отвечающим за неё человеком) стал Иван Углянский, который сам с головой погружен в мир системного программирования (вы можете помнить его доклад «Один день из жизни JVM-инженера»).
И чтобы Хабр знал, чего ожидать на sysconf, мы задали ему несколько вопросов, а также собрали в этом посте описания всех докладов.
В наши дни общепризнанный стандарт для RTL-описаний — это язык SystemVerilog, но популярность сейчас набирает его альтернатива, Chisel. Далее я расскажу подробней об этом языке, его преимуществах, недостатках и рисках, связанных с переходом на Chisel со стандартного стека. Отдельно остановлюсь на функциональном программировании — возможности Chisel, которой нет в SystemVerilog, — и на дополнительных возможностях Chisel, улучшающих механизм переиспользования модулей. А также о том, почему код на Chisel менее подвержен ошибкам и всегда работает. Ну, почти всегда.
Еще один интересный способ решения проблем с оборудованием в этой замечательной ОС. Будет актуально только «особенным» пользователям, действительно использующим это на ноутбуке.
Эта статья не является прямым продолжение статьи Время собирать пакеты, но затрагивает связанные темы. Учимся создавать артефакты в рамках концепции Инфраструктура как Артефакт. Будем разворачивать Verilator в Kubernetes.
Привет, Хабр. На связи Сергей Пушкарёв, я руковожу отделом разработки BIOS в YADRO. Расскажу об устройстве UEFI и его применении в компании. Мы разрабатываем и выпускаем разные аппаратные платформы: серверы, системы хранения данных, клиентское и телеком-оборудование.
Один из «кирпичиков», который обеспечивает инициализацию и функционирование оборудования, — это BIOS (но правильнее говорить UEFI 🙂). В статье кратко разберем историю этой системы и ее современную реализацию — UEFI. Также поговорим о подходе к разработке и отладке этого ПО в YADRO.
Вы узнаете, зачем нам нужна «синяя коробка» Intel, как мы прошиваем BIOS и проводим диагностику «в полях».
Ядро OpenBSD становится уже очень старым — ну просто очень — ему около сорока пяти лет. Оно, следовательно, не любит сюрпризов. Поэтому программы должны сообщать ему о том, где находятся их системные вызовы. В сегодняшнем выпуске «Вежливого программиста» мы поговорим о том, как это делать по всем правилам этикета.
Если вы программируете на C — всё это делается автоматически. Поэтому мы будем писать код только на языке, который совершенно нельзя назвать C, и при этом обойдёмся без линковки с libc.
Ноутбук засыпает, ноутбук просыпается, батарея «зависает» — более не отдает ни уровень заряда ни другие показатели, вне зависимости от подключения к сети.
Патч ядра Linux и три года изысканий, рассказываю как это было.
