Оказывается, для 16-битной архитектуры Intel 8086 имеется компилятор GNU Си/Си++, и активно поддерживается. Раньше я слышал про bcc и OpenWatcom, но они имеют ограниченный функционал. С таким известием затея по восстановлению Юникса v7 (Venix) для писишки не выглядит безнадёжной.

Исходники: github.com/tkchia/gcc-ia16
Зеркало: gitlab.com/tkchia/build-ia16/-/releases

На интеловской Ubuntu компилятор ставится следующим образом:

sudo apt install software-properties-common
sudo add-apt-repository ppa:tkchia/build-ia16
sudo apt-get update
sudo apt-get install gcc-ia16-elf

На Ubuntu ARM64 аналогично, но из другого места:

sudo add-apt-repository ppa:catacombae/gcc-ia16-arm64

Глянем на сгенерённый код:

$ ia16-elf-gcc -S -O hello.c
$ cat hello.s 
	.arch i8086,jumps
	.code16
	.att_syntax prefix
#NO_APP
	.section	.rodata.str1.1,"aMS",@progbits,1
.LC0:
	.string	"Hello, World!"
	.text
	.global	main
	.type	main, @function
main:
	movw	$.LC0,	%ax
	pushw	%ax
	call	puts
	addw	$2,	%sp
	movw	$0,	%ax
	ret
	.size	main, .-main
	.ident	"GCC: (GNU) 6.3.0"

По умолчанию линкуется бинарник для MS-DOS:

$ ia16-elf-gcc hello.c 
$ file a.out
a.out: COM executable for DOS

Приехали новозеландские адаптеры для видеосигнала EGA/CGA и для клавиатуры XT. Подсоединил к писишке - задышало!

При включении показывает имеющуюся периферию и тестирует память.



После чего выдаёт версию прошивки.



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



Упаковка пятидюймовых флопиков у меня припасена, но их же надо ещё записать. Какой-нибудь древний MS-DOS отыскать. В следующий раз. И с дисковым контроллером пора вопрос решать.

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

Умный пылесос был удалённо заблокирован из-за отсутствия сбора данных.

Инженер заинтересовался работой своего умного пылесоса iLife A11 и начал отслеживать сетевой трафик, исходящий от устройства. Тогда он заметил, что тот постоянно отправляет производителю журналы и данные телеметрии, на что он не давал своего согласия. Пользователь, Харишанкар, решил заблокировать IP-адреса серверов телеметрии в своей сети, оставив прошивку и серверы OTA открытыми. Его умный гаджет работал какое-то время, но вскоре перестал включаться. После долгого расследования он обнаружил, что устройству была выдана команда на удалённое отключение.

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

Поскольку A11 был умным устройством, он был оснащен чипсетом AllWinner A33 с операционной системой TinaLinux, а также микроконтроллером GD32F103 для управления множеством датчиков, включая лидар, гироскопы и энкодеры. Он подключил разъёмы к печатной плате и написал скрипты на Python для управления ими с помощью компьютера, с целью индивидуальной проверки каждого компонента и выявления неисправностей. Затем он собрал джойстик на Raspberry Pi для ручного управления пылесосом, доказав, что с оборудованием всё в порядке.



После этого он изучил его программное обеспечение и операционную систему, и именно здесь он обнаружил мрачную правду: его умный пылесос был кошмаром безопасности и чёрной дырой для его личных данных. Прежде всего, Android Debug Bridge, предоставляющий ему полный root-доступ к пылесосу, не был защищён никаким паролем или шифрованием. Производитель добавил импровизированный протокол безопасности, убрав важный файл, из-за чего пылесос отключался вскоре после загрузки, но Харишанкар легко обошёл его. Затем он обнаружил, что пылесос использует Google Cartographer для построения трёхмерной карты его дома в режиме реального времени.

