Представлена стандартная Си-библиотека Musl 1.0.0, развиваемая в качестве альтернативы Glibc

20.03.2014 19:59

После трёх лет разработки представлен первый значительный релиз новой стандартной Си-библиотеки Musl 1.0.0 (libc), ориентированной для использования в Linux-устройствах нового поколения. Библиотека отличается небольшим размером, высокой производительностью, безопасностью, простотой и соблюдением стандартов. Автором проекта является Рич Фелкер (Rich Felker), участник проекта Openwall и член группы Austin Group, развивающей и поддерживающей стандарты POSIX. Код Musl поставляется под свободной лицензией MIT, допускающей использование библиотеки в закрытых проектах.

Musl является универсальной реализацией libc и подходит для применения как на стационарных ПК и серверах, так и на мобильных системах, сочетая полноценную поддержку стандартов, свойственную для полновесных библиотек, таких как Glibc (GNU C library), с небольшим размером, низким потреблением ресурсов и высокой производительностью, свойственными специализированным вариантам libc для встраиваемых систем, таких как uClibc, dietlibc и Android Bionic. Musl предоставляет полную поддержку всех обязательных интерфейсов C99 и POSIX 2008, а также частично C11 и набор расширений, получивших распространение в Linux-окружениях. В том числе библиотека предоставляет средства для многопоточного программирования (POSIX threads), управления памятью и работы с локалями.

Проект Musl старается придерживаться совместимости с Glibc в части функциональности, как на бинарном уровне, так и на уровне исходных текстов. При этом, Musl не ставит перед собой цель обеспечения совместимости с Glibc на уровне ошибок, идущих вразрез со стандартами. На уровне исходных текстов обеспечена достаточно неплохая совместимость с Glibc. На бинарном уровне совместимость ещё оставляет желать лучшего - хотя уже можно загружать при использовании musl некоторые динамические библиотеки, собранные с Glibc, запуск приложений при замене /lib/ld-linux.so.2 на musl пока не поддерживается.

Что касается несовместимости на уровне кода, если работающее с Glibc приложение не удаётся собрать с Musl, то, как правило, проблемы вызваны ошибками при формировании списка директив include, указанием нестандартных элементов (например, __pid_t вместо pid_t) или использованием программных интерфейсов, пока не доступных в musl. Из возможностей Musl, которые отсутствуют в Glibc, можно отметить поддержку атомарного обновления, обеспечение совместимости с будущими версиями (Forward compatibility), поддержку TCB. В настоящее время сборка с Musl успешно протестирована на более чем 5000 пакетах из архива pkgsrc.

Musl поддерживает работу только в 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. При статическом связывании все компоненты Musl занимают примерно 400 Кб, при динамическом - 500 Кб (для сравнения в Glibc 1.5 Мб и 2 Мб). Минимальный размер статически собранной программы составляет 1.8 Кб, Hello World - 13k (в Glibc - 508 Кб), при динамическом связывании прибавляется 20 Кб. По производительности, Musl в основном близка к Glibc, за исключением операций динамического связывания и декодирования UTF-8, которые выполняются в Musl быстрее в несколько раз.

На базе Musl уже развивается несколько дистрибутивов Linux, среди которых проекты OSv, Sabotage, LightCube OS, starchlinux, morpheus и Snowflake. Musl также применяется в компиляторе Emscripten, используемом для преобразования C/C++ проектов в представление на JavaScript. Из известных дистрибутивов, в которых обеспечена опциональная поддержка Musl, можно отметить Debian, Ubuntu, OpenWrt, Gentoo и Arch Linux. Среди дистрибутивов, планирующих переход по умолчанию на Musl: Aboriginal, Alpine и Dragora.

исправить +8 +/–

Лицензия: CC BY 3.0

Короткая ссылка: https://opennet.ru/39365-musl

Ключевые слова: musl, libc

При перепечатке указание ссылки на opennet.ru обязательно

Обсуждение (67)

1.1, Аноним (-), 20:36, 20/03/2014 [ответить] [﹢﹢﹢] [ · · · ]

