The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Red Hat прекращает разработку CentOS 8 в пользу тестового CentOS Stream, opennews (??), 08-Дек-20, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


293. "Red Hat прекращает разработку CentOS 8 в пользу тестового Ce..."  –2 +/
Сообщение от Аноним (269), 09-Дек-20, 11:10 
Alpine с GLibc есть?
Ответить | Правка | Наверх | Cообщить модератору

438. "Red Hat прекращает разработку CentOS 8 в пользу тестового Ce..."  –1 +/
Сообщение от Аноним (146), 09-Дек-20, 23:43 
На кой нужен этот glibc? Дай пример, где этот glibc просто необходим. Зато как только свяжешься с glibc, то получишь "а статическую линковку мы вам запретили, ути-пути, вы воруете наш код". Спасибо, но сейчас тренд "все новое -- хорошо забытое старое" и статическая линковка снова в моде. Почему? Потому что возможности современных компов таковы, что уже давно нормальные люди забили болт на ОЗУ, диск, заботит другой фактор - удобная доставка.
Ответить | Правка | Наверх | Cообщить модератору

449. "Red Hat прекращает разработку CentOS 8 в пользу тестового Ce..."  +/
Сообщение от n00by (ok), 10-Дек-20, 08:14 
> Потому что возможности современных компов таковы, что уже
> давно нормальные люди забили болт на ОЗУ, диск, заботит другой фактор
> - удобная доставка.

Скажу Вам по секрету. Статически слинкованный "ЗдравствуйМир!" на С++ (то есть не puts(), а настоящий std::cout) -- может быть порядка 20 килобайт. Как раз из-за статического связывания, когда лишнее не тянется. Но, да, без glibc.

Ответить | Правка | Наверх | Cообщить модератору

468. "Red Hat прекращает разработку CentOS 8 в пользу тестового Ce..."  +/
Сообщение от Аноним (146), 10-Дек-20, 12:54 
Спасибо, давай превращать тред в женкс.. мужицкие секреты c++. Товарищъ, вы начните писать код сложнее helloworld, там что-нибудь на потоках (pthread) или boost придумали для вас просто так?

Вот тут недавно чел решил переехать на musl с бинарями собранными с glibc: https://www.openwall.com/lists/musl/2020/11/20/1 Там особо ничего нового, но так, может быть интересно.

Еще раз повторю, что вопросов размеров бинарей, а также других накладных от статической линковки уже никто не задает. Вопрос в том, насколько удобно доставить рабочее приложение клиенту. Если не поняли, то собирать на компе клиента или докачивать и устанавливать зависимости вручную или автоматом (а последнее дело сложное), то это нифига не удобная доставка. Посмотрите как доставляются/поставляются WhatsApp, Telegram. Это давно поняли и ребята из комманды go lang, давно поняли ребята из docker и многие другие. Просто сейчас это уже становится мейнстримом, а не уделом избранных.

Ответить | Правка | Наверх | Cообщить модератору

483. "Red Hat прекращает разработку CentOS 8 в пользу тестового Ce..."  +/
Сообщение от n00by (ok), 10-Дек-20, 14:50 
Даже и не знаю, как Вам объяснить. std::cout означает, что стандартная библиотека С++ прилинкована (статически и в 20К). Значит с ней соберётся и boost (выйдет, понятно, побольше). А треды... они часть стандартной библиотеки, насколько помню. Иначе говоря, вопросы "размеров бинарей, а также других накладных от статической линковки" -- несколько преувеличены.
Ответить | Правка | Наверх | Cообщить модератору

507. "Red Hat прекращает разработку CentOS 8 в пользу тестового Ce..."  +/
Сообщение от Аноним (146), 10-Дек-20, 17:02 
>Даже и не знаю, как Вам объяснить. std::cout означает, что стандартная библиотека С++ прилинкована (статически и в 20К).

А я и отвечаю, что ок, статически, но про 20к могли бы и не говорить, потому что не имеет никакого смысла.

>Значит с ней соберётся и boost (выйдет, понятно, побольше). А треды... они часть стандартной библиотеки, насколько помню.

Я понимаю, что на openwall не очень удобно читать весь тред сообщений. Но там отличный пример того, как одна функция pthread_create реализована через ... хитро-"умную" схему и как это все ломается в glibc как только делаешь шаг влево. У них такого кода полно и в libc и в libstdc++, они его используют везде где могут. В результате, при "переезде" на нормальные либы, типа musl, получается фуфло, ибо гнушные, повернутые (там не все такие, уверен) ребята решили, что ты пытаешься скомуниздить их код. И это очень странный подход, т.к. вместо конкретного случая нарушения, они не спрашивая делают бяку: у тебя опенсорс проект и ты честный? Нам по***, ты своруешь код, мы знаем, гарантия 200%. Вот их сегодняшняя логика. Т.е. они так решили вопрос не платить и не ходить по судам, им это не надо, главное запретить всеми способами якобы воровать их код.

