#linux #windows #администрирование #faq #deb
Не холивара ради, но накоплений точек зрения для.
Замучился отвечать одно и тоже в одинаковых темах "я запустил .run и всё сломалось",
"я распаковал tar и компьютер взорвался", поэтому создал вопрос, чтобы в дальнейшем
ссылаться сюда.
Ответы
Ответ 1
Чем плохо: Плохое обновление. В классическом варианте, менеджер пакетов сам проверяет наличие обновления, сам выкачивает и сам ставит. Руками поставленный бинарник или не будет обновляться вообще или будет обновляться тем способом, который выбрал разработчик. В итоге получаем кучу кастомных обновлялок, которые "висят в трее" и непонятно что делают. Плохое сопровождение. Вытекает из первого пункта. Раз непонятно как программа обновляется (не факт, что через скрипт, может и через бинарник), то непонятно куда, что, как, когда, зачем она ставит. При передаче системы в другие руки - нужно больше документации и объяснений кто с кем дружит, а кого в сеть не пускаем. Зоопарк версий. В linux библиотеки общие для всей системы. QT, mp3, java ставятся один раз и используются всеми, кому надо. В случае с ручной установкой, в систему (/opt тоже система) ставятся компоненты мутных версий, которые используются только этой программой. Проблемы начинаются, когда надо закрыть уязвимость, а что делать непонятно, потому что неизвестны (или надо сильно копать) версии и что сломается, если заменить один компонент, но оставить другой. Этим как раз и должен заниматься менеджер пакетов. Проблемы с совместимостью. В системе может быть старая версия ядра или libc и тогда программа будет вести себя весьма странно, если вообще заведётся. Обновление libc руками может уронить вообще всё остальное. Большие затраты по силам и времени. На большом количестве софта установленного руками, времени на поддержание версий в актуальном состоянии тратится просто вагон, а при наличии не одной машины - увеличивается до неприличных цифр. Проблемы с удалением. При удалении проги надо удалить все бинарники, библиотеки, кэши и конфиги, пройтись по всем /var/, /lib/ и /usr/. Самое главное - не удалить ничего лишнего, иначе см. выше про libc. На это тоже уходит порядочное количество времени. Чем хорошо: Свежие версии от разрабов. Не надо дожидаться слоупоков от дистрибутива, которые будут тестировать никому ненужную совместимость с остальными компонентами. Не надо привыкать к другой философии. На винде работало - чем тут хуже? Критические обновления безопасности ставят автоматом только трусы. Меня это не коснётся, мой проект хакерам не интересен. Можно почувствовать себя Ъ-][@k3r0m делая ./configure && make && make install и превращая Ubuntu\CentOS\SuSe в Slackware. Можно прочувствовать всю боль мейнтейнеров постоянно борясь с вылазиющими конфликтами компонентов. Дополнение 1. Отдельно стоит упомянуть виртуалки и контейнеры. Хостовая система будет изолирована, внутрь их можно делать сколь угодно ужасный деплой (но помнить, что плохой код\конфиг в любом уровне абстракции остаётся плохим), если придерживаться концепции атомарного обновления: хочешь обновить что-то - обнови в новом окружении всё что надо, замени старое, а старое грохни. FAQ. Q: А я делаю make install на локалхосте 5 лет и брат пока что жив. A: Молодец, возьми пирожок с полки. deb\rpm\etc придумали не потому, что дело было вечером и делать было нечего. Древние задолбались ставить всё руками и решили ввести абстракцию для облегчения жизни себе и другим. Значит у тебя не те объёмы, чтобы понять какой подарок сделала концепция пакетных менеджеров для администрирования систем. Q: Этим вашим deb и dnf я не могу поставить 2-3-5 версий библиотек в одну систему. Я буду продолжать использовать tar xvf. A: Никто не Вуди Аллен^W^W идеален. Или иди в ногу со всеми и пиши на том, на чём сидит большинство или используй контейнеры\виртуалки. Как вариант - найди дистрибутив, в котором пакетный менеджер позволяет это делать. Q: Тут нет самой свежей версии $AWESOME_SOFTWARE. Где там мой wget? A: Пакетный менеджер $DISTRONAME не серебряная пуля, но он покрывает ~90% потребностей обычного пользователя или админа. Нужна свежая версия? Сами разрабы часто держат свою репу под популярные дистрибутивы. И там можно даже dev-ветку из гита попробовать. Чешутся руки СОБИРАТЬ@КОМПИЛЯТЬ - запакеть то, что собрал и после этого устанавливай. Так, менеджер пакетов будет знать что делать и куда слать алярмы. Q: А что на счёт pip\gem\npm\? A: Спорно. С одной стороны - это менеджер пакетов, с другой - про его действия не сообщается "главному" менеджеру. Но если нет нужных компонентов у родителя, а они нужны позарез, то лучше хоть что-то, чем tar. Ну и если не использовать суперпользователя, то тот же питон ставится в домашний каталог не ломая текущие версии. Более того, оф. документация НЕ рекомендует ставить пакеты через pip в систему.
Комментариев нет:
Отправить комментарий