Вы писали "можете показать" применительно к некоторому бинарю. Это, как минимум, требует от меня выяснения что за бинарь вы притащили, и проведение некоторого обьёма исследований. Такой объём это уже не "можете показать", а хотя бы наличие просьбы.
И да, те 50кк строк исходников, про которые вы говорите, прекрасно могут в течение жизненного цикла отдельного релиза ужаться на порядки.
Это ещё почему ? Наоборот, как показывает практика, размер BSP только увеличивается, с ходом жизненного цикла продукта.
FLS - это образ файловой системы
Прекрасно. И что дальше ?
И в каждом из вариантов, и во всех оверлеях (!!!) есть те самые слепки окружения шелла со всеми переменными. И не по одному разу.
Ну напишите производителю, что апдейты можно сделать более компактными. Только я не пойму причём тут апдейты вообще. Речь о размере самого ПО.
Да, вот только это не мобильный телефон, а модем.
Модем это весьма сложное устройство, и с аппаратной т.з., и с программной. Особенно если это современный модем. Гляньте на размеры бинарников у Qualcomm. Бинарник модема запимает около 70мб, из которых примерно половина - сжата проприетарным аналогом ZIPа, и распаковывается on demand. Т.е. несжатого кода, который реально исполняется, там значительно больше 70мб. При том, что для усложнения отладки, огромное число диагностических сообщений удалено, и заменено на их хеш. А это ещё многие мегабайты информации.
И да - там тоже есть неизбежная поддержка со стороны HLOS.
натурально, полные слепки переменных во время сборки, включая флаги gmake и вообще всё остальное
В линукс ядре есть сжатый текстовый конфиг, с которым было собрано ядро. А также имена сотен тысяч символов (функции, переменные) и их адресов в памяти. Тоже в сжатом виде.
Вы заявили, что раздувание кода прошивки модема имеет смысл
Где ?
Я говорил что современный софт намного сложнее, чем это видит автор статьи. И привёл модем в качестве примера.
Согласен, это не раздувание исходногокода, это хуже - раздувание бинаря, нет, бинарей ФС прошивки
Осталось показать, что это "раздувание" хоть сколько-нибудь существенное. Возможно при сборке просто забыли отключить какую-то отладочную подсистему. Был уже такой конфуз с VxWorks, в середине нулевых. На размер это особо не повлияло, зато открыло всем бекдор.
А если у разраба низкая социальная ответственность самооценка, которая не зависит от производимого им кода - получаем неадекватное ПО. Неадекватное требованиям заказчика, неадекватное потребностям конечного пользователя, неадекватное фазе луны и политическому курсу текущего режима (зачеркните лишнее).
Пока вижу только вашу истерику. В чем состоит неадекватность ПО ? Или несоответствие требованием ? Одних оголтелых заявлений недостаточно.
Не помню, приводил ли я в пример BCM. Так вот, Broadcom лицензирует фирмварь на уровне фич. Все фичи одновременно тупо не влезут в RAM чипа. Поэтому вендоры таскают несколько сборок, с разным набором фич. Запуская ту, которая нужна в данный момент (например, с фичей поднятия точки доступа на телефоне).
Какой вы видите выход ?
Разработка нового чипа, где будет больше RAM ? Дорого, очень долго.
Переработка всей прошивки ? Дорого, долго, не факт что вообще возможно.
Собрать несколько разных прошивок, под свои задачи ? Нееее, перфекционисты в интернетах могут оказаться недовольны)))
Кстати, там ещё патчи на ROM есть, и они зверски расходуют RAM. А иначе не закрыть дыры, которые обнаружились в ROM коде. Понимаете ? Наличие security багов не является поводом для перевыпуска чипов. Вместо этого используют продвинутые механизмы патчинга. А уж размер фирмвари и тем более поводом не является.
Hе я предложил строками исходника меняться, а автор. Я наоборот подчеркнул, что в конкретном линуксовом ядре бОльшая часть строк не будет задействована.
Во-первых, с какого перепугу вы требуете от меня что-то обьяснять по хз каким файлам ?
Во-вторых, налицо непонимание, что такое "строки". Нет, это не выхлоп утилиты "strings". Речь о строках исходного кода.
В-третьих, я понятия не имею даже на каком языке написаны бинарники, по которым вы хотите получить от меня информацию. Я не их автор, и никаким образом с ними не связан. Давайте предположим что это С или С++.
The compiler is allowed, but not required, to combine storage for equal or overlapping string literals. That means that identical string literals may or may not compare equal when compared by pointer.
Т.е. компилятор может зареюзать одинаковые литералы. Но не обязан. А также строки могут быть неконстантными, и представлять собой массив символов в BSS. В таком случае компилятор вообще бессилен сделать реюз (для простоты понимания - представьте что указатель на эту строку отдаётся куда-то наружу, и внешний код может поменять данные по его адресу. Изначально строка-массив просто чем-то заполнена дефолтным, и это значение может (и должно) меняться в процессе работы.
Также неясно что такое "fls" вообще. Это может быть контейнер, из которого достаются отдельные файлы. И три экземпляра - это три различные прошивки, из которых выбирается к загрузке нужная. Это может быть единственная прошивка, а три экземпляра - это три разных функциональных блока, которые могут менять свой набор данных независимо. По крайней мере с т.з. компилятора.
Ну и напоследок. С чего вы, чёрт возьми, взяли, что файл должен обновляться весь целиком ? Уже десятки лет сущетствуют инкрементальные обновления. Которые затронут только изменившиеся части при апдейте. Может здесь применяться подобная технология ? На мой взгляд - запросто.
Наезд на 29 мегабайт - ойвей, 2023 год на дворе, сейчас полное обновление для мобильного телефона(!!!) занимает по 2-4гб.
Вообщем моё мнение - и комментарий не по адресу, и явное отсуствие попытки разобраться в деталях самостоятельно.
Linux — штука более серьёзная, в нём больше 15 миллионов строк
Это только ядро. Далеко не самая объемная часть. Сравните его собранный размер (обычно менее 30мб) с размером дистрибутива. Прикиньте, из скольки миллионов (миллиардов) строк он собран.
Из этих строк (навскидку) 2/3 это поддержка железа: различные драйвера и архитектуры, в т.ч.настолько специфичные, что вы их не увидите никогда.
в «Мерседесе», помимо собственно автомобиля, едет 100 миллионов строк кода. Я не знаю, стоит ли такому верить, и думаю, даже если стоит, эти строчки кода довольно бессмысленные.
Размер прошивки GSM модема больше линуксового ядра где-то на порядок (уже ~50млн строк) и они совсем не бессмысленные.
Похоже вы сами совершаете свою же ошибку
Молодые разработчики не всегда понимают, насколько монструозны проекты «первой» культуры
и просто не осознаёте сложность современных систем.
Браузеры, драйвера современных видеокарт по сложности сопоставимы со сложностью целой ОС, включая юзермод.
Если библиотека настолько отвратительного качества, что базовые вещи оборачиваются в "тако-о-о-о-е...." - то да, извините, но вы некомпетентны, раз выбрали ее.
А в чем проблема ? Такие проекты и клиенты тоже имеют право быть. Например - заказ некрупной, но сильно уникальной системы. Если вписывается в требования и решает задачи - не пофиг ли, на чем она реализована ?
Откройте для себя опцию "--mirror". И клонирование пройдет намного быстрее, и упаковка будет не нужна, т.к.репозиторий уже в компактном виде и с собранным мусором
Например аппараты Sharp это Nokia (точнее FIH). Но даже Nokia это не всегда они сами, большинство (все?) трубки на MTK разрабатываются для них силами ODM
4 тысячи рублей стоит 12 ядерный 24 поточный 2678v3. И пусть задачи хоть обожрутся ядрами.
Кстати, оборотная сторона медали повышенной частоты - энергопотребление. Может лучше пусть ядра работают на 80% частоты, но жрут при этом (условно) вдвое меньше ?
Вы писали "можете показать" применительно к некоторому бинарю. Это, как минимум, требует от меня выяснения что за бинарь вы притащили, и проведение некоторого обьёма исследований. Такой объём это уже не "можете показать", а хотя бы наличие просьбы.
Это ещё почему ? Наоборот, как показывает практика, размер BSP только увеличивается, с ходом жизненного цикла продукта.
Прекрасно. И что дальше ?
Ну напишите производителю, что апдейты можно сделать более компактными. Только я не пойму причём тут апдейты вообще. Речь о размере самого ПО.
Модем это весьма сложное устройство, и с аппаратной т.з., и с программной. Особенно если это современный модем. Гляньте на размеры бинарников у Qualcomm. Бинарник модема запимает около 70мб, из которых примерно половина - сжата проприетарным аналогом ZIPа, и распаковывается on demand. Т.е. несжатого кода, который реально исполняется, там значительно больше 70мб. При том, что для усложнения отладки, огромное число диагностических сообщений удалено, и заменено на их хеш. А это ещё многие мегабайты информации.
И да - там тоже есть неизбежная поддержка со стороны HLOS.
В линукс ядре есть сжатый текстовый конфиг, с которым было собрано ядро. А также имена сотен тысяч символов (функции, переменные) и их адресов в памяти. Тоже в сжатом виде.
Где ?
Я говорил что современный софт намного сложнее, чем это видит автор статьи. И привёл модем в качестве примера.
Осталось показать, что это "раздувание" хоть сколько-нибудь существенное. Возможно при сборке просто забыли отключить какую-то отладочную подсистему. Был уже такой конфуз с VxWorks, в середине нулевых. На размер это особо не повлияло, зато открыло всем бекдор.
Пока вижу только вашу истерику. В чем состоит неадекватность ПО ? Или несоответствие требованием ? Одних оголтелых заявлений недостаточно.
Не помню, приводил ли я в пример BCM. Так вот, Broadcom лицензирует фирмварь на уровне фич. Все фичи одновременно тупо не влезут в RAM чипа. Поэтому вендоры таскают несколько сборок, с разным набором фич. Запуская ту, которая нужна в данный момент (например, с фичей поднятия точки доступа на телефоне).
Какой вы видите выход ?
Разработка нового чипа, где будет больше RAM ? Дорого, очень долго.
Переработка всей прошивки ? Дорого, долго, не факт что вообще возможно.
Собрать несколько разных прошивок, под свои задачи ? Нееее, перфекционисты в интернетах могут оказаться недовольны)))
Кстати, там ещё патчи на ROM есть, и они зверски расходуют RAM. А иначе не закрыть дыры, которые обнаружились в ROM коде. Понимаете ? Наличие security багов не является поводом для перевыпуска чипов. Вместо этого используют продвинутые механизмы патчинга. А уж размер фирмвари и тем более поводом не является.
Ленты дешевле, быстрее, надёжнее и удобнее.
И это на фоне лютого снижения продаж ХДД ))
Hе я предложил строками исходника меняться, а автор. Я наоборот подчеркнул, что в конкретном линуксовом ядре бОльшая часть строк не будет задействована.
Во-первых, с какого перепугу вы требуете от меня что-то обьяснять по хз каким файлам ?
Во-вторых, налицо непонимание, что такое "строки". Нет, это не выхлоп утилиты "strings". Речь о строках исходного кода.
В-третьих, я понятия не имею даже на каком языке написаны бинарники, по которым вы хотите получить от меня информацию. Я не их автор, и никаким образом с ними не связан. Давайте предположим что это С или С++.
Т.е. компилятор может зареюзать одинаковые литералы. Но не обязан. А также строки могут быть неконстантными, и представлять собой массив символов в BSS. В таком случае компилятор вообще бессилен сделать реюз (для простоты понимания - представьте что указатель на эту строку отдаётся куда-то наружу, и внешний код может поменять данные по его адресу. Изначально строка-массив просто чем-то заполнена дефолтным, и это значение может (и должно) меняться в процессе работы.
Также неясно что такое "fls" вообще. Это может быть контейнер, из которого достаются отдельные файлы. И три экземпляра - это три различные прошивки, из которых выбирается к загрузке нужная. Это может быть единственная прошивка, а три экземпляра - это три разных функциональных блока, которые могут менять свой набор данных независимо. По крайней мере с т.з. компилятора.
Ну и напоследок. С чего вы, чёрт возьми, взяли, что файл должен обновляться весь целиком ? Уже десятки лет сущетствуют инкрементальные обновления. Которые затронут только изменившиеся части при апдейте. Может здесь применяться подобная технология ? На мой взгляд - запросто.
Наезд на 29 мегабайт - ойвей, 2023 год на дворе, сейчас полное обновление для мобильного телефона(!!!) занимает по 2-4гб.
Вообщем моё мнение - и комментарий не по адресу, и явное отсуствие попытки разобраться в деталях самостоятельно.
Это только ядро. Далеко не самая объемная часть. Сравните его собранный размер (обычно менее 30мб) с размером дистрибутива. Прикиньте, из скольки миллионов (миллиардов) строк он собран.
Из этих строк (навскидку) 2/3 это поддержка железа: различные драйвера и архитектуры, в т.ч.настолько специфичные, что вы их не увидите никогда.
Размер прошивки GSM модема больше линуксового ядра где-то на порядок (уже ~50млн строк) и они совсем не бессмысленные.
Похоже вы сами совершаете свою же ошибку
и просто не осознаёте сложность современных систем.
Браузеры, драйвера современных видеокарт по сложности сопоставимы со сложностью целой ОС, включая юзермод.
Не знаю, куда совать голым. У меня бесшумный десктоп, который не выключается никогда.
Вообще говоря да. Если человек имеет широкий кругозор - то общаться с ним приятнее. Рабочие вопросы решать легче и быстрее.
А как надо было ? Есть конкретная проблема. Она озвучивается. Но никак не может быть исправлена. Это длится несколько итераций.
Если библиотека настолько отвратительного качества, что базовые вещи оборачиваются в "тако-о-о-о-е...." - то да, извините, но вы некомпетентны, раз выбрали ее.
А в чем проблема ? Такие проекты и клиенты тоже имеют право быть. Например - заказ некрупной, но сильно уникальной системы. Если вписывается в требования и решает задачи - не пофиг ли, на чем она реализована ?
Это как ?
И ?
Этот "лёд" скорее от In Circuit Emulator. Аппаратные отладчики. В пику которым был назвал легендарный SoftICE, кстати
Откройте для себя опцию "--mirror". И клонирование пройдет намного быстрее, и упаковка будет не нужна, т.к.репозиторий уже в компактном виде и с собранным мусором
HMD купила бренд Nokia.
Motorola это Lenovo.
Alcatel / Blackberry это TCL.
Vivo / Oppo / Realme это BBK.
Они закрыли смартфонный бизнес.
А кто их действительно выпускает ?
Например аппараты Sharp это Nokia (точнее FIH). Но даже Nokia это не всегда они сами, большинство (все?) трубки на MTK разрабатываются для них силами ODM
NUMA ?
4 тысячи рублей стоит 12 ядерный 24 поточный 2678v3. И пусть задачи хоть обожрутся ядрами.
Кстати, оборотная сторона медали повышенной частоты - энергопотребление. Может лучше пусть ядра работают на 80% частоты, но жрут при этом (условно) вдвое меньше ?