Представлена реализация eForth на C/C++ с кроссплатформенной поддержкой. Проект работает на Linux, MacOS, Windows, ESP32 и даже в WebAssembly (WASM), что делает его универсальным решением для различных систем.

Код проекта размещен на GitHub в репозитории chochain/eforth. Реализация eForth на C/C++ позволяет использовать этот язык программирования в широком спектре устройств - от настольных компьютеров до встраиваемых систем вроде ESP32, а также в веб-среде через WASM.

• Forth ценен для образования как альтернативный подход к вычислениям наряду с Lisp, демонстрирующий разные способы выражения программной логики.
• Классические реализации Forth на ассемблере противоречат идее 100% C/C++ с кросс-платформенностью, но язык остается простым для реализации с нуля, особенно на стековых процессорах.
• Производительность Forth часто страдает из-за цепочек вызовов подпрограмм, но возможна оптимизация через инлайнинг, использование регистров и native-код для критичных участков.
• Forth сохраняет нишевое применение в embedded-системах благодаря компактности и гибкости от низкоуровневого до высокоуровневого программирования.
• Сообщества вокруг таких языков могут предлагу уникальные решения, но иногда склонны к догматизму и пренебрежению другими подходами.

Grayskull — это компактная библиотека компьютерного зрения на C без зависимостей, созданная специально для встраиваемых систем, дронов и робототехники. Её минималистичный дизайн позволяет использовать даже на устройствах с ограниченными ресурсами, сохраняя при этом функциональность для базовых задач компьютерного зрения. Библиотека фокусируется на эффективности и простоте интеграции в существующие проекты.

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

• Пользователи обсуждали, что вместо использования готовых библиотек вроде OpenCV, они предпочитают реализовывать алгоритмы с нуля на C, чтобы лучше понять, что происходит под капотом.
• Участник поделился опытом попытки написать собственную реализацию OpenCV на C, но проект был приостановлен из-за потери интереса к компьютерному зрению.
• Другой участник упомянул, что вместо того, чтобы изучать готовые решения, он предпочитает читать исходный код, чтобы понять, как работает алгоритм.
• Была также поднята тема того, что вместо использования готовых решений, лучше уделять время изучению основ и первопричин.
• Участники сошлись на том, что важно понимать, что стоит за конкретной техникой или инструментом, и что важно не просто использовать инструмент, но и понимать, как он работает.

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

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

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

Статья представляет собой введение в обратную разработку прошивок старых синтезаторов, в частности Yamaha DX7, с использованием дизассемблера Ghidra. Автор предлагает пошаговое руководство для технически подкованных новичков в области реверс-инжиниринга, 8-битной архитектуры или встраиваемых систем. Для работы требуется только базовое понимание двоичных чисел и указателей, а не знание ассемблера или конкретных архитектур процессоров. Автор делится личным опытом, начав с нулевыми знаниями в электронике, но с готовностью экспериментировать.

Периферийные устройства DX7, такие как ЖК-экран и звуковые чипы, отображаются в памяти (memory-mapped), что упрощает взаимодействие с ними через определенные адреса. Для начала реверс-инжиниринга необходимо изучить логику декодирования адресов, используя схемы синтезатора и сервисные руководства. Автор подчеркивает, что обратная разработка старых синтезаторов — отличный способ познакомиться с встраиваемыми системами, сравнивая этот процесс с решением сложной головоломки, где лучше начинать с краев.

• Пользователи обсуждают эмуляцию синтезаторов, включая DSP56300 и JP-8080, и их влияние на сообщество.
• Сообщество выражает обеспокоенность по поводу того, что производители оборудования не поддерживают усилия по эмуляции их продуктов.
• Участники обсуждают возможность реверс-инжиниринга и модификации прошивок таких устройств как Zoom ARQ-96 и другие.
• Участники делятся ссылками на репозитории с исходниками и инструментами для работы с ними.
• Участники выражают благодарность за предоставленную информацию и выражают надежду на дальнейшую работу в этой области.