>Иначе говоря, вопросы "размеров бинарей, а также других накладных от статической линковки" -- несколько преувеличены.

Возращаясь к размерам. Забыли вспомнить главный аргумент против статической линковки - слишком много копий одного и того же кода. Программа А использует либу Х, и программа Б использует либу Х. В случае статической линковки получается двойной размер либы Х. Об этом речь, а не о том насколько больше получается бинарник в статике против аппликуха + шаренные либы.

Ответить | Правка | Наверх | Cообщить модератору

512. "Red Hat прекращает разработку CentOS 8 в пользу тестового Ce..."  +/
Сообщение от n00by (ok), 10-Дек-20, 19:00 
>>Даже и не знаю, как Вам объяснить. std::cout означает, что стандартная библиотека С++ прилинкована (статически и в 20К).
> А я и отвечаю, что ок, статически, но про 20к могли бы
> и не говорить, потому что не имеет никакого смысла.

По-моему, аргументы "разжиреет на 3Мб" не имеют смысла как раз из-за этих 20Кб. Цифры объективны, а "всем плевать на размер" - субъективно (даже если так и есть).

>[оверквотинг удален]
> только делаешь шаг влево. У них такого кода полно и в
> libc и в libstdc++, они его используют везде где могут. В
> результате, при "переезде" на нормальные либы, типа musl, получается фуфло, ибо
> гнушные, повернутые (там не все такие, уверен) ребята решили, что ты
> пытаешься скомуниздить их код. И это очень странный подход, т.к. вместо
> конкретного случая нарушения, они не спрашивая делают бяку: у тебя опенсорс
> проект и ты честный? Нам по***, ты своруешь код, мы знаем,
> гарантия 200%. Вот их сегодняшняя логика. Т.е. они так решили вопрос
> не платить и не ходить по судам, им это не надо,
> главное запретить всеми способами якобы воровать их код.

Спасибо за пояснения. По ссылке на openwall видел только техническую информацию, а ошибок и "нотабагов" во всех библиотеках хватает.

>>Иначе говоря, вопросы "размеров бинарей, а также других накладных от статической линковки" -- несколько преувеличены.
> Возращаясь к размерам. Забыли вспомнить главный аргумент против статической линковки -
> слишком много копий одного и того же кода. Программа А использует
> либу Х, и программа Б использует либу Х. В случае статической
> линковки получается двойной размер либы Х. Об этом речь, а не
> о том насколько больше получается бинарник в статике против аппликуха +
> шаренные либы.

А что, кто-то приводит такие аргументы? Есть же LTO. Когда изучал вопрос, а с тех пор компиляторы малость ушли вперёд, тогда можно было определить 2 функции с разным именем но идентичным телом (или даже только побочным эффектом), а в исполняемом файле оказывался один экземпляр (не всегда, но тем не менее).

Ответить | Правка | Наверх | Cообщить модератору

514. "Red Hat прекращает разработку CentOS 8 в пользу тестового Ce..."  +/
Сообщение от Аноним (146), 10-Дек-20, 19:36 
Могу дать еще один довод. При статической линковке ОЗУ тоже расходуется не оптимально. Зато шаренная либа грузится один раз и дальше по списку о том как это здорово.
Ответить | Правка | Наверх | Cообщить модератору

535. "Red Hat прекращает разработку CentOS 8 в пользу тестового Ce..."  +/
Сообщение от n00by (ok), 11-Дек-20, 07:17 
Вернёмся к примеру с 20Кб. Дело не в самом статическом связывании, а в том, с чем линкуют. Если при создании библиотеки ставится цель "можно использовать только как разделяемую", разумеется, в другом сценарии получится "не оптимально".
Ответить | Правка | Наверх | Cообщить модератору

545. "Red Hat прекращает разработку CentOS 8 в пользу тестового Ce..."  +/
Сообщение от Аноним (545), 11-Дек-20, 15:22 
>Если при создании библиотеки ставится цель "можно использовать только как разделяемую"

