https://www.opennet.dev/openforum/vsluhforumID3/130364.html После года разработки представлен релиз стандартной Си-библиотеки Musl 1.2.4, предоставляющей реализацию libc, которая подходит для применения как на стационарных ПК и серверах, так и на мобильных системах, сочетая полноценную поддержку стандартов (как в Glibc) с небольшим размером, низким потреблением ресурсов и высокой производительностью (как в uClibc, dietlibc и Android Bionic). Имеется поддержка всех обязательных интерфейсов C99 и POSIX 2008, а также частично C11 и набор расширений для многопоточного программирования (POSIX threads), управления памятью и работы с локалями. Код Musl поставляется под свободной лицензией MIT...<br><br>Подробнее: https://www.opennet.ru/opennews/art.shtml?num=59069<br> https://www.opennet.dev/openforum/vsluhforumID3/130364.html#81 Thu, 11 May 2023 06:58:25 GMT &gt; В любом случае проект примечательный &#8212; статически собранный файл на базе alpine <br>&gt; c musl весил в 20-40 раз меньше аналогичного на glibc. Хочется <br>&gt; надеятся, что вся эта экономия не за счёт ассемблерных инструкций, позволяющих <br>&gt; добиться максимальной производительности от железа.<br><br>Основная проблема в удалении "мёртвого" кода линкером. Даже при LTO не всегда возможно определить участки кода, которые при статическом связывании не вызываются. Что бы упростить задачу линкеру, иногда приходится принимать меры в библиотечном коде или вводить условную трансляцию. При создании glibc не ставится цель уменьшить размер исполняемого файла -- там надо, что бы любой школьник мог подгрузить руткит при помощи LD_PRELOAD.<br> https://www.opennet.dev/openforum/vsluhforumID3/130364.html#80 Wed, 10 May 2023 16:08:33 GMT На самом деле разница может быть значительна. Несколько лет назад игрался с этой библиотекой. Там где нужно выжать всё из ЦПУ, производительность программ для рассчётов, собранных с использованием привычной glibc, была в 1.5-2 раза БЫСТРЕЕ чем c musl.<br><br>Ещё, во времена тех экспериментов приятно удивил clang, но то другая история.<br><br>В любом случае проект примечательный &#8212; статически собранный файл на базе alpine c musl весил в 20-40 раз меньше аналогичного на glibc. Хочется надеятся, что вся эта экономия не за счёт ассемблерных инструкций, позволяющих добиться максимальной производительности от железа.<br> https://www.opennet.dev/openforum/vsluhforumID3/130364.html#79 Wed, 10 May 2023 15:52:46 GMT Несколько лет назад мюсли были не совместимы с tcmalloc, от которой зависимы многие серьёзные проекты, такие как базы данных, где тонкая работа с памятью ключевой момент производительности. И это по-моему единственная проблема из сложнорешаемых, которая не позволяла просто так взять и перейти на мюсли по дефолту для любого дистрибутива. Сложнорешаемосто была на стороне разработчиков tcmalloc и никак не зависела от команды musl. Интересно, как сейчас обстоят дела?<br> https://www.opennet.dev/openforum/vsluhforumID3/130364.html#78 Sun, 07 May 2023 15:20:21 GMT &gt; нинужный никому<br><br>Мнение человека, не умеющего писать по русски, очень важно!<br> https://www.opennet.dev/openforum/vsluhforumID3/130364.html#77 Sat, 06 May 2023 06:17:15 GMT Единственный источник тормозов в musl - это аллокатор.<br>Но никто не мешает использовать любой другой, jemalloc тот же.<br> https://www.opennet.dev/openforum/vsluhforumID3/130364.html#76 Fri, 05 May 2023 21:08:24 GMT Здесь некоторые пишут, что musl медленнее glibc. Я решил это проверить и собрал два минимальных образа BuildRoot для OrangePI_PC с двумя этими библиотеками. Конфигурация по умолчанию из BuildRoot, только изменил версию ядра на актуальную. Вот что получилось: https://cloud.mail.ru/public/83jc/MSstJxrFM<br><br>Если кратко, то musl чаще всего немного быстрее, но разница незначительная.<br> https://www.opennet.dev/openforum/vsluhforumID3/130364.html#75 Fri, 05 May 2023 03:45:35 GMT Он не грозит. Он почему-то полагает, что Linux в России не повторит судьбу Windows. Тогда как Microsoft, IBM (RedHat) и прочие спонсоры ушли из России, а компания Meta запрещена и её сотрудники не принимают патчи. При этом сам он никаких гарантий дать не хочет.<br> https://www.opennet.dev/openforum/vsluhforumID3/130364.html#74 Thu, 04 May 2023 23:47:19 GMT Шигорин теперь за мнения технического характера грозит гулагом, когда они ему не нравятся. Что дальше, Миш? Казалось бы уже всё, дальше некуда деградировать, но ты раз за разом находишь способы продолжить.<br> https://www.opennet.dev/openforum/vsluhforumID3/130364.html#73 Thu, 04 May 2023 15:32:01 GMT &gt;&gt; Мои приложения должны работать, а не демонстрировать "прогрессивные" <br>&gt;&gt; технологии. И если меня устраивает Windows, С++ и привязка <br>&gt;&gt; к конкретным архитектурам, то это и есть "достойный" и разумный <br>&gt;&gt; подход.<br>&gt; Ваши пользователи завтра (если не позавчера) заслуженно отведут Вас хорошо если просто <br>&gt; к следователю как саботажника, у которого с 2014 года между левым <br>&gt; ухом и правым ухом так ничего и не щёлкнуло.<br><br>У меня щёлкнуло. Тогда я нарыл в глубинах Qt5 велосипедный dynamic_cast, реализованный как обёртка над dynamic_cast, и понял, что это нельзя использовать, потому что очень скоро компания начнёт выкидывать legacy. Я немного ошибся в прогнозе. Qt не только забросила Qt5, но и ушла из России. Что не мешает этот неподдерживаемый код продавать.<br><br>Кто решит оспорить "неподдерживаемый", пусть расскажет, как активировать отображение контекстного меню не по нажатию ПКМ, а по отпусканию. Это штатная возможность Qt5, не используемая в KDE (много лет висит баг), и где-то здесь валяется мой пример,