sbc.compare — это платформа для сравнения одноплатных компьютеров (SBC), помогающая выбрать оптимальную платформу для проекта. Сайт предлагает обширные бенчмарки, технические характеристики и данные реальной производительности для сотен альтернатив, включая Raspberry Pi, Orange Pi и Radxa. Пользователи могут искать платы по архитектуре (ARM, x86, RISC-V), количеству ядер, объёму ОЗУ и цене, а также сравнивать до трёх устройств одновременно. На сайте представлены популярные сравнения, такие как Raspberry Pi 5 против Pi 4 или Orange Pi 5B.

Платформа особенно полезна для принятия решений об обновлении оборудования — например, при выборе между сохранением Raspberry Pi 4 или переходом на более новую модель. Интерфейс интуитивно понятен: поиск нужных плат, добавление их в список сравнения и детальный анализ различий в производительности. Ресурс охватывает как широко известные модели, так и менее популярные альтернативы, предоставляя пользователям полную картину доступных на рынке решений.

• Пользователи обсуждают, что для встраиваемых проектов важнее всего поддержка периферии и ПО, а не «сырой» производительности, и отмечают, что у большинства SBC его нет.
• Создатель сайта отвечает, что в базе уже есть фильтры по Wi-Fi, Ethernet, PoE и прочим интерфейсам, но пока не хватает данных; обещает, что как только они появятся, появится и поиск по ним.
• Участники обсуждают, что Raspberry Pi и прочие SBC не подходят для промышленного применения из-за отсутствия гарантий и долгосрочной поддержки.
• Создатель сайта отвечает, что вендоры вроде Radxa и Libre Computer предлагают альтернативы, и что у них есть модули вычислений и стандартые 40-pin GPIO.
• Пользователи жалуются на отсутствие в списке таких девайсов как Orange Pi 5 и что не все модели отображаются корректно.
• Создатель сайта отвечает, что он не может найти Orange Pi 5 и что он не может добавить новые платы, пока не будет у него полные спецификации.

Владельцы Jeep Wrangler 4xe столкнулись с критическим сбоем после установки обновления ПО, выпущенного в пятницу. Обновление, предназначенное для информационно-развлекательной системы Uconnect, привело к отказу силовой установки во время движения. Некоторые водители оказались заблокированы на дорогах общего пользования, включая случаи на высоких скоростях.

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

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

• Jeep 4xe внезапно умер в гараже после обновления, а Stellantis молчит; владельцы жалуются на полное отсутствие официального ответа.
• Пользователи обсуждают, что OTA-обновления вообще не должны затрагивать критические системы, а уязвимость, которая позволила это произойти, должна была бы обнаружена и исправлена.
• Сообщество также поднимает вопрос, что если автопроизводитель не может гарантировать безопасность обновлений, то он должен быть обязан предоставлять физическую изоляцию инфотейнмента от ECU.
• Несколько человек упоминают, что владельцы 4xe и других моделей Stellantis уже не первый раз сталкиваются с проблемами после обновлений, но это первый случай, когда обновление вывело из строя само транспортное средство.
• Некоторые комментаторы поднимают вопрос, почему вообще допускается, чтобы обновления могли бы выводить из строя критические системы, и почему не предусмотрен механизм отката.

Команда GRiSP достигла ключевого рубежа в портировании JIT-компилятора Erlang BEAM на ARM32: впервые выполнила функцию Erlang через сгенерированный машинный код. Используя эмулятор QEMU, они запустили минимальный модуль hello.erl, который вызывает встроенную функцию erlang:halt/2 с кодом возврата 42. Это подтвердило работоспособность базовой цепочки: загрузка BEAM, инициализация JIT, компиляция и выполнение кода.

JIT инициализирует общие фрагменты кода и модуль erts_beamasm, содержащий критические инструкции для управления процессами, такие как run_process и normal_exit. Модуль hello был помещён в предзагружаемые модули, чтобы обеспечить его выполнение при старте системы. Код доступен в репозитории GitHub, а работа ведётся при поддержке Erlang Ecosystem Foundation.