+14 +/–

>отличается небольшим размером

насколько может быть большим исполняемый файл, компилируемый из того что написано на си?
>высокой производительностью

производительность там, где есть хорошие алгоритмы, а не маленький размер
>безопасностью

безопасный код тот, который проверен большим сообществом пользователей и разработчиков, поскольку даже Hello World может быть написан с кучей уязвимостей.
>простотой

простота означает лишь то, что кому-то придётся от чего-то отказаться
>соблюдением стандартов

ну это вообще ни в какие ворота, пусть посмотрят на то, что поддерживает glibc

2.4, rshadow (ok), 21:08, 20/03/2014 [^] [^^] [^^^] [ответить]	–1 +/–
Доводы "самых хитрых" всегда надо читать наоборот. Во первых проплатили чтоб переписал под нужной лицензией. Во вторых писал с нуля, используя все новье что есть, отсюда плюшки. Ну а дальше что смог то и осилил, до сообщества далековато.

3.6, Аноним (-), 21:24, 20/03/2014 [^] [^^] [^^^] [ответить]	+/–
> Во вторых писал с нуля, используя все новье что есть, отсюда плюшки. Судя по "частичной поддержке C11", не такое уж и новье. Или вы имели в виду что-то другое?

2.8, Аноним (-), 21:55, 20/03/2014 [^] [^^] [^^^] [ответить]	+/–
> насколько может быть большим исполняемый файл, компилируемый из того что написано на си? В xonotic до 6Мб бинарей догнались, например :). Нормально?

2.11, Lain_13 (ok), 21:58, 20/03/2014 [^] [^^] [^^^] [ответить]

+5 +/–

Как минимум на пару твоих «утверждений» есть ответ в самой статье, которую можно было бы и прочитать более внимательно.

> насколько может быть большим исполняемый файл, компилируемый из того что написано на си?

В статье чётко указано сравнение с компонентами glibc. Вплоть до дополнительных 1-1.5 Мб. Даже в Hello World 500 Кб оверхеда.

> безопасный код тот, который проверен большим сообществом пользователей и разработчиков, поскольку даже Hello World может быть написан с кучей уязвимостей.

Не совсем корректное утверждение. «Хорошо» проверенный, но запутанный или просто слишком огромный код потенциально более уязвим, чем менее проверенный, но и менее запутанный, и более лаконичный код. Для проверки и выявления уязвимостей в последнем требуется куда меньше ресурсов.

> ну это вообще ни в какие ворота, пусть посмотрят на то, что поддерживает glibc

Кучу нестандартных решений и исторически сложившихся ошибок. В статье есть ссылка на то почему та или иная фича glibc не поддерживается musl.

Часть нити удалена модератором

4.15, Lain_13 (ok), 22:08, 20/03/2014 [^] [^^] [^^^] [ответить]	+7 +/–
Ну так сделай аналогичный список ошибочных решений и отхождений от стандарта в musl и покажи его нам. В musl список косяков glibc не поленились составить. Хотя нет, постой. Даже это они там описали.

5.17, Аноним (-), 22:12, 20/03/2014 [^] [^^] [^^^] [ответить]	–4 +/–
> Ну так сделай аналогичный список ошибочных решений и отхождений от стандарта в > musl и покажи его нам. В musl список косяков glibc не > поленились составить. Некий Леня П. тоже не поленился составить список Фатальных Недостатков в конкурирующих решениях. Может, в продвижении его лисапеда ему это где-то и помогло, но умнее он от этого выглядеть не стал.

