В далекие времена установка программного обеспечения под операционные системы семейства Линукс могла серьезно напугать начинающих пользователей этих ОС. Загрузка исходников, борьба с зависимостями, которая зачастую превращалась в нетривиальный квест, ручная правка конфигов и другие “прелести” установка приложений того времени сейчас покажутся глубоким анахронизмом.
Сейчас любой уважающий себя дистрибутив Линукс имеет в своем составе возможность установки программного обеспечения с помощью менеджеров пакетов.
Системы управления пакетами (которые также иногда «менеджер пакетов» или «пакетный менеджер») — это набор программного обеспечения, позволяющего управлять процессом установки, удаления, настройки и обновления различных компонентов ПО.
В этой статье мы рассмотрим основные менеджеры пакетов, которые используются в различных дистрибутивах Линукс.
Какие пакеты бывают
Различные дистрибутивы ОС Linux имеют свои форматы пакетов. Вот основные форматы:
.deb – Debian и производные (Ubuntu, Mint и т.д.)
.rpm – Red Hat и производные (CentOS, Fedora и т.д.), OpenSUSE
.apk – Android
.ebuild – Gentoo
Каждый формат имеет свои преимущества и недостатки. Так rpm совместим с различными дистрибутивами Linux и обеспечивает более быструю установку и обновление пакетов, но при этом установка и обновление зависимостей может занимать значительное время при установке большого количества пакетов и имеет более сложную систему идентификации версий пакетов, что может привести к проблемам при обновлении или установке.
А deb имеет более простую систему идентификации версий пакетов, что упрощает работу с ними, благодаря чему управление зависимостями происходит быстрее и более эффективно. Но при этом поддерживает ограниченное число дистрибутивов Linux, что может создать проблемы при переходе на другую операционную систему и может потребовать дополнительной настройки для работы с некоторыми пакетами (например, в случае несовместимости с определенной версией ядра).
Из чего состоит пакет
Прежде, чем начать рассмотрение принципов работы с пакетами, поговорим о том, что содержат в себе пакеты. Пакет, как правило, содержит само приложение, в откомпилированном виде, то есть, по сути в виде бинарного файла.
Также в пакете указывается метаинформация, то есть информация о другой информации, используемая инструментами управления пакетами.
Метаинформация представляет собой составленное по определённым правилам описание, которое содержит имя пакета, номер версии и сборки, сведения о разработчике и его мастер-сайте, список файлов, их положение в файловой иерархии, список зависимостей. Также, здесь могу присутствовать установочные и настроечные сценарии, необходимые для развертывания приложения.
Помимо установочных сценариев, пакет также содержит набор действий, выполняемых после установки (например, пост-инсталляционную конфигурацию). Также пакет содержит сценарий, выполняемый в случае удаления пакета.
Посмотрим пример структуры пакетов для Debian. Зависимости определены в поле Dependents в заголовке пакета. Это список условий, которые должны быть выполнены для корректной работы пакета. Данная информация используется такими инструментами, как apt, для установки необходимых библиотек, утилит, драйверов и т.д. в соответствующих версиях, удовлетворяющих зависимостям устанавливаемого пакета. Для каждой зависимости можно ограничить диапазон версий, удовлетворяющих этому условию. Другими словами, если нам нужен пакет libc6 в версии, равной или превышающей “2.15” ( “libc6 (>= 2.15)”), то операторы сравнения версий следующие:
<=: less than or equal to;
=: equal to (note that “2.6.1” is not equal to “2.6.1-1”);
>=: greater than or equal to;
>>: greater than.При этом, стоит отметить, что не все пакеты содержат программы, некоторые содержат шрифты, изображения, темы и т.д.
Зависимости и конфликты
Сейчас сложно представить приложение, не использующее в том или ином виде сторонние библиотеки и другие зависимости. То есть любая, сколько-нибудь сложная программа зависит от пакетов, поставляющих библиотеки. При этом возможна ситуация, когда пакет конфликтует с уже установленным в системе. Наиболее распространенные причины этого заключаются в том, что оба пакета включают файл с одинаковым именем и путем, или предоставляют одну и ту же службу на одном и том же сетевом порту, или препятствуют работе друг друга.
Здесь возможны различные варианты реагирования, в общем случае пакетный менеджер откажется устанавливать пакет, если он вызывает конфликт с уже установленным пакетом. Однако возможна ситуация, когда в новом пакете явно указано, что он “заменит” установленный пакет, и в этом случае менеджер предпочтет заменить старый пакет новым. А вот менеджер apt всегда следует вашим инструкциям: если вы решите установить новый пакет, он автоматически предложит удалить пакет, который создает проблему.
Также, в случае конфликта возможен следующий вариант реагирования: пакетный менеджер просигнализирует о том, что установка пакета “сломает” другой пакет (или определенные его версии) и далее уже пользователь должен решать, что делать в подобной ситуации. При этом различные менеджеры по-разному отреагируют на такую ситуацию. Так, dpkg откажется устанавливать пакет, который нарушает работу уже установленного пакета. А вот apt попытается решить проблему, обновив пакет, который был бы нарушен, до более новой версии (предполагается, что она исправлена и, таким образом, снова совместима).
Такого рода ситуация может возникнуть в случае обновлений без обратной совместимости: это тот случай, когда новая сигнализирует о том, что установка пакета “сломает” другой пакет (или определенные его версии).
Некоторые форматы пакетов можно конвертировать. Так, например пакеты .deb можно конвертировать в другие форматы с помощью утилиты alien. В качестве примера преобразуем deb пакет в rpm.
Для этого сначала установим утилиту alien:
sudo apt-get install alien
Далее выполним конвертацию пакета Teamviewer из deb в rpm. Общий формат работы с alien будет следующий:
sudo alien <package_name>.deb
Для нашего примера с teamviewer:
sudo alien --to-rpm teamviewer_amd64.deb
Основные операции с пакетами
Установка пакетов во всех менеджерах производится схожим образом. Необходимо сначала скачать пакет (.deb, .rpm ...), далее установить пакет вручную, используя команду данного дистрибутива (dpkg, rpm и т.д.). Например, для dpkg это будет dpkg –i firefox-19.0.deb, а для apt apt-get install firefox.
При этом, все зависимости разрешаются и устанавливаются автоматически.
Обновление списков пакетов и самих пакетов для apt выполняется следующим образом:
apt-get update
Обновление репозитория. Загружает только список пакетов, а не сами пакеты.
apt-get upgrade
Загрузка более новых версий локально установленных пакетов.
И для удаления пакетов в apt используется следующая команда:
apt-get remove [ --purge ] package
Если "--purge" указан, удаляет и конфигурационные файлы.
Где искать пакеты
Для поиска пакетов под различные дистрибутивы можно конечно воспользоваться поисковиками, но лучше использовать проверенные ресурсы, чтобы не столкнуться с сомнительным содержимым. Так, пакеты для Ubuntu можно поискать на следующем ресурсе:
https://packages.ubuntu.com/
А для RPM можно посмотреть здесь:
http://www.rpmseek.com/
Заключение
В этой статье мы рассмотрели основные моменты, связанные с работой с различными пакетами и пакетными менеджерами. А про стандартные потоки ввода/вывода мои коллеги из OTUS расскажут на бесплатном уроке специализации Administrator Linux.
Комментарии (93)
nronnie
26.06.2023 14:56+6Например, для dpkg это будет dpkg –i firefox-19.0.deb, а для apt apt-get install firefox.
Я в линуксах не великий эксперт, но и не совсем лох, и тут я что-то совершенно не понял и впал в ступор. Разве
apt/apt-getэто не надстройка надdpkg, которая просто работает не с локальными файлами.deb, а с сетевыми репозиториями этих же файлов?
RolexStrider
26.06.2023 14:56+2Если .apk - то в контексте именно дистрибутивов Linux - это про Alpine. А ebuild - это вообще не пакет)
nronnie
26.06.2023 14:56Сейчас, вроде бы еще модно-молодежно это
snap, тиснул бы кто-нибудь статью тут про него уровня "для самых маленьких", а то самому по мануалам разбираться никак всё руки не дойдут.
kovserg
26.06.2023 14:56+3Нафиг нужен snap который для запуска тянет с собой копию половины линукса для небольшой утилиты и при этом загаживает систему (в mount просто жесть). Appimage выглядит в этом ряду значительно привлекательней.
nronnie
26.06.2023 14:56Да я сам им не пользуюсь, за ненадобностью (у меня Линукс стоит, практически, только как запускалка докер-контейнеров), но он существует, и, по-моему в Ubuntu 23 уже даже ставится по умолчанию, так что хотелось бы на всякий случай с ним ознакомиться.
websnow
26.06.2023 14:56Сейчас модно flatpak юзать
kovserg
26.06.2023 14:56websnow
26.06.2023 14:56Например у меня Fedora, и проще пожертвовать 125 MB на flatpak, чем собирать из исходников или, как предлагает автор ScummVM, тащить Canonical Snapcraft ради одной программы. Насколько мне известно, вменяемых альтернатив у flatpak в данном сценарии нет, особенно когда речь заходит о скорости запуска программы
ALexhha
26.06.2023 14:56Докер чем не альтернатива
websnow
26.06.2023 14:56Как предлагаете ту же Krita в Docker использовать?)
Докер чем не альтернатива
всем, это как вместо колёс на автомобиль ставить спасательные круги (потому что круглые)
ALexhha
26.06.2023 14:56Как предлагаете ту же Krita в Docker использовать?)
по офф доке - https://docs.krita.org/en/untranslatable_pages/building/build_krita_with_docker_on_linux.html
P.S.ну хоть не фотошоп и не автокад с 3d макс )))
iig
26.06.2023 14:56build_krita_with_docker_on_linux.html
Сборка в docker - уже привычное зло. Но достаточно удобное ;) А для запуска придумали других инструментов, удобных именно для запуска.
Aldrog
26.06.2023 14:56+1Вы сами эту доку читали? Там ни слова нет про запуск Krita в Docker, только про сборку в контроллируемом окружении.
ALexhha
26.06.2023 14:56Там ни слова нет про запуск Krita в Docker
а в чем проблема после сборки запустить docker run ?
Aldrog
26.06.2023 14:56+1В том, что крита не запустится с какой-нибудь ошибкой в стиле "не найден дисплей"?
iig
26.06.2023 14:56+1Передать дисплей внутрь docker не очень сложно. Но это из серии "в гамаке и стоя".
Aldrog
26.06.2023 14:56Вот именно. А присланный гайд не только никак не помогает в этом, но и вовсе не имеет отношения к заданному вопросу.
iig
26.06.2023 14:56Если docker run вызывает проблемы, то увы, медицина тут бессильна
Лично вы запускали эту самую krita в docker-окружении?
И вкрутили это в свое DE, во все менюшки.. Правда?
Aldrog
26.06.2023 14:56+3Давайте по порядку.
- Вы предложили docker как альтернативу flatpak;
- websnow спросил, как использовать docker в совершенно типичном для flatpak сценарии;
- в ответ вы скидываете гайд по созданию контейнера для сборки программы с таким видом, будто это отвечает на заданный вопрос;
- даже если всё-таки пойти дальше, собрать программу, подобрать правильные опции для её запуска, написать для неё .desktop-файл, вы получите контейнер, занимающий в несколько раз больше места, чем и так раздутый flatpak, и программу с урезанным функционалом (как минимум, не будет подхватываться системная тема, не будет работать drag&drop между приложениями).
Вы всё ещё считаете docker адекватной заменой для flatpak? Напомню, что flatpak появился позже докера, и занял нишу, на которую тот никогда не претендовал — распространение изолированных графических приложений для ПК.
mastan
26.06.2023 14:56+1Установка пакетов во всех менеджерах производится схожим образом. Необходимо сначала скачать пакет (.deb, .rpm ...), далее установить пакет вручную, используя команду данного дистрибутива (dpkg, rpm и т.д.). Например, для dpkg это будет dpkg –i firefox-19.0.deb, а для apt apt-get install firefox
dpkg -i firefox-19.0.debставит пакет из файла,apt-get install firefoxиз репозитория. В последнем случае не нужно скачивать файл вручную вообще - apt скачает нужные файлы из репозитория и сам же вызовет dpkg для их установки.iig
26.06.2023 14:56Пока списки репозиториев никто не правил
непрямыми ручками, и не пытался притащить .deb с нерешаемыми зависимостями - прокатит. А потом бывают жалобы, что этот ваш пакетный менеджер плохой, негодный совсем, полсистемы мне снес ;)
ilitaiksperta
Менеджеры пакетов с зависимостями - одна из худших инженерных идей в истории ойти, гдето на одном уровне с electron.
Вместо того чтобы решать проблемы и упрощать жизнь - эта идея порождает проблемы. Ярчайшие примеры - dependency hell в линуксе, пакеты в npm с 500 вложенным и зависимостями и т.п.
@markmariner
Менеджеры пакетов без зависимостей. Apk \ F-Droid идеальный пример.
markmariner
Какое решение распространения кода вы предложите?
RolexStrider
+1 Я бы даже сформулировал как "какое более эффективное решение для повторного использования бинарного кода предложите?"
swelf
Что бы получать правильные ответы, надо задавать правильные вопросы. Акцент в вашем вопросе на слове "повторного" совершенно не верен с моей точки зрения, и абсолютно никак не связан с желанием "упрощать жизнь" из изначального тезиса(хотя и не противоречит в общем случае тоже). Проблема недостатка свободного места из-за бинарников мне кажется уже не актуальна, на фоне разного рода данных. Всякие snap шагающие по планете тому подтверждение. Если посмотреть например на разработку ПО, так там сейчас у каждого проекта свои наборы зависимостей, потому что удобно. Потому я задам вопрос так: "Какую проблему решает повторное использование бинарного кода?" не вижу ни одной причины за него цепляться и искать "удобные" способы рапространения.
khajiit
А с точки зрения пакетного менеджера — это то, для чего он создан и чем занимается.
Вот в чем фикус-то.
Кстати, с менеджером без зависимостей, упомянутым тредстартером, есть такой забавный нюанс: вот зависит приложение от system webwiew — но где там, оно будет установлено даже в его отсутствие, не говоря уже про вшитые и заброшенные версии от вендора. Просто падать будет, если разработчик не предусмотрел костыль.
И в рамках дихотомии костыли в каждом проекте vs централизованная проверка зависимостей: и как пользователь, и как писатель, и как администратор — этот предпочтет нормальный пакетный менеджер, который сразу скажет что так оно работать не будет, инфантильному инсталлятору без проверок.
DaemonGloom
Кажется, в том комментарии предложили менеджер без зависимостей в виде flatpak/snap. Когда всё нужное ставится каждый раз заново одним пакетом.
khajiit
Перечитал ветку выше — но там только в корневом комментарии предлагается
Apk \ F-Droid идеальный пример.На котором очень уж удобно продемонстрировать ошибку)
Даже если закрыть глаза на проблемы с безопасностью при таком подходе, распухание для krita или браузера на сотню мегабайт — не слишком критично, они и так весят немало.
Распухание на сотню мегабайт каждого бинаря из /bin — это конец.
Ну и всегда остаются слабые зависимости: графическая среда и ее утилиты, видеокодек, сеть и прочая и прочая.
ilitaiksperta
@RolexStrider
Я бы сформулировал вопрос вообще по-другому: Как называется болезнь, когда человек создает реальные проблемы программистам (распространение и поддержка софта) и юзерам (установка софта), чтобы решить воображаемую (повторное использования бинарного кода)?
@zlo1
Охлол, ну доверяй тогда опенсурсу из npm, где сегодня сбилженая аппа с миллионом вложенных зависимостей решает свою задачу, а та же самая аппа, сбилженая через неделю ворует пароли. Потому что у половины пакетов даже версии нефиксированные, и гдето там в глубоких слоях зависимостей ктото закоммитил плохое зло, а отревьюить миллион пакетов нереально.
Ты можешь доверять софту только потому, что он написан на няшкой сишечке или плюсах, у которых нету пакетных менеджеров и либы берутся либо из сорцами папки third-party, либо из системы. И поэтому разрабу пришлось думать, а не пакет с пакетами из помойки тащить. С npm, pipом и прочими порождениями сверхразумов доверять исходникам у тебя уже не получится.
@ALexhha
Пакетный менеджер - придуман чтобы экономить память. Но никаких проблем нет - просто скачай половину репы. Это просто шиза, создать кучу гемороя, чтобы потом всрать основной поинт этой геморной системы. А юзер всеравно в итоге поставит флетпак, скачает гиг мусора чтобы запустить калькулятор, просто потому что так оно хотябы работает без боли.
Это тоже следствие того что зависимости в пакетах - одной из худших решений ever. Пакеты между двумя deb дистрбутивами даже не совместимы, это лол. Т.е. мейнтейнеры буквально допиливают софт под набор костылей, называемый дистрибутивом, иначе оно вообще нежизнеспособно.
@khajiit
Ну есть и есть, у тебя все аргмуенты построены на "хитрой" схеме. Я говорю - пакетные менеджеры с зависимостями создают dependency hell и это создает вагон проблем, как разрабам, так и юзерам, буквально by design. Ты в ответ выискиваешь в других подходах какието маргинальные кейсы, типа на винде иногда dllки дебил-автор забудет с прогой положить, или на ведре системный webview кривожопый. И приравниваешь эти проблемы.
Типа по-твоему системная проблема, которая генерит геморой на ровном месте регулярно и фиксится только отказом от такого подхода - это тоже самое, что решение в котором проблемы возникают в 1-2% случаев и не требуют переделки всей системы для фикса.
Вот именно поэтому пакетные менеджеры прижились только на 1% ос и у полоумных джиесеров в npmе. Юзеру надо что аппа ставилась и работала, а с пакетным менеджером оно регулярно работать не будет. Да, да, я знаю у тебя такой же линукс и все работает. Вон у джавистов например джава не тормозит, это же не стало правдой.
Добавишь в установщик apk зависимости, разрабы начнут туда говнолибы и прочие свои поделки пихать - и проблемы, подобные косякам с системным WebView будут возникать постоянно.
На ведро уже пытались протащить заивисисмости, когда туда портировали Qt. В итоге эта идея быстро загнулась, юзеры не поняли почему они должны гемором заниматься, вместо того чтобы apk поставить.
@kovserg
@saege5b
Смотрится не очень, зато работает без боли. Установить иногда vsredist, да даже 10 версий этого vsredist разом куда меньший геморой, чем разруливать зависимости в линуксе.
khajiit
Особенно хитрой становится схема, когда начинаешь учить матчасть и — ВНЕЗАПНО! — понимаешь, что начиная с 7 в винде реализовано то же самое: версии, зависимости и вот это вот все, только с мелкомягкой спецификой )
У вас какие-нибудь пригодные к обсуждению аргументы-то найдутся, кроме бессмысленного и беспощадного вайна?
0xd34df00d
«C» in CVE is for the C language.
Доверять можно только софту, написанному на идрисе. Доверять, что не своруют пароли, ещё можно на хаскеле.
Зачем пловину?
Для их задач — не тормозит (точно так же, как человеку сверху не лень фильтровать локально скачанный список писем через сервер). Для моих задач — у меня на линуксе всё работает, а на винде — нет.
ALexhha
пакетный менеджер рассчитан на наличие интернета, внезапно. А то ты сначала выдумываешь ситуации, а виноват в итоге пакетный менеджер )))
никаких проблем не вижу. Зависимости избавляют от кучи проблем с софтом
а с чего они должны быть совместимы лол ? Поставь поршни от бмв на ауди, внезапно они не совместимы :D
никто ничего не допиливает, а выбирают по их мнению самые стабильные версии. Не нравится - Welcome to Linux From Scratch!
Aldrog
Внезапно нет, как минимум apt(-get) и pacman поддерживают локальные репозитории (например, на дисках или флешках). В yum и прочих наверняка тоже подобные механизмы есть.
ALexhha
Естественно поддерживают, тогда о чем вообще разговор ? Я показал пример как установить без наличия инета, дисков, флешек и вот этого всего
zlo1
Как гентушник, в эпоху интернета и git, для меня дикость доверять бинарному Г.. и не оптимизированному под мое железо (march=native) . Зависимости при установке из исходников - наименьшая из проблем
CherryPah
Можете привести какой-нить довод зачем мне нужно оптимизировать под свое железо почтовый клиент. Почта быстрее ходить станет?
0xd34df00d
Полнотекстовый поиск по почтовой базе быстрее станет, например.
Starl1ght
на 0.02% ?
0xd34df00d
В 10 раз.
c3gdlk
10 раз от какого времени? я разницу между микросекундами и милисекундами не замечу.
0xd34df00d
Смотря какая база. Единицы секунд — уже достаточно?
А батарея — заметит.
Starl1ght
Для интереса качнул такой же греп, что у меня в убунте (3.7), собрал его через make CFLAGS="-O2 -pipe -march=native -floop-interchange -floop-strip-mine -floop-block"
И запустил по 100 тестов а-ля "grep -ri pogchamp" по ~/ для собранного и системного - системный греп отрабатывает в среднем на пару-тройку процентов быстрее.
Что я делаю не так? В линуксокопошении не силен.
i7-13700KF, DDR5-6400, Kingston KC3000 2tb ссд.
0xd34df00d
Используете для бенчмаркинга непредназначенный для этого grep и делаете непонятно какие выводы, которые вы забыли написать?
Starl1ght
Так давайте проведем бенчмарк и сделаем понятные выводы?
Идея грепа в том - что это как раз тот самый полнотекстовый поиск, пакет из репо убунты для всех, и те же сырцы, перекомпилированные ПОД СЕБЯ, ровно так, как вы написали в комменте ниже.
На 100 запусках каждого бенча есть повторяемая разница в пару-тройку процентов в пользу пакета из репо.
Я просто очень хочу обещанное х10 ускорение увидеть. В идеале, без читерства а-ля #ifdef AVX512_SUPPORTED
0xd34df00d
Довольно забавно, что я как раз позавчера обновил один свой древний бенчмарк с очень тупой задачей подсчёта (aka поиска) количества вхождений символа в строке, и там разница между
-O2и-O3 -march=nativeкак раз в 7.5-9 раз.И, кстати, при
-march=nativeс поддерживающим avx512 хостом, например, clang заменяет порнографию из последовательности popcnt над скалярными регистрами в один avx512bw-толстый popcnt (правда, всё равно упираясь в шину памяти, но это другой разговор — на amd'шном железе нет аналогов интеловского vtune с интеловским анализатором потребления энергии).Про верчение-перемножение матриц, которое от компиляции под конкретное железо может ускоряться в те же 10 раз, что я наблюдал на практике, но бенчмарк для чего наваять сходу геморройнее, я уж не говорю.
Греп — это комбайн с кучей легаси. Написанный с нуля код может заруливать легаси даже на непредназначенном для этого языке. Что там бородатые мастера C нафигачили, что оно не поддаётся оптимизациям компилятора, я даже разбираться не хочу — мне говнокода в coreutils'ном
wcхватило, аgrepсложнее.А почему так? Это, особенно с #ifdef, не нацеливание на конкретную машину?
iig
Так и этот ваш linux состоит из легаси чуть более чем полностью. Числодробилку или синтетический тест, или очень правильно написанный код ускорить правильной сборкой наверное можно. А вся система полностью упрется в IO.
0xd34df00d
Как и любая современная ОС, имеющая больше трёх с половиной пользователей.
Немало задач сводится к числодробилкам, так что нет.
M_AJ
В эпоху IMAP, когда поиск писем практически всегда выполняется сервером?
0xd34df00d
Хочу выполнить поиск всех писем, содержащих pdf-вложение с текстом «имяпроекта», или поиск всех писем, содержащих близкие в word2vec слова к «досада». Помогите, пожалуйста, сделать это через IMAP. В качестве задачи со звёздочкой помогите это сделать через IMAP, если письма зашифрованы каким-нибудь там GPG (потому что я не доверяю серверу), и ключ есть только локально.
Кстати, если у вас в папке 100500 писем, то для фильтрования вашей вьюшки с их списокм по заголовку или отправителю вы тоже будете ходить в сеть и делать IMAP-запрос?
Ну и главное тут — чтобы треды с нытьём о тормозах современного ПО и треды «гагага зачем собирать ПО под свою машину с sse 4.2/avx2/avx512 оптимизаторы хреновы))))» были достаточно разнесены в пространстве-времени, а то иначе вопросы могут возникнуть даже у авторов таких комментариев.
M_AJ
Это конечно же делается в стандартном почтовом клиенте, который нужно просто пересобрать с нужными флагами, а не с помощью чего-то самописного. И конечно тут главный вклад внесет время самого поиска, а не скачивания pdf-ок, и не чтение их с диска.
Современное ПО если тормозит, то явно не от того, что собрано без поддержки AVX512 инструкций, и то что оживить старый комп на 10-летней давности Core i5 помогает вовсе не замена проца и пересборка ПО, а замена диска на SSD очень жирно на это намекает. Есть исключения, в виде задач обработки изображений, рендера видео или рассчетов в CADах, но это явное меньшинство.
0xd34df00d
Как дела с фильтрацией по теме или отправителю?
Немало известных мне почтовых клиентов вполне умеют в GPG.
С word2vec да, я сам себе свои костыли написал. Но на вопрос о том, «зачем», это, надеюсь, отвечает?
Качаете их вы в любом случае и один раз.
Вы что-нибудь слышали об индексах?
M_AJ
Сложно сказать без тестов, и уж это то точно без проблем делается на стороне сервера.
В контексте обсуждения пакетных менеджеров, обсуждать то, насколько ускорились свои самописные костыли просто не имеет смысла, имеет смысл обсуждать какой прирост даст пересборка популярных пакетов. Впрочем, надо будет просто как нибудь взять, да погонять под Дженту и под Убунтой какие-нибудь популярные вещи типа Chromium/Firefox, парочку СУБД, да какой-нибудь PHP и сравнить.
Если я не ищу в них потом текст постоянно, то время на сам поиск в любом случае будет мало в сравнении со временем скачивания. То же самое относится и к индексам -- если я не ищу по письмам постоянно, то время на скачивание и индексирование будет многократно превышать время на сам поиск, и даже ускорение его в десять раз не будет играть роли в скорости получения итогового результата, потому что бутылочное горлышко в данном случае совсем в другом месте. В народе это называется "экономией на спичках".
0xd34df00d
Ну, то есть, делаем сетевой запрос на сервер, чтобы просто поискать слово в теме. А если интернет недоступен, то фильтровать по заголовкам нельзя. Зато пересобирать ничего не нужно!
Это уже минимум третий раз, когда в этом треде двигаются гоалпосты.
Firefox гоняли, правда, пять лет назад, профит измерим вполне: тыц.
Разница в том, что индексировать (и качать) вы можете асинхронно — это подготовительная работа, которую потом, во время поиска, не видно.
Arris
Ну так, просто для сведения: синтетические тесты на PHP, поставленном из бинарника отрабатывают примерно на 20-25% дольше, чем те же самые тесты, но выполненные на PHP скомпилированном под конкретную архитектуру.
Несколько лет назад на генте проверял.
Сейчас бы проверил с пайтоном и pytorch, но у меня уже нет генты..
randomsimplenumber
В debian, например, есть бинарники для кучи архитектур. Можно надеяться, что бинарники для х64 собраны не хуже, чем если руками configure && make && make install ?
0xd34df00d
Нельзя, потому что x64 много разных, и core 2 duo из 2006-го и ryzen 9 из 2023-го — это две разные железки, с двумя разными наборами доступных расширений архитектуры, и то, что собрано в дебиане под x64, должно работать и на первой из них, поэтому там берётся наибольший общий делитель всех этих архитектур.
Да, есть рантайм-диспатч, но это совершенно отдельный разговор, и это — что-то, о чём автор кода должен позаботиться явно. Это требует неприятного кода, и это тяжело сделать кроссплатформенно (тот коммент и далее по тексту). Более того, это требует дупликации кода — значит, количество ваших тестов соответствующим образом растёт, а уверенность в них — падает, тогда как оптимизатору компилятора вы и так доверяете.
Arris
Я в курсе, спасибо. Но сборка "под процессор" это немного другое, нежели "сборка под архитектуру".
P.S. Да, моя ошибка. Под "конкретную архитектуру" я понимал именно "конкретный процессор + всё остальное железо, что и составляет архитектуру".
ALexhha
а вот и оптимизаторы с секретными ключами сборок подъехали. Только они знают секретные ключи сборки, которые позволят собрать пакет и он будет работать на 0,00001% быстрее, но это не точно. Причем, как правило, это оптимизаторы потом ни за что не отвечают и в случае чего, всю вину валят на ментейнеров.
В k8s тоже предлагаете компилить все из исходников в инит контейнерах, нее ну а чо, удобно же
cat_chi
Подозреваю, что труЪ гентушник за одно упоминание k8s должен бы предать вас анафеме :)
M_AJ
Да и бог с ними, честно говоря, пусть развлекаются на своих десктопах, как их душе угодно.
0xd34df00d
Что секретного в
?
Подъехали какие-то совсем уже неприкрытые соломенные чучела.
Не пользуюсь k8s и даже не знаю, зачем он мне был бы нужен.
ALexhha
и что оно дает по сравнению со стандартными ключами дистрибутива ?
не пользуешься, это не значит что он не нужен другим
0xd34df00d
Вы знакомы с
-march?Тред начался с того, что «я не пользуюсь сборкой под своё железо, значит, это глупо и никому не нужно».
Что вам там даёт k8s, 0.02% удобства?
ALexhha
а с чем сравниваем ? Если с vps/vds - то 1000%. Если взять аналогию - сравните ваз и мерседес
в общих чертах.
Я имел ввиду, вот мы перекомпилировали все утилиты из coreutils c этими ключами, что мы как devops/сисадмин от этого выиграли ? У нас база данных стала быстрее запросы выполнять или rps в nginx вырос в 2-3 раза.
Ответ очевиден - конечно же нет. Тогда напрашивается вопрос - мы это делали чтобы что ? А теперь умножаем количество серверов на 1000. Все еще хочется пересобирать пакеты ? А обновления уязвимости выходят раз в неделю и поехали перекомпилировать на 1000 серверов
P.S.
я не рассматриваю случай, когда мы это делаем на личном ноуте. Там как говорится - играйся на здоровье, если есть время и желание
0xd34df00d
Бенчмарки покажете? :]
Но я не девопс и не сисадмин. Дома — вы сами написали, всем пофиг. На работе — я как раз пишу (вернее, раньше писал) эти самые числодробилки, и там всё собирается под конкретное железо.
Чё-то там про бинхосты.
ALexhha
бенчмарки удобства ? ))) Ну самое банальное, вам через 5 минут надо поднять 100/200/300/1000 нод на arm и запустить тест.
ну так это эдж кейс. Конечно для таких случаев оно имеет смысл и место быть. Более того, там и до asm вставок можно скатиться и оно будет иметь смысл
0xd34df00d
Ну да. У меня вон сверху требуют же бенчмарки, так почему тут голословных утверждений должно быть достаточно?
Это какая-то синтетика.
Ну а в моей практике 100 нод на чём угодно — эдж кейс (мой код никогда не работал больше чем на то ли 14, то ли 16 нодах, и никаких кубернетесов там не было). А вот низкоуровневой оптимизацией в том числе я лет 10 себе на жизнь зарабатывал. ХЗ, какой тут вывод.
ALexhha
реальный юзкейс из практики
cat_chi
Пока не нашли способ бенчмаркать седину админов :)
Хотя есть идея. Берём две контрольные группы, поддерживающие идентичные хайлод-сервисы, цепляем каждому умные часы, трекаем качество сна в "чёрную пятницу"...
M_AJ
Предсказуемость работы на различных этапах, автоскейлинг, автоматическая балансировка нагрузки и автоматический перезапуск упавших частей системы, это куда больше чем "0.02% удобства".
cat_chi
Кому-то нужно, кому-то не нужно. Но это точно история не для всех. Хотя "играться" с гентой всегда было интересно.
Та же история с кубером.
А с чего там тред начался, да какое нам дело :) Куда важнее, куда он в итоге придёт
vvpoloskin
Это проходит. Я этим 15 лет назад тоже болел.
net_racoon
В начале 2к кеды + либра опенофис собиралось из исходников 2 дня. Зато оптимизировано под мое железо...
nikhotmsk
Мне тоже накипело. Пакетные менеджеры - сложная вещь, при желании их легко можно ввести в ступор. Если бы я коллекционировал все ошибки, которые выдает пакетный менеджер, накопилось бы на целую тетрадку.
Сейчас я уже освоился с ним, но крови он попил прилично в свое время.
Порой приходится вручную лезть в пакеты, стирать ненужные зависимости, ведь программа работает и без них.
Ни один пакетный менеджер еще не научился подгружать библиотеки для бинарника в runtime. Это все по прежнему вручную происходит. И это бесит. Особенно если нужный файлик находится в пакете с совсем другим именем, ничего не напоминающем. В разных дистрах имена одного и того же пакета разные, естественно.
Если для бинарника нужна библиотека другой версии, то без шансов. Не запустишь. Я так и не смог запустить нужную программу для звукорежиссеров, просто потому что там gtk старый.
Установка программ на машину без интернета - отдельная очень длинная и сложная история, даже не буду трогать. Винда здесь выигрывает однозначно.
kovserg
Винда тоже смотрится не очень особенно в директории winsxs. Да и навязчивые добавления искусственной не совместимости со старыми версиями тоже.
saege5b
В Винде легко какая-нибудь сборка может упереться в какую-нибудь исполняемую среду визуалстудии.
После чего говорит: - прощайте.
ALexhha
да нет никаких проблем, на машине с инетом
на машине без инета просто
ну да ну да
зачем ? Чтобы сэкономить 1 мб дискового места ? Если зависимость реально не нужна, то делаешь PR мейнтейнеру и ее удаляют
yum install git ничего в ручную не ставлю
если ты пытаешься ставить пакет с ubuntu на debian то ССЗБ
iig
Но виноваты Торвальдс и менеджер пакетов ;)
khajiit
Плохому танцору вечно что-то мешает )
Aldrog
На самом деле, менеджеры с зависимостями очень эффективно решают ряд проблем:
При этом они не вносят никаких новых проблем до тех пор, пока используются для популярного, активно развивающегося, открытого софта. А вот если по этим параметрам достаточно далеко уходить (особенно по нескольким сразу), то начинаются проблемы, и в какой-то момент действительно становится проще воспользоваться flatpak/snap/AppImage.
Но благо никто не заставляет выбирать что-то одно, последние никак не конфликтуют с первыми, и ничего не мешает использовать для части софта условный pacman, а для другой условный flatpak.
ilitaiksperta
@Aldrog
Это я и называю выпиюще дерьмовым инженерным решением.
Потому что первые 2 проблемы вообще не существуют. А любые бенефиты от экономии на спичках аннулируются как только юзер ставит flatpak.
А третья решается лишь теоретически, при условии что весь софт установлен через менеджер пакетов, а не через flatpak/snap/AppImage или бинарь без зависимостей, что зависимости системные а не вкомпилены в исходники, что мейнтейнеры не прокекают момент, и что репа не помойка типа aur или npm и т.п. Т.е. в условиях, не существующих в реальной жизни.
Т.е. пока юзер пользуется только софтом, специально допиленным мейнтейнером под дистрибутив. Этот подход с репой и мейнтейнерами под каждый дистр вообще не масштабируемый. Миллон разрабов может мейнтейнить по одной аппе, в итоге мейнтейня миллон апп. Миллион апп в каждой репе под каждый дистр отдельно, силой нескольких мейнтейнеров это уже unmaintainable.
В итоге и профитов никаких нет, а проблемы собрали со всех мест.
@ALexhha
Еще один минус пакетных менеджеров.
Примеры приводить, вы конечно же не будете.
@0xd34df00d
Все правильно пишешь, только гентушники это 1% от одного процента линуксоидов, у других людей есть жизнь за пределами компьютера.
@khajiit
От этого что, установка софта через пакеты с зависимостями стала доминирующим (или хотябы популярным) способом установки софта в винде?
Это все таже охеренно "хитрая" схема - я говорю что ставить софт черещ пакетный менеджер это геморой потому dependency hell, а ты говоришь что гдето в жопе винды тоже есть пакетные менеджеры. Только в линуксе это дефолтный способ ставить софт часто без особых альтернатив, а в винде маргинальный.
Если для тебя это одно и тоже, то внеси в свою матчасть учебник логики, может осилишь не такой школьный способ вести спор.
Ты либо контр-аргументы приводи, либо признавай неправоту. А ты троллинг нытьем разводишь, что аргументы не нравятся.
Aldrog
Серьёзно? Не, я понимаю, что лишняя сотня Мб на каждую программу при текущих ценах на SSD не критична, но ОЗУ-то не резиновая.
Поставил flatpak и два приложения из него. Потерял лишних пару сотен Мб на диске, и сотню Мб оперативки, когда их запускаю. На многих десятках программ, установленных из пакетов, сэкономил на порядок больше. ЧЯДНТ?
Во-первых, почему вы считаете, что наличие хоть одной программы с уязвимостью автоматически делает уязвимой всю систему? А если она даже не выходит в сеть? Во-вторых, flatpak и snap имеют механизмы изоляции приложений, поэтому даже если злоумышленник воспользуется уязвимостью в устаревшей библиотеке, ему понадобится ещё и уязвимость в flatpak/snap для того, чтобы проникнуть в систему.
0xd34df00d
ЧСХ на администрирование системы я трачу околонулевое количество времени, и на другие дистрибутивы переходить не хочу отчасти потому, что мне лень их изучать — в генте всё просто работает.