По мере распространения 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. Мы зашли в тупик.

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

Но есть нюанс ...

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

Данные - это важный компонент системы. Приложение может хранить их где угодно, но в результате все сводится к файлам. Файлы - это хорошая абстракция, но она протекает: если не знать того, как работают ОС или гарантии файловой системы, то легко выстрелить себе в ногу.

Меня увлекла тема отказоустойчивости, а конкретно - отказоустойчивой работы с файлами. В этой статье я попытался соединить все полученные знания:

Кто участвует в процессе записи

Ошибки, которые могут произойти

Что от нас зависит, а что нет

И самое главное - как это этого защититься

Мы уже рассказывали о том, как приручили робота-пайщика, как делаем устройства и тестируем их. Теперь хотим поделиться опытом разработки полноценного Embedded Controller для ПЛК на Linux — какие задачи решает, как устроен и что у него под капотом в прошивке.

Рун не должен резать
Тот, кто в них не смыслит.
В непонятных знаках
Всякий может сбиться.
Десять знаков тайных
Я прочел и знаю...(Сага об Эгиле)

Многие начинающие программисты, уже освоив синтаксис C++, обнаруживают, что нет простого способа, как подключить библиотеку, так и собрать программу для другой ОС, или чего хуже, под другим компьютером с той же ОС. Эта проблема отчасти порождается спорной практикой обучения, когда код учат писать и запускать лишь средствами IDE, таких как Visual Studio, Code::Blocks, и других.
Поначалу такой подход работает, но лишь до первой реальной задачи сделать что-то, что запустится не только на вашей машине. Тут-то новички и сталкиваются с отсутствием стандартной системы сборки и менеджера зависимостей. После осознания этой сложности, большинство студентов, как правило, переходят на другие языки, попутно тиражируя в индустрии миф о том, что C++ де не кроссплатформенный язык, а вот мой Python/Java/C# - да.
Между тем нас окружает множество замечательных кроссплатформенных программ написанных на C++. Если вы обучаетесь C++ и хотите понять как создавать такое ПО, то эта статья для вас.

У меня много статей в закладках. Многие из них я добавил, чтобы прочитать позже. Это статья не про то, почему так произошло и как с этим бороться, а про то, как выбрать статью для удаления чтения. Давайте найдем самые лучшие статьи. Критериями могут быть, например, рейтинг, просмотры и т.д. И красиво оформим в виде HTML-файла.

Пример закладок @alizar: 800+ статей.

Изначально я представлял LED Industrial Piercing [перевод на Хабре] как проект, специально рассчитанный на использование светодиодов 0201. В конечном итоге они оказались совершенно не нужны. Светодиоды 0201 слишком малы! Очевидно, я должен был двинуться глубже, поэтому целью нового проекта стало размещение как можно большего их количества на поверхности серёжки-гвоздика.