6.18, Lain_13 (ok), 22:26, 20/03/2014 [^] [^^] [^^^] [ответить]	+1 +/–
Я не возражаю, что лучше вносить улучшения в старые решения, чем городить новые. Да вот только порой старые решения такие улучшения не примут просто для сохранения обратной совместимости со своими старыми косяками или просто устаревшими и практически никому не нужными фичами. А такие косяки имеют свойство накапливаться и превращаются в то, что именуется legacy code. И чем такого кода больше — тем хуже для проекта. Вон иксы практически целиком в него превратились, например. Все современные тулкиты только и делают, что при работе с иксами стараются ими не пользоваться. Ну не парадокс ли? Или ты думаешь, что Wayland зародился и набирает популярность просто потому, что все кругом больные идиоты, а иксы так и надо тащить в неизменном виде ещё лет 20? Вот и glibc все, кому не лень, стараются заменить на что-то более удачное. Да, собственно, уже сейчас glibc крупным дистрибутивам не интересна и тот же Debian использует eglibc (а с ним и Ubuntu).

7.19, Аноним (-), 22:38, 20/03/2014 [^] [^^] [^^^] [ответить]

+/–

> Да, собственно, уже сейчас glibc крупным дистрибутивам не интересна и тот же Debian использует eglibc (а с ним и Ubuntu).

Офигенный аргумент. Особенно если учесть, что eglibc - это просто glibc с возможностью опционального отключения сборки некоторых фич (которая на десктопе все равно не актуальна).

Я, правда, тут видел одного анонима, который мамой клялся, что eglibc в любой момент может послать нафиг glibc и сделать свой нестандартный интерфейс, но это был явный клоун.

8.21, Аноним (-), 23:13, 20/03/2014 [^] [^^] [^^^] [ответить]	+/–
Интересно, что он же уверял, что дистрибутивы массово переходят на eglibc имен... текст свёрнут, показать

8.23, Lain_13 (ok), 23:56, 20/03/2014 [^] [^^] [^^^] [ответить]	+1 +/–
Не только и не столько опциональное отключение сборки некоторых фичь, а возможно... текст свёрнут, показать

9.25, Аноним (-), 00:14, 21/03/2014 [^] [^^] [^^^] [ответить]	–2 +/–
Скорее наоборот В glibc очень неаккуратно относятся к совместимости с legacy, н... текст свёрнут, показать

10.27, Lain_13 (ok), 00:30, 21/03/2014 [^] [^^] [^^^] [ответить]	+2 +/–
Вообще-то в eglibc memcpy тоже 171 сломали 187 https bugs launchpad net u... текст свёрнут, показать

11.32, Аноним (-), 01:33, 21/03/2014 [^] [^^] [^^^] [ответить]	+1 +/–
Поэтому в комментарии выше написано полагая этот проект более консервативным , ... текст свёрнут, показать

2.42, Nuzhny (?), 08:02, 21/03/2014 [^] [^^] [^^^] [ответить]	+2 +/–
Мегабайты кода Есть системы, для которых это критично Есть программы, для кото... большой текст свёрнут, показать

1.2, Аноним (-), 20:40, 20/03/2014 [ответить] [﹢﹢﹢] [ · · · ]	+14 +/–
А теперь давайте посмотрим реальные плюсы этой либы: 1) MIT !!!, если дело пойдёт, это может заинтересовать некоторых проприетарщиков, хотя может и не заинтересовать. 2) ЭГО !!!, чувак распиарился на весь мир, как поборник истинной свободы без Столлмана и GPL

2.9, Аноним (-), 21:57, 20/03/2014 [^] [^^] [^^^] [ответить]

+/–

> 1) MIT !!!, если дело пойдёт, это может заинтересовать некоторых проприетарщиков, хотя
> может и не заинтересовать.

1) Кернел все-равно придется релизить.
2) Кому надо - при пересборке возьмет uclibc/eglibc, если сорц зажмут, так что плюс очень эфемерный.
3) С каких пор проприерастия стала плюсом? Это на данный момент жирный минус уже.

> без Столлмана и GPL

...работая только под Linux... :)

3.12, Аноним (-), 22:01, 20/03/2014 [^] [^^] [^^^] [ответить]

+1 +/–

> 2) Кому надо - при пересборке возьмет uclibc/eglibc, если сорц зажмут, так что плюс очень эфемерный.

Судя по "частичной совместимость glibc", просто так взять и поменять musl на eglibc вряд ли получится.

> 3) С каких пор проприерастия стала плюсом? Это на данный момент жирный минус уже.

