Comments 162
Сарказм:
Сначала дождёмся, когда Астра-Линукс выловит совсем-ошибки. И тогда можно предложить им перейти на альтернативы (libmusl или др.).
Если не сарказм, то это напоминает известный мем: 15 разъёмов для зарядки мобильников??? Это ужас!!! Разъём должен быть единым!!! ... Теперь 16 разъёмов для зарядки ...
Уж лучше glibc допиливать. Википедия говорит, что libmusl он больше в embedded и слегка устарел по стандартам.
Мем с зарядками не актуален, когда все перешли на новый стандарт, оставив весь тот зоопарк в прошлом.
Способ, как это решили у зарядок, тут не прокатит и его можно не учитывать...а вообще мем про конкурирующие стандарты в целом более к месту
Это решаемо при помощи довлеющего авторитета. Торвальдс или Столлман... Кризис GNU еще и в том, что в настоящее время сообщество не порождает таких "атаманов", которые могут повести за собой всю разрозненную "ватагу" разработчиков.
Какой авторитет - для сегодняшней молодежи из разработчиков - его нет от слова совсем. Думаю и серьезная open source разработка за бесплатно - полностью потеряла свой смысл - как некий стимул для будущей карьеры разработчика. Линукс со своей кучей сборок и С - стал неинтересен и у него давно уже нет чего либо действительно серьезного как операционной системы. Думаю будущее - за операционной системой - которая не файловая (эти динозавры - даже не смешны). Так - просто личное мнение.
Если основной пул разработчиков дистрибутивов (RedHat aka IBM, Debian, ...), крупные поставщики ПО (MS как ни странно), тупо в междусобойчике перейдут, то остальные, конечно сильно плача, вынуждены перейти в мейнстрим.
Демократия - она такова, куда смотрит большинство (крупные дяди, определяющие что правильно) - то правильно. Такова жизнь.
Никто не спорит, что Патрик или мантайнеры Арча или тот же Базальт (АльтЛинукс), смогут долго плыть поперек течения, как с общим решением с SystemD, но общая масса пойдёт куда ведут не сильно рассматривая путь.
Демократия - она такова, куда смотрит
большинство(крупные дяди, определяющие что правильно) - то правильно. Такова жизнь.
Вот поэтому, по моему глубокому убеждению (почёрпнутым у Прудона и Бакунина), демократия без анархии не ведет к свободе. Только анархия может породить порядок гарантирующий свободу личности. В том числе и свободу личного творчества.
Большинство, когда говорят - "такова жизнь", просто констатируют сложившуюся ситуацию. а Ведь мы наглядно видим как жизнь меняется. Общественная жизнь определяется культурой общества. Чем больше в обществе образованных людей, тем более сложные отношения в нем возникают. И тем большая ценность индивидуальной свободы.
Пруф ссылкой на авторитет
Я понимаю, но нормальных, долгоживущих анархических проектов не наблюдается.
Человек, скотина такая, начинает подгребать власть, особенно когда самке этого человека захочется быть самой-самой, то быстро любые анархические структуры вырождаются.
Как и в сложных ситуациях вече не дает решения, а нужно решение одного (одной узкой группы), который и продавливает своё "демократическое" решение.
Любой идеализм не переживает столкновения с реальностью.
Идея что анархия идеализм - активно навязывается. На самом деле все чистые идеи - идеализм. Демократия. Монархия. Олигархия. В обществе всегда присутствуют различные элементы из которых формируются общественный строй. Он определяется развитием производственных сил.
ИМХО, в современном обществе доля анархии недооценена.
Может так совпало, но я замечаю что разработчики с опытом обычно не участвуют в опенсорсе ибо, неожиданно, им не платят. А вот студентов самых-самых юных там полно и качество соответствует.
Куда прикажете девать уже выпущенные устройства? Их под новый стандарт скорее всего не переделать. Аналогично и с ПО - не всё ПО обновляется лёгким щелчком пальцев
Если честно, не вижу с этим особых проблем. Что железо, что ПО, устаревает. Это естественный процесс, который был всегда. Почему аудиокассеты устарели, а какая нибудь нокиа 3310 должна служить ещё многие десятилетия?
Потому что в ТЗ на поставку выставлен срок поддержки в 10 или 15 лет (или больше). И разработчик/поставщик на такие условия подписывается (или не участвует в поставке). И вот тогда и условные аудиокассеты продолжают работать и всё остальное. А ПО собирается из "древних" исходников устаревшим компилятором под устаревшую платформу.
Как выясняется, не всем нужно самое новое и актуальное. :)
Так ведь не устарели и функции свои выполняют и пользователей своих удовлетворяют.
никто не спорит. просто скажут, а с версии ХХ.УУ вы используете другое.
много таких уже случаев произошло за долгие 28 лет что я наблюдаю в линуксе, но мало какой из активно используемых продуктов от этого умер. пусть, как с Qucs с серьезным запозданием, или появились альтернативы, но...
для тяжелых случаев будет очередная библиотека compat-xxx
И породили в итоге еще больший зоопарк с вроде бы совместимыми разъемами, но несовместимыми протоколами быстрой зарядки.
musl в Alpine Linux используется. Alpine активно используется в docker-контейнерах.
Я вот посмотрел сейчас более подробно на musl. Судя по всему он более современный и менее совместимый с приложениями-старичками.
Тут таблица сравнения. Допустим мы ей верим. Тогда
Из неё видно, что например однобайтовые локали плохо мюсли поддерживаются, зато utf-8 свой родной. Ну и хрен бы, честно говоря, с этими старыми локалями. Линукс и все более-менее развивающиеся проекты давно перешли на utf-8, и правильно сделали. И то, что в glibc это работает медленно совсем не в её пользу.
Также лучшая обработка внештатных ситуаций, о чём собственно статья.
Вопреки тому, что утверждает @Apoheliy, ссылаясь на википедию, поддержка платформы PC-x64 вполне на уровне.
Очевидные недостатки: страдает regexp, и возможно, не хватает POSIX localedef; нет отладки, т.е. я не смогу лог добыть как сделал в данном случае. Хотя в случае glibc это пока что мало помогло.
Использовать Alpine на проде это очень смелое решение.
Забить на DNS/TCP это смело, учитывая лимит в 512 байт... На спичках экономят?
К сожалению, большинство OpenSource-проектов развивается по генетическому алгоритму. Удачные варианты форкаются и модифицируются, в ходе естественного отбора обретают популярность наиболее конкурентоспособные модификации, после чего они в свою очередь форкаются и модифицируются.
К сожалению, даже на примере эволюции живых существ мы видим, что генетический алгоритм почти никогда не приводит к оптимальному решению - только к более-менее рабочему. А под капотом там всё, что только может быть сделано через задницу, именно через неё и будет сделано. Бывает, смотришь - и удивляешься: что за инопланетяне вообще писали этот код? Даже сумасшедший не может быть настолько чокнутым, чтоб выдавать такое.
А разгадка именно в том, что код эволюционировал вышеуказанным способом.
Вообще-то нет. Вы кидаете ссылку на википедию, после чего натягиваете сову на глобус (опенсорс не то, чтобы переживает естественный отбор, не менее важен маркетинг, иначе про идеальную либу просто никто не узнает). После чего утверждаете, что этот алгоритм приводит только к более-менее рабочему (решению). Что категорически не верно!
Во-первых, генетический алгоритм - это модель (!) эврестического алгоритма, который состоит в последовательном применении функций скрещивания, мутаций и отбора. Без уточнения этих функций почти любые разговоры об этой технологии бесполезны.
Во-вторых, подобные алгоритмы - это поиск субоптимальных решений. То есть не "кое-как работает", не "более-менее", а - локально-оптимальное решение в данных условиях. И даже не примере эволюции живых существ, мы видим, что естественный отбор (! - не генетический алгоритм) приводит к поразительно оптимальным результатам, что многие задумываются о творце. Но не всегда, конечно, эти результаты являются самыми оптимальными глобально.
Наконец, говнокодинг - это не только про "эволюцию". Но и просто про плохие решения. Мы все разные люди с разными принципами и разными способностями. Для кого-то нормально будет наворотить "говнеца", лишь бы у себя работало, а потом запилить PR, ради квадратиков в гитхабе. Тогда как для другого намного важнее будет вылизать решение, покрыть тестами и... Вобще не мержить в апстрим, потому что нефиг выслушивать почему (любая технология) это плохо и надо использовать (любую другую технологию).
К сожалению, большинство используют опенсорс, но при этом не читают дисклеймер: используйте как хотите, претензии пишите в спортлото. Нет, вам ничего не должны, нет вы ничего не должны. Как сказал бы класик, "такие же люди, только денежный вопрос испортил их", поэтому многие почему-то смотрят на подобные решения как на бесплатный сыр, но забывают, что такого не бывает. Либо вместо ваших денег разработчики получают вас самих с потрохами (хром), либо разработчики дико халтурят и получается УГ (дофига чего), либо стоимость использования софта выше, чем покупка (на подписки, на специалистов, etc), либо где-то ещё спрятан трейд-офф какой.
Плохо. Очень плохо.
glibc - этот ?
Адрес точнее - этот: https://sourceware.org/glibc/
glibc-2.17 - это Debian 9 Stretch, Ubuntu 18.04.6 LTS (Bionic Beaver), Astra Linux CE, CentOS 7, Oracle Linux 7
А какой дистриб Вы используете?
Зачем собирать chromium?
Хорошая статья. Там про firefox в systemd-nspawn, но ничего не мешает запуску chromium по аналогии.
https://wiki.debian.org/nspawn
Я работал с версией 2.27, не 2.17.
Сборку делал на машине Fedora-28 (всё стандартное).
Хромиум мне потенциально нужен для использования в своём проекте
Насчёт systemd-nspawn, не уверен, что есть в федоре. Хотя вот есть некий systemd-container.
Пока что я запустился в чруте с федора-33, не знаю, насколько это будет стабильно для хрома.
Да и в самой 28-й системе вроде можно теперь запустить, если убрать причину сбоя - удалить libqt5_shim.so.
Извините, очипятался с glibc-2.17
Пакет systemd-container с systemd-nspawn на всех дистрибах https://pkgs.org/search/?q=systemd-container
https://docs.fedoraproject.org/en-US/fedora-server/containerization/systemd-nspawn-setup/
https://fedoramagazine.org/container-technologies-fedora-systemd-nspawn/
Возможно, имеет смысл собрать docker image или в podman и buldah https://docs.fedoraproject.org/en-US/iot/build-docker/
https://docs.fedoraproject.org/en-US/iot/buildah/
Жаль, что нет Docker Official Image chromium
https://hub.docker.com/search?q=chromium&operating_system=linux
Тут есть нюансы.
Мне нужен именно свой хром, буду его ковырять. Хотя неофициальные образы тоже есть
Мне на период разработки всё-таки желательно с графикой чтоб было
Да, с Branch:f28 печально
https://src.fedoraproject.org/rpms/chromium/tree/f28
Зачем вам дистрибутив Fedora, срок поддержки версии которого обеспечивается ровно год, в версии 28, которая вышла в 2018 и снята с поддержки в 2019? Сейчас актуальная 39 версия.
Исторически так сложилось, что я обитаю на федоре, и меня вполне устраивает за некоторыми исключениями. Для разработки до последнего времени также подходила, даже без регулярных апгрейдов.
Да, тут есть конфликт необходимости новшеств для разработки и стабильности для обычной домашней системы. До сих пор это удавалось как-то решать с помощью виртуалок.
Насчёт systemd-nspawn, не уверен, что есть в федоре
Автор systemd работает работал в редхат, разумеется все системдшные штуки есть и работают в федоре. Лично мне не понравилось как nspawn работает, я словил кучу странного поведения с сопуствующим bind mount и навелосипедил свою обвязку для чрута (мне хочется на древней федоре пускать свежайший телеграм). Но вероятно я просто не умею готовить nspawn.
А тут, между прочим, ещё один пример последствий отсутсвия проверок
но он используется без проверки, да ещё в цикле.
для перфоманса может и не нужно проверять в цикле?
Но предварительно указатель на массив можно проверить на ноль ведь? Там кстати есть проверка на ноль уже в теле, но поскольку элемент не первый, то указатель уже не ноль. Смешно.
хорошим подспорьем был бы атрибут nullable для переменных, и проверка на этапе компиляции.
Хорошим подспорьем был бы язык без null-ов вообще, вроде Раста.
In 2009, Tony Hoare stated that he invented the null reference in 1965 as part of the ALGOL W language. In that 2009 reference Hoare describes his invention as a "billion-dollar mistake".
частично согласен с вами, предполагаю что подобные кейсы будут основываться на монадах или подобном. Но тогда все равно добавится один лишний бранч, условие для дальнейшего выполнения кода, если есть обьект или если нет обьекта.
Я же имел ввиду проверку на этапе компиляции, и если есть вероятность что обьект может отсутствовать, то проверку и бранчевание сделать один раз, например при получении обьекта. А все дальнейшие обработки производить с гарантией что обьект обязательно существует.
Ну так в чем тут новость? Общеизвестно, что второе имя Линукса - это словосочетание "DLL Hell". Проблема эта существовала всегда, в этом нет ничего нового. Проблема только усугубилась после того, как статическая линковка с glibc стала deprecated.
Когда-то давно еще трепыхалась надежда, что проблему "DLL Hell" в Линуксе как-то удастся решить. Но в какой-то момент стало ясно, что в рамках линуксового подхода проблема неразрешима. С этого момента все усилия линуксовой коммьюнити были швырнуты на рекрутинг орд малолетних трололо на реддите, задачей которых было заорывание темы на публичных ресурсах, а частности, распространение бредней, которые вы все, я уверен, слышали: что, мол, "DLL Hell" - это, якобы, проблема Windows.
Этот момент и стал последним гвоздем в гроб Линукса.
Но в какой-то момент стало ясно, что в рамках линуксового подхода проблема неразрешима
source-based дистрибутивы не имеют таких проблем.
Ха, скажите это buildroot.
Недавно с коллегой повеселились из-за того, что наше ПО собиралось, но в рантайме требовало версию одной библиотеки, сильно отличную от того, что попадало в target file system
Когда я последний раз пользовался только FreeBSD (лет ...дцать назад), их ports (при наличии мэнтейнеров, конечно) выгодно отличался от всего, что было в linux - и от rpm, и от gentoo: простота пересборки отдельных пакетов, независимость от конкретных версий сборки, простота правки параметров сборки, большая репа собранных пакетов...
Опять же, своя очень добротная libc, но зависимость современного софта от gnu-измов, конечно, омрачала...
Очевидно это ошибка в buildroot или в вашей конфигурации, но не системная проблема. Я ж тоже могу любой бинарик слинковать с одной версией библиотеки, а в LD_PATH другую положить.
Так значит source-based дистрибутивы всё таки подвержены такой проблеме?
Всё держится исключительно на надежде, что ни кто не допустит ошибок
Этому подвержена любая операционная система, у которой файловая система доступна на запись. Ведь я своими кривыми ручонками могу делать в ней что угодно.
Вопрос лишь в том, может ли пакетный менеджер вас защитить от этого.
Так значит source-based дистрибутивы всё таки подвержены такой проблеме?
/dev/hands
Для того, чтобы слинковать софтину с libfoo.1.0, а положить в архив libfoo_2.0 - нужно чтобы эти 2 либы существовали одновременно, для начала. clean build штоли.
В том и прикол был. У нас проект на cmake. Либа цепляется через FetchContent, всё настроено так, чтобы была статическая линковка. А в итоге пытается на старте подгрузить несуществующую версию.
Это я про что. Если дистрибутив source-based - это вообще ничего не значит. C++ проекты можно собирать десятком разных способов и нужно надеяться не только на то, что мэйнтейнер правильно сборку описал, но и что в скриптах сборки самого проекта всё хорошо
Недавно с коллегой повеселились из-за того, что наше ПО собиралось, но в рантайме требовало версию одной библиотеки, сильно отличную от того, что попадало в target file system
buildroot нужно уметь готовить.
Этот момент и стал последним гвоздем в гроб Линукса.
Вендекапец всЁ, в тренде линукскапец?
Если всё ставить из официальных реп, никакой "DLL Hell" действительно не существует. Проблемы начинаются со сторонним софтом, который тянет свои версии библиотек, чаще всего это собственнический софт и потому разработчиков свободных дистрибутивов эти проблемы не заботят.
Тем не менее, нашлись люди, которые озаботились этой проблемой и слепили решение и даже не одно. Называется flatpak, snap, appimage... Так что даже для любителей тягать за собой свои версии библиотек проблема "DLL Hell" решена.
Не ставьте бинарные пакеты.
Сарказм: Э-м-м, предлагаете ставить десятичные пакеты? Или сразу шестнадцатеричные?
Только давайте не трогать исходники, ладно? Там головная боль (и тормоза) будут постоянными союзниками.
configure --prefix=xxx; make; make install уже сложно сделать? Сочуствую...
а потом разбирать портянки fail error warning... libblabla.h not found...гуглить что надо собрать libblabla или установить libblabla-dev...офигеть то оно требует ядро 2.8 и вообще depricated 15 лет назад....ну ну, очень просто и для простых смертных
Ну а ты как хотел? Или ты тащишь сорцы и строишь, или надеешься что backward compatibility твоих бинарных пакетов будет ОК.
Ладно, давай так - в конкретно заданном дистре бинарники уже проверены на совместимость майтенерами и нет необходимости делать эту работу дважды. Тогда моя фраза будет звучать так: Не ставьте бинарные пакеты не из своего дистра.
Если всё ставить из официальных реп, никакой "DLL Hell" действительно не существует.
ну для начала "DLL Hell" это исключительно виндовая проблема, и существует она только потому что такие простые вещи как FHS слишком сложны для некрософта (на эту тему есть забавная шутка, к сожалению я не смог сейчас её найти, но суть там в том что основной критерий найма в майкрософт - неумение читать, ибо если бы сотрудники оного умели читать они бы прочитали fhs и сделали нечто подобное).
Проблемы начинаются со сторонним софтом, который тянет свои версии библиотек
ну как бэ нет, сторонний софт который тянет свои версии либ обычно и складывает их где нибудь у себя в /opt/стороннийсофт/ проблемы тут не в стороннем софте а в том что иногда находятся очень криворукие недоинженеры которые очень криво этот софт пакуют забывая указать зависимости, забывая их положить в пакет, забывая про них в целом (да и статическую линковку никто не отменял).
Тем не менее, нашлись люди, которые озаботились этой проблемой и слепили решение и даже не одно. Называется flatpak, snap, appimage...
это не решение проблемы а создание новой. вообще в целом когда в системе появляется второй способ поставки ПО это неправильно и фуфуфу.
Но ведь и в windows больше одного способа установки: msi, exe, appx, store, winget...
Если посмотреть только на первые два: msi является приоритетным способом, а exe вообще лишь программа "для копирования" другой программы
Но ведь и в windows больше одного способа установки
ну так windows и является одним большим примером КАК ДЕЛАТЬ НЕ НАДО. там в целом одни недостатки, все приписываемые винде преимущества это 99% софт сторонних разработчиков, иногда это софт самих мелкомягких но не имеющий отношения к самой винде..
Для начала стоит сказать что винда это пример того что такое поддержка Легаси кода. Все стандарты начиная чуть ли не с 95 шинды - поддерживаются. Даже СОМ ещё как-то можно запустить, лол.
А все эти разные версии установки ПО идут напрямую из таймлайна. В начали были бинари, потом установочные пакеты, потом контейнеры. Остальное лишь способы доставки, стор/винджет.
Но после винды начинаешь дико орать с того, что ты не можешь просто так установить и запустить какой-то софт. Ибо в твоей системе есть appimage но нет flatpak, а как софтину поставить тогда? И это сюр, что разрабам надо залить свой софт в кучу репозиториев, а потом собрать их под кучу разных бинарей. Совсем не юзер френдли.
это не решение проблемы а создание новой
Честно говоря, не понимаю в чем проблема с flatpak кроме того, что они занимают чуть больше места на диске.
когда в системе появляется второй способ поставки ПО это неправильно и фуфуфу.
А как без второго способа? Вы предлагаете отказаться от репозиториев и оставить единственным способом установки сборку из исходников? Так с ней в большинстве случаев еще "веселее".
ну как бэ нет, сторонний софт который тянет свои версии либ обычно и складывает их где нибудь у себя в
/opt/стороннийсофт/
Бывает по-разному. Например известный https://www.deb-multimedia.org/ просто апгрейдит системные библиотеки. Что работает прекрасно, но только до тех пор, пока не отключишь эту репу, что полностью ломает систему. Кто-то складывает свои версии библиотек в /us/local/lib, что делает их доступными глобально (или в /opt и прописывает в ld.config - тот же эффект), что тоже работает, но только до тех пор пока библиотека с тем же именем, но с другой версией не ставится где-то ещё. Это, кстати, похоже случай нашего автора. В общем случае корректного и удобного решения этой проблемы на уровне отдельного пользователя/разработчика действительно нет, кроме как раз вышеупомянутого flatpak, snap, appimage, NixOS и Guix.
это не решение проблемы а создание новой. вообще в целом когда в системе появляется второй способ поставки ПО это неправильно и фуфуфу.
А что делать, если разработчики мейнстимовых дистров, типа Дебиана просто игнорируют эту проблему? По крайней мере появилась возможность кое-как эту проблему решить. Я согласен, что это не оптимальный способ. Лучше бы сам Дебиан предоставил механизм для решения этой проблемы, как это делают NixOS и Guix.
В моём случае Хром собрал две обвязки для Qt5 и Qt6 (упомянутая out/default/libqt5_shim.so и libqt6_shim.so) с использованием локально поставленного в каталог исходников корня системы Дебиан, указав при сборке путь до этого корня (--sysroot=../../build/linux/debian_bullseye_amd64-sysroot). Т.е. сборка именно libqt*_shim.so была выполнена относительно выкачанной дебиановской системы.
При этом основная сборка вроде всё-таки на системные либы полагалась, там где не собирала своё (а в хроме своих локальных версий много).
но только до тех пор, пока не отключишь эту репу, что полностью ломает систему.
простите но если вы отключаете используемую в системе репу вы ссзб. перейдите на пакеты из родной репы и отключайте себе наздоровье
Кто-то складывает свои версии библиотек в /us/local/lib, что делает их доступными глобально (или в /opt и прописывает в ld.config - тот же эффект), что тоже работает, но только до тех пор пока библиотека с тем же именем, но с другой версией не ставится где-то ещё
вот это вот всё решается простым "ЧИТАЙ СТАНДАРТЫ ГАДИНА" в мегафон в ухо поставщику софта
В общем случае корректного и удобного решения этой проблемы на уровне отдельного пользователя/разработчика действительно нет
нормальная сборка по стандартам решает все эти проблемы. если ваша софтина использует какую либо либу которой нету в дистре опакетьте её в отдельный пакет. если ваша софтина требует либу альфа версии которую ещё рано пихать в дистр - выпейте святой воды и больше так не делайте. читайте fhs, думайте головой а не жопой, и всё будет нормально.
кроме как раз вышеупомянутого flatpak, snap, appimage, NixOS и Guix.
это не решение проблемы а подстановка костылей которые как мы знаем на опыте рано или поздно выливаются в новые проблемы. вместо того чтобы клепать 100500 сторонних пакетников с разными несовместимыми форматами и не пригодными в качестве одного единственного
Лучше бы сам Дебиан предоставил механизм для решения этой проблемы
не обязательно сам debian, от opensuse есть obs который можно использовать для сборки как под дебиан так и под рач, центось и кучу всего (включая эти ваши флаткаки).
у меня слили карму (не стоило указывать лжецу на его враньё) так что дальше пойдут ответы на другие комменты
В пользу кого? У Davinchi Resolve есть настоящие конкуренты на Linux? Не Kdenlive же, в самом деле :)
это как раз самое тупое, ибо не в пользу кого-то а просто в воздух, "так не доставайся же ты никому" ©
Из реальных его недостатков, как правило называют только вес, что в
эпоху доступных терабайтных дисков, и дистрибутивов весящих 5+ Гб, на
мой взгляд более чем приемлемая плата за "просто установил, и работает",
и не падает после обновлений.
ну для начала вес не самая большая проблема, основная проблема в том что это ВТОРОЙ способ поставки по а не основной, в том что дублирующийся рантайм увеличивает время запуска, потребление озу и проца, ломает связность с другим ПО. и "установил и работает" это было бы весомым аргументом если бы это было так, флатпаки тоже имеют свойство просто не запускаться по непонятным причинам и сегфолтится в процессе работы, и на моём опыте гораздо чаще чем по из родных системе реп.
А как ментейнеры решают проблему? Кто занимается тестированием софта с обновленной версии библиотеки?
тут короткого ответа не будет, есть множество подходов и разные мейнтейнеры используют по нескольку разных подходов, например у suse есть openqa, есть тестовые репы для всех желающих, есть ручное тестирование..
вот это вот всё решается простым "ЧИТАЙ СТАНДАРТЫ ГАДИНА" в мегафон в ухо поставщику софта
в корпоративной среде это не работает
если вы рядовой админ, можете на себя покричать для развлечения (что вы с этим разбираетесь) и посетовать на то что мир несовершенен
чем более серьезный софт, тем более там заковыристые тараканы такого рода
вы никогда не сталкивались с фразой вендора? "наш софт в рекомендованной конфигурации работает, то что вы там делаете ваши проблемы, мы ничего решать не будем" и как опция "в %клиент_name_размером_с_гугл% таких проблем нет, мы ради вас ничего чинить не станем"
в корпоративной среде это не работает
давайте не будем путать "не работает" и "не может работать". то что большинство вендоров ПО совершает кучу глупостей по причине того что "так исторически сложилось" не аргумент чтобы продолжать так же. они это делают с молчаливого согласия юзверей.
вы никогда не сталкивались с фразой вендора? "наш софт в рекомендованной конфигурации работает, то что вы там делаете ваши проблемы, мы ничего решать не будем" и как опция "в %клиент_name_размером_с_гугл% таких проблем нет, мы ради вас ничего чинить не станем"
сталкивался, и имел опыт пусть непростого и долгого, но успешного убеждения вендора исправить тот или инной косяк который по первоначальному мнению вендора был совсем не косяком а нормальным поведением. конечно такую глобальную вешь как способ поставки ПО в одно лицо не решить.. но это возможно!
Не аргумент да, но когда, допустим банк, покупает программный комплекс за 1млн рублей за рабочее место и по 300тыс за процессор на сервере, никто уже не задает вопрос о том какие пакеты и зависимости нужны при установке этого всего, и мнение админов тут совсем самое крайнее. а бизнесу интересны бизнес-функции комплекса, а не то какую версию линукса он требует... понимаете, технические подробности вообще никого не интересуют, также как вас не интересует как организовано маслоснабжение двигателя вашего авто...это проблема отдела СТО в автосфере или ИТ в случае программных продуктов... можно пожаловаться, но продукт выполняет бизнес функцию? выполняет, отлично выполняет? отлично. все ок, закрываем вопрос, никто не будет тратить деньги на аналитиков чтобы в требованиях выписывать соответствие стандартом линукса потому что васян админ страдает
И чтобы тут не тыкать в банки, я могу вам сказать что это Oracle DB например такой продукт..мне довелось костыли в него забивать в свое время потому что он железно требовал определенную версию ядра и всяких рядом стоящих либ, а аудиторы по ИБ мне запрещали их использовать...а самое гдавное что оракл что поставщики продукта в рамках которого оракл работал...тупо принесли мне бумажку от ИБ где было написано что он соответствует стандартам, печать подпись ...PwC, KPMG... все.. бизнес свое дело сделал...ты можешь лично вендору жаловаться хах ;))
и мнение админов тут совсем самое крайнее
мне искренне жаль вас если вы работали там где так, я из такого места сбежал через неделю
также как вас не интересует как организовано маслоснабжение двигателя вашего авто
ну не надо обобщать, меня очень интересует, более того есть даже планы по доработкам (правда не в маслоснабжении)
можно пожаловаться, но продукт выполняет бизнес функцию? выполняет, отлично выполняет? отлично. все ок, закрываем вопрос, никто не будет тратить деньги на аналитиков чтобы в требованиях выписывать соответствие стандартом линукса потому что васян админ страдает
то что в основном так и происходит не означает что это правильно, как итог мы получаем плохо работающие продукты и дико переусложнённые пайплайны и ещё большие затраты бизнеса чем на аналитику
ты можешь лично вендору жаловаться хах
не можешь а должен, если бы большинство админов, инженеров, разработчиков и проч не ленились пожаловаться вендору то кол-во сообщений о проблемах в ТП вендора бы перевалило за отметку "да всем насрать" к отметке "этим надо заняться". каждый второй говорит что сообщения от одиночек игнорируются, нужно чтобы бизнес от своего имени жаловался, но это не совсем так, сообщение от одиночКИ игнорируется, а если таких сообщений от одиночЕК много то игнора не будет.
мне искренне жаль вас если вы работали там где так, я из такого места сбежал через неделю
мне нравится работать в крупных компаниях, с огромными сервисами, серверными кластерами и т.п. и цена такого - это проблемы которые я описываю и они стоят того, мне интересны сервисы целиком, а не то как они написаны (хотя я поскорбить могу по этому поводу)
ну не надо обобщать, меня очень интересует, более того есть даже планы по доработкам (правда не в маслоснабжении)
ну в данном случае вы скорее исключение, я отъездив суммарно 16 лет на бу автомобилях где надо было чето дорабатывать и улучшать, хочу сейчас просто ездить ;))
то что в основном так и происходит не означает что это правильно, как
итог мы получаем плохо работающие продукты и дико переусложнённые
пайплайны и ещё большие затраты бизнеса чем на аналитику
боюсь тут уже рынок решает за нас, мне не нравится как и куда двигается отрасль, но она двигается именно так как хотят гиганты, а не мелкие компании
Я пробовал терроризировать некоторых вендоров по поводу ИБ например (захардкоженный логин-пароль админский в софтине управления банкоматами)...и им...им плевать собственно ;))
не можешь а должен, если бы большинство админов, инженеров,
разработчиков и проч не ленились пожаловаться вендору то кол-во
сообщений о проблемах в ТП вендора бы перевалило за отметку "да всем
насрать" к отметке "этим надо заняться".
вы правы, я согласен, но всем собственно плевать по большей части, админам плевать. а сейчас я даже время тратить не будут на сражение с мельницами если вопрос идет о подобных продуктах и если моя компания не имеет ценности в лице вендора
я уже сталкивался с тем что вендор тупо бросал трубку услышав номер контракта поддержки со словами "у вас всего 2 часа консультаций в месяц, вы платите по полтора ляма в месяц всего, звоните только если чтото экстренное, а баги шлите в /dev/null у нас приоритет только для крупных клиентов"
я отъездив суммарно 16 лет на бу автомобилях где надо было чето дорабатывать и улучшать, хочу сейчас просто ездить
от части я понимаю, у меня были авто в которых приходилось чаще ковыряться чем ездить, но пересев на новый хороший автомобиль у меня желание допилинга никуда не пропало..
Я пробовал терроризировать некоторых вендоров по поводу ИБ например и им...им плевать собственно
1) это потому что таких терроризирующих было недостаточно
2) это не повод останавливаться (тем более в банках)
но всем собственно плевать по большей части
разве это достаточный повод чтобы и самому скатится до такого же уровня?
я уже сталкивался с тем что вендор тупо бросал трубку услышав номер контракта поддержки со словами
если правильно донести суть проблемы до руководства то или будет куплена поддержка на большее кол-во часов или в суде вылюблен вендор хорошим адвокатом который расскажет вендору что если тот не пытался ничего сделать то это не считается за истраченное время работы поддержки
Не аргумент да, но когда, допустим банк, покупает программный комплекс за 1млн рублей за рабочее место и по 300тыс за процессор на сервере, никто уже не задает вопрос о том какие пакеты и зависимости нужны при установке этого всего, и мнение админов тут совсем самое крайнее.
Это пока банк не нагнут хакеры, которые взломают этот комплекс с его устаревшими либами. Тогда головы этих молчаливых админов первыми и полетят
не полетят, там ведутся обязательные списки уязвимостей, планы по обновлению софта (например переход на новую версию софтины в течении 2х лет) и мероприятия по огораживанию затронутых сервисов
Славабогу в отрасли всетаки ввели несколько обязательных стандартов ИБ..хотя могу я вам сказать что людей которым реально плевать и они их саботируют там полно...
Судя по количеству утечек данных никто ничего не ведёт и вести не собирается
утечки там скорее не технические через уязвимости, а через людей
вот положа руку на сердце, слить себе базу на флешку и утащить домой, никогда проблемой для админа не было, чо бы там ИБшники про себя не думали со своими заклинаниями что у них все под контролем
у нас тестовые контуры были например клонами продакшн серверов гдето с месячным отставанием, при том что по регламенту оно должно быть обезличено...и даже скриптик был который обезличивает, но всем лень было его запускать...и долго оно это всё отрабатывает
p.s. дело было больше 10 лет назад и банка и конторы где это было давно нет, но я более чем уверен что ничего не поменялось концептуально..лет 6 назад я частично с отраслью пересекался и был удивлен что у нас там еще все очень неплохо было
нормальная сборка по стандартам решает все эти проблемы
Нет. Все не решает. Какие-то проблемы можно решить, часто не очевидным и странным способом, но в целом есть масса вообще нерешённых проблем, даже при использовании официальных реп.
Например, допустим я хочу банально поставить две версии библиотеки из официальной репы, но к примеру, одну из текущей версии Дебиана, а другую из предыдущей версии. Или, что почти тоже самое, я хочу поставить версию приложения из официальной репы, но из предыдущей версии Дебиана (естественно с зависимостями). И это просто банальный рядовой случай.
две версии библиотеки из официальной репы, но к примеру, одну из текущей версии Дебиана, а другую из предыдущей версии.
Странное пожелание. Зачем это может пригодиться? И как указывать приложениям, где какую библиотеку искать?
Запилить то можно. но как потом управлять этим?
Ничего странного нет. Если в старой версии всё работало, а в новой возникли проблемы, то желание поставить старую версию, хотя бы чтобы провести какие-то тесты вполне естественно.
Либо если в новой версии поменяли интерфейс, а все зависимости что с ними связаны ещё не успели переделать.
Да мало ли случаев бывает...
Разруливать dependency hell методом тыка так себе идея.
Если у вас ровно одна либа и ровно одно приложение - это разумно. если 100500 приложений требуют эту либу - как вы убедитесь, что глобальная замена версии не сломала ничего в 100499 приложениях? Если учить каждое приложение отдельно работать с указанной либой - это нужно придумывать очень хитрый загрузчик. Не то чтобы это выглядело невозможным.. Но appimage проще ;)
В том и дело что нынешний подход в мейнстримных дистрибутивах ГНУ/Линукс предусматривает лишь глобальную замену. Более того, разработчики этих дистрибутивов десятилетиями игнорировали проблему. Да, к сожалению в мире свободного свободного ПО это вполне возможно.
Поэтому и появились хитрые альтернативы вроде flatpak, snap, appimage, guix, nixos, которые позволяют устанавливать несколько версий одновременно.
Причём две последних это полноценные дистрибутивы!
Конечно, лучше бы разработчики deb/apt,rpm озаботились и выкатили своё общее решение. Но пока так.
В том и дело что нынешний подход в мейнстримных дистрибутивах ГНУ/Линукс предусматривает лишь глобальную замену.
да в общем-то нет большой сложности это решить, есть только нежелание решать проблемы и желание втыкать костыли
Более того, разработчики этих дистрибутивов десятилетиями игнорировали проблему
проблема игнорировалась тогда когда не была проблемой, раньше релизы различных библиотек появлялись сильно реже, библиотек было сильно меньше, и было принято как неоспоримый факт что каждый новый релиз должен быть обратносовместим с предыдущим. в такой кухне необходимости держать несколько версий одной и той же либы просто не было
Конечно, лучше бы разработчики deb/apt,rpm озаботились и выкатили своё общее решение. Но пока так.
собственно идея такого решения существует давно, но реализацией никто не занимается, все слишком заняты втыканием новых костылей. и это самое "пока" будет растягиваться всё больше и больше с появлением новых костылей..
собственно идея такого решения существует давно, но реализацией никто не занимается, все слишком заняты втыканием новых костылей. и это самое "пока" будет растягиваться всё больше и больше с появлением новых костылей..
Когда пользователи массово начнут ставить приложения через всякие флэтпаки, то думаю разработчики мэинстримовых систем пакетирования зачешутся. Если они там ещё остались, конечно.
ибо не в пользу кого-то а просто в воздух
Я вас не понимаю, то есть людям был нужен продукт уровня Davinci Resolve и люди отказались от него из-за того, что его нельзя установить одной командой, и при этом не заменили его ни на что? Что-то я сомневаюсь, что такие люди ЦА Davinci, и что о них корректно говорить как о рынке.
проблема в том что это ВТОРОЙ способ поставки по
Так нам всегда нужен второй способ, потому что нам может понадобится не мэйнстримный софт, который никто и никогда не будет собирать под зоопарк дистрибутивов. Раньше это делалось методом ./configure && make && make install, сейчас такое частенько можно найти в виде готового flatpak/snap
Я вас не понимаю, то есть людям был нужен продукт уровня Davinci Resolve и люди отказались от него из-за того, что его нельзя установить одной командой, и при этом не заменили его ни на что? Что-то я сомневаюсь, что такие люди ЦА Davinci, и что о них корректно говорить как о рынке.
конечно не понимаете, ибо говорите не о том о чём тред а о чём-то своём. проблема не в установке одной командой а в том что после установки он то не работает, то работает но не может использовать gpu, то падает при вызове каких-то функций. и всё от того что поставляется он без списка зависимостей необходимых для работы хотя бы в текстовом виде, и сиди разбирайся чего ему там в очередной раз для работы не хватило, да не только после установки но и после обновлений его самого либо системы вокруг него.
Так нам всегда нужен второй способ, потому что нам может понадобится не мэйнстримный софт, который никто и никогда не будет собирать под зоопарк дистрибутивов. Раньше это делалось методом ./configure && make && make install, сейчас такое частенько можно найти в виде готового flatpak/snap
кому это "вам"? тем кто любит изобретать миллионную копию костыля? нужен не второй способ поставки по а причина использовать первый всем причастным
простите но если вы отключаете используемую в системе репу вы ссзб. перейдите на пакеты из родной репы и отключайте себе наздоровье
А такого механизма в Дебиане нет, о чём и речь.
А такого механизма в Дебиане нет, о чём и речь.
на дебиане в apt и apt-get нет вендоринга как например в zypper, это да, это печально. но ничто не мешает вам сделать это руками:
apt-cache policy <package name> - ищем нужную версию пакета из системной репыapt install <package name>=<version> - ставим нужную версию пакета
После вашего комментария NixOS и GuixSD очень нервно курят в сторонке. (в них dependency hell просто невозможен by design). Ну и флатпаки до кучи.
После вашего комментария NixOS и GuixSD очень нервно курят в сторонке. (в них dependency hell просто невозможен by design)
заменили dependency hell на filesystem hell
Ну и флатпаки до кучи.
оооо нет, там ещё тот ад зависимостей творится. ставишь ты себе какой нибудь простенький софт а-ля блокнот, а флаткака тебе "а давай я тебе притащу три терабайта рантайма, плевать что всё это у тебя уже есть в системе, а ещё давай притащу рантайм гейвидии, сразу три, для разных версий, и плевать что у тебя нет гейвидии". оч классное решение (нет). я уж молчу про оооочень медленный флатхаб, иногда быстрее пересечь океан и с флешкой прийти чем с него что-то выкачать. хуже флатпака только снап..
плевать что всё это у тебя уже есть в системе,
Сегодня есть, завтра нет. Обновил систему - у софтины отпала башня. Так лучше?
плевать что у тебя нет гейвидии
Сегодня нет, завтра есть. Иногда люди обновляют железо - это не повод чтобы у софтины при этом отваливалась гусеница ;)
Сегодня есть, завтра нет. Обновил систему - у софтины отпала башня. Так лучше?
вы испорчены масдем, в нормальных ОС чтобы такого не случалось существует пакетный менеджер отслеживающий зависимости. если по какой-то причине например мейнтейнеры в срочном порядке соберутся выпилить из системы какой нибудь libfoo то сборочница быстро сообщит им сколько пакетов от него зависят и как связаться с их мейнтейнерами чтобы порешать этот вопрос.
Сегодня нет, завтра есть. Иногда люди обновляют железо - это не повод чтобы у софтины при этом отваливалась гусеница ;)
ну да, мне на диске капец как нужно несколько гигов рантайма от хреновины которую я мооожет быть куплю лет через дцать когда этот рантайм уже будет не актуален.. умно(нет).
существует пакетный менеджер отслеживающий зависимости
Это если авторы сторонней софтины решили в него упороться. И они честно держат репозитории под 3 релиза debian, 3 релиза убунтов, для редхатоидов там свои забавы.. Разные архитектуры еще случаются.. Ничего не пропустил? ;)
если по какой-то причине например мейнтейнеры в срочном порядке соберутся выпилить из системы какой нибудь libfoo то сборочница быстро сообщит им сколько пакетов от него зависят
Это сторонняя софтина. Она не входит в дистрибутив, и никто, кроме ее авторов, не знает про ее зависимости.
несколько гигов рантайма
Правда штоли?
Это если авторы сторонней софтины решили в него упороться. И они честно держат репозитории под 3 релиза debian, 3 релиза убунтов, для редхатоидов там свои забавы.. Разные архитектуры еще случаются.. Ничего не пропустил? ;)
Это сторонняя софтина. Она не входит в дистрибутив, и никто, кроме ее авторов, не знает про ее зависимости.
ну смотрим на примерах:
1) vscode - заморочились с репами под deb и rpm, проблем с зависимостями нет, мейнтейнеры держат руку на пульсе. как итог миллионы установок и куча куча юзверей рекламирующих продукт друг другу
2) davinchi resolve - поленились сделать пакеты и репозитории, потеряли часть рынка, недополучают деньги
хмм, кому же хуже? даже не знаю.. не надо придумывать проблему там где её нет. это лет так 10 назад проблема стояла остро, сейчас это редкие отголоски которые встречаются сильно реже чем про них вспоминают и чаще всего в недрах корпоративного сегмента где юзверю вообще об этом думать не надо ибо это головная боль не его а админов (и да, флаткаки и снапы там тоже не вариант, их туда ИБ не пропустит).
и как связаться с их мейнтейнерами чтобы порешать этот вопрос.
Или не решить, и просто выкинуть пакет из репо.
Для вас есть gentoo.
А мне, например, пофиг на место на диске. Мне важно иметь возможность удалить программу после использования так, чтобы следов не осталось и в общем чтобы на систему не повлияло.
Каждому по требованиям или как оно там...
Чёт мне кажется вы причины и следствия местами поменяли
вам именно что кажется
Для вас есть gentoo.
так сказали буд-то это что-то плохое
А мне, например, пофиг на место на диске. Мне важно иметь возможность удалить программу после использования так, чтобы следов не осталось и в общем чтобы на систему не повлияло.
и с чего вдруг это идёт в разрез с пакетным менеджером который как бы для этого и создан? или вы из тех кто путает удаление софта и удаление конфигов софта? открою вам секрет это разные вещи и смешение их в одно действие как минимум неправильно.
Нет, гента не плохая. Я же написал, что под каждую задачу свой инструмент.
Я не путаю удаление софта и его конфигов. Софт не только конфиги может поражать.
Например логи и другие временные файлы. Мне охота, чтобы они были привязаны к софту и удалились с ним же.
Кстати про конфиги - файлы конфигов могут создаваться при запуске, а не установке. Тогда пакетный менеджер врятли о них узнает. Если я хочу переустановить софтину "с чистого листа", хорошо бы, чтобы и их удалило.
Ну и бонусом, тот же deb позволяет запускать скрипты при установке/удалении и этим скриптам позволено оооочень многое. Надо доверять тем, кто их писал
Например логи и другие временные файлы. Мне охота, чтобы они были привязаны к софту и удалились с ним же.
ну мы же все понимаем что "мне охото" это слабый аргумент. пакетный менеджер при удалении пакетов не трогает логи и конфиги не потому что "не знает" про них, это легкопоправимо. они не удаляются потому что так и задумано, гораздо больше пользы от оставшихся после удаления пакета логов чем от утерянных.
Кстати про конфиги - файлы конфигов могут создаваться при запуске, а не установке. Тогда пакетный менеджер врятли о них узнает. Если я хочу переустановить софтину "с чистого листа", хорошо бы, чтобы и их удалило.
я вам даже больше скажу, если мейнтейнер не наркоман то пакетник не удалит даже тот конфиг о котором знает, и это не ошибка, так и задумано.
Ну и бонусом, тот же deb позволяет запускать скрипты при установке/удалении и этим скриптам позволено оооочень многое. Надо доверять тем, кто их писал
это да, без доверия никуда. но никто не мешает вам проверить что там делают postinstall скрипты, да и проверяют их сильно больше человек чем вы один. конечно в каком нибудь арчевском AUR можно нарваться и на малварь, но в нормальных репозиториях нормального дистрибутива это крайне маловероятно. за годы практики я помню один случай когда случайно вставленный проблем в postun скрипте удалял всё от корня. и на эту проблему никто не попался потому что внимательные мейнтейнеры исправили ошибку невнимательного до попадания в репы, зато помню как при обновлении виндового яндекс диска он пытался удалить всё на диске C:/ и это попало в прод (емнип даже на хабре была статья об этом).
я не спорю что классический пакетный менеджер не идеальное решение, но самодостаточные аналоги всё равно хуже. они не решают никаких проблем
изоляция приложения - возьмите firejail, он будет пользоваться тем же функционалом неймспейсов что и фатпак
ограничение ресурсов - туда же
единый рантайм на всех ос - это надо решать не костылями а стандартизацией
недоверие к поставщику - ну камон, у снапа вообще серверная часть проприетарная и закрытая от глаз посторонних, с чего бы вдруг к нему больше доверия было?
ну и коронное: зато работает везде да вот нифига не везде, так сложилось что нет такого софта который был бы мне нужен но я не мог бы поставить его из репозиториев, кроме plex desktop (ну и plexamp до кучи), вот их я из флатпака и поставил (правда позже осознал что они не дружат с mpris в отличии от браузерной версии и отказался, но это уже другая история) и они благополучно не работали, от релиза к релизу ошибки менялись но работать оно не хотело, и только спустя пол года внезапно заработало (и то после удаления всего что мне наставил флатпак и повторной установки которая заняла почти пол часа потому что флатхаб это самый медленный поставщик на моей памяти). и я не помню таких проблем ни с одной софтиной из реп. конечно проблемы встречались, но пара сообщений в багзилле их исправляли.
То есть вы не помните то время, когда vscode можно было сказать только исходниками или только собранным deb пакетом?
я ещё помню времена когда невидия вообще под линуксом не работала, тут на хабре есть люди помнящие времена когда пакетных менеджеров не было, когда msi не существовало.. не надо смотреть так далеко в прошлое, ошибки для того и существуют чтобы их исправлять.
единый рантайм на всех ос - это надо решать не костылями а стандартизацией
Это невозможно, особенно, когда речь идет о свободном ПО. Всегда найдется какой-нибудь идеологический противник стандартного рантайма, который будет против него, так же как вы против flatpak.
Это невозможно
ну нет, нет ничего невозможного тут, просто очень сложно
Всегда найдется какой-нибудь идеологический противник стандартного рантайма
и пусть, пусть живёт отдельным дистром. стандарт всё равно нужен, пусть будет основой для построения мейнстримных дистрибутивов, а особоспецифичные запрещать я и не предлагаю
так же как вы против flatpak
я совсем не против флатпака в целом, я против его использования там где он не нужен. это отличный инструмент показать mvp заказчику, это отличный способ выяснить "а вззлетит ли" ваш продукт не собирая его под всё подрят.. у него есть своя сфера применения, просто его пихают сейчас везде подрят.
ну нет, нет ничего невозможного тут, просто очень сложно
Теоретически конечно возможно, на практике же Linux сообщество вообще мало о чем договорилось за почти 30 лет существования, даже о пакетном менеджере не договорились, чтобы несколько раз приложения не перепаковывать, что уж говорить о рантайме.
я против его использования там где он не нужен
Нужен/не нужен это философия. Из реальных его недостатков, как правило называют только вес, что в эпоху доступных терабайтных дисков, и дистрибутивов весящих 5+ Гб, на мой взгляд более чем приемлемая плата за "просто установил, и работает", и не падает после обновлений.
вам именно что кажется
То есть вы не помните то время, когда vscode можно было сказать только исходниками или только собранным deb пакетом?
плевать что всё это у тебя уже есть в системе
find /usr/lib -name libEGL.so
/usr/lib/slack/libEGL.so
/usr/lib/x86_64-linux-gnu/libEGL.so
find /usr/share/ -name libEGL.so
/usr/share/skypeforlinux/libEGL.so
/usr/share/discord/libEGL.so
/usr/share/discord/swiftshader/libEGL.so
/usr/share/code/libEGL.so
/usr/share/gitkraken/libEGL.so
/usr/share/gitkraken/swiftshader/libEGL.so
Ну да, ну да.. ;) Каждый притащил свою копию. Ну и ладно.
из любого правила есть исключения, тут специфика электроноговна (там проблем сильно больше чем таскание своего рантайма каждой софтиной) да и тут скорее криворукость мейнтейнеров которая является человеческим фактором от которого не спасёшься переехдом на флаткаку или снап или что-там ещё придумают через пол года.
впрочем бывает и так:
[werwolf@workbook] ~
❯ find /usr -name libEGL.so
/usr/lib64/libEGL.so
Ну да, ну да.. ;) Каждый притащил свою копию. Ну и ладно
Не знаю что у вас за дистр, но на моем арче с ~2000 пакетами ситуация такая
$ sudo find /usr -name libEGL.so
/usr/lib32/libEGL.so
/usr/lib/libEGL.so
иногда быстрее пересечь океан и с флешкой прийти чем с него что-то выкачать
Я как бы не знаю что вам сказать, вы близки к истине...
Никакой проблемы с DLL hell в линуксе нет. Собирайте софт в том же дистрибе, в котором он будет запускаться и живите счастливо. Либо распространяйте свою софтину вместе с библиотеками и игнорируйте стандартный путь их расположения. Либо вообще статическая сборка ибо зачем нужны разделяемые библиотеки, если их юзает только одно приложение - не понятно
Кстати, по поводу альтернатив Хабр тут вовремя предложил статью-сравнение мюсли и гну
https://habr.com/ru/articles/520920/
Насчет качества кода не скажу (хотя есть сомнения в качестве той же libstdc++, потому что я ставлю читаемость кода как одно из основых его хороших качеств), но насчет проверок..
Тут все дело в производительности и отделении, так называемой, core части либы и приложения от прослойки, которая взаимодействует с внешним миром и валидирует/парсит входные данные для последующей передачи в core.
Другой вопрос в том, что в C типизация не очень сильно развита, чтобы так обращаться с данными (хотя возможно тут дело просто в сложившихся практиках разработки).
Я вот не знаю почему в Си особо не используют абстракции вроде option, either/maybe или тех же smart ptrs.
Для smart ptr нужны деструкторы. Их нет в стандарте.
Для option/either/maybe нужны дженерики. Си может предложить только макросы (_Generic в Си это не те дженерики, которые вы ищите), которые вовсе не факт, что добавят читаемости и отлаживаемости коду.
Да, с монадами я позабыл про дженерики. Хотя наверно есть всякие велосипеды.
А вот умные указатели имеют пользу не только для устранения утечек памяти, но я для гарантии, что указатель в них валидный. Конечно в Си мало что можно гарантировать в
самом интерфесе функций, но когда видишь
size_t strlen(not_null_ptr str)то это говорит само за себя в отличии от
size_t strlen(char* str)Возможно я не вижу здесь какой-то очевидной проблемы с производительность)
Я думаю делать такие маленькие и говорящие структурки это удобно и читаемо.
Есть интересный ролик о чем-то схожем.
Что в not_null_ptr лежит? void*? char*?
Вот здесь возникает проблема из-за отсутствия дженериков. Либо придётся сводить всё к void* (что теряет другую, не менее важную информацию о типе - чтобы не отправить нечаянно в strlen int*), либо для каждого типа делать парный not null тип руками.
На самом деле я бы здесь вообще создавал свою строчку, у которой не будет проблем с NULL указателями.
Но это наверно не путь для стандартной либы)
Если кто-то вдруг сделает libc, в котором, например, станет возможно передавать nullptr в str* - нужно заодно переписать все API (strlen(null) - что должна вернуть? 0? -1 (нельзя, это же size_t)). И код, работающий с новым API, будет полностью несовместим со старым. Та еще бомба получится.
Я имею ввиду структурку с char*, size, capacity, внутри, которая передается по значению.
Короче обычная оопшная строка
насчет стандратной либы итак сказал
(strlen(null) - что должна вернуть? 0
почему по вашему нельзя 0 вернуть при NULL?
strlen не отвечает же на вопрос существования строки, а только ее длины. И если строки нет, то и длина получается ноль.
И если строки нет, то и длина получается ноль.
Можно и так ;) Но функций str* много, и от nullptr они падают (strlen - падает). Если вдруг внутри этих функций появится код с дополнительными проверками - существующие программы этого не заметят, в них уже есть эти проверки. А новым программам придется учитывать, что функции из libc работают иначе, и наворачивать проверки после вызова функций.
Для smart ptr нужны деструкторы. Их нет в стандарте
Деструкторы, которые вы имеете в виду, нужны для RAII.
Для умных указателей формально они не нужны. FFmpeg полон использования shared ptr для управления ресурсами, GLib предоставляет функциональность shared/weak ptr и наверняка ещё куча, если не большинство сложных проектов на C так или иначе приходят к использованию подсчёта ссылок с финализацией объекта.
Для option/either/maybe нужны дженерики. Си может предложить только макросы
В виде какой-нибудь стандартной библиотеки реализовать их и вышеупомянутые умные указатели непросто.
Но в пределах одного проекта вполне возможно. Конкретизируя каждый тип и/или необходимые для него методы (av_frame_ref, ns_optional_type1, ns_either_type2_type3 и т. д.) либо вручную, либо при помощи макроса.
В том то и дело, что если ограничиться проверкой только входных данных, то внутреннее состояние не контролируется. Это работает, если либа идеальна и без ошибок. Но такого не бывает. Так хоть бы определяли ошибки на более раннем этапе. Я ведь так и не выяснил, где же был баг в загрузчике. Удовлетворился пока тем, что в версии 2.32 работает (но это не точно, вернее не точно, что всегда).
интересно, как тогда с этим бороться?
Насколько я понимаю, в таком случае система должна оставаться в рабочем состоянии, но может быть в неправильном. На простом примере - получаем на вход два положительных числа, наша задача сложить их.
Кладем их в integer и возвращаем integer. Тут в core мы будем надеяться, что возвращается всегда положительное, но тип данных шире. Поэтому, при ошибке в core, система может оказаться в невалидном состоянии.
Кладем их в unsigned и его же возвращаем. В таком случае, при возникновении ошибки в core, мы попадаем всегда в валидное состояние, хоть и неправильное.
мне кажется это будет работать, если соблюсти инварианты при парсинге. glibc же их не соблюдает, как и большинство сишного кода. А правильность можно контролировать тестами. Хотя может я и ошибаюсь - выслушаю, если объясните по подробнее.
Alpine Linux использует musl вместо glibc. Попробуйте, может вам понравится. Но вообще это рулетка.
это Астра? Вообще зависимостей libQtCore не должно быть вроде.. А астра знаменита тем что средства разработки даваемые в комплекте - это не те средства которыми собирали ОС. Да, это та версия, но не тот же экземпляр сборки.
Та же проблема может возникнуть на любой другой линукс если цепочку пересобирать своими лапками...
Ребята из LLVM не сидят в сторонке и тоже пилят свой libc:
https://libc.llvm.org/
Я использую и glibc и musl. Так, musl хорошь очень. И меньше glibc и архитектура у него лучше. Но все-таки он немножко медленнее glibc, особенно при работе с памятью.
Да, судя по всему именно на памяти они и экономят, всё остальное стандартно
К слову, libbionic тоже изначально на минимум памяти рассчитывал, но сейчас у них там вроде компромиссный аллокатор в тренде (согласно Википедии).
Как сказал бы Линукс - не ломайте юзерспейс. Если вам хочется musl - ничто не мешает вам его использовать, но ещё миллион тысяч софта зависит от glibc и никуда от него не деться.
А какие альтернативы? Сколько тех компиляторов я. п. C/C++ известно?
От Microsoft, 2) От Intel, 3) от GNU, 4) Pelles C.
Что-то нужно менять: либо я. п., либо ОС. Потому как для Linux он только один. Если не ошибаюсь, интеловский компель, вроде, тоже не в данном вагоне едет.
Почему Вы пользуете какие-то старинные glibc?
Вот у меня, на пример
ldd --version
ldd (GNU libc) 2.38
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.
Но Вы же сами пишите, что проблема была в несовпадении версий библиотек, откуда мысль что это должен разруливать glibc? Если считаете что пора искать альтернативу, исчите, пишите, это Linux.
Хм, вообще-то проблема не в том, что версии не совпадают, а в том, что программа сыпется. Какие бы версии либ там ни были, падать не стоит. Не совпадает версия - ну не загрузили и всё. Собственно так и было задумано: либа грузится с помощью dlopen, динамически, и если не загрузится - мы пробуем другую (libQt6Core.so). Но такой расчёт не принял во внимание бажность самого загрузчика, да он и сам от себя такого не ожидал - я же писал, что он не определил, что находится в невалидном состоянии.
ПС когда так ведёт себя ядро мы видим, что происходит: бесконечные синие экраны смерти порядком надоедали в старых версиях винды (98-я, например, да и Хр). Да и линуксы с кернел паник тоже не радовали. Нормальный софт почти любую ситуацию должен разруливать корректно.
Не пора ли валить с gnu libc на что‑то другое?