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

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

>Выгодно слили лежак со склада

Причем выгодно для обеих сторон. Знаю много народа кто смог начать эксперименты с
одноплатниками и робототехникой именно благодаря появлению _доступных_ и неплохо документированных "малинок".

>> А так как работать это в большинстве случаев будет на 32-битном armv7
>> то логично и отлаживать на 32-битной системе.
> По задумке мой код на си портабельный

Так это _ваш_ код. А если используете не ваш - что,предлагается заниматься ловлей багов,возникших
из-за переноса на другую разрядность? В случае кода запускаемого на одноплатниках - он может быть
достаточно объемным,а также и сложным для понимания по причине личных предпочтений тех кто его
писал. Вон тот же ardupilot как пример.

> Я сказал что люблю быстрые компы? Я также люблю плавные, low latency,
> приятные в использовани компы. И мои ядра более радикальны в этом
> чем дистровские low-latency.

Возможно это связано с какими-то психологическими особенностями. Например временем реакции (своей,а не компа имеется в виду). Или чем-то еще. Вон,среди профессиональных игроманов есть
те кто отличает частоту на экране 75 и 100 Гц. А я и на обычном телевизоре с его 50Гц мерцания не вижу - видимо потому что не игроман.
Это я к тому что для меня и дистрибутивные ядра для десктопа вполне приятные в использовании.
Может быть потому что я не пытаюсь навешивать на систему всякие "интегрированные среды" типа KDE
и пользуюсь простым IceWM.

>> А что, некривые таблицы ACPI вообще хоть где-то бывают?
> Device Tree называется :))). Правда не ACPI зато не кривой

Кривость или не кривость опять же зависит не от самого Device Tree,а от того,
насколько правильно его написали под конкретное железо. Например в китайских планшетах
это условие не всегда выполняется.

> не требует маздайских тулкитов для крафтинга.

Вообще-то средства для пересборки таблиц ACPI есть нативные в Дебиане.
На ноутбуках ими не раз пользовался, ремонтируя то что недописали производители.

>Одна из причин по которым я хочу развидеть x86 вокруг себя, даже 64 битный.

За последние три десятка лет накопилось очень много кода, явно или не явно завязанного
даже не столько на сам x86,сколько на архитектуру типичного ibm-совместимого компа где он стоит.
Так-то с общетеоретической точки зрения я согласен, что и x86 и "ibm-совместимые" компы - это нагромождение накопившихся с 80х годов костылей многоуровневой совместимости.
Но пока что заменить особо и нечем. Причем я не о производительности говорю - она уже давно избыточна для большинства решаемых задач,а именно об архитектурных особенностях. Похоже надо
ждать когда появится какой-нибудь китайский последователь Стива Джобса и соберет в гараже
новый комп с каким-нибудь новым процом,и это не будет отягощено грузом тридцатилетней совместимости.

> Раз на раз не приходится. Да и можно подумать у вас почтари не работают.

Я в начале прошлого десятилетия имел неудачный опыт покупки через почту именно _новой_ железки -
это была плата с процом TI OMAP. Не доехало. Потому что экспортный контроль(вроде других причин небыло). Так что приобретать слегка "устаревшее" и потому распространенное железо выгоднее - оно
особо никого уже не заинтересует "по дороге".

>> В проприетарном софте хотябы есть некие господа,которые может быть будут разбираться.
> Лицензию читайте. И им пофиг что с бизнесом будет, не их
> же! Как вы это оспорите?

Я же сказал - МОЖЕТ БЫТЬ будут разбираться. Если повезет. К нам их лицензии вообще отношения не имеют - у нас же нет денег на американских адвокатов чтобы судиться опираясь на написанное в лицензии.

>> дипломного проекта - разбираться приходится самому потому что авторы давно утратили
>> к нему интерес и недоступны для связи.
> И все же это не должно становиться проблемой других людей.

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

> Хотя бы потому что проблемы с портабельностью - это не их факап.

Тот,кто писал код - может быть например хорошим математиком. Но посредственным программистом.
А так как хороших математиков мало,тем более в опенсорсе, то приходится пользоваться тем что есть. Автоматическое управление - область достаточно наукоемкая чтобы один человек мог разбираться во всём что к ней относится. Поневоле приходится использовать и чужой код тоже.
И если это управление объектами с достаточно сложным поведением (летающий дрон например) - то
и код будет весьма сложным. Не на программном уровне,а на математическом. Чтобы это переписать -
надо не столько архитектуру процессора знать,сколько математику на основе которой оно было написано. Иначе легко можно получить неправильное поведение софта в каких-нибудь граничных случаях (как раз с представлением чисел и связанных).

>> симулятор микроконтроллеров AVR. Ну очень удобная штука. Кстати - бесплатная и
>> официально совместимая с WINE. Но - с 32-разрядным конечно.
> Мне как-то не требовались симуляторы особо.

Мне далеко до вашей квалификации,поэтому без VMLAB в программировании AVR я как без рук.