Этот сценарий я видел только в гнушных либах. Во всех других случаях этой ерунды нет. И нет ни одного довода почему я так не могу делать: ни из-за безопасности (кто сказал, что клиент обновляется регулярно и мейнтернеры его дистрибутива умнее меня?), ни из-за размера (кто сказал, что это критично?), ни из-за ОЗУ (кто сказал, что у меня ее недостаточно?). Единственное исключение это лицензия библиотеки. Но и в последнем случае единственным препятствием может быть только жопотень в коде, как делают в glibc, libgcc, если я использую свой код локально, нигде не публикую и ни с кем не делюсь им.

Ну, я тут не беру в расчет либы, которые пишутся без PIC или с другими "оптимизациями". Во всяком случае PIC чаще всего легко включается.

Ответить | Правка | Наверх | Cообщить модератору

563. "Red Hat прекращает разработку CentOS 8 в пользу тестового Ce..."  +/
Сообщение от Аноним (-), 12-Дек-20, 12:48 
> Вернёмся к примеру с 20Кб. Дело не в самом статическом связывании, а
> в том, с чем линкуют.

С статической линковкой потом еще проблема в том что если в либе что-то не так - и это что? Все 50 программ рекомпилить? Вместо того чтобы 1 либу пакетником заменить? Ну так это маздай с винлокерами получится.

Ответить | Правка | К родителю #535 | Наверх | Cообщить модератору

570. "Red Hat прекращает разработку CentOS 8 в пользу тестового Ce..."  +/
Сообщение от n00by (ok), 12-Дек-20, 14:31 
Предусматривать проблемы и предвидеть, это хорошо. Вот Вам история из жизни.

Некий персонаж нахамил мне прилюдно.
Я подождал, потом спросил его, хорошо ли у него работает видеопроигрыватель Kodi.
Прошло ещё немного времени, в его любимой ОС обновили Kodi (ffmpeg там используется системный), и у того персонажа тетеньки в фильмах из папочки XXL принялись разговаривать голосами дяденек.
Он неделю просидел в соответствующей шапочке, полагая, что я через этот Kodi управляю его компами и решил его таким образом наказать. Потом его прорвало.

В общем, аргумент работает в обе стороны.

Ответить | Правка | Наверх | Cообщить модератору

509. "Red Hat прекращает разработку CentOS 8 в пользу тестового Ce..."  +1 +/
Сообщение от phprus (ok), 10-Дек-20, 18:34 
glibc нужен примерно всегда, так как он значительно быстрее, чем musl (а musl нужен только в тех случаях, когда критична не загрузка CPU, а место на диске).

Тесты http://www.etalabs.net/compare_libcs.html показывают, что glibc в 2-5 раз быстрее musl, за исключением операций с UTF-8, но это связано с тем, что в musl ограничена поддержка локалей.
Ветка комментариев https://www.opennet.me/opennews/art.shtml?num=48850#5

Ответить | Правка | К родителю #438 | Наверх | Cообщить модератору

513. "Red Hat прекращает разработку CentOS 8 в пользу тестового Ce..."  –1 +/
Сообщение от Аноним (146), 10-Дек-20, 19:30 
Спасибо. И что? Это нужно для всех кейсов? На десктопе это важно? Нет. Если уж говорить про скорость, то ответ один - на асме руками все это можно до-оптимизировать, что будет еще быстрее. Можно даже фигачить на FPGA.

Кроме того, musl-1.1.5.tar.gz вышел Oct 14, 2014 https://musl.libc.org/releases.html
Сейчас может лучше, может хуже, но статистика однозначно устарела. Собственные замеры есть, которые это подтверждают? Или просто поверили на слово?

Ответить | Правка | Наверх | Cообщить модератору

520. "Red Hat прекращает разработку CentOS 8 в пользу тестового Ce..."  +/
Сообщение от phprus (ok), 10-Дек-20, 20:33 
> Спасибо. И что? Это нужно для всех кейсов? На десктопе это важно?

На серверных нагрузках важно. Даже в некоторых моих объективно маленьких задачах 20% процентов производительности - это может быть с десяток лишних серверов. А здесь есть люди у кого задачи куда масштабнее.
А разница в два раза в производительности аллокаций очень сильно бьет по интерпретируемым языкам, например, по Python.

> Нет. Если уж говорить про скорость, то ответ один - на
> асме руками все это можно до-оптимизировать, что будет еще быстрее. Можно
> даже фигачить на FPGA.

И это тоже применяется (правда мы до FPGA не доходили, пока хватало CPU и GPU), но все эти способы стоят денег и не малых, а смена musl на glibc чаще всего бесплатна, так как glibc идет в дистрибутивах из коробки.