В мире BSD/MIT ценности немного другие.

4.50, Аноним (-), 13:13, 21/03/2014 [^] [^^] [^^^] [ответить]

+/–

> Судя по "частичной совместимость glibc", просто так взять и поменять musl на
> eglibc вряд ли получится.

Скорее, взять и заменить eglibc на musl врядли получится. Мелкотравчатые/lightweight проекты обычно именно это :) имеют в виду. Ибо выписывать все довески и навороты glibc можно и подзадолбаться, а вот еще и свои довески реализовывать при том что и так кодить дофига + ориентация на lightweight в общем то довольно странная идея.

> В мире BSD/MIT ценности немного другие.

Да, там полтора идеалиста-академзадрoта пашущих на полторы особо жлобские корпорации. И взаимодействие в стиле садо-мазо.

5.75, Анонимдругой (?), 02:52, 04/08/2017 [^] [^^] [^^^] [ответить]	+/–
BSD/MIT - единственные свободные/free лицензии, даже больше типичного freeware, хватит лапшу вешать про них или наоборот про "свободность" GPL.

3.16, Аноним (-), 22:09, 20/03/2014 [^] [^^] [^^^] [ответить]	–2 +/–
> ...работая только под Linux... :) GPL в ядре Linux не накладывает ограничений на закрытие юзерспейса. В отличие от GPL в glibc.

4.22, Аноним (-), 23:56, 20/03/2014 [^] [^^] [^^^] [ответить]	–1 +/–
>GPL в ядре Linux не накладывает ограничений на закрытие юзерспейса. Это упущение. Нужно ограничение на закрытие билиотеки самого нижнего уровня, непосредственно взаимодействующего с ядром. Прикладного ПО это не касается.

5.26, Аноним (-), 00:20, 21/03/2014 [^] [^^] [^^^] [ответить]

+/–

> Это упущение.
> Нужно ограничение на закрытие билиотеки самого нижнего уровня, непосредственно взаимодействующего с ядром. Прикладного ПО это не касается.

Чтобы библиотеки были открыты, но прикладного ПО это не касалось - они должны быть лицензированы под LGPL или аналогичной лицензией. В современных проектах все к этому идет - glibc и ее клон eglibc, а также uclibc, например. Еще с ядром тесно работают всякие libsystemd-*, которые тоже под LGPL.

А сабж - под MIT, позволяющей закрывать код.

6.76, Анонимдругой (?), 03:12, 04/08/2017 [^] [^^] [^^^] [ответить]

+/–

> А сабж - под MIT, позволяющей закрывать код.

Прикиньте
1) сами разработчики *именно поэтому* её и выбрали! Алло!
2) другим желающим что то расширить и заработать на том коде
(а задарма пилять GPL и ли что чаще за продажу чужих секретов так или иначе реализованную, в лучшем случае на баннерах и предоставлении услуг внедрения и поддержки - что всё подходит немногим и точно не всем),
это как раз плюс.

P.S.
Но, лично я бы всё же запретил бы проприетарное использование и даже незакрытое (+привет не только Apple с BSD kernel, но и RedHat,Canonical,и т.д. с GPL)
- корпорациями или иными организацими или лицами могущими захватить весь и большую часть рынка своими миллиоными вложениями в раскрутку и ладе когда и в расширение,
тем самым обессмысливая идею развития самого продукта *пользователю* *конкурентными методами* для чего была и созданна BSD лицензия в отличие от GPL(ориентированный - на *заимствование исходного кода и непатентуемых GPL разработчиками решений* - у менее успешных конкурентов форка, т.е.их труда бесплатно, т.о.делая и неявно рабами себе, в том числе и пишушщи на API только такой ОС),
ибо при ["]захвате["] рынка конкуренция сильнйших превращается в монополию,
даже 100% монопольный в сфере их АPI и аппартных поддерживаемых платформ+драйверов
Apple или Android (напомню никсоидам: основанных не только на BSD - но и GPL...)
- тому лучшие примеры, и даже %-но - куда большие чем у охаиваемой MS на платформе PC.