> Тем более что обвес и периферию они все равно симулируют "не очень".

Ту периферию что внутри контроллера AVR (таймеры,порты) - VMLAB симулирует хорошо.
Немало ошибок в использовании всего этого так отловил.
Подключенные снаружи устройства - да, симулируются весьма ограниченно. Тут уж ничего особо не поделать. Разве что Proteus запускать в WINE - там несколько больше возможностей по симуляции того что к контроллеру подключено снаружи. Но и ошибок в симуляции больше или просто странного поведения,о котором если не знаешь то оно становится неприятной неожиданностью.

>А так qemu умеет STM32.
> Но - увы - без большей части железок. В уарт поругатсья
> можно. А при попытке читануть ADC - hard fault.

Вот именно поэтому я (и далеко не я один) в любительских самоделках предпочитаю AVR там где их возможностей хватает. Был бы для STM32 хороший _визуальный_ симулятор (как VMLAB) - любители более охотно использовали бы STM32 потому что оно содержит всё-таки достаточно полноценный arm-процессор,на котором значительно меньше заморочек с математикой. А так - периферийные устройства намного сложнее чем у AVR,а удобных средств пощупать их глазами и руками нет. Ну или может быть можно какую-то отладочную конфигурацию собрать чтобы глазами видеть что внутри STM32 происходит (по типу того же VMLAB) но нет хороших описаний как это сделать поэтому простой народ не знает.

>> Вы считаете что это вообще хорошо,когда одна программа может сожрать всю память
>> в системе?
> Я считаю что как использовать мое железо решать - мне.

Безусловно с вами согласен.

> Иногда ну вот надо какую-то ресурсоемкую разовую операцию например. И так лучше всего.

У меня просто нет таких операций,даже разовых, которые способны сожрать четыре гига памяти.
Хотя допускаю,что если бы я работал программистом то может быть они бы и возникали. Но я уже полтора десятка лет как не работаю.
Кстати,в прежние времена,когда памяти на компах было немного, я обычно настраивал квоты так чтобы
ни один процесс не мог выжрать всю память и поставить систему колом настолько что даже в шелл не зайти чтобы корректно его прибить. Возможно это наследие моей работы с низкоуровневым программированием в DOS,где любая ошибка означала мёртвый повис и перезагрузку через reset.

> Более того - это лезет и в других местах. Скажем mmap() для
> работы с файлами как с массивом в ряде случаев удобно -
> но в 32 битах оно жестко утыкается в "нехватку номерков"

Соглашусь что работа с файлами гигантских размеров актуальна для тех кто
профессионально занимается монтажем звука или видео. Но я этим не занимаюсь поэтому
у меня на компе просто неоткуда взяться файлам в четыре и больше гигов размером.
За последний десяток лет самый большой файл с которым мне пришлось иметь дело - это
образ инсталляционного диска Alt Linux Simple размером 3397 Мб. Всё равно до 4 Гб не дотянул:)
Ставил его знакомой даме на ноутбук взамен сдохших в очередной раз виндов.
Вообще-то Альт мог бы и поменьше инсталлятор сделать типа дебиановского netinstall.
Потому что перекачать три гига сюда через интернет по радио было долго и не просто.

>> не видел бы постоянно 0% использования.
> Я себе ZRAM нарулил вместо свопа, опять же, так латенси лучше.

Возможно вы правы. Я сам не пробовал - просто потому что довольно
давно уже своп просто не требуется,ни настоящий ни виртуальный.

> урон латенси лимитирован. Звездолет не снабжен якорем, он должен
> быть быстрым.

Вот только я заметил,что уже десятка полтора лет как скорость решения прикладных
задач ограничивается быстродействием не процессора,а моих мозгов. Копаться в мегабайтах
кода и разбираться что там к чему - быстрее не получается. И уж тем более придумывание
собственного кода процесс совсем не быстрый. У меня же нет задачи побыстрее "тяп-ляп и в продакшн". А над хорошим кодом думать приходится.

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

Питон - слишком новая вещь, его даже сейчас еще не всегда в институтах изучают.
А раньше,когда пишущие и учились, были Паскаль и Си. Вот и пишут на том что хоть как-то знают.
Я кстати когда впервые столкнулся с Питоном - очень неприятно удивили значащие пробелы в исходние. Сразу вспомнилась ЕС1046 и позиции на перфокартах - да, я это застал.

> А я и не ставлю их барахло посмотрев depends

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

>> указатель это тоже 32 бита. А еще встречается хранение IP-адреса как 32-разрядного инта.
> В случае дебиана это вообще повод выбросить пакет из репы, ибо они
> сватают себя как IPv6 ready.

В Дебиане этого кода и нет потому что те кто его писал не обладают нужными _социальными_ скиллами для пропихивания написанного в Дебиан. Я же не о профессиональных программистах говорил,а о любителях. Ну вот как раньше были "радиолюбители" так теперь появилось немало и программистов-любителей.