Re[7]: Raspberry Pi dev device.
От: alpha21264 СССР  
Дата: 26.03.23 11:31
Оценка:
Здравствуйте, CreatorCray, Вы писали:

A>>Глупостей не говори. Ты видел Винду на Raspberry? Вот ыменно.

CC>https://www.tomshardware.com/how-to/install-windows-11-raspberry-pi
CC>Народ ставил и более старые версии

ОС без программ никому не нужна.

Течёт вода Кубань-реки куда велят большевики.
Re[8]: Raspberry Pi dev device.
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 26.03.23 12:06
Оценка:
Здравствуйте, alpha21264, Вы писали:

A>Она там не "работает". Она там "есть". Без программ.


В том же состоянии, что и линукс после появления новых платформ. Все, что есть в исходниках под винду для x86/x64, с легкостью собирается под ARM (хоть 32, хоть 64), если оно не заточено под особенности архитектуры. Но то же самое касается и линукса. Если же в исходниках чего нет, оно и под виндой, и под линуксом появится не раньше, чем соберет разработчик.

A>Вот ровно потому что.


Ровно настолько, насколько платформа востребована. Навскидку, под ARM64 уже давно подтянули FAR, 7-Zip, утилиты SysInternals, еще что-то по мелочи. Пишут, что MS уже выкатили студию под ARM64 — с прицелом на то, чтоб разработчики ставили винду на Mac M1/M2.
Re[8]: Raspberry Pi dev device.
От: zx zpectrum  
Дата: 26.03.23 13:04
Оценка: +2
ЕМ>При том, что в винде принципиально нет понятия "сборка под родную систему". В ней всегда была и есть "просто сборка". Что под свою систему, что под чужую, что под линукс, что под МК — результат определяется исключительно набором и настройкой используемых средств.

Это всё красивые концептуальные речи. А теперь пара вопросов из грязной приземлённой практики:

1. Компилятор msvc с хост-архитектурой x86_64-windows сумеет выдать статическую или динамическую библиотеку с target–архитектурой arm–linux, которую потом успешно всосёт gcc или clang под целевой ОС?
2. Какая-нибудь роутерная прошивка OpenWRT потребует под виндой менее забористых и более прямых build–скриптов по сравнению со сборкой оной под линуксом?

По-моему Вы просто основываете свои утверждения на маргинальных примерах сборки под MK, то есть под bare metal target. В этом случае все телодвижения действительно на порядок проще оных при сборке именно под чужую ОС.
Re[18]: Raspberry Pi dev device.
От: alex_public  
Дата: 26.03.23 16:11
Оценка:
Здравствуйте, /aka/, Вы писали:

A>>>Вау. Расскажи, какие публичные проекты ты собирал на виндовсе под линукс?

_>>...у нас был нативный клиент на C++, который собирался из одних исходников в десяток разных дистрибутивов, под множество ОС
A>Выделено же — публичные проекты. Зачем лезть со своими белыми и пушистыми исходниками? У нас тоже есть наш код, который из одних исходников кросс-компилируется под разные платформы.
A>Сборка своего не даёт тебе никакого понимания о тех конюшнях, которые придётся разгребать, когда будешь собирать чужое, не подготовленное авторами к кросс-коспиляции.

Так наш проект то использовал десятки открытых библиотек, которые в начале надо собрать, опять же под все целевые платформы. И там встречалось всякое. Были и по сути не зависящие от платформы, такие как Boost (во всяком случае большая часть их библиотек). Были и нормально собирающиеся под все платформы, но ценой очень сложного кастомного скрипта сборки (такие как Qt, OpenSSL и т.п.). А были и вообще без подготовки под все платформы, так что приходилось для них самим писать универсальные (под все платформы) скрипты сборки, как например для библиотеки UDT. Так что опыта игр в эти дела более чем достаточно и происходило это всё с Windows (правда с Линуха или Мака оно всё было бы точно так же).
Re[9]: Raspberry Pi dev device.
От: alex_public  
Дата: 26.03.23 16:18
Оценка:
Здравствуйте, zx zpectrum, Вы писали:

ЕМ>>При том, что в винде принципиально нет понятия "сборка под родную систему". В ней всегда была и есть "просто сборка". Что под свою систему, что под чужую, что под линукс, что под МК — результат определяется исключительно набором и настройкой используемых средств.

ZZ>Это всё красивые концептуальные речи. А теперь пара вопросов из грязной приземлённой практики:
ZZ>1. Компилятор msvc с хост-архитектурой x86_64-windows сумеет выдать статическую или динамическую библиотеку с target–архитектурой arm–linux, которую потом успешно всосёт gcc или clang под целевой ОС?

