После шести месяцев разработки опубликован релиз системной библиотеки GNU C Library (glibc) 2.41, которая полностью следует требованиям стандартов ISO C11 и POSIX.1-2017. В состав нового выпуска включены исправления от 68 разработчиков...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=62633
И чем она лучше мusl?
А в вашем настольном дистре что, Musl что-ли?
У меня кстати да, сижу на Alpine, использую на серверах и рабочем десктопе.
И как оно?
Нормально, на первых порах только непонятно, но ничего сложного. На официальной вики в статье musl написано как локали настроить.
Пакеты дробят сильнее других дистрибутивов. Нет всяких "рекомендованных, но по умолчанию устанавливаемых" пакетов.
В общем, знакомишься с настройкой локалей + находишь нужные пакеты какие доставить = нормальный рабочий десктоп.
В установленной системе есть кстати setup- скрипты. Например, setup-desktop. Поставит окружение на выбор, затем минимально дополить и можно работать.
Apk работает, по сравнению с apt/dpkg быстро.
Не забудь community репо включить.
> Нет всяких "рекомендованных, но по умолчанию устанавливаемых" пакетов.Никогда не понимал, почему некоторые так на любят механизм Recommends/Suggests в deb-системах. Может прольёте свет?
> Apk работает, по сравнению с apt/dpkg быстро.
Ну тут заслуга не столько apk, сколько мейнтейнеров alpine. Если ты ориентируешься прежде всего на запуск в контейнерах, то ты будешь стремиться сократить размер базовой системы и свести к минимуму количество install-скриптов, что естественным образом сильно ускоряет процесс.
Ну и конечно, не стоит забывать, что количество пакетов в том же Debian на целый порядок превышает количество пакетов в Alpine. Это тоже неплохо так сказывается на скорости.
> Никогда не понимал, почему некоторые так на любят механизм Recommends/Suggests в deb-системах. Может прольёте свет?Ставят левые пакеты, которые при удалении основного пакета не удаляются. Вилкой вычищать и скать их - то ещё удовольствие. Особенно весело вычищать при удалении мета пакетов.
> Ну тут заслуга не столько apk, сколько мейнтейнеров alpine.
Ответ неверный. Apt/dpkg работает медленно потому что после каждой операции делает sync. Дело здесь не в размере пакетов или их количестве. Разница заметна при установке идентичного ПО.
Установка Xfce со всеми программами и плагинами у меня в Debian занимала на hdd 40-50 минут. На Alpine - 20 минут.
>> Ответ неверный. Apt/dpkg работает медленно потому что после каждой операции делает sync.И правильно делает, dpkg создавали для жестких накопителей. Правильное решение для надежности. Люди ставят ОС чтобы в ней работать, а не форсить апдейты пакетов каждые пол часа как то делают в РАЧлинукс.
Для dpkg есть "решение" в файл /etc/dpkg/dpkg.cfg добавить строку force-unsafe-io
Alpine создавал один единственный по сути красноглазый наркоман у которого задача была создать минимальную ОС, такую чтобы работала в режимах in-memory / diskless mode, это единственное ее отличие от почти всех других ОС.
> Люди ставят ОС чтобы в ней работать, а не форсить апдейты пакетов каждые пол часа как то делают в РАЧлинукс.При чём здесь Arch, в ветке про Alpine? И в Arch, к слову, обновления прилетают реже, чем вы представляете.
> Для dpkg есть "решение"
Как вы это "решение" выполните на этапе установки системы?
>> Никогда не понимал, почему некоторые так на любят механизм Recommends/Suggests в deb-системах. Может прольёте свет?
> Ставят левые пакеты, которые при удалении основного пакета не удаляются.
> Вилкой вычищать и скать их - то ещё удовольствие.Вообще-то удаляются, если задать при удалении флаг --autoremove, ну или если забыли, то потом можно отдельно apt-get autoremove запустить.
> Особенно весело вычищать при удалении мета пакетов.
Ну, во-первых это камень не в сторону Recommends/Suggests, а в сторону именно что мета-пакетов. Во-вторых, мета-пакеты для того и нужны, чтобы облегчить установку софта и защитить от случайного удаления.
В целом, если вы понимаете, что делаете, никаких проблем удалить зависимости мета-пакета нет. Для этого есть такие инструменты как tasksel, ну или же apt-mark, если вам нужен более глубокий уровень контроля за состоянием пакетов.
Я по сути не понимаю следующего: неужели работа с мета-пакетами настолько сложна, что вызывает у пользователей затруднения?
Вы не могли бы, быть может, попытаться вспомнить, что именно вы пытались сделать, и с чем именно не получилось разобраться?
>Для этого есть такие инструменты как...вот эти вот ваши "инструменты" уже говорят о том, что апт говна кусок, в то время как в нормальном дистрибутиве, пользователь имеет ключик --recursive, который не сносит пол системы. а еще в apk есть такая мулька, не помню как называется, суть вот в чем: ставишь пакеты определенным образом(для экспериментов или типа того), пм помечает их в группу, потом просто удаляшь группу со всеми ее зависимостями. ну, той плесени, что поддерживает дебиан, такое и не нужно, работает — не трож! не понимаю я, кто в здравом уме будет пользоваться этим набором костылей не по принуждению
> вот эти вот ваши "инструменты" уже говорят о том, что апт говна кусокА в чём разница? =)
Ну серьёзно, вы в альпине используете прямые аналоги: вместо tasksel у вас setup-desktop, вместо apt-mark auto вы правите файл /etc/apk/world. Одно и то же ведь. =)
> Ну серьёзно, вы в альпине используете прямые аналоги: вместо tasksel у вас setup-desktop, вместо apt-mark auto вы правите файл /etc/apk/world. Одно и то же ведь. =)Снова ответ неверный. В Alpine _нет_ рекомендованных пакетов. Установленные с помощью setup скриптов пакеты удаляются _полностью_, со всеми зависимостями.
> В Alpine _нет_ рекомендованных пакетов.Разве я утверждал обратное?
> Установленные с помощью setup скриптов пакеты удаляются _полностью_, со всеми зависимостями.
Как и в Debian.
>> Ну тут заслуга не столько apk, сколько мейнтейнеров alpine.
> Ответ неверный. Apt/dpkg работает медленно потому что после каждой операции делает sync.Если бы вы потрудились задуматься, вы бы и сами поняли, что тут никакого противоречия нет. Оставлю это вам на подумать.
> Вообще-то удаляются, если задать при удалении флаг --autoremove, ну или если забыли, то помом можно отдельно apt-get autoremove запустить.Снова ответ неверный. Autoremove не удаляет все рекомендации, лично с этим сталкивался и вычищал. Я не жаловался бы, если бы не знал про это всё вживую и досконально.
> tasksel
Это вообще корявые костыли. Tasksel только метапакет удаляет.
> Вы не могли бы, быть может, попытаться вспомнить, что именно вы пытались сделать, и с чем именно не получилось разобраться?Если мой тон был резок, прошу прощения. Если по делу, то: поставил с помощью tasksel gnome, захотел стереть. С помощью tasksel удалился только метапакет. Остальное пришлось искать руками что там поставилось в придачу.
Так что теперь обхожу стороной tasksel, стараюсь по минимуму метапакеты использовать.
Вот, например, как дочиста стереть gnome? Чтобы система была такой же чистой и без лишних пакетов, как и до установки gnome?
>> Вы не могли бы, быть может, попытаться вспомнить, что именно вы пытались сделать, и с чем именно не получилось разобраться?
> Если мой тон был резок, прошу прощения.Ладно. Вы попытались вести себя прилично, да и я тут выпил глинтвейна, да и конец недели. Чего бы собственно и не простить.
> Если по делу, то: поставил с помощью tasksel gnome, захотел стереть.
> С помощью tasksel удалился только метапакет. Остальное пришлось искать руками что там поставилось в придачу. Так что теперь обхожу стороной tasksel, стараюсь по минимуму метапакеты использовать.Это в целом понятно, почему так произошло; и это вовсе не вина tasksel, и уж тем более не вина recommends/suggests.
> Вот, например, как дочиста стереть gnome?
Хороший вопрос. Ответ на самом деле находится на поверхности: tasksel install gnome-desktop делает только то, что устанавливает мета-пакет task-gnome-desktop; а tasksel remove gnome-desktop -- соответственно удаляет этот мета-пакет.
Но да, я понимаю, почему вы могли сильно удивиться, когда autoremove вам удалил несколько десятков пакетов, а не несколько сотен, которые прилетели вслед за task-gnome-desktop. Тем не менее это ожидаемое и правильное поведение, и вот почему: по умолчанию пакетник ставит recommends, но не ставит suggests. Однако при autoremove он уважает и recommends, и suggests.
Таким образом, чтобы стереть gnome дочиста, вам нужно дополнительно дёрнуть:
# apt-get -y -o APT::AutoRemove::SuggestsImportant=false autoremove
В этой команде особая опция, которая прямо указывает пакетнику "не уважать" suggests-зависимости, и помечать их для удаления тоже. Более того, вы можете её выставить по умолчанию в false в /etc/apt/apt.conf.d, если хотите. Мне сдаётся, что тогда поведение APT будет более соответствовать вашим ожиданиям.
> Чтобы система была такой же чистой и без лишних пакетов, как и до установки gnome?
А вот это момент интересный. Посмотрите например на эту зависимость пакета logrotate:
Depends: cron | anacron
Это называется "alternative dependencies". Эта зависимость будет удовлетворена, если стоит либо cron, либо anacron, либо оба сразу. Если изначально в вашей системе стоял только cron, а anacron прилетел как зависимость от гнома -- то при удалении зависимостей гнома из-за этой зависимости ни при каких обстоятельствах нельзя будет принять решение об удалении anacron: ибо откуда пакетнику знать, что нужно удалить именно anacron, а не cron? В общем, anacron останется: "как и до установки gnome" -- не будет. И это совершенно нормально.
Тут важно понимать, что подобное поведение является общим свойством абсолютно всех пакетников, которые реализуют либо альтернативные зависимости, либо виртуальные пакеты (ибо вторые по сути -- это просто вариация первых). В частности, поскольку apk в alpine виртуальные пакеты реализует -- он этому тоже подвержен.
По факту же, отвечая на ваш исходный вопрос: если вы хотите именно что "как и до установки gnome", то надо выгрепать список пакетов, которые были установлены в систему, из /var/log/dpkg.log, и передать их в apt-get remove -y. Это, в принципе, одна строчка на bash. И других способов нет, да и быть, собственно, не может. Во всяком случае, в пределах пакетника. Так-то можно поставить условный LVM и снапшот перед апдейтом системы всякий раз снимать, но это уже за пределами обсуждения возможностей пакетных менеджеров.
Добавлю, что во FreeBSD pkg это сделано с применением флагов - те пакеты, которые были установлены автоматически из-за установки метапакета - помечаются как auto, и есть способ их удалить одним махом. Так же есть pkg_rmleaves и pkg_cutleaves, которые показывают список только тех пакетов, от наличия которых в системе не зависят никакие другие пакеты. Удобно, особенно если вспомнить, что метапакет с тем, что лично тебе нужно - сождать проще простого, фактически один текстовый файл скопировать и поредактировать.
За pkg_rmleaves спасибо. Посмотрел его код и вижу, что в принципе там чуть-чуть можно подпилить и получится аналог для APT: вместо pkg query -e '%#r = 0' вставить aptitude search '~i ! ~R ~i', ну и может быть output подогнать; и должно заработать.
> Ладно. Вы попытались вести себя прилично, да и я тут выпил глинтвейна, да и конец недели. Чего бы собственно и не простить.Спасибо, узнал много полезного. Рад что завершили на хорошей ноте. Хороших выходных.
> Спасибо, узнал много полезного.Да пожалуйста. Удивительно, но после стольких "неверных ответов" я всё равно рад за вас.
>> Вообще-то удаляются, если задать при удалении флаг --autoremove, ну или если забыли, то помом можно отдельно apt-get autoremove запустить.
> Снова ответ неверный. Autoremove не удаляет все рекомендации, лично с этим сталкивался
> и вычищал. Я не жаловался бы, если бы не знал про это всё вживую и досконально.Вы ошибаетесь, autoremove так не работает.
Вы могли наблюдать подобное поведение только в случае, если в системе имелся иной manually-installed пакет, у которого в recommends была та же зависимость.
> Вы могли наблюдать подобное поведение только в случае, если в системе имелся иной manually-installed пакет, у которого в recommends была та же зависимость.Ответ неверный. Вручную пакеты не устанавливаю, всегда из репозиториев. Чем гадать что там у меня, вы либо доверьтесь, либо проверьте - поставьте в виртуалке пакет с tasksel, удалите его с autoremove. Пока что я вижу, что вы это не проверяли ни разу.
>> Вы могли наблюдать подобное поведение только в случае, если в системе имелся иной manually-installed пакет, у которого в recommends была та же зависимость.
> Ответ неверный. Вручную пакеты не устанавливаю, всегда из репозиториев.Ох. Как вы думаете, что вам показывает команда apt-mark showmanual?
> Чем гадать что там у меня, вы либо доверьтесь, либо проверьте - поставьте в виртуалке пакет с tasksel, удалите его с autoremove. Пока что я вижу, что вы это не проверяли ни разу.
Когда вы такое пишете, вас чайник Рассела не смущает?
> Никогда не понимал, почему некоторые так на любят механизм Recommends/Suggests в deb-системах.Попробуйте поставить openssh на сервер, он иксы с собой потащит.
На рабочем десктопе, это в WSL что-ли?
Установлен как основная ОС, без прослоек, без контейнеров и тем более без WSL.
И чем musl хуже glibc?
Если для десктопа, то в нём сторонние бинарники могут не запуститься.
в теории - тем что там медленный (но простой) аллокатор, на что разработчики говорят "используйте jemalloc через LD_PRELOAD, если вам так надо". На практике, естественно, никому не надо.
На практике разницы не замечал.
>И чем musl хуже glibc?чем дефакто стандарт хуже поделки для ембед?
Оптимизацией. Musl выигрывает простотой кода и размером, что удобно для встраиваемых систем. Glibc лучше оптимизирован, но кодовая база более запутанная, и разбросана по разным директория, притом логики в этом практически нет, для одной архитектуры файлы реализации могут лежать в одно месте, а для другой может быть совершенно другим, и где по логике должна быть реализация, лежит C файл заглушка, т.е. директория с именем архитектуры ничего говорит, о том есть ли там файлы с реализацией, или там будут файлы заглушки лежать, есть не мало дублирующегося кода.
> Glibc лучше оптимизированЧто-то это противоречит новости.
"Из проекта CORE-MATH перенесены оптимизированны и использующие правильное округление варианты функций"
Т.е в Glibc годами были не оптимальные функции.
А вы думаете у конкурентов дела лучше и чудеса математики происходят?
Аллокатор памяти (malloc) до 20 раз быстрее. Мне импонирует подход musl к безопасности и корректности работы с памятью, но софт на Си имеет свою специфику - я хочу чтобы он был быстрым т.к. иначе ВСЁ тормозит 🤷♂️
Лол это самое быстрое из того что есть.
Нет. Мусловский аллокатор ужасен, его обычно сразу заменяют на jemalloc.
Сейчас всё чаще предлагают mimalloc использовать.
На масле не весь софт работает и специфических оптимизаций меньше, но зато лёгок и менее требователен, потому он востребован на встройках с alpineos и проч.
В мюслях уже починили тормозной аллокатор? Или getaddrinfo?
> В мюслях уже починили тормозной аллокатор?jemalloc, mimalloc
> Или getaddrinfo?Давно, в alpine начиная 3.18
Всем лучше. Прежде всего совместимостью и тем, что под гну.
ada с musl не заводится, хотя я пару лет назад проверял, может исправили уже
> И чем она лучше мusl?Тем, что можно подсадить на зависимость от версии glibc и заставить все время обновляться, ну и когда надо поиметь (потому как 1000 глаз в опенсырце, как оказалось - не достаточно).
> И чем она лучше мusl?Glibc устарел.
А так, Musl и Bionic лучше, современее.
Пока что лучшая библиотека из существующих.
Это точно.
getenv/setenv не починили?
Ссылочку на багрепорт можно? Либо как это проверить у себя? Вроде не возникало проблем пока что.
> Ссылочку на багрепорт можно? Либо как это проверить у себя?
> Вроде не возникало проблем пока что.Кто-то пропустил тред на лоре про потоконебезопасность этих функций.
linux.org.ru/forum/development/17857557
не находите странным упрекать пользователя опеннета в том, что он "пропустил тред про потоконебезопасность функций в С_на форуме ЛОРа_" ?
> не находите странным упрекать пользователя опеннета в томНеа, что там, что там практически одни и те же лица.
Я бы мог спросить "не читали ли вы обсуждение на ycombinator или пост на edgedb?"... но какие шансы что кто-то забрел туда?Причем оно сделано настолько убого согласно стандарту POSIX)
Можно, просвещайтесьgithub.com/golang/go/issues/63567
rachelbythebay.com/w/2017/01/30/env/
evanjones.ca/setenv-is-not-thread-safe.html
gnu.org/software/libc/manual/html_node/Environment-Access.html#Environment-Access
> Из проекта CORE-MATH перенесены оптимизированные
> и использующие правильное округление варианты функцийТ.е. все эти годы функции из божественной жлo6-си неправильно округляли результаты?
Не то чтобы я был сильно удивлен... но это сильно.
Эти округления практически не влияют на результат вычисления, там какие-то минимальные погрешности. Я вам открою секрет во многих математических программах так же происходит, например если взять подсчет детерминанта матрицы, то к примеру по формуле с курса линейной алгебры вы просто получите например 1.0, а математические программы вам будут показывать что-то типа 0.999999673223. Попробуйте догадаться почему так происходит.
> Попробуйте догадаться почему так происходит.Я прекрасно понимаю почему такое может быть. О таком рассказывают в первом семестре численных методов. И оно округляет абсолютно верно в контексте машинных расчетов. А вот если оно округляет, но неправильно - то это проблема.
Вам не кажется что в математических функциях результат вычислений должен быть точен и соответствовать стандартам? Тем более, если это стандартная либа.
Иначе получается как-то странно - мы считаем как попало, а если нужно точно - вот тогда иди и бери нормальную мат. либу.
> Вам не кажется что в математических функциях результат вычислений должен быть точен и соответствовать стандартамА с чего вы решили, что он не точен и не соответствует стандартам?
В машинных расчетах есть две противоположности, расчеты или быстрые с определенным уровнем достоверности, или расчеты точные и медленные. Не редко существует очень большое количество формул расчетов одного и того же, и программист может выбрать, что ему важнее в его ПО. Еще один немаловажный факт, математика как наука не стоит на месте, над софтом и математическими программами работает не малое количество аспирантов и докторов наук, появляются более современные и точные методы вычислений, при этом надо не забывать, что glibc это многоархитектурная библиотека, и на каждой архитектуре тоже есть свои ограничения.
> которая полностью следует требованиям стандартов ISO C11Шел 2025й год :D
Хотя, чего тут удивляться.
Ура, бинарники собранные с прошлой версией превращаются в тыкву!
Чего вдруг? Поля в структуры между существующими не вставляли, сигнатуры прежних функций не менялись.
> Чего вдруг?Вы никогда не вречались с:
"error: GLib >= 2.28 is required" ?
И как это >= повлияет на бинарник прошлой версии? Правильно - никак.
> И как это >= повлияет на бинарник прошлой версии? Правильно - никак.Error - по английски - ошибка, от того самого бинарника, который не запускается, уточняю - не работает, не запускается, не выполняет своих функций, не portable across the same platform.
Откуда у тебя в бинарнике _прошлой_ версии - требование >= версии библиотеки которой у тебя нет? У тебя точно все в порядке с причинно-следственной связью и математикой второго класса начальной школы?Этот бинарник у тебя, видимо, наоборот - собран с более новой версией библиотеки. Разумеется не запускается, где он тебе возьмет sched_setattr которой у тебя еще просто нет?
То что это на самом деле следовало бы предоставить линкеру (может там и нет никакой sched_settatr) - разбивается о людишек, не понимающих знака больше-или-равно. Поэтому нате вам версионные символы вбитые намертво, чтоб вы не засоряли багтрекеры своими безграмотными жалобами что у вас "ниработаит".
> У тебя точно все в порядке с причинно-следственной связью и математикой второго класса начальной школы?Хам. Обыкновенный. Нах... короче
> Этот бинарник у тебя, видимо, наоборот - собран с более новой версией библиотеки.
Да ты просто "гений" !!! Рад за тебя что догнал !
> То что это на самом деле...
От твоей демагогии дестрибьютить на разный заоопарк легче не станет. И проблема не в линкере, а в том что там спецон залочили так чтоб нельзя было собрать статику
Я тебе сопли вытирать не собираюсь.> От твоей демагогии дестрибьютить на разный заоопарк легче не станет.
тебе бы стало легче если бы ты владел темой. Умел отличать glibc от glib, знал чем dlopen отличается от обычного связывания и как это понять по выводу ошибки, и что на самом деле означает именно та ошибка, которую ты привел, и почему ее довольно глупо приводить в новости о libc.
Тогда бы вместо того чтобы тыкать тебя пальцем в твою глупость - я бы тебе, как тоже инженеру но недостаточно еще разбирающемуся в деталях - рассказал бы кое-что интересное про glibc (там все гораздо сложнее с версионностью чем в обычных библиотеках - ДА, в том числе потому что разработчики пытались в совместимость "вперед").
И да, я могу собрать программу так, чтобы она запускалась на твоем "зоопарке". Но я совершенно ничего не смогу сделать с тем, что она на самом деле использует функцию, появившуюся только в новейшей версии библиотеки. Софт имеет свойство развиваться, удивительно, но факт. Если разработчик не хочет сохранять совместимость со старыми версиями - хрен ты чего с этим сделаешь. (Ну бэкпорт ты точно ниасилишь)
Нет, не надо тебе собирать статику. Это вот вообще никуда не годный способ обойти проблему "код использует наисвежайшую функцию из еще недописанного релиза, а мне кровь из носу он нужен на моей sls 1.3"
И да, - удачи собрать статически бинарь под амд64 чтоб обойти эту проблему, если там не нароком что то связанно с сетью (а что сейчас с ней не связанно?)
в твоем случае - а ты не сумел отличить glibc от glib - нет никакой проблемы собрать статическую glib. Кроме той что если тебе ту строчку выдала _программа_ - это dl_open, и ее автор имел в виду именно это - с более старой не работает. Зачем ради копеечной glib понадобился dlopen - спроси у автора, может он для stm32 программировал.Несовместимость именно glibc выглядит как "unresolved symbol GLIBC_2.41" и там все значительно сложнее. Не надо тебе собирать ничего статически с такими познаниями.
> в твоем случае - а ты не сумел отличить...
> Кроме той что если тебе ту строчку выдала _программа
...
> Не надо тебе собирать ничего статически с такими познаниями.Да, ты такого большого мнения о себе, но как был нах, так нах никому и ненужен со своими телепатическими и безпонтовыми советами
>В заголовочный файл math.h добавлены тригонометрические функции, появившиеся в стандарте C23 (TS 18661-4:2015): acospi, asinpi, atan2pi, atanpi, cospi, sinpi и tanpi.Вопрос лютым математикам. Расчёты и всякие числодробилки с каким ПО используете?
Вся компьютерная графика, по сути.
Microsoft Excel 2024 же
> Расчёты и всякие числодробилки с каким ПО используете?Исключительно самописанное. На С++. Уже 30 лет как.
да, нормального фортрана на PC в 95м не было, это факт.Хммм... нормального с++ правда тоже. Си-с-классами был.
Путь эволюции был такой: Фортран -> Фортран + С (для интерфейса) -> C++ (для всего) -> С++ (extern "C", для алгоритмов) + VBA (для интерфейса) -> C++ (для алгоритмов) + StarBasic (для интерфейса). Пока так.
Забыл побочную ветвь C++ + Qt, но разработка на паузе из-за невостребованности. Хотя местами красиво, особенно графики нравятся.
Blas, cblas， lapack, lapacke.Но вообще говоря, лютые математики численными методами не пользуются, ими в основном пользуются лютые физики.
А математики большей частью пользуются ручкой и бумагой, потому что всё, что им в первую очередь интересно, дискретными приближениями не описывается.
Но в принципе ты можешь посмотреть на Maxima, cadabra2, reduce, sagemath, fricas. Ну, и для совсем мастеров своего дела, варезная Magma.
> лютые математики численными методами не пользуютсяНе согласен. А продвинутая статистика, моделирование Монте-Карло и прочие типа нейронных сетей?
>продвинутая статистика, моделирование Монте-КарлоЭто всё не продвинутая математика, а счетоводство.
>нейронных сетей?Какую премию выдали Хинтону?
Может, и так. Вам, авторам
> Blas, cblas， lapack, lapackeи получателям премий, виднее.
> дискретными приближениями не описываетсяМожно подробнее? Что это за приближения, к чему приближения и почему не описывается.
Числа "вещественные" в информатике это, по сути, рациональные числа, с точки зрения математика.
Теперь понятно всё. Действительно, без
> Blas, cblas， lapack, lapacke.не обойтись.
Не правильно. Все "числа" в информатике это математическими объекты. И никакой другой трактовки тут нет. Информатика привнесла понятия "чисел с плавающей точкой, и фиксированной точкой". В русском переводе плавающая, и фиксированная запятые. Да, на этот раз, это чисто инженерно-программисткая тема. Дополнительно, общую картину усложняет наличие в языках программирования типы float, double и т.д.
> Blas, cblas， lapack, lapackeСвятая наивность. Полагаете, что вам предоставят эффективные и работающие (привет, SSP от IBM) функции, чтобы, перефразируя Бартини, "черные самолеты летали быстрее красных"? С такими фреймворками они не только не взлетят, а до взлетной полосы не докатятся.
Как показывают публикации за последние полгода, российские и китайские специалисты ускорили вычисления от 800 до 100 тысяч раз по сравнению ... ну и т.д.
>российские и китайские специалисты ускорили вычисления от 800 до 100 тысяч раз по сравнению ... ну и т.д.Это как из афоризм преподавателей военной кафедры 1980-х.
- Товарищ подполковник, а у вас там по схеме, что вы нарисовали, ток так не пойдёт.
- Советский ток куда надо, туда и пойдёт.
В Калифорнии помнят советские анекдоты?
Да, бывший агент КГБ Константин Боровой не даст соврать.
А где традиционные пункты:
1) изменено API
2) удалены "устаревшие" функции
3) нарушена обратная совместимость
?
Это самая базовая библиотека. Не помню случая, чтоб в GLibc меняли API в сторону изменеия поведения уже существующих функций. И "устаревшившие функции", которые Тео у себя давно выпилил, ибо небезопасны, тут тоже на месте. А добавление новых, так это старому софту не мешает.
В чистом Си нет понятия API. GTK - это API. Glibc - это реализация Стандартной библиотеки языка Си, написанное сообществом GNU. Текущий релиз полностью поддерживает стандарт C11. С временем допилят до полной поддержки C23. Устаревшие или исторические функции описанные в предыдущих стандартах типа ANSI 89 вряд ли будут выпиливать.Если кто-то хочет сам, в сей час, реализовать Стандартую билиотеку языка Си, то логично что надо сразу начать с текущего стандарта C23. А исторические функции описанные в предыдущих стнадартах просто игнорировать. Вот так всё просто!
И кроме фунций стандартной библиотеки языка C, в GLibc также реализованы Линукс-специфичные функции. И их там немало.
>А исторические функции описанные в предыдущих стнадартах просто игнорировать. Вот так всё просто!Но ещё придётся убедить писателей прикладного софта привести его в соответствие с C23. А это не просто.