В данной статье пойдёт речь об особенностях UEFI на примере переноса Debian Stretch с MBR на UEFI. Опишу так же разницу между MBR и UEFI, так как я её воспринимаю.

Кроме общей части, ключевая часть статьи про формирование GRUB EFI файла grubx64.efi во время grub-install и про то, что этот файл не так прост, как кажется на первый взгляд.

Здраствуйте меня завут Дмитрий. Как-то я купил OpangePI i96, но к сожалению производитель давно забыл об этой плате, прошивки для неё построены на ядре 3.10.62(актуальная версия на момент написаня статьи 6.5.1). Поэтому я решил собрать собственную прошивку на актуальной версии ядра. Сборка будет проходить полностью из исходников.

SWUpdate — это агент обновлений Linux, целью которого является эффективный и безопасный способ обновления встроенной системы. SWUpdate поддерживает локальные и удаленные обновления, включает несколько стратегий обновления, и его можно легко интегрировать в систему сборки Yocto, подключив слой meta-swupdate.

В статье описывается как можно настроить режим обновление в Yocto наиболее простым способом для платы Orange Pi R1, таким же образом вы можете настроить и обновление для самой распространенной платы Raspberry Pi.

Дистрибутив Yocto для которого будет подготовлено обновление наследуется от образа core-image-minimal и выполняет функцию простого маршрутизатора, используя DHCP и Shorewall.

Статья из серии: если хочешь что то обновить, сделай это сам.

Linux Kernel — это, пожалуй, один из самых распространённых (и, возможно, до сих пор недооценённых) программных продуктов в мире. Он является основой всех дистрибутивов Linux (что очевидно), но на этом его роль не заканчивается. Ядро также работает на множестве встроенных устройств практически повсюду. У вас есть микроволновка? Скорее всего, она работает на ядре Linux. Посудомоечная машина? Тоже. Если у вас достаточно средств на автомобиль Tesla, вы даже сможете найти несколько багов, исправить их и отправить патч в код Model S или Model X на GitHub. А что насчёт схем, которые не позволяют Международной космической станции сойти с орбиты и врезаться в Землю? Конечно, и там тоже Linux. Ядро легковесное — значит, отлично работает даже в условиях невесомости.

В этой статье напишем свой первый модуль ядра под Linux

В этом посте разобраны некоторые фокусы, причуды и фичи языка C (некоторые из них – весьма фундаментальные!), которые, казалось бы, могут сбить с толку даже опытного разработчика. Поэтому я потрудился сделать за вас грязную работу и (в произвольном порядке) собрал некоторые из них в этом посте. Примеры сопровождаются ещё более вольными краткими пояснениями и/или листингами (некоторые из них цитируются).

Конечно же, здесь я не берусь перечислять абсолютно всё, так как факты из разряда «функция nan() не может устанавливать errno, поскольку в определённых ситуациях поведёт себя как strtod()» не слишком интересны.

ВНИМАНИЕ: сам факт попадания тех или иных вещей в эту подборку  не означает автоматически, что я рекомендую или, наоборот, не рекомендую ими пользоваться! Некоторые из приведённых примеров никогда не должны просачиваться за пределы списков наподобие этого, тогда как другие примеры невероятно полезны! Уверен, что могу положиться на ваш здравый смысл, дорогие читатели.

В мире программирования создание собственных библиотек — это не просто возможность пополнения своего портфолио или способ структурировать код, а настоящий акт творческого самовыражения (и иногда велосипедостроения). Каждый разработчик иногда использовал в нескольких своих проектах однообразный код, который приходилось каждый раз перемещать. Да и хотя бы как упаковать свои идеи и знания в удобный и доступный формат, которым можно будет поделиться с сообществом.

Если вы ловили себя на мысли: ‭«А почему мне бы не создать свою полноценную библиотеку?‭», то я рекомендую прочитать вам мою статью.

Эту статью вы можете использовать как шпаргалку для создания проектов, и не только библиотек.

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