• Обсуждение причин разработки JIT-компилятора для ARM32 в Erlang, включая актуальность 32-битных ARM-микроконтроллеров на рынке встроенных систем.
• Дебаты о текущем статусе архитектуры ARM32: участники отмечают, что она не устарела и до сих пор поддерживается в новых реализациях (v8-a, v8-m), несмотря на её нишевый статус.
• Вопросы о целесообразности запуска Erlang на маломощных устройствах: одни видят потенциал, другие сомневаются в необходимости из-за ограничений памяти и производительности.
• Обсуждение технических деталей: путаница с ESP32 JIT, сравнение с RISC-V, особенности наборов инструкций (Arm/Thumb/Thumb2).
• Замечание о том, что «более высокая скорость» других языков является субъективной характеристикой («при определенных определениях быстрее»).

Выбор между Ada, SPARK и Rust вместо C/C++ зависит от целей проекта. C/C++ остаются стандартом для встраиваемых систем из-за привычной экосистемы и обученных кадров, но они несут риски для безопасности — десятилетия разработок не сделали их по-настоящему безопасными без значительных затрат.

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

• Участники обсуждают сравнительные преимущества систем типизации в Ada и Rust, включая возможность создания отдельных типов для единиц измерения (например, мили и километры) для предотвращения ошибок.
• Высказываются мнения о применимости языков (C++, Ada, Rust, SPARK, Zig, D) в высоконадёжных и критических системах, таких как аэрокосмическая отрасль, с акцентом на строгие процессы разработки и верификации, а не только на выбор языка.
• Поднимается тема, что безопасность кода зависит в большей степени от методологии разработки и тестирования (интеграционного, системного), чем от самого языка программирования.
• Обсуждается эргономика и удобство использования возможностей языков (например, newtype в Rust, контролируемые типы в Ada) для обеспечения типобезопасности и предотвращения ошибок на этапе компиляции.
• Некоторые участники выражают скептицизм по поводу необходимости замены C/C++, предлагая вместо этого лучше изучать и использовать существующие языки, совершенствуя навыки и процессы разработки.

Toybox — это минималистичная реализация стандартных утилит командной строки для Linux и Android, написанная на чистом C. Она создана как компактная и самодостаточная альтернатива BusyBox, с акцентом на простоту, корректность и соответствие стандартам POSIX. Проект включает основные инструменты вроде ls, cp, mv и многие другие, сохраняя при этом малый размер и избегая внешних зависимостей.

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

• Toybox — это альтернатива BusyBox с более разрешительной лицензией (0BSD/MIT-0), созданная для решения лицензионных проблем и использования в Android.
• Оба проекта предоставляют набор стандартных UNIX-утилит (ls, cp, mv и др.) в виде одного исполняемого файла, что экономит место на диске.
• Изначальная идея Toybox вызывала споры из-за отказа от copyleft, но была принята как компромисс для включения в ОС.
• Название Toybox, вероятно, отсылает к коллекции игрушек (аналогично BusyBox) и может быть связано с песней Soundgarden.
• Проект ценится за чистый код и пермиссивную лицензию, но пока не достиг полной функциональной parity с BusyBox.

В 1980 году выпускники Университета Ватерлоо Гордон Белл и Дэн Додж основали Quantum Software Systems и начали разработку операционной системы QUNIX (позже переименованной в QNX). Их вдохновил опыт работы с Thoth — реальной ОС с синхронной передачей сообщений, написанной на высокоуровневых языках. Первая версия QUNIX 0.1 работала на самосборном компьютере с процессором Motorola 6809, а с появлением IBM PC в 1981 году они адаптировали систему под эту платформу.

QUNIX сочетала черты UNIX и CP/M: вместо стандартных каталогов вроде /bin использовались /cmds, /config, /sys. Команды отличались — например, help вместо man, task вместо ps. Это была первая микроядерная ОС для PC, ориентированная на надёжность в промышленных и коммуникационных системах. Интересная деталь: в ранних маркетинговых материалах график на мониторе был физически приклеен из-за отсутствия инструментов редактирования фото.