MSVC — это убогое недоразумение. Я его держал у себя исключительно для целей сравнения. А так, все сборки для видны были или с помощью gcc (mingw) или clang'a, которые просто на голову лучше (правда каждый по своему). Ну и есть конечно ещё icc, но это отдельная тема для тех, кому критичен каждый такт и платформа только Intel Х86.

ZZ>2. Какая-нибудь роутерная прошивка OpenWRT потребует под виндой менее забористых и более прямых build–скриптов по сравнению со сборкой оной под линуксом?


OpenWRT — это как раз классический Linux дистрибутив и как все они является самой проблемной целевой платформой для кросс-компиляции. Я подробном писал об этом выше.

ZZ>По-моему Вы просто основываете свои утверждения на маргинальных примерах сборки под MK, то есть под bare metal target. В этом случае все телодвижения действительно на порядок проще оных при сборке именно под чужую ОС.


А скажем сборка под Android (если что, это в данный момент самая массовая ОС на планете) надеюсь не является маргинальным примером? И там кстати тоже ядро Linux... Но при этом кросс-компиляция изначально идеально продумана и работает одинаково беспроблемно на любой хост-системе.
Re[9]: Raspberry Pi dev device.
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 26.03.23 18:12
Оценка:
Здравствуйте, zx zpectrum, Вы писали:

ZZ>1. Компилятор msvc с хост-архитектурой x86_64-windows сумеет выдать статическую или динамическую библиотеку с target–архитектурой arm–linux, которую потом успешно всосёт gcc или clang под целевой ОС?


Не уверен, поскольку задачи полной совместимости по библиотекам там никогда не стояло — только по исходникам. Если нужно собирать непременно библиотеки в линуксовых форматах, может оказаться проще использовать на хосте те же gcc/clang. Только какой может быть смысл в таком сочетании, кроме того, что библиотеки нужных форматов недоступны, и их исходники тоже?

ZZ>2. Какая-нибудь роутерная прошивка OpenWRT потребует под виндой менее забористых и более прямых build–скриптов по сравнению со сборкой оной под линуксом?


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

ZZ>все телодвижения действительно на порядок проще оных при сборке именно под чужую ОС.


Я говорю прежде всего о том, что само по себе разделение на "свою" и "чужую" ОС является сугубо искусственным и не обосновано ничем, кроме упрямого желания "просто хочу, чтоб было так". Система разработки/сборки вообще не должна содержать таких категорий. Она должна тупо получать на входе исходники, библиотеки и параметры сборки в явном виде, тогда на выходе всегда будет предсказуемый результат, никак не зависящий от ее текущего окружения. Для удобства в ней может быть режим "взять параметры из родной системы", но это должен быть лишь один из возможных равноправных вариантов, а не стандартный и предпочтительный.
Re[10]: Raspberry Pi dev device.
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 26.03.23 18:37
Оценка:
Здравствуйте, alex_public, Вы писали:

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


Самое смешное, что не надо ничего "идеально продумывать". Достаточно убрать (а еще лучше — изначально не вводить) разделение на "свою" и "чужую" системы, как все проблемы совместимости исчезнут, и останутся лишь вопросы удобства — в каком виде задавать параметры, как организовать хранилище и т.п.

По сути, это же самые азы абстракции — вместо конкретного значения использовать "x", "n" и прочее. И в математике, и в программировании они всегда приветствовались. И переменные в makefile тоже были введены, чтобы уйти от конкретных значений. Странно, как при таком подходе могла появиться парадигма "собираем всегда под себя" — тем более, что в 70-е уже хватало машин, идентичных/совместимых по системе команд, но сильно различавшихся по доступным ресурсам и удобству среды. Казалось бы, идея собирать что сам unix, что софт под него, на более мощной/удобной машине, а затем переносить на целевую, должна была возникнуть автоматически.

Я в 80-е много работал на PDP-11 с RSX-11M, ее тоже нужно было "генерировать" под типы целевого процессора, набор устройств, конфигурацию ПО и т.п. Но на любой машине можно было сгенерить систему под любую другую, лишь бы она поддерживалась. Встроенных кросс-средств в той системе не было, но лишь потому, что все было написано на ассемблере, и настройка на аппаратуру обеспечивалась обычной условной трансляцией. Будь оно написано на ЯВУ, точно так же работал бы и компилятор, позволяющий задавать целевую архитектуру.

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