По мере распространения Go и Rust появляется всё больше программ, которые состоят из одного бинарника без каких-либо нестандартных зависимостей, и которые мы устанавливаем руками, скачивая релиз с GitHub: либо потому, что данного приложения ещё нет в вашем дистрибутиве, либо потому, что просто хочется всегда иметь актуальную версию, а не ждать, когда её затянут в дистрибутив.

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

Однажды, выполнив в Гугле запрос "Three body problem" ("Задача трёх тел"), я был просто поражен - первая страница результатов состояла только из ссылок на роман китайского писателя-фантаста Лю Цысиня с соответствующим названием, а также на телесериал, снятый по этому роману, т.е. ссылок на собственно задачу трёх тел не было вообще! Мне это показалось удивительным и несправедливым, поскольку сама по себе задача трёх тел тоже может выглядеть увлекательной в популярном изложении. В этой публикации я постарался привести некоторые доказательства этого утверждения.

Все мы понимаем, что рано или поздно кремниевая технология, используемая сегодня для создания процессоров, достигнет своего предела. Это как с нефтью – рано или поздно она закончится – вот поэтому уже сейчас начинают разрабатывать альтернативные энергетические технологии! Точно такая же ситуация сложилась и в мире информационных технологий – кремниевой технике начинают искать замену. Бегущие по проводникам, как танки, электроны довольно непрактичны – как минимум теряется значительная часть их энергии, выделяясь в виде тепла и электромагнитного излучения, хотя это не единственный минус. Причем на рассмотрение предлагаются абсолютно разные варианты замены – от биокомпьютера до оптических процессоров. Стоп! А что это такое? Вряд ли у каждого из нас на столе, скажем, через десять лет будет стоять компьютер из бактерий, а вот то, что в компьютере будущего будет установлен оптический процессор – вполне реально. Сегодня мы поговорим об этом чуде рук человеческих.

Рассмотрим преимущества оптической технологии:

· Можно параллельно передавать двумерные массивы за один световой импульс.

· Возможность использования совершенно разных сред передачи, хранения и обработки информации.

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

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

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

Статья предполагает, что читатель имеет базовые знания программирования bare-metal систем и языка С++, в том числе и современных стандартов. Это означает, что совсем базовые пояснения выходят за рамки этой статьи.

В данной статье я рассмотрю подключение утилиты dfu‑util, написанную на языке С, к С++ проекту на CMake в виде сабмодуля.

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

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

* Превью сгенерировано с помощью Adobe Firefly

Лупхолы — это техника, позволяющая манипулировать глобальным состоянием компилятора, добавляя значения и считывая их.

Эта техника позволяет решать многие задачи, некоторые из которых будут рассмотрены в статье:

Узнать, какие параметры принимает конструктор типа.

Узнать, с какими шаблонными параметрами вызывался метод/функция с ADL.

Как сделать метапрограммирование с типами более похожим на обычный код, где есть состояние.

Думаю, у каждого программиста есть набор любимых утилит, трюков и знаний. Некоторые он даже использует в работе. Скорее всего, у разных программистов они различаются. Значит, пришло время поделиться. Сегодня я расскажу о своей подборке того, что, вероятно, известно не настолько широко, как оно того заслуживает. Речь пойдёт преимущественно про платформу GNU/Linux.

Или почему мне кажется, что про них нужно знать, но не нужно использовать в своей каждодневной работе.

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

Допустим, у нас есть массив чисел с плавающей запятой, и мы хотим их суммировать. Можно наивно подумать, что их достаточно просто сложить, например, на Rust.

Однако это запросто может привести к произвольно большой накопленной погрешности. Давайте проверим:

naive_sum(&vec![1.0; 1_000_000]) = 1000000.0
naive_sum(&vec![1.0; 10_000_000]) = 10000000.0
naive_sum(&vec![1.0; 100_000_000]) = 16777216.0
naive_sum(&vec![1.0; 1_000_000_000]) = 16777216.0

Ой-ёй… Что произошло? Проблема в том .что следующее 32-битное число с плавающей запятой после 16777216 — это 16777218. Так что при вычислении 16777216 + 1, значение округляется до ближайшего числа с плавающей запятой, имеющей чётную мантиссу, то есть снова до 16777216. Мы зашли в тупик.

К счастью, есть более совершенные способы суммирования массива.