• Участники делятся личным опытом использования QNX в образовании (компьютеры ICON), робототехнике, на BlackBerry и в различных встраиваемых системах, отмечая её надёжность и элегантность.
• Многие вспоминают впечатляющую малую занимаемую память QNX и её демо-версию на дискетах, которая включала полноценную ОС с графическим интерфейсом и сетью.
• Обсуждаются сильные стороны ОС: изоляция процессов, реальное время и сетевая прозрачность, но также отмечаются недостатки, такие как накладные расходы на передачу сообщений.
• Упоминается использование QNX в индустрии (автомобильные инфотейнмент-системы VW/Audi, Skytrain в Ванкувере) и её влияние на дальнейшую карьеру в IT.
• Высказывается сожаление о упадке платформы и интерес к возможному открытию её исходного кода, а также ностальгия по эстетике интерфейса Photon.

Unite — это 32-битная многозадачная ОС реального времени для i386, созданная в начале 90-х по образцу QNX. Её ключевая особенность — микроядро, где всё, включая драйверы диска, файловую систему и менеджер пространств имён, работает как пользовательские процессы. Система изначально задумывалась как сетевая: ресурсы удалённых узлов доступны так же просто, как локальные, через префикс идентификатора узла. Разработка велась в Польше на дешёвые сбережения, с тысячами сбоев и ручными сбросами через педаль-переключатель.

Спустя 30 лет автор возродил проект благодаря виртуальным машинам и сохранившимся бинарникам. За две недели удалось запустить систему в VirtualBox с RAM-диска, затем добавить поддержку LBA-дисков. Единственная незавершённая часть — bootfs.com, 16-битный загрузчик, переключающийся между реальным и защищённым режимом; его перекомпиляция пока не удалась. Unite остаётся примером изящной микроядерной архитектуры с приоритетным планированием для встраиваемых систем, где всё можно менять как обычные программы.

• Участники обсуждают технические сложности разработки ОС, включая проблемы с оборудованием и переносом кода
• Поднимаются вопросы о архитектуре ОС, слоях взаимодействия, системе сообщений и защите между процессами
• Обсуждаются альтернативы (QNX, seL4) для IoT-устройств с меньшей поверхностью атаки по сравнению с Linux
• Высказываются предложения разместить код на GitHub для удобства доступа, но автор отвергает идею из-за принципиальных соображений
• Отмечается ценность чистых абстракций и модульной архитектуры в ОС, где каждый компонент изолирован

Миниатюрная библиотека sj.h для парсинга JSON весит всего 500 строк кода и использует единственный заголовочный файл. Она спроектирована для минимализма и эффективности, поддерживая базовые операции: разбор строк, чисел, булевых значений, массивов и объектов.

Библиотека не требует динамического выделения памяти, что делает её идеальной для встраиваемых систем и сред с ограниченными ресурсами. Её API интуитивен — всего несколько функций для доступа к данным, что снижает порог входа. Практический плюс: легко интегрируется в существующие C-проекты без зависимостей.

• Обсуждаются достоинства библиотеки автора: однофайловые решения на ANSI C/Lua с фокусом на простоту, удобный интерфейс и хорошую документацию.
• Отмечаются потенциальные проблемы безопасности и корректности: отсутствие проверок на переполнение целых чисел, возможное неопределённое поведение, слабая валидация JSON.
• Поднимается вопрос о целесообразности использования: обсуждаются нишевые применения (например, embedded), недостатки для продакшена и альтернативные библиотеки.
• Упоминается необходимость тестирования на соответствие стандарту (конформность) и handling edge cases.
• Обсуждается философия подобных минималистичных библиотек: свобода от избыточной сложности ценой отказа от безопасности и обработки всех крайних случаев.

Размещение сайта на одноразовой вейп-системе

Примечание: эта статья НЕ размещена на сервере, работающем на одноразовой вейп-системе. Настоящий пример можно посмотреть здесь.

Предыстория

Я несколько лет собирал одноразовые вейпы у друзей и семьи, изначально извлекая из них батареи для «будущих» проектов. Современные устройства стали сложнее: с USB-C и перезаряжаемыми аккумуляторами. Во время разборки я обнаружил микроконтроллер с маркировкой «PUYA» — это оказался ARM Cortex-M0+.

Технические характеристики

Микроконтроллер PY32F002B имеет:

• 24 МГц Cortex-M0+
• 24 КБ флеш-памяти
• 3 КБ ОЗУ
• Минимальный набор периферии

Подключение к сети

Идея использовать вейп в качестве веб-сервера пришла после экспериментов с semihosting — системными вызовами для ARM через отладчик. Для передачи данных использовался протокол SLIP (Serial Line Internet Protocol), эмулирующий модемное соединение через последовательный порт.

Настройка в Linux:

pyocd gdb -S -O semihost_console_type=telnet -T $(PORT) $(PYOCDFLAGS) &
socat PTY,link=$(TTY),raw,echo=0 TCP:localhost:$(PORT),nodelay &
sudo slattach -L -p slip -s 115200 $(TTY) &
sudo ip addr add 192.168.190.1 peer 192.168.190.2/24 dev sl0
sudo ip link set mtu 1500 up dev sl0

Для реализации TCP/IP стека выбрана легковесная библиотека uIP, не требующая RTOS и поддерживающая базовый HTTP-сервер.

Вот краткое содержание обсуждения:

• Участники обсуждают китайские 4G-донглы и одноразовые вейпы как примеры невероятно дешевых, но мощных вычислительных устройств, которые содержат микроконтроллеры, память и даже GPS.
• Основная мысль: подобные устройства, будучи одноразовыми, представляют собой огромную проблему электронных отходов, и их статус «одноразовых» считается абсурдным и расточительным.
• Обсуждается технический парадокс: эти устройства обладают вычислительной мощью, о которой можно было только мечтать несколько десятилетий назад, но теперь они массово выбрасываются после одного использования.
• Многие пользователи восхищаются техническим достижением автора проекта (запуск веб-сервера на таком устройстве) и духом хакерства, но при этом испытывают смешанные чувства из-за контекста их применения.
• Поднимается вопрос о том, как законно утилизировать такие устройства (батареи и электронику), и выражается сомнение, что люди следуют этим правилам.
• В целом, текущее состояние технологий, где ИИ создает искусство, а веб-серверы работают на вейпах, характеризуется как «странное».

HackberryPiCM5 – карманный Linux-компьютер на базе Raspberry Pi CM5.

• 4" сенсорный TFT 720×720 пикс.
• Клавиатура от Blackberry.
• Ультракомпактный корпус, полноценный Linux.

• Устройство на CM5 с клавиатурой Blackberry вызывает восторг «как в 90-х», но критикуют за отсутствие глубокого сна, микроскопические клавиши и необходимость докупать BT-аудиомодуль.
• Большинство сомневаются в практической пользе: «200+ $ — и положит в ящик», слишком мал 4" экран, нет железного видеодекодера, WiFi-адAPTERA и т.д.
• Альтернативы: Beepy с Sharp Memory LCD, uConsole, лэптоп-консоль Pandora-style на RK3588, SPIRIT-смартфон на том же CM5.
• Кто-то хочет просто отдельную USB-клаву Blackberry или планшет + лёгкий BT-клав, другие мечтают о clamshell с 7" и DP-alt USB-C для очков XR.

Ada в действии: рисуем розетки

Создадим консольную утилиту, генерирующую SVG-файл с анимированными розетками (гипотрохоидами, как в Spirograph™). Проект показывает, что Ada 2022 — не только для безопасно-критичных систем, но и для обычных задач.

Зачем Ada?

• Жёсткая проверка типов и компилятор как «партнёр».
• Читаемость вместо краткости, минимум неопределённого поведения.
• Отлично подходит для встраиваемых, авиа-, железнодорожных и автомобильных систем.

Как работает программа

1. Принимает параметры из командной строки.
2. Вычисляет координаты точек кривой.
3. Записывает XML-совместимый SVG.
4. Открывается в любом браузере без сторонних библиотек.

Структура проекта

rosetta/
├── alire.toml          # зависимости Alire
├── src/
│   ├── rosetta.adb     # точка входа
│   ├── svg.adb/.ads  # генерация SVG
│   ├── curve.adb/.ads # математика кривой
└── Makefile

Ключевые типы

type Point is record
   X, Y : Float;
end record;

type Rosetta_Params is record
   R, r, d : Float;  -- радиусы и смещение
   Steps   : Positive;
end record;

Генерация кривой

function Hypotrochoid(P : Rosetta_Params) return Point_Array is
   Result : Point_Array(1 .. P.Steps);
   Angle  : Float := 0.0;
   Delta  : constant Float := 2.0 * Pi / Float(P.Steps);
begin
   for I in Result'Range loop
      Result(I) := (
        X => (P.R - P.r) * Cos(Angle) + P.d * Cos((P.R - P.r) / P.r * Angle),
        Y => (P.R - P.r) * Sin(Angle) - P.d * Sin((P.R - P.r) / P.r * Angle)
      );
      Angle := Angle + Delta;
   end loop;
   return Result;
end Hypotrochoid;

Создание SVG

procedure Write_SVG(Path : Point_Array; Filename : String) is
   File : File_Type;
begin
   Create(File, Out_File, Filename);
   Put_Line(File, "<svg ...>");
   Put(File, "<path d='M");
   for P of Path loop
      Put(File, Float'Image(P.X) & "," & Float'Image(P.Y) & " ");
   end loop;
   Put_Line(File, "' stroke='black' fill='none'/>");
   Put_Line(File, "</svg>");
   Close(File);
end Write_SVG;

Сборка и запуск

alr build
./bin/rosetta --R 100 --r 40 --d 80 --steps 360
# открыть rosetta.svg в браузере

Что дальше

• Добавить CLI-парсер GNAT.Command_Line.
• Анимировать через <animate> в SVG.
• Портировать на микроконтроллер и выводить на дисплей.

Полный код: github.com/AdaCore/rosetta-ada-demo

• Пользователи просят чёткий список возможностей Ada, доступных бесплатно в GNAT, и тех, что требуют лицензию AdaCore; ответ: весь язык доступен в FSF-GNAT, а проприетарный вариант лишь обновляется чаще и сопровождается коммерчески.
• Участники вспоминают, что писали на Ada ещё в 90-е, отмечают приятный «паскалеподобный» синтаксис и интерес к новым фичам Ada 2022 и SPARK.
• Ada применяется в высоконадёжных системах (NVidia, автопром, проект Muen), но в коммерческой разработке её доля снизилась, уступив C/C++.
• Появились ресурсы для старта: learn.adacore.com, ada-lang.io и репозиторий awesome-ada.
• Обсуждается, помогут ли LLM вернуть Ada в мейнстрим: одни считают, что строгость языка полезна для проверки сгенерированного кода, другие — что LLM сделают все языки нишевыми.

32-битные системы устарели, но ядро всё ещё их поддерживает из-за старого «железа» и ПО.
Arnd Bergmann: новые продукты уже 20 лет выходят на 64-битных платформах; встраиваемые устройства постепенно переходят с armv7 (32-бит) на armv8 (64-бит).

• Arm: 90 % встраиваемых систем; лишь три старые архитектуры до-armv7 ещё можно купить, но ядро держит десяток выведенных из производства. Поддержку можно выбрасывать «по половинам», когда исчезнут пользователи.
• Другие 32-битные архитектуры (arc, microblaze, nios2, openrisc, rv32, sparc/leon, xtensa) вытесняются RISC-V.
• nommu (armv7-m, m68k, superh, xtensa) никто не выпускает, их держат лишь ради существующих систем.

Для несовместимых 32-битных приложений — запуск 32-битного userspace на 64-битном ядре: экономит память, не требует 32-битного ядра.

Боль разработчиков:

• Высокая память (highmem) усложняет mm-подсистему; нужна, когда физической памяти > ~800 МБ.
• Ядро пока держит 32-битные машины до 16 ГБ, но таких почти нет; 4 ГБ встречаются (Chromebook), 2 ГБ — чаще, но «глупо»: память дороже CPU.

• Участники обеспокоены удалением поддержки nommu/32-бит: это уменьшает свободу, лишает возможности запускать Linux на старом или простом железе и делает ядро похожим на «дорожную карту» Apple/Windows.
• Некоторые предлагают форк «Linux Legacy» или переход на NetBSD/OpenBSD, которые по-прежнему поддерживают старые архитектуры.
• Для встраиваемых устройств без MMU считают более подходящими Zephyr, NuttX или Contiki, а не полноценный Linux.
• Поддержка big-endian почти мертва, но сохранится, пока IBM вкладывается в s390x.
• Старые ядра и LTS-дистрибутивы ещё десятилетие обеспечат безопасность и работу выброшенного железа.

Ultrassembler — библиотека RISC-V-ассемблера, встроенная в проект Chata.
В отличие от as и llvm-mc, она вызывается прямо из C++, без system() и временных файлов, что критично для встроенных систем.

Скорость

Тест на 16 тыс. инструкций:

• Ultrassembler ≈ 10× быстрее as, 20× быстрее llvm-mc.
• 1 RISC-V инструкция ≈ 1000 x86-инструкций (у конкурентов 10–20 тыс.).
  Код на чистом C++; можно добавить ассемблерные вставки.

Ключевые оптимизации

Исключения

GCC-реализация «zero-overhead»: штрафа нет, пока исключений нет.
Ошибки встречаются редко и видны человеку, поэтому даже 1 с на обработку незаметна.
std::expected дал −10 %, так как нормальный путь стал дороже.

Быстрые структуры

2000+ RISC-V-инструкций требуют мгновенного поиска.
Вместо std::unordered_map используется perfect-hash таблица от gperf, генерирующая O(1) без коллизий.
Размер таблицы компактен, кэш-эффективен.

Парсинг

• Регистры идентифицируются по первым 2–3 символам через switch.
• Нет std::string, только std::string_view и статические буферы.
• Лексемы разбираются за один проход без регулярных выражений.

Кодогенерация

• Шаблоны на этапе компиляции формируют битовые маски инструкций.
• Варианты одной инструкции разворачиваются в constexpr-таблицы, что убирает ветвления в рантайме.

Память

• Все выделения через стековые std::array/std::string_view.
• Нет new/malloc, следовательно, нет аллокационных штрафов и кэш-промахов.

Платформенные трюки

• [[likely]]/[[unlikely]] для подсказок ветвления.
• __builtin_expect там, где компилятор не догадывается.
• LTO + PGO дают ещё 5–7 %.

Итог

Ultrassembler показывает, что «низкоуровневый» C++ без искусственных ограничений может обгонять даже оптимизированные GNU-утилиты.

• В обсуждении разобрали миф о «системном вызове при каждом росте контейнера» — реальные аллокаторы переиспользуют память и делают syscall лишь при нехватке.
• Участники напомнили, что исключения в C++ не «zero-overhead»; есть компромисс между временем и памятью, и g++ выбирает экономию места.
• Автор статьи подтвердил: пробовал хеширование, но дерево разбора оказалось быстрее; flex/bison тут не при чём, скорее gperf.
• Некоторые посоветовали LLVM C++ API, memory-mapped I/O и std::pmr для ускорения и упрощения кода.
• Большинство сходится: современные ассемблеры и так быстрые, задача скорее академическая, но как «посмотреть, насколько можно ускорить» — интересна.

• Почему Forth?
  20 лет назад прочёл про язык в книге по embedded, но не вник. В июне 2025-го захотелось просто писать код и наткнулся на статьи Dave Gauera — решил попробовать.

• Два уровня Forth
  User: просто пользуешься языком.
  Hacker: IF…THEN, BEGIN…UNTIL и прочие конструкции — обычные слова, которые можно переопределить; язык описывает сам себя.

• goforth (Go)
  «Чистый» интерпретатор: слово хранит исходный текст, который повторно интерпретируется. Для пользователя работает, но нельзя реализовать IF внутри Forth — всё контролирует Go.

• ctil (C)
  Классическая реализация: связанный словарь, токен-трединг, большая часть на Forth. Позволяет писать:

: variable create 1 cells allot ;

: if   ' 0branch , here 0 , ; immediate
: then here swap - swap ! ; immediate
: else ' branch , here 0 , swap dup here swap - swap ! ; immediate

Итого: два эксперимента, показывающие разницу между «просто работает» и «можно копнуть душу языка».

• Реализация Forth на Go оказалась «не по канонам»: стек и память описаны отдельными структурами, поэтому многие стандартные слова не работают.
• Кто-то показал элегантный вариант на C++ с continuation-passing style и musttail-атрибутом clang.
• Всплыли воспоминания о Forth-диалекте FCode в Open Firmware старых Mac, но выяснилось, что Intel-Mac’и использовали EFI, а не Open Firmware.
• Читатели посетовали на читаемость кода без комментариев о стеке и отметили, что «high-level» реализации могут потерять дух Forth.
• Автор ответил: первая версия на Go была экспериментом, а «правильная» реализация на C хранит код и данные вместе, как положено.

SDS — библиотека динамических строк на C от автора Redis.
Предоставляет удобный API: создание, копирование, конкатенация, форматирование, сравнение, обрезку и пр.
Скрывает ручное управление памятью, хранит длину и оставшийся буфер в заголовке, что ускоряет операции и делает буфер-переполнение невозможным.
Совместима с обычными char* (нулём-терминатором), поэтому строки можно передавать в любые функции стандартной библиотеки.
Используется в Redis, хорошо протестирована, распространяется под BSD-лицензией.

• Пользователи обсуждают, почему в SDS предпочитают sdscat(s, "...") вместо stscat(&s, "..."): главное — производительность и простота.
• Некоторые удивлены, что sds — это char* без const, что может привести к ошибкам при передаче в libc-функции, не обновляющие метаданные.
• Автор antirez напоминает: актуальная версия SDS живёт внутри Redis, куда она мигрировала и развивалась дальше.
• Разгорелся спор «зачем вообще писать на C, если есть C++ и string_view»; ответы: embedded, совместимость, «не платишь за то, что не используешь», а также исторические причины (Redis начинался в 2009, string_view появился в C++17).
• Подчёркивают: C-код можно встраивать куда угодно, а C++ уже требует рантайма и ограничивает переносимость.

100R — пережить софтверную зиму

Главная | О нас | Знания | Статьи | Проекты | Путешествия

---

Отрывок из доклада Девайна, 26 ноября 2022

видео | презентация Adelie

Февраль 2025. После Handmade Seattle 2024 организатор извинился за «слишком разнообразную» программу и пообещал вернуть «байтовые» доклады, исключив при этом FOSS-спикеров. В чате разгорелась трансфобная волна; организатор обвинил меня в развале конференции и отказался оплачивать перелёт. Я попросил удалить запись.

---

Пережить софтверную зиму

Студия Hundred Rabbits — два человека на солнечной яхте, работаем на выброшенных устройствах: быстрый софт требует медленных компьютеров. Путешествуем и исследуем устойчивость: от электроники до продовольствия и забытых технологий.

За 7 лет обогнули Тихий: Мексика → Полинезия → Новая Зеландия → Фиджи → Япония → Камчатка → Аляска → Канада. План был делать арт, музыку и игры, но техника, рассчитанная на Запад, начала сыпаться сразу после отхода от берега.

На яхте не выйдет «просто взять метлу», если сломается GPS или прогноз погоды. Подписки, DRM и облака превращают навыки в аренду: пропал интернет — пропал и Photoshop, а с ним и профессия.

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