Поскольку для линуксов давно наработаны типовые комплекты скриптов, в основу которых положена странная идея "своей" системы, неудивительно, что это создает столько проблем при малейшем отступлении от привычных вариантов.
Re[8]: Raspberry Pi dev device.
От: CreatorCray  
Дата: 26.03.23 22:43
Оценка: +1 -1 :)
Здравствуйте, alpha21264, Вы писали:

A>ОС без программ никому не нужна.

Ну т.е. линух не нужен
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[18]: Raspberry Pi dev device.
От: CreatorCray  
Дата: 26.03.23 22:43
Оценка: +1 -1
Здравствуйте, /aka/, Вы писали:

A>Сборка своего не даёт тебе никакого понимания о тех конюшнях, которые придётся разгребать, когда будешь собирать чужое, не подготовленное авторами к кросс-коспиляции.

А так уж надо ли эти конюшни разгребать? Я уже столько раз видел как оказывалось дешевле и быстрее "взорвать руины и построить сразу нормально" что у меня уже аллергия на опенсорсные копролиты.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[3]: Raspberry Pi dev device.
От: Skorodum Россия  
Дата: 27.03.23 08:54
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Мне вот интересно, есть ли хоть одна надобность, не говоря уже о "еще какой". Единственное, что приходит на ум — отсутствие нормального кросс-компилятора для целевой платформы. Но такое, насколько я знаю, кончилось еще лет двадцать назад.

1. Кросс-компиляция с некоторыми зависимостями может быть проблемной, например Qt.
2. Тестирование после сборки.
Re[11]: Raspberry Pi dev device.
От: B0FEE664  
Дата: 27.03.23 10:53
Оценка: +1
Здравствуйте, Евгений Музыченко, Вы писали:

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

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

ЕМ> Если же библиотеке нужна "тонкая настройка" на целевую платформу (какие-то нюансы аппаратной или программной конфигурации, производительности и т.п.), то конфигуратор должен быть сделан так, чтобы собрать его кросс-средствами было предельно просто, в идеале — в одну командную строку.

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

ЕМ>Ну и так заморачиваться со статической конфигурацией имеет смысл лишь в том случае, когда динамическая (при инициализации библиотеки уже на целевой платформе) обходится неоправданно дорого.

Иногда это просто не возможно.

ЕМ>То есть, проблема снова не в кросс-компиляции, как таковой, а в явной кривизне софта, ей подвергаемого.

Задача: сделать средство кросскомпиляции, которое будет работать для любых целевых архитектур, даже ещё не созданных. Как такую задачу решить?

BFE>>вам хотелось бы увидеть реальные строки из моей рабочей системы?

ЕМ>Да хоть бы пути с измененными именами примерно той же длины, чтобы стало более-менее понятно — реальная там необходимость в длинных путях, или просто причуда.
/asdf/asd/qwe/asd_asdfghjklas/asdfghjklh/adadadada.aaaa.aaaaaaaaaaa/qwertyuouy/sdf/asd_werty/asd/ljutdbms/aassdfgta/xdrtyhbvfgd/ddd.sdfrdgrdg.dd/dft.sgsgsgsgsg/sss_sdfrtgddfvxcdAndhjdjdkdkdkdlAtffhjkklsbddyecetdDuringhdjdlddydbLimitdsSgfhkfifnSkfdkfjjwqwaInvariant.cpp

И это при том, что были предприняты усилия по сокращению длины имён каталогов: многие из имён каталогов были по 40-50 символов длиной, да и вложенность была поболее.

BFE>>Просто ограничение в винде накладывают естественным образом ограничения на пользователей, а вот начинаешь что-нибудь развесистое из другой системы копировать и облом.

ЕМ>Вот и вопрос, отчего оно в той системе такое развесистое. Скажем, насколько часто в программах на C++ встречаются имена, полная запись которых (со всеми namespace-ами, именами классов и прочим) дотянет хотя бы до 200 символов?
Не часто, но встречается.

BFE>>Все исходники открыты, можете заняться.

ЕМ>А мне оно на хрена? Я предпочитаю называть каталоги именами разумной длины, чтоб путь, по возможности, не превышал 100-120 символов.
Так я о том и говорю, никто это чинить не будет.

BFE>>Это не будут чинить по другой причине: поставил WSL и нет таких проблем.

ЕМ>А по какой причине не чинили пятнадцать лет до появления WSL?
Считали извращением кросскомпилировать исходники линаксав не из под линаксов.

BFE>>попробуйте убедить какого-нибудь линуксоида устанавливать библиотеки не в систему, а домашний каталог.

ЕМ>Тогда, наверное, стоило бы при обсуждении проблем с кросс-компиляцией оговаривать, что бОльшая их часть возникает от кривизны рук на разных уровнях.
Почему именно рук?

