Внутри критически важного ракетного крейсера USS Yorktown (CG-48) типа Тикондерога c 1996 года работала Windows NT 4.0.
Встраиваемые Windows и Linux работают в медицинском оборудовании лет 30 для Windows и лет 20 для Linux. В том числе работает RTLinux, система реального времени.
В 2013 году:
Кейт Чувала (Keith Chuvala), руководитель United Space Alliance, организации, по контракту выполняющей обслуживание вычислительных операций Международной космической станции, принял решение перевести десятки ноутбуков, работающих на МКС, с Windows XP на Debian 6.

Linux используется в компьютерной инфраструктуре МКС с самого запуска станции в 1998 г., а также обеспечивает работу вычислительных систем центра управления полетами МКС в NASA.
Международная космическая станция перешла с Windows XP на Linux
Автору не стыдно не знать ничего про вещи, про которые он пишет?

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

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

Самое же смешное - тут

Система научилась работать с процессорными архитектурами PowerPC, ARM и ARM64.

Учитывая, что в исходном тексте жаловались, что старого PowerPC (не путать с OpenRISC ) не хватает, у некоторых несознательных граждан может возникнуть неудобный вопрос - что же там за центральный процессор стоит в импортозамещенном самолете, если система работает с PowerPC, ARM и ARM64.

Зачем вообще переделывать, а не дорабатывать готовое? Я решил серьезно углубиться в Godot и реально сделать свой проект, игру. Ту в которую я бы хотел сыграть. Все же гнаться за мечтой, даже детской, это несколько романтично, возвышено и тупо. Меня устраивает. Старый контроллер имел серьезные проблемы в самой своей базе. Так же его переработка хороший способ убить сразу несколько зайцев. Структура проекта "Контроллер" осталась старой.

1. Сервер на Python - принимает подключение телефона, получает нажатия и передает их драйверу ViGEmBus. Сервер поддерживает подключение до 4ех человек;

2. Контроллер на Godot (далее по тексту клиент) - подключается к серверу, передает ему нажатия. Для хобби-прототипа сильно париться не хотелось. У клиента всего 2 сцены - настройки и сам контроллер;

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

Чертовы кнопки

Бесплатные картинки для кнопок взял с https://itch.io/game-assets/free/tag-gamepad. Набор приличный, на любой вкус. Со стиками было проще всего - не стал создавать велосипед и загрузил Virtual Joystick от MarcoFazio через AssetLib. А вот кнопки делал через узел TouchScreenButton - в документации Godot этот узел как раз предназначен для обработки на сенсорных устройствах. Загрузил текстуры для кнопок ииии... И границы текстур оказались слегка больше, чем ожидалось.

В общем Godot правильно определяет границы - я ведь не обрезал прозрачные лишние части. Вроде и черт с ним, но ведь нажатия будут обрабатываться неправильно - в местах пересечений будет срабатывать несколько кнопок. Вариантов была два (по крайней мере о которых я прочитал):

1. Обрезать кнопки в редакторе убирая пустоты;

2. Забить на TouchScreenButton и создавать области вручную через Area2D и CollisionShape2D.

Будучи здравомыслящим(?) человеком, я выбрал второй вариант. Чтоб больше страданий было, хех. Если пошагово, то создавалось все это дело следующим образом:

1. Для 4ех левых кнопок был создан отдельный узел Node2D (CrossButtons1);

2. Для каждой кнопки создан узел Area2D (UpArea);

3. Для Area2D были созданы Sprite2D (UPsprite) - отображение кнопки, и CollisionShape2D (для него я уже поленился название выдумывать) - зона обработки нажатия.

Для узла CrossButtons1, в который входят кнопки, добавляем скрипт со следующим текстом:

Строка 4 нужна для привязки функции обработки нажатия к нашей области Area2D (UpArea). Строки 8 и 10 ловят нажатие и отпускание кнопки.
Это все супер, но как будто лень писать подобный код для каждой новой кнопки. Благо, действительно есть способ попроще.

Пробегаемся по всем подузлам нашего Node2D (CrossButtons1), находим те, что принадлежат типу Area2D и подключаемся функцию _on_button_input для обработки всех кнопок в Node2D. Для нашей задачи главное понимать, какая кнопка была нажата - получаем через button.name.

Замечательно, но что если мы хотим, чтобы картинка кнопки менялась при нажатии? Вышеописанные методы уже не сработают, придется работать с каждым Area2D узлом отдельно. В целом ничего страшного. Делаем все те же шаги, что раньше, но создаем скрипт для узла Area2D. В него грузим картинки состояний.

Код +- тот же, но добавляем:

1. Строка 7 - начальное состояние/начальная картинка;

2. Строки 12 и 15 для переключения состояния/картинки при обработке нажатия.

Заключение

Все что осталось - томная работа по повторению процесса для создания всех нужных кнопок. В следующей части добавлю новую сцену, ввод текста и сохранение данных в json формате. И немного работы сети. У-о-о-т. Спасибо за чтение. Дельные замечания и советы приветствуются, ибо в плане создания подобного я ещё профан.