Разработчики Fedora Linux объявили (https://lists.fedoraproject.org/archives/list/devel-announce.../) о формировании команды Minimization Team, которая совместно с мэйнтейнерами пакетов будет вести работу (https://docs.fedoraproject.org/en-US/minimization/) по сокращению установочного размера поставляемых приложений, runtime и других компонентов дистрибутива. Размер планируется сокращать за счёт прекращения установки излишних зависимостей и исключения необязательных компонентов, таких как документация.
Сокращение размера позволит добиться уменьшения размера контейнеров приложений и специализированных сборок для устройств интернета вещей.
Отмечается, что в текущем виде размер базового образа Fedora почти в три раза превышает аналогичные образы от проектов Ubuntu, Debian и openSUSE (300Мб против 91-113 Мб). В качестве основной причины роста установочного размера отмечаются зависимости, без которых вполне можно было обойтись. Сокращение зависимостей позволит не только оптимизировать размер минимального окружения, но и повысить общую безопасность и уменьшить векторы атак за счёт исключения лишнего кода.
Для сокращения зависимостей планируется проанализировать дерево зависимостей для типовых и часто используемых применений, что позволит понять какие зависимости можно исключать из-за их невостребованности, а какие имеет смысл разбить на части. Также рассматривается возможность предоставления специальных режимов для уменьшения размера устанавливаемых приложений, например, за счёт исключения документации и примеров использования.
URL: https://lists.fedoraproject.org/archives/list/devel-announce.../
Новость: https://www.opennet.ru/opennews/art.shtml?num=51202
Подскажите, как в RPM4 можно проанализировать дерево зависимостей? Какие-то сторонние утилиты? Знаю, что в Росе просто включат все опции сборки, потом тупо пытаются пересобрать все пакеты и запустить.
Что значит "проанализировать дерево зависимостей"? У собранного пакета? Ну вот так хотя бы: https://github.com/htgoebel/rpmgraphИли речь про пакет до сборки? А как вы это представляете, анализировать configure.in / cmakefiles / etc эвристикой? Так это нереально. Тут только руками алгоритмом типа такого: собрать на системе где все стоит с нужными опциями сборки, посмотреть получившиеся зависимости, прописать их, удаляя лишние, если нужно, собрать на чистой системе (чем-нибудь типа mock) для проверки.
Ну а для сборки всего дистрибутива с циклическими зависимостями уже более серьезный подход и инструменты нужны, конечно. Они есть (koji, например).. но все равно нужно делать много итераций сборки и в процессе вручную исправлять косяки.
> Что значит "проанализировать дерево зависимостей"?Цитата из новости. Тоже хотелось бы знать, что подразумевается под этим.
> У собранного пакета? Ну вот так хотя
> бы: https://github.com/htgoebel/rpmgraphЭта штука строит граф Requires из spec-ов. Позже в новой версии разделяемой библиотеки изменились опции, и часть функционала из неё при сборке исчезла. По графу вроде всё ровно, но при запуске системный загрузчик не найдёт связи. Или пользователь через пол-года сообщит: «нажимаю 5-ю кнопку в 3-м меню и оно падает».
> Или речь про пакет до сборки? А как вы это представляете, анализировать
> configure.in / cmakefiles / etc эвристикой? Так это нереально. Тут только
> руками алгоритмом типа такого: собрать на системе где все стоит с
> нужными опциями сборки, посмотреть получившиеся зависимости, прописать их, удаляя лишние,
> если нужно, собрать на чистой системе (чем-нибудь типа mock) для проверки.
> Ну а для сборки всего дистрибутива с циклическими зависимостями уже более серьезный
> подход и инструменты нужны, конечно. Они есть (koji, например).. но все
> равно нужно делать много итераций сборки и в процессе вручную исправлять
> косяки.По-моему, "нужно" и "приходится" -- две большие разницы.
>> бы: https://github.com/htgoebel/rpmgraph
> Эта штука строит граф Requires из spec-ов. Позже в новой версии разделяемойнет, она строит граф из rpmdb. О чем написано в первой же строке ридми.
Если вы не понимаете, в чем разница - вам рано делать глубокомысленные выводы, вы базовый функционал-то изучите.> библиотеки изменились опции, и часть функционала из неё при сборке исчезла.
и граф надо строить заново. Что не так?
> По-моему, "нужно" и "приходится" -- две большие разницы.
приходится из-за циклических зависимостей всего от всего.
Поэтому никакой бутстрэп с нулевой фазы больше невозможен - вам нужна полная система с миллионом неведомых хреней, иначе прекрасные cmake/ninja/meson не запустятся и не смогут собрать /bin/ls.В лучшем случае можно только научиться воспроизводимо пересобирать один отдельный пакет.
>>> бы: https://github.com/htgoebel/rpmgraph
>> Эта штука строит граф Requires из spec-ов. Позже в новой версии разделяемой
> нет, она строит граф из rpmdb. О чем написано в первой же
> строке ридми.
> Если вы не понимаете, в чем разница - вам рано делать глубокомысленные
> выводы, вы базовый функционал-то изучите.эЯ так понимаю, по-вашему, в БД данные сами собой попадают, непосредственно из Космоса, верно? А моё предположение, что люди тут понимают: сначала на базе спека собирается пакет, при установке которого заполняется база -- оно слишком опрометчиво оказалось.
>> библиотеки изменились опции, и часть функционала из неё при сборке исчезла.
> и граф надо строить заново. Что не так?Граф хорошо бы строить с учётом имён импортируепмых-экспортируемых функций, а не только лишь библиотек.
>> По-моему, "нужно" и "приходится" -- две большие разницы.
> приходится из-за циклических зависимостей всего от всего.
> Поэтому никакой бутстрэп с нулевой фазы больше невозможенХотите верьте, хотите нет, но формулировки с избытком абсолютных отрицаний говорят мне достаточно, что бы не воспринимать остальной текст всерьёз.
> вам нужна полная
> система с миллионом неведомых хреней, иначе прекрасные cmake/ninja/meson не запустятся
> и не смогут собрать /bin/ls.
> В лучшем случае можно только научиться воспроизводимо пересобирать один отдельный пакет.
> Я так понимаю, по-вашему, в БД данные сами собой попадают, непосредственно из
> Космоса, верно? А моё предположение, что люди тут понимают: сначала на
> базе спека собирается пакет, при установке которого заполняется база -- оно
> слишком опрометчиво оказалось.Вы, наверное, плохо представляете объем зависимостей, которые создает rpm автоматически (find-requires и другие механизмы, в т.ч. для вытягивание зависимостей из результатов линковки для нативного кода, из анализа метаданных с описанием зависимостей для разных языков типа maven-файлов для java и т.п.). В requires в спеке они явно вписаны могут не быть (хорошо это или плохо - другой вопрос). А в rpmdb они будут.
Более того, в гайдлайнах есть явные требования не писать всякую очевидную чепуху в явные зависимости спека, типа glibc. При сборке она все равно будет в наличии, а в итоговом пакете эта зависимость будет вписана автогенератором.
>>> библиотеки изменились опции, и часть функционала из неё при сборке исчезла.
>> и граф надо строить заново. Что не так?
> Граф хорошо бы строить с учётом имён импортируепмых-экспортируемых функций, а не только
> лишь библиотек.Каких еще функций? Если программа линкуется с каким-нибудь libX11.so, не все ли равно, какие именно функции она оттуда собралась дергать? Это проблема линковщика, а на уровне пакетов достаточно зависимости уровня библиотек.
> Каких еще функций? Если программа линкуется с каким-нибудь libX11.so, не все ли
> равно, какие именно функции она оттуда собралась дергать? Это проблема линковщика,это он glibc(и не только) versioning изобретает. Когда цифирки после .so ничего не означают, потому что линкуется принципиально не по soname, или soname по глупости или сознательно сделан неправильным, а надо уточнить, какую именно libX11 ему надо.
> > Граф хорошо бы строить с учётом имён импортируепмых-
> > экспортируемых функций, а не только лишь библиотек.
> Каких еще функций?Видимо, подразумевалось "импортируемых-экспортируемых".
> Если программа линкуется с каким-нибудь libX11.so, не все ли
> равно, какие именно функции она оттуда собралась дергать?Некоторым из нас нет (в очередной раз сошлюсь на Лёшу Турбина и разработанный им в ALT-RPM механизм set-versions), но это совсем другая сказка: если бы человек озадачился несколькими прогонами apt-cache dot на своей убунте или что там у него, а затем прикинул хоть на пальцах среднепотолочное число функций на сошку -- то пытаться даже не визуализировать граф, а получать данные для него ему бы, скорее всего, расхотелось.
Просто даже для тыщ пяти пакетов лет пятнадцать назад это было уже почти сплошное чёрное пятно из стрелочек в отдельных местах -- при картинке в размерах, которые я мог позволить себе тогда распечатать, а не хотя бы A0...
> Просто даже для тыщ пяти пакетов лет пятнадцать назад это было уже
> почти сплошное чёрное пятно из стрелочек в отдельных местах -- при
> картинке в размерах, которые я мог позволить себе тогда распечатать, а
> не хотя бы A0...Когда у меня был Спектрум, я написал на бейсике программку, которая тупо выводила содержимое памяти на экран. Загружал бинарник от игрушки и тупо в это месиво смотрел. Потом я начал понимать, в каком месте у игрушки картинки, в каком непосредственно код. Это позволило мне здорово экономить время по поиску бессмертий в играх. Даже оставалось время, что бы делать уроки.
А тут я, разумеется, граф смотреть не собираюсь. Пусть железка его анализирует.
>> Я так понимаю, по-вашему, в БД данные сами собой попадают, непосредственно из
>> Космоса, верно? А моё предположение, что люди тут понимают: сначала на
>> базе спека собирается пакет, при установке которого заполняется база -- оно
>> слишком опрометчиво оказалось.
> Вы, наверное, плохо представляете объем зависимостей, которые создает rpm автоматически
> (find-requires и другие механизмы, в т.ч. для вытягивание зависимостей из результатов
> линковки для нативного кода, из анализа метаданных с описанием зависимостей для
> разных языков типа maven-файлов для java и т.п.). В requires в
> спеке они явно вписаны могут не быть (хорошо это или плохо
> - другой вопрос). А в rpmdb они будут.Автоматически пусть хоть в Небесную Канцелярию звонят. Начинается всё с создаваемого методом тыка спека. Вот когда автоматически начнут создавать spec, и пересборка пакетиков не будет превращаться в Китайский Новый год, когда никаких обновлений нет, тогда у меня вопросы отпадут.
> Более того, в гайдлайнах есть явные требования не писать всякую очевидную чепуху
> в явные зависимости спека, типа glibc. При сборке она все равно
> будет в наличии, а в итоговом пакете эта зависимость будет вписана
> автогенератором.Знаю. Читал жалобы пользователей той же Росы, как urpmi --auto-orphans превращает систему в тыкву.
>>>> библиотеки изменились опции, и часть функционала из неё при сборке исчезла.
>>> и граф надо строить заново. Что не так?
>> Граф хорошо бы строить с учётом имён импортируепмых-экспортируемых функций, а не только
>> лишь библиотек.
> Каких еще функций? Если программа линкуется с каким-нибудь libX11.so, не все ли
> равно, какие именно функции она оттуда собралась дергать?Практика показала, что перед тем как дёрнуть, функция там должна присутствовать.
> Это проблема линковщика,
> а на уровне пакетов достаточно зависимости уровня библиотек.
> Я так понимаю, по-вашему, в БД данные сами собой попадают, непосредственно из Космоса, верно?проще: они туда попадают не из спека.
Точнее, в редких-редких случаях - и из спека тоже.> А моё предположение, что люди тут понимают: сначала на базе спека собирается пакет, при установке
> которого заполняется базанет, не при установке. При сборке. Вы просто не в курсе довольно банальных особенностей технологии.
никакие современные пакетные менеджеры не ориентируются на описанные в spec или debian/* данные, они собирают их самостоятельно, после сборки программы и перед ее упаковкой в архив.
Никакой особой магии нет, используется компот из ldd, grep (не все зависимости у нас разрешает ld - есть еще интерпретируемые языки) и так далее. Его поведением можно управлять, но обычно не нужно.Вот результат всего этого - он, естественно, разный при малейших изменениях сборочной среды - и попадает потом из пакета в rpmdb (для графа нам, естественно, нужна именно она, а не отдельный пакет, поскольку мы хотим видеть зависимости зависимостей).
> Граф хорошо бы строить с учётом имён импортируепмых-экспортируемых функций, а не только лишь
> библиотек.это слишком геморройно (и не поможет для пакета использующего numpy ;-) но у библиотек есть versioning:
libcrypt.so.1(GLIBC_2.2.5)(64bit)
libc.so.6()(64bit)
libc.so.6(GLIBC_2.10)(64bit)
libc.so.6(GLIBC_2.2.5)(64bit)
libc.so.6(GLIBC_2.3.2)(64bit)
и так далее. Как видите, некоторые базовые меры предосторожности предпринимаются, хотя по задумке должно было хватать цифирок после .so, но это немодно и немолодежно.
>[оверквотинг удален]
> никакие современные пакетные менеджеры не ориентируются на описанные в spec или debian/*
> данные, они собирают их самостоятельно, после сборки программы и перед ее
> упаковкой в архив.
> Никакой особой магии нет, используется компот из ldd, grep (не все зависимости
> у нас разрешает ld - есть еще интерпретируемые языки) и
> так далее. Его поведением можно управлять, но обычно не нужно.
> Вот результат всего этого - он, естественно, разный при малейших изменениях сборочной
> среды - и попадает потом из пакета в rpmdb (для графа
> нам, естественно, нужна именно она, а не отдельный пакет, поскольку мы
> хотим видеть зависимости зависимостей).Это всё несущественные мелочи и детали реализации.
>> Граф хорошо бы строить с учётом имён импортируепмых-экспортируемых функций, а не только лишь
>> библиотек.
> это слишком геморройноИ чего такого в ELF принципиально отличного от PE (для которого приходилось решать сходную задачу, при том что нужный функционал из ldd пришлось реализовать самому)?
> (и не поможет для пакета использующего numpy ;-) но
> у библиотек есть versioning:
> libcrypt.so.1(GLIBC_2.2.5)(64bit)
> libc.so.6()(64bit)
> libc.so.6(GLIBC_2.10)(64bit)
> libc.so.6(GLIBC_2.2.5)(64bit)
> libc.so.6(GLIBC_2.3.2)(64bit)
> и так далее. Как видите, некоторые базовые меры предосторожности предпринимаются, хотя
> по задумке должно было хватать цифирок после .so, но это немодно
> и немолодежно.И этот же автор пишет ниже про Gentoo portage...
> Поэтому никакой бутстрэп с нулевой фазы больше невозможен -
> вам нужна полная система с миллионом неведомых хреней,
> иначе прекрасные cmake/ninja/meson не запустятся и не смогут
> собрать /bin/ls.Не настолько пока всё-таки плохо, хотя безумцы и стараются изо всех сил.
По крайней мере на e2k бутстрапиться (начали в 2015) не так уж часто помогали пакеты из предыдущей стабильной ветки (p7, 2013--2015 в активной фазе). Хотя заметил такое, что в перловке количество циклов и неприятных развесистостей заметно подросло между p7 и p8 -- и это в перловке, с питонами и протчая всё было достаточно сильно хуже, чтобы на глаз я различить не брался...
> В лучшем случае можно только научиться воспроизводимо
> пересобирать один отдельный пакет.Да ладно, это теперь тоже немножко модно стало -- всяко не один (и даже не каждый второй, а потолще).
rpmreaper хорошая утилита
> rpmreaper хорошая утилитаСпасибо, интересная штука. Чисто полюбоваться, как люди умеют писать на Сишечке. А так... она опять же сводится к запуску rpm -q (не, я намекаю не на librpm, а на то что информации из БД может оказаться недостаточно).
> исключения необязательных компонентов, таких как документация.все правильно, домохозяйкам не нужна документация.
> > необязательныхДомохозяйкам как раз нужна. А тот, кто уже много лет работает со своим стеком, в документации при решении типовых задач не нуждается. А если что подзабудет — доустановит доку или освежит в памяти через онлайн-документацию. Тем более, что разработчик работает на одном варианте дистрибутива — более полном и рассчитанном на десктоп, а в продакшене крутится совершенно другой вариант — рассчитанный на облака и прочее.
Поэтому можно сказать, что ты сделал полностью противоположный вывод и имеешь ощутимые проблемы с формальной логикой. Жаль, что дистрибутивы обычно не предоставляют formal-logic-docs, тебе бы точно пригодилось.
> Домохозяйкам как раз нужна. А тот, кто уже много лет работает со
> своим стеком, в документации при решении типовых задач не нуждается. Аконечно-конечно, он же ее наизусть уже выучил. Всю-всю, ведь задач у него ровно две - писать отчеты и добавлять "приложения" для деплоя через интуитивно-приятный интерфейс.
> если что подзабудет — доустановит доку или освежит в памяти через
копипасту со стековерфлоу, всегда так работаем.
P.S. изучите на досуге документацию на банальный rpm, пока она еще не выпилена "инициативными сокращателями размера приложений" куда-нибудь подальше в "онлайн". Работничек вы "со своим стеком". Может быть даже найдете свитч --excludedocs - существующий еще с прошлого века. Да, не поверите - вы могли не ставить эту самую "ненужную" вам документацию на свой продакшн из дерьма и палок - еще в 96м.
ну ничего, ничего - сейчас федора о вас позаботится, хотите вы того или нет.
P.P.S. в исходном сообщении вы не заметили огромного тега "сарказм". Тем не менее, спасибо за уточнение, что тем кто много лет работает нажимателем кнопок - документация и тем более не нужна. Сам я что-то не сообразил, в отличие от федоро-разработчиков.
> копипасту со стековерфлоу, всегда так работаемВот в чем твоя претензия? И к кому? Если, по твоей "логике", разрабы уже сейчас всё изучают в stack overflow, то, по твоей же "логике", эти маны все равно получаются не нужны. Ну а моя позиция проста: маны нужны. Но не всем. Кому нужны, пусть доустановят.
Там, наверное, не про маны, а про то, что в /usr/share/docs
кругом контейнеризация, и в правде зачем хлам всякий тащить
> P.S. изучите на досуге документацию на банальный rpm, пока она еще не выпилена "инициативными
> сокращателями размера приложений" куда-нибудь подальше в "онлайн". Работничек вы "со своим
> стеком". Может быть даже найдете свитч --excludedocs - существующий еще с прошлого века. Да, не
> поверите - вы могли не ставить эту самую "ненужную" вам документацию на свой продакшн из дерьма и > палок - еще в 96м.И как мне поможет --excludedocs, если пакеты устанавливаю при помощи утилиты yum?
тогда хуже - придется прочитать документацию еще и на yum.впрочем, вместо этого можно по прежнему воспользоваться stackoverflow - наверняка кто-то за вас уже написал такой плагин, и можно никакой документации не читать. Когда-то чуть ли не в анаконде была подобная опция, к счастью, по-моему, выпиленная.
(если что - учтите, что никакой опции "поставить только то, что от большого ума понаэкономили, обратно" не предусмотрено)
> Домохозяйкам как раз нужна.Давайте будем честными - кто в последнее время делал man packagename? Это на опеннетике даже домохозяйки его используют, а в реальном мире даже у разработчиков есть гуй с браузером, где он забивает в гугл "как рекурсивно найти файл ponyporn.bmp в хоум".
> кто в последнее время делал man packagename?Регулярно, а что?
+1 к регулярности.
Это сильно быстрее в ряде случаев, чем искать в Интернете ман под нужную версию пакета.
На опеннетик захожу изредка, поржать над идиотами, так что даже постоянным читателем не являюсь.
> Домохозяйкам как раз нужнаДа ладно. Вы пользуетеь документацией к пульту телевизора? )
> освежит в памяти через онлайн-документациюДа ничего он не освежит: проходит время, пыль под ковром^W^W^W контейнер оказывается невозможным ни обновить, ни убрать, работает какое-то старьё; в онлайне же — только документация от распоследней модной версии, а документация от той, что стоит, была вынесена в пакет, который уже исчез со всех зеркал за давностью лет и непопулярностью в виду наличия Великого Онлайна.
> Размер планируется сокращать за счёт прекращения установки излишних зависимостей и исключения необязательных компонентов, таких как документация.Я вот как раз когда первый раз установил линь - плевался на то, что там нет вменяемой документации.
Да и винда этим грешит тоже.
И это в те годы, когда картинка модемом скачивалась пол-минуты.
> Я вот как раз когда первый раз установил линь - плевался на
> то, что там нет вменяемой документации.не переживайте, теперь ее точно не будет
> Да и винда этим грешит тоже.
винда первая начала - еще лет десять тому. Особенно классно это выглядит сейчас, когда большая часть линков "подробнее" из хелпа семерки ведет на "file not found".
Разумеется, лап4атые не могли не подхватить и эту глупость, что-что, такое за ними не залеживается.
Домохозяйкам нужна как инструкция так и документация.Отсутствие документации либо недоработка девелоперов, либо мейнтейнеров, либо продукт сделан настолько очевидно и понятно, что простите меня даже бомж без всего на помойке сможет этим воспользоваться.
Документация это минимальное и необходимое зло которое нужно делать, и сделать так, чтобы "[больной на голову человек] с подворотни" смог её прочесть, понять и не [сломать всё].
Всё правильно сделали. Зачем деплоить документацию? Она должна быть у разработчиков, а не на проде.
да еще в контейнере :)пс: документацию не иметь нужно, а читать :)
Внутри контейнера точно не нужна
Странные люди..весь мир переходит на снапы... один пакет-один дистриб...
Хочешь секрет открою? Только никому не говори. Ты - не весь мир.
> Странные люди..весь мир переходит на снапы... один пакет-один дистриб...все норм, они тоже пилят свою прекрасную atomichost или как там она в очередной раз называется.
пока, правда, кроме опилок, ничего не произвелось, но результат не за горами.
А мир и не знал...
> весь мир переходит на снапыЭто на те, которые полноценно только на убунте работают?
ты хочешь получить очередную винду с другим гуем? а нет погоди уже много тем оформления под семерочку и 10. забудьте о снапах как о страшном сне лучше. иначе в страшном сне окажутся все вместе с вами. или появятся следом linux-like)) потому как снапы это вред. 1 - 2 пакета куда ни шло, но все? разделяемые библиотеки нафига делали если сразу могли так делать. вы батенька нам назад в будущее не подсовывайте))
Удачи. Нового в этом нет, т.к. цель не сделать аналог FreeBSD Ports / Gentoo Portage.
FreeBSD Ports - самая нелепая штука во всем мире БСД.Бессмысленные перекомпиляции всего (за свой счет), брокен порты (сюрпрайзззчувак, неполуциссаааа...), ад с пакетами поставленными мимо портов (надо следить, следить и следить за всем вручную как в 90-х).
> следить за всем вручную как в 90-хДа уж, я в то время мелкий был, но знал каждый файл в Windows 95 в лицо, в XP мог найти трояна пройдясь по папкам. А сейчас в 10ке это нереально в принципе, зато ныне в сабже беззаботно знаю, что всё лежит на своём месте и по полочкам.
Когда вирусы распространялись через самозаписк на флоппи диски. Я себя комфортней чувствовал чем сейчас с отключенным интернетом. Раньше диски были мягче...
>FreeBSD Ports - самая нелепая штука во всем мире БСД.предложи лучшее решение за те же деньги.
>Бессмысленные перекомпиляции всего (за свой счет)
да, иметь на сервере предкомпилированный traceroute, слинкованный с gtk,
это просто необходимая вещь.
$ ldd /usr/bin/mtr
linux-vdso.so.1 (0x00007fff34989000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f91b6512000)
libncurses.so.5 => /lib/x86_64-linux-gnu/libncurses.so.5 (0x00007f91b62ed000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007f91b60c3000)
libgtk-x11-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 (0x00007f91b5a75000)
libgdk-x11-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0 (0x00007f91b57bf000)
libatk-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libatk-1.0.so.0 (0x00007f91b5598000)
libgio-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0 (0x00007f91b521e000)
libpangoft2-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libpangoft2-1.0.so.0 (0x00007f91b5008000)
libpangocairo-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libpangocairo-1.0.so.0 (0x00007f91b4dfb000)
libgdk_pixbuf-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0 (0x00007f91b4bd9000)
libcairo.so.2 => /usr/lib/x86_64-linux-gnu/libcairo.so.2 (0x00007f91b48bf000)
libpango-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0 (0x00007f91b4671000)
libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007f91b43c7000)
libfontconfig.so.1 => /usr/lib/x86_64-linux-gnu/libfontconfig.so.1 (0x00007f91b418a000)
libgobject-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 (0x00007f91b3f37000)
libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007f91b3c28000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f91b3a0b000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f91b3660000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f91b3449000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f91b3245000)
libgmodule-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0 (0x00007f91b3041000)
libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f91b2cfe000)
libXcomposite.so.1 => /usr/lib/x86_64-linux-gnu/libXcomposite.so.1 (0x00007f91b2afb000)
libXdamage.so.1 => /usr/lib/x86_64-linux-gnu/libXdamage.so.1 (0x00007f91b28f8000)
libXfixes.so.3 => /usr/lib/x86_64-linux-gnu/libXfixes.so.3 (0x00007f91b26f2000)
libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1 (0x00007f91b24e8000)
libXinerama.so.1 => /usr/lib/x86_64-linux-gnu/libXinerama.so.1 (0x00007f91b22e5000)
libXi.so.6 => /usr/lib/x86_64-linux-gnu/libXi.so.6 (0x00007f91b20d5000)
libXrandr.so.2 => /usr/lib/x86_64-linux-gnu/libXrandr.so.2 (0x00007f91b1ecb000)
libXcursor.so.1 => /usr/lib/x86_64-linux-gnu/libXcursor.so.1 (0x00007f91b1cc0000)
libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007f91b1aae000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f91b1893000)
libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f91b166e000)
libgthread-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgthread-2.0.so.0 (0x00007f91b146c000)
libharfbuzz.so.0 => /usr/lib/x86_64-linux-gnu/libharfbuzz.so.0 (0x00007f91b1215000)
libpng12.so.0 => /lib/x86_64-linux-gnu/libpng12.so.0 (0x00007f91b0fee000)
libpixman-1.so.0 => /usr/lib/x86_64-linux-gnu/libpixman-1.so.0 (0x00007f91b0d41000)
libxcb-shm.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-shm.so.0 (0x00007f91b0b3d000)
libxcb-render.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-render.so.0 (0x00007f91b0933000)
libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f91b0711000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f91b0509000)
libthai.so.0 => /usr/lib/x86_64-linux-gnu/libthai.so.0 (0x00007f91b0300000)
libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007f91b00d7000)
libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007f91afecf000)
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f91afc61000)
/lib64/ld-linux-x86-64.so.2 (0x00007f91b6813000)
libgraphite2.so.3 => /usr/lib/x86_64-linux-gnu/libgraphite2.so.3 (0x00007f91afa3b000)
libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f91af837000)
libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f91af632000)
libdatrie.so.1 => /usr/lib/x86_64-linux-gnu/libdatrie.so.1 (0x00007f91af42a000)
остальное в твоем спиче вопросы компетенций.халявы не бывает.
>>FreeBSD Ports - самая нелепая штука во всем мире БСД.
> предложи лучшее решение за те же деньги.gentoo portage разьве не выглядит (хотя бы - выглядит) - лучше? И синтаксисом, и юзабилити...
насчет денег у freebsd foundation спросите, чего она там sponsored, лекцию о гендерном равенстве или о правах альтернативно-одаренных.
> да, иметь на сервере предкомпилированный traceroute, слинкованный с gtk,
бл... ну я ж ем!
зачем вы мне ЭТО показали? :-(
я как любитель bsd скажу что gentoo выглядит как ос без гейства (минимально) по сравнению с мейнстримом: Ubuntu итдРаньше для оперирования портами была россыпь утилит через нижнее подчеркивание. Сейчас одна которая выглядит удобно. Для 98% хватает pkg ins portname, после нажать "y" (или "yes" как утилита)
стабильность нужна, стабильность!!!
Тебя так стебанули версией под X11. На сервере достаточно поставить mtr-nox11:$ ldd /usr/local/sbin/mtr
libncurses.so.8 => ..
libm.so.5 => ..
libc.so.7 => ..
$
> Тебя так стебанули версией под X11. На сервере достаточно поставить mtr-nox11:судя по /usr/bin - это линукс, и у них ее нет. Достаточно просто пересобрать deb/rpm/чтотам как тебе нравится, поправив по дороге в пяти местах - и вот, чудо экономии размера приложений достигнуто!
а во фре меня и traceroute устроит, он пока в base.
> Тебя так стебанули версией под X11. На сервере достаточно поставить mtr-nox11:
>> судя по /usr/bin - это линукс, и у них ее нетЕсть. mtr-tiny называется.
Н-да. Рассмотрим mtr(8) здорового проекта:$ ldd /usr/bin/mtrА Вы, молодой человек, забыли ls -l туда же показать и немножко поразмыслить над полученным выводом, сдаётся мне.
ldd: ошибка: у вас нет разрешения на чтение `/usr/bin/mtr'
# ldd /usr/bin/mtr
linux-vdso.so.1 (0x00007ffe4ed76000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f81a83fe000)
libm.so.6 => /lib64/libm.so.6 (0x00007f81a806b000)
libncurses.so.5 => /usr/lib64/libncurses.so.5 (0x00007f81a7e48000)
libtinfo.so.5 => /lib64/libtinfo.so.5 (0x00007f81a7c1e000)
libc.so.6 => /lib64/libc.so.6 (0x00007f81a7861000)
/lib64/ld-linux-x86-64.so.2 (0x00007f81a8615000)
libgpm.so.1 => /usr/lib64/libgpm.so.1 (0x00007f81a765a000)
# control mtr
netadmin
pkg add - Install a package from either a local source or a remote one
или pkg ins вам скачает любой бинарь без компиляции + зависимости
что значит брокен? вы ставите через portmaster или используя makeЯ считаю ты man не смог осилить. Или выдачу не смог расшифровать. Для этого есть туча вспомогательных утилит https://www.freebsd.org/ports/ports-mgmt.html
> pkg add - Install a package from either a local source orречь, вообще-то, шла о портах (позволяющих ставить так и то, что именно тебе хочется - с доками, без доков, с вкомпиленным hangman вместо доков), не о pkg
ну так ports-mgmt/portmaster (Есть новее альтернативы)
Скармиваешь ему имя нужного порта, он из дерева берет make сидишь выбираешь любые опции. Он в зависимости от опций тащит зависимости, для которых опять make + опции.
Далее portmaster регистрирует все что ты накомпилял в pkg.
Ты можешь построить любую конфигурацию бинари с зависимостями от (портов) и наоборот. Главное что бы все в pkg было зарегистрированно.
Есть из dragonflyBSD тул для этого ports-mgmt/synth/. Есть гуевые. Целый раздел этих ... ports-mgmt ...
> Далее portmaster регистрирует все что ты накомпилял в pkg.Если б он опять научился билдзависимости пакетом ставить, совсем хорошо было бы. А то собирать несколько часов какой-нить раст или llvm8 - увольте.
> Главное что бы все в pkg было зарегистрированно.
единожды:
echo "local: {
url : "file:///usr/ports/packages/",
enabled : yes,
priority : 5
}
" >> /usr/local/etc/pkg/repos/local.conf
Потом достаточно:
make package clean
<список>
...
pkg repo /usr/ports/packages
pkg update
pkg upg
# PROFIT!!
отличие от make install (который тоже регистрирует пакет) - в мета-информации пакета присутствует репа, да и разница в опциях сборки или минорые обновления теперь не норовят заменить эту кастомную версию на "правильную" из официальной репы.
Когда нужно поддерживать 3½ кастомных пакета, велосипедится только влет.А вот как раз большая часть не обсолетных тулз из раздела ports-mgmt … как бы это мягко сказать …
оctopkg заброшен, тот же поиск так и не доделан, баг с неправильными размерами пакетов (все что больше 1МБ показывает как 0 byte) так и висит.poudriere-заменитель на Ada (synth) - сколько не тыкал, так и не завел толком (а больше пары часов мне втыкать - так овчинка выделки не стоит).
Неплох был в качестве гуя для pkg старый AppCafe, c его надстройками в виде кастомного индекса с описаниями и скриншотами от пользователей/мейненеров для самых распространенных гуепрограмм и прочих … сломали^W улучшили, теперь ни пакета в фряшной репе, ни вики, ни пользователей. И даже ссылка из дока труОС на https://sysadm.us/handbook/client/sysadmclient.html?#appcafe мертва.
Чем вы сейчас пользуетесь? Или как выглядит хороший менеджер портов?
/* Я планирую сделать репозиторий поверх торрента (с поддержкой версий для файлов. Промежуточный вариант между git и полным обновлением). Будет отдельно раздача каталог (список ссылок) всего и отдельно раздачи для всех репозиториев */
> Чем вы сейчас пользуетесь?Если речь именно про порты, то - ручками.
Обновил пакеты раз в месяц или по pkg audit, глянул в
pkg version -vRL=|grep -v "orpha\|succe"
и pkg check -dВсего пакетов чуть больше двух дюжин, где-то треть "залочены", т.к. просто или старые версии софта или кастомные сборки достаточно старого софта или вообще "dummy" пакеты (qt5-doc, qt5-examples, gvfs) поэтому обычно больше 3-5 обновлений не прилетает (или же там вообще ломаться нечему).
> Или как выглядит хороший менеджер портов?
Тот же portmaster, только чтобы умел брать список кастомных, обновлять все runtime и билд зависимости из пакетов и пересобирать только список.
Оно-то в принципе велосипедится достаточно легко:
make build-depends-list 2>&1|awk '{if (NF>1) {gsub("\"","",$2);print $2} else {print $1}}'|sed 's/\/usr\/ports\///g' | теперь делаем pkg install и pkg upgrade с этим списком,
кабы не всякие граничные случаи - например, если в билд/рантайм зависимости где-то будет другой кастомный пакет, то начинать следует с него, иначе будет зависимость от старой версии.
Т.е. по уму, следует построить дерево/граф зависимостей всех кастомных пакетов и уже танцевать оттуда - но делать такое на шелле как-то совершенно не хочется.
> DebianВот уж нафиг. Заходишь на хост с дебом - ни манов, ни пинга, ни вима. Красота мля!
> Заходишь на хост с дебом - ни манов, ни пинга, ни вимаТоже правишь IИDEX.PHP через ftp и дебажишь на бою через var_dump? Вся документация должна быть у тебя в голове, если ее там нет — в твоей локальной тачке. Если ее там нет — в интернете. А на боевой тачке документация ни к чему.
>А на боевой тачке документация ни к чему.глупости.
наличие man и документированных примеров, а так же исходных текстов очень и очень помогает в поиске проблем и отладке.
естественно, надо для начала знать язык оригинала и соотвествующие знания-опыт, желательно и в разработке.
если ни того, ни другого в голове, тоды ой.
> очень помогает в поиске проблем и отладкеНикто не спорит. Вопрос лишь -- зачем делать это на боевой тачке, а не на своей?
>> очень помогает в поиске проблем и отладке
> Никто не спорит. Вопрос лишь -- зачем делать это на боевой тачке,
> а не на своей?затем что на своей вполне может быть Рач, для поиграть с сырыми технологиями. Или вовсе винда, для поработать.
И документация у них, внезапно, либо не от тех версий, либо вообще не о том.Но ты продолжай нам рассказывать как мы все делаем неправильно, и экономить байтики на продакшне, а то ж ему не хватает.
> на своей вполне может быть Рач, для поигратьВ серьезных организациях регламентируется, какой дистрибутив должен ставить разработчик на свою рабочую тачку. Не уверен, как можно положительным образом охарактеризовать того, кто прямо в процессе работы на боевой машине будет восполнять свои пробелы, которые он должен был восполнить еще до того, как соответствующий отдел выдаст ему доступы к этой самой боевой тачке.
> В серьезных организациях регламентируется, какой дистрибутив должен ставить разработчик
> на свою рабочую тачку.Проблема в том, что дистрибутив этот обычно — macOS.
Единственный способ убедиться что на проде будет всё работать так же как у разраба - поставать абсолютно одинаковый дистр. С одинаковыми версиями софта. И одинаковыми манами соответственно.
В серьёзных организациях пора бы об этом знать
и на продакшн отправляется какой-нибудь vscode вместе с брейнфако...простите,brainstorm ?
Иначе ничего работать не будет.А если ненароком разработка идет не наколенного сайтика а софта для суперкомпьютера - каждому разработчику выдают по суперкомпьютеру, как же ж еще?!
Я вам страшную тайну открою, но у разработчика таки мак, и ему нахрен на нем не надо рабочую среду - его мак все равно не потянет даже тестовый запуск урезанного кластера.
У него есть сборочный сервер, и сервера тестирования. Но нет, мы совершенно не хотим всю используемую для сборки и отладки ботву тащить в прод - он лопнет, или его поломают.Эту проблему кое-как научились решать с помощью контейнеров, и, надо сказать, это почти единственное место, где они действительно оказались полезны.
Очень часто бывают ситуации, когда ты на выезде у заказчика чего-то крутишь, или ставишь, или обновляешь...А интернетов нет, потому что ты в аппаратной в подвале какого-нибудь центро- или просто банка, и ни телефона, ни ноутбука с собой не пронести. У меня такое с завидной периодичностью.
И, в общем-то, хочется иметь маны, и прочие мурзилки под руками, голова не резиновая.
Вы что, ногами к серверу ходите??
нет, конечно же тебя центробанк с радостью пустит в свою сеть и предоставит пароли от всего.Приехал аутсорсер что-то починять в конкретной коробке с конкретным функционалом на ней - вот коробка, вот консоль от нее, вот трое сопровождающих, смотрят чтоб ты ничего лишнего в этой стойке не трогал.
И много в каждой стране центробанков?
не на боевой тачке, а на боевом контейнере
> не на боевой тачке, а на боевом контейнерето же самое. В контейнере зачем-то оказалась пресловутая федора - а на хосте дебиан. Вот и разбирайся как хочешь, какие там параметры у ее специфических утилит и актуальных для нее версий, удобно, чо - быстренько поставишь рядом виртуалочку с федорой, чисто маны почитать, ага.
linups:~> du -hs /usr/share/{man,doc}
37M /usr/share/man
40M /usr/share/docохренеть эти выпиливальщики наэкономили на размере контейнера.
Я правильно понимаю, что ты вначале разворачиваешь федору, а потом, толком не изучая ее, пытаешься с ней совладать? Чем ж ты тогда лучше стэк-оверфлоущиков? Я больше за классический подход: вначале выделяешь время на изучение платформы, затем прикидываешь, подходит ли она для решения твоих задач, а затем уже ее применяешь.
> Я правильно понимаю, что ты вначале разворачиваешь федоруя могу развернуть что угодно, если мне покажется, что под текущую задачу оно подходит лучше всего. Единственное преимущество модной-современной контейнерной среды, как бы. (раньше-то vm приходилось)
Это совершенно не означает что я "держу в голове" всю ее документацию.> изучая ее, пытаешься с ней совладать? Чем ж ты тогда лучше стэк-оверфлоущиков?
я хуже - именно тем, что без острой необходимости страюсь не копипастить из вопросов, а выяснять, что за нёх и как она работает. Документация для этого мне, внезапно, нужна, и у меня есть волшебная команда, выпиливающая убунтину и дебиановскую "оптимизацию" напрочь - на, скопипасти:
sed -i -Ee /excl/d /etc/dpkg/dpkg.cfg.d/excludes
sed -i -Ee s/incl/excl/ /etc/dpkg/dpkg.cfg.d/excludes
(вторая строчка для тех, кто заглянул таки в файлик ;-) я тоже люблю ненужную оптимизацию)и мне совершенно незачем гадать, что за контейнер и контейнер ли у меня в текущей сессии и переключаться куда-то еще, чтобы вспомнить стопиццотый параметр у первый и последний раз понадобившейся команды.
> Я больше за классический подход: вначале выделяешь время на изучение
> платформы, затем прикидываешь, подходит ли она для решения твоих задач, атебе уже там выше написали - современному "разработчику" неположено ничего изучать на работе, даром тратить ценное оплачиваемое время и ресурс казенной техники - давай обезьянка, лабай таски, еще пять до вечера чтоб закрыл, дидлайн не ждет!
Самообразованием в отпуске будешь заниматься - у тебя ведь нет и не должно быть другой жизни, кроме твоей прекрасной работы, и ты все-все знаешь, что тебе на ней может понадобиться уже прямо сейчас, иначе компания в тебе и не нуждается, вон очередь с феноменальной памятью у отдела кадров стоит.и ведь не менеджер же это написал.
А я так думаю что вы отдельно компилируете пакеты без man а затем с man
Всегда можно переехать своим контейнером на Alpine - всего 5 метров весит.
не всегда. Иногда в контейнере нужна операционная система, а не ld-linux.so
Там есть пакетный менеджер, можно доставить что надо. Можно свой образ сделать.
> Там есть пакетный менеджер, можно доставить что надо. Можно свой образ сделать.там нет glibc, и в общем-то чего ни хватишься, ничего нет - потому что оно специально предназначено для запуска единичных самодостаточных программ,наиболее близко к пресловутому freebsd'шному jail - что и хорошо, когда программа действительно самодостаточная, как какой-нибудь nginx, а с внешним миром общается только и исключительно через сокеты.
А когда таки нужна операционная система - свой образ сделать конечно можно, но низачем не нужно, как и собирать потом глюки из-за того что все делал сам, но не из тех деталей, с которыми работал автор нужного тебе проекта.
Проще поставить образ на базе того же debian, где все уже есть.
А если приспичило обмазаться свеженьким - то и федора нелишней будет.
За всю свою историю работы с докером (не сильно длинную, ибо докер сам не сильно стар) только один раз наткнулся на аппликуху, которая не жила с musl (зато какая! docker-compose, хе-хе).
там не то чтобы совсем жить не будет - такое довольно быстро найдут и исправят, а будет как-нибудь противно глючить по тихому- память жрать, или дескрипторы, или просто раз в день выдавать sigsegv. Не напасешься носовых платков на каждый чих.
А экономия - грошовая, раз уж все равно понадобилась операционная система целиком.
77 метров в контейнере.
контейнеров 999.9
> 77 метров в контейнере.это не контейнер, это как раз полноценная рабочая операционка, в которой понаставленно сам уже давно не знаю, что.
В контейнере будет аж семь.> контейнеров 999.9
и? У меня вон контейнер занимает 800 мег.
Тебе на фоне 750G интересна экономия "целых" 7 ценой создания себе геморроя?Причем я мог бы уменьшить эти 800, отказавшись от части содержимого, нужного только для тестирования, но...опаньки, весь смысл контейнера именно в том, чтобы на prod гарантированно уезжало именно то, с чем мы тестировались.
77 мегабайт, 7 мегабайт, 800 мегабайт 750 гигабайт
ты с размерностью определись для начала. на бумажке записывай, что ли..
> 77 мегабайт, 7 мегабайт, 800 мегабайт 750 гигабайтдля бестолковых, медленно, следи за руками: 77 я тебе показал с рабочей системы, где понаставлено непойми чего, давно забыто зачем. Можно и еще больше, но уже придется очень стараться.
7 будет в контейнере, где стоит пусть и сложный, с мильеном зависимостей, но один проект. У попавшего мне сейчас под руку контейнера полный размер - 800, и это далеко не предел.
Когда у тебя таких контейнеров будет под тысячу - они займут примерно 750G, если даже забыть о том, что вообще-то контейнер не занимает ничего, а образ один на одну физическую систему и по прежнему занимает на ней 800 мегабайт.
Но даже если ты умудришься потратить на них 750G - размер всех копий ужасно мешающей тебе документации при этом будет чуть меньше 7G. Которых на этом фоне снова никто не разглядит даже в микроскоп.> ты с размерностью определись для начала. на бумажке записывай, что ли..
ты записал?
Все слова понятны?Учись читать, малыш, и понимать, что тебе пишут - а то так и будешь на манах экономить.
> но один проект. У попавшего мне сейчас под руку контейнера полный
> размер - 800, и это далеко не предел.Воот!
> Когда у тебя таких контейнеров будет под тысячу - они займут примерно
> 750G,Воооот!
> если даже забыть о том, что вообще-то контейнер не занимает
> ничего, а образ один на одну физическую систему и по прежнему
> занимает на ней 800 мегабайт.А здесь ты начал быстро манипулировать грязными руками.
Тысяча контейнеров, каждый из которых отличается от других. Ибо! в этом суть контейнера тащить с собой все зависимости необходимые проекту, не замусоривая основную систему лишними зависимостями и не влияя на работу других контейнеров несовместимыми конфликтующими либами.
> А здесь ты начал быстро манипулировать грязными руками.здесь кто-то просто, похоже, не в теме.
во-первых, если у тебя в проекте тысяча контейнеров, каждый из которых отличается - тебе крупно неповезло полюбому, моргни, если тебя удерживают силой.
У большинства смертных речь о тысяче заходит когда они как раз совершенно одинаковые и создаются по мере необходимости каким-нибудь k8s, не к ночи полярной будь помянут.
Занимают таки 800 на каждый физический хост, а не на каждый контейнер.
(в реальности, вероятно, их будет пять-десять разных типов)Во-вторых, контейнеры и их образы у нас - layered, и контейнер, отличающийся от этого каким-нибудь модным и нужным питоновским модулем - будет занимать по прежнему 0, плюс 25 килобайт того питоновского модуля в образе, построенном поверх предыдущего - снова один раз на всю тысячу, если она уместилась в одном хосте.
А общестистемные детали, вестимо, ставятся в самый нижний тазик.
>> А здесь ты начал быстро манипулировать грязными руками.
> здесь кто-то просто, похоже, не в теме.
> во-первых, если у тебя в проекте тысяча контейнеров, каждый из которых отличается
> - тебе крупно неповезло полюбому, моргни, если тебя удерживают силой.моргаю.
У меня в живом проекте 24 _отличающихся_ контейнера. Примерно 70 гигов.
ЧСХ^W Что очень характерно, когда разработчики приносят в контейнере (с либами актуальными на сегодняшний день) новый релиз своего восхитительного продукта, почему то нельзя гасить ни старый (с либами некоторой давности) ни позапрошлый (с прошлогодними либами). "без них ниработает".
Методы физического воздействия на разработчиков запрещены внутренним распорядком компании. "Светлые головы пиз^W бить нельзя!".
> У меня в живом проекте 24 _отличающихся_ контейнера. Примерно 70 гигов.ну это всего 24x на... ну вот специально для тебя пересобрал один чисто поржать - 9 мегабайт разницы.
заметишь ты 220 мегабайт на фоне 70 гигов, даже если эти 24 отличаются вообще всем, включая FROM scratch, а не один поверх другого и все вместе - поверх ubuntu:latest ?> Методы физического воздействия на разработчиков запрещены внутренним распорядком компании.
> "Светлые головы пиз^W бить нельзя!".так соблюдай распорядок - лупи по хребтине! Я, если чо, осенью вроде в тайланд собрался- могу напиленного бамбука подвезти, небольшую охапочку - килограмм пять у меня наверное останутся в пределах лимита. Там, правда, дурная А/К, "не длиннее метр-20", но для офисного применения сойдет.
> linups:~> du -hs /usr/share/{man,doc}
> 37M /usr/share/man
> 40M /usr/share/docdu -hs /lib/firmware/
?-)
> du -hs /lib/firmware/Если бы не в контейнере -- то зачем же вот так серпом-то сразу?..
> документация должна быть у тебя в голове, если ее там нетныкаемся, ныкаемся пацаны - среди нас опять тот мальчик - с феноменальной памятью!
Потом у таких вояк с "боевыми тачками" датчики угловых скоростей оказываются вбиты кверх ногами, потому что стрелочку нарисовать они считают зашкваром, потому что "всё должно быть в голове", а меры для минимизации вероятности ошибок - у них это "ни к чему", настоящие солдаты ведь не ошибаются.
> боевой тачкеХерачке. Системы должны быть пригодными к использованию независимо от уровня среды и наличия автоматизированного управления конфигурацией, а таких экспертов как ты надо на курсы повышения квалификации отправлять.
> Вот уж нафиг. Заходишь на хост с дебом - ни манов, ни
> пинга, ни вима. Красота мля!ну да, то ли дело на хост с rhel - и пинг, и вим! Манов, правда, нет.
(их там реально нет, пока явно не ставишь, домох...админам с феноменальной памятью они ж не нужны)
>> Вот уж нафиг. Заходишь на хост с дебом - ни манов, ни
>> пинга, ни вима. Красота мля!
> ну да, то ли дело на хост с rhel - и пинг,
> и вим! Манов, правда, нет.И traceroute нет. (А вот что взамен приходит с ойпиутилсом, помнят только феноменальные ребята и изрядно избитые граблями.)
> И traceroute нет.это о нас так заботятся - он-то точно разработан в ливерморской лаборатории, всем нам на погибель!
(тьфу, простите, опять ненароком в тред о победе над гитхабом заглянул)
Наконец-то, додумались... Это в Федорке раздражает, когда ставишь какую-то прогу весом 20Mb а с ней ставится ещё 100Mb зависимостей, причём половина из них очевидно нафиг не нужна...
Пример в студию!
> Пример в студию!не надо! Мне уже mtr хватило!
dnf install kdenlive...
Install 105 PackagesTotal download size: 122 M
Installed size: 855 M
Ну извините, kdenlive действительно нужна куча qt5-* и kf5-*, помимо мультимедийщины.Хотя на локалхосте (с почти всей мультимедийщиной, частью qt5-*, без kf5-* вообще) это выглядит как-то так:
Необходимо получить 0B/45,8MB архивов.
После распаковки потребуется дополнительно 258MB дискового пространства.
Скорей бы i686 закопали.Возможно, в Fedora 32 дропнут процессы без avx2. Ляпота.
Процессоры //fix
>Для сокращения зависимостей планируется проанализировать дерево зависимостей для типовых и часто используемых применениймысль хорошая, только нужно это делать не раз в десять лет, а где-то раз на квартал
Даже раз в год-два уже неплохо, на самом деле.
Ещё б били по рукам за статическую линковку, жабу и прочие гадости. Если бинапный покет занимает более 50М - это уже повод задуматься. (да, я в курсе про хромус и дрова нвидиа).
напишите ваши представления - какой будет федора через 25 летхоть посмеемся потом
> напишите ваши представления - какой будет федора через 25 летне будет никакой.
> хоть посмеемся потомну-ну...
>не будет никакой.Это с чего бы?
>>не будет никакой.
> Это с чего бы?с такими разработчиками? Ты чего-то другого ждешь?
А, ну да, еще ж могут вмешаться рептилоиды и ввести, наконец, прямое правление.
Целая команда для
> исключения необязательных компонентов, таких как документация.Видимо пришло время осваивать бюджеты ИБМ
Будет как на IBM i. Хочешь научится работать на IBM i иди на курсы один курс 1000 долларов. А чтобы получить сертификат таких курсов надо с десяток по разным направлениям и на разные сертификаты по разному. Потом проходишь платное тестирование тебе дают сертификат если вдруг пройдешь.IBM i ты нигде сам не скачаешь и нигде сам поиграться не сможешь. Да даже загуглить не сможешь. Да даже работодателя на открытом рынке не сможешь найти.
Поэтому если какая-то корпорация вдруг внедряет IBM i. В контракте обычно включено обучение существующего персонала либо аутсорсинг чуть ли не самого IBM. И все по ценам кратным 10 млн руб.
Вот к чему ведет Линукс ваш ИБМ.
это ж бывшая s/400? Ну так она реально ни на что непохожа, ей действительно надо учиться, с нуля.И кой смысл ее скачать, если б и было откуда, коли она все равно только на специальной железяке ценой как самолет работает?
hands on preview через браузер в браузере в браузере - полагаю, вполне можно выклянчить, толку от него, правда, ноль.Правда, врали-то, врали, что там zero(brain) administration, и она сама себя администрит, да еще админу за кофеем бегает.
Если IBM таки приложит руку к редхату и приделает в него smitty, уже за это можно всё простить.)))
Конечно приделают назовут AIX и запросят с тебя столько денег что мало не покажется.
> Конечно приделают назовут AIX и запросят с тебя столько денег что мало
> не покажется.так у нас вроде, это, уже есть один? И его эмулятор в i, кстати, тоже (надо уточнить в соседнем отделе - мы его пообещали, или уже на самом деле запилили, или уже запилили, а потом задепрекейтили, минуточку, оставайтесь на линии... biiip... bip bip bip
Ви так плачете будто этих IBM Power Systems можно купить занедорого. Есть мнение, и не только мое, шо сами вы себе такой ништяк не купите, а на предприятие- такое привезут только интеграторы. а там уже совсем другие суммы. на фоне которых ваши слезы о 1000$- просто насмех...
И что если у ИБМ на этом бизнес с чего бы им не сделать тоже самое из Линукса. Будешь записываться в очередь на курсы по системд и то ничего не поймешь. А федору будут только в лампочках использовать.
systemd enable kde
systemd enable firefox
systemd enable firefox-plugins
systemd enable firefox-search
systemd enable GCC
systemd enable wget
systemd search firefox-search как установить man
systemd найдено 123137 ссылок
1. Man-страницы в Linux. Как пользоваться. Установка. Linux статьи
2. Как установить man-страницы на centos? Flip Linux
3. Как сделать man-страницу для своей программы - MNorin.com
4. Нужно скомпилировать ...
systemd search firefox-search get(4) как установить man
systemd wget -gcc -sudo man.tar.gz
systemd GCC -compile -sudo man.tar.gz
systemd install man
systemd man runtime
лучше бы глибц на мусл заменили вместо удаления манов.
Айбием доводит опенсорс до такого состояния что хочещь не хочешь покупай подпсику на рхел.
Подсыпку или присыпку?
Сто мегабайт - это норма для интернета вещей? Управляемый выключатель для лампочки будет на железке с прошивкой в сто мегабайт? Они там вконец упоролись?
так ведь в меньше мы нашу новейшую разработку на electron никак уместить не можем... зато смотрите - теперь есть пятый режим мигания!
Управляемый выключатель для лампочки, скорее всего, будет даже не с линуксом, и там 100 МБ будет подавно не нужно. А вот IoT gateway для централизации управления выключателями в доме вполне будет на нем. Или что-то сильно более функциональное, нежели выключатель, например, IP-камера.
Выключатели на МК с rtos или на nodeMCU. там линуксы не нужны.
А вот микроволновки и холодильники с распознаванием голосовых команд могут позволить сотни мегабайт хранилища.
Это для тех, кто туда (зачем-то) вкорячивает полноценную ось. И вы таки наверное догадываетесь, зачем? Так быстрее и дешевле. Примерно по той же причине, что в демо-киоске стоит полноценный pc, только ради того, чтобы крутить видосик. Спецы по микроэлектронике не дешёвые, да и их не стало больше. А количество заказчиков увеличилось раз 100, если не в тысячи.
Хотите полного контроля над зависимостями и размером - используйте Nix.
> рассмотрение предложения по прекращению формирования основных
> репозиториев для архитектуры i686Опеннет скрестил пальцы
Пистон пусть выкосят из своих yum
libc бы еще выкосить отовсюду
Лучше сделайте что-нибудь с netinstall в центосе. 600мб без пакетов вообще - это ппц
Чего не делают лишь бы не улучшать компилятор Сишный. Давно пора уже отказаться от autotools (сразу +10 минут к пересборке). Кешировать хедеры (x2-x10 к сборке). Компилировать в tmpfs (x10- x100 времени сборки). Вот и решение всех проблем, нет они все бинари пакуют и ставят пакуют и ставят. Прям не поймут что это путь в никуда.
А зачем увеличивать время сборки?
>отказаться от autotools (сразу +10 минут к пересборке). \И не надейся - bootstrap никто не отменял