BFE>>Ну раз должны, тогда надо назначить ответственного. Есть кандидаты?

ЕМ>Ну а кто там в Linux-сообществе отвечает за разработку стандартов и рекомендаций? Вот их и назначать.
Не-не-не. Вам дают продукт как есть: не хотите — не пользуйте.

ЕМ>Если это делается грамотно и корректно в рамках поддерживаемых архитектур — пусть хоть к char'у приводят, но пишут в документации: "библиотека не поддерживает архитектуры, размер указателей в которых превышает sizeof (char)".

Вполне возможно, что где-то в недрах исходников, в комментарии так и написано. И что?

ЕМ>Почти в любой статье о "Unix Philosophy" упоминается о portability over efficiency. А как добиться portability без compatibility?

portability без compatibility — это легко. Это вообще ортогональные понятия.
И каждый день — без права на ошибку...
Re[2]: Raspberry Pi dev device.
От: ononim  
Дата: 27.03.23 14:16
Оценка:
A>Да, кстати, есть такая штука — yocto.
A>https://www.yoctoproject.org/
A>Я пробовал. Оно даже работает.
buildroot проще для восприятия и тоже работает
Как много веселых ребят, и все делают велосипед...
Re[9]: Raspberry Pi dev device.
От: alpha21264 СССР  
Дата: 27.03.23 14:58
Оценка:
Здравствуйте, CreatorCray, Вы писали:

A>>ОС без программ никому не нужна.

CC>Ну т.е. линух не нужен

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

Течёт вода Кубань-реки куда велят большевики.
Re[12]: Raspberry Pi dev device.
От: CreatorCray  
Дата: 28.03.23 01:55
Оценка:
Здравствуйте, B0FEE664, Вы писали:

BFE>/asdf/asd/qwe/asd_asdfghjklas/asdfghjklh/adadadada.aaaa.aaaaaaaaaaa/qwertyuouy/sdf/asd_werty/asd/ljutdbms/aassdfgta/xdrtyhbvfgd/ddd.sdfrdgrdg.dd/dft.sgsgsgsgsg/sss_sdfrtgddfvxcdAndhjdjdkdkdkdlAtffhjkklsbddyecetdDuringhdjdlddydbLimitdsSgfhkfifnSkfdkfjjwqwaInvariant.cpp


На винде:
C:\Windows\servicing\LCU\Package_for_RollupFix~31bf3856ad364e35~amd64~~19041.2006.1.7\amd64_microsoft-windows-fileexplorer.appxmain_31bf3856ad364e35_10.0.19041.1949_none_dde30ee0b2d6f53a\n\squaretile44x44.targetsize-256_altform-unplated_contrast-black_devicefamily-colorfulunplated.png

285 символов, даже подлиннее твоего на глаз
И это в самой винде. Так у меня и 300 символов есть в своих файлах
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[10]: Raspberry Pi dev device.
От: CreatorCray  
Дата: 28.03.23 01:55
Оценка:
Здравствуйте, alpha21264, Вы писали:

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

Перечитай свое сообщение
Автор: alpha21264
Дата: 26.03.23
.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re: Raspberry Pi and programmable logic device, PLD
От: sergey2b ЮАР  
Дата: 28.03.23 02:15
Оценка:
Здравствуйте, c-smile, Вы писали:

подскажите пожалуйста а есть ли готовын решения что бы прикрутит PLD к Raspberry Pi
Re[13]: Raspberry Pi dev device.
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 28.03.23 07:45
Оценка:
Здравствуйте, CreatorCray, Вы писали:

CC>На винде:

CC>C:\Windows\servicing\LCU\Package_for_RollupFix~31bf3856ad364e35~amd64~~19041.2006.1.7

Так это ж чисто внутривиндовые дела, они уже больше двадцати лет не создают проблем. Он-то жалуется на то, что gcc использует ANSI-версии файловых фунций, которые не понимают больше 260. И это правильно — каждой такой функции приходится транслировать путь в Unicode, для чего выделять память в стеке. Снятие ограничения в ANSI (в котором нет никакого смысла) привело бы или к увеличению расхода стека, или к необходимости выделять динамически. Если gcc столько времени тянут на ANSI-функциях, ни длинные, ни национальные имена подавляющее большинство не парят.
Re[4]: Raspberry Pi dev device.
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 28.03.23 07:49
Оценка: +1
Здравствуйте, Skorodum, Вы писали:

S>1. Кросс-компиляция с некоторыми зависимостями может быть проблемной, например Qt.


Как я уже объяснил, это проблема не кросс-компиляции, а линуксового подхода к ней.

S>2. Тестирование после сборки.


Это уже вообще никак не связано с местом сборки. Я свой виндовый софт тестирую в нескольких виртуалках с разными версиями винды, и на одном ноутбуке c Win 7/10, но даже в страшном сне не приходила в голову мысль взгромоздить туда средства разработки.
Re[12]: Raspberry Pi dev device.
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 28.03.23 08:47
Оценка:
Здравствуйте, B0FEE664, Вы писали:

ЕМ>>Если параметрами библиотеки являются известные, фиксированные свойства целевой системы — они должны быть документированы


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


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

BFE>Откуда кросс-средствам знать параметры целевой платформы?


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

BFE>Вы не забывайте, что сами кросс-средства тоже иногда собираются из исходников.


Если они собираются исключительно для использования там же, где собирались — значит, их сборка не имеет никакого отношения к "кросс"-технологиям. Если же там предусмотрена возможность сборки в одной системе (хостовой), а использования — в другой (целевой), то должна быть возможность описать целевую систему явно (в идеале — запуском в ней скрипта, который сформирует набор параметров, который можно будет передать системе сборки в готовом виде).

BFE>Задача: сделать средство кросскомпиляции, которое будет работать для любых целевых архитектур, даже ещё не созданных. Как такую задачу решить?


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

BFE>/asdf/asd/qwe/asd_asdfghjklas/asdfghjklh/adadadada.aaaa.aaaaaaaaaaa/qwertyuouy/sdf/asd_werty/asd/ljutdbms/aassdfgta/xdrtyhbvfgd/ddd.sdfrdgrdg.dd/dft.sgsgsgsgsg/sss_sdfrtgddfvxcdAndhjdjdkdkdkdlAtffhjkklsbddyecetdDuringhdjdlddydbLimitdsSgfhkfifnSkfdkfjjwqwaInvariant.cpp


Мне одному кажется, что здесь видна явная тенденция к удлинению имен сверх разумной, или еще кто-нибудь так считает?

BFE>Считали извращением кросскомпилировать исходники линаксав не из под линаксов.


Как я понимаю, до сих пор считается извращением кросс-компилировать любые линуксовые исходники вне системы, где будет работать софт (упомянутый true linux way"). А многие ли понимают, что это тупиковый путь? Чем это принципиально отличается от использования литералов вместо именованных констант, глобальных переменных вместо параметров функций и т.п?

ЕМ>>Тогда, наверное, стоило бы при обсуждении проблем с кросс-компиляцией оговаривать, что бОльшая их часть возникает от кривизны рук на разных уровнях.


BFE>Почему именно рук?


Потому, что выражение такое. Если что-то получается плохо, принято говорить о кривых руках, даже если в основе лежит кривая идея.

BFE>Вам дают продукт как есть: не хотите — не пользуйте.


А какие соображения поддерживают оставление продукта в таком состоянии?

ЕМ>>пусть хоть к char'у приводят, но пишут в документации: "библиотека не поддерживает архитектуры, размер указателей в которых превышает sizeof (char)".


BFE>Вполне возможно, что где-то в недрах исходников, в комментарии так и написано. И что?


Я б такую библиотеку использовал лишь в крайних случаях, когда без нее совсем никак. Насколько часто такое бывает? Я еще могу понять, когда такое используется "чиста у себя" — "как-то получилось, и хрен с ним". Но получается, что такие библиотеки регулярно включаются в массовые продукты, и это считается вполне нормальным.

BFE>portability без compatibility — это легко.


Compatibility — это ж не только о двоичной совместимости. Это совместимость и по идеологии, набору функций, файловым системам, ключевым утилитам, их параметрам и функциональности и прочему. Если в линуксе на какой-то платформе не будет bash'а или совместимой с ним оболочки, а все скрипты будут переписаны на другой язык — это будет еще линукс, или уже что-то другое?

Ну и сама идея portability автоматически подразумевает, что хотя бы первая сборка ядра и основного софта под новую платформу будет проходить в другой системе. Тут бы и сообразить, что описание целевой системы в явном виде должно быть правилом, а не исключением для таких случаев.
Re[2]: Raspberry Pi and programmable logic device, PLD
От: ononim  
Дата: 28.03.23 11:07
Оценка:
S>подскажите пожалуйста а есть ли готовын решения что бы прикрутит PLD к Raspberry Pi
Надо прям распберри? Просто девайсинка типа EBAZ4205 не покатит?
Как много веселых ребят, и все делают велосипед...
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.