glibc 2.44

И зачем это нужно? Давно на расте переписать надо уже…

И почему я не сомневался, что первым же комментарием в сишном треде будет комментарий от раст-истерички с криками «нинужна!»

Ненужно. Есть Musl.

главных новшеств стал файл /etc/tunables.conf

почему не
/etc/glibс_xxx.conf ???
откуда такая любовь к «бесконтекстному поименованию»? может я чего не знаю?! :о)

как промпт на душу ляжет…

И почему я не сомневался, что первым же комментарием в сишном треде будет комментарий от раст-истерички с криками «нинужна!»

Раз вы не высказали это сомнение до появления первого комментария, значит не было.

Шутка юмора.

по changelog прям-таки хороший релиз. Про CORE-MATH очень понравилось, прямо вкусно.

чуть подождать когда закроют свеже-внесённые баги и радоваться жизни :-)

в Федоре 45 будет?

да

GLibC-2.44 поломало mold.

ну да, можно предположить что нагенерили ии-лапши, не провели ревью и сразу в «продакш»... ну тогда это очень печально :о(

ну вы там тестируйте, а я пока на хорошо-запатченной предыдущей версии посижу

lbzip2: stdin: compression ratio is 1:4.636, space savings is 78.43%
>>> sys-libs/glibc-2.43-r2 merged.
>>> Regenerating /etc/ld.so.cache...

>>> Completed (1 of 1) sys-libs/glibc-2.43-r2::gentoo

Одним из главных новшеств стал файл /etc/tunables.conf

~ $ cat /etc/tunables.conf
cat: /etc/tunables.conf: No such file or directory

Они придерживаются очень строгих правил генерирования кода - не более пяти строк за раз. Коммиттер несёт персональную ответственность за чистоту лицензии и качество кода. Поэтому шух-мух ии-лапша и в прод сомнительна.

И шо?

хорошо! какие ваши предположения по поводу

откуда такая любовь к «бесконтекстному поименованию»?

самостоятельно создать файл?!

и в чем он не прав, глибс надо переписать на раст

откуда такая любовь к «бесконтекстному поименованию»?

Наверное с позиции разработчиков glibc - файлы напрямую в /etc для них, а для остальных - подпапки

видите разницу?

/etc/tunables.conf
/etc/glibс_tune.conf

файлы напрямую в /etc

/etc - общесистемные, не требующие более одного файла
/etc/subdir - требующие бОлее сложной иерархии/файлов
думают так :о)

Ну и какой же мерзкий человечишко вам это запрещает? Вперёд же ж!

Лучше пусть навайбкодит. Всё равно растаманскиц синтаксис не для людей.

И обязательно пусть притянет штук 50 первичных зависимостей, а те каждая ещё по 50 и так до бесконечности. Чтобы каждый школьник, написавший leftpad принял участие.

Надо musl делать))

И чего? На него даже манов нет.

на хорошо-запатченной

Что за изменения?

формат и расположение нового файла пока не считаются стабильным интерфейсом и
в будущих версиях могут измениться.

т.е. у фичи пилотный запуск, поэтому - для тестировщиков и продвинутых (смотрим код и рулим)
не айс, но в нашем «любимом огороде» - так уже давно.
согласен, хотелось-бы чуть «поближе к человеку» :о)

п.с. толь дело в нашем любимом лазаре, все (ну почти все) понятно и на месте! :о)

не мои патчи, гентушные ) баги закрывают и CVE бэкпортами патчей из апстрима,
всё как везде в других нормальных дистрах

И почему я не сомневался, что первым же комментарием в сишном треде будет комментарий от раст-истерички с криками «нинужна!»

«Растеричка»?.. ;))

Ненужно. Есть Musl.

И нормальные libc у *BSD.

Оказалось, что mimalloc поломался, но ужо починили.

И нормальные libc у *BSD.

Во-первых, без гнутых quality of life расширений, типа canonicalize_file_name или strerrordesc_np довольно грустно.

Во-вторых, GNUтые расширения аккуратно защищены feature guard’ом, тогда как у BSD какой-нибудь shm_create_largepage болтается в открытую, и скомпилив программу под BSD у тебя нет никакой гарантии, что она соберётся под другие nix-системы.

У GNU инженерная культура на уровень выше.