7.77, Анонимдругой (?), 03:14, 04/08/2017 [^] [^^] [^^^] [ответить]	+/–
* корпорациями или иными организацими или лицами когда могущими захватить весь и большую часть рынка ... или по факту захвата

8.78, Анонимдругой (?), 03:19, 04/08/2017 [^] [^^] [^^^] [ответить]	+/–
своими миллиоными вложениями в раскрутку, и даже когда и в расширение прод... текст свёрнут, показать

4.51, Аноним (-), 13:14, 21/03/2014 [^] [^^] [^^^] [ответить]

+/–

> В отличие от GPL в glibc.

Вот же ж. А как, простите, проприетарные игры с ним линкуются? :)

5.64, Michael Shigorin (ok), 12:03, 22/03/2014 [^] [^^] [^^^] [ответить]	+/–
>> В отличие от GPL в glibc. > Вот же ж. А как, простите, проприетарные игры с ним линкуются? :) Всем некростудентам, отметившимся в треде: учите матчасть, в данном разе LGPL.

6.68, Маленькая Серая Мышка (?), 01:34, 24/03/2014 [^] [^^] [^^^] [ответить]	–1 +/–
Да чего уж там учить, вся матчать-то "closed_source + LGPL = dlopen".

1.7, Аноним (7), 21:45, 20/03/2014 [ответить] [﹢﹢﹢] [ · · · ]	–1 +/–
здоровская экономия памяти. ГДЕ ВЗЯТЬ ХОТЬ ОДИН ЛИНУКС, С СОФТОМ, в котором всё, или большинство собрано именно с приминением этой библиотеки? я ничего не нашел.

2.10, Аноним (-), 21:58, 20/03/2014 [^] [^^] [^^^] [ответить]	+3 +/–
> На базе Musl уже развивается несколько дистрибутивов Linux, среди которых проекты OSv, Sabotage, LightCube OS, starchlinux, morpheus и Snowflake.

2.35, Аноним (-), 01:38, 21/03/2014 [^] [^^] [^^^] [ответить]	+1 +/–
> здоровская экономия памяти. ГДЕ ВЗЯТЬ ХОТЬ ОДИН ЛИНУКС, С СОФТОМ, в котором всё, или большинство собрано именно с приминением этой библиотеки? я ничего не нашел. Вы надеетесь что, если собрать кеды или хром с использованием сабжа, они сразу начнут жрать на 90% меньше памяти? Я бы не стал на это рассчитывать.

3.45, Могикан (?), 08:56, 21/03/2014 [^] [^^] [^^^] [ответить]	+1 +/–
Какашка Хром? Ну хотя бы на 10%. Мы бы уже сказали "ДА!!!!!!"

3.65, AlexAT (ok), 16:12, 22/03/2014 [^] [^^] [^^^] [ответить]	+/–
Особенно если учесть, что in-memory образ библиотеки, как правило, один на всё загруженное...

4.71, Вареник (?), 06:45, 28/04/2016 [^] [^^] [^^^] [ответить]	+/–
При монолитном ядре, после сжатия весящем 40-60 мегабайтов - без разницы сколько весит libc: 400 килобайт, 2 мега, 6 мегов...

1.14, NO_ID (?), 22:05, 20/03/2014 [ответить] [﹢﹢﹢] [ · · · ]	+5 +/–
http://www.musl-libc.org/jslinux/ in-browser demo setup using jslinux

1.20, Аноним (20), 23:10, 20/03/2014 [ответить] [﹢﹢﹢] [ · · · ]	–1 +/–
Где ссылка на гитхаб?

2.24, NO_ID (?), 00:10, 21/03/2014 [^] [^^] [^^^] [ответить]	+1 +/–
http://git.musl-libc.org/cgit/musl/ зачем github?

1.29, Pop (?), 01:13, 21/03/2014 [ответить] [﹢﹢﹢] [ · · · ]	–2 +/–
>> Musl поддерживает работу только в Linux Ну и чем оно лучше Glibc ?