В этом нет ничего необычного. В конце концов, это умный пылесос, и ему нужны эти данные для навигации по дому. Однако беспокоит то, что он отправлял все эти данные на сервер производителя. Вполне логично, что устройство отправляет эти данные производителю, поскольку его встроенная система на кристалле недостаточно мощна для обработки всех этих данных. Однако, похоже, iLife не согласовала это со своими клиентами. Более того, инженер сделал одно тревожное открытие: в логах своего неработающего умного пылесоса он обнаружил команду с меткой времени, точно совпадающей со временем остановки устройства. Это была явно команда на завершение работы, и после того, как он отменил её и перезагрузил устройство, оно снова ожило.



Итак, почему A11 работал в сервисном центре, но отказывался работать дома? Техники переустанавливали прошивку умного пылесоса, удаляя код отключения, а затем подключали его к открытой сети, восстанавливая нормальную работу. Но как только он снова подключался к сети, в которой были заблокированы серверы телеметрии, он удалённо блокировался, поскольку не мог связаться с серверами производителя. Поскольку он заблокировал сбор данных устройства, производитель решил просто полностью отключить его. «Кто-то — или что-то — удалённо дал команду на отключение», — говорит Харишанкар. «Будь то намеренное наказание или автоматическое принуждение к «соблюдению правил», результат был один и тот же: потребительское устройство напало на своего владельца».

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

Приходится ли вам сравнивать файлы? Риторический вопрос: очевидно, приходится. Я лично команду "git diff" выдаю тысячу раз за день. Всем классический diff хорош, кроме одного: не различает перестановку фрагмента. Показывает только удаления и вставки. Если же часть текста переехала в другое место, diff учитывает его дважды: и как удаление, и как вставку.

Для некоторых применений такое не годится. Представьте, что вы хранитель коллекции ценных документов. И вдруг с одним файлом что-то случилось. Стандартный diff говорит, что всё пропало, документ полностью испорчен. А просто строки перемешались, ничего на самом деле не потеряно. Надо только порядок восстановить. В эпоху перфокарт такое сплошь и рядом происходило, когда колоду рассыпали и собрали впопыхах. Или кто-то решил навести порядок и переставил главы в тексте.

45 лет назад мой коллега Рид Котлер сделал утилиту сравнения файлов: "Text File Comparator". Трудился он тогда молодым студентом на компанию Intermetrics по контракту NASA. Сохранилось упоминание на странице 117 журнала NASA Tech Briefs Winter 1982 Vol. 7, No. 2: https://ntrs.nasa.gov/api/citations/20100028127/downloads/20100028127.pdf

Программа сравнивает два файла и выводит список их различий.

Программа сравнения файлов IFCOMP — это сравнение текстовых файлов для систем, совместимых с IBM OS/VS. IFCOMP принимает на вход два текстовых файла и выводит список их различий в форме псевдообновления. Все различия представлены в виде строк, которые следует удалить, заменить, вставить или переместить в первом входном файле для преобразования его во второй входной файл. Также выводится сводка с указанием количества строк, затронутых каждым типом изменений.

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

Программа IFCOMP написана на языке XPL (расширенный язык PLI, для которого поставляются исполняемые файлы компилятора) для пакетного выполнения и была реализована на компьютере IBM серии 370 с объёмом центральной памяти около 46 КБ 8-битных байт. IFCOMP была разработана в 1979 году.

Эта программа была написана Ридом С. Котлером из Intermetrics, Inc. для Космического центра имени Джонсона. Для получения дополнительной информации обведите кружком S на карточке запроса COSMIC.

Алгоритм подробно описан в статье: "A Technique for Isolating Differences Between Files", Paul Heckel 1978. 

Исходники на языке XPL утеряны, увы. Но сохранился вариант, переписанный Томом Пенелло на Си. Его я и решил поковырять. С ним Рид мне прислал четыре теста, и они работали. Но на некоторых других файлах программа выдавала внутреннюю ошибку или циклилась. Ошибка там неочевидная.

Я подумал: хороший случай применить ИИ для отладки. Интересно, как неестественный ум справится, скажем Cursor или Cline. Получился увлекательный сеанс. 😀

В целом программирование с помощью современного AI-агента напоминает походовую стратегическую игру. Если помните первую Empire, ещё в текстовом виде. Из неё потом выросла Civilization. Здесь нечто похожее, только без карты и в диалоге. Стратегически плодите и размещаете юнит тесты, и постепенно боретесь за расширение функционала и покрытия.

Благо, ИИ агент теперь удобно встроен в VS Code. Работает с файлами прямо в вашем локальном git-репозитории. Или даже прямо на Гитхабе, вам решать. Компилирует, запускает, пишет документацию, находит причины ошибок посредством юнит тестов, чинит, и по новому кругу. Вы внимательно наблюдаете за "сражением" и адресно вмешиваетесь в критические моменты.

Первый "подход к штанге" мы с Курсором продули. 😀 Для начала насоздавали несколько десятков юнит тестов, из которых больше половины не проходили. Хорошо, значит покрытие приемлемое. После этого несколько часов бились все эти тесты пройти. Курсор кромсал код без жалости. Объём Си-шных текстов увеличился вдвое, но справиться с глюками не удавалось. Стало понятно, что зашли в тупик.

Второй подход я распланировал иначе. Сначала переписываем всё с Си на Си++, чтобы уменьшить базовую сложность кода. Вместо доморощенных строк и примитивного выделения памяти переходим на стандартные строки и контейнеры из библиотеки Си++. После этого начинаем покрывать юнит тестами и отлаживать размеренно, по стадиям. Благо алгоритм имеет чёткое разделение на восемь проходов: от pass1() до pass8().

Главная бага обнаружилась на стадии pass6(). При слиянии двух блоков криво обновлялось дерево. Но проявлялся глюк только на уровне pass8(). Тесты уровней pass6 и pass7 багу не ловили. Курсор пытался "чинить" сначала уровень pass8, потом догадывался вернуться и сделать что-то с pass7, и даже заглядывал с сомнением в pass6, но тут его чутья не хватало. Как только я догадался скомандовать создать юнит тест, воспроизводящий нужную багу на уровне pass6, дело пошло на лад. Починка остального была уже делом техники.

Все исходники здесь: github.com/sergev/ifcomp

Дополировал я текстовый редактор, теперь уже и показать не жалко. Получился красивый код на Си++, и даже кое-как покрытый тестами. Не стыдно людям показать. Не знаю зачем оно может пригодиться, но ещё одна ностальгическая тема закрыта. 😀

github.com/sergev/v-edit

Внутри всё устроено ровно как в древнем Rand Editor. Редактируемые файлы не зачитываются целиком в память. Вместо этого строится компактный список сегментов, облегчающих подчитывание строк файлов по мере необходимости. Изменения в изначальные файлы не вносятся. Модифицированные строки записываются в отдельный временный файл. И только по команде записи в файл происходят перемены. Изначальный редактируемый файл foo переименовывается в бэкап foo~, а в новый foo записываются все строки по порядку, как изменённые (из временного файла), так и прежние (из старого файла). Таким образом обеспечивается устойчивость к сбоям: в любой момент, что бы ни случилось с компьютером, на диске имеется как минимум одна правильная копия файла.

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

Cursor в прошлые выходные глючил нещадно. Я даже разочаровался и переключился на Cline с горя. Это такой плагин для VS Code, от claude.ai. Он тоже приемлемо работает. Но вчера Cursor выкатил новую версию 2.0, я поставил и порадовался. Ничего не глючит, и кодит заметно умнее, чем Cline. Отличный инструмент.

Вот такой видео адаптер стоит в древней писишке. Тайваньская фирма Diamond Flower Inc производила Cpg-400 и другие видео контроллеры с 1981 года, а с 1992 переключилась на материнские платы.



Описание джамперов: theretroweb.com/expansioncard/documentation/50632.pdf

Чтобы сконвертировать этот видеосигнал в VGA, я заказал хитрый конвертер новозеландской фирмы. Приедет - будем пробовать.

- Пароль?
- План по валу!
- Вал по плану. Проходи.



Покажу, как выглядит программирование с ИИ помощником. В данном случае на примере допиливания текстового редактора v-edit. Для конкретики: используется Cline, такой плагин к VS Code, подключенный к модели grok-code-fast-1.