> Сейчас может лучше, может хуже, но статистика однозначно устарела. Собственные замеры есть,
> которые это подтверждают? Или просто поверили на слово?

Эта статистика приведена одними из авторов musl, а раз он не удаляет ее, значит она адекватна.
Впрочем, есть и более новые ссылки, например, вот эта:
https://andygrove.io/2020/05/why-musl-extremely-slow/

Ответить | Правка | Наверх | Cообщить модератору

527. "Red Hat прекращает разработку CentOS 8 в пользу тестового Ce..."  +/
Сообщение от Аноним (146), 10-Дек-20, 23:57 
>Впрочем, есть и более новые ссылки, например, вот эта: https://andygrove.io/2020/05/why-musl-extremely-slow/

Видел. Это уже неактуально. В 1.2.1 новая реализация malloc. Черновик можно глянуть тут https://github.com/richfelker/mallocng-draft

Ответить | Правка | Наверх | Cообщить модератору

564. "Red Hat прекращает разработку CentOS 8 в пользу тестового Ce..."  +/
Сообщение от Аноним (-), 12-Дек-20, 12:52 
> Видел. Это уже неактуально. В 1.2.1 новая реализация malloc.

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

Ответить | Правка | Наверх | Cообщить модератору

528. "Red Hat прекращает разработку CentOS 8 в пользу тестового Ce..."  –1 +/
Сообщение от Аноним (146), 11-Дек-20, 00:08 
>На серверных нагрузках важно. Даже в некоторых моих объективно маленьких задачах 20% процентов производительности - это может быть с десяток лишних серверов. А здесь есть люди у кого задачи куда масштабнее.

Что касается производительности, то вы сами ниже превели линк чела, который делает все как профи. Взял и заменил malloc из musl на jemalloc, да, возникли сложности. Да, это признал автор musl и да, он уже это исправил. Где новые тесты, что все плохо? И да, я заставляю делать эту работу, потому что меня все устраивает.

>А разница в два раза в производительности аллокаций очень сильно бьет по интерпретируемым языкам, например, по Python.

Я сначала подумал, что это я сморозил глупость спросив про производительность glibc и зачем он вам нужен. Но видимо нет. Какой смысл мерить циклы в каких-то недоинтерпертаторах??? Да, я тот кто не понимает писькомерство интерпретаторов. Никогда не упоминайте производительность и Python/Perl/PHP/Ruby/etc в одном предложении. Просто страдайте.

Ответить | Правка | К родителю #520 | Наверх | Cообщить модератору

536. "Red Hat прекращает разработку CentOS 8 в пользу тестового Ce..."  +/
Сообщение от n00by (ok), 11-Дек-20, 07:20 
> А разница в два раза в производительности аллокаций очень сильно бьет по
> интерпретируемым языкам, например, по Python.

Вы это серьёзно? То есть там не свой специально для Питона оптимизированный аллокатор, а какой попало?

Ответить | Правка | К родителю #520 | Наверх | Cообщить модератору

546. "Red Hat прекращает разработку CentOS 8 в пользу тестового Ce..."  +/
Сообщение от Аноним (545), 11-Дек-20, 15:46 
>То есть там не свой специально для Питона оптимизированный аллокатор, а какой попало?

FYI: https://docs.python.org/3/c-api/memory.html#pymalloc
pymalloc оптимизирован для объектов меньше 512 байт (внутри mmap по возможности или фолбэк на malloc). Так что предыдущий оратор в чем-то прав.

Ответить | Правка | Наверх | Cообщить модератору

558. "Red Hat прекращает разработку CentOS 8 в пользу тестового Ce..."  +/
Сообщение от n00by (ok), 12-Дек-20, 09:10 
Спасибо. Там ключевое, скорее, не размер объектов, а "с коротким временем жизни" (поскольку затачивается под сборщик мусора). Потому и не понятно, откуда берутся изменения в скорости из-за библиотечного аллокатора. Вероятно, дело в чём-то другом.
Ответить | Правка | Наверх | Cообщить модератору

537. "Red Hat прекращает разработку CentOS 8 в пользу тестового Ce..."  +/
Сообщение от ACCA (ok), 11-Дек-20, 07:55 
> Тесты http://www.etalabs.net/compare_libcs.html показывают, что glibc в 2-5 раз быстрее
> musl, за исключением операций с UTF-8, но это связано с тем,

Ага. Ну ещё и поведение при нехватке памяти для regcomp and regexec. Подумаешь, мелочь...

Ответить | Правка | К родителю #509 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру