Все это было и в 2000, а если исключить CMake (кроме него существовал давно automake/autoconfig) то и в 90x с кросскомпиляцией проблем не было. Наоборот скорее общее число поддерживаемых архитектур с того времени заметно уменьшилось...
ALPHA, PA-RISC, 68K, TILERA,… Забыли в списке RISC
А какже CISC S3x0, z/Architecture, IA64?
Смысл скорее всех этих действ в замене дорогих UNIX систем на дешевые на основе X86 а вовсе не в смене реальной архитектуры микропроцессора, которая реально довольно часто уже MISC/VLIW.
Загляните в стандарт, типов гораздо больше и они не обязаны быть определены с помощью базовых языковых типов. По поводу линейки char, short, int, long есть только одно ограничение которое состоит в том что размер следующего в линейке не меньше предыдущего, но существуют еще типы с фиксированным размером контейнера и представлением (например int в ILP32 не обязан выражать 32bit отрицательные числа через доролнительный код а int32_t обязан), с минимально гарантированным или оптимальным размером контейнера.
Тип size_t гарантирует возможность адресовать (использовать в качестве смещения) любой доступный объект в используемой модели памяти. Это его назначение. Как следствие этого он (и ssize_t) является результатом для разности однотипных указателей. Хотя для арифметики с указателями рекомендован ptrdiff_t из-за невнятного определения ssize_t в стандарте.
Не от компилятора а от применяемой модели C/C++ ABI.
Причем стандартные(общепринятые) модели в UNIX и WINDOWS отличаются.
Разработчиеи из мира M$ решили, что наиболее просто сделать переход с ILP32 на 64bit архитектуру за счет ABI LLP64 (sizeof(int)=4, sizeof(long)=4 sizeof(void*)=8 sizeof(__int64)=8) это было обусловлено в основном плохим качеством кода и плохим знанием стандартов программистами, пренебрежением стандартов разработчиков VS (например использованием в качестве контейнеров фиксированного размера типов SHORT, INT,LONG etc и неиспользования по назначению size_t,ptrdiff_t, отсутствию stdint.h и inttypes.h можно очень долго перечислять. Где-то начиная с 2015 года большинство недостатков несоответствия стандартам в VS было устранено за что ребятам респект, но к сожалению необходимо еще проделать много работы и C99 для VS не скоро будет достигнут)
В мире UNIX процент квалифицированных программистов был гораздо выше, компиляторы и библиотеки были более близки к стандартам поскольку большинство из них имели значительную кроссплатформенную историю, поэтому стандартной стало C ABI LP64 (sizeof(int)=4, sizeof(long)=8, sizeof(long long)=8, sizeof(void*)=8) т.к общепринято было расширять по степени двойки следующие типы из ряда sizeof(char)<=sizeof(short)<=sizeof(int)<=sizeof(long)<=sizeof(long long)
Следует упоминуть конечно про MIPS-III где в unix системах было принято C ABI n32 в котором sizeof(void*)=4 что является весьма неплохой оптимизацией для 64bit систем. Однако архитектурно указатели все равно сериализовывались на стеке в 8 октетов со значением 0xff`ff`ff`ff в месте где положено быть старшей части (которое зависит от используемого endian)
15-20k страниц Обычный объем для UM документации на средненький современный SoC. Надеюсь у ребят стало меньше ошибок в документации. Посмотрел по диагонали по прежнему по уровню еще далеко до документации от INTELL, IBM, ATMEL, AN… но безусловно по объему стало лучше, а вот структура хуже, надеюсь что хоть работает ближе к написанному...
Это уже сейчас не важно. Данное конкурентное преемущество позволило arm в оптимальный момент времени стать самым популярным SoC для смартфонов… чистая стратегическая победа архитектуры.
Arm себя дискредитировала в свете потакания USA в ее недобросовестной конкуренции с Huawei. Сейчас наблюдаются тенденции поиска замены ARM на MIPS, PPC, RISC V. Из всех перечисленных ARM для современных SoC наиболее закрытая попробуйте например сделать низкоуровневую оптимизацию для open cl кода для Mali Gxx или хотябы найти вменяюмую документацию на ее ISA сравните errata на современные ядра для разных архитектур.
Единственная причина доминирования ARM на рынке это встроенная в ядра arm начиная с arm5 java машина. Большинство Arm SoC на рынке так себе, шины так себе (но особенно я не люблю поделки от Ti) чипы от Nvidia не плохи и hisi верхняя линейка норм у atmel самая лучшая документация. Но закрытость софта и документации на компоненты SoC сильно ухудшает качество и увеличивает время разработки сложных, высоконагруженных систем.
Я говорю с высоты 20летнего опыта embedded разработки arch/bsp/kernel/user space (68k, ppc, mips,arm куча микроконтроллеров. Армов разных производителей штук 10, hi3559av100,nvidia tegra k1/tx1/tx2/nano,ti dm368,dm365,dm320… freescale/nxp ls1021a/,atmel sama d5/d3)
Однако если сравнивать с х86 то на тех же задачах устройство на ARM для режима 24х7 имеет в 10раз меньше проблем, потребляет в 2 раза меньше энергии и весит в 2-4 раза меньше и может иметь промышленный диапазон рабочих температур в отличии от x86. А если говорить о надежных рад стойких девайсах для космоса или экстремальных температурах то только PPC на iso.
Сначала нужно убедиться, что это именно так ifconfig -a в помощь. Для поддержки сети вовсе не обязательна эмуляция железа реального сетевого адаптера или виртуальный сетевой адаптер для общения с хост системой можно и в user space весь data link уровень сделать через tun/tap и подобные механизмы. Но конечно существуют и инвазивные методы встраивания в реализацию ipc4/ipv6 в ядре.
Соблюдение совета не курить снижает минимум в 10 раз вероятность рака легких. Лучший рецепт это не попадать в экстремальную ситуацию. Не стоит попадаться на ошибку выжившего (что конечно не отрицает его полезный опыт для людей попавших в подобную ситуацию) и считать что тоже все будет хорошо, лучше заранее снизить риск онкологии. Вести здоровый образ жизни в первую очередь, регулярно проверять организм, чтобы начать лечение отклонений на ранней стадии...
В россии почему-то не особо популярен. В любой вменяемой конторе используют для QA целей например используется expect для систем тестирования. Очень часто встраивается как язык для сборки и автоматизации например в продуктах Xilinx, Altera, Lattice, Cadence (практически во всем серьезном софте для ASIC разработки), пару раз встречал его как движок для логический игр и questов.
Самый быстрый, компактный язык для разработки клиентских GUI приложений для бизнес логики.
Я использую для кроссплатформенных инженерных утилит и систем контроля. Альтернатив по компактности, скорости разработки и богатству сетевых и графических возможностей в этой области у него нет. (работает под всеми Unix подобными OS, в IOS, под Win,Android, встраивается в браузер с плагином)
Конечно такая схема сложнее немножко, но менять размеры/порядок разделов это по сути только изменение адреса образа ядра/app во флешке и опционально cmdline к ядру или дескриптор флешки в fdt если app не загружается в память (мы обычно загружаем, т.к. ставим spi на embedded устройства сейчас SPI флешка это самый дешевый и сердитый вариант).
Нет, хватает.
[uboot][env][old kernel+rootfs][old app][config] ->
[uboot][env][old kernel+rootfs][new kernel+rootfs][config] ->
[uboot][env][new app][new kernel+rootfs][config]
В этой схеме избыточности нет и экономится ресурс флешки. Кроме того ничего не мешает (кроме необходимости модификации uboot, которая итак есть) разделам [kernel+rootfs] и иметь [app] разные размеры.
Правильнее было бы назвать назвать статью Проблемы деградации в bloatware ПО с плохой архитектурой и при использовании неверных подходов к разработке ПО.
В каком месте у C или C++ описанные вами проблемы? Вы случайно не путаете проблемы OS, совместимости с конкретной OS и архитектурой с проблемами языка?
Все это было и в 2000, а если исключить CMake (кроме него существовал давно automake/autoconfig) то и в 90x с кросскомпиляцией проблем не было. Наоборот скорее общее число поддерживаемых архитектур с того времени заметно уменьшилось...
ALPHA, PA-RISC, 68K, TILERA,… Забыли в списке RISC
А какже CISC S3x0, z/Architecture, IA64?
Смысл скорее всех этих действ в замене дорогих UNIX систем на дешевые на основе X86 а вовсе не в смене реальной архитектуры микропроцессора, которая реально довольно часто уже MISC/VLIW.
for (size_t i=0; i < (size_t)len; i++)
Причем стандартные(общепринятые) модели в UNIX и WINDOWS отличаются.
Разработчиеи из мира M$ решили, что наиболее просто сделать переход с ILP32 на 64bit архитектуру за счет ABI LLP64 (sizeof(int)=4, sizeof(long)=4 sizeof(void*)=8 sizeof(__int64)=8) это было обусловлено в основном плохим качеством кода и плохим знанием стандартов программистами, пренебрежением стандартов разработчиков VS (например использованием в качестве контейнеров фиксированного размера типов SHORT, INT,LONG etc и неиспользования по назначению size_t,ptrdiff_t, отсутствию stdint.h и inttypes.h можно очень долго перечислять. Где-то начиная с 2015 года большинство недостатков несоответствия стандартам в VS было устранено за что ребятам респект, но к сожалению необходимо еще проделать много работы и C99 для VS не скоро будет достигнут)
В мире UNIX процент квалифицированных программистов был гораздо выше, компиляторы и библиотеки были более близки к стандартам поскольку большинство из них имели значительную кроссплатформенную историю, поэтому стандартной стало C ABI LP64 (sizeof(int)=4, sizeof(long)=8, sizeof(long long)=8, sizeof(void*)=8) т.к общепринято было расширять по степени двойки следующие типы из ряда sizeof(char)<=sizeof(short)<=sizeof(int)<=sizeof(long)<=sizeof(long long)
Следует упоминуть конечно про MIPS-III где в unix системах было принято C ABI n32 в котором sizeof(void*)=4 что является весьма неплохой оптимизацией для 64bit систем. Однако архитектурно указатели все равно сериализовывались на стеке в 8 октетов со значением 0xff`ff`ff`ff в месте где положено быть старшей части (которое зависит от используемого endian)
Просто для для сравнения чтобы была понятна весовая категория у hi3559av100 далеко не полная документация занимает. порядка 600MiB в архиве.
15-20k страниц Обычный объем для UM документации на средненький современный SoC. Надеюсь у ребят стало меньше ошибок в документации. Посмотрел по диагонали по прежнему по уровню еще далеко до документации от INTELL, IBM, ATMEL, AN… но безусловно по объему стало лучше, а вот структура хуже, надеюсь что хоть работает ближе к написанному...
Это уже сейчас не важно. Данное конкурентное преемущество позволило arm в оптимальный момент времени стать самым популярным SoC для смартфонов… чистая стратегическая победа архитектуры.
Arm себя дискредитировала в свете потакания USA в ее недобросовестной конкуренции с Huawei. Сейчас наблюдаются тенденции поиска замены ARM на MIPS, PPC, RISC V. Из всех перечисленных ARM для современных SoC наиболее закрытая попробуйте например сделать низкоуровневую оптимизацию для open cl кода для Mali Gxx или хотябы найти вменяюмую документацию на ее ISA сравните errata на современные ядра для разных архитектур.
Единственная причина доминирования ARM на рынке это встроенная в ядра arm начиная с arm5 java машина. Большинство Arm SoC на рынке так себе, шины так себе (но особенно я не люблю поделки от Ti) чипы от Nvidia не плохи и hisi верхняя линейка норм у atmel самая лучшая документация. Но закрытость софта и документации на компоненты SoC сильно ухудшает качество и увеличивает время разработки сложных, высоконагруженных систем.
Я говорю с высоты 20летнего опыта embedded разработки arch/bsp/kernel/user space (68k, ppc, mips,arm куча микроконтроллеров. Армов разных производителей штук 10, hi3559av100,nvidia tegra k1/tx1/tx2/nano,ti dm368,dm365,dm320… freescale/nxp ls1021a/,atmel sama d5/d3)
Однако если сравнивать с х86 то на тех же задачах устройство на ARM для режима 24х7 имеет в 10раз меньше проблем, потребляет в 2 раза меньше энергии и весит в 2-4 раза меньше и может иметь промышленный диапазон рабочих температур в отличии от x86. А если говорить о надежных рад стойких девайсах для космоса или экстремальных температурах то только PPC на iso.
Сначала нужно убедиться, что это именно так ifconfig -a в помощь. Для поддержки сети вовсе не обязательна эмуляция железа реального сетевого адаптера или виртуальный сетевой адаптер для общения с хост системой можно и в user space весь data link уровень сделать через tun/tap и подобные механизмы. Но конечно существуют и инвазивные методы встраивания в реализацию ipc4/ipv6 в ядре.
Непонятно зачем такая боль, если можно использовать docker под вменяемыми операционками, просто чтобы показать что умеете готовить кошек?
Соблюдение совета не курить снижает минимум в 10 раз вероятность рака легких. Лучший рецепт это не попадать в экстремальную ситуацию. Не стоит попадаться на ошибку выжившего (что конечно не отрицает его полезный опыт для людей попавших в подобную ситуацию) и считать что тоже все будет хорошо, лучше заранее снизить риск онкологии. Вести здоровый образ жизни в первую очередь, регулярно проверять организм, чтобы начать лечение отклонений на ранней стадии...
Самый быстрый, компактный язык для разработки клиентских GUI приложений для бизнес логики.
Я использую для кроссплатформенных инженерных утилит и систем контроля. Альтернатив по компактности, скорости разработки и богатству сетевых и графических возможностей в этой области у него нет. (работает под всеми Unix подобными OS, в IOS, под Win,Android, встраивается в браузер с плагином)
[uboot][env][old kernel+rootfs][old app][config] ->
[uboot][env][old kernel+rootfs][new kernel+rootfs][config] ->
[uboot][env][new app][new kernel+rootfs][config]
В этой схеме избыточности нет и экономится ресурс флешки. Кроме того ничего не мешает (кроме необходимости модификации uboot, которая итак есть) разделам [kernel+rootfs] и иметь [app] разные размеры.
Совершенно согласен. Если б Tix еще стал стандартом на равне с js в браузерах вообще жизнь бы удалась.
Правильнее было бы назвать назвать статью Проблемы деградации в bloatware ПО с плохой архитектурой и при использовании неверных подходов к разработке ПО.
В каком месте у C или C++ описанные вами проблемы? Вы случайно не путаете проблемы OS, совместимости с конкретной OS и архитектурой с проблемами языка?
Самая первая это ipfw было до 2.1.x ядер. ipchains появился в 2.1.x.