( Ставлю задачу... )

Вот всё что осталось.

Summary of the Amazon DynamoDB Service Disruption in Northern Virginia (US-EAST-1) Region

19–20 октября 2025 года в регионе Северная Вирджиния (US-EAST-1) произошел значительный сбой в работе сервисов AWS, вызванный, главным образом, скрытым состоянием гонки в автоматизированной системе управления DNS Amazon DynamoDB. Это привело к сбоям в разрешении DNS для региональной конечной точки DynamoDB, что привело к масштабным последствиям для нескольких сервисов AWS. Событие развивалось в три основных этапа: учащение ошибок API DynamoDB (с 23:48 по тихоокеанскому времени 19 октября до 2:40 по тихоокеанскому времени 20 октября), ошибки подключения к NLB (с 5:30 до 14:09 по тихоокеанскому времени 20 октября) и сбои запуска экземпляров EC2 из-за проблем с подключением (с 2:25 до 13:50 по тихоокеанскому времени 20 октября).

Проблема была связана с архитектурой DNS DynamoDB, которая использует DNS Planner для генерации планов конечных точек и избыточные DNS Enactors (в трёх зонах доступности) для их применения через Amazon Route 53. Редкое состояние гонки возникло, когда один Enactor столкнулся с задержками, позволив другому применить новый план и удалить старый в процессе. Это привело к пустой записи DNS для публичной конечной точки, что привело к блокировке подключений. Восстановление потребовало ручного вмешательства для восстановления DNS к 2:25 утра по тихоокеанскому летнему времени, а полное подключение было восстановлено к 2:40 утра по истечении срока действия кэшей. Глобальные таблицы испытывали задержки репликации, но оставались доступными в других регионах.

В EC2 наблюдались ошибки API, задержки и сбои запуска из-за зависимостей от DynamoDB. Менеджер рабочих процессов дроплетов (DWFM) не смог поддерживать аренду на физических серверах («дроплетах»), что привело к ошибкам, связанным с нехваткой ёмкости. После восстановления DynamoDB DWFM столкнулся с перегрузкой из-за накопившихся данных, что потребовало ограничения пропускной способности и перезапуска. Network Manager столкнулся с задержками распространения сетевых данных для новых экземпляров, которые были устранены к 10:36 PDT. Полное восстановление EC2, включая снятие ограничений пропускной способности, произошло в 13:50 PDT. Существующие экземпляры не пострадали.

В NLB возникали ошибки подключения из-за сбоев проверки работоспособности, усугублявшиеся задержкой распространения сетевых данных для новых экземпляров EC2. Это приводило к чередованию работоспособных и неработоспособных состояний, вызывая ненужные отказоустойчивости AZ и снижение производительности. Инженеры отключили автоматические отказоустойчивости в 9:36 PDT, восстановив работу к 14:09 PDT после стабилизации EC2.

Влияние на другие сервисы:
- Lambda: Ошибки и задержки API до 14:15 PDT, с задержками из-за сбоев опроса SQS и недостаточного масштабирования из-за проблем с NLB/EC2.
- ECS/EKS/Fargate: Сбои запуска и масштабирования контейнеров до 14:20 PDT.
- Amazon Connect: Повышенное количество ошибок вызовов/чатов до 13:20 PDT, с обратным заполнением данных до 28 октября.
- STS: Ошибки API до 09:59 PDT.
- AWS Management Console: Сбои аутентификации до 01:25 PDT.
- Redshift: Ошибки запросов и кластеров до 02:21 PDT, некоторые кластеры недоступны до 21 октября из-за заблокированных замен EC2; проблемы с запросами IAM временно затронули все регионы.
- Другие сервисы, такие как Airflow, Outposts и Support Center, столкнулись с аналогичными сбоями.

AWS извинилась за последствия и предложила решения: отключение/пересмотр автоматизации DNS DynamoDB для устранения состояния гонки; добавление контроля скорости NLB; улучшение тестирования и регулирования EC2; а также текущие проверки для повышения устойчивости и времени восстановления во всех сервисах.