Разработчик ПО не знает тонкостей дистрибутива, не потому что криворук, а потому что дистрибутив очень много и помимо сделанных по одним лекалам (различные ...-based дистрибутивы) есть очень уж много таких что авторы продвигают какой-то новый подход (как то всякие "атомарно обновляемые", "свой формат пакетов", "все прикладное в snap" и 100500 других идей, о которых я даже пока не догадываюсь хотя видел много разных дистрибутивов).
Просто у меня всё время ощущение, что среднестатистический пользователь считает, что "разработчик должен сделать пакет для установки ПО" и не задумывается, что под словом "разработчик" две обычно не связанных между собой стороны (разработчики дистрибутива и разработчики ПО). Пользователю конечно и не нужно в этом разбираться, но все ошибки ожидания (должен ли быть пакет в репозитории, насколько он должен быть интегрирован в систему и т.д.) из этого проистекают.
С готовыми пакетами есть две стороны 1) разработчики дистрибутива и 2) разработчики ПО и тут либо:
пакет собирают первые (разработчики дистрибутива) и тогда он идеально встроен в дистрибутив (доступны нужные версии библиотек-зависимостей), будет ярлык в кнопке Пуск, настройки по умолчанию, контекстные менюшки в файловом менеджере и остальное принятые в этом дистрибутиве плюшки. НО делает это человек знающий дистрибутив, а не разработчик ПО (то есть может поверхностно знать внутренности самого ПО, тем более нюансы новой версии ПО при её выходе).
пакет собирают вторые (разработчики ПО) и тогда они идеально знают своё ПО, но не знают 100500 особенностей различных дистрибутивов и пакет будет "так себе" встроен в систему (чем проще утилита, тем меньше проблем).
У пакетов с открытыми исходниками меньше проблем с внедрением в различные системы (дистрибутивы), так как он проходит через глаза разных ментейнеров (разработчики разных дистрибутивов) и их работа по внедрению в систему накапливается (появляются spec-файлы для сборки пакета, документация, локализация на разные языки и тд) - эти наработки часто используется для сборки этого пакета в 100500ый новый дистрибутив. С закрытым ПО (даже если есть пакет под Linux) нет таких возможностей.
eget (📨) - утилита для скачивания ПО в виде небольших предварительно скомпилированных утилит из GitHub. Оно ищет в, указанном в виде аргумента команды, github-репозиторие исполняемый файл (в том числе и внутри архивов, а также переименует appimage-файл) и копирует его в /usr/local/bin
eget - интересная идея (есть риск не проверенные вредонос запустить, но мысль интересная). Переварю - добавлю в статью
А из упомянутых в ansible-плейбуке: утилитой yq пользовался, lnav не давно как раз натыкался (с мыслей, что вроде интереснее чем ccze) - и yq и lnav встречал в репозиториях некоторых дистрибутивах
tstack/lnav - The Logfile Navigator
koenbollen/jl -- translating structured message into old-fashioned log lines
mikefarah/yq -- lightweight and portable command-line YAML, JSON and XML processor
Только эти (hostnamectl, lsb_release -a, uname -a, cat /etc/*release* и cat /proc/version) показывают "какой дистрибутив используете", а не "с каким совместим используемый вами дистрибутив"
ALT Linux создан на базе операционной системы Mandrake, которая, в свою очередь, базируется на Red Hat.
Альт не создан на основе Mandrake. Не вводите людей в заблуждение. То что "до выпуска своего дистрибутива некоторая часть AltLinuxTeam выпустила русскую локализацию Mandrake" не означает, что всё что они выпустили потом основано на Mandrake.
Альт самостоятельный дистрибутив - не RedHat-based и не Mandrake-based.
Больше всего команд начинается с буквы: s(107), f(92), p(68), l(62), m(57), g(53), c(52). Меньше всего команд начинается с буквы: j(8), y(8), z(10), q(14), k(15).
Всё было нужно разобраться в вызове функция командой complete, но не позволяла (скорее всего лень) сложности перевода английской документации в bash (для zsh давно разобрался) - в итоге половину статьи прочитал и всё понял))
Неверно про Alt "имеет оригинальный графический интерфейс собственной разработки (Alterator), который сделан по лекалам Windows", а правильно "имеет оригинальный графический интерфейс настройки и установки системы собственной разработки (Alterator) и используется интерфейс рабочего стола (MATE и есть версия с KDE), который сделан похожим на Windows"
Разработчик ПО не знает тонкостей дистрибутива, не потому что криворук, а потому что дистрибутив очень много и помимо сделанных по одним лекалам (различные ...-based дистрибутивы) есть очень уж много таких что авторы продвигают какой-то новый подход (как то всякие "атомарно обновляемые", "свой формат пакетов", "все прикладное в snap" и 100500 других идей, о которых я даже пока не догадываюсь хотя видел много разных дистрибутивов).
Просто у меня всё время ощущение, что среднестатистический пользователь считает, что "разработчик должен сделать пакет для установки ПО" и не задумывается, что под словом "разработчик" две обычно не связанных между собой стороны (разработчики дистрибутива и разработчики ПО). Пользователю конечно и не нужно в этом разбираться, но все ошибки ожидания (должен ли быть пакет в репозитории, насколько он должен быть интегрирован в систему и т.д.) из этого проистекают.
Абсолютно верно сказано.
С готовыми пакетами есть две стороны 1) разработчики дистрибутива и 2) разработчики ПО и тут либо:
пакет собирают первые (разработчики дистрибутива) и тогда он идеально встроен в дистрибутив (доступны нужные версии библиотек-зависимостей), будет ярлык в кнопке Пуск, настройки по умолчанию, контекстные менюшки в файловом менеджере и остальное принятые в этом дистрибутиве плюшки. НО делает это человек знающий дистрибутив, а не разработчик ПО (то есть может поверхностно знать внутренности самого ПО, тем более нюансы новой версии ПО при её выходе).
пакет собирают вторые (разработчики ПО) и тогда они идеально знают своё ПО, но не знают 100500 особенностей различных дистрибутивов и пакет будет "так себе" встроен в систему (чем проще утилита, тем меньше проблем).
У пакетов с открытыми исходниками меньше проблем с внедрением в различные системы (дистрибутивы), так как он проходит через глаза разных ментейнеров (разработчики разных дистрибутивов) и их работа по внедрению в систему накапливается (появляются spec-файлы для сборки пакета, документация, локализация на разные языки и тд) - эти наработки часто используется для сборки этого пакета в 100500ый новый дистрибутив. С закрытым ПО (даже если есть пакет под Linux) нет таких возможностей.
Добавил в пункт Архив с исполняемыми файлами:
eget - интересная идея (есть риск не проверенные вредонос запустить, но мысль интересная). Переварю - добавлю в статью
А из упомянутых в ansible-плейбуке: утилитой
yqпользовался,lnavне давно как раз натыкался (с мыслей, что вроде интереснее чемccze) - и yq и lnav встречал в репозиториях некоторых дистрибутивахtstack/lnav - The Logfile Navigator
koenbollen/jl -- translating structured message into old-fashioned log lines
mikefarah/yq -- lightweight and portable command-line YAML, JSON and XML processor
как раз на прошлой неделе решил посмотреть, что из себя предоставляет этот дистрибутив
NAME="MOS Desktop"
ID=mos
ID_LIKE=rosa
PRETTY_NAME="MOS Desktop 12"
...
:)
Посмотрел из своих старых записей - три дистрибутива:
NAME="Rocky Linux"
VERSION="9.3 (Blue Onyx)"
ID="rocky"
ID_LIKE="rhel centos fedora"
...
NAME="SLES"
VERSION="15-SP5"
VERSION_ID="15.5"
PRETTY_NAME="SUSE Linux Enterprise Server 15 SP5"
ID="sles"
ID_LIKE="suse"
...
NAME="Manjaro Linux"
PRETTY_NAME="Manjaro Linux"
ID=manjaro
ID_LIKE=arch
...
проще и корректнее (без проблем с файлам в названии, которых есть "пробел"):
tail -n+1 /etc/*releaseТолько эти (hostnamectl, lsb_release -a, uname -a,
cat /etc/*release* и cat /proc/version)показывают "какой дистрибутив используете",
а не "с каким совместим используемый вами дистрибутив"
Спасибо, ссылки добавлю
Как назвать по вашему блок с "Pip, Cargo и так далее"?
В остальном не вижу противоречий - написали тоже самое что и в статье, но со своими примерами.
сегодня 25 августа - день первого упоминания о системе, получившей название Linux, так что 🖐Linux, с днем Рождения!!! 🎂 📖
Да - так корректнее написано.
Только в таблице еще осталось запись "База:Mandrake"
Альт не создан на основе Mandrake. Не вводите людей в заблуждение. То что "до выпуска своего дистрибутива некоторая часть AltLinuxTeam выпустила русскую локализацию Mandrake" не означает, что всё что они выпустили потом основано на Mandrake.
Альт самостоятельный дистрибутив - не RedHat-based и не Mandrake-based.
Добавь еще в статью про опции -X и -Y утилиты ssh - наиболее полезное для начинающих
:)
намекаете NIH-синдром у них?
В списке их утилит:
52 утилиты fly-* (из них 32 утилиты fly-admin-* - gui чтобы админы вместо правки конфигов кнопки жали)
5ток утилит pdp* (для работы с их мандатными метками).
Половина вполне неплохо работают, но большая часть не opensource
Всего 1005 команд (02/11/2023):
Больше всего команд начинается с буквы: s(107), f(92), p(68), l(62), m(57), g(53), c(52).
Меньше всего команд начинается с буквы: j(8), y(8), z(10), q(14), k(15).
Сделал разделы с буквами и добавил ссылки:
Все ссылки: ><(6) A(42) B(33) C(52) D(44) E(24) F(92) G(53) H(23) I(35) J(8) K(15) L(62) M(57) N(37) O(32) P(68) Q(14) R(35) S(107) T(40) U(29) V(29) W(22) X(28) Y(8) Z(10)
P.S. Перевалил через 1000 команд и через 1000 закладок
Спасибо - Полезный перевод.
Всё было нужно разобраться в вызове функция командой complete, но не позволяла (скорее всего лень) сложности перевода английской документации в bash (для zsh давно разобрался) - в итоге половину статьи прочитал и всё понял))
Неверно про Alt "имеет оригинальный графический интерфейс собственной разработки (Alterator), который сделан по лекалам Windows", а правильно "имеет оригинальный графический интерфейс настройки и установки системы собственной разработки (Alterator) и используется интерфейс рабочего стола (MATE и есть версия с KDE), который сделан похожим на Windows"