Представлен (http://www.openwall.com/lists/musl/2017/10/19/1) релиз стандартной Си-библиотеки Musl 1.1.17 (http://www.musl-libc.org/), предоставляющей реализацию libc, которая подходит для применения как на стационарных ПК и серверах, так и на мобильных системах, сочетая полноценную поддержку стандартов (как в Glibc) с небольшим размером, низким потреблением ресурсов и высокой производительностью (как в uClibc, dietlibc и Android Bionic). Имеется поддержка всех обязательных интерфейсов C99 и POSIX 2008, а также частично C11 и набор расширений для многопоточного программирования (POSIX threads), управления памятью и работы с локалями. Код Musl поставляется (http://git.musl-libc.org/cgit/musl) под свободной лицензией MIT.
В новой версии устранена уязвимость (http://seclists.org/oss-sec/2017/q4/107) (CVE-2017-15650) в коде разбора ответов от DNS-сервера, которая может потенциально привести в выполнению кода при использовании функции getaddrinfo(), в случае если злоумышленник контролирует работу DNS-сервера, указанного в resolv.conf, или может вклиниться в трафик (MITM). В качестве обходного пути защиты можно запустить собственный локальный кэширующий DNS-сервер и указать его в resolv.conf.
Из новых возможностей (https://git.musl-libc.org/cgit/musl/tree/WHATSNEW) можно выделить поддержку отложенной привязки символов (deferred symbol binding) в компоновщике (эмуляция RTLD_LAZY), опцию для переопределения значения argv[0] при запуске программы через ldso, поддержку запуска новых сеансов при помощи posix_spawn (POSIX_SPAWN_SETSID), возможность определения активной для потока локали (расширение _NL_LOCALE_NAME), улучшение совместимости с приложениями, платформами и сборочными системами.URL: http://seclists.org/oss-sec/2017/q4/107
Новость: http://www.opennet.ru/opennews/art.shtml?num=47422
Хм, интересно, будет ли прирост быстродействия на моём нетбуке, если перекатиться на это с glibc?
Нет. http://www.etalabs.net/compare_libcs.html
нашли кого слушатьа ниче что это данные многолетней давности ?
да и сравнение некорректно, т.к. либы собраны
с разной опцией производительности
glibc -O2, а остальные -O0
У musl простой код и малое потребление ресурсов. Но это не способствует рекордной производительности. Хотя-бы по причине того что бывает speed vs memory tradeoff.
> У musl простой кодПосмотрим, сколько еще дыр найдется в этом простом коде.
оно не для прироста а для сокращения объема
Не то спрашиваете. Нужно спрашивать, а можно ли нетбук перекатить на это вообще.Но вообще да, конечно будет. Потому что нетбук будет не занят. Потому что ни че не будет работать.
Это почему это? Накатить на него Alpine, всё будет работать.
не знаю почему. генту собрать не удалось.
https://wiki.gentoo.org/wiki/Project:Hardened_musl> Unlike the situation with uClibc, where pretty much every package in the Gentoo portage tree "just builds," musl's adherence to standards means that many packages which deviate from those standards, primarily POSIX, need some patching.
Новые библиотеки игнорируют сложившиеся ошибочные практики. Это их сильно упрощает, но перекладывает на мэйнтэйнеров работу, которую обычно автоматически делает glibc. В долгосрочной перспективе так, конечно, правильнее.
Еще пол года ждать пока LEDE обновится?
Я правильно понимаю, что, если LEDE использует Musl, значит, мой провайдер может выполнить произвольный код на моём роутере?Веселуха, чо.
> Я правильно понимаю, что, если LEDE использует Musl, значит, мой провайдер может
> выполнить произвольный код на моём роутере?Теоретически может. На практике это пока не доказано. Но да, обновляться надо.
> Я правильно понимаю, что, если LEDE использует Musl, значит, мой провайдер может выполнить произвольный код на моём роутере?
>
> Веселуха, чо.Вы так говорите, как будто это что-то плохое.
Предыдущие два фикса вышли оперативно. Но при такой тенденции им придётся каждую неделю фиксы выпускать.
Они и так очень часто релизятся.
> Они и так очень часто релизятся.Надо бы им перейти на хромовскую систему непрерывной нумерации. Потому что xx.yy.zz.aa, крутящиеся как в одометре - это трешЪ и угарЪ.
Чото она за последнее время два раза прилезла в обновлениях, а новость только одна. Наверное уязвимость только в одном обновлении исправляли.
Обычно второе обновление - это regression fix, когда в первом дыру закрыли так, что софтина начала чудить.
> В новой версии устранена уязвимость (CVE-2017-15650) в коде разбора ответов от DNS-сервера, которая может потенциально привести в выполнению кода при использовании функции getaddrinfo()Что характерно, автор Musl Рич Фелкер люто ненавидит Поттеринга, однако дыры у него беззастенчиво таскает.
Этого ашаурка любой недостаточно флегматичный человек ненавидит, а дыра небось из восьмидесятых кочует.
> Этого ашаурка любой недостаточно флегматичный человек ненавидитС годами это обычно проходит. После восемнадцатого-двадцатого дня рождения уже как-то пофиг.
> а дыра небось из восьмидесятых кочует
Но ведь musl - это инновационная, не имеющая аналогов, полностью написанная с нуля библиотека. Какие там дыры из восьмидесятых?
Или Фелкер таки копипастил не глядя из glibc?
.. но в данном случае ситуация иная - Рич Фелкер вообще очень много чего ненавидит, в частности практически любые фичи/удобства, существующие ценой хотя бы крошечной потери производительности - даже там, где здравый смысл говорит о том, что кроме железа 10-летней давности разницы в производительности нет, а фича нужна всем. Также любые усложнения - даже если они нужны для последующих доработок - ненавидит с маниакальной педантичностью. В общем, скорее всего он половину из того, что использует 90% пользователей линукс ненавидит :)
Меня больше впечатлила его техническая безграмотность. Например, один из главных его аргументов в критике системды - что системда не умеет reexec на лету.
Чувак не удосужился даже минимально погуглить, не то что ман почитать. Инфу про systemctl daemon-reexec даже мой хомяк может найти.
> Меня больше впечатлила его техническая безграмотность. Например, один из главных его аргументов
> в критике системды - что системда не умеет reexec на лету.
> Чувак не удосужился даже минимально погуглить, не то что ман почитать. Инфу
> про systemctl daemon-reexec даже мой хомяк может найти.Цитата:
"With regards to upgrades, systemd's systemctl has a daemon-reexec command to make systemd serialize its state, re-exec itself, and continue uninterrupted. This could perhaps be used to switch to a new version without rebooting. Various programs already use this technique, such as the IRC client irssi which lets you /upgrade without dropping any connections. Unfortunately, this brings us back to the issue of PID 1 being special. For normal applications, if re-execing fails, the worst that happens is the process dies and gets restarted (either manually or by some monitoring process) if necessary. However for PID 1, if re-execing itself fails, the whole system goes down (kernel panic)."Кажется, про daemon-reexec он в курсе, это просто ты читать не умеешь.
Это он уже потом жoпкой вилять начал.
Сначала было "sysvinit может reexec, а systemd нет, и поэтому он отcтой".
> Это он уже потом жoпкой вилять начал.
> Сначала было "sysvinit может reexec, а systemd нет, и поэтому он отcтой".Где он такое писал? Можно ссылку? В мэиллистах busybox, из которых родился его пост, на ewontfix, на который я сослался, ничего такого нет.
Или ты про это:
"Inability to upgrade all the functionality that's been moved into
systemd without rebooting, due to the inability to kill and restart
pid #1."?(http://lists.busybox.net/pipermail/busybox/2014-February/080... цитата не полная)
Если прочитать трэд дальше, видно, что речь о том, что нельзя НАДЁЖНО и ГАРАНТИРОВАННО обновить systemd, ибо есть много причин, по которым reexec может закончиться провалом, что приведёт к падению init и kernel panic. А не о том, что он утверждает, что systemd не умеет reexec в принципе.
Чтобы он топил за sysvinit я также не видел.
В посте на ewontfix он приводит пример идеального init в его понимании, и только.Суть его претензий к systemd в том, что куча лишнего засунуто в PID 1, что черевато. Как я понимаю его подход, он предлагает делать init максимально простым, статически слинкованный бинарником, который нет даже необходимости обновлять когда либо, а все остальные fancy-возможности делать сбоку от PID 1, чтобы он никогда не упал.
В BSD системах (по крайней мере в FreeBSD и OpenBSD) init - это как раз статически слинкованный бинарник. Аналогичное, ЕМНИП, в клонах daemontools и/или runit (могу врать, давно на них не смотрел).
Это пример адекватного подхода.
Засовывать всё в PID 1, ошибка в котором грозит крахом системы - пример неадекватного.Всё просто, не?
> Меня больше впечатлила его техническая безграмотность. Например, один из главных его аргументов
> в критике системды - что системда не умеет reexec на лету.
> Чувак не удосужился даже минимально погуглить, не то что ман почитать. Инфу
> про systemctl daemon-reexec даже мой хомяк может найти.ашаурок не осилил читать логи и написал жорналдэ, это гораздо круче
> ашаурок не осилил читать логи и написал жорналдэ, это гораздо кручеРазработчики Ъ юниксов (Solaris/HP-UX/AIX) придумали бинарные логи задолго до него.
Знаю, и потому очень сильно озабочен грядущей смертью обычного мейснтримного линукса. Слава таким парням, как разработчики musl и openrc.
> .. но в данном случае ситуация иная - Рич Фелкер вообще очень
> много чего ненавидит, в частности практически любые фичи/удобства, существующие ценой
> хотя бы крошечной потери производительности - даже там, где здравый смысл
> говорит о том, что кроме железа 10-летней давности разницы в производительности
> нет, а фича нужна всем. Также любые усложнения - даже если
> они нужны для последующих доработок - ненавидит с маниакальной педантичностью. В
> общем, скорее всего он половину из того, что использует 90% пользователей
> линукс ненавидит :)А можно какие-то примеры публичных высказываний Рича про удобства/производительность?
Можно погуглить рассылки mplayer где-нибудь 10-15 давности, он много кода там ревьюил и комментировал.
> Можно погуглить рассылки mplayer где-нибудь 10-15 давности, он много кода там ревьюил
> и комментировал.Так почему бы не погуглить, если можно?
Ты, в отличие от меня, хотя бы примерно знаешь, что и где искать.
А то ведь хорошо получается, назвал человека ретроградом, а пруфов нема.
Нет, более детально выискивать пруфы я не собираюсь - писал он (в mplayer-dev) в то время очень много, немало и по делу (собственно, он был один из разработчиков), но реакции, как я описал проявлялись тут и там достаточно ярко. Но в массе постов выискивать их я не хочу, не хотите - не верьте )Я, строго говоря, не скажу прямо так уж про ретроградство. Просто есть такие люди, которые в описаниях любых технологий и разработок заявляют, что мол на их втором пеньке в кладовке с 256 мегами памяти это не нормально заработает, поэтому разработчики должны удавиться и научиться программировать и вообще писать все на асме, а потом уже в люди лезть и какие-то разработки миру показывать. Вот у него подобные проявления были, что - в отличие от просто троллей в интернете - необычно смотрелось на фоне того, что он сам разработчик и код пишет и свои вещи знает вроде бы хорошо. Но готов отвергнуть любую, сколько-либо желанную фичу из-за неидеальной реализации - как в плане скорости, так и (например) объема кода. Glibc, кстати, он в первую очередь за последнее не терпит, и по фигу, насколько там универсальные и полные реализации - кода много, значит априори плохо и надо переписать. Ну да, много. Ну да, плохо. Но обычно это менее важно, чем полнота и фичастость реализации. А для него - нет, фичастость для пользователей менее важна, чем идеальность кода.
> Нет, более детально выискивать пруфы я не собираюсьТак и запишем: мир, дверь, мяч.
> Но в массе постов выискивать их я не хочу, не хотите - не верьте )
Я не то чтобы верю или не верю. Просто сам я у него не замечал неадекватных, на мой вкус, высказываний, а обсуждать его позицию исходя из данных агентства ОБС не вижу смысла.
> кроме железа 10-летней давности разницы в производительности нетТы про какое железо сейчас, про роутеры?
прикольный чувак, успехов ему
> Что характерно, автор Musl Рич Фелкер люто ненавидит Поттеринга, однако дыры у
> него беззастенчиво таскает.Шта? Поттеринг-то тут каким боком?
>> Что характерно, автор Musl Рич Фелкер люто ненавидит Поттеринга, однако дыры у
>> него беззастенчиво таскает.
> Шта? Поттеринг-то тут каким боком?Он теперь Главнюк по DNS-ам. BIND фсйо.
> Он теперь Главнюк по DNS-ам. BIND фсйо.BIND еще поставить надо. А resolved/musl обычно идет из коробки (на разных системах конечно, но все же).
>> Шта? Поттеринг-то тут каким боком?
> Он теперь Главнюк по DNS-ам. BIND фсйо.А это слово, точно и емко характеризующее Горшечника, точно с 'л' пишется?
Друзья, а подскажите пожалуйста, с этой либой если вместо glibc всё линкуется, то меньше памяти занимают программы и быстрее работают?Извините за глупый может вопрос.
> Друзья, а подскажите пожалуйста, с этой либой если вместо glibc всё линкуется,
> то меньше памяти занимают программыВ некоторых случаях действительно могут занимать меньше места. Но абсолютное большинство программ, помимо libc, используют и другие библиотеки, так что на практике выигрыш может быть незаметен.
> и быстрее работают?
Это вряд ли. Обычно либо меньше памяти, либо быстрее работать.
> В некоторых случаях действительно могут занимать меньше места. Но абсолютное большинство программ, помимо libc, используют и другие библиотеки, так что на практике выигрыш может быть незаметен.На самом деле абсолютно все библиотеки в таком случае прийдётся линковать с musl. Поэтому выйгрыш может быть значительный. В противном случае будет статическая линковка.
> Это вряд ли. Обычно либо меньше памяти, либо быстрее работать.
Не забывайте про буфер TLB. Чем больше памяти используется, тем чаще будут попадания мимо кеша TLB, тем меньше будет производительность. Скорее всего частично по этой причине продукты, написанные на java очень медленно работают по сравнению с аналогами на Си или даже C++.
> На самом деле абсолютно все библиотеки в таком случае прийдётся линковать с musl. Поэтому выйгрыш может быть значительный.Во-первых, "вы*и*грыш" и "придётся". Во-вторых, нет никакой разницы, с какой libc слинкована библиотека, сама-то она столько же памяти откушает (в пределах погрешности).
> В противном случае будет статическая линковка.
В противном чему случае? И почему она непременно будет?
> В противном чему случае? И почему она непременно будет?Если Вы захотите в дистрибутиве, где используется одна libc-библиотека использовать другую libc-библиотеку. И то, будут большие проблемы, если вы попытаетесь использовать стандартные библиотеки дистрибутива.
Не знаю, где ты нашёл какие-то проблемы.$ ldd hello_glibc
linux-vdso.so.1 (0x00007ffe5cbbc000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fcf069ba000)
/lib64/ld-linux-x86-64.so.2 (0x000055e8aa317000)
$ ldd hello_musl
./hello_musl: error while loading shared libraries: /usr/lib/x86_64-linux-gnu/libc.so: invalid ELF header
$ musl-ldd hello_musl
/lib/ld-musl-x86_64.so.1 (0x5560ca667000)
libc.so => /lib/ld-musl-x86_64.so.1 (0x5560ca667000)
$ ./hello_glibc
hi!
$ ./hello_musl
hi!
$
И? Я не вижу использования какой-либо библиотеки, зависимой от libc у Вас в hello_musl. Hello World на musl и я могу написать, тут проблем никаких не будет.
Библиотеки, разумеется, тоже надо будет пересобрать. А видеть надо было не их использование, а отсутствие статической линковки, несмотря на наличие в системе двух разных libc.
Ага, а теперь подумаем дальше. Предположим Вам требуется фреймворк какой-то, ну пересоберёте Вы все библиотеки, потратите много времени, а потом окажется, что у Вас используется ПО, которое от этого фреймворка зависит. Вы психанёте и, скорее всего, статическую линковку использовать будете, т. к. со сборкой с rpath может не везде оказаться просто.
Если ты не понял из приведённого выше примера, я использую дистрибутив, разработчики которого осилили multilib. Библиотека, собранная с musl и установленная в /usr/lib/x86_64-linux-musl, спокойно может сосуществовать с библиотекой, собранной с glibc и установленной в /usr/lib/x86_64-linux-gnu. Так что поводов психовать нет.
Ну, если только на пересборке N-й библиотеки...
Только вот в той-же libc есть математическая библиотека, где используется векторизация, SSE, AVX и прочее и прочее. Так вот, если делать так, чтоб максимально меньше памяти занимало, то все это идет лесом.
> Только вот в той-же libc есть математическая библиотека, где используется векторизация,
> SSE, AVX и прочее и прочее. Так вот, если делать так,
> чтоб максимально меньше памяти занимало, то все это идет лесом.А ну еще выравнивание памяти сильно память отъедает, только вот в скорости выигрывает. Оптимизации под конвеер (пустые nop'ы все дела) тоже память не экономят.
> А ну еще выравнивание памяти сильно память отъедает, только вот в скорости
> выигрывает. Оптимизации под конвеер (пустые nop'ы все дела) тоже память не
> экономят.Ну есть мнение, что выравнивание за счет увеличения памяти, на архитектурах с внешним CISC-ом и внутренним RISC-ом (практически все современные i386 x86-64), в скорости не выигрывают (за исключением некоторого небольшого подмножества случаем). И выравнивать - это просто дань традиции и потому, что в gcc не поменяны настройки по умолчанию для режимов оптимизации в соответствии с вовременными реалиями
> Друзья, а подскажите пожалуйста, с этой либой если вместо glibc всё линкуется,
> то меньше памяти занимают программы и быстрее работают?В случае _статической_ линковки занимают меньше места, работают в среднем чуть медленнее или в редких случаях могут не работать вовсе. Однако сравнение не совсем корректно, так как статическая линковка с glibc является проблемой, ряд функций из нее требуют наличия отдельно установленной glibc той же версии в системе. Так что дело не столько в меньшем размере, сколько вообще в наличии возможности полноценной статической линковки.
Основное предназначение musl это контейнеры и embed. Использовать ее для "улучшения" полноценного десктопа удел условного "школоло"
Вы, наверное, ошиблись, - занимают больше места. Потому как вероятность, что другой такой библиотеки (в зависимостях установленного ПО) не будет в дистрибутиве - нулевая.
Еще раз для особо одаренных. Оно не для замены glibc в ваших дистрах, оно совсем для другого, ключевые слова(статическая линковка, контейнеры, embed) можешь погуглить, но если не поймешь, то спрашивай, объясню с примерами.
> Еще раз для особо одаренных. Оно не для замены glibc в ваших
> дистрах, оно совсем для другого, ключевые слова(статическая линковка, контейнеры, embed)
> можешь погуглить, но если не поймешь, то спрашивай, объясню с примерами.Я Вам не про замену, а про статическую линковку говорил. Для каждого приложения статически слинкованная libc приведёт к огромному размеру установленного ПО.
А вот Вам про замену в наших дистрибутивах:
https://alpinelinux.org/posts/Alpine-Linux-has-switched-to-m...
https://ru.wikipedia.org/wiki/Alpine_Linux
Я использую Docker, поэтому использую как минимум один дистрибутив, который уже перешёл на musl.
> Я Вам не про замену, а про статическую линковку говорил. Для каждого приложения статически слинкованная libc приведёт к огромному размеру установленного ПО.Спасибо, кэп, я же за двадцать лет опыта программистом ни за что не догадался бы. А теперь напряги извилины и подумай, зачем всё-таки иногда используют статическую линковку.
> Я использую Docker, поэтому использую как минимум один дистрибутив, который уже перешёл на musl.
И как и большинство любителей докера неспособен смотреть в корень. Во-первых, в alpine по прежнему есть glibc, так как не все программы нормально работают с musl, о чем я говорил с самого начала. Во-вторых, причина малого размера контейнера alpine в первую очередь в busybox, а не в musl. Поставь туда весь набор софта из debootstrap и получишь совсем небольшую разницу. musl же экономит 7.4MB однократно на .so и целых 28KB на каждую программу.
Ну и отдельно отмечу, что я говорил про десктопные дистры, к коим alpine не относится. А относится он как раз к задаче контейнеров. Или ты не в курсе даже о том, что докер это одно из решений контейнеризации?
> Во-первых, в alpine по прежнему есть glibcНет.
Посмотрел, действительно уже нет. Приходится людям с какой-нибудь из реп на гитхабе ставить ее.
> Посмотрел, действительно уже нет. Приходится людям с какой-нибудь из реп на гитхабе
> ставить ее.Зачем? Посмотрел, вроде поддерживаются GNU-расширения языка. Поэтому никто даже не почувствует разницы между библиотеками, если одну на другую в дистрибутиве поменять.
Для использования бинарников, слинкованных с glibc.
Подразумевается скачанных? ln может всё-таки?
Прошу прощения, ляпнул не подумавши, здесь моих текущих знаний недостаточно. Кажется, это повод почитать на досуге про процесс линковки и таблицы символов. Извините.
> Приходится людям с какой-нибудь из реп на гитхабе ставить ее.Нет.
У Вас может быть и есть 20 лет опыта, но я не вижу профессионализма. То, что Вы не можете признавать свои ошибки и спокойно это воспринимать (попытки доказать, что всё равно были правы, но Вам неправильно поняли), а также не задаёте вопросов в духе "имелось в виду это, либо это?" и "почему?". Это уже показатель, что у Вас merge request'ы не используются. А дальше логические цепочки доведут и до качества кода. Прав я?
> То, что Вы не можете признавать свои ошибки и спокойно это воспринимать (попытки доказать, что всё равно были правы, но Вам неправильно поняли)И где же у меня ошибка, кроме как с наличием glibc в современном alpine, которую я признал?
> а также не задаёте вопросов в духе "имелось в виду это, либо это?" и "почему?"
Если ТЫ не понимаешь, о чем я говорю, то это ТЫ должен задавать мне такие вопросы, а не наоборот. Я могу спросить лишь другое: "ты домашнее задание по поиску usecase для статической линковки выполнил?"
Мне было интереснее узнать ответ на свой последний вопрос. Насчёт merge request'ов. Впрочем ответ я уже не увижу, а у Вас по вечерам будут поводы для раздумий о всём своём накопленном опыте. Люди, которые умеют быстро обучаться могут за 3 года получить больше опыта, чем спорщики за 20 лет, если всё время правильно направлять. Я, например, сейчас такого обучаю. Я не собираюсь указывать, где и в чём Вы ошибались, просто дружеский совет о том, что можно и не пытаться красоваться, резко реагировать на все высказывания, фамильярничать. Всегда найдётся человек, кто знает больше Вас. Это не обязательно буду я, это может быть любой случайный зевака, решивший узнать текущее мнение народа. А умение быстро обучаться предполагает не восприятие в штыки любой новой информации, а диалог, в ходе которого люди выясняют правильную точку зрения и пытаются правильно понять друг друга. В заметной части случаев ярые споры рождаются из-за непонимания, когда обе стороны пытаются доказать одну и ту же точку зрения разными словами.
Молодец, следуешь правилам демагога, когда нечего ответить по сути, надо либо переходить на личности, либо срываться в словоблудие. Вот только меня спор ради спора не интересует. Гуляй.