После трёх лет разработки представлен (http://www.openwall.com/lists/musl/2014/03/20/1) первый значительный релиз новой стандартной Си-библиотеки Musl 1.0.0 (http://www.musl-libc.org) (libc), ориентированной для использования в Linux-устройствах нового поколения. Библиотека отличается (http://www.etalabs.net/compare_libcs.html) небольшим размером, высокой производительностью, безопасностью, простотой и соблюдением стандартов. Автором проекта является Рич Фелкер (Rich Felker), участник проекта Openwall и член группы Austin Group, развивающей и поддерживающей стандарты POSIX. Код Musl поставляется (http://www.musl-libc.org/download.html) под свободной лицензией MIT.Musl является универсальной реализацией libc и подходит для применения, как на стационарных ПК и серверах, так и на мобильных системах, сочетая полноценную поддержку стандартов, свойственную для полновесных библиотек, таких как Glibc (GNU C library), с небольшим размером, низким потреблением ресурсов и высокой производительностью, свойственными специализированным вариантам libc для встраиваемых систем, таких как uClibc, dietlibc и Android Bionic. Musl предоставляет (http://wiki.musl-libc.org/wiki/Compatibility) полную поддержку всех обязательных интерфейсов C99 и POSIX 2008, а также частично C11 и набор расширений, получивших распространение в Linux-окружениях. В том числе библиотека предоставляет средства для многопоточного программирования, управления памятью и работы с локалями.
Проект Musl старается придерживаться совместимости с Glibc в части функциональности, как на бинарном уровне, так и на уровне исходных текстов. При этом, Musl не ставит перед собой цель обеспечения совместимости с Glibc на уровне ошибок (http://wiki.musl-libc.org/wiki/Functional_differences_from_g...), идущих в разрез со стандартами. На уровне исходных текстов обеспечена достаточно неплохая совместимость с Glibc. На бинарном уровне совместимость ещё оставляет желать лучшего - хотя уже можно загружать при использовании musl некоторые динамические библиотеки, собранные с Glibc, запуск приложений при замене /lib/ld-linux.so.2 на musl пока не поддерживается.
Что касается несовместимости на уровне кода, если работающее с Glibc приложение не удаётся собрать с Musl, то, как правило, проблемы вызваны ошибками при формировании списка директив include, указанием нестандартных элементов (например, __pid_t вместо pid_t) или использованием программных интерфейсов, пока не доступных в musl. В настоящее время сборка с Musl успешно протестирована на более чем 5000 пакетах из архива pkgsrc.
Musl поддерживает (http://wiki.musl-libc.org/wiki/Supported_Platforms) работу только в Linux и может работать с ядрами Linux, начиная с выпуска 2.6.39. Официально поддерживаются следующие архитектуры: i386, x86_64, ARM (armv4t и новее), MIPS, PowerPC и Microblaze. Экспериментальная поддержка обеспечена для SuperH (SH) и x32. Из компиляторов поддерживаются GCC 3.4.6+, Clang 3.2+, PCC 1.1.0+ и CParser/firm (http://pp.ipd.kit.edu/firm/).
На базе Musl уже развивается (http://wiki.musl-libc.org/wiki/Projects_using_musl) несколько дистрибутивов Linux, среди которых проекты OSv (http://www.opennet.dev/opennews/art.shtml?num=37936), Sabotage (https://github.com/sabotage-linux/sabotage), LightCube OS (https://github.com/jhuntwork/lightcube-bootstrap-musl), starchlinux (http://starchlinux.org/), morpheus (http://git.2f30.org/morpheus/) и Snowflake (https://bitbucket.org/GregorR/snowflake). Musl также применяется в компиляторе Emscripten (http://emscripten.org/), используемом для преобразования C/C++ проектов в представление на JavaScript. Из известных дистрибутивов, в которых обеспечена опциональная поддержка Musl, можно отметить Debian, Ubuntu, OpenWrt, Gentoo и Arch Linux. Среди дистрибутивов, планирующих переход по умолчанию на Musl: Aboriginal (http://landley.net/aboriginal/), Alpine (http://alpinelinux.org/) и Dragora (http://www.dragora.org/).
URL: http://www.openwall.com/lists/musl/2014/03/20/1
Новость: http://www.opennet.dev/opennews/art.shtml?num=39365
>отличается небольшим размеромнасколько может быть большим исполняемый файл, компилируемый из того что написано на си?
>высокой производительностьюпроизводительность там, где есть хорошие алгоритмы, а не маленький размер
>безопасностьюбезопасный код тот, который проверен большим сообществом пользователей и разработчиков, поскольку даже Hello World может быть написан с кучей уязвимостей.
>простотойпростота означает лишь то, что кому-то придётся от чего-то отказаться
>соблюдением стандартовну это вообще ни в какие ворота, пусть посмотрят на то, что поддерживает glibc
Доводы "самых хитрых" всегда надо читать наоборот. Во первых проплатили чтоб переписал под нужной лицензией. Во вторых писал с нуля, используя все новье что есть, отсюда плюшки. Ну а дальше что смог то и осилил, до сообщества далековато.
> Во вторых писал с нуля, используя все новье что есть, отсюда плюшки.Судя по "частичной поддержке C11", не такое уж и новье.
Или вы имели в виду что-то другое?
> насколько может быть большим исполняемый файл, компилируемый из того что написано на си?В xonotic до 6Мб бинарей догнались, например :). Нормально?
Как минимум на пару твоих «утверждений» есть ответ в самой статье, которую можно было бы и прочитать более внимательно.> насколько может быть большим исполняемый файл, компилируемый из того что написано на си?
В статье чётко указано сравнение с компонентами glibc. Вплоть до дополнительных 1-1.5 Мб. Даже в Hello World 500 Кб оверхеда.
> безопасный код тот, который проверен большим сообществом пользователей и разработчиков, поскольку даже Hello World может быть написан с кучей уязвимостей.
Не совсем корректное утверждение. «Хорошо» проверенный, но запутанный или просто слишком огромный код потенциально более уязвим, чем менее проверенный, но и менее запутанный, и более лаконичный код. Для проверки и выявления уязвимостей в последнем требуется куда меньше ресурсов.
> ну это вообще ни в какие ворота, пусть посмотрят на то, что поддерживает glibc
Кучу нестандартных решений и исторически сложившихся ошибок. В статье есть ссылка на то почему та или иная фича glibc не поддерживается musl.
Ну так сделай аналогичный список ошибочных решений и отхождений от стандарта в musl и покажи его нам. В musl список косяков glibc не поленились составить.
Хотя нет, постой. Даже это они там описали.
> Ну так сделай аналогичный список ошибочных решений и отхождений от стандарта в
> musl и покажи его нам. В musl список косяков glibc не
> поленились составить.Некий Леня П. тоже не поленился составить список Фатальных Недостатков в конкурирующих решениях. Может, в продвижении его лисапеда ему это где-то и помогло, но умнее он от этого выглядеть не стал.
Я не возражаю, что лучше вносить улучшения в старые решения, чем городить новые. Да вот только порой старые решения такие улучшения не примут просто для сохранения обратной совместимости со своими старыми косяками или просто устаревшими и практически никому не нужными фичами. А такие косяки имеют свойство накапливаться и превращаются в то, что именуется legacy code. И чем такого кода больше — тем хуже для проекта. Вон иксы практически целиком в него превратились, например. Все современные тулкиты только и делают, что при работе с иксами стараются ими не пользоваться. Ну не парадокс ли? Или ты думаешь, что Wayland зародился и набирает популярность просто потому, что все кругом больные идиоты, а иксы так и надо тащить в неизменном виде ещё лет 20? Вот и glibc все, кому не лень, стараются заменить на что-то более удачное. Да, собственно, уже сейчас glibc крупным дистрибутивам не интересна и тот же Debian использует eglibc (а с ним и Ubuntu).
> Да, собственно, уже сейчас glibc крупным дистрибутивам не интересна и тот же Debian использует eglibc (а с ним и Ubuntu).Офигенный аргумент. Особенно если учесть, что eglibc - это просто glibc с возможностью опционального отключения сборки некоторых фич (которая на десктопе все равно не актуальна).
Я, правда, тут видел одного анонима, который мамой клялся, что eglibc в любой момент может послать нафиг glibc и сделать свой нестандартный интерфейс, но это был явный клоун.
> Я, правда, тут видел одного анонима, который мамой клялся, что eglibc в любой момент может послать нафиг glibc и сделать свой нестандартный интерфейс, но это был явный клоун.Интересно, что он же уверял, что дистрибутивы "массово переходят на eglibc" именно потому, что в glibc всякие дрепперы относятся без должного почтения к "исторически сложившимся" ошибкам. В eglibc, мол, никаких ломающих изменений быть не может.
Не только и не столько опциональное отключение сборки некоторых фичь, а возможность пропихивать в апстрим исправления кода, которые в glibc не примут из-за того, что им их legacy code важнее здравого смысла.Собственно вот тебе краткий список причин перехода на eglibc в Debian: http://blog.aurel32.net/47
Возможность выключать отдельные компоненты при сборке там лишь один из пунктов.
> Не только и не столько опциональное отключение сборки некоторых фичь, а возможность пропихивать в апстрим исправления кода, которые в glibc не примут из-за того, что им их legacy code важнее здравого смысла.Скорее наоборот. В glibc очень неаккуратно относятся к совместимости с legacy, недавний скандал с Adobe - тому пример. Поэтому дистрибутивы предпочитают eglibc, полагая этот проект более консервативным.
Вообще-то в eglibc memcpy тоже «сломали».
https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/734694
https://bugs.launchpad.net/ubuntu/+source/adobe-flashplugin/...
Поэтому в комментарии выше написано "полагая этот проект более консервативным", а не "так как этот проект более консервативен".
По факту, eglibc - просто надстройка над glibc, и наследует весь legacy оттуда.
>насколько может быть большим исполняемый файл, компилируемый из того что написано на си?Мегабайты кода. Есть системы, для которых это критично. Есть программы, для которых это критично. Тут вообще сложный впрос в каждом конкретном случае: код оптимизированный по памяти (даже на современных настольных системах) может быть быстрее кода, оптимизированного по скоррости. И наоборот.
В качестве примера для С заранее неизвестно, как лучше оформить часто использующующийся небольшой функционал: в виде макроса или в виде функции. Макросы могут привести к распуханию кода и замедлить его. Или они могут позволить сэкономить на инструкциях вызова.>производительность там, где есть хорошие алгоритмы, а не маленький размер
Производительность чего? Большой системы - да. Низкоуровневой библиотеки - нет. Мы говорим о глобальных вещах, о стандартной библиотеке длля Линукса. Дело в том, что код стандартной библиотеки будет вызываться очень много раз во всевозможных программах. Допустип, что glibc используется на миллионе компьютеров, на каждом из которых сотней программ. И для каждого использования он экономит, ммм, один мегабайт памяти. То есть имеем экономию в... 100 Тбайт! А масштабы использования куда больше...
Также и с низкоуровневой оптимизацией: каждый сэкономленный такт в мировых масштабах выливается в колоссальную экономию.
А экономия памяти и тактов в мобильных девайсах вообще бесценна.>безопасный код тот, который проверен большим сообществом пользователей и разработчиков, поскольку даже Hello World может быть написан с кучей уязвимостей.
И? Библиотека опенсорсная, значит, твой комментарий вообще не по делу.
Но даже открытость не даёт гарантии безопасности. Код изначально должен писаться с учётом возможных проблем, а также базироваться на библиотеках, которые этих проблем лишены.>простота означает лишь то, что кому-то придётся от чего-то отказаться
Чистой воды демагогия. Простота также означает более адекватный выбор абстракций для описания предметной области.
>ну это вообще ни в какие ворота, пусть посмотрят на то, что поддерживает glibc
glibc может подддерживать даже больше, но почитай же статью целиком! Поддержка стандартов означает не только соответствие неким документам, но и отсутствие лишнего. В том-то и "прелесть", что код написанный с использованием glibc может не собираться с другими библиотеками. Потому что glibc поддерживает не только стандарты, но и всякие другие свои штуки, которые будут загружать бесполезной работой программистов при портировании кода.
А теперь давайте посмотрим реальные плюсы этой либы:
1) MIT !!!, если дело пойдёт, это может заинтересовать некоторых проприетарщиков, хотя может и не заинтересовать.
2) ЭГО !!!, чувак распиарился на весь мир, как поборник истинной свободы без Столлмана и GPL
> 1) MIT !!!, если дело пойдёт, это может заинтересовать некоторых проприетарщиков, хотя
> может и не заинтересовать.1) Кернел все-равно придется релизить.
2) Кому надо - при пересборке возьмет uclibc/eglibc, если сорц зажмут, так что плюс очень эфемерный.
3) С каких пор проприерастия стала плюсом? Это на данный момент жирный минус уже.> без Столлмана и GPL
...работая только под Linux... :)
> 2) Кому надо - при пересборке возьмет uclibc/eglibc, если сорц зажмут, так что плюс очень эфемерный.Судя по "частичной совместимость glibc", просто так взять и поменять musl на eglibc вряд ли получится.
> 3) С каких пор проприерастия стала плюсом? Это на данный момент жирный минус уже.
В мире BSD/MIT ценности немного другие.
> Судя по "частичной совместимость glibc", просто так взять и поменять musl на
> eglibc вряд ли получится.Скорее, взять и заменить eglibc на musl врядли получится. Мелкотравчатые/lightweight проекты обычно именно это :) имеют в виду. Ибо выписывать все довески и навороты glibc можно и подзадолбаться, а вот еще и свои довески реализовывать при том что и так кодить дофига + ориентация на lightweight в общем то довольно странная идея.
> В мире BSD/MIT ценности немного другие.
Да, там полтора идеалиста-академзадрoта пашущих на полторы особо жлобские корпорации. И взаимодействие в стиле садо-мазо.
BSD/MIT - единственные свободные/free лицензии, даже больше типичного freeware,
хватит лапшу вешать про них или наоборот про "свободность" GPL.
> ...работая только под Linux... :)GPL в ядре Linux не накладывает ограничений на закрытие юзерспейса.
В отличие от GPL в glibc.
>GPL в ядре Linux не накладывает ограничений на закрытие юзерспейса.Это упущение.
Нужно ограничение на закрытие билиотеки самого нижнего уровня, непосредственно взаимодействующего с ядром. Прикладного ПО это не касается.
> Это упущение.
> Нужно ограничение на закрытие билиотеки самого нижнего уровня, непосредственно взаимодействующего с ядром. Прикладного ПО это не касается.Чтобы библиотеки были открыты, но прикладного ПО это не касалось - они должны быть лицензированы под LGPL или аналогичной лицензией. В современных проектах все к этому идет - glibc и ее клон eglibc, а также uclibc, например. Еще с ядром тесно работают всякие libsystemd-*, которые тоже под LGPL.
А сабж - под MIT, позволяющей закрывать код.
> А сабж - под MIT, позволяющей закрывать код.Прикиньте
1) сами разработчики *именно поэтому* её и выбрали! Алло!
2) другим желающим что то расширить и заработать на том коде
(а задарма пилять GPL и ли что чаще за продажу чужих секретов так или иначе реализованную, в лучшем случае на баннерах и предоставлении услуг внедрения и поддержки - что всё подходит немногим и точно не всем),
это как раз плюс.P.S.
Но, лично я бы всё же запретил бы проприетарное использование и даже незакрытое (+привет не только Apple с BSD kernel, но и RedHat,Canonical,и т.д. с GPL)
- корпорациями или иными организацими или лицами могущими захватить весь и большую часть рынка своими миллиоными вложениями в раскрутку и ладе когда и в расширение,
тем самым обессмысливая идею развития самого продукта *пользователю* *конкурентными методами* для чего была и созданна BSD лицензия в отличие от GPL(ориентированный - на *заимствование исходного кода и непатентуемых GPL разработчиками решений* - у менее успешных конкурентов форка, т.е.их труда бесплатно, т.о.делая и неявно рабами себе, в том числе и пишушщи на API только такой ОС),
ибо при ["]захвате["] рынка конкуренция сильнйших превращается в монополию,
даже 100% монопольный в сфере их АPI и аппартных поддерживаемых платформ+драйверов
Apple или Android (напомню никсоидам: основанных не только на BSD - но и GPL...)
- тому лучшие примеры, и даже %-но - куда большие чем у охаиваемой MS на платформе PC.
* корпорациями или иными организацими или лицами *когда* могущими захватить весь и большую часть рынка ... или по факту захвата
* ... своими миллиоными вложениями в раскрутку, и даже когда и в расширение продукта, ...
> В отличие от GPL в glibc.Вот же ж. А как, простите, проприетарные игры с ним линкуются? :)
>> В отличие от GPL в glibc.
> Вот же ж. А как, простите, проприетарные игры с ним линкуются? :)Всем некростудентам, отметившимся в треде: учите матчасть, в данном разе LGPL.
Да чего уж там учить, вся матчать-то "closed_source + LGPL = dlopen".
здоровская экономия памяти. ГДЕ ВЗЯТЬ ХОТЬ ОДИН ЛИНУКС, С СОФТОМ, в котором всё, или большинство собрано именно с приминением этой библиотеки? я ничего не нашел.
> На базе Musl уже развивается несколько дистрибутивов Linux, среди которых проекты OSv, Sabotage, LightCube OS, starchlinux, morpheus и Snowflake.
> здоровская экономия памяти. ГДЕ ВЗЯТЬ ХОТЬ ОДИН ЛИНУКС, С СОФТОМ, в котором всё, или большинство собрано именно с приминением этой библиотеки? я ничего не нашел.Вы надеетесь что, если собрать кеды или хром с использованием сабжа, они сразу начнут жрать на 90% меньше памяти? Я бы не стал на это рассчитывать.
Какашка Хром? Ну хотя бы на 10%. Мы бы уже сказали "ДА!!!!!!"
Особенно если учесть, что in-memory образ библиотеки, как правило, один на всё загруженное...
При монолитном ядре, после сжатия весящем 40-60 мегабайтов - без разницы сколько весит libc: 400 килобайт, 2 мега, 6 мегов...
http://www.musl-libc.org/jslinux/ in-browser demo setup using jslinux
Где ссылка на гитхаб?
http://git.musl-libc.org/cgit/musl/зачем github?
>> Musl поддерживает работу только в LinuxНу и чем оно лучше Glibc ?
>>> Musl поддерживает работу только в Linux
> Ну и чем оно лучше Glibc ?Тем, что под BSD-like лицензией.
> Тем, что под BSD-like лицензией.Сомнительное "улучшение". Выигрывает полтора жирных корпораса. Пролетают все остальные.
Где, где я вас спрашиваю systemd-libc ?
> Где, где я вас спрашиваю systemd-libc ?Ленька не осилил, и решил отмазаться, мол, это первоапрельский прикол был. Но мы-то знаем!
Человек сделал библиотеку которая меньше ест памяти и работает быстрее (
http://www.etalabs.net/compare_libcs.html). Обязательно нужно его залажать?Я понимаю что всех уже достал systemd и т.д. Но здесь противоположный случай - здоровый минимализм и оправданный отказ от legacy.
Было бы под GPLv3 - лично я хвалил бы. А если человек кормит врагов - не вижу чему радоваться.
А враги знают что они враги? :)
> А враги знают что они враги? :)Их знание не требуется.
На данный момент пусть лучше "враги" используют наши библиотеки (и соответственно наши стандарты), чем городят свои ни с чем несовместимые с квадратными колесами.
> Человек сделал библиотеку которая меньше ест памяти и работает быстрее (
> http://www.etalabs.net/compare_libcs.html). Обязательно нужно его залажать?
> Я понимаю что всех уже достал systemd и т.д. Но здесь противоположный
> случай - здоровый минимализм и оправданный отказ от legacy.Так, первое, что усмотрел с половины взгляда - полное отсустствие поддержки нормальных русских 8-битных кодировок. Уклон в UTF-8. Очень нехорошо (мягко выражаясь). (хотя сейчас что-то тоже набрало дурацкую популярность в частности в GNOME)... memcpy кажется тоже сделана как обычная функция...
> полное отсустствие поддержки нормальных русских 8-битных кодировок.Как? Ни одной из over9000 "нормальных русских 8-битных кодировок"? Ужас!
>memcpy кажется тоже сделана как обычная функция
А должна быть как...?
...как необычная.
> А должна быть как...?:-) Пожалуй, так и должна наверно... Для gcc.
> :-) Пожалуй, так и должна наверно... Для gcc.Не "для gcc" а "в XXI веке", где пора бы уже забыть про гемор с выбором кодировок и просто использовать уникод.
> Не "для gcc" а "в XXI веке", где пора бы уже забыть
> про гемор с выбором кодировок и просто использовать уникод.Поскольку год сейчас 2014 и пятница, то поддержка 8 битных русских кодировок необходима с особенной очевидностью...
> необходима с особенной очевидностью...В этот четверг не было дождя.
>> необходима с особенной очевидностью...
> В этот четверг не было дождя.Зато в 1999 году помнится был... Перед XXI веком.
Стандартная библиотека с лицензией MIT работающая только в Linux? Любопытно...
> Стандартная библиотека с лицензией MIT работающая только в Linux? Любопытно...Можно и для других OS адаптировать и MIT как раз это позволит
прикольно =)
в дебьяне и ко - мы ее врятли увидим а в арче имб красношапке - возможно, опять-же всяческие генто и форки ... кто знает =)
а про "стандартные" glibC и eglibC либы - дык они все под улюлдочными(относительно GPL3)лицензиями, так что MIT у сабжа - не выглядит ни бледно, ни необычно. в отличие от того, КАК БЫСТРО она работает !!! ракета просто !
bsd libc в FreeBSD 10.0 весит 1.5мб и Hello World на сишечке ~7кб.
Такой толстый пингвин=\
> bsd libc в FreeBSD 10.0 весит 1.5мб и Hello World на сишечке
> ~7кб.
> Такой толстый пингвин=\Такой толстый и тупой BSD'шный анонимный тролль.
решил проверить... он не тролль, он пишет правду:# cat hw.c
#include <stdio.h>
int main(){ printf("Hello world!\n");}# clang -Os hw.c -o hw
# ls -l hw
-rwxr-xr-x 1 admin wheel 7350 29 апр 12:05 hw# ./hw
Hello world!#
и?edo@edo-home:/tmp$ cat > hw.c
#include <stdio.h>
int main(){ printf("Hello world!\n");}
edo@edo-home:/tmp$ gcc -Os -o hw hw.c
edo@edo-home:/tmp$ gcc -Os -static -o hw-static hw.c
edo@edo-home:/tmp$ ls -l hw*
-rwxr-xr-x 1 edo edo 6728 июн 26 11:12 hw
-rw-r--r-- 1 edo edo 58 июн 26 11:12 hw.c
-rwxr-xr-x 1 edo edo 827272 июн 26 11:12 hw-static
edo@edo-home:/tmp$ file hw
hw: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=9030f53ca7ced7617d29a32ce5a7b01a559928ab, not stripped
Ну хоть кто-то еще придерживается традиционной ориентации, а не пишет libc на asm.js :)))
> Ну хоть кто-то еще придерживается традиционной ориентации, а не пишет libc на
> asm.js :)))Возможно после вашего комментария это может изменится. :) Ну а если серьезно то на данном этапе Musl показывает хорошие результаты. Есть только одно опасение что в попытке сделать его совместимым с glibc получится такой же перегруженный код как у glibc, тут главное не переусердствовать и придерживаться первоначального плана развития.
Уважаемый автор, разрешаете ли вы перепечатать текст вашей новости в статье о musl в Википедии https://ru.wikipedia.org/wiki/Musl ?