2.33, Аноним (-), 01:34, 21/03/2014 [^] [^^] [^^^] [ответить]	–1 +/–
>>> Musl поддерживает работу только в Linux > Ну и чем оно лучше Glibc ? Тем, что под BSD-like лицензией.

3.52, Аноним (-), 13:15, 21/03/2014 [^] [^^] [^^^] [ответить]

+/–

> Тем, что под BSD-like лицензией.

Сомнительное "улучшение". Выигрывает полтора жирных корпораса. Пролетают все остальные.

1.30, pavlinux (ok), 01:18, 21/03/2014 [ответить] [﹢﹢﹢] [ · · · ]	–2 +/–
Где, где я вас спрашиваю systemd-libc ?

2.34, Аноним (-), 01:35, 21/03/2014 [^] [^^] [^^^] [ответить]	+/–
> Где, где я вас спрашиваю systemd-libc ? Ленька не осилил, и решил отмазаться, мол, это первоапрельский прикол был. Но мы-то знаем!

1.36, Mihail Zenkov (ok), 02:15, 21/03/2014 [ответить] [﹢﹢﹢] [ · · · ]	+7 +/–
Человек сделал библиотеку которая меньше ест памяти и работает быстрее ( http://www.etalabs.net/compare_libcs.html). Обязательно нужно его залажать? Я понимаю что всех уже достал systemd и т.д. Но здесь противоположный случай - здоровый минимализм и оправданный отказ от legacy.

2.38, Crazy Alex (ok), 06:08, 21/03/2014 [^] [^^] [^^^] [ответить]	+1 +/–
Было бы под GPLv3 - лично я хвалил бы. А если человек кормит врагов - не вижу чему радоваться.

3.41, hoopoe (ok), 07:27, 21/03/2014 [^] [^^] [^^^] [ответить]	+/–
А враги знают что они враги? :)

4.53, Аноним (-), 13:15, 21/03/2014 [^] [^^] [^^^] [ответить]	–1 +/–
> А враги знают что они враги? :) Их знание не требуется.

3.57, Mihail Zenkov (ok), 14:29, 21/03/2014 [^] [^^] [^^^] [ответить]	+2 +/–
На данный момент пусть лучше "враги" используют наши библиотеки (и соответственно наши стандарты), чем городят свои ни с чем несовместимые с квадратными колесами.

2.40, Anonym2 (?), 07:23, 21/03/2014 [^] [^^] [^^^] [ответить]

–3 +/–

> Человек сделал библиотеку которая меньше ест памяти и работает быстрее (
> http://www.etalabs.net/compare_libcs.html). Обязательно нужно его залажать?
> Я понимаю что всех уже достал systemd и т.д. Но здесь противоположный
> случай - здоровый минимализм и оправданный отказ от legacy.

Так, первое, что усмотрел с половины взгляда - полное отсустствие поддержки нормальных русских 8-битных кодировок. Уклон в UTF-8. Очень нехорошо (мягко выражаясь). (хотя сейчас что-то тоже набрало дурацкую популярность в частности в GNOME)... memcpy кажется тоже сделана как обычная функция...

3.43, Led (ok), 08:23, 21/03/2014 [^] [^^] [^^^] [ответить]

+1 +/–

> полное отсустствие поддержки нормальных русских 8-битных кодировок.

Как? Ни одной из over9000 "нормальных русских 8-битных кодировок"? Ужас!

>memcpy кажется тоже сделана как обычная функция

А должна быть как...?

4.47, Анонимоус (?), 11:03, 21/03/2014 [^] [^^] [^^^] [ответить]	+/–
...как необычная.

4.48, Anonym2 (?), 11:31, 21/03/2014 [^] [^^] [^^^] [ответить]

–2 +/–

> А должна быть как...?

:-) Пожалуй, так и должна наверно... Для gcc.

5.54, Аноним (-), 13:16, 21/03/2014 [^] [^^] [^^^] [ответить]

+/–

> :-) Пожалуй, так и должна наверно... Для gcc.

Не "для gcc" а "в XXI веке", где пора бы уже забыть про гемор с выбором кодировок и просто использовать уникод.

6.55, Anonym2 (?), 13:39, 21/03/2014 [^] [^^] [^^^] [ответить]	–2 +/–
> Не "для gcc" а "в XXI веке", где пора бы уже забыть > про гемор с выбором кодировок и просто использовать уникод. Поскольку год сейчас 2014 и пятница, то поддержка 8 битных русских кодировок необходима с особенной очевидностью...

7.58, Аноним (-), 16:15, 21/03/2014 [^] [^^] [^^^] [ответить]

+/–

> необходима с особенной очевидностью...

В этот четверг не было дождя.

8.69, Anonym2 (?), 15:43, 24/03/2014 [^] [^^] [^^^] [ответить]	+/–
Зато в 1999 году помнится был Перед XXI веком ... текст свёрнут, показать

1.49, northbear (??), 12:12, 21/03/2014 [ответить] [﹢﹢﹢] [ · · · ]	+/–
Стандартная библиотека с лицензией MIT работающая только в Linux? Любопытно...

2.59, Аноним (-), 17:29, 21/03/2014 [^] [^^] [^^^] [ответить]	+/–
> Стандартная библиотека с лицензией MIT работающая только в Linux? Любопытно... Можно и для других OS адаптировать и MIT как раз это позволит

1.60, Аноним (-), 23:58, 21/03/2014 [ответить] [﹢﹢﹢] [ · · · ]	–1 +/–
прикольно =) в дебьяне и ко - мы ее врятли увидим а в арче имб красношапке - возможно, опять-же всяческие генто и форки ... кто знает =)

1.61, Аноним (-), 00:01, 22/03/2014 [ответить] [﹢﹢﹢] [ · · · ]	–2 +/–
а про "стандартные" glibC и eglibC либы - дык они все под улюлдочными(относительно GPL3)лицензиями, так что MIT у сабжа - не выглядит ни бледно, ни необычно. в отличие от того, КАК БЫСТРО она работает !!! ракета просто !

1.62, Аноним (-), 00:38, 22/03/2014 [ответить] [﹢﹢﹢] [ · · · ]	–2 +/–
bsd libc в FreeBSD 10.0 весит 1.5мб и Hello World на сишечке ~7кб. Такой толстый пингвин=\

2.63, Led (ok), 01:46, 22/03/2014 [^] [^^] [^^^] [ответить]	+1 +/–
> bsd libc в FreeBSD 10.0 весит 1.5мб и Hello World на сишечке > ~7кб. > Такой толстый пингвин=\ Такой толстый и тупой BSD'шный анонимный тролль.

3.72, prushka.ruit (?), 12:06, 29/04/2016 [^] [^^] [^^^] [ответить]

+/–

решил проверить... он не тролль, он пишет правду:

# 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!

4.73, edo (ok), 11:16, 26/06/2016 [^] [^^] [^^^] [ответить]	+/–
и? 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

1.67, bOOster (?), 13:27, 23/03/2014 [ответить] [﹢﹢﹢] [ · · · ]	+1 +/–
Ну хоть кто-то еще придерживается традиционной ориентации, а не пишет libc на asm.js :)))

2.70, Аноним (-), 22:32, 24/03/2014 [^] [^^] [^^^] [ответить]	+/–
> Ну хоть кто-то еще придерживается традиционной ориентации, а не пишет libc на > asm.js :))) Возможно после вашего комментария это может изменится. :) Ну а если серьезно то на данном этапе Musl показывает хорошие результаты. Есть только одно опасение что в попытке сделать его совместимым с glibc получится такой же перегруженный код как у glibc, тут главное не переусердствовать и придерживаться первоначального плана развития.

1.74, Аноним (-), 00:32, 06/10/2016 [ответить] [﹢﹢﹢] [ · · · ]	+/–
Уважаемый автор, разрешаете ли вы перепечатать текст вашей новости в статье о musl в Википедии https://ru.wikipedia.org/wiki/Musl ?

игнорирование участников | лог модерирования

Добавить комментарий

Текст: